User Community Service Desk Downloads
If you can't find the product or version you're looking for, visit support.ataccama.com/downloads

Engine Tables

The tables are created automatically based on Model configuration files (see Model). All the following tables are prefixed based on a prefix definition in MDM Configuration (see MDM Configuration): [prefix].

Name Pattern for Instance and Master Data Tables

These two types of tables store all the cleansed, matched and merged data processed by the engine. The following pattern is used for General CDI project, but it might differ in other MDM projects:

`[prefix][entity_name][entity_type_suffix] `

  • The entity name is based on nme-model.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:

  • a_party_i

  • a_party_Master

Engine Technical Tables

Following tables don’t have any business related data. They are used by the NME engine itself to manage it’s processes.

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

[prefix]_INL_S

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

[prefix]_ORIGIN

Table is used to store generated origin id code (hash) and related origin.` `

[prefix]_TASKS

The table is used to store information about finished tasks (load, export, processDelta).

[prefix]_STATS

The table is used to store information about counts of process data divided into active and inactive (plus divided per system on instance layer).

[prefix]_TREG

This table is created only when the VLDB Persistence is used (see Persistence Layer, 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.

[prefix]_EXPORT_REG

The table is used to manage incremental exports. It contains export name and the last exported transactional id.

[prefix]ID_SEQ

The table (or sequence, depends on DB support) stores the maximum id assigned by the NME engine.

[prefix]TASK_SEQ

The table (or sequence, depends on DB support) stores the maximum id assigned by the NME engine (used only for tasks).

[prefix]_DRAFTS

Created only when MDM back-end component is enabled. Contains the current record drafts.

[prefix]_DRAFTS_HISTORY

Created only when MDM back-end component is enabled. Contains the past record drafts.

[prefix]_DRAFTS_RECORD_IDS

Created only when MDM back-end component is enabled. Contains draft identifier and corresponding MDM record(s) identifiers.

[prefix]_DRAFTS_RECORD_IDS_HISTORY Created only when MDM back-end component is enabled. Contains historical draft identifier and corresponding MDM record(s) identifiers.

Engine X-tables

These tables are created only when the VLDB Persistence is used (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.

[prefix]x_stats

[prefix]x_export_reg

[prefix]x[entity_name][entity_type_suffix]

Examples:

  • a_xparty_i

  • a_xparty_Master

Engine Override Tables

Instance and master engine override tables store the original values of instance record source attributes as well as the output of merge plans for master records, provided they were then manually overridden using MDM or through Native Services (see Native Services).

Table name syntax:

[prefix][entity_name][entity_type_suffix]_O

Examples:

  • A_PARTY_I_O

  • A_PARTY_MASTER_O

In the override tables there are two columns for each attribute on the instance/master layer that hold the information about the original value and activation flag (0/1) for the specific attribute.

  • O_[column_name]

  • A_[column_name]

Examples:

  • A_CMO_ZIP

  • O_CMO_ZIP

Was this page useful?