Chapitre 3

LE MODÈLE RELATIONNEL
Sommaire
1. Définitions
2. Règles de modélisation
3. Identifiant d'une relation (clé primaire)
4. Identifiant externe (clé étrangère)
5. Traduction d'un schéma entité association en relationnel
6. Normalisation d’une relation
 Première et deuxième formes normales
 Troisième forme normale
 forme normale de Boyce Codd
1. Définitions
1. Le modèle relationnel ?

Le modèle relationnel a été inventé en 1960 et a fait

l'objet de très nombreuses recherches qui ont
débouché sur la réalisation et commercialisation de
SGBDs relationnels. C'est le modèle le plus utilisé
par les SGBDs actuellement disponibles sur le
marché.
2. Les objets et associations du monde réel sont représentés par un
concept unique: la RELATION.
1. Définitions
RELATION
1. Exemples :

TUPLE

ATTRIBUT
1. Définitions
3. Notion de domaine
 Un domaine est un ensemble de valeurs que peut
prendre un attribut; c'est le domaine définition d'un
ou plusieurs attributs.
 Exemple de domaines:
• Dnom : chaînes de caractères de longueur maximale 30
• Dnum : entiers compris entre 0 et 99999
• Dcouleur : {"bleu", "vert", "jaune"}
• Dâge : entiers compris entre 16 et 65
1. Définitions
4. Relation :
 Une relation est définie par :
 son nom
 liste de couples (nom d'attribut : domaine)
 son (ses) identifiant(s) (clés)
 sa définition (phrase en français)
 Les trois premières informations: nom de la relation,
liste des couples (attribut : domaine) et identifiant(s)
constituent le schéma de la relation.
 Exemple : schéma de la relation Etudiant :
 Etudiant (N° Etud : Dnum, Nom : Dnom, Prénom : Dnom, Age :
Dâge)
1. Définitions
4. Relation :

La population d'une relation est constituée de l'ensemble des tuples

de la relation. C'est un ensemble; il n'y a donc ni doubles, ni ordre (les
nouveaux tuples sont rajoutés à la fin de la relation).

On appelle schéma d'une base de données

relationnelle l'ensemble des schémas de ses relations. On appelle
base de données relationnelle, la population de toutes ses relations.
2. Règles de modélisation
 Les attributs sont tous simples et monovalués:
toute valeur prise par un attribut pour un tuple est
atomique (non décomposable par le SGBD) et unique.

Les notions d'attribut multivalué, complexe ou

facultatif, n'existent pas dans le modèle relationnel.
2. Règles de modélisation
 Cas d'un attribut facultatif du modèle EA :
 Certains SGBDs relationnels gèrent une valeur spéciale,
appelée valeur nulle et notée "?".
 Par exemple, un étudiant, Marc Dumont, de numéro 123, dont
on ne connaîtrait pas l'âge, serait représenté par le tuple:
 < 123, Dumont, Marc, ? >
 Une telle solution implique un traitement particulier de cette
valeur nulle dans les langages de manipulation des données. A
l'opposé, les attributs obligatoires sont traduits lors de la
création de la table en SQL par la clause NOT NULL.
2. Règles de modélisation
 Cas d'un attribut complexe du modèle EA :
 Soit par exemple, un attribut complexe en entité association,
Adresse, composé des attributs: n° rue, nom rue , ville,
code-postal. Si on veut ajouter cet attribut dans la relation
Etudiant, il y a plusieurs solutions.
 Solution 1 : On ajoute l'attribut Adresse qui a pour domaine
les chaînes de caractères. Dans ce cas, l'utilisateur ne peut pas
poser de questions sur la ville, il devra lire l'adresse et chercher
dans la chaîne de caractères le nom de la ville lui-même, ou
par programme.
2. Règles de modélisation
 Cas d'un attribut complexe du modèle EA :
 Soit par exemple, un attribut complexe en entité association,
Adresse, composé des attributs: n° rue, nom rue , ville,
code-postal. Si on veut ajouter cet attribut dans la relation
Etudiant, il y a plusieurs solutions.
 Solution 2 : On ajoute les attributs suivants : n°rue, nom-rue,
ville, code-postal à la relation. Le SGBD connaît le détail de
l'adresse, mais ne connaît pas la notion globale d'adresse.

La solution est choisie en fonction du type d'utilisation de

l'attribut.
2. Règles de modélisation
 Cas d'un attribut multivalué du modèle EA :

 Par exemple, on veut mémoriser les différents prénoms des

étudiants (et non pas uniquement leur premier prénom).
 Solution 1 : Avoir dans la relation Etudiant plusieurs attributs
: Prénom1, Prénom2,...
 Problèmes : combien mettre d'attributs Prénom ? Comment
poser des questions sur cet attribut (on est obligé de poser
autant de questions que d'attributs déclarés !).
 C'est une mauvaise solution à ne pas utiliser.
2. Règles de modélisation
 Cas d'un attribut multivalué du modèle EA :

 Par exemple, on veut mémoriser les différents prénoms des

étudiants (et non pas uniquement leur premier prénom).
 Solution 2 : On ne garde que N°Etud, Nom, Age pour la relation
Etudiant, et on crée une relation supplémentaire,
EtudPrénoms (N°Etud , Prénom)
 Cette solution n'a pas les inconvénients de la solution
précédente. Si l'on veut, plutôt que l'ensemble des prénoms, la
liste ordonnée des prénoms on décrira la relation:
EtudPrénoms2 (N°Etud, N°Prénom, Prénom).
3. Identifiants d’une relation
 Définition : L'identifiant (aussi appelé clé) d'une relation est un
ensemble minimum d'attributs de la relation, tel qu'il n'existe pas deux
tuples ayant même valeur pour cet identifiant.
C'est un ensemble minimum d'attributs tel que tous les autres
attributs en dépendent fonctionnellement.
Un identifiant peut-être composé d'un ou plusieurs attributs.
Exemples : Etudiant (N°Etud, nom, prénom, age) : Il n'y a pas deux étudiants
qui ont le même numéro.
La relation précédente, EtudPrénoms2, possède deux identifiants qui sont
N°Etud, N°Prénom et N°Etud, Prénom.
Règle: tous les attributs de tout identifiant doivent toujours avoir une
valeur connue.
4. Identifiant externe
 Définition : Soient deux relations R1(X, Y) et R2 (V, W), où X, Y, V,
W, désignent des attributs ou des ensembles d'attributs, et où X est
un identifiant de R1, on dit que W est un identifiant externe sur R1
(ou que W référence R1) si pour tout tuple de R2, la valeur prise par
W est nécessairement la valeur de X pour un tuple existant de R1.
Autrement dit, à tout instant, l'ensemble des valeurs prises par W
est compris dans l'ensemble des valeurs prises par X.
Exemples :
 Suit (N°Etud : Dnum, NomC : Dnom)
 Identifiants externes: N°Etud référence un Etudiant
 NomC référence un Cours
 Dans le cas où la relation référencée possède plusieurs identifiants il faut préciser
lequel. La clause est alors: N°Etud référence un Etudiant•N°Etud
4. Identifiant externe
 Vérification automatique assurée par le SGBD :
 Une fois déclaré l'identifiant externe W de R2 sur R1, le SGBD
vérifie toutes les insertions dans R2 (il vérifie que la valeur de
W existe dans R1);
 il vérifie de la même façon les modifications de W.
 Il vérifie toutes les suppressions de tuples de R1 (il vérifie qu'il
n'existe pas de tuple dans R2 référençant ce tuple à
supprimer).
Le SGBD assure ainsi, l'intégrité de référence (ou intégrité
référentielle) de la base de données.
5. Traduction d'un schéma
EA en relationnel
 Objectifs : Concevoir un schéma entité association,
puis le traduire en relationnel. Si le schéma entité
association était "bon", alors la plupart des relations
sont bonnes (« normalisées »).
 Seules les relations qui proviennent d'attributs
complexes contenant des dépendances peuvent ne
pas l'être. Il suffit donc de vérifier la forme normale
de ces relations (les normaliser).
 Un algorithme de traduction est présenté ci-dessous.
Algorithme de traduction
1) Pour chaque TE, créer une relation de :
 nom = nom du TE;
 attributs = attributs monovalués du TE (pour les
attributs complexes, prendre leurs attributs
composants simples, avec pour nom le nom de
l'attribut complexe concaténé à celui de l'attribut
composant); les attributs facultatifs deviennent
des attributs à valeur nulle possible.
Algorithme de traduction
Algorithme de traduction
Algorithme de traduction
Algorithme de traduction
Algorithme de traduction
Contraintes :

 Certaines contraintes exprimées dans le schéma entité

