sql >> Base de Datos >  >> RDS >> Database

¿Qué tienen en común los Juegos Olímpicos, los partidos de fútbol de la UEFA Euro 2016 y las bases de datos?

Al escuchar lo que hago, la gente tiende a hacerme la misma pregunta:¿Puedes desarrollar un sistema que prediga los resultados de los partidos de fútbol? ¿O los resultados de las medallas olímpicas? Personalmente, no confío mucho en las predicciones. Aún así, si tuviéramos una gran cantidad de datos históricos e indicadores relevantes, ciertamente podríamos diseñar un sistema que nos ayude a generar suposiciones más precisas. En este artículo, consideraremos un modelo que puede almacenar los resultados de partidos y torneos.

Este modelo se centra principalmente en los partidos, las estadísticas y los resultados del fútbol europeo, pero podría modificarse fácilmente para adaptarse a muchos otros deportes. Mi principal motivación para escribir este artículo fueron los dos grandes eventos futbolísticos de este año:la Eurocopa 2016 de la UEFA que acaba de suceder y los Juegos Olímpicos de Verano de 2016 que se están llevando a cabo en este momento.

¿Qué sabemos antes de que comience el torneo?

Antes de que comience el torneo, sabemos casi todo al respecto, excepto lo más importante:quién ganará. Indiquemos brevemente exactamente lo que ya sabemos:

  • Las fechas de inicio y finalización del torneo
  • Los lugares donde se llevarán a cabo los partidos
  • Las horas exactas en que comenzarán los partidos
  • Qué equipos se han clasificado para el torneo
  • Los jugadores de cada uno de estos equipos
  • El desempeño anterior de cada jugador y su forma actual

¿Qué detalles del partido queremos almacenar?

Los torneos consisten en múltiples partidos. Antes de almacenar los detalles de cualquier coincidencia, necesitamos:

  • Relacionar cada partido con el torneo
  • Registre la etapa del torneo cuando se jugó el partido (por ejemplo, la fase de grupos, las semifinales)

También necesitamos almacenar detalles para coincidencias individuales, que incluyen:

  • Los equipos involucrados en el partido
  • Alineaciones iniciales y sustituciones
  • Eventos del partido (en fútbol son:gol, penalti, falta, tarjeta amarilla, etc.)
  • Puntuación final
  • Acciones de los jugadores durante el partido

Usaremos estos datos para capturar todos los eventos importantes del partido. Comparar el rendimiento de un jugador antes y durante el partido podría llevar a ciertas conclusiones. Tal vez no podamos predecir los resultados finales de su desempeño (es decir, una victoria o una derrota), pero las estadísticas ciertamente podrían ayudarnos a hacer suposiciones con cierto grado de confiabilidad.

Presentación del modelo




El modelo se divide en cuatro áreas principales:

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

Las tablas fuera de estas áreas son diccionarios (sport , phase , position ), catálogos (sport_event , team , player ) y una única relación muchos a muchos (plays ).

Primero describiremos las tablas sin categorizar y luego analizaremos de cerca cada área.

Las tablas sin categorizar

Estas tablas son importantes porque las tablas de las cuatro áreas las usan como diccionarios o catálogos.

El sport La tabla enumera todos los deportes que almacenaremos en nuestra base de datos. Probablemente solo tengamos un deporte aquí, fútbol masculino, pero esta tabla nos brinda la flexibilidad de agregar deportes similares (por ejemplo, fútbol femenino) si es necesario.

En el sport_event tabla, almacenaremos los eventos relacionados con nuestro(s) deporte(s). Un ejemplo serían los “Juegos Olímpicos de 2016”.

La phase table es un diccionario que contiene todas las etapas posibles del torneo. Contiene valores como “fase de grupos” , “octavos de final” , “cuartos de final” , “semifinales” , “final” .

El team La tabla es, como puede suponer, una lista simple de todos los equipos. Los valores posibles son “Croacia” , “Polonia” , “Estados Unidos” etc. Si utilizamos la base de datos para almacenar información sobre la competición de clubes o ligas, también tendríamos valores como “Barcelona” , “Real Madrid” , “Bayern” , “Manchester United” etc.

