LA GESTION DES VUES

1. INTRODUCTION

Pourquoi des vues ? Elles permettent de raliser, dans le monde des SGBD relationnels, le
niveau externe des SGBD selon larchitecture ANSI/SPARC. Rappelons que le niveau externe
propose lutilisateur une perception de la base plus proche de ses besoins, en termes de
structures et de formats de donnes. De manire gnrale, les vues garantissent une meilleure
indpendance logique des programmes par rapport aux donnes. En effet, le programme
restera invariant aux modifications de schma sil accde la base via une vue qui lisole de
celle-ci. Lors des modifications du schma de la base, ladministrateur modifiera seulement la
dfinition des vues, et les programmes dapplication pourront continuer travailler sans
modification. Les vues ont aussi un rle de scurit : lutilisateur ne peut accder quaux
donnes des vues auxquelles il a droit daccs ; ainsi, les donnes en dehors de la vue sont
protges. De manire dtourne, les vues permettent aussi certains contrles dintgrit
lorsquelles sont utilises pour les mises jour : on dit alors quon effectue une mise jour au
travers dune vue. De telles mises jour sont trs contrles, comme nous le verrons ci-
dessous.

Ces dernires annes, les vues ont trouv de nouvelles applications. Elles permettent de dfinir
des tables virtuelles correspondant aux besoins des programmes dapplication en termes de
donnes. Dans le monde du client-serveur, les vues constituent un lment essentiel
doptimisation de performance. Par exemple, la dfinition dune vue jointure de deux tables, ou
rsultant dun calcul dagrgat, vite au client les risques de lire les tuples des tables et de faire
le calcul de jointure ou dagrgat sur le client : seules les donnes rsultant du calcul de la vue
sont exportes sur le site client. On laisse ainsi faire au serveur les calculs de jointure, agrgat,
etc., quil sait en principe bien faire. Dans le monde des entrepts de donnes et du dcisionnel,

IX.1
les vues peuvent tre concrtises. Elles permettent de raliser par avance des cumuls ou
synthses plus sophistiqus de quantits extraites de la base selon plusieurs dimensions. Des
mcanismes de mises jour des vues concrtes lors des mises jour des relations de base sont
alors dvelopps afin dviter le recalcul des cumuls.

Les vues ont donc une importance croissante dans les bases de donnes. En pratique, ce sont
des relations virtuelles dfinies par des questions. Cette dfinition est stocke dans la mtabase.
Les vues sont interroges comme des relations normales. Idalement, elles devraient pouvoir
tre mises jour comme des relations normales. Les vues concrtes sont calcules sur disques
lors de leurs crations. Des mcanismes de mise jour diffrentiels permettent le report
efficace des mises jour des relations de base. Toutes ces techniques sont aujourdhui bien
matrises ; nous allons les prsenter ci-dessous.

Afin dillustrer les mcanismes de vues, nous utiliserons tout dabord la base de donnes
viticole classique compose des relations :
BUVEURS (NB, NOM, PRENOM, ADRESSE, TYPE)
VINS (NV, CRU, REGION, MILLESIME, DEGRE)
ABUS (NV, NB, DATE, QUANTITE).

dcrivant respectivement les buveurs, les vins, et les consommations de vins quotidiennes.
Comme habituellement, les cls des relations sont soulignes. Des vues typiques sont les vins
de Bordeaux, les gros buveurs, les quantits de vins bues par crus, etc.

Pour des exemples plus avances, intgrant notamment des agrgats complexes, nous
utiliserons la base MAGASINS suivante :
VENTES(NUMV, NUMPRO, NUMFOU, DATE, QUANTITE, PRIX)
PRODUITS (NUMPRO, NOM, MARQUE, TYPE,PRIX)
FOURNISSEURS (NUMFOU, NOM, VILLE, REGION, TELEPHONE)

Des vues typiques sont les quantits de produits vendus par fournisseurs et par mois, les
volutions des quantits commandes par rgion, etc. La relation Ventes dcrit les ventes
journalires de produits. NUMPRO est la cl de produits et NUMFOU celle de fournisseurs. Dans
une telle base de donnes, les faits de base sont les ventes, alors que produits et fournisseurs
constituent des dimensions permettant dexplorer les ventes selon une ville ou une rgion par
exemple.

Ce chapitre est organis comme suit. Aprs cette introduction, la section 2 expose plus
formellement le concept de vue, dtaille le langage de dfinition et prsente quelques exemples
simples de vues. La section 3 dveloppe les mcanismes dinterrogation de vues. La section 4
pose le problme de la mise jour des vues et isole les cas simples tolrs par SQL. La section
5 traite des vues concrtes, notamment en vue des applications dcisionnelles. En particulier,
les techniques de report des mises jour depuis les relations de base sur des vues concrtes
avec agrgats sont tudies. La conclusion voque quelques autres extensions possibles du
mcanisme de gestion des vues.

IX.2
2. DEFINITION DES VUES

Dans cette partie, nous dfinissons tout dabord prcisment ce quest une vue, puis nous
introduisons la syntaxe SQL pour dfinir une vue.

Notion IX.1 : Vue (View)

Une ou plusieurs tables virtuelles dont le schma et le contenu sont drivs de la base
relle par un ensemble de questions.
Une vue est donc un ensemble de relations dduites dune bases de donnes, par composition
des relations de la base. Le schma de la vue est un schma externe au sens ANSI/SPARC.
Dans la norme SQL, la notion de vue a t rduite une seule relation dduite. Une vue est
donc finalement une table virtuelle calculable par une question.

La syntaxe gnrale de la commande SQL1 de cration de vue est :

CREATE VIEW <NOM DE VUE> [ (LISTE DATTRIBUT)]
AS <QUESTION>
[WITH CHECK OPTION]

