The Data Modeling Addict – July 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

For more background information on the high-level data model, please see my April column

From Chapter 3 – Components of a High-Level Data Model (HDM)
Now let’s take a look at the parts of a high-level data model (HDM) and discuss some of the guidelines and techniques for building one. While we’ll stress throughout the book that
these guidelines are not strict rules, and that they can and should be customized to fit your particular audience, there are general principles that apply to these models that we, and others
we’ve surveyed in the industry, have found to work effectively in practice.  The objects that are included in a HDM are described below.

Concept: A concept is represented as a noun that has meaning to the business. In the HDM, we create an inventory of the words, terms, and concepts used by the
business with clear definitions for each. In creating this inventory, it is helpful to think of Who, What, Where, When, Why, and How? For example:

Employee, Customer, Student, Vendor

Product, Service, Raw Material, Course

Location, Address, Country

Fiscal Period, Year, Time, Semester

Transaction, Inquiry, Order, Claim, Credit, Debit

Invoice, Contract, Agreement, Document

A concept is usually shown on the diagram as a box, with its name at the top or center of the box. The reason for this is that HDMs are normally created by data architects who use the HDM to develop
the logical data model.  The logical data model uses a box to represent an entity.

We’ll talk more about notation in Chapter 6, but for now, we’ll use the commonly used box style, as shown in Figure 3.11.

Figure 3.11: Customer Concept

Supertype/Subtype: Supertypes and Subtypes are a mechanism for grouping objects with similar (but not identical) characteristics. The supertype is the
‘master’ and contains the attributes and relationships that are shared by all of the subtypes.  A subtype is a variation of the supertype and may have some of its own distinct
characteristics. For example, let’s take a supertype of vehicle, defined as a means of carrying or transporting something.  Subtypes would include automobile, airplane, train, and

In the customer example, we determined that a customer can be either an individual or an organization. Different information might be stored about a corporation (e.g. corporate tax id) than for an
individual (e.g. gender), and different rules might apply to each. But they are both still customers and there are certain characteristics and rules that apply to all customers. We represent this by
creating a supertype concept named ‘Customer’ and two individual subtypes of ‘Corporation’ and ‘Individual’, as shown in Figure 3.12.

Figure 3.12: Using a Supertype/Subtype Relationship

Without any explanation of the notation, you can probably figure out that this diagram is showing that a customer can be a corporation or an individual.  That’s the goal of a good
high-level data model—it should be intuitive to a non-technical person with little or no explanation. The half-moon symbol in the center of the graph with an ‘X’ in its center is
one way to represent a supertype/subtype relationship:


The ‘X’ in the middle indicates that the subtype is eXclusive, which means that a customer may be a corporation OR an individual, but not both.

Relationship: While concepts show the NOUNS of a business, relationships are the VERBS. Relationship verbs reflect the business rules of an organization for
operational databases. For reporting databases, they show the navigation paths for queries. Again, it’s probably easiest to explain this by using some examples. Below are some sample business
rule relationships that might be expressed in a data model:

  • An employee can work for more than one department.
  • A department may have more than one employee.
  • A customer can have more than one account.
  • Sales are reported monthly.

These may seem like very simple and obvious rules to you. But remember, the definition of what a customer is might have seemed obvious, too, before we started delving deeper and asking different
departments and individuals how they used the term. And, like the definitions of concepts/nouns, the definitions of these relationships/verbs are critical to ensuring that the database systems that
run an organization work correctly and efficiently.

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