Power BI is a platform that enables users to connect to various data sources, transform data, create interactive visualizations, and share insights through dashboards and reports.
Data modeling refers to the process of defining how tables connect, interact, and filter each other to enable accurate calculations, fast performance, and intuitive reporting.
SQL JOINS
INNER JOIN-Returns matching rows from both tables.
LEFT JOIN-All rows from left table, matching from right, NULLs for no match.
RIGHT JOIN-All rows from right table, matching from left, NULLs for no match.
FULL OUTER-All rows from both, NULLs where no match.
LEFT ANTI-Rows in left table with no match in right.
RIGHT ANTI-Rows in right table with no match in left.
POWERBI RELATIONSHIP
Power BI relationships connect tables in the data model to enable dynamic filtering and accurate aggregations across visuals without physically merging data.
Relationship Cardinality
Cardinality defines how many rows in one table match rows in another.
1:1 (One-to-One): Each row in Table A matches exactly one row in Table B (e.g., Employee to EmployeeDetails via unique EmployeeID); rare, used for normalized data or security filtering.
1:M (One-to-Many): One row in Table A matches multiple in Table B (e.g., Product to Sales via ProductID); standard for star schemas.
M:M (Many-to-Many): Multiple rows in both tables match (e.g., Students to Classes); avoid direct M:M—instead use a bridge table for performance and clarity.
Active vs Inactive Relationships
Active: Default, single relationship per table pair; filter context propagates automatically in visuals and DAX (solid line).
Inactive: Additional relationships (dashed line); ignored by default—activate via USERELATIONSHIP() DAX function for specific measures (e.g., role-playing dates).
Cross-Filter Direction
Controls filter propagation:
Single: Filters flow one way (default for 1:M, e.g., Dimension → Fact).
Both: Bi-directional (e.g., Fact ↔ Dimension); use cautiously to avoid ambiguity or performance hits.
The difference between joins and relationships
Fact vs Dimension Tables
Fact tables store quantitative metrics (e.g., SalesAmount, Quantity) with foreign keys to dimensions; they grow vertically with transactions.
Dimension tables hold descriptive attributes (e.g., ProductName, CustomerCity) with hierarchies; they grow horizontally and less frequently.
Star Schema: Central fact table surrounded by denormalized dimension tables; simplest and fastest for Power BI queries.
Use Case: Sales dashboards needing quick slicing by product/customer.
Snowflake Schema: Dimensions normalized into sub-tables (e.g., Product → Category); saves storage but slower joins.
Use Case: Data warehouses with complex hierarchies; avoid in pure Power BI models.
Flat Table (DLAT): Single denormalized table blending facts/dimensions; easy but inefficient for filtering.
Use Case: Small, simple datasets before unpivoting into star schema.
Role-Playing Dimensions
A single dimension (e.g., Date table) connects to a fact table multiple times for different roles (OrderDate, ShipDate). Use inactive relationships + USERELATIONSHIP() DAX to activate contextually.
Common Modeling Issues
Circular dependencies: Resolved by star schema or inactive relationships.
Bi-directional filter loops: Set single direction.
Wrong cardinality: Causes incorrect aggregations; verify in properties.
Ambiguous paths: Hide unused columns or use bridge tables.
Top comments (0)