Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
Database Servers
DB2InformixIngresMS SQLOraclePervasive.SQLPostgreSQLProgressSybase
Desktop Databases
FileMakerFoxProMS AccessParadox
General
General DB TopicsDatabase Theory
Related Topics
Java Development.NET DevelopmentVB DevelopmentMore Topics ...

Database Forum / General DB Topics / DB Theory / July 2005

Tip: Looking for answers? Try searching our database.

dumb terminology question: candidate key

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Marshall  Spight - 15 Jul 2005 06:09 GMT
Does anyone have any insight or information on the origin
of the term "candidate key"? It seems like a standout bad
term in a field full of not-very-good terms.

A "candidate" is something that aspires to a particular position,
but hasn't attained it yet. So the term suggests that we're
*considering* declaring this set of attributes to be unique,
but we're not sure yet. We'll get back to you once we're sure.

What advantage does this term have over the simpler term "key"?
Any reason we just shouldn't all say key? We don't say "primary
candidate key" or "foreign candidate key" do we?

Marshall
Jonathan Leffler - 15 Jul 2005 06:34 GMT
Marshall Spight wrote:
> Does anyone have any insight or information on the origin
> of the term "candidate key"? It seems like a standout bad
[quoted text clipped - 8 lines]
> Any reason we just shouldn't all say key? We don't say "primary
> candidate key" or "foreign candidate key" do we?

In the bad old days - say 1990 - the perceived rules of the RM were that
every relation had one primary key.  Unfortunately, some relations had a
number of unique keys - think of a table of chemical elements, where
atomic number, symbol and name are each possible keys (that is,
candidate keys) - so if you selected one key as the primary key (which
one), the others were alternative (or was it alternate) keys.  There was
also the entity integrity rule that said that primary keys could not
allow nulls - but alternative keys could (but an alternative key that
allowed nulls was no longer a candidate key and hence not really an
alternative key after all; what a tangled web nulls weave!)  The
collection of unique keys were all candidate keys - one was selected as
the primary, and the rest became alternatives.

Then the primacy of primary keys was called into question; normalization
theory didn't deal with primary keys, only with candidate keys.  So
primary keys lost some of their significance, and the term that was left
was candidate keys.

Signature

Jonathan Leffler                   #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2005.01 -- http://dbi.perl.org/

Marshall  Spight - 15 Jul 2005 08:57 GMT
> Marshall Spight wrote:
> > Does anyone have any insight or information on the origin
[quoted text clipped - 12 lines]
> collection of unique keys were all candidate keys - one was selected as
> the primary, and the rest became alternatives.

I see. So the thing it's a candidate for is being the primary key.

Wow.

> Then the primacy of primary keys was called into question; normalization
> theory didn't deal with primary keys, only with candidate keys.  So
> primary keys lost some of their significance, and the term that was left
> was candidate keys.

Now that we know better, I propose that we drop the term "candidate"
from "candidate key" and leave just "key." I say this with all the
naive optimism of youth. (A good trick at my age.)

Marshall
David  Cressey - 16 Jul 2005 12:32 GMT
> > Marshall Spight wrote:
> > > Does anyone have any insight or information on the origin
[quoted text clipped - 27 lines]
>
> Marshall

The earlier replies cover the answer to your question.

As to whether the word "key" can be used without a qualifier,  note that
there are other terms, such as:

foreign key
natural key
surrogate key
index key

So dropping the word "candidate" might create more problems than it solves.

As far as "dumb terminology"  goes,  consider the phrase "flashlight
battery".   In Britain, what we Americans call a "flashlight" is called an
"electric torch".  A more functional description, really.  How often do you
use a flashlight to flash?

And the word "battery" properly refers not to an individual cell,  but to a
group of cells operating as a team,  like a battery of cannon.

There are historical reasons for this, which I'll omit.

If we start down the trail of repairing all the dumb terminology we've
inherited, there will be no end of it.
Marshall  Spight - 16 Jul 2005 15:12 GMT
> As far as "dumb terminology"  goes,  consider the phrase "flashlight
> battery".   In Britain, what we Americans call a "flashlight" is called an
> "electric torch".

