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

4
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.

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