Lead your team forward
OCT 24 / 9AM ET Register nowHistory Tables
The tables are created automatically based on History Plugin configuration (see History Plugin), which is initialized from the MDM Configuration file (see MDM Configuration).
All the following tables are prefixed based on a prefix definition in plugin class="com.ataccama.nme.history.NmeHistoryPlugin"
: [hist_prefix]
.
Name Pattern for History Instance and Master Data Tables
The pattern for history data tables is nearly the same as for current data, but the prefix is different. A history table has simple format: there are columns that keeps format version, valid from/valid to and history data, that are stored as a BLOB.
`[hist_prefix][entity_name][entity_type_suffix] `
-
The entity name is based on
nme-history.xml
. -
The suffix is derived from MDM project transformations (it might differ among MDM projects).
-
_i
stands for instance tables. -
_[Master_layer_name]
stands for master tables of particular master domain view.
-
Examples:
-
h_party_i
-
h_party_Master
Specifically for history plugin, there is additional set of data tables generated. The purpose of them is to keep valid from information, that cannot be kept as a part of the history data tables (performance reasons).
`[hist_prefix]q[entity_name][entity_type_suffix] `
Examples:
-
h_qparty_i
-
h_qparty_Master
Engine Technical Tables
There are also some additional tables created specifically for history plugin:
[hist_prefix]_FORMAT
Keeps all previous formats of history to be able access history table when a history model has changed.
The following tables has the same meaning as for current data, but they are just prefixed by hist_prefix
:
[hist_prefix]_INL_L
Temporary table for SQL queries, which uses where condition including IN statement. IN list table keeps all long items (usually id) which are used in joins instead of doing full scan of a table.
[hist_prefix]_INL_S
Same purpose as _INL_S
, but it is used for string items (usually source_id).
[hist_prefix]_TREG
This table is created only when the VLDB Persistence is used (see see xrefconfiguration:persistence-layer.adoc[], section VLDB Persistence). It keeps the information about ongoing, finished and failed logical transactions. Based on this information, the NME engine is able to provide only the committed data when there is an already running transaction.
When all transactions including the garbage collecting process are finished, the table is empty.
Engine X-tables
These tables are created only when the VLDB Persistence is used (see see Persistence Layer, section VLDB Persistence). In general, the x-tables are used during each data processing and store a list of ids to remove from original non-x table after the transaction is finished successfully. When the transaction completed (including garbage collector process), these tables are empty.
`[hist_prefix]x[entity_name][entity_type_suffix] `
`[hist_prefix]xq[entity_name][entity_type_suffix] `
Examples:
-
h_xparty_i
-
h_xqparty_i
-
h_xparty_Master
-
h_xqparty_Master
Was this page useful?