A composite key, in the context of relational databases, is a combination of two or more columns in a table that can be used to uniquely identify each row in the table. Uniqueness is only guaranteed when the columns are combined; when taken individually the columns do not guarantee uniqueness.
Any column(s) that can guarantee uniqueness is called a candidate key; however a composite key is a special type of candidate key that is only formed by a combination of two or more columns. Sometimes the candidate key is just a single column, and sometimes it is formed by joining multiple columns.
Consider an example of a certain table in the database of a commercial bank. This table is used to store records of individuals' bank accounts. Assuming that the table has separate columns for the account type (C for checking, S for savings and so on), followed by another column for the year and month of the account’s creation, and another column for a sequential number within that month, it is obvious that any one of these columns by itself cannot identify an account – one can deduce that there would be several C’s in the “Account Type” column, there would be several entries for May 2008 in the “Date of Creation” column, and so on. However, if all three columns are combined, then a unique record for each and every account is produced. A hypothetical account number in this example would be "C 200807 001" for the first account created in July 2008, which is a checking account. Another is "S 201003 004" for the fourth savings account created in March 2010. This is a composite key, that is, a candidate key that guarantees uniqueness only when two or more columns are joined together.
A composite key can be defined as the primary key. This is done using SQL statements at the time of table creation. It means that data in the entire table is defined and indexed on the set of columns defined as the primary key.