Design and build semantic models

Objective coverage

• Choose a storage mode
• Implement a star schema for a semantic model
• Implement relationships, such as bridge tables and many-to-many relationships
• Write calculations that use DAX variables and functions, such as iterators, table filtering, windowing, and information functions
• Implement calculation groups, dynamic format strings, and field parameters
• Identify use cases for and configure large semantic model storage format
• Design and build composite models

The semantic model is a business contract

A semantic model turns prepared data into a consistent analytical vocabulary. It defines relationships, measures, security, formatting, and the way consumers navigate business entities. A report can be visually attractive while its model produces wrong totals. A model can also be numerically correct but confusing because it exposes surrogate keys, ambiguous date fields, or unexplained measures. Design for both computational correctness and the analyst who must choose the right field without reading the implementation.

Northstar's model contains Sales at order-line grain, Product and Customer dimensions, and a Date dimension. It later adds Budget at month-and-category grain and a customer-account bridge. These extensions are intentionally chosen to expose common mistakes: joining facts directly, filtering through ambiguous paths, averaging ratios, and expecting storage modes to have identical refresh behavior. All figures and scenarios are authored teaching examples.

Choose a storage mode

Storage mode determines how a semantic table obtains data for queries and how freshness is maintained. Import stores an optimized copy in the model and requires refresh to incorporate source changes. DirectQuery sends queries to supported sources and depends on their response, concurrency, and connectivity. Direct Lake reads supported Delta data in OneLake through the semantic engine without a conventional full Import copy lifecycle. Composite designs combine supported modes. The right choice depends on freshness, volume, source capabilities, transformations, capacity, security, and expected query patterns.

Write the maximum acceptable data age and the performance target, then identify where prepared data will live. Check connector and capacity support for each candidate mode. Estimate model size and refresh cost for Import, source concurrency and query cost for DirectQuery, and Delta readiness and capacity guardrails for Direct Lake. Prototype representative visuals under realistic filters and security. Measure cold and warm behavior separately. Confirm which upstream and model lifecycle events make a newly inserted row visible. Choose based on the complete path, not a promise that one mode is always real time or always faster.

A small finance model refreshes once after nightly reconciliation and must serve predictable interactive queries. Import can be a strong fit. A large curated Delta dataset already lives in Fabric and needs low-latency analytical access; Direct Lake is a candidate, subject to its variant, model features, and capacity constraints. A supported external operational source must remain queried in place, with acceptable source performance; DirectQuery may fit. These are starting hypotheses. A source that takes 15 seconds per query can make DirectQuery reports slow even if the semantic model itself is small.

Freshness has several clocks: source update, ingestion, transformation, model refresh or framing, and report query or visual refresh. A mode changes some of those clocks, not all of them. Direct Lake does not eliminate upstream data preparation, and DirectQuery does not guarantee that the source itself is current. Check mode-specific feature restrictions before choosing calculated columns, composite relationships, or security behavior. The exam distinction is operational: where the data is read from, what work happens during query versus refresh, and which limits apply to that path.

Scenario: An Import model shows yesterday's figures although the warehouse finished loading this morning. Is rebuilding the report visual the first repair?

Answer: No. Verify whether the semantic model refreshed after the warehouse load, then inspect refresh history and connection binding. An Import model queries its imported representation, so a current warehouse alone does not establish current report data. Validate a known new row after refresh.

Recall: Which costs move to query time with DirectQuery? Why must a Direct Lake design still specify upstream transformation and freshness requirements?

Implement a star schema for a semantic model

A semantic star schema connects descriptive dimensions to fact tables through well-defined relationships. Dimensions support filtering and grouping; facts support measures at a declared grain. A physical star schema is a useful input, but the semantic model still needs relationship configuration, clear field names, explicit measures, and appropriate visibility. Hide technical keys for usability while remembering that hiding is not security. A Date dimension should represent the calendar logic the business actually uses, including fiscal periods when required.

