Poly BD Partial 2019

Introduction aux bases de
données relationnelles
Pour les étudiants des licences en informatique
Ahmed Zinedine
2018/2019
Introduction aux bases de données
relationnelles
Pour les étudiants des licences en informatique
Ahmed Zinedine
2018/2019
A. Zinedine Introduction aux bases de données relationnelles
Présentation du polycopié
Ce cours est destiné aux étudiants de des licences en informatique. Il donne une
introduction générale sur les bases de données relationnelles. Nous avons
partagé ce polycopié en 3 parties :
Dans la première partie, qui contient le chapitre 1, nous avons présenté des
généralités sur les bases de données et sur les SGBD.
La deuxième partie contient trois chapitres consacrés au modèle relationnel.

Ainsi, dans le chapitre 2, nous avons présenté les concepts de base de ce modèle,
le chapitre 3 est consacré aux opérateurs de l’algèbre relationnelle, tandis que le
chapitre 4 traite la notion de normalisation d’un schéma relationnel.
La troisième partie qui contient le chapitre 5 présente les notions fondamentales
du langage de requêtes SQL.
Un chapitre complémentaire présente certains objets de base de données que

l’étudiant peut envisager dans les SGBD les plus diffusés.
Ahmed Zinedine
Pour toute remarque, suggestion ou correction, merci de contacter l’auteur par email
sur l’adresse : ahmed.zinedine@usmba.ac.ma
3
4
Table des Matières

Partie 1 : Généralités sur les bases de données............................................... 7
Chapitre 1 : Généralités sur les bases de données..................................................... 9
0. Introduction........................................................................................................................................................ 9
1. Définitions........................................................................................................................................................... 10
2. Fonctions d’un SGBD..................................................................................................................................... 10
3. Les différents niveaux de représentation d’une base de données...................................................... 11
4. Modèles de données......................................................................................................................................... 13
5. Le concept d’indépendance données/programmes ................................................................................ 14
6. Mise en œuvre d’une base de données....................................................................................................... 14
Résumé.................................................................................................................................................................... 16
Partie 2 : Le modèle relationnel.......................................................................... 17

Chapitre 2 : Concepts de base du modèle relationnel............................................... 19
1. Relation, domaine, attribut, tuple ............................................................................................. 20
2. Identifiants : Clé candidate, clé primaire, clé étrangère............................................................ 21
3. Intégrité d’entité, intégrité référentielle.................................................................................... 23
4. Schéma relationnel................................................................................................................... 23
Résumé......................................................................................................................................... 24
Chapitre 3 : L’algèbre relationnelle........................................................................... 25
1. La projection............................................................................................................................. 25
2. La sélection (ou restriction)..................................................................................................... 26
3. L’union..................................................................................................................................... 27
4. L’intersection........................................................................................................................... 28
5. La différence............................................................................................................................. 28
6. La division............................................................................................................................... 28
7. Le produit cartésien.................................................................................................................. 29
8. La θ-Jointure............................................................................................................................. 29
9. La jointure naturelle.................................................................................................................. 30
Résumé.......................................................................................................................................... 32
Chapitre 4 : Normalisation d’un schéma relationnel............................................... 33
1. Problèmes liés à une mauvaise conception.............................................................................. 33
a) Problème de redondance...................................................................................... 34
b) Anomalies de mise à jour ..................................................................................... 34
c) Anomalie de l’insertion et de la suppression........................................................ 34
2. Dépendances fonctionnelles .................................................................................................... 34
a) Définitions............................................................................................................. 34
b) Propriétés des dépendances fonctionnelles........................................................... 35
c) Graphe des dépendances fonctionnelles (GDF)................................................... 35
d) Dépendances fonctionnelles et identifiants........................................................... 36
3. Normalisation............................................................................................................................ 36
a) Décomposition sans perte de données.................................................................. 36
b) Décomposition sans perte de dépendances.......................................................... 37
4. Formes Normales...................................................................................................................... 37
a) Première Forme Normale (1FN)........................................................................... 37
5
b) Deuxième Forme Normale (2FN)......................................................................... 37

c) Troisième Forme Normale (3FN)......................................................................... 38
Résumé.......................................................................................................................................... 39
Partie 3 : Le langage SQL..................................................................................... 41
Chapitre 5 : Le langage SQL...................................................................................... 43
1. Langage de Définition de Données ........................................................................................ 43
a) Créer une table............................................................................................... 44
b) Modifier une table.......................................................................................... 45
c) Supprimer une table........................................................................................ 45
2. Langage de manipulation de données....................................................................................... 45
a) L’instruction insert ........................................................................................ 45
b) L’instruction update........................................................................................ 46
c) L’instruction delete........................................................................................ 46
d) L’instruction Select......................................................................................... 47
Clause where............................................................................................ 47
Clause where avec les opérateurs AND et OR ........................................ 47
Clause where avec l’opérateur NOT........................................................ 47
Clause where avec l’opérateur BETWEEN.............................................. 47
Clause where avec l’opérateur IN........................................................... 48
Clause where avec l’opérateur LIKE....................................................... 48
Clause order by…………………………………………………………. 48
Fonctions d’agrégation............................................................................. 48
La clause GROUP BY – HAVING............................................................ 49
3. SQL et Opérations relationnelles ............................................................................................. 49
Résumé ......................................................................................................................................... 51
Exercices ...................................................................................................................................... 52
Complément : Objets de bases de données............................................................... 55
1. Tables ....................................................................................................................................... 55
2. Vues ......................................................................................................................................... 55
3. Index ........................................................................................................................................ 56
4. Procédures et fonctions stockées ............................................................................................. 56
5. Déclencheurs ............................................................................................................................ 56
6. Privilèges.................................................................................................................................. 56
7. Rôles ......................................................................................................................................... 57
Résumé ........................................................................................................................................ 58
6
Partie 1
Généralités sur les bases de données
7
8
Chapitre 1 : Généralités sur les bases de

données
Dans ce chapitre, nous allons étudier les concepts suivants :

 La notion de base de données et de SGBD ;
 Les fonctions d’un SGBD ;
 Les différents niveaux de représentation d’une base de données ;
 Le concept de modèle de données ;
 Le concept d’indépendance données/programmes.
0. Introduction
Avez-vous pensé comment les gestionnaires d’une banque font pour traiter toutes ces
quantités de données qu’ils ont à gérer quotidiennement avec une très grande efficacité et
fiabilité ? Comment une entreprise importante peut gérer des millions d’enregistrements
concernant ses clients, ses fournisseurs, ses employés… ? Comment par exemple une société
de télécommunication qui compte des millions d’abonnés peut gérer toutes les informations
sur les abonnés, sur le personnel,…et sur des centaines de milliers d’appels simultanés chaque
instant ?
A partir du moment où les utilisateurs ont disposé d’ordinateurs, on a immédiatement pensé à
exploiter la force de traitement de ces machines et on s’est posé la question de savoir
comment les données pouvaient être archivées et extraites des organes périphériques des
ordinateurs.
Au début, l’approche gestion de fichiers régnait. Dans cette approche, les fichiers sont définis
pour un ou plusieurs programmes de traitement. Les données d’un fichier sont directement
associées à un programme par une description contenue dans le programme de traitement lui-
même.
Mais ces fichiers, qui ont été construits pour répondre aux besoins des applications
informatiques possèdent la plupart du temps des éléments communs, des associations qui ne
sont pas exploitées du fait qu’ils sont utilisés isolément et indépendamment les uns des autres.
Ces limitations concernant l’utilisation des fichiers ont poussé l’évolution vers une nouvelle
approche : l’approche base de données.
Dans cette approche, la partie de structuration et description de données est unifiée et séparée
des programmes d’application. Bien sûr la gestion de ces données (stockage, modification,
recherche,…) qui est étroitement dépendante de leur structuration, est fournie par le système
de gestion de base de données. Les programmes d’application ne communiquent avec les
données qu’au travers de ce système. D’où l’indépendance entre les données et les
applications, qui peuvent être modifiées indépendamment.
Outre les limitations de l’approche gestion de fichiers, d’autres facteurs ont été à l’origine du
concept de base de données :
9
 L’évolution des entreprises (volumes importants de données, centralisées ou réparties,

qui doivent être accessibles en un temps utile,…).
 L’évolution technologique (accroissement des performances et diminution des
coûts,…).
 L’évolution des systèmes d’exploitation et des architectures (extension logicielle du
matériel initial, les SE réalisent une machine virtuelle très puissante qui définit un
environnement pour des langages de haut niveau,…).
1. Définitions
Une base de données est un ensemble structuré de données enregistrées dans un ordinateur
et accessibles simultanément par plusieurs utilisateurs de façon sélective et en un temps
opportun.
N.B. Ne pas confondre une base de données avec une banque de données. Une banque de
données représente un ensemble d’informations mémorisées par un ordinateur concernant un
domaine scientifique, économique ou culturel donné, et cela d’une façon aussi exhaustive que
possible.
Un système de gestion de base de données (SGBD) est un logiciel qui permet à l’utilisateur
d’interagir avec une base de données.
2. Fonctions d’un SGBD

Un SGBD est une interface entre l’utilisateur et la base de données. Tout utilisateur ou
programme d’application doit passer obligatoirement par le SGBD pour communiquer avec la
base de données. Ainsi, pour pouvoir utiliser cette base de données, le SGBD doit fournir les
fonctions suivantes :
1) Description des données : Le SGBD doit mettre à la disposition de l’utilisateur un

outil pour décrire l’ensemble des données qui seront stockées et organisées dans la
base de données. Il fournit pour cela un langage dit Langage de description de données
(LDD).
2) Manipulation des données : Le SGBD doit fournir toutes les procédures nécessaires
à l’insertion des données dans la base, à la modification et à la suppression de ces
mêmes données et répondre à toute demande d’information portant sur les données
contenues dans la base. Un langage de manipulation de données (LMD) est mis à la
disposition des utilisateurs.
3) Intégrité : Plus la masse d’informations enregistrées dans une base de données est
grande, plus le risque que les données enregistrées soient erronées par rapport à la
réalité. Pour diminuer ce risque et pour maintenir la validité et la cohérence des
données, le SGBD doit offrir à l’utilisateur la possibilité d’exprimer toutes les règles
qui contraignent les valeurs pouvant être enregistrées dans la base de façon à éviter
toute erreur. Par exemple dans une application de gestion universitaire:
• Un étudiant ne peut être inscrit deux fois dans un même module.
• On ne peut pas programmer deux cours dans la même salle dans le même
horaire.
• La date de naissance d’un étudiant ne peut pas être supérieure à la date
courante !!
10
• Les notes doivent être comprises entre 0 et 20.

Ces règles qu’on doit pouvoir exprimer s’appellent des contraintes d’intégrité. Elles
correspondent à des propriétés qui devront toujours être vérifiées quelles que soient les
valeurs enregistrées dans la base de données.
4) Confidentialité : Du fait que la base de données est partagée par plusieurs utilisateurs,
certains sous-ensembles de données ne doivent être accessibles que par des personnes
réellement autorisées. Le SGBD doit donc protéger toute information contre tout accès
par des utilisateurs non autorisés. Il doit offrir à ce stade un mécanisme qui permet de
vérifier les droits d’accès (ou privilèges, ou encore autorisations).
5) Sécurité : En cas de panne matérielle ou logicielle telle que panne de l’ordinateur,