En el player tabla, almacenaremos los registros de todos los jugadores pertenecientes a los equipos correspondientes.

El plays table es nuestra única relación de muchos a muchos, y relaciona jugadores y equipos. Un jugador puede pertenecer a más de un equipo al mismo tiempo (por ejemplo, la selección nacional y un club), pero durante un torneo obviamente jugará para un solo equipo.

Finalmente, tenemos la position mesa. Este diccionario simple almacenará una lista de todas las posiciones requeridas. En el fútbol, ​​estos incluyen portero, medio centro, delantero, etc.

Detalles del Torneo

Nota: Si solo desea almacenar los resultados de coincidencias individuales, no necesita usar esta sección.

Un torneo consta de más de un partido; tanto la UEFA Euro 2016 como los eventos de fútbol en los Juegos Olímpicos de Verano de 2016 son torneos. Como dijimos antes, podemos almacenar un solo partido en nuestra base de datos, pero también podemos relacionar los partidos con sus torneos relevantes. Las mesas en la sección de Torneos son:

  • tournament – Contiene todos los datos básicos del torneo:el deporte, la fecha de inicio, la fecha de finalización, etc. También necesitamos almacenar el nombre del torneo y una descripción de dónde se lleva a cabo. El sport_event_id El atributo es opcional porque un torneo no tiene que estar asociado con un evento más grande (como los Juegos Olímpicos).
  • group – Esto enumera todos los grupos en ese torneo. La UEFA Euro 2016 tuvo seis grupos, de la A a la F.
  • participant – Estos son los equipos que juegan en el torneo; cada participante puede ser asignado a un grupo. La mayoría de los torneos comienzan con una fase de grupos y luego continúan con una fase eliminatoria (por ejemplo, la Eurocopa de la UEFA, la Copa Mundial de la UEFA, el fútbol olímpico). Algunos torneos tendrán solo una fase de grupos (p. ej., ligas nacionales), mientras que otros tendrán solo una fase eliminatoria (p. ej., copas nacionales).
  • in_team – Esta tabla proporciona una relación de muchos a muchos que almacena información sobre los jugadores registrados para ese torneo y sus posiciones esperadas.
  • tournament_schedule – En mi opinión, esta es la tabla más interesante de esta sección. La lista de todos los juegos jugados durante este torneo se almacena aquí. El tournament_id El atributo indica a qué torneo pertenece cada partido y el phase_id El atributo define la fase durante la cual se llevará a cabo el partido. También almacenaremos la ubicación del partido y la hora en que comienza. Ambos participantes serán descritos por campos de texto. Cuando termine la fase de grupos, sabremos todos los enfrentamientos para la ronda eliminatoria. Por ejemplo, al comienzo de la UEFA Euro 2016, sabíamos que el ganador del Grupo E (1E) jugaría contra el subcampeón del Grupo D (2D). Después de que se jugaron las tres rondas de la fase de grupos, esta pareja fue Italia vs. España.

Detalles del partido

Los Match details El área se utiliza para almacenar datos para coincidencias individuales. Usaremos dos tablas:

  • match – Esto contiene todos los detalles sobre un solo partido; este partido puede estar relacionado con un torneo, pero también podría ser un solo juego. Entonces el tournament_schedule_id El atributo es opcional y almacenaremos el sport_id , start_time y location atributos de nuevo aquí. Si el partido es parte de un torneo, entonces tournament_schedule_id se le asignará un valor. El team_1_id y team_2_id Los atributos son referencias a los equipos involucrados en el partido. El goals_team_1 y goals_team_2 Los atributos contienen el resultado de la coincidencia. Son obligatorios y deben tener "0" como valor predeterminado para ambos.
  • in_match – Esta tabla es una lista de todos los jugadores que están registrados para ese partido; los jugadores que no participen tendrán un NULL en el started_at atributo, mientras que los jugadores que entraron como sustituciones tendrán started_at> 0 . Si se reemplazó a un jugador, tendrá un ended_at atributo que coincide con started_at atributo del jugador que los reemplazó. Si el jugador se quedó durante todo el partido, su ended_at el atributo tendrá el mismo valor que el end_time atributo.

