Optimizing Tables, Relationships, and Data Models in Power BI

Course: Microsoft Power BI Training

Topic: Optimizing Tables, Relationships, and Data Models

Course Link: Microsoft Power BI Training

Demo Link: Register for a Free Course Demo

JustAcademy Website: Visit JustAcademy

1. Introduction to Data Model Optimization in Power BI

Data model optimization is the process of organizing tables, defining relationships, reducing unnecessary data, and improving the efficiency of calculations in Microsoft Power BI. A well-designed data model helps reports load faster, reduces memory consumption, improves DAX performance, and makes reports easier to maintain.

Power BI uses a columnar storage engine called VertiPaq for importing and compressing data. The way tables and columns are structured can significantly influence compression, memory usage, query performance, and report responsiveness.

Optimization is not limited to improving speed. It also involves making sure that relationships are accurate, calculations return correct results, and business users can understand the model.

1.1 Objectives of Data Model Optimization

• Improve report loading and visual rendering speed.
• Reduce the size of Power BI files and semantic models.
• Minimize unnecessary columns, rows, and tables.
• Create clear and efficient relationships between tables.
• Improve the performance of DAX measures.
• Prevent ambiguous filtering and incorrect aggregation.
• Make the model easier to understand, test, and maintain.
• Support reliable reporting as data volumes increase.

1.2 Key Components of an Optimized Model

2. Understanding Tables in Power BI

A table is a collection of rows and columns representing a business entity, transaction, or category. For example, a sales reporting model may contain Sales, Products, Customers, Dates, and Regions tables.

2.1 Types of Tables

• Fact tables: Store business events and numerical transactions, such as sales amounts, quantities, costs, and order details.
• Dimension tables: Store descriptive information used to categorize and filter facts, such as product names, customer details, dates, and locations.
• Lookup tables: Provide reference values used to classify or map records.
• Bridge tables: Connect tables when a many-to-many relationship is required.
• Aggregation tables: Store summarized data to support faster queries in suitable model designs.
• Disconnected tables: Have no active relationship with other tables and are often used for parameter selection or specialized calculations.

2.2 Fact Tables vs. Dimension Tables

2.3 Example of a Sales Data Model

Consider a retail business that tracks product sales. The model may contain the following tables:

In this design, Sales is the central fact table, while Products, Customers, and Date are dimension tables. This structure allows users to analyze sales by product, customer, month, quarter, or year.

3. Optimizing Tables in Power BI

Table optimization starts before relationships and DAX are tuned. Removing unnecessary data and improving the shape of the source data can reduce the work required by the storage and query engines.

3.1 Remove Unnecessary Columns

Every imported column consumes model resources to some extent. Columns that are not required for reporting, relationships, sorting, calculations, or other model functionality should usually be removed.

Examples of potentially unnecessary columns include:

• Unused comments or long text descriptions.
• Source-system audit fields that are never analyzed.
• Duplicate descriptions already available in dimension tables.
• Temporary columns created during data preparation.
• Unused identifiers that are not needed for relationships or analysis.

Steps to remove unnecessary columns:

1. Open Power BI Desktop.
2. Select Home > Transform data to open Power Query Editor.
3. Select the table containing unnecessary columns.
4. Select the columns that are not required.
5. Choose Remove Columns.
6. Select Close & Apply to apply the transformation.
7. Validate that existing visuals, relationships, and measures still work correctly.

Best practice: Confirm the business purpose of a column before removing it. An apparently unused column may support a relationship, sorting rule, or future business requirement.

3.2 Remove Unnecessary Rows

Reducing the number of imported rows can lower storage requirements and improve refresh performance. However, rows should only be removed when business rules permit it.

Possible techniques include:

• Filtering out records that are outside the reporting period.
• Removing invalid records according to documented business rules.
• Excluding irrelevant transaction types.
• Using source-system filters when appropriate.
• Loading summarized data when transaction-level detail is not required.

For example, if a report only needs the previous five years of sales, the model may not need to import decades of historical transactions. Before applying this filter, verify retention, comparison, and compliance requirements.

3.3 Use Appropriate Data Types

Correct data types help prevent calculation errors and can improve compression and processing efficiency.

Avoid storing numeric values as text unless there is a specific reason. For example, a numeric quantity stored as text cannot be reliably summed without conversion.

Identifiers such as postal codes and product codes may need to remain text because leading zeros and non-numeric characters can be meaningful.

