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 un exemple de 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.

A’s Account

Open_Account(A)
Old_Balance = A.balance
New_Balance = Old_Balance - 500
A.balance = New_Balance
Close_Account(A)

B’s Account

Open_Account(B)
Old_Balance = B.balance
New_Balance = Old_Balance + 500
B.balance = New_Balance
Close_Account(B)

Propriétés ACID

Une transaction est une très petite unité d'un programme et peut contenir plusieurs tâches de bas niveau. Une transaction dans un système de base de données doit maintenirAtomicité, Consistance, Isolation, et Durabilité - communément appelée propriétés ACID - afin de garantir l'exactitude, l'exhaustivité et l'intégrité des données.

  • Atomicity- Cette propriété indique qu'une transaction doit être traitée comme une unité atomique, c'est-à-dire que toutes ses opérations sont exécutées ou 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 / l'avortement / l'échec de la transaction.

  • Consistency- La base de données doit rester dans un état cohérent après toute transaction. Aucune transaction ne devrait 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.

  • Durability- La base de données doit être suffisamment durable pour contenir 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 est validée, la base de données contiendra les données modifiées. Si une transaction est validée mais que le système échoue avant que les données puissent être écrites sur le disque, ces données seront mises à jour une fois que le système redeviendra opérationnel.

  • Isolation- Dans un système de base de données où plusieurs transactions sont exécutées simultanément et en parallèle, la propriété d'isolation indique que toutes les transactions seront exécutées et exécutées comme s'il s'agissait de la seule transaction du système. Aucune transaction n'affectera l'existence de toute autre transaction.

Sérialisabilité

Lorsque plusieurs transactions sont exécutées par le système d'exploitation dans un environnement de multiprogrammation, il est possible 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 calendrier. Un programme peut contenir de nombreuses transactions, chacune comprenant un certain nombre d'instructions / tâches.

  • Serial Schedule- Il s'agit d'un calendrier 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, la transaction suivante est exécutée. Les transactions sont ordonnées les unes après les autres. Ce type de programme est appelé programme en série, car les transactions sont exécutées en série.

Dans un environnement multi-transactions, les plannings en série sont considérés 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 ne nuit pas si deux transactions sont mutuellement indépendantes et fonctionnent sur des segments de données différents; mais dans le cas où ces deux transactions fonctionnent 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 programme de transaction, si ses transactions sont sérialisables ou ont une relation d'équivalence entre elles.

Calendriers d'équivalence

Un programme d'équivalence peut être des types suivants -

Équivalence des résultats

Si deux planifications produisent le même résultat après exécution, elles sont dites équivalentes au 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.

Voir l'équivalence

Deux programmes seraient une équivalence de vue si les transactions des deux programmes exécutaient 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 exécute également l'écriture finale sur la valeur de données dans S2.

Équivalence de conflit

Deux horaires seraient en conflit 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".

On dit que deux horaires comportant plusieurs transactions avec des opérations en conflit sont équivalents en conflit si et seulement si -

  • Les deux programmes contiennent le même ensemble de transactions.
  • L'ordre des paires d'opérations en conflit est conservé dans les deux horaires.

Note- Afficher les horaires équivalents sont sérialisables et les horaires équivalents en conflit sont sérialisables en conflit. Toutes les planifications sérialisables en conflit sont également sérialisables.

États des transactions

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

  • Active- Dans cet état, la transaction est en cours d'exécution. C'est l'état initial de chaque transaction.

  • Partially Committed - Lorsqu'une transaction exécute son opération finale, on dit qu'elle est dans un état partiellement engagé.

  • Failed- Une transaction est dite en é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 échouée ne peut plus continuer.

  • Aborted- Si l'une des vérifications échoue et que la transaction a atteint un état d'échec, le gestionnaire de récupération annule 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 base de données peut sélectionner l'une des deux opérations après l'annulation d'une transaction -

    • Redémarrez la transaction
    • Tuez la transaction
  • Committed- Si une transaction exécute toutes ses opérations avec succès, elle est dite validée. Tous ses effets sont désormais établis en permanence sur le système de base de données.