Re: In an RDBMS, what does "Data" mean?
Date: Thu, 01 Jul 2004 23:33:33 +0200
Message-ID: <40e4832a$0$93324$e4fe514c_at_news.xs4all.nl>
Marshall Spight wrote:
> mAsterdam wrote:
>>Marshall Spight wrote: >> >>>>>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 :-)
>
> Mostly I agree. But I don't think the "we should"
> part always applies. Sometimes we should, and
> sometimes we shouldn't. It depends on what
> particular operations we want to do. The most
> flexible way is where we get to choose.
The flexible way would unfortunately also
be the way that would force us to make
decicions where there are no
a priori criteria.
If *all* we want is to assiocate some meaning with the order of some values, the *only* meaningful thing besides those values should be the order of them. Nothing more - for if we would have more, we'd have to decide between them, and thus be forced to assign meaning where we have none.
The fact that there are so many ways to represent lists (just read a few of Jan Hidders' links), all with different consequences, suggests that there should be a visible, simple part (only the values in order + operators) and an invisible, complex part (the values, and all that is necessary to keep them in order under the visible operators).
The complex, invisible part could use the flexiblity to make efficiency decisions based on the (a posteriori) actual content and usage of the values, but these choices should in no way affect the content of the visible, meaningful part.
>><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).
>
> No, I don't think I do. What you have to do is decide
> how you are going to model your data. *That* choice
> is fundamental; you can't get rid of it. Do your pizza
> toppings come in order or not? The data model you're
> working with won't help you make that decision; it
> only comes into play when you have to figure out how
> to *express* that decision.
We decided that, beside the values, the order
is relevant.
For now, it would be a good thing (TM) to
also decide/assume that *only* the order
and the values are relevant.
>>But later. One thing at a time. For now: lists!
>
> Deal.
>
>>>>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 ;-)
>
> Well, okay; whether a particular aspect of your data model
> is ordered or not is part of the conceptual modelling; that's
> the part that's all art, no science.
Yep, hence the assumptions.
> Pizza Hut's pizza-ordering web app treats pizza toppings
> as unordered; I postulate a chain called "Bob's Totally
> Delicious Pizza withTotally Ordered Pizza Toppings"
> that keeps them in order.
:-)
>>>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.
>
> Ah; I see. I agree the list members should be first-class
> citizens. Thus, you should be able to say, I have a list
> of items which are each foreign keys to <whatever>.
Exactly.
>>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'.
>
> Yes, but you wanted to talk about lists, and a totally
> ordered set is not the same thing as a list!
>
> Consider the string "abca". This is a list of characters,
> but it certainly isn't a totally ordered set over {abc}.
Yep, that is clear. I was also thinking about precedence ordering (CPM/PERT type planning graphs) to *exclude* them from the problem space (at least for now).
> I wish it was simpler, but it's not.
You wouldn't have volonteered if it were :-) Received on Thu Jul 01 2004 - 23:33:33 CEST