Testing derived relation types

This topic describes how to validate logic and run-time performance of your derived relation type (DRT) using the built-in testing tools, and offers strategies for troubleshooting errors.

Testing your DRT with the "Relation test" tab

Once you have defined the relation paths for your derived relation type, it is recommended to confirm that they work as expected. You can test the relation paths against an asset using the Relation test tab in the right sidebar in the derived relation type editor. This testing tool helps you verify two essential aspects of your derived relation type:

  • Accuracy: Are the relation paths in your derived relation type delivering expected results?
  • Performance: Is the query in your derived relation type (generated by your relation paths) running within a reasonable period?

Running a test

The test simulates how the derived relation is resolved by querying the explicit relations in the knowledge graph.

  1. Select a test asset: In the Test asset field, select a head asset. The Test asset field contains only those assets that are compatible with the head asset type in your derived relation type. If needed, you can use Filter icon next to the Test asset field to narrow the list by communities and domains.
    If the Type inheritance checkbox is selected, the Test asset field includes assets of the head asset type as well as its descendant asset types. Clear the Type inheritance checkbox if you want the test assets to include assets of only the head asset type.
  2. Run the test: Click Run test to resolve the derived relation for the test asset. The system searches for assets that are related to the test asset through the relation paths you defined in your derived relation type. The query times out after 10 seconds.
    Like any relation type in a knowledge graph, a derived relation type can be traversed in two directions: from head to tail (role direction) and from tail to head (co-role direction). To run a test in the co-role direction, select the Start from tail checkbox, select a tail asset in the Test asset field, and click Run test.

Understanding test results

After the test runs, two key pieces of information are shown:

  • Related assets: The assets found at the end of the relation paths appear below the Test asset field. Check if they match what you expected to see.
    The asset results are paginated, and you can switch between 25 and 50 assets per page.
  • Run time: The time it took to run the query is shown in seconds.
    Whether the query time is fast or slow depends on your use case and expectations. A time of 1 to 2 seconds can be acceptable to show a derived relation on an asset page.

Image of the Relation test tab with results

Example

You want to test a derived relation type that shows the database a column belongs to. The following image shows the relation path that the derived relation type follows.
Image of a diagram showing how a column is related to a database
Select the column 11apr2023 as your test asset and run a test. The results show the correct parent database, and they also show that the query took 66 ms to run, which is acceptable.
Image of the Relation test tab with results

Taking the same example as above, suppose that you also want to check if your relation path works from the database to the column. If you select the Start from tail checkbox, you can query the list of columns that are part of a selected database. Select the database postgres as your test asset and run a test. The results show 25 columns, and they also show that the query took 80 ms to run, which is still acceptable.
Image of the Relation test tab with results
When you click the right arrow next to Results per page at the bottom to go to the next page, the query is run again to process more information. The columns shown on the other pages still belong to the same database (postgres) and the run time is still very low. You can now confidently assign your derived relation type to the Column or Database asset types.

Troubleshooting strategies

When testing your derived relation type on the Relation test tab in the derived relation type editor, you may encounter two situations requiring attention:

  • Accuracy: The relation paths are not delivering expected results.
  • Performance: The query is not running within a reasonable period.

Let’s look at what actions you can take in each case.

When results are empty or incorrect

Suppose that you have a test asset, DRT Test - Email, which is expected to return two assets, DRT Test - Employee Table and DRT Test - Customer Table. But when running a test, the results return empty, or you see a different list of assets than you expected. This usually means that there is a mismatch between the relation paths defined in your derived relation type and the actual relations existing between those assets.

Finding the issue

  • Map the actual paths in your data.
    • Find the test asset and the target assets that you expected to see. Check the relation paths that link the test asset to the expected assets, following the relations that link them together. You can do this either by navigating from the test asset to the target asset page by page or by using a diagram.
    • Check the type of each relation that you traverse and record the full relation type identifier. The identifier can be either the relation type public ID or the combination of head, role, co-role, and tail.
  • Compare the paths to your derived relation type definition.
    • Look at your derived relation type definition. Does it match the list of relation types that you recorded in the previous step? Confirm that there is a path that follows the same relation types as defined in the derived relation type definition.
      A common mistake is selecting the wrong relation type—one that has the same role/tail or co-role/head as the relation type that you need.
    • For example, you want to navigate from a table to a column and are presented with two similar relation types when building the derived relation type: "Table contains / belongs to Column" and "Data Asset contains / belongs to Column". From an operating model perspective, both of these relation types are compatible because a table is also a data asset. However, only one of these relation types is likely to be present in the knowledge graph, and you might have selected the wrong relation type in your derived relation type.

Fixing the issue

  • To make things readable, the relation type builder shows only role and tail ("contains Column"), or co-role and head ("belongs to Table"). However, the relation type selector of the builder allows you to see both the head and the tail at the same time ("Table contains Column" and "Column belongs to Table"). When you open the selector, the relation type that is currently selected is highlighted in blue. This helps you check if you selected the right relation type.
  • If you are familiar with JSON syntax, another option is to look at the JSON editor. The JSON structure uses the relation type public IDs, and each ID is unique across all relation types. This helps you confirm more easily that the selected relation type matches the one that is used in your test assets.
  • You can also check the kinds of the relation types that are in the relation paths of your derived relation type. In the relation type builder, explicit relation types are shown in grey, and derived relation types are shown in purple. Because you are more likely to use explicit relation types, when you see a relation type in purple, confirm that it is truly meant to be a derived relation type. Similarly, if you know that a relation type is supposed to be a derived relation type, confirm that it is shown in purple. In both cases, a wrong color means that you selected the wrong relation type and you should review your selection.
  • If your test results were partially correct, it is probably because some of the paths in your derived relation type are correct and some aren't. Temporarily removing certain paths can help in identifying the problematic path. The Undo icon and Redo icon icons in the relation type builder can be helpful to avoid spending time rebuilding the paths you removed. If you are using the JSON editor, you can save the structure temporarily in a separate text editor.

When performance is slow

Suppose that you need the derived relation to run within a short period of time. But when running a test, you find that the query takes a long time to run. There can be two reasons that your derived relation type doesn't run within a reasonable period:

  • Your paths are too long and lead to complex database queries.
    Your relation paths contain too many relations in total or traverse too many relations before reaching the target asset. You can remove redundant relation types by using the JSON editor, which allows for more complex paths that can fork and join at any time. If this doesn’t help, consider removing certain relation types from the paths.
  • Your knowledge graph contains too many assets.
    The performance of a database query depends on the size of your database, among other things. The larger a knowledge graph, the slower the query. If you suspect your graph size is causing the slow query, check if you can reduce the number of assets or simplify the relation paths as explained in the previous point.

Related topics