But the USA doesn't have much backgroud with torches, whereas is
Europe,
there is a long history of villagers storming eccentic scientist's
castle with torches. I know because I've seen that in the movies
many times.

> If we start down the trail of repairing all the dumb terminology we've
> inherited, there will be no end of it.

Heh, I've never been much persuaded by the line of argument
that goes, "sure, this is bad, but other things are bad, too,
so do nothing."

Marshall
dawn - 16 Jul 2005 16:00 GMT
> > Marshall Spight wrote:
> > > Does anyone have any insight or information on the origin
[quoted text clipped - 24 lines]
> from "candidate key" and leave just "key." I say this with all the
> naive optimism of youth. (A good trick at my age.)

Works for me, youngster.  When we ditch the candidate key term, can we
add "primary key" back in?  I'd like to keep the notion of a primary
key that does not map to the mathematical model, but to people.  It
could also help in tools since there is often a key that could be
deemed the one most likely to be used as a foreign key to this relation
(could be the default unless someone chooses another).  I suspect there
are quite a few dbms implementations that still have this concept by
whatever name (identity, id, pk etc).  So, let's ditch the candidate
key term and refrain from booing when we hear about primary and
alternate keys.  OK?

Cheers!  --dawn

> Marshall
Marshall  Spight - 21 Jul 2005 18:50 GMT
> > Now that we know better, I propose that we drop the term "candidate"
> > from "candidate key" and leave just "key." I say this with all the
> > naive optimism of youth. (A good trick at my age.)
>
> Works for me, youngster.

(I'm old enough that being called "youngster" is pleasantly quaint,
the way one feels about a well-meant compliment that couldn't
possibly be true. :-)

> When we ditch the candidate key term, can we
> add "primary key" back in?

I don't know that we ever formally took it out. That said,
I buy into Date's claim that the concept is one of convenience,
not formalism.

> I'd like to keep the notion of a primary
> key that does not map to the mathematical model, but to people.  It
[quoted text clipped - 5 lines]
> key term and refrain from booing when we hear about primary and
> alternate keys.  OK?

Again, as a convenience, particularly a notational convenience,
it makes sense. There are some concerns, but I think they can
be managed.

Marshall
paul c - 15 Jul 2005 21:38 GMT
Marshall Spight wrote:
> Does anyone have any insight or information on the origin
> of the term "candidate key"? It seems like a standout bad
> term in a field full of not-very-good terms.

i'd say the very word 'key' is an unfortunate one, although i can
sympathize with Dr. Codd using it, given the context of the ignorant
times thirty-five years ago.  i've heard from various first-hand sources
that not only was there resistance within IBM to his ideas but he was
under constant attack, especially from IBM's powerful sales arm, so much
so that some people thought his first stroke was due to it.  perhaps he
was using the term 'key' because in those days with the various
file-systems, let alone IMS, it was a very common term.  i have the
impression that he wanted to use terminology that had some familiarity
and wouldn't inflame the bigots.

as most people seem to use it today it is a subset of attribute values
that are uni..ue (sorry, keyboard is broken, i mean no duplicates), in
fact a constraint.  i believe it is possible to avoid the term
completely, since most relational algebras are capable of defining it
without resorting to a 'keyword', although i don't know of any that are
that rigourous.

> A "candidate" is something that aspires to a particular position,
> but hasn't attained it yet. So the term suggests that we're
> *considering* declaring this set of attributes to be unique,
> but we're not sure yet. We'll get back to you once we're sure.
> ...

following the political analogy, you might just as well call it a 'draft
key'.

regarding terms, i remember reading that CJ Date said that
'normalization' had nothing to do with China.  i don't have a copy
anymore, but i also remember reading, i think it was in DBMS magazine
around 1993, an interview with Edgar Codd where he said that he did in
fact borrow the term around 1970 when Nixon was 'normalizing'
'relations' with that country.  can anybody back up or refute this?

paul c.
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.