Database Modeling and Design

Chapter 8 (part B): Data Warehouse Modeling

Paul Chen

www.cs522.com (containing Seattle U teaching materials ) www.cie-sea.org(Principles & Techniques For Data Warehousing Design)

Topics
1.
2. 3.

4.
5. 6.

Levels of Modeling Data Warehouse Modeling: What, Why The General Approach --The Star Schema Development The Database Component of a Data Warehouse Fact Table and Dimension Table Designing Data Mart A Case Study

Databases & Modeling

Databases & Modeling Type of

Database Relational Database
Multi-dimensional Database

Constructs

Characteristics

New Trend

ERD & EER

Dimensional Modeling
Distributed Component Object Model

Row/ Column Cube

Client Object (DCOM)

OLAP DW
XML UML

Distributed Database
Object-Oriented Database

Class Diagram

Object

Object = Data + Operations(Services); Entity = Data only

Topic 1: Level of Modeling

Descriptive: The dealer sold 200 cars last month. Operational (OLTP)
Primarily Two Dimensional Database System

Explanatory: For every increase in 1 % in the interest, auto sales decrease by 5 %. Traditional DW (OLAP)
Star Schema Cube

Predictive: predictions about future buyer behavior.

Data Mining
Cube + sophisticated analytical tools

Level of Analytical Processing

Descriptive
SIMPLE QUERIES & REPORTS

Explanatory
WHAT IF PROCESSING ANALYZE WHAT HAS PREVIOUSLY OCCURRED TO BRING ABOUT THE CURRENT STATE OF THE DATA

Predictive
DETERMINE IF ANY PATTERNS EXIST BY REVIEWING DATA RELATIONSHIPS

Normalized Tables
Query

Dimensional Tables Roll-up; Drill Down

Statistical Analysis/Expert System/ Artificial Intelligence

Classification & Value Prediction

DESCRIPTIVE MODELING

Relational Data Modeling using ER Diagram

Conceptual Data Model (Analysis - Requirements Gathering; Whats it?) Logical Data Model (Design-How is it?) Physical Data Model (Implementation)

EXPLANATORY MODELING

Also called Dimensional Modelling

Ways to derive the database component of a data warehouse Every dimensional model (DM) is composed of one table with a composite primary key, called the fact table, and a set of smaller tables called dimension tables.

PREDICTIVE MODELING

Similar to the human learning experience Uses observations to form a model of the important characteristics of some phenomenon.
Uses generalizations of real world and ability to fit new data into a general framework.

Can analyze a database to determine essential characteristics (model) about the data set.

Statistical Analysis of Actual Sales (dollars and quantities) relative To these Signage Variables-a predictive modeling example.

Content Frequency Depth Focus Depth Scale Length Location

Statistical Analysis : Correlation, Regression, Experiment Design, Optimization. Now it goes into real time analysis.

Signage

Signage

PREDICTIVE MODELING

There are two techniques associated with predictive modeling: classification and value prediction, which are distinguished by the nature of the variable being predicted.

PREDICTIVE MODELINGclassification

Used to establish a specific predetermined class for each record in a database from a finite set of possible, class values.
Two specializations of classification: tree induction and neural induction.

Example of Classification using tree Induction

Customer renting property > 2 years No Yes Customer age>45 No Yes

Rent property

Rent property

Buy property

Retina Scan
That recent Tom Cruise movie, Minority Report, shows advertising that targets each individual consumer as they pass by the signage. Thats the extreme, but I can see it going that way, said St. Denis.

A Little Perspective
Assigned to work as a team member of a major data warehouse project at the Boeing Company from 1996 to 1998 . The purpose of the project is to re-engineer the company-wide product definitions residing in various legacy systems and consolidate them into a single source data warehouse to be accessed within as well as outside of the Company (such as, airplane customers and suppliers) globally. My responsibilities were to develop data and process modeling of the airplane BOM (bill of material) using Excellarator and later Designer/2000 tools.

Primary Concerns

Replaceable & exchangeable parts

AOG (Airplane on ground) how to get the part in the shortest time and at a minimum cost The volumes of the queries for parts were running at 250,000 / day.

