オリンピック、UEFAユーロ2016サッカーの試合、データベースの共通点は何ですか？

私がしていることを聞くと、人々は私に同じ質問をする傾向があります。サッカーの試合結果を予測するシステムを開発できますか？またはオリンピックメダルの結果？ 個人的には、予測にはあまり信頼を置いていません。それでも、大量の履歴データと関連する指標があれば、より正確な仮定を立てるのに役立つシステムを確実に設計できます。この記事では、試合やトーナメントの結果を保存できるモデルについて検討します。

このモデルは、主にヨーロッパのサッカー（サッカー）の試合、統計、結果に焦点を当てていますが、他の多くのスポーツに対応するために簡単に調整できます。この記事の主な動機は、今年の2つの大きなサッカーイベントでした。ちょうど起こったUEFAユーロ2016チャンピオンシップと、今起こっている2016年夏季オリンピックです。

トーナメントが始まる前に私たちは何を知っていますか？

トーナメントが始まる前に、私たちはトーナメントについてほとんどすべてを知っています—最も重要なことを除いて：誰が勝つか。私たちがすでに知っていることを正確に簡単に述べましょう：

トーナメントの開始日と終了日
試合が行われる場所
試合が開始される正確な時間
どのチームがトーナメントに参加する資格がありますか
これらの各チームのプレーヤー
各プレーヤーの過去のパフォーマンスと現在のフォーム

どの一致の詳細を保存しますか？

トーナメントは複数の試合で構成されています。試合の詳細を保存する前に、次のことを行う必要があります。

各試合をトーナメントに関連付けます
試合が行われたときのトーナメントステージを記録します（例：グループステージ、準決勝）

また、次のような単一の試合の詳細を保存する必要があります。

試合に参加したチーム
スタメンと交代
試合のイベント（サッカーでは、ゴール、ペナルティ、ファウル、イエローカードなど）
最終スコア
試合中のプレーヤーの行動

このデータを使用して、すべての重要な試合イベントをキャプチャします。試合前と試合中のプレーヤーのパフォーマンスを比較すると、特定の結論につながる可能性があります。彼らのパフォーマンスの最終結果（つまり、勝ち負け）を予測することはできないかもしれませんが、統計は確かにある程度の信頼性を持って仮定を立てるのに役立ちます。

モデルの紹介

モデルは4つの主要な領域に分かれています：

Tournament details
Match details
Events
Indicators and Performance

これらの領域の外側のテーブルは辞書です（sport 、phase 、position ）、カタログ（sport_event 、team 、player ）および単一の多対多関係（plays 。

最初に分類されていないテーブルについて説明し、次に各領域を詳しく見ていきます。

未分類のテーブル

これらのテーブルは、4つの領域すべてのテーブルが辞書またはカタログとして使用するため、重要です。

sport 表には、データベースに保存するすべてのスポーツが一覧表示されています。ここにはおそらく男子サッカーの1つのスポーツしかありませんが、この表では、必要に応じて同様のスポーツ（女子サッカーなど）を柔軟に追加できます。

sport_event テーブルには、スポーツに関連するイベントが保存されます。一例として、「2016年のオリンピック」があります。

phase tableは、可能なすべてのトーナメントステージを保持する辞書です。 「グループステージ」のような値が含まれています、「16のラウンド」 、「準々決勝」 、「準決勝」 、「最終」 。

team 表は、ご想像のとおり、すべてのチームの単純なリストです。可能な値は「Croatia」です。、「ポーランド」 、「USA」 など。データベースを使用してクラブやリーグの試合に関する情報を保存すると、「バルセロナ」のような値も得られます。、「レアルマドリード」 、「バイエルン」 、「マンチェスターユナイテッド」 など

player 表には、関連するチームに属するすべてのプレーヤーのレコードが保存されます。

plays テーブルは私たちの唯一の多対多の関係であり、プレーヤーとチームを関連付けます。プレーヤーは同時に複数のチーム（たとえば、代表チームとクラブ）に所属できますが、トーナメント中は明らかに1つのチームでのみプレーします。

最後に、position テーブル。この単純な辞書には、必要なすべての位置のリストが格納されます。サッカーでは、これらにはゴールキーパー、センターハーフ、ストライカーなどが含まれます。

トーナメントの詳細

注：単一の一致の結果を保存するだけの場合は、このセクションを使用する必要はありません。

トーナメントは複数の試合で構成されます。 UEFAユーロ2016と2016年夏季オリンピックのサッカーイベントはどちらもトーナメントです。前に述べたように、データベースに1つの試合を保存できますが、試合を関連するトーナメントに関連付けることもできます。トーナメントセクションの表は次のとおりです。

tournament –これには、スポーツ、開始日、終了日など、すべての基本的なトーナメントデータが含まれます。また、トーナメント名と開催場所の説明を保存する必要があります。 sport_event_id トーナメントをより大きなイベント（オリンピックなど）に関連付ける必要がないため、属性はオプションです。
group –これはそのトーナメントのすべてのグループをリストします。 UEFAユーロ2016には、AからFまでの6つのグループがありました。
participant –これらはトーナメントでプレーしているチームです。各参加者をグループに割り当てることができます。ほとんどのトーナメントはグループステージで始まり、ノックアウトステージに続きます（例：UEFAユーロ、UEFAワールドカップ、オリンピックサッカー）。一部のトーナメントにはグループステージ（例：ナショナルリーグ）のみがあり、他のトーナメントにはノックアウトステージ（例：ナショナルカップ）のみがあります。
in_team –このテーブルは、そのトーナメントに登録されているプレーヤーとその予想される位置に関する情報を格納する多対多の関係を提供します。
tournament_schedule –私の意見では、これはこのセクションで最も興味深い表です。このトーナメント中にプレイされたすべてのゲームのリストはここに保存されます。 tournament_id 属性は、各試合が属するトーナメントとphase_idを示します。属性は、一致が行われるフェーズを定義します。試合の場所と試合開始時刻も保存します。両方の参加者はテキストフィールドで説明されます。グループステージが終了すると、エリミネーションラウンドのすべての対戦がわかります。たとえば、UEFAユーロ2016の初めに、グループE（1E）の勝者がグループDのランナーアップ（2D）と対戦することを知っていました。グループフェーズの3ラウンドすべてがプレイされた後、このペアはイタリア対スペインでした。

