BLOGあります

■データフォーマットにある欠陥

　タイム理論を扱うソフトや競馬新聞を表示では、馬柱を構成する要素毎に必要なデータがあります。 簡単にまとめると以下のようになります。

(1)出馬表

• レース開催日
• コース
• レース番号
• 発走時刻
• トラック(芝・ダート)
• 施行距離
• 出走頭数
• 出走馬一覧

(2)戦績

• 出走馬毎の成績データ
• レース開催日
• コース
• レース番号
• トラック(芝・ダート)
• 施行距離
• 着順
• 走破タイム
• 上がり3F
• 着差

　馬柱を構成するデータをData Lab.に当てはめると、2種類のデータに集約されます。 出走馬以外のレース情報を含む「レース詳細RA」と、馬名、騎手、調教師、 着順などの馬にまつわるデータで構成された「馬毎レース情報SE」になります。

　シンプルぱっと２のように、戦績を含まない出馬表を表示するだけでもRAとSEが必要になります。 18頭立てのレースの出馬表を表示する場合は、RAデータがひとつ、SEデータが18コが必要になります。この段階で凄く面倒に感じます。

　一方、各馬の戦績を表示したいと思ったら、血統番号をキーに「馬毎レース情報SE」を検索します。ここに「欠陥」 とも言うべき落とし穴が潜んでいます。戦績の中に含まれているべきデータがSEデータにないのです。そのデータとは 「トラック」と「施行距離」です。競馬新聞の馬柱を見ても分かりますが、 日付と一緒に「芝2000」などのトラック、距離情報が掲載されています。しかし、肝心のSEデータにはこれが含まれておらず、 いちいちレース情報RAを参照する必要があります。

　過去50走した馬の完全な戦績データを取得するには、それぞれのレースのRAが50コ、 SEが50コと出走数の倍のデータを取得しなければなりません。

　これはスピード指数のように、トラックや距離を計算に含めている予想理論にとって大変な負担です。 どうしてこういう仕様にしてしまったのか理解に苦しむところがありますが、Data Lab.フォーマットはプログラマーの負担をあまり考慮していないと言えるでしょう。

■DBMSのみが救いの神？

　データ処理については、MySQLやSQL Server、JetDB(アクセス)に代表される、 DBMSを導入すればかなり敷居は低くなります。RAやSEはそれぞれキーになる「開催日」や「コース番号」を持っているため、 これらを元に検索をかければすぐにデータが揃うからです。
　それでもレース情報RAに出走馬の血統番号が含まれていれば、もっと容易になったと思われます。

　自分だけで利用するソフトはDBMSを検討すれば済みますが、広く一般に公開するソフトの場合はそうは簡単にいきません。 その理由は下記の通りです。

• DBMSは有償のものが多い上、高価
• アクセスは入門用DBとして適当だが、 データベースサイズが大きくなるとデータが破壊される欠陥がある(MicrosoftはSQL Serverの使用を推奨)
• 無償のDBMSはユーザー自身に導入してもらう必要があり、敷居が高い

　何とかDBMSを導入しても、競馬に最適化されたファイル形式を読みこむことに比べれば、パフォーマンスは落ちます。
　TARGETなどはDBMSを使わず、しかも非常に高速にデータを処理できるので、改めてこの辺は一日の長があるなと感じます。

　DBMSを使わないと、出馬表を表示するだけでも一苦労なので、ここで躓いてしまう人が多いかもしれません。Data Lab.対応ソフトを増やすには、 もう少し利用者の立場に立ったフォーマットを策定する必要があります(これまで大きな変更にソフト作者自身が振り回されてきたので、 今度大きな変更を加えるとさらに着いてくる人が少なくなるかもしれませんが)。

■関連エントリー

• 「JRA-VANが馬吉をオープンソース化」
• 「競馬用データベースで競馬新聞を作ろう」
• 「競馬用データベース」