Université de Tunis El Manar

École Nationale d'Ingénieurs de Tunis

Département Technologies de l'Information et de la Communication

Notes de cours

Bases de Données

par

Minyar Sassi ép. Hidri

29 août 2016
 Table des matières
1 Introduction aux bases de données 1
1.1 Introduction : évolution de données . . . . . . . . . . . . . . . . . . . 2
1.2 Base de données : dénition . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Système de Gestion de Bases de Données . . . . . . . . . . . . . . . . 3
1.4 Dualité SGBD vs SGF . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4.1 Comparaison SGBD - SGF . . . . . . . . . . . . . . . . . . . 3
1.4.2 Organisation des données . . . . . . . . . . . . . . . . . . . . 4
1.5 Architecture d'un SGBD . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5.1 Niveaux de représentation d'une BD . . . . . . . . . . . . . . 5
[Link] Niveau interne . . . . . . . . . . . . . . . . . . . . . 6
[Link] Niveau conceptuel . . . . . . . . . . . . . . . . . . . 6
[Link] Niveau externe . . . . . . . . . . . . . . . . . . . . . 6
1.5.2 Indépendances Physique/Logique . . . . . . . . . . . . . . . . 7
[Link] Indépendance physique . . . . . . . . . . . . . . . . 7
[Link] Indépendance logique . . . . . . . . . . . . . . . . . 7
1.6 Apports des SGBD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.7 Fonctions d'un SGBD . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.8 Les grands acteurs dans le monde des BD : Qui fait quoi ? . . . . . . 9
1.9 Un peu d'histoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.10 Études de cas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.10.1 Étude de cas 1 : Gestion d'une entreprise . . . . . . . . . . . 11
1.10.2 Étude de cas 2 : Gestion de stock . . . . . . . . . . . . . . . . 11

2 Le modèle Entités/Relations 13
2.1 Entités et classes d'entités . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Relations et classes de relations . . . . . . . . . . . . . . . . . . . . . 14
2.2.1 Dénition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.2 Rôle d'une classe d'entités dans une relation . . . . . . . . . . 15
2.2.3 Attribut d'une relation . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Contraintes structurelles . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.1 Contraintes de cardinalité . . . . . . . . . . . . . . . . . . . . 15
2.3.2 Contraintes de participation . . . . . . . . . . . . . . . . . . . 17
2.3.3 Modélisation des contraintes . . . . . . . . . . . . . . . . . . . 17
2.4 Identiants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5 Étapes à suivre pour dénir un modèle E/R . . . . . . . . . . . . . . 18
2.6 Représentation graphique d'un modèle E/R . . . . . . . . . . . . . . 18
2.7 Généralisation et hiérarchie . . . . . . . . . . . . . . . . . . . . . . . 19
2.8 Études de cas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.8.1 Étude de cas 1 : Gestion d'une entreprise . . . . . . . . . . . 20
2.8.2 Étude de cas 2 : Gestion de stock . . . . . . . . . . . . . . . . 20
 TABLE DES MATIÈRES

3 Le modèle relationnel 22
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Concepts de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.1 Domaine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.2 Attribut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.3 Relation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.4 Représentation d'une relation . . . . . . . . . . . . . . . . . . 24
3.2.5 Schéma de relation . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.6 Caractéristiques d'une relation . . . . . . . . . . . . . . . . . 25
3.3 Notations utilisées dans un contexte de modèle relationnel . . . . . . 25
3.4 Attribut clé d'une relation . . . . . . . . . . . . . . . . . . . . . . . . 25
3.5 Contraintes d'intégrité sur un schéma relationnel . . . . . . . . . . . 26
3.6 Traduction d'un modèle E/A en modèle relationnel . . . . . . . . . . 26
3.6.1 Traduction des entités . . . . . . . . . . . . . . . . . . . . . . 26
3.6.2 Traduction des associations . . . . . . . . . . . . . . . . . . . 27
[Link] Traduction des associations binaires . . . . . . . . . 27
[Link] Traduction des associations n-aires . . . . . . . . . . 29
3.6.3 Traduction du lien is-a . . . . . . . . . . . . . . . . . . . . . . 30
3.7 Études de cas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.7.1 Étude de cas 1 : Gestion d'une entreprise . . . . . . . . . . . 32
3.7.2 Étude de cas 2 : Gestion de stock . . . . . . . . . . . . . . . . 32

4 L'algèbre relationnelle 34
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2 Opérateurs ensemblistes . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.1 Union . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.2 Intersection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.3 Diérence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.4 Produit cartésien . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3 Opérateurs spéciques aux BD relationnelles . . . . . . . . . . . . . . 36
4.3.1 Sélection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3.2 Projection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3.3 Séquences d'opérations . . . . . . . . . . . . . . . . . . . . . . 38
4.3.4 Renommage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3.5 Jointure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3.6 Division relationnelle . . . . . . . . . . . . . . . . . . . . . . . 41
4.4 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.5 Fonctions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.5.1 Fonctions arithmétiques . . . . . . . . . . . . . . . . . . . . . 42
4.5.2 Fonctions de groupe . . . . . . . . . . . . . . . . . . . . . . . 42
4.5.3 Fonctions sur caractères . . . . . . . . . . . . . . . . . . . . . 44

ii
TABLE DES MATIÈRES

5 Normalisation d'une base de données relationnelle 45

5.1 Introduction : Inconvénients soulevés par une mauvaise perception du
réel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.2 Dépendance fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . 47
5.2.1 Dénition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.2.2 Propriétés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.2.3 Dépendance fonctionnelle élémentaire . . . . . . . . . . . . . 48
5.2.4 Dépendance fonctionnelle canonique . . . . . . . . . . . . . . 48
5.2.5 Clé d'une relation . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.2.6 Graphe de dépendances fonctionnelles . . . . . . . . . . . . . 48
5.2.7 Fermeture transitive et couverture minimale . . . . . . . . . . 49
5.2.8 Méthodes formelle de décomposition . . . . . . . . . . . . . . 49
5.3 Dénitions des trois premières formes normales . . . . . . . . . . . . 49
5.3.1 Première forme normale (1FN) . . . . . . . . . . . . . . . . . 50
5.3.2 Deuxième forme normale (2FN) . . . . . . . . . . . . . . . . . 50
5.3.3 Troisième forme normale (3FN) . . . . . . . . . . . . . . . . . 50
5.4 Forme normale de Boyce-Codd . . . . . . . . . . . . . . . . . . . . . 50
5.5 Algorithme de décomposition en 3FN . . . . . . . . . . . . . . . . . . 51

6 SQL : un langage de BD relationnelle 52

6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.2 Dénition de données en SQL : le LDD . . . . . . . . . . . . . . . . . 53
6.2.1 Création d'une table . . . . . . . . . . . . . . . . . . . . . . . 53
6.2.2 Modication d'une table . . . . . . . . . . . . . . . . . . . . . 54
6.2.3 Suppression d'une table . . . . . . . . . . . . . . . . . . . . . 55
6.3 Manipulation de données en SQL : le LMD . . . . . . . . . . . . . . 56
6.3.1 Insertion de tuples . . . . . . . . . . . . . . . . . . . . . . . . 56
6.3.2 Modication de tuples . . . . . . . . . . . . . . . . . . . . . . 56
6.3.3 Suppression de tuples . . . . . . . . . . . . . . . . . . . . . . 56
6.4 Interrogation de données en SQL : LID . . . . . . . . . . . . . . . . . 57
6.4.1 Syntaxe générale d'une requête SQL . . . . . . . . . . . . . . 57
6.4.2 Expression de projection . . . . . . . . . . . . . . . . . . . . . 57
6.4.3 Expression de sélection/ restriction . . . . . . . . . . . . . . . 58
6.4.4 Expression de jointure . . . . . . . . . . . . . . . . . . . . . . 58
6.4.5 Expression de l'union, de l'intersection et de la diérence . . . 59
6.4.6 Les expressions . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.4.7 Alias et fonctions d'agrégation . . . . . . . . . . . . . . . . . 61
6.4.8 Groupement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.4.9 Tri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.4.10 Requêtes imbriquées . . . . . . . . . . . . . . . . . . . . . . . 63
6.4.11 Expression de la division relationnelle . . . . . . . . . . . . . 64
6.4.12 Les requêtes récursives en SQL . . . . . . . . . . . . . . . . . 64
6.5 Contrôle de données en SQL : LCD . . . . . . . . . . . . . . . . . . . 65
6.6 Les vues en SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

iii
 TABLE DES MATIÈRES

6.6.1 Création d'une vue en SQL . . . . . . . . . . . . . . . . . . . 66

6.6.2 Interrogation d'une vue SQL . . . . . . . . . . . . . . . . . . 66
6.6.3 Modication d'une vue SQL . . . . . . . . . . . . . . . . . . . 66
6.6.4 Suppression d'une vue . . . . . . . . . . . . . . . . . . . . . . 67
6.7 Gestion des transactions en langage SQL . . . . . . . . . . . . . . . . 67
6.8 Exemple de script de BD . . . . . . . . . . . . . . . . . . . . . . . . . 67

Bibliographie 73
Index 74

iv
 Table des gures
1.1 Gestion des données avec les SGF. . . . . . . . . . . . . . . . . . . . 4
1.2 Gestion des données avec les SGBD. . . . . . . . . . . . . . . . . . . 4
1.3 Niveaux de représentation d'une BD. . . . . . . . . . . . . . . . . . . 5

2.1 Relation biunivoque. . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2 Relation 1 vers N . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Relation N vers 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 Relation N vers N . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5 Représentation graphique d'une relation. . . . . . . . . . . . . . . . . 18
2.6 Relation EST-UN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.7 Exemple de relation EST-UN. . . . . . . . . . . . . . . . . . . . . . . 20
2.8 Étude de cas 1 : modèle E/R - Gestion d'une entreprise. . . . . . . . 21
2.9 Étude de cas 2 : modèle E/R - Gestion de stock. . . . . . . . . . . . 21

3.1 Représentation d'une relation. . . . . . . . . . . . . . . . . . . . . . . 24

3.2 Traduction d'une entité. . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3 Traduction d'une association Un-à-Un : solution 1. . . . . . . . . . . 28
3.4 Traduction d'une association Un-à-Un : solution 2. . . . . . . . . . . 28
3.5 Traduction d'une association Un-à-Plusieurs. . . . . . . . . . . . . . 29
3.6 Traduction d'une association Plusieurs-à-Plusieurs. . . . . . . . . . . 29
3.7 Traduction d'une association n-aires. . . . . . . . . . . . . . . . . . . 30
3.8 Représentation de l'entité mère et de ses entités lles. . . . . . . . . . 31
3.9 Pas de représentation de l'entité mère. . . . . . . . . . . . . . . . . . 31
3.10 Fusion des entités lles et de l'entité mère. . . . . . . . . . . . . . . . 32
3.11 Étude de cas 1 : modèle relationnel - Gestion d'une entreprise. . . . . 33
3.12 Étude de cas 2 : modèle relationnel - Gestion de stock. . . . . . . . . 33

6.1 Instance de la BD Gestion d'une entreprise. . . . . . . . . . . . . . . 68

 Liste des tableaux
2.1 Représentation graphique d'un modèle E/R. . . . . . . . . . . . . . . 19

4.1 Synthèse des opérateurs de l'algèbre relationnelle. . . . . . . . . . . . 43

4.2 Fonctions arithmétiques. . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3 Fonctions de groupe. . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4 Fonctions sur caractères. . . . . . . . . . . . . . . . . . . . . . . . . . 44
 Chapitre 1

Introduction aux bases de données

Sommaire
1.1 Introduction : évolution de données . . . . . . . . . . . . . . 2
1.2 Base de données : dénition . . . . . . . . . . . . . . . . . . . 2
1.3 Système de Gestion de Bases de Données . . . . . . . . . . . 3
1.4 Dualité SGBD vs SGF . . . . . . . . . . . . . . . . . . . . . . 3
1.4.1 Comparaison SGBD - SGF . . . . . . . . . . . . . . . . . . . 3
1.4.2 Organisation des données . . . . . . . . . . . . . . . . . . . . 4
1.5 Architecture d'un SGBD . . . . . . . . . . . . . . . . . . . . . 5
1.5.1 Niveaux de représentation d'une BD . . . . . . . . . . . . . . 5
1.5.2 Indépendances Physique/Logique . . . . . . . . . . . . . . . . 7
1.6 Apports des SGBD . . . . . . . . . . . . . . . . . . . . . . . . 7
1.7 Fonctions d'un SGBD . . . . . . . . . . . . . . . . . . . . . . . 8
1.8 Les grands acteurs dans le monde des BD : Qui fait quoi ? 9
1.9 Un peu d'histoire . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.10 Études de cas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.10.1 Étude de cas 1 : Gestion d'une entreprise . . . . . . . . . . . 11
1.10.2 Étude de cas 2 : Gestion de stock . . . . . . . . . . . . . . . . 11
 Chapitre 1 : Introduction aux bases de données

1.1 Introduction : évolution de données

+ Données intégrées aux programmes (1950-1960) : on dispose uniquement de
langage machine (Assembleur) qui :
 Dépend du matériel utilisé ;
 Utilise uniquement des variables globales et des constantes.
 À partir de 1956 :
 Naissance des langages de haut niveau et des compilateurs, par exemple
Fortran, Algo, CISP, etc.
 Masse de données traitées très grande ;
 Apparition de notion de chier.
+ Autonomie des données vis-à-vis des programmes : naissance du langage CO-
BOL et des langages de gestion qui utilisent les chiers.
+ Partage et indépendance des données : les problèmes des chiers sont :
 redondance de données ⇒ gaspillage de la mémoire secondaire ;
 risque d'incohérence de données ;
 diculté de maintenance de chiers et par conséquent des programmes qui
les traitent.
Ce qui fait apparaître les concepts de base de données (BD) et de système de
gestion de BD (SGBD) qui permettent :
 La mise en commun des données ;
 Le partage de données entre plusieurs applications et plusieurs utilisateurs :
 La description de ces données selon une structure unique ;
 Une structure hiérarchisée des enregistrements logiques.

1.2 Base de données : dénition

Dénition 1 (Base de données) Une base de données (BD) est une collection de
données opérationnelles et utilisées par les systèmes d'applications (les programmes)
d'une organisation humaine particulière.
Dénition 2 (Base de données) Une base de données (BD) est une collection de
données :
 Structurées indépendamment d'une application particulière ;
 Cohérente ;
 De redondance minimale ;
 Accessible par plusieurs utilisateurs.
L'approche BD est due à une triple évolution :
 Évolution des entreprises (volumes importants de données, centralisées ou ré-
parties, qui doivent être accessibles en temps utile,...) ;
 Évolution du matériel (accroissement des performances, intégration des com-
posants, diminution des coûts,...) ;
 Évolution des logiciels (les systèmes d'exploitation, les architectures client/serveur
et les réseaux).

2
1.3 Système de Gestion de Bases de Données

Considérons l'exemple d'une BD commerciale. Les données sont relatives aux

clients, aux produits, aux commandes, aux lignes de commandes, etc. Les requêtes
sont très variées telles que :
 Quels sont les produits qui ont été commandés par un client déterminé ?
 Quel est le client de la commande numéro X ?
 Quelle est la date de la dernière commande du client s'appelant Y ?

1.3 Système de Gestion de Bases de Données

Dénition 3 (Système de Gestion de Bases de Données (SGBD)) Un SGBD
(ou DBMS : Data Base Management System) peut être déni comme un ensemble
de logiciels permettant de stocker et d'interroger un ensemble de chiers interdépen-
dants. Il peut aussi être déni comme un outil permettant de modéliser et de gérer
les données d'une entreprise.

Ainsi, un SGBD permet à un utilisateur de communiquer avec une BD pour :

 Décrire et organiser les données sur les mémoires secondaires (disques) ;
 Rechercher, sélectionner et modier les données.
Un SGBD ore la possibilité à l'utilisateur de manipuler les représentations
abstraites des données, indépendamment de leur organisation et de leur implantation
sur les supports physiques (mémoires). Il assure :
 La description des données ;
 Leur recherche et mise à jour ;
 La sûreté : sauvegarder et restaurer les données ;
 La sécurité : vérier les droits d'accès des utilisateurs an de limiter les accès
