Cours de Bases de donnes

Rsum de cours Master Informatique anne 1 2005/2006

Prsentation des bases de donnes

Les Systmes de Gestion de Bases de Donnes (SGBD) rpondent un besoin global de gestion d'informations, comme
par exemple :
Gestion des personnels, tudiants, cours, inscriptions, ... d'une universit
Systme de rservation
Gestion des comptes clients d'une banque
Gestion des commandes
Pour rpondre au besoin de description d'une base de donnes, il faut :
dcrire les donnes de l'application sans faire rfrence une solution informatique particulire (modlisation
conceptuelle)
laborer une description quivalente pour le stockage des donnes dans le SGBD choisi (modlisation logique et
langage de description des donnes (LDD))
Cette base de donnes doit rpondre aux besoins de cration et modifications :
Crer la base de donnes initiale avec les donnes minimales (langage permettant l'insertion de donnes)
Crer au fur et mesure les donnes, pouvoir modifier et ventuellement supprimer toute donne dj rentre
(langage de manipulation de donnes (LMD) pour l'insertion, la modification et la suppression).
Elle doit de plus grer des besoins d'interrogation :
Rpondre toute demande d'informations portant sur les donnes contenues dans la base. (langage de requte
langage d'interrogation).
Une base de donnes doit rpondre des besoins d'exactitude et de cohrence. Il faut pouvoir exprimer toutes les rgles
qui contraignent les valeurs pouvant tre enregistres de faon viter toute erreur qui peut tre dtecte (langage
d'expression de contraintes d'intgrit).
On compte de plus :
Besoins de garanties : il ne faut pas que les informations soient perdues cause d'un disfonctionnement
quelconque : erreur de programmation, panne systme, panne de l'ordinateur, coupure de courant, ... (garantie de
fiabilit). Il ne faut pas qu'une action faite pour un utilisateur soit perdue du fait d'une autre action faite
simultanment pour un autre utlisateur (garantie de contrle de concurrence).
Besoins de confidentialit : toute information doit pouvoir tre protge contre l'accs par des utilisateurs non
autoriss (en lecture, ou en criture) : garantie de confidentialit.
Besoins d'efficacit : le temps de rponse du systme doit tre conforme aux besoins en interactif (pas plus de 3
secondes) et en programmation (assez rapide pour assumer la charge de travail attendue nombre de transactions
par jour par exemple). On utilise pour cela des mcanismes d'optimisations, avec parfois rpartition, duplication
des donnes et/ou donnes sur plusieurs sites.
Les moyens utiliss :
Les bases de donnes : ensemble cohrent, intgr et partag de donnes structures dfini pour les besoins d'une
application.
Systme de gestion de base de donnes (SGBD) : logiciel permettant de couvrir les besoins : dfinir une
reprsentation des informations apte stocker, interroger et manipuler de grandes quantits de donnes dont il
faut garantir la longvit et l'accessibilit de manire concurrente et sre.
L'architecture d'un SGBD :
L'interface utilisateur, lie au SGBD, permet l'analyse et la vrification des requtes.
L'interface d'accs physique : Stockage accs aux donnes, optimisation des performances.
Un SGBD se compose de 3 couches :
Couche externe : dialogue avec les utilisateurs, vues associes chaque groupe d'utilisateurs
Couche interne : stockage des donnes sur des supports physiques, gestion des structures de mmorisation et

1
 d'accs
