PATTERNS OF DATA MODELING- P26: Models provide the means for building quality software in a predictable manner. Models let developers think deeply about software and cope with large size and complexity. Developers can think abstractly before becoming enmeshed in the details of writing code. Although models are beneficial, they can be difficult to construct. That is where patterns come in. Patterns provide building blocks that help developers construct models faster and better. | 108 Chapter 8 Universal Antipatterns Antipattern example Level 1 table internid changedate changetime Level 2 table internid changedate changetime pointerl Level 3 table internid changedate changetime pointer1 pointer2 Figure Paradigm degradation Fixed three-level hierarchy. Figure shows a table from another application. I am not sure what the attributes mean. My best guess is that this table was being used for populating a spreadsheet. Antipattern example d100 d200 d300 d400 d500 d600 d705 d710 d720 d725 d740 d750 d775 d790 h200 h300 h400 h705 h710 h720 h725 h740 h750 h790 Figure Paradigm degradation Spreadsheet as a giant table. Avoid distortions of a relational database. Chapter Summary 109 Chapter Summary An antipattern is a characterization of a common software flaw. As you construct models you should be alert for antipatterns and correct them. Table summarizes universal antipatterns antipatterns to always avoid along with their exceptions and resolution. Table Summary of Universal Antipatterns Antipattern name Observation Exceptions Resolution Frequency Symmetric relationship A self relationship has the same multiplicity and roles on each end. None Promote the relationship to an entity type. Common Dead elements A model has unused elements. Acceptable in small amounts. Delete them or isolate them. Common Disguised fields Field names do not describe data. A few user-defined fields. Use meaningful names. Common Artificial hardcoded levels There is a fixed hierarchy of similar entity types. Use only with great caution. Consolidate the levels and use a tree pattern. Occasional Excessive generalization There is a deep generalization. None A db taxonomy should be at most four levels deep. Occasional Disconnected entity types A model has freestanding entity types. A few can be acceptable. Add the missing relationships. Occasional Modeling errors There is a serious conceptual flaw. None Fix the model. Occasional Multiple inheritance A