Dimension entity

A dimension entity provides descriptive, nonnumeric information about the numerical values in a fact entity. In the Dimensional Warehouse Model (DWM), dimension entities are designed to be used in a pure star-schema style as conformed dimensions. Dimension entities originate from the business terms that are defined as dimensions in the analytical requirements and from the fundamental entities in the Atomic Warehouse Model (AWM). A dimension entity is composed of elements of a fundamental entity, and all other elements from other fundamental entities that together form an aggregation path.

The dimension entities are organized in a package that is named Data Areas and are related to one or more fact entities, indicating the axes of analysis. Each fact entity is related to at least one dimension entity, which holds the details that qualify the measures. When a dimension entity needs versioning, it holds all the versions of an instance, which are related to each other with an anchor attribute. This allows a fact to be related to the appropriate version of a related dimension entity.

A dimension entity can require Dimensional design techniques to support specific requirements. For example, outrigger entities support fast changing attributes, bridge entities or pathstring attributes allow navigation within variable depth hierarchies.

History management

When the attribute values of a dimension entity vary over time and those changes need to be tracked, the history management on the dimension entity is enabled by applying the principles of Slowly Changing Dimension (SCD) Type 2. History management is enabled when different versions of a dimension entity need to be related to a fact, or for reporting purposes on the dimension entity itself. When history management is enabled, the dimension entity holds the current values of data, as well as all previous values.

Transaction timestamps indicate the time period during which the values of this dimension entity are true in the source system or in the business reality. For each version of a dimension entity that needs to be stored in DWM, a new version of the dimension entity instance is created, and all attribute values are stored in the new version, even if they remain unchanged. In this technique, all versions of the same instance of the dimension entity are linked using an anchor attribute.

The attributes required to enable history management are defined in an attribute group that is named Dimension History Support, which is included in every dimension entity that requires history management. The Dimension History Support attribute group allows the single definition of such attributes and ensures consistency across the model.

About mini-dimensions

A mini-dimension is a dimension entity that groups attributes that analyze a fact entity. Each attribute of a mini-dimension has discrete values on which you can aggregate the measures of a fact entity. Typically, the mini-dimensions externalize attributes that represent an operational code, a flag or an indicator. Mini-dimensions must be defined only for dimensions that otherwise can hold a substantial number of such attributes. By default, a mini-dimension is created when the corresponding dimension has at least five attributes with discrete values. A mini-dimension is populated with as many rows as there are combinations of values of the attributes it holds. Each combination represents a profile. One of the advantages of a mini-dimension is that its volume is lower than the volume of its corresponding dimension. Using the mini-dimension rather than the more granular dimension potentially reduces the volume of the fact entity, since the granularity of the fact is higher. Moreover, mini-dimensions hold all columns on which users can run queries. Mini-dimensions make profiling easier.

For some dimension entities, multiple mini-dimensions are defined on the basis of logical business grouping of attributes that are usually queried together.

About aggregation paths

Since DWM follows a star-schema style, the dimension entity holds the attributes that are needed to express the aggregation paths that are used to drill up and down on facts. Each aggregation path is expressed as a hierarchy by using the dimensional notation. The dimension entities support all levels of granularity of the aggregation path. This assumes that the dimension entity is populated with instances at all levels of granularity. For example, the Calendar Date Dimension dimension entity supports two aggregation paths, Calendar and Fiscal, which are defined as hierarchies. Fact entities can use the Calendar Date Dimension dimension entity at all levels of granularity, such as Calendar Date, Calendar Month, Calendar Quarter, or Calendar Year. The Calendar Date Dimension dimension is populated with instances at all levels of granularity.

Properties

Name (mandatory)

A textual name that identifies this dimension entity in title case (all words start with a capital letter). Where possible, this name is based on the name of the business terms that this entity originates from and can be inherited from it when appropriate.

e.g. dimension entity Calendar Date Dimension
e.g. dimension entity Channel Dimension

Dimensional type (mandatory)

The dimensional type is set to Dimension for all dimension entities.

Owning package (mandatory)

The owning package to which this dimension entity belongs.

e.g. package Classification owns dimension entity Calendar Date Dimension

Description (mandatory)

A complete and unambiguous description of this dimension entity. This description can be based on the description of the business term that this entity originates from.

