Discussion :

[noals]

Il faut que je fasse bien attention à la notion d'héritage alors.

Revoyez les explications détaillées dans mon message #3 pour savoir si l'héritage est utile et pertinent ou s'il faut seulement typer les items, s'ils ont tous les mêmes propriétés (futures colonnes de la table des items).

C'est à cause de ça que je m'y perd un peu, c'est pour ça que je voulais faire différentes catégories d'item.
ma catégorie weapon aura toujours comme paramètre une valeur d'attaque par exemple et aura peut-etre un effect
ma catégorie armor aura toujours une valeur de défense et aura peut-être un effect
ma catégorie usable n'aura ni attaque ni défense mais peut avoir un effect qui lui ajoutera une valeur d'attaque ou de défense
du coup, je me retrouve avec des paramètres qui forme un triangle dans plusieurs tables et je ne sais pas encore exactement comment bien les organiser parce qu'après je me retrouve aussi avec les skill des joueurs qui eux aussi ont des effect, je vais revoir ça avec l'héritage en tête.

C'est quoi un "key_item" ?

Un item plus rare pour certaines quêtes, j'avais ajouté comme paramètre "can_trade" ou "can_sell" dans item de mon brouillon, le key_item resterai dans l'inventaire jusqu'à ce que la quête soit accomplie par exemple, cette catégorie n'est pas forcément utile grâce à ces paramètres du coup.

2) Pas de multiples propriétés pour la même notions (color1 à color5 dans hero).
Écrivez la règle de gestion :
Un hero est colorié de 5 colors et une color peut colorier plusieurs heros.

J'avais dans l'idée que le joueur peut définir ses couleurs lui même donc une couleur serait une valeur RGB par exemple, donc je le considère plus comme un paramètre qu'une entité.

Merci.

[escartefigue]

Vous avez plein d'idées et hâte d'aboutir, c'est une bonne chose, mais c'est aussi un handicap car ça favorise la dispersion tellement vous voulez vous précipiter vers le développement en brulant les étapes.

