Transaction de base de données

Une transaction de base de données symbolise une unité de travail , effectuée dans un système de gestion de base de données (ou un système similaire) sur une base de données , qui est traitée de manière cohérente et fiable indépendamment des autres transactions. Une transaction représente généralement tout changement dans une base de données. Les transactions dans un environnement de base de données ont deux objectifs principaux :

1. Fournir des unités de travail fiables qui permettent une récupération correcte après une panne et maintiennent une base de données cohérente même en cas de panne du système. Par exemple : lorsque l'exécution s'arrête prématurément et de manière inattendue (complètement ou partiellement), auquel cas de nombreuses opérations sur une base de données restent inachevées, avec un statut incertain.
2. Assurer l'isolation entre les programmes accédant simultanément à une base de données. Si cette isolation n'est pas assurée, les résultats des programmes peuvent être erronés.

Dans un système de gestion de base de données, une transaction est une unité logique ou de travail unique, parfois composée de plusieurs opérations. Tout calcul logique effectué de manière cohérente dans une base de données est appelé transaction. Un exemple est un virement d'un compte bancaire à un autre : la transaction complète nécessite de soustraire le montant à transférer d'un compte et d'ajouter ce même montant à l'autre.

Une transaction de base de données, par définition, doit être atomique (elle doit être complète dans son intégralité ou n'avoir aucun effet), cohérente (elle doit être conforme aux contraintes existantes dans la base de données), isolée (elle ne doit pas affecter les autres transactions) et durable (elle doit être écrite sur un stockage persistant). Les praticiens de bases de données font souvent référence à ces propriétés des transactions de base de données en utilisant l'acronyme ACID .

Les bases de données et autres bases de données qui considèrent l' intégrité des données comme primordiale incluent souvent la capacité de gérer les transactions pour maintenir l'intégrité des données. Une transaction unique se compose d'une ou plusieurs unités de travail indépendantes, chacune lisant et/ou écrivant des informations dans une base de données ou une autre base de données. Lorsque cela se produit, il est souvent important de s'assurer que tous ces traitements laissent la base de données ou la base de données dans un état cohérent.

Les exemples de systèmes de comptabilité en partie double illustrent souvent le concept de transactions. Dans la comptabilité en partie double, chaque débit nécessite l'enregistrement d'un crédit associé. Si quelqu'un émet un chèque de 100 $ pour acheter des produits d'épicerie, un système de comptabilité transactionnelle en partie double doit enregistrer les deux écritures suivantes pour couvrir la transaction unique :

1. Débiter 100 $ sur le compte de dépenses d'épicerie
2. Créditez 100 $ sur votre compte courant

Un système transactionnel devrait faire en sorte que les deux entrées soient acceptées ou qu'elles échouent toutes les deux. En traitant l'enregistrement de plusieurs entrées comme une unité de travail transactionnelle atomique, le système préserve l'intégrité des données enregistrées. En d'autres termes, personne ne se retrouve dans une situation où un débit est enregistré mais aucun crédit associé n'est enregistré, ou vice versa.

Une base de données transactionnelle est un SGBD qui fournit les propriétés ACID pour un ensemble d'opérations de base de données entre crochets (begin-commit). Les transactions garantissent que la base de données est toujours dans un état cohérent, même en cas de mises à jour et d'échecs simultanés. Toutes les opérations d'écriture au sein d'une transaction ont un effet tout ou rien, c'est-à-dire que soit la transaction réussit et toutes les écritures prennent effet, soit, dans le cas contraire, la base de données est amenée à un état qui n'inclut aucune des écritures de la transaction. Les transactions garantissent également que l'effet des transactions simultanées satisfait certaines garanties, appelées niveau d'isolement . Le niveau d'isolement le plus élevé est la sérialisation , qui garantit que l'effet des transactions simultanées est équivalent à leur exécution en série (c'est-à-dire séquentielle).

La plupart des systèmes de gestion de bases de données relationnelles modernes prennent en charge les transactions. Les bases de données NoSQL privilégient l'évolutivité ainsi que la prise en charge des transactions afin de garantir la cohérence des données en cas de mises à jour et d'accès simultanés.

Dans un système de base de données, une transaction peut être constituée d'une ou plusieurs instructions et requêtes de manipulation de données, chacune lisant et/ou écrivant des informations dans la base de données. Les utilisateurs de systèmes de base de données considèrent la cohérence et l'intégrité des données comme très importantes. Une transaction simple est généralement envoyée au système de base de données dans un langage comme SQL , enveloppée dans une transaction, en utilisant un modèle similaire au suivant :

1. Commencer la transaction.
2. Exécuter un ensemble de manipulations de données et/ou de requêtes.
3. Si aucune erreur ne se produit, validez la transaction.
4. Si une erreur se produit, annulez la transaction.

Une opération de validation de transaction conserve tous les résultats des manipulations de données dans le cadre de la transaction dans la base de données. Une opération d'annulation de transaction ne conserve pas les résultats partiels des manipulations de données dans le cadre de la transaction dans la base de données. En aucun cas, une transaction partielle ne peut être validée dans la base de données, car cela laisserait la base de données dans un état incohérent.

En interne, les bases de données multi-utilisateurs stockent et traitent les transactions, souvent en utilisant un ID de transaction ou XID.

Il existe plusieurs façons différentes de mettre en œuvre des transactions autres que la méthode simple documentée ci-dessus. Les transactions imbriquées , par exemple, sont des transactions qui contiennent des instructions qui démarrent de nouvelles transactions (c'est-à-dire des sous-transactions). Les transactions à plusieurs niveaux sont une variante des transactions imbriquées où les sous-transactions ont lieu à différents niveaux d'une architecture système en couches (par exemple, avec une opération au niveau du moteur de base de données, une opération au niveau du système d'exploitation). Un autre type de transaction est la transaction compensatoire .

Les transactions sont disponibles dans la plupart des implémentations de bases de données SQL, mais avec des niveaux de robustesse variables. Par exemple, MySQL a commencé à prendre en charge les transactions à partir de la version 3.23, mais le moteur de stockage InnoDB n'était pas le moteur par défaut avant la version 5.5. Le moteur de stockage disponible précédemment, MyISAM, ne prend pas en charge les transactions.

Une transaction est généralement démarrée à l'aide de la commande BEGIN(bien que la norme SQL spécifie START TRANSACTION). Lorsque le système traite une COMMITinstruction, la transaction se termine avec succès. Une ROLLBACKinstruction peut également mettre fin à la transaction, annulant ainsi tout travail effectué depuis BEGIN. Si la validation automatique a été désactivée au début d'une transaction, la validation automatique sera également réactivée à la fin de la transaction.

Il est possible de définir le niveau d'isolation pour les opérations transactionnelles individuelles ainsi que globalement. Au niveau le plus élevé ( READ COMMITTED), le résultat de toute opération effectuée après le début d'une transaction restera invisible pour les autres utilisateurs de la base de données jusqu'à la fin de la transaction. Au niveau le plus bas ( READ UNCOMMITTED), qui peut être utilisé occasionnellement pour garantir une concurrence élevée, de telles modifications seront immédiatement visibles.

Les bases de données relationnelles sont traditionnellement composées de tables avec des champs et des enregistrements de taille fixe. Les bases de données objet comprennent des blobs de taille variable , éventuellement sérialisables ou incorporant un type mime . Les similitudes fondamentales entre les bases de données relationnelles et objet sont le démarrage et la validation ou la restauration .

Après le démarrage d'une transaction, les enregistrements ou objets de la base de données sont verrouillés, soit en lecture seule, soit en lecture-écriture. Des lectures et des écritures peuvent alors avoir lieu. Une fois la transaction entièrement définie, les modifications sont validées ou annulées de manière atomique , de sorte qu'à la fin de la transaction, il n'y ait aucune incohérence .

Les systèmes de bases de données implémentent des transactions distribuées en tant que transactions accédant aux données sur plusieurs nœuds. Une transaction distribuée applique les propriétés ACID sur plusieurs nœuds et peut inclure des systèmes tels que des bases de données, des gestionnaires de stockage, des systèmes de fichiers, des systèmes de messagerie et d'autres gestionnaires de données. Dans une transaction distribuée, il existe généralement une entité qui coordonne l'ensemble du processus pour garantir que toutes les parties de la transaction sont appliquées à tous les systèmes concernés. De plus, l'intégration du stockage en tant que service (StaaS) dans ces environnements est cruciale, car elle offre un pool pratiquement infini de ressources de stockage, prenant en charge une gamme de classes de magasins de données basées sur le cloud avec une disponibilité, une évolutivité et des propriétés ACID variables. Cette intégration est essentielle pour obtenir une disponibilité plus élevée, un temps de réponse plus court et une efficacité des coûts dans les applications gourmandes en données déployées dans des magasins de données basés sur le cloud

Le système de fichiers Namesys Reiser4 pour Linux prend en charge les transactions et, à partir de Microsoft Windows Vista , le système de fichiers Microsoft NTFS prend en charge les transactions distribuées sur les réseaux. Des recherches sont en cours sur des systèmes de fichiers plus cohérents en termes de données, tels que le système de fichiers transactionnel Warp (WTF).