CHAPITRE 1

Concepts fondamentaux

1.

Bases de donnes, banques de donnes et fichiers

Base de donnes (BD)

Systme de gestion de bases de donnes (SGBD)
Une base de donnes (BD) reprsente l'ensemble (cohrent, intgr, partag) des informations ncessaires
au fonctionnement d'une entreprise, ensemble dont la gestion est assure par un logiciel appel systme de
gestion de bases de donnes (SGBD).
On entend ici par entreprise toute collectivit d'individus travaillant en coordination la ralisation d'un
objectif commun.
Exemples de base de donnes: celle qui permet la gestion des personnels, tudiants, cours, inscriptions, ...
d'une universit ou cole, celle du systme de rservation de places d'avion des compagnies d'aviation, celles
qui permettent la gestion des comptes des clients des socits bancaires, ...
Banque de donnes
Une base de donnes est dveloppe au sein d'une entreprise, pour son propre fonctionnement. Inversement,
une banque de donnes est un ensemble de donnes, propres un domaine d'application, que des
"producteurs" runissent pour ensuite en commercialiser l'usage vers le public extrieur. Exemple: les
banques de donnes juridiques, conomiques, mdicales, des brevets, des proprits des matriaux, ... . La
constitution et l'exploitation des banques de donnes font appel des techniques spcifiques (tlmatique,
par exemple), diffrentes des techniques bases de donnes, seules tudies dans ce cours.
Fichier
Dans une entreprise, il convient de faire appel l'approche base de donnes lorsque les donnes grer sont
de natures diverses (exemple : tudiants, cours, enseignants, salles, ...) et possdent 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 donnes grer, bien que importantes en volume, sont homognes : les abonns d'une revue, le
personnel d'une entreprise, les produits vendus par un magasin ... . Dans ces cas, on parlera de fichier (le
fichier des abonns, ...) et l'on utilisera un systme de gestion de fichiers (SGF), moins complexe qu'un
SGBD.
Tout systme d'exploitation d'un ordinateur contient un SGF spcifique. Toutefois, pour les applications, on
fait plutt appel des progiciels du commerce (exemple: dBase, Filemaker, ...), d'un usage plus simple et
offrant des fonctionnalit plus labores.

Chapitre 1 : Concepts fondamentaux

Il est noter que l'implantation physique d'une base de donnes sur les mmoires secondaires se fait via la
notion de fichier. Le choix de ceux-ci, toutefois, reste de la comptence du SGBD et est invisible
l'utilisateur. Le cours abordera les techniques de gestion de fichiers lorsque nous traiterons des aspects
internes de ralisation d'un SGBD.

2.

Cycle de vie d'une base de donnes

On appelle conception d'une base de donnes la phase d'analyse qui aboutit dterminer le futur contenu
de la base.
Lorsqu'une entreprise dcide, pour son informatisation, d'adopter une approche base de donnes, le premier
problme rsoudre, peut-tre le plus difficile, est de dterminer les informations qu'il conviendra de mettre
dans la base de donnes. Il faut ainsi que l'ensemble des utilisateurs actuels et futurs de cette base de donnes
se mettent d'accord sur la nature et les caractristiques 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, spcifique du logiciel choisi, que l'on
appelle langage de description de donnes (LDD). Une fois que le SGBD aura pris connaissance de cette
description, il sera possible aux utilisateurs d'entrer les donnes, c'est--dire de constituer la premire
version, initiale, de la base de donnes. On appelle implantation de la base de donnes cette phase qui
consiste dcrire la base de donnes dans le langage du SGBD et construire cette premire version.
Une fois l'implantation termine, peut commencer l'utilisation de la base de donnes. Celle-ci se fait au
moyen d'un langage, dit langage de manipulation de donnes (LMD), qui permet d'exprimer aussi bien les
requtes d'interrogation (pour obtenir des informations contenues dans la base) que des requtes de mise
jour (pour ajouter de nouvelles informations, supprimer des informations primes, modifier le contenu des
informations).
On appelle cycle de vie d'une base de donnes la suite des phases conception, implantation, utilisation.

3.

Modles de donnes et schmas

