uml 2 pour les bases de donnees eyrolles bibliolivre com

http://bibliolivre.com
Télécharger la version complète Sur http://bibliolivre.com

© É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 carac-
téristiques, convient bien à la modélisation d’une base de données (relationnelle ou objet-rela-
tionnelle). 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 simple-
ment parce que le concepteur préfère utiliser une autre possibilité d’implémentation pour
traduire telle ou telle autre association.
=Soutou FM.book Page 1 Vendredi, 16. f vrier 2007 5:56 17
Télécharger la version complète Sur http://bibliolivre.com

UML 2 pour les bases de données
2© Éditions Eyrolles
Il semble donc préférable de maîtriser des concepts et une démarche plutôt que de connaître
les caractéristiques d’un outil en particulier. Cela n’empêchera pas, bien au contraire, d’utiliser
l’outil de manière optimale. C’est pour cela que cet ouvrage détaille d’une part comment
construire un modèle conceptuel sous la forme d’un diagramme de classes, et d’autre part
énonce des règles précises de transformation entre les différents niveaux d’abstraction qui
interviennent dans la conception d’une base de données. Cette démarche pourra ainsi servir de
base théorique à l’utilisation des différents outils du marché.
À qui s’adresse cet ouvrage ?
Cet ouvrage s’adresse aux personnes qui s’intéressent à la modélisation et à la conception des
bases de données.
●Les concepteurs habitués au modèle entité-association (que ce soit la notation américaine
ou celle de type Merise/2) y trouveront les moyens de migrer vers le diagramme de classes
de UML 2.
●Les concepteurs UML repéreront des règles de passage afin de traduire un diagramme de
classes dans un modèle de données d’une base de données relationnelle ou objet-relationnelle.
●Les programmeurs connaissant le modèle relationnel et SQL2 découvriront l’influence de
l’approche objet sur les bases de données, et les mécanismes de programmation mettant en
œuvre les types abstraits de données avec SQL3.
●Les étudiants dénicheront des définitions pragmatiques et de nombreux exercices mettant
en jeu tous les niveaux du processus de conception d’une base de données.
Ouvrages relatifs à UML et aux bases de données
Lors de la sortie de la première version de cet ouvrage (juin 2002), il n’existait que peu d’ouvrages
relatifs à l’utilisation d’UML pour la conception de bases de données.
●Oracle8 Design Using UML Object Modeling [DOR 99], axé sur une implémentation sous
Oracle, couvre la traduction de toutes les catégories d’associations UML en SQL2 et avec
les caractéristiques objet-relationnelles d’Oracle pour certaines. Il n’est pas organisé
autour des niveaux d’abstraction comme ce présent ouvrage. La connaissance d’UML est
un prérequis pour cet ouvrage qui est assez austère (Oracle Press oblige…) et pas très péda-
gogique. De plus, pour chaque type d’association, une seule solution d’implémentation est
donnée.
●Database Design for Smarties [MUL 99] comporte un chapitre sur le diagramme de classes
et des règles de passage aux modèles relationnel et objet-relationnel. Très verbeux,
=Soutou FM.book Page 2 Vendredi, 16. f vrier 2007 5:56 17

