Mart Dimension

A Mart Dimension loads a dimension table of the Mart layer with an integer surrogate key and terms of Historization Type SCD0, SCD1 or SCD2. Use it for the descriptive attributes that Mart Facts reference. You join historized sources on their keys only, without validity conditions, and the generated loader builds the combined history.

A Mart Dimension reads history but does not create it: SCD2 versions come only from sources with a Version Valid From Term.

Sources and relationships

A Mart Dimension reads these sources:

• Data Mart: Mart Composite and Mart Hierarchy Flatten of the project, and linked objects of a Data Vault, Dimensional (Entity, Fact) or Data Store project (Store Entity).
• Vault and Mart: the Raw Vault and Business Vault objects of the project except the composites, Vault Out, Mart Composite and Mart Hierarchy Flatten.
• Dimensional and Mart (not on Databricks dbt and Oracle): Entity, Fact, Mart Composite, Mart Hierarchy Flatten and linked Store Entity.

A Mart Dimension has no relationships of its own. A Mart Fact references it through a relationship, and a Mart Out can read it.

Create a Mart Dimension

• With the wizard: open the menu of the source model object, choose Automate and then Create Mart Dimension. See Create a Model Object with the wizard for its steps.
  
• Manually: create a model object of type Mart Dimension in the Datamart column, create a dataflow set, add the source model objects and map the terms.

Then complete the configuration:

• Mark at least one term as business key.
• In the dataflow set, set Version Valid From Term on each historized source, for example a Satellite, History View or PIT, to its valid-from term. See Configure a multi-version load.
• Change the Historization Type of the terms that are not SCD1. Map SCD2 terms from historized sources.

Historization

• SCD1 (default): a new value overwrites the term in every version of the business key.
• SCD2: a changed value starts a new version.
• SCD0: the value of the first version is kept, also when later loads deliver another value.

Without a Version Valid From Term, the table holds one row per business key, and SCD2 terms fail validation. With Version Valid From Term on one or more sources, a version starts at every valid-from timestamp of these sources. Each version combines the source versions valid at that time. A source without the property adds its current values to every version and starts no version. Consecutive versions with equal SCD1 and SCD2 values are merged. See Change detection and historization.

Properties

• Implementation Type: Permanent (default) or Cached. Permanent inserts new rows and versions and updates SCD1 terms. Cached empties and reloads the table on every load and assigns new surrogate keys. Validation accepts Cached only when every referencing Mart Fact has Fact Load Strategy Truncate Insert alone and Foreign Key Mode None.
• Delta Detection: Hash Value Comparison (default) compares BG_RowHashScd1 and BG_RowHashScd2. Column Comparison compares the SCD1 and SCD2 terms column by column and creates no row-hash columns.
• Load Caching: empty (default) or Hashing, which stores the hashing view in a table before the loader runs.
• Custom Singleton Values: values of the unknown-member row for selected terms.
• Hash Group Size (Oracle): number of terms per group hash in BG_RowHashScd1 and BG_RowHashScd2.
• Version Valid From Term: per dataflow model object, see Historization.

The project property Persist Validity decides whether BG_ValidToTimestamp is a table column or computed by the result view.

Default Terms

• <model object name>_SK (Default Term BG_MartDimension_Identity): the integer surrogate key and primary key, named after the model object. Mart Facts store it as BG_MartFact_ForeignKey_Identity.
• BG_SourceSystem
• BG_LoadTimestamp: the load that inserted or last updated the row.
• BG_ValidFromTimestamp and BG_ValidToTimestamp: the validity of a version. They are generated only when at least one term has SCD2. The business key and BG_ValidFromTimestamp form a unique constraint.
• BG_RowHashScd1 and BG_RowHashScd2: hashes of the SCD1 and the SCD2 terms. SCD0 terms are not hashed.

Deployment inserts an unknown-member row with the surrogate key -1, Unknown for text, 0 for numbers and 1900-01-01 for dates. Custom Singleton Values replaces these values for the selected terms, except the surrogate key, the row hashes and a stored BG_ValidToTimestamp. With Implementation Type Cached, each load writes the row again, so changed values apply after the next load. A Mart Fact row without a matching dimension row references this row.

Generated objects

These are the names on Microsoft SQL Server for a Mart Dimension employee with one dataflow:

• Loaders are stored procedures, DM_MD_employee and the hashing table are tables, all other objects are views.
• Versioning, Scd and RowCondensing views exist only when a source has a Version Valid From Term.
• The hashing table and hashing loader exist only with Load Caching Hashing.
• The hashing view does not exist with Column Comparison.
• The delta view does not exist with Cached.
• All objects except the table and the result view exist once per dataflow.

With all optional objects, the dependencies are:

sources -> _Source -> _Versioning -> _Scd -> _Hashing
_Hashing -> _HashingLoader -> _HashingTable (Load Caching)
_Hashing or _HashingTable -> _RowCondensing -> _Delta
_Delta -> _Loader -> DM_MD_employee -> _Result
_Result -> _Delta (comparison with the stored rows)

Example

