Discussion :

[Betanaelle]

Bonjour,

Je voudrai vérifier que l'héritage que j'ai fait tient la route, vous trouverez donc une image des tables concernés.

Explication : J'ai une table objet qui correspond à des objets réels, ces objets sont issus d'autres tables d'objet générique. Hors je me suis rendu compte que certains attributs étaient identique à toutes ces tables, j'ai donc créé une table contenant les attributs commun et j'ai relié les autres tables via l'héritage dessus.
La table mère s'appelle model_objet et les tables filles sont les tables arme, armure, contenant, moteur, roue, chassis, drogue .
Les cardinalités sont simple, 1 objet réel appartient à 1 table modèle, 1 objet modèle peut servir à faire 0 ou n objet réel.

Est-ce que c'est correct ?

[CinePhil]

Avec ton schéma, un "objet" est typé à la fois en une armure, une arme, un contenant...

En plus tu as fait une unique association typer impliquant plus de deux entités types et une patte avec des cardinalités 1,1, ce qui est le plus souvent le signe d'une erreur et c'est bien le cas ici.

Je ne suis pas sûr que tu aies besoin de l'entité type "objet".

Vu les noms des entités types filles, je suppose qu'il s'agit d'un modèle pour un jeu en ligne ?

On va se limiter à l'exemple de l'arme.

Selon l'héritage que tu as modélisé, une arme est un objet_simple et un objet-simple peut être une arme.

Je suppose que les personnages incarnés par les joueurs vont à certains moment posséder ces armes.
Tu peux alors avoir l'association suivante :
joueur -0,n----posséder----0,n- objet_simple -0,1----etre----(1,1)- arme

La table associative engendrée à partir de l'association posséder te permettra de savoir de quelles armes dispose tel joueur.

Quant à l'attribut "pr_courant" figurant dans l'entité objet et dont je ne comprends pas la signification, ne peut-il être déplacé dans l'association posséder que j'ai suggéré ci-dessus ?

[Betanaelle]

Bonsoir Cinephil

Alors oui c'est bien pour un jeu en ligne.
pr_courant = point de résistance courant
pr_max = point de résistance max

un objet modèle a donc un pr_max de base, l'objet réel que possèdera le joueur lui aura un pr_courant avec bien sur pr_courant <= pr_max

Par contre j'ai fait un lapsus, la table mère s'appelle objet_simple et pas model_objet comme précédemment expliqué, mais je pense que tu as corrigé.

J'ai besoin d'avoir d'un coté une liste et les caractéristiques de tous les types d'objets pouvant exister sur le jeu (pour me permettre d'en rajouter un nouveau par exemple).
Et de l'autre des objets qui auront réellement une existence sur le jeu, et qui seront posséder par les personnages (mais aussi qui pourront être porter par des animaux, dans des véhicules, stocker dans des bâtiments, poser par terre sur la case, échanger entre les persos aussi.)
1 objet réel est forcément issu d'1 seul modèle (soit une arme, armure etc, soit un objet_simple)

Je comptais vous mettre la suite dans un autre topic, car cette relation (posséder) je la vois avec avec plusieurs branches et je ne suis pas sur du résultat, mais on verra plus tard, corrigeons d'abord le début.

Avec ton explication je ne vois pas comment je peux avoir mes 2 besoins.
Peut-être ai-je mal fait les flèches pour l'héritage remarque bien, c'est la première fois que je fais ça.

le "pr_courant" pourrait être rajouter comme attribut de la relation posséder cela dit, il y a déjà l'attribut "quantité" qui s'y trouve.

Si tu as besoin de voir le reste du MCD je peux le poster aussi.

[CinePhil]

Donc si je comprends bien, pour en rester sur l'exemple de l'arme, la table arme contiendrait par exemple arc, couteau, blaster, sabre laser et la table objet de ton schéma contiendrait potentiellement plusieurs exemplaires d'arcs, de couteaux de blasters et de sabres laser ?

Pour en rester sur le cas simple du joueur possédant une arme, l'association que j'ai proposée dans mon message fait en fait la même chose que ton entité objet :

joueur -0,n----posséder----0,n- objet_simple -0,1----etre----(1,1)- arme

L'association posséder entraîne la création d'une table associative dont chaque ligne correspond à une arme possédée par un joueur. On peut ainsi avoir 5 joueurs différents qui seraient des Jedi munis chacun de leur sabre laser.

Chaque sabre laser sera identifié par le couple {joueur_id, objet_simple_id}

Comme l'association pointe non pas sur l'entité fille arme mais sur l'entité mère objet_simple, ça fonctionne pareil avec tout type d'objet.

(mais aussi qui pourront être porter par des animaux, dans des véhicules, stocker dans des bâtiments, poser par terre sur la case, échanger entre les persos aussi.)

La première approche consiste ici à créer autant d'associations similaires à celle que j'ai donnée plus haut. Par exemple :
animal -0,n----porter----0,n- objet_simple
batiment -0,n----stocker----0,n----|

Mais j'imagine que ça se complique car tous les objets ne peuvent pas être portés par des animaux ou stockés dans des bâtiments. Ces associations ne peuvent se faire qu'avec certains types.

Peut-être aussi que tu veux considérer qu'il n'y a par exemple qu'une seule étoile noire dans la galaxie et que Lando Calrissian ne peut pas en avoir une sauf s'il l'a piquée à Palpatine ?
En clair, peut-être as-tu la contrainte qu'un objet existe en un certain nombre d'exemplaires ?

Je n'ai pas trop le temps de réfléchir à ces difficultés maintenant mais j'espère que ce message aura éclairé un peu ta réflexion.

Juste une piste qui me vient :
joueur -0,n----posséder----0,1- objet -1,1----typer----0,n- objet_simple -0,1----etre----(1,1)- arme

L'entité objet représenterait cette fois tous les objets physiques et la table issue de cette entité contiendrait donc potentiellement plusieurs sabres lasers qui pourraient être possédés chacun par au maximum un joueur.

A+

[Betanaelle]

Bonsoir Cinephil,

Désolé pour le retard sur ta réponse.

Dans les 2 solutions que tu me proposes, je ne sais pas ce qu'il en est de l'héritage que j'ai fais.

Du coup je te remets une image qui comprends la correction sur les flèches de l'héritage et les relations avec 5 tables supplémentaire.

Le principe comme tu l'as si bien rappelé, c'est que le sabre laser de Luke n'est pas celui de Dark Vador, et que si Obiwan perd son sabre laser, il peut récupérer un pistolaser pour tirer sur l’infâme Général Grievous.

La relation 1,1 me semble correcte car 1 objet est forcément typer à partir de : une table fille ou une table mère, au choix

Il n'y a donc que des objets créés à partir de différent modèle qui sont dans la table objet
Ces objets ne peuvent être qu'à 5 endroits dans le jeu : sur une case, sur un perso, dans un véhicule, dans un batiment et sur un animal.
Des objets peuvent aussi servir à assembler un véhicule ( on doit pouvoir donc y avoir accès à partir du véhicule pour réparation par exemple)
Des objets peuvent servir à fabriquer d'autre objet n'est pas modélisé, car il y aura delete et create, donc je n'ai pas créé de relation "récursive" (j'ai un doute sur la définition exacte) pour ne pas me compliquer inutilement.
Des objets peuvent être échanger entre perso -- perso et perso -- ville, je l'ai donc modélisé aussi, mais pas sur l'image que je vous donne, je comptais en parler plus tard.

