Tag: Power BI

Improve Performance by Reducing Granularity (PL-300 Exam Prep)

This post is a part of the PL-300: Microsoft Power BI Data Analyst Exam Prep Hub; and this topic falls under these sections:
Model the data (25–30%)
--> Optimize model performance
--> Improve Performance by Reducing Granularity


Note that there are 10 practice questions (with answers and explanations) at the end of each topic. Also, there are 2 practice tests with 60 questions each available on the hub below all the exam topics.

Overview

Reducing granularity is a key performance-optimization technique in Power BI. It involves lowering the level of detail stored in tables—particularly fact tables—to include only the level of detail required for reporting and analysis. Excessively granular data increases model size, slows refreshes, consumes more memory, and can negatively affect visual and DAX query performance.

For the PL-300 exam, you should understand when high granularity is harmful, how to reduce it, and the trade-offs involved.


What Is Granularity?

Granularity refers to the level of detail in a dataset.

Examples:

  • High granularity: One row per transaction, per second, per sensor reading
  • Lower granularity: One row per day, per customer, per product

In Power BI models, lower granularity usually results in better performance, provided it still meets business requirements.


Why Reducing Granularity Improves Performance

Reducing granularity can:

  • Decrease model size
  • Improve query execution speed
  • Reduce memory consumption
  • Speed up dataset refresh
  • Improve visual responsiveness

Power BI’s VertiPaq engine performs best with fewer rows and lower cardinality.


Common Scenarios Where Granularity Is Too High

PL-300 scenarios often test your ability to recognize these situations:

  • Transaction-level sales data when only daily or monthly trends are required
  • IoT or log data captured at seconds or milliseconds
  • Fact tables containing unnecessary identifiers (e.g., transaction IDs not used for analysis)
  • Snapshot tables with excessive historical detail that is never reported on

Techniques to Reduce Granularity

1. Aggregate Data During Data Preparation

Use Power Query to group rows before loading:

Examples:

  • Aggregate sales by Date + Product
  • Aggregate events by Day + Category
  • Pre-calculate totals, averages, or counts

This is often the best practice approach.


2. Remove Unnecessary Transaction-Level Tables

If reports never analyze individual transactions:

  • Eliminate transaction tables
  • Replace them with aggregated fact tables

3. Use Aggregation Tables (Import Mode)

Create:

  • A summary table (lower granularity)
  • A detail table (higher granularity, optional)

Power BI can automatically route queries to the aggregated table when possible.

This approach is frequently tested conceptually in PL-300.


4. Reduce Date/Time Granularity

Instead of:

  • DateTime with hours, minutes, seconds

Use:

  • Date only
  • Pre-derived columns (Year, Month)

This reduces cardinality significantly.


5. Eliminate Unused Detail Columns

Columns that increase granularity unnecessarily:

  • Transaction IDs
  • GUIDs
  • Row-level timestamps

If they are not used in visuals, relationships, or DAX, they should be removed.


Impact on the Data Model

AspectEffect
Model sizeSmaller
Refresh timeFaster
DAX performanceImproved
Visual load timeFaster
Memory usageLower

However:

  • Over-aggregation can limit analytical flexibility
  • Drill-through and detailed visuals may no longer be possible

Common Mistakes (Often Tested)

  • Keeping transaction-level data “just in case”
  • Reducing granularity after building complex DAX
  • Aggregating data in DAX instead of Power Query
  • Removing detail needed for drill-through or tooltips
  • Aggregating dimensions instead of facts

Best Practices for PL-300 Candidates

  • Optimize before writing complex DAX
  • Aggregate data in Power Query, not in measures
  • Match granularity to actual reporting needs
  • Use aggregation tables when both detail and performance are required
  • Validate that reports still answer business questions after aggregation

Exam Tips

You may be asked:

  • Which action improves performance the most?
  • Why a model is slow despite simple visuals
  • When aggregation tables are appropriate
  • How to reduce model size without changing visuals

The correct answer often involves reducing fact table granularity, not adding more DAX.


Practice Questions

Go to the Practice Exam Questions for this topic.

Improve Performance by Identifying and Removing Unnecessary Rows and Columns (PL-300 Exam Prep)

This post is a part of the PL-300: Microsoft Power BI Data Analyst Exam Prep Hub; and this topic falls under these sections:
Model the data (25–30%)
--> Optimize model performance
--> Removing Unnecessary Rows and Columns


Note that there are 10 practice questions (with answers and explanations) at the end of each topic. Also, there are 2 practice tests with 60 questions each available on the hub below all the exam topics.

Optimizing model performance is a core responsibility of a Power BI Data Analyst and a recurring theme on the PL-300 exam. One of the most effective—and often overlooked—ways to improve performance is by removing unnecessary rows and columns from the data model. A lean model consumes less memory, refreshes faster, and delivers better query performance for reports and visuals.


Why This Topic Matters for PL-300

Power BI uses an in-memory columnar storage engine (VertiPaq). Every column and every row loaded into the model increases memory usage and impacts performance. The PL-300 exam expects candidates to understand:

  • How excess data negatively affects model size and performance
  • When and where to remove unneeded data
  • Which tools and techniques to use to optimize the model efficiently

This topic directly supports real-world scalability and aligns with Microsoft’s recommended best practices.


Identifying Unnecessary Columns

Common Examples of Unnecessary Columns

  • Surrogate keys not used in relationships
  • Audit columns (CreatedDate, ModifiedBy, LoadTimestamp)
  • Technical or system fields from source systems
  • Duplicate descriptive columns (e.g., both CategoryName and CategoryDescription when only one is used)
  • High-cardinality text columns not used in visuals, filters, or calculations

Why Columns Hurt Performance

  • Each column increases model memory footprint
  • High-cardinality columns compress poorly
  • Unused columns still consume memory even if hidden

PL-300 Tip: Hidden columns still impact performance. Removing them is better than hiding them.


Identifying Unnecessary Rows

Common Examples of Unnecessary Rows

  • Historical data not required for analysis (e.g., data older than 10 years)
  • Test or placeholder records
  • Inactive or obsolete entities (e.g., discontinued products)
  • Duplicate records due to poor source filtering

Why Rows Hurt Performance

  • More rows increase storage size and query scan time
  • Large fact tables slow down DAX calculations
  • Visuals must process more data than needed

Where to Remove Rows and Columns (Exam-Relevant)

Power Query (Preferred Approach)

Removing data before it reaches the model is the most effective strategy.

