Topic — 14 essays
Data Modeling
How to shape data on purpose: dimensional modeling, star schemas, fact tables, keys, and slowly changing dimensions — the structural decisions that make analytics consistent.
Field Notes
Ontology vs Data Model: Meaning You Can Reuse vs Structure You Can Query
A data model shapes data for one system; an ontology defines what concepts mean, independent of any system — and machines now read your schema.
02Field Notes
The Grain of a Fact Table: The First Decision That Decides Everything Else
The grain is the business definition of what one fact table row represents. Declare it first — every dimension, measure, and bug traces back to it.
03Field Notes
Normalization vs Denormalization: When Each Wins
Normalization splits data into many tables to remove redundancy; denormalization combines them to remove joins. One favors writes, the other reads. The trade.
04Field Notes
One Big Table vs the Star Schema: The Real Trade-off
One Big Table denormalizes everything into one wide table; the star schema keeps facts and dimensions apart. What each costs, and why the answer is usually both.
05Field Notes
Data Vault vs Dimensional Modeling: Which Belongs Where
Data Vault and dimensional modeling aren't rivals; they solve different problems at different layers. What Data Vault costs, and when it's worth paying for.
06Field Notes
Fact Table Types: Transaction, Periodic Snapshot, and Accumulating
Three kinds of fact table, distinguished by what one row represents over time: transaction, periodic snapshot, and accumulating snapshot. How to pick one.
07Field Notes
Slowly Changing Dimensions, Explained Without the Jargon
Slowly changing dimensions answer one question: when an attribute changes, do you overwrite history or preserve it? SCD Types 1, 2, and 3, and when to use each.
08Field Notes
Factless Fact Tables, Explained
A factless fact table records that an event happened, or could have, without any numeric measure. Why a fact table with no facts is useful, and the two types.
09Field Notes
What Are Conformed Dimensions, and Why Do They Matter?
A conformed dimension is one dimension shared identically across several fact tables, so different business processes can be compared on the same terms.
10Field Notes
The Date Dimension: How to Build One and Why You Need It
A date dimension is a table with one row per calendar day, pre-loaded with every attribute of that day. Why every warehouse needs one, and how to build it.
11Field Notes
Star Schema vs Snowflake Schema: Which to Use and When
Star schema vs snowflake schema comes down to one decision: whether you normalize your dimensions. The difference, a worked example, and why the star wins.
12Field Notes
Fact Table vs Dimension Table: The Core Distinction
A fact table stores the measurements you analyze; a dimension table stores the context you analyze them by. The distinction every dimensional model rests on.
13Field Notes
A Field Guide to Dimensional Modeling
Facts, dimensions, and grain — the three ideas that quietly run most analytics, explained without the dogma.
14Field Notes
Surrogate Keys vs Natural Keys: A Practical Rule
Surrogate key vs natural key is a decision every data model faces. The practical rule: surrogate keys for dimensions, natural key kept as an attribute.