Relational mode

Overview of modes

Semantic mode explained

Semantic mode offers all TIBCO EBX® advanced features of master data management, in particular, dataspaces, dataset inheritance, and inherited fields.

Semantic mode is the default mode for persisting the data governed by the EBX® repository. Data models are in semantic mode unless relational mode is explicitly specified.

Internally, the master data managed in semantic mode is represented as standard XML, which complies with the XML Schema Document of its data model. The XML representation is additionally compressed and segmented for storage into generic relational database tables. This mode provides efficient data storage and access, including for:

• Dataspaces: no data is duplicated when creating a child dataspace, and

• Inheritance: no data is duplicated when creating an inherited instance.

Semantic mode also makes it possible to maintain an unlimited number of datasets for each data model, organized into an unlimited number of dataspaces or snapshots. This can be done with no impact on the database schema.

As this mode only uses common, generic internal tables, modifications to the structure of the data model also never impact the database schema. Data model evolutions only impact the content of the generic database tables.

Relational mode explained

Relational mode, which is a mapped mode, persists master data directly into the database. The primary function of relational mode is to be able to benefit from the performance and scalability capabilities of the underlying relational database. However, relational mode does not support the advanced governance features offered by semantic mode.

For some cases where the management advantages of semantic mode are not necessary, such as "current time" tables, or tables that are regularly updated by external systems, the performance gains offered by relational mode may be more valuable.

Generally, when a dataset is in relational mode, every table in this dataset has a corresponding table in the database and every field of its data model is mapped to a relational table column.

Direct comparison of semantic and relational modes

This table summarizes the differences between the two persistence modes:

Enabling relational mode for a data model

The data model declares that it is in relational mode. Due to the necessary restrictions of relational mode, such as not having child dataspaces or snapshots, a specific relational dataspace must be provided, to which the data model will be published. Relational dataspaces do not allow creating sub-dataspaces or snapshots.

Example of a relational mode declaration:

<xs:schema>
	<xs:annotation>
		<xs:appinfo>
			<osd:relationalMode>
				<dataSpace>aDataSpaceKey</dataSpace>
				<dataSet>aDataSetReference</dataSet>
				<tablesPrefix>aPrefixForTablesInRDBMS</tablesPrefix>
			</osd:relationalMode>
		</xs:appinfo>
	</xs:annotation>
	...
</xs:schema>

with the elements:

Validation

This section details the impact of relational mode on data validation.

Structural constraints

Some EBX® data model constraints will generate a "structural constraint" on the underlying RDBMS schema for relational mode and also if table history is activated. This concerns the following facets:

• facets xs:maxLength and xs:length on string elements;

• facets xs:totalDigits and xs:fractionDigits on xs:decimal elements.

Databases do not support as tolerant a validation mode as EBX®. Hence, the above constraints become blocking constraints. A blocking constraint means that updates are rejected if they do not comply. Additionally, such constraints are no longer checked during validation process, except for foreign key constraints under some circumstances (see Foreign key blocking mode). When a transaction does not comply with a blocking constraint, it is cancelled and a ConstraintViolationException is thrown.

Foreign key blocking mode

In order to reduce validation time, foreign key constraints are automatically set in blocking mode if:

• The foreign key constraints are defined on a table in relational mode,

• The foreign key constraints are defined on a table in semantic or relational mode referencing a table in relational mode.

For these constraints, blocking mode implies that attempting the following actions will result in a ConstraintViolationException:

• Deleting a record referenced by a foreign key constraint,

• Deleting an instance referenced by a foreign key constraint,

• Closing a dataspace referenced by a foreign key constraint.

However, it is possible to overwrite this behavior by setting a specific control policy. See Blocking and non-blocking constraints for more information.

In order to ensure the integrity of foreign key constraints after direct SQL writes that bypass the EBX® governance framework, the foreign key constraints will be validated on the following cases:

• On the first explicit validation through the user interface or API,

• On the first explicit validation through the user interface or API after refreshing the schema,

• On the first explicit validation through the user interface or API after resetting the validation report of a dataset in the user interface.

Important:

• Blocking aspect of the foreign key constraint does not concern filters that may be defined. That is, a foreign key constraint is non-blocking if a referenced record exists but does not satisfy a foreign key filter. In this case, updates are not rejected and thus an error will be added to the validation report.

• Foreign key constraints are not in blocking mode upon archive import. Indeed, all blocking constraints, excepted structural constraints, are always disabled when importing archives. This allows flexibility upon archive import where under certain circumstances the import of foreign keys referencing records that are not yet imported must be tolerant.

Constraints on the whole table

Programmatic constraints are checked on each record of the table at validation time. If the table defines millions of records, this becomes a performance issue. It is then recommended to define a table-level constraint.

In the case where it is not possible to define such a table-level constraint, it is recommended to at least define a local or explicit dependency, so as to reduce the cost of incremental validation.

SQL access to data in relational mode

This section describes how to directly access the data in relational mode, through SQL.

Finding the table in the database

For every EBX® table in relational mode, a corresponding table is generated in the RDBMS. Using the EBX® user interface, you can find the name of this database table by clicking on the documentation pane of the table.

SQL reads

Direct SQL reads are possible in well-managed, preferably short-lived transactions. However, for such accesses, EBX® permissions are not taken into account. As a result, applications given allowed to perform reads must be trusted through other authentication processes and permissions.

SQL writes

Direct SQL writes bypass the governance framework of EBX®. Therefore, they must be used with extreme caution. They could cause the following situations:

• failure to historize EBX® tables;

• failure to execute EBX® triggers;

• failure to verify EBX® permissions and constraints;

• modifications missed by the incremental validation process;

• losing visibility on EBX® semantic tables, which might be referenced by foreign keys.

Consequently, direct SQL writes are to be performed if, and only if, all the following conditions are verified:

• The written tables are not historized and have no EBX® triggers.

• The application performing the writes can be fully trusted with the associated permissions, to ensure the integrity of data. Specifically, the integrity of foreign keys (osd:tableRef) must be preserved at all times. See Foreign key blocking mode for more information.

• The application server running EBX® is shut down whenever writes are performed. This is to ensure that incremental validation does not become out-of-date, which would typically occur in a batch context.

Limitations of relational mode

The relational mode feature is fully functional, but has some known limitations, which are listed below. If using relational mode, it is strongly recommended to read these limitations carefully and to contact the TIBCO EBX® Support team at https://support.tibco.com in case of questions.

See Supported databases for the databases on which relational mode is supported.

Data model restrictions for tables in relational mode

Some restrictions apply to data models in relational mode:

• Data model restrictions due to mapped mode

• Aggregated lists are not supported in relational tables. Such a schema will cause a compilation error.

• User-defined attributes on relational tables result in data model compilation errors.

• Dataset inheritance.

• Inherited fields.

• Programmatic constraints, since the computation cost of validation would be too high. However, constraints on tables remain available.

Schema evolutions may also be constrained by the underlying RDBMS, depending on the data already contained in the concerned tables.

Other limitations of relational mode

• Limitations of mapped mode

• From a dataspace containing datasets in relational mode, it is not possible to create child dataspaces and snapshots.

• For D3, it is not possible to broadcast a dataspace defined in relational mode.

• For very large volumes of data, the validation will show poor performance if the relational table declares any of these features: osd:function, osd:select, osd:uiFilter, osd:tableRef/filter. Additionally, a sort cannot be applied on a osd:function column.

• It is not possible to set the AdaptationValue.INHERIT_VALUE to a node belonging to a data model in relational mode.