CNAM

UML et les Bases de Donnes

UML et les Bases de Donnes

1. Diagramme de classes / diagramme dobjets (UML) ................................... 2
1.1. Premier niveau de modlisation des donnes dune application .................................... 2 1.2. Les lments de modlisation ......................................................................................... 2 1.2.1. Objet......................................................................................................................... 2 1.2.2. Classe........................................................................................................................ 2 1.2.3. Diagramme de classes et dobjets............................................................................ 2 1.2.4. Atomicit des attributs, classe normalise .............................................................. 3 1.2.5. Lien entre objets et associations entre classes........................................................ 3 1.2.6. Multiplicits (cardinalits)........................................................................................ 4 1.2.7. Les rles.................................................................................................................... 7 1.2.8. Composition, lien de composition ........................................................................... 9 1.2.9. Hritage .................................................................................................................. 12 1.3. Exemples de modlisation des donnes dune application ........................................... 13 1.3.1. Exemple 1 (facturation de produits des clients) ................................................. 13 1.3.2. Exemple 2 (gestion des prts de livres dans un club) ............................................ 14

2. Transformation dun diagramme de classes en un schma relationnel ......15

2.1. Conception, gnration de code .................................................................................... 15 2.2. Transformation dune classe dans le modle relationnel ............................................. 15 2.2.1. Principe gnral de transformation ....................................................................... 15 2.2.2. Identifiant, cl primaire dune relation.................................................................. 15 2.2.3. Gnration du code du LDD SQL............................................................................ 16 2.2.4. Attribut cl primaire de la relation ........................................................................ 17 2.3. Principe de transformation des associations et des liens en relationnel ...................... 17 2.3.1. Association par valeur de cl (primaire) ................................................................ 17 2.3.2. Dpendance rfrentielle, cl trangre ............................................................... 18 2.4. Transformation dune association en relationnel (cas gnral).................................... 19 2.4.1. Relation de base, relation dassociation ................................................................ 19 2.4.2. Exemple .................................................................................................................. 20 2.4.3. Algorithme de transformation dune association en relationnel .......................... 21 2.4.4. Circuits dans les dpendances rfrentielles......................................................... 21

Grgory Claude

2010 2011

CNAM

UML et les Bases de Donnes

1. Diagramme de classes / diagramme dobjets (UML)

1.1. Premier niveau de modlisation des donnes dune application
Objectif : dfinir un premier niveau de modlisation des donnes de lapplication en faisant abstraction des aspects techniques (informatiques) qui se poseront lors de la ralisation de lapplication. Les lments de modlisation dUML sont suffisamment gnraux pour permettre aux utilisateurs non spcialistes en informatique (dcideurs en entreprise, par exemple) de comprendre les lments fondamentaux (essentiels) qui vont tre pris en compte lors de la ralisation de lapplication. Elments de modlisation de ce premier niveau de modlisation : classe, attribut, association, multiplicit, rle : diagramme de classes objet, donne, lien : diagramme dobjets spcification formelle laide dexpressions OCL compltant le diagramme de classes

1.2. Les lments de modlisation

1.2.1. Objet
Objet : entit qui a des proprits structurelles et comportementales. Par exemple un compte bancaire a un numro, un solde qui correspond au montant deuros que le propritaire du compte a confi la banque. Sur ce compte ce dernier pourra dposer, retirer de largent ou effectuer des virements.

1.2.2. Classe
Classe : dfinition structurelle et comportementale dun ensemble dobjets ayant les mmes proprits.

1.2.3. Diagramme de classes et dobjets

Diagramme de classes, diagramme dobjets : reprsentation graphique des classes et des objets. Exemple : A lUniversit, on souhaite mettre en place une application permettant denregistrer, pour chaque tudiant inscrit lUniversit, son nom et son adresse ainsi que pour chaque formation de lUniversit son code, le thme des enseignements et le nombres dheures denseignement. Modliser les donnes de cette application laide dun diagramme de classes et donner des exemples dinstances dobjets. De ce texte, on en dduit le diagramme de classes suivant :
Etudiant -nom: String -adresse: String Filire -code: String -thme: String -nbHeures: Integer

et un exemple de diagramme dobjets, instance du diagramme ci-dessus :

Grgory Claude

2010 2011

CNAM

UML et les Bases de Donnes

e1 : Etudiant -nom: "Dupont" -adresse: "Toulouse"

e2 : Etudiant -nom: "Dupont" -adresse: "Albi" f1 : Filire -code: "Systme08" -thme: "Systme" -nbHeures: 150 f : Filire -code: "Info007" -thme: "Info" +nbHeures: 100

etu2 : Etudiant -nom: "Dulong" -adresse: "Toulouse"

