Discussion :

[yinkoh]

Bonjour,

Après avoir pas mal cherché d'exemples et bien avancé dans mon MCD, je viens en quête d'informations avant de me lancer dans le développement de l'application qui utilisera la bdd.

J'ai créé l'entité "sanction" (attributs: id,raison,durée) qui possède une association "affecter" vers plusieurs entités ("joueur", "club", "équipe", "match" [Toutes définies par un id unique]) avec à chaque fois des cardinalités 0,n.

Ma question est la suivante:

Est-il pertinent de laisser l'entité "sanction" ou bien est-il plus judicieux de placer les attributs de celle-ci directement dans l'association "affecter" ?


Cordialement.

[fsmrel]

Bonsoir yinkoh,


Votre narration est ambiguë. Y a-t-il autant d'associations AFFECTER avec SANCTION qu'il y a d'entités-types : JOUEUR, CLUB, etc., ou bien ces dernières viennent-elles toutes se brancher sur une association AFFECTER unique ?

Pourriez-vous présenter une esquisse de votre MCD ?

[CinePhil]

Je trouve moi aussi la formulation ambigüe.

Je m'attarderai donc sur un autre aspect :

J'ai créé l'entité "sanction" (attributs: id,raison,durée)

J'imagine que ces sanctions peuvent être, par exemple : "suspension", "exclusion", "amende"...
Ces trois sanctions peuvent s'appliquer à plusieurs joueurs ou équipes et pour des durées variables. Je ferais donc une entité-type "sanction" avec seulement un id et un libellé et je mettrais dans les associations "affecter" les propriétés "raison" et "duree".

[yinkoh]

Je veux bien admettre la formulation ambiguë car j'ai déjà du mal à la formuler correctement dans ma tête...



Les deux gros points noirs sont les associations "affecter" et "participer" (Liée à l'entité "season") qui me semblent erronées dans leurs conceptions.

Pour répondre à CinePhil, oui, je pense que votre proposition se rapproche de ce que je recherche puisqu'il existe des barèmes de sanction type.

En partant de ce postulat, n'est-il pas plus judicieux de lister dans la table "sanction" l'ensemble des sanctions possibles avec leurs durées et de limiter l'association "affecter" à une date à laquelle la sanction prend effet ?

[chewing-gum]

Est-il pertinent de laisser l'entité "sanction" ou bien est-il plus judicieux de placer les attributs de celle-ci directement dans l'association "affecter" ?

Pour répondre à la question de départ, je pense qu'il est très pertinent d'avoir une entité [SANCTION] avec comme propriétés : un identifiant et le libellé de la sanction.
CinePhil conseillait aussi de mettre les propriétés "durée" et "raison" dans l'association (AFFECTER), mais à titre personnel, cela ne me choque pas que ça soit dans l'entité [SANCTION]. Tout dépend si la durée de la sanction est variable ou non / si la raison est variable ou non.

En revanche, au vu du MCD, je ne comprends pas très bien pourquoi l'association (AFFECTER) concerne aussi les entités [TEAM] et [CLUB] ? Une sanction peut-elle aussi être affligée à un club / une équipe ? Est-ce parce que vous avez besoin de savoir dans quelle équipe / quel club se trouve la personne (dans ce cas, ne pouvez-vous pas retrouver l'équipe / le club à partir de la personne ?).

[yinkoh]

En revanche, au vu du MCD, je ne comprends pas très bien pourquoi l'association (AFFECTER) concerne aussi les entités [TEAM] et [CLUB] ? Une sanction peut-elle aussi être affligée à un club / une équipe ? Est-ce parce que vous avez besoin de savoir dans quelle équipe / quel club se trouve la personne (dans ce cas, ne pouvez-vous pas retrouver l'équipe / le club à partir de la personne ?).

En effet, une sanction peut concerner une équipe (Feuille de match manquante) aussi bien qu'un club (Dettes), qu'un joueur (Mauvais comportement).

Dans le cas, par exemple, d'une suspension d'un club, la sanction sera propagée à tous les enfants [TEAM], [PLAYER] liés à ce dernier.

[fsmrel]

Bonsoir,

Une sanction peut concerner une équipe (Feuille de match manquante) aussi bien qu'un club (Dettes), qu'un joueur (Mauvais comportement).
Dans le cas, par exemple, d'une suspension d'un club, la sanction sera propagée à tous les enfants [TEAM], [PLAYER] liés à ce dernier.

