CHAPITRE4: MODÈLE RELATIONNEL Par MERCI KELLY

ET NORMALISATION
CONTENU
3.1 Introduction
3.2 Le modèle relationnel
3.3 Identifiants
3.4 Dépendances fonctionnelles
3.5 Contraintes d'inclusion et clés étrangères
3.6 Calcul des identifiants d'une relation
3.7 Décomposition d'une relation
3.8 Normalisation d'une relation
3.1 INTRODUCTION
Le but de ce chapitre est d’étudier de manière rigoureuse le problème de la
redondance interne au sein d’une table et techniques qui permettent de
l’identifier et de l’éliminer sans perte d’information.
Nous situerons l’analyse du problème dans le cadre du modèle relationnel de
base de données dont l’un des objectifs est l ’étude et l’élimination de la
redondance interne.
Nous réexaminerons la notion d’identifiant puis nous introduirons celle de
dépendance fonctionnelle.
3.2 LE MODÈLE RELATIONNEL
A. Concepts de base
Un domaine est un ensemble nommé de valeurs a priori. Chaque valeur est
supposée designer un objet concret ou abstrait du monde réel: un client, un
nom, un prix, une date, …
Une relation est un ensemble nommé d’agrégats de n valeur, chacune
appartenant a un domaine. Nous appellerons ligne un tel agrégat (ou n-uplet).
Les composants de même rang des lignes forment un attribut de la relation.
Les attributs d’une relation portent des noms distincts.
On distingue dans une relation, d’une part, son schéma ou intention et d’autre part,
son extension ou contenu
Quel rapport existe-t-il entre une relation et une table?
Une table est une représentation matérielle d’une relation, ou l'inverse, une relation
est une abstraction mathématique d’une table.
Notation de la représentation graphique du schéma
OFFRE(CHAINE: char(20), PRODUIT: char(16), PRIX: decimal(6,2))
Ou, plus simplement, si on ignore les domaines,
OFFRE(CHAINE, PRODUIT, PRIX)
B. Operateur d’extraction des données
Un modèle de données n’a d’utilité que s’il propose un moyen de dériver des
données a partir des lignes des relations.
Nous étudierons plus loin le langage SQL qui répondra a ce besoin.
Nous nous contenterons ici d’un ensemble réduit d’operateurs très simples mais
suffisants pour notre analyse.
Ces operateurs font partie de ce qu’on appelle l’algèbre rationnelle, qu’on
trouvera en partie dans le langage SQL.
Nous n’en retiendrons que la projection, la jointure et la sélection, que nous
illustrerons sur la petite base de données de la figure 3.1.
1. Projection d’une relation
L’operateur de projection produit une relation dont les attributs forment un sous
ensemble de ceux de la relation d’origine.
Le résultat comporte, en principe, moins d’attributs que la relation d’origine; elle
peux aussi comporter moins de lignes lorsque plusieurs lignes de la relation d’origine
ont les mêmes valeurs pour attributs de la projection (élimination des double).
La projection de la relation OFFRE sur les attributs PRODUIT et PRIX nous donne une
relation à deux attributs (figure 3.2) qui indique pour chaque produit à quel(s) prix il
est offert, sans qu’on sache dans quelle(s) chaine(s).
2. Jointure naturelle de deux relations
La jointure de deux relations telles que OFFRE et IMPLANTATION sur les attributs
CHAINE produit une relation dont les lignes sont constituées à partir d’une ligne
d’OFFRE et d’une ligne, dits attributs de jointure, ont même valeurs.
Par exemple, la ligne (MAMMOUTH, Chocolat, 5) d’OFFRE et la ligne (MAMMOUTH,
LILLE) d’IMPLANTATION seront jointes sous forme (MAMMOUTH, Chocolat, 5, LILLE)
qui fera donc partie du résultat, lequel est repris a la figure 3.3.
On notera cette jointure comme suit:
OFFRE-VILLE = OFFRE(CHAINE)*IMPLATATION(CHAINE)
Ou lorsqu’il n’y a pas d’ambiguite sur les attributs de jointure,
OFFRE-VILLE = OFFRE*IMPLATATION
3. Sélection des lignes
La sélection est un operateur qui, applique à une relation, retourne
le sous ensemble de ses lignes qui satisfont une condition de
sélection.
La sélection des offres dont le prix est inferieur à 5 s’écrit comme
suit:
OFFRE-BUDGET = OFFRE(PRIX < 5)
4. Combinaison d’operateurs
Puisque le résultat de l'application d’un operateur de projection, de
jointure ou de sélection est une relation, on peut appliquer sur celle-ci
d’autres opérateurs.
L’expression suivante qui demande l’application d’une projection au
résultat de la jointure d’une sélection et dune relation de base, produit
une relation qui donne, pour chaque produit dont le prix est inférieur à
5, les ville où il est offert:

