The base model distinguishes between entities, attributes, and relationships. Basically, a distinction 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, a business process can be a considered object. 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 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 figure below). 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. In the following, 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, a customer address can be understood as an entity and not as an attribute 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 using connections (see the following figure).

Often, only one direction of reading relationship type names results in viable connections. The example above illustrates the relationship Supplier supplies Part. In the opposite direction, this would read Part supplies Supplier, which is not suitable. If you cannot determine the particular read direction, carefully select superior terms.

Various kinds of relationship types can be distinguished. 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).

There are four different types of relationships (cardinalities):

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 multiple 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 on an entity specifies for 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 poses a different interpretation of cardinality. However, the notation used in this manual allows for clearer specifications, particularly when illustrating relationships between multiple entity types. In order to avoid confusion, Chen's original work is not discussed 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 can be distinguished by assigning role names. The following figure illustrates recursive relationships. 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 figure below).

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 figure below (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.