AUSTRALIA

May 13-14, 2015

www.datamodellingzone.com.au

How well does the model leverage

generic structures?

Join us at Data Modelling Zone, Australia

13-14 May, 2015
Sydney

About Data Modelling Zone, Australia

The world is quickly changing with respect to how we view and analyse data, and along with these
changes, data modelling plays a major role. The principles of data modelling need to stay firm, but our
application of them needs refinement as technology advances. The sessions at Data Modelling Zone are
a reflection of where the data modelling industry is, and where it is heading. Join us on 13-14 May, 2015
in Sydney for inspiring sessions and thought-provoking case studies, both fundamental and advanced, by
local and international industry leaders.
Register to attend Data Modelling Zone, Australia
Data Modelling Zone is being brought to Australia by Analytics8.
About Analytics8
At Analytics8, we provide objective, independent, best-of-breed Business Intelligence and Data
Warehousing Services, in order to lead organisations to sustained and measurable success by leveraging
our experience, expertise and partnering approach. We are Australias leading Data Vault data modelling
training and implementation consultancy. We show you how to make the most of your data to know and
understand your markets, your customers and your business.

This is extract 5 of 11.

The complete document incorporating all 11 extracts is available at
Data Modelling Zone, Australia

Join us at Data Modelling Zone, Australia

13-14 May, 2015
Sydney
How well does the model leverage generic structures?
An applications flexibility and data quality depend quite a bit on the underlying data model. In other
words, a good data model can lead to a good application and a bad data model can lead to a bad
application. Therefore we need an objective way of measuring what is good or bad about the model.
After reviewing hundreds of data models, I formalized the criteria I have been using into what I call the
Data Model Scorecard.
The Scorecard contains 10 categories:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

How well does the model capture the requirements?

How complete is the model?
How structurally sound is the model?
How well does the model leverage generic structures?
How well does the model follow naming standards?
How well has the model been arranged for readability?
How good are the definitions?
How well has real world context been incorporated into the model?
How consistent is the model with the enterprise?
How well does the metadata match the data?

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

Join us at Data Modelling Zone, Australia

13-14 May, 2015
Sydney
structures while a data warehouse which requires flexibility and longevity would be a good candidate for
abstraction.
See Figure 1 for an example of under abstracting. If this structure is part of a data warehouse model
which requires longevity in the face of ever changing requirements, we would question whether the
Customers phone numbers should have been abstracted. Removing the phone number data elements
and creating a separate Customer Phone structure where phone numbers are stored as values instead of
elements will provide more flexibility.
Figure 1 Possibly under abstracting
CUSTOMER
Customer identifier
Customer primary phone number
Customer secondary phone number
etc

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

This is extract 5 of 11.

The complete document incorporating all 11 extracts is available at
Data Modelling Zone, Australia

Join us at Data Modelling Zone, Australia

13-14 May, 2015
Sydney

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.

This is extract 5 of 11.

The complete document incorporating all 11 extracts is available at
Data Modelling Zone, Australia

Join us at Data Modelling Zone, Australia

13-14 May, 2015
Sydney
About Steve Hoberman
Steve Hoberman is the most requested data modelling instructor in the world. In his consulting and
teaching, he focuses on templates, tools, and guidelines to reap the benefits of data modelling with
minimal investment. He taught his first data modelling class in 1992 and has educated more than 10,000
people about data modelling and business intelligence techniques since then, spanning every continent
except Africa and Antarctica. Steve is known for his entertaining, interactive teaching and lecture style
(watch out for flying candy!), and organizations around the globe have brought Steve in to teach his Data
Modelling Master Class, which is recognized as the most comprehensive data modelling course in the
industry. Steve is the author of six books on data modelling, including the bestseller Data Modelling
Made Simple. He is the founder of the Design Challenges group, inventor of the Data Model Scorecard,
and the recipient of the 2012 DAMA International Professional Achievement Award.

This is extract 5 of 11.

The complete document incorporating all 11 extracts is available at
Data Modelling Zone, Australia