Couche logique : contrle global et structure globale des donnes
Voyons maintenant brivement le fonctionnement du SGBD (un exemple avec le parcours d'une requte) :
Analyse syntaxique et smantique d'une requte
traduction au niveau logique
contrle de confidentialit, concurrence
si la requte est accepte, optimisation et dcoupe en sous-requtes lmentaires transfres au niveau interne
au niveau interne, traduction des sous-requtes en requtes physiques correspontes.
Le cycle de vie d'une base de donnes se dfini en 4 phases :
Conception de la base (schma conceptuel)
Implantation des donnes (schma logique)
Utilisation (interrogation, mises jour)
Maintenance (correction, volution)
Le niveau conceptuel permet de passer de la description des besoins au modle conceptuel (indpendant de la solution
informatique et dfinissant la partie statique structure des donnes et la partie dynamique rgles et oprations). Les
contraintes d'intgrits sont inhrentes aux donnes et traduisent les rgles des applications utilisant la base.

L'exemple ci-dessus montre un schma conceptuel. On peut y ajouter les contraintes d'intgrits suivantes :
Un tudiant suit au plus 6 cours
Un cours est assur par un unique Enseignant
La traduction du schma conceptuel en un schma logique se fait en fonction des concepts du modle utilis par le
SGBQ choisi. Un exemple de traduction dans le schma logique relationnel de l'exemple prcdent :
Etudiant (nom, prnom, date de naissance, N etudiant)
Enseignant (nom, prnom)
Cours (Nom_Cours, Cycle, nom_enseignant)
Inscript (N Etudiant, Nom_Cours, notes)
L'implantation des donnes dpend du choix des structures de stockages des donnes par les administrateurs systmes :
schma interne : description des choix d'enregistrement des donnes dans les fichiers
fait appel un nouveau modle, le modle interne, ou les concepts sont ceux de fichier, organisation de fichier,
index, chemin d'accs, cl, ...

Schmas entits/associations
On appelle Objet une entit. Les liens entre des entits s'appellent Associations . Les proprits d'une entit ou
d'une association s'appelle attribut . Un attribut peut aussi dfinir les proprits associes un autre attribut. (Par
exemple un attribut date est dfini par les attributs jour , mois et anne ).

Ici :
Personne et Maison sont des objets (ou des entits)
Achte est une association
Nom, Prix et Adresse sont les attributs respectifs de Personne, Achte, Maison

2
Un schma entits/associations dfinit de plus des contraintes de cardinalit des associations : A combien d'associations
de A une entit E appartient ? : On dfinit cela sur un intervalle reprsentant le minimum et le maximum :

Dans l'exemple ci-dessus :

une Personne achte au minimum aucune maison, et au maximum n maisons
une Maison peut ne jamais tre achete (0) et elle est au plus achete par une seule personne (1)
Les contraintes de cardinalits existent aussi pour les attributs. Par exemple, l'attribut Poste d'une entit Employ est
compos des sous attributs :
intitul (1:1)
salaire (1:n)
date dbut (1:1)
date fin (0:1)
Il peut donc s'agir d'attributs :
monovalu (x:1) ou multivalu (x:n)
obligatoire (1:x) ou facultatif (0:x)
Les cls sont les identifiants des entits et des associations. La raison d'utilisation des cls est qu'elles permettent de
dsigner une entit (une association) de faon univoque. Une cl est un ensemble (minimal) d'attributs tel qu'il n'existe
pas deux instances de l'entit ou de l'association ou ces attributs aient la mme valeur. La valeur des attributs de la cl
dtermine la valeur de tous les attributs.
(Dans un schma, les attributs constituant la cl sont sousligns).
On appelle entit faible une entit qui ne peut tre identifi par ses seuls attributs propres. Dans l'exemple ci-dessous,
Exemplaire est une entit faible, qui besoin de la cl de Livre : un exemplaire est un Livre avec un numro ISBN et un
numro d'exemplaire.

Les contraintes d'intgrit (CI) d'un schma entit/association sont :

des rgles dfinissant ce qui est possible (les tats : CI statiques et les transitions : CI dynamiques)
doivent tre dcrites explicitement avec un langage appropri : le MCD ne peut pas les exprimer toutes
une base de donnes est cohrente si toutes les CI sont respectes par les valeurs de la BD au cours de son
utilisation (utilisation qui respecte les CI dynamiques)
Pour terminer la prsentation des schmas entits/associations, nous allons voir la spcialisation et la gnralisation. La
spcialisation est la division d'un ensemble d'entits en sous-classes. A l'inverse la gnralisation est un regroupement
d'un ensemble d'entits en une super classe. Le schma ci-dessous montre la reprsentation d'une
spcialisation/gnralisation sur un schma relationnel (ISA = ... is a ...)

3
Des schmas entits/associations au schma relationnel
Le modle relationnel est un modle de niveau logique trs simple dfini par Ted Codd en 1970. Il est aujourd'hui utilis
par beaucoup de SGBD commerciaux.
Il existe un seul type de structure pour reprsenter les donnes : la relation (table) :
chaque ligne de la table (tuple) reprsente une association
les noms des colonnes sont les attributs.
Soit le schma conceptuel suivant :

On obtient le schma relationnel suivant :

Client (Nom, Adresse, Solde)
Commande (N, Nom, Nom_F, Quantit)
Fournisseur (Nom_F, Adresse_F, Prix)
Ainsi, le modle relationnel peut tre dfini par un certain nombre d'identificateurs que l'on appelle attributs :
le schma d'une relation est un ensemble d'attributs
A chaque attribut, on associe un domaine : l'ensemble des valeurs possibles. En gnral, les attributs ne peuvent
prendre que des valeurs atomiques
Le domaine d'un schma d'une relation R est le produit cartsien des domaines de ses attributs.
Pour un schma d'une relation R(A1, ..., An) donne, un tuple ou n-uplet est un lment de Dom(A1) x ... x Dom
(An)
Pour un schma de relation R, une relation est un ensemble fini de tuples
Une base de donnes est un ensemble fini de relations
Concernant les cls, pour un schma d'une relation :
une cl est un ensemble d'attributs qui identifie de manire unique un tuple de la relation
une cl minimale est une cl qui, prive de n'importe quel attribut, n'est plus une cl.
Nous allons voir comment passer maintenant du modle entit-association au modle relationnel. Un type d'entit E non
faible est reprsent par une relation T dont les attributs simples sont les attributs du type d'entit E. De plus, la cl de T
est l'identifiant de E.
Dans l'exemple ci-dessus : on passe de l'entit Client la table Client (Nom, Adresse, Solde).
Remarques :
on remplace les attributs composites par leurs composants (ainsi, Date devient : jour, mois, anne)
les attributs multivalus sont viter!!
Si l'entit E considre est une entit faible, elle est reprsente par une relation T dont les attributs sont
les attributs du type d'entit E
les attributs identifiants E et la cl de T est l'identifiant de E
Soit par exemple, le schma entit association suivant :

Le schma relationnel correspondant est :

Vol (Num Vol, Origine, Destination
Dpart (Num Vol, Date, Nb_passagers)
Un type d'association R est reprsent par une relation T dont les attributs sont :

4
 les attributs de l'association R
les attributs identifiants les entits en relation. Et dans ce cas, la cl de T n'est pas vidente. S'il faut, on rajoute
arbitrairement une cl.
Par exemple :

On obtient, pour l'association Commande le schma relationnel : Commande (Nom, Nom_F, N, Quantit).
Les attributs multivalus A d'un type d'entit E est traduit par une relation T dont les attributs sont les attributs de
l'identifiant de E et les attributs de A. Mais en ralit, il vaut mieux viter les attributs multiples.
Concernant la spcialisation/gnralisation, il existe plusieurs solutions :

Solution 1 : Le type d'entit E est reprsent par une relation T dont les attributs sont les attributs de E et la cl de T est
l'identifiant de E. Les sous entits Ei sont reprsentes par des relations Ti dont les attributs sont les attributs de Ei et les
attributs identifiants de E, la cl de Ti est l'identifiant de E. Avec l'exemple prcdent :
Employ (Numro, Nom, Adresse)
Secrtaire (Numro, Vitesse de frappe)
Professeur (Numro, Discipline)
Solution 2 : Une seule table pour tous le monde avec tous les attributs (des attributs peuvent donc tre NULL). Avec
l'exemple prcdent :
Employ (Numro, Nom, Adresse, Vitesse de frappe, Discipline)
Solution 3 : Une table par entit avec exactement ses attributs. La cl de T est l'identifiant de E. La cl de Ti est
l'identifiant de E ou un autre identifiant spcifique A. Une relation peut identifier un objet de Ei et un de E, si on
souhaite rpter les objets d'un Ei dans E. Avec l'exemple prcdent, on obtient le schma relationnel suivant :
Employ (Numro, Nom, Adresse)
Secrtaire (Numro, Nom, Adresse, Vitesse de frappe)
Professeur (Numro, Nom, Adresse, Discipline)
Pour conclure, rappelons donc la description d'un schma relationnel. Un schma relationnel dfinit donc pour chaque
relation :
le nom de la relation,
la dfinition,
les attributs et les domaines des dits attributs,
les attributs cls
les attributs externes (attributs dfinis dans une autre relation)
les contraintes d'intgrit de la relation.
Il dfinit de plus les contraintes d'intgrits portant sur plusieurs relations.

5
Algbre relationnelle
L'algbre relationnelle permet de dfinir un ensemble d'oprations :
relation + condition = nouvelle relation
relation + ensemble d'attributs = relation,
relation + relation = relation.
Les oprations sont (on considre des schmas R et S de relations disjointes et r une relation de schma R et s une
relation de schma S) :
La slection (note ) : la slection P (r) est une relation de schma R constitu des tuples de R qui satisfont le
prdicat p.
La projection (note ) : la projection S (r) est une relation de schma S obtenue partir de R en supprimant les
attributs qui ne sont pas dans S.
Le changement de nom (note ) : le changement de nom A:B R est une relation dans laquelle le nom de l'attribut
A est remplac par le nom B.
Le produit cartsien (not r x s) : le produit cartsien de deux relations r et s est une relation de schma R U S
obtenue en combinant les tuples de r et de s de toutes les manires possibles.
La jointure naturelle (note r s) est une relation de schma R U S obtenue en combinant les tuples de r et de
s ayant les mmes valeurs d'attributs sur R S, de toutes les manires possibles).
La jointure conditionnelle r [p]s = P (r x s)
Le quotient r/s est une relation de schma R \ S constitue des tuples t de [R\S](r) tels que pour tout t' de S, t.t'
appartient R.
On dnote de plus : l'union, l'intersection et la diffrence qui impliquent que les attributs entre les tables soient les
mmes.
Nous allons maintenant voir les multi-ensembles. Soit t un tuple figurant R fois dans r et S fois dans s :
avec l'union, r U s : le tuple t apparat R + S fois.
l'intersection : t figure min(R, S) fois dans r s.
la diffrence : t figure max( R S, 0) dans r s.
avec le produit cartsien : (t, u) figure R*S fois dans r x s. Remarque : pour le produit, cartsien, R et S n'ont pas
forcment les mmes attributs.
Voyons maintenant quelques lois de l'algbre relationnelle :
Optimisation des requtes :
Les slections diminuent le nombre de n-uplets et donc la taille des tables.
Les projection diminuent un peu la taille des tables.
Les produits et les jointures augmentent considrablement la taille des tables.
Commutativit, associativit :
la jointure et le produit cartsien sont associative et commutative
L'union et l'intersection sont associative et commutative, mais il n'y a pas de distributivit de U et avec les
multi-ensembles.
Lois avec la slection :
[C1ANDC2]R = [C1][C2](R)
[C](R U S) = [C]R U [C](S)
[C](R \ S) = [C]R \ S = [C]R \ [C]S
Si C ne concerne que R:
[C](R S) = ([C]R) S
[C](R S) = ([C]R)S
Si C ne concerne que les attributs communs:
[C](R S) = ([C]R) [C]S R et S ont mme attributs, C concerne forcment les attributs communs.
[C](R S) = ([C]R) [C]S
Lois avec la projection :
Si :
M (Attr (R) \ Attr (S))
N (Attr (S) \ Attr (R))
T = (Attr (R) Attr (S))

6
 KT
Alors
MKN(R S) = MKN( MTR TNS)
Si :
= (Attr (R) Attr (S))
M (Attr (R) \ Attr (S))
N (Attr (S) \ Attr (R))
Alors :
MN(R S) = ( MR NS)
Bases de donnes Quelques lois de lalgbre relationnelle

DATALOG
Datalog est un langage logique de requtes. On peut donc y exprimer des conditions (Si alors Sinon) couramment
utilises aujourd'hui. Datalog gre de plus les requtes non rcursives ( = algbre relationnelle) et rcursives (extension
ajoute SQL 99).
Prenons un premier exemple. Soit la base de donnes reprsente par le schma suivant :
Frquente (client, bar)
Aime (Client, bire)
Sert (Bar, Bire, Prix)
On cherche les clients heureux, c'est dire ceux qui frquentent un bar qui sert une bire qu'ils aiment. La requte se
structure alors de la manire suivante :
heureux (x) <- Frquente(x, bar) AND Aime (d, Bire) AND Sert (bar, bire, p)
Le sens d'une clause (rgle) s'interprte de la manire suivante : la tte est vraie s'il existe des valeurs des variables qui
rendent vraies les atomes du corps de la clause. Ainsi, la requte prcdente s'interprte de la manire suivante : x est
heureux s'il existe un bar et une bire et un prix tels que :
d frquente bar
d aime bire
bar sert bire au prix p.
Un atome est un prdicat ou une relation avec des variables ou des constantes comme arguments. Ainsi, la tte d'une
clause est un atome, le corps est une conjonction d'atomes. Sert (bar, bire, 3) est un atome ou le prdicat est le nom de
la relation et les arguments sont des variables ou des constantes.
Il existe des sous requtes (ou atomes) conditionnelles : c'est dire des atomes de comparaison utilisant des prdicats
prdfinis. On peut donc avoir toute les sortes de conditions usuelles (x > y, ou x <> y, ... par exemple)
Supposons, toujours avec le mme exemple, qu'une bire bon march est une bire vendue par au moins deux bars qui la
servent moins de 2.5. On peut chercher cette bire bon march par la requte Datalog suivante :
Bon_march (bire) <- Sert (bar1, bire, p1) AND Sert (bar2, bire, p2) AND p1 < 2.5 AND p2 < 2.5 AND
bar1<> bar2
Une sous requte peut tre ngative (prcde de NOT). Il faut alors vrifier la valeur de la requte. En effet, une
requte est correcte (ou sure) si toute variable apparat dans une sous requte non nie. Ainsi, les requtes (ou clauses)
suivantes sont incorrectes :
S(x) <- NOT R(x)
S(x) <- R(y) AND NOT R(x)
S(x) <- R(y) AND x < y
En effet, chaque fois, on peut avoir une infinit de valeurs pour x, mme si R est une relation finie.
De manire gnrale, pour valuer les rgles, on distingue deux approches :
instanciation des variables : on essaye toutes les valeurs possibles pour les variables des sous requtes, et si les
sous requtes sont valides, on ajoute le n-uplet
instanciation des n-uplets : on essaye tous les n-uplets possibles des atomes sans ngation, et si les sous requtes

7
 sont valides alors on ajoute le n-uplet.
L'instanciation des n-uplets se fait de la manire suivante :
commencer par les atomes relationnels non nis
considrer toutes les instanciations de leur n-uplets par des n-uplets pris dans les relations correspondantes
si les instanciations donnent des valeurs cohrentes aux variables et rendent toutes les sous requtes vraies, alors
ajouter la solution le n-uplet correspondant.
Un programme Datalog est une suite de clauses. Il existe alors deux types de prdicats :
EDB (Extensional DataBase) : table stocke
IDB (Intensional DataBase) : relation dfinie par les clauses
Une relation n'est donc jamais EDB et IDB. Il n'y a jamais de EDB dans les ttes de clauses.
On peut valuer les programmes Datalog en tenant compte des quelques rgles suivantes :
Si pas de rcursion : ordonner les clauses pour que le corps ne contienne que des prdicats dj dfinis et valus
Si un prdicat IDB est dfini par plus d'une clause, chaque clause ajoute des n-uplets au prdicat IDB
Sans rcursion, Datalog est quivalent l'algbre relationnelle, avec rcursion, Datalog sort de ce cadre.
Afin de mieux comprendre, nous allons maintenant voir le principe de rcursion avec Datalog. Il faut former un graphe
de dpendance des sommets (= prdicats IDB). L'arc X -> Y existe si et seulement si X est la tte d'une clause avec Y
dans le corps d'une autre clause. S'il y un cycle dans ce graphe, alors il y a rcursion.
Pour valuer les programmes rcursifs s'il n'y pas de ngation :
On suppose les IDB vides
Evaluer les clauses en utilisant les EDB et les n-uplets dj ajouts aux IDB
S'arrter quand le contenu du prdicat IDB est stationnaire
Il s'agit d'une valuation nave, une valuation semi-nave consiste :
Les EDB ne changent pas, chaque tour, on obtient un nouvel n-uplet dans un IDB que si l'on utilise un nouvel
n-uplet d'un IDB
Eviter de redcouvrir les mmes n-uplets (malgr cela, un mme n-uplet peut tre redcouvert!)
Evaluer un programme avec rcursion et ngation devient toutefois difficile. En effet, l'valuation nave ne fonctionne
plus si des sous requtes sont nies. En gnral, la ngation au sein d'un programme rcursif n'a pas de sens : mme
lorsque les rcursions et ngations sont indpendantes, les prdicats IDB peuvent tre mal dfinis.
Pour les programmes qui utiliseraient la fois la ngation et la rcursion, il faut alors utiliser une ngation stratifie. En
effet, la stratification est une contrainte habituellement requise en Datalog avec la ngation et la rcursion. La ngation
ne peut plus tre imbriqu dans la rcursion et on obtient alors les relations souhaites.
Intuitivement, la strate d'un prdicat IDB est le nombre maximal de ngations que l'on peut rencontrer durant son
valuation (ngation stratifie = strate finie) :
Dans P(x) <- Q(x) AND NOT P(x) on peut nier P une infinit de fois pour calculer P...
Les strates peuvent tre formalises par un graphe :
Sommets = prdicats IDB
Arc A -> B si et seulement si A dpend du prdicat B
Etiquette - sur l'arc A -> B si et seulement si B est ni dans la clause A <- ... B ...
Ainsi, la strate d'un sommet (prdicat IDB) est le chemin maximum d'arcs - sur un chemin partant de ce sommets. Un
programme Datalog est stratifi si tous les prdicats IDB ont une strate finie : c'est dire qu'il n'y a pas de cycle avec un
- .
Pour finir ce paragraphe concernant Datalog, nous allons voir les modles. Un modle est un choix de relations IDB qui,
avec des relations EDB donnes rend vraie toutes les clauses, quelles que soient les valeurs donnes aux variables :
Attention, si le corps de la clause est faux, alors la clause est vraie
Si le corps de la clause est vrai, la tte doit tre vraie.
On appelle modle minimal un modle tel que :
il n'y a pas de ngation : un programme Datalog a un unique modle minimal.
Avec la ngation : il peut y en avoir plusieurs
Le modle calcul avec la stratification est celui qui a un sens.

8
Lorsqu'on a un modle stratifi :
On value les prdicats IDB par ordre croissant de strate,
Ds qu'un prdicat IDB est valu, on le considre comme un prdicat EDB.

SQL
Le langage SQL est un langage de haut niveau qui vite de spcifier la manipulation des donnes comme il faudrait le
faire en C++ par exemple. SQL fonctionne grce des requtes trs efficacement optimises pour des rponses rapides.

Select From Where

La structure gnrale d'une requte est : Select 'attributs recherchs' From 'une ou plusieurs tables' Where 'conditions'.
SELECT : Les attributs recherchs correspondent au nom des attributs de la (les) table(s) (relations) :
* signifie que l'on souhaite rcuprer tous les attributs de la relation,
On peut aussi spcifier les noms d'attributs : par exemple : SELECT Nom, Prnom FROM Personne. Si la table
Personne (Nom, Prnom, Adresse), on ne rcupre donc ici que les noms et prnoms.
On peut renommer dans le Select le nom d'un attribut : SELECT Nom as Nom_Principal FROM Personne.
Avec le renommage, on peut alors utiliser toute expression calcule dans le Select : SELECT bire, prix * 120 as
PrixEnYen FROM Bires : la table Bires contient des bires avec leur prix en Euros. On slectionne les bires
en modifiant le prix pour l'afficher en Yen : on renomme alors l'attribut Prix en "PrixEnYen".
On peut indiquer une constante dans la slection : SELECT Nom, Prnom, "vit Bordeaux" as Vit_A_Bordeaux
FROM Personne WHERE Adresse = "Bordeaux" : on obtient alors une table 3 attributs (Nom, Prnom,
Vit_A_Bordeaux) affichant la liste des personnes vivant Bordeaux. Un n-uplet rsultat est donc (Durand, Paul,
vit Bordeaux).
WHERE : les conditions se composent ainsi :
On peut utiliser AND, OR, NOT et des parenthses
SQL ne distingue pas les majuscules et les minuscules
Une condition peut contenir des comparaisons d'une chaine de caractre : Attribut LIKE expression Attribut
NOT LIKE expression. Par exemple : SELECT Nom FROM Personne WHERE Numero LIKE "0556______"
va retrouver les personnes dont le numro de tlphone commence par 0556.

NULL et UNKNOWN
Les n-uplets des relations SQL peuvent avoir des composants indfinis (NULL). Le sens de la valeur NULL dpend du
conteste :
valeur inconnue : Personne dont on a pas l'adresse par exemple
inapplicable : le mtier d'un enfant
SQL utilise alors la logique trivalue : TRUE FALSE UNKNOWN : La comparaison entre une valeur et NULL
donne UNKNOWN. Un n-uplet est slectionn si le WHERE donne TRUE (et pas FALSE ni UNKNOWN). Nous
rappelons dans les tableaux ci-dessous les rsultats logiques de comparaisons :

AND TRUE UNKNOWN FALSE

TRUE TRUE UNKNOWN FALSE
UNKNOWN UNKNOWN UNKNOWN FALSE
FALSE FALSE FALSE FALSE

OR TRUE UNKNOWN FALSE

TRUE TRUE TRUE TRUE
UNKNOWN TRUE UNKNOWN UNKNOWN
FALSE TRUE UNKNOWN FALSE

Requtes plusieurs relations

Certaines requtes utilisent plusieurs relations (jointures). On peut mettre plusieurs relations dans le SELECT. Il faut

9
alors distinguer les attributs de mme nom appartenant des relations diffrentes : <relation>.<attribut>
Le sens des requtes ressemble alors au cas unaire : on fait le produit des relations du FROM et on slectionne les n-
uplets qui satisfont le WHERE. Ces n-uplets sont alors projets sur les attributs du SELECT.

Sous-requtes
Les oprateurs IN, ALL et ANY peuvent servir utiliser des sous-requtes. Une sous requte se construit exactement de
la mme manire qu'une requte classique. Ainsi, une expression parenthses SELECT-FROM-WHERE est une sous
requte qui peut tre utilis dans un FROM ou dans un WHERE.
L'oprateur IN s'utilise comme suit :
<n-uplet> IN <relation> vaut TRUE si et seulement si <n-uplet> appartient relation,
inversement avec <n-uplet> NOT IN <relation>
Le IN s'utilise de manire gnrale dans le WHERE et dans ce cas, <relation> est une sous requte.
L'oprateur EXISTS s'utilise comme suit :
EXISTS (<relation>) vaut TRUE si et seulement si <relation> n'est pas vide
NOT EXISTS (<relation>) : le contraire,
EXISTS apparat toujours dans un WHERE
L'oprateur ANY s'utilise comme suit :
x = ANY (<relation>) vaut TRUE si et seulement si au moins un n-uplet de <relation> est x.
Il en va de mme pour les autres styles de comparaisons, par exemple >= signifie que x est plus grand que l'un
des lments de <relation> (se qui prsuppose que le n-uplet x n'a qu'un seul attribut!)
L'oprateur ALL s'utilise comme suit :
x <> ALL (<relation>) vaut TRUE si et seulement si tous les lments de <relation> sont diffrents de x.
On peut, comme pour ANY, utiliser tout type de comparaisons.

Oprations multi-ensemblistes
L'union, l'intersection et la diffrence existent en SQL :
(sous-requte) UNION (sous-requte)
(sous-requte) INTERSECT (sous-requte)
(sous-requte) EXCEPT (sous-requte)
Remarque : par dfaut, SELECT-FROM-WHERE travaille avec les multi-ensembles. En revanche, UNION,
INTERSECT et EXCEPT fonctionne avec les ensembles : les doublons sont donc limins. Ce choix d'implmentation
de SQL existe pour des raisons d'efficacits. Les multi-ensembles sont plus pratiques pour la projection (attributs du
SELECT) et la slection (conditions du WHERE) car on procde n-uplet par n-uplet. A l'inverse, pour l'intersection et la
diffrence, il est plus efficace de trier d'abord et liminer ensuite, autant que possible, les doublons.
Pour supprimer les doublons dans SELECT-FROM-WHERE : utiliser l'oprateur DISTINCT aprs le SELECT. Par
exemple : SELECT DISTINCT Nom FROM Personne va slectionner de manire distinctes tous les noms de la table
Personne. Si plusieurs personnes portent le mme nom, ce nom n'apparait toutefois qu'une seule fois dans la rponse.
Inversement, pour retrouver les doublons dans les oprations multi-ensemblistes UNION, INTERSECT et EXCEPT, il
faut utiliser l'oprateur ALL aprs l'opration : ... UNION ALL ...

