Discussion :

[mimiferry]

Pièce jointe 457701

Bonjour tout le monde,

Etudiante en deuxième année informatique, je souhaite concevoir un modèle conceptuel de données MCD pour la gestion de la paye.
le MCD est tellement complexe, mais la partie ou je me bloque un peu concerne la logique a transcrire en MCD en utilisant les entités suivant :

• Organisme sociaux (ASSEDIC, Pole Emploi, Caisse retraite ..............)
• Charges sociaux
• Paye
• Rubriques (éléments) de paye

J aimerai avoir vos suggestions ou éléments d'analyse supplémentaire me sera très utile

[CinePhil]

Bonjour,

Étant donné qu'il existe une foule de logiciels de paye et que c'est effectivement un domaine complexe et très réglementé, je m'étonne que vous ayez besoin de vous lancer là-dedans !

Commentaires sur votre MCD...

1) Utilisez plutôt des verbes à l'infinitif pour vos associations.
"Composer", "Soumettre", "Verser"...
J'utiliserais d'ailleurs plutôt le verbe "Assujettir" au lieu de "Soumettre".

2) Bannissez les mots réservés du langage SQL de vos noms de tables, propriétés, associations... et plus tard de vos autres objets de base de données.
Ça peut causer des problèmes de syntaxe.
=> Propriété "Date" de l'association "Verser" : préférez par exemple "date_versement".

3) Association "Composer"
Si une paye est effectivement composée d'au moins une rubrique, toute rubrique n'entre pas forcément dans la composition d'une paye. Vous pouvez enregistrer toutes les rubriques de paye possibles avant d'avoir créé la moindre paye.
=> Cardinalités 0,n du côté de "Rubrique_paye"

4) Association "Soumettre" ou "Assujettir"
Idem ci-dessus : cardinalités 0,n du côté de "Charge_sociale"

Une rubrique de paye peut vraiment être soumise à plusieurs charges sociales ?

Peut-être y a t-il confusion de ma part dans ce que vous entendez par "Rubrique_paye"...

5) Association "Verser"
Je trouve étonnant qu'une charge sociale puisse être versée à plusieurs organismes !
Pouvez-vous me donner un exemple ?

Que veut dire votre "date" ?
Est-ce le jour du mois, du trimestre ou de l'année auquel la charge sociale doit être versée à l'organisme social ?
Si oui, alors le type Date n'est pas pertinent. Il vaut mieux un entier qui donne le numéro du jour (dans le mois, dans le trimestre ou dans l'année).

6) Une paye est versée à un salarié.
=> Il manque l'entité-type "Salarie" et l'association avec la "Paye".

7) Externalisez le "type_rubrique".
Vous auriez intérêt ici à déporter le "type_rubrique" dans une entité-type et à l'associer à "Rubrique_paye". Cela évite les saisies différentes du même type, cela gagne de la place en mémoire puisqu'il n'y a plus qu'une clé étrangère entière référençant le type dans la table des rubriques et ça permet d'adjoindre des informations complémentaires au type, telles que des dates de validité, par exemple (prélèvement à la source à compter de janvier 2019).

8) Entité-type "Charge_sociale"
Plutôt que des montants, ne faudrait-il pas ici des taux et une base applicable ?
Cette entité-type modélise l'ensemble des charges sociales possibles, pas la charge sociale de la paye de Jean Dupont pour le mois de mars 2019.

"Periode" ne peut pas être de type DATE !
Une période est un intervalle entre deux dates. Je ne vois d'ailleurs pas ce que représente cette notion de période ici ! Pouvez-vous nous l'expliquer ?

Vous auriez intérêt à coder vos charges sociales donc ajouter une propriété "code" (ex. : "ASSMALPLAF" pour "Assurance maladie plafonnée").

9) Entité-type "Organisme_social"
"Code_organisme" constituera une mauvaise clé primaire.
=> Ajoutez un identifiant technique de type entier.

