Re: What predicates the following relation represents

From: Eric Kaun <ekaun_at_yahoo.com>
Date: Wed, 31 Mar 2004 19:48:55 GMT
Message-ID: <HgFac.574$ho2.515_at_newssvr32.news.prodigy.com>


"Mikito Harakiri" <mikharakiri_at_iahu.com> wrote in message news:jbDac.26$rc5.89_at_news.oracle.com...
>
> "Eric Kaun" <ekaun_at_yahoo.com> wrote in message
> news:ToAac.46100$jm6.6203_at_newssvr16.news.prodigy.com...
> > "Mikito Harakiri" <mikharakiri_at_iahu.com> wrote in message
> > news:mrmac.22$mR.124_at_news.oracle.com...
> > > SALES
> > > =====
> > > PART SOLD
> > > ---- ---
> > > nuts 10
> > > nuts 15
> > >
> > > Is SALES a legal relation? Is database really a repository of facts?
> >
> > Yes, a database is a repository of facts.
> >
> > It's a legal relation, though the external predicate to which it
> corresponds
> > may be nonsense. You can always define a candidate key over all the
> > attributes - that doesn't mean it makes sense to do so.
>
> Just a key. I never understood the difference between "primary" and
> "unique", let alone "candidate". I guess they are mathematically
> indistinguishable, that is why there is no decent definitions for those
> adjectives.

A primary key is an arbitrarily-chosen candidate key, and is downplayed by Date as being of little importance. UNIQUE is a SQL artifact, but could be interpreted as meaning candidate key. Candidate keys identify functional dependencies.

> Key is fine, but what about the fact
>
> <PART=Nuts, SOLD=0>
>
> Is it the same as the absence of the tuple?

Not necessarily - the above looks like a derived relation, rather than a base one. If it were a base one, given common-sense interpretations of the attribute names, I'd say the presence of the tuple was meaningless. If a derived one, then it has meaning - no nuts were sold. It's hard to say without understanding the requirements, but is certainly suspicious.

> My humble interpretation is that the SALES table with attributes PART and
> SOLD is still physical model. This relation on logical level is
>
> select PART, sum(SOLD) from SALES
> group by PART

Agreed, that's probably the way it should be, but the SQL above isn't equivalent to the data you gave earlier, or nuts wouldn't appear twice. Perhaps there's some external predicate that might make the relation valid - but I doubt it. It's most likely simply poor design.

  • erk
Received on Wed Mar 31 2004 - 21:48:55 CEST

Original text of this message