Best practices:

  • Remove columns using Remove Columns
  • Filter rows using Filter Rows
  • Apply logic early in the query to enable query folding

Why Power Query Matters on the Exam

  • Reduces data volume at refresh time
  • Improves refresh speed and memory usage
  • Often allows source systems to do the filtering

DAX (Less Preferred)

Using DAX to filter data (e.g., calculated tables or measures) happens after data is loaded, so it does not reduce model size.

PL-300 Rule of Thumb:
If your goal is performance optimization, remove data in Power Query—not DAX.


Star Schema and Performance Optimization

Unnecessary rows and columns often come from poor data modeling.

Optimization Best Practices

  • Keep fact tables narrow (only numeric and key columns)
  • Keep dimension tables descriptive, but minimal
  • Avoid denormalized “wide” tables
  • Remove columns not used in:
    • Relationships
    • Measures
    • Visuals
    • Filters or slicers

Tools to Help Identify Performance Issues

Model View

  • Inspect table sizes and column usage
  • Identify wide or bloated tables

Performance Analyzer

  • Helps identify visuals impacted by large datasets

VertiPaq Analyzer (Advanced / Optional)

  • Analyzes column cardinality and compression
  • Not required to use, but understanding its purpose is helpful

Exam Scenarios to Expect

You may be asked to:

  • Choose the best way to reduce model size
  • Identify why a model is slow or large
  • Select the correct optimization technique
  • Decide where data should be removed (Power Query vs DAX)

Example phrasing:

“What should you do to reduce memory usage and improve report performance?”

Correct answer often involves:

  • Removing unnecessary columns
  • Filtering rows in Power Query
  • Reducing cardinality

Key Takeaways for PL-300

  • Smaller models perform better
  • Remove unused columns and rows
  • Prefer Power Query over DAX for data reduction
  • Hidden columns still consume memory
  • This is a foundational performance optimization skill tested on the exam

Practice Questions

Go to the Practice Exam Questions for this topic.

Create Calculation Groups (PL-300 Exam Prep)

This post is a part of the PL-300: Microsoft Power BI Data Analyst Exam Prep Hub; and this topic falls under these sections:
Model the data (25–30%)
--> Create model calculations by using DAX
--> Create Calculation Groups


Note that there are 10 practice questions (with answers and explanations) at the end of each topic. Also, there are 2 practice tests with 60 questions each available on the hub below all the exam topics.

Overview

Calculation groups are an advanced DAX modeling feature used to reduce measure duplication and apply consistent calculation logic (such as time intelligence or variance analysis) across multiple measures.

For the PL-300 exam, you are not expected to be an expert author, but you must understand:

  • What calculation groups are
  • Why and when they are used
  • Their impact on the data model
  • Common limitations and exam pitfalls

What Is a Calculation Group?

A calculation group is a special table in the data model that contains calculation items, each defining a DAX expression that modifies how measures are evaluated.

Instead of creating multiple similar measures like:

  • Sales YTD
  • Sales MTD
  • Sales YoY

You create one base measure (e.g., [Total Sales]) and apply different calculation items dynamically.


Key Benefits of Calculation Groups

  • ✔ Reduce the number of measures in the model
  • ✔ Enforce consistent calculation logic
  • ✔ Simplify maintenance and updates
  • ✔ Improve model organization
  • ✔ Enable advanced analytical patterns

Exam Insight: Microsoft emphasizes model simplicity and maintainability—calculation groups directly support both.


Where Calculation Groups Are Created

Calculation groups cannot be created in Power BI Desktop.

They are created using:

  • Tabular Editor (external tool)
    • Tabular Editor 2 (free)
    • Tabular Editor 3 (paid)

Once created, they appear as a table in the model and can be used like a slicer or filter.


Structure of a Calculation Group

A calculation group contains:

  • A single column (e.g., Time Calculation)
  • Multiple calculation items (e.g., YTD, MTD, YoY)

Each calculation item uses the SELECTEDMEASURE() function.

Example calculation item:

CALCULATE(
    SELECTEDMEASURE(),
    DATESYTD('Date'[Date])
)


Common Use Cases (Exam-Relevant)

Time Intelligence

  • Year-to-Date (YTD)
  • Month-to-Date (MTD)
  • Year-over-Year (YoY)
  • Rolling averages

Variance Analysis

  • Actual vs Budget
  • Difference
  • Percent Change

Currency Conversion

  • Local currency
  • Reporting currency

Scenario Analysis

  • Actuals
  • Forecast
  • What-if scenarios

SELECTEDMEASURE(): The Core Concept

SELECTEDMEASURE() references whatever measure is currently in context.

This allows one calculation item to work across:

  • Sales
  • Profit
  • Quantity
  • Any numeric measure

PL-300 Tip: Expect conceptual questions about why SELECTEDMEASURE is required, not detailed syntax questions.


Interaction with Measures and Visuals

  • Calculation groups modify measures at query time
  • They work with:
    • Slicers
    • Matrix visuals
    • Charts
  • They do not replace measures
  • At least one base measure is always required

Calculation Precedence (Often Tested)

When multiple calculation groups exist, precedence determines order of execution.

  • Higher precedence value = evaluated first
  • Incorrect precedence can cause unexpected results

Exam questions may describe incorrect results caused by calculation group conflicts.


Impact on the Data Model

Advantages

  • Fewer measures
  • Cleaner model
  • Easier long-term maintenance

Considerations

  • Adds modeling complexity
  • Harder for beginners to understand
  • Requires external tooling
  • Can affect performance if misused

Limitations and Constraints

  • ❌ Not supported in DirectQuery for some sources
  • ❌ Not visible/editable in Power BI Desktop
  • ❌ Can confuse users unfamiliar with advanced modeling
  • ❌ Can override measure logic unexpectedly

Common Mistakes (Often Tested)

  • Creating calculation groups for simple scenarios
  • Forgetting calculation precedence
  • Overusing calculation groups instead of measures
  • Applying them where clarity is more important than reuse
  • Assuming they replace the need for measures

When NOT to Use Calculation Groups

  • Simple models with few measures
  • One-off calculations
  • Beginner-level reports
  • When report consumers need transparency

PL-300 Exam Insight: The exam often tests judgment, not just capability.


Best Practices for PL-300 Candidates

  • ✔ Use calculation groups to reduce repetitive measures
  • ✔ Keep calculation logic consistent and reusable
  • ✔ Document calculation group purpose clearly
  • ✔ Use meaningful calculation item names
  • ❌ Don’t use calculation groups just because they exist

