Discussion :

[FadeToBlack]

Bonjour à tous,

Je suis en train de mettre en place une base de données de gestion du personnel pour ma boite.
Pour faire simple, j'ai :
-Une table Salarié (avec le nom et le prénom)
- Une table motif de rupture de contrat
- Une table modalité liée à la rupture.

Comme motif de rupture, il y a en données : Le licenciement, la démission, la retraite, la mutation et la fin de contrat (pour les CDD).
La table Modalités liées à la rupture conserve les renseignements spécifiques à certaines mesures de rupture (Nb et date d'entretiens, indemnités etc....).
J'ai donc créé un lien d'héritage entre la table rupture et les tables Licenciement, rupture conventionnelle.

Mais est-ce que je dois créer des tables pour démission et retraite qui ne possèdent pas de renseignements spécifique ?

Merci d'avance pour vos conseils

[FadeToBlack]

Re-bonjour,

Au-delà de ma question précédente, j'aimerais savoir s'il existait un genre de 'best practice' du développement de base de données.

J'ai parcouru des dizaines de fois les cours de F BROUARD, de C GRUAU et de C SOUTOU. J'y comprends une façon de développer une base de données, mais je n'arrive pas à y capter ce qui est préférable de faire et ce qui ne doit pas être fait.

Auriez vous des tuyaux pour moi

Merci

[FadeToBlack]

Salut,

Puisque personne ne semble pouvoir me répondre, je vous joins un png de mon problème. J'aimerais savoir si vous pouviez me le valider ou me dire ce qui ne fonctionne pas.

Par ailleurs dans la branche avec l'héritage, je me dis que je ne dois pas générer la table père mais uniquement les fils. Ai-je raison ?

Merci de vos avis

[CinePhil]

Mais est-ce que je dois créer des tables pour démission et retraite qui ne possèdent pas de renseignements spécifique ?

Vu ta question, je suppose que la propriété "Motif" de l'entité type "Ruptures" (que tu devrais nommer au singulier, ainsi que toutes les entités types que tu as nommées au pluriel) contiendra en quelque sorte le nom de l'entité type fille ?
C'est une redondance qui n'est pas souhaitable et il vaut donc mieux, comme tu l'as fait, mettre la date dans l'entité type fille. Ces dates ont d'ailleurs des significations différentes selon le motif de rupture. La date de la retraite est la date à laquelle le salarié devient retraité mais la date de démission est peut-être la date à laquelle le salarié à posé sa démission, pas la date à laquelle il part effectivement. À toi de le préciser dans ton dossier d'analyse.

De plus, tu pourrais vouloir ajouter des propriétés spécifiques aux retraites et aux démissions, telles que le motif de la démission (débauché par un concurrent, se met à son compte, déménage à l'étranger...) ou bien le nombre de trimestres que le salarié a cumulé.

Au-delà de ma question précédente, j'aimerais savoir s'il existait un genre de 'best practice' du développement de base de données.

Tu peux aussi regarder dans les livres de Michel Diviné qui sont disponibles en téléchargement gratuit sur DVP.

Tu peux aussi parcourir le présent forum dans lequel tu trouveras moult conseils avisés d'experts tels que fsmrel.

Passons au MCD...

J'aimerais savoir si vous pouviez me le valider ou me dire ce qui ne fonctionne pas.

1) Externalise au maximum
Marque et modèle de téléphone devraient être externalisés :
Perso -0,1----posséder----1,1- TelPro -1,1----typer----0,n- ModeleTel -1,1----fabriquer----0,n- MarqueTel

Idem pour Statut, Service, Ville

2) Cardinalités
2a) À mon avis, une rupture se rapporte à un et un seul emploi (cardinalités 1,1).

2b)Les cardinalités (1,1 - 1,1) de l'association Occuper impliquent que tu devras créer les deux lignes Perso et Emploi en même temps et jouer du trigger. Si possible, passe l'une des deux cardinalités mini à 0.
De plus, l'emploi disparaît-il lorsque le perso quitte l'emploi ? Ne sera t-il pas occupé par un autre perso ?
Ne faudrait-il pas alors considérer le contrat du perso plutôt que l'emploi ?
Je t'invite à réfléchir de nouveau à cet aspect des choses...

2c) Adresse devrait être identifiée relativement à Perso.
Si tu supprimes le perso, les adresses qui lui appartenaient n'ont plus lieu de rester en BDD.
Perso -1,n----Habiter----(1,1)- Adresse
Du coup, il n'y a plus d'identifiant de type Séquentiel dans Adresse mais seulement une propriété "Numero" qui permet de distinguer les différentes adresses d'un perso.

3) Commentaire pour chaque perso ?
Si tous les perso n'auront pas forcément un commentaire, externalise le commentaire :
Perso -0,1----avoir----(1,1)- Commentaire

4) Une "boîte" mais plusieurs sociétés ?

Je suis en train de mettre en place une base de données de gestion du personnel pour ma boite.

Tu parles de ta "boîte" mais tu as une entité type "Sociétés". Il s'agit d'un groupe avec ses filiales ?