PRODUIT-VILLE = (OFFRE(PRIX < 5)*IMPLANTATION)[PRODUIT, VILLE]

5. Autres opérateurs
L’algèbre relationnelle comporte d’autres operateurs permettant de
dériver de nouveaux domaines et de nouvelle relations.
Citons en particulier:
 Les operateurs ensemblistes (union, intersection et différence),
 Le produit cartésien, déjà mentionné,
 La division
3.3 IDENTIFIANTS
Un identifiant d’une relation est un sous-ensemble de ses attributs tel qu’il ne peut
exister à aucun moment plus d’une ligne posséda nt les mêmes valeurs de ces
attributs. Examinons quelques propriétés de ce concept.
1. Un identifiant est minimal si aucune de ses parties n’est un identifiant. Si au contraire il
comporte des attributs surnuméraires, qu’on peut supprimer sans qu’il perde son statut
d’identifiant, il est dit non minimal.
2. Tout ensemble d’attributs dont une partie est un identifiant est aussi un identifiant. On en déduit
qu’en ajoutant un attribut quelconque à un identifiant, on obtient encore un identifiant (non
minimal).
3. L’ensemble des attributs d’une relation est un identifiant de celle-ci. En effet, par définition, une
relation ne peut contenir deux lignes identiques (3.2.1). Cet identifiant est très souvent non
minimal. Conséquence : toute relation possède au moins un identifiant.
4. Une relation peut posséder plusieurs identifiants minimaux. Il est habituel de désigner l’un
d’entre eux comme l’identifiant primaire de la relation.
5. Il est possible qu’un attribut appartienne à plusieurs identifiants minimaux.
On indiquera un identifiant en soulignant ses composants de manière continue. Dans les
situations plus complexes, on spécifiera un identifiant par la clause " id :" ou " id(R) : ". Les
exemples suivants illustrent ces principes.
1. VENTE(ARTICLE , MAGASIN, PRIX, ...) . Dans le domaine d’application décrit, un article n’est vendu que
dans un seul magasin, et à prix fixe.
2. VENTE’ (ARTICLE, MAGASIN, PRIX, ...). Ici, un article peut être vendu par plusieurs magasins. Son prix
dépend du magasin qui le vend.
3. VENTE"(ARTICLE, MAGASIN, PRIX , ...) . Un magasin peut vendre un même article à différents prix (selon
une règle qui n’est pas précisée).
4. EMPLOYE(MATR , NSS , NOM, ADRESSE) . Cette relation est dotée de deux identifiants distincts,
indiquant par là qu’un employé peut être identifié soit par son matricule ( MATR ), soit par son numéro
de Sécurité sociale ( NSS ).
5. HORAIRE(PROF, HEURE, LOCAL)
id: PROF,HEURE
id: HEURE,LOCAL
3.4DEPENDANCE FONCTIONNELLE
A. Le phénomène de DF
Si, quel que soit le contenu de ACHAT , la valeur de l’attribut PRIX ne dépend que de celle
de PRODUIT et pas des autres attributs ( CLIENT ), alors on dira qu’il existe une
dépendance fonctionnelle de PRODUIT vers PRIX , ce qu’on notera :
ACHAT: PRODUIT PRIX
ou plus simplement, quand le contexte le permet :
PRODUIT PRIX

À une valeur déterminée de PRODUIT correspond une même valeur de PRIX dans toutes les
lignes dans lesquelles cette valeur de PRODUIT apparaît. Si on construit une relation par
projection de ACHAT sur PRODUIT et PRIX , alors PRODUIT en sera automatiquement
l’identifiant.
Dans notre exemple, on dira que :
 PRODUIT détermine (fonctionnellement) PRIX ;
 PRIX dépend (fonctionnellement) de PRODUIT ;
 PRODUIT est le déterminant et PRIX est le déterminé de la dépendance fonctionnelle.