Persistent (mandatory)

A flag that indicates whether or not the entity is persistent. All entities of the delivered model are set to persistent. When the persistent flag is enabled, the entity is included in the scope of the practitioner, project, or enterprise data model.

Note: a persistent entity is physically implemented when it transforms the logical data model into a physical data model. When harvesting the data model, special care must be taken in connection with the persistent flag. For example, project A can decide to include an entity, but project B can decide not to include it. When harvesting project A at the enterprise level, the entity is set to persistent, indicating that the entity is part of the enterprise data model. Afterward, when harvesting project B at the enterprise level, care must be taken to keep the entity as persistent, although project B does not include it.

Basic attributes (mandatory)

One or more basic attributes that describe this dimension entity. These basic attributes are based on the business terms that they originate from and depend on their corresponding attributes in AWM. The attributes are those that are requested to support the aggregation path in a star-schema style.

e.g. attribute Calendar Year describes dimension entity Calendar Date Dimension
e.g. attribute Country describes dimension entity Geographic Area Dimension

Unique identifier (mandatory)

An attribute that identifies uniquely and without business meaning the dimension entity. By convention, the name is the name of the dimension entity, which is suffixed with Id. This sole attribute defines the surrogate primary key of this dimension entity. Natural keys, which can be useful in business reporting, are designed as basic attributes.

e.g. attribute Calendar Date Dimension Id is the unique identifier of dimension entity Calendar Date Dimension
e.g. attribute Geographic Area Dimension Id is the unique identifier of dimension entity Geographic Area Dimension

Primary key (mandatory)

The primary key identifies uniquely an instance of this dimension entity and is composed of the unique identifier attribute. By convention, the name of the primary key is the name of the dimension entity, which is suffixed with PK.

e.g. primary key Calendar Date Dimension PK is the primary key of dimension entity Calendar Date Dimension
e.g. primary key Geographic Area Dimension PK is the primary key of dimension entity Geographic Area Dimension

History Support attributes (optional)

Dimension History Support is an attribute group that holds all the technical attributes required to handle history management. Dimension History Support is defined on dimension entities that require history management. This attribute group does not apply to mini-dimension entities, which are not subject to history management.

Anchor Id

An attribute that serves as the unique anchoring point to link together all versions of an instance of the same concept, and by doing so identifying the instance. Every time the value of one or more attributes of an instance changes, a new row is created that holds the new version of the instance with the same value of the anchor attribute. The anchoring mechanism is applied onto changing dimensions. It is not applied to mini-dimensions, because a change in an attribute value in such an entity implies a different profile.

e.g. attribute Anchor Id is the anchor of dimension entity Geographic Area Dimension

Current Row Indicator (mandatory)

An attribute that indicates whether the version represents the current values in the business reality. It eases model consumability by allowing the business user to immediately identify, among all history versions of an instance, which row represents the current values in the business reality, without having to use a more complex condition on the Effective From Timestamp and Effective To Timestamp in their query. For example, this attribute is useful for current and ad hoc analysis on dimensions without traversing fact tables.

e.g. attribute Current Row Indicator in dimension entity Customer Dimension

Business transaction timestamps

Business transaction timestamps indicate the period during which the values of all attributes of the dimension entity instance are true in the business reality:

Effective From Timestamp: the transaction time that represents the beginning of the time period during which the values of this recorded data are true in the business reality.
Effective To Timestamp: the transaction time that represents the end of the time period during which the values of this recorded data are true in the business reality.

These timestamps can be equivalent to the timestamps of the recording in the source system (system transaction timestamps) or can be different when the data is recorded before or after it is effective in the business reality. For example, if a change in a person's marital status is recorded in the source system on 15 April, but the change actually happened on 1 April, the Effective From Timestamp is set to 1 April and the Valid From Timestamp is set to 15 April.

System transaction timestamps (mandatory)

System transaction timestamps indicate the period during which the values of all attributes of the dimension entity are true in the source system:

Valid From Timestamp: the transaction time that represents the beginning of the time period during which the values of this recorded data are true in the source system.
Valid To Timestamp: the transaction time that represents the end of the time period during which the values of this recorded data are true in the source system.

There is no overlap between the periods of versions of the same dimension entity.

Population information attributes (optional)

