3.

Data Modelling
 3.0: Chapter Goals

Fundamental Concepts

What is Data Modelling

Star Schema
Traditional Data Modelling
3.0 Chapter Goals

Snowflake Schema

Linked Tables

Concatenated Fact Tables

QlikView Data Modelling
Mixed Granularity Schema
Challenge
Data Islands
Solution
 3.1: Data Modelling Conceptual Asides
Conceptual Asides:
• OLAP vs Associative Model
• Dimensional vs Relational Modelling
• Schema
• Cardinality
• Normalization
• Metadata
• Primary Key
• Subset Ratio, Information Density and Perfect Key
• Synthetic Keys / Tables
• Circular Reference
• Importance of Outer Joins
3.2: Understanding Data Modelling

What is Data Modelling?

Relationship between Tables

Science vs. Art

?
Multiple Techniques

Best Practices Advice!

Business Requirements

Outer Join

Validation of Right Model

 3.2: Understanding Data Modelling
Before you start Data Modeling:
• Understand and define the granularity of the data
• Identify and separate Dimension(s) from Fact(s)
• Check if multiple Fact tables exist and wherever possible – Join or Concatenate
• Identify the potential Measures and map with the user requirements
• Identify Join Keys between Fact tables and Dimension tables
• Check if there are any Slowly Changing Dimensions (SCD)
• User requirements and user experience (UX) will determine the data model
 3.3: Types of Data Model

Single Table

Traditional Modelling Star Schema

Types of Data Models

Snowflake Schema

Concatenated Fact Tables

QlikView Modelling Mixed Granularity Schema

Linked Tables
 3.4: Conceptual Aside - Star Schema

%Date_Key
Date
%Customer_Key
Day
Customer Name
Week
Customer Profile
Month
Customer Address
Quarter
Customer Postcode
Year
Online or Store
%Date_Key
%Product_Key
%Product_Key %Store_Key
Product Name %Customer_Key
Description %Promo_Key
Sub Category
Category Quantity
Brand Dollars Sold
%Promo_Key
Discount
Promo Name
Dollars Cost
Promo Type
%Store_Key Ad Type
Store Name Promo Category
Store Location
Store Postcode
Store Region
 3.4: Conceptual Aside - Star Schema
Rules:
• Only one Fact Table
• Only one Field links between Dimensions and Fact Table
• Relationship can be One-to-One or One-to-Many between Dimension and Fact
• Every Dimension Table must contain a Primary Key
• Dimension Table will not have a Parent or Child Table
 3.4: Conceptual Aside - Star Schema
Advantages:
• Query performance
• Load performance and administration
• Easily understood
3.5: Demo – Star Schema
 3.6: Conceptual Aside – Snowflake Schema
What is Snowflake Schema:
• Extension to Star Schema
• Normalized Dimension Tables
• Multiple Nodes
• Dimension Table will have Parent or Child Table
 3.6: Conceptual Aside – Snowflake Schema

%Date_Key
%Customer_Key
Date
Customer Name
Day
Customer Profile
Week
Customer
Month
Address
Quarter
Customer
Year
Postcode
%Date_Key Online or Store
%Product_Key
%Cat_Key
%Store_Key
Category %Product_Key %Customer_Key
Sub Category %Cat_Key %Promo_Key %Promo_Key
%Brand_Key Promo Name
%Brand_Key Product Name Quantity
Brand Name Promo Type
Dollars Sold Ad Type
Discount Promo Category
Dollars Cost
%Store_Key
%Loc_Key %Loc_Key
Lat Store Name
Long Store Region
Location
Postcode
Address
3.7: Demo – Snowflake Schema
 3.8: Concatenated Fact Tables
In Store Sales
%Date_Key
%Customer_Key
Date
Customer Name
Day
Customer Profile
Week %Date_Key Customer
Month %Product_Key Address
Quarter %Store_Key Customer
Year %Customer_Key Postcode
%Promo_Key Online or Store

Quantity
%Product_Key Dollars Sold
%Cat_Key Discount %Promo_Key
%Brand_Key Dollars Cost Promo Name
Product Name Promo Type
Concatenated Tables
Ad Type
Promo Category
%Date_Key
%Store_Key %Product_Key
%Loc_Key %Customer_Key
Store Name %Promo_Key
Store Region Webstore Sales
Quantity
Dollars Sold
Discount
Dollars Cost
 3.8: Conceptual Aside – Concatenated Fact Table
Rules:
• Not more than one Fact Table (Multiple Flat Files and Fact data from multiple sources)
• Implicit vs Explicit Concatenation
• If Field Names are different – rename the Fields and then Concatenate the Tables
• Always identify the tables with flags/tags – ‘Web Sales’ and ‘In Store’ etc.
• Perform data transformations after Concatenation of Tables
 3.9: Mixed Granularity Schema
• Multiple FACT tables with different granularity (Aggregated and Transactional)
• Budget vs. Actual, Web Sales vs Retail Sales and Previous Year Aggregated vs Current Year
Transactional data etc.

Granularity: Transactional Level Granularity: Aggregated to Month

 3.10: Our Advice
2 Cents:
• User requirements must drive the data model and app design approach
• Best practices are great but if your users reject the application, then it is failure regardless
of technical execution
• Consistency beats Coolness
• Most of the traditional data warehousing techniques are applicable in the QlikView world
• Always test your model before publishing the app(s)