Besoin d'aide MCD Equipe de Football

Version imprimable

09/12/2021, 00h10
ZaRToP

1 pièce(s) jointe(s)

Besoin d'aide MCD Equipe de Football

Bonjour,

Je cherche à créer une base de données pour gérer une équipe de football, mais je galère un peu sur certains point, du coup j'aurai besoin de votre aide

Je galère un peu sur la partie Saison / Compétition / rencontre et là intervient mon premier problème, j'aimerai gérer plusieurs compétitions, mais des compétitions différentes :

- L'une est la Ligue 1 par exemple, où il y a 38 journées par saison, avec 10 rencontres par journées
- L'autre est la coupe de france avec plusieurs tours, et plusieurs rencontres par tour

Dans ma précédentes version, j'avais une table compétitions, cette table était lié à une table saison où j'avais plusieurs saison pour une compétition, sauf que j'avais 2 fois la même saison pour 2 compétitons, la même saison revenait plusieurs fois dans la table, et cela me paraissait pas bon.

Voilà ma dernière version : Pièce jointe 609929

Sauf que cela me parait pas du tout approprié.

Est-ce que vous auriez des idées pour améliorer ça ?

Merci d'avance
09/12/2021, 14h24
escartefigue

Bonjour

Commencer par le modèle conceptuel (MCD) est une très bonne chose, mais il faut d'abord établir la liste des "objets de gestion" ou "individus", par exemple les compétitions, les saisons, les joueurs, les catégories, les terrains, etc.
Il faut ensuite énoncer les règles de gestion pour décrire comment ces "objets de gestion" interagissent, c'est ce qui permettra de définir les associations.
Par exemple :
- R001a : une compétition est concernée par plusieurs rencontres
- R001b : une rencontre concerne une et une seule compétition
- R002a : une recontre se déroule sur un seul terrain
- R002b : sur un terrain peuvent se dérouler plusieurs rencontres mais à des dates différentes
etc.
Une fois que c'est fait, on traduit tout ça sous forme de MCD :)
10/12/2021, 22h50
ZaRToP

D'accord, merci de ta réponse, effectivement, je n'ai pas effectué cette étape, je vais aller faire ça, merci :)
11/12/2021, 01h03
ZaRToP

2 pièce(s) jointe(s)

J'ai pu définir les règles suivantes, qui me paraissent pas mal :
- R001a : une compétition dispose de plusieurs saisons
- R001b : une saison peut avoir plusieurs compétitions
- R002a : une saison est composé de plusieurs journées
- R002b : une journée est associé à une seule saison
- R003a : dans une journée se déroule plusieurs rencontre
- R003b : une rencontre est associé à une seule journée

Et du coup je me retrouverai avec quelque chose comme ça :
Pièce jointe 610037

Avec le MLD :
Pièce jointe 610038

Du coup, j'ai dans ma table "composer" une journée, qui est lié à une saison, qui est lié à une compétition, et avec l'id de la journée, je peux récupérer les informations de la journée dans la table journée, ainsi que les rencontres associés, etc...

Cela me parait pas mal, mais tout de même vachement complexe, j'ai l'impression de me compliqué la vie

2 pièce(s) jointe(s)

Bonjour,

il manque beaucoup de choses pour pouvoir modéliser des rencontres de football : les clubs, les joueurs, les terrains, peut-être les arbitres, les entraineurs etc.
ensuite, concernant les règles de gestion, il doit y avoir à minima une règle pour chaque "patte" d'association

ainsi, pour le MCD suivant :

[ENTITE1] ---(asso1)---[ENTITE2]---(asso2)---[ENTITE3]
il y a deux associations, chacune ayant deux "pattes", je dois avoir au moins 4 règles de gestion

Les règles de gestion étant très incomplètes, j'ai établi ci-dessous un MCD d'après les quelques connaissances (très incomplètes) que j'ai du milieu footbalistique :

Pièce jointe 610044

Le MLD correspondant :

Pièce jointe 610045

