Discussion :

[zkvm45]

Bonjour, j'ai beaucoup cherché et je souhaiterais savoir s'il est possible de modéliser ce que je vous explique ci-après avec des contraintes d'inclusion.

Je souhaite gérer les droits d’utilisateurs et ceux des groupes d’utilisateurs dans une application qui permet de voter, si on en a le droit, les dates d’une réunion pour que celle-ci se réalise au meilleur moment.

J’ai simplifié ma base de données pour vous faire comprendre plus facilement mon problème.

Le droit de vote est donné si la personne est inscrite à la réunion.



Une personne peut voter pour la date d’une réunion uniquement si cette personne est inscrite à cette réunion. J’ai supposé faire une contrainte d’inclusion. (je ne sais pas si elle est bien modélisée sur le mcd)

Mais ce qui n'est pas modélisé :
je souhaite également gérer les groupes de personnes : Une personne appartient à un groupe, elle peut également voter pour la date d’une réunion si son groupe est inscrit à la réunion en question.

C’est plus simple et moins lourd de gérer les groupes de personnes dans une application mais je dois quand même scinder en deux les droits pour une personne et pour un groupe car parfois je peux inscrire des personnes sans qu’elles appartiennent à un groupe.

Comment modéliser cette contrainte liée à l’inscription d’un groupe à une réunion pour donner le droit aux personnes appartenant à ce groupe de pouvoir voter pour cette réunion ?

Merci d'avance

[Richard_35]

Bonjour Zkvm45,

Très intéressant !...

Il me semble que ce cas montre que tout n'est pas, forcément, modélisable simplement.

Suggestion :

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
Reunion -0,n---[Inscrire]---0,n----------------- Key -0,1---[Identifier]---(1,1)- Personne
                   |                              |                                  |
                  0,n                             |                                 0,n
                   |                              |                                  |
                   |                              |                             [Appartenir]--
                   |                              |                                  |       |
                   |                              |                                 1,n      |
                   |                              |                                  |       |
                   |                              ----0,1---[Identifier]---(1,1)- Groupe     |
                   |                                                                         |
               [Proposer]---0,n---------------------------------------------------------------
                   |
                  0,n
                   |
                 Date

ce qui devrait donner :

Reunion(IdReunion, ...)
Key(IdKey, ...)
Personne(IdKey, ...)
Groupe(IdKey, ...)
Date(Date, ...)

Inscription(IdInscription, #IdReunion, #IdKey (personne ou groupe), ...) ==> {#IdReunion, #IdKey} unique
GroupePersonne(#IdKeyGroupe, #IdKeyPersonne, ...)

Proposition(#IdInscription, #IdKey (personne), #Date, ...) ==> c'est toujours une personne qui fait une proposition de date ; le contrôle de l'appartenance de cette personne non inscrite à un groupe inscrit peut s'effectuer par un trigger

Le droit de vote est donné si la personne est inscrite à la réunion .../...
.../... si son groupe est inscrit à la réunion en question .../...

==> résolu par Key (distributeur d'identifiant).

Une personne appartient à un groupe, elle peut également voter pour la date d’une réunion si son groupe est inscrit à la réunion en question.

==> résolu par le trigger.


A voir... et surtout à tester...

[CinePhil]

Ce genre de truc n'est généralement solvable que par des triggers ou des tests dans l'application.

Mais revenons aux règles de gestion et modélisons progressivement...

1) Une personne peut appartenir à plusieurs groupes et un groupe possède de une à plusieurs personnes.

personne -0,n----appartenir----1,n- groupe

2) Une personne peut être inscrite à plusieurs réunions et une réunion peut voir inscrire plusieurs personnes.

personne -0,n----inscrire----0,n- reunion

3) Une réunion peut proposer plusieurs dates et une date peut être proposée pour plusieurs réunions.

reunion -0,n----proposer----0,n- date

Nota : cardinalités différentes de votre MCD !

4) Une personne inscrite à une réunion peut voter pour une date proposée de réunion et une date proposée de réunion peut avoir le vote de plusieurs personnes.

Là, on transforme les associations 2 et 3 en entités associatives :

personne -0,n----inscrire----(1,1)- inscription_reunion -(1,1)----concerner----0,n- reunion

reunion -0,n----proposer----(1,1)- proposition_date_reunion -(1,1)----concerner----0,n- date

Les cardinalités entre parenthèses indiquent une identification relative, ce qui donnera une clé primaire composée de deux clés étrangères, comme dans la table associative qui aurait été issue de l'association de départ.

On peut maintenant associer les deux entités associatives :
inscription_reunion -0,1----voter----0,n- proposition_date_reunion

Mais ce qui n'est pas modélisé :
je souhaite également gérer les groupes de personnes : Une personne appartient à un groupe, elle peut également voter pour la date d’une réunion si son groupe est inscrit à la réunion en question.

Même principe : commençons par modéliser l'inscription du groupe à une réunion.

5) un groupe peut être inscrit à plusieurs réunions et une réunion peut voir inscrire plusieurs groupes.

groupe -0,n----inscrire----0,n- reunion

6) Une personne appartenant à un groupe inscrit à une réunion peut voter pour une date proposée pour la réunion et une date proposée pour une réunion peut avoir le vote d'une personne appartenant à un groupe inscrit à la réunion.

Là par contre, je pense qu'il faut une contrainte d'inclusion reliant le groupe inscrit, la personne appartenant au groupe et le vote. Et donc il faudra en BDD un trigger ou peut-être une contrainte CHECK.

[zkvm45]

Merci pour vos réponses,

Pour Richard_35 :

Je ne comprends pas les liaisons entre les relations : inscrire --- proposer et proposer --- appartenir. On m'a toujours expliqué qu'une relation s'effectuait entre des entités, pouvez vous m'expliquer ?

Pour l'entité Key, le principe m'a l'air bien mais n'est-ce pas plus simple au final de la décomposer en 2 relations :
personne -0,n----inscrire_personne----0,n- réunion
groupe -0,n----inscrire_groupe----0,n- réunion
Je n'ai pas compris l'objectif de les réunir en une seule table Key

Pour CinePhil :

Merci pour la reprise à zero, j'ai simplifié mon MCD pour me focaliser uniquement sur la gestion du groupe mais dans le MCD complet je gère bien la gestion de réunions et suggestion de dates/lieux.

Je pense créer la relation :

groupe -0,n----inscrire----0,n- réunion
avec la contrainte d'inclusion qui sera gérée par trigger.

Merci beaucoup

[Richard_35]

Bonjour Zkvm45,

On m'a toujours expliqué qu'une relation s'effectuait entre des entités, pouvez vous m'expliquer ?

==> c'est vrai. En l’occurrence, ces associations deviendraient des entités.

Pour l'entité Key, le principe m'a l'air bien mais n'est-ce pas plus simple au final de la décomposer en 2 relations :
personne -0,n----inscrire_personne----0,n- réunion
groupe -0,n----inscrire_groupe----0,n- réunion

==> ce schéma générera deux tables associatives :

Inscription_personne(#IdPersonne, #IdReunion, ...)
Inscription_groupe(#IdGroupe, #IdReunion, ...)

Je n'ai pas compris l'objectif de les réunir en une seule table Key

==> cela te permet de n'avoir qu'une seule table Inscription :

Key(IdKey, ...)
Personne(IdKey, ...)
Groupe(IdKey, ...)
Inscription(IdInscription, #IdReunion, #IdKey (personne ou groupe), ...) ==> {#IdReunion, #IdKey} unique