Data Modeling & Design (KA 3)

Data Modeling & Design (KA 3)

Conceptual, logical, physical — and the modelling notations DMBOK names (E-R, dimensional, NoSQL, graph).

Why it matters

The model IS the contract. A weak model leaks complexity into every query, every pipeline, every report. DMBOK insists on multiple notations because no single notation serves every workload.

Going deeper

Modelling notations DMBOK recognises, with a one-line ‘best for’:

Notation	Best for	Trade-off
E-R (Chen / Crow's-Foot)	OLTP, 3NF correctness	Verbose for analytical workloads
Dimensional (Kimball star)	Analytics, BI dashboards	Update anomalies (intentional)
Data Vault	Auditable, source-agnostic enterprise hub	Steep learning curve
NoSQL / aggregate-oriented	Document, KV, time-series stores	Limited cross-aggregate queries
Property graph / RDF	Connected / variable-depth questions	Aggregate queries are awkward

A mature platform uses two or three: relational 3NF for OLTP, dimensional for the BI layer, graph for the connection / fraud workload — and keeps them all traceable back to the same conceptual model.

Choosing a model is choosing the right map for the question.

A subway map distorts geography on purpose — it answers ‘which line do I take?’ brilliantly and ‘how far is it?’ uselessly. A road map does the opposite. A topographical map answers ‘can I hike there?’ A street-view 3D map answers ‘will I recognise the entrance?’. Same city, four maps, all correct — for one question each.

OLTP models, dimensional models, graph models and document models are four maps of the same business. Using a road map to navigate the subway is the cost of modelling everything in one notation ‘to be consistent’.