UML 2 pour les bases de données
162
© Éditions Eyrolles
Avantages et inconvénients
Les collections privilégient l’accès aux données via une table au détriment d’une autre. Considé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’interrogation. 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 fonctionnalité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.
Les solutions les plus relationnelles
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.
Contraintes du niveau conceptuel
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.
Tableau 2.6 Correspondances objet/relationnel
Association
Modèle navigationnel
un-à-un
solution 2
un-à-plusieurs
solution 3
plusieurs-à-plusieurs
solution 1
n-aire
solution 1
162
© Éditions Eyrolles
Avantages et inconvénients
Les collections privilégient l’accès aux données via une table au détriment d’une autre. Considé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’interrogation. 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 fonctionnalité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.
Les solutions les plus relationnelles
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.
Contraintes du niveau conceptuel
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.
Tableau 2.6 Correspondances objet/relationnel
Association
Modèle navigationnel
un-à-un
solution 2
un-à-plusieurs
solution 3
plusieurs-à-plusieurs
solution 1
n-aire
solution 1