Derived Model
A derived model builds a Power BI semantic model 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 YAML 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: Verkopen
- Table: Klant
- Table: Kalender
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
Namedoes not exist on the base table is added. - A measure whose
Namealready exists on the base table is only replaced when you setOverride: true. Without it, generation fails with a clear error so a clash is never applied silently.
- Table: Verkopen
Measures:
- Name: Verkoop YTD # new measure — added
Expression: TOTALYTD([Totaal Verkoop], Kalender[Datum])
- Name: Totaal Verkoop # already exists in the base model
Expression: SUM(Verkopen[NetAmount])
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 measure (base or derived) may also carry custom Annotations emitted onto the
generated measure:
Measures:
- Name: Aantal Verkopen
Expression: COUNTROWS(Verkopen)
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.
Derived models currently support table selection and measures. Per-column overrides are not yet implemented.