Discussion :

[Batou69]

Je ne comprends rien à ces histoires d'afficheur partageant des codes géo.

Pourriez-vous expliquer concrêtement ce que vous essayez de modéliser ?
Lisez la phrase en bleu de ma signature et appliquez son principe !

J'ai véritablement failli la citer car c'est aussi une phrase que je garde souvent en mémoire. Mais son application n'est pas toujours aisée, même sur des sujets qui paraissent "simples"

Pour les afficheurs : Je modélise une installation de préparation de commandes avec ce que l'on appelle du "pick to light". Si vous ne connaissez pas, en gros on a une armoire avec des cases (les codes géo). Chaque case contient un seul article. Un afficheur est souvent constitué de quelque digits et d'un bouton. Les digits indiquent la quantité que l'opérateur doit prendre dans la case et le bouton sert de validation. Compte tenu du prix des afficheurs et du grand nombre de cases, il est possible de partager un afficheur entre deux cases. Dans ce cas, l'affichage ne peut pas être simultané bien sûr. Il est séquentiel : on indique à l'opérateur de prendre la quantité X dans la case du haut, puis la quantité Y dans la case du bas.

Alors pourquoi ce binz sur le reste ?
Parce qu'il est possible, en plus des afficheurs sur chaque case, de gérer un afficheur par groupe de cases. Cet afficheur sert pour d'autres informations.
Et pour couronner le tout, comme je modélise un logiciel qui s'adapte à tous les cas, je ne veut pas fixer le nombre de niveaux de groupe (je souhaite pouvoir faire des groupes de groupes et ainsi de suite). C'est ce que j'ai appelé ENSEMBLE dans mon modèle. Un ensemble peut aussi avoir un afficheur (mais dans ce cas un seul).

Enfin, une installation de préparation de commandes est vaste, et comporte des tas de systèmes différents présent dans mon modèle. Par exemple des sorties de trieur. Les sorties n'ont rien à voir avec les code géo, mais ont ceci en commun : elles peuvent avoir un afficheur et elles peuvent s’agréger en groupes (avec des niveaux aussi).

Voila, c'est certainement plus clair avec toutes ces explications...

[JeitEmgie]

Là je ne vous suis plus.

