Re: What predicates the following relation represents

From: Mikito Harakiri <mikharakiri_at_iahu.com>
Date: Wed, 31 Mar 2004 15:59:04 -0800
Message-ID: <T4Jac.40$rc5.20_at_news.oracle.com>


"mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message news:406b4865$0$559$e4fe514c_at_news.xs4all.nl...
> >>Key is fine, but what about the fact
> >>
> >><PART=Nuts, SOLD=0>
> >>
> >>Is it the same as the absence of the tuple?
>
> In other words: what fact is conveyed? What does it *mean* ?

I don't understand. Do you request more details? More formality?

OK, more formally, when do we find convenient to consider

|--A
|--SALE(Nuts, 0)

as equivalent to

|--A
|--!exists x>0: SALE(Nuts, x)

where A is some arbitrary set of clauses? (There might be not much substance in that kind of questions within logic realm, but I want to understand what aggregation is and its connection to logic).

> > 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.
>
> Requirements is much to broad. Meaning. Just meaning. Necessary and
> sufficient.

If you refer me to Model theory, let me think it over.

> >>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.
>
> To achieve conceptual integrity one needs concepts.

Be careful using the same abstract word twice in the sentence. Received on Thu Apr 01 2004 - 01:59:04 CEST

Original text of this message