3.4 Reduce High-Cardinality Columns

Cardinality refers to the number of distinct values in a column. Columns with many unique values can require more storage than columns with only a few distinct values.

Examples of high-cardinality columns include:

• Transaction-level identifiers.
• Unique session IDs.
• Long URLs or email addresses.
• Precise timestamps containing many distinct values.
• Free-text descriptions.

Ways to manage high cardinality include:

• Removing columns that are not needed for analysis.
• Splitting a timestamp into date and time attributes when appropriate.
• Replacing verbose text with suitable numeric keys when a valid mapping exists.
• Reducing unnecessary precision in numeric or time values.
• Moving descriptive attributes to appropriate dimension tables.

Important: High cardinality is not automatically a problem. A unique key may be essential for data integrity or relationships. Do not remove a required key merely to reduce model size.

3.5 Avoid Redundant Columns and Repeated Data

Repeated descriptive information in a large fact table can increase storage requirements. A star schema often places product names, categories, and brand descriptions in a Products dimension table instead of repeating them across every sales transaction.

For example, storing a product category in every row of a million-row Sales table can be less efficient than storing it once per product in a Products table and connecting the tables through ProductKey.

However, normalization should be balanced with usability. The goal is not to create the maximum possible number of tables; it is to build a clear model that performs well and supports the required analysis.

4. Understanding Data Relationships

A relationship connects two tables through matching columns. Relationships allow filters from one table to affect calculations over related tables.

For example, a relationship between Products[ProductKey] and Sales[ProductKey] enables a report to display sales by product category.

4.1 Types of Relationships

4.2 One-to-Many Relationships

One-to-many is the most common relationship pattern in a star schema. The dimension table is on the one side, and the fact table is on the many side.

Example:

Products[ProductKey]  (1) -------- (*)  Sales[ProductKey]

Suppose the Products table contains one row for ProductKey 101, while the Sales table contains several rows with ProductKey 101. The product row describes the product, and the sales rows record its transactions.

Power BI uses this relationship to aggregate sales by product attributes without repeating product details in the fact table.

4.3 Primary Keys and Foreign Keys

• Primary key: A column, or combination of columns, that uniquely identifies each row in a table.
• Foreign key: A column in one table that references a key in another table.

In a typical model, Products[ProductKey] acts as a primary key, while Sales[ProductKey] acts as a foreign key.

The dimension key on the one side should contain unique values. Duplicate keys can prevent a valid one-to-many relationship from being created.

4.4 Creating Relationships in Power BI

1. Open Power BI Desktop and select Model view.
2. Identify the tables that need to be connected.
3. Drag the key column from one table onto the corresponding key column in the other table, or select Manage relationships.
4. Choose New to define a relationship manually if required.
5. Confirm the table and column selections.
6. Set the appropriate cardinality, such as One-to-many.
7. Choose the cross-filter direction according to the model design.
8. Set the relationship to active if it should be used by default.
9. Confirm the relationship and test the report using fields from both tables.

Power BI can detect and create some relationships automatically, but automatically generated relationships should always be reviewed.

5. Optimizing Relationship Design

5.1 Prefer a Star Schema

A star schema organizes the model around a central fact table connected to descriptive dimension tables. This is generally a strong starting point for analytical models in Power BI.

                 Date
                  |
                  |
Customers ---- Sales ---- Products
                  |
                  |
                Region

In this example, Sales stores transaction-level data. Date, Customers, Products, and Region provide descriptive fields for filtering and grouping the facts.

Benefits of a star schema:

• Clear separation between transactional and descriptive data.
• More predictable filter propagation.
• Simple and readable DAX measures.
• Improved usability for report authors.
• Reduced ambiguity in relationship paths.
• Often better performance and easier maintenance.

5.2 Use Single-Direction Filtering by Default

Cross-filter direction determines how filters propagate across a relationship. In a typical star schema, filters flow from the dimension table to the fact table.

For example, selecting the Electronics category in Products filters related rows in Sales.

Products (1) ----> (*) Sales

Single-direction filtering is usually easier to understand and can avoid ambiguous filter paths. Bidirectional filtering can be useful in specific scenarios, but it should be applied only when necessary and tested carefully.

Recommended practice: Begin with single-direction relationships. Use bidirectional filtering only when the business requirement justifies it and the effect on the complete model is understood.

