Discussion :

[Squale76]

Bonjour,

tout d'abord merci pour l'aide que vous pourrez m'apporter.

Je ne suis pas de formation informatique mais j'aime apprendre et surtout dans ce domaine (un développeur "sur le tard").

Je voudrais développer une application pour gérer les statistiques de joueurs de basket. Pour ce faire (et d'après ce que j'ai pu lire à droit, à gauche),la première chose à faire est de matérialiser les base de données par les schémas MCD et MLD.Ce que j'ai fait, mais n'étant pas très calé, je souhaiterais votre avis.
Surtout n'hésitez pas à critiquer, j'ai mis mon nez dans les SGBD que depuis 1 mois alors y aura sûrement des choses à dire, essayer juste d'être constructif merci....

Mon modèle en "texte" :

• Une saison est composée d'au moins une phase
• Une phase est composée d'au moins un match
• Une phase est définie par son type
• Un match est composé de deux clubs à une date
• Un Club est défini par un nom
• Un match contient 4 quart temps
• Dans un quart temps, il peut y avoir n tirs, n entrée, n rebond off., n rebond def., n interception, et n entre-sortie de joueurs et dure 10 min
• Un match de coupe peut avoir n prolongations
• Dans une prolongation, il peut y avoir n tirs, n entrée, n rebond off., n rebond def., n interception, et n entre-sortie de joueurs et dure 5 min
• Dans un match un joueur porte un numéro
• Un tir est défini par des coordonnées (X,Y) et un booléen (réussi ou pas)
• Une entrée sortie est définie par le joueur entrant, le joueur sortant, le décompte du quart temps, le score de l'equipe A et celui de l'equipe B
• Un rebond offensif est défini par un nombre par joueur dans un quart temps
• Un rebond défensif est défini par un nombre par joueur dans un quart temps
• Une interception est défini par un nombre par joueur dans un quart temps
• Une balle perdue est défini par un nombre par joueur dans un quart temps
• Une faute est défini par un nombre par joueur dans un quart temps
• Une passe décisive est défini par un nombre par joueur dans un quart temps

en PJ mon MCD et mon MLD.

Je pèches surtout sur les cardinalités, je n'ai pas trop bien saisi comment cela fonctionnait. Si vous pouviez détailler sur un exemple concret de mon schéma.

Merci d'avance.

[fsmrel]

Bonsoir Squale76,

Quelques observations :

1) Changez d’outil de modélisation, car celui que vous utilisez est beaucoup trop fruste en ce qui concerne votre sujet. Passez par exemple à Toad Data Modeler (gratuit), moins "conceptuel" mais plus souple, notamment en ce qui concerne le mécanisme d’identification. Ainsi, on peut présumer qu’un quart-temps n’est jamais qu’une propriété multivaluée d’un match donné, mais l’outil que vous utilisez ne permet pas de le prendre en compte.

2) Selon votre représentation, à un match donné peuvent participer un nombre quelconque de clubs, or il est d’usage que ce nombre soit limité à deux.

3) Les types d’action : rebond offensif, rebond défensif, contre, passe décisive, interception, balle perdue, font seulement l’objet d’une comptabilisation par joueur et par période (quart-temps, prolongation). Ces types d’action pourraient faire l’objet d’une entité-type unique TypeAction. En outre, cela rendrait transparente la prise en compte à l’avenir d’autres types d’action imaginés la FIBA.
Le nombre d’actions d’un type donné, par joueur et par période dans un match donné deviendrait attribut d’une entité-type associative disons Action, caractérisée par le joueur, le type d’action, le match et la période.