erreur de programmation, coupure de courant…, il ne faut pas que les informations
soient perdues. Lorsque la panne est supprimée, le SGBD doit pouvoir remettre la base
de données dans un état cohérent. Pour cela, les SGBD offrent la possibilité de
sauvegarder périodiquement les données et les restaurer au cas de besoin. En plus, ils
enregistrent dans des fichiers spéciaux (dits journaux) toutes les opérations effectuées.
En cas de panne, le SGBD consulte ces journaux et reproduit à nouveau ces
opérations.
6) Gestion de la concurrence : Il ne faut pas qu’une action faite par un utilisateur soit
perdue du fait d’une autre action faite simultanément par un autre utilisateur.
Supposons, par exemple, qu’un compte bancaire contient la somme 10000 DH. Deux
utilisateurs veulent ajouter à ce compte respectivement 30000 DH et 20000 DH.
Temps Utilisateur 1 Utilisateur 2
t1 Lire S
t2 Lire S
t3 S = S + 30000
t4 S = S +20000
t5 Ecrire S
t6 Ecrire S
Les deux utilisateurs ont entré leurs modifications mais seule la dernière est retenue. La
première a été écrasée par la dernière ! Les deux utilisateurs ont lu la variable S qui
contient dans notre cas la valeur 10000. Le premier utilisateur a modifié S en ajoutant
30000. Mais avant de sauvegarder, le deuxième utilisateur ajoute à S la valeur 20000
(pour cet utilisateur S contient encore 10000). Hélas ! Même si l’utilisateur 1 va
sauvegarder, S ne contiendra à la fin que 10000 +20000. Les 30000 DH de l’utilisateur 1
sont donc perdus !
Pour éviter les problèmes de ce genre qui sont causé par l’accès concurrent aux mêmes
données, le SGBD doit offrir des mécanismes pour contrôler l’accès des utilisateurs aux
données en cours de modification par d’autres utilisateurs.
3. Les différents niveaux de représentation d’une base de données
On distingue trois niveaux de représentation d’une base de données suivant que l’on regarde
plus du côté de l’utilisateur que du côté du stockage physique des données :
1. Le niveau interne à qui correspond le schéma interne.
2. Le niveau conceptuel à qui correspond le schéma conceptuel.
3. Le niveau externe à qui correspond le schéma externe.
11
Monde réel
Processus de
Modélisation
Groupe
Utilisateurs1 Schéma
externe 1
Groupe
Schéma Schéma Schéma
Utilisateurs2
externe 2 Conceptuel interne
Groupe Schéma
Utilisateurs3 externe 3
Niveau externe Niveau conceptuel Niveau Interne
Figure 1.1 : les différents niveaux d’une base de données
1) Le niveau interne
Le schéma interne a pour but de spécifier comment les données seront stockées sur les
supports de stockage (disques, bandes,…). Le SGBD gère donc à ce niveau les structures de
mémorisation (Fichiers) et aussi les structures d’accès aux données (gestion des index, gestion
des clés,…).
2) Le niveau conceptuel
Le schéma conceptuel est la partie fondamentale dans l’architecture d’un système de base de
données. Il a pour but de décrire en terme abstrait, mais fidèle une certaine réalité d’une
organisation et de ses processus de gestion qui nécessitent la mise en œuvre d’une base de
données.
Pour passer du monde réel au schéma conceptuel, on passe par un processus de modélisation.
Le SGBD fournit un langage de définition de données qui permet de décrire les données tout
en respectant ce qu’on appelle un modèle de données (voir le paragraphe suivant).
Un modèle de données est un outil formel utilisé pour comprendre et interpréter le monde
réel.
Lors de ce processus de modélisation, les objets du monde réel sont classés en catégories et
désignés par des noms. Par exemple, si on s’intéresse aux étudiants dans une application de
gestion universitaire, on pourra considérer une classe d’objets dénommée ETUDIANT. Par la
suite on ne fera référence aux étudiants que par l’intermédiaire de ce nom. Un modèle de
données permettra aussi de décrire les associations qui peuvent exister entre classes d’objets.
Par exemple, l’inscription est un phénomène qui associe un étudiant à un ou plusieurs
modules, dans ce cas on nommera par exemple INSCRIPTION l’association entre la classe
ETUDIANT et la classe MODULE.
12
Pour résumer les notions introduites, on peut dire que le schéma conceptuel est le résultat
d’une action de modélisation du monde réel qui respecte un modèle de données à l’aide des
termes et des expressions permises par le langage de définition de données.
3) Le niveau externe
Les données sont centralisées logiquement et sont partagées par tous les utilisateurs. Mais
chaque utilisateur ne doit « voir » que la partie de la base qui l’intéresse. Par exemple dans
une base de données universitaire, une personne chargée d’inscrire les étudiants, ne peut
« voir » que les informations concernant les étudiants et les modules. Cette personne n’a pas
besoin de savoir par exemple les salaires des fonctionnaires de l’université. De sa part,
l’étudiant peut accéder aux informations concernant les horaires des cours qu’il suit, mais il
n’est pas autorisé de modifier les notes.
Bref, chaque utilisateur voit une partie des données et ne peut pas voir le reste.
Le niveau externe correspond aux différentes façons dont les utilisateurs peuvent voir les
données. La représentation de la base est donc composée de plusieurs schémas externes (ou
vues).
4. Modèles de données
Comme nous l’avons dit précédemment, un modèle de données est un outil formel utilisé pour
comprendre et interpréter le monde réel. On peut dire que c’est un ensemble de concepts et de
règles de composition de ces concepts permettant de décrire des données. Il doit être
suffisamment puissant pour capter la sémantique des données et représenter le lien qui existe
entre elles.
Tout SGBD repose sur un modèle de données. On distingue plusieurs modèles.
Historiquement, les premiers SGBD étaient de type hiérarchique, puis sont apparus les SGBD
de type réseau. Actuellement, la plupart des SGBD qui dominent le marché sont de type
relationnel. Des SGBD de type « Objet » commencent à apparaître sur le marché.
a) Modèle hiérarchique
Les données sont représentées sous forme d’une structure arborescente d’enregistrements.
Cette structure est conçue avec des pointeurs et détermine le chemin d’accès aux données.
b) Modèle réseau
La structure des données peut être visualisée sous forme d’un graphe quelconque. Comme
pour le modèle hiérarchique, la structure est conçue avec des pointeurs et détermine le chemin
d’accès aux données.
Pour les modèles hiérarchiques et réseau, les programmes d’application dépendent étroitement
de la structure logique de la base et de chemin d’accès aux données : le programmeur doit
décrire dans son programme comment on doit naviguer dans la base pour retrouver les
données, et si par exemple on enlève un index, tous les programmes qui l’utilisent doivent être
réécrits. De plus le langage de travail est complexe.
c) Modèle relationnel
Il est fondé sur la théorie mathématique des relations. Il conduit à une représentation très
simple des données sous forme de tables constituées de lignes et de colonnes. Il n’y a plus de
pointeurs qui figeaient la structure de la base.
Ce modèle offre :
13
--- une représentation simple de données (sous forme de tables)

--- des langages assertionnels et non procéduraux : l’utilisateur se contente de demander les
données qu’il veut et c’est le SGBD qui se charge de déterminer comment fournir le résultat.
--- une meilleure indépendance entre les données et les programmes.
d) Modèle objet
Les données sont représentées sous forme d’objets au sens donné par les langages orientés
Objet : les données sont enregistrées avec les fonctions et procédures qui permettent de les
manipuler. Les SGBDOO (SGBD Orientés Objet) supportent aussi la notion d’héritage entre
classes d’objets.
Le développement rapide des langages orientés objet a mis en avant les SGBDOO qui
permettent la sauvegarde directe des objets manipulés par ces langages. Cependant les
SGBDOO ne sont utilisés actuellement que pour des usages bien spécifiques et il n’existe pas
de normes communément admises.
Les SGBDR reposent sur une théorie formelle plus solide que les SGBDOO. Ils sont aussi
plus souples pour répondre aux interrogations de la base non prévues au départ.
5. Le concept d’indépendance données/programmes

Nous avons dit dans l’introduction de ce chapitre que l’un des points les plus faibles de
l’approche classique de gestion de fichiers était la dépendance entre les données et les
programmes. A chaque fois qu’une modification se produit sur la structure des données ou sur
leur organisation physique, tous les programmes accédant à ces données doivent être réécrits
pour pouvoir continuer à fonctionner. En effet, le code de tels programmes devait prendre en
charge la structure des données et les méthodes d’accès à ces mêmes données.
Donc parmi les raisons d’apparition des bases de données était de trouver une solution à ce
problème de dépendance entre les données et les programmes. En tant qu’interface entre les
utilisateurs (les programmes) et la base de données, Les SGBD assurent l’indépendance
données/programmes.
L’architecture à trois niveaux d’une base de données présentée précédemment suggère deux
types d’indépendances :
a) L’indépendance physique On entend par ceci que l’administrateur de la base de données

peut modifier le schéma physique sans influencer sur le schéma conceptuel (ni sur le schéma
externe par suite). Par exemple, et pour des raisons d’efficacité, l’administrateur peut décider
de modifier l’organisation physique des données ou ajouter un index pour accélérer la
recherche et tout cela, sans aucune modification des programmes d’application.
b) L’indépendance logique : elle a pour but de permettre la modification du schéma

conceptuel (par exemple en ajoutant des nouvelles classes d’objets ou des nouvelles
associations entre classes) sans nécessiter de modifier les programmes d’application.
6. Mise en œuvre d’une base de données

La première phase est la phase conceptuelle dans laquelle on fait une abstraction du monde
réel pour déterminer le schéma conceptuel de la future base de données tout en respectant un
modèle de données. Plusieurs acteurs interviennent en suite :
14
a) L’administrateur de la base de données : c’est la personne responsable de bon

fonctionnement de la base et de sa sécurité. Il joue un rôle fondamental à la fois durant la
conception de la base et durant son utilisation courante. Il est responsable de :
 Construire le schéma conceptuel (en utilisant des instructions du langage LDD) ;
 Construire le ou les schémas externes nécessités par les différentes applications ;
 Définir les droits d’accès qui seront alloués à chaque utilisateur afin de préserver
la confidentialité ;
 Spécifier les organisations physiques des données, ainsi que des méthodes d’accès
qui seront utilisées ;
 Mettre en œuvre des procédures permettant d’assurer un niveau de sécurité de
fonctionnement satisfaisant en s’appuyant sur les mécanismes fournis par le
SGBD (par exemple la sauvegarde périodique de la base, l’archivage des
journaux…).
b) Les programmeurs des applications : ils écrivent les applications qui vont interagir avec
la base de données à travers les différents schémas externes. Ils incluent dans leur code des
instructions du langage LMD (langage de manipulation de données) qui fournissent toutes les
opérations prévues par l’application. D’ailleurs, on peut interagir directement avec la base en
formulant des requêtes écrites par ce LMD.
c) Les utilisateurs finaux : ils sont le plus souvent non informaticiens, et donc non capables
de formuler des requêtes en LMD. Ils interagissent avec la base en exécutant des programmes
effectuant des tâches prédéfinies.
15
Résumé
Une base de données est un ensemble structuré de données enregistrées dans un ordinateur et accessibles
simultanément par plusieurs utilisateurs de façon sélective et en un temps opportun.
Un SGBD est un logiciel qui permet d’interagir avec une base de données. Il assure principalement les fonctions
suivantes :
1. La description des données ;
2. La manipulation des données ;
3. L’intégrité des données ;
4. La confidentialité ;
5. La sécurité ;
6. La gestion de la concurrence.
On distingue trois niveaux de représentation d’une base de données:
1. Le niveau interne avec le schéma interne : on s’intéresse à ce niveau au stockage physique des données
et aux méthodes d’accès à ces données.
2. Le niveau conceptuel avec le schéma conceptuel : C’est le résultat d’une action de modélisation du
monde réel qui respecte un modèle de données à l’aide des termes et des expressions permises par le
langage de définition de données.
3. Le niveau externe avec le schéma externe : il correspond aux différentes façons dont les utilisateurs
peuvent voir les données. La représentation de la base est donc composée de plusieurs schémas externes
(ou vues).
Un modèle de données est un outil formel utilisé pour comprendre et interpréter le monde réel. Voilà quelques
exemples :
--- le modèle hiérarchique : Les données sont représentées sous forme d’une structure arborescente.
--- le modèle réseau : Les données sont vues comme un graphe quelconque.
Ces deux modèles (qui sont dépassés) utilisent des pointeurs et nécessitent la détermination des chemins d’accès.
Donc ils figent la structure de la base, et les programmes sont dépendants de la structure des données.
--- le modèle relationnel : Représente les données sous forme de tables. Parmi ses points forts :
• La représentation simple des données ;
• S’appuie sur un fondement mathématique solide ;
• Utilise des langages non procéduraux.
--- le modèle Objet : il utilise la notion d’objet utilisée dans les langages orientés objet (tels que java).
Indépendance données/programmes : C’est pour exprimer le fait de pouvoir modifier la structure des données
et leur organisation physique sans être obligé de modifier les programmes d’application.
Les intervenants :
 L’administrateur de la base de données : c’est la personne responsable de bon fonctionnement
de la base et de sa sécurité. Il joue un rôle fondamental à la fois durant la conception de la base
et durant son utilisation courante.
 Les programmeurs des applications : ils écrivent les programmes d’application en incluant
dans leur code des instructions du langage LMD.
 Les utilisateurs finaux : ils sont le plus souvent non informaticiens, et interagissent avec la
base en exécutant des programmes effectuant des tâches prédéfinies.
16
Partie 2
Le modèle relationnel
17
18
Chapitre 2 : Concepts de base du modèle

relationnel
Le modèle relationnel a prouvé son importance et il domine actuellement le marché des SGBD. Dans ce chapitre
nous allons étudier les concepts de base de ce modèle :
 Relation, domaine, attribut, tuple (ou occurrence) ;
 Clé candidate, clé primaire, clé secondaire, clé étrangère ;
 Schéma d’une relation, extension d’une relation ;
 Intégrité d’entité, intégrité référentielle ;
 Schéma relationnel.