5.3 Avoid Unnecessary Bidirectional Relationships

Bidirectional relationships allow filters to flow in both directions. Although they can support certain calculations, excessive use can create unexpected filtering behavior and ambiguous paths.

Potential problems include:

• Unexpected changes in totals.
• Ambiguous paths between multiple tables.
• More difficult DAX troubleshooting.
• Increased complexity when the model grows.

When a calculation needs special filter behavior, consider whether a targeted DAX technique is more appropriate than changing the filtering direction for the entire relationship.

5.4 Use Active and Inactive Relationships Correctly

An active relationship is used automatically for normal filter propagation. An inactive relationship remains in the model but is not used by default.

Inactive relationships are useful when two tables have multiple possible connections. For example, an Orders table may contain both OrderDate and ShipDate, which can connect to the same Date table.

One relationship can be active while the other is inactive. A measure can activate the inactive relationship using USERELATIONSHIP.

Total Sales =
SUM(Sales[SalesAmount])

Sales by Ship Date =
CALCULATE(
    [Total Sales],
    USERELATIONSHIP(Sales[ShipDate], 'Date'[Date])
)

This example assumes that Sales[ShipDate] and Date[Date] have compatible data types and that the model contains the required relationship.

5.5 Handle Many-to-Many Relationships Carefully

Many-to-many relationships are appropriate when neither side has a unique key for the relationship. However, they can introduce complex filtering and aggregation behavior.

Consider a situation where customers can belong to multiple sales territories and each territory contains multiple customers.

A bridge table can make the relationship structure clearer:

Customers (1) ---- (*) CustomerTerritory (*) ---- (1) Territories

The CustomerTerritory table stores the combinations of customers and territories. This can provide more explicit control over the model than a direct many-to-many relationship, although the correct design depends on the reporting requirement.

Before using many-to-many relationships, verify that totals, distinct counts, and filters behave as expected.

6. Data Model Design and Optimization

6.1 What Is a Data Model?

A data model defines how tables, columns, relationships, measures, and business rules work together. It determines how Power BI interprets filters and calculates results.

A good model should be understandable to report creators, accurate for business calculations, and efficient for the expected data volume.

6.2 Use a Dedicated Date Table

A dedicated Date table provides consistent calendar attributes for time-based analysis, such as year, quarter, month, week, and day.

Typical Date table columns include:

• Date
• Year
• Quarter
• Month Number
• Month Name
• Year-Month
• Day of Week

A Date table should contain a unique row for every date in the required range, without missing dates in the calendar period. Its date column should have the Date data type.

To use a table for standard time-intelligence scenarios, select it in Power BI Desktop and choose Mark as date table, then select its date column. Check the model's requirements and the time-intelligence functions being used.

6.3 Hide Technical Columns from Report View

Columns required internally for relationships or calculations do not always need to appear in the report field list.

Examples include:

• Surrogate keys such as ProductKey.
• Technical transaction identifiers.
• Intermediate calculation columns.
• Columns used only for model relationships.

In Model view or Data view, select the column and choose Hide in report view. Hiding a column does not delete it or reduce its storage usage; it simply makes the model easier to use.

6.4 Use Measures Instead of Unnecessary Calculated Columns

Calculated columns are computed for individual rows and stored in the model. Measures are calculated when a visual or query requests a result under a particular filter context.

Measures are usually preferable for aggregations that need to respond dynamically to report filters.

Example of a calculated column:

Sales[Line Amount] =
Sales[Quantity] * Sales[UnitPrice]

Example of a measure:

Total Sales =
SUMX(
    Sales,
    Sales[Quantity] * Sales[UnitPrice]
)

The best choice depends on the business requirement. If the row-level amount is needed repeatedly across many calculations, a calculated column or a source-side column may be appropriate. If the calculation is primarily an aggregate, a measure may avoid storing an additional column.

6.5 Reduce Unnecessary Calculated Tables

Calculated tables can be useful for specialized modeling requirements, but each additional table increases model complexity and may consume storage. If the same result can be created more efficiently in the source or Power Query, consider those alternatives.

Keep calculated tables when they provide meaningful analytical functionality, such as a disconnected parameter table, a date table, or a required bridge table.

7. DAX Optimization for Better Model Performance

Data modeling and DAX performance are closely connected. A clean model makes it easier to write measures that use relationships and filter context effectively.

7.1 Create Reusable Measures

