Reusable vs Anonymous types
There are two primary reasons to name a complex type:
- Reusability: It will appear in the reusable types section of the modeller
- Readability of physical storage
If a type is not named, it will be listed as being an anonymous type in the model.
Entity level
As a general rule, the complex type that defines a complete entity can be left as anonymous. There is usually no benefit to making the type reusable. In terms of the physical storage of MDM, there are no advantages since the table name is taken from the entity name.
Complex types within an entity
Whether a complex type with an entity needs to be reusable depends on how you define your cardinalities. It can of course be reusable if there are benefits to doing so, that is if you need to use this type in multiple entities.
In the following example, a reusable type is not required:
While this is a hierarchical structure, 'testComplex' and its child element 'stuff' can both only appear a maximum of one time. Thus, when they are manifested in the physical storage, the child elements are in the entity level table 'test'. Only elements that can contain data appear in the physical storage, so there is no benefit to having fields for 'testComplex' and 'stuff', since they cannot hold any actual data.
However, should you change the cardinality of 'stuff' to allow multiple instances of it within the list:
Now the physical structure has become more complex, with multiple tables required to store the data as it is modelled. The names of the new tables are not particularly helpful.
Now you can name your types.
It is clear from the physical table names which tables belong to your 'test' entity.
Finally, here is what happens when you create a second entity that reuses the type 'testComplex_T':
You can now see the reuse in action in the physical storage.
The MDM application layer operates at a higher level of abstraction than the physical storage, which is in third normal form and is not actually aware of how the data is physically stored. The application layer understands records as XML documents with relationships to other XML documents. This is a Talend extension to the base definition of XML. However, you can see from this exercise that there are benefits to the physical storage in applying some modelling best practices. Other examples of this are detailed later in this article.
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!