UML 2 pour les bases de données
66
© Éditions Eyrolles
Contre-exemple
Il n’est pas nécessaire d’utiliser une agrégation pour décrire l’association binaire entre les postes
de travail et les segments (figure 1-10). En effet, un poste de travail peut avoir une existence
propre indépendamment d’un segment et réciproquement.
Règles de validation
Il est très intéressant d’appliquer les règles de validation inspirées des principes de normalisation
du modèle relationnel au niveau du diagramme de classes UML. En l’absence de directives de
la spécification UML en la matière, ces règles permettront d’assurer la cohérence de la base de
données. Elles sont basées sur les propriétés des dépendances fonctionnelles que nous étudierons
au chapitre suivant.
Ces règles préparent correctement le passage à SQL, en limitant les risques d’erreurs de
modélisation lourdes de conséquences au niveau de la base de données. La méthode Merise
avait à l’époque aussi proposé des règles, en amont des problèmes d’implémentation pour
valider des MCD.
Caractère élémentaire d’un attribut
Tous les attributs sont élémentaires dans le sens où ils doivent être non décomposables (exemple
de l’attribut adresse qui serait composé d’un numéro de rue, du nom de la rue, du code postal,
etc. et pour lequel il faudrait définir autant d’attributs que de propriétés).
Vérification
Non-redondance
Un attribut doit apparaître une seule fois dans le diagramme, soit au sein d’une classe, soit
dans une association (ou classe-association).
Dans l’exemple 1-65, l’attribut b apparaît à plusieurs endroits. Il convient de corriger cette
modélisation pour ne garder qu’une occurrence en se posant la question : « de quoi dépend
b ? ». Si b permet de caractériser la classe C1, il devra se trouver dans C1, même chose pour
C2. S’il dépend à la fois des classes C1 et C2, il devra alors se trouver dans C3.
Nous détaillerons plus formellement dans les chapitres suivants cette démarche.
66
© Éditions Eyrolles
Contre-exemple
Il n’est pas nécessaire d’utiliser une agrégation pour décrire l’association binaire entre les postes
de travail et les segments (figure 1-10). En effet, un poste de travail peut avoir une existence
propre indépendamment d’un segment et réciproquement.
Règles de validation
Il est très intéressant d’appliquer les règles de validation inspirées des principes de normalisation
du modèle relationnel au niveau du diagramme de classes UML. En l’absence de directives de
la spécification UML en la matière, ces règles permettront d’assurer la cohérence de la base de
données. Elles sont basées sur les propriétés des dépendances fonctionnelles que nous étudierons
au chapitre suivant.
Ces règles préparent correctement le passage à SQL, en limitant les risques d’erreurs de
modélisation lourdes de conséquences au niveau de la base de données. La méthode Merise
avait à l’époque aussi proposé des règles, en amont des problèmes d’implémentation pour
valider des MCD.
Caractère élémentaire d’un attribut
Tous les attributs sont élémentaires dans le sens où ils doivent être non décomposables (exemple
de l’attribut adresse qui serait composé d’un numéro de rue, du nom de la rue, du code postal,
etc. et pour lequel il faudrait définir autant d’attributs que de propriétés).
Vérification
Non-redondance
Un attribut doit apparaître une seule fois dans le diagramme, soit au sein d’une classe, soit
dans une association (ou classe-association).
Dans l’exemple 1-65, l’attribut b apparaît à plusieurs endroits. Il convient de corriger cette
modélisation pour ne garder qu’une occurrence en se posant la question : « de quoi dépend
b ? ». Si b permet de caractériser la classe C1, il devra se trouver dans C1, même chose pour
C2. S’il dépend à la fois des classes C1 et C2, il devra alors se trouver dans C3.
Nous détaillerons plus formellement dans les chapitres suivants cette démarche.