UML 2 pour les bases de données
96
© Éditions Eyrolles
●
Disposition des attributs dans chaque entité (classe).
●
Détermination d’un identifiant par entité (classe).
●
Recensement des associations et définition du degré : binaire, classe-association ou n-aire.
●
Disposition d’éventuels attributs dans chaque classe-association.
●
Mise en place des contraintes.
●
Vérification par normalisation.
Attention à ne pas surestimer le degré d’une association.
Ne pas réfléchir en terme de fonctionnement ou en termes de traitement, mais simplement
exprimer des faits.
Bilan
Alors que les aspects statiques du niveau conceptuel (entité, classe, association, classe-association,
héritage) se traduisent naturellement sous SQL2 ou SQL3, les contraintes nécessitent un effort
de programmation le plus souvent sous la forme de contraintes SQL de vérification CHECK ou
de déclencheurs. L’aspect dynamique du niveau conceptuel n’est pas natif aux bases de données
et il restera à programmer l’encapsulation par les méthodes.
Les méthodes et outils de conception objet qui permettent de transiter du conceptuel au physique
(spécifications UML traduites automatiquement en classes C++ ou Java) sont bien plus adaptés à
l’élaboration de programmes que de schémas de bases de données. Les principaux inconvénients
de ces démarche sont les suivants :
●
le souci d’intégrité des objets stockés n’est pas suffisamment pris en compte ;
●
la traduction des associations au niveau physique n’est ni clairement décrite, ni totalement
maîtrisée.
UML 2 ou Merise/2 ?
Après avoir examiné différents formalismes : le modèle de Chen, le MCD de Merise/2 et la
notation UML, on est en droit de savoir quel formalisme convient le plus à la modélisation
d’une base de données. La notation UML 2 est bien adaptée à la modélisation d’une base de
données (et si elle est utilisée à bon escient !) pour les raisons suivantes :
●
les bases de données sont majoritairement relationnelles, mais certaines migreront vers l’objet ;
●
les concepts fondamentaux de Merise/2 peuvent être représentés dans le diagramme de
classes d’UML qui offre en plus la possibilité de définir des stéréotypes et des contraintes
personnalisées ;
96
© Éditions Eyrolles
●
Disposition des attributs dans chaque entité (classe).
●
Détermination d’un identifiant par entité (classe).
●
Recensement des associations et définition du degré : binaire, classe-association ou n-aire.
●
Disposition d’éventuels attributs dans chaque classe-association.
●
Mise en place des contraintes.
●
Vérification par normalisation.
Attention à ne pas surestimer le degré d’une association.
Ne pas réfléchir en terme de fonctionnement ou en termes de traitement, mais simplement
exprimer des faits.
Bilan
Alors que les aspects statiques du niveau conceptuel (entité, classe, association, classe-association,
héritage) se traduisent naturellement sous SQL2 ou SQL3, les contraintes nécessitent un effort
de programmation le plus souvent sous la forme de contraintes SQL de vérification CHECK ou
de déclencheurs. L’aspect dynamique du niveau conceptuel n’est pas natif aux bases de données
et il restera à programmer l’encapsulation par les méthodes.
Les méthodes et outils de conception objet qui permettent de transiter du conceptuel au physique
(spécifications UML traduites automatiquement en classes C++ ou Java) sont bien plus adaptés à
l’élaboration de programmes que de schémas de bases de données. Les principaux inconvénients
de ces démarche sont les suivants :
●
le souci d’intégrité des objets stockés n’est pas suffisamment pris en compte ;
●
la traduction des associations au niveau physique n’est ni clairement décrite, ni totalement
maîtrisée.
UML 2 ou Merise/2 ?
Après avoir examiné différents formalismes : le modèle de Chen, le MCD de Merise/2 et la
notation UML, on est en droit de savoir quel formalisme convient le plus à la modélisation
d’une base de données. La notation UML 2 est bien adaptée à la modélisation d’une base de
données (et si elle est utilisée à bon escient !) pour les raisons suivantes :
●
les bases de données sont majoritairement relationnelles, mais certaines migreront vers l’objet ;
●
les concepts fondamentaux de Merise/2 peuvent être représentés dans le diagramme de
classes d’UML qui offre en plus la possibilité de définir des stéréotypes et des contraintes
personnalisées ;