Validation de mon MCD

Bonjour aux professionnels,
Je viens vers vous pour la validation du MCD de mon projet.
En fait, je veux developper une application de gestion d'une association.
Voici mes règles de gestion:

1) Membre-Adhesion
Un Membre paie 1,N fois un droit d'adhésion.
Un adhesion est payée par 1,1 Membre.

2) Membre-Categorie
UnMembre appartient à 1,1 catégorie
Une catégorie renferme 1,n Membre

3) Membre-Paiement-Cotisation
Un Membre effectue 1,n Paiement pour une cotisation donnée.
Une cotisation peut être l'objet de 1,n paiement de 1,1 même Membre donné.

4) Membre-Paiement-Evenement
Un Membre fait 1,n Paiement pour 1,1 Evenement donné.
Un Evenement peut enregistrer 1,n Paiement d'1,1 même membre donné.

5) Membre-Type_paiement
Un Paiement possède 1,1 Type_paiement.
Un Type_paiement appartient à 1,n Paiement.
Ici Type_paiement à seulement 2 valeurs ("Partiel" pour les paiements partiels des membres et "Totalite" pour les paiements au comptant, donc j'ai 2 choix:

1er choix: - Metrre les deux types de paiements dans des options de select (<select><option>Partiel</option><option>Totalite</option></select> dans la table "Paiements".

2ème choix: Créer une table à part pour les types de paiements "Type_paiement" (type_paiement(id INTEGER, partiel VARCHAR, totalite VARCAHR).
Je ne sais pas lequel des choix me sera favorable, aux experts de m'en dire plus...

6) Montant-Paiement
Un montant est lié à 1,n Paiement.
Un Paiement est lié à 1,1 Montant.

7) Categorie-Membre-Paiement-Montant
Une Categorie doit (1,1) Montant pour (1) Paiement donné.
Un Montant est dû par (1,n) Categorie pendant (1,1) même Paiement. Du fait que 2 categories différentes peuvent payer le même montant pour un paiement d'une cotisation lamda.
Cela pourrait se traduire par:
Un Membre doit (1,1) Montant pour (1) Paiement donné et pour (1) evenement ou pour (1) cotisation donné en fonction de sa "Categorie".
Un Montant est dû par (1,n) Membre d'une même "Categorie" pour (1) "evenement" ou pour (1) "Cotisation" fesant objet d'(1) Paiement.

En effet, c'est là que j'ai vraiment un soucis de cohérence, car la table "Categorie" est liée à la table "Membre" qui elle est liée au "Paiement", tandis que la table "Paiement" est liée à la table "Montant" et la table "Montant" est encore liée à la table "Categorie". Il ya donc une fermeture dans la relation [categorie-Membre-Paiement-Montant], pourtant je pense qu'il ya une règle de MERISE qui dit qu'il ne doit pas avoir de fermeture entre les relations...sauf si je me trompe. Voir MCD.

Ce qui m'emmène à vouloir créer cette fermeture de relation, c'est le fait que j'ai retiré la colonne "Montant" de la table "Cotisation" et aussi de la table "Evenement" pour vouloir en faire une table, car chaque Evenement de l'association a un montant qui est fonction de la "Categorie" des "Membres", et, le "Montant" de la "Cotisation" est aussi fonction de la "Categorie" du "Membre". Ce qui veut dire qu'il ya des membres qui payent des "Montant" supérieurs à d'autres Membres en fonction de leur categorie, pour les evenements et aussi pour les cotisations.
J'ai donc besoin d'une bonne solution pour la règle 7.

8) Que pouvez-vous me dire aussi sur la table Adhesion? Doit-elle être reliée directement au "Membre" ou à la table "Paiement" comme Cotisation et Evenement?

Je joints le MCD à mes règles de gestion pour que vous puissiez l'analyser minutieusement.

Pièce jointe 413783
Encore merci pour la reflexion!

Bonjour,

Citation:

---

Envoyé par Busima

Je viens vers vous pour la validation du MCD de mon projet.

---

En l'occurrence, votre schéma est un MLD, nous sommes au niveau tabulaire.

Citation:

---

Envoyé par Busima

En fait, je veux developper une application de gestion d'une association.
Voici mes règles de gestion:

---

C'est une excellente chose d'avoir pensé aux règles de gestion, mais il manque des explications sur le contexte, il faut planter un peu le décor et définir le vocabulaire.

