Discussion :

[Kyrian]

Bonjour,

Je me présente kyrian étudiant en licence pro réseaux et telecoms.
Je vous sollicite, pour résoudre un exercice merise, MCD

Donc j'aurais besoin de vos lumières s'il vous plaît .

Je vous donne le contexte :

Individu :
- nom et prenom de l'individu
- date de naissance de l'individu
- langues pratiquées par l'individu
- niveau dans les langues pratiquées
- désignation des centres d'interets
- salaire actuel de l'individu
- salaire recherché

Diplome :
- désignation du diplome (code et libelle)
- date d'obtention

Employeurs successif :
- raison social de l'employeur
- date d'entree dans l'entreprise
- date de départ de l'entreprise
- fonction exercé chez l'employeur
- date de début de la fonction
- date de fin de la fonction

On précise également :
- un individu peut éventuellement avoir été embauché plusieurs fois chez le meme employeur
- un individu peut avoir exercé plusieurs fonctions chez le meme employeur ou la même fonction chez plusieurs employeurs

Questions:
1 - Etablir le modèle entité-association correspondant
2- preciser les clés des entités et des associations
3 - proposer un modele relationnel normalisé ainsi que le schéma relationnel associé.

J'ai pu faire mon modèle entité association mais j'ai un doute sur la conception de celui-ci. Fsmrel ma un peu mis sur le chemin mais je bloque.

imagik


Pouvez- vous m'aider ??


Merci beaucoup pour votre aide
Cordialement

[fsmrel]

Bonjour Kyrian,

Si vous faites un vrai MCD, les informations ne doivent pas être répétées. Ainsi, l’attribut id_langue# (association PARLER) redonde avec l’attribut id_langue de l’entité-type INDIVIDU et doit donc disparaître : c’est à la génération du MLD qu’il renaîtra sous forme de clé étrangère, disons que vous avez anticipé. Même principe pour tous les attributs que vous avez suffixés par « # ».


DIPLOME :

La patte d’association connectant INDIVIDU et DETENIR est porteuse d’une cardinalité 0,N, donc un individu peut être détenteur de plusieurs diplômes. Mais comme le même diplôme peut concerner plusieurs individus, la patte d’association connectant DIPLOME et DETENIR doit être porteuse d’une cardinalité 0,N. La date du diplôme fera l’objet d’un attribut porté par l’association DETENIR.

EMPLOYEUR :

Là où ils sont placés, les attributs date_entree et date_depart signifient que l'employeur untel a été en activité de telle date à telle date... S’il s’agit des périodes d’embauche des individus chez les employeurs, alors ces dates doivent figurer dans l’association EMBAUCHER.

FONCTION :

Il faut revoir la modélisation des fonctions, car selon votre MCD on n’a aucune idée de l’employeur chez lequel un individu a exercée telle ou telle fonction.

[Kyrian]

Bonjour Kyrian,

Si vous faites un vrai MCD, les informations ne doivent pas être répétées. Ainsi, l’attribut id_langue# (association PARLER) redonde avec l’attribut id_langue de l’entité-type INDIVIDU et doit donc disparaître : c’est à la génération du MLD qu’il renaîtra sous forme de clé étrangère, disons que vous avez anticipé. Même principe pour tous les attributs que vous avez suffixés par « # ».


DIPLOME :

La patte d’association connectant INDIVIDU et DETENIR est porteuse d’une cardinalité 0,N, donc un individu peut être détenteur de plusieurs diplômes. Mais comme le même diplôme peut concerner plusieurs individus, la patte d’association connectant DIPLOME et DETENIR doit être porteuse d’une cardinalité 0,N. La date du diplôme fera l’objet d’un attribut porté par l’association DETENIR.

EMPLOYEUR :

Là où ils sont placés, les attributs date_entree et date_depart signifient que l'employeur untel a été en activité de telle date à telle date... S’il s’agit des périodes d’embauche des individus chez les employeurs, alors ces dates doivent figurer dans l’association EMBAUCHER.

FONCTION :

Il faut revoir la modélisation des fonctions, car selon votre MCD on n’a aucune idée de l’employeur chez lequel un individu a exercée telle ou telle fonction.

Bonjour, Fsmrel

J'ai refait mon mcd en prenant en compte tes conseils, j'ai aussi separé le mcd du mld afin de bien voir les clés etrangères

Voici mon schéma :

imagik

Voici mon MLD :

Diplôme (id_diplome, code,libelle)