Remarques : e2, e1, etu2, sont appels les noms (identifiants) des objets. Dupont, Albi, sont des donnes de lapplication. e2 : Etudiant = ( Dupont, Albi) ou e2 sont des reprsentations simplifies dun objet.

1.2.4. Atomicit des attributs, classe normalise

Atomicit des attributs, classe normalise : lorsque la modlisation des donnes est faite en vue dune implantation des donnes laide dun SGBD Relationnel, le type dun attribut ne peut tre quun type de base (Integer, String, Boolean, ). On dit que les attributs doivent tre atomiques et par voie de consquence les classes sont normalises. Autre exemple : Les responsables dune banque souhaitent mettre en place une application pour grer les donnes concernant les clients de la banque et leurs comptes bancaires : pour chaque client, on enregistre son nom et son numro de tlphone, et pour chaque compte bancaire, son numro et le montant disponible sur ce compte. Sur chaque compte, on pourra dposer, retirer de largent ou effectuer des virements. Modliser ces donnes laide dun diagramme de classes et donner des exemples dinstances.

1.2.5. Lien entre objets et associations entre classes

Liens entre objets (diagramme dobjets) : Dans un diagramme dobjets on peut tablir des liens entre des objets. Par exemple, les tudiants e1 et etu2 sont inscrits en filire f2. Ce qui se reprsente graphiquement au niveau du diagramme dobjets de la manire suivante :

Associations entre classes (diagramme de classes) : Tout objet dun diagramme dobjets doit tre une instance dune classe dfinie dans le diagramme de classes correspondant : de mme tout lien entre des objets doit tre une instance dune association dfinie dans le diagramme de classes correspondant. Une classe a pour objectif de dfinir les proprits (attributs et oprations) dun ensemble dobjets qui pourront tre crs et manipuls par les programmes de lapplication : de mme, une association a pour objectif de dfinir les proprits dun ensemble de liens que lon pourra tablir entre les objets. A toute association, dfinie par un nom, correspond un ensemble de classes, dfinies dans le diagramme de classes. Tout lien tant une instance dune association a pour nom, le nom de lassociation correspondant et relie un objet de chaque classe caractrisant lassociation. Le diagramme de classes suivant montre que lassociation Inscription dfinit un ensemble de liens, chacun qui a pour nom Inscription, relie un objet de la classe Etudiant et un objet de la classe Filire :

Grgory Claude

2010 2011

CNAM

UML et les Bases de Donnes

Etudiant Inscrire -nom: String -adresse: String

Filire -code: String -thme: String -nbHeures: Integer

Un diagramme de classes peut avoir plusieurs associations. Une association peut dfinir des liens entre 2 classes, 3 ou plus. Par exemple un contrat est sign par un client, un reprsentant pour le compte dune compagnie dassurance : dans ce cas chaque contrat reliera un client, un reprsentant et une compagnie dassurance. On peut avoir plusieurs associations entre deux classes. Une association peut dfinir des liens entre des objets dune mme classe (association rflexive). Un objet peut appartenir plusieurs liens. Exemple : En prvision des lections, le service informatique dun Ministre souhaite mettre en place une application grant les donnes concernant les lecteurs et les villes o ils rsident : pour chaque lecteur, on enregistre son nom et sa profession, et pour chaque ville, on enregistre son nom et le code du dpartement o elle se trouve. Les lecteurs rsident dans des villes, et les villes ont des maires qui sont des lecteurs.
Electeur -nom: String +profession: String EtreMaire Rsider Ville -nom: String -codeDpt: Integer

Exemple : Lapplication de gestion du personnel dune entreprise a pour objectif de grer les donnes de ses employs, de leurs affectations dans les dpartements de lentreprise ainsi que leurs salaires : le nom et le numro de tlphone de chaque employ sont enregistrs dans la base de donnes ainsi que le nom et lactivit de chaque dpartement ; une grille de salaire donne pour chaque salaire, un indice et le montant de ce salaire ; les employs dont les salaires sont rfrencs dans la grille des salaires, sont affects dans les dpartements de lentreprise ; tout dpartement a un directeur qui est un employ de lentreprise ; tout employ a un responsable qui est un employ de lentreprise. Question : en dduire du texte, une modlisation des donnes laide du diagramme de classes, et donner des exemples dinstance.

1.2.6. Multiplicits (cardinalits)

Soit le diagramme de classes et le diagramme dobjets suivants :
Etudiant -nom: String -adresse: String Inscrire Module -code: String -thme: String -nbHeures: Integer

Grgory Claude

2010 2011

CNAM

UML et les Bases de Donnes

