Vous êtes sur la page 1sur 223

UNIVERSITE DE BATNA

Faculté des Sciences de l’Ingénieur


Département d’Informatique

Bases de données
à l’usage de l’étudiant

Docteur Brahim BELATTAR

Doctorat Nouvelle thèse en informatique


Diplômé de l'Université Claude BERNARD de Lyon I-France
Maître de Conférence au Département d’Informatique
Faculté des Sciences de l’Ingénieur
Université de Batna

Année universitaire 2002/2003


Bases de données à l’usage de l’étudiant Sommaire 1

SOMMAIRE

Chapitre 1 : Généralités sur les bases de données


1. PROBLÈMES POSÉS PAR LES ORGANISATIONS CLASSIQUES 1
1.1 REDONDANCE DES INFORMATIONS 1
1.2 DÉPENDANCE ENTRE LES DONNÉES ET LES PROGRAMMES 1
2. BASES DE DONNÉES : NOTIONS GÉNÉRALES 3
2.1 DÉFINITION 3
2.2 OBJECTIFS D’UNE BASE DE DONNÉES 3
2.3 ROLE D’UNE BASE DE DONNEES 3
2.4 LA DÉMARCHE DE CONCEPTION D’UNE BASE DE DONNÉES 4
2.5 PROBLÈMES POSÉS PAR LA CENTRALISATION DE L’INFORMATION 5
3. SYSTÈMES DE GESTION DE BASES DE DONNÉES (SGBD) 7
3.1 DÉFINITION 7
3.2 FONCTIONS PRINCIPALES D’UN SGBD 7
3.3 LES DIFFÉRENTS TYPES D’UTILISATEURS D’UN SGBD 8
4. NIVEAUX DE DESCRIPTION D’UNE BASE DE DONNÉES 10
4.1 NIVEAU CONCEPTUEL 10
4.2 NIVEAU EXTERNE 13
4.3 NIVEAU INTERNE 13
5. LES EFFORTS DE STANDARDISATION DANS LE DOMAINE DES B.D. 13
5.1 LE GROUPE CODASYL 14
5.2 LE GROUPE ANSI 16
5.3 LE GROUPE GUIDE/SHARE 17
6. MISE EN ŒUVRE D’UN SGBD 17
6.1 LE LANGAGE DE DÉFINITION DE DONNÉES (DDL) 17
6.2 LE LANGAGE DE MANIPULATION DE DONNÉES (DML) 18
6.3 EXÉCUTION D’UN PROGRAMME D’APPLICATION PAR LE SGBD 18
7. APPROCHES DE DÉVELOPPEMENT D’UN SGBD RELATIONNEL 20
7.1 APPROCHE DESCENDANTE 20
7.2 APPROCHE ASCENDANTE 22
8. ARCHITECTURE DE QUELQUES SGBD RELATIONNELS 23
8.1 LE SYSTÈME SQL/DS (STRUCTURED QUERY LANGAGE/DATA SYSTEM) 23
8.2 LE SYSTÈME INGRES (INTERACTIVE GRAPHICS & RETRIEVAL SYSTEM) 24
8.3 LE SGBD ORACLE 25
9. CONCLUSION 26

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Bases de données à l’usage de l’étudiant Sommaire 2

Chapitre 2 : Les modèles de données réseau et hiérarchique


1. LE MODÈLE DE DONNÉES RÉSEAU GÉNÉRAL 27
1.1 CARACTÉRISTIQUES PRINCIPALES 27
1.2 DIAGRAMME DE STRUCTURE DE DONNÉES DE BACHMAN 28
2. LE MODÈLE DE DONNÉES RÉSEAU DE CODASYL 30
2.1 PRINCIPAUX CONCEPTS DU MODÈLE 30
2.2 DESCRIPTION D’UN SCHÉMA AVEC UN LDD DE TYPE CODASYL 36
2.3 NOTION DE SOUS SCHÉMA DANS LE MODÈLE RÉSEAU 47
2.4 LANGAGE DE MANIPULATION DE DONNÉES DANS UN MODÈLE RÉSEAU 48
3. LE MODÈLE HIÉRARCHIQUE 53
3.1 PRÉSENTATION GÉNÉRALE 53
3.2 CARACTÉRISTIQUES PRINCIPALES D’UN MODÈLE HIÉRARCHIQUE 53
3.3 LES LIENS N:M DANS UN MODÈLE HIÉRARCHIQUE 54
3.4 SCHÉMA CONCEPTUEL D’UNE BASE DE DONNÉES HIÉRARCHIQUE 56
3.5 DESCRIPTION D’UN SCHÉMA DANS LE CAS D’UN SGBD HIÉRARCHIQUE 56
3.6 IMPLANTATION PHYSIQUE D’UNE BASE DE DONNÉES HIÉRARCHIQUE 60
3.7 NOTION DE SOUS SCHÉMA DANS LE MODÈLE HIÉRARCHIQUE 63
3.8 LA MANIPULATION DE DONNÉES DANS UN MODÈLE HIÉRARCHIQUE 65
4. CONCLUSION 66
EXERCICES 67

Chapitre 3 : Le modèle relationnel

1. INTRODUCTION 74
2. OBJECTIFS VISÉS PAR LE MODÈLE RELATIONNEL 74
2.1 PROPOSER DES SCHÉMAS FACILES À UTILISER 74
2.2 AMÉLIORER L’INDÉPENDANCE LOGIQUE ET PHYSIQUE 74
2.3 METTRE À LA DISPOSITION DES UTILISATEURS DES LANGAGES DE
MANIPULATION DE HAUT NIVEAU 76
2.4 AMÉLIORER L’INTÉGRITÉ ET LA CONFIDENTIALITÉ 76
2.5 PRENDRE EN COMPTE UNE VARIÉTÉ D’UTILISATEURS 77
2.6 OFFRIR UNE APPROCHE MÉTHODOLOGIQUE POUR LA CONSTRUCTION DU
SCHÉMA CONCEPTUEL 77
3. DÉFINITIONS 78
3.1 ATTRIBUT 78
3.2 DOMAINE D’UN ATTRIBUT 78
3.3 PRODUIT CARTÉSIEN D’UN ENSEMBLE DE DOMAINES 79

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Bases de données à l’usage de l’étudiant Sommaire 3

3.4 RELATION 80
4. DÉMARCHE DE CONCEPTION D’UN SCHÉMA RELATIONNEL 84
4.1 PROBLÈMES POSÉS AU NIVEAU DE LA MODÉLISATION 84
4.2 L’APPROCHE DE MODÉLISATION PAR DÉCOMPOSITION 85
4.3 DÉFINITION D’UNE DÉCOMPOSITION 86
4.4 QUALITÉ D’UNE DÉCOMPOSITION 89
5. DÉPENDANCES FONCTIONNELLES 91
5.1 GÉNÉRALITÉS 91
5.2 DÉFINITION 91
5.3 PROPRIÉTÉS DES DÉPENDANCES FONCTIONNELLES 92
5.4 DÉPENDANCE FONCTIONNELLE ÉLÉMENTAIRE 93
5.5 DÉPENDANCE FONCTIONNELLE TRANSITIVE 94
5.6 DÉPENDANCE FONCTIONNELLE DIRECTE 94
5.7 DÉPENDANCE FONCTIONNELLE TOTALE, PLEINE OU COMPLÈTE 95
5.8 DÉPENDANCE FONCTIONNELLE TRIVIALE 95
5.9 REPRÉSENTATION GRAPHIQUE DES DÉPENDANCES FONCTIONNELLES 95
6. FERMETURE D’UN ENSEMBLE DE DÉPENDANCES FONCTIONNELLES 97
6.1 DÉFINITION 97
6.2 EQUIVALENCE ENTRE DEUX ENSEMBLES DE DÉPENDANCES FONCTIONNELLES 97
6.3 COUVERTURE MINIMALE D’UN ENSEMBLE DE DÉPENDANCES FONCTIONNELLES 97
6.4 FERMETURE D’UN ENSEMBLE D’ATTRIBUTS 98
7. DÉFINITION FORMELLE D’UNE CLÉ 100
7.1 ENONCÉ 100
7.2 DÉMARCHE DE RECHERCHE DES CLEFS CANDIDATES 100
8. FORMES NORMALES D’UNE RELATION 104
8.1 OBJECTIFS DE LA NORMALISATION 104
8.2 LES DEUX TENDANCES DE DÉFINITION DES FORMES NORMALES 105
8.3 LA PREMIÈRE FORME NORMALE (1FN) 105
8.4 LA DEUXIÈME FORME NORMALE (2FN) 107
8.5 LA TROISIÈME FORME NORMALE (3FN) 109
8.6 FORME NORMALE DE BOYCE ET CODD 111
8.7 AUTRES TYPES DE DÉFINITIONS DES FORMES NORMALES 112
9. LES MÉTHODES DE CONCEPTION D’UN SCHÉMA 113
9.1 PRÉSERVATION DES D.F. LORS D’UNE DÉCOMPOSITION 114
9.2 DÉCOMPOSITION BINAIRE D’UNE RELATION 114
9.3 DÉCOMPOSITION BINAIRE SANS PERTE D’INFORMATION 116
9.4 LES MÉTHODES AGRÉGATIVES 116
9.5 LES MÉTHODES PAR DÉCOMPOSITION 120
9.6 DÉCOMPOSITION SANS PERTE D’INFORMATION : ALGORITHME D’ULLMAN 122

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Bases de données à l’usage de l’étudiant Sommaire 4

10. DÉPENDANCES MULTIVALUÉES ET QUATRIÈME FORME NORMALE 126


10.1 LIMITES DES DÉPENDANCES FONCTIONNELLES 126
10.2 NOTION DE DÉPENDANCE MULTIVALUÉE 127
10.3 PROPRIÉTÉS DES DÉPENDANCES MULTIVALUÉES 129
10.4 QUATRIÈME FORME NORMALE (4 FN) 131
10.5 DÉCOMPOSITION SELON UNE DÉPENDANCE MULTIVALUÉE 131
11. DÉPENDANCE DE JOINTURE ET CINQUIÈME FORME NORMALE 132
11.1 INTÉRÊT DES DÉPENDANCES DE JOINTURES 132
11.2 DÉFINITION 135
11.3 REMARQUE 136
11.4 CINQUIÈME FORME NORMALE (5 FN) 136
12. NORMALISATION : ENTRE LA THÉORIE ET LA PRATIQUE 138
12.1 LES DÉPENDANCES FONCTIONNELLES SUR LE PLAN PRATIQUE 138
12.2 LE PROBLÈME DE L’INTÉGRITÉ RÉFÉRENTIELLE 139
12.3 LA DÉNORMALISATION DES RELATIONS 140
13. CONCLUSION 140
EXERCICES 141

Chapitre 4 : Introduction à l’algèbre relationnelle

1. LES LANGAGES DE MANIPULATION DE DONNÉES RELATIONNELLES 155


2. L’ALGÈBRE RELATIONNELLE 155
2.1 LES OPÉRATIONS DE BASE 155
2.1.1 Opérations binaires ensemblistes 156
2.1.1.1 L'union de deux relations 156
2.1.1.2 Remarques 156
2.1.1.3 Différence entre deux relations 157
2.1.1.4 Remarques 157
2.1.2 OPERATIONS UNAIRES SPECIFIQUES 158
2.1.2.2 LA SÉLECTION (APPELÉE AUSSI RESTRICTION) 159
2.1.2.3 Remarque 160
2.2 LES OPÉRATIONS COMPLÉMENTAIRES 160
2.2.1 LA JOINTURE 161
2.2.1.1 La JOINTURE selon une qualification 161
2.2.1.2 Remarques 162
2.2.1.3 JOINTURE Naturelle 162

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Bases de données à l’usage de l’étudiant Sommaire 5

2.2.1.4 Remarque 163


2.2.1.5 La Semi Jointure 163
2.2.1.6 Remarques 164
2.2.2 L'INTERSECTION ENTRE DEUX RELATIONS 164
2.2.3 QUOTIENT (DIVISION) 166
3. PROPRIÉTÉS DES OPÉRATEURS ALGÉBRIQUES 168
3.1 COMMUTATIVITÉ ET ASSOCIATIVITÉ DE LA JOINTURE ET DU PRODUIT
CARTÉSIEN 168
3.2 REMPLACEMENT D’UNE CASCADE DE PROJECTIONS 168
3.3 REMPLACEMENT D'UNE CASCADE DE SÉLECTIONS 168
3.4 COMMUTATION D'UNE SELECTION ET D'UNE PROJECTION 168
3.5 COMMUTATION D'UNE SELECTION ET D'UNE UNION 168
3.6 COMMUTATION D'UNE SELECTION ET D'UNE DIFFERENCE 168
3.7 COMMUTATION D'UNE SELECTION ET D'UN PRODUIT CARTESIEN 169
3.8 COMMUTATION D'UNE PROJECTION ET D'UN PRODUIT CARTESIEN 169
3.9 COMMUTATION D'UNE PROJECTION AVEC UNE UNION 169
3.10 REMARQUES 169
4. EXPRESSIONS DE L’ALGÈBRE RELATIONNELLE 170
5. CONCLUSION 171
EXERCICES 172

Chapitre 5 : Présentation générale de SQL


1. INTRODUCTION 181
2. REQUÊTE EN SQL 181
2.1 STRUCTURE D’UNE REQUÊTE 181
2.2 REMARQUE IMPORTANTE 182
3. EXPRESSION DE LA PROJECTION AVEC SQL 183
4. EXPRESSION DE LA SÉLECTION AVEC SQL 184
5. EXPRESSION DE L’UNION AVEC SQL 186
6. EXPRESSION DU PRODUIT CARTÉSIEN AVEC SQL 187
7. EXPRESSION DE L’INTERSECTION AVEC SQL 188
8. EXPRESSION DE LA DIFFÉRENCE AVEC SQL 188
9. EXPRESSION DES JOINTURES AVEC SQL 189
9.1 JOINTURE AVEC QUALIFICATION 189
9.2 JOINTURE NATURELLE 190
9.3 EQUI-JOINTURE 191
9.4 JOINTURE D’UNE RELATION AVEC ELLE MÊME (AUTO-JOINTURE) 191

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Bases de données à l’usage de l’étudiant Sommaire 6

10. UTILISATION DES SOUS-REQUÊTES 193


10.1 SOUS-REQUÊTE RETOURNANT UNE SEULE VALEUR 193
10.2 SOUS-REQUÊTE RETOURNANT UN ENSEMBLE DE VALEURS 194
10.3 SOUS-REQUÊTE RETOURNANT PLUSIEURS COLONNES 195
10.4 UTILISATION DES SOUS REQUÊTES DANS UNE JOINTURE 196
11. AUTRES POSSIBILITÉS D'INTERROGATION DE SQL 197
11.1 UTILISATION DU PRÉDICAT EXISTS 197
11.2 EXPRESSION DE LA DIFFÉRENCE AVEC EXISTS 197
11.3 EXPRESSION DE LA DIVISION AVEC EXISTS 198
12. LES FONCTIONS DE GROUPES 199
12.1 APERÇU GÉNÉRAL 199
12.2 MANIPULATION DE GROUPES : LA CLAUSE GROUP BY 200
12.3 TRI DU RÉSULTAT D’UNE REQUÊTE : LA CLAUSE ORDER BY 202
12.4 REQUÊTES IMPLIQUANT DES COLONNES CONTENANT NULL 203
13. LA DESCRIPTION DES DONNÉES AVEC SQL 205
13.1 CRÉATION DE TABLES : LA COMMANDE CREATE TABLE 205
13.2 EXTENSION D’UNE COLONNE: LA COMMANDE ALTER TABLE 205
13.3 AJOUT D’UNE NOUVELLE COLONNE : LA COMMANDE ALTER TABLE 206
13.4 SUPPRESSION D’UNE TABLE : DROP TABLE 206
13.5 REQUÊTES DE MISE A JOUR D'UNE TABLE 206
14. UTILISATION DES VUES ( VIEWS ) 208
14.1 CRÉATION D’UNE VUE : LA COMMANDE CREATE VIEW 208
14.2 INTERROGATION D’UNE VUE 209
15. CONCLUSION 210
EXERCICES 211

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Avant-propos

Avant-propos
Comme l’indique le titre, ce polycopié est destiné plus spécialement à l’étudiant qu’il soit de la filière
« Ingénieurs » ou « D.E.U.A. ». C’est l’aboutissement de plusieurs années d’enseignement du module
sur les bases de données que j’avais en charge. Le contenu que je présente ici a été mis à disposition
sur le Web dès 1998 sur un site personnel que j’avais créée et dont l’URL est :
http://www.chez.com/lisapub/.

Le domaines des bases de données étant vaste, je me suis limité aux seuls chapitres qui me semblent
indispensables à couvrir dans un polycopié comme celui-ci. Pour la présentation, j’ai adopté une
approche didactique en essayant de ne rien laisser dans le flou comme c’est le cas avec bon nombre
d’ouvrages sur le même thème.

Dans le premier chapitre, je présente des généralités sur les bases de données afin de mettre l’étudiant
dans le bain.

J’ai consacré le deuxième chapitre à la présentation des modèles de données réseau et hiérarchique qui
furent à l’origine de la première générations des systèmes de gestion de bases de données. Ce chapitre
me paraît incontournable du fait qu’il va permettre à l’étudiant de cerner les fondements de ces
modèles de données, la philosophie des SGBD qui les implémentent afin de pouvoir situer par la suite
les apports du modèle relationnel.

Le troisième chapitre traite du modèle relationnel. Partant du constat que la plupart des ouvrages que
j’avais eu à consulter pour préparer mes cours étaient d’une lecture difficile, floue voir ambiguë, j’ai
fait en sorte d’être le plus claire et le plus simple possible dans ma rédaction. De nombreux exemples
sont utilisés pour expliquer soit les définitions soit une mise en œuvre d’un algorithme.

Dans le quatrième chapitre, je présente les fondements de l’algèbre relationnelle avec beaucoup
d’exemples de mise en œuvre des opérations algébriques.

Enfin le cinquième chapitre a été réservé à l’introduction du langage SQL qui est a l'heure actuelle le
langage le plus utilisé dans le domaine des bases de données relationnelle. Il s’agit surtout d’expliquer
comment se fait la mise en œuvre des opérateurs de l’algèbre relationnel avec SQL. Bien que de
nombreux exemples sont fournis rien ne remplacerais l’apprentissage de ce langage par la pratique en
utilisant n’importe quel SGBD relationnel dont on peut disposer.

Une série d’exercices a été rajoutée à la fin de chaque chapitre(sauf le premier). Je n’ai pas jugé utile
d’insérer les corrigés dans le document car ça ne fait qu’augmenter les frais d’éditions. Et comme
aujourd’hui, il y a l’Internet, je les diffuserais sur mon site dès que l’édition du polycopié sera
effective.

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Remerciements

Remerciements

Il est de coutume pour un auteur de remercier les personnes qui auront contribué de près ou de loin à la
réalisation de son œuvre. Pour ma part, je tiens à remercier vivement mes amis et collègues qui m’ont
toujours encouragé à faire ce pas. Je citerais plus particulièrement :

- Mr Bilami Azzedine
- Mr Sedrati mâamar

Je tiens à exprimer toute ma reconnaissance et ma sympathie aux membres de la commission de


lecture qui ont accepté de donner leur avis sur ce document. La confiance totale dont ils m’ont fait
preuve m’a profondément touché. Il s’agit de :

- Mr Bilami Azzedine
- Mr Talhi Said
- Mr Merah El Kamel

Je ne saurais aussi oublier les étudiants des promotions 1995, 1996, 1997 , 1998 et 1999 qui avaient
suivi le module « Bases de données » avec moi et dont la participation active aux séances de travaux
dirigés m’a permis d’affiner le contenu du cours. Je citerais plus particulièrement :

- Melle Yahiaoui Itheri


- Melle Ferdi Wafa
- Mr Keddache Nabil
- Mr Bacha Hichem
- Mr Achoura Samir
- Melle Mellaoui Wahiba
- Mr Adouane Samir

Enfin, que celles ou ceux que j’ai pu oublier me pardonnent.

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 1: Généralités sur les bases de données •1

Chapitre 1 : Généralités sur les bases de données

1 Problèmes posés par les organisations classiques

L’approche classique de mise en place d’une application informatique dans une entreprise,
consistait le plus souvent à l’écriture d’un certain nombre de programmes destinés à l’exploitation
d’un ensemble de fichiers qu’il fallait aussi créer. Les principaux problèmes posés par cette démarche
sont : la redondance des informations et la dépendance entre les données et les programmes qui les
manipulent.

1.1 Redondance des informations

La création anarchique de fichiers ajoutée à l’absence de coordination entre les groupes de


développement entraîne une duplication non contrôlée des informations (préexistence de ces
informations dans d'autres fichiers propres à d'autres applications). Cette duplication engendre des
redondances c'est à dire qu'une même information peut se trouver dans plusieurs fichiers distincts. Par
exemple, l'identité d'un employé (nom, prénom, adresse, etc.) peut figurer dans un fichier F1 propre à
une application P1 calculant la paie, et dans un fichier F2 propre à une autre application P2 de gestion
des remboursements des frais médicaux. Une telle situation complique les opérations de mise à jour
car il est nécessaire pour une même information mise à jour dans un fichier de la mettre à jour dans
tous les fichiers où elle est supposée exister. (Ex : si on change l'adresse d’un employé dans le fichier
F1, il faut faire aussi ce changement dans tous les fichiers contenant cette information). Ceci devient
de plus en plus difficile dès que le nombre de fichiers est élevé et souvent on a tendance à retarder la
mise à jour dans les autres fichiers ce qui engendre une situation incohérente qui se traduit par le fait
que l'interrogation de la même information par deux utilisateurs différents chacun sur son propre
fichier fournira deux résultats différents.

1.2 Dépendance entre les données et les programmes

Généralement, la création de fichiers faite lors de la mise en place d'une application sous entend la
réalisation d’un certain nombre d’opérations telles que :

• La structuration des enregistrements : définir les champs, leurs types et leur ordre
• Le choix d'une organisation : séquentielle, séquentielle indexée, directe, etc.
• Le choix du support : disque dur, bande magnétique, etc.

Cette création était donc figée car faite en fonction d'un ou de plusieurs programmes. Ceci veut dire
que les données contenues dans les fichiers sont directement associées aux programmes qui les
exploitent et ceci par le biais d’une description contenue dans ces programmes eux-mêmes.

Exemple :

Si on a à mettre en place une application de gestion de prêts dans laquelle on suppose


qu'un emprunteur peut emprunter jusqu'à trois (3) ouvrages, on doit créer un fichier ayant
à peu près la structure suivante :

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 1: Généralités sur les bases de données •2

Nom Prénom Adresse Ouvrage 1 Ouvrage 2 Ouvrage 3

Figure 1.1 : Allure des enregistrements du fichier de l’application ‘‘gestion de prêt’’

Les programmes qui utilisent un tel fichier en donnent la description à l’intérieur du programme
même. Si on se réfère par exemple au langage COBOL, une telle description aurait l’allure suivante :

01 PRET
02 NOM PICTURE A(20)
02 PRENOM PICTURE A(20)
02 OUVRAGE OCCURS 3 TIMES
03 COTE_OUVRAGE 9(6)

Si ce fichier est utilisé par les programmes P1, P2, P3 (voir Figure 2) et si on doit le modifier pour
le besoin de P2 (prise en compte de l’âge de l’emprunteur par exemple !), il faudra modifier P1 et P3
en conséquence. Ceci est dû au fait que tous les programmes voient le fichier de la même façon bien
qu’ils n’aient pas tous besoin des mêmes informations. De même qu’un changement de l’organisation
du fichier sur disque pour le besoin d’un programme Pi (passer par exemple d’une organisation
séquentielle à une organisation directe afin d’optimiser les temps d’accès de Pi) obligera les autres
programmes à prendre en compte ce changement et en quelque sorte à suivre Pi même s’ils n’ont pas
vraiment besoin de ce type d’organisation. De même qu’une réorganisation des champs de
l’enregistrement (changement de l’ordre des champs à l’intérieur de l’enregistrement) entraînera une
modification dans les programmes et une reconstruction du fichier sur le support.

Programme 1 Crée un Emprunteur

FICHIER Programme 2 Gère les Prêts

Programme 3 Edition Retards

Figure 1.2 : Vue d’un même fichier par 3 programmes différents

On peut dire qu’il manque un moyen de filtrer les informations afin de ne retenir que celles qui
sont utiles à un programme donné. Ceci montre qu’il existe une dépendance étroite entre les données
et les programmes qui les manipulent qui se traduit par le fait qu’il n’est pas possible de changer la
structure et l’organisation des données sans modifier en conséquence les programmes.

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 1: Généralités sur les bases de données •3

2 Bases de données : Notions générales

2.1 Définition

Une base de données est un ensemble d’informations structurées permettant la mise en place d’une
série d’applications informatiques destinées à une grande variété d’utilisateurs.

Exemple:

Dans une entreprise, les informations concernant son fonctionnement :

- Employés
- Produits Fabriqués
- Moyens matériels (Machines, Véhicules, Magasins, etc.)

peuvent être rassemblées et mises à la disposition de nombreux utilisateurs (cadres de


l’entreprise, gestionnaires, opérateurs, etc.).

2.2 Objectifs d’une base de données

Parmi les principaux objectifs visés par une base de données, on peut citer :

2.2.1 Partage de l’information

Une base de données permet le partage d’un ensemble unique d’informations par plusieurs
utilisateurs. Cependant, il faut que cette mise en commun soit faite tout en préservant la vue
particulière que chaque utilisateur peut avoir des informations, et en s’assurant que la simultanéité des
traitements qui peuvent être effectués ne risque pas de dégrader l’intégrité de la base de données.

2.2.2 Organisation des données indépendamment des programmes

Afin de construire un ensemble d’informations structurées non redondant et qui soit partageable par
plusieurs utilisateurs, il est nécessaire de faire abstraction des traitements particuliers de tel ou tel
utilisateur (ou programme) pour tenter d’organiser les informations en fonction de leur nature et des
liens réels qui existent entre elles. C’est de cette manière qu’on arrivera à garantir le maximum
d’indépendance entre données et programmes.

2.3 Rôle d’une Base de données

Contrairement aux approches classiques, la création d’une base de données qui soit partagée par
plusieurs utilisateurs est le reflet d’une évolution dans la gestion de l’entreprise. Son rôle est de rendre
possible :

z La centralisation de l’information : l’information n’est plus éparpillée dans différents

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 1: Généralités sur les bases de données •4

fichiers à différents endroits)


z L’intégration (tout ce qui se fait dans un service est visible par d’autres services)
z La diffusion de l’information archivée (si l’information est disponible à un seul
endroit, elle est facile à diffuser)

Ceci a pour avantages :

„ d’améliorer la cohérence de l’information (une seule valeur pour une même


information)
„ de réduire les redondances (une même information n’est stockée si possible qu’une
seule fois)
„ de réduire les efforts de saisie et de mise à jour des informations (i.e. une information
qui doit être stockée une seule fois ne sera saisie qu’une seule fois. De même que sa
mise à jour ne se fera qu’une seule fois)

2.4 La démarche de conception d’une base de données

2.4.1 Principe général

Il est communément reconnu que la conception d’une base de données doit se faire en utilisant une
méthode de conception qui définit la démarche à suivre. Plusieurs méthodes de conception existent à
cet effet et nous citerons comme exemple la méthode MERISE. Pour certaines méthodes, on dispose
même d’un outil logiciel d’aide à la conception appelé aussi un Atelier de Génie Logiciel (AGL)
constitué d’un ensemble de logiciels permettant l’automatisation d’un certain nombre de tâches lors
des différentes phases du processus de conception (génération automatique de la structure de la B.D.,
de programmes d’accès et de manipulation, etc.).

Néanmoins, quelle que soit la méthode utilisée, la conception d’une base de données passe par un
processus de modélisation permettant de modéliser une certaine partie du monde réel afin de
caractériser les entités qu’on manipule (étudiants, Comptes Bancaires, Ouvrages, etc.). De plus on
essaye de caractériser les attributs de ces entités en fonctions des problèmes que doit résoudre
l’existence de la B.D. : Gestion de la scolarité, Gestion de Prêt d’ouvrages dans une bibliothèque, etc.

Le cas le plus général est celui où la B.D. est partagée par plusieurs utilisateurs. Ces utilisateurs
n’ont pas tous la même vue des données de la base, et n’ont pas tous à voir la base dans sa totalité car
chaque utilisateur n’est concerné que par une partie de celle-ci.

Exemple :

Dans une entreprise l’ensemble des informations sur les départements, les employés, les
produits, le matériel, etc. peuvent être rassemblées sous forme d’une B.D. et il est bien
rare qu’un utilisateur de cette base ait besoin de toutes ces informations à la fois.

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 1: Généralités sur les bases de données •5

Monde Réel

Modélisation

Description de la B.D.

Application A Application B Application C

Comptabilité Paye
Gestion de Stock
Ventes
S.Sociale Achats

3 Programmes d’applications 2 Programmes d’applications 1 Programme d’application

Figure 1.3 : Processus de Modélisation d’une B.D.

2.4.2 Remarque

Il serait plus juste de remplacer le terme Utilisateur par celui d’Application car on définit en
général une B.D. afin de mettre en place une série d’applications ayant chacune ses programmes et ses
propres utilisateurs exploitant le même sous-ensemble de données.

Exemple :

Dans une B.D. de Gestion Universitaire, on peut mettre en place une application de
gestion de Prêts qui sera composée des programmes P1, P2 et P3 (voire Figure 2) et dont
les utilisateurs seront ceux concernés par les traitements réalisés par ces programmes
(Secrétaire, Documentaliste, Archiviste, etc.).

2.5 Problèmes posés par la Centralisation de l’information sous forme de B.D.

Dans la pratique, la centralisation de l’information sous forme d’une B.D. unique pose un certain
nombre de problèmes liés directement à l’intégrité et à la sécurité de ces informations. Parmi ces
problèmes, on peut énumérer les suivants :

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 1: Généralités sur les bases de données •6

2.5.1 Nature et type de l’information

Lors de la mise en place d’une B.D., l’utilisateur décrit les propriétés que doivent vérifier ses
données. Ces propriétés peuvent se situer à différents niveaux :

; Appartenance d’une donnée à un ensemble de valeurs (Ex : l’âge d’un employé est un
entier positif compris entre 0 et 150 0< âge < 150)

; Déclaration de propriétés invariantes au cours du temps (Ex : Un enseignant à une


heure Donnée ne peut se trouver que dans une seule salle).

; Relation d’ordre total à respecter lors du stockage des données (Ex : Les employés
doivent être stockés dans la B.D. par ordre croissant de leur numéro ou par ordre
alphabétique sur leur nom)

Toutes ces propriétés doivent être préservées tout au long de l’existence de la base de données.

2.5.2 Sûreté physique, sûreté de fonctionnement et point de reprise

Il s’agit de protéger l’information contre un mauvais fonctionnement soit de la machine, soit du


système qui géré la base de données.

Dans le premier cas, on peut délimiter les enregistrements qui ont été altérés ou perturbés alors que
dans le second cas le problème est beaucoup plus complexe. Une des solutions en usage consiste à
prendre à intervalles réguliers des copies de la B.D. et à enregistrer l’ensemble des transactions
(opérations) effectuées sur la base. Ceci permettra en cas d’incident de régénérer une copie consistante
(i.e. sans défauts) de la base.

2.5.3 Partage de l’information

Lorsque deux programmes P1 et P2 veulent se partager la même donnée A, il peut y avoir perte
d’intégrité.

Exemple :

P1 accède à A et la transfère dans son buffer propre


P2 accède à A et la transfère dans son buffer propre
P1 modifie A dans son buffer puis la recopie dans la B.D.
P2 modifie A dans son buffer puis la recopie dans la B.D. venant ainsi
écraser les modifications faites par P1.

La solution à ce problème serait par exemple celle de l’exclusion mutuelle qui est une technique
utilisée dans les systèmes d’exploitation.

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 1: Généralités sur les bases de données •7

2.5.4 Problème des données confidentielles

Il s’agit de protéger les données contre des utilisateurs indiscrets. On dispose en général pour cela
de procédures sélectionnant les accès à la base de données. Lorsqu’un utilisateur veut faire un accès,
on distingue deux phases :

- La phase d’identification : qui a pour but d’identifier l’utilisateur qui veut se


connecter à la base de données. Ceci est possible grâce à un mot de passe, une carte
spéciale, etc.

- La phase d’autorisation : qui après identification de l’utilisateur, permet de


déterminer ce que peut faire cet utilisateur sur tel ou telle données (consulter
seulement, consulter et mettre à jour, etc.)

3 Systèmes de gestion de bases de données (SGBD)

L’exploitation d’une base de données nécessité la mise en place d’un système informatique appelé
communément : système de gestion de base de données

3.1 Définition

Un SGBD peut être vu comme un système informatique (un logiciel) spécialisé dans le traitement
de gros volumes d’informations et permettant à différents utilisateurs d’interagir avec la base de
données.

Un SGBD doit permettre de définir la structure de la base et d’y introduire les données
correspondantes. De plus, une fois la base créée, il faudra d’une part la mettre à jour et d’autre part
l’exploiter ou l’interroger.

3.2 Fonctions principales d’un SGBD

Un SGBD possède 3 fonctions principales :

1- Fonction Description
2- Fonction Manipulation
3- Fonction Utilisation

3.2.1 Description des données

La modélisation conduit à la définition des entités qui vont constituer les données de la base, de
préciser leurs caractéristiques ainsi que les liaisons qui existent entre elles.

Ceci se fait grâce à un langage de description de données ou LDD (Data Definition Langage ou
DDL en anglais) offert par le SGBD. Le but essentiel de ces langages est de fournir une indépendance
totale des données vis à vis des supports où elles seront stockées (on peut comparer la DATA

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 1: Généralités sur les bases de données •8

DIVISION d’un programme COBOL à la description de la base)

3.2.2 Manipulation des données

Lorsque la structure de la base est décrite, il faut pouvoir stocker les informations correspondantes.
Ceci implique nécessairement un certain nombre de mécanismes pour construire des enregistrements
correctement structurés et qu’il faut ensuite écrire sur un support physique (mémoire secondaire). De
plus, il faudra pouvoir accéder à de tels enregistrements pour tous les problèmes de mise à jour et
d’interrogation.

Pour ce faire, le SGBD fournit un langage de manipulation de données ou LMD (Data


Manipulation Language en anglais). Ce langage est en général construit autour de quelques primitives
d’accès et de manipulation (Get, Retrieve, Update, etc.).

3.2.3 Utilisation des données

A ce niveau, on désire par exemple interroger la base de données, c’est à dire rechercher parmi
l’ensemble des entités stockées celles qui répondent à des critères de choix très divers. C’est une
fonction qui définit directement le lien entre l’utilisateur et les données au sein d’une application.

Utilisation Manipulation

Description
Utilisateurs

B.D.

Figure 1.4 : Agencement des fonctions d’un SGBD

A ce niveau, il faut préciser que la mise en place et l’exploitation d’une base de données fait appel
à une panoplie d’individus appelés ‘‘Utilisateurs’’ ayant chacun un rôle à jouer dans ce processus. Il
est donc important de bien définir les différents types d’utilisateurs d’un SGBD et de préciser les rôles
de chacun.

3.3 Les différents types d’utilisateurs d’un SGBD

Il s’agit donc de voir les différents rôles que doivent jouer un individu ou un groupe d’individus
pour concevoir, créer, mettre en œuvre et exploiter une base de données.

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 1: Généralités sur les bases de données •9

3.3.1 L’administrateur de la base de données

On désigne ainsi la ou les personnes chargées d’établir une description des données constituant la
base. Elles sont chargées de décrire les entités de la base de données et indiquer les liaisons existant
entre ces entités, ceci au moyen du DDL offert par le SGBD.

Ce travail est l’aboutissement d’une phase d’analyse de l’environnement réel (Entreprise, etc.). Le
choix de la structure est primordial pour l’avenir de la base de données car une fois fixée et une fois la
base créée, il est très difficile pour ne pas dire impossible dans de nombreux SGBD, de modifier cette
structure.

Souvent, on utilise le terme ‘‘ Administrateur de l’entreprise’’ pour désigner les personnes


chargées de la description formelle des données de la base pour souligner l’ouverture vers le monde
réel de ce rôle, et on réserve le terme ‘‘Administrateur de la base’’ pour désigner les personnes
chargées de l’aspect plus technique de la création de la base : choix de l’organisation des fichiers, des
structures de mémoires secondaires, des méthodes d’accès aux données, etc.

3.3.2 L’administrateur d’application

Il est chargé de décrire la portion de la base de données concernée par une application particulière.
En effet, dans la pratique chaque application n’est concernée que par une portion plus ou moins
importante des données de la base. Cette description sera utilisée par les programmes qui vont
constituer l’application en question. Ces derniers ne verront donc la base de données que par cette
description.

Là aussi, l’administrateur d’application utilise le DDL offert par le SGBD pour décrire la portion
de la base de données qui concerne une application donnée (appelée sous schéma ou vue).

3.3.3 Le programmeur d’application

Il est chargé d’élaborer les programmes pour exploiter la base de données en fonction de la
description qui a été faite par l’administrateur d’application. Le programmeur d’application utilise le
LMD offert par le SGBD ainsi que d’autres sous-programmes conservés généralement dans une
librairie (i.e. bibliothèque de sous-programmes).

3.3.4 L’utilisateur

Il s’agit de caractériser ici la personne qui se sert simplement de la base de données et qu’on
appelle couramment l’utilisateur final (End User en anglais).

Exemple :

Dans une agence de réservation de billets d’avion, la personne qui tape sur son terminal
quelques commandes pour effectuer une réservation est une utilisatrice au même titre
qu’un chef d’entreprise qui lui aussi demande de temps en temps à une base de données
de son entreprise un certains nombre d’informations reflétant l’état de son entreprise
(produits non vendus, commandes en attente, etc.).

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 1: Généralités sur les bases de données • 10

Ce sont là deux exemples typiques d’un utilisateur final d’une base de données (End User). Leur
point commun est qu’ils ne sont pas informaticiens. C’est donc pour cette catégorie là que
l’administrateur et le programmeur d’application ont conçu et réalisé des programmes qu’ils n’ont plus
qu’à activer au moyen d’un langage de commandes qui devrait être le plus naturel possible.

4 Niveaux de description d’une Base de Données

La description d’une base de données peut se faire à différents niveaux, suivant que l’on regarde
plus du côté de l’utilisateur que du côté du stockage des données sur les supports physiques. On
distingue communément trois (3) niveaux de description d’une B.D. :

1- niveau conceptuel
2- niveau externe
3- niveau interne

Monde Réel

Groupe
Utilisateurs 1 Schéma Externe 1

Groupe
Utilisateurs 2 Schéma Externe 2 Schéma Schéma
Conceptuel Physique

Groupe
Utilisateurs 3 Schéma Externe 3

B.D.
Physique

Niveau Externe Niveau Conceptuel Niveau Interne

Figure 1.5 : Les niveaux de description d’une base de données

4.1 Niveau conceptuel

Le schéma conceptuel est la partie fondamentale dans l’architecture d’une base de données. Il a
pour but de décrire en termes abstraits mais fidèles une certaine réalité d’une organisation et de ses
processus de gestion qui ont nécessité la mise en place d’une B.D.

Le passage du monde réel au schéma conceptuel correspond à un processus de modélisation où les


objets du monde réel ayant les mêmes caractéristiques sont classés en catégories et désignés par des
noms (Etudiants, Véhicules, etc.). Le SGBD fournit un langage de description qui permet de spécifier

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 1: Généralités sur les bases de données • 11

le schéma conceptuel.

Dans le processus de modélisation, le concepteur de la B.D. spécifie le schéma conceptuel en


utilisant les possibilités offertes par un modèle de données.

4.1.1 Définition d’un modèle de données

Un modèle de données est un outil formel destiné à décrire la réalité de manière indépendante de
tout traitement informatique.

Un modèle de données doit permettre de regrouper les objets du monde réel auxquels on s’intéresse
en classes d’objets de nature identique.

Exemple :

Dans une application de gestion universitaire, on pourra regrouper les étudiants dans une
classe d’objets qu’on appellera ETUDIANTS et les modules dans une autre classe
d’objets qu’on appellera MODULES. Par la suite on ne fera référence aux objets de ces
classes que par l’intermédiaire de ces noms.

Un modèle de données doit aussi permettre de décrire les liaisons ou associations qui peuvent
exister entre les classes d’objets.

Exemple :

Dans une application de gestion universitaire, l’inscription est un phénomène qui associe
un objet étudiant appartenant à la classe ETUDIANTS à un ou plusieurs objets modules
appartenant à la classe MODULES. On pourra dans ce cas créer une association qu’on
nommera INSCRIPTION entre la classe ETUDIANTS et la classe MODULES afin de
modéliser cette réalité.

4.1.2 Classification des modèles

Un schéma conceptuel est donc le résultat d’un processus de modélisation fait en respectant les
possibilités d’un modèle de données. Le modèle de données est une caractéristique de tout SGBD. Il
existe trois grandes classes de modèles de données qui se distinguent par la nature des associations
qu’ils permettent de modéliser. Ce sont :

„ Les modèles hiérarchiques


„ Les modèles réseaux
„ Les modèles relationnels

4.1.2.1 Le modèle hiérarchique

A l’aide du modèle hiérarchique, le schéma conceptuel peut être vu comme un graphe arborescent
dont les nœuds correspondent aux classes d’objets (entités) et les arcs entre deux nœuds aux liaisons
ou associations entre les entités. Un tel graphe possède donc un nœud racine (sur lequel n’arrive
aucun arc !) et les autres nœuds sont des fils, petit-fils, etc., de cette racine. Avec le modèle
hiérarchique, le nombre de flèches pouvant arriver sur un nœud est donc égal à un (sauf pour le nœud
racine).

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 1: Généralités sur les bases de données • 12

ETUDIANTS

PRET_ETUDIANT
INSCRIPTIONS

MODULES OUVRAGES

Figure 1.6 : Un exemple de modèle hiérarchique

4.1.2.2 Les modèles réseaux

A l’aide de ce modèle, le schéma conceptuel peut être vu comme un graphe général où les nœuds
correspondent aux classes d’objets et les arcs entre deux nœuds aux associations. A la différence du
modèle hiérarchique on peut avoir ici plusieurs arcs qui arrivent sur le même nœud. De même que la
notion de nœud racine n’existe pas avec le modèle réseau.

ETUDIANTS ENSEIGNANTS
ENSEIGNE

INSCRIPTIONS PRET_ENSEIGNANTS

PRET_ETUDIANT
MODULES
OUVRAGES

Figure 1.7 : Un exemple de modèle Réseau

4.1.2.3 Le modèle relationnel

Ce modèle est fondé sur la théorie mathématiques des relations. Le schéma conceptuel peut être vu
comme un ensemble de tables (ou relations) à n colonnes, n désignant le degré de la relation. Avec le
modèle relationnel, une table sert à représenter aussi bien une classes d’objets qu’une association entre
des classes d’objets. Ainsi, la distinction entre nœud et arc comme dans les autres modèles n’est pas
nécessaire avec le modèle relationnel. Chaque élément d’une table est appelé un n-uplet. Par exemple
la table INSCRIPTION décrit l’association entre la classe d’objets ETUDIANTS et la classe
MODULES et qui permet de modéliser le fait qu’un étudiant peut s’inscrire à 0, 1 ou plusieurs
modules.

Num Nom Prenom Code Titre Num Code Note

ETUDIANTS MODULES INSCRIPTIONS

Figure 1.8 : Un exemple de modèle Relationnel

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 1: Généralités sur les bases de données • 13

4.2 Niveau externe

Ce niveau correspond à la vision de tout ou partie du schéma conceptuel par un groupe


d’utilisateurs concerné par une application. Il s’agit de décrire à l’aide d’un schéma externe ou Vue la
façon dont seront perçues les données par un programme d’application.

Exemple :

Dans une base de données de gestion universitaire, un groupe d’utilisateurs concerné par
les INSCRIPTIONS des étudiants n’a pas besoin d’avoir une vision globale de la base et
peut se limiter à la partie qui englobe les informations relatives aux étudiants et aux
Modules.

Un schéma externe peut être considéré comme un sous schéma du schéma conceptuel. Grâce à cette
notion de schéma externe, chaque groupe d’utilisateurs perçoit les données à sa façon Par exemple,
une donnée vue comme donnée numérique par un groupe peut être vue comme une chaîne de
caractères par un autre (cas d’une date par exemple). Un groupe peut ne pas voir certaines
caractéristiques (attributs) d’une entité (ex : note obtenue dans un module) qui seront par contre
visibles par un autre groupe (ou application).

4.3 Niveau interne

Ce niveau a pour but de spécifier comment les données sont stockées sur les supports physiques.
Cette spécification est faite par le biais d’un schéma physique ou schéma de stockage. Ce schéma
permettra par exemple de :

• Décrire la structure des fichiers qui constituent la base de données (nom d’un fichier,
organisation, adresse sur le support, etc.)
• Définir les méthodes d’implantation (fichier plat, inversé, etc.)
• Préciser les chemins d’accès aux enregistrements (index, chaînage, calcul d’adresse,
etc.)

Cependant, il faut noter que tous ces aspects ne doivent pas affecter les applications sauf sur le plan
des performances d’accès à la base afin de garantir l’un des objectifs visés par une base de données à
savoir : l’indépendance entre les données et les programmes. Le souci du schéma physique est donc de
pouvoir changer l’organisation physique des données sans modifier le schéma conceptuel ni les
programmes d’application. Par exemple, pour augmenter les performances d’accès à la base de
données, on peut être amené à :

• Changer l’organisation d’un fichier (Passer par exemple d’une organisation


initialement séquentielle à une organisation séquentielle indexée ou directe).
• Déplacer physiquement le fichier vers une autre adresse sur le support
• Modifier les chemins d’accès aux enregistrements (changer d’index, ajouter d’autres
indexes, etc.).

5 Les efforts de standardisation dans le domaine des B.D.

Historiquement, les efforts de développement des SGBD avaient donné naissance à toute une
gamme de notions nouvelles qui variaient d’un système à un autre. Plusieurs groupes d’usagers

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 1: Généralités sur les bases de données • 14

avaient alors ressenti très tôt le besoin de préciser les principales caractéristiques concernant la
terminologie, la syntaxe, la sémantique ainsi que les structures logiques des langages DDL et DML
qui devaient être offerts par un SGBD. Ces groupes composés d’usagers d’un même secteur industriel
ou de clients d’un même fabricant d’ordinateurs avaient influencé directement ou indirectement les
efforts de standardisation et de développement des SGBD. Parmi ces groupes, les plus distingués sont
:

• CODASYL ( COnference on DAta SYstems Language)


• ANSI (American National Standard Institute)
• GUIDE/SHARE (groupe d’usagers IBM)

5.1 Le groupe CODASYL

Ce groupe a profondément influencé le développement des logiciels SGBD. Il a été formé en 1959
aux USA lors d’une réunion des représentants d’environ quarante (40) organisations comportant des
fabricants d’ordinateurs(IBM), des agences gouvernementales, et des usagers importants du matériel
informatiques(grandes compagnies).

Ce groupe avait pour mandat de Concevoir et développer des techniques et des langages pour
aider au développement des systèmes informatiques. Le premier projet du groupe fût de développer
les spécifications d’un langage de programmation adapté aux traitements de gestion. Ce fût la
naissance du langage COBOL (COmmon Business Oriented Language).

A partir de 1966, le groupe se pencha sur les possibilités d’inclure dans COBOL la syntaxe
nécessaire pour exploiter les bases de données. Vers 1968, un rapport intitulé ‘‘COBOL Extension To
Handle Data Bases’’ fût publié par le groupe.

A partir de 1969, la structure organisationnel de CODASYL fût modifiée et trois comités furent
crées :

• PLC (Programming Language Committee) dont le mandat était de développer des


spécifications pour les langages de programmation.

• SC (Systems Committee) dont le mandat était de développer des langages et des


systèmes de très haut niveau pour aider à la conception des systèmes informatiques.

• PC (Planning Committee) dont le mandat était d’informer les usagers sur les objectifs
poursuivis et les résultats obtenus. Il fût dissout vers 1973.

Le comité SC publia deux documents dans lesquels sont rapportés les résultats de ses travaux dans
le domaine des bases de données. Les intitulés de ces documents sont :

- ‘‘A Survey of Generalized Database Management Systems ’’ (1969)


- ‘‘A Feature Analysis of Generalized Database Management Systems ’’ (1971)

Le comité PLC créa un sous-groupe appelé DBTG (Data Base Task Group) ayant pour mission
spécifique d’étudier de très près les questions relatives aux bases de données. Le DBTG publia deux
rapports importants sur les résultats de ses travaux dans la revue ACM (Association of Computer
Machinery). Ce sont :

- ‘‘Data Base Task Group, October 1969 Report, ACM’’. Dans ce rapport, le groupe
avait proposé un DDL et un DML formulés comme une extension au langage

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 1: Généralités sur les bases de données • 15

COBOL.

- ‘‘Data Base Task Group, April 1971 Report, ACM’’ . Suite aux critiques et suggestions
reçues sur le premier rapport, le groupe avait publié ce deuxième rapport afin
d’exposer toutes les modifications qui ont été apportés au langage.

5.1.1 Propositions de CODASYL

Les comités de CODASYL (surtout le DBTG) avaient fait les propositions suivantes :

a. La définition de la structure logique de l’ensemble des données (base de données) est faite au
moyen d’un schéma (schéma conceptuel) et les vues des applications par autant de sous-
schémas que d’applications (schéma externe).

b. Un DDL est spécifié pour la description du schéma et des sous-schémas.

c. La structure logique des données est définie en termes de :

• Donnée élémentaire ou atome (field) : c’est la plus petite unité d’information possédant
un nom
• Agrégat : suite consécutive de données élémentaires ayant les mêmes caractéristiques ou
une collection de données apparaissant plusieurs fois consécutivement

• Enregistrement : collection d’agrégats et d’atomes rangés consécutivement constituant


l’unité d’échange entre la base de données et les applications.

• SETS : Association entre un enregistrement père (propriétaire ou Owner) et un


enregistrement fils (Membre ou Member).

• AREA : Un espace physique sur le support qui possède un nom. La base de données sera
constituée d’une ou de plusieurs AREA (un ensemble de pages), chacune pouvant
recevoir un ensemble d’enregistrements.

Ces propositions ont été beaucoup influencé par le langage COBOL. L’exemple suivant permet de
préciser les notions utilisées :

01 EMPLOYE
02 NOM PIC X(20) Atome
02 PRENOM PIC X(20) Atome
02 ENFANTS OCCURS 5 TIMES
03 PRENOM PIC X(20) Agrégat
03 AGE PIC 99 répétitif
02 ADRESSE
03 NUMERO PIC 9(4) Agrégat
03 RUE PIC X(30) vecteur
03 VILLE PIC A(20)

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 1: Généralités sur les bases de données • 16

5.1.2 Architecture du SGBD CODASYL

Le DBTG avait proposé une architecture d’un SGBD dont le principe de fonctionnement est le
suivant :

Programme d’application 1 Programme d’application 2

Zone de Sous- Zone de Sous-


Travail Schéma Travail Schéma

T
A Schéma de la BD
SGBD M
P
O
N
S Schéma de stockage
Syst. d’exploitation (SGF)

B.D.

Figure 1.9 : Architecture du SGBD CODASYL

5.2 Le groupe ANSI

Organisme officiel chargé de l’élaboration des normes industrielles aux Etats-Unis. Il créa en 1973
un comité ANSI/X3/SPARC chargé d’étudier les SGBD et les possibilités de normalisation. Ce comité
proposa un certain nombre de nouvelles notions qu’il définit ainsi :

1- Administrateur d’entreprise : a une vue d’ensemble des opérations de l’entreprise et


de la sémantique des données. Il a la responsabilité globale du contenu et de l’usage de
la base de données.

2- Administrateur de la base : a la responsabilité de l’organisation, de la représentation


et de l’intégrité de la base de données physique.

3- Administrateur d’application : a la responsabilité de l’exploitation d’une ou de


plusieurs applications connexes.

Le comité propose aussi les notions de schéma conceptuel, de schéma externe et de schéma interne.
Il propose également un ensemble d’interfaces de type logiciel qui permettent de modifier, consulter,
copier et extraire des renseignements du schéma conceptuel et des schémas externes.

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 1: Généralités sur les bases de données • 17

5.3 Le groupe GUIDE/SHARE

Composé d’un nombre important d’usagers du matériel IBM. GUIDE représente les usagers de
type commercial (entreprises), et SHARE représente les usagers de type scientifique (universités,
centres de recherches, etc.).

Le groupe publia en 1971 un rapport s’intitulant : ‘‘ The Joint GUIDE/SHARE database


Requirment group report’’ et dans lequel il avait exposé ses idées sur les approches de
développement des SGBD. Il avait aussi initié plusieurs projets de recherches dans le domaine des
bases de données. Parmi les thèmes les plus importants qui avaient été traités dans ces projets, on peut
citer : l’administration de la base de données et les méthodologies de conception d’une base de
données.

6 Mise en œuvre d’un SGBD

La conception, la réalisation et l’utilisation d’un SGBD nécessitent les efforts de nombreuses


personnes. Cependant, d’un point de vue externe, les choses peuvent être décrites simplement.

Exemple :

un étudiant qui désire s’inscrire se présente à la scolarité. L’employé chargé d’assurer


les inscriptions est en général non informaticien et a à sa disposition un terminal lui
permettant de communiquer avec la base de données. Il a aussi à sa disposition un
ensemble de commandes qu’il doit taper pour afficher les modules en retard, les modules
auxquels l’étudiant peut s’inscrire, etc.

Ainsi, le dialogue entre l’employé et le SGBD paraît simple. Cependant, cette simplicité apparente
n’a été rendu possible que grâce au concours de beaucoup d’éléments du SGBD qu’il faudra préciser.

6.1 Le langage de définition de données (DDL)

La première tâche à réaliser est de construire le schéma conceptuel de la B.D. qu’on veut mettre en
place. Il est spécifié grâce à un LDD. Ce LDD est propre à chaque SGBD et dépend du type de modèle
de données supporté par le SGBD.

Un LDD est un langage descriptif permettant de décrire et de nommer d’une part les classes
d’objets que l’utilisateur perçoit dans son application, et d’autre part les associations qui existent entre
ces classes d’objets.

Il permet également la description des contraintes d’intégrité, les droits d’accès aux données et les
chemins d’accès (indexes, clés, hachage, etc.). Il est utilisé lors de la définition du schéma conceptuel,
et aussi pour la définition des différents schémas externes et lorsqu’on veut effectuer certaines
modifications du schéma conceptuel.

Dans l’hypothèse ou le schéma externe ferait référence à un modèle de données autre que celui
utilisé dans le schéma conceptuel, il serait effectivement nécessaire d’avoir un LDD adapté à ce
schéma externe. Dans les SGBD actuellement commercialisés, cette possibilité n’existe pas bien
qu’elle puisse probablement devenir une réalité future.

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 1: Généralités sur les bases de données • 18

6.2 Le langage de manipulation de données (DML)

Une fois les différents schémas définis, il faut pouvoir créer, mettre à jour, interroger et effectuer
toute manipulation que l’on souhaite sur la B.D. On dispose pour cela d’un LMD pour écrire les
programmes d’applications. Un LMD a toutes les caractéristiques d’un langage de programmation :
schémas conditionnels, schémas itératifs, affectation, etc. Toutefois, il comporte des instructions
spécifiques qui lui permettent de référencer les données que l’on souhaite manipuler, et d’exprimer le
type de manipulation à effectuer : insertion, mise à jour, suppression, recherche et interrogation.

Dans de nombreux SGBD, ces instructions sont invoquées à partir d’un langage de programmation
classique(COBOL, FORTRAN, PL1, etc.) au moyen d’un ordre de type CALL faisant appel à une
routine du SGBD qui réalise la fonction supportée par cette instruction. On dit alors que ces langages
de programmation sont des langages hôtes.

Par contre, dans certains SGBD, le LMD est entièrement indépendant des langages de
programmation et possède sa propre syntaxe. On parle dans ce cas de langage de manipulation de
données autonomes. De même que certains SGBD permettent aussi bien l’utilisation du LMD sous
forme de langage autonome qu’à partir d’un langage hôte (ex : SQL ).

6.3 Exécution d’un programme d’application par le SGBD

Un programme d’application est écrit à partir des connaissances qu’on a sur la base de données,
c’est à dire au travers d’un schéma externe puisque l’application ne voit la B.D. qu’à travers un
schéma externe. Le SGBD devra interpréter les instructions exprimées en terme du schéma externe,
pour les convertir en termes du schéma conceptuel, puis en ordres sur la base de données physique.

Programme Niveau Niveau Niveau


d’application Externe Conceptuel Physique

B.D.
Utilisateur
Flots des données

Flots des ordres

Figure 1.10 : Cheminement des données et des requêtes dans un SGBD

L’architecture d’un SGBD a pour but d’assurer la circulation du flot des ordres et du flot des
données. Cette architecture est très diverse selon les différents SGBD (CODASYL ou ANSI).
Néanmoins, l’essentiel demeure identique et permet de préciser approximativement le principe de
fonctionnement d’un SGBD (Figure 11).

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 1: Généralités sur les bases de données • 19

Tampons du
Programme Programme
d’application
11 d’application
Schéma Schéma Schéma
Externe 1 Externe 2 Externe 3
9
10

8 1
Tampons du
2 Schéma de la B.D.
SGBD
SGBD ou Conceptuel
3
7
5
Schéma de stockage
4 ou Physique
6
B.D.
Syst. d’exploitation (SGF)

Flot des données

Informations provenant des schémas

Flot des ordres

Figure 1.11 : Exécution d’un programme par un SGBD

Cette architecture fait apparaître les éléments principaux suivants :

• Le noyau du SGBD : logiciel qui assure le bon fonctionnement de la base de données

• Le système d’exploitation : logiciel qui assure le fonctionnement de la machine et sur


lequel le SGBD a été construit

• Les différents schémas : externes, conceptuel, physique qui sont stockés sous formes de
catalogues internes obtenus à partir des descriptions fournies au système grâce au
LDD.

6.3.1 étapes de fonctionnement du SGBD (cas d’une lecture de données)

1. La demande de lecture est envoyée par le programme d’application au SGBD (ce qui
correspond à la flèche N° 1 sur la figure précédente)

2. La demande est analysée par le SGBD en utilisant le schéma externe propre à cette
application. Ceci lui permet de vérifier d’une part que l’application a le droit d’accéder
aux données et d’autre part pour extraire et transmettre les caractéristiques de la
données à partir de ce schéma.

3. Le SGBD consulte le schéma conceptuel pour déduire le type logique de données à


extraire (Table, enregistrement, segment, etc.)

4. Le SGBD consulte le schéma physique pour déduire l’enregistrement physique à lire


(Page, Secteur, etc.)

5. Le SGBD transmet à cet effet un ordre de lecture au système d’exploitation (accès à des

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 1: Généralités sur les bases de données • 20

pages, blocs, secteurs, etc.)

6. Le système d’exploitation reçoit l’ordre de lecture et l’analyse en consultant certains


paramètres du schéma physique puis lance un ordre de lecture au canal ou contrôleur de
l’unité périphérique (lire des enregistrements physiques en ignorant le contenu).

7. Les données recherchées sont transmises dans une zone de mémoire qui constitue le
tampon du SGBD (tables, enregistrements ou articles, etc.)

8. Le SGBD sélectionne parmi l’ensemble des données reçues dans son tampon seulement
celles qui sont nécessaires au programme d’application. Il effectue toute transformation
nécessitée par la correspondance schéma externe ←→ schéma conceptuel (filtrage des
données reçues)

9. Le SGBD transmet ces données dans le tampon du programme d’application.

10. Le SGBD informe éventuellement le programme d’application des déroulements


anormaux qui auraient pu se produire lors de l’opération afin que celui-ci réagisse.

11. Le programme d’application dispose de la donnée demandée et peut entreprendre


l’opération suivante.

Le principe est le même au cas ou l’opération est une écriture ou une mise à jour. Ce principe
concerne uniquement un seul programme d’application. Dans la pratique, il y aura plusieurs
programmes d’application qui se déroulent en parallèle. Il appartient au SGBD de les gérer et plus
particulièrement de détecter le cas ou différents programmes souhaitent accéder à la même donnée.

7 Approches de développement d’un SGBD relationnel


Il existe deux approches de développement d’un SGBD relationnel :

1. Une approche descendante qui a donné naissance à la première génération de SGBD


relationnels

2. Une approche ascendante qui a donné naissance à la deuxième génération de SGBD


relationnels

7.1 Approche descendante

Cette approche a été adoptée très tôt pour le développement de nombreux SGBD commercialisés
avec succès (DBASE II, III, etc.).

Elle a consisté à concevoir le SGBD comme une interface relationnelle construite autour d’un
système de gestion de fichiers existant (SGF). C’est donc au SGF que revient la tâche de gérer les
supports physiques où est stockée la B.D.

La correspondance entre les notion de relation (propre au modèle relationnel) et de fichier (propre
au SGF) peut être de trois types :

1- Une relation ←→ Un fichier : c’est une implantation dite par ‘‘ fichier plat’’
2- Un attribut ←→ Un fichier : c’est une implantation dite par ‘‘ fichier

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 1: Généralités sur les bases de données • 21

transposé’’
3- Mixte : c’est une implantation dite par ‘‘ fichier virtuel’’

SGBD

SGF

B.D.

Figure 1.12 : Première approche de conception d’un SGBD/R

7.1.1 Inconvénients

Le SGBD est limité à la fonction de Manipulation des données sans se préoccuper de


l’implantation physique. Toute relation est décrite à travers le SGF : l’indépendance physique est
artificielle (difficile de changer l’organisation physique pour les soucis de performances d’accès).

C’est une méthode de développement fermée : le développeur est prisonnier des structures
physiques des objets du SGF (Si le nombre d’attributs par enregistrement est limité, le nombre
d’attributs par relation le sera aussi. Si les enregistrements ont une taille maximale fixe, les tuples de la
relation le seront aussi). Le SGBD obtenu n’est donc qu’un SGF aux fonctionnalités étendues ou ce
qui revient au même un SGBD aux fonctionnalités réduites.

L’accès à plusieurs relations en même temps est limité du fait qu’il nécessitera l’ouverture d’autant
de fichiers que de relations. Ceci est du au fait qu’un SGF ne peut pas permettre pratiquement
l’ouverture d’autant de fichiers qu’on le désire.

7.1.2 Avantages

Cette méthode offre l’avantage de pouvoir intégrer dans la B.D. des fichiers utilisés (ou créés) par
d’autres applications du fait qu’ils ont été crées par le même SGF. Donc la compatibilité entre les
formats rend possible la création d’une B.D. à partir de fichiers générés par d’autres applications (Paie,
tableur, facturation, etc.).

Elle rend aussi possible la manipulation de fichiers créés par un SGF avec des opérateurs
relationnels en utilisant des moyens de programmation classiques (langages évolués, clipper, etc.). Le
niveau interne du SGBD se réduit à une interface très simple avec le SGF puisque le SGBD ne gère
pas l’espace physique (un requête se traduira par des ordres de type READ, WRITE, OPEN, CLOSE
qui sont caractéristiques de tout SGF).

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 1: Généralités sur les bases de données • 22

7.2 Approche Ascendante

C’est l’approche adoptée pour le développement de la plupart des SGBD commercialisés à l’heure
actuelle. La différence avec la première est qu’ici le SGBD possède son propre système de gestion de
l’organisation physique des données. Ce système est généralement un système de gestion de pages
(SGP où 1 page est l’unité de transfert entre la mémoire centrale et le disque ~ 512 Octets).

Avec cette approche, toute la B.D. et son dictionnaire (différents schémas) sont stockés dans un
seul fichier système qui est géré par le SGP comme un ensemble de pages (vue comme un ensemble de
tables ou relations). Le SGBD est quasiment indépendant du SGF même s’il est possible de les faire
communiquer pour tout problème de transfert de données avec d’autres logiciels.

SGBD
SGF
SGP

B.D.

Figure 1.13 : Deuxième approche de conception d’un SGBD/R

7.2.1 Inconvénients

Cette méthode est caractérisée par sa complexité de développement car elle nécessite l’écriture de
toutes les fonctions de gestion des supports physiques (i.e. le SGP). A titre indicatif, IBM a mis plus
d’une année avec une équipe de 200 personnes (ingénieurs et programmeurs) pour la réalisation du
seul niveau interne de son SGBD SYSTEM/R.

De même, des fonctions de conversions SGBD ←→ SGF sont nécessaires (Extracteurs) pour
permettre le transfert de données dans les deux sens.

7.2.2 Avantages

Avec cette méthode, il n’y a pas de limitation sur le nombre de relations qui peuvent être
manipulées en même temps (jusqu’à plusieurs centaines !).

L’accès à une relation ne se fait plus au travers de primitives OPEN et CLOSE de fichiers qui sont
propres à un SGF. Le SGBD supporte entièrement les deux fonctions essentielles de description des
objets de la base (LDD) et de manipulation (LMD).

Le SGBD ne gère qu’un seul fichier contenant la B.D. et son dictionnaire. Le SGBD est facilement
portable vers d’autres environnement car il est indépendant du SGF (il suffit d’adapter le SGP au nouvel
environnement). Il est aussi ouvert car il maîtrise bien la structure des objets qu’il utilise d’où la possibilité de
l’étendre à d’autres types d’objets (images, sons, documents, etc.).

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 1: Généralités sur les bases de données • 23

8 Architecture de quelques SGBD relationnels

Les SGBD relationnels sont à l’heure actuelle les plus diffusés sur le marché. Ils permettent
d’organiser les données sous formes de tables. La description de la base de données est faite grâce à un
schéma conceptuel ou relationnel permettant de décrire toutes les tables (relations) implantées sur
disque. Ce schéma conceptuel servira par la suite à définir un ensemble de schémas externes ou vues
décrivant chacun les tables ou relations utilisées par une application. Au schéma relationnel est associé
un schéma interne décrivant les chemins d’accès aux tables et les méthodes d’accès (indexes, etc.).

8.1 Le système SQL/DS (Structured Query Langage/Data System)

Ce SGBD est issu d’un projet de recherche lancé par IBM et appelé SYSTEM/R. Il a été
initialement commercialisé sur le matériel IBM. Comme on le voit sur la figure, le SGBD est divisé en
trois composants :

1- DSC (Data System Control)


2- RDS (Relationnal Data System)
3- DBSS (Data Base Storage System)

„ DSC (Data System Control) : Ce composant assure la communication des usagers avec le
système. Il contrôle l’initialisation du système et la terminaison. Il permet aussi la
communication des programmes avec le SGBD via des ordres d’appel de type CALL.

„ RDS (Relationnal Data System) : Les requêtes émises par les usagers sont prises en
compte par DSC qui les analyse et les transforme de façon à respecter les VUES. Ensuite
DSC donne la main à RDS qui les transforme en des appels (les compile) à des modules
d’accès aux tables. Il est chargé de déterminer les meilleurs chemins d’accès possibles.

„ DBSS (Data Base Storage System) : Il effectue les accès disques demandés par les
modules de RDS. Il assure aussi la gestion de l’espace disque (Allocation, libération,...) et
résout les problèmes d’accès concurrents ainsi que la reprise après panne.

USER 1 USER n

VUE 1 VUE n

DSC

Schéma Relationnel

RDS
Schéma Interne
Chemin et méthodes
d’accès

B.D DBSS

Figure 1.14 : Architecture Fonctionnelle du SGBD SQL/DS (System/R)

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 1: Généralités sur les bases de données • 24

8.2 Le système INGRES (INteractive Graphics & REtrieval System)

Ce SGBD a été réalisé à l’université de BERKLEY par StoneBraker(en 1976). Il a été construit
autour du système d’exploitation UNIX et commercialisé initialement sur le matériel de la société
Digital Equipment Corporation (PDP et VAX).

INGRES se présente sous forme de 4 composants appelés Process (Processus)

• Process 1 : Assure la gestion des terminaux. Il permet à l’usager de formuler, imprimer,


modifier et lancer l’exécution des commandes (requêtes) offertes par le SGBD.

• Process 2 : Effectue l’analyse syntaxique des requêtes, la transformation de ces requêtes


afin de respecter les vues. Il assure aussi la protection et le contrôle de cohérence des
données ainsi que le contrôle des accès concurrents à la base.

• Process 3 : Assure la décomposition des requêtes impliquant plusieurs tables en une suite
de requêtes simples portant sur une table unique. En cas de requête impliquant une table
unique, il effectue lui-même l’accès aux données.

• Process 4 : Assure la création de nouvelles tables, indexes ; de même que les suppressions.
En gros, il s’occupe de tout ce qui concerne la gestion de l’espace disque. Il prend
également en charge les reprises après panne en retardant les mises à jour. Une mise à
jour n’est pas directement répercutée sur la base de données mais jusqu’à la fin du
programme.

USER 1 USER n

Process 1

VUE 1 VUE n

Process 2

Schéma Relationnel
Requêtes Process 3
mono-table
Schéma Interne
Chemin et méthodes
d’accès

Process 4
B.D

Figure 1.15 : Architecture fonctionnelle du SGBD INGRES

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 1: Généralités sur les bases de données • 25

8.3 Le SGBD ORACLE

C’est le SGBD relationnel le plus diffusé actuellement. Il existe aussi bien en version PC et
compatibles qu’en version mainframe. Il se présente sous forme d’un ensemble de modules dont un
constituant le noyau du SGBD. Depuis sa première diffusion sur le marché (vers 1984), ce SGBD n’a
cessé d’être amélioré et plusieurs versions se sont succédées. Si on se réfère par exemple à la version 5
du logiciel, la structure fonctionnelle du SGBD se présente comme suit :

Pro*C SQL*Plus

SQL*Forms
Noyau du
Utilitaires
SGBD

SQL*Calc

SQL*Report SQL*Graph

Figure 1.16 : Architecture fonctionnelle du SGBD ORACLE (V5)

On distingue :

• Le Noyau du SGBD : est la couche de base. Il permet la communication avec la B.D. et


assure les fonctions suivantes :

- Contrôle les accès à la base de données


- Gère les problèmes de confidentialité
- Assure les reprises après panne
- Contrôle la cohérence des données

• SQL*Plus : Permet à l’utilisateur d’envoyer des requêtes au SGBD (interrogation,


création, mise à jour, etc.)

• SQL*Forms : C’est un générateur d’application interactif (grilles d’écrans, masques de


saisie, etc.)

• SQL*Calc : Permet d’associer des requêtes SQL à des cellules d’un tableur intégré à
Oracle. le résultat de la requête constituera le contenu de la cellule.

• SQL*Graph : Permet de présenter sous forme graphique des données issues de la base
(histogramme, courbe, camembert, etc.)

• SQL*Report : Permet de mettre sous forme de rapports des données issues de la base
(Formatage, mise en page, Titre, etc.)

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 1: Généralités sur les bases de données • 26

• Pro*C : Précompilateur de programme écrit en C et contenant des requêtes SQL


(interrogation, création, mise à jour, etc.). Il existe d’autres
précompilateurs disponibles avec le même SGBD mais propre à d’autres
langages de programmation (Fortran, Cobol, etc.). Le principe de
précompilation est d’analyser lors d’une première passe le programme
afin de remplacer les requêtes SQL par des appels à des routines de bas
niveau se trouvant dans des bibliothèques du SGBD. Le résultat de la
précompilation sera donc un programme source C qui devra passer par les
étapes classiques de compilation et d’édition de liens pour enfin donner
un programme exécutable.

• Utilitaires : Il en existe une variété, chacun réalisant une fonction précise


(Exportation de données vers une autre B.D., Importation de données
depuis une autre B.D., allocation d’espace disque supplémentaire pour la
B.D., etc.)

L’avantage de ce SGBD est qu’il offre une compatibilité totale entre les versions PC et mainframe
(une B.D. créée sur PC peut facilement être transférée sur un gros ordinateur et vice versa).

9 Conclusion

Les SGBD relationnels sont à l’heure actuelle les systèmes les plus diffusés sur le marché. Leur
succès est dû au modèle de données sur lequel ils sont basés à savoir : le modèle relationnel. Ce
modèle est basé sur des fondements mathématiques (théorie des ensembles et des relations) et offre
une approche méthodologique pour la conception d’une B.D. De plus, il faut noter aussi que le succès
de ce modèle a été grandement favorisé par l’adoption par l’ISO du langage SQL (Structured Query
Language) comme une norme pour les langages de description et de manipulation d’une base de
données relationnelle.

Cependant, bien que la supériorité des SGBD relationnels est maintenant reconnue, ceci ne veut
pas dire que les SGBD de type réseau ou hiérarchique ne sont plus en usage. Ces SGBD ont aussi
évolués avec le temps et certains distributeurs continuent à promouvoir leur produit en allant jusqu’à
intégrer dans leur SGBD les concepts du relationnel en arguant que les meilleurs SGBD seront ceux
qui intégreront le relationnel et le navigationnel (réseau ou hiérarchique).

Pour mieux comprendre les apports du modèle relationnel dans le domaine des bases de données,
nous jugeons utile d’étudier d’abord dans le prochain chapitre les modèles qui l’ont précédé (réseau et
hiérarchique) et qui avaient, remarquons-le, fait la vogue pendant longtemps. Ceci nous permettra de
familiariser le lecteur avec les concepts de base inhérents à ces modèles et montrer par la même
occasion leurs inconvénients majeurs afin de mieux comprendre par la suite pourquoi le modèle
relationnel a effectivement pu les surpasser.

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 27

Chapitre 2 : Les modèles de données réseau et hiérarchique

1. Le modèle de données réseau général

1.1 Caractéristiques principales

Un modèle de données Réseau général (ou PLEXE) est un modèle dans lequel les relations entre
les entités sont représentées par des liens qui peuvent être 1:1, 1:N, N:1, ou N:M. Ces liens en nombre
quelconque peuvent associer toute paire d’entités du modèle. Ils devront être distingués les uns des
autres par un identificateur.

⌦ L’exemple suivant va nous permettre de préciser la signification de tous les liens (ou
associations) existants entre les entités

1: N Est_Peuplé_Par
PAYS PERSONNES

Est_Composée_de 1:N Habite_Dans N: 1 1:N Est_Habitée_Par

1:1 Se_Trouve_Dans
WILAYAS Villes

Regroupe
N:M
A_Pour_Wali 1:1
Est_Implantée_Dans

WALI SOCIETES

Figure 2.1 : Exemple de modèle de données de type réseau général

• Un lien de type 1 : 1 associe à une occurrence de l’entité origine une et une seule
occurrence de l’entité d’arrivée. Il faut remarquer que dans ce type de lien les cardinalités
(1:1) ne suffisent pas pour orienter le lien afin de distinguer l’entité origine du lien de celle
d’arrivée. C’est pour cela que la sémantique du lien doit être véhiculée par le nom du lien.
Par exemple le lien 1:1 existant entre les deux entités WILAYAS et WALI et ayant pour
nom A_Pour_Wali sous entend qu’on oriente le lien de l’entité WILAYAS vers l’entité
WALI. On aurait pu utiliser le même lien mais en l’orientant de l’entité WALI vers l’entité
WILAYAS grâce au nom du lien qui serait dans ce cas Est_Wali_De.

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 28

• Un lien de type 1:N associe à une occurrence de l’entité origine (se trouvant du côté de la
flèche simple) zéro (0), une (1) ou plusieurs (N) occurrences de l’entité d’arrivée (se trouvant
du côté de la flèche double). L’orientation du lien est donc entièrement déterminée grâce aux
cardinalités 1:N. Le nom attribué au lien permet de rattacher une sémantique au lien. Par
exemple le lien Est_Habité_Par de type 1:N va implicitement de l’entité VILLES vers
l’entité PERSONNES et permet de modéliser le fait qu’une ville v soit habitée par 0, une
ou plusieurs personnes.

• Un lien de type N:1 associe à 0, une ou plusieurs occurrences de l’entité origine (se
trouvant du côté de la flèche double, une et une seule occurrence de l’entité d’arrivée (se
trouvant du côté de la flèche simple). Ce lien est donc implicitement orienté de l’entité se
trouvant du côté de la flèche double vers l’entité se trouvant du côté de la flèche simple. Par
exemple le lien Habite_Dans de type N:1 allant de l’entités PERSONNES vers l’entité
VILLES modélise le fait que 0, une ou plusieurs personnes Habitent dans une seule ville.

• Un lien de type N:M associe à 0, une ou plusieurs occurrences de l’entité origine (se
trouvant du côté de la première flèche double), 0, une ou plusieurs occurrences de l’entité
d’arrivée (se trouvant du côté de l’autre flèche double). Là aussi, les cardinalités N:M ne
suffisent pas pour fixer l’orientation du lien afin de pouvoir distinguer entre l’entité origine
et l’entité d’arrivée de ce lien. C’est le même problème que dans le cas d’un lien de type 1:1
et par conséquent la sémantique du lien doit être véhiculée par le nom qui sera attribué au
lien. Par exemple, le lien N:M entre les entités VILLES et SOCIETES et ayant pour nom
Est_Impantée_Dans sous-entend qu’on oriente le lien de l’entité SOCIETES vers l’entité
VILLES puisque dans la réalité on dit qu’une société est implantée dans une ville (ou
possède un siège dans une ville). La possibilité qui consisterait à orienter le lien de l’entité
VILLES vers l’entité SOCIETES permettrait quant à elle de modéliser une autre réalité qui
signifie qu’une ville regroupe 0, une ou plusieurs sociétés. Il faudra dans ce cas donner au
lien N:M un nom qui véhicule cette sémantique. Dans notre exemple c’est le nom Regroupe
attribué au lien qui renseigne sur cette sémantique.

1.2 Diagramme de structure de données de BACHMAN

1.2.1 Définition

Un diagramme de BACHMAN (appelé aussi diagramme de structures de données) est un modèle


de données de type réseau général mais dans lequel toutes les relations entre les entités sont de type 1:
N. Nous rappelons que la représentation graphique d’un modèle de données sous forme de boîtes et de
flèches a été proposée justement par BACHMAN. Auparavant, on ne représentait un modèle de
données que par le biais de structures de données plus proche du niveau physique telles que des liste
chaînées et des fichiers ce qui rendait difficile l’étape de conception du modèle de données.
L’avantage du diagramme de BACHMAN est donc de permettre une représentation simple et
uniforme des modèles de données basée sur deux concepts : la boîte (rectangle) modélisant une entité
et la flèche modélisant un lien entre deux entités. Pour obtenir un tel modèle, il est bien souvent
nécessaire de transformer tous les liens de type N:M en des liens 1:N. Bien entendu, le modèle ne
comportera pas de lien N:M, mais peut cependant avoir plusieurs liens 1:N entre deux mêmes entités
qui seront alors différenciés par un nom (i.e. un identificateur).

1.2.2 Méthodes de transformation des liens N:M

Un lien N:M (complexe) entre deux entités peut être transformé de telle sorte que les liens
résultants soient de type 1:N en utilisant l’une des méthodes suivantes :

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 29

1.2.2.1 Création d’une entité d’intersection

Cette méthode consiste à créer une nouvelle entité appelée entité d’intersection qui possédera une
clé obtenue par concaténation des clés des deux entités participant au lien N:M. Considérons
l’exemple suivant où nous avons deux entités A et B entre lesquelles existe un lien N:M :

⌦ La transformation de ce lien par la méthode de l’entité d’intersection donnerait :

A B
A

L1 1:N 1:N L2
N:M

Autres Attributs
B #A . #B de l’entité .........

Entité d’Intersection

Figure 2.2 : Transformation d’un lien N:M par la méthode de l’entité d’intersection

1.2.2.2 Méthodes des entités virtuelles et des pointeurs logiques

Cette méthode consiste à créer des entités virtuelles appelées aussi entités pointeurs qui sont
constituées de pointeurs et contenant autant de pointeurs que l’entité pointée. Un pointeur logique doit
être vu à ce niveau comme une clé de l’entité concernée.

⌦ Avec cette méthode, la transformation du lien N:M de l’exemple précédent donnerait :

A B

1:N 1:N

Entité Virtuelle B Entité Virtuelle A

Contenant des Pointeurs sur B Contenant des Pointeurs sur A

Figure 2.3 : Transformation d’un lien N:M par la méthode de l’entité virtuelle

Les flèches en pointillés signifient que l’entité virtuelle contient des pointeurs logiques (ou clés)
sur l’entité pointée (A ou B). Cette solution a surtout pour but d’éviter le problème de duplication des
entités qui comme on le sait engendre de la redondance d’information avec tous les problèmes qui en
découlent (gaspillage de l’espace mémoire, risque d’incohérence, etc.). En effet, rien ne nous interdit
pour transformer le lien complexe N:M de créer une copie de chaque entité A et B (i.e. avec les mêmes
attributs) mais auxquelles on donnera deux noms distincts par exemple A2 et B2.

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 30

⌦ On aura donc le modèle suivant :

A B

LAB LBA
1:N 1:N

B2 A2

Figure 2.4 : Transformation d’un lien N:M par duplication des entités

Les deux entités A2 et B2 seront définies au même niveau que A et B et de la même façon. Un
SGBD ne peut en aucun cas déduire par exemple que l’entité A2 et une copie de l’entité A ni que B2
et une copie de l’entité B et ce malgré que celles-ci ont les mêmes attributs. Mis à part les problèmes
de redondance d’information et leurs conséquences, cette solution oblige le programmeur de gérer lui
même les problèmes de cohérence car toute mise à jour dans A ou B devra obligatoirement être
répercutée dans A2 ou B2 respectivement. En effet, ce travail ne peut en aucun être fait par le SGBD
qui ignore comme on l’a dit plus haut que A2 est une copie de A et que B2 est une copie de B puisque
les entités sont simplement distinguées par leurs noms.

Par contre dans le cas de la méthode des entités virtuelles, c’est le SGBD qui met à la disposition
du programmeur des instructions du LDD pour spécifier que telle entité est virtuelle c’est à dire
qu’elle a été définie auparavant et qu’on veut simplement la réutiliser pour les besoins du modèle sans
la redéfinir. Il devient ainsi possible d’éviter les problèmes de duplication d’information. Cette
technique est utilisée par exemple avec les SGBD hiérarchiques.

2. Le modèle de données réseau de Codasyl

Le modèle réseau proposé par le Data Base Task Group (DBTG) est un modèle de type
diagramme de BACHMAN. Tous les liens sont donc de type 1:N, c’est à dire qu’aucun lien complexe
N:M n’est autorisé. Dans ce cas, si le processus de modélisation conduit à un modèle de données
comportant des liens complexes (N:M), il faudra nécessairement pour se conformer aux spécifications
du modèle réseau CODASYL, les transformer en des liens 1:N.

2.1 Principaux concepts du modèle

Le modèle réseau CODASYL propose deux concepts de base, les enregistrements appelés
RECORD dans la terminologie CODASYL et les liens (ou associations) entre enregistrements
appelés SET.

2.1.1 L’enregistrement

Un enregistrement ou RECORD est décrit par un nom (identificateur) unique permettant de le

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 31

distinguer parmi l’ensemble des enregistrements du schéma conceptuel et par un ensemble d’attributs
chacun possédant un nom et un type (entier, réel, chaîne de caractères, etc.).

⌦ L’exemple suivant permet d’avoir une idée approximative sur la façon de décrire un
enregistrement avec un SGBD CODASYL :

RECORD NAME IS EMPLOYE

02 Numero PICTURE 9(6)

02 Nom PICTURE A(12)

02 Nbre_Enfants PICTURE 99

02 Enfants OCCURS Nbre_Enfants TIMES


03 Prenom_Enfant TYPE IS CHARACTER 10
03 Age_Enfant PICTURE 99
03 Annee_Scolaire PICTURE 99

Figure 2.5 Exemple de description d’un enregistrement selon CODASYL

Les mots en gras sont des mots clefs du langage de description de données(LDD) offert par le
SGBD. L’enregistrement ici s’appelle EMPLOYE et possède comme attributs :

un numéro identifié par Numero de type numérique à six (06) chiffres :PICTURE 9(6)
un nom identifié par Nom de type alphabétique à 12 caractères : PICTURE A(12)
un nombre d’enfants identifié par Nbre_Enfants de type numérique à 2 chiffres
(PICTURE 99)
de 0 à Nbre_Enfants enfants (variable selon chaque employé) chaque enfant étant
caractérisé par les attributs :
un prénom identifié par Prenom_Enfant de type caractère pouvant occuper jusqu’à 10
au maximum
un âge identifié par Age_Enfant de type numérique à 2 chiffres (PICTURE 99)
une année scolaire identifiée par Annee_Scolaire de type numérique à 2 chiffres
(PICTURE 99)

2.1.2 Le Lien ou SET

Un lien entre deux entités est appelé un SET dans la terminologie CODASYL. L’entité origine du
SET est dite propriétaire ( ou Owner en anglais ). C’est le cas de l’entité MEDECIN dans la figure
ci-dessous. L’entité sur laquelle arrive le SET (l’arc) est dite membre du SET ( ou Member en
anglais ). C’est le cas de l’entité MALADES dans la figure ci-dessous. Un SET permet d’associer à
une occurrence de l’entité (ou enregistrement) propriétaire une ou plusieurs occurrences de l’entité
membre (car tout lien du modèle est de type 1:N) alors qu’inversement à chaque occurrence de l’entité
membre ne peut être associé qu’au plus une occurrence de l’entité propriétaire.

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 32

⌦ Un exemple de représentation graphique d’un SET CODASYL serait :

MEDECIN

Examine

MALADE

Figure 2.6 : Représentation graphique d’un SET CODASYL

Dans la représentation graphique d’un SET, il n’est pas nécessaire d’indiquer par une double
flèche que le lien est de type 1:N puisque tous les liens sont sous entendus être de type 1:N. On
représente donc simplement un SET à l’aide d’un arc orienté de l’entité propriétaire vers l’entité
membre et on le distingue par un nom. Sur la figure ci-dessus, le SET a pour nom Examine et est
orienté dans le sens MEDECIN vers MALADES.

Dans le cas où la modélisation conduit à des liens N:M, il faudra donc pour passer au modèle
Réseau CODASYL, les transformer en des liens 1:N par l’une des méthodes présentées plus haut. Le
mécanisme d’accès qui permet de passer d’une occurrence de l’entité propriétaire aux occurrences de
l’entité membre qui lui sont associées par le lien est en général celui d’une liste circulaire ayant pour
tête de liste l’occurrence de l’entité Propriétaire .

⌦ Un exemple de représentation par liste circulaire d’une occurrence du SET Examine


serait comme suit :

Pasteur

Ali

Omar

Kamel

Figure 2.7 Représentation d’une occurrence d’un SET par une liste circulaire

2.1.3 Remarques

Cette liste circulaire ne représente qu’une seule occurrence (on dit aussi réalisation) du SET ayant
pour nom Examine. Sur la figure 2.7, la tête de la liste contient l’occurrence Pasteur de
l’enregistrement MEDECIN qui est le Propriétaire du SET. Les membres de la liste sont : Ali,
Omar,.... et enfin Kamel qui sont toutes des occurrences de l’enregistrement MALADES. Cette
représentation est possible car chaque occurrence de l’enregistrement de type MALADES (ex : Ali,
Omar, ...ou Kamel) n’est associé qu’à une seule occurrence de l’enregistrement de type MEDECIN
(ex : Pasteur) et ne peut donc apparaître que dans une seule liste circulaire. En effet, si une occurrence
de l’enregistrement de type MALADES pouvait être parcouru par plusieurs listes ayant chacune pour
tête une occurrence différente de MEDECIN, il faudrait un nombre variable de pointeurs à rajouter à
chaque occurrence de MALADES et aussi à celles de MEDECIN (en tête de chaque liste). Au fond,
cette solution difficile à implémenter ne vise qu’à modéliser le fait qu’un malade peut être examiné par
plusieurs médecins et qu’un médecin peut examiner plusieurs malades et qui n’est autre qu’un lien
complexe N:M. C’est donc pour des raisons liées à des difficultés d’implémentation qu’une

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 33

association de type N:M n’a pas été retenue dans le modèle réseau de CODASYL.

Au niveau physique, il y aura pour chaque SET autant de listes qu’il y a d’occurrences de
l’enregistrement propriétaire de ce SET. On dit que chaque liste est une réalisation du lien L. Ce
sera la même chose pour tous les autres SET existant entre les enregistrements du modèle.

2.1.4 Exemple de transformation d’un lien N:M

Considérons deux entités INSTITUTS et MODULES qui sont associées par un lien N:M
modélisant le fait qu’un module peut être enseigné dans 0, 1 ou plusieurs instituts et qu’inversement
un institut peut dispenser 0, 1 ou plusieurs modules. En nous limitant à l’exemple de 3 instituts qui
dispensent respectivement les modules suivants :

un institut d’informatique qui dispense les modules : INF123, M002 et P014


un institut de mathématiques qui dispense le module : M002
un institut de physique qui dispense les modules : M002 et P014

(Les codes INF123 signifiant le module d’informatique N°123, M002 signifient le module de
Mathématiques N° 002 et P014 signifiant le module de Physique N° 014 )

⌦ La représentation à l’aide d’un diagramme des associations existant entre les occurrences
des entités INSTITUTS et MODULES donnerait :

M 002
Mathématiques

Informatique INF 123

Physique P 014

Figure 2.8 : Diagramme des associations entre les occurrences des deux entités

⌦ La transformation du lien N:M en utilisant la méthode de l’entité d’intersection donnerait :

INSTITUTS MODULES

L1 L2
1:N 1:N

Entité d’intersection
#Instituts . #Modules

Figure 2.9 : Transformation du lien N:M entre INSTITUTS et MODULES

#Instituts et #Modules désignent respectivement les clés des entités INSTITUTS et MODULES.

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 34

Comme nous l’avons déjà signalé, la clé de l’entité d’intersection que nous avons notée sur la figure
par #Instituts. #Modules sera obtenue par concaténation de ces deux clés. Sur le plan pratique, il
s’agira d’une entité dont la clé est composée des deux attributs : #Institut et #Module

Chaque enregistrement de l’entité Instituts va être une tête de liste pour la réalisation du lien L1
allant de l’entité Instituts vers l’entité d’intersection. Il en sera de même pour les enregistrements de
l’entité Modules pour la réalisation du lien L2 allant de l’entité Modules vers l’entité d’intersection.

⌦ La réalisation des liens L1 et L2 grâce au mécanisme de la liste circulaire pourrait être


schématisée comme suit :

Informatique Mathématiques Physique

#Infor. #P014 #Phys. #P014

#Infor. #M002 #Math. #M002 #Phys. #M002

#Infor. #Inf 123

Inf 123 M002 P014

Figure 2.10 : Représentation des SET L1 et L2 par liste circulaires

On remarque que chaque occurrence de l’entité INSTITUTS ou MODULES est une tête de liste.
On remarque qu’il y’ a trois (03) listes réalisant le SET L1 ayant chacune pour tête une occurrence de
INSTITUTS à savoir : Informatique puis Mathématiques puis Physique. L’établissement du
chaînage des occurrences des propriétaires avec les occurrences des membres respectifs est représentée
par des flèches en trait plein et les pointeurs servant à parcourir chacune des listes sont représentés
par le symbole . Ce pointeur caractérise donc sans ambiguïté le SET L1. IL en est de même pour la
réalisation du SET L2 ayant pour Propriétaire l’entité MODULES et pour membre l’entité
d’intersection. Pour le SET L2, le chaînage est représenté par des flèches en traits pointillés et les
pointeurs par le symbole qui caractérise aussi sans ambiguïté le SET L2.

Compte tenu du fait que sur un enregistrement peuvent arriver autant de liens qu’on veut et que de
ce même enregistrement peuvent aussi partir autant de liens qu’on veut, le nombre de pointeurs qui
seront rajoutés par le SGBD à chaque occurrence de cet enregistrement sera égal à : (Nombre de liens
entrants + Nombre de liens sortants). Il faut préciser que chaque pointeur sert pour gérer un lien
(SET) et un seul. Par exemple, le nombre de pointeurs qui sont rajoutés à chaque occurrence de
l’entité d’intersection sera donc égal à 2 puisque on a un Nombre de liens entrants égal à 2 et un
Nombre de liens sortants égal à 0 (ce qui donne bien 0 + 2 = 2). Par contre le nombre de pointeurs
qui sont rajoutés à chaque occurrence de l’entité INSTITUTS (Propriétaire du lien L1) ou à celle de

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 35

MODULES (Propriétaire du SET L2) sera égal simplement à 1 puisqu’on a un Nombre de liens
entrants égal à 0 et un Nombre de liens sortants égal à 1 (ce qui donne bien 0 + 1 = 1 et ce aussi
bien pour INSTITUTS que pour MODULE).

2.1.5 Remarques importantes

La création d’une entité d’intersection a lieu dans la phase de modélisation et est imposée par le fait
que le modèle de données supporté par le SGBD ne permet pas de liens complexes N:M entre deux
entités. Le SGBD en lui-même ne fait pas de distinction entre les entités et n’a pas à distinguer si telle
ou telle entité est une entité d’intersection ou pas. Ainsi, une entité d’intersection peut même avoir des
attributs qui lui sont propres en plus de sa clé obtenue par concaténation. A ce niveau, il faut préciser
que le résultat de la phase de modélisation n’est en réalité qu’une version sur papier du schéma
conceptuel de la base de données et sur lequel il est évidemment possible de distinguer que telle entité
est une entité d’intersection. Cependant, dans la phase de description de ce schéma conceptuel à l’aide
du Langage de Description de données (LDD) offert par le SGBD, toutes les entités seront décrites de
la même façon et il n’y a pas d’intérêt pratique de distinguer à ce niveau les entités d’intersection des
autres entités. Nous rappelons que le concept d’entité d’intersection sert essentiellement pour éviter les
liens complexes de type N:M qui ne sont pas autorisés par le modèle réseau tel qu’il a été spécifié par
le groupe CODASYL.

2.1. 6 Propriétés d’un schéma conforme au modèle réseau CODASYL

Les notions de SET (ou lien) et de RECORD (ou enregistrement) servent de support principal à la
définition du schéma d’une base de données conforme au modèle réseau proposé par CODASYL. La
structure d’un schéma dépend étroitement de l’application qui a nécessité sa mise en place. Cependant,
il existe un certain nombre de propriétés qui doivent être respectées lors de l’établissement de tout
schéma et ce indépendamment de l’application. Ce sont les suivantes :

• D’un enregistrement on peut faire partir autant de liens différents que l’on veut
• Sur un enregistrement peuvent arriver autant de liens que l’on veut.
• Entre deux enregistrements distincts P et M, il peut y avoir plusieurs liens différents
allant de P vers M et inversement.
• Sur un enregistrement, il ne peut y avoir de lien pouvant boucler sur ce même
enregistrement (lien réflexif)

L’impossibilité d’avoir un lien réflexif est dûe au fait que l’implémentation physique d’un lien est
faite généralement à l’aide d’un ensemble de listes circulaires dont chacune a pour tête une
occurrence de l’enregistrement propriétaire du lien et dont les autres éléments sont des occurrences de
l’enregistrement membre qui sont liées à l’occurrence de ce propriétaire. Dans le cas d’un lien réflexif,
il sera donc difficile de distinguer parmi les occurrences composant la liste l’occurrence du
propriétaire (tête de liste) des occurrences du membre car elles sont toutes de même type. Il faut à ce
niveau souligner que la distinction entre un enregistrement propriétaire dans un SET d’un
enregistrement membre de ce même SET se fait grâce au type de l’enregistrement qui est caractérisé
par son nom (identificateur).

Si la réalisation physique des SET peut se faire par le biais des listes circulaires, celle des
RECORD (entités ou enregistrements) se fait généralement par le biais de fichiers classiques. Lors du
parcours d’une liste circulaire réalisant un SET, le SGBD passe d’un fichier (celui contenant les
occurrences du propriétaire) à un autre fichier (celui contenant les occurrences du membre) et
inversement. Dans un lien réflexif, c’est le même fichier qui contiendra les occurrences du propriétaire

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 36

et celles du membre (même type d’enregistrement défini par un nom). IL sera donc très difficile pour
ne pas dire impossible pour le SGBD de distinguer entre les occurrences du Propriétaire et celles du
membre. C’est donc pour des raisons purement techniques ayant trait aux difficultés de mise en œuvre
au niveau physique d’un lien réflexif que ce type de lien n’a pas été autorisé dans le modèle réseau
CODASYL.

Il faut cependant noter que la possibilité d’avoir un lien réflexif partant d’un enregistrement de
type P et bouclant sur P serait très utile au niveau de la modélisation car ce cas se rencontre très
fréquemment en pratique.

⌦ Par exemple le lien réflexif défini sur l’entité Personne pourrait modéliser la réalité
suivante :

A_Pour_Enfants

PERSONNE PERSONNE
PERSONNE

A_Pour_Frères

Figure 2.11 : Lien réflexif sur l’entité PERSONNE

où le lien A_Pour_Enfants modélise la réalité qu’une Personne peut avoir zéro, un ou plusieurs
enfants et le lien A_Pour_Frères modélise la réalité qu’une Personne peut avoir zéro, un ou
plusieurs frères.

⌦ Un autre exemple serait le lien réflexif qu’on pourrait définir sur l’entité Pièces et qui
pourrait modéliser la nomenclature d’une pièce :

Compose

PIECE PIECE PIECE

Est_Composée_De

Figure 2.12 : Lien réflexif sur l’entité PIECE

où le lien Compose modélise la réalité qu’une PIECE peut participer à la composition de zéro, une
ou plusieurs autres pièces et le lien Est_Composée_De modélise la réalité qu’une PIECE peut être
composée à partir d’une ou de plusieurs autres pièces (ici au minimum une pièce car dans le cas d’une
pièce indécomposable celle-ci n’est composée que d’elle même).

2.2 Description d’un schéma avec un LDD de type CODASYL

2.2.1 Exemple illustratif

Considérons la base de données représentée par le modèle réseau général de la figure ci-dessous et
obtenu par l’application d’un processus de modélisation sans tenir compte des spécificités du modèle
réseau de CODASYL.

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 37

⌦ La réalité modélisée par cet exemple est la suivante :

Un Fournisseur peut fournir 0, 1 ou plusieurs Produits et inversement un Produit


peut être fourni par 0, 1 ou plusieurs Fournisseurs ;

Un Client peut commander 0, 1 ou plusieurs Produits et inversement un Produit peut


être commandé par 0, 1 ou plusieurs Clients.

Fournisseurs Produits Clients


N:M N: M

Figure 2.13 Exemple de modèle pouvant résulter de la phase de modélisation

Un modèle sous cette forme n’est pas conforme aux spécifications du modèle réseau proposé par le
DBTG et ce à cause des liens complexes N:M qu’il comporte. Nous allons essayer de le transformer
en utilisant deux entités d’intersection, l’une que nous appellerons PRIX et qui permettra de
transformer le lien N:M entre l’entité Fournisseurs et l’entité Produits, et l’autre que nous
appellerons COMMANDES et qui permettra de transformer le lien N:M entre l’entité Clients et
l’entité Produits.

Le lien N:M entre l’entité FOURNISSEURS et l’entité PRODUITS sera donc remplacé par deux
liens de type 1:N. l’un allant de l’entité FOURNISSEURS vers l’entité d’intersection PRIX et ayant
pour nom : FOURNISSEUR_PRIX, l’autre allant de l’entité PRODUITS vers l’entité d’intersection
PRIX et ayant pour nom : PRODUIT_PRIX.

Le lien N:M entre l’entité CLIENTS et l’entité PRODUITS sera aussi remplacé par deux liens de
type 1:N l’un allant de l’entité CLIENTS vers l’entité d’intersection COMMANDES et ayant pour
nom : COMMANDE_CLIENT, l’autre allant de l’entité PRODUITS vers l’entité d’intersection
COMMANDES et ayant pour nom : COMMANDE_PRODUIT

⌦ Ainsi, on obtient un modèle réseau comportant uniquement des liens 1:N. C’est donc bien
un modèle réseau CODASYL (ou aussi un diagramme de Bachman ) :

FOURNISSEURS

FOURNISSEUR_PRIX
CLIENTS

PRIX COMMANDE_CLIENT

PRODUIT_PRIX
COMMANDE_PRODUIT
Produits COMMANDES

Figure 2.14 Modèle réseau CODASYL après transformation des liens N:M

Les entités PRIX et COMMANDES sont les entités d’intersection que nous avons introduit. Le

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 38

schéma est donc composé de cinq entités qui sont : FOURNISSEURS, PRODUITS, CLIENTS,
COMMANDES et PRIX. Il comporte aussi quatre SET qui sont : FOURNISEUR_PRIX,
PRODUIT_PRIX, COMMANDE_PRODUIT et COMMANDE_CLIENT.

2.2.2 Structure d’un schéma

La description d’un schéma selon les spécifications du DBTG comprend quatre types de
déclarations :

La déclaration du nom du schéma qui servira au SGBD à le distinguer parmi l’ensemble


des schémas gérés par le SGBD ;

Une ou plusieurs déclarations d’AREA précisant les noms des zones physiques du
support de stockage dans lesquelles seront écrites les occurrences des enregistrements de
la base de données.

Cette proposition consistant à déclarer des AREAS au même niveau que celui de
la définition logique du schéma a été vivement critiqué car elle va à l’encontre de
l’indépendance physique des données. Néanmoins le DBTG la justifie par le fait
qu’elle permet d’aider le SGBD à mieux gérer l’organisation physique des données

Une ou plusieurs déclarations de type d’enregistrement (ou RECORD). Un type


d’enregistrement est décrit de manière analogue à une description d’enregistrement en
COBOL c’est à dire par un nom et un ensemble d’attributs possédant chacun un type
(entier, chaîne de caractères, etc.) et un format ;

Une ou plusieurs déclarations de lien (ou SET), spécifiant les associations entre les types
d’enregistrement déjà définis.

2.2.3 Programme de description

Nous donnons dans ce qui suit une description ‘‘à la CODASYL’’ de ce schéma. Il ne s’agit pas ici
de respecter scrupuleusement la syntaxe du langage de description (LDD) proposé par le groupe
puisque tel n’est pas notre objectif. Nous voulons surtout permettre au lecteur d’avoir une idée sur ce à
quoi pourrait ressembler un programme de description du schéma conceptuel ou logique d’une base de
données avec un SGBD CODASYL. Une discussion du programme nous permettra de mettre en
évidence l’essentiel des propositions de CODASYL.

01 SCHEMA NAME IS GESTION_VENTES


02 AREA NAME IS COMMANDES_CLIENTS
03 AREA NAME IS PRODUITS_FOURNISSEURS

04 RECORD NAME IS CLIENTS


05 PRIVACY LOCK FOR GET FIND IS 266D
06 PRIVACY LOCK FOR MODIFY, INSERT, DELETE, REMOVE, STORE IS CHEF_VENTES
07 LOCATION MODE IS CALC HASH-PROC1 USING Num_Client IN CLIENTS
08 DUPLICATES ARE NOT ALLOWED
09 WITHIN COMMANDES_CLIENTS
10 IDENTIFIER IS Num_Client IN CLIENTS

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 39

11 02 Num_Client PICTURE 9(6).


12 02 Nom_Client PICTURE A(12).
13 02 Adr_Client
14 03 Numéro PICTURE 999.
15 03 Rue PICTURE X(15).
16 03 Code_Postal PICTURE 9(5).
17 03 Ville PICTURE A(20).

18 RECORD NAME IS FOURNISSEURS


19 LOCATION MODE IS CALC HASH-PROC2 USING Num_Fourn IN FOURNISSEURS
20 DUPLICATES ARE NOT ALLOWED
21 WITHIN PRODUITS_FOURNISSEURS
22 IDENTIFIER IS Num_Fourn IN FOURNISSEURS
23 02 Num_Fourn PICTURE 9(6)
24 02 Nom_Fourn PICTURE A(15)
25 02 Adr_Fourn PICTURE X(20)
26 02 Téléphone PICTURE 9(8)

27 RECORD NAME IS PRODUITS


28 LOCATION MODE IS CALC HASH-PROC3 USING Num_Produit IN PRODUITS
29 DUPLICATES ARE NOT ALLOWED
30 WITHIN PRODUITS_FOURNISSEURS
31 IDENTIFIER IS Num_Produit IN PRODUITS
32 02 Num_Produit PICTURE 9(4).
33 02 Nom_Produit PICTURE X(15).

34 RECORD NAME IS COMMANDES


35 LOCATION MODE IS
36 SYSTEM DEFAULT
37 WITHIN COMMANDES_CLIENTS
38 02 Quantité PICTURE 9(3)
39 02 Num_Produit IS VIRTUAL SOURCE IS Num_Produit OF OWNER OF
COMMANDE_PRODUIT
40 02 Num_Client IS VIRTUAL SOURCE IS Num_Client OF OWNER OF
COMMANDE_CLIENT

41 RECORD NAME IS PRIX


42 LOCATION MODE IS
43 SYSTEM DEFAULT
44 WITHIN PRODUITS_FOURNISSEURS
45 02 Prix_Unité PICTURE 9999V99
46 02 Num_Produit IS VIRTUAL SOURCE IS Num_Produit OF OWNER OF
PRODUIT_PRIX
47 02 Num_Fourn IS VIRTUAL SOURCE IS Num_Fourn OF OWNER OF
FOURNISSEUR_PRIX

48 SET NAME IS FOURNISSEUR_PRIX


49 ORDER IS SORTED
50 MODE IS CHAIN
51 OWNER IS FOURNISSEURS
52 MEMBER IS PRIX INSERTION IS AUTOMATIC
53 RETENTION IS MANDATORY
54 ASCENDING KEY IS Num_Fourn
55 DUPLICATES ARE NOT ALLOWED
56 SET SELECTION IS THRU FOURNISSEUR_PRIX

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 40

57 OWNER IDENTIFIED BY Num_Fourn IN FOURNISSEURS

58 SET NAME IS PRODUIT_PRIX


59 ORDER IS SORTED
60 OWNER IS PRODUITS
61 MEMBER IS PRIX INSERTION IS MANUAL ; RETENTION IS OPTIONAL
62 ASCENDING KEY IS Num_Produit, Prix_Unité
63 DUPLICATES ARE NOT ALLOWED
64 SET SELECTION IS THRU PRODUIT_PRIX OWNER IDENTIFIED BY Num_Produit
65 IN PRODUITS

66 SET NAME IS COMMANDE_PRODUIT


67 ORDER IS NEXT
68 MODE IS CHAIN
69 OWNER IS PRODUITS
70 MEMBER IS COMMANDES INSERTION IS MANUAL ; RETENTION IS OPTIONAL
71 DUPLICATES ARE ALLOWED
72 SET SELECTION IS THRU COMMANDE_PRODUIT OWNER IDENTIFIED BY
Num_Produit IN PRODUITS

73 SET NAME IS COMMANDE_CLIENT


74 ORDER IS NEXT
75 MODE IS CHAIN
76 OWNER IS CLIENTS
77 MEMBER IS COMMANDES INSERTION IS MANUAL ; RETENTION IS OPTIONAL
78 DUPLICATES ARE ALLOWED
79 SET SELECTION IS THRU COMMANDE_CLIENT OWNER IDENTIFIED BY
Num_Client IN CLIENTS

Figure 2.15 : Description d’un schéma avec un LDD CODASYL

2.2.4 Discussion du programme

Compte tenu de la structure d’un schéma, on remarque qu’un programme de description est formé
de quatre sections de déclarations à savoir :

2.2.4.1 Déclarations relatives aux noms du schéma et des Areas

⌦ L’instruction 1 permet de définir le nom du schéma qui sera : GESTION_VENTES

⌦ Les instructions 2 et 3 indiquent les noms des AREAS (ou zones) dans lesquelles les
enregistrements de la base de données vont résider. On spécifie qu’on a deux AREAS l’une
s’appelant : COMMANDES_CLIENTS et l’autre : PRODUITS_FOURNISSEURS. Il
faut cependant remarquer qu’on ne définit à ce niveau que les noms logiques (i.e. des
identificateurs) des AREAS et qu’aucune adresse physique sur le support n’est précisée. Le
travail d’association d’une adresse physique à un nom d’AREA sur le support de stockage
sera donc du ressort du SGBD.

2.2.4.2 Déclarations relatives aux enregistrements (RECORD)

⌦ L’instruction 4 permet de définir le type d’enregistrement ayant pour nom : CLIENTS. Les

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 41

instructions 5 et 6 permettent de contrôler l’accès à ce type d’enregistrement. L’instruction 5


précise que les opérations de lecture (GET, FIND ) ne peuvent être réalisées sur CLIENTS
que si le programme d’application fournit la clé de protection qui est : 266D. L’instruction
6 quant à elle permet de préciser que les opérations : MODIFY, INSERT, DELETE,
REMOVE, STORE sur CLIENTS ne pourront être réalisées que si le programme
d’application fournit la clé de protection qui est : CHEF_VENTES.

⌦ L’instruction 7 définit le mode de localisation < 07 LOCATION MODE IS CALC ....>


d’une occurrence d’un enregistrement de type CLIENTS. Le mode de localisation spécifié
dans ce cas consiste à transformer une valeur de l’attribut Num_Client en une adresse sur le
support en appliquant à cette valeur la procédure de transformation ayant pour nom : HASH-
PROC1 et qui est en quelque sorte une fonction de hachage. De telles fonctions sont soit
offertes par le SGBD soit écrites pour le besoin de l’application par l’administrateur de la
base de données. D’autres modes de localisation sont aussi possible. Ce sont :

Mode Direct ( déclaré avec LOCATION MODE IS DIRECT ) : Ce mode précise


que les occurrences d’un enregistrement sont accédés directement grâce à une adresse
dans le fichier qui les contient. Une telle adresse est appelée dans la terminologie du
DBTG une clé Base de Données (database key). Cette dernière n’est pas une adresse
physique mais peut être vue comme une adresse symbolique désignant un numéro
d’ordre d’une occurrence dans le fichier.

Mode VIA ( déclaré avec LOCATION MODE IS VIA nom_d’un_set SET ) : Ce


mode précise que les occurrences du membre du SET dont le nom est spécifié dans
l’instruction doivent être regroupées physiquement avec l’occurrence du propriétaire à
laquelle elles sont liées dans ce SET. L’avantage du mode VIA est la possibilité
d’accéder en même temps à toutes les occurrences du membre qui sont liés à une
occurrence donnée du propriétaire. Ceci permet principalement de minimiser le
nombre d’accès disque. Il faut préciser que ce mode de localisation est valable
uniquement pour les enregistrement qui sont membre d’un SET et peut conduire à des
structures complexes.

Par exemple dans le schéma suivant :

R1 R3
L3

L2

L4
R2 R4

On peut spécifier que le mode de localisation de R2 est VIA le SET L2 et/ou que le
mode de localisation de R3 est VIA le SET L3 et/ou que le mode de localisation de
R4 est VIA le SET L4.

Ainsi, le SGBD devra tenir compte de tous ces choix qui peuvent alors conduire à des
structures très complexes puisqu’il s’agira toujours de respecter la proximité physique
des occurrences du membre avec l’occurrence d’un propriétaire.

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 42

⌦ L’instruction 8 < 08 DUPLICATES ARE NOT ALLOWED > précise que les occurrences
de l’enregistrement de type CLIENTS doivent posséder des valeurs distinctes de leur
attribut Num_Client. Ceci revient à dire qu’on n’autorise pas l’existence de deux occurrences
possédant la même valeur de l’attribut Num_Client. Cette clause doit être précisée lorsqu’on
a choisi un mode de localisation des occurrences consistant à utiliser une fonction de
hachage tel que celui expliqué dans l’instruction 7. Elle vise principalement d’éviter les
problèmes de collisions et leur gestion puisque l’application d’une fonction de hachage à
deux numéros de clients identiques donnera toujours une même adresse ce qui nécessiterait
la gestion de zones de débordement pour prendre en compte deux clients possédant un
même numéro. Ceci va donc compliquer inutilement la gestion de la base de données
puisqu’on sait d’avance que le cas de deux clients possédant un même numéro n’existe pas
dans la pratique.

⌦ L’instruction 9 (WITHIN COMMANDES_CLIENTS) a pour rôle d’indiquer au SGBD que


toutes les occurrences de l’enregistrement de type CLIENTS doivent être stockées dans la
zone (Area) ayant pour nom COMMANDES_CLIENTS sur le support de stockage. Dans
l’instruction 10 (IDENTIFER IS Num_Client ) on précise le nom de l’attribut qui constitue
la clé de l’enregistrement de type CLIENTS.

⌦ Les instruction de 11 à 17 permettent de définir les attributs de l’enregistrement de type


CLIENTS. Il s’agit de définitions approximativement analogues à celle qu’on retrouve dans
un programme COBOL (Voir le commentaire de la figure 2.5).

⌦ Les instructions 18 à 26 permettent de définir le type d’enregistrement FOURNISSEURS.


L’instruction 21 (WITHIN PRODUITS_FOURNISSEURS) précise de la même façon que
pour CLIENTS que toutes les occurrences de l’enregistrement de type FOURNISSEURS
doivent être stockées dans la zone (AREA) ayant pour nom PRODUITS_FOURNISSEURS
sur le support de stockage. On remarque que les accès aux occurrences du type
d’enregistrement FOURNISSEURS ne sont soumis à aucun type de protection comme c’était
le cas pour CLIENTS. Le mode de localisation spécifié pour les occurrences de
FOURNISSEURS est analogue à celui des CLIENTS et consiste à transformer une valeur de
l’attribut Num_Fourn (qui est déclarée comme clé à l’instruction 22) en une adresse sur le
support en appliquant à cette valeur la procédure de transformation ayant pour nom : HASH-
PROC2.

⌦ Les instructions 27 à 33 permettent de définir le type d’enregistrement PRODUITS. Le


mode de localisation spécifié pour les occurrences de ce type d’enregistrement consiste aussi
à transformer une valeur de l’attribut Num_Produit (qui est déclarée comme clé à
l’instruction 31) en une adresse sur le support en appliquant à cette valeur la procédure de
transformation ayant pour nom : HASH-PROC3. L’instruction 30 (WITHIN
PRODUITS_FOURNISSEURS) précise aussi que toutes les occurrences de l’enregistrement
de type PRODUITS doivent être stockées dans la zone (AREA) ayant pour nom
PRODUITS_FOURNISSEURS sur le support de stockage.

⌦ Les instructions 34 à 40 permettent de définir le type d’enregistrement COMMANDES qui


est rappelons le une entité d’intersection. On remarque qu’aucune distinction n’est faite par
le SGBD concernant cette particularité. Le mode de localisation spécifié à l’instruction 36 (
36 SYSTEM DEFAULT ) signifie que le choix est laissé au SGBD quant à la méthode qu’il
utilisera (séquentielle, directe, etc.). L’instruction 37 : (37 WITHIN
COMMANDES_CLIENTS) précise que toutes les occurrences de l’enregistrement de type
COMMANDES doivent être stockées dans la zone (Area) ayant pour nom

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 43

COMMANDES_CLIENTS sur le support de stockage.

Du fait que COMMANDES est une entité d’intersection ayant servi à transformer le
lien N:M qui existait initialement entre PRODUITS et CLIENTS, les instructions 39
et 40 permettent de lui rattacher deux attributs Num_Produit et Num_Client qui sont
rappelons-le les clés de ces entités. Afin d’éviter les problèmes de redondance
d’information du fait que les attributs Num_Produit et Num_Client ont déjà été définit
dans PRODUITS et dans CLIENTS respectivement, le SGBD donne la possibilité de
les déclarer dans COMMANDES comme attributs virtuels (Num_Produit IS
VIRTUAL dans l’instruction 39) en indiquant l’endroit précis où ils se trouvent
réellement (SOURCE IS Num_Produit OF OWNER OF COMMANDE_PRODUIT
dans l’instruction 39) qui signifie que la valeur de l’attribut Num_Produit d’une
occurrence de l’enregistrement COMMANDES membre du SET
COMMANDE_PRODUIT, est celle qui se trouve dans l’occurrence du propriétaire
(OWNER) du SET COMMANDE_PRODUIT. Comme on peut le constater, le
propriétaire de ce SET est bien l’enregistrement PRODUITS dans lequel se trouve
l’attribut réel Num_Produit. On pourrait faire les mêmes remarques pour l’attribut
Num_Client déclaré lui aussi comme virtuel et provenant d’une autre source. Par
contre, l’attribut Quantité est propre à l’enregistrement COMMANDES et n’est pas
virtuel. Il a été rajouté pour le besoin de l’application. Ainsi, cette technique
d’attributs virtuels a pour principal avantage d’éviter la redondance d’information tout
en permettant d’enrichir le modèle dans le but de pouvoir répondre à une diversité de
questions.

⌦ Les instructions 41 à 47 permettent de définir le type d’enregistrement PRIX qui est lui aussi
une entité d’intersection au même titre que l’est COMMANDES. Les mêmes remarques
faites pour COMMANDES s’appliquent ici aussi concernant aussi bien le mode de
localisation des occurrences et les attributs virtuels qui sont dans ce cas : Num_Produit et
Num_Fourn. Par contre, l’attribut Prix_Unité est propre à l’enregistrement PRIX et a été
rajouté pour le besoin de l’application.

2.2.4.3 Déclarations relatives à un SET


2.2.4.3.1 Noms caractérisant un SET

Un SET est défini par son nom qui est fourni au SGBD grâce à une instruction du style : SET
NAME IS Par exemple, les instructions 48, 58, 66 et 73 précisent les noms des quatre SET de notre
schéma et qui sont : FOURNISSEURS_PRIX, PRODUIT_PRIX, COMMANDE_PRODUIT,
COMMANDE_CLIENT.

On doit indiquer au SGBD le nom de l’enregistrement propriétaire du SET ainsi que celui de
l’enregistrement membre grâce aux deux instructions : < OWNER IS ...... > et < MEMBER IS
....... > respectivement. Par exemple, les instructions 51 et 52 indiquent que pour le SET
FOURNISSEURS_PRIX, l’enregistrement propriétaire est FOURNISSEURS < 51 OWNER IS
FOURNISSEURS > et l’enregistrement membre est PRIX < 52 MEMBER IS PRIX >.

2.2.4.3.2 Ordre d’insertion des occurrences du membre d’un SET

Lors de la déclaration d’un SET, on doit préciser l’ordre dans lequel on veut maintenir les
occurrences du membre lorsqu’elles sont rattachées à une occurrence du propriétaire. Ceci se fait par
le biais d’une instruction du LDD de la forme < ORDER IS ........>. Différents modes sont proposés
par les SGBD CODASYL dont les principaux sont :

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 44

NEXT : Il s’agit d’insérer la nouvelle occurrence du membre à la position suivant celle de


l’occurrence courante (ou active) connue bien sûr par le SGBD. Il faut préciser que
l’occurrence active peut être soit de type membre (i.e. tout élément de la liste circulaire sauf
la tête de cette liste). Dans ce cas il s’agira d’une insertion classique d’un élément dans une
liste à partir d’une position courante. Elle peut aussi être de type propriétaire auquel cas elle
est effectivement la tête de cette liste et la nouvelle occurrence du membre sera donc insérée
en première position relativement aux occurrences du membre qui existent déjà.

Les instruction 67 et 74 du programme (ORDER IS NEXT ) permettent de


préciser au SGBD qu’on choisit cet ordre de rangement. C’est un ordre purement
séquentiel qui ne se soucie pas d’un tri éventuel des occurrences du membre selon
un quelconque critère. Ce sera donc au programmeur d’aller insérer lui même
toute nouvelle occurrence du membre à la position qu’il veut puisqu’il possède
les moyens techniques (instructions du DML) pour rendre active une occurrence
d’un membre d’un SET (un élément d’une liste réalisant ce SET) ou une
occurrence du propriétaire de ce SET (tête d’une liste réalisant ce SET ) afin de
fixer la position d’insertion.

FIRST : Il s’agit d’insérer toute nouvelle occurrence du membre en première position


relativement aux occurrences du membre qui existent déjà. Avec ce mode, l’insertion se fera
relativement à l’occurrence du propriétaire qui constitue la tête de liste. Cette dernière
pointera donc directement sur la nouvelle occurrence du membre et le reste du chaînage sera
mis à jour.

LAST : Il s’agit d’insérer toute nouvelle occurrence du membre en dernière position


relativement aux occurrences du membre qui existent déjà (i.e. en fin de liste).

PRIOR : Il s’agit d’insérer toute nouvelle occurrence du membre à la position précédant


celle de l’occurrence active connue bien sûr par le SGBD. Dans le cas où cette occurrence
est de type propriétaire (tête de liste) la nouvelle occurrence du membre sera insérée en
dernière position relativement aux occurrences existant déjà (i.e. en fin de liste)

SORTED : Il s’agit de maintenir les occurrences du membre triées selon un critère qu’on
spécifie. Ce choix se fait grâce à la clause ORDER IS SORTED (instruction 49 et 59 par
exemple) qui permet de préciser au SGBD qu’on veut maintenir dans un ordre trié les
occurrences du membre. Comme dans toute opération de tri, il faut préciser l’ordre du tri
(croissant, décroissant) ainsi que le ou les attributs sur lesquels on effectuera ce tri. Par
exemple l’instruction : 54 ASCENDING KEY IS Num_Fourn indique au SGBD de trier
par ordre croissant selon l’attribut Num_Fourn les occurrences du membres liés à une
occurrence du propriétaire qui est FOURNISSEURS. L’attribut de tri Num_Fourn est bien
sûr celui de l’enregistrement membre à savoir : PRIX et pour lequel Num_Fourn a bien
été déclaré comme attribut et ce même s’il est déclaré virtuel. De même l’instruction : 62
ASCENDING KEY IS Num_Produit, Prix_Unité indique au SGBD de trier par ordre
croissant selon les deux attribut Num_Produit et Prix_Unité les occurrences du membre qui
sont liées à une occurrence du propriétaire de ce SET à savoir : PRODUITS. Les deux
attributs de tri Num_Produit et Prix_Unité sont ceux définis dans l’enregistrement membre
qui est aussi : PRIX . Il faut remarquer que chaque SET est indépendant de l’autre même
s’ils ont en commun l’enregistrement membre PRIX. Au niveau physique, ils seront réalisés
par deux ensembles de listes circulaires complètement distinctes. C’est pour cela que les
déclarations relatives à un SET n’ont pas d’effet sur celles d’un autre SET.

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 45

2.2.4.3.3 Duplication des occurrences du membre d’un SET

L’autorisation de dupliquer ou non des occurrences de l’enregistrement membre d’un SET dans
une liste circulaire correspondant à une réalisation de ce SET doit être spécifiée grâce à une instruction
du LDD de la forme : DUPLICATES ARE [NOT] ALLOWED. Il s’agit en fait de préciser au
SGBD si deux éléments d’une liste circulaire réalisant une occurrence du SET peuvent ou non avoir
des clés identiques. Ces deux éléments étant deux occurrences du membre ; par exemple de PRIX si
on se réfère au SET FOURNISSEURS_PRIX ou PRODUIT_PRIX ( instructions 48 à 65 ), et qui
ont tous deux comme membre l’enregistrement PRIX, il s’agira donc de préciser au SGBD si on
autorise ou non la présence de deux occurrences de PRIX ayant deux clés identiques et ce dans
l’ensemble des listes circulaires réalisant le SET en question. Dans le cas ou cette clé n’a pas été
précisée au niveau de la définition de l’enregistrement membre, il s’agira de la clé par défaut de toute
entité c’est à dire l’ensemble de ses attributs ce qui est le cas pour l’enregistrement membre PRIX de
notre exemple pour lequel aucune clé n’a été spécifiée.

2.2.4.3.4 Modes d’implantation d’un SET

On peut indiquer au SGBD le mode d’implantation qu’on désire utiliser pour réaliser un SET. Le
plus courant est celui de la liste chaînée (liste circulaire) que nous avons vu jusqu’à maintenant et qui
est généralement le mode par défaut. Un tel choix est indiqué par une instruction du style < MODE IS
CHAIN > comme il a été fait aux instructions 50, 68 et 75 du programme. Une autre possibilité est
celle qu’on appelle le mode VIA est qui consiste à regrouper physiquement toutes les occurrences du
membre a proximité de l’occurrence du propriétaire avec lequel elles sont liées par le SET. On ne
sépare donc pas l’ordre logique des occurrences du membre de leur ordre physique.(Voir l’explication
de LOCALISATION MODE IS VIA ..... donnée plus haut ). Enfin, il est aussi possible d’utiliser un
index contenant des pointeurs sur les occurrences du membre d’un SET qui sont liées à une occurrence
du propriétaire de ce SET. Ce type d’implantation est spécifié par une instruction du style < MODE
IS INDEX >. A chaque occurrence du propriétaire correspondra donc une table d’index contenant les
adresses des occurrences du membre qui lui sont associées par le SET.

2.2.4.3.5 Insertion et Rétention dans un SET

Au moment de la description d’un SET au niveau du schéma, on doit spécifier comment se fera
l’insertion d’une occurrence d’un enregistrement membre de ce SET. On doit aussi spécifier le degré
de liberté (ou rétention) d’une occurrence d’un enregistrement membre de ce SET vis à vis de
l’occurrence du SET (la liste circulaire) dans laquelle elle a été initialement insérée.

L’insertion d’une occurrence d’un enregistrement membre à une réalisation du SET (à une
liste circulaire) peut se faire soit explicitement grâce à l’instruction (< INSERTION IS
MANUAL > ), soit implicitement grâce à l’instruction ( < INSERTION IS AUTOMATIC
>. Dans le premier cas, cela signifie que l’insertion sera faite explicitement par le
programmeur en utilisant une ou plusieurs instructions du langage de manipulation de
données (ex : l’instruction CONNECT). C’est le cas des SET PRODUITS_PRIX,
COMMANDE_PRODUIT et COMMANDE_CLIENT (instructions 61, 70 et 77
respectivement). Par contre dans le second cas, cela signifie que lorsqu’une occurrence d’un
enregistrement membre est créée pour la première fois, le SGBD ira la placer
automatiquement dans l’occurrence du SET approprié (inséré dans une liste circulaire). C’est
le cas du SET FOURNISSEUR_PRIX (instruction 52 du programme).

La rétention quant à elle indique le degré de liberté dont dispose les occurrences du membre
d’un SET. Ce degré est indiqué par l’une des options suivantes : FIXED, MANDATORY
ou OPTIONAL

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 46

FIXED : signifie qu’une fois rattaché à une réalisation d’un SET (inséré dans une
liste circulaire), une occurrence du membre de ce SET ne peut exister dans la base de
données autrement que rattaché à cette liste. Elle ne peut donc pas quitter la liste
circulaire dans laquelle elle se trouve. Cette liste est identifiée par sa tête qui est une
occurrence de l’enregistrement propriétaire du SET.

MANDATORY : signifie qu’une fois rattaché à une réalisation d’un SET (inséré dans
une liste circulaire réalisant ce SET), une occurrence du membre de ce SET ne peut
exister dans la base de données autrement que membre de ce SET. Dans ce cas, elle
peut seulement changer d’une occurrence du Propriétaire à une autre mais en restant
dans le même SET (i.e. peut seulement changer de liste circulaire parmi celles
réalisant ce SET).

OPTIONAL : signifie que l’occurrence de l’enregistrement membre est libre d’être


ou non rattachée à une occurrence de l’enregistrement Propriétaire du SET. Elle peut
exister dans la base de données sans appartenir à l’une des listes circulaires réalisant
ce SET.

Les exemples suivants permettent de mieux éclaircir la notion de rétention dans un SET
et les options qui peuvent la caractériser :

Le SET Est_Composée_De sera déclaré avec l’option


VILLES RETENTION IS FIXED car une occurrence de MAISONS
(i.e. une maison particulière) sera toujours rattachée à la même
Est_Composée_De occurrence de VILLES dans le SET Est_Composée_De (on ne
peut pas déplacer physiquement une maison d’une ville vers une
MAISONS autre !)

Le SET Expose sera déclaré avec l’option RETENTION IS


MUSEES MANDATORY car une occurrence de STATUES (i.e. une
statue particulière) peut être déplacée d’un musée à un autre pour
Expose y être exposée par exemple. Elle peut donc changer d’occurrence
du propriétaire MUSEES mais la statue reste liée dans le même
STATUES
SET Expose avec MUSEES (on peut déplacer physiquement
une statue d’un musée vers un autre !)

Le SET Emprunte sera déclaré avec l’option RETENTION IS


EMPRUNTEURS OPTIONAL car un livre peut être emprunté par un emprunteur
(étudiant, enseignant, etc.) qui le restitue par la suite et ce livre
Emprunte
ne n’est pas de nouveau emprunté. Donc il figure dans la B.D.
sans appartenir à une occurrence du lien Emprunte (i.e. à une
LIVRES des listes circulaires réalisant ce lien).

Figure 2.16 : La notion de rétention dans un SET

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 47

2.3 Notion de sous schéma dans le modèle réseau

2.3.1 Caractéristiques générales

Un sous schéma ou vue est un sous ensemble du schéma conceptuel. Il correspond au niveau
externe de description d’une base de données et dont le rôle est de permettre aux programmes
d’application de ne voir que la partie de la base de données dont ils ont besoin. La définition d’un sous
schéma à partir du schéma conceptuel de la base de données obéit à un ensemble de règles qui varient
d’un SGBD à un autre. Néanmoins, en se référant aux propositions du DBTG, on peut énumérer la
liste non exhaustive de règles suivantes :

On peut définir un nombre quelconque de sous schémas pour un schéma conceptuel donné
un sous schéma peut être partagé par plusieurs programmes d’application
dans la description d’un sous schéma, on peut ne pas déclarer :

une ou plusieurs AREA


un ou plusieurs enregistrements (Record)
un ou plusieurs SET
un ou plusieurs attributs d’un enregistrement

Dans un sous schéma, on peut renommer une AREA, un enregistrement, un SET ou un


attribut. Ceci permet par exemple d’utiliser des synonymes pour les noms déclarés dans le
schéma (voir le programme de description plus loin).
L’ordre de déclaration des attributs d’un enregistrement qui a été suivi dans la description du
schéma peut ne pas être respecté dans le sous schéma
Le type d’un attribut peut être changé

Un sous schéma sera donc décrit grâce à un programme en utilisant le langage de description de
données offert par le SGBD.

2.3.2 Exemple de description d’un sous schéma

Considérons le sous schéma suivant obtenu à partir du schéma conceptuel de la figure 2.14 et dans
lequel nous avons gardé uniquement les enregistrements (Records) : CLIENTS, COMMANDES et
PRODUITS ainsi que les SETS : COMMANDE_CLIENT et COMMANDE_PRODUIT

CLIENTS

COMMANDE_CLIENT

COMMANDE_PRODUIT
PRODUITS COMMANDES

Figure 2.17 : Exemple de sous-schéma

Nous donnons ci-après l’allure du programme de description de ce sous schéma selon la


philosophie du groupe CODASYL. Ce programme est proposé dans le but d’expliquer cette
philosophie et il ne s’agit donc pas d’un programme respectant à la lettre la syntaxe du LDD proposé

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 48

par le groupe comme une extension au langage COBOL. Nous tenons à souligner que le plus
important est de comprendre la philosophie du passage d’un schéma conceptuel à un sous schéma dans
le cas du modèle réseau proposé par le DBTG et que nous avons synthétisé à travers les règles
énumérées plus haut.

Les lignes du programme ont été numérotées L1, L2, ... pour qu’il n’y ait pas de confusion avec les
numéros de niveau qui apparaissent dans la section de déclaration des RECORD.

(L1) SUBSCHEMA NAME IS VUE1 OF SCHEMA NAME GESTION_VENTES


(L2) RENAMING SECTION
(L3) DATA NAME Num_Client IN SCHEMA IS CHANGED TO Numéro
(L4) SET NAME COMMANDE_PRODUIT IN SCHEMA IS CHANGED TO
PROD_COMMANDES
(L5) RECORD SECTION
(L6) 01 CLIENTS
(L7) 02 Numéro PICTURE 9(6).
(L8) 02 Nom_Client PICTURE A(12)
(L9) 01 PRODUITS
(L10) 02 Num_Produit PICTURE 9(4).
(L11) 01 COMMANDES
(L12) 02 Quantité PICTURE 9(3)
(L13) 02 Num_Produit PICTURE 9(4).
(L14) 02 Num_Client PICTURE 9(6).
(L15) SET SECTION
(L16) COPY PROD_COMMANDES.
(L17) COPY COMMANDE_CLIENT.
(L18) END.

Figure 2.18 : Description d’un sous schéma avec un LDD CODASYL

2.4 Langage de manipulation de données dans un modèle réseau

Lors de la description du schéma conceptuel, un certain nombre de contraintes seront spécifiées


telles que le mode d’insertion dans un SET qui peut être automatique ou manuel, le degré de liberté ou
rétention des occurrences d’un enregistrement membre dans un SET. Ces contraintes ont pour but de
permettre au programmeur de détecter facilement les erreurs mais aussi d’améliorer la cohérence de la
base de données. En effet, lorsqu’on précise par exemple lors de la déclaration d’un SET que la
rétention est de type FIXED, l’insertion d’une occurrence de l’enregistrement membre de ce SET dans
la base de données rendra celle-ci incohérente tant que cette occurrence n’aura pas été rattaché à une
occurrence de l’enregistrement propriétaire de ce SET (i.e. insérée dans une liste circulaire réalisant ce
SET). Les contraintes imposées sur le schéma vont donc permettre au SGBD d’autoriser ou non une
opération sur la base de données, de déclencher automatiquement d’autres opérations pour maintenir la
cohérence de la base.

Avant d’introduire la liste des opérations qui nous paraissent suffisantes pour comprendre la
philosophie générale du langage de manipulation de données d’un SGBD réseau, il est nécessaire de
préciser que la communication entre les programmes d’applications et un SGBD réseau se fait
principalement par le biais d’une zone d’échange appelée User Working Area (UWA). Dans cette
zone, un certain nombre de variables globales sont prédéfinies et rendues accessibles aux programmes
afin de minimiser le nombre de paramètres à passer lors des appels au SGBD. Deux sortes de variables
sont prédéfinies :

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 49

Variables de type enregistrement : à chaque enregistrement déclaré dans le schéma


correspond une variable de même nom qui sert de zone d’échange entre le programme et
la base de données. Avant d’être écrite dans la base, une occurrence d’un enregistrement
doit d’abord être préparée dans cette zone (initialisation de ses attributs). De même
qu’une occurrence d’un enregistrement est d’abord lue dans cette zone pour pouvoir être
traitée par le programme.

Variables de type POINTEUR : ce sont des variables qui contiennent des adresses
d’occurrences d’enregistrements dans la base de données. Chaque pointeur sert donc à
mémoriser l’adresse de la dernière occurrence d’un enregistrement à laquelle le
programme a eu accès. Tous ces pointeurs sont mis à jour en permanence par le SGBD.
Les trois types de pointeurs les plus importants sont :

Un pointeur courant associé au programme : C’est un pointeur qui désigne toujours


l’adresse de la dernière occurrence de l’enregistrement à laquelle le programme a eu
accès quelque soit le type de l’enregistrement. Cette adresse peut donc être celle de
l’occurrence d’un enregistrement propriétaire dans un SET ou bien celle d’un
enregistrement membre dans un SET ;

Des pointeurs courants associés aux enregistrements : Il en existe un par


enregistrement. Pour un enregistrement donné, ce pointeur repère toujours le dernière
occurrence de cet enregistrement à laquelle le programme a eu accès ;

Des pointeurs courants associés aux Sets : Il en existe un par SET. Pour chaque
SET, ce pointeur repère la dernière occurrence à laquelle le programme a eu accès.
Elle peut être soit une occurrence de l’enregistrement propriétaire du SET, soit une
occurrence de l’enregistrement membre du SET;

2.4.1 Opérations principales du LMD d’un SGBD réseau

Les opérations principales du LMD sont les suivantes :

FIND :

cette opération est la plus importante. Elle permet au programmeur de naviguer dans la
base de données en tenant compte de sa structure (i.e. au grès des chemins d’accès). Elle
permet de localiser ou se positionner sur une occurrence d’un enregistrement sans la
délivrer au programme. Les deux formes les plus caractéristiques de cette opération sont :

Recherche directe d’une occurrence d’un enregistrement :

Recherche d’une occurrence dont on connaît l’adresse et qu’on a mémorisée


dans une variable du programme :

FIND < Nom d’un Enregistrement > DB-KEY IS < Nom d’une Variable >

Recherche d’une occurrence d’un enregistrement dont la localisation se fait par


une fonction de hachage (spécifiée lors de la déclaration du schéma) :

FIND ANY < Nom d’un Enregistrement >

Dans le cas ou on a autorisé la duplication des occurrences (DUPLICATES ARE

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 50

ALLOWED), les autres occurrences seront obtenues par :

FIND DUPLICATE < Nom d’un Enregistrement >

Cette opération entraîne la mise à jour du pointeur courant associé à


l’enregistrement en question

Parcours d’une réalisation d’un SET (une liste circulaire):

Comme à chaque SET est associé un pointeur courant qui repère l’occurrence d’un
enregistrement membre ou bien celle d’un propriétaire de ce SET, les opérations pour
parcourir une réalisation d’un SET (une liste circulaire) sont :

Recherche d’une occurrence de l’enregistrement propriétaire (recherche de la


tête de liste) :

FIND OWNER WITHIN < Nom d’un SET >

Recherche de la première occurrence de l’enregistrement Membre :

FIND FIRST < Nom d’un Enregistrement> WITHIN < Nom d’un SET >

Recherche de l’occurrence suivante de l’enregistrement Membre :

FIND NEXT < Nom d’un Enregistrement> WITHIN < Nom d’un SET >

Recherche de la première occurrence de l’enregistrement Membre dont certains


attributs vérifient un critère donné :

FIND < Nom d’un Enregistrement > WITHIN < Nom d’un SET >
USING < Liste Attributs >

GET :

cette commande permet au programme de lire l’occurrence courante d’un enregistrement


et dont l’adresse se trouve dans la variable de type pointeur courant associé à cet
enregistrement. L’occurrence sera lue dans la zone d’échange identifiée par la variable
globale associée à l’enregistrement en question (voir l’explication du rôle de ces variables
donnée plus haut)

le format de cette commande est généralement :

GET < Nom d’un Enregistrement>

Par exemple GET FOURNISSEURS va permettre de lire l’occurrence de


l’enregistrement FOURNISSEURS dont l’adresse est indiquée par le pointeur
courant associé à cet enregistrement .

STORE :

cette commande permet au programme d’insérer une nouvelle occurrence d’un


enregistrement dans la base. Elle nécessite la préparation de l’occurrence dans la zone

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 51

d’échange identifiée par la variable globale associée à l’enregistrement en question.


L’occurrence sera insérée à l’adresse se trouvant dans la variable de type pointeur courant
associé à cet enregistrement.

le format de cette commande est généralement :

STORE < Nom d’un Enregistrement>

Par exemple STORE FOURNISSEURS va permettre d’insérer l’occurrence de


l’enregistrement FOURNISSEURS à l’adresse contenue dans la variable de type
pointeur courant associé à cet enregistrement .

MODIFY :

cette commande permet au programme de modifier une occurrence d’un enregistrement


se trouvant déjà dans la base. Modifier une occurrence signifie changer la valeur d’un ou
de plusieurs attributs de cette occurrence. Cette opération nécessite d’abord la
préparation de la version modifiée de l’occurrence et ceci dans la zone d’échange
identifiée par la variable globale associée à l’enregistrement en question. Il faudra ensuite
initialiser la variable de type pointeur courant associé au programme avec l’adresse de
l’occurrence à modifier puis exécuter l’opération proprement dite.

le format de cette commande est généralement :

MODIFIY < Nom d’un Enregistrement >

Par exemple MODIFY PRODUIT va permettre de remplacer l’occurrence de


l’enregistrement PRODUIT dont l’adresse est contenue dans la variable de type
pointeur courant associé au programme avec l’occurrence préparé dans la zone
d’échange est identifiée par la variable globale associée à l’enregistrement en
question.

ERASE :

cette commande permet de supprimer l’occurrence d’un enregistrement dont l’adresse se


trouve dans la variable de type pointeur courant associé au programme. Si cette
occurrence est propriétaire dans un ou plusieurs SET dont la rétention est de type FIXED,
il y aura suppression de toutes les occurrences de l’enregistrement membre de chaque
SET. Dans le cas où cette occurrence est propriétaire dans un ou plusieurs SET dont la
rétention est optionnelle (OPTIONAL), il y aura déconnexion des occurrences de
l’enregistrement membre de chacun des SET (les occurrences ne forment plus une liste
circulaire puisque le propriétaire qui en est la tête est supprimé). Enfin si l’occurrence à
supprimer est celle d’un enregistrement membre dans un ou plusieurs SET, il y aura
déconnexion de cette occurrence de toutes les occurrences ou réalisations des SET ( listes
circulaires) où elle apparaît (mise à jour du chaînage dans chaque liste circulaire réalisant
chacun des ces SET).

le format de cette commande est généralement :

ERASE < Nom d’un Enregistrement>

Par exemple ERASE FOURNISSEURS va permettre de supprimer l’occurrence

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 52

courante de l’enregistrement FOURNISSEURS dont l’adresse est contenue dans la


variable de type pointeur courant associé à cet enregistrement en satisfaisant les
contraintes précisées ci-dessus.

CONNECT :

cette commande permet d’insérer manuellement l’occurrence d’un enregistrement se


trouvant déjà dans la base de données comme membre dans une réalisation ou occurrence
d’un SET (insertion d’un élément dans une liste circulaire). Pour cela, il faudra au
préalable choisir l’occurrence du SET dans laquelle on veut faire l’insertion. Ceci devra
être fait en initialisant le pointeur courant associé à ce SET soit avec l’adresse d’une
occurrence de l’enregistrement propriétaire soit avec l’adresse de l’occurrence de
l’enregistrement membre. L’une ou l’autre de ces adresses permet de désigner sans
ambiguïté une seule occurrence de ce SET(i.e. une seule liste circulaire). La deuxième
opération à faire est d’initialiser le pointeur courant associé au programme avec l’adresse
de l’occurrence de l’enregistrement qu’on veut insérer dans la liste circulaire puis
exécuter l’opération de connexion (i.e. établir le chaînage). La connexion se fera bien sûr
en respectant les déclarations relatives au SET(ordre à respecter, rétention, etc.).

le format de cette commande est généralement :

CONNECT < Nom d’un Enregistrement > TO < Nom d’un SET >

Par exemple CONNECT COMMANDES TO COMMANDE_CLIENT va


permettre d’insérer l’occurrence de l’enregistrement COMMANDES dont l’adresse
est contenue dans la variable de type pointeur courant associé au programme (et non à
l’enregistrement COMMANDES !) dans l’occurrence courante du SET
COMMANDE_CLIENT (liste circulaire) dont on connaît soit l’adresse d’une
occurrence du propriétaire (tête de cette liste) soit l’adresse d’une occurrence du
membre (un des éléments composant cette liste). Cette adresse est contenue dans la
variable de type pointeur courant associé au SET COMMANDE_CLIENT.

La commande CONNECT est valable uniquement pour un SET pour lequel on a


déclaré dans le schéma que le mode d’insertion est manuel. Dans le cas d’un SET
déclaré avec un mode d’insertion automatique, c’est le SGBD qui doit connecter
automatiquement une occurrence du membre à une occurrence du propriétaire.
Pour que le SGBD puisse retrouver l’occurrence de ce propriétaire, on doit le lui
spécifier au niveau du schéma grâce à la clause (Voir aussi le programme de
description) :

SET SELECTION IS THRU <Nom d’un SET> OWNER IDENTIFIED BY ......

DISCONNECT :

cette commande permet de supprimer logiquement l’occurrence d’un enregistrement se


trouvant déjà dans la base de données comme membre dans une réalisation ou
occurrence d’un SET (suppression d’un élément d’une liste circulaire sans le supprimer
physiquement de la base de données) . Pour la suppression logique, il n’est pas nécessaire
de choisir au préalable l’occurrence du SET dans laquelle on veut faire la suppression car
on sait que l’occurrence à supprimer n’appartient qu’à une seule liste réalisant le SET. Il
suffit donc d’initialiser le pointeur courant associé au programme avec l’adresse de
l’occurrence de l’enregistrement qu’on veut supprimer puis exécuter l’opération de

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 53

déconnexion (i.e. met à jour le chaînage). La déconnexion n’est pas autorisée si la


rétention du SET a été déclarée fixe (RETENTION IS FIXED).

le format de cette commande est généralement :

DISCONNECT < Nom d’un Enregistrement > FROM < Nom d’un SET >

Par exemple DISCONNECT PRODUIT FROM COMMANDE_PRODUIT va


permettre de supprimer l’occurrence de l’enregistrement PRODUIT dont l’adresse est
contenue dans la variable de type pointeur courant associé au programme de la liste
circulaire réalisant le SET COMMANDE_PRODUIT et à laquelle elle appartient.

2.4.2 Remarques

Toutes les opérations que nous venons de voir, vont servir de support pour l’écriture d’un
programme d’application qui est généralement écrit en COBOL. Le plus important à retenir ce n’est
pas la structure d’un programme ni la syntaxe exacte du langage. C’est plutôt de comprendre l’aspect
navigationnel du LMD d’un SGBD réseau. Comme nous pouvons le constater l’écriture d’un
programme tient compte des chemins d’accès et le programmeur connaît à tout moment l’endroit
précis où il se trouve dans la base grâce aux différents pointeurs qui sont comme nous l’avons dit, mis
à jour en permanence par le SGBD.

3. Le modèle hiérarchique

3.1 Présentation générale

Afin de bien faire ressortir les caractéristiques essentielles du modèle hiérarchique nous utiliserons
dans la suite de notre présentation une terminologie très proche de celle du SGBD IMS développé par
IBM vers les années 1968 et basé sur ce type de modèle de données.

Les éléments de base du modèle hiérarchique sont les enregistrements logiques appelés Segments
dans IMS. Un segment est défini par un nom et un ensemble d’attributs appelés Fields dans IMS et
constitue l’unité d’échange entre la base de données et les programmes d’application. C’est
l’équivalent du RECORD vu avec le modèle réseau.

La notion de lien ou SET telle que nous l’avons vue dans le modèle réseau n’existe pas. Un lien
entre deux segments du modèle hiérarchique n’est donc pas défini explicitement par des instructions
du langage de définition de données de manière à part comme ce fût le cas dans le modèle réseau.
Dans le modèle hiérarchique seule existe la relation PARENT-ENFANT qui est spécifiée au moment
de la description d’un segment en indiquant pour un segment donné le nom de son segment PARENT
s’il en possède.

3.2 Caractéristiques principales d’un modèle hiérarchique

Un modèle hiérarchique est un modèle de type diagramme de structures de données ou de Bachman


dans lequel :

Tous les liens entre les entités (segments) sont de type 1:N
Sur chaque entité ou segment n’arrive qu’un seul lien (arc)
De chaque entité ou segment peuvent partir autant de lien (arcs) qu’on veut
Il existe une entité ou segment particulier appelé racine sur lequel n’arrive aucun lien

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 54

(arc).

Les exemples suivants vont aider à savoir comment distinguer un modèle conforme au modèle
hiérarchique d’un autre qui ne l’est pas :

C
Ce modèle n’est pas conforme au modèle hiérarchique à cause
des deux arcs qui arrivent sur le segment D
D E

A
Ce modèle n’est pas conforme au modèle hiérarchique car il ne
possède pas de segment Racine sur lequel n’arrive aucun arc.
B

C Ce modèle est conforme au modèle hiérarchique car il possède un


G
segment Racine qui est C et sur chaque segment n’arrive qu’un
D E F seul arc.

C
Ce modèle n’est pas conforme au modèle hiérarchique à cause
des deux arcs qui arrivent sur le segment E
D E F

Figure 2.19 : Exemples de modèles hiérarchiques

3.3 Les liens N:M dans un modèle hiérarchique

De part sa définition, le modèle hiérarchique n’accepte pas de lien N:M entre deux entités ni de
structure en réseau. Donc si la modélisation produit un modèle de données dans lequel existe un ou
plusieurs lien N:M, ou bien une ou plusieurs entités sur lesquelles arrivent plus d’un lien (arc), il
faudra le transformer pour le conformer aux caractéristiques du modèle hiérarchique.

La transformation d’un lien N:M dans le cadre du modèle hiérarchique repose essentiellement sur
la duplication des entités et la création d’entité d’intersection.

3.3.1 Transformation par duplication des entités

Considérons l’exemple suivant du lien N:M entre deux entités ETUDIANTS et MODULES :

ETUDIANTS ETUDIANTS ETUDIANTS

N:M 1:N 1:N

MODULES MODULES MODULES

Figure 2.20 : Transformation d’un lien N:M par duplication des entités

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 55

La duplication des entités consiste à transformer le lien N:M en deux liens 1:N en créant des
copies des entités impliquées dans le lien. Dans l’exemple ci-dessus, on a transformé le lien N:M en
deux liens 1:N l’un allant de l’entités ETUDIANT vers l’entité MODULES et l’autre allant de l’entités
MODULES vers l’entité ETUDIANTS. Pour ce faire, cela a nécessité de dupliquer les deux entités
afin de pouvoir représenter les deux liens 1:N en restant conforme avec le modèle hiérarchique. Au
niveau physique, on aura un ensemble d’arbres réalisant le premier lien 1:N dont la racine est
ETUDIANTS et un autre ensemble d’arbres réalisant le second lien 1:N dont la racine est MODULES.

E1 E2 E3

MOD1 MOD2 MOD1 MOD7 MOD4 MOD3 MOD5

MOD1 MOD2 MOD3 MOD4 MOD5

E1 E2 E1 E2 E3 E2 E3

Figure 2.21 : Arbres réalisant les liens 1:N entre les deux entités

Comme on le voit, cette méthode engendre une redondance d’information avec toutes les
conséquences qui s’en suivent (perte d’espace, risques d’incohérence des données, ...)

3.3.2 Transformation par création d’entités d’intersection

Il est aussi possible de transformer un lien N:M entre deux entités en deux liens 1:N grâce à la
création d’une nouvelle entité dite entité d’intersection. On obtient généralement un réseau qui devra
être de nouveau transformé en arborescence par duplication d’entité.

⌦ Reprenons l’exemple du lien N:M entre les deux entités ETUDIANTS et MODULES :

Création d’une entité Duplication de l’entité d’intersection


d’intersection
On obtient deux modèles hiérarchiques
le modèle obtenu est un modèle chacun avec une racine (2 PDB )
Réseau

ETUDIANTS MODULES ETUDIANTS MODULES

1:N 1:N 1:N 1:N

N°_ET N°_MOD N°_ET N°_MOD N°_ET N°_MOD

Figure 2.22 : Transformation d'un lien N:M par création d’entités d’intersection

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 56

Afin d’éviter la duplication des occurrences des entités dans les deux bases physiques, on peut
utiliser la techniquedite des entités virtuelles. Celle-ci consiste à définir réellement dans l’une des
PDB l’entité d’intersection et à la déclarer comme entité virtuelle dans l’autre PDB (Voir le
programme de description de l’exemple illustratif). On aura le schéma suivant :

ETUDIANTS MODULES

N°_ET N°_MOD

Figure 2.23 : Utilisation de la technique de l’entité virtuelle

La flèche en pointillés allant de MODULES vers l’entité d’intersection indique que cette dernière
est un fils logique de MODULES. Elle sera déclarée en tant que tel au moment de la description du
PDB contenant uniquement l’entité MODULES comme entité (segment) réel.

La flèche en pointillés gras allant de l’entité d’intersection vers l’entité MODULES indique que
cette dernière est un parent logique de l’entité d’intersection. Elle sera déclarée en tant que tel au
moment de la description du PDB composé de l’entité ETUDIANTS et de l’entité d’intersection.

3.4 Schéma conceptuel d’une Base de données hiérarchique

Une base de données hiérarchique peut être vue au niveau conceptuel comme un ensemble d’arbres
dont chacun est composé d’entités ou segments et de liens de type 1:N et respectant les
caractéristiques du modèle hiérarchique énoncées plus haut. Chaque arbre appelé aussi un PDB
(Physical Data Base) dans IMS sera décrit indépendamment grâce à un programme de description
appelé une DBD (Data Base Description program) en utilisant le langage de description de données
offert par le SGBD.

Ainsi, le schéma conceptuel d’une base de données hiérarchique peut comporter une ou plusieurs
PDB distinctes, dont chacune sera décrite par son propre programme de description ou DBD.

3.5 Description d’un schéma dans le cas d’un SGBD Hiérarchique

3.5.1 Eléments à décrire pour un schéma

Compte tenu de la structure du schéma conceptuel d’une base de données hiérarchique, sa


description si on se réfère à la terminologie du SGBD IMS va comprendre pour chaque PDB
composant le schéma :

La déclaration du nom du PDB qui servira au SGBD de la distinguer parmi toutes les PDB
une ou plusieurs déclarations de segments, chaque segment étant caractérisé par son nom, ses
attributs (ou FIELDS) et le nom de son segment PARENT.

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 57

3.5.2 Exemple illustratif

Si on considère la base de données hiérarchique de la figure 2.24, celle-ci est composée de deux
(02) PDB (Physical Data Base) . La première PDB est composée des segments : DEPARTEMENTS,
EMPLOYES, ENFANTS et VEHICULES. La seconde PDB est composée des deux segments :
VILLES et ECOLES.

Pour le besoin de l’application, il a été jugé utile de rajouter un arc allant du segment ECOLES de
la seconde PDB vers le segment ENFANTS de la première PDB. Ce lien permettra par exemple de
répondre à une question du style : » Quels sont les Enfants inscrits dans une école X«. Cependant, on
remarque qu’il n’est pas possible de rajouter un tel lien directement parce que on aurait dans ce cas
une contradiction avec les spécifications du modèle hiérarchique puisque le segment ENFANTS de la
première PDB posséderait alors deux liens (arcs) entrants : l’un provenant du segment EMPLOYES
de la même PDB et l’autre du segment ECOLES de la seconde PDB et on aurait alors non plus un
modèle hiérarchique mais plutôt un modèle réseau.

Une première solution consisterait à dupliquer le segment ENFANTS en le redéfinissant dans la


seconde PDB. Cette solution engendre une redondance de l’information avec toutes les conséquences
qu’on connaît. La deuxième solution est celle de l’utilisation du concept de segment virtuel qui
consiste à définir dans la seconde PDB, le segment ENFANTS appartenant à la première PDB, non
pas comme fils réel du segment ECOLES mais comme fils logique ou virtuel en sachant qu’il est
défini explicitement dans une autre PDB. On devra aussi préciser au moment de la description du
segment ENFANTS qu’il possède un PARENT LOGIQUE qui est le segment ECOLES défini dans
une autre PDB. Ce lien est matérialisé sur la figure par une flèche en trait pointillé.

Le schéma conceptuel de notre base de données serait donc le suivant :

DEPARTEMENTS
VILLES

VEHICULES EMPLOYES ECOLES

ENFANTS

PDB N° 1 PDB N° 2

Figure 2.24 : Schéma conceptuel d’une B.D. Hiérarchique composé de deux PDB

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 58

3.5.3 Programmes de description du schéma

Nous donnons dans ce qui suit une description du schéma basée sur le langage de description de
données proposé par le SGBD IMS. Il ne s’agit pas de respecter scrupuleusement la syntaxe du
langage mais de permettre au lecteur d’avoir une idée sur ce à quoi pourrait ressembler un programme
de description du schéma conceptuel ou logique d’une base de données hiérarchique tout en faisant
apparaître les éléments clés d’un tel programme.

3.5.3.1 Programme de description de la première PDB

01 DBD NAME = ENTREPRISE

02 SEGM NAME = DEPARTEMENT, BYTES = 26


03 FIELD NAME = (NOMDPT, SEQ), BYTES = 16, START = 1
04 FIELD NAME = SPECIALITE , BYTES = 8, START = 17
05 FIELD NAME = NUMDPT , BYTES = 2, START = 25

06 SEGM NAME = EMPLOYES, BYTES=45, PARENT = DEPARTEMENT


07 FIELD NAME = (NUMEMP, SEQ), BYTES = 4, START = 1
08 FIELD NAME = NOMEMP , BYTES = 16, START = 5
10 FIELD NAME = ADRESSE , BYTES = 25, START = 21

11 SEGM NAME = ENFANTS, BYTES = 12,


PARENTS = ( ( EMPLOYES ) , ( ECOLES,
VIRTUAL, PDB = VILLE_ECOLE ))
12 FIELD NAME = PRENOM, BYTES = 8, START = 1
13 FIELD NAME = AGE , BYTES = 2, START = 9
14 FIELD NAME = ANNEE_SCOLAIRE , BYTES = 2, START = 11

15 SEGM NAME = VEHICULE, BYTES = 11, PARENT = DEPARTEMENT


16 FIELD NAME = TYPE_VEHICULE, BYTES = 2, START = 1
17 FIELD NAME = MATRICULE , BYTES = 9, START = 3
18 END

Figure 2.25 (a) : Description du PDB n° 1 avec le LDD du SGBD IMS

3.5.3.2 Programme de description de la seconde PDB

01 DBD NAME = VILLE_ECOLE

02 SEGM NAME = VILLES, BYTES = 37


03 FIELD NAME = (NOMVIL, SEQ), BYTES = 16, START = 1
04 FIELD NAME = WILAYA , BYTES = 16, START = 17
05 FIELD NAME = CODE_POSTAL , BYTES = 5, START = 33

06 SEGM NAME = ECOLES, BYTES = 20, PARENT = VILLES


07 FIELD NAME = (NOM_ECOLE, SEQ), BYTES = 20, START = 1
08 LCHILD NAME = ( ENFANTS, PDB = ENTREPRISE )
09 END

figure 2.25(b) : Description du PDB n° 2 avec le LDD du SGBD IMS

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 59

3.5.4 Discussion des programmes

Comme notre base de données hiérarchique est composée de deux PDB, elles sont donc décrites
indépendamment chacune par un programme de description ou DBD (Data Base Description).

3.5.4.1 Attribution d’un nom à une PDB

Chaque PDB est identifiée par son nom. Ce nom est fourni au SGBD grâce à l’instruction :

< DBD NAME =......>

Par exemple, l’instruction suivante figurant dans le premier programme :

01 DBD NAME = ENTREPRISE

et celle figurant dans le deuxième programme :

01 DBD NAME = VILLE_ECOLE

ont pour rôle de donner comme nom à la première PDB : ENTREPRISE et à la seconde PDB :
VILLE_ECOLE.

3.5.4.2 Description d’un segment

La description d’un segment revient à attribuer un nom au segment, préciser ses attributs (ou
FIELD) et leurs caractéristiques et préciser aussi le nom de son segment PARENT. Ceci est possible
car rappelons-le, avec le modèle hiérarchique, sur un segment autre que la racine, il ne peut y arriver
qu’une seule flèche (ou lien). Ainsi le segment PARENT de n’importe quel segment d’une PDB est
connu sans ambiguïté.

Si on se réfère au programme de description de la première PDB, on peut faire les commentaires


suivants :

l’instruction 02 définit le segment racine (DEPARTEMENT) de cette PDB en précisant


que le segment est composé d’attributs (FIELD) occupant 26 octets (BYTES = 26). A ce
niveau le programmeur est censé savoir combien occupe un caractère alphanumérique sur
la machine (ex : un octet), un entier (ex : 2 ou 4 octets) etc. On remarque cette lacune à
travers ce type de LDD et qui consiste à mélanger au niveau de la description logique de
la base de données des paramètres très techniques et de bas niveau.

les instruction 02 à 05 définissent les attributs (FIELD) du segment DEPARTEMENT.


Ce sont :

⌦ NOMDPT occupant 16 octets (BYTES = 16) et commençant à partir de l’octet


numéro 1 par rapport au début du segment ( START = 1 ). Le paramètre SEQ
indique la séquentialité des occurrences du segment. Il s’agit ici d’ordonner ces
occurrences selon un ordre croissant de l’attribut NOMDPT.

⌦ SPECIALITE occupant 8 octets (BYTES = 8) et commençant à partir de l’octet


numéro 17 par rapport au début du segment ( START = 17 ).

⌦ NUMDPT occupant 2 octets (BYTES = 2) et commençant à partir de l’octet

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 60

numéro 25 par rapport au début du segment ( START = 25 ).

les instruction 06 à 10 définissent de la même manière le segment EMPLOYES ayant


pour attributs NUMEMP, NOMEMP et ADRESSE et pour segment PARENT : le
segment DEPARTEMENT.

les instruction 11 à 14 définissent de la même manière le segment ENFANTS ayant pour


attributs PRENOM et AGE. et pour segment PARENT : le segment EMPLOYES.

On sait que le segment ENFANTS a un seul parent physique dans sa PDB


ayant pour nom ENTREPRISE . C’est le segment : EMPLOYES. Le
segment ENFANTS possède aussi un deuxième parent dans la seconde
PDB ayant pour nom VILLE_ECOLE. Ce parent est le segment ECOLES
et n’est qu’un parent logique ou virtuel.

La clause : PARENTS = ( ( EMPLOYES ), ( ECOLES, VIRTUAL,


PDB = VILLE_ECOLE )) de l’instruction 11 spécifie que le parent réel ou
physique du segment ENFANTS est le segment EMPLOYES, et que le
segment ECOLES est un parent virtuel ou logique se trouvant dans la PDB
ayant pour nom VILLE_ECOLE.

Les instruction 15 à 17 définissent de la même manière le segment VEHICULES ayant


pour attributs TYPE_VEHICULE et MATRICULE et pour segment PARENT : le
segment DEPARTEMENT.

L’examen du programme de description de la seconde PDB, nous permet de faire les commentaires
suivants :

Les même remarques faites au sujet de la description des segments et de leurs attributs
pour le premier programme sont valables ici aussi. La seule instruction qui doit être
commentée est l’instruction :

< 08 LCHILD NAME = ( ENFANTS, PDB = ENTREPRISE ) >

Le rôle de cette instruction est de préciser que le segment ECOLES possède un segment
fils logique (LCHILD signifiant LOGICAL CHILD) qui se trouve dans une autre PDB à
savoir la PDB ayant pour nom : ENTREPRISE.

Remarquons aussi que la notion de fils physique n’existe pas dans le modèle hiérarchique. On n’a
pas la possibilité au moment de la description d’un segment donné de préciser quels sont ses segments
fils physiques s’il en possède. Seule existe donc la possibilité de définir un fils logique et dont
l’avantage est d’éviter les problèmes de duplication physique de segments avec tous les problèmes de
redondance qui s’en suivent, mais aussi de voir logiquement une base de données hiérarchique sous
forme d’un réseau. Sur le plan pratique, cette possibilité permet de répondre à un plus grand nombre
de question surtout celles dont la réponse nécessite l’utilisation de plusieurs PDB distinctes.

3.6. Implantation physique d’une base de données hiérarchique

Une base de données hiérarchique peut être vue au niveau physique comme un ensemble de
réalisation ou d’occurrences de chaque PDB. Chaque occurrence n’est qu’un arbre au sens
informatique du terme dont chaque nœud est valué par une occurrence d’un segment qui compose la

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 61

PDB à laquelle appartient ce segment.

Il existe différentes structures de données pour représenter une telle base de données. Celles qui
sont utilisées dans la plupart des SGBD hiérarchiques sont : la structure séquentielle et la structure
de liste.

3.6.1 structure séquentielle

Cette méthode consiste à construire des enregistrements de longueur variable à raison d’un
enregistrement par occurrence d’arbre. En effet chaque arbre peut être transformée en son équivalent
linéaire grâce à un algorithme bien connu de parcours d’un arbre qui est le parcours en Préordre.
Nous rappelons cet algorithme qu’on peut exprimer simplement sous une forme récursive comme suit :

Préordre (Nœud)
Début
Lister Nœud
Pour chaque fils n de Nœud en partant de la gauche faire
Préordre ( n )
Fin Pour
Fin

⌦ Si on considère le modèle hiérarchique ci-dessous composé des segments(ou entités) A,


B, C et D et dont une occurrence ou réalisation est donnée en exemple, le parcours en
Préordre de cette occurrence donnerait :

a1 b1 d1 d2 b2 d3 b3 d4 d5 c1 c2

a1
A

B C
b1 b2 b3 c1 c2

D
d1 d2 d3 d4 d5

figure 2.26 : Parcours en Préordre d’une réalisation d’un modèle hiérarchique

Chacune des listes de segments obtenus ainsi va constituer un enregistrement de longueur variable.
Afin de reconnaître la structure d’un enregistrement et la nature des segments qui le composent,
chaque segment est précédé d’un entête qui donne sa longueur et son type par référence au schéma
hiérarchique (les PDB). Ces enregistrements sont rangés consécutivement et forment un fichier
séquentiel. L’inconvénient de cette structure est qu’elle ne permet pas de sélectionner rapidement la
racine d’une arborescence, puis à l’intérieur d’une arborescence un nœud quelconque. Ceci pourrait
beaucoup faciliter les réponses aux questions susceptibles d’être posées à la base de données.

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 62

3.6.2 Structure de liste

Cette méthode consiste à considérer que chaque nœud d’une arborescence est un élément d’un liste
chaînée, l’ordre des nœuds étant toujours celui donné par application de l’algorithme du Préordre.
Cette méthode permet de séparer l’ordre logique des occurrences des segments de leur ordre physique.
Elle présente plusieurs inconvénients. Par exemple, en cas de recherche d’un élément en fin de liste, il
faudra parcourir tous les éléments de la liste. Pour accélérer la recherche, on introduit en pratique
plusieurs types de pointeurs tels que :

Pointeur sur le père : pour chaque nœud, ce pointeur pointe vers le père de ce nœud
Pointeur sur le fils : pour chaque nœud, ce pointeur pointe vers le premier fils gauche. On
peut utiliser autant de pointeurs fils différents qu’il y a de liens hiérarchiques différents dans
le schéma.
Pointeur frère : pointe sur le nœud suivant de même type (occurrence du même segment)

La représentation sous forme de liste chaînée de l’occurrence de l’arbre de la figure 2.26 obtenue
plus haut par le Préordre et qui est : a1 b1 d1 d2 b2 d3 b3 d4 d5 c1 c2 donnerait :

a1

c1 c2 /

b1 b2 b3 /

d1 d2 / d3 / d4 d5 /

figure 2.27 : Représentation sous forme de liste chaînée d’une occurrence de l’arbre

Les pointeurs utilisés ont respectivement les significations suivantes :

ce pointeur est un pointeur vers le frère droit de type Racine (pas de référence au père)
ce pointeur est un pointeur vers le père
ce pointeur est un pointeur vers le frère droit de même type (ayant le même père)
ce pointeur est un pointeur vers le premier fils gauche relatif au lien entre B et D
ce pointeur est un pointeur vers le premier fils gauche relatif au lien entre A et C
ce pointeur est un pointeur vers le premier fils gauche relatif au lien entre A et B

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 63

3.7 Notion de sous schéma dans le modèle hiérarchique

Nous avons vu qu’une base de données hiérarchique peut être composée d’une ou de plusieurs
PDB dont l’ensemble sera assimilé au schéma conceptuel de cette base de données. Définir une vue ou
un sous schéma sur un tel schéma conceptuel va revenir à définir pour chaque PDB le sous ensemble
de segments que l’utilisateur est autorisé à voire. C’est ainsi qu’une vue ou sous schéma dans le cadre
du modèle hiérarchique peut être considéré comme un ensemble de sous schémas chacun se rapportant
à une PDB. De tels sous schémas sont appelés dans IMS des PCB pour Program Communication
Block et dont les règles de construction sont globalement les suivantes :

Un PCB étant un sous ensemble d’une PDB, il sera défini en masquant un ou plusieurs
segments de ce PBD. Dans ce cas tous les segments fils d’un segment masqué doivent aussi
être masqués.

Le segment racine d’un PCB doit être le même que celui de la PDB à laquelle il se rapporte.
Cette contrainte se comprend naturellement à partir de la précédente car si on masque le
segment racine d’une PDB c’est tous les segments de la PDB qui devront aussi être masqués
et ceci n’a vraiment pas d’intérêt. Cette contrainte n’existe pas dans le cas du modèle réseau.

On peut masquer n’importe quel attribut (ou FIELD) d’un segment. Il faut remarquer que
cette possibilité n’existait pas dans les premières versions du SGBD où il fallait inclure tous
les champs d’un segment devant composer un PCB.

On peut définir plusieurs PCB pour une même PDB. En effet, une PDB étant vue comme
une arborescence de segments, le nombre de PCB qu’on pourra construire sera identique aux
nombre de sous arbres qu’on peut dériver de cette PDB.

Un même PCB peut être utilisé par plusieurs programmes d’application

Deux PCB distincts peuvent comporter des segments en commun

Un programme d’application peut voir la base de données à travers un ou plusieurs PCB

A titre d’exemple, nous allons définir à partir du schéma conceptuel de la figure 2.24, le sous-
schéma (ou vue) suivant:

DEPARTEMENTS

EMPLOYES

ENFANTS

Figure 2.28 : Un exemple de sous schéma

qui constitue donc ce qu’on a appelé un PCB. Le programme de description de ce PCB en utilisant
le LDD du SGBD IMS aurait à peu près l’allure suivante :

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 64

01 PCB DBDNAME = ENTREPRISE


02 SENSEG NAME = DEPARTEMENT, PROCOPT = G
03 SENSEG NAME = EMPLOYES, PARENT = DEPARTEMENT, PROCOPT = GI
04 SENFLD NAME = NUMEMP
05 SENFLD NAME = NOMEMP
06 SENGEG NAME = ENFANTS, PARENTS = EMPLOYES, PROCOPT = GIRD
07 SENFLD NAME = PRENOM
08 SENFLD NAME = AGE
09 PSBGEN LANG = COBOL, PSBNAME = VUE1

Figure 2.29 : Définition d’un sous schéma avec le LDD du SGBD IMS

Les segments composants un PCB sont appelés dans IMS des segments sensitifs (ou sensibles) et
sont déclarés à l’aide du mot clé SENSEG (Sensitive Segment) dans le programme. Le terme sensitif
(ou sensible) caractérise donc tout segment qu’on désire rendre accessible à un programme
d’application.

Les instructions 02, 03 et 06 du programme ont pour rôle de déclarer les segments :
DEPARTEMENTS (qui est la racine de l’arbre!), EMPLOYES et ENFANTS comme
étant des segments sensitifs (donc visibles par le programme l’application).

La clause PROCOPT (Processing Options) permet de spécifier les types


d’opérations qu’on autorise sur le segment. Les opérations possibles sont : Get
et/ou Insert et/ou Replace et/ou Delete. Par exemple, pour le segment
DEPARTEMENTS on autorise uniquement des opérations de lecture
(PROCOPT = G), pour le segment EMPLOYES on autorise des opérations de
lecture et d’insertion (PROCOPT = GI), et pour le segment ENFANTS on
autorise des opérations de lecture, d’insertion, de modification et de suppression
(PROCOPT = GIRD).

Dans certaines versions du SGBD, ce style de protection peut même être


spécifié au niveau des attributs ou Fields d’un segment permettant ainsi de
renforcer les contrôles d’accès aux données de la base.

Dans le cas où on désire rendre accessibles à un programme d’application seulement certains


attributs (ou FIELD) d’un segment sensitif, ils suffira de les déclarer eux aussi comme attributs
sensitifs grâce au mot clé SENFLD (Sensitive Field).

Les instructions 04 et 05 du programme ont pour rôle de déclarer les attributs :


NUMEMP et NOMEMP du segment EMPLOYES comme étant des attributs sensitifs.
Par conséquent, le programme d’application ne peut voir que ces deux attributs du
segment EMPLOYES. Les même remarques peuvent être faites au sujet des attributs
PRENOM et AGE du segment ENFANTS qui sont déclarés sensitifs (instructions 07 et
08 du programme). Par contre pour le segment DEPARTEMENTS, aucun attribut n’est
déclaré sensitif et dans ce cas, le SGBD considère par défaut que tous les attributs de ce
segment sont accessibles aux programme (sensitifs).

Nous avons vu qu’un programme d’application peut voir la base de données à travers
un ou plusieurs PCB. L’ensemble de ces PCB constitue selon la terminologie du

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 65

SGBD IMS un Program Spécification Bloc ou PSB qui correspond effectivement à la


notion de sous schéma présente dans les autres types de SGBD (relationnel, réseau).
C’est ainsi que le SGBD distingue les PSB entre eux (et non pas les PCB!) grâce à un
nom qui sera attribué à chaque PSB.

L’instruction : [ 09 PSBGEN LANG = COBOL, PSBNAME = VUE1 ] précise


que le programme l’application utilisant ce sous schéma est écrit en COBOL et que le
nom du sous schéma est : VUE1. Par contre l’instruction : [ 01 PCB DBDNAME
= ENTREPRISE ] à pour rôle d’indiquer le début de la déclaration d’un PCB et
d’indiquer à quelle DBD se rapporte ce PCB. Dans notre cas c’est la DBD ayant pour
nom ENTREPRISE correspondant à la première PDB composant le schéma conceptuel
de notre base données et qui a été décrite par le programme de description du § 3.5.3.1

Une vue n’est en fait qu’un sous arbre de segments partant nécessairement de la racine. La question
qui vient à l’esprit est : Comment peut on cacher un segment appartenant à un sous arbre ?. Par
exemple dans le sous arbre donné plus haut comment peut on cacher le segment EMPLOYES afin de
n’autoriser le programme d’application qu’à voir les segments DEPARTEMENTS et ENFANTS. Le
SGBD oblige à déclarer dans un PCB tous les segments qui le compose. Par contre, pour ceux qu’on
désire cacher, il suffira de les déclarer en fixant le paramètre : PROCOPT = K (Key sensitivity). Ceci
signifie que le SGBD va nécessairement utiliser la clé du segment caché (EMPLOYES) pour toutes
les opérations d’accès qu’il fera à la base de données mais ne délivrera en aucun à l’utilisateur des
information sur le segment caché.

3.8 La manipulation de données dans un modèle hiérarchique

Le langage de manipulation de données offert part un SGBD hiérarchique est essentiellement basé
sur des opérations telle que les suivantes :

Retrouver un enregistrement dont le type a été spécifié. Cette opération est


particulièrement utilisée pour accéder à la racine d’une arborescence connaissant la valeur
de la clé d’un enregistrement. Dans IMS, une telle opération est réalisée grâce à une
instruction GET UNIQUE (GU).

Se déplacer dans une arborescence en utilisant une fonction de type successeur ou suivant
d’un nœud. Cette opération se base sur la méthode de parcours en préordre de
l’arborescence. C’est une opération de recherche purement séquentielle qui consiste donc
à explorer la liste des nœuds telle qu’elle est produite par l’algorithme du préordre. Dans
IMS, une telle opération est réalisée grâce à l’instruction GET NEXT (GN).

⌦ L’exécution d’une telle opération sur l’occurrence de l’arbre de la figure 2.26


(dont le parcours selon la méthode du préordre est : a1 b1 d1 d2 b2 d3 b3
d4 d5 c1 c2) dans le cas où le nœud courant était b1 donnera comme résultat
d1. L’exécution de la même instruction une deuxième fois va donner comme
résultat d2.

: Expliquer comment vous mettriez en œuvre l’exécution de cette instruction


en utilisant la représentation sous forme de liste chaînée avec tous les types de
pointeurs qui y sont définis ?

Se déplacer dans une arborescence en utilisant une fonction de type successeur ou suivant

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 66

d’un nœud mais en se limitant uniquement à des nœuds qui ont le même père. Cette
opération se base aussi sur la méthode de parcours en préordre de l’arborescence. Dans
IMS, une telle opération est réalisée grâce à l’instruction GET NEXT WITHIN
PARENT.

⌦ L’exécution de GET NEXT WITHIN PARENT sur le même exemple dans le


cas où le nœud courant était b1 donnera comme résultat b2. L’exécution de la
même instruction une deuxième fois va donner comme résultat NIL. Ceci
signifie que b2 est le dernier élément de la liste dont le père est a1.

: Même questions que plus haut

Insérer une nouvelle occurrence d’un nœud (ou segment), supprimer une occurrence d’un
nœud, remplacer une occurrence.. Dans IMS, de telles opération sont réalisées grâce aux
instruction INSERT, DELETE et REPLACE.

Toutes ces opérations ou instructions vont servir à l’écriture d’un programme d’application. Elles
seront en général invoquées à partir d’un langage de programmation (PL/1, COBOL, Assembleur, ...)
qui servira de support (langage hôte) à l’écriture des programmes d’application.

4 Conclusion

Les modèles réseaux et hiérarchiques ont été à l’origine de la première génération de SGBD connus
comme étant relativement rigides et complexes à mettre en œuvre. Ceci est dû au fait que ces SGBD
ont été développés par des programmeurs pour être utilisés principalement par des programmeurs.

Ils sont dits navigationnels car on doit décrire le chemin d’accès à utiliser pour trouver une donnée
dans la base de données. Le terme navigationnel caractérise bien ces SGBD puisque la base de
données est perçue comme une ‘‘ Mer ’’ dans laquelle on doit naviguer pour atteindre des ‘‘ îles ’’ qui
sont représentées par les fichiers d’enregistrements en utilisant des ‘‘ ponts ’’ qui sont représentés par
les liens entre les entités et qui permettent de passer d’une île à l’autre.

Les SGBD navigationnels sont verbeux c’est à dire qu’ils contiennent beaucoup de mots réservés
que le programmeur devra apprendre pour être à même de décrire et manipuler les données de sa base.
A titre indicatif, un SGBD CODASYL peut contenir jusqu’à 300 mots réservés alors qu’un SGBD
relationnel ne posséderait qu’une trentaine (30) de mots réservés en moyenne.

L’avantage du modèle réseau par rapport au modèle hiérarchique est qu’il ne restreint pas le
nombre de liaisons qui peuvent arriver ou partir d’un nœud. Un modèle hiérarchique n’est en fait
qu’un cas particulier de modèle réseau mais la réciproque n’est pas vraie.

Un SGBD CODASYL offre un langage de description de données (LDD) et un langage de


manipulation de données (LMD) séparés. Cette séparation entre les deux langages encourage un
travail en deux phases : Conception de la base de données (mise en place du schéma conceptuel et des
sous schémas) puis exploitation de celle-ci (écriture des programmes d’application ).

Les SGBD navigationnels manipulent un enregistrement à la fois alors qu’un SGBD relationnel
manipulerait plutôt une relation à la fois. Une relation n’est en fait qu’un ensemble de tuples dont
chacun pourrait être assimilé à un enregistrement que manipule un SGBD navigationnel. Or, il faut
souligner qu’avec un SGBD relationnel, une seule instruction peut modifier plusieurs tuples à la fois
répondant à des critères alors qu’avec un SGBD navigationnel, il faudrait écrire un petit programme

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 67

pour arriver à faire le même travail.

Enfin la supériorité des SGBD relationnels par rapport aux SGBD navigationnels est actuellement
communément reconnue. Cependant, certains grands distributeurs de SGBD navigationnels comme la
société CULLINET avec son SGBD réseau IDMS/R ou la société CINCOM avec son SGBD TIS,
continuent à promouvoir leurs produits en y intégrant les concepts du relationnel. Ces sociétés
justifient leur approche par le fait que les meilleurs SGBD seront ceux qui combineront le
navigationnel avec le relationnel.

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 68

Exercices sur le Chapitre 2

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 69

Exercice 1:

Identifier parmi les modèles de données suivants ceux qui ne sont pas conformes aux spécifications
du modèles réseau Codasyl :

A A

B B

D C D C

A
A

B
B C

A
A

B C
A A

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 70

Exercice 2:

Identifier parmi les modèles de données suivants ceux qui ne sont pas conformes aux spécifications
du modèles hiérarchique :

A
A

B
B

D C
D C

A
A

B C
D
B

E
D

A E
A

D B C
B D

B C

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 71

Exercice 3:

Parmi les modèles de données suivants, Transformer ceux que ne sont pas conformes aux
spécifications du modèle réseau CODASYL de façon à les rendre conformes :

VILLES MODULE

ETUDIANT ENSEIGNANT
PRODUITS SOCIETES

ENSEIGNANT

MODULE ETUDIANT

Exercice 4:

Préciser pour chacun des Sets du modèle de données suivant :

Regroupe
DEPARTEMENTS VILLES

Utilise Emploie Habitée_Par

Contient
VEHICULES EMPLOYES

Père_De

ECOLES
ENFANTS
Accueille

1) l’entité propriétaire et l’entité membre.


2) le type de rétention que vous choisirez pour l’enregistrement membre dans un SET
3) Dans le cas ou la rétention choisie pour les Sets est comme suit :

Regroupe : RETENTION IS MANDATORY


Utilise : RETENTION IS OPTIONAL
Emploie : RETENTION IS MANDATORY

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 72

Père_De : RETENTION IS FIXED


Accueille : RETENTION IS OPTIONAL
Contient : RETENTION IS FIXED
Habitée_Par : RETENTION IS MANDATORY

Expliquer ce qui se passe si on avait à supprimer une occurrence de chacun des


enregistrements suivants :

- VILLES
- ENFANTS
- VEHICULES
- ECOLES
- DEPARTEMENTS
- EMPLOYES

Exercice 5 :

Est-ce que la transformation du lien N:M entre les deux entités MODULE et ETUDIANT peut être
faite simplement en le remplaçant par deux liens L1 et L2 de type 1: N . Justifier votre réponse en
raisonnant sur une représentation par liste circulaire de quelques occurrences de ces entités.

MODULE
MODULE

L1 L2

ETUDIANT
ETUDIANT

Exercice 6:

Soit le modèle réseau CODASYL suivant :


Emploie
ENSEIGNANTS INSTITUS

Enseigne

Contient
MODULES
Encadre

Suivi-Par Dispense

ETUDIANTS DEPARTEMENTS
Contient

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 2: Les modèles de données réseau et hiérarchique • 73

Proposer plusieurs sous schémas valides qu'on pourrait définir à partir de ce schéma et Proposer
plusieurs sous schémas valides qu'on pourrait définir à partir de ce schéma et précisant le type de
questions possibles avec chaque sous schéma.

Exercice 7 :

Soit le modèle hiérarchique suivant :

Emploie
ENSEIGNANTS INSTITUS

Enseigne

Contient
MODULES

Suivi-Par

ETUDIANTS DEPARTEMENTS

Ce schéma permet-il de répondre à chacune des questions suivantes .

- Trouver la liste des enseignants connaissant le département


- Trouver la liste des modules dispensés dans un institut
- Trouver l'institut auquel est rattaché un étudiant
- Trouver la liste des modules enseignés dans un département

Proposer plusieurs sous schémas valides qu'on pourrait définir à partir de ce schéma et préciser le
type de questions possibles avec chaque sous schéma.

Exercice 8:

La notion d’AREA dans un SGBD de type CODASYL permet de préciser pour chaque
enregistrement le nom d’une zone sur le support de stockage ou on désire stocker les occurrences de
cet enregistrement. Cette notion est-elle aussi utilisée pour le stockage des occurrences d’un SET
(l’ensemble des liste circulaires réalisant un SET) ?

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie
Chapitre 3: Le modèle relationnel •74

Chapitre 3 : Le modèle relationnel

1 Introduction
Le modèle relationnel est un modèle de données qui consiste à percevoir la base de données comme
un ensemble de relations qu’on peut visualiser sous forme de tables à deux dimensions : les colonnes
qui correspondent aux attributs d’une relation et les lignes qui contiennent les tuples d’information
(voir les définitions plus loin). La caractéristique principale de ce modèle est qu’il n’utilise qu’un seul
concept : la relation. Contrairement aux modèles réseau et hiérarchique qui distinguent entre les
concepts d’entité et de lien, avec le modèle relationnel, on modélise indifféremment une entité ou un
lien entre deux entités par une relation . De plus, les associations de type N : M sont directement
supportées par le modèle relationnel sans aucune transformation préalable comme ce fût le cas avec
les modèles réseau et hiérarchique. L’intérêt de cette approche est qu’elle conduit à un modèle simple,
plus facile à comprendre et à utiliser même par un utilisateur non spécialiste.

2 Objectifs visés par le modèle relationnel


C’est dans le but de remédier aux lacunes des modèles réseau et hiérarchique dits modèles de
première génération que fût proposé vers 1970 le modèle relationnel par E.F. CODD (qui n’était pas
informaticien de formation mais matheux!) ouvrant ainsi la voie à une deuxième génération de
modèles basés principalement sur des fondements mathématiques.

Parmi les objectifs visés par ce modèle, nous allons présenter quelques-uns qui nous semblent
attester sans équivoque de sa supériorité par rapport à ceux de la première génération. Nous essayerons
au fur et à mesure de mettre en évidence les problèmes qui étaient posés avec les autres modèles afin
de bien situer l’apport du modèle relationnel.

2.1 Proposer des schémas faciles à utiliser

Les modèles réseau et hiérarchique mélangent au niveau de la description du schéma conceptuel de


la base de données des notions du niveau logique avec celles du niveau physique (ex : Hachage,
attributs virtuels, entités virtuelles, Aréa, mode d’implantation des SETS, mode de localisation des
occurrences, Lien Parent-Enfant...). De plus, les associations N:M ne sont pas directement
représentables et il faudra d’abord les transformer en des liens 1: N avec les méthodes que nous avons
vu dans le chapitre précédent. Ainsi, la construction d’un schéma est une tâche difficile qui nécessite
une bonne connaissance des aspects techniques liés au niveau physique et une bonne maîtrise des
langages DDL et DML offerts par le SGBD. Ces langages sont caractérisés par leur complexité et ne
sont donc pas à la portée de tout utilisateur. De ce fait, la construction d’un schéma et son utilisation
sont des tâches très difficiles qui conviennent plutôt à des personnes compétentes (programmeurs).

L’avantage du modèle relationnel est qu’il n’utilise qu’un concept unique celui de relation pour
représenter aussi bien les entités que les liens pouvant exister entre elles sans utiliser de notions du
niveau physique. L’intérêt pratique d’une telle approche est que la construction d’un schéma devient
simple ce qui rend le modèle utilisable par un grand nombre d’utilisateurs ayant plus ou moins de
connaissances informatiques. De plus, les langages DDL et DML offert par les SGBD relationnels
sont moins verbeux ce qui facilite leur apprentissage et favorise l’écriture des programmes et la mise
en place des applications.

2.2 Améliorer l’indépendance logique et physique

Ces deux notions sont fondamentales dans un SGBD. L’indépendance logique correspond à la
Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •75

nécessité que des applications différentes aient des vues différentes du même schéma conceptuel alors
que l’indépendance physique correspond à la possibilité de modifier pour des raisons d’efficacité,
l’organisation physique des données et des chemins d’accès sans affecter les programmes
d’application. On doit par exemple avoir la possibilité de supprimer ou d’ajouter une table d’index, un
lien entre deux enregistrements sans être obligé de modifier les programmes d’application.

Nous avons vu dans le chapitre précédent qu’avec les modèles réseau et hiérarchique,
l’indépendance logique repose sur le concept de sous schéma qui correspond à un sous ensemble du
schéma conceptuel. Ce sous schéma correspond en général à un filtrage du schéma conceptuel sans
possibilité de modification de ce dernier. Il n’est pas possible par exemple de spécifier dans un sous
schéma qu’une application ne peut voire qu’un sous ensemble d’occurrences d’un enregistrement
déclaré dans le schéma conceptuel qui satisfont un critère donné.

De même, il n’est pas possible de définir dans un sous schéma un nouvel enregistrement comme
étant obtenu par combinaison d’attributs pris dans d’autres enregistrements déclarés dans le schéma
conceptuel. L’ajout d’un nouvel lien entre deux enregistrements au niveau du schéma conceptuel est
une opération qui n’est pas en général transparente aux programmes d’application et le plus souvent
on sera amené à les modifier pour prendre en compte un tel changement. Ceci est surtout le cas dans le
modèle hiérarchique où l’ajout d’un segment entre deux autres segments du schéma conceptuel déjà
liés par un lien PARENT-ENFANT nécessite la définition d’un nouveau lien PARENT-ENFANT
dans le schéma mais aussi dans un ou plusieurs sous schémas ainsi que des modifications dans les
programmes d’application.

En ce qui concerne l’indépendance physique, nous avons déjà souligné que celle-ci est
pratiquement inexistante car lors de la description du schéma conceptuel on utilise des notions du
niveau physique (ex : Hachage, attributs virtuels, mode d’implantation de liens, mode de localisation,
...). Si par exemple pour des raisons d’efficacité, on décide de changer dans le schéma conceptuel le
nom de l’attribut d’un enregistrement utilisé par une fonction de hachage, il faudra impérativement en
tenir compte dans les programmes d’application qui sont concernés. De même, si on décide
d’augmenter la précision d’un attribut en changeant sa taille (nombre d’octets qu’il occupe et son
format), il faudra non seulement recompiler le schéma mais aussi revoir tous les programmes qui
manipulent cet attribut.

Dans le cas du modèle relationnel, l’indépendance logique est garantie grâce à la notion de vue
relationnelle. Il devient possible de définir une vue comme étant composée de relations ou tables qui
n’existent pas dans le schéma conceptuel mais qui sont dérivées de celles constituant le schéma
conceptuel. L’avantage certain d’une vue dans le modèle relationnel par rapport au concept de sous
schéma tel qu’il est proposé dans les autres modèles est qu’elle possède un caractère de dynamicité.
En effet, elle permet au moment même de sa définition, de spécifier des critères que doivent vérifier
les données de la base qu’on désire rendre accessibles à un utilisateur. Une telle opération est
pratiquement irréalisable au moment de la définition d’un sous schéma dans les SGBD réseau ou
hiérarchique. Avec le modèle relationnel, l’ajout d’une nouvelle entité ou d’un nouveau lien au
schéma conceptuel devient une opération transparente aux programmes d’application puisqu’il s’agira
de rajouter simplement la définition d’une nouvelle relation.

En ce qui concerne l’indépendance physique, elle est rendue possible dans le sens où au moment de
la description des relations composant le schéma conceptuel ou relationnel, aucune notion du niveau
physique n’est utilisée. On n’a pas par exemple à préciser au SGBD la méthode d’implantation d’une
relation modélisant un lien entre deux entités, ni de préciser que la localisation d’un tuple dans une
relation (qui est l’équivalent d’une occurrence d’une entité) se fait par telle ou telle méthode. L’ajout
d’un index sur une relation qui est une opération qu’on utilise surtout pour augmenter les
performances d’accès à la base de données peut se faire sans avoir à modifier les programmes
d’application. De même que, le déplacement physique d’une relation sur le support ( appelée aussi le
clustering ou groupage) qui est une opération souvent nécessaire pour optimiser le temps de réponse
de certains types d’opérations telle qu’une jointure, peut être réalisée sans aucune incidence sur les

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •76

programmes.

2.3 Mettre à la disposition des utilisateurs des langages de


manipulation de haut niveau

Les langages de description et de manipulation de données offerts par les SGBD réseau ou
hiérarchique sont par nature verbeux c’est à dire comportent beaucoup de termes ou mots réservés. Ce
sont des langages accessibles surtout à l’utilisateur informaticien. Le langage de manipulation qui sert
de support pour l’écriture d’un programme d’application est navigationnel en ce sens qu’il oblige le
programmeur à tenir compte de la structure de la base de données pour formuler ses requêtes. Ceci
veut dire que l’utilisateur navigue dans la base de données au grès des chemins d’accès. Dans ce cas
les accès à la base de données sont entièrement sous son contrôle puisque c’est lui-même qui indique
au SGBD les chemins à emprunter pour atteindre telle ou telle donnée. Cette approche ne garantit en
aucun cas que les chemins prescrits par l’utilisateur sont les meilleurs en termes de temps d’accès. De
plus, les LMD offerts par un SGBD réseau ou hiérarchique ne garantissent pas l’indépendance
physique entre données et programmes puisque leur vocabulaire renferme des termes liés au niveau
physique. De ce fait, l’écriture des programmes d’application convient mieux au personnes
connaissant bien les aspects du niveau physique.

Le LMD offert par les SGBDs relationnels n’est pas navigationnel, c’est à dire que l’utilisateur n’a
pas à prescrire dans son programme de stratégie d’accès ni de chemin d’accès aux données. Il
appartient donc au SGBD de rechercher toutes les stratégies d’accès possible et de retenir celle qui est
plus efficace en termes de temps d’accès à la base de données. De même que ces LMD sont basés sur
un vocabulaire plus réduit relativement à celui des SGBDs réseau ou hiérarchique et qui ne renferme
pas de termes liés au niveau physique. Ceci simplifie donc leur apprentissage et leur utilisation et
contribue aussi à l’amélioration de l’indépendance physique.

2.4 Améliorer l’intégrité et la confidentialité

Ces deux notions sont fondamentales dans un SGBD. Les SGBDs basés sur les modèles réseau ou
hiérarchique proposent des solutions limitées lors de la description du schéma conceptuel ou d’un sous
schéma telles que :

• la protection de l’accès aux occurrences d’un enregistrement grâce à un mot clé


• la déclaration du type d’un attribut (entier, caractère, ...)
• la protection de l’accès à la base de données grâce à un sous schéma
• etc.

Cependant, il faut noter qu’une contrainte d’intégrité sur les données doit être normalement
spécifiée au niveau de la description du schéma conceptuel. Elle doit aussi être définie en termes
logiques c’est à dire sous forme de propriétés que doivent vérifier les données répondant à certains
critères sans référence ni aux chemins d’accès ni aux méthodes d’accès. Avec les SGBD réseau et
hiérarchique, l’expression de contrainte d’intégrité au niveau du schéma conceptuel est limitée à la
déclaration de propriétés simples (ex : type d’un attribut). L’expression d’une contrainte d’intégrité
plus élaborée, ne peut se faire que par bricolage tel que sa traduction sous forme de programme (ou
routine) qui sera déclenché manuellement par le programmeur

La confidentialité concerne la protection de l’accès à la base de données. Nous avons vu que le


concept de sous schéma a pour rôle de permettre à un programme d’application ayant ses propres
utilisateurs de voir uniquement les données qui l’intéressent. Ainsi, un sous schéma sert de moyen
pour protéger les accès à la base de données. Si on se place au niveau de l’enregistrement (ou du
SEGMENT), la protection est rendue possible grâce à la technique des mots de passe qu’on peut
associer à l’enregistrement pour contrôler l’accès et les opérations permises dessus (Voire Chapitre

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •77

précédent). Ainsi, il n’est pas possible de spécifier au niveau du schéma ou du sous schéma qu’on
désire protéger seulement les occurrences d’un enregistrement vérifiant un critère donné (ex : autoriser
uniquement l’accès aux Employés dont le salaire < 10.000 D.A.). Cette lacune est due essentiellement
aux inconvénients des langages de description et de manipulation et que nous avons souligné plus
haut.

Le modèle relationnel offre un LMD qui n’est pas de type navigationnel et qui permet d’identifier
une information atomique (attribut) ou une combinaison d’informations reliées entre elles en dehors
de tout chemin ou méthode d’accès. Il devient ainsi possible de spécifier de façon plus naturelle au
niveau du schéma conceptuel l’information qu’on veut protéger et contre qui on veut la protéger. Le
concept de vue relationnel avec quelques mécanismes d’octroi de privilèges donne au modèle
relationnel une puissance inégalée en matière de confidentialité et de protection de la base de données.

2.5 Prendre en compte une variété d’utilisateurs

L’environnement de programmation offert par les SGBD basés sur les modèles réseau ou
hiérarchique pour la description du schéma conceptuel et l’écriture des programmes d’application est
très complexes et ne peut être maîtrisé que par l’utilisateur informaticien. Ceci entraîne souvent une
limitation dans le nombre d’application mises en place et par voie de conséquence le nombre
d’utilisateurs de la base de données. Cette limitation est due principalement au fait que la mise en
place d’un projet nécessite très souvent la mobilisation d’un personnel qualifié qui revient
généralement cher et augmente considérablement le coût d’un projet. Cette réalité n’encourage donc
pas la mis en place de beaucoup d’applications.

Le modèle relationnel permet l’utilisation de schéma conceptuel simple et des langages de


description et de manipulation moins verbeux et ne nécessitant pas des connaissances solides en
informatique. La mis en place d’une application devient donc plus simple ce qui favorise
l’augmentation du nombre d’applications. Cet avantage du modèle est mieux perçu pour le cas des
petites bases de données où le coût principal d’un projet est le temps passé dans l’écriture des
programmes d’application. Avec un SGBD bien adapté tel que ceux basés sur le modèle relationnel,
le coût d’un tel projet serait à coup sûr réduit.

2.6 Offrir une approche méthodologique pour la construction du


schéma conceptuel

La construction du schéma conceptuel est une étape fondamentale dans la mise en place d’une base
de données. Il serait donc important d’aider l’utilisateur dans la tâche de conception d’un tel schéma.
Avec les modèles réseau et hiérarchique, le concepteur ne dispose d’aucune méthodologie pouvant le
guider dans la conception d’un schéma ni de lui permettre d’évaluer la qualité du résultat auquel il
parvient. En général, le concepteur visualise sous forme de boîtes et de flèches son schéma conceptuel
dans lequel il associe mentalement une boîte à un fichier et une flèche à un lien entre deux fichiers.
Cette approche est basée sur le bon sens du concepteur pour lequel il est impossible de justifier le
choix d’une seule boîte en non pas deux , d’une flèche au lieu d’une boîte, etc.

Dans le modèle relationnel, E.F. CODD a défini des formes normales (1ière , 2ième, 3ième, etc.) pour
les relations fondées sur des propriétés mathématiques et permettant au concepteur de structurer
l’information en identifiant de façon précise les associations qui existent entre elles et les contraintes
qu’elles doivent satisfaire. D’autre part, le concept de forme normale peut être vu comme un moyen
pour mesurer la qualité du schéma conceptuel. Il a été prouvé que si un schéma conceptuel ne
comportait que des relations en troisième forme normale, il garantit un découpage de l’information de
telle sorte que toute modification de valeurs à l’intérieur d’une relation n’a pas de répercussion sur
d’autres relations. Il est même possible d’aboutir à une construction quasi automatique du schéma
conceptuel (i.e. par un algorithme).

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •78

3 Définitions
3.1 Attribut

Dans le modèle relationnel, un attribut désigne une propriété ou une caractéristique d’une relation
qui comme nous l’avons dit dans l’introduction peut modéliser une entité ou un lien entre deux entités.
Cette notion d’attribut correspond exactement à la même notion utilisée dans le modèle réseau pour
définir un enregistrement ou RECORD et correspond à la notion de champ ou FIELD utilisée dans le
modèle hiérarchique pour définir un segment.

3.2 Domaine d’un attribut


Le domaine d’un attribut correspond à l’ensemble des valeurs que peut prendre cet attribut. Cet
ensemble peut être fini ou dénombrable comme il peut être infini. En pratique, il est très difficile
d’énumérer l’ensemble des valeurs définissant le domaine d’un attribut surtout si cet ensemble est
infini. Nous devons souligner qu’il n’existe à notre connaissance aucun SGBD qui offre la possibilité
de déclarer au niveau du schéma conceptuel le domaine d’un attribut. La majorité des ces systèmes
assimilent le type de donnée d’un attribut (entier, date , chaîne de caractères, réel,...) à son domaine et
limitent ainsi la définition d’un attribut à la déclaration du nom de l’attribut suivi de son type (ex :
Prénom_Employé : Char(10)).

Ainsi, on peut dire que cette notion de domaine sert surtout pour la définition formelle du modèle
relationnel. Les quelques exemples suivants permettront de donner au lecteur une idée plus précise sur
cette notion de domaine mais surtout de montrer combien elle est difficile à prendre en compte par un
SGBD.

• Le domaine de l’attribut Jour_De_Semaine est : (Samedi, Dimanche, Lundi, Mardi, Mercredi,


Jeudi, Vendredi). C’est un domaine constitué d’un nombre fini de valeurs et qui sont connues.

• Le domaine de l’attribut Jour_De_Travail est : (Samedi, Dimanche, Lundi, Mardi, Mercredi,


Jeudi). C’est un domaine constitué d’un nombre fini de valeurs et qui sont connues. Le
domaine de l’attribut Jour_De_Semaine est un domaine différent de celui de l’attribut
Jour_De_Travail et ce même s’ils contiennent plusieurs valeurs identiques.

• Le domaine de l’attribut Jour_Du_Mois est : [1...31]. C’est un domaine constitué d’un


nombre fini de valeurs comprises entre une valeur minimale égale à 1 et une valeur maximale
égale à 31. Ce nombre est fini car dans la réalité nous savons que le jour dans un mois peut
être représenté par une valeur entière comprise entre 1 et 31. Il est tout à fait possible
d’énumérer l’ensemble des valeurs mais ce travail serait à coup sûr ennuyeux et il est
préférable de le simplifier en définissant les deux bornes de l’intervalle.

• Le domaine de l’attribut Mois est : [1...12]. C’est un domaine constitué d’un nombre fini de
valeurs comprises entre une valeur minimale égale à 1 et une valeur maximale égale à 12. Les
mêmes remarques faites au sujet de l’attribut Jour_Du_Mois sont applicables ici aussi.

• Le domaine de l’attribut Année est : [1900...3000]. C’est un domaine constitué d’un nombre
fini de valeurs comprises entre une valeur minimale égale à 1900 et une valeur maximale
égale à 3000. Les mêmes remarques faites au sujet de l’attribut Jour_Du_Mois sont
applicables ici aussi.

• Le domaine de l’attribut Date est : (Jour_Du_Mois, Mois, Année ). C’est un domaine


composé des trois domaines propres aux attributs Jour_Du_Mois, Mois et Année. L’ensemble
des valeurs que peut prendre l’attribut Date sera donc un sous ensemble du produit cartésien
de ces trois domaines (Voir définition du produit cartésien entre domaines § 3. 3 ) lequel

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •79

contient 31 * 12 * 2101 valeurs ( ou 2101 = (3000 - 1900) + 1 ).

• Le domaine de l’attribut Couleur_Pantalon est : (Rouge, Vert, Bleu, Orange, Gris, Marron)
C’est un domaine constitué d’un nombre fini de valeurs mais ce nombre peut augmenter si on
prévoit par exemple de rajouter plus tard pour le besoin de l’application une nouvelle couleur
comme le Violet.

• Le domaine de l’attribut Age_Employé est : [15...50]. C’est un domaine constitué d’un


nombre fini de valeurs comprises entre une valeur minimale égale à 15 et une valeur
maximale égale à 50 (mêmes remarques que l’attribut Mois).

• Le domaine de l’attribut Poids_Pièce est : En général, un attribut tel que le poids peut prendre
n’importe quelle valeur réelle. Dans ce cas son domaine est infini et il est pratiquement
impossible d’énumérer toutes les valeurs possibles ni de le définir grâce à un intervalle en
précisant la valeur minimale et maximale comme nous l’avons fait pour l’âge d’un employé.
Cependant, il faut remarquer que ceci reste lié à l’application et il est tout à fait possible de
trouver dans la réalité des applications pour lesquelles un attribut de ce type possède un
domaine dont les valeurs sont réelles mais comprises entre deux bornes, soit des valeurs
entières comprises entre deux bornes, etc.

• Le domaine de l’attribut Poids_Employé est : Les mêmes remarques faites pour l’attribut
Poids_Pièce sont vraies ici aussi. Cependant, il serait totalement faux de dire que les deux
attributs ont le même domaine même s’ils désignent tous les deux un poids. Donc, il faut tenir
compte de la sémantique car on ne peut en aucun cas comparer le poids d’une pièce au poids
d’un employé même si informatiquement parlant ce sont deux valeurs réelles tout à fait
comparables. C’est là un sujet de recherches tout à fait ouvert car dans la pratique beaucoup de
SGBD se cassent la gueule lorsqu’on leur dit de comparer un poids avec un salaire !

• Le domaine de l’attribut Prénom_Employé est : (Ali, Amar, Allaoua,...Bachir,


Brahim,....Zakaria, Zoubir, Zouaoui,....). C’est un domaine constitué d’un nombre fini de
valeurs qui sont des chaînes de caractères mais qu’il est difficile pour ne pas dire impossible
(sauf si on dispose du répertoire des prénoms utilisables dans l’état civil !) d’énumérer. On
assimile alors le domaine à un domaine de valeurs infini pour simplifier les choses bien que
d’autres solutions pourraient bien faire l’affaire comme préciser que le domaine est un
intervalle dont les valeurs sont comprises entre une valeur minimale égale à AAAAAA et une
valeur maximale égale à ZZZZZZ. (si un prénom est composé de six caractères au
maximum).

Nous invitons vivement le lecteur à dresser une liste d’attributs en se plaçant dans le contexte d’une
application qui lui est familière et d’associer à chaque attribut son domaine. Il s’apercevra que rare
sont les attributs qui ont le même domaine et qu’on a souvent tendance à associer à chaque attribut un
domaine qui lui est propre.

3.3 Produit cartésien d’un ensemble de domaines

Le produit cartésien d’un ensemble de domaines D1 , D2 , D3 ,....., Dn non nécessairement distincts


que l’on note : D1 x D2 x D3 x.....x Dn est l’ensemble des n-uplets ou tuples (v1 , v2 , v3 ,....., vn) tel que
vi ∈ Di et ce pour tout i = 1, 2, 3,....., n.

Exemple : Soit les trois domaines suivants :

D1= (Lundi, Mardi, Mercredi, Jeudi, Vendredi, Samedi, Dimanche)


D2= (1, 2 , 3 ,.....31)
D3= (Janvier, Février, Mars, Avril, Mai, .......Décembre)

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •80

Alors le produit cartésien D1 x D2 x D3= { (Lundi, 1, Janvier), (Lundi, 2, Janvier), (Lundi, 3,


Janvier), ....... (Lundi, 31, Janvier), (Lundi, 1, Février), ....... (Lundi, 31, Février), .......
(Lundi,31, Décembre), (Mardi, 1, Janvier), ....... (Dimanche, 1, Décembre), ....... (Dimanche, 31,
Décembre)

3.4 Relation
3.4.1 Définition formelle

Une relation est définie par une liste d’attributs A1 , A2 , A3 ,...., An ayant respectivement pour
domaine D1 , D2 , D3 ,..... , Dn . On la note R(A1 , A2 , A3 ,..... , An ) ou R est le nom de la relation. Elle
est composée d’un ensemble de tuples (a1 , a2 , a3 ,....., an) ou ai ∈ Di ∀ i = 1, 2, 3,....., n, cet
ensemble constituant un sous-ensemble du produit cartésien : D1 x D2 x D3 x..... x Dn.

3.4.2 Tuple d’une relation

Afin de lever toute ambiguïté, nous devons préciser que lorsqu’on parle de table c’est à dire la
représentation sous forme tabulaire d’une relation, les termes ligne et colonne seront utilisés. Par
contre lorsqu’on parle de relation ce sont plutôt les termes tuple (ou n-uplet) et attribut qui seront
utilisés.

Compte tenu de ces précisions, un tuple d’une relation désigne donc tout simplement une ligne dans la
table représentant cette relation. Un attribut quant à lui désignerait plutôt une colonne dans la même
table.

3.4.3 Arité d’une relation

L’arité d’une relation est le nombre de ses attributs. C’est aussi le nombre de colonnes de la table si
on songe à la représentation de la relation sous forme de table. Par exemple, la relation R(A1 , A2 , A3
,..... An ) a une arité égale à n car elle possède n attributs. Comme cas particuliers, il faut distinguer les
relations ayant un seul attribut (tables à une seule colonne) et qui sont dites unaires (i.e. arité = 1) et
aussi les relations ayant deux attributs seulement (tables à deux colonnes) et qui sont dites binaires
(i.e. arité = 2).

3.4.4 Cardinalité d’une relation

La cardinalité d’une relation est le nombre de tuples de cette relation. C’est aussi le nombre de
lignes de la table si on songe à la représentation de la relation sous forme de table. La cardinalité
d’une relation R sera donc un nombre entier et se note : |R|.

3.4.5 Schéma d’une relation - Extension d’une relation

Le schéma d’une relation est le nom de la relation suivi de la liste des attributs (ou constituants) de
cette relation comme par exemple : R(A1 , A2 , A3 ,..... An ). C’est ce qu’on appelle aussi la
définition en intention de la relation par opposition à la définition en extension d’une relation (voir
plus loin).

Soit la relation CATALOGUE_PRIX (Code_Produit , Désignation , Fournisseur , Prix).


Cette relation est définie par ses attributs qui sont : Code_Produit , Désignation , Fournisseur
et Prix. Son nom est : CATALOGUE_PRIX.

Une représentation sous forme d’une table de cette relation où les colonnes correspondent aux
attributs et les lignes aux tuples de la relation serait :
Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •81

Code_Produit Désignation Fournisseur Prix

P001 ETAGERE ALI 1500


P002 ARMOIRE ALI 5400
P003 TIROIR ALI 750
P030 FAUTEUIL BRAHIM 3000
P003 TIROIR KAMEL 600
P150 CHAISE KAMEL 1000
P150 CHAISE OMAR 900

Figure 3.1 Exemple de représentation d’une relation par une table : extension d’une relation

L’attribut Code_Produit a pour domaine de valeurs des chaînes de caractères


L’attribut Désignation a pour domaine de valeurs des chaînes de caractères
L’attribut Fournisseur a pour domaine de valeurs des chaînes de caractères
L’attribut Prix a pour domaine de valeurs des entiers

Le tuple : P002 ARMOIRE ALI 5400

indique par exemple que le produit dont le code est P002 et la désignation est ARMOIRE peut être
fourni par le fournisseur qui s’appelle ALI qui le vend au prix de 5400.

La cardinalité de cette relation est égale à 7 car le nombre de tuples de cette relation est 7. C’est
aussi le nombre de lignes de la table de la figure 3.1 qu’on peut noter : |CATALOGUE_PRIX | = 7.

A partir de la figure 3.1, on peut faire les remarques suivantes :

z Il n’y a pas deux tuples ou lignes identiques

z L’ordre d’apparition des tuples n’a pas de signification particulière si ce n’est que les tuples
peuvent être classés selon un critère appliqué aux valeurs d’un attribut ou colonne de la table
(ordre alphabétique des noms de fournisseurs, ordre croissant des codes de produits, etc.).
Par exemple les tuples de la relation CATALOGUE_PRIX sont classés selon un ordre
alphabétique de l’attribut FOURNISSEUR désignant le nom d’un fournisseur.

z L’ordre des attributs ou colonnes n’a pas de signification particulière. En effet, il faut
préciser d’une part que les noms donnés aux colonnes ou attributs de la relation doivent être
distincts et d’autre part que le nom d’un attribut renseigne généralement sur le domaine de
cet attribut. Ainsi, la définition d’une relation sur des attributs ayant le même nom traduisant
le fait que ces attributs ont implicitement le même domaine n’est pas possible car elle pose
des problèmes au niveau de l’association d’un sens à un attribut (ou une colonne) en fonction
de son ordre d’apparition dans le schéma de la relation (ou l’extension c’est à dire la table
représentant cette relation). L’exemple suivant va nous aider à expliquer ces problèmes :

Soit la relation COMPOSITION (Pièce, Pièce, Quantité) qui modélise le fait qu’une pièce p
est composée d’une certaine quantité q d’une autre pièce p’. Cette relation est défini sur trois attributs
dont les deux premiers possèdent le même nom Pièce signifiant implicitement qu’ils ont le même
domaine. Comme on peut le constater, il sera difficile pour ne pas dire impossible d’associer un sens à
ces deux attributs en fonction de leur ordre d’apparition c’est à dire le premier attribut de la relation ou
la première colonne de la table signifie la pièce composée, le deuxième attribut de la relation ou la
deuxième colonne de la table signifie la pièce composante ou inversement. Le seul moyen pour
Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •82

distinguer entre les attributs sera donc le nom qui leur sera donné. Dans ce cas, il faudra donner aux
attributs (ou colonnes de la table) des noms différents selon le rôle que joue chaque attribut dans la
relation. Dans notre exemple, on pourrait donner aux deux premiers attributs de la relation
COMPOSITION des noms tels que : COMPOSITION (Pièce_Composée,
Pièce_Composante, Quantité).

Si le schéma d’une relation est le nom de la relation suivi de la liste de ses attributs, L’extension
d’une relation est l’ensemble de ses tuples. Le terme extension fait donc référence au contenu de la
relation alors que le terme intention fait référence au contenant c’est à dire le schéma de la relation. Il
faut souligner qu’en général, on a tendance à utiliser de façon impropre le terme relation pour
désigner l’ensemble des tuples qui lui sont associés c’est à dire confondre le schéma de la relation
(contenant ou intention) avec son extension (contenu). Il serait cependant important de pouvoir
distinguer pour une relation donnée différentes extensions.

Par exemple la relation ayant pour nom PRODUIT_VENDUS et dont le schéma est :
PRODUIT_VENDUS(Code_Produit, Désignation, Prix) définissant la liste des produits vendus
par des fournisseurs avec pour chaque produit son code, sa désignation et son prix. La table ci-dessous
représente une extension de cette relation correspondant aux produits vendus par le fournisseur ALI.

Code_Produit Désignation Prix


P001 ETAGERE 1500
P002 ARMOIRE 5400
P003 TIROIR 750

Figure 3.2 une extension de la relation PRODUIT_VENDUS

Si on considère maintenant la liste des produits vendus par le fournisseur KAMEL, une autre
extension de la relation PRODUIT_VENDUS serait alors :

Code_Produit Désignation Prix


P003 TIROIR 600
P150 CHAISE 1000

Figure 3.3 une autre extension de la relation PRODUIT_VENDUS

Cette nouvelle table représente donc bien une autre extension de la même relation
PRODUIT_VENDUS. De là, il faut remarquer une chose importante c’est que le SGBD qui gère
toutes les relations ne peut en aucun cas distinguer deux extensions différentes de la même relation car
cette dernière n’est défini que par son schéma (nom de la relation plus ses différents attributs). On
notera au passage, que deux relations différentes c’est à dire qui différent par leur nom peuvent
posséder les mêmes attributs.

Afin de pouvoir distinguer les deux extensions de la relation PRODUIT_VENDUS , il faudra donc
soit les désigner par des noms différents (par exemple PRODUIT_ALI et PRODUIT_KAMEL) en
sachant que la première est celle relative au fournisseur ALI et que la deuxième est celle relative au
fournisseur KAMEL et qu’elles ont les mêmes attributs. L’autre solution consiste à rajouter un attribut
dans la relation PRODUIT_VENDUS tel que le nom du fournisseur (Nom_Fournisseur). Dans ce
cas, la nouvelle relation PRODUIT_VENDUS (ayant un attribut en plus) contiendra deux ensembles
de tuples correspondant aux deux extensions (i.e. aux deux tables) de la relation
PRODUIT_VENDUS de départ (sans l’attribut supplémentaire) avec en plus, à chaque tuple sera
rajoutée la valeur du nouvel attribut Nom_Fournisseur :

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •83

Code_Produit Désignation Prix Nom_Fournisseur

P001 ETAGERE 1500 ALI


P002 ARMOIRE 5400 ALI
P003 TIROIR 750 ALI
P003 TIROIR 600 KAMEL
P150 CHAISE 1000 KAMEL

Figure 3.4 Extension de la nouvelle relation PRODUIT_VENDUS

3.4.6 Clé d’une relation


3.4.6.1 Définition informelle

La clé d’une relation R est sous-ensemble d’attributs X dont les valeurs identifient un tuple et un
seul de la relation R. A tout moment la clé d’une relation possède les propriétés suivantes :

z Unicité : elle identifie un seul tuple de la relation


z Composition minimale : aucun attribut de la clé ne peut être éliminé sans détruire la
propriété d’unicité.

Dans le cas où on est pas en mesure d’identifier une clé pour une relation donnée, il faut rappeler
que toute relation possède au moins une clé à savoir : l’ensemble de ses attributs. En effet, d’après
la définition même d’une relation, celle-ci ne peut pas contenir deux tuples identiques (deux lignes
de la table ayant respectivement les mêmes valeurs dans les colonnes associées aux attributs). Ainsi,
deux tuples différent au moins par les valeurs d’un attribut.

Nous donnerons une définition plus formelle d’une clé lorsque nous aborderons le paragraphe
relatif à la théorie de la normalisation des relations.

3.4.6.2 Notion de clé candidate

Une relation peut posséder plus d’une clé satisfaisant toutes la définition donnée plus haut.
Chacune de ces clés sera appelée une clé candidate.

3.4.6.3 Notion de clé primaire

Lorsqu’on dispose pour une relation donnée de plusieures clés candidates, il est nécessaire de ne
retenir qu’une seule parmi cet ensemble La clé retenue s’appellera alors la clé primaire. Elle sera
utilisée effectivement pour repérer de manière unique les tuples de la relation. La clef primaire devra
impérativement être déclarée au moment de la description ou de la définition de la relation au niveau
du SGBD.

Le choix de la clé primaire est généralement effectué en fonction des deux critères suivants :

z On choisit la clé candidate ayant le plus petit nombre d’attributs : il est préférable de
minimiser le nombre d’attributs composant la clé.

z On choisit la clé candidate en fonction de son usage pour la localisation des tuples : il s’agit
de privilégier la clé candidate dont l’usage serait le plus fréquent pour localiser les tuples de
la relation.
Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •84

3.4.6.5 Notion d’attribut primaire

On appelle attribut primaire tout attribut appartenant à une clef candidate (ou à plusieurs clés
en même temps) d’une relation.

Par exemple dans la relation R(A, B, C, D) ayant deux clefs candidates (A,B) et (A,C) , les
attributs primaires sont : A, B et C.

On remarque que l’attribut D n’appartient à aucune clé candidate. Un tel attribut sera dit attribut
non primaire.

L’attribut primaire A appartient en même temps aux deux clés candidates de R.

3.4.6.6 Remarques importantes

Toute clé candidate qui n’a pas été retenue comme clé primaire constitue ce que l’on appelle une
clé secondaire. Sur le plan pratique, la clé primaire et les clés secondaires peuvent servir à définir
des index qui permettent de réaliser des accès sélectifs aux tuples de la relation. Cependant, il faut
souligner que cette distinction entre clé primaire et clé secondaire ou candidate n’a d’intérêt que sur
le plan théorique puisqu’au niveau du SGBD on peut en général construire un index sur tout attribut
ou ensemble d’attributs même s’il ne constitue pas une clé.

4 Démarche de conception d’un schéma relationnel


4.1 Problèmes posés au niveau de la modélisation
La phase de modélisation est une phase très importante dans tout projet de conception. L’un des
objectifs principaux visés par le modèle relationnel est de mettre à la disposition du concepteur une
méthodologie pour l’aider dans la conception du schéma conceptuel de la base de données.

L’inconvénient des modèles réseau et hiérarchique est justement de ne proposer aucune aide à ce
niveau. La démarche de conception consistant à utiliser des boîtes et des flèches pour représenter
graphiquement le schéma conceptuel de la base de données avant de le décrire à l’aide d’un LDD,
certes facilite le travail mais ne permet en aucun cas de juger de la qualité du schéma conceptuel
obtenu. Le seul intérêt de cette démarche est que le concepteur peut dessiner son modèle sur papier,
détecter les anomalies, le discuter avec d’autres personnes, etc. De plus la traduction du schéma en un
programme est grandement simplifiée du fait qu’il y a correspondance entre boîte et enregistrement ou
segment et entre flèche et SET ou lien PARENT-ENFANT.

Avec le modèle relationnel, dessiner sur papier le schéma conceptuel de la base de données revient
à représenter graphiquement chaque relation à l’aide d’une table. Une telle représentation ne permet
pas de distinguer facilement une entité d’une association, ni de servir de support de communication si
on a à discuter le schéma conceptuel avec d’autres personnes. Il est même possible d’utiliser une
représentation du schéma par boîtes et flèches comme dans les autres modèles et de le traduire ensuite
en termes de relations. Généralement, on préfère utiliser un autre formalisme tel que celui du modèle
entité-association offrant une aide au niveau de la phase de modélisation même si cela demande un
travail supplémentaire de transformation de ce modèle vers le modèle relationnel.

Compte tenu de toutes ces précisions, il devient clair que si on ne dispose pas d’une aide au niveau
de la modélisation, ni d’une métrique pour juger de la qualité du schéma conceptuel, il n’est pas exclu
que des erreurs de conception aient lieu et peuvent conduire à un schéma mal conçu qui peut poser des
problèmes lors de l’exploitation de la base de données. L’exemple suivant va nous permettre de mettre

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •85

en évidence certains problèmes typiques qui peuvent être la conséquence d’un schéma mal conçu :

Supposons que nous avons à concevoir le schéma d’une base de données devant servir à mettre en
place une application de gestion des prêts au sein d’une bibliothèque universitaire. On suppose qu’on
a décidé de modéliser cette réalité par une seule entité que nous traduisons dans le formalisme du
modèle relationnel à l’aide d’une seule relation ayant pour schéma : PRET (Lecteur, Nom, Livre,
Titre, Auteur, DatePrêt). Considérons maintenant l’extension suivante de la relation PRET :

Lecteur Nom Livre Titre Auteur DatePrêt


LEC025 BENALI L0010 Programmer en M. DESMADRIL 25/12/1997
c++
LEC032 BENOMAR L0220 Les misérables V. HUGO 01/10/1996
LEC025 BENALI L1500 Introduction au J. DE LAGARDE 30/12/1997
PASCAL
LEC070 BENKADA ????? ????? ????? ?????
????? ????? L3000 La synthèse F. MARTINEZ ?????
d’images
••••••• ••••••• ••••••• ••••••••• ••••••••• •••••••••

Figure 3.5 Extension de la relation PRET

En examinant cette extension on peut faire les remarques suivantes :

z Il existe des redondances dans les données contenues dans cette table. Chaque lecteur est
répété autant de fois qu’il a emprunté de livres ce qui pose des problèmes de mise à jour
car si on doit modifier la valeur d’un attribut tel que le numéro de lecteur, le nom ou
l’adresse, il faudra le faire dans tous les tuples associés à ce lecteur. C’est le cas des
tuples dont la valeur de l’attribut Lecteur est égale à LEC025.
z Il faut autoriser la présence de tuples à moitié vides correspondant aux lecteurs n’ayant
pas empruntés de livres et aux livres n’ayant pas été empruntés. Pour de tels tuples, il sera
très difficile sinon impossible de choisir des valeurs par défaut pour compléter celles
associées aux attributs non connus(symbolisés par ?????? dans la figure ci-dessus). C’est
le cas du quatrième et du cinquième tuple qui correspondent respectivement au cas d’un
lecteur n’ayant pas emprunté de livres et au cas d’un livre n’ayant pas encore été
emprunté.

Les problèmes que nous venons d’identifier sont la conséquence d’une mauvaise conception ayant
conduit à un schéma composé d’une seule relation alors qu’il aurait peut être fallu au moins trois : une
modélisant un lecteur, une un livre et la troisième l’association entre un lecteur et un livre qui traduit
l’opération d’emprunt. Une mauvaise perception de la réalité à modéliser peut ainsi conduire à un
schéma mal conçu composé de relations qui rendent difficile leur manipulation aussi bien pour le
SGBD que pour l’utilisateur.

4.2 L’approche de modélisation par décomposition


Parmi les objectifs du modèle relationnel, nous avons souligné celui de fournir une approche
méthodologique pour la conception du schéma relationnel. L’approche par décomposition est
justement une approche méthodologique permettant d’aboutir à un schéma conceptuel ou relationnel
qu’on peut qualifier de schéma acceptable.

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •86

Cette approche consiste à partir d’une relation composée de tous les attributs qu’on appelle aussi
relation universelle et à la décomposer en plusieurs autres relations qui ne poseraient plus de
problèmes. Cette décomposition est réalisée par application d’un algorithme qui nécessite en entrée les
liens sémantiques qui existent entre les attributs et qu’on appelle dépendances entre attributs
(fonctionnelles ou autres). Ce processus de décomposition est schématisé par la figure suivante :

Sémantique des Données

•Lecteur

•Titre
Algorithme de
•Nom Décomposition
•Auteur

{
•DatePrêt

•Livre
LECTEUR (Lecteur, Nom)
LIVRE (Livre, Auteur, Titre)
PRET (Lecteur, Livre, DatePrêt )
Attributs de la Relation Universelle

Résultat de la Décomposition = Un ensemble de Relations

Figure 3.6 Algorithme de décomposition d’une relation

Si nous reprenons l’exemple de la gestion des prêts, les relations qui pourraient résulter de
l’application de l’algorithme de décomposition à la relation universelle sont : LECTEUR , LIVRE et
PRET. Bien sûr nous connaissons la liste des attributs de la relation universelle qui est utilisée comme
entrée par l’algorithme mais nous devons aussi fournir à ce même algorithme des informations sur la
sémantique des données. Pour fixer les idées, nous nous contenterons à ce niveau de préciser
simplement que la sémantique des données sera généralement exprimée sous forme d’une liste de
dépendances fonctionnelles. Cette notion de dépendance fonctionnelle sera définie plus loin dans ce
chapitre ce qui nous permettra alors d’expliquer son utilité

4.3 Définition d’une décomposition


D’après le schéma de fonctionnement de l’algorithme de décomposition, la décomposition d’une
relation R(A1 , A2 , A3 ,..... An ) peut être définie comme étant le remplacement de cette relation par
un ensemble de relations R1 , R2 ,..... Rm dont chacune est obtenue par application d’une opération de
projection à la relation R et telle que la jointure naturelle de ces relations donne comme résultat une
relation ayant le même schéma que R. Ceci revient à dire que l’union des attributs des différentes Ri
est un ensemble d’attributs égal à (A1 , A2 , A3 ,..... An ) .

On remarque que cette définition utilise les termes de projection et de jointure. Ce sont deux
opérations très importantes dans les langages de manipulation de données relationnels que nous allons
introduire afin de bien assimiler la définition d’une décomposition. Ces opérations seront étudiées en
détail dans le chapitre traitant de l’algèbre relationnelle.

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •87

4.3.1 Projection

La projection est une opération qui consiste à supprimer des attributs d’une relation R(A1 , A2 ,
......, An) et à supprimer les tuples en double qui peuvent apparaître dans la relation résultant de cette
opération. Nous devons remarquer qu’on aurait pû remplacé dans cette définition le terme «attributs»
par celui de « colonnes », le terme « relation » par celui de « table » et le terme « tuples » par celui de
« lignes ». Le résultat de cette opération sera donc une nouvelle relation qui possède son propre
schéma (nom et liste d’attributs) et sa propre extension (ensemble de tuples).

On note cette opération par : Π Ai1 , Ai2 , ..... , Aik ( R ) qui signifie que la nouvelle relation aura
pour attributs l’ensemble Ai1 , Ai2 , ..... , Aik. Il s’agira donc de supprimer de R tous les attributs qui
n’appartiennent pas à cet ensemble et à supprimer ensuite les tuples en double qui apparaîtront dans la
nouvelle relation. Il faut remarquer que dans l’ensemble d’attributs Ai1 , Ai2 , ..... , Aik , chaque attribut
n’apparaît qu’une seule fois. Par exemple la projection de la relation :

CATALOGUE_PRIX (Code_Produit , Désignation , Fournisseur , Prix) sur les attributs


(Code_Produit, Désignation) donnerait une nouvelle relation qu’on pourrait appeler Liste_Produit
ayant pour schéma : Liste_Produit(Code_Produit , Désignation), et pour extension :

Code_Produit Désignation Code_Produit Désignation


P001 ETAGERE P001 ETAGERE
P002 ARMOIRE P002 ARMOIRE
P003 TIROIR P003 TIROIR
P030 FAUTEUIL P030 FAUTEUIL
P003 TIROIR P150 CHAISE
P150 CHAISE
P150 CHAISE

(a) Avant suppression des tuples en double (b) Après suppression des tuples en double

Figure 3.7 Application d’une opération de projection à une relation

4.3.2 Jointure naturelle

La jointure naturelle de deux relations R et S dont les schémas ne sont pas disjoints (R et S ont au
moins un attribut commun) est une relation T ayant pour attributs l’union des attributs de R et S et
pour tuples l’ensemble des tuples obtenus par concaténation des tuples de R et S ayant les mêmes
valeurs pour les attributs de même nom

On note cette opération par : R S

Exemple :

Soit les deux relations Liste_Produit (Code_Produit , Désignation) et Vendu_Par


(Code_Produit, Fournisseur, Prix) ayant respectivement pour extension :

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •88

Code_Produit Désignation Code_Produit Fournisseur Prix


P001 ETAGERE P001 ALI 1500
P002 ARMOIRE P002 ALI 5400
P003 TIROIR P003 ALI 750
P030 FAUTEUIL P030 BRAHIM 3000
P150 CHAISE P003 KAMEL 600
P150 KAMEL 1000
P150 OMAR 900

(a) Extension de la relation Liste_Produit (b) Extension de la relation Vendu_Par

Figure 3.8 Résultat d’une opération de projection

• Ces deux relations ont un seul attribut commun (de même nom), c’est Code_Produit. Les
tuples de la relation résultant de la jointure entre ces deux relations seront construits en
prenant un tuple de la première relation et pour chaque tuple de la deuxième relation ayant la
même valeur de l’attribut Code_Produit, générer un tuple dans la nouvelle relation résultat
par concaténation des deux tuples des relations Liste_Produit et Vendu_Par.

• Si on considère par exemple que la première relation est Liste_Produit, le troisième tuple de
cette relation est :

P003 TIROIR

• En parcourant les tuples de la deuxième relation qui sera donc Vendu_Par on s’aperçoit
qu’il y a deux tuples qui ont la même valeur de l’attribut Code_Produit qui est P003. Ce
sont les tuples :

P003 ALI 750 et P003 KAMEL 600

Dans ce cas on va construire dans la relation résultat de l’opération de jointure naturelle, les deux
tuples suivants :

P003 TIROIR ALI 750 et P003 TIROIR KAMEL 600

On remarque que lors de l’opération de concaténation on tient compte du fait que l’ordre des
colonnes n’a pas d’importance et que la colonne Code_Produit doit figurer une seule fois dans le
tuple construit, ce qui est tout à fait logique puisqu’on est sûr que dans les deux tuples des relations
Liste_Produit et Vendu_Par on a la même valeur de l’attribut Code_Produit qui est P003.

 L’opération de jointure naturelle est une opération associative et commutative.

1) R S = S R

2) ((R S) V) = (R (S V) )

• La commutativité signifie que dans l’algorithme de construction de la relation résultat de la

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •89

jointure naturelle entre R et S (dont le principe a été expliqué plus haut), on peut soit considérer
comme première relation R et comme deuxième relation S ou bien l’inverse.

• Pour l’associativité, il faut en premier souligner que si on a à calculer la jointure naturelle entre
trois relations R , S et V (ou plus !), il faudra procéder par étape puisque cette opération est une
opération binaire qui ne s’applique qu’à deux relations seulement. Ainsi, l’associativité signifie
qu’on peut soit calculer d’abord la jointure entre R et S obtenant ainsi une relation résultat
TEMP puis calculer la jointure entre TEMP et V qui donnera la relation constituant le résultat
final, soit calculer d’abord la jointure entre S et V obtenant ainsi une relation résultat TEMP’
puis calculer la jointure entre TEMP’ et R qui donnera la relation constituant le résultat final.

4.4 Qualité d’une décomposition


Nous avons vu que la décomposition d’une relation R consiste à remplacer cette relation par un
ensemble de relations R1 , R2 , ..... Rm dont chacune est obtenue par application d’une opération de
projection à la relation R . De plus, la jointure naturelle de ces relations doit donner comme résultat
une relation R’ ayant le même schéma que R. On remarque donc qu’une relation peut être
décomposée de différentes manières. Il serait alors intéressant de savoir si R et R’ ont aussi la même
extension. Dans ce cas, si on avait à choisir parmi toutes les décompositions possibles de R, il serait
préférable de choisir celle(s) dont la jointure naturelle des relations constituant la décomposition
donne une relation ayant le même schéma que R et la même extension. C’est ainsi qu’on qualifie une
décomposition de décomposition sans perte d’information par opposition à une autre qui se fait avec
perte d’information.

4.4.1 Décomposition sans perte d’information

Une décomposition d’une relation R en R1 , R2 , .....; Rm sera dite sans perte d’information si et
seulement si :

1) R1 R2 ...... Rm a le même schéma que R

2) ∀ l’extension de R, (R1 R2 ..... Rm) a la même extension que R

4.4.2 Décomposition avec perte d’information

Par définition on sait que toute décomposition d’une relation R en R1 , R2 , ..... , Rm est telle que la
jointure naturelle de R1 , R2 , ..... Rm est une relation qui a le même schéma que R. Donc une
décomposition sera qualifiée de décomposition avec perte d’information si elle ne vérifie pas la
deuxième condition donnée plus haut c’est à dire que l’extension de la relation résultant de la jointure
naturelle de R1 , R2 , ....., Rm n’est pas égale à celle de R.

Considérons de nouveau la relation CATALOGUE_PRIX (Code_Produit, Désignation, Fournisseur,


Prix) avec l’extension suivante pour simplifier le calcul des jointures:

Code_Produit Désignation Fournisseur Prix


P001 ETAGERE ALI 1500
P002 CHAISE OMAR 1500

Figure 3.9. Une extension de la relation CATALOGUE_PRIX

Cette relation peut être décomposée de plusieurs façons. Nous allons considérer les deux
décompositions suivantes :
Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •90

1) R1(Code_Produit, Désignation, Fournisseur) ; R2(Désignation, Prix)

2) S1(Code_Produit, Fournisseur, Prix) ; S2(Désignation, Prix)

a) les relation R1 et R2 ont respectivement pour extension :

R1 R2
Code_Produit Désignation Fournisseur Désignation Prix
P001 ETAGERE ALI ETAGERE 1500
P002 CHAISE OMAR CHAISE 1500

Figure 3.10 Extensions de R1 et de R2

Calculons la jointure naturelle entre R1 et R2 qui ont comme attribut commun : Désignation. Nous
appellerons cette relation R’. Le premier tuple de R1 et le premier tuple de R2 ont la même valeur de
l’attribut Désignation (i.e. ETAGERE ), donc on construit un tuple dans R’ par concaténation de ces
deux tuples. On aura le tuple :

P001 ETAGERE ALI 1500

On refait la même travail avec le deuxième tuple de R1 et le deuxième tuple de R2 qui ont aussi la
même valeur de l’attribut Désignation. Le tuple obtenu dans R’ par concaténation de ces deux tuples
sera :

P002 CHAISE OMAR 1500

Donc R’ aura pour extension :

Code_Produit Désignation Fournisseur Prix


P001 ETAGERE ALI 1500
P002 CHAISE OMAR 1500

Figure 3.11 Résultat de l’opération de jointure entre R1 et R2

On remarque que R’ a le même schéma et la même extension que R. Donc, on peut dire que cette
décomposition est une décomposition sans perte d’information ou aussi que cette décomposition
préserve les données.

b) Dans la seconde décomposition, les relation S1, S2 ont respectivement pour extension :

Code_Produit Fournisseur Prix Désignation Prix


P001 ALI 1500 ETAGERE 1500
P002 OMAR 1500 CHAISE 1500

(1) extension de S1 (2) extension de S2

Figure 3.12 Extensions de S1 et de S2

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •91

Calculons la jointure naturelle de S1 et S2 qui ont comme attribut commun Prix. On aura la
relation qu’on appellera S’ ayant pour schéma S’(Code_Produit, Désignation, Fournisseur, Prix) et
pour extension :

Code_Produit Désignation Fournisseur Prix


P001 ETAGERE ALI 1500
P001 CHAISE ALI 1500
P002 ETAGERE OMAR 1500
P002 CHAISE OMAR 1500

Figure 3.13 Résultat de l’opération de jointure entre S1 et S2

On remarque que S’ a le même schéma que R mais n’a pas la même extension. Donc, on peut
dire que cette décomposition est une décomposition avec perte d’information ou aussi que cette
décomposition ne préserve pas les données.

En effet, les deux tuples suivants :

P001 CHAISE ALI 1500

P002 ETAGERE OMAR 1500

n’appartiennent pas à R mais appartiennent à S’. Ceci pose un problème car avant de décomposer
R en {S1 , S2} , on était en mesure de retrouver la désignation du produit P001 ou celle de P002. Par
exemple pour P001 c’est ETAGERE et pour P002 c’est CHAISE. En décomposant la relation, on
s’aperçoit que la relation S’ même si elle a un schéma identique à celui de R, ne permet plus d’obtenir
la même réponse à la même question. Par exemple avec S’, pour P001 on a deux désignations
différentes ETAGERE et CHAISE ce qui est faux car avec R, la désignation du produit P001 est
ETAGERE. On voit donc qu’une telle décomposition posera à coups sûrs des problèmes. C’est pour
cela qu’il va falloir privilégier parmi l’ensemble des décompositions possibles pour une relation, une
parmi celles préservant les données (il peut en exister plusieurs!).

5 Dépendances Fonctionnelles

5.1 Généralités
Lorsqu’une relation est définie sur un ensemble d’attributs, ceci sous entend que ces attributs ont
un lien sémantique entre eux qui se traduit par le fait que tout tuple de la relation véhicule une
information ayant un sens pour le concepteur. Les dépendances fonctionnelles servent à exprimer des
propriétés entre les attributs d’une relation que l’on souhaite maintenir à vraies durant toute la durée de
vie de la base de données.

5.2 Définition
Etant donnée une relation R ayant pour schéma R (A1, A2, ......, An) et soient X et Y des sous-
ensembles d’attributs de (A1, A2, ......, An) , on dit que X → Y (X détermine Y ou bien Y dépend
fonctionnellement de X) si pour toute extension de R, et quelque soient les tuples t1 et t2 de cette
extension on a:

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •92

Si ∏ X (t1) = ∏ X (t2) ⇒ ∏ Y (t1) = ∏ Y (t2) (ou ∏ est le symbole de l’opération de


projection)

Ceci revient à dire que X → Y si et seulement si, lorsqu’on a deux lignes dans la table contenant
l’extension de la relation, si les valeurs se trouvant dans la colonne correspondant à l’attribut X sont
égales, alors pour ces même lignes, les valeurs se trouvant dans la colonne correspondant à l’attribut Y
sont aussi égales.

Nous devons souligner que les dépendances fonctionnelles sont des assertions sur le monde réel
qu’on tente de modéliser. Elles définissent les propriétés que doivent vérifier les attributs entre eux et
il est donc incorrecte de vouloir les déduire à partir d’une extension de la relation.

Nous utiliserons dans la suite l’abréviation D.F. ou d.f. pour désigner une dépendance
fonctionnelle.

5.3 Propriétés des dépendances fonctionnelles


Les dépendances fonctionnelles possèdent trois propriétés fondamentales qu’on appelle
couramment les axiomes d’Armstrong car mises en évidence par W. Armstrong. En supposant que X,
Y , Z, sont trois ensembles d’attributs, il est utile de faire les remarques suivantes avant d’énoncer les
propriétés :

z L’écriture X , Z est une écriture simplifiée de l’union ensembliste des deux ensembles
d’attributs X et Z. Ceci veut dire que l’écriture X , Z devra être interprétée comme X ∪ Z .

z Il faut souligner aussi que l’union ensembliste est un opérateur associatif et


commutatif :

((X ∪ Y) ∪ Z ) = (X ∪(Y ∪ Z))

X∪Z =Z∪X

5.3.1 Réflexivité

Si X⊆Y ⇒ Y → X

Ex : A ⊆ A,B ⇒ A,B →A et A,B → B

5.3.2 Transitivité

Si X → Y et Y → Z ⇒ X → Z

Ex : A,B →C et C → D ⇒ A,B →D

5.3.3 Augmentation

Si X → Y ⇒ ∀Z X , Z → Y, Z

Ex : A,B →C ⇒ A,B,D →C,D

A partir de ces trois axiomes de base, on peut déduire facilement d’autres propriétés très utiles en
pratiques. Les plus remarquables sont :
Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •93

5.3.4 Union des parties droites

Si X → Y et X → Z ⇒ X → Y, Z

Ex : A →C et A →D ⇒ A →C,D

5.3.5 Décomposition

Si X → Y, Z ⇒ X → Y et X → Z

Ex : A →C,D ⇒ A →C et A →D

5.3.6 Pseudo Transitivité

Si X → Y et Y , W → Z ⇒ X , W → Z

Ex : A →C et B,C →D ⇒ A,B → D

5.3.7 Distributivité par rapport à l’union

Si X → U ⇒ ∀ ui ⊆ U X → ui (c’est une généralisation de la


décomposition)

Ex : A →C,D,E,F ⇒ A → C et A → D et A → E et A → F

A,B →C,D,E ⇒ A,B → C et A,B → D et A,B → E

(" Démontrer ces propriétés à partir des axiomes d’Armstrong ?)

5.4 Dépendance fonctionnelle élémentaire

On appelle dépendance fonctionnelle élémentaire une dépendance de la forme : X → A , ou A


est un attribut unique non inclus dans X ( A ⊄ X), tel que ∀ X’ ⊂ X, il n’existe pas de dépendance
fonctionnelle X’ → A .

En d’autres termes, une dépendance fonctionnelle est élémentaire si elle n’est pas obtenue par
augmentation de sa partie gauche.

exemple :

Si on considère les deux D.F. :

(NUMERO, NOM ) → ADRESSE (1)


NUMERO → ADRESSE (2)

la D.F. (1) est une D.F. non élémentaire car NUMERO ⊂ (NUMERO,NOM) et il
existe la D.F. NUMERO → ADRESSE.

Par contre la D.F. (2) est une D.F. élémentaire car elle vérifie les propriétés d’une
D.F. élémentaire.

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •94

5.5 Dépendance fonctionnelle transitive

On appelle dépendance fonctionnelle transitive une dépendance de la forme : X → A , ou A est


un attribut unique non inclus dans X ( A ⊄ X), tel que :

∃ Y ⊄ X, X → Y et Y → A et Y /→ X

Dans ce cas, on dit aussi que A est transitivement dépendant de X. Dans le cas où A n’est pas
transitivement dépendant de X, on dit que A est directement dépendant de X (voire plus loin la
définition d’une d.f. directe ).

exemple :

Si on considère les D.F. :

c A → B dB → C eA → C
f D → B gD → C hB → D

La D.F. A → C est transitive car ∃ B ⊄ A tel que :

A → B et B → C et B /→ A

Par contre la D.F. D →C n’est pas transitive puisque ∃ B ⊄ D tel que :

D → B et B → C mais B → D

5.6 Dépendance fonctionnelle directe

On appelle dépendance fonctionnelle directe une dépendance de la forme X → A , ou A est un


attribut unique non inclus dans X ( A ⊄ X), tel que :

∀ Y ⊄ X, si X → Y et Y → A alors la d.f. Y → X existe aussi

exemple :

Si on considère les D.F. :

c A → B dB → C eA → C
f D → B gD → C hB → D

La D.F. A → C n’est pas directe car pour B ⊄ A on a :

A → B et B → C =/=> B → A

La D.F. D →C est directe puisque pour B ⊄ D on a :

D → B et B → C ⇒ B → D existe

La D.F. A →B est directe puisque il n’existe pas d’attribut Y ⊄ A tel qu’on a en
même temps les d.f. A →Y et Y →B pour vérifier s’il y a ou non contradiction
avec la définition. Dans ces cas là , la d.f. est forcément directe.

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •95

Dans le cas où A n’est pas directement dépendant de X (i.e. la d.f. Y → X n’existe pas), on dit
que A est transitivement dépendant de X.

5.7 Dépendance fonctionnelle totale, pleine ou complète


On appelle dépendance fonctionnelle totale , pleine ou complète une dépendance fonctionnelle de
la forme X → A , ou A est un attribut unique non inclus dans X ( A ⊄ X), telle que ∀ X’ ⊂ X , il
n’existe pas de dépendance fonctionnelle X’ → A . En d’autres termes, la dépendance X → A est
élémentaire.

Dans ce cas on dit aussi que A est pleinement ou totalement ou complètement dépendant de X.
Dans le cas contraire, on dit aussi que A est partiellement dépendant de X (i.e. A dépend d’une
partie de X et donc forcément de X aussi par augmentation)

exemple :

Si on considère les D.F. :

c A ,B → C dB → C e B,C → D

dans la d.f. c C n’est pas totalement dépendant de A ,B car on a B ⊂ A,B tel que B →
C. On peut dire que C est partiellement dépendant de A,B.

dans la d.f. e D est totalement dépendant de B,C car il n’existe pas de X’ ⊂ B ,C et tel
que X’ → D.

5.8 Dépendance fonctionnelle triviale

On appelle dépendance fonctionnelle triviale une dépendance fonctionnelle de la forme X → Y


, tel que Y ⊆ X. En d’autres termes, une dépendance fonctionnelle est triviale si elle est obtenue
grâce à la propriété de réflexivité.

exemple : Si on considère les D.F. :

c A ,B → B d B,C → C e A ,C→ D

la d.f. c est triviale car on a B ⊂ A ,B


la d.f. d est triviale car on a C ⊂ B ,C
la d.f. e n’est pas triviale car on a D ⊄ A ,C

Comme nous le verrons plus loin, les notions de dépendance fonctionnelle élémentaire, de
dépendance fonctionnelle totale, de dépendance fonctionnelle directe vont intervenir dans la définition
des formes normales d’une relation et principalement la deuxième et la troisième formes normales.

5.9 Représentation graphique des dépendances fonctionnelles


Il est tout à fait possible de visualiser à l’aide d’un graphe un ensemble de dépendances
fonctionnelles. Dans le cas où les parties gauches sont composées d’un seul attribut, il s’agira de
représenter chacun de ces attributs par un nœud du graphe auquel on donnera comme nom le nom de
l’attribut qu’il représente. Dans le cas où la partie droite d’une D.F. est composée de plusieurs
attributs, on peut en appliquant la propriété de décomposition remplacer cette D.F. par un ensemble de

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •96

D.F. ayant toutes un seul attribut en partie droite. Ainsi, à chaque attribut apparaissant en partie droite
et non encore représenté dans le graphe, on lui associe un nœud qui porte son nom. Ensuite, on mettra
un arc orienté entre deux nœuds X et Y chaque fois qu’il y a une D.F. ayant comme partie gauche X et
comme partie droite Y.

Soient les D.F. suivantes :

NUMERO → NOM , ADRESSE (1)


NOM → PRENOM (2)

Pour pouvoir représenter ces D.F. sous forme d’un graphe , on applique à la première D.F. la
propriété de décomposition de façon à avoir deux D.F. ayant un seul attribut en partie droite. Ceci va
donner :

NUMERO → NOM
NUMERO → ADRESSE

On aura alors le graphe suivant :

NUMERO NOM

ADRESSE PRENOM

Figure 3.14 (a) Représentation graphique d’un ensemble de d.f

Dans le cas où l’on a des D.F. dont les parties gauches ne sont pas composées d’un seul attribut
mais de plusieurs, et comme il n’existe aucune propriété qui permet de décomposer la partie gauche
d’une D.F., la représentation graphique de ce type de D.F. se complique et le graphe de représentation
n’est plus un graphe simple.

soient les D.F. suivantes :

ETUDIANT, MODULE → PROF


ETUDIANT, MODULE → SALLE
PROF → BUREAU
PROF, MODULE → HEURE

M ODULE PR OF HE UR E

ETUDIANT BURE AU

SALLE

Figure 3.14 (b) Représentation graphique d’un ensemble de d.f

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •97

6 Fermeture d’un ensemble de dépendances


Fonctionnelles

6.1 Définition
Le fermeture d’un ensemble de dépendances fonctionnelles F et qu’on note F+ s’obtient à partir de
F par application des propriétés des dépendances fonctionnelles qui permettent de générer d’autres
dépendances fonctionnelles. L’application successives de ces propriétés sur un ensemble initial F de
dépendances conduit à augmenter progressivement F avec de nouvelles dépendances. Néanmoins, à
partir d’un certain moment, l’ensemble obtenu va devenir stationnaire : on dit que l’on a obtenu la
fermeture F+ de F.

Il faut dès lors souligner que les nouvelles dépendances obtenues par applications des propriétés
sont en fait redondantes puisqu’elles s’obtiennent à partir d’autres. Le problème va consister donc à
éliminer ce type de dépendances afin de ne conserver qu’un ensemble minimal de dépendances
représentant la même sémantique que l’ensemble initial mais sans redondance. Cet ensemble s’appelle
une couverture minimale de l’ensemble initial F.

Il faut noter aussi que la fermeture F+ peut comporter beaucoup plus de dépendances que F et plus
le nombre de dépendances de F est grand plus le calcul de F+ sera long. En pratique, on ne sera
presque jamais amené à calculer l’ensemble F+.

6.2 Equivalence entre deux ensembles de dépendances


fonctionnelles
On dit que deux ensemble F et G de dépendances fonctionnelles sont équivalents si et seulement si
la fermeture de F est égale à celle de G :

F+ = G+

6.3 Couverture minimale d’un ensemble de dépendances


fonctionnelles

6.3.1 Définition

La couverture minimale d’un ensemble de dépendances fonctionnelles F qu’on notera CF, est un
ensemble de dépendances fonctionnelles équivalent à F (CF+ = F+ ) et ayant les propriétés suivantes :

1- Toute dépendance fonctionnelle de CF à une partie droite unique (composée d’un seul
attribut)

2- ∀ X → A ∈ CF et Z ⊂ X , {(CF - X → A) ∪ Z → A } n’est pas équivalent à CF

3- ∀ X → A ∈ CF , CF - ( X → A ) n’est pas équivalent à CF

• La propriété (1) peut s’obtenir en décomposant toute d.f. dont la partie droite n’est pas
unique grâce à l’axiome de décomposition. Ceci permet de manipuler des d.f. ayant une
partie droite simple.
• La propriété (2) permet de garantir qu’aucun attribut dans la partie gauche d’une D.F. de CF

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •98

n’est redondant. Elle permet de supprimer les d.f. obtenues par application de l’axiome
d’augmentation.
• La propriété (3) permet de garantir qu’aucune d.f. n’est redondante dans CF

6.3.2 Remarque

Tout ensemble de dépendances fonctionnelles F possède au moins une couverture minimale


ayant les propriétés citées plus haut. Une telle couverture s’obtient par construction à partir de F en
satisfaisant les propriétés indiquées plus haut. Elle sert principalement comme entrée à l’algorithme
de décomposition en troisième forme normale qui sera présenté plus loin dans ce chapitre.

6.4 Fermeture d’un ensemble d’attributs


6.4.1 Utilité

Lors de la décomposition d’une relation vérifiant un ensemble de dépendances fonctionnelles, il est


important de pouvoir vérifier si cette décomposition préserve les dépendances fonctionnelles. Pour
cela, il faudra impérativement calculer la fermeture F+ de l’ensemble F des dépendances vérifiées par
la relation décomposée. Or, comme nous l’avons remarqué plus haut, plus le nombre de dépendances
dans F est grand, plus le temps de calcul de F+ sera grand.

Il existe une autre méthode pour vérifier si une dépendance fonctionnelle X → Y est perdue ou
non lors d’une décomposition c’est à dire si X → Y ∈ ou non à F+ sans passer par le calcul de F+ .
Cette méthode est justement basée sur la notion de fermeture d’un ensemble d’attributs.

6.4.2 Définition

Formellement, la fermeture d’un ensemble d’attributs X et qu’on note X+ est aussi un ensemble
d’attributs tel que : X+={ ∪Ai / X → Ai peut être déduite de F par application des axiomes
d’Armstrong }.

L’intérêt pratique de calculer X+ est donc de pouvoir vérifier facilement si X → Y ∈ ou non à F+


sans être amené à calculer F+

6.4.3 Lemme

Une dépendance fonctionnelle V → U ∈ F+ si et seulement si U ⊆ V+ où V+ est la fermeture de


l’ensemble d’attributs V relativement à l’ensemble de dépendances fonctionnelles F et contient tous
les attributs A tel que la dépendance fonctionnelle V → A peut être déduite de F par application des
axiomes d’Armstrong. Ce lemme peut être utilisé pour montrer qu'une D.F. est redondante dans un
ensemble F de dépendances fonctionnelles ( Voire l'exemple plus loin).

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •99

6.4.4 Algorithme de calcul de X +

Fermeture (X)
$ entrée :
X un ensemble d’attributs
F un ensemble de dépendances fonctionnelles
$ Sortie :
X + : Fermeture de X par rapport à F
Début
| X + ← X ;
| Fin ← Faux;
|
| Tant que  Fin faire
||
|| Temp ← X + ;
||
|| Pour toute dépendance fonctionnelle Y → Z de F Faire
|| |
|| | Si Y⊆X+
|| | alors X + ← X + ∪ Z;
|| | Fin si
|| Fin Pour
|| Si Temp = X + Alors Fin ← Vrai ;
| Fin Tan que
Fin
Fin Fermeture

exemple :

Soit l’ensemble F de d.f. :

F={ AB → C ; c
C → A ; d
BC → D ; e
ACD → B; f
D → EG ; g
BE → C; h
CG → BD ; i
CE → AG j
}

- Calculons la fermeture (BD)+ de l’ensemble d’attributs (BD)

étape 0 : (BD) + = {BD}


étape 1 : (BD) + = {BDEG} car dans g on a D ⊆ (BD) +.
on ajoute EG à (BD) +

étape 2 : (BD) + = {BDEGC} d’après h

étape 3 : (BD) + = {BDEGCA} d’après j

on remarque que (BD) + contient tous les attributs. Donc, on s’arrête car quelque soit
la d.f. à examiner et l’attribut à rajouter ça ne changera pas (BD) +.On est dans le
Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •100

critère d’arrêt de l’algorithme TEMP = (BD) +.

- Vérifions si la d.f. CG → B est redondante dans F

(indication : on calcule la fermeture (CG) + de CG relativement à { F - CG → B }


et on voit si B ⊆ CG+ ).

On va donc travailler avec F’= F - CG → B

étape 0 : (CG) + = {CG}


étape 1 : (CG) + = {CGD} grâce à la d.f. CG → D
étape 2 : (CG) + = {CGDA} d’après d C → A
étape 3 : (CG) + = { CGDAB } d’après f ACD → B

On remarque qu’après cette étape B ⊆ CG+. On peut s’arrêter et conclure que la d.f.
CG → B est redondante dans F. Pour vérifier ce résultat, il suffit de montrer qu’on
peut la déduire de F’ par applications des propriétés des d.f. En effet :

1. C → A ⇒ CG → AG augmentation avec G
2. CG → AG ⇒ CG → ACG augmentation avec C
3. CG → D et CG → ACG ⇒ CG → ACDG union des parties droites
4. CG → ACDG ⇒ CG → ACD et CG → G décomposition
5. CG → ACD et ACD → B ⇒ CG → B transitivité (cqfd)

7 Définition formelle d’une clé

7.1 Enoncé
La clé d’une relation R(A1 ,A2 , ......, An) est un sous ensemble d’attributs X tel que :

1- X ⊆ (A1 ,A2 , ......, An)


2- X → A1 ,A2 , ......, An (i.e. X → A1 ; X → A2 ; ........ ; X → An )
3- Il n’existe pas Y ⊂ X tel que : Y → A1 ,A2 , ......, An

Il faut noter qu’une relation peut posséder plusieurs clés qui satisfont les propriétés ci-dessus. Elles
constituent ce que nous avons appelé les clés candidates de la relation.

7.2 Démarche de recherche des clefs candidates


La connaissance des clés d’une relation est primordiale car leur connaissance ainsi que celle des
d.f. vérifiées par la relation permettent d’une part de déterminer la forme normale de la relation et
d’autre part d’envisager une décomposition de la relation si celle-ci n’est pas dans une forme normale
convenable.

Connaissant les dépendances fonctionnelles vérifiées par une relation R(Ω), les clés candidates
peuvent facilement se démontrer en utilisant les propriétés des d.f. L’algorithme de calcul de la
fermeture d’un ensemble d’attributs peut servir comme base pour la recherche des clefs. Une
démarche à suivre est la suivante :

1- Pour toute d.f. X → Y vérifiée par R , calculer X+


2- Si X+ = Ω placer X dans une table Cp des clefs potentielles

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •101

3- Si X+ ≠ Ω placer X dans une table CpA des clefs potentielles par augmentation
4- Pour tout X de la table CpA , enlever X de la table CpA. Pour toute partie p de {Ω -
X+}, augmenter X avec p et soit X’=X∪p cet ensemble. Réappliquer les étapes 1, 2 et 3 à
X’
5- Répéter l’étape 4 jusqu’à ce que la table CpA devienne vide.
6- Supprimer de la table Cp les ensembles qui ne satisfont pas à la propriété numéro 3 de la
définition d’une clé. Les éléments restants dans la table Cp constituent l’ensemble des
clefs candidates de R.

Exemple:

Soit une R(A,B,C,D,E) vérifiant les d.f.

F ={ AB → C ;
C → D ;
BC → A ;
D → AC ;
E → B ; }
+
étape 1 : (AB) = {ABCD} ≠Ω
+
(C) = {CDA} ≠Ω
+
(BC) = {BCAD} ≠Ω
+
(D) = {DAC} ≠Ω
+
(E) = {EB} ≠Ω

étape 2 & 3: on construit la liste des clefs candidates potentielles et la liste des clefs
candidates potentielles par augmentation

clefs candidates potentielles clefs candidates potentielles par augmentation

∅ AB
C
BC
D
E

étape 4 : On travaille avec les éléments de la liste des clefs candidates potentielles
par augmentation.

Cas de AB : on enlève AB de la table CpA :


+
soit Y = {Ω - AB } = {(ABCDE)-(ABCD) } = {E}. On doit donc augmenter AB avec la seule
partie de Y qui est E et réappliquer les étapes 1,2 et 3.

Ensemble Augmenté avec + Décision à prendre


Calcul de X
+ ajouter ABE dans table Cp
ABE E (ABE) =ABCDE =Ω

Cas de C : on enlève C de la table CpA :


+
soit Y = {Ω - C } = {(ABCDE)-(CDA) } = {BE}. On doit donc augmenter C avec les parties
de Y qui sont B , E et BE puis réappliquer les étapes 1,2 et 3.

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •102

Ensemble Augmenté avec + Décision à prendre


Calcul de X
+
CB B (CB) =CDAB ≠Ω ajouter CB dans la table Cpa
+ ajouter CE dans la table Cp
CE E (CE) =CDAEB =Ω
+ ajouter CBE dans la table Cp
CBE BE (CE) =CDABE =Ω

Cas de BC : on enlève BC de la table CpA : (BC) + = {BCAD} ≠ Ω


+
soit Y = {Ω - BC } = {(ABCDE)-(BCAD) } = {E} . On doit donc augmenter BC avec la seule
partie E de Y puis réappliquer les étapes 1,2 et 3.

Ensemble Augmenté avec + Décision à prendre


Calcul de X
+ ajouter BCE dans la table Cp
BCE E (BCE) =BCADE =Ω

A ce niveau le contenu des deux tables Cp et CpA est :

Le contenu de la table Cp devient :

clefs candidates potentielles

ABE
CE
BCE

Le contenu de la table CpA devient :

clefs candidates potentielles par augmentation

D
E
CB

Cas de D : on enlève D de la table CpA.


+
soit Y = {Ω - D } = {(ABCDE) - (DAC) } = {BE}. On doit donc augmenter D avec les parties
de Y qui sont B , E et BE et réappliquer pour chaque augmentation les étapes 1,2 et 3.

Ensemble Augmenté avec + Décision à prendre


Calcul de X
+
DB B (DB) =DBAC ≠ Ω ajouter DB dans la table CpA
+
DE E (DE) =DEACB = Ω ajouter DE dans la table Cp
+
DBE BE (DBE) = DEACB = Ω ajouter DBE dans la table Cp

Cas de E : on enlève E de la table CpA


+
soit Y = {Ω - E } = {(ABCDE) - (EB) } = {ACD}. On doit donc augmenter E avec les parties
de Y qui sont A , C , D , AC , CD , AD , et ACD et réappliquer pour chaque augmentation
les étapes 1,2 et 3.

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •103

Ensemble Augmenté avec + Décision à prendre


Calcul de X
+
EA A (EA) =EABCD = Ω ajouter EA dans la table Cp
+
EC C (EC) =EBCAD = Ω ajouter EC dans la table Cp
+
ED D (ED) =EBDAC = Ω ajouter ED dans la table Cp
+
EAC AC (EAC) = EBDAC = Ω ajouter EAC dans la table Cp
+
EAD AD (EAD) = EBDAC = Ω ajouter EAD dans la table Cp
+
ECD CD (ECD) = EBDAC = Ω ajouter ECD dans la table Cp
+
EACD ACD (EACD) = EBDAC = Ω ajouter EACD dans la table Cp

A ce niveau le contenu des deux tables Cp et CpA est :

clefs candidates potentielles

ABE
CE
BCE
DE
DBE
EA
EC
ED
EAC
EAD
ECD
EACD

clefs candidates potentielles par augmentation

CB
DB

On poursuit le parcours de la table CpA


+ +
Cas de CB : on enlève CB de la table CpA . (CB) = (BC) = {BCAD}
+
soit Y={Ω - CB }={(ABCDE) - (BCAD) }={E} . On doit donc augmenter CB avec la seule
partie E de Y et réappliquer pour chaque augmentation les étapes 1,2 et 3.

Ensemble Augmenté avec + Décision à prendre


Calcul de X
CBE ou BCE + ajouter BCE dans la table Cp
E (BCE) =BCADE =Ω

+
Cas de DB : on enlève DB de la table CpA . (DB) = {DBAC}
+
soit Y = {Ω - DB } = {(ABCDE) - (DBAC) } = {E}. On doit donc augmenter DB avec la
seule partie E de Y et réappliquer pour chaque augmentation les étapes 1,2 et 3.

Ensemble Augmenté avec + Décision à prendre


Calcul de X
+ ajouter DBE dans la table Cp
DB E (DBE) =DBACE =Ω

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •104

A ce niveau le contenu des deux tables Cp et CpA est :

clefs candidates potentielles

ABE
CE
BCE
DE
DBE
EA
EC
ED
EAC
EAD
ECD
EACD

clefs candidates potentielles par augmentation


étape 5 : Puisque la table CpA est devenu vide et on n’a rajouté aucun nouvel élément, on
passe à l’étape 5. Tout élément X de cette table satisfait les propriétés 1 et 2 de la définition
d’une clé. Il faut voir s’il satisfait la propriété 3 c’est à dire qu’il n’existe pas Y ⊂ X tel que Y
→ A1 ,A2 , ......, An. En d’autres termes, il faudra enlever de la table Cp tous les éléments
contenant d’autres éléments de façon à ne garder que les éléments qui ne sont contenus
dans aucun autre. Dans le cas où on a plusieurs éléments identiques , on ne garde d’un seul
exemplaire.

clefs candidates potentielles

1 ABE éliminé car contient 6


2 CE
3 BCE éliminé car contient 3
4 DE
5 DBE éliminé car contient 4
6 EA
7 EC éliminé car le même que 2
8 ED éliminé car le même que 4
9 EAC éliminé car contient 6
10 EAD éliminé car contient 6
11 ECD éliminé car contient 2
12 EACD éliminé car contient 2

Ce qui donnera la liste des clefs candidates effectives : (CE) , (DE) et (EA)

8 Formes normales d’une relation


8.1 Objectifs de la normalisation
La conception d’un schéma relationnel ne doit pas être faite d’une façon quelconque mais doit être
soumise à une normalisation dont l’objectif est de permettre l’obtention de relations vérifiant certaines
propriétés telles que :

„ Faciliter les opérations de création , de suppression et de mise à jour d’un tuple


„ Faciliter la modification d’un schéma
„ Permettre l’utilisation d’algorithmes efficaces pour la recherche d’un tuple
„ Rendre possible la représentation d’une relation quelconque
Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •105

8.2 Les deux tendances de définition des formes normales


Avant de définir les formes normales d’une relation, nous estimons très important de mettre
d’abord en évidence les deux tendances selon lesquelles sont énoncées les définitions des formes
normales dans la littérature. Ces deux tendances sont totalement différentes et conduisent le plus
souvent a des énoncés vrais dans un cas mais faux dans l’autre.

La première tendance vise a définir la forme normale d’une relation en tenant compte du fait que la
clef primaire de la relation est déjà choisie parmi les clefs candidates éventuelles. Ceci veut dire que si
la relation est dans une certaine forme normale(2ième, 3ième, BCNF ), elle ne l’est que relativement à
la clef primaire retenue. Ceci sous entend aussi que la forme normale trouvée pour cette relation peut
ne pas être vraie relativement à une autre clef candidate de cette relation. Cette tendance impose donc
comme contrainte au moment de la normalisation d’une relation de choisir d’abord une clef primaire
K. De plus ce choix devra aussi être respecté au moment de l’implémentation en spécifiant lors de la
création de la relation (grâce au LDD) que sa clef primaire est K.

La deuxième tendance par contre est plus généraliste en ce sens qu’elle n’impose pas au moment de
la normalisation le choix d’une clef primaire. Ainsi, si la relation est dans une certaine forme
normale(2ième, 3ième, BCNF ), elle le sera quelle que soit la clef primaire qui sera choisie parmi
toutes les clefs candidates de la relation. Ceci veut dire qu’au moment de l’implémentation de la
relation on peut retenir n’importe quelle clef candidate comme clef primaire et ceci ne remettra pas en
cause la forme normale trouvée.

Dans la suite du chapitre, nous privilégions cette deuxième tendance car elle est plus générale et
sépare clairement entre les étapes de conception d’un schéma relationnel et de son implémentation.
Cependant nous essaierons d’énoncer pour chaque forme normale sa définition selon chacune des
deux tendances afin d’aider le lecteur à mieux faire la part des choses.

8.3 La première forme normale (1FN)


La première forme normale ne se base pas sur la notion de clef ni de d.f. Elle a pour objectif de
rendre possible la représentation sous forme de table d’une relation.

Une relation sera dite en 1FN si chaque attribut de cette relation a un domaine de valeurs simple
c’est à dire les valeurs que peut prendre chaque attribut sont des valeurs atomiques (i.e. non
décomposables.

Exemple :

Soit la relation AVION (TYPEAVION, CAPACITE) dans laquelle l’attribut TYPEAVION


désigne le type d’un avion et l’attribut CAPACITE désigne le nombre de places que peut
contenir un avion de ce type. Sachant que dans la réalité, il peut exister plusieurs modèles d’un
même type d’avion chacun avec une capacité ; un exemple d’extension d’une telle relation serait
donc :
TYPEAVION CAPACITE
CARAVELLE (100)
CONCORDE (400, 600)
AIRBUS (250, 275)
B707 (180, 150)
B747 (350)

Figure 3.15 Extension de la relation Avion

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •106

L’attribut CAPACITE est donc un attribut qui n’est pas atomique. Il possède des valeurs qui
peuvent être décomposées en d’autres valeurs qui sont atomiques. Par exemple la valeur (400, 600) de
l’attribut CAPACITE qui figure dans le deuxième tuple peut être décomposée en deux valeurs
atomiques (indécomposables) qui sont 400 et 600. Cette relation n’est donc pas en 1FN. On dit aussi
qu’elle n’est pas normalisée. Pour la mettre en 1FN, on peut :

a) éclater le groupe répétitif CAPACITE en créant un nouveau tuple pour chaque valeur
différente du groupe. On aura donc:

TYPEAVION CAPACITE
CARAVELLE 100
CONCORDE 400
CONCORDE 600
AIRBUS 250
AIRBUS 275
B707 180
B707 150
B747 350

Figure 3.16 (a) Mise en 1FN de la relation Avion

L'inconvénient de cette solution est la redondance des autres attributs car pour chaque valeur du
groupe on crée un nouveau tuple avec les mêmes valeurs des attributs sauf la capacité qui change.

b) Une autre solution serait si on connaît la cardinalité maximum des valeurs du groupe, de
créer pour chaque valeur une colonne dans la relation AVION1. Dans notre exemple, on sait
que la cardinalité maximum des valeurs du groupe est 3. Donc on crée dans AVION1 trois
nouvelles colonnes qu'on appellera par exemple CAP1, CAP2 et CAP3 et dans chaque
colonne on mettra une valeur de CAPACITE prise dans le groupe. Ceci donnera la relation
suivante :

TYPEAVION CAP1 CAP2 CAP3


CARAVELLE 100 ? ?
CONCORDE 400 600 ?
AIRBUS 250 275 ?
B707 180 150 ?
B747 350 ? ?

Figure 3.16 (b) Mise en 1FN de la relation Avion

ou le ? symbolise une valeur indéfinie. L'inconvénient de cette solution est l'ajout des
valeurs indéfinies ou NULL qui complique la gestion (beaucoup de SGBD ne savent pas
bien gérer les valeurs NULL).

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •107

8.4 La deuxième forme normale (2FN)


8.4.1 Définition 1 (première tendance)

Une relation est en 2FN si et seulement si :

1) Elle est en 1FN


2) Tout attribut n’appartenant pas à la clef primaire est pleinement dépendant de
la clef primaire.

Cette définition traduit le fait que toutes les dépendances ayant en partie droite un attribut
n’appartenant pas à la clef primaire et en partie gauche la clef primaire sont élémentaires.

Exemple :

Soit la relation R ( NUMETUDIANT , NOM , DIPLOME , INSTITUT ) ayant deux clefs


candidates qui sont NUMETUDIANT et (NOM,DIPLOME). On suppose aussi qu’elle
vérifie la D.F. : DIPLOME → INSTITUT:

Dans le cas où on retient la clef candidate NUMETUDIANT comme clef primaire, cette
relation est bien en 2FN puisque tous les attributs n’appartenant pas à cette clef primaire sont
en dépendance totale de cette même clef :

NUMETUDIANT →INSTITUT ;
NUMETUDIANT → NOM ;
NUMETUDIANT → DIPLOME

Par contre si on avait retenu comme clef primaire l’autre clef candidate (NOM,DIPLOME),
cette relation n’aurait pas été en 2FN puisqu’il existe un attribut INSTITUT n’appartenant
pas à cette clef primaire et qui n’est pas en dépendance totale de cette clef primaire puisqu’il
dépend d’une partie DIPLOME de cette clef :

DIPLOME →INSTITUT

Ainsi, il devient claire qu’avec cette première tendance il faut être très attentif en
précisant bien que la forme normale est fonction de telle ou telle clef primaire.

Exemple :

Soit la relation STOCK (PROD, DEPOT, LIBELLE, QTE) ou les attributs ont les sens
suivants :

(PROD : numéro du produit ; DEPOT : numéro du dépôt ou est stocké le produit ;


LIBELLE: nom du produit ; QTE : quantité du produit stockée dans le dépôt )

On suppose que la clé de cette relation est formée par le couple d'attributs (PROD, DEPOT)
et que cette relation vérifie les D.F. suivantes :

{ (PROD,DEPOT) → QTE ; PROD → LIBELLE }

Cette relation est en 1FN car tous ses attributs possèdent des valeurs atomiques(ou du moins
on l’admet en l’absence d’une extension qui pourrait contredire ce fait).

Elle n’est pas en 2FN à cause de la D.F. PROD → LIBELLE qui a dans la partie droite
un attribut (LIBELLE) ∉ à la clé, et qui a dans la partie gauche un attribut : PROD, qui

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •108

constitue une partie de cette clé.

Toute relation dont la ou les clé(s) est (sont) composée(s) d’un seul attribut, est forcément en
2FN car il n y aura jamais de D.F. ayant en partie gauche un sous ensemble d’attribut
contenus dans la ou les clé(s) de cette relation.

8.4.2 Définition 2 (deuxième tendance)


Une relation est en 2FN si et seulement si :

1) Elle est en 1FN


2) Tout attribut non primaire est pleinement dépendant de chaque clef candidate

On remarque que cette définition est plus générale et ne se restreint pas uniquement à la notion de
clef primaire. Elle traduit le fait que toutes les dépendances ayant en partie droite un attribut non
primaire et en partie gauche une clef candidate sont élémentaires.

Si on reprend l’exemple de la relation R ( NUMETUDIANT , NOM , DIPLOME , INSTITUT ),


les attributs primaires sont : NUMETUDIANT , NOM et DIPLOME. Le seul attribut non primaire
(i.e. qui n’appartient à aucune clef candidate) est INSTITUT. Et puisque cet attribut n’est pas en
dépendance totale de la clef candidate (NOM,DIPLOME) du fait qu’il dépend d’une partie
DIPLOME de cette clef :

DIPLOME →INSTITUT

On peut dire que cette relation n’est pas en 2FN. On voit que cette conclusion est générale et est
valable quelle que soit la clef primaire qu’on retiendra au moment de l’implémentation.

8.4.3 Problèmes posés par une relation qui n’est pas en 2FN

Reprenons l’exemple de la relation STOCK (PROD, DEPOT, LIBELLE, QTE) et qui n’est pas
en 2FN comme nous l’avons vu. La d.f. qui empêche la relation d’être en 2FN est : PROD →
LIBELLE. C’est justement cette D.F. qui cause des problèmes à la relation et que nous pouvons
résumer selon leur type comme suit :

• Insertion de tuples : Si on décide de rajouter un nouveau produit p ayant pour libellé l dans
notre base de données, il ne sera pas possible d’insérer cette information si on ne connaît pas
au moins un Dépôt où le stocker (une valeur d de l’attribut DEPOT) puisque la clé est le
couple (PROD, DEPOT). En effet, pour insérer un tuple dans la base il faut que sa clé soit
connue au moment de l’insertion. Ceci est un problème dans la mesure ou puisque les
attributs PROD et LIBELLE sont liés sémantiquement et ceci indépendamment des autres
attributs, on soit obligé de connaître au moins une valeur de l’attribut DEPOT, pour pouvoir
rajouter une information sur un produit.

• Suppression de tuples (ou perte d’information): Si parmi tous les tuples de la relation, il
existe un seul tuple contenant l’information que le produit P1 a pour libellé Armoires, la
suppression d’un tel tuple de la base va engendrer la perte de cette information. La
conséquence de cette suppression est qu’on ne pourra plus savoir que le produit P1 a pour
libellé Armoires.

• Mise à jour de tuples : Dans tous les tuples correspondant aux dépôts dans lesquels est
stocké le produit P1 , on va avoir le couple de valeur (P1 , Armoires) qui sera dupliqué
dans chaque tuple. Cette redondance d’information pose des problèmes au niveau de la
mise à jour. En effet, si on veut mettre à jour la valeur P1 dans la colonne PROD ou

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •109

Armoires dans la colonne LIBELLE on est obligé de le faire partout d’où un problème de
perte de temps. Et si par souci de gain de temps, on ne fait la mise à jour qu’à un seul endroit
(sur un seul tuple) on engendre un problème d’incohérence dans la base de données (une
même donnée possède deux valeurs différentes dans la base).

• Redondance d’information : Comme nous venons de le dire plus haut, pour tous les tuples
correspondant aux dépôts dans lesquels est stocké le produit Pi ayant pour libellé Li on va
avoir le couple de valeur (Pi , Li ) qui sera dupliqué au niveau de chaque tuple. C’est bien un
problème de redondance d’information puisque la même valeur du couple d’attributs
(PROD , LIBELLE) et qui est (Pi , Li ) est stockée plusieurs fois dans la base de données.

8.5 La troisième forme normale (3FN)


8.5.1 Définition 1 (première tendance)

Une relation est en 3FN si et seulement si :

1) Elle est en 2FN


2) Tout attribut n’appartenant pas à la clef primaire est directement dépendant de la clef
primaire.

Cette définition traduit le fait que tout attribut n’appartenant pas à la clef primaire n’est pas
transitivement dépendant de la clef primaire.

Une autre définition plus condensée serait :

Une relation est en 3FN si et seulement si tout attribut n’appartenant pas à la clef primaire est
pleinement et directement dépendant de la clef primaire.

Exemple :

Soit la relation R (A,B,C,D) ayant pour clef primaire le couple (A,B) et vérifiant les D.F.
suivantes : { C → A ; D → B }

les attributs n’appartenant pas à la clef primaire sont : C et D. Ces deux attributs sont pleinement
dépendant de la clef primaire car on a bien : (A,B) → C et (A,B) → D et ces deux d.f. sont
élémentaires. La relation est donc en 2FN. De même que les attributs C et D sont directement
dépendant de la clef primaire i.e. les deux d.f. (A,B) → C et (A,B) → D sont directes. La relation
est donc aussi en 3FN.

8.5.2 Définition 2 (deuxième tendance)

Une relation est en 3FN si et seulement si :

1) Elle est en 2FN


2) Tout attribut non primaire est directement dépendant de chaque clef candidate de la
relation.

On remarque là aussi que cette définition est plus générale et ne se restreint pas uniquement à la
notion de clef primaire. Elle traduit le fait que toutes les dépendances ayant en partie droite un attribut
non primaire et en partie gauche une clef candidate sont élémentaires et directes.

Une autre définition plus condensée serait :

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •110

Une relation est en 3FN si et seulement si tout attribut non primaire est pleinement et
directement dépendant de chaque clef candidate de la relation.

Exemple :

Soit la relation R (A ,B, C, D) ayant maintenant deux clefs candidates (A, B) et (B, D) et
vérifiant les D.F. suivantes : { D → B ; C → D }

les attributs primaires sont : A, B et D. Le seul attribut non primaire est C. La relation est en
2FN du fait que les d.f. de C sur chaque clef candidate sont élémentaires : A, B → C et
B,D → C. En d’autres termes C est pleinement dépendant de chaque clef candidate. On
peut dire aussi que :

(A,B) → C et (B,D) → C sont élémentaires. La relation est donc en 2FN.

De même que l’attribut non primaire C est directement dépendant de chaque clef candidate
i.e. les deux d.f. (A,B) → C et (B,D) → C sont directes. La relation est donc aussi en
3FN.

8.5.3 Problèmes posés par une relation qui n’est pas en 3FN

Soit la relation R ( NUMETUDIANT, NOM, DIPLOME, INSTITUT ). On suppose que R a une


seule clé qui est formée par l’attribut NUMETUDIANT et qu’elle vérifie la d.f. :

INSTITUT → DIPLOME

Cette relation n’est pas en 3FN à cause de la D.F. : INSTITUT → DIPLOME dans laquelle
un attribut non primaire : DIPLOME ∉ à la clé et dépend transitivement de cette clé. En effet,
d’après les d.f. :

NUMETUDIANT → INSTITUT
NUMETUDIANT → DIPLOME
INSTITUT → DIPLOME

on peut montrer que la d.f. NUMETUDIANT → DIPLOME n’est pas directe car d’après
la définition d’une d.f. directe, cette d.f. serait directe si : ∀ Y ⊄ NUMETUDIANT,
NUMETUDIANT → Y et Y → DIPLOME ⇒ Y → NUMETUDIANT

Or en prenant Y= INSTITUT on a bien :

NUMETUDIANT → INSTITUT et INSTITUT → DIPLOME mais on n’a pas


INSTITUT → NUMETUDIANT

donc la d.f. NUMETUDIANT → DIPLOME d’un attribut non primaire sur la clef n’étant pas
directe, cette relation ne peut être en 3FN. Elle est simplement en 2FN puisqu’elle possède une clé
formée d’un seul attribut.

La d.f. qui cause des problèmes n’est pas la d.f. NUMETUDIANT → DIPLOME mais plutôt
INSTITUT → DIPLOME car c’est elle qui engendre une d.f. transitive de DIPLOME sur la clé.
Nous pouvons résumer les problèmes posés selon leur type comme suit :

• Insertion de tuples : Si un institut i décide de dispenser pour la première fois un diplôme


d, il ne serait pas possible d’insérer cette réalité dans la base si on ne connaît pas au moins
un étudiant (identifié par NUMETUD qui est la clé) qui veut suivre ce diplôme . Ceci pose
Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •111

un problème dans la mesure ou la réalité qu’un institut dispense un diplôme est indépendante
de celle relative à l’inscription d’un étudiant dans ce diplôme.

• Suppression de tuples (ou perte d’information): Si parmi tous les tuples de la relation,
il existe un seul tuple contenant l’information que l’institut i1 dispense le diplôme d1, le fait
de supprimer ce tuple engendre la perte de cette information. On ne pourra plus savoir que le
diplôme dispensé par l’institut i1 est d1 .

• Mise à jour de tuples : Pour tous les étudiants préparant le diplôme dm dans l’institut im
le couple de valeur (im , dm) sera dupliqué pour chaque étudiant. C’est essentiellement un
problème de redondance qui pose des problèmes de mises à jour. Si on veut mettre à jour
la valeur im ou dm on est obligé de le faire partout (d’où un problème de perte de temps)
ou le faire en un seul endroit (sur un seul tuple) et on a alors un problème d’incohérence
des données (une même donnée possède deux valeurs différentes dans la base).

• Redondance d’information : Comme nous venons de le dire plus haut, pour tous les
étudiants préparant le diplôme dm dans l’institut im le couple de valeur (im, dm) sera dupliqué
pour chaque étudiant. C’est bien un problème de redondance d’information puisque la même
valeur du couple d’attributs (INSTITUT, DIPLOME) et qui est (im, dm) est stockée
plusieurs fois dans la base de données.

8.6 Forme normale de BOYCE ET CODD


Les définitions de la 2FN et de la 3FN tenaient compte uniquement des attributs non primaires et
de leur dépendances fonctionnelles vis à vis des clefs candidates. Malheureusement on s’est rendu
compte que même les attributs primaires participant dans certaines d.f. pouvaient posaient des
problèmes au niveau des relations. En d’autres termes, même une relation qui se trouve en 3FN peut
encore poser des problèmes. C’est pour cela qu’a été introduite cette nouvelle forme normale appelée
la forme normale de BOYCE et CODD (ou BCNF)

8.6.1 Définition

La définition de la BCNF ne privilégie aucune clé et s’énonce ainsi :

Une relation R est en BCNF si quelque doit la dépendance fonctionnelle X → A (avec A ⊄ X )


alors X est une clé de R ou contient une clé de R (on dit aussi dans ce cas que X est une super-clé de
R).

Exemple :

Soit la relation ADRESSE(Code_Postal, Ville, Nom_Rue) ayant pour clé le couple


d’attributs (Ville, Nom_Rue) et munie des dépendances fonctionnelles suivantes :

Ville, Nom_Rue → Code_Postal c


Code_Postal → Ville d

En utilisant les propriétés des d.f. on peut déduire de d par augmentation avec l’attribut
Nom_Rue que : Code_Postal , Nom_Rue → Ville, Nom_Rue e

Ainsi, cette relation possède une autre clé candidate qui est : (Code_Postal , Nom_Rue).
Comme il n’existe pas d’attribut non primaire (tous les attributs sont primaires), la relation
est au moins en troisième forme normale 3FN.

Par contre dans la dépendance fonctionnelle Code_Postal → Ville l’attribut Code_Postal


Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •112

n’est pas une clé pour la relation ni ne contient une clé de la relation. Cette relation n’est donc
pas en BCNF.

Considérons l’extension suivante de la relation ADRESSE :

Code_Postal Ville Nom_Rue


C1 V1 R1
C1 V1 R2
C2 V2 R3
C2 V2 R4

Figure 3.17 Une extension de la relation ADRESSE

On remarque que bien que la relation ADRESSE soit en 3FN, le problème de redondance
d’informations existe toujours. Par exemple, on a plusieurs fois la même valeur C1 qui apparaît dans
la colonne Code_Postal, plusieurs fois la même valeur V1 qui apparaît dans la colonne Ville,
plusieurs fois la même valeur V2 qui apparaît dans la colonne Ville

8.6.2 Remarques

• On remarque que même si une relation est en 3FN, ceci n’élimine pas complètement le
problème de redondance d’information d’où la nécessité de passer à la forme normale de
BOYCE et CODD.

• Toute relation admet une décomposition en BCNF qui préserve la jointure mais qui ne
préserve pas généralement les dépendances fonctionnelles.

8.7 Autres types de définitions des formes normales


Nous proposons d’autres définitions des formes normales qui ne prennent en compte que les
notions d’attributs primaire et non primaire. Ces définitions sont plus simples à assimiler et permettent
de mieux montrer la hiérarchie des formes normales.

8.7.1 Définition de la 2FN

Une relation R est en 2FN si et seulement si :

1- Elle est en 1FN

2- Elle ne vérifie pas de d.f X → A ou A est un attribut non primaire et X ⊂ dans une
clef candidate.

L’existence de d.f. d’un attribut non primaire sur un sous ensemble d'une clef candidate signifie
qu’il existe une d.f. non élémentaire d’un attribut non primaire sur une clé candidate, ce qui
contredirait la 2FN. C’est pourquoi la condition 2 de la définition impose que ce type de d.f. ne doit
pas exister pour que la relation soit en 2FN.

8.7.2 Définition de la 3FN

Une relation R est en 3FN si et seulement si :

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •113

1- Elle est en 2FN


2- Elle ne vérifie pas de d.f Y → A ou A est un attribut non primaire et Y n'est pas une
clef candidate.

L’existence de d.f. d’un attribut non primaire sur un attribut ou un ensemble d’attributs Y qui
n'est pas une clef candidate engendre inévitablement une d.f. transitive d’un attribut non primaire sur
une clef candidate ce qui contredirait la 3FN. C’est pourquoi la condition 2 de la définition impose
que ce type de d.f. ne doit pas exister pour que la relation soit en 3FN. Et du fait que la condition 1
de la définition impose que R soit d’abord en 2FN, toutes les d.f. contredisant la 2FN ne doivent pas
exister dans R.

8.7.3 Définition de la BCNF

Une relation R est en BCNF si et seulement si :

1- Elle est en 3FN


2- Elle ne vérifie pas de d.f Y → B ou B est un attribut primaire et Y n'est pas une clef
candidate.

La condition 1 permet d’écarter toutes les d.f. contredisant la 3FN. La condition 2 permet
d’étendre cette restriction aux attributs primaires (appartenant à une clef candidate) qui ne doivent
pas dépendre d'un attribut ou un ensemble d’attributs Y qui n'est pas une clef candidate. En effet,
nous avons vu que même ce type de d.f engendre aussi des problèmes de redondance dans une
relation.

8.7.4 Résumé

Soit X un attribut ou un ensemble d'attributs ⊂ dans une clef candidate, A un attribut non
primaire, Y un attribut ou un ensemble d'attributs qui n'est pas une clef candidate et B un attribut
primaire. Un tableau résumant le principe de ces définitions serait :

Forme normale D.f. non autorisées

2FN • X → A
• X → A
3FN • Y → A
• X → A
BCNF • Y → A
• Y → B

Figure 3.18 Résumé des défintions de formes normales

On peut facilement montrer que ces définitions sont équivalentes à celles données plus haut et se
basant sur les notions de d.f. élémentaire, directe, totale, ou transitive.

9 Les méthodes de conception d’un schéma


Les méthodes de conception utilisées dans le cadre du modèle relationnel forment deux grandes
familles : les méthodes agrégatives (ou ascendantes ou aussi par synthèse) et les méthodes par
Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •114

décomposition (ou descendantes) ; chaque famille présentant des avantages et des inconvénients.
Nous allons dans la suite présenter pour chaque famille le principe d’un algorithme mettant en œuvre
la méthode. Avant cela, certaines notions doivent être introduites en premier car elles vont servir à
mieux appréhender la finalité de ces méthodes.

9.1 Préservation des d.f. lors d’une décomposition


Le processus de décomposition d’une relation consiste à remplacer cette relation par un ensemble
de relations (au minimum 2). Une telle décomposition doit préserver les dépendances fonctionnelles
vérifiées par la relation de départ qui sont des propriétés indépendantes du temps et existant entre les
attributs.

On dit que la décomposition d’une relation R vérifiant un ensemble F de dépendances


fonctionnelles en {R1, R2, R3,....Rn} préserve les dépendances fonctionnelles si la fermeture F+ de
l’ensemble F est égale à la fermeture de l’union des dépendances fonctionnelles vérifiées par R1, R2
,.... et Rn.

F+= [ FR1 ∪ FR2 ∪ FR3 ∪ ........ ∪ FRn] +

ou ∀ i, FRi = {ensemble des d.f. V → U de F+ tel que les attributs V et U appartiennent au


schéma de Ri}

9.2 Décomposition binaire d’une relation

Soit R(Ω) un schéma relationnel avec X, Y, Z une partition de Ω (Ω=X∪ Y∪Z). Si X → Y est
une dépendance fonctionnelle vérifiée par R, alors on peut décomposer R sans perte d’information en
deux relations : R1(X,Y) et R2(X,Z) telle que :

R(Ω) = R1(X,Y) R1(X,Z)

La relation R1 est construite sur les attributs intervenants dans la dépendance fonctionnelle X →
Y c’est à dire X∪Y qu’on note aussi X,Y. La relation R2 est construite sur les attributs Ω - Y c’est à
dire X∪Z qu’on note aussi X, Z.

Reprenons l’exemple de la relation ADRESSE. Celle-ci peut être décomposée sur la base de la d.f.
Code_Postal → Ville (qui l’empêche d’être en BCNF ) en deux relations :

R1(Code_Postal, Ville) vérifiant la d.f. {Code_Postal → Ville } et ayant donc pour clé
l’attribut Code_Postal

R2(Code_Postal, Nom_Rue) vérifiant uniquement les d.f. triviales qu’on peut énoncer en
utilisant la propriété de réflexivité. R2 a pour clé le groupe d’attributs (Code_Postal,
Nom_Rue)

On peut vérifier qu’on a bien : ADRESSE = R1 R2

avec R1(Code_Postal, Ville) = ∏Code_postal, Ville (ADRESSE)


dont l’extension sera :

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •115

Code_Postal Ville
C1 V1
C2 V2

Figure 3.19 Extension de la relation R1

et R2(Code_Postal, Nom_rue) = ∏Code_postal, Nom_rue (ADRESSE)


dont l’extension sera :

Code_Postal Nom_rue
C1 R1
C1 R2
C2 R3
C2 R4

Figure 3.20 Extension de la relation R2

La jointure de R1 avec R2 sur l’attribut commun Code_Postal sera une relation R’ ayant pour
schéma R’(Code_postal, Ville, Nom_rue) et pour extension :

Code_Postal Ville Nom_Rue


C1 V1 R1
C1 V1 R2
C2 V2 R3
C2 V2 R4

Figure 3.21 : Extension de la relation R’ R2


=R1

On voit que R’ a le même schéma que ADRESSE et même extension. Donc cette décomposition
préserve bien la jointure. Cependant, elle ne préserve pas les dépendances fonctionnelles car :

ƒ Les d.f. associées à R1 sont : FR1 = {Code_Postal → Ville }


ƒ Les d.f. associées à R2 sont : FR2 = {d.f. triviales} telles que :
(Code_Postal, Nom_Rue) → Code_Postal ou (Code_Postal ,Nom_Rue) → Nom_Rue }

d’où : ( FR1 ∪ FR2 )= {Code_Postal → Ville }

Donc on voit que ( FR1 ∪ FR2 )+ ≠ F+ . Par exemple la d.f. (Ville, Nom_Rue) → Code_Postal
qui était vérifiée par la relation de départ ADRESSE est perdue lorsqu’on décompose cette relation
afin de la mettre en BCNF).

ƒ Pour vérifier que la d.f. (Ville, Nom_Rue) → Code_Postal est perdue, il faudra utiliser
nécessairement l’algorithme de calcul de la fermeture d’un ensemble d’attributs à partir de (
FR1 ∪ FR2 ).

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •116

9.3 Décomposition binaire sans perte d’information

Soit R (Ω) un schéma relationnel vérifiant un ensemble F de dépendances fonctionnelles. Une


décomposition (R1, R2) de R se fait sans perte d’information si au moins l’une des deux
dépendances fonctionnelles suivantes appartient à F + :

(1) R1 ∩ R2 → R1 - R2
(2) R1 ∩ R2 → R2 - R1

avec :
R1 ∩ R2 = { ensemble des attributs ∈ à R1 et ∈ à R2 aussi )
R1 - R2 = { ensemble des attributs ∈ à R1 et ∉ à R2 )
R2 - R1 = { ensemble des attributs ∈ à R2 et ∉ à R1 )

exemple :

ƒ Soit la relation R(A, B, C) vérifiant les d.f. F ={ C →A ; B → C} et considérons


la décomposition de R en { R1(A,C) , R2(B, C) } , on a : R1 ∩ R2 = { C } ; R1 -
R2 = { A } et R2 - R1 = { B}

On s’aperçoit que la dépendance fonctionnelle C → A ( c.a.d. R1 ∩ R2 → R1 -


R2) appartient à F et donc nécessairement à F + aussi. Cette décomposition se fait donc
sans perte d’informations.

ƒ Si on considère maintenant la décomposition de R en { R1(A,C) , R2(A, B) } , on a :


R1 ∩ R2 = { A } ; R1 - R2 = { C } et R2 - R1 = { B}

On s’aperçoit que ni la d.f. A → C ( c.a.d. R1 ∩ R2 → R1 - R2) ni A → B (


c.a.d. R1 ∩ R2 → R2 - R1) n’appartient à F ni à F+. Cette décomposition se fait
donc avec perte d’informations (ne pas confondre A → C avec C → A !).

9.4 Les méthodes agrégatives


Ces méthodes sont basées sur un algorithme ayant comme entrée une couverture minimale de
l’ensemble F de dépendances fonctionnelles et produisant en sortie une décomposition dont les
relations sont au moins en 3FN (on l’appelle généralement algorithme de décomposition en 3FN) . Son
principe est le suivant :

9.4.1 Algorithme de décomposition d’une relation en 3FN

L’algorithme s’utilise pour décomposer n’importe quelle relation qui est au plus en 2FN et au
moins en 1FN (attributs atomiques) et vérifiant un ensemble F de dépendances fonctionnelles.
Néanmoins, il nécessite de trouver d’abord une couverture minimale pour l’ensemble F.

Son principe est le suivant :

b ƒ S'il existe dans la couverture des d.f X → A1 ; ........ ; X → An tel que X U


A1 U....An = Ω alors retourner comme résultat R elle-même.

c ƒ Extraire tous les attributs isolés c’est à dire qui ne participent dans aucune dépendance
fonctionnelle, et construire une relation ayant comme attributs ces attributs isolés et pour
clé la clé par défaut c’est à dire l’ensemble de ses attributs ;

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •117

d ƒ Regrouper les dépendances fonctionnelles de la couverture par paquets chacun


contenant uniquement les dépendances ayant la même partie gauche (au pire on aura une
D.F. par paquet !) ;

e ƒ Prendre le paquet ayant le plus grand nombre de D.F.. Ces D.F. sont toutes de la
forme : X → A1 ; X → A2 ; ........ ; X → An car on sait qu’on travaille avec
la couverture minimale qui par définition contient uniquement des d.f. ayant une partie
droite unique (un seul attribut) ce qui n’est pas obligatoire pour la partie gauche qu’on a
désigné par X exprès.

f ƒ Construire une relation dont la liste des attributs est : (X , A1 , A2,.....An) et dont le
nom sera attribué en fonction des besoins de l’application !. Cette relation est bien en
3FN car sa seule clé est l’ensemble d’attributs X et il n’existe pas de D.F. transitive sur
cette clé. En effet si on a deux D.F. X → Ai et X → Aj qui appartiennent à la
couverture minimale, on est sûr que la D.F. Ai → Aj qui pourrait causer une
transitivité ne figure pas dans la couverture. En effet, si Ai → Aj figurait dans la
couverture avec X → Ai on n’aurait pas eu la D.F. X → Aj dans la couverture
minimale puisqu’elle serait redondante et peut s’obtenir alors à partir de : X → Ai et
Ai →Aj en appliquant la propriété de transitivité.

g ƒ Eliminer le paquet en cours d’examen de la couverture minimale puis éliminer tous les
attributs qui deviennent isolés (qui ne participent dans aucune dépendance fonctionnelle
parmi celles qui restent)

h ƒ S’il reste des paquets non traités Aller en e

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •118

La formalisation d’un tel algorithme peut être faite comme suit :

Procédure DECOMPEN3FN (Cm , Liste_Attributs)


|
| $ entrée :
| z Cm est la couverture minimale des D.F. vérifiées par la relation à décomposer
| z Liste_Attributs : liste des attributs de la relation à décomposer
|
| $ Sortie :
|
| z Edition d’un ensemble de relations constituant la décomposition
| (sont au moins en 3FN)
|
Début
| S'il existe dans Cm des d.f X → A1 ; ........ ; X → An
| | tel que X U A1U....An = Ω
| |
| alors retourner comme résultat R elle-même
| |
| sinon
| | ƒ Construire une relation R0 avec les attributs isolés
| | (qui ne participent à aucune D.F. de Cm) ;
| |
| | ƒ REDUIRE (Cm) ;
| |
| | ƒ Construire une dernière relation Rk avec tous les
| | attributs restants dans Liste_Attributs;
| Fin si
|
Fin DECOMPEN3FN

Procédure REDUIRE ( C )
|
| $ entrée :
| z C est la couverture minimale des D.F. à laquelle on a enlevé
| un certain nombre de D.F.
|
| $ Sortie :
| z Construit à chaque pas une relation faisant partie
| de la décomposition en 3FN de la relation
| Début
| |
| | Tant que il reste des paquets à examiner dans C
| | | et il n'existe pas de d.f.
| | Faire
| | |
| | | Æ Choisir le paquet de C ayant le plus grand nombre de d.f.
| | |
| | | /* il est de la forme X → A1 ; X → A2 ; .........; X → An */
| | |
| | | Æ Construire une relation Ri (X, A1, A2, ..... , An) ;
| | | Æ Supprimer le paquet de d.f. de C
| | | Æ Eliminer les attributs isolés (ne participant dans aucune
| | | D.F de C) de la liste des attributs Liste_Attributs ;
| | Fin Tant que
| Fin
|
fin REDUIRE

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •119

9.4.2 Exemple d’application de l’algorithme

Soit la relation COURS(PROF,MODULE, SALLE, HEURE) vérifiant les d.f. suivantes :

F = { PROF,MODULE → SALLE ;
MODULE, SALLE → HEURE ;
PROF,MODULE, HEURE → MODULE ;
PROF,MODULE, SALLE → HEURE, SALLE}

La première étape de l’algorithme est de chercher une couverture minimale pour F. On doit
appliquer la propriété de décomposition aux d.f. dont les parties droites comporte plusieurs attributs
pour se conformer à la propriété N°1 de la couverture minimale. On aura l’ensemble F1 :

1 PROF,MODULE → SALLE
2 MODULE, SALLE → HEURE
3 PROF,MODULE, HEURE → MODULE
4 PROF,MODULE, SALLE → HEURE
5 PROF,MODULE, SALLE → SALLE

On élimine ensuite de F1 les d.f. obtenues par la propriété d’augmentation pour se conformer à la
propriété N°2 de la couverture minimale. C’est le cas par exemple des d.f. 4 et 5 qui s’obtiennent par
augmentation à partir de 1 et 2 respectivement. On aura l’ensemble F2 :

1 PROF,MODULE → SALLE
2 MODULE, SALLE → HEURE
3 PROF,MODULE, HEURE → MODULE

On élimine aussi de F2 les d.f. triviales obtenues par la propriété de réflexivité pour se conformer à
la propriété N°2 de la couverture minimale. C’est le cas de la d.f. 3 ci-dessus. On aura l’ensemble F3 :

1 PROF,MODULE → SALLE
2 MODULE, SALLE → HEURE

On élimine ensuite les d.f. redondantes dans F3 pour se conformer à la propriété N° 3 de la


couverture. On utilise l’algorithme de calcul de la fermeture d’un ensemble d’attributs (X+) qui
permet de vérifier si une d.f. est redondante dans un ensemble (Voir un exemple similaire donné avec
cet algorithme) et qui donne :

(PROF,MODULE)+ = (PROF, MODULE)


(MODULE, SALLE) + = (MODULE, SALLE)

On a : SALLE ⊄ (PROF,MODULE)+ donc la d.f. 1 n’est pas redondante dans F3.

On a : HEURE ⊄ (MODULE, SALLE)+ donc la d.f. 2 n’est pas redondante dans F3.

Ainsi F3 constitue une couverture minimale pour F.

L’application de l’algorithme de décomposition en 3FN consiste donc à regrouper les d.f. de F3 en


paquets chacun contenant toutes les d.f. ayant la même partie gauche. Pour notre exemple, on aura une
d.f. par paquet et qui sont :

P1 : PROF,MODULE → SALLE
P2 : MODULE, SALLE → HEURE

• On initialise une variable LISTE_ATTRIBUTS={ PROF,MODULE, SALLE, HEURE}


avec l’ensemble des attributs de la relation.

• Il n’existe pas d’attributs isolés (ne participant à aucune d.f), donc aucune relation n’est à
Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •120

construire pour ce type d’attributs.

• On construite une relation P1(PROF,MODULE, SALLE) avec le paquet P1. On


supprime la d.f. 1 de F3. On aura :

F’3 = { MODULE, SALLE → HEURE}.

On supprime de LISTE_ATTRIBUTS les attributs qui sont devenus isolés dans F’3. C’est
le cas de l’attribut PROF qui ne participe dans aucune d.f. de F’3. On aura :

LISTE_ATTRIBUTS={MODULE, SALLE, HEURE}.

• On construite une autre relation P2(MODULE, SALLE, HEURE) avec le paquet P2. On
supprime la d.f. 2 de F’3. On aura :

F’’3 = { ∅ }

On supprime de LISTE_ATTRIBUTS les attributs qui sont devenus isolés dans F’’3. Tous
les attributs sont isolés car F’’3 est vide. On aura :

LISTE_ATTRIBUTS={∅}.

On a examiné tous les paquets. On arrête l’algorithme avec comme résultat la décomposition
suivante :

P1(PROF,MODULE, SALLE) vérifiant la d.f. PROF, MODULE→ SALLE et ayant


pour clé le couple (PROF, MODULE). P1 est au moins en 3FN.

P2(MODULE, SALLE, HEURE) vérifiant la d.f. MODULE, SALLE → HEURE et


ayant pour clé le couple (MODULE, SALLE). P2 est au moins en 3FN.

Cette décomposition préserve les d.f. car FP1 ∪ FP2 = F3. Mais puisque F3 est une
couverture minimale, on sait par définition qu’elle est équivalente à F.

9.4.3 Remarque

Les méthodes dites agrégatives se caractérisent par le fait qu’elles donnent comme résultat une
décomposition qui préserve les dépendances fonctionnelles mais pas nécessairement les données.

Il a été montré qu’étant donnée une décomposition d’une relation R selon cette méthode et qui ne
préserve pas les données, il suffit de lui rajouter une nouvelle relation S(X) dans laquelle X est une clé
de R pour constituer une décomposition préservant en même temps les dépendances fonctionnelles
et les données.

9.5 Les méthodes par décomposition


9.5.1 Principe

Ces méthodes sont basées sur un processus itératif de décomposition consistant à décomposer à
chaque étape une relation par application du théorème de décomposition binaire présenté plus haut.
A la fin du processus, on obtient un arbre de décomposition dans lequel toutes les feuilles sont les
relations constituant la décomposition.

Il faut dès lors souligner que le théorème de décomposition binaire est applicable quelque soit la
relation à décomposer et quelle que soit sa forme normale. C’est donc au concepteur de choisir la
bonne dépendance fonctionnelle à isoler grâce à ce théorème. Les situations possibles peuvent être

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •121

résumées comme suit :

Type de la Relation Type de d.f. à utiliser Résultat


Relation en 1FN et non en 2FN une d.f. qui contredit la 2FN 2 relations dont une est au
moins en 2FN
Relation en 2FN mais non en 3FN une d.f. qui contredit la 3FN 2 relations dont une est au
moins en 3FN
Relation en 3FN mais non en une d.f. qui contredit la BCNF 2 relations dont une est au
BCNF moins en BCFN

Figure 3.22 Principe de la méthode de décomposition descendante

Il faut remarquer aussi qu’il peut exister pour une même relation plusieurs d.f. qui contredisent telle
ou telle forme normale. C’est pour cela que le choix d’une d.f. à utiliser avec le théorème de
décomposition binaire conduit à une décomposition qui sera différente que celle qu’on obtiendrait
avec une autre d.f.. Ceci ne va pas à l’encontre de ce qui a été dit concernant une décomposition
puisqu’on sait qu’une même relation peut être décomposée de plusieurs façons différentes. Ce qui
qualifie les décompositions faites sur la base du théorème de décomposition binaire, c’est qu’elles se
font sans perte d’informations.

Ainsi, à chaque application du théorème si l’une des deux relations résultantes n’est pas dans la
forme normale que l’on souhaite, c’est qu’elle vérifie une d.f. qui l’empêche d’être dans cette forme là.
Il faudra alors réappliquer le théorème à cette relation sur la base de cette d.f. On voit que c’est
effectivement un processus itératif qui se termine lorsque toutes les relations de l’arborescence sont
dans une forme normale souhaitée par le concepteur.

Exemple : Soit la relation R(NUMERO, NOM, SPECIALITE, VILLE) vérifiant les d.f. :

NUMERO → NOM (1)


VILLE → SPECIALITE (2)

On peut facilement montrer que le couple (NUMERO,VILLE) est une clé pour la relation. Grâce a
la réflexivité, on peut énoncer que :

NUMERO,VILLE → NUMERO (3) NUMERO,VILLE → VILLE (4)

Par application de la transitivité à (3) et (1) on déduit que : NUMERO,VILLE → NOM (5). Par
application de la transitivité à (4) et (2) on déduit que : NUMERO,VILLE → SPECIALITE (6)

Puisque le couple d’attributs (NUMERO,VILLE) détermine tous les autres attributs de la relation,
il constitue bien une clé pour la relation. Cette relation est simplement en 1FN et n’est pas en 2FN
car les deux D.F. : NUMERO → NOM et VILLE → SPECIALITE

sont des dépendances ayant en partie droite des attributs non primaires et dans la partie gauche une
partie de la clé (NUMERO,VILLE). Ceci revient à dire aussi que les d.f. :

(NUMERO,VILLE) →NOM et (NUMERO,VILLE) →SPECIALITE ne sont pas


élémentaires ou que NOM ne dépend pas pleinement de la clef, de même que SPECIALITE.

On peut dans ce cas appliquer le théorème de décomposition binaire sur la base de l’une des deux
d.f. NUMERO → NOM ou VILLE → SPECIALITE car elles empêchent toutes les
deux la relation d’être en 2FN. Si on choisit de décomposer selon VILLE → SPECIALITE,

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •122

on aura :

Relation clé(s) dépendances F.N.


R1(VILLE,SPECIALITE) VILLE VILLE→ SPECIALITE BCNF
R2(NUMERO,VILLE,NOM) (NUMERO,VILLE) NUMERO →NOM 1FN

Puisque R2 n’est pas en 2FN à cause de la d.f. NUMERO → NOM , on poursuit le processus
de décomposition avec R2. On applique le théorème de décomposition binaire sur la base de la d.f.
NUMERO → NOM car elle empêche la relation R2 d’être en 2FN. on aura :

Relation clé(s) Dépendances F.N.


R21(NUMERO,NOM) NUMERO NUMERO → NOM BCNF
R22(NUMERO,VILLE) (NUMERO,VILLE) d.f. triviales BCNF

Toutes les relations sont maintenant en BCNF, on arrête donc le processus de décomposition. Une
représentation graphique de l’arbre de décomposition où toutes les feuilles sont des relations en
BCNF serait :

1FN
R

R1 R2 1FN

BCNF

R21 R22

BCNF BCNF

Figure 3.23 Arbre de décomposition selon la méthode descendante

Le résultat du processus de décomposition de la relation R selon la méthode dite par décomposition


sera donc constitué des trois relations R1, R21 et R22 qui constituent des feuilles de l’arbre ci-dessus.

9.5.2 Remarque

Les méthodes dites par décomposition se caractérisent par le fait qu’elles donnent comme résultat
une décomposition qui préserve les données mais pas nécessairement les dépendances
fonctionnelles.

9.6 Décomposition sans perte d’information : Algorithme d’Ullman

Cet algorithme permet de vérifier si une décomposition (R1,.....Rn) avec n ≥ 2 d’une relation
R(A1,A2, ....., An) vérifiant un ensemble de dépendances fonctionnelles F est une décomposition
sans perte d’information ou non. C’est une généralisation du théorème d’Ullman applicable aux
décompositions binaires.

9.6.1 Formalisation de l’algorithme

Une formalisation de cet algorithme serait :

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •123

Fonction ULLMAN (F , (R1, R2 , ... , Rn) , (A1, A2 , ..... An) )


| $ entrée :
| • F : l’ensemble des D.F. vérifiées par la relation R
| • (R1, R2 , ..... , Rk) une décomposition de R
| • (A1, A2 , ..... , An) liste des attributs de R
| $Sortie :
| ULLMAN = Vrai si la décomposition se fait sans perte , Faux sinon
| Début :
|
| ƒ Construire une matrice MAT(k , n) ayant k lignes et n colonnes
| /* ( k : nombre de relations de la décomposition ; */
| /* n : nombre d’attributs de la relation R) */
| /* La colonne j dans la matrice MAT(k, n) correspond à l’attribut Aj de R */
| /* La ligne i de la matrice correspond à la relation Ri de la décomposition */
|
| ƒ Remplir la matrice MAT(k , n) comme suit :
|
| A l’intersection d’une ligne i et d’une colonne j faire,
| Si L’attribut Aj de R appartient au schéma de Ri
| Alors placer le symbole aj ;
| Sinon placer le symbole bij ;
|
| ENCORE ← Vrai ;
|
| Tant que ENCORE = Vrai Faire
| |
| | Ya_Eu_Changement ← Faux ;
| | Fixer un ordre de parcours des D.F. de F ;
| | Tant que il reste une D.F. à examiner et ENCORE = Vrai Faire
| | | Prendre une D.F. X → Y dans F ;
| | | Choisir 2 lignes dans la matrice MAT
| | |
| | | Si dans la colonne X (ou les colonnes X si X est composé)
| | | | les 2 lignes ont des symboles identiques
| | | Alors Transformer les symboles de la colonne Y de ces 2 lignes
| | | | comme suit
| | | | Ya_Eu_Changement ← Vrai ;
| | | |
| | | | Si un des deux symboles est un symbole aj
| | | | Alors remplacer l’autre par aj
| | | | Sinon /* les 2 symboles sont de type bij */
| | | | remplacer les deux par bij ou blj
| | | | FinSi
| | | Finsi
| | Fin Tant que
| | SI ∃ dans MAT( ) une ligne remplie de symboles aj
| | |
| | Alors ULLMAN ← Vrai ; ENCORE ← Faux ;
| | |
| | Sinon
| | | Si Ya_Eu_Changement = Faux
| | | Alors
| | | | ENCORE ← Faux;
| | | | ULLMAN ← Faux ;
| | | FinSi
| | FinSi
| FinTantque
Fin ULLMAN

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •124

9.6.2 Exemple d’application

Exemple 1 :

Soit la relation R(NUMERO,NOM, VILLE,SPECIALITE) vérifiant les d.f. suivantes :

F = { VILLE → SPECIALITE ; NUMERO → NOM}

et soit la décomposition suivante de R :

{R1(VILLE,SPECIALITE) ; R2(NUMERO,NOM) ; R3(NUMERO,VILLE)}

L’application de l’algorithme serait :

Etape 0 : Construction de la matrice

NUMERO NOM VILLE SPECIALITE

R1 b11 b12 a3 a4
R2 a1 a2 b23 b24
R3 a1 b32 a3 b34

Etape 1 : on choisit une d.f. dans F par exemple VILLE → SPECIALITE

On remarque que seules R1 et R3 ont le même symbole sur la colonne VILLE (symbole a3). On
doit donc effectuer un changement dans la colonne SPECIALITE. Or sur la colonne
SPECIALITE , R1 contient le symbole a4 et R3 le symbole b34. Donc on change sur la ligne
R3 le symbole b34 par a4 (en gras). On aura :

NUMERO NOM VILLE SPECIALITE

R1 b11 b12 a3 a4
R2 a1 a2 b23 b24
R3 a1 b32 a3 a4

Il n’y a pas de lignes composées de symboles ai , on passe a l'autre D.F.

on choisit la D.F. NUMERO → NOM

On remarque que seules R2 et R3 ont le même symbole sur la colonne NUMERO (symbole a1).
On doit donc effectuer un changement dans la colonne NOM. Or sur la colonne NOM , R2
contient le symbole a2 et R3 le symbole b32. Donc on change sur la ligne R3 le symbole b32
par a2. On aura :

NUMERO NOM VILLE SPECIALITE

R1 b11 b12 a3 a4
R2 a1 a2 b23 b24
R3 a1 a2 a3 a4

On remarque qu'on a une ligne R3 composée uniquement de symboles ai. On conclut que la
décomposition se fait sans perte d’information (ou qu’elle préserve les données).

L’ordre d’examen des d.f. n’est pas important sauf sur le plan de la convergence de l’algorithme
qui signifie qu’un ordre peut conduire rapidement au résultat relativement à un autre.

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •125

Exemple 2 :

Soit la relation COURS(PROF,MODULE, SALLE, HEURE) vérifiant les d.f. suivantes :

F = { PROF,MODULE → SALLE ;
MODULE, SALLE → HEURE ;
PROF,SALLE, HEURE → MODULE }

et soit la décomposition suivante de COURS :

{R1(PROF,MODULE , SALLE) ; R2(MODULE, SALLE) ; R3(PROF,HEURE) }

L’application de l’algorithme serait :

Etape 0 : Construction de la matrice

PROF MODULE SALLE HEURE

R1 a1 a2 a3 b14
R2 b21 b22 a3 b24
R3 a1 b32 b33 a4

Etape 1 : on choisit une d.f. dans F par exemple PROF, SALLE, HEURE → MODULE

On remarque qu’il n’existe pas un couple de lignes ayant les mêmes symboles sur les colonnes
PROF, SALLE et HEURE. Donc cette d.f. n’engendre aucun changement dans la matrice.

On passe à une autre d.f. par exemple MODULE, SALLE → HEURE

On remarque là aussi qu’il n’existe pas un couple de lignes ayant les mêmes symboles sur les
colonnes MODULE et SALLE car (a2,a3) ≠ (b22,a3) ≠ (b32,b33) . Donc cette d.f.
n’engendre aucun changement dans la matrice.

On passe à la dernière d.f. non examinée PROF, MODULE → SALLE

On remarque là aussi qu’il n’existe pas un couple de lignes ayant les mêmes symboles sur les
colonnes PROF et MODULE car (a1,a2) ≠ (b21,b22) ≠ (a1,b32). Donc cette d.f.
n’engendre aucun changement dans la matrice.

Toutes les d.f. ont été examinées et aucun changement n’a été opéré sur la matrice. Comme il
n’existe pas de ligne composée uniquement de symboles ai alors cette décomposition se fait avec
perte d’information ou ne préserve pas les données.

L’examen de l’ensemble F peut se faire sur plusieurs itérations. Ceci est logique car chaque fois
qu’une d.f. fi engendre un changement dans la matrice, ce changement peut avoir un effet sur toutes
les d.f. qui ont été examinées avant fi et qui n’ont pas engendré de changement. Les deux critères
d’arrêt de l’algorithme sont :

1- obtention d’une ligne composée de symbole ai


2- L’examen de toutes les d.f. ne provoque aucun changement dans la matrice

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •126

10 Dépendances multivaluées et quatrième forme normale

10.1 Limites des dépendances fonctionnelles


Nous avons vu que les dépendances fonctionnelles expriment des liens sémantiques entre les
attributs et servent comme entrée pour l’algorithme de décomposition d’une relation. Cette
décomposition conduit à des relations qui sont en 3FN ou en BCNF. Cependant, il a été constaté que
les dépendances fonctionnelles ne suffisent pas pour supprimer totalement les redondances
d’information et les anomalies de mise à jour.

Considérons la relation ETUDIANT(NUMERO, COURS, SPORTS) qui modélise la réalité


suivante : Un étudiant est identifié par un NUMERO , peut suivre un ou plusieurs COURS et
pratiquer un ou plusieurs SPORTS. La clé de cette relation est donc l’ensemble de ses attributs. Une
extension de cette relation est :

NUMERO COURS SPORTS


100 B.D. TENNIS
100 B.D. FOOT
200 B.D. VELO
200 MATH VELO
300 B.D. FOOT
300 B.D. TENNIS

Figure 3.24 Une extension de la relation ETUDIANT

Il apparaît sur cette extension plusieurs redondances :

ƒ On a deux fois le couple de valeurs (100, B.D.) dans les deux premiers tuples alors que dans
la colonne SPORTS de ces mêmes tuples on a deux valeurs différentes TENNIS ≠ FOOT

ƒ On a deux fois le couple (200, VELO) dans le troisième et le quatrième tuple alors que dans
la colonne COURS de ces mêmes tuples on a deux valeurs différentes B.D. ≠ MATH

ƒ On a deux fois le couple (300,B.D.) dans les deux derniers tuples alors que dans la colonne
SPORTS de ces mêmes tuples on a deux valeurs différentes TENNIS ≠ FOOT

On peut aussi vérifier sur cette extension que les dépendances fonctionnelles suivantes ne sont pas
vérifiées :

• NUMERO /→ COURS : par exemple pour NUMERO = 200 on a 2 valeurs différentes
de COURS : B.D. et MATH }
• COURS /→ SPORTS :par exemple pour COURS = B.D. on a 3 valeurs différentes de
SPORTS : TENNIS, FOOT et VELO }
• NUMERO /→ SPORTS : par exemple pour NUMERO = 100 on a 2 valeurs différentes
de SPORTS : TENNIS et FOOT }
•(NUMERO, COURS) /→ SPORTS : par exemple pour (NUMERO = 200, COURS = B.D.) on a 2
valeurs différentes de SPORTS : TENNIS et FOOT

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •127

•(COURS, SPORTS) /→ NUMERO : par exemple pour (COURS=B.D., SPORTS=FOOT) on a 2


valeurs différentes de NUMERO : 100 et 300
•(NUMERO, SPORTS) /→ COURS : par exemple pour (NUMERO = 200, SPORTS = VELO) on
a 2 valeurs différentes de COURS : B.D. et MATH }

Ainsi, en l’absence de dépendances fonctionnelles, cette relation ne peut pas être décomposée et
par conséquent les problèmes de redondance que nous avons soulignés plus haut ne peuvent pas être
supprimés.

10.2 Notion de dépendance multivaluée

Soit R(Ω) un schéma relationnel avec X, Y, Z une partition de Ω (Ω = X ∪ Y ∪ Z). On dit que :

X →→ Y (X multidétermine Y)

si pour toute valeur de X, il y a un ensemble de valeurs de Y qui lui sont associées et cet ensemble
est indépendant des autres attributs de R (c.a.d. de Z).

Une dépendance multivaluée sert donc à caractériser une indépendance entre deux ensembles
d’attributs Y et Z vis-à-vis d’un troisième ensemble X.

(nous noterons par la suite une dépendance multivaluée par D.M. ou d.m. pour simplifier)

10.2.1 Définition formelle

Formellement :

X →→ Y ⇔ { (x, y, z) et (x, y’, z’) ∈ R ⇒ (x, y’, z) et (x, y, z’) ∈ R }

ou (x, y, z), (x, y’, z’), (x, y’, z) et (x, y, z’) sont des tuples de la relation R.

10.2.2 Remarque

Les D.F. sont des cas particuliers de dépendances multivaluées. En effet, si on a la D.F. X →Y
qui est vérifiée par R, l’existence des tuples (x, y, z) , (x, y’, z’) dans R implique nécessairement que y
= y’ et donc les tuples (x, y’, z) , (x, y, z’) appartiennent aussi à R. On a donc bien X → Y ⇒ { (x,
y, z) et (x, y’, z’) ∈ R ⇒ (x, y’, z) et (x, y, z’) ∈ R } ce qui revient à dire que la dépendance
multivaluée X →→ Y est aussi vérifiée dans R.

Donc : X → Y ⇒ X →→ Y

Il faut souligner que la réciproque n’est pas vraie. Une Dépendance multivaluée X →→ Y
n’implique pas forcément la dépendance fonctionnelle X → Y.

10.2.3 Exemple

Reprenons la relation ETUDIANT(NUMERO, COURS, SPORTS) et examinons si l’une des


Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •128

dépendance multivaluées suivantes :

NUMERO →→ COURS


COURS →→ SPORTS
NUMERO →→ SPORTS

est vérifiée par cette relation. Avant de faire cette vérification, nous devons faire la remarque
suivante :

 Pour vérifier si une dépendance multivaluée est vérifiée ou non par une relation il faut
utiliser l’extension de la relation et la définition formelle d’une dépendance multivaluée. Il
s’agira chaque fois qu’on a deux tuples (x,y,z) et (x,y’,z’) dans R de voir si les deux tuples
(x, y’, z) et (x, y, z’) sont aussi présents dans R. Si l’un au moins de ces deux tuples n’existe
pas dans R alors on conclut directement que la dépendance multivaluée n’est pas vérifiée.
Normalement, une dépendance multivaluée au même titre qu’une dépendance fonctionnelle
ne peut en aucun cas être déduite d’une extension de la relation. Compte tenu du fait que les
dépendances multivaluées sont plus difficile à exprimer que les dépendances fonctionnelles,
on se permet chaque fois qu’on a à vérifier l’existence d’une dépendance multivaluée, de
raisonner à partir d’une extension de la relation et ce dans le seul but pédagogique.

Désignons par Ω l’ensemble des attributs de la relation c.a.d. Ω = (NUMERO, COURS,


SPORTS).

1) NUMERO →→ COURS

En posant : X = NUMERO ; Y = COURS et Z = Ω - (X ∪Y) = SPORTS on peut


constater que :

ƒ Les deux tuples ( X =100 , Y=B.D. , Z=TENNIS) et (X=100 , Y’=B.D. , Z’= FOOT) ∈ à R
donc on doit aussi trouver les tuples (X=100 , Y’=B.D. , Z=TENNIS) et (X=100 , Y=B.D. ,
Z’= FOOT) dans R ce qui est la cas car Y= Y’ .

ƒ Les deux tuples (X=200 , Y=B.D. , Z=VELO) et (X=200, Y’=MATH, Z’= VELO) ∈ à R
donc on doit aussi trouver les tuples (X=200 , Y’=MATH , Z=VELO) et (X=200 , Y=B.D. ,
Z’= VELO) dans R ce qui est la cas car Z = Z’ .

ƒ Les deux tuples (X=300 , Y=B.D. , Z=FOOT) et (X=300 , Y’=B.D. , Z’= TENNIS) ∈ à R
donc on doit aussi trouver les tuples (X=300 , Y’=B.D. , Z=FOOT) et (X=300 , Y=B.D.,
Z’= TENNIS) dans R ce qui est la cas car Y= Y’ .

On peut donc conclure que la dépendance multivaluée NUMERO →→ COURS est
vérifiée dans R.

2) COURS →→SPORTS

En posant : X = COURS ; Y = SPORTS et Z = Ω - (X ∪Y) = NUMERO on peut constater


que :

ƒ Les deux tuples (X=B.D. , Y=TENNIS , Z=200) et (X=B.D. , Y’=FOOT , Z’= 100) ∈ à R
donc on doit aussi trouver les tuples (X=B.D. , Y’=FOOT , Z=200) et (X=B.D. ,
Y=TENNIS , Z’= 100) dans R. Or le tuple (X=B.D. , Y’=FOOT , Z=200) n’existe pas dans
R.

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •129

On peut donc immédiatement conclure que cette dépendance multivaluée n’est pas vérifiée
dans R (i.e. COURS /→→SPORTS)

3) NUMERO →→ SPORTS

En posant : X = NUMERO ; Y = SPORTS et Z = Ω - (X ∪Y) = COURS on peut


constater que :

ƒ Les deux tuples (X=100 , Y=TENNIS , Z=B.D.) et (X=100, Y’=FOOT , Z’= B.D.) ∈ à R
donc on doit aussi trouver les tuples (X=100 , Y’=FOOT , Z=B.D.) et (X=100 , Y=TENNIS ,
Z’= B.D.) dans R ce qui est la cas car Z =Z’ .

ƒ Les deux tuples (X=200 , Y=VELO , Z=B.D.) et (X=200 , Y’=VELO , Z’= MATH) ∈ à R
donc on doit aussi trouver les tuples (X=200 , Y’=VELO , Z=B.D.) et (X=200 , Y=VELO ,
Z’= MATH) dans R ce qui est la cas car Y = Y’ .

ƒ Les deux tuples (X=300 , Y=FOOT , Z=B.D.) et (X=300 , Y’=TENNIS , Z’= B.D.) ∈ à R
donc on doit aussi trouver les tuples (X=300 , Y’=TENNIS , Z=B.D.) et (X=300 , Y=FOOT
, Z’= B.D.) dans R ce qui est la cas car Z= Z’ .

On peut donc conclure que la dépendance multivaluée NUMERO →→ SPORTS est vérifiée
dans R.

 Nous avons vu aussi que la d.f. NUMERO → SPORTS n’est pas vérifiée. Ceci prouve bien
qu’une dépendance multivaluée n’implique pas forcément une dépendance fonctionnelle.

10.3 Propriétés des dépendances multivaluées


Les dépendances multivaluées possèdent des propriétés à partir desquelles il est possible d’inférer
d’autres dépendances multivaluées. Si on désigne par Ω l’ensemble des attributs d’une relation, les
trois axiomes à partir desquels on peut dériver d’autres dépendances multivaluées sont les suivants :

10.3.1 Complémentation

X →→ Y ⇒ X →→ Ω - ( X ∪ Y)

10.3.2 Augmentation

X →→ Y et V ⊆ W ⇒ X, W →→ Y, V

10.3.3 Transitivité

X →→ Y et Y →→ Z ⇒ X →→ Z -Y

Comme pour les d.f., il existe d'autres propriétés très utiles en pratique surtout lors du calcul de la
fermeture d'un ensemble G de D.F. et de D.M.. Ce sont les suivantes :

10.3.4 Union

X →→ Y et X →→ Z ⇒ X →→ Y,Z

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •130

10.3.5 Intersection

X →→ Y et X →→ Z ⇒ X →→ Y∩Z

10.3.6 Différence

X →→ Y et X →→ Z ⇒ X →→ Y- Z et X →→ Z - Y

10.3.7 Propriétés entre D.F. et D.M.

Il existe deux propriétés très importantes liant les dépendances fonctionnelles aux dépendances
multivaluées et inversement. Ce sont les deux suivantes :

10.3.7.1 La réplication

Cette propriété permet de déduire une D.M. à partir d'une D.F.

X → Y ⇒ X →→ Y

10.3.7.2 La coalescence

Cette propriété permet de déduire une D.F. à partir d'une D.M.

X →→ Y et Z ⊆ Y et il existe W tel que W ∩ Y = ∅ et W → Z ⇒ X → Y

Toutes les propriétés présentées peuvent servir pour le calcul de la fermeture d’un ensemble G
comportant en même temps des d.f. et des d.m.

10.3.8 Dépendance multivaluée triviale

Une dépendance multivaluée X →→ Y vérifiée par une relation R(Ω) sera dite triviale dans
l'un des deux cas suivants :

1- Y⊆X

2- X∪Y=Ω

Exemple :

Soit la relation R( A,B,C,D) vérifiant les D.M. suivantes :

1. A, B →→ C,D
2. A, C →→ C
3. A →→ B,D

La D.M. numéro 1 est triviale car AB ∪ CD = Ω = (ABCD).


La D.M. numéro 2 est triviale car C ⊆ AC
La D.M. numéro 3 n'est pas triviale car A ∪ BD ≠ Ω et B,D ⊄ A

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •131

10.4 Quatrième Forme Normale (4 FN)


10.4.1 Définition

Une relation R vérifiant un ensemble de dépendances fonctionnelles et un ensemble de


dépendances multivaluées est en 4 FN si pour toute D.M X →→ Y , on a :

ƒ X →→ Y est triviale ou


ƒ X est une clef ou contient une clef de R.

10.4.2 Remarque

On peut montrer facilement que toute relation en 4 FN est aussi en BCNF (à faire !).

exemple 1:

Soit la relation VOL(Pilote, Avion, Ville_Départ, Ville_Arrivée) ayant pour clé le


couple d’attributs (Pilote, Avion) et vérifiant les dépendances multivaluées suivantes :

Pilote →→ Avion


Pilote →→ (Ville_Départ, Ville_Arrivée)

Cette relation n’est pas en 4 FN car l’attribut Pilote est une partie gauche de deux
dépendances multivaluées mais n’est pas une clé candidate de R (Pilote n’est qu’une
partie de la clé!)

exemple 2:

La relation ETUDIANT(NUMERO, COURS, SPORTS) que nous avons déjà vue a


pour clé l’ensemble de ses attributs (NUMERO, COURS, SPORTS).

Nous avons vu que les dépendances multivaluées NUMERO →→ COURS et


NUMERO →→ SPORTS sont vérifiées dans cette relation. Or l’attribut NUMERO
n’est pas une clé pour cette relation et par conséquent la relation ETUDIANT ne peut être
en 4 FN.

10.5 Décomposition selon une dépendance multivaluée


La dépendance multivaluée fournit une condition nécessaire et suffisante de décomposition d’une
relation en deux relations et cette décomposition se fait sans perte d’information.

10.5.1 Théorème

Soit une relation R(Ω) et soit une partition (X, Y, Z) de Ω (X ∪ Y ∪ Z = Ω ). Si la dépendance


multivaluée X →→ Y est vérifiée dans R, on peut décomposer R en R1(X, Y) et R2(X, Z) tel que :

R(Ω) = R1(X,Y) R1(X,Z)

exemple 1 :

Soit la relation VOL(Pilote, Avion, Ville_Départ, Ville_Arrivée) qui n’est pas en 4 FN car
Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •132

Pilote est une partie gauche de deux dépendances multivaluées mais Pilote n’est pas une clé
candidate de R (Pilote n’est qu’une partie de la clé!). Elle peut donc être décomposée selon la
d.m. Pilote →→ Avion en :

R1(Pilote, Avion) et R2(Pilote, Ville_Départ, Ville_Arrivée) et on aura :

VOL = R1(Pilote, Avion) R2(Pilote, Ville_Départ, Ville_Arrivée)

exemple 2 :

La relation ETUDIANT(NUMERO, COURS, SPORTS) que nous avons présentée plus haut
n’est pas en 4 FN. On peut la décomposer selon l’une ou l’autre de deux dépendances
multivaluées NUMERO →→ COURS ou NUMERO →→ SPORTS qui contredisent la
définition de la 4FN. On aura donc :

ETUDIANT = R1(NUMERO, COURS) R2(NUMERO, SPORTS)

avec R1 et R2 qui sont maintenant toutes les deux en 4 FN.

10.5.2 Préservation de la jointure

Une décomposition de R vérifiant un ensemble G de dépendances fonctionnelles et de dépendances


multivaluées en (R1,R2) préserve la jointure si et seulement si l’une des dépendances multivaluées
suivantes ∈ G+ :

R1 ∩ R2 →→ R1 - R2 ou R1 ∩ R2 →→ R2 - R1

G+ représente la fermeture de G et est égal à G ∪ { toutes les dépendances fonctionnelles et les


dépendances multivaluées qu’on peut déduire de G par application des propriétés des dépendances
fonctionnelles et multivaluées }.

10.5.3 Remarque

Il a été montré que toute relation admet une décomposition (pas forcément unique) en 4FN et qui
se fait sans perte d’information.

11 Dépendance de Jointure et cinquième forme normale

11.1Intérêt des dépendances de jointures


Une dépendance multivaluée au même titre qu’une dépendance fonctionnelle permet seulement de
décomposer une relation en deux (02) relations et pas plus. Cependant, il a été constaté qu’il existe des
relations qui peuvent être décomposées en trois (03) relations et plus et la décomposition se fait sans
perte d’informations. Ceci montre donc l’insuffisance des dépendances multivaluées.

Soit la relation EXPERIENCE (Employé, Atelier , Machine) modélisant la réalité suivante :


Un employé a acquis une expérience dans un ou plusieurs Ateliers sur une ou plusieurs machines. Un
exemple d’extension de cette relation est :

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •133

Employé Atelier Machine


E1 At1 M1
E1 At1 M2
E1 At2 M2
E2 At1 M2

Figure 3.25 Une extension de la relation EXPERIENCE

On remarque des redondances d’information dans cette extension. Par exemple les valeurs E1 , At1
et M2 sont répétées plusieurs fois. On peut aussi vérifier que :

ƒ Employé /→ Atelier : pour E1 on 2 valeurs différentes de Atelier (E1, At1) et


(E1, At2)
ƒ Employé /→ Machine : pour E1 on deux valeurs différentes de Machine (E1, M1)
et (E1, M2)
ƒ Atelier /→ Employé : pour At1 on deux valeurs différentes de Employé (At1, E1)
et (At1, E2)
ƒ Machine /→ Employé : pour M2 on deux valeurs différentes de Employé (M2, E1)
et (M2, E2)
ƒ Machine /→ Atelier : pour M2 on deux valeurs différentes de Atelier (M2, At1)
et (M2, At2)
ƒ Atelier /→ Machine : pour At1 on deux valeurs différentes de Machine (At1, M1)
et (At1, M2)

Ceci montre que la relation ne peut pas être décomposée grâce au théorème de décomposition
utilisant comme base une dépendance fonctionnelle puisque cette relation ne vérifie aucune
dépendance fonctionnelle et par conséquent les problèmes de redondance posés par celle-ci ne peuvent
pas être éliminés.

Il en est de même pour les dépendances multivaluées. On peut vérifier que la relation ne vérifie pas
les dépendances multivaluées suivantes :

ƒ Employé /→→ Atelier car on a les 2 tuples (E1, At1, M1) et (E1, At2, M2) mais on a le
tuple (E1, At1, M2) et pas le tuple (E1, At2, M1)

On peut de la même manière montrer que les dépendances multivaluées suivantes ne sont pas aussi
vérifiées :

ƒ Employé /→→ Machine

ƒ Atelier /→→ Employé

ƒ Atelier /→→ Machine

ƒ Machine /→→ Employé

ƒ Machine /→→ Atelier

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •134

Ainsi, cette relation ne peut pas être décomposée grâce au théorème de décomposition utilisant
comme base une dépendance multivaluée puisque elle ne vérifie aucune dépendance multivaluée et par
conséquent les problèmes de redondance posés par celle-ci ne peuvent pas être éliminés.

Considérons maintenant les trois décompositions binaires suivantes de cette relation :

1) {R1(Employé, Atelier) , R2(Atelier, Machine) }


2) {R1(Employé, Atelier) , R3(Employé, Machine) }
3) {R2(Atelier, Machine) , R3(Employé, Machine) }

Les extensions de R1 , R2 et R3 seront obtenues par des projections de la relation R sur les
attributs respectifs de R1, R2 et R3. Ces extensions sont :

Employé Atelier Atelier Machine Employé Machine


E1 At1 At1 M1 E1 M1
E1 At2 At1 M2 E1 M2
E2 At1 At2 M2 E2 M2

R1 (Employé , Atelier) R2 ( Atelier , Machine) R3 ( Employé , Machine)

Figure 3.26 Extension de R1, R2, R 3

On peut vérifier que :

• Le schéma de la relation EXPERIENCE est égal à l’union des schémas de R1 et de R2 :


(Employé , Atelier, Machine) mais que l’extension de cette relation est différente de celle
de :

R1 R2

• Le schéma de la relation EXPERIENCE est égal à l’union des schémas de R1 et de R3 :


(Employé , Atelier, Machine) mais que l’extension de cette relation est différente de celle
de :

R1 R3

• Le schéma de la relation EXPERIENCE est égal à l’union des schémas de R2 et de R3 :


(Employé , Atelier, Machine) mais que l’extension de la relation est différente de celle de
:

R2 R3

Donc cette relation ne peut pas être décomposée sans perte en deux relations seuleument.

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •135

Cependant on peut très bien vérifier que le schéma de la relation EXPERIENCE est égale à l’union
des schémas de R1 , R2 et R3 : (Employé , Atelier, Machine) et son extension est égale aussi à
celle de la relation :

R1 R2 R3

Ceci montre bien que cette relation peut très bien être décomposée sans perte d’informations en
trois (03) relations R1 , R2 et R3. On constate donc l’insuffisance d’une dépendance multivaluée
(comme celle d’une dépendance fonctionnelle) du fait qu’elle ne capture que la possibilité de
décomposer sans perte d’information une relation en deux (02) relations seulement.

Nous avons vu que toute relation R(Ω) vérifiant une dépendance multivaluée X →→ Y peut être
décomposée sans perte d’informations en deux relations R1(X,Y) et R2( Ω - X ∪ Y). Et puisque nous
venons de voir qu’il existe des relations telle que EXPERIENCE qui sont décomposables sans perte
d’information non pas en deux relations mais en trois relations ou plus, il est évident que même les
dépendances multivaluées ne suffisent donc plus à palier aux problèmes pour lesquels nous visons à
décomposer une relation (i.e. redondance d’informations, Mise à jour, ...)

La notion de dépendance de jointure va justement permettre de décomposer une relation en


plusieurs autres relations.

11.2 Définition

Soit R (Ω) une relation et X1, X2, ....... Xm des sous ensembles de Ω. On dit que R vérifie la
dépendance de jointure qu’on note * { X1, X2, ....... Xm } si on a :

R= ∏ X1 (R) ∏ X2 (R) •••••••• ∏ Xm (R)

C’est à dire R est égale à la jointure de ses projections sur X1, X2, ....... Xm.

Exemple :

Nous avons vu par exemple que la relation EXPERIENCE est égale à :

EXPERIENCE = R1 R2 R3

avec :

R1 = ∏ Employé , Atelier(EXPERIENCE )
R2 = ∏ Atelier , Machine (EXPERIENCE )
R3 = ∏ Employé , Machine (EXPERIENCE )

On peut donc dire que EXPERIENCE vérifie la dépendance de jointure :

* { (Employé , Atelier) ; (Atelier , Machine ) ; (Employé , Machine ) }

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •136

11.3 Remarque
Une dépendance multivaluée est un cas particulier de dépendance de jointure. En effet, une relation
R (Ω ) avec (X,Y,Z) une partition de Ω qui vérifie la dépendance multivaluée X →→ Y (et donc X
→→ Ω - ( X ∪Y) par complémentation), vérifie la dépendance de jointure * { (XY) , (XZ) } car :

R = R1(X , Y) R2(X , Z)

Ceci est le cas aussi pour une dépendance fonctionnelle.

11.4 Cinquième Forme Normale (5 FN)


La cinquième forme normale va donc être définie à partir de la notion de dépendance de jointure.

11.4.1 Définition

Une relation est en 5 FN si toute dépendance de jointure est impliquée par ses clés candidates.

Cette définition laisse donc supposer que l’on soit capable de vérifier qu’une dépendance de
jointure est impliquée ou non par les clés candidates d’une relation pour pouvoir affirmer si cette
relation est ou non en 5FN. On dispose pour cela d’un algorithme qui sera présenté plus loin.

Exemple :

Soit la relation R(A, B, C, D) ayant deux clés candidates qui sont l’attribut A et l’attribut B.
Cette relation peut être décomposée sans perte d’informations en :

„ R1(A,B) ; R2 (A,C) ; R3(A,D) ou


„ R’1(A,B) ; R’2(B,C) ; R’3(B,D)

(" Vérifier ce résultat en utilisant l’algorithme d’Ullman ?)

D’après la définition d’une dépendance de Jointure, on peut donc dire que la dépendance de
Jointure on a : * { (A,B) ; (A,C) ; (A,D) } est vérifiée par R puisque :

R = R1(A , B) R2(A , C) R3(A , D)

Il en est de même pour la dépendance de Jointure * { (A, B) ; (B, C) ; (B, D) } puisque :

R = R’1(A , B) R’2(B , C) R’3(B , D)

11.4.2 Dépendance de jointure impliquée par un ensemble de clés candidates

La définition de la 5FN montre que la connaissance des clés candidates d’une relation implique la
connaissance de dépendances de jointures impliquées par ces clés candidates. En pratique, on dispose
d’un algorithme permettant de tester si une D.J. est impliquée par un ensemble K de clés
candidates d’une relation R. L’enoncé de cet algorithme est le suivant :

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •137

11.4.2.1 Enoncé de l’algorithme

Fonction IMPLIQUE (K , D.J.)


|
| $ Entrée :
| D.J. une dépendance de jointure * {X1, X2, ........ Xm}
| K : un ensemble de clés k1→ Ω ; ...... ; kr → Ω ;
| $Sortie :
| IMPLIQUE = Vrai si la D.J. est impliquée par K
| IMPLIQUE = Faux si la D.J. n’est pas impliquée par K
|
| Début :
| | S ← {X1, X2, ........ Xm} ;
| | Tant que ∃ ki , Y∈S et Z ∈S tel que ki ⊆ Y ∩ Z Faire
| | |
| | | Enlever Y et Z de S ;
| | | Ajouter Y ∪ Z dans S ;
| | |
| | Fin tant que
| |
| | Si Ω∈ S
| | |
| | Alors IMPLIQUE ← Vrai ;
| | |
| | Sinon IMPLIQUE ← Faux ;
| | |
| | Finsi
| |
| Fin
|
Fin IMPLIQUE

11.4.2.2 Application de l’algorithme

Nous allons utiliser cet algorithme pour vérifier que les deux D.J. * { (A,B) ; (A,C) ; (A,D) } et
* { (A,B) ; (B,C) ; (B,D) } de la relation R(A, B, C, D) vue plus haut sont impliquées par les clés
candidates de R qui sont A et B.

Nous allons traiter uniquement le cas de la D.J. * { (A,B) ; (A,C) ; (A,D) }

étape0 :
S ← {(A,B) ; (A,C) ; (A,D)}
K← {A ; B}

étape1 :
prenons k1=A et Y = (A,B) et Z=(A,C) puisque k1 ⊆ Y ∩ Z =A on doit :
enlever Y et Z de S ce qui donne S = {(A,D)}
rajouter Y ∪ Z à S ce qui donne S ={(A,D);(A,B,C)}

étape2 :
prenons toujours k1=A et Y = (A,D) et Z=(A,B,C)
puisque k1 ⊆ Y ∩ Z =A on doit :
enlever Y et Z de S ce qui donne S = {∅}
rajouter Y ∪ Z à S ce qui donne S ={ (A, B,C,D)}

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •138

étape3 :
on remarque que Ω=(A,B,C,D) ∈ S donc on conclut que cette D.J. est impliquée par
les clefs candidates de R.

(" Refaire le même travail avec l’autre D.J.)

Nous allons vérifier que la D.J. * {(Employé, Atelier); (Atelier, Machine); (Employé,
Machine)} de la relation EXPERIENCE donnée dans les paragraphes précédents n’est pas impliquée
par la seule clé candidate de cette relation qui est (Employé, Atelier, Machine).

étape0 :
S ← {(Employé, Atelier); (Atelier, Machine); (Employé, Machine)}
K← {(Employé, Atelier, Machine)}

étape1 :
prenons le seul k1=(Employé, Atelier, Machine) et Y = (Employé, Atelier) et
Z=(Atelier, Machine) puisque k1 ⊄ Y ∩ Z =Atelier on ne peut faire aucune
modification sur S.

étape2 :
prenons le seul k1=(Employé, Atelier, Machine) et Y = (Employé, Atelier) et
Z=(Employé, Machine) puisque k1 ⊄ Y ∩ Z =Employé on ne peut faire
aucune modification sur S.

étape3 :
prenons le seul k1=(Employé, Atelier, Machine) et Y = (Atelier, Machine) et
Z=(Employé, Machine) puisque k1 ⊄ Y ∩ Z =Machine on ne peut faire aucune
modification sur S.

étape4 :
Toutes les combinaisons ont été testées et à la sortie de la boucle Tantque on a
toujours S={(Employé, Atelier); (Atelier, Machine); (Employé, Machine)}.

Donc puisque Ω= (Employé, Atelier, Machine) ∉S on conclut que la D.J. n’est pas impliquée
par la seule clef candidate de la relation.

11.4.2.3 Remarques

Toute relation en 5 FN ne peut plus être décomposée sans perte d’informations sauf dans le cas de
décompositions basée sur les clés de la relation et qui n’ont pas d’intérêt pratique (supprimer les
redondances et les anomalies de mise à jour).

La 5 FN est donc un point final à la décomposition par Projection - Jointure. La 5 FN est aussi
appelée Forme Normale de Projection - Jointure.

12 Normalisation : entre la théorie et la pratique


12.1Les dépendances fonctionnelles sur le plan pratique
Les dépendance fonctionnelles ou multivaluées servent principalement à obtenir un schéma
relationnel dans lequel les relations sont dans une forme normale (3ième ou plus) jugées acceptables
par le concepteur. Cette étape a lieu avant l’implémentation de la base de données. Une fois le
processus de normalisation terminé, on passe à la phase d’implémentation sous forme de tables en
utilisant les possibilités offertes par le SGBD relationnel dont on dispose. Les remarques que nous

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •139

devons faire seront les suivantes :

• Aucun SGBD n’offre un moyen pour énoncer la ou les d.f. vérifiées par une relation que l’on
souhaite implémenter sous forme de table et ce quelle que soit la forme normale de cette
relation.

• Aucun SGBD n’offre un moyen pour énoncer la ou les D.M. vérifiées par une relation que l’on
souhaite implémenter sous forme de table et ce quelle que soit la forme normale de cette
relation.

On sait aussi que le processus de normalisation s’il conduit à des relations en 3FN ceci veut dire
que chaque relation vérifient des d.f. du style :

clef candidate → attribut non primaire (dépendance totale et directe)

Dans le cas ou les relations sont en BCNF ceci veut dire que chaque relation vérifient des d.f. du
style :

clef candidate → attribut (dépendance totale et directe)

Au moment de l’implémentation, il faudra ne retenir qu'une seule clé primaire K. Ainsi, les d.f.
ayant en partie gauche cette clef primaire seront simplement traduites en précisant au moment de la
description de la relation avec le concept de table du SGBD que cette table possède une clé primaire
K. Ceci se fait généralement grâce à une clause du LDD du style : PRIMARY KEY IS..... Dans
certains SGBD ou certaines versions , si cette possibilité n’existe pas on aura à construire un index
unique avec la clé primaire K. Ceci se fait généralement grâce à une instruction du LDD du style :
CREATE INDEX ON.... . Ceci traduit le fait que la clef primaire va servir au SGBD pour contrôler
l’unicité des tuples insérés dans la base et c’est le rôle joué par une clé. Dans le cas ou une relation
posséderait plusieurs clés candidates en plus de la clef primaire retenue, il serait tout a fait possible de
construire pour chaque clé candidate un index unique de la même manière qu'avec la clef primaire.
Chacun de ces indexes va servir au SGBD pour contrôler l’unicité des tuples insérés dans la base, mais
aussi de permettre des accès sélectifs au tuples en fonctions de valeurs des clefs candidates pour
lesquelles un index aurait été créé.

12.2 Le problème de l’intégrité référentielle

Le processus de décomposition d’une relation engendre souvent un problème dit de l’intégrité


référentielle et que nous pouvons expliquer à travers l’exemple suivant :

Soit la relation R ( NUMETUDIANT , NOM , DIPLOME , INSTITUT ) ayant pour clé l’attribut
NUMETUDIANT et vérifiant la d.f. INSTITUT → DIPLOME. Nous avons vu qu’elle n’est
pas en 3FN. Une décomposition donnerait :

R1 (INSTITUT , DIPLOME ) vérifiant la d.f. : INSTITUT → DIPLOME qui est en BCNF


R 2( NUMETUDIANT , NOM , INSTITUT ) vérifiant les d.f. : NUMETUIDANT→NOM,
INSTITUT qui est aussi en BCNF.

Dans la relation R1 la clé INSTITUT sera une clé primaire. Elle sera déclarée par l’une ou l’autre
des techniques expliquées plus haut au moment de l’implémentation de R1 sous forme de table au
niveau du SGBD.

Dans la relation R2 la clé NUMETUDIANT sera une clé primaire. Elle sera déclarée par l’une ou
l’autre des techniques expliquées plus haut au moment de l’implémentation de R2 sous forme de table
au niveau du SGBD. Cependant on remarque qu’un attribut de R2 qui est INSTITUT joue le rôle de

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •140

clef primaire dans R1. Ceci crée ce qu’on appelle le problème de l’intégrité référentielle et qui se
traduit par la situation suivante :

R1 R2
INSTITUT DIPLOME NUMETUDIANT NOM INSITUT
Informatique DEUA 01 ALI informatique
Droit License 02 OMAR informatique
Physique Doctorat 03 Tahar Droit

Figure 3.27 Extension de R1, R2

Les valeurs de l’attribut INSTITUT se trouvant dans la relation R2 référencent toutes des tuples
dans la relation R1. Si on supprime un tuple dans R1 correspondant à l’institut d’informatique, cette
suppression a une répercussion directe sur la relation R2 qui contient toujours la valeur
INFORMATIQUE dans la colonne INSTITUT alors que dans R1 cet institut ne figure plus.
Généralement la présence d’un même attribut dans deux relation différentes sous entend que des
opérations de jointure naturelles peuvent être réalisées en vue de répondre à certains types de question.
(ex : quel est le diplôme préparé par ALI qui nécessitera une jointure entre R1 et R2)

De là on voit que le problème de l’intégrité référentielle et un problème sérieux qui est introduit
suite à l’application du processus de normalisation. On doit y remédier soit en déclenchant une
suppression en cascades dans R2 de tous les tuples ou apparaît INFORMATIQUE, soit laisser ce
travail pour le SGBD. Ceci n’est pas toujours possible en l’absence de moyens à mettre à la
disposition du concepteur. Certains SGBD donnent la possibilité lors de la description de R2 avec le
LDD de spécifier que INSTITUT est une clé étrangère dans R2 et qu’elle référence la clé primaire
INSTITUT de la relation R1.

12.3 La dénormalisation des relations


Comme nous l’avons souligné plus haut, le processus de décomposition d’un schéma relationnel
permet d’obtenir un schéma relationnel dans lequel les relations sont dans une forme normale (3ième
ou plus) qui ne posent pas de problèmes. Cependant, dans la pratique des critères de performances
d’accès à la base de données peuvent conduire le concepteur à préférer un schéma relationnel
contenant une ou plusieurs relations qui ne sont pas dans une forme normale acceptable à un autre.
Cette technique s’appelle la dénormalisation des relations(voir l’exercice 19 qui traite ce problème).

13 Conclusion
Les dépendances servent à transformer un schéma relationnel en vue de minimiser les redondances
d’information et les problèmes de mise à jour. En pratique, la normalisation va rarement au delà de la
BCNF. Elle a pour but de remplacer un problème de dépendance intra-relation (entre les attributs
d’une même relation) par un problème de dépendance inter- relation issu de la duplication d’attributs
dans les relations obtenues par décomposition et qui est directement lié à la notion de contrainte
d’intégrité référentielle.

La hiérarchie des différentes formes normales peut être schématisée comme suit :

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •141

1 FN

2 FN

3 FN Décompositions basées sur :


Par définition BCNF - les dépendances fonctionnelles
-les dépendances multivaluées
4 FN
-les dépendances de jointure
5 FN

Les dépendances fonctionnelles sont les plus fréquentes dans les problèmes pratiques du fait
qu’elles sont les plus faciles à exprimer. En plus des dépendances fonctionnelles, des dépendances
multivaluées et des dépendances de jointures, d’autres types de dépendances ont été aussi identifiés
par les chercheurs. On peut citer :

• les dépendances hiérarchiques


• les dépendances d’inclusion
• les isodépendances
• etc.

L’étude de ces dépendances a surtout servi pour l’approfondissement des aspects théoriques du
modèle relationnel et n’a pas donc eu de répercussion significative sur les applications.

Certains auteurs proposent même d’autres formes normales telles que :

• Forme normale 3,3 : qui résulte d’une décomposition basée sur la sélection et l’union
contrairement aux décompositions que nous avons vues à travers ce chapitre et qui sont
principalement basées sur la projection et la jointure. Il a été montré qu’une relation
en 3,3 FN est aussi en BCNF et n’a pas besoin d’être exprimée en 4FN ou en 5FN.

• Forme normale DK (Domain/Key) : qui comprend des contraintes sur la clé primaire
et sur les valeurs prises par les attributs. Une relation en forme normale DK est aussi en
5 FN (et donc en 4 FN aussi)

Enfin les travaux sur la normalisation préoccupent encore beaucoup de chercheurs. Parmi les
résultats les plus importants, il faut noter des propositions d’extension du modèle relationnel dans le
soucis de permettre la prise en compte par le SGBD de nouveaux types de données autres que ceux
propres aux applications de gestion classiques (entier, réel, chaîne de caractères, Date, etc.). On peut
citer par exemple l’image, le son, les documents de Bureautique, ou les cartes géographiques.
C’est ainsi qu’on parle de Bases de Données MULTIMEDIA, Bases de données Cartographiques,
etc. L’extension du modèle relationnel la plus significative est le modèle N-F (ou Non First Normal
Form ) qui est un modèle relationnel dans lequel la contrainte d’avoir au moins des relations en 1 FN
n’est plus imposée.

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •142

Exercices sur le Chapitre 3

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •143

Exercice 1 :

Soit la relation ELECTIONS(GAGNANT, PERDANTS, ANNEE)

ANNEE GAGNANT PERDANTS

1970 ALI (OMAR,RACHID, KAMEL)


1985 OMAR (ALI, RACHID, RABAH, TAHAR)
1988 ALI (OMAR, RACHID, RABAH, TAHAR)
1990 RACHID (ALI, RABAH, KAMEL)

Q1 : cette relation est-elle en 1 FN?


Q2 : Proposez une ou plusieurs méthodes pour la mettre en 1 FN?

Exercice 2 :

Soit la relation R(PROJET, PIECE, FOURNISSEUR, ADRESSE_F, N) modélisant le fait qu'un


fournisseur f ayant pour adresse af a fourni n pièces de type p pour le projet pr.

Les attributs ont donc la signification suivante :

PROJET : numéro de projet


PIECE : nom de pièce
FOURNISSEUR : nom de fournisseur
ADRESSE_F : adresse du fournisseur
N : nombre de pièces fournies

Sachant que les dépendance fonctionnelles suivantes sont vérifiées par cette relation :

FOURNISSEUR → ADRESSE_F ;


PROJET,PIECE → FOURNISSEUR, N

Q1 : Trouvez une clé pour cette relation.


Q2 : Représentez graphiquement les dépendances fonctionnelles vérifiées par
Q3 : Dans quelle forme normale est cette relation
Q4 : Si vous jugez que la relation doit aussi etre décomposée, Proposez une décomposition de celle-ci
en précisant le type de forme normale et la clé des relations obtenues
Q5 : Cette décomposition se fait- elle sans perte d'information et préserve-t-elle les D.F.?

Exercice 3 :

On considére la relation AUTEUR(NOM, ADRESSE, TITRE, ANNEE) dont les attributs ont les
significations suivantes :

NOM : nom de l'auteur


ADRESSE : adresse de l'auteur
TITRE : titre de l'ouvrage écrit par l'auteur
ANNEE : année d'édition de l'ouvrage

Sachant que les dépendances fonctionnelles suivantes sont vérifiées par cette relation :

NOM → ADRESSE ; (NOM,TITRE) → ANNEE

Q1 : Montrez que le couple d'attributs (NOM,TITRE) constitue une clé pour cette relation.
Q2 : Dans quelle forme normale est cette relation et pourquoi ?

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •144

Q3 : Proposez une décomposition de cette relation en précisant les D.F. et les clés associées aux
relations obtenues ainsi que le type de Forme Normale de chacune.
Q4 : Votre décomposition se fait- elle sans perte d'information et préserve-t-elle les D.F.?

Exercice 4 :

Soit la relation EXPERIENCE(NUMERO, NOM, SPECIALITE, VILLE) ayant pour clé l'attribut
NUMERO et modélisant les spécialités acquises par les employés dans différentes villes. Les attributs
ont les significations suivantes :

NUMERO : numéro d’un employé


NOM : nom d’un employé
SPECIALITE : spécialité acquise par un employé dans une ville
VILLE : Ville où l'employé a acquit sa spécialité

et considérons l'extension suivante de cette relation :

NUMERO NOM SPECIALITE VILLE

1 ALI MECANIQUE ANNABA


2 OMAR ELECTRICTE BISKRA
3 KAMEL PLOMBERIE ORAN
4 RACHID ELECTRICITE BISKRA
5 SAMIR MECANIQUE ANNABA
6 TAHAR MECANIQUE SETIF
7 RIAD ELECTRICITE BISKRA

Sachant que la dépendance fonctionnelle VILLE → SPECIALITE est vérifiée par cette relation
:

Q1 : Expliquer la signification de la dépendance fonctionnelle : VILLE → SPECIALITE pour


cette relation.
Q2 : Est-ce que les trois types d'anomalies suivantes peuvent avoir lieu dans cette relation (justifiez
votre réponse par des exemples) :

- anomalies d'insertion
- anomalies de suppression
- anomalies de mise à jour
Q3 : Proposez une décomposition de cette relation en :

- en 2FN
- en 3FN
- en BCNF
Q4 : On suppose maintenant qu'un employé peut avoir plusieurs spécialités différentes qu'il aura
acquises dans des villes différentes.

a) Dire pourquoi l'attribut NUMERO ne constitue plus une clé pour cette relation.
Proposez alors une autre clé en justifiant votre proposition.
c) Quelle est maintenant le type de forme normale de cette relation.
d) Si vous jugez que la relation doit aussi être décomposée, Proposez une décomposition
de celle-ci en précisant le type de Forme Normale et la clé des relations obtenues
e) Votre décomposition se fait- elle sans perte d'information? Préserve-t-elle les D.F.?

Exercice 5 :

Soit la relation R(ETUDIANT, MODULE, PROF, INSTITUT) modélisant la réalité suivante :

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •145

1) Un étudiant suit un module donné dans un seul institut


2) Un étudiant suit un module donné avec un seul professeur
3) Un professeur n’enseigne qu’un seul module

Q1 : Exprimez cette réalité à l’aide de dépendances fonctionnelles


Q2 : Dans quelle forme normale est cette relation
Q3 : Si vous jugez que R doit être décomposée, Proposez une décomposition et dites si celle-ci
préserve la jointure et/ou les D.F.

Exercice 6 :

Soit la relation R(Employé, Atelier, Machine) modélisant l’affectation des employés sur des
machines se trouvant dans des ateliers. Sachant que l’extension suivante de cette relation ne contient
aucun tuple contredisant la réalité modélisée :

Employé Atelier Machine

ALI AT1 PERCEUSE


OMAR AT1 PERCEUSE
OMAR AT2 FRAISEUSE
ALI AT1 TOUR
KAMEL AT1 TOUR
KAMEL AT1 PERCEUSE

Q1 : Dans quelle forme normale est cette relation


Q2 : Proposez une décomposition de R en 3FN de façon à préserver la jointure et les D.F.

Exercice 7 :

Soit la relation R ( ETUDIANT , MODULE , ENSEIGNANT , SALLE ) vérifiant l’ensemble F de


D.F. suivant :

1- ETUDIANT , MODULE → ENSEIGNANT ;


2- ENSEIGNANT , SALLE → MODULE ;
3- ETUDIANT , ENSEIGNANT → MODULE ;
4- MODULE , ENSEIGNANT → SALLE ;
5- ETUDIANT , MODULE → SALLE ;
6- ETUDIANT , ENSEIGNANT → SALLE ;

Q1 : Quelles sont les D.F. redondantes et non redondantes dans F (justifiez votre réponse grâce à
l’algorithme de calcul de X+)

Q2 : Trouvez une couverture minimale pour F


Q3 : Proposez une décomposition en 3FN de R grâce à l’algorithme de décomposition utilisant
comme entrée une couverture minimale des D.F. et dire si elle préserve la jointure et / ou les
D.F. ?
Q4 : On se propose de décomposer R en 2 relations :

R1(ETUDIANT , SALLE , ENSEIGNANT) et R2 (ETUDIANT , MODULE , SALLE)

a) Cette décomposition préserve-t-elle la jointure ?

Exercice 8 :

Soit la relation R ( A , B , C , D , E , F ) vérifiant l’ensemble F de D.F. suivants :

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •146

A → C , F
B → D , F
C → A , E
D → A , F
A → D , E
B → C , E
C → B , F
D → B , E
E → C
F → B

Q1 : Quelles sont les D.F. redondantes dans F ?


Q2 : Quelles sont les D.F. non élémentaires de F ?
Q3 : Est-ce que l’un des couples d’attributs suivants peut constituer une clé candidate pour R ?

- (A,C)
- ( B , C)
- (B,F)
- (A,D)
- (B,D)
- (C,E)
- (A,E)
- (B,E)
- (C,F)

Q4 : Trouvez toutes les autres clés candidates de R ?


Q5 : Dans quelle forme normale est R ?
Q6 : Proposez une décomposition pour R en deux relations seulement en précisant pour chaque
décomposition si celle-ci préserve la jointure et/ou les D.F. ? Trouvez d'autres décompositions
pour R ?

Exercice 9 :

Soit la relation R(Employé, Machine, Heure, Opération) dans laquelle un tuple (e, m, h, op)
signifie que l’employé e est affecté sur la machine m à l’heure h pour exécuter l’opération op. Sachant
que les D.F. vérifiées par R sont :

F= { Employé → Machine ; Machine, Heure → Opération }

Et étant donnée l’extension suivante de cette relation :

Employé Machine Heure Opération


E1 M1 H1 OP1
E2 M1 H1 OP1
E2 M1 H2 OP2
E1 M1 H2 OP2
E3 M2 H2 OP1
E3 M2 H1 OP3

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •147

Q1 : Existe-t-il des tuples dans cette extension qui contredisent la réalité modélisée par cette relation .
Si oui, supprimez-les pour la suite de l’exercice.

Q2 : Parmi les D.F. suivantes, quelles sont celles qui ∈ à F+ et celles qui ∉ à F+ ? :

(Employé , Opération) → Machine , Heure


(Employé , Machine) → Opération , Heure
(Machine , Opération) → Employé , Heure
(Machine ,Heure ) → Employé , Opération
(Heure , Opération) → Employé , Machine

Q3 : Le triplet ( Employé, Machine, Heure) constitue-t-il une clé candidate pour R ?


Trouvez d’autres clés candidates pour R
Q4 : Dans quelle forme normale est cette relation ?
Q5 : Proposez une décomposition de R et précisez si celle-ci préserve la jointure et/ou les D.F.
Vérifiez votre résultat sur l’extension donnée plus haut et tenant compte de votre réponse à la
question Q1

Exercice 10 :

Soit la relation R ( NUMETUDIANT , NOM , DIPLOME , INSTITUT ) modélisant les diplomes


que préparent les étudiants dans des instituts. Sachant que R a pour clé l’attribut NUMETUDIANT et
qu’elle vérifie la D.F. : INSTITUT → DIPLOME :

Q1 : Cette relation poserait-elle des problèmes au niveau de :

a) l’insertion de tuples
b) la suppression de tuples
c) la mise à jour de tuples
d) la redondance d’information

Q2 : Si vous estimez que R doit être décomposée , Dites pourquoi et Proposez une décomposition En
précisant si elle préserve la jointure et / ou les D.F.

Q3 : On suppose maintenant qu’un étudiant peut préparer plusieurs diplômes différents dans des
instituts différents ,

a) l’attribut NUMETUDIANT est-il dans ce cas une clé pour R? Dans le cas contraire ,
trouvez une nouvelle clé pour R ?

b) Dans quelle Forme Normale est R


c) Proposez une décomposition de R en précisant si elle preserve la jointure et / ou les D.F.

Exercice 11 :

Soit R( X , Y , Z ) , l'implication suivante est-elle vraie ou fausse ? Justifiez votre réponse par une
démonstration.

R = R1(X,Y) R2(Y,Z) ⇒ la d.f. X →Y est vérifiée par R

Exercice 12 :

- Montrer qu'une relation en 3FN est aussi en 2FN.


- Montrer qu'une relation en BCNF est aussi en 3FN.
- Montrer qu'une relation en BCNF est aussi en 2FN.
Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •148

Exercice 13 :

Soit la relation R(VOL, JOUR, PL, AV, TYPEVOL) ou les attributs ont les significations suivantes :

VOL : numéro du vol


JOUR : jour du vol
PL : numéro du pilote affecté à ce vol
AV : numéro de l'avion qui effectue ce vol
TYPEVOL : qualité du vol

Sachant que la clé primaire de cette relation est formée par le couple d'attributs (VOL, JOUR) et que
chaque VOL a une qualité unique (un TYPEVOL unique) :

Q1 : Donner un graphe des D.F. vérifiées par R.


Q2 : Dans quelle forme normale est cette relation ?
Q3 : Quelles sont les anomalies pouvant exister dans R.
Q4 : Proposer une décomposition de R telle que les relations obtenues soient au moins en 2FN.

Exercice 14 :

Soit la relation R (A, B, C, D, E) munie des D.F. suivantes :

F={A → C ; D, E → C ; B → C ; C, E → A ; C → D} ;

Et soit la décomposition de R suivante :

{ R1 (A, D) ; R2 (A, B) ; R3 (B, E) ; R4 (C, D, E) ; R5 (A, E) }

Q1: Cette décomposition se fait-elle sans perte d’informations?

Exercice 15 :

Soit la relation R (ETUDIANT, MODULE, PROF) munie des D.F. suivantes :

F = { ETUDIANT , MODULE → PROF ; PROF → MODULE }

Et soit l'extension suivante de R :

ETUDIANT MODULE PROF


ALI MATH IL
ALI BD ELLE
OMAR MATH IL
OMAR BD MOI

Q1 : Est-ce que la D.F. MODULE → PROF est vérifiée par R ?


Q2 : Quelles seraient les clefs candidates de R?
Q3 : R est-elle en BCNF ?
Q4 : Donner une décomposition de R en deux relations qui soient au moins en 3FN?
Q5 : Donner l’extension de R1 et R2
Q6 : Calculer la jointure de R1 avec R2 sur le ou les attributs communs. Que pouvez-vous conclure?
Q7 : La décomposition de R en R1 et R2 préserve-t-elle les D.F. ?

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •149

Exercice 16 :

Soit la relation VENTE (VENDEUR , SECTEUR , PRIX, PRODUIT) munie des D.F. suivantes :

F={
VENDEUR, SECTEUR → PRODUIT ;

VENDEUR, SECTEUR → PRIX;

PRIX → SECTEUR }

Et soit l'extension suivante de la RELATION VENTE :

VENDEUR SECTEUR PRIX PRODUIT


ALI 25 10 P1
OMAR 35 15 P2
KAMEL 25 12 P1
ALI 50 20 P2
Q1 : Expliquer la sémantique véhiculée par les D.F. de cette relation ?
Q2 : Peut-on avoir le tuple (ALI,70,10,P3) dans cette relation ?
Q3 : Cette relation est-elle en 3FN ? Est-elle en BCNF ?
Q4 : Si elle n'est pas en BCNF, Décomposez-la

Exercice 17 :

Soit la relation : TARIF (CODE_P , CODE_F , NOM_F , ADR_F, PRIX) ou :

CODE_P : code d'un produit


CODE_F : code du fournisseur pouvant fournir ce produit
NOM_F : nom du fournisseur pouvant fournir ce produit
ADR_F : adresse de ce même fournisseur
PRIX : prix du produit propose par ce fournisseur

Sachant que la relation TARIF possède une clé composée des deux attributs (CODE_P, CODE_F) et
la D.F. CODE_F → NOM_F , ADR_F est vérifiée dans par la relation :

Q1 : La relation est-elle en 1FN ? en 2FN ?


Q2 : Dans le cas contraire, Proposez une décomposition pour la relation et dire dans quelle forme
normale sont les relations obtenues.

Exercice 18 :

Soit la relation :

R (CODE_VENDEUR, NOM_VENDEUR, SECTEUR, CODE_CLIENT, NOM_CLIENT, ADR_CLIENT)

Sachant que les D.F. suivantes sont vérifiées dans R :

1- CODE_VENDEUR → NOM_VENDEUR ;
2- CODE_CLIENT → NOM_CLIENT ,ADR_CLIENT , SECTEUR

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •150

Q1 : Donnez le graphe de ces D.F. ?


Q2 : Montrez que le couple (CODE_VENDEUR, CODE_CLIENT) constitue une clef pour R ?
Q3 : R est-elle en 2FN ?
Q4 : Proposez une décomposition de R telle que les relations obtenues soient au moins en 3FN?

Exercice 19 :

Considérons a nouveau la relation de l’exercice précèdent et soient les trois décompositions suivantes
de cette relation :

SCHEMA 1 :

CLIENT1 (CODE_CLIENT , NOM_CLIENT , ADR_CLIENT, SECTEUR)


VENDEUR1 (CODE_VENDEUR , NOM_VENDEUR)
VENTES1 (CODE_VENDEUR , CODE_CLIENT)

SCHEMA 2 :

CLIENT2 (CODE_CLIENT , NOM_CLIENT , ADR_CLIENT, SECTEUR)


VENDEUR2 (CODE_VENDEUR , NOM_VENDEUR)
VENTES2 (CODE_VENDEUR , SECTEUR)

SCHEMA 3 :

CLIENT3 (CODE_CLIENT , NOM_CLIENT , ADR_CLIENT, SECTEUR)


VENDEUR3 (CODE_VENDEUR , SECTEUR , NOM_VENDEUR)

Ces trois décompositions sont acceptables mais le problème est de trouver des critères pour retenir le
schéma satisfaisant au mieux ces critères. Les critères a utiliser seront de type quantitatifs c'est a
dire permettant d'estimer pour chaque schéma la quantité d'information que contiennent les tables qui
lui sont associées et ce en fonction de certaines données numériques.

Pour cela, on suppose qu'on dispose de 15 VENDEURS a repartir sur 20 SECTEURS et que
chaque VENDEUR peut couvrir 4 SECTEURS au plus et qu'un SECTEUR peut regrouper 50
CLIENTS au maximum.

Q1 : Calculez la cardinalité de la relation (nombre de tuples).


Q2 : Calculez pour chacun des schémas 1, 2 et 3 la cardinalité des relations qui le composent (c.a.d.
le nombre de tuples de chaque relation)
Q3 : Calculez pour chaque relation des schémas 1, 2 et 3 son volume non pas en termes de tuples
mais en termes de nombre d’occurrences d’attributs apparaissant sur chacune des colonne
d’une relation.
Q4 : En fonction des comparaisons faites sur les résultats numériques des questions précédentes, quel
serait à votre avis le schéma le plus optimal et pourquoi ?

Exercice 20 :

Soit la relation R ( A , B , C , D , E , F ) vérifiant les D.F. suivantes :

F= { A → C , F ; B → D , F ; C → A , E ; D → A , F ; A → D , E ;
B → C , E ; C → B , F ; D → B , E ; E → C ; F → B }

Q1 : Trouvez toutes les couvertures minimales pour F ?


Q2 : Trouvez toutes les clefs candidates de R ?
Q3 : Donnez la liste des attributs primaires et celle des attributs non primaires ?

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •151

Q4 : Proposez une décomposition de R en utilisant l’algorithme de décomposition base sur une


couverture minimale de F ? Votre décomposition préserve-t-elle les données ? Si non
transformez-la pour qu'elle les préserve.
Q5 : Proposez une décomposition en BCNF de R en utilisant la méthode basée sur le processus
itératif de décomposition binaire? Votre décomposition préserve-t-elle les d.f. ?

Exercice 21 :

Soit la relation VENTE (VENDEUR , SECTEUR ,PRIX, PRODUIT) munie des D.F. suivantes :

1- VENDEUR,SECTEUR → PRODUIT
2- VENDEUR, SECTEUR → PRIX
3- PRIX → SECTEUR

Et soient les décompositions suivantes de cette RELATION :

1. R1 (VENDEUR , PRODUIT ,PRIX) ; R2 (SECTEUR , PRODUIT) ; R3 (VENDEUR , PRIX)


2. S1 (SECTEUR , PRODUIT ,PRIX) ; S2 (VENDEUR , PRODUIT) ; S3 (SECTEUR , PRIX)

Q1 : Dire si chacune de ces deux décompositions préserve les données ou non en utilisant
l’algorithme d’Ullman

Exercice 22 :

Soit la relation COMANDES(CLIENT, PRODUIT, FOURNISSEUR) qui modélise les produits


commandés par les clients chez un fournisseur fabriquant ces produits. Les attributs de cette relation
ont les significations suivantes :

CLIENT : numéro du client


PRODUIT : code du produit
FOURNISSEUR : nom du fournisseur

et soit l'extension suivante de la relation COMMANDE :

CLIENT PRODUIT FOURNISSEUR

100 P1 ALI
100 P1 OMAR
100 P2 OMAR
104 P1 OMAR

Q1 : Trouvez une clé pour cette relation en justifiant votre réponse.


Q2 : Dans quelle forme normale est cette relation ?
Q3 : Dire si l'une des dépendances multivaluées suivantes est vérifiée par la relation COMMANDES

- CLIENT →→ PRODUIT


- FOURNISSEUR →→ CLIENT
- PRODUIT →→ FOURNISSEUR

Q4 : Est-ce que la dépendance de jointure :

* {(CLIENT,PRODUIT);(CLIENT,FOURNISSEUR);(PRODUIT,FOURNISSEUR)}

est impliquée par la clé de cette relation (trouvée en Q1)

Q5 : Est-ce que la relation COMMANDE est en 5FN et Dans le cas contraire, Mettez-la en 5FN.

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •152

Exercice 23 :

Soit la relation R ( E , M , P , S ) vérifiant les D.F. suivantes :

F={ 1- E , M → P,S
2- P , S → M
3- E , P → M ,S
4- M , P → S

Q1 : Quelles sont les D.F. redondantes et non redondantes dans F (justifiez votre réponse )
Q2 : Trouvez une couverture minimale pour F
Q3 : Proposez une décomposition en 3FN de R en utilisant la couverture minimale trouvée plus haut?
Votre décomposition préserve-t-elle la jointure et / ou les D.F. ?

Exercice 24 :

Montrez qu’une relation qui est déjà en cinquième forme normale (5 FN) est aussi en quatrième
forme normale (4 FN)

Exercice 25 :

Soit la relation VOL (PILOTE, NUM_AVION, VILLE_D, VILLE_A) ou les attributs signifient :

PILOTE : numéro du pilote conduisant l'avion


NUM_AVION : numéro de l'avion
VILLE_D : nom de la ville de départ
VILLE_A : nom de la ville d'arrivée

Et soit l'extension suivante de cette relation :

PILOTE NUM_AVION VILLE_D VILLE_A

11 100 BATNA ALGER


10 100 ALGER BATNA
10 100 BATNA ALGER
10 101 BATNA ALGER

Q1 : Est-ce que l'attribut PILOTE est une clé pour cette relation
Q2 : Meme question avec le couple d'attributs (PILOTE,NUM_AVION)
Q3 : Est-ce que la D.M. PILOTE →→ NUM_AVION est verifiee par la relation VOL ?
Q4 : Donner l'extension des relations R1(PILOTE, NUM_AVION) et R2(PILOTE,VILLE_D, VILLE_A)
obtenues par des projections de la relation VOL sur les attributs de R1 et R2.
Q5 : Calculer la jointure de R1 et R2 sur l'attribut commun PILOTE
Q6 : Est-ce que cette jointure donne la même extension que celle de VOL ?
Q7 : Est-ce que la D.M. PILOTE →→ NUM_AVION est vérifiée par la jointure de R1 avec R2 ?
Q8 : A quelle condition aurait-on donc pu décomposer VOL en (R1,R2) sans perte d'information ?
Q9 : Est-ce que la dépendance de jointure suivante est vérifiée par VOL ? :

*{(PILOTE,NUM_AVION) , (PILOTE,VILLE_D) ,(NUM_AVION,VILLE_D,VILLE_A)}

- Si oui proposer une décomposition de VOL relative a cette dépendance ?


- La jointure des relations obtenues par cette décomposition est-elle égale à VOL?

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •153

Exercice 26 :

Soit la relation R ( A , B , C , D ) vérifiant les D.F. suivantes :

F= { A ,B → C ; D → B ; C → A }

Q1 : Est-ce que l’une des Dépendances de jointure suivantes est vérifiée par R :

a) * { ( A , B , C ) ; ( A , B , D) }
b) *{(B,D) ; ( A , D , C) }
c) * { ( B , C , D ) ; ( A , C) }

Q2 : R est-elle en 5 FN (justifiez votre réponse) ?


Q3 : Si R nécessite une décomposition , Proposez-en une en précisant pour chaque relation obtenue
sa forme normale , sa clé et les D.F. qui lui sont associées? Votre décomposition préserve-t-elle
la jointure et/ou les D.F. ?

Exercice 27 :

Soit la relation R (NUMEMP, NOMEMP, ATELIER , MACHINE, TYPE ) modélisant la répartition des
employés dans des ateliers contenant des machines. Les seules D.F. vérifiées par cette relation sont :
F={NUMEMP → NOMEMP ; MACHINE → TYPE , ATELIER }

On suppose pour la suite de l’exercice qu’on a au total 100 employés à repartir sur 50 Ateliers et que
chaque Employé peut travailler dans 10 Ateliers au plus et qu'un Atelier peut contenir 50 Machines au
maximum. Une extension de cette relation est la suivante :

NUMEMP NOMEMP ATELIER MACHINE TYPE


1 E1 AT1 M1 SOUDEUSE
1 E1 AT1 M2 TARAUDEUSE
1 E1 AT1 M5 PERCEUSE
2 E2 AT1 M1 SOUDEUSE
2 E2 AT1 M2 TARAUDEUSE
2 E2 AT1 M5 PERCEUSE
2 E2 AT2 M3 TOUR
2 E2 AT2 M4 FRAISEUSE
3 E3 AT2 M3 TOUR
3 E3 AT2 M4 FRAISEUSE

Q1 : Les dépendance de jointure suivantes sont elles vérifiées par R :

a) * { (MACHINE, TYPE, ATELIER) ; (NUMEMP, NOMEMP) ; (NUMEMP , MACHINE) }


b) * { (MACHINE , TYPE, ATELIER ) ; (NUMEMP , NOMEMP) ; (NUMEMP , ATELIER) }
c) * { (ATELIER , MACHINE ,TYPE ) ; (NUMEMP , NOMEMP , ATELIER ) }

Q2 : Si vous aviez à choisir pour R une décomposition parmi les trois suivantes

1) R1(MACHINE , TYPE , ATELIER)


R2(NUMEMP, NOMEMP)
R3(NUMEMP , MACHINE) }

2) S1(MACHINE , ATELIER , TYPE)


S2(NUMEMP , NOMEMP)
S3(NUMEMP , ATELIER) }

3) T1(ATELIER , TYPE , MACHINE )

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 3: Le modèle relationnel •154

T2(NUMEMP , NOMEMP , ATELIER ) }

Laquelle choisiriez-vous dans le cas de chacun des critères suivants :

a)- On choisit de préférence une décomposition dans laquelle toutes les relations sont au moins
en 3FN
b)- On choisit une décomposition dont les relations occupent un espace minimum même s’il
existe parmi elles certaines qui ne sont pas au moins en 3FN

Q3 : - Est-ce que l’une des deux dépendances Multivaluées suivantes est vérifiée par R ?

- ATELIER →→ NUMEMP , NOMEMP


- ATELIER →→ MACHINE , TYPE

Exercice 28 :

Soit la relation R ( X , Y , Z ) avec l’extension suivante :

X Y Z
x1 y1 z1
x2 y1 z2
x2 y2 z2
x1 y1 z3
x3 y1 z3
x3 y1 z1

Q1: Trouvez une clé pour R et dire dans quelle forme normale elle est
Q2: Quelles sont les anomalies que présente cette relation
Q3: Donnez la liste de toutes les dépendances multivaluées vérifiées par R
Q4: R est-elle en 4FN ? Dans le cas contraire proposez une décomposition en 4 FN de R en
précisant pour chaque relation obtenue sa clé et les dépendances (fonctionnelles ou
multivaluées) qu’elle vérifie.

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’Ingénieur - Université de Batna - Algérie
Chapitre 4: Introduction à l'algèbre relationnelle •155

Chapitre 4 : Introduction à l'algèbre relationnelle

1 Les langages de manipulation de données relationnelles

Un Langage de Manipulation de Données (LMD) se compose d'un ensemble de commandes


permettant d'interroger une BD et d'un ensemble de commandes permettant de la modifier (insertion,
suppression, mise a jour, etc.). Un LMD doit être incorporable dans un langage de programmation
classique afin de permettre au programmeur de réaliser des transactions depuis son programme. En
général, la plupart des SGBD propose a l'utilisateur un LMD avec une interface conversationnelle et
aussi une possibilité d'intégration de ce LMD dans un langage hôte. Contrairement aux SGBD réseaux
et hiérarchiques, le LMD disponible avec un SGBD relationnel (langage d'interrogation) est un
langage de type assertionnel (non procédural). Il permet de définir les données auxquelles on veut
accéder sans dire comment ni par quel chemin les accéder.

On distingue trois grandes classes de langages :

z Les langages algébriques : basés sur l'algèbre relationnelle de CODD et dont le


langage SQL (Structured Query Language) est le plus représentatif.

z Les langages basés sur le calcul relationnel de tuples qui sont construits à partir de
la logique des prédicats en faisant varier les variables sur les tuples des relations. Le
langage QUEL (QUEry Language) disponible sur le SGBD INGRES est le plus
représentatif.

z Les langages basés sur le calcul relationnel de domaines: qui sont aussi construits à
partir de la logique des prédicats mais en faisant varier les variables sur les
domaines des relations. Le langage QBE (Query By Example) développé par IBM
pour son SGBD DB2 est le plus représentatif de cette catégorie.

Aujourd'hui le langage SQL est devenu le langage de référence dans le domaine des bases de
données relationnelles. Nous estimons donc très utile de familiariser d’abord le lecteur avec les
fondements théoriques de l’algèbre relationnelle avant de présenter le langage.

2. L’algèbre relationnelle

On peut dire que l'algèbre relationnelle est le domaine des relations muni d'un ensemble
d'opérateurs. Elle possède un ensemble d'opérateurs de base et d'opérateurs complémentaires qui ne
modifie pas l'algèbre car ils s'expriment en fonction des opérateurs de base.

2.1 Les opérations de base

Les opérations de base sont de deux sortes. On a d'une part les opérations binaires ensemblistes et
d'autre part les opérations unaires spécifiques.

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Université de Batna - 05000 - Algérie
Chapitre 4: Introduction à l'algèbre relationnelle •156

2.1.1 Opérations binaires ensemblistes

2.1.1.1 L'union de deux relations

L'union de deux relations R et S ayant même arité (même nombre de colonnes) est la relation notée
R ∪ S (ou UNION(R,S) ) constituée de l'ensemble des tuples appartenant a R ou à S ou au deux.

2.1.1.2 Remarques

Il est courant d'imposer que les relations R et S aient le même schéma (c.a.d. les mêmes attributs)
qui sera dans ce cas le schéma de la relation résultat. En effet, si les deux relations n'ont pas la même
sémantique l'union des deux n'a sans doute pas de sens même si elle peut être calculée.

Exemple : soient les relations R et S suivantes :

Figure 4.1 : Union entre deux relations

L'union de ces deux relations donnera une nouvelle relation ayant le même schéma que R et S (car
R et S ont le schéma) et pour extension :

Figure 4.2 : Relation résultant de l’union entre deux relations

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Université de Batna - 05000 - Algérie
Chapitre 4: Introduction à l'algèbre relationnelle •157

2.1.1.3 Différence entre deux relations

La différence entre deux relations R et S ayant même arité (même nombre de colonnes) est la
relation notée R - S (ou MINUS(R,S) ) constituée de l'ensemble des tuples appartenant à R et
n'appartenant pas à S.

2.1.1.4 Remarques

Comme pour l'union, il est courant d'imposer que les relations R et S aient le même schéma (c.a.d.
les mêmes attributs) qui sera dans ce cas le schéma de la relation résultat.

Exemple: si on considère les mêmes relations R et S utilisées dans l'exemple de l'union,


on aura :

Figure 4.3 : Différence entre deux relations

En effet les tuples (a1,b1,c1) et (a2,b2,c2) appartiennent à R mais aussi à S. Donc ils ne doivent pas
figurer dans la relation résultat R - S.

2.1.1.5 Produit Cartésien de deux relations

Le produit cartésien de deux relations R et S de schémas quelconques est une relation notée R x S
(ou PRODUCT(R,S) ) ayant pour attributs la concaténation des attributs de R et de S et pour tuples
tous les tuples obtenus par concaténation d'un tuple de R a un tuple de S.

2.1.1.6 Remarques

Le calcul du produit cartésien impose que les attributs de R et de S n'aient pas de nom commun
même s'ils ont le même domaine.

Exemple :

Le produit cartésien des relations R et S utilisées dans l'exemple de l'union ne peut se faire

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Université de Batna - 05000 - Algérie
Chapitre 4: Introduction à l'algèbre relationnelle •158

que si on donne aux attributs de S (A,B et C) des noms qui seront distincts de ceux de R (car
R a aussi des attributs ayant les mêmes noms A, B et C). Si on renomme dans S la colonne A
par D, la colonne B par E et la colonne C par F, on aura :

Figure 4.4 : Produit cartésien de deux relations

Le résultat sera une nouvelle relation ayant pour schéma et pour extension :

Figure 4.5 : Résultat du produit cartésien de deux relations

Si le nombre de tuples de R est r et le nombre de tuples de S est s alors la relation R x S contiendra


r*s tuples (dans l'exemple R x S contient 12 tuples puisque R contient 3 tuples et S en contient 4).

2.1.2 OPERATIONS UNAIRES SPECIFIQUES

Il existe deux opérations unaires appelées PROJECTION et SELECTION (ou RESTRICTION).


Ces opérations peuvent être vues comme l'élimination de colonnes (PROJECTION) ou de lignes
(SELECTION) dans une relation. La combinaison de ces deux opérations avec les opérations binaires
permet de générer toutes les opérations de l'algèbre relationnelle.

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Université de Batna - 05000 - Algérie
Chapitre 4: Introduction à l'algèbre relationnelle •159

2.1.2.1 La Projection

La projection d'une relation R ayant pour schéma R(A1,A2,....An) sur les attributs Ai1,Ai2,....Aip
(ou ij sont des entiers tels que 1≤ ij ≤ n et ij ≠ ik) est une relation R' de schéma R'(Ai1,Ai2,....Aip)
notée PROJECT Ai1,Ai2,....Aip (R) ou Π
Ai1,Ai2,....Aip (R) dont les tuples sont obtenus par
élimination des valeurs des attributs de R n'appartenant pas a R' (c.a.d. à Ai1,Ai2,....Aip ) et par
suppression des tuples en double de la relation résultat (c.a.d. de R').

Exemple :

Si on considère la relations R utilisée dans les exemples précédents, la relation :


R' = Π A , C (R) aura pour schéma R'(A,C) et pour extension :

R' = Π A , C (R)

Figure 4.6 : Projection d’une relation

On a éliminé les valeurs des attributs B (colonne B de la relation R) car l'attribut B n'appartient pas
a R'.

2.1.2.2 La Sélection (appelée aussi Restriction)

L'idée de l'opération de sélection est de conserver les seuls tuples d'une relation qui vérifient une
condition donnée sur leurs attributs. La sélection dans une relation R selon une condition c est une
relation R' de même schéma que R notée σ
c (ou SELECT c (R) ) et dont les tuples sont ceux de R
qui satisfont la condition c. La condition c est une expression faisant intervenir :

• des opérandes (constantes ou des noms d'attributs)


• des opérateurs arithmétiques de comparaison ( ≤ , ≠ , < , = , > , ≥ )
• des opérateurs logiques (ET,OU,NON)

Exemple : Soit la relation PRODUIT(NOM_PRODUIT,PRIX,QTE) avec l’extension suivante :

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Université de Batna - 05000 - Algérie
Chapitre 4: Introduction à l'algèbre relationnelle •160

Figure 4.7 : Extension de la relation Produit

La sélection dans la relation PRODUIT selon la condition suivante :

c : "PRIX ≤ 500 ET QTE ≥ 20"


est la relation R'= SELECT "prix ≤ 500 ET qte ≥ 20" (R) ayant même schéma que R et dont
l'extension est la suivante :

Figure 4.8 : Sélection dans une relation

2.1.2.3 Remarque

Si on avait utilisé la condition c : "prix < 10 ET qte ≥ 20" comme condition de sélection, le
résultat serait une relation vide (ne contenant aucun tuple) car aucun tuple de la relation PRODUIT ne
vérifie cette condition.

2.2 Les opérations complémentaires

Les opérations qui viennent d'être présentées forment un ensemble cohérent et minimal. Cependant,
il est courant dans un LMD de leur ajouter d'autres opérations qui ne modifient pas l'algèbre
puisqu’elles sont exprimées en fonction de ces opérations de base. Bien que les opérations
complémentaires sont redondantes (on peut les obtenir a partir des opérations de base), elles sont
essentielles pour la réalisation pratique d'un SGBD relationnel. En effet, une opération de base tel que
le produit cartésien est très coûteuse en temps machine et en espace et on préfère réaliser une autre
opération similaire mais plus restrictive qu'on appelle la jointure.

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Université de Batna - 05000 - Algérie
Chapitre 4: Introduction à l'algèbre relationnelle •161

2.2.1 La JOINTURE

2.2.1.1 La JOINTURE selon une qualification

La jointure de deux relations R et S selon une condition (ou une qualification) c comparant des
attributs de R à ceux de S est la relation notée :

R S
C

ou JOIN c (R,S) ) de schéma égal a l'union des schémas de R et de S et contenant l'ensemble des
tuples du produit cartésien R x S satisfaisant la qualification c.
La forme la plus courante de la qualification c est : A θ B ou A est un attribut de R et B un attribut
de S et θ un opérateur de comparaison ( ≤ , ≠ , < , = , > , ≥ ). On peut remarquer d'après la définition
de la jointure qu'on a : JOIN c (R,S) = SELECT c (R x S)

Donc la jointure s'obtient en appliquant une opération de sélection selon la condition c à la relation
résultant du produit cartésien R x S.

Exemple : soient les deux relations R et S suivantes :

Figure 4.9 : Jointure entre deux relations selon une condition

La jointure de R et de S selon la condition c : " C ≤ D" est la relation R' de schéma


R'(A,B,C,D,E) et contenant les tuples suivants :

Figure 4.10 : Résultat d’une jointure entre deux relations

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Université de Batna - 05000 - Algérie
Chapitre 4: Introduction à l'algèbre relationnelle •162

2.2.1.2 Remarques

Dans le cas ou l'opérateur θ est l'opérateur d'égalité (=) la jointure s'appelle une
EQUIJOINTURE.

2.2.1.3 JOINTURE Naturelle

La jointure naturelle de deux relations R et S dont les schémas ne sont pas disjoints (R et S ont des
attributs de même noms) est une relation notée JOIN (R,S) de schéma égal a l'union des schémas de R
et de S et contenant tous les tuples obtenus par EQUIJOINTURE de R et de S sur tous les attributs
ayant le même nom dans R et S suivie d'une PROJECTION qui permet de conserver un seul de ces
attributs égaux de même nom.

En supposant que A1,A2,......Ak sont les noms d'attributs apparaissant dans les deux relations R et
S, la condition c qui sera utilisée dans l'équijointure sera de la forme R.A1=S.A1 /\ R.A2=S.A2 /\......
/\ R.Ak=S.Ak

On peut noter que JOIN (R,S) = PROJECT v (SELECT c (RxS) ) ou v est égal l'union des
attributs de R et des attributs de S n'appartenant pas à R.

Exemple : soient les deux relations R et S suivantes :

Figure 4.11 : Jointure naturelle entre deux relations

La jointure naturelle de R et S sera une relation R' ayant pour schéma :

R' [(A,B,C) ∪ (B,C,D)] c.a.d. R'(A,B,C,D)

Les attributs de même noms dans R et S sont B et C. Donc la condition c pour réaliser
l'equijointure sera : R.B = S.B /\ R.C = S.C . Le résultat de la jointure naturelle de R et S ( JOIN
(R,S) ) sera donc :

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Université de Batna - 05000 - Algérie
Chapitre 4: Introduction à l'algèbre relationnelle •163

Figure 4.12 : Résultat de la jointure naturelle entre deux relations

2.2.1.4 Remarque

Nous avons exprès sauté les étapes intermédiaires du calcul du résultat final. Normalement, les
étapes intermédiaires du calcul sont :

1) Calcul de la relation R1 = R x S
2) Calcul de la relation R2 = SELECT c (R1) avec la condition c indiquée plus haut

(R.B = S.B /\ R.C = S.C)


3) Calcul de la relation R3 = Π A , B, C, D (R2) qui sera le résultat final.
Donc : JOIN (R,S) = Π A , B, C, D (SELECT c (R x S))

2.2.1.5 La Semi Jointure

C'est une opération dérivée de la jointure. Il s'agit en fait, une fois la jointure réalisée entre deux
relations R et S, de projeter la relation obtenue sur les attributs de la relation R. Formellement, la
SEMI-JOINTURE de la relation R par la relation S selon une condition c est une relation de même
schéma que R et contenant l'ensemble des tuples de R participant à la jointure de R et de S selon la
condition c.

Exemple : Soient les deux relations R et S suivantes :

Figure 4.13 : Semi Jointure entre deux relations

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Université de Batna - 05000 - Algérie
Chapitre 4: Introduction à l'algèbre relationnelle •164

La semi-jointure de R et S selon la condition c : "C ≤ D" s'obtient en faisant :

1) une jointure de R et S selon la condition c


2) une projection de la relation résultant de cette jointure sur les attributs
(A,B,C) qui sont les attributs de R

On aura donc : R' = JOIN "C ≤ D" (R,S) aura pour extension :

Figure 4.14 : Relations R' = JOIN "C ≤ D" (R,S)

puis R" = Π A,B,C (R') aura pour extension :

Figure 4.15 : Relation Π A,B,C (JOIN "C ≤ D" (R,S))

On a donc éliminé après projection le tuple (1, 2, 3) qui est un tuple en double.

2.2.1.6 Remarques

L’intérêt essentiel de la semi-jointure est lié à l'optimisation des requêtes relationnelles car dans ce
cas la jointure proprement dite ne doit pas être évaluée complètement puisqu'on sait qu'on ne retiendra
que les tuples provenant de R.

2.2.2 L'intersection entre deux relations

2.2.2.1 Définition

L'intersection de deux relations R et S de même schéma est une relation de même schéma notée :
R ∩ S (ou INTERSECT(R,S) ) contenant les tuples qui appartiennent à R et à S en même temps.

Exemple : Soient les deux relations R(A,B,C) et S(A,B,C) suivantes :

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Université de Batna - 05000 - Algérie
Chapitre 4: Introduction à l'algèbre relationnelle •165

Figure 4.16 : Intersection entre deux relations

L'intersection des deux relations R et S donnera comme résultat une nouvelle relation de même
schéma que R et S et ayant pour extension (contenant les tuples) :

Figure 4.17 : Relation résultant de l’intersection entre deux relations

2.2.2.2 Remarques

L'opération INTERSECTION peut s'obtenir a partir de l'opération de base DIFFERENCE à l'aide


de l'une des deux formules suivantes :

a) R ∩ S = R - (R - S )

b) R ∩ S = S - (S - R )

En effet si on pose R = R+s ∪ R-s où R+s représente l’ensemble des tuples de R appartenant
aussi à S et R-s représente l’ensemble des tuples de R n'appartenant pas à S.

et si on pose S = S+r ∪ S-r où S+r représente l’ensemble des tuples de S appartenant aussi à R et
S-r représente l’ensemble des tuples de S n'appartenant pas à R.

Les deux ensembles S+r et R+s sont égaux (S+r = R+s). Par définition de l'opération
DIFFERENCE on a aussi :

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Université de Batna - 05000 - Algérie
Chapitre 4: Introduction à l'algèbre relationnelle •166

R - S = R-s
et S - R = S-r

On peut alors écrire d'après a) que :

R ∩ S = R+s ∪ R-s - ( R-s ) = R+s

et d'après b) que :
R ∩ S = S+r ∪ S-r - ( S-r ) = S+r

Ceci montre bien que le résultat est l'ensemble des tuples appartenant à R et à S (R+s ou S+r qui
sont égaux) telle que l'énonçait la définition de l'opération INTERSECTION.

2.2.3 QUOTIENT (DIVISION)

2.2.3.1 Définition

Le quotient d'une relation R de schéma R(A1,A2,....An) par une relation S de schéma


S(Ap+1,Ap+2,....An) est une relation Q notée R % S (ou DIVISION(R,S)) de schéma
Q(A1,A2,....Ap) contenant tous les p_tuples de R qui concaténés à chacun des tuples de S donnent
toujours un tuple de R.

La division de deux relations n'est donc définie que lorsque la seconde relation S est un sous-
schéma de la première R.

Exemple : soient les relations R(A,B,C,D) et S(C,D) suivantes :

La relation Q = R % S aura pour schéma Q(A,B) (les attributs de R moins les attributs de S). Elles
contiendra les sous-tuples de R suivants :

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Université de Batna - 05000 - Algérie
Chapitre 4: Introduction à l'algèbre relationnelle •167

Figure 4.18 : Division d’une relation par une autre

En effet la concaténation du sous-tuple (a1, b1) avec les tuples de S donne les deux tuples suivants
: (a1, b1, c1, d1) et (a1,b1, c2, d2) qui appartiennent bien a R

De même la concaténation du sous-tuple (a3, b3) avec les tuples de S donne les deux tuples
suivants :
(a3, b3, c1, d1) et (a3, b3, c2, d2) qui appartiennent aussi a R

Par contre le sous-tuple (a2, b2) n'appartient pas au quotient de R par S car sa concaténation avec
les tuples de S donne les deux tuples suivants :

(a2, b2, c1, d1) qui appartient à R , et (a2, b2, c2, d2) qui n'appartient pas à R

ce qui contredit la définition du quotient qui énonce que : TOUS LES TUPLES OBTENUS PAR
CONCATENATION DOIVENT APPARTENIR A R ce qui n'est pas le cas pour (a2, b2).

2.2.3.2 Autre définition du QUOTIENT

Le quotient d'une relation R de schéma R(A1, A2, ....An) par une relation S de schéma S(Ap+1,
Ap+2, ....An) est une relation Q notée R % S de schéma Q(A1, A2, ....Ap) et telle que :

Q = { (a1,a2,...ap) appartenant à R / ∀ (ap+1,ap+2,...an) ∈ à S , on a


(a1,a2,...ap,ap+1,ap+2,...an) ∈ à R) }

2.2.3.3 Remarques

1) Le quotient étant une opération complémentaire, il peut s'exprimer à partir des opérations
de DIFFERENCE, PRODUIT CARTESIEN et de PROJECTION.

Si on pose v=(A1, A2, ....Ap) (l'ensemble des attributs de Q), on peut vérifier que :

Q = R % S = PROJECT v (R) - PROJECT v ( (PROJECT v (R) x S) - R)

2) On n'a pas : (R % S) x S = R mais simplement (R % S) x S ⊂ R

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Université de Batna - 05000 - Algérie
Chapitre 4: Introduction à l'algèbre relationnelle •168

3 Propriétés des opérateurs algébriques

Les opérations algébriques ont des propriétés entre elles qui permettent de transformer les
expressions en changeant l'ordre d'évaluation de ces opérations afin d'obtenir des expressions
équivalentes mais plus efficaces en termes de temps d'évaluation et d'espace mémoire requis pour cette
évaluation. Ces propriétés vont servir essentiellement à résoudre le problème d'optimisation de requête
qui constitue une des tâches les plus importante de tout SGBD.

3.1 Commutativité et associativité de la jointure et du produit cartésien

R1 x R2 = R2 x R1
R1 x (R2 x R3) = (R1 x R2) x R3
JOIN (R1 , R2) = JOIN (R2 , R1)
JOIN (R1 , JOIN (R2 , R3)) = JOIN (JOIN (R1 , R2) , R3)

3.2 Remplacement d’une cascade de projections

Si x est inclus dans y alors on a : Π x (Π y (R)) = Π x (R)

3.3 Remplacement d'une cascade de sélections

Si on considère le cas d'une sélection simple mono-attribut avec θ un opérateur de comparaison {


< , ≤ , >, ≥, = , ≠ , } , on a :

σ "B θ d" (σ "A θ c" (R)) = σ "B θ d /\ A θ c" (R)

Ce résultat peut être généralisé à plusieurs attributs.

3.4 Commutation d'une SELECTION et d'une PROJECTION

Dans le cas ou l'attribut B est inclus dans Y (un ensemble d'attributs), on a :

σ "B θ c" ( Π Y (R)) = Π Y ( σ "B θ c" (R))


Si B n'est pas inclus dans Y, alors :

Π Y ( σ "B θ c" (R)) = Π Y ( σ "B θ c" ( Π Y ∪ B (R)))


3.5 Commutation d'une SELECTION et d'une UNION

σ "A θ c" (R1 ∪ R2) = σ "A θ c" (R1) ∪ σ "A θ c" (R2)
3.6 Commutation d'une SELECTION et d'une DIFFERENCE

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Université de Batna - 05000 - Algérie
Chapitre 4: Introduction à l'algèbre relationnelle •169

σ "A θ c" -
(R1 R2) = σ "A θ c" (R1) - σ "A θ c" (R2)

3.7 Commutation d'une SELECTION et d'un PRODUIT CARTESIEN

Soient deux relations R1(X) et R2(Y) :

• Si le critère de sélection est de la forme "A θ c" avec A ∈ X. On aura :

σ "A θ c" (R1 x R2) = ( σ "A θ c" (R1)) x R2

• Si le critère de sélection est de la forme "A θ c" /\ "B θ d" avec A ∈ X et B ∈ Y. On


aura :
σ "A θ c" /\ "B θ d" (R1 x R2) = (σ"A θ c" (R1)) x σ
( "B θ d" (R2))

3.8 commutation d'une PROJECTION et d'un PRODUIT CARTESIEN

Soient deux relations R1(X) et R2(Y) et A , B et C des ensembles d'attributs tel que :

A = B ∪ C avec B ∈ X et C ∈ Y . On a alors :

Π A (R1 x R2) = Π B (R1) x Π C (R2)

3.9 Commutation d'une PROJECTION avec une UNION

Soient deux relations R1(X) et R2(Y) et A , B et C des ensembles d'attributs tel que :

A = B ∪ C avec B ∈ X et C ∈ Y . On a alors :

Π A (R1 ∪ R2) = Π B (R1) ∪ Π C (R2)

3.10 Remarques

• Les propriétés P2 et P3 ont pour intérêt essentiel de regrouper des opérations


(SELECTION ou PROJECTION) en une seule opération.

• Les propriétés P4 , P5 , P6 et P7 montrent qu'on peut faire passer une SELECTION avant
une PROJECTION , une UNION, une DIFFERENCE ou un PRODUIT CARTESIEN.
L'intérêt d'une telle transformation est d'appliquer la SELECTION le plus tôt possible afin
de minimiser le nombre de tuples des relations auxquelles seront appliquées les autres
opérations (UNION, PRODUIT CARTESIEN, DIFFERENCE, PROJECTION)

• Les propriétés P8 et P9 montrent qu'on peut faire passer une PROJECTION avant une
UNION ou un PRODUIT CARTESIEN . L'intérêt d'une telle transformation est d'appliquer
la PROJECTION le plus tôt possible afin de minimiser le nombre de colonnes des relations
auxquelles seront appliquées l'UNION ou le PRODUIT CARTESIEN.

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Université de Batna - 05000 - Algérie
Chapitre 4: Introduction à l'algèbre relationnelle •170

4 Expressions de l’algèbre relationnelle

Les opérations algébriques peuvent être combinées pour former des expressions de l’algèbre
relationnelle. Il sera donc possible de composer la plupart des questions que l'on peut poser à une base
de données relationnelle. Ainsi, ces questions peuvent être exprimées à l'aide de successions des
opérations UNION , DIFFERENCE, JOINTURE, SELECTION, PROJECTION. La représentation
graphique de ces opérations permet de composer des arbres d'opérations relationnelles.

Exemple : soit la base de données composée des relations suivantes :

R1(MEDECIN , MALADIE , TARIF)


R2(NUMERO , MALADE , MALADIE)

La relation R1 représente les maladies qui peuvent être examinées par un médecin et le tarif de la
consultation chez ce médecin pour chaque maladie. La relation R2 représente les maladies pour
lesquelles un malade souhaite être examiné. Des exemples d'extensions de ces deux relations sont :

Figure 4.19 : Extensions des relations R1 et R2

La réponse à la question suivante : "Quels sont les noms des médecins pouvant examiner le malade
"RABAH" et les prix de leurs consultations ainsi que les maladies à examiner " peut être exprimée à
l'aide de l'un des deux arbres suivants :

(a)
(b)
Figure 4.20 : Représentation des expressions algébriques par un arbre

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Université de Batna - 05000 - Algérie
Chapitre 4: Introduction à l'algèbre relationnelle •171

et où la condition C1 est : Malade = ‘‘Rabah’’

Un arbre d'opérations s'interprète de bas en haut. Les expressions algébriques correspondant à


chacun des deux arbres précédents sont respectivement :

a) PROJECT médecin, maladie, tarif ( SELECT malade = ''RABAH'' ( JOIN (R1, R2)))
b) PROJECT médecin, maladie, tarif ( JOIN (SELECT malade = ''RABAH'' (R2), R1))

On passe de a) à b) en utilisant la propriété P7 car une JOINTURE n'est qu'un cas particulier du
PRODUIT CARTESIEN. De ce fait b) est plus efficace que a) puisque on applique d'abord le
SELECT sur R2 qui donnera une relation intermédiaire contenant uniquement les tuples relatifs au
malade "RABAH" (c.a.d. 2) et qu'on utilisera pour calculer le JOIN avec R1.

5 Conclusion

Nous venons de voir que la réponse à une même question peut s’obtenir de différentes façons.
C’est à dire que différentes stratégies d’exécution d’une requête peuvent donner la réponse à la
question. Néanmoins, parmi ces stratégies, certaines sont plus performantes que d’autres en terme de
temps d’exécution et d’espace mémoire requis. Heureusement, les SGBD relationnels intègrent tous
un module d’optimisation des requêtes permettant de choisir parmi plusieurs stratégies possibles
d’exécution d’une requête, celle qui est la plus performante. Cette optimisation est basée
principalement sur l’application des propriétés des opérateurs de l’algèbre relationnelles.

Parmi les langages basés sur l'algèbre relationnelle, le langage SQL est le plus représentatif. C'est
le langage de description et de manipulation d’une base de données relationnelle le plus diffusé
actuellement. Le prochain chapitre sera réservé à une présentation générale de SQL. Il s’agira surtout
de voir comment exprimer les opérations que nous avons présentées grâce au LMD supporté par SQL
et la manière dont elles peuvent être combinées pour formuler une requête quelconque.

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Université de Batna - 05000 - Algérie
Chapitre 4: Introduction à l'algèbre relationnelle •172

Exercices sur le Chapitre 4

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Université de Batna - 05000 - Algérie
Chapitre 4: Introduction à l'algèbre relationnelle •173

Exercice 1:

Soit les deux relations :

R1(MODULE, INSTITUT)
R2(MODULE, INSTITUT)

Sachant que R1 représente les modules enseignés par le professeur ALI et pour chaque module,
l’institut dans lequel ALI enseigne ce module. R2 représente les modules enseignés par le professeur
OMAR et pour chaque module, l’institut dans lequel OMAR enseigne ce module. Soient les deux
extensions suivantes de R1 et R2 :

MODULE INSTITUT MODULE INSTITUT

Tec710 Informatique Tec712 Informatique


Sem200 Informatique Tec800 Informatique
Tat300 Mécanique sem200 Maths
Tec628 Mécanique sem400 Maths
sem500 Mécanique

Relation R1 Relation R2

On suppose que les professeurs ALI et OMAR peuvent enseigner les mêmes modules et qu’un
même module peut être dispensé dans plusieurs instituts.

Q1: CALCULER R1 U R2.


Q2: QUE REPRESENTENT LES TUPLES DE LA RELATION R1 U R2 ?
Q3: CALCULER R1 - R2 ET R2 - R1.
Q4: QUE REPRESENTENT LES TUPLES DE LA RELATION R1 - R2 ? MEME QUESTION AVEC LES
TUPLES DE R2 - R1 ?

Q5: DONNER LE SCHEMA ET L’EXTENSION DE LA RELATION R’ = σInstitut = ″ Informatique ″ (R1)


? MEME QUESTION AVEC LA RELATION R’’ = σInstitut = ″ Maths ″ (R2) ?.
Q6: QUE REPRESENTENT LES TUPLES DE LA RELATION R’ ? MEME QUESTION AVEC LES
TUPLES DE R’’ ?
Q7: DONNER LE SCHEMA ET L’EXTENSION DES DEUX RELATIONS SUIVANTES :

R3 = Π Module (σInstitut = ″ Informatique ″ (R1) )


R4 = Π Module (σInstitut = ″ Informatique ″ (R2) )
Q8: QUE REPRESENTENT LES TUPLES DE LA RELATION R3 ? MEME QUESTION AVEC LES
TUPLES DE R4 ?

Q9: DONNER LE SCHEMA ET L’EXTENSION DE LA RELATION R3 ∩ R4 . QUE


REPRESENTENT LES TUPLES DE CETTE RELATION ?

Q10: DONNER LE SCHEMA ET L’EXTENSION DE LA RELATION : R1 R2


QUE REPRESENTENT LES TUPLES DE CETTE RELATION?

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Université de Batna - 05000 - Algérie
Chapitre 4: Introduction à l'algèbre relationnelle •174

Exercice 2:

Soit les deux relations :

R1(MODULE , INSTITUT)
R2(MODULE, PROF)

ou R1 représente la liste des Modules dispensés dans chaque institut et R2 represente la


liste des modules que peut enseigner chaque professeur .

MODULE INSTITUT MODULE PROF


Tec710 Informatique Tec710 ALI
Tec712 Informatique Sem200 ALI
Tec800 Informatique Tec628 ALI
Tec628 Mécanique Tec712 ALI
Tec628 Informatique Sem200 OMAR
Sem200 Informatique Tec712 OMAR
Sem200 Maths Tec628 OMAR
sem400 Maths Sem400 AHMED
sem500 Mécanique Sem500 AHMED
Tat300 Mécanique Sem500 ALI
Tat300 ALI
relation R1 Sem400 ALI
Tec800 ALI
Tat300 HAKIM

relation R2

Q1 : ¾ DONNER LE SCHEMA ET L’EXTENSION DE LA RELATION : Π PROF (R1 R2)


¾ QUE REPRESENTENT LES TUPLES DE CETTE RELATION?

Q2 : ¾ DONNER LE SCHEMA ET L’EXTENSION DE LA RELATION :

R2 - (Π PROF, MODULE (R1 R2))

¾ QUE REPRESENTENT LES TUPLES DE CETTE RELATION? FORMULEZ SOUS FORME DE


PHRASE UNE QUESTION DONT LA REPONSE SERAIT L’ENSEMBLE DES TUPLES DE
CETTE RELATION ?

Q3 : ¾ DONNER LE SCHEMA ET L’EXTENSION DE LA RELATION :

R1 - (Π INSTITUT, MODULE (R1 R2))

¾ QUE REPRESENTENT LES TUPLES DE CETTE RELATION? FORMULEZ SOUS FORME DE


PHRASE UNE QUESTION DONT LA REPONSE SERAIT L’ENSEMBLE DES TUPLES DE
CETTE RELATION ?

Q4 : ¾ DONNER LE SCHEMA ET L’EXTENSION DES RELATIONS :

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Université de Batna - 05000 - Algérie
Chapitre 4: Introduction à l'algèbre relationnelle •175

R31 = σ MODULE = ″ Sem200 ″ (Π MODULE (R1) )


R32 = Π MODULE (σMODULE = ″ Sem200 ″ (R1) )
¾ LES RELATIONS R31 et R32 ONT-ELLES LE MEME SCHEMA ? ONT-ELLES LA MEME
EXTENSION ? DANS L’AFFIRMATIVE, QUELLE EST LA RELATION QUE VOUS
RETIENDRIEZ ET POURQUOI ?

Q5 : ¾ DONNER LE SCHEMA ET L’EXTENSION DES RELATIONS :

R41 = Π MODULE (σ PROF = ″ ALI ″ (R2 R1 ))

R42 = Π MODULE (σ PROF = ″ ALI ″ (R2) ) (R1)


¾ LES RELATIONS R41 et R42 ONT-ELLES LE MEME SCHEMA ? ONT-ELLES LA MEME
EXTENSION ? DANS L’AFFIRMATIVE, QUELLE EST LA RELATION QUE VOUS
RETIENDREZ ET POURQUOI ? QUE REPRESENTENT LES TUPLES DE CES RELATIONS?
FORMULEZ SOUS FORME DE PHRASE UNE QUESTION DONT LA REPONSE SERAIT
L’ENSEMBLE DES TUPLES DE L’UNE DE CES RELATION ?

Q6 : ¾ DONNER LE SCHEMA ET L’EXTENSION DES RELATIONS :

R5 = (σ INSTITUT = ″ Informatique ″ (R1) ) R2 )


R6 = Π PROF (R2) - Π PROF (R5)
R7 = Π PROF (R5) - Π PROF (R2)
R8 = Π PROF (R2) ∩ Π PROF (R5)

¾ QUE REPRESENTENT LES TUPLES DE CHACUNE DES RELATIONS CI-DESSUS?


FORMULEZ SOUS FORME DE PHRASE UNE QUESTION DONT LA REPONSE SERAIT
L’ENSEMBLE DES TUPLES DE CHACUNE DE CES RELATION ?

Q7 : ¾ DONNER LE SCHEMA ET L’EXTENSION DES RELATIONS SUIVANTES :

a) R1 - R2
b) R2 - R1
c) R1 ∪ R2
d) R1 ∩ R2

Exercice 3:

Soit les deux relations :

CATALOGUE (CODE_PRODUIT, NOM_PRODUIT, PRIX_UNITE)


COMMANDE (DATE, CODE_PRODUIT,NOM_PRODUIT, QUANTITE)

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Université de Batna - 05000 - Algérie
Chapitre 4: Introduction à l'algèbre relationnelle •176

La relation CATALOGUE représente pour la liste des produits fournis par tous les fournisseurs. La
relation COMMANDE représente les commandes passées par une société X avec leurs dates, les
produits commandés et leurs quantités. Soient les extensions suivantes de ces relations :

FOURNISSEUR CODE_PRODUIT NOM_PRODUIT PRIX_UNITE


TOTO P0130 ETAGERE 300
TOTO P0150 ARMOIRE 3200
TATA P0170 COMMODE 5500
TUTU P0130 ETAGERE 500
TUTU P0170 COMMODE 6000
TITI P0130 ETAGERE 500

Relation CATALOGUE

DATE CODE_PRODUIT NOM_PRODUIT QUANTITE


2/02 P0130 ETAGERE 10
28/02 P0150 ARMOIRE 5
3/03 P0130 ETAGERE 5
5/03 P0170 COMMODE 2
15/03 P0180 CHAISE 4
20/03 P0150 ARMOIRE 5

Relation COMMANDE

Q1 : ¾ CALCULER LA JOINTURE NATURELLE DES RELATIONS CATALOGUE ET


COMMANDES

Q2 : ¾ DONNER UNE EXPRESSION ALGEBRIQUE A BASE DE SELECTION, PRODUIT


CARTESIEN ET PROJECTION QUI SERAIT EQUIVALENTE A LA JOINTURE NATURELLE
DE LA QUESTION PRECEDENTE

Q3 : ¾QUE REPRESENTENT LES TUPLES DE LA RELATION RESULTANT DE CETTE JOINTURE


POUR LE FOURNISSEUR ?

Q4 : ¾QUE REPRESENTENT LES TUPLES DE LA RELATION RESULTANT DE CETTE JOINTURE


POUR LA SOCIETE X ?

Q5 : ¾ SOIENT LES DEUX CONDITIONS DE SELECTION SUIVANTES :

C1 : NOM_PRODUIT = ‘‘ETAGERE’’
C2 : PRIX_UNITE ≤ 400’’

• DONNER UNE EXPRESSION ALGEBRIQUE EQUIVALENTE A L’ARBRE ALGEBRIQUE CI-


DESSOUS.
• DONNER LE SCHEMA ET L’EXTENSION DE LA RELATION RESULTAT DE CETTE
EXPRESSION
• FORMULER SOUS FORME DE PHRASE LA QUESTION A LAQUELLE LES TUPLES DE
CETTE RELATION CONSTITUENT UNE REPONSE

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Université de Batna - 05000 - Algérie
Chapitre 4: Introduction à l'algèbre relationnelle •177

FOURNISSEUR

C2 C1

CATALOGUE COMMANDES

Q6 :
¾ DONNER UNE EXPRESSION ALGEBRIQUE EQUIVALENTE A L’ARBRE ALGEBRIQUE CI-
DESSOUS.
¾ DONNER LE SCHEMA ET L’EXTENSION DE LA RELATION RESULTAT DE CETTE
EXPRESSION.
¾ FORMULER SOUS FORME DE PHRASE LA QUESTION A LAQUELLE LES TUPLES DE
CETTE RELATION CONSTITUENT UNE REPONSE

CODE_PRODUIT CODE_PRODUIT

CATALOGUE

CATALOGUE COMMANDES

Exercice 4:

Reprenons les deux relation R1 et R2 avec leurs extensions données à l'exercice 2 :

R1(MODULE , INSTITUT)
R2(MODULE, PROF)

Q1 : ¾ CALCULER S = ΠMODULE (R1)

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Université de Batna - 05000 - Algérie
Chapitre 4: Introduction à l'algèbre relationnelle •178

Q3 : ¾ QUEL EST LE SCHEMA DE LA RELATION Q QUOTIENT DE R2 PAR S ?


Q4 : ¾ DONNER UNE EXTENSION DE LA RELATION Q
Q5 : ¾ CALCULER LA RELATION T RESULTAT DE L'EXPRESSION ALGEBRIQUE SUIVANTE :

ΠPROF (R2) - ΠPROF ( (ΠPROF (R2) x S) - R2)


Q6 : ¾ EST-CE QUE LES RELATIONS Q ET T ONT MEME EXTENSION ?
Q7 : ¾ A QUELLE QUESTION CORRESPONDRAIT LE RESULTAT DU QUOTIENT Q DE R2 PAR S

Exercice 5 :

Soit les relations :

FREQUENTE (CLIENT , CAFE)


SERT (CAFE , BOISSON)
AIME (CLIENT , BOISSON)

La relation FREQUENTE représente les cafés que fréquentent les clients. La relation SERT
représente les boissons que sert chaque café. La relation AIME représente les boissons qu’aime chaque
client. Soient les extensions suivantes de ces relations :

CLIENT CAFE CLIENT BOISSON


TOTO CHEZ ALI TOTO CAFE
TOTO PLAZA TOTO THE
TOTO L’AN 2000 TOTO ORANGINA
TUTU 4 SAISONS TUTU PEPSI
TUTU LA GARE TUTU TISANE
TATA DES AMIS TATA COCA

Relation FREQUENTE Relation AIME

CAFE BOISSON
CHEZ ALI THE
PLAZA ORANGINA
L’AN 2000 PEPSI
4 SAISONS TISANE
LA GARE CAFE
DES AMIS LAIT
CHEZ ALI LAIT
PLAZA TISANE
L’AN 2000 CAFE
4 SAISONS ORANGINA
CHEZ ALI PEPSI

Relation SERT

Q1 : ¾QUE REPRESENTENT LES TUPLES DE LA RELATION RESULTANT DE LA JOINTURE


NATURELLE DES RELATIONS FREQUENTE ET SERT?

Q2 : ¾QUE REPRESENTENT LES TUPLES DE LA RELATION RESULTANT DE LA JOINTURE


NATURELLE DES RELATIONS FREQUENTE ET AIME?

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Université de Batna - 05000 - Algérie
Chapitre 4: Introduction à l'algèbre relationnelle •179

Q3 : ¾QUE REPRESENTENT LES TUPLES DE LA RELATION RESULTANT DE LA JOINTURE


NATURELLE DES RELATIONS AIME ET SERT?

Q4 : ¾QUE REPRESENTENT LES TUPLES DE LA RELATION RESULTANT DE LA JOINTURE


NATURELLE DES RELATIONS FREQUENTE , SERT ET AIME?

Q5 : ¾ DONNER POUR CHACUNE DES QUESTIONS SUIVANTES, UNE EXPRESSION ALGEBRIQUE


AINSI QUE L’ARBRE ALGEBRIQUE CORRESPONDANT PERMETTANT D’OBTENIR UNE
REPONSE A CETTE QUESTION :

1) ‘‘Liste des CLIENTS qui fréquentent au moins un Café qui SERT une Boisson qu’ils aiment
?’’

2) ‘‘Liste des CLIENTS qui ne fréquentent que des Cafés servant des Boissons qu’ils aiment ?’’

3) ‘‘Liste des CLIENTS qui ne fréquentent aucun Café Servant des Boissons qu’ils aiment ?’’

4) ‘‘Liste des CAFES Servant au moins une BOISSON qu’aucun CLIENT n’aime ?’’

5) ‘‘Liste des CLIENTS qui ne fréquentent que des Cafés Servant des Boissons qu’ils n’aiment
pas ?’’

6) ‘‘Liste des CAFES Servant des BOISSONS et qu’aucun CLIENT ne fréquente ?’’

7) ‘‘Liste des Cafés fréquentés uniquement par des CLIENTS aimant au moins une Boisson
servie par ces Cafés ?’’

Q6 : ¾FORMULER SOUS FORME DE PHRASE UNE QUESTION DONT LA REPONSE EST FOURNIE
PAR L’ARBRE ALGEBRIQUE SUIVANT :

CLIENT CLIENT

FREQUENTE

X FREQUENTE

CLIENT CAFE

FREQUENTE SERT

Q7 : ¾ DONNER UNE EXPRESSION ALGEBRIQUE EQUIVALENTE A CET ARBRE EN UTILISANT


LES OPERATEURS DE DIVISION (%) ET DE PROJECTION.

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Université de Batna - 05000 - Algérie
Chapitre 4: Introduction à l'algèbre relationnelle •180

Exercice 6 :

Soit le schéma relationnel suivant :

INSCRITS (ETUDIANT , MODULE)


DISPENSE (INSTITUT , MODULE)
RETARD (ETUDIANT , MODULE)

La relation INSCRITS représente la liste des modules auxquels sont inscrits les étudiants.. La
relation DISPENSE représente les modules que dispensent les instituts. La relation RETARD
représente les modules qu’ont en retard les étudiants.

Q1 : ¾ DONNER POUR CHACUNE DES QUESTIONS SUIVANTES, UNE EXPRESSION ALGEBRIQUE


AINSI QUE L’ARBRE ALGEBRIQUE CORRESPONDANT PERMETTANT D’OBTENIR UNE
REPONSE A CETTE QUESTION :

1) ‘‘Liste des ETUDIANTS INSCRITS A au moins un MODULE QUE DISPENSE l’institut de MATHS
?’’

2) ‘‘Liste des MODULES auxquels est INSCRIT l’étudiant ALI ainsi que les MODULES qu’il a en
RETARD ?’’

3) ‘‘Liste des MODULES Dispensés par au moins un INSTITUT et auxquels aucun étudiant n’est
INSCRIT ?’’

Q2 : ¾ A QUELLE QUESTION CHACUN DES ARBRES ALGEBRIQUES SUVANTS POURRAIT-IL


FOURNIR UNE RESPONSE ? : L’expression de selection C est : ETUDIANT = ‘‘ALI’’ ou
ETUDIANT = ‘‘OMAR’’

INSCRITS INSCRITS RETARD

(2)
INSCRITS RETARD

(1)
INSTITUT

ETUDIANT ETUDIANT

DISPENSE
INSCRITS RETARD C

(3)

INSCRITS
(4)

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Université de Batna - 05000 - Algérie
Chapitre 5 : Présentation générale DE SQL •181

CHAPITRE 5 : Présentation générale de SQL


1. Introduction
Le langage SQL (Structured Query Language) est issu des travaux menés par IBM autour du
langage prototype SEQUEL (Semi Query Language) pour le SGBD Système R. Aujourd'hui SQL
est devenu un standard (normalisé par l'ANSI depuis 1986) disponible sur presque tous les SGBD
relationnels (DB2, ORACLE, INFORMIX,...). Certains SGBD tel que INGRES offrent même deux
types de langages, l'un algébrique (SQL) et l'autre prédicatif (QUEL).

Contrairement à ce qu’on pourrait penser, SQL n’est pas simplement un langage de requête ou
d’interrogation d’une base de données relationnelle. Il supporte aussi bien les fonctions de description
de données que celles de manipulation de données. La liste suivante permet de donner une idée sur les
opérations qui peuvent être réalisées avec SQL :

• Créer le schéma de la base(Créer , supprimer une table ou un index, etc.)


• Modifier le schéma de la base (ajouter une nouvelle table, modifier le format d’une
colonne, etc.)
• Interroger la base de données
• Définir des vues sur la base de données
• Spécifier les droits d’accès d’un utilisateur vis à vis des objets de la base (relations et
vues)
• Mettre en place un mécanisme de contrôle d’intégrité des données
• Invoquer les commandes à partir d’un langage de programmation (Embedded SQL)

Nous allons présenter la philosophie du langage en matière d’interrogation de la base de données


en vue d’expliquer comment se fait la mise en œuvre des opérateurs de l’algèbre relationnel dans SQL.
Il faut dès lors souligner que notre objectif n’est ni de vous enseigner la pratique de SQL, car il y a
d’autres ouvrages pour ça, ni de vous convaincre de l’utiliser parce que tout le monde en parle et que
presque tous les soit disant SGBD sur PC proposent une interface de type de SQL.

2. Requête en SQL

2.1 Structure d’une requête


Une requête d’interrogation en SQL est composée de trois clauses : SELECT , FROM et
WHERE ayant chacune le rôle suivant :

• SELECT : Cette clause correspond à l’opération de projection de l’algèbre


relationnelle. Elle est utilisée pour lister les attributs devant figurer dans le
résultat d’une requête.

• FROM : Cette clause correspond à l’opération de produit cartésien de l’algèbre


relationnelle. Elle est utilisée pour spécifier la liste des relations devant être
utilisées pour évaluer l’expression.

• WHERE : Cette clause correspond à la condition ou qualification utilisée avec


l’opération de sélection de l’algèbre relationnelle. Elle permet de spécifier
une condition faisant intervenir des attributs appartenant aux relations
figurant dans la clause FROM.

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Univéristé de Batna - 05000 - Algérie
Chapitre 5 : Présentation générale DE SQL •182

2.2 Remarque importante :

Le terme SELECT utilisé dans une requête SQL n’a rien à voir avec celui utilisé dans l’opération
de sélection de l’algèbre relationnelle notée elle aussi par Select ou σ. Dans la suite du texte nous
utiliserons une notation en majuscules SELECT pour désigner la sélection dans une requête SQL et
une notation en minuscules pour faire référence à l’opération algébrique de sélection Select.

Une requête SQL aura donc la forme suivante :

SELECT A1 , A2 , ......., An
FROM R1 , R2 , ......, Rm
WHERE C

Où chaque Ai représente un attribut, chaque Ri représente une relation et C représente une


condition ou une qualification. Une telle requête est équivalente à l’expression de l’algèbre
relationnelle suivante :

Π A1 , A2 , ......., An (σC (R1 x R2 x ......x Rm))

Ainsi, on peut dire que l’évaluation de la requête va consister à calculer le produit cartésien entre
les relations Ri figurant dans la clause FROM, puis à appliquer au résultat obtenu l’opération de
sélection σC de l’algèbre relationnelle en utilisant la condition C figurant dans la clause WHERE, et
enfin à appliquer au résultat obtenu l’opération de projection Π A1 , A2 , ......., An de l’algèbre relationnelle
en utilisant la liste des attributs Ai figurant dans la clause SELECT de la requête. Néanmoins, il faut
souligner que ce schéma d’évaluation est trop simpliste car dans la pratique, le SGBD peut être amené
à convertir une requête en une autre requête équivalente mais plus performante en terme de temps
d’exécution et ce en utilisant les propriétés des opérateurs de l’algèbre relationnelle.

Afin de bien illustrer les possibilités de SQL en matière d’interrogation d’une base de données
relationnelle, nous allons nous servir du schéma relationnel suivant :

EMPLOYES (Num_Emp, Nom_Emp, Fonction, Salaire, Prime, Num_Resp , Num_Dept)


DEPARTEMENTS (Num_Dept, Nom_Dept , Ville)

La signification des attributs de la relation EMPLOYES est la suivante :

Num_Emp : numéro de l’employé


Nom_Emp : nom de l’employé
Fonction : fonction de l’employé
Salaire : salaire de l’employé
Prime : montant de la prime que perçoit l’employé
Num_Resp : numéro du responsable de l’employé
Num_Dept : numéro du département dans lequel travaille l’employé

La signification des attributs de la relation DEPARTEMENTS est la suivante :

Num_Dept : numéro du département


Nom_Dept : nom du département
Ville : nom de la ville ou se trouve le département

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Univéristé de Batna - 05000 - Algérie
Chapitre 5 : Présentation générale DE SQL •183

et nous considérerons les extensions suivantes :

Num_Dept Nom_Dept Ville


10 Comptabilité Batna
20 Recherches Batna
30 Ventes Alger
40 Fabrication Oran

Relation DEPARTEMENTS

Num_Emp Nom_Emp Fonction Num-Resp Salaire Prime Num_Dept


1 Ali Ingénieur 13 800 20
2 Rachid Vendeur 6 1600 300 30
3 Kamel Vendeur 6 1250 500 30
4 Omar Directeur 9 2975 20
5 Brahim Vendeur 6 1250 1400 30
6 Farouk Directeur 9 2850 30
7 Lyes Directeur 9 2450 10
8 Tahar Analyste 4 3000 20
9 Malik Président 5000 10
10 Louisa Vendeur 6 1500 0 30
11 Fatma Ingénieur 8 1100 20
12 Nadia Ingénieur 6 950 30
13 Ahmed Analyste 4 3000 20
14 Kader Ingénieur 7 1300 10

Relation EMPLOYES
Les cases vides traduisent le fait que la valeur de l’attribut est indéfinie pour l’employé
correspondant. Ce sont justement ce que nous avons appelé dans le chapitre 3 des valeurs NULL. Une
valeur NULL ne signifie pas une valeur égale a zéro bien que SQL offre des possibilités pour
convertir une valeur NULL en une autre valeur numérique (par exemple en 0 ) dans les expressions de
calcul utilisables dans une requête.

3. Expression de la projection avec SQL


Une projection consiste à extraire des colonnes (attributs) spécifiques d'une relation puis à éliminer
les tuples en double pouvant apparaître dans la relation résultat. Cette opération s'exprime a l'aide de
SQL par la clause :

SELECT liste d'attributs


FROM nom de relation

En pratique, SQL n'élimine pas les tuples en double car ces tuples ne gênent pas l'utilisateur et leur
élimination implicite par SQL peut entraîner une perte de temps. Cependant SQL offre à l'utilisateur la
possibilité de demander une élimination explicite de ces doubles grâce a un mot clé du langage qui est
: DISTINCT (ou parfois UNIQUE).

A ce niveau, il est important de remarquer que l’autorisation de la présence de tuples dupliqués est
un inconvénient majeur de SQL est qu’il n’est pas un langage ensembliste puisque ne fournissant pas
automatiquement comme résultat un ensemble. Or nous avons vu que les opérations de l’algèbre
relationnelle s’appliquaient à des relations et le résultat était aussi une relation. Ceci n’est en fait vrai

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Univéristé de Batna - 05000 - Algérie
Chapitre 5 : Présentation générale DE SQL •184

que parce que les arguments de ces opérations sont supposées être des relations qui sont des ensembles
au sens mathématique du terme c’est à dire ne contenant pas de tuples dupliqués. Dans le cas où une
relation pouvait contenir un tuple en double, beaucoup de propriétés des opérateurs de l’algèbre
relationnelle seraient remises en cause.

Q1: Donner les noms de tous les employés et le salaire de chacun d'eux ?

SELECT Nom_Emp , Salaire


FROM EMPLOYES

Q2: Liste de tous les Départements dans lesquels travaille au moins un employé?

SELECT DISTINCT Num_Dept


FROM EMPLOYES

On a rajouté le mot clé DISTINCT car le même numéro de Département peut apparaître plusieurs
fois dans le résultat du fait que plusieurs Employés différents peuvent travailler dans un même
département.

Q3: Lister tous les tuples de la relation DEPARTEMENTS ?

SELECT Num_Dept , Nom_Dept , Ville


FROM DEPARTEMENTS

On voit que la liste des attributs après la clause SELECT inclut tous les attributs de la relation
DEPARTEMENTS. Pour simplifier l’écriture d’une telle requête, SQL permet de les formuler comme
suit :

SELECT *
FROM DEPARTEMENTS

ou le SELECT * signifie : " Sélectionner tous les attributs de la relation DEPARTEMENTS "

4. Expression de la sélection avec SQL


L’opération algébrique de sélection s'exprime dans SQL par un bloc du type :

SELECT liste d'attributs


FROM nom de relation
WHERE condition

Q4: Quels sont les employés travaillant dans le département numéro 10

SELECT *
FROM EMPLOYES
WHERE Num_Dept = 10

Avec cette requête, on aura comme résultat une relation ayant le même schéma que la relation
EMPLOYES (i.e. mêmes attributs) et contenant tous les tuples de la relation EMPLOYES pour
lesquels l'attribut Num_Dept a pour valeur 10.

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Univéristé de Batna - 05000 - Algérie
Chapitre 5 : Présentation générale DE SQL •185

Q5: Quels sont les numéros et les noms des employés travaillant dans le
département numéro 10 ?

SELECT Num_Emp, Nom_Emp


FROM EMPLOYES
WHERE Num_Dept = 10

Le résultat de cette requête est identique a celui de la question Q4 sauf qu'ici on aura uniquement
une relation formée de deux colonnes (attributs) qui sont Num_Emp et Nom_Emp et non pas une
relation formée de tous les attributs comme c’était le cas pour Q4 à cause de la clause SELECT *.

On peut éventuellement ordonner le résultat d’une requête grâce à la clause ORDER BY. Pour
cela, il suffit de spécifier dans cette clause le ou les attributs selon lesquels on désire ordonner le
résultat ainsi que le critère ascendant ou descendant.

La condition de la clause WHERE peut utiliser les opérateurs tels que: = , > , ≥ , < , ≤ , != , AND
, OR , NOT , BETWEEN , LIKE , IN , ANY, ALL, EXIST, .... }

BETWEEN : Test d'appartenance à un intervalle


IN : Test d'appartenance d’une valeur à un ensemble
LIKE : Test de ressemblance de chaînes de caractères
ANY : Comparaison d’une valeur à une valeur quelconque d’un ensemble
ALL : Comparaison d’une valeur à toutes les valeurs d’un ensemble
EXIST : Test d’existence d’un tuple dans une relation (Quantificateur existentiel ∃)

Q6: Quels sont les numéros et les noms des employés du département numéro
10 et qui ont un salaire supérieur à 1000 ?

SELECT Num_Emp, Nom_Emp


FROM EMPLOYES
WHERE Num_Dept = 10 AND Salaire > 1000

Q7: Quels sont les fonctions exercées par les employés des départements 10 et
20 en éliminant les tuples en double du résultat?

(a) : avec IN (b): avec OR

SELECT DISTINCT Fonction SELECT DISTINCT Fonction


FROM EMPLOYES FROM EMPLOYES
WHERE Num_Dept IN (10 , 20 ) WHERE Num_Dept = 10 OR Num_Dept = 20

Q8: Quels sont les fonctions dont le salaire est compris entre 2000 et 3000?

(a) : avec BETWEEN (b): avec AND

SELECT DISTINCT Fonction SELECT DISTINCT Fonction


FROM EMPLOYES FROM EMPLOYES
WHERE Salaire WHERE Salaire >= 2000
BETWEEN 2000 AND 3000 AND Salaire < = 3000

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Univéristé de Batna - 05000 - Algérie
Chapitre 5 : Présentation générale DE SQL •186

Q9: Quels sont les employés du département numéro 10 dont le nom


commence par la lettre ‘B’ ?

SELECT Nom_Emp
FROM EMPLOYES
WHERE Num_Dept = 10 AND Nom_Emp LIKE ‘B%’

Le symbole % représente n’importe quelle chaîne de caractères. Il existe d’autres possibilités de


comparaisons avec l’opérateur LIKE. Par exemple, pour rechercher les employés dont le nom se
termine par la lettre R , il suffit d’utiliser ‘%R’ comme argument de LIKE.

Q10: Quels sont les employés du département numéro 10 dont la fonction n’est
ni ‘Ingénieur’ ni ‘Analyste’ ?

SELECT Nom_Emp
FROM EMPLOYES
WHERE Num_Dept = 10
AND NOT (Fonction = ‘Ingénieur’ OR Fonction = ‘Analyste’ )

Il est important à ce niveau de préciser que la réponse à une même question peut être obtenue avec
une ou plusieurs requêtes différentes utilisant chacune un ou des opérateur(s) différent(s).

Il est aussi possible d’exprimer en SQL les opérations algébriques UNION, PRODUIT
CARTESIEN, JOINTURE , INTERSECTION , DIFFERENCE et DIVISION. Certaines opérations
algébriques ne sont pas directement supportées par SQL car ce dernier ne proposant pas un opérateur
spécifique pour les exprimer directement. Cependant, il existe toujours une possibilité pour les traduire
en termes des opérateurs offerts par le langage. C’est le cas par exemple des opérations algébriques de
JOINTURE , DIFFERENCE , INTERSECTION et DIVISION. Nous verrons comment les traduire en
fonction des possibilités du langage dans le cas ou ce dernier ne les supporte pas directement.

5. Expression de l’union avec SQL


L’opération d’union algébrique s'exprime dans SQL par un bloc du type :

SELECT liste d'attributs


FROM nom de relation
WHERE condition
UNION
SELECT liste d'attributs
FROM nom de relation
WHERE condition

Q11: Quels sont les fonctions exercées par les employés des départements 10
et 20 en éliminant les tuples en double du résultat? (même que Q7)

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Univéristé de Batna - 05000 - Algérie
Chapitre 5 : Présentation générale DE SQL •187

(a) : Pas de tuples en double (b) : Avec tuples en double

SELECT Fonction SELECT Fonction


FROM EMPLOYES FROM EMPLOYES
WHERE Num_Dept = 10 WHERE Num_Dept = 10
UNION UNION ALL
SELECT Fonction SELECT Fonction
FROM EMPLOYES FROM EMPLOYES
WHERE Num_Dept = 20 WHERE Num_Dept = 20

Par défaut, l’opération d’UNION (requête (a) ) élimine les tuples en double du résultat. Si on veut
les garder, on doit utiliser UNION ALL (requête (b) ) à la place de UNION tout court comme ci-
dessus. Cette question étant la même que Q7, nous avons vu que dans la requête correspondant à Q7,
on avait explicitement demandé l’élimination des tuples en double grâce au mot clé DISTINCT.

6. Expression du produit cartésien avec SQL


Le produit cartésien entre deux relations est un cas particulier de jointure ou la condition de
jointure est absente (i.e. clause WHERE).

Par exemple le produit cartésien des relations EMPLOYES et DEPARTEMENTS s'obtient à


l'aide de la requête suivante :

SELECT *
FROM EMPLOYES , DEPARTEMENTS

On remarque l'absence de la clause WHERE puisque comme il a été précisé on n'a pas besoin de
spécifier une condition pour avoir le produit cartésien.

Dans la définition de l’opération de produit cartésien, nous avons noté que cette opération ne peut
être évaluée que si les deux relations n’avait pas d’attributs en commun. Dans le cas où les deux
relations avaient des attributs en commun (c’est à dire ayant les même noms), il fallait d’abord les
renommer pour être à même de calculer le produit cartésien de ces relations. Or dans notre exemple,
les relations EMPLOYES et DEPARTEMENTS ont un attribut en commun à savoir Num_Dept. et
pourtant nous ne l’avons pas renommé dans une de ces relations avant de calculer le produit cartésien.
Ceci est dû au fait qu’avec SQL le renommage n’est pas nécessaire puisque ce dernier préfixe
automatiquement un attribut avec le nom de sa relation selon la notation pointée
Nom_de_Relation.Nom_Attribut. Ainsi le nom effectif de l’attribut Num_Dept de la relation
EMPLOYES est EMPLOYES.Num_Dept et celui de la relation DEPARTEMENTS est
DEPARTEMENTS. Num_Dept ce qui évite tout problème d’ambiguïté.

Il est aussi tout à fait possible de préfixer dans une requête un attribut apparaissant dans une clause
SELECT ou une clause WHERE avec le nom de sa relation comme dans la requête suivante (même
que Q6) :

SELECT EMPLOYES.Num_Emp, EMPLOYES.Nom_Emp


FROM EMPLOYES
WHERE Num_Dept = 10 AND Salaire > 1000

Bien que cette écriture soit juste, aucun problème d’ambiguïté ne se pose dans cet exemple puisque
on est sûr que les attributs Num_Emp et Nom_Emp appartiennent à la relation EMPLOYES. Le
préfixage n’est donc pas nécessaire. Néanmoins, dans certaines requêtes, surtout celles mettant en jeu

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Univéristé de Batna - 05000 - Algérie
Chapitre 5 : Présentation générale DE SQL •188

les jointures, on sera très souvent amené à utiliser cette notation afin de lever toute ambiguïté dans la
désignation des attributs.

7. Expression de l’intersection avec SQL


On sait que cette opération a comme arguments deux relations et donne comme résultat une
relation contenant l'ensemble des tuples qui appartiennent en même temps à la première relation et à la
deuxième. Un exemple de question illustrant cette opération est :

Q12: Quels sont les numéros des départements dans lesquels travaillent des
VENDEURS et des 'INGENIEURS'.

SELECT Num_Dept
FROM EMPOYES
WHERE Fonction ='VENDEUR'
INTERSECT
SELECT Num_Dept
FROM EMPOYES
WHERE Fonction ='INGENIEUR'

8. Expression de la différence avec SQL


On sait que cette opération a comme arguments deux relations et donne comme résultat une
relation contenant l'ensemble des tuples appartenant à la première relation mais pas à la deuxième. Un
exemple de question illustrant cette opération est:

Q13: Quels sont les numéros des départements dans lesquels travaillent des
'VENDEURS' mais pas des 'INGENIEURS' ?

SELECT Num_Dept
FROM EMPOYES
WHERE Fonction ='VENDEUR'
MINUS
SELECT Num_Dept
FROM EMPOYES
WHERE Fonction ='INGENIEUR'

Si on se réfère à la définition de l'opération algébrique R-S, on remarque que la première relation R


correspond au le résultat de la sous-requête :

SELECT Num_Dept
FROM DEPARTEMENT
WHERE Fonction ='VENDEUR'

qui contiendra les numéros de tous les départements dans lesquels travaille au moins un employé
ayant pour fonction ‘VENDEUR’ alors que la deuxième relation S correspond au résultat de la sous-
requête :

SELECT Num_Dept
FROM DEPARTEMENT
WHERE Fonction ='INGENIEUR'

qui contiendra les numéros de tous les départements dans lesquels travaille au moins un employé
ayant pour fonction ‘INGENIEUR’.

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Univéristé de Batna - 05000 - Algérie
Chapitre 5 : Présentation générale DE SQL •189

D’après la définition de l’opération MINUS, le résultat sera l'ensemble des tuples appartenant à R mais pas à
S. Donc si un même département possède au moins un employé ayant pour fonction ‘VENDEUR’ (figure dans
R) et possède aussi au moins un employé ayant pour fonction ‘INGENIEUR’ (figure aussi dans S) alors ce
département ne figurera pas dans le résultat de R-S, ce qui répond bien à la question.

9. Expression des jointures avec SQL


9.1 Jointure avec qualification

SQL n’offre pas une opération spécifique pour exprimer la jointure avec qualification ou avec
condition. Comme cette opération algébrique est une opération complémentaire, elle peut s'exprimer
en fonction des opérations de algébriques de base à savoir : la sélection et le produit cartésien. On sait
que :

JOIN C (R,S) = Select C (R x S) ou C représente la condition ou qualification de jointure


faisant intervenir des opérateurs de comparaison.

SQL n’offre pas un opération spécifique pour exprimer la jointure. Il faudra donc l’exprimer
comme une sélection selon une condition sur le produit cartésien des relations R et S .

Q14: Quels sont les numéros et les noms des employés qui travaillent à
‘BATNA’ ?

SELECT Num_Emp , Nom_Emp


FROM EMPLOYES , DEPARTEMENTS
WHERE EMPLOYES•Num_Dept=DEPARTEMENTS•Num_Dept
AND Ville = 'BATNA'

Une représentation graphique de l’expression algébrique permettant de répondre à cette question


serait :

Num_Emp , Nom_Emp Correspond au SELECT


de la requete SQL

Correspond au WHERE
C de la requete SQL

X Correspond au FROM
de la requete SQL

DEPARTEMENTS
EMPLOYES
où la condition C est : EMPLOYES•Num_Dept=DEPARTEMENTS•Num_Dept ∧
Ville = 'BATNA'

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Univéristé de Batna - 05000 - Algérie
Chapitre 5 : Présentation générale DE SQL •190

Q15: Quels sont les noms ,les fonctions et les salaires des employés du
département ‘RECHERCHES’ dont le salaire est supérieur à 1000 ?

SELECT Nom_Emp , Fonction , Salaire


FROM EMPLOYES , DEPARTEMENTS
WHERE EMPLOYES•Num_Dept = DEPARTEMENTS•Num_Dept
AND Nom_Dept = 'RECHERCHE'
AND Salaire > 1000

On remarque que le préfixage d’un attribut avec le nom de sa relation n’est utilisé que pour
Num_Dept qui est commun aux deux relations participant dans la jointure. La condition spécifiée dans
la clause WHERE correspond à la condition de jointure C.

Il est également possible d'imbriquer des blocs : SELECT ... FROM ...WHERE .. à plusieurs
niveaux.

Q16: Quels sont les noms et les fonctions des employés travaillant à ‘BATNA’ et
ayant la même fonction que l’employé ‘AHMED’ ?

Cette jointure peut s'exprimer sous forme de blocs SELECT imbriqués.

SELECT Nom_Emp , Fonction


FROM EMPLOYES , DEPARTEMENTS
WHERE Ville = 'BATNA'
AND EMPLOYES•Num_Dept = DEPARTEMENTS•Num_Dept
AND Fonction IN
( SELECT Fonction
FROM EMPLOYES
WHERE Nom_Emp = 'AHMED' )

9.2 Jointure Naturelle

SQL n’offre pas une opération spécifique pour exprimer la jointure naturelle. Il faudra là aussi
traduire en utilisant l’expression de la jointure naturelle en fonction des opérations algébriques de
sélection , projection et produit cartésien et qui est :

JOIN (R,S) = ΠV ( σ C (R x S) ) ou v est égal l'union des attributs de R et des attributs de S


n'appartenant pas à R , et la condition C : R.A1=S.A1 /\ R.A2=S.A2 /\...... /\ R.Ak=S.Ak avec
(A1,A2,.....AK) les attributs communs à R et à S.

L’expression de la jointure naturelle entre les relations EMPLOYES et DEPARTEMENTS qui ont
un seul attribut peut s’écrire : ΠV ( σ C (EMPLOYES X DEPARTEMENTS) ) où :

V = (Num_Emp,Nom_Emp,Salaire, Fonction, Prime, Num_Dept,Nom_Dept,Ville)

et la condition de sélection C est : EMPLOYES•Num_Dept = DEPARTEMENTS•Num_Dept

d’où la requête SQL équivalente :

SELECT Num_Emp,Nom_Emp,Salaire, Fonction, Prime, Num_Dept,Nom_Dept,Ville


FROM EMPLOYES , DEPARTEMENTS
WHERE EMPLOYES•Num_Dept = DEPARTEMENTS•Num_Dept

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Univéristé de Batna - 05000 - Algérie
Chapitre 5 : Présentation générale DE SQL •191

Il n’est pas obligatoire de spécifier tous les attributs apparaissant dans la clause SELECT de la
requête ci-dessus car SQL ignore qu’il s’agit d’une jointure naturelle. On peut même ne spécifier dans
la clause SELECT qu’un sous ensemble d’attributs de la liste V seulement. Dans le cas où on utilise
un SELECT * , on aura comme résultat une relation ayant pour schéma l’union des attributs de X1 et
X2 (même schéma que la relation résultant du produit cartésien X1 x X2 ) c’est à dire tous les attributs
de X1 plus tous les attributs de X2 indépendamment du fait que X1 et X2 ont les mêmes attributs.
Rappelons que la notation pointée utilisée par SQL pour désigner un attribut X1.nom_Attribut ou
X2.nom_Attribut fait que les attributs communs à deux relations de la base de données possèdent au
niveau interne de SQL des noms distincts du fait du préfixage et ce même si au niveau du schéma ils
ont les mêmes noms.

9.3 Equi-Jointure

Cette opération n’existe pas aussi dans SQL. Cependant, il est possible de l’exprimer de la même
manière que la jointure avec qualification puisque la seule différence est que dans l’équi-jointure
l'opérateur de comparaison θ utilisé dans la condition de jointure est l'opérateur d'égalité ( = ).

9.4 Jointure d’une relation avec elle même (Auto-Jointure)

Pour répondre à certaines questions, on peut parfois être amené à faire la jointure d'une table avec
elle-même. Le problème qui se pose alors est comment distinguer les attributs. La solution qui est
largement utilisée est de désigner dans la clause FROM de la requête SQL la relation (ou table) par
deux noms différents appelés synonymes.

Avec SQL, l’association d’un nom synonyme à une table consiste à faire suivre le nom de la table
par le nom synonyme qui n’est autre qu’un identificateur au sens informatique du terme.

Q17: Quels sont les noms et les fonctions des employés ayant un salaire
supérieur à celui de l’employé dont le nom est 'ALI'

SELECT X1.Nom_Emp , X1.Fonction


FROM EMPLOYES X1 , EMPLOYES X2
WHERE X1.Salaire > X2.Salaire
AND X2.Nomp_Emp = 'ALI'

X1 et X2 sont les noms synonymes désignant la table EMPLOYES. Cette requête peut être vue
comme une requête ayant pour arguments dans la clause FROM deux tables X1 et X2 ayant le mêmes
attributs et la même extension que EMPLOYES. L’évaluation de la requête va consister à calculer le
produit cartésien entre deux les tables X1 et X2, puis de sélectionner les tuples du résultat pour
lesquels la colonne X1.Salaire > X2.Salaire et la colonne X2.Nomp_Emp = 'ALI' . Enfin, on fait une
projection sur les colonnes X1.Nom_Emp et X1.Fonction qui sera alors la relation répondant à cette
question.

Ainsi, le schéma de la relation résultat du produit cartésien X1 x X2 sera :

Attributs de la Table X1 Attributs de la Table X2

X1•Num_Emp X1•Nom_Emp X2•Salaire ..... X2•Num_Emp X2•Nom_Emp X2•Salaire

.
.

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Univéristé de Batna - 05000 - Algérie
Chapitre 5 : Présentation générale DE SQL •192

Après sélection des lignes ou tuples satisfaisant la condition :

X1•Salaire > X2•Salaire AND X2•Nomp_Emp = 'ALI' ,

la projection permet de retenir les colonnes X1•Nom_Emp et X1•Fonction

Un autre exemple d’auto-jointure est :

Q18: Quels sont les noms des employés ayant le même responsable ?

SELECT EMP1•Nom_Emp , EMP2•Nom_Emp


FROM EMPLOYES EMP1 , EMPLOYES EMP2
WHERE EMP1•Num_Resp = EMP2•Num_Resp

Dans cette requête EMP1 et EMP2 sont les noms synonymes de la table EMPLOYES. Les étapes
d’évaluation de la requête sont les mêmes que celles de Q14. Cependant, il faut remarquer ici que dans
le résultat on peut avoir des tuples en double et des tuples symétriques traduisant les situations qui
suivent :

Dans notre exemple, les employés Tahar et Ahmed ont le même responsable (Num_Resp = 4 qui
correspond à l’employé Omar). Dans le résultat de notre requête, on aura une relation ayant deux
attributs et contenant parmi ses tuples les suivants :

EMP1•Nom_Emp EMP2•Nom_Emp

Tahar Tahar
Tahar Ahmed
Ahmed Ahmed
Ahmed Tahar

Les tuples 2 et 4 traduisent la même information : Tahar et Ahmed ont le même responsable. Il
faudrait donc ne garder qu’un seul de ces deux tuples. Les tuples 1 et 3 traduisent le fait que tout
employé a le même responsable que lui-même. Ils n’apportent aucune information et doivent être
éliminés du résultat.

Pour traiter ces cas il suffit de rajouter dans la clause WHERE une condition supplémentaire :

EMP1•Nom_Emp < EMP2•Nom_Emp (ou > )

SELECT EMP1•Nom_Emp , EMP2•Nom_Emp


FROM EMPLOYES EMP1 , EMPLOYES EMP2
WHERE EMP1•Num_Resp = EMP2•Num_Resp
AND EMP1•Nom_Emp < EMP2•Nom_Emp

Essayons de voir l’effet de cette condition supplémentaire sur le résultat final. L’application de
cette condition a lieu au moment de la sélection des lignes à partir de la relation résultant du produit
cartésien entre EMP1 et EMP2. Voyons quelles sont parmi les lignes qui contenaient dans les colonnes
EMP1.Nomp_Emp et EMP2.Nom_Emp les valeurs Tahar et Ahmed celles qui seront retenues par
l’opération de sélection :

¾ Tahar n’est pas < à Tahar : donc la ligne qui contient dans la colonne

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Univéristé de Batna - 05000 - Algérie
Chapitre 5 : Présentation générale DE SQL •193

EMP1.Nom_Emp la valeur Tahar et dans la colonne EMP2.Nom_Emp la valeur


Tahar aussi ne figurera pas dans la relation résultat de la sélection

¾ Tahar n’est pas < à Ahmed : donc la ligne qui contient dans la colonne
EMP1.Nom_Emp la valeur Tahar et dans la colonne EMP2.Nom_Emp la valeur
Ahmed ne figurera pas dans la relation résultat de la sélection.

¾ Ahmed n’est pas < à Ahmed : donc la ligne qui contient dans la colonne
EMP1.Nom_Emp la valeur Ahmed et dans la colonne EMP2.Nom_Emp la valeur
Ahmed aussi ne figurera pas dans la relation résultat de la sélection.

¾ Ahmed est < à Tahar : donc la ligne qui contient dans la colonne
EMP1.Nom_Emp la valeur Ahmed et dans la colonne EMP2.Nom_Emp la valeur
Tahar figurera dans la relation résultat de la sélection

Donc après projection on aura uniquement le tuple (Ahmed,Tahar) dans le résultat final et
correspondant au fait que Tahar et Ahmed ont le même responsable. Il en sera de même pour les autres
employés ayant le même responsable.

10. Utilisation des sous-requêtes


Le terme sous-requête désigne toute requête utilisée à l’intérieur d’une requête dite principale ou
externe. Elle retourne comme toute requête un résultat qui est une relation qui peut comporter une ou
plusieurs colonnes et aussi une seule valeur (une seule ligne), ou un ensemble de valeurs.

La sous requête sert en général pour comparer un attribut ou un ensemble d’attributs de la requête
principale au résultat retourné par la sous requête. Il faut remarquer au passage que les sous requêtes
peuvent aussi être utilisées dans les opérations d’insertion, de mise à jour et de suppression de tuples
dans une table.

10.1 Sous-requête retournant une seule valeur

Q19: Quels sont les noms des employés ayant la même fonction que l’employé
‘OMAR’

SELECT Nom_Emp
FROM EMPLOYES
WHERE Fonction =
( SELECT Fonction
FROM EMPLOYES
WHERE Nomp_Emp ='OMAR' )

La sous requête doit être placée entre parenthèses. Elle est évaluée en premier et va retourner une
seule valeur 'DIRECTEUR'. Cette valeur sera utilisée pour constituer la condition de sélection de la
clause WHERE de la requête principale qui sera donc :

Fonction = 'DIRECTEUR'.

L’opérateur de comparaison utilisé est celui de l’égalité (=) parce qu’on est sûr d’avance que le
résultat retourné par la sous requête comporte une seule valeur.

On aurait pu répondre à cette question en utilisant les deux requêtes séparées suivantes :

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Univéristé de Batna - 05000 - Algérie
Chapitre 5 : Présentation générale DE SQL •194

requête (1) requête (2)

SELECT Fonction SELECT Nom_Emp


FROM EMPLOYES FROM EMPLOYES
WHERE Nomp_Emp ='OMAR' WHERE Fonction = 'DIRECTEUR'

La requête (1) va retourner : 'DIRECTEUR' . On l’utilise alors pour exprimer la requête (2).

10.2 Sous-requête retournant un ensemble de valeurs

Lorsqu’une sous requête retourne un ensemble de valeurs , il faudra faire précéder l’opérateur de
comparaison (= , != , > , < , <= , >=) de la clause WHERE de la requête principale avec un des mots
clefs ANY ou ALL.

Q20: Quels sont les noms des employés ayant un salaire supérieur à celui d’un
employé quelconque du département 30 ?

SELECT Nom_Emp
FROM EMPLOYES
WHERE Salaire > ANY
( SELECT Salaire
FROM EMPLOYES
WHERE Nump_Dept = 30 )

La sous requête va retourner un ensemble de valeurs représentant les salaires du département 30.
Pour chaque employé, la requête principale va comparer son salaire avec l’ensemble des valeurs
retournées par la sous requête. Si le salaire est supérieur à une valeur quelconque de cet ensemble, cet
employé sera inclus dans le résultat.

0 Exprimez cette requête en utilisant la fonction de groupe MINIMUM

Q21: Quels sont les noms des employés ayant un salaire supérieur à celui de
tous les employés du département 30 ?

SELECT Nom_Emp
FROM EMPLOYES
WHERE Salaire > ALL
( SELECT Salaire
FROM EMPLOYES
WHERE Nump_Dept = 30 )

0 Exprimez cette requête en utilisant la fonction de groupe MAXIMUM

On peut dans le cas ou la condition est = ANY , remplacer ce test par l’opérateur IN. De même
que != ALL peut être remplacer par NOT IN.

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Univéristé de Batna - 05000 - Algérie
Chapitre 5 : Présentation générale DE SQL •195

Q22: Quels sont les noms et les fonctions des employés du département 10
ayant la même fonction qu’un employé quelconque du département 30 ?

SELECT Nom_Emp , Fonction


FROM EMPLOYES
WHERE Num_Dept = 10
AND Fonction IN
( SELECT Fonction
FROM EMPLOYES
WHERE Nump_Dept = 30 )

10.3 Sous-requête retournant plusieurs colonnes

Une sous requête peut retourner plus d’une colonne si la liste des attributs de sa clause SELECT
comprend plus d’un attribut. Le nombre d’attributs de la requête principale à comparer avec
l’ensemble des lignes (ou valeurs) retournées par la sous requête doit être égale au nombre de colonnes
retournées par la sous requête.

Q23: Quels sont employés ayant le même salaire et la même fonction que
l’employé ‘Omar’ ?

SELECT *
FROM EMPLOYES
WHERE (Salaire , Fonction) =
( SELECT Salaire , Fonction
FROM EMPLOYES
WHERE Nom_Emp = ‘Omar’ )

Il est aussi possible d’utiliser plusieurs sous requêtes imbriquées et construire ainsi des requêtes
aussi complexes qu’on le souhaite. C’est ce qui fait la puissance du langage SQL.

Q24: Quels sont les noms et les fonctions des employés ayant la même
fonction que l’employé ‘Omar’ ou un salaire supérieur ou égal à celui de
‘Rachid’?

SELECT Nom_Emp , Fonction


FROM EMPLOYES
WHERE Fonction =
( SELECT Fonction
FROM EMPLOYES
WHERE Nom_Emp = ‘Omar’ )

OR Salaire > =

( SELECT Salaire
FROM EMPLOYES
WHERE Nom_Emp = ‘Rachid’ )

Le nombre autorisé de sous requêtes imbriquées dépend de l’implémentation du langage. Par


exemple dans le SQL des premières versions du SGBD ORACLE (V3 et V4 datant déjà de 1982-
1983) autorisait jusqu’à 16 sous requêtes imbriquées en plus de la requête principale.

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Univéristé de Batna - 05000 - Algérie
Chapitre 5 : Présentation générale DE SQL •196

10.4 Utilisation des sous requêtes dans une Jointure

Une sous requête peut être aussi utilisée dans l’expression d’une jointure. L’évaluation de la sous
requête dépend de la façon dont on structure la requête qui la contient. Les exemples suivants
permettent de donner une idée sur quelques possibilités.

Q25: Quels sont les noms, Salaires et fonctions des employés travaillant à
‘Alger’ et ayant la même fonction que ‘Rachid’?

SELECT Nom_Emp , Fonction , Salaire


FROM EMPLOYES , DEPARTEMENTS
WHERE Ville = ‘Alger’
AND EMPLOYES•Num_Dept = DEPARTEMENTS•Num_Dept
AND Fonction IN
( SELECT Fonction
FROM EMPLOYES
WHERE Nom_Emp = ‘Rachid’ )

Dans cette jointure, la sous requête est exécutée en premier et fournit comme résultat un ensemble
de valeurs correspondant aux fonction des employés ayant pour nom ‘Rachid’. Si on est sûr que deux
employés ne peuvent pas avoir le même nom alors le IN peut être remplacé par =. Le résultat est
utilisé pour constituer la partie de la condition de jointure :

Fonction IN <Ensemble des valeurs retournées par la sous requête>.

Dans notre exemple , l’ensemble retourné par la sous requête étant égal à ‘Vendeur’, la condition
de jointure serait équivalente à :

Ville = ‘Alger’
AND EMPLOYES•Num_Dept = DEPARTEMENTS•Num_Dept
AND Fonction IN (‘Vendeur’ )

Nous allons voir un autre exemple où l’évaluation de la sous requête ne se fait pas en une seule fois
indépendamment de la requête principale mais est répétée plusieurs fois en fonction de certaines
données provenant de la requête principale.

Q26: Quels sont les noms et Salaires des employés qui ont un salaire supérieur
à la moyenne des salaires de leur départements?

L’obtention d’une réponse à cette question va nécessiter les étapes suivantes :

• Parcourir la table EMPLOYES de façon à connaître le numéro d du département de


l’employé et son salaire s

• Calculer la moyenne md des salaires du département d (dans une sous requête)

• Tester si le salaire s est > md et si oui inclure l’employé dans le résultat

Une requête permettant de répondre à cette question serait :

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Univéristé de Batna - 05000 - Algérie
Chapitre 5 : Présentation générale DE SQL •197

SELECT Nom_Emp , Salaire


FROM EMPLOYES , X
WHERE Salaire >
( SELECT AVG(Salaire)
FROM EMPLOYES
WHERE X•Num_Detp = Num_Dept )

On remarque l’utilisation d’un nom synonyme X pour la table EMPLOYES dans la clause FROM
de la requête principale. X peut être vu comme une variable qui parcourt les tuples de la relation
EMPLOYES apparaissant dans la requête principale.

La clause WHERE X•Num_Detp = Num_Dept de la sous requête lui permet en quelque sorte de
se synchroniser avec la requête principale. Ainsi pour chaque tuple repéré par la variable X , la sous
requête va calculer la moyenne (fonction AVG : Average qui sera expliquée dans la suite) des salaires
du département ayant le même numéro que celui du tuple repéré par X et qui correspond à un employé
bien sûr. Le fait que la sous requête référence la même table EMPLOYES dans sa clause FROM ne
gêne en aucun cas la requête principale.

11. Autres possibilités d'interrogation de SQL


11.1 Utilisation du prédicat EXISTS

En logique on utilise généralement les deux quantificateurs ∃ (il existe) et ∀ (quelque soit) qui
s’appliquent à des propositions selon les deux formes : ∃ x P(x) et ∀ x P(x) . Dans le premier cas la
P(x) est vraie s’il existe au moins une valeur de x qui la rend vraie et dans le deuxième cas P(x) est
vraie si et seulement si elle est vraie pour toutes les valeurs de x .

SQL offre un prédicat qui s’appelle EXISTS équivalent du quantificateur existentiel ∃. Il permet
de tester si l’ensemble de valeurs (tuples) retourné par une requête (ou sous requête) est vide ou non.
Ce test est évalué à vrai (TRUE) si l’ensemble contient au moins une ligne et à faux (FALSE) si
l’ensemble retourné est vide.

SQL n’offre pas de prédicat équivalent du quantificateur ∀. Cependant, ce quantificateur peut être
traduit en utilisant l’opérateur EXISTS. En effet, Il suffit de remarquer l’équivalence entre les deux
formules suivantes :

∀ x P(x) ≡ ∃ x P(x)

L’utilisation du quantificateur ∀ est très rare dans l’expression des requêtes. Il sert surtout pour
exprimer l’opération algébrique de DIVISION dont la définition formelle utilise justement ce
quantificateur.

11.2 Expression de la différence avec EXISTS

La différence entre deux relations peut s’exprimer grâce a l’opérateur MINUS dont l’utilisation est
semblable a celle de l’union entre deux relations. Il est aussi possible d’utiliser le prédicat EXISTS
pour réaliser cette opération. Nous allons illustrer la mise en ouvre de la différence à l’aide de la
question suivante :

Q27: Quels sont les numéros des départements dans lesquels travaillent des
'VENDEURS' mais pas des 'INGENIEURS' ?

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Univéristé de Batna - 05000 - Algérie
Chapitre 5 : Présentation générale DE SQL •198

SELECT Num_Dept
FROM DEPARTEMENT
WHERE Fonction ='VENDEUR'
AND NOT EXISTS
( SELECT Num_Dept
FROM DEPARTEMENT
WHERE Fonction ='INGENIEUR' )

11.3 Expression de la division avec EXISTS

On sait que la division d’une relation R de schéma R(A,B,C) par une relation S de schéma S(C) est
une relation Q de schéma Q(A, B) et telle que :

Q = { (a, b) ∈ à R / ∀ (c) ∈ à S , ∃ (a,b,c) ∈ à R) }

Autrement dit, en utilisant l’équivalence des formules : ∀ x P(x) ≡ ∃ x P(x) on peut traduire la
division comme suit :

(a,b) ∈ Q si et seulement si il n’existe pas de c ∈ à S tel qu’il n’existe pas de (a,b,c) ∈ R.

Ainsi, la division va se traduire en SQL par l’utilisation de deux opérateurs NOT EXITS
successifs. Nous allons illustrer la mise en ouvre de la division à l’aide des deux relations suivantes :

PROFESSEURS(Num_Prof, Code_Mod)
MODULES(Code_Mod , Spécialité)

Il s’agit de répondre à la question suivante :

Q28: Quels sont les numéros des enseignants qui dispensent TOUS les
modules de la spécialité ‘INFORMATIQUE’?

SELECT DISTINCT (Num_Prof)


FROM PROFESSEURS X
WHERE NOT EXISTS
( SELECT *
FROM MODULES
WHERE MODULES.Spécialité ='INFORMATIQUE'
AND NOT EXISTS
( SELECT *
FROM PROFESSEURS
WHERE MODULES•Code_Mod=PROFESSEURS•Code_Mod
AND PROFESSEURS•Num_Prof = X•Num_Prof ) )

12. Les fonctions de groupes


12.1 aperçu général

SQL offre aussi un certain nombre de fonctions dites fonctions de groupes qui peuvent être
utilisées dans l'expression d'une requête. les plus importantes sont :

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Univéristé de Batna - 05000 - Algérie
Chapitre 5 : Présentation générale DE SQL •199

AVG : permet de calculer une MOYENNE


SUM : permet de calculer une SOMME
COUNT : permet de compter des tuples
MAX : permet de calculer un maximum
MIN : permet de calculer un minimum
GROUP BY : permet de créer des sous-ensembles de tuples
HAVING : permet de tester si une condition est vérifiée par un groupe de tuples

Nous allons commencer par illustrer à l’aide d’exemples comment utiliser les fonctions AVG, MIN
, MAX et COUNT puis nous examinerons de plus près la manipulation des groupes de tuples.

Q29: Quels sont les numéros et salaires des employés dont le salaire est
supérieur à 10% de la moyenne des salaires de son département ?

SELECT Nom_Emp , Salaire


FROM EMPLOYES , X
WHER Salaire >
( SELECT AVG(Salaire) * 0.10
FROM EMPLOYES
WHERE X•Num_Detp = Num_Dept )

Q30: Quel est le nom , la fonction et le salaire de(s) l’employé(s) ayant le


salaire le plus élevé

SELECT Nom_Emp , Fonction , Salaire


FROM EMPLOYES
WHER Salaire =
( SELECT MAX(Salaire)
FROM EMPLOYES)

La sous requête est évalué en premier et permet de calculer le salaire maximum des employés. La
requête principale va parcourir les lignes de la table EMPLOYES et comparer le salaire de chaque
employé avec le résultat de la sous requête. S’il y a égalité, le nom , la fonction et le salaire de cet
employé figurera dans le résultat final.

Q31: Quel est le salaire maximum , le salaire minimum et la différence entre


ces deux valeurs ?

SELECT MAX(Salaire) , MIN(Salaire) , MAX(Salaire) - MIN(Salaire)


FROM EMPLOYES

Q32: Quel est le nombre d’employés percevant une prime ?

SELECT COUNT(Prime)
FROM EMPLOYES

Q33: Quel est le nombre de fonctions différentes exercées dans le département


30 ?

SELECT COUNT(DISTINCT Fonction)


FROM EMPLOYES
WHERE Num_Dept = 30

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Univéristé de Batna - 05000 - Algérie
Chapitre 5 : Présentation générale DE SQL •200

Le mot DISTINCT clé permet de ne compter une même valeur qu’une seule fois. Le nombre
retourné sera bien le nombre de valeurs différentes de l’attribut Fonction.

12.2 Manipulation de groupes : la clause GROUP BY

La clause GROUP BY permet de partitionner les tuples d’une relation de façon à former des
groupes de tuples. Chaque groupe de tuples est caractérisé par le fait que les tuples qu’il contient
possèdent les mêmes caractéristiques.

La manipulation des groupes implique donc que les requêtes peuvent comporter des clauses
WHERE , GROUP BY, des fonctions de groupes (AVG, SUM, MAX, MIN) et HAVING. La clause
WHERE est utilisée pour sélectionner dans une table les lignes (tuples) qui satisfont une condition.
Elle ne s’applique donc pas aux groupes. La clause HAVING est utilisée pour sélectionner dans une
table les groupes de lignes (tuples) qui satisfont une condition. Elle ne s’applique donc pas aux lignes
et s’utilise avec une clause GROUP BY.

Dans une requête manipulant des fonctions de groupe, il existe un ordre logique d'exécution de la
requête et qui est :

1- La clause WHERE est appliquée en premier pour qualifier les lignes


2- Les groupes de lignes sont formés (GROUP BY)
3- Les fonctions de groupes sont appliquées(AVG, MIN , MAX,..)
4- Enfin la clause HAVING est appliquée pour choisir les groupes répondant au critère
spécifié dans cette clause.

Q34 : Quelle est la moyenne des salaires du département 10 ?

SELECT AVG (Salaire)


FROM EMPLOYES
WHERE Num_Dept = 10

Si on veut connaître la moyenne des salaires des départements 20 et 30, il suffit d’utiliser la même
requête en remplaçant dans la clause WHERE Num_Dept = 10 par Num_Dept = 20 puis par
Num_Dept = 30 comme suit :

moyenne des salaires du département 20 moyenne des salaires du département 30

SELECT AVG (Salaire) SELECT AVG (Salaire)


FROM EMPLOYES FROM EMPLOYES
WHERE Num_Dept = 20 WHERE Num_Dept = 30

Au lieu d’utiliser 3 requêtes séparées, on peut obtenir la moyenne des salaires par département
avec une seule requête en utilisant une clause GROUP BY comme suit :

SELECT Num_Dept , AVG (Salaire)


FROM EMPLOYES
GROUP BY Num_Dept

Q35: Quels est pour chaque département et chaque fonction le salaire annuel
(12 mois) moyen par fonction et le nombre d’employés exerçant cette
fonction?

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Univéristé de Batna - 05000 - Algérie
Chapitre 5 : Présentation générale DE SQL •201

SELECT Num_Dept, Fonction , Count (*) , AVG (Salaire) * 12


FROM EMPLOYES
GROUP BY Num_Dept , Fonction

Q36: même question que mais donner le nom du département au lieu du


numéro ce qui va nécessiter de faire une jointure ?

SELECT Nom_Dept, Fonction , Count (*) , AVG (Salaire) * 12


FROM EMPLOYES , DEPARTEMENTS
WHERE EMPLOYES•Num_Dept = DEPARTEMENTS•Num_Dept
GROUP BY Num_Dept , Fonction

Q37: Quels est pour chaque département le salaire annuel (12 mois) moyen de
tous ses employés sauf ceux ayant une fonction de ‘DIRECTEUR’ ou
‘PRESIDENT’?

SELECT Num_Dept, AVG (Salaire) * 12


FROM EMPLOYES
WHERE Fonction NOT IN (‘DIRECTEUR’ , ‘PRESIDENT’)
GROUP BY Num_Dept

Q38: Quels sont les numéros des départements ayant plus de 10 employés ?

SELECT Num_Dept
FROM EMPLOYES
GROUP BY Num_Dept
HAVING COUNT(*) > 10

Le COUNT(*) compte les tuples des sous-ensembles créés par GROUP BY. Les tuples de chaque
sous-ensemble crée ont la même valeur de l'attribut qui est utilisé dans le GROUP BY (c.a.d. ici
Num_Dept). Le résultat de cette requête sera une relation partitionnée en groupes de tuples ayant la
même valeur de l’attribut Num_Dept. A chacun de ces groupes sera appliquée la qualification de la
clause HAVING c'est a dire COUNT(*) > 10. Si le groupe satisfait la condition (contient plus de 10
tuples), il sera inclut dans le résultat par le biais de son attribut Num_Dept jouant le rôle de
dénominateur commun pour les tuples du groupe.

Q39: Quelles sont les différentes fonctions exercées dans l’ensemble des
départements et la moyenne des salaires par fonction ?

SELECT Fonction , AVG (Salaire)


FROM EMPLOYES
GROUP BY Fonction

Q40: Quelles sont les différentes fonctions exercées dans l’ensemble des
départements dont la moyenne des salaires par fonction est supérieure à
10.000 ?

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Univéristé de Batna - 05000 - Algérie
Chapitre 5 : Présentation générale DE SQL •202

SELECT Fonction , AVG (Salaire)


FROM EMPLOYES
GROUP BY Fonction
HAVING AVG (Salaire) > 10.000

Q41: Quels sont les numéros des départements au moins deux employés
exerçant la fonction de ‘Vendeur’?

SELECT Num_Dept
FROM EMPLOYES
WHERE Fonction = ‘Vendeur’
GROUP BY Num_Dept
HAVING COUNT(*) > 2
Q42: Quels sont les numéros des départements dans lesquels la moyenne des
primes est supérieur à 10% de la moyenne des salaires?

SELECT Num_Dept , AVG (Salaire) , AVG (Prime) , AVG (Salaire) * 0.10


FROM EMPLOYES
GROUP BY Num_Dept
HAVING AVG (Prime) > AVG (Salaire) * 0.10
Dans la liste des attributs figurant dans une clause SELECT si on a des noms d’attributs avec
fonctions de groupe (AVG , MAX, MIN , .....), on ne peut pas avoir en même temps de nom d’attribut
sans fonction de groupe. Par exemple l’écriture suivante serait une erreur :

SELECT Nom_Emp , AVG (Salaire)

parce que l’attribut Nom_Emp est un attribut ayant une valeur dans chaque ligne alors que AVG
(Salaire) représente une valeur correspondant à un ensemble de lignes qui seront sélectionnées. Si
on veut combiner dans la liste un attribut sans fonction de groupe avec un autre avec fonction de
groupe, on doit utiliser une sous requête.

12.3 Tri du résultat d’une requête : la clause ORDER BY


La clause ORDER BY permet de trier le résultat retourné par une requête. L’ordre peut être ascendant (ASC)
ou descendant (DESC) et sera fonction du type de ou des attributs qui seront spécifiés comme arguments de cette
clause. Les exemples suivants permettent de donner une idée des possibilités de cette clause.

Q43: Liste des employés du département 10 par ordre décroissant de leur


salaire?

SELECT Num_Dept , Nom_Emp, Salaire


FROM EMPLOYES
WHERE Num_Dept = 10
ORDER BY Salaire DESC

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Univéristé de Batna - 05000 - Algérie
Chapitre 5 : Présentation générale DE SQL •203

Q44: Liste par ordre alphabétique des employés du département 10?

SELECT Nom_Emp
FROM EMPLOYES
WHERE Num_Dept = 10
ORDER BY Nom_Emp
Il est aussi possible de trier le résultat retourné par une requête en fonction de plusieurs attributs.

Q45: Liste des employés triés selon un ordre alphabétique de leur fonction et a
l’intérieur de chaque fonction les trier selon un salaire décroissant.

SELECT Nom_Emp, Fonction, Salaire


FROM EMPLOYES
ORDER BY Fonction ASC, Salaire DESC
Cette requête va entraîner dans un premier temps un tri du résultat par ordre alphabétique selon la
fonction des employés. Puis un autre tri sera effectué sur les tuples correspondant aux employés ayant
la même fonction de façon a les arranger selon un ordre décroissant de leur salaire.

12.4 Requêtes impliquant des colonnes contenant NULL

12.4.1 Utilisation de colonnes contenant NULL dans une clause WHERE

L’opérateur de comparaison IS NULL (ou IS NOT NULL) permet d’exprimer une condition avec une
colonne contenant des valeurs NULL.

Q46: Liste des employés n’ayant pas reçu de prime.

SELECT Nom_Emp, Salaire, Prime


FROM EMPLOYES
WHERE Prime IS NULL

Nom_Emp Salaire Prime


Ali 800
Omar 2975
Farouk 2850
Lyes 2450
Tahar 3000
Malik 5000
Fatma 1100
Nadia 950
Ahmed 3000
Kader 1300

La condition Prime = NULL n’est pas un test valide pour trouver les valeurs NULL. Son utilisation est
possible mais retourne un résultat vide.

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Univéristé de Batna - 05000 - Algérie
Chapitre 5 : Présentation générale DE SQL •204

Q47: Liste des employés du département 30 dont la prime est inférieure a 1000.

SELECT Nom_Emp, Prime, Num_Dept


FROM EMPLOYES
WHERE Num_Dept = 30 AND Prime < 1000

Nom_Emp Prime Num_Dept


Rachid 300 30
Kamel 500 30
Louisa 0 30

On remarque que les employés du département 30 dont la prime est NULL ne sont pas inclus dans le
résultat.

12.4.2 Utilisation de colonnes contenant NULL avec la clause ORDER BY

Quelque soit l’ordre de tri ascendant (ASC) ou descendant (DESC), si dans une clause ORDER BY l’attribut
utilisé contient des valeurs NULL ou indéfinies, les t sera fonction du type de ou des attributs qui seront spécifiés
comme arguments de cette clause. Les exemples suivants permettent de donner une idée des possibilités de cette
clause.
SELECT Nom_Emp, Salaire, Prime
FROM EMPLOYES
ORDER BY Prime
Du fait que la colonne Prime contient des valeurs NULL, dans le résultat les lignes pour lesquelles l’attribut
Prime a une valeur NULL apparaîtront en premier suivies de celles pour lesquelles Prime n’est pas NULL et qui
seront alors triées par ordre croissant des primes.

Nom_Emp Salaire Prime


Ali 800
Omar 2975
Farouk 2850
Lyes 2450
Tahar 3000
Malik 5000
Fatma 1100
Nadia 950
Ahmed 3000
Kader 1300
Louisa 1500 0
Rachid 1600 300
Kamel 1250 500
Brahim 1250 1400

13. La description des données avec SQL


SQL offre un certain nombre de commandes pour créer des tables et pour modifier leurs structures.
Les principales commandes sont :

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Univéristé de Batna - 05000 - Algérie
Chapitre 5 : Présentation générale DE SQL •205

CREATE TABLE : ajouter une table à la B.D.


ALTER TABLE : modifier une colonne ou ajouter une nouvelle colonne à une table
DROP TABLE : supprimer une table

13.1 Création de tables : La commande CREATE TABLE

Pour créer une table on spécifie le nom de la table, les noms des colonnes ainsi que le type des
données de chaque colonne. Un nom de table ou de colonne (attribut) est un identificateur au sens
informatique du terme et obéit en général aux règles syntaxiques de construction d’un identificateur
(i.e. commencer par un caractère alphabétique, etc.).

Les Types de données possibles pour un attribut sont variés. Nous donnons ci-dessous des
exemples inspirés du SGBD ORACLE :

CHAR : caractères
NUMBER : chiffre de 0 à 9,signe et point décimal
DATE : date (MM-JJ-AA)

On peut aussi spécifier la longueur maximal d'un champ (CHAR ou NUMBER).

Exemple:

CHAR(12) : maximum 12 caractères


NUMBER(4) : 4 chiffres au maximum
NUMBER(7,2) : maximum 7 chiffres dont 2 à droite du point décimal

La spécification de la longueur maximale d'un champ permet au SGBD de contrôler si une valeur
ajoutée dans la colonne ne dépassera pas ce maximum.

Pour spécifier qu'une colonne ne doit pas contenir de valeurs NULL (ou indéfinies, inconnues), il
faut ajouter après le type l'option NOT NULL.

Exemple:

CREATE TABLE ETUDIANTS ( NUMERO NUMBER NOT NULL,


NOM CHAR(10),
MOYENNE NUMBER(4,2) )

L’attribut NUMERO est un nombre dont la taille sera prise par défaut et ne comporter de valeurs
NULL. L’attribut NOM est une chaîne de 10 caractères au maximum. L’attribut MOYENNE est un
nombre de 4 chiffres dont 2 après la virgule.

13.2 Extension d’une colonne: La commande ALTER TABLE

La taille d'une colonne peut être augmentée grâce à la commande ALTER TABLE dont le format
est :

ALTER TABLE <nom de table>


MODIFY (<nom de colonne>,<type(nouvelle taille)>)

Exemple:

ALTER TABLE ETUDIANTS


MODIFY (MOYENNE,NUMBER(6,2))

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Univéristé de Batna - 05000 - Algérie
Chapitre 5 : Présentation générale DE SQL •206

13.3 Ajout d’une nouvelle colonne : La commande ALTER TABLE

L’ajout d’une nouvelle colonne peut se faire grâce à la commande ALTER TABLE avec le Format
suivant :

ALTER TABLE <nom de table>


ADD (<nom de colonne>,<type>)

Exemple:

ALTER TABLE ETUDIANTS


ADD (AGE,NUMBER(2))

La nouvelle colonne AGE sera rajoutée à droite des autres colonnes de la table et sera initialisée
par des valeurs NULL. On ne doit donc pas spécifier l'option NOT NULL à ce niveau. Cette colonne
peut être remplie grâce à la commande UPDATE (voir la commande UPDATE plus loin).

13.4 Suppression d’une table : DROP TABLE

Pour supprimer une table, on utilise la commande DROP TABLE ayant le format suivant :

DROP TABLE <nom de table>

Exemple:

DROP TABLE ETUDIANTS

qui va provoquer la suppression de la table ETUDIANTS.

13.5 Requêtes de mise a jour d'une table

SQL offre les 3 commandes suivantes:

INSERT : ajouter une ligne dans une table


UPDATE : changer une valeur dans une ligne de la table
DELETE : supprimer une ligne dans une table

On suppose pour la suite que la relation ou table ETUDIANTS a pour schéma :

ETUDIANTS(NUMERO, NOM, MOYENNE, AGE)

13.5.1 Insertion de lignes dans une table : la commande INSERT

La commande INSERT permet d’insérer des lignes (tuples) dans une table. Son format général est
:
INSERT INTO <nom de relation>
VALUES (liste de valeurs)

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Univéristé de Batna - 05000 - Algérie
Chapitre 5 : Présentation générale DE SQL •207

Exemple:

On veut insérer une ligne ou un tuple dans la table ETUDIANTS correspondant à l’étudiant ayant
pour numéro 795 , pour nom JOJO , pour moyenne 12.54 et pour âge 21 ans.

INSERT INTO ETUDIANTS


VALUES (795,'JOJO',12.54,21)

On peut ajouter une ligne incomplète en ne donnant que les valeurs de certains attributs. Pour cela,
il faut préciser les noms de ces attributs (i.e. colonnes) dans INSERT.

Exemple:

On veut insérer une ligne ou un tuple dans la table ETUDIANTS correspondant à l’étudiant ayant
pour numéro 15 , pour nom TITI , pour âge 19 ans et dont on ne connaît pas le moyenne.

INSERT INTO ETUDIANTS(AGE,NUMERO,NOM)


VALUES (15,'TITI',19)

Toutes les autres colonnes de la table seront initialisées avec la valeur NULL. On remarque que
l’ordre des colonnes n’a pas d’importance alors que dans l’exemple précédent si car on n’a pas
spécifié les noms des attributs et donc l’ordre implicite est celui donné lors de la création de la table.

13.5.2 Mise à jour de lignes dans une table : UPDATE

La commande UPDATE permet de changer la valeur d'un attribut. Son Format général est :

UPDATE <nom de table>


SET <nom de colonne> = valeur
WHERE <liste de conditions>

La clause WHERE est optionnelle. Elle sert à faire des changements sélectifs sur les lignes
satisfaisant les conditions spécifiées. WHERE peut contenir les mêmes conditions de recherches que
celles possibles avec une clause SELECT.

Exemple 1 : Mise à jour d'une seule colonne d'une ligne

L'étudiant ayant pour nom TOTO , vient réclamer qu’il lui manque un demi point dans sa
moyenne. Il faudra alors lui majorer sa moyenne de 0.5.

UPDATE ETUDIANTS
SET MOYENNE = MOYENNE + 0.5
WHERE NOM = 'TOTO'

Exemple 2 : Mise à jour de plusieurs colonnes dans une même ligne

Lors de la saisie des attributs de l'étudiant numéro 795 des erreurs se sont glissées dans l'âge, la
moyenne et le nom de cet étudiant. Il faudra alors les corriger avec les valeurs correctes suivantes :

UPDATE ETUDIANTS
SET AGE=25 , NOM = 'OMAR' , MOYENNE =09.5
WHERE NUMERO = 795

Les colonnes doivent être séparées par une virgule dans la clause SET.

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Univéristé de Batna - 05000 - Algérie
Chapitre 5 : Présentation générale DE SQL •208

13.5.3 Suppression de lignes dans une table : DELETE

La commande DELETE permet de supprimer des lignes d'une table. Elle permet donc de
supprimer une seule ligne dans une table ou plusieurs en même temps. Son format général est :

DELETE FROM <nom de relation>


WHERE <liste de conditions>

La clause WHERE est optionnelle. Elle sert à faire des suppressions sélectives des lignes
satisfaisant les conditions spécifiées. WHERE peut contenir les mêmes conditions de recherches que
celles possibles avec SELECT ou UPDATE.

Exemple 1:

Supprimer l’étudiant ayant pour nom : TOTO

DELETE FROM ETUDIANTS


WHERE NOM = 'TOTO'

Exemple 2:

Supprimer tous les étudiants ayant la même moyenne que l'étudiant ayant pour nom : TOTO.

DELETE FROM ETUDIANT


WHERE MOYENNE IN ( SELECT MOYENNE
FROM ETUDIANTS
WHERE NOM = 'TOTO')

Une commande DELETE sans clause WHERE implique la suppression de toutes les lignes de la
table.

14. Utilisation des vues ( VIEWS )


Les vues sont en quelque sorte des fenêtres à travers lesquelles on peut voir les données de la base.
Les vues ne contiennent pas de données mais c'est tout comme et peuvent être manipulées comme si
c'étaient des tables. Du fait que les vues n'occupent pas d'espace mémoire, elles sont appelées
TABLES VIRTUELLES.

14.1 Création d’une vue : la commande CREATE VIEW

Une vue est dérivée d'une ou plusieurs tables réelles. Du fait que le résultat d'une requête est lui-
même une table, une vue peut donc être définie grâce à une requête. Le format général d’une requête
de création d'une vue est :

CREATE VIEW <nom de la vue>


AS <requête de création>

Exemple :

On veut créer une vue MOYENNE_ETUDIANTS à partir de la table ETUDIANTS qui


contiendra uniquement les noms et les moyennes des étudiants dont le nom commence par ‘B’ et la
moyenne inférieure à 10.

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Univéristé de Batna - 05000 - Algérie
Chapitre 5 : Présentation générale DE SQL •209

CREATE VIEW MOYENNE_ETUDIANTS


AS
SELECT NOM,MOYENNE
FROM ETUDIANTS
WHERE NOM LIKE ‘B%’
AND MOYENNE < 10.0

La vue MOYENNE_ETUDIANTS est équivalente à une table de 2 colonnes NOM et MOYENNE


et dont les lignes sont extraites de la table ETUDIANTS.

On peut utiliser toute la puissance de SQL pour définir une VUE. La commande CREATE VIEW
ne doit pas contenir de clause ORDER BY car l'ordre est spécifié lorsqu'on exécute une requête sur la
vue. Cependant quelques limites existent telles que :

On peut utiliser une jointure entre tables dans la définition d’une vue.

Exemple :

On veut créer une vue RECHERCHE à partir des tables EMPLOYES , DEPARTEMENTS
uniquement les noms , fonctions et salaires des employés du département ‘RECHERCHES’ dont le
salaire est supérieur à 1000 ?

CREATE VIEW RECHERCHE


AS
SELECT Nom_Emp , Fonction , Salaire
FROM EMPLOYES , DEPARTEMENTS
WHERE EMPLOYES•Num_Dept= DEPARTEMENTS•Num_Dept
AND Nom_Dept = 'RECHERCHE'
AND Salaire > 1000

14.2 Interrogation d’une vue

On peut utiliser dans toute requête SQL le nom d'une vue, comme on peut utiliser toute la
puissance du langage SQL pour interroger une vue.

Exemple :

Quels sont les nom et les moyennes de tous les étudiants dont le nom se termine par 'R'

SELECT NOM,MOYENNE
FROM MOYENNE_ETUDIANTS
WHERE NOM LIKE ‘%R’

Il faut souligner que les changements qui sont faits dans les tables sont directement visibles dans
les vues qui ont été définies à partir de ces tables. Par exemple , la requête précédente n'affichera pas
l’étudiant de nom 'BERBAR' si ce dernier a été supprimé de la table ETUDIANTS par la commande
de suppression de tuples DELETE.

On peut ajouter, mettre à jour ou supprimer des lignes dans une vue de la même façon qu'avec une
table. Cependant certaines opérations (comme l'insertion) sur une vue engendrent des problèmes au
niveau de la répercussion de ces opérations sur les tables qui ont servi à définir cette vue. C'est le
problème de propagation des mises à jour sur une vue.

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Univéristé de Batna - 05000 - Algérie
Chapitre 5 : Présentation générale DE SQL •210

Exemple :

Insérer l'étudiant de NOM = 'BACHIR' et de MOYENNE = 12 dans la vue


MOYENNE_ETUDIANTS créée plus haut

INSERT INTO MOYENNE_ETUDIANTS


VALUES ('BACHIR',12)

Or la table ETUDIANTS qui a servi à la création de cette vue a le schéma suivant :

ETUDIANTS(NUMERO,NOM,MOYENNE,AGE)

Donc l'insertion du tuple ('BACHIR', 12) dans la vue ne peut se répercuter dans la table
ETUDIANTS que sous la forme du tuple suivant : (NULL,'BACHIR',12,NULL)

ou NULL correspond à une valeur indéfinie. Ceci pose un problème car l'attribut NUMERO a été
défini comme NOT NULL lors de la création de la table ETUDIANTS et on ne pourra donc pas
insérer le tuple (NULL,'BACHIR',12,NULL) dans la table. Donc on ne peut pas répercuter l'insertion
faite sur la vue au niveau de la table qui a permis de créer cette vue. Le problème se complique encore
plus si la vue a été obtenue par jointure entre plusieurs tables.

15. Conclusion
Le langage SQL est a l'heure actuelle le langage le plus utilisé dans le domaine des bases de
données. Certains auteurs le qualifient de COBOL des années 90. Il constitue aussi le support idéal au
développement des L4G (langages de 4ieme génération). Un L4G est un outil de productivité
permettant de développer des applications complètes sans programmation. Il est construit a partir d'un
langage relationnel comme SQL.

Certains SGBD comme ORACLE offrent des outils dans ce sens et qui sont tous développés autour
de SQL. Ceci inclue :

- un générateurs d'états
- un tableur
- un utilitaire de sortie graphique
- un générateur d'application
- etc.

L'utilisation de SQL et des utilitaires associés ouvre le développement d'applications a de nouveaux


utilisateurs (non spécialistes) tout en améliorant les performances (temps de développement, de
maintenance et de flexibilité). Avec un véritable L4G, le développeur d'application n'est plus un
programmeur au sens classique du terme (i.e. au sens des L3G procéduraux).

Enfin, rien ne remplacerais l’apprentissage du langage par la pratique en utilisant n’importe quel
SGBD relationnel dont on peut disposer. A notre avis, le plus simple serait de pratiquer le langage
avec le SGBD Microsoft ACCESS. Mais il faut noter aussi qu’il existe beaucoup d’autres SGBD
relationnels distribués gratuitement et pouvant même fonctionner dans une architecture Client/Serveur
comme par exemple MySql.

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Univéristé de Batna - 05000 - Algérie
Chapitre 5 : Présentation générale DE SQL •211

Exercices sur le Chapitre 5

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Univéristé de Batna - 05000 - Algérie
Chapitre 5 : Présentation générale DE SQL •212

Exercice 1:

Considérons a nouveau la base de données relationnelle présentée au début du chapitre et composée


des tables suivantes avec les mêmes extensions :

EMPLOYES (Num_Emp, Nom_Emp, Fonction, Salaire, Prime, Num_Resp , Num_Dept)


DEPARTEMENTS (Num_Dept, Nom_Dept , Ville)

Donnez pour chacune des questions suivantes une requête SQL permettant de répondre a cette
question :

Q1 : Liste des départements avec pour chacun la moyenne des salaires du département

Q2 : Liste par ordre croissant de leur salaire des employés travaillant dans la ville de BATNA

Q3 : Pour chaque département donnez le nombre d’employés exerçant comme responsable dans ce
département.

Q4 : Liste des départements avec le nombre d’employés par département

Q5 : Liste des employés ayant le même salaire que l’employé numéro 100

Q6 : Donnez les noms et salaires des employés dont le salaire est plus grand que le salaire moyen de
leur département

Q7 : Liste des départements yant au moins 3 employés dont le salaire est égal a 5000

Q8 : Donnez les noms et salaires des employés dont le salaire est supérieur a celui de leur
responsable ainsi que le nom est le salaire de ce responsable

Q9 : Liste des départements ou travaillent plus de 10 employés occupant le poste de responsable.

Exercice 2:

Soit la base de données relationnelle composée des tables suivantes :

ETUDIANTS (Num_Etudiant, Nom_Etudiant, Age, Num_Délégué, Num_Institut)


INSTITUTS (Num_Institut, Nom_Institut)

Donnez pour chacune des questions suivantes une requête SQL permettant de répondre a cette
question :

Q1 : Liste des étudiants de l’institut ayant pour nom ‘MATHS’

Q2 : Liste des INSTITUTS avec pour chacun la moyenne d’âge de cet institut

Q3 : Quel est le nom de l’étudiant le plus âgé ainsi que le nom de son institut

Q4 : Liste des instituts ayant au moins deux étudiants dont l’âge est égal a 16.

Q5 : Liste des instituts avec le nombre d’étudiants par institut

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Univéristé de Batna - 05000 - Algérie
Chapitre 5 : Présentation générale DE SQL •213

Q6 : Donnez les noms et âges des étudiants ayant le même âge que l’étudiant ayant le numéro 200.

Q8 : Donnez les noms et âges des étudiants dont l’âge est supérieur a la moyenne d’âge de leur
institut.

Q9 : Donnez les noms et âges des étudiants dont l’âge est supérieur a celui de leur délégué ainsi que
le nom et l’âge de ce délégué.

Q10 : Liste des instituts dont le nombre de délégués est supérieur a 5.

Q11 : Liste des instituts avec le nombre de délégués par institut.

Exercice 3:

Reprendre les exercices du chapitre 4 en exprimant toutes les requêtes algébriques avec SQL

Exercice 4:

Comme SQL ne peut être bien maîtrisé que par la pratique, on vous propose d’utiliser un SGBD
relationnel de votre choix (ACCESS, Oracle, MySQL) et d’implémenter la bases de données de
l’exercice 1 avec les extensions des tables fournies au début du chapitre en utilisant les requêtes SQL
adéquates.

Une fois vos tables créées et remplies, Reprendre les exemples de requêtes données tout au long du
chapitre pour enfin voir les résultats de chacune et s’assurer de leur validité.

Dr. Brahim BELATTAR - Dpt d’informatique – Faculté des Sciences de l’ingénieur - Univéristé de Batna - 05000 - Algérie
Bibliographie

Bibligoraphie

• CARDENAS A. F. , Database Management Systems, ALLYN and BACON Inc., Second Edition ,
USA, 1985
• CARREZ C. , Des structures aux bases de données , DUNOD informatique, France, 1990
• CELKO J. , SQL avancé , (traduction de Martine Chamond), INTENATIONAL THOMSON
PUBLISHING, FRANCE, 1997
• DATE. C. J. , An Introduction to Database Systems, Volume I, Fourth Edition , ADDISON-
WESLEY PUBLISHING COMPANY, 1986
• DELOBEL C. , M. ADIBA , Bases de données et systèmes relationnels, DUNOD informatique,
France, 1982
• GALACSI, Concetin de bases de données : du schéma conceptuel aux schémas physiques, ,
DUNOD informatique, France, 1989
• GALACSI, Les systèmes d’information : Analyse et conception , DUNOD informatique, France,
1989
• GAMACHE A., Logiciels SGBD et bases de données, Les Presses de l’Université LAVAL,
Quebec, 1980
• GARDARIN G., Bases de données : les systèmes et leurs langages, EYROLLES, France, 1982
• KORTH H. F. , SILBERSCHATZ A., Database System Concepts, Second Edition , McGraw-
Hill, Inc., USA, 1991
• MARTIN D. , Techniques avancées pour bases de données , DUNOD informatique, France, 1985
• MIRANDA S., BUSTA J.S., L’art des Bases de données : Tome 2 - Les bases de données
relationnelles, EYROLLES, France, 1986
• ULLMAN J. D. , Principles of Database Systems, Computer Science Press, Second Edition ,
USA, 1982

Dr. Brahim BELATTAR - LISA - Dpt d’informatique - Faculté des sciences de l’Ingénieur - Univ. de Batna - 05000 - Algérie