Power BI L200 Data Modeling

Instructor: Roshan Oganiya

Email: roganiya@dstrat.com
Making sense of your data
We Love Data
• 20 years of experience in analytics & business intelligence.
• Based in the GTA & service clients worldwide.
• Award winning Microsoft Partner with 70+ Employees.
Our clients
Report Development Flow
Every component is equally important to produce robust solution

Power Query

Data Close &

Apply
Modeling

DAX

(Prep data for Data

Model)
Visualizations
COURSE OBJECTIVES

By the end of this course, you will be able to:

• Understand basic concepts of Data Modeling

• Understand the consequences of data model design decisions

• Understand concepts of calculated columns and measures

 * Times are approximate and will be fluid with the class.

Agenda
9:00 - 9:15 Initial remarks and Introduction to the course
Section A
9:15 - 10:15 Intro to Data Preparation

Section B
10:15 - 11:00 Data Model Schemas, Normalization, Calculated Columns and Measures
11:00 - 11:15 Break
11:15 - 11:45 Lab 1
Section C
11:45 - 12:15 Data Storage in Power BI
12:15 - 12:30 Best Practices, Q&A
Section A
Intro to Data Preparation
Why Prepare our data?
• Power BI is powerful enough to compile and analyze
data, but..
• If the data is not prepared properly, these
compilations will be slower and reduce the report’s
analytical efficiency
• Data needs to cater to the technology of the
compression engine being used by PBI to develop a
robust data model
What is a Data model?
The Technology behind Power BI
The VertiPaq Engine:
Columnar Database Engine - Columns & Segments
How many distinct products sold in 2017-Q1 , only Product and Date columns are used

Compresses data to distinct values (Encoding)

VertiPaq Engine
In-Memory mode for tabular architecture

Pro Tip – Have your Queries/Tables be as “Narrow” as possible

Columnar Database

First Name Last Name Sales First Name Last Name Sales

John Smith $10 John Smith $10

Jane Doe $25 Jane Doe $25

Hardy B $35 Hardy B $35

each row separately each column separately

• Columnar databases are well suited for analytics

In-Memory Database
Data stored in RAM (in memory) when the file is open

Sales Fact 145.0 MB Data Model 13.0 MB

Dimensions 7.0 MB
Int’l Sales 128.0 MB
Total Data 280.0 MB Almost 21X
Compression!!

Query Metadata 14 KB
Entities
Dimension Table:
Contain descriptive information used to slice and dice data from Fact Tables (eg:
branch_name, branch_type)
branch_key
Also holds Relationship/Key Fields used to connect the dimension to the fact table
(eg: branch_key)
Wider tables with small amount of rows

Fact Table:
Contain facts/details which are fields used as values in a visualization (eg: dollars_sold,
units_sold)
Also holds Relationship/Key fields used to connect the dimension to the fact table
(eg: time_key, item_key, branch_key, location_key)
Narrow tables with large amount of rows
• H

Golden Rule:
Avoid using a single table that includes everything (both facts and dimensions)
Relationships
• Connections between a 2 tables (usually
fact & Dim tables) using columns from
each are called Relationships

• Once you have two tables connected, you

can work with the data in both as if they
were in a single table
• A Relationship is analogous to how an
Excel VLOOKUP function brings two tables
together
• Power BI automatically sets the Cardinality,
Cross Filter Direction and Active
relationship when you load queries onto
PBI.
Cardinality
One to One (1 : 1) relationship
- Takes place when you connect columns with the same, distinct values.
- For such a relationship, you can merge the two tables together in Power Query Editor and
disable loading the original to avoid redundancy

One to Many (1 : *) relationship

- The most common type of cardinality used
- Takes place when you connect a field with unique values to another table with the same field
but repeating values
Cardinality

Many to Many ( * : * ) relationship

- Takes place when there are multiple records of the same value in the joining field of the two
tables being joined.
- Considered to be a weak relationship; causes a lot of issues. Can be resolved by creating a
shared dimension and creating one to many relationships with the shared dimension.
- Avoid Many to Many relationships when possible as it is laborious to maintain
Cross Filter Direction
The direction of a relationship is called the cross-filter direction as it sets up the way a filter propagates
through your data

Uni -Directional Relationship

- Used when a dimension table to filters through fact table data as the filter direction moves
from the dimension to the fact table with the connecting field (ProductID)

Bi-Directional Relationship
‐ Allow you to pass filters in both directions
‐ This is different than Many to Many
‐ There is a significant performance penalty for Bi-Directional filtering
Section B
Data Model Schemas, Normalization, DAX Calculated
Columns and Measures
Phases in Building a Power BI Desktop File
Data Model Brings Facts and Dimensions Together

Data Models

Flat or Snowflake
Star Schema
Denormalized Schema
 Flat or
Denormalized
Schema

• All attributes for model exist in a

single table

• Highly inefficient

• Model has extra copies of data >

slow performance

• Size of a flat table can blow up

quickly as data model becomes
complex
 Star Schema 1 Many 1 1

• Simple, easy to understand, fewer

