Discussion :

[ecarbill]

Bonjour à tous.
J'essaye de modéliser la gestion d'associations donc les principes de bases peuvent différer (Niveau de cotisation différents) selon les principes suivants:

P01. Une personne peut appartenir à plusieurs associations
P02. Une Association peut être subdiviser en plusieurs groupes auxquels les membres sont affectés
P03. Une cotisation peut être fixée pour chaque groupe pour une période donnée (Les montants peuvent être différents d'un groupe à l'autre)
P04. Une cotisation peut être fixée pour chaque adhérent pour une période donnée (Les montants peuvent être différents d'un groupe à l'autre).

Je joins le projet de MCD que j'ai fais sous PowerDesigner.



Néanmoins je souhaiterais avoir un coup de main sur deux points

1. Au niveau P02 tel que j'ai modéliser je vois une redondance puisque avec la relation

AFFECTER

entre adhesion et Groupe, je voulais supprimer la relation

ADHES_ASSOCIATION

, mais en ce moment au niveau MPD, ce sont les clés primaires de personne et groupe qui apparaitront comme clé étrangère dans adhesion. Ce que je ne souhaite pas puisque je me dis que c'est dans l'association qu'une personne adhère, l'affectation à un groupe vient après.

2. Concernant les cotisation qui peuvent être liées soit à un adherant, soit à un groupe, j'ai du mal à faire la bonne modélisation. J'avais voulu utiliser la notion d'héritage en créant une entité cotisant dont les fils seraient adhesion et groupe. Mais je ne sais pas si cela correspond vraiment au concept d'héritage, et en plus j'ai du mal à le réaliser.

Merci d'avance de m’éclairer avec vos expertises

[escartefigue]

Bonjour Ecarbill,

C'est une très bonne chose d'avoir communiqué les règles de gestion, mais il faut les compléter avant de pouvoir valider le MCD.

Par exemple :

P01. Une personne peut appartenir à plusieurs associations

Très bien, mais il manque la règle décrivant l'autre sens de l'association.
Cette règle manquante est possiblement "Pxx : à une association peuvent adhérer plusieurs personnes" ou encore "Pxx : à une association adhère au moins une personne"
le verbe "adhérer" est mieux adapté qu'"appartenir"

Il en va de même pour les autres associations du MCD dont chaque "patte" doit trouver sa justification dans une règle de gestion.


Que sont les attributs "contact1" à "contact3" de l'entité-type [personne] ?

S'il s'agit de n° de téléphone, d'adresse courriel ou autre, il est préférable de modéliser une entité-type spécifique qu'on pourra appeler par exemple [MEDIA] et qui sera associée à la personne autant de fois que nécessaire.
Cette ET [MEDIA] sera également associée à un type de média pour savoir de quoi il s'agit (type téléphone fixe domicile, type téléphone portable pro, fax pro, portable perso...)
Ce qui donne [PERSONNE] 0,n --- (posseder) --- 1,1 [MEDIA] 1,1 --- (typer) --- 0,n[TYPE_MEDIA]

S'il s'agit du nom d'autres personnes à contacter, alors il faut établir une relation reflexive de l'ET [PERSONNE] sur elle-même.


Mais pour l'instant, comme dit plus haut, le plus important est de compléter les règles de gestion

Bon courage

[ecarbill]

mais il manque la règle décrivant l'autre sens de l'association

Bonjour, en fait j'ai mis en exergue juste les éléments pour lesquels j'avais un soucis mais je vais compléter comme je peux:



P01. Une personne peut adhérer à plusieurs associations et chaque personne adhère à au moins une association
P02. Une Association peut être subdiviser en plusieurs groupes auxquels les membres sont affectés, et chaque groupe est relié à au moins une association
P03. Une cotisation peut être fixée pour chaque groupe pour une période donnée (Les montants peuvent être différents d'un groupe à l'autre)
P04. Une cotisation peut être fixée pour chaque adhérent pour une période donnée (Les montants peuvent être différents d'un groupe à l'autre).
P05. Une adhésion est relative à une et une seule personne
P06. Une adhésion est relative à une et une seule association
p07. Une cotisation peut faire l'objet de 0 ou plusieurs versements
p08. Un versement porte sur une et une seule cotisation

Voila pour l'essentiel. merci d'avance

[escartefigue]

On en sait déjà un peu plus, mais

Une personne peut-elle adhérer à une association sans pour autant être rattachée à un groupe ?
Une personne peut-elle adhérer à une association en étant rattachée à plusieurs groupes de cette même association ?

Par ailleurs, je note qu'en vertu de la règle P02, un même groupe peut concerner plusieurs associations :

et chaque groupe est relié à au moins une association

Ce faisant, compte tenu de cette règle

Une cotisation peut être fixée pour chaque groupe pour une période donnée

Si ce groupe concerne plusieurs associations, alors la cotisation est la même pour les différentes associations.

On est bien d'accord ?

Tous ces points sont importants, le modèle conceptuel en dépend.

[ecarbill]

Bonjour escartefigue et merci de ton intérêt pour mon problème.