Jointures
En SQL on distingue 4 types de jointures. Ces jointures fonctionnent avec les multi-ensembles. Ces expressions peuvent
s'utiliser comme requtes ou dans une requte et les relations R et S peuvent tre des requetes entres parenthses :
jointure naturelle : R NATURAL JOIN S
jointure produit : R CROSS JOIN S
jointure conditionnelle R JOIN S ON <condition>
jointure externe : R OUTER JOIN S. Le noyau de la jointure externe peut tre modifi par des options
(NATURAL devant OUTER, ON, LEFT, RIGHT, FULL aprs OUTER) avec :
LEFT : accepte les n-uplets de R sans les n-uplets de S qui correspondent
RIGHT : accepte les n-uplets de S sans les n-uplets de R qui correspondent
FULL : option par dfaut, accepte les n-uplets de R et S qui ne correspondent pas aux n-uplets de l'autre
relation.

10
Oprateurs d'agrgation
Les agrgations :
SUM (somme), AVG(moyenne), COUNT, MIN, MAX s'utilisent sur une colonne du SELECT
COUNT(*) compte les n-uplets de la relation.
NULL n'intervient pas dans une somme, une moyenne, ... et n'est jamais un minimum ou maximum.
Le regroupement s'effectue avec GROUB BY et s'utilise de la manire suivante :
SELECT-FROM-WHERE peut tre suivi de GROUP BY et d'une liste d'attributs.
Le rsultat du SELECT-FROM-WHERE est regroup par valeur des attributs du GROUP BY. L'agrgation est alors
appliqu chaque groupe. Attention toutefois, il existe alors des restrictions sur le contenu de SELECT avec les
agrgations : tout lment du SELECT est soit un oprateur agrg par un oprateur d'agrgation, soit un attribut du
GROUP BY.
L'oprateur HAVING permet de spcifier des conditions sur le GROUP BY. Il s'utilise comme suit :
HAVING <condition>, la suite du GROUP BY
Il supprime les groupes qui ne satisfont pas la condition.

