Discussion :

[touronster]

Bonjour, je suis débutant et j'ai un problème pour faire un MCD, notamment à un certain niveau :

Dans le cadre d'un championnat de football, on dit que un joueur appartient à un club (jusque là ça peut aller), mais ce joueur contient des caractéristiques concernant le contrat qu'il a avec son club (date d'entrée dans le club, durée du contrat, salaire brut mensuel etc..), j'avais donc pensé à les placer dans l'association "Posséder" entre CLUB et JOUEUR, puisque ces caractéristiques d'un contrat dépendent à la fois de ces deux entités. Mais là où se trouve le problème ; c'est au niveau des cardinalités, en effet, un club possède 1,N JOUEUR, et un joueur appartient à 1,1 CLUB. La cardinalité 1,1 est donc fausse (puisque l'association contient des caractéristiques)..

D'où ma question, comment puis-je m'y prendre ?

Merci beaucoup.

[CinePhil]

Dans sa carrière, un joueur passera probablement plusieurs contrats avec plusieurs clubs. Tu as donc en fait une relation 0,n - 0,n entre Clubs et Joueurs.

Voici un schéma vite fait avec DBDesigner :

[touronster]

Merci, mais comme on me demande de faire un MCD (et non pas un MCDi), je ne peux utiliser d'identifiants relatifs, donc je suppose que je dois faire une association "contracter" (ça se dit comme ça ?) entre le club et le joueur, possédant les caractéristiques date_entrée, duree_contrat, salaire_brut, etc.


Nan ?

P.S : derniere question, dans un MCD, peut-on créer des entités "vides", sans caractéristiques ?

Merci.

[fsmrel]

