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:

Who?      
Employee, Customer, Student, Vendor

What?       
Product, Service, Raw Material, Course


Where?
Location, Address, Country

When?      
Fiscal Period, Year, Time, Semester

Why?
Transaction, Inquiry, Order, Claim, Credit, Debit

How?
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
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.

Share

submit to reddit

About Steve Hoberman

Steve Hoberman is a world-recognized innovator and thought-leader in the field of data modeling. He has worked as a business intelligence and data management practitioner and trainer since 1990.  Steve is known for his entertaining, interactive teaching and lecture style (watch out for flying candy!) and is a popular, frequent presenter at industry conferences, both nationally and internationally. Steve is a columnist and frequent contributor to industry publications, as well as the author of Data Modeler’s Workbench and Data Modeling Made Simple. He is the founder of the Design Challenges group and inventor of the Data Model Scorecard™. Please visit his website www.stevehoberman.com to learn more about his training and consulting services, and to sign up for his Design Challenges! He can be reached at me@stevehoberman.com.

Top