2007年02月22日

データベースが重要な訳

しばらくブログを書いていませんでしたが、投資状況はと言うと、未だ方向性もつかず、ぼちぼちとオプションデータベースの設計をしています。

なぜこんなに時間がかかるのか?と言うと、データベース設計の変更は、プログラム開発前に変更する場合と、プログラムの開発後に変更するのでは負担が10倍違うと言われています。またプログラムが開発終了して運用開始後に変更するのは、更に10倍負担が多いとも言われています。これが身にしみているからこそ、データベース設計には十分な時間をかけて行う必要があります。

通常データベースの設計は「運用の分析」から始めて「必要な項目(エンティティ)の抽出」「エンティティ間の関係(リレーション)の整理」「正規化」「安定性解析」「正規化くずし」と行います。ここでいう運用の分析とは、○○さんが△△な業務を行う、ということで、今回の場合は「ユーザがオプション指標Deltaを複数取得してニュートラルした場合の勝率・期待値を計算する」みたいな感じになります。これから想定される「銘柄エンティティ」や「日々のデータエンティティ」「銘柄詳細エンティティ」などを抽出して、それぞれの関係性を1:1, 1:n, m:nで区別して整理します。正規化自体は機械的作業ですからさほど難しいわけではありません。

安定性解析は、将来起こるであろう変更に対して、どのくらい柔軟に対応できるか?ということを調べるためのものです。例えば現在日経225オプションは500円幅ですが、将来100円幅になっても、今設計しているデータベースは対応できるのか?などを調べます。あまりに柔軟に設計しすぎるといたずらにテーブル数が増えてしまいますので、割り切ってガチガチに組むというのも一つの方法です。

一般的にテーブル数が増えすぎることの問題点は、検索速度が落ちたり、プログラムの煩雑化による工数の増加・バグの増加が考えられます。したがって適度に正規化をくずして実践向きのデータベースを構築する「正規化くずし」という手法が使われます。

また他のカラムから算出できる導出項目は極力カラムに入れないようにするのが一般的です。今回の例だと「SQまでの残り日数」は「SQの日付」と「対象日の日付」から算出可能ですので、カラムとして特別に設ける必要はありません。ただし、これらをカラムとして導入することにより、データベース固有の関数の使用を用いることを避けられるだけでなく、毎回計算させるよりもずっと高速なレスポンスを期待できます。導出項目をカラムとして入れることのデメリットは、導出項目の元となる「SQの日付」や「対象日の日付」が変更されるたびに導出項目を更新しなければ同期が取れないことです。

正規化くずしは設計者のポリシーや運用要求によって強く左右されますので、こうしたほうが良い、といった一般的な解はありません。適当なところでプログラマーと折り合いを付けるのがよい気がします。

そんなわけで、シミュレーションを行う前に大真面目にデータベース設計しているわけです。とりあえずエクセルでさっさとシミュレーションすればいい、という意見もあると思いますが、これは直感なのですが、恐らく自分は投資活動では大儲けはできないと踏んでいます(小儲けはできそう)。その代わりシステム開発による定期的な収入や、あるいはシステムそのものの売却で一発逆転を狙う、というのは、投資活動よりも随分と現実的に思えるため、強固なシステム開発を日々めざしております。

自動売買も「収益を度外視すれば」システムとしては相当に安定しているんですが・・・ orz


トラックバックURL

コメントする

名前:
URL:
  情報を記憶: 評価:  顔   星
 
 
 
Recent Comments
Categories
Google Analytics
アクセス解析の決定版
QRコード
QRコード
Recent TrackBacks
livedoor Readerに登録
Syndicate this site
livedoor Blog(ブログ)