Discussion :

[pashaone]

Bonjour,

Actuellement élève en L2 informatique, je travaille actuellement sur un projet de création d'un site dynamique utilisant PHP/MySQL/CSS/HTML avec utilisation d'une base de donnée :

Soit les spécifications suivantes

Le site Web a pour objectif principal la gestion de parties de jeux de société. En particulier, le site doit permettre de saisir une nouvelle partie, de générer des parties aléatoires, de visualiser des salles de jeux ou joueuses sur une carte et de suggérer des recommandations de jeux.
Décrivons tout d’abord les joueuses. Celles-ci possèdent un pseudo, un nom, un prénom et une date de naissance. Le pseudo est unique et ne peut plus être modifié une fois choisi. Chaque joueuse possède également une adresse postale, qui inclut la rue, le code postal, la ville, la région. Éventuellement, une adresse postale peut être rattachée à un lieu, qui se définit comme une entité géographique avec un nom et des coordonnées géographiques (latitude et longitude, e.g., 45.762391 et 4.822415 pour la Basilique de Fourvière). Une équipe, qui possède un nom, une date de création et une devise, permet de regrouper au moins deux joueuses pour des jeux en équipe. Il n’y a pas de restriction sur le nombre d’équipes qu’une joueuse peut rejoindre, et on enregistre sa dernière date d’arrivée dans l’équipe.
Une notion cruciale dans ce projet est celle de jeu au sens large, bien que l’application doit permettre de gérer obligatoirement les jeux de société (et éventuellement des jeux vidéos, des évènements sportifs). Chaque jeu a un nom, une date de sortie et il est créé par des auteurs. Par contre, c’est un éditeur, et un seul, qui se charge de concevoir le jeu. Les jeux sont souvent réservés à un public (selon l’âge, e.g., "à partir de 10 ans"). Le jeu est également prévu pour un nombre de joueurs donné (e.g., "de 2 à 6 joueurs") et fait partie d’une ou plusieurs catégories (e.g., "jeu de plateau", "jeu de rôle", "jeu de dés"). Dans l’application, il sera nécessaire de filtrer les jeux, par exemple "liste des jeux de cartes à partir de 7 ans et pour 3 joueurs". Enfin, un jeu peut proposer des extensions (e.g., le jeu "les aventuriers du rail" se déroule initialement aux États-Unis, mais possède une extension pour la Scandinavie, Bretagne, etc.). Chaque nouvelle extension s’identifie par un numéro équivalent à son ordre d’apparition parmi les extensions de ce jeu. Comme pour un jeu, une extension comporte un nom et une date de sortie.
L’un des buts de cette application est de stocker des parties, c’est à dire les résultats d’une joueuse ou équipe à un jeu donné. Une partie possède donc un score, une durée et une valeur indiquant si la joueuse/équipe a gagné. À noter que l’on connait aussi la durée moyenne d’une partie d’un jeu. Une partie se déroule à une date précise et dans un lieu donné, ce qui permettra de rechercher des joueuses par zone géographique. Une même joueuse/équipe peut évidemment jouer au même jeu plusieurs fois par jour. Enfin, des statistiques seront produites sur les parties et les joueuses.


A l'heure actuelle j'ai fait mon modèle conceptuel sur Jmerise, importer le fichier SQL dans phpadmin et réalisé une maquette de mon site :
http://ludotex.arquusia.fr/

Certains formulaires sont encore génériques et je suis loin d'avoir fini. Néanmoins j'ai pu tester quelques formulaires simples comme celui d'une recherche dans la base. http://ludotex.arquusia.fr/index.php?page=affichage.php

Mon schéma entité/association est le suivant :



Mes questions sont les suivantes :

Que pensez vous de cette modélisation générale ?
Je pense qu'il y a une entité faible forcément dans ce projet car c'est une notion qui a été arborée en cours mais je n'arrive pas à l'identifier ?
Quelles modifications pouvez vous me suggérer ?

Enfin, ayant extrait des informations bruts d'un site et utilisé un programme en C générant automatiquement un fichier .sql pour peupler ma base (par exemple pour les "jeux de société"), il me manque les attributs "catégorie" dans cette table. Comment puis-je implementer un formulaire pour remplir appartient_cat manuellement avec N-menu déroulants (un jeu peu avoir plusieurs catégories).

J'espère que ma demande d'aide n'est pas trop exagérée, ni trop exhaustive !

Cordialement
Alexandre

[fsmrel]

Bonsoir Alexandre,

Que pensez vous de cette modélisation générale ?

C’est un début correct, mais à revoir du côté des parties.


Evitez le pluriel pour le nom d’une type d’entité, exemple JEU : un type d’entité (ou entité-type) est un modèle d’entité et à considérer comme un prédicat :

Le jeu id_jeu a pour nom nom, il a été publié à la date date_publication, y participent au moins nb_joueurs_min, au plus nb_joueurs_max, etc.

Agrandissez vos schémas, il y a des noms d’attributs illisibles.



Entité-type JEU :

A quoi correspond l’attribut nombre_extensions ? Est-ce une donnée primitive ? Si, au contraire, il s’agit du dénombrement des entités (occurrences) de l’entité-type EXTENSION, alors c’est un résultat de calcul, auquel cas cet attribut devrait être supprimé.

L’attribut nb_joueur est du type VARCHAR : ceci sous-entend que le nombre de joueurs n’a pas de rôle particulier, il serait purement informatif. Peut-être pourriez-vous définir deux attributs nb_joueurs_min et nb_joueurs_max (de type numérique cette fois-ci), permettant de s’assurer que le nombre de joueuses d’une partie reste cohérent par rapport aux bornes définies par ces deux attributs.

L’attribut duree_moyenne est du type virgule flottant : préférez le type virgule fixe (DECIMAL). En outre, si cette durée est calculable, elle n’a pas lieu de faire l’objet d’un attribut de l’entité-type.

Par ailleurs, ça n’est pas une obligation, mais vous pourriez spécialiser cette entité-type en JEU_SOLO et JEU_EN_EQUIPE (le nombre de joueurs d’une partie en solo n’apporte rien...),

Entité-type PARTIE :

Une partie se déroule à un moment précis dans le temps : ça n’est pas dans les associations que vous avez définies qu’il faut faire figurer la date (et l’heure, l’attribut pourrait alors être du type TIMESTAMP).

Entité-type EXTENSION :

Vous avez associé un éditeur à chaque extension : vous considérez donc que l’éditeur de l’extension peut être différent de l’éditeur du jeu. C’est bien cela ? (Même question quant aux auteurs).

Association ADHERE :

