Tabular Reference

The References section is used to establish relationships between tables in your data model. This section defines the main table and lists all the associated tables it connects to.

Reference

Name	Description
Table*	Name of the related table
Column	Column name of the fact table. The dimension column remains equal. Only necessary for multiple relationships to the same dimension. IsActiveRelation is mandatory when supplied.
MultiDirectionalFilter	Is this both way relation? Use with caution. (default=false)
IsActiveRelation	Is this relation active? (default=true)

* Indicates that the field is mandatory and must be used.

References

- Table: 
    Name: CallLog
    SourceTable: F_CallLog
    TableType: Fact
    References:
    - Table: Company
    - Table: Date
    - Table: Employee
    - Table: Time
    - Table: CallStatus
    Columns:
    - SourceColumn: StartTime
      Type: varchar(50)
    - SourceColumn: EindTime
      Type: varchar(50)
    - SourceColumn: Caller
      Type: int
    - SourceColumn: Phonenumber
      Type: int

• References: The References section lists the tables that the current table is linked to within the model. Each entry should include the name of a related table, establishing relationships across the model.

MultiDirectionalFilter

- Table: 
    Name: CallLog
    References:
    - Table: Company
      MultiDirectionalFilter: true
    - Table: Date
    - Table: Employee
    - Table: Time
    - Table: CallStatus
    Columns:
    - SourceColumn: StartTime
      Type: varchar(50)
    - SourceColumn: EindTime
      Type: varchar(50)
    - SourceColumn: Caller
      Type: int
    - SourceColumn: Phonenumber
      Type: int

MultiDirectionalFilter: The MultiDirectionalFilter property specifies if the relationship between tables is bidirectional. When set to true, filters can flow in both directions. This property should be used cautiously as it can complicate the data model and affect performance.

IsActiveRelation

A tabular model allows only one active relationship between two tables, but you often need several — a classic example is a role-playing dimension such as a Date table linked to both OrderDate and ShipDate on the same fact. Model the extra relationships with IsActiveRelation: false; the model keeps them but leaves them inactive until a measure activates them with USERELATIONSHIP.

When a fact references the same dimension more than once, give each reference its own fact-side Column (the dimension column stays the same) and set IsActiveRelation explicitly on every one of them — exactly one may stay active.

- Table:
    Name: Sales
    SourceTable: F_Sales
    TableType: Fact
    References:
    - Table: Date
      Column: OrderDateKey
      IsActiveRelation: true
    - Table: Date
      Column: ShipDateKey
      IsActiveRelation: false
    - Table: Customer
    Columns:
    - SourceColumn: OrderDateKey
      Type: int
    - SourceColumn: ShipDateKey
      Type: int
    - SourceColumn: Amount
      Type: decimal(18,2)

IsActiveRelation: The IsActiveRelation property controls whether the relationship is active in the model. It defaults to true. Set it to false to keep an additional relationship to a dimension that is already actively related; the relationship becomes available to DAX measures through USERELATIONSHIP, for example:

Sales by Ship Date =
CALCULATE (
    [Total Amount],
    USERELATIONSHIP ( Sales[ShipDateKey], Date[DateKey] )
)

Defining more than one active relationship to the same dimension is rejected during generation, so only one reference per target table may keep IsActiveRelation: true.