=Soutou FM.book Page 1 Vendredi, 16. f vrier 2007 5:56 17 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. © Éditions Eyrolles 1 =Soutou FM.book Page 2 Vendredi, 16. f vrier 2007 5:56 17 UML 2 pour les bases de données 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. 2 ● 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édagogique. 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, © Éditions Eyrolles =Soutou FM.book Page 3 Vendredi, 16. f vrier 2007 5:56 17 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’appliquent à 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’utilisation. 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 relationnelles [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é. © Éditions Eyrolles 3