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.

[escartefigue]

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".

Vu qu'une formation peut être composée d'un seul monstre, ma proposition de modèle communiquée hier à 9h12 est valide, il suffit de modifier les cardinalités de [MONSTRE] vers (agreger) pour remplacer 0,n par 1,n
Vous pouvez en profiter pour identifier la frénésie relativement au monstre comme l'a judicieusement proposé Fsmrel plus haut.

Concernant le code SQL, la contrainte d'inclusion se traduit par une contrainte de type REFERENCE, elle ressemblera à ceci

Code SQL :

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

1
2
3
4
5
alter table AQ_acquerir
add constraint FK_AQ_AC
foreign key (UT_ident, MO_ident)
references RE_rencontrer (UT_ident, MO_ident)
;

Notez "agréger" avec un seul "g" contrairement à l'anglais "aggregate"

Dans votre premier modèle, le type d'entité [MONSTRE] possède un attribut nommé gameid qui est probablement l'identifiant d'un autre type d'entité.
Si c'est bien le cas, il doit être supprimé : les clefs étrangères n'ont pas lieu d'être au stade conceptuel, elle sont la conséquence de la dérivation du MCD en modèle tabulaire et n'apparaissent donc que dans les MLD et MPD

[deedolith]

Ok,

Mais si je comprend bien, la contrainte doit plutôt s'appliquer sur les relations "Acquiert" et "Rencontre" ?

[escartefigue]

Oui et c'est le cas : au niveau tabulaire, j'ai nommé les tables issues de ces associations selon une norme que j'applique souvent (préfixe unique par table, qu'on retrouve dans chaque attribut de cette table).

[fsmrel]

Bonjour,

Concernant le code SQL, la contrainte d'inclusion se traduit par une contrainte de type REFERENCE, elle ressemblera à ceci

Code SQL :

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

1
2
3
4
5
 
alter table AQ_acquerir
add constraint FK_AQ_AC
foreign key (UT_ident, MO_ident)
references RE_rencontrer (UT_ident, MO_ident);

Mais ceci permet à un utilisateur d’acquérir une frénésie appartenant à un monstre ne faisant pas partie des formations qu’il rencontre...

[escartefigue]

Que nenni : la contrainte fait référence au duo (identifiant utilisateur, identifiant monstre), on répond donc bien au besoin

[fsmrel]

Que nenni : la contrainte fait référence au duo (identifiant utilisateur, identifiant monstre), on répond donc bien au besoin

Négatif ! Je répète que ceci permet à un utilisateur d’acquérir une frénésie appartenant à un monstre ne faisant pas partie des formations que cet utilisateur rencontre...

Je rappelle en effet le point sur lequel deedolith insiste :
 

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.

Il faut donc appeler un chat, un chat.

Pour s’assurer que chaque utilisateur ne puisse acquérir que des frénésies possédées par des monstres faisant partie des formations qu’il rencontre, il faut mettre en oeuvre une association, appelons-la UFM, entre les associations Rencontre, Acquiert et Agrege.
 
Comme Merise ne le permet pas, il faut transformer ces associations en entités-types. Pour cela, on utilise l’icône en bas à droite de la boîte Association :

 
 
MCD que je propose :
 

 
Bien entendu, Looping produit pour la table UFM une structure où les attributs UtilisateurId , FormationId et MonstreId redondent :
 

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
CREATE TABLE UFM
(
   UtilisateurId INT,
   FormationId INT,
   FormationId_1 INT,
   MonstreId INT,
   UtilisateurId_1 INT,
   MonstreId_1 INT,
   PRIMARY KEY(UtilisateurId, FormationId, FormationId_1, MonstreId, UtilisateurId_1, MonstreId_1),
   FOREIGN KEY(UtilisateurId, FormationId) REFERENCES Rencontrer(UtilisateurId, FormationId),
   FOREIGN KEY(FormationId_1, MonstreId) REFERENCES Agreger(FormationId, MonstreId),
   FOREIGN KEY(UtilisateurId_1, MonstreId_1) REFERENCES Acquerir(UtilisateurId, MonstreId)
);

Je ne sache pas que nos AGL permettent de produire une table non redondante, à savoir :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
CREATE TABLE UFM
(
   UtilisateurId INT,
   FormationId INT,
   MonstreId INT,
   PRIMARY KEY(UtilisateurId, FormationId, MonstreId),
   FOREIGN KEY(UtilisateurId, FormationId) REFERENCES Rencontrer(UtilisateurId, FormationId),
   FOREIGN KEY(FormationId, MonstreId) REFERENCES Agreger(FormationId, MonstreId),
   FOREIGN KEY(UtilisateurId, MonstreId) REFERENCES Acquerir(UtilisateurId, MonstreId)
);