Pendant les années 60, tous les SGBD étaient de type hiérarchique ou réseau. Ces modèles
présentaient des limites surtout au niveau de l’indépendance données/programmes et au
niveau de la manipulation des données : ces SGBD sont dits de type « navigationnel », car
l’utilisateur doit savoir naviguer dans la base de données pour retrouver la donnée qu’il
souhaite.
Vers 1970, un chercheur d’IBM, E. F. Codd, a proposé un nouveau modèle basé sur la théorie
mathématique des relations, c’est le modèle relationnel. Parmi les objectifs principaux de ce
modèle il y a :
 Utiliser des structures de données simples et issues de la vie courante (tables) ;
 Assurer l’indépendance données/programmes ;
 Proposer des langages de haut niveau (4ème génération) utilisable par des utilisateurs
non informaticiens.
Supposons par exemple que nous voulons stocker des informations sur des hommes et leurs
femmes. On considère donc l’ensemble H des hommes et l’ensemble F des femmes et la
relation R (H, F) qui, à un moment donné, peut être schématisée comme suit :
H F
Omar Fatiha
Mehdi Fatima
Abdellah Saida
Figure 2.1
19
On dit donc que la relation R a deux attributs H et F. Les n-uplets (n=2 dans ce cas) (Omar,
Fatiha), (Mehdi, Fatima) et (Abdellah, Saida) sont des tuples (ou occurrences) de la relation
R.
Pour être plus précis, donnons quelques définitions :
1. Relation, domaine, attribut, tuple

Un domaine est un ensemble de valeurs, par exemple le domaine des entiers est N = {0,
1,2,…}, le domaine des couleurs du drapeau marocain est l’ensemble {rouge, vert}.
Une relation entre n domaines D1, D2, …, Dn est un sous-ensemble du produit cartésien
D1×D2×…×Dn. Une relation peut donc être vue comme un ensemble de n-uplets de la forme
(a1, a2,…, an) où ai ∈ Di. n est appelé le degré de la relation. Les (a1, a2,…, an) sont appelés
les tuples ou occurrences de la relation.
Plusieurs domaines peuvent être identiques (par exemple D1=D2). Pour différencier les
domaines et rendre l’ordre sans importance, on associe à chaque domaine Di un nom Ai
différent de tous les autres Ai. Les Ai s’appellent les attributs de la relation R. On utilise la
notation suivante qui s’appelle le schéma de la relation : R (A1 : D1, A2 : D2, …, An : Dn) ou
tout simplement R (A1, A2, …, An).
Le schéma d’une relation est alors constitué par le nom de la relation et par la liste de ses
attributs [suivis de leurs domaines].
Une extension d’une relation est constituée du schéma de la relation et de l’ensemble de ses
tuples.
On peut représenter une relation par une table (on utilise souvent le terme table au lieu de
relation) dont les colonnes possèdent des noms. Les colonnes sont alors les attributs de la
relation et les lignes sont les tuples (ou occurrences) de cette relation.
Certains attributs peuvent ne pas être valués pour certains tuples à un instant donné. On dit
alors qu’ils ont la valeur NULL. Par exemple, un étudiant peut ne pas avoir un téléphone.
Exemple :
Considérons la relation :
Etudiant (NumEtudiant, Nom, Prénom, Age, Tél)
Nom de la relation Noms des attributs
Figure 2.2
On peut la voir à un instant donné sous la forme suivante :
20
Schéma de Etudiant
la relation
NumEtudiant Nom Prénom Age Tél
113 Slaoui Salwa 21 060000001

Tuple ou
202 Khaldouni Khalid 22 060000002
occurrence
567 Moussaoui Moussa 21 060070070
580 Moussi Moussa 22 NULL
309 Karimi Karim 20 066600005
310 Karimi Karima 20 NULL
Figure 2.3 : Une extension de la relation Etudiant.
2. Identifiants : Clé candidate, clé primaire, clé étrangère

Identifiant d’une relation Un ensemble, au sens mathématique, ne peut contenir des
éléments en double. Par exemple, on ne peut pas considérer {x, x, y, z} comme ensemble.
Une relation, étant par définition un ensemble au sens mathématique, ne peut contenir de
doublons. Donc les tuples d’une relation doivent différer par au moins un attribut (ou un
ensemble d’attributs). Dans l’exemple de la figure 2.3, les numéros des étudiants ne se
répètent pas, donc on peut considérer l’attribut NumEtudiant comme identifiant de la relation
Etudiant. De même l’ensemble d’attributs (Nom, Prénom) peut être considéré comme
identifiant de cette relation car, dans notre cas, deux étudiants n’ont jamais les mêmes nom et
prénom.
Un ensemble minimal d’attributs qui peut servir d’Identifiant d’une relation s’appelle clé
candidate. Dans notre cas, NumEtudiant est une clé candidate, la même chose est vraie pour
(Nom, Prénom).
Le concepteur de la base de données doit choisir une parmi les clés candidates et la désigner
comme clé primaire. Une clé primaire est donc une clé candidate renommée
« officiellement » comme identifiant de la relation.
Dans le schéma d’une relation, on souligne l’attribut (ou les attributs) retenu(s) comme clé
primaire. Par exemple, si nous avons retenu l’attribut NomEtudiant comme clé primaire de la
relation Etudiant, son schéma sera noté Etudiant (NumEtudiant, Nom, Prénom, Age, Tél).
Identifiant externe ou clé étrangère : C’est un attribut d’une relation qui est clé primaire
dans une autre relation.
Prenons l’exemple de notre base de données universitaire qui contient, parmi d’autres
relations, la relation Etudiant et la relation Module(CodeModule, NomModule,
VolumeHoraire) et la relation Inscrit(NumEtudiant, CodeModule) qui maintient
l’association entre les étudiants et les modules dans lesquels ils sont inscrits. Représentons ces
deux relations sous forme de tables :
21
Etudiant
NumEtudiant Nom Prénom Age Tél
113 Slaoui Salwa 21 060000001
Clé primaire 202 Khaldouni Khalid 22 060000002
567 Moussaoui Moussa 21 060070070
580 Moussi Moussa 22 NULL
309 Karimi Karim 20 066600005
310 Karimi Karima 20 NULL
Inscrit
NumEtudiant CodeModule
113 BD Clé primaire
202 BD
202 SE
Clé étrangère
202 ARCH
580 BD
580 SE
Module
CodeModule NomModule VolumeHoraire
BD Bases de données 45
Clé primaire
SE Systèmes d’exploitation 45
SI Système d’information 45
ARCH Architecture des ordinateurs 45
22
3. Intégrité d’entité, intégrité référentielle

a) L’intégrité d’entité signifie que les valeurs de clés primaires doivent être uniques (sans
doublons) et n’acceptent pas la valeur NULL.
b) L’intégrité référentielle signifie qu’à chaque fois qu’une relation fait référence à une autre
relation, une « contrainte de référence » existe. Par exemple, (1000, BD) ne peut pas être
accepté comme tuple de la table Inscrit ci-dessus, car aucun tuple de la table Etudiant n’a
1000 comme numéro. Autrement dit, puisque l’attribut NumEtudiant de la table Inscrit fait
référence à l’attribut NumEtudiant de la table Etudiant, le SGBD doit veiller de n’accepter
dans la table Inscrit que les tuples qui correspondent à des enregistrements réellement
existants dans la table Etudiant.
4. Schéma relationnel
Un Schéma relationnel se compose de l’ensemble des schémas des relations constituant la
base de données et des contraintes d’intégrité. C’est à dire, il est constitué de :
 Pour Chaque relation :
• Nom de la relation ;
• Liste des attributs de la relation avec leurs domaines ;
• Clé primaire ;
• Clés étrangères (éventuellement) ;
• Contraintes d’intégrité associées.
 D’autres contraintes d’intégrité qui portent sur plusieurs relations.
23
Résumé
Les SGBD des années 60 qui étaient de type hiérarchique ou réseau présentaient des limites surtout au niveau de
l’indépendance données/programmes et au niveau de la manipulation des données : En effet, ces SGBD étaient
de type « navigationnel », c’est à dire que l’utilisateur doit naviguer dans la base de données pour retrouver la
donnée qu’il souhaite.
En 1970, Codd a introduit le modèle relationnel qui, dès lors, prouvait son importance et qui domine
actuellement le marché des SGBD.
Parmi les points forts de ce modèle :
 Il se base sur un fondement mathématique solide (la théorie des relations) ;
 Il utilise des structures de données simples et issues de la vie courante (tables) ;
 Il assure l’indépendance données/programmes ;
 Il propose des langages de haut niveau (4ème génération) utilisables par des utilisateurs non
informaticiens.
Voilà quelques définitions qui donnent les concepts de base de ce modèle :
Relation
Un domaine est un ensemble de valeurs, par exemple, le domaine des couleurs du drapeau marocain est
l’ensemble {rouge, vert}.
Une relation entre n domaines D1, D2, …, Dn est un sous-ensemble du produit cartésien
D1×D2×…×Dn. Les éléments de ce sous-ensemble sont alors de la forme (a1, a2,…, an) (avec ai ∈ Di)
et sont appelés les tuples ou occurrences de la relation.
On associe à chaque domaine Di un nom Ai différent de tous les autres Ai. Les Ai s’appellent les
attributs de la relation R.
Le schéma d’une relation est alors constitué par le nom de la relation et par la liste de ses attributs
[suivis de leurs domaines] : R (A1 : D1, A2 : D2, …, An : Dn) ou tout simplement R (A1, A2, …, An).
Une extension d’une relation est constituée du schéma de la relation et de l’ensemble de ses tuples (à
un instant donné).
On peut représenter une relation par une table dont les colonnes sont les attributs de la relation et les
lignes sont ses tuples.
Clés
Une occurrence (un tuple) ne peut être stockée deux fois dans une même relation car une relation est un
ensemble au sens mathématique. Il existe donc au moins un sous-ensemble d’attributs de la relation qui
permet de différencier les occurrences. Un tel sous-ensemble, quand il est minimal, s’appelle clé
candidate (ou identifiant) de la relation.
On choisit arbitrairement une clé candidate et on la désigne clé primaire.
Une clé étrangère est un attribut d’une relation R qui est désigné clé primaire d’une autre relation R’.
Intégrité
L’intégrité d’entité : les valeurs d’une clé primaire doivent être uniques (pas de doublons) et différents
de la valeur NULL (c’est à dire ne peuvent être laissées vides).
L’intégrité référentielle signifie qu’à chaque fois qu’une relation fait référence à une autre relation,
une « contrainte de référence » existe : on ne peut pas faire référence à un enregistrement qui n’existe
pas.
Un Schéma relationnel se compose de l’ensemble des schémas des relations constituant la base de données
et des contraintes d’intégrité.
24
Chapitre 3 : L’algèbre relationnelle
Pour répondre aux requêtes des utilisateurs, un SGBDR fait des opérations relationnelles sur des relations pour
obtenir en résultat d’autres relations. Nous allons voir dans ce chapitre les principales opérations relationnelles
suivantes :
 La sélection ;
 La projection ;
 L’union ;
 L’intersection ;
 La différence ;
 La division ;
 Les produits (produit cartésien, θ-jointure, jointure naturelle…).
Nous avons déjà dit que parmi les points forts des SGBD relationnels il y a le fait qu’ils
offrent des langages de manipulation de données assertionnels et non procéduraux, c’est à dire
que l’utilisateur se contente de demander au SGBD une requête sans se préoccuper de préciser
comment trouver le résultat. Autrement dit, l’utilisateur demande le « Quoi » et c’est le SGBD
qui se charge du « Comment ».
Ceci est, en effet, possible grâce aux langages relationnels utilisés par ces SGBD. Parmi ces
langages il y a les langages algébriques qui reposent sur les opérateurs de l’algèbre
relationnelle introduite par Codd. L’idée est de pouvoir répondre à toute requête par
application d’un ou plusieurs opérateurs relationnels à certaines relations pour obtenir en
résultat une autre relation qui répond à la requête.
Les opérateurs algébriques sont de deux types :
1) Opérateurs unaires qui portent sur une seule relation. Les plus importants de cette
catégorie :
 La sélection ;
 La projection.
2) Opérateurs binaires qui portent sur deux relations. Parmi ceux-ci il y a :
 L’union ;
 L’intersection ;
 La différence ;
 La division ;
 Les produits (produit cartésien, jointures,…).
1. La projection
La projection d’une relation R (A1, A2,…, An) sur les attributs Ai1, Ai2,…Aip est une
relation R’ de schéma R’ (Ai1, Ai2,…Aip) et dont les tuples sont ceux de R après élimination
des valeurs des attributs qui n’appartiennent pas à R’ et suppression des tuples en double.
Dans ce cours nous utiliserons la notation : R’ = π Ai1, Ai2,...Aip (R).
25
Donc, la projection est une opération unaire qui consiste à supprimer des colonnes d’une
relation.
Exemple 1 : « donnez les numéros, noms et prénoms des étudiants ».
La projection de la relation Etudiant sur NumEtudiant, Nom, Prénom donne la relation
Etudiant_2 suivante :
Etudiant_2
NumEtudiant Nom Prénom
113 Slaoui Salwa
202 Khaldouni Khalid
567 Moussaoui Moussa
580 Moussi Moussa
309 Karimi Karim
310 Karimi Karima
Figure 2.5 : Etudiant_2 = π NumEtudiant, Nom, Prénom (Etudiant)

