Vous êtes sur la page 1sur 40

1

Elments de cours de BD du CNAM (2005/2006) 1 Diagramme de classes / diagramme dobjets (UML)___________________________4 1.1 Premier niveau de modlisation des donnes dune application ____________4 1.2 Les lments de modlisation ________________________________________4 1.2.1 Objet_________________________________________________________4 1.2.2 Classe ________________________________________________________4 1.2.3 Diagramme de classes et dobjets __________________________________4 1.2.4 Atomicit des attributs, classe normalise ____________________________5 1.2.5 Lien entre objets et associations entre classes _________________________5 1.2.6 Multiplicits (cardinalits) ________________________________________6 1.2.7 Les rles ______________________________________________________8 1.2.8 Composition, lien de composition _________________________________10 1.3 Exemples de modlisation des donnes dune application ________________12 1.3.1 Exemple 1 (facturation de produits des clients) _____________________12 1.3.2 Exemple 2 (Gestion de bons de commandes, des livraisons et des factures) 13 1.3.3 Exemple 3 (gestion des prts de livres dans un club) __________________19 2 Introduction au langage OCL (Object Contraint Language) ___________________19 2.1 Aspect structurel des lments de modlisation du diagramme de classes___19 2.2 Concepts de base du langage OCL ___________________________________20 2.2.1 OCL est un langage sans effet de bord______________________________21 2.2.2 OCL est un langage objet ________________________________________21 2.2.3 OCL est un langage ensembliste __________________________________22 2.2.4 OCL est un langage bas sur la logique des prdicats du 1er ordre ________23 2.3 Lapproche fonctionnelle du langage OCL ____________________________24 2.3.1 OCL est un langage fonctionnel___________________________________24 2.3.2 Enchanement des oprations sur les collections ______________________24 2.3.3 Navigation des expressions OCL__________________________________25 2.3.4 Remarque sur la visibilit dun objet _______________________________25 2.3.5 Quelques expressions OCL ______________________________________26 2.4 3 3.1 Modlisation : diagramme de classes + contraintes dintgrit OCL _______26 Conception, Gnration de code _____________________________________28 Transformation dun diagramme de classes en un schma relationnel___________28 3.2 Transformation dune classe dans le modle relationnel _________________28 3.2.1 Principe gnral de transformation ________________________________28 3.2.2 Identifiant, cl primaire dune relation______________________________28 3.2.3 Gnration du code du LDD SQL _________________________________29 3.2.4 Attribut cl primaire de la relation_________________________________29 3.3 Principe de transformation des associations et des liens en relationnel _____30 3.3.1 Association par valeur de cl (primaire) ____________________________30 3.3.2 Dpendance rfrentielle, cl trangre _____________________________31 3.4 Transformation dune association en relationnel (cas gnral)____________31 3.4.1 Relation de base, relation dassociation_____________________________32 3.4.2 Exemple _____________________________________________________32

______________________________________________________________________________________ CNAM (2005/2006) : Bases de Donnes (notes de cours)

3.5 Transformation dune association en relationnel (en tenant compte des contraintes de multiplicits) ______________________________________________33 3.5.1 Multiplicits 0..* / m..M ________________________________________33 3.5.2 Multiplicits 0..1 / m..M ________________________________________36 3.5.3 Multiplicits 1..* / m..M ________________________________________37 3.5.4 Multiplicits 1..1 / m..M ________________________________________38 3.5.5 Circuits dans les dpendances rfrentielles _________________________39 4 Rsum, Bilan ________________________________________________________40

______________________________________________________________________________________ CNAM (2005/2006) : Bases de Donnes (notes de cours)

3 Introduction sur le cours Intervenants dans les enseignements : Thierry Millan (millan@irit.fr), Pierre Bazex (bazex@irit.fr) Application bases de donnes : application o laspect donne est primordial : - volume de donnes important - trs grande varit des donnes - persistance des donnes - change de donnes entre applications - aspect multi-utilisateur - application de trs nombreux domaines dactivit - trs grande varit dutilisateurs autour dune application BD - Les rseaux informatiques (WEB), les interfaces graphiques font des bases de donnes un sujet dactualit trs important, : manipulation de trs gros volumes de donnes, accs aux bases de donnes 24 h / 24, trs grand nombre dutilisateurs demandant des accs en mme temps, . Les applications bases de donnes ne sont plus limites des applications de gestion : on trouve des bases de donnes dans pratiquement tous les secteurs dactivits (transport, aronautique, espace, , mdecine, pharmacie, ). Processus de dveloppement (diffrentes tapes de dveloppement) dune application base de donnes : - partir de lexpression des besoins (rdige sous forme informelle) : - ! premier niveau de modlisation des donnes : conception/spcification. ! ralisation de lapplication. - (faire le parallle avec la programmation : algorithme ! programmation) - (faire le parallle avec le plan dune maison dduit des besoins du client ! construction) Conception/Spcification : - elle est gnralement faite avec la mthode Merise prconisant un premier niveau de modlisation des donnes laide du modle Entit/Association. - dans ce cours on remplace le modle Entit/Association par le diagramme de classes et le diagramme dobjets dUML (Unified Modeling Language) qui, en plus de la modlisation des donnes, permet de modliser dautres aspects des applications. UML est une norme. Ralisation laide dun Systme de Gestion de Base de Donnes (SGBD) : - les SGBD sont classs en fonction des modles de donnes quils proposent : . actuellement les SGBD Relationnels (Oracle, DB2, ) sont les plus courants. Plan du cours : - I (P. Bazex) : - modlisation, spcification des donnes (diagramme de classes et dobjets (UML) ) - introduction au langage OCL permettant de complter la modlisation des donnes - passage au niveau relationnel : . transformation dun diagramme de classes en un schma relationnel - II (T. Millan) : - le modle relationnels et les SGBD Relationnels Remarques : - un diteur UML, et lvaluateur dexpressions OCL USE peuvent tre tlchargs sur PC, - les tudiants qui auraient un compte CICT peuvent accder ces logiciels : les diteurs UML et le logiciel USE sur la machine Marine, et le logiciel Oracle (SGBD Relationnel) sur la machine Telline).

______________________________________________________________________________________ CNAM (2005/2006) : Bases de Donnes (notes de cours)

1
1.1

Diagramme de classes / diagramme dobjets (UML)


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 de UML 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 : (voir livre PA. Muller : modliser avec UML (?) 2me dition ; des cours sur UML sont accessibles sur le WEB : se limiter au diagramme de classes et dobjets et OCL) - 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 : - une entit atomique (?) 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 nbeHheure : Integer

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


e2 : Etudiant nom : Dupont adresse : Albi etu2 : Etudiant nom : Dulong adresse : Toulouse

e1 : Etudiant nom : Dupont adresse : Toulouse

f1 : Filire code : Systme08 thme : Systme nbeHeure : 150

f : Filire code : Info 007 thme : Info. nbeHeure : 100

remarques :

- e2, e1, etu2, sont appels les noms (identifiants) des objets. - Dupont, Albi, sont des donnes de lapplication.

______________________________________________________________________________________ CNAM (2005/2006) : Bases de Donnes (notes de cours)

5 - 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 :
e2 etu2 e1 Inscription f Inscription f1

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 :
Etudiant nom : String adresse : String Inscription Filire code : String thme : String nbeHheure : 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.

______________________________________________________________________________________ CNAM (2005/2006) : Bases de Donnes (notes de cours)

6
Electeur nom : String profession : String Residence Maire 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)


Multiplicits (cardinalits) : soit le diagramme de classes et le diagramme dobjets suivants :
Etudiant nom : String adresse : String e1 e2 e3 e4 e5 e6 Module code : String thme : String nbeHheure : Integer m1 m2 m3

Inscription

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 :

______________________________________________________________________________________ CNAM (2005/2006) : Bases de Donnes (notes de cours)

7
Etudiant nom : String e1 e2 e3 e4 e5 Inscription 1..* Module code : String thme : String m1 m2 m3

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 nom : String e1 e2 e3 e4 e5 Filire code : String thme : String m1 m2 m3

