A data dictionary explains how data is represented technically. A business glossary explains what an organization means. Governance needs both, linked: one business term may use several fields, and one field may support several business concepts.
Keeping the layers distinct makes review easier. Engineers can update observed types and formats without rewriting business policy; Stewards can refine a term without copying the same definition into every column description.
Build the link, not two isolated lists
- Profile the implementation Record table, field, type, format, nullability, key evidence and source in the dictionary.
- Define the concept Record business boundary, calculation, synonyms, domain and Steward in the glossary.
- Create explicit links Connect terms to the fields and tables that implement them, including filters or derivations.
- Review changes separately A detected type change and a revised business definition are different governance events.
| Layer | Example record | Answers |
|---|---|---|
| Business glossary | Revenue = net amount for completed sales | What do we mean, who decides, what is included? |
| Data dictionary | sales_transactions.net_amount · decimal(12,2) | Where is it, how is it stored, what was observed? |
| Data dictionary | sales_transactions.status · text | Which field supplies the inclusion condition? |
| Semantic link | Revenue → net_amount where status = completed | How does the concept map to implementation? |
What good looks like
If a definition cannot be traced to implementation, it is hard to test. If a field has no business context, it is hard to use responsibly.