Le nom de vue est le nom de la table virtuelle correspondant la vue, la liste des attributs
dfinit les colonnes de la table virtuelle, la question permet de calculer les tuples peuplant la
table virtuelle. Les colonnes du SELECT sont appliques sur celles de la vue. Si les colonnes
de la vue ne sont pas spcifies, celle-ci hrite directement des colonnes du SELECT
constituant la question.

La clause WITH CHECK OPTION permet de spcifier que les tuples insrs ou mis jour via
la vue doivent satisfaire aux conditions de la question dfinissant la vue. Ces conditions seront
vrifies aprs la mise jour : le SGBD testera que les tuples insrs ou modifis figurent bien
parmi la rponse la question, donc dans la vue. Ceci garantie que les tuples insrs ou
modifis via la vue lui appartiennent bien. Dans le cas contraire, la mise jour est rejete si la
clause WITH CHECK OPTION est prsente. Par exemple, si la vue possde des attributs
dune seule table et la question un critre de jointure avec une autre table, les tuples insrs
dans la table correspondant la vue devront joindre avec ceux de lautre table. Ceci peut tre
utilis pour forcer la vrification dune contrainte rfrentielle lors dune insertion via une vue.
Nous tudierons plus en dtail la justification de cette clause dans la partie traitant des mises
jour au travers de vues.

La suppression dune vue seffectue simplement par la commande :

DROP <NOM DE VUE>.

Cette commande permet de supprimer la dfinition de vue dans la mtabase (aussi appele
catalogue) de la base. En principe, sauf comme nous le verrons ci-dessous, dans le cas des vues
concrtes, une vue na pas dexistence physique : cest une fentre dynamique (et dformante),
non matrialise sur les disques, par laquelle un utilisateur accde la base. La destruction de
vue na donc pas se soucier de dtruire des tuples.

IX.3
Voici maintenant quelques exemples de dfinition de vues. Soit la base de donnes Viticole
dont le schma a t rappel en introduction.

(V1) Les vins de Bordeaux :

CREATE VIEW VINSBORDEAUX (NV, CRU, MILL, DEGR)
AS SELECT NV, CRU, MILLSIME, DEGR
FROM VINS
WHERE RGION = "BORDELAIS".

Cette vue est simplement construite par une restriction suivie dune projection de la table
Vins. Chaque tuple de la vue est driv dun tuple de la table Vins.

(V2) Les gros buveurs :

CREATE VIEW GROSBUVEURS
AS SELECT NB, NOM, PRNOM, ADRESSE
FROM BUVEURS B, ABUS A
WHERE B.NB = A.NB AND A.QUANTIT > 10
WITH CHECK OPTION

Un tuple figure dans la vue GrosBuveurs si le buveur correspondant a commis au moins un

abus en quantit suprieure 10 verres. Cest l une dfinition trs large des gros buveurs. La
dfinition de vue comporte une restriction et une jointure. La clause WITH CHECK OPTION
prcise que lors dune insertion dun buveur via la vue, on doit vrifier quil sagit bien dun
gros buveur, cest--dire que le buveur a dj commis un abus de quantit suprieure 10.
Notez que ceci spcifie une rgle dintgrit rfrentielle lenvers pour les gros buveurs, ce
qui est paradoxal.

(V3) Les quantits de vins bues par crus :

CREATE VIEW VINSBUS (CRU, MILL, DEGR, TOTAL)
AS SELECT CRU, MILLESIME, DEGRE, SUM(QUANTITE)
FROM VINS V, ABUS A
WHERE V.NV = A.NV
GROUP BY CRU.

Cette vue fait appel une jointure (suivant une contrainte rfrentielle) suivie dun calcul
dagrgat (la somme). Un tuple de la table Vins donne plusieurs tuples lors de la jointure
(autant quil y a dabus) ; ceux-ci sont ensuite regroups selon le cru.

Pour la base MAGASINS, nous dfinirons seulement une vue (V4) documentant la table
VENTES selon les dimensions PRODUITS et FOURNISSEURS, rsultant de jointures sur
cl de ces tables :

IX.4
 CREATE VIEW VENTEDOC (NUMV,NOMPRO,MARQUE,NOMFOU,VILLE,REGION, DATE,
QUANTITE, PRIX) AS
SELECT V.NUMV,P.NOM,P.MARQUE,F.NOM,F.VILLE,F.REGION,V.DATE,
V.QUANTITE, V.PRIX
FROM VENTES V, PRODUITS P, FOURNISSEURS F
WHERE V.NUMPRO=P.NUMRO AND V.NUMFOU=F.NUMFOU

Nous verrons des vues plus complexes, notamment avec des agrgats ci-dessous.

La suppression des vues ci-dessus seffectuera par les commandes :

DROP VINSBORDEAUX.
DROP GROSBUVEURS.
DROP VINSBUS.
DROP VENTESDOC.

3. INTERROGATION AU TRAVERS DE VUES

Du point de vue de l'utilisateur, linterrogation au travers d'une vue seffectue comme pour une
table normale. Le rle du serveur est alors denrichir la question avec la dfinition de vue quil
retrouve dans la mtabase. Pus formellement, la dfinition dune vue V sur des relations R1,
R2, ...Rn est une fonction V = F(R1, R2, ...Rn), o F est une expression de lalgbre
relationnelle tendue avec des agrgats. F est donc une expression de restriction, projection,
jointure, union, diffrence et agrgats. Une question Q est exprime sur la vue en SQL. Il
sagit aussi dune fonction calculant la rponse R = Q(V), o Q est aussi une expression de
lalgbre relationnelle tendue. Calculer R partir de la base revient donc remplacer V dans
la requte R = Q(V) par sa dfinition. On obtient alors la fonction compose :

