What Is a Data Dictionary? Definition, Examples, and How to Build One
A data dictionary defines every field in your data: what it means, what values are allowed, and who owns it. Here's how to build one.
A data dictionary is a centralized description of every field in a dataset: what each one means, what type it is, what values are allowed, and who owns it. It answers the question “what exactly is in this data?” for someone who did not build it.
Data dictionaries come in two forms. A passive dictionary is documentation: a spreadsheet or wiki page someone maintains by hand, which drifts the moment a field changes. An active dictionary is connected to the systems it describes, so the definition and the data cannot disagree for long.
What is a data dictionary?
A centralized description of every field in a dataset — its meaning, type, allowed values and owner.
The artifact is old and the definition is stable. Research-data guidance describes it as the reference that lets someone who did not collect the data understand and reuse it (Harvard Medical School Data Management, “Document and describe your data”, accessed 2026-09-10).
What has changed is who needs one. A dictionary used to be something a database administrator produced for a schema that changed quarterly. Increasingly it is a thing a marketing team needs for fields that dozens of people populate every week, often from outside the organization. Same artifact, very different operating conditions.
What goes in a data dictionary
A usable entry names the field, defines it in one sentence, states its data type, lists allowed values, and names an owner.
Government data-management guidance settles the required attributes, and they are short (USGS, “Data Dictionaries”, accessed 2026-09-10):
| Attribute | What it records | Why it matters |
|---|---|---|
| Field name | The exact name as it appears in the system | Two systems calling one thing different names is the join problem in miniature |
| Definition | One sentence, in business language | If it needs a paragraph, the field is doing two jobs |
| Data type | String, integer, date, boolean, enum | Determines what can be validated |
| Allowed values | The permitted set, or the format pattern | The single most useful column, and the one most often left blank |
| Required? | Whether a record can exist without it | Turns “completeness” from an opinion into a check |
| Owner | A named person or role | Someone has to be able to approve a new value |
| Source system | Where the field is created | Tells you where to fix a problem, not just where to see it |
| Example value | One real, valid instance | Resolves more ambiguity than the definition does |
The allowed-values column is where a dictionary stops being documentation and starts being useful. A definition tells a person what a field means. An allowed-value list tells a system what it may accept.
Active vs passive data dictionaries
A passive dictionary documents what the fields mean; an active one enforces it.
| Passive | Active | |
|---|---|---|
| Lives in | A spreadsheet, wiki or doc | The system that creates or validates the data |
| Updated by | A person, when they remember | The system, as part of the change |
| Drift | Begins immediately | Cannot persist — the definition is what the system checks |
| Answers | “What is this field supposed to contain?” | “Will this value be accepted?” |
| Cost of being wrong | Silent; nobody notices until a report disagrees | Loud and immediate; the entry is rejected |
Most organizations have a passive dictionary and believe they have governance. The document is usually accurate on the day it is written and quietly wrong within a quarter, because nothing forces the document and the system to agree.
That gap is not a discipline problem. It is a design problem: any artifact a human must remember to update will eventually not be updated.
A worked example, and a template you can copy
A campaign data dictionary looks like this, and the table below is a working starting point.
Here are four entries from a marketing data dictionary. Nothing is abstracted — these are the fields that actually break reporting.
| Field name | Definition | Type | Allowed values | Required | Owner | Example |
|---|---|---|---|---|---|---|
campaign_name | The human-readable name of the campaign this asset belongs to | String | Pattern: {region}_{brand}_{initiative}_{YYYYQn} | Yes | Campaign Ops | NA_acme_springlaunch_2026Q2 |
channel | The category of media the placement ran in | Enum | paid_search, paid_social, display, video, email, affiliate, ooh, organic_social | Yes | Media Ops | paid_social |
agency | The external partner that built the placement | Enum | Approved agency list, maintained by Procurement | No | Procurement | northstar_media |
launch_date | The date the placement first served | Date | YYYY-MM-DD | Yes | Campaign Ops | 2026-04-12 |
Three things about that table are worth copying.
channelis an enum, not a string. Eight values, closed. This is the difference between a channel report with eight rows and one with ninety.campaign_namehas a pattern, not a value list. Names are unique by definition, so the thing to constrain is their shape.agencyis owned by Procurement, not by marketing. Field ownership follows whoever can actually approve a new value. Getting that wrong is why so many allowed-value lists go stale.
To use it as a template, keep the columns and replace the rows. The columns are the part that transfers between organizations; the values never do.
See the standards layer: Read: what are data standards? — what turns an allowed-value list into something a system enforces.
How to build a data dictionary
Building one starts by inventorying the fields you already collect, not by designing the schema you wish you had.
- Inventory what exists. Export the field list from each system that holds campaign data. The first surprise is usually how many fields nobody can name an owner for.
- Define each field in one sentence. If the sentence needs an “and”, the field is probably two fields wearing a trenchcoat.
- Record type and allowed values. For closed sets, list them. For open ones, give the format pattern. Leave nothing as “free text” without deciding that free text is genuinely correct.
- Assign one owner per field. One, not a committee, and a person who can approve a new permitted value without escalating.
- Find the disagreements. Where two systems define the same field differently, you have found a reporting bug before it becomes an incident.
- Version it. A dictionary without a change history cannot answer why last quarter’s numbers were computed differently.
- Connect it to something that checks. Until a system reads the dictionary, it is a description of intent.
Step 5 is the one that pays for the exercise. Teams expect the inventory to be tedious and find instead that two systems have been calling different things by the same name for a year.
What an enterprise data dictionary adds
An enterprise data dictionary spans systems and teams, which means it needs an owner, a change process and enforcement, not just a document.
A single-team dictionary can survive on goodwill. An enterprise one cannot, because the people using the fields do not all report to the person maintaining the definitions, and some of them work at agencies.
Three things separate an enterprise dictionary from a large one:
- A change process. Adding a permitted value is a request with an approver, a decision and a date, not an edit.
- Scope boundaries. Which fields are enterprise-wide and which are local to one market. Attempting to standardize everything is the most reliable way to standardize nothing.
- Enforcement at the point of entry. Otherwise the dictionary describes the intent while the data records the practice, and the two drift apart at the speed of your campaign volume.
Scaling taxonomy governance across agencies, brands and global markets is one of the most common jobs enterprise teams bring us, across 55 accounts, and the dictionary is usually where that work starts — because you cannot govern fields nobody has written down.
From documentation to enforcementAllowed values applied where records are created.Explore Claravine Data StandardsData dictionary best practices
The practices that survive contact with a real organization are: one owner per field, allowed values over free text, and versioning.
- One owner per field. Shared ownership means no ownership. Name a person or a role, not a department.
- Allowed values over free text. Every free-text field is a future reconciliation project. Where a closed list is possible, use one.
- Version everything. Record what changed, when, and who approved it.
- Define in business language. A definition only a data engineer understands will not be read by the campaign manager populating the field.
- Start with the fields that feed reporting. Not the largest table — the fields that appear in the numbers leadership reads.
- Review on a schedule, not on an incident. A dictionary reviewed only after something breaks is a post-mortem template.
Template design, field configuration and scalability come up constantly in our work with enterprise teams, across 65 accounts. The recurring lesson is that dictionaries fail on maintenance rather than on design — the first version is nearly always good enough, and the third revision is where teams give up.
How a data dictionary relates to data standards and governance
A data dictionary defines the fields; a data standard enforces the values; governance decides who may change either.
“A data dictionary that lives in a spreadsheet describes what your data was supposed to be. The one worth building is the one your systems check against.” — Anthony Freeman, Principal Product Manager, Claravine The three artifacts are routinely conflated and do different jobs. DAMA International’s own framework keeps them as separate knowledge areas rather than nesting one inside another — Metadata Management “maintains ‘data about data’ to improve understanding, governance, and accessibility,” while Data Quality Management and Data Governance are enumerated alongside it, each with its own scope (DAMA International, “DAMA-DMBOK Framework”, DMBOK 2.0, accessed 2026-09-12).
The dictionary is the reference: what channel means, who owns it, what it may contain. The data standard is the enforceable form of that last part — the allowed set, applied where the value is created. Governance is the program around both: who approves a new value, how disputes are settled, how change is recorded.
A dictionary without a standard is a description. A standard without governance is a list that decays. Governance without either is a steering committee.
Vanguard’s marketing technology team described the step that comes before any of it.
“We had to come to an agreement on what the taxonomy would be for how we measure campaigns across different channels.” — Kimberly Whitehead, marketing technology manager, Vanguard
Agreement first, then documentation, then enforcement, in that order. That is why the inventory step above is worth more time than it looks like it deserves. Choosing the tooling is the last decision, not the first; data standardization tools is a separate evaluation, and data quality management is the discipline that keeps the result honest over time.
Frequently asked questions
What is a data dictionary with an example?
It is a description of every field in a dataset. Example: field campaign_name, type string, allowed values drawn from the approved campaign list, owner Campaign Ops.
How do I build a data dictionary?
Inventory the fields you already collect, define each in one sentence, record type and allowed values, assign an owner, then version it.
What is another name for a data dictionary?
Metadata repository, data catalog entry, or schema documentation, though a data catalog is broader and usually automated.
What is a master data dictionary?
One dictionary covering every system, rather than a separate dictionary per system.
Is a data dictionary the same as a database dictionary?
A database dictionary describes tables and columns inside a DBMS. A data dictionary can describe any dataset, including campaign metadata that never lands in a database at all.
What is a data dictionary in healthcare?
The same artifact applied to clinical and research fields, where allowed values are often bound to published code sets rather than locally agreed lists.
Sources
Outbound citations, named and dated:
-
Harvard Medical School Data Management, “Document and describe your data” (accessed 2026-09-10) — the canonical research-data definition and its reuse rationale.
-
USGS, “Data Dictionaries” (accessed 2026-09-10) — the required-attribute set underlying the table above.
-
DAMA International, “DAMA-DMBOK Framework” (DMBOK 2.0, accessed 2026-09-12) — metadata management, data quality and governance as distinct co-equal knowledge areas.