La patte d’association connectant EQUIPE et ADHERE est porteuse d’une cardinalité 1,N au lieu d’une cardinalité 2,N, mais c’est à cause de l’outil qui ne le permet pas. De toute façon, ça sera à vous de contrôler cette minimalité, car si MySQL devrait permettre de le faire, ça n’est malheureusement pas le cas.

Association PARTICIPATION :

L’association PARTICIPATION (cf. votre 2e MCD) pose un 1er problème : elle correspond à un prédicat qui se lit ainsi :

La joueuse joueuse de l’équipe équipe a participé à la partie partie, à la date date_participation.

Autrement dit, pour participer à une partie une joueuse fait obligatoirement partie d’une équipe participant elle aussi à la partie, contrainte qui n’est pas précisée dans l’énoncé, en plus, même si c’est pour une partie de type solo, votre représentation fait nécessairement intervenir une équipe de la joueuse.

2e problème : il faudra modéliser une contrainte d’inclusion entre les associations ADHERE et PARTICIPATION, sinon rien n’empêche de faire participer à un jeu par équipes une joueuse non adhérente à une des équipes participantes.

=> Repartir sur les bases de la modélisation initiale.

Exemple (avec l’AGL DB-MAIN) :

Plus haut, je parlais de la spécialisation de l’entité-type JEU. Maintenant, on peut parler de généralisation : généralisation des entités-types JOUEUSE et EQUIPE en une entité-type PARTICIPANT. Une joueuse est un participant, et une équipe est un participant. Un participant participe à des parties (et PARTIE n’est jamais que l’association d’un participant et d’un jeu). A noter que si un participant ne peut pas participer à plus d’un jeu au même moment, l’identifiant de l’association PARTIE est réduit à la paire {PARTICIPANT, timestamp_partie}, contrainte que j’ai fait figurer sans le diagramme ci-dessous. Par contre, s’il peut participer à plus d’un jeu au même moment, cette contrainte ne vaut plus. Qu’en est-il de cette contrainte ?






Association avec l’entité-type LIEU :




L’identifiant de PARTIE reste inchangé.

Je pense qu'il y a une entité faible forcément dans ce projet car c'est une notion qui a été arborée en cours mais je n'arrive pas à l'identifier.

Une entité faible n’a pas d’autonomie, elle ne vit que par l’entité qui la porte : une entité-type faible est une propriété multivaluée d’une entité-type plus forte. Ainsi, une extension n’a pas de sens en dehors du jeu auquel elle se rattache : l’entité-type EXTENSION est manifestement une entité-type faible relativement à l’entité-type JEU.

Comment puis-je implémenter un formulaire pour remplir appartient_cat manuellement.

Ceci n’est pas un problème de modélisation et ne ressortit donc pas au forum Schéma : je n’ai aucune idée quant à la façon de récupérer les valeurs de la table APPARTIENT_CAT...

[pashaone]

Bonjour,

Tout d'abord merci pour votre réponse exhaustive !

Je vous avoue que j'ai un peu de mal à comprendre le schéma de DB-MAIN étant habitué au formalisme Merise.
Cependant j'ai rectifié plusieurs choses sur Jmerise:

- explicité clairement en majuscule les entité-type/associations qui seront des relations
- enlevé les "s"
- considéré que EXTENSION est publié/crée par les mêmes AUTEUR/EDITEUR
- changé l'entité-type PARTIE

Je ne suis pas très motivé pour spécialiser l'entité JEU, ni pour changer nb_joueur. J'ai déjà peuplé ma base de jeux et ne souhaite pas trop modifier son contenu. Je souhaite garder nb_joueur : VARCHAR.

Je trouve la partie modélisation très décourageante et peu gratifiant car extrêmement chronophage. On revient sans cesse dessus alors que le projet est plus ambitieux qu'une simple modélisation. Il s'agit aussi de faire l'affichage du site, remplir des formulaires, générer des parties etc... Leurs implémentations demandent aussi beaucoup de travail et le tout repose sur la modélisation.