On supprimera donc les redondances à la main.

Exemple avec SQL Server, création des tables :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
create table Formation
(
   FormationId INT,
   FormationNumero INT NOT NULL,
   PRIMARY KEY(FormationId),
   UNIQUE(FormationNumero)
);
create table Monstre
(
   MonstreId INT,
   MonstreNom VARCHAR(24) NOT NULL,
   PRIMARY KEY(MonstreId),
   UNIQUE(MonstreNom)
);
 
create table Agreger
(
   FormationId INT,
   MonstreId INT,
   PRIMARY KEY(FormationId, MonstreId),
   FOREIGN KEY(FormationId) REFERENCES Formation(FormationId),
   FOREIGN KEY(MonstreId) REFERENCES Monstre(MonstreId)
);
create table Frenesie(
   MonstreId INT,
   FrenesieNom VARCHAR(24) NOT NULL,
   PRIMARY KEY(MonstreId),
   FOREIGN KEY(MonstreId) REFERENCES Monstre(MonstreId)
);
 
create table Utilisateur
(
   UtilisateurId INT,
   UtilisateurNom VARCHAR(24) NOT NULL,
   PRIMARY KEY(UtilisateurId)
);
create table Rencontrer
(
   UtilisateurId INT,
   FormationId INT,
   PRIMARY KEY(UtilisateurId, FormationId),
   FOREIGN KEY(FormationId) REFERENCES Formation(FormationId),
   FOREIGN KEY(UtilisateurId) REFERENCES Utilisateur(UtilisateurId)
);
 
create table Acquerir
(
   UtilisateurId INT,
   MonstreId INT,
   PRIMARY KEY(UtilisateurId, MonstreId),
   FOREIGN KEY(UtilisateurId) REFERENCES Utilisateur(UtilisateurId),
   FOREIGN KEY(MonstreId) REFERENCES Frenesie(MonstreId)
);
 
create table UFM
(
   UtilisateurId INT
,  FormationId INT
,  MonstreId INT
   PRIMARY KEY(UtilisateurId, FormationId, MonstreId)
,  FOREIGN KEY(UtilisateurId, FormationId) REFERENCES Rencontrer(UtilisateurId, FormationId)
,  FOREIGN KEY(FormationId, MonstreId) REFERENCES Agreger(FormationId, MonstreId)
,  FOREIGN KEY(UtilisateurId, MonstreId) REFERENCES Acquerir(UtilisateurId, MonstreId)
);

Jeu d’essai :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
insert into Formation values
  (1,1)
, (2,2)
, (3,3)
;
select '' as Formation, * from Formation ;
 
insert into Monstre values
  (1,'m1')
, (2,'m2')
, (3,'m3')
, (4,'m4')
, (5,'m5')
;
select '' as Monstre,* from Monstre ;
 
insert into Agreger values
  (1,1)
, (1,2)
, (1,3)
, (2,1)
, (2,3)
, (2,4)
, (3,2)
, (3,5)
;
select '' as Agreger,* from Agreger ;
 
insert into Frenesie values
  (1,'f1')
, (2,'f2')
, (3,'f3')
, (4,'f4')
, (5,'f5')
;
select '' as Frenesie, * from Frenesie ;
 
insert into Utilisateur values
  (1,'u1')
, (2,'u2')
, (3,'u3')
;
select '' as Utilisateur, * from Utilisateur ;
 
insert into Rencontrer values
  (1,1)
, (1,2)
, (2,1)
, (2,2)
, (2,3)
;
select '' as Rencontrer, * from Rencontrer ;
 
insert into Acquerir values
  (1,1)
, (1,3)
, (2,1)
, (2,4)
, (3,2)
, (1,5) – UFM ne sera pas d’accord
;
select '' as Acquerir, * from Acquerir ;
 
insert into UFM values
  (1,1,1)
, (1,1,3)
;
select '' as UFM, * from UFM ;  -- ok
 
insert into UFM values
  (1,3,5) -- délinquant : l’utilisateur 1 n’a pas rencontré la formation 3
;
select '' as UFM, * from UFM ; -- ko

Le SGBD valide les deux premiers inserts UFM, tandis que 3e le fait tousser :

« L'instruction INSERT est en conflit avec la contrainte FOREIGN KEY "UFM_Rencontrer_fk".
Le conflit s'est produit dans la base de données "deedolith", table "dbo.Rencontrer". »

Quod erat demonstrandum. 

[escartefigue]

Sauf que, tout monstre fait partie d'une formation, ce faisant, par transitivité, tout utilisateur qui rencontre un monstre rencontre aussi la formation de ce monstre, du coup, la contrainte est suffisante

