Discussion :

[john82]

Bonjour à tous,
Je voudrais concevoir un MCD qui se base sur le jeu "Pokemon", pour pouvoir ensuite créer les autres schémas et enfin utiliser la BDD correspondante. Je tiens à préciser que pour le moment je ne compte pas mettre en place un système d'évolution, chaque pokemon sera considérer comme n'ayant pas d'évolution (sauf si certains sont motivés pour m'aider lol)
J'ai donc beaucoup réfléchi et voici le MCD :



Explication:
On a des FichesPokemons (c'est à dire le Pokédex), qui contient les informations de base d'un Pokemon (nom,stats de base...). Chaque FichesPokemons ont au moins un Types (jusqu’à 2) On a ensuite des Pokemons (c'est à dire les pokémons réels), un Pokemon a une et une seule FichesPokemons, et en plus un sexe, un niveau, l’expérience du niveau en cours . Un Pokémons appartient à un seul Dresseurs. Un Pokemons connait (peut utiliser) au moins une Attaques (et jusqu’à 4), et une Attaque est d'un seul Types.

Jusque là je ne pense pas avoir fait trop d'erreurs, mais c'est la suite que je trouve moins cohérente :
Une FichesPokemons peut apprendre au moins une Attaques (jusqu'à n) à un certain niveau.

Mon problème est que ce sont les Pokemons qui connaissent des Attaques, mais que ce sont les FichesPokemon qui peuvent en apprendre. J'ai fait ce choix car de base la table FichesPokemons sera pré-remplie ainsi que la table de jointure Apprendre, alors que les Pokemons seront créer au fur et a mesure.

Exemple :
Attaques
id_att | nom_att | ect....
---1----Griffe-------....
---2----Charge-----....
---3----Éclair-------....

FichesPokemon
id_fichepkmn | nom_fichepkmn | ect....
---1----------------Bulbizarre-------....
---2----------------Pikachu------....

Apprendre
id_fichepkmn | id_att | niveau_app
---1---------------1---------1
---1---------------2---------12
---2---------------1---------1
---2---------------2---------12
---2---------------3---------20

Mon choix de mettre apprendre en relation avec FichesPokemons me permet de ne pas avoir de redondances. En effet si j'avais relier apprendre a Pokemon, il pourrait y avoir 2 pikachu différents dans Pokemons et cela ferait que dans la table apprendre je devrais lister chaque attaque que chacun des deux pikachu peuvent apprendre :
Attaques
id_att | nom_att | ect....
---1----Griffe-------....
---2----Charge-----....
---3----Éclair-------....

FichesPokemon
id_fichepkmn | nom_fichepkmn | ect....
---1----------------Bulbizarre-------....
---2----------------Pikachu------....

Pokemons
id_pkmn | id_fichepkmn | ect....
---1-------------1------------.... (Pikachu 1)
---2-------------1------------.... (Pikachu 2)

Apprendre
id_pkmn | id_att | niveau_app
---1---------1---------1
---1---------2---------12
---1---------3---------20
---2---------1---------1
---2---------2---------12
---2----------3---------20
On voit les redondances que cela pourrait créer alors que les deux apprennent les mêmes Attaques

Comment pourrais-je représenter au mieux cette situation? Je suis débutant donc je ne connais pas toutes les subtilités, j'aimerais savoir si ce MCD tient la route, et surtout comment l'améliorer et le rendre plus cohérent?
Merci beaucoup d'avoir pris le temps de lire

[escartefigue]

Bonjour,

Voilà un sujet amusant et original

L'usage est d'utiliser des singuliers pour identifier les entité-type, par exemple "ATTAQUE" et non "ATTAQUES", en effet le type d'entité est bien "ATTAQUE" qui contiendra plusieurs occurrences (instances) d'attaques.
Essayez de trouver des verbes plus simples pour vos relations, par exemple "apprendre_attaque_fichepkm" pourrait peut être être renommé "apprendre", "connaitre" ou "maitriser"

Je connais pas du tout le jeu Pokemon, je ne me prononcerai donc pas sur l'aspect fonctionnel

Le principal problème que je vois sur votre modèle est qu'il présente des "cycles" c'est à dire des incohérences de cardinalités.
En effet, si on regarde la relation entre "POKEMON" et "FICHE_POKEMON" on constate qu'il y a une et une seul fiche pour un pokemon, jusque là pas de souci
Par contre, si on passe par "Connaitre", "ATTAQUE" et "Apprendre Attaque", alors un Pokemon peut etre en relation avec plusieurs fiches
Ces deux chemins sont incohérents entre eux
Vous avez le même souci avec ATTAQUE qui est de 1 et un seul type via la relation "être de" mais peut avoir plusieurs types si on passe par "apprendre attaque" puis "fiche pokemon" puis "avoir"

Mon problème est que ce sont les Pokemons qui connaissent des Attaques, mais que ce sont les FichesPokemon qui peuvent en apprendre. J'ai fait ce choix car de base la table FichesPokemons sera pré-remplie ainsi que la table de jointure Apprendre, alors que les Pokemons seront créer au fur et a mesure.

Ce problème pourra être résolu après avoir corrigé le cycle lié aux cardinalités incohérentes.
Ce qu'il faut savoir c'est : Est-ce que les attaques apprises par une "fiche pokemon" est connue ou non par tous les pokemon liés à cette fiche ?

[Kropernic]

Juste pour être sûr de bien comprendre (car les pokemons, ce n'est plus de mon âge ).

Les fiches pokemons sont des espèces de templates contenant les stats de bases des pokemons réels.
Les pokemons connaissent des attaques mais ils ne peuvent connaître que celles que la fiche pokemon qui leur est associée les autorise à apprendre et ce, à partir d'un certain niveau.

De prime abord, ça m'a l'air bien comme ça. Qu'est-qui te dérange dans ton modèle ?

Il manque juste une contrainte pour s'assurer que les attaques connues sont bien celles que le pokemon est autorisé à apprendre.
Et j'imagine qu'un pokemon ne peut apprendre non plus une attaque qui n'est pas d'un type possédé par sa fiche. Si oui, il faut également une contrainte.

[john82]

Bonjour, merci beaucoup de votre réponse

L'usage est d'utiliser des singuliers pour identifier les entité-type, par exemple "ATTAQUE" et non "ATTAQUES", en effet le type d'entité est bien "ATTAQUE" qui contiendra plusieurs occurrences (instances) d'attaques.
Essayez de trouver des verbes plus simples pour vos relations, par exemple "apprendre_attaque_fichepkm" pourrait peut être être renommé "apprendre", "connaitre" ou "maitriser"

D'accord, c'est ce que j'avais fait au départ mais j'avais lu après que c'était au pluriel, je vais corriger sa, et pour "apprendre_attaque_fichepkm" je vais utiliser "apprendre"

Le principal problème que je vois sur votre modèle est qu'il présente des "cycles" c'est à dire des incohérences de cardinalités.
En effet, si on regarde la relation entre "POKEMON" et "FICHE_POKEMON" on constate qu'il y a une et une seul fiche pour un pokemon, jusque là pas de souci
Par contre, si on passe par "Connaitre", "ATTAQUE" et "Apprendre Attaque", alors un Pokemon peut etre en relation avec plusieurs fiches
Ces deux chemins sont incohérents entre eux
Vous avez le même souci avec ATTAQUE qui est de 1 et un seul type via la relation "être de" mais peut avoir plusieurs types si on passe par "apprendre attaque" puis "fiche pokemon" puis "avoir"
Ce problème pourra être résolu après avoir corrigé le cycle lié aux cardinalités incohérentes.

Maintenant que vous le dites je le remarque, mais je n'arrive vraiment pas a casser le cycle, si vous avez des suggestions n'hesitez pas

Ce qu'il faut savoir c'est : Est-ce que les attaques apprises par une "fiche pokemon" est connue ou non par tous les pokemon liés à cette fiche ?

Eh bien oui, car de ce fait les différents Pikachu de Pokemon connaissent les attaques que peuvent apprendre leur fiche.
Imaginons je capture 2 Pikachu (ils seront dans Pokemon), ils sont différents (un mâle et une femelle) mais ont tous les deux en commun leur fiche, et donc ils ont le même movepool (liste des Attaques qu'ils peuvent apprendre, en gros c'est apprendre).

[john82]

Juste pour être sûr de bien comprendre (car les pokemons, ce n'est plus de mon âge ).

Ahah ce n'est plus censé être du miens non plus

Les fiches pokemons sont des espèces de templates contenant les stats de bases des pokemons réels.
Les pokemons connaissent des attaques mais ils ne peuvent connaître que celles que la fiche pokemon qui leur est associée les autorise à apprendre et ce, à partir d'un certain niveau.

Voila c'est exactement sa! Moi même j'avais du mal à l'expliquer mais c'est exactement ce à quoi je veux arriver comme résultat.

De prime abord, ça m'a l'air bien comme ça. Qu'est-qui te dérange dans ton modèle ?
Il manque juste une contrainte pour s'assurer que les attaques connues sont bien celles que le pokemon est autorisé à apprendre.

C'était en partie sa qui me dérangeait, il suffit d'ajouter une contrainte pour vérifier sa?
Il faut aussi vérifier que les attaques qu'il connait peuvent être connues à son niveau.
Par exemple, si mon Pokemon est Pikachu (Encore lui, mais c'est le plus connu ), imaginons qu'il puisse apprendre "Eclair" au niveau 12, il faudra vérifier que si il connait cette attaque, son niveau est bien >= 12 non?

Et j'imagine qu'un pokemon ne peut apprendre non plus une attaque qui n'est pas d'un type possédé par sa fiche. Si oui, il faut également une contrainte.

Sa non, une FichePokemon peut apprendre des attaques qui ne sont pas de son type. Pikachu (Type: Foudre) peut apprendre griffe (Type: Normal), la difference se fait au niveau des calculs des dégats: Un pokemon utilisant une attaque de son propre type rendra l'attaque plus puissante, et de sa puissance normale si l'attaque n'est pas de son type, cela n'intervient pas dans le MCD du coup

[escartefigue]

Maintenant que vous le dites je le remarque, mais je n'arrive vraiment pas a casser le cycle, si vous avez des suggestions n'hesitez pas

La seule chose à faire est de vérifier les règles de gestion (ou les faire vérifier si vous avez une maitrise d'ouvrage, mais vu le sujet j'en doute ) , d'abord unitairement, puis, comme je l'ai fait, en vérifiant que les différents chemins, par transitivité, sont cohérents entre eux.

Eh bien oui, car de ce fait les différents Pikachu de Pokemon connaissent les attaques que peuvent apprendre leur fiche.
Imaginons je capture 2 Pikachu (ils seront dans Pokemon), ils sont différents (un mâle et une femelle) mais ont tous les deux en commun leur fiche, et donc ils ont le même movepool (liste des Attaques qu'ils peuvent apprendre, en gros c'est apprendre).

Du coup, nul besoin de relation entre POKEMON et ATTAQUE, c'est via la relation avec sa fiche que le POKEMON connait un pannel d'attaques
Ce faisant, votre problème de cycle dans la partie basse du schéma tombe tout seul
Il restera tout de même le cycle du haut à corriger

[john82]

La seule chose à faire est de vérifier les règles de gestion (ou les faire vérifier si vous avez une maitrise d'ouvrage, mais vu le sujet j'en doute ) , d'abord unitairement, puis, comme je l'ai fait, en vérifiant que les différents chemins, par transitivité, sont cohérents entre eux.
Il restera tout de même le cycle du haut à corriger

D'accord je vais regarder sa et essayer de le corriger.

Du coup, nul besoin de relation entre POKEMON et ATTAQUE, c'est via la relation avec sa fiche que le POKEMON connait un pannel d'attaques
Ce faisant, votre problème de cycle dans la partie basse du schéma tombe tout seul

Ah oui d'accord, la relation entre POKEMON et ATTAQUE signifie qu'un POKEMON peut utiliser que 4 attaques au maximum, il peuvent en apprendre pleins, mais peuvent en connaitre entre 1 et 4 à la fois.
Le POKEMON devra donc "oublier" une de ses 4 attaques lorsqu'il en apprend une cinquième, pour la remplacer.
Je sais pas si c'est clair..

[JPhi33]

Bonjour à tous,

Le principal problème que je vois sur votre modèle est qu'il présente des "cycles" c'est à dire des incohérences de cardinalités.

Il n'y a pas de cycle dans le MCD de john82. Voir à ce propos ma réponse dans une discussion sur le MCD de Dv4pp.

En revanche, il faut ajouter une contrainte, comme l'indique Kropernic, stipulant que les attaques d'un pokémon font partie de celles de sa fiche. Pour préciser, il s'agit d'une contrainte d'inclusion de "connaitre" et "Contenir" dans "apprendre_attaque_fichepkmn".

[escartefigue]

Exact Jphi33, merci pour cette correction
Une fiche peut être liée à plusieurs attaques donc tout va bien : pas de cardinalité 1,1 "dans le sens retour" qui provoquerait une boucle infernale

[john82]

Bonjour et merci beaucoup pour vos réponses, si il n'y a pas de cycles je vais donc conserver le MCD comme cela, en ajoutant la contrainte d'inclusion pour être sur que les attaques connues sont correctes.
Depuis j'ai également pu corriger les erreurs sur les pluriels, connaitre est devenu moveset (c'est se qui désigne la liste d'attaques connues) je suis passé sous powerAMC, et j'ai également pu réfléchir sur les évolutions, pour moi ce serait une association réflexive sur FichePokemon:



Pour les évolutions j'ai considérer que soit une FichePokemon ne peut pas évoluer, soit elle peut évoluer en une seule FichePokemon (0,1) à un certain niveau (niveau_evo), avec le même raisonnement dans le sens inverse : une FichePokemon peut soit ne pas avoir d'évolution précédente, soit une seule (0,1) à un certain niveau (niveau_evo). Cela ne posera pas de problème par rapport aux Pokemon ? car l'id de leur FichePokemon va changer lors de l'évolution..
Que pensez-vous des modifications apportées au MCD? Et au niveau de l'évolution ?
Merci encore de vos réponses

[escartefigue]

Bonjour,

Excusez moi pour ces questions "basiques" mais encore une fois, je n'y connais rien dans ce jeu

- Quand une "fiche" évolue, est-ce que ce sont potentiellement tous les attributs de type entier qui peuvent être modifiés, ou seulement certains d'entre eux ?
- Qu'est -ce que c'est que la classe d'attaque ? ne faut il pas créer une entité type et une relation entre attaque et classe d'attaque ?

Et quelques remarques
- Il semble que le type de Desc_fichepkmn devrait être (n)char ou (n)varchar voir éventuellement texte
- Pour une longueur maximale de 512, vous pouvez privilégier le type varchar plutôt que le type text
- D'après votre MCD, seuls vos attributs identifiants sont obligatoires, c'est très suspect et c'est probablement un oubli

[JPhi33]

Bonjour à tous,

Pour les évolutions j'ai considérer que soit une FichePokemon ne peut pas évoluer, soit elle peut évoluer en une seule FichePokemon (0,1) à un certain niveau (niveau_evo), avec le même raisonnement dans le sens inverse : une FichePokemon peut soit ne pas avoir d'évolution précédente, soit une seule (0,1) à un certain niveau (niveau_evo).

Oui, c'est correct

Cela ne posera pas de problème par rapport aux Pokemon ? car l'id de leur FichePokemon va changer lors de l'évolution..

Prenons un exemple (les identifiants sont entre crochets <>).
Supposons deux fiches Pokémon, <7> Carapuce et <8> Carabaffe, laquelle est l'évolution de Carapuce (niveau 16), et le pokémon <1> lié à la fiche <7> par l'association Contenir (ce pokémon est donc un Carapuce).
Lorsque le pokémon <1> atteint le niveau 16, il évolue en Carabaffe. Cela se traduit par la modification de l'association "Contenir" qui passe de la valeur <7> à la valeur <8>.


Concrètement, dans la base de données, la table Pokemon aura cet aspect :

Pokemon(id_pkmn, niveau_pkmn, sexe_pkmn, expencours_pkmn, #id_fichepkmn)

La modification en question porte sur la valeur de la clé étrangère id_fichepkmn qui passe de 7 à 8. Le pokémon <1> devient alors un Carabaffe.