What it means
Two teams report different numbers for "active customer": one system counts any account with a recent purchase, while another counts a current contract. A data dictionary records the fields and definitions behind each report so the disagreement can be traced and corrected.
Oracle describes its database data dictionary as metadata about database contents, including schema objects and columns, while Atlan describes a broader repository of data-element definitions, types, lengths, constraints and allowed values, so the term can cover both system-generated technical metadata and human-maintained business context. List each field with a stable name and plain-English meaning, because a column named cust_status needs more than a code label.
Record data type and format, since a date stored as text may behave differently from a true date field, and specify allowed values, so that if status can be active, paused or closed the dictionary explains when each applies. State whether blank means unknown, not applicable or missing due to an error, because those cases should not silently be merged.
Identify the source system and the process that updates the field, so staff know where a value comes from, and assign an owner for definitions, since an engineer can document storage while a business owner confirms what the field means. Document units and currency, because a value of 500 without a unit can be interpreted as dollars, cents or quantity.
Record calculation logic for derived metrics, since revenue net of refunds is not the same as gross transaction value, and note when the data is refreshed so a nightly extract is not mistaken for a live customer balance. Version definitions, because a changed code mapping can make old and new reports incomparable unless the effective date is known, and when a field is deprecated show its replacement and a migration date.
For a data transfer, map fields between systems using meaning, not only similar names, since a field called account_id in two databases may identify different entities, so check uniqueness and relationships. Check how downstream reports use a field before changing it, because one altered meaning can affect several dashboards.
Include privacy and handling labels where relevant, because metadata can guide secure use although the dictionary itself is not an access control, and illustrate fields with safe sample data rather than copying sensitive values. Keep the dictionary close to the source of change, since a static spreadsheet that no one updates becomes misleading.
Automated schema discovery can capture types and constraints but may not explain business meaning, so ask subject-matter owners to review high-impact definitions, especially those used in finance or regulatory reports. A data dictionary is not necessarily a data catalogue, which often helps discover many datasets, and it is not a substitute for a business glossary, which defines concepts used across departments while the dictionary maps actual data fields to those concepts.
Link the three where available, so that a metric definition can point to the exact table and field used to calculate it. A simple dictionary can start with name, definition, type, values, source and owner, adding detail as use cases demand and tying each field to a review date, with adoption measured through fewer reconciliation disputes and faster onboarding so that teams can use data without guessing what each field represents.
In practice
Real-world examples.
Example
A customer_status field lists active, paused and closed with the rule for each value. Analysts can see that paused means a temporary hold, not cancellation. Reports then count each status consistently.
Example
A revenue field states currency, whether tax is included and when refunds are subtracted. Finance and sales can see why their totals differ. The dictionary records which version is used for board reporting.
Example
A migration team maps two similarly named account IDs after confirming they refer to the same entity. They check uniqueness and relationships before moving data. Where the meanings differ, the fields are mapped separately.
Case study
Seen in the real world.
This entirely fictional case follows Pine Analytics. Sales and finance teams used different active-customer rules. They documented source fields, refresh times and the approved business definition, then corrected a dashboard that mixed the two. The dictionary named an owner for future changes.
The case is invented. Pine Analytics then tracked coverage of its priority fields: 45 of 60 had approved definitions, or 75%, with the remainder scheduled for review. New analysts used the dictionary during onboarding, and the active-customer figure was quoted with its definition in each report. The numbers are illustrative.
Watch out
Common mistakes.
- Assuming a column name explains its business meaning.
- Leaving the dictionary unchanged after a schema or policy change.
- Treating documentation as an access-control mechanism.
Questions
People also ask.
Is a data dictionary the same as a data catalogue?
No. A catalogue helps find datasets; a dictionary describes their elements.
Who maintains it?
Technical and business owners should share responsibility for accuracy.
Can software generate one automatically?
It can capture technical metadata, but business meaning still needs review.
From the founder's library
Take it further with the book.
Build your financial confidence beyond this definition. Shihan's full-length guide, Accounting Fundamentals, takes the same plain-English approach and turns it into a complete, practical playbook for non-finance managers, business owners and students - with chapter-end quiz answers and presentation slides included.
25% off with code MMHQ25, applied at checkout. Priced in USD - checkout may show the equivalent in your local currency.
View the book and save 25%