Si une sanction frappe un club, inutile de matérialiser la propagation de cette sanction aux équipes appartenant au club puis aux joueurs du club, puisqu’on sait déterminer quelles sont ces équipes et les joueurs au moment de la sanction (dans la mesure où les dates correspondantes sont bien là).

En outre, du strict point de vue de la modélisation, lors du passage au MLD, l’association AFFECTER donnera lieu à une table ayant pour clé primaire {sa_id, pe_id, cl_id, te_id, ga_id} ; En effet, les entités-types branchées sur AFFECTER le sont toutes avec une cardinalité 0,N, or une équipe (team) fait partie d’un club et un seul, l’attribut te_id doit dégager de la clé, autrement dit, dans le MCD, l’association n’est pas merisement correcte.


Par contrecoup, pour les sanctions visant les clubs, on doit mettre en œuvre une association, appelons-la SANCTION_CLUB, connectant SANCTION et CLUB, etc. En supposant que les motifs de sanction, leur date d’effet et leur durée soient spécifiques au sanctionnés :




On peut éventuellement procéder à une généralisation :





Selon votre MCD, une personne peut jouer contre elle-même. En effet, une occurrence de l’entité-type PERSONNE peut être associée à plusieurs occurrences de l’entité-type PLAYER (association ÊTRE) et chaque joueur (instance PLAYER) faire partie d’un club différent (association FAIRE_PARTIE associant PLAYER et CLUB), or ne figure aucune contrainte temporelle pouvant empêcher cette situation. De toute façon, l’association FAIRE_PARTIE en question devrait disparaître (à une présence de dates près), puisqu’on sait la recomposer par transitivité : un joueur (player) joue dans une équipe (team) et une équipe fait partie d’un club.

[yinkoh]

Merci pour vos réponses.

@fsmrel, la propagation était un exemple et ne devait pas réellement se matérialiser dans le schéma mais votre démonstration reste correcte.

L'association telle que définie dans le mcd actuel ne me convenait pas mais je n'arrivai pas à comprendre le pourquoi, ce qui est chose faite à présent grâce à votre réponse (Même si cela implique de nouvelles liaisons :p).

En revanche, concernant les deux derniers points que vous soulevez, l'un est exact (Pour la cardinalité entre [person] et [player] mais pour le second il est partiellement vrai.

La cardinalité entre [club] et [player] est erroné en effet mais elle est obligatoire car lors de l'importation de données un joueur, ce dernier ne possède qu'un numéro de licence et un numéro de club.

C'est au gestionnaire du système d'associer un joueur à une équipe.

C'est donc par contrainte que je suis obligé de laisser cette association.


L'association "participer" vous paraît-elle correcte au fait ?


Je vais aller parcourir votre blog qui devrait m'aider à organiser mes pensées

[fsmrel]

Bonsoir yinkoh,

C'est au gestionnaire du système d'associer un joueur à une équipe.
C'est donc par contrainte que je suis obligé de laisser cette association.

C’est effectivement dans ce sens qu’allait ma remarque. Si donc vous devez conserver l’association connectant PLAYER et CLUB la cardinalité 1,1 portée par la patte connectant PLAYER et JOUER DANS doit être remplacée par une cardinalité 0,1, et il sera prudent par ailleurs de mettre en œuvre une contrainte CK1 garantissant que le club du joueur et le club de l’équipe dont ce joueur fait (enfin) partie ne font qu’un : un joueur (player) ne peut pas à la fois faire partie d’un club et d’une équipe d’un club qui n’est pas le sien...

Lors du passage en SQL, la contrainte CK1 fait en théorie l’objet d’une assertion, au moyen de l’instruction CREATE ASSERTION proposée par la norme SQL/92. Mais comme les SGBD répugnent à proposer cette instruction, reste l’utilisation de triggers, par comparaison toujours lourds et délicats à programmer dans ce cas de figure. Par ailleurs, la cardinalité 0,1 se traduit par la présence du bonhomme NULL au stade SQL et NULL se révèle comme uns semeur de m... dans les bases de données.

Pour éviter la présence du bonhomme NULL, je vous propose (vous n’êtes pas obligé de me suivre !) de remplacer l’association JOUER_DANS par une entité-type (nommée PLAYER_TEAM ci-dessous). En plus, pour résoudre la contrainte CK1 sans avoir à programmer des triggers, je vous propose (vous n’êtes toujours pas obligé de me suivre !) :

