Database Reference
In-Depth Information
Tableau 3-11 : Transformation de l'héritage en push-up
Schéma relationnel
Script SQL
DROP TABLE personnel CASCADE CONSTRAINTS;
CREATE TABLE personnel (
idpers INTEGER NOT NULL,
nom VARCHAR2(40),
indice INTEGER,
prime FLOAT,
nbhmois INTEGER,
projet VARCHAR2(60),
syndicat VARCHAR2(254),
nbheuressupp INTEGER,
CONSTRAINT pk_personnel
PRIMARY KEY (idpers));
Figure 3-11
. Héritage par push-up
Contrainte d'exclusivité
La contrainte d'exclusivité interdit le fait qu'un personnel appartienne à plusieurs classiica-
tions (commercial, manager ou administratif) tout en permettant à un personnel de n'être
rattaché à aucune classiication.
La première règle de gestion s'implémente à l'aide d'une contrainte de vériication (
CHECK
).
Il s'agit d'interdire que toutes les colonnes provenant des tables spéciiques disposent toutes
d'une valeur. Si les colonnes relatives à un manager sont renseignées, alors les autres (relatives
aux commerciaux et aux administratifs) doivent être nulles. Le même raisonnement devra
s'appliquer pour les colonnes des commerciaux et des administratifs.
Le tableau suivant présente cette contrainte ainsi que quelques insertions valides et une inva-
lide (personnel à la fois commercial et administratif).
Tableau 3-12 : Contrainte d'exclusivité pour l'héritage push-up
Contrainte d'exclusivité
Jeu d'essai
-- commercial
INSERT INTO personnel VALUES
(100,'F. Brouard',500,47800,NULL,NULL,NULL,NULL);
1 row created.
ALTER TABLE personnel
ADD CONSTRAINT ck_exclusivite
CHECK
((projet IS NOT NULL AND nbhmois IS NOT NULL
AND prime IS NULL
AND syndicat IS NULL
AND nbheuressupp IS NULL)
-- manager
INSERT INTO personnel VALUES
