Database Reference
In-Depth Information
Et voici les données présentées par cette vue.
TVA_TYPE TVA_DATE_DEBUT_APPLICATION
TVA_DATE_FIN_APPLICATION
TVA_TAUX
---------------- ---------------------------- --------------------------- --------
Super Réduit 1982-07-01 1988-12-31 5,5
Super Réduit 1989-01-01 9999-12-31 NULL
Réduit 1968-01-01
1968-11-30 6,38
Réduit 1968-12-01
1969-12-31
7,53
Réduit 1970-01-01
1972-12-31
7,5
Réduit 1973-01-01
1988-12-31
7
Réduit 1989-01-01
9999-12-31
5,5
Intermédiaire 1968-01-01 1968-11-30
14,92
Intermédiaire 1968-12-01 1969-12-31
15,65
Intermédiaire 1970-01-01 1982-06-30
17,6
Intermédiaire 1982-07-01 9999-12-31 NULL
Normal 1968-01-01 1968-11-30 20
Normal 1968-12-01 1969-12-31 23,46
...
Ce serait une énorme faute que de rajouter à la table une date de in d'application, car en cas d'erreur de
saisie, on pourrait se retrouver soit avec plusieurs taux différents pour un même jour, soit aucun…
À noter : la présence d'une ligne avec un taux à
NULL
signiie tout simplement la disparition de ce taux
de TVA !
Contrôles d'intégrité référentielle
Une vue peut contrôler la validité des références entre tables. En l'absence du mécanisme de
clés étrangères, vous pouvez programmer l'intégrité référentielle (un autre moyen plus coûteux
est d'utiliser des déclencheurs).
La.cohérence.référentielle.entre.deux.tables.
t1
.(table.« parent »).et.
t2
.(table.« enfant »).se.
programme :
•. du.parent.vers.l'enfant.par.l'utilisation.d'une.vue.
v1
.de.la.table.
t1
.définie.avec.la.clause.
NOT
EXISTS
;
•. de.l'enfant.vers.le.parent.par.l'utilisation.d'une.vue.
v2
.de.la.table.
t2
.définie.avec.la.clause.
WITH CHECK OPTION
.
Considérons la table des départements (renommée
t1
et jouant le rôle de parent :
CREATE
TABLE t1 AS SELECT * FROM hr.departments
) et celle des employés (renommée
t2
et jouant le rôle de l'enfant :
CREATE
TABLE t2 AS SELECT * FROM hr.employees
).
Puisqu'il n'existe aucune clé étrangère entre ces tables, les vues à créer sont les suivantes.