Import or connect the curated fact and dimensions, then verify key uniqueness on each dimension's one side. Configure active relationships and deliberate filter directions. Create explicit measures for business calculations and give them descriptions and format strings. Set sensible summarization behavior for fields that should not be summed, such as identifiers. Organize and hide implementation fields for a usable field list. Test each dimension's filter against a known subset of facts, and reconcile totals with the prepared data before building many report pages.

Sales contains ProductKey, CustomerKey, OrderDateKey, ShipDateKey, Quantity, and NetAmount. Product filters Sales through ProductKey, and Customer filters Sales through CustomerKey. A Date table can have an active order-date relationship and a separate inactive ship-date relationship, with measures deliberately selecting the needed role, or the model can use separate role-playing date dimensions when that better serves users. The choice should make the distinction between ordered revenue and shipped revenue explicit. A single vaguely named Date field invites inconsistent analysis.

A relationship can be configured while still producing incorrect results because the keys have different meanings, duplicate dimension rows exist, or values do not match. Test an individual known customer and a missing-key fact. Avoid joining fact tables directly merely because they share a date or product column; their grains may differ. Budget at month-category grain cannot safely behave like line-level Sales without a deliberate comparison design. In the exam, a star schema is about analytical roles, grain, and filter propagation, not simply arranging boxes into a star shape.

Scenario: A budget table has one row per month and category, while Sales has one row per transaction line. Why is joining the two facts directly on category unsafe?

Answer: The join can repeat each budget value for many sales lines and across inappropriate dates. Model shared dimensions at the required comparison grain and define measures that respect each fact's grain. Test a single month-category pair and the grand total before exposing the comparison to users.

Recall: Why should surrogate keys usually be hidden from ordinary report authors? How can two date roles be represented without making their meaning ambiguous?

Implement relationships, such as bridge tables and many-to-many relationships

Relationships propagate filters; they are not merely documentation that two columns look alike. A regular one-to-many relationship requires a unique key on the one side. Many-to-many business relationships, such as customers who share accounts, often benefit from a bridge table that records valid associations. Filter direction and active paths determine which facts are affected. Broad bidirectional filtering can create ambiguous paths and surprising totals, so enable only the propagation required by a understood business rule.

Describe each relationship in business terms and verify cardinality using data profiling. For a bridge, define its grain, usually one row per unique association, and remove duplicate associations. Draw how a filter should travel from the chosen dimension through the bridge to the fact. Configure only the necessary supported directions or measure-specific filter behavior. Test one entity, overlapping entities, all entities, and an entity with no association. Validate security propagation separately. Record whether totals intentionally count shared facts once or allocate them among owners.

Customer C1 owns Account A; C2 co-owns A and owns B. Account balances are A=100 and B=50. Selecting C1 should expose balance 100; selecting C2 should expose 150. Selecting both should expose account balance 150 if the question is the balance of distinct selected accounts. Adding customer rows yields 250 and double-counts the shared account. A bridge can express the associations, but the intended total remains a business decision. If the requirement is allocated balance, add explicit ownership weights and validate that the allocation rules sum appropriately.

Many-to-many is not a license to ignore uniqueness. Distinguish duplicate keys caused by bad data from legitimate shared associations. A relationship error can sometimes be repaired upstream by producing a proper dimension rather than changing cardinality to many-to-many. If filters fail to propagate, inspect active state, direction, key types, and disconnected tables. If totals expand unexpectedly, inspect overlapping associations and filter paths. On the exam, a bridge is often appropriate for an actual many-to-many business relation, while blindly enabling Both everywhere is not a principled model design.

Scenario: Two customers share an account, and the sum of customer balances exceeds the total balance of distinct accounts. Must the total be wrong?

Answer: Not necessarily. The customer rows may each include the shared account, while the grand total evaluates distinct selected accounts once. Clarify whether the measure represents exposure or allocated ownership. If allocation is required, define weights; do not force the total to equal a double-counted sum without a business justification.

