User Community Service Desk Downloads
If you can't find the product or version you're looking for, visit

History 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.


  • 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] `


  • h_qparty_i

  • h_qparty_Master

Engine Technical Tables

There are also some additional tables created specifically for history plugin:


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:


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.


Same purpose as _INL_S, but it is used for string items (usually source_id).


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] `


  • h_xparty_i

  • h_xqparty_i

  • h_xparty_Master

  • h_xqparty_Master

Was this page useful?