Re: No exceptions?

Jon Heggland wrote:
> Erwin wrote:
>

>>>I keep five database textbooks in my office: Date, Elmasri/Navathe,
>>>Garcia-Molina/Ullman/Widom, Ramakrishnan/Gehrke, and Riccardi. All of
>>>them agree with me: a key is an irreducible superkey.

That is provably false.

  Granted, two of

>>>them say that "key" is short for "candidate key", but that does not
>>>invalidate my position; one says that "candidate key" is what you call a
>>>key when a relation has more than one; and the others don't use the term
>>>at all, afaict. All agree that a proper superkey is not a key.
>>>
>>>Whose "contract" should I abide by? Yours, or theirs?
>>
>>Check out Date.  I believe you'll find Bob's statements are in line
>>with Date's.

You have me at a slight disadvantage because most of my books are still packed in boxes after my move last year. Nevertheless, grabbing a few from one of the top boxes:

_The Database Relational Model, A Retrospective Review and Analysis_ C. J. Date (2001) page 11: "A key is said to be /nonredundant/ if every attribute it contains is necessary for the purpose of unique identification; that is, if any attribute were removed, what would be left wouldn't be a unique identifier any more. ("Key" here thus means what we now call a /superkey/, and a "nonredundant" key is what we now call a /candidate/ key--candidate keys being "nonredundant," or /irreducible/, by definition.)

It sure seems that key refers to all kinds of keys here: candidate, superkey, nonredundant key, redundant key, irreducible key, reducible key etc.

_What Not How, The Business Rules Approach to Application Development_ C. J. Date (2000) page 92:
"
* First, a /candidate/ key is a set of columns that can serve as a unique identifier for the table in question and includes no column that's unnecessary for unique identification purposes. ... * Second, a /superkey/ is a superset of a candidate key (so a candidate key is always a superkey, but the converse is false.) ... * Finally, a /primary/ key is a candidate key that's chosen for some reason to be "more equal than the others." "

Again, all of the above are keys.

I won't bother quoting _Volume II, An Introduction to Database Systems_ because it is out of date. On page 191, it defines candidate key, primary key, alternate key etc.

_Foundation for Object/Relational Databases, The Third Manifesto_ C. J. Date and Hugh Darwen (1998) page 143: "RM PRESCRIPTION 15: CANDIDATE KEYS" defines a candidate key as unique and irreducible.

Page 198: "A /superkey/ is a superset--not necessarily a proper superset--of a candidate key; in other words, a superkey satisfies the uniqueness property but not necessarily the irreducibility property. A /proper/ superkey is a superkey that definitely does not satisfy the irreducibility property."

Page 69: "We use the unqualified /keyword/ KEY to refer to a candidate key specifically, for simplicity." (emphasis mine) In other words, Date and Darwen define key to mean all kinds of keys and for brevity create a lexical token, KEY, within the grammar for Tutorial D that refers specifically to a candidate key.

_Relational Database Design, Clearly Explained_ Jan L. Harrington is not a worthwhile book. She defines only primary key and foreign key.

_Database, Principles, Programming, Performance_ Patrick O'Neil is again not a worthwhile book. I note that he tries to use your definition of 'key' as 'a candidate key only' on pp. 39-40; however, I note that at the same time he makes the mistake of excluding an empty set of attributes as a candidate key. He also makes the rather sloppy/stupid mistake of confusing a subset with a proper subset. In spite of defining key to mean only a candidate key, everywhere else in the book, he nevertheless uses candidate key rather than key. pp. 295, 386 etc.

_Relational Database Systems_ Dan A. Simovici and Richard L. Tenney. Again, not a worthwhile book. They try to define key to mean only a candidate key. Again, they exclude an empty set of attributes in a candidate key, but they make the further mistake of equating 'candidate key' with 'superkey' including proper superkeys as candidate keys.

_Database System Implementation_ Hector Garcia-Molina, Jeffrey D. Ullman and Jennifer Widom (2000) page 647 uses key even more broadly to include hash keys, search keys and sort keys.

Page 125 in the text box titled: "Keys and More Keys" they state: "The term "key" has several meanings, and this book uses "key" in each of these ways when the situation warrants it. ... We try to use the appropriate adjective -- "primary," "sort," or "search" -- when the meaning of "key" is unclear. However, notice in sections such as 4.1.2 and 4.1.3 that there are many times when the three kinds of keys are one and the same."

One wonders how you concluded they equate 'key' with 'irreducible superkey'.

> Did he change his mind? Perhaps, or perhaps he just nailed down what the
> unqualified term "key" means. In any case it seems clear to me that when
> Date now uses the term "key", he means an irreducible superkey.

Perhaps he changed his mind. Perhaps you misuderstood him. I don't know.

If he has changed his mind, it wouldn't be the first time he and I disagree on some point.

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.

> Now, can anyone cite sources that treat "key" and "superkey" as
> synonyms? That is what the opposition is arguing, isn't it?

Key is not a synonym for superkey. Key is a much broader term. Received on Mon Jul 03 2006 - 19:25:56 CEST