10) Évitez les types "texte" !
Réservez ce type aux textes longs, commentaires...
Pour les libellés, noms, intitulés... qui sont des textes courts, potentiellement munis d'une contrainte d'unicité, préférez le type VARCHAR.
Pour les codes, qui sont généralement des textes très courts et de longueur fixe, préférez le type CHAR.

Remarque : Un code postal, un numéro de référence ou de série, même composé que de chiffres, sont de type CHAR. On ne fera pas de calcul avec !

[mimiferry]

Excellente remarque j'applique cette modif


Voici le MCD révisé selon vos conseils et remarques
Pièce jointe 458194

[CinePhil]

Il me semble que Oui, mais pas cetraine, de plus depuis que le prélèvement à la source, je pense que pour un élément de paye X doit y voir une partie qui sera verser à la retraite par exemple et une autre partie doit etre verser à l'assurance, impôt ........... Mais à confirmer

Ouh là ! Vous mélangez des choses il me semble !
L'entreprise qui verse un salaire et paye les charges sociales y afférant ne s'occupe pas de la retraite !

Classiquement, sur un bulletin de paye, il y a la ligne du salaire brut puis les lignes des différentes charges salariales et patronales. D'ailleurs, la partie patronale et salariale sont exprimées sur deux lignes, il me semble (je n'ai pas mon bulletin de paye sous les yeux). Donc ça fait 2 rubriques pour le même objet.

7) Externalisez le "type_rubrique".
Vous auriez intérêt ici à déporter le "type_rubrique" dans une entité-type et à l'associer à "Rubrique_paye". Cela évite les saisies différentes du même type, cela gagne de la place en mémoire puisqu'il n'y a plus qu'une clé étrangère entière référençant le type dans la table des rubriques et ça permet d'adjoindre des informations complémentaires au type, telles que des dates de validité, par exemple (prélèvement à la source à compter de janvier 2019).

Externaliser le type-element oui mais comment

Et bien selon la règle de gestion suivante :
Une rubrique de paye est typée d'un type de rubrique et un type de rubrique peut typer plusieurs rubriques.

MCD :
type_rubrique -0,n----typer----1,1- rubrique

8) Entité-type "Charge_sociale"
Plutôt que des montants, ne faudrait-il pas ici des taux et une base applicable ? Pas sûr d'voir compris cette remarque, le type des attributs "Total_charge_patronal" et "total_charge_salarial" sont de type "Monnaie et sont calculable a partir de la table "élément_paye" mais ils peuvent être modifié si une meilleur solution s'impose

Là j'ai l'impression qu'il y a confusion entre ce que je pourrais appeler la bibliothèque des rubriques et des charges sociales et les charges sociales réellement versées à tel organisme pour la paye de tel salarié tel mois.

La paye P1 de tel salarié S1 pour tel mois M1 est composée de la rubrique R1. C'est dans l'association Composer que se trouvent les valeurs.
L'entité-type Element_paye (je ne comprends pas pourquoi vous avez changé son nom !) contient le catalogue de tous les éléments possibles (congés, salaire, prime...). Certains éléments (presque tous, hélas, je pense ) sont soumis à des charges sociales selon un certain taux applicable et parfois sur une base de calcul qui n'est pas la totalité de l'élément. Je ne suis pas spécialiste de la paye mais il me semble que, par exemple, l'assurance maladie est calculée sur le plafond de la sécu à un certain taux et sur ce qui dépasse à un autre taux. Idem pour la retraite avec les tranches A, B... Donc l'entité-type Charge_sociale représente, là aussi, le catalogue de toutes les charges sociales applicables. Le calcul du bulletin de paye, ligne par ligne, se fait en fonction des informations figurant dans ce catalogue. Je ne pense pas qu'il y ait de montant fixe de charge sociale mais uniquement des taux.
L'association de Charge_sociale avec Organisme_social indique seulement à quel organisme doit être versé telle charge sociale, avec indication de la périodicité de paiement (le 5 du mois, le 10ème jour du trimestre...).
C'est par le calcul sur les données des bulletins de salaire qu'on saura combien on doit payer à l'organisme. Si ça doit être mémorisé, ça doit être modélisé en plus.

[seabs]

