The describe-data deliverable
◈ 5 cardsOne row per column: name, description, type, unit, allowed values, source, missing code. It records the stored type, marks the key, and is what a join is checked against.
What a dictionary is for
A data dictionary is a table about a table: one row per column of the dataset, describing what that column is. It is the deliverable of data understanding → describe data, and it is the first artefact the crew project is marked on. It exists because a column name is not a definition. amount — before or after HST? In dollars or cents? Can it be blank? Every later step (a pivot, a merge, an R call) makes an assumption about each of those, and the dictionary is where the assumption is written down once so nobody guesses twice.
Seven fields, in this course's convention:
- name — exactly as it appears in the header row
- description — one plain sentence
- type — categorical or numeric (discrete/continuous), date, logical — as stored
- unit — CAD, items, days; blank for a categorical
- allowed values — the levels of a categorical; the range of a numeric
- source — where the column came from (system, export, lookup)
- missing code — how a missing value appears: blank,
NA, −999, "n/a"
Worked example — the dictionary for orders
| name | description | type | unit | allowed values | source | missing |
|---|---|---|---|---|---|---|
order_id | unique order number — the key | categorical (identifier) | — | 1001–1012, unique | web store admin export | never blank |
prov | province the order shipped to | categorical, nominal | — | ON, QC, BC, AB | export | blank |
channel | how the order was placed | categorical, nominal | — | Online, Store | export | blank |
amount | order total including HST | numeric, continuous | CAD | 0 – ∞; observed 90–1320 | export | blank |
units | number of items on the order | numeric, discrete | items | integers ≥ 1 | export | blank |
order_date | date the order was placed | date (ISO text in the export) | — | 2025-01-01 to 2025-03-31 | export | blank |
Three rows carry the lesson's weight. order_id is marked as the key: the column that is unique per record and identifies it, which means it is never summed, averaged or binned and is what a merge with another table is matched on. amount carries the unit and the definition — including HST — because a later analyst who assumes pre-tax will be 13 % wrong in Ontario without any tool complaining. And order_date records its stored type, ISO text, not the intended type, date. The export has not been parsed yet; writing "date" would describe the sheet as you wish it were.
The stored type, not the intended one
This is the rule the paper tests. If amount arrived as text — left-aligned, SUM returning 0 — the dictionary says text (to be converted), because the dictionary describes the data as it is, and the conversion is a preparation step that happens after the description and because of it. A dictionary that records what the column should be is a wish list, and it hides exactly the fault the quality check was meant to find.
Keys on both sides of a join
When orders is later merged with a customers table on cust_id, the dictionary for both tables must show the same stored type for the key. "00123" as text in one and 123 as a number in the other will match nothing, silently. Recording the type is what makes that visible before the merge rather than after.
Complete two rows
The crew adds cust_id (a customer number, text, from the CRM, blank when a walk-in) and hst (the tax portion in CAD, computed as amount − amount / 1.13 for Ontario, never blank). Write the seven fields for each before reading on — and note that cust_id is a second key-like column: unique per customer, not per order, so it may repeat across rows and must never be summed.
CRISP-DM: writing the dictionary is data understanding → describe data.