1

20:17
2
REFERENCES
 Jeffrey D. Ullman and Jennifer Widom. A First Course in
DATABASE SYSTEMS, Third Edition , Pearson Eduction, 2008
 E.F. Codd, A relational model for large shared data banks, Comm.
ACM 13:6, pp.377-387, 1970.
 Conception de Bases de Données Relationnelles, Marc Plantevit,
Faculté de Sciences et Technologie - Laboratoire LIRIS -Université
Lyon 1
 Modélisation des bases de données: UML et les modèles entité-
association, 4eEdition; Christian Soutou avec la contribution de
Frédéric Brouard, Edition EYROLLES.

20:17
3

Mai 2022

20:17
4
INTRODUCTION
La séparation de la définition logique des
données de son implémentation physique est
fondamentale pour la description des bases de
données.
Des modèles de données logiques ont été définis,
visant à permettre à l’utilisateur de se
concentrer uniquement sur une représentation
logique des données sans se soucier de la
20:17

représentation physique des données..

5
INTRODUCTION
Plusieurs modèles ont été développés,
comprenant les modèles:
 hiérarchiques,
en réseaux,
relationnels,
et orientés objet.
20:17
6
INTRODUCTION
La séparation des aspects logique et
physique permet:
 un accroissement extraordinaire de
l’utilisation des bases de données et de la
productivité des programmeurs
plusieurs aspects de l’implémentation physique
peuvent être changés sans avoir à modifier la
vision abstraite de la base de données. 20:17
7
INTRODUCTION
La séparation des niveaux logique et physique
est appelée principe d’indépendance des
données.
Elle est la distinction la plus importante qui
existe entre les systèmes de fichiers et les
systèmes de bases de données.

20:17
8
INTRODUCTION
En pratique, le modèle relationnel est, de loin, le
plus utilisé de tous les modèles de données.
Il existe quelques SGBD objet, mais rencontrent
des problèmes de performances pour les gros
volumes de données, dus à l’exécution en
cascade de méthodes lors des parcours de
données.
20:17
9
INTRODUCTION
Des SGBD XML ont aussi plus récemment vu le
jour, et sont utilisés, mais n’égalent pas les
performances du modèle relationnel.
Les principaux SGBD relationnels intègrent de
plus en plus des extensions permettant de
“percevoir” les données sous la logique objet ou
XML, mais utilisant derrière des bases de
données relationnelles pour stocker les données.
20:17
10
INTRODUCTION
Le modèle de données relationnel repose sur des
principes simples et permet néanmoins de modéliser
des données complexes.
La description des données repose sur le concept de
relations.
Il est aussi possible de modéliser un schéma relationnel
avec le formalisme UML.

20:17
11
CONCEPTS
Le modèle relationnel tire son nom de la notion
de relation mathématique entre des éléments.
Chacun de ces éléments peut prendre des
valeurs dans un ensemble défini.
Une relation possède des attributs.
Chaque attribut prend sa valeur dans un
domaine (ensemble de valeurs).
20:17
12
CONCEPTS
L’approche relationnelle modélise les faits de la vie
réelle par des tuples (enregistrements), qui sont des
ensembles de valeurs de différents champs (ou
attributs) :
Ex: (Karire, Emelyne, 23ans) est un tuple qui
représente des valeurs des champs ‘Nom’, ‘Prénom’,
‘Age’ liées dans le monde réel.

20:17
13
CONCEPTS
L’ensemble des tuples s’appelle une relation.
Il s’agit du concept de base qui sera manipulé
par l’approche relationnelle et peut être
représenté sous la forme d’une table.

20:17
14
CONCEPTS
On utilise la clé d’une relation pour identifier un
tuple. La clé est constituée d’un ou de plusieurs
champs de la relation.
Elle est établie en utilisant le concept de dépendance
fonctionnelle entre les différents champs.
La définition des clés est un acte de modélisation, elle
ne renvoie pas à une vérité intangible, mais à la réalité
telle qu'elle est représentée dans le modèle élaboré.
20:17
15
CONCEPTS
La clé est constituée par le plus petit ensemble de
champs dont dépendent fonctionnellement les autres
champs.
Si plusieurs clés sont possibles, on parle de clés
candidates.
La clé choisie sera nommée la clé primaire.
La clé primaire est généralement choisie de façon à ce
qu'elle soit la plus simple, c’est-à-dire portant sur le
moins d'attributs et sur les attributs de domaine les
plus basiques (entiers ou chaînes courtes
typiquement). 20:17
16
CONCEPTS
S'il est impossible de trouver une clé primaire, ou
que les clés candidates sont trop complexes, il est
possible de faire appel à une clé artificielle.
Une clé artificielle est un attribut supplémentaire
ajouté au schéma de la relation, qui n'est lié à
aucune signification, et qui sert uniquement à
identifier de façon unique les enregistrements et/ou
à simplifier les références de clés étrangères.