B. Un exemple plus complexe
La relation COM suivante est particulièrement complexe. Une ligne (a,b,c,d,e,f,g,h)
indique que le client n° a , de nom b et d’adresse c a passé la commande numéro d
, à la date e , spécifiant le produit n° f en quantité g et au prix unitaire h.
COM(NCLI, NOM, ADRESSE, NCOM, DATE, NPRO, QTE, PRIX-U)
 NCOM NCLI toute commande est émise par un client df1
 NCLI NOM tout client a un nom df2
 NCLI ADDRESSE tout client a une adresse df3
 NCOM DATE toute commande est passée à une certaine date df4
 NCOM, NPRO QTE dans toute commande, il y a une quantité par produit df5
 NPRO PRIX-U tout produit a un (et un seul) prix unitaire df6
C. Graphe ADF d’une relation (attributs et DF)
On appelle DF externe dans un graphe ADF toute DF dont le déterminé n’entre dans la
composition d’aucun déterminant. Les autres DF sont dites internes . La relation COM
comporte une seule DF interne ( NCOM NCLI ), toutes les autres étant externes.
Un attribut externe appartient à un déterminé mais à aucun déterminant ( NOM , ADRESSE
, DATE , QTE , PRIX-U ). Un attribut source appartient à un déterminant mais pas à un
déterminé ( NPRO , NCOM ). Un attribut interne appartient à un déterminant et à un
déterminé ( NCLI ). Un attribut isolé n’appartient ni à un déterminant ni à un déterminé. Les
attributs sources et isolés forment les attributs racines
3.5 CONTRAINTE D’INCLUSION ET CLÉS
ÉTRANGÈRES
Une contrainte d’inclusion précise que les va leurs d’un attribut (ou d’un groupe
d’attributs) dans une relation doivent simultanément être des valeurs d’un attribut (ou
groupe d’attributs) d’une autre relation (ou de la même relation).

Lorsque le membre de droite de l’expression est défini sur les attributs d’un
identifiant, la contrainte est dite référentielle et les attributs du membre de gauche
forment une clé étrangère de la première relation.
3.6 CALCUL DES IDENTIFIANT D’UNE RELATION
La normalisation d’une relation va reposer sur les rapports qui existent entre les
identifiants et les dépendances fonctionnelles de cette relation.
Mais comment raisonner dans les cas plus complexes tels que ceux des relations
VENTE" ou HORAIRE de la section 3.3? En fait, les identifiants ne se choisissent pas,
ils s’imposent , ou plus exactement ils se calculent à partir de l’ensemble des DF dont
la relation est le siège. Nous examinerons une procédure intuitive qui permet de
résoudre la plupart des cas qui se présentent en pratique.
Procédure de calcul de l’identifiant d’une relation R (procédure de base)
1. Un premier identifiant J est constitué de l’ensemble des attributs de R
2. On recherche dans J un attribut C externe dans le graphe ADF de J; on retire C de J
3. On répète l’étape 2 jusqu’à ce qu’il ne soit plus possible de retirer d’attribut à J
4. J est l’identifiant (non nécessairement minimal) de R.
5. Si cet identifiant n’est le siège d’aucune DF, la procédure est terminée.
6. Sinon, le graphe ADF résiduel comporte un ou plusieurs circuits. Pour chaque attribut
A appartenant à un circuit, on applique l’étape 7.
7. On retire A du graphe ADF ainsi que toutes les DF dans lesquelles il apparaît. On
applique au graphe résultant la Procédure
Exemple 1 : La relation COM (figure 3.5) se traite comme suit :
1. L’identifiant de départ est l’ensemble {NCLI, NOM, ADRESSE, NCOM, DATE, NPRO, QTE, PRIX-U} .
2. On en retire les attributs externes DATE , QTE , PRIX-U , NOM et ADRESSE .
3. On en retire l’attribut NCLI , qui est devenu externe. Il reste l’identifiant {NCOM, NPRO} (figure 3.11)
10.

