Avant-propos

=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


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,



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é.


3



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). Guide de lecture

Univers à modéliser Niveau externe Entité-association

ou

UML

Niveau conceptuel Chapitre 1

Niveau logique Chapitre 2

Notation relationnelle

UML

Relation(a, b…)… ou Vues SQL2 ou SQL3 Niveau physique Chapitre 3

Scripts SQL2 ou 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.

4



Avant-propos

Le chapitre 2 expose les règles de dérivation d’un modèle conceptuel dans le modèle de données relationnel (ou objet-relationnel). Nous rappelons aussi les principes de normalisation, qui permettent de préparer correctement un diagramme de classes à sa traduction en langage SQL.

Programmation SQL2 et SQL3 Le chapitre 3 détaille la traduction d’un modèle de données relationnel en script SQL2 et celle d’un modèle objet-relationnel en langage SQL3. Nous décrivons également les moyens de programmer les différentes contraintes d’un schéma conceptuel.

Outils du marché Le chapitre 4 valide la démarche théorique de l’ouvrage en la comparant aux offres des principaux outils informatiques du marché. L’étude comparative confronte 14 logiciels (Enterprise Architect, MagicDraw, MEGA Designer, ModelSphere, MyEclipse, Objecteering, Poseidon, PowerAMC, Rational Rose Data Modeler, Together, Visio, Visual Paradigm, Visual UML et Win’Design). Chaque outil est évalué selon la qualité dont il dispose à implémenter différents critères de UML 2 (associations binaires, n-aires, classes-associations, agrégations, contraintes inter-associations, héritage multiple avec contrainte et rétroconception d’une base de données).

Annexes Les annexes contiennent une webographie et une bibliographie. L’index recense les termes utilisés dans la définition des concepts et instructions SQL, ce qui permettra au lecteur de faire rapidement le parallèle entre les concepts et la programmation.

Site Web Les corrigés détaillés des exercices et les errata sont mis en ligne sur http://www.soutou.net/ christian/livres/UML2BD/Complements.html.

Conventions typographiques La police courrier est utilisée pour souligner les instructions SQL, noms de variables, tables, contraintes, etc. (ex : SELECT nom FROM Pilote). De plus, nous employons les majuscules pour les directives SQL et les minuscules pour les autres éléments. Le nom des tables, comme celui des classes, est précédé d’une majuscule. Nous utilisons aussi cette convention pour les noms et composants des classes UML (ex : la classe Compagnie dispose de la méthode affreter).


5



Ce sigle introduit une définition, un concept ou une remarque importante. Il apparaît dans la partie théorique de l’ouvrage, mais aussi dans la partie technique pour souligner soit des instructions essentielles, soit la marche à suivre avec SQL.

Ce sigle annonce soit une impossibilité de mise en œuvre d’un concept, soit une mise en garde. Il est principalement utilisé dans la partie consacrée à SQL.

Ce sigle indique une astuce ou un conseil personnel.

Contact avec l’auteur Si vous avez des remarques à formuler sur le contenu de cet ouvrage, n’hésitez pas à m’écrire à l’adresse [email protected]. Je vous souhaite une bonne lecture.

6
