MICROSOFT

POWER BI

DESKTOP
ETL (EXTRACT, TRANSFORM, LOAD)

Grab / Fetch the data from a source : Apply some transformations to it & Load / Save the data to be used in
CSV, Excel, Database, Data Lake etc. clean it up visualizations!
ETL – PowerBI Terminology

Grab / Fetch the data from a source : Apply some transformations to it & Load / Save the data to be used in
CSV, Excel, Database, Data Lake etc. clean it up visualizations!
ETL – PowerBI Lifecycle

Used to get the data into PowerBI

Used to Transform the Data & Push it out to the Data Model

Used to Model & Arrange the tables – define relationships & push it
Ahead for visualization (Model View)

Used to create beautiful viz, dashboards etc. (Report View)

Power Query

• Data Connectivity & Preparation engine created by Microsoft – ETL

• No coding needed, makes transformations a breeze.
• Learn once and use across multiple products – PowerBI and Excel.

ADLS

Text/CSV

Excel

SQL Database
Normalization

• The process of organizing various tables & establishing relationships between them.
• Don’t have 1 huge table, split it into multiple tables.
• Helps to reduce redundancy and manageability.

Book ID Title Author Author Email

1 "Book 1" "Author A" "authorA@[Link]"

2 "Book 2" "Author A" "authorA@[Link]"

3 "Book 3" "Author B" "authorB@[Link]"

Issues with this structure

• Author information is being duplicated each time a new book is launched.

• Updating author information? Can potentially lead to inconsistencies + wasted storage space.

Book ID Title Author Author Email

1 "Book 1" "Author A" "authorA@[Link]"

2 "Book 2" "Author A" "authorA@[Link]"

3 "Book 3" "Author B" "authorB@[Link]"

Issues with this structure

• Author information is being duplicated each time a new book is launched.

• Updating author information? Can potentially lead to inconsistencies + wasted storage space.

Book ID Title Author Author Email

1 "Book 1" "Author A" "authorA123@[Link]"

2 "Book 2" "Author A" "authorA@[Link]"

3 "Book 3" "Author B" "authorB@[Link]"

Improving this structure

• Author information is being duplicated each time a new book is launched.

• Updating author information? Can potentially lead to inconsistencies + wasted storage space.

Author ID Author Author Email Book ID Title Author ID

1 "Book 1" 1
1 "Author A" "authorA@[Link]"
Relationship
2 "Book 2" 1

2 "Author B" "authorB@[Link]"

3 "Book 3" 2

Authors Books
Improving this structure

• Author information is being duplicated each time a new book is launched.

• Updating author information? Can potentially lead to inconsistencies + wasted storage space.

Author ID Author Author Email Book ID Title Author ID

1 "Book 1" 1
1 "Author A" "authorA123@[Link]"
Relationship
2 "Book 2" 1

2 "Author B" "authorB@[Link]"

3 "Book 3" 2

Authors Books
PRIMARY KEYS (PK)

