Clé étrangére et cardinalité 0,1 [Débutant(e)] [Résolu]

[Erric]

Bonjour,

J'ai les deux tables suivantes :
[clubFootball]--0,1--------------0,n--[joueurFootball]

Un club de Football peux contenir 0 ou n joueur.
Un joueur de Football peux être inscrit dans 0 ou 1 club.

Pour ce faire, je créé une clé étrangère clubFootball_idClub dans la table joueurFootball que j'initialise à NULL.
Puis je demande à mon application (lors de la création d'un joueur) de ne toucher au champs idClub uniquement si celui ci est resseigné .. sinon on le laisse a NULL

Est-ce une bonne méthode de faire ?
Merci pour votre aide !

[CinePhil]

Envoyé par Erric

Bonjour,

J'ai les deux tables suivantes :
[clubFootball]--0,1--------------0,n--[joueurFootball]

Un club de Football peux contenir 0 ou n joueur.
Un joueur de Football peux être inscrit dans 0 ou 1 club.

Tes cardinalités et tes règles de gestion sont inversées !
Voilà le MCD qui correspond à tes règles de gestion.
club -0,n----contenir----0,1- joueur

Pour ce faire, je créé une clé étrangère clubFootball_idClub dans la table joueurFootball que j'initialise à NULL.
Puis je demande à mon application (lors de la création d'un joueur) de ne toucher au champs idClub uniquement si celui ci est resseigné .. sinon on le laisse a NULL

Est-ce une bonne méthode de faire ?
Merci pour votre aide !

En toute rigueur, les cardinalités (0,1 - 0,n) entraînent la création d'une table associative dont la clé primaire est constituée par l'identifiant de la table située du côté 0,1.
Voir mon blog à ce sujet.

[Erric]

Merci pour le blog, c'est clair et précis !

Pour le sens des cardinalités : existe t-il plusieurs normalisation ?
Dans le logiciel MySQL Workbench j'ai l'impression qu'elles sont inversées ...

[Erric]

Voici un exemple :

Lorsque je créé cette relation : Par rapport aux cardinalités, la clé étrangère n'est-elle pas automatiquement ajoutée dans la mauvaise table ?

[sevyc64]

Concernant les cardinalités, elles ne me semblent pas inversées. De ce que j'ai compris de mon initiation à la modélisation, je les ai appris aussi dans ce sens là


Concernant la clé étrangère, je suppose que c'est un des cas évoqués dans le blog (que j'ai lu en travers) et qui font débat ?

Personnellement, je ne vois aucun intérêt à faire une classe d'association dans ce cas là, si ce n'est à complexifier la compréhension de la relation. Si le joueur ne peut être que dans un seul club à la fois, la clé étrangère dans la table joueur est suffisante.

Par contre, si tu dois conserver un historique des clubs passés du joueur, l'affaire est tout autre, et la table d'association est, là, inévitable (avec comme infos supplémentaires la date d'entrée et la date de sortie, par exemple)

[Erric]

Salut sevyc64,

Pour les cardinalités moi j'ai appris dans le sens dont parle CinePhil mais le soft MySQL Workbench m'a tout embrouillé ...

@CinePhil : Dans l'exemple ci-dessus la clé étrangère ne devrait elle pas se retrouver dans la table issue de l'entité située du côté des cardinalités 1,1 ?

Envoyé par sevyc64

Personnellement, je ne vois aucun intérêt à faire une classe d'association dans ce cas là, si ce n'est à complexifier la compréhension de la relation. Si le joueur ne peut être que dans un seul club à la fois, la clé étrangère dans la table joueur est suffisante.

En fait, oui le joueur ne peut être que dans un seul club à la fois, mais en plus je veux pouvoir avoir des joueurs qui n'apartiennent à aucun club (cardinalité 0,1), c'est pour cette deuxième propriété que la table d'association est utile ...

C'est ce que le blog m'a permis de comprendre et je suis d'accord que cette facon de faire je la trouve plus "propre". (mais effectivement ca doit compliquer un peu plus l'application).

[CinePhil]

Envoyé par Erric

Pour le sens des cardinalités : existe t-il plusieurs normalisation ?
Dans le logiciel MySQL Workbench j'ai l'impression qu'elles sont inversées ...

Dans le modèle conceptuel de données (MCD) standard de la méthode Merise, les cardinalités sont bien dans le sens que j'ai donné.

A -0,1----associer----0,n- B

Pour comprendre les cardinalités, on coupe l'association en deux morceaux. Comme disait M. Mazet, mon prof au CNAM : "On s'arrête à la patate !"

Combien de fois l'entité type A participe t-elle à l'association ?
=> A -0,1----associer
Mini : 0 fois
Maxi : 1 fois

Combien de fois l'entité type B participe t-elle à l'association ?
=> associer----0,n- B
Mini : 0 fois
Maxi : n fois

Simple !

Le schéma par défaut de MySQL Workbench est un schéma Entity/Relationship qui est plus proche du modèle logique de données (MLD) que du MCD.

Envoyé par Erric

Voici un exemple :

Lorsque je créé cette relation : Par rapport aux cardinalités, la clé étrangère n'est-elle pas automatiquement ajoutée dans la mauvaise table ?

Ce schéma ressemble dans son formalisme au MCD merisien mais les "cardinalités" utilisées sont en fait plutôt les "multiplicités" du diagramme de classes UML.
Et il se trouve que les multiplicités UML sont inversées par rapport aux cardinalités Merise ! On se demande bien pourquoi ?!

Dans ce schéma, pour savoir combien de fois un A peut être associé à un B, il faut aller jusqu'au bout de la "relationship", jusqu'aux multiplicités situées du côté de l'autre "entity".

C'est donc bien B qui est associée 1 et 1 seule fois à A et qui accueille la clé étrangère référençant B.

Envoyé par sevyc64

Concernant les cardinalités, elles ne me semblent pas inversées. De ce que j'ai compris de mon initiation à la modélisation, je les ai appris aussi dans ce sens là

Peut-être as-tu étudié la modélisation UML ?

Concernant la clé étrangère, je suppose que c'est un des cas évoqués dans le blog (que j'ai lu en travers) et qui font débat ?