R = Q(F(R1, R2, ...Rn)).

Ce mcanisme est illustr figure IX.1. La requte rsultante peut alors tre passe
loptimiseur et le plan dexcution correspondant peut tre calcul. Cest ainsi que
fonctionnent les SGBD : ils gnrent la requte composition de la dfinition de vue et de la
requte usager, et traitent ensuite cette requte plus complexe, mais valuable sur les relations
de la base.

Base
Rponse
Vue
R1
F Q
...

Rn

Figure IX.1 Composition d'une question Q avec la dfinition de vue F

IX.5
Deux techniques sont possibles pour raliser la composition de la vue et de la requte
utilisateur : la transformation de la requte source appele modification de question, ou la
transformation de larbre relationnelle, parfois appele concatnation darbre.

Notion IX.2 : Modification de question (Query modification)

Mcanisme consistant modifier une question en remplaant 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 rsultat de la question initiale.
La modification de question est une technique invente dans le projet Ingres Berkeley
[Stonebraker75]. Elle permet de remplacer les vues par leurs dfinitions lors des recherches ou
d'ajouter des prdicats afin de vrifier des proprits avant dexcuter une requte. La figure
IX.2 illustre cette technique pour la recherche des gros buveurs habitant Versailles. Cette
technique peut aussi tre utilise pour les mises jour afin denrichir le critre pour vrifier par
exemple la non-violation de contraintes dintgrit.

(1) Question
SELECT NOM, PRENOM
FROM GROSBUVEURS
WHERE ADRESSE LIKE "VERSAILLES".

(2) Dfinition de vue

CREATE VIEW GROSBUVEURS
AS SELECT NB, NOM, PRENOM, ADRESSE
FROM BUVEURS B, ABUS A
WHERE B.NB = A.NB AND A.QUANTITE > 10.

(3) Question modifie

SELECT NOM, PRENOM
FROM BUVEURS B, ABUS A
WHERE B.ADRESSE LIKE "VERSAILLES" AND B.NB=A.NB AND A.QUANTITE>10.

Figure IX.2 Exemple de modification de question

Notion IX.3 : Concatnation darbres (Tree concatenation)

Mcanisme consistant remplacer un nud pendant dans un arbre relationnel par un

autre arbre calculant le nud remplac.
La concatnation darbres est une technique invente dans le fameux systme R San-Jos
[Astrahan76]. La dfinition de vue se retrouve dans la mtabase sous la forme dun arbre
relationnel. Larbre rsultant de lanalyse de la question est simplement connect celui
dfinissant la vue. Lensemble constitue un arbre qui reprsente la question enrichie, qui est
alors passe loptimiseur. La figure IX.3 illustre ce mcanisme pour la recherche des gros
buveurs habitant Versailles.

IX.6
 B.NOM, B.PRENOM

B.ADRESSE= "Versailles" Question

Vue Vue

B.NB, B.NOM, B.PRENOM, B.ADRESSE

A.NB B.NB Dfinition de vue

=

A.QTE > 10 BUVEURS B

ABUS A

Figure IX.3 Exemple de concatnation darbres

4. MISE A JOUR AU TRAVERS DE VUES

Dans cette section, nous examinons, dun point de vue pratique puis thorique, le problme des
mises jour au travers des vues.

4.1 Vue mettable jour

Le problme est de traduire une mise jour (ou une insertion, ou une suppression) portant sur
une vue en mise jour sur les relations de la base. Toute vue nest pas mettable jour.

Notion IX.4 : Vue mettable jour (Updatable view)

Vue comportant suffisamment d'attributs pour permettre un report des mises jour dans
la base sans ambigut.
De manire plus fine, une vue peut tre mettable jour en insertion, en suppression, ou en
modification. Par exemple, la vue V1 dfinissant les vins de Bordeaux est totalement mettable
jour, cest--dire que toute opration INSERT, DELETE ou UPDATE est reportable sur la
base. Ajoutons la vue V2 dfinissant les gros buveurs la quantit bue (QUANTIT) aprs le
SELECT. Ceci pose problme lors dune insertion : comment gnrer le numro de vins (NV)
et la date (DATE) de labus qui doit obligatoirement tre insr puisque NB, NV, DATE est cl
de ABUS ? Si lon obligeait lexistence de labus avant dinsrer le buveur il ny aurait pas de
problme. La clause WITH CHECK OPTION permet justement de vrifier l'existence de tels
tuples. Malheureusement, sa prsence simultane la contrainte rfrentielle ABUS.NB
REFERENCE BUVEURS est impossible ! La suppression et la modification de tuples existants
ne pose pas non plus de problme. La vue V3 est encore plus difficile mettre jour : il est
impossible de dterminer les quantits lmentaires partir de la somme ! En rsum,
lutilisation de certaines vues en mises jour est problmatique.

IX.7
4.2 Approche pratique

En pratique, la plupart des systmes rsolvent le problme en restreignant les possibilits de

mise jour des vues monotable : seuls les attributs dune table de la base doivent apparatre
dans la vue. En imposant de plus que la cl de la table de la base soit prsente, il est possible de
dfinir une stratgie de mise jour simple. Lors dune insertion, on insre simplement les
nouveaux tuples dont la cl nexiste pas, avec des valeurs nulles pour les attributs inexistants.
Lors dune suppression, on supprime les tuples rpondant au critre. Lors dune modification,
on modifie les tuples rpondant au critre. La dfinition de vue peut rfrencer dautres tables
qui permettent de prciser les tuples de la vue. En thorie, il faut vrifier que les tuples insrs,
supprims ou modifis appartiennent bien la vue. En pratique, SQL neffectue cette
vrification que si elle a t demande lors de la dfinition de vue par la clause WITH
CHECK OPTION.

