Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
This is the fifth of a series of articles on the Data Model Scorecard. The first article on the Scorecard
summarized the 10 categories, the second article focused on the correctness category, the third article
focused on the completeness category, the fourth article focused on the structure category, and this
article focuses on the abstraction category. That is, How well does the model leverage generic
structures? For more on the Scorecard, please refer to my book, Data Modeling Made Simple: A Practical
Guide for Business & IT Professionals.
How well does the model leverage generic structures?
This category gauges the use of generic data element, entity, and relationship structures. One of the
most powerful tools a data modeler has at their disposal is abstraction, the ability to increase the types
of information a design can accommodate using generic concepts. Going from Customer Location to a
more generic Location for example, allows the design to more easily handle other types of locations,
such as warehouses and distribution centers. This category ensures the correct level of abstraction is
applied on the model.
In applying this category to a model, I look for structures that appear to be under abstracted or over
abstracted:
Under abstracting. If a data model contains structures that appear to be similar in nature (i.e. similar
types of things), I would question whether abstraction would be appropriate. Factored into this equation
is the type of application we are building. A data mart for example, would rarely contain abstract
This is extract 5 of 11.
The complete document incorporating all 11 extracts is available at
Data Modelling Zone, Australia
CUSTOMER NAME
Customer name type code
Customer identifier (FK)
Customer name
Over abstracting. Likewise, if I see too much abstraction on a model, I would question whether the
flexibility abstraction can bring is worth the loss of business information on the model and the additional
cost of time and money to implement such a structure. Writing the scripts to load data into an abstract
structure or extract data out of an abstract structure is no easy task. In fact, a complete generalization
but I have found that modelers who used to be developers tend to be the shrewdest abstracters because
they understand the cost.
See Figure 2 for an example of over abstracting. The purpose of this model was limited to obtaining a
detailed understanding of Customer. Specifically, the business sponsor summarizes their requirement as
We need to get our arms around Customer. Our company has customer maintained in multiple places
with multiple definitions. We need a picture which captures a single agreed-upon view of customer.
Figure 2 Definitely over abstracting
Party
Party Role
A Party can be a person or organization, and that person or organization can play many roles. One of
these roles is Customer. Although the final Customer model might contain such an abstract structure,
jumping straight to Party and Party Role before understanding Customer mistakenly skips the painful
activity of getting a single view of customer.
As a proactive measure to ensure the correct level of abstraction, I recommend performing the following
activities:
Ask the value question. As a proactive measure to ensure the correct level of abstraction, I find
myself constantly asking the value question. That is, if a structure is abstracted, can we actually
reap the benefits some time in the not so distant future? In Figure 1 for example, the Customers
names are abstracted into the Customer Name entity. The value question might take the form of,
I see you have abstracted Customer Name. What are other types of customer names you envision in
the next 2-3 months?
Abstract after normalizing. When you normalize, you learn how the business works. This gives you a
substantial amount of information to make intelligent abstraction decisions.
Consider type of application. Some types of applications, such as data warehouses and operational
data stores, require more abstraction than other types of applications, such as data marts. A good
rule of thumb is if the application needs to be around a long time, yet its future data requirements
can not be determined, abstraction tends to be a good fit.