Recall: How does a bridge's grain differ from a fact table's grain? Which tests reveal an unintended bidirectional filter path?

Write calculations that use DAX variables and functions, such as iterators, table filtering, windowing, and information functions

DAX measures operate in filter context; iterators introduce row context over a table expression. SUMX evaluates an expression for each row and sums the results. FILTER produces a table meeting a condition. CALCULATE changes filter context and can transition row context into filters. Variables store intermediate results in the context where they are defined; they improve readability and can avoid repeated evaluation, but they are not macros reevaluated later under every new filter. Window functions express ordered and partitioned analytical calculations, while INFO functions inspect supported model metadata rather than business transactions.

Start from a plain-language calculation and a small fixture. Decide whether the expression needs a scalar aggregate or an iteration. Use variables for named intermediate results and inspect them during debugging. Choose Boolean filter arguments when they express the rule cleanly; use a table expression when the condition genuinely requires it. For a window, define the relation, ordering, partitioning, and unique row identification needed for deterministic results. Check current support for information functions and the execution context. Test leaf values, totals, blank selections, and security-filtered contexts before optimizing.

Assume Sales has Quantity, UnitPrice, and UnitCost. Two lines have (2,20,12) and (1,15,10). A measure can calculate revenue 55 and cost 34:

Gross Revenue =
SUMX ( Sales, Sales[Quantity] * Sales[UnitPrice] )

Gross Profit =
VAR RevenueAmount = [Gross Revenue]
VAR CostAmount = SUMX ( Sales, Sales[Quantity] * Sales[UnitCost] )
RETURN
    RevenueAmount - CostAmount

Gross Margin % = DIVIDE ( [Gross Profit], [Gross Revenue] )

Profit is 21 and margin is about 38.18%. DIVIDE expresses safe denominator handling rather than returning an accidental error at zero revenue. To investigate a calculation, temporarily return a named variable in a test copy of the measure; restore the intended result afterward. A variable assigned [Gross Revenue] outside a later CALCULATE does not automatically recompute that revenue under CALCULATE's new filters.

Window calculations require an explicit ordered question. A rolling three-month total differs from the previous three nonempty transactions. Missing dates and duplicate ordering keys can change the result. INFO metadata functions can help inspect objects or dependencies, but they do not replace ordinary measures and may require particular permissions or tools. If a measure is wrong, simplify context changes before changing storage mode. Exam distinctions include scalar versus table expressions, row context versus filter context, and a stored variable value versus a context-dependent measure reference.

Scenario: A developer stores [Revenue] in a variable, then expects CALCULATE of that variable under a different Region filter to recalculate revenue. Why does the value stay unchanged?

Answer: The variable already holds the result evaluated in its defining context. Apply CALCULATE to the measure expression where reevaluation is intended, or define the variable inside the appropriate context. Validate with two regions whose revenues differ so that the context mistake is visible.

Recall: When does SUMX solve a different problem from SUM? What must be specified to make a rolling window deterministic when timestamps repeat?

Implement calculation groups, dynamic format strings, and field parameters

These three features solve different reuse and presentation problems. Calculation groups apply reusable transformations to explicit measures, such as a family of time comparisons. Dynamic format strings control numeric presentation without converting the measure into text. Field parameters let report users choose among supported fields or explicit measures used in a visual. A calculation group changes how a measure is evaluated; a format string changes how its value is displayed; a field parameter changes the selected field or measure. None is a security boundary.

Create explicit base measures and validate them first. For a calculation group, define each calculation item's intent and use SELECTEDMEASURE where appropriate; test interactions and precedence if multiple groups exist. For dynamic formatting, return valid format strings and verify totals, currencies, percentages, and blanks. For field parameters, define the allowed fields or explicit measures and test single and multiple selections in supported visuals. Check current model and client limitations, and ensure users can still understand the resulting axis and measure labels.