Essayez de garder votre sang froid et surtout les idées claires, pour ça il faut lever un peu la tête du guidon et essayer de décrire avec des phrases simples les interactions entre les "individus" ou "objets" qui entrent en jeu dans votre univers. Ces "individus" sont les personnages (certains sont sans doute des personnages joueurs, d'autres peut-être des personnages non joueurs), les items (armes, armures, flacons, parchemins...), les territoires, les villes et villages, les populations, les monstres etc...
Les règles de gestion sont la description de ces interactions. Pour une association simple, de type binaire, il faut à minima deux règles de gestion : une pour chaque "patte" de l'association

Oubliez pour l'instant tout ce qui répond à la question "comment", concentrez vous uniquement sur ce qui correspond à la question "quoi" ou "qui"

Cinephil et moi-même nous vous avons proposé des exemples de règles de gestion. Vous pouvez également consulter les autres sujets ouverts dans cette section pour vous inspirer de ce qu'il faut faire

[CinePhil]

ma catégorie weapon aura toujours comme paramètre une valeur d'attaque par exemple

Donc il y aura, dans l'entité-type "weapon", une propriété (future colonne de la table) nommée par exemple "attack".
Il s'agit d'une propriété spécifique de l'item de type weapon donc l'héritage de données est justifié.

Rappel du principe...

Règle de gestion :
R1 : Une "weapon" est un "item" et un "item" peut être une "weapon".

Remarque 1 : On décrit bien l'association entre UNE weapon et UN item.

MCD :
weapon -(1,1)----être----0,n- item

Remarque 2 : Conséquemment à la remarque 1, les entités-types "weapon" et "item" sont au singulier.

Tables provisoires :
te_item_itm (itm_id, [colonnes communes à tous les items])
th_weapon_wpn (wpn_id_item, attack, [autres colonnes spécifiques à toutes les armes])


Remarque 3 : Les noms des tables sont aussi au singulier. J'utilise ici mon standard de nommage inspiré de celui de SQLPro. Son gros avantage est d'être sûr de ne jamais avoir de noms de table, colonne ou autre objet de la BDD qui soit aussi un mot du langage SQL. On évite ainsi d'éventuels problèmes de syntaxe dans les requêtes. le préfixe "te_" est pour les tables issues des entités-types principales du MCD. Le préfixe "th_" est pour les tables issues des entité-types d'héritage ("te_weapon_wpn" hérite de "te_item_itm").

Remarque 4 : Dans les tables ci-dessus, les clés primaires sont soulignées et les clés étrangères en italique. On voit donc que la clé primaire de la table "th_weapon_wpn" est aussi une clé étrangère référençant la table "te_item_itm".

ma catégorie weapon (...) et aura peut-etre un effect

D'après votre MCD du message #19, un "effect" est une entité-type munie de plusieurs propriétés. Il faut donc écrire une règle de gestion décrivant l'association entre "weapon" et "effect" ou, plus généralement puisque d'autres types d'items peuvent aussi avoir un "effect", entre "item" et "effect".

Règle de gestion :
R2 : Un "item" peut posséder un "effect" et un "effect" peut être possédé par plusieurs "items".

MCD :
item -0,1----posséder----0,n- effect

Tables provisoires :
te_effect_eft (eft_id, ...)
tj_itm_posseder_eft_ipe (ipe_id_item, ipe_id_effect...)

Remarque 5 : D'après la règle de gestion, un "item" ne peut figurer qu'une seule fois dans la table associative "tj_itm_posseder_eft_ipe" (préfixe "tj_" pour "table de jointure") puisqu'il n'a qu'un seul "effect". La clé primaire n'est donc constituée que de la clé étrangère référençant la table des "items"

ma catégorie armor aura toujours une valeur de défense et aura peut-être un effect

Je vous laisse faire le même exercice que ci-dessus et implémenter les deux dans le MCD ou, de préférence, un nouveau MCD pour repartir sur de bonnes bases.

ma catégorie usable n'aura ni attaque ni défense mais peut avoir un effect qui lui ajoutera une valeur d'attaque ou de défense

"attack" et "defence" sont deux propriétés de "effect" dans votre MCD. Rien n'interdit qu'un item de type "weapon", par exemple, soit muni d'une propriété "attack" (de base) et qu'un "effect" sur un item, quel qu'il soit (même une "weapon") augmente (ou attribue à partir de rien) l'attaque de l'item. Ces deux propriétés "attack" ne sont donc pas tout à fait de même nature : il y a d'une part la puissance d'attaque de l'arme et d'autre part l'augmentation de la puissance d'attaque de l'effet. Pour préciser cette distinction, vous pourriez nommer la propriété "attack" de "effect" plutôt "attack_growth".

du coup, je me retrouve avec des paramètres qui forme un triangle dans plusieurs tables

En réfléchissant un peu plus profondément à la vraie signification des propriétés, vous voyez que ce n'est plus tout à fait le cas !

C'est quoi un "key_item" ?

Un item plus rare pour certaines quêtes

Donc c'est un "item" spécial, un type d'item, au même titre que "weapon" est un type d'item, non ?

J'avais dans l'idée que le joueur peut définir ses couleurs lui même donc une couleur serait une valeur RGB par exemple, donc je le considère plus comme un paramètre qu'une entité.

Pourquoi pas ! Mais c'est le côté 5 couleurs => 5 colonnes qui est gênant.
Soit ces couleurs s'appliquent sur des choses en quantité bien définie (couleur de costume, de casque, de bottes...) auquel cas vous pouvez avoir une colonne par couleur : "costume_color", "helmet_color", "boots_color"...
Soit il peut y avoir de une à plusieurs couleurs sur les parties d'un personnage et nous avons là une association entre le personnage et ses parties dont une propriété est la couleur RGB...

Règle de gestion :
R3 : Un "hero" est constitué de une à plusieurs "hero_parts" et une "hero_part" entre dans la constitution d'un "hero".

MCD :
hero_part -(1,1)----constituer----1,n- hero

Tables provisoires :
te_hero_hro (hro_id...)
te_hero_part_hpt (hpt_id_hero, hpt_part_number, hpt_color...)

Remarque 6 : Nous n'avons pas ici un héritage mais une composition. "hero_part" est défini relativement à "hero" (cardinalités 1,1 entre parenthèses) parce que c'est une partie du héros qui ne peut plus exister si on supprime le héros. La clé primaire de la table "te_hero_part_hpt" est ainsi constituée de la clé étrangère "hpt_id_hero" référençant la table "te_hero_hro" et du numéro de partie du héros "hpt_part_number".

Remarque 7 : Si les parties d'un héros sont toujours les mêmes et si la seule propriété de ces parties est la couleur, je vous invite à conserver vos colonnes de couleurs mais en les nommant plus précisément.

[noals]

Son gros avantage est d'être sûr de ne jamais avoir de noms de table, colonne ou autre objet de la BDD qui soit aussi un mot du langage SQL

oui, c'est pour ça que mon "users" est encore au pluriel, looping ne me laisse pas utiliser de mot réservé à sql. J'en changerai plus tard, je préfère des noms de table les plus compréhensibles possible pour moi, ne serait-ce que pour m'y retrouver ensuite en programmant.

Si les parties d'un héros sont toujours les mêmes et si la seule propriété de ces parties est la couleur, je vous invite à conserver vos colonnes de couleurs mais en les nommant plus précisément.

Oui, les parties seront les même. J'en ai mis 5 comme j'aurai pu en mettre 3, ça dépendra du chara design et je n'en suis pas encore là, c'est aussi une manière pour moi de garder l'idée.


J'ai refais les items, je verrai ensuite pour les effect, skill, etc... il y a des trucs que je n'ai pas encore bien définis donc il faut que j'y réfléchisse.

[CinePhil]

Ça commence à prendre une forme sympathique !

Pour les élément-type, weapon-type et armor_type, je vous suggère fortement d'externaliser ça dans des entiés-types de référence.

Règle de gestion :
Un "weapon" est typé par un "weapon_type" et un "weapon_type" peut typer plusieurs "weapons".

MCD :
weapon_type -0,n----typer----1,1- weapon

Tables :
tr_weapon_type_wtp (wtp_id, wtp_code, wtp_libelle, wtp_order)
th_weapon_wpn (wpn_id_item, wpn_id_weapon_type, wpn_attack...)

Remarques :
1) J'insiste un peu avec mon standard de nommage mais vous faites comme vous voulez ! Le préfixe "tr_" est pour les tables de référence.
2) le "wtp_id" est un identifiant entier et auto-incrémenté, purement technique et sans signification. J'ai ajouté le "wtp_code" qui peut être un caractère ou une petite chaîne de caractères de longueur fixe, mnémotechnique pour le libellé du type.
3) J'ai aussi ajouté un "wtp_ordre" qui permet d'afficher la liste des items dans un ordre que vous décidez. Si vous ajoutez plus tard un "weapon_type", il aura l'identifiant suivant (dans votre liste, le 8) mais vous voudrez peut-être l'afficher après "shield", par exemple. La colonne "wtp_order" permet de faire ça facilement sans devoir bidouiller le code de l'application.