Qu'est ce qu'une catégorie, qu'est-ce qui fait qu'un membre est rattaché à telle ou telle catégorie ?
Pourquoi certains membres payent plusieurs adhésions (ce que d'ailleurs la table adhésion en l'état ne permet pas, il faudrait un identifiant d'adhésion pour le permettre) ?
Quelle différence entre adhésion et cotisation ?
Qu'est-ce qu'un événement ?


Libellé ainsi, ce genre de règle est peu compréhensible, voire pas du tout !

Citation:

---

Envoyé par Busima

7) Categorie-Membre-Paiement-Montant
Une Categorie doit (1,1) Montant pour (1) Paiement donné.
Un Montant est dû par (1,n) Categorie pendant (1,1) même Paiement. Du fait que 2 categories différentes peuvent payer le même montant pour un paiement d'une cotisation lamda.
Cela pourrait se traduire par:
Un Membre doit (1,1) Montant pour (1) Paiement donné et pour (1) evenement ou pour (1) cotisation donné en fonction de sa "Categorie".
Un Montant est dû par (1,n) Membre d'une même "Categorie" pour (1) "evenement" ou pour (1) "Cotisation" fesant objet d'(1) Paiement.

---

Remplacez ce type de formulation par une expression fonctionnelle, en français
Par exemple :

Une Categorie doit (1,1) Montant pour (1) Paiement donné.

veut peut être dire

A chaque catégorie est associée un et un seul montant

Bonjour,

Citation:

---

En l'occurrence, votre schéma est un MLD, nous sommes au niveau tabulaire.

---

Oui, je l'ai fait exprès pour que vous compreniez mieux et rapidement sans voir le MLD.

Citation:

---

C'est une excellente chose d'avoir pensé aux règles de gestion, mais il manque des explications sur le contexte, il faut planter un peu le décor et définir le vocabulaire.

Qu'est ce qu'une catégorie, qu'est-ce qui fait qu'un membre est rattaché à telle ou telle catégorie ?

---

==>Une catégorie est la différence entre les membres (catégorie "Doyen", catégorie "Cadet", catégorie "junior" ...) par exemple. Donc chaque membre est forcement rattaché à une catégorie.

Citation:

---

Pourquoi certains membres payent plusieurs adhésions (ce que d'ailleurs la table adhésion en l'état ne permet pas, il faudrait un identifiant d'adhésion pour le permettre) ?

---

==>Merci pour le rappel sur le "id" de la table "adhésion", je l'avais oublié. Certains membres payent plusieurs adhésions parce que certains membres peuvent payer l'adhésion et quitter l'association après quelques temps, ensuite revenir encore après pour adhérer. Ils doivent donc payer à nouveau l'adhésion pour redevenir membre. Je vois là une colonne "statut" à 2 valeurs "actif" si le membre paye régulièrement les cotisations, "inactif" s'il cesse le paiement des cotisations.

Citation:

---

Quelle différence entre adhésion et cotisation ?
Qu'est-ce qu'un événement ?

---

==> Différence entre adhésion, cotisation et evenement:
adhésion est la somme que paye une personne pour devenir membre, tandis que cotisation est la contribution des membres pour faire fonctionner l'association( le paiement de la cotisation est périodique alors que le paiement de l'adhésion peut se faire une seule fois). A la différence de cotisation, evenement est un peu comme cotisation, cependant il n'est pas périodique car son paiement se fait lors d'un événement (soit pour le mariage ou anniversaire d'un membre...).

Citation:

---

Libellé ainsi, ce genre de règle est peu compréhensible, voire pas du tout !

Remplacez ce type de formulation par une expression fonctionnelle, en français
Par exemple :

Une Categorie doit (1,1) Montant pour (1) Paiement donné.

veut peut être dire

A chaque catégorie est associée un et un seul montant

---

Qu'est-ce que vous voyez ici comme cardinalité, puisque la table "adhesion" est rattachée à la table "paiement" et mérite un "montant" à payer, ensuite la table "cotisation" est aussi rattachée au paiement tout comme la table "evenement", et, toutes ces tables méritent un montant à payer. D’où la création de la table "montant". Est-ce que vous trouvez cette réflexion juste de ma part?

Bonjour,

Citation:

---

Envoyé par Busima

Bonjour,

Citation:

---

Envoyé par escartefigue

En l'occurrence, votre schéma est un MLD, nous sommes au niveau tabulaire.

---

Oui, je l'ai fait exprès pour que vous compreniez mieux et rapidement sans voir le MLD.

---

Utilisez le bouton "répondre avec citation" puis copiez-collez les balises de début (quote=...) et de fin de citation (/quote) pour découper les différentes parties qui vous intéressent ;)
Je suppose que vous vouliez dire "sans voir le MCD"
Or le MCD est justement la traduction en schéma des règles de gestion, il est donc préférable à ce stade de schématiser le MCD plutôt que directement le MLD