A chaque tudiant, on fait correspondre les modules o il est inscrit : e1, on fait correspondre {m1} (dans le cadre de lassociation Inscription) de mme, e2, on fait correspondre {m3} de mme, e3, on fait correspondre {m1, m3} Dune manire gnrale, tout objet e Etudiant, on associe dans le cadre de lassociation Inscription un ensemble de modules lis e, dont le nombre peut varier selon les mises jour effectues sur le diagramme dobjets. Au niveau du diagramme de classes, on doit indiquer le nombre minimum et maximum de modules qui pourront tre lis tout tudiant : un tel couple dentiers est appel multiplicits (cardinalits). Ce couple dentiers exprimant les multiplicits dune association vis vis dune classe : est not m..M, avec m = le nombre minimum (gnralement 0 ou 1), et M = le nombre maximum de modules (gnralement 1 ou *, pour indiquer un entier > 1) auxquels tout tudiant e peut sinscrire ; est situ sur lune des extrmits de lassociation, prs de la classe Module. Le diagramme suivant indique que tout tudiant doit tre inscrit au moins un module, et le diagramme dobjets qui suit, est une instance pertinente du diagramme de classes, puisque lon voit des tudiants qui sont inscrits un module (e1, e2, e4 et e5) et que e3 est inscrit plusieurs modules.
Etudiant -nom: String -adresse: String Inscrire 1..* Module -code: String -thme: String -nbHeures: Integer

Une association binaire, reliant 2 classes, a donc deux extrmits : on doit indiquer ces types de multiplicits sur les 2 extrmits de lassociation. Le diagramme suivant indique que tout tudiant doit tre inscrit dans une (seule) filire, et que dans une filire il peut y avoir plusieurs tudiants qui y sont inscrits. Le diagramme dobjets qui suit en montre une instance pertinente :
Etudiant Inscrire -nom: String -adresse: String 0..* 1 Filire -code: String -thme: String -nbHeures: Integer

Grgory Claude

2010 2011

CNAM

UML et les Bases de Donnes

Retour lexemple des lecteurs et des villes : Tout lecteur rside dans une ville, et toute ville a un maire qui est un lecteur. Un maire ne peut tre maire que dune ville. Donner le diagramme de classes, et donner une instance pertinente de votre diagramme de classes. Exemple : On suppose que lon a une base de donnes qui centralise les donnes de ltat civil concernant les franais et les franaises. On suppose que lon a enregistr pour tout franais son nom, sa date de naissance et le nom de la ville et du pays o il est n. Il en est de mme pour toute franaise. On enregistre dans la base de donnes les mariages, en supposant quun mariage permet dunir, par les liens du mariage, un franais une franaise. Donner le diagramme de classes, et donner un exemple pertinent dinstance de votre diagramme de classes. Association porteuse dinformations (classe dassociation) : Une association peut tre porteuse dinformation : une telle association est appele classe dassociation. Ce qui signifie qu tout lien, instance dune telle classe dassociation devra correspondre des donnes conformes ce qui est dclar dans la classe dassociation. Par exemple, le diagramme suivant montre que lon souhaite enregistrer lanne o tout tudiant sinscrit un module :
Etudiant Inscrire (anne) -nom: String -adresse: String Module -code: String -thme: String -nbHeures: Integer

De cette instance, on en dduit, par exemple, que e3 est inscrit au module 1 en 2005 et au module 3 en 2006. La reprsentation en UML dune classe dassociation est la suivante :

Grgory Claude

2010 2011

CNAM

UML et les Bases de Donnes

Etudiant -nom: String -adresse: String 0..* 0..*

Module -code: String -thme: String -nbHeures: Integer

Inscription -annee: Integer

Remarque : association ou classe ? Une association (ou classe dassociation) peut tre vue comme une classe. Les 2 diagrammes suivants dfinissent des structures de donnes quivalentes :
Etudiant -nom: String -adresse: String 1..* Ville 0..1 -nom: String -codeDpt: Integer

Habiter

Etudiant -nom: String -adresse: String 1

Ad_Pers 0..1

Adresse 1..*

Ad_Ville 1

Ville -nom: String -codeDpt: Integer

Question : donner, pour chaque diagramme, linstance modlisant le mme ensemble de donnes. Justifier les passages des multiplicits du premier diagramme, par rapport au deuxime diagramme.

1.2.7. Les rles

Objectifs des rles : les rles permettent dapporter plus de lisibilit, plus de comprhension aussi bien au niveau du diagramme de classes quau niveau du diagramme dobjets. Par exemple, le diagramme de classes suivant ne permet pas de savoir comment sinterprte lassociation Responsable, par rapport aux multiplicits (1..1 et 0..*) :
0..1 Employe 0..* -nom: String -adresse: String 1..* 1 Diriger

Responsable

Affecter 1 Departement -nom: String 0..1 -activite: String

Cette imprcision se rpercute au niveau du diagramme dobjets, o, dans certains cas, on ne peut pas savoir qui est responsable de qui :

