Discussion :

[Eric26]

Bonjour,

Je suis en train d'élaborer une BD qui va servir à gérer des employés d'une société.

J'ai commencé par lister tous les termes (attributs) que j'utiliserai.
J'ai réussi à identifier 2 tables : IDSALARIE (identité des salariés) ET CONTRATS (contrats des salariés)
Question ? : comment je fais pour identifier d'autres entités à partir de ces attributs.

Merci

[Invité]

de la même façon que tu as trouvé les 2 autres....

Ce n'est pas en nous disant si peu de choses que nous pourrons t'aider

Qu'est-ce que cela veut dire pour toi "gérer des employés" :
gérer les payes, les horaires, les missions, les services, les responsabilités, les vacances, etc.... ?

[TheLeadingEdge]

Bonjour,

Si vraiment tu ne décrouvre pas tes entites de façon intuitive,
essaie d'utiliser ''une matrice des dépendances fonctionnelles''.
En gros tu fait 1 tableau avec tes attributs en x et en y,
puis tu met des croix à l'intersection des 2 lorsque tu estime qu'une propriété dépend d'une autre. Le regroupement des dépendances de certains attributs par rapport à un autre devrait te permettre d'identifier assez facilement tes entités.

bon courage

[Eric26]

OK, j'explique mieux.

Il s'agit d'élaborer une BD qui gérera les contrats de travail des employés d'une société de gardiennage-sécurité.
Particularité : Dans ce genre de société, il n'est pas rare de voir des employés (= Agents De Sécurité) ayant plusieurs contrats de travail la même année (= le taux de TURN OVER est élévé). De plus, chaque employé fait l'objet d'une demande d'agrément préfectorale préalable à son embauche (et cette demande doit être renouvelée 1 X par an en moyenne pour les employés en poste).
J'ai déjà réussi à identifier les tables suivantes :
ID_EMPLOYES (N°_EMPL ; NOM_EMPL ; Pr_EMPL ; ADR_EMPL ; CP_EMPL ; VI_EMPL ; DNAIS_EMPL ; LIEUNAIS_EMPL ; NATIO_EMPL ; N°SS_EMPL ; SITFAM_EMPL ; N°TEL_EMPL)
CONTRATS (N°_CONTRATS ; NumEmpl_CONTRATS ; POSTE_CONTRATS ; TYPE_CONTRATS ; DEBUT_CONTRATS ; FIN_CONTRATS ; NBHEURES_CONTRATS ; PERIODESSAI_CONTRATS ; AVENANT_CONTRATS)
Là ou je flanche, c'est pour la visite médicale et l'agrément préfectoral : je sais pas s'il faut en faire des tables séparées ou bien les intégrer dans une des tables ci-dessus, puisque les 2 s'appliquent aussi bien à l'agent qu'au contrat.

Merci

[TheLeadingEdge]