Sur l'image du MCD on voit qu'il y a la relation être au sol et posseder_transporter_stocker qui ressemble beaucoup à ta relation posséder Cinephil. D'ailleurs au vu des cardinalités je me demande s'il ne vaudrait pas mieux mettre une seule relation qui lierait objet et les 5 autres tables.

[CinePhil]

Dans les 2 solutions que tu me proposes, je ne sais pas ce qu'il en est de l'héritage que j'ai fais.

Dans mon schéma, l'héritage existe seulement entre arme et objet_simple :

joueur -0,n----posséder----0,1- objet -1,1----typer----0,n- objet_simple -0,1----etre----(1,1)- arme

D'ailleurs, un héritage se traduit toujours dans un MCD par le verbe être et les cardinalités 0,1-(1,1).

Il correspond à l'héritage que tu as fait sauf que la partie basse de ton MCD se retrouverait dans le mien en haut !

Encore une fois, ton association typer fait qu'un objet est typé à la fois comme une armure ET comme une arme ET comme un contenant...

Un autre héritage que l'on pourrait faire, qui serait sémantiquement bizarre mais conceptuellement correct serait dû à cette phrase :

Ces objets ne peuvent être qu'à 5 endroits dans le jeu : sur une case, sur un perso, dans un véhicule, dans un batiment et sur un animal.

Généralisons ces 5 endroits :
case -(1,1)----etre-------0,1- endroit
perso -(1,1)----etre----0,1--------|
vehicule -(1,1)----etre----0,1----|
batiment -(1,1)----etre----0,1---|
animal -(1,1)----etre----0,1------|

Il suffit ensuite d'ajouter l'association pour situer les objets :
case -(1,1)----etre-------0,1- endroit -0,n----situer----1,1- objet
perso -(1,1)----etre----0,1--------|
vehicule -(1,1)----etre----0,1----|
batiment -(1,1)----etre----0,1---|
animal -(1,1)----etre----0,1------|

Puis tu y colles la partie droite de mon schéma :
... situer----1,1- objet -1,1----typer----0,n- objet_simple -0,1----etre----(1,1)- arme

[Betanaelle]

D'ailleurs, un héritage se traduit toujours dans un MCD par le verbe être et les cardinalités 0,1-(1,1)

Eureka ! j'ai compris, je sens la force en moi (une petite d'ailleurs) et oui je suis juste padawan débutant.

Je vois mon erreur en effet maintenant, désolé de ne pas avoir capter plus tôt.

Du coup j'ai modifié le MCD et j'ai ajouté la table endroit comme tu peux voir sur la pièce jointe.
A cette table j'ai ajouté un id et l'attribut quantite mais je ne sais pas si c'est suffisant.

Il est vrai que ça fait bizare d'un point de vue sémantique.

Là où c'est intéressant, c'est que j'ai d'autre relation 1,1--0,1 dans le reste de mon MCD, il faut donc que je vois si je ne me suis pas trompé dans les cardinalités et donc mettre l'héritage correctement. J'étais resté sur un héritage sémantique.

[CinePhil]

Sur le plan des associations entre entités, ça me semble pas mal.
Je n'ai pas regardé en détail le contenu des entités.

[Betanaelle]

Merci Cinephil,

On va donc en conclure que c'est résolu, je vais vous poster d'autre question sur d'autres interrogations que j'ai concernant d'autres tables dans un autre topic