最好的金融工具条款和条件数据库设计（最小或复杂）

我想设计一个金融工具条款和条件数据库，可以看到2个可能的解决方案。首先是我所说的最小的设计，我认为它具有最大的灵活性。第二种方法是将具有级联更新系统的主数据库放入存储每种不同安全类型的更精细细节的子表中。最好的金融工具条款和条件数据库设计（最小或复杂）

举一个例子来说明这些概念。对于最小的设计，我认为只需要4列。此表我看到的是最多才多艺的衍生金融工具，应该很容易通过包括被纳入新的AttibuteName的

UpdateDate   SecurityID AttributeName AttributeValue 
----------------- ----------- --------------- --------------- 
09/12/2011 18:01 1   Name   HSBC Plc 
09/12/2011 18:01 1   Ticker   HSBA LN Equity 
09/12/2011 18:01 1   SecurityType Equity 
09/12/2011 18:01 1   Currency  GBP 
09/12/2011 18:01 1   Country   UK 
11/12/2011 12:23 2   Name   RBS 6% 15-Mar-2015 
11/12/2011 12:23 2   Ticker   XS000000Corp 
11/12/2011 12:23 2   SecurityType Bond 
11/12/2011 12:23 2   Currency  EUR 
11/12/2011 12:23 2   Country   UK 
11/12/2011 12:23 2   Coupon   6% 
11/12/2011 12:23 2   Maturity  15-Mar-15 
11/12/2011 12:23 2   CouponFreq  2

虽然大多数金融工具不改变它们的性质，这种方法确实允许有障碍触发对奇异衍生品可以很容易地改变，因为当触发事件改变安全特征时，可以在稍后的日期更改SecurityType。此方法还保留了保留的证券持有者的“旧”特征（UpdateDate定义了证券持有人细节更改的生效日期）。唯一的问题是需要构建一个Pivot Type Query，然后将不同的AttributeNames转换为新的Pivot Table的列名称。（我不确定正确的术语是什么，但让我们称之为膨胀数据）。

这是我如何看第二个解决方案的一瞥。

Name  Ticker   SecurityType SecurityID  Currency Country 
--------- --------------- ------------ ----------  -------- ------- 
HSBC Plc HSBA LN Equity Equity   1    GBP   UK

哪里的AttributeName的通用于所有证券（姓名，股票代码，货币），这些列将被存储在一个SecurityMaster表。当仪器有“perculiarities”，会有一个级联更新子表，其中的具体合同的细节将举行（例如SecurityBond，SecurityEquityFuture，SecurityEquityOption，SecurityInterestRateFuture，...）

希望你能看到2个范式。第一张桌子非常小巧，容易安装。 1的唯一问题是需要构建Dynamic Pivot表代码，该代码实质上构建了将在范例2下创建的单个SecurityType表。

任何评论/指针都会受到欢迎，并且如果有任何不明（或者我没有使用过正式的DB术语）。特别是如果某人有Pivot代码从范例1到范例2。

非常感谢和亲切的问候， Bertie p.s.经验：使用Sql Server Express 2-3个月（在没有软件工程师的公司中）。

来源

2011-12-19 Bertie

有一个alterantive - 你认为使用XML字段存储XML某些领域？ ;）你可以拥有不同的模式并扩展它们，其中qerying比EAV模型更快。 – TomTom 2011-12-19 19:20:56

我不会将此作为答案发布，因为上下文似乎明确限于SQL Server（并且我已经提出了其中一个答案），但您是否承诺使用关系存储？关系存储这些数据的困难在于关系（表格）本身很难定义，很大并且经常变化（新的工具类型）。调查NoSQL替代品可能更有意义，例如RavenDB，MongoDB。请参阅http://martinfowler.com/bliki/DatabaseThaw.html获取一些高层次的动机。 – 2011-12-20 07:51:07

几个可怜的途径：

全部上EAV：这是你上面
第一提案中的一些规范化的表（ISIN，名称，发行人，货币等），其余EAV

我已经在以前的角色工作过，他们会最终咬你
EAVs是反模式：One，Two

点

更好的方法：

Superkey/subtype pattern（SO回答1）与仪器表然后子表对于每种类型：结构化产品，衍生物，债券，共享等：这是您第二选择上述每种类型

完全分离表采用全独立的表，你可以有通过视图或去归一化表中的通用数据访问，但我会用超密钥/亚型模式去

而且小号ee值this SO answer too对于如何做到这一点（MySQL，但希望你的想法）和on DBA.SE too

来源

2011-12-19 18:54:38 gbn

你的第一种方法被称为EAV data model，而第二个是有规律的关系模型。 EAV是一个开放模式数据模型，它为您定义新实体（您的案例中的证券）或扩展现有实体提供了更大的灵活性。但是，因为您无法在动态枢轴表上创建索引，所以对于大型数据集上的复杂查询，性能会很差。

另外，你可以为每个实体的数据透视表的物化视图，并在其上创建索引。但是每当一个实体发生变化时，你将不得不重建物化视图。

来源

2011-12-19 19:00:24 Raihan

最好的金融工具条款和条件数据库设计（最小或复杂）

回答

相关问题