DAX Fundamentals Part 3: The Patterns That Make Reports Work

You've learned how filter context and CALCULATE actually work. This is where it pays off. Part 3 of the DAX Fundamentals series covers the patterns you'll keep reaching for in real models, and why they behave the way they do.

We get into time intelligence (YTD, QTD, prior cycle, and why these functions return tables of dates rather than numbers), variables for cleaner and faster formulas, and SWITCH as the cure for nested IF chains nobody wants to maintain. Then inactive relationships and USERELATIONSHIP for when one fact table has two date columns fighting over the same date table.

The pattern that saves the most pain is calculation groups. Write three base measures, add one calc group with YTD, Prior Cycle, and YoY%, and you've replaced nine measures (and growing) with something you maintain in one place.

The video closes on the part most people skip: how the engine splits work between the Storage Engine and the Formula Engine, and why pushing work toward simple aggregations on a star schema is the difference between fast DAX and slow DAX.

Building Operational Systems on Databricks (with Andre Landgraf)Building Operational Systems on Databricks - with Andre Landgraf

LIVESTREAM DATE/TIME 📅

June 26th: 9:30 AM (Pacific Time)

DESCRIPTION 📄

There are two broad categories of systems: analytical systems and operational systems. Databricks is primarily known for the former. It’s an OLAP platform where organizations ingest, manage, analyze, and derive value from their data. This includes everything from business intelligence and analytics to machine learning models, AI workloads, and data pipelines.

The resulting insights, predictions, and AI-generated outputs need to flow back into operational systems that can act on them, whether that's powering an internal tool or personalizing a customer experience. This is even more true in the age of AI, where this data becomes context for agents. To make that possible, we need ways to channel analytical data back into operational systems (data apps, AI agents, and more).

In this session, I’ll give an overview of the Databricks capabilities that help operationalize analytical data. We’ll look at services such as Databricks Apps, Lakebase, and other platform components that enable you to build operational and agentic applications directly within your Databricks workspace. Let's vibe code an app from scratch and cover practical vibe coding best practices while integrating data from your lakehouse.

GUEST BIO (Andre Landgraf) 👤

Andre is a passionate developer from Germany who loves building for the web. Based in the Bay Area, he is a Staff Developer Advocate at Databricks. He was previously a Senior Software Engineer at LinkedIn and holds master’s degrees in Information Systems and Computer Science. In his free time, he brings the community together through All Things Web events in San Francisco.

RELATED CONTENT 🔗

Andre's X
Andre's LinkedIn
Databricks DevHub

Materialized Lake Views in Microsoft Fabric: How They Actually Work

Video by: Reid Havens

Every report hitting your raw tables runs the same expensive joins and aggregations over and over, even when the underlying data hasn't moved. Materialized Lake Views in Microsoft Fabric pre-compute those results once and store them as Delta tables in OneLake, so consumers read finished numbers instead of recalculating from scratch.

In this video I cover what MLVs actually are, how the automatic refresh logic decides between skip, incremental, and full rebuild, the Spark SQL syntax to create and manage them, and where they sit in a medallion architecture (think of them as a "Gold+" layer).

The part worth sticking around for: point Direct Lake at an MLV instead of your raw tables and you get pre-aggregated data at import speed. In the example here, a 50 million row fact table collapses to around 500K. Fewer rows means faster transcoding into VertiPaq and a lot less DirectQuery fallback risk. That's the single best reason to pair the two.

I also get into when NOT to use them, because they're not free. Sub-minute volatile data, tiny tables, and row-level security needs are all cases where an MLV is the wrong tool.

Curiosity, Creativity, and Chemistry: How I Stopped Copiloting and Started Collaborating - with James Bartlett

LIVESTREAM DATE/TIME 📅

June 11th 2026 - 9:30 AM (Pacific Time)

DESCRIPTION 📄

Most people use AI assistants like fancy search engines, and the results often leave much to be desired. But James Bartlett isn't most people. He has a personal AI agent named Cray, whom he treats more like a junior colleague, and they have racked up some interesting and impressive achievements together. Cray runs 24/7 on James's home server, managing scheduled jobs, helping James with otherwise boring and repetitive tasks, and building dozens of tools (including an entire PowerShell MCP framework) during unsupervised nightly "innovation sessions."

In this conversation with Reid Havens, James pulls back the curtain on what daily life with an AI partner actually looks like: the good, the weird, the genuinely useful, the unexpectedly wholesome, and the parts that honestly still need some work. If you've wondered what's beyond "prompt engineering," this is that conversation.

GUEST BIO (James Bartlett) 👤

James D. Bartlett III is a Microsoft Data Platform MVP, co-host of The Drill Down with Ahmad & James podcast, and an unapologetic PowerShell enthusiast. By day, he helps organizations wrangle Microsoft Fabric and Power BI at P3 Adaptive, and by night, he tinkers with open-source software projects, home automation, vintage audio gear, local LLMs, and an AI agent named Cray who lives on his LAN and builds handy tools while he sleeps.