This chapter is an introduction to history tables and replicated tables.
The term mapped mode refers to any tables that are stored as-is, and thus whose contents can be accessed directly in the database.
Data that is modeled in and governed by the EBX® repository are primarily persisted in the relational database, using generic tables (common to all datasets and data models).
Master data tables can activate historization in order to track modifications to their data, regardless of whether they are replicated.
The history itself is in mapped mode, meaning that it can be consulted directly in the underlying database.
Replication enables direct SQL access to tables of master data, by making a copy of data in the repository to replica tables in the relational database. Replication can be enabled on any table regardless of whether it has history activated.
The replica tables are persisted in mapped mode, as their primary purpose is to make master data accessible to direct queries outside of EBX®.
Mapped mode refers to cases where tables are persisted in the underlying relational database in a format that allows their data to be accessed directly, outside of EBX®. History tables and replica tables are all examples of tables in mapped mode.
All cases of mapped mode involve automatic alterations of the database schema (the database tables, indexes, etc.) when necessary, by automatically executing required DDL statements in the background. Such procedures are always triggered at data model compilation time and the data model compilation report notifies of any resulting errors.
Another general consideration regarding mapped modes is that, in most cases, when a data model entity is removed, its corresponding database object is not deleted immediately. Instead, it is marked as disabled, which leaves the possibility of later re-enabling the object. In order to definitively drop the object and its associated data and resources from the database, it must be marked for purge. The removal then takes place during the next global purge.
When a mapped mode is set, some EBX® data model constraints will generate a "structural constraint" on the underlying RDBMS schema. This concerns the following constraining 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: when a transaction does not comply with a blocking constraint, it is cancelled and a ConstraintViolationException is thrown.
Due to the nature of persisting directly in the underlying database, some restrictions apply to all tables stored in mapped mode:
Unlimited-length strings: All string fields, except foreign keys, of type xs:string, its derived types, and xs:anyURI must define a 'maxLength' or 'length' facet. Since a foreign key field is composed of the final primary key field(s) of its target table(s), this facet requirement applies to each of those final primary key fields instead of the foreign key field itself. Additionally, limitations of the underlying database concerning the maximum length of its character types apply, such as VARCHAR and NVARCHAR2.
Large lists of columns might not be indexable. Example for Oracle: the database enforces a limit on the maximum cumulated size of the columns included in an index. For strings, this size also depends on the character set. If the database server fails to create the index, you should consider redesigning your indexes, typically by using a shorter length for the concerned columns, or by including fewer columns in the index. The reasoning is that an index leading to this situation would have headers so large that it could not be efficient anyway.
Fields of type type="osd:password" are ignored.
Terminal complex types are supported; however, they cannot be globally set to null at record-level.
More generally, tables in mapped mode are subject to any limitations of the underlying RDBMS. For example, the maximum number of columns in a table applies (1000 for Oracle, 1600 for PostgreSQL). Note that a history table contains twice as many fields as declared in the schema (one functional field, plus one generated field for the operation code).
Data model evolutions may also be constrained by the underlying RDBMS, depending on the existing data model.