Bien que certaines implémentations qui marchent sont encourageantes : http://ludotex.arquusia.fr/index.php?page=affichage.php
ex : ajout de plusieurs catégories à un jeu existant (http://ludotex.arquusia.fr/index.php?page=ajoutcat.php)
Si on modifie le MCD à chaque fois c'est un retour en arrière et il faut recommencer tout à 0...

Merci pour votre aide.
Alexandre

[fsmrel]

Bonsoir Alexandre,

J'ai un peu de mal à comprendre le schéma de DB-MAIN étant habitué au formalisme Merise.

Le formalisme de DB-MAIN est celui de Merise avec — dans les diagrammes que j’ai présentés —une représentation des CIF plus légère et puissante (réduction de l’identifiant d’une association à un sous-ensemble d’attributs).


Votre association PARTICIPATION_EQUIPE est porteuse d’un attribut id_participant_equipe qui est manifestement une redondance. Même chose en ce qui concerne l’association PARTICIPATION_JOUEUSE.


Une question relative à votre représentation :




Supposons que la partie P1 fasse référence à un jeu par équipes. L’association PARTICIPATION_EQUIPE permet de savoir quelles sont les équipes participantes. La patte d’association connectant PARTIE et PARTICIPATION_JOUEUSE est porteuse d’une cardinalité 1,N, ce qui veut dire, a priori, que seules certaines joueuses de ces équipes ont participé à P1 et l’on veut savoir qui elles sont. Est-ce ainsi que vous voyez les choses ?

— Si oui, il faudrait mettre en œuvre une contrainte d’inclusion dans laquelle sont parties prenantes les associations ADHERE, PARTICIPATION_JOUEUSE et PARTICIPATION_EQUIPE, car à défaut, on pourrait faire participer des joueuses n’ayant rien à voir avec les équipes participantes.

— Sinon, la modélisation est à revoir : généralisation de JOUEUSE et EQUIPE comme je vous l’ai proposé, ou bien (moins satisfaisant quand même) éclatement de PARTIE en PARTIE_SOLO et PARTIE_EQUIPE comme ci-dessous :







A propos des extensions : le nom de l’association connectant les entités-types JEU et EXTENSION est mal choisi, il faut remplacer le verbe être par le verbe avoir, sinon vous signifiez qu’un jeu est une extension aux multiples avatars (au sens 1er du terme)...

[JPhi33]

Enfin, un jeu peut proposer des extensions (e.g., le jeu "les aventuriers du rail" se déroule initialement aux États-Unis, mais possède une extension pour la Scandinavie, Bretagne, etc.). Chaque nouvelle extension s’identifie par un numéro équivalent à son ordre d’apparition parmi les extensions de ce jeu. Comme pour un jeu, une extension comporte un nom et une date de sortie.
[...]
Je pense qu'il y a une entité faible forcément dans ce projet car c'est une notion qui a été arborée en cours mais je n'arrive pas à l'identifier ?

Chaque nouvelle extension s’identifie par un numéro équivalent à son ordre d’apparition parmi les extensions de ce jeu. Par exemple, pour le jeu J1, on a l'extension 1, la 2, la 3. Pour le jeu J2, on a l'extension 1. Par conséquent, l'identifiant d'une extension est l'ensemble constitué par {id_jeu, numéro_extension}. EXTENSION est donc une entité faible de l'entité forte JEU.

[pashaone]

Oui merci ! Je vais implementer ça à ma base. Ce n'est pas la partie la plus compliquée du projet.
Néanmoins l'entité-type partie avec participation solo et équipe reste encore obscure pour moi. Nous allons essayer d'implémenter et de comprendre vos propositions. Merci encore pour votre aide !

[fsmrel]

Bonsoir Alexandre,

L'entité-type partie avec participation solo et équipe reste encore obscure pour moi.

Je fournis ci-dessous le code SQL (à compléter) de création des tables : cela pourra sans doute vous éclairer.

J’avais posé la question suivante :

Supposons que la partie P1 fasse référence à un jeu par équipes. L’association PARTICIPATION_EQUIPE permet de savoir quelles sont les équipes participantes. La patte d’association connectant PARTIE et PARTICIPATION_JOUEUSE est porteuse d’une cardinalité 1,N, ce qui veut dire, a priori, que seules certaines joueuses de ces équipes ont participé à P1 et l’on veut savoir qui elles sont.

Est-ce ainsi que vous voyez les choses ?

J’ai supposé qu’il en était ainsi, auquel cas on doit respecter la contrainte voulant qu’une joueuse ayant participé à la partie P1 appartienne bien à l’équipe ayant participé à P1. La table PARTIE_EQUIPE_JOUEUSE sert à tout ça : c’est une table associant les tables ADHESION et PARTIE_EQUIPE. Au niveau conceptuel, c’est une association entre deux associations, avec inclusion, c'est-à-dire quelque chose de difficile à représenter : on se contentera de la représentation SQL, car là c’est simple.

USE temp ;

DROP TABLE IF EXISTS PARTIE_EQUIPE_JOUEUSE ;
DROP TABLE IF EXISTS PARTIE_SOLO ;
DROP TABLE IF EXISTS PARTIE_EQUIPE ;
DROP TABLE IF EXISTS ADHESION ;
DROP TABLE IF EXISTS JOUEUSE ;
DROP TABLE IF EXISTS EQUIPE ;
DROP TABLE IF EXISTS LIEU ;
DROP TABLE IF EXISTS JEU_SOLO ;
DROP TABLE IF EXISTS JEU_EQUIPE ;
DROP TABLE IF EXISTS EXTENSION ;
DROP TABLE IF EXISTS JEU ;
DROP TABLE IF EXISTS AUTEUR ;
DROP TABLE IF EXISTS EDITEUR ;
DROP TABLE IF EXISTS CATEGORIE ;


CREATE TABLE CATEGORIE 
(
        id_categorie                INT               NOT NULL
      , nom_categorie               VARCHAR(32)       NOT NULL
    , CONSTRAINT CATEGORIE_PK PRIMARY KEY (id_categorie)       
) ;

CREATE TABLE EDITEUR 
(
        id_editeur                  INT               NOT NULL
      , nom_editeur                 VARCHAR(32)       NOT NULL
    , CONSTRAINT EDITEUR_PK PRIMARY KEY (id_editeur)       
) ;

CREATE TABLE AUTEUR 
(
        id_auteur                   INT               NOT NULL
      , nom_auteur                  VARCHAR(32)       NOT NULL
    , CONSTRAINT AUTEUR_PK PRIMARY KEY (id_auteur)       
) ;

CREATE TABLE JEU 
(
        id_jeu                      INT               NOT NULL
      , nom_jeu                     VARCHAR(32)       NOT NULL
      , id_categorie                INT               NOT NULL
      , date_publication            DATE              NOT NULL
      , age_joueur                  INT               NOT NULL      
    , CONSTRAINT JEU_PK PRIMARY KEY (id_jeu)    
    , CONSTRAINT JEU_CATEGORIE_FK FOREIGN KEY (id_categorie)
          REFERENCES CATEGORIE  (id_categorie)    
) ;

CREATE TABLE EXTENSION 
(
        id_jeu                      INT               NOT NULL
      , id_extension                INT               NOT NULL        
      , nom_jeu                     VARCHAR(32)       NOT NULL
      , id_categorie                INT               NOT NULL
      , date_sortie                 DATE              NOT NULL
    , CONSTRAINT EXTENSION_PK PRIMARY KEY (id_extension)    
    , CONSTRAINT EXTENSION_JEU_FK FOREIGN KEY (id_jeu)
          REFERENCES JEU (id_jeu) ON DELETE CASCADE   
) ;

CREATE TABLE JEU_SOLO 
(
        id_jeu                      INT               NOT NULL
    , CONSTRAINT JEU_SOLO_PK PRIMARY KEY (id_jeu)    
    , CONSTRAINT JEU_SOLO_JEU_FK FOREIGN KEY (id_jeu)
          REFERENCES JEU (id_jeu)  ON DELETE CASCADE   
) ;


CREATE TABLE JEU_EQUIPE 
(
        id_jeu                      INT               NOT NULL
      , nb_joueurs_min              INT               NOT NULL  
      , nb_joueurs_max              INT               NOT NULL      
    , CONSTRAINT JEU_EQUIPE_PK PRIMARY KEY (id_jeu)    
    , CONSTRAINT JJEU_EQUIPE_JEU_FK FOREIGN KEY (id_jeu)
          REFERENCES JEU (id_jeu)  ON DELETE CASCADE   
) ;

CREATE TABLE LIEU
(
        id_lieu                     INT               NOT NULL
      , nom_lieu                    VARCHAR(32)       NOT NULL
      , latitude                    DECIMAL(9,6)      NOT NULL
      , longitude                   DECIMAL(9,6)      NOT NULL      
    , CONSTRAINT LIEU_PARTIE_PK PRIMARY KEY (id_lieu)    
) ;

CREATE TABLE EQUIPE
(
        id_equipe                   INT               NOT NULL
      , nom_equipe                  VARCHAR(32)       NOT NULL
      , date_creation_equipe        DATE              NOT NULL
      , devise                      VARCHAR(32)       NOT NULL      
    , CONSTRAINT EQUIPE_PK PRIMARY KEY (id_equipe)    
) ;

CREATE TABLE JOUEUSE
(
        id_joueuse                  INT               NOT NULL
      , pseudo                      VARCHAR(32)       NOT NULL        
      , nom_joueuse                 VARCHAR(32)       NOT NULL
      , prenom_joueuse              VARCHAR(32)       NOT NULL
      , date_naissance              DATE              NOT NULL
      , devise                      VARCHAR(32)       NOT NULL      
    , CONSTRAINT EQUIPE_PK PRIMARY KEY (id_joueuse)    
) ;

CREATE TABLE ADHESION
(
        id_equipe                   INT               NOT NULL
      , id_joueuse                  INT               NOT NULL
      , date_arrivee                DATE              NOT NULL
      , devise                      VARCHAR(32)       NOT NULL      
    , CONSTRAINT EQUIPE_PK PRIMARY KEY (id_equipe, id_joueuse)
    , CONSTRAINT ADHESION_EQUIPE_FK FOREIGN KEY (id_equipe)
          REFERENCES EQUIPE (id_equipe)    
    , CONSTRAINT ADHESION_JOUEUSE_FK FOREIGN KEY (id_joueuse)
          REFERENCES JOUEUSE (id_joueuse)  ON DELETE CASCADE   
) ;

CREATE TABLE PARTIE_SOLO
(
        id_joueuse                  INT               NOT NULL
      , id_jeu                      INT               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)
    , 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)    
) ;

