Regrouper plusieurs opérations dans une transaction
Si une modification apportée à un élément de données doit entraîner une modification d’un autre élément de données, une application doit regrouper une série de mises à jour des données. Vous pouvez utiliser des transactions pour regrouper ces mises à jour. Dans une transaction, si un événement d’une série de mises à jour échoue, la série entière peut être restaurée ou annulée.
Un détaillant en ligne qui utilise une transaction pour placer une commande, vérifier le paiement et mettre à jour le stock des produits est un exemple. Le regroupement des événements connexes garantit que vous ne réduisez pas vos niveaux de stock tant que vous n’avez pas reçu une forme approuvée de paiement.
Vous allez découvrir maintenant ce que sont les transactions et si elles sont nécessaires pour vos données.
Qu’est-ce qu’une transaction ?
Une transaction est un groupe logique d’opérations de base de données qui s’exécutent ensemble.
Voici la question que vous devez vous poser pour savoir si vous devez utiliser des transactions dans votre application : la modification d’un élément de données dans votre jeu de données affecte-t-elle un autre élément de données ? Si la réponse est oui, vous avez besoin d’une prise en charge des transactions dans votre service de base de données.
Les transactions sont souvent définies par un ensemble de quatre exigences appelées garanties ACID. ACID est l’acronyme d’atomicité, cohérence, isolation et durabilité.
- Atomicité signifie qu’une transaction doit s’exécuter exactement une fois et doit être atomique. Le travail est effectué dans sa totalité ou pas du tout. Les opérations au sein d’une transaction partagent généralement une intention commune et sont interdépendantes.
- La cohérence garantit que les données sont cohérentes à la fois avant et après la transaction.
- L’isolation garantit qu’une transaction n’est pas affectée par d’autres transactions.
- La durabilité signifie que les modifications apportées suite à une transaction sont enregistrées de manière permanente dans le système. Le système enregistre les données validées de sorte que, même en cas de défaillance et de redémarrage du système, les données soient disponibles dans un état correct.
Lorsqu’une base de données offre des garanties ACID, ces principes sont appliqués de manière cohérente à chaque transaction.
OLTP et OLAP
Les bases de données transactionnelles sont souvent appelées systèmes de traitement transactionnel en ligne (OLTP, Online Transaction Processing). Les systèmes OLTP prennent généralement en charge de nombreux utilisateurs, ont des temps de réponse rapides et gèrent de grands volumes de données. Ils sont également hautement disponibles, ce qui signifie qu’ils ont un temps d’arrêt minimal. Les systèmes OLTP gèrent généralement de petites transactions ou des transactions relativement simples.
Azure SQL Database est un exemple de service Azure qui prend en charge OLTP.
Les systèmes de traitement analytique en ligne (OLAP, Online Analytical Processing) prennent généralement en charge moins d’utilisateurs, ont des temps de réponse plus longs, peuvent être moins disponibles, et gèrent généralement des transactions volumineuses ou complexes.
Azure Analysis Services est un exemple de service Azure qui prend en charge OLAP.
Les termes OLTP et OLAP ne sont plus utilisés aussi souvent qu’avant, mais les comprendre facilite la catégorisation des besoins de votre application.
Transactions : Évaluer vos types de données
La garantie de l’état correct de vos données n’est pas toujours une tâche facile. Les transactions peuvent s’avérer utiles en appliquant des conditions d’intégrité à vos données. Si vos données tirent profit des principes ACID, choisissez une solution de stockage qui prend en charge les transactions.
Nous allons étudier chacun des jeux de données dans le scénario de vente au détail en ligne et déterminer la nécessité des transactions.
Données du catalogue de produits
Les données du catalogue de produits doivent être stockées dans une base de données transactionnelle. Quand un utilisateur passe une commande et que le paiement est vérifié, le stock de l’article doit être mis à jour. De même, si la carte de crédit du client est refusée, la commande doit être annulée et le stock ne doit pas être mis à jour. Ces relations nécessitent des transactions.
Photos et vidéos
Les photos et vidéos dans un catalogue de produits ne nécessitent pas de prise en charge transactionnelle. Ces fichiers ne sont modifiés que lorsqu’une mise à jour est effectuée ou que de nouveaux fichiers sont ajoutés. Même s’il existe une relation entre l’image et les données de produits véritables, elle n’est pas de nature transactionnelle.
Données métier
Les données métier étant historiques et ne changeant pas, la prise en charge du transactionnel n’est pas nécessaire. Les analystes métier qui travaillent avec des données ont également des besoins de requête uniques. Ils doivent souvent employer des agrégats dans leurs requêtes, afin de pouvoir utiliser les totaux d’autres points de données plus petits.