Database
 sql >> Base de données >  >> RDS >> Database

Qu'est-ce que les Jeux olympiques, les matchs de football de l'UEFA Euro 2016 et les bases de données ont en commun ?

En entendant ce que je fais, les gens ont tendance à me poser la même question :Pouvez-vous développer un système qui prédit les résultats des matchs de football ? Ou les médailles olympiques ? Personnellement, je ne fais pas beaucoup confiance aux prédictions. Pourtant, si nous disposions d'une grande quantité de données historiques et d'indicateurs pertinents, nous pourrions certainement concevoir un système pour nous aider à formuler des hypothèses plus précises. Dans cet article, nous allons considérer un modèle qui peut stocker les résultats des matchs et des tournois.

Ce modèle est principalement axé sur les matchs, les statistiques et les résultats du football européen (soccer), mais il pourrait facilement être modifié pour s'adapter à de nombreux autres sports. Ma principale motivation pour cet article était les deux grands événements de football de cette année :le championnat de l'UEFA Euro 2016 qui vient de se dérouler et les Jeux olympiques d'été de 2016 qui se déroulent en ce moment.

Que savons-nous avant le début du tournoi ?

Avant le début du tournoi, nous savons presque tout à son sujet, sauf le plus important :qui va gagner. Énonçons brièvement exactement ce que nous savons déjà :

  • Les dates de début et de fin du tournoi
  • Les lieux où se dérouleront les matchs
  • L'heure exacte à laquelle les matchs commenceront
  • Quelles sont les équipes qualifiées pour le tournoi
  • Les joueurs de chacune de ces équipes
  • Les performances passées de chaque joueur et sa forme actuelle

Quels détails de correspondance voulons-nous stocker ?

Les tournois se composent de plusieurs matchs. Avant de stocker les détails du match, nous devons :

  • Liez chaque match au tournoi
  • Enregistrer l'étape du tournoi au moment où le match a été joué (par exemple, phase de groupes, demi-finales)

Nous devons également stocker les détails des matchs simples, notamment :

  • Les équipes impliquées dans le match
  • Compositions de départ et remplacements
  • Événements de match (dans le football, ce sont :but, penalty, faute, carton jaune, etc.)
  • Note finale
  • Actions des joueurs pendant le match

Nous utiliserons ces données pour capturer tous les événements de match importants. Comparer les performances d'un joueur avant et pendant le match peut conduire à certaines conclusions. Nous ne serions peut-être pas en mesure de prédire les résultats finaux de leurs performances (c'est-à-dire une victoire ou une défaite), mais les statistiques pourraient certainement nous aider à faire des hypothèses avec un certain degré de fiabilité.

Présentation du modèle




Le modèle est divisé en quatre domaines principaux :

  • Tournament details
  • Match details
  • Events
  • Indicators and Performance

Les tableaux en dehors de ces zones sont des dictionnaires (sport , phase , position ), catalogues (sport_event , team , player ) et une seule relation plusieurs-à-plusieurs (plays ).

Nous décrirons d'abord les tableaux non catégorisés, puis nous examinerons de près chaque domaine.

Les tableaux non classés

Ces tableaux sont importants car les tableaux des quatre domaines les utilisent comme dictionnaires ou catalogues.

Le sport Le tableau répertorie tous les sports que nous stockerons dans notre base de données. Nous n'aurons probablement qu'un seul sport ici, le football masculin, mais ce tableau nous donne la possibilité d'ajouter des sports similaires (par exemple, le football féminin) si nécessaire.

Dans le sport_event table, nous stockerons les événements liés à nos sports. Un exemple serait les "Jeux olympiques de 2016".

La phase table est un dictionnaire qui contient toutes les étapes possibles du tournoi. Il contient des valeurs telles que "phase de groupe" , « huitièmes de finale » , "quarts de finale" , "demi-finales" , "finale" .

L'équipe team table est, comme vous le devinez, une simple liste de toutes les équipes. Les valeurs possibles sont "Croatie" , "Pologne" , "États-Unis" etc. Si nous utilisons la base de données pour stocker des informations sur les compétitions de clubs ou de ligues, nous aurions également des valeurs telles que "Barcelone" , "Réal Madrid" , "Bayern" , "Manchester United" etc.

Dans le player table, nous stockerons les enregistrements de tous les joueurs appartenant aux équipes concernées.

