A data dictionary records what each attribute means before schema decisions turn assumptions into tables. It commonly lives in a spreadsheet and captures names, descriptions, business rules, example data, types, upstream dependencies, and lineage. section 4.1.3
Use it to make each attribute answer practical questions:
- What does this value mean, and which business rules constrain expected values or uniqueness? section 4.1.3
- What type and example value should represent it? section 4.1.3
- Where did it originate, and through which dependencies did it reach this table? section 4.1.3
Tracking a marketing cookie ID
Record lineage as a path: Tracking ID in an impressions CSV from a cookie provider becomes TrackingID in staging, then CookieID in the marketing schema. This makes a stored value traceable instead of mysterious. section 4.1.3
Sales Sales Order Date Sales Order Number Sales Person Name Sales Person Email Sales Area Name Sales Area Manager Customer Company Name Customer Contact Name Customer Contact Email Customer Invoice Address Customer Delivery Addresses Sales Order Delivery Due Date Sales Order Delivery Actual Date Sales Order Item Sales Order Quantities Currier Used for Delivery Purchasing Supplier Name Supplier Contact Name Supplier Contact Email Supplier Address Purchase Order Date Purchase Order Number Purchase Order Items Purchase Order Quantities Products Product Name Product Stock Level Product Next Manufacture Date Product Next Manufacture Quantity Back Order Manufacturing ID Product Type Name Product Type Description Product Category Name Product Category Description Product Subcategory Name Product Subcategory Description
Use this unnormalized Sales, Purchasing, and Products attribute list as a starting inventory for dictionary entries before normalization. section 4.1.3