Exemple 2 :
La projection de la relation Etudiant_2 (ou de Etudiant) sur Nom, Age donne la relation
Etudiant_3 suivante :
Etudiant_3
Nom Age
Slaoui 21
Khaldouni 22
Moussaoui 21
Moussi 22
Karimi 20
Figure 2.6 : Etudiant_3 = π Nom, Age (Etudiant_2)

Remarquez qu’un seul Karimi existe dans cette table, les enregistrements en double sont
supprimés.
2. La sélection ou (restriction)
La restriction d’une relation R par une condition C est une relation R’ dont les tuples sont
ceux de R qui vérifient la condition C. On note alors R’ = σC (R)
26
Autrement dit, la sélection (ou la restriction) est une opération unaire qui consiste à supprimer
d’une relation R les tuples qui ne satisfont pas à une condition donnée C.
Exemple : « Donnez les noms des étudiants qui sont âgés de 21 ans »
On applique alors une sélection sur la relation Etudiant_3, avec la condition C : « Age =21 »
pour obtenir la relation Etudiant_4 suivante :
Etudiant_4
Nom Age
Slaoui 21
Moussaoui 21
Figure 2.7 : Etudiant_4 = σ Age = 21 (Etudiant_3)
3. Union
C’est une opération binaire qui porte sur deux relations R1 et R2 qui ont (obligatoirement) les
mêmes attributs. Elle consiste à fusionner les deux relations en une seule relation R3. On note
R3 = R1 U R2.
Par exemple, la relation Sportif est le résultat de la requête « Trouvez les personnes qui sont
footballeurs ou athlètes » :
Footballeur Athlète
Nom Age Nom Age
Kaddour 21 Kaddour 21
Jalloul 22 Guerrouj 22
Jarray 18
Sportif
Nom Age
Kaddour 21
Jalloul 22
Guerrouj 22
Jarray 18
Figure 2.8 : Sportif = Footballeur U Athlète

Remarquez que Kaddour n’apparaît qu’une seule fois dans la relation résultante.
4. Intersection
27
mêmes attributs. Elle consiste à ne garder dans la relation résultante R3 que les tuples
communs aux deux relations. On note R3 = R1 ∩ R2.
Exemple : L’intersection des deux relations précédentes Footballeur et Athlète est la relation
Sportif_plus suivantes :
Sportif_plus
Nom Age
Kaddour 21
Figure 2.9 : Sportif_plus = Footballeur ∩ Athlète
5. Différence
mêmes attributs. La relation résultante R3 est constituée des tuples de R1 qui n’appartiennent
pas à R2.On note alors R3 = R1 - R2.
Exemple : La différence entre Sportif et Athlète est la relation Footballeur_seulement
suivante :
Footballeur_seulement
Nom Age
Jalloul 22
Figure 2.10 : Footballeur_seulement = Sportif – Athlète

6. Division
Cette opération « divise » une relation R1 par une relation R2 qui contient exclusivement des
attributs de R1. Il s’agit de déterminer les occurrences de la première relation qui sont
associées à toutes les occurrences de la seconde.
Exemple : Considérons les deux relations suivantes :
R1 R2
Etudiant Module Module
Ali BD BD
Ali SE SE
Ali ARCH ARCH
Omar BD
Samir SE
Le résultat de la division de R1 par R2 est la relation R3 suivante :
28
R3
Etudiant
Ali
Figure 2.11 : R3 = R1 ÷ R2
Dans la relation R3, les attributs de R2 sont supprimés de ceux de R1 (ici l’attribut module
n’apparaît pas dans R3) et on ne garde que les étudiants qui sont inscrits dans tous les
modules (ici : Ali).
7. Produit cartésien
Le produit cartésien de deux relations R1 et R2 est une relation R3 qui possède tous les
attributs de R1 et R2 à la fois, et dont les tuples sont constitués par toutes les combinaisons
possibles.
Exemple :
R1 R2
Ouvrage Qualité
livre bon
magazine mauvais
R3
Ouvrage Qualité
livre bon
livre mauvais
magazine bon
magazine mauvais
Figure 2.12 : R3 = R1 × R2
8. θ-Jointure
La θ-jointure (thêta-jointure), où θ est l’un des opérateurs <, >, =, ≠, est une opération qui
applique à deux relation R1 et R2 un produit cartésien suivi d’une sélection. On ne retient que
les occurrences qui vérifient une condition logique.
Exemple
29
Employé Chef
Nom Salaire Nom Salaire
Emp1 6000 Ch1 7000
Emp2 3000 Ch2 5000
Emp3 2000
Supposons que nous voulons répondre à la requête : « Trouver les employés qui gagnent
plus qu’un chef de service ». Alors on utilise une θ-jointure où θ est l’opérateur >. Donc, on
procède comme suit :
1) on construit le produit cartésien de Employé et Chef :
Relation_intermédiaire
Employé.Nom Employé.Salaire Chef.Nom Chef.Salaire
Emp1 6000 Ch1 7000
Emp1 6000 Ch2 5000
Emp2 3000 Ch1 7000
Emp2 3000 Ch2 5000
Emp3 2000 Ch1 7000
Emp3 2000 Ch2 5000
2) On ne retient que les Occurrences pour lesquelles Employé.salaire > Chef.Salaire :
Résultat1
Employé.Nom Employé.Salaire Chef.Nom Chef.Salaire
Emp1 6000 Ch2 5000
C’est le résultat de la θ-jointure des deux relations, impliquant les deux attributs
Employé.Salaire et Chef.Salaire et où θ est l’opérateur >.
9. Jointure naturelle
La jointure naturelle est un cas particulier de la θ-jointure. C’est le cas où θ est l’égalité (=) et
les deux attributs impliqués dans la jointure sont égaux.
Exemple :
30
Employé Service
NumEmployé Nom NumService NumService NomService
25 Emp1 1 1 Informatique
83 Emp2 2 2 Comptabilité
17 Emp3 1 3 Vente
57 Emp4 4 4 Achat
Pour répondre à une question de type « Donner les employés et leurs services », on fait alors
une jointure naturelle sur l’attribut NumService (le même dans les deux tables), l’opérateur de
jointure étant l’égalité . On obtient la relation suivante:
Résultat2
NumEmployé Nom NumService NomService
25 Emp1 1 Informatique
83 Emp2 2 Comptabilité
17 Emp3 1 Informatique
57 Emp4 4 Achat
Remarquez que le service « vente » qui ne contient aucun employé (actuellement) n’est pas
présent dans le résultat de la jointure. De même, cette relation est le résultat d’un produit
cartésien suivi d’une opération de sélection.
31
Résumé
Pour répondre aux requêtes des utilisateurs, un SGBDR fait des opérations relationnelles sur des relations pour
obtenir en résultat d’autres relations.
Les opérateurs relationnels sont de deux types :
Opérateurs unaires qui portent sur une seule relation. Les plus importants de cette catégorie :
 La projection : c’est une opération qui élimine certains attributs d’une relation
 La sélection : c’est une opération qui élimine certains tuples d’une relation
Opérateurs binaires qui portent sur deux relations. Parmi ceux-ci il y a :

 L’union
C’est une opération qui fusionne deux relations qui ont (obligatoirement) les mêmes attributs et élimine
les doublons de la relation résultante.
 L’intersection
c’est une opération qui s’applique à deux relations qui ont les mêmes attributs et ne garde que les tuples
communs.
 La différence
R1-R2 est une relation R3 qui contient les tuples de R1 qui n’appartiennent pas à R2.
 La division
R1 ÷ R2 (avec les attributs de R2 sont tous des attributs de R1) est une relation R3 dont les attributs sont
ceux de R1 qui ne sont pas des attributs de R2 et dont les occurrences sont ceux de R1 qui sont
associées à toutes les occurrences de R2.
 Le produit cartésien
consiste à construire une relation avec toutes les combinaisons possibles entre les occurrences de deux
relations.
 La θ-jointure
le résultat de cette opération sur deux relations R1 et R2 est une relation qui ne retient des occurrences
du produit cartésien que les tuples qui vérifient une condition comparant un attribut de R1 et un attribut
de R2. (La comparaison utilise l’opérateur θ, celui-ci étant =, >, <,..).
 La jointure naturelle
Quand la comparaison porte sur un attribut commun et θ est l’égalité, on parle alors de la jointure
naturelle.
32
Chapitre 4 : Normalisation d’un schéma

relationnel
Un schéma relationnel mal conçu peut provoquer de graves problèmes lors de l’évolution de la base de données
(par exemple lors de la mise à jour). Le présent chapitre a pour objectif de montrer comment normaliser un
schéma relationnel pour éviter de tels problèmes. Nous allons étudier les thèmes suivants :
 Exemples de problèmes causés par une mauvaise conception ;
 La notion de dépendances fonctionnelles et certaines propriétés ;
 Normalisation : décomposition sans perte de données, décomposition sans perte de dépendances ;
 Formes normales : 1FN, 2FN, 3FN,…
1. Problèmes liés à une mauvaise conception

Etant donné un ensemble de données à représenter dans une base de données relationnelle,
quelle est la structure adéquate pour ce faire ?
Nous allons voir que, si l’on n’y prend garde, une mauvaise répartition des données dans les
relations peut occasionner de graves problèmes lors de l’évolution de la base. Nous verrons
comment normaliser des relations pour éviter ces problèmes.
Prenons par exemple notre application de gestion universitaire. Revoir la page 22 pour noter
quelles sont les relations utilisées pour représenter les étudiants, les modules et les
associations entre les étudiants et les modules. Supposons maintenant que, et à cause d’une
MAUVAISE conception, nous avons adopté la solution suivante :
Etudiant_Module
NumEtudiant Nom Prénom Age Tél CodeModule NomModule VolumeHoraire
113 Slaoui Salwa 21 060000001 BD Bases de données 45
202 Khaldouni Khalid 22 060000002 BD Bases de données 45
202 Khaldouni Khalid 22 060000002 Systèmes

SE 45
d’exploitation
202 Khaldouni Khalid 22 060000002 Architecture des

ARCH 45
ordinateurs
580 Moussi Moussa 22 NULL BD Bases de données 45
580 Moussi Moussa 22 NULL Systèmes

SE 45
d’exploitation
Cette relation souffre de plusieurs problèmes et elle va poser pas mal d’anomalies lors de
l’évolution de la base de données (par exemple, lors de l’insertion, la mise à jour ou la
suppression d’enregistrements) :
33
a) Problème de redondance : remarquez que les informations sur l’étudiant de numéro 202
(nom, prénom, âge…) sont répétées ici 3 fois ; de même, les informations sur l’étudiant 580
sont répétées 2 fois. Pire que ça, les informations sur un module vont se répéter autant de fois
qu’il y a d’étudiants inscrits dans ce module. Donc c’est un gaspillage inutile de l’espace de
stockage.
b) Anomalies de mise à jour : le gaspillage de l’espace disque n’est pas le seul problème ;
car la redondance cause des anomalies. Prenons un exemple : si un étudiant change son
numéro de téléphone, il est fort probable de le modifier dans des enregistrements et ne pas le
modifier dans les autres ce qui touche à la cohérence de la base de données :
202 Khaldouni Khalid 22 066666666 BD Bases de données 45
202 Khaldouni Khalid 22 066666666 SE Systèmes d’exploitation 45
202 Khaldouni Khalid 22 060000002 ARCH Architecture des ordinateurs 45
c) Anomalies de l’insertion et de la suppression : Remarquez que nous avons perdu avec

cette structure toutes les informations sur les étudiants qui ne sont pas encore inscrits en un
module (par exemple les étudiants 567, 309 et 310). De même, toute information sur les
modules non encore choisis par les étudiants (par exemple le module SI) est absente de la
base de données.
On ne peut pas insérer un étudiant dans la base tant qu’il n’est pas inscrit en un module au
moins, et il est supprimé de la base dès qu’il valide le dernier module.
Bref, la structure ci-dessus n’est pas adéquate pour une bonne représentation de ces données.
Le problème vient du fait qu’on a « mélangé » des données qui sont « indépendantes » les
unes des autres. Par exemple :
Le téléphone de l’étudiant, en fait, n’a rien à voir avec les modules dont lesquels l’étudiant est
inscrit. On peut modifier le téléphone sans influencer sur les inscriptions ; de même on peut
modifier ces inscriptions sans influencer sur le numéro de téléphone. A vrai dire, le numéro de
téléphone ne dépend que de l’étudiant, représenté par son NumEtudiant ou par son Nom et
Prénom. En effet, le NumEtudiant détermine d’une façon unique le numéro de téléphone.
Pour passer d’une « Mauvaise » structure à une structure adéquate et éviter les problèmes
desquels nous avons parlé, on normalise toutes les relations de la base de données pour
obtenir un schéma relationnel normalisé.
L’idée essentielle de la normalisation est « un seul fait dans un seul lieu », c’est à dire « une
seule notion sémantique par relation ». Pour obtenir cela, le processus de normalisation
conduit le plus souvent à éclater des relations en plusieurs relations. Il existe plusieurs degrés
dans les formes normales que nous allons étudier dans ce chapitre. Cette notion de forme
normale repose sur la notion de clé que nous avons déjà vue et sur la notion de dépendances
fonctionnelles.
2. Dépendances fonctionnelles
a) Définitions
Soient X et Y deux attributs d’une relation R. On dit que X détermine Y (ou que Y dépend de
X) si toute valeur de l’attribut X détermine une valeur au plus pour l’attribut Y. On dit alors
qu’il y a dépendance fonctionnelle entre les attributs X et Y. La source de cette dépendance
est X et la cible c’est Y. On note X → Y.
34
Dans le cas où X détermine Y, alors si des tuples de la relation R ont les mêmes valeurs pour
l’attribut X alors ils ont obligatoirement les mêmes valeurs pour l’attribut Y :
R X Y Z
x1 y1 z1
x2 y2 z2
x1 y1 z3
x1 y1 z4
x2 y2 z5
x6 y6 z6
On peut généraliser la définition précédente en prenant X et Y comme étant un ensemble

