In database design, a compound key is a key that consists of 2 or more attributes that uniquely identify an entity occurrence. Each attribute that makes up the compound key is a simple key in its own right.
This is often confused with a composite key whereby even though this is also a key that consists of 2 or more attributes that uniquely identify an entity occurrence, at least one attribute that makes up the composite key is not a simple key in its own right.
An example of a compound key might be an entity that represents the modules each student is attending at University. The entity has a studentId and a moduleCode as its primary key. Each of the attributes that make up the primary key are simple keys because each represents a unique reference when identifying a student in one instance and a module in the other.
Now imagine we have an entity representing a deck of cards. Each card is uniquely identified by its suit and rank/value. The primary key of the entity would be a composite key in this case since the attributes which make up the primary key are not simple keys in and of themselves. By itself, neither a suit nor a value, can uniquely identify a card.
No restriction is applied to the attributes regarding their (initial) ownership within the data model. This means that any one, none, or all, of the multiple attributes within the compound key can be foreign keys. Indeed, a foreign key may itself be a compound key.
Compound keys almost always originate from attributive or associative entities (tables) within the model, but this is not an absolute.
- relational database
- candidate key
- primary key
- alternate key
- foreign key
- unique key
- surrogate key
- Composite Inverse Functional Properties: for an equivalent notion in the Semantic Web