Exemple 2 : La relation COLIS , dont le graphe ADF est repris à la figure 3.6, possède un
identifiant obtenu comme suit :
1. L’identifiant de départ est l’ensemble {NCOL, NCLI, DATE, NOM, ADRESSE} .
2. On en retire les attributs externes ADRESSE et NOM .
3. On retire ensuite les attributs NCLI et DATE qui sont ainsi devenus externes. On obtient l’identifiant
minimal {NCOL} .
3.7 DÉCOMPOSITION D’UNE RELATION
3.8 NORMALISATION D’UNE RELATION
Normaliser une relation consiste à lui appliquer une ou plusieurs décompositions préservant les
données afin d’éliminer les problèmes de redondance interne dont elle est éventuellement le
siège.
Réexamen du phénomène de redondance interne Considérons à nouveau la relation ACHAT
(figure 3.4) dont on rappelle le schéma:
ACHAT(CLIENT, PRODUIT, PRIX
PRODUIT PRIX

Ce problème de redondance trouve son origine dans le fait que la relation ACHAT représente
deux types de faits indépendants :
 les clients achètent des produits , qui est exprimé dans le fragment
ACHAT[CLIENT,PRODUIT] ;
 chaque produit a un prix déterminé , correspondant au fragment
ACHAT[PRODUIT,PRIX] .
Relation normalisée Cette analyse se traduit comme suit :
 une DF dont le déterminant est un identifiant n’entraîne pas de redondance (on exclut du raisonnement les DF
triviales).
 Une relation dont toutes les DF satisfont cette propriété est sans redondance et est dite normalisée .
 Dans le cas contraire, cette relation est non normalisée . On appellera DF anormale une DF non triviale dont le
déterminant n’est pas un identifiant.

Une relation R est normalisée si, simultanément :

1. elle est en 1re forme normale
2. le déterminant de chaque DF non triviale de R est un identifiant de R.

Une DF n’est en soi ni bonne ni mauvaise. C’est le rapport qui existe entre son déterminant et
les identifiants de la relation qui induit ou non une redondance.
À partir du canevas de la section 3.7, on observe que chaque décomposition :
 génère une nouvelle relation R1(déterminant , déterminé) ;
 réduit la relation d’origine R par retrait des attributs du déterminé . Les relations R et R2 ayant même
signification, on convient d’attribuer le nom R à R2 .
Procédure pour la normalisation d’un e relation R :
1. Dessiner le graphe ADF de la relation réduit aux DF de base
2. Calculer les identifiants minimaux
3. Marquer les DF anormales
4. Tant qu’il existe une DF anormale externe K L, générer une relation R L (K , L) et
retirer L de R; préciser la contrainte référentielle
5. Finalisation : regroupement, noms significatifs, contraintes référentielles.
Exemple Soit la relation COM dont le graphe ADF est donné à la figure 3.5. Ce graphe ne
reprend que les DF de base. L’unique identifiant {NCOM, NPRO} de la relation a déjà été
calculé. Les DF anormales sont marquées sur le graphe ADF de la figure 3.16.
En pointillés, les DF anormales de la relation COM Les cinq itérations successives de l’étape
4 produisent les résultats suivants
état initial
COM(NCLI, NOM, ADRESSE, NCOM, NPRO , DATE, QTE, PRIX-U)

itération 1
DF anormale externe : NPRO PRIX-U
R1(NPRO , PRIX-U)
COM(NCLI, NOM, ADRESSE, NCOM, NPRO , DATE, QTE)

itérations 2 et 3
DF anormales externes : NCLI NOM, NCLI ADRESSE
R1(NPRO, PRIX-U)
R2(NCLI , NOM)
R3(NCLI , ADRESSE)
COM(NCLI, NCOM, NPRO, DATE, QTE)
itérations 4 et 5
DF anormales externes : NCOM DATE; NCOM NCLI;
R1(NPRO, PRIX-U)
R2(NCLI , NOM)
R3(NCLI , ADRESSE)
R4(NCOM , DATE)
R5(NCOM , NCLI)
COM(NCOM, NPRO , QTE)

Finalisation : il semble pertinent de regrouper les relations R2 et R3 d’une part, et R4 et

R5 d’autre part, considérant qu’elle ont le même identifiant :
R1(NPRO, PRIX-U)
R23(NCLI , NOM, ADRESSE)
R45(NCOM , NCLI, DATE)
COM(NCOM, NPRO , QTE)
En donnant aux relations R1 , R23 et R45 des noms significatifs et en reconstituant les
contraintes référentielles, on obtient les relations normalisées :
TARIF(NPRO , PRIX-U)
CLIENT(NCLI , NOM, ADRESSE)
COMMANDE(NCOM , DATE, NCLI)
DETAIL(NCOM, NPRO , QTE)
COMMANDE.NCLI : clé étrangère vers CLIENT
DETAIL.NCOM : clé étrangère vers COMMANDE
DETAIL.NPRO : clé étrangère vers TARIF

Les SGBD ignorent les dépendances fonctionnelles, à l’exception de celles dont le

déterminant est un identifiant de leur table, de sorte qu’ils sont incapables de gérer les
redondances internes d’une table non normalisée. Il est donc important de n’admettre que
de s tables normalisées.
EXERCICE