Topic 2: Data Warehouse Modeling- What and Why?

Also called Dimensional Modelling

Ways to derive the database component of a data warehouse Every dimensional model (DM) is composed of one table with a composite primary key, called the fact table, and a set of smaller tables called dimension tables.

Why Do I Need a DW Data Model?

Completeness of Scope needed to achieve integration throughout. The data model serves as a road map guiding development over a long time. Interlocking Parts because of the complex of large data warehouse. The model keeps track of the intertwining parts. Future Additions- want a foundation to build upon. Without a model, how and where additions are to be made is open to question. Redundancy Recognition because integration strives to remove redundancy. The DW data model provides a vehicle to recognize and control redundancy.
Note: Without the model, it is questionable whether the data warehouse should be built.

Completeness of Scope

Recognition of Antonyms (Same name, different object)

Financial Accounting Subsystem

Customer Tracking Subsystem

Account_id Account_name Account_balance

Account_id Account_name Account_balance

Are these the same?

Completeness of Scope

Recognition of Synonyms (Same object, different name)

Customer Billing Subsystem

Customer Tracking Subsystem

Account_id Account_name Account_balance Account_address Account_start_date

Customer_number Customer _name Customer _address Customer_credit_rating Customer_bill_date

Are these the same?

Interlocking Parts- because of the

multidimensional flavor of the data warehouse, the model is needed to reflect and control the numerous relational tables Times Hotel Fact Table Sales Hotel_No Key time key
Hotel Desc Hotel name day of week Hotel_No Key quarter Guest Key year Time Key YTD_Sales_dollars_by_hotel YTD_Sales_dollar_by_Type YTD_Sales_By_Business YTD_Sales_by_non-business

Room_no key
Single Double Family

Guest Profile
Profile key Profile desc Territory

Demographics
Demographic Key
Cluster 1 Population

Age category Income category

Cluster 2 Population

Future Additions
Additional attributes: Penthouse season
Where should these go?

Hotel
Hotel_No Key Hotel Desc Hotel name

Fact Table

Times
time key day of week quarter year

Sales
Hotel_No Key Guest Key Time Key YTD_Sales_dollars_by_hotel YTD_Sales_dollar_by_Type YTD_Sales_By_Business YTD_Sales_by_non-business

Room_no key
Single Double Family

Guest Profile
Profile key Profile desc Territory

Demographics
Demographic Key
Cluster 1 Population

Age category Income category

Cluster 2 Population

Redundancy Recognition
The DW Data Model is used to control the placement of redundant data. Hotel
Hotel_No Key Hotel Desc Hotel name Hotel_Location_Id Hotel_Location_Name

What the Dimensional Model Needs to Achieve and What its Purposes are?

The model should provide the data access.

The whole model should be query-centric. It must be optimized for queries and analysis. The model must show that dimension tables must interact with the fact table. It should also be constructed in such a way that every dimension can interact equally with the fact table. The model should allow drilling down or rolling up along dimension hierarchy.

Topic 3: The General Approach

Create the high level enterprise ERD Develop logical data model for subject area only

Create data warehouse data model from LDM

Develop physical data model

The above is an iterative process; user reviews are critical.

Data Warehousing Modeling

Conceptual Source System Layer By subject area
Analysis - Requirements Gathering; Whats it?

Logical

Integrated Data System Layer (Normalized to third form)

Design-How is it?

Physical

Implementation

Fact Table Dimension Table Denormalization is generally the only way to improve query performance after all the normal tuning options have been employed

Data Warehousing Layer (Denormalized)

Relationship Between the Data Models

Conceptual DM

Logical DM

Physical DM

Dimensional Modeling Operational DM (supporting OLTP)

Supporting OLAP

Data Warehouse DM

Logical Data Model vs. DW Data Model -Table

Normalized Organized around business rules Element of time Maybe specified Repeating group Shown only once

Denormalized; Organized around usage and stability Must be specified

Can contain data arrays

Dimensional Modelling

Modelling technique that aims to present the data in a standard, intuitive form that allows for highperformance access. Uses the concepts of ER modelling with some important restrictions.
Every dimensional model (DM) is composed of one table with a composite primary key, called the fact table, and a set of smaller tables called dimension tables.