試合の詳細

Match details エリアは、単一の一致のデータを格納するために使用されます。 2つのテーブルを使用します：

match –これには、単一の一致に関するすべての詳細が含まれます。この試合はトーナメントに関連している可能性がありますが、単一のゲームである可能性もあります。したがって、tournament_schedule_id 属性はオプションであり、sport_idを保存します、start_time およびlocation ここでも属性。試合がトーナメントの一部である場合は、tournament_schedule_id 値が割り当てられます。 team_1_id およびteam_2_id 属性は、試合に関与するチームへの参照です。 goals_team_1 およびgoals_team_2 属性には、一致の結果が含まれます。これらは必須であり、両方のデフォルト値として「0」を設定する必要があります。
in_match –この表は、その試合に登録されているすべてのプレーヤーのリストです。参加しないプレーヤーは、started_atにNULLが含まれます属性、代わりに参加したプレーヤーは started_atを持ちます> 0 。プレーヤーが交代した場合、そのプレーヤーにはended_atがあります started_atに一致する属性それらを置き換えたプレーヤーの属性。プレーヤーが試合全体に留まった場合、そのended_at 属性はend_timeと同じ値になります属性。

一致イベント

このセクションは、ゲーム中に発生したすべての詳細またはイベントを保存することを目的としています。そして、テーブルは次のとおりです。

event –これは、保存するすべてのイベントを一覧表示する辞書です。サッカーでは、これらは「ファウルコミット」のような価値観です。、「ファウルに苦しんだ」 、「イエローカード」 、「レッドカード」 、「フリーキック」 、「ペナルティ」 、「目標」 、「オフサイド」 、「置換」 、「プレーヤーが試合から退場した」 。
match_event –これはイベントを試合に関連付けます。 event_timeを保存しますそのイベントに関連するプレーヤー情報（in_match_id 。
related_event –これがイベント情報をまとめるものです。説明のために、プレーヤーAがプレーヤーBをファウルした場合の例を見てみましょう。match_event プレーヤーAがファウルを犯したことを示す表と、プレーヤーBがファウルを被ったことを示す別の表。 related_event テーブルでは、「コミットされたファウル」が親になり、「苦しんだファウル」が子になります。イエローカード、フリーキックまたはペナルティーキック、そしておそらくゴールなど、ファウルの結果も記録します。

指標とパフォーマンス

このセクションは、試合の前後の選手とチームを分析するのに役立ちます。

indicator 表は、各試合の前に各プレーヤーのインジケーターの事前定義されたセットを備えた辞書です。これらのインジケーターは、プレーヤーの現在のフォームを説明する必要があります。このリストには、次のような値を含めることができます：「過去10試合のゴール数」 、「過去10試合でカバーされた平均距離」 、「過去10試合でのGKのセーブ数」 。

performance 辞書はindicatorと非常によく似ています、ただし、単一の一致に関連する値のみを格納するために使用します：「対象距離」 、「正確なパス」 、など。

player_indicator およびperformance_indicator テーブルはほぼ同じ構造を共有しています：

in_match_id –特定の試合に参加しているプレーヤーを指します
indicator_id / performance_id –indicatorを参照しますまたは」パフォーマンス辞書
value –そのインジケーターの値を保存します（例：10.72 kmの距離をカバーしたプレーヤー）
description –必要に応じて、追加の説明を保持します

試合中に何が起こったのですか？

このすべてのデータを入力すると、データベース内のすべての一致の一致の詳細、イベント、および統計を簡単に取得できます。

この単純なクエリは、次の試合の基本的な詳細を返します：

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`

特定の試合中のすべてのインプレーイベントのリストを取得するには、以下のクエリを使用します：

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

私が考えることができる追加のクエリはたくさんあります。データがあれば、分析を簡単に行うことができます。多数の指標とプレーヤーのパフォーマンスデータを測定して保存した場合は、これらのパラメータを最終結果に関連付けることができる場合があります。私は個人的にそのような予測を信じていません。試合中の運の要素に加えて、ゲームが始まるまでわからない他の多くの要素があります。それでも、データセットが大きく、パラメータが多い場合は、より正確な予測を行う可能性が高くなります。

この記事で紹介するモデルを使用すると、試合、試合の詳細、および各プレーヤーのパフォーマンスの履歴を保存できます。試合前に各プレイヤーのフォームインジケーターを設定することもできます。十分な詳細を保存することで、仮定の基礎となるより多くのパラメーターが提供されます。ゲームの結果を予測できると言っているわけではありませんが、それを楽しむことはできます。

このモデルを簡単に調整して、他のスポーツのデータを保存することもできます。これらの変更はそれほど複雑であってはなりません。 sport_idを追加する辞書への属性はトリックを行う必要があります。それでも、スポーツごとに新しいインスタンスを作成するのが賢明だと思います。