SQL Server 2012 : Data Design Patterns (part 2) - Many-to-Many Pattern

3. Many-to-Many Pattern

In a many-to-many relationship, both sides may relate to multiple tuples (rows) on the other side of the relationship. The many-to-many relationship is common in reality, as shown in the following examples:

• The classic example is members and groups. A member may belong to multiple groups, and a group may have multiple members.
• In a typical sales system, an order may contain multiple products, and each product may be sold on multiple orders.
• In the AdventureWorks2012 sample database, a product may qualify for several special offers, and each special offer may have several qualified products.

In a conceptual diagram, the many-to-many relationship can be diagramed by signifying multiple cardinality at each side of the relationship, as shown in Figure 3.

Figure 3 The many-to-many logical model shows multiple tuples on both ends of the relationship.

Many-to-many relationships are nearly always optional. For example, the many products-to-many special offers relationship is optional because the product and the special offer are each valid without the other.

The one-to-one and the one-to-many relationship can typically be constructed from items within an organization that users can describe and understand. That's not always the case with many-to-many relationships.

To implement a many-to-many relationship in SQL DDL, a third table, called an associative table (sometimes called a junction table) is used, which artificially creates two one-to-many relationships between the two entities (see Figure 4).

Figure 4 The many-to-many implementation adds an associative table to create artificial one-to-many relationships for both tables.

Figure 5 shows the associative entity with data to illustrate how it has a foreign key to each of the two many-to-many primary entities. This enables each primary entity to assume a one-to-many relationship with the other entity.

Figure 5 In the associative entity (SpecialOfferProduct), each special offer can be represented multiple times, which creates an artificial one-specialoffer-to-many-product relationship. Likewise, each product can be listed multiple times in the associative entity, creating a one-product-to-many-special relationship.

In some cases the subject-matter experts can readily recognize the associated table:

• In the case of the many orders to many products example, the associative entity is the order details entity.
• A class may have many students, and each student may attend many classes. The associative entity would be recognized as the registration entity.

In other cases an organization might understand that the relationship is a many-to-many relationship, but there's no term to describe the relationship. In this case, the associative entity is still required to resolve the many-to-many relationship — just don't discuss it with the subject-matter experts.

Typically, additional facts and attributes describe the many-to-many relationship. These attributes belong in the associative entity. For example:

• In the case of the many orders to many products example, the associative entity (order details entity) would include the quantity and sales price attributes.
• In the members and groups example, the member_groups associative entity might include the datejoined and status attributes.

When designing attributes for associative entities, it's extremely critical that every attribute actually describe only the many-to-many relationship and not one of the primary entities. For example, including a product name describes the product entity and not the many orders to many products relationship.