The core object types in the eERM are:
- Cluster/data model,
- Entity type,
- Relationship type,
- Generalization type.
Their symbols are shown in Figure 1.
Figure 1: Basic object types and symbols in the eERM
The other object types, i.e. ERM attributes and their domains (see lowest level in Hierarchy of ER object types figure in my post about the ER Model types in ARIS), are discussed in a separate article which describes the model type “eERM attribute allocation diagram”.
Clusters are not part of Chen´s “original” ER diagram, they were discussed for the first time at conferences and in technical papers in the middle of the 1980´s when ER modeling was applied to design really large integrated enterprise-wide data models. It was nearly impossible to obtain a general overview and to perceive the global context of an enterprise data model [FeMi86][TWB89].
Clustering has been proposed as an approach to combine entity and relationship types that belong together according to a specific criterion/perspective, and to represent the respective parts of the model by a higher level object. Thus, clustering is a kind of view building. Model readers who are interested in different aspects of a data model build different clusters of the same underlying data model.
This is the main reason why clusters are used in ARIS to represent business information in business process models. They represent those parts of an underlying data model whose detailed structure is irrelevant and often unknown for the business expert.
A higher level cluster may consist of several (at least 2) lower-level clusters because clustering is an iterative process. At the lowest level a cluster is made up of one or more entity or relationship type. The following modeling examples underline these explanations.
Direct connection types between clusters (“is linked to”) are allowed in ER models, but they are not often used.
The assignment relationship “consists of” which is automatically established when an ER diagram is assigned to a cluster is mandatory to build up the hierarchy between a cluster and its components.
In Figure 3 the cluster “Customer ID” represents an attribute – an object at the lowest level of detail in data modeling. An attribute always refers to an entity or relationship type on the next higher level, it is never directly assigned to a cluster (see Hierarchy of ER object types figure in my post about the ER Model types in ARIS). For that reason it is suggested to model the attribute together with the entity or relationship type it refers to. Unfortunately, this rule is not enforced by ARIS.