Modifications des tables

Il existe trois types de modifications sur les tables :
INSERT : insertion de n-uplet : INSERT INTO <relation> VALUES (<value_attribut1>, <value_attribut2>,...)
DELETE : destruction de n-uplets : DELETE FROM <relation> [WHERE <condition>]. S'il n'y a pas de
condition WHERE, tous les n-uplets de la relation sont supprims.
UPDATE : modification de n-uplets : UPDATE <relation> SET <listes d'instanciations d'attributs> WHERE
<condition sur le n-uplet>. Par exemple : UPDATE Personne SET Numro='0556050505' WHERE
Nom='Dupond' met jour le numro de tlphone de Dupond.

Dfinition d'un schma relationnel

La dfinition d'un schma relationnel en SQL consiste dclarer les relations (tables) de la base de donnes. Pour
dclarer une relation : CREATE TABLE <nom> (<liste d'lments>).
Les lments d'une table peuvent tre typs : INT ou INTEGER, REAL ou FLOAT, CHAR (n) chaine de n caractres,
VARCHAR (n) chaine de moins de n caractres, DATE (type SQL de la forme 'aaaa-mm-jj') et TIME ('hh:mm:ss').
Un attribut, ou une liste d'attributs peut tre dclar PRIMARY KEY ou UNIQUE. Cela signifie que ces attributs
dterminent les autres. Pour la dclaration d'une cl un seul attribut, il suffit d'crire UNIQUE ou PRIMARY KEY
aprs le type dans la dclaration de l'attribut. Par exemple, dans la table Beers si dessous, Name est la cl :
CREATE TABLE Beers (
Name CHAR(20) UNIQUE,
Price REAL
);
Lorsque la cl est consistue de plusieurs attributs, on la dfinit part la fin de la dclaration de la table :
CREATE TABLE Personne (
Nom CHAR(20),
Prnom CHAR(20),
Adresse CHAR(50),
Telephone CHAR(10)
PRIMARY KEY (Nom, Prnom)
);
La cl de Personne est alors le couple (Nom, Prnom).
Bien qu'il n'y ait pas vraiment de distinction entre PRIMARY KEY et UNIQUE dans le standard SQL, on remarque
quelques diffrences entre ces deux types :
Le SGBD peut crer un index pour PRIMARY KEY et pas pour UNIQUE
Il ne peut y avoir qu'une seule PRIMARY KEY pour une relation, mais plusieurs UNIQUE
Un attribut d'une PRIMARY KEY ne peut jamais valoir NULL. En revanche, un attribut UNIQUE peut valoir
NULL, et ce, mme pour plusieurs n-uplets.

11
On distinque enfin d'autres dclarations pour les attributs :
NOT NULL : attribut qui ne vaut jamais NULL,
DEFAULT <value> prcise la valeur par dfaut d'un attribut.
Pour terminer, on peut modifier une table :
Ajouter des attributs : ALTER TABLE <name> ADD <attribute_declaration> : ajoute la table <name> l'attribut
(la colonne) dfinit dans <attribute_declaration>. Par exemple ALTER TABLE Personne ADD age INTEGER
DEFAULT 0.
Supprimer un attribut : ALTER TABLE <name> DROP <attribute>. Par exemple ALTER TABLE Personne
DROP Adresse, supprime l'attribut adresse de la table Personne.

Vues
Une vue est une table virtuelle dfinie partie des autres tables et vues. Pour crer une vue, on utilise l'oprateur
CREATE VIEW. Par exemple CREATE VIEW <name> AS <requete>.
Une vue s'interroge ensuite comme une table. Le SGBD interprte la requte comme si la vue tait une table de base. Il
en fait une formule de l'algbre relationnelle dans laquelle intervient la vue C. Cette table C est remplac par sa
dfinition en algbre relationnelle.

Dpendances fonctionnelles
La proprit X -> A signifie que si deux n-uplets d'une relation R sont gaux sur X, alors ils sont gaux sur A. Si c'est le
cas, alors on dit que R satifait la dpendance fonctionnelle X -> A.
On peut avoir des dpendances fonctionnelles plusieurs attributs. Par exemple (dans la relation Personne) :
Nom -> Adresse, Telephone : est un raccourci pour dire que Nom -> Adresse et Nom -> Telephone
Nom, Adresse -> Prnom : est ici indispensable : Le Nom a lui seul ne permet pas de connaitre le prnom de la
personne (plusieurs personnes portant le mme nom). En y ajoutant l'Adresse, on connait la personne : celle qui
porte ce nom et qui vit cette adresse.
Soit K un attribut ou un ensemble d'attributs. K est une cl de la relation si et seulement si, pour tout attribut A de la
relation R on a K -> A.
K est une cl minimale si et seulement si K est une cl et aucun sous ensemble de K n'est cl.
Remarque : Les cls des schmas entits/associations portent sur les entits. Les cls des relations portent sur les n-
uplets. En principe, un n-uplet = une entit. Mais si le schma relationnel est mal conu, une entit correspond
plusieurs n-uplets. Donc, en principe, les deux notions diffrent.
On peut poser K comme tant une cl, et dans ce cas, les seules dpendances fonctionnelles sont K -> A pour tout
attribut A de la relation. Une autre mthode consiste poser les dpendances fonctionnelles et a en dduire les cls : le
modle entits/associations nous donne les dpendances fonctionnelles partir des entits et des relations.
L'analyse d'un problme nous donne des dpendances fonctionnelles de bon sens. Par exemple "jamais deux cours la
mme heure dans la mme salle" permet de dire que Heure, Salle -> Cours.

Dduire les dpendances fonctionnelles

Soit F un ensemble de dpendances fonctionnelles X1 -> A1, X2 -> A2, ..., Xn -> An. On se demande si la DF Y -> B est
consquence smantique de F, c'est dire Y -> B est satisfaite dans tout modle satisfaisant F (par exemple, si A -> B et
B -> C sont vraie, sans doute que A -> C aussi mme si on ne le dit pas).
Pour voir si Y -> B, on suppose que deux n-uplets sont gaux sur Y et on se demande s'ils sont alors gaux sur B. Il faut
alors utiliser les DF donnes pour en dduire que les n-uplets sont gaux sur d'autres attributs. Si B est l'un des attributs,
alors Y -> B est consquence. Sinon les 2 n-uplets avec les galits induites par les dpendances forment un exemple de
table pour R qui satisfait les DF de dpart et pas Y -> B qui n'est pas consquence.

