Hierarchies

There are two approaches to modelling hierarchies with Talend MDM. You can:

• Explicitly model all levels of your hierarchy at design time as part of your model.
• Create self-referencing entities that allow N-level hierarchies to be defined at runtime.

In either case, it is important to understand the role of foreign keys in Talend MDM when thinking about hierarchies.

In the following example, two very simple entities are defined: 'simpleParent' and 'simpleChild'.

Now you can deploy to Talend MDM Server and populate some data.

You can see that the data implies a simple hierarchy.

The node 'parentA' can have N children, you simply add more children records that reference 'parentA' as a parent.

You can have multiple hierarchies contained in the same entities.

You could even change your model structure slightly to allow a child to have multiple parents.

You could also change your model to have a parent > child relationship instead of child > parent.

However, there are many issues with this simple approach:

• There is no validation of the relationships between your hierarchy levels. Thus, it is possible to create invalid hierarchies. For example, in your simple child > parent scenario, you may create a 'parentA', but then create a child record that references a non-existent 'parentE', that is a 'parentE' that does not have a record in the 'simpleParent' entity.
  

  If data is only entered into Talend MDM using the integration layer (Jobs and services), you could enforce your hierarchy relationships within the integration logic. However, if you want to use the Talend MDM Web UI for navigating, visualizing or even editing your hierarchies, this approach does not make for a good user experience. For example, if you browse a child record, you can see that it has a parent but you cannot click a link to traverse the relationship. Even worse, there is nothing to stop you from entering incorrect data, and thus corrupting your hierarchy.

• This approach cannot leverage the Talend MDM Hierarchy Explorer or Navigator views. Both of these visualization tools rely on the presence of explicit relationships in the model.
  

  To avoid these issues, you must include explicit foreign key relationships within your model when defining it to represent one or more hierarchies. This allows you to maintain the integrity of your data and improves the user experience greatly.

You can alter the simple child > parent model from the previous example to include explicit relationships:

And add data:

Now you have a simple hierarchy that allows you to:

• Enforce the relationships between parent and child and select or remove the relationship in the UI
  
• Traverse the relationship in the Talend MDM Web UI browser view
  
• Create a parent while creating or editing a child
  
• Use the navigator to traverse the hierarchy
  
• Use the hierarchy explorer view, which can also be used to edit or filter the hierarchy
  

If you want to have more than two levels to your hierarchy and if you know the number of levels at model design time, you can simply add additional entities to your model with relationships.

If you want to use the hierarchy explorer to change the parent of 'childLevel2-2', you can simply drag and drop it to a new parent.

What is happening underneath is that the relationship FK in the model is updated.

As you can see from this example:

• There is nothing implicit in Talend MDM that would prevent a hierarchy from being unbalanced. For more information, see Unbalanced hierarchy.
• This approach to modelling would not allow a ragged hierarchy. For more information, see Ragged hierarchies.
• There is nothing enforcing uniqueness of name at any level. You would need to enforce rules using the integration layer or a 'beforeSaving' process, which is only used if UI edits are allowed, if you had business rules about:
  • A name being unique within a level of a hierarchy
  • A name being unique across all levels of a hierarchy
  • A name being unique across all hierarchies