Discussion :

[sohiermdp]

Bonsoir à tous,

Actuellement en train de travailler sur la conception d'un site de vente, je cherche à modéliser les personnes décomposées en personnes physiques et personnes morales.

Mon problème porte sur l'entité utilisateur.
A mon sens, un utilisateur est une personne physique.

Cependant, une personne physique représente une personne morale.
Cette personne physique peut très bien détenir un compte client.

L'utilisateur peut (ou doit) être différent selon que la personne physique se connecte pour son compte client ou pour le compte de l'entreprise dont il est mandataire.
Au final, une personne physique peut donc posséder plusieurs utilisateurs, car il peut représenter plusieurs personnes morales.


PS : sur mon schéma, les cardinalités ne sont pas correctes. Ce que je cherche surtout c'est à placer correctement mon entité UTILISATEUR par rapport aux autres. Que pensez-vous de mon schéma ?

[fsmrel]

Bonsoir sohiermdp,

A mon sens, un utilisateur est une personne physique.

Auquel cas une personne physique peut être un utilisateur mais pas plusieurs (cf. votre MCD).

Au final, une personne physique peut donc posséder plusieurs utilisateurs

Comme vous avez écrit plus haut qu’un utilisateur est une personne physique, vous signifiez qu’une personne physique peut « posséder » plusieurs personne physiques... J’avoue que quelque chose m’échappe...

J’y verrais mieux si les comptes étaient modélisés en tant que tels :

Un personne peut être titulaire d’un ou plusieurs comptes ;
Un compte a exactement un titulaire (c'est-à-dire au moins un et au plus un).

Je prends note qu’une personne physique peut être mandataire pour plusieurs personnes morales.

Questions :

Une personne physique peut-elle avoir la signature pour plusieurs comptes d’une même personne morale ?
Un compte (d’une personne morale) fait-il l’objet du mandat d’une seule personne physique ? Possiblement de plusieurs ?

Remarque en passant : en modélisation, on spécialise les personnes plutôt qu’on ne les décompose.

[sohiermdp]

Je reprécise mon besoin :

• Une personne peut être une personne physique ou une personne morale
• Un client est une personne
• Une personne physique détient des comptes utilisateurs
• Une personne morale est représentée par une ou des personnes physiques
• Un compte utilisateur est utilisé pour se connecter à un compte client
• Une personne physique utilise un compte utilisateur pour se connecter au compte client d'une personne morale
• Une personne physique peut représenter plusieurs personnes morales

Je ne sais pas si je suis clair...

Ma problématique est d'offrir un moyen simple de connecter un utilisateur et de le renvoyer vers le bon espace en fonction de ses identifiants de connexion (compte perso, ou compte d'une personne morale pour lequel il a délégation)

[fsmrel]

Je suis désolé d’en revenir à des choses qui ne peuvent que vous paraître basiques, mais il vaut mieux perdre un peu de temps au départ plutôt que d’en perdre beaucoup ensuite et casser des MCD...

Quoi qu'il en soit, vous faites la distinction entre compte utilisateur et compte client, tout en précisant qu’un compte utilisateur permet de se connecter à un compte client, d'accord. Mais entre la compréhension des concepts qu’a le rédacteur (vous) et celle qu’en a le lecteur (les autres membres de Developpez, qui peuvent être actifs dans des secteurs bien différents du vôtre), il peut y avoir un fossé, des pièges donnant lieu des quiproquos fâcheux...

Ainsi, qu’est-ce qu’un compte client dans votre système ? Pourriez-vous donner des exemples ?

Je reformule les questions de mon message précédent :

— Une personne physique peut-elle mandatée pour plus d’un compte (client) d’une même personne morale ?
— Un compte client (d’une personne morale) fait-il l’objet du mandat d’une seule personne physique ? Possiblement de plusieurs ?

On voit apparaître la notion d’espace. De quoi s’agit-il ? Quelle forêt peut cacher cet arbre ?

Dans votre MCD, quelle sens exact donner au verbe être dans la relation entre CLIENT et PERSONNE ? Je rappelle qu’en modélisation « être » doit se lire « être un ». Autrement dit, soit la cardinalité 0,N portée par la patte connectant PERSONNE et ÊTRE est à remplacer par 0,1, soit le verbe être n’est pas pertinent ici et l’association est à renommer.

[sohiermdp]

J'ai essayé de comprendre vos remarques et de faire évoluer le schéma en conséquence.

Voici les règles un peu mieux définies (enfin... je l'espère) :
- 1 personne est soit une personne morale soit une personne physique
- 1 personne peut posséder un compte fournisseur et 1 compte fournisseur est détenu par 1 seule personne
- 1 personne peut posséder un compte client et 1 compte client est détenu par 1 seule personne
- 1 compte client passe des commandes
- 1 personne morale est représentée par une ou plusieurs personnes physiques, à l'aide d'un mandat
- 1 personne physique peut être salariée de l'entreprise (c'est un collaborateur)
- 1 utilisateur est une personne physique

- 1 utilisateur peut se connecter à son compte client, s'il en possède un
- 1 utilisateur peut se connecter au compte client d'une personne morale pour laquelle il est mandatée

- 1 utilisateur peut se connecter à son compte fournisseur, s'il en possède un
- 1 utilisateur peut se connecter au compte fournisseur d'une personne morale pour laquelle il est mandatée

- 1 utilisateur peut se connecter à son compte collaborateur, s'il en possède un

[fsmrel]

Je suis désolé, mais vous n’avez pas répondu à mes questions et en échange vous passez à des concepts nouveaux : salarié, compte collaborateur, compte fournisseur, avec de nouvelles règles qui ajoutent à l’ambiguïté.

— Pour le compte collaborateur, vous vous limitez au salarié d’une entreprise : d’accord, ça se conçoit, mais y a-t-il un rapport entre ce genre de personne et une personne physique qui « peut représenter plusieurs personnes morales » ? Quel rapport avec le concept d’utilisateur ?