non autorisés ;
 L'intégrité : dénir des règles qui maintiennent l'intégrité de la BD (contraintes
d'intégrité) ;
 La concurrence d'accès : détecter et traiter les cas où il y a conit d'accès
entre plusieurs utilisateurs et les traiter correctement.

1.4 Dualité SGBD vs SGF

Un système organisé autour d'une BD est centré sur les données, contrairement
aux systèmes de gestion de chiers (SGF) basés sur les traitements (par exemple :
traitement de la paye, facturation, gestion des stocks, etc.).

1.4.1 Comparaison SGBD - SGF

Dans l'approche gestion de chiers, les chiers sont dénis pour un ou plusieurs
programmes de traitement. Les données d'un chier sont directement associées à
un programme par une description contenue dans le programme de traitement lui-
même. Il n'existe aucune indépendance entre le programme et les données. Toute
modication de la structure des données nécessite la réécriture du programme.

3
 Chapitre 1 : Introduction aux bases de données

La gure 1.1 illustre la gestion des données avec les SGF.

Figure 1.1  Gestion des données avec les SGF.

Dans l'approche BD, la partie de structuration et de description des données est

uniée et séparée des programmes d'application. Bien sûr la gestion de ces données
(stockage, modication, recherche) qui est étroitement dépendante de leur structu-
ration, est fournie par le système de gestion des données. Les applications ne commu-
niquant avec les données qu'au travers de l'interface de gestion. D'où l'indépendance
entre les données et les applications, qui peuvent être modiées indépendamment.
Le programmeur des applications (l'utilisateur) n'a pas à connaître l'organisation
physique des données.
La gure 1.2 illustre la gestion des données avec les SGBD.

Figure 1.2  Gestion des données avec les SGBD.

1.4.2 Organisation des données

Dans les deux approches, des chiers de données sont constitués, permettant le
stockage, l'organisation et l'accès aux diérents enregistrements. Ces chiers peuvent
être accéder selon diérentes méthodes :

4
1.5 Architecture d'un SGBD

 Méthodes d'accès séquentielles : consistant à lire successivement tous les en-

registrements d'un chier depuis le premier jusqu'à l'enregistrement désiré ;
 Méthodes d'accès sélectives : permettant de lire/écrire tout article au moyen
de quelques accès disques, y compris pour de très gros chiers ;
 Méthodes d'accès par hachage : basées sur l'utilisation d'une fonction de calcul
qui, appliquée à la clé, détermine l'adresse relative d'une zone appelée paquet
dans laquelle est placé l'article ;
 Méthodes d'accès indexées : consistant à associer à la clé d'un enregistrement
son adresse relative dans le chier à l'aide d'une table des matières appelée
index du chier. Ainsi, à partir de la clé de l'enregistrement, un accès rapide
est possible par recherche de l'adresse relative dans la table des matières, puis
par un accès en relatif à l'enregistrement dans le chier.

1.5 Architecture d'un SGBD

1.5.1 Niveaux de représentation d'une BD
La description d'une BD peut se faire à diérents niveaux, suivant que l'on
regarde plus du coté de l'utilisateur que du coté du stockage physique des données
sur les supports disques ou bandes magnétiques.
Il est couramment admis aujourd'hui qu'il existe trois niveaux de représentation
d'une BD à savoir :
 Le niveau interne avec le schéma physique ;
 Le niveau conceptuel avec le schéma conceptuel ;
 Le niveau externe avec les schémas externes.
Dans une telle représentation, seule la BD physique a une existence matérielle,
les autres niveaux correspondent à des représentations décrites en termes abstraits
qui servent de référentiel à son utilisation.
La gure 1.3 illustre les niveaux de représentation d'une BD.

Figure 1.3  Niveaux de représentation d'une BD.

5
 Chapitre 1 : Introduction aux bases de données

[Link] Niveau interne

Ce niveau dénit le schéma physique qui a pour but de spécier comment les
données seront stockées sur les organes périphériques (disque, bande, etc.) de l'or-
dinateur.

[Link] Niveau conceptuel

Le schéma conceptuel est la partie fondamentale dans l'architecture d'un système
de BD. Il a pour but de décrire en terme abstrait mais dèle une certaine réalité
d'une organisation et de ses processus de gestion qui nécessitent la mise en ÷uvre
d'une BD.
Le passage du monde réel au schéma conceptuel correspond à un processus de
modélisation où les objets du monde réel sont classés en catégories et désignés par
des noms.
Le SGBD fournit un langage de dénition de données (LDD) qui permet de
spécier le schéma conceptuel selon un modèle approprié.
On diérencie quatre grandes classes de modèles de données qui se distinguent
par la nature des associations qu'ils permettent de modéliser :
 Le modèle hiérarchique : il permet de représenter des classes ou ensembles
d'objets et des relations de type père-ls entre ces classes. L'ensemble de ces
classes constitue une arborescence. Les SGBDs supportant ce type de structure
gèrent les liens entre un père et ses ls. Ils orent des primitives pour manipuler
et naviguer dans de telles structures ;
 Le modèle réseau : il permet également la représentation de classes d'objets et
de liens de type père-ls entre ces classes. Comme son nom l'indique, et à la
diérence du modèle hiérarchique, il autorise une classe lle à avoir plusieurs
classes mères. Les langages de ces SGBD sont aussi de type navigationnel ;
 Le modèle relationnel : en 1970, TED Codd, chercheur chez IBM, a proposé le
modèle relationnel. Ce modèle conceptuel constitue un progrès important car
il repose sur une représentation uniée de l'information sous forme de tables.
Il dispose d'un fondement mathématique solide avec l'algèbre relationnelle.
Il permet une plus grande indépendance entre les applications, les données
et le support physique. Il propose une démarche cohérente et uniée pour la
description et pour l'interrogation ;
 Le modèle Entités/Relations ou Entités/Associations : il facilite la dénition
du modèle relationnel par l'intermédiaire des règles de migration.

[Link] Niveau externe

Le niveau externe est propre à chaque utilisateur ou plutôt à chaque program-
meur d'application.
Ce niveau correspond à la vision de tout ou d'une partie du schéma conceptuel
par un groupe d'utilisateurs concerné par une application et chargé de mettre en
÷uvre des programmes d'utilisation.

6
1.6 Apports des SGBD

Il s'agit donc de décrire, à l'aide d'un schéma externe, parfois appelé vue, la façon
dont seront perçues les données par un programme d'application. Dans ce sens, un
schéma externe ou une vue peut être considérée comme un sous schéma du schéma
conceptuel.

1.5.2 Indépendances Physique/Logique

[Link] Indépendance physique
Un des objectifs essentiels des SGBD est de permettre de réaliser l'indépendance
des structures de stockage aux structures de données du monde réel, c'est-à-dire entre
le schéma interne et le schéma conceptuel.
Le schéma interne et le schéma conceptuel décrivent les données, mais à des
niveaux diérents. L'indépendance physique permet donc de modier le schéma
interne sans avoir à modier le schéma conceptuel, en tenant compte seulement des
critères de performance et de exibilité d'accès.
On pourra par exemple ajouter un index, regrouper deux chiers en un seul,
changer l'ordre ou le codage des données dans un enregistrement, sans mettre en
cause les entités et les associations dénies au niveau conceptuel.

[Link] Indépendance logique

Le schéma conceptuel résulte d'une synthèse des vues particulières de chaque
groupe de travail utilisant la BD, c'est-à-dire d'une intégration de schémas externes.
Ainsi, chacun doit pouvoir se concentrer sur les éléments constituant son centre
d'intérêt, c'est-à-dire qu'un utilisateur ne doit pouvoir connaître qu'une partie des
données de la base au travers de son schéma externe, encore appelé vue.
L'indépendance logique est donc la possibilité de modier un schéma externe
(une vue) sans modier le schéma conceptuel. Elle assure aussi l'indépendance entre
les diérents utilisateurs, chacun percevant une partie de la base via son schéma
externe, selon une structuration voir un modèle particulier.
Il doit par exemple être possible d'ajouter des attributs, d'en supprimer d'autres,
d'ajouter et de supprimer des associations, d'ajouter ou de supprimer des entités
dans des schémas externes sans modier la plus grande partie des applications

1.6 Apports des SGBD

Les avantages des SGBD par rapport aux systèmes traditionnels (méthodes pa-
pier ou approche de gestion de chiers) sont :
 Compacité : plus besoin de chiers volumineux ;
 Rapidité : le système est capable de retrouver et de mettre à jour les données
beaucoup plus rapidement que de manière manuelle ou avec un système de
gestion de chiers ;
 Moins de corvées : les travaux ennuyeux de maintenance manuelle des chiers
sont éliminés ;

7
 Chapitre 1 : Introduction aux bases de données

 Exactitude : des informations précises et réactualisées sont disponibles à tout

moment.
De plus, le contrôle centralisé des données dans une BD a pour résultat certains
autres avantages tels que :
 Les données peuvent être partagées : partager ne signie pas seulement que
les opérations existantes peuvent partager les données de la BD, mais égale-
ment que de nouvelles opérations peuvent être développées pour manipuler ces
mêmes données. En d'autres termes, il est possible de satisfaire les besoins des
données des nouvelles applications sans avoir à ajouter de nouvelles données
dans la base de données ;
 La redondance peut être réduite : dans les systèmes autres que les BDs, chaque
application possède ses propres chiers, ce qui peut conduire à une très grande
redondance des données ;
 L'incohérence peut être évitée : c'est une conséquence du point précédent ;
 Les transactions peuvent être gérées : une transaction est une unité logique
de travail qui réalise, en général, plusieurs opérations sur la BD ;
 L'intégrité peut être assurée : le problème de l'intégrité consiste à assurer
l'exactitude des données de la BD ;
 La sécurité peut être appliquée : c'est le fait de dénir des contraintes ou des
règles de sécurité qui sont contrôlées chaque fois que l'on essaye d'accéder à
des données sensibles.

1.7 Fonctions d'un SGBD

Un SGBD est un ensemble d'outils logiciels permettant la création et l'utilisation
des BD. Il doit assurer les fonctions suivantes :
 Description : le SGBD doit orir à l'utilisateur un outil pour décrire l'ensemble
des données qui seront stockées dans la BD. Cet outil constitue généralement
ce qu'on appelle le langage de description de données (LDD) ;
 Manipulation : la fonction de manipulation est celle qui a pour but d'orir
à l'utilisateur une interaction avec la BD sous forme d'un dialogue pour re-
chercher, sélectionner et modier des données. Cette fonction est réalisée par
le langage de manipulation de données (LMD) qui permet de manipuler les
données de la base en temps réel ;
 Intégrité : plus la masse d'informations enregistrées dans une BD est grande,
plus le risque que la donnée enregistrée soit erronée par rapport à la réalité
est grand. Pour diminuer ce risque, un SGBD doit orir à l'utilisateur la
possibilité de dénir des règles qui permettent de maintenir l'intégrité de la
BD. Ces règles sont appelées contraintes d'intégrité (C.I). Elles correspondent
à des propriétés qui devront toujours être vériées dans la BD quelles que
soient les valeurs enregistrées.
Par exemple, dans une BD universitaire, les notes des étudiants doivent être
entre 0 et 20.

8
1.8 Les grands acteurs dans le monde des BD : Qui fait quoi ?

 Condentialité : si un BD est partagée entre plusieurs utilisateurs, certains

sous-ensembles ne doivent être accessibles que par des personnes réellement
autorisées.
Pour cela, le SGBD doit orir des mécanismes permettant de vérier les droits
d'accès des utilisateurs. Par exemple, une personne travaillant dans le service
de la scolarité ne devra pas être autorisée à accéder aux informations contenues
dans le chier des enseignants concernant l'historique de ses services et son
indice de rémunération.
 Concurrence d'accès : bien souvent les programmes d'applications des utilisa-
teurs accèdent aux mêmes informations de la BD en même temps. Le SGBD
doit orir des mécanismes qui permettent de détecter les cas où il y aurait
conit d'accès et de les traiter correctement.
 Sécurité de fonctionnement : en cas d'incident ayant pour origine le matériel
ou le logiciel, la BD n'est plus opérationnelle. An d'assurer le redémarrage
du système lorsque l'incident a été supprimé, le SGBD doit permettre la prise
de point de contrôle pour remettre la BD dans un état satisfaisant.
 Aide d'utilisation : diverses interfaces constituent des outils utilitaires parmi
lesquelles on trouve :
 un utilitaire de chargement initial de la BD ;
 établissement des statistiques de la BD.

1.8 Les grands acteurs dans le monde des BD : Qui fait

quoi ?
On distingue quatre types d'acteurs dans un environnement de BD :
 Les concepteurs d'une BD :
 Choix des données et des structures de données ;
 Rencontres avec les usagers et analyse des besoins ;
 Interactions postérieur à la conception avec les usagers pour l'élaboration
de vues spéciques répondant à de nouveaux besoins .
 Les administrateurs de la BD (DBAs) :
 Gestion des ressources partagées par plusieurs personnes ;
 Autorisation d'accès à la BD ;
 Responsabilité de la BD aussi bien au niveau Contenant-Contenu que Protection-
Sécurité ;
 Il est chargé du fonctionnement de la BD et surtout de son évolution depuis
sa conception ;
 Il peut être assisté dans sa tâche par une équipe d'intervenant spécialistes.
 Les analystes et les programmeurs :
 Analystes de systèmes : déterminent les besoins des usagers et les traduisent
en spécications correspondantes ;
 Programmeurs d'applications : transforment les spécications précédentes
en programmes qu'ils doivent ensuite tester, mettre au point, documenter

9
 Chapitre 1 : Introduction aux bases de données

et maintenir ;
 Nécessité pour ces deux types d'acteurs de maîtriser les possibilités du
SGBD pour un accomplissement ecace de leurs tâches.
 Les utilisateurs naux de la BD : accès à la BD pour l'interrogation (requêtes),
la mise à jour et l'édition de rapports divers. On distingue généralement plu-
sieurs catégories d'usagers :
 Occasionnels : accès occasionnels à la BD pour l'obtention d'informations
très variées. Ce sont les plus souvent des cadres moyens ou supérieurs avec
un grand pouvoir de décision ;
 Novices : c'est la plus grande partie des utilisateurs. Leurs activités essen-
tielles concernent la mise à jour et l'interrogation de la BD à l'aide de requête
standards pre-programmées et testées ;
 Experts : ce sont les ingénieurs, scientiques, analystes de gestion, etc. Ils
sont très familiers à l'utilisation et aux possibilités du SGBD.

1.9 Un peu d'histoire

 1961 :
 Apparition du système Integrated Data Storage (General Electric) conçu
par Bachman.
La terminologie utilisée sera à la base du modèle réseau développé par CO-
DASYL DBTG (Conference on Data Systems and Languages Data Base
Task Group).
 1965-1970 :
 Développement de systèmes de gestion de chiers généralisés ;
 Développement, par IBM, du modèle hiérarchique ;
 Apparition de IBM DB/DC (database/datacom) qui supporte le modèle
réseau au dessus du modèle hiérarchique.
 1970 : Apparition du modèle relationnel de données développé par TED CODD.
 1972 :
 Première conférence internationale organisée par l'association of computing
machinery ;
 Special Interest Group on Management Of Data (ACM SIGMOD).
 1975-1980 :
 Première conférence internationale Very Large Data Base (VLDB) ;
 Publication du rapport ANSI-SPARC
 Apparition du modèle Entités/Associations ;
 Développement de systèmes relationnels expérimentaux : SYSTEM-R (IBM),
langage SQUARE, SEQUEL,SQL, INGRES, QUEL.
 Les années 80 :
 Nombreux SGBD relationnels commercialisés ;
 Nombreuses réalisations de systèmes de quatrième génération avec des outils
et des interfaces multiples.

10
1.10 Études de cas

 Les orientations actuelles :

 BDs réparties ;
 BDs déductives ;
 BDs sémantiques ;
 BDs orientées objet ;
 BDs objet-relationnelles ;
 BDs multimédias.

1.10 Études de cas

1.10.1 Étude de cas 1 : Gestion d'une entreprise
La BD Gestion d'une entreprise a pour but de gérer les employés, les départe-
ments et les projets d'une entreprise. On se propose de concevoir une BD pour cette
entreprise.
Au terme de cette première phase les concepteurs aboutissent aux spécications
suivantes :
 Un département possède un nom, un numéro et un directeur dont la date
d'entrée en fonction est mémorisée. Un département est identié par son nu-
méro de département. Un département peut être localisé à diérents endroits
géographiques.
 Un département est responsable d'un certain nombre de projets. Chaque projet
est caractérisé par un nom, un numéro et une localisation unique. Un projet
est identié par son numéro de projet.
 Chaque employé est caractérisé par son nom, son prénom, son numéro d'assu-
rance, son adresse, son salaire, son sexe et sa date de naissance. Un employé
est identié par son numéro d'assurance.
Un employé est toujours rattaché à un seul département mais peut travailler
sur plusieurs projets non nécessairement rattachés à un seul département.
Le nombre d'heures par semaine passé par un employé sur chaque projet est
mémorisé. À chaque employé correspond un superviseur responsable.
 Pour chaque employé, on désire également conserver le prénom, le sexe, la date
de naissance et la relation de liation de chacune de ses personnes à charges.
On suppose que les prénoms des personnes à charges d'un même employé sont
distincts.

1.10.2 Étude de cas 2 : Gestion de stock

Il s'agit de concevoir une BD pour la gestion de stock d'une société informatique.
La société gère les clients, des commandes passées par ces clients et des pro-
duits commandés par ces clients. Ces produits ont été achetés de chez plusieurs
fournisseurs.
Pour chaque client on désire mémoriser son numéro de carte d'identité (identi-
eur), son nom, son prénom, son adresse et son numéro de téléphone. Un client peut

11
 Chapitre 1 : Introduction aux bases de données

passer plusieurs commandes.

Pour chaque commande passée par un client, on désire mémoriser son numéro
(identieur), sa date de commande et son état. Une commande peut porter sur
plusieurs produits.
Chaque produit sera décrit par une ligne de commande. Une commande est
formée par plusieurs lignes de commandes. Dans chaque ligne de commande, on
précise le numéro de la ligne de commande, le code du produit commandé ainsi que
la quantité commandée de ce produit.
Un produit est identié par un code (identieur), un libellé, un prix, une quantité
seuil (stock limite du produit) et la quantité dans le stock. Ces produits ont été
achetés de chez plusieurs fournisseurs.
Un fournisseur est décrit par un code (identieur), un nom, une adresse et un
numéro de téléphone. Chaque fournisseur doit fournir un ou plusieurs produits au
stock de la société. On suppose qu'un produit est fourni par un seul fournisseur.
La société dispose d'un ensemble de règles de gestion dénies comme suit :
1. Une commande ne peut être passée que par un seul client ;
2. Une commande peut inclure plusieurs produits et, dans tous les cas, elle en
inclut au moins un. Un produit peut apparaître plusieurs fois dans une même
commande ;
3. Un produit peut faire l'objet de plusieurs commandes diérentes. Il peut éga-
lement exister dans la base sans n'avoir jamais été commandé.
4. L'état de la commande peut prendre l'une des trois valeurs :
 CE : Commande En-cours ;
 CLI : Commande Livrée ;
 CNLI : Commande Non Livrée.
L'état de la commande prend en premier lieu une valeur par défaut CE. Si
toutes les quantités des produits gurants dans la commande peuvent être livrées
pour la commande (QTESTK > QTE SEUIL après décrémentation), alors l'état de
la commande = CLI sinon : dans le cas où la quantité en stock d'un produit devient
<= QTE SEUIL, les mises à jour de cette commande sont annulées et l'état de la
commande = CNLI.

12
 Chapitre 2

Le modèle Entités/Relations

Sommaire
2.1 Entités et classes d'entités . . . . . . . . . . . . . . . . . . . . 14
2.2 Relations et classes de relations . . . . . . . . . . . . . . . . . 14
2.2.1 Dénition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.2 Rôle d'une classe d'entités dans une relation . . . . . . . . . . 15
2.2.3 Attribut d'une relation . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Contraintes structurelles . . . . . . . . . . . . . . . . . . . . . 15
2.3.1 Contraintes de cardinalité . . . . . . . . . . . . . . . . . . . . 15
2.3.2 Contraintes de participation . . . . . . . . . . . . . . . . . . . 17
2.3.3 Modélisation des contraintes . . . . . . . . . . . . . . . . . . 17
2.4 Identiants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5 Étapes à suivre pour dénir un modèle E/R . . . . . . . . . 18
2.6 Représentation graphique d'un modèle E/R . . . . . . . . . 18
2.7 Généralisation et hiérarchie . . . . . . . . . . . . . . . . . . . 19
2.8 Études de cas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.8.1 Étude de cas 1 : Gestion d'une entreprise . . . . . . . . . . . 20
2.8.2 Étude de cas 2 : Gestion de stock . . . . . . . . . . . . . . . . 20
 Chapitre 2 : Le modèle Entités/Relations

2.1 Entités et classes d'entités

La structure Entités/Relations repose sur une perception du monde réel sous
forme d'un ensemble d'objets appelés entités associés au moyen d'un ensemble de
relations entre ces objets.

Dénition 1 (Entité) Une entité est un objet existant et discernable d'autres ob-
jets. Chaque entité possède des propriétés particulières appelées attributs qui per-
mettent de la décrire.
Elle est dénie par un ensemble d'attributs. Pour chaque attribut, il existe un
ensemble de valeurs autorisées que l'on appelle domaine de l'attribut. Chaque entité
est ainsi dénie par un ensemble de paires (attribut, valeur)

Dénition 2 (Classe d'entités) On appelle classe d'entités un ensemble d'enti-

tés possédant toutes les mêmes attributs (de valeurs diérentes pour chacune). Un
attribut peut être de type simple ou de type composé

Dénition 3 (Attribut) On appelle :

 Attribut mono-valué : un attribut à valeur simple ;
 Attribut multi-valué : un attribut à plusieurs valeurs possibles ;
 Attribut dérivé ou dérivable : un attribut dont la valeur est déduite de la valeur
d'un autre attribut :
 de la même entité ;
 d'une même entité.
 Attribut à valeur nulle : un attribut dont la valeur peut être absente.

2.2 Relations et classes de relations

2.2.1 Dénition
Dénition 4 (Relation/Association) Une relation ou association représente un
lien (sémantique) entre une occurrence d'une classe d'entités appelée Maître et un
ensemble d'occurrences d'une autre classe d'entités appelées Membres.
Étant donné une suite d'ensembles E1 , E2 ,..,EN , on appelle une relation R sur
cette suite un sous-ensemble du produit cartésien E1 × E2 × .. × EN .
On note : R(E1 , E2 , .., EN ) (N ≥ 2).
Si N = 2, la relation est dire binaire.
Si N = 3, la relation est dite ternaire.
De manière générale, la relation est dire N-aire.

Dénition 5 (Classe de relations) Une classe de relations rassemble des rela-

tions de même type.

14
2.3 Contraintes structurelles

2.2.2 Rôle d'une classe d'entités dans une relation

Chaque classe d'entités participant à une relation peut y jouer un rôle particulier.
Le nom du rôle traduit le rôle que joue une entité participant dans chacune des
instances d'une relation.

2.2.3 Attribut d'une relation

Une relation peut être caractérisée par des attributs qui participent à sa déni-
tion.

2.3 Contraintes structurelles

Les contraintes structurelles d'une relation ou d'une classe de relations traduisent
la situation du monde réel et les besoins des usagers.

Les contraintes structurelles= Les contraintes de cardinalité + Les contraintes de

participation

2.3.1 Contraintes de cardinalité

Dénition 6 (Cardinalité) Les cardinalités des relations dénissent le nombre
d'entités auxquelles est associée une entité donnée au moyen de la relation considé-
rée.

Dans le cas d'un ensemble R de relations binaires entre deux classes d'entités A
et B , on peut avoir les cardinalités suivantes :
 Lien 1 :1 - Lien biunivoque ou Biunivocité (one to one)
Une (1) entité de A est associée à une (1) seule entité de B , est réciproquement.
La gure 2.1 illustre la relation biunivoque.

Figure 2.1  Relation biunivoque.

 Lien 1 vers N - Lien hiérarchique (one to many)

Une entité de A est associable à N entités de B (N ≥ 1). Par contre, une entité
de B n'est associée qu'à une entité de A.
La gure 2.2 illustre la relation hiérarchique.

15
 Chapitre 2 : Le modèle Entités/Relations

Figure 2.2  Relation 1 vers N .

 Lien N vers 1 - Lien fonctionnel (many to one)

Une entité de A est associable à une seule entité de B , tant disque une entité de
B peut être associée à N (N > 1) entité de A.
La gure 2.3 illustre la relation N vers 1.

Figure 2.3  Relation N vers 1.

 Lien N vers N (many to many)

Une entité de A est associable à N entités de B (N > 1) et réciproquement, une
entité de B est associable à N entités de A (N > 1).
La gure 2.4 illustre la relation N vers N .

Figure 2.4  Relation N vers N .

16
2.4 Identiants

2.3.2 Contraintes de participation

Ces contraintes permettent de dénir si l'existence d'une entité dépend de l'autre
entité à laquelle est associée dans un classe de relations.
La participation d'une entité à une relation peut être totale ou partielle.

2.3.3 Modélisation des contraintes

Pour modéliser les contraintes structurelles, on associe un couple (M in, M ax) à
chaque participation d'une classe d'entités E à une classe de relations R et tels que
0 ≤ M in ≤ M ax et M ax ≥ 1.
Chacune des entités e de E participe toujours à :
 au moins M in fois ;
 au plus M ax fois à la relation R.
Si M in = 0 alors la participation est partielle.
Si M in > 0 alors la participation est totale.

2.4 Identiants
Il est important de diérencier correctement les entités et les relations que l'on
crée lors de l'élaboration d'une BD.
On assigne un identieur à chaque classe d'entités au sein d'une BD.

Dénition 7 (Identieur/Identieur minimal/Identieur privilégié) Un iden-

tieur est un ensemble d'attributs qui permet, par son collectif d'attributs, d'identier
de façon unique une entité dans sa classe.
Lors de l'utilisation d'un identieur, on cherche souvent un identieur minimal
dont aucun sous-ensemble ne peut être lui même un identieur.
Les identieurs minimaux sont appelés identieurs privilégiés.

Dénition 8 (Identieur primaire ou Clé primaire) Nous désignons par iden-

tieur primaire, ou clé primaire, un identieur privilégié retenu par le créateur de
la BD comme descripteur des entités d'une classe donnée.

Dénition 9 (Entité faible/forte) Une entité est dite faible si elle ne possède
pas assez d'attributs pour permettre de lui aecter une clé primaire.
Une entité est dite forte si elle possède une clé primaire.

La relation qui lie une entité faible à son entité forte associée (propriétaire) est
appelée relation d'identication.
Une entité faible ne possède pas d'identieur primaire, cependant, il faut bien la
diérencier au sein de l'ensemble des entités faibles auxquelles elle appartient. On
appelle clé partielle d'une entité faible un jeu d'attributs qui permet cette distinction.
Remarques :
17
 Chapitre 2 : Le modèle Entités/Relations

1. Toute entité faible peut être convertie en une entité forte par adjonction d'at-
tributs appropriés. Le choix du mode de représentation (entité faible ou forte)
est laissé au concepteur d'application.
2. Toute entité faible peut quelquefois être remplacée par un attribut composé
multi-valué.
3. En général, le nombre de niveaux d'entités faibles peut être quelconque :
 une entité propriétaire peut être elle même une entité faible ;
 une entité faible peut être associée à plusieurs entités propriétaires et la
relation d'identication peut être de degré supérieur à 2.

2.5 Étapes à suivre pour dénir un modèle E/R

A) Entités / Classes d'entités
1. déterminer les entités et les classes d'entités nécessaires ;
2. déterminer les attributs de ces classes d'entités.
B) Ranement de la modélisation après l'introduction du concept relation
Durant les premiers pas du processus de conception, il est parfois pratique de
représenter certaines relations par des attributs pour les convertir ensuite lors
des ranements successifs du modèle. On suit dans ce cas les étapes suivantes :
1. transformer des attributs qui représentent des relations en classes de re-
lations ;
2. déduire les cardinalités et les contraintes de participation pour chaque
classe de relations à partir des spécications précédentes ;
3. si des doutes persistent encore sur certaines cardinalités ou dépendances,
alors on revient au usagers pour éclaircissements.

