Trasaction BD

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
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
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
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
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]
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
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
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);
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

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

Stphane Crozat

3
4
5
6
7
8

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
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
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.
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).
Elles ont dbut avant tc, mais n'tait pas termines tf. Elles devront tre
annules (pas de COMMIT).
Elles ont dbut aprs tc et se sont termines avant tf. Elles devront tre
rejoues.
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
5. Mini-TP : Simulation d'une panne sous PostgreSQL

1. Se connecter une base de donnes : psql mydb
Question
1.
2.
3.
4.
5.
[Solution n3 p 49]
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
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;
COMMIT;
COMMIT;
COMMIT;
ROLLBACK;
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
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') ;
('Superchild','bras gauche','bleu') ;
('Superchild','jambe gauche','bleu') ;
('Superchild','jambe droite','bleu') ;
('Superchild','torse','rouge') ;
('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
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
Non prises en compte par l'algorithme.
Ajoutes la liste UNDO (tape 1b) puis dplace vers REDO (tape 2b)
puis rejoue (tape 3b).
Ajoutes la liste UNDO (tape 1b) puis annule (tape 3a).
19
Ajoutes la liste UNDO (tape 2a) puis dplace vers REDO (tape 2b)
puis rejoue (tape 3b).
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
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
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
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
(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
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
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
Question 2
1.
2.
3.
4.
5.
6.
term1
term1
term1
term2
term1
term2
[Solution n7 p 51]
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
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
T em ps
T rans ac tion1
t0
T rans ac tion2
B E G INT RA NS A CT IO N
t1
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
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
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

Exercice
Exercice
Exercice
Exercice
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
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
Exercice
36
Stphane Crozat
Test : Transactions

Exercice
Exercice
Exercice
Exercice
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

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

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

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

ROLLBACK;
COMMIT;
ROLLBACK;
COMMIT;
COMMIT;
COMMIT;
ROLLBACK;
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
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
T A B LE 1.A = T A B LE 1.A + 1
t5
CO M M IT
t6
T rans ac tion2
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
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
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);
COMMIT;
SELECT * FROM test;
1
2
3
4
a
--1
2

1
2
3
4
5
6
BEGIN TRANSACTION;
ROLLBACK;
SELECT * FROM test;
1
2
3
4
a
--1
2
Stphane Crozat
1
2
3
4
5
6
7
BEGIN TRANSACTION;
SELECT * FROM test;
1
2
3
a
--1
49

4
1
2
-- SIMULATION DE CRASH
SELECT * FROM test;
1
2
3
4
a
--(0 rows)

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

COMMIT ;
COMMIT ;
COMMIT ;
COMMIT ;
COMMIT ;
COMMIT ;
COMMIT ;

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

Stphane Crozat

7
8
9

COMMIT ;
AUTOCOMMIT activ, BEGIN explicite

1
2
3
4
5
6
7
8
9
BEGIN TRANSACTION ;
COMMIT TRANSACTION ;

1
2
-- term1
1
2
-- term2
SELECT * FROM test;
1
2
3
a
--1
Stphane Crozat
1
2
3
4
5
-- term1
BEGIN TRANSACTION;
SELECT * FROM test;
1
2
3
4
a
--1
2
1
2
-- term2
SELECT * FROM test;
1
2
3
a
--1
-- term1
51

2
3
COMMIT;
1
2
-- term2
SELECT * FROM test;
1
2
3
4
a
--1
2

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
52
Stphane Crozat
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,
53

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,
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,
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,
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)
);

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

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
WHERE fkClient=1;
WHERE fkClient=1;
SET aSolde=aSolde-500
WHERE fkClient=2;
WHERE fkClient=2;

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.

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);
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

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;
WHERE fkClient=1;
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;
SET aSolde=aSolde-500
WHERE fkClient=2;
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

3

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).

ROLLBACK;
COMMIT;
ROLLBACK;
COMMIT;
COMMIT;
COMMIT;
ROLLBACK;
ROLLBACK;
Stphane Crozat
57
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.

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.

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
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.

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

Trasaction BD

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Trasaction BD

Încărcat de

Drepturi de autor:

Formate disponibile

Conception de bases de donnes

Paternit - Partage des Conditions Initiales l'Identique :

I - Thorie : Transactions, fiabilit, concurrence

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

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

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

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

Thorie : Transactions, fiabilit, concurrence

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

III - Test : Transactions

IV - Synthse : Les transactions

V - Bibliographie commente sur les transactions

Solution des exercices

Solution des exercices

Signification des abrviations

Principes des transactions

Manipulation de transactions en SQL

A. Principes des transactions

1. Problmatique des pannes et de la concurrence

Thorie : Transactions, fiabilit, concurrence

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

Fondamental : Cohrence des excutions incorrectes

: 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

4. Proprits ACID d'une transaction

Thorie : Transactions, fiabilit, concurrence

5. Journal des transactions

B. Manipulation de transactions en SQL

Syntaxe : Dbut d'une transaction

BEGIN TRANSACTION (ou BEGIN) ;

Thorie : Transactions, fiabilit, concurrence

Syntaxe : Fin correcte d'une transaction

COMMIT TRANSACTION (ou COMMIT) ;

Syntaxe : Fin incorrecte d'une transaction

ROLLBACK TRANSACTION (ou ROLLBACK) ;

2. Mini-TP : Transaction en SQL standard sous

3. Exemple : Transaction sous Oracle en SQL

: Exemple en SQL sous Oracle

INSERT INTO test (a) VALUES (1);

Attention : BEGIN implicite sous Oracle

Thorie : Transactions, fiabilit, concurrence

4. Exemple : Transaction sous Oracle en PL/SQL

: Exemple en PL/SQL sous Oracle

5. Exemple : Transaction sous Access en VBA

: Exemple de transfert entre deux comptes en VBA sous

Remarque : VBA et transactions

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

\set AUTOCOMMIT off

Thorie : Transactions, fiabilit, concurrence

Autocommit activ : BEGIN explicites, COMMIT implicites

Autocommit dsactiv : BEGIN implicites, COMMIT explicites

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

SET AUTOCOMMIT OFF

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

SET AUTOCOMMIT OFF

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

SET AUTOCOMMIT OFF

Thorie : Transactions, fiabilit, concurrence

CREATE TABLE T2 (A INTEGER);

Les dfaillances systme