0

私は、一連の証券のシナリオ分析を行う金融アプリケーションを開発しています。「シナリオ」は非常に単純で、特定の入力（私の場合、特にAとBの2つ）を受け取り、それらを「ショック」（つまり、10％、20％、30％などを掛ける）してから計算します。出力（約20の異なる出力メトリックがあります）。

これにより、次の4次元テーブルが作成されます。

  1. x軸は入力Aの衝撃です（10％A、20％A、30％Aなど）
  2. y軸は入力Bの衝撃です（10％B、20％B、30％Bなど）
  3. z軸は20の異なる出力メトリックです
  4. w軸は異なる証券です

このテーブルをデータベース（oracle）に永続化したいと思います。私がこれを行った方法は、2つのテーブルを持つことでした：

  1. Table S入力のショックレベル（パーセント）の場合
  2. Table Oセキュリティと出力

各テーブルは次のようになります。

 Table S
 -------------------------
 shock_id    shock_value
 0           0%
 1           10%
 2           20%
 3           30%
 4           40%
 ...   ...

 Table O
 --------------------------
 security_id   A_shock_id   B_shock_id   output_1   output_2 
 1             0            0            1.2        2.3
 1             1            0            1.34       3.52
 1             2            0            2.4        3.98
 1             3            0            3.42       5.31
 1             4            0            23.2       133.1
 1             0            1            2.2        32.1
 1             0            2            23.1       4.2
 1             0            3            ...        ...
 ...           ...          ...          ...        ...

Table O基本的に、PKが(security_id, A_shock_id, B_shock_id)どこにA_shock_idありB_shock_id、FKがである4次元テーブルをフラット化しましたTable S。この方法の明らかな欠点は、他のショック可能な入力を追加したい場合は柔軟性がないことです（ショックを受けた入力は列としてハードコーディングされているため）。

このようなデータを表現するためのより柔軟で標準的な方法はありますか？それとも、これは正規化されたデータベースの制限ですか？

4

2 に答える 2

3

これがリレーショナル データベースの制限なのか機能なのかは、明らかに未解決の問題です。しかし、そうです、リレーショナル データベースは、「既知の」データをそれらの間の関係を持つテーブル/セットにマップすることを目的としています。リレーショナル データベースを含むほとんどのプロジェクトは、プロセスの公式または非公式のステップとして、データ モデリングから始まります。

あなたが提起する問題は、リレーショナル テクノロジに簡単にマッピングできます。あなたは結果の出力に固執しすぎています。次の 2 種類の入力があるようです。

  • 証券
  • 調整可能なパラメータ

および 20 の出力メトリック。

異なる列を持つテーブルとして、出力メトリックを行うのと同じ方法で、調整可能なパラメーターをエンコードする必要があります。パラメータ セット テーブルは、Shock_A と Shock_B の 2 つの列で始まります。「タイプ」列も含めて、これら 2 つのパラメーターを正確に期待できるようにします。変数を追加するのは、このテーブルに列を追加するのと同じくらい簡単です。

この構造は純粋に正規化されたものではありません。ほとんどの SQL エンジンに適切にマッピングされない関係のタイプの 1 つは、1 対 1 の関係です。パラメーター セットは、この例です。この構造を表すには、さまざまなパラメーターを持つ「タイプ」列が適切な方法です。

于 2012-12-26T16:14:23.863 に答える
1

別の解決策は、スキーマを完全に正規化し、InputTypes列Idと。を含むテーブルを使用して入力タイプを分類することですDescription。あなたの場合、テーブルは次のように表示されます。

Table InputTypes
-----------------------
Id   Description
0    A
1    B
...

別の表ShockCombinationsでは、次のようなさまざまな衝撃の組み合わせがあります。

Table ShockCombinations
-----------------------------
Id InputType_Id ShockValue
1  0            10%
1  1            20%
2  0            0%
2  1            10%
....

表OutputTypesでは、さまざまな出力タイプを使用できます。

Table OutputTypes
-----------------------------
Id Description
1  Output1
2  Output2
....

このように、テーブルOは次の構造を持つことができます。

Table O
--------------------------
security_id   ShockCombination_id   OutputType_id Values 
1             1                     1             1.2
1             1                     2             2.3
1             2                     1             1.34
1             2                     2             1.77
...

このように、処理できる入力の組み合わせと出力の数に制限はなく、スキーマを変更することなく、新しい入力タイプ、それらの組み合わせ、および出力を簡単に追加できます。

于 2012-12-26T16:21:29.090 に答える