Restreindre la mise jour des vues monotables est beaucoup trop fort. On peut simplement
tendre, au moins en insertion et en suppression, aux vues multitables comportant les cls des
tables participantes. Les attributs non documents sont alors remplacs par des valeurs nulles
lors des insertions. Cette solution pratique gnre cependant des bases de donnes avec de
nombreuses valeurs nulles. Elle sera souvent interdite dans les systmes commercialiss. Ceux-
ci sont donc loin de permettre toutes les mises jour thoriquement possibles, comme le
montre la figure IX.4.
Ensemble de toutes les vues
Vue thoriquement
mettable jour

Mettable jour en SQL

( la qualification peut invoquer
plusieurs tables)

Vues multi-tables

Vues mono-tables
avec cls

avec cls

Figure IX.4 Classification des vues selon les possibilits de mise jour

4.3 Approche thorique

Le problme thorique est de dfinir une stratgie de report qui prserve la vue quelle que soit
la mise jour : si lon calcule la vue et on lui applique la mise jour, on doit obtenir le mme
rsultat que si on applique les mises jour la base et on calcule ensuite la vue. Lquation
u(V(B)) = V(u(B)) doit donc tre vrifie, en notant B la base, v le calcul de vue, u la
mise jour sur la vue et u les mises jour correspondantes sur la base. Autrement dit, le
diagramme de la figure IX.5 doit commuter. Dautre part, il est vident quune bonne stratgie
doit prserver le complment de la base, cest--dire toutes les informations de la base qui ne
figurent pas dans la vue [Bancilhon81]. Selon ces hypothses raisonnables, le problme du
calcul de u na pas toujours une solution unique [Abiteboul91].

IX.8
 Mise jour u
Vue Vue'

as Question V as Question V

Mise jour rpercute u

BD BD'

Figure IX.5 Diagramme de mise jour et drivation de vue

Une approche intressante a t propose rcemment dans [Bentayeb97]. Lide est de dfinir
linverse de chaque opration relationnelle. En effet, soit V = E(R1, R2, ...Rn) une dfinition
de vue. E est une expression de lalgbre relationnelle. Si lon peut dfinir linverse de chaque
opration de lalgbre sur une relation, on pourra alors calculer R1 R2... Rn = E-1(V). La
rpercussion dune mise jour de V se fera simplement en unifiant Ri avec la projection de E -
1
(V) sur Ri. Le problme de linversion de lalgbre relationnelle a aussi t tudi dans
[Imielinski83]. Dsignons par t un tuple de la vue V et par [t] une table compose de ce seul
tuple. Limage rciproque dun tuple t par E peut tre vue comme un ensemble de tables T1,
T2, ..., Tn telles que E (T1, T2, ..., Tn) = [t]. Les tables Ti peuvent possder des attributs
inconnus dsigns par des variables x,y, etc. Elles ne doivent pas contenir de tuples inutiles
pour composer t, donc pour tout tuple ti Ti, E (T1, ..., Ti-[ti], ..., Tn) [t]. Insrer le tuple t
dans la vue V a alors pour effet de modifier les relations de base Ri en les unifiant avec les
relations Ti. Lunification est une opration difficile, pas toujours possible, explicite dans
[Bentayeb97] sous forme dalgorithmes pour linsertion et la suppression.

En rsum, la mise jour au travers de vue est un problme complexe, bien tudi en thorie,
mais dont les solutions pratiques sont rduites. Certains SGBD permettent des mises jour de
vues multitables en laissant ladministrateur dfinir la stratgie de report.

5. VUES CONCRETES ET DECISIONNEL

Dans cette section, nous abordons le problme des vues concrtes. Celles-ci sont
particulirement intressantes dans les entrepts de donnes (data warehouse), o elles
facilitent lanalyse de donnes (OLAP) pour laide la dcision.

5.1 Dfinition

Une vue est en principe une fentre dynamique sur une base de donnes, dont une partie est
instancie lors dune question. La concrtisation de la vue par le serveur peut tre plus
avantageuse si celle-ci est souvent utilise et si les tables sources sont peu modifies. Ainsi,
certains serveurs supportent des vues concrtes.

IX.9
 Notion IX.5 : Vue concrte (Concrete view)

Table calcule partir des tables de la base par une question et matrialise sur disques
par le SGBD.
Une vue concrte est calcule ds sa dfinition et mise jour chaque fois quune transaction
modifie la base sous-jacente. La mise jour seffectue si possible en diffrentiel, cest--dire
que seuls les tuples modifis sont pris en compte pour calculer les modifications apporter la
vue. Mais ceci n'est pas toujours possible. Dans le cas de vues dfinies par des slections,
projections et jointures (SPJ), le report diffrentiel des insertions est simple, celui des mises
jour de type suppression ou modification beaucoup plus difficile. Pour rpercuter suppressions
et mises jour, il faut en gnral retrouver au moins partiellement les chanes de
drivation qui ont permis de calculer les tuples de la vue concrte. Dans le cas gnral (vues
avec diffrence, agrgat, etc.), les reports diffrentiels sont trs difficiles, comme nous le
verrons ci-dessous

Les vues concrtes sont dfinissables par une requte du type :

CREATE CONCRETE VIEW <SPECIFICATION DE VUE>.

Elles sont particulirement intressantes lorsquelles contiennent des agrgats, car elles
permettent de mmoriser des rsums compacts des tables. Par exemple, il est possible de
dfinir des vues concrtes avec agrgats de la table VENTES dfinie dans lintroduction :
VENTES(NUMV, NUMPRO, NUMFOU, DATE, QUANTITE, PRIX)

Les tables PRODUITS et FOURNISSEURS permettent de gnrer des exemples de vues avec
jointures :
PRODUITS (NUMPRO, NOM, MARQUE, TYPE,PRIX)
FOURNISSEURS (NUMFOU, NOM, VILLE, REGION, TELEPHONE)

