Kindly fill up the following to try out our sandbox experience. We will get back to you at the earliest.
What a data dictionary is, with worked examples, a template you can copy, and a clear comparison of business glossary vs data dictionary, including who owns each.
Updated on
A data dictionary is a reference guide to the information inside a dataset. It records metadata such as object names, data types, sizes, classifications and the relationships a field has with other data assets. Ask what is a data dictionary in a working data team and the practical answer is the document or module a person opens when they need to know what a column actually contains before they query it.
The purpose is to help data teams understand and use data assets correctly. It gives one central record of what the data means, where it came from, how it is used and what format it takes, which is what makes the collection, storage and use of data possible to plan, control and review.
The term itself dates to the late 1960s, when organisations first began storing large volumes of data in computer systems and needed a way to describe what they had stored. The idea has held up. A data dictionary is still a tool for defining and documenting data elements, and it is still the first thing missing when nobody can agree what a column means.
A data dictionary is one part of a wider metadata management practice. The dictionary holds the field level detail; metadata management is the discipline of keeping that detail current across every system.
A data dictionary typically includes the following components. Each one exists because somebody needed it to answer a question about a field without asking an engineer.
The fastest way to understand the format is to read one. Below is a data dictionary example for a customer table in an analytics warehouse. Each row is one field. Nothing in it is unusual, and that is the point: a useful entry is short, specific and checkable.
| Field name | Data type | Allowed values | Description | Source |
|---|---|---|---|---|
| customer_id | integer | Positive integers only | Unique identifier for a customer account | billing.customer, primary key |
| customer_status | varchar(16) | active, trial, churned, suspended | Current lifecycle state of the customer account | Nightly job derived from billing.subscription |
| signup_date | date | 2015-01-01 onwards | Date the customer account was created | billing.customer |
| country_code | char(2) | ISO 3166-1 alpha-2 codes | Country of the billing address, used for tax and reporting | billing.address |
| mrr_usd | numeric(12,2) | Zero or greater | Monthly recurring revenue for the account in US dollars, excluding tax | billing.subscription |
Two details in that example do more work than the rest. The allowed values column tells a reader that filtering on a status of "cancelled" will silently return nothing, because the value is called "churned". The source column tells them that mrr_usd excludes tax, which is the kind of definition mismatch that produces two revenue numbers in one meeting.
Data dictionaries take different shapes depending on where they live. A spreadsheet is a legitimate starting point for a single dataset. A modelling tool such as dbt holds the same fields as column descriptions and tests next to the model definition. A governance platform holds them alongside data lineage and data observability signals, so a reader can see not only what a field is but where it came from and whether it broke last night. The content is the same in all three. Only the maintenance cost differs.
Use this data dictionary template as the column set for a new dictionary. Ten columns cover everything a reader needs and stop short of the detail nobody maintains. Copy the left column as your headers and fill one row per field.
| Column | What goes in it | Example |
|---|---|---|
| Field name | The exact name as stored, not a friendly label | customer_status |
| Table or dataset | Where the field lives, fully qualified | analytics.dim_customer |
| Data type and length | The physical type as stored | varchar(16) |
| Description | One sentence a non engineer can read | Current lifecycle state of the customer account |
| Allowed values | The full list, or the valid range | active, trial, churned, suspended |
| Validation rules | The conditions a valid value must meet | Not null, and must match the allowed list |
| Source | The system or job the value comes from | Nightly job from billing.subscription |
| Relationships | Keys that link this field to others | Joins dim_customer to fct_revenue on customer_id |
| Owner | One named person or team accountable for the entry | Analytics engineering |
| Last reviewed | The date the entry was last checked | 4 August 2026 |
The last two columns are the ones teams drop first and regret. Without an owner there is nobody to correct an entry when the schema changes. Without a review date there is no way to tell a current definition from one written two migrations ago, and a reader who cannot tell stops trusting all of them.
A data dictionary is a working requirement for managing data in a database or information system. Four reasons carry most of the weight.
A data dictionary delivers four benefits that show up in day to day work: data consistency, easier analysis, transparency, and self serve access for data teams.
A data dictionary helps detect anomalies and avoid inconsistent data by recording descriptive statistics and data quality expectations alongside each field. With defined elements and validation rules in place, values stay accurate and reliable through the whole life of the dataset, which is what business decisions depend on.
By supplying context and detail about each element, a data dictionary lets analysts work with data they can trust. It acts as the reference guide that explains what every element means and how it behaves, which makes analysis both faster and more accurate.
A data dictionary sets consistent practice for how data is collected, documented and used. As a central record of metadata it gives every stakeholder the same current view of the data assets, which supports collaboration, feeds data governance and builds shared accountability.
A data dictionary is what makes self serve work inside a data team. Clear definitions, guidance and validation rules let people find and use data without waiting for support, which removes a dependency that slows down every analysis.
| Benefit | What it does |
|---|---|
| Data consistency | Helps detect anomalies and avoid inconsistent data |
| Data analysis | Makes data easier to analyse accurately |
| Data transparency | Supports collaboration and shared understanding |
| Self serve data | Lets people find and use data independently |
Together those four are why a data dictionary tends to pay for itself long before the wider governance programme around it does.
Creating a data dictionary takes four steps. Follow them in order; the fourth is the one that decides whether the first three were worth doing.
Start by listing the data elements the dictionary needs to hold. These are the fields, attributes or variables that carry information people query. Define each one with a name, a description, a data type, a length and any other property that matters. This is what makes the entries consistent enough for someone else to use.
Data elements depend on each other, and those dependencies are what a reader gets wrong first. Record the relationships: primary keys, foreign keys and any other link that connects one element to another. Written down, they stop somebody joining two tables on the wrong column.
With the elements defined and the relationships recorded, write the dictionary somewhere people will actually open. A spreadsheet or a document works, and so does a governance platform. Include every defined element, its properties and its relationships, so the result is one place to look rather than several.
A data dictionary has to change when the data changes. Update it whenever an element or a relationship is altered, so the documentation stays accurate and matches the current state of the data assets. This is the step that decides whether the dictionary is a reference or an archive.
Four practices separate a data dictionary people use from one they stop opening.
These two are confused more often than any other pair in data management, and the confusion is expensive because teams buy or build one and assume they now have both.
A business glossary defines what a term MEANS to people. A data dictionary describes what a FIELD is technically. The glossary is agreed between humans and written down. The dictionary is largely read out of the schema and then enriched. They serve different readers, they are owned by different people, and neither one substitutes for the other.
| Dimension | Business glossary | Data dictionary |
|---|---|---|
| Question it answers | What does this term mean to the business? | What is this field, technically? |
| Primary audience | Analysts, finance, product and executives, anyone reading a report | Data engineers and analysts, anyone writing a query |
| Typical owner | A business domain owner, such as finance, revenue or risk | Data engineering or analytics engineering |
| What one entry contains | Term, plain language definition, synonyms, approving owner, approval date, related terms | Field name, table, data type, length, allowed values, validation rules, source, relationships |
| Where it lives | A governance platform glossary module, or a maintained internal wiki | The database catalog, a modelling tool such as dbt, a governance platform, or a spreadsheet |
| How it is created | Negotiated between people, then approved and published | Extracted from the schema, then enriched by hand |
| What breaks without it | Two reports quote different numbers for the same term and nobody can say which is right | Someone joins on the wrong column, or filters on a value that does not exist |
Take one concept, "active customer", and write it in each artefact.
The business glossary entry reads: Active customer. A customer who has completed at least one paid transaction in the previous 90 days. Excludes trial accounts and accounts suspended for non payment. Owner: Head of Revenue Operations. Approved 12 March 2026. Related terms: churned customer, trial customer. Used in: the monthly revenue pack and board reporting.
The data dictionary entry for the same concept reads: customer_status. Field in analytics.dim_customer. Type varchar(16). Allowed values active, trial, churned, suspended. Populated by a nightly job from billing.subscription. Not null. Owner: analytics engineering. Last reviewed 4 August 2026.
Neither entry is sufficient on its own. The glossary tells you that an active customer must have paid in the last 90 days, but not which column to filter. The dictionary tells you the column holds the value "active", but not that a trial account is deliberately excluded from the definition. A reader with only the dictionary will happily count trials as customers and be wrong by whatever the trial volume is.
The glossary belongs to the business domain. Whoever is accountable for the number in the board pack should be accountable for the definition behind it, which usually means finance, revenue operations or risk rather than the data team. The dictionary belongs to data or analytics engineering, because its content follows the schema and the schema is theirs.
They connect at the field. A glossary term should name the field or fields that implement it, and a dictionary entry should name the glossary term it serves. That single link is what lets a reader move from "what does active customer mean" to "which column do I filter" without asking anyone. Where the link is missing, the two artefacts drift apart and a definition change quietly stops matching the data. Decube built its business glossary module to hold that link, so an approved term points at the fields that implement it.
Readers usually conflate three things, not two. The data catalog is the layer above both: it inventories the assets across every source and reads the dictionaries and glossaries underneath to build context. A glossary is meaning, a dictionary is field detail, a catalog is the index over everything. If you want all three set side by side, we compare business glossary, data catalog and data dictionary in a dedicated article.
A data catalog indexes, inventories and classifies data assets across many sources. It builds context by reading the data dictionaries and business glossaries underneath it for technical, business and operational metadata, and it usually adds lineage, observability and collaboration features on top.
A data dictionary sits inside that picture as the field level detail. The two are not alternatives, and choosing between them is the wrong question: the catalog is how you find the dataset, the dictionary is how you understand the columns once you have found it.
| Comparison | Data catalog | Data dictionary |
|---|---|---|
| Definition | Indexes, inventories and classifies data assets across many sources | Describes the individual data elements inside a dataset |
| Features | Search, data lineage, data observability, collaboration | Descriptive statistics, validation rules, data quality expectations |
| How they relate | Reads dictionaries and glossaries to build context | Sits inside the catalog as the field level detail |
For the longer version of this comparison, including how to decide which one to build first, read our data catalog vs data dictionary article.
Decube holds the dictionary, the glossary and the catalog in one place, which is what stops the link between a definition and a field from being maintained by hand. The business glossary module manages the definitions of key metrics and ties each approved term to the fields that implement it, while Decube data governance covers the field level detail, lineage and quality signals underneath. If you want to see how the two link in practice, request a demo.
A data dictionary is the record of what your fields are: their names, types, allowed values, sources, relationships and rules. Kept current, it gives a team consistency, faster analysis, transparency and self serve access to data, and it is usually the cheapest piece of data governance to start.
Build it in four steps: define the elements, record the relationships, document them in one place, and update them on a schedule with a named owner. Then pair it with a business glossary, because a dictionary without a glossary tells you what a column holds but not what the business means by it, and a glossary without a dictionary tells you the meaning but not where to find it.
A data dictionary is a reference guide to the information inside a dataset. It records metadata about each data element, including its name, description, data type, length, allowed values, validation rules, source and relationships with other elements. Its purpose is to let anyone understand what a field contains before they query or report on it.
The data dictionary meaning is straightforward: it is the list of every field in your data, with a short explanation of each one. It says what the field is called, what kind of value it holds, which values are valid and where the value came from. It does not say what the business means by a term, which is the job of a business glossary.
A data dictionary example for a customer table would list one row per field. For instance: customer_status, type varchar(16), allowed values active, trial, churned and suspended, described as the current lifecycle state of the customer account, sourced from a nightly job derived from billing.subscription. Each row is short, specific and checkable.
A data dictionary template needs ten columns: field name, table or dataset, data type and length, description, allowed values, validation rules, source, relationships, owner and last reviewed date. The last two are the ones teams drop first and regret, because without an owner nobody corrects an entry after a schema change and without a review date nobody can tell a current definition from an old one.
A business glossary defines what a term means to the business, in plain language agreed and approved by a business owner. A data dictionary describes what a field is technically: its name, type, allowed values, source and relationships. The glossary serves report readers, the dictionary serves people writing queries. They connect at the field, because a glossary term should name the field that implements it.
No. A data dictionary can tell you that the field customer_status holds the value active, but not that the business defines an active customer as one who paid in the previous 90 days and excludes trial accounts. Someone working from the dictionary alone will count trials as customers. The two artefacts answer different questions and both are needed.
No. A data catalog indexes, inventories and classifies data assets across many sources and adds lineage, observability and collaboration on top. A data dictionary describes the individual fields inside a dataset. The catalog is how you find the dataset, the dictionary is how you understand its columns once you have found it.
Data dictionaries are usually owned by data engineering or analytics engineering, because their content follows the schema. Business glossaries are owned by the business domain instead, such as finance or revenue operations. Whichever team owns it, each entry should name one accountable owner and carry the date it was last reviewed.
Kamus data is the Indonesian term for a data dictionary and it refers to the same thing: the record of every field in a dataset with its name, type, allowed values, source and rules. The components and the template described on this page apply without change.
The section above argued that a glossary and a dictionary only hold together when an approved term names the field that implements it. This 48 second walkthrough starts from the same failure this article describes, teams using one term for different things and different terms for the same thing, then shows the glossary in Decube: how glossaries, categories and terms are structured, how data owners, stewards and business owners are assigned so every definition is accountable to someone, how a term is enriched with calculation logic and other custom attributes, and how a term is linked to the data assets that carry it. Watch it to see what the link between a definition and a field looks like when it is held in one place instead of maintained by hand.
First step to AI Readiness
Table of Contents
Sneak peek from the data world.
Bring lineage, quality, governance, and AI together in one platform—so your teams and AI agents can act with confidence.
_For%20light%20backgrounds.svg)
.svg){kind=small}
.webp)