You are on page 1of 34

Understanding

Prepared By : Amit Sharma

Hyperion/OBIEE Trainer
learnhyperion.wordpress.com
Review

 Architecture
 Characteristics
 Relational OLAP
 Multidimensional OLAP
 ROLAP VS. MOLAP
Today Star Schema

Fact table
Dimensions

Drilling Down & Roll up

Slicing & Dicing
Fact
Definition : Facts are numeric measurements (values) that
Facts are stored in a FACT table I.e. the center of the star
schema.
Facts are used in business data analysis, are units, cost,
prices and revenues
Example: sales figures are numeric measurements that
represent product and/or service sales.
.
Fact Table
Central table
– Mostly raw numeric items
– Narrow rows, a few columns at most
– Large number of rows (millions to a
billion)
– Access via dimensions
Fact Table
Definition :The centralized table in a star schema is called as
FACT table, that contains facts and connected to dimensions. A
fact table typically has two types of columns:
 Contain facts and
 Foreign keys 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.
A fact table might contain either detail level facts or facts that
have been aggregated (fact tables that contain aggregated
facts are often instead called summary tables). A fact table
usually contains facts with the same level of aggregation.
Dimension
Definition : Qualifying characteristics that provide additional
perspective to a given fact.
Example: sales might be compared by product from region to region
and from one time period to the next.
Here sales have product, location and time dimensions.
Such dimensions are stored in DIMENSIONAL TABLE.
Dimension Tables
Definition: The dimensions of the fact table are further described with
dimension tables
Fact table:

Sales (Market_id, Product_Id, Time_Id,

Sales_Amt)
Dimension Tables:

Market (Market_Id, City, State, Region)

Product (Product_Id, Name, Category, Price)
Time (Time_Id, Week, Month, Quarter)
What is Star Schema?
Definition: Star Schema is a relational database schema for
representing multidimensional data. It is the simplest form of data
warehouse schema that contains one or more dimensions and fact
tables.
It is called a star schema because the entity-relationship diagram
between dimensions and fact tables resembles a star where one
fact table is connected to multiple dimensions.
The center of the star schema consists of a large fact table and it
points towards the dimension tables.
The advantage of star schema are slicing down, performance
increase and easy understanding of data.
Steps in designing Star Schema
 Identify a business process for analysis(like sales).
 Identify measures or facts (sales dollar).
 Identify dimensions for facts(product dimension, location dimension,
time dimension, organization dimension).
 List the columns that describe each dimension.(region name, branch
name, region name).
 Determine the lowest level of summary in a fact table(sales dollar).
 In a star schema every dimension will have a primary key.
 In a star schema, a dimension table will not have any parent table.
Whereas in a snow flake schema, a dimension table will have one or
more parent tables.
 Hierarchies for the dimensions are stored in the dimensional table itself
in star schema.
 Whereas hierarchies are broken into separate tables in snow flake
schema. These hierarchies helps to drill down the data from topmost
hierarchies to the lowermost hierarchies.
Attributes
Each dimension table contain attributes.
Used to search, filter and classify facts.
Example, Sales, we can identify some attributes for each
dimension:
– Product Dimension: product ID, description,
product type
– Location Dimension: region, state, city.
– Time Dimension: year quarter, month, week
and date.
Attributes Hierarchy
Definition : AH provides a top-down data organization
Used for aggregation and drill-down/roll-up data analysis.
Example, location dimension attributes can be organized
in a hierarchy by region, state and city.
AH provides the capability to perform drill-down and roll-
up searches.
Allows the DW and OLAP systems to to have defined
path.
A Concept Hierarchy: Dimension
all (location)
all

office L. Chan ... M. Wind

A Concept Hierarchy: Dimension
(location)
Product Line Product Family Product Product Name
Category

Books Audiobooks Biographies Wild Swans: Three

Daughters of China

Books Audiobooks Childrens The Hobbit

Books Audiobooks Childrens Winnie The Pooh

Books Audiobooks Fiction The Adventures of

Huckleberry Finn

Product_Line->Product_Family->Product_Category->Product_Name
Multidimensional Data
Sales volume as a function of product, month, and
region
Dimensions: Product, Location, Time
Hierarchical summarization paths
on
gi
Re

Product

Product City Month Week

Office Day

Month
A Sample Data Cube
Date Total annual sales
2Qtr of TV in U.S.A.
1Qtr 3Qtr 4Qtr sum
t
uc

TV
od

PC U.S.A
Pr

VCR
sum

Country

Mexico

sum
A Sample Data Cube
Date
t
uc

1Qtr2Qtr3Qtr4Qtr

Country
od

TV sum
Pr

PC U.S.A Total annual sales

