Excerpt from Data Modeling for the Business: A Handbook for Aligning the Business with IT using High-Level Data Models
This is the fifth in a series of articles covering the ten steps for completing the High-Level Data Model (HDM), which is also known as a subject area model or conceptual data model. In our series so far, we covered an overview of the HDM and three of the ten steps to building one: Identify Model Purpose, Identify Model Stakeholders, and Inventory Available Resources. In this article we will discuss the fourth step, Determine Type of Model. Here are all ten steps as a reference (the step in bold is the focus of this column):
- Identify model purpose
- Identify model stakeholders
- Inventory available resources
- Determine type of model
- Select approach
- Complete an audience-view HDM
- Incorporate enterprise terminology
- Signoff
- Market
- Maintain
Now that you have identified why you are building the model, the superset of individuals who will be involved in building and using it, and the actual resources we will be using to build the HDM, we can now turn our attention to determining the type of model we need.
The purpose of the model from Step 1 aids in determining the type of model to build in Step 4. The HDM needs to be one of four different variations, as shown in the table below.
| Relational | Dimensional | |
| Business | Choose when capturing how the business works and there is a need to understand a business area, design an enterprise data model, or start a new development effort. | Choose when capturing how the business is monitored and there is a need to visually capture how the business is going to play with numbers. That is, view metrics at different levels of granularity, such as by Month and Year. |
| Application | Choose when capturing how an application works and there is a need to understand an existing or proposed application, or start a new development effort. | Choose when capturing how the business is monitored through a particular application. The application allows users to view metrics at different levels of granularity, such as by Month and Year. |
The modeler will need to select one of the cells in this chart, depending on the characteristics of their model. Application and business represent focus, while relational and dimensional represent functions.
Relational Data Model
A relational data model describes the operational databases that support business processes. The scope of a high-level relational data model can range from an individual business process, such as order processing, student registration, or account billing, to an enterprise perspective of all of the concepts encompassed by the business. A sample business rule from a relational model would state, “A Customer must place one or more Orders. An Order must be placed by one and only one Customer.”
Dimensional Data Model
A dimensional model is used exclusively for reporting. A number such as Gross Sales Amount might need to be viewed at a month or year level, or at a region or country level, for example. The relationships on a high-level dimensional model represent navigation paths between concepts instead of business rules, as in the relational model. For example, a business rule on a dimensional data model would state, “I need to see Sales Amount by Customer, Month, and Product. Then I plan on going up to a Year and Brand level.”
The scope of a dimensional model is a collection of related measures that together address some business concern. For example, the metrics Number of Product Complaints and Number of Product Inquiries can be used to gauge product satisfaction.
Business Perspective
A business perspective is a high-level data model of a defined portion of the business. The scope can be limited to a department or function such as manufacturing or sales or it can be as broad as the entire enterprise or industry. The business perspective is chosen more frequently over the application perspective. Many times when we say we are creating a high-level data model, we mean the business perspective. Before embarking on any large development effort, we first need to understand the business. If an organization needs a new claims-processing system, it needs to have a common understanding of claims and related concepts. The business perspective can be created simply to understand a business area, or as a beginning to a large development effort, such as introducing third-party software into your organization.
Choose the business perspective for any of the following situations:
- Understanding a business area. The most popular usage is to gain understanding into an area of the business. It could be the way the business works today or the way the business would like to work at some time in the future. Recall Step 1.
- Designing an enterprise model. An enterprise data model must initially be designed at the concept level. Many times we recommend not getting any more detailed than the high-level data model due to the complexities and maintenance issues with hundreds of entities and thousands of data elements.
- Starting a new development effort. The business perspective is a very good place to start capturing the concepts and business rules for a new application. All future concept and logical data models can be based on this initial model.
Application Perspective
An application perspective is a high-level data model of a defined portion of a particular application. This perspective can be for either a proposed or existing application. In many cases, the application perspective is built after first understanding the business perspective and is usually a subset of its business perspective. For example, if a business perspective models order processing, the application perspective may focus on an order entry system.
Choose the application perspective for any of the following situations:
- Understanding an application. If you need to understand a current or proposed application, the application perspective should be chosen. Recall Step 1. An application might describe concepts using different terminology and enforcing different rules than the actual business area, and therefore this terminology and set of rules needs to be shown on the model.
- Starting a new development effort. Ideally, the application perspective HDM should be completed prior to logical design. This way, terminology, rules, and definitions can be agreed upon prior to detailed project analysis. It will save time, money, and unpleasant surprises further down in the software lifecycle.
In the next column, I will go into detail on Step 5, Select Approach.