Bonjour,

@CinePhil

Le calcul du bulletin de paye, ligne par ligne, se fait en fonction des informations figurant dans ce catalogue. Je ne pense pas qu'il y ait de montant fixe de charge sociale mais uniquement des taux.

Il peut exister des lignes de charges fixes notamment pour la prévoyance maladie complémentaire. Le taux peut-être fixe ou proportionnel avec le nombre de personnes présentes dans la familles. Le calcul a donc rien à voir avec le salaire de l'intéressé. Il me semble donc nécessaire de prévoir cette option.

Bon après, je n'ai pas examiné le détail du MCD qui effectivement ne peut-être que complexe compte tenu de l'usine à gaz de la paye inventée par la France.

Bon courage
A+

[mimiferry]

Bonjour tout le monde,

A ce jour, voici mon MCD comment il est modélisé
Les questions que je me pose c'est de savoir s'il y a des associations qui doivent être porteuses d'attributs
Vous remarquerez aussi que l'entité Salarie doit etre décomposer en plusieurs entités pour sortir Catégorie, Qualification.......

A vos remarques

Pièce jointe 458498

[seabs]

Bonjour,

J'ai regardé ton MCD sans détailler l'ensemble.

Cependant, mon attention est attirée par le fait qu'il n'existe aucune entité des bulletins. Or, il me semble nécessaire d'historiser les bulletins car dans la paie les changements des différents paramètres sont permanents. Avec ton approche, si tu veux éditer un bulletin de l'année précédente, il sera effectuer avec les données présentes dans les entités au jour de l'édition et non avec les éléments de la période concernée.

Il s'agit juste d'un avis.

Bon courage.

[CinePhil]

Pas sûr d'avoir le temps de commenter tout le MCD mais je commence, en vrac...

1) Pourquoi avoir mis des numéros aux entités-types "Organisme_social3", "Charge_sociale2", "Rubrique_paye2" et "Type_rubrique2" ?

2) "Organisme_social"
a) Code_organisme sera une mauvaise clé primaire !

b) 25 caractères pour les intitulés 1 et 2, c'est peut-être un peu juste.

c) Pourquoi 2 intitulés ?

d) Num_affiliation est un numéro, pas un nombre. Vous ne n’additionnerez ou ne ferez jamais la moyenne entre ces numéros. Il est possible que ce numéro contienne des caractères chez un organisme.
=> Choisissez le type VARCHAR. Renseignez-vous sur le nombre de caractères employés par les différents organismes pour avoir le max et prenez une petite marge au cas où vous n'auriez pas tous les organismes tout de suite.

2) Ensemble "Convention_collective" et "Employeur"
Modélisez-vous un futur logiciel de paye pour une entreprise de service de paye qui fait la paye de plusieurs entreprises ?
Si c'est pour une seule entreprise, il ne me semble pas utile de modéliser ça. Vous modélisez alors le domaine paye de votre entreprise.

D'ailleurs, plus généralement, j'avais fait part, dans mon premier commentaire, de mon étonnement sur le choix du sujet vu qu'il existe déjà plein de logiciels de paye. Dans quel but faites-vous ça ?

3) Évitez le type TEXT
À moins que ce soit une généralisation de votre logiciel de modélisation (quel est-il ?), essayez d'utiliser les types SQL standard et choisissez les tout de suite de manière la plus pertinente possible :
- identifiants (futurs clés primaires et clés étrangères) de type entier auto-incrémenté ;
- codes, abréviation et numéros à tailles fixes et courtes de type CHAR ;
- libellés, noms, titres, morceaux d'adresse postale, url, chemins de fichiers... de tailles un peu plus longue de type VARCHAR ;
- commentaires, textes, articles, messages... pouvant être de grande taille de type TEXT, voire LONGTEXT ;
- dates de type DATE...

4) "Employeur"
a) Externalisez la forme juridique dans une entité-type de référence et associez là à Employeur.

b) Le SIRET est de taille fixe donc de type CHAR.