CREATE TABLE PARTIE_EQUIPE
(
        id_equipe                   INT               NOT NULL
      , id_jeu                      INT               NOT NULL
      , id_lieu                     INT               NOT NULL
      , duree                       INT               NOT NULL
      , score                       INT               NOT NULL
      , statut                      BOOLEAN           NOT NULL
    , CONSTRAINT PARTIE_EQUIPE_PK PRIMARY KEY (id_equipe, id_jeu)
    , CONSTRAINT PARTIE_EQUIPE_JEU_FK FOREIGN KEY (id_jeu)
          REFERENCES JEU_EQUIPE (id_jeu)    
    , CONSTRAINT PARTIE_EQUIPE_EQUIPE_FK FOREIGN KEY (id_equipe)
          REFERENCES EQUIPE (id_equipe)    
) ;

CREATE TABLE PARTIE_EQUIPE_JOUEUSE
(
        id_equipe                   INT               NOT NULL
      , id_jeu                      INT               NOT NULL
      , id_joueuse                  INT               NOT NULL
    , CONSTRAINT PARTIE_EQUIPE_JOUEUSE_PK PRIMARY KEY (id_equipe, id_jeu)
    , CONSTRAINT PARTIE_EQUIPE_JOUEUSE_ADHESION_FK FOREIGN KEY (id_equipe, id_joueuse)
          REFERENCES ADHESION (id_equipe, id_joueuse)    
    , CONSTRAINT PARTIE_EQUIPE_EQUIPE_PARTIE_FK FOREIGN KEY (id_equipe, id_jeu)
          REFERENCES PARTIE_EQUIPE (id_equipe, id_jeu) ON DELETE CASCADE   
) ;

[pashaone]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208

#------------------------------------------------------------
#        Script MySQL.
#------------------------------------------------------------


#------------------------------------------------------------
# Table: Joueuse
#------------------------------------------------------------

CREATE TABLE Joueuse(
        ID_joueuse     int (11) Auto_increment  NOT NULL ,
        pseudo_joueuse Varchar (15) ,
        nom_joueuse    Varchar (50) ,
        prenom_joueuse Varchar (50) ,
        date_naissance Date ,
        ID_adresses    Int ,
        PRIMARY KEY (ID_joueuse ) ,
        UNIQUE (pseudo_joueuse )
)ENGINE=InnoDB;


#------------------------------------------------------------
# Table: Adresses
#------------------------------------------------------------

CREATE TABLE Adresses(
        ID_adresses int (11) Auto_increment  NOT NULL ,
        rue         Varchar (100) ,
        code_postal Int ,
        ville       Varchar (100) ,
        region      Varchar (100) ,
        ID_lieu     Int ,
        PRIMARY KEY (ID_adresses )
)ENGINE=InnoDB;


#------------------------------------------------------------
# Table: Equipe
#------------------------------------------------------------

CREATE TABLE Equipe(
        ID_Equipe     int (11) Auto_increment  NOT NULL ,
        nom_equipe    Varchar (20) ,
        date_creation Date ,
        devise        Text ,
        PRIMARY KEY (ID_Equipe ) ,
        UNIQUE (nom_equipe )
)ENGINE=InnoDB;


#------------------------------------------------------------
# Table: Jeux
#------------------------------------------------------------

CREATE TABLE Jeux(
        ID_jeux          int (11) Auto_increment  NOT NULL ,
        nom              Varchar (100) ,
        date_publication Year ,
        nb_joueur        Varchar (2) ,
        duree_moyenne    Double ,
        age_joueurs      Int ,
        ID_Editeur       Int ,
        PRIMARY KEY (ID_jeux )
)ENGINE=InnoDB;


#------------------------------------------------------------
# Table: Extension
#------------------------------------------------------------

CREATE TABLE Extension(
        ID_extension int (11) Auto_increment  NOT NULL ,
        ID_jeux      Int ,
        PRIMARY KEY (ID_extension )
)ENGINE=InnoDB;


#------------------------------------------------------------
# Table: Partie_solo
#------------------------------------------------------------

CREATE TABLE Partie_solo(
        ID_partie_solo int (11) Auto_increment  NOT NULL ,
        duree_partie   Datetime ,
        statut         Bool ,
        score          Float ,
        ID_joueuse     Int ,
        ID_lieu        Int ,
        ID_jeux        Int ,
        PRIMARY KEY (ID_partie_solo )
)ENGINE=InnoDB;


#------------------------------------------------------------
# Table: auteurs
#------------------------------------------------------------

CREATE TABLE auteurs(
        ID_auteur int (11) Auto_increment  NOT NULL ,
        nom       Varchar (50) NOT NULL ,
        PRIMARY KEY (ID_auteur )
)ENGINE=InnoDB;


#------------------------------------------------------------
# Table: Editeurs
#------------------------------------------------------------

CREATE TABLE Editeurs(
        ID_Editeur int (11) Auto_increment  NOT NULL ,
        nom        Varchar (50) NOT NULL ,
        PRIMARY KEY (ID_Editeur )
)ENGINE=InnoDB;


#------------------------------------------------------------
# Table: Lieu
#------------------------------------------------------------

CREATE TABLE Lieu(
        ID_lieu   int (11) Auto_increment  NOT NULL ,
        nom_lieu  Char (25) ,
        long_lieu Double ,
        lat_lieu  Double ,
        PRIMARY KEY (ID_lieu )
)ENGINE=InnoDB;


