Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
The Build Dimensional Model feature provides an easier and quicker way to build a dimensional model by selecting and configuring fact and dimension entities.
Through this option, the process of designing a dimensional model architecture is significantly automated, streamlining the overall development experience. The feature intelligently handles various aspects of the model creation such as configuring fact and dimension entities, establishing relationships between them, automatically identifying primary and foreign keys, assigning surrogate keys and row identifiers, and more. By eliminating the need for manual intervention, this option significantly reduces the time and effort required for dimensional modelling.
Let’s see how we can build a dimensional model using the Build Dimensional Model feature of Astera Data Warehouse Builder.
To build a dimensional model, first create a new data warehousing project or open an existing data warehousing project, and Reverse Engineer a database.
Let’s consider the following source model, using which we need to derive a star schema architecture.
Using the Build Dimensional Model option, you can automate the creation of the star schema from the source model instead of manually configuring the fact and dimension entities and other aspects of the dimensional model.
Go to Main Menu > Data Model and select the Build Dimensional Model option.
The Build Dimensional Model window will open.
Under the Select Fact(s) and Dimension(s) section, select the entities you want to include in your dimensional model. When an entity is selected, it is marked as a Dimension by default. If the entity that you have selected is a Fact entity, check the Fact checkbox next to the entity name.
The Auto Detect option automatically sets an entity as a fact, dimension or a general entity based on its relationships with other entities. The entity with foreign keys referring to other entities is chosen as the fact entity.
You can configure facts and dimensions using the options provided under the Facts/Dimensions Configuration section.
Add Row Identifier: A row identifier helps identifying the current and previous records while dealing with SCD2 or SCD6 elements. You can choose one of the following row identifiers from the Add Row Identifier dropdown.
Current Record Designator: stores the Active Value for the current record, and the Inactive Value for the previous records.
Current Record Designator: stores the Active Value for the current record, and the Inactive Value for the previous records.
Version Number: stores the version number of the records.
Effective Date: stores the effective date of the records.
Expiry Date: stores the expiration date of the records.
Effective Expiration Date: stores the effective and expiration date of the records.
None: Choose this option if you do not want to add a row identifier. However, a row identifier is needed for SCD2 and SCD6 elements.
Child Fact Entity Options: If you have more than one entity selected as a fact entity, you can choose from one of the following options for the child fact entity.
Merge into Parent Fact: merges the child fact entity with the parent fact entity.
Treat as Separate Fact: treats the child fact entity as a separate entity, without merging it with the parent fact entity. The dimensions are shared by all facts.
None: does not treat the child fact entity as a separate fact. The dimensions are not shared by the child fact.
Add Date/ Time Relationships: If you want to add a date or time dimension to your dimensional model, you can choose one of the following options.
Date Relationships: adds a Date Dimension and its relationships with the fact entities.
Time Relationships: adds a Time Dimension and its relationships with the fact entities.
Both Date & Time Dimensions: adds both Date and Time Dimensions and their relationships with the fact entities.
None: does not add a Date or Time dimension.
Add Surrogate Key in Fact Entities: This option adds a surrogate key for all fact entities, if checked.
Add Surrogate Key in Dimension Entities: This option adds a surrogate key for all dimension entities, if checked.
Extract only Numeric Fields for Fact Entities: This option drops all the non-numeric attributes of the fact entities ,if checked.
After you have made your selections, click OK. A dimensional model, based on your selections and configuration, will be built.
USE CASE:
Let’s build a dimensional model with the following selections.
Mark the Cities, Suppliers, Customers and StockItems entities as Dimensions.
Mark the Invoice and InvoiceLines entities as Facts.
Select Effective Expiration Range as the row identifier.
Select Merge into Parent Fact under the Child Fact Entity Options. The child fact entity (InvoiceLines) will be merged into the parent fact entity (Invoice).
Select Both Date and Time Dimensions under the Add Date/Time Relationships option.
Check the checkboxes for adding surrogate keys to Fact and Dimension entities.
Uncheck the Extract only Numeric Fields for Fact Entities checkbox to include all numeric and non-numeric attributes of the fact entity.
Click OK. The following Dimensional Model will be built with all the configurations selected above.
This provides a starting point for the dimensional model. You can make any desired changes to the dimensional model, for example, adding SCD type definitions, prior to forward engineering it.
This concludes our discussion on how to build a dimensional model using the Build Dimensional Model option.
In this article, we will discuss how we can convert a data model to a dimensional model in Astera Data Stack.
The first step is to Reverse Engineer a database. To learn more about Reverse Engineering in Astera Data Stack, click here.
Once a database has been reversed engineered, the entities on the designer are set to be general entities by default. To convert this data model into a dimensional model, these entities need to be changed, according to their attributes, into facts and dimensions.
There are two ways to change entity types in Astera Data Stack:
Right click on the entity you want to change, and hover over the Entity Type option. You will get the option to choose an entity type between General, Fact and Dimension. Select the type that you want to assign.
Open Properties of the entity and select the Entity Type on the Entity Properties window. Now let’s discuss this in detail:
Right click on the entity you want to assign as a Fact. An Entity Properties window screen will open. The following elements are available on this screen.
Table Name
Schema
Entity Type
Definition
2. Currently, the entity type of the table is set to General. Click on the Entity Type drop-down and select Fact to convert this General entity to a Fact entity.
On the next screen, there is a Layout Builder, where we will specify the keys for the dimensional model. For the model to work properly, there should be a Primary Key, and Foreign Key specified in the entity.
There are other columns like Column Type, Data Type, Db Type, Fact Role, etc. where you can make modifications according to the requirements of the dimensional model.
To learn more about fact roles, click here.
The next screen is for Data Model Entity Indexes. Once you have set the properties for the fact entity, click OK.
To learn more about Entity Indexes, click here.
Once a Fact table has been specified, all the other tables in the model would be dimension tables, in this case only. To change an entity to a Dimension, follow steps 3 and 4. In the Entity Type drop-down, select Dimension. Click Next.
On the Layout Builder screen, you can make modifications to the table. Specify the Dimension Role (Business Key, Surrogate Key and SCD Types) and the Keys in the dimension table.
The Dimension Role options include options for Business Key, Surrogate Key, SCD Types and Insert Only.
To learn more about Dimension Roles, click here.
The next screen is for Data Model Entity Indexes. Once you have set the properties for the fact entity, click OK.
To learn more about Entity Indexes, click here.
Follow steps 7 to 9 for all the other entity objects in the model to transform them into dimension entities.
Once Entity Types have been set for all the entities, your dimensional model would be ready to use.
Note: In this case, the entity names Sale is the fact entity, and the rest are dimension entities.
This concludes our discussion on how to convert a data model to a dimensional model in Astera Data Stack.
In a dimensional model, a fact entity represents a database table that contains quantitative information regarding a business process, such as measures and metrics. It is the central entity of a star schema and is surrounded by related dimension entities. This implies that the primary key of each dimension table is also part of the fact table as a foreign key.
Let’s assume that we have a sample dimensional model that looks like this:
The Sale entity in this model represents the fact table and is surrounded by numerous dimension entities in the star schema.
In the next sections of this article, we’ll examine the layout of the Sale entity to learn how you can configure facts in Astera Data Stack.
To open the properties of the fact entity, right-click on it and select Properties from the context menu.
A configuration window will appear. This window provides the same options as it does for a general entity, the only addition being the Fact Role column on the Layout Builder screen. To learn more about the general entity properties, click here.
On the first screen, you can view and edit some general information regarding the table, including its name, schema, and type.
Click Next to proceed to the Layout Builder screen.
In the layout of this fact table, you’ll notice quite a few foreign keys, such as City_Key, Customer_Key, etc.
Each of these foreign keys represents a relationship between this fact table and one of the dimension tables. For example, City_Key represents the primary key of the City table, Customer_Key represents the primary key of the Customer table, and so on.
The Fact Role column in the layout builder provides a dropdown menu for you to assign the role of Transaction Date Key to one of the fields.
Transaction Date Key: A key date field that is coming from the OLTP system.
Note: Assigning the Transaction Date Key fact role to more than one field in a fact entity will cause a verification error in the model.
In this case, we’ve assigned the role to the Invoice_Date_Key field.
Once you’ve assigned the Transaction Date Key role to a field, click OK.
This concludes our discussion on fact entities in Astera Data Stack.
In a dimensional data model, a dimension entity represents a table that contains descriptive information regarding a fact. Each attribute in a dimension table provides context to the numeric information present in the fact table. In a star schema, each dimension entity is related to the fact entity.
Let’s assume that we have a sample dimensional model that looks like this:
The Customer, City, Stock_Item, and Employee entities in this model represent dimension tables. The Sale entity in the center represents the fact table.
In this article, we will examine the layout of the Customer entity to learn how you can configure dimension entities in Astera Data Stack.
To open the properties of an entity, right-click on it and select Properties from the context menu. Alternatively, you can double-click on the entity object.
A configuration window will appear. This window provides the same options as it does for a general entity, the only additions being the Dimension Role and Related Dimension Field columns on the Layout Builder screen. To learn about general entity properties, click here.
On the first screen, you can view and edit some general information regarding the table, including its name, schema, and type.
Click Next to proceed to the Layout Builder screen.
The Dimension Role column in the layout builder provides a dropdown menu for you to assign a dimension-related role to each field present in the table. These roles mostly constitute Slowly Changing Dimension types and other SCD functions.
Insert Only: Stores a field value that will not be updated, regardless of any updates made to it. Otherwise known as SCD0.
Business Key: Holds the key that is normally used to identify records in the table.
SCD1 – Update: Stores an SCD value which will be updated if modified. The storage of historical data is not considered.
SCD2 – Update and Insert: Stores an SCD value which is expected to change over time. A new record is added each time the value changes. The validity of each record is indicated through additional fields.
Current Record Designator: Stores the Active Value if the record has the current version of the SCD value. Otherwise, it stores the Inactive Value. Active Value and Inactive Value should be entered in the appropriate cells in the grid next to the Current Record Designator.
Surrogate Key: Designates the field holding an extra system generated key that identifies versions of the SCD value with the same business key.
Effective Date: Stores the date at which the SCD value in a record became valid.
Expiration Date: Stores the date at which the SCD value in a record became invalid.
Version Number: Stores the version number of the SCD value.
Previous Surrogate Key: Stores the surrogate key of the previous version of the record.
SCD3 – Current Value: Stores the current value of an SCD Type 3 field.
SCD3 – Previous Value: Stores the previous value of an SCD Type 3 field.
SCD6 – Current Value: Stores the current value of an SCD Type 6 field.
SCD6 – Historical Value: Stores a historical value (not necessarily the previous value) of an SCD Type 6 field.
Placeholder Dimension: Caters to late arriving dimensions and early arriving facts.
In this dimension table, we have the following fields:
Customer_Key: Surrogate Key
WWI_Customer_ID: Business Key
Customer: SCD2 – Update and Insert
Bill_to_Customer: Insert Only
Valid_To: Expiration Date
The Related Dimension Field column only appears in the layout builder when the Show Options for SCD3 and SCD6 option on the Entity Properties screen is checked.
Once you’ve assigned the SCD3 or SCD6 role to a field, the dropdown menu in the Related Dimension Field column will provide a list of fields that have been assigned the SCD3 - Previous Value or the SCD6 - Historical Value dimension role. From here, you can choose a field to store the previous value or historical value, respectively. This functionality is particularly useful in cases where you need to use more than one set of SCD3 or SCD6 values.
In this case, the Customer dimension entity already contains fields that can be assigned the surrogate key and row identifier dimension roles. However, if your entity layout does not contain such fields, you can create them via the options that appear in the context menu when you right-click on the entity.
Note: In this case, the Add Surrogate Key option is disabled because the layout already contains a surrogate key field.
If you wish to add a row identifier to the layout or change the row identifier already present in the layout, click on the Add Row Identifier option. A pop-up window will allow you to choose from the list of row identifiers that are available in the product.
Once you’ve chosen an option from the list, you can name the new field using the textbox at the bottom of the window. Click OK to close the window and add the field to the dimension entity’s layout.
This concludes our discussion on dimension entities.
Early arriving facts and late arriving dimensions is a concept in data warehousing that refers to the facts that arrive in the data warehouse before the related dimension information has been loaded into the data warehouse. For example, in a retail data warehouse, order details might arrive earlier than the corresponding customer’s information who placed the order. Since the dimension is not available at the time the fact table is loaded, the foreign key in the fact table will not have a corresponding primary/surrogate key in the dimension table, thereby causing an error.
Placeholder dimensions are a way to handle early arriving facts and late arriving dimensions in a data warehouse. Placeholder dimensions are temporary dimension records that are created with the specified default values until the real dimension data becomes available. Once the real dimension data arrives, the placeholder dimension is replaced with the real dimension data.
Here’s how you can create a placeholder dimension in Astera Data Warehouse Builder.
Right-click the dimension entity for which you want to specify the placeholder dimension, select Properties, and navigate to the Layout Builder.
Add a new field – in this case, the ‘IsPlaceholder’ field - of Boolean Data Type and mark the Dimension Role as Placeholder Dimension.
Click OK.
Note: Make sure to specify default values for all the fields within the dimension entity which do not allow nulls. These default values will be used to create the placeholder dimension record in case of early arriving facts and late arriving dimensions. If the default value is not specified for these fields, a warning will be shown prior to the data model deployment, and an error will be thrown at runtime.
You can also specify default values for fields that do allow nulls, but it is not a requirement.
Consider this use case, where we have specified a placeholder dimension for the Customers Dimension.
Let’s consider a scenario of early arriving facts and late arriving dimensions. An order is placed by a customer with Customer ID ‘ALFKI’. However, the information of the Customer with Customer ID ‘ALFKI’ is not available in the dimension table yet.
When the fact is loaded, it looks for the corresponding dimension in the customer dimension table. Since the record for the corresponding dimension (CustomerID ‘ALFKI’) is missing and has not arrived yet, a temporary dummy Placeholder Dimension record is created in the customer dimension – using the default values specified earlier - and its surrogate key is used to populate the foreign key in the fact table.
The placeholder dimension is identified by the ‘IsPlaceholder’ field, if the value of this field is ‘1’ (which indicates that the Placeholder field is True), it shows that the record is a placeholder in the dimension table.
When the actual data for the customer where CustomerID = ‘ALFKI’ arrives, the placeholder dimension record is updated with the new information and the ‘IsPlaceholder’ value changes to zero indicating that it is no longer a placeholder record, and therefore the Placeholder field is False.
Aggregate tables in Astera Data Stack allow users to quickly and easily merge data to compute averages, totals, counts, and minimum and maximum values.
These tables are highly beneficial when used as foundations for standard reports that require minimal changes. For such standardized reporting structures, aggregate tables are fast, dependable, and user-friendly for both developers and end-users. Their ease of setup also makes them valuable for impromptu reporting.
However, adaptability is compromised in favor of this efficiency and simplicity. Aggregate tables are not as practical for analysts who need to examine data from various perspectives. Unlike an OLAP cube, consolidated table data cannot be pivoted, nor can it be drilled down to a more detailed level to view underlying transactions. Nevertheless, aggregate tables can be incredibly useful when applied in the appropriate context.
For our use case, we will create an aggregate table to aggregate customers’ sales data by month. For the purposes of this demonstration, please refer to the simple dimensional model shown here:
As the sales data must be aggregated for our use case, the base fact table will be Sale. Right-click the Sale table header and select Add Aggregate Table from the context menu.
A new Sale_Aggregate entity will be created in the model. This will act as the aggregate entity, indicated by a blue dash-dotted link pointing to its base fact table, as shown below:
First, right-click the aggregate table’s header and select Properties from the context menu or double-click the table header.
In the Sale_Aggregate: Aggregate Table Properties window, provide the name, schema, and description (optional) according to requirements. Once done, click Next.
In the Sale_Aggregate: Sort Transformation Properties window, select fields on which the aggregate must be performed, along with the operation. Once done, click Next.
In the Sale_Aggregate: Aggregate Group By window, select Group By fields to specify fields to analyze data by and select granularity.
Data Granularity: You can change the granularity for a date field to determine the intervals for which item values are shown. Granularity in Aggregates only works if you have selected a date dimension related field as a Groupby field, which in our use case is the Invoice_Date_key field. You can set the date granularity to any one of the following values:
Yearly
Quarterly
Monthly
Weekly
Daily (this is the default)
Once the appropriate granularity has been selected, click Next. The Sale_Aggregate: Entity Properties shows the finalized layout of the aggregate table. You can change the length, name, and dB types of the fields according to your needs.
Once done, Click OK to close the window.
Your aggregate table has been configured successfully. The newly created blue, dash-dotted links point to the tables that your aggregate table is dependent on.
Notice that a new dimension (MonthDimension) has also been created. This is because the ‘Monthly’ granularity was selected while configuring the aggregate.
The Month dimension will hold records in monthly granularity and will further allow timely aggregations of these figures when reporting. You will get different dissected dimensions for other granularities except for the ‘Daily’ granularity as the dimension for this granularity is already present in the DateDimension entity in the model.
Now, forward engineer the aggregate entities (aggregate table and dissected dimension) and the dimensional model (if it has not already been forward engineered).
Fill the dissected dimension, the MonthDimension, by right-clicking the table header and selecting the Fill Month Dimension Table option from the context menu.
Note: You can also edit or update already configured aggregate tables.
After completing all aforementioned steps, the model must be deployed. When deploying a dimensional model containing aggregate tables, Astera Data Stack verifies some set of rules specific to aggregates in order for the deployment to be successful.
These rules are:
All dissected dimensions such as MonthDimension, WeekDimension…etc., must be filled.
At least one field should be selected for Groupby.
At least one field should be selected for Aggregation.
If a DateDimension-related field is selected as GroupBy and Monthly, Weekly, Quarterly or Yearly granularity is selected, then the equivalent dissected dimension (such as YearDimension) must be present in the model.
Aggregate tables are loaded/Updated along with fact tables.
To load or update a fact table, the Fact Table Loader object can be used in a dataflow.
First, drag-and-drop the Fact Table Loader object from the Toolbox onto the designer.
Double-click the object header or right-click the object header and select properties from the context menu. The FactSale: Database Connection window will open.
Select the appropriate data model deployment and click Next.
In the FactSale: Pick Table window select the fact associated with your aggregate. Once done, click Next.
In the FactSale: Select Aggregate Table window, you will see all the aggregates associated with the selected fact.
Check the aggregate tables which you want to load/update and click OK to close the window.
Now, map all appropriate fields from the DataModelQuery object to your fact loader, in the same manner as loading a fact table.
Now, run the fact loader dataflow. First, your fact table will be loaded, and then the selected aggregates that were checked earlier in the fact loader. You can see the stack trace of your aggregate in the Job Progress window.
Your aggregate table has been loaded successfully. You can now view the resultant data available in your aggregate table.
Also notice that the “invoice Date Key” field shows only monthly level information, as we had selected Monthly Granularity while configuring our aggregate.
Aggregates only work with Star-Schema dimensional models.
If any field/relationship/dimension is deleted and was being used in a configured aggregate, the aggregate table will need to be refreshed in order to make the required changes in the aggregate as well. You can refresh the aggregate by right-clicking the aggregate table header and selecting the Refresh Aggregate Table option from the context menu.
A dimensional model is a data model that has been optimized for data storage and faster data retrieval in a data warehouse. As part of a data warehouse, it reads, analyzes, and summarizes information, thus playing a pivotal role in business analysis and decision-making.
Every dimensional model is composed of fact tables and dimension tables. A fact table is traditionally the central table of the model and consists of quantitative information such as measures and metrics. A dimension table, on the other hand, contains descriptive information and is referenced to in the fact table through a foreign key. Together, fact tables and dimensional tables make up the star schema of the model, with a fact table in the center, surrounded by related dimension tables.
Note: The star schema is the simplest schema for a dimensional model. Some extensions of it include the snowflake schema and galaxy schema.
In Astera Data Stack, you can assign an entity type (fact or dimension) to each general entity in a data model, turning it into a dimensional model. For dimension entities, you can assign dimension roles, including surrogate keys, business keys, and slowly changing dimensions, to each field. Similarly, in fact entities, you can assign fact roles. Moreover, the toolbox contains date and time dimension entities that can also be used as part of a dimensional model.
Here is a sample dimensional model that comprises a star schema.
The entity named Sales represents the fact table and the rest of entities represent dimension tables.
This concludes our discussion on an introduction to dimensional modelling.
Date and time dimensions can be used in a dimensional model to analyze and report data more efficiently.
The Date Dimension table has date-specific attributes that include day, date, weeks, quarter, months, fiscal period, national holiday indicators, quarter, and year.
The Time Dimension table has time-specific attributes that include hour formats, minute of the day, seconds of hour, quarter hour, and am or pm.
Note: Both lists are not exhaustive.
This is how you can access and use Date and Time dimensions in Astera Data Stack:
To get the Date Dimension object on the data model, go to Toolbox > Data Model > Date Dimension and drag-and-drop it onto the data model designer.
To get the Time Dimension object on the data model, go to Toolbox > Data Model > Time Dimension and drag-and-drop it onto the data model designer.
You cannot make any modifications in the Date and Time dimension objects. If you right-click on a Date Dimension or Time Dimension object and open its properties, you would see that the Entity Properties options have been disabled for the objects.
The next screen is the Layout Builder, where you can view the entity layout and its specifications. All other options are set to default and cannot be modified.
Next is the Data Model Entity Indexes screen, where you’ll find a list of predefined indexes. Rest of the options for indexes are disabled.
At this point, we can create relationships between the fact entity and the newly added date and time dimensions respectively, and then forward engineer the data model for the date and time dimension tables to be reflected in the target database.
To fill the date and time dimension objects with data, follow the steps below:
To fill a Date Dimension table – Right-click on the Date Dimension object and select the Fill Date Dimension Table option. Astera Data Stack would automatically fill values in the provided database table.
To fill a Time Dimension table – Right-click on the Time Dimension object and select the Fill Time Dimension Table option. Astera Data Stack would automatically fill values in the provided database table.
A Date/Time field within the Fact entity can be replaced with the Date/Time Dimension Relationship, as follows:
Right-click the Date/Time field you want to replace with Date/Time Relationship and select ‘Replace with Date Dimension Relationship’ or Replace with Time Dimension Relationship’ option from the menu.
2. A Date or Time Dimension entity will be created, and a relationship will be created between the newly created Date/Time dimension and the fact table.
Notice that the Date/Time Field that was replaced with the Date/Time Dimension relationship has been marked as a foreign key that refers to the newly created Date/Time Dimension.
This concludes our discussion on using date and time dimensions in Astera Data Stack.
Note: For more information about configuring the Fact Table Loader object, click .
Note: For more information about the Data Model Query object, click .
To learn more about Forward Engineering, click .
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.
In this article, we’ll cover a few common errors and warnings that you may encounter while verifying a dimensional model.
In this case, we have a data model that contains one dimension entity called SCD_Customer.
Here is the layout of this entity.
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:
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.
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.
Here, we have a modified version of the data model used in case 1.
In this case, the layout of the SCD_Customer entity contains an SCD2 element but does not contain any record identifiers.
Upon verifying for read and write deployment, the Verify window will display the following error:
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.
The model can now be verified successfully.
Here, we have another modified version of the model in cases 1 and 2.
The layout of the SCD_Customer entity contains a business key, an SCD1 element, and an Effective Date record identifier.
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:
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.
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.
The model can now be verified successfully.
This concludes our discussion on verifying a dimensional model.
