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?

[f-leb]

Bonjour,

Je suppose que tes règles de gestion sous-entendent une contrainte inter-associations d'inclusion.

Je pense que ton logiciel de modélisation ne permet pas de les prendre en compte, mais on sort un peu du cadre Access, tu devrais poser ta question dans le forum schéma et passer à Looping qui permet de créer les scripts SQL de création de tables avec Access comme cible.

Note : tu es sûr de tes cardinalités ? Notamment avec les cardinalités 1,1 de chaque côté de l'association Posséder :
Monstre----1,1----posseder----1,1----Frenesie

[deedolith]

Je pense que je voit l'idée, bien que je ne suis pas sûre d'avoir tout compris.
En pratique, cela se traduit par un trigger (data macro) ?

Je pense que ton logiciel de modélisation ne permet pas de les prendre en compte,

J'utilise AnalyseSI.

Note : tu es sûr de tes cardinalités ? Notamment avec les cardinalités 1,1 de chaque côté de l'association Posséder :
Monstre----1,1----posseder----1,1----Frenesie

L'idée est de décoréléer les frénésies des monstres (chaque monstre possède une seule frénésie).
En théorie, c'est une relation 1:1 / 1:1, en pratique une relation 0:1 / 1:1 sera plus adaptée (à ma connaissance, on ne peut mettre à jour 2 tables simultanément).

[f-leb]

Je pense que je voit l'idée, bien que je ne suis pas sûre d'avoir tout compris.

Moi non plus, c'est bien pour ça que j'ai proposé de poser ta question sur le forum Schéma où sont présents les cadors de la modélisation.

En pratique, cela se traduit par un trigger (data macro) ?

Ou du VBA dans tes formulaires, du genre une liste déroulante qui ne présentent que les frénésies déjà rencontrées par l'utilisateur.

J'utilise AnalyseSI.

Il fait ce qu'il peut, mais peut peu... Looping est bien plus complet, et tout aussi simple d'utilisation et gratuit.

En théorie, c'est une relation 1:1 / 1:1, en pratique une relation 0:1 / 1:1 sera plus adaptée ...

Il ne peut pas y avoir de MCD "en théorie" et un autre "en pratique". Il faut modéliser l'intention d'abord sur un MCD. La mise en oeuvre pratique viendra après le MCD avec les tables, les clés, les data macros, le SQL et le VBA sur Access.
Si c'est vraiment 1,1 des deux côtés, je ne vois pas pourquoi tu ne mettrais pas un attribut nomFrenesie (avec une contrainte d'unicité) dans l'entité Monstre (je vois que Looping n'autorise pas la création de ces cardinalités 1,1 de chaque côté de l'association).

[f-leb]

Bonsoir,

Alors si je reprends le schéma suivant :



Et qu'on a la règle de gestion :

"Un utilisateur ne peut acquérir une frénésie que si celle-ci appartient à un monstre d’une formation rencontrée par l’utilisateur."

J'ai réglé ça avec une macro de données (data macro), des triggers en quelque sorte, à la façon d'Access...

On commence par une requête enregistrée R_frenesies_rencontres qui donne les monstres rencontrés pour chaque utilisateur :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT DISTINCT Rencontrer.UtilisateurId, Agreger.MonstreId
FROM Agreger INNER JOIN Rencontrer 
ON Agreger.FormationId = Rencontrer.FormationId;

Et on prépare la macro suivante sur l'évènement Avant Modification de la table Acquerir :



Si Rechercher un enregistrement... donne un résultat pour la saisie en cours, c'est que l'utilisateur a bien rencontré le monstre et la saisie est valide. On quitte alors la macro, et l'enregistrement est validé.
Si Rechercher un enregistrement... ne renvoie rien, l'utilisateur n'a jamais rencontré le monstre, on quitte immédiatement le bloc, et on déclenche une erreur.

Franchement, c'est pas très intuitif cette façon de programmer, je trouve ça même très moche Mais ça fait le boulot...
Quand on force un enregistrement délinquant (sur insertion ou mise à jour d'un enregistrement), la validation devient impossible :