PATTERNS OF DATA MODELING- P23 ppt

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-