Je vous laisse faire le même exercice pour les element_types et les armor_types.

Dernière remarque pour ce coup là : en anglais, c'est plutôt "defence" que "defense" !
https://www.linguee.fr/francais-angl...3%A9fense.html

[noals]

Faut que je me creuse un peu le crâne pour les effets là.

[CinePhil]

Je ne sais pas si c'est votre logiciel qui fait ça ou vous qui l'utilisez mal mais autant les associations d'héritage sont bien représentées, autant les associations simples ne sont pas du formalisme habituel d'un MCD merisien.
Vous avez aussi vos clés étrangères dans les entités-types alors qu'elles ne devraient pas figurer sur le MCD.

[escartefigue]

J'ai l'impression qu'il ne s'agit pas d'un logiciel de modélisation mais d'un outil de dessin, à cause notamment des liens entre les ET

Il existe quelques logiciels de modélisation gratuits, cf. cette discussion : https://www.developpez.net/forums/d4...-realiser-mcd/

[noals]

J'ai ça donc ça doit être moi qui ne m'en sert pas académiquement mais tant que je comprends ce que je fais, ça ne me préoccupe pas plus que ça.



Je réfléchis à mes tables pour skills, effects, etc... mais j'hésite à ouvrir un autre sujet parce que j'ai aussi besoin de savoir dans quelle mesure je peux effectuer des calculs avec postgresql.
Pour un personnage, j'ai défini la vitality, strengh, etc... mais j'ai aussi besoin d'un calcul intermédiaire pour les hp (health point), l'attack, etc... car mes skills ou autre se basent aussi sur ces notions.
Est-ce qu'il est possible d'automatiser ça avec postgresql ?