4) Selon votre représentation, un quart-temps n’a pas de propriétés en propre. Il ne représente qu’une "rondelle" de match. Il est inutile d’en faire une entité-type, il n’intervient que dans l’entité-type Action (en temps que propriété identifiante) et au besoin dans les entités-types Shoot et EntreeSortie.
En outre, je considèrerais le quart-temps plus comme une période, tout comme une prolongation : un quart-temps serait alors une période dont la valeur serait comprise entre 1 et 4, tandis qu’une prolongation serait une période dont la valeur serait supérieure à 5. On retrouve cela avec les attributs PeriodeNo du modèle ci-dessous, entités-types Action, EntreeSortie). J'ai omis de l'intégrer dans Shoot : au besoin le rajouter.

5) concernant les remplacements de joueurs (entrées sorties) : si l’attribut Heure (de préférence exprimé en secondes) prend la même valeur pour une entrée et une sortie, vous êtes à même de vérifier que le nombre de joueurs sur le terrain est constant : disons que la représentation est satisfaisante, mais :
Si l’instant du remplacement permettait de déterminer la période, alors cette dernière n’aurait pas à être en relation avec EntreeSortie. Mais les calculs sont peut-être compliqués ?
Dans le même sens, si j’ai bien compris qu’il s’agit de lui, le score du match (attributs ScoreA et ScoreB) dépendrait des remplacements parce que c’est seulement à ces occasions qu’on s’y intéresserait. Ceci dit, si le score est calculable à partir des données de l’entité-type Shoot, sous réserve que l’on y injecte l’heure du tir (et que l’on connaisse précisément le nombre de points représentés par chaque tir réussi), on saurait quel est le score du match au moment d’un remplacement (et à la fin d’un match...) mais là encore se pose un problème de faisabilité...

6) Je pense qu’il serait utile de mettre en œuvre une entité-type associative JoueurClub, porteuse de propriétés ne valant que dans le cadre du couple {joueur, club}, telles que la date à laquelle le joueur a intégré le club. A vous de voir.

7) On peut envisager la mise en œuvre d’une entité-type TypeMatch (permettant de déterminer si un match est un match de coupe ou non).

Ci-joint un modèle réalisé avec Toad Data Modeler. Ce modèle ne se veut pas exemplaire, mais permet d’illustrer quelques points tels que l’identification relative ou les associations multiples entre deux entités-types.

Signification des cardinalités.

La représentation des cardinalités n’est pas précisément la même que celle que vous avez utilisée, mais elle lui est équivalente.

Relation Joueur - JoueurClub
Pour une instance de Joueur, on peut avoir plusieurs instances de JoueurClub ("peut avoir" marque l’optionalité, d’où le 0 au-dessus du "trident").
Une instance de JoueurClub fait obligatoirement référence à une (et une seule) instance de Joueur.

Relation Club - JoueurClub
Pour une instance de Club, on a au moins une instance de JoueurClub.
Une instance de JoueurClub fait obligatoirement référence à une (et une seule) instance de Club.

Relations Club - Match
A un match participent exactement deux clubs (rôles respectifs A et B). Un club peut participer à plusieurs matchs (disons qu’en début de saison et avant constitution du calendrier, il n’a encore aucun match à son actif).

Etc.


A quand un modèle traitant des matchs de cricket ?

[Squale76]

Tout d'abord merci de votre aide.

J'ai quelques petites questions.
1) Auriez vous un lien pour telecharger Toad Data Modeler sans passer par un site où l'on doit téléphoner à un service surtaxé pour avoir un code. Et quelle version de ce logiciel dois je prendre pour faire ce genre de graph ?

2) Sur le modèle, je ne comprends pas l'intêret de mettre dans la table "EntreeSortie" les deux entités MatchIdE et MatchIdS. Un changement de joueur se déroule forcément dans le même match.

3) Sur le graph, quelle est la différence entre les liaisons en trait plein et celles en pointillés ?

4) Sur le graph, que signifie (PK), (PFK) et (FK) ?

5) Pour mieux comprendre le lien entre MCD et MLD, pourriez vous me transmettre le MCD de ce modèle ?

Encore merci pour votre aide, mon modèle se simplifie à vue d'oeil.

[hed62]

4) Sur le graph, que signifie (PK), (PFK) et (FK) ?