Inscription 0..* 1..1

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 digramme 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 digramme 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 nom : String adresse : String e1 e2 e3 e4 e5 e6 Inscription (anne) Module code : String thme : String nbeHheure : Integer

Inscription (2006) m1 Inscription (2005) m2 Inscription (2006) Inscription (2006) m3

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 :
______________________________________________________________________________________ CNAM (2005/2006) : Bases de Donnes (notes de cours)

Inscription anne Etudiant nom : String adresse : String 0..* Module code : String thme : String nbeHheure : Integer

0..*

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 1..* 0..1 Ville nom : String dpt. : String

Personne nom : String

Ad_Pers 1..1 0..1

Adresse 1..*

Ad_Ville 1..1

Ville nom : String dpt. : String

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..* ) :
Affectation 0..1 Responsable 0..* Emp loye nom : String adresse : String 1..* 1..1 Departement nom activite

1..1 Directeur 0..1

Cette imprcision se rpercute au niveau du diagramme dobjets, o, dans certains cas, on ne peut pas savoir qui est responsable de qui :
e1 e2 e3 e4 e5 e6 Aff. Aff. Aff. Aff. Aff. Aff. Dir. d3 Dir. Dir. d1 d2

Resp.

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 :

______________________________________________________________________________________ CNAM (2005/2006) : Bases de Donnes (notes de cours)

9
Affectation 0..1 Responsable 0..* Emp loye nom : String adresse : String 1..* 1..1 Departement nom activite

leDir 1..1 Directeur 0..1

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 :
leDir Aff. e1 e2 Aff. Aff. e3 leDir Dir. e4 Aff. e5 Aff. e6 Aff. leDir

Resp.

d1 d2 d3 Dir.

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 0..1 Responsable 0..* resp e1 e2 leDir d1 Affectation Emp loye nom : String adresse : String 1..* 1..1 Departement nom activite

leDir 1..1 Directeur 0..1

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 Inscription lesInscrits inscritEn 1..1 0..* Module code : String thme : String nbeHheure : Integer

Mme question pour ce diagramme de classes :


leResp 0..1 Responsable estRespDe 0..* Affectation Emp loye nom : String adresse : String lesEmp 0..* leDir 1..1 deptAff 1..1 estDirDe 0..1 Directeur Departement nom activite

______________________________________________________________________________________ CNAM (2005/2006) : Bases de Donnes (notes de cours)

10

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 :
Entreprise E Facture nom du Client : Dupont numroF : 123 date de facturation : 10/03/2006 date de paiement : produits facturs : nom du produit quantit facture vis 35 clou 30 pointe 50

Ce qui peut se modliser de la manire suivante :


Facture numroF nom du Client date de facturation date de paiement produits_facturs( nom du produit, quantit facture )

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 produits facturs 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 : Produits_Facturs ; - 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 :
______________________________________________________________________________________ CNAM (2005/2006) : Bases de Donnes (notes de cours)

11

Facture numroF nom du Client date de facturation date de paiement

Produit_Facturs f 1..1 pf 1..*

Produit_Factur nom du produit quantit facture

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


f1 : Facture = ( 123, Dupont, 10/ 03/ 2006, undefined ) f2 : Facture = ( 200, Dupont, 11/ 03/ 2007, 13/ 03/ 2006 ) pf pf pf1 : Produit_Factur( vis, 35 ) pf pf2 : Produit_factur( clou, 30 ) pf pf3 : Produit_Factur( pointe, 50 ) pf4 : Produit_Factur( clou, 40 )

Ce diagramme dobjets, instance du diagramme de classes ci-dessus, montre que 2 factures ont tt 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 :
Facture pf f 1..* 1..1 Prod_Fact Prod_Fact Dpartement m et 1..1 1..* Inscription Emp loy

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 :
Facture pf f 1..1 1..* Prod_Fact Prod_Fact Dpartement m et 1..1 1..* Inscription Emp loy

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 :
______________________________________________________________________________________ CNAM (2005/2006) : Bases de Donnes (notes de cours)

12
Vo iture v r 0..1 0..5 Vo it_R Roue Vo iture v r 0..1 0..5 Vo it_R Roue

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 que avant 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 toutes faons, 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.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. Une modlisation laide du diagramme de classes pourrait tre la suivante :

______________________________________________________________________________________ CNAM (2005/2006) : Bases de Donnes (notes de cours)

13
Client nom adresse cl 1..1 Client_Facture f 0..* Facture numroF date de facturation f date de paiement 1..1 Produit nom PU p 1..1

Produit_Factur

Facture_QF pf 1..* QF quantit facture

pf 0..*

1.3.2 Exemple 2 (Gestion de bons de commandes, des livraisons et des factures)


Exercice de rflexion ( prparer durant les congs de printemps): Une entreprise souhaite dvelopper une application grant les bons de commandes mis par ses clients. On enregistre : - pour tout client de lentreprise, son nom et son adresse, et pour tout produit mis au catalogue de lentreprise, son nom et son prix unitaire, - pour toute commande envoye par un client, un numro, la date de rception du bon de commande, et pour chaque produit command sa quantit commande. Dautre part, chaque livraison de produits commands par un client, on cre un bon de livraison contenant un numro et la date de livraison des produits. question 1 : donner une modlisation des donnes de cette application laide dun diagramme de classes, et en dduire une instance de votre diagramme de classes ; question 2 : en fait la premire question nest pas suffisamment prcise pour que lon puisse donner une modlisation correcte (?) des donnes. Pour chaque sous-question suivante, donner une modlisation ainsi quune instance de votre modle : 2-1 : lentreprise effectue une livraison pour chaque bon de commande, ds quelle a en stock tous les produits commands dans le bon de commande ; 2-2 : souvent les livraisons ne peuvent pas se faire ds rception des bons de commandes ; ainsi il pourrait y avoir plusieurs bons de commandes dun mme client, en attente de livraison : lentreprise peut donc tre amene livrer, en fonction de son stock, en une livraison tous les produits commands par un client dans plusieurs bons de commandes (dans ce cas toute la description des donnes est-elle prise en compte ?) ; 2-3 : pour tenter de satisfaire la clientle autant que lentreprise peut le faire, elle peut tre amene, en fonction de son stock, effectuer des livraisons partielles de produits commands dans un bon de commande. Dans ce cas, dans chaque bon de livraison on doit retrouver la quantit livre de chaque produit command ; lorsque tous les produits dun bon de commande sont livrs, une facture est envoye au client : elle contient un numro de livraison, bien sr, la date de facturation et la date dacquittement de la facture (dans ce cas toute la description des donnes est-elle prise en compte ?) ; 2-4 : que devient votre modlisation si lentreprise serait amene effectuer, en une livraison, des livraisons partielles de produits issus de plusieurs bons de commande dun mme client ? 2-5 : lments de solution de cet exercice de rflexion question 1 : tout dabord, il suffit de partir de lexercice prcdent sur les factures et de ladapter aux bons de commandes :

______________________________________________________________________________________ CNAM (2005/2006) : Bases de Donnes (notes de cours)

14
Client_BC Client nom cl Bon_Co mmande bc adresse 1..1 numro_BC 0..* date de commande Produit nom PU

p bc 1..1 BC_QC qc 1..* qc 0..* Quantit_Com. quantit commande Produit_Co mmand 1..1

remarque : puisque une quantit commande doit tre lie un bon de commande et un produit (multiplicits 1..1 aux deux extrmits) on en dduit que la classe Quantit_Com. pourrait tre vue comme une association (ou plus exactement comme une classe dassociation puisquelle est porteuse dinformation). On aurait pu avoir la modlisation suivante :
Client_BC Client nom cl Bon_Co mmande bc adresse 1..1 numro_BC 0..* date de commande Produit nom PU

p 1..* bc 0..* Produit_Co mmand quantit commande

