DAX Survey and Likert Scale Patterns: Calculating Weighted Scores, Response Distribution, and Net Promoter Score Measures Across Dynamic Respondent Segments

Introduction

Picture this: your organization just finished a global employee engagement survey — 4,200 respondents across 18 departments, answering 32 questions on a 5-point Likert scale, plus a Net Promoter Score question. The raw data lands in your Power BI model and your stakeholders want everything: weighted averages that account for department headcount, response distribution breakdowns for each question, NPS by region and tenure cohort, and the ability to slice all of it by role, manager, location, and survey wave simultaneously. Oh, and the VP wants to drill into any segment without breaking a single measure.

This is the scenario that exposes the limits of basic DAX knowledge fast. Survey analytics look deceptively simple — "just average some numbers" — but the moment you introduce dynamic segmentation, weighted calculations, percentage distributions that must always sum to 100%, and NPS logic that demands you classify respondents rather than aggregate raw values, you're dealing with patterns that require genuine mastery of filter context, iterator functions, and virtual table construction. A naive approach produces measures that silently return wrong numbers when users apply slicers, or that collapse to blank in edge cases that surface in production.

By the end of this lesson, you'll be able to design a complete DAX measurement layer for survey and Likert scale data that handles all of this correctly. You'll understand not just the formulas, but why each pattern works, where it breaks down, and how to make it fast enough for enterprise-scale survey datasets.

What you'll learn:

• How to model survey data for DAX efficiency, including the tradeoffs between wide and tall (unpivoted) schemas
• Weighted score calculations that respect dynamic filter context and survive slicers intact
• Response distribution measures that always produce correct percentages across any segmentation
• Net Promoter Score calculation in DAX, including Promoter/Passive/Detractor classification and the NPS formula
• Segment-aware measures that work correctly whether a user has filtered by one department or 17

---

Prerequisites

You should be comfortable with:

• DAX filter context and how CALCULATE modifies it — if you need a refresher, Master DAX CALCULATE and Filter Context in Power BI is the right starting point
• Iterator functions like SUMX and AVERAGEX — DAX Iterators Explained: How SUMX, AVERAGEX, and MAXX Evaluate Row by Row to Solve Problems SUM Cannot covers these thoroughly
• Variable declarations with VAR/RETURN — essential for the multi-step measures in this lesson; see DAX Variables in Practice: Using VAR and RETURN to Simplify Complex Measures
• Basic understanding of how filters flow through relationships in Power BI

---

The Right Data Model for Survey Analytics

Before writing a single measure, let's talk about schema design, because the wrong model makes correct DAX nearly impossible and the right model makes it elegant.

Wide vs. Tall: The Fundamental Choice

Survey data arrives in two typical shapes. The wide format has one row per respondent and one column per question:

RespondentID | Q1_Score | Q2_Score | Q3_Score | ... | NPS_Score | Department | Tenure
R001         | 4        | 3        | 5        | ... | 8         | Engineering | 2-5yr
R002         | 2        | 4        | 4        | ... | 9         | Marketing   | <1yr

The tall (unpivoted) format has one row per respondent-question combination:

RespondentID | QuestionID | Score | Department | Tenure
R001         | Q1         | 4     | Engineering | 2-5yr
R001         | Q2         | 3     | Engineering | 2-5yr
R001         | NPS        | 8     | Engineering | 2-5yr
R002         | Q1         | 2     | Marketing   | <1yr

For DAX, the tall format wins decisively. Here's why: in the tall model, every single measure you write uses the same CALCULATE + filter pattern to focus on any question. In the wide model, you need separate measures for every question (or brittle SWITCH logic against column names), and aggregations across questions require painful unpivoting in DAX itself using virtual tables — possible but slow.

Recommended Table Structure

Design three core tables:

Responses (the fact table, tall format):

• ResponseID — surrogate key
• RespondentID — foreign key to Respondents
• QuestionID — foreign key to Questions
• Score — numeric response value (1–5 for Likert, 0–10 for NPS)
• SurveyWaveID — foreign key to SurveyWaves

Respondents (dimension):

• RespondentID
• Department
• Region
• Tenure (bucketed: <1yr, 1-2yr, 2-5yr, 5+yr)
• Role
• Weight — this column is critical for weighted scoring (more on this shortly)

Questions (dimension):

