LEBIGDATA.FR I.A, Cloud & Cybersécurité
ACID est un acronyme résumant les quatre propriétés élémentaires d'une transaction au sein d'une base de données : Atomicité, Cohérence, Isolation, Durabilité. Découvrez la signification précise de ces propriétés.
Au sein d'une base de données, le terme de » transaction » désigne les opérations apportant des modifications aux données. Par exemple, un virement bancaire provoquant le débit du compte de l'émetteur et le crédit du compte du bénéficiaire est une transaction.
Ces transactions doivent toutefois présenter quatre propriétés visant à garantir leur validité même en cas d'erreur ou de pannes informatiques. Ces quatre propriétés sont l'atomicité, la cohérence, l'isolation et la durabilité. Afin de mémoriser facilement ces attributs, Andreas Reuter et Theo Härder ont inventé l'acronyme » ACID » en 1983.
ACID : définition de l'Atomicité d'une transaction de base de données
L'atomicité des transactions au sein des bases de données signifie que tous les changements apportés aux données sont effectués totalement, ou pas du tout. Soit tous les changements apportés par la transaction sont enregistrés pour la postérité, soit aucun ne l'est.
En outre, l'atomicité permet d'éviter que les changements prennent effet en cas de panne de l'application ou du serveur de la base de données en plein milieu de la transaction. Ainsi, la base de données ne risque pas d'être corrompue par des opérations imprévisibles et à moitié complétées.
ACID : définition de la Cohérence d'une transaction de base de données
La cohérence signifie que les transactions doivent respecter les contraintes d'intégrité des données de la base de données. Ainsi, une transaction qui commence avec un ensemble de données cohérent (respectant les contraintes d'intégrité) doit résulter par un ensemble de données cohérent.
Pour maintenir la cohérence, un système de base de données DBMS peut abandonner les transactions qui risquent de provoquer une incohérence. Précisons que cette cohérence ne s'applique pas aux étapes intermédiaires de la transaction.
Pour assurer la cohérence au fil du temps, il est possible d'utiliser une base de données temporelle. Ceci permet de spécifier les contraintes de données qui doivent traverser la dimension temporelle.
ACID : définition de l'Isolation d'une transaction de base de données
L'isolation signifie que les écritures et lectures des transactions réussies ne seront pas affectées par les écritures et lectures d'autres transactions, qu'elles soient ou non réussies. Les transactions isolées peuvent être » sérialisées « , ce qui signifie que l'état final du système peut être atteint en effectuant les transactions une par une.
Pour décrire comment l'isolation peut être atteinte, on emploie souvent les termes des transactions » optimistes » ou » pessimistes « . Dans le cas des transactions optimistes, le logiciel de gestion des transactions considère de manière générale que les autres transactions sont réussies et qu'elles ne lisent ou n'écrivent pas deux fois au même endroit. Il permet aussi les lectures et les écritures aux données modifiées par d'autres transactions. Si une transaction est avortée ou si des conflits d'ordre surviennent, les deux transactions sont annulées et réinitialisées.
Dans le cas des transactions pessimistes, les ressources sont verrouillées jusqu'à la fin de la transaction pour empêcher toute interférence. Si une transaction nécessite des ressources utilisées par une autre, elle devra patienter. Bien souvent, cette attente est inutile et entame les performances.
Il existe en outre de nombreuses approches hybrides combinant transactions optimistes et pessimistes. Ceci permet généralement de profiter des performances supérieures des transactions optimistes, et de la progression garantie des transactions pessimistes.
ACID : définition de la Durabilité d'une transaction de base de données
Enfin, la durabilité garantit que les transactions réussies survivront de façon permanente et ne seront pas affectées par d'éventuelles pannes ou problèmes techniques. Les changements apportés aux données doivent être permanents. Plus précisément, ce sont les effets logiques des données modifiées sur les futures transactions qui doivent être permanents.
La simple écriture des données sur le disque ne suffit pas pour atteindre la durabilité. Pour cause, le disque peut par exemple tomber en panne. Il est nécessaire que le DBMS écrive des logs sur les changements effectués. Ces logs doivent être permanents, et éventuellement redondants.
En cas de panne du disque, de l'OS ou du DBMS, la base de données sera redémarrée et le DBMS pourra vérifier si les données sont synchronisées avec les logs. En effet, les logs contiennent les effets de toutes les transactions effectuées. Ce n'est pas forcément le cas des fichiers de données. Si des informations sont manquantes, les opérations enregistrées dans les logs seront à nouveau effectuées.
Restez à la pointe de l'information avec LEBIGDATA.FR !
Abonnez-vous à notre chaîne YouTube et rejoignez-nous sur Google Actualités pour garder une longueur d'avance.
- Partager l'article :