¡ A unique identi[er for each row in the table

¡ Like our [ngerprint – Uniquely identi[es each row

in a table!

¡ E.g. – Your country’s Social Insurance Number /

National Identi[er

¡ Imagine how easy search and retrieval becomes

– Name vs ISBN
PRIMARY KEYS (PK) - IMPORTANCE

¡ Uniqueness – No two rows in the table can have

the same primary key.

¡ Identification – Use the PK to locate info. About a

certain record easily. E.g. – Book

¡ No NULL values – A PK value cannot be empty

for any row!

PRIMARY KEYS (PK) - IMPORTANCE

Author ID Author Author Email

1 "Author A" "authorA123@[Link]"

2 "Author B" "authorB@[Link]"

FOREIGN KEYS (FK)

¡ Enables two tables to talk to each other – Parent:

Child relationship.

¡ Helps to establish relationships!

¡ A table can have multiple FKs but only one PK.

¡ Prevents invalid data from being inserted into the

FK Column!
FOREIGN KEYS (FK)

Author ID (PK) Author Author Email Book ID Title Author ID (FK)

1 "Book 1" 1
1 "Author A" "authorA123@[Link]"

Relationship
2 "Book 2" 1

2 "Author B" "authorB@[Link]"

3 "Book 3" 2

Authors Books
Fact and Dimension Tables

• A way of organizing and creating tables.

• Fact Table – The central table & contains quantitative (numeric) information. E.g. – Sales, Profit etc.
• Can be aggregated & helps to answer business questions.
• They often have a FK relationship to Dimension Tables.

• Dimension Tables – Contain descriptive attributes that provide extra information about the data in the fact table.
• Contain textual/categorical data that provides context to facts.
 Fact and Dimension Tables

ProductID (PK) ProductName Category Manufacturer

101 Laptop Electronics ABC Electronics

Dimension
Table 102 Smartphone Electronics XYZ Tech

103 Desk Chair Furniture Comfort Co.

OrderID ProductID (FK) CustomerID QuantitySold TotalAmount OrderDate

1 101 201 3 $150.00 2023-01-15

2 102 202 2 $75.00 2023-02-01

Fact Table
3 103 203 1 $30.00 2023-02-10

4 101 204 5 $250.00 2023-03-05

Star Schema & Snowflake Schema

• Now that we know about fact tables & dimension tables, how we connect them is the
next question.

• This is where Star & Snowflake schema come into the picture!
Star Schema – Looks like a Star! One connection from all dimension tables to the fact table!

ProductID ProductName Category Manufacturer CustomerID CustomerName Country

ABC 201 John Doe USA

101 Laptop Electronics
Electronics
202 Jane Smith Canada
102 Smartphone Electronics XYZ Tech
203 Bob Johnson UK

103 Desk Chair Furniture Comfort Co. 204 Emily White Australia

OrderID ProductID CustomerID QuantitySold TotalAmount OrderDate

1 101 201 3 $150.00 2023-01-15

2 102 202 2 $75.00 2023-02-01

3 103 203 1 $30.00 2023-02-10

4 101 204 5 $250.00 2023-03-05

Star Schema – Looks like a Star! One connection from all dimension tables to the fact table!

ProductID ProductName Category Manufacturer CustomerID CustomerName Country

ABC 201 John Doe USA

101 Laptop Electronics
Electronics
202 Jane Smith Canada
102 Smartphone Electronics XYZ Tech
203 Bob Johnson UK

103 Desk Chair Furniture Comfort Co. 204 Emily White Australia

OrderID ProductID CustomerID QuantitySold TotalAmount OrderDate

1 101 201 3 $150.00 2023-01-15

2 102 202 2 $75.00 2023-02-01

3 103 203 1 $30.00 2023-02-10

4 101 204 5 $250.00 2023-03-05

 Star Schema – One connection from all dimension tables to the fact table!

CustomerID CustomerName Country

ProductID ProductName Category Manufacturer
201 John Doe USA
ABC
101 Laptop Electronics
Electronics
202 Jane Smith Canada

102 Smartphone Electronics XYZ Tech

203 Bob Johnson UK

103 Desk Chair Furniture Comfort Co. 204 Emily White Australia

OrderID ProductID CustomerID QuantitySold TotalAmount OrderDate

1 101 201 3 $150.00 2023-01-15

2 102 202 2 $75.00 2023-02-01

3 103 203 1 $30.00 2023-02-10

4 101 204 5 $250.00 2023-03-05

 Snowflake Schema – Looks like a snowflake! Multiple dimension tables can be connected to create a hierarchy.

Manufacturer ID Name Address

Manufacturer
ProductID ProductName Category CustomerID CustomerName Country
ID
1 ABC KKK
201 John Doe USA
101 Laptop Electronics 1

202 Jane Smith Canada

2 DEF LLL 102 Smartphone Electronics 2
203 Bob Johnson UK

103 Desk Chair Furniture 3

204 Emily White Australia
3 XYZ MMM

OrderID ProductID CustomerID QuantitySold TotalAmount OrderDate

1 101 201 3 $150.00 2023-01-15

2 102 202 2 $75.00 2023-02-01

3 103 203 1 $30.00 2023-02-10

4 101 204 5 $250.00 2023-03-05

Joins.

• Combining two (or more) tables two create a single table.

• Information may not lie in one single table – Normalized.
• 4 main types: Left, Inner, Right, and Outer.

• Inner – Keep only matching rows.

• Left – Preserve left table and anything that matches right table.
• Right – Preserve right table and anything that matches left table.
• Outer – Preserve everything.
Cardinality.

• Indicates how many rows in one table correspond to how many rows in another table.

• Can be 1:1 (One to One), 1:* (One to Many) , *:* (Many to Many)
Cardinality – 1:1 (One to One).

• In a 1:1 relationship, each row in the first table is related to EXACTLY one row in the second table, and vice-
versa.

EmployeeID Name DepartmentID DepartmentID DepartmentName

1 Alice 101 101 HR

2 Bob 102 102 Finance

3 Charlie 103 103 IT

Cardinality – 1:1 (One to One).

• In a 1:1 relationship, each row in the first table is related to EXACTLY one row in the second table, and vice-
versa.

EmployeeID Name DepartmentID DepartmentName

1 Alice 101 HR

2 Bob 102 Finance

3 Charlie 103 IT
Cardinality – 1:* (One to Many).

• In a 1:* relationship, each row in the first table can be related to MULTIPLE rows in the second table. However,
each row in the second table is related to only ONE row in the first table.

OrderID CustomerID Product

CustomerID Name Email

101 1 Widget A
1 John john@[Link]
102 1 Widget B

2 Jane jane@[Link]
103 2 Widget C

Customers Orders
Cardinality – * : * (Many to Many)

• In a *:* relationship, each row in the first table can be related to MULTIPLE rows in the second table and vice-
versa.

State Type Sales State City Population (m)

CA Internet 60 CA Los Angeles 4

CA Store 80 CA San Fransisco 0.9

TX Store 400 New York New York 8.5

Star Schema – Looks like a Star! One connection from all dimension tables to the fact table!

ProductID ProductName Category Manufacturer CustomerID CustomerName Country

ABC 201 John Doe USA

101 Laptop Electronics
Electronics
202 Jane Smith Canada
102 Smartphone Electronics XYZ Tech
203 Bob Johnson UK

103 Desk Chair Furniture Comfort Co. 204 Emily White Australia

OrderID ProductID CustomerID QuantitySold TotalAmount OrderDate

1 101 201 3 $150.00 2023-01-15

2 102 202 2 $75.00 2023-02-01

3 103 203 1 $30.00 2023-02-10

4 101 201 5 $250.00 2023-03-05

PRIVACY LEVELS
¡ Privacy levels in Power BI control how data from different sources is combined, helping to prevent unintended data exposure
during query operations.

¡ 3 Types – Public, Private, Organizational

Level Description Examples

Private Highly sensitive data. Never shared. Excel with salaries, HR files

Internal-use data within company

Organizational SharePoint, SQL Server
boundaries.

Non-sensitive, safe for external

Public Web APIs, Wikipedia, public files
access.
WHY PRIVACY LEVELS MATTER?

¡ It may generate queries to public APIs based on private data

¡ This leads to indirect data leaks (e.g., values from your private Excel affecting public API calls)

¡ Example: [Link]("[Link] & [Currency])

Scenario Combining:

• Private: Excel file with employee salaries and currencies • Public: Web API for exchange rates
WHY PRIVACY LEVELS MATTER?

¡ Block or isolate query steps that might expose private data

¡ Prevent Power BI from generating outbound requests driven by private info

¡ Maintain trust boundaries between data sources

BEST PRACTICES:

[Link]

✅ Set data sources to the correct privacy level

✅ Avoid using private data in dynamic web requests
✅ Use “Organizational” for internal trusted sources
⚠ Be cautious with Fast Combine or disabling privacy checks
DIRECTQUERY VS. IMPORT

Power BI offers two primary modes for connecting

to data sources:

1. Import Mode: Data is imported and stored within

Power BI, allowing for high-performance querying
using the in-memory VertiPaq engine.

2. DirectQuery Mode: Data remains in the source

system; Power BI queries the data in real-time
upon each interaction.
DIRECT QUERY VS. IMPORT
Feature Import Mode DirectQuery Mode

Data remains in the source; Power BI

Data Storage Data is copied and stored within Power BI.
queries it in real-time.

High performance due to in-memory Performance depends on the source

Performance
processing. system and network latency.

Always displays the most current data from

Data Freshness Data reflects the last scheduled refresh.
the source.

Full support for complex transformations, Limited support; some DAX functions and
Modeling Flexibility
DAX functions, and calculated columns. transformations are restricted.

Larger, as data is stored within the Power Smaller, since data isn't stored within Power
File Size
BI file. BI.

Needed for scheduled refreshes from on- Required for accessing on-premises data
Gateway Requirement
premises sources. sources in real-time.

Requires an active connection to the data

Offline Access Reports can be accessed offline.
source.
IMPORT

Use Import Mode When:

dd/mm/yy hh:mm:ss

¡ You require high-performance reports with fast

response times. Your data doesn't change
frequently, and periodic refreshes suffice. Copy of data

¡ You need complex data modeling and

transformations within Power BI.

¡ Working with small to medium-sized datasets.

DIRECTQUERY

Use DirectQuery Mode When:

¡ Real-time or near real-time data is crucial for your

reports.
Passthrough

¡ You're dealing with large datasets that are impractical

to import.

¡ Data security policies mandate that data remains at

the source. You need to minimize data duplication
and storage within Power BI.
LOGICAL FLOW

Import Import

Composite Dual

DirectQuery DirectQuery

Connectivity Mode Storage Mode

COMPOSITE MODELS

Power BI supports Composite Models, allowing you to combine

Import and DirectQuery modes within the same report.
This hybrid approach lets you:

¡ Import stable, less frequently changing data for performance.

¡ Use DirectQuery for real-time data needs. Create relationships
between imported and DirectQuery tables.
¡ This flexibility enables optimized performance while ensuring up-to-
date data where necessary.
¡ Tip: For Composite models, use Import for Aggregated tables, and
DirectQuery for Fact tables!
DUAL STORAGE MODE

In Power BI, Dual Storage Mode is a feature that allows a table to behave both as Import and DirectQuery, depending on
how it's used in your report.

💡 In simple terms: Dual mode gives you the performance benebts of Import mode and the real-time access of
DirectQuery, intelligently switching between the two as needed.

⚙ How Dual Mode Works

¡ When a Dual table is used with other Import tables: It behaves as an Import table (fast, in-memory).

¡ When used with DirectQuery tables: It behaves as a DirectQuery table (real-time).

¡ Power BI automatically decides the best mode at query time.

UNDERSTANDING ERRORS IN POWER QUERY

Types of Errors

Step-Level Errors: Prevent the entire query from loading.

Example: Referencing a non-existent column.
Solution: Review the error message and adjust the query step accordingly.

Cell-Level Errors: Occur in specific cells but allow the query to load.
Example: Data type conversion issues, such as converting 'NA' to a number.
Solution: Handle errors using Power Query's built-in functions.

Common Error Scenarios:

• [Link]: Occurs when the data source is inaccessible or moved.
Solution: Update the file path or credentials to access the data source.
• [Link]: Triggered by referencing missing columns or invalid operations.
Solution: Ensure all referenced columns exist and operations are valid. Source: [Link]
HANDLING ERRORS

Built-in Error Handling Options:

1) Remove Errors: Eliminate rows with errors.

• Use when: Erroneous data is not needed.

2) Replace Errors: Substitute errors with a default value.

• Use when: A fallback value is appropriate.

3) Keep Errors: Isolate and review error rows.

• Use when: Analyzing the cause of errors.

AUTO-DATE/TIME

When Auto Date/Time is enabled, Power BI:

¡ Creates an internal date table behind the scenes for each date field in your model.

¡ Automatically allows time intelligence functions (like YTD, MTD, QTD, etc.) without
creating a custom calendar.

¡ Enables drill-down in visuals (year → quarter → month → day).

¡ It applies only to columns with Date or Date/Time data types in models using Import
mode. The column also shouldn’t be on the “Many” side of the relationship.
HOW DOES IT WORK?

Structure & Creation

¡ Each Auto Date/Time table is a calculated table generated

using the DAX CALENDAR function.

¡ It includes seven columns:

Date, Day, MonthNo, Month, QuarterNo, Quarter, and Year.

¡ The table spans full calendar years covering all values in the
associated date column.

Behavior & Functionality

[Link]

¡ Power BI automatically creates a relationship between the

Auto Date/Time table's Date column and the model’s date
column.
HOW DOES IT WORK?
Refresh & Scope

¡ When the dataset refreshes, Auto Date/Time tables are also

refreshed to reflect the latest date values.

¡ For example, dates from March 20, 2016 to October 23, 2019
would result in 1,461 rows spanning all days from Jan 1, 2016
to Dec 31, 2019.

Limitations

¡ Permanently hidden from the Fields pane, Model view, and

Table view.

¡ Cannot be referenced directly in DAX or accessed via tools

like Analyze in Excel or external designers.

¡ Only usable within Power BI visuals and time intelligence

calculations. [Link]
PROS

Advantage Description

🔧 Quick Setup No need to create and relate a date table - works out of the box

Enables DAX functions like TOTALYTD, SAMEPERIODLASTYEAR,

⌚ Time Intelligence Support
etc.

📆 Auto Hierarchy Automatically creates a hierarchy: Year > Quarter > Month > Day

📊 Easy Drill-Down Hierarchies allow intuitive visual interactions without extra setup

🧠 Good for Beginners Helps users unfamiliar with DAX or calendar modeling
CONS

Limitation Description

Creates a hidden date table for every date column, which can
📈 Performance Overhead
slow down large models

Cannot change fiscal year settings, holidays, weekend logic, or

🧭 Limited Customization
add columns like week number

Internally managed — not visible in model view, which makes

🔍 Hidden Tables
debugging harder

Multiple date tables can exist for multiple date columns, bloating
🔁 Duplication
the model

You can't use one auto-generated date table across multiple

🔄 Not Reusable
tables/columns

📉 Doesn't Work in DirectQuery Only available in Import mode models

WHEN TO USE IT? ✅
¡ Small or personal datasets

¡ Quick prototypes or ad-hoc analysis

¡ When you have only 1–2 date columns

¡ If you're not ready to build or manage a date table

WHEN TO AVOID IT? ❌

¡ In enterprise-grade models with many date fields

[Link]
¡ When you need a custom calendar (fiscal year, academic year, etc.)

¡ When optimizing for performance or file size

¡ If you're using DirectQuery or composite models

¡ To avoid redundancy and manage relationships manually

BEST PRACTICE
Aspect Auto Date/Time Custom Date Table

Setup Automatic Manual

For most robust models:

May degrade with

Performance Optimized
1. Create a custom Date table in Power BI or many fields
import one from Excel/SQL.
Customization None Full control

2. Mark it as a Date Table: Modeling → Mark

as Date Table. Reusability No Yes

3. Use this for all time intelligence to improve DirectQuery Support ❌ ✅

consistency and performance.

Use Case Small / Simple Medium to Complex

WHY SHOULD WE CREATE A COMMON DATE TABLE?

Reason Explanation

Functions
Time Intelligence Functions like YTD, MTD, SAMEPERIODLASTYEAR require a
proper Date table.
Enables unified slicers across multiple date fields (e.g.,
Consistent Filtering
Order, Ship, Delivery).

Uniform Year > Quarter > Month > Day structure

Reusable Date Hierarchy
improves UX.

Custom Business Logic Add fiscal periods, weekends, holidays, sort orders, etc.

Avoids Auto Date/Time feature bloat; keeps model

Better Performance
optimized, smaller model size, faster refresh.

Activate inactive relationships for flexible time analysis

Enables Advanced DAX
using USERELATIONSHIP().
FILTER CONTEXT

RegionID RegionName Manager Year

R1 North Alice
CY2018
R2 South Bob

CY2019
StoreID StoreName RegionID City

CY2020
1 Elm St R1 Chicago

2 Pine Rd R2 Austin CY2021

3 Oak Ave R1 Detroit

StoreID Year Revenue ( $K )

1 CY2019 85

1 CY2020 100
Total revenue in $220K
2 CY2020 150
CY2020 for the
3 CY2020 120
North region?
2 CY2019 90
 WHAT IS DAX?

¡ Definition: DAX (Data Analysis Expressions) is a formula language used in Power BI to create custom
calculations and aggregations for data analysis.

¡ Purpose: Enables users to define measures, calculated columns, and tables to enhance data models and
generate insights.

¡ Key Uses:
o Perform complex calculations (e.g., year-over-year growth, running totals).

o Create dynamic reports and dashboards.

o Manipulate and analyze data beyond basic visuals.

¡ Components:
o Measures: Calculations for summarizing data (e.g., total sales).

o Calculated Columns: New columns derived from existing data.

o Calculated Tables: Tables created using DAX formulas.

¡ Example: Total Sales = SUM(Sales[Amount]) (Calculates the sum of the Amount column in the Sales table).
 WHY USE DAX?

¡ Power and Flexibility: Allows advanced analytics not possible with standard Power BI features.

¡ Context Awareness:
o Row Context: Calculations applied to individual rows (e.g., in calculated columns).

o Filter Context: Dynamic filtering based on report selections (e.g., slicers, visuals).

¡ Common Functions:
o Aggregation: SUM, AVERAGE, COUNT.

o Time Intelligence: DATEADD, TOTALYTD for time-based calculations.

o Logical: IF, SWITCH for conditional logic.

 IMPLICIT MEASURES

¡ Auto-generated by Power BI when you drag a field (like Sales) into the
Values area of a visual.

¡ Only basic aggregations allowed (SUM, COUNT, AVERAGE, etc.).

¡ Can't be reused in other visuals or customized further.

¡ Created on the fly and exist only within the visual they're used in. Unlike
calculated columns they don’t take storage space in the model!

¡ No DAX formula involved - Power BI handles it for you.

¡ Ideal for quick ad-hoc analysis.

WHAT DOES CAN’T BE CUSTOMIZED MEAN?

¡ It's like writing a quick calculation on a sticky note for one use - you can't save or
reference it elsewhere.

¡ Power BI decides the aggregation type (SUM, COUNT, etc.) automatically based
on the data type.

¡ You can't add filters, conditions, or change logic in an implicit measure.

¡ No way to say “SUM only for the year 2024” or “SUM where Product Category =
‘Electronics’” unless you turn it into an explicit measure using DAX.
EXPLICIT MEASURES

¡ Created manually using DAX (Data Analysis Expressions).

¡ Reusable across multiple visuals, pages, and reports.

¡ Support advanced logic and customized calculations (e.g.,

using CALCULATE, FILTER, IF, etc.).

¡ Named by the user, allowing better report readability and documentation.

¡ Appear with a calculator icon in the Fields pane.

 AUTO DATE-TIME
¡ In Power BI, hidden date tables are automatically created by the Auto Date/Time feature. While convenient for beginners, they can cause
problems in larger or more complex models.

🧱 What Are Hidden Date Tables?

When Auto Date/Time is enabled:

¡ Power BI automatically generates a hidden date table behind the scenes for every Date or Date/Time column in your data model.

¡ These tables are not visible in the Fields pane or in the Data Model section.

¡ Each one includes a full set of time intelligence columns (Year, Month, Quarter, etc.).

🧩 Example

¡ If you load a table with a column OrderDate, Power BI silently creates:

¡ A hidden table like OrderDate (auto) with columns like Year, Month, etc.

¡ A relationship between OrderDate and its auto-generated hidden date table.

¡ A date hierarchy in your Fields pane: OrderDate > Year > Quarter > Month > Day.
[Link]
TIME INTELLIGENCE MEASURES

Performance To Date Running Totals & Another Period

• DATESWTD • DATESINPERIOD

• DATESMTD • DATEADD

• DATESQTD • SAMEPERIODLASTYEAR

• DATESYTD

• NEXTDAY

• TOTALWTD • NEXTMONTH

• TOTALMTD • NEXTYEAR

• TOTALQTD • PREVIOUSMONTH

• TOTALYTD • PREVIOUSQUARTER
SEMI – ADDITIVE MEASURES

• In DAX, measures are typically additive - meaning they can be summed across all dimensions (e.g., sales
amounts add up across product category, sub-category, dates, and Continents etc).

• However, semi-additive measures (often abbreviated as "semi-additive" or "SEM" in shorthand) behave

differently: they add up across some dimensions (like products or regions) but not across others, especially
time-based dimensions like dates or periods.

This is common for snapshot data, such as:

1. Inventory/stock levels: The total stock across warehouses adds up, but summing stock over multiple days
doesn't make sense—instead, you want the stock at the end of the period (e.g., closing balance).

2. Bank account balances: Additive across accounts, but shows the balance as of the last date in a time range.

3. Headcount/HR metrics: Adds up across departments, but for a quarter, you report the ending headcount, not
the sum of monthly headcounts.

Summing semi-additive measures over time would produce misleading results. Instead, DAX uses functions to
"snapshot" the value at the start, end, or average of a period.

Key Concepts

1. Fully Additive: Sum across all dimensions (e.g., Total Sales = SUM(Sales[Amount])).
2. Semi-Additive: Sum across some dimensions (e.g., geography), but use special logic for time (e.g., last non-
empty value).