• QuestionID
• QuestionText
• Category (e.g., "Engagement", "Culture", "NPS")
• Scale ("Likert5", "Likert7", "NPS")

SurveyWaves (dimension):

• SurveyWaveID
• WaveName
• WaveDate

This gives you a proper star schema where every slicer on the Respondents or Questions table filters the Responses fact table directly. Department, tenure, region — all of them flow through relationships without a single CALCULATE override needed for basic filtering.

---

Building the Foundation: Basic Likert Averages

With the model in place, start simple. The most fundamental measure is a plain average score:

Avg Score = 
AVERAGE( Responses[Score] )

This works, but it has no defensive logic and will produce misleading results when the current filter context includes NPS question rows (scored 0–10) alongside Likert rows (scored 1–5). Add a question category filter from the start:

Avg Likert Score = 
CALCULATE(
    AVERAGE( Responses[Score] ),
    Questions[Scale] = "Likert5"
)

Now any slicer on Department, Region, or Tenure flows through the Respondents table → Responses table relationship, and the CALCULATE adds an additional filter on the Questions table. Both filters stack correctly because CALCULATE merges them in an AND relationship.

---

Weighted Score Calculations

Here's where the interesting complexity begins. A simple average treats a response from a 10-person department identically to one from a 500-person department. If your survey has different response rates across segments, or if your business explicitly wants to weight by headcount rather than response count, you need weighted averages.

The formula for a weighted average is:

Weighted Average = SUM(Score × Weight) / SUM(Weight)

The Weight column lives on the Respondents table. You cannot use AVERAGE directly — you need SUMX to iterate and multiply.

Weighted Avg Score = 
VAR WeightedNumerator = 
    CALCULATE(
        SUMX(
            Responses,
            Responses[Score] * RELATED( Respondents[Weight] )
        ),
        Questions[Scale] = "Likert5"
    )
VAR WeightedDenominator = 
    CALCULATE(
        SUMX(
            Responses,
            RELATED( Respondents[Weight] )
        ),
        Questions[Scale] = "Likert5"
    )
RETURN
    DIVIDE( WeightedNumerator, WeightedDenominator )

Let's dissect this. SUMX iterates over every row in the Responses table that's visible in the current filter context. For each row, RELATED pulls the Weight from the Respondents table — this works because we're inside SUMX's row context, which provides the join key. The denominator sums those same weights, giving us a proper weighted divisor.

DIVIDE handles the division safely, returning BLANK() if the denominator is zero rather than a division error.

Why RELATED Works Here

RELATED is valid inside SUMX because SUMX creates a row context over the Responses table. Each row has a RespondentID, and the relationship to Respondents is active, so RELATED can traverse it. If you tried to use RELATED outside an iterator — in a plain CALCULATE — it would error. This is the row context vs. filter context distinction that Row Context vs Filter Context: The Mental Model Every DAX User Needs explains in depth.

Weight Design Decisions

How should you populate the Weight column? Three common approaches:

1. Population proportion: Set weight = department headcount / total company headcount. This makes the weighted average represent company-level truth rather than survey-participant truth.
2. Post-stratification weights: Statistical technique where you compute weights so your sample demographics match target demographics. Usually done in your ETL pipeline, not DAX.
3. Equal weights (weight = 1): Your weighted average collapses to a plain average. Useful as a "no-op" default so the same measure works regardless of whether weighting is enabled.

---

Response Distribution: Percentages That Always Sum to 100%

Stakeholders don't just want averages — they want to see the shape of the distribution. How many people scored 1? How many scored 5? This is a classic challenge because you need the percentage denominator to come from the correct total, regardless of how many response values exist in the current filter context.

First, build the count of responses for a specific score value:

Response Count Score 1 = 
CALCULATE(
    COUNTROWS( Responses ),
    Responses[Score] = 1,
    Questions[Scale] = "Likert5"
)

This is fine as a concrete measure, but you'll want a reusable pattern. Create a base measure first:

Total Likert Responses = 
CALCULATE(
    COUNTROWS( Responses ),
    Questions[Scale] = "Likert5"
)

Then the percentage for any score value:

Pct Score 1 = 
VAR ScoreCount = 
    CALCULATE(
        COUNTROWS( Responses ),
        Responses[Score] = 1,
        Questions[Scale] = "Likert5"
    )