The Mart Dimension employee on Microsoft SQL Server reads the Business History View of employees twice: s1 for the employee and s2 for the manager, with an inner join on s1.MANAGER_ID = s2.EMPLOYEE_ID. Both have Version Valid From Term BG_ValidFromTimestamp. The example uses these terms:

• EMPLOYEE_ID: business key.
• BRANCH_ID and MANAGER_LAST_NAME (from s2.LAST_NAME): SCD2.
• LAST_NAME: SCD1.
• BIRTH_DATE: SCD0.

Load 1 delivers this history:

• Employee 1, Meier, born 1990-05-01, manager 2: branch 10 from 2026-01-01, branch 20 from 2026-03-01.
• Employee 2: Huber from 2026-01-01, Huber-Keller from 2026-02-01.

Load 2 adds two versions:

• Employee 1 from 2026-04-01: last name Meier-Schmid, birth date corrected to 1990-05-02.
• Employee 2 from 2026-05-01: Keller.

Check the result

Query the result view, here in the schema mart:

SELECT employee_SK, BG_ValidFromTimestamp, BG_ValidToTimestamp,
       BRANCH_ID, MANAGER_LAST_NAME, LAST_NAME, BIRTH_DATE
FROM mart.DM_MD_employee_Result
WHERE EMPLOYEE_ID = 1
ORDER BY BG_ValidFromTimestamp;

This is the result after load 2, with the first three column names and the timestamps shortened and split into two blocks. 9999-12-31 marks the current version:

SK  ValidFrom   ValidTo     BRANCH_ID  MANAGER_LAST_NAME
1   2026-01-01  2026-02-01  10         Huber
2   2026-02-01  2026-03-01  10         Huber-Keller
3   2026-03-01  2026-05-01  20         Huber-Keller
4   2026-05-01  9999-12-31  20         Keller

SK  LAST_NAME     BIRTH_DATE
1   Meier-Schmid  1990-05-01
2   Meier-Schmid  1990-05-01
3   Meier-Schmid  1990-05-01
4   Meier-Schmid  1990-05-01

• 2026-04-01 starts no version, because only SCD1 and SCD0 terms changed.
• LAST_NAME is Meier-Schmid in all versions, and BIRTH_DATE stays 1990-05-01.
• Load 1 had created versions 1 to 3 with LAST_NAME Meier, version 3 valid to 9999-12-31. They keep their surrogate keys.
• Employee 2 has no manager, so the inner join leaves it out.
• Repeating load 2 changes no row.

Platform differences

• Persist Validity is on by default on Snowflake, Databricks, Databricks dbt, Fabric Lakehouse and Fabric Warehouse, and off on Microsoft SQL Server and Oracle.
• Snowflake: names are in capitals. The load control task LC_DM_MD_<MODEL OBJECT NAME>_TASK calls the loader. The dataflow properties Use Stream and Warehouse Placeholder Variable Name apply.
• Databricks and Fabric Lakehouse: the loader is the notebook DM_MD_<model object name>_Loader. The properties File Format, Optimization Method, Optimization Method Columns and Use Sequential Dataflow Execution apply.
• Databricks dbt: the generator creates the dbt models dm_md_<model object name>_source (view), dm_md_<model object name> (table) and dm_md_<model object name>_result (view, only with Create Result Views on). The table model uses the materialization bg_overwrite for Cached. Load Caching is not available. The properties File Format, Optimization Method and Optimization Method Columns apply.
• Fabric Warehouse: the loader assigns surrogate keys from the current maximum, without an identity column.
• Oracle: physical properties such as Partition Clause, Table Compression and tablespaces apply.

Limitations

• The loader reads the complete source on every load; there is no incremental load.
• A Mart Dimension has exactly one identity term (<model object name>_SK) and at least one business key term.
• With a Version Valid From Term, a Mart Dimension allows one dataflow, one dataflow set and no aggregation.
• Terms with different Historization Types produce a validation warning; the load works.

Release differences

• Generator 2.0: Implementation Type Cached, Load Caching and Delta Detection are available.
• Generator 2.2: Column Comparison and Persist Validity are available. BG_RowHashScd1 and BG_RowHashScd2 replace BG_RowHash. ValidFrom Source Term is renamed Version Valid From Term. Databricks dbt is available.
• Generator 2.3: Custom Singleton Values is available.

Related articles

• Next: Mart Fact, Generate artifacts
• Reference: Implementation Type (Model Object), Delta Detection (Model Object), Load Caching (Model Object), Version Valid From Term (Dataflow Model Object), Custom Singleton Values (Model Object), Hash Group Size (Model Object), Persist Validity (Project), Historization Type (Term and Relationship), BG_MartDimension_Identity, BG_SourceSystem, BG_LoadTimestamp, BG_ValidFromTimestamp, BG_ValidToTimestamp, BG_RowHashScd1, BG_RowHashScd2
• See also: Change detection and historization, Configure a multi-version load, Create a Model Object with the wizard, Mart Composite, Mart Hierarchy Flatten, Mart Out, Model a Data Mart Solution, Historized Source (Business Rule), Version Valid From Term configured (Business Rule), Supported Implementation Types (Business Rule)