Browsing All posts tagged under »Kimball«

Tracking History with Slowly Changing Dimensions

September 24, 2011


In this post I’d like to show a few of the different ways to maintain history. As anyone who has been in data-warehousing for a while can attest to, the two most common scenarios that business users want to see are the data as it was (Kimball Slowly Changing Dimension Type 2) , or as-is […]

Dimensional Modeling Worst Practices

May 16, 2011


As a consultant I see a lot of BI/DW solutions with various clients, and am often called in to fix performance issues. Often times developers/architects will ignore the Ralph Kimball methodology, or try to “improve it” by breaking a few rules. So I thought it might be worthwhile for me to post some of the […]

Data Modeling Conundrum Follow up

March 17, 2011


As a follow up to my previous post on a Data Modeling Conundrum in January (see I left it open as to what the appropriate dimensional model should be. To recap from my first post, let’s say that I’m trying to track Marine Incidents. Zero or many vessels may be involved in an incident, […]

Populating a many-to-many bridge table

January 25, 2011


STOP! For a simpler, faster and more elegant solution to the following problem, see this: In a recent post on dealing with the many-to-many situation ( , I illustrated the use of a bridge table in a dimensional model, as prescribed by Ralph Kimball. So if for example we are recording sales, and many […]

Data Modeling Conundrum

January 16, 2011


A post on the Kimball forum found at has raised a question very similar to one I worked on five years ago when I implemented an Oracle OLTP system capturing Marine Incidents, and the associated data mart for reporting. The question was this: How to model an incident when an incident may involve zero or many […]

Kimball Hierarchy Bridge Table

January 15, 2011


The Bridge table advocated by Ralph Kimball is yet another method to navigate hierarchies. It works by storing all of the ancestors for each node. The leaf node is then joined to the fact table, and the ancestor joined to the dimension table ala: The contents of the ProductBridge table would then look like this: […]