VAR TotalCount = [Total Likert Responses]
RETURN
    DIVIDE( ScoreCount, TotalCount )

The Dynamic Distribution Pattern

The real power move is building a measure that produces a percentage for whatever score value is currently in the filter context, rather than hard-coding Score = 1, Score = 2, etc. This lets you use a single measure in a matrix visual with scores on rows or columns.

Response % by Score = 
VAR CurrentScoreContext = SELECTEDVALUE( Responses[Score] )
VAR ScoreCount = COUNTROWS( Responses )
VAR TotalCount = 
    CALCULATE(
        COUNTROWS( Responses ),
        ALL( Responses[Score] ),
        Questions[Scale] = "Likert5"
    )
RETURN
    IF(
        NOT ISBLANK( CurrentScoreContext ),
        DIVIDE( ScoreCount, TotalCount ),
        DIVIDE(
            CALCULATE( COUNTROWS( Responses ), Questions[Scale] = "Likert5" ),
            TotalCount
        )
    )

Here's the key: ALL( Responses[Score] ) inside CALCULATE removes the filter on the Score column while preserving every other active filter — Department, Region, Survey Wave, etc. This means TotalCount is "total responses in this segment, across all score values." Dividing ScoreCount by that gives you a percentage that correctly sums to 100% within any segment.

Visualizing Distribution

For a bar chart showing distribution of scores for a selected question:

• Put Responses[Score] on the X-axis
• Use Response % by Score as the value
• Put question filters on a slicer

When a user picks "Q7: I feel recognized for my contributions," the visual shows what percentage of respondents scored 1, 2, 3, 4, or 5 — and those percentages sum to exactly 100% because of the ALL(Responses[Score]) pattern above.

---

Net Promoter Score in DAX

NPS is the most widely requested survey metric in Power BI, and it's also the one most commonly implemented incorrectly. Let's be precise about the definition before writing code.

NPS is calculated from a 0–10 scale question ("How likely are you to recommend us to a friend or colleague?"):

• Promoters: Score 9 or 10
• Passives: Score 7 or 8
• Detractors: Score 0 through 6

NPS = (% Promoters) − (% Detractors)

The result ranges from −100 (everyone is a detractor) to +100 (everyone is a promoter). Passives are included in the denominator when calculating percentages but don't contribute to the final score — they're the "meh" middle ground.

Building the NPS Measures

Start with the classification counts:

NPS Respondent Count = 
CALCULATE(
    COUNTROWS( Responses ),
    Questions[Category] = "NPS"
)

NPS Promoter Count = 
CALCULATE(
    COUNTROWS( Responses ),
    Questions[Category] = "NPS",
    Responses[Score] >= 9
)

NPS Passive Count = 
CALCULATE(
    COUNTROWS( Responses ),
    Questions[Category] = "NPS",
    Responses[Score] >= 7,
    Responses[Score] <= 8
)

NPS Detractor Count = 
CALCULATE(
    COUNTROWS( Responses ),
    Questions[Category] = "NPS",
    Responses[Score] <= 6
)

Now calculate percentages and the final NPS:

NPS Promoter % = 
DIVIDE( [NPS Promoter Count], [NPS Respondent Count] )

NPS Detractor % = 
DIVIDE( [NPS Detractor Count], [NPS Respondent Count] )

Net Promoter Score = 
VAR PromoterPct = [NPS Promoter %]
VAR DetractorPct = [NPS Detractor %]
VAR NPSResult = ( PromoterPct - DetractorPct ) * 100
RETURN
    IF( [NPS Respondent Count] > 0, NPSResult )

The multiplication by 100 converts the decimal percentage to the conventional NPS integer scale. The IF guard returns BLANK when there are no NPS respondents — preventing a misleading zero from appearing in segments where the survey wasn't deployed.

Dynamic Segmentation of NPS

The beauty of this design is that slicers work automatically. Drop Department, Region, or Tenure onto slicers, and NPS recalculates for that exact segment because the Respondents table filters flow through the relationship to Responses.

For a matrix showing NPS by department and tenure in a single visual:

• Put Department on Rows
• Put Tenure on Columns
• Use [Net Promoter Score] as the value

Every cell correctly calculates NPS for that specific department × tenure intersection with no additional measure modifications needed. This is filter context doing exactly what it's designed for.

NPS Benchmark Comparison

