Discussion :

[babouba]

Bonjour

Je voudrais avoir votre avis sur mon MCD « Gestion des Mutuelles »

Voici les règles de Gestion
L'outil permet de Gérer des Mutuelle , Si on crée Une Mutuelle , les bureaux, les utilisateurs, les adhérents qui votre être créer derrières seront liés à cette mutuelle .

C’est une mutuelle privée qui a des bureaux sur l’ensemble du territoire.
Pour être adhérent et bénéficier des prestations de la mutuelle , on demande une cotisation mensuelle
Et cette cotisation varie selon qu’on est en activité ou pas.

Pour les utilisateurs de l’outil c'est-à-dire les employés de la mutuelle.
Ils ont des profits différents fixés par le super Administrateur en fonction au niveau de leur rôle

Certains utilisateurs peuvent ajouter des adhérents, les supprimer tandis que d’autres peuvent que consulter les dossiers des adhérents

Pour ce qui du super administrateur celui qui a le rôle le plus élève a même la possibilité de créer une nouvelle mutuelle pour d’autres Type Services

On souhaite conserver les traces de ces utilisateurs par exemple : derrières date de login, opérations effectués

Un Dossier de Prestation concerne un seul adhérent

Un dossier de Prestation concerne l’adhérent lui-même ou un membre de sa famille(Bénéficiaire)

Un adhérent peut n’avoir aucun dossier comme il peut avoir plein.

On souhaite gérer les traces des dossiers, les primes et les remboursements

Pour les prestations
Il a des Types de Prestations et chaque Type de prestations est composé de plusieurs Prestations

Dans un Dossiers de Prestation il peut y avoir plusieurs Type de Prestations
Outil De Modélisation Visual Paradigm Comminity Edition

MCD Ci joint
« Je ne sais pas si je sui clair mais bon j’essaye en tout cas »

Je reste à votre disposition pour plus D’informations

merci

[CinePhil]

Le schéma que tu présente n'est pas un MCD mais un schéma Entity/Relationship, plus proche du MLD que du MCD.

Je lis ton schéma...

1) "Addresses"
1.a) En français, adresse n'a qu'un D et il est d'usage, comme tu l'as d'ailleurs fait pour les autres tables, de nommer au singulier les entités types du MCD et les tables de la base de données qui en découleront.
=> Change le nom en "Adresse".

1.b) C'est bien d'avoir externalisé l'adresse pour éviter d'avoir 3 fois les mêmes propriétés dans 3 entités types différentes. Par contre, un petit détail au niveau des cardinalités t'a fait commettre une erreur qui se voit avec les clés étrangères dans la table Adresse. D'après celles-ci, une adresse est à la fois adresse d'une mutuelle et d'un adhérent !

Je remonte aux règles de gestion naturelle de ce type de cas :
Une adresse peut appartenir à un adhérent et un adhérent n'a qu'une adresse.
Une adresse peut appartenir à une mutuelle et une mutuelle n'a qu'une adresse.
Une adresse peut appartenir à un bureau et un bureau n'a qu'une adresse.

MCD :
Adresse -0,1----appartenir----1,1- Adherent
|-------------0,1----appartenir----1,1- Mutuelle
|-------------0,1----appartenir----1,1- Bureau

MLD façon schéma E/R :
Adresse |--------o| Adherent
|----------------------o| Mutuelle
|----------------------o| Bureau

Et ce sont les tables Adherent, Mutuelle et Bureau qui ont chacun une clé étrangère référençant l'adresse.

=> Change les cardinalités des associations.

1.c) La ville devrait être externalisée dans une table de référence des villes car tu risques d'avoir dans la table adresse, au fur et à mesure des saisies des adresses par les utilisateurs, Saint-Étienne, St. Etienne, Saint Etienne...
=> Met en oeuvre ce schéma :
MCD :
Adresse -1,1----Situer----0,n- Ville

E/R :
Adresse >o--------| Ville

=> Il manque le code postal dans ta table Adresse.

2) Civilite
C'est bien d'avoir externalisé la civilité mais :
2.a) CHAR(2) est insuffisant
Mademoiselle => Mle
Madame => Mme

2.b) Je trouve que tu devrais ajouter une colonne pour le libellé complet de la civilité.

2.c) Tu as fait une association avec Utilisateur mais celui-ci n'a qu'un login et pas de nom. Je trouverais bizarre de voir un écran de logiciel qui m'appellerait "M. CinéPhil" !
=> Ajoute le nom et le prénom de l'utilisateur ou supprime cette association qui me semble inutile.
Si tu laisses l'association, celle-ci devrait avoir les cardinalités suivantes :
Civilite |--------o< Utilisateur

Idem pour les cardinalités de l'association avec Adherent et avec Proche :
Civilite |--------o< Adherent
|--------------------o< Proche

3) Role
Que doit contenir la colonne role par rapport au nom ?
=> Donne un nom plus signifiant à la colonne role.

4) Proche
4.a) Colonne "prenomProche" et non pas "prnomProche" !
4.b) L'association avec DossierPrestation me semble fausse

Un dossier de Prestation concerne l’adhérent lui-même ou un membre de sa famille(Bénéficiaire)

Tu devrais écrire tes règles de gestion de la manière que je l'ai fait plus haut, avec les eux propositions inversées, ce qui donnerait ici :
Un dossier de prestation peut concerner un adhérent et un adhérent peut être concerné par plusieurs dossiers de prestation.
Un dossier de prestation peut concerner un proche et un proche peut être concerné par plusieurs dossiers de prestation.

