Discussion :

[HASSNAA66]

Bonjour tout le monde ,
svp si vous pouvez m'aider pour resoudre un probleme dans mcd et merci.

Pour vous expliquer j'ai 3 tables : dossier personnel et proche famille .
Les cardinalité entre personnel et Dossier c'est (0.n) _ (1,1) pour Personnel et proche famille( 0,n )_( 1,n) et enfin les cardinalité entre dossier et proche famille sont (1,1) _(1,n) le probleme c'est j'ai une cercle entre les 3 tables.

Si vous pouvez me proposez une solution je vous remercie autre fois.

[fsmrel]

Bonjour,


Ça manque de précisions ! Pourriez-vous fournir une image de votre représentation graphique ?

En attendant, on va jouer les Sherlock Holmes....

Renommons Personnel en P, Proche famille en F et Dossier en D.

Appelons PF l’ensemble PF des couples {P, F} défini par l’association Personnel - Proche famille. On va conjecturer que l’ensemble PF représente le référentiel, le catalogue des couples légaux {P, F}.

Votre cercle représente très vraisemblablement une contrainte au sens de Merise. Parmi les contraintes possibles (CIF, exclusion, totalité, égalité, inclusion, stabilité, etc., voyez la FAQ Merise), la plus plausible est celle d’inclusion (à ce sujet, n’y a-t-il pas une lettre à l’intérieur du cercle ?) signifiant que chaque valeur de couple <P, F> déterminé par un dossier doit être un élément de PF.

[HASSNAA66]

le voila et merci

[fsmrel]

Le « cercle » est simplement la représentation Merise de la relation entre Personnel et Dossier :

Un membre du personnel peut être en relation avec plusieurs dossiers ;
Un dossier est en relation avec un seul membre du personnel.

Représentation équivalente selon le formalisme Entité/Relation (avec Power AMC) :

[HASSNAA66]

salut mais moi je veux la relation entre les 3 table pas entre 2

[fsmrel]

le probleme c'est j'ai une cercle entre les 3 tables.

Votre MCD ne met en relation aucune association-type ternaire (« cercle entre 3 tables »...) Autrement dit, souhaitez-vous mettre en œuvre une telle association-type ? Si oui, au motif de quelle règle de gestion des données ? On ne dessine pas des ronds pour le plaisir de dessiner des ronds...

Pour mémoire, je rappelle que le MCD que vous nous proposez est le suivant :

[Driss35]

Bonjour,

Je vais essayé éclaircir un peu la problématique qu'on a (je suis avec HASSNAA66). C'est une base de données de gestion des dossiers de mutuelle.

En fait, nous avons les tables : Personnel, Proche_Famille, Dossier (Mutuelle).

Voici les règles de gestion :
- Un dossier concerne un et un seul employé.
- Un employé peut n'avoir aucun dossier comme il peut en avoir plusieurs.
- Un dossier peut avoir comme malade soit l'employé lui-même ou bien un de ses proches famille.
- Un proche famille peut avoir un ou plusieurs parents (Personnel).
- Un employé peut n'avoir aucun proche famille comme il peut en avoir plusieurs.

Nous voulons établir les relation entre ces 3 tables sans qu'il y ai de relation circulaire.

Merci d'avance pour l'aide.

[fsmrel]

Bonsoir,

Un dossier concerne un et un seul employé

Que voulez-vous dire par « concerne » ? Le dossier concerne l’employé E parce qu’il contient des données qui le concernent lui-même, ou bien parce que le dossier est pris en charge par E et contient donc des données d’autres personnes ?

Je vais supposer que le dossier contient des données concernant soit l’employé E, soit un proche.

On peut procéder à une généralisation/spécialisation, c'est-à-dire mettre en commun dans une entité-type — qu’on appellera par exemple PERSONNE (ou MALADE, plus explicite) — les données caractérisant aussi bien l’employé que le proche : nom, prénom, etc.

On définit alors deux entités-types jouant un rôle de sous-type — appelons les EMPLOYE et PROCHE — dont les attributs représentent des données propres à chacune de ces deux entités-types.

