> For the complete documentation index, see [llms.txt](https://documentation.astera.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://documentation.astera.com/workflows/database-operations/validate-data-model.md).

# Validate Data Model

### Overview

The Validate Data Model workflow task in Astera allows users to verify the integrity and correctness of data and metadata  within a data model.  

The task can be used in the following scenarios: 

1. **Data Model Structure Verification:** Validates that the data model structure is correctly defined and consistent. 
2. **Referential Integrity Validation:** Checks for orphan records where child records exist without corresponding parent records in related tables. 
3. **Dimensional Model Verification:** For dimensional models (data warehouses), performs specialized validations on dimension tables including surrogate keys, business keys, and slowly changing dimension (SCD) attributes. 

This document will go over how we can use Validate Data Model in Astera. 

### Use Case 

To get started, drag-and-drop the Validate Data Model object onto the designer and configure the object by right-clicking on the object's header and selecting Properties from the context menu. 

<figure><img src="/files/U6u9NZfHY9r22hNyamB1" alt=""><figcaption><p>01-data-model-validation-properties-window</p></figcaption></figure>

### Source Configuration&#x20;

Here, let's start configuring our Source settings:&#x20;

* **Source Database Connection:** Select the database connection that contains the data you want to validate from the drop-down. &#x20;

{% hint style="info" %}
Note: You must add a Database Connection of your source database in your project as a shared connection. To learn how to add a database connection to a project, click [here](https://app.gitbook.com/o/BkMZLF62xjXwwhHrvAfx/s/zEifS4h8yurLAAwiGNX2/miscellaneous/shared-actions).&#x20;
{% endhint %}

* **Source Data Model Path:** Specify the path to the data model file (.mdl) that defines the structure of your data. This is required for the validation task to understand entity relationships.&#x20;
* **Data Model View:** Optionally specify a particular view within the data model to validate. If left empty, the main view will be used.&#x20;

### Verification Options&#x20;

Here, we can configure the core validation settings:&#x20;

* **Verify Data Model:** When enabled (default: checked), this option validates the data model structure itself, checking for errors and warnings in the model definition as well as the metadata configuration.&#x20;
* **Verify Referential Integrity:** When enabled (default: checked), this option checks for referential integrity violations across all relationships defined in the data model. It identifies "orphan" records where child entities contain foreign key values that don't exist in the parent entity.&#x20;
* **Message Level:** Controls the verbosity of validation messages in the output:&#x20;
  1. **Failure Only (default):** Only reports validation failures and errors. Use this option for cleaner output when you only need to know about problems.&#x20;
  2. **All:** Reports all validation checks including successful validations. Use this option when you want complete visibility into what the validation task is checking.&#x20;
* **Validation Log File Path:** Optionally specify a file path where validation results will be written. This creates a log file containing all validation messages, which is useful for auditing and record-keeping purposes.&#x20;

### Dimensional Model Verification Options&#x20;

For data models that contain dimension tables (used in data warehousing), additional validation checks are performed:&#x20;

* **Min Effective Date:** Specifies the minimum valid effective date for SCD Type 2 dimension records (default: January 1, 1900). Records with effective dates before this value may be flagged during validation.&#x20;
* **Max Expiry Date:** Specifies the maximum valid expiry date for SCD Type 2 dimension records (default: January 1, 2100). Records with expiry dates beyond this value may be flagged during validation.&#x20;

### Dimensional Model Validations&#x20;

When validating dimension entities, the following checks are performed:&#x20;

**Active Row Flag Validation:** Ensures that for each business key, there is only one active record. Note that this works for all types of record identifiers. &#x20;

**Duplicate Surrogate Key Detection:** Identifies duplicate values in surrogate key columns that should be unique.&#x20;

**Effective/Expiration Date Validation:**&#x20;

* Validates that effective dates are not greater than expiration dates&#x20;
* Checks for gaps and overlaps in date ranges for the same business key&#x20;
* Identifies multiple null values for effective or expiry dates within the same business key&#x20;

**Business Key Uniqueness:** When no history attributes are present, validates that business keys are unique.&#x20;

**Placeholder Record Validation:** Ensures only one placeholder dimension record exists per business key.&#x20;

**Default Dimension Record Check:** Verifies that default dimension records exist when surrogate key defaults are specified.&#x20;

### Output&#x20;

The Validate Data Model task produces detailed trace output indicating:&#x20;

* Validation start and completion messages&#x20;
* For each relationship checked, whether orphan children were found&#x20;
* For each dimension entity, detailed validation results for all applicable checks&#x20;
* Any errors encountered during validation&#x20;

If a **Validation Log File Path** is specified, all validation messages are also written to the specified file for later review.&#x20;


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://documentation.astera.com/workflows/database-operations/validate-data-model.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.