Gestion d'une association d'aide au développement

**Sahrrouman** · 19/11/2006, 16h33

Je suis actuelement en école d'ingénieur et j'ai un projet de SGBD a faire.
Mon problème est que concernant l'interrogation de base de donnée j'arrive a peu près a me débrouiller par contre d'un point de vue conception je suis completement perdu, je m'embrouille tout le temps avec les clé primaires, entité-association,etc...

Voici le sujet : association d'aide au développment

Une association organise des chantiers d'été dans des pays en voie de développement. Les membres de l'asso sont ceux qui ont participé à au moins un chantier. En général, une 10ène de membres participent à un chantier. Un chantier est caractérisé par le nom du village et du pays ou il se déroule, le type de batiment construit (école, logements...) un nom de partenaire sur le projet, la date de bébut et la date de fin. Sur un chantier, le membre peut avoir le statut de chef de chantier. il peut y avoir plusieurs membres chefs de chantier par chantier.
Les membres de l'association peuvent aussi être membres du conseil d'administration. Le CA est renouvelé dans sa totalité au moins une fois par an par l'ensemble des membres à jour de leur cotisation. Un CA a une date de début et une date de fin. Un membre du CA a une fonction unique définie pour la durée du CA (président, trésorier, secrétaire, administrateur).
L'association recoit des dons de donateurs (privé ou publics). Un don est caractérsé par la date du don, le montant et le mode de paiement (chèque, liquide ou virement) et l'origine du don (mailing,recu,chantier, inconnue). Un donateur est caractérisé par son nom et son adresse. Les membres de l'assos peuvent aussi être des donateurs. Les cotisations des membres sont considérées comme des dons.
Pour les membres, on conserve aussi éventuellement une 2ieme adresse avec un mail et un téléphone.
Sont à jour de leur cotisation à une date donnée, les membres qui ont fait un don d'au moin 20€ dans les 12 derniers mois.
Chaque année, en janvier, l'assos envoie des recus fiscaux aux donateurs pour les dons de l'année précédente. On envoie un recu fiscal par don. Pour chaque don, on enregistre la date d'envoi du recu fiscal.

J'ai déjà enormement réfléchi a la question, et je me retrouve avec 4 entités (membres, dons, chantier et CA) et 3 associations entre elles. Mais au moment de faire le graphe des dépendances fonctionnelles, cela ne colle pas...

Si vous pouviez m'aider à concevoir une bonne base de donnée de départ pour pouvoir travailler dessus, cela me sauverai la vie car je ne vais pas y arriver seul.

Merci.

**TheLeadingEdge** · 19/11/2006, 21h52

Envoyé par Sahrrouman

J'ai déjà enormement réfléchi a la question, et je me retrouve avec 4 entités (membres, dons, chantier et CA) et 3 associations entre elles. Mais au moment de faire le graphe des dépendances fonctionnelles, cela ne colle pas ...

Au vu de l'énoncé, 4 entités ça me parait court.
Pour découvrir les entités je pense qu'il est préférable de déterminer les DF en 1er.
Essaies de faire la matrice des DF.

Envoyé par Sahrrouman

...cela me sauverai la vie

Fais voir ce que tu as déjà fait, qu'on voit si il te reste 1 espoir

.

**fsmrel** · 20/11/2006, 00h04

Bonsoir Sahrrouman,

Vous y verrez peut-être plus clair en définissant une entité-type Donateur, porteuse des propriétés Nom, adresse.

Les dons sont en relation avec un donateur donné.

