Table des matières
Vous trouverez les réponses des exercices au Chapitre 15, Réponses aux exercices sur modification de base, etc..
L'utilisateur qui a créé les tables a tous les droits sur ces tables. Si rien n'est précisé aucun autre utilisateur ne peut faire la moindre modification sur les tables (contenu ou structure). Ce qui fait que vous ne pourrez tester les commandes de ce chapitre que sur une base de données que vous aurez créée personnellement (voir Chapitre 7, Créer votre propre base).
On étudiera plus tard (Chapitre 9, Les droits) la possibilité de donner (ou enlever) aux autres utilisateurs les droits de modifier la base de données.
Le principe de base des transactions est de grouper un ensemble de commandes de façon à être sûr que TOUTES les commandes seront exécutées, ou sinon qu'AUCUNE ne sera exécutée.
Dans quel but ? Pour pouvoir résoudre un certain de problèmes différents. Par exemple :
Imaginez une transaction bancaire : la banque doit débiter un compte pour en créditer un autre. Facile à réaliser avec deux commandes UPDATE. Mais que faire si une fois la première commande exécutée, on se rend compte que la deuxième ne peut pas l'être ? Il faut annuler la première. Regrouper les deux commandes dans une transaction permet d'automatiser ce comportement : si tout se passe bien les deux se feront, si un quelconque problème survient aucune ne se fera.
D'une manière plus générale, une suite de commandes quelconques qui entraîne des modifications de la base ne doit surtout pas être arrêtée en plein milieu, ce qui risquerait de laisser la base dans un état inconsistant. Une transaction transforme cette suite de commandes en un ensemble insécable (on dira aussi atomique) : ou TOUT se fait, ou RIEN ne sera fait.
Les transactions permettent aussi de gérer les accès concurrents dans une base en réseau : si deux (ou plus) utilisateurs utilisent en même temps la même base pour exécuter chacun une série de commandes du style :
commande1 : recherche d'une information dans une table (par exemple : calcul d'un stock disponible) ;
commande2 : modification de la table en fonction de l'information reçue (par exemple retrait d'un certain nombre d'articles dans la limite du stock diponible).
Dans ce cas rien ne permet de supposer que tout se passera bien. Il est tout à fait possible que la séquence de commandes de déroule de la façon suivante : commande1 pour le premier client, puis commande1 pour le deuxième client, puis commande2 pour le premier client, puis commande2 pour le deuxième client.
Dans ce cas la commande2 du deuxième client a toutes les chances d'entraîner des erreurs car elle est basée sur un résultat calculé avant l'exécution de la commande2 du premier client.
L'utilisation de transaction transforme chaque suite (commande1, commande2) en un bloc non interruptible (atomique) qui assure que l'information du deuxième ne sera fournie que quand le premier aura modifié la table.
Enfin il peut être utile de se ménager une porte de sortie quand on exécute une commande modifiant la table : on peut se tromper, changer d'avis, vouloir seulement faire un essai, etc. Il est toujours utile de disposer de l'équivalent du undo de la plupart des logiciels.
La seule solution est alors d'utiliser une transaction : une fois les commandes exécutées, on peut décider de tout abandonner (comme pour un undo) ou au contraire d'accepter tout.
Vous pourrez trouver d'autre explications sur l'utilité des transactions dans les pages suivantes :
Une transaction commence par « BEGIN ; » :
Si elle se termine par « ROLLBACK ; », aucune des modifications faites ne sera prise ne compte.
Si elle se termine par « COMMIT ; », toutes les modifications sont prises en compte.
Ne pas taper « BEGIN ; » avant de commencer vos modifications revient à taper chacune de vos commandes en mode autocommit : chaque instruction isolée est une transaction en elle-même, une fois tapée elle est exécutée comme si elle était précédée d'un « BEGIN ; » et suivie d'un « COMMIT ; », et elle ne peut plus être défaite.
Toutes les commandes qui vont suivre dans ce chapitre vont modifier votre base de données. Nul n'est à l'abri d'une erreur, il vous est donc fortement conseillé d'inclure vos commandes dans des transactions, pour vous permettre d'annuler éventuellement toute fausse manœuvre.
Dans notre cas il ne se produira rien de castrophique : cette base n'a pas d'importance vitale, et si vous y faites des erreurs, il vous reste toujours la possibilité de la recréer complétement (Chapitre 7, Créer votre propre base).
Dans la vraie vie c'est rarement le cas. C'est donc une bonne habitude à prendre...