Enseignement des Bases de Données

Introduction

Principes des vues relationnelles

L'architecture ANSISPARC définit trois niveaux d'abstraction d'une BD. Elle permet d'obtenir une indépendance logique et une indépendance physique des données.Le principe fondamental basant la séparation entre les schéma externe et le schéma conceptuel est qu'une application est indépendante des modifications apportées aux schémas conceptuels et physique des données.Réciproquement, le schéma conceptuel doit rester indépendant des applications et de son schéma de stockage.

 

 Cette architecture est commentée en Exemples de vues

Nous utilisons ici le chéma de la base des vins élargie dont le schéma figure ici.

Pour rappel, le modèle relationnel de cette base, qui est donc le schéma conceptuel central, est le suivant :

vins (nv, cru, mil, deg)

viticulteurs (nvt, nom, prenom, ville, region)

productions (nv, nvt)

buveurs (nb, nom, prenom, ville)

commandes (nc, date, nb, nv, qte)

expeditions (nc, date, qte)

Pour chacune des applications, chacun des groupes d'utlisateurs, des présentations personnalisée de cette BD peuvent être définie. Des frontières sont déifnies autour des données accessibles, certaines données sont agrégées, retravaillées.Nous pouvons par exemple ici définir trois ensemble de vues pour trois applications sur la BD des vins :

1. Application "Gestion des Vins"

vins (nv, cru, mil, deg)

degreMoyenParCru (cru, degMoy)

2. Application "Gestion des Viticulteurs Bordelais"

vitisBordelais(nvt, nom, prenom)

3. Application "Gestion des Buveurs Parisiens"

buveursParis(nb, nom, prenom)

cdesParis(nc, date, nb, nv, qte)

qteCdeeParBuveur(nb, qte)

expeParis( nc, date, qte)

Qu'offre un SGBD relationnel ?

Un SGBD relationnel prend en charge les trois niveaux définis dns l'architecture ANSI /SPARC :

• au niveau conceptuel : le schéma relationnel, les CI peuvent être décrits ;
• au niveau externe : les vues relationnelles peuvent être définies ;
• au niveau physique : les méthodes de placement, les index peuvent être gérées.

 Vues relationnelles

Définition

Une vue relationnelle est une relation dérivée (virtuelle) construite à partir de relations de base et/ou de vues relationnelles.

Une vue est spécifiée par une question. 

Une vue n'est pas une relation de base :

• l'ensemble des tuples d'une vue n'existe pas physiquement ;
• l'ensemble des tuples d'une vue est calculable par l'exécution de la question définissant la vue.

Exemple de vue en SQL 

'Viticulteurs de vins de Bordeaux'

CREATE VIEW vinsBordeaux AS

SELECT VT.nvt, VT.nom, VT.ville

FROM viticulteurs VT, vins V, productions P

WHERE VT.nvt=P.nvt

AND P.nv=V.nv

AND V.cru='Bordeaux' ;

Gestion d'une vue en SQL

La création, la suppression, le renommage d'une vue sont réalisés en SQL.

Création d'une vue

CREATE VIEW < nom vue>

AS < requête d'interrogation select >

Exemples

Vue mono-relation

CREATE VIEW crus(nom)

AS SELECT DISTINCT cru

FROM vins ;

 

Vue multi-relations

CREATE VIEW BuveursBeaujolaisParis (num, nom, qteCdee)

AS SELECT B.nb, B.nom, SUM(qte)

FROM buveurs B, commandes C, vins V

