SQL avancé
6.2 LES VUES SQL
© Dunod – La photocopie non autorisée est un délit.
on COMPTA01 to S_FINANCIERS with grant option d) Autres privilèges
Il existe d'autres privilèges liés notamment à l'administration de la base de données, en particulier à la définition et à la modification de structures de données : create table, altertable, drop index.
e) Suppression des privilèges
L'ordre revoke permet de retirer un privilège préalablement accordé : revoke update(PRIX)
on PRODUIT to P_MERCIER revoke run
on COMPTA01 from P_MERCIER
L’effet de cette opération peut être délicat à interpréter. Par exemple, lorsqu’un même privilège a été accordé à un utilisateur U par plusieurs utilisateurs indépen-dants, alors U dispose de ce privilège tant que chacun de ces utilisateurs ne le lui aura pas retiré.
Il est possible de retirer la faculté de transmettre un privilège par une commande telle que :
revoke grant option for update (COMPTE) on CLIENT
from P_MERCIER
Que se passe-t-il si P_MERCIER avait déjà transmis ce privilège ? Deux stratégies sont proposées : ou bien P_MERCIER conserve cette faculté de transmission (mode restrict) ou bien les privilèges qu’il a transmis sont retirés (mode cascade).
On trouvera dans [Melton, 1999] une présentation intuitive des principales règles de propagation des privilèges et de leur retrait.
6.2 LES VUES SQL
Les données sont en principe perçues selon leur organisation en tables et colonnes telles qu’elles ont été définies jusqu’ici. Il est cependant possible d’offrir aux utilisa-teurs une présentation différente de ces mêmes données via la notion de vue rela-tionnelle.
6.2.1 Principe et objectif des vues
Une vue correspond à une table virtuelle dont seule la définition, sous la forme d’une requête SFW, est stockée et non le contenu. Une requête SQL peut extraire des données de tables réelles (stockées dans la base) ou virtuelles (vues). Il est même possible sous certaines conditions de modifier les données d’une vue (c’est-à-dire d’ajouter, supprimer, modifier des lignes). Dans ce cas le SGBD répercute sur les données réelles les modifications demandées. D’une manière générale on considé-rera qu’une vue peut être utilisée comme une table réelle.
6.2.2 Définition et utilisation d’une vue
Une vue est définie par une requête SQL qui spécifie son nom, celui de ses colonnes et la requête SFW qui calcule ses lignes2 :
create view COM_COMPLETE(NCOM,NCLI,NOMCLI,LOC,DATECOM) as select NCOM,COM.NCLI,NOM,LOCALITE,DATECOM
from CLIENT CLI,COMMANDE COM where COM.NCLI = CLI.NCLI
La vue COM_COMPLETE peut être utilisée comme une table ordinaire. Les requêtes suivantes sont dès lors tout à fait valides :
select NOMCLI,NCOM,DATECOM from COM_COMPLETE
where LOC = 'Toulouse' select NPRO
from DETAIL
where NCOM in ( select NCOM
from COM_COMPLETE
where LOC = 'Toulouse') select LOC, count(*)
from COM_COMPLETE CC, DETAIL D where CC.NCOM = D.NCOM
group by LOC
Lorsqu’une requête utilise une vue, le SGBD reformule cette requête en y rempla-çant les éléments de la vue par leur définition, puis l’exécute3. C’est ainsi que la première requête est d’abord reformulée comme suit, avant d’être exécutée :
select NOM,NCOM,DATECOM
from CLIENT CLI,COMMANDE COM where COM.NCLI = CLI.NCLI and LOC = 'Toulouse'
2. La notion de vue n’existe pas en MS Access, mais le nom d’un objet requête de type SFW peut apparaître dans la clause from d’une autre requête.
3. La réalité est un peu plus complexe, mais ce modèle est suffisant pour nos besoins.
6.2 Les vues SQL 135
© Dunod – La photocopie non autorisée est un délit.
Une vue peut être supprimée par l’instruction DROP : drop view COM_COMPLETE
Cette opération ne supprime pas les données décrites par COM_COMPLETE. Elle interdit simplement d’y accéder selon cette vue. Seules les instructions droptable et delete permettent de supprimer des données.
6.2.3 Les vues comme interface pour des besoins particuliers
Le but d’une vue est avant tout d’offrir à un utilisateur de la base de données une présentation des données qui soit adaptée à ses besoins, et qui lui évite, d’une part, la complexité d’une base de données dont seules quelques données lui sont utiles, et d’autre part, de devoir rédiger les requêtes complexes correspondant à ses besoins.
La vue ci-dessous pourrait convenir à un analyste marketing qui étudie la répar-tition géographique des commandes de produits :
create view HABITUDE_ACHAT(LOCALITE,NPRO,VOLUME) as select LOCALITE,P.NPRO,sum(QCOM*PRIX)
from CLIENT CLI,COMMANDE COM,DETAIL D,PRODUIT P where COM.NCLI = CLI.NCLI
and D.NCOM = COM.NCOM and P.NPRO = D.NPRO group by LOCALITE, P.NPRO Note
Il serait intéressant de comparer les domaines d’application d’un instantané tel que CLIENT_TOULOUSE (section 5.8.1) avec une vue de même définition.
6.2.4 Les vues comme mécanisme de contrôle d’accès
Dans une entreprise, il n’est pas envisageable que tout le monde puisse faire n’importe quoi sur n’importe quelle donnée. C’est le rôle du contrôle d’accès que de régenter les opérations sur les données (section 6.1). Etant donné une classe d’utili-sateurs, on détermine à quelles données ceux-ci ont accès, et on défini les vues qui ne reprennent que ces données. Ensuite, on accorde à ces utilisateurs l’autorisation d’utiliser ces vues, mais on leur interdit l’accès aux tables de base. Un employé chargé de faire des études sur les habitudes d’achat des clients selon différents critères, ne doit pas avoir accès aux données personnelles de ces clients. On lui donnera donc l’autorisation d’accéder à la vue suivante, mais pas à la table CLIENT elle-même :
create view ANALYSE(LOCALITE, CAT, DATE, NPRO, QCOM) as select LOCALITE, CAT, DATECOM, NPRO, QCOM
from CLIENT C, COMMANDE M, DETAIL D where C.NCLI = M.NCLI and M.NCOM = D.NCOM
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 struc-ture de la base de données. Dans ce dernier cas, une modification de la requête défi-nissant 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 com-merciales COM_CLIENT(NCLI, CAT, COMPTE). Par une vue définie comme la join-ture 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 modifica-tion, 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 obligatoires4.
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.