The business layer
Domains, subject areas, entities, terms, rules, products and contracts — and binding them to real data.
On this page
The physical estate shows what your warehouse has. The business layer records what it means: which domain answers for it, what the words mean, which rules apply, and what a data product has promised. This page describes each kind of business asset and how it is tied to real tables and columns.
The names here come from the starter model. Your repository's metamodel may call things something else, or have more or fewer kinds.
What each kind of thing is for
| Kind | What it is for |
|---|---|
| Data Domain | A top-level grouping by business meaning, such as Customer, Product or Finance. Everything else is owned by a domain, and its owners and stewards pass down from there. |
| Subject Area | A grouping of related entities within a domain. |
| Data Entity | Something the business recognises, such as Customer, Order or Policy. |
| Data Attribute | A property of an entity, such as Customer Email or Order Date. |
| Business Term | A word or phrase the business uses, with its agreed definition. |
| Business Rule | A validation, derivation, constraint or standard the business requires. |
| Business Process | A business activity that uses or produces data. |
| Data Product | A curated dataset published for reuse, with named inputs and outputs and an accountable owner. |
| Input Port | One thing a data product reads: a table, a view, or another product's output port. |
| Output Port | What a data product publishes, and what its consumers depend on. |
| Data Contract | What is promised about an output port, such as refresh, service commitment, retention and notice of breaking changes. |
| Data Sharing Agreement | Who may use what, for what purpose, and until when. |
How they fit together
The links have names you'll see on each asset's page under Relations, for example This data entity realised by:
- An entity belongs to a subject area and has attributes.
- A term defines an entity or an attribute. A term can be related to, broader than or narrower than another term.
- A rule governs an entity, an attribute or a term.
- A process uses entities.
- A data product reads through its input ports, publishes through its output ports, and publishes entities.
- An output port is governed by a contract. A sharing agreement covers output ports and is shared with another domain.
- Almost everything is owned by a data domain.
A sharing agreement is shared with the receiving domain but stays owned by its own. The receiving domain gets access without taking ownership.
Input and output ports belong to their product, so they take the product's domain. You don't need to give them one.
Tie it to real data
A definition that isn't attached to anything drifts out of date without anyone noticing. So the business layer is tied to the harvested estate:
| From | Link | To |
|---|---|---|
| Data Entity | realised by | Table or View |
| Data Attribute | realised by | Column |
| Business Term | maps to | Column |
| Business Term | realised by | Metric |
| Input Port | reads | Table, View or Output Port |
| Output Port | realised by | Table or View |
When these links are in place, you can start on a column and see what it means, who owns it and which rule governs it. You can also start on a term and find where it actually lives. Links to the real estate appear first when Ask shows a best match.
To make a link:
- Open the business asset, for example the entity Customer.
- Under Relations, choose Link this to… and then, for example, realised by a Table.
- Tick the tables in the picker, which is arranged by system, database and schema, and press Link.
A port is often realised by many tables at once. Tick a schema in the picker to take every table in it. See Editing an asset for more on the picker.
Why unbound items are reported
Each business statement should end at a real, harvested asset. When something doesn't:
- A reference that matches nothing is reported by name, and no asset is invented to fill the gap. The definition is then visibly not attached, instead of looking correct when it isn't.
- A reference that matches two assets (for example two tables with the same path in two systems) is linked to neither, because a guess would look exactly like a correct link.
If an entity or attribute is supposed to be realised by a table or column and you can't see the link, the table may not have been harvested yet, or may be named differently in your estate.
Adding and changing business content
- Add one at a time with the New button on a type's list (for example New business term). You can link it to its domain as you create it.
- Add many with Loading from Excel, using the Relations sheet for the links.
- Edit definitions and attributes on the asset's page. See Editing an asset.
An administrator can also load a ready-made business layer. KRISID ships example content for several industries: banking, healthcare, media, reinsurance, retail, telecoms, plus a shared enterprise domain. It is bound to your harvested tables in the way described above, and the run lists every reference it couldn't bind. Once it's loaded, you edit it like anything else.
Good to know
- Keys in the ready-made content include the domain, so Customer in Banking and Customer in Retail are two separate entities with separate definitions.
- Entities in the ready-made content are realised at the conformed (gold) layer. Lineage then traces them back through silver to bronze, so you don't need to link every layer.
- A business term is an agreed meaning, and a metric is a calculation. Link them with realised by so a term has both. See Editing the semantic model.