On sloigne de la vision que lon peut avoir dun bon de commande pouvant contenir plusieurs lignes de commandes de produits, pour chacun dentre eux, la quantit commande. Le rsultat de la conception ne doit pas forcment aboutir une photographie de la ralit : un modle doit tre le plus simple possible, au dpart, mais il doit surtout permettre de restituer la ralit, sans ambigut. A lusage, ou aprs rflexion, ou aprs estimation des performances de lapplication, le modle pourrait voluer. En ce qui concerne les bons de livraisons, il ny a pas assez dinformations dans la question 1 du texte pour complter le modle ci-dessus. Lobjectif de la question 2 est - de modliser les informations concernant les livraisons des produits commands par les clients, - dintgrer la modlisation des bons de livraison dans le modle des bons de commandes : cette intgration dpend de la manire dont les livraisons sont gres. La question 2 propose diffrentes manires de grer les bons de commandes dans lentreprise, ce qui permettra, en fait, dtudier diffrents modles de donnes. question 2 : 2-1 : soit, il suffit de rajouter dans le bon de commande (classe BC) la date de livraison, qui sera mise jour lorsque la livraison sera faite, soit on cre une classe Bon de Livraison (classe BL) permettant ainsi de crer un objet bon de livraison lorsque la livraison sera effectue, et qui devra tre lie au bon de commande correspondant :

______________________________________________________________________________________ CNAM (2005/2006) : Bases de Donnes (notes de cours)

15
Client_BC Client nom cl BC bc adresse 1..1 0..* num_bc date_c bc 1..1 BC_BL bl 0..1 BL num_bl date_l Produit nom PU

bc 1..1

BC_QC qc 1..* QC qc qc 0..*

Pr_QC

p 1..1

exemple dinstance de ce diagramme de classes :


cl1 : Client = (dupont, tlse ) cl2 cl3 cl4

bc1 : BC = (123, ... ) bc2 bc3 bc4 bc5

bl1 : BL = (120, ... ) bl2

qc1 : QC = (60) qc2 qc3 qc4 qc5 qc6 qc7

p1: Produit = (vis, 10) p2 p3 p4 p5 p6 p7 p8

De ces diagramme de classes et dobjets, on en dduit, en particulier, que le client de nom Dupont a pass une seule commande pour 60 vis. Un autre client, dont cl4 est lidentifiant de lobjet a mis 3 bons de commandes, chacun ne portant que sur une quantit de produits commands. Seuls, les produits commands dans les bons de commandes didentifiants bc1 et bc4 ont t livrs. 2-2 : lentreprise peut effectuer en une livraison un client, les produits quil a commands dans plusieurs bons de commandes :
Client_BC Client nom cl BC bc adresse 1..1 num_bc 0..* date_c bc 1..* BC_BL bl 0..1 BL num_bl date_l Produit nom PU

bc 1..1

BC_QC qc 1..* QC qc qc 0..*

Pr_QC

p 1..1

remarque : ce modle (structurel) ne vrifie pas que tout bon de livraison fait rfrence des bons de commande venant du mme client. On pourrait rajouter une association permettant de relier tout bon de livraison au client concern. Mais, a nassure pas que tout bon de livraison fait rfrence des bons de commandes venant du mme client : en fait une contrainte supplmentaire serait rajoute !!

______________________________________________________________________________________ CNAM (2005/2006) : Bases de Donnes (notes de cours)

16 Exemple dinstance du diagramme de classes prcdent :


cl1 : Client = (dupont, tlse ) cl2 cl3 cl4

bc1 : BC = (123, ... ) bc2 bc3 bc4 bc5

bl1 : BL = (120, ... ) bl2

qc1 : QC = (60) qc2 qc3 qc4 qc5 qc6 qc7

p1: Produit = (vis, 10) p2 p3 p4 p5 p6 p7 p8

commentaire : le bon de livraison bl2 montre que tous les produits commands dans les bons de commande bc4 et bc5 ont t livrs, dune part et que dautre part ces 2 bons de commande sont issus de mme client (cl4), dont la commande bc3 na pas encore tait honore. 2-3 : les produits commands dans un bon de commandes pourraient tre livrs en plusieurs fois : dans ce cas, il faut que dans le bon de livraison, on puisse enregistrer la quantit de chaque type de produits livrs :
Client nom adresse Client_BC cl 1..1 bc 0..* BC num_bc date_c bc 1..1 BC_BL bl 0..* BL num_bl date_l BC_QC ql 1..* QL ql Produit nom PU

bc 1..1

BC_QC qc 1..* QC qc qc 0..*

Pr_QC

p 1..1

bl 1..1

Mais, il faudrait vrifier que les quantits livres correspondent bien des produits commands dans le bon de commande correspondant : il faudrait donc associer les classes QL et QC. Il est toujours ncessaire de vrifier que les produits livrs rfrencs dans un bon de livraison correspondent bien des commandes venant du mme bon de commande : lassociation entre BC et BL devient donc inutile. On pourrait donc avoir le modle :

______________________________________________________________________________________ CNAM (2005/2006) : Bases de Donnes (notes de cours)

17
Client nom adresse Client_BC cl 1..1 bc 0..* BC num_bc date_c Produit nom PU

bc 1..1

BC_QC qc 1..* QC qc qc 1..1 qc 0..*

Pr_QC

p 1..1

BL num_bl date_l

BC_BL bl 1..1 BC_QC ql 1..* bl 0..* QL ql

avec les deux contraintes : -c1- : les produits livrs rfrencs dans un bon de livraison correspondent des produits commands dans un seul bon de commandes. -c2- : les produits livrs rfrencs dans un bon de livraison correspondent des bons de commandes issues dun mme client. 2.4 : le modle (structurel) est le mme :
Client nom adresse Client_BC cl 1..1 bc 0..* BC num_bc date_c Produit nom PU

bc 1..1

BC_QC qc 1..* QC qc qc 1..1 qc 0..*

Pr_QC

p 1..1

BL num_bl date_l

bl 1..1

BC_QC ql 1..*

QC_ QL bl 0..* QL ql

mais la contrainte c1 nest plus dactualit.

______________________________________________________________________________________ CNAM (2005/2006) : Bases de Donnes (notes de cours)

18
cl1 : Client = (dupont, tlse ) cl2 cl3 cl4

bc1 : BC = (123, ... ) bc2 bc3 bc4 bc5

bl1 bl2 ql1 ql2 ql3

qc1 : QC = (60) qc2 qc3 qc4 qc5 qc6 qc7

p1: Produit = (vis, 10) p2 p3 p4 p5 p6 p7 p8

Il existe une contrainte importante non mentionne jusquici : - on ne doit pas livrer plus que ce qui a t command : cest--dire que pour chaque quantit de produits commands, la quantit de produits livrs pour cette commande doit rester infrieure ou gale.
Client nom adresse Client_BC cl 1..1 bc 0..* BC num_bc date_c Produit nom PU

bc 1..1

BC_QC qc 1..* QC qc qc 1..1 qc 0..*

Pr_QC

p 1..1

bc 1..1

BL num_bl date_l

bl 1..1

BC_QC ql 1..*

QC_ QL bl 0..* QL ql

fa 0..1 Facture num_fa date_fa date_paie.

autre contrainte : une facture existe que si les produits du bons de commandes correspondant ont tous t livrs. remarque : organisation (chronologique) du diagramme de classes, et en consquence des diagrammes dobjets.

______________________________________________________________________________________ CNAM (2005/2006) : Bases de Donnes (notes de cours)

19

