The base model distinguishes between entities, attributes, and relationships. Basically, a difference is made between type level and occurrence level.

Entities are real or abstract objects that are relevant for the business management tasks being examined.

For example, an object of consideration may be a business process. According to the ARIS breakdown model, the data objects of interest are objects of the environment and objects specifying events. Examples of entities in the Customer order processing process are:

Entities are described in more detail by means of specific attributes (properties). For example, a customer can be specified more precisely by his name, first name, and address.

If similar entities are grouped into sets, these are referred to as entity types, the individual occurrences of which are the entities.

Entities of a similar type can be described by the same attributes. For example, customer Moore and customer Miller are grouped under the Customer entity type; item 4710 and item 4712 are grouped under the Item entity type. Entity types are displayed as rectangles in the ERM (see the following figure). In the following, entity types are indicated by capitalized text.

Attributes are properties describing entity types.

Attribute occurrences are specific values of attributes of individual entities. For example, customer 1235 can be described by attribute occurrences such as Miller, Peter, and Munich. The relevant attributes are Name, First name, and City.

Attributes are usually represented by an oval or a circle. On the following pages, attributes are represented by ovals. The following figure shows examples of attributes for the CUSTOMER entity type.

Entity types and attributes are often hard to distinguish and can sometimes only be determined from the context of the modeling procedure. For example, the customer addresses can be understood as entities and not as attributes of CUSTOMER. In this case, a separate entity type ADDRESS would be modeled with a relationship to CUSTOMER. A helpful criterion for specifying whether you are dealing with an entity type or an attribute is the fact that entities have attributes, while attributes cannot have their own attributes. An attribute that is created in an ERM and is to be described by further attributes later on thus becomes an entity type. Whether or not an object will have relationships with other entity types is another helpful question. If yes, the object under consideration is an entity type as well.

A relationship is a logical link between entities.

Therefore, the existence of relationships directly depends on the existence of entities.

If similar relationships are grouped into sets, these are referred to as relationship types.

For example, a possible relationship type between SUPPLIER and PART is SUPPLIES. In the following text, relationship types are also indicated by capital letters. In an ERM, relationship types are displayed as diamonds and are linked with entity types via connections (see the following figure).

Often, only one direction of reading relationship type names results in viable connections. In the above example, the relationship Supplier supplies Part is to be expressed. In the opposite direction, this would read Part supplies Supplier, which is not suitable. If it is not possible to uniquely determine the read direction, the careful selection of superior terms is required.

Various kinds of relationship types can be differentiated. The distinguishing criteria are the number of entity types linked by relationship types, and the complexity of a relationship.

Thus, unary, binary, or n-ary relationships may exist between entity types.

The complexity or cardinality indicates how many entities of one entity type may be connected with an entity of another entity type.

The relationships to be distinguished are illustrated in the following figure (see Scheer, Business Process Engineering, 1994, p. 34).

Four different types of relationships (cardinalities) can be pointed out:

In a 1:1 relationship, each entity of the first set is assigned to exactly one entity of the second set.

In a 1:n relationship, each entity of the first set is assigned to exactly one entity of the second set, but each entity of the second set may be connected with various entities of the first set.

An n:1 relationship means the same, but in reverse order.

In an n:m relationship, multiple entities of the second set are assigned to each entity of the first set and vice versa.

The cardinalities of the relationship type (Complexity attribute type) are shown at the connections of the entity relationship model.

The cardinality specifies for an entity of the entity type in question the maximum number of relationships of a specific relationship type it may have. In the n:1 relationship shown in the above figure, this means that a company of the COMPANY entity type may have multiple ASSIGNED relationships because a company consists of multiple plants, whereas a specific plant may only have a maximum of one ASSIGNED relationship as it must be uniquely assigned to a company.

Chen's original work interprets cardinality in a different manner. However, the notation used in this manual allows for clearer specifications, particularly when illustrating relationships between multiple entity types. In order to avoid unnecessary confusion, we will not discuss Chen's original work in detail here.

Due to the fact that relationships between entities of one entity type are allowed, two parallel connections may exist between an entity type and a relationship type. These connections may be distinguished by assigning role names. Recursive relationships are illustrated in the following figure. A superior part consists of various subordinate parts. A subordinate part, in turn, may also be used as a component in various superior parts.

Both entity types and relationship types can be described by attributes (see the following figure).

The value ranges of attributes are called domains.

Assignments of domain elements to elements of entity or relationship types are also relationships and can be represented by a connection named accordingly.

A 1:1 relationship must exist between an entity type and at least one domain. The values of this domain uniquely identify individual entities. Therefore, they are called the key attributes of the entity type.

In the example shown in the following figure (see Scheer, Business Process Engineering, 1994, p. 33), the entities of CUSTOMER are uniquely identified by the Customer ID key attribute.

Relationships are identified by merging the key attributes of all linked entities. Thus, the key attributes of the RESIDES AT relationship type are Customer ID and Address ID.

The descriptive attributes of the relevant data objects are defined by values derived from domains having a 1:n relationship to entity types or relationship types.