d’attributs. Par exemple dans la table Etudiant que nous utilisons, l’ensemble d’attributs
(Nom, Prénom) détermine de façon unique l’attribut Age, et il détermine aussi l’attribut
téléphone ainsi que l’attribut NumEtudiant.
b) Propriétés des dépendances fonctionnelles
Quand on a un ensemble de dépendance fonctionnelle, on peut en déduire d’autres
dépendances fonctionnelles en appliquant les règles suivantes :
 Réflexivité : si Y ⊆ X alors X → Y.
Par exemple : (Nom, Prénom) → Nom.
 Augmentation : X → Y  XZ → YZ
Par exemple : (Nom, Prénom) → Age  (Nom, Prénom, Tél) → (Age, Tél).
 Transitivité : X → Y et Y → Z  X → Z.
 Union X→ Y et X → Z  X → YZ
Par exemple, NumEtudiant → Nom et NumEtudiant → Prénom donc NumEtudiant →
(Nom, Prénom).
On ne s’intéresse dans la suite qu’aux dépendances fonctionnelles élémentaires, c’est à dire
non déduites d’autres dépendances fonctionnelles en utilisant les règles ci-dessus.
c) Graphe des dépendances fonctionnelles (GDF)
Pour chaque table, on cherche les dépendances fonctionnelles intéressantes. Il sera alors plus
facile de les représenter sous forme de graphe appelé graphe des dépendances fonctionnelles.
Exemple 1 : Considérons la relation R (A, B, C, D, E) avec les dépendances fonctionnelles
suivantes : E → A, E → B, E → C et C → D. Alors on peut représenter ces dépendances
fonctionnelles par le graphe suivant :
E
A B C
35
Exemple 2 : Considérons la relation :

Inscription (NumEtudiant, Nom, Prénom, CodeModule, NomModule, DateInscription)
Alors on a les dépendances fonctionnelles suivantes :
NumEtudiant → Nom
NumEtudiant → Prénom
CodeModule → NomModule
(NumEtudiant, CodeModule) → DateInscription (car il faut connaître l’étudiant et le module
pour déterminer la date de l’inscription).
On aboutit donc au graphe de dépendances fonctionnelles suivant :
Nom Prénom DateInscription NomModule
d) Dépendances fonctionnelles et identifiants

Le graphe minimum des dépendances fonctionnelles permet de trouver les identifiants de la
table. Ainsi, l’identifiant (ou clé) d’une table est l’ensemble minimal des nœuds du graphe
minimum à partir desquels on peut atteindre tous les autres nœuds (via les dépendances
fonctionnelles).
Dans l’exemple 1 ci-dessus, à partir du nœud E du graphe des dépendances fonctionnelles, on
peut atteindre tous les autres nœuds. Donc E est l’identifiant de la relation R.
Dans l’exemple 2, à partir des deux nœuds NumEtudiant et CodeModule, on atteint tous les
autres nœuds. Donc (NumEtudiant, CodeModule) est une clé (identifiant) de la relation
Inscription.
3. Normalisation
Nous avons déjà dit que la solution des anomalies citées au début de cette section consiste à
normaliser toutes les relations de la base de données. Le processus de normalisation consiste à
décomposer les relations susceptibles d’engendrer des anomalies en plusieurs sous-relations
(C’est à dire des relations obtenues à partir de la relation d’origine par des projections, donc
contiennent moins d’attributs).
Mais, une « bonne » décomposition est une décomposition qui se passe :
 Sans perte de données ;
 Sans perte de dépendances fonctionnelles
a) Décomposition sans perte de données
Une décomposition en plusieurs relations est dite sans perte de données si la jointure naturelle
des relations obtenues redonne la relation de départ.
Attention ! : Il ne faut jamais faire une décomposition avec perte de données car les
informations contenues dans la base seront alors fausses et il serait impossible de rétablir les
bonnes données.
36
Théorème important
Soit R (A, B, C) une relation avec les dépendances fonctionnelles A → B et B → C. Alors la
décomposition de R en les relations R1 (A, B) et R2 (B, C) est sans perte de données. C’est à
dire, la jointure naturelle de R1 (A, B) et R2 (B, C) redonne R (A, B, C).
b) Décomposition sans perte de dépendances
Soit une relation R qui est décomposée en deux relations R1 et R2. La projection de
l’ensemble des dépendances de R sur la relation R1 s’obtient en ne gardant des dépendances
de départ de R que celles dont les attributs (de la source et de la destination) sont des attributs
de la relation R1.
Une décomposition en plusieurs relations est dite « sans perte de dépendances » si on peut
trouver logiquement (par exemple par transitivité) les dépendances de départ à partir de la
projection de l’ensemble de dépendances de départ sur la relation de la décomposition.
Si on décompose une relation en plusieurs relations avec perte de dépendances, on ne peut
travailler indépendamment dans chacune des relations de la décomposition sans s’occuper des
autres relations. Lors des mises à jour, on ne peut, en effet, s’assurer que les dépendances
« perdues » sont vérifiées qu’en consultant les autres relations, ce qui peut occasionner des
traitements coûteux.
Lorsque l’on a le choix entre plusieurs décompositions il faut évidemment préférer celles qui
préservent les dépendances. Mais une perte de dépendances est moins grave qu’une perte de
données et il y a même des cas où il faut choisir entre une perte de dépendances ou une perte
de normalisation.
Formes Normales
Les formes normales représentent un certain degré de normalisation des relations. Plus le
degré de normalisation d’une relation est élevé, plus elle est « bonne » et par suite elle pose
moins de problèmes lors de l’évolution de la base de données.
Les formes normales les plus utilisées sont au nombre de 6. Les formes normales numérotées
de 1 à 5 et la forme normale de Boyce-Codd. Nous nous contenterons dans ce cours d’étudier
les trois premières.
Première Forme Normale (1FN)
Une relation est en première forme normale si elle ne comporte pas d’attribut multivalué.
Remarque : Si on respecte la définition (mathématique) d’une relation, alors cette première
forme normale est automatiquement vérifiée.
Exemple de pseudo-relation qui n’est pas en première forme normale :
LIVRE (CodeLivre, Titre, Auteurs)
Ce n’est pas une « vraie relation » car l’attribut Auteurs n’est pas un attribut simple : il est
multivalué car un livre peut avoir plusieurs auteurs.
On peut décomposer cette pseudo-relation en deux relations qui sont en 1FN comme suit :
LIVRE (CodeLivre, Titre)
AUTEURS (CodeLivre, Auteur)
Deuxième Forme Normale (2NF)
Une relation est en deuxième forme normale (en 2NF) si :
37
a. La relation est en 1FN ;

b. Chaque attribut qui ne fait pas partie d’une clé candidate ne dépend pas d’un
sous-ensemble strict des attributs d’une clé candidate.
Remarque : Pour qu’une relation R ne soit pas en 2FN, il est nécessaire que R possède une
clé candidate composite (c’est à dire qui contient plusieurs attributs), par exemple (A1, A2) et
qu’il existe un autre attribut A3 tel que A1 → A3 (par exemple). Donc A3 ne dépend pas de la
totalité de la clé candidate.
Il est indispensable de chercher toutes les clés candidates pour vérifier si une relation est en
2FN.
Exemple
La relation INSCRIPTION (NumEtudiant, Nom, CodeModule) n’est pas en 2FN, car
(NumEtudiant, CodeModule) est une clé candidate ; l’attribut Nom ne dépend pas de la
totalité de la clé, il dépend seulement de l’attribut NumEtudiant.
Troisième Forme Normale (3FN)
Une relation est en 3FN si tout attribut qui n’appartient pas à une clé candidate ne peut
dépendre que d’une clé candidate.
Remarque :
Une relation en 3FN est nécessairement en 2FN (car une partie d’une clé n’est pas une clé).
Les dépendances fonctionnelles vers une rubrique qui appartient à une clé sont autorisées.
La 3FN permet d’éliminer des sous-relations incluses dans une relation.
Exemple : Fournisseur (NumFournisseur, Ville, Pays)
Avec le graphe de dépendances suivant :
NumFournisseur
Ville Pays
Cette relation n’est pas en 3FN car l’attribut Pays dépend de l’attribut non clé Ville. On doit la
décomposer en deux relations en 3FN :
R1 (NumFournisseur, Ville) et R2 (Ville, Pays).
On peut démontrer que l’on peut toujours normaliser un schéma en troisième forme normale
sans perte de données ni perte de dépendances.
Il existe d’autres formes normales : la forme normale de Boyce-Codd (BCNF), la 4FN, la
5FN.
Les trois premières formes normales sont les plus largement utilisées. Un schéma relationnel
en 3FN est « suffisamment bon ».
38
Résumé
On doit faire attention lors de la conception d’une base de données relationnelle car un schéma mal conçu peut
provoquer des problèmes et anomalies lors de l’évolution de la base.
Parmi les problèmes qui se posent le plus souvent :
 Le problème de la redondance : Stocker une même donnée plusieurs fois dans la base est une mauvaise
chose à éviter car d’une part, c’est un gaspillage de l’espace disque, d’autre part elle cause des
problèmes de mise à jour car il est possible de modifier la donnée redondante à un emplacement sans le
faire dans les autres.
 Des anomalies lors de la mise à jour, de l’insertion et de la suppression si il y a des données
indépendantes dans une même table.
Donc il ne faut pas « mélanger » des données qui sont « indépendantes » les unes des autres.
 Si on a des relations qui contiennent des données indépendantes (sémantiquement), alors on doit les
normaliser. C'est-à-dire les décomposer. Cette notion de normalisation est fortement liée à la notion de
dépendances fonctionnelles.
Soient X et Y deux attributs d’une relation R. On dit que X détermine Y (ou que Y dépend de X) si toute valeur
de l’attribut X détermine une valeur au plus pour l’attribut Y. On dit alors qu’il y a dépendance fonctionnelle
entre les attributs X et Y. La source de cette dépendance est X et la cible c’est Y. On note X → Y.
Les dépendances fonctionnelles possèdent les propriétés suivantes :
Réflexivité : si Y ⊆ X alors X → Y.
Augmentation : X → Y  XZ → YZ
Transitivité : X → Y et Y → Z  X → Z.
Union : X→ Y et X → Z  X → YZ.
Le graphe de dépendance fonctionnelle représente graphiquement les dépendances fonctionnelles qui existent
entre les attributs d’une relation. Par exemple, si on a une relation R (A, B, C, D, E) avec les dépendances
fonctionnelles suivantes : E → A, E → B, E → C et C → D. Alors le graphe des dépendances fonctionnelles est
le suivant :
E
A B C
D
Le graphe minimum des dépendances fonctionnelles permet de trouver les identifiants de la table. Ainsi,
l’identifiant (ou clé) d’une table est l’ensemble minimal des nœuds du graphe minimum à partir desquels on peut
atteindre tous les autres nœuds (via les dépendances fonctionnelles).
Pour normaliser une relation, on doit parfois la décomposer en plusieurs relations. Une « bonne » décomposition
est une décomposition qui se passe :
 Sans perte de données : c'est-à-dire que la jointure naturelle des relations obtenues redonne la relation
de départ.
 Sans perte de dépendances fonctionnelles : c'est-à-dire qu’on peut retrouver logiquement (par exemple