Au cours des diffrentes phases de la vie d'une base de donnes, plusieurs descriptions sont successivement
labores, chacune rpondant un objectif dtermin et complmentaire. Dans l'tat actuel de l'art, ces
descriptions ne peuvent tre faites avec le langage naturel (en franais, par exemple): celui-ci est trop ambigu
et encore trop difficile comprendre par un ordinateur. On fait donc appel un langage formel, base sur un
certain nombre de concepts bien tablis. Par exemple, les concepts d'objet, de lien, de proprit.
On appelle modle de donnes l'ensemble des concepts qui permettent la description de donnes d'une base
et les rgles d'utilisation de ces concepts. On appelle schma d'une base de donnes l'expression de la
description de la base de donnes d'une entreprise obtenue en employant un modle de donnes.
Les diffrents schmas tablis pour dcrire les divers aspects d'une base de donnes sont les suivants:
1/ Lors de la phase de conception, il est ncessaire 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 donnes. Dans cette description, il n'est gure besoin de faire appel des concepts de
l'informatique, dans la mesure o le problme traiter est de dterminer quelles sont les informations
ncessaires la vie de l'entreprise, et ce indpendamment de la solution informatique retenue. Cette
description s'appuiera donc sur un ensemble de concepts qui ne font aucune rfrence l'informatique : le
modle utilis est dit "conceptuel".
La description ainsi obtenue s'appelle schma conceptuel des besoins. Un modle conceptuel comporte
gnralement deux parties: le modle statique, concepts permettant de dcrire la structure de donnes, et le
modle dynamique, concepts permettant de dcrire les oprations sur les donnes.
2

Chapitre 1 : Concepts fondamentaux

Quelque soit le modle conceptuel choisi (il en existe plusieurs), il n'est pas possible de dcrire avec celui-ci
toute la connaissance que l'on possde sur les donnes dcrire: notamment, les rgles de gestion de ces
donnes. Par exemple, l'expression de la rgle "il ne doit pas y avoir plus de 20 % d'cart entre les salaires
des employs d'un mme service et d'une mme catgorie" n'est pas possible avec les seuls concepts
descriptifs d'un modle. On introduira donc, en supplment la description tablie, la description explicite
des contraintes supplmentaires, dites contraintes d'intgrit. On utilise pour cela un langage d'expression
de rgles, compatible avec le modle conceptuel utilis.
2/ Le schma conceptuel des besoins dcrit la future base, indpendamment des choix techniques
d'implantation. La phase suivante, celle d'implantation, demande que la partie dcrivant les donnes de ce
schma soit traduite dans les concepts du modle utilis par le SGBD choisi. On appelle modle logique (ou
modle machinable), le modle sur lequel est construit un SGBD actuel. Il existe aujourd'hui plusieurs
modles logiques (relationnel, CODASYL, hirarchique, ...). Le schma obtenu en traduisant dans un
modle logique le schma conceptuel des besoins sera appel ici le schma logique de la base de donnes. A
noter cependant que, dans la terminologie courante, ce schma est souvent appel le schma conceptuel de la
base de donnes, ce qui ne va pas sans ambigut avec le schma conceptuel rsultant de la phase de
conception (point 1 ci-dessus).
3/ L'implantation des donnes elles-mmes, c'est--dire le chargement de la base de donnes avec la version
initiale, ncessite que soient fixs les choix en matire de structuration de donnes sur la mmoire 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 systme qui, en fonction de leur analyse des traitements qui vont
tre effectus sur la future base de donnes, dtermineront les paramtres 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
schma interne de la base de donnes: description de comment les donnes de la base sont enregistrs dans
les fichiers. Cette description fait donc appel un nouveau modle, appel modle interne, o les concepts
seront ceux de fichier, organisation, index, chemin d'accs, cl, ...
4/ Enfin, au cours de la phase d'utilisation de la base de donnes, d'autres schmas sont labors pour
rpondre aux besoins spcifiques des diffrents groupes d'utilisateurs. Ceux-ci n'ont pas besoin de connatre
l'ensemble du contenu de la base, savoir, toutes les informations sur chaque type d'objet. Chaque utilisateur
a des exigences limites (il n'est intress que par certaines informations) et particulires (il peut souhaiter
une reprsentation des informations diffrente de celle dcrite dans le schma conceptuel).
A chaque utilisateur (ou groupe d'utilisateurs) est donc associ un schma, dit son schma externe, qui
dfinit le sous-ensemble de la base de donnes auquel il a accs, structur de faon rpondre ses besoins
spcifiques.
Avantages de cette approche :
. simplicit chaque utilisateur n'a dans son schma externe que ce qui l'intresse
. protection il n'est pas possible que, par erreur ou par malveillance, un utilisateur accde aux
donnes d'autres utilisateurs non dcrites dans son schma externe.
Dans les SGBD actuels, le modle de donnes employ pour dcrire les schmas externes est le mme que
celui du schma logique, mais on pourrait proposer des modles externes plus adapts aux besoins
spcifiques des utilisateurs.
Un SGBD gre donc trois types de schmas pour une base de donnes, qui sont organiss en cascade de la
faon suivante:

Chapitre 1 : Concepts fondamentaux

schmas externes

schma logique

la BD vue par les

utilisateurs

la BD vue globalement

schma interne
la BD vue par
l'informaticien

Un exemple illustrant ces trois niveaux de schmas (pour un SGBD relationnel) est le suivant.
Entreprise: un institut de formation permanente.
Schma logique (SL)
Etudiant :
Enseignant :
Cours :
Inscription :

nom, prnom, date de naissance, ntudiant

nom, prnom, statut, ncompte_bancaire
nomC, cycle, nom_enseignant
ntudiant, nom_cours, note1, note2

Schmas externes (SE)

Schma externe du professeur de base de donnes :
Etudiant _BD :

nom, prnom, note1, note2, note_finale

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

Schma externe du service de gestion du personnel enseignant :

Professeur :

nom, prnom, ncompte_bancaire, nombre_de_cours, liste(nom_cours)

tel que Professeur rsulte 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))