Grgory Claude

2010 2011

CNAM

UML et les Bases de Donnes

Un rle est un nom que lon met au niveau de lextrmit dune association (au mme niveau que les multiplicits) tel que le montre le diagramme de classe suivant :
0..1 Employe 0..* -nom: String -adresse: String 1..* 1 +LeDir Diriger

Responsable

Affecter 1 Departement -nom: String 0..1 -activite: String

Ce diagramme montre que de la classe Departement, la classe Employe est vue sous le nom leDir. Le nom du rle peut tre report au niveau du diagramme dobjets, o on peut mieux voir, dans linstance suivante que le directeur du dpartement d3 est e3, celui du dpartement d2 e6 et celui du dpartement d1 qui est lemploy e1 :

Un nom de rles peut tre dclar chaque extrmit dune association. Dune manire gnrale un nom de rle facilite la lecture et linterprtation dun diagramme de classes, mais, pour ne pas surcharger les diagrammes de classes et leurs instances on ne met que le nom des associations et des rles qui permettent de lever les ambiguts, tel que le montre lexemple suivant :
+resp Responsable 0..* 0..1 Employe -nom: String -adresse: String 1..* 1 +LeDir Diriger Affecter 1 Departement -nom: String 0..1 -activite: String

Grgory Claude

2010 2011

CNAM

UML et les Bases de Donnes

Cette notation permet de voir que, daprs cette instance prcdente, le responsable de lemploy e2 est e1. Retour lexemple des tudiants inscrits dans des modules : quelle interprtation donnez-vous ce diagramme en prenant en compte les noms des rles :
Etudiant -nom: String -adresse: String +LesInscrits 0..* Inscrire Module +InscritEn -code: String -thme: String 1 -nbHeures: Integer

Mme question pour ce diagramme de classes :

+resp Responsable 0..1 Employe 0..* -nom: String +estRespDe -adresse: String +LesEmp 1..* 1 +LeDir Diriger Affecter +DeptAff 1 Departement -nom: String 0..1 -activite: String +EstDirDe

1.2.8. Composition, lien de composition

Exemple de normalisation dune classe : Les responsables dune entreprise souhaitent faire grer, par un systme de gestion de bases de donnes relationnelles, les donnes contenues dans les factures qui sont envoyes aux clients. Sur chaque facture, on trouve le numro de la facture, le nom du client qui est envoye la facture, la date de facturation, la date de paiement de la facture, et pour chaque type de produit achet par le client, le nom du produit et la quantit achete. Modliser les donnes de cette application laide du diagramme de classes et donner une instance du diagramme. Elments de solution de cet exemple : on pourrait imaginer quune facture (simplifie) se reprsente de la manire suivante :

Ce qui peut se modliser de la manire suivante :

Grgory Claude

2010 2011

CNAM

UML et les Bases de Donnes

10

FacturePasNormalisee -numroF: Integer -nomDuClient: String -dateDeFacturation: Date -dateDePaiement: Date -produitsFacturs: Produit

Les 4 premiers attributs de la facture sont atomiques, puisque toute facture correspond un numro, un nom de client, et une date de facturation et de paiement. Par contre, lattribut produitsFacturs nest pas atomique car cet attribut se dcompose en deux attributs (pour chaque type de produit factur, on enregistre son nom et la quantit facture). Dautre part, le nombre de produits facturs peut varier dune facture une autre (dans lexemple ci-dessus, le nombre de type de produits facturs est 3). On rappelle que tout diagramme de classes modlisant des donnes en vue dune gestion relationnelle des donnes, doit tre normalis : ce qui implique que tout attribut de la classe doit tre atomique. La modlisation prcdente de Facture ne peut donc pas tre considre comme une classe normalise. Une solution consiste clater Facture en deux classes normalises relies par une association permettant de rattacher une facture tous ses produits facturs : la premire reprend les attributs atomiques de la facture, ce que lon appelle gnralement lentte de la facture qui contient les donnes des attributs atomiques de la facture ; la deuxime modlise les donnes de chaque type de produit factur, cette classe est donc dfinie sur les attributs nom du produit et quantit commande de ce produit : cette deuxime classe modlise donc un ensemble de produits facturs dont chacun (chaque instance) doit tre li une facture : la facture o se produit est factur ; lassociation dfinissant les liens entre les factures et leurs produits facturs reprendra, comme nom dassociation, lattribut non atomique de la classe Facture : produitsFacturs ; compte tenu du fait que toute facture fait rfrence , au moins, un produit factur et que tout produit factur doit tre li une facture, on en dduit les multiplicits respectives : 1..* et 1..1. Le diagramme de classes modlisant les donnes, en vue dune implantation relationnelle, pourrait donc tre le suivant :
Facture -numroF: Integer -nomDuClient: String -dateDeFacturation: Date -dateDePaiement: Date +f 1 Facturer +pf 1..* ProduitFactur -nomDuProduit: String -quantitFacture: Integer

