Data dictionary: what it is, what it is for, and how to create one (with an example)

Everyone who works with data has lived this scene. Someone opens a report, looks at a column called "status_cli," and asks what it means. Nobody knows for sure. One person thinks it is the customer's status in finance. Another swears it is the status of the master record. A third says that field hasn't been used since the last migration. And the meeting stalls arguing over the meaning of a field that should already have been documented. The data dictionary exists precisely so that conversation doesn't happen. It is the document that explains, in clear language, what each piece of the company's data means, where it comes from, and how it should be used.

It seems like a detail, but it is one of the most underrated artifacts of data governance. A company without a data dictionary usually has ten people with ten different understandings of the same field. And when each area understands the data its own way, the final number never adds up.

What a data dictionary is

A data dictionary is a structured document that describes the data elements of a system, database, or business domain. For each field, it records the technical name, the business name, the description of what that data represents, the type (text, number, date), the format, the allowed values, the entry rules, and the relationship with other data.

In practice, it is the glossary of your database. If the data catalog is the list of everything that exists in the company, the data dictionary is the explanation of what each thing means. It answers simple questions that, without documentation, turn into endless debate: what is the field "data_ref"? Does it accept null values? Is the CNPJ (Brazil's company registration number) stored with a mask or without? Does the field "tipo_fornecedor" only accept codes 1, 2, and 3, or is there a 4 that someone created without telling anyone?

The point is that data without a definition is not information. It is assumption. And a company that decides based on assumptions about its own data makes bad decisions with the confidence of a good one.

What a data dictionary is for in practice

The usefulness becomes clear when you look at the cost of not having one. Anyone who has taken part in a SAP project, a system migration, or an integration between areas knows that half the time is lost understanding what the data means before being able to move it. A field nobody can explain turns into weeks of investigation, meetings, and rework.

The data dictionary ends that archaeology. It standardizes understanding between business and IT, who almost always speak different languages about the same data. It speeds up the onboarding of new professionals, who understand the database by reading a document instead of asking desk to desk. It helps data quality, because when you define that "the CNPJ has 14 digits and doesn't accept null," you create a rule that can be enforced and measured. And it helps compliance, because that is where you mark which fields contain personal and sensitive data, the first practical step toward complying with the LGPD (Brazil's General Data Protection Law).

There is also the direct impact on AI. An artificial intelligence model learns from the data you give it. If nobody knows what each field means, nobody can guarantee the right data is going into the right model. The data dictionary is part of the foundation that makes AI work in the real world, because it is where the meaning of the data is recorded before it becomes algorithm training.

What a data dictionary contains

A good data dictionary goes beyond the field name. For each element, it records the technical name, the one that exists in the database, and the business name, the one the area uses day to day. It carries a clear description of what the data means, without depending on tribal knowledge. It states the type and format, whether it is text, integer, decimal, or date. It records the allowed values, essential in closed-domain fields: if the "record status" can only be active, inactive, or blocked, that has to be written down, otherwise someone invents a fourth value. It indicates whether the field is mandatory, the associated business rule, such as "the NCM (Mercosur Common Nomenclature, Brazil's tax classification code) field must be valid in the official table," and the source system. And it marks the sensitivity classification, pointing out whether that field is personal data, which connects the dictionary directly with governance and with the law.

An example makes this concrete. In the supplier master, the field "cnpj" would have the business name CNPJ, the description "supplier's registration number with the Receita Federal (Brazil's federal tax authority)," type text, format 14 digits with no mask, values numeric only, mandatory, source in the master record system. It seems obvious when it is written down. The problem is that in most companies, it is not written anywhere. It is in the head of one person who will one day leave and take the knowledge with them.

Data dictionary, data catalog, and metadata

These three terms get confused all the time, and it is worth separating them. Metadata is data about data, the broadest concept of the three. The data catalog is the browsable inventory of all the company's data assets, made so you can discover where the information is and who takes care of it. The data dictionary is deeper and more technical, focused on defining precisely the meaning, format, and rules of each field.

One way to think about it is by audience. The data catalog mainly serves the analyst and the business user who needs to find the right data and understand its context. The data dictionary serves those who need the exact definition, such as the data engineer, the database administrator, and the data steward who is going to enforce quality. In practice, the two complete each other. Many modern platforms combine catalog and dictionary in the same environment, but conceptually they answer different questions. The catalog answers "where is it and what is this at a high level." The dictionary answers "what exactly does this field mean and what rules does it follow."

Who is responsible for the data dictionary

Here lies a common mistake. Many people think the data dictionary is IT's responsibility, and pass the whole ball to the technical team. But the business meaning of a piece of data is not defined by IT. It is defined by the area that uses the data.

Whoever defines what an active customer is, is the business area, not the database. That is why the data dictionary is joint work. The data owner, normally a leader in the business area, owns the meaning and rules of that data domain. The data steward is the one who operationalizes it, keeps the document up to date, enforces the standard, and makes sure the written definition matches the reality of the database. IT contributes the technical part, the types, the formats, and the physical structure of the data. Data governance is not only technology. The system helps, but without a data owner, without a process, and without someone enforcing discipline, the dictionary becomes a document that is born out of date and that nobody trusts.

Tools to create and maintain a data dictionary

There is no single right tool. There is the one that fits your company's maturity. Many serious companies start their first data dictionary in a well-organized spreadsheet, in Excel or Google Sheets, or on a Confluence or SharePoint page. There is no shame in that. A simple document that exists and gets used is worth more than an expensive tool nobody opens.

As the operation grows, specialized platforms come in. In the world of catalogs and metadata governance, market references include Collibra, Alation, Microsoft Purview, and Atlan, which offer integrated dictionary and catalog, with search, lineage, and access control. In the world closer to data engineering, tools like dbt document the meaning and structure of data alongside the transformation code. And when we talk about master data, MDM platforms such as SAP MDG, Informatica, Stibo Systems, Reltio, Semarchy, Profisee, and Ataccama bring the definition and rules of master data into the record creation process itself, which is the ideal scenario, because the rule stops being a separate document and starts being applied at the moment the data is created.

The point is not the brand. It is discipline. The best tool in the world doesn't save a company that has no process to keep the dictionary alive.

How to create a data dictionary step by step

In practice, a data dictionary is born from orderly work. The first step is to choose the scope. Don't try to document the entire company at once, because the project dies from being too big. Start with the domain that hurts the most, usually suppliers, customers, or materials.

Then, gather the fields that actually exist in that domain, straight from the system, not from someone's memory. Sit down with the business area to write the definition of each field in clear language, with the entry rules and allowed values. Mark the fields that contain personal data, because the LGPD is going to require it. Validate the document with the people who use the data day to day. And, the step almost everyone forgets, define who keeps it up to date and how often. A data dictionary is not a project with an end, it is a living document. The day it stops being updated, it starts to lie, and a document that lies is worse than a document that doesn't exist.

How to learn and grow in your career

The good news for anyone entering the field is that the data dictionary is a concrete entry point. You don't need to be a data scientist to start. You need organization, attention to detail, and the ability to talk with the business area to extract the real meaning of each field. Many solid careers in governance started exactly there, documenting master records, understanding business rules, and becoming the person who knows the database better than anyone.

To go further, it is worth studying data management fundamentals in a structured way. The DAMA-DMBOK is the field's reference guide and covers metadata, quality, and governance in an organized manner. The CDMP certification, linked to DAMA, is the internationally recognized path for those who want to prove knowledge in data management. As I discuss in the book "Master Data Management: Fundamentos e Aplicações" (book in Portuguese), published by Editora Brasport, a clear definition of data is the foundation on which all the rest of governance stands. Without an agreed meaning, there is no quality, no integration, and no trustworthy AI.

Main questions about the data dictionary

What is the difference between a data dictionary and a data catalog? The data dictionary defines precisely the meaning, format, and rules of each field, with a technical and business focus. The data catalog is the browsable inventory of the company's data assets, made for discovery and context. The dictionary goes deep, the catalog gives the overview.

Can you build a data dictionary in Excel? Yes, and that is how most people start. A well-structured spreadsheet, with one row per field and columns for name, description, type, allowed values, and rules, already solves the problem at the beginning. A specialized tool comes in when volume grows.

Who should maintain the data dictionary? It is joint work. The data owner in the business area defines the meaning and rules, the data steward keeps the document up to date and enforces the standard, and IT handles the technical part of types and formats.

Does a data dictionary help with the LGPD? It helps directly. It is in the dictionary that you identify and mark which fields contain personal and sensitive data, which is the first practical step toward the data inventory and toward complying with the law.

How often should the data dictionary be updated? Whenever the database changes. A new field, a new rule, a new allowed value, all of it needs to go into the document. A data dictionary that isn't updated stops being a reference and becomes a source of error.

MDM Academy

Training professionals who understand data in practice is the goal of MDM Academy, the governance and master data school of 4MDG. The proposal is to translate technical concepts into real application, the way the market needs it, with a focus on master record maintenance, data quality, MDM, and governance. Those who want to move beyond the operational and grow in the data career find a structured path there, with content from people who live these projects for real.

If you want to go deeper into topics like data dictionary, catalog, quality, and governance, it is worth getting to know MDM Academy and joining the Data Club, where the community discusses the real problems of people who work with data inside companies.

Conclusion

The data dictionary is not bureaucracy. It is the decision to agree, once and for all, on what each piece of data means, so the entire company stops arguing about the obvious and starts trusting its own database. It seems simple, and it is. The hard part is not understanding the concept. The hard part is having the discipline to write it, validate it, and keep it alive.

A company that documents the meaning of its data decides faster, integrates better, makes fewer mistakes, and arrives better prepared to use AI. A company that doesn't document remains hostage to the memory of someone who, one day, will leave. The question that remains is direct. In your company, can anyone clearly explain what each field in the master record means, or does that knowledge still live only in people's heads?