Le modèle de base fait une distinction entre les entités, les attributs et les relations. Le niveau de type peut fondamentalement être distingué du niveau de valeur.
Les entités sont des objets réels ou abstraits, qui présentent un intérêt pour la partie considérée des tâches exécutées au sein d'une entreprise.
Ainsi, un processus d'entreprise peut être un objet pris en compte. Les objets de données intéressants sont alors, selon le modèle de décomposition d'ARIS, les objets du cadre et les objets qui spécifient les événements. Voici des exemples d'entités d'un processus Traitement de la commande client :
Les entités sont décrites plus précisément par des attributs (propriétés) déterminés. Un client peut donc être spécifié plus précisément par son nom, son prénom et son adresse.
Si des entités similaires sont regroupées en quantités, elles sont appelées types d'entités et leurs différentes valeurs sont les entités.
L'appartenance d'entités à une même catégorie peut être décrite par des attributs identiques. Le client Dupont et le client Durant peuvent être regroupés sous le type d'entité Clients, et l'article 4710 ainsi que l'article 4712 sous le type d'entité Article. Les types d'entités sont représentés par des rectangles dans le modèle ERM (cf. figure ci-dessous). Les types d'entités sont caractérisés par du texte en majuscules dans le paragraphe suivant.
Les attributs sont des propriétés permettant de décrire les types d'entités.
Les valeurs d'attributs sont des valeurs concrètes d'attributs de différentes entités. Par exemple, le client 1235 peut être décrit par les valeurs d'attributs Durant, Eric, Strasbourg etc. Les attributs correspondants sont Nom, Prénom et Domicile.
En règle générale, les attributs sont représentés par un ovale ou un cercle. Ci-dessous, nous utiliserons l'ovale comme moyen de représentation. La figure suivante affiche par exemple des attributs pour le type d'entité CLIENT.
Une différenciation entre les types d'entités et les attributs est souvent très difficile et peut uniquement être faite dans le contexte de la modélisation. L'adresse d'un client peut donc par ex. être regroupée en une entité et non pas en attribut de CLIENT. Dans ce cas, un type d'entité propre, ADRESSE, avec une relation vers CLIENTS, serait modélisé. Pour déterminer s'il s'agit d'un type d'entité ou d'un attribut, une caractéristique de différenciation simple existe : les entités possèdent des attributs, mais les attributs n'en possèdent pas. Donc, si un attribut est créé dans un MER que l'on souhaite décrire plus tard par d'autres attributs, il deviendra un type d'entité. Il est également pertinent de se poser la question suivante : Souhaitez-vous créer des relations entre un objet et d'autres types d'entités ? Si c'est le cas, l'objet considéré est également un type d'entité.
Une relation est une connexion logique entre des entités.
Les relations ne peuvent donc exister que si des entités existent aussi.
Si des relations similaires sont regroupées en quantités, ces relations sont appelées types de relations.
Un type de relation entre FOURNISSEUR et PIECE pourrait par ex. s'appeler FOURNIT. Les types de relations sont également écrits en majuscules dans le texte suivant. Dans le MER, les types de relations sont représentés par un losange et reliés aux types d'entités par des liaisons (cf. figure suivante).
Lors de la désignation des types de relations, il n'est pas rare que seule une direction de lecture puisse entraîner des connexions pertinentes. L'exemple ci-dessus illustre la relation Fournisseur fournit pièce. Dans le sens de lecture inverse, le résultat serait Pièce fournit fournisseur, ce qui n'aurait aucun sens. S'il est impossible de déterminer le sens de lecture spécifique, veuillez sélectionner attentivement les termes supérieurs.
Il existe différentes catégories de types de relations. Les caractéristiques de différenciation sont, d'une part, le nombre de types d'entités qui les relient et d'autre part, le degré de complexité d'une relation.
Le nombre des types d'entités connectés par un type de relation peut être différencié par des relations à 1, 2 ou n chiffres.
Le degré de complexité ou la cardinalité indique le nombre d'entités d'un type d'entité qui peuvent être en relation avec une entité d'un autre type d'entité.
Les relations à différencier sont illustrées dans la figure suivante (cf. Scheer, Wirtschaftsinformatik 1994, p. 34).
Il existe quatre types de relations différents (cardinalités) :
Dans le cas d'une relation 1:1, chaque entité de la première quantité se voit attribuer exactement une entité de la deuxième quantité.
Une relation 1:n exprime que chaque entité de la première quantité se voit attribuer exactement une entité de la deuxième quantité, chaque entité de la deuxième quantité peut malgré tout posséder des relations vers plusieurs entités de la première quantité.
La relation n:1 exprime la même chose mais dans le sens inverse.
Si plusieurs entités de la seconde quantité sont affectées à chaque entité de la première quantité et inversement, la relation est une relation n:m.
Les cardinalités du type de relation (type d'attribut Degré de complexité) sont écrites aux liaisons du modèle entité-relation.
La cardinalité d'une entité indique, pour le type d'entité en question, le nombre maximum de relations d'un type de relation spécifique qu'elle peut avoir. Dans l'exemple de la relation n:1 de la figure ci-dessus, une entreprise du type d'entité ENTREPRISE peut apparaître dans plusieurs relations AFFECTE, car une entreprise est composée de plusieurs sites ; en revanche, un site concret peut être associé au maximum à une relation AFFECTE, il doit donc être affecté univoquement à une entreprise.
l'ouvrage original de Chen indique une nouvelle interprétation de la cardinalité. Mais la notation représentée ici permet des formulations plus univoques, surtout lors de la représentation de relations entre plusieurs types d'entités. Afin d'éviter toute confusion, l'ouvrage original de Chen n'est pas discuté en détails ici.
Etant donné que des relations peuvent exister entre différentes entités d'un type d'entité, il est possible de représenter deux liaisons parallèles entre un type d'entité et un type de relation. Des noms de rôles peuvent alors être attribués aux liaisons pour permettre de les différencier. Un exemple de relations récursives est illustré dans la figure suivante. Une partie supérieure est composée de plusieurs parties inférieures, Une partie inférieure, en revanche, peut également être utilisée comme composant dans plusieurs parties supérieures.
Les types d'entités ainsi que les types de relations peuvent être décrits par des attributs (cf. la figure suivante).
Les plages de valeurs des attributs sont appelées domaines.
Les affectations des éléments du domaine aux éléments des types d'entités et de relations représentent également des relations ; elles peuvent être représentées par une liaison caractérisée par le nom.
Il doit exister une relation 1:1 entre un type d'entité et au moins un domaine. Les valeurs de ce domaine identifient de manière univoque les différentes entités. C'est pourquoi elles sont aussi nommées attribut clé du type d'entité.
Dans l'exemple de la figure suivante (cf. Scheer, Wirtschaftsinformatik 1994, page 33), les entités de CLIENT sont identifiées de manière univoque grâce à l'attribut clé Numéro client.
Les relations sont identifiées par la fusion des attributs clé des entités connectées. Les attributs clé du type de relation HABITER sont donc le numéro client et le numéro adresse.
Les valeurs de domaines ayant une relation 1:n aux types d'entités ou de relations définissent les attributs descriptifs des différents objets de données.