Deux relations en liaison

Le tableau 2.2 décrit les cardinalités maximum potentielles des associations d’agrégation à partir de deux relations en liaison. Nous avons numéroté les schémas relationnels en lettres majuscules italiques (A, B, C). Le cas C traite des références inverses, par conséquent ce schéma peut exprimer soit deux associations d’agrégation distinctes (cas 5, 6, 7, 8) soit une seule association d’agrégation (cas 9).Le tableau décrit les cardinalités maximales potentielles des associations d’agrégation à partir de trois relations en liaison avec le degré des clés primaires inférieur à trois (nombre d’attri- buts composant la clé primaire). Les cas F et G traitent des références inverses, par conséquent ces schémas peuvent exprimer soit deux associations d’agrégation distinctes, soit une seule association d’agrégation (cas 18 pour le cas F et 23 pour le cas G).Le tableau suivant décrit les cardinalités maximales potentielles des associations d’agrégation à partir de trois relations en liaison avec le degré des clés primaires égal à trois (nombre d’attributs composant la clé primaire). Le cas I traite de références inverses, par conséquent ce schéma peut exprimer soit deux associations d’agrégation distinctes soit une seule association d’agrégation (cas 36).Nous décrivons dans cette section le processus de passage d’un schéma conceptuel (entité- association ou UML) au modèle objet. Pour chaque association du schéma conceptuel, nous préconisons des transformations dans le modèle objet, qui faciliteront par la suite la déclaration du script SQL3 de la base de données.

La deuxième solution met en œuvre une collection qui contient les attributs de l’association et une référence. L’accès aux données est privilégié par la classe qui héberge la collection. Dans l’exemple 2-74, la collection coll contient l’attribut c et la référence refC1.On recense n+1 possibilités de transformation d’une association n-aire du modèle conceptuel dans le modèle objet. Il est possible de privilégier chaque entité/classe qui compose l’associa- tion n-aire ou de n’en privilégier aucune (par la solution universelle).Chacune des autres solutions privilégie une des classes qui contiendra une collection incluant les attributs de l’association et n-1 références. L’exemple 2-76 illustre la traduction de l’association n-aire A qui contient l’attribut d et est reliée à n entités/classes. Ici la classe C1 est privilégiée.Les collections privilégient l’accès aux données via une table au détriment d’une autre. Consi- dérons l’exemple 2-76, l’accès aux données est privilégié par la classe C1. La requête qui extrait les attributs des classes C2 à Cn en fonction d’un objet C1 donné sera immédiate. L’utilisation de références simplifie l’expression des requêtes dans le langage d’interro- gation. En ce sens, il est intéressant d’utiliser la solution universelle, même si ce n’est pas la panacée.

Le problème des références, c’est qu’elles ne fournissent pas encore totalement les fonction- nalités des clés étrangères. L’intégrité référentielle est à programmer explicitement. De plus, il n’est pas encore possible d’exprimer certaines contraintes sur une référence (comme définir un index de type clé primaire sous Oracle). L’avenir nous dira comment vont évoluer ces techniques quand même prometteuses.Le tableau 2.6 indique la solution du modèle objet la plus proche d’une solution relationnelle classique. Par exemple, dans le cadre d’une association un-à-plusieurs, le modèle relationnel impose l’utilisation d’un attribut de type clé étrangère dans la table fils référençant la table père. La solution la plus proche au niveau navigationnel est la troisième, c’est-à-dire celle qui met en œuvre une référence.Ces contraintes seront réellement prises en compte au niveau de l’implémentation des méthodes. Il est difficile de déterminer à ce niveau la classe qui hébergera la méthode. Tout dépend du SGBD qui rendra certains cas de figure impossibles. Par exemple, Oracle (version 10g R2) ne permet pas de programmer un déclencheur (trigger) sur une collection (nested table). En conséquence, des méthodes seront probablement déplacées dans d’autres classes lors de l’implantation.Considérons la contrainte de partition qui impose à tout pilote d’être affecté soit à un exercice d’entraînement, soit à une mission sanitaire. Lors de la création (ou modification) d’un objet Pilote, il faudra s’assurer que ledit objet est relié soit à un objet Sanitaire, soit à un objet Entrainement. Ici deux associations un-à-plusieurs sont à contraindre.