データベース

作成中の SQLite のデータベースについて御説明しようと思います。
マイクロソフトアクセス（Access）は、現在では時代遅れのデータベースであることは既に御説明をいたしました。
手っ取り早く言えば、遅い、多人数によるネットワークのアクセスに弱い、データベースのファイル容量に限界がある等です。
機能が豊富な分、同じ内容を蓄積したデータベースと比較して極端にファイルの容量が大きくなる点も欠点でしょう。
良い点は豊富な資料と解説がありますので構築が容易な事と使い易いコマンドが多い点でしょうか。
競馬のデータベースをアクセスで構築する場合は、動作の遅さとファイル容量に限界がある点が最大のネックとなります。
ネックと言うよりは、構築は相当無理しないと（特別なテクニックを使用するなど）不可能でしょう。

制限の無い高速で安定性の高いデータベースが現在はいくらでもあるのですから、それを使うべきだと思います。
データベースをマイクロソフトエクセル（Excel）などと連携させたい場合は、SQLサーバーを使用するのが最適でしょう。
同じマイクロソフトの製品ですから連携を考慮された設計になっておりますし、動作に関する評判も良いようです。
最大の欠点は、有料であると言う点で無料版もありますが容量の制限や動作についても有料版と異なるようです。

その点、MySQLは無料で使用できますし、容量の制限もありませんし、動作も軽快であること、古くから存在しておりましたので解説書も多いことなどベストのように思えます。
私も、MySQL で競馬のデータベースを何回か構築しましたが、アクセスと比較して実感できるほどの高速性がありました。
コマンドの種類も多いので、アクセスで動いていた環境ならば、ほとんどそのままの状態で動きます。

今回、なぜ MySQL では無くてSQLite を使用したのかと言うと、簡易的なデータベースと思われていた SQLite が実は MySQL よりも高速で、数百万以上のデータ量に対しても安定に動作するのではないかと考えたからです。
SQLite を実際にそのような状態で使用しているとのサイトの報告があり、評価も高かったので試してみたいと言う気持ちがありました。
それから、データベースの構造が単純で単一構造なので MySQL と比較してバックアップが容易です。
更に、MySQL のように起動しないと使えないと言うような事がありません。
文字コードも一本化されておりますので、バージョンの違いにようる文字化けのトラブルも無さそうです。
PHP でもサポートされておりますので、ホームページからデータベースアクセスする事も容易です。

私の場合はプロバイダがヤフーですから、ヤフーのホームページ（ジオプラス）でも SQLite が扱える点も重要なポイントとなりました。
ムーバブルタイプを使用したブログの作成には、MySQL か SQLite を選択できるのですが、ムーバブルタイプは動作が重くて、MySQL を使用している人が SQLite に切り替えて使用する人が多かったのも SQLite が優秀なデータベースではないかと思った点もありました。
（最新バージョンのムーバブルタイプは、SQLite のデータベースは使用する事が出来ないようです。）
私にとっては、SQLite は魅力がいっぱいのデータベースに思えたのです。
その他では、同じようなデータベース構造の FireBird も使用してみたいデータベースです。
競馬予想ソフトの中には、FireBird を使用しているものもあるようですから、時間が取れればこのデータベースも試してみようと思います。

【追記】
FireBird を使用したデータベースも作成してみました。
構築されるデータベースの容量が少ない点には感心しましたが、SQLite と比較して特に優れている点（検索スピードなど）があるとは私は思いませんでした。
MySQL と同様に起動状態にしておかないと使用出来ない点も少々気になりました。

●SQLiteのインストール

１．SQLite のインストール
データベース SQlite のインストールを行います。
SQLiteのDownLoad ページからSQLite3 をダウンロードします。



次にダウンロードした「sqlite-3_6_23_1.zip」を解凍します。
解凍を行う場所は任意で良いのですが、可能であれば解説の通りの場所に解凍する事をお勧めします。
解説と異なる場所に設定した場合には、odbcドライバーの設定内容をそれに合わせる必要があります。
ここでは「C:\SQLite3」フォルダを作成して、そこに解凍する事にしました。

解凍すると「sqlite3.exe」1個が作成されます。



競馬予想ソフトをインストールする場合は、添付のデータベースファイル（umachan.db）は同じフォルダ内に入れておきます。
新規にデータベースファイルを作成する場合は、以下のようにしてください。
Windowsのスタートから、全てのプログラム→アクセサリー→コマンドプロンプトを選択してコマンドプロンプトをクリックして起動します。
起動時は、通常 Documennt and Settings\****> フォルダが選択されますので、cd\ を入力してクリアします。（****はログインユーザー名）

次に、C:\> の後に cd SQLite3を入力してリターン（RET)キーを押します。
（Documennt and Settings\****>cd C:\SQLite3 の入力でも同じ動作を行います。）
C:\> の表示が、C:\SQLite3> に変ってアクセスフォルダが「C:\SQLite3」移動した事が確認できます。



