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 introduction.
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"2. Application "Gestion des Viticulteurs Bordelais"vins (nv, cru, mil, deg)
degreMoyenParCru (cru, degMoy)
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)
Un SGBD relationnel prend en charge les trois niveaux définis dns l'architecture ANSI /SPARC :
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 :
'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' ;
La création, la suppression, le renommage d'une vue sont réalisés en SQL.
CREATE VIEW < nom vue>AS < requête d'interrogation select >
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 ;
DROP VIEW < nom vue >
RENAME VIEW <anc_nom> TO <nouveau_nom>
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 ;
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.
CREATE VIEW vinsBordeaux
AS SELECT nv, mil, deg
FROM vins
WHERE cru='Bordeaux' ;
UPDATE vinsBordeaux
SET deg = deg * 1,1
WHERE nv = 123 ;
CREATE VIEW degMoyParCru (cru, degMoy)
AS SELECT cru, AVG(deg)
FROM vins
GROUP BY cru ;
UPDATE degMoyParCru
SET degMoy = degMoy *1,1 ;
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 ;
Il existe trois tehniques d'évaluation des vues par un SGBD :
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'; |
La restructuration algébrique nécessite une compilation préalable des vues. Le principe est le suivant :
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.
Les avantages consécutifs à l'utilisation des vues sont nombreux et essentiels au bon fonctionnement d'un SGBD :
Le principal inconvénients est la limite dans les mises à jour au travers des vues qui sont en général impossible.
Il est possible d'ajouter des CIs lors de la définition des vues.
CREATE VIEW vinsOK
AS SELECT *
FROM Vins
WHERE deg >= 8 AND deg <= 13
WITH CHECK OPTION ;
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 ;