Vous êtes sur la page 1sur 2

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

Etudiant
-nom: String
-adresse: String

+LesInscrits
Inscrire

0..*

+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

Affecter

1..*

1
+LeDir

+DeptAff

Diriger

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