Cela comprend donc :
la création et suppression de bases de données : CREATE DATABASE, DROP DATABASE ;
la création, modification, suppression de tables : CREATE TABLE, ALTER TABLE, RENAME TABLE, DROP TABLE ;
la création, modification, suppression d'index : CREATE INDEX, DROP INDEX ;
la création d'objets comme les procédures stockées, les vues, etc., dont nous parlerons plus tard.
De manière générale, tout ce qui influe sur la structure de la base de données, et non sur les données elles-mêmes.
Utilisateurs
La création, la modification et la suppression d'utilisateurs (voir partie 7) provoquent aussi une validation implicite.
Transactions et verrous
Je vous ai signalé qu'il n'était pas possible d'imbriquer des transactions, donc d'avoir une transaction à l'intérieur d'une
transaction. En fait, la commande START TRANSACTION provoque également une validation implicite si elle est exécutée à
l'intérieur d'une transaction.
Le fait d'activer le mode autocommit (s'il n'était pas déjà activé) a le même effet.
La création et suppression de verrous de table clôturent aussi une transaction en la validant implicitement (voir chapitre
suivant).
Chargements de données
Enfin, le chargement de données avec LOAD DATA provoque également une validation implicite.
ACID
Derrière ce titre mystérieux se cache un concept très important !
Quels sont les critères qu'un système utilisant les transactions doit respecter pour être fiable ?
Il a été défini que ces critères sont au nombre de quatre : Atomicité, Cohérence, Isolation et Durabilité. Soit, si on prend la
première lettre de chaque critère : ACID.
Voyons donc en détail ces quatre critères.
A pour Atomicité
Atome signifie étymologiquement "qui ne peut être divisé".
Une transaction doit être atomique, c'est-à-dire qu'elle doit former une entité complète et indivisible. Chaque élément de la
transaction, chaque requête effectuée, ne peut exister que dans la transaction.
Si l'on reprend l'exemple du virement bancaire, en utilisant les transactions, les deux étapes (débit du compte donneur d'ordre,
crédit du compte bénéficiaire) ne peuvent exister indépendamment l'une de l'autre. Si l'une est exécutée, l'autre doit l'être
également. Il s'agit d'un tout.
Peut-on dire que nos transactions sont atomiques ?
Oui. Si une transaction en cours est interrompue, aucune des requêtes exécutées ne sera validée. De même, en cas d'erreur, il
suffit de faire un ROLLBACK pour annuler toute la transaction. Et si tout se passe bien, un COMMIT validera l'intégralité de la
transaction en une fois.
C pour cohérence
Les données doivent rester cohérentes dans tous les cas : que la transaction se termine sans encombre, qu'une erreur survienne,
ou que la transaction soit interrompue. Un virement dont seule l'étape de débit du donneur d'ordre est exécutée produit des
données incohérentes (la disparition de 300 euros jamais arrivés chez le bénéficiaire). Avec une transaction, cette incohérence
Partie 5 : Sécuriser et automatiser ses actions
228/414
www.openclassrooms.com
la création et suppression de bases de données : CREATE DATABASE, DROP DATABASE ;
la création, modification, suppression de tables : CREATE TABLE, ALTER TABLE, RENAME TABLE, DROP TABLE ;
la création, modification, suppression d'index : CREATE INDEX, DROP INDEX ;
la création d'objets comme les procédures stockées, les vues, etc., dont nous parlerons plus tard.
De manière générale, tout ce qui influe sur la structure de la base de données, et non sur les données elles-mêmes.
Utilisateurs
La création, la modification et la suppression d'utilisateurs (voir partie 7) provoquent aussi une validation implicite.
Transactions et verrous
Je vous ai signalé qu'il n'était pas possible d'imbriquer des transactions, donc d'avoir une transaction à l'intérieur d'une
transaction. En fait, la commande START TRANSACTION provoque également une validation implicite si elle est exécutée à
l'intérieur d'une transaction.
Le fait d'activer le mode autocommit (s'il n'était pas déjà activé) a le même effet.
La création et suppression de verrous de table clôturent aussi une transaction en la validant implicitement (voir chapitre
suivant).
Chargements de données
Enfin, le chargement de données avec LOAD DATA provoque également une validation implicite.
ACID
Derrière ce titre mystérieux se cache un concept très important !
Quels sont les critères qu'un système utilisant les transactions doit respecter pour être fiable ?
Il a été défini que ces critères sont au nombre de quatre : Atomicité, Cohérence, Isolation et Durabilité. Soit, si on prend la
première lettre de chaque critère : ACID.
Voyons donc en détail ces quatre critères.
A pour Atomicité
Atome signifie étymologiquement "qui ne peut être divisé".
Une transaction doit être atomique, c'est-à-dire qu'elle doit former une entité complète et indivisible. Chaque élément de la
transaction, chaque requête effectuée, ne peut exister que dans la transaction.
Si l'on reprend l'exemple du virement bancaire, en utilisant les transactions, les deux étapes (débit du compte donneur d'ordre,
crédit du compte bénéficiaire) ne peuvent exister indépendamment l'une de l'autre. Si l'une est exécutée, l'autre doit l'être
également. Il s'agit d'un tout.
Peut-on dire que nos transactions sont atomiques ?
Oui. Si une transaction en cours est interrompue, aucune des requêtes exécutées ne sera validée. De même, en cas d'erreur, il
suffit de faire un ROLLBACK pour annuler toute la transaction. Et si tout se passe bien, un COMMIT validera l'intégralité de la
transaction en une fois.
C pour cohérence
Les données doivent rester cohérentes dans tous les cas : que la transaction se termine sans encombre, qu'une erreur survienne,
ou que la transaction soit interrompue. Un virement dont seule l'étape de débit du donneur d'ordre est exécutée produit des
données incohérentes (la disparition de 300 euros jamais arrivés chez le bénéficiaire). Avec une transaction, cette incohérence
Partie 5 : Sécuriser et automatiser ses actions
228/414
www.openclassrooms.com