20:17
17
CONCEPTS
Une clé est signifiante si elle n'est pas
artificielle. Elle est aussi dite « clé naturelle »
Au niveau du modèle logique, il faut éviter la
simplicité consistant à identifier toutes les
relations avec des clés artificielles, et ne réserver
cet usage qu'aux cas particuliers.

20:17
18
CONCEPTS
Au niveau de l'implémentation physique, il est courant
que des clés artificielles soient utilisées de façon
systématique.
Du point de vue de l'évolutivité de la BD, il existe toujours
un risque qu'une clé non artificielle perde sa propriété
d'unicité ou de non-nullité.
Du point de vue de la maintenance de la BD, il existe
toujours un risque qu'une clé non-artificielle voit sa valeur
modifiée et dans ce cas, la répercutions de ce changement
pour mettre à jour toutes les références peut poser 20:17
19
CONCEPTS
Du point de vue de la performance de la BD, les clés
non-artificielles ne sont pas en général optimisées en
terme de type et de taille, et donc peuvent limiter les
performances dans le cadre des jointures. Toutefois,
les clés artificielles ont pour conséquence de
systématiser des jointures qui auraient pu être
évitées avec des clés primaires signifiantes.

20:17
20
CONCEPTS
Il existe trois catégories des opérations de manipulation des
relations
Les opérations du monde ensembliste : intersection, union et
différence.
Les opérations spécifiques relationnelles : Projection,
sélection (ou restriction) et jointure.
Les opérations et les fonctions de calcul: moyenne, variation
standard, somme, etc. Elles ne constituent pas réellement
des opérations du monde relationnel mais sont utiles pour
effectuer des calculs sans recourir à un langage de 20:17

programmation.
21
CONCEPTS
La cohérence des données contenues dans les
relations est améliorée par la définition de
contraintes à appliquer sur les relations au
moment de leur création.
Ces contraintes expriment essentiellement les
conditions d’appartenance à un domaine du
champ.
20:17
22
CONCEPTS
Cet ensemble se décrit de plusieurs manières :
Une liste exhaustive de valeurs.
Ex: Les jours de la semaine : « lundi », « mardi »,
etc.
Le respect de propriétés.
Ex: « l’âge doit être compris entre 7 et 77 ans ».
L’utilisation des valeurs d’un champ comprises
dans une autre relation de référence. On parle de 20:17

clé étrangère.
23
CONCEPTS
Les liaisons entre les relations, qui
expriment les liens de sens dans la réalité,
sont établies dynamiquement par
l’opération fondamentale de l’approche
relationnelle qui est la jointure.

20:17
24
CONCEPTS
Bien que tous les outils permettent de
modéliser un schéma logique relationnel,
aucun ne peut offrir un processus de
normalisation automatique.
Il est donc nécessaire de maîtriser à la fois
le modèle de données et les principes de
normalisation afin de concevoir des bases
de données cohérentes.
20:17
25 TRANSFORMATION D’UN DIAGRAMME DE
CLASSES EN UN SCHÉMA RELATIONNEL

Généralement, on ne génère pas le code du LDD SQL

directement à partir d’un diagramme de classes.
On préfère transformer le diagramme de classes en un
schéma représentant les données au travers de leurs
éléments de modélisation relationnelle.
Le code du LDD SQL est alors déduit du schéma
relationnel.
20:17
26 TRANSFORMATION D’UN DIAGRAMME DE
CLASSES EN UN SCHÉMA RELATIONNEL

Transformation des classes

Pour chaque classe non abstraite,
on crée une relation dont le schéma est celui
de la classe ;
le nom de la relation reprend le nom de la
classe;
la clé primaire de cette relation est une des
clés de la classe;
20:17
 27 TRANSFORMATION D’UN DIAGRAMME DE
CLASSES EN UN SCHÉMA RELATIONNEL

