我正在开发一个财务应用程序,为一堆证券进行情景分析。 “场景”非常直接,它们采取某些输入(在我的情况下,特别是两个,比如A和B)和“震惊”它们(即乘以10%,20%,30%等)然后计算输出(我有大约20个不同的输出指标)。
这导致了一个4-d表,其中:
我想将此表保存到数据库(oracle)中。我这样做的方式是有2个表:
Table S
表示输入的冲击水平(百分比)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
的{4}表格展平为(security_id, A_shock_id, B_shock_id)
A_shock_id
和B_shock_id
为Table S
的FK。这种方式的明显缺点是,如果我想添加其他可电击输入(因为震动的输入被硬编码为列),它就不灵活。
是否有更灵活/标准的方式来表示此类数据?或者这是规范化数据库的限制吗?
答案 0 :(得分:3)
这是关系数据库的限制或特征,这绝对是一个悬而未决的问题。但是,是的,关系数据库旨在将“已知”数据映射到具有它们之间关系的表/集。涉及关系数据库的大多数项目都是从数据建模开始,作为流程中的正式或非正式步骤。
您构成的问题很容易映射到关系技术。你太注重结果的输出了。您似乎有两种类型的输入:
20个输出指标。
您应该以与输出指标相同的方式对可调参数进行编码,作为具有不同列的表。参数集表将以两列开头:Shock_A和Shock_B。我还会包含一个“类型”列,因此您可以准确地指出这两个参数。添加其他变量就像在此表中添加列一样简单。
这种结构不是纯粹的标准化。一种关系很差地映射到大多数SQL引擎的关系是一种关系。参数集就是这样的一个例子。具有不同参数的“类型”列是表示此结构的适当方式。
答案 1 :(得分: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
...
这样,您可以处理的输入组合和输出数量没有限制,您可以轻松添加新的输入类型,它们的组合和输出,而无需修改您的模式。