This document discusses different types of schemas used in multidimensional databases and data warehouses. It describes star schemas, snowflake schemas, and fact constellation schemas. A star schema contains one fact table connected to multiple dimension tables. A snowflake schema is similar but with some normalized dimension tables. A fact constellation schema contains multiple fact tables that can share dimension tables. The document provides examples and comparisons of each schema type.

1. SCHEMAS FOR
MULTIDIMENSIONAL
DATABASES
Sarvajanik College of Engineering &Technology
Computer (Shift-1) 7th year

2. Presented by:
Yazad H. Dumasia

3. What is Schema?
 Database uses relational model while data warehouse
requires Schema.
 Schema is a logical description of the entire
database.
 It includes the name and description of records.
 Much like a database, a data warehouse also requires
to maintain a schema.

4. Types of Schemas
 Star Schema
 Snowflake Schema
 Galaxy Schema

5. Fact Table
 Contains primary information of the warehouse.
 Contain the contents of the data warehouse and store
different types of measures.
 Located at center in Star or Snowflake Schema
surrounded by dimensional tables.
 Two columns: Measurements(numeric values)and
Foreign keys to dimension tables.

6. Dimension Table
 Contain information about a particular dimension.
 Textual information of the business
 Stores attributes or dimensions that describes
the objects in a fact table.
 Dimension table has a surrogate key column that
uniquely identifies each dimension record.
 It is de-normalized because built to analyze data as easily as
possible.

7. Star Schema
 Star schema is a relational model with
one-to-many relationship between the fact table and
the dimension tables.
 De-normalized model.
 Easy for users to understand.
 Easy querying and data analysis.
 Ability to drill down or roll up.

8. Star Schema
 Each dimension in a star schema is represented
with only one-dimension table.
 This dimension table contains the set of attributes.
 There is a fact table at the center. It contains the
keys to each of four dimensions.
 The fact table also contains the attributes, namely
dollars sold and units sold.

9. Star Schema
time_key
day
day_of_the_week
month
quarter
year
time
location_key
street
city
state_or_province
country
location
Sales Fact Table
time_key
item_key
branch_key
location_key
units_sold
dollars_sold
avg_sales
Measures
item_key
item_name
brand
type
supplier_type
item
branch_key
branch_name
branch_type
branch

10. Star Schema
 Here Sales Fact table got concatenated keys
 Concatenation of all the primary keys of the
dimension tables i.e. Time Key of Time Dimension
table, Item Key of Item Dimension table, Location key
from Location dimension table, Branch key from
Branch dimension table.

11. Star Schema in Real-world Database
SELECT
P.Brand,
S.Country AS Countries,
SUM(F.Units_Sold)
FROM Fact_Sales F
INNER JOIN Dim_Date D ON (F.Date_Id = D.Id)
INNER JOIN Dim_Store S ON (F.Store_Id = S.Id)
INNER JOIN Dim_Product P ON (F.Product_Id = P.Id)
WHERE D.Year = 1997 AND P.Product_Category =
'tv' GROUP BY P.Brand, S.Country

12. Benefits Star Schema
• Star schemas are denormalized, meaning the normal rules of normalization applied
to transactional relational databases are relaxed during star schema design and
implementation. The benefits of star schema denormalization are:
• Simpler queries - star schema join logic is generally simpler than the join logic
required to retrieve data from a highly normalized transactional schema.
• Simplified business reporting logic - when compared to
highly normalized schemas, the star schema simplifies common business reporting
logic, such as period-over-period and as-of reporting.
• Query performance gains - star schemas can provide performance enhancements
for read-only reporting applications when compared to
highly normalized schemas.
• Fast aggregations - the simpler queries against a star schema can result in
improved performance for aggregation operations.
• Feeding cubes - star schemas are used by all OLAP systems to build
proprietary OLAP cubes efficiently; in fact, most major OLAP systems provide
a ROLAP mode of operation which can use a star schema directly as a source
without building a proprietary cube structure.

13. Demerits
• The main disadvantage of the star schema is that data integrity is not
enforced as well as it is in a highly normalized database.One-off inserts and
updates can result in data anomalies which normalized schemas are
designed to avoid.Generally speaking, star schemas are loaded in a highly
controlled fashion via batch processing or near-real time "trickle feeds", to
compensate for the lack of protection afforded by normalization.
• Star schema is also not as flexible in terms of analytical needs as a
normalized data model.
• Normalized models allow any kind of analytical queries to be executed as
long as they follow the business logic defined in the model. Star schemas
tend to be more purpose-built for a particular view of the data, thus not
really allowing more complex analytics.
• Star schemas don't support many-to-many relationships between business
entities - at least not very naturally.Typically these relationships are
simplified in star schema to conform to the simple dimensional model.

14. Snowflake Schema
 Some dimension tables in the Snowflake schema
are normalized.
 The normalization splits up the data into additional
