1 Dictionnaire des données 1.1. Un seul index est défini sur la table

1 Dictionnaire des données
1.1. Un seul index est défini sur la table PAYS : country_key
1.2. Le fichier pays.sql ne mentionne aucune création manuelle d’index. PostgreSQL crée un
index sur la clé primaire.
1.3. CREATE INDEX population_index ON pays (population)
On peut vérifier que l’index a bien été créé en faisant \d pays.
1.4. La commande ANALYZE Pays; collecte des statistiques sur la table Pays.
1.5. La commande ANALYZE VERBOSE Pays; indique que la table pays utilise 8 pages/blocs
pour 265 n-uplets.
1.6. SELECT viewname FROM pg_views WHERE viewname LIKE ’pg_%’ ;
ou, plus simplement : \dS
1.7. SELECT * FROM pg_stats WHERE tablename = ’pays’ ;
Pour chaque champ, l’attribut n_distinct représente le nombre estimé de valeurs distinctes. Si la
valeur est négative, il faut multiplier par -1 puis par le nombre d’enregistrements pour obtenir une
valeur humainement lisible. Une valeur de -1 représente donc un champ pour lequel chaque
enregistrement de la table a une valeur différente.
1.8. SELECT * FROM pg_stat_user_indexes WHERE relname = ’pays’ ;
2 Utilisateurs, vues et autorisations
2.1. CREATE USER équivaut à CREATE ROLE WITH LOGIN.
CREATE USER user1 WITH PASSWORD ’xxxxxxxxx’ ;
CREATE USER user2 WITH PASSWORD ’yyyyyyyyy’ ;
Les utilisateurs sont donc :
– Utilisateur A = ”moi”
– Utilisateur B = ”user1”
– Utilisateur C = ”user2”
2.2.
\i /chemin/vers/le/fichier/film.sql
\i /chemin/vers/le/fichier/acteur.sql
\i /chemin/vers/le/fichier/casting.sql
2.3. On crée le groupe TP1 de façon à ce que :
– personne ne puisse se connecter en tant que TP1 (NOLOGIN)
– les membres de ce groupe ne recoivent pas les privilèges supplémentaires qui
pourraient être accordés au rôle TP1 (NOINHERIT)
– tout membre de ce groupe puisse créer des bases de données (CREATEDB) et des rôles
(CREATEROLE)
ce qui donne CREATE ROLE TP1 NOLOGIN NOINHERIT CREATEDB CREATEROLE ;
On a joute ensuite les trois utilisateurs à ce groupe :
GRANT TP1 to moi ;
GRANT TP1 to user1 ;
GRANT TP1 to user2 ;
On peut lister les utilisateurs appartenant au groupe tp1 avec la requête suivante :
SELECT usename
FROM pg_group, pg_user
WHERE usesysid = ANY (grolist)
AND groname = ’tp1’ ;
2.4. On crée la vue : CREATE VIEW FILM VUE AS SELECT * FROM film ;
Par défaut, TP1 n’a aucun droit sur film ou film_vue. On accorde le droit de lecture sur film vue
avec la requête suivante : GRANT SELECT ON FILM_VUE TO TP1 ;
Après cela, \z film vue indique que l’utilisateur postgres a les droits ”arwdRxt” sur la vue
film vue tandis que le groupe tp1 n’a que le droit ”r”.
2.6.1. Pour n’attribuer l’accès qu’aux films datant de 2001 et 2002, on peut utiliser une vue :
CREATE VIEW films_0102 AS SELECT * FROM filmXX WHERE annee IN (2001, 2002) ;
GRANT SELECT ON films_0102 TO user1 ;
2.6.2. Même raisonnement :
CREATE VIEW films 2003 AS SELECT * FROM filmXX WHERE annee = 2003 ;
GRANT SELECT ON films_2003 TO user1, user2 ;
2.6.3. Le standard SQL prévoit la possiblité de céder des droits sur les attributs d’une table,
PostgreSQL ne le permettait pas ; mais on pouvait tout de même appliquer le raisonnement
précedent : créer une vue puis donner des droits sur cette vue.
CREATE VIEW film_nonote AS SELECT id, titre, annee, realisateur FROM filmXX ;
GRANT SELECT, DELETE, UPDATE ON film_nonote TO user1 ;
Désormais:
GRANT SELECT, DELETE, UPDATE (id,titre,annee, realisateur) ON filmXX TO user1;
2.6.4. L’utilisateur A peut autoriser l’utilisateur B à céder à nouveaux les droits avec l’option
”WITH GRANT OPTION” : GRANT SELECT, INSERT ON filmXX TO user1 WITH GRANT OPTION
L’utilisateur B peut alors partager ces droits avec l’utilisateur C : GRANT ALL ON filmXX TO
user2 ;
L’utilisateur C est alors en mesure d’insérer un film dans la table filmXX : INSERT INTO filmXX
VALUES(1234, ’Le seigneur de SQL : Les deux Rollbacks’, 2010, 0.9, 45, 18) ;
L’utilisateur A annule les droits de l’utilisateur B (avec le mot-clé CASCADE, sinon PostgreSQL
signale les dépendances de privilèges et génère une erreur) : REVOKE ALL ON filmXX FROM
user2 CASCADE
L’utilisateur C n’a alors plus aucun droit sur la table concernée (tout comme l’utilisateur B).
2.6.5. Lors de la suppression des privilèges de l’utilisateur B par l’utilisateur A, PostgreSQL
génère la même erreur que dans le 2.6.4, obligeant à utiliser le mot-clé CASCADE. Après
application du REVOKE adapté, B ne peut plus insérer de films dans filmXX.
3 Triggers
1. Création des triggers :
CREATE RULE on_insert_note_film AS ON INSERT TO filmXX DO INSERT INTO film_audit
VALUES (now(), user, ’INSERT’, new.id, NULL, new.note) ;
CREATE RULE on_update_note_film AS ON UPDATE TO filmXX WHERE old.note != new.note DO
INSERT INTO film_audit VALUES (now(), user, ’UPDATE’, new.id, old.note, new.note) ;
CREATE RULE on_delete_note_film AS ON DELETE TO filmXX DO INSERT INTO
film_audit VALUES (now(), user, ’DELETE’, old.id, old.note, NULL) ;
2. Un autre utilisateur effectue les requêtes suivantes :
# on insère un film :
INSERT INTO filmXX values(78945, ’Le retour d\’Oracle’, ‘2010’, 5, 1, 360) ;
# on change la note d’un film :
UPDATE filmXX set note = 1 WHERE id = 78945 ;
# on supprime un film :
DELETE FROM filmXX WHERE id = 78945 ;
L’utilisateur ayant posé les triggers peut alors faire SELECT * FROM film_audit ; pour constater
que la table film_audit contient trois enregistrements décrivant les requêtes effectuées
précédemment.