Keys in the Relational Model
Super key, candidate key, primary key, alternate key, composite key, foreign key and surrogate key, defined formally with a worked method for finding every candidate key of a relation.
-
DBMS Fundamentals
- Data, Information and Databases
- What a DBMS Is and Why It Exists
- File System versus DBMS
- Advantages and Limitations of a DBMS
- Database Users and the Role of the DBA
- Three Level Architecture and Data Abstraction
- Logical and Physical Data Independence
- Schema, Instance and Metadata
- Database Applications and the Database System Environment
- Database Architecture
- Data Models
-
ER Model
- Entities, Entity Sets and Entity Types
- Types of Attributes in the ER Model
- Keys in the ER Model
- Relationships, Relationship Sets and Degree
- Cardinality and Participation Constraints
- Strong and Weak Entities
- Drawing and Reading ER Diagrams
- Extended ER: Generalisation, Specialisation and Aggregation
- Converting an ER Diagram into Relational Tables
- ER Design Projects
- Relational Model
- Relational Algebra
- Functional Dependencies
-
Normalisation
- Why Normalisation Exists: Anomalies and Redundancy
- First Normal Form
- Second Normal Form and Partial Dependency
- Third Normal Form and Transitive Dependency
- BCNF and BCNF Decomposition
- 4NF, 5NF, Multivalued and Join Dependencies
- Lossless Decomposition and Dependency Preservation
- Complete Worked Normalisation: Unnormalised to BCNF
- Denormalisation and When to Use It
Concept
Because a relation is a set, no two tuples may be identical, so every relation must have some attribute set that identifies its tuples uniquely. Keys are how that is expressed.
The formal definitions
| Key | Definition |
|---|---|
| Super key | An attribute set K such that no two tuples of any valid instance have the same value for K. |
| Candidate key | A super key with no proper subset that is also a super key — that is, a minimal super key. |
| Primary key | The candidate key chosen by the designer to identify tuples. Cannot be null. |
| Alternate key | Any candidate key not chosen as the primary key. |
| Composite key | Any key consisting of more than one attribute. |
| Foreign key | An attribute set in one relation whose values must appear as a primary key value in another relation, or be null. |
| Surrogate key | A system generated attribute with no meaning outside the database, used as the primary key. |
Minimality is the whole difference
STUDENT ( roll_no, email, name, dob )
roll_no unique, email unique
{roll_no} super key, and MINIMAL -> candidate
{email} super key, and MINIMAL -> candidate
{roll_no, name} super key, NOT minimal -> only super
{roll_no, email} super key, NOT minimal -> only super
{roll_no, email, name, dob} super key, NOT minimal -> only super
{name} NOT a super key - names repeat
{name, dob} probably not - two people can match
Number of super keys grows fast: any set containing a
candidate key is a super key. Candidate keys are the
interesting ones because they are irreducible.Finding all candidate keys, worked
Given R ( A, B, C, D ) with the rule that A and B together determine C and D, and C alone determines D.
STEP 1 which attributes never appear on the right hand
side of any rule? Those MUST be in every key.
rules: A B -> C D
C -> D
right hand sides: C, D
so A and B never appear there
-> { A, B } must be part of every candidate key
STEP 2 can { A, B } determine everything?
A B -> C D yes, directly
so { A, B } determines A, B, C, D = all of R
STEP 3 is it minimal?
{ A } alone -> nothing. no
{ B } alone -> nothing. no
so { A, B } is minimal
ANSWER the only candidate key is { A, B }
C is not a candidate key: C determines only D,
never A or BPhase 7 turns this into a general algorithm using attribute closure. The reasoning is identical; the notation becomes formal.
Choosing the primary key
- Unique — guaranteed, not merely likely.
- Not null — required by entity integrity.
- Stable — never updated, because every foreign key copies it.
- Minimal — fewer attributes means smaller indexes and smaller foreign keys.
- Simple — a short integer compares faster than a long string.
- Not sensitive — a primary key is copied into every referencing table, so never use personal identifiers.
Natural and surrogate keys compared
| Natural | Surrogate | |
|---|---|---|
| Meaning | Real world value | None |
| Stability | The real world changes it | Never changes |
| Nulls | May be unknown at first | Always available |
| Readability | A person can recognise it | Meaningless to a person |
| Extra column | No | Yes |
| Risk | Reissued or corrected values break references | Duplicates enter unless the natural key is also constrained unique |
The important rule with surrogate keys: a surrogate key does not remove the need for a uniqueness constraint on the natural key. Without it, the same real world thing is inserted twice with two different generated ids, and nothing complains.
Foreign keys
A foreign key expresses a relationship by value. Its rule, stated precisely: every non null foreign key value must exist as a primary key value in the referenced relation. That is referential integrity, covered in full in the next two notes.
STUDENT ( roll_no, name, dept_code )
|
+--> DEPARTMENT ( dept_code, name )
A foreign key MAY be null, unless declared otherwise. Null
means "this student is not attached to any department" -
which is different from referring to a department that does
not exist, and that difference is why nulls are allowed here
but never in a primary key.Common mistakes
- Calling any unique attribute set a candidate key. Minimality is required.
- Assuming one relation has one candidate key. It may have several; all but one become alternate keys.
- Believing a foreign key must reference a different relation. A self reference is normal — an employee manager column references employees.
- Adding a surrogate key and no unique constraint on the natural key. Duplicates then enter silently.
- Choosing a changeable attribute as primary key. Every referencing row has to change with it.
Exam and interview questions
- Define super, candidate, primary, alternate, composite, foreign and surrogate keys.
- Why is every candidate key a super key but not the reverse?
- Find all candidate keys of R(A,B,C,D) given AB determines CD and C determines D.
- Can a foreign key be null? Can a primary key? Explain both.
- State six criteria for choosing a primary key.
Practice
- For EMPLOYEE ( emp_id, pan, email, name, dept ) with emp_id, pan and email each unique, list all candidate keys and choose a primary key with reasons.
- Give a relation whose only candidate key is composite, and explain why no single attribute works.
- Explain in three sentences why a mobile number should not be a primary key even though it looks unique.
Conclusion
Super keys identify, candidate keys identify minimally, and one candidate is chosen as the primary key. Foreign keys carry relationships by value, and the rule to remember with surrogate keys is that they never remove the need for a uniqueness constraint on the real world key.