Ca je sais
PK : Primary Key, ou clef primaire
FK : Foreign Key, ou clef étrangère
PFK : les deux en meme temps.

5) Pour mieux comprendre le lien entre MCD et MLD,

Je te conseille de rechercher parmi les quelques tuto du site, la distinction y est abordée. Grossomodo, le MCD définit des concepts, le MLD en est une traduction en termes de logique, on se rapproche du modele physique de la base de données (MPD)

[Squale76]

Une Clé peut être primaire et étrangère en même temps ?

[fsmrel]

Une Clé peut être primaire et étrangère en même temps ?

Je réponds affirmativement et il ne faut pas se laisser abuser par le mot "clé" lui-même. Cette simultanéité se produit systématiquement dans le cadre de l'identification relative. Voyez le code des instructions CREATE TABLE ci-dessous.


En réponse aux questions de votre message de 14h33.

Point 1 :

Je viens de faire un tour sur le site de l’éditeur. Manifestement, Toad Data Modeler n’est plus gratuit depuis le passage à la version 3.
Il existe aussi DB Designer 4, mais celui-ci refuse d’établir plus d’une association entre deux entités-types...

Point 2 :

D’après votre modèle, un joueur peut quitter le terrain sans être remplacé (tel Drogba hier soir...) mais ici il s’agit non pas d'exclusion mais bien de remplacement et donc un joueur entrant prend nécessairement la place d’un sortant. Cela dit, l’entité-type EntreeSortie que j’ai proposée (ou table, peu importe) est à aménager au niveau de l’instruction SQL CREATE TABLE. En effet, il est fait deux fois mention du match (attributs MatchIdE et MatchIdS). Il est évident qu’il y a redondance puisqu’il s’agit du même match : MatchIdE = MatchIdS. Mais Toad ne me permet pas d’éliminer un des 2 attributs (en tout cas je n’ai pas trouvé le moyen de le faire). Il faut donc procéder à cette élimination manuellement pour obtenir le résultat suivant, dans lequel la table EntreeSortie ne comporte qu’un seul attribut MatchId :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

Create Table JoueurMatch (
    JoueurId      Integer   Not null
  , MatchId       Integer   Not null
  , Constraint JoueurMatchPK Primary Key (JoueurId, MatchId)   
  , Constraint JoueurMatchFK1 Foreign Key (MatchId)
                References Match
...   
) ;

Create Table EntreeSortie (
    JoueurEntrantId  Integer   Not null
  , MatchId          Integer   Not null
  , ESSequenceur     Integer   Not null
  , JoueurSortantId  Integer   Not null
  , PeriodeNo        Integer   Not null      
  , ScoreA           Integer   Not null
  , ScoreB           Integer   Not null
  , Constraint EntreeSortiePK Primary Key (JoueurEntrantId, MatchId, ESSequenceur)   
  , Constraint EntreeSortieAK1 Unique (JoueurSortantId, MatchId, ESSequenceur)   
  , Constraint EntreeSortieFK1 Foreign Key (JoueurEntrantId, MatchId)
                References JoueurMatch    
  , Constraint EntreeSortieFK2 Foreign Key (JoueurSortantId, MatchId)
                References JoueurMatch    
  , Constraint EntreeSortieC1 Check (JoueurEntrantId <> JoueurSortantId)   
) ;

Pour qu'il n'y ait pas de jaloux, le joueur sortant fait lui aussi l'objet d'une clé candidate. Pour faire bonne mesure, on peut s'assurer qu'un joueur ne se remplace pas lui-même...

Point 3 :

Il s’agit d’un effet mickey de Toad : un trait plein signifie qu’une entité-type est identifiée relativement à une autre. Un trait en pointillés signifie que l’identification relative ne joue pas (cas de votre MCD initial).

Point 4 :