Stakeholders often want to compare NPS against a benchmark or prior wave. Build a benchmark comparison measure using a disconnected parameter table or a calculated reference:

NPS vs Benchmark = 
VAR CurrentNPS = [Net Promoter Score]
VAR BenchmarkNPS = 42  -- Industry benchmark, could be from a parameter table
RETURN
    IF( NOT ISBLANK( CurrentNPS ), CurrentNPS - BenchmarkNPS )

For a dynamic benchmark loaded from a reference table (SurveyBenchmarks[BenchmarkNPS]), use LOOKUPVALUE or a relationship with SELECTEDVALUE to make it respond to wave or category filters.

---

Advanced Pattern: Segment-Aware Score Indexing

One of the most analytically useful survey patterns is the score index — expressing each segment's average score as a percentage of the maximum possible, or relative to the overall average. This allows you to say "Engineering scored 12% above company average on question Q14."

Score Index vs Overall = 
VAR SegmentAvg = [Avg Likert Score]
VAR OverallAvg = 
    CALCULATE(
        [Avg Likert Score],
        ALL( Respondents[Department] ),
        ALL( Respondents[Region] ),
        ALL( Respondents[Tenure] )
    )
RETURN
    DIVIDE( SegmentAvg - OverallAvg, OverallAvg )

The ALL() calls on specific dimension columns remove those filters from the overall calculation while preserving any question filters that might be active. The result: if a user has filtered to Q14 and selected the Engineering department, this measure returns Engineering's score on Q14 expressed as a percentage deviation from the company-wide Q14 average.

Top and Bottom Box Scoring

For Likert scales, many practitioners use "Top 2 Box" (% who scored 4 or 5 on a 5-point scale) and "Bottom 2 Box" (% who scored 1 or 2) as summary metrics. These are more actionable than averages for leadership communication.

Top 2 Box % = 
VAR TopCount = 
    CALCULATE(
        COUNTROWS( Responses ),
        Questions[Scale] = "Likert5",
        Responses[Score] >= 4
    )
VAR TotalCount = [Total Likert Responses]
RETURN
    DIVIDE( TopCount, TotalCount )

Bottom 2 Box % = 
VAR BottomCount = 
    CALCULATE(
        COUNTROWS( Responses ),
        Questions[Scale] = "Likert5",
        Responses[Score] <= 2
    )
VAR TotalCount = [Total Likert Responses]
RETURN
    DIVIDE( BottomCount, TotalCount )

Net Favorable Score = [Top 2 Box %] - [Bottom 2 Box %]

Net Favorable Score is structurally identical to NPS — subtract the unfavorable percentage from the favorable percentage — and it's useful for presenting Likert results in the same intuitive format as NPS.

---

Handling Multiple Survey Waves: Period-Over-Period Comparisons

Survey data almost always spans multiple waves, and stakeholders want trend analysis. Which questions improved? Which departments moved? The patterns here lean on Time Intelligence in DAX: YTD, MTD, Previous Period, and Rolling Averages, but survey waves aren't regular calendar periods — they're typically quarterly or annual events with specific wave IDs.

Since you're working with wave IDs rather than continuous dates, use a filtering pattern rather than time intelligence functions:

NPS Prior Wave = 
VAR CurrentWave = SELECTEDVALUE( SurveyWaves[WaveDate] )
VAR PriorWave = 
    CALCULATE(
        MAX( SurveyWaves[WaveDate] ),
        SurveyWaves[WaveDate] < CurrentWave
    )
RETURN
    IF(
        NOT ISBLANK( PriorWave ),
        CALCULATE(
            [Net Promoter Score],
            SurveyWaves[WaveDate] = PriorWave,
            ALL( SurveyWaves )
        )
    )

This measure finds the most recent wave prior to the currently selected wave and calculates NPS for that prior wave. The ALL( SurveyWaves ) removes the current wave filter before applying the prior wave filter — a classic pattern for "look at a specific different period."

NPS Wave Change = [Net Promoter Score] - [NPS Prior Wave]

Format NPS Wave Change with a conditional formatting rule: green for positive, red for negative, neutral for near-zero. This gives stakeholders an immediate visual signal of trend direction.

---

Respondent-Level Classification with Calculated Columns

Some analyses require classifying each respondent as a Promoter, Passive, or Detractor at the row level — for example, if you want to build a cohort analysis of Promoters or cross-tabulate NPS classification against department survey scores.

