Re: No exceptions?

Bob Badour wrote:

> Jon Heggland wrote:

_Principles of Database Systems with Internet and Java Applications_ Greg Riccardi (2001) page 99: "A /superkey/ of a relation schema is a set of attributes that functionally determines all other attributes of the table. [...] We can now give a formal definition of 'key' based on the definition of functional dependency. A set of attributes A is a /key/ of a relation schema if A is a superkey and any proper subset of A is not a superkey."

_Database Management Systems_ Raghu Ramakrishnan and Johannes Gehrke (2003) page 29: "A *key* is a minimal set of attributes whose values uniquely identify an entity in the set."

_Database Systems: The Complete Book_ Hector Garcia-Molina, Jeffrey D. Ullman and Jennifer Widom (2002) page 84--85: "We say that a set of one or more attributes {A1,A2,...,An} is a /key/ for a relation R if: 1. Those attributes functionally determine all other attributes of the relation. [...] 2. No proper subset of {A1,A2,...,An} functionally determines all other attributes of R; i.e., a key must be /minimal/."

_Fundamentals of Database Systems_ Ramez Elmasri and Shamkant B. Navathe (2000) page 203: "A superkey can have redundant attributes, however, so a more useful concept is that of a /key/, which has no redundancy. A *key* K of relation schema R is a superkey of R with the additional property that removing any attribute A from K leaves a set of attributes K' that is not a superkey of R. Hence, a key is a /minimal superkey/---that is, a superkey from which we cannot remove any attributes and still have the uniqueness constraint hold."

_Database In Depth_ C. J. Date (2005) page 63: "Let K be a subset of the heading of relvar R. Then K is a /candidate key/ (or just /key/ for short) for R is and only if it possesses both [uniqueness and irreducibility]." (The same formulation is used in _Databases, Types, and the Relational Model: The Third Manifesto_ (2007), page 26.) Page 64: "[W]e require keys not to include any attributes that aren't needed for unique identification purposes." Page 139: "Thus, every key is a superkey, but most superkeys aren't keys; for example, {SNO,CITY} is a superkey for relvar S but not a key."

>> Thus, to
>> say that a key might be reducible has very little (if any) support from
>> Date, might indeed contradict Date, and certainly contradicts several
>> other textbooks.

> 
> I disagree. I have provided citations above that demonstrate exactly the
> opposite.

Thank you. With regard to Date, I'll concede this much: His older writings weakens my position---but his most recent writing strengthens it. I also note that your other citations does *not* support your position; at best they weaken mine by associating the "key<->irreducible" definition with "not worthwhile" books. The point about hash keys, search keys and sort keys is hardly relevant; I'm well aware that "key" may have other meanings in other contexts.

In any case, I hope you all agree that it has been shown without a doubt that there are two differing schools of thought---which is good to know for both sides. From current evidence, the sides appear to be Date anno 2001 versus the rest (including Date anno 2005), but no matter---in the interest of clarity, I'll include the qualifier "irreducible" hereafter when talking about keys in this newsgroup. "Candidate" is a bad, bad name---but that is a different discussion.

-- 
Jon