sql-server - 最佳金融工具条款和条件数据库设计(最小与复杂)

Question

我想要设计一个金融工具条款和条件数据库，并且可以看到 2 种可能的解决方案。第一个是我所说的最小设计，我认为它具有最大的灵 active 。第二个涉及拥有一个带有级联更新系统的主数据库到存储每种不同安全类型的更详细信息的子表中。

作为一个例子来说明这些概念。对于最小的设计，我认为只需要 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          XS0000000123 Corp
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 定义证券详细信息更改的生效日期)。唯一的问题是，需要构建一个数据透视类型查询，然后将不同的 AttributeNames 转置为新数据透视表的列名称。 (我不确定正确的术语是什么，但我们可以称之为数据膨胀)。

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

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

如果 AttributeName 对于所有证券都是通用的(名称、股票代码、货币)，这些列将存储在 SecurityMaster 表中。如果工具具有“特殊性”，则会有一个级联更新子表，其中将保存特定的合约详细信息(例如 SecurityBond、SecurityEquityFuture、SecurityEquityOption、SecurityInterestRateFuture，...)

希望您能看到这两种范例。第一张 table 非常紧凑，可以轻松容纳任何安全性。 1 的唯一问题是需要构建动态数据透视表代码，该代码本质上构建将在范例 2 下创建的各个 SecurityType 表。

欢迎任何评论/指针，如果有任何不清楚的地方(或者我没有使用正式的数据库术语)，我们深表歉意。特别是如果有人拥有从范式 1 到范式 2 的 Pivot 代码。

非常感谢和亲切的问候，伯蒂附注经验:使用 Sql Server Express 2-3 个月(在没有软件工程师的公司)。

Answer 1

几个不好的方法:

1. 完整EAV :这是您上面的第一个提案
2. 一些规范化表(ISIN、名称、发行人、货币等)和其余 EAV

我之前担任过这两个角色，它们最终会咬你
EAV 是反模式:One , Two

更好的方法:

Superkey/subtype pattern (所以答案 1)有一个工具表，然后是每种类型的子表:结构性产品、衍生品、债券、股票等:这是上面的第二个选项

每种类型完全独立的表格

使用完全独立的表，您可以通过 View 或非规范化表进行公共(public)数据访问，但我会使用 super 键/子类型模式

另请参阅this SO answer too如何做到这一点(MySQL 但希望你明白)和 on DBA.SE too