Chapitre 9 : De UML au
Relationnel
1
[Link] du diagramme de classes en un
schéma relationnel
Afin de réaliser la persistance des objets du SI, il est important de les
stocker dans une base de données.
Le modèle de données le plus utilisé aujourd’hui est le modèle relationnel.
Les règles de validation appliquées au modèle entité-association peuvent
être transposées au diagramme de classes.
Pour réaliser la transformation d’un diagramme de classes en un schéma
relationnel, nous partons d’un diagramme sur lequel on a déjà appliqué les
règles de validations.
L’application des règles de validation permet de limiter les risques d’erreur
de modélisation lourdes de conséquences au niveau de la base de données.
2
Remarques :
La transformation ne concerne que la partie statique du diagramme.
Elle suppose que toutes les classes du diagramme sont persistantes.
Le diagramme de classes à transformer ne doit pas contenir d’attributs
multivalués.
3
Transformation des classes (R1):
Chaque classe devient une relation.
Le nom de la classe sera le nom de la relation.
Le nom des attributs de la relation sont issus des noms des attributs de la
classe.
Exemple :
Avion
code : chaîne R1 Avion(code, type)
type : chaîne
Cette transformation n’est directement possible que si les attributs de la
classe sont atomiques (entier, chaîne,…), qui devront être adaptés, selon le
cas, en type SQL (varchar, number ou date).
4
Il faut choisir un ou plusieurs attributs de la classe pouvant jouer le rôle de
clé primaire.
Si aucun attribut ne convient en tant que clé, il faut en ajouter un à la
relation.
Exemples :
Avion
code : chaîne R1 Avion(code, type)
type : chaîne
CREATE TABLE Avion ( code VARCHAR(10) PRIMARY KEY, type VARCHAR(30));
5
Livre
titre : chaîne R1 Livre(idLivre, titre, nbPages)
nbPages : entier
CREATE TABLE Livre ( idLivre VARCHAR(10) PRIMARY KEY, titre VARCHAR(50),
nbPages NUMBER(4));
6
Transformation des associations
Associations 1-* , 1-N (R2)
• Il faut ajouter un attribut de type clé étrangère dans la relation fils de
l’association (le côté * ou N). L’attribut porte le nom de la clé primaire
de la relation père de l’association ( le côté 1).
• Exemple :
7
LDD
CREATE TABLE Compagnie (numéro VARCHAR(10) PRIMARY KEY, nom
VARCHAR(50));
CREATE TABLE Avion (code VARCHAR(10) PRIMARY KEY, type VARCHAR(30),
numéro VARCHAR(10));
ALTER TABLE Avion ADD CONSTRAINT FK_CompagnieAvion FOREIGN KEY
(numéro) REFERENCES Compagnie(numéro));
8
Association *-*, n-aires et classes-associations (R3)
• L’association/classe-association devient une relation.
La clé primaire de cette relation est la concaténation
des clés des relations issues des classes connectées
à l’association. Chaque attribut devient une clé
étrangère si la classe dont il provient devient une
relation.
• Les attributs de l’association attribuée/classe-
association doivent être ajoutés à la nouvelle
relation. Ces attributs ne sont ni clé primaire, ni clé
étrangère.
9
• Exemple :
Avion
code
type Compagnie (numéro, nom)
Affréter 1..* Affréter(code#, numéro#,
R1 et R3 dateAff)
dateAff
0..* Avion(code, type)
Compagnie
numéro
nom
10
LDD
CREATE TABLE Avion (code VARCHAR(10) PRIMARY KEY, type
VARCHAR(30));
CREATE TABLE Compagnie (numéro VARCHAR(10) PRIMARY KEY, nom
VARCHAR(50));
CREATE TABLE Affreter (code VARCHAR(10), numéro VARCHAR(10),
dateAff date);
ALTER TABLE affreter ADD CONSTRAINT PK_Affreter PRIMARY KEY (code,
numéro);
ALTER TABLE affreter ADD CONSTRAINT FK_AffreterCompagnie FOREIGN
KEY (numéro) REFERENCES Compagnie(numéro);
ALTER TABLE affreter ADD CONSTRAINT FK_AffreterAvion FOREIGN KEY
(code) REFERENCES Avion(code);
11
Associations 1-1 (R4)
• Il faut ajouter un attribut de type clé étrangère dans
la relation dérivée de la classe attachée à la patte
dont la multiplicité minimale est égale à 0. L’attribut
porte le nom de la clé primaire de la relation dérivée
de la classe connectée à l’association.
• Si les deux multiplicités minimales sont à zéro, le
choix est donné entre les deux relations dérivées des
classes connectées.
• Si les deux multiplicités minimales (et maximales)
sont à 1, il est préférable de fusionner les deux
classes en une seule.
12
• Exemple :
• Exemple :
CREATE TABLE Stage (numéro VARCHAR(10) PRIMARY KEY, entreprise
VARCHAR(50));
CREATE TABLE Etudiant (matricule VARCHAR(6) PRIMARY KEY, nom
VARCHAR(30), numéro VARCHAR(10) );
ALTER TABLE Etudiant ADD CONSTRAINT FK_EtudiantStage FOREIGN
KEY(numéro) REFERENCES Stage(numéro);
13
Cas de la composition
• La règle R2 (resp. R4) est toujours applicable.
• Dans certains cas, il est possible de définir dans la
relation issue du composant une clé primaire
composée, constituée de l’attribut choisi pour jouer
le rôle de clé et de la clé de la relation issue de la
classe du composé.
• Exemple :
Livre (isbn,…)
1..* Chapitre
Livre Chapitre (#isbn,numéro,…)
numéro R2’
isbn
… …
14
LDD :
CREATE TABLE Livre (isbn VARCHAR(13) PRIMARY KEY, …);
CREATE TABLE Chapitre (isbn VARCHAR(13), numéro number(2),…);
ALTER TABLE Chapitre add constraint PK_Chapitre PRIMARY KEY
(isbn, numéro);
ALTER TABLE Chapitre ADD CONSTRAINT FK_ChapitreLivre
FOREIGN KEY (isbn) REFERENCES Livre(isbn) on delete cascade;
15
Transformation des généralisations
Il existe 3 façons possibles pour traduire les généralisations :
Décomposition par distinction (RG1)
• La classe générale ainsi que les sous classes sont transformées en
relations.
• La clé primaire de la classe générale migre dans la ou les relations
issues des sous-classes et devient à la fois clé primaire et clé
étrangère.
16
• Exemple
Salarié Mensualisé (matricule #,
matricule salaireBase, hSup)
nom
adresse RG1 Salarié (matricule, nom,
adresse)
Horaire Horaire (matricule#,
Mensualisé
salaireBase nbHMensuelles nbHMensuelles, tauxHoraire)
hSup tauxHoraire
17
LDD :
CREATE TABLE Salarié (matricule VARCHAR(6) PRIMARY KEY, …);
CREATE TABLE Mensualisé (matricule VARCHAR(6) PRIMARY KEY, …);
CREATE TABLE Horaire (matricule VARCHAR(6) PRIMARY KEY, …);
ALTER TABLE Mensualisé ADD CONSTRAINT FK_MatriculeM FOREIGN KEY
(matricule) REFERENCES Salarie(matricule) on delete cascade;
ALTER TABLE Horaire ADD CONSTRAINT FK_MatriculeH FOREIGN KEY
(matricule) REFERENCES Salarie(matricule) on delete cascade;
18
Décomposition descendante (RG2)
• La classe générale n’est pas traduite en une
relation. Il faut alors faire migrer tous ses
attributs dans la ou les relations issues des sous-
classes.
• Cette solution est généralement adoptée lorsqu’il
existe une contrainte {complet} ou {complet,
disjoint} sur la généralisation.
19
Exemple
Mensualisé
Salarié (matriculeM, nom,
matricule adresse, salaireBase,
nom
adresse RG2 hSup)
{complet, disjoint}
Horaire
Mensualisé Horaire (matriculeH, nom,
salaireBase nbHMensuelles
adresse,
hSup tauxHoraire
nbHMensuelles,
tauxHoraire)
20
LDD :
CREATE TABLE Mensualisé (matriculeM VARCHAR(6) PRIMARY KEY, nom
varchar(50), adresse varchar(50), salaireBase float(8,3), hSup int);
CREATE TABLE Horaire (matriculeH VARCHAR(6) PRIMARY KEY, nom
varchar(50), adresse varchar(50), tauxHoraire float (6,3), Type varchar(10));
21
Décomposition ascendante (RG3)
Il faut supprimer la ou les relations issues de la ou des sous-
classes et faire migrer les attributs dans la relation issue
de la classe générale.
Salarié
matricule
nom Salarié (matricule, nom,
adresse adresse, salaireBase,
RG3
hSup, nbHMensuelles,
tauxHoraire, type)
Mensualisé Horaire
salaireBase nbHMensuelles
hSup tauxHoraire
22
LDD :
CREATE TABLE Salarié (matricule VARCHAR(6) PRIMARY KEY, nom
varchar(50), adresse varchar(50), salaireBase float(8,3), hSup int,
nbHMensuelles int, tauxHoraire float (6,3), Type varchar(10));
23