# signifie cardinal : regardez votre premier schéma
que votre afficheur soit lié à 1 seul emplacement ou à N peut être modéliser de la même manière, simplement si vous devez distinguer entre les 2 cas au point de les considérer comme 2 classes différentes, vous pouvez le faire via une business rule : il n'est pas nécessaire d'avoir 2 modèles différents (mais vous pouvez le faire si d'autres raisons y poussent).

Et là je suis complètement perdu. En tant que développeur C++, je comprend toutes les notions d'héritage, polymorphisme et autre. Mais je ne vois pas ce que cela vient faire dans la conception de la base.
La plupart de ces notions sont propres à un langage objet je ne sais pas les représenter dans une base de données relationnelle.

c'est vous qui demandez que la solution soit évolutive : si vous mettez des auto_increment dans toutes vos tables, vous ne pourrez pas refactorer pour qu'une table X devienne à son tour une sous-classe de Composant dans le futur : puisqu'il y a aura un conflit sur les PK, par contre une "table sequence" commune fonctionnera (ou des UUIDs).
Faire de la table X une sous-classe de Composant reviendra simplement à ajouter des records Composant pour chaque record de X et une FK de la PK de X vers Composant(no_composant) : soit 2 lignes de SQL.

Et que la base soit relationnelle n'empêche en aucune manière de modéliser des concepts objets ni de les représenter.

[CinePhil]

OK. Essayons de modéliser progressivement., mais vous devriez lire mon billet sur les règles de gestion, ça aiderait beaucoup à la modélisation.

on a une armoire avec des cases (les codes géo). Chaque case contient un seul article.

Une case peut-elle être vide ?
Un article peut-il ne pas être contenu dans une case ?
En attendant, je modélise avec hypothèses ; il faudra éventuellement changer les cardinalités.

MCD 1 :
code_geo -1,1----contenir----1,n- article

Compte tenu du prix des afficheurs et du grand nombre de cases, il est possible de partager un afficheur entre deux cases.

Au plus deux cases ou bien un afficheur peut-il être partagé entre n>2 cases ?
Une case peut-elle avoir plusieurs afficheurs ? J'ai l'impression que non.

MCD 2 :
afficheur -1,n----partager----1,1- code_geo

Alors pourquoi ce binz sur le reste ?
Parce qu'il est possible, en plus des afficheurs sur chaque case, de gérer un afficheur par groupe de cases. Cet afficheur sert pour d'autres informations.

Les groupes de cases sont-il des ensembles définis ? Immuables ?
une case peut-elle être dans plusieurs groupes ?
Peut-on considérer qu'il existe des afficheurs de type "case" et des afficheurs de type "groupe" puisque les informations affichées sont différentes ?
Un afficheur de groupe peut-il être partagé entre plusieurs groupes ?

On pourrait alors avoir cette structure pour les groupes :
MCD 3 :
code_geo -0,1----constituer----1,n- groupe

Et un héritage pour les afficheurs.
MCD 4 :
aff_case -(1,1)----être----0,1- afficheur
aff_groupe -(1,1)----être----0,1---|



Du coup, on modifie le MCD 2 de la façon suivante :
MCD 2 bis :
aff_case -1,n----partager----1,1- code_geo

puis on associe aff_groupe à groupe :
MCD 5 :
aff_groupe -1,n----affecter----1,1- groupe

Et pour couronner le tout, comme je modélise un logiciel qui s'adapte à tous les cas, je ne veut pas fixer le nombre de niveaux de groupe (je souhaite pouvoir faire des groupes de groupes et ainsi de suite).

Donc une modélisation d'arbre intervallaire semble en effet judicieuse. Si un groupe ne peut-être inclu que dans un seul groupe de niveau immédiatement supérieur.

MCD 6 :
groupe -0,n--(père)--comprendre
|------------0,1--(fils)-----------|

Les sorties n'ont rien à voir avec les code géo, mais ont ceci en commun : elles peuvent avoir un afficheur

Peut-on considérer alors que nous avons un troisième type d'afficheur ?

MCD 4 bis :
aff_case -(1,1)----être----0,1- afficheur
aff_groupe -(1,1)----être----0,1---|
aff_sortie -(1,1)----être----0,1-----|

Plusieurs sorties peuvent-elles partager le même afficheur ?
MCD 7 :
sortie -0,1----avoir----1,n- aff_sortie

et elles peuvent s’agréger en groupes (avec des niveaux aussi).

Je suppose que les groupes pour les cases sont différents des groupes pour les sorties ? Un groupe X ne peut pas comprendre à la fois des cases et des sorties ?
Auquel cas il y aurait un nouvel arbre intervallaire et une spécialisation des groupes. En supposant que les deux types de groupes aient des propriétés communes, on fait un nouvel héritage :

MCD 8 :
groupe_case (1,1)----être----0,1- groupe
groupe_sortie -(1,1)----être----0,1---|

Ce qui nous amène à modifier le MCD 3, le MCD 5 et le MCD 6.
MCD 3 bis :
code_geo -0,1----constituer----1,n- groupe_case

MCD 5 bis :
aff_groupe -1,n----affecter----1,1- groupe_case

MCD 6 bis :
groupe_case -0,n--(père)--comprendre
|------------0,1--(fils)-------------------|

On modélise l'arborescence des groupes de sorties comme dans le MCD 6 bis.
MCD 9 :
groupe_sortie -0,n--(père)--comprendre
|------------0,1--(fils)-------------------|


Je crois que je suis arrivé au bout de vos explications.
J'ai dessiné le MCD complet à la main, ça me semble cohérent.

Vous pouvez faire de même avec un logiciel de modélisation et nous proposer le résultat.

[Batou69]

OK. Essayons de modéliser progressivement., mais vous devriez lire mon billet sur les règles de gestion, ça aiderait beaucoup à la modélisation.

Je n'avais pas encore vu celui là. Je vais le lire avec attention.

Une case peut-elle être vide ?
Un article peut-il ne pas être contenu dans une case ?

Oui
et Oui

Au plus deux cases ou bien un afficheur peut-il être partagé entre n>2 cases ?

Je ne vois pas de cas où un afficheur serait partagé entre plus de deux cases. Donc ma réponse est non.
A noter que dans le modèle actuel nous utilisons une "astuce".
Lorsqu'un afficheur est sur deux code géo, alors on duplique la ligne dans la table afficheur pour obtenir ue liaison 1-1 (1 afficheur=1 code géo)

Une case peut-elle avoir plusieurs afficheurs ? J'ai l'impression que non.

Non

Les groupes de cases sont-il des ensembles définis ? Immuables ?

Non. Les groupes de cases font partie de la configuration du logiciel qui n'est pas censée être modifiée. Mais entre deux configurations, tout peut changer.

une case peut-elle être dans plusieurs groupes ?

Non. Sauf qu'une case peut être dans un groupe A lui même dans un autre groupe AA. Donc par transitivité, la case est membre de A et AA, mais indirectement.
Chaque groupe pouvant avoir un afficheur.

Peut-on considérer qu'il existe des afficheurs de type "case" et des afficheurs de type "groupe" puisque les informations affichées sont différentes ?

Les afficheurs ont un type. Ce type décrit l'aspect physique de chaque afficheur (combien de boutons, nombre de digits, couleur des leds etc...)

Nous voulons avoir : tous les code géo du groupe G1 on des afficheurs du type A1. Les codes géo du groupe G2 sont du type A2. Le groupe G1 possède lui aussi un afficheur mais de type A3. Le groupe G2 n'a pas d'afficheur.

Un afficheur de groupe peut-il être partagé entre plusieurs groupes ?

Non, dans ce cas j'ai prévu de créer un groupe avec les n groupes sur lequel je rattache l'afficheur.

Plusieurs sorties peuvent-elles partager le même afficheur ?

Oui pourquoi pas, comme les code géo.

Je suppose que les groupes pour les cases sont différents des groupes pour les sorties ? Un groupe X ne peut pas comprendre à la fois des cases et des sorties ?

Oui et oui. Au début j'avais fait deux entités. Mais compte tenu de mes lecture ici et là, je me demande s'il n'est pas plus judicieux de n'en faire qu'une. Cette "pratique" est très fréquente dans mon modèle : deux entités "presque" pareilles sont souvent dans deux tables différentes par habitude, commodité, méconnaissance etc..

Je crois que je suis arrivé au bout de vos explications.
J'ai dessiné le MCD complet à la main, ça me semble cohérent.

Vous pouvez faire de même avec un logiciel de modélisation et nous proposer le résultat.

Ok, il va me falloir du temps pour comprendre ce que vous avez fait.
Mais dores et déjà un grand merci pour votre aide précieuse !

[CinePhil]

Quelques points, rapidement...

1) Case vide et article pas dans case.
Les cardinalités sont à changer sur le MCD 1.
MCD 1 :
code_geo -0,1----contenir----0,n- article

