Chapitre II Modèle relationnel

Le modèle relationnel

 E. F. Codd, 1970
 Le modèle relationnel organise les données dans des tableaux bidimensionnels : colonnes et
lignes.
 Le modèle relationnel comprend : les relations, les tuples, les attributs, les clés primaires et les
clés étrangères.
 Les modèles relationnels sont représentés par un ensemble de schémas relationnels.
 Le modèle relationnel (suite)

 Les valeurs dans les colonnes de ligne peuvent être utilisées pour relier/lier des lignes dans
des tables
 fournit une visualisation des relations.
 Limiter au minimum la duplication des éléments de données entre les tables
 utiliser un processus formel appelé normalisation pour configurer des tables
« optimales ».
 Objectif = « simplicité » => permettre aux utilisateurs finaux d'accéder directement aux
bases de données.
 Trop difficile, mais les professionnels de la base de données peuvent développer et
accéder pour eux.
 Le modèle relationnel (suite)

 Comme nous allons le voir dans ce chapitre, on ne peut pas se contenter de placer toute
une base de données dans une seule table, sous peine de rencontrer rapidement des
problèmes insurmontables.
 Une base de données relationnelle, c’est un ensemble de tables associées les unes aux
autres. La conception du schéma (structures des tables, contraintes sur leur contenu, liens
entre tables) doit obéir à certaines règles et satisfaire certaines propriétés.
 Une théorie solide, la normalisation a été développée qui permet de s’assurer que l’on a
construit un schéma correct.
Eléments d’un model relationnel

 Une relation est un tableau avec des colonnes et des lignes

 Attribut est une colonne nommée d'une relation
 Domaine est l'ensemble des valeurs autorisées pour un ou plusieurs attributs.
 Tuple est une ligne d'une relation
 Le degré est le nombre d'attributs dans une relation.
 La cardinalité est le nombre de tuples dans une relation.
 La base de données relationnelle est une collection de relations normalisées avec des
noms de relation distincts.
Eléments d’un model relationnel

 La clé primaire c’est un ou plusieurs attributs qui identifient d’une manière unique un
tuple dans une relation
 Clé étrangère c’est un attribut qui permet de relier deux relations
 Type de données: c’est le domaine de données définit pour chaque attribut
 Schémas : c’est une définition structurelle des relations , leurs attributs, les types de
données et comment ils sont associés
 Instance de base de données: c’est le contenu de l’ensemble des relations à un
moment donné
Relations

 Définition; une relation est un tableau (ou table) à deux dimensions qui contient
des données relatives à une entité (objet) d'intérêt.
 Toutes les cellules contiennent une seule valeur (pas de tableaux)
 Les entrées d'un attribut sont toutes du même domaines, logiques et physiques,
 Les n-uplets doivent être uniques (doit avoir une clé primaire)
 Nom unique pour chaque attribut
 L'ordre des lignes et des colonnes n'a pas d'importance
 Pas de groupes répétitifs – plus d'un attribut du même domaine physique et
logique (ex. auteur1, auteur2, etc.)
 Remarque : Par définition, toutes les relations sont automatiquement en première
forme Normale (1NF).
Représentation des relations

 Dans le modèle relationnel, la seule structure acceptée pour représenter les données
est la relation.
 Étant donné un ensemble d’objets 𝑂, une relation (binaire) sur 𝑂 est un sous-ensemble
du produit cartésien 𝑂 × 𝑂( le produit cartésien entre deux ensembles 𝐴 × 𝐵 est
l’ensemble de toutes les paires possibles constituées d’un élément de 𝐴 et d’un
élément de 𝐵.)
 exemple

Une relation binaire représentée comme un graphe

Représentation des relations(suite)

 Une relation est un objet abstrait, on peut la représenter de différentes manières. Une
représentation naturelle est le graphe.
 Une autre structure possible est la table, qui s’avère beaucoup plus pratique quand la
relation n’est plus binaire mais ternaire et au-delà.
Attributs

nuplets

 Dans une base de donnée relationnelle, on utilise toujours la représentation d’une

relation sous forme de table. À partir de maintenant nous pourrons nous permettre
d’utiliser les deux termes comme synonymes.
Le schéma

 un schéma est l'organisation de l'information et ses relations. un schéma de bases

