Design is all about building
something new by combining existing concepts or items using patterns.
The same is true for database design. The building blocks are tables,
rows, and columns, and the patterns are one-to-many, many-to-many, and
others. This section explains these patterns.
When the entities — nouns and verbs — are
organized, the next step is to determine the relationships among the
objects. Each relationship connects two entities using their primary
and foreign keys.
Clients or business analysts should describe the common relationships between the objects using terms such as includes, has, or contains.
For example, a customer may place (has) many orders. An order may
include (contains) many items. An item may be on many orders.
Based on these relationship descriptions, you can choose the best data design pattern.
1. One-to-Many Pattern
By far the most common relationship is
a one-to-many relationship; this is the classic parent-child
relationship. Several tuples (rows) in the secondary entity relate to a
single tuple in the primary entity. The relationship is between the
primary entity's primary key and the secondary entity's foreign key, as
illustrated in the following examples:
- In the AdventureWorks2012 sample database, each productsubcategory
may contain several products. Each product belongs to only one
productsubcategory, so the relationship is modeled as one
productsubcategory relating to multiple products. The relationship is
made between the ProductSubCategories primary key and the Products entity's ProductSubcategoryID foreign key, as diagrammed in Figure 1. Each Product's foreign key attribute contains a copy of its SubCategories's primary key.
- Each customer may place multiple orders. Although each order has its own unique SalesOrderID primary key, the SalesOrder Header entity also has a foreign key attribute that contains the CustomerID of the customer who placed the order. The SalesOrderHeader entity may have several tuples with the same CustomerID that defines the relationship as one-to-many.
2. One-to-One Pattern
At the conceptual diagram layer,
one-to-one relationships are quite rare. Typically, one-to-one
relationships are used in the SQL physical layer to partition the data
for some performance or security reason.
One-to-one relationships connect two entities
with primary keys at both entities. Because a primary key must be
unique, each side of the relationship is restricted to one tuple.
For example, a Contact
entity can store general information about various contacts at a
company. However, additional employee information may be stored in a
separate entity, as shown in Figure 2.
Although security can be applied on a per-attribute basis, or a view
can project selected attributes, many organizations choose to model
sensitive information as two one-to-one entities.
