Concatenated Primary Keys in 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:

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

1. the OrderNo and
2. 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.

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 "17^th Ave. SE " and another entered the same address as "SE 17^th 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:

1. The concatenation of all of the primary key columns mst be unique
2. None of the primary keys columns may contain null

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.