Il est recommandé d’affiner vos associations n-aires de façon à préciser la sémantique du schéma et à améliorer l’intégrité de la base de données. Les concepteurs qui n’utilisent pas ces concepts produisent en fait bien plus de programmation (qui pourrait être allégée par des clés étrangères induites par l’adoption de techniques que nous allons présenter).
Pour préciser une association n-aire, vous pouvez soit :
● utiliser une ou plusieurs contraintes d’unicité ;
● utiliser une ou plusieurs contraintes d’inclusion ;
● combiner ces deux types de contraintes.
Avec un formalisme de type entité-association, on utilise une CIF (ou une association d’agré-gation). Sous UML, on peut recourir aux multiplicités et aux classes-associations. Dans les exemples qui suivent, nous ne considérons que des associations 3-aires. Il est bien sûr possible d’appliquer ce raisonnement à des associations de degré supérieur.
Employe Entreprise
assistant *
* 0..1
{self.chef ->isEmpty() or
self.employeur=self.boss.employeur } technicien employeur
chef 1
Contrainte d’unicité sur une association n-aire Merise/2
La contrainte d’unicité sur une association n-aire indique que pour toute occurrence de (n-1) entité(s) il y a une seule occurrence de l’autre entité.
Revenons à l’installation des logiciels sur des serveurs réalisée sur l’initiative de départements.
Ajoutons la contrainte qu’un logiciel acheté par un département ne doit être installé que sur un seul serveur. Avec le formalisme Merise, l’association 1-27 n’exprime pas de contrainte d’unicité. La contrainte qu’il convient de définir sur l’association Installation indique que pour un couple (logiciel, département), un seul serveur est associé. La figure 1-52 décrit le formalisme Merise/2 de [PAN 94].
L’autre possibilité consiste à utiliser une CIF sur le lien d’association connecté à l’entité concernée par l’unicité (ici Serveur), et terminer ce lien par une flèche. L’explication provient de la notion de dépendance fonctionnelle (étudiée à la section Règles de validation et au chapitre 2) : ici, la dépendance fonctionnelle induite par la contrainte d’unicité est nomlogi,codedept→nomserv. Cette dépendance exprime le fait que pour un logiciel et un département donnés correspond au plus un serveur.
Notation UML
La contrainte d’unicité sur une association n-aire se note par une multiplicité maximale valant 1 quand l’association est modélisée par le symbole losange, sinon par une classe-association.
Il est préférable d’utiliser les classes-associations qui font apparaître moins d’éléments sur le diagramme. Par ailleurs, cette solution est mieux adaptée aux associations avec attributs et est plus proche de l’implémentation de la base de données.
Figure 1-52 Contrainte d’unicité sur une association 3-aire Merise/2
Logiciel
Unicité par multiplicité
L’exemple 1-53 modélise la contrainte d’unicité exprimant qu’un représentant de commerce visite un seul secteur à une période donnée (période identifiée par un numéro et étant bornée entre deux dates). On désire connaître le nombre de contrats que le commercial enregistre lors de chaque visite.
Unicité avec une classe-association
Modélisons le cas précédent à l’aide de la classe-association 1-54. La classe-association et sa multiplicité 1 du côté de la classe Secteur modélise la contrainte d’unicité. Ce schéma est plus proche de l’implémentation que la solution précédente dans le sens où il est visible que la table Serveur doit jouer un rôle de clé étrangère pour identifier la colone nbContrats alors que les tables VRP et Periode doivent jouer le rôle de clé primaire.
Figure 1-53 Contrainte d’unicité par multiplicité
Figure 1-54 Contrainte d’unicité avec une classe-association Periode
Contrainte d’inclusion sur une association n-aire
Nous verrons, sur la base d’exemples, qu’une contrainte d’inclusion sur une association n-aire peut être modélisée dans le formalisme entité-association par :
● une association d’associations, appelée aussi « pseudo-entité » (car il s’agit d’entité sans identifiant mais reconnue à l’aide des entités connectées à l’association) [ACS 90] ou
« association d’agrégation » [CHR 87] (car il s’agit de relier une entité à un groupement d’autres entités).
● une entité faible et par l’identification relative, c’est le choix de la méthode Merise et des outils du marché.
Association d’association
Aussi appelée « association d’agrégation » dans le modèle entité-association, l’association d’associations n’a pas de rapport direct avec le concept d’agrégation de la notation UML et que nous détaillerons ultérieurement. En revanche, l’association d’agrégation du modèle entité-association est pratique car analogue aux classes-entité-associations de la notation UML. Le seul bémol est que la majorité des outils ne la programment pas.
Nous décrirons à la section Associations d’agrégation l’analogie avec UML, et dans le chapitre suivant, les moyens de dériver un modèle logique de données en fonction des multiplicités.
Revenons aux installations de logiciels (figures 1-24 et 1-52) et ajoutons la contrainte d’inclusion suivante : une installation est valide à condition que le département ait acheté le logiciel.
Figure 1-55 Association d’agrégation
Serveur ou plusieurs achats »
Le diagramme 1-55 décrit à la fois :
● La contrainte d’unicité à l’aide du couple de cardinalités (0,1) entre l’association Achat appelée « agrégat » et l’entité Serveur (il s’agit de rendre compte qu’un logiciel d’un département doit être installé sur un seul serveur) – définition d’agrégat selon le Larousse :
« substance, masse formée d’éléments primitivement distincts, unis intimement et solidement entre eux ».
● La contrainte d’inclusion à l’aide de l’association d’agrégation Installation qui relie l’entité Serveur à l’agrégat.
Si la contrainte d’unicité n’avait pas lieu d’être, les cardinalités devraient être (0,N) du côté de l’agrégat.
Notation UML
UML propose le concept de classe-association qui convient parfaitement à la modélisation de contrainte d’inclusion sur une association n-aire.
L’exemple 1-56 décrit la contrainte d’inclusion par l’existence même de la classe-association Achat. Notons que ce diagramme inclut aussi une contrainte d’unicité de par la multiplicité 1 du côté de la classe Serveur. Si cette contrainte n’avait pas lieu d’exister, la multiplicité deviendrait *.
Entités faibles de Merise
Une entité faible est formalisée comme une entité mais son identification s’effectue en totalité par rapport aux entités de sa collection (comme une association).
Figure 1-56 Contrainte d’inclusion avec UML
Departement codedept nomdept budget
Logiciel
Serveur nomserv typeserv
* 1
Achat dateachat dateinstall
*
*
Installation nomlogi
editeur
Dans notre exemple, le passage du verbe « acheter » au nom « achat » est un peu révélateur de la nécessité d’utiliser une entité faible. Ce phénomène a été appelé réification. Nous détaillerons plus loin la problématique d’identification et son incidence sur la réification qu’a développée D. Nanci à ce sujet.
L’exemple 1-57 illustre l’entité faible Achatidentifiée à la fois par les attributs nomlogi et codedept. Différents formalismes ont été proposés pour caractériser le lien d’identification des entités faibles, nous présentons celui de l’outil Win’Design (symbole R).