1.3.3 Exemple 3 (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 fait, 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 ?

2
2.1

Introduction au langage OCL (Object Contraint Language)


Aspect structurel des lments de modlisation du diagramme de classes

Un diagramme de classes est le rsultat dune modlisation faite partir dune description informelle rdige en texte libre par les responsables de lapplication. Cette description est intgre dans un document appel cahier des charges de lapplication, ou expression des besoins de lapplication, ou encore description des exigences, Cependant, tout ce qui est dcrit dans le texte drivant les donnes de lapplication peut ne pas forcment se modliser laide dun diagramme de classes qui ne dfinit quune structure de donnes. Le fait, par exemple, quil ne peut exister deux bons de commandes ayant le mme numro ne peut pas sexprimer laide des lment de modlisation dfinis dans le diagramme de classes. Le langage OCL (Object Constraint Language), partie intgrante de la norme UML, a t cr pour exprimer les lments du cahier des charges non exprimables dans un diagramme de classes. Une modlisation (UML) des donnes dune application est donc constitue de 2 parties : - un diagramme de classes dfinissant la structure des donnes de lapplication, - des expressions boolennes OCL, appeles spcifications OCL, exprimant des contraintes (proprits) sur les donnes de lapplication : ces spcifications sont un moyen de prciser dune manire formelle ( laide dexpressions logiques) des contraintes crites en texte libre. Pour tre cohrent par rapport une modlisation UML, les objets et les liens dun diagramme dobjets doivent donc vrifier : - la structure dfinie par le diagramme de classes (on parle de cohrence structurelle), - les spcifications OCL accompagnant le diagramme de classes (on parle de cohrence smantique) La cohrence smantique ne peut se vrifier que si les objets et les liens sont cohrents par rapport la structure dfinie dans le diagramme de classes. Exemple : chez un grand garagiste, on pourrait imaginer une base dont les donnes concerneraient les voitures dont les maintenances sont effectues dans le garage et les clients du garage. La description des donnes pourrait en tre la suivante : - pour tout client, on enregistre son nom, son anne de naissance, son numro de tlphone ainsi que le nom de la rue et de la ville o il habite, - pour toute voiture, on enregistre son numro, sa marque, son modle, - toute voiture a un propritaire qui est un client, - tout propritaire de voiture doit avoir plus de 18 ans. question 1 :
______________________________________________________________________________________ CNAM (2005/2006) : Bases de Donnes (notes de cours)

20 - 1.1 : modliser les donnes de cette application laide dun diagramme de classes, - 1.2 : tous les lments de la description des donnes ont-ils pu tre pris en compte dans le diagramme de classes ? dans le cas ngatif indiquer ces lments, question 2 : en supposant que les expressions OCL compltant le diagramme de classes ont pu tre crites, donner : - 2.1 : un exemple pertinent des donnes, par rapport votre modle de donnes, - 2.2 : un exemple de donnes, cohrente structurellement et smantiquement, - 2.3 : des exemples de donnes, ne vrifiant pas la cohrence smantique, - 2.4 : des exemples de donnes ne vrifiant pas la cohrence structurelle. La ralisation dune application base de donnes demande gnralement un lourd investissement, et ncessite un temps plus ou moins long avant que la base de donnes ait pu acqurir suffisamment dinformations pour rpondre pleinement ce que lon en attend delle. Si ce moment-l, on saperoit quelle ne rpond pas aux exigences des utilisateurs finals (performances insuffisantes, informations incompltes, ) il faut alors revoir le modle de la conception, re-adapter les donnes dj rentres cette nouvelle modlisation et re-crire les programmes dapplications. Cest pourquoi, gnralement ds que le modle de donnes a t dfini, on a lhabitude : - de re-crire le document dcrivant les donnes de lapplication en re-formulant le texte partir du modle des donnes pour montrer aux responsables de lapplication comment toute la description des donnes a pu tre prise en compte au niveau modlisation (cest un moyen de sassurer que les concepteurs et les responsables de lapplication sont bien en phase), - dcrire les expressions OCL correspondant aux manipulations attendues les plus courantes pour sassurer que la structure des donnes se prte bien ces manipulations et que les estimations des performances rpondront aux exigences attendues par les utilisateurs finals. Dans ce cours, on prsente les quelques lments du langage OCL permettrant de mettre en pratique ces diffrents points de vue trs importants. Il ne sagit pas de faire une tude dtaille de OCL comme pour le langage SQL. Pour ceux qui seraient intresss par le langage OCL, il existe de trs nombreux sites sur le WEB o lon trouve des cours sur OCL, preuve que le langage a une importance de plus en plus grande. Nous ne verrons dans OCL les aspects les plus proches de SQL : OCL peut tre utilis comme une tape intermdiaire avant dcrire une requte SQL rpondant une question plus ou moins complexe.

2.2

Concepts de base du langage OCL

OCL est un langage rcent qui intgre de nombreux concepts. OCL est un langage sans effet de bord, typ sappliquant sur les objets et les liens dun diagramme de classes objet. Cest un langage fonctionnel, bas sur la logique ensembliste des prdicats du premier degr, navigationnel et dclaratif. Pour crire les expressions OCL, on sappuiera sur la modlisation suivante :

______________________________________________________________________________________ CNAM (2005/2006) : Bases de Donnes (notes de cours)

21
Client nom : String ddn : integer adresse : String age() : Integer = 2006 - self.ddn cl 1..1 Cl_ Fa fa 0..* Facture numro : Integer date_facturation : Integer total_facture : Integer date_paiement : Integer

cl1 : ( dupont, 1980, Toulouse ) cl2 : ( dulong, 1970, Paris ) cl3 : ( ducourt, 1975, A lbi ) cl10 : ( durand, 1985, Toulouse )

f1 : ( 1, 050102, 50, 050201 ) f2 : ( 2, 050102, 100, 050105 ) f3 : ( 3, 051230, 20, 060105 ) f4 : ( 4, 060310, 30, oclUndefined ) f5 : ( 5, 060310, 80, 060401 )

ce qui signifie, par exemple que lobjet dont lidentifiant est f4, est une facture lie lobjet client cl10. Cette facture dont le total est 80 a pour numro 5, a t labore le 10 mars 2006, et a t acquitte le 1er avril 2006. Cette facture a t envoy au client de nom durant, n en 1085 et habitant Toulouse.

2.2.1 OCL est un langage sans effet de bord


OCL est un langage sans effet de bord : OCL na aucune action de modification sur un diagramme dobjets, contrairement aux ordres du LMD SQL (insert, update ou delete) qui permettent la mise jour des donnes dune base relationnelle. De mme, OCL na aucune action sur un diagramme de classes, contrairement aux ordres du LDD SQL (create table, alter table, ) qui permettent de crer et de mettre jour un schma de base relationnelle. Ce qui signifie que toute expression OCL a pour seul objectif de chercher des donnes ou des objets vrifiant des expressions logiques : le langage OCL est au diagramme de classes et au diagramme dobjets ce que le langage de requtes select du langage SQL est une base de donnes relationnelle. Par exemple, pour rechercher les clients qui habitent Toulouse, on crira lexpression OCL : Client.allInstances!select( adresse = Toulouse )

2.2.2 OCL est un langage objet


Les expressions OCL scrivent par rapport un diagramme de classes et sappliquent un diagramme dobjets, instance du diagramme de classes1 : OCL manipule donc des lments qui peuvent tre : - des objets pouvant tre relis entre eux (sans les modifier), - des donnes de type de base : Boolean (true, false), String ( "Toulouse", par exemple), Integer (, -10, , 0, 10, ), Lappel une opration se fait par rapport un lment (objet ou donne) selon le principe classique des langages objet. Par exemple : - cl2.age() donne 362, - "Toulouse".size() donne 8, - "Toulouse".concat( "Paris" ) donne "ToulouseParis", - cl2.ddn donne 19703.
1

Le concept dhritage, essentiel dans les approches objet, nest pas trait 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. 2 On applique lopration age() lobjet cl2 (mme notation pour lapplication de toute opration dfinie dans la classe Personne) ______________________________________________________________________________________ CNAM (2005/2006) : Bases de Donnes (notes de cours)

22 On retrouve les oprateurs classiques sur les donnes de base : +, -, =, <>, >, and, or, , implies if then exemple : exemple : if cl2.age() > 18 then majeur else mineur

else

endif

endif cl2.ddn = oclUndefined( Integer ) =, <>

-- les expressions introduites par -- les mots cls then et else -- doivent tre de mme type -- OCL 1.3

les oprations sur les objets :

2.2.3 OCL est un langage ensembliste


OCL est un langage ensembliste : - une expression permet de rfrencer un ensemble dobjets : Personne.allInstances est une expression OCL qui rfre toutes les instances de la classe Personne - il est possible de dfinir des collections dlments qui peuvent tre des ensembles (Set) contenant des lments sans doublons, des ensembles avec doublons (Bag) ou des squences ordonns dlments (Sequence) : Set{ 10, 20, 0, 5 } donne lensemble sans doublons : { 0, 5, 10, 20 } Set{ "toto", "titi", "tata" } donne lensemble sans doublons : {"tata", "titi", "toto" } Bag{ 10, 20, 0, 5, 10 } donne lensemble avec doublons : { 0, 5, 10, 10, 20 } Set{ p1, p4, p2 } donne lensemble sans doublons : { p1, p2, p4 } La bibliothque OCL offre un trs grand nombre doprations applicables sur les collections. Contrairement la notation pointe concernant lapplication dune opration sur un objet, lapplication dune opration sur une collection se fait laide dune flche : Set{ 10, 20, 0, 5 }!size() donne 4 Client.allInstances!size() donne 4 Client.allInstances!select( c | c.adresse = "Toulouse" ) donne 2 - includes : Set{ 10, 20, 0, 5 }!includes( 0 ) donne true - includesAll : Set{ 10, 20, 0, 5 }!includesAll( Set{ 0, 10 } ) donne true - - including : Set{ 10, 20, 0, 5 }!including( 15 ) donne Set{ 0, 5, 10, 15, 20 } - - union : Set{ 10, 20, 0, 5 }!union( Set{ 5, 0, 30 } ) donne Set{ 0, 5, 10, 30 } Bag{ 10, 20, 0, 5 }!union( Bag{ 5, 0, 0, 30 } ) donne Bag{ 0, 0, 0, 10, 5, 20, 30 } - - iterate : Set{ 10, 20, 0, 5 }!iterate( e ; somme : Integer = 0 | somme + e ) donne 35 ce qui signifie : - somme : Integer = 0 - pour chaque lment e Set{ 10, 20, 0, 5 } - somme = somme + e - rsultat : somme - collect : Set{ 10, 20, 0, 5 }!collect( e | e+1 ) donne Bag{ 1, 6, 11, 21 } ce qui signifie : Set{ 10, 20, 0, 5 }!iterate( e ; ens : Bag( Integer ) = oclEmpty( Set( Integer ) ) | ens!including( e+1 ) )
3

- size :

mme notation pour lapplication de tout attribut dfini dans la classe Personne ______________________________________________________________________________________ CNAM (2005/2006) : Bases de Donnes (notes de cours)

23 -

2.2.4 OCL est un langage bas sur la logique des prdicats du 1er ordre
En logique des prdicats du premier ordre, on a deux types de formules : - les formules ouvertes qui font rfrence des donnes ou des objets : Client.allInstances!select( x | x.adresse = "Toulouse" ) - les formules fermes qui font appel aux quantificateurs existentiel () (opration exists, en OCL), universel () (oprateur forAll, en OCL) et qui retourne donc une valeur boolenne. exemple : - question : - expression OCL : - le rsultat est boolen : existe-t-il un client qui sappelle "dupont" ? Client.allInstances!exists( c | c.nom = "dupont" ) true

exemple : - question : existe-t-il deux clients qui ont le mme nom ? littralement : existe-t-il un client x et un client y, tel que : - x et y sont diffrents - x et y ont le mme nom - expression OCL : Client.allInstances!exists( x, y | x <> y and x.nom = y.nom ) - le rsultat est boolen : true exemple : - question : est-ce que toutes les factures ont des numros diffrents 2 2 ? littralement : il ne doit pas exister deux factures qui ont le mme numro : - expression OCL : not ( Facture.allInstances!exists( x, y | x <> y and x.numero = y.numero ) ) ou littralement : pour tout couple x et y de facture, si x est diffrent de y alors, le numro de x doit tre diffrent du numro de y sinon, lexpression est vrai pour ce couple x, y : - expression OCL : Facture.allInstances!forAll( x, y | if x <> y then x.numero <> y.numero else true endif ) ce qui scrire gnralement avec loprateur dimplication : Facture.allInstances!forAll( x, y | x <> y implies x.numero <> y.numero )

______________________________________________________________________________________ CNAM (2005/2006) : Bases de Donnes (notes de cours)

24

2.3

Lapproche fonctionnelle du langage OCL

Laspect fonctionnel du langage OCL permet dintgrer logiquement les concepts OCL prsents prcdemment.

2.3.1 OCL est un langage fonctionnel


Ce qui signifie que toute expression OCL retourne un rsultat qui peut tre : - une donne de base (Boolean, String, Integer, ) - un objet de lune des classes du diagramme de classes (Client, Facture, ) - une collection de donnes de base (Set( Integer ), Bag( Integer ), Set( String ), ) - une collection dobjets (Set( Client ), Bag( facture ), ) Tout interprte retourne deux informations aprs valuation dune expression OCL : le rsultat et le type du rsultat. Par exemple : Client.allInstances!select( x | x.adresse = "Toulouse" ) retourne Set{ @cl1, @cl10 } : Set( Client ) Client.allInstances!exists( x | x.adresse = "Toulouse" ) retourne true : Boolean Remarque : tant donn que le langage OCL est sans effet de bord (cest--dire que toute expression ne modifie en aucune sorte le diagramme dobjets sur lequel porte lexpression) la notation @cl1 est un pointeur vers lobjet cl1.

2.3.2 Enchanement des oprations sur les collections


Toute expression retourne un rsultat typ, donc on peut appliquer une opration ce rsultat : cest ce que lon appelle lenchanement des oprations. Exemple : - Client.allInstances!select( x | x.adresse = "Toulouse" ) retourne Set{ @cl1, @cl10 } : Set( Client ) Toute opration dfinie sur les ensembles de clients peut tre appliqu ce rsultat. On pourrait alors crire : - Client.allInstances!select( x | x.adresse = "Toulouse" )!size() retourne 2 : Integer - Client.allInstances!select( x | x.adresse="Toulouse")!select( Client.allInstances!select( x | x.ddn > 1980 ) ) retourne Set( @cl10 ) : Set( Client ) Linterprte OCL value lexpression de gauche droite : - tout dabord : Client.allInstances qui retourne Set{@cl1, @cl2, @cl3, @cl10} : Set( Client ) - ensuite : Set{@cl1, @cl2, @cl3, @cl10}!select( x | x.adresse = "Toulouse" ) qui retourne : Set{@cl1, @cl10 } : Set( Client ) - enfin : Set{@cl1, @cl10 }!select( x | x.ddn > 1980 ) qui retourne Set{@cl10} : Set( Client ) - Client.allInstances!select( x | x.adresse = "Toulouse" ).nom Linterprte value la premire partie de lexpression : Client.allInstances!select( x | x.adresse = "Toulouse" ) qui retourne Set{@cl1, @cl10 } : Set( Client )
______________________________________________________________________________________ CNAM (2005/2006) : Bases de Donnes (notes de cours)

25 linterprte value ensuite : Set{@cl1, @cl10 }.nom qui a pour effet de retourner le nom des clients cl1 et cl10. Cette dernire expression retourne donc : Bag{ "dupont", "durand" } : Bag( String )

2.3.3 Navigation des expressions OCL


Les expressions OCL de navigation permettre de retourner des objets qui sont lis entre eux. Par exemple, lexpression OCL : f2 retourne @f2 : Facture, cest--dire quelle fait rfrence lobjet Facture dont lidentifiant est f2. Il existe une association entre la classe Client et la classe Facture, dont les rles sont : - cl au niveau de lextrmit de lassociation vers la classe Client - fa au niveau de lextrmit de lassociation vers la classe Facture. Ce sont ces noms de rles qui sont utiliss dans lexpression pour retrouver les objets lis entre eux. Par exemple pour retrouver le client qui la facture f2 a t adresse, cest--dire le client qui est li f2 dans le cadre des liens dassociations Cl_Fa, on crira lexpression OCL : f2.cl Linterprte value - dabord f2 qui retourne @f2 : Facture - le rle cl permet, linterprte, daccder lobjet client didentifiant cl1, partir de lobjet f2 : on dit que linterprte navigue dans le diagramme dobjets. Exemples : . question : expression OCL : rsultat retourn . question : expression OCL : rsultat retourn . question : expression OCL : rsultat retourn . question : expression OCL : rsultat retourn . question : expression OCL : rsultat retourn qui est envoye la facture f2 ? f2.cl @cl1 : Client nom du client qui est envoye la facture f2 ? f2.cl.nom "dupont" : String factures adresses au client cl1 ? cl1.fa Set{ @f1, @f2, @f3 } : Set( Client ) numros des factures adresses au client cl1 ? cl1.fa.numero Bag{ 1, 2, 3 } : Bag( Integer ) somme totale des factures adresses au client cl1 ? cl1.fa.total_facture!sum() 170 : Integer

2.3.4 Remarque sur la visibilit dun objet


Dans une expression OCL, aprs un identifiant dobjet, on peut rajouter : . rien : cl1 retourne @cl1 : Client . un attribut de la classe cl1.nom retourne "dupont" : String . une opration de la classe cl1.age() retourne 26 : Integer . un rle dune association partant de la classe cl1.fa retourne Set{ @f1, @f2, @f3 } : Facture Il en est de mme pour une collection dune classe dobjets : . Client.allInstances retourne lensemble des clients
______________________________________________________________________________________ CNAM (2005/2006) : Bases de Donnes (notes de cours)

26 . Client.allInstances.nom . Client.allInstances.age() . Client.allInstances.fa retourne les noms des clients retourne les ges des clients retourne les factures adresses tous les clients

Rappel : une opration sappliquant une collection est introduite par la flche : . Client.allInstances!select( c | c.nom = "dupont" ) . Client.allInstances!select( c | c.nom = "dupont" ).ddn . Client.allInstances!select( c | c.nom = "dupont" ).age() . Client.allInstances!select( c | c.nom = "dupont" ).fa . Client.allInstances!select( c | c.nom = "dupont" ).numero . Lensemble des attributs : nom, ddn, adresse, de lopration age(), du rle fa constitue ce que lon appelle la visibilit de tout objet Client. Les noms de rle servent naviguer.

2.3.5 Quelques expressions OCL


Toute expression OCL est donc construite de gauche droite, en alternant les lments de visibilit et les oprations sur les collections. Un filtre peut apparatre dans une expression boolenne : il se construit selon le mme principe. Exercice : quoi correspond chacune des expressions OCL suivante : . f1 . f1.cl . f1.cl.fa . cl1.fa!select( f | f.total_facture > 30 ) . cl1.fa!select( f | t.total_facture > 30 )!size() . . Client.allInstances!select( c | c.nom = "dupont" ) . Client.allInstances!exists( c | c.nom = "dupont" ) . Client.allInstances!exists( c | c.fa!exists( f | f.total_facture > 30 ) ) . Client.allInstances!select( c | c.fa!exists( f | f.total_facture > 30 ) )

2.4

Modlisation : diagramme de classes + contraintes dintgrit OCL

Les expressions OCL retournant une valeur boolenne peuvent tre utilises pour spcifier les lments de modlisation qui ne peuvent pas tre exprims laide dun diagramme de classes. Ces expressions sont appeles des invariants qui ont une syntaxe particulire. A notre niveau denseignement, il sera suffisant de les crire comme une formule ferme. Exemple : On reprend lexercice sur les clients et les factures. On rajoute les contraintes suivantes : - tout client a plus de 21 ans - le total de toute facture est positif - 2 factures ne peuvent pas avoir le mme numro - tout client ne peut pas avoir plusieurs factures non payes (ce qui pourrait signifier que lon refuserait de livrer des produits un client qui naurait pas encore acquitt sa dernire facture. La modlisation de lapplication des donc la suivante :

______________________________________________________________________________________ CNAM (2005/2006) : Bases de Donnes (notes de cours)

27
Client nom : String ddn : integer adresse : String age() : Integer = 2006 - self.ddn cl 1..1 Cl_ Fa fa 0..* Facture numro : Integer date_facturation : Integer total_facture : Integer date_paiement : Integer

Client.allInstances!forAll( c | c.age() > 21 ) Facture.allInstances!forAll( f | f.total_facture > 0 ) Facture.allInstances!forAll( f1, f2 | f1 <> f2 implies f1.numero <> f2.numero ) Client.allInstances!forAll( c | c.fa!select( f | f.date_paiement ) = oclUndefined( Integer ) < 2 ) )

______________________________________________________________________________________ CNAM (2005/2006) : Bases de Donnes (notes de cours)

28

3
3.1

Transformation dun diagramme de classes en un schma relationnel


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.

3.2

Transformation dune classe dans le modle relationnel

3.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.
X X1 X2 ... x1 : X( x11, x12, ... ) x2 : X( x21, x22, ... ) ... X( X1, X2, ... ) x11, x12, ... x21, x22, ... ...

Exemple :
Voiture numro : String marque : String Voiture( numro, marque ) 1 AA 31, renault 3 BB 75, renault

v1 : Voiture( 1 AA 31, renault ) v2 : Voiture( 3 BB 75, renault )

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

3.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 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.
______________________________________________________________________________________ CNAM (2005/2006) : Bases de Donnes (notes de cours)

29 On a donc la correspondance diagramme de classes/schma relationnel suivante :


X X1 X2 ... x1 = X( , ... ) x2 = X( ... ) ... X( X_I D, X1, X2, ... ) x1, ... x2, ... ...

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

- pr-conditions :

3.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 :
Voiture numro : String marque : String Voiture( Voiture_ID, numro, marque ) v1, 1 AA 31, renault v2 3 BB 75, renault

v1 : Voiture( 1 AA 31, renault ) v2 : Voiture( 3 BB 75, renault )

SQL> create table Voiture(

Voiture_ID numero marque

varchar( 10 ) primary key, number, varchar( 10 )

);

3.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 :

______________________________________________________________________________________ CNAM (2005/2006) : Bases de Donnes (notes de cours)

30 Voiture.allInstances!forAll( v1, v2 | if v1 <> v2 endif then else v1.numero <> v2.numero true )

Dans ce cas, le schma relationnel et le code du LDD SQL peuvent tre simplifis, et le passage au niveau relationnel peut tre reprsente par la figure suivante :
Vo iture numro : Integer marque : String Vo iture( numro, marque )

SQL> create table Voiture(

numero marque

number primary key, varchar( 10 )

);

3.3

Principe de transformation des associations et des liens en relationnel

3.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 :
Propritaire estProptDe Personne lePropt 1..1 0..* p1 : Personne = ( ... ) p2 : Personne = ( ... ) p3 : Personne = ( ... ) Vo iture

v1 : Vo iture = ( ... ) v2 : Vo iture = ( ... )

La transformation en relationnel dun tel diagramme se fait, intuitivement, selon les tapes suivantes : -1- chaque classe correspond une relation :
Propritaire estProptDe Personne lePropt 1..1 0..* p1 : Pe rsonne = ( ... ) p2 : Pe rsonne = ( ... ) p3 : Pe rsonne = ( ... ) Personne( Personne_ID, ... ) p1, ... p2, ... p3, ... Vo iture( Voiture_ ID, ... ) v1, ... v2, ...

Vo iture

v1 : Vo iture = ( ... ) v2 : Vo iture = ( ... )

-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 :

______________________________________________________________________________________ CNAM (2005/2006) : Bases de Donnes (notes de cours)

31
Propritaire estProptDe Personne lePropt 1..1 0..* p1 : Pe rsonne = ( ... ) p2 : Pe rsonne = ( ... ) p3 : Pe rsonne = ( ... ) Personne( Personne_ID, ... ) p1, ... p2, ... p3, ... Vo iture( Voiture_ ID, ... , lePropt ) v1, ... p1 v2, ... p1

Vo iture

v1 : Vo iture = ( ... ) v2 : Vo iture = ( ... )

-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 le 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 :
Propritaire lePropt estProptDe Personne 1..1 0..* p1 : Personne = ( ... ) p2 : Personne = ( ... ) p3 : Personne = ( ... ) Personne( Personne_ID, ... ) p1, ... p2, ... p3, ... Vo iture( Voiture_ ID, ... , lePropt ) v1, ... p1 v2, ... p1

Vo iture

v1 : Vo iture = ( ... ) v2 : Vo iture = ( ... )

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

3.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).

