Microsoft DP-600: Semantic Model Design in Fabric
A Fabric semantic model is the business layer that turns tables into understandable dimensions, measures, relationships, hierarchies, and terminology for Power BI and other analytical consumers. Good semantic design reduces the number of different ways users calculate the same metric and gives reporting, AI-assisted analysis, and self-service exploration a shared definition of the business.
Current Fabric guidance continues to center semantic modeling around star-schema principles. Direct Lake adds a modern storage mode that can query OneLake-backed Delta data with low-latency analytical behavior, while composite models and other storage modes remain available when a workload needs different capabilities. Storage mode matters, but the model’s clarity is still the more important contract.
Semantic model design belongs inside Microsoft Data Platform Engineering.
Start with a clear business grain
Each fact table should represent one consistent business event or observation, such as a sale, invoice line, support case, or daily balance.
Star schemas make filtering and calculation easier because dimensions describe who, what, where, and when while facts carry measurable events.
Mixing several grains in one table creates DAX ambiguity and makes AI-generated analytical queries less reliable.
Use dimensions for reusable context
Customer, product, date, geography, employee, and other descriptive entities should be modeled as dimensions when they are shared across many measures.
Keep keys and relationships stable and hide technical columns from end users where appropriate.
Power BI relationships should express one clear filter path whenever possible instead of relying on complicated ambiguous propagation.
Define measures as business contracts
Measures such as revenue, active customers, gross margin, service-level attainment, or churn should have one documented definition.
Measures and calculated columns serve different purposes; measures are usually the stronger place for reusable dynamic business calculations.
Duplicate or overlapping measures create confusion for users and for AI features that generate DAX from semantic metadata.
Use Direct Lake when the workload fits
Direct Lake on OneLake can provide high-performance analytical access to Delta tables without requiring a traditional import copy.
Direct Lake works best when the underlying tables are well modeled, supported by OneLake security, and compatible with the features the semantic model needs.
Use Import or DirectQuery when their tradeoffs fit the source, scale, feature, or freshness requirement better.
Keep the model understandable to AI
Microsoft’s current guidance for AI-assisted semantic use emphasizes star schema, clear measures, visible business fields, and avoiding noisy helper objects.
Semantic models become a stronger AI interface when names and descriptions reflect business meaning rather than technical abbreviations.
Well-designed metadata can reduce the amount of prompt engineering needed for reliable analytical answers.
Separate model logic from report logic
Business measures that should be reused across reports belong in the semantic model rather than being recreated independently in each visual.
This creates consistency across dashboards and simplifies governance.
Report-specific presentation logic can remain in the report when it does not define enterprise business meaning.
Control row-level security deliberately
Security can be applied through semantic-model design and source permissions depending on the storage mode and architecture.
Test security with representative users rather than only with workspace admins.
Fabric security should preserve the intended data boundary from source through semantic model to report or AI consumer.
Version model changes
Relationships, measures, calculation groups, tables, and storage-mode decisions can affect many downstream reports.
Fabric CI/CD should treat semantic models as production artifacts with source history, testing, deployment, and rollback.
Breaking measure or schema changes need communication and migration plans for dependent reports.
Measure model quality through user outcomes
Query performance matters, but a fast model with confusing metrics still creates bad decisions.
Track reuse, duplicated calculations, support questions, refresh reliability, query latency, and whether business users can find the right measure without specialist help.
For Fabric analytics and engineering teams, the durable design is a clear star schema, governed measures, intentional storage mode, understandable metadata, tested security, and controlled lifecycle. The semantic model should make the business easier to analyze, not merely expose tables to Power BI.
As AI assistants increasingly query semantic models directly, clear metadata and business definitions become even more important. A well-designed model is both an analytical interface and an AI-readable contract over trusted data.
Semantic model naming should use business language. A measure named Net Revenue with a clear description is more useful than one named NR_Adj_v3, even if both calculate correctly. Human users and AI-assisted analytics both benefit when model metadata communicates intent without requiring knowledge of the implementation history.
Date dimensions deserve deliberate treatment because time intelligence depends on consistent calendars, fiscal periods, and relationship direction. Organizations with fiscal calendars should model those rules centrally rather than rebuild them in every report or prompt.
Many-to-many relationships should be used only when the business relationship genuinely requires them. They can be valid, but they make filter propagation and DAX behavior harder to reason about. Bridge tables and explicit modeling often provide a clearer contract for both report authors and AI-generated queries.
Calculation groups can reduce duplicated measure patterns, but they add abstraction. Use them where recurring logic such as time intelligence or formatting benefits many measures, and document the behavior so model consumers understand how the calculation changes context.
Direct Lake performance still depends on the underlying Delta tables, model design, and user query patterns. A storage mode cannot rescue a weak star schema or an overloaded capacity. Monitor real report and query behavior before changing storage modes solely because one mode appears more modern.
Semantic models used by AI data agents should minimize ambiguity. Duplicate measures, hidden dependencies, overloaded names, and helper calculations can make generated DAX less reliable. Curating the AI-facing model surface is a governance task, not merely a metadata exercise.
Row-level security should be tested with the same questions business users ask. A technically correct role can still confuse users if a measure changes meaning under the filtered population. Documentation should explain whether metrics are global, user-scoped, or filtered by organizational hierarchy.
Model lifecycle should include deprecation. When a measure is replaced, mark it clearly, migrate dependent reports, and remove it after the transition. Keeping every historic measure forever creates semantic debt and makes self-service harder over time.
The best semantic model is a reusable business contract: stable grain, clear dimensions, governed measures, understandable relationships, appropriate storage mode, tested security, and enough metadata that both humans and AI can query the business without reverse-engineering raw tables.
Model descriptions should document calculation intent, not restate the measure name. A useful description explains business scope, exclusions, timing, currency or unit, and any dependency that a report author or AI agent could misunderstand.
Performance should be tested with representative reports and concurrency. A model that responds quickly in a developer session can behave differently under dozens of users, large slicers, or complex DAX. Optimize according to real query patterns.
Semantic-model ownership should be durable. Shared enterprise models need a named team that maintains measures, security, schema compatibility, and release communication. An ownerless model becomes a hidden dependency for dozens of reports.
Keep certified and exploratory models distinct. Self-service teams need freedom to experiment, but enterprise dashboards and AI experiences should point to governed semantic models when consistent business definitions matter.
Model refresh and deployment should be monitored as carefully as query performance. A semantic model that points at the wrong stage, misses a table change, or fails to refresh can publish incorrect business metrics even though the DAX definitions are sound.
Business terminology should be curated with data owners. Technical modelers know relationships and storage modes, while finance, sales, operations, or risk owners know what the measures are supposed to mean. Strong semantic layers combine both kinds of expertise.
Composite models can solve useful integration problems, but every additional source and storage mode increases complexity. Use them when the analytical requirement justifies that complexity rather than as a default architecture.
AI-assisted querying raises the cost of ambiguous metadata because automated systems can generate answers at scale. A clear model with fewer trustworthy measures is often better than a rich model containing many overlapping calculation paths.
Semantic model design should therefore be reviewed like API design: stable names, documented contracts, controlled breaking changes, versioned deployment, and a clear owner for the business meaning exposed to consumers.
Review the model whenever source tables, fiscal calendars, or business definitions change, even if reports still render without errors.
Keep semantic contracts current.
Keep model ownership explicit across business and technical teams.
Retire stale measures before they become competing business definitions.
Document every breaking change before production rollout.
Keep model tests current.