Building derived relation types

This topic explains how to build derived relation types (DRTs) using the visual relation type builder for linear paths and the JSON editor for advanced paths, to ensure that all connections follow strict compatibility rules.

General process

The general process for working with derived relation types is very similar to the one used for explicit relation types.

No.	Step	Description
1	Create a derived relation type.	A derived relation type is a kind of relation type. Both derived relation type and explicit relation type share the same structure, which includes a head, a tail, a role, and a co-role. For a derived relation type, you need to additionally define the relation paths, because a derived relation type is calculated based on other relations.
2	Assign the derived relation type to an asset type.	Because a derived relation type has the same structure as an explicit relation type, you need to add a derived relation type to an asset type assignment to show the derived relation on asset pages. If you defined a custom layout for your assignment, or if a custom layout is defined out of the box, you also need to add the derived relation type to the asset layout.
4	View the derived relation on an asset page.	You are now ready to show the derived relation on asset pages. Open an asset page for the asset type and assignment to which you added the derived relation type. The asset page shows any assets that are present at the end of the derived relation. You can identify a derived relation on an asset page by the diagram icon . Clicking shows the relation paths on which the derived relation is based, and clicking an asset name opens the corresponding asset page.

Starting the process

Derived relations are a kind of relations. They are defined by derived relation types, similar to how explicit relations are defined by explicit relation types. Both of these relation types are managed on the Relation types page in the Operating Model settings.

On the Relation types page, the Kind column helps you differentiate explicit relation types from derived relation types. The Actions column contains the option to edit derived relation types. The table also contains Add explicit relation type and Add derived relation type buttons to allow you to create explicit relation types and derived relation types, respectively. Clicking Add derived relation type takes you to the derived relation type editor.

Let’s have a deeper look at the derived relation type editor.

The "Details" tab

The Details tab in the derived relation type editor is where you can see and define the main characteristics of your derived relation type, including the head, role, co-role, tail, and description. You can fill the role, co-role, and description for the derived relation type you want to build. The head and tail are automatically filled based on the content on the other tabs. As you fill the role and co-role, the title of the derived relation type editor is updated to reflect your changes. Once you save the derived relation type, a public ID is generated and shown on the Details tab. You can edit the public ID if needed.

Relation paths

A derived relation type requires relation paths to define how to traverse the graph from one asset type to another. A relation path begins with an asset type called the head asset type and leads to another one called the tail asset type. A set of relation types is declared between the head and tail asset types to form these paths.

Compatibility rules for a relation path

For a relation path to be valid, every single relation type in the path must be compatible with the asset type it is connecting to—whether that is the head, the tail, or the relation type immediately preceding or succeeding the relation type. Compatibility rules ensure that the asset type used at the beginning or end of a relation type makes sense in the context of the overall relation path.

• A relation type must start with the asset type that ends any preceding relation type, or an ancestor or descendant of that asset type.
  • A relation type connected to the head must begin with the head asset type, or an ancestor or descendant of the head asset type.
• A relation type must end with the asset type that begins the next relation type, or an ancestor or descendant of that asset type.
  • A relation type connected to the tail must end with the tail asset type, or an ancestor or descendant of the tail asset type.

Let’s now make sure that all the relation types in the example above are compatible with each other.

• Head node. You defined the head asset type as Data Asset. The first relation type begins with Table, which is a descendant of Data Asset. The second relation type begins with Data Set, which is also a descendant of Data Asset. Therefore, both relation types begin with an asset type that is compatible with the head asset type.
• Column node. You want to pass through the Column asset type. The incoming relation types end with Column and Data Element. Data Element is an ancestor of Column. Therefore, both relation types are compatible with the Column asset type. The outgoing relation type begins with Data Asset. Data Asset is an ancestor of Column. Therefore, the outgoing relation type is also compatible with the Column asset type.
• Tail node. The relation type that leads to the tail node ends with Data Category and is therefore compatible.

The relation types you use in the relation paths can be traversed in the role or co-role direction, but this must be explicitly specified.

The "Relation type builder" tab

The Relation type builder tab in the derived relation type editor is a graphical editor that assists you in the creation of your relation paths. Use the Relation type builder tab to specify how you want to traverse the knowledge graph from the head asset type to the tail asset type.

General layout of the relation type builder

The relation type builder is split into the following sections.

Defining DRT with the relation type builder

The following steps outline the typical, high-level process to define your relation paths using the relation type builder:

1. Define the head asset type.
2. Define your first straight relation path. A valid derived relation path must define at least one relation path and a relation path must declare at least one relation type. The Graph tab in the right sidebar shows all your relation paths as a graph if they are valid.
3. If needed, add more asset paths.
4. The tail asset type is automatically suggested. If needed, you can change it to a descendant asset type of the suggested one.
5. Ensure that you have defined the role and co-role on the Details tab. You can do this at any time during this process.
6. Save your derived relation type.

Working with relation paths in the relation type builder

In the relation type builder, when you define the head asset type in the Head field, an empty relation path appears for you to define one or more relation types that will form the straight relation path through the graph.

You can select a relation type in the Select relation field (relation type selector). Clicking next to the field allows you to add another relation type. Each relation type in a straight relation path is shown below the preceding relation type and is slightly indented to indicate that it succeeds the one above.

