The principle of inheritance is to mutualize resources that are shared by multiple contexts or entities. TIBCO EBX® offers mechanisms for defining, factorizing and resolving data values: dataset inheritance and inherited fields.
Furthermore, functions can be defined to compute values.
Inheritance mechanisms described in this chapter should not be confused with "structural inheritance", which usually applies to models and is proposed in UML class diagrams for example.
Dataset inheritance is particularly useful when data applies to global enterprise contexts, such as subsidiaries or business partners.
Given a hierarchy of datasets, it is possible to factorize common data into the root or intermediate datasets and define specialized data in specific contexts.
The dataset inheritance mechanisms are detailed below in Dataset inheritance.
Contrary to dataset inheritance, which exploits global built-in relationships between datasets, inherited fields exploit finer-grained dependencies that are specific to the data structure. It allows factorizing and specializing data at the business entities-level.
For example, if the model specifies that a 'Product' is associated with a 'FamilyOfProducts', it is possible that some attributes of 'Product' inherit their values from the attributes defined in the associated 'FamilyOfProducts'.
When using both inheritance mechanisms in the same dataset, field inheritance has priority over dataset inheritance.
In the data model, it is also possible to specify that a node holds a computed value. In this case, the specified JavaBean function will be executed every time the value is requested.
The function is able to take into account the current context, such as the values of the current record or computations based on another table, and to send requests to third-party systems.
The dataset inheritance mechanism is declared from DMA in the data model (Configuration > Data model properties) or directly in the XML Schema Definition, when using (Actions > Import data model):
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:ebxbnd="urn:ebx-schemas:binding_1.0">
<xs:annotation>
<xs:appinfo>
<osd:inheritance>
<dataSetInheritance>all</dataSetInheritance>
</osd:inheritance>
</xs:appinfo>
</xs:annotation>
...
</xs:schema>
The element osd:inheritance defines the property dataSetInheritance to specify the use of inheritance on datasets based on this data model. The following values can be specified:
all, indicates that inheritance is enabled for all datasets based on the data model.
none, indicates that inheritance is disabled for all datasets based on the data model.
If not specified, the inheritance mechanism is disabled.
The dataset inheritance lookup mechanism for values proceeds as follows:
If the value is locally defined, it is returned.
It can be explicitly null.
Otherwise, looks up the first locally defined value according to the built-in child-to-parent relationship of the dataset in the hierarchy of datasets.
If no locally defined value is found, the default value is returned.
If no default value is defined, null is returned.
Note: Default values cannot be defined on:
A single primary key node
Auto-incremented nodes
Nodes defining a computed value
Like values, table records can also be inherited as a unit by multiple contexts, but they can also be partially redefined (overwritten), defined for a specific context (root mode), or be occulted.
Formally, a table record has one of four distinct definition modes:
root record | Locally defined in the table and has no parent. This means that no record with the same primary key exists in the parent table, or that this parent is an occulting record. |
overwriting record | Locally defined in the table and has a parent record. This means that a record with the same primary key exists in the parent table, and that this parent is not an occulting record. The overwriting record inherits its values from its parent, except for the values that it explicitly redefines. |
inherited record | Not locally defined in the current table and has a parent record. All values are inherited. Functions are always resolved in the current record context and are not inherited. |
occulting record | Specifies that, if a parent with the same primary key is defined, this parent will not be visible in table descendants. |
It is also possible to specify management rules in the declaration of a table in the data model.
The specific inheritance mechanism allows fetching a value of a field according to its relationship to other tables.
Specific inheritance must be specified:
on the node's advanced properties in the underlying data model.
on terminal nodes in the underlying data model and is declared as follows:
<xs:element name="sampleInheritance" type="xs:string"> <xs:annotation> <xs:appinfo> <osd:inheritance> <sourceRecord> /root/table1/fkTable2, /root/table2/fkTable3 </sourceRecord> <sourceNode>color</sourceNode> </osd:inheritance> </xs:appinfo> </xs:annotation> </xs:element>
The element sourceRecord is an expression that describes how to look up the record from which the value is inherited. It is a foreign key, or a sequence of foreign keys, from the current element to the source table.
If sourceRecord is not defined in the data model, the inherited fields are fetched from the current record.
The element sourceNode is the path of the node from which to inherit in the source record.
The following conditions must be satisfied for specific inheritance:
The element sourceNode is mandatory.
The expression for the path to the source record must be a consistent path of foreign keys, from the current element to the source record. This expression must involve only one-to-one and zero-to-one relationships.
The sourceRecord cannot contain any aggregated list elements.
Each element of the sourceRecord must be a foreign key.
If the inherited field is also a foreign key, the sourceRecord cannot refer to itself to get the path to the source record of the inherited value.
Every element of the sourceRecord must exist.
The source node must belong to the table containing the source record.
The source node must be terminal.
The source node must be writeable.
The source node type must be compatible with the current node type.
The source node cardinalities must be compatible with those of the current node.
The source node cannot be the same as the inherited field if the fields to inherit from are fetched into the same record.
The lookup mechanism for inherited fields values proceeds as follows:
If the value is locally defined, it is returned.
It can be explicitly null
Otherwise, looks up the source record and value to inherit from, according to the properties that are defined in the data model.
The process is recursive; if the source node does not locally define a value, it is then looked up according to the inheritance behavior of the source node.
EBX® provides a built-in user service for optimizing the dataset inheritance in the hierarchy of datasets. This service performs the following functions:
Handles duplicated values: Detects and removes all parameter values that are duplicates of the inherited value.
Mutualizes common values: Detects and mutualizes the common values among the descendants of a common ancestor.
Datasets are processed from the bottom up, which means that if the service is run on the dataset at level N, with N+1 being the level of its children and N+2 being the level of its children's children, the service will first process the datasets at level N+2 to determine if they can be optimized with respect to the datasets at level N+1. Next, it would proceed with an optimization of level N+1 against level N.
These optimization and refactoring functions do not handle default values that are declared in the data model.
The highest level considered during the optimization procedure is always the dataset on which the service is run. This means that optimization and refactoring are not performed between the target dataset and its own ancestors.
Table optimization is performed on records with the same primary key.
Inherited fields are not optimized.
The optimization and refactoring functions do not modify the resolved view of a dataset, if it is activated.
The 'Optimize & Refactor' service is available on datasets that have child datasets and have the 'Activated' property set to 'No' in their dataset information.
The service is available to any profile with write access on current dataset values. It can be disabled by setting restrictive access rights on a profile.
For performance reasons, access rights are not verified on every node and table record.