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

"Eric Kaun" <ekaun_at_yahoo.com> wrote in message news:eMoyc.25262$674.5547_at_newssvr31.news.prodigy.com...

>
> > Months ago, I asked whether a pizza with pepperoni and onion was the
same
> > as a pizza with onion and pepperoni.
> >
> > I got several cute responses, but nobody really addressed the underlying
> > issue. Sounds like you've got a handle on it.
>
> It's a slippery handle, but maybe - but be careful asking about "the same
> as" in an OO context - that subject gets very confusing to OOers. :-)
>
> A related and interesting issue is that of relation-valued attributes as
> primary keys; for example, from one of Date's non-free papers, a relation
> with a single column: a relation of siblings. Since in a relation order is
> irrelevant, you couldn't insert the tuple ( {Eric, Curt, Amy} ) if the
> relation already contained ( {Amy, Curt, Eric} ), for example. He did a
> similar thing with prime factors; the relation consisted of 2 columns:
> Integer and {Integer}.
>
> Anyway, I'm rambling...

I don't think it's rambling at all... It's precisely where I was heading with the question.

There's a second question, along the same lines.

In the recent Pick example, showing an invoice, there's a list of account numbers, and a correlated list of amounts. That is, the second amount "goes with" the second account number. But, in the earlier pizza pick example we had a list of three toppings and an uncorrelated list of three cheeses. Now my question is this: how the heck do you know that in one case the two lists are correlated and in the other example they are uncorrelated?

Are you "just expected to know" the logical structure of invoices and pizzas enough to draw this inference?
Not that there aren't things you "just have to know" in a schema of tables, but the Pick people treat it as though it's "intuitively obvious". Maybe to an SME, but maybe not to everybody else. Received on Sat Jun 12 2004 - 00:07:22 CEST