Dimensions are not just for data warehouses

Conventional wisdom has OLTP people thinking in the third-normal form with master - detail relationships and the like popping up all over the place, and us DWers (does the expression data warehomemaker exist?) working with long tables of fact linked to many denormalised tables representing the dimensions. These dimension tables represent hierarchical knowledge about an entity for example: Customer -> City -> State -> Country. Typical data warehouse dimensions include customers, products, and dates.

But what if we moved the idea of dimensions to something such as the receiving accounts in an ERP system. We could develop a hierarchy that has levels such

  1. company total
  2. expense category (income or expense)
  3. expense type (shipping, labour costs etc)
  4. account
And then if we have a time dimension that aligned to the fiscal calendar and perhaps mix in customers and possibly product then we have the beginnings of a system to provide some pretty flexible management (and perhaps financial) reporting. And if this runs over some OLAP style aggregates or a OLAP cube the performance should not be too bad at all