Discussion :

[fsmrel]

Dès lundi...

O tempora, O mores ! Pauvre Paprick ! de mon temps, fin des années cinquante, la rentrée à l’université se passait début novembre...

[seabs]

Bonjour fmsrel,

Malgré une résistance tenace, l’attribut "Qualif_T_S" ayant été évacué, la base de données ne devrait que s’en sentir mieux. Cette histoire fut pour moi une variation sur le thème de la redécouverte de l’oeuf de Christophe Colomb...

Merci de nous tenir au courant une fois que vous aurez jugé que votre MCD est bien stabilisé, qu’il répond à votre besoin et est à la source d’un DDL autorisant des requêtes SQL exploitables sans complications tordues et inutiles.

Effectivement, je vous présenterai les conclusions définitives lorsque l'application sera opérationnelle. Ne pas vous inquiéter, car il va me falloir quelque temps pour développer la base et le programme correspondant.

Je tiens encore à vous remercier pour votre aide, sans laquelle j'aurai bien eu des difficultés pour inclure cette particularité d'une convention collective dans ma base de données.

Je considère dans l'immédiat cette discussion comme résolue

[seabs]

Bonjour fmsrel,

J'ai bien avancé dans la mise en place de la base ayant fait l'objet de cette discussion. J'ai apporté quelques modifications de détail au MCD, mais le schéma proposé me donne entière satisfaction.
De plus, j'ai constaté une simplification significative dans le développement du code, par rapport au pré-projet que j'avais griffonné.
L'ensemble n'est pas encore terminé, mais au niveau actuel tout semble satisfaisant pour obtenir un programme qui réponde à la demande faite.
Le moment venu, je ne manquerai pas de présenter ici le MCD définitif retenu.
Encore merci mille fois pour votre aide sans laquelle j'aurais pataugé pour sortir quelque chose de convenable.

A plus,

[fsmrel]

Bonjour seabs,
 
Voilà une bonne nouvelle ! en fait, remercions Guillaume d'Ockham qui nous a prêté son rasoir pour faire jouer le principe de parcimonie :

Pluralitas non est ponenda sine necessitate

Comme disait Laetitia avec son accent bien à elle : pourvou qué ça doure !

Bonne continuation,

François

[fsmrel]

Bonsoir seabs,

Le moment venu, je ne manquerai pas de présenter ici le MCD définitif retenu.

« Anne, ma soeur Anne » , tout se passe bien ?

[seabs]

Bonjour,

Merci de toujours t’intéresser à ce projet.

Non seulement tout se passe bien, je dirai même plus « se passe très bien ».
Je vais finir dans les prochains jours le programme. Le MCD rectifié avec votre aide m’a permis d’apporter de nombreuses simplifications dans le code.
Dès que j’ai terminé, je n’oublie pas ma promesse de présenter le MCD définitif.

Encore merci pour votre aide précieuse

À bientôt.

[escartefigue]

bonjour,

Le MCD rectifié avec votre aide m’a permis d’apporter de nombreuses simplifications dans le code.

Puissent de nombreux lecteurs comprendre ce propos : je ne compte plus le nombre de questions ici sur ce forum comme en entreprise, sur des requêtes complexes et contre performantes dont la seule raison d'être est un MCD mal conçu voire - le plus souvent- absent !

[fsmrel]

Ave,

Le moment venu, je ne manquerai pas de présenter ici le MCD définitif retenu.

 
Grâce à Looping 4.1, ça va être le moment !

[seabs]

Bonjour,

Envoyé par fsmrel
Grâce à Looping 4.1, ça va être le moment

Je te rassure, je n'ai pas oublié, mais quelques ennuis de santé ont perturbé mon activité.
Le logiciel correspondant au MCD est terminé et répond à nos attentes.
Pour l'inclure dans ce forum, j'ai une ou deux retouches à effectuer. Je pense l'inclure ici avant la fin mars.

Acceptez mes excuses pour ce retard.

Encore merci pour vos précieux conseils et votre compétence technique et pédagogique.

[fsmrel]

Ave seabs,

Tu es tout excusé, surtout remets-toi bien. On est tous contents que le logiciel tourne comme une horloge ! Prends encore ton temps avant de nous présenter un beau MCD !

[seabs]

Bonjour fsmrel,

Comme promis, je présente le MCD, le MLD et le LDD qui ont été utilisés pour établir la base des données et permettre la mise en place du logiciel pour suivre l’évolution des salaires.

Il est fort possible que, lors de l’examen de votre part, vous remarquiez quelques améliorations à apporter. Je suis toujours preneur, car je n’ai pas une pratique et une formation suffisante pour connaître toutes les subtilités de la modélisation. Quoi qu’il en soit, le logiciel développé nous donne satisfaction.

Le MCD définitif se présente ainsi :


