Previously, I have written about the challenge that Hierarchies can constitute. See “Unbalanced, n-level Hierarchies”. I have also written about Semantic Links as a useful way to navigate data. But they are especially useful to navigate hierarchies.
A good example of hierarchies is that of the wine districts of the world, where you can see some in this picture:
The benefit of using Semantic links with hierarchies is that it is possible to create list boxes showing the daughters, ancestors or all sub-nodes of the selected wine district, thus giving a better overview and enabling a simple navigation of the data.
In the image below you can see what it looks like in QlikView:
In the middle, there is a standard list box with ‘Bordeaux’ selected. The three semantic links surrounding this list box show how Bordeaux relates to other wine districts. The ancestors (above) show that Bordeaux belongs not only to ‘France’, but also to ‘Europe’ and ‘The World’. The list box below shows the immediate daughters: ‘Entre-Deux-Mers’, ‘Graves’, etc.
And finally, to the right, all sub-districts of Bordeaux are listed using the path of the wine district.
The overview you can get of a hierarchy this way is excellent.
But that’s not all. The semantic links of course also allow selections. All links are clickable, so if the user now clicks on ‘Saint-Emilion’, this will become selected instead of Bordeaux:
This way a user can walk through the hierarchy and navigate the data.
To create such semantic links, you first need to create the relations in the script using the Hierarchy and HierarchyBelongsTo prefixes. Then you need to load these relations in the script using the Semantic prefix.
Here is how I have done it. First a Directory statement to enable relative paths, and then a mock-up transaction table:
After these statements, there are two hierarchy-defining statements in line with how a hierarchy should be loaded:
Once the hierarchy has been loaded, we can proceed to the semantic load statements. The first one loads from the WineDistricts table to establish the parent-child relationship, and the second one loads from the WineDistrictsSubNodes table to establish the ancestor-descendant relationship.
Each semantic load links to the data using TreeID and TreeIDCopy.
Each semantic load also creates two semantic fields, i.e four fields all in all. However, only three of these fields are used: The Parents field really adds no value, so it is not used. But it needs to be there for syntactical reasons. However, the other three fields are very useful: Daughters, BelongsTo, and SubDistricts.
The BelongsTo field is special: In the UI it needs to be sorted not alphabetically, but rather top-down. This is achieved by ordering the Load statement according to the Depth field and displaying the list box using the load order.
A copy of the TreeID is created, since the semantic loads need this. Finally, unnecessary fields are dropped:
The illustrations are from QlikView but this works just as well also in Qlik Sense. Good luck with your semantic links!
HIC