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”.
Cluster/data model
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.
Figure 2: Hierarchy of clusters
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.
Figure 3: Cluster representing an attribute assigned to an entity type
Hello,
Your article is realy nice, i'm happy to now that i was modeling the data architecture in a good way. It should be interesting for people to know how they can map fields in screens with entity attributes.
You know that in a company there is a lot of datas wich needs to be mapped one with each other.
Message with fields in a database or entity attributes
Fields in a form and fields in a database or entity attributes
Fields in a report fields in a database or entity attributes
...
Thank you for your article.
Pierre
Mon, 06/03/2013 - 09:23
Hi Pierre,
your question is „how can I map objects of the “ERM attribute” to objects of type “screen“.
I cannot answer this question without knowing your screen modeling concept. What do you want to do with your screens?
In ARIS you have 3 model types dealing with different aspects of screen modeling: see screen diagram, screen design and screen navigation.
Direct connections between a screen and an ERM attribute are allowed in the “Screen diagram” (and also in process models and the event diagram). Implicite connections can be built if you assign an eERM or an IE data model to a screen object. But as mentioned above, the right answer depends on your screen modeling concept.
Regards
Eva
