# Verifying a Dimensional Model

The process of verifying a dimensional model in Astera Data Stack is the same as that for a general data model. To learn more about verifying a general data model, click [here](https://documentation.astera.com/data-model/data-models/verifying-a-data-model).

In this article, we’ll cover a few common errors and warnings that you may encounter while verifying a dimensional model.

### Common Verification Errors and Warnings

#### Case 1: Insert Only

In this case, we have a data model that contains one dimension entity called *SCD\_Customer*.

![01-verification-dimensional-model-case1](https://content.gitbook.com/content/zEifS4h8yurLAAwiGNX2/blobs/0WsRynE35Ny2bYK7srqu/01-verification-dimensional-model-case1.PNG)

Here is the layout of this entity.

![02-case1-dimension-entity-layout](https://content.gitbook.com/content/zEifS4h8yurLAAwiGNX2/blobs/6WIdcl2xZoafmfEB6JAx/02-case1-dimension-entity-layout.PNG)

You’ll notice that the *Dimension Role* for all of the fields is *Insert Only*. However, you need to assign a business key, SCD types, and other SCD-related roles to certain fields in a dimension entity.

Upon verifying for read and write deployment, the *Verify* window will display the following errors:

![03-case1-dimensional-verification-errors](https://content.gitbook.com/content/zEifS4h8yurLAAwiGNX2/blobs/Oy7KGuosuHE2H2rXfwQc/03-case1-dimensional-verification-errors.PNG)

The first error indicates that the entity must contain at least one SCD element.

The second error indicates that the entity must contain a business key.

**Solution**: Go to the *Layout Builder* screen and assign appropriate *Dimension Roles* to certain fields. Here is a look at the entity layout after we have done so.

![04-case1-dimension-entity-roles](https://content.gitbook.com/content/zEifS4h8yurLAAwiGNX2/blobs/nohFay4QBHjrXjJOQH6y/04-case1-dimension-entity-roles-1616595944062.PNG)

As you can see, the entity now contains a business key and three SCD1 elements.

Once you’ve defined the dimension roles, click *OK*. The model can now be verified successfully.

#### Case 2: Record Identifiers

Here, we have a modified version of the data model used in case 1.

![05-verification-dimensional-model-case2](https://content.gitbook.com/content/zEifS4h8yurLAAwiGNX2/blobs/RUe64mLT81OeTR9BRiOg/05-verification-dimensional-model-case2.PNG)

In this case, the layout of the *SCD\_Customer* entity contains an SCD2 element but does not contain any record identifiers.

![06-case2-dimension-entity-layout](https://content.gitbook.com/content/zEifS4h8yurLAAwiGNX2/blobs/80F45uJheTN1DTzbzaYL/06-case2-dimension-entity-layout.PNG)

Upon verifying for read and write deployment, the *Verify* window will display the following error:

![07-case2-dimension-verification-error](https://content.gitbook.com/content/zEifS4h8yurLAAwiGNX2/blobs/ph48FGWvOT9jMrzhzeTs/07-case2-dimension-verification-error.PNG)

The error states that the *SCD\_Customer* entity contains a SCD2 or SCD6 element but does not have any active row identifiers.

**Solution**: Go to the *Layout Builder* screen and assign a record identifier field. In this case, the entity layout already contains a field that denotes the *Version Number* (*VersionNo*). We’ll use the *Dimension Role* dropdown menu to assign the *Version Number* role to the field named *VersionNo*.

![08-case2-dimension-role-identifier](https://content.gitbook.com/content/zEifS4h8yurLAAwiGNX2/blobs/SMQMoiL3lrrSYUsywqhH/08-case2-dimension-role-identifier.PNG)

The model can now be verified successfully.

#### Case 3: Record Identifier Not Needed

Here, we have another modified version of the model in cases 1 and 2.

![09-verification-dimensional-model-case3](https://content.gitbook.com/content/zEifS4h8yurLAAwiGNX2/blobs/UxJuxobwTI3RhT09nS1a/09-verification-dimensional-model-case3.PNG)

The layout of the *SCD\_Customer* entity contains a business key, an SCD1 element, and an *Effective Date* record identifier.

![10-case2-dimension-entity-layout](https://content.gitbook.com/content/zEifS4h8yurLAAwiGNX2/blobs/hcv4bQaujR9e1RZSsjpb/10-case2-dimension-entity-layout.PNG)

However, a record identifier is only needed in the layout when it contains at least one SCD2 or SCD6 element.

Upon verifying for read and write deployment, the *Verify* window will display the following warning:

![11-case2-dimension-verification-warning](https://content.gitbook.com/content/zEifS4h8yurLAAwiGNX2/blobs/IwdM6w1fkS6byFnR36kW/11-case2-dimension-verification-warning.PNG)

{% hint style="info" %}
**Note**: A warning is not the same as an error. When a model contains one or more warnings, it can still be deployed or forward engineered. However, it is a good practice to remove warnings before you move forward.
{% endhint %}

This warning indicates that the layout contains an effective or expiration date which serves no purpose since it does not contain an SCD2 or SCD6 field.

**Solution**: Go to the *Layout Builder* screen and delete the *EffectiveDate* field by right-clicking on the field and selecting *Delete* from the context menu. However, if you wish to add an SCD2 or SCD6 element to the layout, do not delete the field.

![12-case3-delete-field](https://content.gitbook.com/content/zEifS4h8yurLAAwiGNX2/blobs/TWHw1Sr7LL2Vj1ikEw67/12-case3-delete-field.PNG)

The model can now be verified successfully.

This concludes our discussion on verifying a dimensional model.
