Information and services relative to database mapping can be found in the Administration area.
This feature is available on the 'Columns' table records, under the 'Actions' menu. It allows renaming a column in the database.
The administrator can specify the name of each column of the data model in the database for mapped modes.
Once the service is selected on a record, a summary screen displays information regarding the selected column and the administrator is prompted to enter a new name for the column in the database.
It is required that the new identifier begins with a letter.
Besides, the new name must be a valid column identifier, which depends on the naming rules of the underlying RDBMS.
This feature is available on the 'Columns' table records, under the 'Actions' menu. It allows purging columns in mapped structures.
A column can be purged if it has been disabled for mapped modes.
A column is disabled for mapped modes when:
the corresponding field has been removed from the data model, or
the corresponding field has been changed in the data model, in a way that is not compatible (for example: its data type has been modified), or
the defined mapped modes have been disabled locally on the corresponding fields, using the elements osd:history and osd:replication.
Note that this behavior will change for aggregated lists:
when deactivating a complex aggregated list, its inner fields will still be in the LIVING state, whereas the list node is disabled. As lists are considered as auxiliary tables in the mapping system, this information can be checked in the 'Tables' table,
on the other hand, when the deactivation is just for inner nodes of the list, then the list will remain LIVING, while its children will be DISABLED IN MODEL.
A column can be purged only if its own state is DISABLED IN MODEL, or if it is an inner field of a DISABLED IN MODEL list.
This feature allows renaming master tables for both relational and history modes in the database. However, it is not available for replicated tables since their names are specified in the data model.
Both features are available on the 'Tables' table records, under the 'Actions' menu.
Master tables are database tables used for persisting the tables of the data model.
The administrator can specify in the database the name of each master table corresponding to a table of the data model.
Once the service is selected on a record, a summary screen displays information regarding the selected master table and the administrator is prompted to enter a new name for the master table in the database.
It is required that the new identifier begins with a letter and with the repository prefix.
For history tables, it is also required that the repository prefix is followed by the history tables prefix.
For relational tables, it is also required that the repository prefix is followed by the relational tables prefix.
Besides, the new name must be a valid table identifier, which depends on the naming rules of the underlying RDBMS.
This feature allows renaming history auxiliary tables in the database. This feature is neither available for replicated tables since their names are specified in the data model, nor for the relational mode, as aggregated lists are never supported in this mode.
This feature is available on the 'Tables' table records, under the 'Actions' menu.
Auxiliary tables are database tables used for persisting aggregated lists.
The administrator can specify in the database the name of each auxiliary table corresponding to an aggregated list of the data model.
Once the service is selected on a record, a summary screen displays information regarding the selected auxiliary table and the administrator is prompted to enter a new name for the auxiliary table in the database.
It is required that the new identifier begins with a letter.
It is required that the new identifier begins with the repository prefix.
It is also required that the repository prefix is followed by the history tables prefix.
Besides, the new name must be a valid table identifier, which depends on the naming rules of the underlying RDBMS.
This feature allows purging history and relational tables in the database if they are no longer used.
It is available on the 'Tables' table records, under the 'Actions' menu, and is only available for master tables. This feature only applies to master tables. When a master table is purged, all its auxiliary tables are purged as well.
A mapped table can be purged in the database only if it has been disabled for the corresponding mapped mode.
To disable the mapped mode for a table, follow the procedure hereafter.
For history mode:
Deactivate historization of the table in the data model, or
Remove the table from the data model
For relational mode:
Remove the table from the data model, or
Deactivate the relational mode on the data model. As data models in semantic mode cannot be used for relational dataspaces, it is thus necessary to create a dataset on a semantic dataspace using this modified data model. TIBCO EBX® will then detect that the relational mode was previously used, and will therefore propose the relational table database resources for purge.