par transitivité) les dépendances de départ à partir de la projection de l’ensemble de dépendances de
départ sur les relations de la décomposition.
La perte de dépendances est moins grave que la perte de données. Cette dernière est à éviter absolument. Le
théorème suivant permet de faire des décompositions sans perte de données :
Théorème important
Soit R (A, B, C) une relation avec les dépendances fonctionnelles A → B et B → C. Alors la décomposition de R
en les relations R1 (A, B) et R2 (B, C) est sans perte de données. C’est à dire, la jointure naturelle de R1 (A, B)
et R2 (B, C) redonne R (A, B, C).
Formes Normales
Les formes normales représentent un certain degré de normalisation des relations. Plus le degré de normalisation
d’une relation est élevé, plus elle est « bonne » et par suite elle pose moins de problèmes lors de la mise à jour.
Première Forme Normale (1NF)
Une relation est en première forme normale si elle ne comporte pas d’attribut multivalué.
Exemple : LIVRE (CodeLivre, Titre, Auteurs) n’est pas en 1FN car l’attribut Auteurs n’est pas monovalué pour
tous les tuples :
CodeLivre Titre Auteurs
L1 Livre1 Auteur1_1
Auteur1_2
L2 Livre2 Auteur2
39
Deuxième Forme Normale (2NF)

Une relation est en deuxième forme normale (en 2NF) si :
a) La relation est en 1FN ;
b) Chaque attribut qui ne fait pas partie d’une clé candidate ne dépend pas d’un sous-ensemble strict
des attributs d’une clé candidate.
Nom DateInscription
Cette relation n’est pas en 2FN car l’attribut Nom ne dépend pas de la totalité de la clé.
Troisième Forme Normale (3FN)
Une relation est en 3FN si tout attribut qui n’appartient pas à une clé candidate ne peut dépendre que d’une clé
candidate.
NumFournisseur
Ville Pays
Cette relation n’est pas en 3FN car pays dépend d’un attribut non clé (Ville).
40
Partie 3
Le langage SQL
41
42
Chapitre 5 : Le langage SQL
La plupart des SGBDR (voire tous) offrent une interface SQL pour permettre aux utilisateurs de communiquer
avec la base de données. Nous allons voir ici les commandes essentielles de ce langage, à savoir :
 Les commandes de LDD : create, alter et drop ;
 Les commandes de LMD : insert, select, update et delete ;
 Pour l’instruction select, nous allons voir les différentes utilisations de cette instruction :
(select…from…where…group by…having…order by) ainsi que les fonctions d’agrégation ;
 Nous notons le lien entre SQL et le langage algébrique.
Le langage SQL (Structured Query langage) est un langage de 4ème génération qui permet la
description, l’interrogation et la manipulation des données. C’est un langage assertionnel (non
procédural), facile à utiliser par des utilisateurs non informaticiens. Le langage SQL est utilisé
actuellement par la plupart des SGBD relationnels pour toutes les interactions avec la base de
données.
Ce chapitre d’apprentissage de bases de SQL est très important. En effet, connaître SQL
permet de mieux comprendre le fonctionnement d’une base de données relationnelle.
Les commandes SQL peuvent être classées dans deux familles :
 Commandes de définition des données (LDD : Langage de définition de données).
Les commandes de cette famille permettent de créer, modifier et supprimer les objets
de bases de données (tels que les tables). Les principales commandes de cette
catégorie sont create, alter, et drop.
 Commandes de manipulation des données (LMD : Langage de manipulation des
données). Les commandes de cette famille permettent de manipuler les données d’une
base de données, par exemple, elles permettent d’insérer des enregistrements dans une
table, de mettre à jour ou de supprimer des lignes. Les principales commandes de cette
catégorie sont insert, select, update et delete.
1. Langage de Définition des Données

Les commandes de ce langage permettent de créer, modifier et supprimer des objets de bases
de données (voir le chapitre suivant). Dans notre cours, nous nous intéresserons uniquement
aux tables.
Une table est une représentation d’une relation de la base de données à un instant donné. Les
attributs de la relation et leurs domaines sont représentés respectivement par les colonnes de
la table et leurs types de données, les tuples de la relation sont représentés par les lignes de la
table.
Les principales commandes du LDD permettent de créer, modifier ou supprimer une table:
 create table nom_de_la_table…
 alter table nom_de_la_table…
 drop table nom_de_la_table…
43
a) Créer une table

Le langage LDD permet de créer le schéma de la table et d’exprimer certaines contraintes.
Dans un premier temps, nous allons voir comment créer le schéma d’une table. La syntaxe est
la suivante :
create table nom_de_la_table (champ1 type1, champ2 type2,…)
Pour être plus clair, donnons un exemple. Considérons la table suivante qui contient des
informations sur les clients d’une entreprise :
Client
Id_client Nom_client Ville Tel_client Date_naissance
1000 Omari Rabat 037333300 07/03/1975
1001 Moussa Fès 055757575 13/02/1973
1002 Soufiani Fès 055839373 12/01/1972
1003 Abid Casa 022131314 01/01/1974
1004 Hassoun Fès
1005 Brahimi Rabat
1006 ElMardi Fès
Remarques importantes
1) Le LDD ne permettra de créer que le schéma de la table. Les données proprement
dites sont manipulées par le LMD (voir paragraphe suivant).
2) La table a un nom (client).
3) Les différents champs (colonnes) contiennent des informations variées : par
exemple le champ date_naissance est une date ce qui est totalement différent du
champ ville qui contient une chaîne de caractères. Le champ id_client, à son tour,
ne peut contenir que des numéros. Le LDD doit donc permettre d’associer à un
champ son type de données. Voilà les types de données les plus utilisés pour les
champs d’une table : NUMBER (m, n), CHAR (n), VARCHAR (n), DATE
4) Certains champs peuvent rester vides (i.e. avoir des valeurs NULL) comme par
exemple le champ Tél_Client, qui peut être non disponible à un moment donné.
D’autres, doivent obligatoirement être non vides (NOT NULL), comme le cas du
champ Id_Client qui identifie d’une façon unique un client.
5) On doit aussi pouvoir indiquer un champ comme clé primaire, par exemple le
champ id_client dans notre cas.
44
Voilà maintenant l’instruction SQL qui permet de créer cette table :

Create table Client (id_client NUMBER (10) PRIMARY KEY,
nom_client CHAR(20) NOT NULL,
ville VARCHAR(30), tel_client NUMBER(9),
date_naissance DATE) ;
Cette commande a pour effet de créer une table nommée client avec cinq colonnes. Le champ
id_client par exemple est un nombre qui contient au maximum 10 chiffres, le champ
nom_client contiendra une chaîne de caractères de longueur fixe égale à 20 caractères. Même
si le nom d’un client ne contient que 10 caractères, le SGBD réserve physiquement 20. Par
contre, le champ ville est de type VARCHAR (30) qui accepte des chaînes de caractères de
longueur variable mais qui ne peut pas dépasser 30 caractères. Le SGBD ne réserve que
l’espace réellement occupé par cette chaîne. Le champ date_naissance est prêt à contenir une
date.
La clause NOT NULL est optionnelle. Les champs qui portent cette mention ne peuvent rester
non valués. Par exemple, dans notre cas, le SGBD n’acceptera pas d’insérer des
enregistrements avec le champ nom_client vide.
c) Modifier une table
Pour modifier la structure d’une table, par exemple pour ajouter des nouveaux champs ou
modifier des champs existants, on utilise l’instruction Alter table.
Exemple : Nous allons modifier notre table client :
1) En ajoutant un nouveau champ email_client ;
2) En modifiant le type du champ nom_client pour le rendre varchar (30)
La commande est la suivante :
alter table client ADD email_client VARCHAR (50),
MODIFY nom_client VARCHAR (30) ;
c) Supprimer une table
Pour supprimer une table définitivement de la base de données on utilise l’ordre SQL drop
table. Pour supprimer, par exemple, la table client on exécute cette commande :
drop table Client
2. Langage de manipulation des données

Nous avons vu que le langage de définition des données permet (parmi autres choses) de créer
le schéma d’une table. Nous allons étudier dans la suite le langage de manipulation de
données (LMD) qui permet de manipuler les données contenues dans les tables. Les
principales instructions de ce langage sont : insert, select, update et delete.
a) l’instruction insert :
L’instruction insert permet d’insérer des enregistrements dans une table. La syntaxe de cette
instruction est la suivante :
insert into nom_de_la_table values (champ1, champ2,…) ;
Par exemple, pour insérer les 4 premiers enregistrements de la table client ci-dessus, on
exécute la commande suivante :
insert into Client values (1000, ‘Omari’, ‘Rabat’, 037333300, 07/03/1975) ;
45
insert into Client values (1001, ‘Moussa’, ‘Fès’, 055757575, 13/02/1973) ;

insert into Client values (1002, ‘Soufiani’, ‘Fès’, 055839373, 12/01/1972) ;
insert into Client values (1003, ‘Abid’, ‘Casa’, 022131314, 01/01/1974) ;
Avec ces instructions, les champs insérés correspondent respectivement aux champs de la
table (dans l’ordre). Par exemple, dans la première instruction, la valeur 1000 correspond à
l’id_client, le deuxième champ (‘omari’) correspond au nom de client et ainsi de suite.
Si on ne veut pas respecter l’ordre, ou si on veut introduire des enregistrements avec des
champs manquants alors on doit préciser explicitement les champs concernés. Par exemple,
pour insérer les 3 derniers champs de la table client, on exécute les instructions suivantes :
insert into Client (id_client, nom_client, ville) values (1004, ‘Hassoun’, ‘Fès’) ;
insert into Client (id_client, nom_client, ville) values (1005, ‘Brahimi’, ‘Rabat’) ;
insert into Client (id_client, nom_client, ville) values (1006, ‘ElMardi’, ‘Fès’) ;
Remarques :
--- Remarquez que toutes les chaînes de caractères sont comprises entre simples quottes.
--- Dans SQL, s’il y a plusieurs instructions à exécuter, on marque la fin de chaque instruction
par un point-virgule.
b) Instruction update
Il est parfois nécessaire de modifier des données déjà stockées dans une table. Pour cela, on
utilise l’instruction update qui se compose de trois parties :
1. le mot clé update suivi de la table sur laquelle porte la modification. Cette partie est
obligatoire.
2. le mot clé set suivi d’une ou plusieurs colonnes contenant la valeur ou les valeurs à
modifier. Cette partie est aussi obligatoire.
3. le mot clé where suivi de critères de sélection pour sélectionner les lignes à modifier.
Cette partie est optionnelle.
Exemple : Modifier dans le champ ville toute valeur égale à « Casa » par la valeur
« Casablanca »
update client
set ville = ’Casablanca’
where ville = ’Casa’
c) L’instruction delete
Pour supprimer des enregistrements on utilise l’instruction delete qui comporte deux
parties
1. le mot clé delete from suivi du nom de la table qui contient les lignes à supprimer.
Cette partie est obligatoire.
2. le mot clé where qui permet d’exprimer les critères de sélection des lignes à
supprimer. Cette partie est optionnelle.
L’instruction suivante supprime de la table Client le client qui a l’id_client 1005 :
46
delete from client

where id_client = 1005
d) L’instruction Select
L’instruction select permet d’extraire des données d’une base de données en spécifiant les
critères de sélection. Cette instruction est la plus fréquemment utilisée. Elle est composée de
quatre parties principales :
1. Le mot clé select, suivi des colonnes que vous voulez afficher. On utilise le caractère *
pour désigner toute les colonnes d’une table. Cette partie est obligatoire.
2. le mot clé from suivi du nom d’une (ou plusieurs) table (ou vue) qui contient les
informations spécifiées dans la première partie. Cette partie est également obligatoire.
3. le mot clé where, qui définit les critères de sélection. Cette partie est optionnelle.
4. Le mot clé order by, suivi du critère de tri permet de trier les enregistrements du
résultat de la sélection suivant ce critère.
Clause where
Tandis que la clause select permet de sélectionner certaines colonnes, la clause where permet
de sélectionner certains enregistrements en se basant sur les critères spécifiés après le mot clés
where.
Par exemple, dans la table client ci-dessus, pour extraire les noms et les numéros de téléphone
de tous les clients dont la ville est Fès on exécute la commande :
Select nom_client, tel_client
from client
where ville = ‘Fès’
Clause where avec les opérateurs AND et OR
Pour pouvoir combiner plusieurs critères, on peut utiliser les opérateurs AND et OR :
Pour afficher tous les clients dont la ville est Fès et dont le id_client >1004 on exécute
Select * from client
where ville = ‘Fès’ AND id_client > 1004
Pour afficher tous les clients dont la ville est Fès ou Casa on exécute :
where ville = ‘Fès’ OR ville = ‘Casa’
Clause where avec l’opérateur NOT
Pour afficher tous les clients dont la ville n’est pas Fès on exécute
where ville <> ‘Fès’
« <> » signifie « non égal ».
Clause where avec l’opérateur BETWEEN
Pour sélectionner en fonction d’une plage de valeurs, on utilise l’opérateur BETWEEN. Par
exemple l’instruction suivante sélectionne tous les clients dont le id_client est entre 1002 et
1005 :
47

