CHAPITRE 3 : Les Vues

Concept de vue
Création d’une vue
Utilisation des vues
Catalogue Vue
Mise à Jour d’une vue
Utilité des vues

A. Concept de vue :
Les vues permettent de réaliser dans le mode des SGBD relationnels, le niveau externe des
SGBD selon l’architecture ANSI/SPARC

User 1 User 2 user N

————————————————————————————————————-
Niveau Externe Schéma Externe1 SE2 SE3
————————————————————————————————————-
Niveau Conceptuel Schéma Conceptuel
————————————————————————————————————-
Niveau Interne Schéma Interne ==> (BD)

Niveaux de représentation des données (ANSI/SPARC)

Les vues reflètent la partie visible de la BD pour chaque utilisateur

Seules les tables contiennent des données et pourtant, pour l’utilisateur, une vue apparait comme
une table.

Définition 1 : C’est quoi une vue : C’est un ensemble de relations déduites d’une BD par
compositions des relations de la base.

Définition 2 : Une vue est une relation virtuelle (ou table virtuelle) calculable par une question
(requête). C’est une fenêtre dynamique sur la base (pas de fichier physique).

Remarques : Dans la norme SQL, la notion de vue a été réduite à une seule relation déduite.
En théorie, les utilisateurs ne devraient accéder aux informations qu’en questionnant des vues.
Mais en pratique, les utilisateurs manipulent généralement directement les tables.

B. Création de vue :

Syntaxe : La commande de création (ou de définition) d’une vue s’écrit comme suit :
Create [or replace] view <nom de la vue> [liste d’attributs] AS requêteSELECT
create or replace view V1 (Name, FirstName) as select nom, prenom from etudiant ;

- OR REPLACE: remplace la vue existante par la nouvelle définition même si elle existe déjà pour
éviter de détruire avant de la recréer
- Liste d’attributs : désigne les noms de colonnes de la vue. Par défaut, les colonnes prennent les
noms renvoyés par la requêteSQL.
RequêteSQL :requête d’interrogation d’une de de plusieurs tables /vues.

Remarque : La requête de définition (requêteSQL) peut comporter toutes les possibilités d’une
requête d’interrogation SQL.

Exemple :
Soit la BD ayant le schéma relationnel suivant :
Bateau (nbat, nombat, sponsor)
Competition(ncomp, nomcomp, datcomp, prixcomp)
Courses (nbat*, ncomp*, score)
Participants ( npart, nompart, nbat*)

Competition Courses
_____________________________________________________________ ____________________
Ncomp Nomcomp DateComp prixComp Nbat Ncomp Score
200 LE GRAND TOUR 21 03 2000 1000000 102 210 2
210 COURSE DE LA LIBERTE 05 05 2004 1000000 102 240 1
215 LE GRAND TOUR 20 03 2005 1100000 102 270 4
220 TROPHEE BARBEROUSSE 01 08 2005 1500000 103 210 4
240 COURSE DE LA LIBERTE 10 05 2007 1500000 103 215 3
260 TROPHEE BARBEROUSSE 01 08 2009 2000000 104 210 1
265 LE GRAND TOUR 21 03 2010 2000000 104 215 2
270 COURSE DE LA LIBERTE 08 05 2010 1800000 104 220 4
_____________________________________________________________ 104 240 3
104 260 5
104 265 1
BATEAU Participants 104 270 3
_____________________________ ________________________ 105 210 3
Nbat Nombat Sponsor Npart Nompart Nbat 105 215 1
102 TASSILI DJEZZY 320 MOHAMMED 104 _____________________
103 EL BAHDJA BNA 470 ALI 103
104 LA COLOMBE CONDOR 601 OMAR 102
105 HOGGAR BNA 720 MUSTAPHA 105
______________________________ _________________________

Définition d’une vue sur les bateaux sponsorisés par CONDOR :

Create view bateau-condor (N, Nom)
as select nbat, nombat from Bateau where sponsor = ‘CONDOR’ ;

Bateau-CONDOR
————————————
Nbat nombat
104 LA COLOMBE
————————————
Remarque : La vue Bateau-CONDOR a deux attributs hérités de la relation Bateau. De nouveaux
noms auraient pu être donnés aux attributs de cette « nouvelle relation ».
Les noms des attributs doivent être spécifiés dans le cas d’une ambiguïté ou si le résultat du
SELECT est une fonction de calcul (agrégat).

Exemple :
Create view bateau-courses (nbat, nbcomp)
as select nbat, count(ncomp) from courses group by nbat ;

cette requête crée une vue décrivant les bateaux ainsi que le nombre total des compétitions dans
lesquelles ils ont participé.

Bateau-Courses
———————————
nbat nbComp
102 3
103 2
104 7
105 2
———————————
Complément : Caractéristiques d’une vue :
La modification d’une table de la base affecte la vue (c à d, toute modification sur une relation
source est automatiquement reportée au travers de la vue. Ainsi, dans l’Exemple 1, lorsqu’un
bateau n’est pas sponsorisé par CONDOR, il n’apparait plus dans la vue bateau-CONDOR).
Le corps d’une vue ne peut contenir la clause ORDER BY. pourquoi?
prendre l’ordre existant physiquement car la vue est une sorte de fenêtre sur les données
physiques. seuls les agrégats sont possibles.

C. Utilisation des Vues :

Du point de vue de l’utilisateur, l’interrogation au travers d’une vue s’effectue comme pour une
table normale. Une vue se comporte donc comme une table (relation) de la base. On peut
l’interroger est peut également servir à construire d’autres vues.

Exemple : Utilisation de la vue Bateau-Courses

Select nbat from Bateau-Courses where nbcomp>5 ;

La requête donne les numéros des bateaux dont le nombre de compétitions dans lesquelles ils ont
participé est supérieur à 5.

Opération de composition de vue :

Pour traiter une requête comportant une vue, les SGBD relationnels effectuent ce qu’il est convenu
d’appeler l’opération de composition de vue. Il s’agit d’enrichir la requête utilisateur avec la
définition de vue. La requête résultante peut alors être passée à l’optimiser et le plan d’exécution
correspondant peut être calculé.
C’est ainsi que fonctionne les SGBD : Ils génèrent la requête composition de la définition de vue et
de la requête usager, et traitent ensuite cette requête plus complexe, mais évaluable sur les
relations de la base.

Remarque :
Deux techniques sont possibles pour réaliser la composition de la vue et de la requêteutilisateur :
la transformation de la requête source appelée modification de question, ou transformation de
l’arbre relationnel, parfois appelée concaténation d’arbres.

Modification de question (Query Modification )

Mécanisme consistant à modifier une question en remplaçant certaines vues du FROM par les
relations de base sources de ces vues et en enrichissant les conditions de la clause WHERE pour
obtenir le résultat de la question initiale.

Exemple :
Question : Select nbat from Bateau-Courses where nbcomp >5 ;

Définition de vue : Create View Bateau-Courses (nbat, nbcomp)

as select nbat, count(ncomp) from courses group by nbat;

Question modifiée : Select nbat from courses group by bat

Having count(ncomp)>5 ;

D. Catalogue Vues

Une vue est une relation virtuelle sur la BD, il n’existe pas de fichier physique qui la représente
directement. Par contre, sa définition est stockée dans la méta-base (catalogues), dans un
catalogue appelé : Catalogue Vue
——————————————————————————————————————————
Idf-Rel Idf des Relations de la Vue Requête SELECT
——————————————————————————————————————————
…. …. select ….
… … select ….
——————————————————————————————————————————
Catalogue des vues
Chaque ligne du catalogue vue correspond à une vue où :
Idf-Rel : la vue est décrite dans le catalogue comme une relation de type V (virtuelle) avec une Idf-
Rel
Idf des relations constituant la vue ( la clause from).
Requête Select qui va alimenter la vue.
Exemple :
Les vues Bateau-CONDOR et Bateau-Courses des exemples 1 et 2 sont décrites dans les
catalogues comme suit :

Catalogue Vues
——————————————————————————————————————————
Idf-Rel Idf des Relations Requête SELECT
——————————————————————————————————————————
153 150 select nbat, nombat from bateau where sponsor =‘condor’
154 152 select neat, count(ncomp) from courses group by nbat
——————————————————————————————————————————

Catalogue Relation
———————————————————————————————————
NomRelation Type Idf-Rel Taille tuple Card Degré …
———————————————————————————————————
Relation S 1
Attribut S 2
Vue S 3
…
Bateau B 150 40 500 3
Competition B 151 40 200 4
Courses B 152 40 1200 3
Bateau-CONDOR V 153 34 0 2
Bateau-Courses V 154 10 0 2
…
…
———————————————————————————————————

Deux tuples sont insérés dans ce catalogue pour décrire BATEAU-CONDOR et BATEAU-
COURSES comme relations de type ‘V’ (Virtuelle).
Dans le catalogue Attribut deux tuples sont insérés dans ce catalogue pour décrire les attributs
BATEAU-CONDOR et deux autres pour ceux de Bateau-COURSES.

—————————————————————————————————————————
NomAttribut Idf Attribut Idf Rel Type Attribut Longueur Position dans la relation
—————————————————————————————————————————
….
nbat
nombat
nbat 102 153 number 4 1
nombat 103 153 char 30 2
nbat 104 154 number 4 1
nbcomp 105 154 number 6 2
…
—————————————————————————————————————————
Effets de création des vues sur le catalogues « attribut »

E. Mise à jour d’une vue

La mise à jour au travers d’une vue n’est pas toujours possible. Le problème est de traduire une
mise à jour (insertion, suppression ou modification) portant sur une vue en mise à jour sur les
relations de la BD.
Toute vue n’est pas mettable à jour.

Définition : Vue mettable à jour (Updatable View)

Une vue comportant suffisamment d’attributs pour permettre un report des mises à jour dans la BD
sans ambiguïté.

De manière plus fine, une vue peut être mettable à jour en insertion en suppression ou en
modification.
Par exemple, la vue Bateau-CONDOR est totalement mettable à jour c à d que toute opération
INSERT, DELETE ou UPDATE est reportable sur la BD. La vue Bateau-Courses par contre est
difficile à mettre à jour : il est impossible de déterminer les numéros des compétitions à partir du
total calculé.
En résumé : l’utilisation de certaines vue en mise à jour est problématique.

Exemple : Mise à jour au travers d’une vue entraînant des incohérences.

Soient les deux relations :
EMPLOYE (NUM, NOM, NDEP)
DEPARTEMENT (NDEP, NDIR)

Où un employé a un numéro NUM, un nom NOM, il travaille dans un département de numéro

NDEP. Un département a un numéro NDEP et un directeur de numéro NDIR. L’extension de ces
relations est :

EMPLOYE DEPARTEMENT
——————————————————————- ————————————————-
NUM NOM NDEP NDEP NDIR
100 ACHIR D1 D1 110
110 AMERAOUI D1 D2 390
200 LAHMER D2 ————————————————-
250 SALHI D2
370 BENAMEUR D2
…..
——————————————————————-
Supposons une vue EMPDEP définie par la jointure de ces deux relations sur NDEP :
CREATE VIEW EMPDEP as select NUM, NOM, [Link], NDIR
from EMPLOYE, DEPARTEMENT where [Link] = [Link];

EMPDEP EMPDEP
———————————————- ———————————————-
NUM NOM NDEP NDIR NUM NOM NDEP NDIR
100 ACHIR D1 110 100 ACHIR D1 380
110 AMERAOUI D1 110 110 AMERAOUI D1 110
200 LAHMER D1 110 200 LAHMER D1 110
250 SALHI D2 390 250 SALHI D2 390
370 BENAMEUR D2 390 370 BENAMEUR D2 390
———————————————- ———————————————-

Si nous autorisons l’utilisateur à modifier la vue EMPDEP de la manière suivante :

Update EMPDEP SET NDIR = 380 where NUM = 100 ;
Cela revient à changer le directeur de l’employé N°100 qui de N°110 devient 380.

En considérant le fait qu’un directeur est lié à un département de manière fonctionnelle, nous
créons ansi une incohérence car il y a ambiguïté : le directeur du département D1 : 380 ou 110?
Attention : Une mise à jour au travers d’une vue V est autorisée que si :
V est bâtie sur une seule relation source, disons R.
Il existe une association une à une entre les tuples de V et ceux de R de telle sorte qu’une
opération de mise à jour (INSERT, DELETE ou UPDATE) sur V se traduit en opération sur R.

EMPLOYE Vue : EFFECTIF

———————————————————— ————————————————-
NUM NOM NDEP NDEP NbEMP
100 ACHIR D1 D1 2
110 AMERAOUI D1 D2 3
200 LAHMER D2 ————————————————-
250 SALHI D2
370 BENAMEUR D2
————————————————————
La vue EFFECTIF :

Create view EFFECTIF (NDEP, NbEMP)

as select NDEP, Count(*) from EMPLOYE group by NDEP ;

un insert sur EFFECTIF ne peut être reporté sur EMPLOYE car il y a une association 1 à N, c à d,
pour une ligne insérée sur EFFECTIF, on ne sait pas quels employés sont impliqués par le count.

Complément : Cela signifie que les insertions, suppressions et modifications ne sont possibles au
travers d’une vue qui comporte :
une jointure,
des opérations ensemblistes (union, intersect, minus)
l’option group by
une fonction d’agrégat
l’opération Distinct ou Unique

F. L’utilité des vues :

La vue est une table logique qui permet l’accès aux données d’une ou plusieurs tables de la BD de
façon transparente. Ainsi, une vue peut être utilisée pour :
Assurer l’indépendance logique: Les vues garantissent une meilleure indépendance logique des
programmes par rapport aux données. En effet, le programme restera invariant aux modifications
de schéma s’il accède à la BD via une vue qui l’isole de celle-ci. Lors des modifications du schéma
de la base, l’administrateur modifiera seulement la définition des vues, et les programmes
d’application pourront continuer à travailler sans modification.
Fournir un niveau supplémentaire de sécurité sur les tables de base : L’utilisateur ne peut accéder
qu’aux données de vues auxquelles il a droit d’accès; ainsi les données en dehors de la vue sont
protégées.
Masquer la complexité des requêtes : Une vue permet de simplifier l’écriture de certaines requêtes
complexes, et fréquemment utilisées.
…