Talk:Candidate key
From Wikipedia, the free encyclopedia
A candidate key is a concept in the relational model of data. Any set of attributes upon which all attributes of a relation are functionally dependant is a candidate key.one of this key is made primary key.
- That's not the usual definition of candidate key, but of superkey. Who gave this definition? -- Jan Hidders 23:10, 25 Apr 2004 (UTC)
You cannot infer candidate keys from a single instance of a relation. It is too easy to insert a tuple and blow the keys good-bye. This example should go away.
- Just deleting it would be a bit blunt, as it does make an important point. I have put it back with some explanation. -- Jan Hidders 14:50, 2 Nov 2004 (UTC)
-
- From AndrewWarden 16:33, 3 February 2006 (UTC):
-
- I noticed that yesterday somebody actually deleted the example and placed a line of gibberish in its place, resulting in that action being cancelled out by an editor. I wonder if the reason for the attempted deletion was the logical error I found and tried to correct. The error was an observation that you might be able to conclude that a certain subset of the heading of a certain "instance", having the uniqueness property, is not a CK because it in turn has some proper subset having the uniqueness property in that "instance". That's quite wrong, as explained in my replacement text.
-
- I do completely agree with Ejrrjs's remarks below, but the observation that you can sometimes infer that some subset is not a CK is valid, so I've left it in. I don't think it's a very useful observation as far as database design is concerned, but it might be useful educationally. I would not object to deleting it.
Suppose that the relation also has the following instance:
| A | B | C | D |
|---|---|---|---|
| a1 | b1 | c1 | d1 |
| a1 | b1 | c1 | d2 |
| a1 | b1 | c2 | d1 |
| a1 | b2 | c1 | d1 |
| a2 | b1 | c1 | d1 |
Now the only viable key for the ABCD schema is ABCD. This means that we have to restrict somehow which instances are valid. We do that by means of functional dependencies. But these FDs have a semantic value, as in the real world A, B, C, D stand for product#, year, color, size, etc. Hence A->B is a property of the real world and cannot be inferred from a sample of instances, it has to be developed from a business model that states what makes sense to the user(s) by means of whatever elicitation technique is useful for that user situation. Afterwards, from your (complete) set of basic FDs you can automatically infer, using Armstrong rules, all valid FDs for the schema AND all valid candidate keys. Am I making myself clear? This is why I think it is misleading to suggest that you can obtain the candidate keys from one isolated instance of that schema. If you need references, Ullman, Helman, Navathe, etc...you'll get them.
Kindly, Ejrrjs 23:07, 2 Nov 2004 (UTC)
- Er, yes, that hadn't escaped me, but the point was that instead of just deleting the example and trying to impress me with your expertise it would be so much more nicer if you used that expertise to improve the example. It's not every day that someone with a PhD in database theory passes by here, you know. :-) So tell me, how do you like the article now? -- Jan Hidders 00:04, 4 Nov 2004 (UTC)
This example in the article isn't too good in my opinion. An example of a sample normal table could have explained it better.--80.227.100.62 07:47, 31 October 2006 (UTC)
[edit] foreign keys
I'm a bit scratchy on my theory here, but I think the following statement is wrong:
Foreign keys, for example, are usually required to reference such a primary key and not any of the other candidate keys.
If I understand candidate keys correctly, then most RDBMS do allows foreign key relationships with any candidate key that has a unique or primary key defined. John Vandenberg 08:50, 20 February 2007 (UTC)
