Was haben die Olympischen Spiele, die Fußballspiele der UEFA Euro 2016 und Datenbanken gemeinsam?

Wenn sie hören, was ich tue, neigen die Leute dazu, mir dieselbe Frage zu stellen:Können Sie ein System entwickeln, das die Ergebnisse von Fußballspielen vorhersagt? Oder olympische Medaillenergebnisse? Ich persönlich traue Vorhersagen nicht so sehr. Hätten wir jedoch eine große Menge historischer Daten und relevanter Indikatoren, könnten wir sicherlich ein System entwerfen, das uns hilft, genauere Annahmen zu treffen. In diesem Artikel betrachten wir ein Modell, das die Ergebnisse von Spielen und Turnieren speichern kann.

Dieses Modell konzentriert sich in erster Linie auf europäische Fußballspiele, Statistiken und Ergebnisse, aber es könnte leicht angepasst werden, um viele andere Sportarten aufzunehmen. Meine Hauptmotivation für diesen Artikel waren die beiden großen Fußballereignisse dieses Jahres:die UEFA Euro 2016-Meisterschaft, die gerade stattgefunden hat, und die Olympischen Sommerspiele 2016, die gerade stattfinden.

Was wissen wir, bevor das Turnier beginnt?

Bevor das Turnier beginnt, wissen wir fast alles darüber – außer dem Wichtigsten:Wer wird gewinnen? Lassen Sie uns kurz genau sagen, was wir bereits wissen:

• Die Daten, an denen das Turnier beginnt und endet
• Die Orte, an denen die Spiele stattfinden werden
• Die genauen Startzeiten der Spiele
• Welche Mannschaften haben sich für das Turnier qualifiziert
• Die Spieler in jedem dieser Teams
• Die bisherige Leistung jedes Spielers und seine aktuelle Form

Welche Spieldetails möchten wir speichern?

Turniere bestehen aus mehreren Spielen. Bevor wir Spieldetails speichern, müssen wir:

• Verknüpfen Sie jedes Spiel mit dem Turnier
• Aufzeichnen der Turnierphase, in der das Spiel gespielt wurde (z. B. Gruppenphase, Halbfinale)

Wir müssen auch Details für einzelne Übereinstimmungen speichern, einschließlich:

• Die am Spiel beteiligten Teams
• Startaufstellungen und Auswechslungen
• Spielereignisse (im Fußball sind dies:Tor, Elfmeter, Foul, gelbe Karte usw.)
• Endstand
• Aktionen der Spieler während des Spiels

Wir verwenden diese Daten, um alle wichtigen Spielereignisse zu erfassen. Der Vergleich der Leistung eines Spielers vor und während des Spiels könnte zu bestimmten Schlussfolgerungen führen. Vielleicht wären wir nicht in der Lage, die endgültigen Ergebnisse ihrer Leistung vorherzusagen (d. h. einen Sieg oder eine Niederlage), aber Statistiken könnten uns sicherlich dabei helfen, Annahmen mit einem gewissen Grad an Zuverlässigkeit zu treffen.

Einführung des Modells

Das Modell ist in vier Hauptbereiche unterteilt:

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

Die Tabellen außerhalb dieser Bereiche sind Wörterbücher (sport , phase , position ), Kataloge (sport_event , team , player ) und eine einzelne Viele-zu-Viele-Beziehung (plays ).

Wir werden zuerst die nicht kategorisierten Tabellen beschreiben und uns dann jeden Bereich genau ansehen.

Die nicht kategorisierten Tabellen

Diese Tabellen sind wichtig, weil Tabellen aus allen vier Bereichen sie als Wörterbücher oder Kataloge verwenden.

Der sport Tabelle listet alle Sportarten auf, die wir in unserer Datenbank speichern. Wahrscheinlich haben wir hier nur eine Sportart, Männerfußball, aber diese Tabelle gibt uns die Flexibilität, bei Bedarf ähnliche Sportarten (z. B. Frauenfußball) hinzuzufügen.

Im sport_event Tabelle speichern wir die mit unserer(n) Sport(en) verbundenen Ereignisse. Ein Beispiel wären die „Olympischen Spiele 2016“.

Die phase table ist ein Wörterbuch, das alle möglichen Turnierphasen enthält. Es enthält Werte wie „Gruppenphase“ , "Achtelfinale" , "Viertelfinale" , „Halbfinale“ , "final" .

Das team Tabelle ist, wie Sie sich vorstellen können, eine einfache Liste aller Teams. Mögliche Werte sind „Kroatien“ , „Polen“ , „USA“ usw. Wenn wir die Datenbank verwenden, um Informationen über Vereins- oder Ligawettbewerbe zu speichern, hätten wir auch Werte wie "Barcelona" , "Real Madrid" , "Bayern" , "Manchester United" usw.

