Institut Universitaire et Stratégique de

l’Estuaire
Estuary Academic and Strategic Institute(IUEs/Insam)
Sous la tutelle académique des Universités de Dschang et de Buéa

SUPPORT DE COURS BASES DE

DONNEES
Objectifs :
 Création, gestion et optimisation d'une base de donnée relationnelle avec le langage
SQL et le Système de Gestion de Bases de Données,
 Utilisation optimale d’un SGBD.
 Déployer une base de données et mettre en place l’interface d’accès à base

Contenu :

Chapitre 1: Concepts fondamentaux

Chapitre 2 : Le Modèle relationnel
Chapitre 3 : Langage de Requêtes Structuré (SQL)
Chapitre 5 : Introduction aux Bases de Données Objets
Chapitre 6 : Aspects systèmes
Chapitre 7 : Introduction à la réalisation d’applications
Chapitre 8 : Introduction aux Entrepôts de données et à la concurrence d’accès
Mots clés:
BD, Modèle Relationnel, Formes normales, Relation, Table, SQL, SGBD,
Formulaire, Requêtes, Etat, Application, Interface, BD Objet, WQL, Transactions,
Concurrence.

Enseignant : FOTSO CHATUE HERMANN

Support de cours bases de données Page 1

Support de cours Bases de données

C H A P I T R E 1:
CONCEPTS FONDAMENTAUX

1. Bases de données, banques de données et fichiers

Base de données (BD)

Système de gestion de bases de données (SGBD)

Une base de données (BD) représente l'ensemble (cohérent, intégré, partagé) des informations nécessaires
au fonctionnement d'une entreprise, ensemble dont la gestion est assurée par un logiciel appelé système de
gestion de bases de données (SGBD).
On entend ici par entreprise toute collectivité d'individus travaillant en coordination à la réalisation d'un
objectif commun.
Exemples de base de données: celle qui permet la gestion des personnels, étudiants, cours, inscriptions, ...
d'une université ou école, celle du système de réservation de places d'avion des compagnies d'aviation, celles
qui permettent la gestion des comptes des clients des sociétés bancaires, ...

Banque de données
Une base de données est développée au sein d'une entreprise, pour son propre fonctionnement. Inversement,
une banque de données est un ensemble de données, propres à un domaine d'application, que des
"producteurs" réunissent pour ensuite en commercialiser l'usage vers le public extérieur. Exemple: les
banques de données juridiques, économiques, médicales, des brevets, des propriétés des matériaux, ... . La
constitution et l'exploitation des banques de données font appel à des techniques spécifiques (télématique,
par exemple), différentes des techniques bases de données, seules étudiées dans ce cours.

Fichier
Dans une entreprise, il convient de faire appel à l'approche base de données lorsque les données à gérer sont
de natures diverses (exemple : étudiants, cours, enseignants, salles, ...) et possèdent de nombreux liens entre
elles (exemple : un étudiant suit un cours, un cours est assuré par un enseignant, ...). A contrario, il existe des
cas où les données à gérer, bien que importantes en volume, sont homogènes : les abonnés d'une revue, le
personnel d'une entreprise, les produits vendus par un magasin ... . Dans ces cas, on parlera de fichier (le
fichier des abonnés, ...) et l'on utilisera un système de gestion de fichiers (SGF), moins complexe qu'un
SGBD.

Support de cours bases de données Page 2

Support de cours Bases de données

Tout système d'exploitation d'un ordinateur contient un SGF spécifique. Toutefois, pour les applications, on
fait plutôt appel à des progiciels du commerce (exemple: dBase, Filemaker, ...), d'un usage plus simple et
offrant des fonctionnalité plus élaborées.

Il est à noter que l'implantation physique d'une base de données sur les mémoires secondaires se fait via la
notion de fichier. Le choix de ceux-ci, toutefois, reste de la compétence du SGBD et est invisible à
l'utilisateur. Le cours abordera les techniques de gestion de fichiers lorsque nous traiterons des aspects
internes de réalisation d'un SGBD.

2. Cycle de vie d'une base de données

On appelle conception d'une base de données la phase d'analyse qui aboutit à déterminer le futur contenu
de la base.
Lorsqu'une entreprise décide, pour son informatisation, d'adopter une approche base de données, le premier
problème à résoudre, peut-être le plus difficile, est de déterminer les informations qu'il conviendra de mettre
dans la base de données. Il faut ainsi que l'ensemble des utilisateurs actuels et futurs de cette base de données
se mettent d'accord sur la nature et les caractéristiques des informations qu'il faut garder pour assurer la
gestion de l'entreprise.

Une fois que cet accord aura été établi, il faudra pouvoir transmettre son contenu au logiciel SGBD choisi
par l'entreprise. Ceci sera fait au moyen d'un langage symbolique, spécifique du logiciel choisi, que l'on
appelle langage de description de données (LDD). Une fois que le SGBD aura pris connaissance de cette
description, il sera possible aux utilisateurs d'entrer les données, c'est-à-dire de constituer la première
version, initiale, de la base de données. On appelle implantation de la base de données cette phase qui
consiste à décrire la base de données dans le langage du SGBD et construire cette première version.

Une fois l'implantation terminée, peut commencer l'utilisation de la base de données. Celle-ci se fait au
moyen d'un langage, dit langage de manipulation de données (LMD), qui permet d'exprimer aussi bien les
requêtes d'interrogation (pour obtenir des informations contenues dans la base) que des requêtes de mise à
jour (pour ajouter de nouvelles informations, supprimer des informations périmées, modifier le contenu des
informations).
On appelle cycle de vie d'une base de données la suite des phases conception, implantation, utilisation.

3. Modèles de données et schémas

Au cours des différentes phases de la vie d'une base de données, plusieurs descriptions sont successivement
élaborées, chacune répondant à un objectif déterminé et complémentaire. Dans l'état actuel de l'art, ces
descriptions ne peuvent être faites avec le langage naturel (en français, par exemple): celui-ci est trop ambigu

Support de cours bases de données Page 3

Support de cours Bases de données