Ex:
Cette correspondance
est directement
possible si les attributs
de la classe sont
atomiques seront
adaptés, selon le cas,
Voiture (Numero, Marque, Capacity) en type SQL.
Voiture(‘JA0234’, ‘Toyota’, ’12vc’)
Voiture(‘AA9876’, ‘Audi’, ‘14vc’) 20:17
28 TRANSFORMATION D’UN DIAGRAMME DE
CLASSES EN UN SCHÉMA RELATIONNEL

Identifiant, clé primaire d’une relation

Enfin de pouvoir identifier de manière unique tout tuple de la
relation, une solution simple et systématique consiste à rajouter
arbitrairement à la relation un attribut qui jouera le rôle de clé
primaire de la relation : clé artificielle.
Ce nouvel attribut, clé primaire de la relation, pourra être appelé
identifiant de la relation.
Lorsqu’un objet est créé, normalement on donne un nom
(identifiant) a cet objet, et on affecte une valeur a chacun des
attributs de la classe dont l’objet est une instance. 20:17
29 TRANSFORMATION D’UN DIAGRAMME DE
CLASSES EN UN SCHÉMA RELATIONNEL

Au niveau relation, il faut aussi donner, lors de

la création d’un tuple, sa valeur de clé primaire
(l’identifiant du tuple), et pour chaque attribut
de la relation une valeur.
Les identifiants d’objets ne sont pas modifiables
; en principe, il devrait en être de même pour les
valeurs de clé primaire.
20:17
30 TRANSFORMATION D’UN DIAGRAMME DE
CLASSES EN UN SCHÉMA RELATIONNEL

Exemple:
Dans l’exemple précédent, on ajoute l’attribut
de voiture ID.
Voiture( Voiture_ID, numero, marque, capacity)
Voiture(V1,‘JA0234’, ‘Toyota’, ’12vc’)
Voiture(V2,‘AA9876’, ‘Audi’, ‘14vc’)

20:17
31 TRANSFORMATION D’UN DIAGRAMME DE
CLASSES EN UN SCHÉMA RELATIONNEL

Génération du code du LDD SQL

A partir du schéma relationnel, on peut en
déduire le code du LDD SQL qui devra être
transmis au SGBD Relationnel pour qu’il puisse
créer le schéma interne des données :
Ex: SQL> create table Voiture( Voiture_ID
varchar( 10 ) primary key; numero varchar(32);
marque varchar(32); capacity varchar(10)) 20:17
32 TRANSFORMATION D’UN DIAGRAMME DE
CLASSES EN UN SCHÉMA RELATIONNEL

Si sur certains attributs de la classe, un

invariant de type clé est défini : l’un de ces
attributs peut se substituer à la clé primaire
créée arbitrairement lors du passage au niveau
relationnel, les autres seront des attributs qui,
au niveau relationnel, auront la propriété :
unique not null.

20:17
33
TRANSFORMATION DES ATTRIBUTS

Attributs simples
Pour chaque attribut élémentaire et mono-valué
d'une classe, on crée un attribut correspondant.

Etudiant(Nom, Prenom)

20:17
34
TRANSFORMATION DES ATTRIBUTS
Attributs composites
Pour chaque attribut composite comprenant N
sous-attributs d'une classe, on crée N attributs
correspondants, dont les noms sont la
concaténation du nom de l'attribut composite
avec celui du sous-attribut.

Etudiant(Nom, Prenom, Adresserue, adresseAvenue)

20:17
35
TRANSFORMATION DES ATTRIBUTS
Attributs multi-valués: méthode 1
Pour chaque attribut multi-valué b d'une classe, on
crée une nouvelle relation, qui comprend un attribut
mono-valué correspondant à l’attribut multi-value,
plus la clé de la relation représentant la classe, la clé
de la nouvelle relation est la concaténation des deux
attributs.

