他の記事との重複もありますが、それだけ重要
DB作りというと、多くの方は「データを集めること」から始まると思うかもしれません。
もちろん、それは間違いではありません。
出走表を集める。
直前情報を集める。
結果を集める。
オッズを集める。
これらを蓄積していくことで、競艇ソフトの土台となるDBは作られていきます。
しかし、本当に大事なのはその前です。
実はDB作りは、データを集め始める前からすでに始まっています。
何を集めるかより、どう使うか
最初に考えるべきことは、
「どのデータを集めるか」
だけではありません。
それ以上に大事なのは、
「集めたデータをあとでどう使うのか」
です。
たとえば、出走表だけを見て予想するのか。
直前情報も使うのか。
結果と照合して検証するのか。
オッズと組み合わせて期待値を出すのか。
この目的によって、必要なデータの形は変わります。
ただ集めるだけなら、HTMLを保存するだけでも一応は可能です。
しかし、あとから分析するなら、レース日、会場、レース番号、艇番、選手情報、展示タイム、進入、スタート、オッズ、結果などを、きちんと結びつけられる形にしておく必要があります。
つまり、DBとは単なるデータ置き場ではありません。
あとで使うための整理棚です。
私の私生活のように押し入れに何でも放り込むのとは違います。
あれをDBと呼んでしまうと、あとで探すときにだいたい遭難します。（検証済み）
レースIDを先に決める
競艇データで特に重要なのが、レースIDです。
レースIDとは、簡単に言えば「このレースはどのレースなのか」を一発で特定するための番号です。
たとえば、
- 日付
- 会場コード
- レース番号
このような情報を組み合わせれば、ある程度そのレースを特定できます。
ID： 20230314_03_06
意味は ２０２３年 ３月4日の平和島、6R
（私はこのように整理しましたが、会場コード03を最後に持ってきた方が良かった気もしています。）
大切なのは、出走表、直前情報、結果、オッズのすべてで、同じレースIDを使うことです。
後悔しても始めてしまったからには貫く覚悟が必要です。
出走表ではこのID。
直前情報では別のID。
結果ではまた違うID。
これをやってしまうと、あとで結合するときに苦労します。
苦労で済めばまだいいのですが、最悪の場合、別のレース同士をくっつけてしまう危険もあります。
これはかなりまずいです。
予想ソフトを作っているつもりが、知らないうちに間違ったデータで学習している。
こうなると、当たらない理由すら分からなくなります。
ですから、DB構築では最初にレースIDを決めておくことが重要です。
ここは地味ですが、絶対に手を抜いてはいけない部分です。
保存ルールを決めてから集める
次に大事なのが、保存ルールです。
どのフォルダに保存するのか。
ファイル名はどうするのか。
年ごとに分けるのか。
会場ごとに分けるのか。
出走表、直前情報、結果、オッズをどう分類するのか。
こういうことを決めずにデータを集め始めると、あとで大変なことになります。
最初のうちは数十レース、数百レースなので問題ありません。
しかし、1年分で約5万レース。
8年分なら約50万レースです。
この規模になると、気合いや記憶では管理できません。
「たしかこの辺に保存したはず」
「このファイルは何のデータだったかな」
「同じレースを二重に取っていないかな」
こうなった時点で、もうかなり危険です。
DB作りに必要なのは、根性ではなくルールです。
根性で50万レースを管理しようとすると、途中で人間の方が先に壊れます。
Excelより先にこちらがフリーズします。
（実は会社の業務で時折見かけることでもあります）
生データを残しておく-大切な保険
私が大事だと思っているのは、加工済みデータだけでなく、元のHTMLも残しておくことです。
最初に作った集積ソフトが、必ず完璧とは限りません。
むしろ、最初から完璧な方が珍しいですし経験者としては「そんなことが出来るわけがない。」と言っておきます。
あとになって、
「この項目も必要だった」
「風向の取り方を変えたい」
「展示タイムの扱いを見直したい」
「グレード判定に漏れがあった」
こういうことは普通に起こります。
そのとき、元のHTMLが残っていれば、もう一度そこから取り直すことができます。
しかし、加工後のデータしか残していないと、取り返しがつかない場合があります。
DBは一度作って終わりではありません。
あとから修正し、見直し、改善していくものです。
そのためにも、生データを残しておくことは大きな保険になります。
検証できる形にしておく
データは、集めたら終わりではありません。
本当に正しく取れているか。
抜けているレースはないか。
重複しているレースはないか。
結果とオッズが同じレースに結びついているか。
中止レースや欠場が変な形で混ざっていないか。
こうした確認が必要です。
ここを飛ばしてしまうと、見た目だけは立派なDBができます。
しかし、中身に間違いがあると、その先の分析はすべて怪しくなります。
たとえば、1着の選手を予測するモデルを作ったとしても、結果データの結合がズレていれば、正しい検証にはなりません。
オッズを使って期待値を出す場合も同じです。
オッズと結果が別レースのものなら、どれだけ計算式が正しくても意味がありません。
計算式は正しい。
でも材料が違う。
これは料理で言えば、カレーを作るつもりで砂糖とワサビを煮込んでいるようなものです。
根性では解決しません。
最初から完璧を目指さない
ここまで読むと、DB構築がかなり大変な作業に見えるかもしれません。
実際、大変です。
ただし、最初から完璧なDBを作ろうとする必要はありません。
まずは1年分。
まずは1会場。
まずは出走表と結果だけ。
このように小さく始めても構いません。
大切なのは、あとから広げられる形にしておくことです。
レースIDを統一する。
保存ルールを決める。
生データを残す。
検証できる形にする。
この土台さえ作っておけば、あとから直前情報やオッズを追加していくことができます。
反対に、最初にこの土台を作らずに走り出すと、あとで作り直しになる可能性が高くなります。
そして、この作り直しが一番つらいです。
データ集めそのものより、間違った構造で集めたデータを整理し直す方がはるかに大変です。
DB構築前に考えるべきこと
DB構築の前に、最低限考えておきたいことは次のような点です。
どのデータを集めるのか。
何年分を対象にするのか。
どの単位で保存するのか。
レースIDをどう作るのか。
元データを残すのか。
加工後のデータをどの形で保存するのか。
あとから検証できる仕組みになっているのか。
これらを先に考えておくことで、DB構築はかなり安定します。
いきなりデータを集め始めると、作業している感じは出ます。
画面も動きます。
ファイルも増えます。
なんとなく前に進んでいる気がします。
しかし、DB作りで本当に大事なのは、集める前の設計です。
ここを飛ばすと、あとで泣きます。
逆に言えば、ここを丁寧に決めておけば、その後の作業はかなり楽になります。
DB作りは、データを集める前から始まっています。
このことを最初に知っておくだけで、競艇ソフト作りの遠回りをかなり減らすことができます。
それの「お手伝い」のための記事もこれから掲載していきます。
