Re: In an RDBMS, what does "Data" mean?
Date: Tue, 29 Jun 2004 00:36:22 +0200
Message-ID: <40e09d5e$0$65807$e4fe514c_at_news.xs4all.nl>
Marshall Spight wrote:
> mAsterdam wrote:
>>Marshall Spight wrote:
>>
>>>>Let's put a new element 'N' into
>>>>the list, right after the 'B':
>>>>
>>>>The new list is [A, B, N, C].
>>>>Now what is the set?
>>>>
>>>>is it UC1: { (1, A), (2, B), (3, C), (2.5, N) } or
>>>>is it UC2: { (1, A), (2, B), (4, C), (3, N) } ?
>>>
>>>It's UC2.
>>
>>Ok. No argument, just wondering: any particular reason to
>>discard UC1?
>
> If you deviate from the integer domain for your index, you
> no longer have a list; you now have just another set with
> just another regular attribute. A list or sequence is a mapping
> from the natural numbers to another set. For example, a string
> is a mapping from nat -> char.
>
> UC1 is a perfectly valid approach; it's just not a list.
Now I am puzzled. What makes the integer *not* a regular attribute? -
I'll try myself: it is easier to hide.
And that is exactly what is
necessary. We can pretend it's not there, and
we should, because in the unambigous list
presentation it is not there. Any more data
than exactly necessary for presenting the
order should not be visible.
(Yep: interface :-)
<snip>
>
> Something the information principal *doesn't* say is that
> those relations cannot be a subtype of relation.
> Ordered relation is a subtype of unordered relation, and
> list is a subtype of ordered relation. And if we allow relation-
> valued attributes (RVAs) then that means we also allow
> lists as attributes.
How does this eliminate the extra choice to make? (- I think you agree it should).
>>So we have to answer the question: which attribute(s') >>values? The answer seems obvious: list typed attributes. >>But that's not the way it is done - so what stops that? >>I know: the lack of the "Spight list algebra"!
>
> Actually, I think it's exactly that. (Not that it needs to
> have my name on it, of course.) I think we need a *theoretical*
> understanding of the subtyping relationship between
> sets, totally ordered sets, partially ordered sets, and lists.
> (Mathematicians, of course, have had this understanding
> for years, but not too many people in data management
> are there yet. Still, I wish I knew as much math as, say
> Mikito Harakiri.)
>
> We also need the relational language to have a type system
> that isn't antediluvian. SQL's type system is right in line
> with other languages of the day, such as FORTRAN, Cobol,
> and Pascal (or C for that matter.) It hasn't advanced much,
> at least not in the type system, and it's extraordinary market
> success has defeated all newcomers.
Yep. Types. Sigh. Gimme gimme gimme :-)
But later. One thing at a time. For now: lists!
>>>[note if you do them in the wrong order you're screwed.] >> >>No problem. Assume a preprocessor and make a >>macro^H^H^H^H^H shorthand.
>
>
> Agreed, but I think that for practical purposes you *have* to
> have this shorthand form.
/me nods.
>>>I don't think the choice is intrinsically complex. I think >>>the issue is just that SQL (and TTM for that matter) don't >>>give you even the most basic list manipulation or integrity >>>checks. >> >>The more options we have, the more serious the problem is. >>Is list [A, B, N, C] ambiguous? Is 'insert Y into L1 after B' >>amibiguous?
>
> I'd say "no" and "no." I'm not certain I see your point, though.
> Maybe it's that the current situation is quite complicated if
> you want to handle lists? I'd agree with that. That's why I
> think we need those list primitives (derived from that
> list algebra) to make it simple.
>
>>Say we have a pizza-attribute 'topping' of type 'list-of-toppings'
>
> Why is that a list? When I go to pizza hut and ask for ham and
> pineapple, I get the same thing as if I asked for pineapple and
> ham. Pizza toppings aren't a list; they're a set.
To connaisseurs it's a list. The order of the toppings matters. I assumed that this foundation of the pizza-model was common knowledge ;-)
> I think part of the reason people see lists everywhere is because
> they're used to supplying information in the form of a list,
> even when the order info isn't relevant. This makes for
> potential program bugs, because
>
> List{ham, pineapple} != List {pineapple, ham}
> but
> Set {ham, pineapple} == List {pineapple, ham}
>
>>Is 'constraint FK topping refers to toppings' ambiguous?
>
> I don't get the question.
After the above pizza-model 101 you probably do.
It's just to state that the list-member should be first class^H^H^H^H^H type citizens.
>>If it is intrinsically simple as you say - what is your >>explanation why SQL (and TTM) do simply not address meaningful >>order? >> >>Maybe we are just overlooking something obvious.
>
> I think Date et. al.'s usual culprit suffices here: lack of education.
> I would note, ironically, that that group has never managed
> to clarify the (IHMO) essential distinction between partial
> order and total order when discussing order.
I have to admit that I suppressed bringing it (partial order) in
earlier. I think complete sequence (non-partial order) is to
be viewed as a special case of partial ordering (1 part).
So maybe the simplest strategy is: get the simple, special
case first in thorough detail,
than tackle the more complicated (partial order), than show
the simple case is a specialization of the complex.
Not unlike the approach in 'Temporal data'.
>>>I was more thinking of something like the relational algebra, >>>with its minimal set of operators, additional operators defined >>>in terms of the minimal ones, and a definition of what it means >>>for a set of operators to be complete. Only for lists. >>> >>>Frighteningly, if I can't find something like that, I may have >>>to do it myself. >> >>"Spight list algebra". Sounds good. :-)
>
>
> I'll get right on it. :-)
Just lists for now, ok? Received on Tue Jun 29 2004 - 00:36:22 CEST