Discussion :

[Mélodie_et_rythmes]

Bonjour,
J'ai un projet de réalisation d'un BD à l'aide d'Access 2007 et qui porte sur la gestion d'une association.

L'association dispose d'un gestionnaire qui est salarié à part entière.
et d'un réseau de bénévoles qui interviennent de manière ponctuelle.

Ces personnes interviennent pour animer des ateliers proposés par l'association.

J'ai créé une table "employé" qui liste l'ensemble des intervenants (bénévoles et gestionnaire).
J'ai prévu un enregistrement pour le gestionnaire et des enregistrements "bidons" pour les bénévoles (on a pas besoin de suivre les bénévoles de façon nominative).

Par exemple :
>
- ID : 1111
- Nom : Dupont (le gestionnaire)
>
- ID : 1112
- Nom : Bénévole 1
>
- ID : 1113
- Nom : Bénévole 2

Je n'arrive pas à savoir comment modéliser ça au niveau MCD et MLD.
Je ne vois pas comment distinguer le gestionnaire des bénévoles. Faut-il prévoir une relation réflexive ?

Merci d'avance pour vos retours.

[f-leb]

Bonjour,

mettre des noms "bidons" n’est pas vraiment une bonne idée, autant laisser le nom comme chaîne vide ( = "" ).