Im player Tabelle speichern wir Aufzeichnungen für alle Spieler, die zu den relevanten Teams gehören.

Der plays Tabelle ist unsere einzige Viele-zu-Viele-Beziehung, und sie verbindet Spieler und Teams. Ein Spieler kann gleichzeitig mehr als einer Mannschaft angehören (z. B. der Nationalmannschaft und einem Verein), aber während eines Turniers spielt er natürlich nur für eine Mannschaft.

Schließlich haben wir die position Tisch. Dieses einfache Wörterbuch speichert eine Liste aller erforderlichen Positionen. Im Fußball gehören dazu Torhüter, Innenverteidiger, Stürmer usw.

Turnierdetails

Hinweis: Wenn Sie nur die Ergebnisse einzelner Spiele speichern möchten, brauchen Sie diesen Abschnitt nicht zu verwenden.

Ein Turnier besteht aus mehr als einem Match; Sowohl die UEFA Euro 2016 als auch die Fußballveranstaltungen der Olympischen Sommerspiele 2016 sind Turniere. Wie wir bereits gesagt haben, können wir ein einzelnes Spiel in unserer Datenbank speichern, aber wir können auch Spiele den entsprechenden Turnieren zuordnen. Die Tabellen in der Turniersektion sind:

• tournament – Diese enthält alle grundlegenden Turnierdaten:Sportart, Startdatum, Enddatum usw. Wir müssen auch den Turniernamen und eine Beschreibung des Veranstaltungsortes speichern. Die sport_event_id Das Attribut ist optional, da ein Turnier nicht mit einem größeren Ereignis (wie den Olympischen Spielen) verbunden sein muss.
• group – Dies listet alle Gruppen in diesem Turnier auf. Die UEFA Euro 2016 hatte sechs Gruppen, A bis F.
• participant – Dies sind die Mannschaften, die am Turnier teilnehmen; Jeder Teilnehmer kann einer Gruppe zugeordnet werden. Die meisten Turniere beginnen mit einer Gruppenphase und gehen dann in eine K.-o.-Phase über (z. B. UEFA Euro, UEFA World Cup, Olympischer Fußball). Einige Turniere haben nur eine Gruppenphase (z. B. nationale Ligen), während andere nur eine K.-o.-Phase haben (z. B. nationale Pokale).
• in_team – Diese Tabelle bietet eine Viele-zu-Viele-Beziehung, die Informationen über die für dieses Turnier registrierten Spieler und ihre erwarteten Positionen speichert.
• tournament_schedule – Meiner Meinung nach ist dies die interessanteste Tabelle in diesem Abschnitt. Die Liste aller während dieses Turniers gespielten Spiele wird hier gespeichert. Die tournament_id -Attribut gibt an, zu welchem ​​Turnier jedes Match gehört, und die phase_id -Attribut definiert die Phase, in der das Match stattfindet. Wir speichern auch den Ort des Spiels und die Zeit, zu der es beginnt. Beide Teilnehmer werden durch Textfelder beschrieben. Wenn die Gruppenphase beendet ist, kennen wir alle Begegnungen für die Ausscheidungsrunde. Zum Beispiel wussten wir zu Beginn der UEFA Euro 2016, dass der Sieger der Gruppe E (1E) gegen den Zweitplatzierten der Gruppe D (2D) spielen wird. Nachdem alle drei Runden der Gruppenphase gespielt waren, hieß es in dieser Paarung Italien gegen Spanien.

Spieldetails

Die Match details Bereich wird verwendet, um Daten für einzelne Spiele zu speichern. Wir verwenden zwei Tabellen:

• match – Dies enthält alle Details zu einem einzelnen Spiel; Dieses Match kann sich auf ein Turnier beziehen, es kann sich aber auch um ein einzelnes Spiel handeln. Also die tournament_schedule_id Das Attribut ist optional und wir speichern die sport_id , start_time und location Attribute hier noch einmal. Wenn das Spiel Teil eines Turniers ist, dann tournament_schedule_id wird ein Wert zugewiesen. Die team_1_id und team_2_id Attribute sind Verweise auf die am Spiel beteiligten Teams. Das goals_team_1 und goals_team_2 Attribute enthalten das Ergebnis des Abgleichs. Sie sind obligatorisch und sollten für beide „0“ als Standardwert haben.
• in_match – Diese Tabelle ist eine Liste aller Spieler, die für dieses Spiel registriert sind; Spieler, die nicht teilnehmen, haben eine NULL im started_at Attribut, während Spieler, die eingewechselt wurden, started_at haben> 0 . Wenn ein Spieler ersetzt wurde, hat er ein ended_at Attribut, das mit started_at übereinstimmt Attribut des Spielers, der sie ersetzt hat. Wenn der Spieler während des gesamten Spiels drin geblieben ist, wird sein ended_at Attribut hat denselben Wert wie end_time Attribut.

