AUSTRALIA

May 13-14, 2015

www.datamodellingzone.com.au

How well does the model follow naming

standards?

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 6 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 follow naming standards?
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 sixth 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, the fifth
article focused on the abstraction category, and this article focuses on the standards category. That is,
How well does the model follow naming standards? 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 follow naming standards?
Correct and consistent naming standards are extremely helpful for knowledge transfer and integration.
New team members who are familiar with similar naming conventions on other projects will avoid the
time to learn a new set of naming standards. Efforts to bring together information from multiple systems
will be less painful if the data elements are named consistently across projects. This category focuses on
naming standard structure, abbreviations, and syntax.
Structure includes the components of a name. A popular standard for data element structure is one
Subject Area, zero, one, or many Modifiers, and one Class Word. A subject area is a concept that is basic
and critical to the business. A modifier qualifies this subject area and a class word is the high-level
domain for a data element. Examples of class words are Quantity, Amount, Code, and Date. Enforcing a
naming standard on Gross Sales for example, would require us to accurately identify the class word, such
as Gross Sales Amount. Enforcing a naming standard on Name would require us to accurately identify the
subject area and modifiers, such as customer last name.
This is extract 6 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
An abbreviations list should be used to name each logical and physical term. Organizations should have a
process in place for efficiently creating new abbreviations if a term cannot be found on a list. The process
should be carefully managed to prevent different abbreviations being created for the same or similar
term, and for creating the same abbreviation for completely different terms.
Syntax includes whether the term should be plural or singular, whether hyphens spaces, or camelback
(i.e. initial upper case such as CustomerLastName) should be used, and case includes whether the terms
should be all upper case, initial upper case, all lower case.
Here are a few of the red flags I look for to validate this category:
Entity names that sound more like data elements, such as Customer Type Code.
Data element names that dont follow the structure one Subject Area, zero, one, or many
Modifiers, and one Class Word such as Gross Sales and Name.
Inconsistent syntax, such as Customer Last Name, CUSTOMER FIRST NAME and
customer_middle_initial_name.
As a proactive measure to improve the naming standards on the data model, I have found the following
techniques to be very helpful:
Publish your naming standards clearly and succinctly in a format that is easily accessible.
Ideally, keep your naming standards to a maximum of a few pages and make it very easy to read
and user-friendly. Also publish it on Web sites, shared drives, and so on, to make it as easy as
possible for people to reference.
Look for opportunities to automate as much of the abbreviations process as possible. For
example, there are some software tools out there that will let you import an abbreviations list
and then automatically apply the abbreviations to data element and entity names. This can save
much time and reduce human errors.
Apply naming conventions as early as possible in the life cycle. The earlier you apply or validate
naming standards, the greater the chance the design and development teams will be more
receptive to make the changes. After there is code written against the data elements it can be
much more work to change the data element names.
Have rules about when to Grandfather older names. When I notice data element names that
dont follow standards, it is possible that different or older naming standards might have been
used. In situations like this I prefer to have consistent and wrong names rather than
inconsistency with some percentage of the names following current naming standards. For
example, I would rather have CUST_LAST_NAME appear consistently throughout the model,
instead of having CUST_LAST_NAME and CUST_LST_NAM appear within the same model.

This is extract 6 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 6 of 11.

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