2.6 Représentation graphique d'un modèle E/R

Le tableau 2.1 présente la représentation graphique d'un modèle E/R.
Un deuxième type de représentation pet être envisagé. La gure 2.5 illustre la
représentation graphique d'une relation entre deux entités.

Figure 2.5  Représentation graphique d'une relation.

Dans la suite de ce cours, nous allons suivre la représentation graphique d'une

relation du modèle E/R de la gure 2.5.

18
2.7 Généralisation et hiérarchie

Table 2.1  Représentation graphique d'un modèle E/R.

Symbole Signication

Classe d'entité type forte

Classe d'entité type faible

Relation

Relation d'identication (pour une entité faible)

Attribut (d'une relation ou d'une entité)

Attribut clé

Attribut multi-valué

Attribut composé

Attribut dérivé
Les lignes relient les classes d'entités aux attributs et les classes d'entités
aux classes de relations

Contraintes structurelles (M in, M ax) de la participation de E à R

2.7 Généralisation et hiérarchie

Un ensemble d'entités E1 est un sous-ensemble de E2 si toute occurrence de E1

est aussi une occurrence de E2 . L'ensemble d'entités E1 hérite des attributs de E2 .

Un ensemble d'entités E est une généralisation de E1 , E2 , EN si chaque occur-

rence de E est aussi une occurrence d'une et une seule entité E1 , E2 , ..., EN . Les
ensembles E1 , E2 , ..., EN sont des spécialisations de l'ensemble d'entités E . Les
ensembles d'entités E1 , E2 , EN héritent des attributs de E et possèdent en outre
des attributs spéciques qui expriment leur spécialisation.

Notation : EST-UN (IS A) : B EST-UN A si l'ensemble A est une extension

de B ou B un cas particulier de A.

La gure 2.6 illustre la relation EST-UN.

Exemple : La gure 2.7 illustre l'ensemble des Véhicules est une généralisation
de l'ensemble des Automobiles et des Cycles.

19
 Chapitre 2 : Le modèle Entités/Relations

Figure 2.6  Relation EST-UN.

Figure 2.7  Exemple de relation EST-UN.

2.8 Études de cas

2.8.1 Étude de cas 1 : Gestion d'une entreprise
Le modèle E/R de l'étude de cas 1 décrit dans le chapitre 1 est illustré par la
gure 2.8.

2.8.2 Étude de cas 2 : Gestion de stock

Le modèle E/R de l'étude de cas 2 décrit dans le chapitre 1 est illustré par la
gure 2.9.

20
2.8 Études de cas

Figure 2.8  Étude de cas 1 : modèle E/R - Gestion d'une entreprise.

Figure 2.9  Étude de cas 2 : modèle E/R - Gestion de stock.

21
 Chapitre 3

Le modèle relationnel

Sommaire
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Concepts de base . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.1 Domaine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.2 Attribut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.3 Relation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.4 Représentation d'une relation . . . . . . . . . . . . . . . . . . 24
3.2.5 Schéma de relation . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.6 Caractéristiques d'une relation . . . . . . . . . . . . . . . . . 25
3.3 Notations utilisées dans un contexte de modèle relationnel 25
3.4 Attribut clé d'une relation . . . . . . . . . . . . . . . . . . . . 25
3.5 Contraintes d'intégrité sur un schéma relationnel . . . . . . 26
3.6 Traduction d'un modèle E/A en modèle relationnel . . . . . 26
3.6.1 Traduction des entités . . . . . . . . . . . . . . . . . . . . . . 26
3.6.2 Traduction des associations . . . . . . . . . . . . . . . . . . . 27
3.6.3 Traduction du lien is-a . . . . . . . . . . . . . . . . . . . . . . 30
3.7 Études de cas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.7.1 Étude de cas 1 : Gestion d'une entreprise . . . . . . . . . . . 32
3.7.2 Étude de cas 2 : Gestion de stock . . . . . . . . . . . . . . . . 32
3.1 Introduction

3.1 Introduction
Le modèle relationnel a été introduit par TED Codd en 1970. Il est basé sur des
concepts très simples. L'objectif essentiel de ce modèle était d'accroître l'indépen-
dance vis-à-vis de la représentation de données.
De point de vue de l'utilisateur, une BD peut être considérer comme un ensemble
de tableaux manipulables par des langages de haut-niveau dont la caractéristique
essentielle est d'être des langages non-procédureaux.

Dénition 1 (BD relationnelle) Une BD relationnelle (BDR) se compose d'un

ensemble de tableaux dont chacun est libellé de façon unique.
Chaque tableau est de structure semblable à celle rencontrée dans le modèle E/R
lorsque nous avons représenté les objets au moyen des entités.

3.2 Concepts de base

3.2.1 Domaine
Dénition 2 (Domaine) Un domaine est un ensemble de valeurs caractérisées par
un nom.

Exemple :
 D1 = Ensemble des entiers ;
 D2 = Ensemble de chaînes de caractères.

3.2.2 Attribut
Un attribut est une variable prenant ses valeurs dans un domaine. C'est une
colonne d'une relation caractérisée par un nom.
Exemple :
 attribut A1 = N Cl à valeurs dans D1 ;
 attribut A2 = N omCl à valeurs dans D2 ;
 attribut A3 = AdrCl à valeurs dans D2 .

3.2.3 Relation
Dénition 3 (Produit cartésien) Soient D1 , D2 , .., Dn un ensemble de domaines.
Le produit cartésien d'un ensemble de domaines D1 , D2 , .., Dn , noté D1 ×D2 ×..×Dn ,
est l'ensemble des n-uplets ou tuples V1 , V2 , .., Vn tel que Vi ∈ Di .

Dénition 4 Une relation N-aire R sur les attributs A1 , A2 , .., An de domaines

respectifs D1 , D2 , .., Dn , est un sous-ensemble du produit cartésien des domaines
D1 , D2 , .., Dn .

La relation R peut être vu comme un tableau à deux dimensions dont les colonnes
correspondent aux domaines et les lignes contiennent les tuples.

23
 Chapitre 3 : Le modèle relationnel

Un élément appartenant à une telle relation sera appelé n-uplet ou tuple. Il sera
noté (d1 , d2 , .., dn ) où di ∈ Di , ∀ 1 ≤ i ≤ n.
L'ensemble des n-uplets d'une relation sera appelé extension de la relation.
Exemple :
Soit r une extension constituée de trois tuples : r = {(2140, Ali, T unis), (1123, Salah, Sf ax),
(3425, M hmed, Gabes)}.

3.2.4 Représentation d'une relation

On peut représenter une relation sous forme de tables où :
 chaque ligne est un tuple ;
 chaque colonne est un attribut de la relation.
Une relation peut modéliser :
 soit une classe d'entités ;
 soit une classe de relations.
La gure 3.1 illustre la représentation d'une relation.

Figure 3.1  Représentation d'une relation.

3.2.5 Schéma de relation

Un schéma de relation est le nom de la relation suivie de la liste des attributs.
Dénition 5 (Schéma de relation) Un schéma de relation de degré n est noté
R(A1 , A2 , .., An ) où :
 R représente le nom de la relation ;
 A1 ,A2 ,..,An : les attributs de la relation.
Chaque attribut Ai est le nom d'un rôle joué par un certain domaine D dans le
schéma de la relation R.
Le domaine de Ai est noté dom(Ai ).
Dénition 6 (Instance de relation r(R)) Une instance d'une relation r de schéma
de relation R(A1 , A2 , .., An ), notée r(R), est un ensemble de n-tuples r = {t1 , t2 , .., tm }.
Chaque n-tuple t st constitué par une liste ordonnée de n valeurs t =< V1 , V2 , .., Vn >
où ∀i, 1 ≤ i ≤ n, Vi ∈ dom(Ai )

24
3.3 Notations utilisées dans un contexte de modèle relationnel

3.2.6 Caractéristiques d'une relation

L'ordre des tuples et des attributs dans une relation est quelconque.
Chaque valeur d'attribut dans un tuple doit être atomique, c-à-d non divisible
en composantes.
Remarque : Les attributs composés ou multi-valués ne sont pas autorisés. De
ce fait, les attributs multi-valués doivent être représentés par des relations séparées.
Les attributs composés doivent être remplacer par leurs composantes élémentaires.

3.3 Notations utilisées dans un contexte de modèle rela-

tionnel
Les notations utilisées dans un contexte de modèle relationnel sont les suivantes :
 Un schéma de relation R de degré n est représenté par : R(A1 , A2 , .., An ) ;
 Un n-uplet t dans une relation r(R) est représenté par : t =< V1 , V2 , .., Vn >
où Vi =valeur correspondant à l'attribut Ai ;
 Pour se référer à des valeurs d'attributs dans un tuple, on utilise la notation