5) Ancienneté
N'est-ce pas une propriété calculable à partir de la date d'entrée du Perso ?
Si c'est le cas, il ne faut pas la mémoriser en BDD.

6) Noms de tes propriétés
Pourquoi y a t-il des disparités dans ta manière de nommer les propriétés ?
Pourqoi par exemple avoir nommé "Pnom" au lieu de "Prenom" alors que juste en dessous tu as le nom long "DateNaissance" ?
Pourquoi avoir utilisé dans certains cas l'underscore (_) pour séparer les mots (Nom_Soc) et dans d'autres accolé les mots en mettant la majuscule à chaque mots.
Puisque tu cherches des bonnes pratiques, je t'invite à consulter la norme de développement de SQLPro et de réfléchir à sa pertinence. Je l'ai personnellement adaptée pour mes besoins.

Bon courage !

[FadeToBlack]

Salut Cinephil,
et merci de ta réponse.

Je suis bien d'accord avec toi sur la distinction entre les dates, qui effectivement ne veulent pas dire la même choses suivant le cas de rupture.

Concernant la propriété 'Motif', je comprends moins. Il faut bien à un moment où à un autre mentionné 'en dur', je veux dire par écrits, quel est le type de rupture non? Sur l'interface graphique, il faudra à ce moment là un script précisant que si Date_dem est différent de null alors motif = Démission.

Ou est-ce que je dois mettre dans chaque sous table leur nom donc avoir une propritée type genre type = démission?


Enfin, la relation entre Emploi et Rupture me gene. Ne faudrait-il pas qu'elle soit entre Rupture, emploi et Perso ? Parce que c'est une personne qui rompt (de son fait ou pas) un emploi ?

Merci d'avance

[CinePhil]

J'ai édité mon message ; j'avais appuyé ar erreur sur la touche entrée et il était incomplet.

Concernant la propriété 'Motif', je comprends moins. Il faut bien à un moment où à un autre mentionné 'en dur', je veux dire par écrits, quel est le type de rupture non? Sur l'interface graphique, il faudra à ce moment là un script précisant que si Date_dem est différent de null alors motif = Démission.

Ou est-ce que je dois mettre dans chaque sous table leur nom donc avoir une propritée type genre type = démission?

Il te faut construire uin modèle organisationnel de données qui va se matérialiser dans le SGBD par des vues.

Enfin, la relation entre Emploi et Rupture me gene. Ne faudrait-il pas qu'elle soit entre Rupture, emploi et Perso ? Parce que c'est une personne qui rompt (de son fait ou pas) un emploi ?

C'est effectivement le problème que j'évoque dans la suite de mon message que tu n'as pas encore vue. Il te faut, à mon avis, distinguer l'emploi (ingénieur, comptable, chef du service X) du contrat (n° 12345 du salarié Jean Dupont).

[FadeToBlack]

Ouh là là....

Ta réponse me renvoie l'énormité de mes erreurs et la somme des choses que j'ai encore à apprendre. Bon mais je n'ai eu que ce que je méritais et puis d'ailleurs j'ai posé la question pour cela

Je lis l'article de Brouard que tu m'as donné et je refais mon MCD. Si tu es d'accord je le repost après.

Merci

[FadeToBlack]

Salut CinePhil et tous les autres,

Je mets en Pj le MCD actualisé. Certaines modifs n'apparaissent pas (comme l'externalisation de certaines tables...) Mais j'ai revu une partie du nommage des attributs.

5) Ancienneté
N'est-ce pas une propriété calculable à partir de la date d'entrée du Perso ?

J'ai viré cet attribut qui effectivement sera calculé automatiquement et non stocké

4) Une "boîte" mais plusieurs sociétés ?

Effectivement ma boite est un groupe qui dispose de plusieurs sociétés. On aurait, logiquement, fait une appli par société, mais le service RH voulait quelque chose englobant le tout.

Ne faudrait-il pas alors considérer le contrat du perso plutôt que l'emploi ?
Je t'invite à réfléchir de nouveau à cet aspect des choses...

J'ai revu aussi la partie 'emploi'. Effectivement, une personne signe un contrat pour un poste. Et ce contrat peut être rompu.

Maintenant, je me dis un truc. Si je pars de ce principe, cela veut dire que le salarié ou une des société peut rompre le contrat. Cela donnerait
perso 1,1 ----rompre --- 0,1 contrat
societé 0,n ---rompre --- 0,1 contrat

Mais du coup, si je mets des attributs à la relation 'Rompre', comme je crée des liens d'héritage suivant le type de rupture?

Merci de tes conseils avisés et surtout bon Dimanche à tous

[CinePhil]

1) Je continue de penser qu'une rupture ne concerne qu'un et un seul contrat :
Contrat -0,1----Rompre----1,1- Rupture

On pourrait même faire une identification relative :
Contrat -0,1----Rompre----(1,1)- Rupture

L'entité type Rupture perd ainsi son identifiant propre.

2) Un contrat n'est-il pas forcément signé parcommerciaux une personne ?
Contrat -1,1----Signer----1,n- Personne

