Eva Klein's picture

The eERM attribute allocation diagram plays a special role: it cannot be used to model data structures in terms of relationships between entity types. Its purpose is to assign attributes to the structural elements (entity types and relationship types, if available) and thus to reduce the complexity of ER models.

An eERM attribute allocation diagram is assigned to exactly one entity type (or relationship type). The assignment relation

I recommend to insert the respective object as an occurrence copy in the model and to use the object name as model name, too.

ERM attributes

ERM attributes are used to describe characteristics of entity types (or relationship types). ERM attributes have a name, and they are “atomic”, i.e. attributes cannot be broken down into other elements. They always refer to an entity type (or relationship type), they cannot exist “stand-alone”.

Attributes are typically differentiated in 3 types:

  • key attributes
  • foreign key attributes
  • descriptive attributes

As shown in Figure 1, ARIS provides three different symbols and connection types to distinguish them. The connection types are determined by the attribute symbols – they are symbol-dependent:

  • is primary key for
  • is foreign key for
  • is describing for

Different attribute symbols and their connection types

Figure 1: Different attribute symbols and their connection types

A key attribute identifies an entity; it must be unique. Examples are: Customer ID, Employee number, Product No.

A descriptive attribute represents a „normal“ characteristic of an entity. It must not be unique. Examples are: Product name, Price, Quantity, Status, Transaction volume.

A foreign key attribute references the key attribute of another related entity type. Example: „Product ID“ and „Sales order ID“ in entity type „Sales order position“ (see "Re-interpreted relationship type in the eERM" figure in my post about the Entity type) .

The usage of foreign key attributes in ER models is discussed very controversially in theory and practice. The fact is, they need not be explicitly displayed in a conceptual data model, they can be derived by analyzing the relationship types and their cardinalities.