Exemple dinstance (diagramme dobjets) de ce diagramme de classes :

Grgory Claude

2010 2011

CNAM

UML et les Bases de Donnes

11

Ce diagramme dobjets, instance du diagramme de classes ci-dessus, montre que 2 factures ont t enregistres : sur la premire on trouve 3 produits facturs et sur la deuxime, 1 seul produit a t factur : le client de nom Dupont se voit factur des clous en quantit 40. Remarques : cette tape de dcomposition dune classe non normalise en 2 classes normalises, relies par une association nest pas trs naturelle : mais elle est ncessaire avant de passer une tape de modlisation relationnelle. En fait, cette tape de dcomposition prpare la dfinition des fichiers de lapplication, chacun tant un ensemble darticles de mme structure (logique et physique) : intuitivement, on pourrait admettre qu chaque classe correspondrait un fichier. Lorsque dun diagramme de classes est conu en vue dune implantation Java, par exemple, cette tape prliminaire de dcomposition dune classe nest pas ncessaire, puisque un attribut Java peut tre implant laide dun tableau, ce qui nest pas le cas en relationnel. Association/Composition : Cette dcomposition dune classe non normalise en deux classes normalises, runies par une association, fait que des donnes de deux applications diffrentes peuvent se modliser structurellement de la mme manire, alors quen fait les objets se manipuleront selon des approches diffrentes. Par exemple, soient les 2 diagrammes, chacun correspondant aux besoins dune application :

Si ces deux modlisations des donnes ci-dessus sont identiques structurellement parlant, en fait au niveau applicatif, la destruction dune facture entrane la destruction des produits facturs dans cette facture ; par contre, la destruction dun dpartement ne peut pas se faire si des employs sont affects ce dpartement. Pour marquer cette diffrence montrant un rattachement fort (physique) dobjets dune classe entrant dans la composition des objets dune autre classe, lassociation doit transforme en ce que lon appelle une Composition et se note habituellement laide dun losange noire tel que le montre la figure suivant :

Dans ce cours, on admettra que toute composition vient de la dcomposition dun attribut dune classe non atomique. En reprenant lexemple prcdent, Facture est appele classe englobante de la classe prod_Fact ; inversement, la classe Prod_Fact est appele classe composite de la classe Facture. La nuance entre une association et une composition est difficile cerner au niveau de la modlisation des donnes et lors de la modlisation. En fait, elle apparat plus claire lors de la manipulation des donnes. Cest pourquoi modliser des donnes peut savrer tre une tape trs dlicate. Souvent, le choix entre une association ou une composition dpend des applications. Les deux modles suivants montrent qu toute voiture peut tre lie au maximum 5 roues :

Grgory Claude

2010 2011

CNAM

UML et les Bases de Donnes

12

Le diagramme de gauche pourrait modliser les donnes dune application dun ferrailleur par exemple, qui quand il limine une voiture (la compresse pour la rduire en un cube prenant le moins de place possible) il limine aussi tous les lments de la voiture qui la composent. Par contre, le diagramme de droite montre quavant dliminer une voiture, il faut pralablement liminer les liens avec ses roues : ce modle de donnes irait bien, par exemple, une application destine un garagiste qui voudrait rcuprer toutes les pices dune voiture avant de lliminer. Le langage SQL permet de prendre en compte la diffrence entre une association et une composition. Cette dcomposition de classes montre que quand on modlise, il ne faut pas chercher reprsenter la structure des donnes dune application telle que lon pourrait se les imaginer. Il faut les modliser de manire ce que lon puisse les retrouver intgralement et sans ambigut. De toute faon, mme au niveau implantation, on aura du mal conserver exactement une structure de donnes physique reprenant exactement la modlisation qui en a t faite lors de la conception. Par contre, au niveau manipulation des donnes, il faudra absolument avoir les moyens de retrouver les donnes telles que souhaitent les voir les utilisateurs finals. Ce problme de dcomposition de classes en classes normalises est trs courant, et se rencontre dans un trs grand nombre dapplications, en particulier toutes les applications de gestion o les donnes sont naturellement structures hirarchiquement plusieurs niveaux : gestion dappartements dans des immeubles qui ont des propritaires, dossier mdical, bordereau de notes dtudiants, emploi du temps,