tables.
 Unlike Star schema, the dimensions table in a
snowflake schema are normalized.

15. Snowflake Schema
time_key
day
day_of_the_week
month
quarter
year
Time
location_key
street
city_key
location
Sales Fact Table
time_key
item_key
branch_key
location_key
units_sold
dollars_sold
avg_sales
Measures
item_key
item_name
brand
type
supplier_key
Item
branch_key
branch_name
branch_type
Branch
supplier_key
supplier_type
Supplier
city_key
city
state_or_province
country
city

16. Snowflake Schema
 For example, the item dimension table in star
schema is normalized and split into two dimension
tables, namely item and supplier table.
 Advantage of Snowflake schema is that it is easier
to update and maintain normalized structures.
 Disadvantage of Snowflake schema is that it
degrades the query performance because of additional
joins..

17. Snowflake Schema in Real-world Database

18. SELECT
B.Brand,
G.Country,
SUM(F.Units_Sold)
FROM Fact_Sales F
INNER JOIN Dim_Date D ON F.Date_Id = D.Id
INNER JOIN Dim_Store S ON F.Store_Id = S.Id
INNER JOIN Dim_Geography G ON S.Geography_Id =
G.Id
INNER JOIN Dim_Product P ON F.Product_Id = P.Id
INNER JOIN Dim_Brand B ON P.Brand_Id = B.Id
INNER JOIN Dim_Product_Category C ON
P.Product_Category_Id = C.Id
WHERE D.Year = 1997 AND C.Product_Category =
'tv' GROUP BY B.Brand, G.Country

19. Benefits Snowflake Schema
• The snowflake schema is in the same family as the star schema logical
model.
• In fact, the star schema is considered a special case of the snowflake
schema. The snowflake schema provides some advantages over the star
schema in certain situations, including:
• Some OLAP multidimensional database modeling tools are optimized for
snowflake schemas.
• Normalizing attributes results in storage savings, the tradeoff being
additional complexity in source query joins.

20. Demerits
• The primary disadvantage of the snowflake schema is that the additional
levels of attribute normalization adds complexity to source query joins, when
compared to the star schema.
• Snowflake schemas, in contrast to flat single table dimensions, have been
heavily criticized. Their goal is assumed to be an efficient and compact
storage of normalized data but this is at the significant cost of poor
performance when browsing the joins required in this dimension.[3] This
disadvantage may have reduced in the years since it was first recognized,
owing to better query performance within the browsing tools.
• When compared to a highly normalized transactional schema, the snowflake
schema's denormalization removes the data integrity assurances provided by
normalized schemas. Data loads into the snowflake schema must be highly
controlled and managed to avoid update and insert anomalies.

21. Star Schema Snow Flake Schema
 The star schema is the simplest data warehouse
scheme.
 In star schema, each of the dimensions is
represented in a single table. It should not have
any hierarchies between dims.
 It contains a fact table surrounded by dimension
tables. If the dimensions are de-normalized, we
say it is a star schema design.
 In star schema only one join establishes the
relationship between the fact table and any one
of the dimension tables.
 A star schema optimizes the performance by
keeping queries simple and providing fast
response time. All the information about the
each level is stored in one row.
 It is called a star schema because the diagram
resembles a star.
 Snowflake schema is a more complex data
warehouse model than a star schema.
 In snow flake schema, at least one hierarchy
should exist between dimension tables.
 It contains a fact table surrounded by dimension
tables. If a dimension is normalized, we say it is a
snow flaked design.
 In snow flake schema since there is relationship
between the dimensions tables it has to do many
joins to fetch the data.
 Snowflake schemas normalize dimensions to
eliminated redundancy. The result is more
complex queries and reduced query
performance.
 It is called a snowflake schema because the
diagram resembles a snowflake.
Difference between Star Schema and Snow Flake Schema

22. Fact Constellation Schema
 A fact constellation has multiple fact tables.
 It is also known as galaxy schema.
 The following diagram shows two fact tables,
namely sales and shipping.

23. Fact Constellation Schema
time_key
day
day_of_the_week
month
quarter
year
Time
location_key
street
city
province_or_state
country
location
Sales Fact Table
time_key
item_key
branch_key
location_key
units_sold
dollars_sold
avg_sales
Measures
item_key
item_name
brand
type
supplier_type
item
branch_key
branch_name
branch_type
branch
Shipping Fact Table
time_key
item_key
shipper_key
from_location
to_location
dollars_cost
units_shipped
shipper_key
shipper_name
location_key
shipper_type
shipper

24. Fact Constellation Schema
 The sales fact table is same as that in the star
schema.
 Shipping fact table contains three dimensions.
 It is also possible to share dimension tables between
fact tables.
 For example item and location dimension tables
are shared between the sales and shipping fact table.
 It is a collection of schema in which multiple fact
tables share dimension tables. Sophisticated application
requires such schema.