How This Appears on the PL-300 Exam

You may be asked to:

  • Identify when calculation groups are appropriate
  • Choose between measures and calculation groups
  • Understand the role of SELECTEDMEASURE()
  • Recognize benefits and risks in a scenario
  • Identify why a model is difficult to maintain

Syntax-heavy questions are rare; scenario-based reasoning is common.


Final Takeaway

Calculation groups are a powerful but advanced modeling feature. For the PL-300 exam, focus on why and when they are used, their benefits, and their impact on maintainability and performance—not deep implementation details.


Practice Questions

Go to the Practice Exam Questions for this topic.

Configure Table and Column Properties (PL-300 Exam Prep)

This post is a part of the PL-300: Microsoft Power BI Data Analyst Exam Prep Hub; and this topic falls under these sections:
Model the data (25–30%)
--> Design and implement a data model
--> Configure Table and Column Properties


Note that there are 10 practice questions (with answers and explanations) for each section to help you solidify your knowledge of the material. Also, there are 2 practice tests with 60 questions each available on the hub below the exam topics section.

Configuring table and column properties is a critical step in designing a clean, intuitive, and performant Power BI data model. While these settings may appear cosmetic at first glance, they directly influence usability, accuracy, performance, and user experience — all of which are assessed on the PL-300: Microsoft Power BI Data Analyst exam.


Why Table and Column Properties Matter

Properly configured properties:

  • Make reports easier for business users to navigate
  • Reduce confusion and misuse of fields
  • Improve DAX readability and maintenance
  • Prevent incorrect aggregations
  • Support star schema best practices

On the exam, Microsoft frequently tests why and when to configure properties — not just where the settings are located.


Table Properties

Table Name

  • Should be descriptive and business-friendly
  • Avoid technical or source-system names

Good examples:

  • FactSales
  • DimCustomer

Poor examples:

  • tbl_sales_v2
  • Query1

Exam Tip: Clear naming improves self-service reporting.


Table Description

  • Used for documentation
  • Appears as tooltips in Power BI Service
  • Helps report consumers understand table purpose

Table Visibility (Hide/Show)

  • Hidden tables remain in the model but are not visible in the Fields pane
  • Commonly used for:
    • Bridge tables
    • Technical helper tables
    • Date tables used only for relationships

Important: Hiding does not improve performance — it only affects usability.


Column Properties

Column Name

  • Use business-friendly terminology
  • Avoid abbreviations unless widely understood
  • Remove underscores and technical prefixes

Column Description

  • Explains the meaning of the column
  • Appears as a tooltip
  • Valuable in shared datasets and Power BI Service

Data Type

Choosing the correct data type is foundational:

  • Impacts aggregation
  • Affects relationship behavior
  • Influences performance and compression

Examples:

  • Dates → Date or Date/Time
  • IDs → Whole Number or Text (depending on source)
  • Currency → Decimal Number

Default Summarization

Controls how numeric columns aggregate by default.

Common options:

  • Sum
  • Average
  • Min / Max
  • Count
  • Do not summarize

Best Practice:

  • Disable summarization for:
    • IDs
    • Keys
    • Percentages
    • Rates

Exam Insight: Misconfigured summarization is a common exam trap.


Format

Determines how values display in visuals.

Examples:

  • Currency
  • Percentage
  • Decimal places
  • Date formats

Formatting improves readability and consistency across reports.


Sort By Column

Used when a column’s natural sort order is not alphabetical.

Common use cases:

  • Month Name sorted by Month Number
  • Day Name sorted by Day of Week

PL-300 Tip: Sort By Column is frequently tested.


Column Visibility

  • Hide columns not intended for report authors
  • Common examples:
    • Surrogate keys
    • Technical IDs
    • Relationship-only columns

Special Column Properties

Data Category

Informs Power BI how to interpret data, especially for maps.

Examples:

  • City
  • Country/Region
  • Latitude / Longitude
  • URL

Correct categorization improves map accuracy and link behavior.


Summarize Across Tables

Controls whether a column can be aggregated across relationships.

  • Typically enabled for measures
  • Rarely changed for standard columns

Properties and the Star Schema

In a well-designed star schema:

  • Fact tables:
    • Numeric columns summarized
    • Foreign keys hidden
  • Dimension tables:
    • Descriptive columns visible
    • Primary keys hidden
    • Sorted attributes configured properly

These property settings reinforce proper analytical usage.


Impact on the Data Model

Correct configuration:

  • Prevents incorrect totals
  • Improves DAX clarity
  • Simplifies report authoring
  • Reduces user errors

Poor configuration leads to:

  • Summing IDs
  • Confusing field lists
  • Incorrect visual behavior
  • Increased support questions

Common Mistakes (Often Tested)

❌ Leaving default summarization on ID columns

This results in meaningless totals.


❌ Not configuring Sort By Column

Causes incorrect ordering in visuals.


❌ Exposing technical columns to report users

Leads to misuse and confusion.


❌ Using inconsistent naming conventions

Makes models hard to understand and maintain.


Best Practices for PL-300 Candidates

  • Use business-friendly names
  • Hide keys and technical columns
  • Disable summarization for non-additive values
  • Always configure Sort By Column when needed
  • Add descriptions for shared datasets
  • Validate formatting and data categories

How This Appears on the PL-300 Exam

You may encounter questions like:

  • Why are totals incorrect in a visual?
  • Why are months sorting alphabetically?
  • Which columns should be hidden from report view?
  • What property controls default aggregation?

The correct answer often involves column properties, not DAX.


Quick Decision Guide

RequirementProperty to Configure
Prevent summing IDsDefault Summarization
Correct month orderSort By Column
Improve map visualsData Category
Hide technical fieldsColumn Visibility
Improve usabilityNames & Descriptions

Final PL-300 Takeaways

  • Table and column properties shape how users interact with data
  • Defaults are rarely optimal
  • Proper configuration prevents errors before they happen
  • This topic is high-value on the exam
  • Most fixes do not require DAX

Practice Questions

Go to the Practice Exam Questions for this topic.

Configure Data Loading for Queries (PL-300 Exam Prep)

This post is a part of the PL-300: Microsoft Power BI Data Analyst Exam Prep Hub; and this topic falls under these sections:
Prepare the data (25–30%)
--> Transform and load the data
--> Configure Data Loading for Queries


