Discussion :

[pleug]

Bonjour à tous,
Je vous propose un petit test pour vos méninges, LoL.

Je travaille sur un MCD de jeu en ligne (juste pour le plaisir, donc j'ai pas la pression...)

Cela devrait me permettre de me perfectionner en Merise.

Voici le principe du jeu :

une fois inscrit un utilisateur peut :
1) créer une partie & l'administrer
2) créer une équipe dont il est le manager (maxi 1 équipe par ville)
3) s'inscrire dans d'autres équipes comme membre
4) écrire un article visible dans le forum d'une partie.

Un chef d'équipe peut :
1) inscrire son équipe à des parties ouvertes

Lorsqu'une partie est lancée, chaque team se voit attribué deux adversaires pour un combat virtuel en temps réel de manière à former une boucle comme ceci :

exemple de boucle de combat pour une partie de 8 teams:

... T1 <-c-> T4 <-c-> T7 <-c-> T2 <-c-> T3 <-c-> T8 <-c-> T5 <-c-> T6 <-c-> T1 ... ( remarquez qu'il s'agit de la première équipe de la boucle)

légende :
[Tx] corespond à la Team N° x
[<-c->] signifie qu'il y a Combat entre les teams située de chaque coté.

Chaque équipe est donc impliquée dans 2 combats en même temps et en temps réel de telle sorte que lorsqu'un combat prends fin le perdant sort de la boucle.

Exemple si T7 perds contre T2, la boucle devient :
... T1 <-c-> T4 <-c-> T2 <-c-> T3 <-c-> T8 <-c-> T5 <-c-> T6 ...

Puis si T3 perds contre T2 :
... T1 <-c-> T4 <-c-> T2 <-c-> T8 <-c-> T5 <-c-> T6 ...

et ainsi de suite jusqu’à ce qu'il n'y ait plus qu'une équipe dans la boucle qui sera de fait l'équipe gagnante.

voici mon ebauche de MCD :