Reusable measures reduce duplicated business logic and improve consistency across reports.

Total Sales =
SUM(Sales[SalesAmount])

Total Quantity =
SUM(Sales[Quantity])

Total Orders =
DISTINCTCOUNT(Sales[OrderID])

Average Order Value =
DIVIDE(
    [Total Sales],
    [Total Orders],
    0
)

The DIVIDE function safely handles division by zero according to the specified alternate result.

7.2 Use Simple Aggregations Where Possible

Prefer straightforward aggregation functions when they meet the requirement. For example, use SUM for a stored numeric amount rather than iterating through every row unnecessarily.

Total Sales =
SUM(Sales[SalesAmount])

If the amount must be calculated from other columns, an iterator such as SUMX may be appropriate.

Total Sales =
SUMX(
    Sales,
    Sales[Quantity] * Sales[UnitPrice]
)

The second expression calculates the amount for each row and then adds the results. Choose the expression that correctly represents the business rule rather than assuming one function is always faster.

7.3 Avoid Unnecessary Iterators

Functions such as SUMX, FILTER, and ADDCOLUMNS are powerful, but iterating over a large table unnecessarily can increase query cost.

Use iterators when row-by-row evaluation is required. Where possible, simplify the expression, use suitable model relationships, and reduce the number of rows that must be evaluated.

7.4 Use Variables in Complex Measures

Variables can make measures easier to read and help avoid repeating the same expression unnecessarily.

Sales Growth % =
VAR CurrentSales = [Total Sales]
VAR PreviousSales = [Previous Year Sales]
RETURN
    DIVIDE(
        CurrentSales - PreviousSales,
        PreviousSales,
        0
    )

Variables improve clarity and can help structure calculations. They do not automatically guarantee faster execution; measure performance should still be tested.

7.5 Avoid Excessive Calculated Columns

Calculated columns can increase memory consumption, especially when they contain many distinct values. Where appropriate, move transformations to Power Query or the data source, or calculate aggregated results through measures.

Keep calculated columns when they are necessary for row-level classification, relationships, sorting, or other model requirements.

8. Optimizing the Model with Power Query

Power Query is the data preparation environment in Power BI. Transformations performed there can reduce the amount of unnecessary data imported into the model.

8.1 Remove Columns Early

Remove unused columns as early as practical in the query process. This makes the intended model structure clearer and can reduce the volume of data passed through later transformations.

8.2 Filter Rows at the Source Where Possible

When a source supports query folding, Power Query can translate compatible transformations into a query executed by the source system. Filtering at the source may reduce the amount of data transferred to Power BI.

Query folding support depends on the connector, source, and transformations used. Verify folding rather than assuming every transformation is pushed to the source.

8.3 Understand Query Folding

Query folding is the process of translating Power Query transformations into operations that the data source can execute.

For example, a filter on a SQL table may be translated into a WHERE clause. This can reduce the number of records retrieved by Power BI.

Useful practices include:

• Use source filters where appropriate.
• Keep transformations compatible with the source when possible.
• Check query-folding indicators or available query-plan tools.
• Compare refresh performance before and after changes.

8.4 Choose the Correct Storage Mode

Choose a storage mode based on data freshness, data volume, source capability, security, and performance requirements. DirectQuery is not automatically faster than Import, and Import is not always suitable for every workload.

9. Handling Relationship Problems and Data Quality

9.1 Duplicate Keys

A one-to-many relationship requires unique key values on the one side. Duplicate values in a dimension key can prevent the relationship from being created or indicate a data-quality problem.

To investigate:

1. Open Power Query Editor.
2. Select the dimension table and its key column.
3. Check for duplicates and blank values.
4. Identify whether duplicates are legitimate or caused by data errors.
5. Correct the source data or redesign the key where appropriate.
6. Refresh and validate the relationship.

Do not simply remove duplicate rows if they represent legitimate business entities. Determine the correct business key and the required grain of the dimension first.

9.2 Unmatched Foreign Keys

A fact table may contain foreign keys that do not exist in the corresponding dimension table. These unmatched keys can lead to blank or unexpected categories in reports.

Possible causes include missing dimension records, inconsistent data types, spelling or formatting differences, and timing differences between data refreshes.

Check for unmatched keys and decide whether to correct the source data, create an appropriate unknown member, or handle the records according to documented business rules.

9.3 Incorrect Totals