WHERE B.nb=C.nb and C.nv=V.nv AND V.cru='Beaujolais' AND B.ville=`Paris'

GROUP BY B.nb, B.nom ;

 

Vue définie à partir d'une autre vue

Considérons la relation de base PARENT (ASC, DSC)

Comment définir la vue GRAND_PARENT (ASC, DSC) ?

CREATE VIEW GRAND_PARENT (ASC, DSC)

AS SELECT P1.ASC, P2.DSC

FROM PARENT P1, PARENT P2

WHERE P1.DSC=P2.ASC ;

 

comment définir la vue ARR_GRAND_PARENT (ASC, DSC) ?

CREATE VIEW ARR_GRAND_PARENT (ASC, DSC)

AS SELECT P.ASC, GP.DSC

FROM PARENT P, GRAND_PARENT GP

WHERE P.DSC=GP.ASC ;

 Suppression d'une vue

DROP VIEW < nom vue >

 Renommage d'une vue

RENAME VIEW <anc_nom> TO <nouveau_nom>

 Interrogation d'une vue

L'interrogation d'une vue est toujours possible. Une vue est interrogée exactement de la même manière qu'une relation de base, à l'aide d'une requête SELECT. 

SELECT nom

FROM vinsBordeaux ;

 Mise à jour au travers des vues

La mise à jour au travers des vues est très délicate. Dans de nombreux cas elle est impossible. Il est en effet impossible de mettre à jour un tuple d'une vue, qui, rappelez vous n'est que virtuel, s'il ne correpond pas à un et un seul tuple, parfaitement identifiable, dans les relations de base. 

La syntaxe utlisée est identique à celle de la mise à jour des relations de base.

Exemple 1

CREATE VIEW vinsBordeaux

AS SELECT nv, mil, deg

FROM vins

WHERE cru='Bordeaux' ;

UPDATE vinsBordeaux

SET deg = deg * 1,1

WHERE nv = 123 ;

Exemple 2

CREATE VIEW degMoyParCru (cru, degMoy)

AS SELECT cru, AVG(deg)

FROM vins

GROUP BY cru ;

UPDATE degMoyParCru

SET degMoy = degMoy *1,1 ;

Exemple 3

CREATE VIEW BuveursBordeaux (nb, nom, qte)

AS SELECT B.nb, B.nom, SUM(qte)

FROM buveurs B, commandes C, vins V

WHERE B.nbn=C.nb and C.nv=V.nv and
V.cru='Bordeaux'

GROUP BY B.nb, B.nom ;

UPDATE  BuveursBordeaux

SET qte = qte +100

WHERE nb = 123 ; 

Evaluation des vues par un SGBD

Il existe trois tehniques d'évaluation des vues par un SGBD : 

• la modification de question utilisée par INGRES ;
• la restructuration algébrique introduite par SYSTEM/R. C'est cette technique qui est la plus répandue dans les SGBD ;
• la matérialisation de la vue utilisée par SABRE

Modification de question

La modification de question retravaille le code source de la requête. Le principe est de modifier la question Q portant sur la vue V en réintégrant le code décrivant la vue V dans la question Q.

Exemple

CREATE VIEW vins77 AS SELECT nv, cru, deg FROM vins WHERE mil=1977 ;	SELECT nv, cru, deg FROM vins WHERE mil=1977 AND cru<>'Fronsac' ;
SELECT * FROM vins77 WHERE cru <>'Fronsac';

Restructuration algébrique

La restructuration algébrique nécessite une compilation préalable des vues. Le principe est le suivant :

1. fusionner les arbres algébriques résultant de la compilation de la vue V et de la question Q ;
2. optimisation de l'arbre algébrique ainsi obtenu.

Matérialisation de vue

La matérialisation des vues est réalisée à l'exécution de la requête. Le principe estrêmemnt simple est de matérialiser temporairement la vue V par exécution de la requête la spécifiant. La requête sur la vue est ensuite optimisée et exécutée, comme elle le serait sur une relation de base, sur la matérialisation de la vue V.

Critique des vues

Avantages des vues

Les avantages consécutifs à l'utilisation des vues sont nombreux et essentiels au bon fonctionnement d'un SGBD :

• adaptation des données aux applications utilisateur ;
• intégration d'applications existantes;
• dynamique possible du schéma de la base ;
• confidentialité des données ;
• définition de contraintes d'intégrité (option check de
  SQL 86)

Inconvénients des vues

Le principal inconvénients est la limite dans les mises à jour au travers des vues qui sont en général impossible.

Vues et CIs

Il est possible d'ajouter des CIs lors de la définition des vues.

Contexte

La norme SQL86 introduit l'ajout de CI lors de la définition de vue (il s'agit de la clause CHECK associée au CREATE VIEW). Seules les vues autorisées en mise à jour sont concernées par cela.

Exemples

CI de domaine

CREATE VIEW vinsOK

AS SELECT *

FROM Vins

WHERE deg >= 8 AND deg <= 13

WITH CHECK OPTION ;

CI référentielle

CREATE VIEW productionsOK

AS SELECT P.*

FROM productions P,

WHERE P.nv IN (SELECT nv FROM vins)

AND P.nvt IN (SELECT nvt FROM viticulteurs)

WITH CHECK OPTION ;

Posté le 28 août 2009