Discussion :

[Marco94]

Bonjour,

Je sollicite votre aide afin d'avancer sur la conception d'une base sur laquelle s'appuie une application de révision salariales (augmentation annuelle).

Je bloque en fait sur la partie validation des infos de rémunération.

Je vous montre le schéma actuel :



Les contraintes sont :
- un salarié peut être référant pôle ou référant société ou admin... ou simple salarié mais dans ce cas il n'accède pas à l'appli.
- les infos de rémunération (table T_REMUN_REM) sont d'abord importées par l'admin, puis validées par un pôle (constitué de N référants pôles), puis par le référant société, puis par l'admin.
- l'étape de validation par un pôle n'est pas obligatoire pour chaque salarié, dans ce cas la validation commence directement par le référant société.
- chaque étape de modification par les différents intermédiaires doit être enregistrée.

Mon problème est que je ne sais pas trop comment relier la table T_REMUN_REM, dois-je la relier à la table T_SALARIE_SAL ou carrément créér des tables héritées de la table T_SALARIE_SAL (ex : T_REFSOCIETE_RFS+T_REFPOLE_RFP+T_ADMIN_ADM)

Voici ma vision des choses quant à l'alimentation de la table T_REMUN_REM :
- salarié : 1151 / année : 2013 / remun : 30000 / << importé par admin ( données non modifiables)
- salarié : 1151 / année : 2013 / remun : 31000 / << par le référant pôle 1
- salarié : 1151 / année : 2013 / remun : 30500 / << par le référant pôle 2
- salarié : 1151 / année : 2013 / remun : 31800/ << par le référant société
- salarié : 1151 / année : 2013 / remun : 31800 / << par l'admin


voilà je ne sais pas si c'est bien clair, j'ai l'impression de me prendre la tête et de passer à côté de la solution la plus simple.

Merci d'avance pour votre aide.

[StringBuilder]

Honnêtement, c'est pas hyper clair pour moi, mais il faut dire aussi que j'ai pas trop le temps de me pencher en profondeur sur votre problème.

Voici une solution que je verrais pour stocker vos informations, et savoir, pour chaque employé à quelle étape du flux vous êtes : deux colonnes supplémentaires dans votre table T_REMUN_REM :
- Etape du flux
- Acteur du flux

Il vous faudra alors non pas faire une clé étrangère, mais une contrainte par trigger, dans laquelle vous vérifierez la cohérence de l'acteur du flux en fonction de l'étape.

Je verrais les règles suivantes :

Etape 1 : Ça doit être un admin
Etape 2 : Ça doit être un responsable de pôle
Etape 3 : Ça doit être un responsable de société
Etape 4 : Ça doit être un admin

On ne peut créer qu'une seule ligne à l'étape 1
On ne peut pas créer une ligne à l'étape 2 s'il n'y a pas d'étape 1
On peut créer autant de lignes à l'étape 2 qu'on veut, sauf s'il existe une ligne à l'étape 4
On ne peut créer qu'une seule ligne à l'étape 3
On ne peut créer une ligne à l'étape 3 que s'il y a une ligne à l'étape 1
On ne peut créer qu'une seule ligne à l'étape 4
On ne peut créer une ligne à l'étape 4 que s'il y a une ligne à l'étape 3

Bref, un joli trigger.

Mais à priori, ça résous vos contraintes fonctionnelles.

[fsmrel]

Bonsoir,

Je sollicite votre aide

C’est très bien, mais nous ne sommes pas censés connaître le monde dans lequel vous évoluez.

Qu’est-ce qu’un « référant » ? Un responsable ? C’est de la novlangue ? Merci d’éviter de jargonner.

Qu’est-ce qu’un pôle ?

Qu’est-ce qu’une entité ?

Quelle relation y a-t-il entre un salarié et un pôle ?

Quelle relation y a-t-il entre un pôle et une société ?

A vous lire il n’y a qu’un seul admin dans votre système. C’est bien cela ?

[CinePhil]

Quelques petites choses vite fait...

1) Utilisez des entiers pour les futures clés primaires de vos tables, donc les identifiants des entités types du MCD.
Un matricule est une clé candidate mais ne doit pas être une clé primaire car il peut être porteur de signification et/ou formaté d'une certaine manière et peut changer.

De plus, Les types des clés étrangères doivent être identiques aux types des clés primaires qu'elles référencent. Dans votre schéma, SAL_MATRICULE est de type VARCHAR dans T_SALARIE_SAL et de type INT(10) dans TJ_SALENT_SLN.

2) Je vois plusieurs boucles dans votre schéma.
Il faudra sans doute mettre en oeuvre des triggers pour assurer la cohérence des données et interdire des données qui contrevie"ndraient aux règles de gestion de l'entreprise tout en respectant le modèle de donénes.
Par exemple, d'après votre schéma :
- une rémunération R concerne un salarié S ;
- qui est référent d'une entité E ;
- qui est concernée par une campagne C ;
- qui comprend des rémunérations autres que celles de S !

3) Petit détail : Si on traduit votre diagramme entités/associations en MCD merisien, toutes les cardinalités mini sont à 1. Il faudrait éditer chaque lien entre les tables et jouer de la case à cocher "Mandatory" pour mettre certaines cardinalités à zéro.

Quant à votre problème, j'ai l'impression qu'il concerne davantage la modélisation des traitements que la modélisation des données, même si certaines contraintes peuvent être implémentées par des triggers dans la base de données.