de données est une collection de structure de données dans une base de
données ou une conception abstraite de la façon dont les données sont stockées
dans une base de données. Dans MySQL, le schéma et la base de données sont
utilisés de manière interchangeable.
 la représentation par graphe que celle par table incluent un nommage de
chaque dimension (le nom du département, son code, dans notre exemple).
 Ce nommage n’est pas strictement indispensable (on pourrait utiliser la position
par exemple), mais s’avère très pratique et sera donc utilisé systématiquement.
Notation d’un schémas relationnel

 Les relations peuvent être représentées sous forme de texte : Appelée

schémas relationnel
 NOMRELATION(attr1, attr2,..., attrN) avec l’attribut représentant la clé
primaire est souligné. L’attribut représentant la clé étrangère si elle existe
est en italique ou bien attr(fk)
Propriétés d’une relation

➢ Chaque tuple est distinct; il n’y a pas de duplicata

 L’ordre des attributs(colonnes) n’a pas d’importance.
 L’ordre des tuples n’a pas d’importance théoriquement.
 Chaque cellule d’une relation (tableau) contient exactement une valeur
 Chaque attribut (colonne) a un nom unique.
 Les valeurs d’un attribut proviennent toutes d’un même domaine
 Deux lignes ne peuvent pas être identiques
 Le nom d’une relation doit être distinct des noms des autres relations dans
le même model relationnel c’est –à-dire on ne peut pas avoir deux tables
avec le même nom.
 Cette relation est elle valide?

EMPLOYE

NSS Nom Date de naissance

123-45-5678 Maidagi 06/11/74
888-99-7766 Soumana 04/11/80
123-45-5678 Maidagi 06/11/74
 Cette relation est elle valide?

EMPLOYE

NSS Nom Date de naissance

123-45-5678 Abdou 12/03/54
888-99-7766 Soumana 04/11/80
332-45-3672 Maidagi 06/11/74
Cette relation est elle valide?

EMPLOYE

NSS Nom Date de naissance

123-45-5678 Issoufou 12/03/54
888-99-7766 Aichatou Comptabilité
332-45-3672 Hama 06/11/74
 n-uplet

 Un élément d’une relation de dimension n est un n-uplet (𝑎1, 𝑎2, · · · , 𝑎𝑛).

 Dans la représentation par table, un n-uplet est une ligne. Là encore nous
assimilerons les deux termes, en privilégiant toutefois n-uplet qui indique plus
précisément la structure constituée d’une liste de valeurs.
 On ne peut pas trouver deux fois le même n-uplet car il n’y a pas de doublons
dans un ensemble.
Les Clés

 Une relation doit avoir un ou plusieurs attributs qui définissent chaque ligne de
manière unique.
 Cet ensemble d'attributs est appelé clé primaire. Exemple : Quelle est la clé de
cette relation ?
 ÉTUDIANT (ID-Etudiant, nom, spécialité)
 Les clés primaires sont notées dans les relations en les soulignant :
 Pour les clés composées de plusieurs attributs (clés composés), tous
les attributs qui font partie de la clé sont soulignés.

Comment passer du modèle
conceptuel au modèle logique

1. l’ensemble des entités transformées en des relations(tableaux à deux

dimensions)
2. Chaque attribut d’une entité devient l’attribut de la relation
3. L’identifiant de l’entité devient la clé primaire de la relation
4. Toute association de type N:M dans le diagramme d’entité association devient
une relation dans le model relationnel et aura pour clé primaire les deux clés
primaires des deux relations qui sont associées.
5. Toute association de type 1:M est représentée sous forme de clé étrangère
avec la clé primaire de l’entité de cardinalité 1 qui passe vers l’entité de
cardinalité M comme clé étrangère.
6. L’association 1:1 prenez la clé primaire de l’une des deux relations et la placer
dans l’autre relation comme clé étrangère
7. M:N dans ce cas on introduit une nouvelle relation intermédiaire qui
comprendra les deux clés primaires des deux relations originales..
Clés étrangères

 Les clés étrangères sont ajoutées à une relation pour montrer la relation
entre deux (ou plusieurs) entités.
 Les clés étrangères sont notées avec un soulignement en pointillés ou en
italique.
 ex. FKey ou Fkey
 Exemple
