Mart Out

A Mart Out is a model object type of the Mart layer that combines Mart objects into one output that is read after the star schema. Use it as the final object that consumers query, or as the source of another Mart Out. With Implementation Type Virtual you get views only; with Cached you also get a table that each load fills again.

Available since Generator 2.2. A Mart Out reads only Mart objects, also in Vault and Mart and in Dimensional and Mart projects.

Sources and consumers

A Mart Out reads these model object types:

• Mart Composite, Mart Dimension, Mart Fact and Mart Hierarchy Flatten of the project.
• Another Mart Out of the project.
• In a Data Mart project, a Mart Out that you imported from another project through Data Connections. The source view reads its result view DM_MO_<model object name>_Result through the placeholders {<project identifier>#<import name>#database_name}, schema_name and server_name, which you set when you replace the placeholders. Nothing is generated for the imported Mart Out itself.

Raw Vault, Business Vault, Dimensional and Data Store objects, PITs and linked objects other than a Mart Out are not valid sources. A Vault Out is not a valid source either.

Among model objects, only another Mart Out can use a Mart Out as source. A Mart Out has no relationships.

Create a Mart Out

• With the wizard: open the menu of a Mart Composite, Mart Dimension, Mart Fact, Mart Hierarchy Flatten or Mart Out, choose Automate and then Create Mart Out. The steps are Create Model Object, Create Dataflow, Map Selected Terms and Add to View; see Create a Model Object with the wizard. Implementation Type is preset to Virtual. Map Selected Terms lists the terms of the source with their data type and business-key flag; select the terms the Mart Out gets.
• Manually: create a model object of type Mart Out in the Mart layer, create a dataflow set, add the source model objects and map the terms.

A Mart Out has exactly one dataflow. Join several sources in its dataflow set, or combine dataflow sets with a set operator.

Properties

• Implementation Type: Virtual (default) or Cached. Virtual creates views only, so the result view reads the sources at query time. Cached adds a table and a loader. The loader empties the table and inserts all rows again on every load.
• Deduplication Method, set per dataflow: None (default), Distinct or Partition. Distinct removes rows that are equal in all terms. Partition keeps one row per business key, the first one by Sort Order within Partition.
• Sort Order within Partition, set per dataflow: the order that decides which row Partition keeps.

Edit Term offers the Business Key flag on Mart Out terms. Only Partition uses it. Without business keys, Partition partitions by all terms that are not Default Terms, which removes the same rows as Distinct, and validation shows warning ID-10051.

Default Terms

• BG_LoadTimestamp: with Cached, the loader writes the load timestamp. In a Virtual Mart Out it is NULL unless you map it.
• BG_SourceSystem: NULL unless you map it.

The wizard maps neither of them.

Generated objects

These are the names on Microsoft SQL Server for a Mart Out sales_mo:

• The loader is a stored procedure and the table is a table; all other objects are views.
• The source view reads the result views of the sources, for example DM_MD_<model object name>_Result of a Mart Dimension.
• The deduplication view exists only with Distinct or Partition.
• The table and the loader exist only with Cached. Load control runs the loader after the loaders of the sources.
• The result view reads the table with Cached, otherwise the deduplication or source view.

sources -> _Source -> _Deduplication (Distinct or Partition)
Cached:  last view -> _Loader -> DM_MO_sales_mo -> _Result
Virtual: last view -> _Result

Example

Two Mart Outs on Microsoft SQL Server, in the schema m:

• sales_mo reads QUANTITY and TRANSACTION_TIME of the Mart Dimension common_salestransaction. Implementation Type is Cached and Deduplication Method is Distinct.
• sales_report_mo reads the same terms from sales_mo with Implementation Type Virtual.

The Default Terms are not mapped. The result view of the Mart Dimension delivers three rows: quantity 2 at 2026-04-01 10:00 twice and quantity 5 at 11:00. After the loader of sales_mo ran at 2026-04-02 06:00, query both result views:

SELECT QUANTITY, TRANSACTION_TIME, BG_LoadTimestamp, BG_SourceSystem
FROM m.DM_MO_sales_mo_Result ORDER BY QUANTITY;
SELECT QUANTITY, TRANSACTION_TIME, BG_LoadTimestamp, BG_SourceSystem
FROM m.DM_MO_sales_report_mo_Result ORDER BY QUANTITY;

This is the result, with the timestamps shortened. Distinct keeps the two equal rows of quantity 2 once:

sales_mo
QUANTITY  TRANSACTION_TIME  BG_LoadTimestamp  BG_SourceSystem
2.000     2026-04-01 10:00  2026-04-02 06:00  NULL
5.000     2026-04-01 11:00  2026-04-02 06:00  NULL

sales_report_mo
QUANTITY  TRANSACTION_TIME  BG_LoadTimestamp  BG_SourceSystem
2.000     2026-04-01 10:00  NULL              NULL
5.000     2026-04-01 11:00  NULL              NULL

Then the Mart Dimension stops delivering the row with quantity 5. sales_report_mo still returns both rows, because it reads the table of sales_mo. The loader of sales_mo at 2026-04-03 06:00 reports 1 inserted row, the two equal rows counted once. Afterwards the same queries return:

sales_mo
QUANTITY  TRANSACTION_TIME  BG_LoadTimestamp  BG_SourceSystem
2.000     2026-04-01 10:00  2026-04-03 06:00  NULL

sales_report_mo
QUANTITY  TRANSACTION_TIME  BG_LoadTimestamp  BG_SourceSystem
2.000     2026-04-01 10:00  NULL              NULL

Platform differences

• Snowflake: names are in upper case, and the table is transient. The loader overwrites the table, and the load control task LC_DM_MO_<MODEL OBJECT NAME>_TASK calls it; a Virtual Mart Out has no task. The dataflow properties Use Stream and Warehouse Placeholder Variable Name apply.
• Databricks and Fabric Lakehouse: the loader is the notebook DM_MO_<model object name>_Loader and overwrites the table. The properties File Format, Optimization Method and Optimization Method Columns apply.
• Databricks dbt: the generator creates the dbt models dm_mo_<model object name>_source (view, with the deduplication inside), dm_mo_<model object name> (table, only with Cached) and dm_mo_<model object name>_result (view, only with Create Result Views on). There is no loader. File Format, Optimization Method and Optimization Method Columns apply.
• Oracle: the properties Partition Clause, Table Compression, Create Table Statistics, Parallel Degree of Statistics Calculation, Tablespace Table and Tablespace Index apply to the table.

Limitations

• A Mart Out has exactly one dataflow, at least one term that is not a Default Term, and no relationships.
• Implementation Type Permanent and Deduplication Method Condensing fail validation.
• A Cached Mart Out keeps no history: each load replaces all rows.

Related articles

• Next: Generate artifacts
• Reference: Implementation Type (Model Object), Deduplication Method (Dataflow), Deduplication Partition (Dataflow), BG_LoadTimestamp, BG_SourceSystem
  • Snowflake: Use Stream (Model Object)
  • Databricks: File Format (Model Object), Optimization Method (Model Object), Optimization Method Columns (Model Object)
  • Databricks dbt: File Format (Model Object), Optimization Method (Model Object), Optimization Method Columns (Model Object)
  • Fabric Lakehouse: File Format (Model Object), Optimization Method (Model Object), Optimization Method Columns (Model Object)
  • Oracle: no Partition Clause, Table Compression or tablespace article available yet
• See also: Create a Model Object with the wizard, Create a Mart Composite, Mart Dimension, Create a Mart Fact, Create a Mart Hierachy Flatten, Create a Vault Out, Use Linked Projects, Import a Project to be used as a Linked Project