skip to content

How does a business glossary differ from a data dictionary, and why link glossary terms to the columns that implement them?

level: middleimportance: should knowfreq 40%

answer

  1. concepts versus columns
  2. one term, many implementations
  3. owned by the business
  4. links make search and review work

basics

~20 s

A glossary defines business concepts in plain language, independent of any system; a data dictionary describes the columns of specific tables. Linking terms to columns shows where each concept lives and exposes columns that claim a term but compute it differently.

solid answer

~40 s

A **business glossary** is a controlled list of business **concepts** — "active customer", "net revenue", "churn" — each with an agreed definition, an owner on the business side, and related terms. It is independent of how any system stores data. A **data dictionary** describes **physical columns**: name, type, allowed values and a technical description, per table. The two meet through **links**: tagging `customers.status` and `crm_accounts.is_active` with the glossary term "active customer" lets people search by concept and find every implementation, and it makes **disagreements visible** — two columns linked to one term but computed differently are a finding to resolve. The glossary gives shared language; the links turn it into something you can navigate and audit.

go deeper

for a junior

Know that a glossary defines business terms and a data dictionary describes columns.

for a middle

Explain what linking terms to columns enables, including search by concept and spotting conflicting implementations.

for a senior

Show how you would build and maintain a glossary with owners, testable definitions, suggested links and versioning.

for a principal

Decide the governance for definitions across departments, including who arbitrates disputes and how definition changes reach published reports.

## Two different artefacts | | Business glossary | Data dictionary | |---|---|---| | Unit | a business **term** (concept) | a **column** in a specific table | | Content | definition, examples, synonyms, related terms, business owner | name, data type, nullability, allowed values, technical description | | Scope | organisation-wide, system-independent | per system, per table | | Owned by | business owner or steward | the dataset's technical owner | | Changes when | the business changes its definition | the schema changes | A glossary answers **"what do we mean by X?"**. A dictionary answers **"what is in this column?"**. ## Why link them A glossary on its own is a document people forget to read; a dictionary on its own tells you about columns but not which of five similar ones is *the* "active customer". **Linking** terms to columns connects them: - **Search by concept.** An analyst searches "active customer" and finds every column that implements it, with the certified one marked. - **Consistency checks.** If two columns are linked to one term but compute it differently — one counts customers with an order in 90 days, the other in 30 — the link exposes a disagreement that would otherwise surface as two dashboards showing different numbers. - **Impact of a definition change.** When the business redefines a term, the links list every column and, through lineage, every report that must change. - **Policy by concept.** Some platforms attach classification to terms, so a column linked to "customer email" inherits its sensitivity. ## Keeping a glossary useful 1. **Start small**: the few dozen terms that appear on executive dashboards and in cross-team disputes. 2. **Give each term a business owner** who approves definition changes. 3. **Write definitions testably** — name the population, the time window and the exclusions. 4. **Link, then review**: automated suggestions propose column-term links from names and descriptions; owners confirm. 5. **Version definitions**: record when a definition changed, because historical numbers were computed under the old one. ## Where it stops A glossary defines *meaning*. The executable definition of a metric — which measure, which filters, which joins — belongs in a metrics or semantic layer; the glossary term should point to it rather than restate it. ## Why interviewers ask it Analysts and data engineers both meet the "two teams, two numbers" problem. A good answer separates **concepts** from **columns**, explains what the **links** make possible, and puts ownership of definitions with the business.

  • Two columns are linked to the same glossary term but give different results. What do you do?
    Treat it as a definition dispute, not a bug to patch silently. Bring the evidence to the term's business owner, agree which computation matches the definition, mark the other column as a different or deprecated concept, and update the links and any reports that relied on the wrong one.
  • Who should be allowed to change a glossary definition?
    The term's business owner, through a review that shows which columns and reports are linked to it. Engineers can propose changes, but a definition is a business decision because it changes what published numbers mean.

saying these in an interview costs you the question

  • Treating the glossary and the data dictionary as the same thing
  • Letting engineers define business terms without a business owner
  • Writing a glossary as a document with no links to columns
  • Changing a definition without recording when it changed