Discussion :

[klatbah]

Bonjour à tous,

Je suis actuellement en formation Méthode et Techniques des S.I.G (Système d'Informations Géographiques) et dans le cadre de cette formation, j'apprends la création de MCD et MLD avec la méthode MERISE, et dans le cadre d'un projet personnel je souhaite me créer une base de données portant sur la NBA comme je l'ai marqué dans le titre. Je travaille avec le logiciel JMerise.

Comme données de départ j'ai récupéré 3 fichiers que j'ai trouvé :

- player_data(nom,année de début,année de fin,position,taille,poids,date de naissance,college )
- players( nom,taille,poids,college,ville de naissance,état de naissance)
-season_stats(année,nom du joueur,position, age,équipe,et beaucoup de champs de stats )

Pour que vous puissiez avoir une vue d'ensemble des données de départ j'ai limité les stats et les joueurs aux deux premières années des fichiers à savoir 1950 et 1951.
Voici le fichier

nba_players_stats_mod.rar

Je voudrais ensuite intégrer des fichiers avec les coordonnées et les limites des états afin de pouvoir m'entraîner aux requêtes SQL sur Postgre et Postgis. Je ne pense pas avoir de soucis avec cette étape. Les villes apparaîtront sous forme de point sur la carte,ou éventuellement de polygones.

Si je poste ici c'est que lors de la réalisation du MCD je me suis posé plusieurs questions et j'aimerais avoir votre avis sur la meilleure facon de le réaliser :

-Les statistiques sont rangées par années et un même joueur peut apparaître plusieurs fois dans les stats d'une année avec une équipe différentes. Du coup comment organiser les relations entre les entités joueurs, stats et équipes et les années ( j'y reviens plus bas ). C'est vraiment ce point la sur lequel j'ai le plus de mal et je ne sais pas vraiment quelle serait la meilleure organisation

- Lorsqu'un joueur a joué dans plusieurs équipes il y a une ligne avec l'ensemble de ses stats ( si il a joué 15 matchs avec l'équipe A et 12 avec l'équipe B il y aura 27 matchs dans TOT ). Du coup comment intégrer cette colonne TOT, est-ce qu'il faut la considérer comme une équipe ou tout simplement ne pas la prendre

- Comment intégrer les différentes années comprises dans le MCD,est ce qu'on les met directement dans les stats tel quel, ou créer une table par année,mais du coup vu que le fichier commence en 1950, cela ferait énormément de tables.