2)

Je ne vois pas de cas où un afficheur serait partagé entre plus de deux cases. Donc ma réponse est non.

Au niveau MCD, ça ne change pas grand chose.
MCD 2 bis :
aff_case -1,2----partager----1,1- code_geo
Par contre, en toute rigueur, ça a des conséquences sur le développement de la BDD pour assurer la contrainte maxi 2 codes geo pour une aff_case.

A noter que dans le modèle actuel nous utilisons une "astuce".
Lorsqu'un afficheur est sur deux code géo, alors on duplique la ligne dans la table afficheur pour obtenir ue liaison 1-1 (1 afficheur=1 code géo)

3)

Non. Sauf qu'une case peut être dans un groupe A lui même dans un autre groupe AA. Donc par transitivité, la case est membre de A et AA, mais indirectement.
Chaque groupe pouvant avoir un afficheur.

Je pense que la modélisation par arbre intervallaire permet de prendre en compte cette règle naturellement.

4)

Les afficheurs ont un type. Ce type décrit l'aspect physique de chaque afficheur (combien de boutons, nombre de digits, couleur des leds etc...)

Le typage que j'ai défini dans mon précédent message est plus un typage sémantique ou conceptuel qu'un typage technologique. Vérifiez si les deux correspondent, c'est à dire si tous les aff_case sont du même type technologique. Idem pour tous les aff_groupe et tous les aff_sortie.
Si ce n'est pas le cas, il peut être utile de typer les afficheurs au niveau de l'entité type afficheur ou de faire de nouveau un héritage des différents types technologiques d'afficheurs qui se superpose à l'héritage des types conceptuels d'afficheurs.
Il faudrait plus de précisions pour développer ce point qui peut, ou pas, être délicat.

5)

Cette "pratique" est très fréquente dans mon modèle : deux entités "presque" pareilles sont souvent dans deux tables différentes par habitude, commodité, méconnaissance etc..

Deux entités types peuvent être presque pareilles parce qu'elles sont deux aspects d'une même chose. On pratique alors un héritage de données, appelé aussi généralisation/spécialisation.
On met alors les propriétés communes dans l'entité type mère et les propriétés spécifiques dans les entités types filles.