Eventos de partidos

Esta sección está destinada a almacenar todos los detalles o eventos que sucedieron durante el juego. Y las tablas son:

  • event – Este es un diccionario que enumera todos los eventos que queremos almacenar. En el fútbol, ​​estos son valores como “falta cometida” , “falta sufrida” , “tarjeta amarilla” , “tarjeta roja” , “tiro libre” , “penalización” , “objetivo” , “fuera de juego” , “sustitución” , “jugador expulsado del partido” .
  • match_event – Esto relaciona eventos con el partido. Guardaremos el event_time así como la información del jugador relacionada con ese evento (in_match_id ).
  • related_event – Esto es lo que une la información del evento. Para explicarlo, veamos un ejemplo cuando el jugador A comete falta contra el jugador B. Insertaremos un registro en el match_event tabla que indica que el jugador A cometió una falta y otra que indica que el jugador B sufrió una falta. También agregaremos un registro al related_event mesa, donde la 'falta cometida' será el padre y la 'falta sufrida' será el niño. También registraremos los resultados de la falta:una tarjeta amarilla, un tiro libre o un tiro penal, y tal vez un gol.

Indicadores y Desempeño

Esta sección debería ayudarnos a analizar jugadores y equipos antes y después del partido.

El indicator table es un diccionario con un conjunto predefinido de indicadores para cada jugador antes de cada partido. Estos indicadores deben describir la forma actual del jugador. Esta lista podría contener valores como:“número de goles en los últimos 10 partidos” , “distancia media recorrida en los últimos 10 partidos” , “número de paradas de GK en los últimos 10 partidos” .

El performance el diccionario es muy similar a indicator , pero lo usaremos para almacenar solo valores relacionados con la coincidencia única:“distancia recorrida” , “pases precisos” , etc.

El player_indicator y performance_indicator las tablas comparten una estructura casi idéntica:

  • in_match_id – se refiere al jugador que participa en un determinado partido
  • indicator_id / performance_id – hace referencia al indicator o ”diccionarios de rendimiento
  • value – almacena el valor de ese indicador (por ejemplo, un jugador recorrió una distancia de 10,72 km)
  • description – contiene una descripción adicional, si es necesario
  • ¿Qué sucedió durante el partido?

    Con todos estos datos ingresados, podríamos obtener fácilmente detalles de partidos, eventos y estadísticas para cada partido en nuestra base de datos.

    Esta simple consulta devolvería detalles básicos para un próximo partido:

    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`
    

    Para obtener una lista de todos los eventos en juego durante una determinada partida, usaríamos la siguiente consulta:

    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
    

    Hay numerosas consultas adicionales que se me ocurren; es fácil hacer un análisis cuando tienes los datos. Si ha medido y almacenado una gran cantidad de indicadores y datos de rendimiento del jugador, es posible que pueda relacionar estos parámetros con un resultado final. Personalmente, no creo en tales predicciones; está el factor suerte durante los partidos, además de muchos otros factores que no puedes saber hasta que comienza el juego. Aún así, si tiene un gran conjunto de datos y muchos parámetros, aumentan sus posibilidades de hacer predicciones más precisas.

    El modelo presentado en este artículo nos permite almacenar partidos, detalles de partidos y un historial del rendimiento de cada jugador. También podemos establecer indicadores de forma para cada jugador antes del partido. Almacenar suficientes detalles debería proporcionarnos más parámetros en los que basar nuestras suposiciones. No digo que podamos predecir el resultado del juego, pero podemos divertirnos un poco.

    También podríamos modificar fácilmente este modelo para almacenar datos de otros deportes. Estos cambios no deberían ser demasiado complejos. Añadir un sport_id atributo a los diccionarios debería hacer el truco. Aún así, creo que sería prudente tener una nueva instancia para cada deporte diferente.