et encore trop difficile à comprendre par un ordinateur. On fait donc appel à un langage formel, basée sur un
certain nombre de concepts bien établis. Par exemple, les concepts d'objet, de lien, de propriété.
On appelle modèle de données l'ensemble des concepts qui permettent la description de données d'une base
et les règles d'utilisation de ces concepts. On appelle schéma d'une base de données l'expression de la
description de la base de données d'une entreprise obtenue en employant un modèle de données.

Les différents schémas établis pour décrire les divers aspects d'une base de données sont les suivants:

1/ Lors de la phase de conception, il est nécessaire que les utilisateurs puissent discuter de leurs besoins: il
faudra donc qu'ils puissent exprimer leur vision sous forme d'une description, éventuellement partielle, de la
future base de données. Dans cette description, il n'est guère besoin de faire appel à des concepts de
l'informatique, dans la mesure où le problème à traiter est de déterminer quelles sont les informations
nécessaires à la vie de l'entreprise, et ce indépendamment de la solution informatique retenue. Cette
description s'appuiera donc sur un ensemble de concepts qui ne font aucune référence à l'informatique : le
modèle utilisé est dit "conceptuel".
La description ainsi obtenue s'appelle schéma conceptuel des besoins. Un modèle conceptuel comporte
généralement deux parties: le modèle statique, concepts permettant de décrire la structure de données, et le
modèle dynamique, concepts permettant de décrire les opérations sur les données.
Quelque soit le modèle conceptuel choisi (il en existe plusieurs), il n'est pas possible de décrire avec celui-ci
toute la connaissance que l'on possède sur les données à décrire: notamment, les règles de gestion de ces
données. Par exemple, l'expression de la règle "il ne doit pas y avoir plus de 20 % d'écart entre les salaires
des employés d'un même service et d'une même catégorie" n'est pas possible avec les seuls concepts
descriptifs d'un modèle. On introduira donc, en supplément à la description établie, la description explicite
des contraintes supplémentaires, dites contraintes d'intégrité. On utilise pour cela un langage d'expression
de règles, compatible avec le modèle conceptuel utilisé.

2/ Le schéma conceptuel des besoins décrit la future base, indépendamment des choix techniques
d'implantation. La phase suivante, celle d'implantation, demande que la partie décrivant les données de ce
schéma soit traduite dans les concepts du modèle utilisé par le SGBD choisi. On appelle modèle logique (ou
modèle machinable), le modèle sur lequel est construit un SGBD actuel. Il existe aujourd'hui plusieurs
modèles logiques (relationnel, CODASYL, hiérarchique, ...). Le schéma obtenu en traduisant dans un
modèle logique le schéma conceptuel des besoins sera appelé ici le schéma logique de la base de données. A
noter cependant que, dans la terminologie courante, ce schéma est souvent appelé le schéma conceptuel de la
base de données, ce qui ne va pas sans ambiguïté avec le schéma conceptuel résultant de la phase de
conception (point 1 ci-dessus).

Support de cours bases de données Page 4

Support de cours Bases de données

3/ L'implantation des données elles-mêmes, c'est-à-dire le chargement de la base de données avec la version
initiale, nécessite que soient fixés les choix en matière de structuration de données sur la mémoire secondaire
(quels types de fichiers? quels index? ...). Ces choix, ainsi que nous l'avons dit plus haut, ne sont pas faits par
les utilisateurs, mais par les administrateurs système qui, en fonction de leur analyse des traitements qui vont
être effectués sur la future base de données, détermineront les paramètres effectifs pour l'implantation de la
base sous forme d'un ensemble de fichiers. L'ensemble de ces choix sera consigné dans ce que l'on appelle le
schéma interne de la base de données: description de comment les données de la base sont enregistrés dans
les fichiers. Cette description fait donc appel à un nouveau modèle, appelé modèle interne, où les concepts
seront ceux de fichier, organisation, index, chemin d'accès, clé, ...

4/ Enfin, au cours de la phase d'utilisation de la base de données, d'autres schémas sont élaborés pour
répondre aux besoins spécifiques des différents groupes d'utilisateurs. Ceux-ci n'ont pas besoin de connaître
l'ensemble du contenu de la base, à savoir, toutes les informations sur chaque type d'objet. Chaque utilisateur
a des exigences limitées (il n'est intéressé que par certaines informations) et particulières (il peut souhaiter
une représentation des informations différente de celle décrite dans le schéma conceptuel).
A chaque utilisateur (ou groupe d'utilisateurs) est donc associé un schéma, dit son schéma externe, qui
définit le sous-ensemble de la base de données auquel il a accès, structuré de façon à répondre à ses besoins
spécifiques.
Avantages de cette approche :
. simplicité chaque utilisateur n'a dans son schéma externe que ce qui l'intéresse
. protection il n'est pas possible que, par erreur ou par malveillance, un utilisateur accède aux
données d'autres utilisateurs non décrites dans son schéma externe.

Dans les SGBD actuels, le modèle de données employé pour décrire les schémas externes est le même que
celui du schéma logique, mais on pourrait proposer des modèles externes plus adaptés aux besoins
spécifiques des utilisateurs.

Un SGBD gère donc trois types de schémas pour une base de données, qui sont organisés en cascade de la
façon suivante:

Support de cours bases de données Page 5

Support de cours Bases de données

Support de cours bases de données Page 6

Un exemple illustrant ces trois niveaux de schémas (pour un SGBD relationnel) est le suivant.
Entreprise: un institut de formation permanente.
Schéma logique (SL)

Etudiant : nom, prénom, date de naissance, n°étudiant

Enseignant : nom, prénom, statut, n°compte_bancaire
Cours : nomC, cycle, nom_enseignant
Inscription : n°étudiant, nom_cours, note1, note2

Schémas externes (SE)

• Schéma externe du professeur de base de données :

Etudiant _BD : nom, prénom, note1, note2, note_finale

tel que Etudiant _BD résulte de la combinaison de Etudiant et Inscription du SL,
tels qu'il existe une Inscription de cet étudiant pour le cours BD
(n°étudiant dans Etudiant = n°étudiant dans Inscription et nom_cours
dans Inscription = BD), et
tel que note_finale = (note1 + note2)/2

• Schéma externe du service de gestion du personnel enseignant :

Professeur : nom, prénom, n°compte_bancaire, nombre_de_cours, liste(nom_cours)

tel que Professeur résulte de la combinaison de Enseignant et Cours du SL, tels
que liste(nom_cours) est la liste de nomC qui se trouvent dans Cours tel
que nom_enseignant dans Cours = nom dans Enseignant, et
tel que nombre_de_cours = Cardinalité (liste(nom_cours))

Schéma interne (SI)

Etudiant : fichier FEtud,

contenu : nom, prénom, date de naissance, n°étudiant
indexé sur n°étudiant,
index secondaire sur nom+prénom

Enseignant
+ : fichier FEnsCours,

Support de cours bases de données Page 7

 Cours contenu : nom, prénom, statut, n°compte_bancaire, liste(nomC, cycle)
tel que nom_enseignant dans Cours = nom dans Enseignant
indexé sur nom,
deux index secondaires, l'un sur nomC, l'autre sur cycle

Inscription : fichier FInscrits,

contenu : n°étudiant, nom_cours, note1, note2
indexé sur n°étudiant,
index secondaire sur nom_cours

4. Architecture d'un SGBD

Au niveau d'abstraction le plus élevé, un SGBD peut être vu comme une boite noire, assurant la gestion de la
BD conformément aux requêtes de ses utilisateurs:

L'interface utilisateur permet aux utilisateurs d'exprimer des requêtes: soit pour définir le contenu de la BD
(avec le LDD), soit pour interroger la BD (en extraire des informations), soit enfin pour apporter des
modifications à ce qui a été enregistré.
L'interface d'accès physique permet au SGBD d'accéder aux données sur les supports (disques, ...).
Un SGBD gère des problèmes très différents, avec des objectifs particuliers:
- interface utilisateur: compréhension, analyse et vérification des requêtes; objectifs: convivialité de
l'interface, puissance des langages de description et de manipulation;
- interface d'accès physique: optimisation du stockage des données (en termes d'espace occupé sur les
supports) et de l'accès aux données (en temps); objectif: avoir les meilleures performances.

