Bonsoir,
Envoyé par
Waldar
Comment Date envisage de gérer le cas de colonnes non-nulles sans attribut DEFAULT :
1 2 3
| create table t1 (c1 int not null, c2 int not null);
create view v1 as select c1 from t1; |
On fait comment pour insérer dans la vue ?
On fait comme pour insérer dans la table (laquelle, en passant, est ici un sac puisqu’elle n’a pas de clé). Les instructions :
INSERT INTO V1 (C1) VALUES (1) ;
et
INSERT INTO T1 (C1) VALUES (1) ;
sont interchangeables, ce qui vaut pour l’une vaut pour l’autre. En l’occurrence (comme l’a signalé le vaillant Oishiiii) il y a rejet de l’opération puisqu’il n’y a pas de valeur par défaut prévue pour la colonne C2.
Pour en dire un peu plus : la vue en cause correspond à une opération de projection et comme dans la discussion traitant des préliminaires de la mise à jour des vues de jointure, je me réfère à ce qu’écrit Date dans An Introduction to Database Systems, Eighth Edition (Addison Wesley), page 311.
Comme on doit parler de prédicat de relvar, Je rappelle au préalable que l’éternel exemple de Date est le suivant (et dont se sert aussi Oishiiii à l’occasion de sa réponse) :
Relvar des fournisseurs :
1 2 3 4 5 6
| VAR S BASE RELATION
{SNO CHAR,
SNAME CHAR,
STATUS INTEGER,
CITY CHAR}
KEY {SNO} ; |
Qui a pour prédicat PS (son intension si vous préférez, et prenant la valeur soit VRAI, soit FAUX) :
Le fournisseur SNO a pour nom SNAME, il a pour statut STATUS et il est localisé dans la ville CITY.
A signaler que le prédicat d'une relvar intègre les contraintes définies pour cette relvar (par exemple la clé candidate définie par la clause KEY pour la relvar S).
Dans le cas général, soit A une relvar de prédicat PA et dont on partitionne les attributs en deux groupes disjoints, disons X et Y. Considérons X comme un seul attribut composé, même chose pour Y et soit A{X} la projection de A sur X. Soit (x) un tuple (ligne en SQL) de cette projection, laquelle a un prédicat qui ressemble à ceci :
Pour tous les (x), il existe un (y) du domaine des valeurs de Y tel que le tuple (x, y) vérifie le prédicat PS de la relvar S.
Si on considère par exemple la projection S{X} de la relvar S sur SNO, SNAME et CITY, chaque tuple (s, n, c) appartenant à cette projection est tel qu’il existe une valeur t de statut tel que le tuple (s, n, t, c) vérifie le prédicat PS.
Les règles pour mettre à jour A{X} sont les suivantes :
INSERT :
Soit (x) le tuple à insérer et y la valeur par défaut de Y (l’absence de valeur par défaut se traduit par une erreur comme évoqué plus haut), le tuple (x, y) (qui doit respecter le prédicat PA) est inséré dans A.
DELETE :
Tous les tuples de A qui ont la même valeur X que le tuple à supprimer de A{X} sont supprimés de A.
UPDATE :
Soit (x) le tuple à modifier et (x’) le tuple de remplacement. Soit a un tuple de A dont la valeur pour X est égale à x et soit y la valeur de Y dans a. Tous les tuples tels que a sont supprimés de A (sans déclenchement automatique d’actions quelconques ni de contrôles de prédicats). Ensuite, le tuple (x’, y) — qui doit respecter PA — est inséré dans A. (Bien entendu, Date fournit des indications plus précises pour raffiner cette description qui pourrait paraître un peu fruste à d’aucuns).
A propos des valeurs par défaut :
Dans leur ouvrage de référence Databases, Types, and the Relational Model The Third Manifesto (Third Edition), Chris Date et Hugh Darwen laissent le soin aux SGBD de type D (c'est-à-dire se référant à Tutorial D) de définir un mécanisme du genre « valeurs par défaut », mais pas forcément ce lui qu’on connaît traditionnellement en SQL et ils ne veulent pas forcer la main de ceux qui modélisent et proposent ces SGBD. Se reporter aux pages 215 et 425 de l’ouvrage.
Pour ne pas innover, on peut par exemple considérer ici un scénario orienté SQL pour la relvar S :
1 2 3 4 5 6 7 8 9
| VAR S BASE RELATION
{SNO CHAR,
SNAME CHAR,
STATUS INTEGER,
CITY CHAR}
KEY {SNO}
DEFAULT {SNAME ''}
DEFAULT {STATUS 10}
DEFAULT {CITY ''} ; |
Waldar, ai-je répondu à votre question ?
[EDIT]
A la page 312 de son Introduction, Chris Date donne des exemples de mise à jour d’une vue de projection.
Vue à mettre à jour :
1 2 3 4 5 6 7
| SC SNO CITY
S1 London
S2 Paris
S3 Paris
S4 London
S5 Athens |
Quelques tentatives caractéristiques de mise à jour de la vue SC :
— La tentative d’ajout dans SC du tuple (S6, Athens) sera couronnée de succès. Au résultat il y aura ajout du tuple (S6, n, t, Athens) dans la relvar de base S, où n et t sont les valeurs par défaut respectives des attributs SNAME et STATUS.
— La tentative d’ajout dans SC du tuple (S1, Athens) échouera parce que le prédicat PS de la relvar S n’est pas respecté (donc celui de la vue SC) : en effet, il y a là une tentative de créer la valeur clé S1 en double.
— La tentative de suppression dans SC du tuple (S4, London) sera couronnée de succès, avec pour conséquence la suppression dans la relvar S du tuple correspondant à S4.
— La tentative de remplacement dans SC du tuple (S1, London) par le tuple (S1, Athens) sera couronnée de succès. Supposons que le tuple correspondant dans la relvar S soit (S1, Smith, 20, London) : il sera remplacé par le tuple (S1, Smith, 20, Athens).
— La tentative de remplacement dans SC du tuple (S1, London) par le tuple (S2, London) échouera. J’espère que tout le monde saura expliquer pourquoi.
Partager