WedX - журнал о программировании и компьютерных науках

Трехсторонняя ссылочная целостность — SQL Server 2008

Я создаю базу данных с помощью SQL Server 2008 для хранения цен на ценные бумаги, торгуемые на нескольких рынках.

Для данного рынка все ценные бумаги имеют одинаковый календарь праздников. Однако календари праздников отличаются от рынка к рынку.

Мне нужны следующие четыре таблицы: Market, GoodBusinessDay, Security и SecurityPriceHistory, и я хочу применить их SecurityPriceHistory не содержит строк для рабочих дней, когда рынок, на котором торговалась ценная бумага, был закрыт.

Поля в таблицах следующие:

Рынок: MarketID (PK), MarketName

GoodBusinessDay: MarketID (FK), SettlementDate (пара — PK)

Безопасность: SecurityID (PK), MarketID (FK), SecurityName

SecurityPriceHistory: это вопрос - я предпочитаю SecurityID, SettlementDate, SecurityPrice

Как определить таблицы таким образом и гарантировать, что для каждой строки в SecurityPriceHistory есть соответствующая строка в GoodBusinessDay?

Если бы я добавил столбец для MarketID в SecurityPriceHistory. Я мог представить, как это сделать с двумя внешними ключами (один указывает на Security, а другой указывает на GoodBusinessDay), но это не похоже на правильный способ сделай это.

sql-server referential-integrity foreign-key-relationship
19.05.2011

Ответы:


1

Эта модель должна подойти. Связь между Market и BusinessDay является идентифицирующей, то есть рабочий день не существует вне контекста рынка, к которому он принадлежит.

Точно так же связь между BusinessDay и SecurityPriceHistory является идентифицирующей, как и связь между Security и SecurityPriceHistory.

Это означает, что первичный ключ SecurityPriceHistory составной: security_id, market_id и расчёт_дата.

дубль 1

Это обеспечит соблюдение ограничения, согласно которому каждая ценная бумага может иметь не более одной строки в SecurityPriceHistory для данного рыночного/рабочего дня. Однако он позволяет одной и той же ценной бумаге торговать на нескольких рынках, несмотря на связь ценной бумаги с конкретным рынком: чтобы ограничить это, связь между рынком и ценной бумагой должна быть идентифицирующей, таким образом:

дубль 2

19.05.2011
  • Еще одна вещь, которую следует отметить: превращение отношения «ценная бумага-торги на рынке» в идентифицирующее означает, что это усложняет перемещение ценной бумаги, скажем, с NYSE на NASDAQ, поскольку идентификатор рынка является частью первичного ключа ценной бумаги. Просто кое-что, что нужно иметь в виду. 19.05.2011
  • Это приближается к 4NF и 5NF BTW (я не слишком глубоко задумываюсь об этом...) 19.05.2011
  • Спасибо за предостережение - учитывая фактические ценные бумаги / рынки (такие вещи, как облигации США и европейские облигации, в отличие от акций США, торгующихся на NYSE, и акций США, торгующихся на Nasdaq), я согласен с предположением, что рынок никогда не изменится в течение заданная безопасность. 19.05.2011

    • 2

    SecurityPriceHistory может иметь FK для GoodBusinessDay и НЕТ FK для Market. Вы можете понять рынок, присоединившись к таблице GoodBusinessDay. Мне не очень нравится этот вариант, но он возможен.

    Вы также можете использовать триггер, чтобы проверить наличие правильной записи GoodBusinessDay при вставке/обновлении, иначе отклоните транзакцию.

    19.05.2011

    3

    Я думаю, вам понадобится поле marketID в таблице securityPriceHistory, предполагая, что один и тот же securityID может быть продан на разных рынках в один и тот же день goodBusinessDay.

    Настроить его так, как вы думаете, это нормально. У вас есть родитель, двое родственных детей, потом внук, у которого есть отношения с обоими детьми.

    Даже если ценная бумага может быть продана только на одном рынке, я бы все же включил marketID в таблицу securityPriceHistory с двумя составными FK, MarketDay и MarketSecurity. Так понятнее, имхо.

    19.05.2011
  • Данный SecurityID всегда торгуется на одном и том же MarketID (это не многие ко многим). 19.05.2011
    • Новые материалы
    Как проанализировать работу вашего классификатора?
    Не всегда просто знать, какие показатели использовать С развитием глубокого обучения все больше и больше людей учатся обучать свой первый классификатор. Но как только вы закончите..
    Работа с цепями Маркова, часть 4 (Машинное обучение)
    Нелинейные цепи Маркова с агрегатором и их приложения (arXiv) Автор : Бар Лайт Аннотация: Изучаются свойства подкласса случайных процессов, называемых дискретными нелинейными цепями Маркова..
    Crazy Laravel Livewire упростил мне создание электронной коммерции (панель администратора и API) [Часть 3]
    Как вы сегодня, ребята? В этой части мы создадим CRUD для данных о продукте. Думаю, в этой части я не буду слишком много делиться теорией, но чаще буду делиться своим кодом. Потому что..
    Использование машинного обучения и Python для классификации 1000 сезонов новичков MLB Hitter
    Чему может научиться машина, глядя на сезоны новичков 1000 игроков MLB? Это то, что исследует это приложение. В этом процессе мы будем использовать неконтролируемое обучение, чтобы..
    Учебные заметки: создание моего первого пакета Node.js
    Это мои обучающие заметки, когда я научился создавать свой самый первый пакет Node.js, распространяемый через npm. Оглавление Глоссарий I. Новый пакет 1.1 советы по инициализации..
    Забудьте о Matplotlib: улучшите визуализацию данных с помощью умопомрачительных функций Seaborn!
    Примечание. Эта запись в блоге предполагает базовое знакомство с Python и концепциями анализа данных. Привет, энтузиасты данных! Добро пожаловать в мой блог, где я расскажу о невероятных..
    ИИ в аэрокосмической отрасли
    Каждый полет – это шаг вперед к великой мечте. Чтобы это происходило в их собственном темпе, необходима команда астронавтов для погони за космосом и команда технического обслуживания..
    Для любых предложений по сайту: [email protected]