Les principes fondateurs de ORM ont été proposés en 1976 par Falkenberg sous le nom de object-
role model [41]. Ils ont ensuite été étendus par de nombreuses propositions jusqu’à aboutir à ce qu’on
regroupe aujourd’hui sous le terme de ORM ou Object-Role Modeling [51, 52]. ORM est aussi parfois appelé NIAM pour Natural language (ou Nijssen) Information Analysis Method [76].
ORM représente l’information sous la forme d’objets (entités ou valeurs) qui jouent des rôles dans des associations. Contrairement à la majorité des modèles, la notion d’attribut n’existe pas : ils sont remplacés par des associations avec des valeurs.
ORM est parfois qualifié d’approche orientée-faits. En effet, le processus de conception de schémas conceptuels (CSDP pour Conceptual Schema Design Procedure) proposé commence par transformer des exemples de l’information à modéliser en faits élémentaires. Ceux-ci permettent ensuite de créer des types de faits qui correspondent à des associations. Le modèle final est obtenu après plusieurs autres étapes permettant d’ajouter les contraintes et de vérifier la validité du modèle.
Une autre particularité d’ORM est l’accent mis sur la verbalisation. Tous les éléments du modèle peuvent être transformés en des phrases simples en langage naturel, ce qui permet une meilleure com- munication entre le concepteur et son interlocuteur.
4.3.1 Entités et valeurs
Les classes d’entités n’ont pas d’attributs dans le modèle ORM mais ont au moins un schéma de
référence, qui indique comment faire correspondre chaque instance du type d’entités à des valeurs via
des prédicats : (E, {{p11 : T11, . . . , p1n : Tn1}, . . . , {p q 1 : T q 1, . . . , p q m : Tmq}}) avec n ≥ 1 et q ≥ 1
(généralement,q = 1 et n = 1). La notion de clef du modèle E/A peut être traduite par un schéma de référence dans le modèle ORM.
Les attributs au sens E/A étant remplacés par des associations, le modèle ORM introduit aussi la notion de types de valeurs pour les représenter. Un type de valeur n’est composé que d’un nom et d’un type de base :(V, T ).
Les notions de type d’entités et type de valeurs sont regroupées dans la notion plus générale de type d’objets.
Comme illustré par la figure 4.6, les types d’entités sont représentés par des ellipses pleines et les types de valeurs par des ellipses en pointillés. Lorsque le schéma de référence est simple, il peut être indiqué directement en représentant le mode de référence entre parenthèses sous le nom du type d’entités. Les liens de spécialisation / généralisation sont représentés par de simple flèches allant du sous- type vers le super-type. Comme nous pouvons le voir sur le schéma, des contraintes peuvent aussi être représentées. La spécialisation du typeSOURCEest ainsi une partition : les sous-types sont exclusifs et leur union est égale à leur super-type.
4.3.2 Associations
Les associations sont décrites par un nom (optionnel), un ensemble de rôles (obligatoires ou non) et un ensemble de contraintes internes d’unicité :(R, hO1, . . . , Oni, hhOi1, . . . , Oj1i, . . . , hOip, . . . , Ojpii)
avecn ≥ 1, p ≥ 1 et ∀x ∈ [1, p], (ix, jx) ∈ [1, n]2etix≤ jx. De plus, une association ne peut exister si
elle ne fait pas intervenir au moins un type d’entités.
Comme l’illustre la figure 4.6, les associations sont représentées sous la forme de rectangles com- posés d’une case par rôle, et chaque rôle est relié à son type d’objets par une ligne. Le nombre de rôle d’une association correspond à son arité.
CHAPITRE 4 — Famille Entité-Association (E/A) 47 "Concurrence !" Entreprise (SIREN) Marché (nom) dirige Employé (id) concerne Document (URI) a a Site WEB travaille pour Nom a a Taille Type Source (id) Etude Marché Source WEB Source Interne Source Mail Source BD agressivité a fournit
Principaux symboles utilisés :
Type de valeurs Type d’entités
Association
Contrainte de participation Contrainte interne d’unicité
Lien de spécialisation / généralisation Contrainte d’exclusion
Ou exclusif ... et ... sont concurrentes sur ...
Pour indiquer qu’un rôle est obligatoire pour un type d’entités, un point noir est ajouté. Dans ce cas toute instance de ce type doit forcément jouer ce rôle. Une entreprise, par exemple, a forcément un nom, mais l’existence d’un site sur la Toile est optionnelle.
La désignation des associations est particulière. Dans le cas simple, son nom est inscrit dans ou à côté de la case correspondant à son premier rôle. D’autres lectures peuvent cependant être fournies, par exemple une phrase avec un « trou » pour chaque rôle : « . . . et . . . sont concurrentes sur . . . ».
Il n’existe pas de contraintes de cardinalité telles que nous les avons introduites en section 3.2.2. Elles sont ici remplacées par des contraintes internes d’unicité. Une simple flèche au dessus d’un ou plusieurs rôles indique qu’il ne peut pas exister deux instances d’association utilisant le même rôle ou la même combinaison de rôles. Une contrainte de cardinalité1 : n est ainsi transformée en une contrainte interne d’unicité sur le rôle dont la cardinalité est multiple : le même objet ne peut être présent deux fois dans l’association. Pour une cardinalitén : m, la contrainte interne d’unicité est sur le couple de rôle, alors que pour une cardinalité1 : 1, nous aurons une contrainte sur chacun des rôles. Ce mécanisme est plus expressif dès lors que les associations ont une arité supérieure à deux.
Comme le montre l’association de concurrence du schéma, la réification est possible et elle est re- présentée par un cadre arrondi englobant le rectangle. Le nom du nouveau type est alors indiqué entre guillemets. Dans l’exemple représenté, le point d’exclamation indique que le type d’entités est indépen- dant : des instances de ce type peuvent exister sans prendre part à un fait.
4.3.3 Autres particularités
ORM a d’autres particularités par rapport aux modèles E/A et UML. La première d’entre elles étant l’arité des associations. En effet, il est possible en ORM de créer des associations unaires. Dans les autres modèles, cela peut être simulé par des attributs booléens, ou de façon moins directe par des sous- types. L’utilisation d’associations unaires offre cependant l’avantage de pouvoir facilement représenter des contraintes d’inclusion sur le schéma [54]. Nous pouvons par exemple indiquer que tous les fu- meurs sont des personnes susceptibles d’avoir un cancer en créant une contrainte d’inclusion entre deux associations unaireshfumeiethest à risquei.
D’autres contraintes plus complexes, intraduisibles graphiquement dans les modèles E/A et UML, peuvent l’être en ORM (ex. : contraintes d’inclusion jointe) [54].
Une limite que n’ont pas les autres modèles est posée pour la réification : il est impossible de réifier des associations 1 : n (contrainte interne d’unicité sur un seul rôle). En effet, il est toujours possible « d’aplatir » une telle réification sans perte d’information sous la forme de plusieurs associations et de contraintes d’inclusion. Autoriser la réification d’associations 1 : n ne se justifie que dans des cas très particuliers [53].
Pour compléter le modèle correspondant à un schéma, ORM permet de représenter une partie de la population. Les valeurs sont alors indiquées dans des tables de faits qui contiennent une colonne par rôle des associations auxquelles elles correspondent.
4.3.4 Conclusion et limites
ORM met l’accent sur les associations et les rôles qu’y jouent les objets. Il est plus adapté que UML à une modélisation de données (l’implémentation des schémas en relationnel est aisée), mais lui laisse l’avantage dans le domaine applicatif.
On notera qu’il est globalement plus expressif que E/A et UML, mais qu’en contrepartie, les schémas créés sont plus volumineux.
CHAPITRE 4 — Famille Entité-Association (E/A) 49
Comme les modèles précédents, ORM est un outil de conception de schémas et ne leur permet pas d’évoluer une fois instanciés.