ETUDIANT DORTOIR

ID-Etudiant Bâtiment
Nom Chambre
Spécialité Téléphone
Exemple de clé étrangère

 Étant donné:
 ÉTUDIANT(ID-Etudiant, Nom, Spécialité )
 Dortoir(Bâtiment, Chambre, Téléphone)
 Comment relie-t-on un étudiant à un dortoir ?
 ÉTUDIANT(ID-Etudiant, Nom, Spécialité, Bâtiment, Chambre)
 ou
 ÉTUDIANT (ID-Etudiant, nom, Spécialité, Bâtiment, chambre)
Clés étrangères(suite)

 Le ratio de cardinalité d'une relation détermine quelle entité (ou les

entités) qui contiendra la clé étrangère.
 Il y a trois (3) situations possibles :
 1:1
 1:N
 N:M
Entités associatives

 Lorsqu'une entité associative est créée, elle transforme une relation

plusieurs-à-plusieurs en deux relations un-à-plusieurs.
 Lorsqu'une association plusieurs-à-plusieurs a un ou plusieurs attribut(s),
alors la relation devient une entité associative.
 Tous les attributs sont ajoutés à l'entité associative.
Contraintes

 Afin de préserver l’intégrité de données dans le model relationnel il y a des

contraintes.
 Contrainte de domaine
 Contrainte d’unicité
 Contrainte d’intégrité référentielle
 Contraintes d’intégrité.

 Une propriété que toutes les instances d’une base de données doivent satisfaire
 Il y a deux types de contraintes:
1. Les contraintes intra-relationnelles définies sur les attributs d’une seule relation (exemples:
contrainte d’unicité, les contraintes du domaine, les contraintes des nuplets ou lignes)
2. Les contraintes interrelationnelles, définies sur plusieurs relations en même temps (exemple:
contraintes d’intégrité référentielle)
Contraintes d’intégrité.

 Il y a toujours des contraintes et il est indispensable de les inclure dans le schéma pour assurer
(dans la mesure du possible) l’intégrité de la base.
Voici les règles (ou contraintes d’intégrité́) que l’on peut demander au système de garantir :
 La valeur d’un attribut doit être unique au sein de la table.
 Un attribut doit toujours avoir une valeur. C’est la contrainte « not null » vue précédemment.
 Un attribut (ou un ensemble d’attributs) constitue(nt) la clé de la table.
 Un attribut dans une table est liée à la clé́ primaire d’une autre table (intégrité́ référentielle).
 Enfin toute règle s’appliquant à la valeur d’un attribut (min et max par exemple).
Les contraintes sur les clés (unicité́ et intégrité́ référentielle) doivent être systématiquement
spécifiées.
Contrainte de domaine

 La valeur de données pour chaque attribut doit être une valeur atomique
dans son domaine. Par exemple si c’est définie comme entier elle doit
prendre une seule valeur parmi les valeurs possibles de l’ensemble des
entiers.
 Elle exprime des conditions sur la valeur prise par un attribut d’un n-uplet. Il
peut s'agir d'une expression booléenne (et, ou, non) de prédicats simples
 exemple : Score > 0 et Score ≤ 30
Contrainte d’unicité

 La clé primaire ne peut pas se répéter

Contrainte d’intégrité référentielle

 Intégrité référentielle : la valeur d'une clé étrangère dans une relation