Schma interne (SI)

Etudiant :

Enseignant
+
:
Cours

fichier FEtud,
contenu : nom, prnom, date de naissance, ntudiant
index sur ntudiant,
index secondaire sur nom+prnom
fichier FEnsCours,
contenu : nom, prnom, statut, ncompte_bancaire, liste(nomC, cycle)
tel que nom_enseignant dans Cours = nom dans Enseignant
index sur nom,
4

Chapitre 1 : Concepts fondamentaux

deux index secondaires, l'un sur nomC, l'autre sur cycle

Inscription :

4.

fichier FInscrits,
contenu : ntudiant, nom_cours, note1, note2
index sur ntudiant,
index secondaire sur nom_cours

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 conformment aux requtes de ses utilisateurs:

L'interface utilisateur permet aux utilisateurs d'exprimer des requtes: soit pour dfinir 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'accs physique permet au SGBD d'accder aux donnes sur les supports (disques, ...).
Un SGBD gre des problmes trs diffrents, avec des objectifs particuliers:
- interface utilisateur: comprhension, analyse et vrification des requtes; objectifs: convivialit de
l'interface, puissance des langages de description et de manipulation;
- interface d'accs physique: optimisation du stockage des donnes (en termes d'espace occup sur les
supports) et de l'accs aux donnes (en temps); objectif: avoir les meilleures performances.
L'articulation entre ces deux interfaces doit rpondre un objectif fondamental: assurer l'indpendance
programme/donnes. 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 oprs au niveau interne en matire de fichiers;
d'autre part, inversement, la possibilit pour un administrateur systme de modifier ces choix, pour amliorer
les performances, sans que cela ait un impact sur les utilisateurs (leurs requtes d'interrogation ou de mise
jour, ou leurs programmes d'application qui utilisent la base de donnes).
Enfin, un SGBD tant utilis simultanment par plusieurs utilisateurs, il a rsoudre plusieurs problmes
internes de coordination de ses actions, de cohrence et de contrle du bon droulement de ses activits.
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 problme du dialogue avec les utilisateurs, c'est--dire l'analyse

des demandes de l'utilisateur, le contrle des droits d'accs de l'utilisateur, la
prsentation des rsultats

. niveau interne

s'occupe du stockage des donnes dans les supports physiques et de la gestion des
structures de mmorisation (fichiers) et d'accs (gestion des index, des cls, ...)
5

Chapitre 1 : Concepts fondamentaux

. niveau intermdiaire:

assure les fonctions de contrle global:

- optimisation globale des requtes
- gestion des conflits d'accs simultans de la part de plusieurs utilisateurs
- contrle gnral de la cohrence de l'ensemble
- coordination et suivi des processus en cours
- garantie du bon droulement des actions entreprises mme en cas de panne
- ...

La couche intermdiaire de contrle est appele niveau logique: on cherche ne dpendre ni des exigences
des utilisateurs ni des structures physiques choisies.

couche
logique
schmas
externes

schma
logique

schma
interne

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

Une requte, exprime par l'utilisateur dans un langage accept par le systme (LMD), est d'abord analyse
du point de vue syntaxique (conformit la grammaire du langage); suit une analyse smantique (les objets
cits doivent tre connus dans le schma externe de l'utilisateur).
Aprs cette validation, faite dans la couche externe, la requte est traduite, pour son passage la couche
logique: les rfrences aux objets du schma externe sont remplaces par les rfrences aux objets
correspondants dans le schma logique. On utilise pour cela la description des rgles de correspondance
entre schma externe et schma logique, tablie, ncessairement, au moment de la dfinition du schma
externe.
Au niveau logique, on fait les contrles sur la confidentialit, la concurrence, etc. Si la requte est accepte,
elle est optimise et dcoupe en sous-requtes plus lmentaires qui sont transfres au niveau interne;
sinon, elle peut tre mise en attente ou refuse.
Au niveau interne, chaque sous-requte reue est traduite en une ou plusieurs requtes physiques
correspondantes (en fonction des informations contenues dans le schma interne), puis le SGBD ralise
l'accs physique aux donnes (extraction ou modification). S'il s'agit d'une requte d'interrogation, les
donnes extraites sont passes la couche logique, puis la couche externe. Ici elles sont rorganises, selon
le schma externe de l'utilisateur, avant de les transmettre l'utilisateur.