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
:
