Vous êtes sur la page 1sur 15

Bases de données, L1 ESIS, 2019 – 2020, Chap II Page |1

Chapitre II : LE MODELE RELATIONNEL

II.1. Aperçu historique


Le modèle relationnel a été inventé par E.F.CODD, directeur de recherche du
centre IBM de San José en 1970. Il est basé sur une organisation des données sous
forme de tables. C’est le modèle le plus répandu car il convient à la majorité des
besoins des entreprises.

La manipulation des données s’effectue selon le concept mathématique de


relations de la théorie des ensembles, c’est-à-dire l’algèbre relationnelle.
Celle-ci est constituée d’un ensemble d ‘opérations formelles sur les relations. Les
opérations relationnelles permettent de créer une nouvelle relation (table) à partir
d’opérations élémentaires sur d’autre tables (Ex : l’intersection, l’union ou la
différence).
Le modèle relationnel est simple, facile à appréhender, même pour un non
spécialiste et repose sur de solides bases théoriques qui permettent notamment de
définir de façon formelle les langages de manipulation associés.
Il représente l'information dans une collection de relations. Intuitivement, on peut voir
une relation comme une table à double entrée, voire même comme un fichier. Chaque
ligne de la table (appelée n-uplet ou tuple) peut être vue comme un fait décrivant une
entité du monde. Une colonne de la table est appelée un attribut.

Le modèle relationnel est souvent considéré comme le plus simple et le plus


élégant des modèles. Sa simplicité est due à une vision tabulaire des données très
intuitive. Son élégance résulte de bases formelles issues de la théorie mathématique
des ensembles.
Les objectifs du modèle relationnel étaient différents de ceux des modèles réseau et
hiérarchique ; Parmi les lacunes de ces modèles auxquelles E.F.Codd souhaitait
apporter une solution, nous en retenons deux :

Permettre un haut degré d'indépendance entre les applications (programmes,


interfaces) et la représentation interne des données (fichiers, chemins d'accès)

Etablir une base solide pour traiter les problèmes de cohérence et de


redondance des données.

Le modèle relationnel présente également de nombreux avantages dus au fait


qu'il soit basé sur la théorie des ensembles : Langage de manipulation des données

Patrick KASONGA patrick.kasonga@esisalama.org


Bases de données, L1 ESIS, 2019 – 2020, Chap II Page |2

ensemblistes grâce à l'algèbre relationnelle et grâce à des langages assertionnels qui


permettent de spécifier ce que l'on souhaite obtenir sans dire comment l'obtenir. Le
SGBD est responsable de la politique d'exécution des requêtes.

En 1986, grâce à IBM, le modèle relationnel et son langage SQL ont été
standardisées au niveau international (ISO089)

A l’heure actuelle, il s’avère que les bases de données relationnelles


sont de loin le type de base de données fréquemment utilisé. L’accès aux données est
beaucoup plus aisé et plus sûr dans la mesure où la base de données devient
responsable d’une partie de sa propre intégrité. Tous les développeurs restent
impressionnés par les possibilités qu’offrent des bases de données relationnelles
telles que SQL Server et ORACLE. En effet, ces derniers fournissent des données à
grande échelle tout en leur permettant de concevoir une meilleure intégrité.

II.2. Objectifs

- Proposer des schémas faciles ou simples à utiliser, car on a des relations où les liens
physiques entre objets n’apparaissent pas mais existent, et aussi parce que la
représentation se fait à l’aide d’une table de valeurs ;

- Améliorer l’indépendance logique et l’indépendance physique entre les données et


les programmes ;

- Mettre à la disposition des utilisateurs des langages évolués (de haut niveau) de type
« non procédural ».Dans le langage non procédural, on dit seulement ce qu’on veut
avoir mais on ne précise pas comment y arriver ; c’est le SGBD qui choisit le meilleur
chemin pour y parvenir.

II.3. Modèle Entité – association

Le modèle relationnel est basé sur le schéma Entité – Association et repose sur les
notions mathématiques simples de la théorie des ensembles. C’est un modèle de type
conceptuel et est actuellement utilisé par plusieurs méthodes et outils d’aide à la
conception de bases de données. Le modèle E/A permet une représentation
graphique assez lisible du chemin d’une base de données.

Patrick KASONGA patrick.kasonga@esisalama.org


Bases de données, L1 ESIS, 2019 – 2020, Chap II Page |3

Toute organisation faisant partie du monde réel peut être représentée comme un
tout constitué de deux éléments :
- les objets (appelés Entités)
- les liens entre ces objets (appelés Associations)

II.3.1. Le concept d’entité

Une entité est un objet concret ou abstrait de la réalité pour lequel on souhaite
connaître et enregistrer des informations.

Une entité est une représentation d’un élément matériel ou immatériel du monde
réel ayant un rôle dans le système où l’on voudrait opérer. C’est un modèle d’objet
identifié du monde réel dont le type est défini par un nom et une liste de propriétés
(rubriques) qui le caractérisent.

L’identification [logique] des entités à modéliser constitue la première étape de


représentation logique des données.
Ces entités peuvent définir des personnes, des endroits, des choses ou des concepts.
Généralement elles correspondent aux noms figurant dans le système à modéliser.
On peut finalement conclure qu’une entité est un regroupement d’objets :
- ayant la même nature
- jouant le même rôle
- ayant la même structure informationnelle

Exemples : Le Client d’une banque, le cours enseigné dans une école, le malade dans
un hôpital, l’étudiant dans une université, etc.

II.3.2. Entité et instances d’entité

Lorsque les propriétés d’une entité prennent des valeurs, l’ensemble de ces
valeurs constitue une instance d’entité. Il s’agit donc d’un objet précis d’une entité.
Ainsi, dans la vision tabulaire d’une entité, toutes les lignes de valeurs appelées
« tuples » ou « n-uplets » ou encore « enregistrements » constituent des instances de
cette entité.

Exemple :
Entité Instances d’entité

Patrick KASONGA patrick.kasonga@esisalama.org


Bases de données, L1 ESIS, 2019 – 2020, Chap II Page |4

Intitulé =
COURS
Mathématiques
….
Intitulé Intitulé = Bases de
… Données

Intitulé = Réseaux

II.3.4. Le concept d’attribut et de domaine


Un attribut est une propriété caractéristique d’une entité qui est utile ou
nécessaire, mais pas forcément pertinente pour décrire la réalité perçue. Il prend une
valeur bien précise pour chaque occurrence d’une entité.

Par exemple, un produit vendu dans un magasin peut avoir les attributs suivants :
- le code
- la désignation
- la quantité en stock
- le prix de vente unitaire

Un attribut prend ses valeurs dans un ensemble des valeurs possibles appelé
« domaine ».

Un domaine est un ensemble de valeurs atomiques. On distingue deux types de


domaines :
a. les domaines prédéfinis : les chaines de caractères, les entiers, les réels, les
booléens
b. les domaines définis dont
 les domaines définis en extension (on énumère les valeurs ou éléments de
l’ensemble) ; Par exemple COULEUR = {« bleu », « rouge », « jaune »}
 les domaines définis en intension (on donne la formule ou propriété que doit
vérifier chaque valeur ; Exemple Mois = { m/m est un entier et 1≤m≤12 }
Exemple

Attribut Domaine

Nom d'une personne Caractères alphanumériques

Quantité en stock Nombre entier positif

Patrick KASONGA patrick.kasonga@esisalama.org


Bases de données, L1 ESIS, 2019 – 2020, Chap II Page |5

Prix d'un article Nombre avec 2 décimales

Date d'une commande Jour / Mois / Année

II.3.5. Définition d’une relation

Une relation est un sous-ensemble du produit cartésien de n domaines D1, D2


… Dn
R  D1xD2xD3x…xDn

On dit que R est une relation définie sur les domaines D1, D2, … Dn
Exemple : soient les 3 domaines

Nom = {Ornella, Dan, Joyce}


Age = {21, 7 , 10}
Sexe = {M, F}

R = {(Ornella, 22, F), (Dan, 7, M), (Joyce, 10, F)}

R est un sous-ensemble du produit cartésien Nom x Age x Sexe


R  Nom x Age x Sexe

II.3.6. Vision tabulaire d’une relation

L’extension d’une relation R peut être vue comme une table de nom R
possédant n colonnes et dont chaque ligne représente un tuple de la relation.
C’est ainsi qu’une relation s’appelle aussi table et les attributs sont des colonnes.

Exemple : AGENT

MAT NOM AGE

A001 NKULU 24

A074 ILUNGA 32

A195 MASENGO 24

… … …

Patrick KASONGA patrick.kasonga@esisalama.org


Bases de données, L1 ESIS, 2019 – 2020, Chap II Page |6

II.3.7. Concept d’identifiant ou clé primaire

L’identifiant ou la clé primaire est un attribut (ou le plus petit sous-ensemble


d’attributs) permettant de repérer de manière unique une occurrence parmi toutes les
occurrences possibles d’une entité.
C’est, en d’autres termes, une propriété particulière d'un objet telle qu'il n'existe pas
deux occurrences de cet objet pour lesquelles cette propriété pourrait prendre une
même valeur.
Ainsi, chaque individu d’une entité doit être identifiable de manière unique. C’est
pourquoi les entités doivent toujours posséder un attribut (ou un groupe d’attributs)
sans doublon qu’est l’identifiant ou la clé primaire (toujours souligné).

La clé primaire est choisie parmi les clés candidates d’une relation. En effet,
une relation peut posséder une ou plusieurs candidates.
Exemple : AGENT (matricule, nom, fonction, âge, nss)
où nss est le numéro de sécurité sociale
La relation AGENT possède deux clés candidates qui sont : matricule et nss

Règles pour choisir la clé primaire parmi plusieurs clés candidates


- prendre celle qui est proche de la sémantique de la relation, sinon
- prendre celle qui est la plus utilisée dans l’organisation, sinon
- prendre celle qui contient celle qui contient le moins de caractères (longueur
minimale), sinon
- faire un choix arbitraire

Dans l’entité AGENT, l’attribut matricule est sémantiquement plus proche de l’agent
que le nss. Donc matricule peut être choisi comme clé primaire.

II.3.8. Clé étrangère

Un attribut X (ou éventuellement un ensemble d’attributs X) est une clé


étrangère d’une relation R1 s’il existe une relation R2 possédant X comme clé primaire.
Ainsi, on dira que :
- l’attribut X réfère la relation R2
- R1 est une relation référençante
- R2 est une relation référencée

Exemple

AGENT (matricule, nomagent, fonctionagent, telagent)

Patrick KASONGA patrick.kasonga@esisalama.org


Bases de données, L1 ESIS, 2019 – 2020, Chap II Page |7

ENFANT (nomenf, postonenf, prenomenf, sexenf, matricule#)

Ici, l’attribut matricule est une clé étrangère de la relation ENFANT et il réfère la relation
AGENT.
ENFANT est donc une relation référençante et AGENT est une relation référencée.

II.3.9. Association
Une association représente les liens sémantiques qui peuvent exister entre deux
ou plusieurs entités.
A titre illustratif, on a l’association Acheter entre les entités Personne et Voiture.

PERSONNE VOITURE

ACHETE
… R …
… …

N.B.

* Une association peut aussi posséder des attributs. Dans l’exemple ci-dessus, les
attributs date d’achat et prix peuvent appartenir à l’association Acheter.

* L’identifiant d’une association est constitué de l’ensemble des identifiants des entités
impliquées dans l’association.

II.3.10. Cardinalités
La cardinalité d’un lien entre une entité et une association est le minimum et le
maximum de fois qu’une occurrence de l’entité peut être concernée par l’association.
- Minimum : 0 ou 1
- Maximum : 1 ou n
- Combinaisons possibles : (0,1) (1,1) (0,n) (1,n)
Exemple

CLIENTS 1,n 0,n ARTICLES 1,n 1,n FOURNISS

- nºclient -nºart - nºfourn


- nomcl ACHETER
- nomart LIVRER - nomfourn
- prénomcl - P.U. - nºtél
- adressecl - Qté cdée - stock
- date - qtélivrée
- datelivr
- nomlivr

- Un client peut acheter une à plusieurs fois (car pour être considéré comme client, il
faut avoir acheté au moins une fois) ; d’où (1,n)

- Un article peut ne pas être acheté ; ou s’il l’est, il peut l’être plusieurs fois. D’où (0,n)

Patrick KASONGA patrick.kasonga@esisalama.org


Bases de données, L1 ESIS, 2019 – 2020, Chap II Page |8

II.3.11. Contraintes d’intégrité relationnelle


Une contrainte d'intégrité est une propriété du schéma E/A, invariante dans le
temps. On peut aussi l’appeler règle de gestion. C’est en fait une règle de cohérence
et de précision dans la structure des données qui forment le système observé.
Il existe trois types de contraintes d’intégrité :
- l’intégrité de domaine
- l’intégrité d’entité
- l’intégrité référentielle

a. L’intégrité de domaine

Les contraintes d’intégrité de domaine forment des restrictions sur l’ensemble


des valeurs autorisées pour les attributs des relations.
Une intégrité de domaine concerne un contrôle syntaxique et sémantique d’une valeur
d’un attribut par rapport au domaine de l’attribut.
Par exemple, âge ≥ 18
b. L’intégrité d’entité

L’intégrité d’entité stipule que toute entité doit toujours posséder une clé
primaire et que cette clé primaire ne peut posséder des valeurs nulles.

Une valeur nulle est une absence de valeur ou une valeur inconnue. Elle est différente
d’un zéro (0) un d’un caractère blanc (« »)

c. La contrainte d’intégrité référentielle

L’intégrité référentielle est une contrainte exprimée entre deux relations et qui
concerne la valeur d’une clé étrangère dans une relation référençante. Intuitivement,
elle consiste à vérifier que l'information utilisée dans un n-uplet pour désigner un autre
n-uplet est valide, notamment si le n-uplet désigné existe bien.
Par exemple, on ne peut créer une commande pour un fournisseur qui n’existe pas,
de même qu’on ne peut supprimer un fournisseur pour lequel il existe encore des
commandes non soldées.

II.4. Perception du monde réel


Le monde réel peut être modélisé à l’aide d’entités qui représentent les objets
ayant une existence visible, et d’associations entre ces objets.

Patrick KASONGA patrick.kasonga@esisalama.org


Bases de données, L1 ESIS, 2019 – 2020, Chap II Page |9

A titre d’exemple, soient les données modélisant des entités « personne » et


« voiture », et le type d’association « possède » qui traduit le fait qu’une personne est
propriétaire d’une ou plusieurs voitures.
Une personne est caractérisée par un numéro de sécurité sociale (NSS), un
nom et un prénom alors qu’une voiture est caractérisée par les attributs Numéro de
véhicule, Marque, Type, Puissance et Couleur.
Chaque personne est identifiée par une occurrence du numéro de sécurité sociale
(NSS) alors que chaque voiture est identifiée par un numéro de véhicule (NV).
A chaque occurrence d’association correspond par exemple une date d’achat (DATE)
et un prix d’achat (PRIX).

La figure ci-dessous illustre la partie du monde réel modélisée en représentant


une entité par un rectangle, une association par un hexagone et un attribut par un
cercle.

Graph.2

PERSONNE POSSED VOITURE


E

NS NOM PREN DATE PRIX NV MARQU TYPE PUISSANC COULEUR


S E E

Le modèle relationnel se prête bien à la représentation des entités et des


associations. Une entité est représentée par une relation ( table ) dont le schéma est
le nom de l’entité suivi de la liste des attributs de l’entité.
Par exemple, les entités PERSONNE et VOITURE seront respectivement
représentées par les relations :

PERSONNE (NSS, NOM , PRENOM )


VOITURE (NV, MARQUE, TYPE, PUISSANCE, COULEUR )

Une association est représentée par une relation dont le schéma est le nom de
l’association, suivie de la liste des identifiants des entités participantes et des attributs
de l’association.
Par exemple, l’association POSSEDE sera représentée par la relation :

Patrick KASONGA patrick.kasonga@esisalama.org


Bases de données, L1 ESIS, 2019 – 2020, Chap II P a g e | 10

POSSEDE (NSS, NV, DATE, PRIX).

Notons qu’une mauvaise perception des entités et associations représentant le


monde réel modélisé conduit à des relations problématiques.
Imaginons par exemple que l’on isole une entité unique PROPRIETAIRE contenant
tous les attributs des trois relations PERSONNE, VOITURE et POSSEDE. Ainsi, nous
pourrions représenter toutes les informations modélisées par une seule relation.

La figure ci-dessous représente une extension possible de cette relation :

PROPRIETAIRE

NV MARQUE TYPE PUIS COUL NSS NOM PRENOM DATE PRIX

SH402B Renault R12TS 6 Rouge 100 AMISI Alain 10.02.75 2000

KN511S Peugeot 504 9 Verte 100 AMISI Alain 11.06.80 9000

KT689J Citroen 2CV 2 Bleue 200 KADI Pierre 20.04.76 1000

CD750N Citroen AM18 5 Bleue 200 KADI Pierre 20.08.81 5000

KT900G Renault R18B 9 Verte 300 MBAY Yves 11.09.99 6000

La relation représentée ci-dessus souffre de plusieurs types d’anomalies:


- tout d’abord, des données sont redondantes ; par exemple, AMISI Alain et KADI
Pierre apparaissent deux fois ; plus généralement, une personne apparaît autant de
fois qu’elle possède de voitures ;
- ces redondances conduisent à des risques d’incohérences lors des mises à jour : par
exemple, si l’on s’aperçoit que le prénom de KADI n’est pas Pierre mais Jean, il faudra
veiller à mettre à jour les deux tuples contenant KADI sous peine de voir apparaître un
KADI Pierre et un KADI Jean ;
- il est nécessaire d’autoriser la présence de valeurs nulles dans une telle relation afin
de pouvoir conserver des voitures sans propriétaire ou des personnes ne possédant
pas de voitures dans la base.

En résumé, une relation qui ne représente pas de vraies entités ou associations


semble donc souffrir de la présence de données redondantes et d’incohérences

Patrick KASONGA patrick.kasonga@esisalama.org


Bases de données, L1 ESIS, 2019 – 2020, Chap II P a g e | 11

potentielles et nécessite le codage de valeurs nulles. Il y a donc tout intérêt à éliminer


ces anomalies afin de faciliter la manipulation des relations.

Cette procédure d’élimination d’anomalies peut se faire à l’aide d’une approche


par décomposition. Celle-ci tend à partir d’une relation composée de tous les attributs,
appelée la relation universelle, et à décomposer cette relation en sous-relations qui ne
souffriraient pas des anomalies précédemment signalées.
La décomposition susmentionnée s’effectue par la notion de dépendances
fonctionnelles.

II.5. Dépendances fonctionnelles

II.5.1. Définition
La notion de dépendance fonctionnelle fut introduite par CODD afin de
caractériser des relations qui peuvent être décomposées sans perte d’informations.

Soit une relation R ( A, B, C, D )


On dit que A détermine C ou que C dépend fonctionnellement de A, et on note A → C,
ssi ayant deux tuples ( a1, b1, c1, d1 ) et (a2, b2, c2, d2 ) tels que si a1=a2, alors c1=c2.

Plus simplement, un attribut ( ou un groupe d’attributs ) Y dépend


fonctionnellement d’un autre attribut ( un groupe d’attributs ) X si la connaissance d'
une valeur de X lui fait correspondre une valeur unique de Y.

Ex1 : Matricule Nom Prénom Catégorie Adresse

Ici, le Matricule de l’agent détermine son Nom, son Prénom, sa Catégorie et son
Adresse.

Ex2 : Nom-Fournisseur Article Fourni Adresse Fournisseur Prix

De même ici, l’Adresse Fournisseur et le Prix sont déterminés par le Nom du


Fournisseur et l’Article Fourni.

Patrick KASONGA patrick.kasonga@esisalama.org


Bases de données, L1 ESIS, 2019 – 2020, Chap II P a g e | 12

II.5.2. Propriétés
Soit la relation R ( A, B, C, D )
1. Réflexivité : A → A
2. Transitivité : si A → B et B → C, alors A → C
3. Pseudo-transitivité : si A → B et B, C → D, alors A,C → D

Ex : Soit un atelier où Total Heures = nombre d’heures prestées dans un atelier


en un mois.
N° Machine → N° Atelier
Mois, N° Atelier → Total Heures

Alors N°Machine, Mois → Total Heures

4. Augmentation : si A → B , alors A, C → B C
5. Union : si A → B et A → C , alors A → B, C
6. Décomposition : si A → B, C alors A → B et A → C

II.5.3. Types de dépendances

a. Dépendance élémentaire (totale)

Soit une relation R ( A, B, C, D )


On dit que A → B est une dépendance élémentaire ou totale ssi il n’existe pas une
partie A’  A telle que A’ → B.

A → B signifie que B dépend totalement ou entièrement de A.

b. Dépendance directe

Soit une relation R ( A, B, C, D )

Une dépendance A → B est directe s’il n’existe pas un attribut C dans R tel qu’on ait
A → C et C → B.
En d’autres termes, la dépendance A → B est directe si et seulement si l’attribut B ne
peut pas dépendre d’un attribut autre que A
On dit alors que B dépend directement de A.

Patrick KASONGA patrick.kasonga@esisalama.org


Bases de données, L1 ESIS, 2019 – 2020, Chap II P a g e | 13

Ex : AUTO ( Nº, MARQUE, TYPE, PUISSANCE, COULEUR )

1) Nº → PUISSANCE
2) Nº → TYPE directe
3) Nº → COULEUR
4) TYPE → PUISSANCE directe