VCR of TV in U.S.A.
Mexico
sum Essbase
Sales Manager Qtr1 Qtr2 Qtr3 Qtr4
Sales Sales Sales Sales
John New York 1000 1000 1000 1000
California 200 200 200 200
Texas 63446 63446 63446 63446
Ohio 6633 6633 6633 6633
Illnois 3466 3466 3466 3466
Qtr1 Qtr2 Qtr3 Qtr4
Mac New York
California
Texas
Ohio 300
Illnois
Star Schema
A single fact table and for each dimension one dimension table
Does not capture hierarchies directly
Example of Star Schema: Figure 1.6
In the example, sales fact table is connected to dimensions
location, product, time and organization. It shows that data can be
sliced across all dimensions and again it is possible for the data to
be aggregated across multiple dimensions. "Sales dollar" in sales
fact table can be calculated across all dimensions independently or
in a combined manner which is explained below.

 Sales dollar value for a particular product

 Sales dollar value for a product in a location
 Sales dollar value for a product in a year within a location
 Sales dollar value for a product in a year within a location sold
or serviced by an employee
Example of Star Schema
time
time_key item
day item_key
day_of_the_week Sales Fact Table item_name
month brand
quarter time_key type
year supplier_type
item_key
branch_key
branch location
location_key
branch_key location_key
branch_name units_sold street
branch_type city
dollars_sold province_or_street
country
avg_sales
Measure
s
Aggregation
Many OLAP queries involve aggregation of the data in the fact
table

For example, to find the total sales (over time) of each product in
each market, we might use

SELECT S.Market_Id, S.Product_Id, SUM (S.Sales_Amt)

FROM Sales S
GROUP BY S.Market_Id, S.Product_Id

The aggregation is over the entire time dimension and thus

produces a two-dimensional view of the data
Aggregation Over Time
The output of the previous query
Market_Id
SUM(Sales_Amt) M1 M2 M3 M4
P1 3003 1503 …
Product_Id

P2 6003 2402 …
P3 4503 3 …
P4 7503 7000 …
P5 … … …
Typical OLAP
Operations
Roll up (drill-up): summarize data
– by climbing up hierarchy or by dimension reduction
Drill down (roll down): reverse of roll-up
– from higher level summary to lower level summary or
detailed data, or introducing new dimensions
Slice and dice:
– project and select
Pivot (rotate):
– reorient the cube, visualization, 3D to series of 2D planes.
Other operations
– drill across: involving (across) more than one fact table
– drill through: through the bottom level of the cube to its
back-end relational tables (using SQL)
Drilling Down and Rolling
Up
Some dimension tables form an aggregation hierarchy
Market_Id → City → State → Region
Executing a series of queries that moves down a hierarchy (e.g., from
aggregation over regions to that over states) is called drilling down
– Requires the use of the fact table or information more specific
than the requested aggregation (e.g., cities)
Executing a series of queries that moves up the hierarchy (e.g., from
states to regions) is called rolling up
Drilling Down

Drilling down on market: from Region to State

Sales (Market_Id, Product_Id, Time_Id, Sales_Amt)
Market (Market_Id, City, State, Region)

SELECT S.Product_Id, M.Region, SUM (S.Sales_Amt)

FROM Sales S, Market M
WHERE M.Market_Id = S.Market_Id
GROUP BY S.Product_Id, M.Region

SELECT S.Product_Id, M.State, SUM (S.Sales_Amt)

FROM Sales S, Market M
WHERE M.Market_Id = S.Market_Id
GROUP BY S.Product_Id, M.State,
Rolling Up
Rolling up on market, from State to Region
– If we have already created a table, State_Sales, using

1. SELECT S.Product_Id, M.State, SUM (S.Sales_Amt)

FROM Sales S, Market M
WHERE M.Market_Id = S.Market_Id
GROUP BY S.Product_Id, M.State
then we can roll up from there to:

2. SELECT T.Product_Id, M.Region, SUM (T.Sales_Amt)

FROM State_Sales T, Market M
WHERE M.State = T.State
GROUP BY T.Product_Id, M.Region
Roll-up and Drill Down
Higher Level of
Aggregation

Sales Channel
Region

Drill-Down
Country
State
Roll Up

Sales Representative

Low-level
Details
“Slicing and Dicing”
The Telecomm Slice
Product

Household

s
Telecomm
ion
e g
R Europe
Video
Far East
Audio India

Retail Direct Special Sales Channel

Snowflake Schema
A snowflake schema is a term that describes a star schema
structure normalized through the use of outrigger tables. i.e
dimension table hierarchies are broken into simpler tables. In
star schema example we had 4 dimensions like location, product,
time, organization and a fact table (sales)
Snowflake schema
Represent dimensional hierarchy directly by normalizing tables.
Easy to maintain and saves storage
Example of Snowflake
Schema
Example of Snowflake Schema
time
item
time_key
day item_key supplier
day_of_the_week Sales Fact Table item_name supplier_key
month brand supplier_type
quarter time_key type
year item_key supplier_key

branch_key
branch location
location_key
location_key
branch_key
units_sold street
branch_name
city_key city
branch_type
dollars_sold
city_key
avg_sales city
province_or_street
Measure country
s
THANK YOU