Data Mart/ Data Warehouse: Dimensional Modeling

1. Case Study: Data Mart / Data Warehouse
Dimensional Modeling
Implementation of dimension table and fact table
DIMENSIONAL MODELING:
A Dimensional Model is a database structure that is optimized for online queries and Data
Warehousing tools. It is comprised of "fact" and "dimension" tables.
A "fact" is a numeric value that a business wishes to count or sum. A "dimension" is essentially
an entry point for getting at the facts. Dimensions are things of interest to the business.
It is the design concept used by many Data Warehouse designers to build their Data
Warehouse.
It contains two types of tables:
1. FACT TABLE
2. DIMENSION TABLE
1. FACT TABLE:
Fact Tables contains the measurements, or metrics or facts of the business process. If your
business process is SALES, then the measurement of this business process such as “monthly
sales number” is captured into the fact table. In addition to measurements, the only other
things a fact table contains are foreign keys for the dimension table.

2. In data warehousing, a Fact table consists of the measurements, metrics or facts of a business
process. It is located at the center of a star schema or a snowflake schema surrounded by
dimension tables. Where multiple fact tables are used, these are arranged as a fact
constellation schema. A fact table typically has two types of columns: those that contain facts
and those that are a foreign key to dimension tables. The primary key of a fact table is usually a
composite key that is made up of all of its foreign keys. Fact tables contain the content of the
data warehouse and store different types of measures like additive, non additive, and semi
additive measures.
Fact tables provide the additive values that act as independent variables by which dimensional
attributes are analyzed. Fact tables are often defined by their grain. The grain of a fact table
represents the most atomic level by which the facts may be defined. The grain of a SALES fact
table might be stated as "Sales volume by Day by Product by Store". Each record in this fact
table is therefore uniquely defined by a day, product and store. Other dimensions might be
members of this fact table but these add nothing to the uniqueness of the fact records. These
"affiliate dimensions" allow for additional slices of the independent facts but generally provide
insights at a higher level of aggregation.
2. DIMENSION TABLE:
In data warehousing, a dimension is a collection of reference information about a measurable
event. These events are known as facts and are stored in a fact table. Dimensions categorize
and describe data warehouse facts and measures in ways that support meaningful answers to
business questions. They form the very core of dimensional modeling.
A data warehouse organizes descriptive attributes as columns in dimension tables. For
example, a customer dimension’s attributes could include first and last name, birth date,
gender, etc., or a website dimension would include site name and URL attributes.
A dimension table has a primary key column that uniquely identifies each dimension record
(row). The dimension table is associated with a fact table using this key. Data in the fact table
can be filtered and grouped by various combinations of attributes. For example, a Login fact
with Customer, Website, and Date dimensions can be queried for “number of male’s age 19-25
who logged in to funsportsite.com more than once during the last week of September 2010,
grouped by day”.
Dimension tables are referenced by fact tables using keys. When creating a dimension table in a
data warehouse, a system-generated key is used to uniquely identify a row in the dimension.
This key is also known as a surrogate key. The surrogate key is used as the primary key in the
dimension table. The surrogate key is placed in the fact table and a foreign key is defined

3. between the two tables. When the data is joined, it does so just as any other join within the
database.
Like fact tables, dimension tables are often highly de-normalized, because these structures are
not built to manage transactions they are built to enable users to analyze data as easily as
possible.
DIMENSION ATTRIBUTE:
These are various columns in a dimension table. In a location dimension, the attributes can be
location code, state, country, zip code.
Before designing your DWH, you need to decide what this DWH contains. Ex if you want to
build a DWH containing Sales, across multiple locations, across time and across products then
your dimensions would
1) Location
2) Time
3) Product
Each dimension table contains data for one dimension
“A SCHEMA IS A FACT TABLE PLUS ITS RELATED DIMENSION TABLES”.
Visually, a dimension schema looks very much like a star, hence the term STAR SCHEMA used to
describe dimensional model. Fact table reside at the center of the schema, and their
dimensions are typically drawn around it.

4. STAR SCHEMA:
A normalized multi-dimensional model in which each disjoint dimension is represented
by a single table.
One key principles of dimensional modeling is the use of fully normalized fact tables together
with fully de-normalized dimensional tables.
Each dimension table contains data for one dimension.
Properties of Fact and Dimension Tables:
Conclusion: Hence we studied implementation of fact tables and dimension tables in data
warehouse / data marts.