« fille » doit exister dans la relation « mère « comme clé primaire.
 Exemple :
 EMP(EMP#, Nom, DateDeNaissance, ...)
 VEHICULEDESERVICE(VIN, EMP#, Couleur, ...)
 La valeur trouvée dans EMP# dans VEHICULEDESERVICE, doit exister
d’abord dans la relation EMP.
 Intégrité référentielle

EMP# Nom DateDeNaissance

EMP 1 Abdou 12/15/1955
2 Souley 8/3/1967
3 Amadou 9/12/1973

VIN EMP# Couleur

VEHICULEDESE
556AA76541 1 Blue
RVICE
3456FG8876 3 Jaune
3905HHA903 2 Rouge

Cela viole-t-il l'intégrité référentielle ?

 Exemples

Num
IDClient Nom

Placé
CLIENT par/place COMMANDE

Date
Adresse

CLIENT(IDClient, Adresse, Nom)

Binaire 1 à plusieurs

Entité A Entité B

Attribut 1 Attribut 1
Attribut 2 Attribut 2
Attribut 3 Attribut 3

Entité1(Attribut1, Attribut2, Attribut3)

Binaire plusieurs à plusieurs

Entité A Entité B

Attribut 1 Attribut 1
Attribut 2 Attribut 2
Attribut 3 Attribut 3

EntitéA(Attribut1, Attribut2, Attribut3)

EntitéB(Attribut1, Attribut2, Attribut3)
Unaire un à plusieurs

Entité 1

Attribut 1
Attribut 2
Attribut 3

Entité1(Attribut1, Attribut2, Attribut3, Attribut1B(fk))

Unaire plusieurs à plusieurs

Entité 1

Attribut 1
Attribut 2
Attribut 3

Entité1(Attribut1, Attribut2, Attribut3)

Entité1_1(Attribut1A(fk), Attribut1B(fk))
 Clés étrangères 1:1

A B
CléB
CléA
Attr2
Attr2
Attr3
Attr3

A(CléA, Attr2, Attr3)

B(CléB, Attr2, Attr3, CléA)
ou
A(CléA, Attr2, Attr3, CléB)
B(CléB, Attr2, Attr3)
Clés candidates

 Il est possible qu'une relation ait plusieurs attributs possibles, ou groupes

d'attributs, qui pourraient être la clé primaire.
 Exemple :
 EMPLOYÉ(IDEmp, Nom, NoSS, DatedeNaissance, ...)
 Les attributs clé possibles sont appelés clés candidates.
 Les utilisateurs indiquent au concepteur de la base de données celui qu'ils
utilisent comme clé primaire.
 Clés étrangères 1:N

Règle : Le PK du « côté un »
A B de la relation migre vers le «
CléB côté plusieurs ».
CléA
Attr2
Attr2
Attr3
Attr3

A(CléA, Attr2, Attr3)

A B
B(CléB, Attr2, Attr3, CléA) CléB
CléA
Attr2
Remarque : le FK n'est Attr2
Attr3
normalement pas représenté dans Attr3
CléA
un diagramme E-R - à moins qu'il
n'y apparaisse naturellement.
 Clé étrangère Exemple #1

PK

DEPARTEMENT EMPLOYE

IDDept IDEmp
NomDept NomEmp
IDDept FK
Emplacement

Coté de « un » Coté de « plusieurs »

Clé étrangère Exemple #2

 Créer une autre association 1:N :

 Un projet a un gestionnaire.
 Un chef de projet peut gérer plusieurs projets.

PROJET GESTIONNAIRE

IDProjet
TitreProjet IDGest
DateDébut GestNom
IDGest
 Clés étrangères N:M

A B
CléB
CléA
Attr2
Attr2
Attr3
Attr3

A AB B
CléB
CléB CléB
CléA CléA
Attr2
La table AB est une entité Attr2 CléB
Attr3
associative. Le tableau est Attr3
généralement appelé tableau
« d'intersection » ou de « lien ».
Clés, dépendances et normalisation

 le schéma d’une relation consiste – pour l’essentiel – en un nom (de

relation) et un ensemble de noms d’attributs.
 On pourrait naïvement penser qu’il suffit de créer une unique relation et
de tout mettre dedans pour avoir une base de données.
 Le schéma d’une base de données est donc constitué d’un ensemble de
schéma de relations.
Normalisation

 C’est une technique pour produire un ensemble des relations

convenables (c’est-à-dire avec un nombre minimal d’attributs nécessaire
pour supporter les exigences de l’entreprise en matière de donnée, une
redondance minimale)qui supportent les exigences de l’entreprise en
matière de donnée.
 décomposition des relations pour éviter les anomalies lors de l'insertion, de
la mise à jour ou de la suppression de données.
 Sert également à réduire la redondance des données
Avantages de la Normalisation

 Résoudre les problèmes causés par la redondance de données

 Rendre facile l’accès et la maintenance de données
 Occuper un espace minimal de stockage
Anomalies

 Redondance : informations répétées à plusieurs endroits

 Anomalie de mise à jour : échec de modification de toutes les instances
d'une valeur spécifique.
 Anomalie due à la suppression : supprimer les données et perdre d'autres
valeurs comme effet secondaire
 Anomalie due à l’insertion : pas besoin d'ajouter des données sur plusieurs
« thèmes » dans une relation
 Règle générale : un tableau ne doit pas appartenir à plus d'un type
d'entité
Dépendance des données

 Déf. dépendance : c’est une relation ou un lien entre les attributs d’un
nuplet d’une même relation. Cela sous entend, étant donné la valeur
d'un (ou plusieurs) attribut(s), nous pouvons déterminer la valeur d'un autre
attribut par exple :
 Calcul : PrixTotal = PrixUnitaire * Quantity
 (PrixUnitaire, Quantity) PrixTotal
Dépendances fonctionnelles des données

 Dans l’objectif de comprendre les formes normales et le processus de la normalisation

nous avons besoin d’abord de comprendre les dépendances fonctionnelles.
 Les dépendances fonctionnelles décrivent les liens qui existent entre les attributs dans une
même relation
 Les dépendances fonctionnelles (DFs) sont exprimées comme suit :
 X→Z X détermine Z ; Z est totalement dépendant de X
 (X, Y) → Z et si (X, Y) est un vrai déterminant composé, alors X → Z et non Y → Z.
 D'autres dépendances de données existent (nécessitent une normalisation) :
 si (X, Y) → Z et X → Z et Non Y → Z, alors on a une dépendance partielle (anomalie), qu'il
faut éliminer.
 Si A → B et B → C et (B et C sont des attributs non clés) alors on a une dépendance
transitive.
Types de dépendances fonctionnelles

 Les dépendances fonctionnelles complètes/ partielles

 Les dépendances fonctionnelles transitives
Dépendances fonctionnelles complètes/partielles

 Dans une relation, si un ensemble d’attributs A: (a1, a2, ..., an) détermine
l’attribut B:
 A: (a1, a2, ..., an) → B
S’ il n’y a aucun sous ensemble propre de A qui lui aussi détermine B alors A:
(a1, a2, ..., an) → B est une dépendance fonctionnelle complète. Elle est
complète parce que nous avons besoins de tous les attributs dans l’ensemble
A pour déterminer B.
Par contre s’il y a un sous ensemble propre de A qui détermine B, alors A:
(a1, a2, ..., an) → B est une dépendance partielle.
Dans ce cas pour la rendre complète nous devons rendre l’ensemble A
minimal en enlevant les attributs non nécessaire.
Exemple

EmpID Nom Prenom DDN Fonction Département BoutiqueID

#20399 Ali Ousman 1998/2/12 Manager RH #1506

#30123 Ambouka Baidari 2001/3/12 Stagiaire Marketing #1546
#12524 Daouda Bilyamin 2000/2/20 Assistant Vente #1524

Senior
#14517 Abdou Boukari 2001/9/12 RH #1506
Manager

#15214 Mary Maidagi 2001/9/12 Assistant IT #1524

#11032 Ramatou Soumana 1999/1/21 Stagiaire IT #1503

Senior
#02012 Djalo Soumana 1977/12/1 IT #1503
Manager
Exemple(suite)

 EmpID + Nom + Prénom → DDN, cette dépendance fonctionnelle est elle

complète ou partielle ?
 EmpID + Nom → DDN, cette dépendance fonctionnelle est elle complète
ou partielle ?
 EmpID → DDN, cette dépendance fonctionnelle est elle complète ou
partielle ?
•NB: si A → B, et A a un seul attribut, alors elle doit être une dépendance
fonctionnelle complète.
Exemple(suite)

La Relation R (A, B, C, D, E, F, G) possède les dépendances fonctionnelles

suivantes:
•DF1: A, B, C → D, E, F, G
•DF2: A → D
•DF3: B, C → E
•DF4: F → G
•DF1 est elle complète or Partielle ?
•DF3 est elle complète or Partielle ?
Dépendance fonctionnelle transitive

 Dans une relation, si un attribut A détermine l’attribut B, et B détermine

l’attribut C (C différent de A):
 DF1: A → B
 DF2: B → C
 Nous pouvons avoir A → C parce que les dépendances fonctionnelles DF1
et DF2 forment une dépendance fonctionnelle transitive.
Exemple

 La Relation R (A, B, C, D, E, F, G) a les dépendances fonctionnelles

suivantes:
 DF1: A, B, C → D, E, F, G
 DF2: A → D
 DF3: B, C → E
 DF4: F → G
Existe-t-il des dépendances fonctionnelles transitives?
Processus de normalisation

 Le processus de normalisation consiste à convertir une relation étant dans une

forme moins restrictive à une forme plus restrictive.
 Ce niveau de restriction s’appelle la forme normale.
 Corrige ces anomalies en supprimant la redondance des données.
 Nous couvrirons les types de normalisation suivants :
 Première forme normale (1FN)
 Deuxième forme normale (2FN)
 Troisième Forme Normale (3FN)
 Il existe plusieurs formes supplémentaires de normalisation que nous ne
couvrirons pas dans ce cours :
 Quatrième forme normale (4FN)
 Cinquième forme normale (5FN)
 Forme normale de clé de domaine (DKNF)
Première forme normale

 1NF : La table doit satisfaire la définition d'une relation :

 tableau à 2 dimensions.
 Nom unique pour chaque colonne/attribut.
 Toutes les cellules contiennent une valeur unique - Pas de groupes
répétitifs.
 Les entrées d'un attribut sont toutes du même type de données
(domaine).
 Pas de lignes identiques – chaque ligne est identifiable de manière
unique.
 L'ordre des lignes et des colonnes n'a pas d'importance.
Première forme normale(suite)

 Si une table répond aux critères d'être une relation, elle est en première
forme normale.
 Forme normale la plus simple.
 Fait peu pour réduire les anomalies.
 Cependant, c'est un précurseur requis pour d'autres formes normales.
Deuxième forme normale

 2NF :
 Une relation doit être en première forme normale et en plus:
 tous les attributs non clés dépendent de la clé OU
 la clé primaire est constituée d'un seul attribut
 Déf. attributs non clés = tous les attributs qui ne font pas partie de la clé
primaire.
 Déf. dépendant = les attributs qui apparaissent sur le côté droit d'une
dépendance fonctionnelle.
Deuxième forme normale (suite)

tous les attributs non clés dépendent de l'ensemble de la clé primaire, c'est-
à-dire aucune dépendance partielle.
 Cette forme s'applique vraiment aux tables avec des clés composés –
des clés composées de plusieurs attributs.
 Exemple : chambreAcoucher (Bâtiment, Chambre, Téléphone) Clé
composée.
Convertir une relation avec une
dépendance partielle en 2FN

1. Créer une nouvelle relation pour chaque attribut de la clé primaire(ou

combinaison d’attributs)qui est un déterminant dans la dépendance
partielle. Cet attribut sera la clé primaire de cette nouvelle relation,
2. Migrer les attributs non clé qui uniquement dépendent de l’attribut(ou
attributs) clé primaire de l’ancienne relation à la nouvelle relation
 Convertir une relation avec une
dépendance partielle en 2FN
Exemple:

Matière Date Intitulé Salle Capacité disponible

SQL101 3/1/2021 Fondement SQL 4A 12 4

BD202 3/1/2021 Conception BD 7B 14 7

SQL101 4/14/2021 Fondement SQL 7B 14 10

SQL101 5/28/2021 Fondement SQL 12A 8 8

CS200 4/15/2020 Programmation C 4A 12 11

 Convertir une relation avec une
dépendance partielle en 2FN
Exemple: Evènement
IDMatière Date Intitulé Salle Capacité disponible

SQL101 3/1/2021 Fondement SQL 4A 12 4

BD202 3/1/2021 Conception BD 7B 14 7

SQL101 4/14/2021 Fondement SQL 7B 14 10

SQL101 5/28/2021 Fondement SQL 12A 8 8

CS200 4/15/2020 Programmation C 4A 12 11

 Convertir une relation avec une
dépendance partielle en 2FN
Exemple: Evènement

Matière
IDMatière Date Salle Capacité disponible
IDMatière Intitulé SQL101 3/1/2021 4A 12 4
SQL101 Fondement SQL BD202 3/1/2021 7B 14 7
BD202 Conception BD SQL101 4/14/2021 7B 14 10
SQL101 Fondement SQL SQL101 5/28/2021 12A 8 8
SQL101 Fondement SQL CS200 4/15/2020 4A 12 11
CS200 Programmation C
Troisième forme normale

 3NF : une relation est en troisième forme normale si elle :

 est déjà en deuxième forme normale et
 ne contient aucune dépendance transitive. C’est-à-dire lorsqu’il n y a
aucun attribut non-clé qui dépend d’un autre attribut non-clé
 Déf. dépendance transitive = un attribut est fonctionnellement dépendant
d'un autre attribut non clé plutôt que de la clé primaire.
 Troisième forme normale: Exemple

VENTE

ID-Client Nom ChargéVente Région

8023 Salissou Issa Sud
9167 Iro Issoufou Ouest
7924 Hamsa Issa Sud
6837 Marou Soumana Est
7018 Amani Jimraou Nord
8596 Bawa Issoufou Ouest
ID-Client est la clé primaire .
Troisième forme normale: Exemple

 Conversion en 3NF
 VENTE(ID-Client, Nom, ChargéVente, Région )

 ChargéVente(ChargéVente, Région)

 VENTE(Client-ID, Nom, ChargéVente)

Décomposition des relations

 Considérons le schéma ci-dessous d’une relation

 Appart(idAppart, superficie, idImmeuble, nbEtages, dateConstruction)
 Deux dépendances fonctionnelles
 𝑖𝑑𝐴𝑝𝑝𝑎𝑟𝑡 → 𝑠𝑢perficie, 𝑖𝑑𝐼𝑚𝑚𝑒𝑢𝑏𝑙𝑒, 𝑛𝑏𝐸𝑡𝑎𝑔𝑒𝑠, 𝑑𝑎𝑡𝑒𝐶𝑜𝑛𝑠𝑡𝑟𝑢𝑐𝑡𝑖𝑜𝑛

 𝑖𝑑𝐼𝑚𝑚𝑒𝑢𝑏𝑙𝑒 → 𝑛𝑏𝐸𝑡𝑎𝑔𝑒𝑠, 𝑑𝑎𝑡𝑒𝐶𝑜𝑛𝑠𝑡𝑟𝑢𝑐𝑡𝑖𝑜𝑛

 Cette relation n’est pas normalisée car la seconde DF montre une dépendance dont la partie
gauche qui n’est pas la clé́, idAppart.
 Une idée naturelle est de prendre les dépendances fonctionnelles minimales et directes :
 𝑖𝑑𝐴𝑝𝑝𝑎𝑟𝑡 → s𝑢perficie, 𝑖𝑑𝐼𝑚𝑚𝑒𝑢𝑏𝑙𝑒
 et
 𝑖𝑑𝐼𝑚𝑚𝑒𝑢𝑏𝑙𝑒 → 𝑛𝑏𝐸𝑡𝑎𝑔𝑒𝑠, 𝑑𝑎𝑡𝑒𝐶𝑜𝑛𝑠𝑡𝑟𝑢𝑐𝑡𝑖𝑜𝑛
Décomposition des relations(suite)

 On peut alors créer une table pour chacune des deux dépendances fonctionnelles. On
obtient une décomposition en deux relations :
 APPART(idAppart, superficie, idImmeuble)
 IMMEUBLE(idImmeuble, nbEtages, dateConstruction)
Algorithme de normalisation par
décomposition

 On part d’un schéma de relation 𝑅, et on suppose donner l’ensemble des

dépendances fonctionnelles minimales et directes.
 On détermine alors les clés de 𝑅, et on applique la décomposition :
 — Pour chaque DF minimale et directe 𝑋 → 𝐴1,···𝐴𝑛 on crée une relation
(𝑋,𝐴1,···𝐴𝑛) de clé 𝑋
 — Pour chaque clé 𝐶 non représentée dans une des relations
précédentes, on crée une relation (𝐶) de clé 𝐶.
 On obtient un schéma de base de données normalisé et sans perte
d’information.
Développement de base de données
- Résumé des étapes

1. Créez un modèle conceptuel de données.

2. Transposer le modèle conceptuel en des relations normalisées
3. Implémentez les tables de la base de données dans un progiciel de
SGBD.
4. Définissez les associations entre les tables.
5. Définir les applications composantes (métadonnées) : formulaires,
requêtes, états, menus et/ou programmes d'application.