© Éditions Eyrolles 3
Avant-propos
manquant d’exemples et de précisions à propos des associations n-aires, il était toutefois
assez complet.
●UML for database design [NAI 01], écrit par deux pointures de la société Rational Software
(société rachetée par IBM en 2001), est basé sur une étude de cas fictive de la gestion d’une
clinique de rééducation (bonjour la joie…). Il s’agit de l’analyse de l’existant à la définition
des classes UML et des tables représentées à l’aide du profil UML pour les bases de données
créées par Rational (un profil est une proposition d’une communauté et regroupe un ensemble
d’éléments UML tels que des composants, stéréotypes, icônes, propriétés, etc. qui s’appli-
quent à un contexte particulier et qui conservent le métamodèle d’UML intact). Nous
détaillerons au chapitre 5 le profil UML pour la conception de bases de données. Il n’était
pas question de SQL dans UML for database design qui s’axe plutôt vers la représentation
de la dynamique d’un système avec de nombreux diagrammes d’activités et de cas d’utili-
sation. En effet, seules quatre pages sur près de trois cents sont consacrées au passage d’un
modèle de classes à un modèle de données relationnel. La connaissance d’UML et des
principes des conceptions d’une base de données sont un prérequis pour cet ouvrage.
●Information Modeling and Relational Database [HAL 01] consacre un chapitre entier
(50 pages sur 760) au comparatif de la notation UML et du modèle qu’il préconise dans
son ouvrage : ORM (Object Role Model).
Citons aussi ceux qui passaient sous silence cette notation : Conception de bases de données
[STE 01], The Data Model Resource Book [SIL 01] et Conception des bases de données rela-
tionnelles [AKO 01] basé sur le modèle entité-relation étendu.
Cinq ans après la sortie de la première version de cet ouvrage, pas grand-chose de vraiment
nouveau dans la littérature actuelle, si ce n’est le fait de citer le diagramme de classes de UML
soit en quelques lignes, soit en quelques pages, soit, exceptionnellement, faisant l’objet seul
d’un chapitre :
●Bases de données et modèles de calculs [HAI 04] présente en 6 pages (sur 435) le
diagramme de classes sans préconiser de solution d’implémentation.
●Systèmes de bases de données [CON 05] se sert de la notation UML (16 pages sur 1412)
uniquement pour présenter le concept de spécialisation/généralisation dans le cadre de la
modélisation entité-association étendue.
●Conception et architecture de bases de données [ELM 04] ne consacre que 7 pages (sur 728)
à l’outil de Rational Rose en ne le présentant qu’au niveau logique (notation relationnelle).
●Data Modeling Essentials [SIM 05] traite de UML en seulement 7 pages également (sur
532), on y apprend principalement à éviter les associations qualifiées (je n’en parle pas non
plus dans cet ouvrage).
●Création de bases de données [LAR 05] ne consacre que 3 pages (sur 190) au diagramme
de classes sans décrire précisément ses possibilités.
Aucun de ces ouvrages n’étudie en détail les possibilités conceptuelles offertes par UML
ni l’adéquation de UML avec les outils de modélisation du marché.
=Soutou FM.book Page 3 Vendredi, 16. f vrier 2007 5:56 17

UML 2 pour les bases de données
4© Éditions Eyrolles
Guide de lecture
Cet ouvrage s’organise en quatre chapitres. L’introduction développe cet avant-propos. Les
chapitres 1 et 2 traitent de modélisation et de normalisation avec UML 2. Le chapitre 3 est
consacré à l’implémentation sous SQL2 et SQL3. Le chapitre 4 valide ma démarche en la
comparant aux solutions des outils du marché.
La figure suivante illustre les différents chapitres par rapport aux niveaux d’abstraction d’un
processus de conception. Elle peut ainsi servir de guide schématique à la lecture de ce livre
(merci à http://www.iconarchive.com).
Le niveau externe qui correspond à la définition de vues sort quelque peu du cadre de cet
ouvrage, le lecteur trouvera aisément des ressources à propos de ce sujet (SQL pour Oracle
aux éditions Eyrolles pour les vues SQL2, Programmer objet avec Oracle aux éditions Vuibert
pour les vues SQL3).
Conception et normalisation
Le chapitre 1 décrit la première étape du processus de conception d’une base de données, à
savoir la construction d’un schéma conceptuel normalisé. Nous réalisons un face à face entre
le modèle entité-association et le diagramme de classes UML.
Guide de lecture
Scripts
SQL2 ou SQL3
Niveau externe
Niveau conceptuel
Chapitre 1
Niveau physique
Chapitre 3
Niveau logique
Chapitre 2
Univers à modéliser
Notation relationnelle
Relation( a , b…)… ou
ou
Vues
SQL2 ou SQL3
UML
UML
Entité-association
=Soutou FM.book Page 4 Vendredi, 16. f vrier 2007 5:56 17