Oui, il s'agit ici du cas 03.
Le débat, déjà abordé dans plusieurs discussion de nos forums, concerne l'acceptation ou non qu'une clé étrangère soit "nullable".
Pour ma part, je me range du côté de fsmrel qui tire à vue sur le bonhomme NULL, fort de ses 40 ans d'expérience dans le mon des bases de données.

Personnellement, je ne vois aucun intérêt à faire une classe d'association dans ce cas là, si ce n'est à complexifier la compréhension de la relation.

Ça ne complique pas du tout la compréhension de l'association, ni sur le plan du MCD, ni sur le plan du MLD dès lors qu'on applique avec rigueur et régularité ce principe : pas de clé étrangère à NULL !

Par contre, si tu dois conserver un historique des clubs passés du joueur, l'affaire est tout autre, et la table d'association est, là, inévitable (avec comme infos supplémentaires la date d'entrée et la date de sortie, par exemple)

On est bien d'accord, mais alors les cardinalités deviennent (0,n - 0,n).

[Erric]

Merci CinePhil pour ces explications !

[sevyc64]

Envoyé par Erric

En fait, oui le joueur ne peut être que dans un seul club à la fois, mais en plus je veux pouvoir avoir des joueurs qui n'apartiennent à aucun club (cardinalité 0,1), c'est pour cette deuxième propriété que la table d'association est utile ...

Bof, je vois toujours pas l'intéret. Une simple clé étrangère dans la table suffit à gérer ce cas.

Je vais lire ce fameux blog, alors (ça ne me dérange pas d'avoir une clé étrangère à Null, vais voir les arguments avancés).

Envoyé par CinePhil

Peut-être as-tu étudié la modélisation UML ?

Ben non justement, Merise par des cours du CNAM l'été dernier.

Mais c'est vrai que je suis arrivé sans avoir jamais étudier la modélisation mais avec quand même quelques années de gestions de bases de données derrière. J'ai eu du mal à faire abstraction du modèle physique. Mais je me rappelle avoir eu du mal à comprendre cette notation A-0,1-------0,n-B ou A pouvait référencer plusieurs B mais ou B ne référençait qu'un seul A. Elle me semblait justement à l'envers, mais c'est bien comme ça que je l'ai apprise dans mes souvenirs.

Je suis bon pour reprendre mes cours.

[CinePhil]

Envoyé par sevyc64

Je suis bon pour reprendre mes cours.

Il me semble bien oui !