Fact Tables
Fact tables represent business measurements in a dimensional model (more info: 1, 2, 3). They form the center of the star schema and act as a hub among dimensions for “slice-and-dice” operations to create interesting many-to-many relationships. Measurement data in a fact table is most useful if it is additive (prices and number of units for example); however, non-additive data (such as a percentage) as well as partly-additive data (a metric that is only additive in certain contexts) can also be useful under the right circumstances.
Granularity is the defined level of detail of a measurement. The more granular, the greater the detail. The granularity of the fact table will help determine its type and application. More detail allows you to aggregate data in different ways. If there is not enough detail, then drilling down into the data won’t be possible. Here are the three basic types of fact tables as defined by their grain:
Transaction-level grain
These fact tables are common and represent a business function at the transaction level, often representing the lowest-possible level of data available. An example would be a line item on an invoice or sales receipt; a visit, or “hit”, to a page on a website; or perhaps a single pitch in a baseball game.
Accumulating Snapshot grain
This type of fact is not as common as the transaction-level fact, but very important, especially if you are interested in tracking the lifetime of a process. For example, you could use an accumulating snapshot to store a product’s movement through the supply chain. Each row in the fact table would contain date foreign keys that represent milestones in the process (product ordered, removed from inventory, shipped, received, etc.). This fact would compliment your transaction-level fact table, giving you the ability to view a process’s performance.
Periodic Snapshot grain
The periodic snapshot, like the type implies, is a view of a business process at the end of a specific interval. A summary of measurement data is taken at consistent intervals, such as by hour, day, week, or month. These measurements can then be used for trend analysis and to test business performance over time, without the overhead of aggregating transaction-level details.
Each of these fact table types have different applications in the warehouse. Transaction grain is most intuitive to business users and queries against these tables tend to be simple. If the level of detail in the transaction fact is fine enough, then a periodic snapshot will simply be an aggregate of this activity. If the grain is not fine enough, then the periodic snapshot will give additional insight into the operations of the business by providing a better and complimentary view of business data. Accumulating snapshots work exceedingly well when tracking a process over time. Product orders are a great example, as they move from point-to-point in the supply chain. Any business process that expands beyond a single moment in time is a candidate for an accumulating snapshot.
Next, I will discuss different types of dimensions, followed by examples using facts and dimensions in a data warehouse.
I'm a Quant Technical Specialist (Data Warehousing and Business Intelligence), with expertise in business analysis, data modeling, and data integration. I have extensive experience developing vertical and integrated desktop, Internet, and BI applications spanning municipal, clinical, and financial industries.

September 17th, 2007 at 10:26 am
[…] my post, Fact Tables, I discussed three types of fact tables as defined by their grain: transactional, accumulating, and […]
June 16th, 2008 at 11:45 pm
[…] the business process dimensional model. I discussed fact tables already in a previous post (”Fact Tables“), so I won’t repeat myself here. Recently, I also provided a more formal definition of […]
June 23rd, 2008 at 8:38 am
Can i have different metrics granularity in the same fact table? ex: A metric for daily work time, and another for monthly average time? (for the monthly metric there are no values if we drill to the day)… I’ve managed to do it with 2 fact, 2 dim and 2 time dimensions, but i guess it’s not the proper way.
congrats for the good work
June 24th, 2008 at 3:39 am
Hi micaman,
I would never mix grains in a Fact table. Your situation sounds like a classic need for 1 transaction-grain fact and 1 periodic-grain fact table. Your daily data, “One row per day of work time” would fit into your transaction-grained fact. Another fact table would contain the average for each month as in “One row per month with average work time”.
Also, you normally would have a single Time dimension. Create your Time dimension to contain details that match the grain of your transaction fact (one row per day?). Then, create a role-playing dimension on your physical Time table called “DimTimeMonth” (or something similar). This role-playing dimension would simply be a view containing month-specific attributes.
As Time and other dimensions (like Employee) are conformed, you can easily “Drill Across” both Fact tables on common attributes.
Hope this helps!