Pour qu'elles dépendent de contrat il faudrait que chaque contrat implique 1 nouvelle visite et 1 nouvel agrément. La il semble qu'il faut simplement qu'il y ait 1 aggrément et 1 visiste médicale ''valides''. Il semble possible en plus qu'il y ait plusieurs agrements et visistes médicales durant la période d'un contrat, ca exclu donc définiivement le contrat. Si tu n'historises pas les dates de visites médicales et de périodes de validité d'agrement, ce sont des propriétés qui sont propres à l'employé.
Sinon il faut en faire des entités séparées. (c'est ce que je te conseille)

[Eric26]

Si tu n'historises pas les dates de visites médicales et de périodes de validité d'agrement, ce sont des propriétés qui sont propres à l'employé.
Sinon il faut en faire des entités séparées. (c'est ce que je te conseille)

Très bonne explication; je vais y réfléchir.

Que dois-faire maintenant, mettre le sujet "RESOLU" sachant que j'aurais sûrement d'autres question + tard concernant la modélisation de cette BD ou bien laisser comme ça ?

merci

[Eric26]

Re bonjour,

En fait, là, je bloque sur autre chose : LES AVENANTS au contrat (c'est à dire les modifications de contrat).
exemple : un employé en CDD ; on lui fait un AVENANT de prolongation de CDD ou bien un AVENANT qui transforme son CDD en CDI (et il y a toutes sortes d'avenant tels que les augmentation d'heures, les diminutions d'heures etc ...).
Mon problème est le même que pour les agréments et visite médicale. Caractéristiques de l'avenant :
- La date de l'avenant.
- Le type d'avenant (quelle est la modification apportée au contrat=quel est le nouveau contrat).
- si c'est une prolongation de CDD : quelle est la nouvelle date de fin de CDD.
- Si c'est une augmentation ou une diminution d'heures mensuelle : quelles sont les nouvelles heures.
- Etc ...
Sachant que l'avenant est propre à chaque contrat, je pense que ça doit rentrer avec l'entité CONTRATS.
Mais ce que j'aimerais faire, c'est qu'à chaque fois que l'on fait un AVENANT (= on modifie un contrat), alors le ou les anciens contrats se retrouvent dans une tables spéciale, et cela, afin de suivre l'évolution des contrats d'un même employé.
Du coup, je ne sais plus bien si il ne faut pas en faire une entité à part, et si oui, comment lier cette entité.

Merci d'avance

[TheLeadingEdge]

re,

Plusieurs avenants pour 1 contrat (0,n).
Tu as trouvé tt seul la réponse.
1 table ''avenant'' avec 1 clef étrangère qui référence la PK de ''contrat''.

[Eric26]

3 choses si vous permettez :

- pourquoi pas (1,n) au lieu de (0,n) puisqu'il y a +sieurs avenants pour 1 contrat (je ne suis pas encore bien à l'aise avec les relations)

- Pour la clef étrangére, je peux pas prendre le numéro de contrat par exemple ?

- Qu'est ce que la PK ?

Merci

[TheLeadingEdge]

bonjour,

Désolé pour les abbréviations

- pourquoi pas (1,n) au lieu de (0,n) puisqu'il y a +sieurs avenants pour 1 contrat (je ne suis pas encore bien à l'aise avec les relations)

1 avenant est 1 modification d'1 contrat. Initialement 1 contrat n'a pas d'avenant, et peut tres bien ne pas en avoir. Si tu mets 1,n tu va rendre obligatoire avenant (not null) il y aura (normalement ...) 1 contrainte d'intégrité qui vérifiera l'existence d'un avenant à la création d'un contrat (bnjour les soucis ;-) )
Ca ne représente pas du tout la réalité.

- Pour la clef étrangére, je peux pas prendre le numéro de contrat par exemple ?

Bien sur ...
La cle primaire (PK) de ''contrat'' sera plus que probablement son n° ... et elle sera référencée par une clef étangère (FK) depuis ''avenants''

- Qu'est ce que la PK ?

PK -> primary key -> clef primaire d'une table
FK -> foreign key -> clef etrangère d'une table

[edit] Je viens de relire, et j'ai compris pourquoi tu posais ta 1ere question.
0,n est la cardinalité de ''avenant'' ds la relation avec ''contrat'', (1 contrat peut ne pas avoir d'avenant et peut en avoir plusieurs). Il est bien évident que pour ''contrat'' la cardinalité est 1,1 (s'il existe, 1 avenant est lié à 1 contrat et 1 seul) [/edit]

[Eric26]

bonjour,

Désolé pour les abbréviations


1 avenant est 1 modification d'1 contrat. Initialement 1 contrat n'a pas d'avenant, et peut tres bien ne pas en avoir. Si tu mets 1,n tu va rendre obligatoire avenant (not null) il y aura (normalement ...) 1 contrainte d'intégrité qui vérifiera l'existence d'un avenant à la création d'un contrat (bnjour les soucis ;-) )
Ca ne représente pas du tout la réalité.

Trés bonne explication

Merci, j'ai compris maintenant.