Part II

Antipatterns

Part I covers templates — mathematical constructs that often occur and that you should reuse.

Part II provides the opposite advice with antipatterns. An antipattern is a characterization 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 engineering complements data modeling as legacy applications often pertain to a new application. 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.