Skip to main content

Derived Model

A derived model builds a Power BI semantic modelThe "brain" of your data that tells Power BI how different pieces of information relate to each other. on top of an existing (base) model definition, without duplicating its model.yaml. You select which tables of the base model the derived model exposes, and optionally add or replace measures on those tables. Everything else — columns, relationships, hierarchies — comes from the base model unchanged.

This is useful when several semantic models share the same gold tables but a subset of them needs fewer tables or some extra measures, e.g. a focused "Sales" model derived from a broad enterprise model.

How a derived model is linked to its base​

There is no reference inside the YAMLA simple way to write configurations. It's basically a list that computers can read easily. files. The link is made in the models: list of dp.<env>.yaml: add a second model entry that reuses the base model's ModelFolder and ModelFile, and point DerivedModelFile at the derived YAML (resolved in that same folder).

 models:
 - model: DM                      # the base ("mother") model — unchanged
   tabularName: DM
   ModelFolder: Models/DM
   ModelFile: model.yaml
   datasourceType: fabric
   # ...

 - model: DM-Sales               # the derived model
   tabularName: DM Sales
   BimFolder: DM-Sales           # distinct folder → deploys as its own model
   bimFile: Model.bim
   ModelFolder: Models/DM         # SAME folder as the base
   ModelFile: model.yaml          # SAME base model.yaml
   DerivedModelFile: derived-sales.yaml   # the link → the table/measure list
   datasourceType: fabric
   # ...

Give the derived entry its own model, tabularName and BimFolder so it builds and deploys as a separate semantic model instead of overwriting the base. Derived models are target-agnostic — they work the same for fabric and azuresql.

Selecting tables​

The derived file (Models/DM/derived-sales.yaml above) is a list of the base tables to keep. Tables not listed are dropped, and any relationship pointing at a dropped table is removed automatically, so you do not get dangling relations.

- Table: Sales
- Table: Customer
- Table: Calendar

Each Table value matches the base table's logical name (the Table: field in model.yaml).

Adding or overriding measures​

A derived table may define Measures. They are merged onto the base table:

  • A measure whose Name does not exist on the base table is added.
  • A measure whose Name already exists on the base table is only replaced when you set Override: true. Without it, generation fails with a clear error so a clash is never applied silently.
- Table: Sales
  Measures:
    - Name: Sales YTD                # new measure — added
      Expression: TOTALYTD([Total Sales], 'Calendar'[Date])
    - Name: Total Sales              # already exists in the base model
      Expression: SUMX(Sales, Sales[Quantity])
      Override: true                 # required to replace the base measure

Derived measures support the same fields as base measures (DisplayFolder, FormatString, FormerName, DerivedMeasures, …); only Override is specific to derived models. A FormatString may reference a friendly name from formatstrings.yaml — it is resolved exactly as on a base measure.

A measure (base or derived) may also carry custom Annotations emitted onto the generated measure:

  Measures:
    - Name: Number of Sales
      Expression: COUNTROWS(Sales)
      Annotations:
        - Name: Owner
          Value: Finance

The EF_ prefix is reserved for EasyFabric's own annotations (e.g. EF_TableType, EF_LoadCategory), so use your own names for custom metadata.

note

Derived models currently support table selection and measures. Per-column overrides are not yet implemented.