Explain the unit of each record
Before analysing a table, establish what one row represents. It might describe a person, event, transaction or repeated observation, depending on the project. Do not infer the unit merely from a file name. Find the relevant documentation and ask about ambiguous structure. If you do not know what a record means, calculations can look orderly while answering a different question from the one you intended. Follow the project’s approved data and access arrangements throughout.
Define fields in plain language
For each relevant field, record its name, meaning, unit where applicable and the source of that definition. A short column label can hide an important distinction. Clarify whether a date is the event date, the recording date or something else. Do not guess that similar labels in different files have identical meanings. Keep the original field identifiable even if you create a clearer label for your own working notes or report.
Document values and missingness
Identify permitted categories, codes and the meaning of missing or special values using the supplied documentation. An empty field, zero and not applicable may represent different situations. Do not replace one with another just to make a calculation run. Record uncertainties and consult the responsible person where necessary. A dictionary should describe the actual data arrangement, including its limits, rather than impose a neat structure that erases information about how the records were produced.
Record transformations separately
If the approved work requires a derived field, document the inputs and the rule used to create it. Preserve the distinction between original and derived material. Note the relevant version so that later changes do not silently alter the interpretation. Do not put personal identifiers or restricted values into a general teaching example. The dictionary can describe a field without exposing the actual sensitive content it may hold; use authorised systems for the project’s real records.
Use definitions to limit the conclusion
Return to the research question after the fields are defined. Does the table actually contain what the proposed argument needs? A recorded category may be a proxy or an administrative label rather than the concept you want to discuss. Explain that gap instead of relabelling it as though the measurement were direct. A data dictionary improves transparency; it does not validate every measure, resolve every bias or authorise an analysis beyond the project’s method and permissions.
Practice with a fictional table
Create a small fictional table with clearly invented records and write a dictionary for three fields. Include one date, one category and one value that could be missing. Explain how the dictionary prevents a plausible misunderstanding of each field. Then write one conclusion the table cannot support. Do not substitute real personal data for the invented records. The exercise should make definitions and limits visible before analysis, while any real project still requires its own documentation, authorised access and appropriate methodological review.
