© Éditions Eyrolles
1
Avant-propos
Dans cet avant-propos et dans l’introduction, j’expliquerai pourquoi il convient d’utiliser à
présent UML (Unified Modeling Language) pour concevoir une base de données relationnelle
de type SQL2 ou objet-relationnelle de type SQL3. Dans les chapitres suivants, j’exposerai les
moyens à mettre en œuvre, étape par étape, pour arriver à définir un script SQL à partir d’une
spécification UML 2 sous la forme d’un diagramme de classes.
Rappel
« Une base de données est un ensemble de données évolutives, organisé pour être utilisé par
des programmes multiples, eux-mêmes évolutifs. » (Le Petit Larousse)
Depuis plus de 30 ans, la conception des bases de données est réalisée à l’aide du modèle entitéassociation. Ce modèle a fait ses preuves et la plupart des outils informatiques de conception
(destinés aux concepteurs français) l’utilisent encore aujourd’hui. La notation UML s’est imposée
depuis quelques années pour la modélisation et le développement d’applications écrites dans
un langage objet (C++ et Java principalement). Cette notation n’a pas été initialement pensée
pour les bases de données mais elle permet d’offrir un même formalisme aux concepteurs
d’objets métiers et aux concepteurs de bases de données. Le marché a suivi cette tendance car,
aujourd’hui, tous les outils utilisent cette notation.
Personnellement je considère, et je l’expliquerai, que le diagramme de classes, avec ses caractéristiques, convient bien à la modélisation d’une base de données (relationnelle ou objet-relationnelle). En effet, on retrouve tous les concepts initiaux tout en découvrant de nouvelles
possibilités qui, si elles sont employées à bon escient, n’entravent en rien la normalisation des
schémas SQL dérivés. Lors du face à face entre le modèle entité-association et le diagramme
de classes UML 2 et du rappel des règles de dérivation du conceptuel vers SQL, il n’y aura
qu’un pas à franchir pour passer de UML 2 à SQL.
Bien qu’il existe depuis quelques années des outils informatiques permettant de générer des
scripts SQL à partir d’un schéma conceptuel graphique, il est courant de constater que ces
mêmes scripts (ou les modèles logiques de données), doivent être modifiés manuellement par
la suite, soit pour des raisons d’optimisation, soit parce que l’outil ne permet pas de générer
une caractéristique particulière du SGBD (index, vues, type de données...), soit tout simplement parce que le concepteur préfère utiliser une autre possibilité d’implémentation pour
traduire telle ou telle autre association.
1
Avant-propos
Dans cet avant-propos et dans l’introduction, j’expliquerai pourquoi il convient d’utiliser à
présent UML (Unified Modeling Language) pour concevoir une base de données relationnelle
de type SQL2 ou objet-relationnelle de type SQL3. Dans les chapitres suivants, j’exposerai les
moyens à mettre en œuvre, étape par étape, pour arriver à définir un script SQL à partir d’une
spécification UML 2 sous la forme d’un diagramme de classes.
Rappel
« Une base de données est un ensemble de données évolutives, organisé pour être utilisé par
des programmes multiples, eux-mêmes évolutifs. » (Le Petit Larousse)
Depuis plus de 30 ans, la conception des bases de données est réalisée à l’aide du modèle entitéassociation. Ce modèle a fait ses preuves et la plupart des outils informatiques de conception
(destinés aux concepteurs français) l’utilisent encore aujourd’hui. La notation UML s’est imposée
depuis quelques années pour la modélisation et le développement d’applications écrites dans
un langage objet (C++ et Java principalement). Cette notation n’a pas été initialement pensée
pour les bases de données mais elle permet d’offrir un même formalisme aux concepteurs
d’objets métiers et aux concepteurs de bases de données. Le marché a suivi cette tendance car,
aujourd’hui, tous les outils utilisent cette notation.
Personnellement je considère, et je l’expliquerai, que le diagramme de classes, avec ses caractéristiques, convient bien à la modélisation d’une base de données (relationnelle ou objet-relationnelle). En effet, on retrouve tous les concepts initiaux tout en découvrant de nouvelles
possibilités qui, si elles sont employées à bon escient, n’entravent en rien la normalisation des
schémas SQL dérivés. Lors du face à face entre le modèle entité-association et le diagramme
de classes UML 2 et du rappel des règles de dérivation du conceptuel vers SQL, il n’y aura
qu’un pas à franchir pour passer de UML 2 à SQL.
Bien qu’il existe depuis quelques années des outils informatiques permettant de générer des
scripts SQL à partir d’un schéma conceptuel graphique, il est courant de constater que ces
mêmes scripts (ou les modèles logiques de données), doivent être modifiés manuellement par
la suite, soit pour des raisons d’optimisation, soit parce que l’outil ne permet pas de générer
une caractéristique particulière du SGBD (index, vues, type de données...), soit tout simplement parce que le concepteur préfère utiliser une autre possibilité d’implémentation pour
traduire telle ou telle autre association.