dimensional-data-modelinglisted

# dimensional-data-modeling **The grain declaration is the binding contract.** It states exactly what one row of a fact table represents, and every later decision inherits its mistakes: a dimension is admissible only if it is single-valued at the grain, a measure is admissible only if it is true at the grain. Declare it before choosing dimensions or facts, in one sentence, at the atomic level the source captures. A model whose grain was declared vaguely cannot be repaired by fixing the ETL or the BI layer; it gets restated, which means reloading history. Three more mistakes account for most of the rest, and all three are mechanical: descriptive text sitting in a fact table, a nullable foreign key where the unknown member row belonged, and a second `dim_customer` that means something slightly different from the first. ## First: which situation is this? **Cold start, designing a model.** Work the four steps in order (below), then run the sessions in `references/workshop-runbook.md` and capture each decision in the artifacts in `references/templates.md`. The grain gate is a real gate: do not proceed to dimensions until the grain sentence is written and agreed. **Inherited warehouse, judging what is there.** Do not redesign. Profile first, then diff the existing model against the laws below and report findings by blast radius: grain defects are restatements, conformance defects are enterprise-wide, a snowflaked dimension is a view away from fixed. Run the checker over the DD