— Qu’est-ce qu’un compte fournisseur dans votre système ? Quel rôle joue-t-il ?

Tout ceci reste ambigu. Au lieu de fournir des règles de gestion nouvelles, répondez déjà aux questions que je vous avais posées.

Ambiguïté pour ambiguïté à lever, je vous pose une question concernant un domaine qui n’est pas forcément le vôtre : Pour vous qu’est-ce qu’un titre ?

N.B. Dans votre dernier MCD, il reste un « être » entre PERSONNE PHYSIQUE et UTILISATEUR avec une cardinalité 0,N.

1 compte client passe des commandes

Je suis désolé d’insister sur la rigueur de la formulation, mais un compte client ne passe pas de commandes, c’est la personne détenant ce compte qui le fait.

[sohiermdp]

Bonjour,

Je vais tenter de vous répondre :

Pour le compte collaborateur, vous vous limitez au salarié d’une entreprise : d’accord, ça se conçoit, mais y a-t-il un rapport entre ce genre de personne et une personne physique qui « peut représenter plusieurs personnes morales » ? Quel rapport avec le concept d’utilisateur ?

Un salarié, qui est une personne physique, peut en effet être le représentant d'une personne morale comme une association par exemple où il peut tenir un rôle précis (adhérent, trésorier, président, secrétaire, ...).
Une personne physique peut tout à fait représenter plusieurs personnes morales : l'entreprise dont il est salarié par exemple et une association.

Une personne physique peut-elle mandatée pour plus d’un compte (client) d’une même personne morale ?

Comme je le dis au-dessus une personne physique peut être mandatée pour plusieurs comptes clients. Cependant une personne ne détient qu'un seul compte.

Un compte client (d’une personne morale) fait-il l’objet du mandat d’une seule personne physique ? Possiblement de plusieurs ?

Une personne morale peut être représentée par plusieurs personnes physiques. Ces personnes physiques sont mandatées pour passer des commandes pour le compte de la personne morale.

Qu’est-ce qu’un compte fournisseur dans votre système ? Quel rôle joue-t-il ?

Un compte fournisseur est par définition un fournisseur. Une personne peut être aussi bien fournisseur que client. Je n'ai pas fait figurer le reste mais on peut imaginer que le fournisseur est lié à des bordereaux de livraison, à une liste des achats, etc...

[fsmrel]

Je retiens que pour passer une commande pour le compte d’une personne morale Pm pour laquelle elle est mandatée, une personne physique Pp peut utiliser le compte client Cc de son choix parmi l’ensemble des comptes Cc de Pm.

Exemple de personnes mandatées (pour y voir plus clair, j’indice la lettre P par des nombres impairs pour les personnes physiques et par des nombres impairs pour les personnes morales) :

• Raoul (personne P1), salarié de l’entreprise Volfoni SA (P2) est mandaté pour passer des commandes pour le compte de cette entreprise ;
• Raoul (personne P1), trésorier de l’association « Les joyeux flingueurs du samedi » (P4) est mandaté pour passer des commandes pour le compte de cette association ;
• Bastien (personne P3), salarié de l’entreprise Volfoni SA (P2) est mandaté pour passer des commandes pour le compte de cette entreprise ;
• Bastien (personne P3), secrétaire de l’association « Balades au Relationland » (P6) est mandaté pour passer des commandes pour le compte de cette association ;
• Albert (personne P5), salarié de l’entreprise Dubicobit (P8) est mandaté pour passer des commandes pour le compte de cette entreprise ;
• Albert (personne P5), adhérent de l’association « Les joyeux flingueurs du samedi » (P4) est mandaté pour passer des commandes pour le compte de cette association ;
• Bernard (personne P7), salarié de l’entreprise Dubicobit (P8) est mandaté pour passer des commandes pour le compte de cette entreprise ;
• Carole (personne P9), adhérente de l’association « Balades au Relationland » (P6) est mandatée pour passer des commandes pour le compte de cette association.

Sommes-nous en phase ? Qu’ai-je raté ?

Votre MCD comporte une entité-type MANDAT : quelles en sont les propriétés (attributs) ? Pourriez-vous illustrer l’association REPRESENTER à partir d’exemples faisant intervenir Raoul et les autres ? Cette association est-elle porteuse de propriétés ?

[sohiermdp]

Votre MCD comporte une entité-type MANDAT : quelles en sont les propriétés (attributs) ? Pourriez-vous illustrer l’association REPRESENTER à partir d’exemples faisant intervenir Raoul et les autres ? Cette association est-elle porteuse de propriétés ?

Le mandat permet de caractériser la relation entre une personne morale et une personne physique. Une personne morale étant toujours représentée par une personne physique.
Le MANDAT contient les attributs suivants : code, libellé...
En effet l'association REPRESENTER pourrait être transformée en entité REPRESENTATION, car celle-ci contient une date de début et une date de fin correspondant à la période de la relation entre la personne morale et la personne physique.

Pour illustrer :

• P1 est le représentant légal de P2 du 01/01/2013 au 31/12/2013
• P3 est le président de P5 du 14/02/2013 au 14/05/2013
• P4 est le président de P5 du 15/05/2013 au 31/12/2013, ...

[fsmrel]

Le MANDAT contient les attributs suivants : code, libellé...

A part ces attributs passe-partout et sans valeur ajoutée au plan sémantique, en auriez-vous d'autres à proposer ? Quand je parle d’attributs, je sous-entends : attributs spécifiques aux mandats, ayant leur propre originalité. La présence intéressante d’une période confirme en tout cas qu’on est dans un contexte temporel. Cela dit, quand vous écrivez :

P1 est le représentant légal de P2 du 01/01/2013 au 31/12/2013

