2011-12-05 2 views
0

異なるデータポイントが潜在的に異なる属性を持つ多量の金融時系列データを格納する必要があります。異種属性を持つ財務時系列データに最適なデータベース技術は何ですか?

たとえば、株式とオプションを含む時系列の金融商品をデータベースに保存する必要がある状況を考えてみましょう。株式とオプションの両方は、任意の時点で価格を持っていますが、オプションにはグリックス(デルタ、ガンマ、ベガ)などの追加属性があります。

ここではリレーショナルデータベースが最も適しているようです。属性ごとに列を作成し、未使用の属性をNULLに設定します。上の例では、株式を表すレコードの場合は列の一部のみを使用し、オプションの場合は他の列を使用します。

このアプローチの問題は、非常に非効率的で(多数のNULLを格納することになります)、非常に柔軟性がない(属性を追加または削除するたびに列を追加または削除する必要がある)ということです。

すべての属性を縦型テーブル(Key-Name-Value)に格納する方法もありますが、すべての属性を安全でないものにする(たとえば、すべて文字列として格納するなど) 。

私が考えた別の選択肢は、属性をXML文書として時系列表の単一の列に格納することです。私はこのアプローチをテストしましたが、パフォーマンスの観点からは実用的ではありません。より多くの時系列レコードの属性を抽出する場合は、各行のXML解析が遅すぎます。

NoSQLとRDBMSの組み合わせで、キー・タイムスタンプ・ペアはリレーショナルの表形式データベースの行のように動作しますが、すべての属性は行レベル・バッグに格納され、それぞれに高速アクセスできます。

このようなシステムを知っている人はいますか?私が記述しているデータの種類を格納するための他の提案はありますか?

+0

ヌルはデータベース内にスペースをとらないため、効率的ではありません。たとえば、属性/属性グループごとのテーブルなどを考えましたか?それは垂直ではなくクエリ時間を短縮し、何かを追加したい場合には、おそらく使用中のテーブルを変更する必要はありません。 – Ben

+0

EAVテーブルは、型の安全性、並べ替え/検索のためにひどいものです(インデックス内で通常は連続しているものはパフォーマンスを損なうことはありません)。外部キー関係を(意味を持って)強制することも不可能です - あなたは 'key'-'name'カラムをキーオフすることができますが、**値が有効であることを要求することができません。あなたが良い、_eventually_何かが起こるだろう。特に私には分かりませんが、私はハイブリッドシステムであることを見たと思っていました。さもなければ、私は提案されるようにマスター/子テーブルの方に向かうだろう。 –

答えて

1

別のオプションです。 類似したオブジェクトの属性の関連テーブルを持つマスタテーブル(継承を伴うオブジェクト指向)。マスターテーブルのプライマリキーに基づいて、関連するプライマリキーとしてのマスタとサブタブ間の関係が1-1になります。

+0

属性または属性グループ(master-child)ごとに別々のテーブルが存在することは確かですが、クエリを管理する複雑さが大幅に増加します。これは、それぞれの属性(すべての属性のLEFT JOIN) 。確かに動作しますが、理想的ではありません。 私はリレーショナルデータベースでこれを処理するさまざまな方法を認識しています。しかし、RDBMSはこの特定のケースでは間違ったツールであり、誰かが何か違うものを見つけたのか不思議に思っていました。 –

+0

あなたはかなり正しいです。私がタイトルを再読していたら、私は答えなかっただろう...しかし、私は質問を見て、見た:私は記述しているデータの種類を格納するための他の提案はありますか?よく考えてみてください。良い、偉大な、または理想的ではありません。それはもっともらしい。 – xQbert

2

"financial_instruments"を使用して、すべての金融商品に共通の情報を格納します。ストックにのみ適用される属性を格納するには、「ストック」を使用します。オプションにのみ適用される属性を格納するための "options"。

create table financial_instruments (
    inst_id integer primary key, 
    inst_name varchar(57) not null unique, 
    inst_type char(1) check (inst_type in ('s', 'o')), 
    other_columns char(1), -- columns common to all financial instruments 
    unique (inst_id, inst_type) -- required for the FK constraint below. 
); 

create table stocks (
    inst_id integer primary key, 
    inst_type char(1) not null default 's' check (inst_type = 's'), 
    other_columns char(1), -- columns unique to stocks. 
    foreign key (inst_id, inst_type) references financial_instruments (inst_id, inst_type) 
); 

create table options (
    inst_id integer primary key, 
    inst_type char(1) not null default 'o' check (inst_type = 'o'), 
    other_columns char(1), -- columns unique to options; delta, gamma, vega. 
    foreign key (inst_id, inst_type) references financial_instruments (inst_id, inst_type) 
); 

"financial_instruments"を各サブタイプと結合する更新可能なビューを作成することができます。アプリケーションコードは単にビューを使用できます。

すべての金融商品に関する関連情報を格納する追加のテーブルは、 "financial_instruments" "inst_id"への外部キー参照を設定します。株式だけに関する関連情報を掘り起こす表は、 "株式"への外部キー参照を設定します。 "inst_id"。

+0

理にかなっていますが、あなたは自分をコーナーに描いているように感じています(大きなものでも、私は認めます:-))。結局のところ、異なる株式レコードが異なる属性(例えば、海外対国内株式)を持つことも可能です。それは良いが、それでも理想的ではない。 このタイプのシナリオを扱う非RDBMS技術があるかどうかは疑問です。 –

+0

次に、株価テーブルを "サブタイプ"し、そこにあるすべての株式に属性を共通にし、新しいテーブル "foreign_stocks"に外国株に固有の属性と新しい "domestic_stocks"テーブルに国内株式に固有の属性を入れます。非RDBMSテクノロジの調査を開始する前に、SQLデータベースの最初の動作を理解することをお勧めします。そうでなければ、あなたはもう一方を選択するための健全な基礎を持っていません。 –

関連する問題