Note that there are 10 practice questions (with answers and explanations) for each section to help you solidify your knowledge of the material. Also, there are 2 practice tests with 60 questions each available on the hub below the exam topics section.

Power BI doesn’t just connect to data — it decides what to load and when to load it. Configuring data loading properly ensures your model contains only the necessary data, improves performance, and aligns with business requirements.

In the context of the PL-300: Microsoft Power BI Data Analyst exam, you’ll be expected to understand how to control which queries load to the data model, use query folding where possible, and manage refresh settings appropriately.


Why Configuring Data Loading Matters

Before discussing how to configure data loading, it’s important to understand why it matters:

  • Model performance — unnecessary tables and columns consume memory and slow visuals
  • Refresh efficiency — fewer loaded objects means faster refresh
  • Manageability — only relevant data should end up in the model
  • Clarity — clean, minimal data models reduce mistakes and confusion

Power BI uses Power Query Editor as the staging area for all transformations and loading decisions.


Key Concepts

1. Enable Load vs Disable Load

Each query in Power Query has a toggle called “Enable Load” (or “Load to model”).

  • Enabled: The resulting table will load into the data model
  • Disabled: The query runs for transformations but does not create a table in the model

Common Usage:

  • Use Disable Load for staging or helper queries that feed other queries but aren’t needed as standalone tables in the model
  • Ensure only final tables are loaded into the model

2. Staging Queries

A staging query is a query used exclusively to prepare data for other queries. It should usually have Enable Load turned off so it doesn’t clutter the model.

Example:

  • A staging query cleans raw data
  • Final queries reference it
  • Only final queries load to the model

3. Query Dependencies

In Power BI Desktop, View → Query Dependencies shows a visual map of how queries relate.

  • Staging queries feed final tables
  • Ensures understandability and data lineage
  • Highlights which queries are loaded and which are not

Understanding query dependencies helps validate that:

  • Only the intended tables are loaded
  • Intermediate queries aren’t unnecessary

4. Incremental Refresh

Incremental refresh allows Power BI to refresh only new or changed data rather than the entire dataset.

Why this matters:

  • Essential for large datasets
  • Reduces refresh time and resource usage
  • Requires configuration in the Power BI Service and on tables with a date/time column

Incremental refresh is usually enabled in Table Settings with parameters like:

  • RangeStart
  • RangeEnd

These parameters determine the portion of data to refresh.


5. Query Folding

Query folding refers to the ability of Power Query to push transformations back to the source (e.g., SQL Server).

Why it matters:

  • Performance: operations happen at source
  • Large data sets benefit most

Configuration that enables query folding includes:

  • Filtering early
  • Aggregating early
  • Avoiding operations that break folding (e.g., certain custom columns)

While not strictly a “loading” setting, query folding directly affects how Power BI retrieves and loads data.


How to Configure Data Loading

In Power Query Editor

Disable Loading for Specific Queries

  1. Right-click the query
  2. Uncheck Enable Load
  3. Optional: Uncheck Include in report refresh

This prevents the query from creating a model table.


In the Data View (or Model View)

After loading:

  • Hide unnecessary columns
  • Hide unused tables from report view
  • Rename tables for clarity

Note: Hiding doesn’t remove the data — it simply declutters the field list.


Incremental Refresh Setup

To enable incremental refresh:

  1. Identify a Date/Time column
  2. Define RangeStart and RangeEnd parameters
  3. Use these parameters to filter the date column
  4. Enable Incremental Refresh in table settings

Power BI then only refreshes the relevant partition of data.


Best Practices

Load MINIMAL Necessary Tables

Avoid loading:

  • Staging queries
  • Helper queries
  • Intermediate transformations

Disable Load Early

This prevents clutter and improves refresh times.

Use Descriptive Names

Query and table names should reflect final usage (e.g., FactSales, DimProduct).

Understand Dependencies

Always validate that disabling load on a query won’t break dependent queries.

Preserve Query Folding

Design transformations that can be folded to source — especially for large data.


Common Mistakes (Often Tested)

❌ Loading staging queries into the model

This increases model size unnecessarily.

❌ Forgetting to define a key date column when setting up incremental refresh

Incremental refresh requires a proper date/time column.

❌ Breaking query folding early

Certain transformations can prevent folding and slow down refresh.

❌ Changing load settings after building relationships

Altering load settings on queries used in relationships can cause broken models.


How This Appears on the PL-300 Exam

The exam may present scenarios like:

  • A model has slow refresh times. What could you configure to improve efficiency?
  • Which queries should be loaded into the model?
  • How do staging queries affect model size?
  • When should incremental refresh be used?

Exam questions often expect you to explain the impact of loading decisions on performance and maintainability.


Quick Decision Guide

ScenarioRecommended Configuration
Helper query only used for transformationsDisable Load
Main dimensional tableEnable Load
Large historical datasetUse Incremental Refresh
Query with steps that can be pushed to sourceEnsure Query Folding

Final PL-300 Takeaways

  • Enable Load controls whether a query creates a model table
  • Disable Load for staging/helper queries
  • Incremental Refresh accelerates large dataset refresh
  • Query Folding improves performance during load
  • Validate via View Query Dependencies

Practice Questions

Go to the Practice Exam Questions for this topic.

Identify and Create Appropriate Keys for Relationships (PL-300 Exam Prep)

This post is a part of the PL-300: Microsoft Power BI Data Analyst Exam Prep Hub; and this topic falls under these sections:
Prepare the data (25–30%)
--> Transform and load the data
--> Identify and Create Appropriate Keys for Relationships


Note that there are 10 practice questions (with answers and explanations) for each section to help you solidify your knowledge of the material. Also, there are 2 practice tests with 60 questions each available on the hub below the exam topics section.

Establishing correct relationships is fundamental to building accurate, performant Power BI data models. At the core of every relationship are keys — columns that uniquely identify records and allow tables to relate correctly. For the PL-300: Microsoft Power BI Data Analyst exam, candidates must understand how to identify, create, and validate keys as part of this topic domain.


What Is a Key in Power BI?

A key is a column (or combination of columns) used to uniquely identify a row in a table and connect it to another table.

In Power BI models, keys are used to:

  • Define relationships between tables
  • Enable correct filter propagation
  • Support accurate aggregations and calculations

Common Types of Keys

Primary Key

  • A column that uniquely identifies each row in a table
  • Must be unique and non-null
  • Typically found in dimension tables

Example:
CustomerID in a Customers table


Foreign Key

  • A column that references a primary key in another table
  • Found in fact tables