Le plays table est notre seule relation plusieurs-à-plusieurs, et elle relie les joueurs et les équipes. Un joueur peut appartenir à plusieurs équipes à la fois (par exemple l'équipe nationale et un club), mais lors d'un tournoi, il jouera évidemment pour une seule équipe.

Enfin, nous avons la position table. Ce dictionnaire simple stockera une liste de tous les postes requis. Dans le football, il s'agit notamment du gardien de but, du demi-centre, de l'attaquant, etc.

Détails du tournoi

Remarque : Si vous souhaitez uniquement stocker les résultats des matchs simples, vous n'avez pas besoin d'utiliser cette section.

Un tournoi se compose de plus d'un match; l'UEFA Euro 2016 et les événements de football des Jeux olympiques d'été de 2016 sont des tournois. Comme nous l'avons déjà dit, nous pouvons stocker un seul match dans notre base de données, mais nous pouvons également associer des matchs à leurs tournois pertinents. Les tableaux de la section Tournoi sont :

  • tournament – Il contient toutes les données de base du tournoi :le sport, la date de début, la date de fin, etc. Nous devons également stocker le nom du tournoi et une description de l'endroit où il se déroule. Le sport_event_id L'attribut est facultatif, car un tournoi n'a pas besoin d'être associé à un événement plus important (comme les Jeux olympiques).
  • group – Ceci répertorie tous les groupes de ce tournoi. L'UEFA Euro 2016 comptait six groupes, de A à F.
  • participant – Ce sont les équipes qui jouent dans le tournoi ; chaque participant peut être affecté à un groupe. La plupart des tournois commencent par une phase de groupes et se poursuivent ensuite par une phase à élimination directe (par exemple, l'UEFA Euro, la Coupe du monde de l'UEFA, le football olympique). Certains tournois n'auront qu'une phase de groupes (par exemple, les ligues nationales), tandis que d'autres n'auront qu'une phase à élimination directe (par exemple, les coupes nationales).
  • in_team – Cette table fournit une relation plusieurs-à-plusieurs qui stocke des informations sur les joueurs inscrits à ce tournoi et leurs positions attendues.
  • tournament_schedule – À mon avis, c'est le tableau le plus intéressant de cette section. La liste de tous les jeux joués pendant ce tournoi est stockée ici. Le tournament_id l'attribut indique à quel tournoi chaque match appartient, et le phase_id L'attribut définit la phase pendant laquelle le match aura lieu. Nous stockerons également le lieu du match et l'heure à laquelle il commence. Les deux participants seront décrits par des champs de texte. À la fin de la phase de groupes, nous connaîtrons tous les affrontements pour le tour éliminatoire. Par exemple, au début de l'UEFA Euro 2016, nous savions que le vainqueur du groupe E (1E) jouera contre le deuxième du groupe D (2D). Après les trois tours de la phase de groupes, cette paire était l'Italie contre l'Espagne.

Détails du match

Les Match details La zone est utilisée pour stocker des données pour des correspondances simples. Nous utiliserons deux tables :

  • match - Cela contient tous les détails sur un seul match; ce match peut être lié à un tournoi, mais il peut aussi s'agir d'un seul match. Donc le tournament_schedule_id l'attribut est facultatif, et nous stockerons le sport_id , start_time et location attributs à nouveau ici. Si le match fait partie d'un tournoi, alors tournament_schedule_id se verra attribuer une valeur. L'team_1_id et team_2_id les attributs sont des références aux équipes impliquées dans le match. Le goals_team_1 et goals_team_2 les attributs contiennent le résultat de la correspondance. Ils sont obligatoires et doivent avoir "0" comme valeur par défaut pour les deux.
  • in_match – Ce tableau est une liste de tous les joueurs inscrits pour ce match; les joueurs qui ne participent pas auront un NULL dans le started_at attribut, tandis que les joueurs qui sont entrés en remplacement auront started_at> 0 . Si un joueur a été remplacé, il aura un ended_at attribut qui correspond à started_at attribut du joueur qui les a remplacés. Si le joueur est resté pendant tout le match, son ended_at l'attribut aura la même valeur que le end_time attribut.

Événements de match

Cette section est destinée à stocker tous les détails ou événements qui se sont produits pendant le jeu. Et les tables sont :

  • event – Il s'agit d'un dictionnaire qui répertorie tous les événements que nous souhaitons stocker. Dans le football, ce sont des valeurs comme "faute commise" , "faute subie" , "carton jaune" , "carton rouge" , "coup franc" , "pénalité" , "objectif" , "hors-jeu" , "remplacement" , "joueur expulsé du match" .
  • match_event – Cela concerne les événements avec le match. Nous stockerons le event_time ainsi que des informations sur le joueur liées à cet événement (in_match_id ).
  • related_event – C'est ce qui rassemble les informations sur l'événement. Pour expliquer, regardons un exemple où le joueur A commet une faute sur le joueur B. Nous allons insérer un enregistrement dans le match_event tableau qui indique que le joueur A a commis une faute et un autre qui indique que le joueur B a subi une faute. Nous ajouterons également un enregistrement au related_event table, où la « faute commise » sera le parent et la « faute subie » sera l'enfant. Nous enregistrerons également les résultats de la faute :un carton jaune, un coup franc ou un penalty, et peut-être un but.

Indicateurs et performances

Cette section devrait nous aider à analyser les joueurs et les équipes avant et après le match.

L'indicateur team table est un dictionnaire avec un ensemble prédéfini d'indicateurs pour chaque joueur avant chaque match. Ces indicateurs doivent décrire la forme actuelle du joueur. Cette liste peut contenir des valeurs telles que :"nombre de buts lors des 10 derniers matchs" , "distance moyenne parcourue lors des 10 derniers matchs" , "nombre d'arrêts pour GK lors des 10 derniers matchs" .

Les performance dictionnaire est très similaire à indicator , mais nous l'utiliserons pour stocker uniquement les valeurs liées à la correspondance unique :"distance parcourue" , "passes précises" , etc.

Le player_indicator et performance_indicator les tables partagent une structure presque identique :

  • in_match_id – fait référence au joueur participant à un certain match
  • indicator_id / performance_id – fait référence à l'indicator ou "dictionnaires de performance
  • value – stocke la valeur de cet indicateur (par exemple, un joueur a parcouru une distance de 10,72 km)
  • description – contient une description supplémentaire, si nécessaire

    • Que s'est-il passé pendant le match ?

    Avec toutes ces données saisies, nous pourrions facilement obtenir les détails des matchs, les événements et les statistiques pour chaque match de notre base de données.

    Cette requête simple renverrait des détails de base pour un match à venir :

    SELECT team_1.`team_name`, team_2.`team_name`, `match`.`start_time`, `match`.`location`
FROM `match`, `team` AS team_1, `team` AS team_2
WHERE `match`.`team_1_id` = team_1.`id`
AND `match`.`team_2_id` = team_2.`id`

    Pour obtenir une liste de tous les événements en jeu pendant un certain match, nous utiliserions la requête ci-dessous :

    SELECT `event`.`event_name`, `match_event`.`event_time`, `player`.`first_name`, `player`.`last_name`
FROM `match`, `match_event`, `event`, `in_match`, `player`
WHERE `match_event`.`match_id` = `match`.`id`
AND `event`.`id` = `match_event`.`event_id`
AND `in_match`.`id` = `match_event`.`in_match_id`
AND `player`.`id` = `in_match`.`player_id`
AND `match`.`id` = @match
ORDER BY `match_event`.`event_time` ASC

    Il existe de nombreuses requêtes supplémentaires auxquelles je peux penser ; il est facile de faire une analyse lorsque vous avez les données. Si vous avez mesuré et stocké un grand nombre d'indicateurs et de données sur les performances des joueurs, vous pourrez peut-être associer ces paramètres à un résultat final. Personnellement, je ne crois pas à de telles prédictions; il y a le facteur chance pendant les matchs, ainsi que de nombreux autres facteurs que vous ne pouvez pas connaître avant le début du match. Néanmoins, si vous disposez d'un grand ensemble de données et de nombreux paramètres, vos chances de faire des prédictions plus précises augmentent.

    Le modèle présenté dans cet article nous permet de stocker les matchs, les détails des matchs et un historique des performances de chaque joueur. Nous pouvons également définir des indicateurs de forme pour chaque joueur avant le match. Stocker suffisamment de détails devrait nous fournir plus de paramètres sur lesquels fonder nos hypothèses. Je ne dis pas que nous pourrions prédire le résultat du jeu, mais nous pourrions nous amuser avec.

    Nous pourrions également facilement modifier ce modèle pour stocker des données pour d'autres sports. Ces changements ne devraient pas être trop complexes. Ajouter un sport_id l'attribut aux dictionnaires devrait faire l'affaire. Pourtant, je pense qu'il serait sage d'avoir une nouvelle instance pour chaque sport différent.