Et le script (j'ai choisi arbitrairement le SGBD PostGreSQL) :

Code:

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
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
CREATE TABLE CO_competition(
   CO_ident SERIAL,
   CO_nom VARCHAR(50) NOT NULL,
   PRIMARY KEY(CO_ident)
);
 
CREATE TABLE CS_comp_saison(
   CO_ident INTEGER,
   CS_ident SERIAL,
   CS_dtdeb DATE NOT NULL,
   CS_dtfin DATE NOT NULL,
   PRIMARY KEY(CO_ident, CS_ident),
   FOREIGN KEY(CO_ident) REFERENCES CO_competition(CO_ident)
);
 
CREATE TABLE CL_club(
   CL_ident SERIAL,
   CL_nom VARCHAR(50) NOT NULL,
   PRIMARY KEY(CL_ident)
);
 
CREATE TABLE TR_terrain(
   TR_ident SERIAL,
   TR_nom VARCHAR(50) NOT NULL,
   PRIMARY KEY(TR_ident)
);
 
CREATE TABLE PE_personne(
   PE_ident SERIAL,
   PE_nom VARCHAR(50) NOT NULL,
   PE_prenom VARCHAR(50) NOT NULL,
   PE_ddn DATE NOT NULL,
   PRIMARY KEY(PE_ident)
);
 
CREATE TABLE TN_entraineur(
   PE_ident INTEGER,
   TN_agrement CHAR(10) NOT NULL,
   PRIMARY KEY(PE_ident),
   UNIQUE(TN_agrement),
   FOREIGN KEY(PE_ident) REFERENCES PE_personne(PE_ident)
);
 
CREATE TABLE JO_joueur(
   PE_ident INTEGER,
   JO_license CHAR(8) NOT NULL,
   PRIMARY KEY(PE_ident),
   UNIQUE(JO_license),
   FOREIGN KEY(PE_ident) REFERENCES PE_personne(PE_ident)
);
 
CREATE TABLE AR_arbitre(
   PE_ident INTEGER,
   AR_license CHAR(12) NOT NULL,
   PRIMARY KEY(PE_ident),
   UNIQUE(AR_license),
   FOREIGN KEY(PE_ident) REFERENCES PE_personne(PE_ident)
);
 
CREATE TABLE EQ_equipe(
   EQ_ident SERIAL,
   EQ_nom VARCHAR(50) NOT NULL,
   CL_ident INTEGER NOT NULL,
   PRIMARY KEY(EQ_ident),
   FOREIGN KEY(CL_ident) REFERENCES CL_club(CL_ident)
);
 
CREATE TABLE RC_rencontre(
   CO_ident INTEGER,
   CS_ident INTEGER,
   RC_ident SERIAL,
   RC_date DATE,
   TR_ident INTEGER NOT NULL,
   PRIMARY KEY(CO_ident, CS_ident, RC_ident),
   FOREIGN KEY(CO_ident, CS_ident) REFERENCES CS_comp_saison(CO_ident, CS_ident),
   FOREIGN KEY(TR_ident) REFERENCES TR_terrain(TR_ident)
);
 
CREATE TABLE IN_inscrire(
   EQ_ident INTEGER,
   CO_ident INTEGER,
   CS_ident INTEGER,
   PRIMARY KEY(EQ_ident, CO_ident, CS_ident),
   FOREIGN KEY(EQ_ident) REFERENCES EQ_equipe(EQ_ident),
   FOREIGN KEY(CO_ident, CS_ident) REFERENCES CS_comp_saison(CO_ident, CS_ident)
);
 
CREATE TABLE JR_jouer(
   EQ_ident INTEGER,
   CO_ident INTEGER,
   CS_ident INTEGER,
   RC_ident INTEGER,
   JR_score SMALLINT NOT NULL,
   PRIMARY KEY(EQ_ident, CO_ident, CS_ident, RC_ident),
   FOREIGN KEY(EQ_ident) REFERENCES EQ_equipe(EQ_ident),
   FOREIGN KEY(CO_ident, CS_ident, RC_ident) REFERENCES RC_rencontre(CO_ident, CS_ident, RC_ident)
);
 
CREATE TABLE EN_entrainer(
   EQ_ident INTEGER,
   PE_ident INTEGER,
   EN_dtdeb DATE NOT NULL,
   EN_dtfin DATE NOT NULL,
   PRIMARY KEY(EQ_ident, PE_ident),
   FOREIGN KEY(EQ_ident) REFERENCES EQ_equipe(EQ_ident),
   FOREIGN KEY(PE_ident) REFERENCES TN_entraineur(PE_ident)
);
 
CREATE TABLE PA_participer(
   CO_ident INTEGER,
   CS_ident INTEGER,
   RC_ident INTEGER,
   PE_ident INTEGER,
   PA_mindeb SMALLINT NOT NULL,
   PA_minfin SMALLINT NOT NULL,
   PRIMARY KEY(CO_ident, CS_ident, RC_ident, PE_ident),
   FOREIGN KEY(CO_ident, CS_ident, RC_ident) REFERENCES RC_rencontre(CO_ident, CS_ident, RC_ident),
   FOREIGN KEY(PE_ident) REFERENCES JO_joueur(PE_ident)
);
 
CREATE TABLE CT_constituer(
   PE_ident INTEGER,
   CA_date DATE,
   CT_dtfin DATE NOT NULL,
   EQ_ident INTEGER NOT NULL,
   PRIMARY KEY(PE_ident, CA_date),
   FOREIGN KEY(PE_ident) REFERENCES JO_joueur(PE_ident),
   FOREIGN KEY(EQ_ident) REFERENCES EQ_equipe(EQ_ident)
);
 
CREATE TABLE AB_arbitrer(
   CO_ident INTEGER,
   CS_ident INTEGER,
   RC_ident INTEGER,
   PE_ident INTEGER,
   PRIMARY KEY(CO_ident, CS_ident, RC_ident, PE_ident),
   FOREIGN KEY(CO_ident, CS_ident, RC_ident) REFERENCES RC_rencontre(CO_ident, CS_ident, RC_ident),
   FOREIGN KEY(PE_ident) REFERENCES AR_arbitre(PE_ident)
);
 
alter table JR_jouer
add constraint JRFK001
foreign key(EQ_ident, CO_ident, CS_ident)
references IN_inscrire(EQ_ident, CO_ident, CS_ident)
;

28/12/2021, 15h35
ZaRToP

1 pièce(s) jointe(s)

Salut,

Désolé de ne pas avoir répondu plus tôt, j'ai était pas mal occupé ces derniers temps et n'ai pas eu le temps de travailler sur mon petit projet.

Désolé également de ne pas l'avoir précisé avant et de t'avoir fait perdre du temps, mais j'ai déjà fait le reste de la base de données :
Pièce jointe 610899

Evidemment ce n'est pas parfait, je n'ai pas mis tous les champs, et il manque des tables, je vais l'améliorer avec le temps, mais j'avais surtout besoin d'aide sur la partie que j'ai montré plus haut

Merci beaucoup de ton aide
28/12/2021, 16h54
escartefigue

Bonjour,

Quelques remarques rapidement

Le trajet STADE / EQUIPE / RENCONTRE ne va pas

Ce qui est modélisé [STADE] 1,1 ---(jouer dans) --- 0,n [EQUIPE]
1,1 implique que sur un stade, il n'y a qu'une et une seule équipe ! Et ce indépendamment de la date...
0,n implique qu'une équipe peut jouer sur plusieurs stades au même moment...
Il faut reprendre ce que j'ai modélisé dans mon exemple pour voir comment relier ces différentes entité-type : c'est la rencontre qui doit être associée au terrain et non l'équipe.
Attention aussi au fait qu'une rencontre ne se déroule pas toujours sur le terrain d'une des deux équipes, il arrive que ce soit sur un terrain neutre.

Le type d'entité [PARTICIPATION] possède des cardinalités 1,1 sur chacune de ses associations.
C'est symptomatique d'une association convertie en type d'entité, ici je ne vois pas ce que ça apporte.
Dans ma proposition, j'avais mis les attributs heure de début et heure de fin dans l'association (PA_participer), je pense que c'est suffisant.

Votre modèle permet à un joueur de marquer un but dans une rencontre sans y participer et sans faire partie d'une des équipes participant à la rencontre.
Il faut utiliser les Contraintes d'Intégrité Fonctionnelles (CIF) pour éviter ce genre de mésaventures. Cf. le cercle marqué (I) dans mon MCD qui matérialise une CIF de type "inclusion".

Dans votre modèle, on ne peut pas savoir à quelle compétition (championnat, coupe ou autre) se rapporte une rencontre, voyez la différence avec le modèle que j'ai proposé.
28/12/2021, 20h06
ZaRToP

1 pièce(s) jointe(s)

Voilà avec les corrections :

Pièce jointe 610917

Effectivement, j'avais oublié de relier l'entité stade avec l'entité rencontre, c'est beaucoup plus logique comme ça.

Pareil pour l'entité participation, elle était inutile. Utiliser une association ici est beaucoup plus efficace et pratique pour la lisibilité du mcd.

Pour ce qui est de la CIF, je n'en ai jamais utilisé, je suis un peu perdu, je comprend le principe, mais je ne vois pas la différence quand j'en mais une et quand il n'y en a pas. Je l'ai placé entre l'association participer et l'association marquer, mais je ne vois aucune différence. Je m'y prend mal j'imagine :(

Pour l'instant, dans mon MCD, je ne gère pas encore les différentes compétitions car je ne savais pas encore comment faire pour différencier le championnat et les coupes, car l'un dispose de journées, et l'autres de tour (16ème de finale, 8ème de finale, quart de finale, etc...). Si je ne me trompe pas, dans votre MCD, vous ne faites pas la différences entre ces compétitions
29/12/2021, 00h13
Paprick

Bonjour,

Votre contrainte inter-associations d'Inclusion (qui n'est pas vraiment une CIF) doit être ciblée (fléchée) comme le montre le MCD d'Escartefigue.
Quel logiciel de modélisation avez-vous utilisé ? JMerise ?

1 pièce(s) jointe(s)

Comme indiqué dans mon message précédent, le triptyque [SAISON] [JOURNEE] [COMPETITION] ne convient pas

Pour différencier les championnats, coupes et autres types de compétitions, en reprenant mon exemple, il suffit d'ajouter une entité-type
[TYPE-COMPETITION] qui sera en relation avec la compétition comme suit :

[CO_competition] 1,1 --- (typer) --- 0,n [YC_type_competition]

Pour distinguer les journées de championnat et les tours d'une coupe (32e, 16^e etc.), on pourra ajouter une association entre [RENCONTRE] et une nouvelle entité-type [TOUR]

Voici une nouvelle version. J'en ai profité pour corriger une coquille que j'avais laissée dans mon MCD précédent : comme l'entité-type CS est identifiée relativement à CO, l'identifiant de CS ne doit pas être un auto_increment, puisqu'il redémarrera à 0 ou 1 pour chaque CO parent ;)
Même raisonnement pour la rencontre RC, identifiée relativement à RS.
J'en ai également profité pour ajouter les entités-pivot de la contrainte d'inclusion. Décidément j'aurais dû me relire :aie:

Pièce jointe 610954

Ce qui donne le script (cette fois-ci j'ai choisi MySQL puisque j'ai vu que votre modèle comportait des "auto_increment" spécifiques à ce SGBD) :

Code:

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
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
CREATE TABLE YC_type_compet(
   YC_ident INT AUTO_INCREMENT,
   YC_code CHAR(4) NOT NULL,
   YC_lib VARCHAR(128) NOT NULL,
   PRIMARY KEY(YC_ident),
   UNIQUE(YC_code)
);
 
CREATE TABLE TR_terrain(
   TR_ident INT AUTO_INCREMENT,
   TR_nom VARCHAR(50) NOT NULL,
   PRIMARY KEY(TR_ident)
);
 
CREATE TABLE CL_club(
   CL_ident INT AUTO_INCREMENT,
   CL_nom VARCHAR(50) NOT NULL,
   PRIMARY KEY(CL_ident)
);
 
CREATE TABLE EQ_equipe(
   EQ_ident INT AUTO_INCREMENT,
   EQ_nom VARCHAR(50) NOT NULL,
   CL_ident INT NOT NULL,
   PRIMARY KEY(EQ_ident),
   FOREIGN KEY(CL_ident) REFERENCES CL_club(CL_ident)
);
 
CREATE TABLE PE_personne(
   PE_ident INT AUTO_INCREMENT,
   PE_nom VARCHAR(50) NOT NULL,
   PE_prenom VARCHAR(50) NOT NULL,
   PE_ddn DATE NOT NULL,
   PRIMARY KEY(PE_ident)
);
 
CREATE TABLE TN_entraineur(
   PE_ident INT,
   TN_agrement CHAR(10),
   PRIMARY KEY(PE_ident),
   FOREIGN KEY(PE_ident) REFERENCES PE_personne(PE_ident)
);
 
CREATE TABLE JO_joueur(
   PE_ident INT,
   JO_license CHAR(12) NOT NULL,
   PRIMARY KEY(PE_ident),
   UNIQUE(JO_license),
   FOREIGN KEY(PE_ident) REFERENCES PE_personne(PE_ident)
);
 
CREATE TABLE AR_arbitre(
   PE_ident INT,
   AR_license CHAR(8) NOT NULL,
   PRIMARY KEY(PE_ident),
   UNIQUE(AR_license),
   FOREIGN KEY(PE_ident) REFERENCES PE_personne(PE_ident)
);
 
CREATE TABLE CO_competition(
   CO_ident INT AUTO_INCREMENT,
   CO_nom VARCHAR(50) NOT NULL,
   YC_ident INT NOT NULL,
   PRIMARY KEY(CO_ident),
   FOREIGN KEY(YC_ident) REFERENCES YC_type_compet(YC_ident)
);
 
CREATE TABLE CS_comp_saison(
   CO_ident INT,
   CS_ident SMALLINT,
   CS_dtdeb DATE NOT NULL,
   CS_dtfin DATE NOT NULL,
   PRIMARY KEY(CO_ident, CS_ident),
   FOREIGN KEY(CO_ident) REFERENCES CO_competition(CO_ident)
);
 
CREATE TABLE RC_rencontre(
   CO_ident INT,
   CS_ident SMALLINT,
   RC_ident SMALLINT,
   RC_date DATE NOT NULL,
   TR_ident INT NOT NULL,
   PRIMARY KEY(CO_ident, CS_ident, RC_ident),
   FOREIGN KEY(CO_ident, CS_ident) REFERENCES CS_comp_saison(CO_ident, CS_ident),
   FOREIGN KEY(TR_ident) REFERENCES TR_terrain(TR_ident)
);
 
CREATE TABLE TO_tour(
   CO_ident INT,
   CS_ident SMALLINT,
   TO_ident TINYINT,
   TO_dtdeb DATE NOT NULL,
   TO_dtfin DATE NOT NULL,
   PRIMARY KEY(CO_ident, CS_ident, TO_ident),
   FOREIGN KEY(CO_ident, CS_ident) REFERENCES CS_comp_saison(CO_ident, CS_ident)
);
 
CREATE TABLE JR_jouer(
   CO_ident INT,
   CS_ident SMALLINT,
   RC_ident SMALLINT,
   EQ_ident INT,
   JR_score SMALLINT NOT NULL,
   PRIMARY KEY(CO_ident, CS_ident, RC_ident, EQ_ident),
   FOREIGN KEY(CO_ident, CS_ident, RC_ident) REFERENCES RC_rencontre(CO_ident, CS_ident, RC_ident),
   FOREIGN KEY(EQ_ident) REFERENCES EQ_equipe(EQ_ident)
);
 
CREATE TABLE IN_inscrire(
   CO_ident INT,
   CS_ident SMALLINT,
   EQ_ident INT,
   PRIMARY KEY(CO_ident, CS_ident, EQ_ident),
   FOREIGN KEY(CO_ident, CS_ident) REFERENCES CS_comp_saison(CO_ident, CS_ident),
   FOREIGN KEY(EQ_ident) REFERENCES EQ_equipe(EQ_ident)
);
 
CREATE TABLE CT_constituer(
   PE_ident INT,
   CA_date DATE,
   CT_dtfin DATE NOT NULL,
   EQ_ident INT NOT NULL,
   PRIMARY KEY(PE_ident, CA_date),
   FOREIGN KEY(PE_ident) REFERENCES JO_joueur(PE_ident),
   FOREIGN KEY(EQ_ident) REFERENCES EQ_equipe(EQ_ident)
);
 
CREATE TABLE AB_arbitrer(
   CO_ident INT,
   CS_ident SMALLINT,
   RC_ident SMALLINT,
   PE_ident INT,
   PRIMARY KEY(CO_ident, CS_ident, RC_ident, PE_ident),
   FOREIGN KEY(CO_ident, CS_ident, RC_ident) REFERENCES RC_rencontre(CO_ident, CS_ident, RC_ident),
   FOREIGN KEY(PE_ident) REFERENCES AR_arbitre(PE_ident)
);
 
CREATE TABLE PA_participer(
   CO_ident INT,
   CS_ident SMALLINT,
   RC_ident SMALLINT,
   PE_ident INT,
   PA_mindeb SMALLINT NOT NULL,
   PA_minfin SMALLINT NOT NULL,
   PRIMARY KEY(CO_ident, CS_ident, RC_ident, PE_ident),
   FOREIGN KEY(CO_ident, CS_ident, RC_ident) REFERENCES RC_rencontre(CO_ident, CS_ident, RC_ident),
   FOREIGN KEY(PE_ident) REFERENCES JO_joueur(PE_ident)
);
 
alter table JR_jouer
   add constraint JRFK001
   foreign key (CO_ident, CS_ident, EQ_ident)) 
   references IN_inscrire((CO_ident, CS_ident, EQ_ident)
;

On trouve en fin du script la contrainte d'inclusion (et non pas la CIF d'inclusion, merci Paprick :)), codée directement dans la contrainte grâce à la fenêtre ad hoc de looping :)