For row-level classification, use a calculated column on the Responses table:

-- Calculated column on Responses table
NPS Classification = 
IF(
    RELATED( Questions[Category] ) = "NPS",
    SWITCH(
        TRUE(),
        Responses[Score] >= 9, "Promoter",
        Responses[Score] >= 7, "Passive",
        "Detractor"
    ),
    BLANK()
)

RELATED( Questions[Category] ) traverses the relationship from Responses to Questions to check whether this row is an NPS response. For non-NPS rows, the column returns BLANK — keeping the classification column meaningful and clean.

With this calculated column, you can now:

• Slice any visual by NPS Classification to see how Promoters scored on engagement questions vs. Detractors
• Use it in dynamic segmentation measures
• Build bar charts that simultaneously show engagement scores and NPS classification for the same respondents

---

Statistical Confidence and Response Rate Measures

Enterprise survey analytics should always surface response rates alongside scores. A 95% score from 3 respondents is meaningless; the same score from 300 respondents is significant.

Response Rate = 
VAR TotalRespondents = COUNTROWS( Respondents )
VAR ActualRespondents = 
    CALCULATE(
        DISTINCTCOUNT( Responses[RespondentID] ),
        Questions[Category] = "NPS"  -- or any category as proxy for survey completion
    )
RETURN
    DIVIDE( ActualRespondents, TotalRespondents )

For NPS specifically, you should suppress the NPS display when the response count is too low to be statistically meaningful. A common threshold is n < 10 or n < 30 depending on your organization's standards:

NPS (Qualified) = 
VAR RespondentCount = [NPS Respondent Count]
VAR MinimumThreshold = 10
RETURN
    IF(
        RespondentCount >= MinimumThreshold,
        [Net Promoter Score],
        "n < " & MinimumThreshold  -- Returns a string when threshold not met
    )

For a more rigorous approach, you can implement confidence intervals using the standard error of a proportion, which Building Statistical Measures in DAX: Percentiles, Standard Deviation, and Outlier Detection for Analytical Reporting covers in depth. Applied to NPS, the margin of error for the promoter percentage at 95% confidence is approximately 1.96 * SQRT( PromoterPct * (1 - PromoterPct) / N ).

---

Performance Optimization for Large Survey Datasets

With 4,200 respondents × 32 questions = 134,400 rows, performance is manageable. At 50,000 respondents × 50 questions = 2,500,000 rows, you'll start feeling it. Here are the key optimizations:

Avoid Row-by-Row FILTER Where Possible

The pattern CALCULATE(..., FILTER(Responses, Responses[Score] >= 9)) forces a row-by-row scan. The equivalent column-filter syntax CALCULATE(..., Responses[Score] >= 9) pushes the filter to the storage engine where column indexes make it dramatically faster. Always use the scalar column filter syntax when the condition is simple.

Pre-Aggregate in Your ETL When Appropriate

If stakeholders only ever look at NPS by Department, Region, and Tenure (not individual respondents), pre-aggregate to a summary table in your ETL and query that in your model. The DAX patterns are identical; you just apply them to a smaller table.

Use SUMMARIZECOLUMNS in DAX Queries for Batch Extraction

When you need to extract survey summaries programmatically, use SUMMARIZECOLUMNS in DAX Query View rather than matrix visuals. It's the most efficient aggregation function for grouped results. The DAX Query View Mastery article covers this pattern.

Cache Expensive Base Measures

If you find yourself computing [Total Likert Responses] inside multiple measures, each measure independently queries the engine. Consider creating explicit helper measures for expensive computations that many other measures reference — they're cached during a single visual render.

---

Hands-On Exercise

Implement the following in a Power BI Desktop file using the schema described in this lesson. Use the sample data structure below (build it in Power Query from CSV or use Enter Data).

Exercise Dataset:

• 100 respondents, 10 questions (Q1-Q9 on Likert5, Q10 as NPS)
• 4 departments: Engineering, Marketing, Operations, HR
• 3 tenure buckets: <1yr, 1-3yr, 3+yr
• 2 waves: Wave 1 (Q1 2024), Wave 2 (Q3 2024)

Tasks:

1. Build the three-table star schema (Responses, Respondents, Questions)