Axiomes D'armstrong
Une dpendance fonctionnelle X -> Y est consquence d'un ensemble de dpendance fonctionnelle si et seulement si
elle s'obtient partir :
de F
des axiomes d'Armstrong

12
Les axiomes d'Armstrong :
X -> X' avec X' inclus dans X (rflexivit)
Si Z -> Z' alors ZW -> Z'W (augmentation)
Si X -> Y et Y -> Z alors X -> Z (transitivit)
Quelques consquences des axiomes d'Armstrong :
Si X -> Y et X -> Z alors X -> YZ
Si X -> Y et WY -> Z alors WX -> Z
Si X -> Y et Z inclus dans Y alors X -> Z
Si une dpendance fonctionnelle f s'obtient partir de F par les axiomes d'Armstrong, alors elle est consquence
smantique de F (tout modle satisfaisant F satisfait f). Si une DF f X -> Y est consquence smantique de F alors f se
dduit de F par les axiomes d'Armstrong. Supposons maintenant que X -> Y soit consquence smantique de F et pas
drivable.
Appelons X+ les attributs U tels que la dpendance X -> U est consquence de F par les axiomes d'Armstrong. X+
contient videmment X (rflexivit). Si X -> Y est consquence smantique de F, Y doit tre inclus dans X+ (sinon les n-
uplets diffreraient sur Y) et donc, pour chaque attribut A de Y, A est dans X+. On peut alors calculer la cloture d'un
ensemble d'attributs grce au programme suivant :
Initialisation : Y0 = Y
Induction : Yn+1 = Yn U {A / Z -> A et Z inclus dans Yn}
Arrt : lorsqu'il y a stabilit Yn = Yn+1

