Siksha Sarovar

Siksha Sarovar (sikshasarovar.com) is a free educational web application that helps students in India learn programming and prepare for academic and competitive exams. The platform offers structured coding courses (C, C++, Python, Java, HTML, CSS, PHP, Power BI, AI, Machine Learning, Data Science), complete university curriculum notes for BCA/MCA students with previous year question papers, Class 10 and Class 12 CBSE/HBSE school notes, and dedicated preparation material for SSC, UPSC, Banking, Railway and other government exams. Browsing the site is completely free and requires no account. Users may optionally sign in with Google solely to save their learning progress, quiz scores and personal preferences across devices.

Privacy Policy | Terms of Service | Contact Siksha Sarovar | About Siksha Sarovar

v4.0.9 · PWA
Siksha Sarovar logo
Siksha Sarovar
Your Learning Universe

Siksha Sarovar is a free e-learning platform for coding courses, BCA university notes and competitive exam preparation. Optional Google sign-in saves your learning progress across devices.

Initializing knowledge base…
Compiling modules 0%

2.9 Relationships, Cardinality & Cross-Filtering

Lesson 19 of 62 in the free Power BI notes on Siksha Sarovar, written by Rohit Jangra.

Creating Relationships Between Tables

Relationships define how tables connect to each other in the data model. They are essential for cross-table analysis and accurate calculations.

How to Create Relationships

Method 1: Auto-detect • Power BI automatically detects relationships based on matching column names • Go to FileOptionsCurrent FileData Load → Enable "Auto detect new relationships"

Method 2: Drag and Drop (Model View)

  1. Go to Model View
  2. Drag a column from one table to the matching column in another table
  3. A relationship line appears between the tables

Method 3: Manage Relationships Dialog

  1. Go to HomeManage Relationships
  2. Click New
  3. Select the two tables and matching columns
  4. Configure cardinality and cross-filter direction
  5. Click OK

Cardinality

Cardinality defines the nature of the relationship between two tables — how many rows in one table relate to rows in another.

CardinalityDescriptionExample
One-to-Many (1:*)One row in Table A relates to multiple rows in Table BOne Customer → Many Orders
Many-to-One (*:1)Many rows in Table A relate to one row in Table BMany Orders → One Customer
One-to-One (1:1)One row in Table A relates to exactly one row in Table BOne Employee → One ID Card
Many-to-Many (:)Multiple rows in both tables relate to each otherMany Students → Many Courses

Best Practice: Most relationships should be **One-to-Many (1:)*, with the "one" side being the dimension table and the "many" side being the fact table.

Cross-Filter Direction

Cross-filtering determines how filters flow between related tables.

DirectionDescription
SingleFilter flows from the "one" side to the "many" side only
Both (Bidirectional)Filter flows in both directions

Default: Single direction (recommended) Bidirectional: Use cautiously — can cause ambiguity, performance issues, and unexpected results

When to Use Bidirectional: • When a slicer on a fact table needs to filter a dimension • In many-to-many relationships • For specific bridge table scenarios

Primary Key & Foreign Key

Primary Key (PK): • A column with unique values that identifies each row • Located in the dimension table (the "one" side) • Example: CustomerID in the Customers table

Foreign Key (FK): • A column that references the primary key of another table • Located in the fact table (the "many" side) • Example: CustomerID in the Sales table (references Customers.CustomerID)

Key TypeLocationValuesPurpose
Primary KeyDimension tableUnique, no duplicatesUniquely identify rows
Foreign KeyFact tableCan repeatReference dimension rows

Relationship Best Practices

• Use Star Schema — fact table in center, dimensions around it • Prefer One-to-Many relationships • Avoid bidirectional cross-filtering unless absolutely necessary • Ensure primary key columns have no duplicates and no nulls • Use a Date dimension table for time-based analysis • Keep relationships simple — avoid complex chains of tables