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
Data Lake vs Data Warehouse: Pros and Cons
Scott HietpasScott Hietpas  |  
Jun 18, 2019
In this blog series, Scott Hietpas, a principal consultant with Skyline Technologies’ data team, responds to some common questions on data warehouses and data lakes. For a full overview on this topic, check out the original Data Lake vs Data Warehouse webinar.   There's a lot of...
Blog Article
How to Use a Glossary to Model and Analyze BI Requirements
Rachael WilterdinkRachael Wilterdink  |  
Jun 13, 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...
Blog Article
Why Did Our Team Succeed? (Habits of a Successful Agile Team)
Rachel RieckRachel Rieck  |  
Jun 06, 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 for you. Our Solutions Consulting Director shares proven strategies and tactics she learned from a pivotal agile journey that you can use to capitalize on your current...
Blog Article
How Business Analysts Can Help Maximize Project ROI
Tim MorrowTim Morrow  |  
Jun 04, 2019
In my career as a Business Analyst (BA) over the past decade or so, I've been involved with many different projects and project teams. Some have been wildly successful with a great ROI, happy stakeholders and project team…and some have not. The most successful ones have been done on...
Blog Article
How to Use Decision Modeling to Model and Analyze BI Requirements
Rachael WilterdinkRachael Wilterdink  |  
May 30, 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...