Example:
CustomerID in a Sales table referencing Customers


Composite Key

  • A key made up of multiple columns
  • Used when no single column uniquely identifies a row

Example:
OrderDate + ProductID

PL-300 Tip: Power BI does not support native composite keys in relationships — you must create a combined column.


Identifying Appropriate Keys

When preparing data, always evaluate:

Uniqueness

  • The key column in the one-side of a relationship must contain unique values
  • Duplicate values cause many-to-many relationships

Completeness

  • Keys should not contain nulls
  • Nulls can break relationships and filter context

Stability

  • Keys should not change frequently
  • Avoid descriptive fields like names or emails as keys

Creating Keys in Power Query

Power Query is the preferred place to create or clean keys before loading data.

Common Techniques

Concatenate Columns

Used to create a composite key:

ProductID & "-" & StoreID

Remove Leading/Trailing Spaces

Prevents mismatches:

  • Trim
  • Clean

Change Data Types

Keys must have matching data types on both sides of a relationship.


Surrogate Keys vs Natural Keys

Natural Keys

  • Already exist in source systems
  • Business-meaningful (e.g., InvoiceNumber)

Surrogate Keys

  • Artificial keys created for modeling
  • Often integers or hashes

PL-300 Perspective:
You are more likely to consume surrogate keys than create them, but you must know why they exist and how to use them.


Keys and Star Schema Design

Power BI models should follow a star schema whenever possible:

  • Fact tables contain foreign keys
  • Dimension tables contain primary keys
  • Relationships are one-to-many

Example

  • FactSales → ProductID
  • DimProduct → ProductID (unique)

Relationship Cardinality and Keys

Keys directly determine cardinality:

CardinalityKey Requirement
One-to-manyUnique key on one side
Many-to-manyDuplicate keys on both sides
One-to-oneUnique keys on both sides

Exam Insight: One-to-many is preferred. Many-to-many often signals poor key design.


Impact on the Data Model

Poor key design can cause:

  • Incorrect totals
  • Broken slicers
  • Ambiguous filter paths
  • Performance degradation

Well-designed keys enable:

  • Predictable filter behavior
  • Accurate DAX calculations
  • Simpler models

Common Mistakes (Often Tested)

❌ Using descriptive columns as keys

Names and labels are not guaranteed to be unique.


❌ Mismatched data types

Text vs numeric keys prevent relationships from working.


❌ Ignoring duplicates in dimension tables

This results in many-to-many relationships.


❌ Creating keys in DAX instead of Power Query

Keys should be created before load, not at query time.


Best Practices for PL-300 Candidates

  • Ensure keys are unique and non-null
  • Prefer integer or stable identifier keys
  • Create composite keys in Power Query
  • Validate cardinality after creating relationships
  • Follow star schema design principles
  • Avoid unnecessary many-to-many relationships

How This Appears on the PL-300 Exam

You may see scenario questions like:

A relationship cannot be created between two tables because duplicates exist. What should you do?

Correct reasoning:

  • Identify or create a proper key
  • Remove duplicates or create a dimension table
  • Possibly generate a composite key

Quick Decision Guide

ScenarioAction
No unique column existsCreate a composite key
Duplicate values in dimensionClean or redesign table
Relationship failsCheck data types
Many-to-many relationshipRe-evaluate key design

Final PL-300 Takeaways

  • Relationships depend on clean, well-designed keys
  • Keys should be prepared before loading
  • One-to-many relationships are ideal
  • Composite keys must be explicitly created
  • Key design directly affects DAX and visuals

Practice Questions

Go to the Practice Exam Questions for this topic.

Identify When to Use Reference or Duplicate Queries and the Resulting Impact (PL-300 Exam Prep)

This post is a part of the PL-300: Microsoft Power BI Data Analyst Exam Prep Hub; and this topic falls under these sections:
Prepare the data (25–30%)
--> Transform and load the data
--> Identify When to Use Reference or Duplicate Queries and the Resulting Impact


Note that there are 10 practice questions (with answers and explanations) for each section to help you solidify your knowledge of the material. Also, there are 2 practice tests with 60 questions each available on the hub below the exam topics section.

When preparing data in Power BI, analysts often need to reuse an existing query to create additional tables or variations of the same dataset. Power Query provides two options for this: Reference and Duplicate queries.

For the PL-300: Microsoft Power BI Data Analyst exam, Microsoft tests whether you understand when to use each option and how they affect refresh behavior, dependency chains, and performance.


Reference vs Duplicate: High-Level Overview

OptionWhat It DoesKey Characteristic
ReferenceCreates a new query that depends on the original queryLinked / dependent
DuplicateCreates a full copy of the query and its stepsIndependent

Exam insight: This is not just a UI decision — it’s a data lineage and dependency decision.


What Is a Referenced Query?

A referenced query points to the output of another query and builds additional transformations on top of it.

Key Characteristics

  • Inherits all steps from the source query
  • Updates automatically when the source query changes
  • Creates a dependency chain
  • Reduces duplicated transformation logic

Common Use Cases

  • Creating dimension tables from a cleaned fact table
  • Building multiple outputs from a single prepared dataset
  • Centralizing complex cleaning logic
  • Ensuring consistent transformations across tables

Exam favorite: Reference is commonly used when creating dimension tables from a base query.


What Is a Duplicated Query?

A duplicated query creates a complete copy of the original query, including all transformation steps.

Key Characteristics

  • Independent of the original query
  • Changes to one query do not affect the other
  • No dependency chain
  • May increase maintenance effort

Common Use Cases

  • Creating a what-if version of a dataset
  • Applying very different transformations
  • Testing changes safely
  • Preventing downstream impact

Impact on Refresh and Performance

Referenced Queries

  • Refresh order matters
  • If the source query fails, dependent queries fail
  • Can improve maintainability
  • May improve performance by avoiding repeated transformations

Duplicated Queries

  • Each query executes its own steps
  • Can increase refresh time if logic is repeated
  • Easier to isolate failures
  • Can lead to inconsistent transformations if not managed carefully

Exam insight: Microsoft often tests dependency awareness, not raw performance numbers.


Impact on Data Lineage (Often Tested)

Power BI’s View Lineage clearly shows:

  • Referenced queries as downstream dependencies
  • Duplicated queries as separate branches

Referenced queries create upstream/downstream relationships, which is important for:

  • Debugging refresh failures
  • Understanding transformation flow
  • Model governance

