282
Chapitre 11 • Production du schéma de la base de données
procédures SQL (section 6.5). Nous illustrerons ce processus par la traduction de
quelques contraintes reprises de la section 9.5.
a) Contraintes statiques
Les deux contraintes
• il existe quatre valeurs de catégories de clients : B1, B2, C1, C2;
• un client ne peut être de catégorie C2 que si son compte est non négatif;
s’expriment aisément par deux prédicats (on observe que la seconde contrainte est
une implication, qui se traite comme décrit en 5.2.6) :
create table CLIENT( ...
primary key(NUMCLI),
check(CAT is null or CAT in ('B1','B2','C1','C2')),
check(CAT<>'C2' or CAT is null 4 or COMPTE >= 0));
Cependant, la contrainte
• toute commande doit avoir au moins un détail;
est plus complexe à traduire, car elle ne peut être prise en charge ni par des prédicats
ni par des déclencheurs, mais par des procédures SQL. Elle correspond à la situation décrite ci-dessous (cardinalité 1-N, section 11.10.2). En outre, la procédure
SUP_DETAIL de la section 6.5 gère l’opération de suppression d’un détail.
b) Contraintes dynamiques
Nous considérerons la contrainte :
• on ne peut ajouter de détails qui référencent un produit en rupture de stock.
Elle doit être validée lors de deux événements distincts : l’insertion d’une ligne de
DETAIL et la modification de NPRO d’une ligne de DETAIL. Le mécanisme de
traduction qui s’impose est un déclencheur :
create trigger INS_DETAIL_STK_0
before insert or update of NPRO on DETAIL
for each row
begin
if (select QSTOCK from PRODUIT where NPRO=new.NPRO) <= 0
then abort();
end;
Ce dispositif annule (abort) toute opération d’insertion ou de modification de
NPRO qui entraînerait une violation de la contrainte.
4. Attention, en logique ternaire, not(CAT = 'C2') n’est pas (CAT <> 'C2') mais (CAT
<> 'C2' or CAT is null).
Chapitre 11 • Production du schéma de la base de données
procédures SQL (section 6.5). Nous illustrerons ce processus par la traduction de
quelques contraintes reprises de la section 9.5.
a) Contraintes statiques
Les deux contraintes
• il existe quatre valeurs de catégories de clients : B1, B2, C1, C2;
• un client ne peut être de catégorie C2 que si son compte est non négatif;
s’expriment aisément par deux prédicats (on observe que la seconde contrainte est
une implication, qui se traite comme décrit en 5.2.6) :
create table CLIENT( ...
primary key(NUMCLI),
check(CAT is null or CAT in ('B1','B2','C1','C2')),
check(CAT<>'C2' or CAT is null 4 or COMPTE >= 0));
Cependant, la contrainte
• toute commande doit avoir au moins un détail;
est plus complexe à traduire, car elle ne peut être prise en charge ni par des prédicats
ni par des déclencheurs, mais par des procédures SQL. Elle correspond à la situation décrite ci-dessous (cardinalité 1-N, section 11.10.2). En outre, la procédure
SUP_DETAIL de la section 6.5 gère l’opération de suppression d’un détail.
b) Contraintes dynamiques
Nous considérerons la contrainte :
• on ne peut ajouter de détails qui référencent un produit en rupture de stock.
Elle doit être validée lors de deux événements distincts : l’insertion d’une ligne de
DETAIL et la modification de NPRO d’une ligne de DETAIL. Le mécanisme de
traduction qui s’impose est un déclencheur :
create trigger INS_DETAIL_STK_0
before insert or update of NPRO on DETAIL
for each row
begin
if (select QSTOCK from PRODUIT where NPRO=new.NPRO) <= 0
then abort();
end;
Ce dispositif annule (abort) toute opération d’insertion ou de modification de
NPRO qui entraînerait une violation de la contrainte.
4. Attention, en logique ternaire, not(CAT = 'C2') n’est pas (CAT <> 'C2') mais (CAT
<> 'C2' or CAT is null).