Elles peuvent aussi se ressembler mais concerner deux choses totalement différentes. Par exemple, plusieurs entités type de référence peuvent avoir une structure similaire du type identifiant + libellé. Mais il ne viendrait à personne l'idée de mélanger dans une seule entité type des catégories et des couleurs par exemple.

Bon courage !

[Batou69]

J'ai commencé à modéliser cela sur poweramc et j'ai quelques questions concernant les associations :

MCD 5 bis :
aff_groupe -1,n----affecter----1,1- groupe_case

MCD 6 bis :
groupe_case -0,n--(père)--comprendre
|------------0,1--(fils)-------------------|

On modélise l'arborescence des groupes de sorties comme dans le MCD 6 bis.
MCD 9 :
groupe_sortie -0,n--(père)--comprendre
|------------0,1--(fils)-------------------|

1 La modélisation de l'arborescence est effectuée dans chaque entité héritée de groupe. Est il possible de le faire au niveau groupe, l'héritage faisant le reste ?

2 - Sur le MCD 5 on affecte un aff_groupe à groupe_case. Mais n'est il pas plus simple de l'affecter à un groupe tout court ?

Merci

[CinePhil]

1 La modélisation de l'arborescence est effectuée dans chaque entité héritée de groupe. Est il possible de le faire au niveau groupe, l'héritage faisant le reste ?

Je pense que oui mais alors tu n'auras qu'un seul arbre pour les groupes case et les groupes sortie. Je ne sais pas si ça peut te convenir.
Fait un essai sur papier avec quelques données concrètes en dessinant l'arbre comme dans l'article de SQLPro.

2 - Sur le MCD 5 on affecte un aff_groupe à groupe_case. Mais n'est il pas plus simple de l'affecter à un groupe tout court ?

Je reprends le MCD :

MCD 5 bis :
aff_groupe -1,n----affecter----1,1- groupe_case

cela correspond à la règle de gestion suivante :
Un afficheur de groupe est affecté à un à plusieurs groupes de cases et un groupe de cases se voit affecter un seul afficheur de groupe.

Si on fait ceci :
aff_groupe -1,n----affecter----1,1- groupe

Alors l'afficheur de groupe peu aussi être affecté à un groupe de sortie. Est-ce cohérent ?

[Batou69]

Je pense que oui mais alors tu n'auras qu'un seul arbre pour les groupes case et les groupes sortie. Je ne sais pas si ça peut te convenir.

En effet ce n'est pas ce que je cherche.

Je reprends le MCD :

cela correspond à la règle de gestion suivante :
Un afficheur de groupe est affecté à un à plusieurs groupes de cases et un groupe de cases se voit affecter un seul afficheur de groupe.

Si on fait ceci :
aff_groupe -1,n----affecter----1,1- groupe

Alors l'afficheur de groupe peu aussi être affecté à un groupe de sortie. Est-ce cohérent ?

En théorie, oui c'est possible si j'ai bien compris ce qu'est un afficheur de groupe.
J'ai la règle suivante : Un groupe de cases ou un groupe de sorties peuvent avoir un afficheur.

J'ai fait ce schéma :


Nous ne modélisons jamais avec du mcd, toujours avec du mpd (industries inside).
Ne soyez pas trop sévères !

[CinePhil]

En théorie, oui c'est possible si j'ai bien compris ce qu'est un afficheur de groupe.

Ce n'est pas nous qui pourrons te contredire sur ce point, c'est ton domaine. À toi de demander des précisions à ton donneur d'ordre.

J'ai la règle suivante : Un groupe de cases ou un groupe de sorties peuvent avoir un afficheur.

Règle mal formulée !
La présence du "ou" rend la règle ambigüe car la phrase peut être interprétée de deux manières :
1) Un groupe de cases peut avoir un afficheur ; un groupe de sorties peut avoir un afficheur.
2) Un groupe de cases et de sorties peut avoir un afficheur.

Donc la question posée suite à la modification du MCD que tu veux opérer n'est pas résolue :

l'afficheur de groupe peut aussi être affecté à un groupe de sortie. Est-ce cohérent ?

Passons au MCD, même si je n'ai pas mon brouillon sous les yeux...
Dans l'ensemble cela me paraît correct, à un détail prêt :
Groupe_Sortie -0,n----contenir----0,n- Sortie

Traduction :
Un groupe de sorties peut contenir plusieurs sorties et une sortie peut être contenue dans plusieurs groupes de sorties.

