Discussion :

[badams]

Bonjour chers tous,

J'aimerai gérer la prise de service et la fin de service d'un employé, en vue de créer des tables dans ma DB pour archivage.
Cependant, comme il y a un service de jour et un service de nuit, j'hésite un peu sur la conception du modèle de données. Car, je veux savoir que pour telle date et pour tel service(jour ou nuit), je peux retrouver les employés concernés.

Voici ma solution, mais je ne sais pas si je suis dans le bonne direction ?
Il y a 4 entités : EMPLOYE, SERVICE, TYPE SERVICE(jour/nuit), DATE.

Comme EMPLOYE est liée à SERVICE avec une double relations (Prise de service et Fin de service), je ne sais pas ou placer l'entité DATE entre EMPLOYE et SERVICE ?





Merci beaucoup pour votre aide.

[JPhi33]

Bonjour Badams,

J'aimerai gérer la prise de service et la fin de service d'un employé, en vue de créer des tables dans ma DB pour archivage.
Cependant, comme il y a un service de jour et un service de nuit, j'hésite un peu sur la conception du modèle de données. Car, je veux savoir que pour telle date et pour tel service(jour ou nuit), je peux retrouver les employés concernés.

On se représente bien ce que sont un EMPLOYE, une DATE et le TYPE de SERVICE (jour ou nuit). En revanche, l'entité SERVICE reste mystérieuse. Il faudrait en dire un peu plus à son sujet.

Quelques exemples illustrant le propos seraient les bienvenus.

[badams]

Bonjour,

Merci pour votre précision.

En fait, un employé dois faire deux choses:
- lors de sa prise de service, il doit effectuer un ensemble de tâches, donc il est en service,
- ou être à son poste de contrôle, après avoir effectuer ces tâches,

Et, je ne savais pas comment exprimer ces deux états exactement que par un SERVICE, pour savoir qu'il est soit en service ou à son poste de contrôle.

Cordialement.

[JPhi33]

Sans trop rentrer dans les détails, on peut modéliser ce problème ainsi :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
[ EMPLOYE ]
     |
    0,n
     |
     |
( SERVICE )--1,1----(CIF)----0,n->[ TYPE SERVICE ]
     |
     |
    0,n
     |
 [ DATE ]

L'association SERVICE porte les propriétés "heure de début de service" et "heure de fin de service". La CIF (Contrainte d'Intégrité Fonctionnelle) entre SERVICE et TYPE SERVICE peut surprendre mais est tout à fait "légale".

Les règles qui conduisent à ce modèle sont :
- A une date donnée, plusieurs employés peuvent effectuer leur service
- Un employé peut effectuer plusieurs services, chacun à une date différente
- A une date donnée, un employé prend et quitte son service ("heure de début de service" et "heure de fin de service")
- A une date donnée, un employé effectue un service d'un seul type (jour ou nuit)

Dérivation en Modèle Relationnel (clés soulignées, clés étrangères préfixées par #) :

EMPLOYE (id_employé, ...)
TYPE SERVICE (id_type_service, ...)
SERVICE (#id_employé, date, heure_deb, heure_fin, #id_type_service)

(L'entité DATE ne se dérive pas, il ne s'agit pas d'une "véritable" entité)



Les règles plus haut amènent plusieurs questions susceptibles de modifier cette modélisation :

- Un employé peut-il effectuer plusieurs services à la même date ?
- Un employé peut-il quitter son service le lendemain de sa prise de service (notamment pour le service de nuit) ? Par exemple, prise de service le 30/07/2014 à 21h, fin de service le 31/07/2014 à 4h.
- Si oui, veut-on conserver cette particularité dans la base ? On pourrait se contenter de la même date (30/07/2014), des heures telles quelles (début 21h, fin 4h) et savoir que, puisque l'heure de fin est inférieure à l'heure de début, la fin de service se situe le lendemain.

La liste n'est pas exhaustive mais c'est déjà une base de réflexion.

[badams]

Bonjour,

Voilà, je suis de retour après une courte période de vacances.
Un grand merci à toi JPhi33 pour ta solution.

Cordialement.