The data model is the engine of your Power BI report. A clean model produces fast, accurate, and easy-to-maintain reports. A messy model produces slow, confusing reports that break when requirements change. Here is how to build models that work.
What is a data model?
A data model in Power BI is the set of tables, relationships, and measures that define how your data connects and how calculations flow. When you load tables into Power BI, you are building a data model whether you realize it or not. The difference between beginners and experts is whether that model is intentional.
The star schema: the gold standard
A star schema has one or more fact tables (transactions, events, measurements) surrounded by dimension tables (products, customers, dates, regions). Fact tables contain numbers you want to aggregate: amounts, quantities, counts. Dimension tables contain the attributes you want to filter and group by: product names, customer segments, calendar dates. The relationships go from dimension to fact, one-to-many.
Why star schema matters for Power BI
Power BI's engine (VertiPaq) is optimized for star schema. DAX filter context flows from dimensions to facts through relationships. If your model follows star schema, your DAX will be simpler, your reports faster, and your filter interactions predictable. If you try to use a flat table or a complex snowflake, you will fight the tool instead of working with it.
Rule 1: Every model needs a date table
Time intelligence functions like TOTALYTD and SAMEPERIODLASTYEAR only work with a proper date table: a continuous table with one row per day, no gaps. Create it with DAX CALENDAR function or import a pre-built date table. Add columns for Year, Quarter, MonthName, MonthNumber, WeekNumber, and any fiscal periods your business uses. Mark it as a date table in the model properties.
Rule 2: Avoid bidirectional relationships
Bidirectional relationships (double arrows in the model view) create ambiguous filter paths and unpredictable DAX behavior. Unless you have a specific, well-understood use case, keep all relationships as single-direction, from dimension to fact. If you need a bidirectional filter, use CROSSFILTER in DAX instead of the model setting.
Rule 3: No calculated columns for aggregation
Calculated columns are computed at refresh time and stored in memory. Measures are computed at query time in the current filter context. If you are summing or averaging values, use a measure. Calculated columns are appropriate for categorization (putting records into buckets) or for creating keys for relationships, not for numbers you plan to aggregate.
Rule 4: Handle many-to-many carefully
When two tables have a many-to-many relationship (like students and courses), you need a bridge table (enrollment records). Do not use a many-to-many relationship setting directly unless you understand how it affects filter propagation. Bridge tables are explicit and predictable.
Common modeling mistakes
Loading all data into a single flat table is the most common beginner mistake. It duplicates dimension data, inflates file size, and makes DAX harder. Using Excel-style column names with spaces and special characters is another: rename columns during Power Query load to PascalCase or snake_case. Importing unused columns wastes memory, so remove them in Power Query before loading.
Further learning
Data modeling is the skill that separates Power BI beginners from professionals. If your reports are slow, your DAX is complicated, or your numbers do not add up, the data model is almost always the root cause. Our [Power BI training](/courses/power-bi/) includes dedicated data modeling sessions with expert guidance.