suivante :
 t[Ai ]= valeur Vi dans le tuple pour l'attribut Ai ;
 t[Au , Aw , .., Az ] (Au , Aw , .., Az est une liste d'attributs de R) réfère le sous-
ensemble de valeurs < Vu , Vw , .., Vz > de t correspondant aux attributs
spéciés dans la liste.

3.4 Attribut clé d'une relation

Dénition 7 (Clé d'une relation) Une clé est un ensemble d'attributs minimal
dont la connaissance des valeurs permet d'identier un tuple unique de la relation
considérée.

Tout schéma de R possède obligatoirement une clé. Cette propriété doit être
toujours vériée par le SGBD.

Dénition 8 (Clé candidate) En général, un schéma d'une relation R peut avoir

plusieurs clés. Dans ce cas, chacune de ces clés est appelée clé candidate. Dans ce
cas, le concepteur doit choisir l'une d'entre elles qui sera appelée clé primaire et qui
sera utilisée pour l'identication des tuples.

Dénition 9 (Clé étrangère) Soient deux schémas de relations R1 et R2 . Un

ensemble d'attributs Fk dans R1 est une clé étrangère de R1 si elle remplit les deux
conditions suivantes :
1. Les attributs constituant Fk ont le même domaine que les attributs Pk consti-
tuant la clé primaire du schéma de la relation R2 .
On dit alors que les attributs Fk font référence à la relation R2 .

25
 Chapitre 3 : Le modèle relationnel

2. Une valeur de Fk dans un tuple t1 de R1 est soit identique à une valeur de Pk

dans un tuple T2 de R2 soit Nulle.
D'un point de vue formelle : t1 [Fk ] = t2 [Pk ].

3.5 Contraintes d'intégrité sur un schéma relationnel

Les contraintes d'intégrité sont toujours spéciées sur un schéma relationnel mais
doivent être vériées pour toute instance particulière de ce schéma.
Il existe quatre types de contraintes d'intégrité :
 Les contraintes de clé :
 permettent de spécier les clés candidates de chaque schéma relationnel ;
 les valeurs de clés candidates doivent être distinctes pour chaque tuple dans
toute instance de relation du schéma de relation.
 Les contraintes d'intégrité sur une entité : elles ont pour but d'interdire une
valeur NULL pour une clé primaire. Ceci revient alors d'éviter toute ambiguïté
d'identication de deux tuples qui pourraient tous deux avoir une clé primaire
de valeur nulle.
 Les contraintes d'intégrité référentielles :
 Contraintes de clé et contraintes d'intégrité sur une entité s'appliquent
toutes deux sur une seule relation ;
 Une contrainte d'intégrité référentielle s'applique toujours entre deux rela-
tions et a pour but de maintenir une certaine cohérence parmi les tuples des
deux relations ;
 De façon informelle, une contrainte d'intégrité référentielle permet de spé-
cier qu'un tuple dans une relation qui réfère à une autre relation doit faire
référence à un tuple existant dans cette deuxième relation.
 Les contraintes sémantiques : par exemple, on peut imposer que la note d'un
étudiant est entre 0 et 20.

3.6 Traduction d'un modèle E/A en modèle relationnel

L'absence de SGBD supportant directement le modèle E/R amène à transformer
le schéma conceptuel en un schéma conforme au modèle de données du SGBD cible.
Dans ce paragraphe, nous présentons les règles qui permettent de passer d'un schéma
E/R à un schéma relationnel.

3.6.1 Traduction des entités

Toute entité est traduite selon les trois règles suivantes :
 L'entité se transforme en une relation ;
 L'identiant de l'entité devient la clé primaire de la relation ;
 Les propriétés de l'entité deviennent des attributs de la relation.
La gure 3.2 illustre la traduction d'une entité du modèle E/R vers le modèle
relationnel.

26
3.6 Traduction d'un modèle E/A en modèle relationnel

Figure 3.2  Traduction d'une entité.

3.6.2 Traduction des associations

Nous distinguons deux catégories d'associations : les associations binaires et les
associations n-aires. La traduction d'une association s'eectue selon les cardinalités
relatives aux entités participant à l'association. Plusieurs cas peuvent se présenter.

[Link] Traduction des associations binaires

 Association Un-à-Un : pour ce type d'association, deux traductions sont
possibles :
1. Solution 1 : les deux entités et l'association seront transformées en une
seule relation contenant les attributs des deux entités ainsi que les attri-
buts éventuels de l'association. L'identiant de l'entité A ou de l'entité
B sera choisie comme clé primaire de la nouvelle relation. Cette solution
est surtout utilisée dans le cas où les deux entités ont des cardinalités 1,1
qui ne sont pas sujettes à des modications dans le temps.
La gure 3.3 illustre la traduction d'une association Un-à-Un du modèle
E/R vers le modèle relationnel.
2. Solution 2 : les deux entités seront transformées en deux relations. Une
de ces deux relations sera choisie et étendue par la liste des attributs
éventuels de l'association ainsi que de l'identiant de l'autre entité en
tant que clé étrangère. Ce choix se base sur la séquence temporelle de
création des entités. L'entité qui sera créée en second lieu aura comme
clé étrangère l'identiant de l'entité créée en premier lieu. Cette solution
est la plus adaptée dans le cas où une ou les deux cardinalités minimales
sont nulles.
La gure 3.4 illustre la traduction d'une association Un-à-Un du modèle
E/R vers le modèle relationnel.
 Association Un-à-Plusieurs (Maître-Esclave) : Les règles de traduction
de ce type d'association sont les suivantes :

27
 Chapitre 3 : Le modèle relationnel

Figure 3.3  Traduction d'une association Un-à-Un : solution 1.

Figure 3.4  Traduction d'une association Un-à-Un : solution 2.

 L'entité Maître (Entité A) devient la relation Maître ;

 L'entité Esclave (Entité B ) devient la relation Esclave ;
 L'identiant de l'entité Maître devient attribut de la relation Esclave. Cet
attribut est désigné comme clé étrangère ;
 Les attributs éventuels de l'association (AssAB) migrent vers la relation
esclave et deviennent ses attributs.
La gure 3.5 illustre la traduction d'une association Un-à-Plusieurs du modèle
E/R vers le modèle relationnel.
 Association Plusieurs-à-Plusieurs : Les règles de traduction de ce type
d'association sont les suivantes :
 Chaque entité (Entité A et Entité B ) devient une relation ;
 L'association sera transformée aussi en une relation ayant comme clé la
concaténation des deux clés issues des entités A et B . Les attributs éventuels
de l'association seront stockés dans cette relation en tant qu'attributs.
La gure 3.6 illustre la traduction d'une association Plusieurs-à-Plusieurs du
modèle E/R vers le modèle relationnel.

28
3.6 Traduction d'un modèle E/A en modèle relationnel

Figure 3.5  Traduction d'une association Un-à-Plusieurs.

Figure 3.6  Traduction d'une association Plusieurs-à-Plusieurs.

[Link] Traduction des associations n-aires

Ce type d'association sera transformé en une relation ayant comme liste d'at-
tributs la liste des clés des relations correspondantes aux entités qui participent à
cette association en plus de ses attributs éventuels. Une clé minimale sera choisie
parmi la liste des attributs ainsi constituée.
La gure 3.7 illustre la traduction d'une association n-aires du modèle E/R vers
le modèle relationnel.

29
 Chapitre 3 : Le modèle relationnel

Figure 3.7  Traduction d'une association n-aires.

3.6.3 Traduction du lien is-a

La traduction du lien is-a peut se faire selon plusieurs règles. Dans ce qui suit,
nous considérerons une entité mère R avec N entités lles S1 , S2 ,..,SN .
La traduction d'un lien is-a se fait selon l'une des trois règles suivantes :
 Règle 1 - Représentation de l'entité mère et de ses entités lles :
dans ce cas, l'entité mère sera transformée en une nouvelle relation avec ses
attributs. Chaque entité lle Si sera transformée en une relation comportant
comme clé primaire l'identiant de l'entité mère et comme attributs les attri-
buts de Si .
La gure 3.8 illustre la traduction du lien is-a par la représentation de l'entité
mère et de ses entités lles.
Cette règle est adaptée pour tout type de spécialisation, ce qui permettra de
représenter l'entité mère et les entités lles explicitement.
 Règle 2 - Pas de représentation de l'entité mère : dans ce cas, chaque
entité lle Si sera transformée en une relation comportant comme clé primaire
l'identiant de l'entité mère et comme attributs les attributs de Si en plus des
attributs de l'entité mère.
La gure 3.9 illustre la traduction du lien is-a dans le cas où l'entité mère ne
sera pas représentée.
Cette règle pose un problème lorsque les sous-entités ne sont pas disjointes.
Dans ce cas, il peut y avoir duplication de certaines données. Certains pro-

30
3.6 Traduction d'un modèle E/A en modèle relationnel

Figure 3.8  Représentation de l'entité mère et de ses entités lles.

Figure 3.9  Pas de représentation de l'entité mère.

blèmes d'incohérence peuvent alors avoir lieu.

Cette règle est applicable donc, dans le cas de sous-entités totalement dis-
jointes tels que Homme, Femme →Personne ou aussi Alimentaire, Habille-
ment, Electro-ménager → Article.
Pour le cas Étudiant, Employé → Personne, cette règle conduirait à dupliquer
les données héritées pour des employés étudiants.
 Règle 3 - Fusion des entités lles et de l'entité mère : dans ce cas,

31
 Chapitre 3 : Le modèle relationnel

l'entité mère et ses entités lles seront transformées toutes en une seule relation
ayant comme clé primaire l'identiant de l'entité mère et comme attributs les
attributs de toutes les entités (mère et lles).
La gure 3.10 illustre la traduction du lien is-a avec fusion des entités lles et
de l'entité mère.

Figure 3.10  Fusion des entités lles et de l'entité mère.

Le problème posé par cette règle est que certains attributs risquent d'avoir une
valeur nulle. Par exemple, pour la hiérarchie Homme, Femme → Personne,
suite à l'utilisation de cette règle les attributs spéciques aux hommes seront
nuls pour les femmes et vice versa. En utilisant cette règle par exemple pour
la hiérarchie Étudiant, Employé → Personne, tout étudiant non employé aura
les attributs spéciques aux étudiants nuls, et tout employé non étudiant aura
les attributs d'étudiants nuls.

3.7 Études de cas

3.7.1 Étude de cas 1 : Gestion d'une entreprise
Le modèle relationnel déduit à partir du modèle E/R illustré par la gure 2.8
est donné par la gure 3.11.

3.7.2 Étude de cas 2 : Gestion de stock

Le modèle relationnel déduit à partir du modèle E/R illustré par la gure 2.9
du chapitre 2 est donné par la gure 3.12.

32
3.7 Études de cas

Figure 3.11  Étude de cas 1 : modèle relationnel - Gestion d'une entreprise.

Figure 3.12  Étude de cas 2 : modèle relationnel - Gestion de stock.

33
 Chapitre 4

L'algèbre relationnelle

Sommaire
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2 Opérateurs ensemblistes . . . . . . . . . . . . . . . . . . . . . 35
4.2.1 Union . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.2 Intersection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.3 Diérence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.4 Produit cartésien . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3 Opérateurs spéciques aux BD relationnelles . . . . . . . . . 36
4.3.1 Sélection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3.2 Projection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3.3 Séquences d'opérations . . . . . . . . . . . . . . . . . . . . . . 38
4.3.4 Renommage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3.5 Jointure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3.6 Division relationnelle . . . . . . . . . . . . . . . . . . . . . . . 41
4.4 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.5 Fonctions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.5.1 Fonctions arithmétiques . . . . . . . . . . . . . . . . . . . . . 42
4.5.2 Fonctions de groupe . . . . . . . . . . . . . . . . . . . . . . . 42
4.5.3 Fonctions sur caractères . . . . . . . . . . . . . . . . . . . . . 44
4.1 Introduction

4.1 Introduction
L'algèbre relationnelle a été introduite par Ted Codd en 1970. C'est un ensemble
d'opérations permettant de manipuler les relations. Ces opérations ont comme opé-
randes les relations et rendent comme résultat une nouvelle relation sur laquelle
peuvent s'appliquer d'autres opérations.
Ces opérations sont réparties en deux groupes :
1. Opérations reposant sur la théorie des ensembles :
 Union ∪ (n-aire) ;
 Intersection ∩ (n-aire)
 Diérence − (binaire) ;
 Produit cartésien × (binaire).
2. Opérations spéciques aux BD relationnelles :
 Sélection σ (unaire) ;
 Projection π (unaire) ;
 Jointure ◃▹ (binaire) ;
 Division relationnelle / (binaire).

4.2 Opérateurs ensemblistes

Les opérateurs ensemblistes correspondent aux opérateurs habituels de la théorie
des ensembles, dénis sur des tables de même schéma (union-compatibles).

Dénition 1 (Union-compatibilité) Soient r et s deux relations de schémas res-

pectifs R(A1 , A2 , .., An ) et S(B1 , B2 , .., Bn ). R et S sont dites compatibles d'union
si et seulement si :
 Elles sont de même degré n ;
 ∀i, 1 ≤ i ≤ n, dom(Ai ) = dom(Bi ).

4.2.1 Union
Dénition 2 (Union) Soient r et s deux relations de schémas respectifs R et S .
Les schémas R et S doivent être union-compatibles. L'union des deux relations R∪S
produit une nouvelle relation de schéma identique à R et à S possédant les enregis-
trements appartenant à R ou à S ou aux deux relations.

4.2.2 Intersection
Dénition 3 (Intersection) Soient r et s deux relations de schémas respectifs R
et S . Les schémas R et S doivent être union-compatibles. L'intersection des deux
relations R∩S produit une nouvelle relation de schéma identique à R et à S possédant
les enregistrements appartenant conjointement à R et à S .

35
 Chapitre 4 : L'algèbre relationnelle

4.2.3 Diérence
Dénition 4 (Diérence) Soient r et s deux relations de schémas respectifs R et
S . Les schémas R et S doivent être union-compatibles. La diérence des deux rela-
tions R − S produit une nouvelle relation de schéma identique à R ou à S possédant
les enregistrements présents dans R mais pas dans S .

4.2.4 Produit cartésien

Dénition 5 (Produit cartésien) Soient r et s deux relations de schémas res-
pectifs R et S . Les schémas R et S doivent être disjoints, c'est à dire ne pas avoir
d'attributs communs. Le produit cartésien des deux relations R × S produit une nou-
velle relation de schéma Z égal à l'union des schémas R et S et possédant comme
enregistrements, la concaténation des enregistrements de R avec ceux de S .

Requête 1 : Lister toutes les aectations possibles des employés dans les diérents
projets.

R ← Employé × Projet

4.3 Opérateurs spéciques aux BD relationnelles

4.3.1 Sélection
Dénition 6 (Sélection) L'opérateur de sélection permet la sélection de tous les
tuples qui vérient la condition de sélection dans la relation origine.

La syntaxe est la suivante :

σ<condition de sélection> (< nom de relation >)

où :
 σ est l'opérateur de sélection ;
 <condition de sélection> est une expression booléenne portant sur les attri-
buts de la relation concernée. Cette expression peut contenir un ensemble de
clauses de la forme :

< nom attribut >< op. comparaison >< constante >

ou
< nom attribut >< op. comparaison >< nom attribut >
 La relation résultante a les mêmes attributs que la relation origine ;
 Le nombre de tuples est ≤ à celui de la relation origine ;
 Les opérateurs de comparaison peuvent être =, <, ≤, >, ≥ et ̸= ;

36
4.3 Opérateurs spéciques aux BD relationnelles

 Les liaisons entre les clauses se font par AND, OR et NOT.

Requête 2 : Lister tous les employés qui travaillent dans le département numéro
4 et dont le salaire est >300 dinars.

R ← σ(N o−Dept=4) AN D (Salaire>300) (Employé)

ou

R1 ← σN o−Dept=4 (Employé)
R2 ← σSalaire>300 R1

Requête 3 : Lister tous les employés qui travaillent dans le département nu-
méro 4 et dont le salaire est >250 dinars ou ceux qui travaillent dans le département
numéro 5 et dont le salaire est > 300 dinars.

R ← σ((N o−Dept=4) AN D (Salaire>250)) OR ((N o−Dept=5) AN D (Salaire>300)) (Employé)

4.3.2 Projection
Dénition 7 (Projection) L'opérateur de projection permet la production d'une
nouvelle relation ne contenant qu'un sous-ensemble d'attributs de la relation origine
et sans tuples en double.

La syntaxe est la suivante :

π<liste d′ attributs> (< nom de relation >)

où :
 π est l'opérateur de projection ;
 <liste d'attributs> est la liste des attributs que l'on désire retrouver dans la
relation résultante ;
 Le degré de la relation résultante est le nombre d'attributs spéciés dans <liste
d'attributs> ;
 L'opération de projection élimine automatiquement les duplications de tuples ;
 La relation résultante contient les attributs spéciés dans le même ordre que
celui indiqué dans <liste d'attributs>.
Requête 4 : Lister le nom et le salaire de tous les employés.
R ← πN om,Salaire (Employé)

37
 Chapitre 4 : L'algèbre relationnelle

4.3.3 Séquences d'opérations

Il existe deux options pour combiner plusieurs opérations de l'algèbre relation-
nelle à savoir :
 Écrire la suite d'opérations sous forme d'une seule expression de l'algèbre
relationnelle ;
 Appliquer successivement une opération après l'autre en créant des relations
intermédiaires.
Requête 5 : Lister le nom et le salaire de tous les employés qui travaillent dans
le département numéro 5.

R1 ← σ(N o−Dept=5) (Employé)

R2 ← πN om,Salaire (R1)

ou

R ← πN om,Salaire (σ(N o−Dept=5) (Employé))

4.3.4 Renommage
La modication des noms des attributs peut être très utile pour des opérations
plus complexes tels que l'union et la jointure.
Dénition 8 (Renommage) Le renommage ou l'aectation permet de renommer
les attributs d'une relation pour résoudre des problèmes de compatibilité entre noms
d'attributs de deux relations opérandes d'une opération binaire.
Requête 6 : Lister les NAS et les noms des employés. Renommez l'attribut
NAS par numéro d'assurance.

R(N uméro Assurance) ← πN AS,N om (Employé)

4.3.5 Jointure
Dénition 9 (Jointure) Soient r et s deux relations de schémas respectifs R et
S , R ◃▹ S permet la production d'une nouvelle relation contenant toutes les combi-
naisons des tuples de R et S qui vérient la condition de jointure.

La syntaxe est la suivante :

R ◃▹<condition de jointure> S
où :

38
4.3 Opérateurs spéciques aux BD relationnelles

 ◃▹ est l'opérateur de jointure ;

 La condition de jointure est de la forme :

< condition > AN D < condition > AN D..AN D < condition >

 <condition> est de la forme : Ai θBj où :

 Ai est un attribut de R ;
 Bj est un attribut de S de même domaine que Ai ;
 θ ∈ {=, <, ≤, >, ≥, ̸=}.
 Si θ ∈ {=, <, ≤, >, ≥, ̸=} alors on parle de la théta-jointure ;
 Si θ = {=} alors on parle de l'équi-jointure.

Dénition 10 (Équi-jointure) L'équi-jointure de r et s de schémas respectifs R

et S sur les attributs Ai et Bj est une jointure selon la condition valeur Ai =
valeur Bj . Les attributs Ai et Bj , appelés colonnes de jointure, doivent avoir des
domaines compatibles. S'ils ont des noms identiques, on ajoute le nom de la relation
(Exemple : [Link] )

La relation résultante de l'équi-jointure a comme tuples la concaténation des

tuples de R et de S s'ils ont la même valeur pour les attributs communs. Le but de
l'équi-jointure est de créer toutes les combinaisons signicatives (portant la même
valeur pour les attributs de même nom) entre tuples de deux relations.

Dénition 11 (Théta-jointure) La théta-jointure de r et s de schémas respectifs

R et S sur les attributs Ai et Bj est une jointure selon la condition Ai opérateur
Bj , avec opérateur ∈ {<, ≤, >, ≥, ̸=}.

La relation resultante de la théta-jointure (θ-jointure) a comme tuples la conca-

tenation des tuples de R et de S dont les valeurs vérient la condition.

Dénition 12 (Jointure naturelle) La jointure naturelle de r et s de schémas

respectifs R et S sur les attributs Ai et Bj est une équi-jointure de r et de s sur
tous les attributs de même nom dans R et S (Ai = Bj ) suivie de la projection qui
élimine les doublures des attributs (les attributs de même nom n'apparaissent qu'une
seule fois dans la relation résultante).

La syntaxe de la jointure naturelle est la suivante :

R ∗(<liste 1>,<liste 2>) S

Seules les attributs contenus dans < liste 1 > sont conservés.
Le but de la jointure naturelle est de créer toutes les combinaisons entre les
tuples de deux relations qui ont au moins un attribut de même nom Si de plus R
et S n'ont pas d'autres attributs en commun, on peut omettre le paramètre de la
jointure, et écrire simplement R ◃▹ S .
Requête 7 : Rechercher le nom du directeur de chaque département (Nom).

39
 Chapitre 4 : L'algèbre relationnelle

R1 ← Département◃▹N AS−Resp=N AS (Employé)

R ← πN om−D,N om (R1)

Requête 8 : Rechercher la localisation de chaque département (Nom).

R1 ← Département◃▹(N o−Dep=N o−Dep) (Dep_Loc)
R ← πN om−D,Loc−Dep (R1)

La requête précédente produit des attributs de mêmes valeurs pour chaque tuple
et c'est inutile de garder deux colonnes qui contiennent la même chose, on peut
supprimer une colonne, d'où la notion de jointure naturelle.
Requête 9 : Rechercher la localisation de chaque département (Nom).
R ← Département∗(N o−Dep),(N o−Dep) Dep_Loc

Si les attributs ont les mêmes noms dans les deux relations, ils peuvent être
hormis. ce qui revient à écrire la requête précédente comme suit :

R ← Département∗Dep_Loc

Remarque : Dans le cas le plus général, la jointure naturelle se fait implicite-

ment sur toutes les paires d'attributs ayant les mêmes noms dans les deux relations
respectives.
Requête 10 : Rechercher les noms des départements responsables de chaque
projet (Nom).

R ← Projet◃▹(Dept−N o=N o−Dep) Département

ou

R1 ← Projet∗(Dep−N o),(N o−Dep) Département

R ← πN om−P,N om−D (R1)

Requête 11 : Trouver les noms et les adresses de tous les employés qui tra-
vaillent dans le département Recherche.

R1 ← σ(N om−D=′ Recherche′ ) (Département)

R2 ← R1 ◃▹(N o−Dep=N o−Dept) Employé

40
4.3 Opérateurs spéciques aux BD relationnelles

R ← πN om,Adresse (R2)

ou

R1(N o − Dept) ← πN o−Dep (σ(N om−D=′ Recherche′ ) (Département))

R2 ← R1∗ Employé
R ← πN om,Adresse R2

Requête 12 : Pour chaque projet localisé à Tunis, lister le numéro du projet,

le département qui en est responsable ainsi que le nom, l'adresse et la date de nais-
sance de son directeur.

R1 ← σ(Loc−P =′ T unis′ ) (Projet)

R2 ← R1 ◃▹(Dept−N o=N o−Dep) Département
R3 ← R2 ◃▹(N AS−Resp=N AS) Employé
R ← πN o−P,Dept−N o,N om,Adresse,D−N ais (R3)

4.3.6 Division relationnelle

Dénition 13 (Division relationnelle) Le résultat de la division d'une relation
R(X, Y ) par une relation S(Y ) est une relation Q(X) dénie par :
1. Le schéma de Q est constitué de tous les attributs de R n'appartenant pas à
S.
2. Les tuples qj de Q tels que, quels que soit les tuples si de S , le tuple (qj , si )
est un tuple de R (c'est-à-dire Q × S ⊆ R).

La division traite les requêtes de style les...tels que tous les....

Requête 13 : Retrouver les noms des employés qui travaillent sur tous les
projets sur lesquels travaille l'employé de 'Ben Ahmed'.
Pour répondre à cette requête, on va procéder par étapes :
 Création d'un relation intermédiaire contenant tous les numéros de projets sur
lesquelles travaille 'Ben Ahmed'.

R1 ← σ(N om=′ BenAhmed′ ) (Employé)

R2 ← R1 ◃▹(N AS=N AS−Emp) Travaille_Sur
R3 ← πP rojet−N o R2

 Création d'un relation intermédiaire ayant le schéma < P rojet − N o, N AS −

Emp > tel que l'employé N AS − Emp travaille sur le projet P rojet − N o.

41
 Chapitre 4 : L'algèbre relationnelle

R4 ← πP rojet−N o,N AS−Emp (Travaille_Sur)

 Application de la division relationnelle pour en déduire les NAS des employés

qui travaillent sur tous les projets sur lesquels travaille Ben Ahmed.

R5 ← R4 ÷ R3

 Résultat : jointure avec la table employé pour en déduire les noms des em-
ployés.

R ← πN om (R5 ◃▹N AS−Emp=N AS Employé)

4.4 Synthèse
Le tableau 4.1 présente une synthèse des diérents opérateurs de l'algèbre rela-
tionnelle.

4.5 Fonctions
4.5.1 Fonctions arithmétiques
Ce sont des fonctions qui retournent une valeur pour chaque tuple sélectionné.
Les principales fonctions arithmétiques sont résumées dans le tableau 4.2.

4.5.2 Fonctions de groupe

Ce sont des fonctions qui opèrent sur plusieurs tuples/colonnes d'une relation.
Les principales fonctions de groupe sont résumées dans le tableau 4.3.
La syntaxe de cette expression est la suivante :

< groupement d′ attributs > ℑ<liste de f onctions> (< nom de relation >)

où :
 < groupement d′ attributs > est une liste d'attributs de la relation spéciée
dans < nom de relation > ;
 < liste de f onctions > est une liste de couples (< f onction >< attribut >)
où :
 < f onction > est une fonction de groupe ;
 < attribut > est un attribut de la relation spéciée dans < nom de relation >.
 La relation résultante contient les attributs spéciés dans < groupement d′ attributs >
plus les attributs spéciés dans < liste de f onctions >.

42
4.5 Fonctions

Table 4.1  Synthèse des opérateurs de l'algèbre relationnelle.

Opérateur Signication Notation
Sélection Sélection de tous les tuples qui véri- σ<condition de sélection> (< nom de relation >
ent la condition de sélection dans )
R.
Projection Production d'une nouvelle relation π<liste d′ attributs> (< nom de relation >)
ne contenant qu'un sous-ensemble
d'attributs de R et sans tuples en
double.
Théta-jointure Production d'une nouvelle relation R ◃▹<condition de jointure> S
contenant toutes les combinaisons
de tuples de R et S qui vérient la
condition de jointure.
Équi-jointure Idem que théta-jointure mais où la R ◃▹<condition de jointure> S
condition de jointure se limite à une ou
condition d'égalité. R ◃▹(<attributs 1>),(<attributs 2>) S
Jointure naturelle Idem que équi-jointure excepté que R ∗<condition de jointure> S
les attributs de S ne sont pas pré- ou
sents dans la relation résultante. Si R ∗(<attributs 1>),(<attributs 2>) S
les attributs de jointure ont le même ou R ∗ S
nom, il n'est pas utile de les men-
tionner.
Division relationnelle Produit une relation Q(X) qui in- R ÷ S
clut tous les tuples t{X} dans R(Z)
qui apparaissent dans R en combi-
naison avec chaque tuple de S(Y ) et
où X = Z − Y .
Union Produit une relation qui inclut tous R ∪ S
les tuples de R et de S . R et S
doivent être compatibles d'union.
C'est une opération commutative et
associative.
Intersection Produit une relation qui inclut tous R ∩ S
les tuples présents simultanément
dans R et dans S qui ne sont pas
dans S . R et S doivent être compa-
tibles d'union. C'est une opération
commutative et associative.
Diérence Produit un relation qui inclut tous R − S
les tuples de R qui ne sont pas dans
S . R et S doivent être compatibles
d'union. C'est une opération com-
mutative.
Produit cartésien Produit une relation qui possède les R × S
tuples de R et de S et qui inclut
comme tuples toutes les combinai-
sons possibles de tuples de R et de
S.

Table 4.2  Fonctions arithmétiques.

Fonction Exemple Signication
ABS ABS(Solde) Valeur absolue de Solde.
GREATEST GREATEST(A,B) Valeur la plus grande entre A et B .
LEAST LEAST(A,B) Valeur la plus petite entre A et B .
ROUND ROUND(salaire,2) Valeur arrondie de salaire (2 chires après
le point décimal).
TO-NUMBER TO-NUMBER(A) Conversion d'une valeur caractère conte-
nant un nombre en une valeur numérique.
TRUNC TRUNC(Salaire.2) Troncature de salaire 2 chires après le
point décimal.

Requête 14 : Donner le nombre total des employés et leurs salaires moyen dans
tous les départements.

43
 Chapitre 4 : L'algèbre relationnelle

Table 4.3  Fonctions de groupe.

Fonction Exemple Signication
AVERAGE AVERAGE(Salaire) Valeur moyenne de salaire.
COUNT COUNT(NAS) Nombre totale de valeurs dans la colonne
NAS.
SUM SUM(Salaire) Somme des valeurs de la colonne Salaire.
MAX MAX(Salaire) Salaire maximum.
MIN MIN(Salaire) Salaire minimum.

R(N ombreEmlpyés, SalaireM oyen) ← ℑCOU N T (N AS),AV G(Salaire) Employé

Requête 15 : Donner pour chaque département (Numéro), le nombre d'em-

ployés travaillant dans ce département et leurs salaires moyens.

R(N o−Dept, N ombreEmlpyés, SalaireM oyen) ←N o−Dept ℑCOU N T (N AS),AV G(Salaire) Employé

4.5.3 Fonctions sur caractères

Ce sont des fonctions qui opèrent sur des chaînes de caractères. Les principales fonctions
sur caractères sont résumées dans le tableau 4.4.

Table 4.4  Fonctions sur caractères.

Fonction Exemple Signication
DECODE DECODE(Note, 'A', 4, 'B', Conversion du résultat littéral de la co-
3, 'C', 2, 'D', 1 :0) lonne Note en valeur numérique correspon-
dante.
INITCAP INITCAP(Nom) Met la première lettre de chaque nom en
majuscule.
INSTR INSTR(Adresse,′ ′ ) Retourne la position du 1er caractère
'Blanc' dans Adresse.
LENGHT LENGHT(Nom) Longueur de Nom en caractères.
LOWER LOWER(Nom) Conversion de Nom en minuscules.
UPPER UPPER(Nom) Conversion de Nom en majuscules.
SUBSTR SUBSTR(Nom,1,2) Retourne 2 caractères de Nom à partir du
premier.

44
 Chapitre 5

Normalisation d'une base de

données relationnelle

Sommaire
5.1 Introduction : Inconvénients soulevés par une mauvaise
perception du réel . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.2 Dépendance fonctionnelle . . . . . . . . . . . . . . . . . . . . 47
5.2.1 Dénition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.2.2 Propriétés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.2.3 Dépendance fonctionnelle élémentaire . . . . . . . . . . . . . 48
5.2.4 Dépendance fonctionnelle canonique . . . . . . . . . . . . . . 48
5.2.5 Clé d'une relation . . . . . . . . . . . . . . . . . . . . . . . . 48
5.2.6 Graphe de dépendances fonctionnelles . . . . . . . . . . . . . 48
5.2.7 Fermeture transitive et couverture minimale . . . . . . . . . . 49
5.2.8 Méthodes formelle de décomposition . . . . . . . . . . . . . . 49
5.3 Dénitions des trois premières formes normales . . . . . . . 49
5.3.1 Première forme normale (1FN) . . . . . . . . . . . . . . . . . 50
5.3.2 Deuxième forme normale (2FN) . . . . . . . . . . . . . . . . . 50
5.3.3 Troisième forme normale (3FN) . . . . . . . . . . . . . . . . . 50
5.4 Forme normale de Boyce-Codd . . . . . . . . . . . . . . . . . 50
5.5 Algorithme de décomposition en 3FN . . . . . . . . . . . . . 51
 Chapitre 5 : Normalisation d'une base de données relationnelle

5.1 Introduction : Inconvénients soulevés par une mau-

vaise perception du réel
L'approche par décomposition, pour concevoir des schémas relationnels, tend à partir
d'une relation composée de tous les attributs, appelée relation universelle, et à décomposer
cette relation en sous-relations qui ne souriraient pas des anomalies telles que la redondance
des données, l'incohérence des données, etc.
Ce processus de ranement successif doit aboutir à isoler des entités des associations
du monde réel. Il doit être réalisé par un algorithme à partir d'une bonne compréhension
des propriétés sémantiques des données.

Dénition 1 (Décomposition d'une relation) Une décomposition d'une relation R(A1 , A2 , .., An )
est un remplacement de la relation R par une collection de relations R1 , R2 , .., Rn obtenues
par des projections de R et telles que la relation résultat des jointures (R1 ◃▹ R2 ◃▹ .. ◃▹ Rn )
ait même schéma que R.

Exemple :

NV Marque Type Puissance Couleur

872 TN 75 Renault R12TS 6 Bleue
872 TN 80 Renault R12TS 6 Rouge

Deux décompositions possibles pour cette relation :

 Décomposition 1

R1
NV Type Couleur
872 TN 75 R12TS Bleue
872 TN 80 R12TS Rouge

R2
Type Marque Puissance
R12TS Renault 6

 Décomposition 2

R1
NV Type
872 TN 75 R12TS
872 TN 80 R12TS

La décomposition 1 permet de retrouver toutes les informations par jointure.

La décomposition 2 ne permet pas de retrouver la couleur de la voiture ⇒ perte d'in-
formation.

46
5.2 Dépendance fonctionnelle

R2
Type Puissance Couleur
R12TS 6 Bleue
R12TS 6 Rouge

R3
Type Marque
R12TS Renault

Dénition 2 (Décomposition sans perte) Une décomposition sans perte est la décom-
position d'une relation R en R1 , R2 , .., Rn telle que pour toute extension de R, on ait
R = (R1 ◃▹ R2 ◃▹ .. ◃▹ Rn ).

5.2 Dépendance fonctionnelle

5.2.1 Dénition
La notion de dépendance fonctionnelle (DF) est introduite par CODD en 70 an de
caractériser des relations qui peuvent être décomposées sans perte d'informations.
Dénition 3 (Dépendance fonctionnelle) Soit la relation R(A, B, C, D), on dit que :
 il y a dépendance fonctionnelle entre le constituant A et B
 ou le constituant A détermine le constituant B
 ou le constituant B dépend du constituant A.
ssi à partir d'une valeur a ∈ Dom(A), on peut associer une valeur b unique ∈ Dom(B).
Par convention, la dépendance fonctionnelle entre A et B est notée A → B .
Dénition 4 Soit R(A1 , A2 , .., An ) un schéma de relation, et X et Y deux sous-ensembles
de (A1 , A2 , .., An ). On dit que X → Y (X détermine Y , ou Y dépend fonctionnellement de
X ) si pour toute extension r de R et ∀ (t1 , t2 ) ∈ r2 , t1 [X] = t2 [X] ⇒ t1 [Y ] = t2 [Y ].
Intuitivement, on dira qu'un attribut ou qu'une liste d'attributs Y dépend fonctionnel-
lement d'un attribut ou d'une liste d'attributs X dans une relation R, si étant donnée une
valeur de X , il ne lui est associée qu'une seule valeur de Y dans toute extension de R.
Exemple : Soit la relation Employé (NAS,Nom,Prénom)
NAS → Nom
Nom 9 NAS.

5.2.2 Propriétés
Les DF obéissent à plusieurs règles d'inférences triviales qui sont :
1. Réexivité : Y ⊆ X ⇒ X → Y
Cette règle stipule que tout ensemble d'attributs détermine, lui-même, ou une partie
de lui-même.
2. Augmentation : si on a X → Y ⇔ ∀ Z on a : XZ → Y Z ou XZ → Y .
Cette règle signie que si X détermine Y , les deux ensembles d'attributs peuvent être
enrichis par un même attribut.

47
 Chapitre 5 : Normalisation d'une base de données relationnelle

3. Transitivité : X → Y et Y → Z ⇒ X → Z .
Ces trois premières règles composent les axiomes de dépendances fonctionnelles et
sont connues sous le nom de : Axiomes de Armstrong.
4. Union : X → Y et X → Z ⇒ X → Y Z .
5. Pseudo-transitivité : X → Y et W Y → Z ⇒ W X → Z .
6. Décomposition : X → Y et Z ⊆ Y Rightarrow X → Z .
À partir de ces règles, il est possible d'introduire la notion de dépendance fonctionnelle
élémentaire.

5.2.3 Dépendance fonctionnelle élémentaire

Dénition 5 (Dépendance fonctionnelle élémentaire) Une dépendance fonctionnelle
X → Y est élémentaire si pour tout X ′ ⊂ X la dépendance fonctionnelle X ′ → Y n'est pas
vraie. En d'autres termes, Y ne dépend pas fonctionnellement d'une partie de X (X est la
plus petite quantité d'information donnant Y ).

Exemple :
NV, Marque → Type n'est pas élémentaire car il sut d'avoir le numéro de la voiture
pour déterminer son type.

5.2.4 Dépendance fonctionnelle canonique

Dénition 6 (Dépendance fonctionnelle canonique) Une dépendance fonctionnelle X →
Y est canonique si sa partie droite ne comporte qu'un seul attribut et un ensemble F de
dépendances fonctionnelles est canonique si chacune de ses dépendances est canonique.

5.2.5 Clé d'une relation

La notion de clé de relation est un concept essentiel du modèle relationnel. Bien que
la notion de clé soit bien connue, il est possible d'en donner une dénition plus formelle à
partir de celle de DF.

Dénition 7 (Clé de relation) Un clé de relation est un sous-ensemble X des attributs

d'une relation R(A1 , A2 , .., An ) tels que :
1. X → A1 , A2 , .., An ;
2. Il n'existe pas de sous-ensemble Y ⊂ X tel que Y → A1 , A2 , .., An .

On peut dire qu'une clé est un ensemble minimum d'attributs qui détermine tous les
autres. Il peut y avoir plusieurs clés pour une même relation ; on en choisit en général une
comme clé primaire. On parle de clé candidate pour désigner une clé quelconque.

5.2.6 Graphe de dépendances fonctionnelles

Les dépendances fonctionnelles peuvent être représentées à l'aide d'un graphe dont les
n÷uds sont les attributs impliqués dans les dépendances et les arcs les dépendances elles-
mêmes. Les arcs sont orientés de la partie gauche de la dépendance vers sa partie droite.

Dénition 8 (Graphe de dépendances fonctionnelles) Soit F un ensemble de DF

élémentaires. F peut être représenté à l'aide d'un graphe dont :

48
5.3 Dénitions des trois premières formes normales

 Les n÷uds sont les attributs impliqués dans les dépendances ;

 Les arcs sont les dépendances elles mêmes.
Les arcs sont orientés de la partie gauche de la dépendance vers la partie droite.

L'intérêt de la représentation graphique est multiple. D'une part, des algorithmes dits
de synthèse de schémas relationnels s'appuient sur une telle représentation, et d'autre part,
elle est appropriée pour l'établissement de propriétés formelles des dépendances.
Ainsi, on pourra par exemple dénir un sous-ensemble minimal de DF, à partir duquel
toutes les autres DF peuvent être engendrées en utilisant les diérentes règles de dérivation
présentées précédemment.

5.2.7 Fermeture transitive et couverture minimale

Dénition 9 (Fermeture transitive) Soit F un ensemble de DF élémentaires. On ap-
pelle Fermeture transitive de l'ensemble F , l'ensemble F + de DF élémentaires obtenu en
ajoutant à F toutes les DF élémentaires obtenues par transitivité.

Soient E et F deux ensembles de DF, on dit que E est équivalent à F s'ils ont même
fermeture transitive : E + = F + .
Il sera intéressant donc de déterminer un sous-ensemble minimum de DF permettant
de générer toutes les autres.

Dénition 10 (Couverture minimale) Soit F un ensemble de DF élémentaires. La

couverture minimale de F est un ensemble F ′ de DF élémentaires tels que :
 Aucune dépendance dans F ′ n'est redondante, c-à-d, pour toute DF f , F ′ − f n'est
pas équivalent à F ′ ;
 Toute DF élémentaire des attributs est dans la fermeture transitive de F ′ (notée F + ).

Tout ensemble de DF a au moins une couverture minimale. Cette couverture va être un

élément essentiel pour décomposer des relations sans perte d'informations.

5.2.8 Méthodes formelle de décomposition

Dénition 11 Une relation R(X, Y, Z) est décomposable selon (X, Y ) et (X, Z) s'il existe
deux relations R1 et R2 tels que :
 R1 = π[X, Y ](R) et R2 = π[X, Z](R) ;
 et R = R1 ◃▹ R2 (R est la jointure naturelle de R1 et R2 ).

Théorème de Heath : R(X, Y, Z) est décomposable sans perte d'information en

R1 (X, Y ) et R2 (X, Z) si X → Y .
Le processus de décomposition est réversible c'est dire il est nécessaire de pouvoir re-
constituer la relation initiale par jointure naturelle de celles obtenues par décomposition.
Les dépendances fonctionnelles entre les données représentent les contraintes d'intégrité ;
une composition doit le préserver.

5.3 Dénitions des trois premières formes normales

Les trois premières formes normales ont pour objectifs de permettre la décomposition
de relations sans perte d'informations, à partir de la notion de DF. L'objectif de cette dé-
composition est d'aboutir à un schéma conceptuel représentant les entités et les associations
canoniques du monde réel.

49
 Chapitre 5 : Normalisation d'une base de données relationnelle

5.3.1 Première forme normale (1FN)

L'objectif de la première forme normale (1FN) est d'interdire :
 les attributs multi-valués ;
 les attributs composés ;
 la combinaison de ces derniers.

Dénition 12 (1 Forme Normale (1FN)) Une relation est dite en 1FN si chacun de
ses attributs à un domaine atomique.

Cette dénition exclut donc les relations ayant des attributs dont les valeurs seraient
des ensembles ou des listes de valeurs.
Cette forme normale est justiée par la simplicité et l'esthétique. Elle consiste simple-
ment à éviter les domaines de plusieurs valeurs.

5.3.2 Deuxième forme normale (2FN)

La deuxième forme normale (2FN) permet d'assurer l'élimination de certaines redon-
dances en garantissant qu'aucun attribut en dehors de la clé n'est déterminé seulement par
une partie de la clé. Ceci dit qu'il doit dépendre de toute la clé et non pas d'une partie de
cette clé.

Dénition 13 (2 Forme Normale (2FN)) Une relation est dite en 2FN ssi :
1. Elle est en 1FN
2. et tout attribut n'appartement pas à une clé ne dépend pas que d'une partie de celle
clé.

5.3.3 Troisième forme normale (3FN)

La troisième forme normale (3FN) permet d'assurer l'élimination des redondances dues
aux dépendances transitives.

Dénition 14 (3 Forme Normale (3FN)) Une relation est dite en 3FN ssi :
1. Elle est en 2FN
2. et tout attribut n'appartenant pas à une clé ne dépend pas d'un attribut non clé.

5.4 Forme normale de Boyce-Codd

La 3FN permet d'éliminer des redondances dues aux dépendances transitives entre
les attributs. Néanmoins, cette forme normale ne permet pas d'éliminer tous les types de
redondances.
En 1974, Boyce et Codd ont introduit la forme normale qui porte leurs noms, notée
BCNF.

Dénition 15 (Forme normale de Boyce-Codd (BCNF)) Une relation est en BCNF

ssi les seules dépendances fonctionnelles élémentaires sont celles dans laquelle une clé dé-
termine un attribut.

50
5.5 Algorithme de décomposition en 3FN

5.5 Algorithme de décomposition en 3FN

Compte tenu des inconvénients des relations en forme quelconque, il est évidemment
souhaitable qu'un schéma relationnel ne comporte que des relations qui soient au minimum
en 3FN. L'objectif de cette section est de présenter un algorithme de construction de schémas
où toutes les relations sont en 3FN.
Toute relation a au moins une décomposition en 3FN qui est sans perte d'informations
et qui préserve les dépendances fonctionnelles.
Les étapes de décomposition en 3FN sont données par l'algorithme 1.

Algorithm 1 Algorithme de décomposition en 3FN

1: Considérer une couverture minimale de DF
2: Répéter
3: Regrouper les attributs isolés (ceux qui ne sont ni source ni cible d'aucun arc du
graphe) dans une relation dont les attributs sont clés
4: Rechercher le plus grand ensemble X d'a déterminant d'autres attributs X1 , .., Xn
5: Constituer une relation d'attributs (X, X1 , .., Xn ). Cette relation est forcément en
3FN car X1 , .., Xn dépendent fonctionnellement de X et qu'il n'y a pas de dépendance
transitive puisque nous sommes partis de la couverture minimale des dépendances
6: Éliminer les dépendances X → X1 ,..,X → Xn de la couverture minimale
7: Éliminer les attributs isolés dans le graphe
8: Jusqu'à Graphe vide

La mise en ÷uvre pratique de l'algorithme consiste à tracer le graphe des dépendances

fonctionnelles puis à regrouper dans une relation toutes les cibles des arcs ayant même
source. La source des arcs constitue la clé de la relation. Ce regroupement est eectué pour
tous les arcs de sources diérentes.

51
 Chapitre 6

SQL : un langage de BD
relationnelle

Sommaire
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.2 Dénition de données en SQL : le LDD . . . . . . . . . . . . 53
6.2.1 Création d'une table . . . . . . . . . . . . . . . . . . . . . . . 53
6.2.2 Modication d'une table . . . . . . . . . . . . . . . . . . . . . 54
6.2.3 Suppression d'une table . . . . . . . . . . . . . . . . . . . . . 55
6.3 Manipulation de données en SQL : le LMD . . . . . . . . . . 56
6.3.1 Insertion de tuples . . . . . . . . . . . . . . . . . . . . . . . . 56
6.3.2 Modication de tuples . . . . . . . . . . . . . . . . . . . . . . 56
6.3.3 Suppression de tuples . . . . . . . . . . . . . . . . . . . . . . 56
6.4 Interrogation de données en SQL : LID . . . . . . . . . . . . 57
6.4.1 Syntaxe générale d'une requête SQL . . . . . . . . . . . . . . 57
6.4.2 Expression de projection . . . . . . . . . . . . . . . . . . . . . 57
6.4.3 Expression de sélection/ restriction . . . . . . . . . . . . . . . 58
6.4.4 Expression de jointure . . . . . . . . . . . . . . . . . . . . . . 58
6.4.5 Expression de l'union, de l'intersection et de la diérence . . 59
6.4.6 Les expressions . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.4.7 Alias et fonctions d'agrégation . . . . . . . . . . . . . . . . . 61
6.4.8 Groupement . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.4.9 Tri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.4.10 Requêtes imbriquées . . . . . . . . . . . . . . . . . . . . . . . 63
6.4.11 Expression de la division relationnelle . . . . . . . . . . . . . 64
6.4.12 Les requêtes récursives en SQL . . . . . . . . . . . . . . . . . 64
6.5 Contrôle de données en SQL : LCD . . . . . . . . . . . . . . 65
6.6 Les vues en SQL . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.6.1 Création d'une vue en SQL . . . . . . . . . . . . . . . . . . . 66
6.6.2 Interrogation d'une vue SQL . . . . . . . . . . . . . . . . . . 66
6.6.3 Modication d'une vue SQL . . . . . . . . . . . . . . . . . . . 66
6.6.4 Suppression d'une vue . . . . . . . . . . . . . . . . . . . . . . 67
6.7 Gestion des transactions en langage SQL . . . . . . . . . . . 67
6.8 Exemple de script de BD . . . . . . . . . . . . . . . . . . . . . 67
6.1 Introduction

6.1 Introduction
SQL (Structured Query Language) est une évolution de SQUARE conçu par IBM dans
les années 70. C'est un langage de quatrième génération (L4G), non procédural.

SQU ARE[Boyce, 1975] → SEQU EL[Chamberlin, 1976] → StructuredQueryLanguage.

Il est basée sur l'algèbre relationnelle (opérations ensemblistes et relationnelles). SQL

a été normalisé dès 1986 mais les premières normes, trop incomplètes, ont été ignorées par
les éditeurs de SGBD. La norme actuelle SQL-2 (appelée aussi SQL-92) date de 1992. Elle
est acceptée par tous les SGBD relationnels. Ce langage permet l'accès aux données et se
compose de quatre sous-ensembles :
1. Le Langage de Dénition de Données (LDD) : ce langage permet la dénition et la
mise à jour de la structure de la base de données (tables, attributs, vues, index, ...).
2. Le Langage de Manipulation de Données (LMD) : ce langage permet de manipuler
les données de la base et de les mettre à jour.
3. Le Langage d'Interrogation de Données (LID) : ce langage permet de rechercher
des informations utiles en interrogeant la base de données. Certains considèrent ce
langage comme étant une partie du LMD.
4. Le Langage de Contrôle de Données (LCD) : ce langage permet de dénir les droits
d'accès pour les diérents utilisateurs de la base de données, donc il permet de gérer
la sécurité de la base et de conrmer et d'annuler les transactions. Note : Ce qui
suit ne constitue qu'une présentation incomplète de SQL. Pour plus de précision, se
référer à la documentation technique du SGBD utilisé.
Les requêtes posées dans ce chapitre sont relatives à l'étude de cas présenté dans le
chapitre 3 (gestion d'une entreprise).

6.2 Dénition de données en SQL : le LDD

6.2.1 Création d'une table
La création de tables se fait à l'aide du couple de mots-clés CREATE TABLE. La syn-
taxe est comme suit :

CREATE <nom_table>
(<attribut1 > <type> [<contrainte d'attribut>],
<attribut2 > <type> [<contrainte d'attribut>],
...
<attributn > <type> [<contrainte d'attribut>],
[<contrainte de relation>],...) ;

Pour chaque attribut que l'on crée, il faut préciser le type de données que le champ
va contenir. Sous le SGBD Oracle, les types de données suivants sont utilisables lors de la
dénition des attributs d'une relation :
 CHAR(n) : Chaîne de caractères de longueur xe n (n <16383) ;
 VARCHAR(n) : Chaîne de caractères de longueur variable de n caractères maximum
(n<16383)

53
 Chapitre 6 : SQL : un langage de BD relationnelle

 INTEGER : Entier signé de 32 bits (-2E31 à 2E31-1) ;

 NUMBER(n, [d]) Nombre de n chires [optionnellement d après la virgule] ;
 LONG : chaîne d'au plus 65535 caractères ;
 RAW et LONGRAW : similaire à CHAR et à LONG respectivement, pour des chaînes
hexadécimales ;
 DATE Date sous la forme 160799 ;
 TIME Heure sous la forme 12 :54 :24.85 ;
 TIMESTAMP Date et Heure.
[<contrainte d'attribut>] permet de spécier des contraintes d'intégrité associées à
l'attribut.
Une contrainte d'intégrité est une règle qui permet de contrôler la validité et la cohérence
des valeurs entrées dans les diérentes tables de la base. Elle peut être dénie sous deux
formes :
 dans les commandes de création des tables ;
 au moment de la modication de la structure de la table.
Il existe des contraintes :
 sur un attribut : la contrainte porte sur un seul attribut. Elle suit la dénition de
l'attribut. Ces contraintes sont :
 NOT NULL : spécie que pour toute occurrence, l'attribut doit avoir une valeur
(la saisie de ce champ est obligatoire) ;
 UNIQUE : toutes les valeurs de l'attribut sont distinctes ;
 PRIMARY KEY : l'attribut est une clé primaire pour la table et elle peut être
remplacée par UNIQUE et NOT NULL.
 REFERENCES table (attribut) : il s'agit d'une contrainte d'intégrité fonctionnelle
par rapport à une clé ; chaque valeur de l'attribut doit exister dans la table dont
l'attribut est référencée. On utilise cette contrainte pour les clés étrangères.
 CHECK : c'est une contrainte associée à une condition qui doit être vériée par
toutes les valeurs de l'attribut (domaine des valeurs de l'attribut).
 sur une table : la contrainte porte sur un ensemble d'attributs d'une même table, une
virgule sépare la dénition d'une contrainte de table des dénitions des attributs. Ces
contraintes sont :
 UNIQUE (attributi , attributj ,...) : l'unicité porte sur le n-uplet des valeurs ;
 PRIMARY KEY (attributi , attributj ,...) : clé primaire de la table (clé composée) ;
 FOREIGN KEY (attributi , attributj ,...) REFERENCES table (attributm , attributn ,...)
[ON DELETE CASCADE] : désigne une clé étrangère sur plusieurs attributs. L'op-
tion ON DELETE CASCADE indique que la suppression d'une ligne de la table
de référence va entraîner automatiquement la suppression des lignes référencées.
Il est possible de donner un nom à une contrainte grâce au mot clé CONSTRAINT suivi
du nom que l'on donne à la contrainte, de telle manière à ce que le nom donné s'ache en
cas de non respect de l'intégrité, c'est-à-dire lorsque la clause que l'on a spéciée n'est pas
validée.

6.2.2 Modication d'une table

La clause ALTER permet :
1. L'ajout d'un attribut : permet d'ajouter un attribut à la structure initiale de la table.

ALTER TABLE <nom_table>

ADD <attribut> <type> ;

54
6.2 Dénition de données en SQL : le LDD

2. La modication d'un attribut : associée avec la clause MODIFY, la clause ALTER

permet la modication du type de données d'un attribut. On ne peut qu'agrandir la
taille d'un attribut.

ALTER TABLE <nom_table>

MODIFY <attribut> <nouveau_type> ;

3. La suppression d'un attribut : permet de supprimer un attribut d'une table.

ALTER TABLE <nom_table>

DROP COLUMN <attribut> ;

4. Ajout de contrainte : permet d'ajouter une contrainte au niveau d'une table.

ALTER TABLE <nom_table>

ADD CONSTRAINT <nom_contrainte> <dénition_contrainte> ;

5. Suppression de contrainte : permet de supprimer une contrainte.

ALTER TABLE <nom_table>

DROP CONSTRAINT <nom_contrainte> ;

6. Désactivation d'une contrainte : permet de désactiver une contrainte, elle est par dé-
faut active (au moment de sa création).

ALTER TABLE <nom_table>

DISABLE CONSTRAINT <nom_contrainte> ;

7. Activation d'une contrainte : permet d'activer une contrainte désactivée.

ALTER TABLE <nom_table>

ENABLE CONSTRAINT <nom_contrainte> ;

6.2.3 Suppression d'une table

La clause DROP permet d'éliminer des tables. Cette clause est toutefois à utiliser avec
précaution dans la mesure où elle est irréversible. La syntaxe est comme suit :

DROP TABLE <nom_table> ;

55
 Chapitre 6 : SQL : un langage de BD relationnelle

6.3 Manipulation de données en SQL : le LMD

6.3.1 Insertion de tuples
L'instruction INSERT permet d'ajouter un ou plusieurs tuples dans une table ou rela-
tion.
Dans le cas d'ajout d'un seul tuple, la syntaxe est comme suit :

INSERT INTO <nom_table> [(attribut1 [,attribut2 ]...)]

VALUES (<n-uplet>) ;

Dans le cas d'ajout de plusieurs tuples, la syntaxe est comme suit :

INSERT INTO <nom_table1> [(attribut1 [,attribut2 ]...)]

SELECT ..FROM <nom_table2> WHERE ;

6.3.2 Modication de tuples

L'instruction UPDATE permet de modier certaines valeurs d'attributs dans un ou
plusieurs tuples. La syntaxe est la suivante :

UPDATE <nom_table>
SET attribut1 =expression1 [,attribut2 =expression2 ]...
[W HERE < condition >] ;

Dans le cas de modication de plusieurs tuples, la syntaxe est comme suit :

UPDATE <nom_table>
SET attribut1 =expression1 [,attribut2 =expression2 ]...
WHERE ... IN (SELECT ... FROM ... WHERE) ;

6.3.3 Suppression de tuples

L'instruction DELETE permet de supprimer un ou plusieurs tuples d'une relation. La
syntaxe est la suivante :

DELETE FROM <Nom_Table>

[W HERE < condition >] ;

56
6.4 Interrogation de données en SQL : LID

Dans le cas de suppression de plusieurs tuples, la syntaxe est comme suit :

DELETE FROM <Nom_Table>

[WHERE ... IN (SELECT ... FROM ... WHERE)] ;

6.4 Interrogation de données en SQL : LID

6.4.1 Syntaxe générale d'une requête SQL
La syntaxe générale d'une requête SQL est la suivante :

SELECT [DIST IN CT ] < liste de sélection >

F ROM < liste de relations >
[W HERE < conditions >]
[GROU P BY < attributs de regroupement >]
[HAV IN G < condition de groupe >]
[ORDER BY < critères de tri >] ;

où :
1. <liste de sélection> : dénit les attributs de la relation résultat. Un élément de la
liste de sélection peut être une constante, un attribut, une expression arithmétique
ou une fonction de groupe ;
2. <liste de relations> : dénit les relations qui seront utilisées pour la requête ;
3. La clause DISTINCT : permet d'éliminer les doubles du résultat ;
4. La clause WHERE est une qualication des n-uplets de R1 ×R2 ×..×Rn . Ces n-uplets
qui satisfont le WHERE seront utilisés pour construire le résultat. Elle est formée en
utilisant :
 Les opérateurs de comparaison : =, ! =, >, <=, >, => ;
 Les connecteurs logiques : AND, OR, NOT avec les parenthèses si c'est nécessaire.
AND est prioritaire par rapport à OR ;
 Prédicats d'appartenance à un ensemble : IN et NOT IN ;
 Prédicats de comparaison entre ensembles : CONTAINS et NOT CONTAINS ;
 Prédicat de comparaison de texte : LIKE ;
 Prédicats de test d'un terme comparaison avec IS NULL et IS NOT NULL ;
 Prédicats existentiels : EXISTS, NOT EXISTS ;
 Prédicat BETWEEN : permettant de tester si la valeur d'un terme est comprise
entre la valeur de deux constantes ;
 Prédicat de comparaison avec uns sous-requête : ANY et ALL.
5. La clause GROUP BY : permet de partitionner le résultat en groupes ou partitions ;
6. La clause ORDER BY : permet de trier le résultat selon un ou plusieurs critères de
tri (ascendant ou descendant).

6.4.2 Expression de projection

Une projection est une instruction permettant de sélectionner un ensemble d'attributs
dans une table.

57
 Chapitre 6 : SQL : un langage de BD relationnelle

La syntaxe de cette expression est la suivante :

SELECT [ALL] | [DISTINCT] <liste des attributs> | ∗

FROM <nom_table> ;

Requête 1 : Lister le NAS de tous les employés.

SELECT NAS
FROM Employé ;

Requête 2 : Lister toutes les informations de de tous les employés.

SELECT *
FROM Employé ;

6.4.3 Expression de sélection/ restriction

La sélection consiste à sélectionner les lignes satisfaisant à une condition logique eec-
tuée sur leurs attributs.
La syntaxe de cette expression est la suivante :

SELECT [ALL] | [DISTINCT] <liste des attributs> | ∗

FROM <nom_table>
WHERE <condition> ;

Requête 3 : Donner la liste de tous les employés qui ont un salaire >300 Dinars.
SELECT *
FROM Employé
WHERE Salaire >300 ;

Requête 4 : Donner la liste de tous les employés (Nom, Prénom) qui travaillent dans
le département numéro 5 et dont le salaire est ≥ 300 Dinars.

SELECT NOM,Prénom
FROM Employé
WHERE (No-Dept=5) AND (Salaire >300) ;

6.4.4 Expression de jointure

Il s'agit ici de sélectionner les données provenant de plusieurs tables ayant un ou plu-
sieurs attributs communs. Cette jointure sera assurée grâce aux conditions spéciées dans

58
6.4 Interrogation de données en SQL : LID

la clause WHERE.
La syntaxe de cette expression est la suivante :

SELECT [ALL] | [DISTINCT] <liste des attributs> | ∗ FROM <liste des tables> WHERE
<nom_table1 .attributj > = <nom_table2 .attributj > AND ... AND <condition> ;

Requête 5 : Lister tous les employés qui sont des directeurs.

SELECT *
FROM Employé,Département
WHERE NAS=NAR-Resp ;

Requête 6 : Lister le nom et le salaire de tous les employés qui travaillent dans le
département Recherche.

SELECT Nom,Salaire
FROM Employé,Département
WHERE (Nom-D LIKE 'Recherche') AND (No-Dep=No-Dept) ;

Requête 7 : Lister les noms de tous les départements qui sont localisés à Tunis.
SELECT Nom-D
FROM Département,Dep-Loc
WHERE (Loc-Dep LIKE 'Tunis') AND ([Link]-Dep=[Link]-Dep) ;

6.4.5 Expression de l'union, de l'intersection et de la diérence

L'opérateur UNION permet de fusionner deux sélections de tables pour obtenir un
ensemble de lignes égal à la réunion des lignes des deux sélections. Les lignes communes
n'apparaîtront qu'une seule fois.
La syntaxe de cette expression est la suivante :

Requête1 UNION Requête2 ;

Remarques :
1. Requête1 et Requête2 doivent avoir la même structure ;
2. Par défaut, les doublons sont automatiquement éliminés. Pour conserver les doublons,
il est possible d'utiliser une clause UNION ALL.
Requête 8 : Lister tous les projets (Nom) qui impliquent un employé dont le nom est
'Ben Ahmed' comme travaillant sur le projet ou comme directeur du département respon-
sable du projet.

SELECT DISTINCT(Nom-P)

59
 Chapitre 6 : SQL : un langage de BD relationnelle

FROM Employé,Travaille-Sur,Projet
WHERE (Nom LIKE 'BEN Ahmed') AND (NAS=NAS-Emp) AND (Projet-No=No-P)
UNION
SELECT DISTINCT(Nom-P)
FROM Employé,Département,Projet
WHERE (Nom LIKE 'BEN Ahmed') AND (NAS=NAS-Resp) AND (No-Dep=Dept-No) ;

Idem pour les expression d'intersection (INTERSECT) et de diérence (MINUS ou

EXCEPT).

6.4.6 Les expressions

Les expressions acceptées par SQL portent sur des attributs, des constantes et des
fonctions. Ces trois types d'éléments peuvent être reliés par des opérateurs arithmétiques
(+, -, ∗, ).
Requête 9 : Lister tous les noms des employés résidents à Tunis.
SELECT Nom
FROM Employé
WHERE Adresse LIKE '%Tunis%' ;

Requête 10 : Lister tous les employés dont le nom possède 9 caractères et commence
par les 3 lettres Ben.

SELECT Nom
FROM Employé
WHERE Adresse LIKE 'BEN- - - - - -' ;

Requête 11 : Lister le nom et le salaire de tous les employés si on augmente leurs

salaires de 10%.

SELECT Nom,1.1∗ salaire

FROM Employé ;

Requête 12 : Lister tous les noms et les prénoms des employés dont le salaire est entre
300 et 400.

SELECT Nom,Prénom
FROM Employé
WHERE Salaire BETWEEN 300 AND 400 ;

Requête 13 : Acher le montant de la vente de 23 articles au prix de 45.000.

SELECT 23∗45
FROM DUAL ;

60
6.4 Interrogation de données en SQL : LID

La table DUAL est une table virtuelle permettant de satisfaite la syntaxe SQL.

6.4.7 Alias et fonctions d'agrégation

Les fonctions de groupe (ou d'agrégation) ne peuvent apparaître dans une requête que
dans la clause SELECT ou la clause HAVING. Ces fonctions sont :
1. COUNT (<expression>|∗)|COUNT([DISTINCT | ALL]<expression>) : cardinal
2. SUM ([DISTINCT | ALL]<expression>) : Somme
3. AVG ([DISTINCT | ALL]<expression>) : Moyenne
4. MAX ([DISTINCT | ALL]<expression>) : Maximum
5. MIN ([DISTINCT | ALL]<expression>) : Minimum
6. VARIANCE ([DISTINCT | ALL]<expression>) : Variance
Les alias permettent de renommer des attributs ou des tables. Ils sont caractérisés par
le mot-clé AS.
Requête 14 : Donner le nombre de salaires diérents.
SELECT COUNT(DISTINCT salaire) AS Salaire_Diérents
FROM Employé ;

Requête 15 : Donner le nombre d'employés qui travaillent dans le département Re-

cherche.

SELECT COUNT(*) AS Nombre_Employés

FROM Employé,Département
WHERE (Nom-D LIKE 'Recherche') AND (No-Dept=No-dep) ;

6.4.8 Groupement
La clause GROUP BY permet de partitionner la relation résultante en groupes de n-
uplets tel que chaque n-uplet d'un groupe ait la même valeur sur lesquelles sont eectuées
les groupements. La relation résultante contient autant de lignes que de groupes.
Requête 16 : Pour chaque département, retrouver le numéro de département, le
nombre d'employés et leur salaire moyen.

SELECT No-Dept,COUNT(NAS) AS Nombre_Employés,AVG(Salaire) AS Salaire_Moyen,COUNT(*)

AS Nombre_Employés
FROM Employé
GROUP BY No-Dept ;

Requête 17 : Rechercher pour chaque projet, son numéro, son nom ainsi que le nombre
d'employés qui y travaillent.

61
 Chapitre 6 : SQL : un langage de BD relationnelle

SELECT No-P,Nom-P,COUNT(*) AS Nombre_Employés

FROM Projet,Travaille-Sur
WHERE No-P=Projet-No
GROUP BY No-P,Nom-P ;

Règle : Lorsque les attributs de groupage sont utilisés dans la clause SELECT, on doit
obligatoirement les retrouver tous dans la clause GROUP BY.
Requête 18 : Lister tous les projets (Numéro, Nom, Nombre d'employés) tel que le
nombre d'employés travaillant dans ce projet est supérieur à 2.

SELECT No-P,Nom-P,COUNT(*) AS Nombre_Employés

FROM Projet,Travaille-Sur
WHERE No-P=Projet-No
GROUP BY No-P,Nom-P
HAVING Nombre_Employés>2 (ou HAVING COUNT(*)>2) ;

La clause HAVING ne peut être présente que si la clause GROUP BY est utilisée. Elle
permet de sélectionner un sous-ensemble de tout les groupes obtenus par la clause GROUP
BY. Elle permet de restreindre les groupes au seuls groupes qui vérient la condition qui
suit la clause HAVING.
L'expression suivant la clause HAVING doit être mono-valué pour chaque groupe.

6.4.9 Tri
L'ordre des lignes d'une table est arbitraire. Il est cependant possible d'imposer un
ordre de présentation spécique par la clause ORDER BY.
La syntaxe de cette expression est la suivante :

SELECT attribut1 , attribut2..., attributn

FROM nom_table1 , nom_table2 ,...
WHERE <condition>
ORDER BY attribut1 [ASC| DESC], attribut2 [ASC| DESC],... ;

Note : L'ordre de tri par défaut est croissant (ASC).

Requête 19 : Lister tous les employés (No-Dept, Nom du département, Nom, Prénom,
Salaire) triés par ordre croissant du numéro de département, ordre décroissant de leurs
salaires et ordre croissant de leurs noms.

SELECT No-Dept,Nom-D,Nom,Prénom,Salaire
FROM Employé,Département
WHERE No-Dept=No-Dep
ORDER BY No-Dept ASC, Salaire DESC, Nom ASC ; (ou ORDER BY No-Dept,Salaire
DESC, Nom ;

62
6.4 Interrogation de données en SQL : LID

6.4.10 Requêtes imbriquées

Eectuer une sous-requête consiste à eectuer une requête à l'intérieur d'une autre, ou
en d'autres termes d'utiliser une requête an d'en réaliser une autre (on entend parfois le
terme de requêtes en cascade).
Une sous-requête doit être placée à la suite d'une clause WHERE ou HAVING, et doit
remplacer une constante ou un groupe de constantes qui permettraient en temps normal
d'exprimer la qualication :
 Lorsque la sous-requête remplace une constante utilisée avec des opérateurs clas-
siques, elle doit obligatoirement renvoyer une seule réponse (une table d'une ligne et
une colonne). Par exemple :

SELECT ... FROM ...

WHERE ... < (SELECT ... FROM ...) ;

 Lorsque la sous-requête remplace une constante utilisée dans une expression mettant
en jeu les opérateurs IN, ALL ou ANY, elle doit obligatoirement renvoyer une seule
colonne. Par exemple :

SELECT ... FROM ...

WHERE ... IN (SELECT ... FROM ...) ;

 Lorsque la sous-requête remplace une constante utilisée dans une expression mettant
en jeu l'opérateur EXISTS, elle peut renvoyer une table de n colonnes et m lignes.
Par exemple :

SELECT ... FROM ...

WHERE ... EXISTS (SELECT ... FROM ...) ;

Requête 20 : Lister les noms et les prénoms des employés n'ayant aucune personne à
charge.

SELECT Nom,Prénom
FROM Employé
WHERE NOT EXISTS (SELECT ∗
FROM Dépendant
WHERE NAS=NAS-Emp) ;

Requête 21 : Lister les noms et les prénoms de tous les directeurs des départements
ayant au moins une personne à charge.

SELECT Nom,Prénom
FROM Employé
WHERE EXISTS (SELECT ∗
FROM Département
WHERE NAS=NAS-Resp)
AND EXISTS (SELECT ∗

63
 Chapitre 6 : SQL : un langage de BD relationnelle

FROM Dépendant
WHERE NAS=NAS-Emp) ;

Requête 22 : Lister les noms de tous les employés qui travaillent sur un des projets
contrôlés par le département numéro 5.

SELECT DISTINCT Nom

FROM Employé,TRAVAILLE-Sur
WHERE (NAS=NAS-Emp)
AND Projet-No IN (SELECT No-P
FROM Projet
WHERE (Dept-No=5)) ;

6.4.11 Expression de la division relationnelle

Requête 23 : Lister les noms de tous les employés qui travaillent dans tous les projets
contrôlés par le département numéro 5.

SELECT DISTINCT Nom

FROM Employé
WHERE (SELECT Projet-No
FROM Travaille-Sur
WHERE (NAS=NAS-Sup) CONTAINS (SELECT No-P
FROM Projet
WHERE Dept-No =5) ;

6.4.12 Les requêtes récursives en SQL

Pour modéliser une requête récursive, on a besoin de faire appel au variable dite variable
de corrélation permettant de désigner la table par cette variable.
Cette variable évite de répéter le nom de la table et simplie ainsi l'écriture d'une
requête.
Requête 24 : Donner pour chaque employé son nom et son prénom ainsi que le nom
et le prénom de son superviseur hiérarchique direct.

SELECT E1 .Nom, E1 .Prénom,E2 .Nom,E2 .Prénom

FROM Employé E1 , Employé E2
WHERE E1 .Nas-Sup=E2 .NAS ;

64
6.5 Contrôle de données en SQL : LCD

6.5 Contrôle de données en SQL : LCD

Plusieurs personnes peuvent travailler simultanément sur une BD. Toutefois ces per-
sonnes n'ont pas forcément les mêmes besoins : certaines peuvent par exemple nécessiter
de modier des données dans la table, tandis que les autres ne l'utiliseront que pour la
consulter. Ainsi, il est possible de dénir des permissions pour chaque personne en leur
octroyant un mot de passe.
Cette tâche incombe à l'administrateur de la BD (en anglais DBA, DataBase Adminis-
trator). Il doit dans un premier temps dénir les besoins de chacun, puis les appliquer à la
BD sous forme de permissions. Le langage SQL permet d'eectuer ces opérations grâce à
deux clauses :
 GRANT : permet d'accorder des droits à un (parfois plusieurs sur certains SGBD)
utilisateur ;
 REVOKE : permet de retirer des droits à un (ou plusieurs sur certains SGBD) uti-
lisateur. Les permissions (appelées aussi droits ou privilèges) peuvent être dénies
pour chaque (un grand nombre) clause. D'autre part il est aussi possible de dénir
des rôles, c'est-à-dire de permettre à d'autres utilisateurs d'accorder des permissions.
GRANT permet au propriétaire d'une table ou vue de donner à d'autres utilisateurs
des droits d'accès à celles ci.
La syntaxe est la suivante :

GRANT <liste_privilèges> ON <table|vue> TO <utilisateur> [WITH GRANT OP-

TION] ;

Les privilèges sont :

 SELECT : droit de lecture ;
 INSERT : droit d'insertion de lignes ;
 UPDATE : droit de modication de lignes ;
 UPDATE (attribut1 , attribut2 , ...) : droit de modication de lignes limité à certains
attributs ;
 DELETE : droit de suppression de lignes ;
 ALTER : droit de modication de la structure de la table ;
 INDEX : droit de création d'index ;
 ALL : tous les droits.
Un utilisateur ayant accordé un privilège peut l'annuler à l'aide de la commande RE-
VOKE.
La syntaxe est la suivante :

REVOKE <liste_privilèges> ON <table|vue> FROM <utilisateur> ;

Note : Si on enlève un privilège à un utilisateur, ce même privilège est automatiquement

retiré à tout autre utilisateur à qui il l'aurait accordé.

6.6 Les vues en SQL

Les vues en SQL ont un sens plus restreint que le concept de vue externe présenté dans
le premier chapitre.

65
 Chapitre 6 : SQL : un langage de BD relationnelle

Une vue SQL est souvent constituée par ne table (virtuelle) qui correspond au résultat
d'une requête fréquente.
Une vue est une relation dont la valeur est calculée à chaque invocation. Elle est dénie
par une requête qui utilise des relations ou des vues existantes (et qui ne doit pas comporter
de clause ORDER BY).
Une vue est donc une table virtuelle dérivée d'autres tables ou d'autres vues. Elle
correspond à une table virtuelle dont seule la dénition est stockée et non le contenu. Si les
attributs d'une vue ne sont pas le résultat d'une opération arithmétique ou d'une fonction,
ils n'ont pas à être spéciés.

6.6.1 Création d'une vue en SQL

La syntaxe de création d'une vue est la suivante :

CREATE VIEW <nom_vue> AS <requête> ;

 Exemple de requête fréquente (sans spécication d'attributs) : Liste de tous les em-
ployés (Nom) et des projets (Nom, Nombre d'heures) sur lesquels ils travaillent.

CREATE VIEW ProjetsEmployé

AS SELECT Nom,Nom-P,Heures
FROM Employé,Projet,Travaille-Sur
WHERE NAS=NAS-Emp AND Projet-No=No-P ;

 Exemple de requête avec attributs dérivés.

CREATE VIEW InfoDépartement

AS SELECT Nom-D,COUNT(*),SUM(salaire)
FROM Employé,Département
WHERE No-Dep=No-Dept
GROUP BY Nom-D ;

6.6.2 Interrogation d'une vue SQL

Une vue est utilisée comme toute autre relation. La seule diérence réside dans le fait
que ses n-uplets ne sont pas stockés mais ils sont le résultat de l'évaluation de la requête
de dénition de vue.

6.6.3 Modication d'une vue SQL

Toutes modications des relations ayant servi à la dénition de la vue sont respectées
sur la vue. Par contre, la mise à jour d'une BD à travers une vue n'a pas trouvé de solution
générale. De ce fait, il est nécessaire de consulter la documentation du système dont on
dispose pour connaître les types de mise à jours autorisées en utilisant une vue.

66
6.7 Gestion des transactions en langage SQL

6.6.4 Suppression d'une vue

La syntaxe de suppression d'une vue en SQL est la suivante :

DROP VIEW <nom_vue>

6.7 Gestion des transactions en langage SQL

Dénition 1 (Transaction) Une transaction est un ensemble de modications de la BD
qui forment un tout invisible.
Il faut eectuer ces modications entièrement ou pas du tout, sous peine de laisser la
base dans un état cohérent.

Au cous d'une transaction, l'utilisateur travaille sur une copie privée des tables qu'il
modie ; ainsi, il est le seul à voir les modications qu'il a eectué.
Pour rendre ces modications eectives pour l'ensemble des utilisateurs, il doit les
valider. Il a la possibilité de revenir à tout moment à l'état dans lequel étaient les tables
avant le début de mise à jour.
Par défaut, une modication de la BD ne sera validée que lors de l'exécution de la
commande COMMIT ou lors de la sortie dénitive de l'environnement SQL∗Plus par EXIT.
Après exécution de la commande COMMIT ou de la commande EXIT, les modications
deviennent dénitives et accessibles par tous les utilisateurs.
Toutes les modications eectuées depuis le début d'une transaction sont défaites par
l'exécution de la commande ROLLBACK.
D'autre part, en cas de n normale d'une tâche utilisateur, il y a automatiquement
exécution de la commande ROLLBACK pour les transactions non terminées.

6.8 Exemple de script de BD

Soit l'instance de la BD illustrée par la gure 6.1.

67
 Chapitre 6 : SQL : un langage de BD relationnelle

Figure 6.1  Instance de la BD Gestion d'une entreprise.

68
6.8 Exemple de script de BD

Les scripts de création de la BD et de manipulation des données sont comme suit :

/*Employé_LDD.sql*/

ALTER TABLE Département DROP PRIMARY KEY CASCADE ;

ALTER TABLE Employé DROP PRIMARY KEY CASCADE ;
ALTER TABLE Projet DROP PRIMARY KEY CASCADE ;

DROP TABLE Employé ;

DROP TABLE Département ;
DROP TABLE Dep_Loc ;
DROP TABLE Travaille_Sur ;
DROP TABLE Projet ;
DROP TABLE Dépendant ;

CREATE TABLE Département

(
Nom_D varchar2(20),
No_Dep number(2),
Nas_Resp number(10) not null,
Date_Resp date,
CONSTRAINT PK_DEP1 PRIMARY KEY (No_Dep)
);

CREATE TABLE Employé

(
Nom varchar2(15),
Prénom varchar2(15),
NAS number(10) not null,
D_Nais date,
Adresse varchar2(50),
Sexe char CHECK (Sexe in ('F','M') ),
salaire number(6,2),
NAS_Sup number(10),
No_Dept number(2),
CONSTRAINT PK_EMP11 PRIMARY KEY (NAS),
CONSTRAINT FK1_EMP11 FOREIGN KEY (No_Dept) REFERENCES Département(No_Dep)
);

CREATE TABLE Dep_Loc

(
No_Dep number(2),
Loc_Dep varchar2(10),
CONSTRAINT PK_DEPL1 PRIMARY KEY (No_Dep,Loc_Dep),
CONSTRAINT FK_DEPL1 FOREIGN KEY (No_Dep) REFERENCES Département(No_Dep)
);

CREATE TABLE Projet

69
 Chapitre 6 : SQL : un langage de BD relationnelle

(
Nom_P varchar2(10),
No_P number(2),
Loc_P varchar2(10),
Dept_No number(2),
CONSTRAINT PK_PROJ1 PRIMARY KEY (No_P),
CONSTRAINT FK_Proj1 FOREIGN KEY (Dept_No) REFERENCES Département(No_Dep)
);

CREATE TABLE Travaille_Sur

(
NAS_Emp number(10) not null,
Projet_No number(2),
Heures Number(4,2),
CONSTRAINT PK_TRS1 PRIMARY KEY (NAS_Emp,Projet_No),
CONSTRAINT FK1_TRS1 FOREIGN KEY (Projet_No) REFERENCES Projet(No_P),
CONSTRAINT FK2_TRS1 FOREIGN KEY (NAS_Emp) REFERENCES Employé(NAS)
);

CREATE TABLE Dépendant

(
NANS_Emp number(10) not null,
Prénom_Dépendant varchar2(15),
Sexe char CHECK (sexe in ('F','M') ),
Naiss_D date,
Filiation varchar2(10),
CONSTRAINT PK_Depd1 PRIMARY KEY (NAS_Emp,Prénom_Dépendant),
CONSTRAINT FK_Depd1 FOREIGN KEY (NAS_Emp) REFERENCES Employé(NAS)
);

ALTER TABLE Département

ADD CONSTRAINT FK1_Dep1 FOREIGN KEY (NAS_Resp) REFERENCES Employé(NAS) ;

ALTER TABLE Employé

ADD CONSTRAINT FK2_Emp1 FOREIGN KEY (NAS_Sup) REFERENCES Employé(NAS) ;

/*Employé_LMD.sql*/

INSERT INTO Employé VALUES('Ben Ahmed','Ali',123456789,'090155','34 rue de la sambre,

Tunis', 'M', 300, Null, NULL) ;
INSERT INTO Employé VALUES ('Ben Ali','Mohamed',333445555,'081245','4 rue banaf-
sej , Rades', 'M', 400, NULL , NULL) ;
INSERT INTO Employé VALUES ('Ben Ali', 'Fethi',999887777,'190758','10 rue 2566, Ez-
zahra', 'M', 250, NULL, NULL)
INSERT INTO Employé VALUES ('Ben Salah','Alia',987654321,'200647','22 rue 65989
Hammam lif', 'F', 430, NULL , NULL) ;
INSERT INTO Employé VALUES ('Hergli', 'Faten',666884444,'151252','10 rue 10245 El
Menzeh', 'F', 380, NULL , NULL) ;

70
6.8 Exemple de script de BD

INSERT INTO Employé VALUES ('Sayadi', 'Iméne',453453453,'310762','22 rue el yassa-

mine El Manar2', 'F', 250, NULL, NULL) ;
INSERT INTO Employé VALUES ('Sayadi', 'Leila',987987987,'290359','10 rue 10254, Mont-
eury', 'F', 250, NULL, NULL) ;
INSERT INTO Employé VALUES ('Tlili','Salah',888665555,'101157','7 rue 14587, Tunis',
'M', 550, NULL, NULL) ;

INSERT INTO Département VALUES ('Recherche',5,333445555,'220578') ;

INSERT INTO Département VALUES ('Administration',4,987654321,'010185') ;
INSERT INTO Département VALUES ('Direction',1,888665555,'190671') ;

INSERT INTO Dep_Loc VALUES (1,'Tunis') ;

INSERT INTO Dep_Loc VALUES (4,'Monastir') ;
INSERT INTO Dep_Loc VALUES (5,'Sfax') ;
INSERT INTO Dep_Loc VALUES (5,'Sousse') ;
INSERT INTO Dep_Loc VALUES (5,'Tunis') ;

INSERT INTO Projet VALUES ('ProduitX',1,'Sfax',5) ;

INSERT INTO Projet VALUES ('ProduitY',2,'Sousse',5) ;
INSERT INTO Projet VALUES ('ProduitZ',3,'Tunis',5) ;
INSERT INTO Projet VALUES ('ProduitX1',10,'Monastir',4) ;
INSERT INTO Projet VALUES ('ProduitY1',20,'Tunis',1) ;
INSERT INTO Projet VALUES ('ProduitZ1',30,'Monastir',4) ;

INSERT INTO Travaille_sur VALUES (123456789,1,32.5) ;

INSERT INTO Travaille_sur VALUES (123456789,2,7.5) ;
INSERT INTO Travaille_sur VALUES (666884444,3,40.0) ;
INSERT INTO Travaille_sur VALUES (453453453,1,20.0) ;
INSERT INTO Travaille_sur VALUES (453453453,2,10.0) ;
INSERT INTO Travaille_sur VALUES (333445555,2,10.0) ;
INSERT INTO Travaille_sur VALUES (333445555,3,10.0) ;
INSERT INTO Travaille_sur VALUES (333445555,10,10.0) ;
INSERT INTO Travaille_sur VALUES (333445555,20,10.0) ;
INSERT INTO Travaille_sur VALUES (999887777,30,30.0) ;
INSERT INTO Travaille_sur VALUES (999887777,10,10.0) ;
INSERT INTO Travaille_sur VALUES (987987987,10,35.0) ;
INSERT INTO Travaille_sur VALUES (987987987,30,5.0) ;
INSERT INTO Travaille_sur VALUES (987654321,30,20.0) ;
INSERT INTO Travaille_sur VALUES (987654321,20,15.0) ;
INSERT INTO Travaille_sur VALUES (888665555,20,Null) ;

INSERT INTO Dépendant VALUES (333445555,'Ali','M','050286','Fils') ;

INSERT INTO Dépendant VALUES (333445555,'Zeineb','F','051088','Fille') ;
INSERT INTO Dépendant VALUES (333445555,'Ridha','M','030590','Fils') ;
INSERT INTO Dépendant VALUES (987654321,'Sami','M','200289','Fils') ;
INSERT INTO Dépendant VALUES (123456789,'Saloua','F','150386','Fille') ;
INSERT INTO Dépendant VALUES (123456789,'Taouk','M','100685','Fils') ;
INSERT INTO Dépendant VALUES (123456789,'Sami','M','100690','Fils') ;

71
 Chapitre 6 : SQL : un langage de BD relationnelle

UPDATE Employé SET NAS_Sup= 333445555,No_Dept= 5 WHERE NAS=123456789 ;

UPDATE Employé SET NAS_Sup= 888665555,No_Dept= 5 WHERE NAS=333445555 ;
UPDATE Employé SET NAS_Sup= 987654321,No_Dept= 4 WHERE NAS=999887777 ;
UPDATE Employé SET NAS_Sup= 888665555,No_Dept= 4 WHERE NAS=987654321 ;
UPDATE Employé SET NAS_Sup= 333445555,No_Dept= 5 WHERE NAS=666884444 ;
UPDATE Employé SET NAS_Sup= 333445555,No_Dept= 5 WHERE NAS=453453453 ;
UPDATE Employé SET NAS_Sup= 987654321,No_Dept= 4 WHERE NAS=987987987 ;
UPDATE Employé SET No_Dept= 1 WHERE NAS=888665555 ;

72
 Bibliographie
[Akoka & Comyn-Wattiau 2001] J. Akoka et I. Comyn-Wattiau. Conception des bases de
données relationnelles. Vuibert, 2001.
[Bowman et al. 2002] J.-S. Bowman, S.-L. Emerson et M. Darnovsky. SQL. Campus Press,
2002.
[Date 2004] J. Date. Introduction aux bases de données. Vuibert, 2004.
[Gabillaud 2004] J. Gabillaud. SQL et algèbre relationnelle. ENI, Nantes, 2004.
[Garcia-Molina et al. 2002] H. Garcia-Molina, J. D. Ullman et J. Widow. Database sys-
tems, the complete book. Prentice Hall, 2002.
[Gardarin 1993] G. Gardarin. Maîtriser les bases de données. Eyrolles, Paris, 1993.
[Gardarin 1999] G. Gardarin. Bases de données : objet et relationnel. Eyrolles, Paris, 1999.
[Gardarin 2003] G. Gardarin. Bases de données. Eyrolles, Paris, 2003.
[Grissa-Touzi 2000] A. Grissa-Touzi. Cours de Bases de Données. PhD thesis, École Na-
tionale d'Ingénieurs de Tunis, 2000.
[LeMaitre 2014] J. LeMaitre. Bases de données. [Link]
supports-cours/[Link], 2014.
[Melton & Simon 2002] J. Melton et A. R. Simon. SQL : 1999 understanding relational
language components. Morgan Kaufman Publishers, 2002.
[Pratt 2001] P.-J. Pratt. Initiation à SQL - cours et exercices corrigés. Eyrolles, Paris,
2001.
[Serge & José-Maria 1984] M. Serge et B. José-Maria. L'art des bases de données. 1., in-
troduction aux bases de données. Eyrolles, Paris, 1984.
[UVT 2007] UVT. Bases de données. Université Virtuelle de Tunis, Tunis, Tunisie, 2007.
 Index
Symbols Contraintes de cardinalité . . . . . . . . . . . . . . . 15
1 Forme Normale (1FN) . . . . . . . . . . . . . . . . . 50 Contraintes de participation . . . . . . . . . . . . . 17
2 Forme Normale (2FN) . . . . . . . . . . . . . . . . . 50 Contraintes de participation . . . . . . . . . . . . . 15
3 Forme Normale (3FN) . . . . . . . . . . . . . . . . . 50 Contraintes sémantiques . . . . . . . . . . . . . . . . . 26
Contraintes structurelles. . . . . . . . . . . . . . . . .15
A COUNT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44, 61
ADD CONSTRAINT. . . . . . . . . . . . . . . . . . . .55 Couverture minimale . . . . . . . . . . . . . . . . . . . . 49
Algorithme de décomposition en 3FN . . . . 51 CREATE TABLE . . . . . . . . . . . . . . . . . . . . . . . 53
ALL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 CREATE VIEW . . . . . . . . . . . . . . . . . . . . . . . . 66
ALTER TABLE . . . . . . . . . . . . . . . . . . . . . . . . . 54
Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 D
Association Plusieurs-à-Plusieurs . . . . . . . . 28 Décomposition . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Association Un-à-Plusieurs . . . . . . . . . . . . . . 27 Décomposition d'une relation . . . . . . . . . . . . 46
Association Un-à-Un . . . . . . . . . . . . . . . . . . . . 27 Décomposition sans perte . . . . . . . . . . . . . . . 47
Associations n-aires . . . . . . . . . . . . . . . . . . . . . 29 Dépendance fonctionnelle . . . . . . . . . . . . . . . . 47
Attribut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 Dépendance fonctionnelle élémentaire . . . .48
Attribut dérivé . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Dépendance fonctionnelle canonique . . . . . 48
Attribut mono-valué . . . . . . . . . . . . . . . . . . . . .14 DELETE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56
Attribut multi-valué . . . . . . . . . . . . . . . . . . . . . 14 Diérence . . . . . . . . . . . . . . . . . . . . . . . . . . . 35, 36
Augmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 DISABLE CONSTRAINT. . . . . . . . . . . . . . .55
AVERAGE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44 DISTINC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
AVG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 DISTINCT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Division relationnelle . . . . . . . . . . . . . . . . 35, 41
B Division relationnelle . . . . . . . . . . . . . . . . . . . . 64
Base de données . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Domaine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Base de données . . . . . . . . . . . . . . . . . . . . . . . . . . 2 DROP COLUMN . . . . . . . . . . . . . . . . . . . . . . . 55
BD relationnelle . . . . . . . . . . . . . . . . . . . . . . . . . 23 DROP CONSTRAINT . . . . . . . . . . . . . . . . . . 55
BETWEEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 DROP TABLE . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Biunivocité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 DROP VIEW . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

C E
Cardinalité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 ENABLE CONSTRAINT . . . . . . . . . . . . . . . 55
CASCADE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Entité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
CHECK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Entité faible/forte . . . . . . . . . . . . . . . . . . . . . . . 17
Clé étrangère . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Entité mère . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Clé candidate . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Entités lles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Clé d'une relation . . . . . . . . . . . . . . . . . . . . . . . 25 Modèle Entités/Associations . . . . . . . . . . . . . . 6
Clé de relation . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Équi-jointure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Clé primaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17 EXCEPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Classe d'entités . . . . . . . . . . . . . . . . . . . . . . . . . .14 EXISTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Classe de relations. . . . . . . . . . . . . . . . . . . . . . .14
CONTAINS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 F
Contraintes d'intégrité référentielles . . . . . 26 Fermeture transitive . . . . . . . . . . . . . . . . . . . . . 49
Contraintes d'intégrité sur une entité . . . . 26 Fonctions arithmétiques . . . . . . . . . . . . . . . . . 42
INDEX

Fonctions de groupe . . . . . . . . . . . . . . . . . . . . . 42 Modèle réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Fonctions sur caractères . . . . . . . . . . . . . . . . . 44 Modèle relationnel . . . . . . . . . . . . . . . . . . . . . . . . 6
FOREIGN KEY. . . . . . . . . . . . . . . . . . . . . . . . .54
Forme normale de Boyce-Codd (BCNF) . 50 N
n-uplet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
G n-uplets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
GRANT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Niveau conceptuel . . . . . . . . . . . . . . . . . . . . . . . . 5
Graphe de dépendances fonctionnelles . . . 48 Niveau externe . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
GROUP BY. . . . . . . . . . . . . . . . . . . . . . . . . . . . .61 Niveau interne . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
NOT CONTAINS . . . . . . . . . . . . . . . . . . . . . . . 57
H NOT EXISTS . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
HAVING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 NOT IN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57
NOT NULL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
I
Identieur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 O
Identieur minimal . . . . . . . . . . . . . . . . . . . . . . 17 Occurrence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Identieur primaire . . . . . . . . . . . . . . . . . . . . . . 17 ORDER BY. . . . . . . . . . . . . . . . . . . . . . . . . . . . .62
Identieur privilégié . . . . . . . . . . . . . . . . . . . . . 17
IN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 P
Indépendance logique . . . . . . . . . . . . . . . . . . . . . 7 PRIMARY KEY . . . . . . . . . . . . . . . . . . . . . . . . 54
Indépendance physique . . . . . . . . . . . . . . . . . . . 7 Produit cartésien. . . . . . . . . . . . . . . . .23, 35, 36
INDEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Projection . . . . . . . . . . . . . . . . . . . . . . . . . . . 35, 37
INSERT INTO . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Projection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
INTERSECT. . . . . . . . . . . . . . . . . . . . . . . . . . . .60 Pseudo-transitivité . . . . . . . . . . . . . . . . . . . . . . 48
Intersection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
IS NOT NULL . . . . . . . . . . . . . . . . . . . . . . . . . . 57 R
IS NULL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Réexivité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . 54
J Relation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14
Jointure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35, 38 Relation biunivoque . . . . . . . . . . . . . . . . . . . . . 15
Jointure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Renommage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Jointure naturelle . . . . . . . . . . . . . . . . . . . . . . . 39 Requête récursive . . . . . . . . . . . . . . . . . . . . . . . 64
Requêtes imbriquées . . . . . . . . . . . . . . . . . . . . . 63
L Restriction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Langage d'Interrogation de Données (LID) REVOKE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
53
Langage de Contrôle de Données (LCD) . 53 S
Langage de Dénition de Données (LDD)53 Sélection. . . . . . . . . . . . . . . . . . . . . . . . . . . . .35, 36
Langage de Manipulation de Données (LMD) Sélection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
53 Schéma conceptuel . . . . . . . . . . . . . . . . . . . . . . . 5
Lien biunivoque . . . . . . . . . . . . . . . . . . . . . . . . . 15 Schéma de relation . . . . . . . . . . . . . . . . . . . . . . 24
Lien fonctionnel . . . . . . . . . . . . . . . . . . . . . . . . . 16 Schéma physique . . . . . . . . . . . . . . . . . . . . . . . . . 5
Lien hiérarchique . . . . . . . . . . . . . . . . . . . . . . . . 15 Schémas externes . . . . . . . . . . . . . . . . . . . . . . . . . 5
LIKE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Sous-requête . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
SUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44, 61
M Système de Gestion de Bases de Données
MAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44, 61 (SGBD) . . . . . . . . . . . . . . . . . . . . . . . . . 3
MIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44, 61 Système de gestion de chiers. . . . . . . . . . . . .3
MINUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Modèle Entités/Relations . . . . . . . . . . . . . . . . . 6 T
Modèle hiérarchique . . . . . . . . . . . . . . . . . . . . . . 6 Théorème de Heath . . . . . . . . . . . . . . . . . . . . . 49

75
 INDEX

Théta-jointure . . . . . . . . . . . . . . . . . . . . . . . . . . .39
Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Transitivité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
tuple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

U
UNION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Union . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35, 48
Union-compatibilité . . . . . . . . . . . . . . . . . . . . . 35
UNIQUE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
UPDATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

V
VARIANCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

76
INDEX

[Gardarin 1999, Serge & José-Maria 1984, Gardarin 2003, Melton & Simon 2002, Date 2004,
Garcia-Molina et al. 2002, UVT 2007, LeMaitre 2014, Akoka & Comyn-Wattiau 2001, Bow-
man et al. 2002, Pratt 2001, Gardarin 1993, Gabillaud 2004, Grissa-Touzi 2000]

77
 INDEX

78