Vous associez les entités-types Donateur et Membre : un Membre est un donateur et un donateur peut être un membre (ça ressemble à du sous-typage mais semble-t-il, les donateurs non membres n'ont pas de propriétés particulières).

Le montant de la cotisation payée figure dans Don en tant que montant du don. Si le membre n’a pas encore payé sa cotisation, il est quand même considéré comme donateur n’ayant pas (encore) fait de don.

Ça vaut ce que ça vaut, mais ça mérite d’être étudié.

Si vous avez besoin de précisions, n'hésitez pas.

**Sahrrouman** · 20/11/2006, 15h32

Envoyé par TheLeadingEdge

Fais voir ce que tu as déjà fait, qu'on voit si il te reste 1 espoir

.

J'ai pensé à une table des membres de l'association avec comme attributs (nom, prénom, num_chantier, statut, num_don) qui serai en relation par le num_chantier avec la table des chantiers ayant pour attributs (num_chantier, nom_village, nom_pays, type_batiments, partenaire, date_début, date_fin) mais aussi avec la table des dons par num_don.

Ensuite une table des dons avec (num_don, typ_don, date_don, montant_don mode_paiement, origine_don) qui serai en relation avec une table type des donateur (nom_donateur, prenom_donateur, adress_donateur, type_donateur)

J'ai aussi pensé à une table Conseil d'Administration avec comme attributs (date_début, date_fin) mais je ne vois pas comment la mettre en relation avec la table des membres sachant que qu'il peux y avoir que 4 membres dans le CA (préz, trésorier, secrétaire, admininisteur) enfin d'apres ce que j'ai compris.

Plus loin dans l'énoncé, il m'est demander de créer les tables avec au moins 2 chantiers, 5 personnes par chantier, 2 CA, 3 personnes par CA, 10 dons, 5 donnateurs non membres, là encore, je ne vois comment je peux lier CA et membres sachant qu'il peux y avoir plusieur CA.

Voilà, cela ne dois pas être tres brillant mais je débute ^^

**fsmrel** · 20/11/2006, 19h18

Bonsoir Sahrrouman,

Sahrrouman a écrit :
J'ai aussi pensé à une table Conseil d'Administration avec comme attributs (date_début, date_fin) mais je ne vois pas comment la mettre en relation avec la table des membres sachant que qu'il peux y avoir que 4 membres dans le CA (préz, trésorier, secrétaire, admininisteur) enfin d'apres ce que j'ai compris.

Vous pouvez définir une entité-type associative disons Participation connectant Membre et CA. Participation est porteuse de la propriété Fonction ou selon Merise est en relation avec une entité-type Fonction.

Après dérivation du MCD, l’instruction Create Table Participation pourrait ressembler à ceci :

Code :

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

1
2
3
4
5
6
7
8
9
CREATE TABLE Participation
       (
	Membre_Id    Integer   Not Null,
	CA_Id        Integer   Not Null,
	Fonction     Character 
               Constraint Fonction_Possible Check (Fonction in ("président", "trésorier", "secrétaire", "administrateur")), 
        ...
       )

Plus classiquement, vous pouvez aussi dériver l’entité-type Fonction sous forme d’une table Fonction et laisser dériver le lien Participation-Fonction sous forme de clé étrangère (Cf. Pièces jointes).

**TheLeadingEdge** · 20/11/2006, 20h10

Bonsoir,

Ca pourrait aussi donner qque chose comme ça ...

Mais ça me semble limite 1FN ...
J'aimerais bien avoir l'avis de Nanci

**fsmrel** · 20/11/2006, 23h55

Bonsoir Sahrrouman, bonsoir TheLeadingEdge,

TheLeadingEdge a écrit :
Mais ça me semble limite 1FN

Je m’adresse donc à TheLeadingEdge :

Je ne sais pas ce qu’en pense Nanci, mais du point de vue de Ted Codd, qui a donné la définition de la première forme normale dans son article fondateur de 1970, votre représentation est légale à cet égard. La première forme normale n’est pas respectée quand un attribut d’une relation (au sens du Modèle Relationnel) contient des valeurs qui sont des relations. Donc pour faire court, en traduisant les choses en Merise, quand une propriété d’une entité-type prendrait des valeurs qui seraient des entités. Par exemple : l’entité-type Facture ayant pour attribut la ligne de facture. En passant, toujours au sens du Modèle Relationnel, les choses ont évolué et un attribut d’une relation peut aujourd’hui prendre des valeurs qui sont des relations, mais ceci est une autre histoire.

Cela dit, votre représentation permet de garantir la présence des fonctions exercées par les membres : un CA comporte nécessairement un président, un secrétaire, un trésorier et un administrateur. Mais, cette représentation autorise-t-elle que dans le temps, un membre puisse changer de fonction ? (Je m’en remets à vous-même et à Nanci).

Inconvénients

1) Tout cela passe peut-être au-dessus de la tête de Sahrrouman qui se présente plutôt comme novice en matière de modélisation.

2) En procédant comme vous le faites (quatre relations au sens Merise), vous ne simplifiez pas l’évolution du système. En effet le jour ou l’on aura 5 puis 6, puis etc. types de fonctions exercées par les membres au sein d’un CA, ça deviendra délicat... Vous me direz qu’au niveau conceptuel, on ajoute autant d’associations, point barre. Mais, au niveau du SGBD, les collègues DBA auront à chaque fois à ajouter une colonne par fonction exercée et, pour quitter le cas d’école, la production informatique sera mécontente (euphémisme...), surtout si les tables comportent des dizaines ou des centaines de millions de lignes (histoire vécue). Loin des cimes conceptuelles et platoniciennes, un Alter Table n’est pas neutre, ça se quantifie en journées/homme, dans les environnements de test, puis d’intégration, puis de production, et ça met en jeu le porte-monnaie des DSI...

On pourrait par exemple mettre en œuvre une entité-type Fonction (exercée par un membre dans un CA) et vérifier au niveau du SGBD les contraintes que vous avez modélisées. Le problème étant que, si au niveau du Modèle Relationnel (voire du standard SQL) les contraintes s’expriment sans problèmes, en revanche les SGBD sont à la traîne : aujourd’hui tout n’est pas encore simple à ce sujet et sans doute pour quelques années encore...