Mais (1) n’est pas directe car il y transitivité entre (2) et (4) ou encore parce que
l’attribut PUISSANCE dépend de N° et de TYPE.

II.6. Normalisation

II.6.1. Définition
La normalisation est une opération qui consiste à examiner dans quelle
condition une relation R souffrant de quelques anomalies (cfr supra) peut être
remplacée par deux relations normales R1 et R2 telles que l’espace des attributs R1 et
R2 soit plus petit que celui de R et que R1 et R2 contiennent les mêmes informations
que R.

II.6.2. Formes normales

a. Première forme normale ( 1NF)

` Une relation R est en 1NF si tout attribut contient une valeur atomique
(élémentaire) en fixant la clé, c'est-à-dire qu'il existe au moins une clé caractérisant
chaque occurrence de l'objet représenté.
La définition de la clé entraîne la première forme normale. Cette forme normale
consiste simplement à éviter les domaines composés de plusieurs valeurs.

b. Deuxième forme normale (2NF)

Une relation R est en 2NF si :


- elle est en 1NF
- toutes les dépendances qui partent de la clé vers les autres attributs sont totales,
c’est-à-dire CLE → A est totale  A.
Autrement dit, tout attribut n’appartenant pas à la clé ne dépend pas d’une partie de
cette clé.

Patrick KASONGA patrick.kasonga@esisalama.org


Bases de données, L1 ESIS, 2019 – 2020, Chap II P a g e | 14

Ex : FOURNISSEUR ( NOM-F, ART, ADR-F, PRIX )

- La clé est ( NOM-F, ART )


- NOM-F, ART → ADR-F n’est pas totale car il existe NOM-F → ADR-F
NOM-F, ART → PRIX est totale

Donc FOURNISSEUR n’est pas en 2NF


Ainsi, dans la dépendance non totale NOM-F, ART → ADR-F, on tire la dépendance
NOM-F → ADR-F qui est totale.

On décompose alors FOURNISSEUR en deux relations qui sont :


R1 ( NOM-F, ADR-F )
R2 ( NOM-F, ART, PRIX ) qui sont toutes deux en 2NF.

c. Troisième forme normale 3NF

Une relation R est en 3NF si :


- R est en 2NF
- toutes les dépendances de la clé vers les autres attributs sont directes, c’est-à-dire
tout attribut n’appartenant pas à la clé ne dépend pas d’un attribut non clé.
Ex : AUTO ( Nº, TYPE, MARQUE, COULEUR, PUISSANCE )

La dépendance Nº → PUISSANCE n’est pas directe car elle est transitive :

Nº → TYPE
TYPE → PUISSANCE Nº → PUISSANCE.

Donc AUTO n’est pas en 3NF.


D’ou il faut la décomposer.
On retient : Nº → TYPE, MARQUE, COULEUR
TYPE → PUISSANCE

D’où R1 (Nº, MARQUE, TYPE, COULEUR ) en 3NF

R2 ( TYPE, PUISSANCE ) en 3NF

d. Forme normale de Boyce - Codd (BCNF)

Patrick KASONGA patrick.kasonga@esisalama.org


Bases de données, L1 ESIS, 2019 – 2020, Chap II P a g e | 15

La 2ème forme normale élimine les anomalies créées par les dépendances
entre parties de clé et attributs non clé. La 3ème forme normale élimine les anomalies
créées par des dépendances entre attributs non clé. Quid des dépendances
fonctionnelles des parties de clé entre elles ou d’attributs non clé vers une partie de
clé ? La 3ème forme normale est insuffisante.
Afin d’éliminer les redondances créées par les dépendances entre parties de clé et
celles déjà éliminées par la 3ème forme normale, Boyce et Codd ont introduit la forme
normale qui porte leur nom (BCNF).
« Une relation est en BCNF si et seulement si les dépendances fonctionnelles
élémentaires sont celles dans lesquelles une clé entière détermine l’attribut ».
En d’autres termes, tout attribut faisant partie de la clé ne doit pas dépendre
d’un attribut non clé.

II.6.3. Relation normalisée


Une relation est dite normalisée si elle est en 3NF.
Si elle ne l’est pas, il faut la décomposer.

Ex : Voir exemple précédent où : R1= VEHICULE


R2 = MODELE

On en déduit le schéma relationnel ci-après :

VEHICULE MODELE
NºV Marque
Marque Type
Type Puissance
Couleur

II.6.4. Avantages de la normalisation


La normalisation permet :

1) une cohésion des attributs autour de la clé.

2) De supprimer et diminuer les anomalies en mise à jour (réduire la redondance


d’informations, d’où la réduction des I/O), en insertion et en suppression.

Patrick KASONGA patrick.kasonga@esisalama.org

Vous aimerez peut-être aussi