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 fact’s data on detail or aggregated level.
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 fact’s 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 don’t 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.
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.
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.
No comments:
Post a Comment