Editing Superkey (section)

{{Short description|Set of attributes that uniquely identifies each tuple of a relation}}
{{about|the database design term|the keyboard button|Super key (keyboard button)}}

In the [[relational model|relational data model]] a '''superkey''' is any [[Set (mathematics)|set]] of attributes that uniquely identifies each [[tuple]] of a [[Relation (database)|relation]].<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 |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><ref>
{{cite book|title=Introduction to Database Management Systems|publisher=Tata McGraw-Hill|page=77|isbn=9780070591196|year=2005|quote=no two tuples in any legal relation
}}</ref> Because superkey values are unique, tuples with the same superkey value must also have the same non-key attribute values. That is, non-key attributes are [[functional dependency|functionally dependent]] on the superkey.

The set of all attributes is always a superkey (the trivial superkey). Tuples in a relation are by definition unique, with duplicates removed after each operation, so the set of all attributes is always uniquely valued for every tuple. A [[candidate key]] (or minimal superkey) is a superkey that can't be reduced to a simpler superkey by removing an attribute.<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>

For example, in an employee schema with attributes <code>employeeID</code>, <code>name</code>, <code>job</code>, and <code>departmentID</code>, if <code>employeeID</code> values are unique then <code>employeeID</code> combined with any or all of the other attributes can uniquely identify tuples in the table. Each combination, {<code>employeeID</code>}, {<code>employeeID</code>, <code>name</code>}, {<code>employeeID</code>, <code>name</code>, <code>job</code>}, and so on is a superkey. {<code>employeeID</code>} is a candidate key, since no subset of its attributes is also a superkey. {<code>employeeID</code>, <code>name</code>, <code>job</code>, <code>departmentID</code>} is the trivial superkey.

If attribute set ''K'' is a superkey of relation ''R'', then at all times it is the case that the [[Projection (relational algebra)|projection]] of ''R'' over ''K'' has the same [[Cardinality (data modeling)|cardinality]] as ''R'' itself.