Re: Counting propositions

• Post for FREE via your newsreader at post.usenet.com ****

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:can1f6$k04$1_at_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.

Similarly there are no rules about what candidate key to pick as a primary key, when to use a composite key, and maybe other stuff like this.

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

Similar is not good enough. :-)
If you think you understood, think again. :-)

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

Why "fortunately" ? It seems it is a good professor.

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

Yes. It was a relational question. I gived several clues toward this. I used keywords such as: proposition, tuple, relation, relvar.

But it was not about SQL and the use of "*" and "distinct" in SQL.

Why most relations are functions ?
Have you counted them ? :-)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

• Usenet.com - The #1 Usenet Newsgroup Service on The Planet! *** http://www.usenet.com Unlimited Download - 19 Seperate Servers - 90,000 groups - Uncensored -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=