Skip to main content

Relation

A Relation represents a data table. It is essentially a List of Contexts (a table of rows).

Structure​

  • Columns: Define the fields (keys).
  • Rows: Define the data values.

Example​

NameAgeRole
"Alice"30"Manager"
"Bob"25"Developer"

Result:

[
  { "Name": "Alice", "Age": 30, "Role": "Manager" },
  { "Name": "Bob", "Age": 25, "Role": "Developer" }
]

Usage​

Relations are useful for defining lookup tables or static datasets within the model logic.

FAQ​

Can I query a DMN Relation using FEEL filters?

Yes — a Relation evaluates to a FEEL list of contexts, so you can filter and project it using standard FEEL list syntax. myRelation[Role = "Manager"] returns the rows where the Role column equals "Manager", myRelation[Age > 25].Name returns the names of rows whose Age is above 25. Sorting, indexing, counting, and aggregation all work the same way they do on any FEEL list.

Can a Relation have empty cells or null values?

Yes — a cell with no expression (or with the FEEL literal null) evaluates to null in that row's context entry. FEEL operations against the Relation treat the missing cell as a regular null: myRelation[Role = null] returns rows with a null Role, and aggregations like sum skip non-numeric values including null. If a column is allowed to be missing in practice, downstream consumers should be defensive — checking value != null or providing a fallback via a Context entry.

Can a Relation contain another Relation or a List as a cell value?

Yes — boxed expressions nest freely. A cell can contain a Literal Expression that produces a list, a nested Context, even another Relation. The resulting FEEL value will be a list of contexts where one or more of the column values is itself a list or context. Common use case: a row representing a customer with an Orders column whose value is a list of order records. Just remember the column type is implicit in the expression — there's no schema enforcement that every row in a column produces the same shape.