Est-ce exact ? Un groupe de sortie peut être vide ? Une sortie peut être dans plusieurs groupes ?

Nous ne modélisons jamais avec du mcd, toujours avec du mpd (industries inside).

Autrement dit, vous fabriquez avant de concevoir !
Heureusement qu'Airbus ou Alstom ne font pas comme ça !

[Batou69]

Ce n'est pas nous qui pourrons te contredire sur ce point, c'est ton domaine. À toi de demander des précisions à ton donneur d'ordre.

He bien, le donneur d'ordre, c'est moi .

C'est un projet de RetD où je rédige le cahier des charges selon mon expérience, je fais la conception et comme je suis bien parti, je code aussi. (mais nous ne sommes que 4 dev et 2 cp dans la boite!).

Ce que je voulais dire, c'est que si j'ai bien compris, un aff_groupe représente un afficheur attaché à un groupe, quel qu'il soit.

Règle mal formulée !
La présence du "ou" rend la règle ambigüe car la phrase peut être interprétée de deux manières :
1) Un groupe de cases peut avoir un afficheur ; un groupe de sorties peut avoir un afficheur.
2) Un groupe de cases et de sorties peut avoir un afficheur.

Réponse 1.

Passons au MCD, même si je n'ai pas mon brouillon sous les yeux...
Dans l'ensemble cela me paraît correct, à un détail prêt :
Groupe_Sortie -0,n----contenir----0,n- Sortie

Traduction :
Un groupe de sorties peut contenir plusieurs sorties et une sortie peut être contenue dans plusieurs groupes de sorties.

Est-ce exact ? Un groupe de sortie peut être vide ? Une sortie peut être dans plusieurs groupes ?

Oui j'ai vu le problème de cardinalité après avoir posté.
J'ai également modifié la cardinalité aff_groupe affecté à groupe. J'ai la règle suivante :
Un afficheur groupe est être affecté à un et un seul groupe
Un groupe peut avoir un seul afficheur ....ou pas.

Cela donne :

Autrement dit, vous fabriquez avant de concevoir !
Heureusement qu'Airbus ou Alstom ne font pas comme ça !

[HS]
Disons que nous sommes 80 dans la boite, que nous faisions principalement que de la mécanique et qu'un base de données chez nous, quand une table dépasse 10000 lignes, c'est déjà le Pérou. Alors non, Airbus et Alstom ne font pas comme nous, mais ils n'ont pas non plus la même force de frappe !

Ajoutez a cela une hiérarchie qui ne comprend pas grand chose à l’intérêt de modéliser correctement, secouez tout cela et on obtient 15 ans de projets fonctionnellement très proches mais sans jamais avoir deux bases de données qui se ressemblent (même de très loin).

Pour vous donner un ordre d'idée ,je suis actuellement en train de me battre pour ne plus mettre des dates de nature différente par colonnes dans les tables mais plutôt faire une table de dates avec un type (jusqu'ici à chaque nouvelle date, on ajoute une colonne)

C'est d'ailleurs mon propos ici : apprendre à faire au moins mieux, établir des bonnes pratiques et construire des fondations solides pour notre produit.
Et je vous remercie d'y contribuer activement !
[/HS]

[CinePhil]

Le MCD me semble pas mal.

Je me demande juste si le modèle que j'ai donné pour la hiérarchie des groupes es t compatible avec la modélisation en arbre intervallaire. À tester.

[HS]
Disons que nous sommes 80 dans la boite, que nous faisions principalement que de la mécanique et qu'un base de données chez nous, quand une table dépasse 10000 lignes, c'est déjà le Pérou. Alors non, Airbus et Alstom ne font pas comme nous, mais ils n'ont pas non plus la même force de frappe !

Ajoutez a cela une hiérarchie qui ne comprend pas grand chose à l’intérêt de modéliser correctement, secouez tout cela et on obtient 15 ans de projets fonctionnellement très proches mais sans jamais avoir deux bases de données qui se ressemblent (même de très loin).

Si vous fabriquez des pièces mécaniques, vous avez bien des plans non ? Et si ces plans vous sont donnés par vos clients, peut-être avez-vous un bureau d'études interne qui les vérifie et qui établi des procédés de fabrication compatibles avec vos machines ?

Pour vous donner un ordre d'idée ,je suis actuellement en train de me battre pour ne plus mettre des dates de nature différente par colonnes dans les tables mais plutôt faire une table de dates avec un type (jusqu'ici à chaque nouvelle date, on ajoute une colonne)