Citation:

---

Envoyé par Busima

Qu'est ce qu'une catégorie, qu'est-ce qui fait qu'un membre est rattaché à telle ou telle catégorie ?
==>Une catégorie est la différence entre les membres (catégorie "Doyen", catégorie "Cadet", catégorie "junior" ...) par exemple. Donc chaque membre est forcement rattaché à une catégorie.

---

C'est donc une conséquence directe de l'âge. Stocker la catégorie serait une erreur, ce serait un risque d'incohérence avec l'âge.
Vous pouvez la déduire de la date de naissance, dont vous déduirez l'âge (que vous ne stockerez pas non plus pour la même raison).
Bien évidemment, il ne faut donc plus identifier le membre relativement à la catégorie

Citation:

---

Envoyé par Busima

==>Merci pour le rappel sur le "id" de la table "adhésion", je l'avais oublié. Certains membres payent plusieurs adhésions parce que certains membres peuvent payer l'adhésion et quitter
l'association après quelques temps, ensuite revenir encore après pour adhérer. Ils doivent donc payer à nouveau l'adhésion pour redevenir membre. Je vois là une colonne "statut" à 2 valeurs
"actif" si le membre paye régulièrement les cotisations, "inactif" s'il cesse le paiement des cotisations.

---

Si la durée de validité d'une adhésion est invariante (un an par exemple), la date d'adhésion suffit pour connaitre sa validité, le statut serait en ce cas une redondance, à supprimer

Citation:

---

Envoyé par Busima

==> Différence entre adhésion, cotisation et evenement:
adhésion est la somme que paye une personne pour devenir membre, tandis que cotisation est la contribution des membres pour faire fonctionner l'association( le paiement de la cotisation
est périodique alors que le paiement de l'adhésion peut se faire une seule fois). A la différence de cotisation, evenement est un peu comme cotisation, cependant il n'est pas périodique car
son paiement se fait lors d'un événement (soit pour le mariage ou anniversaire d'un membre...).

---

Est-ce qu'on peut simplifier en disant que :
- est adhérent tout membre à jour de ses cotisations
- le montant de la cotisation est plus élevé pour un membre non adhérent que pour un membre déjà adhérent ?