Ce document nous donne le MLD ci-dessous.


A partir de ces éléments, nous avons le LLD ci-après.

Code :

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
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
CREATE TABLE T_QUALIF(
   QUA_NIV SMALLINT,
   QUA_ECHEL SMALLINT,
   PRIMARY KEY(QUA_NIV, QUA_ECHEL)
);

CREATE TABLE T_DATE_CONV(
   DATE_CONV DATE,
   DATE_APPL BOOLEAN NOT NULL False,
   PRIMARY KEY(DATE_CONV)
);

CREATE TABLE T_SALARIE(
   SAL_ID SMALLINT,
   SAL_STATUT CHAR(2) NOT NULL,
   SAL_MATRICULE CHAR(5) NOT NULL,
   SAL_NOM VARCHAR(50) NOT NULL,
   PRIMARY KEY(SAL_ID),
   UNIQUE(SAL_MATRICULE)
);

CREATE TABLE T_QUALIF_SAL(
   SAL_ID SMALLINT,
   QUA_DATE_SAL DATE,
   QUA_NIV_T SMALLINT NOT NULL,
   QUA_ECHEL_T SMALLINT NOT NULL,
   QUA_NIV_S SMALLINT NOT NULL,
   QUA_ECHEL_S SMALLINT NOT NULL,
   PRIMARY KEY(SAL_ID, QUA_DATE_SAL),
   FOREIGN KEY(SAL_ID) REFERENCES T_SALARIE(SAL_ID),
   FOREIGN KEY(QUA_NIV, QUA_ECHEL) REFERENCES T_QUALIF(QUA_NIV, QUA_ECHEL),
   FOREIGN KEY(QUA_NIV_1, QUA_ECHEL_1) REFERENCES T_QUALIF(QUA_NIV, QUA_ECHEL)
);

CREATE TABLE T_ACTIVITE(
   SAL_ID SMALLINT,
   ACT_DATE DATE,
   ACT_NIV_ACTIVIT SMALLINT NOT NULL,
   PRIMARY KEY(SAL_ID, ACT_DATE),
   FOREIGN KEY(SAL_ID) REFERENCES T_SALARIE(SAL_ID)
);

CREATE TABLE T_REMUN(
   REM_DATE DATE,
   REM_MODIF CHAR(2) NOT NULL,
   REM_ACTIVIT SMALLINT NOT NULL,
   REM_MONTANT DECIMAL(12,4) NOT NULL,
   SAL_ID SMALLINT NOT NULL,
   QUA_DATE_SAL DATE NOT NULL,
   PRIMARY KEY(REM_DATE),
   FOREIGN KEY(SAL_ID, QUA_DATE_SAL) REFERENCES T_QUALIF_SAL(SAL_ID, QUA_DATE_SAL) ON UPDATE CASCADE
);

CREATE TABLE T_CONTRAT(
   SAL_ID SMALLINT,
   CON_DATE DATE,
   CON_TYPE CHAR(4),
   PRIMARY KEY(SAL_ID, CON_DATE),
   FOREIGN KEY(SAL_ID) REFERENCES T_SALARIE(SAL_ID)
);

CREATE TABLE T_INDICE_PRIX(
   IND_AN SMALLINT,
   IND_DATE_CONV DATE NOT NULL,
   IND_DATE_LMIT DATE NOT NULL,
   IND_INDICE DECIMAL(6,2),
   IND_BLOCAGE SMALLINT NOT NULL,
   PRIMARY KEY(IND_AN)
);

CREATE TABLE T_SAL_DEPART(
   SAL_ID SMALLINT,
   DATE_DEP DATE,
   PRIMARY KEY(SAL_ID, DATE_DEP),
   FOREIGN KEY(SAL_ID) REFERENCES T_SALARIE(SAL_ID)
);

CREATE TABLE T_SAL_ENTREE(
   SAL_ID SMALLINT,
   SAL_DATE_ENTR DATE,
   PRIMARY KEY(SAL_ID, SAL_DATE_ENTR),
   FOREIGN KEY(SAL_ID) REFERENCES T_SALARIE(SAL_ID)
);

CREATE TABLE T_BASE_CALCUL_INDICE(
   IND_AN SMALLINT,
   SAL_ID SMALLINT,
   BAS_CON_TYPE CHAR(4) NOT NULL,
   BAS_SAL_ACTUEL DECIMAL(12,4) NOT NULL,   
   BAS_SAL_ACT SMALLINT NOT NULL,
   BAS_ACTIVIT_ACTUEL SMALLINT NOT NULL,
   BAS_SAL_BAS_CONV DECIMAL(12,4) NOT NULL,
   BAS_ACTIVIT_CONV DECIMAL(10,2) NOT NULL,
   BAS_SAL_CALCUL DECIMAL(12,4) NOT NULL,
   PRIMARY KEY(IND_AN, SAL_ID),
   FOREIGN KEY(SAL_ID) REFERENCES T_SALARIE(SAL_ID)
);

