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's formed by joining multiple columns.
Let us 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. Now assume 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- for instance you 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, you combine all the three columns, then you do end up with a unique record for each and every account. A hypothetical account number in our 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 account created in March 2010, this time a savings account. This is a composite key, that is, a candidate key that guarantees uniqueness only when two or more columns are joined together.
