DataLab.の払戻データ

年末から作り始めた、JRA-VAN DataLab.のデータをSQLiteのデータベースに格納するスクリプトの修正作業が終わりません…。
便利かも、と思って始めましたが、ちょっと失敗だったかな…。

しかし、今まで気がつかなかった、DataLab.提供データの特性(？)に気がついたのは収穫でした。特に、払戻(HR)における「特払、不成立」データの扱いは、謎です。

以下、払戻(HR)データに関するメモ。

まず、DataLab.提供データはレコード長が固定なので、同着を考慮して予めデータ領域が多めに確保されています。そのため、SQLiteでデータベース化するために、未使用のデータ領域がどのように処理されているかを把握しておく必要がありました。(というか、エラーが出て、そうする羽目になりました。)

未使用領域は単純にデフォルト値(半角スペース)を入れておくのがシンプルで間違いもないと思います。手元のデータを見る限り、DataLab.でも2003年12月6日よりも前のレースのデータでは、そのようになっています。ところが、2003年12月6日以降のデータに関しては、状況に応じてデフォルト値以外の値が格納されることが分かりました。

私が調べた限りでは、2003年12月6日以降における未使用領域の扱いは、次の2通りに分かれます。

(1) 同着を考慮して多めに用意されているデータ領域(予備領域)。
　　→『デフォルト値(半角スペース)』で埋められる。

(2) 通常より当たり馬券の数が少なかった場合の空き領域。
　　→『馬番・組番が「00…」で「払戻金」「人気順」がデフォルト値』のデータで埋められる。

(2)は、(a)複勝で出走頭数が7頭以下の場合(通常は3着までだが、この場合2着まで)や、(b)該当種類の馬券が発売されなかった場合－－が該当します。

そのため、2003年12月6日以降のレースでは、該当種類の馬券が発売されなかった場合、たとえば「ワイド払戻」なら、最初の3つが(2)型のデータで埋められた後、残り4つの予備領域が(1)型のデータで埋められるという、必要性のよく分からない複雑なフォーマットになっています。

これまで普段の分析には「成立したレースの意味のあるデータ」だけを使い、それ以外は読み飛ばしていたので、このようなフォーマットになっていることには全く気がつきませんでした。

しかし、このようなフォーマットだとすると、問題が1つあります。それは、馬番・組番が「00…」なのは、「発売なし」の場合だけでなく、「特払、不成立」の場合もあるということです。
JV-Data仕様書によると、「特払、不成立」の場合は払戻金に「特払、不成立の金額が入る」となっています。この場合、具体的にどのようなデータが提供されるのか知りたいところですが、私の手元にある払戻(HR)には、該当するデータがありませんでした。

まず、そもそも「特払」は、昭和46年の福島競馬以来ないようです。これは、DataLab.でデータが提供されている1986年よりも前のレースです。

≪お問い合わせ≫　http://jra.jp/faq/faq02.html#q1_10
(Q)　すべての投票券が的中してしまった場合、払戻金はどうなるのですか？
逆にすべての投票券が不的中になってしまったときはどうなるのですか？

(A)　(略)これを「特払い」と呼んでいますが、中央競馬においては昭和４６年の福島競馬で単勝式の的中者がなく特払いとなって以来、こうした事例はありません。(略)
(JRAのホームページより引用)

「不成立」も珍しいですが、検索してみると、ときどきあるようです。たとえば、以下のような記事が見付かりました。

≪札幌の２歳５００万条件戦不成立に　2007/08/16(木)≫　http://keiba.radionikkei.jp/keiba/news/20070816K11.html
１８日（土）の札幌競馬第５レースに予定されていた２歳の５００万条件戦（混合、特指、芝１２００）は、出馬投票締め切りの結果、出走申し込みがわずか２頭であったためにレースが取りやめとなった。
(ラジオNIKKEIより引用)

このニュースは2007年に馬インフルエンザが流行ったときのものですが、この日のレースは手元のDataLab.のデータ上では、レース詳細(RA)のデータは「0:該当レコード削除(提供ミスなどの理由による)」で、払戻(HR)には該当レースのデータが存在しません。まあ、木曜にレース取りやめなので馬券は発売されていないわけですし、「不成立」と「取りやめ」の違いもよく分からないわけですが。

いずれにしても、手元には『馬番・組番が「00…」で「払戻金」が金額』というデータがありませんでした。

そのため、「特払、不成立」データの格納形式は想像するしかないのですが、たとえば「ワイド払戻」なら、

(a)「特払、不成立」を表わす同じデータ3つ、デフォルト値のデータ4つ。
(b)「特払、不成立」を表わすデータ1つ、「発売なし」のデータ2つ、デフォルト値のデータ4つ
(c)「特払、不成立」を表わすデータ1つ、デフォルト値のデータ6つ。

といったパターンがありそうです。(c)がいちばんスマートだと思いますが、2003年12月6日以降のフォーマットを考えると、(a)か(b)のような気もします。

とりあえず、現状のスクリプトでは、払戻金がデフォルト値でないデータを有効なデータとして格納することにしました。これだと、(2)型のような「発売なし」が複数並んだときにも対応できますし、「特払、不成立」の(b)型と(c)型にも対応できます。
ただし、これだと(a)型のデータが来た場合、複数の同じデータをテーブルに書き込もうとしてエラーになります。要は、読み込んだデータを処理する前に正規化してやればいいのだけれど……問題が出たら考えよう。

それにしても、なんでこんなフォーマットになっているのかな…。