Incorrect totals may result from duplicate fact rows, inappropriate relationship cardinality, many-to-many behavior, or measures that do not match the intended business definition.

Recommended checks:

• Confirm the grain of every fact table.
• Validate key uniqueness on dimension tables.
• Check relationship cardinality and filter direction.
• Compare totals against the source system.
• Review DAX filter context and aggregation logic.
• Test results using a small, known sample of records.

9.4 Ambiguous Relationships

Ambiguity occurs when multiple active paths can transmit filters between tables. Power BI may prevent some ambiguous active relationship configurations or produce confusing results in complex models.

To resolve the problem, review the relationship diagram, remove unnecessary relationships, use inactive relationships where appropriate, and simplify the model around a clear star schema.

10. Practical Example: Building an Optimized Sales Model

In this exercise, you will build a basic sales model and apply common optimization techniques.

10.1 Sample Data

Sales table:

Products table:

10.2 Step-by-Step Implementation

1. Import the Sales and Products tables into Power BI.
2. Inspect the data types and ensure that keys have compatible types.
3. Remove columns that are not needed for reporting, while retaining required keys.
4. Check that Products[ProductKey] contains unique values.
5. Create a one-to-many relationship from Products[ProductKey] to Sales[ProductKey].
6. Use single-direction filtering from Products to Sales.
7. Create a dedicated Date table and connect it to the Sales table using the appropriate date key.
8. Hide technical keys from report view where appropriate.
9. Create reusable measures for sales and quantity.
10. Build visuals and compare totals against the sample data.
11. Use Performance Analyzer to identify slow visuals if performance issues occur.

10.3 Create DAX Measures

Total Sales =
SUM(Sales[SalesAmount])

Total Quantity =
SUM(Sales[Quantity])

Total Products Sold =
DISTINCTCOUNT(Sales[ProductKey])

Average Sales per Transaction =
DIVIDE(
    [Total Sales],
    COUNTROWS(Sales),
    0
)

For the sample data, Total Sales should equal 8,900 and Total Quantity should equal 8. These totals provide a basic validation check for the model.

Total Products Sold equals 3 because three distinct product keys appear in the sales records. Average Sales per Transaction equals 2,225 because there are four transactions.

10.4 Validate the Model

• Place Category and ProductName in a table visual.
• Add the Total Sales measure.
• Confirm that Electronics totals 6,500 and Furniture totals 2,400.
• Add a date slicer and verify that it filters sales correctly.
• Check that no products disappear unexpectedly because of missing keys.
• Compare the results against the original sample data.

11. Measuring and Improving Performance

11.1 Use Performance Analyzer

Performance Analyzer in Power BI Desktop helps identify which visuals take the most time to load and separates aspects of visual performance, including DAX query execution and other processing.

Steps:

1. Open the report in Power BI Desktop.
2. Select the Optimize ribbon and open Performance Analyzer, or locate it through the relevant View or optimization controls in your version.
3. Start recording.
4. Refresh visuals or interact with slicers.
5. Identify visuals with high durations.
6. Inspect the available timing details and copy the visual's query if further analysis is needed.
7. Optimize the relevant DAX, model structure, visual design, or data source.
8. Record again and compare the results.

11.2 Reduce Visual Complexity

A large number of visuals on one page can increase rendering and query work. Optimize the report page as well as the data model.

• Remove visuals that do not contribute to the report's purpose.
• Avoid displaying excessive categories in a single chart.
• Use slicers and drill-through pages when appropriate.
• Avoid unnecessarily complex visual interactions.
• Use aggregation and filtering to display relevant information.

11.3 Monitor Model Size

For large Import models, model-size analysis tools can help identify tables and columns consuming the most memory. Depending on the environment and permissions, tools such as DAX Studio and VertiPaq Analyzer can provide detailed storage statistics.

Investigate large columns, repeated text, unnecessary tables, and high-cardinality data. Make changes based on evidence rather than removing useful business data without validation.

12. Common Mistakes to Avoid

13. Best Practices Checklist

• Use a star schema where it fits the reporting requirements.
• Separate facts from descriptive dimensions.
• Remove unused rows and columns where business rules allow.
• Use appropriate data types and avoid unnecessary precision.
• Validate uniqueness on the one side of one-to-many relationships.
• Use single-direction filtering by default.
• Use many-to-many relationships and bidirectional filtering deliberately.
• Build a dedicated Date table for time-based analysis when appropriate.
• Hide technical columns that report authors do not need.
• Prefer reusable measures for dynamic aggregations.
• Inspect query folding for supported data sources and transformations.
• Choose a storage mode based on data volume, freshness, and performance.
• Measure report performance before and after optimization.
• Validate model results against trusted source totals.
• Document important relationships, assumptions, and business definitions.

