Concatenated primary key: Also known as composite primary key is a combination of two or more column values used to define a key in a table. Primary-key columns were discussed in the preceding lesson. Primary-key columns contain values that uniquely identify a record within a table. Sometimes a single column does not contain sufficient information to distinguish one record from every other record in the table.
Consider the Line Item table:
Line Item
OrderNo
CDNo
Quantity
SellingPrice
Discount
LineCost
Shipped
Unable to create unique Record for Database Table
No single column contains enough information to set a record apart from every other record in the table, though OrderNo and CDNo are the most likely prospects. The problem is, an order can contain more than one CD and a CD can be part of more than one order. It is possible to create a CDOrderID column, but there is an easier solution:
Create Concatenated Primary key: Solution: Create a concatenated primary key. You should create a concatenated primary key based on the existing columns in the database table. A concatenated primary key is a primary key made up of two or more columns. In the case of the Line Item table, each record is uniquely identified by the combined values of
the OrderNo and
CDNo
which are columns located at the extreme left of the table. We are assuming a particular CD will not occur more than once in an order.
Two Additional Rules for Concatenated Primary Keys:
Concatenated primary keys need to follow two additional rules:
They should contain the smallest number of columns required to uniquely identify each record.
The columns should not contain meaningful information. You may need to break this rule on occasion, but those circumstances are very rare.
Meaningful Information in Database
In the context of relational databases, the term meaningful information refers to information that describes an attribute of an entity represented in a table, such as a customer's first name, last name, address, or phone number. It might be tempting to use one or more of those attributes in a primary key, but bear in mind that values for those attributes can change. Customers can change their names, move, or install new phone numbers. A customer could be entered into the table twice if one customer-relations staff member entered the address as "17th Ave. SE " and another entered the same address as "SE 17th Ave.".
When you assign arbitrary values, such as a CustID, to each customer, you avoid these problems.
Regardless of whether customers change their name or residence, you will always have their orders and other information tied to their original CustID value.
For concatenated primary keys or composite primary keys:
The concatenation of all of the primary key columns mst be unique
None of the primary keys columns may contain null
Relations, Attributes, and Tuples
The values in a row are related by the fact that they apply to a particular person. Because of this fact, the formal term for a table is a relation[1]. This can cause some confusion because the word relation is also used informally to describe a relationship between two tables. The formal term for a column is an attribute or data element. The formal term for a row is a tuple. This almost makes sense if you think of a two-attribute relation as holding data pairs, a three-attribute relation as holding value triples, and a four-attribute relation as holding data quadruples. Beyond four items, mathematicians would say 5-tuple, 6-tuple, and so forth, hence the name tuple. Do not confuse the formal term relation (meaning table) with the more general and less precise use of the term that means "related to" as in "these fields form a relation between these two tables". Similarly, do not confuse the formal term attribute with the less precise use that means "feature of" as in this field has the required attribute. Theoretically a relation does not impose any ordering on the tuples that it contains nor does it give an ordering to its attributes. Generally the orderings do not matter to mathematical database theory. In practice, however, database applications usually sort the records selected from a table in some manner to make it easier for the user to understand the results. It is also a lot easier to write the program (and for the user to understand) if the order of the fields remains constant, so database products typically return fields in the order in which they were created in the table unless told otherwise.
Combine Two Table Columns
Some tables have no single column in which the values never duplicate. As an example, look at the sample order items table in Figure 2-1 below.
Because there is more than one item on an order and because the same item can appear on more than one order, order numbers are repeated.
Therefore, neither column by itself can serve as the primary key of the table. The combination of an order number and an item number, however, is unique. We can therefore concatenate the two columns that form the table's primary key. One could also concatenate all three columns in the table and still ensure a unique primary key. However, the quantity column is not necessary to ensure uniqueness and therefore should not be used.
Figure 2-1: Combining 2 columns is required in order to provide a unique identifier to act as a primary key.
We now have some additional properties of a good primary key:
A concatenated primary key should be made up of the smallest number of columns necessary to ensure the uniqueness of the primary key.
Whenever possible, the columns used in a concatenated primary key should be meaningless identifiers.