Data Dictionary in RDM: Definition & Components

A data dictionary is a structured document, table, or file that defines every variable in a dataset — its name, meaning, data type, unit of measurement, allowed values, and any coding scheme used to represent those values — so that anyone other than the person who collected the data can interpret it correctly. In research data management (RDM), a data dictionary is variable-level documentation: it operates one column, field, or measurement at a time, in contrast to dataset-level metadata (title, creator, date, subject) or study-level documentation (methodology, sampling, provenance).

A dataset without a data dictionary is frequently unusable to anyone but its original creator within a few years, even when the raw values are intact, because coded values (1 = male, 2 = female, 9 = missing), abbreviated variable names (bp_sys_v1), and unit assumptions (is weight in kilograms or pounds?) are rarely self-evident from the data alone. A data dictionary is what converts a column of numbers or codes into an interpretable, reusable variable.

What makes something a data dictionary (operational definition)

A document functions as a data dictionary when it satisfies two conditions: it is organized around individual variables/fields (not the dataset as a whole), and, for every variable it lists, it supplies enough information that an independent user could correctly interpret and reuse a value from that variable without consulting the original researcher. In practice this means a complete data dictionary entry answers, at minimum:

What is this variable called? — the exact field/column name as it appears in the dataset.
What does it measure or record? — a plain-language definition or label, and, for survey data, the exact question wording.
What type of data is it? — numeric, integer, text/string, date, boolean, categorical.
What unit is it measured in? — kilograms, days, USD, Likert points, etc., for any continuous or ordinal measure where a unit applies.
What values are valid, and what do coded values mean? — for categorical/coded variables, the full value-label mapping (e.g., 0 = No, 1 = Yes, -99 = Not applicable); for continuous variables, the plausible range.
How is missingness represented? — the specific code(s), blank convention, or null handling used, and ideally why a value might be missing (skip pattern, non-response, not applicable).
Where did this variable come from? — whether it was directly collected, derived/calculated from other variables (with the formula or logic), or transformed, and any relevant provenance.

A spreadsheet tab that lists only column headers with no definitions is not a data dictionary under this definition — it is a header list. A single paragraph describing a dataset’s general subject matter, with no per-variable breakdown, is also not a data dictionary — that is dataset-level metadata (see below).

Worked example (illustrative)

The table below is an illustrative composite, not drawn from any specific real study, showing what a minimally complete data dictionary entry looks like for three variables in a hypothetical clinical survey dataset:

Variable name	Definition	Type	Unit	Valid values / coding	Missing code
`ptid`	Unique participant identifier	String	—	Alphanumeric, format P#####	Never missing
`age_enroll`	Participant age at enrollment	Integer	Years	18–95	-99
`bp_sys_v1`	Systolic blood pressure, visit 1	Numeric	mmHg	70–250	-99 = not measured
`smoker_status`	Current smoking status at enrollment	Categorical	—	0 = Never, 1 = Former, 2 = Current, -99 = Declined to answer	-99

Without this table, a value of 2 under smoker_status is meaningless noise to anyone reusing the dataset; with it, the value is a fully interpretable data point.

Components of a complete data dictionary

Beyond the minimum fields above, more thorough data dictionaries — particularly those built to a formal standard — also typically capture:

Derivation logic for any computed variable (e.g., bmi = weight_kg / (height_m^2)), so the calculation can be checked or reproduced.
Universe/skip logic — which subset of records a variable applies to, common in survey data where later questions depend on earlier answers.
Format constraints — fixed field width, decimal precision, date format (ISO 8601 versus other conventions).
Version history — when a variable’s definition, coding, or unit changed across waves of a longitudinal study, since reusing older and newer values as if they were identical is a common reproducibility error.
Cross-references to controlled vocabularies — e.g., mapping a diagnosis field to ICD-10 codes, or an occupation field to a standard classification, rather than leaving it as free text.

How a data dictionary differs from a codebook

In practice the two terms are used inconsistently across disciplines, and the distinction is more a matter of scope and formality than a hard line:

A data dictionary is typically the narrower, more mechanical artifact: a table of variable names, types, units, and value labels, often produced directly from a database schema or survey instrument export, and sometimes generated automatically by data-collection software.
A codebook usually wraps the same variable-level information inside a fuller document that also includes study-level context: the questionnaire text as administered, sampling and weighting information, fieldwork dates, and notes on how the study was conducted. A codebook is meant to be read as a standalone reference for understanding the whole dataset, not just looked up variable-by-variable.