joins
• Comprises of a single Fact table in
the middle branching outwards to
connect to various dimension tables
• Fact table is the “Many” side of the
(one to many) relationship
• Consumes more space than the
snowflake schema (not always a bad
thing as Power BI is powerful enough)
 Snowflake Dims Facts Dims Flake

Schema

• Dimension tables are Normalized in

Snowflake schema

• Dimensions “snowflake” off of other

Dimensions

• Dim or Fact tables can be the

“Many” side of the relationship
 Granularity &
Multiple Fact Tables

• Grain (granularity) measures the level of

detail in a table

Example:
One row per order or per Item
Daily or Monthly date grain

• If your facts have very different

granularities, split them into Multiple Fact
tables & connect them to shared
Sales (Daily by Product)
dimensions at the lowest common
granularity. Budget (Monthly by Product Category & Product Segment
Normalization
• Process of organizing database to make it more flexible by eliminating redundancy and inconsistent
dependency
• Deals with creating separate tables for values that can apply to multiple records (dimension tables) and
relating these tables with some sort of a foreign key.
- This involves studying the dataset to see what fields can be grouped together to form dimension tables that
could be used by other fact tables

• Next, try to figure out how

the new dimension tables could
be related to the fact table with
the help of a simple or
compound key
DAX Foundations
Calculated Columns and Measures are both written in the DAX Language

A Calculated Column is evaluated as a new column in the table in which it resides and will not change value until the
underlying data is refreshed.

Measures are calculations which do not have a result until they are used in a visualization.
They may use sums, averages, minimum or maximum values, counts, or more advanced calculations; and they change
value in response to your interaction with your reports.

Calculated Column
What is a Calculated Column?

Calculated Column
Best Practices – Calculated Columns
What is a Measure?

[Total Sales]=SUM(Sales[Sales Amount])

Calculated Column vs. Measure: When to Use What
Rule of Thumb
Calculated Column – Use in Page, Report & Visual Filters as well as Slicers, Rows and Columns
Measures - Use in Values section

Columns

Values

Slicer

Rows
Designing good data models
Key takeaways to design a good Power BI Desktop data model

• RAM is precious !!!!!

• If a fact table contains an ID field which is unique for each record, remove it unless needed as a connector key
• Ex. Transaction ID

• Sort columns before bringing them into a Power BI data model

• The DateTime data type is usually not needed, unless you are specifically using the Time component
➢ If you really need Time, try splitting Date & Time into
Knowledge Check

1. What is a data model in the context of Power BI?

• A data model is a collection of tables and relationships

2. What are some advantages of a star schema over a flat or denormalized model?
• Dimension tables save space by reducing the amount of data that needs to be repeated over and
over in every row
• Relationships between tables can be leveraged for more complex measures

3. How might you improve the performance of a Power BI model?

• Try using a star schema instead of a flat or denormalized model
• Remove unnecessary columns
• Set appropriate data types
Break
Lab 1
Section C
Data Storage in Power BI
Data Mode Types in Power BI
How can I tell what Data Model Type I have?
Connection: Live Connect
Choosing storage mode: LiveConnect
Connection: DirectQuery to Relational Source
Import Mode

- Most widely used connection and the default type when

connecting to most sources.

- The connection will ingest/pull all the data from the source and
make it a part of the PBI
Choosing storage mode: Import vs DirectQuery
Best Practices
Data Modeling

An inefficient model can completely slow down a report, even with very small data
volumes

GOALS:

• Make the model as small as possible

• Schema supports the analysis

• Relationships are built purposefully and thoughtfully

Move calculations to the source
Scenario
• Many DAX calculated columns with high cardinality

Why is it undesired?
• Calculated columns don’t compress as well as physical columns

Proposed Solution
• Perform calc in Power Query, ideally push down
Remove unused tables and columns
Scenario
• Model contains tables/columns that are not used for reporting/analysis or
calculations

Why is it undesired?
• Increases model size
• Increases time to load into memory
• Increases refresh time
• May affect usability
Avoid high precision/cardinality columns
Scenario
• Model contains columns at a higher precision than needed for analysis e.g. datetime
in milliseconds, weight to 6 decimal places
• Model contains columns that are highly unique

Why is it undesired?
• Less compression with high precision/cardinality
• Increases time to load into memory
• Increases refresh time

Proposed Solution
• Remove if not needed
• Reduce precision
• Split datetime into date and time
Use integers instead of strings
Why is it undesired?
• Strings use dictionary encoding, integers use run length encoding which is more
efficient

Proposed Solution
• Check data types and set to integer if known to be numerical
Be careful with bi-directional relationships
Scenario
• Most relationships in the model are set to bi-
directional

Why is it undesired?
• Applying filters/slicers traverses many
relationships and can be slower
• Some filter chains unlikely to add business
value

Proposed Solution
• Only use bi-di where the business scenario
requires it
Set Default Summarization
Scenario
• Numeric columns in model that are purely
informational (e.g. Account ID)
• Default summarization is Sum

Why is it undesired?
• Power BI will try to sum the number when
dropped into visuals.
• Detailed tables/matrixes can be slower

Proposed Solution
• Set the default summarization to None
Q&A