3.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..*.
______________________________________________________________________________________ CNAM (2005/2006) : Bases de Donnes (notes de cours)

32 Dans ce paragraphe, on montre comment, dune manire gnrale, les associations se traduisent en relationnel : on tudie dabord la cas dune association dont les multiplicits sont 0..* / 0..*, cest--dire sans contraintes particulires. On en dduira ensuite, pour chacune des autres multiplicits (0..1 / 1..* , par exemple) comment se traduisent en relationnel les diffrentes contraintes quelles expriment.

3.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 :

X x1, x2, x3, x4, ... ... ... ...

rx 0..*

ry 0..*

Y y1, ... y2, ... y3, ...

Y( Y_ID, Y1, 2, ... ) X( X_I D, X1, X2, ... ) x1, ... x1, ... x2, ... x2, ... ... ... A( A_ID, rx,ry ) a1, x2, y1 a2, x2, y3 a3, x4, y3

- remarque :

. A( rx ) X( X_ID ), A( ry ) Y( Y_ID ) . X et Y sont des relations de base ; A est une relation dassocation exprimant des liens entre les tuples des relations X et Y. . les nom de rles rx et ry sont diffrents, et sont diffrents du nom de lassociation.

- pr-conditions :

- gnration du code du LDD SQL : SQL> create table X( SQL> create table Y( SQL> create table A( X_ID X1 Y_ID Y1 A_ID rx ry varchar( 10 ) primary key, , ); varchar( 10 ) primary key, , ); varchar( 10 ) primary key, varchar( 10 ) references X( X_ID ), varchar( 10 ) references Y( Y_ID )

);

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.