La vue suivante donne les ventes de produits par fournisseur et par jour :
CREATE CONCRETE VIEW VENTESPFD (NUMPRO,NUMFOU,DATE,COMPTE,QUANTOT)AS
SELECT NUMPRO,NUMFOU,DATE,COUNT(*)AS COMPTE,SUM(QUANTITE) AS QUANTOT
FROM VENTES
GROUP BY NUMPRO, NUMFOU, DATE.

La notation VENTESPFD signifie ventes groupes par produits, fournisseurs et dates . Une
vue plus compacte liminera par exemple les fournisseurs :
CREATE CONCRETE VIEW VENTESPD (NUMPRO,DATE,COMPTE,QUANTOT) AS
SELECT NUMPRO, DATE,COUNT(*)AS COMPTE,SUM(QUANTITE) AS QUANTOT
FROM VENTES
GROUP BY NUMPRO, DATE.

Notez que la vue VENTESPD peut tre drive de la vue VENTESPFD par la dfinition
suivante :

IX.10
 CREATE CONCRETE VIEW VENTESPD (NUMPRO, DATE, COMPTE,QUANTOT) AS
SELECT NUMPRO, DATE,SUM(COMPTE)AS COMPTE,SUM(QUANTOT) AS QUANTOT
FROM VENTESPFD
GROUP BY NUMFOU.

Il est aussi possible de driver des vues concrtes avec agrgats par jointures avec les tables
dimensions, par exemple en cumulant les ventes par rgion des fournisseurs :
CREATE CONCRETE VIEW VENTESPRD(NUMPRO,REGION,DATE,COMPTE,QUANTOT) AS
SELECT NUMPRO, DATE,COUNT(*)AS COMPTE,SUM(QUANTITE) AS QUANTOT
FROM VENTES V, FOURNISSEURS F
WHERE V.NUMFOU = F.NUMFOU
GROUP BY V.NUMPRO, F.REGION.

Toutes ces vues concrtes sont trs utiles pour laide la dcision dans un contexte dentrept
de donnes, o lon souhaite analyser les ventes selon diffrentes dimensions [Gray96].

5.2 Stratgie de report

Les vues concrtes doivent tre mises jour lors de la mise jour des relations de la base. Un
problme important est de dterminer une stratgie de report efficace des mises jour
effectues sur les relations de base. Bien sr, il est possible de recalculer compltement la vue
aprs chaque mise jour, mais ceci est inefficace.

Une meilleure stratgie consiste maintenir la vue concrte de manire diffrentielle, ou si lon
prfre incrmentale. Soit une vue V = F(R1, R2, ...Rn) dfinie sur les relations R1, R2, ... Rn.
Des mises jour sont effectues par exemple sur la relation Ri. Soient des insertions de tuples
notes +Ri et des suppressions notes -Ri. Une modification de tuples existants peut
toujours se ramener une suppression suivie dune insertion. Leffet net des mises jour sur Ri
est donc Ri = (Ri - -Ri) +Ri. Le problme est de calculer leffet net sur V, qui peut tre
exprim par des tuples supprims, puis par des tuples insrs comme suit : V = (V - -V)
+V. Dans certains cas, les mises jour apporter sur V (-V, +V) peuvent tre calcules
partir de celles apportes sur Ri (-Ri, +Ri). La vue V est alors qualifie dauto-maintenable
[Tompa88, Gupta95]

Notion IX.6 : Vue auto-maintenable (Self-maintenable view)

Vue concrte contenant suffisamment dinformations pour tre mise jour partir des
mises jour des relations de base, sans accs aux tuples des relations de la base.
Cette notion est trs importante dans les architectures distribues (client-serveur, entrepts de
donnes, copies), o la vue est matrialise sur un site diffrent de celui de la base. Elle est
illustre figure IX.6. Il est possible de distinguer lauto-maintenabilit en insertion ou en
suppression, cest--dire lors des insertions ou suppressions dans une relation de base. Lauto-
maintenabilit peut aussi tre caractrise pour chaque relation, et enfin gnralise au cas dun
groupe de vues [Huyn97].

IX.11
 Figure IX.6 Maintenance de vues avec ou sans accs la base

En guise dillustration, considrons la vue V1 des vins de Bordeaux dfinie ci-dessus comme
une restriction de la table Vins : V1 = REGION = "Bordelais" (VINS). Cette vue est auto-
maintenable. En effet, comme la restriction commute avec la diffrence, il est simple de
calculer :

+V1 = REGION = "Bordelais" (+VINS).

-V1 = REGION = "Bordelais" (-VINS).

Par suite, les mises jour apporter V1 sont calculables sans accder la table VINS, mais
seulement partir des mises jour de VINS. Malheureusement, ds quune vue comporte des
projections avec limination de doubles, des jointures ou des diffrences, elle nest
gnralement plus auto-maintenable [Fabret94]. Par exemple, dans le cas de projections sans
double, lorsque lon enlve un tuple dune table source, on ne sait plus sil faut lenlever dans
la vue car sa projection peut provenir dun autre tuple. De mme, pour calculer le tuple
enlever dans une vue jointure lors dune suppression dun tuple dans une table, il faut accder
lautre table pour trouver les tuples jointures. De manire gnral, savoir si une vue est auto-
maintenable savre difficile, et mme trs difficile lorsque la vue contient des agrgats
[Gupta96]. Ce dernier cas est examin dans le paragraphe qui suit.

Dans le cas dune vue calcule par slections, projections et jointures (SPJ), les problmes
essentiels semblent provenir des jointures. Toute vue comportant toutes les informations de la
base ncessaires son calcul (attributs de projection et de jointure, tuples) est auto-
maintenable en insertion ; en effet, la nouvelle instance de la vue V est :

