91 7 Summary of Templates Table 7.1 through Table 7.5 summarize the mathematical templates. Template Synopsis UML diagram Use when Frequency Hardcoded tree Specifies a type sequence, one for each level of the hierarchy. The levels in a tree are known and ordered. Seldom Simple tree Treats all nodes the same. A tree concerns only data struc- ture. Common Structured tree Differentiates leaf nodes from branch nodes. Branch nodes and leaf nodes differ. Common Overlap- ping tree Permits a node to belong to mul- tiple trees. A node can belong to more than one tree. Occasional Tree chang- ing over time Stores variants of a tree over time. There is history to record. Occasional Degenerate node and edge Groups a parent with its children. There is data for the parent–child grouping. Rare . . . Table 7.1 Tree Templates 92 Chapter 7 / Summary of Templates Template Synopsis UML diagram Use when Frequency Simple DG Treats all nodes the same. Edges are unim- portant; nodes have the same kind of data. The DG is acyclic. Occasional Structured DG Differentiates leaf nodes from branch nodes. Edges are unim- portant; branch nodes and leaf nodes have differ- ent data. The DG is acyclic. Occasional Node–edge DG Treats nodes and edges as peers. Nodes and edges can both have data; there can be multiple edges between a pair of nodes. Common Connection DG Promotes a node–edge connection to an entity type. Connections have data. Occasional Simple DG changing over time Stores variants of a DG over time. There is history to record; edges are unimportant. The DG is acyclic. Seldom Node–edge DG chang- ing over time Stores variants of a DG over time. There is history to record; edges are important. Occasional Table 7.2 Directed Graph Templates 93 Template Synopsis UML diagram Use when Frequency Node–edge UDG Treats nodes and edges as peers. No edge con- nects to the same node. Occasional Connection UDG Promotes a node–edge con- nection to an entity type. Connections have data or an edge connects to the same node. Occasional UDG chang- ing over time Stores variants of a UDG over time. There is history to record. Seldom Table 7.3 Undirected Graph Templates Template Synopsis UML diagram Use when Frequency Item description Relates data and metadata in the same model. The same model relates data and metadata. Frequent Homomor- phism Expresses an analogy between two item descrip- tion templates. Item description templates are involved in an analogy. Occasional Table 7.4 Item Description Templates Template Synopsis UML diagram Use when Frequency Star schema Represents data as facts that are bound to dimen- sions. There must be a flexible struc- ture for query- ing data. Occasional (frequent for data warehouse) Table 7.5 Star Schema Template 95 Part II Antipatterns Chapter 8 Universal Antipatterns 97 Chapter 9 Non–Data–Warehouse Antipatterns 111 Part I covers templates — mathematical constructs that often occur and that you should re- use. Part II provides the opposite advice with antipatterns. An antipattern is a characteriza- tion of a common software flaw. When you find an antipattern, substitute the correction. Most patterns are good ideas that can be reapplied to new situations. In contrast, antipatterns look at what can go wrong and offer fixes for the problems. The literature focuses on anti- patterns for programming code, but antipatterns also apply to data models. Many of the examples in these chapters are from my consulting experiences with data modeling and reverse engineering (inspecting the databases of others). Reverse engineering is the process of starting with implementation artifacts and deducing the intent. Reverse en- gineering complements data modeling as legacy applications often pertain to a new applica- tion. A legacy application might be a source of ideas, a source of data for a new database, or something with which to integrate. Chapter 8 presents antipatterns that you should always avoid. Chapter 9 presents antipatterns to avoid for non–data–warehouse applications. These antipatterns simplify reading but compromise the ability of database structure to enforce quality. Hence, these antipatterns are acceptable for data warehouses, but you should avoid them otherwise. A data warehouse is skewed towards reading and its database structure does not enforce data quality—that is the responsibility of the loading programs. Data warehouses forego enforcement of data quality in order to simplify database structure so that it is easier to write queries. A simple structure also reduces the difficulty of integrating disparate data sources. Many of antipatterns are relatively simple so we just present the UML notation. For the more complex antipatterns, we use both UML and IDEF1X notations. 97 8 Universal Antipatterns An antipattern is a characterization of a common software flaw. When you find an antipat- tern, substitute the correction. Universal antipatterns are antipatterns that you should avoid for all applications. 8.1 Symmetric Relationship Antipattern 8.1.1 Observation An entity type has a self relationship with the same multiplicity and role names on each end. Typically this is a many-to-many self relationship. Symmetric relationships can be trouble- some for programming and are always troublesome for relational databases. 8.1.2 Exceptions There are no exceptions for relational database designs. Avoid symmetric relationships. 8.1.3 Resolution Promote the relationship to an entity type in its own right. The improved model not only re- solves the symmetry but is often more expressive. 8.1.4 Examples Consider Figure 8.1a and Figure 8.2a. RelatedContract involves two contracts but the sym- metry is troublesome. If each pairing is entered once, it is not clear which contract should be first and which is second. If each pairing is entered twice, the amount of storage increases and any change requires double update. If more than two contracts are related, the situation is messier yet (for three contracts that are double stored: C1-C2, C2-C1, C1-C3, C3-C1, C2- . contrast, antipatterns look at what can go wrong and offer fixes for the problems. The literature focuses on anti- patterns for programming code, but antipatterns also apply to data models. Many of the. en- gineering complements data modeling as legacy applications often pertain to a new applica- tion. A legacy application might be a source of ideas, a source of data for a new database, or something. antipatterns that you should always avoid. Chapter 9 presents antipatterns to avoid for non data warehouse applications. These antipatterns simplify reading but compromise the ability of database