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

时间:2011-12-19 18:30:28

标签: sql-server sql-server-2008 sql-server-2005 database-design pivot

我希望设计一个金融工具条款和条件数据库,并且可以看到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          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定义了证券的详细信息更改的生效日期)。唯一的问题是需要构建一个Pivot Type Query,然后将不同的AttributeNames转换为新的Pivot Table的列名。 (我不确定正确的术语是什么,但我们称之为膨胀数据)。

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

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

如果AttributeName是所有证券(Name,Ticker,Currency)共有的,那么这些列将存储在SecurityMaster表中。当工具具有“特殊性”时,会有一个级联更新子表,其中将保存特定的合同细节(例如SecurityBond,SecurityEquityFuture,SecurityEquityOption,SecurityInterestRateFuture,......)

希望你能看到2个范例。第一张桌子非常紧凑,可以轻松容纳任何安全性。 1的唯一问题是需要构建Dynamic Pivot表代码,该代码基本上构建将在范例2下创建的各个SecurityType表。

如果有任何不明确的地方(或者我没有使用正式数据库术语的地方),任何评论/指示都会受欢迎并道歉。特别是如果某人有Pivot代码从范例1到范例2。

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

2 个答案:

答案 0 :(得分:3)

几种不好的方式:

  1. EAV完整:这是您上面的第一个提案
  2. 一些规范化表格(ISIN,名称,发行人,货币等)和其余的EAV
  3. 我曾在之前的职位上工作,他们最终会咬你 EAV是反模式:OneTwo

    更好的方式:

    1. Superkey/subtype pattern(SO回答1)带有一个工具表,然后是每种类型的子表:结构化产品,衍生产品,债券,股份等:这是您上面的第二个选择
    2. 每种类型完全独立的表格
    3. 使用完整的单独表格,您可以通过视图或非规范化表格访问公共数据,但我会使用超级键/子类型模式

      另请参阅this SO answer too了解如何操作(MySQL但希望您明白这一点)和on DBA.SE too

答案 1 :(得分:1)

您的第一种方法称为EAV data model,而第二种方法是常规关系模型。 EAV是一种开放式架构数据模型,它为您定义新实体(在您的案例中为证券)或扩展现有实体提供了更大的灵活性。但是,由于无法在动态枢轴表上创建索引,因此对于大型数据集上的复杂查询,性能将非常差。

或者,您可以为每个实体的数据透视表创建实体化视图,并在其上创建索引。但每次实体更改时,您都必须重建物化视图。