1) D’identifier TEAM relativement à CLUB (après tout, une équipe n’est jamais qu’une propriété multivaluée d’un club et sans club une équipe n’a pas de sens).

2) D’identifier PLAYER relativement à CLUB :





Rappel : avec PowerAMC, l’identification relative est symbolisée par mise entre parenthèses des cardinalités 1,1.


Le MLD devient le suivant (après suppression d’une clé étrangère bêtement générée par l’AGL, entre PLAYER et PLAYER_TEAM, dans le sens PLAYER vers PLAYER_TEAM) :




Les symboles c, p, t désignant des entiers quelconques, Si PLAYER_TEAM de clé primaire {ClubId, PlayerId} contient la paire <c, p>, où le singleton <c> désigne un certain club et <c, p> identifie un joueur du club <c>, alors ce joueur ne peut pas faire partie d’un club <c’> différent de <c>. Par ailleurs, en vertu de l’intégrité référentielle, <c, p> est une valeur de la clé primaire {Clubid, PlayerId} de la table PLAYER et, toujours en vertu de l’intégrité référentielle, <c> doit être à son tour une valeur de la clé primaire {ClubId} de CLUB. De la même façon, si dans PLAYER_TEAM est présente la paire <c, t>, où le singleton <c> désigne encore le club dont il est question, alors en vertu de l’intégrité référentielle, <c, t> est aussi une valeur de la clé primaire {ClubId, TeamId} de la table TEAM et <c> doit être à son tour une valeur de la clé primaire {ClubId} de CLUB. En vertu de l’unicité des clés primaires, un joueur (player) ne peut pas faire partie en même temps de deux clubs différents.

L'association "participer" vous paraît-elle correcte au fait ?

On retrouve en quelque sorte une variante du problème précédent : si un certain joueur fait partie d’une certaine équipe, il ne doit pas pouvoir participer pour le compte d’une autre équipe. C’est cela ?

Examinons le MLD issu du MCD :




Selon la structure de la table PARTICIPATION, un joueur, une équipe, ne peuvent participer pour le compte d’un club auquel ils n’appartiennent pas. Par contre, un joueur peut participer pour le compte d’une équipe de son club, mais qui n’est celle à laquelle il appartient. Si c’est interdit, cette fois-ci il faudra un trigger, ou rendre le triplet {ClubId, TeamId, PlayerId} clé alternative (en fait surclé) de la table PLAYER_TEAM, en sorte que ce même triplet appartenant à l’en-tête de PARTICIPATION y soit clé étrangère par rapport à cette clé alternative de PLAYER_TEAM (on ne touche pas à la clé primaire {ClubId, PlayerId} de PLAYER_TEAM !)

Et n'oubliez pas de voter quand une réponse vous a été utile...

[yinkoh]

Encore merci pour vos réponses !

Je vais étudier tout cela et je reviendrai sur ce topic une fois que j'aurai un peu plus avancé.

[yinkoh]

Bonjour,

Je reviens vers vous en quête d'éclaircissement (et d'aide ).

J'ai modifié les relations de sanction et des individus en fonction de vos remarques, il me reste à présent à m'occuper de la partie "saison".

En lisant les règlements, j'ai pu énoncer des règles de gestion:

- un club est composé d'un bureau de 3 individus minimum (Président, Secrétaire, Trésorier).
- un club doit s'affilier chaque saison à la fédération pour pouvoir participer.
- un club peut pratiquer une ou plusieurs activités.
- chaque activité d'un club peut engendrer une ou plusieurs équipes.
- une compétition se déroule sur une saison.
- une équipe participe à une ou plusieurs compétitions.

La relation entre les entités "team" et "ladder" n'est pas représentée sur le diagramme.

Je souhaite savoir si ma modélisation de la règle "un club doit s'affilier chaque saison à la fédération pour pouvoir participer" est correcte.





Merci de votre aide.

[fsmrel]

Bonsoir yinkoh,

Je souhaite savoir si ma modélisation de la règle "un club doit s'affilier chaque saison à la fédération pour pouvoir participer" est correcte.

Considérons votre diagramme :




Il y a un problème : du fait de la cardinalité 0,1 portée par la patte connectant s_affilier er club, on doit comprendre qu’un club peut ne pas être affilié à comité départemental, alors qu’en fait, qu’il soit ou non affilié, on aimerait probablement bien savoir quel est le comité dont il relève.

