Personne réelle/Personne "anonyme" : affecter le premier au second

**Kropernic** · 23/01/2014, 10h50

Bonjour,

Derrière ce titre sans très peu claire, se cache en fait quelque chose d'assez simple à expliquer.

Objectif du projet : pouvoir planifier un horaire de travail aux employés actuels et futurs d'un magasin.

Dans un premier temps, tout a été discuté sans jamais évoqué la possibilité de planifié un horaire pour une personne "inexistante" (il est évident qu'elle existe quelque part mais d'un point donnée, dans ma DB, c'est le néant à son sujet).

La modélisation s'est donc faite comme indiqué dans la pièce jointe "mcd.png".

(Je ne me suis pas embêté à mettre les cardinalités car, même si ça fonctionne maintenant depuis un mois sans encombre, je me rends compte qu'il y a des problèmes de modélisation que je n'avais pas réaliser sur le coup.

Les données incluant des données temporelles, cela touche à la 6e forme normale que je ne maitrise pas encore (d'où les erreurs de modélisation).

Mais là n'est pas le sujet. Ca fonctionne et mon boss et les utilisateurs sont contents.)

Un employé peut donc être un chef d'équipe et appartenir à une ou plusieurs équipes. Un chef d'équipe dirige une ou plusieurs équipe (ce qui est assez logique

) et établit les plannings qui sont donnés aux employés.
Le fait de ne pas relier les plannings aux équipes ni même au chef est volontaire. Cela permet une gestion plus aisée des employées qui seraient dans plusieurs équipe. De cette manière, lorsqu'un chef désire créer un planning pour un employé, il reçoit automatiquement ce qui a déjà été planifié par cet employé. Cela évite à un employé de se retrouvé avec un planning lui demandant d'être à deux endroits en même temps

.

Jusqu'ici donc, pas de souci. Là où ça se complique, c'est qu'on me demande à présent de pouvoir établir un planning sur des personnes fictives. En effet, un magasin doit établir les plannings de son personnel 4 semaines à l'avance. Or, pour des périodes de grandes affluences (comme les soldes par exemple), un magasin a recours à du personnel supplémentaire qu'il engage parfois seulement 2 à 3 jours seulement avant le début effectif de cette personne. Etant donné les données sur les employés proviennent du département HR, il est évident que ce personnel supplémentaire ne figure nulle part dans mes données et qu'il est donc impossible de lui attribuer un planning.

L'idée serait donc de créer des personnes "anonymes" (fictives en fait), de leur attribuer un planning et que, lorsque la personne, a qui se planning sera donné, sera connue du système (ie. introduite dans la DB via les RH), il soit possible de lui dire que l'anonyme X devient en fait l'employé 1234. Cette affection serait faite par un responsable dans le magasin.

J'ai déjà envisagé plusieurs scénarios mais ils débouchent tous inévitablement sur une modification de la cléf primaire de l'une ou l'autre table et conduisent à ce que l'utilisateur tente de violer les contraintes d'intégrité référentielles. Bref, ça ne va pas...

Je viens donc chercher des pistes de modélisation. Je ne demande pas de solution "clef sur porte". Juste une piste.

Il est tout de même sans doute nécessaire que la table des employés est mise à jour par un batch de nuit. Je reçois les données de notre secrétariat social, mets à jour les employés existant et insère les nouveaux.

Merci d'avance pour vos suggestions pour simplement d'avoir pris la peine de lire ce message.

**Kropernic** · 23/01/2014, 12h35

Une fois de plus, je pense que le fait de devoir l'expliquer à quelqu'un d'extérieur au problème m'a permis d'y voir plus clair.

En modifiant le "MCD" du message précédent pour arriver à celui de ce message, je pense arriver à une solution satisfaisante. Elle demandera néanmoins l'adaptation de quelques procédures stockées pour prendre cela en compte mais bon... On n'a rien sans rien.

J'ai ajouté une entité Anonyme. Un anonyme peut appartenir à plusieurs équipe. Un anonyme peut recevoir plusieurs planning. Un anonyme peut être affecté à un employé (c'est la liaison en pointillé dont j'ai oublié d'indiqué le verbe

).

Et je crois qu'on y est. Qu'en pensez-vous ?

**frm013** · 23/01/2014, 12h59

Bonjour Kropernic,

Une piste de réflexion générale, pourquoi ne pas raisonner par postes ?

Vous affecteriez des postes au planning, et des employés aux postes.

Exemple :

Vendeuse n°2 affectée au rayon homme du 03.02.2014 au 08.02.2014

Par la suite, le responsable décide après embauche de Sylvie M. quelle sera la vendeuse n°2.

Qu'en pensez vous?

Cordialement,
François

**Kropernic** · 23/01/2014, 13h28

@frm013 :
Tout a déjà été développé et le système est déjà en production. Il est donc un peu tard pour changer totalement de manière de procéder

Concernant ce que j'avais suggéré dans mon message précédent, en l'état, cela conduirait à ce que la table T_PLANNING_PLA (contenant les plannings) contiennent deux clefs étrangères pouvant être NULL (à savoir une EMP_ID référençant la clef primaire de la table des employés et ANO_ID qui référencerait la clef primaire de la future table T_ANONYMOUS_ANO (contenant les anonymes).

Or le NULL, c'est mal !

Il me faudra donc une seconde table pour les plannings réservées aux plannings des anonymes avec une vue par dessus pour unir les deux.
Sans oublié une gestion des conflits lors de l'affection d'un anonyme à un employé (car l'un et l'autre pourraient déjà avoir reçu leur planification respective).

**frm013** · 23/01/2014, 14h08

ok, je comprends.

Mais vous partez avec 2 schémas de planning avec les problèmes de mises à jour et de conflits dont vous parlez.

Donc, à part généraliser EMPLOYE et modifier la patte de RECEVOIR, je ne vois pas de solution élégante...

Quelque chose comme ça :

Je pense que vous pourriez maquiller la modif physique avec une vue non? Mais je ne connais pas l'application...

Devez vous aussi prévoir les affectations des anonymes aux équipes?

**Kropernic** · 23/01/2014, 14h20

Envoyé par frm013

ok, je comprends.

Mais vous partez avec 2 schémas de planning avec les problèmes de mises à jour et de conflits dont vous parlez.

Bin c'est vrai que ça m'ennuie mais si j'y suis obligé, et bien tant pis.

Envoyé par frm013

Donc, à part généraliser EMPLOYE et modifier la patte de RECEVOIR, je ne vois pas de solution élégante...

Quelque chose comme ça :

Je pense que vous pourriez maquiller la modif physique avec une vue non? Mais je ne connais pas l'application...

Cette solution apporte, à priori, le même problème que celle que je vais expliquer plus bas :-/

Envoyé par frm013

Devez vous aussi prévoir les affectations des anonymes aux équipes?

Oui oui. Un anonyme est "juste" un employé un peu spécial.

De ce fait, j'ai déjà envisagé en :

créant les entités employé_anonyme, employé_réel ;
en migrant la plupart des attributs de l'entité employé actuelle vers l'entité employé_réel ;
en faisant hérité employé_anonyme et employé_réel de l'entité employé.

De cette manière, une seule entité planning suffit. De même que je n'ai plus qu'une relation n;n entre employé et équipe (au lieu deux qui relieraient respectivement employé et anonyme à équipe).
Mais il reste toujours le problème de la gestion des conflits. Mais c'est déjà nettement mieux que les cas où j'en arrivais à des changements de valeur de clefs primaires dans une table

.

J'ai l'impression que je ne vais pas avoir le choix que de faire avec cette gestion de conflit.

**frm013** · 23/01/2014, 14h37

Avec cette méthode d'ou viennent les conflits dont vous parlez?

Un employe_anonyme devient un employe_reel, il garde le même ID... non ?

**Kropernic** · 23/01/2014, 15h17

Ah bin oui, vous avez raison. Faut vraiment que je fasse plus attention.

En théorie, ça va bien.

Le souci vient de ce petit détail mentionné dans mon premier message et auquel je me doutais qu'on n'y prêterait pas attention :

Envoyé par Kropernic

Il est tout de même sans doute nécessaire que la table des employés est mise à jour par un batch de nuit. Je reçois les données de notre secrétariat social, mets à jour les employés existant et insère les nouveaux.

Du coup, je crée mon employé anonyme et je lui fais son planning. Une nuit, la personne "attendue" par le magasin arrive dans la table des employés réels. On a alors bien deux identifiants différents :-/

Cette duplicité fait que, de facto, il n'est pas impossible qu'un chef ajoute cette personne dans une équipe et lui prévoie un planning. Ce qui fait que, en plus d'avoir 2 identifiants différents, il faudra quand même faire de la gestion de conflit

Si j'avais un moyen de faire directement l'association réel/anonyme au moment de la mise à jour des employés réels, je pourrais prendre l'anonyme et le basculer dans les réels avec les bonnes infos. Mais ce n'est pas le cas

Ou alors je me fourvoie encore quelque part (ce qui n'est pas impossible).

**frm013** · 23/01/2014, 15h40

Envoyé par kropernic

Ou alors je me fourvoie encore quelque part (ce qui n'est pas impossible).

Mouais, je ne vois pas non plus comment faire.

Vous partez dans des grosses complications.
Si j'ai bien compris, le secrétariat ne crée pas les employés avec la même application.

Franchement, je ne vois pas d'autre solution que celle de mon premier message, quitte à choisir entre la peste et le choléra, autant partir sur une solution pérenne. A vous de le "vendre" à votre chef.
Dans ce que vous dites, on voit bien que le problème c'est les postes de travail, sans savoir pour quel poste un nouvel employé à été embauché, impossible de traiter le batch correctement. Il en va de même en gérant deux planning... vous êtes coincé !

Bon courage

**Kropernic** · 23/01/2014, 16h21

Je viens de faire une mini réunion avec mon chef pour mettre en commun nos cellules grises sur le sujet.

Je pense que nous avons atteint une solution.

Alors par contre désolé, mais je vais parler en MPD car les schémas de la DB (MS SQL 2008 R2) vont intervenir (et que je n'ai aucune idée de comment faire la distinction dans un MCD

).

Actuellement
Dans le schéma S_HR qui contient tout ce qui touche aux ressources humaines, j'ai, entre autres, la table T_EMPLOYEE_EMP dont voici le DDL (ce sera plus simple que de lister les colonnes et leur type).

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
CREATE TABLE [S_HR].[T_EMPLOYEE_EMP](
    [EMP_ID] [int] IDENTITY(1,1) NOT NULL PRIMARY KEY,
    [EMP_FIRSTNAME] [varchar](45) NOT NULL,
    [EMP_LASTNAME] [varchar](45) NOT NULL,
    [EMP_NATIONAL_REGISTRY] [char](11) NOT NULL,
    [EMP_CADRE] [bit] NOT NULL,
    [STR_ID] [tinyint] NOT NULL REFERENCES dbo.T_STORE_STR(STR_ID),
    [FCT_ID] [smallint] NOT NULL REFERENCES S_HR.T_FUNCTION_FCT(FCT_ID),
    [LNG_ID] [tinyint] NOT NULL REFERENCES dbo.T_LANGUAGE_LNG(LNG_ID),
    [EMP_BIRTH_DATE] [date] NOT NULL,
    [EMP_DATE_IN] [date] NOT NULL,
    [EMP_DATE_OUT] [date] NOT NULL,
    [EMP_MATRICULE] [varchar](7) NOT NULL,
    [EMP_HOURS_PER_WEEK] [decimal](4, 2) NOT NULL)

Il y a également le schéma S_OPERATIONAL qui contient tout ce qui concerne l'opérationnel (la partie métier quoi...) dont les équipes, les chefs, les plannings, etc.

Actuellement, dans les tables du schéma S_OPERATIONAL, lorsqu'il s'agit de faire un lien vers un employé, la clef étrangère pointe vers la colonne EMP_ID de la table ci-dessus.
Je pense que le noeud du problème est là.

Notre solution
Créer une table des employés dans le schéma S_OPERATIONAL qui aurait son ID propre ainsi qu'une colonne clef étrangère pointant vers EMP_ID du schéma S_HR comme précédemment SAUF QUE, cette colonne pourrait être NULL pour le cas d'un employé fictif (il lui faut d'autre colonne comme le magasin par exemple mais ce sont des détails qui ne posent pas de problèmes).
Ainsi, il lors de l'affectation d'un employé réel à un fictif, je viens simplement mettre une valeur dans cette colonne.
Dernier détail, pour solution le sac de noeud que je soulève dans mon précédent message, je rends cette colonne unique.
Ce qui fait que lors de l'affectation, si l'employé a déjà été utilisé pour cette application, il aura déjà son "id local" et la DB gueulera. Au magasin à ce moment-là de s'organiser correctement pour éviter ce genre de problème.

Qu'en pensez-vous ? Ok, y a une colonne dans une table (ce n'est donc plus une relation) mais bon. Comme vous dites, entre la peste et le choléra....

**frm013** · 23/01/2014, 18h56

En admettant que j'ai compris, je ne vois pas ce que cela résout...

merci de me répondre, je suis un peu dans le flou :

Envoyé par frm013

Si j'ai bien compris, le secrétariat ne crée pas les employés avec la même application.

Autrement dit, il n'utilise pas la même BD ?

Comment ferez-vous pour savoir que l'employé fraichement créé par le secrétariat sera à affecter à tel ou tel employé fictif déjà utilisé dans le planning ?

Le fait est qu'un employé fictif affecté au planning y rempli une fonction, un employé fraichement embauché, l'est pour une fonction aussi, comment ferez-vous le lien ?
Comment différencierez-vous les employés fictifs les uns des autres ?
Vous aurez beau faire, un employé qui n'existe pas encore n'est autre qu'un poste à pourvoir... essayer d'y échapper ne mènera qu'a dénaturer votre base.

Dans votre table PLANNING, vous nommez bien la fonction occupé par un employé durant telle période je suppose ?
Ex : M. Dupont sera magasinier dans le magasin n° 5 de telle à telle date.
Pour moi, l'erreur de conception vient de quelque part par là. En tout cas j'en ai l'intuition...

J'ai bien du mal à m'approprier votre schéma...

**Kropernic** · 23/01/2014, 21h05

Le lien entre un fictif et un réel est fait manuel via un écran de l'application.

Les employés ne fonctionne pas vraiment par poste...

Voici à quoi ressemble un planning (voir pièce jointe) d'une semaine pour une personne.

La notion de fonction/poste n'est pas impliquée pour cette application.
Il s'agit uniquement de définir des horaires (que j'ai appelé planning car je bosse en anglais^^) pour chaque jour ouvrable pour chaque personne. L'unité de temps la plus petite est le quart d'heure.

Et donc, j'ai mon employé fictif avec la clef étrangère vers les réelles "valant" NULL. Un responsable dans le magasin, via l'application, va lier cet employé fictif à un employé réel. C'est à ce moment-là que je mets à jour la clef etrangère avec l'id de l'employé réel. Les valeurs de cette colonne étant unique, il n'y aura pas non plus de gestion de conflit (à moins d'un cas auquel je n'aurais pas pensé mais honnêtement, ça ne fait rien)

**frm013** · 24/01/2014, 12h33

Bonjour Kropernic,

Ah, je comprends mieux, content que vous ayez trouvé une solution.

A bientôt,
François

Personne réelle/Personne "anonyme" : affecter le premier au second [MCD]

Schéma

Partager

Partager