BLOGあります

　データベースを使ってミッションクリティカルな業務をしようと思っているわけではないので、基本的に蓄積されたデータを抜き出し、 競馬ソフトのデータに利用するのが最大の目的です。
　で、練習をかねてデータベースから競馬新聞を作るところまでやってみました。今回は防備録をかねて、 EveryDBから出馬表を作る流れを書いてみたいと思います。

■データベースの仕様

• 年度を決定すると、年間スケジュールYSから開催一覧を出力する
• 開催一覧から開催日・コースを選択すると、該当日のレース情報RAを読みこむ
• レース情報RAを元に1Rから最終レースまでのレース名を表示
• レースを選択すると、該当レースの馬毎レース情報SEを読みこむ
• 該当レースの馬毎レース情報SEから出馬表を作成する
• 出走馬を選択すると、出走馬の血統番号から馬毎レース情報SEを呼び出し、戦績を表示する

■各処理の流れ

(1) 開催日一覧の作成

　開催日の一覧は、年間スケジュールYSを読みこむだけで簡単に作成できます。YSを読みこむSQLは下記の通りです。 年度を変数にして変更できるようにすれば汎用性が出ます。

SELECT * FROM schedule WHERE Year=2007;

　SQLを実行したあとは、取得したレコードセットから、開催年度(Year)、開催月日(MonthDay)、 開催回次(Kaiji)、場コード(JyoCd)、開催日次(Nichiji)など必要な情報を抜き出します。 YSは年度末までのデータが含まれているので、未来の年度を表示したくない場合は、 現在の日付より5日以上先のデータを読みこまないようにすればOKでしょう。

(2)開催日選択から1日のレース一覧作成

　(1)で作成した開催日一覧から開催日、場コードが決定します。これをキーにレース情報RAを検索します。

SELECT * FROM race WHERE Year=2007 AND Monthday=0331 AND Jyocd=06;

　これで2007/3/31 中山開催のレース情報RAを検索できます。 これを実行すると該当開催日のRAのみがレコードセットとして取得できるので、必要な情報を抜き出して表示します。
　次のアクションに移るのに必要な情報は、開催年度(Year)、開催月日(Monthday)、場コード(JyoCd)、 レース番号(raceNum)です。

(3)レース選択から出馬表の作成

　ここからが本題です。実は「開催日」、「コース」、「レース番号」 が特定できれば(1)から(2)のプロセスは必要ありません。

　Data Lab.から出馬表を作る場合、レース情報RAと馬毎レース情報SEが必要になります。 レース情報RAにはレース名や発走時刻、賞金などの基本情報しかふくまれていません。出走馬一覧＝出馬表を作成するには、 馬毎レース情報SEが必要になります。

　開催年度(Year)、開催月日(Monthday)、場コード(JyoCd)、 レース番号(raceNum)をキーに馬毎レース情報SEを検索します。

SELECT * FROM uma_race WHERE Year=2007 AND Monthday=0331
　　　　　AND Jyocd=06 AND Racenum=11;

　SQLを発行して得られたレコードセットから枠番、馬番、馬名など必要と思われる情報を抜き出します。

(4)戦績を表示する

　(3)の作業は大切ですが、出馬表が作成されただけで新聞と呼ぶには情報が不足しています。 いわゆる馬柱には過去何走分かの競走成績がふくまれており、これを表示してはじめて競馬新聞と同じ土俵に立てます。

　戦績を検索するには「血統番号」が必要になります。 競走馬には血統番号(KettoNum)とよばれる固有のIDが振られており、これをキーに馬毎レース情報SEを検索します。

SELECT * FROM uma_race WHERE KettoNum=xxxxxxxxxx;

　血統番号は馬毎レース情報SEに含まれているので、これを利用します。上記のSQLを実行すると、 指定血統番号の馬の全戦績がレコードセットに格納されます。あとはこれを似るなり約なり好きに調理すればよいでしょう。

■まとめ

　DBMSを利用して競馬新聞を作るのは実は簡単です。なぜならData Lab.のデータフォーマットがDBMSを前提とした形式になっているからです。「DIY競馬プログラミング Data Lab.編」 でデータベースについて触れましたが、この時はDBMSを使わないシステムの構築を前提としたため、 非常に面倒な処理が必要でした(紙面が中途半端になってしまった由縁です)。

　データの扱いはDBMSに軍配が上がるものの、 単に表示するだけで考えるとよく考えられた専用のデータ形式にはかないません。例えば、シンプルぱっとの出馬表形式は、 あるレースの出走馬一覧を表示するだけなら、DBMSよりもはるかに高速に動作します。

　どのようなデータ構造にするかは、用途やユーザー層を考えて決定する必要があります。 逆に自分とごく限られた人しか使用しない場合は、DBMSを存分に活用した方がよいでしょう。その方が楽ですし、拡張性もあります。

　また、EveryDBやKeiba Database Serverのようなソフトを使えば、 面倒なデータベース構築までを代行してくれるので、かなりの工数削減になります。

吉田さん、こんにちは。
私はＴＡＲＧＥＴがあれば十分だと思ってます。
戦績もすべてわかりますし、なんといってもオッズがすぐに得られます。競馬新聞は一切見ません。競馬場、ＷＩＮＺでも、持っていくのはパソコン＋Ｗｉｌｌｃｏｍだけです。データ処理は桐で行っています。

TARGETで見られるのはあくまでも一般の人が見られる情報に限られています。もちろん、出力したデータを加工すれば同じ事ですが。

一歩先を行く競馬をしようと思えば、やはり自前のデータベースがあった方が便利です。とくにプログラミングが出来る人間にとって、自由にアクセスできるデータベースを持つことは非常に大きなメリットがあります。

競馬新聞と同じ情報を作るのは、戦績処理を含めた競馬データの扱いの基本です。

ウィルコムはDDI POCKETの時代から使ってますが、×2程度ではちとしんどいですね。無線LANは使いませんか？

データベースの重要性はレース前よりはレース後の分析や予想法の検証に必要だと思います。
こういうデータベース構築とそこからアイデアを得ることも私にとっては競馬の楽しみです。
自宅ではADSLです。競馬場や外出先ではAirHです。今年２月に中山ゴンドラ席に行きましたが、AirH'が接続できなくなり、ipotに駆け込み投票しました。
AirH'は遅いですが、つながるだけでも有り難いです。

分析や検証にも必要ですが、「自分の予想法」に適合したソフトを用意するには不可欠です。でないと、肝心の予想段階で既成のソフトを使う事になります。今現在、吉田は自作ソフトで予想から投票までを行っています。

中山の指定は電波の入りが悪いようです。東京はA指定でもB指定でも問題なく電波が入りますが(無線LAN)。
ゴンドラで、AirEdgeが使えなくなったかはちょっと覚えてません。