#------------------------------------------------------------
# Table: categorie
#------------------------------------------------------------

CREATE TABLE categorie(
        id_categorie  int (11) Auto_increment  NOT NULL ,
        nom_categorie Varchar (25) ,
        PRIMARY KEY (id_categorie )
)ENGINE=InnoDB;


#------------------------------------------------------------
# Table: Partie_equipe
#------------------------------------------------------------

CREATE TABLE Partie_equipe(
        ID_partie_equipe int (11) Auto_increment  NOT NULL ,
        duree_partie     Datetime ,
        statut           Bool ,
        score            Float ,
        ID_Equipe        Int ,
        ID_lieu          Int ,
        nb_joueur_min    Int ,
        nb_joueur_max    Int ,
        ID_jeux          Int ,
        PRIMARY KEY (ID_partie_equipe )
)ENGINE=InnoDB;


#------------------------------------------------------------
# Table: Adhère
#------------------------------------------------------------

CREATE TABLE Adhere(
        date_arrivee TimeStamp ,
        ID_joueuse   Int NOT NULL ,
        ID_Equipe    Int NOT NULL ,
        PRIMARY KEY (ID_joueuse ,ID_Equipe )
)ENGINE=InnoDB;


#------------------------------------------------------------
# Table: auteur_cree
#------------------------------------------------------------

CREATE TABLE auteur_cree(
        ID_auteur Int NOT NULL ,
        ID_jeux   Int NOT NULL ,
        PRIMARY KEY (ID_auteur ,ID_jeux )
)ENGINE=InnoDB;


#------------------------------------------------------------
# Table: appartient_cat
#------------------------------------------------------------

CREATE TABLE appartient_cat(
        ID_jeux      Int NOT NULL ,
        id_categorie Int NOT NULL ,
        PRIMARY KEY (ID_jeux ,id_categorie )
)ENGINE=InnoDB;

ALTER TABLE Joueuse ADD CONSTRAINT FK_Joueuse_ID_adresses FOREIGN KEY (ID_adresses) REFERENCES Adresses(ID_adresses);
ALTER TABLE Adresses ADD CONSTRAINT FK_Adresses_ID_lieu FOREIGN KEY (ID_lieu) REFERENCES Lieu(ID_lieu);
ALTER TABLE Jeux ADD CONSTRAINT FK_Jeux_ID_Editeur FOREIGN KEY (ID_Editeur) REFERENCES Editeurs(ID_Editeur);
ALTER TABLE Extension ADD CONSTRAINT FK_Extension_ID_jeux FOREIGN KEY (ID_jeux) REFERENCES Jeux(ID_jeux);
ALTER TABLE Partie_solo ADD CONSTRAINT FK_Partie_solo_ID_joueuse FOREIGN KEY (ID_joueuse) REFERENCES Joueuse(ID_joueuse);
ALTER TABLE Partie_solo ADD CONSTRAINT FK_Partie_solo_ID_lieu FOREIGN KEY (ID_lieu) REFERENCES Lieu(ID_lieu);
ALTER TABLE Partie_solo ADD CONSTRAINT FK_Partie_solo_ID_jeux FOREIGN KEY (ID_jeux) REFERENCES Jeux(ID_jeux);
ALTER TABLE Partie_equipe ADD CONSTRAINT FK_Partie_equipe_ID_Equipe FOREIGN KEY (ID_Equipe) REFERENCES Equipe(ID_Equipe);
ALTER TABLE Partie_equipe ADD CONSTRAINT FK_Partie_equipe_ID_lieu FOREIGN KEY (ID_lieu) REFERENCES Lieu(ID_lieu);
ALTER TABLE Partie_equipe ADD CONSTRAINT FK_Partie_equipe_ID_jeux FOREIGN KEY (ID_jeux) REFERENCES Jeux(ID_jeux);
ALTER TABLE Adhere ADD CONSTRAINT FK_Adhere_ID_joueuse FOREIGN KEY (ID_joueuse) REFERENCES Joueuse(ID_joueuse);
ALTER TABLE Adhere ADD CONSTRAINT FK_Adhere_ID_Equipe FOREIGN KEY (ID_Equipe) REFERENCES Equipe(ID_Equipe);
ALTER TABLE auteur_cree ADD CONSTRAINT FK_auteur_cree_ID_auteur FOREIGN KEY (ID_auteur) REFERENCES auteurs(ID_auteur);
ALTER TABLE auteur_cree ADD CONSTRAINT FK_auteur_cree_ID_jeux FOREIGN KEY (ID_jeux) REFERENCES Jeux(ID_jeux);
ALTER TABLE appartient_cat ADD CONSTRAINT FK_appartient_cat_ID_jeux FOREIGN KEY (ID_jeux) REFERENCES Jeux(ID_jeux);
ALTER TABLE appartient_cat ADD CONSTRAINT FK_appartient_cat_id_categorie FOREIGN KEY (id_categorie) REFERENCES categorie(id_categorie);

[pashaone]

bonsoir monsieur,


c'est idir le collègue:
1-Nous avons refait le modèle selon votre proposition sans considérer le cas de la table "partie_equipe_joueuse" dont on a pas besoin dans notre projet (sauf mauvaise compréhension de notre part). Question: qu'en dites vous ?

2-Nous ne comprenons pas pourquoi l'identifiant TimeStemp n’apparaît pas dans le code SQL que vous avez envoyez ?

[fsmrel]

Bonsoir,

Nous avons refait le modèle selon votre proposition sans considérer le cas de la table "partie_equipe_joueuse" dont on a pas besoin dans notre projet (sauf mauvaise compréhension de notre part). Question: qu'en dites vous ?

Si fonctionnellement vous n’avez pas besoin de savoir parmi les joueuses d’une équipe, quel est le sous-ensemble de celles qui ont effectivement participé à une partie, la table PARTIE_EQUIPE_JOUEUSE est inutile. Si un jour le besoin s’en faisait sentir, vous pourrez toujours « réanimer » cette table.

Nous ne comprenons pas pourquoi l'identifiant TimeStemp n’apparaît pas dans le code SQL que vous avez envoyé ?

Bonne remarque ! Il y a eu manifestement une erreur de copier/coller de ma part... La structure des tables PARTIE_SOLO et PARTIE_EQUIPE est en fait la suivante :

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)    
) ;

CREATE TABLE PARTIE_EQUIPE
(
        id_equipe                   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_EQUIPE_PK PRIMARY KEY (id_equipe, id_jeu, timestamp_partie)
    , CONSTRAINT PARTIE_EQUIPE_JEU_FK FOREIGN KEY (id_jeu)
          REFERENCES JEU_EQUIPE (id_jeu)    
    , CONSTRAINT PARTIE_EQUIPE_EQUIPE_FK FOREIGN KEY (id_equipe)
          REFERENCES EQUIPE (id_equipe)    
) ;

