Database Reference
In-Depth Information
Schéma relationnel (
suite
)
Script SQL (
suite
)
CREATE TABLE manager (
idpers
INTEGER NOT NULL,
nbhmois INTEGER,
projet VARCHAR2(60),
nom
VARCHAR2(40),
indice
INTEGER,
CONSTRAINT pk_manager
PRIMARY KEY (idpers));
Contrainte de partition
La contrainte de partition (notation
{complete, disjoint}
avec UML) interdit les scéna-
rios suivants.
●
Un personnel appartient simultanément à plusieurs classiications (commercial, manager
ou administratif).
●
Un personnel n'est associé à aucune classiication (ni commercial, ni manager, ni admi-
nistratif).
La première règle de gestion s'implémente à l'aide de trois déclencheurs : un sur chaque table
spéciique. Il s'agit d'interdire qu'un manager de numéro 100 soit également référencé dans
une autre table spéciique avec ce même numéro (
commercial
et
administratif
). Le
raisonnement devra s'appliquer à l'identique pour les tables des commerciaux et celle des
administratifs. Le code du déclencheur est décrit au paragraphe précédent.
La deuxième règle s'implémente naturellement du fait de l'inexistence d'une table générique.
Ici seuls managers, commerciaux ou administratifs peuvent être stockés.
Totalité ou absence de contrainte
La contrainte de totalité (notation UML
{complete, overlapping}
) et l'absence de
contrainte (notation UML
{incomplete, overlapping}
) autorisent le scénario dans lequel
un personnel n'est associé à aucune classiication (ni commercial et ni manager ou adminis-
tratif).
Cette contrainte est impossible à mettre en œuvre du fait de l'inexistence d'une table géné-
rique. Si telle est la contrainte à implémenter, vous devrez opter pour une autre décomposition
de l'héritage (distinction ou
push-up
).
Héritage en push-up
Suivant le principe de la décomposition ascendante, seule la table générique est créée et ras-
semble toutes les colonnes des tables génériques.