Detenir (date_obtention,id_diplome#,id_individu#)

Individu(id_individu,nom,prenom,date_naissance,salaire_actuel, salaire_rechercher)

Parler (id_individu#,id_langue#)

Langues(id_langue,langues,niveau)

Interets (id_interets, designation )

Avoir (id_interets#, id_individu#)

Embaucher (date_entree, date_depart, id_individu#,id_employeur#)

Employeur (id_employeur,raison_social,nom,fonction,date_debut_fonction,date_fin_fonction)

J'ai insérer les attributs des fonctions dans employeur ce qui me semble plus cohérent.

Parcontre je n'arrive pas à comprendre comment faire pour passer de 1FN en 2FN puis en 3FN ???
Dois je le faire sur tout mon schéma ou seulement ou c'est possible ???



Merci beaucoup Fsmrel Cordialement

[fsmrel]

Bonjour Kyrian,


Voyons voir les entités-types, associations, tables...

INDIVIDU

Votre MCD et votre MLD sont conformes concernant les individus.

DIPLOME

Dans votre MCD, l’entité-type DIPLOME comporte encore un attribut id_individu qui n’a rien à y faire. Par contre ? au niveau du MLD, votre table DIPLOME est correcte :

Diplôme (id_diplome, code,libelle)

DETENIR

Votre MCD est correct, par contre votre MLD n’est pas valide car la table DETENIR n’a pas de clé :

Detenir (date_obtention,id_diplome#,id_individu#)

La version correcte est la suivante :

Detenir (date_obtention, id_diplome#, id_individu#)

Je vous fournis la version MySQL Workbench correspondant à cette partie :




LANGUE

L’attribut Niveau n’est pas à sa place, car, il concerne aussi un individu.

PARLER

C’est au sein de la table PARLER que l’attribut Niveau prend son sens :

INTERET

Votre MCD et votre MLD sont conformes concernant les centres d’intérêt.

AVOIR

Votre MCD est correct, par contre votre MLD n’est pas valide car la table AVOIR n’a pas de clé :

Avoir (id_interets#, id_individu#)

La version correcte est la suivante :

Avoir id_interets#, id_individu#)

EMPLOYEUR

Y a du mou dans la corde à nœuds...

En effet, selon les attributs composant l’en-tête de votre table EMPLOYEUR, un employeur a une raison sociale, un nom, c’est d’accord, mais il exerce aussi une fonction depuis telle date : encore des attributs qui ne sont pas à leur place.

EMBAUCHER

[indent]Selon votre représentation pour une paire {Individu, Employeur} il n’y a qu’en seule date d’embauche : l’association EMBAUCHER ne respecte donc pas la règle :

Un individu peut éventuellement avoir été embauché plusieurs fois chez le même employeur.

Pour que cette règle soit respectée, dans le contexte de Merise, il faut définir une association ternaire :




Mais comme les employeurs sont successifs, on peut énoncer la règle suivante :

A une date donnée, un individu n'est employé que par un seul employeur.

Ce qui en Merise conduit à définir une CIF (contrainte d’intégrité fonctionnelle), c'est-à-dire une contrainte d’unicité à cet effet :

{INDIVIDU, DATE} -> {EMPLOYEUR}

Symbolisée ci-dessous par la pointe de flèche rouge :




Les choses sont plus simples à représenter au niveau du MLD. Version MySQL Workbench :




Selon votre notation :

Embaucher (id_individu# , date_embauche, id_employeur#, date_depart)

FONCTION_EXERCEE

Il reste donc à définir les fonctions exercées par un individu chez les employeurs. Là encore, on peut faire l’hypothèse qu’un individu n’exerce qu’une fonction à la fois (il ne serait pas difficile de modifier le modèle si cette règle ne valait pas).





Selon votre notation :

Fonction_exercee (id_individu#, date_debut_fonction, id_fonction#, date_embauche#, date_fin_fonction)

La table FONCTION_EXERCEE est en relation avec la table EMBAUCHE, car un individu ne peut exercer de fonction chez un employeur que si celui-ci l’a embauché.

Par ailleurs, on peut considérer qu’un individu a pu exercer une certaine fonction chez un certain employeur, le quitter, puis revenir pour exercer à nouveau cette même fonction chez cet employeur.


Exemples :

L’individu Bastien, embauché [chez l’employeur Volfoni] le 01/01/1954, a exercé la fonction de conseiller technique du 01/01/1954 au 31/12/1955 ;

L’individu Bastien, embauché [chez l’employeur Volfoni] le 01/01/1954, a exercé la fonction de bras droit du 03/01/1954 au 31/12/1956 ;

L’individu Bastien, embauché [chez l’employeur Naudin] le 11/01/1957, a exercé la fonction de consultant du 11/01/1957 au 14/07/1957 ;

L’individu Bastien, embauché [chez l’employeur Naudin] le 11/01/1957, a exercé la fonction de conseiller commercial du 15/07/1957 au 23/09/1957 ;

L’individu Bastien, embauché [chez l’employeur Volfoni] le 01/10/1957, a exercé la fonction de chef d’équipe du 07/10/1957 au 25/09/1958 ;

L’individu Bastien, embauché [chez l’employeur Volfoni] le 01/01/1957, a exercé la fonction de conseiller technique du 26/09/1958 au 30/03/1959 ;

Etc.

L’expression entre crochets : [chez l’employeur Volfoni] est simplement là pour rappeler que par jointure des tables FONCTION_EXERCEE et EMBAUCHE, on sait qui est l’employeur de Bastien.

Par contre je n'arrive pas à comprendre comment faire pour passer de 1FN en 2FN puis en 3FN ?
Dois-je le faire sur tout mon schéma ou seulement où c'est possible ?

Il ne s’agit pas de passer en 1FN, 2FN, 3FN, en FNBC, etc., mais de vérifier que ces formes normales ne sont pas violées. La vérification doit être effectuée pour chaque table.


Bon courage, et n'hésitez pas à voter pour les réponses qui ont pu vous aider...