Choosing the Right Option (Decision Scenarios)

Use Reference When:

  • You want to reuse cleaned data
  • You are creating multiple tables from a common source
  • Consistency is critical
  • You want changes to propagate automatically

Use Duplicate When:

  • You need a fully independent version
  • You want to experiment or test changes
  • The transformation logic will diverge significantly
  • You want to avoid breaking existing queries

PL-300 best practice: Prefer Reference for production models, Duplicate for experimentation.


Common Exam Scenarios

Scenario 1: Dimension Creation

You have a cleaned Sales table and need Customer and Product dimensions.

Correct choice: Reference the Sales query
✖ Duplicate would repeat logic unnecessarily


Scenario 2: What-If Testing

You want to test a new transformation without impacting reports.

Correct choice: Duplicate the query
✖ Reference could unintentionally affect dependent tables


Scenario 3: Centralized Data Cleaning

Multiple tables require identical preprocessing steps.

Correct choice: Reference
✖ Duplicate risks inconsistency


Impact on the Data Model

Referenced Queries

  • Cleaner model design
  • Easier maintenance
  • Predictable behavior
  • Tighter dependency management

Duplicated Queries

  • Greater flexibility
  • Potential for inconsistency
  • Increased refresh cost
  • More manual maintenance

Common Mistakes (Often Tested)

❌ Duplicating When Referencing Is Needed

Leads to:

  • Repeated logic
  • Longer refresh times
  • Inconsistent data shaping

❌ Referencing When Independence Is Required

Leads to:

  • Unexpected changes downstream
  • Hard-to-trace refresh failures

❌ Breaking Dependencies Unintentionally

Changing a referenced base query can affect multiple tables.


Best Practices for PL-300 Candidates

  • Start with a base query for raw data
  • Apply heavy cleaning once
  • Reference for downstream tables
  • Duplicate only when isolation is required
  • Rename queries clearly to reflect dependencies
  • Use View Lineage to validate relationships
  • Know when not to reference (testing, experimentation, divergent logic)

How This Appears on the PL-300 Exam

Expect questions like:

  • Which option ensures changes propagate automatically?
  • Which choice minimizes repeated transformations?
  • Why did a downstream query fail after a change?
  • Which approach improves maintainability?

The correct answer almost always depends on intent and impact, not convenience.


Quick Decision Table

RequirementBest Choice
Reuse cleaned dataReference
Independent copyDuplicate
Centralized logicReference
Safe experimentationDuplicate
Dimension creationReference

Final Exam Takeaways

  • Reference = dependent, reusable, consistent
  • Duplicate = independent, flexible, isolated
  • This topic tests data lineage awareness
  • Microsoft emphasizes maintainability and correctness
  • Choosing incorrectly can break refresh or logic

Practice Questions

Go to the Practice Exam Questions for this topic.

Create Fact Tables and Dimension Tables (PL-300 Exam Prep)

This post is a part of the PL-300: Microsoft Power BI Data Analyst Exam Prep Hub; and this topic falls under these sections:
Prepare the data (25–30%)
--> Transform and load the data
--> Create Fact Tables and Dimension Tables


Note that there are 10 practice questions (with answers and explanations) for each section to help you solidify your knowledge of the material. Also, there are 2 practice tests with 60 questions each available on the hub below the exam topics section.

Creating fact tables and dimension tables is a foundational step in preparing data for analysis in Power BI. For the PL-300: Microsoft Power BI Data Analyst exam, this topic tests your understanding of data modeling principles, especially how to structure data into a star schema using Power Query before loading it into the data model.

Microsoft emphasizes not just what fact and dimension tables are, but how and when to create them during data preparation.


Why Fact and Dimension Tables Matter

Well-designed fact and dimension tables:

  • Improve model performance
  • Simplify DAX measures
  • Enable accurate relationships
  • Support consistent filtering and slicing
  • Reduce ambiguity and calculation errors

Exam insight: Many PL-300 questions test whether you recognize when raw data should be split into facts and dimensions instead of remaining as a single flat table.


What Is a Fact Table?

A fact table stores quantitative, measurable data that you want to analyze.

Common Characteristics

  • Contains numeric measures (Sales Amount, Quantity, Cost)
  • Includes foreign keys to dimension tables
  • Has many rows (high granularity)
  • Represents business events (sales, orders, transactions)

Examples

  • Sales transactions
  • Inventory movements
  • Website visits
  • Financial postings

What Is a Dimension Table?

A dimension table stores descriptive attributes used to filter, group, and label facts.

Common Characteristics

  • Contains textual or categorical data
  • Has unique values per key
  • Fewer rows than fact tables
  • Provides business context

Examples

  • Customer
  • Product
  • Date
  • Geography
  • Employee

Star Schema (Exam Favorite)

The recommended modeling approach in Power BI is the star schema:

  • One central fact table
  • Multiple surrounding dimension tables
  • One-to-many relationships from dimensions to facts
  • Single-direction filtering (typically)

Exam insight: If a question asks how to optimize performance or simplify DAX, the answer is often “create a star schema.”


Creating Fact and Dimension Tables in Power Query

Starting Point: Raw or Flat Data

Many data sources arrive as a single wide table containing both measures and descriptive columns.

Typical Transformation Approach

  1. Identify measures
    • Numeric columns that should remain in the fact table
  2. Identify dimensions
    • Descriptive attributes (Product Name, Category, Customer City)
  3. Create dimension tables
    • Reference the original query
    • Remove non-relevant columns
    • Remove duplicates
    • Rename columns clearly
    • Ensure a unique key
  4. Create the fact table
    • Keep foreign keys and measures
    • Remove descriptive text fields now handled by dimensions

Keys and Relationships

Dimension Keys

  • Primary key in the dimension table
  • Must be unique and non-null

Fact Table Keys

  • Foreign keys referencing dimension tables
  • May repeat many times

Exam insight: PL-300 questions often test your understanding of cardinality (one-to-many) and correct relationship direction.


Common Dimension Types

Date Dimension

  • Often created separately
  • Supports time intelligence
  • Includes Year, Quarter, Month, Day, etc.

Role-Playing Dimensions

  • Same dimension used multiple times (e.g., Order Date, Ship Date)
  • Requires separate relationships

Impact on the Data Model

Creating proper fact and dimension tables results in:

  • Cleaner Fields pane
  • Easier measure creation
  • Improved query performance
  • Predictable filter behavior