V = F (R1,..., Ri+Ri,..., Rn) .

Comme F ne contient pas de diffrence, on a :

V = F (R1,..., Ri,..., Rn) F (R1,..., +Ri,..., Rn) = V F (R1,..., +Ri,..., Rn)

IX.12
do lon dduit :

V+ = F (R1,..., +Ri,..., Rn).

Si F (R1,..., +Ri,..., Rn) est calculable partir de V et +Ri, la vue est auto-maintenable en
insertion. Tel est le cas condition que V contienne les attributs et les tuples de R1, ...Rn
ncessaires son calcul. Les jointures externes seules ne perdent pas de tuples. Donc, une vue
calcule par des jointures externes et projections est gnralement auto-maintenable en
insertion.

Pour lauto-maintenabilit en suppression, le problme est plus difficile encore. On ne peut

distribuer F par rapport Ri - -Ri, ce qui rend le raisonnement prcdent caduc. Cependant,
toute vue contenant les attributs de R1, ..., Rn ncessaires son calcul et au moins une cl de
chaque relation de base est auto-maintenable. En effet, lorigine des tuples de la vue peut tre
identifie exactement par les cls, ce qui permet de reporter les suppressions.

Des structures annexes associes une vue peuvent aussi tre maintenues [Colby96, Colby97].
Les reports sur la vue concrte peuvent tre diffrs. La vue devient alors un clich (snapshot)
[Adiba80]. Beaucoup de SGBD supportent les clichs.

Notion IX.7 : Clich (Snapshot)

Vue concrte dune base de donnes mise jour priodiquement.

La gestion de structures diffrentielles associes au clich, par exemple les mises jour sur
chaque relation dont il est driv (les Ri), peut permettre un accs intgr la vue concrte
jour et conduit au dveloppement dalgorithmes de mise jour spcialiss [Jagadish97].

5.3 Le cas des agrgats

Le cas de vues avec agrgats est particulirement important pour les systmes dcisionnels,
comme nous allons le voir ci-dessous. Le problme de lauto-maintenabilit des agrgats a t
tudi dans [Gray96], qui propose de distinguer trois classes de fonctions : distributives,
algbriques, et non rgulires (holistic).

Les fonctions agrgatives distributives peuvent tre calcules en partitionnant leurs entres en
ensembles disjoints, puis en appliquant la fonction chacun, enfin en agrgeant les rsultats
partiels pour obtenir le rsultat final. Une fonction distributive AGG vrifie donc la proprit :

AGG(v1,v2, ...vn) = AGG(AGG(v1, ...vi},AGG(vi+1,..vn)).

Parmi les fonctions standard de calcul dagrgats, SUM, MIN et MAX sont distributives. La
fonction COUNT, qui compte le nombre dlments sans liminer les doubles, peut tre
considre comme distributive en linterprtant comme une somme de comptes partiels gaux
1 pour des singletons ; par contre, COUNT DISTINCT nest pas distributive car se pose le
problme des doubles.

Les fonctions agrgatives algbriques peuvent tre exprimes comme fonctions algbriques de
fonctions distributives. Par exemple, la moyenne AVG est une fonction algbrique, car
AVG(v1, ...vn) = SUM(v1, ...vn) / COUNT(v1, ...vn). Pour le problme
IX.13
de la maintenance des vues concrtes, les fonctions algbriques peuvent tre remplaces par
plusieurs fonctions distributives ; par exemple, une colonne AVG sera remplace par deux
colonnes SUM et COUNT.

Les fonctions non rgulires ne peuvent tre calcules par partitions. Des vues comportant de
telles fonctions sont a priori non auto-maintenables.

La notion de vue auto-maintenable sapplique tout particulirement aux vues rsultant dune
agrgation dune table de base. On parle alors dagrgats auto-maintenables.

Notion IX.8 : Agrgats auto-maintenables (Self-maintenable aggregate)

Ensemble dagrgats pouvant tre calculs partir des anciennes valeurs des fonctions
dagrgats et des mises jour des donnes de base servant au calcul de la vue.
Comme pour les vues en gnral, on peut distinguer lauto-maintenabilit en insertion et en
suppression. [Gray96] a montr que toutes les fonctions dagrgats distributives sont auto-
maintenables en insertion. En gnral, ce nest pas le cas en suppression.

Savoir quand liminer un tuple de la vue pose problme. En introduisant un compteur du

nombre de tuples source dans la base pour chaque tuple de la vue (COUNT(*)), il est facile de
dterminer si un tuple doit tre supprim : on le supprime quand le compteur passe 0.
COUNT(*) est toujours auto-maintenable en insertion comme en suppression. Lorsque les
valeurs nulles sont interdites dans lattribut de base, SUM et COUNT(*) forment un ensemble
auto-maintenables : SUM est maintenu par ajout ou retrait de la valeur, et COUNT(*) par ajout
ou retrait de 1 ; COUNT(*) permet de savoir quand supprimer le tuple. En prsence de
valeurs nulles, il devient difficile de maintenir la somme. MIN et MAX sont aussi des fonctions
non auto-maintenable en suppression. En effet, si on supprime la valeur minimale ou maximale,
on ne peut recalculer le nouveau minimum ou maximum qu partir des valeurs figurant dans la
base.

Par exemple, la vue :

CREATE CONCRETE VIEW VENTESPFD (NUMPRO,NUMFOU,DATE,COMPTE,QUANTOT)AS
SELECT NUMPRO,NUMFOU,COUNT(*)AS COMPTE,SUM(QUANTITE) AS QUANTOT
FROM VENTES
GROUP BY NUMPRO, NUMFOU

est compose dagrgats auto-maintenables en insertion et en suppression, donc auto-

