0

この質問に対するいくつかの回答が見つかりましたが、私の問題に一致するものはありません。

http://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/ nosql データベースのツリー構造

これらの例のほとんどは、「is a」グラフ階層をモデル化しています。靴は服です。ツリーは型の特殊化に関するものです。

"has a" 関係をモデル化する少数の 1 つは、型をサポートしません。

私の最初の問題は、金融商品のモデル化に由来します。シンプルにするために: http://en.wikipedia.org/wiki/Option_style

説明

各ノードが、2 つの子ノードによって表される資産を交換する権利または義務のいずれかであるツリーを想定します。

例えば。Microsoft 株のヨーロピアン コール オプション: 「私は 2016 年 1 月 10 日、Microsoft 株を 50 ドルで購入する権利 (義務はありません) を持っています」 ==> 交換は $ 現金と株の間です。

しかし、別のコール オプションにコール オプションを設定することもできます。「私は、2015 年 6 月 10 日、上記のオプションを 11 ドルで購入する権利があります (義務ではありません)」

木

ツリーの葉は、ある市場 (株式、債券、レート、上場オプションなど) で上場されている商品、またはそのような商品の集合バスケットでなければなりません。

各ノードは、ほぼすべてのタイプにすることができます。

  1. 経路依存の報われるか否か (アジア、振り返り ...)
  2. 運動タイプ（バミューダ、アメリカン、ヨーロピアン）
  3. プット/コール
  4. ロング/ショート

そのタイプに基づいて非常に異なるパラメーター セットを持つ場合があります。次に例を示します。

  • バミューダの権利行使には一連の日付が必要ですが、それ以外の場合は 1 つの満期日のみが必要です。

そのため、各ノードが非常に異なる性質を持ち、非常に異なるパラメーターを持つ可能性がある "has a" 関係 (バスケット/インデックス集約を含む) を表現するツリーをモデル化する必要があります。しかし、DB構造内のノード間のある種のタイプ継承も反映する必要があります。アメリカのプットオプションは「オプションです」。

制約事項

  1. 予約した商品の価格を設定するのに十分な情報が必要です。指定された DB + 市場データへのアクセス + 価格モデルの選択 ==> 価格
  2. 必要に応じて、ACID の側面がコード レベルで保証されると考える人もいるかもしれません。
  3. 上記がOKである限り、速度は唯一の尺度です

質問

私のオプションは何ですか？ファイルの書き込みやシリアル化、またはあなたが持っているかもしれないどんなクレイジーなアイデアに対しても、私は非常にオープンです。

大きな頭脳のストーミングの大規模なブレインストーミングが必要です。

編集：クリストフに感謝

SQLでの継承のために、私は通常これを行います

CREATE TABLE OPTION ("isin", "name", "emitter","typeId"); "use American type id"
CREATE TABLE AMERICAN_OPTION ("isin","foo1", "foo2");

問題は、その「ダウン リンク」に関するものです。たとえば、基礎となる私のアメリカン オプションは、必ずしも単純なリストされた製品ではありません。

CREATE TABLE ASSET ("uniqueIdentifier,"typeId","name","asset1","asset2");
CREATE TABLE ASSET_TYPE_1 ("uniqueIdentifier","DATA_1",..."DATA_N");
CREATE TABLE ASSET_TYPE_2 ("uniqueIdentifier","DATA_1",..."DATA_N");
CREATE TABLE ASSET_TYPE_1_B ("uniqueIdentifier","DATA_1",..."DATA_N");

....

「資産」はほとんど何でも構いません。これはほとんどの場合に機能しますが、いくつかのトリックが必要です。たとえば、バスケットケースは、クリストフによって次のように設計されている必要があります。たとえば、バスケットのアメリカン オプション、asset1 は現金、asset2 はバスケット タイプで、次のようにモデル化されています。

ASSET( "XYZT12345", "American", "XYZT__1", "XYZT__2", ...[common admin data(e.g.tradedate,valuationCurrency...] )
ASSET( "XYZT__1", "cash", "NULL", "NULL" )
ASSET( "XYZT__2", "basket", "NULL", "NULL" )

CASH_ASSET( "XYZT__1", "10$" )
BASKET_ASSET( "XYZT__2", "Ric_1" )
BASKET_ASSET( "XYZT__2", "Ric_2" )
BASKET_ASSET( "XYZT__2", "Ric_3" )
VANILLA_OPTION_ASSET( "XYZT12345", "MaturityDate", "strikePrice" ); // both european and american fit in there

オプションがバミューダ/カリビアンだったら、おそらくdateSetモデルテーブルが必要だったでしょう

4

1 に答える 1

0

データベースでの「is a」関係のモデル化は、データを正規化することで実現できます。つまり、OPTION テーブルと AMERICAN_OPTION テーブルがある場合、それらは次のようになります。

（私は疑似SQLに切り替えていますが、nosqlでも同じことができます）：

CREATE TABLE OPTION ("isin", "name", "emitter");
CREATE TABLE AMERICAN_OPTION ("isin", "name", "emitter", "foo1", "foo2");

ここでは、これを「AMERICAN_OPTION は OPTION から派生し、追加のメンバー 'foo1' および 'foo2' を持つ」と解釈できます。

または、すべてを 1 つのテーブルに配置し、未使用の列を NULL のままにすることもできます。

「has a」関係のモデル化は、通常、データベース インデックスとそれらの間の関係を作成することによって行われます。

ETF バスケットは、他の商品と「1:n」の関係にあります。NoSQL データベースが何らかの方法で 1:n の関係をサポートしていることを確認してください。多くの NoSQL データベースはそのままではインデックスをサポートしていないため、アプリケーションでこれらの関係をモデル化する必要がある場合があります。関係が複雑すぎない場合、これは通常、大した問題ではありません。詳細については、ウィキペディアで「スター スキーマ」を検索してください。

CREATE TABLE BASKET ("id", "name", "emitter");
CREATE TABLE INSTRUMENT ("id", "name", "emitter");
CREATE TABLE BASKET_TO_INSTRUMENT("etf_id", "instrument_id"); <-- your 1:n relationship

グラフ データベースを使用する場合、この機能の一部はそのまま使用できる可能性がありますが、私はグラフ データベースの経験がありません。しかし、私は彼らがより速いとは思いません。

振り返ってみると、NoSQL データベースのモデリングは SQL データベースのモデリングと変わらないように見えますが、アプリケーション開発者としての作業は他にもあります。

よろしくお願いします、

クリストフ

于 2013-10-11T06:16:13.830 に答える