If needed, you can remove a relation type from the path using → Delete. Removing a relation type from a path also removes the succeeding relation types from the path. This means that if you remove the very first relation type from a path, the path itself is removed. If you accidentally removed a relation type, click to restore it. To remove it again, click .

Clicking Add path allows you to add another straight relation path below the existing one. To change the position of a relation path, drag to the required position.

The "JSON" tab

As mentioned earlier, a derived relation type requires relation paths to define how to traverse the graph from one asset type to another. We showed you earlier how to use the relation type builder for that purpose. When to use the JSON editor on the JSON tab then? It is when you want to declare optimized relation paths without the linearity (straight path) constraint required by the relation path builder.

In the JSON structure, a relation path is represented as a subgraph of the operating model, where asset types are nodes and relation types are edges. Each relation type begins with either the head or a node and leads to either the next node or the tail.

The JSON editor already contains a template to help you get started. It also guides you with auto-completion features and highlights possible syntax errors.

JSON structure

The JSON structure contains the following three sections at the first level:

• headNode: This section describes the head of your derived relation type. You need to specify the following properties:
  • name: Name for the head node. It must be unique within a derived relation type.
  • headType: Public ID of the head asset type.
  • outgoingEdges: List of relation types that leave the head node and lead to the next nodes in the relation paths. An outgoing edge can lead to any other node, including the tail node.
• intermediateNodes: This section describes all the nodes that are neither the head nor the tail. You need to specify the following properties for each intermediate node:
  • name: Name for the intermediate node. It must be unique within a derived relation type.
  • outgoingEdges: List of relation types that leave the intermediate node and lead to the next nodes in the relation paths. An outgoing edge can lead to any successive node, including the tail node.
• tailNode: This section describes the tail of your derived relation type. You need to specify the following properties:
  • name: Name for the tail node. It must be unique within a derived relation type.
  • tailType: Public ID of the tail asset type.

Both headNode and intermediateNodes require a list of outgoingEdges. You need to specify the following properties for each outgoing edge:

• direction: Direction in which the relation type is traversed, which can be in the role direction (head to tail) or the co-role direction (tail to head).
• type: Public ID of the relation type, which can be explicit or derived.
• nextNodeName: Name of the node that succeeds the end of the relation type.

{
  "headNode": {
    "name": "head (Data Asset)",
    "headType": "DataAsset",
    "outgoingEdges": [
      {
        "direction": "co-role",
        "type": "ColumnIsPartOfTable",
        "nextNodeName": "Column node"
      },
      {
        "direction": "role",
        "type": "DataSetContainsDataElement",
        "nextNodeName": "Column node"
      }
    ]
  },
  "intermediateNodes": [
    {
      "name": "Column node",
      "outgoingEdges": [
        {
          "direction": "co-role",
          "type": "DataCategoryCategorizesDataAsset",
          "nextNodeName": "tail (Data Category)"
        }
      ]
    }
  ],
  "tailNode": {
    "name": "tail (Data Category)",
    "tailType": "DataCategory"
  }
}

When the relation paths are complete and valid, they are shown as a graphical representation on the Graph tab in the sidebar.

You can save your derived relation type only when the following conditions are fulfilled:

• The role and co-role on the Details tab are defined.
• A valid relation path is defined.

You can see and edit the public ID of the derived relation type on the Details tab only after the derived relation type is saved. Remember that changing the public ID can affect any existing integrations.

The "Graph" tab

In the derived relation type editor, the Graph tab in the right sidebar shows all the relation paths that the derived relation type follows through the knowledge graph only after you have correctly built the relation paths. In the graph, the label and the code shown for a node are determined using different rules:

• Node labels: A node label itself isn't always the actual name of the corresponding asset type. Rather, it is determined by how the node was created. If you used the JSON editor, the node label is the specific name you entered. If, however, you used the relation type builder, the node label is automatically generated based on the asset type at the end of the relation type reaching that node.
• Node codes: In order to show a code next to a node label, the graph dynamically evaluates the asset types of all incoming and outgoing relation types connected to that node. To remain compatible with every connected relation path, the graph shows the code of the closest common ancestor in the asset hierarchy. For example, if the relation type reaching a node is "Directory contains Directory" and the relation type leaving the same node is "Technology Asset implements Data Asset", the graph must accommodate both paths. The closest common ancestor between a Directory and a Technology Asset is a Technology Asset (Directory Contains (Directory Technology Asset) implements Data Asset). Therefore, the graph shows the code of Technology Asset, which is TA, next to the node label Directory.

Adding one DRT to another

You can add a derived relation type to another derived relation type. A relation path in a derived relation type can include any kind of relation. In the background, a derived relation type is automatically replaced with its definition, ensuring that it ultimately queries only explicit relations.

Create a derived relation type for relation paths that you frequently use, even if you don’t plan to assign the derived relation type to an asset type. This approach allows you to reuse your derived relation type within another derived relation type, avoiding the need to repeat the same relation path multiple times.

Related topics

• Repeated relations in derived relations
• Usage guidelines for derived relations
• Testing derived relation types
• Deploying derived relation types
• Managing derived relation types