Gestion des transactions dans les SGBD : états, types et ACID

Qu'est-ce qu'une transaction de base de données ?

A Transaction de base de données Une transaction est une unité de traitement logique dans un SGBD qui comprend une ou plusieurs opérations d'accès à la base de données. En résumé, les transactions de base de données représentent des événements concrets au sein d'une entreprise.

Dans un SGBD, toutes les opérations d'accès à la base de données effectuées entre les instructions de début et de fin de transaction sont considérées comme une seule transaction logique. Durant la transaction, la base de données est incohérente. Ce n'est qu'une fois la transaction validée que son état passe d'un état cohérent à un autre.

Informations sur les transactions de bases de données

• Une transaction est une unité de programme dont l'exécution peut ou non modifier le contenu d'une base de données.
• Le concept de transaction dans le SGBD est exécuté comme une seule unité.
• Si les opérations de base de données ne mettent pas à jour la base de données mais récupèrent uniquement des données, ce type de transaction est appelé transaction en lecture seule.
• Une transaction réussie peut faire passer la base de données d'un état cohérent à un autre.
• Les transactions des SGBD doivent être atomiques, cohérentes, isolées et durables.
• Si la base de données était dans un état incohérent avant une transaction, elle le resterait après la transaction.

Pourquoi avez-vous besoin de concurrence dans les transactions ?

Une base de données est une ressource partagée. Elle est utilisée simultanément par de nombreux utilisateurs et processus. On peut citer comme exemples les systèmes bancaires, les systèmes de réservation ferroviaires et aériennes, la surveillance des marchés boursiers, ainsi que la gestion des stocks et des caisses des supermarchés.

Ne pas gérer les accès simultanés peut créer des problèmes tels que :

• Pannes matérielles et plantages système.
• Exécution simultanée de la même transaction, impasse, ou des performances lentes.

Contrôler cet accès partagé est la tâche de Contrôle de la concurrenceCette méthode utilise le verrouillage et l'horodatage pour entrelacer les transactions de manière sécurisée. Auparavant, il est utile de connaître les états par lesquels passe une transaction.

États des transactions

Les différents états d'un concept de transaction dans un SGBD sont répertoriés ci-dessous :

Étudions un diagramme de transition d'état qui met en évidence la façon dont une transaction se déplace entre ces différents états.

1. Une fois qu'une transaction commence son exécution, elle devient active. Elle peut alors effectuer une opération de lecture ou d'écriture.
2. Une fois les opérations de lecture et d'écriture terminées, la transaction atteint l'état partiellement validé.
3. Ensuite, certains protocoles de récupération doivent garantir qu'une panne système n'empêchera pas l'enregistrement définitif des modifications de la transaction. Si cette vérification est concluante, la transaction est validée et passe à l'état validé.
4. Si le contrôle échoue, la transaction passe à l'état d'échec.
5. Si une transaction est annulée alors qu'elle est en cours, elle passe à l'état d'échec. Il convient alors de la restaurer pour annuler les modifications apportées à la base de données.
6. L'état terminé fait référence à la transaction qui quitte le système.

Que sont les propriétés des acides ?

Propriétés ACIDES sont utilisées pour maintenir l'intégrité de la base de données lors du traitement des transactions. ACID, dans le contexte des SGBD, signifie Atomicité, Cconstance, Ile réconfort, et Durabilité.

• Atomicité : Une transaction est une unité d’opération unique. Soit vous l’exécutez entièrement, soit vous ne l’exécutez pas du tout. Il ne peut y avoir d’exécution partielle.
• Cohérence: Une fois la transaction exécutée, elle doit passer d’un état cohérent à un autre.
• Isolement: Une transaction doit être exécutée de manière isolée des autres transactions. Lors d'une exécution simultanée, les résultats intermédiaires des transactions exécutées simultanément ne doivent pas être communiqués entre elles.
• Durabilité: Après la réussite d'une transaction, les modifications apportées à la base de données doivent être conservées, même en cas de panne du système.

Propriétés ACID dans les SGBD : exemple

Voici un exemple de la propriété ACID dans un SGBD :

Transaction 1: Begin X=X+50, Y = Y-50 END
Transaction 2: Begin X=1.1*X, Y=1.1*Y END

La transaction 1 transfère 50 $ du compte X vers le compte Y.

La transaction 2 crédite chaque compte d'un paiement d'intérêt de 10 %.

Si les deux transactions sont soumises simultanément, rien ne garantit que la transaction 1 sera exécutée avant la transaction 2, ni l'inverse. Quel que soit l'ordre, le résultat sera identique à celui d'une exécution séquentielle des transactions.

Types d'opérations

En fonction des domaines d'application :

• Non distribué vs. distribué.
• Transactions compensatoires.
• Délai de transaction.
• En ligne ou par lots.

En fonction des actions :

• Deux étapes.
• Limité.
• Modèle d'action.

Basé sur la structure :

• Transactions plates ou simples : consistent en une séquence d’opérations primitives exécutées entre une opération de début et une opération de fin.
• Transactions imbriquées : une transaction qui contient d’autres transactions.
• Flux de travail.

Qu'est-ce qu'un horaire ?

Un ordonnancement est un processus qui consiste à créer un groupe unique de plusieurs transactions parallèles et à les exécuter une à une. Il doit préserver l'ordre d'apparition des instructions dans chaque transaction. Si deux transactions sont exécutées simultanément, le résultat de l'une peut affecter le résultat de l'autre.

Exemple

Initial Product Quantity is 10
Transaction 1: Update Product Quantity to 50
Transaction 2: Read Product Quantity

Si la transaction 2 est exécutée avant la transaction 1, des informations obsolètes sur la quantité de produit seront lues. Des horaires sont donc nécessaires.

L'exécution parallèle dans une base de données est inévitable. Elle n'est toutefois autorisée que lorsqu'il existe une relation d'équivalence entre les transactions exécutées simultanément. Cette équivalence est de trois types.

Équivalence des résultats : Si deux planifications affichent le même résultat après exécution, on parle de planifications à résultat équivalent. Elles peuvent donner le même résultat pour certaines valeurs et des résultats différents pour d'autres. Par exemple, une transaction met à jour la quantité de produit tandis qu'une autre met à jour les informations client.

Afficher l'équivalence : L'équivalence de vue se produit lorsque les transactions des deux planifications effectuent une action similaire. Par exemple, une transaction insère les détails d'un produit dans la table des produits, tandis qu'une autre les insère dans la table des archives. La transaction est identique, mais les tables sont différentes.

Équivalence des conflits : Dans ce cas, deux transactions mettent à jour ou consultent le même ensemble de données. Un conflit survient entre les transactions, car leur ordre d'exécution influe sur le résultat.

Qu’est-ce que la sérialisabilité ?

La sérialisabilité est le processus de recherche d'un ordonnancement concurrent dont le résultat est équivalent à celui d'un ordonnancement séquentiel où les transactions sont exécutées l'une après l'autre. Selon le type d'ordonnancement, il existe deux types de sérialisabilité :

• Sérialisabilité des conflits.
• Afficher la sérialisabilité.

Les deux diffèrent dans la rigueur avec laquelle ils jugent l'équivalence, comme résumé ci-dessous.

Tout calendrier sérialisable par conflit est également sérialisable par vue, mais l'inverse n'est pas vrai, c'est pourquoi la sérialisabilité par conflit est le test pratique appliqué par un SGBD.

FAQ