07/01/2022, 21h59
ZaRToP

Bonjour,

Une fois de plus, désolé du temps de réponse, j'ai été pas mal occupé :(

Citation:

Envoyé par Paprick

Bonjour,

Votre contrainte inter-associations d'Inclusion (qui n'est pas vraiment une CIF) doit être ciblée (fléchée) comme le montre le MCD d'Escartefigue.
Quel logiciel de modélisation avez-vous utilisé ? JMerise ?

Oui c'est bien Jmerise, mais impossible de modéliser correctement une contrainte d'inclusion, j'ai parcouru la doc du logiciel, contacter le support, mais sans réponse, ou alors je m'y suis mal pris, ce qui est fort possible

Citation:

Envoyé par escartefigue

Comme indiqué dans mon message précédent, le triptyque [SAISON] [JOURNEE] [COMPETITION] ne convient pas

Pour différencier les championnats, coupes et autres types de compétitions, en reprenant mon exemple, il suffit d'ajouter une entité-type
[TYPE-COMPETITION] qui sera en relation avec la compétition comme suit :

[CO_competition] 1,1 --- (typer) --- 0,n [YC_type_competition]

Pour distinguer les journées de championnat et les tours d'une coupe (32e, 16^e etc.), on pourra ajouter une association entre [RENCONTRE] et une nouvelle entité-type [TOUR]