2. Create these measures and verify they produce correct results:

   • Avg Likert Score — plain average excluding NPS rows
   • Weighted Avg Score — using respondent weights (assign weight = 1.5 to 3+yr tenure, 1.0 to others)
   • Top 2 Box % — percentage scoring 4 or 5 on Likert questions
   • Net Promoter Score — correct NPS formula

3. Build a matrix visual with Department on rows and these four measures as columns. Apply a Tenure slicer and verify:

   • Filtering to 3+yr changes all four measures correctly
   • Top 2 Box % always stays between 0% and 100%
   • NPS changes when you filter and stays in the −100 to +100 range

4. Create NPS Classification as a calculated column on Responses, then build a bar chart that shows Avg Likert Score broken down by NPS Classification (Promoter, Passive, Detractor) for the selected department.

5. Challenge: Add a Response Rate measure and format your NPS card to show "Insufficient data" when fewer than 5 responses are available (useful for small departments at the tenant level).

---

Common Mistakes & Troubleshooting

Mistake 1: Using SUM instead of COUNTROWS for response counts

SUM(Responses[Score]) gives you the total of all scores, not the count of responses. When you mean "how many people responded," always use COUNTROWS(Responses) or COUNT(Responses[Score]). They're usually equivalent when Score has no blanks, but COUNTROWS is explicit and safe.

Mistake 2: NPS denominator includes only Promoters + Detractors

This is a classic conceptual error. The NPS denominator must be ALL respondents (Promoters + Passives + Detractors). Passives are excluded from the numerator difference but not the denominator. Using only Promoters + Detractors inflates NPS in both directions.

Mistake 3: ALL() removes cross-filtering from other tables

When calculating an "overall" value to compare against, using ALL(Responses) removes not just the current segment filter but ALL filters on the Responses table — including those pushed through from other tables. ALL(Respondents[Department]) removes only the department filter and is usually the precise instrument you need.

Mistake 4: Weighted average denominator is wrong under segment filters

If you hard-code the weight denominator as a total company weight, your weighted average won't respond correctly to segment filters. Always calculate the weight denominator as SUMX(Responses, RELATED(Respondents[Weight])) within the same filter context — let it be dynamic.

Mistake 5: Forgetting that CALCULATE arguments are ANDed, not ORed

CALCULATE([Measure], Responses[Score] >= 9, Responses[Score] <= 8) returns blank because no value can be both ≥9 and ≤8. This is obvious when stated directly, but it catches people when they try to filter for "Promoters OR Detractors" by stacking two CALCULATE filters. Use FILTER(Responses, Responses[Score] >= 9 || Responses[Score] <= 6) for OR logic.

Mistake 6: Response distribution percentages exceed 100%

If your distribution percentages are summing to more than 100%, check that you're using ALL(Responses[Score]) in the denominator, not a fixed count. Also verify that your Question filter is the same in both numerator and denominator — if the denominator includes NPS rows (scored 0–10) but the numerator counts Likert rows (scored 1–5), your percentages will be understated.

---

Summary & Next Steps

You've built a complete DAX measurement layer for survey and Likert scale analytics. The core patterns you now have in your toolkit:

• Tall schema design that makes every measure reusable across questions and segments
• Weighted averages using SUMX + RELATED to respect respondent weights dynamically
• Response distribution using column-specific ALL() to maintain segment context while releasing score filters
• Net Promoter Score with correct Promoter/Passive/Detractor classification and segment-aware denominator
• Wave-over-wave comparisons using a prior-period lookup pattern that doesn't require calendar time intelligence
• Row-level classification via calculated columns for cross-sectional analysis
• Threshold suppression to prevent statistically meaningless NPS values from appearing in low-count segments

The techniques here — particularly the ALL(Column) denominator pattern and the weighted SUMX pattern — generalize to many domains beyond surveys. Anywhere you need "percentage of relevant total within current filter context," the distribution pattern applies. Anywhere you need "row-level weight applied through a relationship," the SUMX + RELATED pattern applies.

For next steps in your DAX mastery journey, explore Dynamic Segmentation and Grouping with DAX: Build Flexible Customer Analytics to apply similar segmentation patterns to customer analytics contexts. If your survey data involves complex many-to-many relationships (respondents belonging to multiple teams, for example), DAX for Many-to-Many Relationships and Complex Data Models will be your next essential read.