The DDI Codebook (DDI-C) specification, maintained by the Data Documentation Initiative Alliance, formalizes this: it is an XML standard explicitly named “codebook” precisely because it bundles study description, file description, and per-variable data description into one document, where a bare data dictionary would typically supply only the variable-level portion. Many research teams use “data dictionary” and “codebook” interchangeably in casual usage; where CASRAI content distinguishes them, it follows the scope difference above rather than treating either as universally more authoritative.

How a data dictionary differs from a metadata schema

A metadata schema is a standardized structure — a defined set of elements and rules, such as DataCite’s metadata schema or Dublin Core — that specifies what descriptive fields any compliant dataset record should carry (title, creator, publication year, subject, related identifiers) so that repositories and search systems can index datasets consistently. A metadata schema describes the dataset as a whole and is designed to be interoperable across many datasets and systems.

A data dictionary, by contrast, is specific to one dataset’s internal content: it does not need to be interoperable with other datasets’ dictionaries, because its job is to document the actual variables inside this particular file. The two are complementary rather than substitutes — a well-documented dataset deposited in a repository typically has both: schema-conformant metadata for discovery (findable via search, correctly attributed, citable), and a data dictionary or codebook for actual reuse (a downstream researcher can correctly interpret and analyze the variables). For guidance on selecting a schema for the discovery layer, see how to choose a metadata schema for a dataset.

A related, more formal standard in this space is ISO/IEC 11179, Information technology — Metadata registries (MDR), a multi-part international standard for how individual data elements should be named, defined, and registered so they can be consistently reused across systems and organizations — effectively a standardized methodology for building the kind of variable-level definitions a data dictionary contains, aimed at large-scale or multi-study data element registries rather than a single project’s dataset.

Why data dictionaries matter for research data management

FAIR compliance. The FAIR principles’ Interoperable and Reusable criteria depend on data being accompanied by documentation clear enough for both humans and, increasingly, machines to correctly interpret variable meaning — a data dictionary is the primary artifact that satisfies this at the variable level.
Funder and repository requirements. Data management plans commonly commit to documenting datasets to a stated standard, and repositories reviewing a deposit for completeness routinely check whether a data dictionary or codebook is included alongside the raw data files.
Reproducibility. Independent verification of a published result requires that another researcher can correctly reconstruct what each variable in the underlying dataset represents; undocumented or ambiguously coded variables are a common, avoidable obstacle to reproducing published analyses.
Longitudinal and multi-site consistency. Where the same variable is collected at multiple time points or multiple sites, a shared data dictionary is what keeps definitions, units, and coding consistent, preventing silent drift (e.g., one site coding sex as text and another as an integer).

Creating a data dictionary in practice

Common approaches, roughly in order of increasing formality:

Manual spreadsheet — one row per variable, columns for name/definition/type/unit/valid values/missing code, as in the worked example above. Adequate for small, single-study datasets, but prone to drifting out of sync with the actual data if updated by hand.
Generated from a data-collection tool — platforms such as REDCap can export a data dictionary directly from the instrument definition, which keeps the dictionary synchronized with the actual field structure by construction.
Generated from a database schema — for data held in a relational database, dictionary content (field names, types, constraints) can be extracted programmatically from the schema itself, though human-written definitions and value labels usually still need to be added on top.
Authored to a formal standard — producing a DDI Codebook (DDI-C) XML file or aligning variable definitions to ISO/IEC 11179 registration practice, appropriate where the dataset will be deposited in a disciplinary repository (particularly social science, survey, or health data archives) that expects or validates against that standard.

Frequently asked questions

Is a data dictionary the same as a codebook?

They overlap heavily and are often used interchangeably, but where a distinction is drawn, a codebook is the broader document (study context plus variable definitions), and a data dictionary is the narrower, variable-only table. See the comparison above.

What is a data dictionary in simple terms?

It is a reference document that explains, for every variable/column in a dataset, what it means, what type of data it holds, what unit it’s measured in, and what any coded values stand for — so someone other than the original data collector can correctly use the data.

Does every dataset need a data dictionary?

Any dataset intended to be shared, deposited in a repository, reused, or kept beyond the immediate project team benefits from one. Funder data management plan requirements and repository deposit checklists increasingly expect it explicitly rather than treating it as optional documentation.

What is the difference between a data dictionary and a metadata schema?

A metadata schema standardizes how a dataset as a whole is described for discovery and citation across many datasets (title, creator, date, subject). A data dictionary documents the internal variables of one specific dataset so its contents can be correctly interpreted and reused. See the comparison above.

What tools can generate a data dictionary automatically?

Structured data-collection platforms (e.g., REDCap) can export a data dictionary directly from the instrument definition, and database schema-introspection tools can extract field names, types, and constraints from a relational database, though human-authored definitions and coded-value labels typically still need to be added.