J’en ai profité pour mettre à jour la structure des entités-types correspondantes dans le message #4.


Concernant votre table Partie_equipe :

Attention, si les attributs nb_joueur_min et nb_joueur_max ne dépendent pas de l’équipe mais seulement du jeu, alors la table Partie_equipe que nous avez définie viole la troisième forme normale : à chaque fois qu’on insérera une ligne dans la table Partie_equipe et que cette ligne fera référence au jeu J, il faudra recopier dans la table, de façon redondante, les valeurs de nb_joueur_min et nb_joueur_max qui valent pour J :

CREATE TABLE Partie_equipe(
        ID_partie_equipe int (11) Auto_increment  NOT NULL ,
        duree_partie     Datetime ,
        statut           Bool ,
        score            Float ,
        ID_Equipe        Int ,
        ID_lieu          Int ,
        nb_joueur_min    Int ,
        nb_joueur_max    Int ,
        ID_jeux          Int ,
        PRIMARY KEY (ID_partie_equipe )
)ENGINE=InnoDB;

A supposer que l’on veuille connaître le nombre joueurs minimum pour un jeu donné, il faudra exécuter une requête SELECT portant sur la table Partie_equipe, requête pouvant ramener l’ensemble des lignes concernées. Si vous voulez changer la valeur de l’attribut nb_joueur_min, il faudra le faire pour l’ensemble des lignes concernées, etc.

Si donc les attributs nb_joueur_min et nb_joueur_max dépendent seulement du jeu, ils doivent migrer vers la table JEU. Le mieux reste encore de définir les sous-types JEU_SOLO et JEU_EQUIPE, d’autant que JMerise vous permet de mettre en œuvre la spécialisation :







N.B. Si tel ou tel message a pu vous aider, n’hésitez pas à voter...

[pashaone]

Bonsoir,

ici Alexandre à nouveau

A noter que si un participant ne peut pas participer à plus d’un jeu au même moment, l’identifiant de l’association PARTIE est réduit à la paire {PARTICIPANT, timestamp_partie}, contrainte que j’ai fait figurer sans le diagramme ci-dessous. Par contre, s’il peut participer à plus d’un jeu au même moment, cette contrainte ne vaut plus. Qu’en est-il de cette contrainte ?

Je pense que c'est bien une bonne idée d'identifier une partie par son timestamp car effectivement il semble difficile de participer à plusieurs jeux de société en même temps non ?

[fsmrel]

Bonsoir,

il semble difficile de participer à plusieurs jeux de société en même temps non ?

Difficile sans doute, mais pas impossible, si l'on considère le jeu d'échecs comme un jeu de société, car il y a des simultanées...

Cela dit, de mon côté, j'opterais prudemment pour interdire la participation à plusieurs jeux de société en même temps...

[pashaone]

Si fonctionnellement vous n’avez pas besoin de savoir parmi les joueuses d’une équipe, quel est le sous-ensemble de celles qui ont effectivement participé à une partie, la table PARTIE_EQUIPE_JOUEUSE est inutile. Si un jour le besoin s’en faisait sentir, vous pourrez toujours « réanimer » cette table.

Vous considérez donc qu'il est possible qu'une équipe ne contienne pas tous ses membres (joueuses) pour une partie ? Ne serait il pas plus logique de former uniquement des équipes "completes" pour chaque partie ?

Tout le reste du projet me semble clair sauf cette histoire de partie joueuse ou équipe. Je trouve le sujet très vague (volontairement ? une approche pédagogique qui serait contestable...). La notion de générateur de partie rend le tout encore plus obscure... CF les pdf ci-dessous.

http://liris.cnrs.fr/~fduchate/ens/L...et/projet1.pdf
http://liris.cnrs.fr/~fduchate/ens/L...et/projet2.pdf
http://liris.cnrs.fr/~fduchate/ens/L...et/projet3.pdf
http://liris.cnrs.fr/~fduchate/ens/L...et/projet4.pdf

Je pense avoir suffisamment épuisé de votre temps ;-) merci en tout cas pour votre aide. J'ai up-voté vos contributions.
Je vais utiliser votre dernière proposition pour les parties_solo/equipe. C'est bien la dernière fois qu'on change la base, c'est assez contraignant à repeupler car on a pas mal de requêtes SQL de filtrages des données à refaire à chaque fois.

Cordialement

[pashaone]

Cela dit, de mon côté, j'opterais prudemment pour interdire la participation à plusieurs jeux de société en même temps...

Qu'entendez vous par "prudemment" ?

[fsmrel]

Bonsoir,

Qu'entendez vous par "prudemment" ?

En l’absence de règle explicite, il est préférable d’être plutôt restrictif que laxiste, quitte à ouvrir les vannes quand le besoin s’en fait sentir, donc prévoir la solution laxiste sans la mettre en œuvre d’office. C’est du moins ainsi qu’on procède dans le monde des systèmes d’information des entreprises quand la maîtrise d'ouvrage et la maîtrise d'oeuvre n’ont pas de réponse a priori à un problème soulevé par l’informaticien, l’équipe chargée du projet : en tout cas, dans l’intérêt des projets, j’ai procédé ainsi pendant trente ans, et ça s’est toujours bien passé. Dans le cadre de votre propre projet, vous n’avez pas manifestement pas d’interlocuteur que vous puissiez interroger, si donc vous choisissez une solution, n’oubliez pas de préciser que vous conservez l’alternative au chaud et qu’il n’y aura pas de difficulté à procéder au changement.

Vous considérez donc qu'il est possible qu'une équipe ne contienne pas tous ses membres (joueuses) pour une partie ? Ne serait il pas plus logique de former uniquement des équipes "complètes" pour chaque partie ?

Je ne suis ni maîtrise d'ouvrage ni maîtrise d'oeuvre, et ne peux donc pas décider du choix qui se présente. Il y a là une règle de gestion qui devrait être écrite. Si des participants sont absents (malades, etc.) quand se déroule telle partie, on peut légitimement se poser la question de leur participation...

Je cite votre source :

Question 3 : Dans les spécifications, il n’est pas demandé de modéliser la notion "d’adversaire". Autrement dit, on sait qu’une joueuse ou une équipe a gagné ou perdu une partie, mais on ignore contre qui. Est-ce tout de même possible de connaître les participantes d’une partie ? Que faudrait-il modifier dans votre schéma E/A pour modéliser correctement cette notion d’adversaire ?

