BASES DE DONNES
LE MODELE RELATIONNEL
LES TRANSACTIONS
LES TRANSACTIONS
• Contexte: On effectue une opération entre deux bases de
données (BD) ou deux étapes (traitement entre T0 et T1).
Cela peut inclure des lectures, des mises à jour ou des
insertions.
• Risque: Si une défaillance survient pendant le traitement
(entre T0 et T1), la base de données pourrait se retrouver
dans un état incohérent.
Par exemple :
• Si une opération est partiellement exécutée (ex. débiter
un compte sans créditer l’autre)
• Si une panne ou une erreur interrompt le processus
avant sa finalisation.
• Conséquence: les données peuvent devenir incorrectes, ce
qui peut entraîner des erreurs critiques, comme des pertes
financières, des incohérences dans des stocks, ou des
doublons.
LES TRANSACTIONS
• Une transaction SQL est une série d'opérations exécutées sur une base de
données qui sont traitées comme une unité logique unique. Une transaction
garantit que les données sont modifiées de manière cohérente et fiable,
même en cas de défaillance, comme une panne de courant ou une erreur
système.
• On utilise les transactions SQL pour garantir la fiabilité, la cohérence et
l'intégrité des données lors de l'exécution d'opérations sur une base de
données. Elles jouent un rôle essentiel dans les systèmes où plusieurs
opérations doivent être exécutées ensemble, de manière sécurisée et sans
erreurs.
LES TRANSACTIONS
Raisons principales d’utiliser les transactions:
• Garantir l’intégrité des données
les transactions permettent d’assurer que les données restent dans un état
cohérent avant et après une série d’opérations;
(Par exemple, dans une application bancaire, lors d’un transfert d’argent, si
une étape échoue, la transaction peut être annulée pour éviter des
incohérences (comme débiter un compte sans créditer l'autre).
• Permettre des annulations (Rollback)
En cas d’erreur ou de problème (comme une panne système ou une erreur
dans une requête), les transactions permettent de revenir à l’état initial des
données. Cela évite des modifications partielles ou incorrectes.
LES TRANSACTIONS
• Assurer l’atomicité
Une transaction garantit que toutes les opérations sont exécutées dans
leur totalité, ou qu'aucune n'est exécutée. Cela empêche les
modifications incomplètes, même en cas de panne.
• Gérer les accès concurrents
Dans un environnement multi-utilisateur, les transactions assurent que
plusieurs utilisateurs ou applications peuvent accéder à la base de
données simultanément sans compromettre l'intégrité des données.
(par exemple, deux utilisateurs modifiant le même enregistrement en
même temps ne devraient pas entraîner une corruption des données.
LES TRANSACTIONS
• Garantir la cohérence des données
Les transactions respectent les contraintes d'intégrité (comme les
contraintes de clé étrangère ou d'unicité). Cela garantit que la
base reste dans un état cohérent.
• Faciliter le traitement des erreurs
En cas de défaillance, une transaction peut être annulée
complètement. Cela simplifie la gestion des erreurs dans le code
applicatif.
LES TRANSACTIONS
Cas pratiques où les transactions sont indispensables
• Banque et finance
Transferts d’argent, paiements multiples, ou calculs financiers
sensibles.
• E-commerce
Gestion des commandes: retirer un article du stock et débiter un
client doivent être traités ensemble.
• Systèmes d’inscription ou de réservation
Eviter la sur-réservation en vérifiant la disponibilité et en bloquant
une place en une seule transaction.
• Mises à jour complexes des bases de données
Lorsqu’une opération implique plusieurs tables ou dépendances.
PROPRIETES D’UNE TRANSACTION
Atomicité (A)
Cohérence (C)
Isolation (I)
Durabilité (D)
Ces propriétés sont résumées par l’acronyme ACID
PROPRIETES D’UNE TRANSACTION
Atomicité (A)
Une transaction est atomique, ce qui signifie que toutes ses
opérations sont exécutées ou aucune d'elles ne l'est. Si une
partie échoue, tout est annulé.
PROPRIETES D’UNE TRANSACTION
Consistance (C)
L’exécution de la transaction fait passer la base de
données d’un état consistant à un autre état consistant
PROPRIETES D’UNE TRANSACTION
Isolation (I)
Chaque transaction est indépendante des autres
transactions concurrentes.
Sérialisation des transactions.
Les résultats d’une transaction ne sont visibles aux autres
transactions qu’une fois la transaction validée.
Les concurrences sont parfaitement contrôlées
PROPRIETES D’UNE TRANSACTION
Durabilité (D)
C’est la persistance des mises à jour d’une transaction
validée.
Les effets d’une transaction validée sont durables et
permanents, quelques soient les problèmes logiciels ou
matériels, notamment après la fin de la transaction.
TRANSACTION
Exemple:
TRANSACTION
• Une transaction englobe
plusieurs opérations pour
garantir leur atomicité, leur
cohérence et leur durabilité.
• En cas de succès, on valide
avec COMMIT.
• En cas d’échec, on annule
avec ROLLBACK.
TRANSACTION
• Etat initial cohérent:
• Avant le début de la transaction, la BDD est dans un état cohérent, c’est-à-dire que toutes
les règles d’intégrité et de validation des données sont respectées.
• Etat final cohérent:
• Une fois la transaction terminée avec succès (validée par un COMMIT), la BDD atteint un
nouvel état cohérent.
COMMIT ET ROLLBACK
• Pourquoi utiliser ROLLBACK?
• Protéger la base de données contre des états incohérents causés par
des erreurs ou des interruptions. Par exemple, si une étape de la
transaction échoue, toutes les modifications précédentes sont
annulées.
• Pourquoi utiliser COMMIT?
• Valider définitivement les modifications lorsque toutes les étapes de
la transaction sont exécutées correctement, garantissant la fiabilité et
la cohérence des données
TRANSACTIONS SOUS ORACLE
TRANSACTIONS SOUS ORACLE
SET TRANSACTION READ [ONLY | WRITE]
INSERT INTO compte_1 (…) VALUES (…);
INSERT INTO compte_2 (…) VALUES (…);
SAVEPOINT <NOM>
DELETE FROM comptabilité WHERE num=123;
UPDATE …….
SAVEPOINT <NOM>
DELETE FROM
[COMMIT | ROLLBACK] ;
TRANSACTIONS SOUS ORACLE
Une transaction commence soit à la connexion ou en début de session, soit à la fin d'une transaction précédente
annulée ou validée.
Le début d’une transaction dans Oracle peut être IMPLICITE (pas besoin de SET TRANSACTION ….)
COMMIT valide entièrement la transaction
ROLLBACK annule entièrement la transaction
Les savepoint sont des points de contrôle utilisés dans les transactions pour annuler partiellement l’une
d’elles.
Il est possible de définir des Savepoint qui sont des points de contrôle utilisés dans une transaction ainsi on a
la possibilité de faire des annulations partielles de transaction.
TRANSACTIONS SOUS ORACLE
RESUME DU FLUX DE LA TRANSACTION:
1. La transaction es initiée (par défaut ou avec SET TRANSACTION)
2. Plusieurs opérations sont exécutées (INSERT, UPDATE, DELETE)
3. Des points intermédiaires sont définis avec SAVEPOINT
4. A la fin de la transaction:
• Si tout se passe bien, un COMMIT valide les modifications.
• En cas de problème, un ROLLBACK annule toutes les modifications ou
revient à un SAVEPOINT précis.
TRANSACTIONS SOUS ORACLE
SET TRANSACTION READ WRITE;
INSERT INTO compte_1 (id, solde) VALUES (1, 1000);
INSERT INTO compte_2 (id, solde) VALUES (2, 500);
SAVEPOINT etape1;
DELETE FROM comptabilité WHERE num = 123;
UPDATE comptes SET solde = solde + 200 WHERE id = 2;
SAVEPOINT etape2;
DELETE FROM ventes WHERE date < '2023-01-01';
-- Valider la transaction
COMMIT;
-- Ou annuler jusqu'au point etape1
-- ROLLBACK TO etape1;