Mettre des colonnes de dates dans les tables n'est pas du tout incohérent ! Au contraire, c'est même le plus souvent ce qu'il faut faire, même si on modélise une entité type (alors fictive) "Date".
Les seuls cas où on a vraiment besoin de créer un calendrier de dates, c'est quand on gère des notions de planning ou de statistiques par jour/semaine/mois/année... car les tables de données ne couvrent pas obligatoirement toutes les dates possibles.
Il y a aussi le cas des dates partielles qui s'évère délicat mais c'est un autre sujet auquel je suis confronté pour un projet personnel actuellement en sommeil.

C'est d'ailleurs mon propos ici : apprendre à faire au moins mieux, établir des bonnes pratiques et construire des fondations solides pour notre produit.

Et bien le MCD, c'est un peu les fondation de la BDD. S'il n'est pas assez solide, la BDD peut s'écrouler lors de la montée en charge.

[Batou69]

Si vous fabriquez des pièces mécaniques, vous avez bien des plans non ? Et si ces plans vous sont donnés par vos clients, peut-être avez-vous un bureau d'études interne qui les vérifie et qui établi des procédés de fabrication compatibles avec vos machines ?

En effet..

Mettre des colonnes de dates dans les tables n'est pas du tout incohérent ! Au contraire, c'est même le plus souvent ce qu'il faut faire, même si on modélise une entité type (alors fictive) "Date".
Les seuls cas où on a vraiment besoin de créer un calendrier de dates, c'est quand on gère des notions de planning ou de statistiques par jour/semaine/mois/année... car les tables de données ne couvrent pas obligatoirement toutes les dates possibles.

L'exemple que j'ai en tête est celui d'une série d'évènements qui surviennent sur un colis. Le plus facile, immédiat et le plus crade est de mettre une colonne de date par évènement (des fois c'est même juste un bit). Si bien que le jour où un évènement non prévu au départ doit être ajouté, il faut modifier la structure, et casser une partie du code source ! (sans compter que faire des stats entre des évènements dans des colonnes, bonjour la partie de plaisir !).
J'utilise donc maintenant une table d'évènements datés et typés.

Il y a aussi le cas des dates partielles qui s'évère délicat mais c'est un autre sujet auquel je suis confronté pour un projet personnel actuellement en sommeil.

Je vais regarder cela de près.

Et bien le MCD, c'est un peu les fondation de la BDD. S'il n'est pas assez solide, la BDD peut s'écrouler lors de la montée en charge.

En reparlant du MCD, un truc m'échappe :
L'entité aff_groupe et aff_sortie sont des afficheurs. Il ne possèdent pas d'attributs eux même. Lors du passage au MPD, la table générée est donc simplement constituée de la clef de la table afficheur.

Dans ces conditions, quel est l'intérêt de ces deux tables ?

[CinePhil]

L'exemple que j'ai en tête est celui d'une série d'évènements qui surviennent sur un colis. Le plus facile, immédiat et le plus crade est de mettre une colonne de date par évènement (des fois c'est même juste un bit). Si bien que le jour où un évènement non prévu au départ doit être ajouté, il faut modifier la structure, et casser une partie du code source ! (sans compter que faire des stats entre des évènements dans des colonnes, bonjour la partie de plaisir !).
J'utilise donc maintenant une table d'évènements datés et typés.

OK. Ce n'est pas comme ça que j'avais compris ton précédent texte !
Effectivement, il faut modéliser les événements qui contiennent entre autres une propriété "date de l'évéenement".

En reparlant du MCD, un truc m'échappe :
L'entité aff_groupe et aff_sortie sont des afficheurs. Il ne possèdent pas d'attributs eux même. Lors du passage au MPD, la table générée est donc simplement constituée de la clef de la table afficheur.

Dans ces conditions, quel est l'intérêt de ces deux tables ?

Tout simplement d'avoir chacune des associations avec des tables différentes.
Reprends le cheminement de la réflexion qui a conduit à la création de ces entités types filles et tu comprendras l'utilité de ces tables.

[Batou69]

Tout simplement d'avoir chacune des associations avec des tables différentes.
Reprends le cheminement de la réflexion qui a conduit à la création de ces entités types filles et tu comprendras l'utilité de ces tables.

Ok, je comprends mieux maintenant. (désolé pour le délai, retour de vacances au ski )

Je crois que j'ai résolu mon problème. Je tiens à remercier tous les participants et particulièrement Cinephil pour leur aide !