このフォルダには、解凍した「sqlite3.exe」ファイルがあります。
次に以下のコマンドで、データベースファイルを作成します。
sqlite3.exe umachan.db（sqlite3 umachan.db でも同じ動作をします。）



次に、作成したデータベースに test テーブルを作成します。



ここでは、test テーブルはデータベースを作成するためにダミーのテーブルです。
テーブルを作成後に、.exit（.quitでも同じ）を入力して、sqlite3.exe を終了します。
「C:\SQLite3」フォルダに、umachan.db の名前でデータベースが作成されたのが確認できます。
これで、SQLite のインストールとデータベースの作成は終了です。
同じフォルダ内に、odbc フォルダや SQLiteManager-1.2.0 フォルダも作成されおりますが、これについては後述します。(現在は無関係です）

２．ODBC ドライバーのインストール
データベースと接続するための ODBC ドライバーのインストールを行います。
SQLite と接続するためのドライバーは何種類かありますが、 民芸的プログラミング さんの作成されたものを使用させていただきます。
特に他のドライバーと比較してみた訳ではありませんが、トラブルが発生した事がありませんので、こちらの使用をお勧め致します。

ドライバーの ダウンロード とインストール方法はこちらに記載されております。
インストールに慣れていない初心者の方のために、インストールの方法を補足いたします。
画面中央に記載の http://www7a.biglobe.ne.jp/~kzworks/attach/sqlite3odbc-0.83.zip をクリックして、ドライバーをダウンロードします。



ここでは、前に作成した「C:\SQLite3」フォルダに「odbc」と言うサブフォルダを作成して、そこに解凍します。
解凍するとファイル名が、sqlite3odbc.dll となります。
次にWindowsのスタートから、全てのプログラム→アクセサリー→コマンドプロンプトを選択してコマンドプロンプトをクリックして起動します。
起動時は、通常 Documennt and Settings\****> フォルダが選択されますので、cd\ を入力してクリアします。（****はログインユーザー名）

次に、C:\> の後に cd SQLite3\odbc を入力してリターン（RET)キーを押します。
C:\> の表示が、C:\SQLite3\odbc> に変ってアクセスフォルダが移動した事が確認できます。
この状態で、rundll32 sqlite3odbc.dll,install を入力してリターン（RET）キー押すと、ODBC ドライバーがインストールされます。
インストールした ODBC ドライバーを削除する場合は、rundll32 sqlite3odbc.dll,uninstall と入力します。
【注記】
rundll32.exe が正常に動作しない場合には、様々な原因が考えられるようです。
ファイルの破損、ウィルスの感染などサイト上には多くの情報がありますので御確認ください。

３．ODBC ドライバーの接続設定
インストールした ODBC ドライバー を使用するための接続設定を行います。
この設定は、パソコンの初心者が最も苦手とする部分で、正確に入力しないと正常に動作致しません。
後少しの辛抱ですので、頑張って設定してください。
最初にコントロールパネルを立ち上げます。
解説では、WindowsXp を例にしております。
画面はコントロールパネルをクラシック表示にした状態です。



管理ツールを選択します。



データソース（ODBC)を選択します。



「システム DSN 」タブをクリックします。
追加ボタンを押します。
この画面は、私のパソコンの設定内容の画面ですから、お使いのパソコンで表示される内容とは異なります。



「SQLite3 ODBC Driver」を選択してから、完了ボタンを押します。
（SQLite3 ODBC Driver を選択した場合は、実際はブルーの枠に囲まれた状態になります。）
画面内の内容はお使いのパソコンによって異なりますが、名前の欄内に「SQLite3 ODBC Driver」が無い場合は、ODBC ドライバーのインストールに失敗していると考えられます。
このような場合には、ドライバーの提供サイトの説明やドライバーのインストール方法の解説サイトをご覧ください。

完了ボタンを押すと以下のような画面に切り替わります。



