Vous êtes sur la page 1sur 58

Conception de bases de donnes

La gestion des
transactions

http://bdd.crzt.fr

STPHANE CROZAT

Paternit - Partage des Conditions Initiales l'Identique :


http://creativecommons.org/licenses/by-sa/2.0/fr/

27 juillet 2014

Table des
matires
Introduction

I - Thorie : Transactions, fiabilit, concurrence

A. Principes des transactions..............................................................................7


1.
2.
3.
4.
5.

Problmatique des pannes et de la concurrence....................................................................7


Notion de transaction.........................................................................................................8
Droulement d'une transaction...........................................................................................8
Proprits ACID d'une transaction.......................................................................................8
Journal des transactions.....................................................................................................9

B. Manipulation de transactions en SQL...............................................................9


1.
2.
3.
4.
5.
6.
7.
8.
9.

Transactions en SQL..........................................................................................................9
Mini-TP : Transaction en SQL standard sous PostgreSQL.......................................................10
Exemple : Transaction sous Oracle en SQL.........................................................................10
Exemple : Transaction sous Oracle en PL/SQL.....................................................................11
Exemple : Transaction sous Access en VBA.........................................................................11
Mode Autocommit...........................................................................................................11
Exercice.........................................................................................................................12
Exercice.........................................................................................................................12
Exercice.........................................................................................................................12

C. Fiabilit et transactions................................................................................13
1.
2.
3.
4.
5.
6.
7.
8.
9.

Les pannes.....................................................................................................................13
Point de contrle.............................................................................................................14
Ecriture en avant du journal.............................................................................................14
Reprise aprs panne........................................................................................................14
Mini-TP : Simulation d'une panne sous PostgreSQL..............................................................16
Exemple : Transfert protg entre deux comptes................................................................16
Exercice.........................................................................................................................17
Super-hros sans tte......................................................................................................17
Complment : Algorithme de reprise UNDO-REDO...............................................................18

D. Concurrence et transactions.........................................................................20
1.
2.
3.
4.
5.
6.
7.
8.
9.

Stphane Crozat

Trois problmes soulevs par la concurrence......................................................................20


Le verrouillage................................................................................................................23
Le dverrouillage............................................................................................................24
Inter-blocage..................................................................................................................24
Mini-TP : Simulation d'accs concurrents sous PostgreSQL....................................................25
Solution aux trois problmes soulevs par la concurrence.....................................................26
Exercice.........................................................................................................................27
Exercice : Films en concurrence........................................................................................28
Complment : Protocole d'accs aux donnes.....................................................................30

Thorie : Transactions, fiabilit, concurrence

II - Application : Transactions

33

A. Opration bancaires et transactions...............................................................33

III - Test : Transactions

35

IV - Synthse : Les transactions

41

V - Bibliographie commente sur les transactions

43

Questions de synthse

45

Solution des exercices

49

Solution des exercices

57

Signification des abrviations

61

Bibliographie

63

Webographie

65

Index

67

Stphane Crozat

Introduction
Les transactions sont une rponse gnrale aux problmes de fiabilit et d'accs
concurrents dans les BD, et en particulier dans les BD en mode client-serveur. Elles sont le
fondement de toute implmentation robuste d'une BD. Un SGBDR ne fonctionne nativement
qu'en mode transactionnel.

Stphane Crozat

Thorie :
Transactions,
fiabilit,
concurrence
I-

Principes des transactions

Manipulation de transactions en SQL

10

Fiabilit et transactions

14

Concurrence et transactions

23

A. Principes des transactions


Objectifs
Comprendre les principes et l'intrt des transactions

1. Problmatique des pannes et de la concurrence


Une BD est un ensemble persistant de donnes organises qui a en charge la
prservation de la cohrence de ces donnes. Les donnes sont cohrentes si elles
respectent l'ensemble des contraintes d'intgrit spcifies pour ces donnes :
contraintes de domaine, intgrit rfrentielle, dpendances fonctionnelles...
La cohrence des donnes peut tre remise en cause par deux aspects de la vie
d'une BD :

La dfaillance
Lorsque le systme tombe en panne alors qu'un traitement est en cours, il y
a un risque qu'une partie seulement des instructions prvues soit excute,
ce qui peut conduire des incohrences. Par exemple pendant une mise
jour en cascade de cls trangres suite au changement d'une cl primaire.

La concurrence
Lorsque deux accs concurrents se font sur les donnes, il y a un risque que
l'un des deux accs rende l'autre incohrent. Par exemple si deux
utilisateurs en rseau modifient une donne au mme moment, seule une
des deux mises jour sera effectue.
Stphane Crozat

Thorie : Transactions, fiabilit, concurrence

La gestion de transactions par un SGBD est la base des mcanismes qui


permettent d'assurer le maintien de la cohrence des BD. C'est dire encore qu'il
assure que tous les contraintes de la BD seront toujours respectes, mme en cas
de panne et mme au cours d'accs concurrents.

2. Notion de transaction
Dfinition : Transaction
Une transaction est une unit logique de travail, c'est dire une squence
d'instructions, dont l'excution assure le passage de la BD d'un tat cohrent un
autre tat cohrent.

Fondamental : Cohrence des excutions incorrectes


La transaction assure le maintien de la cohrence des donnes que son excution
soit correcte ou incorrecte.

Exemple

: Exemples d'excutions incorrectes

L'excution d'une transaction peut tre incorrecte parce que :

Une panne a lieu

Un accs concurrent pose un problme

Le programme qui l'excute en a dcid ainsi

3. Droulement d'une transaction


1. DEBUT
2. TRAITEMENT
Accs aux donnes en lecture
Accs aux donnes en criture
3. FIN
Correcte : Validation des modifications
Incorrecte : Annulation des modifications

Fondamental
Tant qu'une transaction n'a pas t termine correctement, elle doit tre assimile
une tentative ou une mise jour virtuelle, elle reste incertaine. Une fois
termine correctement la transaction ne peut plus tre annule par aucun moyen.

4. Proprits ACID d'une transaction


Une transaction doit respecter quatre proprits fondamentales :

L'atomicit
Les transactions constituent l'unit logique de travail, toute la transaction
est excute ou bien rien du tout, mais jamais une partie seulement de la
transaction.

La cohrence
Les transactions prservent la cohrence de la BD, c'est dire qu'elle
transforme la BD d'un tat cohrent un autre (sans ncessairement que
les tats intermdiaires internes de la BD au cours de l'excution de la
transaction respectent cette cohrence)

Stphane Crozat

Thorie : Transactions, fiabilit, concurrence

L'isolation
Les transactions sont isoles les unes des autres, c'est dire que leur
excution est indpendante des autres transactions en cours. Elles accdent
donc la BD comme si elles taient seules s'excuter, avec comme
corollaire que les rsultats intermdiaires d'une transaction ne sont jamais
accessibles aux autres transactions.
La durabilit
Les transactions assurent que les modifications qu'elles induisent perdurent,
mme en cas de dfaillance du systme.

Remarque
Les initiales de Atomicit, Cohrence, Isolation et Durabilit forme le mot
mnmotechnique ACID.

5. Journal des transactions


Dfinition : Journal
Le journal est un fichier systme qui constitue un espace de stockage redondant
avec la BD. Il rpertorie l'ensemble des mises jour faites sur la BD (en
particulier les valeurs des enregistrements avant et aprs mise jour). Le journal
est donc un historique persistant (donc en mmoire secondaire) qui mmorise
tout ce qui se passe sur la BD.
Le journal est indispensable pour la validation (COMMIT), l'annulation (ROLLBACK)
et la reprise aprs panne de transactions.
Synonymes : Log

B. Manipulation de transactions en SQL


Objectifs
Connatre les syntaxes SQL standard, PostgreSQL, Oracle
et Access pour utiliser des transactions

1. Transactions en SQL
Introduction
Le langage SQL fournit trois instructions pour grer les transactions.

Syntaxe : Dbut d'une transaction


1

BEGIN TRANSACTION (ou BEGIN) ;

Cette syntaxe est optionnelle (voire inconnue de certains SGBD), une transaction
tant dbute de faon implicite ds qu'instruction est initie sur la BD.

Stphane Crozat

Thorie : Transactions, fiabilit, concurrence

Syntaxe : Fin correcte d'une transaction


1

COMMIT TRANSACTION (ou COMMIT) ;

Cette instruction SQL signale la fin d'une transaction couronne de succs. Elle
indique donc au gestionnaire de transaction que l'unit logique de travail s'est
termine dans un tat cohrent est que les donnes peuvent effectivement tre
modifies de faon durable.

Syntaxe : Fin incorrecte d'une transaction


1

ROLLBACK TRANSACTION (ou ROLLBACK) ;

Cette instruction SQL signale la fin d'une transaction pour laquelle quelque chose
s'est mal pass. Elle indique donc au gestionnaire de transaction que l'unit logique
de travail s'est termine dans un tat potentiellement incohrent et donc que les
donnes ne doivent pas tre modifies en annulant les modifications ralises au
cours de la transaction.

Remarque : Programme
Un programme est gnralement une squence de plusieurs transactions.

2. Mini-TP : Transaction en SQL standard sous


PostgreSQL
1. Se connecter une base de donnes : psql mydb
2. Crer une table test : CREATE TABLE test (a integer);

Question 1
1.
2.
3.
4.

[Solution n1 p 49]
Commencer une transaction : BEGIN TRANSACTION;
Insrer les deux valeurs 1 et 2 dans la table : INSERT INTO...
Valider la transaction : COMMIT
Vrifier que les valeurs sont bien dans la table : SELECT * FROM ...