3.4.2 Exemple
Inscription inscritEn etuInscrit 0..* 0..* Etudiant( Etudi ant_ ID, ... ) Module( Module_ID, ... ) Inscription( Inscripti on_ ID, etuInscrit, inscritEn )

Etudiant

Module

______________________________________________________________________________________ CNAM (2005/2006) : Bases de Donnes (notes de cours)

33 SQL> create table etudiant( Etudiant_ID , Module_ID , varchar( 10 ) primary key, ); varchar( 10 ) primary key, );

SQL> create table Module(

SQL> create table Inscription( Inscription_ID varchar( 10 ) primary key, etuInscrit varchar( 10 ) references Etudiant( Etudiant_ID ), inscritEn varchar( 10 ) references Module( Module_ID ) ) ; 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 :
Inscription inscritEn etuInscrit 0..* 0..* Etudiant( numEtu, numSS, no m ) Module( nom, nbeH ) Inscription( Inscripti on_ ID, etuInscrit, inscritEn )

Etudiant numEtu numSS nom

Module nom nbeH

SQL> create table etudiant(

numEtu numSS nom nom nbeH

varchar( 10 ) primary key, number unique not null, varchar( 10 ) varchar( 10 ) primary key, number

); );

SQL> create table Module(

SQL> create table Inscription( Inscription_ID varchar( 10 ) primary key, etuInscrit varchar( 10 ) references Etudiant( numEtu ), inscritEn varchar( 10 ) references Module( nom ) ) ;

3.5

Transformation dune association en relationnel (en tenant compte des contraintes de multiplicits)

Il suffit dappliquer les rgles de passage dun diagramme de classes en un schma relationnel dont lassociation correspond au cas gnral ( 0..* / 0..* ), et de rajouter la (ou les) contrainte(s) de multiplicits qui se traduisent en relationnel sous la forme de cl et/ou de dpendance rfrentielle ventuellement double-sens.

3.5.1 Multiplicits 0..* / m..M


cas : 0..* / 0..1 Dans ce cas, tout objet x de X ne peut tre associ qu, au plus, un objet y de Y. Cela signifie que lon ne peut pas avoir deux tuples de la relation dassociation A qui ont la mme valeur pour lattribut rx. A( rx ) est donc une cl de la relation A.

______________________________________________________________________________________ CNAM (2005/2006) : Bases de Donnes (notes de cours)

34 - diagramme de classes et schma relationnel


X x1, x2, x3, x4, ... ... ... ... rx 0..* A ry 0..1 Y y1, ... y2, ... y3, ... Y( Y_ID, Y1, 2, ... ) X( X_I D, X1, X2, ... ) x1, ... y1, ... x2, ... y2, ... x3, ... y3, ... A( A_ID, rx,ry ) x4, ... a1, x1, y1 a2, x2, y1 a3, x4, y3

- proprits : - remarques :

A( rx ) X( X_ID ), A( ry ) Y( Y_ID ) . la relation A possde 2 cls : une cl primaire et une cl secondaire (unique not null), . la cl primaire peut tre report sur lattribut rx.

- lordre de cration de la table A est le suivant : SQL> create table A( A_ID varchar( 10 ) primary key, rx varchar( 10 ) references X( X_ID ) ry varchar( 10 ) references Y( Y_ID ) unique not null, );

cas : 0..* / 1..* Dans ce cas, tout objet x de x doit tre li , au moins, un objet y de Y. Ce qui signifie que lidentifiant de tout tuple x de la relation X doit se retrouver dans la colonne rx de la relation dassociation A : on a donc une dpendance rfrentielle double sens, tel que le montre la figure suivante :
X x1, x2, x3, x4, ... ... ... ... rx 0..* A ry 1..* Y y1, ... y2, ... y3, ... X( X_I D, X1, X2, ... ) Y( Y_ID, Y1, 2, ... ) x1, ... y1, ... x2, ... y2, ... x3, ... A( A_ID, rx,ry ) x4, ... a1, x1, y1 a2, x2, y1 a3, x3, y1 a4, x3, y1 a5, x4, y3

______________________________________________________________________________________ CNAM (2005/2006) : Bases de Donnes (notes de cours)

35 - proprits : - remarques : A( rx ) X( X_ID ), X( X_ID ) A( rx ), A( ry ) Y( Y_ID ) . la dpendance rfrentielle est double-sens et ne pourra pas tre traduite en LDD SQL : elle devra tre intgre au niveau applicatif ( laide de procdures vrifiant cette contrainte).

Le schma relationnel exprimable en LDD SQL est donc le suivant :


X x1, x2, x3, x4, ... ... ... ... rx 0..* A ry 1..* Y y1, ... y2, ... y3, ... X( X_I D, X1, X2, ... ) Y( Y_ID, Y1, 2, ... ) x1, ... y1, ... x2, ... y2, ... x3, ... y3, ... A( A_ID, rx,ry ) x4, ... a1, x1, y1 a2, x2, y1 a3, x3, y1 a4, x3, y1 a5, x4, y3

- code du LDD SQL que lon dduit de ce schma relationnel : SQL> create table X( SQL> create table Y( SQL> create table A( X_ID X1 Y_ID Y1 A_ID rx ry varchar( 10 ) primary key, , ); varchar( 10 ) primary key, , ); varchar( 10 ) primary key, varchar( 10 ) references X( X_ID ), varchar( 10 ) references Y( Y_ID ) );

auquel il faut rajouter des triggers ou de sous-programmes pour vrifier lors des mises jour la dpendance rfrentielle double-sens qui a t supprime.

cas : 0..* / 1..1 Dans ce cas, on cumule les deux contraintes : tout objet x doit tre li un (et un seul) objet y de Y. - diagramme de classes et schma relationnel
X x1, x2, x3, x4, ... ... ... ... rx 0..* A ry 1..1 Y y1, ... y2, ... y3, ... Y( Y_ID, Y1, 2, ... ) X( X_I D, X1, X2, ... ) x1, ... y1, ... x2, ... y2, ... x3, ... A( A_ID, rx,ry ) x4, ... a1, x1, y1 a2, x2, y1 a3, x3, y1 a4, x4, y3

- proprits : - remarques :

A( rx ) X( X_ID ), X( X_ID ) A( rx ), A( ry ) Y( Y_ID ) . du fait que X( I_ID ) et A( rx ) sont cls et sont lis par une dpendance rfrentielle double-sens, lattribut ry pourrait tre report dans la relation X, . en fait, dans ce cas la relation A est inutile, et lon pourrait avoir e schma relation, tel quil a t dfini intuivement au paragraphe 3.3 : mais le fait de supprimer la

______________________________________________________________________________________ CNAM (2005/2006) : Bases de Donnes (notes de cours)

36 relation dassociation A entrane une perte de modlisation : rx. Cest pourquoi, on prfre garder la relation de lien A, en reportant ventuellement la cl primaire sur lattribut rx.

Pour les autres cas de multiplicits, on donne les structures de donnes quivalentes. Le code du LDD SQL pourra en tre dduit en appliquant les rgles dfinies ci-dessus pour chaque type de multiplicits.

3.5.2 Multiplicits 0..1 / m..M


cas : 0..1 / 0..*
X rx 0..1 A ry 0..* Y X( X_ ID, X1, X2, ... ) Y( Y_ ID, Y1, Y2, ... )

A( A_ ID, rx,ry )

cas : 0..1 / 0..1


X rx 0..1 A ry 0..1 Y X( X_ ID, X1, X2, ... ) Y( Y_ ID, Y1, Y2, ... )

A( A_ ID, rx,ry )

exemple (trs classique) :


Homme Mariage epoux epouse 0..1 0..1 Homme( Homme_ ID, ... ) Femme Mariage( Mariage_ID, epoux, epouse ) Femme ( Femme_ID, ... )

code du LDD SQL : SQL> create table Homme( SQL> create table Femme( SQL> create table Mariage(

Homme_ID varchar( 10 ) Femme_ID varchar( 10 )

primary key, ); primary key,

); Mariage_ID varchar( 10 ) primary key, epoux varchar( 10 ) references Homme( Homme_ID ) unique not null, epouse varchar( 10 ) references Femme( Femme_ID ) unique not null );

cas : 0..1 / 1..*


X rx 0..1 A ry 1..* Y X( X_ ID, X1, X2, ... ) Y( Y_ ID, Y1, Y2, ... )

A( A_ ID, rx, ry )

______________________________________________________________________________________ CNAM (2005/2006) : Bases de Donnes (notes de cours)

37 cas : 0..1 / 1..1


X rx 0..1 A ry 1..1 Y X( X_ ID, X1, X2, ... ) Y( Y_ ID, Y1, Y2, ... )

A( A_ ID, rx, ry )

ou plus simplement :
X rx 0..1 A ry 1..1 Y Y( Y_ ID, Y1, Y2, ... )

X( X_ ID, X1, X2, ... , ry )

3.5.3 Multiplicits 1..* / m..M


cas : 1..* / 0..*
X rx 1..* A ry 0..* Y X( X_ ID, X1, X2, ... ) Y( Y_ ID, Y1, Y2, ... )

A( A_ ID, rx, ry )

cas : 1..* / 0..1


X rx 1..* A ry 0..1 Y X( X_ ID, X1, X2, ... ) Y( Y_ ID, Y1, Y2, ... )

A( A_ ID, rx, ry )

cas : 1..* / 1..*


X rx 1..* A ry 1..* Y X( X_ ID, X1, X2, ... ) Y( Y_ ID, Y1, Y2, ... )

A( A_ ID, rx, ry )

cas : 1..* / 1..1


X rx 1..* A

ry 1..1 Y X( X_ ID , X1, X2, ... ) Y( Y_ ID , Y1, Y2, ... )

A( A_ ID, rx, ry )

______________________________________________________________________________________ CNAM (2005/2006) : Bases de Donnes (notes de cours)

38 ou plus simplement :
X rx 1..* A ry 1..1 Y Y( Y_ ID, Y1, Y2, ... )

X( X_ ID, X1, X2, ... , ry)

3.5.4 Multiplicits 1..1 / m..M


cas : 1..1 / 0..*
X rx 1..1 A ry 0..* Y X( X_ ID, X1, X2, ... ) Y( Y_ ID, Y1, Y2, ... )

A( A_ ID, rx, ry )

ou plus simplement :
X rx 1..1 A ry 0..* Y X( X_ ID, X1, X2, ... )

Y( Y_ ID, Y1, Y2, ... , ry)

cas : 1..1 / 0..1


X rx 1..1 A ry 0..1 Y X( X_ ID, X1, X2, ... ) Y( Y_ ID, Y1, Y2, ... )

A( A_ ID, rx, ry )

ou plus simplement :
X rx 1..1 A ry 0..1 Y X( X_ ID, X1, X2, ... )

Y( Y_ ID, Y1, Y2, ... , rx )

cas : 1..1 / 1..*


X rx 1..1 A ry 1..* Y X( X_ ID, X1, X2, ... ) Y( Y_ ID, Y1, Y2, ... )

A( A_ ID, rx, ry )

ou plus simplement :
X rx 1..1 A ry 1..* Y X( X_ ID, X1, X2, ... )

Y( Y_ ID, Y1, Y2, ... , rx )

______________________________________________________________________________________ CNAM (2005/2006) : Bases de Donnes (notes de cours)

39 cas : 1..1 / 1..1


X rx 1..1 A ry 1..1 Y X( X_ ID, X1, X2, ... ) Y( Y_ ID, Y1, Y2, ... )

A( A_ ID, rx, ry )

3.5.5 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 :
Maire estMaireDe leMaire 0..1 1..1 habitant rsidence 1..* 1..1 Adresse Electeur( Electeur_ ID, ... , residence ) Ville Ville( Ville_ID, ... , leMaire )

Electeur

Dans ce cas, pour pouvoir crire le code du LDD SQL, il faut supprimer une dpendance, par exemple :
Maire estMaireDe leMaire 0..1 1..1 habitant rsidence 1..* 1..1 Adresse Electeur( Electeur_ ID, ... , residence ) Ville Ville( Ville_ID, ... , leMaire )

Electeur

en dduire le code du LDD SQL correspondant et rajouter des triggers ou des sous-programmes pour vrifier la contrainte supprime, savoir : tout lecteur rside dans une ville , et que toute ville a au moins un lecteur qui y rside.

______________________________________________________________________________________ CNAM (2005/2006) : Bases de Donnes (notes de cours)

40

Rsum, Bilan

Dans cet enseignement, on a cherch montrer que la modlisation des donnes dune application se fait selon une dmarche en trois tapes : - le diagramme de classes, complt ventuellement par des contraintes (spcifications OCL), - le schma relationnel, avec ses cls primaires et secondaires, et ses dpendances rfrentielles, - le code du LDD SQL, avec ses cls primaires, secondaires (unique not null) et trangres et ses contraintes syntaxiques (rfrence en avant, circuit, ) imposes pour des raisons pragmatiques de mises jour des donnes et de performances des programmes dapplication. A ce code, il est possible de rajouter des index de relations pour amliorer les performances, si ncessaire.

Cette dmarche de conception et ralisation dapplications oriente donne rpond plusieurs objectifs : - sparation des proccupations, en faisant apparatre les problmes au fur et mesure : . dfinition des objets et des liens de lapplication, partir de lexpression des besoins, . dfinition du modle de donnes selon la plate-forme qui prendra en charge lapplication : ici, cest le modle relationnel avec ses concepts dfinissant la structure des donnes et leurs implantations, . dduction du code source (LDD SQL) avec ses contraintes de programmation trs spcifiques ; - chacun, ses proccupations : . lanalyste/concepteur dfinit le diagramme de classes avec les responsables de lapplication, partir de lexpression des besoins, . le concepteur/dveloppeur dfinit le schma relationnel partir de diagramme de classes, . ladministrateur de la base de donnes dfinit les codes du LDD SQL et les programmes dapplication partir du schma relationnel, et rajoutant les ventuels les index pour rpondre aux exigences des utilisateurs finals. - chacun, avoir la possibilit de suivre ce que font les autres pour comprendre les problmes qui se posent au fur et mesure : . cest le rle du schma relationnel qui fait le lien la conception et limplantation proprement dite des donnes, . cest la possibilits de dfinir de faon dynamique les index de relations sans changer la conception des donnes.

Cet enseignement fait ressortir 2 aspects : . laspect technique : le modle relationnel et les outils qui gravitent autour, . les aspects mthodologiques (dmarches) qui montrent comment on a lhabitude daborder les problmes, de les rsoudre (avec les moyens du bord) et comment on peut matriser les aspects techniques. Les aspects techniques sont gnralement imposs dans le contexte o lon travaille, cest chacun (ou cest le rle du responsable de lquipe) de dfinir les aspects mthodologiques les plus appropris pour mener bien le projet dans lequel on est impliqu.

______________________________________________________________________________________ CNAM (2005/2006) : Bases de Donnes (notes de cours)