Discussion :

[lll-K]

sous ce titre intentionnellement tourné à la dérision, se cache une question que je me pose, moi petit développeur web qui préfère en général passer directement a mysql workbench... mais qui se demande de plus en plus si une bonne maitrise du MCD l'aiderait pas a gagner en qualité sur ses cahiers des charges...

Voilà : j'ai une entité "manutentionnaire" [MAN] qui hérite de l'entité "employé" [EMP], une entité "type de machine" [TYP], chaque MAN peut bien sûr avoir une ou plusieurs compétences, il sera donc relié a plusieurs TYP par l'association (CONNAITRE)

couche bdd, j'aurai tendance a créer une table "employés" (#id_employe#, id_type_employe), une table "types d'employés" (#id_type_employe#,...), une table "types de compétences" (#id_competence#), et une table "compétences" comportant :
#id_liste#, id_competence, id_employe;
pour relier les tables "employés" et "types de compétences".

MAIS, dans le cas d'un mcd, on modélise ça avec des cardinalités,
j'ai donc [MAN] -1,n- (CONNAITRE) -0,n- [TYP]

mais aussi (dans le cadre de l'exercice), chaque type de manutention [TYP] est relié a une ou plusieurs machines [MAC] donc,

[TYP] -0,n- (FAIRE) -1,1- [MAC]

on a donc les propriétés suivantes :

[MAN]
numTYP
herité : #numEMP#, nom, prenom...

[TYP]
#numTYP#
nomTYP

[MAC]
numTYP
#refMAC#

Q1 : premièrement, la propriété numTYP de [MAN], ne devrait elle pas apparaître dans l'assignation (CONNAITRE) ou doit signaler la "lisaisons" dans l'entité en plaçant de même la "clé étrangère" (en termes bd) ? celà dépend il de la cardinalité ? si par ex un [MAN] peut ne pas avoir de numTYP alors on place la propriété dans l'assignation, si il est obligé -ce qui me parait normal pour etre embauché!- on la place dans l'entité ?

Q2 : ensuite, venant d'une conception plus db de la modélisation, j'aurai tendance a n'utiliser que des champs d'entiers pour l'index et donc mettre des "#id_entité_entier#" partout plutot que des #reference_surement_alphanum#, est ce "une bonne pratique d'optimisation" à ce stade ou considéré comme moins "sémantiquement MCD", et donc quel pratique considérer comme meilleure MCDément parlant ?

Q3 : puis, vu l'ampleur du schéma (je n'aborde ici juste une zone systémique réduite du mcd global dont le reste me semble au point), je me retrouve avec des associations qui se coupent sans pouvoir faire autrement ! est ce grave docteur ? (il paraitrait que c'est signe d'une mauvaise modélisation et donc pénalisant!!!). Dois je ne pas les faire et les signaler en note ?

si quelqu'un me permet de le contacter, je serai trés heureux d'avoir de plus ses commentaires sur le mcd global (sans me donner les réponses !)

merci d'avance !

[fsmrel]

Bonsoir lll-K,


Votre nom de plume donne à penser que vous venez d’une lointaine galaxie...

couche bdd, j'aurai tendance a créer une table "employés" (#id_employe#, id_type_employe), une table "types d'employés" (#id_type_employe#,...), une table "types de compétences" (#id_competence#), et une table "compétences" comportant :
#id_liste#, id_competence, id_employe;
pour relier les tables "employés" et "types de compétences".

La structure de la table des compétences mettant en relation les employés et les types de compétences comporte un attribut superflu id_liste. En effet, la paire {id_employe, id_competence} suffit pour cette mise en relation et conceptuellement les choses sont ainsi représentées :


La dérivation du MCD en MLD donnant lieu automatiquement à ceci :



Si l’entité-type Manutentionnaire représente un sous-type de l’entité-type Employe, inutile de répéter les atributs tels que Nom, Prenom. La représentation (outil Power AMC) du MCD et du MLD correspondant est la suivante :



Que vient faire l’attribut numTYP (table Manutentionnaire) ? S’il représente un type de compétence, on dispose de la table Competence pour connaître l’ensemble des compétences d’un manutentionnaire (via la table Employe).

Concernant la question Q1.

Je pense que les éléments ci-dessus devraient permettre de vous éclairer.

Concernant la question Q2.

Le choix du type ENTIER est le plus souvent préférable au type Alphanumérique. A user sans modération.

Concernant la question Q3.

Que les traits se recoupent n’est en rien le signe d’une mauvaise modélisation, mais celui d’une certaine richesse fonctionnelle. Ce n’est qu’en expertisant un tel MCD que l’on peut juger de sa qualité.

Conseil de lecture :

http://michel-divine.developpez.com/...rlezVousMerise

[lll-K]

bonjour, je vous remercie de votre réponse, en effet, vu sous cet angle aucun intérêt de citer les fk dans le mcd si le passage au mld se charge de générer ces "tables" de gestion avec ces dernières clés des tables associées.

ça devrait trés largement délester mon mcd galactique d'entités inutiles !
(et c'est pas de refus quand on sait a quel point l'univers est grand ;-) )

bien cordialement,