L'articulation entre ces deux interfaces doit répondre à un objectif fondamental: assurer l'indépendance
programme/données. A savoir, d'une part, la possibilité pour un utilisateur de modifier sa vue de la base et
ses traitements sans avoir à se soucier des choix qui ont été opérés au niveau interne en matière de fichiers;

Support de cours bases de données Page 8

 d'autre part, inversement, la possibilité pour un administrateur système de modifier ces choix, pour améliorer
les performances, sans que cela ait un impact sur les utilisateurs (leurs requêtes d'interrogation ou de mise à
jour, ou leurs programmes d'application qui utilisent la base de données).

Enfin, un SGBD étant utilisé simultanément par plusieurs utilisateurs, il a à résoudre plusieurs problèmes
internes de coordination de ses actions, de cohérence et de contrôle du bon déroulement de ses activités.

Il convient donc d'avoir une vision plus fine de l'architecture d'un SGBD. Celle-ci conduit à distinguer trois
couches :

. niveau externe prend en charge le problème du dialogue avec les utilisateurs, c'est-à-dire l'analyse
des demandes de l'utilisateur, le contrôle des droits d'accès de l'utilisateur, la
présentation des résultats

. niveau interne s'occupe du stockage des données dans les supports physiques et de la gestion des
structures de mémorisation (fichiers) et d'accès (gestion des index, des clés, ...)

. niveau intermédiaire: assure les fonctions de contrôle global:

- optimisation globale des requêtes
- gestion des conflits d'accès simultanés de la part de plusieurs utilisateurs
- contrôle général de la cohérence de l'ensemble
- coordination et suivi des processus en cours
- garantie du bon déroulement des actions entreprises même en cas de panne
- ...
La couche intermédiaire de contrôle est appelée niveau logique: on cherche à ne dépendre ni des exigences
des utilisateurs ni des structures physiques choisies.

Support de cours bases de données Page 9

 Avec cette approche, le principe du fonctionnement d'un SGBD est le suivant.

Une requête, exprimée par l'utilisateur dans un langage accepté par le système (LMD), est d'abord analysée
du point de vue syntaxique (conformité à la grammaire du langage); suit une analyse sémantique (les objets
cités doivent être connus dans le schéma externe de l'utilisateur).

Après cette validation, faite dans la couche externe, la requête est traduite, pour son passage à la couche
logique: les références aux objets du schéma externe sont remplacées par les références aux objets
correspondants dans le schéma logique. On utilise pour cela la description des règles de correspondance
entre schéma externe et schéma logique, établie, nécessairement, au moment de la définition du schéma
externe.
Au niveau logique, on fait les contrôles sur la confidentialité, la concurrence, etc. Si la requête est acceptée,
elle est optimisée et découpée en sous-requêtes plus élémentaires qui sont transférées au niveau interne;
sinon, elle peut être mise en attente ou refusée.

Au niveau interne, chaque sous-requête reçue est traduite en une ou plusieurs requêtes physiques
correspondantes (en fonction des informations contenues dans le schéma interne), puis le SGBD réalise
l'accès physique aux données (extraction ou modification). S'il s'agit d'une requête d'interrogation, les
données extraites sont passées à la couche logique, puis à la couche externe. Ici elles sont réorganisées, selon
le schéma externe de l'utilisateur, avant de les transmettre à l'utilisateur.

Support de cours bases de données Page 10

 Fiche TD1 CONCEPTS FONDAMENTAUX BD

Questions de cours:
1. Donner 2 avantages d'un SGBD par rapport à un système de gestion de fichiers
classique.
2. Qui intervient sur une base de données ?
3. Présenter le rôle de chaque intervenant sur une base de données.
4. Soit la figure suivante :

a. Donner un nom à cette figure.

b. Compléter la figure (renommer les différents niveaux).
c. Que signifie cette figure pour une base de données ?
5. Expliquer le Processus de conception d’une base de données en se basant sur une figure bien
détaillée.

Support de cours bases de données Page 11

C H A P I T R E 2:
CHAPITRE 2 : LE MODELE
RELATIONNEL

Le modèle relationnel a été inventé en 1960 et a fait l'objet de très nombreuses recherches qui ont débouché
sur la réalisation et commercialisation de SGBDs relationnels. C'est le modèle le plus utilisé par les SGBDs
actuellement disponibles sur le marché.

C'est un modèle de données plus simple que celui de l'entité association, ce qui explique son succès tant sur
le plan théorique (théorie de la normalisation, définition de langages de manipulation de données), que sur
celui des réalisations. Mais cette simplicité est aussi sa faiblesse principale: c'est un outil trop pauvre
sémantiquement pour pouvoir bien représenter la complexité du monde réel. Ce pourquoi d'autres modèles
de type entité association ou orientés objets ont été ensuite proposés.

I. Lesrelations
1. Définitions
Les objets et associations du monde réel sont représentés par un concept unique: la relation. Les relations
sont des tableaux à deux dimensions, souvent appelés tables.

Exemples

Etudiant N° Etud Nom Prénom Age

136 Rochat Jean 19
253 Aubry Annie 20
101 Duval André 20
147 Rochat Marc 21

Cet exemple représente une relation (ou table) décrivant les étudiants. Etudiant est le nom de la relation. Les
entêtes des colonnes, N° Etud, Nom, Prénom et Age, sont les attributs de la relation. Chaque ligne de la
table correspond à une occurrence. Par exemple:
<253, Aubry, Annie, 20>
constitue un n-uplet ou tuple, qui décrit une occurrence (l'étudiante Annie Aubry).
Il est usuel de souligner l'attribut, ou les attributs, qui constituent l'identifiant de la relation.

Support de cours bases de données Page 12

 Cours Nom C Horaire Prof
Algo Lundi 10-12 Duval
Système Mardi 16-17 Malin

Suit N° Etud NomC

253 Algo
136 Système
253 Système

On remarque que l'identifiant de la relation "Suit" (qui traduit un type d'association) est composé des
identifiants des deux relations précédentes. Cette relation Suit exprime le lien entre un étudiant, désigné par
son numéro, et un cours, désigné par son nom. Si on avait utilisé le modèle entité association, les relations
Etudiant et Cours auraient été modélisées par des types d'entité, Etudiant et Cours, alors que la relation Suit
aurait été modélisée par un type d'association reliant ces types d'entité.

Notion de domaine
Un domaine est un ensemble de valeurs que peut prendre un attribut; c'est le domaine définition d'un ou
plusieurs attributs.
Exemple de domaines:
Dnom : chaînes de caractères de longueur maximale 30
Dnum : entiers compris entre 0 et 99999
Dcouleur : {"bleu", "vert", "jaune"}
Dâge : entiers compris entre 16 et 65

Relations
Une relation est définie par :
 son nom
 liste de couples (nom d'attribut : domaine)
 son (ses) identifiant(s)
 sa définition (phrase en français)
Les trois premières informations: nom de la relation, liste des couples (attribut : domaine) et identifiant(s)
constituent le schéma de la relation.
Exemple : schéma de la relation Etudiant :
Etudiant (N° Etud : Dnum, Nom : Dnom, Prénom : Dnom, Age : Dâge)

La population d'une relation est constituée de l'ensemble des tuples de la relation. C'est un ensemble; il n'y
a donc ni doubles, ni ordre (les nouveaux tuples sont rajoutés à la fin de la relation).

Support de cours bases de données Page 13

 On appelle schéma d'une base de données relationnelle l'ensemble des schémas de ses relations. On
appelle base de données relationnelle, la population de toutes ses relations.

2. Règles de modélisation
Les attributs sont tous simples et monovalués: toute valeur prise par un attribut pour un tuple est atomique
(non décomposable par le SGBD) et unique. Les notions d'attribut multivalué, complexe ou facultatif,
n'existent pas dans le modèle relationnel.

Cas d'un attribut facultatif du modèle entité association

Certains SGBDs relationnels gèrent une valeur spéciale, appelée valeur nulle et notée "?". Cette valeur peut
être prise par tout attribut (sauf si dans le schéma on a spécifié le contraire); elle signifie alors que le tuple
n'a pas de valeur pour cet attribut. Par exemple, un étudiant, Marc Dumont, de numéro 123, dont on ne
connaîtrait pas l'âge, serait représenté par le tuple:
< 123, Dumont, Marc, ? > .
Une telle solution implique un traitement particulier de cette valeur nulle dans les langages de manipulation
des données.
A l'opposé, les attributs obligatoires sont traduits lors de la création de la table en SQL par la clause NOT
NULL.

Cas d'un attribut complexe du modèle entité association

Soit par exemple, un attribut complexe en entité association, Adresse, composé des attributs: n° rue, nom rue
, ville, code-postal. Si on veut ajouter cet attribut dans la relation Etudiant, il y a plusieurs solutions.

Solution 1: On ajoute l'attribut Adresse qui a pour domaine les chaînes de caractères. Dans ce cas,
l'utilisateur ne peut pas poser de questions sur la ville, il devra lire l'adresse et chercher dans la chaîne de
caractères le nom de la ville lui-même, ou par programme.

Solution 2: On ajoute les attributs suivants : n°rue, nom-rue, ville, code-postal à la relation. Le SGBD
connaît le détail de l'adresse, mais ne connaît pas la notion globale d'adresse.
La solution est choisie en fonction du type d'utilisation de l'attribut.
Cas d'un attribut multivalué du modèle entité association

Par exemple, on veut mémoriser les différents prénoms des étudiants (et non pas uniquement leur premier
prénom).

Solution 1: Avoir dans la relation Etudiant plusieurs attributs : Prénom1, Prénom2,...

Support de cours bases de données Page 14

 Problèmes : combien mettre d'attributs Prénom ? Comment poser des questions sur cet attribut (on est obligé
de poser autant de questions que d'attributs déclarés !).
C'est une mauvaise solution à ne pas utiliser.

Solution 2: On ne garde que N°Etud, Nom, Age pour la relation Etudiant, et on crée une relation
supplémentaire, EtudPrénoms :

EtudPrénoms N°Etud Prénom

136 Jean
136 Marie
136 André
253 Annie
253 Claudette
101 André
147 Marc
147 Antoine

Cette solution n'a pas les inconvénients de la solution précédente.

Si l'on veut, plutôt que l'ensemble des prénoms, la liste ordonnée des prénoms on décrira la relation:
EtudPrénoms2 (N°Etud, N°Prénom, Prénom).

3. Identifiant d'une relation

Définition : L'identifiant (aussi appelé clé) d'une relation est un ensemble minimum d'attributs de la relation,
tel qu'il n'existe pas deux tuples ayant même valeur pour cet identifiant.
C'est un ensemble minimum d'attributs tel que tous les autres attributs en dépendent fonctionnellement. 

Un identifiant peut-être composé d'un ou plusieurs attributs. Une relation peut avoir un ou plusieurs
identifiants. Une relation étant un ensemble, elle a toujours un identifiant qui, dans le cas le plus
défavorable, est composé de tous les attributs de la relation. Par convention, l'attribut (ou les attributs)
constituant l' (ou un des) identifiant(s) est souligné.

Exemples
Etudiant (N°Etud, nom, prénom, age)
Il n'y a pas deux étudiants qui ont le même numéro.
La relation précédente, EtudPrénoms2, possède deux identifiants qui sont N°Etud, N°Prénom et N°Etud,
Prénom.

Support de cours bases de données Page 15

 On ne peut pas avoir de valeur inconnue (notée "?") pour un identifiant (on entre obligatoirement un numéro
d'étudiant). Si on entrait deux tuples sans N°Etud, alors il existerait deux étudiants avec la même valeur
pour l'identifiant (valeur inconnue), ce qui est impossible d'après la définition de l'identifiant. On a donc la
règle suivante:

Règle: tous les attributs de tout identifiant doivent toujours avoir une valeur connue. 

Exemple
Insérer dans Etudiant: < ?, Rochat, Jean, 19> est une instruction que le SGBD doit refuser.

4. Identifiant externe
Certains attributs référencent des tuples d'une autre relation (ou parfois de la même); c'est à dire que leur
valeur est toujours égale à celle de l'identifiant d'un tuple existant dans l'autre relation. On les appelle
identifiants externes (ou clés externes ou clés étrangères). Par exemple, la relation Suit (NomC, N°Etud)
possède un identifiant (NomC + N°Etud), et deux identifiants externes : NomC et N°Etud. En effet, NomC
"référence" un Cours, c'est à dire que si une valeur NomC existe dans Suit, alors il doit nécessairement
exister un cours de ce nom là dans la relation Cours. De même, N°Etud "référence" un Etudiant.

Le schéma d'une relation comprend donc, en plus de la définition du nom de la relation et de ses attributs et
domaines associés, la définition de son (ses) identifiant, et celle de ses identifiants externes, s'il en existe.

Les identifiants externes sont déclarés de la façon suivante:

Suit (N°Etud : Dnum, NomC : Dnom)
Identifiants externes: N°Etud référence un Etudiant
NomC référence un Cours
Dans le cas où la relation référencée possède plusieurs identifiants il faut préciser lequel. La clause est alors:
N°Etud référence un Etudiant•N°Etud

Définition :
Soient deux relations R1(X, Y) et R2 (V, W), où X, Y, V, W, désignent des attributs ou des ensembles
d'attributs, et où X est un identifiant de R1, on dit que W est un identifiant externe sur R1 (ou que W
référence R1) si pour tout tuple de R2, la valeur prise par W est nécessairement la valeur de X pour un tuple
existant de R1. Autrement dit, à tout instant, l'ensemble des valeurs prises par W est compris dans l'ensemble
des valeurs prises par X. 

Vérification automatique assurée par le SGBD :

Support de cours bases de données Page 16

 Une fois déclaré l'identifiant externe W de R2 sur R1, le SGBD vérifie toutes les insertions dans R2 (il
vérifie que la valeur de W existe dans R1); il vérifie de la même façon les modifications de W. Il vérifie
toutes les suppressions de tuples de R1 (il vérifie qu'il n'existe pas de tuple dans R2 référençant ce tuple à
supprimer). Le SGBD assure ainsi, l'intégrité de référence (ou intégrité référentielle) de la base de données.

II- Normalisation d’une relation

1. Introduction
On veut décrire les produits et leurs fournisseurs. On peut le faire avec le schéma suivant, schema 1 (on suppose
que chaque produit est d'une couleur unique):

Produit (NP, NomP, Couleur, Poids)

Fournisseur (NF, NomF, Adr, Tel)
Livraison (NP, NF, Date, Qté)

Autre schéma proposé pour le même sujet, schéma 2 :

Produit (NP, NomP, Couleur, Poids)

Fournisseur (NF, NomF, Adr)
Livraisonbis (NP, NF, Date, TélF, Qté)

Exemples de problèmes rencontrés lors des mises à jour de la base de données décrite par le schéma 2:

S'il n'y a plus de livraison pour un fournisseur son numéro de téléphone est perdu. S'il existe N livraisons
pour un fournisseur, le numéro TélF est répété N fois, il faut vérifier que c'est le même. Pour insérer une
nouvelle livraison, il faut enregistrer à nouveau ce numéro TelF. Ces problèmes n'existent pas avec le
schéma 1 qui est meilleur que ce second schéma.
Le processus de transformation d'une relation posant des problèmes lors des mises à jour en relations n'ayant
pas ces problèmes, est appelé processus de normalisation.

On mesure la qualité d'une relation (ou sa capacité à représenter le monde réel sans générer les problèmes
aperçus ci-dessus) par son degré de normalisation. Une relation peut être (de la moins bonne à la meilleure) en
1ère forme normale, en 2ème forme normale, en 3ème forme normale, en forme normale de Boyce Codd, en
4ème forme normale ... (chaque forme normale implique les précédentes).

Notation : pour la suite, les lettres X, Y, Z ... désigneront soit des attributs, soit des ensembles d'attributs; les
lettres A, B, C, ... désigneront des attributs.

Support de cours bases de données Page 17

 2. Dépendances fonctionnelles et graphe des dépendances fonctionnelles
Définition :
Etant donné une relation, R (X, Y, Z), il existe une dépendance fonctionnelle, ou "DF", de Y vers Z, notée
YZ,
Si étant donné deux tuples quelconques de R, s'ils ont même valeur pour Y, alors ils ont nécessairement
même valeur pour Z.
On appelle Y source de la DF, et Z cible de la DF.
Exemple : pour la relation Produit (NP, NomP, Poids, Couleur), il y a les DF suivantes en supposant qu'il
n'existe pas deux produits de même nom :
NP NomP, NomP  NP, NP Poids
NomP  Poids, NP Coule ur, NomP  Couleur
NP (Nom P, Poids, Couleur)
(NP, NomP) Poids, (NP, NomP) Couleur
...........
Définition : une DF, X  B, est une dépendance fonctionnelle élémentaire si B est un attribut uniqu e,
et si X est un ensemble minimum d'attributs (ou un attribut unique).

Exemples : Dans la relation Produit, les DF :

NP  (couleur, poids) et (NP, NomP)
Poids ne sont pas élémentaires.

Mais les DF :
NP  Couleur, NP  Poids, NP NomP
NomP  Couleur, NomP  Poids, NomP NP sont élémentaires.

La DF :
(NP, NF, date)  Qté de la relation Livraison est élémentaire.

Chaque DF traduit un fait du monde réel. Les DF élémentaires traduisent des faits atomiques. La DF, NP
 Couleur, signifie que chaque produit, identifié par son numéro, est d'une seule couleur. La DF, (NP,
NF, date)  Qté, signifie qu'un même fournisseur ne peut livrer plusieurs fois le même jour le même
produit avec des quantités différentes.

Propriété des dépendances fonctionnelles :

Si dans une relation, on a les deux dépendances fonctionnelles, XY et YZ, alors on a aussi
la dépendance fonctionnelle XZ qui est dite déduite des deux autres.

Définition :
Etant donné une relation et un ensemble de DF portant sur les attributs de cette relation, on appelle
graphe minimum des DF de la relation, tout ensemble de DF élémentaires non déduites, équivalent à en
ce sens que toute DF de peut être déduite des DF du graphe.

Une méthode pour savoir si une DF, XY, est déduite des autres est la
suivante:
- établir un graphe (non minimum) des DF,

Support de cours bases de données Page 18

 - supprimer la DF XY du graphe,

- parcourir tous les chemins possibles partant de X et suivant les DF. La DF, XY, est déduite si un
(ou plusieurs) de ces chemins atteint Y.

Le graphe minimum des DF sert essentiellement à définir des relations normalisées.

Tout graphe (minimum ou pas) des DF peut être employé pour la recherche des identifiants des relations de
la façon suivante:
chercher, sur le graphe des DF de la relation, tout ensemble minimum d'attributs, X, tel que tous les chemins
partant de X et suivant les DF atteignent tous les autres attributs du graphe. Alors X est un identifiant de la
relation.

3. Première et deuxième formes normales

Normaliser une relation qui pose des problèmes de mise-à-jour (relation non normalisée), consiste à
décomposer cette relation en relations sans problèmes (relations normalisées). La méthode à suivre est la
suivante:
1/ vérifier que la relation est en première forme normale (voir définition ci-dessous);
2/ établir son graphe minimum des dépendances;
3/ déterminer, à l'aide du graphe, tous ses identifiants;
4/ déterminer, à l'aide du graphe, sa forme normale (voir définitions ci-dessous);
5/ si la relation n'est pas normalisée, décomposer, à l'aide du graphe, la relation en relations mieux
normalisées .
Définition : Une relation est en première forme normale si chaque valeur de chaque attribut de chaque
tuple est une valeur simple (tous les attributs sont simples et monovalués).

Soit une relation qui est en 1ère forme normale, mais qui n'est pas en 2ème forme normale:
Fournisseur1 (NF, NomProduit, Adr, Tel, Prix)

Graphe minimum des DF de Fournisseur1:

Nom Produit

Prix

Adr
NF
Tél

Une telle relation pose des problèmes :

Redondances : s'il existe 100 produits pour un fournisseur on va répéter 100 fois le nom, l'adresse, le
téléphone du fournisseur.

Support de cours bases de données Page 19

 Problème de mise à jour pour les insertions : quand on veut rajouter un produit, il faut rentrer à
nouveau l'adresse et le téléphone du fournisseur.

Problème pour les suppressions : si on supprime (momentanément) la liste des produits d'un fournisseur,
alors on supprime aussi le fournisseur.
Problème de mise à jour des tuples : si un fournisseur change d'adresse ou de téléphone, il faut faire cette
mise à jour sur tous les 100 tuples !

Ces problèmes sont dus au fait que la relation n'est pas en 2ème forme normale.
On décompose Fournisseur1 en deux relations de la façon suivante : pour chaque source de DF, on crée une
relation ayant pour attributs la source et tous les attributs en dépendance fonctionnelle directe de cette
source, en s'assurant qu'une (au moins) des deux sources est entièrement contenue dans les attributs
communs aux deux relations ainsi créées (cf théorème de Heath). On obtient ainsi :
Fournisseur (NF, Adr, Tel)
Catalogue (NF, NomProduit, Prix)
qui sont en 2ème forme normale (et même plus).
Cette décomposition est :
- sans perte d'information (NF est l'identifiant de la relation Fournisseur)
- sans perte de dépendance fonctionnelle (les DF sont soit dans l'une, soit dans l'autre des deux relations
décomposées).