Poorly designed models (single flat tables or snowflake schemas) can lead to:

  • Complex DAX
  • Ambiguous relationships
  • Slower performance
  • Incorrect results

Common Mistakes (Often Tested)

❌ Leaving Data in a Single Flat Table

This often leads to duplicated descriptive data and poor performance.


❌ Creating Dimensions Without Removing Duplicates

Dimension tables must contain unique keys.


❌ Including Measures in Dimension Tables

Measures belong in fact tables, not dimensions.


❌ Using Bi-Directional Filtering Unnecessarily

Often used to compensate for poor model design.


Best Practices for PL-300 Candidates

  • Design with a star schema mindset
  • Keep fact tables narrow and tall
  • Keep dimension tables descriptive
  • Use Power Query to shape tables before loading
  • Rename tables and columns clearly
  • Know when not to split (very small or static datasets)

Know when not to over-model: If the dataset is extremely small or used for a simple report, splitting into facts and dimensions may not add value.


How This Appears on the PL-300 Exam

Expect scenario-based questions such as:

  • A dataset contains sales values and product details — how should it be structured?
  • Which table should store numeric measures?
  • Why should descriptive columns be moved to dimension tables?
  • What relationship should exist between fact and dimension tables?

These questions test modeling decisions, not just terminology.


Quick Comparison

Fact TableDimension Table
Stores measurementsStores descriptive attributes
Many rowsFewer rows
Contains foreign keysContains primary keys
Central tableSurrounding tables
Used for aggregationUsed for filtering

Final Exam Takeaways

  • Fact and dimension tables are essential for scalable Power BI models
  • Create them during data preparation, not after modeling
  • The PL-300 exam emphasizes model clarity, performance, and correctness
  • Star schema design is a recurring exam theme

Practice Questions

Go to the Practice Exam Questions for this topic.

Convert Semi-Structured Data to a Table (PL-300 Exam Prep)

This post is a part of the PL-300: Microsoft Power BI Data Analyst Exam Prep Hub; and this topic falls under these sections:
Prepare the data (25–30%)
--> Transform and load the data
--> Convert Semi-Structured Data to a Table


Note that there are 10 practice questions (with answers and explanations) for each section to help you solidify your knowledge of the material. Also, there are 2 practice tests with 60 questions each available on the hub below the exam topics section.

In real-world analytics, data rarely arrives in a perfectly tabular format. Instead, analysts often work with semi-structured data, such as JSON files, XML documents, nested records, lists, or poorly formatted spreadsheets.

For the PL-300: Microsoft Power BI Data Analyst exam, Microsoft expects you to understand how to convert semi-structured data into a clean, tabular format using Power Query so it can be modeled, related, and analyzed effectively.


What Is Semi-Structured Data?

Semi-structured data does not follow a strict row-and-column structure but still contains identifiable elements and hierarchy.

Common examples include:

  • JSON files (nested objects and arrays)
  • XML files
  • API responses
  • Excel sheets with nested headers or inconsistent layouts
  • Columns containing records or lists in Power Query

Exam insight: The exam does not focus on file formats alone — it focuses on recognizing non-tabular structures and flattening them correctly.


Where This Happens in Power BI

All semi-structured data transformations are performed in Power Query Editor, typically using:

  • Convert to Table
  • Expand (↔ icon) for records and lists
  • Split Column
  • Transpose
  • Fill Down / Fill Up
  • Promote Headers
  • Remove Blank Rows / Columns

Common Semi-Structured Scenarios (Exam Favorites)

1. JSON and API Data

When loading JSON or API data, Power Query often creates columns containing:

  • Records (objects)
  • Lists (arrays)

These must be expanded to expose fields and values.

Example:

  • Column contains a Record → Expand to columns
  • Column contains a List → Convert to Table, then expand

2. Columns Containing Lists

A column may contain multiple values per row stored as a list.

Solution path:

  • Convert list to table
  • Expand values into rows
  • Rename columns

Exam tip: Lists usually become rows, while records usually become columns.


3. Nested Records

Nested records appear as a single column with structured fields inside.

Solution:

  • Expand the record
  • Select required fields
  • Remove unnecessary nested columns

4. Poorly Formatted Excel Sheets

Common examples:

  • Headers spread across multiple rows
  • Values grouped by section
  • Blank rows separating logical blocks

Typical transformation sequence:

  1. Remove blank rows
  2. Fill down headers
  3. Transpose if needed
  4. Promote headers
  5. Rename columns

Key Power Query Actions for This Topic

Convert to Table

Used when:

  • Data is stored as a list
  • JSON arrays need flattening
  • You need row-level structure

Expand Columns

Used when:

  • Columns contain records or nested tables
  • You want to expose attributes as individual columns

You can:

  • Expand all fields
  • Select specific fields
  • Avoid prefixing column names (important for clean models)

Promote Headers

Often used after:

  • Transposing
  • Importing CSV or Excel files with headers in the first row

Fill Down

Used when:

  • Headers or categories appear once but apply to multiple rows
  • Semi-structured data uses grouping instead of repetition

Impact on the Data Model

Converting semi-structured data properly:

  • Enables relationships to be created
  • Allows DAX measures to work correctly
  • Prevents ambiguous or unusable columns
  • Improves model usability and performance

Improper conversion can lead to:

  • Duplicate values
  • Inconsistent grain
  • Broken relationships
  • Confusing field names

Exam insight: Microsoft expects you to shape data before loading it into the model.


Common Mistakes (Often Tested)

❌ Expanding Too Early

Expanding before cleaning can introduce nulls, errors, or duplicated values.


❌ Keeping Nested Structures

Leaving lists or records unexpanded results in columns that cannot be analyzed.


❌ Forgetting to Promote Headers

Failing to promote headers leads to generic column names (Column1, Column2), which affects clarity and modeling.


❌ Mixing Granularity

Expanding nested data without understanding grain can create duplicated facts.


Best Practices for PL-300 Candidates

  • Inspect column types (Record vs List) before expanding
  • Expand only required fields
  • Rename columns immediately after expansion
  • Normalize data before modeling
  • Know when NOT to expand (e.g., reference tables or metadata)
  • Validate row counts after conversion

How This Appears on the PL-300 Exam

Expect scenario-based questions like:

  • A JSON file contains nested arrays — what transformation is required to analyze it?
  • An API response loads as a list — how do you convert it to rows?
  • A column contains records — how do you expose the attributes for reporting?
  • What step is required before creating relationships?

Correct answers focus on Power Query transformations, not DAX.


