Skip to main content

N-level hierarchies

Availability-noteDeprecated
This section defines some best practices regarding N-level hierarchies.

The most advanced technique to model hierarchies in Talend MDM is reserved for the following cases:

  • You do not know how many levels your hierarchy is going to have when designing your model.
  • You want to hold multiple hierarchies in the same entity structure, but the hierarchies may have different numbers of levels.
  • You want to master ragged hierarchies.

To facilitate these requirements, you can introduce a new entity called 'hierarchyNode'.

Notice that:

  • The 'parentFk' field is a foreign key to itself. The parent of a 'hierarchyNode' record is another 'hierarchyNode' record.
  • The 'parentFk' value has a cardinality of 0...1, which means it is optional. This is necessary, since the root node of a given hierarchy does not have a parent. Without setting this field as option, the structure would be infinitely recursive.

If you look at the data in this model structure and in the hierarchy explorer, you can see that you have an N-level hierarchy, with the number of levels determined at runtime, not design time.

The same structure could also hold a second hierarchy, or N additional hierarchies.

You could also reference your 'hierarchyNode' hierarchies from other entities to denote membership of something at a given node of a hierarchy, or multiple hierarchy memberships.

Above, you can see a 'product' entity, which can have 1...many relationships with various 'hierarchyNodes' (and therefore, with various hierarchies).

You can also extend the 'hierarchyNode' concept by introducing the idea of an entity that defines each of your hierarchies, hierarchy Xrefs (to source values) and an entity that allows runtime definition of hierarchy levels.

Did this page help you?

If you find any issues with this page or its content – a typo, a missing step, or a technical error – let us know how we can improve!