Vous précisez « le représentant légal » et non pas « un représentant légal » : est-ce à dire que pendant une période une personne morale ne peut avoir qu’un seul représentant légal ? Modélisez-vous les fonctions exercées au fil du temps par les des personnes physiques en relation avec les personnes morales qu’elles représentent ?

Selon votre dernier MCD, l’entité-type REPRESENTATION est en réalité une ternaire entre PERSONNE MORALE, PERSONNE PHYSIQUE et MANDAT, ce qui veut dire que :

(1) Pour une personne morale et un mandat donnés une représentation peut comporter plusieurs personnes physiques, so far so good.

(2) Pour une personne physique et un mandat donnés une représentation peut comporter plusieurs personnes morales : là j’ai des doutes...

(3) Pour une personne morale et une personne physique, il peut y avoir plusieurs mandats...

Si (2) n’est pas valide, alors l’association TENIR n’est pas à sa place et si un mandat concerne une seule personne morale, alors on peut sans doute s’orienter vers quelque chose comme ceci :

[PERSONNE MORALE]--0,?--------( )--------1,1--[MANDAT]

[PERSONNE MORALE]--0,N--------(REPRESENTATION{Période})--------0,N--[PERSONNE PHYSIQUE]

Quelle est votre position ?

[sohiermdp]

Si (2) n’est pas valide, alors l’association TENIR n’est pas à sa place et si un mandat concerne une seule personne morale, alors on peut sans doute s’orienter vers quelque chose comme ceci :
[PERSONNE MORALE]--0,?--------( )--------1,1--[MANDAT]

[PERSONNE MORALE]--0,N--------(REPRESENTATION{Période})--------0,N--[PERSONNE PHYSIQUE]

Peut être que je n'ai pas bien défini l'entité MANDAT. Un MANDAT est une fonction tenue au sein de la personne morale (trésorier, président, adhérent, secrétaire, directeur, responsable achat, responsable vente, représentant légal, associé...) pendant une période.

En effet, pour chaque personne morale, il faut peut-être définir une partie de sa structure ou de son organigramme qui peut changer dans le temps.

J'introduis donc l'entité FONCTION
Exemple : trésorier, président, adhérent, secrétaire, directeur, ...

Un MANDAT est une FONCTION tenue au sein de l'organisation d'une PERSONNE MORALE.
Exemple : Une association (P1) propose des mandats de trésorier, de secrétaire, de président. Une entreprise (P2) propose un mandat de représentant légal et un mandat de responsable des achats.

Une PERSONNE PHYSIQUE représente une PERSONNE MORALE par l'intermédiaire d'un MANDAT pendant une période.
Exemple : Raoul (P3) occupe le mandat Représentant légal de (P2). Jonathan (P4) occupe le mandat de Responsable des achats de (P2) du 01/01/2013 au 13/01/2014.

Croyez-vous que cela tient la route ?

[fsmrel]

Bonjour sohiermdp,


Grâce à la définition plus précise du mandat, je pense que les choses commencent à se décanter même si certains points restent à préciser. Du fait de l’aspect temporel aux différents étages, il va falloir avancer prudemment...

Si je comprends bien, une personne morale définit un certain nombre de mandats, chacun étant applicable durant une période donnée. Les mandats sont des fonctions : président, trésorier, secrétaire, adhérent, etc., pouvant évoluer dans le temps du fait de l’organisation non figée chez cette personne morale. Derrière cela se cache peut-être une gestion d’historique, mais travaillons déjà sur la partie en cours. Par exemple :

Depuis le 01/09/2013, l’entreprise Volfoni SA propose les fonctions de trésorier et de président, et depuis le 15/10/2013 elle propose aussi la fonction de secrétaire. Est-ce bien comme cela que l’on doit voir la chose ? Il s’agit d’un point important et que j’énonce sous forme de règle de gestion, à vous de confirmer ou infirmer si cette règle est valide :

RG027 - Au même moment, deux personnes physiques peuvent représenter la même personne morale.

Par « au même moment », je sous-entends « à la même date ». Une remarque : on peut supposer qu’à un moment donné une association n’a qu’un président, qu’un trésorier. Cela dit, une entreprise dotée d’un directoire de cinq personnes devrait pouvoir être représentée au même moment par chacune de ces cinq personnes (fonction : membre du directoire). De la même façon, des adhérents (fonction adhérent) d’une même association pourront-ils représenter l’association au même moment ? Aussi, peut-on faire évoluer la règle précédente ? :

RG027 - Au même moment, deux personnes physiques peuvent représenter la même personne morale, et cela même si elles exercent la même fonction.

Dans votre MCD, j’observe une cardinalité 0,1 portée par la patte connectant MANDAT et TYPER : est-ce qu’on peut dire en l’occurrence que pour tel ou tel mandat il n’y a pas nécessairement de fonction précise ? S’il en est ainsi, pour ne pas compliquer la situation au niveau de la base de données, je suggère qu’on définisse la fonction « non précisée », « sans objet » (ou tout autre libellé à votre convenance), en sorte que la cardinalité 0,1 (toujours source de risques) soit remplacée par une cardinalité 1,1. Ainsi, à supposer que l’association « Les boulistes du XVe » ne propose pas de fonction particulière, on pourrait interpréter cela comme : Depuis le 12/09/2013, « Les boulistes du XVe » proposent des mandats sans fonction précisée (ce qui revient à mettre en oeuvre la fonction « non précisée », « sans objet »).


MANDAT est normalement une association entre PERSONNE_MORALE et FONCTION, et je suppose que vous en avez fait une entité-type pour pouvoir établir une association entre MANDAT et REPRESENTER, alors que Merise ne permet pas de connecter deux associations. Mais on peut alors considérer MANDAT comme une entité-type associative, ce qui conduit à utiliser des liens identifiants dans le contexte Open ModelSphere (cardinalités 1,1 soulignées au moyen de l’icône « clé ») :