maintenables condition que Quantit ne puisse tre nulle (cest--dire de valeur inconnue)
dans lentre dune suppression : il faut alors aller rechercher sa valeur dans la base pour
enlever la vritable quantit la somme.

Par contre, la vue :

IX.14
 CREATE CONCRETE VIEW VENTESPFD (NUMPRO,NUMFOU,DATE,COMPTE,QUANTOT)AS
SELECT NUMPRO,NUMFOU,COUNT(*)AS COMPTE,MIN(QUANTITE) AS QUANMIN
FROM VENTES
GROUP BY NUMPRO, NUMFOU

est compose dagrgats auto-maintenables en insertion mais pas en suppression (problme

avec le MIN).

6. CONCLUSION

La gestion de vues en interrogation est un problme bien compris dans les SGBD relationnels
depuis la fin des annes 70. Nous avons introduit ci-dessus ses principes de base. Le report des
mises jour des vues sur la base est un problme plus difficile encore. Des solutions pratiques
et gnrales restent inventer. Lutilisation de dclencheurs sur les vues peut tre une solution
pour dfinir les stratgies de report.

La matrialisation des vues a connu une nouvelle activit ces dernires annes, avec
lapparition des entrepts de donnes. Les vues avec agrgats sont particulirement
importantes pour grer des donnes rsumes, en particulier le fameux cube de donnes trs
utile en dcisionnel. Les techniques sont maintenant connues. Il reste les mettre en uvre
efficacement dans les systmes, qui gre pour linstant peu de redondances et souvent des
organisations physiques ad hoc pour le multidimensionnel. Ceci nest plus vrai dans les
entrepts de donnes, qui utilisent souvent les vues concrtes pour faciliter les calculs
dagrgats [Bello98].

Les vues connaissent aussi un nouveau dveloppement dans le monde objet avec lapparition
de vues orientes objets au-dessus de bases de donnes relationnelles par exemple. Nous
aborderons cet aspect dans le cadre des SGBD objet ou objet-relationnel.

7. BIBLIOGRAPHIE

[Abiteboul91] Abiteboul S., Hull R., Vianu V., Foundations of Databases, Addison-Wesley,
1995.

Comme son nom lindique, ce livre traite des fondements des bases de donnes relationnelles
et objet. Souvent fond sur une approche logique ou algbrique, il reprend toute la thorie
des bases de donnes, y compris le problme de la mise jour au travers des vues,
parfaitement bien analys.

[Adiba80] Adiba M., Lindsay B., Database Snapshots , Intl. Conf. on Very Large
Databases, IEEE Ed., Montral, Canada, Sept. 1980.

Cet article introduit la notion de clich (snapshot) et montre son intrt, notamment dans les
bases de donnes rparties. Il dcrit aussi la ralisation effectue dans le fameux systme R*.

IX.15
[Adiba81] Adiba M., Derived Relations : A Unified Mechanism for Views, Snapshots and
Distributed Data , Intl. Conf. on Very Large Databases, IEEE Ed., Cannes, France, Sept.
1981.

Lauteur gnralise les clichs aux relations drives, dont il montre lintrt dans les bases
de donnes rparties. Il discute aussi les algorithmes de mise jour.

[Astrahan76] Astrahan M. M., et. al., System R : Relational Approach to Database

Management , ACM TODS, V1, N2, Juin 1976.

Larticle de rfrence sur le fameux System R. Il dcrit aussi le mcanisme de concatnation

darbres implment pour la premire fois dans ce systme.

[Bancilhon81] Bancilhon F., Spyratos N., Update Semantics and Relational Views , ACM
TODS, V4, N6, Dec. 1981, pp. 557-575.

Un article de rfrence en matire de mises jour de vues. Les auteurs posent le problme en
termes dinvariance de la vue suite aux mises jour directes ou rpercutes dans la base. Ils
montrent quune condition suffisante de maintenabilit est la possibilit de dfinir des
stratgies de report complments constants.

[Bello98] Bello R.G, Dias K., Downing A., Freenan J., Norcott D., Dun H., Witkowski A.,
Ziauddin M., Materialized Views in Oracle , Intl. Conf. on Very Large Databases, Morgan
& Kauffman Ed., New York, USA, Aot 1998, pp. 659-664.

Cet article explique la gestion des vues matrialises dans Oracle 8. Celles-ci sont utilises
pour les entrepts de donnes et la rplication. Elles peuvent tre rafrachies la fin des
transactions, sur demande ou priodiquement. Les rafrachissements par lots sont optimiss.
Loptimisation des requtes prend en compte les vues concrtes laide dune technique de
rcriture base sur un modle de cot.

[Bentayeb97] Bentayeb F., Laurent D., Inversion de lalgbre relationnelle et mises jour ,
13e Journes Bases de Donnes Avances (BDA 97), Ed. INRIA, Grenoble, 1997, pp. 199-
218.

Cet article propose une approche dterministe de la mise jour au travers de vue, fonde sur
la notion dimage rciproque. Des algorithmes dinversion de lalgbre sont proposs. Une
stratgie de report avec stockage ventuel dans la vue concrtise est tudie.

[Chamberlin75] Chamberlin D., Gray J., Traiger I., Views, Authorization and Locking in a
Relational Database System , Proc. National Computer Conf., 1975, pp. 425-430.

Cet article dtaille les mcanismes de vue, dautorisation et de verrouillage implante dans
System R.

IX.16
[Colby96] Colby L.S., Griffin T., Libkin L., Mumick I., RTrickey H., "Algorithms for Deferred
View Maintenance", Proc. ACM SIGMOD Int. Conf. on Management of Data, Montreal,
USA, Mai 1996.