TRANSFORM THE LOGICAL DATA MODEL INTO DW DATA MODEL

Remove purely operational data

Add an element of Time to the key structure Accommodate multiple hierarchies and classes Add derived data Add summarization schemes

Data Classification Examples

Data Category Example Total loan amount Decision Support Operational

Average defaulted loan amount

John Does outstanding loan balance

x
x x x x x x x x

Payment received date Loan officers phone # Household income Update indicator Loan date

Dimensional Modelling

Each dimension table has a simple (non-composite) primary key that corresponds exactly to one of the components of the composite key in the fact table.
Forms star-like structure, which is called a star schema or star join.

Star Schema vs. Snowflake Schema

Star Schema (or Star Joint Schema) A specific organization of a database in which a fact table with a composite key is joined to a number of single-level dimension tables, each with a single, primary key Snowflake Schema A variant of the star schema where each dimension can have its dimensions. Starflake schema is a hybrid structure that contains a mixture of star (denormalized) and snowflake (normalized) schemas. Allows dimensions to be present in both forms to cater for different query requirements.

-- Kimball Ralph, Data Warehouse Toolkit ---

A STAR SCHEMA for Auto Sales

Product

Time

Auto Sale

Dealer

Payment method

Customer Demographics

Facts: Actual sale price, Options price, Full price, Dealer add-on, Dealer credit, Dealer invoice, Down payment , Proceeds, Finance vs. Dimension Tables below Time
Year

Product

Payment Method

Customer Dealer Demographics

Dealer name

Model Name Finance Type Age

Quarter
Month Date Day of week Day of month Season Holiday flag

Model Year
Package styling Product category Exterior color Interior color

Term (months)
Interest rate Agent

Gender
Income range Marital status Household size Home value Own or rent

City
State Zone

A Star Join Schema For A Food Cooperative

Fact Table Food Item
Food Item Key Food Item Desc Qty

Times

Sales
Food Item Key Profile Key Time Key YTD_Sales_dollars YTD_Sales_qty

time key day of week quarter year

Dimension tables Member Profile

Profile key Profile desc Territory
Age category Income category

Time-series Dimension table

Demographics
Demographic Key
Cluster 1 Population

Star Schema for Property Sales

Time Time Id (PK)
Day week Quarter year

Fact Table

Branch Branchid (PK)

Promotion Promotionid (PK)

PropertySale TimeId key Propertyid key Branchid key Clinetid key Promotionid key Staffid key Ownerid key
Owner Ownerid (PK)

PropertyforSale Propertyid (PK) Client

Clientid (PK)
Staff Staffid (PK)

Star Schema Keys- Fact Table

Compound primary key, one segment for each dimension. Each dimension table is in a one-to-many relationship with the central fact table. So the primary key of each dimension must be a foreign key in the fact table. If we use concatenated primary key that is the concatenation of all the primary keys of the dimension tables, then we do not need to keep the primary keys of the dimension tables as additional attributes to serve as foreign keys (such as the options below). The individual parts of the primary keys themselves will serve as the foreign keys.

Vs. Two other two options below

A single compound primary key whose length is the total length of the keys of individual dimension table. Or A generated primary key independent of the keys of the dimension tables.

Fact and Dimension Tables for each Business Process of Property Sales
Business Process Fact Tables Property Sales Dimension Tables
Time, Branch Staff, PropertyForSale, owner, ClientBuyer, Promotion Time, Branch, Staff, PropertyForRent, owner, ClientRenter, Promotion Time,Branch, PropertyForSale PropertyForRent, ClientBuyer ClientRenter Time,Branch, PropertyForSale PropertyForRent, Promotion, Newspaper Time, Branch Staff, PropertyForRent

Propertysale

Property Rentals Lease Property Viewing Property Advertising Property Propertyviewing

Advert
Propertymainten

Comparison of DM and ER Models

A single ER model normally decomposes into multiple DMs.

Multiple DMs are then associated through shared dimension tables.

Shared Dimension Tables

Time owner Fact Table Branch PropertySale Promotion Advertisement Newspaper Fact Table

Property For sale

Dimensional Modelling