[CinePhil]

J'ai ça

Il semble donc que ce soit bien un logiciel de modélisation que je ne connais pas. Pourtant, il vient de l'université de Toulouse, pas loin de mon boulot !
Mais bon faut dire que comme il est sous Winbug, ce n'est finalement pas étonnant que je ne le connaisse pas puisque je suis linuxien.

donc ça doit être moi qui ne m'en sert pas académiquement mais tant que je comprends ce que je fais, ça ne me préoccupe pas plus que ça.

Vous avez pourtant un exemple correct sur l'écran que vous nous montrez d'une association classique : "Asso 2".
C'est bien comme ça qu'il faut faire entre "item" et "element_type" (au fait, pourquoi pas "item_type" ? ), entre "weapon" et "weapon_type" et entre "armor" et "armor_type".

j'ai aussi besoin de savoir dans quelle mesure je peux effectuer des calculs avec postgresql.

Ne vous inquiétez pas pour ça ! Le SQL est un langage complet et on peut même faire des choses bien plus efficacement sur des masses de données qu'avec un langage de programmation classique.

N'allez pas trop vite et concentrez-vous pour le moment sur la modélisation des données !

[noals]

au fait, pourquoi pas "item_type" ?

lol, c'est vrai, autant le faire aussi. ^^;

Ne vous inquiétez pas pour ça ! Le SQL est un langage complet et on peut même faire des choses bien plus efficacement sur des masses de données qu'avec un langage de programmation classique.

ha ok cool, ben j'y retourne alors.

[noals]

Bon ben je ne sais pas comment ils font les autres mais perso, avec tous les traits c'est trop le bordel lol, alors j'ai fait autrement mais je m'en sors pas trop mal je pense.

[noals]

et j'en arrive à ce genre de truc avec pour l'instant
-les personnages
-les objects
-les capacités ou bonus
-les npcs
-les guilds
-les groupe
-l'organisation de la map
-la friendlist des joueurs

-et les interactions entre tout ça qu'il me reste à modéliser si je ne me trompe pas sur le terme.

[escartefigue]

Heu ...
la quasi totalité de vos entité-type sont isolées, il manque tous les liens d'association

Dans la plupart des logiciels de modélisation, il suffit de glisser la souris d'une entité-type vers une autre pour créer la relation, en l'état votre schéma est inutilisable

[noals]

