Bonsoir,
Envoyé par
Zizoua
Un utilisateur occupe un bureau et pour toujours? ou il peut changer de bureau? si tel n'est pas le cas regardez au niveau de votre schéma pour la cardinalité (1,1), ne serait elle pas (1,N) et à une date donnée? entre utilisateur et occupe.
Supposons que djamel_c réponde ainsi : « Un utilisateur peut changer de bureau, mais on ne suit pas ses changements successifs ». Dans ces conditions, la cardinalité 1,1 reste valable.
Mais un problème intéressant se pose : qu’advient-il de l’affectation au bureau B1 du matériel M1 affecté par ailleurs à l’utilisateur U1 ?
Ou bien la règle est la suivante :
(R1) Le matériel M1 reste affecté à l’utilisateur U1 et le suit dans son nouveau bureau B2 quand il déménage ;
Ou bien la règle est la suivante :
(R2) Le matériel M1 reste affecté au bureau B1 et n’est donc plus affecté à l’utilisateur U1, lequel devra être doté d’un matériel M2 lors de son arrivée dans le bureau B2.
Exemple de script SQL au cas où appliquerait la règle R1 :
CREATE TABLE MATERIEL
(
id_materiel INT NOT NULL
, code_barres CHAR(13) NOT NULL
, libelle_mat VARCHAR(32) NOT NULL
, CONSTRAINT MATERIEL_PK PRIMARY KEY (id_materiel)
, CONSTRAINT MATERIEL_AK UNIQUE (code_barres)
) ;
CREATE TABLE STRUCTURE
(
id_structure INT NOT NULL
, code_structure VARCHAR(8) NOT NULL
, libelle_structure CHAR(32) NOT NULL
, CONSTRAINT STRUCTURE_PK PRIMARY KEY (id_structure)
, CONSTRAINT STRUCTURE_AK UNIQUE (code_structure)
) ;
CREATE TABLE BUREAU
(
id_structure INT NOT NULL
, id_bureau INT NOT NULL
, code_bureau VARCHAR(8) NOT NULL
, CONSTRAINT BUREAU_PK PRIMARY KEY (id_structure, id_bureau)
, CONSTRAINT BUREAU_AK UNIQUE (code_bureau)
, CONSTRAINT BUREAU_STRUCTURE_FK FOREIGN KEY (id_structure)
REFERENCES STRUCTURE (id_structure)
) ;
CREATE TABLE UTILISATEUR
(
id_utilisateur INT NOT NULL
, code_utilisateur VARCHAR(8) NOT NULL
, nom_utilisateur VARCHAR(32) NOT NULL
, CONSTRAINT UTILISATEUR_PK PRIMARY KEY (id_utilisateur)
, CONSTRAINT UTILISATEUR_AK UNIQUE (code_utilisateur)
) ;
CREATE TABLE UTILISATEUR_BUREAU
(
id_utilisateur INT NOT NULL
, id_structure INT NOT NULL
, id_bureau INT NOT NULL
, CONSTRAINT UTILISATEUR_BUREAU_PK PRIMARY KEY (id_utilisateur)
, CONSTRAINT UTILISATEUR_BUREAU_SK UNIQUE (id_utilisateur, id_structure, id_bureau)
, CONSTRAINT UTILISATEUR_BUREAU_UTILISATEUR_FK FOREIGN KEY (id_utilisateur)
REFERENCES UTILISATEUR (id_utilisateur)
, CONSTRAINT UTILISATEUR_BUREAU_BUREAU_FK FOREIGN KEY (id_structure, id_bureau)
REFERENCES BUREAU (id_structure, id_bureau)
) ;
CREATE TABLE AFFECTATION
(
id_materiel INT NOT NULL
, id_affectation INT NOT NULL
, debut_affectation DATE NOT NULL
, fin_affectation DATE NOT NULL
, libelle_mat VARCHAR(32) NOT NULL
, id_structure INT NOT NULL
, id_bureau INT NOT NULL
, id_utilisateur INT NOT NULL
, CONSTRAINT AFFECTATION_PK PRIMARY KEY (id_materiel, id_affectation)
, CONSTRAINT AFFECTATION_AK UNIQUE (id_materiel, debut_affectation)
, CONSTRAINT AFFECTATION_MATERIEL_FK FOREIGN KEY (id_materiel)
REFERENCES MATERIEL (id_materiel)
, CONSTRAINT AFFECTATION_BUREAU_FK FOREIGN KEY (id_structure, id_bureau)
REFERENCES BUREAU (id_structure, id_bureau)
, CONSTRAINT AFFECTATION_UTILISATEUR_FK FOREIGN KEY (id_utilisateur, id_structure, id_bureau)
REFERENCES UTILISATEUR_BUREAU (id_utilisateur, id_structure, id_bureau) ON UPDATE CASCADE
) ;
La clé primaire UTILISATEUR_BUREAU_PK de la table UTILISATEUR_BUREAU est le singleton {id_utilisateur}, mais pour éviter d’avoir à mettre en œuvre des triggers pour contrôler les déménagements des utilisateurs et de leurs matériels, on utilise les services d’une surclé UTILISATEUR_BUREAU_SK {id_utilisateur, id_structure, id_bureau}.
Pour garantir la cohérence des affectations des matériels aux bureaux lors des déménagements, on CASCADE sur la table AFFECTATION les mises à jour de la table UTILISATEUR_BUREAU.
Exemple d’affectation :
INSERT INTO MATERIEL (id_materiel, code_barres, libelle_mat) VALUES (1, '1234567890123', 'matos 1') ;
INSERT INTO MATERIEL (id_materiel, code_barres, libelle_mat) VALUES (2, '1234567890124', 'matos 2') ;
INSERT INTO STRUCTURE (id_structure, code_structure, libelle_structure) VALUES (1, 's1', 'structure 1') ;
INSERT INTO STRUCTURE (id_structure, code_structure, libelle_structure) VALUES (2, 's2', 'structure 2') ;
INSERT INTO BUREAU (id_structure, id_bureau, code_bureau) VALUES (1, 1, 'b10') ;
INSERT INTO BUREAU (id_structure, id_bureau, code_bureau) VALUES (1, 2, 'b12') ;
INSERT INTO BUREAU (id_structure, id_bureau, code_bureau) VALUES (2, 1, 'b27') ;
INSERT INTO UTILISATEUR (id_utilisateur, code_utilisateur, nom_utilisateur) VALUES (1, 'u1', 'Raoul') ;
INSERT INTO UTILISATEUR_BUREAU (id_utilisateur, id_structure, id_bureau) VALUES (1, 1, 1) ;
INSERT INTO AFFECTATION (id_materiel, id_affectation, debut_affectation, fin_affectation, libelle_mat, id_structure, id_bureau, id_utilisateur) VALUES (1, 1, '2016-04-19', '9999-12-31', 'm1', 1, 1, 1) ;
=>
AFFECTATION
id_materiel id_affectation debut_affectation fin_affectation libelle_mat id_structure id_bureau id_utilisateur
1 1 2016-04-19 9999-12-31 m1 1 1 1
L’utilisateur u1 déménage dans un bureau d’une autre structure :
UPDATE UTILISATEUR_BUREAU SET id_structure = 2, id_bureau = 1 WHERE id_utilisateur = 1 ;
=>
AFFECTATION
id_materiel id_affectation debut_affectation fin_affectation libelle_mat id_structure id_bureau id_utilisateur
1 1 2016-04-19 9999-12-31 m1 2 1 1
Partager