CREATE TABLE T_CONVENT(
   QUA_NIV SMALLINT,
   QUA_ECHEL SMALLINT,
   DATE_CONV DATE,
   SAL_MONT_CONV DECIMAL(12,4) NOT NULL,
   PRIMARY KEY(QUA_NIV, QUA_ECHEL, DATE_CONV),
   FOREIGN KEY(QUA_NIV, QUA_ECHEL) REFERENCES T_QUALIF(QUA_NIV, QUA_ECHEL) ON UPDATE CASCADE,
   FOREIGN KEY(DATE_CONV) REFERENCES T_DATE_CONV(DATE_CONV) ON UPDATE CASCADE
);

Je tiens, à nouveau, à vous remercier pour votre précieuse aide.

A bientôt

[fsmrel]

Bonsoir seabs,

Félicitations pour ce travail rigoureux

L’entité-type Remuneration descend d’un cran, remplacée par Qualification salarié, dont elle dépend désormais, mais du fait de la transitivité, nihil obstat.

Pour la partie historique, pas de problème, même si pour ma part j’ai l’habitude de modéliser ainsi l'historique :
 

 
MCD dans lequel je conserve la dernière date d’entrée comme attribut de l’entité-type Salarie et mets en oeuvre une entité-type faible Durant, avec deux clés candidates {CleSalarie, DateEntree} et {CleSalarie, DateDepart}. Mais c’est pour l’anecdote, chacun ses habitudes. Disons que je sous-traite le contrôle les périodes au système (c’est une manie ), mais ne vous embêtez pas avec ça.

Et maintenant, bon vent !

François

[escartefigue]

Bonjour,

quelques remarques en vrac :

• je suppose que la date d'entrée d'un salarié est obligatoire et non pas facultative et unique et non pas multiple, si c'est bien le cas, il est plus simple d'ajouter l'attribut date_entrée dans le type d'entité et de supprimer le type d'entité [SALARIE_ENTREE] ;
• la date de départ, elle, est bien sûr facultative, par contre, sauf explications complémentaires de votre part, il ne peut y en avoir qu'une seule. Ce faisant la cardinalité maximale est 1 au lieu de n.
  Là aussi, pour raison de simplification, j'aurai tendance à intégrer cet attribut dans le type d'entité [SALARIE] en utilisant la valeur par défaut 9999-12-31 pour les employés qui sont encore dans l'effectif, de sorte à éviter les marqueurs "null" ;
• la cardinalité minimale 0 de [SALARIE] vers [SAL_CON] implique que certains salariés n'ont pas de contrat de travail à confirmer, et si c'est bien le cas, la règle de gestion R060 est à corriger ;
• le statut du salarié pourrait être externalisé en créant un type d'entité [STATUT_SALARIE] avec un code, un libellé et d'autres attributs si besoin 
  Selon qu'on veut ou non connaitre l'historique des statuts du salarié, on aura soit une asso binaire soit une ternaire entre [SALARIE], [STATUT_SALARIE] et, éventuellement, une entité-type fictive [DATE] ;
• le lien entre le salarié et son indice de salaire d'une part, et le salarié et la rémunération d'autre part, sont indépendants. Or, si j'ai bien compris les règles de gestion R090 à R094, l'indice sert annuellement à revaloriser les salaires. Il faut donc que l'un et l'autre naviguent de concert. Ce dernier point mérite une explication détaillée sur le mode de fonctionnement, exemples à l'appui.

[seabs]

Bonjour,

@fsmrel, @escartefigue

J’ai lu vos remarques, sous quelques jours, je vais les analyser en détail dans le but de vérifier que le fonctionnement du logiciel développé ne présente aucun risque. Bon, il faut savoir que l’entreprise ne compte que 70 salariés, détail qui permet de retrouver rapidement une anomalie.

En plus, elle comporte des particularités et notamment pour les salariés en CDD qui peuvent avoir plusieurs périodes d’emploi, mais, en raison d’une contrainte présente dans le logiciel de paie, il est obligatoire de conserver le même matricule d’où une difficulté qui a été traitée avec l’approche mise en place pour les entrées et les sorties. Je vérifierai s’il est possible de mieux faire.

Pour les règles de gestion définies en tête de cette discussion, elles n’ont pas été actualisées.

En tout état, je vais examiner les conséquences de vos remarques et, si nécessaire, je ferai des ajustements. Les volumes étant faibles, il est possible d’actualiser l’ensemble sans nécessiter un travail gigantesque.

Je vous tiens au courant et vous présenterai une réponse détaillée le moment venu.

Merci de vos remarques et à bientôt.