Dans cette question, Je relève ceci : « connaître les participantes d’une partie ».

Malgré le mauvais traitement infligé à la langue française par le rédacteur, (« Est-ce tout de même possible »), il est sous-entendu qu’on pourrait être amené à mettre en œuvre la table PARTIE_EQUIPE_JOUEUSE.

Mais comme je l’ai écrit :

Au niveau conceptuel, c’est une association entre deux associations, avec inclusion, c'est-à-dire quelque chose de difficile à représenter.

Et je subodore que l’auteur de l’exercice a eu des scrupules à incorporer cette partie dans l’énoncé initial. En effet, non plus d’un point de vue fonctionnel, mais technique, autant la solution est simple au niveau relationnel (table PARTIE_EQUIPE_JOUEUSE ajoutée ou supprimée « façon lego »), autant les choses se compliquent au niveau conceptuel, du fait de l’impossibilité (voulue par les pères du modèle Entité-Relation il a 40 ans, mais dommageable) d’interconnecter des associations. Dans votre rapport, vous pourriez faire état de cette difficulté technico-conceptuelle.


Autre point : Il est dommage que MySQL ne permette pas de résoudre de façon automatique la contrainte "une équipe regroupe au moins deux joueuses" (cf. Question 7 de votre PDF), alors qu’en théorie relationnelle, c’est extrêmement simple (la norme SQL a aussi une approche de la solution, mais lourde et pas pleinement satisfaisante). Si vous le souhaitez, je pourrai vous en parler de façon détaillée.

[pashaone]

J'ai essayé de modifier mon fichier SQL existant et d'y incorporer vos propositions. C'est un cauchemar, je n'y comprends plus rien...

Il y'a des ID qui devraient (à preuve du contraire) figurer dans JEU et qui ne sont pas dans votre code SQL de creation de table...
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 ?

Au sujet d'EXTENSION j'ai décidé de procéder ainsi :
- les extensions sont stockés dans JEU
- elles ont donc les mêmes caractéristiques qu'un JEU
=> on sélectionne les jeux dans JEU qui contiennent la chaine de caractères du jeu principal dans chaine du nom d'un autre jeu du même éditeur : ça retourne toutes les extensions de notre base, il y a une dizaine de t-uples qui respectent ces contraintes. Carcassonne par exemple à 3 extensions, Chicago express etc... (ça suppose que l'extension soit publié par le même éditeur, c'est pas très grave c'est juste pour peupler EXTENSION)
- du coup dans EXTENSION on l'id_jeu et l'id_extension (en réalité un id_jeu aussi)

je vous donne mon code SQL en entier si vous avez courage d'y jeter un coup d'oeuil...

https://www.dropbox.com/s/epybxh9v5x...tex-4.sql?dl=0

Qu'est ce que vous me conseillez de faire ? Tout recommencez à 0 ?

[pashaone]

[pashaone]

[pashaone]

Voilà j'y ai passé la nuit... J'ai fait le ménage dans mon MCD : https://www.dropbox.com/s/10gqv15e24...essai_MCD?dl=0
(rajouter extension appropriée pour le lire sur Jmerise)

ça me donne ça comme fichier SQL : https://www.dropbox.com/s/uv2l20wyl6alk10/temp.sql?dl=0

Avec vos propositions. Ca à l'air de fonctionner ! J'ai ajouté des Equipes, des PARTIE_SOLO ET PARTIE_EQUIPE. L'id est le timestamp au moment de l'execution de la requête. Pas de problème de foreign-key visiblement. Les liens semblent fonctionner.

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...

[pashaone]

argh c'était pas le bon fichier .sql
voici le code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
#------------------------------------------------------------
#        Script MySQL.
#------------------------------------------------------------


#------------------------------------------------------------
# Table: JOUEUSE
#------------------------------------------------------------

CREATE TABLE JOUEUSE(
        id_joueuse     int (11) Auto_increment  NOT NULL ,
        pseudo         Varchar (15) ,
        nom_joueuse    Varchar (50) ,
        prenom_joueuse Varchar (50) ,
        date_naissance Date ,
        id_adresse     Int ,
        PRIMARY KEY (id_joueuse ) ,
        UNIQUE (pseudo )
)ENGINE=InnoDB;


#------------------------------------------------------------
# Table: ADRESSE
#------------------------------------------------------------

CREATE TABLE ADRESSE(
        id_adresse  int (11) Auto_increment  NOT NULL ,
        rue         Varchar (100) ,
        code_postal Int ,
        ville       Varchar (100) ,
        region      Varchar (100) ,
        id_lieu     Int ,
        PRIMARY KEY (id_adresse )
)ENGINE=InnoDB;


#------------------------------------------------------------
# Table: EQUIPE
#------------------------------------------------------------

CREATE TABLE EQUIPE(
        id_Equipe            int (11) Auto_increment  NOT NULL ,
        nom_equipe           Varchar (20) ,
        date_creation_equipe Date ,
        devise               Text ,
        PRIMARY KEY (id_Equipe ) ,
        UNIQUE (nom_equipe )
)ENGINE=InnoDB;


#------------------------------------------------------------
# Table: JEU
#------------------------------------------------------------

CREATE TABLE JEU(
        id_jeu           int (11) Auto_increment  NOT NULL ,
        nom_jeu          Varchar (100) ,
        date_publication Year ,
        nb_joueur        Varchar (2) ,
        age_joueur       Int ,
        id_editeur       Int ,
        PRIMARY KEY (id_jeu )
)ENGINE=InnoDB;


#------------------------------------------------------------
# Table: EXTENSION
#------------------------------------------------------------

CREATE TABLE EXTENSION(
        id_extension Int NOT NULL ,
        id_jeu       Int ,
        id_jeu_JEU   Int ,
        PRIMARY KEY (id_extension )
)ENGINE=InnoDB;


#------------------------------------------------------------
# Table: AUTEUR
#------------------------------------------------------------

CREATE TABLE AUTEUR(
        id_auteur  int (11) Auto_increment  NOT NULL ,
        nom_auteur Varchar (50) NOT NULL ,
        PRIMARY KEY (id_auteur )
)ENGINE=InnoDB;


#------------------------------------------------------------
# Table: EDITEUR
#------------------------------------------------------------

CREATE TABLE EDITEUR(
        id_editeur  int (11) Auto_increment  NOT NULL ,
        nom_editeur Varchar (50) NOT NULL ,
        PRIMARY KEY (id_editeur )
)ENGINE=InnoDB;


#------------------------------------------------------------
# Table: LIEU
#------------------------------------------------------------

CREATE TABLE LIEU(
        id_lieu   int (11) Auto_increment  NOT NULL ,
        nom_lieu  Char (25) ,
        long_lieu Double ,
        lat_lieu  Double ,
        PRIMARY KEY (id_lieu )
)ENGINE=InnoDB;