Northstar has Revenue and Profit measures. A time calculation group can apply Current and Prior Year transformations to either measure, avoiding separate copies of every time-comparison formula. A Margin % measure keeps its numeric value 0.25 while a dynamic format displays 25.0%. A field parameter lets a report reader switch the chart between Revenue and Profit or between Product and Region. Using FORMAT to turn every numeric result into a string may impair numerical behavior; dynamic formatting preserves the number when that is the requirement.

Test combinations, not only features in isolation. A currency conversion group and a time-intelligence group can interact through precedence. A calculation item intended for numeric measures may fail on a text title measure unless guarded appropriately. Field parameters have supported-visual and connection limitations, and implicit aggregations are not interchangeable with explicit measures in every scenario. If a total displays the wrong unit, inspect selection ambiguity and formatting logic. In exam questions, identify whether the requested capability is reusable calculation, dynamic numeric formatting, or user-directed field selection.

Scenario: A report must let users switch between Revenue and Profit while keeping both measures governed centrally. Which feature fits the visual selection requirement?

Answer: A field parameter referencing explicit measures can drive the selection in supported visuals. Keep the measures in the governed model and verify the selection labels and formatting. A calculation group would be appropriate for applying a common transformation to measures, while a format string alone cannot select a different measure.

Recall: Why is a numeric value with a dynamic format different from FORMAT returning text? What should be tested when two calculation groups affect the same measure?

Identify use cases for and configure large semantic model storage format

Large semantic model storage format supports model growth and can improve particular model-management operations on supported capacity. It is a storage configuration, not unlimited memory or automatic performance tuning. The capacity still has resource limits, and refresh can require additional working memory beyond the final stored size. A large inefficient model can remain slow after enabling the setting. Reduce unnecessary columns and rows, choose efficient types, and design refresh before treating capacity settings as the only solution.

Estimate model size, growth, refresh working set, and concurrency. Confirm current capacity, licensing, and feature support. Enable the supported large-model storage setting in the semantic-model configuration or supported management workflow. Verify that the change completed and that refresh and queries still work. Plan incremental refresh or partition management for large imported facts where appropriate. Monitor refresh duration, memory pressure, query latency, and eviction behavior. Document the actual capacity constraints rather than hard-coding a remembered historical limit into the architecture.

Northstar expects a sales history model to grow from a moderate size to several years of detailed rows. Before increasing capacity, the team removes unused free-text notes, separates high-cardinality technical identifiers from ordinary analysis, and implements a justified refresh policy. It enables the large-model storage format on a supported capacity and tests the first full load plus later incremental runs. A successful small test refresh is insufficient because the initial historical load has a different resource profile. The release evidence includes both phases and representative concurrent report queries.

Do not confuse on-disk model size with active memory requirements or source size. Compression depends on cardinality and distribution; a narrow table with unique long strings can be expensive. If a refresh fails, inspect capacity pressure, source duration, partition design, and operation limits. A storage setting cannot repair a broken connection or unsupported transformation. On the exam, large storage format addresses supported model growth and management, while model reduction, refresh strategy, and query optimization remain separate responsibilities.

Scenario: Enabling large-model storage format does not prevent refresh failures during concurrent workloads. What should be measured next?

Answer: Measure refresh working memory, capacity utilization, concurrent operations, source query duration, and partition behavior. Remove unnecessary model data and schedule or partition processing appropriately. The storage format does not remove capacity limits or guarantee that a full historical refresh fits alongside every other workload.

Recall: Why can refresh require more memory than the final model? Which column characteristics commonly increase model size disproportionately?

Design and build composite models

A composite model combines supported tables or sources with differing storage behavior. A common pattern uses imported dimensions with a DirectQuery fact, sometimes using Dual mode where supported and appropriate. Other supported designs extend remote semantic models or combine Direct Lake on OneLake with Import tables. These combinations have different limitations. Relationships across source groups can behave differently from regular relationships within one source. Treat a composite design as an explicit architecture with query, security, and refresh consequences rather than a universal way to mix anything.