Définition : Une relation est en deuxième forme normale si elle est en première forme normale et si chaque
attribut qui ne fait partie d'aucun identifiant dépend de tout identifiant entier (et non pas d'un morceau
d'identifiant)

3. Troisième forme normale

Soit une relation qui est en deuxième forme normale :
Fournisseur2 (N°F, Pays, Ville)
Il existe les DF : NF  Ville et Ville  Pays
car on suppose qu'on n'a dans la base de données que des grandes villes sans homonymes. La DF : NF  Pays
est une DF déduite.
Graphe minimum des DF de Fournisseur2 :

NF Ville Pays
Dans le relation Fournisseur2, il y a redondance : le pays d'une ville est répété, ce qui cause des problèmes
de mise à jour. On décompose donc en :
Fourn (NF, Ville)
Géo (Ville, Pays)

Support de cours bases de données Page 20

 Cette décomposition est sans perte d'information (Ville est identifiant pour Géo), et sans perte de DF (les
DF non déduites sont soit dans Fourn, soit dans Géo).

Définition : une relation est en troisième forme normale si elle est en première forme normale et si chaque
attribut qui ne fait partie d'aucun identifiant dépend uniquement des identifiants entiers.

NB : On peut toujours décomposer en troisième forme normale sans perte ni d'information, ni de DF; ce qui
n'est pas vrai des formes normales plus poussées. D'où l'intérêt de cette troisième forme normale.

