5.8 Modification des données
117
© Dunod – La photocopie non autorisée est un délit.
5.8.3 Modification de lignes
Ici encore, la modification sera effectuée sur toutes les lignes qui vérifient une
condition de sélection :
update CLIENT
set
ADRESSE = '29, av. de la Magne',
LOCALITE = 'Niort'
where NCLI = 'F011'
Les nouvelles valeurs peuvent être obtenues par une expression arithmétique. La
commande suivante enregistre une augmentation de prix de 5% pour les produits en
sapin :
update PRODUIT
set
PRIX = PRIX * 1.05
where LIBELLE like '%SAPIN%'
Elles peuvent également provenir de la base de données elle-même. La requête cidessous déduit de la quantité en stock de chaque produit la somme des quantités
actuellement en commande.
update PRODUIT P
set
QSTOCK = QSTOCK - (select sum(QCOM)
from
DETAIL
where NPRO = P.NPRO)
where exists (select * from DETAIL where NPRO = P.NPRO)
On notera l’usage de l’alias de table P dans la clause update, qui permet de relier
des détails au produit en cours de modification. La condition de sélection "exists
(select NPRO from DETAIL)" est nécessaire pour éviter une destruction des
données. En effet, pour un produit P qui n’a pas de détails :
• l’ensemble DETAIL where NPRO = P.NPRO est vide;
• l’expression sum(QCOM) appliquée à un ensemble vide renvoie null;
• l’expression QSTOCK - null vaut null;
• et donc la valeur de la colonne QSTOCK de P est détruite !
5.8.4 Mise à jour et contraintes référentielles
a) Principes
Une requête de modification du contenu de la base de données (insert, delete,
update) ne sera exécutée que si le résultat respecte toutes les contraintes d’intégrité
définies sur cette base. L’impact de ces contraintes sur le comportement des données
en cas de mise à jour a été décrit dans la section 3.8, et est garanti par tous les SGBD
relationnels. Le principe de base est qu’une opération dont l’exécution va laisser les
données dans un état invalide est refusée. Cependant, comme nous l’avons déjà
117
© Dunod – La photocopie non autorisée est un délit.
5.8.3 Modification de lignes
Ici encore, la modification sera effectuée sur toutes les lignes qui vérifient une
condition de sélection :
update CLIENT
set
ADRESSE = '29, av. de la Magne',
LOCALITE = 'Niort'
where NCLI = 'F011'
Les nouvelles valeurs peuvent être obtenues par une expression arithmétique. La
commande suivante enregistre une augmentation de prix de 5% pour les produits en
sapin :
update PRODUIT
set
PRIX = PRIX * 1.05
where LIBELLE like '%SAPIN%'
Elles peuvent également provenir de la base de données elle-même. La requête cidessous déduit de la quantité en stock de chaque produit la somme des quantités
actuellement en commande.
update PRODUIT P
set
QSTOCK = QSTOCK - (select sum(QCOM)
from
DETAIL
where NPRO = P.NPRO)
where exists (select * from DETAIL where NPRO = P.NPRO)
On notera l’usage de l’alias de table P dans la clause update, qui permet de relier
des détails au produit en cours de modification. La condition de sélection "exists
(select NPRO from DETAIL)" est nécessaire pour éviter une destruction des
données. En effet, pour un produit P qui n’a pas de détails :
• l’ensemble DETAIL where NPRO = P.NPRO est vide;
• l’expression sum(QCOM) appliquée à un ensemble vide renvoie null;
• l’expression QSTOCK - null vaut null;
• et donc la valeur de la colonne QSTOCK de P est détruite !
5.8.4 Mise à jour et contraintes référentielles
a) Principes
Une requête de modification du contenu de la base de données (insert, delete,
update) ne sera exécutée que si le résultat respecte toutes les contraintes d’intégrité
définies sur cette base. L’impact de ces contraintes sur le comportement des données
en cas de mise à jour a été décrit dans la section 3.8, et est garanti par tous les SGBD
relationnels. Le principe de base est qu’une opération dont l’exécution va laisser les
données dans un état invalide est refusée. Cependant, comme nous l’avons déjà