#------------------------------------------------------------
# Table: CATEGORIE
#------------------------------------------------------------

CREATE TABLE CATEGORIE(
        id_categorie  int (11) Auto_increment  NOT NULL ,
        nom_categorie Varchar (25) ,
        PRIMARY KEY (id_categorie )
)ENGINE=InnoDB;


#------------------------------------------------------------
# Table: PARTIE_SOLO
#------------------------------------------------------------

CREATE TABLE PARTIE_SOLO(
        timestamp_partie TimeStamp NOT NULL ,
        duree            Int NOT NULL ,
        score            Int NOT NULL ,
        status           Bool NOT NULL ,
        id_lieu          Int ,
        id_jeu           Int ,
        PRIMARY KEY (timestamp_partie )
)ENGINE=InnoDB;


#------------------------------------------------------------
# Table: PARTIE_EQUIPE
#------------------------------------------------------------

CREATE TABLE PARTIE_EQUIPE(
        timestamp_partie TimeStamp NOT NULL ,
        duree            Int ,
        score            Int ,
        status           Bool ,
        id_lieu          Int ,
        id_jeu           Int ,
        PRIMARY KEY (timestamp_partie )
)ENGINE=InnoDB;


#------------------------------------------------------------
# Table: ADHESION
#------------------------------------------------------------

CREATE TABLE ADHESION(
        date_arrivee Date ,
        devise       Varchar (25) ,
        id_joueuse   Int NOT NULL ,
        id_Equipe    Int NOT NULL ,
        PRIMARY KEY (id_joueuse ,id_Equipe )
)ENGINE=InnoDB;


#------------------------------------------------------------
# Table: font_solo
#------------------------------------------------------------

CREATE TABLE font_solo(
        id_joueuse       Int NOT NULL ,
        timestamp_partie TimeStamp NOT NULL ,
        PRIMARY KEY (id_joueuse ,timestamp_partie )
)ENGINE=InnoDB;


#------------------------------------------------------------
# Table: AUTEUR_CREE
#------------------------------------------------------------

CREATE TABLE AUTEUR_CREE(
        id_auteur Int NOT NULL ,
        id_jeu    Int NOT NULL ,
        PRIMARY KEY (id_auteur ,id_jeu )
)ENGINE=InnoDB;


#------------------------------------------------------------
# Table: APPARTIENT_CAT
#------------------------------------------------------------

CREATE TABLE APPARTIENT_CAT(
        id_jeu       Int NOT NULL ,
        id_categorie Int NOT NULL ,
        PRIMARY KEY (id_jeu ,id_categorie )
)ENGINE=InnoDB;


#------------------------------------------------------------
# Table: font_equipe
#------------------------------------------------------------

CREATE TABLE font_equipe(
        id_Equipe        Int NOT NULL ,
        timestamp_partie TimeStamp NOT NULL ,
        PRIMARY KEY (id_Equipe ,timestamp_partie )
)ENGINE=InnoDB;

ALTER TABLE JOUEUSE ADD CONSTRAINT FK_JOUEUSE_id_adresse FOREIGN KEY (id_adresse) REFERENCES ADRESSE(id_adresse);
ALTER TABLE ADRESSE ADD CONSTRAINT FK_ADRESSE_id_lieu FOREIGN KEY (id_lieu) REFERENCES LIEU(id_lieu);
ALTER TABLE JEU ADD CONSTRAINT FK_JEU_id_editeur FOREIGN KEY (id_editeur) REFERENCES EDITEUR(id_editeur);
ALTER TABLE EXTENSION ADD CONSTRAINT FK_EXTENSION_id_jeu_JEU FOREIGN KEY (id_jeu_JEU) REFERENCES JEU(id_jeu);
ALTER TABLE PARTIE_SOLO ADD CONSTRAINT FK_PARTIE_SOLO_id_lieu FOREIGN KEY (id_lieu) REFERENCES LIEU(id_lieu);
ALTER TABLE PARTIE_SOLO ADD CONSTRAINT FK_PARTIE_SOLO_id_jeu FOREIGN KEY (id_jeu) REFERENCES JEU(id_jeu);
ALTER TABLE PARTIE_EQUIPE ADD CONSTRAINT FK_PARTIE_EQUIPE_id_lieu FOREIGN KEY (id_lieu) REFERENCES LIEU(id_lieu);
ALTER TABLE PARTIE_EQUIPE ADD CONSTRAINT FK_PARTIE_EQUIPE_id_jeu FOREIGN KEY (id_jeu) REFERENCES JEU(id_jeu);
ALTER TABLE ADHESION ADD CONSTRAINT FK_ADHESION_id_joueuse FOREIGN KEY (id_joueuse) REFERENCES JOUEUSE(id_joueuse);
ALTER TABLE ADHESION ADD CONSTRAINT FK_ADHESION_id_Equipe FOREIGN KEY (id_Equipe) REFERENCES EQUIPE(id_Equipe);
ALTER TABLE font_solo ADD CONSTRAINT FK_font_solo_id_joueuse FOREIGN KEY (id_joueuse) REFERENCES JOUEUSE(id_joueuse);
ALTER TABLE font_solo ADD CONSTRAINT FK_font_solo_timestamp_partie FOREIGN KEY (timestamp_partie) REFERENCES PARTIE_SOLO(timestamp_partie);
ALTER TABLE AUTEUR_CREE ADD CONSTRAINT FK_AUTEUR_CREE_id_auteur FOREIGN KEY (id_auteur) REFERENCES AUTEUR(id_auteur);
ALTER TABLE AUTEUR_CREE ADD CONSTRAINT FK_AUTEUR_CREE_id_jeu FOREIGN KEY (id_jeu) REFERENCES JEU(id_jeu);
ALTER TABLE APPARTIENT_CAT ADD CONSTRAINT FK_APPARTIENT_CAT_id_jeu FOREIGN KEY (id_jeu) REFERENCES JEU(id_jeu);
ALTER TABLE APPARTIENT_CAT ADD CONSTRAINT FK_APPARTIENT_CAT_id_categorie FOREIGN KEY (id_categorie) REFERENCES CATEGORIE(id_categorie);
ALTER TABLE font_equipe ADD CONSTRAINT FK_font_equipe_id_Equipe FOREIGN KEY (id_Equipe) REFERENCES EQUIPE(id_Equipe);
ALTER TABLE font_equipe ADD CONSTRAINT FK_font_equipe_timestamp_partie FOREIGN KEY (timestamp_partie) REFERENCES PARTIE_EQUIPE(timestamp_partie);