画面内の Data Source Name を、SQLiteUmachan にします。(スペースは入れないでください。）
次に右側の browse... ボタンを押して Database Name の設定を行います。



「C:\SQLite3」フォルダに作成した umachan.db を選択して開くボタンを押すと、Database Name が記入されます。
他の部分の項目には、記入を行ったり、チェックをつける必要はありません。
ＯＫボタンを押して画面を閉じてください。
画面を閉じるとシステム DSN タブに、SQLiteUmachan が作成されている事が確認出来ます。
以上で ODBC の設定は全て終了しました。

参考に ODBC を使用してコネクションするためのコードを記載します。
このコードを記載する方法も色々あって、どの書き方でも正常に動作するようです。
どの方法でも動くが、どの方法でも変化はなかったと言う認識です。
私が使用しているコネクションの記載方法は以下の通りです。

cn3.Open "Driver=SQLite3 ODBC Driver;" & _
        "Database=" & DataBasemei & ";" & _
        "StepAPI=0;SyncPragma=NORMAL;NoTXN=0;Timeout=;ShortNames=0;LongNames=0;NoCreat=0;NoWCHAR=1;LoadExt=;"

Cn3はコネクション名で任意です。
DataBasemei はデータベースの位置をフルパスで記載します。
例えば、C:\SQLite3\umachan.db のように記載します。
このコネクションの記載の内容は、私は十分理解しておりませんが、odbc ドライバーを提供されているサイトでの参考例をそのまま利用させていただいております。
エクセルと接続させるためのコネクションとして記載されていたものですが、VBでも当然動きます。

●データベースの構造

データベースを何にするのかも重要ですが、もっとも重要なのはデータベースの構造です。
データベースの構造が悪いと、どんなに高速なデータベースを使用しても表示が待たされたりします。
多くの本格的な競馬関係のソフト（データベース構築ソフトも含む）は、独自のデータベースを持っておりますが、データベースの構造をみると JRA-VAN から提供されるデータ構造をそのままデータベース化しているようです。
その方がデータベースの作成は楽ですので、私もそのようにしておりましたが、長期間使用しておりますと色々と不満が出てきます。
その点を箇条書きにしてみます。

（１）多くの部分がコード化されていてデータを見ても内容が判らない
コード化されているデータは、競馬場名、曜日、レースグレード、競走種別（２歳戦、３歳戦、３歳以上等）、競走記号（牝馬限定とか見習い騎手戦等）、競走条件（未勝利戦とかオープン戦等）、重量種別（別定戦とかハンデ戦等）、トラックコード（芝とかダート等）、馬場状態（良とか重等）、天候、馬の毛色、性別、所属（関東とか関西等）などがメインで他にもあります。

コード化するメリットですが、データが小さくなるのでデータベースの肥大化には多少貢献できる点と、多国籍語に対応する場合です。
データベースが肥大化するとデータベースのアクセスに影響が出る場合がありますので、これは有利な点です。
ただ、表示をする場合にコードを変換する処理が必要となりますので、コード化されているデータが多いとその分処理が遅れます。
こちらの方が心配です。

多国での使用に対応する場合は日本語に限定しないでコード化しておいた方が便利です。
ただ、競馬ソフトが日本人以外が利用する割合は少ないでしょうから、メリットはほとんど無いと思います。
以上の観点から、私のデータベースでは最初からほとんどの部分をコード化しないで、日本語表記に戻してからデータベースに記録しております。
その方がメリットが大きいと考えています。

（２）レース情報を表示しても出走馬は判らない。
JRA-VANの提供するレース関係のデータは、レース（RACE）という情報です。
この中にはレースの開催日だとかレース内容、天候や単勝人気、通過ラップなど多くの情報が含まれているのですが、なぜか出走馬のデータが提供されません。
恐らくは、木曜日などの枠順が決まっていない時点でのデータの提供のためと思うのですが、そのために出走馬を調べるためには馬毎レース情報（UMA_RACE）から調べる事になります。
ところが、馬毎レース情報はデータ量が最も多いデータの１つで蓄積状態によっては数百万データにも上ります。
表示にストレスを感じるような時間は必要としませんが、それでも瞬時に表示と言う訳にはいきません。

SQLite を使用したデータベースでは、この点を改善するためにレース（RACE）情報中に出走馬のデータも組み込むことにしました。
枠順が発表された時点（通常は金曜日の昼過ぎ）のデータの取り込みでレース（RACE）に馬番別の馬の血統番号（競走馬が固有に所持している）を記録させております。
レースデータもかなり膨大なものですが、馬毎レースデータよりは遥かに少ないために高速なアクセスを期待できます。
レースデータの内容は血統番号なので馬毎レースデータもアクセスする必要がありますが、適切なインデックスを作成しておれば、瞬時の表示も夢ではないと思っております。

（３）競走馬の過去走の表示が遅い
JRA-VAN から提供されるデータには、馬（UMA）と言う情報があって、個々の馬の詳しい内容が判ります。
残念な事に、その馬の過去の走破記録（もしくはその情報）は記載されておりませんので、前述の馬毎レース（UMA_RACE）情報を検索して表示させる事になります。
レースに出走している馬の過去１０走前程度までを全て検索するのは遅く、ストレスを感じる程度の長さ（数秒）と言っても良いぐらいです。

今回作成する SQLite のデータベースには、この問題に対処するために馬（UMA）情報の中に、その競走馬の過去の走破記録の情報を載せる事にしました。
これによって、馬毎レース（UMA_RACE）情報から単純に検索するよりは、数倍の速さで検索する事ができる筈です。
今までは、競馬新聞を作成するためにはストレスを感じる程の時間を必要としましたが、今後はあっという間に印刷が始まるのではないかと期待しております。

参考にSQLite で作成している ●競走馬マスタ（UMA） のデータフォーマットをご覧ください。
データベースの前半の部分は、一般的な競馬データベースの構築ソフトのテーブル内容とほぼ一緒です。
後半の227番目から独自のテーブルを作成しております。
Maesou1〜Maesou15 は、馬情報の中にその馬の過去走（1走前〜15走前）のレースコードを登録しています。
このコードによって、データの検索を高速に行う事が出来るようになります。
レースコードの登録は、JRA-VAN からデータの取り込み時に自動的に行います。

基礎点（Kisoten）は、私が競馬予想に取り入れた馬の基本的な能力を点数化させたもので、レベルの異なる条件でレースを行った場合に、どの程度の能力を発揮できるのかを知る事ができます。
500万条件では圧倒的な能力がある馬でも、重賞競走の場合にはなかなか勝てないような事が基礎点の点数を見る事でも確認する事が出来ます。
レースグレード別の標準偏差値のようなものとお考えいただければ宜しいかと思います。

●データベースに蓄積する内容

どのデータをデータベースに蓄積するのかも重要です。
レース情報や競走馬、騎手、調教師の情報等を蓄積するのは当然ですが、登録するかどうか迷う情報や不要と思われる情報を列挙してみます。

（１）出走予定馬
レースに出走を予定している馬の登録は少し悩みます。
事前に検討する場合には、出走予定馬の確認は不可欠ですが、登録頭数が多いのでデータベースを圧迫します。
又、出走予定の段階で予定馬の全頭数で競馬予想を行うのも適切ではないでしょう。
競馬予想には有用とは思えませんが、競馬のデータベースの意味からは必要と思われますので登録する事にしました。

（２）票数データ
レースでの式別（単勝、複勝、馬連等）の組み合わせ別の発売票数のデータです。
競馬場のレース別、組み合わせ別の売り上げ金額でも調べる必要が無ければ不用なものです。
データ数が膨大ですし、オッズデータも別に提供されておりますので、馬券の購入やデータの分析にも必要とは思えません。
このデータは取り込みを選択出来るようにして、取り込む場合でもデータベースとは切り離してテキストファイル化にする事にしました。

（３）オッズデータ
馬券の購入には欠かせませんので必要なデータですが、これをデータベースに取り込むのは膨大なデータ量だけに避けたい所です。
特に３連単の組み合わせ数は多いので、これだけでもデータの蓄積は止めたいです。
競馬予想に使用するデータとしての有効性には疑問を感じておりますが、オッズを利用した予想方法を好む方もおられますので蓄積する事にしました。
開催当日の時系列のオッズデータも有効性を確認する（インサイダーオッズとか）ためにデータベースと切り離してテキストファイル形式で登録する事にしました。

（４）坂路調教
このデータ程、役に立ちそうで役に立たないデータは無いと思っています。
レース結果と調教データとの傾向が一致する事がありません。
まず問題なのが、調教データの無い競走馬が多い事で調教をしていないのかと思うとそうではなさそうです。
調教データの無い馬が勝利する事も多いですから、調教データを調べる意味がありません。

調教時計が当てにならないのも問題でしょう。
時間の測定は正確でしょうが、調教の馬場によっても違いますし、馬場状態によっても異なります。
何よりも、追い方によって時計はどうにでも変化しますので、良い時計だからと言ってレースでも良い成績を残せるかは関係ありません。
合わせ馬がいるかいないかでも状況は異なりますし、調教では全く走らない馬もおります。

調教回数を見ても参考にはなりません。
びっしり調教を行った方が良い馬もおりますし、そうではない馬（逆効果の馬）もいるようです。
調教で大事なのは時計ではなくて、走っている状態（追われ方、走行姿勢、馬の状態）です。
これは、調教専門の解説サイトの内容を参考にした方が遥かに的確なデータを得る事ができます。

このデータは私は不用だと思っていますが、調教データが無いと気にいらない人も多そうなので登録は行っています。

（５）競走馬市場取引価格
不用なデータだと思いますが、データ量は知れておりますので登録する事にします。

（６）馬名の意味由来
競馬予想を語呂合わせから行っている人以外は不用なデータでしょう。
世の中には雑学を好む人もおりますから、登録だけは行っています。

（７）その他の変更情報
出走取り消しや競走除外、発走時間変更、騎手変更、当日の天候や馬場状態のデータは、本来はデータベースに記録する内容ではないと思っておりますが、多くのデータベース構築ソフトではデータベースの中にテーブルを作成しておりますので、私もそのようにしました。
私の競馬予想ソフトでは、変更情報は変更情報テーブルには記載しないで、直接データベースの該当部分を書き換えております。
これによる利点は、タイマーの自動取り込みによって変更内容が即座に(無意識でも）反映される事です。
変更履歴を残す必要があれば変更用のテーブルに記入する必要がありますが、一般的な用途としては直接記入しても問題が無いと考えております。
数年間この方式で動作をさせておりますが、不都合を感じた事はありません。

●蓄積するデータについて

今回作成した SQLite のデータベースには、前述のデータベースに蓄積する内容の他に根本的に見直した部分があります。
それは、NULL データを積極的に取り入れた点です。
今までも、データベースに記録する内容は、例えば賞金金額などでは6桁から9桁程度のスペースが設けられており、金額が0の場合でも0が6桁から9桁で埋めつくされておりましたので、これを0一個にするなどしてデータベースの肥大化を防いでおりました。
この効果は非常に大きく、JRA-VANからのデータをそのまま記録する場合と比較して6〜７割程度に抑える事が出来ました。
今回は、それを更に進めてデータが無い場合（0の場合なども含めて）は、データを記録しない（NULLにする）事にしたのです。

NULL については、ここでは詳しい説明を避けますが、単にスペースのデータを記録する事とは根本的に異なります。
スペースならデータはあくまでもスペースですが、NULL の場合はスペースではありません。
以前から、NULLを使用した方がデータベースに蓄積する場合は有利なのは判っておりましたが、プログラムの作成が面倒になるので避けておりました。
何某かのデータがあれば、処理の分岐も楽ですが、データが存在するかどうかまで含めるとプログラムが複雑になるばかりでなく、NULL のデータの場合には思いもかけないエラーが発生する事も珍しくありません。
例えばデータがスペースでも、VAL(データ）なら0が還ってきますので、それをデータがあるかどうかの判定にも使えますが、NULL の場合は、NULLの使い方が不正です。のエラーが発生します。
まさか、エラー処理でデータの存在確認をする訳にはいかないでしょう。

NULL を使用したプログラムの場合は、If Not IsNULL(データ）Then のような書き方をする必要があるのです。
（IsNULL コマンドで、True か False かを見る事でデータが NULL かどうかを判定します。）
「馬吉」のプログラムでも、データベースに蓄積されているデータは一切 NULL を含んでいないものとして扱われておりますので、データに NULL を使用した場合には随所でエラーが発生する事になります。
そこまでしてもデータを NULL にするメリットは大きく、十分に NULL 化を行えばデータベースの容量は従来の半分程度にはなるだろうと思っております。
JRA-VAN から提供されるデータ構造は、フラグ関係も多いですから、今までのように0か1かで判定するのではなくて、データが NULL かどうかで判定しますから、チリも積もればの例え通りデータの肥大化を防ぐ事が出来るのです。
データベースの容量は抑えられるだけ抑えた方が全てに渡って（データの記録時でも）プラスになりますので、 従来作成したプログラム手直し部分は増えますが、積極的にNULL化を行う事にしました。

●インデックスの重要性ついて

SQLite のデータベースが作成出来たので、「エクセル競馬予想 馬ちゃん」で動かしてみました。
さぞかし速く動くだろうと胸はワクワクしておりました。
が、しかし。
信じられないほどの遅さです。
１つのレースに出走している馬番の１つを表示するだけで、数秒を要するのです。
今までのアクセスだったら、数秒あれば2､3レースぐらいは表示が終了しています。
競走馬の中から、血統番号で検索して表示させているのですが、2000年からの全ての競走馬を登録しておりますから、数十万頭は登録されているはずです。
それでも、アクセスなら一瞬で表示されました。

SQLite が遅い原因は、インデックスが活用されていない事なのだろうとは薄々感づいておりました。
それまでに、SQLite の関連サイトにこんな記事があるのを見ていたからです。

これまでMS-Access、MySQLなどを使う機会は多々あったのだが、データベースのインデックスに関して、深く考えたことはあまりなかった。
頻繁に検索をかけるカラムにインデックスを作っておくと速くて便利だというくらいの認識だった。
それが今回、300万件を超えるデータを扱ってみてわかったのだが、「適切にインデックスを作成しておかないと、仕事にならない」。
インデックスがあればほぼ一瞬で結果が取り出せるのに対して、それがなければ3時間、しかもその間はPCがほぼ使い物にならない。
普段は数千件のDBしか扱っていなかったので「インデックス作っておくと速いね」くらいの認識で、何時間もレスポンスがなくなるような事態というものをまったく想定できていなかった。
ある意味、DBに関してあやふやな知識でも使えてしまうMS-Accessがよくできているということでもあったのだろうけれど、結局、Accessで処理が困難な件数のDBに直面したところで、「ああ、あの時基礎をきっちりとやっておけば」ということになるのだ．．．そういう事態にならずに一生を過ごす人のほうがはるかに多いのかもしれないが。

記事にもある通り、アクセスの場合は特に意識しなくてもデータベースが影で行ってくれている部分が多いようである。
ある意味、アクセスを使っている場合は甘やかされた環境でデータベースを使用しているとも言えると思う。
確かに、常識的に考えても数十万件のデータから1頭を選んでいるとしたら、数秒は必要だろう。
一瞬で表示される事の方が異常（ありえない事）だったのである。
早速、SQLite のインデックスの活用方法の勉強を始める事にした。

【後記】
遅かったのはやはりインデックスが作成されていなかったためでした。
Set rs = New ADODB.Recordset
sql = "SELECT * FROM UMA_RACE WHERE DataKubun <> '1' AND KettoNum = '" & KettoNum1 & "' ORDER BY KeyCord DESC"
rs.Open sql, Cn
上記のテーブルを開く場合に、UMA_RACE に KettoNum のインデックスが作成されていないとオープンするのに数秒は要しましたが、作成後は瞬時にオープンする事が出来ました。
一般的には、インデックスを作成する事で100倍程度は高速になるようです。
流れるような表示を見た時、SQLite はマイクロソフトアクセス（Access）を越えていると確信しました。
恐るべきインデックスの効果です。

●データベースのブラウザについて

マイクロソフトアクセス（Access）でデータベースを構築した場合は、データベースの中身を見るには、アクセスを使用すれば見る事ができます。
SQLite で作成した場合には、簡単には見る事が出来ません。
SQLite のコマンドラインから確認は出来ますが、使い勝手が悪くてアクセスで慣れた人には使いきれません。
ＧＵＩを利用したフリーソフトも何種類か試して見ましたが、試した範囲では決定的なものは見つける事が出来ませんでした。
私が使用した中では、一番使い勝手や安定しているものを御紹介します。
それは、SQLite データベース・ブラウザ (SQLite Database browser) と呼ばれるソフトです。



上部の SOURCEFORGE PROJECTPAGES をクリックします。



こちらのファイルをダウンロードします。
インストールに問題は無いと思いますので、解説は省略します。
（ソフトにインストーラーは無く、8個の DLL と本体を適当なフォルダに解凍するだけです。）
ソフトを起動してumachan.db を表示している画面です。



テーブルの構造が表示されています。
次にデータベースに登録されている馬（UMA）のデータを表示します。



13万頭の競走馬のデータが登録されておりますので、表示までに結構時間が掛かります。
更に多くのデータ（UMA_RACE等）を表示する場合は、私の環境（WindowsXp） では厳しいようです。

●SQLiteManagerについて

SQLiteがまともに動くようになってくるとデータベースをローカルではなくてサーバーに移動して動かしてみたくなってきました。
サーバに移動して競馬データベースを公開しようなどと考えている訳ではなくて、単なる技術的な興味からです。
JRA-VAN　から得たデータをサーバー上で公開する事は禁止されておりますが、そのデータを使って競馬予想を行ったものを公開する事は大目に見られているようです。
なぜかと言うと、例えJRA-VAN のデータを利用して競馬予想を行っているとしても、そこから基のデータの内容が得られる訳ではありませんし、同じデータを使っても予想結果まで同じになる事は稀です。
サイトに競馬予想が記載されているからと言って、その予想の基になっているデータがどこから得たものかの特定など出来ないので禁止する事は土台無理です。
じゃあ、データベースの公開ではなくて閲覧者が自由にレースを選択して競馬予想が出来るようなプログラムをサイト上に載せるのかと言われると、PHP の知識や経験も不足している私が競馬予想プログラムを作成するのは容易な事ではありません。
PerlやJAVA ならどうかと言われそうですが、私にはもっと敷居が高い存在になります。
今回は言い訳として、サーバーで自由に競馬予想が出来るようになると、私のプログラムを使っていただける人が居なくなるのでやらないのだと言う事にしておきましょう。

私はインターネットサーバーをプロバイダから提供されたものと自宅サーバーの2箇所で運用しております。
競馬の場合は自宅サーバーをメインサイトにしてヤフーのサーバーをミラーサイトにして運用しております。
これは数年前の話ですが、自宅サーバーに外部から侵入されて、内容を書き換えられたため1週間程度自宅サーバーを停止していた事がありました。
その期間に自分のプロバイダーであるヤフーのサイトにホームページを公開していたためにそのようになっています。
最近では自宅サーバーが落ちる事はめったにありませんので、ミラーサイトのヤフーはアクセス数が少なくて閑古鳥が鳴いている状態になっています。
折角、高いお金を払ってジオプラスにアップバージョンを行ったので、広告でも張ってお金を稼ごうかとは思っているのですが、なかなか進みません。
やたら広告ばかりのサイトが目立って嫌な思いをしているので、自分もその仲間入りをする事に躊躇してしまうのです。

余計な話が長くなってしまいましが、SQLite を管理するプログラムにSQLiteManager があります。
超有名なプログラムで、SQLite を使用している人なら誰でも知っていると思われる程知名度は高いようです。
余りにも有名なので、ここではインストール方法などは省略させていただきますが、もし初めての方がおられましたら解説サイトを検索していただきたいと思います。
ただ、ヤフーのサイトには拡張子の関係からだと思いますがすんなりとは導入出来ませんでした。
後で原因を調べて見ようと思っております。
自宅サーバーにはすんなりとインストール出来ましたし、問題なく立ち上がりました。
ただ、問題が発生しました。

データベースの中に記載している日本語の部分が文字化けしてしまうのです。
原因は文字コードにあってEUC で記載してないと文字化けをするようですが、対策は面倒そうな感じです。
サイトで対策方法を調べて見ると、SQLiteManager のメニューの文字全体が文字化けしているのならlang のJapanese.inv.php の10行目と11行目を'utf-8'と'ja-utf-8'に変更すれば良いようなのですが、データの中身はそれでは直りません。
更に調べて見ると、 よくきた blog さんのサイトに解決するためのプログラムコードが書いてありました。
これは秀逸で、今までは日本語は EUC オンリーだったのが、データベースに合わせて EUC と UTF8 を切り替えて使用する事が出来るものでした。
素晴らしいサイトが多いので、私も最近は自分で考えるよりも先に検索ばかりするようになってしまいました。
大変有り難いことなのですが、コピペプログラマーとなってしまった自分が情けないと思います。

Data-Lab は現在 Windows 上でしか動作しませんので、ザーバー上で JRA-VAN からデータの取り込みを行う事は出来ません。
（一般的なサーバーは、Linux で動作しております。）
サーバーにデータベースを構築した場合は、Windows 上で取得したデータを転送する事になります。
そのためには、処理速度の点から専用のWindows パソコンが別に必要になるでしょう。
個人で使用する分には、ネット上のサーバーにデータベースを置いてもメリットは少ない感じがします。
なぜなら、わざわざそんな事をするよりも、パソコン同士でネットを組んだ方が遥かに効率的で通信速度も速いからです。

データ種別

SQLite のデータベースに登録しているデータの種別を記載します。
蓄積系データ

登録データのフォーマット

この資料は、JRA-VAN の ソフトウェア開発キット（SDK）提供コーナー よりダウンロードさせていただいたものを基に作成しております。
データベースの内容の表示項目は、JRA-VAN 提供による資料の書式に沿うように心掛けました。

１．SETUP_TIME

SETUP_TIMEデータは、私が独自に作成したものです。
「エクセル競馬予想　馬ちゃん」のデータベースを作成した時から採用しております。
内容は、JRA-VANから登録したデータの日付情報を記録するためのものです。
この情報がデータベースに必要と思ったのは、環境設定ファイル（iniファイル）に情報を記載していても、実際のデータベースの内容とは異なる場合がありますので、常に正しい情報を得るためです。
私の場合は、プログラムの起動時にデータベースの SETUP_TIME から情報を読み込んで、環境設定ファイルに書き戻して使用しております。
こうする事で、データベースをコピーして使用した場合でも、環境設定ファイルとの整合が取れます。

２．競馬場マスタ

このデータも私が独自に作成したものです。
内容は競馬場の馬場状態をデータで表現しようとしたものですが、研究段階です。
馬場の状態は、競走結果に決定的な影響を与える事が多いと私は考えておりますが、一般的には軽く扱われております。
せいぜい、今日の馬場は内が荒れているかどうか、外に回した方が良く伸びるとか伸びないとか程度です。
これを更に踏み込んで、外を回る事の距離のロスと馬場状態から、有利の不利の程度をデータ的に表現しようとしました。

馬場が悪い場合の競馬予想には特に威力を発揮できると考えているのですが、具体的にデータ化する部分で悩んでおります。
競走馬が走るスペースを１区切りにして影響度を計算しようと思っているのですが、陸上競技のように一区切りの中で馬が走る訳ではありませんし、競走馬がコースのどこを走るのかは、傾向的なもので判断するしかありません。
コース取りの差はレースのペースによる影響が多きいですし、単純なデータとして扱うのは難しいようです。
取敢えずは、スピード指数のコースの基準タイム的なものを記録しておく程度でお茶を濁そうと考えております。
肝心の馬場状態の表示方法ですが、当面は馬場の状態をプログラムで表現したものを人間が見て予想の判断材料にする予定です。
コースの荒れ具合を絵の形で確認できるのは、楽しいのではないでしょうか。

【注記】
スピード指数の基準タイムは、1000万下の条件戦での距離別のタイムを設定しております。
スピード指数の基準タイムの弱点は、レースは常に競走馬が最高のスピード（能力の限界）で走る事を前提にしている点にあって、スローペースで走った場合には条件が低い競走馬のレベルより評価が低くなる場合が多々ある点です。
ターゲットでは、レース毎に基準タイムを設ける事で、このスピード指数の弱点を解決しようとしています。
但し、ターゲットが提供している基準タイムの算出しているデータの根拠は提示されておりませんし、距離に無関係に0.1秒差を１点として競走馬を評価している点にも特に根拠はなさそうです。
更には、条件別の競走の場合にはターゲットでは独自の補正を行っているようですが、この補正方法についても解説は一切ありません。
私自身は、スピード指数の基準タイムにも多くの疑問を感じますし、ターゲットが提供している基準タイムにも多くの疑問を感じております。
その理由は単純で、どちらも結果に結びつかない事の方が余りにも多い事によります。
展開（レースのペース）を無視してレース内容から競走馬の能力を評価する事は、私は無意味（無理がある）であるだけでなく、競馬予想を行う場合に弊害をもたらすと考えております。

３．特別レース（TOKU_RACE）

JRA-VAN から提供される次開催の特別レースの情報データです。
提供データを全て登録しておりますが、更に新規に以下のテーブルを作成しております。
KeyCord：検索用コード（Year ＆ MonthDay ＆ JyoCD＆Kaiji ＆ Nichiji ＆ RaceNum）16桁
JyoMei：競馬場コードを競馬場名に変換したデータ
SyubetuMei：種別コードを変換したデータ

４．特別登録馬（TOKU）

JRA-VAN から提供される次開催の特別レース登録馬の情報データです。
提供データを全て登録しておりますが、更に新規に以下のテーブルを作成しております。
KeyCord：検索用コード（Year ＆ MonthDay ＆ JyoCD＆Kaiji ＆ Nichiji ＆ RaceNum）16桁

５．レース詳細（RACE）

JRA-VAN 提供の全データの他に独自のデータを登録しております。
116番目以降に記載の Kyosoba テーブルがその一つで、レースに出走している競走馬の血統番号を記載しています。
通常出馬表を作成する場合には、馬毎レースデータ（UMA_RACE）からデータを検索して表示しなければなりませんが、馬毎レースデータには数十万のデータが登録されているために、データベースのアクセス時間が必要で瞬時に出馬表を作成する事は出来ません。
競走馬の血統番号が記載している場合は、競走馬データ（UMA）から検索出来ますのでデータ量が少なく（10万前後）高速な検索が可能になります。
しかも、134番目以降にはレース結果の配当情報も記載しておりますので、レース結果を連続して見たい場合などには特に快適さを実感出来ます。

６．馬毎レース情報（UMA_RACE）

JRA-VAN から提供の全てのデータの他に以下のデータを追加しました。
得点（Tokuten）、前走（Zenso）、次走（Jiso）、予想番手（YosoBante）、予想走破タイム（YosoTime）、予想3F上りタイム（YosoAgari）
結果ラップタイム（１〜１２）、予想マーク（YosoMark　１〜４）

７．払戻（HARAI）

JRA-VAN 提供の全データの他に、以下のテーブルを追加しています。
KeyCord：検索用コード（Year ＆ MonthDay ＆ JyoCD ＆ Kaiji ＆ Nichiji ＆ RaceNum）16桁
JyoMei：競馬場名

８．オッズ_単複枠（ODDS_TANPUKUWAKU）

JRA-VAN 提供の全データの他に、以下のテーブルを追加しています。
KeyCord：検索用コード（Year ＆ MonthDay ＆ JyoCD ＆ Kaiji ＆ Nichiji ＆ RaceNum）16桁
JyoMei：競馬場名

９．オッズ_馬連（ODDS_UMAREN）

JRA-VAN 提供の全データの他に、以下のテーブルを追加しています。
KeyCord：検索用コード（Year ＆ MonthDay ＆ JyoCD ＆ Kaiji ＆ Nichiji ＆ RaceNum）16桁
JyoMei：競馬場名

１０．オッズ_ワイド（ODDS_WIDE）

JRA-VAN 提供の全データの他に、以下のテーブルを追加しています。
KeyCord：検索用コード（Year ＆ MonthDay ＆ JyoCD ＆ Kaiji ＆ Nichiji ＆ RaceNum）16桁
JyoMei：競馬場名

１１．オッズ_馬単（ODDS_UMATAN）

JRA-VAN 提供の全データの他に、以下のテーブルを追加しています。
KeyCord：検索用コード（Year ＆ MonthDay ＆ JyoCD ＆ Kaiji ＆ Nichiji ＆ RaceNum）16桁
JyoMei：競馬場名

１２．オッズ_3連複（ODDS_SANREN）

JRA-VAN 提供の全データの他に、以下のテーブルを追加しています。
KeyCord：検索用コード（Year ＆ MonthDay ＆ JyoCD ＆ Kaiji ＆ Nichiji ＆ RaceNum）16桁
JyoMei：競馬場名