1.2.9. Hritage
L'hritage est un mcanisme de transmission des proprits d'une classe (ses attributs et mthodes) vers une sous-classe. Une classe peut tre spcialise en d'autres classes, afin d'y ajouter des caractristiques spcifiques ou d'en adapter certaines. Plusieurs classes peuvent tre gnralises en une classe qui les factorise, afin de regrouper les caractristiques communes d'un ensemble de classes. La spcialisation et la gnralisation permettent de construire des hirarchies de classes. L'hritage peut tre simple ou multiple. L'hritage vite la duplication et encourage la rutilisation.

Grgory Claude

2010 2011

CNAM

UML et les Bases de Donnes

13

Spcialisation
Employs +numSecuSoc: String

Administratifs +tarifHoraire: Float

Techniciens +tarifHoraire: Float

Cadres +forfaitMensuel: Float

Agents d'exploitation +primeDeRisque: Float

Gnralisation Le concept dhritage, essentiel dans les approches objet, ne sera plus abord dans ce cours parce que le diagramme de classes est ici utilis comme une tape prliminaire une modlisation relationnelle des donnes, modle nintgrant le concept dhritage. Cependant, lhritage tant une valeur importante de lobjet, il est important de savoir quil existe et quoi il correspond.

1.3. Exemples de modlisation des donnes dune application

1.3.1. Exemple 1 (facturation de produits des clients)
Une entreprise souhaite dvelopper une application grant les informations qui sont contenues dans les factures envoyes aux clients. Les responsables de lapplication demandent que soient enregistres dans la base, les donnes suivantes : pour tout client de lentreprise, son nom et son adresse, pour tout produit mis au catalogue de lentreprise, son nom et son prix unitaire, pour toute facture envoye un client, un numro, la date de facturation, la date de paiement qui est mise jour quand elle est acquitte par le client, et pour chaque produit factur sa quantit facture.

Grgory Claude

2010 2011

CNAM

UML et les Bases de Donnes

14

1.3.2. Exemple 2 (gestion des prts de livres dans un club)

Un club de livre souhaite informatiser la gestion des prts des livres aux abonns du club : pour chaque livre, on enregistre le titre, lauteur, et pour chaque exemplaire de livre dont dispose le club, un numro et le nom de lditeur ; pour chaque abonn, on enregistre son nom et le nom de la ville o il habite ; chaque exemplaire de livres est la proprit dun abonn du club ; chaque prt dun exemplaire de livre un abonn, on enregistre la date de prt de lexemplaire ; on souhaite archiver les prts de livres que les abonns ont faits, de manire savoir, en fin danne, qui a lu quoi pour en tenir compte lors de lachat de nouveaux livres. Question : effectuer une analyse du domaine, et en dduire une modlisation les donnes de lapplication laide dun diagramme de classes. Tous les lments du texte ont-ils pu tre exprims dans le diagramme de classes ?

Grgory Claude

2010 2011

CNAM

UML et les Bases de Donnes

15

2. Transformation dun diagramme de classes en un schma relationnel

2.1. Conception, gnration de code
Gnralement, on ne gnre pas le code du LDD SQL directement partir dun diagramme de classes. On prfre transformer le diagramme de classes en un schma reprsentant les donnes au travers de leurs lments de modlisation relationnelle. Le code du LDD SQL est alors dduit du schma relationnel. Un des intrts est de pouvoir reprsenter la structure relationnelle des donnes sous une forme graphique donnant une vision gnrale des donnes, dgage de toute contrainte syntaxique du langage du LDD SQL.

2.2. Transformation dune classe dans le modle relationnel

2.2.1. Principe gnral de transformation
Intuitivement, tel que le suggre la figure suivante, chaque classe on peut faire correspondre une relation telle que : le nom de la relation reprend le nom de la classe, le nom des attributs de la relation sont issus des noms des attributs de la classe.

Exemple :

Cette correspondance nest directement possible que si les attributs de la classe sont atomiques (les types des attributs sont des types de base : Integer, String, , qui devront tre adapts, selon le cas, en type SQL : varchar, number ou date).

2.2.2. Identifiant, cl primaire dune relation

En fait, il est important de pouvoir avoir les moyens didentifier de manire unique tout tuple de la relation. Une solution simple et systmatique consiste rajouter arbitrairement la relation un

Grgory Claude

2010 2011

CNAM

UML et les Bases de Donnes

16

attribut qui jouera le rle de cl primaire de la relation : cet attribut cl primaire de la relation correspond la notion didentifiant dobjets. Ce nouvel attribut, cl primaire de la relation, pourra tre appel identifiant de la relation. Lorsquun objet est cr, normalement on donne un nom (identifiant) cet objet, et on affecte une valeur chacun des attributs de la classe dont lobjet est une instance. Au niveau relation, il faut aussi donner, lors de la cration dun tuple, sa valeur de cl primaire (lidentifiant du tuple), et pour chaque attribut de la relation une valeur. Les identifiants dobjets ne sont pas modifiables ; en principe, il devrait en tre de mme pour les valeurs de cl primaire. On a donc la correspondance diagramme de classes/schma relationnel suivante :