14. Practice Exercises

Exercise 1: Table Optimization

Import a sales dataset containing at least ten columns. Identify unnecessary columns and remove them. Compare model size and refresh time before and after the changes, where measurable.

Exercise 2: Relationship Design

Create Sales and Products tables. Establish a one-to-many relationship using ProductKey. Test whether product category filters the sales measure correctly.

Exercise 3: Star Schema

Extend the model by adding Customers and Date tables. Connect them to Sales and build a report showing sales by year, customer segment, and product category.

Exercise 4: Relationship Troubleshooting

Create a duplicate key in a dimension table or introduce an unmatched foreign key. Observe the issue, identify its cause, correct the data, and validate the results.

Exercise 5: Performance Analysis

Use Performance Analyzer to identify a slow visual. Review its measure, filters, and model relationships. Make one improvement at a time and compare the measured results.

15. Interview Questions and Answers

Q1. What is data model optimization in Power BI?

Answer: It is the process of improving table design, relationships, data types, calculations, and storage choices to reduce resource consumption and improve report performance and accuracy.

Q2. What is a star schema?

Answer: A star schema is a model design in which a central fact table connects to descriptive dimension tables. It simplifies filtering, aggregation, and model maintenance.

Q3. What is the difference between a fact table and a dimension table?

Answer: A fact table stores business events and measurable values. A dimension table stores descriptive attributes used to filter, group, and analyze those events.

Q4. What is a one-to-many relationship?

Answer: It connects a unique key on one side to multiple matching rows on the other side, such as one product record connected to many sales transactions.

Q5. Why should single-direction filtering usually be preferred?

Answer: It provides more predictable filter propagation and helps reduce ambiguous paths in common star-schema models.

Q6. What is cardinality?

Answer: Cardinality describes the number of distinct values in a column. High-cardinality columns can consume more storage, depending on their data and encoding.

Q7. What is the difference between a measure and a calculated column?

Answer: A calculated column stores a result for each row, while a measure calculates a result dynamically under the current filter context.

Q8. What is query folding?

Answer: Query folding translates supported Power Query transformations into operations executed by the data source, potentially reducing the amount of data transferred and processed locally.

Q9. How can duplicate keys affect a relationship?

Answer: Duplicate keys on the one side can prevent a valid one-to-many relationship. The data should be investigated and corrected or the model design should be revised.

Q10. How do you identify slow visuals?

Answer: Use Performance Analyzer to record visual timings, identify expensive queries, and investigate DAX expressions, relationships, visual complexity, and data-source performance.

Q11. What is a bridge table?

Answer: A bridge table represents associations between entities and can help model many-to-many business relationships explicitly.

Q12. Does hiding a column reduce model size?

Answer: No. Hiding a column affects its visibility in report authoring, not its storage. To reduce model size, remove the column only if it is genuinely unnecessary.

16. Quick Revision Notes

• Optimize data before optimizing complex DAX.
• Remove unnecessary columns and rows when safe.
• Choose appropriate data types.
• Use a fact-and-dimension design suited to the business process.
• Use unique dimension keys and valid foreign-key mappings.
• Prefer one-to-many relationships for common analytical models.
• Use single-direction relationships by default.
• Apply bidirectional and many-to-many relationships carefully.
• Use measures for dynamic calculations and calculated columns when row-level storage is needed.
• Use Performance Analyzer to measure report bottlenecks.
• Validate every optimization against correct business results.

17. Conclusion

Optimizing tables, relationships, and data models is a fundamental skill for developing efficient Power BI reports. Removing unnecessary data, using correct data types, designing relationships carefully, following a suitable star schema, and writing appropriate DAX measures can improve performance and maintainability.

Effective optimization should be evidence-based. Establish a baseline, identify the actual bottleneck, apply a targeted change, and validate both the performance improvement and the accuracy of the results. A well-designed semantic model helps report creators answer business questions consistently and confidently.

Learn more: Explore the Microsoft Power BI Training course and register for a course demo to learn more about Power BI modeling, data transformation, DAX, and report development.