Discussion :

[win_ubuntu]

soit le diagramme de classe:

j'aimerais modéliser la contrainte suivante:
à une date donnée, un membre participe à une seule soutenance.

[win_ubuntu]

salut,
j'ai modélisé la contrainte en utilisant une association qualifié. voici le diagramme après modification:

la question qui se pose est la suivante:
comment transformer ce diagramme en un modèle relationnel.

[fsmrel]

Bonjour win_ubuntu,


Si on se situe au niveau relationnel (ou SQL), la situation doit être la suivante : une table, appelons-la PARTICIPATION, permet de brancher les tables MEMBRE et SOUTENANCE, tout en respectant la contrainte selon laquelle à une date donnée, un membre donné ne peut se trouver qu’à un seul endroit : c’est cette contrainte qui fait l'objet de la clé primaire de la table PARTICIPATION.
Code SQL :

CREATE TABLE MEMBRE 
(
        MembreId              INT            NOT NULL
      , MembreNom             VARCHAR(32)    NOT NULL
    , CONSTRAINT MEMBRE_PK PRIMARY KEY (MembreId)
) ;

CREATE TABLE SOUTENANCE 
(
        SoutenanceId          INT            NOT NULL
      , SoutenanceDate        DATE           NOT NULL
      , SoutenanceLieu        VARCHAR(32)    NOT NULL
    , CONSTRAINT MEMBRE_PK PRIMARY KEY (SoutenanceId)
    , CONSTRAINT MEMBRE_AK UNIQUE (SoutenanceDate, SoutenanceLieu)
) ;

CREATE TABLE PARTICIPATION 
(
        MembreId              INT            NOT NULL
      , SoutenanceDate        DATE           NOT NULL
      , SoutenanceLieu        VARCHAR(32)    NOT NULL
    , CONSTRAINT PARTICIPATION_PK PRIMARY KEY (MembreId, SoutenanceDate)
    , CONSTRAINT PARTICIPATION_MEMBRE_FK FOREIGN KEY (MembreId) 
          REFERENCES MEMBRE (MembreId)
    , CONSTRAINT PARTICIPATION_SOUTENANCE_FK FOREIGN KEY (SoutenanceDate, SoutenanceLieu) 
          REFERENCES SOUTENANCE (SoutenanceDate, SoutenanceLieu)
) ;

Diagramme relationnel correspondant :




Observez que la paire {SoutenanceDate, SoutenanceLieu} est la clé de référence de SOUTENANCE, le singleton {SoutenanceId} étant alors (malgré les apparences), ravalé au rang de clé de rechange (je dirais même que l’attribut SoutenanceId devient parasite...)

Le diagramme relationnel pertinent devient alors le suivant :



On fait le ménage en conséquence dans le code SQL :

CREATE TABLE MEMBRE 
(
        MembreId              INT            NOT NULL
      , MembreNom             VARCHAR(32)    NOT NULL
    , CONSTRAINT MEMBRE_PK PRIMARY KEY (MembreId)
) ;

CREATE TABLE SOUTENANCE 
(
        SoutenanceDate        DATE           NOT null
      , SoutenanceLieu        VARCHAR(32)    NOT NULL
    , CONSTRAINT SOUTENANCE_PK PRIMARY KEY (SoutenanceDate, SoutenanceLieu)
) ;

CREATE TABLE PARTICIPATION 
(
        MembreId              INT            NOT NULL
      , SoutenanceDate        DATE           NOT null
      , SoutenanceLieu        VARCHAR(32)    NOT NULL
    , CONSTRAINT PARTICIPATION_PK PRIMARY KEY (MembreId, SoutenanceDate)
    , CONSTRAINT PARTICIPATION_MEMBRE_FK FOREIGN KEY (MembreId) REFERENCES MEMBRE (MembreId)
    , CONSTRAINT PARTICIPATION_SOUTENANCE_FK FOREIGN KEY (SoutenanceDate, SoutenanceLieu) REFERENCES SOUTENANCE (SoutenanceDate, SoutenanceLieu)
) ;

[win_ubuntu]

merci infiniment fsmrel. bonne soirée