L’entité-type PERSONNE est dotée d’un identifiant technique — appelons-le PersonneId —, dont héritent les entités-types EMPLOYE et PROCHE et pour lesquelles on n'a donc pas d’identifiant à déclarer.

Le matricule de l’employé n’est plus l’identifiant, mais un identifiant alternatif de l’entité-type EMPLOYE (voyez le mickey <ai>).

L’association-type établie entre EMPLOYE et PROCHE est porteuse d’un attribut NatureParente permettant de définir la nature des liens de parenté entre un proche et un employé.


Le MCD est alors le suivant :




Et le MLD :


Vous noterez que j’ai renommé les clés primaires des tables EMPLOYE et PROCHE.

Ce MLD pourrait donner l'illusion d'une circularité, mais les entités-types ne bouclent pas sur elles-mêmes, il n'y a donc pas d'auto-référence.

N.B. Prenez l'habitude de bien expliquer la nature des relations entre les objets : le verbe "concerner" ne veut rien dire s'il ne fait pas l'objet d'explications.

[Driss35]

Bonjour,

Merci pour ta réactivité fsmrel.

Effectivement, ce n'était toujours pas assez claire.

Quand je parlais d'employé c'est pour désigner la table PERSONNEL.
Dans le dossier de mutuelle on renseigne l'assuré (l'employé) et le malade en question qui peut être soit l'employé lui même ou bien un de ses proches.

Merci d'avance.

[fsmrel]

Bonjour,

Quand je parlais d'employé c'est pour désigner la table PERSONNEL.

Il serait difficile d’imaginer autre chose.

Dans le dossier de mutuelle on renseigne l'assuré (l'employé) et le malade en question qui peut être soit l'employé lui même ou bien un de ses proches.

On tourne en rond. Avant d'aller plus loin, je reformule la question que j’ai déjà posée : Quand vous dites « on renseigne l’employé », considérez-vous l’employé dans son rôle de gestionnaire du dossier, celui a rédigé le dossier, qui en a la responsabilité ?

Merci de répondre par "oui" ou par "non" à cette question et de justifier votre réponse par des exemples.

[Driss35]

Bonjour,

Oui en effet, par exemple : moi je suis employé, ma femme était malade et a consulté un médecin et fait des analyse. Je vais constituer un dossier de mutuelle à mon nom, en tant qu'assuré, et renseigner le nom de ma femme dans la case correspondant au "nom du malade". Si j'étais moi-même malade, je vais constituer un dossier à mon nom et renseigner aussi mon nom dans la case "nom du malade".

J'espère que j'ai été plus clair.

Merci d'avance.

[fsmrel]

D’accord, vous pouvez remplir un dossier concernant un de vos proches ou vous-même, mais pouvez-vous constituer le dossier d’un adhérent qui n’est pas de votre famille, par exemple le mien ou celui d’un de mes proches (en supposant bien sûr que je sois adhérent de la mutuelle) ? C'est-à-dire pouvez-vous être impliqué dans mon dossier seulement dans le rôle de gestionnaire ? Dans cette hypothèse, vos coordonnées (disons votre matricule) figureront-elles dans mon dossier (disons dan le cadre réservé à la mutuelle) ?

Pour que tout cela soit bien clair, pourriez-vous afficher l'image d'un exemple (factice) de dossier ? Rien de tel qu'un bon dessin...

[Driss35]

Chaque employé ne peut constituer de dossier de déclaration de maladie que pour lui ou un de ses proches (conjoint(e) ou enfants).
J'ai mis ci-joint la feuille qu'on remplit. L'assuré ne peut être qu'un employé et le malade ne peut être que lui même ou un de ses proches.

Merci.

[fsmrel]

Bonsoir,


En principe, le MCD ci-dessous devrait être en phase avec le document de déclaration de maladie. Il s’agit d’une version « light », dans la mesure où le lien de parenté entre le malade et l'employé n’est établi qu’au moment de la rédaction de la déclaration. Si le lien de parenté fourni à la déclaration doit être validé par rapport à un référentiel des liens de parenté, on complètera le MCD en conséquence (voir plus loin).