3) Tu n'as pas externalisé la ville.
Tu risques ainsi de te retrouver avec la même ville orthographiée différemment (Saint-Étienne, St. Etienne, Saint-Etienne Saint Etienne...)

4) N'y a t-il pas plusieurs emplois identiques dans le groupe ?
Par exemple, j'imagine qu'il doit y avoir plusieurs comptables, plusieurs commerciaux, plusieurs ingénieurs...
Tu devrais externaliser l'emploi, quitte à laisser quand même une propriété pour l'intitulé exact du poste (chef du service Contrôle qualité, responsable du bureau d'études...).
Ça m'étonnerait que la RH ne souhaite pas caler les informations de la BDD avec les postes définis dans la convention collective ou les emplois-types du groupe. Renseigne-toi bien sur tout ce qui concerne la classification des contrats (indice, emploi-type, fonction...).

5) Tu n'as pas externalisé les marques et types de téléphones.

6) Dates
6a) Je mettrais les dates de début et de fin de contrat dans l'entité type Contrat et je supprimerais Date_Entree et Date_Sortie de l'entité-type Personne.

6b) Pourquoi y a t-il une date d'entrée dans le Licenciement ?

7) Salaire
Il devrait, à mon avis figurer plutôt dans le contrat que dans la rupture.

[FadeToBlack]

Salut Cinéphil

Pour ce qui est de l'externalisation de Ville et Téléphone, je pensais le faire après quand j'aurais réglé ce problème de rupture de contrat.

Sinon, je viens de me rendre compte que j'avais fais les modifications de cardinalité après avoir fait la capture d'écran. JE suis un peu c.. quand même de n'avoir pas rafraichi cela.

6) Dates
6b) Pourquoi y a t-il une date d'entrée dans le Licenciement ?

C'est une faute de frappe. En fait cela devrait être Date_Entretien. C'est la date de l'entretien de licenciement. Je corrige.

7) le salaire

Effectivement c'est peut être plus clair comme cela... Mais à ce moment là que le salaire brut pas les autres, puisqu'ils n'ont d'intérêts que dans la rupture non?

Sinon au sujet de l'association 'rompre', est-ce complètement idiot de la faire entre les entités Contrat, Société, Personne, Rupture ? Je sais cela fait gros mais..... Ou alors je le laisse comme cela?

[CinePhil]

Pour ce qui est de l'externalisation de Ville et Téléphone, je pensais le faire après quand j'aurais réglé ce problème de rupture de contrat.

Soit ; ne l'oublie pas quand même !

Sinon, je viens de me rendre compte que j'avais fais les modifications de cardinalité après avoir fait la capture d'écran. JE suis un peu c.. quand même de n'avoir pas rafraichi cela.

OK, ça arrive.

C'est une faute de frappe. En fait cela devrait être Date_Entretien. C'est la date de l'entretien de licenciement. Je corrige.

OK.

Effectivement c'est peut être plus clair comme cela... Mais à ce moment là que le salaire brut pas les autres, puisqu'ils n'ont d'intérêts que dans la rupture non?

C'est surtout que les autres sont des données calculables non ?

Sinon au sujet de l'association 'rompre', est-ce complètement idiot de la faire entre les entités Contrat, Société, Personne, Rupture ? Je sais cela fait gros mais..... Ou alors je le laisse comme cela?

Laisse comme ça. Le contrat ne concerne qu'une personne et qu'une société. Il suffit de rompre le contrat ; le lien vers la société et la personne sont implicites et facilement trouvables par jointures.

[FadeToBlack]

C'est surtout que les autres sont des données calculables non ?

Oui je sais les données seraient calculables, mais en fait la RH ne veut pas enregistrer les salaires perçus par une personne pendant toute sa carrière, ce qui permettrait le calcul. Ces chiffres sont donnés par le service comptable au moment où la personne quitte l'entreprise. Cela sert dans négociation entre eux et le salarié pour déterminer les différentes indemnités.

Mais quoiqu'il en soit, ils peuvent se mettre dans contrat.....

Laisse comme ça....

Merci, j'avais essayé de faire une relation quaternaire et le résultat me paraissait plus que bancal. En fait, j'ai du mal dès que les relations sont supérieures à trois. D'ailleurs, mon prof nous disait tout le temps qu'il fallait privilégier une relation binaire aux autres. Du coup.......

Pour les téléphones, j'ai externalisé la marque et pas le modèle que j'ai purement et simplement supprimé parce qu'en fait c'est un ajout perso et je ne pense pas que cela les intéresse.

In fine les choses devraient être comme cela

[FadeToBlack]

quel truffe, j'ai oublié d'enlever l'attribut ville de l'entité adresse... Fais comme il n'était pas là..

Je commence à fatiguer

[CinePhil]

Du fait de l'identification relative dans l'association Rompre, tu n'as plus besoin de Id_Rupt dans Rupture.
Idem pour Id_Comm d'ailleurs qui est devenu inutile.
Idem pour Id_Adrs.

Le reste semble bon.

[FadeToBlack]

Je ne sais pas ce que j'aurais fais sans toi, Merci.

Surtout je ne sais pas ce qui aurait été fait sans toi............

Bon fin de Week End

JE mets le RESOLU