Back to List

How to Use Data Dictionaries to Model and Analyze BI Requirements

Rachael Wilterdink Rachael Wilterdink  |  
May 09, 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 second technique in this blog series is Data Dictionaries.
 

What is a Data Dictionary?

The technical definition of a Data Dictionary from the International Institute of Business Analysis (IIBA®) is: “A data dictionary is used to standardize a definition of data elements and enable a common interpretation of data elements.” - BABOK® v3.0

Data Dictionaries are often confused with another business analysis technique: Glossaries. These two techniques usually overlap. The terms in a Glossary may be included in a Data Dictionary, or vice versa.

However, the audience for a Glossary is much different than that of a Data Dictionary. A Glossary is meant for business users, and the purpose is to use a common vocabulary within an organization, providing a clear understanding of each item - along with any known aliases.

A Data Dictionary, on the other hand, is meant for a technical audience. It may be used by Business Intelligence Analysts on a BI project to help understand the attributes and source of data elements, as well as their destination or possible transformations to the data.

Data Dictionaries contain a detailed list of:
 
  • Data elements
  • Their characteristics
  • Possible values

NOTE: Data Dictionaries may also be referred to as “metadata repositories”.
 

What Are the Elements of a Data Dictionary?

Data Dictionaries contain both primitive (singular) and composite (combined) elements:
 
Primitive (singular) Data elements: Composite (combined) data elements
  • Name - a unique name (which may be referenced by the composite data elements)
  • Aliases - alternate names for the data element used by various stakeholders
  • Values/Meanings - a list of acceptable values for the data element
  • Description - the definition of the data element in the context of the solution
  • Others – any other attribute that is important about the data (see sample below)
  • Sequences - required ordering of primitive data elements within the composite structure. For example, the three primitive elements of a person’s name (First Name, Middle Name & Last Name) can be put together to create a new piece of data called the Customer Name:
 
Customer Name = First Name + Middle Name + Last Name.
  • Repetitions - whether one or more data elements may be repeated multiple times (not common)
  • Optional items - may or may not occur in a particular instance of the composite element.
In our example above, there may or may not be a Prefix (Miss, Dr., etc.) in front of the name.
 
Data Dictionaries are used to:
 
  • Manage data within context of a solution
  • To standardize usage and meaning of data elements
  • Complement other data models
 

What Does a Data Dictionary Look Like?

Here is a sample from the Business Analysis Practice Guide, published by the Project Management Institute (PMI®):
 
data dictionariesExample from: “Business Analysis for Practitioners, a Practice Guide”, published by PMI®
 

Pros

Data Dictionaries are extremely useful when working on any type of project that includes data. It ensures that each piece of data is clearly identified and that its attributes are accounted for. It provides a single source of reference when re-using the same data elements in different locations (such as on multiple reports). It also makes clear the valid uses and values of the data.

Many data management systems have the ability to export a data dictionary – the functionality is essentially built into the tool, and this makes it much simpler to manage.

Data Dictionaries are heavily used in combination with other data models, removing the details of the data from the models themselves, but referencing the Data Dictionary. This keeps the models clean, and enables the use of a single source for the data definitions.
 

Cons

If the data dictionary is maintained manually, versus being systematically created, it may be difficult to manage it and keep it up-to-date. In order for it to be useful, it will need to be available and accessible in a shared location for anyone working with the same set of data.
 

Conclusion

Data dictionaries are great tools for any data project, but must be maintained in order to continue being useful. It’s also possible that data dictionaries may be misused and treated as a Glossary - which is not their intended purpose.

The previous technique was Business Rules Analysis. Next up in this blog series: Data Flow Diagrams.
 

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
How to Use Data Flow Diagrams to Model and Analyze BI Requirements
Rachael WilterdinkRachael Wilterdink  |  
May 16, 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
How To Use Business Rules Analysis to Model and Analyze BI Requirements
Rachael WilterdinkRachael Wilterdink  |  
Apr 25, 2019
Welcome to my latest blog series! This is the direct result of a request I received to speak at a local Business Intelligence (BI) meet-up. While this was originally intended for business analysts, it applies to anyone who is involved in eliciting, modeling, analyzing, or consuming requirements...
Blog Article
Top 4 Reasons to Attend WI BADD 2019
Shannon PagelsShannon Pagels  |  
Mar 21, 2019
WI BADD® (pronounced ”we bad”) is the annual Wisconsin Business Analyst Development Day held every May in Madison, Wisconsin (This year’s event will be held on May 15-16.) We are excited to again be sponsors and speakers at this event. Keep reading to learn more about the...
Blog Article
6 Hybrid Business Analyst Combinations
Rachael WilterdinkRachael Wilterdink  |  
Feb 19, 2019
There's been a lot of talk lately (and a lot of requests from our clients) for flexible hybrid roles. Our clients are looking for flexible people who can take on a variety of work to bring a project to fruition.   Here, I'm going to explore some of the more common combination roles...
Blog Article
Skipping Inspection and Adaptation (Agile Transformation Pain Point #20)
Rachael WilterdinkRachael Wilterdink  |  
Jan 31, 2019
Inspecting and adapting is one of the key parts of agile and Scrum. But over time, teams start to feel bored as if every session is the same.   If it does become boring, make sure you switch it up to keep it fresh. The Fun Retrospectives website has lots of ideas. Don’t skip this...