remarque : X est une relation, les attributs de cette relation sont les attributs de la classe, lattribut X_ID joue le rle de cl primaire de la relation X. pr-conditions : les noms des attributs de la classe X sont diffrents 2 2, le nom des attributs est diffrent de X_ID, le type des attributs sont des types de base (Integer, Boolean, String)

2.2.3. Gnration du code du LDD SQL

A partir du schma relationnel, on peut en dduire le code du LDD SQL qui devra tre transmis au SGBD Relationnel pour quil puisse crer le schma interne des donnes : SQL> create table X( X_ID varchar( 10 ) primary key, X1 , ); Exemple :

SQL>

create table Voiture(

Voiture_ID varchar( 10 ) primary key, numero number, marque varchar( 10 )

);

Grgory Claude

2010 2011

CNAM

UML et les Bases de Donnes

17

2.2.4. Attribut cl primaire de la relation

Il se peut que sur certains attributs de la classe, un invariant de type cl soit dfini : dans ce cas, lun de ces attributs peut se substituer la cl primaire cre arbitrairement lors du passage au niveau relationnel, les autres seront des attributs qui, au niveau relationnel, auront la proprit : unique not null. Par exemple, on pourrait imaginer quil ne peut pas exister deux voitures qui ont le mme numro. Lattribut numro doit donc vrifier linvariant suivant, crit sous la forme dune expression OCL ferme : Voiture.allInstances forAll( v1, v2 | if v1 <> v2 then v1.numero <> v2.numero else true endif ) Dans ce cas, le schma relationnel et le code du LDD SQL peuvent tre simplifis, et le passage au niveau relationnel peut tre reprsent par la figure suivante :

SQL>

create table Voiture(

numero number primary key, marque varchar( 10 ) );

2.3. Principe de transformation des associations et des liens en relationnel

2.3.1. Association par valeur de cl (primaire)
En relationnel, cest au travers des valeurs de cl (primaire) que lon peut lier (associer) des tuples entre eux. Supposons le diagramme classique suivant :

La transformation en relationnel dun tel diagramme se fait, intuitivement, selon les tapes suivantes : 1. chaque classe correspond une relation :

Grgory Claude

2010 2011

CNAM

UML et les Bases de Donnes

18

2. puisque chaque voiture a un propritaire qui est une personne, il suffit dans la relation Voiture de rajouter une colonne permettant dindiquer, pour chaque voiture, quel est son propritaire ; ce propritaire pourra tre reprsent par son identifiant, cest--dire sa valeur de cl (primaire) ; il suffit donc de donner comme nom cette colonne le nom du rle :

3. puisquun propritaire ne peut tre quune personne qui existe, cest--dire une personne dont le tuple est dans la relation Personne, toute valeur de la colonne Voiture( lePropt ) doit tre une valeur de cl primaire de la relation Personne, cest--dire que toute valeur de la colonne( lePropt ) doit se retrouver dans la colonne Personne( Personne_ID ). On dit que lattribut Voiture( lePropt ) a pour domaine rfrentiel lattribut Personne( Personne_ID ). On crit : Voiture( lePropt ) Personne( Personne_ID ). La figure suivante montre comment on reprsente cette dpendance dans le schma relationnel, et au niveau du code du LDD SQL :

Le code du LDD SQL, correspondant au schma relationnel, est le suivant : SQL> create table Personne( Personne_ID varchar( 10 ) primary key, ); SQL> create table Voiture( Voiture_ID varchar( 10 ) primary key, lePropt varchar( 10 ) references Personne(Personne_ID));

2.3.2. Dpendance rfrentielle, cl trangre

Au niveau syntaxe du code LDD SQL : il existe diffrentes manires de dclarer la contrainte lie la dpendance rfrentielle, mais ce niveau du cours du CNAM, on ne rentrera pas dans ces dtails, pour des raisons logiques (au niveau des associations), le domaine de rfrence (ici Personne(Personne_ID)) doit tre une cl ; et pour des raisons doptimisation, le domaine de rfrence doit tre une cl primaire : cest pourquoi, lattribut lePropt est appel cl trangre. (lattribut lePropt nest pas un attribut cl, mais il a pour domaine de rfrence un attribut cl trangre).

Grgory Claude

2010 2011

CNAM

UML et les Bases de Donnes

19

2.4. Transformation dune association en relationnel (cas gnral)

Lexemple de transformation prsent prcdemment permettait de montrer intuitivement comment les valeurs de cl (primaires) peuvent tre utilises pour exprimer des liens entre tuples de relations, ce qui justifie les concepts de dpendance rfrentielle et de cl trangre pour exprimer au niveau relationnel le concept dassociations et de liens dfinis au niveau de diagramme de classes. Cet exemple intuitif tait bas sur une association dont les multiplicits taient 1..1 / 0..*.