Dans votre MCD, je ne comprend pas comment l'entité type_competition et l'entité tour pourront m'aider à différencier les différentes compétitions car si je stock les différents tours d'une coup dans l'entité tour, il faut que je fasse la même pour les journées non ? J'imagine que je suis focalisé sur un truc tout bête, mais je n'arrive pas à comprendre

Grâce à vous, j'ai découvert le logiciel Looping, qui m'a permi de modéliser correctement la contrainte d'inclusion, mais qu'est-ce que la fenêtre d'ad hoc de looping ? J'ai effectué quelques recherches, et c'est lié à Microsoft Access ? Ou alors je ne suis pas du tout
07/01/2022, 22h28
Paprick

Citation:

Envoyé par ZaRToP

Grâce à vous, j'ai découvert le logiciel Looping, qui m'a permi de modéliser correctement la contrainte d'inclusion, mais qu'est-ce que la fenêtre d'ad hoc de looping ? J'ai effectué quelques recherches, et c'est lié à Microsoft Access ? Ou alors je ne suis pas du tout

Bonsoir,
Lorsque vous cliquez sur la contrainte d'inclusion, la fenêtre qui s'ouvre (la fenêtre ad hoc d'escartefigue ;)) vous permet de saisir du code SQL permettant de décrire la contrainte, dans votre cas sous forme d'un ALTER TABLE.
Bonne continuation !
09/01/2022, 23h33
ZaRToP

Bonjour, je comprend mieux maintenant mais pourquoi est-ce que l'on doit coder nous même la contrainte ? Elle n'est pas censé être généré par le logiciel en fonction du mcd ?
10/01/2022, 03h01
Paprick

Bonjour,
Le codage SQL des contraintes varie considérablement en fonction de leur nature, des situations et surtout des SGBD qui n'ont pas les mêmes capacités à gérer TRIGGERS and co.
Une écriture automatique fiable est donc impossible à appréhender correctement.
Seules les CIF font l'objet d'un codage automatique par Looping lors de la création des tables (ce que ne fait pas JMerise, et ce que fait mal Win'Design en cas d'unicité incomplète).
10/01/2022, 08h10
escartefigue

1 pièce(s) jointe(s)

Citation:

Envoyé par ZaRToP

Dans votre MCD, je ne comprend pas comment l'entité type_competition et l'entité tour pourront m'aider à différencier les différentes compétitions car si je stock les différents tours d'une coup dans l'entité tour, il faut que je fasse la même pour les journées non ? J'imagine que je suis focalisé sur un truc tout bête, mais je n'arrive pas à comprendre

YC permet de faire le lien entre une compétition et sa typologie (coupe, championnat, open...)
Certaines compétitions possèdent des tours, dont les dates de début et de fin sont prévues chaque saison, c'est l'objet de TO en lien avec CS
Ensuite, vous pouvez ajouter une association entre la rencontre RC et le tour TO qui vous permettra de savoir quelle rencontre correspond à quel tour.

Ce qui donne :
Pièce jointe 611538

Edit je me suis trompé de cardinalités : il faut 0,1 de RC_rencontre vers TO_tour puisque certaines compétitions n'ont pas de tour ;)
16/01/2022, 23h42
ZaRToP

1 pièce(s) jointe(s)

Citation:

Envoyé par Paprick

Bonjour,
Le codage SQL des contraintes varie considérablement en fonction de leur nature, des situations et surtout des SGBD qui n'ont pas les mêmes capacités à gérer TRIGGERS and co.
Une écriture automatique fiable est donc impossible à appréhender correctement.
Seules les CIF font l'objet d'un codage automatique par Looping lors de la création des tables (ce que ne fait pas JMerise, et ce que fait mal Win'Design en cas d'unicité incomplète).

Bonjour, Je comprend mieux, merci beaucoup pour l'explication

Citation:

Envoyé par escartefigue

YC permet de faire le lien entre une compétition et sa typologie (coupe, championnat, open...)
Certaines compétitions possèdent des tours, dont les dates de début et de fin sont prévues chaque saison, c'est l'objet de TO en lien avec CS
Ensuite, vous pouvez ajouter une association entre la rencontre RC et le tour TO qui vous permettra de savoir quelle rencontre correspond à quel tour.

Ce qui donne :
Pièce jointe 611538

Edit je me suis trompé de cardinalités : il faut 0,1 de RC_rencontre vers TO_tour puisque certaines compétitions n'ont pas de tour ;)

J'ai pas mal galérer pour avoir un code SQL potable, jonglant avec JMerise et Looping (que j'ai découvert grâce à vous, et qui m'a beaucoup aidé), les deux logiciels ayant des avantages que l'autre ne dispose pas.

Quoi qu'il en soit, j'ai quand même pu faire quelque chose de potable, que j'ai testé et qui semble fonctionnait, grâce à vous, j'ai appris des choses et j'ai pu avancer dans ma BDD qui était un peu au ralenti depuis un moment.

Je termine pour le moment avec ça :
Pièce jointe 611928

Dans la dernière version de ton MCD escartefigue, tu as mis un lien relatif au niveau de l'entité rencontre, entre rencontre et saison, je pense que ce n'est pas nécessaire ici, car par exemple, pour deux saisons et deux compétitions, on peut avoir deux fois le même id de rencontre, ce qui n'est pas logique je pense

En tout cas, je pense que le sujet peut être clos, ma question de base étant résolu (et même plus grâce à vous :D) Merci beaucoup
17/01/2022, 00h10
Paprick

Bonsoir,

Citation:

Envoyé par ZaRToP

J'ai pas mal galérer pour avoir un code SQL potable, jonglant avec JMerise et Looping (que j'ai découvert grâce à vous, et qui m'a beaucoup aidé), les deux logiciels ayant des avantages que l'autre ne dispose pas.

Dans le soucis de toujours améliorer Looping, pouvez-vous m'indiquer les avantages que vous avez trouvés à JMerise par rapport à Looping ?
Merci 8-) !
19/01/2022, 08h01
escartefigue

