Discussion :

[djamel_c]

bonsoir Zizoua ,fsmrel et escartefigue

je m'excuse pour le retard je suis vraiment désolé

bon par rapport aux affectations les règles de gestion de l'entreprise étaient un peu ambigus finalement une affectation se fait à un bureau et la connaissance de l'utilisateur est souhaitée (une indication).

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.

[/pre]

oui l'utilisateur peut changer de bureau mais on ne suit pas ses changements successifs et c'est la règle R2 qui est appliqué.

pour la maintenance chaque panne donne lieu à une opération de maintenance ce n'est pas toujours la même panne

[fsmrel]

Bonsoir djamel_c,


Affectation des matériels

Une affectation se fait à un bureau et la connaissance de l'utilisateur est souhaitée (une indication).
c'est la règle R2 qui est appliquée.

D’accord.

MCD des affectations (avec l’AGL DB-MAIN) :





L’entité-type MAT_UTI permet de savoir quels sont les utilisateurs auxquels un matériel est affecté.

L’entité-type AFFECTATION_HISTO permet de savoir quelles furent les périodes durant lesquelles des matériels furent affectés avant leur affection actuelle.


Attention ! il y aura des contraintes à mettre en œuvre (liste non exhaustive) :

— Si on affecte le matériel m1 à l’utilisateur u1, le bureau où se trouve u1 doit être le bureau auquel on a affecté m1 ;

— Si l’utilisateur u1 quitte le bureau b1, et si le matériel m1 lui est affecté, alors il faut supprimer l’affectation de m1 à u1. En effet m1 reste affecté à b1 ;

— Si le matériel m1 change de bureau et si m1 est affecté à l’utilisateur u1, alors il faut supprimer l’affectation de m1 à u1.

— Etc.

=> Petites causes, mai grandes conséquences sur la validité de la base de données...



Maintenance des matériels

pour la maintenance chaque panne donne lieu à une opération de maintenance ce n'est pas toujours la même panne.

Votre MCD va dans ce sens :

Un matériel peut subir plusieurs pannes ;

Une panne est subie par au moins et au plus un matériel ;

Une panne peut le cas échant faire l’objet d’une opération de maintenance.

Cela dit, vous pourriez définir une entité-type recensant les types de panne possibles, ne serait-ce que pour savoir quelles sont les types de panne les plus fréquents :

[PANNE]--1,1-------------(PANNE_EST_DE_TYPE)--------0,N--[TYPE_PANNE]

[fsmrel]

En complément, le script SQL de création des tables correspondant au MCD précédent :

CREATE TABLE STRUCTURE 
(
        id_structure                INT                NOT NULL
      , code_structure              VARCHAR(8)         NOT NULL
      , libelle_structure           VARCHAR(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
      , nom_utilisateur             VARCHAR(32)        NOT NULL
      , code_utilisateur            VARCHAR(8)         NOT NULL
      , id_structure                INT                NOT NULL
      , id_bureau                   INT                NOT NULL
    , CONSTRAINT UTILISATEUR_PK PRIMARY KEY (id_utilisateur)
    , CONSTRAINT UTILISATEUR_AK UNIQUE (code_utilisateur)
    , CONSTRAINT UTILISATEUR_BUREAU_FK FOREIGN KEY (id_structure, id_bureau)
          REFERENCES BUREAU (id_structure, id_bureau)
);

CREATE TABLE MATERIEL 
(
        id_materiel                 INT                NOT NULL
      , code_barres                 CHAR(13)           NOT NULL
      , libelle_mat                 VARCHAR(32)        NOT NULL
      , date_acquisition            DATE               NOT NULL
      , valeur_acquisition          INT                NOT NULL
      , date_affectation_bureau     DATE               NOT NULL
      , id_structure                INT                NOT NULL
      , id_bureau                   INT                NOT NULL
    , CONSTRAINT MATERIEL_PK PRIMARY KEY (id_materiel)
    , CONSTRAINT MATERIEL_AK UNIQUE (code_barres)
    ,  CONSTRAINT MATERIEL_DATE_AFF_CHK CHECK (date_affectation_bureau >= date_acquisition)
    , CONSTRAINT AFFECTATION_BUREAU_FK FOREIGN KEY (id_structure, id_bureau)
          REFERENCES BUREAU (id_structure, id_bureau)
);

CREATE TABLE MAT_UTI 
(
        id_materiel                 INT                NOT NULL
      , date_aff_uti                DATE               NOT NULL
      , id_utilisateur              INT                NOT NULL
    , CONSTRAINT MAT_UTI_PK PRIMARY KEY (id_materiel)
    , CONSTRAINT MAT_UTI_MATERIEL_FK FOREIGN KEY (id_materiel)
          REFERENCES MATERIEL (id_materiel)
    , CONSTRAINT MAT_UTI_UTILISATEUR_FK FOREIGN KEY (id_utilisateur)
          REFERENCES UTILISATEUR (id_utilisateur) ON DELETE CASCADE
);

CREATE TABLE AFFECTATION_HISTO 
(
        id_materiel                 INT                NOT NULL
      , periode_affectation         DATERANGE          NOT NULL
      , id_structure                INT                NOT NULL
      , id_bureau                   INT                NOT NULL
    , CONSTRAINT AFFECTATION_HISTO_PK PRIMARY KEY (id_materiel, periode_affectation)
    , CONSTRAINT AFFECTATION_HISTO_MATERIEL_FK FOREIGN KEY (id_materiel)
          REFERENCES MATERIEL (id_materiel) ON DELETE CASCADE
    , CONSTRAINT AFFECTATION_HISTO_BUREAU_FK FOREIGN KEY (id_structure, id_bureau)
          REFERENCES BUREAU (id_structure, id_bureau)     
);

Un début de jeu d’essai :

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, id_structure, id_bureau) VALUES (1, 'u1', 'Raoul', 1, 1) ;
INSERT INTO UTILISATEUR (id_utilisateur, code_utilisateur, nom_utilisateur, id_structure, id_bureau) VALUES (2, 'u2', 'Fernand', 2, 1) ;