association peuvent être directement exprimées dans le schéma
relationnel issu de la traduction.
 C'est le cas par exemple, des attributs obligatoires (de cardinalité
minimale 1) qui deviennent des attributs NOT NULL en
relationnel.
 Les contraintes qui ne peuvent pas être directement exprimées
dans le schéma relationnel, seront traduites par des CHECK,
ASSERTIONS ou TRIGGERS du SQL.
Algorithme de traduction
Exemple :
Algorithme de traduction

Traduction du schéma E/A sur le tableau

6. Normalisation d’une
relation
 Notion de dépendance fonctionnelle (DF) :
Définition : Etant donné une relation, R (X, Y, Z), il existe une
dépendance fonctionnelle, ou "DF", de Y vers Z, notée Y→Z, si :
étant donné deux tuples quelconques de R, s'ils ont même valeur pour
Y, alors ils ont nécessairement même valeur pour Z. On appelle Y
source de la DF, et Z cible de la DF.
Exemple : pour la relation Produit (NP, NomP, Poids, Couleur), il y a les
DF suivantes en supposant qu'il n'existe pas deux produits de même
nom : NP →NomP, NomP → NP, NP →Poids NomP → Poids, NP
→Couleur, NomP → Couleur NP →(NomP, Poids, Couleur) (NP, NomP)
→Poids, (NP, NomP) →Couleur
6. Normalisation d’une
relation
6. Normalisation d’une
relation
 Normalisation:
Toute relation du schéma relationnel de la BD doit passer les tests successifs de
Formes Normales pour être valide : « normalisée ».
Normaliser une relation qui pose des problèmes de mise-à-jour (relation non
normalisée), consiste à décomposer cette relation en relations sans problèmes
(relations normalisées). La méthode à suivre est la suivante:

 1/ vérifier que la relation est en première forme normale (voir définition ci-dessous);
 2/ établir son graphe minimum des dépendances;
 3/ déterminer, à l'aide du graphe, tous ses identifiants;
 4/ déterminer, à l'aide du graphe, sa forme normale (voir définitions ci-dessous);
 5/ si la relation n'est pas normalisée, décomposer, à l'aide du graphe, la relation en
relations mieux normalisées
6. Normalisation d’une
relation
 Première forme normale (1FN) :
Définition : Une relation est en première forme normale si chaque
valeur de chaque attribut de chaque tuple est une valeur simple (tous
les attributs sont simples et monovalués).

 Deuxième forme normale (2FN):

Définition : Une relation est en deuxième forme normale si elle est en
première forme normale et si chaque attribut qui ne fait partie d'aucun
identifiant dépend de tout identifiant entier (et non pas d'un morceau
d'identifiant).
6. Normalisation d’une
relation
Exemple :
◦ Soit une relation qui est en 1ère forme normale (1FN), mais qui n'est pas en
2ème forme normale (2FN) :

Fournisseur1 (NF, NomProduit, Adr, Tel, Prix)

◦ Graphe de dépendances :

◦ Des problèmes existent !

 6. Normalisation d’une
relation
Une telle relation pose des problèmes :
 Redondances : s'il existe 100 produits pour un fournisseur on va répéter 100 fois le nom,
l'adresse, le téléphone du fournisseur.
Problème de mise à jour pour les insertions : quand on veut rajouter un produit, il faut rentrer à
nouveau l'adresse et le téléphone du fournisseur.
 Problème pour les suppressions : si on supprime (momentanément) la liste des produits d'un
fournisseur, alors on supprime aussi le fournisseur.
 Problème de mise à jour des tuples : si un fournisseur change d'adresse ou de téléphone, il faut
faire cette mise à jour sur tous les 100 tuples !

On va décomposer cette relation en deux :

Fournisseur ( NF, Adr, Tel)
Catalogue (NF, NomProduit, Prix)

qui sont en 2ème forme normale

6. Normalisation d’une
relation
Troisième forme normale (3FN) :
Définition : une relation est en troisième forme normale (3FN) si elle est en
première forme normale et si chaque attribut qui ne fait partie d'aucun
identifiant dépend uniquement des identifiants entiers.
Exemple :
Soit une relation qui est en deuxième forme normale :
Fournisseur2 ( N°F, Pays, Ville)
Il existe les DF : NF → Ville et Ville → Pays car on suppose qu'on n'a dans la
base de données que des grandes villes sans homonymes.
La DF : NF → Pays est une DF déduite.
6. Normalisation d’une
relation
Forme normale de Boyce Codd :
Définition : Une relation est en forme normale de Boyce Codd si elle est en
première forme normale et si toute source complète de DF est un identifiant
entier.
Exemple :
Soit une relation qui est en 3FN (on suppose qu'il n'y a pas d'homonyme chez
les fournisseurs) : Catalogue3 (NF, NomF, NomProduit, Prix)
Identifiants : (NF + NomProduit) , (NomF + NomProduit)
Conclusion
Un schéma relationnel se compose, pour chaque relation
de:
◦ nom de la relation
◦ définition
◦ attributs + domaines
◦ identifiant(s)
◦ éventuellement identifiant(s) externe(s) + contraintes d'intégrité associées
à cette relation et des autres contraintes d'intégrité qui portent sur
plusieurs relations.

◦ Toutes les relations doivent être normalisées.