The Data Modeling Addict – April 2009

This article is an excerpt from Data Modeling for the
Business: A Handbook for Aligning the Business with IT Using High-Level Data Models.

From Chapter 3 – A More Detailed Look at the High-Level Data Model
A High-Level Data Model (HDM) is used to communicate core data concepts, rules, and definitions to a business user as part of an overall application development or enterprise initiative. The
number of objects should be very small and focused on key concepts. Try to limit this model to one page, although for extremely large organizations or complex projects, the model might span two or
more pages.

The HDM is normally shown as a simple box-and-line diagram with names and definitions associated with the boxes. The HDM conveys the scope and definitions of the modeling effort, not what data will
be captured – that will come later. An example of a HDM is shown in Figure 3.6.

Figure 3.6 – Example of a HDM (mouse over image to enlarge)
In this example, we’re drilling down into the ‘Product’ subject in the VHDM to see more detail around product information. Even without understanding the notation, you can get the
sense that this diagram is showing that a product consists of one or more parts, which could be a raw material, a finished product, or a subassembly.

This is a very simple example, but you can see that by drilling into the Product subject from the VHDM, you get a more refined view of the information related to products. Figure 3.7 shows how the
objects on the VHDM and HDM map to each other.

Figure 3.7 – Product Subject on the VHDM Maps to the Product HDM (mouse over image to enlarge)

Focusing on a different business area in the VHDM such as ‘Sales’, for example, would give us something like
Figure 3.8.

Figure 3.8 – Sales HDM

In building a HDM, it’s important to choose both the focus and purpose of the model. It’s nearly impossible to model the entire enterprise at once – that would take years. A better
approach is to start with small, manageable ‘chunks’ of the business and show incremental value at each step before moving on to the next. To that end, each model should have a clear
focus. For example, you may choose to focus on a particular area of the business or a business process such as Credit Applications. Or you may choose to start with a particular application, such as
an SAP module that needs to be integrated with a legacy system. Whatever the focus, it should be clearly defined and documented before the model is built.

Equally important is to choose the purpose of the HDM, which will determine what type of model to build. A HDM may be used to support operational (transactional) systems or reporting systems. The
modeling techniques are different for each: a relational data model is used for operational systems and a dimensional data model is used for reporting.

Relational (Operational): Supports one or more applications that run the business. It captures the concepts and business rules that are needed to support applications. For example, a HDM for an
online store for a retail organization would need to capture the business concepts around product, orders, customers, credit, etc. It would also need to capture the rules supporting the application,
such as the fact that a customer can only have a single line of credit, or that an order may contain multiple products that are shipped together. An easy way to think of this is to consider that the
relational model shows how these business concepts relate to each other.

Dimensional (Reporting): Shows how concepts are used for reporting, usually in association with data warehousing and business intelligence applications. There’s a set of ‘facts’
that represents the numbers resulting from doing business – for example the number of units of a product sold last week, the amount received from the sale of the units, the cost of producing
those units, etc.  The facts are related to ‘dimensions’ – categories of information that can be used to look up characteristics about what the facts refer to.  For
example, product is a dimension that might provide the name of the product that was sold, perhaps its size and weight, the barcode associated with it, its wholesale price, where it is produced, etc.
A dimensional model enables slicing and dicing of information in many ways so that the business can analyze the data.

Share this post

Steve Hoberman

Steve Hoberman

Steve Hoberman has trained more than 10,000 people in data modeling since 1992. Steve is known for his entertaining and interactive teaching style (watch out for flying candy!), and organizations around the globe have brought Steve in to teach his Data Modeling Master Class, which is recognized as the most comprehensive data modeling course in the industry. Steve is the author of nine books on data modeling, including the bestseller Data Modeling Made Simple. Steve is also the author of the bestseller, Blockchainopoly. One of Steve’s frequent data modeling consulting assignments is to review data models using his Data Model Scorecard® technique. He is the founder of the Design Challenges group, Conference Chair of the Data Modeling Zone conferences, director of Technics Publications, and recipient of the Data Administration Management Association (DAMA) International Professional Achievement Award. He can be reached at

scroll to top
We use technologies such as cookies to understand how you use our site and to provide a better user experience. This includes personalizing content, using analytics and improving site operations. We may share your information about your use of our site with third parties in accordance with our Privacy Policy. You can change your cookie settings as described here at any time, but parts of our site may not function correctly without them. By continuing to use our site, you agree that we can save cookies on your device, unless you have disabled cookies.
I Accept