136
Chapitre 6 • SQL avancé
6.2.5 Les vues comme mécanisme d’évolution de la base de données
Les vues permettent de protéger un utilisateur de l’effet de modifications de la structure de la base de données. Dans ce dernier cas, une modification de la requête définissant la vue permet d’offrir à l’utilisateur une perception inchangée des données.
Imaginons que la table CLIENT soit désormais décomposée en deux nouvelles
tables, l’une qui reprend les données signalétiques SIG_CLIENT(NCLI, NOM,
ADRESSE, LOCALITE) et la seconde partie qui ne reprend que les données commerciales COM_CLIENT(NCLI, CAT, COMPTE). Par une vue définie comme la jointure de ces deux tables, on reconstitue la table CLIENT d’origine, certes désormais
virtuelle, mais tout-à-fait opérationnelle.
6.2.6 Les vues comme aide à l’expression de requêtes complexes
Les vues permettent également l’expression de requêtes complexes difficiles ou
impossibles à rédiger directement sous la forme SFW en SQL2. Par exemple, le
calcul de la valeur globale des stocks, déduction faite des quantités commandées,
s’obtiendra comme suit :
create view VAL_STOCK(STOCK,VALEUR) as
select P.NPRO, (QSTOCK - sum(D.QCOM))*PRIX
from
DETAIL D, PRODUIT P
where D.NPRO = P.NPRO
group by P.NPRO, QSTOCK, PRIX
select sum(VALEUR)
from
VAL_STOCK
6.2.7 Mise à jour des données via une vue
On sait qu’une vue est considérée comme une table de base pour ce qui concerne les
requêtes d’extraction. Il en ira de même en ce qui concerne les requêtes de modification, pour autant que le SGBD soit capable de propager les modifications vers les
tables de base. En effet, certaines vues ne reprennent pas les informations qui
permettraient d’identifier les lignes des tables de base à modifier : que signifierait
par exemple la modification de LOCALITE d’une ligne de la vue
HABITUDE_ACHAT construite à la section 6.2.2 ? On conçoit aisément qu’on ne
puisse supprimer une ligne d’une table dont l’identifiant primaire n’est pas repris
dans la vue, ou insérer une ligne via une vue qui ne reprendrait pas certaines
colonnes obligatoires 4 .
Les principales restrictions qui rendent une vue modifiable (c’est-à-dire pouvant
faire l’objet d’insert, delete, update) sont les suivantes. Considérons d’abord
une vue définie sur une seule table (ou vue). Les conditions de modifiabilité sont les
suivantes :
4. A moins que celles-ci ne disposent d’une valeur par défaut, ou qu’un trigger before (Chapitre
5) ne garnisse ces colonnes.
Chapitre 6 • SQL avancé
6.2.5 Les vues comme mécanisme d’évolution de la base de données
Les vues permettent de protéger un utilisateur de l’effet de modifications de la structure de la base de données. Dans ce dernier cas, une modification de la requête définissant la vue permet d’offrir à l’utilisateur une perception inchangée des données.
Imaginons que la table CLIENT soit désormais décomposée en deux nouvelles
tables, l’une qui reprend les données signalétiques SIG_CLIENT(NCLI, NOM,
ADRESSE, LOCALITE) et la seconde partie qui ne reprend que les données commerciales COM_CLIENT(NCLI, CAT, COMPTE). Par une vue définie comme la jointure de ces deux tables, on reconstitue la table CLIENT d’origine, certes désormais
virtuelle, mais tout-à-fait opérationnelle.
6.2.6 Les vues comme aide à l’expression de requêtes complexes
Les vues permettent également l’expression de requêtes complexes difficiles ou
impossibles à rédiger directement sous la forme SFW en SQL2. Par exemple, le
calcul de la valeur globale des stocks, déduction faite des quantités commandées,
s’obtiendra comme suit :
create view VAL_STOCK(STOCK,VALEUR) as
select P.NPRO, (QSTOCK - sum(D.QCOM))*PRIX
from
DETAIL D, PRODUIT P
where D.NPRO = P.NPRO
group by P.NPRO, QSTOCK, PRIX
select sum(VALEUR)
from
VAL_STOCK
6.2.7 Mise à jour des données via une vue
On sait qu’une vue est considérée comme une table de base pour ce qui concerne les
requêtes d’extraction. Il en ira de même en ce qui concerne les requêtes de modification, pour autant que le SGBD soit capable de propager les modifications vers les
tables de base. En effet, certaines vues ne reprennent pas les informations qui
permettraient d’identifier les lignes des tables de base à modifier : que signifierait
par exemple la modification de LOCALITE d’une ligne de la vue
HABITUDE_ACHAT construite à la section 6.2.2 ? On conçoit aisément qu’on ne
puisse supprimer une ligne d’une table dont l’identifiant primaire n’est pas repris
dans la vue, ou insérer une ligne via une vue qui ne reprendrait pas certaines
colonnes obligatoires 4 .
Les principales restrictions qui rendent une vue modifiable (c’est-à-dire pouvant
faire l’objet d’insert, delete, update) sont les suivantes. Considérons d’abord
une vue définie sur une seule table (ou vue). Les conditions de modifiabilité sont les
suivantes :
4. A moins que celles-ci ne disposent d’une valeur par défaut, ou qu’un trigger before (Chapitre
5) ne garnisse ces colonnes.