Rel1(#b, #aClasse1)
20:17
36
TRANSFORMATION DES ATTRIBUTS
Attributs multi-valués: méthode alternative
Dans le cas où le nombre maximum de b est fini, et
petit, on peut également adopter la transformation
suivante : Classe1(#a,b1,b2,b3,b4,b5,b6,b7,b8,b9,b10).
Si le nombre d'attributs est infini (b[1..*]) c'est
impossible, s'il est trop grand ce n'est pas souhaitable.

Rel1#a,b1,b2,b3,b4,b5,b6,b7,b8,b9,b10)
20:17
37
TRANSFORMATION DES ATTRIBUTS

Attributs composés multi-valués

On combine les règles énoncées pour les
attributs composés et pour les attributs multi-
valués.

Rel1(#b_b1,#b_b2,#a=>Classe1)

20:17
38 PRINCIPE DE TRANSFORMATION DES ASSOCIATIONS
ET DES LIENS EN RELATIONNEL

L’association (classe-association) devient une

relation dont la clé primaire est composée par la
concaténation des identifiants des entités (classes)
connectés à l’association.
Les attributs de l’association (classe-association)
doivent être ajoutés à la nouvelle relation.
Ces attributs ne sont ni clé primaire, ni clé
étrangère. 20:17
 39 PRINCIPE DE TRANSFORMATION DES ASSOCIATIONS
ET DES LIENS EN RELATIONNEL

Association par valeur de clé (primaire)

En relationnel, c’est au travers des valeurs de clé (primaire) que l’on
peut lier (associer) des tuples entre eux.
Ex: Le diagramme classique suivant :

20:17
40 PRINCIPE DE TRANSFORMATION DES ASSOCIATIONS
ET DES LIENS EN RELATIONNEL

La transformation en relationnel d’un tel

diagramme se fait, intuitivement, selon les étapes
suivantes:
1. A chaque classe correspond une relation :
 Etudiant(nom, prenom)  Filiere(noCode, theme, nbHeures)
Et1,… F1,…
Et2,… F2,….
Et3,…

20:17
 41 PRINCIPE DE TRANSFORMATION DES ASSOCIATIONS
ET DES LIENS EN RELATIONNEL

2. Chaque étudiant est inscrit dans une filière,

dans la relation Etudiant on ajoute une
colonne permettant d’indiquer, pour chaque
étudiant, quel est sa filière ; cette filière pourra
être représenté par son identifiant, c’est-a-dire
sa valeur de clé (primaire:
 Etudiant(Et_ID,nom, prenom,F_ID)  Filiere(F-ID, theme, nbHeures)
Et1,… F1,…
Et2,… F2,….
Et3,… 20:17
42 PRINCIPE DE TRANSFORMATION DES ASSOCIATIONS
ET DES LIENS EN RELATIONNEL

3. Toute filière doit être un élément dont le tuple est dans

la relation Filière, toute valeur de la colonne
Etudiant(F_ID) doit être une valeur de clé primaire de
la relation Filière, c’est-a-dire que toute valeur de la
colonne(F_ID) doit se retrouver dans la colonne
Filiere(F_ID).
On dit que l’attribut Etudiant(F_ID)a pour domaine
référentiel l’attribut Filiere(F_ID).
20:17

On ecrit : Etudiant(F_ID) ⊆Filiere(F_ID).

43 PRINCIPE DE TRANSFORMATION DES ASSOCIATIONS
ET DES LIENS EN RELATIONNEL

Le code du LDD SQL, correspondant au

schéma relationnel, est le suivant :
 create table Filiere(F_ID varchar( 10 ) primary
key,…);
 create table Etudiant( Et_ID varchar( 10 )
primary key,… F-ID varchar( 10 ) references
Filiere(F_ID));
20:17
44 PRINCIPE DE TRANSFORMATION DES ASSOCIATIONS
ET DES LIENS EN RELATIONNEL

Dependance referentielle, cle etrangere

Au niveau syntaxe du code LDD SQL :
Il existe différentes manières de déclarer la
contrainte liée à la dépendance référentielle, pour de
raison logique, le domaine de référence doit être une
clé ; et pour des raisons d’optimisation, le domaine de
référence doit être une clé primaire : cet attribut de
référence a pour domaine clé étrangère. 20:17
45
Exercices
1. Démontrer les implications suivantes :
a) Soient les deux DF x  y et y  z alors x 
y,z
b) Soient les deux DF x  y et z  w alors x,z
 y,w
c) Soit la DF x  y alors x,z  y,z

20:17
46
Exercices
2. Décrire le schema relational de la modelisation
UML suivante:

20:17
47
Exercices
3. Déduire les DF de la situation suivante.
Soient les dépendances fonctionnelles suivantes :
(1) a --> b
(2) b --> c
(3) a --> e
(4) a --> c
(5) b --> f 20:17
48
Exercices
(6) b,a --> d
(7) d --> g
(8) a,b --> c
(9) a,b,f --> h
(10) a,i --> j
Déterminer le schéma relationnel en utilisant
l’approche par synthèse.
20:17

Déterminer le diagramme UML équivalent.

49

20:17