(celui-ci n'affiche pas relation users_estManagerDe_teams, inutile de me le signaler)



Et voici mes questions :

-Comment gérer la boucle de combat en base de donnée ?
-Le reste de mon MCD est t'il cohérent ?

Merci pour vos pistes de réflexions, vos idées et vos solutions ...

Pascal (un Merise Newbee)

[Richard_35]

Bonjour Pleug,

Vite fait, cette partie me gêne (à moins que je n'ai rien compris) et je ne sais pas où est la faille...

Tout d'abord, quelle la clé primaire de team_has_parties ?

PS : sur la forme, laisses tes entités au singulier : nous nous doutons qu'elles comporteront plusieurs éléments.

[pleug]

Salut Richard,

Merci de te pencher sur mon problème.

Une équipe doit pouvoir s'inscrire à plusieurs parties, et une partie comporte plusieurs équipes... [teams_has_parties] est une table de liaison, elle ne comporte que des clés étrangères.

Pour les entités aux pluriel, c'est délibéré car j'utilise cakePHP pour lequel la convention de nommage des tables veut qu'elles soient écrites au pluriel.
(J'ai voulu éviter de renommer mes tables, suis un gros fainéant ...)

Merci encore pour tes remarques...

De mon coté je me disais que peut être, en rajoutant un champs adversaire à la table [teams_has_parties] ça pourrait le faire.

au début de la partie, j'initialise ce champs en attribuant à chaque équipe un adversaire constituant ainsi la boucle et pour chaque fin de combat, je passe a null ce champs pour le perdant, et je récupère l'adversaire du perdant que je ré-attribut au gagnant.... (ais-je été clair ?!)

qu'en pensez-vous ?

[Richard_35]

Bonjour Pleug,

Team_has_parties est une table de liaison, elle ne comporte que des clés étrangères.

==> j'entends bien, c'est le propre des tables associatives. Mais tu ne réponds pas à la question : quelle est la clé primaire de team_has_parties ?
==> je pense qu'un de te tes soucis se situe à ce niveau (à confirmer après ta réponse précise).

[pleug]

Je pensais que dans une table de liaison, toutes les clés étrangères sont des clés primaires parce que lors de la création de la liaison Mysql Workbench me définit la table comme cela. non ?

pour info, sur le diagramme, les clés primaires sont représentées par une ampoule jaune...

PS: j'ai mis à jour le diagramme en rajoutant une clé primaire [id] à la table [teams_has_parties]

[Richard_35]

Je pensais que dans une table de liaison, toutes les clés étrangères sont des clés primaires

==> pas forcément : l'association peut posséder des attribut propres (date d'affectation de cette team à cette partie, ...). Je pense que "tu as trop mis de clés étrangères" dans cette entité.

j'ai mis à jour le diagramme en rajoutant une clé primaire [id] à la table [teams_has_parties]

==> cela ne résout rien , car, maintenant il faut créer un index unique .

Je te suggère de supprimer id de teams_has_parties. A mon sens, cette table devrait être (souligné=clé primaire, #=clé étrangère) :

teams_has_parties(#IdTeams, #IdParties, [attributs de ce couple])

Ensuite, cette association (qui deviendrait une entité) comportera une partie "détail" :

teams_has_parties_detail(#IdTeams, #IdParties, #IdQuiRestentADéfinir, [attributs de ce détail])

[pleug]

Tous mes id sont en Auto Increment, mais ça se vois pas sur Mysql Worbench, suis en train d'installer la version d'essai de Power AMC. Vais essayer de faire quelque chose de plus propre.

Avec mes croquis ni faits, ni à faire, je te fais perdre du temps.

Je reviens avec de vrais croquis MCD. Merci pour ton aide.

[Luckyluke34]

D'accord avec Richard_35 sur l'entité team_has_parties. J'ai aussi du mal à voir pourquoi l'entité articles a toutes ces clés (primaires ? étrangères ? ...)

PS : tant qu'à tout faire en anglais, partie se dit game et pas party

[pleug]

Bien,

Me voici de retour avec de jolis schémas :

Le schema Merise :


et le schema MPD :


J'ai étoffé un peu mes liaisons (Dsl Luckyluke 34) j'ai modifié l'entité Party dans mon fichier original mais j'ai pas refait une copie d'écran.

C'est du coté de la table de liaison "combattre" que je ne sais pas si c'est vraiment optimisé pour ce que je cherche à faire. Au niveau des cardinalité c'est plutôt du [1,n] non ?

Encore merci de vous pencher sur mon souci (s'il y en a un)...

[CinePhil]

Lecture et critique du MCD...

1) Entité type "user"
1.a) Pourquoi avoir mis user_username et user_mail dans la clé primaire ?
Tu peux poser une contrainte d'unicité sur ces colonnes mais user_id est suffisant pour la clé primaire.
Cela allègera tes clés étrangères dans les autres tables.

1.b) Pourquoi avoir mis la propriété "article_created" ici. C'est inutile. On saura si l'utilisateur 12 a créé un article en interrogeant la table "article".

2) Autres clés primaires
Idem 1.a dans les entités types "role", "city", "country", "result".
L'identifiant est suffisant pour clé primaire. C'est même pour servir de clé primaire qu'on ajoute cet identifiant sans signification.

3) Association "habiter"
Un user peut habiter dans plusieurs villes ?

4) Association "administrer"
Une "party" (que tu devrais appeler game in english mais nomme aussi tes associations en anglais alors, ou partie en français) peut être administrée par plusieurs users ?

5) Association "combattre"
Une association entre plus de deux entités types avec des cardinalités à 1,1, c'est impossible !

Je ferais plutôt une entité type "combat" (fight in english).

Je te laisse réfléchir à tout ça. reviens nous voir avec un MCD corrigé.

Pour les entités aux pluriel, c'est délibéré car j'utilise cakePHP pour lequel la convention de nommage des tables veut qu'elles soient écrites au pluriel.

J'avais déjà lu des trucs pas tristes à propos de la gestion des données avec CakePHP ; ça continue ! Je ne suis pas près d'essayer ce framework !