INSERT INTO MATERIEL (id_materiel, code_barres, libelle_mat, date_acquisition, valeur_acquisition, date_affectation_bureau, id_structure, id_bureau) 
    VALUES (1, '1234567890123', 'matos 1', '2016_01_01', 100, '2016_01_02', 1, 1) ;

INSERT INTO MATERIEL (id_materiel, code_barres, libelle_mat, date_acquisition, valeur_acquisition, date_affectation_bureau, id_structure, id_bureau) 
    VALUES (2, '1234567890124', 'matos 2', '2016_01_01', 200, '2016_01_02', 1, 2) ;

INSERT INTO MAT_UTI (id_materiel, date_aff_uti, id_utilisateur) VALUES (1, '2016_01_02', 2) ;

INSERT INTO AFFECTATION_HISTO (id_materiel, periode_affectation, id_structure, id_bureau) VALUES (1, '[2015-01-01, 2015-12-31]', 2, 1) ;

[djamel_c]

bonsoir Mr fsmrel

Je tiens à vous remercier, vous m'avez beaucoup aidé et j'ai appris des bonnes choses dans ce forum.
concernant les identifiants(clés primaires) es que je peu les déclarer Auto-increment?

[escartefigue]

bonsoir Mr fsmrel

Je tiens à vous remercier, vous m'avez beaucoup aidé et j'ai appris des bonnes choses dans ce forum.
concernant les identifiants(clés primaires) es que je peu les déclarer Auto-increment?

Bonsoir,

Je me permets de répondre bien que le message soit adressé nominativement

Les identifiants attribués par le SGBD sont une solution pratique en effet pour s'affranchir de la gestion de l'unicité des identifiants sous réserve d'avoir bien assimilé que
- vous ne maitriserez pas la valeur attribuée par le SGBD en dehors de la valeur de départ et de celle de l'incrément (voire décrément selon le sgbd)
- vous n'avez aucune garantie que les valeurs soient contigües, des trous de numérotation sont inévitables
- vous ne pourrez nullement utiliser ces valeurs attribuées par le système pour en déduire un ordre d'arrivée

Si tout ceci ne vous pose pas de problème, alors oui, c'est une bonne solution

[djamel_c]

bonsoir Mr escartefigue

d'accord, merci beaucoup ,je veux que les clés primaires soient interne au sgbd et l'accés aux tables par l'utilsateur se fera au moyen des clés unique ,ça ne pose pas de problèmes normalement

[escartefigue]

En effet , aucun souci en ce cas, vous aurez votre identifiant technique d'une part, et votre identifiant fonctionnel d'autre part, tous les deux uniques, mais seul l'id technique sera l'id primaire

[fsmrel]

Bonsoir à vous deux,

Je me permets de répondre bien que le message soit adressé nominativement

Vous fîtes bien, car au moment où Djamel a posté, j’étais encore sous les effets d’une anesthésie (locale)...

concernant les identifiants (clés primaires) est-ce que je peux les déclarer auto-increment ?

Selon la documentation « Ingres 10.2, ING-102-SQL-11, SQL Reference Guide », page 430, il faut utiliser la clause « GENERATED ALWAYS AS IDENTITY ».

Voyez un exemple ici.