Back to List

How to Use Data Modeling to Model and Analyze BI Requirements

Rachael Wilterdink Rachael Wilterdink  |  
May 23, 2019
 
If you’re involved in eliciting, modeling, analyzing, or consuming requirements for BI projects, this post is for you. Over the next several months, we will be releasing 10 Techniques for Business Analysts (BAs) to model and analyze Business Intelligence (BI) requirements on our blog. The fourth technique in my blog series is Data Modeling.
 

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)

 

Unified Modeling Language (UML) - Class Diagram

unified modeling language diagram
Example from: “Business Analysis for Practitioners, a Practice Guide”, published by PMI®
 

Pros

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.
 

Cons

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.
 

Conclusion

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.
 
Next in my blog series: Decision Modeling.

 

Free Agile Resources


References:
“IIBA Home.” IIBA | International Institute of Business Analysis, www.iiba.org/.
“PMI.” PMI | Project Management Institute, www.pmi.org/.
 
Business AnalysisBusiness Intelligence

 

Love our Blogs?

Sign up to get notified of new Skyline posts.

 


Related Content


Blog Article
Pre-Project Components That Can Impact User Adoption
Cory SchmittCory Schmitt  |  
Sep 12, 2019
Does the following situation sound familiar?   You were on a project that rolled out a new application to the organization. You and the team spent many long days (and some nights) building the new application. The team worked hard, and you came in on-time and on-budget. As part of the...
Blog Article
Using Human Hard-Wiring to Create a Strong Agile Experience
Rachel RieckRachel Rieck  |  
Aug 22, 2019
If you have experience on agile teams and are looking to tweak a few things or try something different, then this Trifecta of Greatness blog series is right for you. For more background on the strategies and tactics our Solutions Consulting Director learned from a pivotal agile journey, be sure...
Blog Article
How to Use Prototyping to Model and Analyze BI Requirements
Rachael WilterdinkRachael Wilterdink  |  
Aug 15, 2019
If you’re involved in eliciting, modeling, analyzing, or consuming requirements for Business Intelligence projects, this post is for you. This is the tenth and final technique in our blog series on 10 Techniques for Business Analysts (BAs) to model and analyze Business Intelligence (BI...
Blog Article
Decision Rights, Team Lead Communication, and Smackdowns (Habits of a Successful Agile Team)
Rachel RieckRachel Rieck  |  
Aug 08, 2019
If you have experience on agile teams and are looking to tweak a few things or try something different, then this blog series is right for you. This is the fifth blog in the Trifecta of Greatness series and highlights a few last habits and techniques. For more background on the strategies and...
Blog Article
How to Use Process Modeling to Model and Analyze BI Requirements
Rachael WilterdinkRachael Wilterdink  |  
Aug 01, 2019
If you’re involved in eliciting, modeling, analyzing, or consuming requirements for BI projects, this post is for you. This is the ninth technique in our blog series on 10 Techniques for Business Analysts (BAs) to model and analyze Business Intelligence (BI) requirements.   What is...