Au niveau tabulaire, la paire d’attributs {PMorale, Fonction} est clé primaire de la table MANDAT dérivée :

Code :

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

1
2
3
4
5
6
7
8
9
MANDAT {PMorale                Fonction        Depuis    }
        Volfoni SA             trésorier       01/09/2013
        Volfoni SA             président       01/09/2013
        Volfoni SA             secrétaire      15/10/2013
        Ets Dugoineau          président       01/01/2013
        Les lutins bleus       trésorier       20/09/2013
        Les lutins bleus       adhérent        21/09/2013
        Les boulistes du XVe   non précisée    21/09/2013

Normalement ces attributs prennent des valeurs non significatives, mais j’ai utilisé de telles valeurs pour faciliter la lecture de l’exemple. En outre, j’ai renommé DateDebut en Depuis (et n'ai pas représenté la date fin, en attendant de savoir si vous souhaitez gérer des historiques : qui faisait quoi à telle date).


Pourquoi avoir représenté une entité-type REPRESENTATION ? Une association convient mieux :




D’où la table (de clé primaire {Pphysique, PMorale, Fonction}) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
REPRESENTATION {Pphysique     PMorale                Fonction        Depuis    }
                Raoul         Volfoni SA             président       03/09/2013
                Raoul         Les lutins bleus       adhérent        01/10/2013
                Paul          Les lutins bleus       adhérent        01/11/2013
                Pascal        Volfoni SA             secrétaire      02/11/2013
                Pascal        Volfoni SA             trésorier       02/11/2013
                Bastien       Volfoni SA             secrétaire      02/11/2013
                Raoul         Ets Dugoineau          président       03/09/2013
                Albert        Les boulistes du XVe   non précisée    21/09/2013 
                Bernard       Les boulistes du XVe   non précisée    21/09/2013

Où la paire d’attributs {PMorale, Fonction} participe à la clé primaire de la table REPRESENTATION et surtout est aussi clé étrangère par rapport à la clé primaire de la table MANDAT (intégrité référentielle).

Confirmez-vous la règle suivante ? (voyez le cas de Pascal)

RG028 - Au même moment, La même personne physique peut exercer deux fonctions distinctes pour le compte de la même personne morale.

[sohiermdp]

Je confirme les deux règles suivantes :

• RG027 - Au même moment, deux personnes physiques peuvent représenter la même personne morale, et cela même si elles exercent la même fonction.
• RG028 - Au même moment, La même personne physique peut exercer deux fonctions distinctes pour le compte de la même personne morale.

La gestion de l'historique est pour moi importante et doit être de base intégrée.

[fsmrel]

Je confirme les deux règles suivantes :
RG027 - Au même moment, deux personnes physiques peuvent représenter la même personne morale, et cela même si elles exercent la même fonction.
RG028 - Au même moment, La même personne physique peut exercer deux fonctions distinctes pour le compte de la même personne morale.

D’accord.

La partie du MCD concernant les mandats et les représentations pourrait donc ressembler à ceci (aux attributs près) :




Je n’ai pas fait figurer les dates de fin, car elles demandent quelques explications (voir mes questions ci-dessous).

MLD :




Code SQL (avec MS SQL Server 2005) :

Code SQL :

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

SET DATEFORMAT ymd

TABLE FONCTION

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
CREATE TABLE FONCTION 
(
    FonctionId         INT            NOT NULL,
    FonctionLibelle    VARCHAR(64)    NOT NULL
  , CONSTRAINT FONCTION_PK PRIMARY KEY (FonctionId)
) ;
 
INSERT INTO FONCTION (FonctionId, FonctionLibelle) VALUES (1, 'président') ;
INSERT INTO FONCTION (FonctionId, FonctionLibelle) VALUES (2, 'trésorier') ;
INSERT INTO FONCTION (FonctionId, FonctionLibelle) VALUES (3, 'secrétaire') ;
INSERT INTO FONCTION (FonctionId, FonctionLibelle) VALUES (4, 'adhérent') ;
INSERT INTO FONCTION (FonctionId, FonctionLibelle) VALUES (5, 'non précisée') ; 
 
SELECT ''AS FONCTION,* FROM FONCTION ;

TABLE PERSONNE

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
CREATE TABLE PERSONNE 
(
    PsnId              INT            NOT NULL,
    PsnNom             VARCHAR(64)    NOT NULL
  , CONSTRAINT PERSONNE_PK PRIMARY KEY (PsnId)
) ;
INSERT INTO PERSONNE (PsnId, PsnNom) VALUES (1, 'Raoul') ;
INSERT INTO PERSONNE (PsnId, PsnNom) VALUES (3, 'Paul') ;
INSERT INTO PERSONNE (PsnId, PsnNom) VALUES (5, 'Pascal') ;
INSERT INTO PERSONNE (PsnId, PsnNom) VALUES (7, 'Bastien') ;
INSERT INTO PERSONNE (PsnId, PsnNom) VALUES (9, 'Albert') ;
INSERT INTO PERSONNE (PsnId, PsnNom) VALUES (11, 'Bernard') ;
 
INSERT INTO PERSONNE (PsnId, PsnNom) VALUES (2, 'Volfoni SA') ;
INSERT INTO PERSONNE (PsnId, PsnNom) VALUES (4, 'Les lutins bleus') ;
INSERT INTO PERSONNE (PsnId, PsnNom) VALUES (6, 'Ets Dugoineau') ;
INSERT INTO PERSONNE (PsnId, PsnNom) VALUES (8, 'Les boulistes du XVe') ;
 
SELECT ''AS PERSONNE,* FROM PERSONNE ;

TABLE P_MORALE

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
CREATE TABLE P_MORALE 
(
    PmorId             INT            NOT NULL,
    Siren              CHAR(9)        NOT NULL
  , CONSTRAINT P_MORALE_PK PRIMARY KEY (PmorId)
  , CONSTRAINT P_MORALE_PERSONNE_FK FOREIGN KEY (PmorId) 
        REFERENCES PERSONNE ON DELETE CASCADE
) ;
INSERT INTO P_MORALE (PmorId, Siren) VALUES (2, '234567890') ;
INSERT INTO P_MORALE (PmorId, Siren) VALUES (4, '456789012') ;
INSERT INTO P_MORALE (PmorId, Siren) VALUES (6, '678901234') ;
INSERT INTO P_MORALE (PmorId, Siren) VALUES (8, '890123456') ;
 
SELECT ''AS P_MORALE,* FROM P_MORALE ;

TABLE P_PHYSIQUE

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
CREATE TABLE P_PHYSIQUE 
(
    PphyId             INT            NOT NULL,
    Salaire            INT            NOT NULL
  , CONSTRAINT P_PHYSIQUE_PK PRIMARY KEY (PphyId)
  , CONSTRAINT PHYSIQUE FOREIGN KEY (PphyId) 
        REFERENCES PERSONNE ON DELETE CASCADE
) ;
INSERT INTO P_PHYSIQUE (PphyId, Salaire) VALUES (1, 10000) ;
INSERT INTO P_PHYSIQUE (PphyId, Salaire) VALUES (3, 9000) ;
INSERT INTO P_PHYSIQUE (PphyId, Salaire) VALUES (5, 5000) ;
INSERT INTO P_PHYSIQUE (PphyId, Salaire) VALUES (7, 5000) ;
INSERT INTO P_PHYSIQUE (PphyId, Salaire) VALUES (9, 7000) ;
INSERT INTO P_PHYSIQUE (PphyId, Salaire) VALUES (11, 6000) ;
 
SELECT ''AS P_PHYSIQUE,* FROM P_PHYSIQUE ;

TABLE MANDAT

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
CREATE TABLE MANDAT 
(
    PmorId             INT            NOT NULL,
    FonctionId         INT            NOT NULL,
    DateDebut          DATETIME       NOT NULL
  , CONSTRAINT MANDAT_PK PRIMARY KEY (PmorId, FonctionId)
  , CONSTRAINT MANDAT_P_MORALE_FK FOREIGN KEY (PmorId) 
        REFERENCES P_MORALE
  , CONSTRAINT MANDAT_FONCTION_FK FOREIGN KEY (FonctionId) 
        REFERENCES FONCTION
) ;
INSERT INTO MANDAT (PmorId, FonctionId, DateDebut) VALUES (2, 1, '2013-09-01') ;
INSERT INTO MANDAT (PmorId, FonctionId, DateDebut) VALUES (2, 2, '2013-09-01') ;
INSERT INTO MANDAT (PmorId, FonctionId, DateDebut) VALUES (2, 3, '2013-10-15') ;
INSERT INTO MANDAT (PmorId, FonctionId, DateDebut) VALUES (6, 1, '2013-01-01') ;
INSERT INTO MANDAT (PmorId, FonctionId, DateDebut) VALUES (4, 2, '2013-09-20') ;
INSERT INTO MANDAT (PmorId, FonctionId, DateDebut) VALUES (4, 4, '2013-09-21') ;
INSERT INTO MANDAT (PmorId, FonctionId, DateDebut) VALUES (8, 5, '2013-09-21') ;
 
SELECT ''AS MANDAT,* FROM MANDAT ;

TABLE REPRESENTATION

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
CREATE TABLE REPRESENTATION 
(
    PphyId             INT            NOT NULL,
    PmorId             INT            NOT NULL,
    FonctionId         INT            NOT NULL,
    DateDebut          DATETIME       NOT NULL
  , CONSTRAINT REPRESENTATION_PK PRIMARY KEY (PphyId, PmorId, FonctionId)
  , CONSTRAINT REPRESENTATION_P_PHYSIQUE_FK FOREIGN KEY (PphyId)
        REFERENCES P_PHYSIQUE
  , CONSTRAINT REPRESENTATION_MANDAT_FK FOREIGN KEY (PmorId, FonctionId)
        REFERENCES MANDAT
) ;
INSERT INTO REPRESENTATION (PphyId, PmorId, FonctionId, DateDebut) VALUES (1, 2, 1, '2013-09-03') ;
INSERT INTO REPRESENTATION (PphyId, PmorId, FonctionId, DateDebut) VALUES (1, 4, 4, '2013-10-01') ;
INSERT INTO REPRESENTATION (PphyId, PmorId, FonctionId, DateDebut) VALUES (3, 4, 4, '2013-11-01') ;
INSERT INTO REPRESENTATION (PphyId, PmorId, FonctionId, DateDebut) VALUES (5, 2, 3, '2013-11-02') ;
INSERT INTO REPRESENTATION (PphyId, PmorId, FonctionId, DateDebut) VALUES (5, 2, 2, '2013-11-02') ;
INSERT INTO REPRESENTATION (PphyId, PmorId, FonctionId, DateDebut) VALUES (1, 6, 1, '2013-09-03') ;
INSERT INTO REPRESENTATION (PphyId, PmorId, FonctionId, DateDebut) VALUES (9, 8, 5, '2013-09-21') ;
INSERT INTO REPRESENTATION (PphyId, PmorId, FonctionId, DateDebut) VALUES (11, 8, 5, '2013-09-21') ;
 
SELECT ''AS REPRESENTATION,* FROM REPRESENTATION ;

Pour retrouver les contenus présents dans mon précédent message :

Code SQL :

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

1
2
3
4
SELECT ''AS MANDAT, PsnNom, Fonctionlibelle, DateDebut AS Depuis  
         FROM MANDAT AS x JOIN PERSONNE AS y ON x.PmorId = y.PsnId
                          JOIN FONCTION AS z ON x.FonctionId = z.FonctionId
;

Code SQL :

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

1
2
3
4
5
SELECT ''AS REPRESENTATION, y.PsnNom AS IndividuNom, z.PsnNom AS EntiteNom, Fonctionlibelle, DateDebut AS Depuis  
         FROM REPRESENTATION AS x JOIN PERSONNE AS y ON x.PphyId = y.PsnId
                                  JOIN PERSONNE AS z ON x.PmorId = z.PsnId 
                                  JOIN FONCTION AS t ON x.FonctionId = t.FonctionId
;

A propos de l’historisation :

1) Une date de fin représente-telle pour vous une date à laquelle prendra fin la validité de la période correspondante (c'est-à-dire dans le futur) ? Ou plutôt, marque-t-elle une période dans le passé ?

Que faut-il historiser ? Les mandats ? Les représentations ?

[sohiermdp]

Tout d'abord un grand merci pour votre contribution.

A propos de l’historisation :

1) Une date de fin représente-telle pour vous une date à laquelle prendra fin la validité de la période correspondante (c'est-à-dire dans le futur) ? Ou plutôt, marque-t-elle une période dans le passé ?

Que faut-il historiser ? Les mandats ? Les représentations ?

En effet, il faut distinguer plusieurs dates.
Les dates d'historisation :

• date d'ajout
• date de suppression logique

Les périodes de validité d'une représentation ou d'un mandat définies par :

• date de début
• date de fin

Il faut historiser et les mandat et les représentations.

--

Mon problème de départ était d'associer des comptes utilisateurs à des personnes physiques.
Un compte utilisateur correspond à un couple login/mot de passe. Chaque utilisateur est associé à une adresse email de contact pour lui envoyer un nouveau mot de passe en cas d'oubli. L'utilisateur pourra utiliser indifféremment le login ou l'adresse email comme identifiant.
Chaque personne physique peut avoir plusieurs comptes utilisateurs :

• un seul pour la personne physique qu'il représente. Ce compte lui permettra de se connecter à son espace personnel.
• un compte utilisateur pour chaque représentation d'une personne morale.

Exemple :

• Edouard a un login edouard1 pour s'identifier en tant que personne physique.
• Edouard a un login edouard2 pour s'identifier pour le compte d'une personne morale qu'il représente.
• Edouard a un login edouard3 pour s'identifier pour le compte d'une autre personne morale qu'il représente.

[fsmrel]

Bonjour sohiermdp,


Les dates de fin sont donc obligatoires et permettent de savoir à l’avance à partir de quand un mandat ne sera plus valable, même principe pour les représentations. C’est bien cela ?

Il faut historiser et les mandats et les représentations.

En attendant de traiter de l’historisation, voyons l’histoire des logins... Vous écrivez

Chaque personne physique peut avoir plusieurs comptes utilisateurs :
un seul pour la personne physique qu'il représente. Ce compte lui permettra de se connecter à son espace personnel.
un compte utilisateur pour chaque représentation d'une personne morale.

Une représentation détermine (c'est-à-dire désigne de façon unique) une personne physique et un mandat. Si je comprends bien une représentation détermine aussi un login : s’il en est ainsi, le MLD devient :




Où REPRESENTATION a pour clé primaire le triplet {PphyId, PmorId, FonctionId}, c'est-à-dire qu’une représentation détermine comme on l’a vu une personne physique et un mandat. Une représentation détermine aussi un login, mais de ce que je comprends, un login ne peut servir que pour une seule représentation : si Raoul représente Volfoni SA dans le rôle de président, le login affecté à cette représentation est unique. Deux représentations ne pouvant pas avoir même valeur de login, {Login} est clé candidate de la table REPRESENTATION.

Sommes-nous en phase ?

De la même façon, si une personne physique a en plus son login personnel (et un seul), on peut définir à cet effet un attribut Login pour la table P_PHYSIQUE :




Si vous êtes d’accord avec les fonctionnalités représentées dans ce MLD, vous pouvez légitimement avoir envie de factoriser (généraliser) les logins figurant dans les tables REPRESENTATION et P_PHYSIQUE. Remontons au niveau MCD (mais je quitte Open ModelSphere qui me fait perdre du temps avec ses lourdeurs), on définit une entité-type ad-hoc (que j’ai nommée COMPTE, mais qui peut porter tout autre nom), d’identifiant non significatif {CompteId} et d’identifiant alternatif {Login} :




Mais il faut interdire que le même login puisse servir à la fois pour un compte de personne physique et un compte de représentation. Avec Merise/2 on représente une contrainte d’exclusion entre les associations C_P et C_R :





MLD correspondant (notation PowerAMC) :





Avant de modéliser les adresses de courriel :

Les règles de gestion ci-dessous sont-elles valides ?

RG035 - Un login est associé à une et une seule adresse de courriel.

RG036 - Une adresse de courriel est associée à un seul login.

Sinon, quelles en sont les raisons détaillées (cas des personnes physiques, cas des représentations) ?

[sohiermdp]

Bonjour,

Les dates de fin sont donc obligatoires et permettent de savoir à l’avance à partir de quand un mandat ne sera plus valable, même principe pour les représentations. C’est bien cela ?

Tout à fait.

RG035 - Un login est associé à une et une seule adresse de courriel.
RG036 - Une adresse de courriel est associée à un seul login.

• une personne physique peut se connecter soit avec son login soit avec l'adresse mail associée.
• un représentant ne peut se connecter qu'avec un login, pas avec une adresse mail.
• un login d'une personne physique est associée à une et une seule adresse de courriel
• un login d'un représentant est associé à une et une seule adresse de courriel
• une adresse de courriel est associé à un ou plusieurs logins
• une adresse de courriel est associé à un seul login de personne physique
• une adresse de courriel peut être associé à plusieurs logins de représentant

Ainsi je pourrais avoir :
- Edouard, personne physique : login A, email A
- Edouard, représentant de B : login B, email B
- Edouard, représentant de C : login C, email A

[fsmrel]

Bonjour sohiermdp,


A propos de cette partie de votre MCD :




Je suppose que « EMAIL » est synonyme d’«adresse de courriel » et que « contacter » peut être compris en plus comme « appartenir » : une adresse de courriel appartient à une personne. C’est cela ?

Quoi qu’il en soit, à cause de la cardinalité 1,1 portée par la patte connectant « EMAIL » et « contacter » on peut affirmer que l’adresse de courriel A1 ne peut pas être utilisée à la fois pour contacter la BNS (Banque Nationale des Schtroumpfs) et l’association « La fanfare des pompiers de Morzy-les-Joyeuses », pas plus du reste que la personne physique Édouard.

Par ailleurs, il serait une erreur (facile à commettre...) de connecter un login servant à représenter l’association « La fanfare des pompiers de Morzy-les-Joyeuses » (entité-type REPRESENTATION) à une adresse de courriel (entité-type EMAIL) servant à contacter la BNS (Banque Nationale des Schtroumpfs). Confirmez-vous ?

De même, il serait une erreur de connecter un login servant à représenter l’association « La fanfare des pompiers de Morzy-les-Joyeuses » (entité-type REPRESENTATION) à une adresse de courriel servant à contacter la personne physique Édouard. Confirmez-vous ?

De même, il serait une erreur de connecter un login servant à représenter la personne physique Édouard à une adresse de courriel servant à contacter la BNS. Confirmez-vous ?

[sohiermdp]

En effet, je confirme les trois règles : ce serait des erreurs.

Si je comprends où vous voulez en venir, on devrait avoir une solution du genre :

[fsmrel]

Bonsoir sohiermdp,

Si je comprends où vous voulez en venir

Hum... les ternaires à cardinalité 1,1 ou 0,1 ont la réputation d’être suspectes et pas toujours interprétables...

Par exemple la ternaire REPRESENTATION est décomposable en deux binaires, dont l’une faisant manifestement double emploi avec la binaire Posséder connectant PERSONNE PHYSIQUE et COMPTE.

Quant à la patte connectant COMPTE et la ternaire Posséder entre PERSONNE, ADRESSE COURRIEL et COMPTE, elle semble vouloir dire qu’un compte est facultativement attaché à une adresse de courriel.

Peu importe. En tout cas, votre réponse affirmative à mes questions permet d’énoncer la règle suivante :

RG040 - Si une personne P1 possède l’adresse de courriel A1, aucun login appartenant à une personne P2 ne peut être branché sur l’adresse A1.

Selon le MCD suivant qui est une extension de celui de la figure 4 (cf. message #16), on peut attacher un compte à une adresse de courriel, mais sans garantie du respect de la règle RG040 :




MLD correspondant :



La règle RG040 peut cependant ne pas être respectée car, partant de PERSONNE, on peut « naviguer » jusqu’à REPRESENTATION selon deux chemins :

1) PERSONNE -> MANDAT -> REPRESENTATION

2) PERSONNE -> ADR_COURRIEL -> COMPTE -> REPRESENTATION

Ainsi, on peut brancher une représentation de Volfoni SA sur un compte C1 (par inadvertance ou autre...), alors que ce compte est attaché à l’adresse courriel A1 appartenant elle-même à la Banque Nationale des Schtroumpfs.

La règle RG040 correspond à une contrainte de chemin : si on veut qu’elle soit assurée, en SQL on utilisera une assertion (instruction CREATE ASSERTION), ou un trigger si le SGBD ne permet pas de créer des assertions.

Si on veut éviter la lourdeur des triggers, on peut utiliser l’identification relative pour les adresses de courriel et les comptes, de sorte qu’on propage l’attribut PsnId d’entité-type en entité-type.

J’utilise ici la notation de l’identification relative à la manière PowerAMC :




Équivalent Open ModelSphere (à peu de choses près) :




En conjugaison avec l’association P_ADR_C, l’attribut AdrCourrielId participe à l’identification relative de l’entité-type ADR_COURRIEL par rapport à l’entité-type PERSONNE. L’attribut AdrCourrielId n’est donc qu’un banal séquenceur permettant, pour chaque personne, de numéroter de 1 en 1 ses adresses de courriel, tandis que la véritable adresse de courriel fait l’objet de l’attribut AdressseCourriel (devenant identifiant alternatif).


Traduction au stade MLD :




Traduction au stade SQL :

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
CREATE TABLE PERSONNE (
   PsnId                INT                  NOT NULL,
   PsnNom               VARCHAR(64)          NOT NULL,
   CONSTRAINT PERSONNE_PK PRIMARY KEY (PsnId)
) ;
 
CREATE TABLE ADR_COURRIEL (
   PsnId                INT                  NOT NULL,
   AdrCourrielId        INT                  NOT NULL,
   AdresseCourriel      VARCHAR(64)          NOT NULL,
   CONSTRAINT ADR_COURRIEL_PK PRIMARY KEY (PsnId, AdrCourrielId),
   CONSTRAINT ADR_COURRIEL_AK UNIQUE (AdresseCourriel),
   CONSTRAINT ADR_COURRIEL_PERSONNE_FK FOREIGN KEY (PsnId)
      REFERENCES PERSONNE
) ;

Exemple :

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
 
INSERT INTO PERSONNE (PsnId, PsnNom) VALUES (1, 'Raoul') ;
INSERT INTO PERSONNE (PsnId, PsnNom) VALUES (2, 'Volfoni SA') ;
INSERT INTO PERSONNE (PsnId, PsnNom) VALUES (3, 'Paul') ;
INSERT INTO PERSONNE (PsnId, PsnNom) VALUES (4, 'Les lutins bleus') ;
INSERT INTO PERSONNE (PsnId, PsnNom) VALUES (5, 'Pascal') ;
INSERT INTO PERSONNE (PsnId, PsnNom) VALUES (6, 'Ets Dugoineau') ;
 
INSERT INTO ADR_COURRIEL (PsnId, AdrCourrielId, AdresseCourriel) VALUES (1, 1, 'raoul@cezigue.com') ;
INSERT INTO ADR_COURRIEL (PsnId, AdrCourrielId, AdresseCourriel) VALUES (2, 1, 'volfo1@volfo.com') ;
INSERT INTO ADR_COURRIEL (PsnId, AdrCourrielId, AdresseCourriel) VALUES (2, 2, 'pascal@volfo.net') ;
INSERT INTO ADR_COURRIEL (PsnId, AdrCourrielId, AdresseCourriel) VALUES (3, 1, 'Paul@cezigue.com') ;
INSERT INTO ADR_COURRIEL (PsnId, AdrCourrielId, AdresseCourriel) VALUES (4, 1, 'loulou@lutinsbleus.net') ;
INSERT INTO ADR_COURRIEL (PsnId, AdrCourrielId, AdresseCourriel) VALUES (4, 2, 'paul@lutinsdbleus.net') ;
INSERT INTO ADR_COURRIEL (PsnId, AdrCourrielId, AdresseCourriel) VALUES (5, 1, 'pascal@volfo.com') ;
INSERT INTO ADR_COURRIEL (PsnId, AdrCourrielId, AdresseCourriel) VALUES (6, 1, 'dugoi@dugoineau.com') ;

A leur tour, les adresses de courriel peuvent se décliner en logins (entité-type COMPTE, à renommer au besoin). Par le biais de l’identité relative, on continue à propager l’attribut PsnId. Le véritable login fait l’objet de l’attribut Login de l’entité-type COMPTE et y est identifiant alternatif (si deux personnes ne peuvent avoir même login).


MCD :





MLD :




Code SQL :

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
CREATE TABLE COMPTE (
   PsnId                INT                  NOT NULL,
   AdrCourrielId        INT                  NOT NULL,
   CompteId             INT                  NOT NULL,
   Login                VARCHAR(64)          NOT NULL,
   MotDePasse           VARCHAR(64)          NOT NULL,
   CONSTRAINT COMPTE_PK PRIMARY KEY (PsnId, AdrCourrielId, CompteId),
   CONSTRAINT COMPTE_AK UNIQUE (Login),
   CONSTRAINT COMPTE_ADR_COURRIEL_FK FOREIGN KEY (PsnId, AdrCourrielId)
      REFERENCES ADR_COURRIEL
) ;
INSERT INTO COMPTE (PsnId, AdrCourrielId, CompteId, Login, MotDePasse) VALUES (2, 1, 1, 'Volfo01', '3510') ;
INSERT INTO COMPTE (PsnId, AdrCourrielId, CompteId, Login, MotDePasse) VALUES (2, 1, 2, 'Volfo02', '35j7') ;
INSERT INTO COMPTE (PsnId, AdrCourrielId, CompteId, Login, MotDePasse) VALUES (4, 1, 1, 'lutin01', 'bgty') ;

Globalement :

MCD :




MLD :




Au vu du code SQL ci-dessous, vous conviendrez qu’on ne peut pas violer la règle RG040.


TABLE REPRESENTATION

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
CREATE TABLE REPRESENTATION 
(
   PmorId               INT                  NOT NULL,
   FonctionId           INT                  NOT NULL,
   PphyId               INT                  NOT NULL,
   AdrCourrielId        INT                  NOT NULL,
   CompteId             INT                  NOT NULL,
   DateDebut            DATETIME             NOT NULL,
   DateFin              DATETIME             NOT NULL DEFAULT '2014-12-31',
   CONSTRAINT REPRESENTATION_PK PRIMARY KEY (PmorId, FonctionId, PphyId),
   CONSTRAINT REPRESENTATION_AK UNIQUE (PmorId, AdrCourrielId, CompteId),
   CONSTRAINT REPRESENTATION_P_PHYSIQUE_FK FOREIGN KEY (PphyId)
      REFERENCES P_PHYSIQUE,
   CONSTRAINT REPRESENTATION_MANDAT_FK FOREIGN KEY (PmorId, FonctionId)
      REFERENCES MANDAT ON DELETE CASCADE,
   CONSTRAINT REPRESENTATION_COMPTE_FK FOREIGN KEY (PmorId, AdrCourrielId, CompteId)
      REFERENCES COMPTE
) ;
 
INSERT INTO REPRESENTATION (PphyId, PmorId, FonctionId, AdrCourrielId, CompteId, DateDebut) VALUES (1, 2, 1, 1, 1, '2013-09-03') ;

Même principe concernant la table P_PHYSIQUE.

Mais il ne faudra pas oublier le trigger dont on ne peut se dispenser pour garantir la contrainte d’exclusion qui veut que le même compte (login) ne peut pas être utilisé pour une personne physique et une représentation (cf. figure 9).

une adresse de courriel est associé à un seul login de personne physique

Le MCD que j’ai proposé ne permet pas de prendre en compte cette contrainte, car jusqu’ici, à une adresse de courriel peuvent être associés plusieurs logins, sans distinction du type des personnes.

Pour éviter des triggers supplémentaires, on peut préférer brancher l’entité-type P_PHYSIQUE non pas sur l’entité-type COMPTE mais directement sur l’entité-type ADR_COURRIEL (et donc ne brancher sur COMPTE que l’entité-type REPRESENTATION).


Partie correspondante du MCD :



Le login et le mot de passe des personnes physiques sont directement hébergés par l’entité-type P_PHYSIQUE.

On regardera si le MLD (que je proposerai) continue à garantir la règle RG040, autrement dit si le dernier MCD vaut le coup...