Discussion :

[Sinedb]

Bonjour à tous,

Dans le cadre d'une équipe sportive, j'aimerai essayer de stocker toutes les informations via une base de données.
Pour l'heure, et le systeme fonctionne très bien, j'ai mes différentes informations sur des feuilles de calcul excel que j'exploite via power BI pour extraire divers rapports (fiches joueurs, statistiques, etc)
Inconvénient, pour lire mes rapports, mes compères doivent avoir une licence ......
Par ailleurs, je crois que vous conviendrez tous que ce n'est pas le but premier d'excel .....

Je me sens donc motivé à passer à l'étape supérieure pour stocker et exploiter toutes ces données. Cependant, des la mise en œuvre, je me heure à un écueil .....

La première table, pas de problème:
Effectif, constitué de ce genre de champs: [Id_joueur] [nom] [prenom] [date de naissance] [etc] [etc] [etc] dont de nombreuses pièces jointes

D'autres tables avec différents types de test.
Par exemple : Vitesse [date_test] [nom] [prenom] [5m] [10m] [20m] . Ici, je suppose que je dois mettre en clé primaire le trio date, nom, prénom ? (nous avons des frères dans nos effectifs) ?

Mon problème vient de ma table matches.
Sur mon fichier excel, c'est simple, j'ai une ligne par joueur pour chacun des matches
[date match] [catégorie] [adversaire] [resultat] [nom] [note] [stat1] [stat2] [stat3] ][etc etc etc] [commentaire du coach sur le match] la clé primaire devrait donc etre sur les champs date, categorie, adversaire, nom (et il faudrait que j'ajoute prénom si les 2 freres jouent ensembles)
Cela implique donc que la même information est répétée puisqu'elle est commune a tous les joueurs (les scores, l'adversaire, le commentaire du coach sur la prestation de l'équipe, etc etc)
Je suppose que ce n'est pas optimum ....

Arrivez vous a visualiser mes explications peut être pas très claires ?
Que pourriez vous me conseiller comme procédure ? Et peut etre un SGBD ?

Merci

[pier.antoine]

Bonjour

L'utilisation d'un SGBD relationnel vous permettra de travailler au mieux.

Les spécialistes conseillent toujours de travailler en 3 étapes :
- établir les règles de gestion ;
- établir le MCD (modèle conceptuel des données)
- établir le script de création des tables et autres.

Un simple éditeur de texte doit permettre d'établir les règles de gestion.

Personnellement, j'utilise Looping pour établir le MCD. Plutôt simple, il permet de générer facilement les scripts de création de la base.
En dehors de ces aspects très techniques et concrets, je suggère de lire quelques tuto sur la conception de base, de tables et de relations entre les tables..

Vite fait, comme ça je dirai :
- 1 table joueur (état civil)
- 1 table "adhésion" (début, fin...)
- 1 table match (date, lieu, équipes...)
- 1 table joueur - match (référence à 1 joueur, référence à 1 maths, stat).

Encore une fois, je ne suis pas un grand spécialiste, donc prendre mes informations avec des pincettes.

Bon courage.

[fsmrel]

Bonjour Sinedb

Je me sens donc motivé à passer à l'étape supérieure

Il s’agit donc de mettre en oeuvre une base de données. Une base de données ça se construit comme une maison. Avant de construire une maison, il faut d’abord en établir les plans, ce qui est du ressort de l’architecte. Il en va de même pour la base de données, il va falloir commencer par modéliser votre domaine, sinon ça sera l’échec.

Ne soyez pas décontenancé par mes propos, mais construire un MCD (modèle conceptuel des données) est l’étape incontournable pour produire une base de données digne de ce nom. Cela n’est pas très compliqué, mais ça exige une très grande rigueur et un peu de patience, du reste on se pique assez vite au jeu. Pour l’apprentissage de la chose je vous recommande vivement l’utilisation de Looping et de faire l’acquisition de l’ouvrage qui l’accompagne, Modélisation Conceptuelle de Données, et qui vous guide pas à pas dans l’apprentissage de la modélisation.

On peut évidemment répondre à toutes vos questions concernant l’élaboration du MCD, et sachez qu’une fois celui-ci obtenu, Looping vous produira le code SQL correct (les tables) que vous attendez de vos voeux.

[fsmrel]

Sinedb,

Je vous invite à voir la discussion ouverte par Vincent (aras-vbo) qui a suivi les conseils d’escartefigue en établissant les règles de gestion, une fois défini le dictionnaire des données (ça peut être perçu comme fastidieux, mais ça se révèle ô combien utile par la suite).

[Sinedb]

Merci à tous, je me penche la dessus, et je reviens proposer quelque chose, voir si j'avance dans la bonne direction

[Sinedb]

Concernant les règles de gestion, telles que suggérées par Fsmrel, et le dictionnaire de données, j'avoue, probablement par excès de confiance néfaste, ne pas être passé par cette étape. Je crois être loin de la complexité du projet de Aras-vbo.
J'ai donc essayé via looping (magnifique outil ceci dit) de créer le schéma.
Venant de mes fichiers excel, cela me pertube de ne pas remettre les noms et prénoms des joueurs dans dans les différents tableaux, et cela m'intrigue de voir comment seront renseignées les données. Ceci dit, j'en suis loin ...


Si je comprends bien le passage au modèle relationnel, j'obtiens quelque chose du genre:
Matchjoué (id_match, numero licence, Poste, temps de jeu, note, distance parcourue, commentaires)
Evaluation (numero licence, Date_evaluation, evaluation athletique, evaluation technique, evaluation mentale, evaluation tactique)
Mesure (numero licence, Date teste mesure, taille, poids, mg)
Vitesse (numero licence, date test vitesse, 5m, 10m, 20m, 30m, 40m)

Je suis sur la bonne voie ?

[aras-vbo]

Sinedb,

Même si le dictionnaire de données peut sembler superflu, il permet de lister efficacement les différentes rubriques à stocker dans la base de données. Paprick (Patrick Bergougnoux, l'auteur de Looping) suggère de réaliser une sorte d'interview qui décrit le fonctionnement de votre domaine d'étude, ici le suivi des performances des joueurs de vos équipes.
A l'aide de cette interview et du contenu de votre outil existant, vous constituerez ce dictionnaire de données. Chez vous, ces rubriques seront par exemple le numéro de licence, la date du test, la taille, le poids, etc. Une fois cette liste établie, il devient bien plus logique de les assigner à des élements précis : la taille et le poids seront sans doute des attributs d'athlètes (même si un athlète peut avoir plusieurs tailles et plusieurs poids tout le long de sa carrière).
Je pense qu'il ne faut pas passer à côté de ce listing exhaustif, en ayant toujours en tête : que dois-je enregistrer comme donnée ?

Les règles de gestion sont encore plus importantes car elles vont structurer les entités et leurs relations. Elles décrivent le fonctionnement de votre système, et elles vont le structurer, à partir du dictionnaire de données et de vos entités. Par exemple, un sportif possède une ou plusieurs tailles (en fonction de la date). Un sportif possède une (ou plusieurs ?) licences. Un sportif passe un ou plusieurs tests au cours de sa saison. Un sportif fait un ou plusieurs matchs. Un test comprend une ou plusieurs procédures (évaluation athlétique, tests de vitesse, etc.). Un sportif fait l'objet de zéro ou plusieurs évaluations dans sa saison, etc.

Le MCD (modèle conceptuel des données), le schéma, viendra après et vous verrez qu'il découlera plus logiquement de votre dictionnaire et de vos règles de gestion.

Vincent

[fsmrel]

Bravo Vincent !

20/20 et en cotant vache !

Sinedb, bel effort de votre part avec votre MCD, mais suivez bien Vincent. Difficile de juger en l’absence des règles de gestion.

[Sinedb]

Le problème de l'interview, c'est qu'elle consisterai à m'interroger moi-même
Ma base ne me semble pas si complexe, j'ai tous les attributs à faire apparaître dans mon fichier excel. De ce côté là, je suis paré (je crois), cela fait 4 ans que j'enregistre et stocke les attributs. Je n'en ai mis que quelques uns dans ma proposition, car les autres ne modifient en rien la structure (exemple, pour l'analyse de match, je vais avoir la vitesse max, le nombre d'accélérations, etc etc)
J'ai justement identifié ceux à ne plus conservé puisque le fruits de calculs (exemple, dans mon fichier excel, j'avais une colonne distance / minute, qui si je ne me trompe pas est inutile à stocker puisqu'elle peut être calculée en divisant la distance parcourue par le temps de jeu, eux-mêmes attributs).


Idem pour les règles de gestion, si je reprends tes exemples, qui à eux seuls couvrent quasiment toute la problématique.

Le numéro de licence est unique
Un joueur peut joueur plusieurs matches ou aucun
Un joueur peut effectuer plusieurs tests ou aucun (s'il est absent lors du test par exemple)
Les tests sont d'un seul type et réalisés à des dates différentes (on ne teste pas la vitesse, le jour où on teste l'endurance). C'est la raison pour laquelle j'ai distingué les tables. Peut-être pointes tu cet élément car tu suggères de ne faire qu'une table pour l'ensemble des tests ? C'est effectivement une possibilité. Auquel cas, on se retrouvera fréquemment avec du null puisque le jour du test de vitesse, j'aurai tous les autres attributs vides. Quelle est la bonne pratique ?
La taille, le poids, la MG varient, c'est un public jeune et il est intéressant de garder la trace de l'évolution.

Mais je vais m'y essayer voir si je comprends la logique, mais j'ai l'impression de rater quelque chose ....

Joueur
RJ1: Numéro de licence unique
RJ2: Un joueur peut jouer plusieurs matches ou aucun
RJ3: Un joueur peut effectuer plusieurs tests de vitesse ou aucun
RJ4 :Un joueur peut être mesuré plusieurs fois ou jamais

Match
RM1: Un match est joué par plusieurs joueurs
RM2: Un match génère un compte rendu par joueur sur la feuille de match

Compte rendu match
RC1: un compte rendu par joueur et par match


Test (peut être démultiplié selon le nombre de tests, le principe est toujours le même)
RT1: Les tests concernent plusieurs joueurs
RT2: un joueur peut n'avoir fait aucun test ou les avoir fait plusieurs fois


La finalité est de sortir des fiches joueurs avec des moyennes, la retranscription des commentaires du coach par match, etc etc.
Je peux poster un exemple de ce que j'obtiens via PowerBI au besoin

[escartefigue]

Bonjour Sinedb et bienvenue dans ce forum

Concernant les règles de gestion, pensez à justifier chaque "patte" d'association.

Par exemple, pour le n° de licence, on peut écrire (règles à confirmer bien entendu) :

RJ01 : un joueur possède un et un seul numéro de licence
RJ02 : un numéro de licence est possédé par un et un seul joueur

Ensuite, le numéro de licence est attribué par un organisme extérieur, probablement la fédération française de football, ce faisant, sa longueur ou son type peuvent changer à tout moment. Aussi, il est préférable de ne pas choisir le numéro de licence comme identifiant, conservez le comme simple attribut et choisissez un chrono technique dénué de sens et donc stable comme identifiant. Pour ce besoin, un identifiant attribué par le SGBD sera parfait : il sera stable, concis et performant et vous n'aurez même pas à vous en préoccuper, c'est le SGBD qui fera le boulot .

Enfin, pensez à expliquer les termes utilisés et supprimez les synonymes.

Par exemple, vous parlez dans RM2 de "feuille de match" et vous fournissez avec RC1 une règle de gestion relative au "compte rendu de match"
S'il s'agit de la même chose, il faut utiliser toujours le même terme, ça évite les confusions.
Sinon, expliquez ce que sont l'un et l'autre et fournissez les règles de gestion de chacun

Il y aura d'autres choses à dire concernant votre 1er MCD, notamment en ce qui concerne les différentes mensurations et relevés de performances, mais chaque chose en son temps, priorité aux règles de gestion

J'ai retrouvé un sujet qui concerne des rencontres de football, il pourra sans doute vous éclairer, voyez ICI

[fsmrel]

Bonjour,

il est préférable de ne pas choisir le numéro de licence comme identifiant.

Exact ! Mais dans Looping le déclarer UNIQUE (identifiant alternatif).

[pier.antoine]

Hello tout le monde

Règles de gestion importantes mais pas toujours facile.

Exemple avec le numéro de licence.
Je reprends la règle RJ01 : un joueur possède un et un seul numéro de licence
mais je préciserai : à un moment donné !!
Imaginons le joueur qui ne prend pas de licence pendant 2 ans.
A son retour, il me semble qu'il aura un nouveau numéro de licence.


De façon générale, règle de gestion et MCD permettent d'avoir une vue globale de toutes les activités, de toutes les relations et parfois de comprendre qu'une situation statistiquement la plus présente, n'est qu'un cas particulier, malgré tout.

Exemple rapide :
Les candidats au bac général sont inscrits et gérés par la même académie dans une base Bac.
Les candidats au BTS sont inscrits dans une académie et gérés par la même académie ou parfois par une autre académie dans une base BTS.
Or, un peu de hauteur aurait permis de gérer les deux examens dans une base unique en insérant les notions d'académie d'inscription et d'académie de gestion : dans le cas du bac, l'académie d'inscription est la même que l'académie de gestion.

Bonne soirée

[Sinedb]

Bonjour à tous.

Vous êtes d'un dévouement remarquable ...... Si l'un de vous est en Aquitaine, je peux lui offrir des places

Sur les points relevés:
- Les licences sont attribuées à vie, même en cas d'arrêt puis de reprise d'activité (selon mes informations) sauf passage au statut professionnel ou joueur devenant dirigeant, mais en ce cas, je ne suivrai plus le garçon. Elles sont composées de 10 chiffres (ce qui laisse de la marge avant une évolution). Ceci dit, j'entends vos remarques, d'autant plus que cela ne change pas grand chose de choisir un numéro auto-incrémenté
- J'ai regardé l'autre projet. Nos optiques sont différents. Dans mon besoin, le joueur est central. Le but est de produire des fiches individuelles joueurs ou bien des stats d'équipe
Ceci dit, j'ai une question. Je vois qu'il fait une table "saison". Quel intérêt ? J'avais cru comprendre qu'il ne fallait pas surcharger les bases de données avec ce qui pouvait être calculé. Et dans mon outil actuel de visualisation (Power Bi), la saison est calculée en fonction de la date du match. Faut il donc à ce point décomposer la BDD ??
- Effectivement, feuille de match / rapport de match, je n'arrive pas à trouver un terme adéquat. Je vais donc opter pour
- J'ai été naze en mettant comme clé des tests la date. Evidemment, un test est effectué par plusieurs joueurs le même jour, mais chaque joueur ne le fait qu'une fois ...

Je recommence donc:

Joueur
RJ1: Identifiant auto-incrémenté
RJ2: Un joueur peut jouer plusieurs matches ou aucun
RJ3: Un joueur peut effectuer plusieurs tests de vitesse ou aucun
RJ4 :Un joueur peut être mesuré plusieurs fois ou jamais

Test (peut être démultiplié selon le nombre de tests, le principe est toujours le même)
RT1: identifiant construit par l'association d'une date de test et de l'identifiant joueur
RT1: Les tests concernent plusieurs joueurs
RT2: un joueur peut n'avoir fait aucun test ou les avoir fait plusieurs fois

Evaluation
RE1: une évaluation ne concerne qu'un joueur
RE2: un joueur peut être évalué plusieurs fois


Match
RM1: Identifiant auto incrémenté (ou bien une association date/catergorie/adversaire) ?
RM1: Un match est joué par plusieurs joueurs
RM2: Un match génère une statistique de match par joueur participant

fiche statistique
RC1: Chaque joueur participant (qu'il joue ou nom) engendre une fiche statistique

[fsmrel]

Bonsoir Sinedb

Ça sert bien les règles de gestion...

RE1: une évaluation ne concerne qu'un joueur
RE2: un joueur peut être évalué plusieurs fois.

L’évaluation est donc au joueur ce que la ligne de commande est à la commande, elle en dépend viscéralement et pas d’une autre, c’est à la vie, à la mort. On dit qu’elle est une entité-type faible.

Dans ce cas-là, on utilise l’identification relative, ce qui techniquement conduit (avec Looping) à cocher la case « Identifiant relatif » pour la patte d’association connectant l’entité-type Evaluation et l’association Evaluer. L’identification relative est notée « 1,1(R) ».

Pour les mesures et les tests, même principe.




En regardant le code SQL généré, vous verrez que tout cela se tient.

Vous noterez que le dernier MCD que vous avez proposé tient plus du MLD (modèle logique des données).

Tant qu’à faire, mettez en oeuvre une entité-type faible pour les pièces jointes, car un jour vous éprouverez peut-être le besoin d’aller au-delà de la limite que vous avez fixée...

[fsmrel]

J’ai oublié : pour mieux comprendre le bien fondé de l'identification relative, voyez la discussion Définition 'lien identifiant'.

J'espère que knoxville a réussi son examen

[escartefigue]

J'abonde dans le sens des propos de Fsmrel

Par ailleurs, au niveau conceptuel (le MCD), nommer les types entités tab_ est inadéquat, il n'y pas de tables à ce stade, seulement des types d'entités (ou entités-types) et d'associations.

Egalement, au niveau conceptuel, un identifiant ne doit apparaitre qu'à un seul endroit. Par exemple, l'identifiant du joueur ne doit être présent que dans l'entité-type joueur, il n'a rien à faire dans les entité-type [vitesse] et [morphologie].
C'est au niveau tabulaire (MLD et MPD), que les identifiants devenus clefs primaires migreront dans certaines autres tables pour devenir des clefs étrangères et parfois (cas des tables associatives ou de l'identification relative) participer à la clef primaire.

Concernant l'entité-type [vitesse]
Si on ne mesure que des vitesses et toujours les performances sur 5, 10, 30 et 40 m, alors votre modèle peut être valide, quoi que peu évolutif.
Mais si pour certains joueurs, on ne mesure que la vitesse sur 10m, pour d'autres, la vitesse sur 100m ou le saut en hauteur, ou encore les performances à la nage ou que sais-je encore, ce modèle ne convient pas, il faut en ce cas modéliser comme suit :

[JOUEUR] 0,n --- (mesurer) --- 1,1(R) [PERFORMANCE] 1,1 --- (typer) --- 0,n[TYPE_PERFORMANCE]

Même remarque concernant la morphologie.
De plus, les attributs de [MORPHOLOGIE] sont de type TEXT, ce faisant, il s'agit de commentaires libres, non normés, peu propices à la comparaison des joueurs.
Je doute que ce soit ce qui est souhaité. Besoin à éclaircir

[aras-vbo]

Bonjour,

Etant données la quantité et la variabilité des données à stocker (passes décisives, tailles et poids des joueurs, nombre d'accélérations sur un match, etc.), d'autant plus si elles sont liées à une temporalité, je serai d'avis de partir sur une structure de stockage de type EAV (Entity-Attribute-Value). Les entités seraient les matchs, les tests, etc. auxquelles seraient reliées les tuples (attribut, valeur) variables.
Le gros avantage du modèle EAV est de réduire fortement les valeurs NULL dans les tables et de permettre d'ajouter très facilement des attributs sans avoir à modifier la structure de la base. Si vous souhaitez ajouter plus tard un attribut "Quantité de boisson bue" lors d'un match, vous n'avez pas à modifier la structure de la table et à remplir les valeurs manquantes (lors des matchs passés) par des NULL.

Vincent

[Sinedb]

Vous l'aurez compris, je suis vraiment néophyte dans cet univers, et je viens juste de réaliser qu'il y avait MCD, MLD ...

Je vais essayer de reprendre vos interventions de façon chronologique.

@fmsrel
Je suis allé jeté un œil à cette histoire d'entité faible. C'est cohérent. Knoxville aurait pu revenir vous donner le résultat de son examen. Mais qui sait, il est peut être aujourd'hui à la tête d'une Fintech grâce à vous ...
Mais cela peut aussi s'appliquer à la fiche statistique non ?

D'ailleurs, je me demande si je n'ai pas pris cette histoire de fiche statistique dans le mauvais sens.
Je reformule cette partieen italique ce que j'ai modifié)
Match
RM1: Identifiant auto incrémenté (ou bien une association date/catergorie/adversaire) ?
RM1: Un match est joué par plusieurs joueurs
RM2: Un match génère une fiche statistique par joueur participant

fiche statistique
RFC1: Une fiche statistique correspond à UN joueur
RFC2: un joueur possède autant de fiches statistiques de que matches auxquels il a participé

Je prends note l'option de mettre les pièces jointes dans une autre relation. Par contre, je n'ai aucune idée de la clé primaire que je pourrais y mettre. Puis je m'en passer ?
Pièces jointes
RPJ1 : Il peut n'y avoir besoin d'aucune pièce jointe ou bien d'en stocker plusieurs (docs administratifs probablement)


@escartefigue
Je pense que je les ai nommé tab, car je n'avais pas conscience de la différence entre le modèle conceptuel et le modèle logique. Je crois saisir maintenant. (enfin à peu près)
Je suppose que j'essayais de faire un MLD ..

Les tests de vitesse ne varieront pas, il s'agit de jeunes footballeurs, aucune raison de faire évoluer le protocole test (le 30 et 40 mètres sont déjà limites superflus).
Ces tests sont de toute façon rare, une à 2 fois par an maximum ....
Pour ta remarque sur Morphologie, je pense que tu as confondu avec Evaluation. Les évaluations sont en effet des descriptions textuelles (il y a d'autres critères, mais je n'ai pas tout mis pour éviter de surcharger)
Mon schéma pour la morphologie ne comprenait pas de texte, du moins, le second.

@Aras_vbo
Je pensais etre sur la bonne voie, mais la, tu m'as perdu
Je suis allé jeter un oeil ici du coup: https://shnaos.tech/leav-lalternativ...nnees-rigides/
Ceci dit, par rapport aux avantages que tu cites, les attributs ne seront pas variables (normalement). Nous extrayons toujours les mêmes données des matches.
Jusqu'au jour ou bien sur ...

Voilà donc la dernière mouture. Approche t on du but ?

[Paprick]

Bonsoir,
Tout cela me parait pas mal du tout !
Il y a cependant un point que je ne comprends pas : pourquoi la classe "Piece jointe" comprend 6 rubriques ?
De plus, l'identifiant relatif ne permet pas d'assurer l'unicité : en effet, un joueur peut avoir plusieurs pièces jointes (0,n) et Id_Joueur ne sera donc pas unique dans "Piece jointe".
Par conséquent, je pense que "Piece jointe" doit avoir les rubriques suivantes : Num_Piece (qui viendra compléter l'identifiant relatif Id_Joueur) et "Lien" (qui permettra d'indiquer la localisation de la pièce en question).

[fsmrel]

pourquoi la classe "Piece jointe" comprend 6 rubriques ?

Notre ami Sinedb avait mis les pièces jointes en tant qu’attributs de Fiche_Joueur, un attribut par pj, d’où structure figée. Je lui ai conseillé d’en faire une entité-type, mais il a consciencieusement recopié tous ces attributs dans la nouvelle entité-type.

@Sinedb,
le but de la manip n’et pas d’horizontaliser N pièces jointes, mais de les verticaliser, c’est-à-dire de pouvoir avoir autant de pièces jointes que vous voudrez, une ligne par pj. A cet effet, comme dit Paprick, la structure suivante suffit :



Une fiche peut contenir 0, 1, ..., N pièces...