7.2 Les bases de données actives
171
© Dunod – La photocopie non autorisée est un délit.
create trigger SUP_CLIENT
before delete on CLIENT
for each row
begin
if (select count(*) from COMMANDE
where NCLI = old.NCLI and DATECOM > '1-1-2005') > 0
then abort(); end if;
end;
Dans l’exemple suivant, le déclencheur protège les produits contre toute augmentation de prix qui dépasserait 5%.
create trigger MAJOR
before update of PRIX on PRODUIT
for each row
begin
if new.PRIX > (old.PRIX * 1.05)
then abort(); end if;
end;
7.2.3 Le contrôle de la redondance
En principe, une base de données ne devrait pas contenir de données redondantes,
c’est-à-dire dont la valeur est calculable à partir d’autres données existantes. Si de
telles données devaient malgré ce principe être introduites, alors il serait nécessaire
de prévoir les mécanismes de gestion de cette redondance de manière à garantir leur
intégrité. Admettons par exemple que nous ayons ajouté à la table DETAIL une
nouvelle colonne de nom MONTANT, dont la valeur s’obtient par définition en multipliant la quantité commandée (QCOM) par le prix unitaire (PRIX) du produit correspondant. Les valeurs de cette colonne sont manifestement des données redondantes,
qu’on peut tolérer à la condition qu’elles soient gérées de manière automatique.
Tentons une analyse sommaire afin de déterminer les déclencheurs nécessaires.
Soit D une ligne de DETAIL, P la ligne de PRODUIT telle que P.NPRO =
D.NPRO, D.QCOM la quantité commandée et P.PRIX le prix unitaire du produit. La
redondance s’exprime par la relation suivante, qui doit être vérifiée à tout instant
D.MONTANT = D.QCOM * P.PRIX
Quels sont les événements (opérations de modification) qui sont susceptibles
d’entraîner une violation de cette contrainte, et quelle est la réaction adéquate ? Il en
existe quatre :
• insert into DETAIL;
réaction : calculer MONTANT
• update DETAIL set QCOM;
réaction : recalculer MONTANT
• update DETAIL set NPRO;
réaction : recalculer MONTANT
• update PRODUIT set PRIX;
réaction : recalculer MONTANT
171
© Dunod – La photocopie non autorisée est un délit.
create trigger SUP_CLIENT
before delete on CLIENT
for each row
begin
if (select count(*) from COMMANDE
where NCLI = old.NCLI and DATECOM > '1-1-2005') > 0
then abort(); end if;
end;
Dans l’exemple suivant, le déclencheur protège les produits contre toute augmentation de prix qui dépasserait 5%.
create trigger MAJOR
before update of PRIX on PRODUIT
for each row
begin
if new.PRIX > (old.PRIX * 1.05)
then abort(); end if;
end;
7.2.3 Le contrôle de la redondance
En principe, une base de données ne devrait pas contenir de données redondantes,
c’est-à-dire dont la valeur est calculable à partir d’autres données existantes. Si de
telles données devaient malgré ce principe être introduites, alors il serait nécessaire
de prévoir les mécanismes de gestion de cette redondance de manière à garantir leur
intégrité. Admettons par exemple que nous ayons ajouté à la table DETAIL une
nouvelle colonne de nom MONTANT, dont la valeur s’obtient par définition en multipliant la quantité commandée (QCOM) par le prix unitaire (PRIX) du produit correspondant. Les valeurs de cette colonne sont manifestement des données redondantes,
qu’on peut tolérer à la condition qu’elles soient gérées de manière automatique.
Tentons une analyse sommaire afin de déterminer les déclencheurs nécessaires.
Soit D une ligne de DETAIL, P la ligne de PRODUIT telle que P.NPRO =
D.NPRO, D.QCOM la quantité commandée et P.PRIX le prix unitaire du produit. La
redondance s’exprime par la relation suivante, qui doit être vérifiée à tout instant
D.MONTANT = D.QCOM * P.PRIX
Quels sont les événements (opérations de modification) qui sont susceptibles
d’entraîner une violation de cette contrainte, et quelle est la réaction adéquate ? Il en
existe quatre :
• insert into DETAIL;
réaction : calculer MONTANT
• update DETAIL set QCOM;
réaction : recalculer MONTANT
• update DETAIL set NPRO;
réaction : recalculer MONTANT
• update PRODUIT set PRIX;
réaction : recalculer MONTANT