Data Warehouse – Fact and Dimension Tables in a dimensional model

Fact and Dimension Tables (Ralph Kimball) in a dimensional model
Ok now that we know that we get a Logical and physical Models in a Data warehouse () lets go into some of the content that goes into the actual tables that resides on the Data warehouse
I will discuss Fact and dimension tables on a high level as I know you can find hundreds of books and articles on the web describing it in much more detail. One of the books I used for this summary is a book written by Ralph Kimball (The Data Warehouse Toolkit).
Remember that the tables are not platform specific i.e. it will only run on Oracle/SQL/Ter data.
It makes a lot of sense to attend his master class on this subject.

Dimension (Dim) Table

A dim table contains the textual description of an entity (Subject Area).
Ok saying that does not really make sense now does it?

Let’s do this by example taking a banking industry as our industry.
a Typical dimension will be a Customer with his surname, first name, region, country and address that it no factual data of the customer.
The customer dim table will be linked to a factual table be a Key (will chat on keys in a later blog).
a Dimension table could be used to group data by for example we can group all the customer by region and then link them to a fact table to get accounts by region.
This table should contain best description possible for any description – you can store the short description next to it but the more descriptive the data the better for use the more the user will like you for it.
Build one dim (i.e. Customer) and re-use the key in all fact tables avoid having the same dim table with deferent attributes all over the database-if you need one more description then enter it in the table do not create another table.

Thus a Dim table consists of the following attributes

  • Textual descriptive information on the subject.
  • Can use group by on data.
  • Link to Fact Tables with Keys.
  • Can have more than one attribute of the subject in fact up to a few hundred attributes can exists
  • Data can be used for reporting labels. i.e. Region description
  • Descriptive data can be sourced from the master data repository (MDM)
  • Lengthy description must be provided if possible for any short description (Key) Source from MDM if possible.
  • Table can define a hierarchy within the table (Self reference table – will provide sample later in blog) and have a flat hierarchy with column in Region Country
  • Highly renormalized (Later Blog)
  • Companion table to a fact table.
  • Only one row per business key i.e. one customer cannot have two names.
  • Dimension data can change as follow (Will go into more details on blog)
    1. Type One – Simply overwrite the old value(s).
    2. Type Two – Add a new row containing the new value Type
    3. Type Three – Add a new attribute to the existing row.

Fact Tables:

A fact table typically consist of only numerical data that you can join to the Dim table by Key.
Typically this table is deep and narrow (Not lost of columns) with millions of rows.
Let’s go back to the Customer in the banking industry we would now like to see all transactions for the customer so we create a Fact table with transactions in it.
This transaction table will simply have transaction AMT and Customer Key.
Thus joining the customer dim to this table will show us how many transactions per customers and even what the values of these transactions was , even more we can now see it by region due to the data in the dimension table.
Thus a Fact table consists of the following attributes

  • Typically only Numerical data
  • Narrow of thousands of records (deep)
  • Sums and calculations can be performed on the attributes (Additive , Non Additive, Semi Additive)
  • Must have at least one link to a Dim table in order to do MIS.
  • It is in the centre of a star schema.
  • Grain on fact important for each fact table.(define it before you create it)
  • Types of fact table : Transactional, Periodic snapshots, Accumulating snapshots (Later blog on this)

Sample of both.

Logical and physical model sample

Logical and physical model sample

Kimball, Ralph. The Data Warehouse Lifecycle Toolkit Second Edition. Winely Publishing Inc.

{Views and opinions on this Blog does not reflect current/past employers view(s).}


Tagged: , ,

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: