Une transaction est une unité logique de travail, un ensemble d'instructions d’interrogation ou de mise à jour des données que SQL traite comme une seule action indivisible : soit toutes les instructions comprises dans la transaction sont traitées, soit aucune.
Ce mécanisme garantit la fiabilité des accès au SGBD et la cohérence des données : il pare à toute interruption non désirée d'une séquence d'instructions (arrêt programme, panne machine ou volonté d'annuler les dernières opérations).
La définition explicite de transactions permet de s’assurer de la complétude d’une demande de modification pouvant comporter plusieurs opérations de modification sur plusieurs lignes de plusieurs tables.
Il est ainsi possible de garantir une bonne cohérence à la base de données.
Pour expliciter ce propos, prenons l’exemple d’une transaction bancaire :
Elle est toujours composée du débit d’un compte et du crédit d’un autre compte. Il convient donc de s’assurer que les deux opérations aient bien été effectuées. Si l’une des deux opérations n’aboutit pas, nous aurons alors un système « incohérent ». Si nous ne spécifions pas explicitement que ces deux opérations constituent une seule transaction, le risque d’erreur demeure.
Les données d’une transaction sont validées dans leur ensemble par l’application d’un ordre COMMIT, ou invalidées (elles reprennent alors leur état initial) par l’ordre ROLLBACK.
On appelle ce mécanisme la validation en deux temps.
La validation transactionnelle s’appuie sur le journal des transactions associé à toute base de données.
Une transaction est une suite d'opérations effectuées comme une seule unité logique de travail. Une unité logique de travail doit posséder quatre propriétés appelées propriétés ACID (Atomicité, Cohérence, Isolation et Durabilité), pour être considérée comme une transaction :
Une transaction doit être une unité de travail indivisible ; soit toutes les modifications de données sont effectuées, soit aucune ne l'est.
Lorsqu'elle est terminée, une transaction doit laisser les données dans un état cohérent. Dans une base de données relationnelle, toutes les règles doivent être appliquées aux modifications apportées par la transaction, afin de conserver l'intégrité de toutes les données. Toutes les structures de données internes doivent être cohérentes à la fin de la transaction.
Les modifications effectuées par des transactions concurrentes doivent être isolées transaction par transaction. Une transaction accède aux données soit dans l'état où elles étaient avant d'être modifiées par une transaction concurrente, soit telles qu'elles se présentent après exécution de cette dernière, mais jamais dans un état intermédiaire. Cette propriété est nommée mise en série, car elle permet de recharger les données de départ et de répéter une suite de transactions dont le résultat sur les données sera identique à celui des transactions d'origine.
Lorsqu'une transaction est terminée, ses effets sur le système sont permanents. Les modifications sont conservées même en cas de défaillance du système.
Spécification et maintien de la cohérence des transactions :
Les programmeurs SQL doivent concevoir des transactions dont les points de début et de fin permettent de maintenir la cohérence logique des données. La séquence de modifications des données qu'ils définissent doivent laisser les données dans un état cohérent par rapport aux règles d'entreprise définies par leur société. Ces instructions de modification des données doivent par conséquent être contenues dans une seule transaction pour que Microsoft® SQL Server™ puisse assurer l'intégrité physique de la transaction.
Un système de bases de données d'entreprise comme SQL Server se doit de fournir des mécanismes permettant de garantir l'intégrité physique de chaque transaction. SQL Server dispose des mécanismes suivants :
Verrouillage
Des fonctionnalités de verrouillage permettant d'assurer l'isolation des transactions.
Des fonctionnalités de consignation assurant la durabilité des transactions. En cas de panne matérielle du serveur ou de défaillance du système d'exploitation ou de SQL Server, les journaux de transaction permettent à SQL Server, lorsqu'il redémarre, d'annuler automatiquement toutes les transactions incomplètes au moment de la panne du système.
Des fonctionnalités de gestion des transactions qui assurent l'atomicité et la cohérence des transactions. Lorsqu'une transaction a débuté, elle doit se dérouler correctement jusqu'à la fin, sans quoi SQL Server annule toutes les modifications effectuées sur les données depuis le début de celle-ci.
II. Syntaxe relative aux transactions
BEGIN TRAN ou BEGIN TRANSACTION marque le point de référence du début de la transaction.
La transaction peut éventuellement être nommée.
Les instructions émises dans le cadre la transaction sont verrouillées par le système et l’accès aux données sous-jacentes restreint pour les autres connexions.
Les données sont déverrouillées lors de l’exécution :
Les transactions peuvent être imbriquées.
Les transactions peuvent être nommées et être ainsi référencées plus facilement. Toutefois dans le cadre de transactions imbriquées, seule la transaction la plus extérieure peut être nommée.
L’utilisation de la clause WITH MARK ['description'] lors de la déclaration d’une transaction indique qu’elle est marquée dans le journal des transactions. Si WITH MARK est utilisé, un nom de transaction doit être spécifié.
WITH MARK permet de restaurer un journal de transactions par rapport à une marque nommée.
L’exemple suivant illustre l’intérêt et les conditions de mise en place d’une transaction. Il s’agit ici de l’insertion de lignes de commandes dans la table [Order details] du comptoir anglais.
La clé primaire de la table [Order Details] est constituée de deux colonnes [OrderID] et [ProductID].
Deux lignes d’une même commande ne peuvent donc pas porter sur le même article.
Dans cet exemple, 3 lignes seront insérées et 1 rejetée.
Nous nous trouverons donc avec une commande dans le système non conforme à l’originale.
Insertion de lignes de commandes
Messages et résultat
Dans cet exemple, la différence réside dans le fait qu’aucune ligne ne sera insérée en cas de problèmes. La cohérence des informations reste ainsi assurée.
Recours aux transactions explicites
La variable système @@ERROR
L’utilisation de la variable système @@ERROR dans laquelle se trouve stockée l’erreur relative à la dernière instruction SQL exécutée. J’utilise ici un booléen @Erreur pour détecter si une erreur a été rencontrée au cours de la transaction
Client (Num_client, Nom_client, Prenom_Client)
Compte (Num_Compte, Solde, #Num_Client, typeC)
Mouvement (Num_Mouvement, montant, TypeM, #Num_Compte, DateM)
Virement (Num_Virement,#Num_Cpt_Db, #Num_Cpt_Cr,Montant_Vr, Date_Vr)
Le Numéro de virement est identity, la date du virement est par défaut égale à la date système
1) Créer la table virement
2) Ecrire la procédure stockée ps_virement qui accepte en argument le numéro du compte débiteur, le numéro du compte créditeur, le montant de virement. Mettre à jour les deux comptes débiteur et créditeur puis ajoute la ligne correspondante dans la table virement.
La procédure doit effectuer les traitements suivants dans une seule transaction :
6) Ajouter une ligne dans la table virement.
Toutes les opérations doivent être exécutés dans tous les cas ;
A la sortie de la transaction les traitements sont validés si toutes les opérations ont été effectuer correctement.
En cas de problème la transaction est annulée et des messages qui précisent les sources des erreurs doivent être programmés
Ajouter un commentaire
Veuillez vous connecter pour ajouter un commentaire.
Pas encore de commentaires.