Skip to main content

CryspIQ® vs Kimball

Both are dimensional, and they are fixed at different levels. A Kimball star schema models one business process at a time: a sales fact, with chosen measures, against chosen dimensions. CryspIQ® models a level above that — a typed fact (monetary, quantity, event, percentile, reference, GIS or unstructured) about a party, at a place, at a time. A new business process needs new tables and new pipelines under Kimball. Under CryspIQ® it is new rows. CryspIQ® is fixed where a star schema is flexible, and flexible where a star schema is fixed.

What Kimball is​

The Kimball method is the bottom-up approach: build data marts first, one per business function, so a department gets reporting quickly, then hold the enterprise together with conformed dimensions — shared dimension tables that every mart is supposed to reuse.

It is the most widely practised data warehouse method there is, and its strengths are real: fast initial delivery per function, query performance that is hard to beat, and a very large pool of people who already know how to build one.

Where the two actually differ​

Consistency is a discipline in one and a structure in the other. Conformed dimensions work exactly as well as the organisation's willingness to maintain them. The moment one team needs a customer attribute the shared dimension does not carry, the pressure is to fork. In CryspIQ®, a single instance per party is a property of the schema rather than a rule people are asked to follow.

Change lands in different places. Adding a business process to a Kimball warehouse means new fact tables, new ETL and usually a new mart. In CryspIQ® the fact types already exist, so a new process is reference data and a mapping — no DDL, and no reprocessing of history.

Business definitions live somewhere different. Under Kimball they sit in the mart, or in a semantic layer maintained alongside it, which means the next consumer that does not read that mart starts again. CryspIQ® carries the definition on the fact type itself, next to the data, so every consumer inherits it.

Lineage is manual versus automatic. Tracing a Kimball figure back to source means reading the ETL. CryspIQ®'s link key both reassembles a decomposed record and traces it back to where it came from.

Where Kimball is stronger​

A purpose-built star schema, tuned for a report you already know you need, will outperform a generic model on that specific report. That is not a small thing if your workload is a known set of high-volume queries.

Kimball also gives you total freedom over what to model and how. If your reporting genuinely depends on a structure nobody else has, a method that assumes nothing is an advantage — and CryspIQ® would be asking you to give that up.

The honest trade is per-workload optimisation and design freedom, against enterprise-wide consistency and a model that does not need redesigning every time the business changes.

Using both​

They are not exclusive. Organisations run Kimball marts fed from CryspIQ® — the marts keep serving the reports and BI tools already built against them, while the definitions behind them come from one governed model instead of being reimplemented per mart. See co-existence for how that is sequenced.