III. L’algébre relationnelle

1. Introduction
On appelle algèbre relationnelle un ensemble d'opérations simples sur des tables relationnelles, à partir
desquelles des opérations plus complexes sont définies par composition. Ils définissent donc un petit langage
de manipulation de données.

2. Opérateurs de base ou primitifs

Une opération relationnelle agit sur une ou plusieurs tables et a pour résultat une table
 La projection et la sélection sont des opérations qui s’appliquent à une table
 Les opérations ensemblistes (union, intersection, différence) ne peuvent être utilisés qu’avec deux
tables ayant les mêmes attributs et fournissent une troisième table ayant les même attributs
 Le produit cartésien et la jointure fournissent une troisième table à partie de deux tables
quelconque

2.1 Projection
Projeter sur un ensemble de colonnes d’une table T, revient à supprimer de la table celles qui ne sont pas
dans l’ensemble

E
x
e
m
p
l
e
Support de cours bases de données Page 21
 2.2 Sélection
La sélection sur une condition consiste donc à garder les lignes de la table vérifiant la condition

exemple

3. Opérateurs non essentiels ou dérivés

3.1 INTERSECTION
A∩B contient toutes les lignes communes aux deux tables A et B

Support de cours bases de données Page 22

 Intersection :Exemple

3.2 UNION
A∪B est la table contenant toutes les lignes de A et toutes les lignes de B sans doublon

