SQL Server 2012 : Data Design Patterns (part 4) - Recursive Pattern, Database Design Layers

6. Recursive Pattern

A recursive relationship pattern (sometimes called a self-referencing, unary, or self-join relationship) is one that relates back to itself. In reality, these relationships are quite common:

• An organizational chart represents a person reporting to another person.
• A bill of materials details how a material is constructed from other materials.

To use the standard organization chart as an example, each tuple in the employee entity represents one employee. Each employee reports to a supervisor who is also listed in the employee entity. The ReportsToID foreign key points to the supervisor's primary key.

Because EmployeeID is a primary key and ReportsToID is a foreign key, the relationship cardinality is one-to-many, as shown in Figure 8. One manager may have several direct reports, but each employee may have only one manager.

Figure 8 The reflexive, or recursive, relationship is a one-to-many relationship between two tuples of the same entity.

A bill of materials is a more complex form of the recursive pattern because a part may be built from several source parts, and the part may be used to build several parts in the next step of the manufacturing process, as illustrated in Figure 9.

Figure 9 The conceptual diagram of a many-to-many recursive relationship shows multiple cardinality at each end of the relationship.

An associative entity is required to resolve the many-to-many relationship between the component parts being used and the part being assembled. Figure 10 illustrates the BoM (bill of materials) associative entity that has two foreign keys that both point to the Part entity. The first foreign key points to the part being built. The second foreign key points to the source parts.

Figure 10 The physical implementation of the many-to-many reflexive relationship must include an associative entity to resolve the many-to-many relationship, just like the many-to-many two-entity relationship.

Part A is constructed from two parts (a Thing1 and a bolt) and is used in the assembly of two parts (Widget and SuperWidget).

Entity-Value Pairs Pattern

Entity -value pairs pattern, also known as the entity-attribute-value (EAV) pattern, sometimes called the generic pattern or property bag/property table pattern, illustrated in Figure 11, is another database design pattern often used by data modelers. This is not a popular design pattern, but in some cases it lends itself well to the problem you are attempting to solve.

Figure 11 The entity-values pairs pattern is a simple design with only four tables: class/type, attribute/column, object/item, and value. The value table stores every value for every attribute for every item — one long list.

This design can be popular when applications require dynamic attributes. Sometimes it's used as an Object Oriented (OO) DBMS physical design within an RDBMS product. It's also gaining popularity with cloud databases.

At first blush, the entity-value pairs pattern is attractive, novel, and appealing. It offers unlimited logical design alterations without any physical schema changes — the ultimate flexible extensible design.

But there are problems — many problems:

• The entity-value pairs pattern lacks data integrity — specifically, data typing. The data type is the most basic data constraint. The basic entity-value pairs pattern stores every value in a single nvarchar or sql_variant column and ignores data typing. One option not recommended is to create a value table for each data type. Although this adds data typing, it certainly complicates the code.
• It's difficult to query the entity-value pairs pattern, and there are two solutions. The most common method is hard-coding .NET code to extract and normalize the data. Another option is to code-gen a table-valued UDF or crosstab view for each class/type to extract the data and return a normalized data set. This has the advantage of being usable in normal SQL queries, but performance and inserts/updates remain difficult. Either solution defeats the dynamic goal of the pattern.
• Perhaps the greatest complaint against the entity-value pairs pattern is that it's nearly impossible to enforce referential integrity.

---

7. Database Design Layers

Every database can be visualized as three layers: domain integrity (lookup) layer, business visible layer, and supporting layer, as shown in Figure 12.

Figure 12 Visualizing the database as three layers can be useful when designing the conceptual diagram and coding the SQL DLL implementation.

While you are designing the conceptual diagram, visualizing the database as three layers can help organize the entities and clarify the design. When the database design moves into the SQL DDL implementation phase, the database design layers become critical in optimizing the primary keys for performance.

The center layer contains those entities that the client or subject-matter expert would readily recognize and understand. These are the main work tables that contain working data such as transaction, account, or contact information. When a user enters data on a daily basis, these are the tables hit by the insert and update. You can refer to this layer as the visible layer or the business entity layer.

Above the business entity layer is the domain integrity layer. This top layer has the entities used for validating foreign key values. These tables may or may not be recognizable by the subject-matter expert or a typical end user. The key point is that they are used only to maintain the list of what's legal for a foreign key, and they are rarely updated after initially populated.

Below the visible layer live the tables that are a mystery to the end user — associative tables used to materialize a many-to-many logical relationship are a perfect example of a supporting table. Like the visible layer, these tables are often heavily updated.