Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: Counting propositions

Re: Counting propositions

From: Dawn M. Wolthuis <dwolt_at_tincat-group.com>
Date: Tue, 15 Jun 2004 09:35:09 -0500
Message-ID: <can1f6$k04$1@news.netins.net>

"x" <x-false_at_yahoo.com> wrote in message news:40ceeb61$1_at_post.usenet.com...
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> news:cakuee$ak4$1_at_news.netins.net...
>
> > When, if ever, should aggregate values be designed into base
> > relations?
>
> This is a tough one. :-)
> Because being a base or a derived relation is accidental there is no rule.
> :-)

I suspect most designers would suggest that if you have the information on which the aggregate is based, then you put that into a base relation and aggregate from the granular data. But there are so many exceptions to this in actual use.

> The only rule I can think of is minimizing consistency checks.
>
> > Date uses a parts example, with a quantity, as an example relation in
his
> > database textbook. By designing a quantity of a part into a relation,
> there
> > is an acknowledgement that you are designing aggregate data, rather than
> > having a separate tuple for each real world part.
>
> When there is no way to discriminate the "real world parts" by data in the
> database.
> Think about this. If you think you understood, think again.

Oh zen master, it appears I wrote something similar above. And, yes, I agree that this is non-trivial (apparently lacking a zen mood if using words like non-trivial). [anecdote: my daughter had an exam in a course something like World Religions this past year on which she was asked for a definition of Zen. She drew a flower. Fortunately the professor understood and gave her full credit for that response.]

> > nr, in your example, is derived aggregate data. It is derived from the
> > propositions already instantiated. Derived aggregate data is always
with
> > respect to a particular point in time, so that information needs to be
in
> > the resulting proposition in which nr is used.
>
> Both derived and base aggregate data depend on the point in time.
>
> > At <point in time> the count of distinct instances of <relvar> is <nr>
>
> > I might be completely missing what you are getting at, however, so
perhaps
> > you could provide more clues?
>
> Why someone would need to count "distinct instances of <relvar>" ?

Ah, so it was a specifically relational question you were asking. Since most relations are functions (that is, they have a candidate key that could be used as a function domain) I can see no need for the use of distinct.

cheers! --dawn Received on Tue Jun 15 2004 - 09:35:09 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US