---
title: "Delta Generation Details"
canonical: "https://docs.vaultspeed.com/space/VPD/3081437259/Delta%20Generation%20Details"
format: markdown
---
> Macro (toc)

# Introduction

Delta generations complement full generations by generating only the code representing changes between releases. **Delta comparisons can only be executed against production releases.**

A **Data Vault release becomes a production release** when a **Production Date** is set.

# Production Date

Over time, source and Data Vault models change due to:

- **Source metadata updates**
- **VaultSpeed configuration changes**

Once a release is deployed to production, the **Production Date** can be set in the **Data Vault Releases** screen:

![image](media://0b129d88-13ee-422d-83d5-f9bc5a5b60de)

- Selecting a release and clicking **Upgrade** opens a calendar to set a Production Date.
- **Objects added to a Data Vault Release without a Production Date** will be removed from a new Data Vault Release if they no longer exist in the source release.
- **Objects in a Data Vault Release with a Production Date** **cannot be deleted or renamed** after deployment.

> 📝 **Important:**  
> 📝 Setting the **Production Date** locks **schema, object, and attribute names** to prevent inconsistencies in the Data Vault.

# Delta Generation

The **Delta Generation** tab allows you to compare two **Data Vault (DV) releases** to identify and apply changes.

#### **Prerequisites for Delta Generation**

Delta generation is **only supported** if the following conditions are met:

1. The **old** release has been marked as a **production release** (i.e., a **Production Date** has been set).
2. A **new** release has been created **after** setting the Production Date.

#### **How Delta Generation Works**

- VaultSpeed compares the **old** and **new** Data Vault releases to detect structural and metadata differences.
- The system generates a `xxx_COMP.zip` file containing:
  - **DDL (Data Definition Language) updates**
  - **ETL/ELT updates**
- This file reflects all required changes to **upgrade** the **old release** to the **new release**.

#### `COMP.zip `File Structure

- **Subfolders categorize detected changes.**
- If VaultSpeed **autogenerates data migration scripts**, a `MIGR`** folder** will be included within the **ETL folder**.
- Migration scripts are always **plain SQL** and only need to be **executed once**.

#### **Deployment**

- The `COMP.zip` file can be **automatically deployed** using the VaultSpeed agent.

> ⚠️ #### **Important Considerations for Delta Generation**
> ⚠️ 
> ⚠️ **Warning:**
> ⚠️ 
> ⚠️ **When performing a delta generation, ensure that the parameter **`DDL_DROP`** is set to **`Y`**.**  
> ⚠️ This is critical for the success of the **deployment**.* *If this parameter is not set to* *`Y`*, *you risk incomplete or inaccurate delta generation results. Please double-check this setting before proceeding with the process.
> ⚠️ 
> ⚠️ 
> ⚠️ **Databricks Autodeploy Limitation:**
> ⚠️ 
> ⚠️ For **Databricks**, the **autodeploy function** does **not** automatically execute files in the **MIGR folder**. These scripts must be **manually executed** by the end-user **before running new data loads**.
> ⚠️ 
> ⚠️ 
> ⚠️ **Supported Changes in Delta Generation:**  
> ⚠️ The changes described below are the **only** modifications supported by the **Delta Generation** process.  **Any other changes to structures or parameters** **may have an unknown impact on the delta generation results.**


## Supported FMC Changes


| **Change** | **Create DDL** | **Drop DDL** | **Alter DDL** | **New ETL** | **Drop ETL** | **Data Migration Needed** | **Data Migration Automatically Generated** |
| --- | --- | --- | --- | --- | --- | --- | --- |
| **Parameter OBJECT_SPECIFIC_LOADING_WINDOW = Y** | N/A | N/A | :check_mark: | :check_mark: | :check_mark: | Yes | No |
| When changing the parameter OBJECT_SPECIFIC_LOADING_WINDOW from N to Y, the delta generation will detect this and will generate the new versions of the different FMC procedures and will upgrade the different FMC loading tables to contain the object related attributes.<br>In order to do a correct next incremental load, the loading history table will need to be loaded with the different objects, based on the last load information.  It's best to use the content of the set_fmc procedure to ensure you have the complete list of entities that you need to preload. |

## Supported Source/Data Vault Changes

The table below outlines the **supported changes** that can be detected and processed during delta generation. Each change impacts different aspects of the **Data Vault model and ETL/DDL processes**. Unsupported modifications may require manual intervention.

### Source Changes

| **Change** | **Create DDL** | **Drop DDL** | **Alter DDL** | **New ETL** | **Drop ETL** | **Data Migration Needed** | **Data Migration Automatically Generated** |
| --- | --- | --- | --- | --- | --- | --- | --- |
| **Drop Object** | N/A | :check_mark: | N/A | N/A | :check_mark: | N/A | N/A |
| Dropping a table impacts both the **source model** and the **Data Vault model**. However, **tables are never physically removed** from a Data Vault. Instead:<br>- All **ETL/ELT processes** related to the table will be **dropped** as they are no longer needed.
- Any **Business Vault objects** linked to the table will either be **dropped or regenerated**, depending on whether they can still exist within the updated model. |
| **Add Object** | :check_mark: | N/A | N/A | :check_mark: | N/A | N/A | N/A |
| Adding a table impacts both the **source model** and the **Data Vault model** (*and potentially the Business Vault model*). When a new table is introduced:<br>- **New Objects** are created across multiple layers.
- This includes **DDL scripts** and **initial (**`init`**) + incremental (**`incr`**) ETL processes**. |
| **Drop Descriptive Column** | :check_mark: | :check_mark: | N/A | :check_mark: | N/A | N/A | N/A |
| Dropping a column impacts the **source model** but **not** the **Data Vault model**, as columns are **never physically removed** from a Data Vault. Instead:<br>- Corresponding **Delta-Firewall views, Extraction tables, and Staging tables** are **regenerated** (*dropped and recreated*).
- **Incremental ETL processes** are also **regenerated** for both the **source** and the **Data Vault**.
- Any **impacted Business Views** will be **regenerated** accordingly. |
| **Add New Descriptive Column** | :check_mark: | :check_mark: | :check_mark: | :check_mark: | N/A | N/A | N/A |
| Adding a column impacts both the **source model** and the **Data Vault model**. As a result:<br>- **Data Vault Objects** are **altered** to include the new column.
- Related objects in the **Delta-Firewall, Extraction, and Staging layers** are **dropped and recreated**.
- **ETL processes** are **regenerated** across all layers.
- **Business Vault DDL/ETL** is also **regenerated** if impacted.<br>**Exception:**<br>If the object has a **CDC (Change Data Capture) type**, an **ALTER script** is generated for **INI, CDC, and STG objects** instead of a `CREATE TABLE` script. **This ensures that existing data is not lost**, allowing deletes to be properly tracked.<br>**CDC Types Affected:**<br>- **Full Load with Delete Management**
- **Full Load using Modification Date with Delete Management**
- **Full Load using Modification Sequence with Delete Management** |
| **Add (previously) Disabled Descriptive Column** | :check_mark: | :check_mark: | :check_mark: | :check_mark: | N/A | N/A | N/A |
| Enabling a **previously disabled column** impacts both the **source model** and the **Data Vault model**. As a result:<br>- **Data Vault objects** are **altered** to include the column.
- Related objects in the **Delta-Firewall, Extraction, and Staging layers** are **dropped and recreated**.
- **ETL processes** are **regenerated** across all layers.
- **Business Vault DDL/ETL** is also **regenerated** if impacted.<br>**Exception:**<br>If the object has a **CDC (Change Data Capture) type**, an **ALTER script** is generated for **INI, CDC, and STG objects** instead of a `CREATE TABLE` script. **This ensures that existing data is preserved**, allowing deletes to be properly tracked without data loss.<br>**CDC Types Affected:**<br>- **Full Load with Delete Management**
- **Full Load using Modification Date with Delete Management**
- **Full Load using Modification Sequence with Delete Management**<br>> ⚠️ **Attribute Ordering Limitation**
> ⚠️ 
> ⚠️ In the current implementation, attribute ordering is determined when the **source model is first read**. This means:
> ⚠️ 
> ⚠️ - When an attribute is **disabled and later re-enabled**, it **retains its original position** instead of being placed at the end, as would happen with a newly added attribute.
> ⚠️ - This behavior differs from how new attributes are ordered.
> ⚠️ 
> ⚠️ **Future Improvement:** This will be updated in a future release to ensure re-enabled attributes follow the same ordering rules as newly added attributes. |
| **Drop FK Relationship** | N/A | :check_mark: | N/A | :check_mark: | :check_mark: | :check_mark:<br>(Certain objects see below) | :cross_mark: |
| **Impact of Dropping a Foreign Key Relationship**<br>Dropping a **foreign key (FK) relationship** affects both the **source model** and the **Data Vault model**:<br>- If no other **foreign key** is attached to the attribute, the attribute is converted into a **descriptive attribute**.
- **Existing Data Vault links** are **not** dropped.
- Objects related to the **Delta-Firewall, Extraction, and Staging layers** are **dropped and recreated**.
- **Incremental (INCR) ETL** is **regenerated** for all affected layers.<br>**Migration Considerations**<br>- When a foreign key is dropped, the **child hub and satellite objects remain in the model**, but **their hash keys (hkeys) are not affected**. Because the hkeys stay the same, **no migration is needed** in these cases.
- However, for **many-to-many links, hierarchical links, same-as links, and non-historical links**, the foreign key is used to determine **business keys**.
  - In these cases, **removing the FK changes the structure of the object**, which **impacts hash key calculations** and **requires migration**.
- Because this migration **recalculates hash keys** and modifies the related satellites, it **must be executed before resuming incremental loads**.<br>> ⚠️ **Link Name Change Due to Relationship Reduction**
> ⚠️ 
> ⚠️ If multiple **foreign key relationships** exist between the same **source tables** and one is removed, leaving only **a single remaining relationship**, then:
> ⚠️ 
> ⚠️ - The **extra **`column_short_name` from one of the foreign key attributes will be **removed** from the **Link name**. |
| **Add FK Relationship** | :check_mark: | N/A | N/A | :check_mark: | N/A | :check_mark:<br>(Certain objects see below) | :cross_mark: |
| **Impact of Adding a Foreign Key Relationship**<br>Adding a **foreign key (FK) relationship** affects both the **source model** and the **Data Vault model**:<br>- **New link objects** are **added** to the Data Vault.
- Objects related to the **Delta-Firewall, Extraction, and Staging layers** are **dropped and recreated** to reflect the change.
- **All related ETL mappings** are **regenerated** across layers and dependent objects.
- **New ETL processes (**`init`** and **`incr`**)** are generated for the **newly created links**.<br>**Migration Considerations**<br>- When a foreign key is added, the **child hub and satellite objects remain unchanged**, and their **hash keys (hkeys) are not affected**. Because the hkeys stay the same, **no migration is needed** in these cases.
- However, for **many-to-many links, hierarchical links, same-as links, and non-historical links**, the foreign key is used to determine **business keys**.
  - In these cases, **introducing an FK changes the structure of the object**, which **impacts hash key calculations** and **requires migration**.
- Since this migration **recalculates hash keys** and modifies the related satellites, it **must be executed before resuming incremental loads**.<br>> ⚠️ **Link Name Change Due to Multiple Relationships**
> ⚠️ 
> ⚠️ If **multiple foreign key relationships** exist between the **same source tables**, then:
> ⚠️ 
> ⚠️ - An **extra **`column_short_name` from one of the foreign key attributes will be **added** to the **Link name** to maintain uniqueness. |
| **Alter Not-Character to Character Data Type** | :check_mark: | :check_mark: | :check_mark: | :check_mark: | N/A | N/A | N/A |
| **Impact of Altering a Data Type (Non-Character → Character)**<br>Altering a **data type** from a **non-character** (**numeric, integer, date, timestamp, etc.**) to a **character** (**varchar, char, etc.**) data type will have **less impact** than the reverse process. **Castings will be foreseen** to accommodate this change. This modification:<br>- **Does not impact** the **source model** or the **Data Vault model**.
- **Generates alter scripts** for the **Data Vault**.
- **Drops and recreates DDL** for the **temporary layers**.
- **Regenerates Incremental ETL** across all layers.<br>**Exception:**<br>If the impacted object has a **CDC (Change Data Capture) type**, an **ALTER script** is generated for **INI, CDC, and STG objects** instead of a `CREATE TABLE` script.<br>**CDC Types Affected:**<br>- **Full Load with Delete Management**
- **Full Load using Modification Date with Delete Management**
- **Full Load using Modification Sequence with Delete Management**<br>**Databricks-Specific Behavior:**<br>For **Databricks**, a **rename script** is generated instead of an ALTER script. This process includes:<br>- **Renaming the old objects** in the **INI, CDC, and STG layers** to a **versioned object**.
- **Creating a new object**.
- **Loading the new object using migration scripts** provided by VaultSpeed. |
| > ⚠️ **Important Notice:**
> ⚠️ 
> ⚠️ Conversion from `TIMESTAMP` to `VARCHAR` is not supported in Snowflake. |
| **Alter Character to Not-Character Data Type** | :check_mark: | :check_mark: | :check_mark: | :check_mark: | N/A | :check_mark: | :cross_mark: |
| **Impact of Altering a Data Type (Character → Non-Character)**<br>Altering a **data type** from a **character** (**varchar, char, etc.**) to a **non-character** (**numeric, integer, date, timestamp, etc.**) is **not easily castable** if the object already contains data. To accommodate this change:<br>- A **new table** (**Satellite, Reference Table, or Non-Historized Link**) is **created** with the **same name** after renaming the old satellite.
- This change **does not impact** the **source model** or the **Data Vault model** itself.
- **DDL for temporary layers** is **dropped and recreated**.
- **Incremental ETL processes** are **regenerated** across all layers.<br>**Migration Requirement:**<br>- **End-users must migrate** the data from the old object to the new one.
- During migration, **relevant attributes must be cast** to the new data type.
- **Ghost record values** need to be updated accordingly.<br>**Exception:**<br>If the impacted object has a **CDC (Change Data Capture) type**, a **rename script** is generated for **INI, CDC, and STG objects** instead of an ALTER script. This process includes:<br>- **Renaming the old object** to a **versioned object**.
- **Creating a new object** with the updated data type.
- **End-users must manually migrate** data to the new object.<br>**CDC Types Affected:**<br>- **Full Load with Delete Management**
- **Full Load using Modification Date with Delete Management**
- **Full Load using Modification Sequence with Delete Management** |
| > ⚠️ **Impact of Updating a Business Key’s Data Type**
> ⚠️ 
> ⚠️ When **altering the data type** of a **business key**, note that:
> ⚠️ 
> ⚠️ - **Exception records** will also be affected.
> ⚠️ - **Hash key calculations** will change as a result.
> ⚠️ - **Manual migration is required** to update old values in the current version of the tool. |
| **Increase Length / Precision / Scale of an Attribute** | :check_mark: | :check_mark: | :check_mark: | N/A | N/A | N/A | N/A |
| **Impact of Increasing Data Length, Precision, or Scale**<br>Increasing the **length, precision, or scale** of a data type will:<br>- **Trigger **`ALTER TABLE`** statements** for the impacted **Data Vault objects**.
- **Not impact** the **source model** or the **Data Vault model** itself.
- **Generate alter scripts** for the **Data Vault**.
- **Drop and recreate DDL** for the **temporary layers**.<br>**Exception:**<br>If the impacted object has a **CDC (Change Data Capture) type**, an **ALTER script** is generated for **INI, CDC, and STG objects** instead of a `CREATE TABLE` script.<br>**CDC Types Affected:**<br>- **Full Load with Delete Management**
- **Full Load using Modification Date with Delete Management**
- **Full Load using Modification Sequence with Delete Management** |
| > ⚠️ **Snowflake Limitation**
> ⚠️ 
> ⚠️ Numeric **scale changes** are **not supported** in **Snowflake**. |
| **Decrease Length / Precision / Scale of an Attribute** | N/A | N/A | N/A | N/A | N/A | N/A | N/A |
| Decreasing the **length, precision, or scale** of a data type **is not triggered**, as this change could **cause failures** in already loaded data. |
| **New Source Detected** | :check_mark: | N/A | N/A | :check_mark: | N/A | N/A | N/A |
| Adding a **source** impacts both the **source model** and the **Data Vault model**. As a result:<br>- **New objects** are created across different layers.
- This includes **DDL**, as well as **initial (**`Init`**) and incremental (**`Incr`**) ETL processes**. |
| **Source Removed** | N/A | :check_mark: | N/A | N/A | :check_mark: | N/A | N/A |
| Dropping a **source** impacts both the **source model** and the **Data Vault model**. However, **tables are never physically removed** from a Data Vault. Instead:<br>- **All ETL processes** associated with the source are **dropped**, as they are no longer needed. |
| **Source Schema Changed** | N/A | :check_mark: | N/A | N/A | :check_mark: | :check_mark: | :cross_mark: |
| Changing **schemas** in the **source model** will:<br>- **Trigger new DDL and ETL** generation for objects within the schema.
- **Not automatically update the schema name** in VaultSpeed. |

### Data Vault Changes

#### Satellite Splitting

| **Change** | **Create DDL** | **Drop DDL** | **Alter DDL** | **New ETL** | **Drop ETL** | **Data Migration Needed** | **Data Migration Automatically Generated** |
| --- | --- | --- | --- | --- | --- | --- | --- |
| **Non-Splitted Satellite to a Splitted Satellite** | :check_mark: | N/A | N/A | :check_mark: | N/A | :check_mark: | :check_mark: |
| Splitting a **non-splitted satellite** will:<br>- **Generate DDL** for the **new satellite tables**.
- **Create new Incremental ETL** to load the new splits.
- Keep the **old satellite available** in the database.<br>**Migration:**<br>- **ETL will be provided** to **recalculate hash diffs** for the new splits.
- **Data will be moved** accordingly. |
| **Splitted Satellite to a Non-Splitted Satellite** | :check_mark: | N/A | N/A | :check_mark: | N/A | :check_mark: | :cross_mark: |
| Removing **all splits** from a **satellite** will:<br>- **Generate DDL** for the **combined satellite**.
- **Create new ETL** to load the **non-splitted satellite**.
- Keep the **old splits available** in the database.
- **Migration scripts are not yet available** but will be introduced in a future update.<br>**Migration:**<br>- A **history recalculation** using **hash diffs** is required for the non-split satellite.
- This migration **is not yet generated** by the tool. |
| **Add Splits** | :check_mark: | N/A | N/A | :check_mark: | N/A | :check_mark: | :cross_mark: |
| Adding **splits** to an **already split satellite** will:<br>- **Generate DDL** for the **new satellite tables**.
- **Create new ETL** to load the **additional splits**.
- **Keep migration scripts unavailable for now**, but they will be introduced in a future update.<br>**Migration:**<br>- A **history recalculation** using **hash diffs** is required for the new splits.
- This migration **is not yet generated** by the tool. |
| **Remove Splits** | N/A | N/A | N/A | N/A | :check_mark: | :check_mark: | :cross_mark: |
| **Impact of Removing Splits from an Already Split Satellite**<br>Removing **splits** from an **already split satellite** will:<br>- **Have no impact on DDL**, provided the columns **are not moved** to another satellite.
- **Apply the "Add Column" change** from **[Source Changes](https://vaultspeed.atlassian.net/wiki/spaces/PPD/pages/edit-v2/3128856473#Source-Changes)** if columns **are moved**.
- **Drop the ETL** for loading the removed split.
- Keep the **old splits available** in the database.<br>**Migration:**<br>- A **history recalculation** using **hash diffs** is required if attributes were moved.
- This migration **is not yet generated** by the tool. |
| **Splitted Attributes Re-arranged** | N/A | N/A | N/A | N/A | N/A | :check_mark: | :cross_mark: |
| If **attributes are moved** between splits, the changes **"Add Column"** and **"Drop Column"** from **[Source Changes](https://vaultspeed.atlassian.net/wiki/spaces/PPD/pages/edit-v2/3128856473#Source-Changes)** will be applied.<br>**Migration:**<br>- A **history recalculation** using **hash diffs** is required for the updated splits.
- This migration **is not yet generated** by the tool. |

 

#### Single-Multi Primary Hub

| **Change** | **Create DDL** | **Drop DDL** | **Alter DDL** | **New ETL** | **Drop ETL** | **Data Migration Needed** | **Data Migration Automatically Generated** |
| --- | --- | --- | --- | --- | --- | --- | --- |
| **Single to Multi Primary Hub** | :check_mark: | N/A | :check_mark: | :check_mark: | N/A | :check_mark: | :check_mark: |
| **Impact of Changing a Hub from Single to Multi-Primary**<br>Changing a **hub** from **single** to **multi-primary** will:<br>- **Add the source business key** to the **hub** and include it in the **hash keys** of hubs, links, and satellites.
- **Modify the hub and staging tables** to include this new attribute.
- **Generate **`ALTER TABLE`** DDL** for the hub.
- **Update incremental ETL processes** to load the object accordingly.
- **Regenerate all DDL and ETL** for the **temporary layers**.<br>**Migration:**<br>- **Migration mappings** will be provided to **recalculate hash keys** for all impacted **hub, link, and satellite objects**.<br>**Exception:**<br>If the impacted object has a **CDC (Change Data Capture) type**, a **migration script** is generated for **STG objects**.<br>**CDC Types Affected:**<br>- **Full Load with Delete Management**
- **Full Load using Modification Date with Delete Management**
- **Full Load using Modification Sequence with Delete Management**<br>> ⚠️ #### **Spark SQL (Cloudera) Limitation**
> ⚠️ 
> ⚠️ Hash key recalculation **is not supported** for **Spark SQL (Cloudera)**. |
| **Multi to Single Primary Hub** | :check_mark: | N/A | :check_mark: | :check_mark: | N/A | :check_mark: | :check_mark: |
| **Impact of Changing a Hub from Multi to Single Primary**<br>Changing a **hub** from **multi-primary** to **single-primary** will:<br>- **Remove the source business key** from the **hub** and from the **hash keys** of hubs, links, and satellites.
- **Convert the source business key to a nullable attribute** (since Data Vault attributes cannot be dropped).
- **Generate **`ALTER TABLE`** DDL** for the hub.
- **Update ETL processes** to load the object accordingly.
- **Regenerate all DDL and ETL** for the **temporary layers**.<br>**Migration:**<br>- **Migration mappings** will be provided to **recalculate hash keys** for all impacted **hub, link, and satellite objects**.<br>**Exception:**<br>If the impacted object has a **CDC (Change Data Capture) type**, a **migration script** is generated for **STG objects**.<br>**CDC Types Affected:**<br>- **Full Load with Delete Management**
- **Full Load using Modification Date with Delete Management**
- **Full Load using Modification Sequence with Delete Management**<br>> ⚠️ #### **Manual Unique Key Creation & Spark SQL Limitation**
> ⚠️ 
> ⚠️ - **The unique key for the hub must be manually created** after the **delta deployment**. *(This process will be automated in a future update.)*
> ⚠️ - **Hash key recalculation is not supported** for **Spark SQL (Cloudera)**. |

#### Grouping - Ungrouping

| **Change** | **Create DDL** | **Drop DDL** | **Alter DDL** | **New ETL** | **Drop ETL** | **Data Migration Needed** | **Data Migration Automatically Generated** |
| --- | --- | --- | --- | --- | --- | --- | --- |
| **Existing Ungrouped to Grouped Hubs** | :check_mark: | N/A | N/A | :check_mark: | :check_mark: | :check_mark: | :cross_mark: |
| When **previously ungrouped hubs** are later **grouped**, they should be **migrated** to the **new object** from the different sources. Additionally:<br>- **Impacted links** must also be migrated.
- **Satellites on links** should be migrated accordingly.<br>> ⚠️ Currently, **regrouping is blocked** in the tool if the object being grouped was previously **ungrouped** and meets either of the following conditions:
> ⚠️ 
> ⚠️ - **It has references to other objects.**
> ⚠️ - **It is referenced by other objects.**
> ⚠️ 
> ⚠️ This restriction exists because regrouping would **change the names of Link objects**, which the tool **doesn't yet support**. |
| **New Object to Grouped Hubs** | :check_mark: | N/A | N/A | :check_mark: | :check_mark: | N/A | N/A |
| **Adding New Hubs to a Group**  
When **new hubs are added to an existing group**, the tool generates all necessary **DDL and ETL** processes required to load the new object (refer to **New Source Object**). |
| **Grouped to Ungrouped Hubs** | :cross_mark: | :cross_mark: | :cross_mark: | :cross_mark: | :cross_mark: | :cross_mark: | :cross_mark: |
| This action is currently **blocked in the tool** if the object was previously **grouped**, as this change significantly impacts the model and the tool **cannot yet generate the required changes**. |
| **Non-Intra-Source Grouping to Intra-Source Grouping Hubs** | N/A | N/A | :check_mark: | :check_mark: | N/A | :check_mark: | :check_mark:/:cross_mark:<br>Exceptions can be found in the description below. |
| **Impact of Adding a Table to a Hub Group (Multi-Primary)**<br>Adding a table to a hub group containing a table from the same source (multi-primary scenario) will:<br>- Modify the source business key to include both the source name and the short name of the table. The new format will be: `src_name_in_bk || table_short_name`.
- Generate ALTER TABLE DDL statements for the hub to accommodate this change.
- Update incremental ETL processes to load the affected objects accordingly.
- Regenerate all DDL and ETL processes for the temporary layers to reflect the updated business key calculation.<br>**Migration:**<br>Migration mappings will be provided to recalculate hash keys for all impacted hubs, links, and satellite objects.<br>> ⚠️ **Important Considerations:**
> ⚠️ 
> ⚠️ - **Exception for Migration Mappings:**  
> ⚠️ Migration mappings are only provided if the object causing intra-source grouping is **new**, not an existing ungrouped object. Otherwise, the data migration must be performed manually in the current tool implementation. This includes moving data from the old ungrouped object to the hub group and associated satellites (DDL provided by the tool). After migration, hash keys must be recalculated based on the new `src_name_in_bk || table_short_name` structure for all impacted hubs and related objects.
> ⚠️ - **Spark SQL Limitation:**  
> ⚠️ Hash key recalculation is **not supported** for Spark SQL (Cloudera).
> ⚠️ - **Current Tool Restriction:**  
> ⚠️ The tool currently blocks regrouping if the object was previously ungrouped, as this would require renaming Link objects, which isn't supported yet. |
| **Intra-Source Grouping to Non-Intra-Source Grouping Hubs** | N/A | N/A | :check_mark: | :check_mark: | N/A | :check_mark: | :check_mark: |
| **Impact of Removing a Table from a Hub Group**  
Removing a table from a hub group, resulting in no tables from the same source remaining within the group, will:<br>- Update the source business key to include only the source name: `src_name_in_bk`.
- Regenerate all DDL and ETL processes for the temporary layers to reflect this updated calculation.<br>**Migration:**  
Migration mappings will be provided to recalculate hash keys for all impacted hub, link, and satellite objects.<br>> ⚠️ **Important Considerations:**
> ⚠️ 
> ⚠️ - **Regrouping Limitation:**  
> ⚠️ Moving the object is **only possible** when transferring it to another group. It is **not possible** to make it ungrouped.
> ⚠️ - **Spark SQL Limitation:**  
> ⚠️ Hash key recalculation is **not supported** for Spark SQL (Cloudera). |
| **Automatic Ungrouping Object Based Links** | :check_mark: | N/A | N/A | :check_mark: | N/A | :check_mark: | :cross_mark: |
| **Impact of Changes to Object-Based Links**<br>When an Object-Based Link in a new Data Vault Release no longer points to the same hubs due to a newly introduced relationship, the tool will:<br>- Automatically ungroup the affected Object-Based Links.
- Issue a warning requiring the renaming of at least one of the Object-Based Links.
- Automatically apply the new name to Satellites on the renamed Object-Based Link.
- Potentially rename Satellites on Object-Based Links that retain their original name if no other Object-Based Links remain grouped within the new configuration.<br>**Migration:**<br>- Migration mappings will **not** be provided. If historical data preservation is required, customers must manually migrate the data based on the logic detailed in the new mappings for hash key recalculations.
- The tool will ensure all necessary DDL and ETL processes are generated to support normal data loading workflows. |

#### Business Key

| **Change** | **Create DDL** | **Drop DDL** | **Alter DDL** | **New ETL** | **Drop ETL** | **Data Migration Needed** | **Data Migration Automatically Generated** |
| --- | --- | --- | --- | --- | --- | --- | --- |
| **Non-Concatenated to Concatenated Business Key** | N/A | N/A | :check_mark: | :check_mark: | N/A | :check_mark: | :check_mark:/:cross_mark: |
| **Impact of Changing a Non-Concatenated Business Key to a Concatenated Business Key**<br>Changing from a non-concatenated to a concatenated business key will impact hub and satellite objects in the Data Vault as follows:<br>- If business keys are not already stored in the satellite, they will be added due to concatenation.
- ALTER scripts will be generated to:
  - Add the concatenated business key to the hub.
  - Add the business key to the satellite if not already present.
- Business keys in the hub will be altered to become nullable.
- DDL and ETL scripts will be generated for both temporary layers and the affected hub and satellite.<br>**Migration:**<br>- Migration mappings will be provided to migrate data from non-concatenated to concatenated business keys in the hub.
- Satellite migration is not yet automated and must be performed manually if desired.<br>**Exception:**<br>If the impacted object uses one of the following CDC (Change Data Capture) types, an ALTER script will also be generated for the STG objects:<br>- Full Load with Delete Management
- Full Load using Modification Date with Delete Management
- Full Load using Modification Sequence with Delete Management<br>> ⚠️ **Important Notice:**
> ⚠️ 
> ⚠️ The unique key for the hub must be manually created after the delta deployment. This process will be automated in a future update. |
| **Concatenated to Non-Concatenated Business Key** | N/A | N/A | :check_mark: | :check_mark: | N/A | :check_mark: | :check_mark: |
| **Impact of Changing a Concatenated Business Key to a Non-Concatenated Business Key**<br>Changing from a concatenated to a non-concatenated business key affects hub and satellite objects in the Data Vault as follows:<br>- ALTER scripts will be generated to add the business keys to the hub.
- Business keys in the hub will be altered to become nullable.
- DDL and ETL scripts will be generated for both temporary layers and affected hubs and satellites.<br>**Migration:**<br>Migration mappings will be provided to migrate data from concatenated to non-concatenated business keys.<br>**Exception:**<br>If the impacted object uses one of the following CDC (Change Data Capture) types, an ALTER script will also be generated for the STG objects:<br>- Full Load with Delete Management
- Full Load using Modification Date with Delete Management
- Full Load using Modification Sequence with Delete Management<br>> ⚠️ **Important Notices:**
> ⚠️ 
> ⚠️ - The unique key for the hub must be created manually after the delta deployment. This will be automated in a future update.
> ⚠️ - Records inserted into the HUB by setting the `EARLY_ARRIVING_FACTS = Y` parameter will not be automatically migrated. These records require manual migration. |
| **Added Business Key Attribute** | N/A | N/A | :check_mark: | :check_mark: | N/A | :check_mark: | :cross_mark: |
| **Impact of Adding a Business Key**<br>Adding a business key affects the business keys and hash keys of hubs, satellites, and links in the Data Vault. As a result:<br>- DDL and ETL scripts will be generated for both temporary layers and affected hubs and satellites.<br>**Migration:**<br>Migration ETL is not generated by VaultSpeed due to the entirely new key structure. All hash keys for the hub and related objects must therefore be recalculated manually.<br>**Exception:**<br>If the impacted object uses one of the following CDC (Change Data Capture) types, an ALTER script will be generated for the STG objects:<br>- Full Load with Delete Management
- Full Load using Modification Date with Delete Management
- Full Load using Modification Sequence with Delete Management |
| **Dropped Business Key Attribute** | N/A | N/A | N/A | :check_mark: | N/A | :check_mark: | :cross_mark: |
| **Impact of Dropping a Business Key**<br>Dropping a business key affects the business keys and hash keys of hubs, satellites, and links in the Data Vault. Consequently:<br>- DDL and ETL scripts will be generated for both temporary layers and the impacted hubs and satellites.<br>**Migration:**<br>Migration ETL is not generated by VaultSpeed since the new key structure is entirely different. Therefore, manual recalculation of hash keys is required for all affected hubs and related objects.<br>> 📝 **Note:**
> 📝 
> 📝 The unique key for the hub must be created manually after the delta deployment. This step will be automated in an upcoming release. |
| > ⚠️ #### **Change in Concatenated Business Keys Order**
> ⚠️ 
> ⚠️ **Warning:** VaultSpeed currently does **not support changes to the order of concatenated business keys**. Altering the sequence of business keys in your data model can lead to unexpected behavior during delta generation, including incorrect data mapping, hash key collisions, and inconsistencies in data lineage.
> ⚠️ 
> ⚠️ **Impact on Delta Generation:**
> ⚠️ 
> ⚠️ Rearranging the order of concatenated business keys can disrupt the integrity of the hash key calculation, crucial for accurate delta generation. VaultSpeed relies on this calculation to correctly identify and process changes to your data. When the business key order changes, VaultSpeed may misidentify records, resulting in data discrepancies and inaccurate deltas.
> ⚠️ 
> ⚠️ **Considerations:**
> ⚠️ 
> ⚠️ - To ensure reliability and consistency, it is strongly recommended to avoid changing the order of concatenated business keys.
> ⚠️ - If changes are necessary, manual adjustment of the hash key calculation logic is required.
> ⚠️ - Additionally, implementing custom migration scripts is crucial, particularly for data that has already been loaded. Developing these scripts ensures a smooth transition and accuracy of your data mappings.
> ⚠️ - Thorough testing of custom migration scripts is strongly advised before implementation to prevent any data integrity issues. |