Citation:

Envoyé par ZaRToP

Dans la dernière version de ton MCD escartefigue, tu as mis un lien relatif au niveau de l'entité rencontre, entre rencontre et saison, je pense que ce n'est pas nécessaire ici, car par exemple, pour deux saisons et deux compétitions, on peut avoir deux fois le même id de rencontre, ce qui n'est pas logique je pense

En tout cas, je pense que le sujet peut être clos, ma question de base étant résolu (et même plus grâce à vous :D) Merci beaucoup

Bonjour ZarTop

L'identification relative n'est pas une erreur, ce qui est une erreur, c'est d'avoir typé en "auto_increment" l'identifiant de la rencontre RC_ident
Je commet souvent cette erreur quand un type d'entité est identifié relativement à un autre car je commence par créer l'entité-type faible dans laquelle par habitude je crée l'attribut identifiant de ce type que j'oublie souvent de le corriger ensuite.
Il en va de même pour l'entité-type CS_comp_saison identifiée relativement à CO_compétition, ce faisant CS_ident ne devrait pas être un "auto_increment" ;). Même combat pour TO_ident !
19/01/2022, 08h38
escartefigue

1 pièce(s) jointe(s)

Bizarre : je viens de réouvrir le MCD et ces erreurs d'"auto_increment" à tort n'apparaissent pas dans ma dernière version, de plus, en relisant le fil de discussion, le modèle que j'avais communiqué dans ma réponse n°10 ne présentait pas non plus cette anomalie :weird:
D'ailleurs cette version a perdu les entité pivot de la contrainte, bref, c'est une mauvaise version :aie:

Voici donc le bon MCD avec la coquille de cardinalité corrigée sur la patte allant de [RC] vers [TO]

Pièce jointe 612074