Tu peux aussi aller un peu plus loin en conservant l’historique des gestionnaires, par exemple :
Employe(idEmp, NomEmp, …)
Employe-1------∞-Gestionnaire (dans la fenêtre des relations d’Access)
Gestionnaire(#idEmp, DateDepuis, salaire, …)

[DateDepuis] est la date où l’employé a pris la fonction de gestionnaire et tu en profites pour ajouter le salaire et autres informations utiles sur le gestionnaire.

Tu rajoutes éventuellement une contrainte "sans doublon" sur [DateDepuis], si à une date donnée on ne peut nommer qu’un seul nouveau gestionnaire.
Le gestionnaire en cours correspond alors à celui avec la [DateDepuis] la plus récente.

Le MCD (façon Merise) dont découle le schéma Access serait dans ce cas :
Employe---1,n---EtreGestionnaire(salaire,…)---0,n---Date

[JPhi33]

Bonjour Mélodie_et_rythmes,
(pseudo musical s'il en est !)

Je ne vois pas comment distinguer le gestionnaire des bénévoles. Faut-il prévoir une relation réflexive ?

Une relation réflexive signifierait qu'on associe les employés entre eux. Ce n'est donc pas la bonne solution. Ici, il s'agit de distinguer le gestionnaire des bénévoles.

La démarche a été correctement entamée en regroupant le gestionnaire et les bénévoles sous un même terme Employé car ils ont probablement des caractéristiques communes, par exemple animer des ateliers (association entre Employé et Atelier). Mais du coup, la distinction faite entre Gestionnaire et Bénévoles a disparu. D'où les difficultés à les faire rentrer dans la même boîte Employé : on veut connaître le nom du gestionnaire mais pas celui des bénévoles. Il y a probablement encore d'autres différences (à préciser).

Tout ceci indique qu'il faut spécialiser l'entité Employé en deux entités Gestionnaire et Bénévole. Gestionnaire contient une propriété Nom alors que Bénévole n'en contient pas. C'est ce qui fait leur différence. Plus besoin de noms "bidons" pour les bénévoles. Le concept de la spécialisation permet, grâce au mécanisme d'héritage, de faire partager le même identifiant aux trois entités. Ainsi :
- le gestionnaire a une occurrence dans Employé identifiée par l'ID 1111 et il a aussi une occurrence dans l'entité Gestionnaire identifiée (par héritage) par l'ID 1111, mais n'a pas d'occurrence dans l'entité Bénévole.
- le bénévole 1 a une occurrence dans Employé identifiée par l'ID 1112 et aussi une occurrence dans l'entité Bénévole identifiée (par héritage) par l'ID 1112, mais n'a pas d'occurrence dans l'entité Gestionnaire.


Ces entités sont liées par des associations de type "est un" :
- un gestionnaire "est un" employé
- un bénévole "est un" employé

[ Gestionnaire ]--1,1----(est un)----0,1--[ Employé ]
[ Bénévole ]--1,1----(est un)----0,1--[ Employé ]

"est un" peut s'entendre comme "est une sorte de".


Graphiquement, le lien "est un" est souvent représenté par une flèche à double trait orientée vers l'entité généralisée :

[ Gestionnaire ]===>[ Employé ]
[ Bénévole ]===>[ Employé ]

Au niveau logique, les tables issues du MCD sont :

Employé(Id_employé, ...)
Gestionnaire(#Id_employé, Nom, ...)
Bénévole(#Id_employé, ...)

[CinePhil]

Sémantiquement, j'appellerais ces employés plutôt des personnes car un employé bénévole, c'est un peu choquant !

Je trouve bizarre aussi de ne pas vouloir connaître le nom des bénévoles. Quel est alors l'intérêt de mémoriser X bénévoles ?

Il me semble au contraire que, puisque ces bénévoles ont une fonction d'animation au sein de l'association, celle-ci se doit d'enregistrer qui a animé quoi et quand, ne serait-ce qu'en terme de responsablité civile s'il y a un problème un jour.

[Mélodie_et_rythmes]

Sémantiquement, j'appellerais ces employés plutôt des personnes car un employé bénévole, c'est un peu choquant !

Je trouve bizarre aussi de ne pas vouloir connaître le nom des bénévoles. Quel est alors l'intérêt de mémoriser X bénévoles ?

Il me semble au contraire que, puisque ces bénévoles ont une fonction d'animation au sein de l'association, celle-ci se doit d'enregistrer qui a animé quoi et quand, ne serait-ce qu'en terme de responsablité civile s'il y a un problème un jour.

Merci pour ta réponse
L'intérêt, du moins comment je le conçois, réside au niveau de la gestion des autorisations :
Le bénévole pourra accéder à une appli aux droits restreints.
Le gestionnaire lui aura tous les droits.

Tu penses que ce n'est pas pertinent ?

[CinePhil]

Si c'est seulement pour une gestion des droits, autant gérer ça dans l'application :
- utilisateur non connecté a des droits restreints ;
- pour d'autres actions, il faut se connecter et seul le gestionnaire connaît le login et mot de passe de connexion.

Mais je t'incite à réfléchir à ce que j'ai écrit sur la responsabilité civile. Je trouve bizarre de confier l'animation d'une activité de l'association à quelqu'un sans le connaître. En cas d'accident, c'est le président qui va en taule !

[Mélodie_et_rythmes]

Bonjour Mélodie_et_rythmes,
(pseudo musical s'il en est !)

Une relation réflexive signifierait qu'on associe les employés entre eux. Ce n'est donc pas la bonne solution. Ici, il s'agit de distinguer le gestionnaire des bénévoles.

La démarche a été correctement entamée en regroupant le gestionnaire et les bénévoles sous un même terme Employé car ils ont probablement des caractéristiques communes, par exemple animer des ateliers (association entre Employé et Atelier). Mais du coup, la distinction faite entre Gestionnaire et Bénévoles a disparu. D'où les difficultés à les faire rentrer dans la même boîte Employé : on veut connaître le nom du gestionnaire mais pas celui des bénévoles. Il y a probablement encore d'autres différences (à préciser).

Tout ceci indique qu'il faut spécialiser l'entité Employé en deux entités Gestionnaire et Bénévole. Gestionnaire contient une propriété Nom alors que Bénévole n'en contient pas. C'est ce qui fait leur différence. Plus besoin de noms "bidons" pour les bénévoles. Le concept de la spécialisation permet, grâce au mécanisme d'héritage, de faire partager le même identifiant aux trois entités. Ainsi :
- le gestionnaire a une occurrence dans Employé identifiée par l'ID 1111 et il a aussi une occurrence dans l'entité Gestionnaire identifiée (par héritage) par l'ID 1111, mais n'a pas d'occurrence dans l'entité Bénévole.
- le bénévole 1 a une occurrence dans Employé identifiée par l'ID 1112 et aussi une occurrence dans l'entité Bénévole identifiée (par héritage) par l'ID 1112, mais n'a pas d'occurrence dans l'entité Gestionnaire.


Ces entités sont liées par des associations de type "est un" :
- un gestionnaire "est un" employé
- un bénévole "est un" employé

[ Gestionnaire ]--1,1----(est un)----0,1--[ Employé ]
[ Bénévole ]--1,1----(est un)----0,1--[ Employé ]

"est un" peut s'entendre comme "est une sorte de".


Graphiquement, le lien "est un" est souvent représenté par une flèche à double trait orientée vers l'entité généralisée :

[ Gestionnaire ]===>[ Employé ]
[ Bénévole ]===>[ Employé ]

Au niveau logique, les tables issues du MCD sont :

Employé(Id_employé, ...)
Gestionnaire(#Id_employé, Nom, ...)
Bénévole(#Id_employé, ...)

Moi c'est la maxime que j'aime bien
« Cela va sans dire... mais cela va mieux en le disant ! »

Je te remercie d'avoir pris la peine de répondre de manière complète et simple.
Je vais modéliser ta proposition et voir comment elle s'intègre dans ma BD.

Merci encore.

[Mélodie_et_rythmes]

Si c'est seulement pour une gestion des droits, autant gérer ça dans l'application :
- utilisateur non connecté a des droits restreints ;
- pour d'autres actions, il faut se connecter et seul le gestionnaire connaît le login et mot de passe de connexion.

Mais je t'incite à réfléchir à ce que j'ai écrit sur la responsabilité civile. Je trouve bizarre de confier l'animation d'une activité de l'association à quelqu'un sans le connaître. En cas d'accident, c'est le président qui va en taule !

Mais c'est ce qu'on souhaite
Trêve de plaisanterie : ta remarque est pertinente.

Je conserve donc la solution proposée plus haut puisque j'ai besoin de la distinction bénévole/gestionnaire et je renseigne les infos qui vont bien pour tous.

Merci pour ton aide.

[Mélodie_et_rythmes]

Bonjour,

mettre des noms "bidons" n’est pas vraiment une bonne idée, autant laisser le nom comme chaîne vide ( = "" ).

Tu peux aussi aller un peu plus loin en conservant l’historique des gestionnaires, par exemple :
Employe(idEmp, NomEmp, …)
Employe-1------∞-Gestionnaire (dans la fenêtre des relations d’Access)
Gestionnaire(#idEmp, DateDepuis, salaire, …)

[DateDepuis] est la date où l’employé a pris la fonction de gestionnaire et tu en profites pour ajouter le salaire et autres informations utiles sur le gestionnaire.

Tu rajoutes éventuellement une contrainte "sans doublon" sur [DateDepuis], si à une date donnée on ne peut nommer qu’un seul nouveau gestionnaire.
Le gestionnaire en cours correspond alors à celui avec la [DateDepuis] la plus récente.

Le MCD (façon Merise) dont découle le schéma Access serait dans ce cas :
Employe---1,n---EtreGestionnaire(salaire,…)---0,n---Date

Merci pour ta réponse et pour ta proposition de conserver l'historique. Je n'y avais pas pensé .

[Mélodie_et_rythmes]

Bonjour Mélodie_et_rythmes,
(pseudo musical s'il en est !)


Une relation réflexive signifierait qu'on associe les employés entre eux. Ce n'est donc pas la bonne solution. Ici, il s'agit de distinguer le gestionnaire des bénévoles.

La démarche a été correctement entamée en regroupant le gestionnaire et les bénévoles sous un même terme Employé car ils ont probablement des caractéristiques communes, par exemple animer des ateliers (association entre Employé et Atelier). Mais du coup, la distinction faite entre Gestionnaire et Bénévoles a disparu. D'où les difficultés à les faire rentrer dans la même boîte Employé : on veut connaître le nom du gestionnaire mais pas celui des bénévoles. Il y a probablement encore d'autres différences (à préciser).

Tout ceci indique qu'il faut spécialiser l'entité Employé en deux entités Gestionnaire et Bénévole. Gestionnaire contient une propriété Nom alors que Bénévole n'en contient pas. C'est ce qui fait leur différence. Plus besoin de noms "bidons" pour les bénévoles. Le concept de la spécialisation permet, grâce au mécanisme d'héritage, de faire partager le même identifiant aux trois entités. Ainsi :
- le gestionnaire a une occurrence dans Employé identifiée par l'ID 1111 et il a aussi une occurrence dans l'entité Gestionnaire identifiée (par héritage) par l'ID 1111, mais n'a pas d'occurrence dans l'entité Bénévole.
- le bénévole 1 a une occurrence dans Employé identifiée par l'ID 1112 et aussi une occurrence dans l'entité Bénévole identifiée (par héritage) par l'ID 1112, mais n'a pas d'occurrence dans l'entité Gestionnaire.


Ces entités sont liées par des associations de type "est un" :
- un gestionnaire "est un" employé
- un bénévole "est un" employé

[ Gestionnaire ]--1,1----(est un)----0,1--[ Employé ]
[ Bénévole ]--1,1----(est un)----0,1--[ Employé ]

"est un" peut s'entendre comme "est une sorte de".


Graphiquement, le lien "est un" est souvent représenté par une flèche à double trait orientée vers l'entité généralisée :

[ Gestionnaire ]===>[ Employé ]
[ Bénévole ]===>[ Employé ]

Au niveau logique, les tables issues du MCD sont :

Employé(Id_employé, ...)
Gestionnaire(#Id_employé, Nom, ...)
Bénévole(#Id_employé, ...)

Bonjour,
Je reviens vers vous suite à ma tentative de création du MLD sur Access 2010 en référence à la solution proposée par Phi33 et décrite ci-dessus.
J'ai créé 3 tables :
- Employe (ID_emp, nom_emp, prenom_emp, etc.)
- Benevole (ID_benev, ID_emp, nom_benev, prenom_benev, etc.)
- Gestionnaire (ID_gest, ID_emp, nom_gestv, prenom_gest, etc.)

Je n'arrive pas à établir la relation (de type un à un) entre gestionnaire et employe.
Access m'affiche ce msg d'erreur : Définition du champ non valide dans la définition de l'index ou de la relation.

La clé étrangère ID_emp au niveau de ma table gestionnaire est indexée sans doublons.
J'ai modifié en la passant à non-indexée et ça marche... sauf que c'est une relation 1 à plusieurs et non un à un.

Qu'est-ce que cela signifie ?

Merci d'avance pour vos réponses

[f-leb]

bonsoir,

plutôt comme sur l’image en pièce-jointe.

Si on se réfère aux règles de gestions énoncées par Jphi33 :

- un gestionnaire "est un" employé
- un bénévole "est un" employé

Et si on dit que bénévoles et gestionnaires ont chacun un nom&prénom, c’est seulement dans l’entité généralisée qu’il faut mettre les attributs nom&prénom.

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
T_Employe :
idEmp	NomEmp		…
1	f-leb			…
2	Mélodie&Rythmes	…
3	JPhi33			…
4	CinePhil		…


T_Benevole :
idEmp	…
1	…
3	…
4	…

T_Gestionnaire :
idEmp	Salaire	…
2	1 000 000

C’est toi le gestionnaire

Note aussi qu'il y a un forum Access pour des questions plus spécifiques à ce logiciel

[Mélodie_et_rythmes]

bonsoir,

plutôt comme sur l’image en pièce-jointe.

Si on se réfère aux règles de gestions énoncées par Jphi33 :


Et si on dit que bénévoles et gestionnaires ont chacun un nom&prénom, c’est seulement dans l’entité généralisée qu’il faut mettre les attributs nom&prénom.

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
T_Employe :
idEmp	NomEmp		…
1	f-leb			…
2	Mélodie&Rythmes	…
3	JPhi33			…
4	CinePhil		…


T_Benevole :
idEmp	…
1	…
3	…
4	…

T_Gestionnaire :
idEmp	Salaire	…
2	1 000 000

C’est toi le gestionnaire

Note aussi qu'il y a un forum Access pour des questions plus spécifiques à ce logiciel

Merci à tous pour votre aide
Bonne journée !