where id_client between 1002 and 2005.
Clause where avec l’opérateur IN
Par exemple, pour rechercher les clients dont la ville est Rabat ou Fès on peut exécuter
l’instruction :
Select * from client where Ville IN (‘Rabat’,’Fès’);
Clause where avec l’opérateur LIKE
On peut faire la recherche de certains enregistrements en utilisant un critère générique avec
l’opérateur LIKE. Par exemple, pour afficher tous les clients dont le nom commence par B, on
peut exécuter la commande suivante :
where nom_client LIKE ‘B%’
Clause ORDER BY
La clause ORDER BY permet de trier les résultats obtenus. L’instruction suivante trie les
résultats par nom en ordre alphabétique décroissant :
ORDER BY nom_client desc.
Et l’instruction suivante classe les résultats par nom en ordre alphabétique décroissant et par
id_client croissant :
order by nom_client desc, id_client asc
Le mot clé desc signifie « descendant » et le mot clé asc signifie « ascendant ».
Fonctions d’agrégation
SQL permet d’utiliser des fonctions spéciales appelées fonctions d’agrégation. Elles opèrent
sur une colonne et permettent de grouper les données dans le but d’obtenir des informations
de synthèse. Le tableau suivant donne les fonctions d’agrégation courantes avec des exemples
d’utilisation :
Fonction Valeur renvoyée Exemple
Avg (colonne) La moyenne de toutes les Select avg(Age) from

valeurs d’une colonne Etudiant
Sum (colonne) La somme de toutes les Select sum(VolumeHoraire)

valeurs d’une colonne from Module
Count (*) Le nombre de lignes d’une Select count (*) from Etudiant
table.
Max (colonne) La valeur maximale de la Select Max(Age) from

colonne citée Etudiant
Min (colonne) La valeur minimale de la Select min (Age) from

colonne citée Etudiant
48
Nous allons voir comment ces fonctions d’agrégation peuvent être appliquées. La maîtrise de
ces fonctions est fondamentale pour bien apprécier toute la puissance de SQL.
La clause GROUP BY – HAVING:
Le plus souvent, les utilisateurs souhaitent grouper les enregistrements du résultat d’une
requête par catégorie pour faire des traitements sur ces catégories. Supposons par exemple
que l’utilisateur exécute la requête suivante :
Select count(*) from Client
Cette requête renvoie le nombre des clients enregistrés dans la table client. Supposons
maintenant que nous voulons grouper ces clients par ville et obtenir, pour chaque ville, le
nombre de clients. La requête est alors :
Select ville, count (*)
from Client
Group by ville
Attention : Veillez à spécifier correctement les colonnes de la liste de sélection. Les colonnes
qui ne sont pas spécifiées dans la clause group by d’une requête doivent faire l’objet d’un
traitement via une fonction d’agrégation.
Par exemple, la requête suivante va causer une erreur :
Select nom_client, ville, max(date_naissance)
from Client
Group by ville
La cause de l’erreur est que, la colonne nom_client qui est incluse dans la liste de sélection,
n’est pas spécifiée par la clause groupe by et elle ne fait pas l’objet d’un traitement
d’agrégation. Par contre, les champs ville et date_naissance ne posent aucun problème, car le
premier est spécifié dans la clause group by, le deuxième est traité par la fonction
d’agrégation Max ().
3. SQL et opérations relationnelles
Pour interroger la base de données, l’utilisateur formule sa requête en SQL. Quand le SGBD
reçoit cette requête, il la traduit en langage relationnel pour pouvoir fournir le résultat à
l’utilisateur. Voyons quelques exemples :
a) Projection
Supposons que l’utilisateur veut afficher les champs NumEtudiant, Nom et Prénom de la table
Etudiant alors il peut exécuter la requête :
Select NumEtudiant, Nom et Prénom
from Etudiant
Le SGBD fait alors la projection donnée à la page 26 et affiche le contenu de la table
Etudiant_2.
b) Sélection
Supposons que Le SGBD veut répondre à la requête donnée à la page 27 « donner les noms
des étudiants qui sont âgés de 21 ans ».
La requête est la suivante :
49
Select nom
from Etudiant
where Age = 21
Le SGBD fait une projection sur le champ nom de la table Etudiant (car seulement le nom est
demandé), puis il sélectionne les étudiants qui ont 21 ans. Il affiche donc le contenu de la
table Etudiant_4 de la page 27.
c) Union
Pour obtenir le résultat de l’union des deux relations Footballeur et Athlète (voir figure 2.8)
l’utilisateur peut exécuter la requête :
Select * from Footballeur
UNION
select * from Athlète
Le SGBD fournit alors en résultat le contenu de la relation Sportif.
d) Intersection
Pour obtenir le résultat de l’intersection des deux relations Footballeur et Athlète (voir figure
2.9) l’utilisateur peut exécuter la requête :
Select * from Footballeur
ITERSECT
Le SGBD fournit alors en résultat le contenu de la relation Sportif_plus.
e) Différence
Pour obtenir le résultat de la différence entre les deux relations Sportif et Athlète (voir figure
2.10) l’utilisateur peut exécuter la requête :
Select * from Sportif
MINUS
Le SGBD fournit alors en résultat le contenu de la relation Footballeur_seulement.
f) θ-Jointure
Pour traiter des données qui appartiennent à plusieurs tables, on utilise la jointure. Supposons
par exemple que nous voulons répondre à la requête « trouver les employés qui gagnent
plus qu’un chef de service » (voir la page 30). La requête à exécuter est alors :
Select Employé.Nom, Employé.Salaire, Chef.Nom, Chef.Salaire
from Employé, Chef
where Employé.Salaire > Chef.Salaire
Le SGBD fait alors la jointure donnée à la page 30 pour fournir le résultat.
Remarque
Remarquez qu’on réfère à un champ d’une table en utilisant la forme table.champ. Dans le
cas où il n’y a pas risque de confusion, on peut se contenter de donner le nom du champ
seulement.
50
Résumé
Le langage SQL (Structured Query langage) est un langage assertionnel de 4ème génération utilisé actuellement
par la plupart des SGBD relationnels pour toutes les interactions avec la base de données. Il permet la
description, l’interrogation et la manipulation des données.
Parmi les commandes de SQL, on peut distinguer :
 Les commandes de définition des données : qui permettent de définir le schéma de la base de données.
Il permet, entre autres de créer, modifier et supprimer des tables et définir des contraintes d’intégrité.
Les principales commandes de cette catégorie sont create, alter et drop.
 Les commandes de manipulation des données : qui permettent d’insérer, consulter, mettre à jour et
supprimer des données de la base de données. Les principales commandes de cette catégorie sont
insert, select, update et delete.
1. Langage de définition de données (LDD)
Pour créer une table : create table ma_table (colonne1 type1 [NOT NULL], colonne2 type2 [NOT NULL],...) ;
Les types les plus souvent utilisés sont Char (n) (pour les chaînes de caractères de longueur fixe), Varchar (n)
(pour les chaînes de caractères de longueur variable), Number (n, m) (pour les valeurs numériques) et Date (pour
stocker les dates).
La clause optionnelle NOT NULL est pour interdire la valeur NULL dans une colonne.
Pour modifier une table la commande alter table. Par exemple :
alter table ma_table ADD colonne3 type3 ; (cette commande ajoute une colonne).
alter table ma_table Modify colonne2 type4 ; (cette commande modifie le type d’une colonne).
Pour supprimer une table la commande Drop table. Exemple : drop table ma_table.
2. Langage de manipulation de données
Pour insérer des données : insert into table ma_table values (valeur1, valeur2,...)
Ou insert into table ma_table (colonne1, colonne2,...) values (valeur1, valeur2,...)
Pour mettre à jour des enregistrements la commande update : update ma_table set colonne1 = valeur4 [where
condition] ; cette instruction met la valeur valeur4 dans le champ colonne1 pour tous les enregistrements qui
vérifient la condition.
Pour supprimer des enregistrements la commande delete : delete from ma_table [where condition] ; cette
instruction supprime de la table ma_table tous les enregistrements qui vérifient la condition.
Pour interroger la base : l’instruction select : la syntaxe générale est :
Select colonne1, colonne2,..
From table1, table2,..
Where condition1[AND/OU condition2...]
Group by colonne1, colonne2...
Having condition3,...
Order by colonne1 [Asc, desc], colonne2 [Asc, desc],...
La clause select est suivie des colonnes à afficher, la clause from détermine les tables concernées. La clause
where (optionnelle) sélectionne les enregistrements à afficher selon une condition. La clause groupe by
regroupe les enregistrements dans des catégories (en se basant sur les valeurs de certaines colonnes). La clause
having exclue des catégories qui ne répondent pas à une certaine condition.
Des fonctions d’agrégation sont disponibles avec SQL telles que count (*), sum (colonne), max (colonne),
min (colonne), avg (colonne).
Un SGBD relationnel traduit la requête SQL de l’utilisateur en une requête exprimée en langage relationnel puis
il l’exécute.
Par exemple : select colonne1, colonne2 from ma_table ; correspond à une projection de la relation ma_table sur
les attributs colonne1 et colonne2.
Select * from ma_table where condition ; correspond à une opération de sélection sur la relation ma_table en
utilisant la condition spécifiée.
Remarque : select * signifie toutes les colonnes de la table.
51
Exercices
Considérons la base de données d’une compagnie aérienne qui contient entre autres les
tables suivantes :
La table Avion caractérisée par les champs suivants :

NA : numéroAvion de type smallint (clé primaire)
NOM : Nom Avion de type char (12).
Capacité : capacité avion, de type smallint,
Localité : Ville de localité de l’avion de type char (10).
La table Pilote avec les champs :

NP : Numéro Pilote, smallint,
Nompilote : Nom du pilote de type char (25),
Adresse : adresse du pilote de type char (40).
La table Vol contient les champs :

NV : Numéro de vol, char (6),
NA : Numéro d’avion de type smallint,
NP : Numéro de pilote de type smallint,
VD : ville de départ de type char (10),
VA : ville de d’arrivée de type char (10),
HD : heure de départ de type smallint,
HA : heure d’arrivée de type smallint.
Exercice1
1) Créer cette base de données.

2) Créer les tables Pilote, Avion et Vol.
3) Créer un index unique sur le champ NP de la table Pilote.
4) Créer un index sur le champ Nom de la table Pilote.
5) Créer un index unique sur le champ NA de la table Avion.
6) Créer un index sur le champ Nom de la table Avion.
7) Créer un index unique sur le champ NV de la table Vol
8) Créer un index sur le champ NP et NA de la table Vol.
Exercice2
1) Insérer les pilotes suivants (1,’Ahmed’,’Fès’) ; (2, ‘Jamal’, ‘Rabat’) ; (3,’Kamal’,

‘Meknes’).
2) Insérer les vols suivants (IT100, 1, 100,’Fès’,’Rabat’, 7,8) ;(IT101, 2,
100,’Rabat’,’Casa’, 11,12)
3) Insérer les avions suivants (100,’AIRBUS’, 300,’Rabat’) ; (101,’B737’, 250,’Casa’) ;
(102,’B737’, 220,’Rabat’).
4) Insérer d’autres pilotes, avions, et vols.
52
Select
5) Afficher tous les avions.
6) Afficher tous les avions par ordre croissant sur les noms.
7) Afficher tous les avion par ordre croissant sur les noms et décroissant sur la capacité.
8) Afficher les noms et les capacités des avions.
9) Afficher les localités des avions sans redondance.
10) Afficher les avions dans la localité est Rabat ou Casa.
11) Afficher les avions AIRBUS dans la localité et Rabat.
12) Afficher les avions dont le nom commence par B7.
13) Afficher les noms des avions dont la capacité est supérieure à 200 sans redondance.
14) Afficher les noms des avions dont la capacité est entre 200 et 250 sans redondance.
15) Afficher les avions dont le numéro est 100, 102 ou 104 ordonné par numéro croissant.
16) Afficher la capacité maximale, la capacité minimale et la capacité moyenne des
avions.
17) Afficher par avion le nombre d’avions, la capacité maximale, la capacité minimale et
la capacité moyenne.
18) Même question que 17) mais uniquement pour les avions B737 et B747.
19) Même question que 17) mais uniquement pour les avions ayant une capacité moyenne
supérieure à 250.
20) Même question que 17) mais uniquement pour les avions dont le nombre d’avions et
>2.
21) Afficher les données sur les avions dont la capacité est supérieure à la capacité
moyenne.
Jointure
22) Afficher les noms et les adresses des pilotes assurant les vols IT100 et IT104.
23) Afficher les noms et les adresses des pilotes assurant les vols IT100 et IT104 ordonnés
par nom.
24) Afficher les noms et les numéros des pilotes assurant les vols IT100 et IT104 dont
l’heure de départ est entre 9h et 15h, ordonnés par nom descendant.
25) Afficher la moyenne des capacités des avions pilotés par le pilote numéro 100.
26) Afficher les numéros de pilotes qui conduisent un ‘AIRBUS’.
27) Afficher les numéros de pilotes qui conduisent tous les avions de la compagnie.
28) Afficher les numéros de pilotes qui conduisent au moins tous les AIRBUS de la
compagnie.
29) Afficher les noms de pilotes qui n’effectuent pas de vol au départ de Rabat.
30) afficher les numéros de pilotes qui conduisent un avion conduit aussi par le pilote
numéro 10.
Update
31) Modifier la capacité de l’avion numéro 101, la nouvelle capacité est 220.
32) Modifier la capacité et la localité des avions B737, les nouvelles valeurs sont 280 et
Casa.
Delete
33) Supprimer les avions dont la capacité est inférieure à 200.
53
Exercice3
1) Ajouter à la table pilote un champ TEL de type char (9), un champ SALAIRE de type
NUMBER (8,2) et un champ Age de type NUMBER (2).
2) Ajouter à la table Avion un champ REMARQUE de type char (30).
3) Modifier les types des champs VD et VA de la table Vol ; le nouveau type est char
(15).
4) Supprimer le champ adresse de la table Pilote.
5) Donner de nouveaux noms aux trois tables.
6) Supprimer l’index non unique que vous avez créé sur la table avion.
7) Créer une vue V1 sur les avions AIRBUS.
8) Insérer à travers cette vue l’avion (111, 'AIRBUS', 250, 'Marrakech')
9) Afficher à travers cette vue tous les avions.
10) Afficher à travers cette vue les avions localisés à Rabat.
11) Modifier à travers cette vue la capacité des avions localisés à Casa.
12) Créer une vue V2 sur les vols dont la ville de départ ou d’arrivée est Casa ou Rabat.
13) Tenter l’insertion d’un vol ne respectant pas cette condition.
14) Afficher pour chaque pilote et en utilisant la vue V2 le nombre de vols assurés ayant
pour ville de départ ou d’arrivée Rabat ou Casa.
54
Complément : Objets de bases de données
Ce chapitre complémentaire présente les objets de base de données utilisés par la plupart des SGBDR. Ça
concerne :
 Les tables ;
 Les vues ;
 Les index ;
 Les procédures et fonctions stockées ;
 Les déclencheurs ;
 Les privilèges ;
 Les rôles.