[deedolith]

@escartefigue:
Sauf qu'un monstre peut apparaitre dans plusieurs formations, ce qu'introduit la relation Agrege: 1-n, 1-n.

[deedolith]

Merci pour tout.

Je n'ai plus qu'a faire ingurgiter tout cela à Ms Access (je sent que ca va jazzer).

Dernier point:
Quel est la philosophie derrière les combinaisons de lettre (UA, FC, MF ect ...) ?
Obtenir un nom unique ?

[fsmrel]

Sauf que, tout monstre fait partie d'une formation, ce faisant, par transitivité, tout utilisateur qui rencontre un monstre rencontre aussi la formation de ce monstre, du coup, la contrainte est suffisante

Pour l’anecdote, l’utilisateur qui rencontre un monstre rencontre toutes les formations de ce monstre. Mais ceci n’est-il vraiment qu’un détail ?

Désormais la règle de gestion initiale :

« Un utilisateur peut acquérir une frénésie, à condition qu'elle soit celle d'un monstre présent dans une formation déjà rencontrée. »

Est remplacée par celle-ci, qui n’est pas équivalente :

« Un utilisateur qui acquiert une frénésie doit rencontrer toutes les formations dont fait partie le monstre possesseur de cette frénésie. »

A deedolith de trancher

La philosophie derrière les combinaisons de lettre (UA, FC, MF etc.) ?
Aucune ! Il s’agissait de gagner de la place dans le schéma...

Bon courage avec Access !

[deedolith]

Je confirme: une, et non toutes.
Par exemple, soit 2 formations:
1) Truite des sables, Raie des sables, Raie des sables.
2) Truite des sables, Truite des sables, Truite des sables, Truite des sables, Scorpion, Scorpion.
Si l'utilisateur n'a rencontré que la seconde, cela n'implique pas qu'il a rencontré la première, pourtant la Truite des sables est présente dans les 2.
La frénésie de la Raie des sables doit rester inaccessible.

La philosophie derrière les combinaisons de lettre (UA, FC, MF etc.) ?

Ha ouais ?
Mais du coup, tu m'as perdu loin ... très loin (il y a longtemps dans une galaxie ...)

[fsmrel]

La frénésie de la Raie des sables doit rester inaccessible.

Ce qui implique que la table Rencontrer doit faire référence à la table Formation et non pas à la table Monstre :
 

Code SQL :

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

1
2
3
4
5
6
7
8
create table Rencontrer
(
   UtilisateurId INT,
   FormationId INT,
   PRIMARY KEY(UtilisateurId, FormationId),
   FOREIGN KEY(FormationId) REFERENCES Formation(FormationId),
   FOREIGN KEY(UtilisateurId) REFERENCES Utilisateur(UtilisateurId)
);

 
Et que la table UFM doit faire référence à la table Agreger :
 

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
create table UFM
(
   UtilisateurId INT
,  FormationId INT
,  MonstreId INT
   PRIMARY KEY(UtilisateurId, FormationId, MonstreId)
,  FOREIGN KEY(UtilisateurId, FormationId) REFERENCES Rencontrer(UtilisateurId, FormationId)
,  FOREIGN KEY(FormationId, MonstreId) REFERENCES Agreger(FormationId, MonstreId)
,  FOREIGN KEY(UtilisateurId, MonstreId) REFERENCES Acquerir(UtilisateurId, MonstreId)
);

Cf. en cela les CREATE TABLE dans le post #12.

Do you agree, Tovaritch ?
 
 

tu m'as perdu loin ... très loin

J’en suis navré...

[deedolith]

Yep, on est d'accord.

J’en suis navré...

Maintenant, je me retrouve avec des relations dont le nom ne me dit rien, ce qui ne facilite pas la compréhension.

