Fundamental entity

An Atomic Warehouse Model (AWM) fundamental entity represents a logical data structure that holds a group of atomic business information. A fundamental entity supports one or more business terms and is designed to achieve the objectives of AWM. A fundamental entity is derived from the business terms by applying ER modeling techniques. fundamental entities are organized in a type hierarchy, which classifies them from the more abstract down to the most specific and helps to define common properties.

History management

A temporal modeling technique is used to support data versioning of time-variant attributes that need to be tracked. Only attributes that need to be versioned (some or all) are kept in a separate history entity, which is attached to the fundamental entity. Transaction timestamps are defined in the root fundamental entity and in the history entity to indicate the time period during which the values of this fundamental entity are true in the source system or in the business reality.

This technique stores the majority of changes outside the fundamental entity and does not increase the fundamental entity volume when the update ratio is high. This also allows to version only specific attributes and not the entire row. However, this makes the creation of a new version and the query of different versions more complex, and the enablement of the versioning requests the modeling of an additional history entity on top of the fundamental entity. The decision to enable this technique is driven by the functional and performance requirements on each fundamental entity, and by the number of update activities.

Properties

Name (mandatory)
A textual name that identifies this entity in title case (all words start with a capital letter). This name is based on the name of the business terms that this entity originates from. When the entity originates from only one business term, the name can be inherited from this business term. When the entity originates from multiple business terms, the name is usually the most generic one among the business terms.
  • e.g. fundamental entity Investment Arrangement (that originates from business term Investment arrangement)
  • e.g. fundamental entity City (that originates from business term City)
Owning package (mandatory)
The owning package to which this entity belongs. This package can be based on the business category of the business term that this entity originates from.
  • e.g. package Arrangement owns fundamental entity Investment Arrangement
  • e.g. package Location owns fundamental entity City
Description (mandatory)
A complete and unambiguous description of this entity. Examples can be included in the description. These have to be prefixed with For example and are delimited by a new line. This description can be based on the description of the business terms that this entity originates from and can be identical to it when appropriate.
Persistent (mandatory)
A flag that indicates whether the entity is persistent or not. All fundamental 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.
Supertype (optional)
The generalized fundamental entity that shares its attributes and associations with this fundamental entity. It can originate from the parent concept terms of the business term that this fundamental entity originates from. A fundamental entity has the same primary key as its supertype fundamental entity, and this primary key is also a foreign key to the supertype fundamental entity. When moving to physical design, transformation options indicate whether the fundamental entity is rolled up into its supertype, whether the supertype is rolled down into the fundamental entity, or whether the fundamental entity is implemented as a separate table.
  • e.g. fundamental entity Account Arrangement is a supertype of entity Investment Arrangement
  • e.g. fundamental entity Investment Arrangement is a supertype of entity Fund Investment Arrangement
Subtypes (optional)
The fundamental entities that inherit the attributes and associations of this fundamental entity.
  • e.g. fundamental entity Fund Investment Arrangement is a subtype of entity Investment Arrangement
  • e.g. fundamental entity Investment Arrangement is a subtype of entity Account Arrangement
Basic attributes (mandatory)
One or many basic attributes that describe this fundamental entity, these basic attributes are based on the descriptor or relationship business terms that are associated with the concept business term that this entity originates from, and on the description of that concept business term.
  • e.g. attribute Product Name describes fundamental entity Product
  • e.g. attribute Location Name describes fundamental entity Location
Advanced attributes
The advanced attributes that are defined on this fundamental entity are usually technical attributes that are defined systematically on fundamental entities. These attributes do not usually originate from business terms.
Unique identifier (mandatory)
An attribute that identifies a fundamental entity uniquely and without any business meaning. By convention, the name is the name of the fundamental entity, which is suffixed with Id. This sole attribute is used to define the surrogate primary key of this fundamental entity.
  • e.g. attribute Product Id is the unique identifier of the fundamental entity Product
  • e.g. attribute Location Id is the unique identifier of the fundamental entity Location
Business transaction timestamps (optional)
Business transaction timestamps indicate the period during which the values of all attributes of the fundamental entity instance are true in the business reality:
Effective Date
The transaction date that represents the beginning of the time period during which the values of this recorded data are true in the business reality.
End Date
The transaction date 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. These attributes are defined systematically on root fundamental entities. Sometimes those attributes are identified in the business terms and can be mapped to them.
Primary key (mandatory)
The primary key identifies uniquely an instance of this fundamental entity, and is composed of the unique identifier advanced attribute. By convention, the name of the primary key is the name of the fundamental entity, which is suffixed with PK.
  • e.g. primary key Credit Facility Arrangement PK is the primary key of fundamental entity Credit Facility Arrangement
  • e.g. primary key Location PK is the primary key of fundamental entity Location
Relationships (optional)
The relationships to other entities. A fundamental entity can be related to all kinds of entities. The root fundamental entity is always related to two supportive entities: one to indicate the population information from the source system and the other to indicate the type of data. The fundamental entity is also related to supportive entities for any kind of classification. When time-variant attributes are versioned in a history entity, the fundamental entity is related to this history entity.

The fundamental entity is usually related to other fundamental entities via associative entities. In some cases, however, the fundamental entity can be related directly to another fundamental entity for ease of navigation.

  • e.g. fundamental entity Location is child of relationship populates / is populated by with supportive entity Population Event With Unique Id Characteristic
  • e.g. fundamental entity Location is child of relationship classifies / is classified by with supportive entity Location Type
  • e.g. fundamental entity Individual is child of relationship classifies / is classified by with supportive entity Gender
  • e.g. fundamental entity Involved Party is parent of relationship is subject for / has subject of with associative entity Involved Party / Involved Party Rltnp
  • e.g. fundamental entity Individual is child of relationship has as citizen / is citizen of with fundamental entity Country
  • e.g. fundamental entity Account Credit Facility Arrangement is child of relationship is credit interest rate for / has credit interest rate of with fundamental entity Interest Rate
Assigned terms (mandatory)
The business terms, usually concept terms, that are the origin of the definition of this fundamental entity. A business term can be the source of one or more fundamental entities, depending on its definition. The assigned terms maintain traceability between the AWM elements and the business terms. When a business term is assigned to an AWM element, you must ensure that, if the term has synonyms, all synonyms are mapped to the same AWM element.
  • e.g. business term Investment product is assigned to fundamental entity Investment Product
  • e.g. business term Location is assigned to fundamental entity Location