Question 2
1.
2.
3.
4.

[Solution n2 p 49]
Commencer une transaction : BEGIN TRANSACTION;
Insrer les deux valeurs 3 et 4 dans la table : INSERT INTO...
Annuler la transaction : ROLLBACK
Vrifier que les valeurs ne sont pas dans la table : SELECT * FROM ...

3. Exemple : Transaction sous Oracle en SQL


Exemple
1
2
3

: Exemple en SQL sous Oracle

INSERT INTO test (a) VALUES (1);


COMMIT;

Attention : BEGIN implicite sous Oracle


La commande BEGIN; ou BEGIN TRANSACTION; ne peut pas tre utilis sous Oracle
(la commande BEGIN est rserve l'ouverture d'un bloc PL/SQL).

10

Stphane Crozat

Thorie : Transactions, fiabilit, concurrence

Toute commande SQL LMD (INSERT, UPDATE ou DELETE) dmarre par dfaut une
transaction, la commande BEGIN TRANSACTION est donc implicite.

4. Exemple : Transaction sous Oracle en PL/SQL


Exemple
1
2
3
4
5

: Exemple en PL/SQL sous Oracle

BEGIN
INSERT INTO test (a) VALUES (1);
COMMIT;
END;

5. Exemple : Transaction sous Access en VBA


Exemple
Access
1
2
3
4
5

: Exemple de transfert entre deux comptes en VBA sous

Sub MyTransaction
BeginTrans
CurrentDb.CreateQueryDef("", "INSERT INTO test (a) VALUES
(1)").Execute
CommitTrans
End Sub

Remarque : VBA et transactions


Sous Access, il n'est possible de dfinir des transactions sur plusieurs objets
requtes qu'en VBA.

6. Mode Autocommit
Attention : Autocommit
La plupart des clients et langages d'accs aux bases de donnes proposent un
mode autocommit permettant d'encapsuler chaque instruction dans une
transaction. Ce mode revient avoir un COMMIT implicite aprs chaque instruction.
Ce mode doit tre dsactiv pour permettre des transactions portant sur plusieurs
instructions.

Oracle

Sous Oracle SQL*Plus : SET AUTOCOMMIT ON et SET AUTOCOMMIT OFF

Sous Oracle SQL Developper : Menu Outils > Prfrences > Base de
donnes > Paramtres de feuille de calcul > Validation
automatique dans une feuille de calcul

PostgreSQL
Avec psql :

\set AUTOCOMMIT on

\set AUTOCOMMIT off


Si l'autocommit est activ, il est nanmoins possible de dmarrer une transaction
sur plusieurs lignes en excutant un BEGIN TRANSACTION explicite : BEGIN ; ... ;
Stphane Crozat

11

Thorie : Transactions, fiabilit, concurrence

COMMIT ;.
Ainsi deux modes sont possibles :

Autocommit activ : BEGIN explicites, COMMIT implicites

Autocommit dsactiv : BEGIN implicites, COMMIT explicites

Access
Sous Access, toute requte portant sur plusieurs lignes d'une table est encapsule
dans une transaction.
Ainsi par exemple la requte UPDATE Compte SET Solde=Solde*6,55957 est
excute dans une transaction et donc, soit toutes les lignes de la table Compte
seront mises jour, soit aucune (par exemple en cas de panne pendant .

7. Exercice
[Solution n1 p 57]

Quel est le rsultat de l'excution suivante sous Oracle ?


1
2
3
4
5
6
7
8
9
10
11

SET AUTOCOMMIT OFF


CREATE TABLE T1 (A INTEGER);
INSERT INTO T1 VALUES (1);
INSERT INTO T1 VALUES (2);
INSERT INTO T1 VALUES (3);
COMMIT;
INSERT INTO T1 (4);
INSERT INTO T1 (5);
ROLLBACK;
SELECT SUM(A) FROM T1

8. Exercice
[Solution n2 p 57]

Combien de lignes renvoie l'avant-dernire instruction SELECT ?


1
2
3
4
5
6
7
8

SET AUTOCOMMIT OFF


CREATE TABLE T1 (A INTEGER);
INSERT INTO T1 VALUES (1);
INSERT INTO T1 VALUES (1);
INSERT INTO T1 VALUES (1);
SELECT * FROM T1;
COMMIT;

9. Exercice
[Solution n3 p 57]

Combien de tables sont cres par cette srie d'instruction ?


1
2

12

SET AUTOCOMMIT OFF


CREATE TABLE T1 (A INTEGER);

Stphane Crozat

Thorie : Transactions, fiabilit, concurrence


3
4
5
6
7
8

CREATE TABLE T2 (A INTEGER);


CREATE TABLE T3 (A INTEGER);
INSERT INTO T1 VALUES (1);
INSERT INTO T2 VALUES (1);
INSERT INTO T3 VALUES (1);
ROLLBACK;

C. Fiabilit et transactions
Objectifs
Apprhender la gestion des pannes dans les SGBD.
Comprendre la rponse apporte par la gestion des
transactions.

1. Les pannes
Une BD est parfois soumise des dfaillances qui entranent une perturbation,
voire un arrt, de son fonctionnement.
On peut distinguer deux types de dfaillances :

Les dfaillances systme


ou dfaillances douces (soft crash), par exemple une coupure de courant ou
une panne rseau. Ces dfaillances affectent toutes les transactions en cours
de traitement, mais pas la BD au sens de son espace de stockage physique.

Les dfaillances des supports


ou dfaillances dures (hard crash), typiquement le disque dur sur lequel est
stocke la BD. Ces dfaillances affectent galement les transactions en cours
(par rupture des accs aux enregistrements de la BD), mais galement les
donnes elles-mmes.

Remarque : Annulation des transactions non termines


Lorsque le systme redmarre aprs une dfaillance, toutes les transactions qui
taient en cours d'excution (pas de COMMIT) au moment de la panne sont annuls
(ROLLBACK impos par le systme).
Cette annulation assure le retour un tat cohrent, en vertu des proprits
ACID des transactions.

Remarque : R-excution des transactions termines avec succs


Au moment de la panne certaines transactions taient peut-tre termines avec
succs (COMMIT) mais non encore (ou seulement partiellement) enregistres dans
la BD (en mmoire volatile, tampon, etc.). Lorsque le systme redmarre il doit
commencer par rejouer ces transactions, qui assurent un tat cohrent de la BD
plus avanc.
Cette reprise des transactions aprs COMMIT est indispensable dans la mesure o
c'est bien l'instruction COMMIT qui assure la fin de la transaction et donc la
durabilit. Sans cette gestion, toute transaction pourrait tre remise en cause.
Stphane Crozat

13

Thorie : Transactions, fiabilit, concurrence

Remarque : Unit de reprise


Les transactions sont des units de travail, et donc galement de reprise.

Remarque : Dfaillance des supports


Tandis que la gestion de transactions et de journal permet de grer les dfaillances
systmes, les dfaillances des supports ne pourront pas toujours tre grs par ces
seuls mcanismes.
Il faudra leur adjoindre des procdures de sauvegarde et de restauration de la BD
pour tre capable au pire de revenir dans un tat antrieur cohrent et au mieux de
rparer compltement la BD (cas de la rplication en temps rel par exemple).

2. Point de contrle
Dfinition : Point de contrle
Un point de contrle est une criture dans le journal positionne automatiquement
par le systme qui tablit la liste de toutes les transactions en cours (au moment o
le point de contrle est pos) et force la sauvegarde des donnes alors en mmoire
centrale dans la mmoire secondaire.
Le point de contrle est positionn intervalles de temps ou de nombre d'entres.
Le dernier point de contrle est le point de dpart d'une reprise aprs panne, dans
la mesure o c'est le dernier instant o toutes les donnes ont t sauvegardes en
mmoire non volatile.
Synonymes : Syncpoint

3. Ecriture en avant du journal


Fondamental
On remarquera que pour que la reprise de panne soit en mesure de rejouer les
transactions, la premire action que doit effectuer le systme au moment du
COMMIT est l'criture dans le journal de cette fin correcte de transaction. En effet
ainsi la transaction pourra tre rejoue, mme si elle n'a pas eu le temps de mettre
effectivement jour les donnes dans la BD, puisque le journal est en mmoire
secondaire.

4. Reprise aprs panne


Introduction
Le mcanisme de reprise aprs panne s'appuie sur le journal et en particulier sur
l'tat des transactions au moment de la panne et sur le dernier point de contrle.
Le schma ci-aprs illustre les cinq cas de figure possibles pour une transaction au
moment de la panne.

14

Stphane Crozat

Thorie : Transactions, fiabilit, concurrence

Image 1 tats d'une transaction au moment d'une panne

Transactions de type T1
Elles ont dbut et se sont termines avant tc. Elles n'interviennent pas
dans le processus de reprise.
Transactions de type T2
Elles ont dbut avant tc et se sont termines entre tc et tf. Elles devront
tre rejoues (il n'est pas sr que les donnes qu'elles manipulaient aient
t correctement inscrites en mmoire centrale, puisque aprs tc, or le
COMMIT impose la durabilit).
Transactions de type T3
Elles ont dbut avant tc, mais n'tait pas termines tf. Elles devront tre
annules (pas de COMMIT).
Transactions de type T4
Elles ont dbut aprs tc et se sont termines avant tf. Elles devront tre
rejoues.
Transactions de type T5
Elles ont dbut aprs tc et ne se sont pas termines. Elles devront tre
annules.

Remarque
Les transactions sont des units d'intgrit.

Stphane Crozat

15

Thorie : Transactions, fiabilit, concurrence

5. Mini-TP : Simulation d'une panne sous PostgreSQL


1. Se connecter une base de donnes : psql mydb
2. Crer une table test : CREATE TABLE test (a integer);

Question
1.
2.
3.
4.
5.

[Solution n3 p 49]
Commencer une transaction : BEGIN TRANSACTION;
Insrer les deux valeurs 1 et 2 dans la table : INSERT INTO...
Vrifier que les valeurs sont bien dans la table : SELECT * FROM ...
Simuler un crash en fermant le terminal : ROLLBACK du systme
Se reconnecter et vrifier que les valeurs ne sont plus dans la table :
SELECT * FROM ...

6. Exemple : Transfert protg entre deux comptes


Exemple : Transfert entre deux comptes en SQL standard sous
PostgreSQL
1
2
3
4
5

BEGIN;
UPDATE Compte1 SET Solde=Solde+100 WHERE Num=1;
UPDATE Compte2 SET Solde=Solde-100 WHERE Num=1;
COMMIT;
/

Exemple
1
2
3
4
5
6
7
8

CREATE OR REPLACE PROCEDURE myTransfC1C2


IS
BEGIN
UPDATE Compte1 SET Solde=Solde+100 WHERE Num=1;
UPDATE Compte2 SET Solde=Solde-100 WHERE Num=1;
COMMIT;
END;
/

Exemple
1
2
3
4
5
6

: Transfert entre deux comptes en PL/SQL sous Oracle

: Transfert entre deux comptes en VBA sous Access

Sub myTransfC1C2
BeginTrans
CurrentDb.CreateQueryDef("", "UPDATE Compte1 SET Solde=Solde+100
WHERE Num=1").Execute
CurrentDb.CreateQueryDef("", "UPDATE Compte2 SET Solde=Solde-100
WHERE Num=1").Execute
CommitTrans
End Sub

Fondamental : Transfert protg


Pour les trois exemples ci-avant le transfert est protg au sens o soit les deux
UPDATE seront excuts , soit aucun.
En cas de panne pendant la transaction, le transfert sera annul (ROLLBACK
systme), mais en aucun cas un des deux comptes ne pourra tre modifi sans que
l'autre le soit (ce qui aurait entran une perte ou un gain sur la somme des deux
comptes).

16

Stphane Crozat

Thorie : Transactions, fiabilit, concurrence

7. Exercice
[Solution n4 p 57]
Pour faire un transfert scuris d'un point de vue transactionnel de 100 du compte
bancaire C1 vers le compte bancaire C2 pour le compte numro 12, quelle est la
srie d'instructions correcte (en mode autocommit off)?

UPDATE C1 SET Solde=Solde-100 WHERE Numero=12;


ROLLBACK;
UPDATE C2 SET Solde=Solde+100 WHERE Numero=12;
COMMIT;
UPDATE C1 SET Solde=Solde-100 WHERE Numero=12
UPDATE C2 SET Solde=Solde+100 WHERE Numero=12
ROLLBACK;
UPDATE C1 SET Solde=Solde-100 WHERE Numero=12;
COMMIT;
UPDATE C2 SET Solde=Solde+100 WHERE Numero=12;
COMMIT;
UPDATE C1 SET Solde=Solde-100 WHERE Numero=12;
UPDATE C2 SET Solde=Solde+100 WHERE Numero=12;
COMMIT;
UPDATE C1 SET Solde=Solde-100 WHERE Numero=12;
ROLLBACK;
UPDATE C2 SET Solde=Solde-100 WHERE Numero=12;
ROLLBACK;

8. Super-hros sans tte


[10 minutes]
Les usines GARVEL construisent des figurines de super-hros partir des donnes
prsentes dans la base de donnes PostgreSQL de l'entreprise. Un gros problme
est survenu le mois dernier, lorsque l'usine en charge d'une nouvelle figurine,
Superchild, a livr un million d'exemplaires sans tte. l'analyse de la base il a en
effet t observ que la base contenait un tuple "Superchild" dans la table
Personnage, et cinq tuples associs dans la table Membre, deux pour les bras, deux
pour les jambes et un pour le torse, mais aucun pour la tte.
Le service qui a opr la saisie du nouveau personnage assure, sans ambigut
possible, que la tte a pourtant t saisie dans la base. En revanche, l'enqute
montre des instabilits de son rseau cette priode.
L'extrait du modle UML utile au problme est propos ci-aprs, ainsi que le code
SQL excut via le client psql lors de l'insertion de la nouvelle figurine.

Stphane Crozat

17

Thorie : Transactions, fiabilit, concurrence

Modle UML Figurines GARVEL (extrait)

1
2
3
4
5
6
7
8

\set AUTOCOMMIT on
INSERT INTO Personnage (designation, prix, identite_secrete, genre)
VALUES ('Superchild','12','Jordy','superhros') ;
INSERT INTO Membre (propritaire, nom, couleur) VALUES
('Superchild','bras droit','bleu') ;
INSERT INTO Membre (propritaire, nom, couleur) VALUES
('Superchild','bras gauche','bleu') ;
INSERT INTO Membre (propritaire, nom, couleur) VALUES
('Superchild','jambe gauche','bleu') ;
INSERT INTO Membre (propritaire, nom, couleur) VALUES
('Superchild','jambe droite','bleu') ;
INSERT INTO Membre (propritaire, nom, couleur) VALUES
('Superchild','torse','rouge') ;
INSERT INTO Membre (propritaire, nom, couleur) VALUES
('Superchild','tete','rose') ;

Question 1
[Solution n4 p 50]

Expliquer la nature du problme qui est probablement survenu. Proposer une


solution gnrale pour que le problme ne se renouvelle pas, en expliquant
pourquoi.
Soyez concis et prcis : La bonne mobilisation des concepts du domaine et la
clart de la rdaction seront apprcies.
Question 2
[Solution n5 p 50]

Illustrer la solution propose en corrigeant le code SQL de l'insertion de


"Superchild".

9. Complment : Algorithme de reprise UNDO-REDO


Introduction
L'algorithme suivant permet d'assurer une reprise aprs panne qui annule et rejoue
les transactions adquates.

18

Stphane Crozat

Thorie : Transactions, fiabilit, concurrence

1
2
3
4
5
6
7
8
9
10
11
12
13

1. SOIT deux listes


1a. Initialiser la
1b. Initialiser la
au dernier point de

REDO et UNDO
liste REDO vide
liste UNDO avec toutes les transactions en cours
contrle

2. FAIRE une recherche en avant dans le journal, partir du point de


contrle
2a. SI une transaction T est commence ALORS ajouter T UNDO
2b. SI une transaction T est termine avec succs alors dplacer T
de UNDO REDO
3. QUAND la fin du journal est atteinte
3a. Annuler les transactions de la liste UNDO (reprise en arrire)
3b. Rejouer les transactions de la liste REDO (reprise en avant)
4. TERMINER la reprise et redevenir disponible pour de nouvelles
instructions

Exemple

Image 2 tats d'une transaction au moment d'une panne

Stphane Crozat

Transactions de type T1
Non prises en compte par l'algorithme.
Transactions de type T2
Ajoutes la liste UNDO (tape 1b) puis dplace vers REDO (tape 2b)
puis rejoue (tape 3b).
Transactions de type T3
Ajoutes la liste UNDO (tape 1b) puis annule (tape 3a).

19

Thorie : Transactions, fiabilit, concurrence

Transactions de type T4
Ajoutes la liste UNDO (tape 2a) puis dplace vers REDO (tape 2b)
puis rejoue (tape 3b).
Transactions de type T5
Ajoutes la liste UNDO (tape 2a) puis annule (tape 3a).

* *
*

On voit que la gestion transactionnelle est un appui important la reprise sur


panne, en ce qu'elle assure des tats cohrents qui peuvent tre restaurs.

D. Concurrence et transactions
Objectifs
Apprhender la gestion de la concurrence dans les SGBD.
Comprendre la rponse apporte par la gestion des
transactions.

1. Trois problmes soulevs par la concurrence.


Introduction
Nous proposons ci-dessous trois problmes poss par les accs concurrents des
transactions aux donnes.

a) Perte de mise jour


T em ps

T rans ac tionA

T rans ac tionB

t1

LIRE T

t2

...

LIRE T

t3

UP DA TE T

...

t4

...

UP DA T E T

t5

CO M M IT

...

t4

CO M M IT

Tableau 1 Problme de la perte de mise jour du tuple T par la transaction A


Les transaction A et B accdent au mme tuple T ayant la mme valeur
respectivement t1 et t2. Ils modifient chacun la valeur de T. Les modifications
effectues par A seront perdues puisqu'elle avait lu T avant sa modification par B.

20

Stphane Crozat

Thorie : Transactions, fiabilit, concurrence

Exemple
T em ps
t1
t2
t3
t4
t5

A :A jouter100

B :A jouter10

LIRE CO M P T E
C= 1000
...

LIRE CO M P T E
C= 1000

UP DA TE CO M P T E
C= C+ 100= 1100

...

...

UP DA T E CO M P T E
C= C+ 10= 1010

CO M M IT
C= 1100

...
CO M M IT
C= 1010

t6

Tableau 2 Doucle crdit d'un compte bancaire C


Dans cet exemple le compte bancaire vaut 1010 la fin des deux transactions la
place de 1110.

b) Accs des donnes non valides


T em ps

T rans ac tionA

t1
t2
t3

T rans ac tionB
UP DA T E T

LIRE T

...
RO LLB A C K

Tableau 3 Problme de la lecture impropre du tuple T par la transaction A


La transaction A accde au tuple T qui a t modifi par la transaction B. B annule
sa modification et A a donc accd une valeur qui n'aurait jamais d exister
(virtuelle) de T. Pire A pourrait faire une mise jour de T aprs l'annulation par B,
cette mise jour inclurait la valeur avant annulation par B (et donc reviendrait
annuler l'annulation de B).

Stphane Crozat

21

Thorie : Transactions, fiabilit, concurrence

Exemple
T em ps

A :A jouter10

B :A jouter100(erreur)

t1

LIRE CO M P T E
C= 1000

t2

UP DA T E CO M P T E
C= C+ 100= 1100

t3
t4

LIRE CO M P T E
C= 1100

...

...

RO LLB A CK
C= 1000

t5

UP DA TE C
C= C+ 10= 1110

t6

CO M M IT
C= 1110

Tableau 4 Annulation de crdit sur le compte bancaire C


Dans cet exemple le compte bancaire vaut 1110 la fin des deux transactions la
place de 1010.

c) Lecture incohrente
T em ps

T rans ac tionA

T rans ac tionB

t1

LIRE T

t2

...

UP DA T E T

t3

...

CO M M IT

t4

LIRE T

Tableau 5 Problme de la lecture non reproductible du tuple T par la transaction A


Si au cours d'une mme transaction A accde deux fois la valeur d'un tuple alors
que ce dernier est, entre les deux, modifi par une autre transaction B, alors la
lecture de A est inconsistente. Ceci peut entraner des incohrences par exemple si
un calcul est en train d'tre fait sur des valeurs par ailleurs en train d'tre mises
jour par d'autres transactions.

Remarque
Le problme se pose bien que la transaction B ait t valide, il ne s'agit donc pas
du problme d'accs des donnes non valides.

22

Stphane Crozat

Thorie : Transactions, fiabilit, concurrence

Exemple
T em ps
t1

A :Calc uldeS = C1+ C2

B :T rans fertde10deC1 C2

LIRE CO M P T E 1
C1= 100
...

LIRE CO M P T E 1
C1= 100

...

LIRE CO M P T E 2
C2= 100

...

UP DA T E CO M P T E 1
C1= 10010= 90

...

UP DA T E CO M P T E 2
C2= 100+ 10= 110

t6

...

CO M M IT

t7

LIRE CO M P T E 2
C2= 110

t8

CA LCULS
S = C1+ C2= 210

t2
t3
t4
t5

Tableau 6 Transfert du compte C1 au compte C2 pendant une opration de calcul


C1+C2
Dans cet exemple la somme calcule vaut 210 la fin du calcul alors qu'elle devrait
valoir 200.

2. Le verrouillage
Introduction
Une solution gnrale la gestion de la concurrence est une technique trs simple
appele verrouillage.

Dfinition : Verrou
Poser un verrou sur un objet (typiquement un tuple) par une transaction signifie
rendre cet objet inaccessible aux autres transactions.
Synonymes : Lock

Dfinition : Verrou partag S


Un verrou partag, not S, est pos par une transaction lors d'un accs en lecture
sur cet objet.
Un verrou partag interdit aux autres transaction de poser un verrou exclusif sur
cet objet et donc d'y accder en criture.
Synonymes : Verrou de lecture, Shared lock, Read lock

Dfinition : Verrou exclusif X


Un verrou exclusif, not X, est pos par une transaction lors d'un accs en criture
sur cet objet.
Un verrou exclusif interdit aux autres transactions de poser tout autre verrou

Stphane Crozat

23

Thorie : Transactions, fiabilit, concurrence

(partag ou exclusif) sur cet objet et donc d'y accder (ni en lecture, ni en
criture).
Synonymes : Verrou d'criture, Exclusive lock, Write lock

Remarque : Verrous S multiples


Un mme objet peut tre verrouill de faon partage par plusieurs transactions en
mme temps. Il sera impossible de poser un verrou exclusif sur cet objet tant
qu'au moins une transaction disposera d'un verrou S sur cet objet.

Mthode
Soit la
1.
2.
3.
Soit la
1.
2.

: Rgles de verrouillage

transaction A voulant poser un verrou S sur un objet O


Si O n'est pas verrouill alors A peut poser un verrou S
Si O dispose dj d'un ou plusieurs verrous S alors A peut poser un verrou S
Si O dispose dj d'un verrou X alors A ne peut pas poser de verrou S
transaction A voulant poser un verrou X sur un objet O
Si O n'est pas verrouill alors A peut poser un verrou X
Si O dispose dj d'un ou plusieurs verrous S ou d'un verrou X alors A ne
peut pas poser de verrou X
V errouX prs ent

V errou(s )S prs ent(s )

P as dev errouprs ent

V errouX dem and

D em anderefus e

D em anderefus e

D em andeac c orde

V errouS dem and

D em anderefus e

D em andeac c ord e

D em andeac c orde

Tableau 7 Matrice des rgles de verrouillage

Remarque : Promotion d'un verrou


Une transaction qui dispose dj, elle-mme, d'un verrou S sur un objet peut
obtenir un verrou X sur cet objet si aucune autre transaction ne dtient de verrou S
sur l'objet. Le verrou est alors promu du statut partag au statut exclusif.

3. Le dverrouillage
Dfinition : Dverrouillage
Lorsqu'une transaction se termine (COMMIT ou ROLLBACK) elle libre tous les
verrous qu'elle a pos.
Synonymes : Unlock

4. Inter-blocage
Dfinition : Inter-blocage
L'inter-blocage est le phnomne qui apparat quand deux transactions (ou plus,
mais gnralement deux) se bloquent mutuellement par des verrous poss sur les
donnes. Ces verrous empchent chacune des transactions de se terminer et donc
de librer les verrous qui bloquent l'autre transaction. Un processus d'attente sans
fin s'enclenche alors.
Les situations d'inter-blocage sont dtectes par les SGBD et gres, en annulant
l'une, l'autre ou les deux transactions, par un ROLLBACK systme. Les mthodes
utilises sont la dtection de cycle dans un graphe d'attente et la dtection de dlai
d'attente trop long.

24

Stphane Crozat

Thorie : Transactions, fiabilit, concurrence

Synonymes : Deadlock, Blocage, Verrou mortel

Dfinition : Cycle dans un graphe d'attente


Principe de dtection d'un inter-blocage par dtection d'un cycle dans un graphe
reprsentant quelles transactions sont en attente de quelles transactions (par
infrence sur les verrous poss et les verrous causes d'attente). Un cycle est
l'expression du fait qu'une transaction A est en attente d'une transaction B qui est
en attente d'une transaction A.
La dtection d'un tel cycle permet de choisir une victime, c'est dire une des deux
transactions qui sera annule pour que l'autre puisse se terminer.
Synonymes : Circuit de blocage

Dfinition : Dlai d'attente


Principe de dcision qu'une transaction doit tre abandonne (ROLLBACK) lorsque
son dlai d'attente est trop long.
Ce principe permet d'viter les situations d'inter-blocage, en annulant une des deux
transactions en cause, et en permettant donc l'autre de se terminer.
Synonymes : Timeout

Remarque : Risque li l'annulation sur dlai


Si le dlai est trop court, il y a un risque d'annuler des transactions en situation
d'attente longue, mais non bloques.
Si le dlai est trop long, il y a un risque de chute des performances en situation
d'inter-blocage (le temps que le systme ragisse).
La dtection de cycle est plus adapte dans tous les cas, mais plus complexe
mettre en uvre.

Remarque : Relance automatique


Une transaction ayant t annule suite un inter-blocage (dtection de cycle ou
de dlai d'attente) n'a pas commis de "faute" justifiant son annulation. Cette
dernire est juste due aux contraintes de la gestion de la concurrence. Aussi elle
n'aurait pas d tre annule et devra donc tre excute nouveau.
Certains SGBD se charge de relancer automatiquement les transactions ainsi
annules.

5. Mini-TP : Simulation d'accs concurrents sous


PostgreSQL
1. Se connecter deux fois une mme base de donnes dans deux terminaux
(term1 et term2) :
psql mydb
psql mydb
2. Crer une table test : CREATE TABLE test (a integer);

Question 1
[Solution n6 p 51]
1. term1 Insrer une valeur : INSERT ... (COMMIT implicite)
2. term2 Vrifier que la valeur est visible : SELECT ...

Stphane Crozat

25

Thorie : Transactions, fiabilit, concurrence

Question 2
1.
2.
3.
4.
5.
6.

term1
term1
term1
term2
term1
term2

[Solution n7 p 51]
Commencer une transaction : BEGIN TRANSACTION;
Insrer la valeur 2 dans la table : INSERT INTO...
Vrifier que la valeur est bien dans la table : SELECT * FROM ...
Vrifier que la valeur n'est pas visible : SELECT * FROM ...
Valider la transaction : COMMIT;
Vrifier que la valeur est visible : SELECT * FROM ...

Question 3
[Solution n8 p 52]
1. term1 Commencer une transaction : BEGIN TRANSACTION;
2. term1 Excuter une mise jour (multiplier toutes les valeurs par 2) :
UPDATE...
3. term2 Excuter une mise jour concurrente (multiplier les valeurs par 3) :
UPDATE...
4. term2 Observer la mise en attente
5. term1 Valider la transaction : COMMIT;
6. term2 Vrifier le dblocage et que les deux mises jour ont bien t
effectues (a multipli par 6) : SELECT...
7. term1 Vrifier que les deux mises jour ont bien t effectues (a multipli
par 6) : SELECT...

6. Solution aux trois problmes soulevs par la


concurrence.
Introduction
Le principe du verrouillage permet d'apporter une solution aux trois problmes
classiques soulevs par les accs aux concurrents aux donnes par les transactions.

a) Perte de mise jour


T em ps
t1

T rans ac tionA

T rans ac tionB

LIRE T
V errouS
...

LIRE T
V errouS

t3

U P DA T E T
A ttente...

...

t4

...
A ttente...

UP DA T E T
A ttente...

...

Interbloc age

t2

Tableau 8 Problme de la perte de mise jour du tuple T par la transaction A

Remarque
Le problme de perte de mise jour est rgl, mais soulve ici un autre problme,
celui de l'inter-blocage.

26

Stphane Crozat

Thorie : Transactions, fiabilit, concurrence

b) Accs des donnes non valides


T em ps

T rans ac tionA

UP DA T E T
V errouX

t1
t2

LIRE T
A ttente...

...
RO LLB A C K
Librationduv errouX

t3
t4

T rans ac tionB

V errouS

Tableau 9 Problme de la lecture impropre du tuple T par la transaction A

c) Lecture incohrente
T em ps
t1

T rans ac tionA

T rans ac tionB

LIRE T
V errouS
...

UP DA T E T
A ttente...

t3

LIRE T
V errous S

...

...

...librationdes v errous ...

...repris edelatrans ac tion...

t2

Tableau 10 Problme de la lecture non reproductible du tuple T par la transaction A

Remarque
La lecture reste cohrente car aucune mise jour ne peut intervenir pendant le
processus de lecture d'une mme transaction.

7. Exercice
[Solution n5 p 58]
Soit l'excution concurrente des deux transactions ci-dessous (on pose qu'aucune
autre transaction ne s'excute par ailleurs).
NB : Le tableau fait tat des temps auxquels les instructions sont soumises au
serveur et non auxquels elles sont traites.

Stphane Crozat

27

Thorie : Transactions, fiabilit, concurrence

T em ps

T rans ac tion1

t0

T rans ac tion2
B E G INT RA NS A CT IO N

t1

B E G INT RA NS A CT IO N

t2

UP DA TE T A B LE 1S E T
T A B LE 1.A = T A B LE 1.A + 1
UP DA T E T A B LE 1S E T
T A B LE 1.A = TA B LE 1.A + 1

t3
t4

UP DA TE T A B LE 1S E T
T A B LE 1.A = T A B LE 1.A + 1

t5

CO M M IT

t6

Tableau 11 Transactions concurrentes


De combien le champ TABLE1.A a-t-il t augment t6 du point de vue de la
transaction 2 ?
NB : Si vous pensez que le rsultat ne peut tre dtermin cause d'une perte de
mise jour ou d'un inter-blocage, rpondez 0.

8. Exercice : Films en concurrence


[Solution n6 p 58]

Soit la table Film suivante dfinie en relationnel permettant d'enregistrer le nombre


d'entres des films identifis par leur ISAN.
1

28

Film(#isan:char(33),entrees:integer)

Stphane Crozat

Thorie : Transactions, fiabilit, concurrence

Soit l'excution concurrente de deux transactions TR1 et TR2 visant ajouter


chacune une entre au film '123' :
Temps
t0

Transaction TR1
BEGIN

t1

t2

Transaction TR2

BEGIN

UPDATE Film SET


entrees=entrees+1
WHERE isan='123'

t3

t4

UPDATE Film SET


entrees=entrees+1
WHERE isan='123'

t5

t6

COMMIT

t7

t8

COMMIT

Tableau 12 Transaction parallles TR1 et TR2 sous PostgreSQL


NB :

Les instructions sont reportes au moment o elles sont transmises au


serveur
Aucune autre transaction n'est en cours d'excution entre t0 et t8.

Exercice
De combien les entres du film 123 ont-t-elles t augmentes t3 du point de
vue de la transaction TR1 ?

Exercice

Stphane Crozat

29

Thorie : Transactions, fiabilit, concurrence

De combien les entres du film 123 ont-t-elles t augmentes t3 du point de


vue de la transaction TR2 ?

Exercice
De combien les entres du film 123 ont-t-elles t augmentes t5 du point de
vue de la transaction TR1 ?

Exercice
De combien les entres du film 123 ont-t-elles t augmentes t5 du point de
vue de la transaction TR2 ?

Exercice
De combien les entres du film 123 ont-t-elles t augmentes t7 du point de
vue de la transaction TR1 ?

Exercice
De combien les entres du film 123 ont-t-elles t augmentes t7 du point de
vue de la transaction TR2 ?

9. Complment : Protocole d'accs aux donnes.


Mthode : Rgles de verrouillage avant les lectures et critures
des donnes
Soit la
1.
2.
3.
Soit la
1.
2.
3.

30

transaction A voulant lire des donnes d'un tuple T :


A demande poser un verrou S sur T
Si A obtient de poser le verrou alors A lit T
Sinon A attend le droit de poser son verrou (et donc que les verrous qui l'en
empchent soient levs)
transaction A voulant crire des donnes d'un tuple T :
A demande poser un verrou X sur T
Si A obtient de poser le verrou alors A crit T
Sinon A attend le droit de poser son verrou (et donc que les verrous qui l'en
empchent soient levs)

Stphane Crozat

Thorie : Transactions, fiabilit, concurrence

Soit la transaction A se terminant (COMMIT ou ROLLBACK) :


1. A libre tous les verrous qu'elle avait pos
2. Certaines transactions en attente obtiennent ventuellement le droit de
poser des verrous

Remarque : Liste d'attente


Afin de rationaliser les attentes des transactions, des stratgies du type FIFO sont
gnralement appliques et donc les transactions sont empiles selon leur ordre de
demande.

Stphane Crozat

31

Application :
Transactions
II -

Opration bancaires et transactions

II
37

A. Opration bancaires et transactions


[1 heure]
On dsire ralisation une BD permettant de grer les comptes bancaires des
clients selon les modalits suivantes :

Chaque client possde un compte courant et ventuellement un compte


d'pargne.

Un compte est identifi par un numro unique compos d'un numro de


pays, d'un numro de ville (relatif au pays), d'un numro d'agence (relatif
la ville), et d'un numro propre (fourni par l'agence). A des fins
d'identification du compte par un oprateur humain, on gardera dans la BD
un intitul pour les pays, villes et agences.

Il est possible de faire des transferts d'un compte sur l'autre

Il est possible de dbiter (enlever) de l'argent depuis le compte courant

Il est possible de crditer (ajouter) de l'argent sur les deux comptes

Les comptes doivent toujours tre positifs

On ne garde pas la mmoire des oprations, seules les soldes sur les
comptes sont grs

Un client est dcrit par son nom, son prnom, sa civilit.


Question 1
[Solution n9 p 53]

Raliser la conception complte de la BD


Indice :
La conception complte signifie le MCD, le MLD et et le code SQL de cration de
l'implmentation physique.
Question 2
[Solution n10 p 54]

Soient les vnements suivants survenant sur la BD :

Le client Robert Dupont est cr dans l'agence du centre ville de Compigne,


qui vient d'ouvrir.

Le client Alphonse Durand est cr dans la mme agence, mais il veut


galement un compte d'pargne sur lequel il dpose tout de suite 1000
Stphane Crozat

33

Application : Transactions

Le client Robert Dupont dpose deux chques de 100 sur son compte
courant.

Le client Alphonse Durand transfre 500 de son compte d'pargne son


compte courant.
crire le code SQL permettant de traiter ces vnements, sans utiliser de
transactions
Suite des problmes de coupure rseaux, on constate des problmes sur les
comptes. Ainsi suite l'excution des oprations prcdentes, la requte suivante
renvoie des rsultats errons.

1
2
3

SELECT tCompteCourant.fkClient AS N, tCompteCourant.aSolde +


NVL(tCompteEpargne.aSolde,0) AS SoldeDeTousComptes
FROM tCompteCourant LEFT JOIN TCompteEpargne
ON tCompteCourant.fkClient=TCompteEpargne.fkClient ;

SoldeDeTousComptes

100

500
Tableau 13 Rsultat retourn

Question 3
[Solution n11 p 55]

Expliquer quoi peuvent tre dus les problmes rencontrs.


Indice :
La fonction NVL renvoie comme valeur le second paramtre, si le premier pour
valeur NULL.
Question 4
[Solution n12 p 55]

Proposer une solution permettant d'assurer la cohrence des oprations, en


amnageant cotre code SQL.

34

Stphane Crozat

Test :
Transactions
III -

III

Exercice 1 : Films en concurrence


[Solution n6 p 58]
Soit la table Film suivante dfinie en relationnel permettant d'enregistrer le nombre
d'entres des films identifis par leur ISAN.
1

Stphane Crozat

Film(#isan:char(33),entrees:integer)

35

Test : Transactions

Soit l'excution concurrente de deux transactions TR1 et TR2 visant ajouter


chacune une entre au film '123' :
Temps
t0

Transaction TR1
BEGIN

t1

t2

Transaction TR2

BEGIN

UPDATE Film SET


entrees=entrees+1
WHERE isan='123'

t3

t4

UPDATE Film SET


entrees=entrees+1
WHERE isan='123'

t5

t6

COMMIT

t7

t8

COMMIT

Tableau 14 Transaction parallles TR1 et TR2 sous PostgreSQL


NB :

Les instructions sont reportes au moment o elles sont transmises au


serveur
Aucune autre transaction n'est en cours d'excution entre t0 et t8.

Exercice
De combien les entres du film 123 ont-t-elles t augmentes t3 du point de
vue de la transaction TR1 ?

Exercice

36

Stphane Crozat

Test : Transactions

De combien les entres du film 123 ont-t-elles t augmentes t3 du point de


vue de la transaction TR2 ?

Exercice
De combien les entres du film 123 ont-t-elles t augmentes t5 du point de
vue de la transaction TR1 ?

Exercice
De combien les entres du film 123 ont-t-elles t augmentes t5 du point de
vue de la transaction TR2 ?

Exercice
De combien les entres du film 123 ont-t-elles t augmentes t7 du point de
vue de la transaction TR1 ?

Exercice
De combien les entres du film 123 ont-t-elles t augmentes t7 du point de
vue de la transaction TR2 ?

Exercice 2
[Solution n1 p 57]

Quel est le rsultat de l'excution suivante sous Oracle ?


1
2
3
4
5
6
7
8
9
10
11

Stphane Crozat

SET AUTOCOMMIT OFF


CREATE TABLE T1 (A INTEGER);
INSERT INTO T1 VALUES (1);
INSERT INTO T1 VALUES (2);
INSERT INTO T1 VALUES (3);
COMMIT;
INSERT INTO T1 (4);
INSERT INTO T1 (5);
ROLLBACK;
SELECT SUM(A) FROM T1

37

Test : Transactions

Exercice 3
[Solution n2 p 57]

Combien de lignes renvoie l'avant-dernire instruction SELECT ?


1
2
3
4
5
6
7
8

SET AUTOCOMMIT OFF


CREATE TABLE T1 (A INTEGER);
INSERT INTO T1 VALUES (1);
INSERT INTO T1 VALUES (1);
INSERT INTO T1 VALUES (1);
SELECT * FROM T1;
COMMIT;

Exercice 4
[Solution n3 p 57]

Combien de tables sont cres par cette srie d'instruction ?


1
2
3
4
5
6
7
8

SET AUTOCOMMIT OFF


CREATE TABLE T1 (A INTEGER);
CREATE TABLE T2 (A INTEGER);
CREATE TABLE T3 (A INTEGER);
INSERT INTO T1 VALUES (1);
INSERT INTO T2 VALUES (1);
INSERT INTO T3 VALUES (1);
ROLLBACK;

Exercice 5
[Solution n4 p 57]

Pour faire un transfert scuris d'un point de vue transactionnel de 100 du compte
bancaire C1 vers le compte bancaire C2 pour le compte numro 12, quelle est la
srie d'instructions correcte (en mode autocommit off)?

38

Stphane Crozat

Test : Transactions

UPDATE C1 SET Solde=Solde-100 WHERE Numero=12;


ROLLBACK;
UPDATE C2 SET Solde=Solde+100 WHERE Numero=12;
COMMIT;
UPDATE C1 SET Solde=Solde-100 WHERE Numero=12
UPDATE C2 SET Solde=Solde+100 WHERE Numero=12
ROLLBACK;
UPDATE C1 SET Solde=Solde-100 WHERE Numero=12;
COMMIT;
UPDATE C2 SET Solde=Solde+100 WHERE Numero=12;
COMMIT;
UPDATE C1 SET Solde=Solde-100 WHERE Numero=12;
UPDATE C2 SET Solde=Solde+100 WHERE Numero=12;
COMMIT;
UPDATE C1 SET Solde=Solde-100 WHERE Numero=12;
ROLLBACK;
UPDATE C2 SET Solde=Solde-100 WHERE Numero=12;
ROLLBACK;

Exercice 6
[Solution n5 p 58]

Soit l'excution concurrente des deux transactions ci-dessous (on pose qu'aucune
autre transaction ne s'excute par ailleurs).
NB : Le tableau fait tat des temps auxquels les instructions sont soumises au
serveur et non auxquels elles sont traites.
T em ps

T rans ac tion1

t0
t1

B E G INTRA NS A CT IO N

t2

UP DA TE T A B LE 1S E T
T A B LE 1.A = T A B LE 1.A + 1
UP DA T E T A B LE 1S E T
T A B LE 1.A = T A B LE 1.A + 1

t3
t4

UP DA TE T A B LE 1S E T
T A B LE 1.A = T A B LE 1.A + 1

t5

CO M M IT

t6

T rans ac tion2
B E G INT RA NS A CT IO N

Tableau 15 Transactions concurrentes


De combien le champ TABLE1.A a-t-il t augment t6 du point de vue de la
transaction 2 ?
NB : Si vous pensez que le rsultat ne peut tre dtermin cause d'une perte de
mise jour ou d'un inter-blocage, rpondez 0.

Stphane Crozat

39

Test : Transactions

Exercice 7
[Solution n7 p 59]
Quelle valeur renvoie le code suivant sous Oracle ? (notez ERREUR si le code
renvoie une erreur).
1
2
3
4
5
6
7
8

40

set autocommit off


create table t (a integer);
insert into t values (1);
rollback;
insert into t values (2);
commit;
select sum(a) from t;

Stphane Crozat

Synthse : Les
transactions
IV -

IV

Transaction
Unit logique de travail pour assurer la cohrence de la BD mme en cas de pannes
ou d'accs concurrents.

Panne
Mme en cas de panne, la BD doit rester cohrente.
Dfaillances systme
Coupure de courant, de rseau, etc.
Dfaillances du support
Crash disque (dans ce cas les transactions peuvent tre insuffisantes).

Concurrence
Dimension relevant de la conception d'application.
Perte de mise jour
Accs des donnes non valides
Lecture incohrente

Programmation
Un programme peut dcider de l'annulation d'une transaction.
ROLLBACK
Instruction SQL d'annulation d'une transaction.

Stphane Crozat

41

Bibliographie
commente sur
les transactions
V-

Stphane Crozat

43

Bibliographie commente sur les transactions

Complment

: Synthses

Les transactions [w_developpez.com/hcesbronlavau]


Une bonne introduction courte au principe des transactions avec un exemple trs
bien choisi. Des exemples d'implmentation sous divers SGBD (InterBase par
exemple)
SQL2 SQL3, applications Oracle [Delmal01]
Une bonne description des principes des transactions, avec les exemples
caractristiques, l'implmentation SQL et une tude de cas sous Oracle 8 (chapitre
5).
Tutoriel de bases de donnes relationnelles de l'INT Evry [w_int-evry.fr]
(http://www-inf.int-evry.fr/COURS/BD/BD_REL/SUPPORT/poly.html#RTFToC30
Un aperu gnral de l'ensemble de la problmatique des transactions, de la
concurrence et de la fiabilit.
Programmation SQL [Mata03]
Un exemple d'excution de transactions (pages 20-23)

44

Stphane Crozat

Questions de
synthse
Pourquoi une transaction est-elle atomique ?

Pourquoi une transaction est-elle cohrente ?

Pourquoi une transaction est-elle isole ?

Stphane Crozat

45

Questions de synthse

Pourquoi une transaction est-elle durable ?

Qu'est ce qu'un point de contrle ?

A quoi sert le journal des transactions ?

Lalgorithme de reprise UNDO-REDO terminera-t-il toutes les transactions qui taient


commences au moment de la panne ?

46

Stphane Crozat

Questions de synthse

Laquelle des proprits ACID des transactions est-elle particulirement utile pour grer les
accs concurrents ?

Le verrouillage est-il une solution parfaite pour la gestion de la concurrence ?

Pourquoi peut-on dire que les transactions sont des unit logique de travail, des units
d'intgrit, des units de reprise et des units de concurrence ?

Stphane Crozat

47

Solution des
exercices
> Solution n1 (exercice p. 10)
1
2
3
4
5
6

BEGIN TRANSACTION;
INSERT INTO test(a) VALUES (1);
INSERT INTO test(a) VALUES (2);
COMMIT;
SELECT * FROM test;

1
2
3
4

a
--1
2

> Solution n2 (exercice p. 10)


1
2
3
4
5
6

BEGIN TRANSACTION;
INSERT INTO test(a) VALUES (1);
INSERT INTO test(a) VALUES (2);
ROLLBACK;
SELECT * FROM test;

1
2
3
4

a
--1
2

> Solution n3 (exercice p. 16)

Stphane Crozat

1
2
3
4
5
6
7

BEGIN TRANSACTION;
INSERT INTO test(a) VALUES (1);
INSERT INTO test(a) VALUES (2);
SELECT * FROM test;

1
2
3

a
--1

49

Solution des exercices


4

1
2

-- SIMULATION DE CRASH
SELECT * FROM test;

1
2
3
4

a
--(0 rows)

> Solution n4 (exercice p. 18)


Explication
1. Le script est en mode AUTOCOMMIT ce qui signifie que chaque instruction
est isole dans une transaction propre, un COMMIT implicite tant excut
aprs chaque INSERT (voir ci-aprs).
2. Une dfaillance systme (probablement une coupure rseau) est survenue
juste avant le dernier INSERT, ce qui a empch son excution. Les six
premiers INSERT ont donc t excuts, mais pas le septime (celui qui
concerne la tte).
1
2
3
4
5
6
7
8
9
10
11
12
13
14

INSERT INTO Personnage (designation, prix, identite_secrete, genre)


VALUES ('Superchild','12','Jordy','superhros') ;
COMMIT ;
INSERT INTO Membre (propritaire, nom, couleur) VALUES
('Superchild','tete','rose') ;
COMMIT ;
INSERT INTO Membre (propritaire, nom, couleur) VALUES
('Superchild','bras droit','bleu') ;
COMMIT ;
INSERT INTO Membre (propritaire, nom, couleur) VALUES
('Superchild','bras gauche','bleu') ;
COMMIT ;
INSERT INTO Membre (propritaire, nom, couleur) VALUES
('Superchild','torse','rouge') ;
COMMIT ;
INSERT INTO Membre (propritaire, nom, couleur) VALUES
('Superchild','jambe gauche','bleu') ;
COMMIT ;
INSERT INTO Membre (propritaire, nom, couleur) VALUES
('Superchild','jambe droite','bleu') ;
COMMIT ;

> Solution n5 (exercice p. 18)


AUTOCOMMIT dsactiv, BEGIN implicite
Pour grer ce problme il faut encapsuler les sept INSERT dans une unique
transaction, celle-ci en assure alors l'atomicit : il ne sera plus possible une
partie seulement des INSERT d'tre excute.
1
2
3
4
5
6

50

\set AUTOCOMMIT off


INSERT INTO Personnage (designation, prix, identite_secrete, genre)
VALUES ('Superchild','12','Jordy','superhros') ;
INSERT INTO Membre (propritaire, nom, couleur) VALUES
('Superchild','tete','rose') ;
INSERT INTO Membre (propritaire, nom, couleur) VALUES
('Superchild','bras droit','bleu') ;
INSERT INTO Membre (propritaire, nom, couleur) VALUES
('Superchild','bras gauche','bleu') ;
INSERT INTO Membre (propritaire, nom, couleur) VALUES
('Superchild','torse','rouge') ;

Stphane Crozat

Solution des exercices


7
8
9

INSERT INTO Membre (propritaire, nom, couleur) VALUES


('Superchild','jambe gauche','bleu') ;
INSERT INTO Membre (propritaire, nom, couleur) VALUES
('Superchild','jambe droite','bleu') ;
COMMIT ;

AUTOCOMMIT activ, BEGIN explicite


1
2
3
4
5
6
7
8
9

BEGIN TRANSACTION ;
INSERT INTO Personnage (designation, prix, identite_secrete, genre)
VALUES ('Superchild','12','Jordy','superhros') ;
INSERT INTO Membre (propritaire, nom, couleur) VALUES
('Superchild','tete','rose') ;
INSERT INTO Membre (propritaire, nom, couleur) VALUES
('Superchild','bras droit','bleu') ;
INSERT INTO Membre (propritaire, nom, couleur) VALUES
('Superchild','bras gauche','bleu') ;
INSERT INTO Membre (propritaire, nom, couleur) VALUES
('Superchild','torse','rouge') ;
INSERT INTO Membre (propritaire, nom, couleur) VALUES
('Superchild','jambe gauche','bleu') ;
INSERT INTO Membre (propritaire, nom, couleur) VALUES
('Superchild','jambe droite','bleu') ;
COMMIT TRANSACTION ;

> Solution n6 (exercice p. 25)


1
2

-- term1
INSERT INTO test(a) VALUES (1);

1
2

-- term2
SELECT * FROM test;

1
2
3

a
--1

> Solution n7 (exercice p. 26)

Stphane Crozat

1
2
3
4
5

-- term1
BEGIN TRANSACTION;
INSERT INTO test(a) VALUES (2);
SELECT * FROM test;

1
2
3
4

a
--1
2

1
2

-- term2
SELECT * FROM test;

1
2
3

a
--1

-- term1

51

Solution des exercices


2
3

COMMIT;

1
2

-- term2
SELECT * FROM test;

1
2
3
4

a
--1
2

> Solution n8 (exercice p. 26)


1
2
3
4

-- term1
BEGIN TRANSACTION;
UPDATE test SET a=a*2;

1
2
3

-- term2
UPDATE test SET a=a*3;
-- attente...

1
2

-- term1
COMMIT;

1
2

-- term2
SELECT * FROM test;

1
2
3
4

a
---6
12

1
2

-- term1
SELECT * FROM test;

1
2
3
4

a
---6
12

> Solution n9 (exercice p. 33)

52

Stphane Crozat

Solution des exercices

Image 3 Comptes bancaires

1
2
3
4
5
6
7
8
9
10
11
12
13

*** MLD ***


Pays (Numero:Entier, Intitule:Chane)
Ville (Numero:Entier, NumPays=>Pays, Intitule:Chane)
Agence (Numero:Entier, NumPays=>Ville, NumVille=>Ville,
Intitule:Chane)
CompteCourant(Numero:Entier, NumPays=>Agence, NumVille=>Agence,
NumAgence=>Agence, Solde:RelPositif, Client=>Client)
CompteEpargne(Numero:Entier, NumPays=>Agence, NumVille=>Agence,
NumAgence=>Agence, Solde:RelPositif, Client=>Client)
Client(Numero, Nom:Chane, Prenom:Chane, Civilite:{M|Mme|Melle})
** Contraintes supplmentaires :
CompteCourant.Client est une cl
CompteEpargne.Client est une cl
Tout enregistrement de Client est rfrenc par un enregistrement de
CompteCourant

Remarque
L'ajout des cls trangres dans la cl primaire en cascade (pour ville, agence et
compte) est directement li au fait que les entits Ville, Agence et Compte sont des
entits faibles (ou composition en UML), respectivement par rapport Pays, Ville et
Agence. L'intrt est simple, le Numro d'une ville tant relatif un pays (par
dfinition de l'entit faible), il faut pour identifier (connatre) une ville son numro
et celui de son pays. Chaque pays compte bien une seule ville n1, mais il existe
plusieurs villes n1 si l'on considre tous les pays. Idem pour Agence et Compte. La
seule alternative est de mettre des cls artificielles non relatives, mais ce n'est pas
toujours pertinent. On notera que les comptes bancaires sont effectivement
composs d'un code agence + un code ville + un code pays, etc.

1
2
3
4
5
6
7
8
9
10
11
12

Stphane Crozat

*** Code SQL ***


CREATE TABLE TPays (
pkNumero INTEGER,
aIntitule VARCHAR(20),
PRIMARY KEY (pkNumero)
);
CREATE TABLE TVille (
pkNumero INTEGER,
pfkNumPays INTEGER,
aIntitule VARCHAR(20),

53

Solution des exercices


13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57

PRIMARY KEY (pkNumero, pfkNumPays),


FOREIGN KEY (pfkNumPays) REFERENCES TPays(pkNumero)
);
CREATE TABLE TAgence (
pkNumero INTEGER,
pfkNumVille INTEGER,
pfkNumPays INTEGER,
aIntitule VARCHAR(20),
PRIMARY KEY (pkNumero, pfkNumVille, pfkNumPays),
FOREIGN KEY (pfkNumVille, pfkNumPays) REFERENCES TVille(pkNumero,
pfkNumPays)
);
CREATE TABLE TClient (
pkNumero INTEGER,
aNom VARCHAR(20) NOT NULL,
aPrenom VARCHAR (20),
aCivilite CHAR(5) NOT NULL,
PRIMARY KEY (pkNumero),
CHECK (aCivilite='M' OR aCivilite='Mme' OR aCivilite='Melle')
);
CREATE TABLE TCompteCourant (
pkNumero INTEGER,
pfkNumAgence INTEGER,
pfkNumVille INTEGER,
pfkNumPays INTEGER,
aSolde INTEGER NOT NULL,
fkClient INTEGER REFERENCES TClient(pkNumero) UNIQUE NOT NULL,
PRIMARY KEY (pkNumero, pfkNumAgence, pfkNumVille, pfkNumPays),
FOREIGN KEY (pfkNumAgence, pfkNumVille, pfkNumPays) REFERENCES
TAgence(pkNumero, pfkNumVille, pfkNumPays),
CHECK (aSolde >= 0)
);
CREATE TABLE TCompteEpargne (
pkNumero INTEGER,
pfkNumAgence INTEGER,
pfkNumVille INTEGER,
pfkNumPays INTEGER,
aSolde INTEGER NOT NULL,
fkClient INTEGER REFERENCES TClient(pkNumero) UNIQUE NOT NULL,
PRIMARY KEY (pkNumero, pfkNumAgence, pfkNumVille, pfkNumPays),
FOREIGN KEY (pfkNumAgence, pfkNumVille, pfkNumPays) REFERENCES
TAgence(pkNumero, pfkNumVille, pfkNumPays),
CHECK (aSolde >= 0)
);

> Solution n10 (exercice p. 33)


1
2
3
4
5
6
7
8
9
10
11
12
13
14

54

INSERT INTO TClient VALUES (1, 'Dupont', 'Robert', 'M');


-- Il faut galement crer un compte courant car tout client doit en
possder un.
INSERT INTO TPays VALUES (1, 'France');
INSERT INTO TVille VALUES (1, 1, 'Compigne');
INSERT INTO TAgence VALUES (1, 1, 1, 'Centre Ville');
INSERT INTO TCompteCourant VALUES (1, 1, 1, 1, 0, 1);
INSERT INTO TClient VALUES (2, 'Durand', 'Alphonse', 'M');

Stphane Crozat

Solution des exercices


15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

INSERT INTO TcompteCourant VALUES (2, 1, 1, 1, 0, 2);


INSERT INTO TcompteEpargne VALUES (1, 1, 1, 1, 0, 2);
UPDATE TcompteEpargne
SET aSolde=aSolde+1000
WHERE fkClient=2;
-- NB : On peut utiliser le champs fkClient qui est une cl
UPDATE TcompteCourant
SET aSolde=aSolde+100
WHERE fkClient=1;
UPDATE TcompteCourant
SET aSolde=aSolde+100
WHERE fkClient=1;
UPDATE TcompteEpargne
SET aSolde=aSolde-500
WHERE fkClient=2;
UPDATE TcompteCourant
SET aSolde=aSolde+500
WHERE fkClient=2;

> Solution n11 (exercice p. 34)


Les problmes sont lis au fait que certaines oprations ont eu lieu et d'autres pas.
La valeur 100 pour le solde de tous comptes du client 1, signifie que seul l'un des
deux chques a t enregistr.
La valeur 500 pour le solde de tous comptes du client 2, signifie que, lors du
transfert, le compte pargne a t dbit, mais que le compte courant n'a pas t
crdit.

> Solution n12 (exercice p. 34)


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

Stphane Crozat

BEGIN TRANSACTION;
INSERT INTO TClient VALUES (1, 'Dupont', 'Robert', 'M');
INSERT INTO TPays VALUES (1, 'France');
INSERT INTO TVille VALUES (1, 1, 'Compigne');
INSERT INTO TAgence VALUES (1, 1, 1, 'Centre Ville');
INSERT INTO TCompteCourant VALUES (1, 1, 1, 1, 0, 1);
COMMIT;
-- Les cinq oprations prcdentes doivent toutes tre excutes, ou
bien aucune, car en vertu des cardinalits du MCD :
--il ne peut exister de client sans compte courant,
--il ne peut exister de pays sans ville,
--il ne peut exister de ville sans agence,
--il ne peut exister d'agence sans compte.
--La transaction assure l'unit logique de traitement de ces
oprations.
BEGIN TRANSACTION;
INSERT INTO TClient VALUES (2, 'Durand', 'Alphonse', 'M');
INSERT INTO TcompteCourant VALUES (2, 1, 1, 1, 0, 2);
INSERT INTO TcompteEpargne VALUES (1, 1, 1, 1, 0, 2);
UPDATE TcompteEpargne
SET aSolde=aSolde+1000
WHERE fkClient=2;
COMMIT;
-- Les quatre oprations prcdentes correspondent l'initialisation
du client 2, il est donc conseill qu'elles s'effectuent galement de
faon unitaire.

55

Solution des exercices


24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

56

-- Dans tous les cas les deux premires instructions DOIVENT tre
effectues dans la mme transaction, car il ne peut exister de client
sans compte courant et inversement.
BEGIN TRANSACTION;
UPDATE TcompteCourant
SET aSolde=aSolde+100
WHERE fkClient=1;
UPDATE TcompteCourant
SET aSolde=aSolde+100
WHERE fkClient=1;
COMMIT;
-- Les deux oprations prcdentes peuvent tre regroupes dans une
mme transaction, puisque l'on s'attend bien un crdit de 200.
BEGIN TRANSACTION;
UPDATE TcompteEpargne
SET aSolde=aSolde-500
WHERE fkClient=2;
UPDATE TcompteCourant
SET aSolde=aSolde+500
WHERE fkClient=2;
COMMIT;
-- Le transfert est le cas typique o la transaction est obligatoire,
en effet, effectuer le crdit sans le dbit ou inversement serait une
erreur vis vis de la cohrence de la BD.

Stphane Crozat

Solution des
exercices
> Solution n1 (exercice p. 12,37)
6

> Solution n2 (exercice p. 12,38)


3

> Solution n3 (exercice p. 12,38)


3
Les transactions n'affectent normalement que les instructions LMD et non les
instructions LDD.
Notons nanmoins que certains SGBD peuvent tre paramtrs pour autoriser
certaines instructions LDD tre affectes par les transactions (ce qui est un
dtournement de l'usage thorique des transactions).

> Solution n4 (exercice p. 17,38)


UPDATE C1 SET Solde=Solde-100 WHERE Numero=12;
ROLLBACK;
UPDATE C2 SET Solde=Solde+100 WHERE Numero=12;
COMMIT;
UPDATE C1 SET Solde=Solde-100 WHERE Numero=12
UPDATE C2 SET Solde=Solde+100 WHERE Numero=12
ROLLBACK;
UPDATE C1 SET Solde=Solde-100 WHERE Numero=12;
COMMIT;
UPDATE C2 SET Solde=Solde+100 WHERE Numero=12;
COMMIT;
UPDATE C1 SET Solde=Solde-100 WHERE Numero=12;
UPDATE C2 SET Solde=Solde+100 WHERE Numero=12;
COMMIT;
UPDATE C1 SET Solde=Solde-100 WHERE Numero=12;
ROLLBACK;
UPDATE C2 SET Solde=Solde-100 WHERE Numero=12;
ROLLBACK;
Stphane Crozat

57

Solution des exercices

Il est ncessaire que les deux instructions UPDATE aient lieu pour que le transfert
soit correct et non l'une des deux seulement, le COMMIT doit donc tre plac aprs
les deux instructions.

> Solution n5 (exercice p. 27,39)


3
La transaction 1 obtient un verrou X t2 et excute donc sans problme ses deux
UPDATE.
La transaction 2 est mise en attente avant son UPDATE t3, car elle ne peut
obtenir de verrou X dj pos par la transaction 1. Mais ds que la transaction 1
excute son COMMIT t5, la transaction 1 obtient de poser un verrou X (libr par
la transaction 1) et peut donc excuter son UPDATE. A t6 la transaction 2 voit donc
que A a t augment de 3, puisque les trois transactions UPDATE ont t
excutes.
Notons nanmoins que la transaction 2 n'a pas encore fait de COMMIT, et donc que
potentiellement un ajout de 1 sur A pourrait tre annul plus tard par un ROLLBACK
de la transaction 2. Donc une augmentation de 2 est dfinitivement acquise et une
augmentation de 1 supplmentaire est acquise pour le moment, mais pourra tre
remise en cause.

> Solution n6 (exercice p. 28,35)


Exercice
1
TR1 est en cours, de son point de vue isol les entres ont t augmentes de 1.

Exercice
0
TR1 n'est pas valid t3, les modifications ne sont pas encore visibles en dehors de
la transaction.

Exercice
1

TR1 obtient un verrou X t2 et excute son UPDATE.


TR2 est mise en attente avant son UPDATE t4, car elle ne peut obtenir de
verrou X dj pos par TR1.
t5 TR1 est toujours en cours dexcution, et TR2 toujours bloque, donc
les entres ont t augmentes de 1 pour le moment.

Exercice
0
TR1 est en cours dexcution, et TR2 bloque, donc t.a n'a pas t augment de
son point de vue.

Exercice
1
Le commit dbloque TR2 qui excute son update, mais celui-ci n'est toujours pas
visible depuis TR1.

58

Stphane Crozat

Solution des exercices

Exercice
2
TR2 a pu excuter son update t6 ds que TR1 a libr le verrou avec son commit.
TR1 est valid, donc la modification est visible, et du point de vue de TR2, la
modification en cours de TR2 est galement visible.

> Solution n7 (exercice p. 40)


2

Stphane Crozat

59

Signification des
abrviations
-

ACID
BD
FIFO
LDD
LMD
SGBD
SQL

Stphane Crozat

Atomicity, Consistency, Isolation, Durability


Base de Donnes
First In First Out
Langage de Dfinition de Donnes
Langage de Manipulation de Donnes
Systme de Gestion de Bases de Donnes
Structured Query Language

61

Bibliographie

[Delmal01] DELMAL PIERRE. SQL2 SQL3, applications Oracle. De Boeck Universit, 2001.
[Mata03] MATA-TOLEDO RAMON A., CUSHMAN PAULINE K.. Programmation SQL. Ediscience, 2003.

Stphane Crozat

63

Webographie

[w_developpez.com/hcesbronlavau]
CESBRON-LAVAU
HENRY,
http://www.developpez.com/hcesbronlavau/Transactions.htm , 2002.

Les

transactions,

[w_int-evry.fr] DEFUDE BRUNO, Tutoriel de bases de donnes relationnelles de l'INT Evry, http://wwwinf.int-evry.fr/COURS/BD/ , consult en 2009.

Stphane Crozat

65

Index
Acces......................... p.11, 16
ACID p.8
Annulation....................... p.8
Attente........................... p.30
Cohrence............... p.7, 8, 8, 20
COMMIT................... p.9, 11, 14
Concurrence............. p.7, 20, 26
Dfaillance....................... p.7
Dverrouillage................. p.24
Durabilit......................... p.9

Stphane Crozat

Ecriture.......................... p.23
Excution......................... p.8
Fiabilit.......................... p.16
Inter-blocage.............. p.24, 26
Journal..................... p.9, 14, 14
Lecture........................... p.23
Oracle.................... p.10, 11, 16
Panne............... p.9, 13, 14, 14, 18
Perte p.20
PL/SQL....................... p.11, 16

Point de contrle...... p.14, 14, 18


ROLLBACK............ p.9, 11, 13, 24
SQL p.9, 10, 11, 16
Transaction....... p.8, 10, 11, 11, 16
Transfert........................ p.16
UNDO-REDO................... p.18
Unit p.8, 8, 13, 14
Validation........................ p.8
VBA p.11, 16
Verrou............ p.23, 24, 24, 26, 30

67