Une personne peut-elle adhérer à une association sans pour autant être rattachée à un groupe ?

La reponse est non. Chaque adhérent est forcément rattaché à un groupe

Une personne peut-elle adhérer à une association en étant rattachée à plusieurs groupes de cette même association ?

Chaque adhérent est rattaché à un et un seul groupe

Par ailleurs, je note qu'en vertu de la règle P02, un même groupe peut concerner plusieurs associations :
et chaque groupe est relié à au moins une association

Un groupe est rattaché à une et une seule Association. Effectivement, j'avais mal formulé le P02

merci et bonne journée à toi

[Paprick]

Bonjour,

En plus des conseils avisés de Escartefigue, j'aurais une remarque concernant l'association "HABITER" : telle qu'elle est modélisée, une personne ne peut pas revenir sur une commune où elle a habité précédemment (ou alors, on perd les dates de la première période) ; en effet, pour 1 personne ET 1 commune, il n'y a qu'une seule date de début et de fin...
Pour régler ce problème, il faudrait intégrer la date de début dans l'identifiant de "HABITER", et donc passer par une tripatte avec une classe d'entité fictive "CALENDRIER" : on constatera alors que l'identifiant de la commune n'est plus utile (propriété d'irréductibilité à respecter), une CIF réglant le problème.
Voici ce que donnerait cette partie de MCD (fait avec Looping, PowerDesigner ne gérant pas les CIF à ma connaissance) :

Version avec CIF abrégée :

Le MLD correspondant donnera ça :

Bonne continuation !

[ecarbill]

Bonjour Paprick et merci pour cette aide.

Néanmoins j'attend toujours des aides pour mon problème initial qui était:

1. Comment bien modéliser les cotisations étant donné qu'une cotisation peut etre fixé par groupe (ce sont les groupes qui s'acquittent de la cotisation) ou par adhérent (chaque adhérent paye un montant par période)

2. Comment bien modéliser l'appartenance d'un adhérent à une association, et sont affectation à un groupe à l'intérieur de cette association

Merci bien

[escartefigue]

Pour bien répondre à ces besoins, il faut bien comprendre le contexte, d'où les questions qui précèdent.

Et en voici une autre, désolé, mais ce qui est évident pour vous, ne l'est pas pour nous

Il faut bien distinguer la notion de tarification de la notion de paiement

Quand on dit que

ce sont les groupes qui s'acquittent de la cotisation

ou que

chaque adhérent paye un montant par période

on parle de qui paye, mais ça ne veut pas dire que le tarif est forcément différent.

Si le tarif est le même que ce soit le groupe ou la personne qui paye alors il faut simplement avoir un tarif, associé à l'association et probablement à l'année (le tarif pouvant changer)

Si au contraire le tarif est différent selon que c'est la personne qui paye ou bien le groupe alors il faut associer d'une part un tarif groupe au groupe et d'autre part un tarif associé à l'asso

[ecarbill]

Bonjour escartefigue
Merci pour tes contributions.

on parle de qui paye, mais ça ne veut pas dire que le tarif est forcément différent.

Si le tarif est le même que ce soit le groupe ou la personne qui paye alors il faut simplement avoir un tarif, associé à l'association et probablement à l'année (le tarif pouvant changer)

Si au contraire le tarif est différent selon que c'est la personne qui paye ou bien le groupe alors il faut associer d'une part un tarif groupe au groupe et d'autre part un tarif associé à l'asso

Je l'avait précisé dans mes règles de gestions

P03. Une cotisation peut être fixée pour chaque groupe pour une période donnée (Les montants peuvent être différents d'un groupe à l'autre)
P04. Une cotisation peut être fixée pour chaque adhérent pour une période donnée (Les montants peuvent être différents d'un groupe à l'autre).

En effet les montants peuvent etre différents selon les individus et aussi selon les groupes. C'est pour ca dans mon MCD que j'avais proposé, les montants étaient dans les associations DEVOIR_INDIV et DEVOIR_GPE

Bonne journée a vous

[escartefigue]

En effet, du coup les deux associations de votre modèle se justifient.
Mais ce faisant, plusieurs personnes d'un même groupe risquent de payer des montants différents, ça fait un peut facturation "à la tronche du client" comme on dit trivialement.


Pour la deuxième question :

Comment bien modéliser l'appartenance d'un adhérent à une association et son affectation à un groupe à l'intérieur de cette association