La cardinalité 1,1 est donc fausse (puisque l'association contient des caractéristiques)

Il est bon de séparer le passé du présent. Si un joueur a déjà fait partie d’au moins un autre club que son club actuel, vous devrez définir une association-type, appelons-la JoueurHistorique, porteuse des propriétés que vous mentionnez : date d’entrée dans le club, date de fin, salaire, etc.
Concernant le présent : soit vous procédez de la même façon et l’association-type Posséder (merci de trouver un autre nom...) est porteuse des propriétés qui viennent d’être mentionnées (quel théorème prouve que ça n’est pas possible ?), soit vous faites figurer ces propriétés dans l’entité-type Joueur, parce que le chef ou l’habitude en ont décidé ainsi (en vertu de quel théorème ?) Quoi qu’il en soit, ce débat vieux comme Merise relève de la détermination du sexe des anges : quand vous dériverez votre MCD en MLD, il n’y aura plus que des tables et les propriétés en question seront absorbées par la table Joueur. Choisissez ce qui vous convient.

[fsmrel]

je suppose que je dois faire une association "contracter" (ça se dit comme ça ?) entre le club et le joueur, possédant les caractéristiques date_entrée, duree_contrat, salaire_brut, etc.

Cinephil vous a proposé un MLD (voire un MPD) qui par rétroconception donne lieur à un MCD tout à fait valable, dans la mesure où aucune propriété n’est facultative. L’association-type Contracter sera porteuse des données concernant simultanément joueurs et clubs.

derniere question, dans un MCD, peut-on créer des entités "vides", sans caractéristiques ?

Pourquoi cette question ? Qu'est-ce qui vous tracasse ?

[touronster]

Avec mes cours, j'avais appris que si une des pattes etait simple, alors l'association ne pouvait être porteuse...

[fsmrel]

Avec mes cours, j'avais appris que si une des pattes etait simple, alors l'association ne pouvait être porteuse...

C’est l’usage : de fait, si on réfléchit à sa signification profonde, pourquoi un lien serait-il porteur d’information ? Mais alors un lien de type plusieurs à plusieurs n'a pas à faire exception. Personnellement (et je n’engage que moi et Ted Codd), une association-type peut être en fait associative et donc porteuse de propriétés, comme toute entité-type. Un peu de poudre de perlimpinpin et l'association-type Contracter devient entité-type associative tout à fait respectable, que par convenance on rebaptise en Contrat...
Mais on est sorti de Merise, pour entrer dans RM/T et ceci est une autre histoire.
Bref, pour ne pas vous faire taper sur les doigts, faites ce que dit le chef, le prof, soyez conceptuellement correct, mais si vous êtes libre, suivez votre inclination.

[touronster]

Merci.

[touronster]

En réalité, j'ai un auter problème dans mon MCD. On me dit dans l'énoncé :

Les clubs établissent une liste de 15 à 18 joueurs (numéro maillot, nom, numéro licence) constituant le groupe pour la rencontre ; le nom de l'entraineur est également précisé.

J'ai un doute sur la façon dont j'ai géré cela.

En effet, les caractéristiques numéro maillot, nom et numéro licence font déjà partie des caractéristiques de l'entité JOUEUR, donc je me suis dit que je ne dois pas les rajouter en plus dans l'entité GROUPE JOUEURS (pour éviter la redondance). Ce que j'ai fait, c'est mettre une association "Faire partie de" entre JOUEUR et GROUPE JOUEURS, GROUPE JOUEUR contient alors une seule caractéristique appelée "nom_entraineur", je me demandais si mon cela était juste.

Pour être plus clair, voici mon MCD provisoire :


Meci beaucoup, ça m'aiderait vraiment.

[fsmrel]

Ce que j'ai fait, c'est mettre une association "Faire partie de" entre JOUEUR et GROUPE JOUEURS, GROUPE JOUEUR contient alors une seule caractéristique appelée "nom_entraineur", je me demandais si mon cela était juste.

Tout d'abord, merci d’avoir fourni un MCD provisoire.

Maintenant, le fait d’avoir établi le nom de l’entraîneur comme propriété de GROUPE_JOUEURS fait que, lorsque l’on devra faire référence à ce nom, il faudra systématiquement en passer par GROUPE_JOUEURS (et pas par une autre entité-type, en vertu du sacro-saint principe "one fact, one place"). Ainsi, ou bien le prénom de l’entraîneur, sa date de naissance, etc., toutes ces propriétés qu’il a en propre figureront elles aussi dans GROUPE_JOUEURS ou bien elles figureront à part, dans une entité-type PERSONNE (ou ENTRAINEUR, ou ce que vous voulez) sémantiquement plus juste, mais alors on dispersera les propriétés de l’entraîneur : manifestement, ce rapprochement ad-hoc et douteux du groupe de joueurs et du nom de l’entraîneur est aussi fondé que le mariage de la carpe et du lapin.

A mon sens, donc, exit le nom de l’entraîneur de l’entité-type GROUPE_JOUEURS. Il doit retrouver dans l’entité-type adéquate, le prénom de l’entraîneur, sa date naissance, etc. Par ailleurs, j’ai du mal à imaginer le rôle particulier que peut jouer GROUPE_JOUEURS : l’association-type PARTICIPER suffit pour répondre à des questions du genre "Quelle est la liste des joueurs ayant participé à la rencontre du 9 février 2008, à 21h, au Stade de France ?". Pour répondre à la question : "Qui était l’entraîneur des jeunes gens ayant participé à cette rencontre ?" Il aura suffi d’avoir tiré un lien entre les entités-types RENCONTRE et ENTRAINEUR (ou PERSONNE, etc.)
Reste à s’assurer que l’on est capable de distinguer les équipes des joueurs ayant participé à la rencontre évoquée ci-dessus, en effet, pour le moment on amalgame peut-être partenaires et adversaires (à vérifier).

Votre MCD va certainement susciter des questions et observations de la part des forumeurs. Tant mieux pour vous ! (Attention aux penalties dont ils vont vous accabler !)

Pour ma part, je vous demande instamment de ne pas identifier les entités-types par leurs propriétés naturelles, mais par une propriété artificielle, sans signification, invariante (pour éviter l’instabilité de la base de données à venir) et permettant de distinguer des jumeaux parfaits (selon votre MCD, le Stade de France n’a pu accueillir qu’une seule rencontre durant toute son existence, un seul groupe de joueurs peut avoir un entraîneur nommé Martin, etc.)

Pour éviter (comme dans le cas de l’entraîneur) un éparpillement des propriétés des intervenants, remettez ensemble le nom et l’âge du capitaine (on a deux fois le nom du capitaine, puisqu'il est aussi un joueur...)

[touronster]

Merci pour votre réponse, concernant les identifiants, je sais qu'ils sont faux, mais le logiciel utilisé (AnalyseSI) souligne toujours la première caractéristique de l'entité (même si celui-ci n'est pas identifiant).

Concernant le GROUPE JOUEUR, en réalité, ce groupe est temporaire (établi avant la rencontre), il est constitué de plusieurs joueurs pouvant être retirés de la liste en cas de problème suite à la vérification de leur licence respective.

Concernant ce groupe, voici ce qui est dit :

"La veille de chaque match, les clubs établissent une liste de 15 à 18 joueurs (numéro maillot, nom, numéro licence) constituant le groupe pour la rencontre ; le nom de l'entraineur est également précisé. "

Ensuite il est dit que certains joueurs peuvent être retirés de la liste suite à des problèmes avec leurs licences.

Donc, comment gérer ce GROUPE JOUEUR et y préciser le nom de l'entraineur pour chaque GROUPE JOUEUR ?

Encore merci.

[fsmrel]

Pour traiter des joueurs prévus d’une part et des joueurs retenus d’autre part, on peut mettre en oeuvre un booléen Participation précisant si un joueur prévu a participé ou non à une rencontre.

Par ailleurs, pour une équipe et une rencontre données, on a un groupe unique prévu de joueurs et pour ce groupe on a un seul entraîneur, donc pour une équipe et une rencontre on a un entraîneur unique. Cet entraîneur est déterminé par l’association-type Prévoir Entraîneur (graphique à faire évoluer selon que l'on traite dans la modélisation seulement d'une équipe ou des deux équipes participant à la rencontre).

[touronster]

Merci pour votre aide ! Je crois que je me "collais" trop à l'énoncé ..

J'ai mis en pièce jointe ce que j'ai fait au final (surement pas encore parfait)..
Si vous avez des remarques / conseils..

Merci, ça m'a bien aidé je pense.