Cloture et couverture minimale

Soit F un ensemble de dpendances fonctionnelles. On note Cl(F) = { f / f consquence de F}. Deux ensembles F et G
de DF sont dits quivalents si Cl(F) = Cl(G).
Soit F un ensemble de DF. G est une couverture minimale de F si et seulement si Cl(F) = Cl(G), et :
Dans G, toute DF a un seul attribut droite
Pour toute DF f de G Cl(G f) <> Cl(G) = Cl(F)
Pour toute DF f = X -> A de G, pour tout Z inclus dans X : Cl( (G f) U g) <> Cl(G)
Pour voir s'il existe, et calculer une courverture minimale :
dcomposer les DF pour avoir un seul attribut droite
Supprimer les attributs en surnombre gauche
Supprimer les DF redondantes

Dpendances fonctionnelles induites

On recherche les DF induites dans un but de normalisation. Soit par exemple ABCD avec les DF AB -> C, C -> D et D
-> A. On dcompose ce schma en ABC et AD et on cherche les DF sur ABC. On doit trouver AB -> C mais aussi C ->
A.
L'ide consiste trouver toutes les DF non triviales consquences de F et se restreindre aux DF qui ne concernent que
des attributs d'une mme relation. Un algorithme simple mais exponentiel :
Pour chaque ensemble d'attribut X, calculer X+
Ajouter X -> A pour tout A dans X+ X,
Laisser de cot XY -> A si on dcouvre X -> A
Finalement, ne conserver que les DF qui ne concernent que les attributs d'une mme projection.
Une variante de cet algorithme :
Calculer toutes les consquences de F par les axiomes d'Armstrong
Ne conserver que les dpendances qui ne concernent que les attributs d'une mme projection
Quelques trucs :
Il est inutile de calculer la clture de tous les attributs et de l'ensemble vide...
Si X+ contient tous les attributs, il en va alors de mme pour tout X' contenant X.
Un algorithme plus efficace : soit R une relation et F un ensemble de DF sur R. R est dcompos en R1, ..., Rk. On pose
Gi = Cl(F) / Ri. Est ce que Cl (U Gi) = Cl(F)? Est ce qu'aprs la dcomposition on retrouve les mme dpendances
fonctionnelles? :

13
 Pour vrifier que X -> Y sera prserv
INIT Z := X
Tant que Z change
Pour chaque Ri faire Z:= Z U ((Z Ri)+/F Ri) - avec +/F = cloture par rapport F
A la fin Z vaut X+ par rapport G1 U ... U Gk.
Si Y dans Z alors X -> Y est prserve.

Formes normales
Un bon schma relationnel est un schma dans lequel il n'y pas de redondance et pas d'anomalies :
anomalies de mise jour : une occurrence d'une information est modifie et pas les autres
anomalies de suppressions : une information pertinente est perdue en dtruisant le n-uplet

Forme normale de Boyce Codd BCNF

Une relation R est dite en BCNF si et seulement si pour toute dpendance fonctionnelle non triviale (c'est dire X ne
contient pas A) X -> A sur les attributs de R, X est une cl (pas forcment minimale).
Dcomposition en BCNF :
Donne : une relation R avec des DF F.
Chercher les DF X -> B telles que X ne soit pas une cl (Si R n'est pas BCNF, il y en a au moins une)
Calculer X+ (qui ne contient pas tous les attributs, sinon X serait une cl)
Remplacer R par deux relations dont les attributs sont R1 = X+ et R2 = R (X+ X)
Projeter les DF sur ces schmas (attention : c'est la cloture de F, Cl(F), qu'on projte sur R1 et R2)

3eme Forme Normale 3NF

Certaines dpendances fonctionnelles posent problme lorsqu'on les dcompose : Soient les dpendances AB -> C et C
-> B, on distingue alors deux cls : AB et AC. Et la dpendances C -> B contredit la forme normale BCNF : il faudrait
dcomposer en AC et BC. Mais dans ce cas, on ne peut pas retrouver AB -> C.
La 3me forme normale (3NF) assouplit la condition de BCNF pour ne pas dcomposer dans ce cas. Un attribut est dit
"premier" s'il fait partie d'une cl minimale. Une relation n'est pas en 3NF si et seulement si on peut trouver une
dpendance fonctionnelle X -> A telle que X n'est pas une cl et A ne fait pas partie d'une cl minimale.

Dcomposition SPI (Sans Perte d'Information)

Soit la relation R(A1,,An). On dcompose R suivant X1,,Xk ensembles dattributs inclus dans {A1,,An}.
Soient :
Ri = Xi (R) pour 1 i k
(R)=R1 |X||X| Rk
Jointure note |X|,
a-t-on: R=(R) ?
Quelques proprits :
(R)=R1 |X||X| Rk R
Xi((R))=Ri
((R))=(R)
Soient par exemple la relation R(A, B, C, D, E) et les dpendances fonctionnelles A -> C, B - > C, C -> D, DE -> C et
CE -> A. On dcompose en X1 = AD, X2 = AB, X3 = BE, X4 = CDE et X5 = AE. On met en place le tableau suivant,
dans lequel les attributs d'une colonne sont gaux sur les ensembles Xi dans lesquels ils sont, et diffrents sur tous les
autres. On trouve pour l'exemple donn le tableau suivant :

A B C D E
X1 A1 B12 B13 A4 B15
X2 A1 A2 B23 B24 B25
X3 B31 A2 B33 B34 A5

14
 A B C D E
X4 B41 A2 B43 B44 A5
X5 A1 B52 B53 B54 A5

Il s'agit ensuite de forcer les galits jusqu' ce que les dpendances fonctionnelles soient vraies (voir Tds pour plus de
dtails sur cet algorithme). Si une ligne est de la forme A1, ..., An alors la dcomposition est SPI. Sinon, il y a perte
d'informations.
Si la ligne A1, ..., An n'apparait pas, on a une relation qui satisfait les dpendances fonctionnelles et A1, ..., An est dans la
jointure des projections, mais pas dans R.
Thorme de Heath : une dcomposition en X1 et X2 est SPI si et seulement si :
X1 X2 -> X1 X2 ou
X1 X2 -> X2 X1

Dcomposition en 3NF SPI et sans perte des dpendances fonctionnelles

Algorithme :
Calculer une couverture minimale
Crer une table par dpendance fonctionnelle + une par attribut isol (le rsultat est 3NF)
Si on veut une dcomposition SPI, il faut ajouter une table avec les attributs d'une cl minimale (dcoule du test
SPI)
Correction de la dcomposition :
Si les dpendances fonctionnelles sont prserve = OK
S'il y a un problme avec X -> A dans YB (de Y -> B) :
A = B : X n'est pas une cl strictement inclue dans Y, X -> A peut remplacer Y -> B (couverture non
minimale)
A <> B : soit Z une cl minimale de YB incluse dans Y, A n'est pas dans Z car A est premier et Z est cl de
YB. Z -> B et Z strictement inclus dans Y (couverture non minimale)

Dcomposition efficace en BCNF SPI

