Разработка базы данных по условиям предоставления финансовых инструментов (минимальная или сложная) - PullRequest
Новая
       16

Разработка базы данных по условиям предоставления финансовых инструментов (минимальная или сложная)

4 голосов
/ 19 декабря 2011

Я хотел бы разработать базу данных условий финансовых инструментов и увидеть 2 возможных решения. Первый - это то, что я называю минимальным дизайном, который я считаю наиболее гибким. Второе включало бы наличие базы данных Master с каскадной системой обновлений в подтаблицы, в которых хранятся более мелкие детали каждого отдельного типа безопасности.

В качестве примера для иллюстрации этих понятий. Я думаю, что для минимального дизайна нужны только 4 колонки. Эта таблица, которую я считаю наиболее универсальной, поскольку производные инструменты должны быть легко включены путем включения нового AttibuteName's 

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 определяет дату вступления в силу изменения данных секьюрити). Единственная проблема в этом заключается в том, что нужно будет создать запрос сводного типа, в котором отдельные имена атрибутов затем будут транспонированы в имена столбцов новой сводной таблицы. (Я не уверен, что является правильным термином, но назовем его надувающим данные).

Это проблеск того, как я вижу второе решение. 

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

Если AttributeName являются общими для всех ценных бумаг (имя, тикер, валюта), эти столбцы будут храниться в таблице SecurityMaster. Там, где инструменты имеют «особенности», будет каскадное обновление таблицы, в которой будут храниться конкретные детали контракта (например, SecurityBond, SecurityEquityFuture, SecurityEquityOption, SecurityInterestRateFuture, ...)

Надеюсь, вы сможете увидеть 2 парадигмы. Первый стол очень компактен и легко вмещает любую охрану. Единственная проблема, связанная с 1, состоит в том, что нужно будет создать код таблицы Dynamic Pivot, который по существу создает отдельные таблицы SecurityType, которые будут создаваться в соответствии с парадигмой 2.

Любые комментарии / указатели будут приветствоваться и приносить извинения, если что-то неясно (или если я не использовал формальную терминологию БД). Особенно, если у кого-то есть Pivot-код для перехода от парадигмы 1 к парадигме 2.

Большое спасибо и наилучшие пожелания, Берти постскриптум Опыт работы: 2-3 месяца работы с Sql Server Express (в компании без инженеров программного обеспечения).

Ответы [ 2 ]

3 голосов
/ 19 декабря 2011

Несколько плохих способов:

  1. Полный EAV : это ваше первое предложение выше
  2. Некоторые нормализованные таблицы (ISIN, Имя, Эмитент, Валюта и т. Д.) И остальные EAV

Я работал над обеими ролями в предыдущих ролях, и в конце концов они вас укусят
EAV - это анти-паттерны: Один , Два

Лучше:

  1. Шаблон суперключа / подтипа (SO ответ 1) с таблицей инструментов, а затем дочерней таблицей для каждого типа: структурированный продукт, деривация, облигация, доля и т. Д. - это ваш второй вариант выше
  2. Полностью отдельные таблицы для каждого типа

С полностью отдельными таблицами вы можете иметь общий доступ к данным через представление или денормализованную таблицу, но я бы пошел с шаблоном Superkey / subtype

Также см. этот ответ SO тоже о том, как это сделать (MySQL, но, надеюсь, вы поняли) и на DBA.SE тоже

1 голос
/ 19 декабря 2011

Ваш первый подход известен как Модель данных EAV , тогда как второй - это регулярная реляционная модель.EAV, являясь моделью данных открытой схемы, обеспечивает большую гибкость для определения новых объектов (в вашем случае - ценных бумаг) или расширения существующих.Но поскольку вы не можете создавать индексы для динамических сводных таблиц, производительность будет сложной для сложных запросов к большим наборам данных.

В качестве альтернативы вы можете создать материализованные представления для сводных таблиц каждой сущности и создать для них индексы.Но каждый раз, когда сущность изменяется, вам придется перестраивать материализованное представление.

...