Supportive entity

A supportive entity is used to support the data warehouse and does not always originate directly from business terms. It is usually created to support technical information, such as population information from the source systems, or enumeration values that can be assigned to various entities. Enumeration values include values, such as code values, for example gender, or type values such as type code. A supportive entity can also be used to handle code values and their translations.

Properties

Name (mandatory)
A textual name that identifies this entity in title case (all words start with a capital letter).
  • e.g. supportive entity Common Code
  • e.g. supportive entity Code Set
Owning package (mandatory)
The owning package to which this entity belongs. This can be a package created for grouping supportive entities of the same kind together or this can be the same package as the package of the entities related to this supportive entity.
  • e.g. package Common owns supportive entity Common Code
  • e.g. package Common owns supportive entity Code Set
Description (mandatory)
A complete and unambiguous description of this entity.
Persistent (mandatory)
A flag that indicates whether the entity is persistent or not. In the delivered model, supportive entities created to support enumeration values are set to persistent. Supportive entities containing technical information are set to non-persistent, and will not be physically implemented. However the attributes of these technical entities are set to persist, therefore where they appear as foreign key attributes on other entities with child relationships, they are physically implemented on those other entities. 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 (optional)
The basic attributes that describe this supportive entity.
  • e.g. attribute Code Name describes supportive entity Common Code
  • e.g. attribute Code Set Description describes supportive entity Code Set
Advanced attributes
The advanced attributes that are defined on this supportive entity. The advanced attributes are usually technical attributes that are defined systematically on supportive entities. Those attributes do not usually originate from business terms.
Technical Attributes
The technical attributes that are defined on this array entity. The technical attributes are attributes that are defined systematically on array entities. Those attributes do not usually originate from business terms.
  • Load Info Id: A reference to the load info entity that describes the system event that loaded this row of data.
  • Tenant Id: Indicates the ownership of a particular row of data and controls the logic of multitenant processing.
  • Source Code Id: Indicates the origin of the data identifying the actual load source, vendor, manual key entry, or context of the data in a specific row in the database.
Business transaction timestamps (optional)
Business transaction timestamps indicate the period during which the values of all attributes of the supportive entity instance are true in the business reality:
Effective From Ts
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 Ts
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.

These attributes are defined systematically on root supportive entities. Sometimes these attributes are identified in the business terms and can be mapped to them.

System transaction timestamps (optional)
System transaction timestamps indicate the period during which the values of all attributes of the supportive entity are true in the source system:
Valid From Ts
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 Ts
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 all versions of the same supportive entity.

These attributes can be defined on root supportive entities when needed or can be defined systematically.

Primary key (mandatory)
The primary key identifies uniquely an instance of this supportive entity and is composed of the unique identifier advanced attribute. By convention, the name of the primary key is the name of the supportive entity, which is suffixed with PK.
  • e.g. primary key Common Code PK is the primary key of supportive entity Common Code
Relationships (optional)
The relationships to one or more entities.
Dependencies to Business Data Model elements (optional)
One or more dependencies to the BDM elements from which this supportive entity originates. This maintains traceability between BDM and AWM. By convention, the name of the dependency is and the dependency type is transformation.