Identify why one mode is insufficient. Map each table to its source, storage mode, refresh owner, and security route. Check current support for the exact combination, including Direct Lake variant and authoring tool. Define relationships and understand whether they are regular or limited. Test queries that stay within one source and queries that cross sources. Validate data freshness mismatch, security identity, and aggregate correctness. Measure source query load and data movement under representative slicers and concurrency before accepting the design.

Northstar keeps a large transaction fact in a supported DirectQuery source and imports small planning assumptions maintained elsewhere. A report compares actual revenue with plan. The plan refreshes daily while actuals can change during the day, so the report must communicate those different clocks. If Product exists independently in both sources, the team needs a deliberate conformed dimension and relationship design. Matching labels do not guarantee matching keys. A query that combines both sides can be more expensive than a query confined to the imported table.

Dual mode is not a promise that every table always stays in memory or that every cross-source query becomes a single source query. Its behavior depends on query context and relationships. A remote semantic-model connection also carries permission and chain limitations that must be checked. If a visual fails only when fields from two sources are combined, investigate cross-source relationships, unsupported combinations, identity, and query translation. The exam distinction is between deliberate composite storage behavior and duplicating an entire source simply to avoid understanding its boundaries.

Scenario: A report combines a current DirectQuery actuals table with yesterday's imported budget assumptions. The two sides disagree after a budget update. Is that necessarily a relationship defect?

Answer: No. Check each table's freshness and refresh owner first. The imported assumptions remain at their last refresh until updated. After aligning the intended data versions, validate keys and relationships. Document the freshness contract so that expected timing differences are not misdiagnosed as calculation errors.

Recall: Why should cross-source queries be tested separately? What problem is Dual mode intended to address, and why is it not a universal performance guarantee?

DAX workshop: context before cleverness

Consider Product with two rows, P1 in Hardware and P2 in Accessories. Sales has P1 revenue 40 and P2 revenue 15. A matrix groups by Category. A base Revenue measure should return 40, 15, and a total of 55. Start here before adding time intelligence, calculation groups, or complex filters. If the base matrix fails, a more sophisticated formula may conceal the broken relationship instead of correcting it.

Now define Hardware Revenue as CALCULATE([Revenue], Product[Category] = "Hardware"). At an Accessories row, a plain filter argument on the same column can replace the existing Category filter, returning Hardware revenue. If the intent is to intersect with the row's current selection, KEEPFILTERS changes that behavior. If the intent is to calculate a fixed Hardware reference regardless of the row, replacement might be deliberate. Neither syntax is universally correct; the expected result determines which one matches the measure's contract.

Next define Revenue Share as the current revenue divided by revenue with the Category filter removed. On the two-category fixture, shares are about 72.73% and 27.27%. Decide which other filters remain: Year, Region, and Customer might need to stay active. Removing all filters from the entire fact table can erase more context than intended. Prefer expressing the denominator's business scope precisely, then test a selected region and year. A measure named Share is incomplete documentation unless it states share of what.

A row iterator adds another distinction. SUMX(Sales, Sales[Quantity] * Sales[UnitPrice]) computes each line amount and sums it. SUM(Sales[Quantity]) multiplied by SUM(Sales[UnitPrice]) generally does something different because it multiplies aggregates. For quantities two and one with prices 20 and 15, the correct line sum is 55, while the product of sums is 105. This small fixture is more useful than a large dataset with identical prices, where a mistaken formula may appear plausible.

Variables help name the parts of a calculation, but their scope must be understood. Suppose CurrentRevenue is assigned [Revenue] and then passed to CALCULATE with another year filter. CurrentRevenue is already a scalar value, so it does not become a fresh measure evaluation. Write CALCULATE([Revenue], ...) when the measure must be evaluated under the new context. A variable can still hold that transformed result after it is computed. The distinction is about evaluation timing, not a rule that variables and CALCULATE cannot be used together.