c) L'adresse se décompose au moins en ville (externalisée dans une entité spécifique pour éviter d'avoir 100 fois la même ville, potentiellement sous des orthographes différentes), code postal et morceaux d'adresse. Voir la norme postale. Vous pouvez voir la discussion que j'ai ouverte à propos de la modélisation des adresses postales étrangères et l'avis donné par SQLPro à ce sujet.

d) Un employeur ne peut-il avoir plusieurs numéros de téléphones utiles pour le domaine (accueil, service RH, sous-service paye, comptabilité...) ? Il est d'usage d'externaliser les numéros de téléphone et de les typer ou de les traiter par contact personne physique. Je vous invite à y réfléchir.

e) Les codes APE sont une liste définie et doivent être externalisés dans une entité-type de référence.

f) Que voulez-vous mettre dans "activite" ?
La nomenclature des activités est celle des codes ape, non ? Comptez-vous en utiliser une autre ?
Plusieurs entreprises auront la même activité. Je vous invite dans tous les cas à externaliser les activités.

g) Que comptez-vous mettre dans urssaf_employeur ?
Pourquoi ne pas avoir fait d'association entre Employeur et Organisme_social puisque l'URSSAF y figurera sans doute ?
Ou bien ne peut-on trouver l'urssaf_employeur via le salarié et sa paye ?

h) logo : stocker des images dans une base de données est une mauvaise idée, sauf si vous utiliserez un SGBD qui sait gérer complètement les fichiers via le type DATALINK ou FILESTREAM.


Ce message commence à être long, je vais arrêter là les remarques pour aujourd'hui.

[mimiferry]

@CinePhil
Merci une autre fois pour vos remarques et celles ci seront prises en considération. J'utilise pour modéliser le logiciel Power Designer.
Donc vous suggérez de décomposer l'entité "employeur " en transformant en entités les attributs activité, forme juridique, ville et APE. Je vais devoir revoir tous ça aujourd'hui et je publierai le résultat.

[mimiferry]

@Seabs