Spielereignisse

Dieser Abschnitt soll alle Details oder Ereignisse speichern, die während des Spiels passiert sind. Und die Tabellen sind:

• event – Dies ist ein Wörterbuch, das alle Ereignisse auflistet, die wir speichern möchten. Im Fußball sind das Werte wie „Foul begangen“ , „Foul erlitten“ , "gelbe Karte" , "Rote Karte" , "Freistoß" , „Strafe“ , „Ziel“ , „Abseits“ , „Substitution“ , „Spieler aus dem Spiel ausgeschlossen“ .
• match_event – Dies verknüpft Ereignisse mit dem Spiel. Wir speichern die event_time sowie Spielerinformationen zu diesem Event (in_match_id ).
• related_event – Das bringt Veranstaltungsinformationen zusammen. Schauen wir uns zur Erklärung ein Beispiel an, in dem Spieler A Spieler B foult. Wir fügen einen Datensatz in match_event Tabelle, die anzeigt, dass Spieler A ein Foul begangen hat, und eine andere, die anzeigt, dass Spieler B ein Foul erlitten hat. Außerdem fügen wir dem related_event Tabelle, in der das „begangene Foul“ der Elternteil und das „erlittene Foul“ das Kind ist. Wir erfassen auch die Ergebnisse des Fouls:eine gelbe Karte, einen Freistoß oder einen Elfmeter und vielleicht ein Tor.

Indikatoren und Leistung

Dieser Abschnitt soll uns helfen, Spieler und Mannschaften vor und nach dem Spiel zu analysieren.

Der indicator Tabelle ist ein Wörterbuch mit einem vordefinierten Satz von Indikatoren für jeden Spieler vor jedem Spiel. Diese Indikatoren sollten die aktuelle Form des Spielers beschreiben. Diese Liste könnte Werte enthalten wie:"Anzahl der Tore in den letzten 10 Spielen" , "durchschnittliche zurückgelegte Distanz in den letzten 10 Spielen" , „Anzahl der Paraden für GK in den letzten 10 Spielen“ .

Die performance dictionary ist sehr ähnlich zu indicator , aber wir verwenden es, um nur Werte zu speichern, die sich auf die einzelne Übereinstimmung beziehen:"zurückgelegte Strecke" , „genaue Pässe“ usw.

Der player_indicator und performance_indicator Tabellen haben eine fast identische Struktur:

• in_match_id – bezieht sich auf den Spieler, der an einem bestimmten Spiel teilnimmt
• indicator_id / performance_id – verweist auf den indicator oder „Leistungswörterbücher
• value – speichert den Wert für diesen Indikator (z. B. ein Spieler hat eine Strecke von 10,72 km zurückgelegt)
• description – enthält bei Bedarf eine zusätzliche Beschreibung

Was ist während des Spiels passiert?

Mit all diesen eingegebenen Daten konnten wir problemlos Spieldetails, Ereignisse und Statistiken für jedes Spiel in unserer Datenbank abrufen.

Diese einfache Abfrage würde grundlegende Details für ein bevorstehendes Spiel zurückgeben:

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`

Um eine Liste aller In-Play-Events während eines bestimmten Spiels zu erhalten, würden wir die folgende Abfrage verwenden:

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

Es gibt zahlreiche zusätzliche Abfragen, die mir einfallen; Es ist einfach, eine Analyse durchzuführen, wenn Sie die Daten haben. Wenn Sie eine große Anzahl von Indikatoren und Spielerleistungsdaten gemessen und gespeichert haben, können Sie diese Parameter möglicherweise mit einem Endergebnis in Beziehung setzen. Ich persönlich glaube nicht an solche Vorhersagen; Es gibt den Glücksfaktor während der Spiele sowie zahlreiche andere Faktoren, die Sie nicht kennen können, bis das Spiel beginnt. Wenn Sie jedoch über einen großen Datensatz und viele Parameter verfügen, steigt Ihre Chance, genauere Vorhersagen zu treffen.

Das in diesem Artikel vorgestellte Modell ermöglicht es uns, Spiele, Spieldetails und eine Historie der Leistung jedes Spielers zu speichern. Wir können auch vor dem Spiel Formindikatoren für jeden Spieler setzen. Das Speichern von genügend Details sollte uns mehr Parameter liefern, auf die wir unsere Annahmen stützen können. Ich sage nicht, dass wir das Ergebnis des Spiels vorhersagen könnten, aber wir könnten ein bisschen Spaß damit haben.

Wir könnten dieses Modell auch leicht optimieren, um Daten für andere Sportarten zu speichern. Diese Änderungen sollten nicht zu komplex sein. Hinzufügen einer sport_id -Attribut zu den Wörterbüchern sollte ausreichen. Trotzdem halte ich es für sinnvoll, für jede Sportart eine neue Instanz zu haben.