Are you an EPFL student looking for a semester project?
Work with us on data science and visualisation projects, and deploy your project as an app on top of GraphSearch.
Concept
Composite key
Summary
In database design, a composite key is a candidate key that consists of two or more attributes (table columns) that together uniquely identify an entity occurrence (table row). A compound key is a composite key for which each attribute that makes up the key is a foreign key in its own right.
Composite keys have advantages similar to that of a natural key as it is often composed of multiple natural key attributes.
Composite keys use less disk space as compared to defining a surrogate key column, this is because the composite key already exists as attributes in the table and does not need to be defined in the table just for the purpose of unique identification. This simplifies the table and also saves space.
Composite keys are easy to implement in a database schema as their component parts are already named items in the database. When they are also natural keys, they are often intuitive for real world scenarios. They are often used when a non-composite key does not always uniquely identify a record. For example, a personal name may often, but not always, be unique in a given database, and some other field such as date of birth may be added to make uniqueness much more probable.
The business requirements and rules can change which can change the format of certain real world entities. Composite keys are formed of multiple natural keys which are related to the real world and with the change of their format in the real world, their format in the database will also be changed. This is inconvenient as the number of attributes of composite key will change and all the foreign keys would need to be updated.
A composite key consists of multiple attributes and the composite key will be referenced in multiple tables as the foreign key, this uses a lot of disk space as multiple columns are being stored as the foreign key instead of just possibly one. This makes the schema complex and the queries become more CPU expensive as for every join the DBMS will need to compare three attributes instead of just possibly one in case of a single natural key.
Official source
About this result
This page is automatically generated and may contain information that is not correct, complete, up-to-date, or relevant to your search query. The same applies to every other page on this website. Please make sure to verify the information with EPFL's official sources.
Related publications (24)
Related concepts (7)
Natural key
A natural key (also known as business key or domain key) is a type of unique key in a database formed of attributes that exist and are used in the external world outside the database (i.e. in the business domain or domain of discourse). In the relational model of data, a natural key is a superkey and is therefore a functional determinant for all attributes in a relation.
Foreign key
A foreign key is a set of attributes in a table that refers to the primary key of another table. The foreign key links these two tables. Another way to put it: In the context of relational databases, a foreign key is a set of attributes subject to a certain kind of inclusion dependency constraints, specifically a constraint that the tuples consisting of the foreign key attributes in one relation, R, must also exist in some other (not necessarily distinct) relation, S, and furthermore that those attributes must also be a candidate key in S.
Primary key
In the relational model of databases, a primary key is a specific choice of a minimal set of attributes (columns) that uniquely specify a tuple (row) in a relation (table). Informally, a primary key is "which attributes identify a record," and in simple cases constitute a single attribute: a unique ID. More formally, a primary key is a choice of candidate key (a minimal superkey); any other candidate key is an alternate key.