A data dictionary is a centralized document or system that defines every data field in your organization — specifying each field's name, data type, allowed values, business meaning, and ownership, so that anyone who touches the data understands exactly what each field means and how it should be used.
Without a data dictionary, the same field means different things to different people. Is "active customer" someone who bought in the last 30 days? 90 days? Ever? When that definition lives only in someone's head, every report built on it is built on an assumption — and different teams make different assumptions.
What a Data Dictionary Contains
A data dictionary typically records the following for each field:
Field name: The technical name as it appears in the database or file ("customer_status", not "Status").
Business name: The human-readable label used in reports and conversations ("Customer Status").
See exactly what's wrong with your data — try Sohovi free — try Sohovi free.
Description: A plain-English definition of what the field means and how it's used.
Data type: String, integer, date, boolean, etc.
Allowed values: For categorical fields, the approved list. For numeric fields, the acceptable range.
Owner: Who is responsible for maintaining the accuracy of this field.
Sohovi scores your dataset against your own accuracy standards and highlights the columns and rows where values fall outside expected ranges.
Source system: Where the data originates.
Last updated: When the definition was last verified.
Why a Data Dictionary Matters for Data Quality
A data dictionary is the reference layer that makes data quality rules meaningful. When you write a validation rule ("status must be one of: Active, Inactive, Churned"), that rule is only useful if everyone agrees on what those values mean. The data dictionary defines the agreement.
Sohovi lets you set up validation rules for any column and instantly see which rows fall outside them — no code or SQL required.
It also enables onboarding. When a new analyst joins and needs to build a report, a data dictionary tells them what every field means without requiring them to ask someone who might give them the wrong answer.
Does Your Business Actually Need One?
For businesses with fewer than 5 people and 2-3 data sources: probably not yet. For businesses with multiple systems, multiple teams, or recurring "what does this field mean?" conversations: yes, and sooner than you think.
A simple spreadsheet-based data dictionary covering your 20-30 most important fields can be created in an afternoon and saves hours of confusion every week. A tool like Sohovi profiles your actual data and shows you exactly which fields need clear definitions — making it easy to know where to start.
Frequently Asked Questions
Q: What is a data dictionary in simple terms? A data dictionary is a reference document that defines every piece of data your organization collects — what each field is called, what it means, what values are allowed, and who is responsible for it. Think of it as a glossary for your data.
Q: What is the difference between a data dictionary and a data catalog? A data dictionary defines individual fields — their names, types, meanings, and rules. A data catalog is broader — it inventories entire datasets, tables, and data assets across an organization, with metadata about lineage, quality, and usage. A data dictionary is often a component within a data catalog.
Q: Who should maintain a data dictionary? The business owner of each data domain should maintain the definitions for their fields — with IT or data engineering responsible for technical details like data types and source systems. Data governance leads often coordinate the overall structure.
Q: What format should a data dictionary be in? A spreadsheet works well for small organizations. Larger organizations use dedicated tools like Collibra, Alation, or dbt docs. The format matters less than the discipline of keeping it current.
Q: How do I start building a data dictionary from scratch? Start with your most important dataset — typically your customer contact database or primary reporting table. For each field, document the name, a plain-English description, the data type, and the allowed values or range. Ten fields documented well is better than 200 fields documented poorly.
Q: Is a data dictionary the same as a data schema? Related but different. A schema defines the technical structure of a database — table names, column names, data types, constraints. A data dictionary adds the business context: what each field means in plain English, who owns it, and what values are acceptable from a business perspective.
Q: How often should a data dictionary be updated? Any time a new field is added, an existing field changes meaning, or allowed values are modified. In practice, most organizations update their data dictionary quarterly and do a comprehensive review annually.
Q: What happens if you don't have a data dictionary? Different teams interpret the same fields differently, leading to reports that contradict each other, validation rules that don't match business intent, and onboarding that takes weeks instead of days. The cost is usually most visible when two teams present conflicting numbers to leadership.
Q: Can a data dictionary help with data quality? Directly. A data dictionary defines what "valid" means for each field — what data types, value ranges, and categorical options are acceptable. These definitions become the basis for data validation rules and the standard against which data quality is measured.
Q: What is a business glossary and how does it relate to a data dictionary? A business glossary defines business terms — what "customer," "revenue," and "active" mean in your organization. A data dictionary maps those business terms to specific technical fields. They're complementary: the glossary defines the concepts, the data dictionary links those concepts to actual data fields.
If your team regularly asks "what does this field mean?" or if different reports use the same field differently — a data dictionary is the fix. Start with your 20 most-used fields and build from there.