- Quant aux statistiques elles même il y a souvent une colonne qui est le résumé de deux autres (par exemple FG% et le pourcentage entre les FG réussi(FG) et les FG tentés (FGA). Est ce pertinent afin de limiter le nombre de champs dans la colonne stats d'en faire une entité à part et de la relier à l'entité stats.

Voila les différents modèles que j'ai créé, j'attends vos avis.


Dans celui ci les joueurs et les équipes ne sont pas reliées directement entre elles mais elle le sont par l'entité stats.

Et dans celui ci sur lequel je travaille actuellement les stats sont dans une relation entre les joueurs et les équipes .


J'attends vos avis et comme je l'ai dit plus haut le point qui me pose le plus problème c'est comment bien lier les 4 entités principales( ou 3 si les années ne sont pas une entité) joueurs, équipes et stats.

Merci d'avance

[escartefigue]

Bonsoir klatbah,

Avant de vous lancer bille en tête dans la modélisation, il faut rédiger les règles de gestion

Par exemple, pour ce qui concerne les joueurs et les statistiques il est très probable que les règles de gestions soient les suivantes :
R01a : un joueur est concerné par zéro (nouveau joueur) à plusieurs statistiques
R01b : une statistique concerne un et un seul joueur

Pour ce qui concerne les joueurs et les collèges, on peut supposer les règles de gestion suivantes :
R02a : un joueur a étudié dans un ou plusieurs collèges
R02b : dans un collège un ou plusieurs joueurs ont étudié

De ce petit extrait des règles de gestion qui vous concernent, voici le MCD qui en découle :

STATISTIQUE (1,1) --- concerner --- 0,n JOUEUR 1,n --- étudier --- 1,n COLLÈGE
notez les parenthèses autour des cardinalités des stats, pour mettre en évidence que sans joueur, point de statistique, autrement dit, les statistiques sont une entité-type dite "faible".
Ce faisant au niveau tabulaire (dans le MLD donc), l'identifiant des statistiques est constitué de l'identifiant du joueur + un chrono pour permettre d'avoir plusieurs stats pour un même joueur.

A partir de là, si vous utilisez un logiciel de modélisation (il en existe des gratuits que vous pouvez télécharger), il est très facile de générer automatiquement le MLD et donc les tables suivantes
STATISTIQUE (JO_ident, ST_ident, ST_date, ...)
JOUEUR(JO_ident, JO_nom, JO_prenom, JO_Date_Nais, ...)
ETUDIER(JO_ident #, CO_ident#, DT_debut, DT_fin, ...) comme la relation dans le MCD a des cardinalités maxi n de chaque coté, elle devient une table
COLLEGE(CO_ident, CO_nom, ...)

Donc, complétez les règles de gestion, le MCD puis le MLD en découleront

[fsmrel]

Au bout du compte, il faudra éviter de produire des tableaux du genre de celui ci-dessous (j’espère qu’avec les années sports.fr a amélioré sa programmation)...

M’enfin... Nicolas Batum pèse quand même bien 41 kg, ça n’est pas assez ? Wes Matthiews et Marcus Camby portent bien le même numéro, des joueurs ont plus de 2000 ans, etc. Pas mal, non ? Dans ces conditions, pourquoi n'aurait-on pas 10 pivots de 1,20 m ayant 2000 ans, pesant 500 kg et portant le même numéro ?

[klatbah]

Bon dimanche à tous,

Merci pour vos réponses j'ai bien avancé de mon côté et depuis le temps je suis arrivé à un MCD qui me semble correct, alors après il y aura des champs qui seront en doublon, mais je voulais vous montrer ou j'en étais actuellement, et avoir vos avis sur les règles de gestion

Donc voila le MCD actuel j'ai ajouté les statistiques des équipes et la draft.



Et donc pour les règles de gestion :

J'ai repris le modèle d'escartefigue et je l'ai modifié au niveau des collèges vu que dans les données que j'ai il n'y a qu'un seul collège par joueur

joueurs & collèges :

R01a : un joueur a étudié dans un ou aucun collèges
R01b : dans un collège un ou plusieurs joueurs ont étudié

joueurs & statistiques :
R02a : un joueur est concerné par zéro (nouveau joueur) à plusieurs statistiques
R02b : une statistique concerne un et un seul joueur

joueurs & origine :
R03a : un joueur est né dans une seule ville et un seul état ou dans aucune ville et aucun état(manque de données)
R03b : Dans une ville comprise dans un état, zéro un ou plusieurs joueurs sont nés.

Par rapport à cette relation la,et notamment au fait que plusieurs villes possèdent le même nom,il faudrait peut-être avoir une double clé primaire sur la ville et l'état, je suis pas encore complètement sur de cette règle de gestion

Et par rapport aux règles de gestion je ne sais pas comment faire lorsque plusieurs tables sont liées entre elle,notamment pour la draft( évenement qui se déroule chaque année ou les équipes choisissent les unes après les autres les joueurs qui sortent des universités), ou il y a une relation entre les collèges, les joueurs,les équipes et la table draft qui contient l'historique de chaque draft

Voila je reposterais les règles de gestion plus tard,si vous voyez des choses à modifier n'hésitez pas à me le dire,

Merci beaucoup

[escartefigue]

Et donc pour les règles de gestion :
J'ai repris le modèle d'escartefigue et je l'ai modifié au niveau des collèges vu que dans les données que j'ai il n'y a qu'un seul collège par joueur

Attention, l'analyse de l'existant ne peut pas à elle seule constituer les règles de gestion.
Il est possible à un instant "t" que les joueurs présents dans votre base de données n'aient fréquenté au plus qu'un seul collège, mais ce qui compte, c'est de savoir si potentiellement ils ont pu en fréquenter plusieurs et si ces différents collèges qu'ils ont fréquentés ont un intérêt pour vous.
Que certains joueurs aient fréquenté plusieurs collèges, c'est plus que probable, reste à savoir si vous avez besoin de les connaitre et là, c'est à vos experts métier de vous le dire.

joueurs & statistiques :
R02a : un joueur est concerné par zéro (nouveau joueur) à plusieurs statistiques
R02b : une statistique concerne un et un seul joueur

l'association entre joueurs et stat_joueur ne doit pas mettre en jeu l'équipe, il faut une association binaire pour les statistiques du joueur et une autre association entre joueur et équipe

joueurs & origine :
R03a : un joueur est né dans une seule ville et un seul état ou dans aucune ville et aucun état(manque de données)
R03b : Dans une ville comprise dans un état, zéro un ou plusieurs joueurs sont nés.

OK pour le lieu de naissance inconnu, par contre il faut modéliser ainsi (notez les verbes à l'infinitif pour nommer les relations)
JOUEUR 0,1 --- naitre --- 0,n VILLE 1,1 --- localiser --- 1,n PAYS

Par rapport à cette relation la,et notamment au fait que plusieurs villes possèdent le même nom,il faudrait peut-être avoir une double clé primaire sur la ville et l'état, je suis pas encore complètement sur de cette règle de gestion

Le choix de l'identifiant primaire ne doit jamais porter sur une colonne sémantique. Donc surtout pas sur le libellé de la ville. Il faut utiliser un identifiant technique, dénué de sens et donc stable. Son type sera integer ou assimilé (small, int, bigint) car c'est un type très concis et très performant. Choisir une clef primaire asémantique est primordial. Une clef sémantique est susceptible d'être modifiée
. Par exemple la ville fusionne avec une autre, ou change de nom, ce n'est pas très fréquent mais ça arrive (cas de Châlon sur Marne, devenue Châlon en Champagne par exemple, ou de Saint Laurent des eaux qui a fusionné avec Nouan sur Loire pour former Saint Laurent Nouan). Ces changements provoquent, via les contraintes d'intégrité référentielles, des mises à jour en cascade dans les FK qui peuvent engendre des millions d'update !
Sans compter que les types char ou varchar nécessaires aux libellés sont beaucoup moins performants que de l'integer et bien plus encombrants.
Avec une PL technique, le changement de nom n'a pas d'impact sur la PK
En résumé, jamais de PK fonctionnelle, préférez une colonne technique attribuée par le SGBD

Et par rapport aux règles de gestion je ne sais pas comment faire lorsque plusieurs tables sont liées entre elle,notamment pour la draft( évenement qui se déroule chaque année ou les équipes choisissent les unes après les autres les joueurs qui sortent des universités), ou il y a une relation entre les collèges, les joueurs,les équipes et la table draft qui contient l'historique de chaque draft

Une association à 4 pattes comme votre "draft" est par nature une erreur de modélisation, il faut que vous décriviez ce que vous avez voulu modéliser dans ce quator infernal
De plus, une association et une entité-type qui portent le même nom ça ne va pas, utilisez des verbes à l'infinitif pour les associations et des substantifs pour les types d'entité, ça rend la compréhension plus aisée

[klatbah]

Attention, l'analyse de l'existant ne peut pas à elle seule constituer les règles de gestion.
Il est possible à un instant "t" que les joueurs présents dans votre base de données n'aient fréquenté au plus qu'un seul collège, mais ce qui compte, c'est de savoir si potentiellement ils ont pu en fréquenter plusieurs et si ces différents collèges qu'ils ont fréquentés ont un intérêt pour vous.
Que certains joueurs aient fréquenté plusieurs collèges, c'est plus que probable, reste à savoir si vous avez besoin de les connaitre et là, c'est à vos experts métier de vous le dire.

Pour moi et vu que c'est une base de données à usage personnele afin de m'entraîner à réaliser des mcd,mld et ensuites des requêtes SQL et spatiales avec Postgis, ca ne me pose pas de problème que les joueurs n'aient qu'un seul ou aucun college dans ma bdd.

l'association entre joueurs et stat_joueur ne doit pas mettre en jeu l'équipe, il faut une association binaire pour les statistiques du joueur et une autre association entre joueur et équipe

Quand tu dis une association binaire pour les statistiques du joueurs, tu veux dire qu'il faut donc créer une table avec l'id du joueur et l'id de la stat, et ensuite lier le joueur et l'équipe dans une autre table ? Je l'avais fait avec une relation entre joueurs, stats et équipes en pensant que les 3 étaient liés et c'est aussi ce que j'ai fait au niveau de la draft en pensant que joindre les entités concernées dans une relation mais je me rends compte que j'ai beaucoup à apprendre
Mais si on lie uniquement le joueur et l'équipe dans la même table, et que ce joueur a joué dans 6 équipes au cours de plusieurs années, ca ne posera pas de problème au moment de lier cette table à celle des statistiques ? En y réfléchissant, ca permettrait d'éviter les doublons et vu que chaque ligne de stats a une id unique cela devrait fonctionner.Dans le cas ou le joueur a joué dans 6 équipes,on aura donc pour ce joueur 6 entrées avec son identifiant et les identifiants des équipes et ensuite on liera cette table à celle des statistiques . j'ai bien compris ?
Et donc cela voudrait dire que dans la table des stats, l'identifiant des joueurs et des équipes seraient des clés étrangères ?
je vais essayer de faire ca, je pense que ca simplifiera pas mal de choses. Merci

OK pour le lieu de naissance inconnu, par contre il faut modéliser ainsi (notez les verbes à l'infinitif pour nommer les relations)
JOUEUR 0,1 --- naitre --- 0,n VILLE 1,1 --- localiser --- 1,n PAYS

Je vois ce que tu veux dire et ca tombe sous le sens,merci.

Le choix de l'identifiant primaire ne doit jamais porter sur une colonne sémantique. Donc surtout pas sur le libellé de la ville. Il faut utiliser un identifiant technique, dénué de sens et donc stable. Son type sera integer ou assimilé (small, int, bigint) car c'est un type très concis et très performant. Choisir une clef primaire asémantique est primordial. Une clef sémantique est susceptible d'être modifiée
. Par exemple la ville fusionne avec une autre, ou change de nom, ce n'est pas très fréquent mais ça arrive (cas de Châlon sur Marne, devenue Châlon en Champagne par exemple, ou de Saint Laurent des eaux qui a fusionné avec Nouan sur Loire pour former Saint Laurent Nouan). Ces changements provoquent, via les contraintes d'intégrité référentielles, des mises à jour en cascade dans les FK qui peuvent engendre des millions d'update !
Sans compter que les types char ou varchar nécessaires aux libellés sont beaucoup moins performants que de l'integer et bien plus encombrants.
Avec une PL technique, le changement de nom n'a pas d'impact sur la PK
En résumé, jamais de PK fonctionnelle, préférez une colonne technique attribuée par le SGBD

Bien compris,et sachant que plusieurs villes ont le même nom mais ont des états différents, est ce qu'un identifiant unique par ville suffit ou est-ce qu'il faut prendre l'id de l'état de la ville comme un autre identifiant afin d'éviter tout problème ?

Une association à 4 pattes comme votre "draft" est par nature une erreur de modélisation, il faut que vous décriviez ce que vous avez voulu modéliser dans ce quator infernal
De plus, une association et une entité-type qui portent le même nom ça ne va pas, utilisez des verbes à l'infinitif pour les associations et des substantifs pour les types d'entité, ça rend la compréhension plus aisée

C'est vrai qu'au moment ou je l'ai réalisé ca me semblait bizarre, et j'ai fait confiance au logiciel de création du MCD(JMerise) qui me disait que le MCD était correct.
Et donc pour la draft je suis parti du principe que pour avoir un choix de draft il y a des entités qui sont "indispensables" à savoir :
- Le joueur qui est choisi
- Le collège d'ou il vient OU si il ne vient pas d'un collège de quel club (européen généralement,ou chinois c'est plus rare ) il vient,mais j'avais pas envie de compliquer encore plus le MCD
- L'équipe qui le choisit
- L'année ou il est choisi
- Le pick (qui va de 1 à 60 ) avec lequel il a été choisi

Donc j'en suis arrivé à penser que pour l'entité draft il me fallait :
- L'identifiant du joueur
- L'identifiant du collège ou il a joué
- L'identifiant de l'équipe qui le choisit
- L'identifiant de la draft pour savoir en quelle année il a été choisi

A noter que dans la table draft il y a les statistiques des joueurs dans leur college,mais je pensais que ca allait faire une "boucle" entre joueurs,collège,stats_college(la table que j'aurais créé en récupérant les statistiques de l'entité draft ) du coup je l'ai laissé dans l'entité draft

En faisant ainsi je pensais pouvoir répondre à des requêtes telles que :
- Quelle est l'équipe qui a choisi le plus souvent avec le premier choix et quels sont ces joueurs ?
- Quel collège a le plus de joueurs sélectionné en premier choix et quels sont ces joueurs ?
- Quel ville ou quel état a le plus de joueurs originaire de cette ville état sélectionné lors de la draft ?

Donc du tout comment faire pour régler le cas de ce quatuor infernal ?
J'espère que tu comprendras .
Merci encore

[escartefigue]

Pour moi et vu que c'est une base de données à usage personnele afin de m'entraîner à réaliser des mcd,mld et ensuites des requêtes SQL et spatiales avec Postgis, ca ne me pose pas de problème que les joueurs n'aient qu'un seul ou aucun college dans ma bdd.

OK si c'est à titre didactique pas de problème, considérons que la règle de gestion est validée

Quand tu dis une association binaire pour les statistiques du joueurs, tu veux dire qu'il faut donc créer une table avec l'id du joueur et l'id de la stat, et ensuite lier le joueur et l'équipe dans une autre table ? Je l'avais fait avec une relation entre joueurs, stats et équipes en pensant que les 3 étaient liés et c'est aussi ce que j'ai fait au niveau de la draft en pensant que joindre les entités concernées dans une relation mais je me rends compte que j'ai beaucoup à apprendre

Non, ce n'est pas ce que je dis, car au stade conceptuel la notion de table n'existe pas.
Ce que je dis c'est qu'il faut écrire les règles de gestion puis les schématiser sous forme d'un MCD en fonction de ce qui se passe réellement dans l'univers que l'on décrit.
Dans ce cadre, les statistiques individuelles d'un joueur n'ont pas de lien avec l'appartenance de ce joueur à telle ou telle équipe, il faut donc seulement mettre en relation l'entité-type (et non la table) "joueur" avec l'entité-type stat_joueur. De la même façon, pour les statistiques de telle ou telle équipe on se fiche complètement des joueurs qui composent cette équipe, il faut là encore modéliser une relation entre l'entité-type "équipe" et l'entité-type "stat_equipe". Enfin, l'appartenance d'un joueur à telle équipe pour telle période est une autre relation à modéliser elle aussi, à date bien sur.

Bien compris,et sachant que plusieurs villes ont le même nom mais ont des états différents, est ce qu'un identifiant unique par ville suffit ou est-ce qu'il faut prendre l'id de l'état de la ville comme un autre identifiant afin d'éviter tout problème ?

Puisque le nom n'est pas l'identifiant primaire (pour rappel : ne jamais utiliser d'identifiant fonctionnel comme identifiant primaire), la question ne se pose pas en ces termes.
Par contre, fonctionnellement, lors d'une recherche par nom, il faudra pouvoir distinguer les villes homonymes et l'appartenance à un pays ne suffira peut-être pas, le même nom peut être présent plusieurs fois dans un même pays. Selon le cas, l'appartenance à une région, un district ou la géolocalisation pourraient être des critères discriminants.

Et donc pour la draft je suis parti du principe que pour avoir un choix de draft il y a des entités qui sont "indispensables" à savoir :

Avant de partir de tel ou tel principe, il faut expliquer ce qu'est "la draft", je doute qu'il s'agisse d'un individu au sens conceptuel (les "individus" sont les joueurs, les statistiques, les équipes...)
Quoi qu'il en soit, au niveau du MCD, un identifiant primaire ne doit apparaître que dans une seule "case" une et une seule entité-type et jamais dans une relation.

[roblu]

Bonjour, je sais que ce sujet a déjà 2 ans (ce n'est pas si vieux que ça, allez...) mais j'ai une question pour l'auteur de celui-ci. Où as-tu trouvé tes données à rentrer dans ta base ?

Merci d'avance !

[escartefigue]

L'initiateur de ce sujet n'a plus été actif depuis deux ans...
Par contre, en quelques clics sur la toile avec les mots clefs "nba statistics download", on trouve plusieurs liens.

Par exemple ici : https://www.nbastuffer.com/player-stats/