Dimension entity

A dimension entity provides descriptive, nonnumeric information about the numerical values in a fact entity. 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 Dimensions 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.

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 the 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.

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 Date dimension entity supports two aggregation paths, Calendar Year - Quarter - Month - Date and Fiscal Year - Quarter - Period - Date, which are defined as hierarchies. Fact entities can use the Date dimension entity at all levels of granularity, such as Year, Quarter, Month, or Date.

Properties

Name (mandatory)
A textual name that identifies the 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 the entity originates from and can be inherited from it when appropriate.
  • e.g. dimension entity Meter Model
Dimensional type (mandatory)
The dimensional type is set to Dimension for all dimension entities.
Owning package (mandatory)
The owning package to which the dimension entity belongs. All dimension entities are grouped in a sub-package of the Dimensions package.
  • e.g. package Dimensions owns dimension entity Meter Model
Description (mandatory)
A complete and unambiguous description of the dimension entity. This description can be based on the description of the business term that the 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 the logical data model is transformed 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 the 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 Model Number describes dimension entity Meter Model
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.
  • e.g. attribute Meter Model Id is the unique identifier of dimension entity Meter Model
  • e.g. attribute System Resource Id is the unique identifier of dimension entity System Resource
Primary key (mandatory)
The primary key identifies uniquely an instance of the 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 Meter Model PK is the primary key of dimension entity Meter Model
Technical attributes (required)
The technical attributes that are defined on any dimension entity. The technical attributes are attributes that are defined systematically on all dimension entities.
  • e.g. Source System Unique Id
  • e.g. Source System Name
  • e.g. Source System Code
History Support attributes (optional)
History Support is an attribute group that holds all the technical attributes required to handle history management. History Support is used only in 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 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.
  • e.g. attribute Anchor Id is the anchor of dimension entity Location
Current Row Indicator
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 Date and Effective To Date in their query. For example, this attribute is useful for current and ad hoc analysis on dimensions without traversing fact tables.
    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 Date: 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 Date: 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 Date is set to 1 April and the Valid From Date is set to 15 April.
    System transaction timestamps
    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 Date: 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 Date: 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
    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 used in all dimension entities, except the time dimension.
    Population Timestamp
    An attribute that holds the time of the population cycle.
    Population Description
    An attribute that provides textual information about the population cycle.
    Source System Name
    An attribute that holds the name of the application or source system from which the entity instance was populated.
    Source System Code
    An attribute that holds the code 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, of which the key is defined on the primary key attribute. Some dimension entities, such as Date and Location , have predefined hierarchies.
    • e.g. dimension entity Date has for hierarchies Calendar Year - Quarter - Month - Date and Fiscal Year - Quarter - Period - Date
    • e.g. hierarchy Calendar Year - Quarter - Month - Date has four hierarchy levels defined: Year, Quarter, Month, and Date

    In mini-dimension entities, one hierarchy per attribute is defined to illustrate the aggregation paths of every attribute in the mini-dimension entity. Each hierarchy has only one level of aggregation, the level that 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 do 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 Meter Model is parent of relationship Meter Reading Fact_Meter Model_FK with fact entity Meter Reading Fact
      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 Asset Model is assigned to dimension entity Transformer Model
      Originating Atomic Warehouse Model, Business Data Model elements or both (mandatory)
      One or more dependencies to AWM and/or BDM elements from which this dimension entity originates. This indicates from which AWM detail attribute and/or BDM attribute, the dimension entity is populated, in an environment where these models are deployed. By convention, the name of the dependency starts with AWM or BDM and the dependency type is transformation.
      • e.g. dimension entity Meter Model has a transformation dependency to the target BDM entity Electric Meter Model
      • e.g. dimension entity Meter Model has a transformation dependency to the target AWM fundamental entity Electric Meter Model Detail