Toute information sur ces objets (et plus généralement sur la structure du schéma relationnel) est maintenue par
le SGBD dans le dictionnaire de données.
La plupart des SGBD traitent un certain nombre d’objets stockés dans la base de données.
Toutes les informations sur ces objets sont stockées dans des tables systèmes qui forment ce
qu’on appelle dictionnaire de données. Nous donnons ici un survol des principaux objets
que vous pouvez rencontrer :
1. Tables
Une table est un objet de base de données qui contient des données. Chaque colonne d’une
table est définie avec un type de données spécifique et n’accepte que des données
correspondant à ce type. Par exemple si vous tentez de placer des données de type texte dans
une colonne définie avec un type numérique, le SGBD ne le permettra pas.
Le code suivant a pour effet de créer une table nommée Client :
Create table client
(id_client number(10) primary key,
nom varchar(30) not null,
prénom varchar(20),
région_ventes char(2),
total_ventes number(14,2) ) ;
2. Vues
Une vue est un objet de base de données qui permet de créer une représentation personnalisée
des données d’une ou de plusieurs tables. A l’instar d’une table, une vue supporte les
opération insert, update, delete et select, mais elle ne contient aucune donnée, juste une
requête SQL. Les données extraites au moyen de cette requête sont présentées sous forme de
table.
Les vues ont les avantages suivants :
 Elles permettent d’implémenter un niveau de sécurité supplémentaire.
 Elles cachent la complexité des données
 Elles permettent de présenter les données différemment de celle des tables sous-
jacentes.
55
 Elles isolent le code des applications des changements pouvant survenir dans la
définition des tables de base.
Le code suivant permet de créer une vue nommée région_client ;
create view région_client
as
Select nom, région_ventes
from client
Maintenant, les utilisateurs peuvent, par exemple, utiliser la commande
Select * from région_client
Au lieu de la commande
Select nom, région_ventes from client
3. Index
De la même manière que l’index d’un livre vous aide à retrouver à telle ou telle page les
informations que vous recherchez, un index de base de données placé sur une table vous
permet d’accélérer l’extraction de données. Dans le cas d’une application s’exécutant
lentement, un index bien placé peut améliorer son fonctionnement.
La commande SQL suivante permet de créer un index nommé idx_client sur la colonne
id_client de la table client :
create index idx_client1 on client (id_client)
Il y a des index uniques et des index non uniques. Par exemple, l’instruction suivante crée un
index unique sur la colonne nom_client de la table client.
create unique index idx_client2
on client (nom_client).
Cet index empêche la saisie des noms en doublon dans la colonne nom_client.
On peut définir des index sur plusieurs colonnes
create index idx_client3
on client (id_client, nom_client)
4. Procédures et fonctions stockées
Ce sont des programmes qui font des traitements spéciaux et dont le code est stocké dans la
base de données. A tout moment l’utilisateur peut les réutiliser en les appelant.
5. Déclencheurs
Un déclencheur de base de données est un programme associé à une table. Il s’agit en fait
d’une procédure stockée qu’est lancée suite à une action spécifique sur la table à laquelle elle
est associée. Les déclencheurs sont utilisés principalement pour valider des données avant
qu’elles soient enregistrées dans la base. Ils servent aussi à générer des enregistrements dans
d’autres tables à partir des données qui viennent d’être insérées, et à implémenter les règles de
gestion.
6. Privilèges
Un privilège est le droit d’exécuter un type d’instructions SQL spécifique. Voilà quelques
exemples de privilèges :
 Le droit de se connecter à une base de données (créer une session).
56
 Le droit de créer une table.

 Le droit de sélectionner des lignes dans une table.
 Le droit d’exécuter une procédure appartenant à un autre utilisateur.
Attribution de privilèges aux utilisateurs
Quel que soit le privilège attribué, une instruction grant est toujours utilisée. Elle est
composée de trois parties :
 La portion indiquant le type de privilège. Le mot grant est suivi d’un ou plusieurs
privilèges comme insert, select, update et delete. Lorsque il y’en a plusieurs, ils sont
séparés par des virgules.
 La portion désignant la table. Le mot clé on suivi du nom de la table sur laquelle porte
les privilèges attribués.
 La portion identifiant le bénéficiaire. Le mot clé to suivi par un ou plusieurs
utilisateurs (séparés par des virgules).
Le privilège insert par exemple permet à un utilisateur d’insérer des lignes dans une table
dont il n’est pas propriétaire.
l’instruction:
grant insert, select on table client to public
permet à tous les utilisateurs de la base de consulter et insérer des lignes dans la table Client.
Tandis que l’instruction :
grant update, delete on table client to Ali
autorise Ali de modifier et supprimer des lignes de la table Client.
7. Rôles
Un rôle est un objet de base de données. Pour accorder des privilèges à un groupe
d’utilisateurs, on crée alors un rôle et on lui attribue ces privilèges et enfin on assigne ce rôle
aux utilisateurs concernés. Cette méthode simplifie la tâche de l’administrateur de la base : au
lieu d’avoir à attribuer les privilèges au utilisateurs un par un, il peut le faire en un seul coup
en utilisant les rôles.
Supposons par exemple que Ali, Omar, et Fatima sont des membres du service de finance
d’une entreprise qui utilisent les tables tableA et tableB. Au lieu de donner des privilèges sur
ces tables à chaque utilisateur individuellement, le DBA (l’administrateur de la base de
données) peut procéder comme suit :
1) Créer un rôle nommé par exemple finance en exécutant l’instruction :
create role finance
2) Donner les privilèges nécessaires à ce rôle :
grant insert, update on tableA to finance
grant select on tableB to finance
3) Assigner le rôle finance aux trois utilisateurs:
grant finance to Ali,Omar,Fatima
57
Résumé
La plupart des SGBD traitent un certain nombre d’objets stockés dans la base de données. Toutes les
informations sur ces objets sont stockées dans des tables systèmes qui forment ce qu’on appelle dictionnaire de
données :
Les tables : Une table est un objet de base de données qui contient des données. Chaque colonne d’une table est
définie avec un type de données spécifique et n’accepte que des données correspondant à ce type. Les lignes de
la table sont les enregistrements proprement dits.
Les vues : Une vue est un objet de base de données qui permet de créer une représentation personnalisée des
données d’une ou de plusieurs tables. Seule la définition d’une vue est réellement stockée dans la base. Parmi les
avantages des vues :
 Plus de sécurité ;
 Cacher la complexité des données ;
 Présenter les données différemment aux tables sous-jacentes ;
 Plus d’indépendance données/programmes.
Les index : Par analogie avec un index d’un livre, un index (défini sur une table) est un objet de base de données
qui accélère l’accès aux données de cette table.
Les procédures et fonctions stockées : sont des programmes qui font des traitements spéciaux et dont le code
est stocké dans la base de données. A tout moment l’utilisateur peut les réutiliser en les appelant.
Les déclencheurs : sont des procédures stockées spéciales qui s’exécutent suite à une action donnée (par
exemple, insertion, suppression ou mise à jour). Ils servent essentiellement à implémenter les contraintes
d’intégrité.
Les privilèges : Un privilège est le droit accordé à un utilisateur particulier pour exécuter un type spécifique
d’instructions SQL.
Les rôles : Un rôle est un objet de base de données. Pour accorder des privilèges à un groupe d’utilisateurs, on
crée alors un rôle et on lui attribue ces privilèges et enfin on assigne ce rôle aux utilisateurs concernés. Cette
méthode simplifie la tâche de l’administrateur de la base : au lieu d’avoir à attribuer les privilèges au utilisateurs
un par un, il peut le faire en un seul coup en utilisant les rôles.
58

Poly BD Partial 2019

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Poly BD Partial 2019

Transféré par

Droits d'auteur :

Formats disponibles

Introduction aux bases de

Pour les étudiants des licences en informatique

Pour les étudiants des licences en informatique

La deuxième partie contient trois chapitres consacrés au modèle relationnel.

Un chapitre complémentaire présente certains objets de base de données que

Table des Matières

Partie 2 : Le modèle relationnel.......................................................................... 17

b) Deuxième Forme Normale (2FN)......................................................................... 37

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

Dans ce chapitre, nous allons étudier les concepts suivants :

 L’évolution des entreprises (volumes importants de données, centralisées ou réparties,

2. Fonctions d’un SGBD

1) Description des données : Le SGBD doit mettre à la disposition de l’utilisateur un

• Les notes doivent être comprises entre 0 et 20.

5) Sécurité : En cas de panne matérielle ou logicielle telle que panne de l’ordinateur,

Niveau externe Niveau conceptuel Niveau Interne

Figure 1.1 : les différents niveaux d’une base de données

--- une représentation simple de données (sous forme de tables)

5. Le concept d’indépendance données/programmes

a) L’indépendance physique On entend par ceci que l’administrateur de la base de données

b) L’indépendance logique : elle a pour but de permettre la modification du schéma

6. Mise en œuvre d’une base de données

a) L’administrateur de la base de données : c’est la personne responsable de bon

Chapitre 2 : Concepts de base du modèle

1. Relation, domaine, attribut, tuple

Etudiant (NumEtudiant, Nom, Prénom, Age, Tél)

Nom de la relation Noms des attributs

On peut la voir à un instant donné sous la forme suivante :

113 Slaoui Salwa 21 060000001

580 Moussi Moussa 22 NULL

309 Karimi Karim 20 066600005

310 Karimi Karima 20 NULL

Figure 2.3 : Une extension de la relation Etudiant.

2. Identifiants : Clé candidate, clé primaire, clé étrangère

113 Slaoui Salwa 21 060000001

Clé primaire 202 Khaldouni Khalid 22 060000002

567 Moussaoui Moussa 21 060070070

580 Moussi Moussa 22 NULL

309 Karimi Karim 20 066600005

310 Karimi Karima 20 NULL

113 BD Clé primaire

ARCH Architecture des ordinateurs 45

3. Intégrité d’entité, intégrité référentielle

Chapitre 3 : L’algèbre relationnelle

113 Slaoui Salwa

202 Khaldouni Khalid

567 Moussaoui Moussa

580 Moussi Moussa

309 Karimi Karim

310 Karimi Karima

Figure 2.5 : Etudiant_2 = π NumEtudiant, Nom, Prénom (Etudiant)

Figure 2.6 : Etudiant_3 = π Nom, Age (Etudiant_2)

Figure 2.7 : Etudiant_4 = σ Age = 21 (Etudiant_3)

Figure 2.8 : Sportif = Footballeur U Athlète

Figure 2.9 : Sportif_plus = Footballeur ∩ Athlète

Figure 2.10 : Footballeur_seulement = Sportif – Athlète

Ali ARCH ARCH

Le résultat de la division de R1 par R2 est la relation R3 suivante :

Emp1 6000 Ch1 7000

Emp2 3000 Ch2 5000

Emp1 6000 Ch1 7000

Emp1 6000 Ch2 5000

Emp2 3000 Ch1 7000