May 23, 2019

How to Use Data Modeling to Model and Analyze BI Requirements

Post by: Rachael Wilterdink

If you’re involved in eliciting, modeling, analyzing, or consuming requirements for BI projects, this post is for you.

What is Data Modeling?

The official definition of data modeling, according to the International Institute of Business Analysis (IIBA®) is:

A data model describes the entities, classes, or data objects relevant to a domain, the attributes that are used to describe them, and the relationships among them to provide a common set of semantics for analysis and implementation.” – BABOK® v3.0

Data models depict data entities, their attributes, and relationships. They are typically supported by text descriptions (such as a Data Dictionary). They visually represent:

  • People – the people who need data or provide it
  • Places – the locations where data is stored or exists
  • Things – the objects or entities that are involved with the data
  • Transactions – what happens between the people, places, or things
  • Associated attributes – the attributes that describe the data elements
  • Relationships between them – the relationships between the data, and how many are allowed

There Are 3 Different Types of Data Models

  • Conceptual: Shows how the business perceives its information.
  • Logical: an abstraction of the conceptual model plus rules of normalization for managing integrity (often associated with design).
  • Physical: used for implementation to describe how a database is physically organized.

The type of model you use will depend on what type of project you are doing. The primary focus of this blog is the first option – conceptual. However, if you are working on a brand-new database development project, you may use logical or physical models. While building these models, they may look similar to a database schema, but they are not necessarily the same thing. It’s likely that your diagrams would be used as an input to a Business Intelligence Analyst or DBA to use a reference when doing their database design.

What Are the Elements of Data Modeling?

Entities or Classes represent:

  • Physical – people, objects, entities, things
  • Organizational – business units, companies, other organizations
  • Abstract – unclear concepts
  • Events – things that take place

Attributes may include:

  • Name – the name of the element
  • Values/meanings – possible values or meanings
  • Description – a description of the element
  • Relationships / associations – how the elements are related to one another, and the number of associations allowed
  • Metadata (data about data) – more attributes about the data element

What Are the Different Data Modeling Notations?

There are two primary notations that are commonly used. They are Crow’s Foot Notation, and UML (Unified Modeling Language).

Crow’s Foot Notation – Entity Relationship Diagram (ERD)

Example from:

Unified Modeling Language (UML) – Class Diagram

Example from: “Business Analysis for Practitioners, a Practice Guide”, published by PMI


This is a fantastic diagram if you have to deal with data and need to understand the relationships between them. If you’re on a Business Intelligence project, it’s highly likely that you will end up using or seeing one form of this model type. Both notations are common and generally well-understood by data professionals.

While not necessarily representative of a physical database design, it helps make sense of the different entities or classes you are dealing with, and it helps to organize them in a logical manner.

These diagrams are extremely useful when preparing requirements for any data project, and they can help you identify redundancies or gaps in the data.

This technique helps you understand the business rules that underlie the data. It will also help you ensure you are properly applying those business rules to your systems.


While these models are extremely useful to technical folks, a business person will take one look and their eyes will glaze over. They will have virtually no idea what they’re looking at, or what it means to them or their project.

Because there are two widely used notations, you really need to understand both and be able to use either notation almost interchangeably. The notations are also not the same and have some slight differences you will need to understand. The notations are also not necessarily easy to learn (although there are some nice video tutorials on YouTube). You need to add a few new words to your vocabulary, too, such as “cardinality” (the number of relationships or associations allowed).

People may also get confused thinking that this is a database design, given how closely they resemble database schema diagrams. While they could mirror a database design, they are not meant to replace separate database design.

Like many of the other data models, this model may require supplementary documentation such as a Data Dictionary.


These models are terribly useful to data professionals, but you must know both and learn a few new terms. This is not a model you would want to put in front of a business user.

“IIBA Home.” IIBA | International Institute of Business
“PMI.” PMI | Project Management

Relevant Insights

Are You Falling into the Cloud Conversation Gap?

Most conversations about migrating services to the cloud focus on migration of application workloads and data. The vision is often...

How Aggregation Tables Improve Performance for Power BI Reports

In this blog, Marcus Radue, Solution Architect, offers high-level guidance in the advantages of aggregation tables in Power BI. For a...

Getting Started with Azure DevOps – Views

Like most Microsoft products, there are many ways to look at or perform the same activities. Azure DevOps is no...