Re: In an RDBMS, what does "Data" mean?

From: Marshall Spight <mspight_at_dnai.com>
Date: Tue, 29 Jun 2004 01:53:15 GMT
Message-ID: <fY3Ec.124315$eu.6858_at_attbi_s02>


"mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message news:40e09d5e$0$65807$e4fe514c_at_news.xs4all.nl...
> 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.

> <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.

> 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.

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>.

> 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}.

I wish it was simpler, but it's not.

Marshall Received on Tue Jun 29 2004 - 03:53:15 CEST

Original text of this message