(..........Cependant, mon attention est attirée par le fait qu'il n'existe aucune entité des bulletins. Or, il me semble nécessaire d'historiser les bulletins car dans la paie les changements des différents paramètres sont permanents. ............)
L'entité "paye" qui a comme attributs du(date) et au(date) est modélisé pour le(s) bulletin(s) de paye. Toutes les autres informations figurant dans un bulletin de salaire provient d'autres entités à savoir salarié, employeur, rubrique_paye.

[seabs]

Bonjour,

Ok, j'ai compris ton approche. Il faut dire que je n'avais pas vu l'entité Paye.

Par contre, il ne semble pas nécessaire d'inclure le taux de charges patronales et le taux de charges salariales dans deux entités différentes. En l'occurrence, Charge_Sociale2 et Rubrique_Paye2. La présence dans la première entité me semble suffisante.

Dans le premier MCD, il me semble que c'était le choix fait.

Bon j'arrête ici, car je ne vais pas perturber la discussion que tu as avec @CinePhil, lequel a travaillé plus que moi sur ton projet.
Bon courage car conduire un MCD aussi important nécessite du temps et de l'attention.

[escartefigue]

Bon courage car conduire un MCD aussi important nécessite du temps et de l'attention.

Et aussi de solides connaissances réglementaires, pensez à bien faire valider vos règles de gestion puis votre MCD par des experts métier, le domaine abordé est sensible

[mimiferry]

Bonjour tout le monde,

Merci encore une autre fois pour remarques et commentaires, cela m'a aidé à corriger mon MCD

@CinePhil, J'ai bien appliqué les modifications que vous m'avez proposer et voici le MCD à jour
J'ai externalisé de l'entité Employeur, le statut juridique, Adresse, APE, et Division(les entités en couleur rouge). L'entité "Adresse" est créé telle que vous l'avez proposé dans le forum que vous avez crée !
toutes les clés primaires sont en entier auto incrémente. les formats Texte sont corrigés !


Toute remarque ou suggestion sera encore précieuse de votre part, dites moi ce que vous en penser !
Je vous remercie par avance !

Pièce jointe 468042

[escartefigue]

Bonjour,

Quelques remarques en vrac :

De nombreuses cardinalités sont à revoir.
Par exemple :
ADRESSE 0,n --- situer --- 0,n EMPLOYEUR à remplacer par ADRESSE(1,1) --- situer --- 0,n EMPLOYEUR<== une adresse c'est un et un seul employeur, on peut identifier l'adresse relativement (parenthèses) à l'employeur
idem entre diplôme et salarie
de salarié vers permis : un salarié devrait pouvoir avoir plusieurs permis


L'entité-type RIB n'a pas d'identifiant et les attributs ne sont pas typés


Absence et congés sont des absences, il est donc préférable de ne modéliser qu'une seule entité-type et procéder par héritage si nécessaire (s'il existe des attributs ou des relations spécifiques à tel ou tel type d'absence) ou bien typer l'absence (absence de type CP, RTT, maladie...) au moyen d'une relation vers une nouvelle entité-type "type-absence"


En l'état, rien n'interdit qu'un salarié réalise des heures supplémentaires pendant ses périodes d'absence...


Dans l'entité-type banque, l'identifiant primaire ne doit surtout pas être le code banque. Choisissez un identifiant primaire stable et donc asémantique. Un chrono affecté par le SGBD est ce qui est le mieux


Rares sont vos relations à date, c'est probablement un oubli (exemple l'emploi d'un salarié est forcément à date)


Je ne vois nulle part la notion de fonction exercée par le salarié, or, il me semble que la fonction pilote des éléments de la paye. Là aussi, une relation à date s'impose si la fonction est requise


Bizarrement, vous avez nommé l'entité-type "APE" (ancien code activité principale, à ma connaissance ce code est obsolète) alors que l'attribut est bien le code NAF qui remplace le code APE.
Il me semble que "Activité" serait plus approprié comme nom d'entité (pour ne pas dépendre des évolutions réglementaires éventuelles)


A priori, le code banque du RIB est toujours celui de la banque de rattachement. A vérifier. Si avéré, il y a redondance.


Dans les différentes entités-type où il y a un téléphone, vérifiez que vous n'avez besoin que d'un et un seul numéro, dans le cas contraire (zéro à plusieurs tél requis), externalisez les téléphones dans une entité-type dédiée.
Exemple : SALARIE 0,n --- posseder --- (1,1) TELEPHONE 1,1 --- typer --- 0,n TYPE_TEL

[mimiferry]

Bonjour Escartefigue;

Tout d'abord grand merci pour tes commentaires, cela m'a bien aidé à réviser bien le MCD


Je trouve que c'est une excellente idée de créer une seule entité-type pour Absence et congé et cela donc est fait, Je l'ai nommé volontairement "Absence_et_conge" et la typer dans une autre entité-type

A propos des relations à date, je m’interrogeais depuis un moment, quelle relation doit être à date et ça tombe bien que vous m'avez fait cette remarque
A priori (Si je me trompe pas) tout relation de N- N peut être porteuse d'attributs ou date, c'est bien correcte ? j'ai donc fait ça sur des relations susceptible d’être à date.


Concernant l'entité-type APE, en fait en France les Activités exercés par chaque employeur sont répartie en division et un code APE est attribué à chacune, Il était donc nécessaire de créer deux entités "APE et Activité"
Source : https://blog.easyfichiers.com/wp-con...de-naf-ape.pdf

Pour la dernière remarque concernant les num de téléphones. vous êtes la deuxième personne à me proposer de modéliser les numéro de téléphone, mais j'avoue que j'ai pas compris comment procéder, A priori chaque salarie possède peut avoir plusieurs num à savoir num personnel, num professionnel, fixe.... de la meme manière un service peut avoir plusieurs num,
Es ce que cette modélisation serai correct ?
Entité-type Num_Telephone( #Id_num, num1, num2, num3)
Type_num(#Id_type, Type_num) Ps Type_num = Numero peronnel, Numero professionnel, Numero fixe, télécopie, Fax

J'ai également externalisé les type de contrat et profils salarie car ils sont une liste bien définis
Concernant la table Banque et RIB, je l'ai pas encore fait car je doit d abord l'a bien étudier

Au passage, j'aimerai poser une question, en général si on externalise les types dans une entité_type, doit-on garder son attribut dans l'entité principale ? Si oui, la valeur d'un attribut utilisé sera stocké deux fois( sur l'entité principale et sur l'entité ou celle ci est typée )


Voici donc le MCD mis à jour et dites moi ce que vous en pensez

Pièce jointe 470388

[escartefigue]

Bonjour,

Je trouve que c'est une excellente idée de créer une seule entité-type pour Absence et congé et cela donc est fait, Je l'ai nommé volontairement "Absence_et_conge" et la typer dans une autre entité-type

D'une façon générale, le nom du type d'entité doit être suffisamment générique pour permettre que la table résultante stocke différents types d'une même entité
C'est pourquoi un nom comme "absence" est préférable, car vous y stockerez des occurrences qui correpondent à des congés payés, des RTT, des arrêts maladie, des congés sans solde, des récup...

Par ailleurs, peut être faut il prévoir un statut de l'absence (prévu, confirmé...)
Peut-être faut il même avoir deux relations : l'une pour les absences prévues (ex : demandes de congés), l'autre pour les absences effectives qui peuvent bien sur être différentes
Dans tous les cas, la date seule ne saurait suffire, une absence peut ne concerner qu'une demi-journée, il faut également prévoir un horodatage pour la fin de l'absence et bien sur un contrôle de non chevauchement

A priori (Si je me trompe pas) tout relation de N- N peut être porteuse d'attributs ou date, c'est bien correcte ? j'ai donc fait ça sur des relations susceptible d’être à date.

Peut être porteuse oui doit être porteuse non.

Concernant l'entité-type APE, en fait en France les Activités exercés par chaque employeur sont répartie en division et un code APE est attribué à chacune, Il était donc nécessaire de créer deux entités "APE et Activité"
Source : https://blog.easyfichiers.com/wp-con...de-naf-ape.pdf

Ce document ne fait que donner la liste des codes NAF (ceux dont j'indiquais qu'ils remplacent les codes APE)
Le code NAF sur 5 caractères a remplacé l'ancien code APE qui n'en comportait que 4 il y a une dizaine d'années.
Ces deux codes sont des codes activité de l'entreprise donc l'entité-type devrait s'appeler "activite_entreprise" ou quelque chose d'approchant, et l'un des attributs devrait être le code NAF sur 5 carractères tels que ceux communiqués dans le document PDF.

Pour la dernière remarque concernant les num de téléphones. vous êtes la deuxième personne à me proposer de modéliser les numéro de téléphone, mais j'avoue que j'ai pas compris comment procéder, A priori chaque salarie possède peut avoir plusieurs num à savoir num personnel, num professionnel, fixe.... de la meme manière un service peut avoir plusieurs num,
Es ce que cette modélisation serai correct ?
Entité-type Num_Telephone( #Id_num, num1, num2, num3)
Type_num(#Id_type, Type_num) Ps Type_num = Numero peronnel, Numero professionnel, Numero fixe, télécopie, Fax

Non ! jamais de modélisation à plat avec des données répétées telles que num1, num2, ... numn
J'avais donné la bonne façon de faire dans ma réponse du 18-04 à 14h12, la bonne modélisation est la suivante :
SALARIE 0,n --- posseder --- (1,1) TELEPHONE 1,1 --- typer --- 0,n TYPE_TEL

Ce qui donne les tables suivantes (PK soulignées, FK suffixées par #)
SA_SALARIE(SA_id, SA_nom, SA_prenom...)
TE_TELEPHONE(SA_id#, TE_id, TE_numero, YT_id#...) <-- l'identification du téléphone relativement au salarié fait que la PK du salarié participe à la PK du téléphone
YT_TYPE_TEL(YT_id, YT_code, YT_libelle...)

Si un même salarié possède 3 téléphones, il y aura, pour ce salarié, 3 occurrences dans la table TE_TELEPHONE.

Au passage, j'aimerai poser une question, en général si on externalise les types dans une entité_type, doit-on garder son attribut dans l'entité principale ? Si oui, la valeur d'un attribut utilisé sera stocké deux fois( sur l'entité principale et sur l'entité ou celle ci est typée )

Ne confondez pas le niveau conceptuel et le niveau logique
Conceptuellement (MCD), l'attribut n'est présent que dans l'entité-type (parfois dans l'association)
Au niveau tabulaire (MLD et MPD) certains attributs, les foreign keys, sont dupliqués dans la table coté 1 de la relation si la cardinalité maxi est 1, ou dans la table issue de l'association pour les relations dont les cardinalités maxi sont n de chaque coté

Voici donc le MCD mis à jour et dites moi ce que vous en pensez

J'y reviendrai plus tard faute de temps pour le moment

[mimiferry]

Bonjour escartefigue,

Merci pour vos remarques,
Désolée j'ai pas pu réponse rapidement faut du temps
Voici le MCD mis à jours avec les corrections que vous m'avez proposer et j'ai aussi étudie de près l'entité RIB et Banque
Du coup, l'entité "Téléphone" sera relié à employeur, salarié, banque et pourquoi pas à organisme social
Certe, il reste encore du travail à faire et peut être des entités encore à créer

A vos remarques !

Pièce jointe 473539

[escartefigue]

En vrac :
- le matricule du salarié n'a rien à faire dans l'entité-type "TELEPHONE"
- l'identitiant du type de téléphone n'a rien à y faire non plus
- puisque le téléphone est désormais une entité-type, il faut supprimer l'attribut téléphone de l'ET "SALARIE"
- supprimez également les attributs "situation_fam" et "civilité", tous deux doivent être externalisés dans deux entité-type "CIVILITE" et "SITUATION_FAM" en relation avec l'ET "SALARIE"
- idem pour les attributs "profil", "categorie", "qualification"
- l'identifiant de la ville ne doit pas apparaitre dans l'ET "ADRESSE", vous pouvez externaliser les villes dans une ET spécifique et mettre en relation "ADRESSE" et "VILLE", mais attention aux adresses étrangères le cas échéant

[mimiferry]

En vrac :
- le matricule du salarié n'a rien à faire dans l'entité-type "TELEPHONE"
- l'identitiant du type de téléphone n'a rien à y faire non plus
- puisque le téléphone est désormais une entité-type, il faut supprimer l'attribut téléphone de l'ET "SALARIE"
- supprimez également les attributs "situation_fam" et "civilité", tous deux doivent être externalisés dans deux entité-type "CIVILITE" et "SITUATION_FAM" en relation avec l'ET "SALARIE"
- idem pour les attributs "profil", "categorie", "qualification"
- l'identifiant de la ville ne doit pas apparaitre dans l'ET "ADRESSE", vous pouvez externaliser les villes dans une ET spécifique et mettre en relation "ADRESSE" et "VILLE", mais attention aux adresses étrangères le cas échéant

Bonjour escartefigue

Vraiment grand merci pour le temps que vous avez consacré pour mon MCD

Voici le MCD modifié selon vos propositions
J'ai donc supprimé tous les attributs externalisés
les entités type Ville, Civilité, SituationFamille, Catégorie et Qualification sont rajoutés
Vous remarquerez que j'ai crée une association non pas à trois pattes mais 5, il s'agit de la relation entre Salarié et Civilité, SituationFamille, Catégorie et Qualification ! Je suis pas certaine de bon fonctionnement d'une telle association, je modifierai s'il le faut ! J'utilise Acces 2016 comme SGBD

Je suis entrain de réfléchir sur une éventuelle Entité type pour les sortie salaries, mais sur l’entité "Contrat" il y a bien les attributs Date d'embauche et Date fin contrat
Laissez moi savoir s'il y aura encore des suggestion



Pièce jointe 473878

[mimiferry]

Bonjour tout le monde

Grand merci pour votre aide, remarques et commentaires, cela m'a bien aidé à realiser ce projet !

C'est donc résolu