Database Reference
In-Depth Information
Cohérence fils
→
père (
suite
)
Cohérence père
→
fils (
suite
)
Insertion.incorrecte.(le.département.999.est.un.parent.
absent) :
INSERT INTO v2
(employee_id, irst_name, last_name, email,
hire_date, job_id, salary, commission_pct,
manager_id, department_id )
VALUES (98,'Fred','Comby','bezier',
SYSDATE,'IT_PROG',5400,0,100,
999
);
Modification.correcte :
UPDATE v2
SET department_id = 10
WHERE employee_id=99;
Modification.correcte.(le.département.900.n'a.aucun.
employé) :
UPDATE v1
SET department_id = 77
WHERE department_id = 900;
Modification.incorrecte.(parent.absent) :
UPDATE v2
SET department_id =
999
WHERE employee_id=99;
Modification.incorrecte.(enfant.présent :.le.département.
90.a.des.employés.et.le.mécanisme.de.cascade.n'est.
pas.pris.en.compte) :
UPDATE v1
SET department_id = 77
WHERE department_id = 90;
Suppression.correcte.(enfants.absents) :
DELETE FROM v1
WHERE department_id = 900;
Toute.suppression.est.possible.à.travers.la.vue.
v2
.(sous.
réserve.de.l'existence.d'autres.contraintes.référentielles).
Suppression.incorrecte.(enfants.présents) :
DELETE FROM v1
WHERE department_id = 90;
Le raisonnement sur deux tables peut se généraliser à une hiérarchie d'associations ou à diffé-
rentes associations issues de la même table.
Un avantage spectaculaire et peu connu des vues : les contraintes dynamiques
Dans une base de données, les contraintes sont statiques, c'est-à-dire qu'elles empê-
chent d'introduire des données qui ne respectent pas les règles. Mais comment faire pour
stocker quand même certaines données intermédiaires et ne présenter aux utilisateurs
que les ensembles de données valides ? La réponse est une vue… Imaginons un géomètre
qui doit stocker dans une table ses relevés de mesure de parcelles de terrain. Voici la
table :