hed62 a répondu. On peut encore dire que "PK" est la traduction de la l’identifiant du niveau conceptuel et "FK", la traduction du lien tiré entre les entités-types et les associations-types. "PFK" montre qu’un lien peut donc être identifiant (identification relative).

Point 5 :

Le problème est que Toad considère sa représentation graphique comme un MCD, il le désigne sous le nom de "Entity Relationship diagram" et chaque objet est pour lui une entité. Ça n’est pas faux dans la mesure où les Anglo-saxons ne sont pas inféodés à un style de représentation. un AGL lourd comme IEF (devenu Composer puis Cool:Gen, puis ...) utilise un style très voisin de celui de Toad. En fait Toad est hybride car il reprend au niveau conceptuel les principes de clé primaire et clé étrangère qui sont du niveau logique-relationnel, ce qui du reste n’est pas du tout gênant. On peut encore dire que Toad produit des MLD en récupérant des éléments du niveau conceptuel.
Pour satisfaire votre curiosité, je produirai l’équivalent avec PowerAMC, avec MCD et MLD.

[fsmrel]

le MLD en est une traduction en termes de logique, on se rapproche du modele physique de la base de données (MPD)

Le MLD est effectivement du niveau logique. On y parle de tables, d'attributs, de types, de clés candidates, d'intégrité référentielle, de contraintes, d'héritage, bref de choses qui ont à voir avec la théorie relationnelle, laquelle peut être considérée comme une branche des mathématiques appliquées. Le modèle logique et le modèle conceptuel ne se situent ni dans le temps ni dans l'espace.

Le niveau logique est indépendant du niveau physique, lequel traite des espaces (table spaces) et de leur organisation, de la granularité du verrouillage, des index, bref de toutes ces choses que chaque SGBD voit et organise à sa manière.

Il est vrai que certains éditeurs du genre PowerAMC ne sont pas regardants et mélangent allègrement les domaines, ce qui entretient la confusion...

[fsmrel]

Pour changer de Toad Data Modeler...


PowerAMC, MCD version Merise.

Identification relative : les traits pleins de Toad sont remplacés par la cardinalité 1,1 mise entre parenthèses.





PowerAMC, MCD version Entité-relation "US". L’identification relative est symbolisée par encore un autre mickey.





PowerAMC, MCD version OO




PowerAMC, MLD

Considérez la table EntreeSortie. Les mickeys pk (clé primaire), fk (clé étrangère) et ak (clé alternative) se lisent ainsi :

le triplet {JoueurEntrantId, MatchId, ESSequenceur} est clé primaire de la table.
le triplet {JoueurSortantId, MatchId, ESSequenceur} est clé alternative (mêmes vertus que la clé primaire).
le couple {JoueurEntrantId, MatchId} est clé étrangère (et référence la table JoueurMatch).
le couple {JoueurSortantId, MatchId} est clé étrangère (et référence aussi la table JoueurMatch).

[Squale76]

Tout d'abord merci pour votre aide.

J'ai essayé Toad Data Modeler (TDM) mais je n'ai réussi qu'à construire ce modèle (voir PJ).
Je n'arrives pas à modifier dans la table "Match" l'entité "ClubId" en "ClubIdA", pourriez vous m'expliquer la marche à suivre dans TDM.

De plus dans TDM, je n'arrive pas à générer le script SQL pour la création des tables et des clés. Il ne dit qu'il ne trouve pas "script.sql" et effectivement ce fichier n'existe pas à l'emplacement défini.
Pourriez vous m'envoyer ce fichier ?

Merci.

[fsmrel]

Je n'arrive pas à modifier dans la table "Match" l'entité "ClubId" en "ClubIdA

Cliquer sur l’entité Match.
La fenêtre Entity est ouverte : Cliquer sur le bouton EDIT après avoir sélectionné l’attribut ClubId. Ceci provoque l’ouverture de la fenêtre ATTRIBUTE.
Valoriser ROLENAME à "ClubIdA". Vous pouvez aussi valoriser COLUMN NAME, mais ça n’est pas une nécessité.