Dimension Population Info is an attribute group that holds all the technical attributes regarding the population cycle of the dimension entity. Those attributes assure a proper traceability between each instance of a dimension entity and either the Atomic Warehouse element, or the source system element, from which it gets populated. Dimension Population Info is defined on all dimension entities, except the time dimension.


Population Description: An attribute that provides textual information about the population cycle.
Population Timestamp: An attribute that holds the time of the population cycle.
Source System Code: An attribute that holds the code of the application or source system from which the entity instance was populated.
Source System Name: An attribute that holds the name of the application or source system from which the entity instance was populated.
Source System Unique Id: An attribute that holds the source system's unique identifier of the information used to populate the entity instance.

Hierarchies (mandatory)

One or more hierarchies that illustrate the aggregation paths of the dimension entity. Each hierarchy can have one or more levels of aggregation, a level that is defined by an attribute of the dimension entity. By default, all dimensions have at least one hierarchy with one level defined on the primary key attribute. Some dimension entities, such as Calendar Date Dimension and Geographic Area Dimension, have predefined hierarchies.

e.g. dimension entity Calendar Date Dimension has for hierarchies Calendar Hierarchy and Fiscal Hierarchy
e.g. hierarchy Calendar Hierarchy has four hierarchy levels defined: Calendar Date, Calendar Month, Calendar Quarter, or Calendar Year
e.g. hierarchy level Calendar YearCalendar year uses attribute Calendar Year as both level key and level caption

As far as mini-dimensions are concerned, one hierarchy per attribute must be defined to illustrate the aggregation paths of the mini-dimension entity on each of its attributes. Each hierarchy has only one level of aggregation, where the level is defined by the attribute of the mini-dimension entity. If a business-meaningful level link between two or more attributes of a mini-dimension entity exists, the customization can update the level of the hierarchy accordingly by adding the attributes that participate in the aggregation path to that level.

Relationships (mandatory)

The relationships to other entities. The dimension entity is related to one or more fact entities with a relationship. This relationship indicates an axis of analysis for the measures in the fact entity. Each fact is related to the appropriate version of a dimension entity instance.

e.g. dimension entity Customer Dimension is parent of relationship is dimension of / has for dimension with transaction fact entity Sales Transaction Fact

Relationships to fact entities (optional)

The relationships to one or more fact entities. These relationships indicate the axes of analysis for the measures in the fact entity. Each instance of a fact entity is related to the appropriate version of a dimension entity instance.

e.g. dimension entity Calendar Date Dimension is parent of relationship is dimension of / has for dimension with fact entity Data Service Usage Fact
e.g. mini-dimension entity Customer Mini Dimension is parent of relationship is dimension of / has for dimension with fact entity Commerce Service Usage Fact

Relationships to bridge entities or hierarchy bridge entities (optional)

The relationships to one or more bridge or hierarchy bridge entities. Such relationships exist when a dimension entity is an explicit parent of a bridge entity. Not all parent conformed dimensions of a bridge entity have an explicit relationship with it. If the attribute that represents the key of a parent dimension of a bridge entity supports more than one dimension entities, then the relationship is implicit and the foreign key is defined as a soft link.

e.g. dimension entity Real Property Dimension is parent of relationship is parent of / has for parent with bridge entity Real Property Location Bridge
e.g. dimension entity Geographic Area Dimension is parent of relationship is right parent of / has for right parent with bridge entity Geographic Area Bridge
e.g. dimension entity Geographic Area Dimension is parent of relationship is child of / has for child with hierarchy bridge entity Geographic Area Hierarchy Bridge

Assigned terms (mandatory)

The business terms, usually primary terms, that are the origin of the definition of this dimension entity. The assigned terms maintain traceability between the DWM elements and the business terms that are used as dimensions.

e.g. business term Individual is assigned to dimension entity Individual Dimension
e.g. business term Geographic area is assigned to dimension entity Geographic Area Dimension

Originating Atomic Warehouse Model elements (mandatory)

One or more dependencies to AWM elements from which this dimension entity originates. This indicates from which AWM fundamental entity, the dimension entity is populated, in an environment where these models are deployed. By convention, the name of the dependency is AWM - Data Model Mapping and the dependency type is Data Model Mapping.

e.g. dimension entity Customer Dimension has a population dependency to the target AWM fundamental entity Customer