Finally, test blanks and zero denominators. A blank can communicate absence of data, while zero can communicate a known zero result. Replacing every blank with zero may fill a sparse visual with misleading categories or increase query work. Choose the display and calculation behavior intentionally. A finance report might need zeros for approved combinations while an exploratory report might prefer blanks for missing combinations. DAX correctness includes these user-visible meanings as well as arithmetic.

Window and metadata investigation

A window calculation needs a relation over which rows are ordered. For a monthly running total, the relation should identify months unambiguously, such as a unique MonthStart or YearMonth key. MonthName alone repeats across years and sorts alphabetically unless another ordering is supplied. A three-row window over transactions is not a three-month window. Missing months must be considered if the requirement means calendar time rather than the last three observed records.

Write a paper fixture before using WINDOW: January revenue 10, February 20, March 30, and April 40. A trailing three-calendar-month total is 10, 30, 60, and 90 if earlier missing history contributes no amount. Remove February from the fact table while keeping a complete Date dimension, then decide whether the intended result still spans calendar months. This exercise identifies whether the relation should come from the calendar or from observed transactions. Once the contract is explicit, choose supported WINDOW arguments and validate the query in the actual model.

Information functions address another task: inspecting metadata such as tables, columns, measures, relationships, or dependencies through supported DAX query capabilities. They can help produce a model inventory or investigate why an object exists. Check the specific INFO function's permissions and supported execution context. Do not assume that every metadata function is permitted in a calculated column or every client. Metadata visibility can itself be sensitive, so run inspection under the intended administrative or authoring identity.

The purpose of metadata inspection is to answer a concrete question. For example, before removing a measure, inventory its definition and examine dependencies through supported tools. A list of object names alone cannot establish that deletion is safe; reports and external consumers may also need impact analysis. Combine model metadata with the lifecycle process from the earlier chapter. This keeps DAX information functions connected to an operational use case rather than treating them as isolated trivia.

Model acceptance matrix

Use four personas: a model author, a West consumer, an East consumer, and a user with no entitlement. Use four query shapes: a single region total, a product breakdown, a date comparison, and a grand total. For each combination, record expected visible data and expected denied behavior. The author may legitimately have broader access, so their results cannot substitute for consumer tests. A visually hidden field should also be tested through an authorized model-query tool if confidentiality is required.

For correctness, include an unmatched dimension key, a customer with two accounts, a budget value at a coarser grain, and a date with no transactions. These cases expose relationship and total behavior that ordinary happy-path data often misses. For usability, inspect field names, descriptions, date roles, format strings, and default summarization. For performance, collect representative cold and warm timings without changing the query population between runs. For lifecycle, reopen a clean project and validate that the reviewed definition produces the same results.

A model is ready for downstream report authors when these contracts are understandable and tested. It is not necessary to expose every source column. A curated field list and a small set of explicit, documented measures can reduce errors more effectively than a large unstructured model. DP-600 evaluates the ability to build and manage analytical assets; the strongest preparation connects relationship mechanics and DAX syntax to the quality of the resulting analytical experience.

Operational lab: calculations you can inspect

Use an authorized test model with a complete Date table containing Date and a unique MonthStart value for each month. Relate Date to the sales fact through the intended date role. The following expressions assume explicit Revenue and Profit measures exist and that the Date table is suitable for the chosen time-intelligence functions. Use fabricated data so you can verify every result manually. These are authored examples, not copied Microsoft sample solutions.

For a calculation group, create a Current item whose expression is SELECTEDMEASURE(). Create a Prior Year item with an expression such as:

CALCULATE (
    SELECTEDMEASURE (),
    DATEADD ( 'Date'[Date], -1, YEAR )
)

Place the group's selection column on a slicer or the columns of a matrix, then display Revenue and Profit. Use an isolated year with known current and prior-year values. Current must return the ordinary measure, and Prior Year must return the corresponding prior-period measure under the other retained filters. If a Region selection disappears, inspect the base measure and context modification. If the date selection is irregular, test the supported time-intelligence semantics rather than assuming every date-shifting expression treats gaps identically.

