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:
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
motorcycle.
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.
