According to Webster's, the term universal can be defined as "generally applicable" as well as "applying to the whole." There are some very common patterns that can be generally applied in data models to develop higher quality and more holistic designs. Additionally, reusing patterns can save time and effort by providing model structures that have been proven to work well, flexible alternatives that can handle additional future needs and consistent models and structures that facilitate data sharing.
This article will describe a few common patterns that can be used to build "universal" data models, namely patterns for roles, statuses, categorizations.
For each pattern, I will show specific and abstract ways to model these types of constructs. Which one is right? I believe that there are usually not right and wrong data models, but pros and cons of various ways to model data. More specific data models have the advantage of being more easily understood, and they show the enforcement of business rules. More abstract data models have the advantage of flexibility and maintainability since the model is much more adaptable to change. Later in this article, I will discuss when to use a specific versus an abstract pattern.
Roles
Roles represent the part that a party plays, or the "hat" that they wear. There are two types of roles: declarative and contextual. Declarative roles "declare" that a party is playing a particular role, such as a party that is identified and declared as an "employee." Contextual roles show how a party acts within the context of another entity. For example, a party may play a role of product manager within the context of the entity PRODUCT, or a party may play the role of quality assurance manager within the entity PROJECT.
Declarative Roles
Most enterprises maintain information about key entities such as customer, employee, partner, supplier and other roles that are played by people and/or organizations. However, there is often a lack of insight in data models that the role is not the same as the party involved, and there may be information that is related to a party independent of their role.
When we look at ABC Corporation as only a customer, we are sometimes not seeing the whole picture. A party such as ABC Corporation may be a customer of the enterprise, and they may also be a partner and a supplier, as well as many other roles. When we confuse this and just show them as a customer, their information may show up in many places - one for each role they play. By showing that there is a PARTY entity (which may be either a person or an organization), which is distinguished from the party's various roles, we create models that more closely represent reality and thus are more stable.
The models in Figure 1 show a specific pattern for modeling roles and parties as well as an example using this pattern. Each role may be represented by an entity and associated to a PARTY entity. For example, there may be CUSTOMER, SUPPLIER and PARTNER role entities and each are related to a PARTY - so that if the same party is a customer, supplier and a partner, their information (such as their name and contact information) is maintained once.
Figure 1: Specific Declarative Roles Pattern
This specific model is relatively easy to understand, but one of the issues in this model is that one may not be able to identify all the roles that will exist over time. Therefore, as new roles are identified, additional entities are needed for the model. Furthermore, there may be common information for all roles, such as a need to track relationships that exist between any type of roles.
The pattern and example in Figure 2 shows a more flexible data model for declarative roles. The PARTY ROLE entity is an associative entity between a PARTY and a ROLE TYPE. The PARTY ROLE entity is a supertype of the various roles that could occur. It effectively "tags" a party as having one or more role. The ROLE TYPE maintains information on the possible roles that exist, for example, customer, supplier, partner, worker and so on. The left side of the model shows the pattern that any enterprise may use and the right side of this diagram shows an example that may be applicable to some types of enterprises, for example, a manufacturer of products.
Figure 2: Flexible Declarative Roles Pattern
The advantage to this model is that as new roles are discovered over time, the model can more easily accommodate these with the addition of another ROLE TYPE. There may also be information related to a ROLE TYPE such as product pricing dependent on the role that one plays or authorizations based on the role. Please note that the style of modeling shows subtypes as well as a ROLE TYPE entity because some information may be associated with a specific role (e.g. salary for an employee), while other information may be related to a role type in general (pricing discounts or authorizations related to ROLE TYPE).
Contextual Roles
Contextual roles define how a party is (or was) involved within the context of another entity. For example, there could be several roles that people or organizations play within the context of a project. A person or organization may be the sponsor, worker, manager, lead, advisor or quality assurance manager for a project. This may apply to any other entity that has roles such as order, contract, shipment, payment, product and so on. For example, a shipment could have roles of receiver, sender, carrier, approver, entered by and so on.
Be the first to comment on this post using the section below.