Scribd
Upload
9 views34 pages

Data Warehouse Lec-6

Uploaded by

Naveen Bandaru
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
9 views34 pages

Data Warehouse Lec-6

Uploaded by

Naveen Bandaru
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 34

Outline

• Requirements for DW
– Information Package
• Dimensional Modeling
• Data Design ‐ ER vs DM

2
BITS Pilani, Pilani Campus
BITS Pilani, Pilani Campus
BITS Pilani, Pilani Campus
BITS Pilani, Pilani Campus
BITS Pilani, Pilani Campus
BITS Pilani, Pilani Campus
BITS Pilani, Pilani Campus
BITS Pilani, Pilani Campus
BITS Pilani, Pilani Campus
BITS Pilani, Pilani Campus
BITS Pilani, Pilani Campus
BITS Pilani, Pilani Campus
BITS Pilani, Pilani Campus
BITS Pilani, Pilani Campus
BITS Pilani, Pilani Campus
BITS Pilani, Pilani Campus
BITS Pilani, Pilani Campus
BITS Pilani, Pilani Campus
BITS Pilani, Pilani Campus
BITS Pilani, Pilani Campus
BITS Pilani, Pilani Campus
BITS Pilani, Pilani Campus
BITS Pilani, Pilani Campus
•The grain or level of granularity for each of our fact table (s).
•The number of conformed (cross‐subject area) dimensions.
•Overall size for each dimension and fact table.
•Initial number and type of aggregates.
•The types and number of the predictable queries to be run
against the model and their frequency.
•Con‐Currency and security regarding data for each dimension
and fact.
•Validation in that each attribute in our model is referenced or
used by a process object.
•A view into what will be required in terms of source system
data to populate our model.
•The types of analytic tools to provide the users access to the
information as contained in our model.
BITS Pilani, Pilani Campus
Conduct Business Requirements Analysis
1) Schedule end‐user requirements gathering sessions.
a) Conduct end‐user requirements sessions.
i) Determine all tactical reporting requirements.
ii) Determine all strategic analysis requirements.

(1) Determine all dashboard or EIS‐ based requirements.


(2) Determine all decision support or analytic requirements.
(3) Determine all data mining requirements.
(4) Determine all ad hoc reporting/access requirements.
b) Publish and obtain feedback.

i) Prepare requirements statement for sponsor/steering


committee approval.
BITS Pilani, Pilani Campus
2) Develop subject‐area data model (in concert with the
business requirements sessions).
a) Refine/establish data modeling/repository tool
environment and update process.
i) Identify/model fundamental entity types (dimensions)
for analysis.
ii) Identify/model business requirements processes (facts
or events) for analysis.
(1) Define all derived and key‐based attributes.
(2) Document all required business rules and determine
what initial summarization data. will be required for fact and
dimension table attribute aggregation definition during the
design phase.
BITS Pilani, Pilani Campus
Dimensional Modeling:
Salient Features

• Represents data in a standard framework


• Framework is easily understandable by end users
• Contains same information as ER model
• Packages data in symmetric format
• Resilient to change
• Facilitates data retrieval/analysis

28
BITS Pilani, Pilani Campus
Dimensional Modeling: Vocabulary

• Measures or facts
• Facts are “numeric” & “additive”
• For example; Sale Amount, Sale Units
• Factors or dimensions
• Star Schemas
• Snowflake & Starflake Schemas

Sales Amt = f (Product,Location,Time)


Fact Dimensions 29
BITS Pilani, Pilani Campus
Star Schema

FK FK
Product Location
Dimension Dimension

Sales Fact
Table

FK FK

Time Promotion
Dimension Dimension
30
BITS Pilani, Pilani Campus
Dimensional Modeling

• Detailed data analysis of a single business process is


performed to identify the fact table granularity,
associated dimensions and attributes, and numeric
facts.
• Dimensional models contain the same data content
and relationships as models normalized into third
normal form, but structured differently.
– Improve understandability and query performance
required by DW/BI
• Primary constructs of a dimensional model
– fact tables
– dimension tables

BITS Pilani, Pilani Campus


Dimensional Modeling

• Fact tables
– Contain the metrics resulting from a business process or
measurement event, such as the sales ordering process or
service call event
– Dimensional models should be structured around business
processes and their associated data sources,
• This results in ability to design identical, consistent views of data
for all observers, regardless of which business unit they belong to,
which goes a long way toward eliminating misunderstandings at
business meetings
– Fact table’s granularity should be set at the lowest, most
atomic level captured by the business process
• This allows for maximum flexibility and extensibility.
– Business users will be able to ask constantly changing, free‐ranging,
and very precise questions.

BITS Pilani, Pilani Campus


Dimensional Modeling

• Dimensional table
– Contain the descriptive attributes and characteristics
associated with specific, tangible measurement events,
such as the customer, product, or sales representative
associated with an order being placed.
– Dimension attributes are used for constraining, grouping,
or labeling in a query.
– Hierarchical many‐to‐one relationships are denormalized
into single dimension tables.

BITS Pilani, Pilani Campus


Star Schema

• A fact table
• Multiple dimension tables
• Example: Assume this schema to be of a retail‐chain. Fact will be
revenue (money). How do you want to see data is called a dimension.

BITS Pilani, Pilani Campus


Snowflake Schema

• The snowflake schema is a variation of the star


schema used in a data warehouse.
• The snowflake schema is a more complex schema
than the star schema because the tables which
describe the dimensions are normalized.

BITS Pilani, Pilani Campus

You might also like