Cette séquence aborde les mises à jour sur des données

Cette séquence aborde les mises à jour sur des données persistantes.
Outre les spécificités de SQL dédiées aux mises à jour, la problématique
essentielle des mises à jour que nous allons examiner ici n’est pas tant la
performance d’exécution que l’intégrité.
En effet, dans un contexte de volume très important des données, la vérification
de cette intégrité ne peut être faite par l’utilisateur. De même, la prise en compte
de ces contraintes par les programmes manipulant ces données est
particulièrement complexe et risquée. Il s’agit donc dans cette séquence
d’identifier les sources possible de violation de cette intégrité, afin de mettre en
place des méthodes pour y remédier.
Ces problèmes sont abordés dans le cadre formel des transactions, mécanisme sur
lequel nous passerons une partie de cette séquence, et qui sera approfondi
également dans une séquence ultérieure.
A noter que, concernant les performances, un travail de longue haleine a été fait
par le Transaction Processing Performance Council (TPC : http://www.tpc.org),
d'abord dans un contexte purement transactionnel, puis plus récemment dans le
contexte des entrepôts de données.
1
Définition de la transaction
Les mises à jour sont typiquement des requêtes SQL modifiant les données…
2
Les transactions sont souvent connues via l’acronyme résumant leurs
caractéristiques attendues : ACID.
3
D’un point de vue syntaxe, On valide ou on abandonne une transaction via les
commandes SQL Commit ou Rollback.
De même, une syntaxe est proposée pour définir les contraintes.
On distingue couramment 4 types de contraintes :
-Les contraintes sur valeur d’attribut, dont on pourrait voir la contrainte de non
nullité comme un cas particulier, parce qu’elle se déclare de manière toute à fait
spécifique.
- les contraintes spécifiques aux bases relationnelles sont les contraintes de clés
primaires ou de clés étrangères qui correspondent aux colonnes qui supportent
généralement les jointures.
4
On imagine aisément que la modification au sein d’une même transaction à la
fois des schémas et des données soit difficile à gérer pour le système. Sous Oracle
comme sous nombre de SGBDR, toute modification du schéma termine la
transaction précédemment démarrée.
5
Passons très rapidement sur la syntaxe SQL des mises à jour de données en tant
que telle. Attention à bien distinguer la mise à jour des données, de la mise à jour
du schéma de données qui inclut l’ajout d’une colonne dans une table, la création
de vues, la définition des contraintes d’intégrité, par exemple.
Les commande de référence pour la modification des données sont insert, delete
et update alors que leur équivalent pour la modification de schéma sont
respectivement create, drop ou alter (table, view, index, etc ).
La commande d’insertion nous donne l’occasion de rappeler l’aspect ensembliste
du langage (aussi perceptible dans la présentation de l’algèbre relationnelle).
L’insertion consiste à ajouter des lignes (des tuples) dans un tableau (une
relation). Mais tandis que dans la première requête, on donne précisément les
valeurs insérées dans la table, on insère dans la deuxième requête un ensemble de
lignes qui résultent d’une sous-requête.
De même, la requête de suppression (commande delete) illustre la sémantique
orientée logique de SQL : on identifie les tuples à détruire par leurs
caractéristiques (ici, la valeur de son attribut id).
Même chose pour la requête en modification qui s’applique encore à un ensemble
de tuples, ce qui remplacerait dans un langage de programmation classique
6
l’utilisation d’un itérateur..
6
L’atomicité est la première propriété d’ACID. Elle consiste à garantir que
l’ensemble des mises à jour d’une transaction est exécutée complètement ou pas
du tout.
En centralisé, l’atomicité est le plus souvent mise en œuvre via des techniques de
journalisation. Le principe est de stocker dans un journal (écrit sur le disque, et
donc résistant à un plantage soft) la trace de ce qui a été fait pendant la
transaction.
Les deux méthodes les plus courantes sont les suivantes.
A gauche, on inscrit dans le journal toutes les modifications réalisées mais on
attend l’ordre de validation pour appliquer ces mises à jour dans la base. Lors de
la validation d’une transaction, on inscrit dans le journal l’information et on
démarre l’application des mises à jour. En cas de problème pendant cette phase, il
suffit de reprendre dans le journal les transactions marquées comme validées et
les mises à jour non encore appliquées. Cette méthode est avantageuse quand il y
a beaucoup de transactions abandonnées car dans ce cas, il n’y a rien à faire dans
la base et juste à indiquer dans le journal l’abandon de la transaction.
A droite, la méthode est inverse. On applique les modifications dans la base et on
en garde une trace dans le journal qui n’est utilisé qu’en cas d’abandon de
transaction. En cas de validation, il n’y a rien à faire parce que la BD est déjà à
jour.
7
La cohérence est la deuxième caractéristique des transactions.
Une question pertinente à propos de la cohérence est de savoir à quel moment on
vérifie les contraintes, au cours de la transaction ou à la fin.
La définition de la transaction nous donne un élément de réponse : l’exigence de
cohérence est au début et à la fin d’une transaction, pas au milieu. Il n’y a donc
pas besoin de vérifier l’intégrité pendant la transaction.
Pour des raisons d’efficacité, on est tenté de faire les vérification d’intégrité le
plus tôt possible pour éviter de prolonger une transaction qui serait
manifestement incohérente.
Il existe pourtant des cas où la vérification immédiate des contraintes est
impossible. Par exemple, prenons le schéma personne-service (1 personne est
membre d’un service qui est lui-même dirigé par une personne). Supposons que
les contraintes sont telles qu’une personne est forcément dans un service (la
relation personne a un attribut serv_ref qui est non nul et qui référence un
service), et qu’un service a forcément un chef qui est une personne, ce qui
implique la présence dans Service d’un attribut Chief_ref non nul avec contrainte
référentielle vers personne. Alors, la création de la première personne
(respectivement du premier service) ne peut se faire que si la vérification d’une
des contraintes de clés référentielles est différée.
8
L’isolation est la troisième propriété représentée dans ACID. L’isolation désigne
le fait qu’un utilisateur des données doit pouvoir y accéder sans prendre en
compte le fait que d’autres utilisateurs soient potentiellement au même moment
en train de manipuler ces données.
L’isolation sera traitée plus en détail dans le TP dédié aux transactions et dans
une séquence de cours spécifique.
9
Enfin, la dernière propriété présente dans ACID est la Durabilité, c’est-à-dire le
fait que les effets d’une transaction validée ne sont jamais perdus.
Nous avons vu que les techniques liées à l’atomicité permettait de prendre en
compte les pannes soft. Nous sommes donc ici plutôt dans une situation de panne
disque plus ou moins critique. Cela va de la perte d’un disque à la perte de
l’ensemble des supports permanents (incendie d’un immeuble).
Nous n’examinerons pas dans ces séquences les solutions existantes. Certaines
d’entre elles se sont popularisées dans des outils grands publics tels que les NAS
(RAID 0 à 5), qui gèrent la duplication et la répartition de données sur les disques
pour être capable de résister à 1, 2 ou davantage de pannes disques. Il y a eu dans
le passé quelques événements célèbres où des hébergeurs connus ont rencontrés
des pannes plus graves que celles auxquelles ils étaient préparés. On repart alors
de backup avec évidemment des pertes de données. Le préjudice vis-à-vis des
clients peut être très important.
10
En conclusion, le cadre transactionnel traite une grande part des problématiques
de mise à jour.
En revanche, certaines caractéristiques du modèle relationnel (l’abstraction par
les vues) se comportent moins bien, alors même qu’elles seraient essentielles
pour préciser les modalités de contrôle d’accès sur les données de la base.
Ce cours peut être approfondi sur 3 des caractéristiques d’ACID :
-Concernant l’atomicité, le contexte distribué permet d’étudier des
problématiques intéressantes et des solutions connues sous le nom de « validation
deux phases » (ou two phase commit).
-Concernant la cohérence, la séquence sur les clés primaires est incontournable,
d’autant qu’elle est nécessaire pour comprendre une autre séquence de cours
dédiées à la structuration des données (théorie de la normalisation)
-Concernant l’Isolation, la séquence sur la sérialisabilité et les différentes
approches pour la garantir complète lle TP transaction dédié à la même
problématique.
11