DDBMS - Systèmes de traitement des transactions

Ce chapitre traite des différents aspects du traitement des transactions. Nous étudierons également les tâches de bas niveau incluses dans une transaction, les états de transaction et les propriétés d'une transaction. Dans la dernière partie, nous examinerons les horaires et la sérialisabilité des horaires.

Transactions

Une transaction est un programme comprenant une collection d'opérations de base de données, exécutées comme une unité logique de traitement de données. Les opérations effectuées dans une transaction comprennent une ou plusieurs opérations de base de données telles que l'insertion, la suppression, la mise à jour ou la récupération de données. C'est un processus atomique qui est soit exécuté en totalité ou qui n'est pas exécuté du tout. Une transaction impliquant uniquement la récupération de données sans aucune mise à jour des données est appelée transaction en lecture seule.

Chaque opération de haut niveau peut être divisée en un certain nombre de tâches ou d'opérations de bas niveau. Par exemple, une opération de mise à jour des données peut être divisée en trois tâches -

  • read_item() - lit l'élément de données du stockage vers la mémoire principale.

  • modify_item() - changer la valeur de l'élément dans la mémoire principale.

  • write_item() - écrire la valeur modifiée de la mémoire principale vers le stockage.

L'accès à la base de données est limité aux opérations read_item () et write_item (). De même, pour toutes les transactions, la lecture et l'écriture forment les opérations de base de la base de données.

Opérations de transaction

Les opérations de bas niveau effectuées dans une transaction sont -

  • begin_transaction - Un marqueur qui spécifie le début de l'exécution de la transaction.

  • read_item or write_item - Opérations de base de données qui peuvent être entrelacées avec des opérations de mémoire principale dans le cadre d'une transaction.

  • end_transaction - Un marqueur qui spécifie la fin de la transaction.

  • commit - Un signal pour indiquer que la transaction a été complétée avec succès dans son intégralité et ne sera pas annulée.

  • rollback- Un signal pour indiquer que la transaction a échoué et que toutes les modifications temporaires de la base de données sont annulées. Une transaction validée ne peut pas être annulée.

États de transaction

Une transaction peut passer par un sous-ensemble de cinq états, active, partiellement validée, validée, échouée et abandonnée.

  • Active- L'état initial dans lequel la transaction entre est l'état actif. La transaction reste dans cet état pendant qu'elle exécute des opérations de lecture, d'écriture ou d'autres opérations.

  • Partially Committed - La transaction entre dans cet état après l'exécution de la dernière instruction de la transaction.

  • Committed - La transaction entre dans cet état après la réussite de la transaction et les vérifications du système ont émis un signal de validation.

  • Failed - La transaction passe de l'état partiellement engagé ou actif à l'état d'échec lorsqu'il est découvert que l'exécution normale ne peut plus se poursuivre ou que les vérifications du système échouent.

  • Aborted - Il s'agit de l'état après que la transaction a été annulée après l'échec et que la base de données a été restaurée à son état qui était avant le début de la transaction.

Le diagramme de transition d'état suivant décrit les états de la transaction et les opérations de transaction de bas niveau qui provoquent un changement d'état.

Propriétés souhaitables des transactions

Toute transaction doit conserver les propriétés ACID, à savoir. Atomicité, cohérence, isolation et durabilité.

  • Atomicity- Cette propriété indique qu'une transaction est une unité atomique de traitement, c'est-à-dire qu'elle est effectuée dans son intégralité ou pas du tout. Aucune mise à jour partielle ne doit exister.

  • Consistency- Une transaction doit faire passer la base de données d'un état cohérent à un autre état cohérent. Il ne doit pas nuire aux éléments de données de la base de données.

  • Isolation- Une transaction doit être exécutée comme si elle était la seule du système. Il ne doit y avoir aucune interférence provenant des autres transactions simultanées qui s'exécutent simultanément.

  • Durability - Si une transaction validée entraîne une modification, cette modification doit être durable dans la base de données et non perdue en cas d'échec.

Horaires et conflits

Dans un système avec plusieurs transactions simultanées, un scheduleest l'ordre total d'exécution des opérations. Etant donné un horaire S comprenant n transactions, disons T1, T2, T3 ……… ..Tn; pour toute transaction Ti, les opérations en Ti doivent être exécutées comme prévu dans le calendrier S.

Types d'horaires

Il existe deux types d'horaires -

  • Serial Schedules- Dans un programme en série, à tout moment, une seule transaction est active, c'est-à-dire qu'il n'y a pas de chevauchement des transactions. Ceci est illustré dans le graphique suivant -

  • Parallel Schedules- Dans les programmes parallèles, plusieurs transactions sont actives simultanément, c'est-à-dire que les transactions contiennent des opérations qui se chevauchent à la fois. Ceci est illustré dans le graphique suivant -

Conflits dans les horaires

Dans un calendrier comprenant plusieurs transactions, un conflictse produit lorsque deux transactions actives effectuent des opérations non compatibles. On dit que deux opérations sont en conflit, lorsque toutes les trois conditions suivantes existent simultanément -

  • Les deux opérations font partie de transactions différentes.

  • Les deux opérations accèdent au même élément de données.

  • Au moins une des opérations est une opération write_item (), c'est-à-dire qu'elle tente de modifier la donnée.

Sérialisabilité

UNE serializable schedulede «n» transactions est un programme parallèle qui équivaut à un programme en série comprenant les mêmes «n» transactions. Une planification sérialisable contient l'exactitude de la planification série tout en garantissant une meilleure utilisation du processeur de la planification parallèle.

Équivalence des annexes

L'équivalence de deux horaires peut être des types suivants -

  • Result equivalence - Deux tableaux produisant des résultats identiques sont dits équivalents.

  • View equivalence - Deux horaires qui exécutent une action similaire de manière similaire sont dits équivalents à la vue.

  • Conflict equivalence - Deux programmes sont dits équivalents en conflit si les deux contiennent le même ensemble de transactions et ont le même ordre de paires d'opérations en conflit.