[Colby97] Colby L.S., Kawaguchi A., Lieuwen D.F, Mimick I.S., K. Ross, "Supporting
Multiple View Maintenance Policies", Proc. ACM SIGMOD Int. Conf. on Management of
Data, Tucson, USA, pp. 405-416, Mai 1997.

Ces deux articles explorent diffrentes stratgies pour la maintenance de vues concrtes. Les
auteurs proposent notamment des algorithmes qui garantissent la cohrence dans des cas de
reports des mises jour en temps diffrs, avec divers niveaux et groupes de vues.

[Dayal82] Dayal U., Bernstein P., On the Correct Translation of Update Operations on
Relational Views , ACM TODS, V8, N3, Dept. 1982.

Cet article discute des stratgies de report de mise jour au travers de vues et dfinit des
critres de correction.

[Fabret94] Fabret F., Optimisation du calcul incrmental dans les langages de rgles pour
bases de donnes, Thse, Universit de Versailles SQ, Dcembre 1994.

Cette thse prsente une caractrisation des vues concrtes auto-maintenables dans les bases
de donnes. Les vues sont dfinies par projection, jointure, union, diffrence et restriction.
Cette thse propose aussi des algorithmes afin de maintenir des rseaux de vues pour
acclrer le calcul des requtes dans une BD dductive.

[Gray96] Gray J., Bosworth A., Layman A., Pirahesh H., "Datacube : A relational Aggregation
Operator Generalizing Group-by, Cross-tab, and Sub-totals", IEEE Int. Conf. on Data
Engineering, pp. 152-159, 1996.

Cet article introduit un nouvel oprateur d'agrgation, appel Datacube, afin de calculer des
agrgats multidimensionnels. Nous tudierons plus en dtails les oprateurs des bases de
donnes multidimensionnelles dans le cadre du chapitre sur les entrepts de donnes.

[Gupta95] Gupta M., Mumick I.S., Maintenance of Materialized Views : Problems,

Techniques and Applications , IEEE Data Engineering Bulletin, special Issue on
Materialized Views and data Warehousing, N18(2), Juin 1995.

Les auteurs introduisent les diffrents problmes poss par la gestion de vues concrtes dans
une bases de donnes. Ils proposent quelques solutions et montrent quelques applications
possibles pour la gestion dentrepts de donnes performants.

[Gupta96] Gupta A., Jagadish H.V., Mumick I.S., Data Integration Using Self-Maintainable
Views , Intl. Conf. on Extended Database Technology (EDBT), LCNS N1057, Avignon,
France, 1996, pp. 140-144.

Cet article dfinit prcisment la notion de vue auto-maintenable. Les auteurs tablissent des
conditions suffisantes pour quune vue selection-projection-jointure soit auto-maintenable.

IX.17
[Huyn97] Huyn N., Multiple-View Self-Maintenance in Data Warehousing Environments
Intl. Conf. on Very Large Databases, Morgan & Kauffman Ed., Athens, Grce, Aot 1997,
pp. 26-35.

Cet article tudie le problme de lauto-maintenabilit dun ensemble de vues. Il propose des
algorithmes qui permettent de tester si un groupe de vues est auto-maintenable par
gnration de requtes SQL. De plus, dans le cas o la rponse est positive, les algorithmes
gnrent les programmes de mises jour.

[Jagadish97] Jagadish H.V., Narayan P.P.S., Seshadri S., Sudarshan S., Kanneganti R.,
Incremental Organization for Data Recording and Warehousing , Intl. Conf. on Very Large
Databases, Morgan & Kauffman Ed., Athens, Greece, Aot 1997, pp. 16-25.

Les auteurs proposent deux techniques, la premire base sur des squences tries insres
dans un B-tree, la seconde sur une organisation par hachage, pour stocker les
enregistrements lors de leur arrive dans un entrept de donnes, avant leur intgration dans
les vues matrialises. Ces techniques prcisment values supportent des environnements
concurrents avec reprises.

[Keller87] Keller M.A., Comments on Bancilhon and Spyratoss Update Semantics and
Relational Views , ACM TODS, V12, N3, Sept. 1987, pp. 521-523.

Cet article montre que la condition suffisante de maintenabilit quest la possibilit de dfinir
des stratgies de report complments constants est trop forte, et quelle peut conduire
interdire des stratgies intressantes.

[Kerherv86] Kerherv B., Vues Relationnelles : Implmentation dans un SGBD centralis et

distribu , Thse de doctorat, Universit de Paris VI, Mars 1986.

Cette thse dcrit limplmentation de vues ralise dans le SGBD SABRE lINRIA. Un
mcanisme de gestion de vues concrtes par manipulation de compteurs au niveau des
oprateurs relationnels est aussi propos.

[Nicolas83] Nicolas J-M., Yazdanian K., An Outline of BDGen : A Deductive DBMS ,

Woldwide IFIP Congress, Paris, 1983.

Cet article introduit le systme dductif BDGen ralis au CERT Toulouse. Il maintient des
vues dfinies par des rgles en utilisant des compteurs de raisons de prsence dun tuple.

[Stonebraker74] Stonebraker M.R., A Functional View of Data Independance , ACM

SIGMOD Workshop on Data Description, Access and Control, ACM Ed., mai 1974.

Un des premiers articles de Mike Stonebraker, lun des pres du systme INGRES. Il plaide
ici pour lintroduction de vues assurant lindpendance logique.

IX.18
[Stonebraker75] Stonebraker M., Implmentation of Integrity Constraints and Views by
Query Modification , Proc. ACM-SIGMOD Intl. Conf. On Management of data, San Jos,
CA 1975.

Cet article propose de modifier les questions au niveau du source par la dfinition de vues
pour rpondre aux requtes. La technique est formalise avec le langage QUEL dINGRES,
o elle a t implmente.

IX.19