Quick Decision Guide

Data ShapeRecommended Action
JSON listConvert to Table
Record columnExpand
Nested list inside recordConvert → Expand
Headers in rowsTranspose + Promote Headers
Grouped labelsFill Down

Final Exam Takeaways

  • Semi-structured data must be flattened before modeling
  • Power Query is the correct place to perform these transformations
  • Understand the difference between lists, records, and tables
  • The exam tests recognition and decision-making, not syntax memorization

Practice Questions

Go to the Practice Exam Questions for this topic.

Pivot, Unpivot, and Transpose Data (PL-300 Exam Prep)

This post is a part of the PL-300: Microsoft Power BI Data Analyst Exam Prep Hub; and this topic falls under these sections:
Prepare the data (25–30%)
--> Transform and load the data
--> Pivot, Unpivot, and Transpose Data


Note that there are 10 practice questions (with answers and explanations) for each section to help you solidify your knowledge of the material. Also, there are 2 practice tests with 60 questions each available on the hub below the exam topics section.

Real-world datasets often come in formats that are not ready for analysis or visualization. The ability to reshape data by pivoting, unpivoting, or transposing columns and rows is a fundamental skill for transforming data into the correct structure for modeling.

This capability resides in Power Query Editor, and the PL-300 exam tests both your conceptual understanding and practical decision-making skills in these transformations.


Why Reshape Data?

Data can be presented in a variety of layouts, including:

  • Tall and narrow (normalized)
  • Wide and flat (denormalized)
  • Cross-tab style (headers with values spread across columns)

Some visuals and analytical techniques require data to be in a normalized (tall) format, while others benefit from a wide format. Reshaping data ensures that:

  • Tables have consistent column headers
  • Values are in the correct place for aggregation
  • Relationships and measures work properly
  • Models are efficient and performant

Where Pivoting, Unpivoting, and Transposing Occur

All three transformations happen in Power Query Editor:

  • Pivot Columns
  • Unpivot Columns
  • Transpose Table

You can find them primarily in the Transform or Transform → Any Column menus.

Exam tip: Understanding why the transformation is appropriate for the scenario is more important than knowing the exact UI path.


Pivoting Columns

What It Does

Pivoting converts unique values from one column into multiple new columns.
In essence, it rotates rows into columns.

Example Scenario

A dataset:

ProductYearSales
A2023100
A2024120

After pivoting “Year”:

Product20232024
A100120

When to Use Pivot

  • You need a matrix-style layout
  • You want to create a column for each category (e.g., year, region, quarter)

Aggregation Consideration

Power BI may require you to provide an aggregation function when pivoting (e.g., sum of values).


Unpivoting Columns

What It Does

Unpivoting converts columns back into attribute–value pairs, essentially turning columns into rows.

Example Scenario

A wide table:

ProductJanFebMar
A101520

After unpivoting:

ProductMonthSales
AJan10
AFeb15
AMar20

When to Use Unpivot

  • Your data has repeating columns for values (e.g., months, categories)
  • You need to normalize data for consistent analysis

Exam Focus

Unpivot is one of the most frequently tested transformations because real-world data often arrives in a “wide” layout.


Transposing a Table

What It Does

Transposing flips the entire table, making rows into columns and columns into rows.

Example

ABC
123
456

Becomes:

Column1Column2
A1
B2
C3
(next)4

When to Use Transpose

  • The dataset is oriented incorrectly
  • The first row contains headers but is not in column form
  • You’re reshaping a small reference table

Important Note

Transpose affects all columns — use it when the entire table must be rotated.


Common Patterns in the PL-300 Exam

The PL-300 exam often tests your ability to recognize data shapes and choose the correct approach:

Scenario: Suboptimal Layout

A dataset has months as column headers (Jan–Dec) and needs to be prepared for a time-series analysis.
Key answer: Unpivot columns

Scenario: Create a Cross-Tab Summary

You want product categories as columns with aggregated values.
Key answer: Pivot columns

Scenario: Fix Improper Orientation

The first row contains headers and the current format is not usable.
Key answer: Transpose table (often followed by promoting the first row to headers)


Best Practices (Exam-Oriented)

  • Understand the shape of your data first: Diagnose whether it’s tall vs wide
  • Clean before reshaping: Remove nulls or errors so the transformation succeeds
  • Group/aggregate after unpivoting when necessary
  • Use “Unpivot Other Columns” when you want to keep important keys and unpivot everything else
  • Pivot only when categories are fixed and small in number (too many pivot columns can bloat the model)
  • Transpose sparingly — it’s usually for reference tables, not large fact tables

Know when not to pivot: Don’t pivot if it will produce too many columns or if the data is already in normalized format suitable for analysis.


Impact on the Data Model

Your choices here affect:

  • Model shape and size: Too many columns from pivoting can bloat the model
  • DAX flexibility: Normalized (unpivoted) tables support richer filtering and relationship behaviors
  • Performance: Unpivoted fact tables often perform better for filters and slicers

Choose wisely whether the transformation should occur in Power Query (Physically reshape the data) or via a visual/DAX technique after loading.


Common Mistakes (Often Tested)

The exam often presents distractors like:

❌ Mistaking Pivot for Unpivot

Students try to pivot when the scenario clearly describes normalizing repeated columns.

❌ Transposing without Promoting Headers

Transpose alone doesn’t fix header issues — often you must promote the first row afterward.

❌ Pivoting Without Aggregation Logic

Pivot requires defining how values are aggregated; forgetting this results in errors.

❌ Unpivoting Key Columns

Using unpivot incorrectly can duplicate keys or inflate the dataset unnecessarily.


How This Appears on the PL-300 Exam

Expect scenario-based questions like:

  • “Which transformation will best convert this wide-format month columns into a single Month column?”
  • “The first row contains field names that should be column headers — what is the correct sequence of transformations?”
  • “Which transformation will turn categories into columns for a matrix visual?”

Answers are scored based on concept selection, not clicks.


Quick Decision Guide

ScenarioBest Transformation
Multiple value columns need to become rowsUnpivot
One column’s values need to become individual columnsPivot
Entire table needs rows/columns flippedTranspose

Final Exam Takeaways

  • Pivot, unpivot, and transpose are powerful reshape tools in Power Query
  • The exam emphasizes when and why to use each, not just how
  • Understand the data shape goal before choosing the transformation
  • Cleaning and data type correction often precede shaping operations

Practice Questions

Go to the Practice Exam Questions for this topic.