All natural keys are replaced with surrogate keys (branch Id instead of branch #). Means that every join between fact and dimension tables is based on surrogate (intelligence) keys, not natural keys.

Surrogate keys allows data in the warehouse to have some independence from the data used and produced by the OLTP systems.

Dimensional Modelling

Bulk of data in data warehouse is in fact tables, which can be extremely large. Important to treat fact data as read-only reference data that will not change over time. Most useful fact tables contain one or more numerical measures, or facts that occur for each record and are numeric and additive.

Dimensional Modelling

Dimension tables usually contain descriptive textual information. Dimension attributes are used as the constraints in data warehouse queries. Star schemas can be used to speed up query performance by denormalizing reference information into a single dimension table.

Inside A Dimension Table

Dimension table key. Primary key uniquely identifies each row in the table. Table is wide. Typically, a dimension table has many columns or attributes. Textual attributes. Dimension tables usually contain descriptive textual information. Attributes not directly related. Frequently you will find that some of the attributes are not directly related to the other attributes in the table.

Inside A Dimension Table (Contd)

Not normalized. For efficient query performance, it is best that the query picks up an attribute directly the dimension table. Drilling down, rolling up. The attributes in a dimension table provide the ability to get to the details from high levels of aggregation to lower levels of details.

Multiple Hierarchies. Dimension tables often provide for multiple hierarchies, so that drilling down may be performed along any of the multiple hierarchies.
Few number of record. A dimension table typically has fewer number of records or rows than the fact table.

An Index on this table is nearly as large as the table itself (table = 9GB, Index = 7.2GB)

Example: Part quantity on Airplane

Normalized data structure

Part Table 123N4321-1 321N1234-5 423N1111-6 523N2222-8

100,000 part numbers on a 737

Part Quantity per Airplane 123N4321-1 123N4321-1 123N4321-1 123N4321-1 321N1234-5 321N1234-5 321N1234-5 6 6 6 6 2 2 3 SWA 737 #2521 SWA 737 #2524 SWA 737 #2629 SWA 737 #2744 SWA 737 #2521 SWA 737 #2524 SWA 737 #2629

Airplane Table SWA 737 #2521 SWA 737 #2524 SWA 737 #2629 SWA 737 #2744
3000 737 airplanes

100,000 part number X 3000 airplanes (737 only) = 300,000,000 rows in table

Number of rows in the table and any indexes are dramatically less - 1/600th

Example: Part quantity on Airplane

Denormalized data structure Part Table
100,000 part numbers on a 737

Airplane Table SWA 737 #2521 SWA 737 #2524 SWA 737 #2629 SWA 737 #2744
3000 737 airplanes

123N4321-1 321N1234-5 423N1111-6 523N2222-8

Part Quantity per Airplane 123N4321-1 321N1234-5 321N1234-5 6 2 3 SWA 737 #2521, 2524, 2629, 2744 SWA 737 #2524, 2524 SWA 737 #2629, 2744

number of part numbers X the number of different quantities by part on a model = number of rows in table (approx. 500,000)

Accommodate Multiple Hierarchies and Classes

DIMENSIONS: are roughly equivalent to Fields in a relational database. In the relational table, there are fields called Product and Region.. In the dimensional data, Product and region are both Dimension. The single biggest factor in determining how many dimensions youll need for a particular database is the existence of multiple hierarchies and classes.

Accommodate Multiple Hierarchies and Classes

If your OLAP server supports multiple hierarchies and classes within one dimension, store them in one dimension. Classes are typically attributes such as size color and other characteristics that define a subset of the members of a dimension.

Accommodate Multiple Hierarchies and Classes

For example A common use for multiple hierarchies is in the geographic dimension. (Sales Territory might roll up into City, State and Region.) For Classes, A car line might be defined by Model, Make, and Series.

Simple Hierarchies (Roll up) & Classes Within Dimensions -Dimension Hierarchies
Region Total

East

West

Central

Chevrolet

make

model

Series

Multiple Levels of Hierarchies

Region Total

EAST

West

Central

Calif

Washington

Oregon

Seattle

Bellevue

Some OLAP servers support multiple hierarchies within one dimension. One child can have many parents.
State Sales Region

City

Sales Zone

Dealer

Roll up
Without multiple hierarchies, the previous database would have to be represented with separate dimensions for each roll-up. Region Zone Dealer

State City Dealer

Inside The Fact Table

Concatenated Key. A row in the fact table relates to a combination of rows from all the dimension tables. Data Grain. Data grain is the level of detail for the measurement or metrics. Fully Additive Measures. The values of the attributes can be summed up by simple additions. Semi-additive Measures. Derived attributes such as percentages are not additive. They are known as semiadditive measures.

Inside The Fact Table

Table Deep, not Wide. Typically a fact table has fewer attributes than a dimension table. But the number of records in a fact table is very large in comparison. Sparse Data. There are rows with null measures such as the date representing a closed holiday. In this case, there is no need to keep these rows. Degenerate Dimensions. Examples of such attributes are reference numbers like order numbers, invoice numbers, order line numbers, and so on.

Topic 4: The Database Component of a Data WarehouseFact Table

and Dimension Table

Fact Table: A Fact Table is a table in a relational database with a multi-part key. Each element of the key is itself a foreign key to a single dimension tale. Dimension Tables They are the constraints used in forming the fact table.

Star Schema Fact Table

Consists of the numeric measurement of interest to the business analysts Represents the natural dimensions found in business and facts associated with them Quantifies data described by the Dimension Tables Key is unique concatenation of values of dimension keys Must contain time dimension Numeric values should be additive (Aggregations of quantities or amounts from atomic level; Be careful with percentages or averages)

Star Schema Dimension Table

Consists of the constraints used in forming the fact table Contains mostly textual elements used to describe the dimensions Start with the most detailed aggregation level necessary (e.g. State vs. Zip Code), if possible May have to develop surrogate keys They will increase maintenance effort required Use them when they make sense Maintain a manageable number of aggregation levels in each dimension

Star Schema Dimension Table

Consists of the constraints used in forming the fact table Contains mostly textual elements used to describe the dimensions Start with the most detailed aggregation level necessary (e.g. State vs. Zip Code), if possible May have to develop surrogate keys They will increase maintenance effort required Use them when they make sense Maintain a manageable number of aggregation levels in each dimension

Add An Element Of Time To The Key Structure

Time is probably the most common dimension in a multidimensional databases. It is used to project trends-sales trends, market trends, and so forth.
A series of numbers representing a particular variable (such as sales) over time is called a time series. (for ex. 52 weekly sales numbers for auto is a time-series). Do not mix different periodicities in one dimension (A time series always has a particular periodicity, such as weekly, monthly, quarterly,

When do we keep time- series data?

When trends and patterns are desired

When comparisons are needed (e,g., last quarter to this quarter) For example, Auto Sales information by month or by calendar year.

When to Snowflake Snowflaking is a

method of normalizing the dimension tables in a Start schema. City Customer Dimension table Classification Customer Key Customer name address Zip City class key
table

Fact Table
Customer key Other keys metrics

City class key (pk) City code Class description Population range Cost of living Pollution index Public trans Customer indes

1. If the customer dimension is Very large, the savings in storage could be substantial. 2. Users may now browse the demographic attributes more than others in the dimension table.

Advantages of the Start Schema

Easy for users to understand: Unlike OLTP, the Start Schema reflects exactly how the users think and need data for query and analysis. They think in terms of significant business metrics. The fact table contains the metrics. The users think in terms of business dimensions for analyzing the metrics.
Optimizes navigation: The joint paths between dimension tables and fact tables are simple and straightforward, your navigation is optimized and becomes faster. The Star schema optimizes the navigation through the databases.

Allows data warehouse queries to drill down and roll up: Drill down is a process of further selection of the fact table rows. Going the other way, rolling up is a process of expanding the selection of the fact table rows.

A Few Definitions
OLAP On-Line Analytical Processing (OLAP) is a category of software technology that enables analysts, managers and executives to gain insight into data through fast, consistent, interactive access to a wide variety of possible views of information that has been transformed from raw data to reflect the real dimensions of the enterprise as understood by the user -- DBMS Magazine, April, 1995 Multidimensional Analysis The manipulation of data by a variety of categories or dimensions, facilitating analysis and an understanding of the data-also known as Drill-around and slice and dice Multidimensional Database Proprietary, non-relational database that stores and manages data in a multidimensional manner, with limited dimensional information.

Some Design Issues

Too Few Dimensions Dimensions Are Lacking Aggregate Level Too Many DimensionsOne Possibility Combine Dimensions Overly Complex Dimensions One Possibility: Split Dimensions Another Possibility: The Snowflake Schema Distinct Time Period Fact Table To Improve Overall Performances (load as well as access) Another Possibility: Multiple Fact tables

Vertical Segmentation
Separate attributes into other tables
Ref School Branch

Branch_id PK School_id PK

Branch_id PK School_id PK Month_yr School_name School_Address

Month_yr
School_name School_Address Number_of_Graduates Number_of_underGraduate Semaster_Tuition Branch_id PK School_id PK Month_yr Number_of_Graduates Number_of_underGraduates Semaster_Tuition

Shared Dimension Tables

Time owner Fact Table Branch PropertySale Promotion Advertisement Newspaper Fact Table

Property For sale

Property Sales With Normalized Version of Branch Dimension Table

Branch Id (PK) Branch no Branch type City (FK) City
City ID(PK) Region ID (FK)

PropertySale timeId key propertyid key branchid key Clinetid key Promotionid Key Staffid key Ownerid key

Region
Region ID (PK)

Roll Up (Dimension Hierarchies)

Vertical Segmentation
Separate

attributes in other tables Overhead of shared locks may be reduced Table scans can be faster Could cause excessive joins

Horizontal Segmentation

Separate subset of data to another table

For example, separate yearly sales data into tables containing only monthly data Using UNION to query multiple tables.

Horizontal Segmentation
Separate

subsets of data to another table (Jan, Feb, ..)

Multiple

queries of multiple tables (UNION) up tables will speed table scans

Breaking

Topic 5: Designing Data Mart

A subset of a data warehouse that supports the requirements of a particular department or business function.
Characteristics include Focuses on only the requirements of one department or business function. Do not normally contain detailed operational data unlike data warehouses. More easily understood and navigated.

Reasons for Creating a Data Mart

To give users access to the data they need to analyze most often.
To provide data in a form that matches the collective view of the data by a group of users in a department or business function area.

To improve end-user response time due to the reduction in the volume of data to be accessed.

Reasons for Creating a Data Mart (contd)

To provide appropriately structured data as dictated by the requirements of the end-user access tools.
Building a data mart is simpler compared with establishing a corporate data warehouse. The cost of implementing data marts is normally less than that required to establish a data warehouse.

Reasons for Creating a Data Mart (contd)

The potential users of a data mart are more clearly defined and can be more easily targeted to obtain support for a data mart project rather than a corporate data warehouse project.

Data Warehouse vs. Data Mart In Terms of Data Granularity

Data Warehouse

Data Mart

Corporate/Enterprise-wide Union of all data marts Data received from staging area Queries on presentation source

Departmental A single business process

Star-join (facts & dimensions)

Technology optimal for data access and analysis Structure to suit the departmental view of data

Structure for corporate view of data Organized on E-R Model

Data Mart From Data Granularity

A subset of a data warehouse that supports the requirements of a particular department or business function.
Characteristics include Focuses on only the requirements of one department or business function. Do not normally contain detailed operational data unlike data warehouses. More easily understood and navigated.

Typical Data Mart Architecture Relative to Data Warehouse

Hotel

Data Warehousing-Fact & Dimension Tables

Sales
Fact Table

Times
time key day of week quarter year

Hotel_No Key Hotel Desc Hotel name

Room_no key

Hotel_No Key Guest Key Time Key YTD_Sales_dollars_by_hotel YTD_Sales_dollar_by_Room_Type YTD_Sales_By_Guest_profile

Single Double Family

Guest Profile
Profile key Profile desc Territory

Demographics
Demographic Key
Cluster 1 Population

Age category Income category

Cluster 2 Population

A Typical Data Warehousing System Architecture

Operational Data store Load Manager Warehouse manager

BOM

Subject Data Convert Data

End-user Access tools

Verified Data

Maintain Data
Subject Data Access Data

Change Inf

BOM

Application Bill of Material

User

Data Update Data Maintain Update On-line Update

Data Warehouse data

Query Results User Query Request Applications

Query manager

Manage System

System Security Data Manage Security

Final Words
Transform

data into information by understanding the process information into decisions with knowledge decisions into results with

Transform

Transform

actions

Topic 6: A Case Study

Study

User Requirements Matching User Requirements to DW Data Requirements Develop Dimension and Fact Tables

A Case Study

Suppose that The GM Car Company manufactures two car lines, Chevrolet and Pontiac. GM car lines are described by Make, Models, and Series. The Make is either Chevrolet or Pontiac. The Model is type of car made within the Chevrolet or Pontiac car lines.

Chevrolet (Make)
Model

Chevrolet Suburbana sports utility for the young. Chevrolet Cavalier a compact for the economy-mined consumer. Chevrolet Caprice a median size for the older driver
Three series within each model are available: Loaded Somewhat loaded No frills

Pontiac (Make)
Model

Pontiac Firebird -- a sports car for the young. Pontiac Sunfire -- a compact for the economy-mined consumer. Pontiac Grand AM -- a median size for the older driver Three series within each car line are available: Loaded Somewhat loaded No frills

Independent Dealer

All of GMs cars are sold through independent dealers.

To qualify for GM car dealers, they must follow GMs rules, e.g., they must send in their financial statements on a monthly basis. They must adhere to the car quality GM stipulates. Dealers are located within Sales Territory. (A group of adjacent towns or A major metropolis, such as Seattle).

Sales Territories

Sales Territories are grouped into Sales Zone (A Sales Zone is a group of counties grouped by GM sales organization). Sales Zone areas are grouped into Sales Region (A Region may consist of several states, such as Northwest).
The cars destined for dealers are based on the Sales

Territory.

Simple Hierarchies (Roll up) & Classes Within Dimensions --Dimension Hierarchies
Region Total

East

West

Central

Chevrolet

Suburban Cavalier Caprice

Loaded

Somewhat
No

loaded

make

frills

model

Series

User Requirements
1. Whats is the sales trend in quantity and dollar amounts sold for each Make, Model, Series (MMS) for a specific dealer, for each Sales Territory, Sales Zone and Sales Region? 2. What is the trend in actual sales (Dollars and quantities) of MMS for a specific dealership, by Sales Territory, Sales Zone and Sales Region compared to their objectives? Both by monthly totals and year-to-date(YTD)? 3. What are the dollars sales and quantities by MMS this year-todate as compared to the same time period last year for each dealer?

User Requirements associated with promotional signage and graphic

1 What are the dollar sales and quantities by MMS associated with promotional signage and graphic this year-to-date as compared to the same time last year for each quarter?
What is the trend in actual sales (dollars and quantities) of MMS for a specific digital signage, by Sales Territory, Sales Zone and Sales Region compared to their objectives? Both by monthly totals and year-to-date(YTD)?

Your Assignments
Matching User Requirements to DW Data Requirements to:
1. Develop fact table(s). 2. Determine required dimensions and attributes. 3. Draw a STAR JOIN SCHEMA to show the relationships between the fact table and the dimension tables.

Matching User Requirements to DW Data Requirements (Develop Fact Table)

Primary Key dealer_id month_year sales_area_id make model series

Matching User Requirements to DW Data Requirements (Develop Fact Table)

DW User Requirements to Data Attributes Matrix 1

Primary keys

dealer_id
Dimensions

month_year
Data Attributes Make Model Series

Determine Dimensions & Attributes

Dimensions sales_area_dim sales_time_dim dealer_dim Attributes dealer_mmm_sales_qty dealer_mmm_sales_dollar_amt dealer_ytd_mmm_sales_qty dealer_yts_mmm_sales_amt dealer_inventory_qty

A STAR JOIN SCHEMA

Dimension Tables Product
product desc product key size

Fact Table Sales Product Key Market Key Time Key Dollar sales

Times
time key day of week quarter year

Market
market key market desc territory Demographics Demographic Key
Cluster 1 Population

Cluster 2 Population