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: https://www.lucidchart.com/pages/er-diagrams?a=1
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.