Post on 13-Nov-2015
description
CNAM UML et les Bases de Donnes 9
Grgory Claude 2010 2011
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
Module
-code: String-thme: String-nbHeures: Integer
Inscrire
+InscritEn+LesInscrits
10..*
Mme question pour ce diagramme de classes :
Employe
-nom: String-adresse: String
Departement
-nom: String-activite: String
Affecter +DeptAff+LesEmp
11..*
Diriger +EstDirDe+LeDir
0..11
Responsable
+estRespDe
+resp
0..*
0..1
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 :
CNAM UML et les Bases de Donnes 10
Grgory Claude 2010 2011
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
ProduitFactur
-nomDuProduit: String-quantitFacture: Integer
Facturer +pf+f
1..*1
Exemple dinstance (diagramme dobjets) de ce diagramme de classes :