UML 2 pour les bases de données
142
© Éditions Eyrolles
L’exemple 2-46 illustre le premier cas en considérant la modélisation de la figure 1-14. En
examinant les cardinalités minimales, on choisira la classe pour éviter de stocker des références
nulles. Au niveau de SQL, cela se traduira par une contrainte CHECK de type NOT NULL sur la
référence.
La deuxième solution de transformation est illustrée à la figure 2-47. Il faudra, au niveau du
code SQL, vérifier que les cardinalités maximales ne dépassent pas 1. Cela se traduira par la
définition de contrainte CHECK de type UNIQUE sur les références.
Transformation de l’héritage
Le mécanisme d’héritage de classes s’apparente naturellement à la décomposition descendante,
(push-down) que nous avons précédemment étudiée. En effet, une sous-classe héritant des
attributs et des méthodes d’une sur-classe est considérée comme une classe à part entière.
L’héritage par distinction ne peut pas s’appliquer à un schéma objet, car tous les attributs d’une
sur-classe sont hérités par la ou les sous-classe(s), alors que la distinction préconise la migration
de l’identifiant seul.
La décomposition ascendante peut à la rigueur s’appliquer. On ne parlera alors plus d’héritage
mais de migration d’attribut et de méthodes d’une classe vers une autre. De plus les méthodes
de la sous-classe pourront être exécutées illégalement sur des objets de la sur-classe.
De même que pour l’héritage simple, la traduction de l’héritage multiple s’apparente naturellement à la décomposition descendante (push-down).
L’exemple 2-48 illustre la traduction d’un graphe d’héritage. Le schéma logique est
composé de trois classes. On peut se représenter ainsi la structure des deux sous-classes :
PNC[numPers, nomPers, indice, prime] et PNT[numPers, nomPers, brevet,
validiteLicence].
Figure 2-46 Transformation avec deux classes
Figure 2-47 Transformation avec trois classes
Stage[nstage, entreprise]
Etudiant[netu, nometu, @ref_stage]
Stage[nstage, entreprise]
Effectue[@ref_stage, @ref_etudiant]
Etudiant[netu, nometu]
142
© Éditions Eyrolles
L’exemple 2-46 illustre le premier cas en considérant la modélisation de la figure 1-14. En
examinant les cardinalités minimales, on choisira la classe pour éviter de stocker des références
nulles. Au niveau de SQL, cela se traduira par une contrainte CHECK de type NOT NULL sur la
référence.
La deuxième solution de transformation est illustrée à la figure 2-47. Il faudra, au niveau du
code SQL, vérifier que les cardinalités maximales ne dépassent pas 1. Cela se traduira par la
définition de contrainte CHECK de type UNIQUE sur les références.
Transformation de l’héritage
Le mécanisme d’héritage de classes s’apparente naturellement à la décomposition descendante,
(push-down) que nous avons précédemment étudiée. En effet, une sous-classe héritant des
attributs et des méthodes d’une sur-classe est considérée comme une classe à part entière.
L’héritage par distinction ne peut pas s’appliquer à un schéma objet, car tous les attributs d’une
sur-classe sont hérités par la ou les sous-classe(s), alors que la distinction préconise la migration
de l’identifiant seul.
La décomposition ascendante peut à la rigueur s’appliquer. On ne parlera alors plus d’héritage
mais de migration d’attribut et de méthodes d’une classe vers une autre. De plus les méthodes
de la sous-classe pourront être exécutées illégalement sur des objets de la sur-classe.
De même que pour l’héritage simple, la traduction de l’héritage multiple s’apparente naturellement à la décomposition descendante (push-down).
L’exemple 2-48 illustre la traduction d’un graphe d’héritage. Le schéma logique est
composé de trois classes. On peut se représenter ainsi la structure des deux sous-classes :
PNC[numPers, nomPers, indice, prime] et PNT[numPers, nomPers, brevet,
validiteLicence].
Figure 2-46 Transformation avec deux classes
Figure 2-47 Transformation avec trois classes
Stage[nstage, entreprise]
Etudiant[netu, nometu, @ref_stage]
Stage[nstage, entreprise]
Effectue[@ref_stage, @ref_etudiant]
Etudiant[netu, nometu]