Discussion :

[pashaone]

Voila un aperçu de ce que j'ai fait ... en fait le fichier .sql était le bon. Faut vraiment que j'aille dormir !

[pashaone]

Voila toute la base est remplie avec succès...
quelques modifs dans EXTENSION et PARTIE_SOLO/EQUIPE (notamment ajout d'un ID en plus du timestamp)

https://www.dropbox.com/s/9ia8ap8q14...tex-3.sql?dl=0

Dites moi ce que vous en pensez

[fsmrel]

Bonsoir,

Il n'y a pas id_editeur ? Comment faire le lien avec EDITEUR ? Il y a un id_categorie mais vu qu'on peut avoir plusieurs catégories pour un jeu cet id devrait figurer dans une autre table ? JOUEUSE devrait avoir une id_adresse ? Comment faire le lien avec ADRESSE ?
Il peut y avoir plusieurs auteurs pour un seul jeu ? Il devrait y avoir une table intermédiaire AUTEUR_CREE ?

J’avais écrit :

Je fournis ci-dessous le code SQL (à compléter) de création des tables

Ce qui voulait dire que je me suis focalisé sur le cœur du modèle, plus délicat à aborder que le reste, j’ai laissé de côté la partie périphérique, laquelle ne présente pas de difficulté. Le temps passant, je n’ai pas revu cette partie script de création des tables, mais il est bien évident que la table JEU doit être dotée d’un attribut permettant de référencer l’éditeur. De même, il faut mettre en œuvre une table JEU_CATEGORIE puisqu’un jeu peut faire partie de plusieurs catégories, ainsi qu’une table JEU_AUTEUR (ou AUTEUR_CREE, peu importe le nom) puisqu’un jeu peut avoir été créé par plusieurs auteurs, etc.

Une chose me trouble cependant. JMerise m'a transformé les association font_equipe et font_solo en table. C'est obligatoire ? Ca semblait pas apparaitre dans votre modélisation...

C’est effectivement obligatoire, et JMerise a fait ce que vous lui avez demandé, car vous avez modélisé ceci (cas des partie en solo) :

[ JOUEUSE ]--0,N--------( font_solo )--------1,N-- [ PARTIE_SOLO ]--1,1--------( joue solo )--------0,N [ JEU]

Ce qui revient à dire que des joueuses ont réalisé des parties en solo, mais on ne sait pas quelle joueuse a effectué quelle partie.

Regardons maintenant le code SQL que j’avais proposé, où une joueuse peut participer en même temps à plusieurs jeux :

CREATE TABLE PARTIE_SOLO
(
        id_joueuse                  INT               NOT NULL
      , id_jeu                      INT               NOT NULL
      , timestamp_partie            TIMESTAMP         NOT NULL
      , id_lieu                     INT               NOT NULL
      , duree                       INT               NOT NULL
      , score                       INT               NOT NULL
      , statut                      BOOLEAN           NOT NULL
    , CONSTRAINT PARTIE_SOLO_PK PRIMARY KEY (id_joueuse, id_jeu, timestamp_partie)
    , CONSTRAINT PARTIE_SOLO_JEU_FK FOREIGN KEY (id_jeu)
          REFERENCES JEU_SOLO (id_jeu)    
    , CONSTRAINT PARTIE_SOLO_JOUEUSE_FK FOREIGN KEY (id_joueuse)
          REFERENCES JOUEUSE (id_joueuse)    
) ;

Dans ces conditions, au niveau du MCD, PARTIE_SOLO est une association ternaire entre JOUEUSE, JEU_SOLO et une entité-type ad-hoc TIMESTAMP.


Maintenant, si la règle est qu’une joueuse ne peut pas participer à deux jeux simultanément, alors l’attribut id_jeu ne doit plus participer à la clé primaire (j’ajoute en passant la clé étrangère référençant LIEU) :

CREATE TABLE PARTIE_SOLO
(
        id_joueuse                  INT               NOT NULL
      , id_jeu                      INT               NOT NULL
      , timestamp_partie            TIMESTAMP         NOT NULL
      , id_lieu                     INT               NOT NULL
      , duree                       INT               NOT NULL
      , score                       INT               NOT NULL
      , statut                      BOOLEAN           NOT NULL
    , CONSTRAINT PARTIE_SOLO_PK PRIMARY KEY (id_joueuse, timestamp_partie)
    , CONSTRAINT PARTIE_SOLO_JEU_FK FOREIGN KEY (id_jeu)
          REFERENCES JEU_SOLO (id_jeu)    
    , CONSTRAINT PARTIE_SOLO_JOUEUSE_FK FOREIGN KEY (id_joueuse)
          REFERENCES JOUEUSE (id_joueuse)    
    , CONSTRAINT PARTIE_SOLO_LIEU_FK FOREIGN KEY (id_lieu)
          REFERENCES LIEU (id_lieu)    
) ;

Dans ces conditions, au niveau du MCD, PARTIE_SOLO est une association quaternaire entre JOUEUSE, JEU_SOLO, LIEU et l’entité-type ad-hoc TIMESTAMP, mais il existe désormais deux contraintes, plus précisément deux contraintes d’intégrité fonctionnelle (CIF), signifiant que les attributs id_jeu et id_lieu ne participent pas à l’identifiant de l’association, donc à la clé de la table au niveau SQL.

Pour s’en sortir au niveau du MCD, le mieux est de transformer l’association PARTIE_SOLO en entité-type (ce que vous avez fait), et de l’identifier relativement à JOUEUSE (même principe bien sûr pour PARTIE_EQUIPE) :







Techniquement, pour mettre en œuvre l’identification relative avec JMerise (exemple avec l’entité-type EXTENSION), cliquer sur la patte d’association et cocher la case « Lien relatif » :




Attention, avec JMerise les attributs de la clé primaire ne sont pas dans le bon ordre, il faut permuter.


Je n’ai vérifié qu’une partie de votre script : du fait de l’identification relative, mettez à jour les clés primaires correspondantes. Remplacez les INT(11) par INT. Ajoutez la clause NOT NULL pour chaque attribut. Essayez de réduire les VARCHAR(100), car 100 octets ça occupe pas mal de place, non seulement sur disque, mais aussi en mémoire.