Si oui
- le statut adhérent ou non adhérent est le résultat d'un calcul basé sur la présence d'une cotisation dans l'année qui précède
- la date d'adhésion est à déplacer dans "membre"
- le paiement concerne donc soit la cotisation (avec un supplément éventuel lors de l'adhésion) soit un événement.

Il faut donc faire apparaitre une Contrainte d'Intégrité Fonctionnelle de type "partition" à indiquer sur le MCD

Bonjour escartefigue, je commence d'abord par vous remercier. Je vous donne plus d'informations:

==>Une catégorie est la différence entre les membres, par exemple (catégorie "Doyen", catégorie "Cadet", catégorie "junior" ... ou catégorie "Riche", catégorie "Moins riche", catégorie "Neutre"...). Donc chaque membre est forcement rattaché à une catégorie.

Citation:

---

Envoyé par escartefigue

C'est donc une conséquence directe de l'âge. Stocker la catégorie serait une erreur, ce serait un risque d'incohérence avec l'âge.
Vous pouvez la déduire de la date de naissance, dont vous déduirez l'âge (que vous ne stockerez pas non plus pour la même raison).
Bien évidemment, il ne faut donc plus identifier le membre relativement à la catégorie

---

Non non, la catégorie n'est pas forcement une conséquence directe de l'age. Je veux forcement mettre une différence entre les membres. Par exemple lorsqu'on considère l'ONU, il y a des membres qui ont le droit de véto pour une raison quelconque et d'autres n'en ont pas. C'est ce que je veux faire, d'autres membres doivent être démarqués des autres soit par le montant des cotisations...

Citation:

---

Envoyé par escartefigue

Si la durée de validité d'une adhésion est invariante (un an par exemple), la date d'adhésion suffit pour connaitre sa validité, le statut serait en ce cas une redondance, à supprimer

---

==> La différence entre l'adhésion, la cotisation et evenement est que adhésion est la somme que paye une personne pour devenir membre, tandis que cotisation est la contribution des membres pour faire fonctionner l'association( le paiement de la cotisation est périodique alors que le paiement de l'adhésion peut se faire une seule fois). A la différence de cotisation, evenement est un peu comme cotisation, cependant il n'est pas périodique car son paiement se fait lors d'un événement (soit pour le mariage ou anniversaire d'un membre...).

Citation:

---

Envoyé par escartefigue

Est-ce qu'on peut simplifier en disant que :
- est adhérent tout membre à jour de ses cotisations?

---

Malheureusement non. Est adhérent tout membre qui paye son droit d'adhésion (en quelque sorte adhérent=membre).

Citation:

---

Envoyé par escartefigue

- le montant de la cotisation est plus élevé pour un membre non adhérent que pour un membre déjà adhérent ?

---

Non, on pourra parler de montant de cotisation élevé d'un membre par rapport à un autre seulement à cause de la "catégorie" du membre. On pourra dire par exemple que la "categorie riche" paye plus que la "categorie moins riche". (Comme ici, pour un evenement A,..., montant categorie riche = 1500 euros, categorie moins riche montant=1000 euros et montant categorie neutre =500euros.)

Citation:

---

Envoyé par escartefigue

- le paiement concerne donc soit la cotisation (avec un supplément éventuel lors de l'adhésion) soit un événement.

---

Oui le paiement concerne soit la cotisation, soit l'adhésion ou soit un événement, et non avec un supplément éventuel lors de l'adhésion parce que l'adhésion elle même est concernée par le paiement.
Encore merci pour votre temps que vous prenez!

Y a quelqu'un pour m'aider?

Citation:

---

Envoyé par Busima

Y a quelqu'un pour m'aider?

---

Quelques réponses pour vous débloquer

Citation:

---

Envoyé par Busima

Non non, la catégorie n'est pas forcement une conséquence directe de l'age. Je veux forcement mettre une différence entre les membres. Par exemple lorsqu'on considère l'ONU, il y a des membres qui ont le droit de véto pour une raison quelconque et d'autres n'en ont pas. C'est ce que je veux faire, d'autres membres doivent être démarqués des autres soit par le montant des cotisations...

---

OK, mais en ce cas, il faut considérer que "cadet", "junior" et autres valeurs liées à l'âge ne sont pas des catégories. Ce sont peut être des critères de tarification (cotisation modulée en fonction de la classe d'âge par exemple), mais pas des catégories, ce serait comme expliqué plus haut, une redondance.

Citation:

---

Envoyé par Busima

==> La différence entre l'adhésion, la cotisation et evenement est que adhésion est la somme que paye une personne pour devenir membre, tandis que cotisation est la contribution des membres pour faire fonctionner l'association(le paiement de la cotisation est périodique alors que le paiement de l'adhésion peut se faire une seule fois). A la différence de cotisation, evenement est un peu comme cotisation, cependant il n'est pas périodique car son paiement se fait lors d'un événement (soit pour le mariage ou anniversaire d'un membre...).

---

Je suppose que seul un membre déjà adhérent peut payer une cotisation et que seul un membre déjà adhérent peut payer pour un événement.
Du coup une Contrainte d'Intégrité Fonctionnelle (CIF) de type inclusion doit être modélisée de la relation "effectuer" vers la relation "payer"

Citation:

---

Envoyé par Busima

Malheureusement non. Est adhérent tout membre qui paye son droit d'adhésion (en quelque sorte adhérent=membre).

---

Si vous voulez pouvoir enregistrer des membres qui n'ont pas encore payé leur adhésion, il faut alors une cardinalité mini de zéro de "MEMBRE" vers "ADHESION"
Ne seront réellement considérés comme membres que ceux qui ont une occurrence de relation "payer" dont la date de fin de validité n'est pas atteinte (attribut date de fin à ajouter dans l'entité-type "ADHESION")

Citation:

---

Envoyé par Busima

Non, on pourra parler de montant de cotisation élevé d'un membre par rapport à un autre seulement à cause de la "catégorie" du membre. On pourra dire par exemple que la "categorie riche" paye plus que la "categorie moins riche". (Comme ici, pour un evenement A,..., montant categorie riche = 1500 euros, categorie moins riche montant=1000 euros et montant categorie neutre =500euros.)

---

Les critères de tarifications méritent une étude rigoureuse si vous ne voulez pas être soupçonné d'établir les tarifs "à la tête du client" ;)
Il faut donc recenser précisément les règles selon lesquelles s'établissent les tarifs (classe d'âge, revenu imposable, nombre d'enfants, tarif personnes âgées, étudiant, handicapé...)
La catégorie n'est peut être pas un attribut en soi mais seulement la résultante d'autre critères.

Citation:

---

Envoyé par Busima

Oui le paiement concerne soit la cotisation, soit l'adhésion ou soit un événement, et non avec un supplément éventuel lors de l'adhésion parce que l'adhésion elle même est concernée par le paiement.

---

En ce cas "ADHESION" devrait être en relation avec "PAIEMENT" et il devrait y avoir une CIF de type partition pour mentionner qu'un paiement concerne une et un seule des 3 entités-type

Merci, mais quelle proposition de modèle avec contrainte d'intégrité pouvez-vous me faire svp?

Bonjour,

J'ai lu l'ensemble assez vite mais j'ai quelques doutes sur la compréhension de l'ensemble...

Ce que j'ai compris :
1) Un membre est considéré comme tel dès qu'il paye une adhésion.
2) Un membre peut participer à un événement en payant un droit d'inscription.
Ce que je n'ai pas compris, c'est ce que représente la cotisation.Est-ce une cotisation annuelle (ou autre périodicité) venant en plus de l'adhésion ?

Bonjour CinePhil,

Citation:

---

Envoyé par CinePhil

Ce que je n'ai pas compris, c'est ce que représente la cotisation.Est-ce une cotisation annuelle (ou autre périodicité) venant en plus de l'adhésion ?

---

Je n'ai pas encore décidé de la périodicité de la cotisation (annuelle, semestrielle, trimestrielle ou mensuelle). Mais je pense que c'est le même principe, ou bien je me trompe? Cependant la cotisation vient en plus de l'adhésion et de l'evenement comme sur le schema.

OK. Donc tant que le membre paye sa cotisation périodique, il garde le statut de membre ? L'adhésion ne se paye qu'une seule fois ?

Citation:

---

Envoyé par CinePhil

OK. Donc tant que le membre paye sa cotisation périodique, il garde le statut de membre ?

---

Oui c'est bien ça!

Citation:

---

Envoyé par CinePhil

L'adhésion ne se paye qu'une seule fois ?

---

L'adhésion se paye normalement une seule fois. Cependant on pourra accepter que des membres payent en plusieurs tranches leur adhésion. Aussi, si un membre, après avoir payé son adhésion quitte l'assoiation, il pourra revenir encore quelques temps après pour adhérer à nouveau. Dans ce cas il doit encore payer à nouveau le droit d'adhésion, même s'il l'avait déjà payé. Merci!

M'a t-on oublié?

Bonjour,

Où en êtes-vous ? Est-ce que vous avez des questions ?

Oui, bien sûre Oishiiii. C'est moi qui ai posté le billet. Et je ne suis pas encore satisfait. Si vous pouvez lire un pour vous imprégner de la situation et voir si vous pouvez m'aider!

Publiez une nouvelle version de votre modèle qui tient compte des remarques précédemment formulées, ca facilitera grandement nos interventions ;)

Citation:

---

Envoyé par escartefigue

Publiez une nouvelle version de votre modèle qui tient compte des remarques précédemment formulées, ca facilitera grandement nos interventions ;)

---

Bonjour escartefigue, je publie la nouvelle version de mon modèle pour une analyse minutieuse.
Dans ce nouveau modèle j'ai supprimé la table "Type_paiement", j'ai relié la table "Adhésion" à la table "Paiement" sous votre recommandation. Cependant je doute encore sur la suppression de la table "Catégorie" et sur la position de la table "Montant". Encore merci à toute l'équipe du forum!

Pièce jointe 422460

Bonsoir Busima,