Dynamic formatting is a separate experiment. Keep a numeric measure and define its dynamic format string expression based on the selected currency:

SWITCH (
    SELECTEDVALUE ( Currency[Code] ),
    "USD", "$#,0.00",
    "EUR", "€#,0.00",
    "#,0.00"
)

This expression selects a display format; it does not convert currencies. A value of 100 remains 100. Actual currency conversion requires an approved exchange-rate calculation and date basis. Test the no-selection and multi-selection cases, which use the default format here. Also test a total that combines currencies: a generic numeric format does not make the combined amount economically meaningful. The model should prevent or explain unsupported mixed-currency totals.

For field parameters, use the supported authoring interface to create a parameter containing the existing explicit Revenue and Profit measures. Add its field to the supported visual field well and its selector to a slicer. Select each measure and then both if the visual supports it. Confirm that the values, title, and format communicate what is selected. A field parameter does not create a new revenue definition, and removing a measure from the selector does not prevent an otherwise authorized user from querying it elsewhere.

Operational lab: an ordered DAX window

Prepare four months with Revenue values 10, 20, 30, and 40 and ensure the visual uses Date[MonthStart] in chronological order. The following illustrative measure sums the current and previous two selected month rows:

Trailing Three Selected Months =
IF (
    ISINSCOPE ( 'Date'[MonthStart] ),
    SUMX (
        WINDOW (
            -2, REL, 0, REL,
            ALLSELECTED ( 'Date'[MonthStart] ),
            ORDERBY ( 'Date'[MonthStart], ASC )
        ),
        [Revenue]
    )
)

With all four contiguous months selected, expected values are 10, 30, 60, and 90. The grand total is intentionally blank because this example defines a month-row result, not a separate total contract. The relation passed to WINDOW contains selected month rows. If February is excluded by a slicer, the previous two selected rows are not necessarily the previous two calendar months. That is why the measure name explicitly says Selected Months. Change the relation deliberately if the business requires a calendar-contiguous window independent of that selection.

Now add a second year. MonthStart remains unique across years, while a MonthName column alone would not. If the calculation must restart within another grouping, define the required relation and partitioning explicitly and test the boundary. Do not infer partitioning from the visual's visual proximity. The key learning outcome is to connect WINDOW's relation and ordering to an expected set of rows before summing a measure over them.

For metadata inspection, run a supported query such as EVALUATE INFO.VIEW.MEASURES() in a suitable DAX query context with the required permissions. Inspect the returned measure metadata and compare it with the model's field list. This query returns information about the model; it does not calculate sales. If the function is unavailable in the current client or context, verify current function support and permissions rather than substituting it into a calculated column. Use metadata findings alongside impact analysis when considering a rename or removal.

Sources and provenance

The measured objectives follow the DP-600 blueprint effective July 21, 2026. Product references were retrieved for this edition; the book manifest records the actual retrieval time and SHA-256 of each downloaded HTML response. Examples and scenarios are original teaching material. Shared field guides reuse this project’s original DP-700 writing where the underlying Fabric concepts apply. Microsoft Learn remains authoritative, especially for current feature support and capacity limits.

• Study guide for Exam DP-600: Implementing Analytics Solutions Using Microsoft Fabric
• Semantic model modes in the Power BI service - Power BI
• Understand star schema and the importance for Power BI - Power BI
• Model relationships in Power BI Desktop - Power BI
• Many-to-many relationship guidance - Power BI
• DAX overview - DAX
• CALCULATE function (DAX) - DAX
• Use variables to improve your DAX formulas - DAX
• WINDOW function (DAX) - DAX
• INFO functions (DAX) - DAX
• Create calculation groups in Power BI - Power BI
• Create dynamic format strings for measures - Power BI
• Use Field Parameters in Power BI Reports - Power BI
• Large semantic models in Power BI Premium - Microsoft Fabric
• Use composite models in Power BI Desktop - Power BI