Il serait sans doute préférable de remplacer la cardinalité 0,1, par 1,1 et prévoir pour CLUB un attribut, nommons-le DateDerniereAffiliation, permettant de savoir où en est l’affiliation.

[yinkoh]

Bonjour,

En réalité un club peut ne pas s'affilier pour une saison, c'est la raison pour laquelle j'avais placé la cardinalité "0,1". L'autre contrainte est que le numéro d'affiliation est le même d'année en année et ce, même si il y a eu une année sans affiliation.
Je souhaite donc être en capacité de savoir si un club X s'est affilié telle ou telle année.

Avec le mcd de cette manière, je souhaite utiliser la transitivité (enregistrée dans club) pour trouver la saison d'une équipe ou d'un joueur.

Du coup, je me demandai si les relations entre les tables club, commitee et season ne devaient pas ressembler à celles liant team, player et club.

J'espère être clair dans mes propos quant à ce que je souhaite réaliser.

[fsmrel]

Bonsoir yinkoh,

En réalité un club peut ne pas s'affilier pour une saison, c'est la raison pour laquelle j'avais placé la cardinalité "0,1". L'autre contrainte est que le numéro d'affiliation est le même d'année en année et ce, même si il y a eu une année sans affiliation.

Une modélisation possible est la suivante :





Où l’entité-type AFFILIATION_HISTO permet de suivre les affiliations des clubs. Notez l’identification relative de AFFILIATION_HISTO par rapport à CLUB.

Exemple :


Le club 1 a été affilié entre 1990 et 1998, entre 2000 et 2008 et à nouveau depuis 2014 ;

Le club 2 a été affilié entre 1995 et 2013, mais il n’est pas affilié en 2014 ;

Le club 3 n’est plus affilié depuis 2010 ;

Le club 4 est affilié depuis 1997, sans interruption.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
ClubId    Debut    Fin
------    -----
     1     1990    1998
     1     2000    2008
     1     2014    2014

     2     1995    2013

     3     1998    2009

     4     1997    2014

MLD :




Il y a d'autres représentations possibles.

[yinkoh]

En effet, cette modélisation permet de répondre à la contrainte.

Je me demande s'il est nécessaire de renseigner le champ "Fin" dans le cas où un club est toujours actif, pour répondre votre exemple:

Le club 1 a été affilié entre 1990 et 1998, entre 2000 et 2008 et à nouveau depuis 2014 ;

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
ClubId    Debut    Fin
------    -----
     1     1990    1998
     1     2000    2008
     1     2014    -

Et dernier point, si j'utilise votre conception et que j'ai bien saisi la démarche, je devrai faire une jointure (pour la table saison) basée sur la valeur d'une année et non sur son index n'est ce pas ?

[fsmrel]

Bonjour yinkoh,

Je me demande s'il est nécessaire de renseigner le champ "Fin" dans le cas où un club est toujours actif.

J’aurais dû préciser que début et fin sont traditionnellement les deux composants du type période, plus précisément ici du type période de validité d’une affiliation¹. Par ailleurs, ces composants sont en l’occurrence du type année, et « - » n’étant pas une année, il en résulte une erreur de type (le modèle relationnel de données est très pointilleux quant à l'intégrité des types).

Par ailleurs, d’un côté pratique, si en 2015 le club 1 ne s’affilie pas, dès le 1er janvier vous devrez ne pas oublier de remplacer « - » par « 2014 », sinon le club sera considéré affilié, à tort. Maintenant vous pourrez adopter l'attitude inverse : tant que le club n'aura pas manifesté son intention de ne plus être affilié, par défaut il le restera... Qu'elle est votre position quant à cette alternative ? Cette question est importante, car la modélisation est en jeu...

je devrai faire une jointure (pour la table saison) basée sur la valeur d'une année et non sur son index n'est ce pas ?

Qu'entendez-vous par index ? Quoi qu’il en soit, en relationnel on doit respecter la règle de l’information (Information Rule), à savoir que dans une base de données relationnelle, l’information est représentée d’une façon unique, à savoir au moyen de valeurs (pas de pointeurs pas d’absence d’information et autres procédés).

____________________________
¹ du point de vue théorique, Période est une spécialisation d’un type plus général, à savoir Intervalle.