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	Business key column on the fact table, used in the join and in the transformation table. The dimension column remains equal. The surrogate key column is derived from it: the business key prefix is replaced by the surrogate key prefix (`BK_OrderDate` becomes `SK_OrderDate`). 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. Declare each Column under Columns as well, so the business key is loaded into the fact.

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

Column is the business key on the fact. It becomes the column in the transformation table T_Sales and the fact side of the join; the dimension is still joined on its own BK_Date. The surrogate key column that the Gold view emits — and that the tabular model relates to the dimension — is derived from it by swapping the business key prefix for the surrogate key prefix. So the example above produces:

Reference	Column in `T_Sales`	Join predicate	Surrogate key in `F_Sales` view and model
`BK_OrderDate`	`BK_OrderDate`	`R1.BK_Date = TRN.BK_OrderDate`	`SK_OrderDate`
`BK_ShipDate`	`BK_ShipDate`	`R2.BK_Date = TRN.BK_ShipDate`	`SK_ShipDate`

Dimension columns projected through the view are prefixed per role (OrderDate_Year, ShipDate_Year) instead of by dimension name, so multiple references to the same dimension never collide.

A reference without Column keeps the dimension-derived names: BK_Date in the transformation table and SK_Date in the view and model. You may mix the two — one reference per dimension may omit Column and keep the plain names, while the others name their own. Leaving Column off more than one reference to the same dimension is rejected during generation, because those references would produce the same columns and the same join.

warning

The Gold notebook that fills T_Sales must alias its source columns to the names in the middle column above. A missing column is not an error — with the default auto_null_column the column is silently written as NULL for every row.

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[SK_ShipDate], Date[SK_Date] )
)

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.

Reference​

References​

MultiDirectionalFilter​

IsActiveRelation​

Reference

References

MultiDirectionalFilter

IsActiveRelation