3.3 DIFFERENCE
A – B est la table contenant toutes les lignes de A qui ne se trouvent pas dans B

Support de cours bases de données Page 23

 DIFFERENCE : Exemple

3.4 PRODUIT CARTESIEN

Pour chaque ligne de A fabriquer autant de lignes qu’il y a de lignes dans B par concaténation

Support de cours bases de données Page 24

 3.5 JOINTURE
C’est l’opération permettant de « coller » au bout des lignes de la table A toutes les lignes de la table B
vérifiant la condition de jointure. Le cas le plus fréquent est celui où la condition est l’égalité de deux
attributs
Le predicat ´ P est de la forme R.ai θ S.bj ou` θ est l’un des operateurs de comparaison. Si le predicat ´ P
est l’egalité ( =), on parle d’equijointure

On appelle jointure de T1 et T2 sur la condition cond la sélection sur cond effectuée sur T1 X T2:

Exemple

Support de cours bases de données Page 25

 TD LE MODELE RELATIONNEL

Objectifs

 Lire les relations entre les entités en fonction des cardinalités.
 Appliquer les règles de passage d’un modèle Entité/Association à un modèle
Relationnel.

Exercice n°1 :
Transformer le modèle Entité/Association suivant en modèle relationnel :

Exercice n°2 :
Soit le schéma E /A donnée ci-dessous représentant des visites dans un hôpital. Répondez aux
questions suivantes en fonction des caractéristiques de ce schéma.

Support de cours bases de données Page 26

 1- Deux médecins différents peuvent-ils prescrire le même médicament ? O / N
2- Un médecin peut-il recevoir plusieurs patients dans la même consultation ? O / N
3- Un patient peut-il effectuer plusieurs visites ? O / N
4- Peut-on prescrire plusieurs médicaments dans une même consultation ? O / N
5- Construire le schéma relationnel correspondant au schéma E/A ci-dessus. Indiquer précisément :
La clé primaire, Les clés étrangères et Les contraintes éventuelles (sur les domaines).

Exercice n°3 :
On souhaite gérer des réservations dans une compagnie d'hôtels. On considère donc le
diagramme entité-association suivant (les attributs soulignes sont les identifiants des entités) :

1. A partir de ce diagramme, répondez aux questions suivantes par Oui ou Non en justifiant votre
réponse.
a. Est-il possible d'avoir des clients homonymes ?
b. Un client peut-il réserver plusieurs chambres à une date donnée ?
c. Est-il possible de réserver une chambre sur plusieurs jours ?
d. Est-il possible de savoir si une chambre est libre à une date donnée ?
e. Est-il possible de réserver plusieurs fois une chambre à une date donnée ?
2. Proposez un schéma de base (un modèle relationnel) correspondant au diagramme (Soulignez les
attributs identifiants des relations et ajoutez le caractère « # » avant les attributs identifiants
externes).

Exercice n°4 :
Soit le schéma entité-association suivant :

Support de cours bases de données Page 27

 Proposez un schéma de base (un modèle relationnel) correspondant à ce modèle E/A
(Soulignez les attributs identifiants des relations et ajoutez le caractère « # » avant les attributs
identifiants externes).

Support de cours bases de données Page 28

 TD: Algèbre Relationnelle
Objectifs :

 Manipuler les opérateurs de l’algèbre relationnelle

 Appliquer les opérateurs de l’algèbre relationnelle sur des schémas relationnels.

Exercice n°1 :
Soient les trois relations R1, R2 et R3 :

1- Déterminer l’union, l’intersection et la différence entre R1 et R2 et entre R2 et R3,

sachant que R1.A, R2.A et R3.Z ont le même domaine.
2- Déterminer les relations R4, R5, R6, R7 et R8 comme suit :
 R4 = π X, Y(R3)
 R5 = R2 x R4
 R6 = π B, X, Y(R2 ><R4)
 R7 = R2 ÷ π A (R1)
 R8 = σ<X=’x1’> R5

Exercice n°2:

Soit la table de données Personne: Personne (Nom, Age, Ville)

Nom Age Ville

Marc 29 Paris
Catherine 32 Lyon
Sophie 54 Paris
Claude 13 Montpellier
Serge 40 Lyon

Support de cours bases de données Page 29

 A. Donnez les résultats des requêtes suivantes, et indiquer leur type (sélection ou
projection):
a. σ (Personne )
age =30

b. π Age (Personne)
c. π Age (σ<Nom=’Serge’> (Personne))

B. Exprimer les requêtes suivantes en Algèbre rationnelle:

 Requête 1: L'ensemble des informations concernant les personnes qui habitent
Paris.
 Requête 2: L'ensemble des informations concernant les personnes qui ont moins
de 30 ans.
 Requête 3: Les villes identifiées dans la Table de Données.
 Requête 4: Les noms des personnes habitant à Paris.

Exercice n°3 :

1. Soient les trois relations R1 et R2:

Trouvez le résultat de chaque requête :

a. R 3 = R1 ∪ R2
b. R 4 = R2 ∪ R1

c. R 5 = R2 – R1
d. R 7 = π A (R1)

e. R 8 = π* (σ<B ≠ ‘b2’> (R1))

2. Soit le schéma relationnel suivant :

Pilote (numpil, nompil, adr, sal)

Avion (numav, nomav, capacite, loc)

Support de cours bases de données Page 30

 a. Donnez la liste des avions dont la capacité est supérieure à 350 passagers.
b. Quels sont les numéros et noms des avions localisés à Nice ?
c. Donnez toutes les informations sur les pilotes de la compagnie.
d. Quel est le nom des pilotes domiciliés à Paris dont le salaire est supérieur à 15000F?

Exercice n°4:
Soit un schéma relationnel composé de la relation Passager (nom, age, ville), on propose
l’extension suivante de la relation suivante :

Passager
Nom Age Ville
Catherine 32 Lyon
Sophie 54 Paris
Claude 13 Montpellier
Serge 40 Lyon

1. Donnez les résultats des requêtes suivantes, et indiquer leur type (sélection ou projection):
a. σ (Passager)
Nom=Claude

b. π (Passager)
Ville

c. π (σ (Passager))
Nom Age=30

2. Exprimer les requêtes suivantes en Algèbre rationnelle :

a. L'ensemble des informations de Claude et Serge.
b. L'ensemble des informations concernant les passagers de Lyon.
c. Les villes identifiées dans la Table de Données.
d. Les noms des passagers habitant à Paris.

Support de cours bases de données Page 31

 TD : Normalisation
Objectifs :

 Etudier les dépendances fonctionnelles.

 Normaliser une base de données relationnelle.

Exercice n°1 :
Soit R1 (A, B, C, D, E, F) une relation avec l'ensemble de dépendances suivant :
DF = {AB → C, AB → D, AB → E, AB → F, B → C, D → E, D → F}

1. Donner le graphe (ensemble) minimum de dépendances. Quelles est la clé de R1 ?

2. Quelle est la forme normale de R1 ?
3. On décompose la relation R1 en R11 et R12 : R11(A, B, D, E, F) et R12(B,C). Quelles
sont les formes normales des relations R11 et R12 ?
4. Proposer une décomposition sans perte d'information de R11.

Exercice n°2:

Soit le schéma de la relation R(A, B, C, D, E, G) et un ensemble donné de dépendances

fonctionnelles DF pour cette relation:
DF = {A → B,C ; A,C → E ; A,D,E → B,G ; C,G → D ; B,G → C ; C → B}

1. Donner la couverture minimale des dépendances fonctionnelles de R.

2. Donner une décomposition de R en relations 3NF sans perte d'informations et sans perte
de dépendances.
3. Précisez l'identifiant de chaque relation obtenue.

Exercice n°3:

On considère une relation R construite sur les attributs Propriétaire, Occupant, Adresse,
Noapt, Nbpièces, Nbpersonnes, un nuplet (P, O, A, N, NB1, NB2) ayant la signification
suivante :
la personne O habite avec NB2 personnes l'appartement de numéro N ayant NB1 pièces dont
le propriétaire est P et l’adresse A

Support de cours bases de données Page 32

 Une analyse de cette relation nous fournit un ensemble initial E de dépendances fonctionnelles :
E = {O → A ; O → N; O → NB2 ; A, N → P ; A, N → O ; A, N → NB1}
1. Donner l'ensemble des dépendances fonctionnelles élémentaires engendrées par E.
2. Quelles sont les clés potentielles de R ?
3. R est-elle en 3ème forme normale ?

Exercice n°4:

On considère le schéma relationnel R défini sur les attributs suivants :

C : cours
P : professeur
H : heure
S : salle
E : étudiant
N : note
un nuplet (C, P, H, S, E, N) a pour signification que le cours C est fait par le professeur P à
l'heure H dans la salle S par l'étudiant E qui a reçu la note N.
L'ensemble DF des dépendances fonctionnelles initiales est le suivant :
DF = {C → P ; H, S → C; H, P → S; C, E → N; H, E → S
1. Donner l'ensemble des dépendances fonctionnelles élémentaires engendrées par E.
2. Quelle est la clé de la relation R ? Montrer qu'elle est unique.
3. Quelle est la forme normale de la relation R ? Si elle n'est pas en 3FN proposer une
décomposition en 3FN.

Exercice n°5 :

Soit la relation « Client » qui possède le schéma suivant :

Client (numcli, codepostal, nom, prenom, tel, ville)

 Normaliser cette relation jusqu’à la BCFN.

Exercice n°6 :

Soit R une relation et X, Y, Z et W sont les ensembles d’attributs associés : R(X, Y, Z, W).
A-t-on les implications logiques suivantes ? Si la réponse est vrai préciser les axiomes
d’Armstrong ou les propriétés utilisés ?

Support de cours bases de données Page 33

 1- {X → Y ; Z → W} => XZ → YW
2- {XY → Z ; Z → X} => Z → Y
3- {X → Y ; W → Z} et Y  W => X → Z
4- {W → Y ; X → Z} => WX → Y
5- {XY → Z ; Y → X} => XW → Z
6- {X → Y ; X → W ; WY → Z} => X → Z

Support de cours bases de données Page 34

Support de cours bases de données Page 35