**TheLeadingEdge** · 21/11/2006, 22h52

Bonsoir,

1 table comme ça ...

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
CREATE TABLE CA  
(
debut		DATE	NOT NULL,
fin          		DATE       NOT NULL,
president		INTEGER NOT NULL,
secretaire 	INTEGER NOT NULL,
tresorier		INTEGER NOT NULL,
administrateur	INTEGER NOT NULL,
PRMARY KEY (DATEDEDEBUT, DATEDEFIN),
FOREIGN KEY (president) REFERENCES MEMBRE (IDMEMBRE),
[...]
)

... n'est qu'1 façon déguisée d'écrire ça ...

Code :

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

1
2
3
4
5
6
7
CREATE TABLE CA  
(
debut	DATE	NOT NULL,
fin          DATE       NOT NULL,
idMembre [n]	INTEGER NOT NULL,
[...]
)

... d'ou ma remarque à propos du respect de la 1FN.
Pour moi, en règle générale c'est renvoi direct à l'étape modélisation.

Pour autant c'est ici 1 cas particulier, parce que ''n'' est unique et ''fini''.
La règle de gestion précise qu'il doit être tjours 4.
C'est pour ça que je me suis permis cet exercice de style.

Sinon voici 1 v° plus'' classique''

[mode ''mauvais esprit''

]
et puis traduit ds POET...

Code :

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

1
2
3
4
5
6
7
8
9
persistent class Bureau
{
Protected :

PtDate debut,
PtDate fin,
cset <Membre *>  membres
[...]
}

ç'est moins choquant non?
[/mode ''mauvais esprit'']

Quoiqu'il en soit merci pour la réponse.

**ypicot** · 22/11/2006, 00h35

Envoyé par fsmrel

On pourrait par exemple mettre en œuvre une entité-type Fonction (exercée par un membre dans un CA) et vérifier au niveau du SGBD les contraintes que vous avez modélisées.

Tout à fait d'accord. Pour moi, il s'agit plus d'une règle métier (et donc susceptible de changer comme cela est rappelé très justement), et donc ne devant pas figurer dans le modèle de la base.