2.4.1. Relation de base, relation dassociation

Dune manire gnrale, une association dont les multiplicits sont (0..* / 0..*) se traduit par une relation (souvent appele relation dassociation), tel que le suggre la figure suivante, le diagramme de classes et le schma relationnel qui sen dduit :

remarque : A( rx ) X( X_ID ), A( ry ) Y( Y_ID ) X et Y sont des relations de base ; A est une relation dassociation exprimant des liens entre les tuples des relations X et Y pr-conditions : les nom de rles rx et ry sont diffrents, et sont diffrents du nom de lassociation. gnration du code du LDD SQL : SQL> create table X( X_ID varchar( 10 ) primary key, X1 , ); SQL> create table Y( Y_ID varchar( 10 ) primary key, Y1 , ); create table A( A_ID varchar( 10 ) primary key, rx varchar( 10 ) references X( X_ID ), ry varchar( 10 ) references Y( Y_ID ) ) ;

SQL>

Remarque : les rfrences en avant doivent tre satisfaites au niveau du code du LDD SQL. Cest pourquoi, les tables X et Y doivent tre cres avant la table A. Il est en de mme pour les tuples des relations X et Y qui doivent tre crs avant de retrouver leur valeur de cl primaire dans la relation A. En ce qui concerne la destruction des tuples et des relations, il ne sera possible de dtruire la table A que si elle est vide.

Grgory Claude

2010 2011

CNAM

UML et les Bases de Donnes

20

2.4.2. Exemple

SQL>

create table etudiant( Etudiant_ID varchar( 10 ) primary key, , ); create table Module( Module_ID varchar( 10 ) primary key, , ); Inscription_ID varchar( 10 ) primary key, etuInscrit varchar( 10 ) references Etudiant( Etudiant_ID ), inscritEn varchar( 10 ) references Module( Module_ID ) ) ;

SQL>

SQL>

create table Inscription(

Comme pour lexemple prcdent, les attributs des classes, peuvent, au niveau relationnel, jouer le rle de cl primaire, et dans ce cas, les dpendances rfrentielles doivent tre reportes sur ces attributs. Exemple :

SQL>

create table etudiant( numEtu varchar( 10 ) primary key, numSS number unique not null, nom varchar( 10 ) ); create table Module( nom varchar( 10 ) primary key, nbeH number ); Inscription_ID varchar( 10 ) primary key, etuInscrit varchar( 10 ) references Etudiant( numEtu ), inscritEn varchar( 10 ) references Module( nom ) );

SQL>

SQL>

create table Inscription(

Grgory Claude

2010 2011

CNAM

UML et les Bases de Donnes

21

2.4.3. Algorithme de transformation dune association en relationnel

1. Chaque classe du diagramme de classes devient une table en relationnel. 2. A chaque classe du diagramme de classe est associ un identifiant : celui-ci est soit un identifiant gnrer classe_id soit une proprit de la classe. Cet identifiant devient la cl primaire de la table cre correspondante. 3. Toute relation dont une des cardinalits est de type (,1) provoque la gnration dune cl trangre. Cela a pour consquence la cration dune colonne de nom le_rle dans la table, chaque valeur de cette colonne doit faire rfrence la cl primaire de lautre table issue de lassociation. 4. Pour toutes les autres cardinalits, la relation devient une nouvelle table ayant pour cl primaire le couple didentifiant des tables issues de lassociation. Attention : en fonction des cardinalits, la cration des attributs ne sera pas la mme. Par exemple, une cardinalit (1,1) donnera un attribut dont la valeur ne devra jamais tre nulle et devra rfrencer une cl primaire dune autre table alors quune cardinalit (0,1) donnera un attribut dont la valeur pourra tre nulle ou devra rfrencer une cl primaire dune autre table.

2.4.4. Circuits dans les dpendances rfrentielles

La gnration du code du LDD SQL se fait partir du schma relationnel, ce dernier tant obtenu en appliquant pour chaque classe et pour chaque association les rgles dfinies ci-dessus. Pour effectuer cette gnration de code, on ne tient pas compte du double-sens des dpendances rfrentielles. Lordre de cration des relations se fait en respectant les rfrences en avant des dpendances rfrentielles. Il peut exister un (ou plusieurs circuits) dans les dpendances rfrentielles. Dans ce cas, il faut que le concepteur coupe ce circuit, et reporte la contrainte correspondante au niveau applicatif. Exemple :

Dans ce cas, pour pouvoir crire le code du LDD SQL, il faut supprimer une dpendance, par exemple :

Grgory Claude

2010 2011