http://bintelligencegroup.wordpress.

com/2012/06/05/different-types-of-dimensions-and-facts-in-
data-warehouse/
Oracle Business Intelligence OBIEE blog Skip to contentHomeAbout Active Directory Security
using Init Blocks & Variables in 10g Style Oracle BI 11g
Different Types of Dimensions and Facts in Data Warehouse
Posted on June 5, 2012 by bintelligencegroup Dimension -

A dimension table typically has two types of columns, primary keys to fact tables and
textual\descreptive data.

Fact -
A fact table typically has two types of columns, foreign keys to dimension tables and measures those
that contain numeric facts. A fact table can contain facts data on detail or aggregated level.




Types of Dimensions -

Slowly Changing Dimensions:

Attributes of a dimension that would undergo changes over time. It depends on the business
requirement whether particular attribute history of changes should be preserved in the data
warehouse. This is called a Slowly Changing Attribute and a dimension containing such an attribute is
called a Slowly Changing Dimension.



Rapidly Changing Dimensions:

A dimension attribute that changes frequently is a Rapidly Changing Attribute. If you dont need to
track the changes, the Rapidly Changing Attribute is no problem, but if you do need to track the
changes, using a standard Slowly Changing Dimension technique can result in a huge inflation of the
size of the dimension. One solution is to move the attribute to its own dimension, with a separate
foreign key in the fact table. This new dimension is called a Rapidly Changing Dimension.



Junk Dimensions:

A junk dimension is a single table with a combination of different and unrelated attributes to avoid
having a large number of foreign keys in the fact table. Junk dimensions are often created to manage
the foreign keys created by Rapidly Changing Dimensions.



Inferred Dimensions:

While loading fact records, a dimension record may not yet be ready. One solution is to generate an
surrogate key with Null for all the other attributes. This should technically be called an inferred
member, but is often called an inferred dimension.



Conformed Dimensions:

A Dimension that is used in multiple locations is called a conformed dimension. A conformed
dimension may be used with multiple fact tables in a single database, or across multiple data marts
or data warehouses.



Degenerate Dimensions:

A degenerate dimension is when the dimension attribute is stored as part of fact table, and not in a
separate dimension table. These are essentially dimension keys for which there are no other
attributes. In a data warehouse, these are often used as the result of a drill through query to analyze
the source of an aggregated number in a report. You can use these values to trace back to
transactions in the OLTP system.



Role Playing Dimensions:

A role-playing dimension is one where the same dimension key along with its associated
attributes can be joined to more than one foreign key in the fact table. For example, a fact table
may include foreign keys for both Ship Date and Delivery Date. But the same date dimension
attributes apply to each foreign key, so you can join the same dimension table to both foreign keys.
Here the date dimension is taking multiple roles to map ship date as well as delivery date, and hence
the name of Role Playing dimension.



Shrunken Dimensions:

A shrunken dimension is a subset of another dimension. For example, the Orders fact table may
include a foreign key for Product, but the Target fact table may include a foreign key only for
ProductCategory, which is in the Product table, but much less granular. Creating a smaller dimension
table, with ProductCategory as its primary key, is one way of dealing with this situation of
heterogeneous grain. If the Product dimension is snowflaked, there is probably already a separate
table for ProductCategory, which can serve as the Shrunken Dimension.



Static Dimensions:

Static dimensions are not extracted from the original data source, but are created within the context
of the data warehouse. A static dimension can be loaded manually for example with Status codes
or it can be generated by a procedure, such as a Date or Time dimension.



Types of Facts -



Additive:

Additive facts are facts that can be summed up through all of the dimensions in the fact table. A
sales fact is a good example for additive fact.

Semi-Additive:

Semi-additive facts are facts that can be summed up for some of the dimensions in the fact table,
but not the others.
Eg: Daily balances fact can be summed up through the customers dimension but not through the
time dimension.

Non-Additive:

Non-additive facts are facts that cannot be summed up for any of the dimensions present in the fact
table.
Eg: Facts which have percentages, ratios calculated.



Factless Fact Table:

In the real world, it is possible to have a fact table that contains no measures or facts. These tables
are called Factless Fact tables.

Eg: A fact table which has only product key and date key is a factless fact. There are no measures in
this table. But still you can get the number products sold over a period of time.

Based on the above classifications, fact tables are categorized into two:

Cumulative:

This type of fact table describes what has happened over a period of time. For example, this fact
table may describe the total sales by product by store by day. The facts for this type of fact tables
are mostly additive facts. The first example presented here is a cumulative fact table.

Snapshot:

This type of fact table describes the state of things in a particular instance of time, and usually
includes more semi-additive and non-additive facts. The second example presented here is a
snapshot fact table.

About these ads

Share this:EmailLike this:Like Loading...
This entry was posted in Uncategorized. Bookmark the permalink.
Active Directory Security using Init Blocks & Variables in 10g Style Oracle BI 11g
Leave a Reply Cancel reply
Enter your comment here...

Fill in your details below or click an icon to log in:
Email (required) (Address never made public)

Name (required)

Website

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

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

You are commenting using your Facebook account. ( Log Out / Change )
Cancel
Connecting to %s
Notify me of follow-up comments via email.





Search bintelligencegroup
Search for:
Archives
Select Month June 2012 (3) April 2012 (1) July 2011 (1) June 2011 (3) May 2011 (1) February 2011
(2) January 2011 (1) December 2010 (6) November 2010 (6) October 2010 (3) September 2010
(16) August 2010 (10)
Categories
Select Category BIP (5) OBIEE (35) ODI (5)
June 2012 M T W T F S S
Apr
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30
BIP OBIEE ODI
Blog Stats
49,011 hits
Email Subscription
Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 13 other followers





Blogs useful for OBIEE
BI School
Debashis's OBIEE Blog
John Minkjan blog
Saichand Varanasi blog
Venkatakrishnan blog
Users


Oracle Business Intelligence Theme: Twenty Ten Blog at WordPress.com.
Follow Follow Oracle Business IntelligenceGet every new post delivered to your Inbox.



Powered by WordPress.comSend to Email Address

Your Name

Your Email Address
Cancel
Post was not sent - check your email addresses!
Email check failed, please try again
Sorry, your blog cannot share posts by email. %d bloggers like this: