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

"Laconic2" <laconic2_at_comcast.net> wrote in message news:t6adncXPEMhfsVfdRVn-sw_at_comcast.com...
>
> "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?

I think the way this is handled is one of the (rather few) areas that is not the same with each MV database on the market. In the UniData environment, with which I am most familiar, if there are "associated multivalues" then they are identified as such and this "association" is named in the dictionary -- the vocabulary of the view of the data through a particular portal. So, I can talk about each multivalued field individually, or the association (nested table-ish) by its name.

Keep in mind that unlike an RDBMS schema, the vocabulary for MV/PICK systems is descriptive of the data and not constraining. The same data can be described in many different ways. The association would really be a type of derived data.

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

No we don't -- oddly enough, it is though. smiles. --dawn Received on Sun Jun 13 2004 - 04:30:52 CEST