Discussion :

[deedolith]

Bonjour,

Je me fait une base de données afin de suivre ma progression sur Final Fantasy 6.

Pour vous expliquer simplement le contexte:
Le joueur rencontre des monstres formations de monstre.
Une formation regroupe entre 1 et 6 monstres.
Chaque monstre à, outre ses caractéristiques, une compétence particulière appelée Frénésie.
Le joueur peut acquérir ces frénésies, à condition qu'elle soit issue d'un monstre déjà rencontré (ou plutôt un monstre présent dans une formation déjà rencontrée).

J'ai donc fait la modélisation suivante:

Mais je n'en suit pas très satisfait. En effet, ce modèle autorise l'acquisition de n'importe quelle frénésie, qu'elle soit issue d'un monstre déjà rencontré ou non.

J'ai très envie de mettre un lien entre les relations Acquiert et Rencontre, mais Merise ne l'autorise pas.
Quelle solution est envisageable ?

[escartefigue]

Bonjour deedolith et bienvenue dans ce forum

Un MCD n'est valide que s'il est conforme aux règles de gestion métier, or, vous n'avez communiqué aucune règle de gestion.
Voyez dans ce fil de discussion, réponse n°8, comment les rédiger

D'après ce que je comprends, un utilisateur ne peut acquérir une "frénésie" (terme à expliquer) que s'il a fait une rencontre d'un monstre possédant cette "frénésie".
Pour ce genre de besoins, il faut mettre en oeuvre une contrainte d'inclusion. Dans Looping, l'outil est présent dans la barre d'icones, de mémoire c'est un cercle jaune (je n'ai pas Looping sur ce poste pour le vérifier).

Mais chaque chose en son temps, tout d'abord, précisez bien vos règles de gestion

[deedolith]

Heu ..., je trouves que tu chipottes,
le MCD que j'ai posté est plutôt explicite, j'ai exprimé mon besoin, et apporté les explications adéquat.
Pour rappel: Un monstre a des compétences (que je n'ai pas modélisé car je n'en ai pas besoin), dont une particulière appelée Frénésie. On se contentera de connaitre son nom.

Règles de gestion métier, étant plutôt programmeur, je ne doit pas avoir la même définition que toi.
De mon point de vue, ce sont les règles qui permettent de transformer les données d'un état d'entrée vers un état de sortie, ainsi que les restrictions applicables.

C'est le point suivant qui me pose problème:
Le joueur peut acquérir ces frénésies, à condition qu'elle soit issue d'un monstre déjà rencontré (ou plutôt un monstre présent dans une formation déjà rencontrée).
D'une part, je ne sais pas comment le modéliser.
D'autre part, je ne sais pas comment l'implémenter.

[escartefigue]

Au stade du MCD les règles de gestion concernent évidemment les données et non pas les traitements, donc les changements d'état et les entrées et sorties sont hors sujet à ce stade.
Comme dit précédemment, pour vérifier qu'un joueur ne peut acquérir une "frénésie" que s'il a rencontré le monstre possédant cette "frénésie", il faut inverser les liens d'association comme dans le MCD ci-dessous, mais ceci n'est possible que si les règles de gestion (au sens de la modélisation des données) le permet.
A partir de là, mettre en oeuvre une contrainte d'inclusion devient très simple.

Ce qui donnerait le MCD suivant :



D'après ce MCD, le joueur rencontre non pas une formation, mais un monstre, monstre qui fait partie ou pas d'une formation.
A vous de voir si ça correspond ou pas aux règles de gestion.

[fsmrel]

Bonjour,

Capitaine, ton MCD répond de façon élégante à l’attente de deedolith, à moins qu’une règle de gestion à venir de sa part précise que la connaissance de la formation "rencontrée" par l’utilisateur soit indispensable.
 
deedolith, deux points :

a) Le MCD proposé par Escartefigue trouve-t-il grâce à vos yeux ?

b) Avez-vous besoin du code SQL produit par Looping ?

 

Une remarque concernant l’identification relative

L’association Posseder pourrait être identifiée relativement à l’entité-type Monstre. A défaut, l’entité-type Frenesie possède deux identifiants : {Id} et {MonstreId}, ce dernier étant hérité du fait des cardinalités dont est dotée cette association. {Id} n’apporte rien et peut passer au rasoir d’Ockham.

 

[deedolith]

a) Le MCD proposé par Escartefigue trouve-t-il grâce à vos yeux ?

Bonjour,

Plusieurs choses me font tiquer.
je ne vais pas invoquer de nouvelles règles, mais réitérer celles que j'ai déjà cité et apporter des précisions qui m'on parues évidentes:
Un utilisateur peut rencontrer des formations de monstres.
Une formation comprend 1 à 6 monstres.
Une formation peut être rencontrée par des joueurs.
Un monstre fait partie d'au moins 1 formation (je ne voit d'ailleurs pas pourquoi les cardinalités ont été changées autour de la relation "Aggrege".

J'insiste sur le fait que c'est la formation qui est rencontrée, ce qui implique que les monstres composant cette dernière sont rencontrés en même temps.
Si l'utilisateur pouvais rencontrer un monstre, cela n'impliquerait pas que la ou les formation(s) parentes sont rencontrées.

b) Avez-vous besoin du code SQL produit par Looping ?

Je ne pense pas en avoir besoin.
Par contre, je souhaiterais savoir comment va se traduire ces contraintes au niveau de la base de données, des triggers ?

Est ce que je peux également demander des précisions sur ces contraintes ?
Mes cours de Merise commencent à dater, ce sont des notions qui me sont inconnues.