Oui, je me suis déjà concentré sur l'isolement des entités justement ne serait-ce que pour y voir plus clair et organiser la base.
Les quelques liens d'associations affichés sont les liens qui respectent une hiérarchie en plus des héritages.
Les autres liens d'associations qui ne sont pas affichés sont en générale ceux qui regroupent deux entités bien distinctes et qui ont besoin d'un contenant avec index donc ces liens sont quasi tous identiques (et avec les traits dans tous les coins, c'était le bordel) et je défini les paramètres de ces contenants.
Il y a juste certains endroits où je vais peut-être rajouter des type d'entité (ou type d'association), je ne sais pas encore. (edit: d'ailleurs j'ai tjr pas mis les type d'item ><, ce sera fait)

Ça ne me dérange pas si je dois construire la base manuellement, un shéma comme ça me permet d'y voir clair et de savoir ce que je fais car tout est plus ou moins explicite.

[noals]

Bon ben autant rester simple avec un exemple précis.
Déjà, est-ce que ceci est correcte ?
Comment l'améliorer ? (edit : je demande surtout pour les liaisons, les paramètres vont surement changer selon comment j'optimiserai la base de données)

[escartefigue]

Bonjour,

Difficile de répondre sans les règles de gestion mais quelques commentaires tout de même

Entité-type NPC
Au niveau conceptuel, seul l'identifiant de l'entité-type doit apparaitre. Il faut donc supprimer npc_type_id et sprite_id
C'est lors de la génération du MLD que les clefs étrangères seront rappatriées dans les tables coté cardinalité maxi "1" de la relation


Entités-type monster et adventurer
Il s'agit de sous-types de l'ET NPC, donc il n'y a pas d'identifiant. L'identifiant sera le même que celui de NPC
Là aussi, supprimez les id étrangers à l'ET (e_type_id, m_type_id)


Entité-type item_of_npc
A priori (la encore sous réserve de vos règles de gestion) cette ET n'a pas lieu d'être.
il y a deux "individus" au sens conceptuel : le personnage et l'équipement, ces deux "individus" sont en relation comme suit :
PERSONNAGE 0,n --- posseder --- 1,1 EQUIPEMENT 1,1 --- typer --- 0,n TYPE_EQUIP


Relations type-of-npc, type_off_m, type_of_w...
D'une façon générale, une même typologie peut être utilisée zéro à plusieurs fois
La patte côté typologie doit donc avoir des cardinalités 0,n

[noals]

Ok, merci.
Je sais que ça fais 10 fois que vous répétez la même chose, j'avoue que c'est pas une méthode qui me plait et je m'y perd un peu avec le double sens des règles des fois mais elle me fait avancer quand même donc je vais refaire tout ça.
Je suis quand même content de bien avoir différencié mes données, ça m'aidera.

[CinePhil]

Le double sens des règles est essentiel.

Exemple :
Une personne peut posséder de plusieurs voitures.

Et la voiture ? Peut-elle être possédée par plusieurs personnes ou une seule ?
Dans la vraie vie, une carte grise de véhicule est au nom d'une seule personne, il me semble.

Par contre, si on fait la même chose avec un logement...
Une personne peut posséder plusieurs logements.

Et le logement ?
Dans la vraie vie, un logement peut être possédé par plusieurs personnes. C'est même le plus souvent le cas.

Donc les règles complètes sont :
Une personne peut posséder plusieurs voiture et une voiture est possédée par une seule personne.
Une personne peut posséder plusieurs logements et un logement est possédé par une à plusieurs personnes.

MCD :
Personne -0,n----posséder----1,1- Vehicule
|---------------0,n----posséder----1,n- Logement

Les cardinalités ne sont pas les mêmes et les tables n'auront pas la même structure.

Tables :
te_personne_prs (prs_id, prs_nom...)
te_vehicule_veh (veh_id, veh_id_proprietaire, veh_immatriculation...)
te_logement_lgm (lgm_id, lgm_adresse1...)
tj_prs_posseder_lgm_ppl (ppl_id_proprietaire, ppl_id_logement...)

[noals]

il y a des erreurs vu que le programme n'affiche plus le sql et ce n'est pas fini mais voilà déjà :