What this covers
A data warehouse needs a precise definition of what each row represents. We establish the grain of each fact — an order line, a transaction or a period balance — and the dimensions used to interpret it. Customers, products, organisation and calendars need compatible definitions across processes. Design starts with analytical questions and available sources, avoiding joins that multiply values and aggregations that conceal important differences in the underlying records.
History is part of the model. We distinguish when an event occurred, when information was valid and when it reached the system. We decide which changes to retain and how to handle corrections, late data and changing hierarchies. Mappings, keys and reconciliations document the path from sources to the analytical structure. These make it possible to check totals, trace measures to their origin and explain how a change affects historical views and comparisons.
Inside the work
Facts and grain
We define events, balances and levels of detail, specifying which measures can be added and across which dimensions.
Shared dimensions
We organise common keys, master data and hierarchies, handling unmatched records and differences between system codes.
History and validity
We define history and late-data rules, distinguishing business changes from corrections to the information describing them.
Source reconciliation
We check counts and values through the model, making filters, transformations and exceptions visible.
What takes shape.
Practical work products, scoped to the engagement.
Analytical model
A fact and dimension schema with defined grain, relationships, keys and measures.
Mappings and history
Source mappings and rules for validity, historical changes and corrections.
Consistency checks
Repeatable integrity, count and total checks, with differences traced back to source records.
Start with your context.
We define the question, sources, and expected outcome before choosing tools and a path.
Start with an assessment