Re: Constraints and Functional Dependencies
Date: 25 Feb 2007 02:43:33 -0800
Message-ID: <1172400213.391876.210030_at_q2g2000cwa.googlegroups.com>
On 24 fév, 20:22, mAsterdam <mAster..._at_vrijdag.org> wrote: [Snipped]
> Obviously you did not yet read the responses to the OP when you wrote
> this. By now you may have. This is the same point paul c raises in his
> second reply to the OP, stated another way, right?
Maybe (not sure). The primary key issue is not in fact as important
as the underlying domain concept beneath. See the proposed alternate
formal definition for understanding better what I am getting at.
> One minor nitpick: The distinction between *primary* key and other
> keys is considered to be a practical choice for implementing DBMS's.
> As long as there is no established theoretical
> need for this distinction, we can just use these:
> key and candidate key (candidate key if there are more keys).
>
> Slightly more important: at this stage in the OP's
> argumentation the term (candidate) key has not yet been defined.
Indeed. But there is an important domain prerequisite definition to
define of both pk and ck or choose to ignore them .
> Who cares about proofs these days ;-)
Honest people.
> A reductio ad absurdem, no less.
Indeed. Effective to reveal conceptual dead ends.
> ... because P is not really key to S. QED.
Did anybody mention ck?
> > Second reason: the formalism R(a) *may* lead to the confusion between
> > relation variable and attribute...
Attribute based relational conceptual handling in computing quickly
reveals limitations when drawn into pure mathematics formal
demonstration. I do not see how Codd could not have been aware of
this. I extrapolate he had to make a choice to give a chance of
implementing relation into computing . (I thank him *even* for that
else the notion of domain would have never been put on our hand)
Received on Sun Feb 25 2007 - 11:43:33 CET