SGBD – Transaction

Une transaction peut être définie comme un groupe de tâches. Une seule tâche est l’unité de traitement minimale qui ne peut pas être divisée davantage.

Prenons l’exemple d’une transaction simple. Supposons qu’un employé de banque transfère 500 roupies du compte de A au compte de B. Cette transaction très simple et petite implique plusieurs tâches de bas niveau.

Le compte de A

Open_Account(A)Old_Balance = A.balanceNew_Balance = Old_Balance - 500A.balance = New_BalanceClose_Account(A)

Le compte de B

Open_Account(B)Old_Balance = B.balanceNew_Balance = Old_Balance + 500B.balance = New_BalanceClose_Account(B)

Propriétés de l’ACID

Une transaction est une très petite unité d’un programme et elle peut contenir plusieurs tâches de bas niveau. Une transaction dans un système de base de données doit maintenir l’Atomicité, la Cohérence, l’Isolation et la Durabilité – communément appelées propriétés ACID – afin de garantir l’exactitude, l’exhaustivité et l’intégrité des données.

• Atomicité – Cette propriété stipule qu’une transaction doit être traitée comme une unité atomique, c’est-à-dire que soit toutes ses opérations sont exécutées, soit aucune. Il ne doit y avoir aucun état dans une base de données où une transaction est laissée partiellement terminée. Les états doivent être définis soit avant l’exécution de la transaction, soit après l’exécution/abandon/échec de la transaction.

• Consistance – La base de données doit rester dans un état cohérent après toute transaction. Aucune transaction ne doit avoir d’effet négatif sur les données résidant dans la base de données. Si la base de données était dans un état cohérent avant l’exécution d’une transaction, elle doit également rester cohérente après l’exécution de la transaction.

• Durabilité – La base de données doit être suffisamment durable pour conserver toutes ses dernières mises à jour même si le système échoue ou redémarre. Si une transaction met à jour un morceau de données dans une base de données et committe, alors la base de données conservera les données modifiées. Si une transaction s’engage mais que le système échoue avant que les données puissent être écrites sur le disque, alors ces données seront mises à jour une fois que le système se remet en marche.

• Isolation – Dans un système de base de données où plus d’une transaction sont exécutées simultanément et en parallèle, la propriété d’isolation stipule que toutes les transactions seront effectuées et exécutées comme si c’était la seule transaction du système. Aucune transaction n’affectera l’existence d’une autre transaction.

Sérialisabilité

Lorsque plusieurs transactions sont exécutées par le système d’exploitation dans un environnement de multiprogrammation, il existe des possibilités que les instructions d’une transaction soient entrelacées avec une autre transaction.

• Schedule – Une séquence d’exécution chronologique d’une transaction est appelée un planning. Un ordonnancement peut comporter de nombreuses transactions, chacune comprenant un certain nombre d’instructions/tâches.

• Ordonnancement en série – C’est un ordonnancement dans lequel les transactions sont alignées de telle sorte qu’une transaction est exécutée en premier. Lorsque la première transaction termine son cycle, alors la transaction suivante est exécutée. Les transactions sont ordonnées les unes après les autres. Ce type d’ordonnancement est appelé un ordonnancement série, car les transactions sont exécutées de manière sérielle.

Dans un environnement multi-transactions, les ordonnances série sont considérées comme une référence. La séquence d’exécution d’une instruction dans une transaction ne peut pas être modifiée, mais deux transactions peuvent voir leurs instructions exécutées de manière aléatoire. Cette exécution n’est pas nuisible si les deux transactions sont mutuellement indépendantes et travaillent sur différents segments de données ; mais si ces deux transactions travaillent sur les mêmes données, les résultats peuvent varier. Ce résultat toujours variable peut amener la base de données à un état incohérent.

Pour résoudre ce problème, nous autorisons l’exécution parallèle d’un planning de transactions, si ses transactions sont soit sérialisables, soit ont une certaine relation d’équivalence entre elles.

Equivalence Schedules

Un ordonnancement d’équivalence peut être des types suivants –

Equivalence de résultat

Si deux ordonnances produisent le même résultat après exécution, elles sont dites équivalentes en termes de résultat. Ils peuvent donner le même résultat pour une certaine valeur et des résultats différents pour un autre ensemble de valeurs. C’est pourquoi cette équivalence n’est généralement pas considérée comme significative.

Equivalence de vue

Deux ordonnancements seraient équivalents en termes de vue si les transactions des deux ordonnancements effectuent des actions similaires de manière similaire.

Par exemple –

• Si T lit les données initiales dans S1, alors il lit également les données initiales dans S2.

• Si T lit la valeur écrite par J dans S1, alors il lit également la valeur écrite par J dans S2.

• Si T effectue l’écriture finale sur la valeur de données dans S1, alors il effectue également l’écriture finale sur la valeur de données dans S2.

Equivalence de conflit

Deux programmes seraient conflictuels s’ils ont les propriétés suivantes –

• Les deux appartiennent à des transactions distinctes.
• Les deux accèdent au même élément de données.
• Au moins l’un d’entre eux est une opération « d’écriture ».

Deux planifications ayant plusieurs transactions avec des opérations conflictuelles sont dites équivalentes en conflit si et seulement si –

• Les deux planifications contiennent le même ensemble de transactions.
• L’ordre des paires d’opérations conflictuelles est maintenu dans les deux planifications.

Note – Les planifications équivalentes en vue sont sérialisables en vue et les planifications équivalentes en conflit sont sérialisables en conflit. Tous les ordonnancements sérialisables par conflit sont sérialisables par vue également.

États des transactions

Une transaction dans une base de données peut être dans l’un des états suivants –

• Actif – Dans cet état, la transaction est en cours d’exécution. C’est l’état initial de chaque transaction.

• Partiellement engagée – Lorsqu’une transaction exécute sa dernière opération, on dit qu’elle est dans un état partiellement engagé.

• Echec – Une transaction est dite dans un état d’échec si l’une des vérifications effectuées par le système de récupération de la base de données échoue. Une transaction en échec ne peut plus aller plus loin.

Aborted – Si l’une des vérifications échoue et que la transaction a atteint un état d’échec, alors le gestionnaire de récupération ramène toutes ses opérations d’écriture sur la base de données pour ramener la base de données à son état d’origine où elle était avant l’exécution de la transaction. Les transactions dans cet état sont appelées abandonnées. Le module de récupération de la base de données peut sélectionner l’une des deux opérations après l’abandon d’une transaction –

• Redémarrer la transaction
• Firmer la transaction

• Committed – Si une transaction exécute toutes ses opérations avec succès, elle est dite committée. Tous ses effets sont maintenant établis de façon permanente sur le système de base de données.

.