D'apres ton MCD:
"MF" peut devenir "Posseder" (ce que j'ai dans mon 1er message).
"UFM" peut devenir "Inclure".
Le reste, pour l'instant, je sèche.

[escartefigue]

Une démonstration vaut mieux qu'un discours.

J'ai enrichi un peu mon MCD pour ajouter des attributs en plus des simples identifiants et ajouté l'identification de la frénésie relativement au monstre comme indiqué plus haut.

Ce qui donne le MCD suivant



Le script correspondant décliné pour SQL server est celui-ci, notez la contrainte en fin de script.

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
CREATE TABLE UT_utilisateur(
   UT_ident INT IDENTITY,
   UT_nom VARCHAR(50) NOT NULL,
   PRIMARY KEY(UT_ident)
);
 
CREATE TABLE MO_monstre(
   MO_ident INT IDENTITY,
   MO_nom VARCHAR(50) NOT NULL,
   PRIMARY KEY(MO_ident)
);
 
CREATE TABLE FO_formation(
   FO_ident INT IDENTITY,
   FO_nom VARCHAR(50) NOT NULL,
   PRIMARY KEY(FO_ident)
);
 
CREATE TABLE FR_frenesie(
   MO_ident INT,
   FR_seq SMALLINT,
   FR_nom VARCHAR(50) NOT NULL,
   PRIMARY KEY(MO_ident, FR_seq),
   FOREIGN KEY(MO_ident) REFERENCES MO_monstre(MO_ident)
);
 
CREATE TABLE AQ_acquerir(
   MO_ident INT,
   FR_seq SMALLINT,
   UT_ident INT,
   PRIMARY KEY(MO_ident, FR_seq, UT_ident),
   FOREIGN KEY(MO_ident, FR_seq) REFERENCES FR_frenesie(MO_ident, FR_seq),
   FOREIGN KEY(UT_ident) REFERENCES UT_utilisateur(UT_ident)
);
 
CREATE TABLE RE_rencontrer(
   UT_ident INT,
   MO_ident INT,
   PRIMARY KEY(UT_ident, MO_ident),
   FOREIGN KEY(UT_ident) REFERENCES UT_utilisateur(UT_ident),
   FOREIGN KEY(MO_ident) REFERENCES MO_monstre(MO_ident)
);
 
CREATE TABLE AG_agreger(
   MO_ident INT,
   FO_ident INT,
   PRIMARY KEY(MO_ident, FO_ident),
   FOREIGN KEY(MO_ident) REFERENCES MO_monstre(MO_ident),
   FOREIGN KEY(FO_ident) REFERENCES FO_formation(FO_ident)
);
 
alter table AQ_acquerir
add constraint FK_AQ_AC
foreign key (UT_ident, MO_ident)
references RE_rencontrer (UT_ident, MO_ident);

J'insère ensuite un jeu d'essai de quelques lignes :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
insert into UT_utilisateur (UT_nom)
values ('dupont'), ('martin'), ('abadie')
;
insert into MO_monstre (MO_nom)
values ('raie des sables'), ('truite des sables'), ('scorpion')
;
insert into FO_formation (FO_nom)
values ('FO1'), ('FO2'), ('FO3')
;
insert into FR_frenesie (MO_ident, FR_seq, FR_nom)
values (1, 1, 'FR1'), (2, 1, 'FR2'), (3, 1, 'FR31'), (3, 2, 'FR32')
;
-- création des agrégations
insert into AG_agreger (MO_ident, FO_ident)
values (1, 1), (1, 2), (2, 1), (3, 1), (3, 3)
;
-- création des rencontres
insert into RE_rencontrer (UT_ident, MO_ident)
values (1, 1), (1, 2), (2, 2), (3, 3)
;
-- qui a rencontré quoi
select UTI.UT_nom as joueur
     , MON.MO_nom as monstre
from        UT_utilisateur as UTI
inner join  RE_rencontrer  as REN
   on REN.UT_ident = UTI.UT_ident
inner join  MO_monstre     as MON
   on MON.MO_ident = REN.MO_ident

Puis je réalise des acquisitions de frénésies valides, pas de souci, c'est accepté par SQL server :

Code SQL :

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

1
2
3
4
-- acquisition de frénésies
insert into AQ_acquerir (MO_ident, FR_seq, UT_ident)
values (1, 1, 1), (2, 1, 1)
;

Et enfin, j'essaye d'acquérir une frénésie pour un joueur qui n'a pas rencontré le monstre concerné, là, ça couine

Code SQL :

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

1
2
3
4
-- acquisition invalide : le joueur n'a pas rencontré le monstre qui possède la frénésie
insert into AQ_acquerir (MO_ident, FR_seq, UT_ident)
values (2, 1, 3)
;

Réponse du SGBD :

Msg 547 Level 16 State 0 Line 93
The INSERT statement conflicted with the FOREIGN KEY constraint "FK_AQ_AC". The conflict occurred in database "fiddle_e828546660ab484da435b49044fd19a9", table "dbo.RE_rencontrer".

Vous retrouverez tout le script DB_fiddle ICI


Il n'est donc absolument pas nécessaire que l'utilisateur rencontre toutes les formations d'un monstre ! On répond bel et bien au cahier des charges sans se faire des noeuds au cerveau

EDIT : j'ai oublié de modifier la cardinalité minimale de MO_monstre vers AG_agreger, il faut remplacer le 0 par un 1, mais ça ne change évidemment rien au résultat