Quelques proprits :
Si on dcompose R en R1, ... Rk SPI et si on dcompose R1 en S1 et S2 SPI alors la dcomposition S1, S2, R2, ..., Rk
est SPI. (car la jointure est associative)
Tout schma deux attributs est BCNF. Si R n'est pas BCNF alors il existe des attributs A et B tels que (R AB)
-> A. La rciproque est fausse.
Si on projette un ensemble de dpendances fonctionnelles F (sa cloture) sur R1 inclus dans R et qu'on obtient G et
si on progette G (sa cloture) sur R2 inclus dans R1 alors on obtient la mme chose que si on projette F (sa cloture)
sur R2.
Algorithme de dcomposition en BCNF SPI (Soit Z le schma dcomposer.) :
INIT : Y := Z
Pour chaque paire d'attributs A B :
Si Y AB -> A faire Y:= Y B et C:=A
Si aucune paire ne marche ou si |Y| = 2, Y est BCNF
Dcomposer Z en Y et Z C.
Recommencer avec Z C.
Correction de l'algorithme :
Le schma extrait est BCNF (suivant la proprit 2 site plus haut). On dcompose Z en AX et Z A avec X -> A (pas
de perte par jointure d'aprs le thorme de Heath). La combinaison des dcompositions SPI est SPI (c.f. Proprit 1).
Les X+ sont calculs avec F (proprit 3).

Comparaison de 3NF et BCNF

Il y a deux proprits importantes des dcompositions :
Dcomposition SPI : Sans Perte d'Information : on peut projeter la relation de dpart sur chacune des

15
 composantes et reconstruire la relation de dpart.
Prservation des dpendances fonctionnelles : on peut vrifier dans les relations projetes que les dpendances
originales sont prserves.
On peut toujours mettre en BCNF sans perte d'information.
On peut toujours mettre en 3NF :
Sans perte d'information
En prservant les dpendances fonctionnelles
Par contre il n'y a pas toujours de forme BCNF sans perte d'information et sans perte de dpendances fonctionnelles.

Fiabilit reprise sur panne

La fiabilit est la capacit du systme SGBD remdier aux erreurs et pannes. Il peut s'agir d'erreurs dans les
programmes d'application, dans l'entre des donnes, d'enregistrement sur disques et crash matriel, catastrophes et
dfaillances du systme.
La fiabilit est donc la capacit restaurer la base de donnes dans un tat connu comme correct aprs une erreur
quelconque qui a amen la base de donnes dans un tat non correct.
L'objectif est d'viter que la base de donnes soit incohrente, et viter que les programmes donnent des rsulats faux.
Il existe diffrents types de pannes ou d'erreurs qui peuvent induire un tat incorrect de la base de donnes :
Erreurs dans l'entre des donnes : ces erreurs sont dtectables par les contraintes d'intgrits et par les triggers.
Mais ces erreurs peuvent tre indtectable si elles sont vraissemblable mais incorrectes (anne de naissance 1987
au lieu de 1978 par exemple)
Erreurs disques : on peut utiliser la dtection d'erreurs par l'utilisation de bits de parit pour vrifier les
enregistrements au niveau secteur. Les solutions proposes en cas de crash de la tte la lecture : RAID
"Redundant Arrays of Independant Disks" niveau 1 : mirroring, doublement des disques niveau 4 : un seul
disque miroir avec des bits de parit de tous les disques et du disque miroir niveau 5 : le disque miroir est
rparti. On utilise aussi l'archivage et/ou plusieurs bases de donnes avec duplications (copies multiples)
Catastrophes (incendie, inondation, explosion) entrainent une destruction des donnes. La seule solution consiste
en la redondance des donnes par archivage ou BD rparties avec duplication.
Dfaillance systme : les dfaillances systme sont des pannes ou erreurs qui entrainent la mauvaise excution
d'une transaction et donc amne la base de donnes tre incohrente. Ces dfaillances sont le plus souvent dues
des bugs, coupures de courant, erreurs logicielle. Elles entrainent des pertes ou altration du contenu de la
mmoire centrale et en particulier la perte de l'information sur les transactions en cours. Solution : journalisation,
procdure de reprise aprs panne.
Une transaction est une unit de programme excute sur un SGBD. Le dbut de la transaction demande l'accs la base
de donnes (lecture, criture) et effectue les calculs en mmoire centrale. A la fin de la transaction on effectue un
COMMIT (excution correcte, donc validation) ou un ROLLBACK (excution incorrecte, donc effacement).
Une transaction s'excute correctement s'il y a atomiti (+ cohrence, isolation et durabilit). Le gestionnaire de la
fiabilit doit s'assurer que cette atomicit est maintenue lors des pannes.
Le transfert des donnes d'une transaction vers le disque (et depuis le disque) de la base de donnes transite par des
buffers. Un SGBD utilise donc une unit de tranfert en entre/sortie (un bloc disque) qui est en fait un gestionnaire des
buffers. Ainsi, pour une base de donnes, il y a 3 espaces de stockages :
le disque (BD)
la zone de mmoire centrale (gre par le gestionnaire des buffers)
la zone de mmoire rserve pour la transaction

16
Oprations primitives :
input(x) : bloc contenant x -> mmoire
output(x) => bloc contenant x -> disque
read (x, t) : faire input(x) si ncessaire et t <- valeur de x
write (x, t) : faire input(x) si ncessaire t -> x (en mmoire)
Journal (Log) : le journal enregistre les actions de toutes les transactions. Le journal contient des articles de diffrents
types :
<START T> : dbut de la transaction T
<COMMIT T> : transaction T valide
<ABORT T> : transaction T annule
<T, X, v> : la transaction T mis jour l'lment X, v est l'ancienne valeur de X. <T, X, v> est gnr par un
WRITE
Les enregistrements sont en mmoire centrale comme les donnes de la BD et sont crits priodiquement sur le disque.
En cas de panne, LOG est utilis :
soit pour annuler des actions faites par transactions (UNDO)
soit pour refaire des actions faites par transactions (REDO)
soit pour annuler certaines actions et en refaire d'autres (UNDO/REDO)

Rgles de journalisation UNDO

Les rgles de journalisation UNDO consistent crire les mises jour dans le journal avant de modifier la base de
donnes et n'crire le COMMIT dans le journal qu'aprs l'criture sur le disque de toutes les mises jour de la
transaction (cet ordre s'applique individuellement pour chaque mise jour). Cela signifie que l'on doit (dans l'ordre) :
crire sur le disque les enregistrements LOG indiquant les lments de la BD changs
crire sur le disque les lments BD changs eux-mmes
crire l'enregistrement COMMIT du LOG sur le disque.
Ainsi, lorsqu'on a besoin de restaurer la base de donnes, il suffit d'examiner le fichier LOG (en remontant du plus
rcent au moins rcent) :
pour les transactions pour lesquelles existe un COMMIT : ne rien faire,
pour les autres transactions : dfaire chaque mise jour, rcrire l'ancienne valeur, crire un Abort T dans le
fichier LOG et faire FLUSH LOG (permet de forcer la copie du contenu du LOG de la mmoire centrale sur le
disque).
CheckPoint : A priori, en cas de reprise, on devrait remonter tout le fichier LOG, mais cela peut tre long. Une ide
consiste stabiliter le log priodiquement (criture d'un Chekpoint). Pour effectuer un Checkpoint :
ne plus accepter de nouvelles transactions
attendre la fin des transactions en cours et qu'elles aient crit un enregistrement COMMIT ou ABORT sur le
LOG
Flush Log
Ecrire un enregistrement <CKPT>
Flush Log
Recommencer accepter de nouvelles transactions
Ainsi, pour effectuer une reprise avec Checkpoint, il suffit d'examiner le fichier Log (en remontant) jusqu'
l'enregistrement <CKPT>. Les transactions avant le CKPT se sont termines correctement et leurs mises jour ont t
crites sur le disques. Les transactions aprs le CKPT doivent tre dfaites comme prcdemment.
Nonquiescent Checkpoint : il a pour but de ne pas ralentir le systme en refusant de nouvelles transactions. La mthode
Nonquiescent CheckPoint :
enregistre dans le fichier Log un enregistrement contenant la liste des transactions en cours <START CKPT
(T1, ..., Tn)>
Flush Log
Attendre la fin des transactions en cours, sans interdire le dmarrage de nouvelles transactions
Quand les transactions ont termin, crire un enregistrement <END CKPT>
Flush Log
Lors de la reprise, Si on rencontre un <END CKPT> alors on sait que toutes les transactions incompltes sont situes
aprs le dernier <START CKPT (...)>. Il n'est donc pas ncessaire de remonter au dela. Si on rencontre un <START

17
CKPT (T1, ...Tn)> alors la panne a eu lieu pendant le checkpoint. Les transactions incompltes sont celles rencontres
entre la panne et le <START CKPT (...)> et celles parmi T1, ..., Tn qui ne sont pas termines. On doit remonter jusqu'au
<START> de la plus vieille de ces transactions.

Rgles de journalisation REDO

L'inconvnient de la journalisation REDO est qu'on ne peut pas faire un COMMIT d'une transaction sans avoir crit
toutes les donnes modifies sur le disque (output). Or, il peut tre intressant de laisser les donnes en mmoire avant
d'aller les crire sur un disque. La journalisation REDO permet de ne pas crire immdiatement les mises jour sur les
disques. Ainsi :
UNDO dfait les transactions incompltes et ignore les transactions valides
REDO ignore les transactions incompltes et refait les transactions valides
UNDO crit les mises jour avant d'crire le COMMIT
REDO crit le COMMIT avant d'crire les mises jour
UNDO Log des mises jour avec anciennes valeurs
REDO Log des mises jour avec nouvelles valeurs
Les rgles de journalisation du REDO effectuent les mmes enregistrements que pour UNDO la diffrence que <T, X,
v> signifie "la transaction T crit la nouvelle valeur v pour X :
Avant de modifier une donne sur le disque, crire le <T, X, v> et le <COMMIT> dans le LOG. A la reprise :
identifier les transactions qui ont fait le COMMIT
Balayer le fichier LOG du dbut. Pour chaque ordre <T, X, v> :
Si T n'a pas fait le COMMIT : ignorer la mise jour (elle n'a pas t crite sur le disque)
Si T a fait un COMMIT : refaire la mise jour (crire la valeur v pour X)
Pour chaque transactions incomplte T, crire <ABORT T>, Flush LOG.
CheckPoint : Vu que le COMMIT est crit avant le OutPut, les mises jour faites par une transaction peuvent avoir t
copies sur disque bien aprs que le COMMIT ait eu lieu. Donc, le CheckPoint ne peut pas regarder que les transactions
actives qui sont valides ou non. Ainsi, qu'il soit Quiescent ou Nonquiescent, durant le CheckPoint, on doit forcer
l'criture sur disque des lments modifis par des transactions valides. Les tapes sont donc :
Ecrire <START CKPT (T1, T2, ...Tn)> ou les Ti sont les transactions actives non valides (pas de COMMIT)
Flush LOG
Ecrire sur le disque (vider les tampons) les mises jour des transactions valides (COMMIT) avant le
Checkpoint
Ecrire <END CKPT>
Flush LOG.
Ainsi, lors de la reprise sur panne :
Si la panne a eu lieu aprs <END CKPT> : on sait que les valeurs crites par transactions valides (COMMIT)
avant le <START CKPT (T1, ...Tn)> sont maintenant sur le disque. Les transactions Ti ou ayant commenc
aprs le START CKPT n'ont pas forcment leurs valeurs crites sur le disque mme si elles ont fait COMMIT
(on doit donc faire la reprise pour REDO de ces transactions : Si T n'a pas fait de COMMIT, ignorer la mise
jour, sinon, refaire la mise jour). On ne doit pas regarder plus haut dans le LOG que le plus vieux <START Ti>
ou Ti est une des T1, ... Tn ou ayant commenc aprs le <START CKPT>.
Si la panne a lieu aprs un <START CKPT (T1, ....Tn)> : on ne sait pas si les valeurs crites par les transactions
valides (COMMIT) avant sont sur le disque. On doit donc trouver le dernier enregistrement <END CKPT>,
trouver son <START CKPT (S1, ..., Sn)> ou qui font partie de S1, ..., Sn.

UNDO/REDO
Inconvnients de UNDO / REDO :
UNDO ncessite que les donnes soient crites sur disque avant que le COMMIT soit crit dans le journal, ce qui
entraine beaucoup de I/O.
REDO au contraire, demande ce que les donnes restent dans les buffers tant que la transaction n'est pas valide
et que le fichier LOG est crit. Le nombre de buffers est donc augment.
Pour amliorer les traitements, on utilise donc une mthode qui utilise la fois UNDO et REDO (journalisation
UNDO/REDO). Cette journalisation utilise les mmes enregistrements dans le LOG que UNDO et REDO. On y ajoute
cependant la rgle UPDATE <T, X, v, w> : la transaction T a chang la valeur de X. L'ancienne valeur tait v, la
nouvelle valeur est w.

18
La rgle d'criture dans le fichier LOG est donc : Avant de modifier un lment X de la BD sur le disque, il est
ncessaire qu'un enregistrement de mise jour <T, X, v, w> soit crit sur le disque. <COMMIT> peut tre prcis avant
ou aprs criture sur disque de X.
Lors de la reprise avec UNDO/REDO : on a les informations soit pour dfaire, soit pour refaire une mise jour :
Refaire toutes les transactions valides (en descendant dans le LOG)
Dfaire toutes les transactions non valides (en remontant dans le LOG)
Le Checkpoint avec UNDO/REDO consiste a :
crire <START CKPT (T1, ...Tn)> ou les Ti sont les transactions actives (pas de COMMIT)
Flush LOG,
Ecrire sur le disque (vider les tampons) les mises jour de toutes les transactions actives (valides ou non)
termines avant le Checkpoint.
Ecrire <END CKPT>
Flush LOG.

Reconstruire une base de donnes

Comment reconstruire une base de donnes aprs destruction du disque?
Le LOG restaure les mises jour aprs panne quand les donnes en mmoire sont perdues mais les donnes sur disque
ne sont pas perdues.
L'utilisation du LOG pour reconstruire une base de donnes implique qu'il faudrait conserver tout le LOG. Le LOG peut
tre conserv sur un autre disque que les donnes. Un LOG UNDO/REDO (pour avoir les nouvelles valeurs) est alors
ncessaire. Cette mthode n'est donc pas raliste car le LOG devient alors trs vite volumineux.
Une solution consiste donc archiver la base de donnes une date t. On peut alors reconstruire cette base de donnes
en utilisant cette archive et ventuellement le LOG depuis le moment de l'archivage pour avoir un tat plus avanc (t +
x).
Il existe diffrents niveaux d'archivage :
Full Dump
Incremental Dump
Mixte
Nonquiescent archive : on ne peut pas arrter la base de donnes pour faire l'archivage. Cependant, la copie de la base
de donnes est faite alors que des mises jour peuvent encore tre faites sur la BD. Pour restaurer, on a besoin de
l'archive et du LOG des transactions actives pendant l'archivage. Il faut donc utiliser un LOG UNDO/REDO ou REDO.
La mthode de cration de l'archive est donc :
Ecrire un enregistrement <START DUMP> sur le LOG
Faire un Checkpoint adapt la mthode de journalisation utilise (UNDO/REDO ou REDO)
Faire une copie (full dump ou incremental dump)
S'assurer que le fichier LOG est sauvegard sur un disque sr (au moins partir du Checkpoint inclus).
Ecrire un enregistrement <END DUMP> sur le LOG.
La reprise se fait donc de la manire suivante :
Reconstruire la BD partir de l'archive la plus rcente
Modifier la BD l'aide du LOG (utiliser la mthode de reprise correspondant au type de journalisation utilise).

Index et stockage des donnes

Voir le chapitre 10 des cours du CNAM.

19