Il ne dit qu'il ne trouve pas "script.sql" et effectivement ce fichier n'existe pas à l'emplacement défini.

Ce fichier n’existe pas, parce que c’est vous qui allez le créer (sous le nom qui vous convient).
Avez-vous procédé à la vérification du modèle ? (raccourci : CTRL+F9)
Que voyez-vous quand il affiche la fenêtre "Script generating" ?
Changez le nom du fichier à générer (cartouche File), par exemple "Basket.sql"
Cochez les options qui vont bien (Tables, Primary key, Referential integrity...)
Faites GENERATE puis VIEW.
Normalement, le fichier "Basket.sql" est créé...

[ArtoS]

PowerAMC, MCD version OO

Si je ne m'abuse, il s'agit d'un diagramme de classe UML (donc Orienté Objet comme vous l'annoncez). Donc en aucun cas il ne saurait parfaitement décrire un Système d'informations comme le ferait Merise. L'UML n'est pas une méthode d'analyse des bases de données, bien que certains l'utilisent dans ce but. Personnellement, je vois plutôt l'UML côté "traitement", donc par les tâches que celui-ci doit effectuer. Alors que Merise décrit les relations entre les données et en ce sens, il est utilisé pour décrire les schémas de base de données relationnelle.


Concernant le MCD, il est d'usage d'informer dans l'association l'action de celle-ci par un verbe unique au modèle.

[fsmrel]

Si je ne m'abuse, il s'agit d'un diagramme de classe UML (donc Orienté Objet comme vous l'annoncez).

Vous ne vous abusez pas.

Donc en aucun cas il ne saurait parfaitement décrire un Système d'informations comme le ferait Merise.

Je ne vois pas en quoi un diagramme de classes n’a pas la capacité descriptrice que vous attribuez à Merise. Par ailleurs, l’objet de la discussion n’est pas ici de comparer les vertus et défauts respectifs d’UML et de Merise, mais de représenter un certain univers du discours touchant à une activité sportive. En l'occurrence, un diagramme de classes, un MCD Merise ou un schéma IE ou autre font parfaitement l’affaire.

=> Votre conclusion concerne d’autres discussions que vous pourrez consulter chez developpez.com.

L'UML n'est pas une méthode d'analyse des bases de données, bien que certains l'utilisent dans ce but. Personnellement, je vois plutôt l'UML côté "traitement", donc par les tâches que celui-ci doit effectuer

Vous irez expliquer tout cela à ceux qui sont directement concernés, Christian Soutou par exemple.

Merise décrit les relations entre les données et en ce sens, il est utilisé pour décrire les schémas de base de données relationnelle.

Merise permet de décrire les relations entre les données et, grâce au ciel ! UML aussi (parfois de façon moins laborieuse que Merise, voyez par exemple l’agrégation et la composition). Ainsi, j’ai fourni différents types de diagrammes en ce sens. Peut-être aurais-je dû utiliser IA (NIAM) qui selon le grand merisien Yves Tabourier est supérieur à Merise, quant à l’aptitude à décrire la structure du réel et à expliquer le lien entre structure du réel et structure des données (voyez "De l’autre côté de Merise", pages 160 à 175).

Quant à produire un schéma de base de données relationnelle, Merise en permet une représentation anatomique (pas forcément complète : par exemple il n'est pas possible de prendre en compte l’ensemble des clés candidates des tables d’une base de données relationnelle). Le schéma produit est à nettoyer (par exemple l’entité-type Date qui n’a rien à faire au niveau relationnel, puisqu’en réalité il s’agit d’un type). Quant à la partie métabolique (réactions aux stimuli de destruction par exemple), beaucoup reste à faire, même si Merise 2 propose certaines choses (verrouillage de patte par exemple).

Concernant le MCD, il est d'usage d'informer dans l'association l'action de celle-ci par un verbe unique au modèle.

Oui, oui, oui, ..., oui.