Editing Candidate key

{{Short description|Set of columns in a relational database}}
A '''candidate key''', or simply a '''key''', of a [[relation schema|relational database]] is any set of [[Column (database)|columns]] that have a unique combination of values in each row, with the additional constraint that removing any column could produce duplicate combinations of values.

A candidate key is a minimal [[superkey]],<ref>{{cite web |url=https://www.dcs.warwick.ac.uk/~hugh/TTM/CJD-on-EFC's-First-Two-Papers.pdf |title=Codd's First Relational Papers: A Critical Analysis |last=Date |first=Christopher |date=2015 |website=warwick.ac.uk |publisher= |access-date=2020-01-04 |quote=Note that the extract allows a “relation” to have any number of primary keys, and moreover that such keys are allowed to be “redundant” (better: ''reducible''). In other words, what the paper calls a primary key is what later (and better) became known as a ''superkey'', and what the paper calls a nonredundant (better: ''irreducible'') primary key is what later became known as a ''candidate key'' or (better) just a ''key''.}}</ref> 
i.e., a superkey that does not contain a smaller one. Therefore, a relation can have multiple candidate keys, each with a different number of attributes.<ref>{{Cite web |title=database - Can a relation have Candidate Keys with different lengths? |url=https://stackoverflow.com/questions/45533608/can-a-relation-have-candidate-keys-with-different-lengths |access-date=2023-03-23 |website=Stack Overflow |language=en}}</ref>

Specific candidate keys are sometimes called ''[[primary key]]s'', ''secondary keys'' or ''alternate keys''.
The columns in a candidate key are called '''prime attributes''',<ref>{{Cite journal|last=Saiedian|first=H.|date=1996-02-01|title=An Efficient Algorithm to Compute the Candidate Keys of a Relational Database Schema|url=https://academic.oup.com/comjnl/article-lookup/doi/10.1093/comjnl/39.2.124|journal=The Computer Journal|language=en|volume=39|issue=2|pages=124–132|doi=10.1093/comjnl/39.2.124|issn=0010-4620|url-access=subscription}}</ref> and a column that does not occur in any candidate key is called a '''non-prime attribute'''.

Every relation without NULL values will have at least one candidate key: Since there cannot be duplicate rows, the set of all columns is a superkey, and if that is not minimal, some subset of that will be minimal.

There is a [[functional dependency]] from the candidate key to all the attributes in the relation.

The superkeys of a relation are all the possible ways we can identify a row. The candidate keys are the minimal subsets of each superkey and as such, they are an important concept for the design of [[database schema]].

==Example==
The definition of candidate keys can be illustrated with the following (abstract) example. Consider a relation variable ([[relvar]]) ''R'' with attributes (''A'', ''B'', ''C'', ''D'') that has only the following two legal values ''r1'' and ''r2'':

{| class="wikitable"
|+ ''r1''
|-
! A
! B
! C
! D
|-
| a1
| b1
| c1
| d1
|-
| a1
| b2
| c2
| d1
|-
| a2
| b1
| c2
| d1
|}

{| class="wikitable"
|+ ''r2''
|-
! A
! B
! C
! D
|-
| a1
| b1
| c1
| d1
|-
| a1
| b2
| c2
| d1
|-
| a1
| b1
| c2
| d2
|}

Here ''r2'' differs from ''r1'' only in the '''A''' and '''D''' values of the last tuple.

For ''r1'' the following sets have the uniqueness property, i.e., there are no two distinct tuples in the instance with the same attribute values in the set:
: {A,B}, {A,C}, {B,C}, {A,B,C}, {A,B,D}, {A,C,D}, {B,C,D}, {A,B,C,D}
For ''r2'' the uniqueness property holds for the following sets;
: {B,C}, {B,D}, {C,D}, {A,B,C}, {A,B,D}, {A,C,D}, {B,C,D}, {A,B,C,D}
Since superkeys of a relvar are those sets of attributes that have the uniqueness property for ''all'' legal values of that relvar and because we assume that ''r1'' and ''r2'' are all the legal values that ''R'' can take, we can determine the set of superkeys of ''R'' by taking the intersection of the two lists:
: {B,C}, {A,B,C}, {A,B,D}, {A,C,D}, {B,C,D}, {A,B,C,D}
Finally we need to select those sets for which there is no [[subset#proper subset|proper subset]] in the list, which are in this case:
: {B,C}, {A,B,D}, {A,C,D}
These are indeed the candidate keys of relvar ''R''.

We have to consider ''all'' the relations that might be assigned to a relvar to determine whether a certain set of attributes is a candidate key. For example, if we had considered only ''r1'' then we would have concluded that {A,B} is a candidate key, which is incorrect. However, we ''might'' be able to conclude from such a relation that a certain set is ''not'' a candidate key, because that set does not have the uniqueness property (example {A,D} for ''r1'').  Note that the existence of a proper subset of a set that has the uniqueness property ''cannot'' in general be used as evidence that the superset is not a candidate key.  In particular, note that in the case of an empty relation, every subset of the heading has the uniqueness property, including the empty set.

==Determining candidate keys==
The set of all candidate keys can be computed
e.g. from the set of [[Functional dependency|functional dependencies]].
To this end we need to define the attribute closure <math>\alpha^+</math> for an attribute set <math>\alpha</math>.
The set <math>\alpha^+</math> contains all attributes that are functionally implied by <math>\alpha</math>.

It is quite simple to find a single candidate key.
We start with a set <math>\alpha</math> of attributes and try to remove successively each attribute.
If after removing an attribute the attribute closure stays the same,
then this attribute is not necessary and we can remove it permanently.
We call the result <math>\text{minimize}(\alpha)</math>.
If <math>\alpha</math> is the set of all attributes,
then <math>\text{minimize}(\alpha)</math> is a candidate key.

Actually we can detect every candidate key with this procedure
by simply trying every possible order of removing attributes.
However there are many more [[permutation]]s of attributes (<math>n!</math>)
than [[power set|subsets]] (<math>2^n</math>).
That is, many attribute orders will lead to the same candidate key.

There is a fundamental difficulty for efficient algorithms for candidate key computation:
Certain sets of functional dependencies lead to exponentially many candidate keys.
Consider the <math>2\cdot n</math> functional dependencies
<math>\{A_i \rightarrow B_i : i\in\{1,\dots,n\}\} \cup \{B_i \rightarrow A_i : i\in\{1,\dots,n\}\}</math>
which yields <math>2^n</math> candidate keys:
<math>\{A_1, B_1\} \times \dots \times \{A_n, B_n\}</math>.
That is, the best we can expect is an algorithm that is efficient with respect to the number of candidate keys.

The following algorithm actually runs in polynomial time in the number of candidate keys and functional dependencies:<ref>
{{cite journal
 | last1 =L. Lucchesi
 | first1 =Cláudio
 | last2 =Osborn
 | first2 =Sylvia L.
 | title =Candidate keys for relations
 | journal =Journal of Computer and System Sciences
 | volume =17
 | issue =2
 | pages =270–279
 | date =October 1978
 | doi=10.1016/0022-0000(78)90009-0
| doi-access =
 }}
</ref>

 '''function''' find_candidate_keys(A, F)
     /* A is the set of all attributes and F is the set of functional dependencies */
     K[0] := minimize(A);
     n := 1; /* Number of Keys known so far */
     i := 0; /* Currently processed key */
     '''while''' i < n '''do'''
         '''for each''' α → β ∈ F '''do'''
             /* Build a new potential key from the previous known key and the current FD */
             S := α ∪ (K[i] − β);
             /* Search whether the new potential key is part of the already known keys */ 
             found := false;
             '''for''' j := 0 to n-1 '''do'''
                 '''if''' K[j] ⊆ S '''then''' found := true;
             /* If not, add it */
             '''if''' '''not''' found '''then'''
                 K[n] := minimize(S);
                 n := n + 1;
         i := i + 1
     '''return''' K

The idea behind the algorithm is that given a candidate key <math>K_i</math>
and a functional dependency <math>\alpha \rightarrow \beta</math>,
the reverse application of the functional dependency yields
the set  <math>\alpha \cup (K_i \setminus \beta)</math>,
which is a key, too.
It may however be covered by other already known candidate keys.
(The algorithm checks this case using the 'found' variable.)
If not, then minimizing the new key yields a new candidate key.
The key insight is that all candidate keys can be created this way.

==See also==
* [[Alternate key]], a key that is not selected as a primary key among candidate keys for a relationship
* [[Compound key]]
* [[Database normalization]]
* [[Primary key]]
* [[Relational database]]
* [[Superkey]]
* [[Prime implicant]] is the corresponding notion of a candidate key in [[boolean logic]]

==References==

{{reflist}}
* {{cite book
| last = Date
| first = Christopher
| authorlink = Christopher J. Date
| title = An Introduction to Database Systems
| publisher = Addison-Wesley
| isbn = 978-0-321-18956-1
| year = 2003
| pages = 268–276
| chapter = 5: Integrity
}}

==External links==
* [http://rdbms.opengrass.net/2_Database%20Design/2.1_TermsOfReference/2.1.2_Keys.html Relational Database Management Systems - Database Design - Terms of Reference - Keys]: An overview of the different types of keys in the RDBMS (Relational Database Management System).

{{Databases}}

[[Category:Data modeling]]
[[Category:Relational model]]
[[Category:Database management systems]]