Profile picture for user Eva Klein

The core object types in the eERM are:

  • Cluster/data model,
  • Entity type,
  • Relationship type,
  • Generalization type.

Their symbols are shown in Figure 1.

Basic object types and symbols in the eERM

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.

Hierarchy of clusters

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.

Cluster representing an attribute assigned to an entity type

Figure 3: Cluster representing an attribute assigned to an entity type


by Pierre Pilven
Posted on Fri, 05/24/2013 - 18:11


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.


by Eva Klein
Badge for 'Community Team' achievement
Posted on 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.



by Klaus Schulz
Posted on Wed, 10/30/2013 - 15:30


I am looking to integrate screens and data models. Can you share your approach?


Is there a 'preferred' or recommended way? And if so, can you share it? Can SAG incorporate such models in the UMG?


Featured achievement

Say hello to the ARIS Community! Personalize your community experience by following forums or tags, liking a post or uploading a profile picture.
Recent Unlocks


icon-arrow-down icon-arrow-cerulean-left icon-arrow-cerulean-right icon-arrow-down icon-arrow-left icon-arrow-right icon-arrow icon-back icon-close icon-comments icon-correct-answer icon-tick icon-download icon-facebook icon-flag icon-google-plus icon-hamburger icon-in icon-info icon-instagram icon-login-true icon-login icon-mail-notification icon-mail icon-mortarboard icon-newsletter icon-notification icon-pinterest icon-plus icon-rss icon-search icon-share icon-shield icon-snapchat icon-star icon-tutorials icon-twitter icon-universities icon-videos icon-views icon-whatsapp icon-xing icon-youtube icon-jobs icon-heart icon-heart2 aris-express bpm-glossary help-intro help-design Process_Mining_Icon help-publishing help-administration help-dashboarding help-archive help-risk icon-knowledge icon-question icon-events icon-message icon-more icon-pencil forum-icon