Comme toute personne n'adhère à une association qu'au travers d'un groupe et qu'un groupe ne concerne qu'une et une seule association, on connait l'appartenance (l'adhésion) d'une personne à une association en passant par le groupe

Voici une proposition de MCD pour cette partie, dans laquelle j'ai ajouté une contrainte d'inclusion pour vérifier qu'une personne ne peut faire partie d'un groupe que si elle adhère à l'association de ce groupe.
J'ai également ajouté une entité-type fictive CA_calendrier, car j'ai supposé que les tarifs évoluaient selon les années
Enfin, j'ai fait pointer la personne et le groupe vers une nouvelle entité-type tarif qui peut être associée soit à la personne (tarif individuel) soit au groupe (tarif de groupe).




Le MLD correspondant :




Et enfin le DDL ici décliné pour SQL server (je n'ai pas codé la contrainte, mais ce n'est pas grand chose à faire :

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
74
75
76
77
78
79
CREATE TABLE PE_personne(
   PE_ident INT IDENTITY,
   PE_nom VARCHAR(50) NOT NULL,
   PE_prenom VARCHAR(50) NOT NULL,
   PE_ddn DATE NOT NULL,
   PRIMARY KEY(PE_ident)
);
 
CREATE TABLE AS_association(
   AS_ident INT IDENTITY,
   AS_siren CHAR(9) NOT NULL,
   AS_nom VARCHAR(255) NOT NULL,
   PRIMARY KEY(AS_ident),
   UNIQUE(AS_siren)
);
 
CREATE TABLE GR_groupe(
   AS_ident INT,
   GR_seq SMALLINT,
   GR_code CHAR(4) NOT NULL,
   GR_lib VARCHAR(50) NOT NULL,
   PRIMARY KEY(AS_ident, GR_seq),
   UNIQUE(GR_code),
   FOREIGN KEY(AS_ident) REFERENCES AS_association(AS_ident)
);
 
CREATE TABLE TA_tarif(
   TA_ident INT IDENTITY,
   TA_code CHAR(4) NOT NULL,
   TA_montant DECIMAL(7,2) NOT NULL,
   PRIMARY KEY(TA_ident),
   UNIQUE(TA_code)
);
 
CREATE TABLE CA_calendrier(
   CA_dtdeb DATE,
   PRIMARY KEY(CA_dtdeb)
);
 
CREATE TABLE AD_adhesion(
   PE_ident INT,
   AD_seq SMALLINT,
   AD_dtdeb DATE NOT NULL,
   AD_dtfin DATE NOT NULL,
   AS_ident INT NOT NULL,
   PRIMARY KEY(PE_ident, AD_seq),
   FOREIGN KEY(PE_ident) REFERENCES PE_personne(PE_ident),
   FOREIGN KEY(AS_ident) REFERENCES AS_association(AS_ident)
);
 
CREATE TABLE AF_affecter(
   PE_ident INT,
   AS_ident INT,
   GR_seq SMALLINT,
   PRIMARY KEY(PE_ident, AS_ident, GR_seq),
   FOREIGN KEY(PE_ident) REFERENCES PE_personne(PE_ident),
   FOREIGN KEY(AS_ident, GR_seq) REFERENCES GR_groupe(AS_ident, GR_seq)
);
 
CREATE TABLE AP_appliquer(
   AS_ident INT,
   GR_seq SMALLINT,
   TA_ident INT,
   CA_dtdeb DATE,
   PRIMARY KEY(AS_ident, GR_seq, TA_ident, CA_dtdeb),
   FOREIGN KEY(AS_ident, GR_seq) REFERENCES GR_groupe(AS_ident, GR_seq),
   FOREIGN KEY(TA_ident) REFERENCES TA_tarif(TA_ident),
   FOREIGN KEY(CA_dtdeb) REFERENCES CA_calendrier(CA_dtdeb)
);
 
CREATE TABLE CO_cotiser(
   PE_ident INT,
   TA_ident INT,
   CA_dtdeb DATE,
   PRIMARY KEY(PE_ident, TA_ident, CA_dtdeb),
   FOREIGN KEY(PE_ident) REFERENCES PE_personne(PE_ident),
   FOREIGN KEY(TA_ident) REFERENCES TA_tarif(TA_ident),
   FOREIGN KEY(CA_dtdeb) REFERENCES CA_calendrier(CA_dtdeb)
);

[ecarbill]

Bonsoir escartefigue
Merci du temps consacré à ma préoccupation et surtout pour cette reponse vraiment détaillée.

Globalement j'ai compris la modélisation, à part l'entité CA_calendrier dont j'ai du mal a saisir le lien avec CO_cotiser et AP_appliquer.

Bonne soirée

[escartefigue]

J'ai supposé que les tarifs appliqués à une personne ou à un groupe pouvaient évoluer dans le temps : un même personne ou un même gropue peut se voir appliquer un tarif T1 en 2022 puis un tarif T2 en 2023.
Pour y parvenir, il faut que l'association entre personne (ou groupe) et tarif fasse participer la date qui deviendra une composante de la clef primaire de la table issue de l'association.

CA_calendrier est ce qu'on appelle une entité-type "fictive", elle ne participe au modèle que pour enrichir la clef primaire des tables associatives au niveau SQL, elle ne deviendra pas une table, ce serait inutile *.

Voyez le DDL généré dans lequel on retrouve l'attribut CA_dtdeb comme composante de la PK des tables associatives.

* avec le logiciel Looping que j'ai utilisé pour modéliser, le nom de l'entité-type CA_calendrier aurait du être entre parenthèses, mais j'ai visiblement oublié de cocher la case "entité-type fictive", raison pour laquelle ce n'est pas le cas

[ecarbill]

Ah OK c'est effectivement ca. je comprend parfaitement.

Merci et bonne journée à toi