Datamart Tables

A Datamart Table (DMT) is the internal SQL table that stores Analytics or model data used by Datamarts, Data Loads, and Model Objects (MOs).

Datamart Tables from Data Loads

The Data Manager page describes how data flows through Data Feed > Data Source > Datamart using different Data Loads. Behind these logical objects, the actual data rows are stored in the Datamart Tables. When you run Refresh Data Load or Publish Data Load, data is physically written into Datamart-specific Datamart Tables, not directly into the Datamart object itself.

• Each Datamart/Data Load combination has one or more backing Datamart Tables in the Analytics schema.

• These tables are technical but become visible in:

  • Logs and error messages

  • Admin/maintenance tools

  • Some monitoring or troubleshooting scenarios

Naming Pattern

• Prefix – Prefix is indicating Datamart context and type, e.g. …DMT.…

• Suffix – Suffix DMDL for Data Load backed tables, for example: seeddata.DMT.Segmentation_2147484118_DMDL.1, seeddata.DMT.Segm_Bijou_2147484655_DMDL.12.

Datamart & Datamart Tables

• Datamart – Logical Analytics object configured in Data Manager. It defines:

  • Which Data Sources are joined.

  • Which fields and keys are used.

  • How incremental and publishing behavior works.

• Datamart Table – Physical SQL table where that Datamart’s data resides at a given point in time.

You can think of a Datamart as the configuration and query entry point, while the Datamart Table is the underlying storage table that Data Loads keep up to date.

Datamart Tables in Model Objects

Many Analytics Model Objects (MOs) define several Datamart Tables / Data Model Tables (DMTs) as part of their internal data model. These tables are owned by the model, created and populated during model calculation, and then queried by dashboards or external consumers (via evaluation logics).

Agents and Watchers

For Agents and Watchers are Datamart Tables built on top of a Model Object.

• The Model Object exposes its Datamart Tables as Tables in the application.

• These same tables are visible as Datamart Table options in pickers inside Agent/Watcher configuration (for example, when selecting a table of detected items).

• Detected items are read from model-owned Datamart Tables.

• When Actions are created, the resulting rows are stored in a dedicated Actions Datamart Table.

• When a model-owned Datamart Table structure changes (for example, new columns or renamed columns in an Agent’s backing tables), the system may need to recreate the Datamart Table.

Datamart Tables & Query Fields

In several accelerator models, configuration inputs explicitly note that selected fields become part of multiple Datamart Tables. Typical examples include:

• Product/Customer attributes and hierarchies.

• Revenue, Profit, Quantity, List Price, Reference Price fields.

These fields are propagated from the transaction Datamart into the model’s Datamart Tables (such as Aggregated Transactions and Rolling Period tables), and then reused in dashboards, Agents, and external queries.

Quick Reference

Abbreviation

Where You See Datamart Tables

Example Scenarios

Data Load

• You run a Refresh Data Load to join Customer and Transaction Data Sources into a Sales Datamart.

• The data is stored in an internal table like …DMT.Sales_…_DMDL….

• When you later query the Sales Datamart in the Data Analyzer or Agents, you are reading from this Datamart Table via the Datamart configuration.

Agent Based on a Model

• Data Model defines Datamart Tables such as CustomerRollingPeriod and AggregatedTransactions.

• An Agent reads detected opportunities from these Datamart Tables and writes resulting Actions into an Actions Datamart Table.

• In the Agent Configuration, you select these tables in pickers under Tables, but technically they are model-owned Datamart Tables.