Concernant l'entité-type MONTANT
Vu que la catégorie de membre pilote la tarification, il serait préférable de renommer l'entité-type "MONTANT" en "TARIF"



Concernant l'entité-type PAIEMENT
Le montant du paiement devrait être un attribut de l'entité-type "paiement", la relation de "PAIEMENT" vers "TARIF" est à supprimer
Le montant concerne une dette, cette dette est de type "adhésion", "cotisation" ou "événement".

Utilisez l'héritage comme suit, au niveau conceptuel :
.............................................................. .┌--- ADHESION
PAIEMENT 1,1 --- concerner --- 0,n DETTE ---XT-- COTISATION
............................................................... └--- EVENEMENT

Ce qui donne les tables

PAIEMENT_PA(PA_id, PA_montant, PA_date...)
DETTE_DT(DT_id, DT_montant, DT_solde, DT_date_solde)
ADHESION_AD(DT_id, TA_id#) TA_id étant la clef étrangère liée à la tarification en fonction de la catégorie (voir ci-dessous)
COTISATION_CO(DT_id, CO_annee)
EVENEMENT_EV(DT_id, EV_date, EV_libelle)



D'une façon générale
La plupart de vos attributs sont d'un type inadapté : montant_a_payer en varchar, année en char(5)... à corriger bien sur :P

Bonjour escartefigue,
encore je vous remercie pour votre aide!
Je note bien vos remarques et suggestions sur mon projet. J'ai bien compris pour l'entité-type MONTANT. Cependant j'ai un soucis de compréhension concernant l'entité-type PAIEMENT et "MONTANT". Je comprends et j'accepte que je dois renommer "MONTANT" en TARIF :P et supprimer la relation de "PAIEMENT" vers "TARIF".
Mais si le montant du paiement devient un attribut de l'entité-type "PAIEMENT", alors j'ai un problème sur l'attribut "droit d'adhesion" de l'entité-type "ADHESION" qui est aussi un montant à payer. Cet attribut doit rester dans l'entité "ADHESION" ou bien il doit devenir attribut de "TARIF" ou de "PAIEMNT"?

De plus, du fait que je veux me limiter au MCD pour directement faire ma base de données, je préfère exclure si possible l'héritage au niveau conceptuel parce que je ne maîtrise pas d'abord la notion d'héritage (sauf si vous m'éclaircissez le sujet :P). Je pense que je suis proche du but.
Ci-dessous le nouveau schema.
Pièce jointe 422947

Citation:

---

Envoyé par escartefigue

Concernant l'entité-type MONTANT
Vu que la catégorie de membre pilote la tarification, il serait préférable de renommer l'entité-type "MONTANT" en "TARIF"

---

Ici est ok.

Citation:

---

Envoyé par escartefigue

Concernant l'entité-type PAIEMENT
Le montant du paiement devrait être un attribut de l'entité-type "paiement", la relation de "PAIEMENT" vers "TARIF" est à supprimer

---

Ok

Citation:

---

Envoyé par escartefigue

Le montant concerne une dette, cette dette est de type "adhésion", "cotisation" ou "événement".

Utilisez l'héritage comme suit, au niveau conceptuel :
.............................................................. .┌--- ADHESION
PAIEMENT 1,1 --- concerner --- 0,n DETTE ---XT-- COTISATION
............................................................... └--- EVENEMENT

Ce qui donne les tables
PAIEMENT_PA(PA_id, PA_montant, PA_date...)
DETTE_DT(DT_id, DT_montant, DT_solde, DT_date_solde)
ADHESION_AD(DT_id, TA_id#) TA_id étant la clef étrangère liée à la tarification en fonction de la catégorie (voir ci-dessous)
COTISATION_CO(DT_id, CO_annee)
EVENEMENT_EV(DT_id, EV_date, EV_libelle)

---

??? :oops:

Pour les explications au sujet de l'héritage, jetez un coup d'oeil ici à partir du chapitre IV ;)

Depuis ce poste de travail, je n'ai malheureusement pas accès à un logiciel de modélisation qui m'aurait permis de construire un exemple

Dans l'exemple que j'ai fourni précédemment, "DETTE" est le sur-type alors que "ADHESION", "COTISATION" et "EVENEMENT" sont les sous-types
Les identifiants primaires sont en gras et soulignés et les clef étrangères sont suffixées par #