Par contre, je suis moins d'accord avec le modèle de TheLeadingEdge :
- une association reliant 3 entités est souvent problématique à lire (ne serait-ce qu'au niveau des cardinalités) et à implémenter.
- avoir une cardinalité minimale de 1 de chaque coté d'une association pose des pb lors de la création des enregistrements, car en principe il faudrait créer les 2 entités en même temps. De plus, dans le modèle présenté, il est indiqué qu'un membre doit _forcément_ faire parti du bureau (cardinalité mini de 1).

J'aurais plutot modélisé ce sous-ensemble de la facon suivante :

Code :

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

entité membre     0,n    association fonction    4,4   entité bureau

L'entité bureau contenant les dates de début et de fin. Il n'y a pas d'attribut Annee car le bureau est changé _au moins_ une fois par an.

La cardinalité 4,4 devenant lors de l'implémentation une cardinalité 0,n, la répartition des 4 fonctions (1 président, 1 trésorier, ...) étant vérifiée par l'applicatif.

Yvan

**fsmrel** · 22/11/2006, 01h59

Bonsoir,

TheLeadingEdge a écrit :

1 table comme ça ...

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14

CREATE TABLE CA  
(
debut		      DATE	NOT NULL,
fin          	DATE    NOT NULL,
president	INTEGER NOT NULL,
secretaire 	INTEGER NOT NULL,
tresorier	INTEGER NOT NULL,
administrateur	INTEGER NOT NULL,
PRMARY KEY (DATEDEDEBUT, DATEDEFIN),
FOREIGN KEY (president) REFERENCES MEMBRE (IDMEMBRE),
[...]
)

... n'est qu'1 façon déguisée d'écrire ça ...

Code :

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

1
2
3
4
5
6
7
8
CREATE TABLE CA  
(
debut	     DATE	NOT NULL,
fin          DATE       NOT NULL,
idMembre [n]	INTEGER NOT NULL,
[...]
)

... d'ou ma remarque à propos du respect de la 1FN.

Je comprends. Le problème est qu’au sens de Merise (donc de ce forum), il n’est pas possible de proposer le type ARRAY (à vérifier auprès de Nanci). Au niveau logique, le standard SQL:1999 le permet, mais timidement, puisqu’il s’agit d’une fonctionnalité qui n’est pas intégré au Core SQL (même chose semble-t-il concernant SQL:2003).

En outre, avec la 1ère instruction Create Table, vous garantissez l’intégrité référentielle, mais avec le tableau, comment faites-vous ?

Pour moi, en règle générale c'est renvoi direct à l'étape modélisation.

Heu... De quelle étape s’agit-il ? Conceptuelle ? Logico-relationnelle ? Voilà une ellipse ou un enthymème qui échapperont à ceux qui comme Sahrrouman, débutent en modélisation. Essayons de rester didactiques...

Pour autant c'est ici 1 cas particulier, parce que ''n'' est unique et ''fini''.
La règle de gestion précise qu'il doit être tjours 4.
C'est pour ça que je me suis permis cet exercice de style.

Soit ! Mais au risque de me répéter, je rappelle que les règles d’une entreprise évoluent est que ce qui vaut 4 aujourd’hui vaudra autre chose demain : il est de notre devoir de conseiller aux plus jeunes de modéliser en sorte que leur système puisse évoluer de la façon la plus transparente (reportez-vous aux pièces que j’ai jointes dans mon message du 20 novembre).

Sinon voici 1 v° plus'' classique''

Voilà effectivement une approche plus sage. Néanmoins :

Concernant la cardinalité 1,n entre Membre et Fonction : remplacer par 0,n car tous les membres ne participent pas au bureau.

Cardinalité 1,1 entre Année et Bureau : une année participe une fois et une seule à une rencontre dans la relation Bureau, d'où au niveau relationnel (clé soulignée) :

Bureau (annee , idMembre, idFonction)

Autrement dit, pour une année donnée, le bureau est constitué d’un seul membre ayant une fonction unique...

[mode ''mauvais esprit'' ]
et puis traduit ds POET...
[Code]

persistent class Bureau
{
Protected :

PtDate debut,
PtDate fin,
cset <Membre *> membres
[...]
}

ç'est moins choquant non?
[/mode ''mauvais esprit'']

C’est moins choquant, mais nous ne sommes peut-être plus (ou pas encore) dans le forum qui va bien...

Désolé pour toutes ces remarques...

Allo, Sahrrouman, arrivez-vous à accrocher ?

**TheLeadingEdge** · 22/11/2006, 07h29

Envoyé par ypicot

De plus, dans le modèle présenté, il est indiqué qu'un membre doit _forcément_ faire parti du bureau (cardinalité mini de 1).

Dsl, c'est AMC qui remet 1,n quand on édite la relation. J'avais pas fait attention. J'ai corrigé le schéma.

Année est 1 identifiant pour éviter de mette les 2 dates en PK C'est tout. C'est juste plus parlant qu'une séquence, et se sera moins ''gros'' ds la table ''bureau''.

[edit]

Envoyé par fsmrel

Cardinalité 1,1 entre Année et Bureau : une année participe une fois et une seule à une rencontre dans la relation Bureau, d'où au niveau relationnel (clé soulignée) :

Bureau (annee , idMembre, idFonction)
Autrement dit, pour une année donnée, le bureau est constitué d’un seul membre ayant une fonction unique...

euh ... non. Les PK vont migrer.
La PK sera composée des 3 FK.

Code :

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

1
2
3
4
(...) primary key (IDFONCTION, IDMEMBRE, ANNEE),
foreign key (IDFONCTION) references FONCTION (IDFONCTION),
foreign key (IDMEMBRE) references MEMBRE (IDMEMBRE),
foreign key (ANNEE) references ANNEE (ANNEE)

[/edit]

**Sahrrouman** · 22/11/2006, 10h11

Effectivement, je suis un peu perdu, vous etes parti dans des débats que je ne peux pas encore comprendre ^^

Quoi qu-il en soit, j'ai quasiment fini le code de création des tables. Je vais vous le montrer tout à l'heure et j'aimerais avoir votre avis.

**Sahrrouman** · 22/11/2006, 10h17

CREATE TABLE DONATEURS (
NUMDON INT NOT NULL,
DTYPE CHAR(10) CHECK (VALUE (DTYPE) IN ('PRIVE','PUBLIC')),
DONNOM CHAR(15),
DONPRENOM CHAR(15),
ADRESS CHAR(30),
CP INT,
VILLE CHAR(20)
PRIMARY KEY (NUMDON));

/*INSERT INTO DONATEURS VALUES (0003,'PUBLIC','DE LA FORET','JEAN','36 rue preschez',92210,'saint cloud');*/

CREATE TABLE DONS (
DNUM INT NOT NULL,
DDATE DATE,
MONTANT INT,
TRANSAC CHAR(8) CHECK (VALUE (TRANSAC) IN ('CHEQUE','LIQUIDE','VIREMENT')),
ORIGINE CHAR(8) CHECK (VALUE (ORIGINE) IN ('MAILING','RECU','CHANTIER','INCONNUE')),
DATEENVOI DATE,
NUMDON INT NOT NULL,
PRIMARY KEY (DNUM),
FOREIGN KEY (NUMDON) REFERENCES DONATEURS(NUMDON));

CREATE TABLE MEMBRES (
NUMMEMB INT NOT NULL,
NOMMEMBRE CHAR(15),
PRENOMMEMBRE CHAR(15),
MAIL CHAR(50),
TEL INT,
COTISATION CHAR(10),
NUMCHANT INT NOT NULL,
NUMDON INT NOT NULL,
PRIMARY KEY (NUMMEMB),
FOREIGN KEY (NUMCHANT) REFERENCES CHANTIER (NUMCHANT),
FOREIGN KEY (DNUM) REFERENCES DONS (DNUM));

CREATE TABLE CHANTIER (
NUMCHANT INT NOT NULL,
VILLAGE CHAR(20),
PAYS CHAR(20),
TYPEBAT CHAR(10) CHECK IN TYPEBAT ('ECOLE','LOGEMENT','RENOVATION','PISCINE'),
PARTENAIRE CHAR(20),
DATEDBT DATE,
DATEFIN DATE,
PRIMARY KEY (NUMCHANT));

CREATE TABLE CONSEIL (
NUMCONSEIL INT NOT NULL,
DBTCONSEIL DATE,
FINCONSEIL DATE,
PRIMARY KEY (NUMCONSEIL));

CREATE TABLE PARTICIPE (
NUMCHANT INT NOT NULL,
NUMMEMB INT NOT NULL,
CHEFCHANTIER CHAR(3) CHECK IN CHEFCHANTIER ('OUI','NON'),
FOREIGN KEY (NUMCHANT) REFERENCES CHANTIER (NUMCHANT)
FOREIGN KEY (NUMMEMB) REFERENCES MEMBRES (NUMMEMB));

CREATE TABLE FAITPARTIE (
NUMMEMB INT NOT NULL,
NUMCONSEIL INT NOT NULL,
FONCTION CHAR(15) CHECK IN FONCTION ('PRESIDENT','TRESORIER','SECRETAIRE','ADMINISTRATEUR'),
FOREIGN KEY (NUMCONSEIL) REFERENCES CONSEIL (NUMCONSEIL)
FOREIGN KEY (NUMMEMB) REFERENCES MEMBRES (NUMMEMB));

Voila je sais pas trop ou il faut mettre NOT NULL encore. Mais sinon je pense que c'est un bon début au vu du sujet, qu'en pensez vous ?

**fsmrel** · 22/11/2006, 12h53

Bonjour,

Sahrrouman, j'ai regardé rapidement vos Create Table : c'est pas mal. Attention toutefois, vous avez conservé un lien direct entre Membre et Chantier (attribut NUMCHANT). Le lien est déjà établi par l'entité associative Participe (qui est peut-être porteuse de dates).

Je reviendrai sur l'identification (par exemple, un membre EST un donateur, la clé primaire (et simultanément étrangère) de MEMBRE est celle de DONATEUR (en passant, vous pouvez mettre au singulier le nom des entités-types (donc des tables, par contrecoup) car MEMBRE symbolise les propriétés d'un membre et non pas d'une collection de membres).

On reviendra sur les valeurs nulles, sujet délicat, ce sont des sables mouvants.

TheLeadingEdge a écrit :

fsmrel a écrit :
Cardinalité 1,1 entre Année et Bureau : une année participe une fois et une seule à une rencontre dans la relation Bureau, d'où au niveau relationnel (clé soulignée) :

Bureau (annee, idMembre, idFonction)
Autrement dit, pour une année donnée, le bureau est constitué d’un seul membre ayant une fonction unique...

euh ... non. Les PK vont migrer.
La PK sera composée des 3 FK.

La PK ne peut-être composée des 3 FK que lorsqu'au niveau conceptuel, les 3 cardinalités des pattes de Bureau sont 0,N ou 1,N.

Power AMC n'est cohérent, puisque tel n'est pas le cas. Si vous supprimiez la patte par exemple entre Bureau et Fonction, il devrait selon son raisonnement oter une seule FK de la PK et conserver le couple {année, IdMembre}, or la PK devient cette fois-ci singleton (et Power AMC retrouve la raison).

En tout cas l'association est sur la bonne voie. A ce soir.

**fsmrel** · 23/11/2006, 16h17

Bonjour Sahrrouman

Du nom des entités-types

Un nom d’entité-type est à mettre au singulier. L’entité-type DONATEUR est une abstraction, elle symbolise chaque donateur. On peut encore dire que DONATEUR est un prédicat au sens de la logique, les occurrences de l’entité-type étant les propositions vraies obtenues du prédicat :

Le donateur 3, de la catégorie Public, dont le prénom est Jean et le nom de La Forêt, habite 36 rue Preschez, dans la commune Saint-Cloud, dont le code postal est 92210.

Le donateur 7, de la catégorie Public, etc.

Table Membre : erreur de connexion

Je suppose que c’est par distraction que vous avez établi un lien de référence de MEMBRE vers DON. Le lien va en réalité de MEMBRE vers DONATEUR (un membre est un donateur et n’est pas la propriété d’un don).

Identification

En complément de ce que je viens d’écrire, un membre n’entre pas dans la composition d’un donateur : un membre EST un donateur. Au niveau logico-relationnel, la clé primaire (et simultanément étrangère) de MEMBRE est alors par définition celle de DONATEUR :

Code :

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

1
2
3
4
5
6
7
8
CREATE TABLE MEMBRE (
NUMDON INT NOT NULL,
NOMMEMBRE CHAR(15),
...,
PRIMARY KEY (NUMDON),
FOREIGN KEY (NUMCHANT) REFERENCES CHANTIER (NUMCHANT),
FOREIGN KEY (NUMDON) REFERENCES DONATEUR (NUMDON));

Ceci a un impact sur les tables satellite où il est fait mention de NUMMEMB, qu’il faut remplacer par NUMDON (nom d’attribut ambigu par ailleurs, source de confusions...)

Identification relative

Un don n’est jamais qu’une propriété multivaluée d’un donateur, on dit que l’entité-type DON est une entité-type faible (weak entity). En principe, son identifiant est relatif à celui de DONATEUR :

Code :

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

1
2
3
4
5
6
7
8
CREATE TABLE DON (
NUMDON INT NOT NULL,
DNUM INT NOT NULL,

...
PRIMARY KEY (NUMDON, DNUM),
FOREIGN KEY (NUMDON) REFERENCES DONATEUR(NUMDON));

La numérotation de DNUM redémarre à 1 pour chaque donateur. L’intérêt pratique de l’identification relative est déterminant au niveau opérationnel, mais ceci est un autre sujet.

Valeurs nulles

Il s’agit d’un sujet que peu de monde approfondit alors que les valeurs nulles peuvent avoir des effets dévastateurs, engendrer des anomalies qu’on ne soupçonne pas. Il y a eu des débats terribles chez les théoriciens à ce sujet (logique ternaire appliquée aux bases de données). La prudence recommande d’éviter.

Ainsi, dans votre message du 19 novembre dernier, vous écrivez :

Pour les membres, on conserve aussi éventuellement une 2ieme adresse avec un mail et un téléphone.

Personnellement, je n’hésite pas et je mets en œuvre une entité-type TRUC dépendant de MEMBRE pour ces propriétés :

MEMBRE--0,1----------(1,1)--TRUC

Au niveau tabulaire, la clé primaire de TRUC est la même que celle de MEMBRE et cette clé est en même temps clé étrangère.

Un conseil : réexaminez dans chaque table, chaque attribut susceptible de prendre la valeur nulle, en examinant la possibilité d'utiliser une valeur par défaut.

Remarques diverses

Format des noms et autres chaînes de caractères :

Table DONATEUR, attribut DONNOM : vous avez prévu une limite de 15 caractères : nous ne sommes plus en 1960 avec des disques à 5 MO, prévoyez large, d'autant plus que les SGBD pour leur part savent compresser les données (espérons-le). Ceci vaut pour ADRESS etc.

L’attribut CP n’est pas nécessairement de type numérique (voyez la Corse).

**Sahrrouman** · 24/11/2006, 02h12

Envoyé par fsmrel

Je suppose que c’est par distraction que vous avez établi un lien de référence de MEMBRE vers DON. Le lien va en réalité de MEMBRE vers DONATEUR (un membre est un donateur et n’est pas la propriété d’un don).

Oui effectivment, petite erreur de ma part. j'ai corrigé comme ceci :

Code :

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
CREATE TABLE DONATEUR (
	NUMDON			INT NOT NULL
 	DTYPE           CHAR(10) CHECK (VALUE (DTYPE) IN ('PRIVE','PUBLIC')),
	DONNOM			CHAR(15),
	DONPRENOM		CHAR(15), 
	ADRESS			CHAR(30),
	CP              INT,
	VILLE 			CHAR(20),
	PRIMARY KEY (NUMDON));
	
CREATE TABLE DON (
	DNUM			INT NOT NULL,
	DDATE			DATE,
	MONTANT 		INT,
	TRANSAC    		CHAR(8) CHECK (VALUE (TRANSAC) IN ('CHEQUE','LIQUIDE','VIREMENT')),
	ORIGINE         CHAR(8) CHECK (VALUE (ORIGINE) IN ('MAILING','RECU','CHANTIER','INCONNUE')),
	DATEENVOI	    DATE,
	NUMDON          INT NOT NULL,
	PRIMARY KEY (DNUM),
	FOREIGN KEY (NUMDON) REFERENCES DONATEUR(NUMDON));
	
CREATE TABLE MEMBRE (
	NUMMEMB 		INT NOT NULL,
	NOMMEMBRE  		CHAR(15),
	PRENOMMEMBRE	CHAR(15),
	MAIL            CHAR(50),
	TEL				INT,
	COTISATION		CHAR(10),
	NUMDON          INT,
	PRIMARY KEY (NUMMEMB),
	FOREIGN KEY (NUMDON) REFERENCES DONATEUR (NUMDON),
	FOREIGN KEY (DNUM) REFERENCES DON (DNUM));

Concernant l'identification, je ne vois pas les choses comme vous ! Pour moi, un membre est ou n'est pas donateur tout comme un donateur peux être un membre ou pas. Le texte dit que pour faire partie de l'assos il faut avoir au moin participé a 1 chantier. Et un membre qui cotise fait des dons, oui MAIS un membre ne cotise pas forcément.
Par conséquent la table membre a une clé étrangère qui est clé primaire de la table des donateurs. Ce qui correspond à NUMDON.

Il est vraie que les noms et types des attributs n'est pas trés bien choisi, j'améliorerai cela.

**fsmrel** · 24/11/2006, 16h30

Bonjour Sahrrouman,

Remarque préalable.

Envoyé par Sahrrouman

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
CREATE TABLE MEMBRE (
       NUMMEMB        INT NOT NULL,
       NOMMEMBRE      CHAR(15),
       PRENOMMEMBRE   CHAR(15),
       MAIL           CHAR(50),
       TEL            INT,
       COTISATION     CHAR(10),
       NUMDON         INT,
       PRIMARY KEY (NUMMEMB),
       FOREIGN KEY (NUMDON) REFERENCES DONATEUR (NUMDON),
       FOREIGN KEY (DNUM) REFERENCES DON (DNUM));

Attention, la référence à CHANTIER a disparu et celle à DON est toujours là. Je suppose qu’il s’agit d’un problème de copier/coller.

Venons-en aux choses sérieuses. Vous contestez le fait qu’un membre soit un donateur particulier, parce que contrairement aux autres, il participe aux chantiers, voire aux conseils. Acceptons. Cela dit, vous avez écrit :

« Les cotisations des membres sont considérées comme des dons »

D’où l’on peut inférer qu’un membre a un petit côté donateur.

Maintenant, si l’on remplace le terme Donateur par celui de Cotisant, on peut retrouver la nature de la relation : un membre EST un cotisant particulier (parce qu’il participe aux chantiers etc.) Mais vous me direz qu’un donateur n’est pas un cotisant. Acceptons encore. Dans ces conditions, puisqu'un membre ne doit pas être confondu avec un donateur et réciproquement, un membre et un donateur sont nécessairement des personnes différentes, ce qu’impose à son tour la sacro-sainte règle « One fact, one place » (ce qui n’empêche pas qu’un membre fasse des dons, cf. ci-dessous).

Mais alors, quelle est la nature de la relation actuellement établie entre un membre et un donateur ? Quelle en est la sémantique ? Celle-ci doit être résumée en un verbe, car il ne faut pas oublier que nous sommes sur un forum Merise et comme le rappelle Nanci qui cite Boileau : « Ce que l'on conçoit bien s'énonce clairement, Et les mots pour le dire arrivent aisément ». Si au final un membre et un donateur n’entretiennent pas de relation clairement justifiée, alors il faut supprimer la relation actuelle.

En conséquence, avant même de lui prévoir une possible deuxième adresse, il faut définir l’adresse d’un membre (ce qui n’est manifestement pas fait). Il faut aussi définir la structure d’accueil pour tout ce qui concerne les reçus fiscaux, etc., toutes choses actuellement prévues uniquement pour les donateurs mais susceptibles de concerner les membres.

Par ailleurs, si l’on est contraint à couper le lien ténu entre donateur et membre, les entités-types Donateur et Don sont complètement isolées des autres entités-types du MCD : cela est révélateur d’une modélisation incomplète, sinon, si tout est en place, du MCD on doit logiquement en faire deux (ce qui se traduit à terme par deux bases de données).

Vous me direz qu’un membre peut faire des dons, auquel cas vous pouvez trouver une relation entre Membre et Donateur, mais je rappelle que la sémantique de cette relation doit être précisée avec rigueur. En tout cas, il y a des effets secondaires : je répète que la même personne est à considérer comme deux personnes distinctes, à identifier une 1ère fois comme membre (NumMemb) et une 2ème fois comme donateur (NumDon) : indépendamment de la contradiction sémantique qui s’installe, vous partez à la rencontre de graves problèmes de redondance à maintenir (l’adresse du donateur doit être égale à celle du membre, etc.) Je rappelle encore que l’on enfreint la sacro-sainte règle « One fact, one place ».

Vous pourriez résoudre ces problèmes en définissant une entité-type Personne qui soit un surtype, dont Donateur et Membre seraient les sous-types et servant surtout à factoriser les propriétés communes, mais les sous-types ne seront pas forcément disjoints, ce qui pose d’autres problèmes.

Avec le système que je vous avais proposé, en comptant un membre comme un donateur particulier participant à des chantiers, les problèmes de redondance et autres disparaissaient.

Je suis un peu marqué par le fait que j’ai eu à manipuler des tables comportant de l’ordre de la centaine de millions de lignes. Vous me direz que volumétrie et modélisation conceptuelle n’ont rien à voir, mais l’homme de terrain que je suis a la preuve que si l’on n’en tient pas compte dès le départ, ça peut être la cata quant à la performance du système.

Maintenant, comme dit Laspalès à Chevallier : c’est vous qui voyez...

**TheLeadingEdge** · 25/11/2006, 10h28

Bonjour,

Cardinalité 1,1 entre Année et Bureau :

1 (1,1) ds 1 relation n-aire...

Holala, j'ai besoin de vacances moi.
Dsl, j'étais resté sur mon idée de 1 ligne par bureau... Et comme effectivement AMC à généré le MPD que j'imaginais, je n'ai pas vu l'erreur sur le MCD.

Envoyé par Sahrrouman

Concernant l'identification, je ne vois pas les choses comme vous ! Pour moi, un membre est ou n'est pas donateur tout comme un donateur peux être un membre ou pas.

Je suis globalement d'accord avec fsmrel concernant la relation donateur/membre. 1 ''Membre'' est 1 ''Donateur'' qui a fait 1 ''Chantier''. On peut considérer ''Membre'' comme 1 ''surcharge'' de ''Donateur''.

Les cotisations des membres sont considérées comme des dons.

On pourrait faire 1 héritage, mais autant faire directement 1 relation puisque de ttes façons c'est comme ça que ça va se terminer.

Je changerai aussi

Code :

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

CHEFCHANTIER CHAR(3) CHECK IN CHEFCHANTIER ('OUI','NON'),

pour 1 relation.

Par contre si on ne veut pas perdre des DF, je persiste pour la ternaire bureau/membre/fonction.

A +

**fsmrel** · 25/11/2006, 19h01

Bonjour Sahrrouman, bonjour TheLeadingEdge,

A propos des chantiers et des CA.

Envoyé par TheLeadingEdge

Je changerai aussi

Code :

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

1
2
CHEFCHANTIER CHAR(3) CHECK IN CHEFCHANTIER ('OUI','NON'),

pour 1 relation.

Le MCD que vous proposez en pièce jointe comporte en ce sens 2 relations : Participe et Dirige. Mais alors se pose la question : un membre qui dirige un chantier peut-il ne pas y participer ? Si la réponse est affirmative, la relation Dirige est justifiée. Si un membre participe nécessairement au chantier qu’il dirige, le choix de Sahrrouman est suffisant, sinon si l’on conserve les deux relations, vous conviendrez qu’il faut établir entre celles-ci une contrainte (du genre inclusion). D’autre part, les relations pourraient être datées : on déboulerait alors sur la cohérence des dates entre Participe et Dirige (et bien entendu de la cohérence par rapport aux dates de début et de fin de chantier).

Envoyé par TheLeadingEdge

si on ne veut pas perdre des DF, je persiste pour la ternaire bureau/membre/fonction

Il est un fait que si l’on considère Fonction comme une simple propriété de l’association entre Membre et Bureau (alias CA), on passe à côté de quelque chose. Il est vrai que lors de la dérivation du MCD en MLD, le couple {IdBureau, IdMembre} est une clé candidate pour la table FaitPartie (Participe dans votre MCD) :
La DF {IdBureau, IdMembre} —> IdFonction est bien vérifiée.
Mais je concède que cela n’est pas suffisant si le bureau comporte au plus un membre par type de membre (un seul président, un seul secrétaire, un seul trésorier et un seul administrateur).
En effet, on ne garantit pas la DF {IdBureau, IdFonction} —> IdMembre , en vertu de quoi une clé candidate alternative {IdBureau, IdFonction} doit être ajoutée manuellement au niveau du MLD (si l’AGL le permet) ou lors de la génération du code SQL, lequel doit au final ressembler à ceci :

Code :

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

1
2
3
4
5
6
7
8
9
10
  CREATE TABLE Faitpartie
  (
    IdBureau    INTEGER          NOT NULL,
    IdMembre    INTEGER          NOT NULL,
    IdFonction  INTEGER          NOT NULL,
    CONSTRAINT  FaitpartieCK1   PRIMARY KEY  (IdBureau, IdMembre),
    CONSTRAINT  FaitpartieCK2   UNIQUE  (IdBureau, IdFonction),
   ...
  )

Personnellement, je suis pour la ternaire bureau/membre/fonction que vous préconisez. Une question quand même : à partir de cette ternaire, est-ce que l’AGL que vous avez utilisé (WIN’Design, Power AMC, ...) permet la propagation des contraintes (CIF) définies au niveau conceptuel jusqu’à la production du code ci-dessus, sans intervention manuelle ?
Si oui, bravo, dans le cas contraire la ternaire n’a pas grande valeur ajoutée, sinon au plan documentaire.

Gestion d'une association d'aide au développement [MCD]

Schéma

Discussions similaires

Partager

Partager