Ce qui donne le MCD suivant :
DossierPrestation -0,1----concerner----0,n- Adherent
|-----------------------------0,1----concerner----0,n- Proche

Ce qui doit entraîner la création de deux tables associatives :
DossierPrestation_Adherent (idDossierPrestation, idAdherent)
DossierPrestation_Proche (idDossierPrestation, idProche)

Avec le schéma E/R suivant :
E/R :
DossierPrestation |--------o| DossierPrestation_adherent >o--------| Adherent
|-------------------------------------o| DossierPrestation_Proche >o----------| Proche

4.c) la colonne "typeDeTrace" dans la table TraceDossier laisse supposer qu'il y a des types de trace bien définis et en nombre limité. Plutôt que d'écrire le type de trace à chaque dossier, il vaut mieux externaliser ce type de trace dans une table de référence. Comme c'est la seule propriété de la table TraceDossier, il serait plus simple de aire l'association ci-dessous. Idem pour le type de prime et le type de remboursement.
MCD :
DossierPrestation -0,n----Avoir----0,n- TypeDeTrace
|---------------------------1,1----Bénéficier----0,n- TypeDePrime
|---------------------------0,n----Payer----1,1- Remboursement
E/R :
DossierPrestation |----o< TraceDossier >o----| TypeDeTrace
>o----------------------------------------------------------------| TypeDePrime
>o----------------------------------------------------------------| TypeDeRemboursement

===============

Voilà ! C'est tout pour aujourd'hui ! Tu peux constater qu'il est bon de remonter au niveau MCD pour éviter les erreurs !

Bon courage pour la suite !

[babouba]

Bonjour;

Je vous remercie de toutes ces remarques que j'ai pris en compte .

J'ai rajouté Logs et StatutLogs pour suivre les logs des Utilisateurs

Je suis toujours à l'écoute vos remarques sur ce nouveau MLD.

Je vous remercie
MLD ci joint

[CinePhil]

Remarque générale :
Révise les types et tailles des colonnes de tes tables avant de lancer la génération de la BDD.
Exemples :
- Colonne rue de type entier !
- Colonne nomVille pas assez grande. Voir l'article de SQLPro sur les données et les normes.

1) Table Adresse
On dit un code postal, sans 'e' final !

2) Association Adherent_Proche
Un proche peut être le proche de plusieurs adhérents ?
ne s'agit-il pas ici de dire que tel adhérent couvre telle autre personne que lui-même (ses enfants par exemple) ? Un proche peut-il ainsi bénéficier de la mutuelle de plusieurs adhérents ?

3) Table Civilité
Je mettrais une colonne pour le libellé complet et une pour le libellé abrégé.
Monsieur => M.
Madame => Mme
Mademoiselle => Mle
Maître => Me
Docteur => Dr
Professeur => Pr

4) DossierPrestation_Adherent
il peut concerner plusieurs adhérents ?

5) LienDeParente
Est-ce vraiment en association avec le dossier de prestation ?
Ne s'agit-il pas plutôt du lien de parenté qu'il peut y avoir entre le proche et l'adhérent ?

Comme tu as quasiment les mêmes propriétés chez l'adhérent et le proche, je te conseille de modéliser un héritage de données :
adherent -(1,1)----Etre----0,1- Personne
proche -(1,1)----Etre----0,1-----------|

adherent |o-----------------------| Personne <= Attention, lien continu d'identification relative !
proche |o--------------------------------|

personne (idPersonne, AdresseIdAdresse, CiviliteIdCivilite, nomPersonne, prenomPersonne, telPersonne, emailPersonne)
adherent (PersonneIdPersonne, BureauIdBureau, dateDebutAdhesion, dateFinAdhesion)
proche (PersonneIdPersonne, dateDeDebut, dateDeFin)

Du coup, tes deux tables DossierPrestation_Adherent et DossierPrestation_Proche doivent pouvoir se transformer en une seule DossierPrestation_Personne.
Quant au lien de parenté, à toi de voir s'il s'agit seulement du lien de parenté entre adhérent et proche ou aussi entre proches donc entre personnes. Les libellés des liens de parentés devraient être externalisés dans une table de référence.
6) TypeTrace, TypePrime et TypeRemboursement
Les cardinalités sont inversées ; ce sont TraceDossier, Prime et Remboursement qui devraient avoir la clé étrangère.

Bon courage pour la suite !

[babouba]

Bonjour CinePhil;

Je vous remercie pour votre réactivité
J'ai noté les remarques

Je vous remercie

[babouba]

Bonjour;

2) Association Adherent_Proche
Un proche peut être le proche de plusieurs adhérents ?
ne s'agit-il pas ici de dire que tel adhérent couvre telle autre personne que lui-même (ses enfants par exemple) ? Un proche peut-il ainsi bénéficier de la mutuelle de plusieurs adhérents ?

oui un proche peut être le proche de plusieurs adhérents
mais il peut être couvert que par l'un de ces proche.

donc il peut en bénéficier de la mutuelle d'un de ces proche (adhérer)

4) DossierPrestation_Adherent
il peut concerner plusieurs adhérents ?

un DossierPrestation concerne un et un seul adhérent mais l'adhérent peut en avoir plusieurs DossierPrestations

5) LienDeParente
Est-ce vraiment en association avec le dossier de prestation ?
Ne s'agit-il pas plutôt du lien de parenté qu'il peut y avoir entre le proche et l'adhérent ?

il s'agit du lien de parenté entre bénéficiaire et adhérent (fils, femme ect...)

Merci