MCD, version light :


MLD :



Supposons que Hassnaa, employé de la mutuelle, remplisse une déclaration de maladie pour Driss qui est son frère mais n’est pas employé de la mutuelle.
Supposons encore que fsmrel, employé de la mutuelle, tombe malade et remplisse sa propre déclaration de maladie.

La représentation tabulaire serait la suivante :

La table PERSONNE fournit donc les informations communes à tout le monde, nom, prénom, date de naissance, adresse, etc.

Code :

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

1
2
3
4
5
6
 
PERSONNE  PersonneId   Nom        ...
          ----------   --------   ---
                   1   Hassnaa    ...
                   2   Driss      ...
                   3   fsmrel     ...

La table EMPLOYE fournit les informations spécifiques des employés, matricule, date d’embauche, etc.

Code :

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

1
2
3
4
5
 
EMPLOYE   PersonneId   Matricule   ...
          ----------   ---------   ---
                   1   123456      ...
                   3   314115      ...

La table PROCHE fournit les informations spécifiques des proches des employés (en passant, à quoi correspond l'attribut Pf_Type ?)

Code :

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

1
2
3
4
 
PROCHE    PersonneId   Pf_Type   ...
          ----------   -------   ---
                   2   abcde0    ...

La table DOSSIER fournit les informations du dossier concernant le malade. Le dossier 1 concerne le malade Driss et le dossier 2 l’employé malade fsmrel.

Code :

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

1
2
3
4
5
 
DOSSIER   DossierId    PersonneId   DateDeclaration   ...
          ---------    ----------   ---------------   ---
                  1             2   2011-01-25        ...
                  2             3   2011-02-14        ...

La table DOSSIER fournit les informations du dossier concernant le lien de parenté : pour le dossier 1, la personne parente du malade (Driss) est Hassnaa (PersonneId = 1) qui est son frère.

Code :

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

1
2
3
4
 
PARENTE   DossierId    PersonneId   LienParente   ...
          ---------    ----------   -----------   ---
                  1             1   frère         ...

En prime, je joins le diagramme de classes :




Montons la barre d'un cran...

Si on gère un référentiel des liens de parenté, on repart sur la base du MCD que je vous ai proposé hier, et on le combine avec la version light. Pour s’assurer que, dans le cas où le malade est un proche, sa parenté avec l’employé (entité-type PARENTE) est cohérente avec le référentiel des liens de parenté (entité-type LIEN_PARENTE), alors on est amené à identifier l’entité-type DOSSIER relativement à l’entité-type PERSONNE.

MCD :



MLD :



Au format tabulaire :

Code :

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

1
2
3
4
5
6
 
PERSONNE  PersonneId   Nom        ...
          ----------   --------   ---
                   1   Hassnaa    ...
                   2   Driss      ...
                   3   fsmrel     ...

Code :

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

1
2
3
4
5
 
EMPLOYE   PersonneId   Matricule   ...
          ----------   ---------   ---
                   1   123456      ...
                   3   314115      ...

Code :

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

1
2
3
4
 
PROCHE    PersonneId   Pf_Type   ...
          ----------   -------   ---
                   2   abcde0    ...

Table DOSSIER : attention, l’attribut DossierId est relatif à l’attribut PersonneId :

Code :

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

1
2
3
4
5
 
DOSSIER   PersonneId   DossierId   DateDeclaration   ...
          ----------   ---------   ---------------   ---
                   2           1   2011-01-25        ...
                   3           1   2011-02-14        ...

Code :

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

1
2
3
4
 
LIEN_PARENTE   ProcheId   EmployeId   LienParente   ...
               --------   ---------   -----------   ---
                      2           1   frère         ...

Code :

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

1
2
3
4
 
PARENTE   ProcheId   DossierId   EmployeId   ...
          --------   ---------   ---------   ---
                 2           1           1   ...

Elle est pas belle la vie ? Approche-t-on de la solution que vous cherchez ?

P.-S. Ça n'est pas le moment que nous tombions tous malades...

[Driss35]

Bonjour,

Merci pour votre réponse rapide.

Concernant le champs Pf_Type c'est la nature de la relation entre le proche et l'employé, qui ne peut être que soit conjoint(e) ou bien enfant.

Nous comprenons pas pourquoi il y a une relation entre PARENTE et DOSSIER.
Normalement un dossier ne peut concerner qu'un seul malade et un seul employé. Le proche devrais avoir une relation avec l'employé. Pour compliquer encore, un employé peut être conjoint d'un autre employé.

Le besoin est de savoir qu'un dossier numéro X est constitué par l'employé Y et concerne le malade Z, ce dernier peut être l'employé lui même (c-a-d X) ou bien son proche A.

J'espère avoir été clair dans mon explication.

Merci d'avance.

[Driss35]

Vous utilisez quel logiciel pour la modélisation ?

[fsmrel]

Bonjour,

Concernant l'outil de modélisation, je l'avais déjà indiqué ici.

Pour le reste, j'essaiera de répondre ce soir ou demain, car je suis occupé toute la journée.

A plus tard

[Driss35]

Bonjour,

J'ai mis ci-joint le MCD après modification.
Merci de me donner votre avis.

[fsmrel]

Bonjour,


Repartons sur des bases précises.

A votre tour, vous avez mis en œuvre l’héritage, mais je ne suis pas sûr que vous ayez parfaitement compris son rôle. Tout d’abord, j’avais défini une entité-type PERSONNE en tant que surtype, pour votre part, vous avez préféré le terme MALADE. Il est vrai qu’un malade peut être un membre du personnel ou un de ses proches, mais les membres du personnel ne sont pas a priori tous malades. De même, en nommant MALADE le surtype, on serait tenté de comprendre que seuls les proches (entité-type PROCHE_FAMILLE) qui sont (ou ont été) malades sont à considérer. D’où les questions que je pose :

Question 1 : Une occurrence de l’entité-type PERSONNEL représente-t-elle seulement un employé malade ?

Question 2 : Une occurrence de l’entité-type PROCHE_FAMILLE représente-t-elle seulement un proche malade ?

Si vous répondez négativement à au moins l’une de ces questions, je vous engage à remplacer le terme MALADE par PERSONNE (ou un terme équivalent).

Ensuite, la généralisation permet de regrouper dans le surtype (disons PERSONNE) les propriétés communes aux membres du personnel et à leurs proches. Vous avez pris le parti de ventiler ces propriétés dans les sous-types PERSONNEL et PROCHE_FAMILLE : vous perdez le bénéfice de la généralisation.


A noter que le nom de l’entité-type PERSONNEL n’est pas judicieux : le personnel représente un ensemble d’employés, donc un personnel n’a pas de prénom, de situation de famille, etc., contrairement aux employés. Je vous suggère donc de renommer cette entité-type en EMPLOYE (ou COLLABORATEUR ou MEMBRE_DU_PERSONNEL, ou tout autre nom équivalent).


Cas de l’attribut Pf_Type

Vous me dites que l’attribut Pf_Type représente la nature de la relation entre le proche et l'employé, qui ne peut être que soit conjoint(e) ou bien enfant. Très bien. Mais entre les entités-types PERSONNEL et PROCHE_FAMILLE, vous avez une relation de type N-N ce qui signifie (1) qu’un employé peut être en relation avec plusieurs proches, ce qui est normal, (2) qu’un proche peut être en relation avec plus d’un employé, mais alors la nature de la relation entre le proche et l'employé est plutôt à établir au niveau même de la relation, comme je l’avais fait de mon côté :




Si les proches sont seulement le conjoint ou les enfants, on peut peut-être s’en sortir avec votre représentation, mais elle n’est pas orthodoxe et pas très saine.


A suivre.

[Driss35]

Bonjour,

Merci pour vos explications et votre patience.


Je n'ai pas très bien compris le role de l'entité "PARENTE" alors qu'il y a une entité "LIEN_PARENTE", aussi les relations que vous avez mis pour cette entité.


Merci d'avance pour votre aide précieuse.