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

Question

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

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

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

Поля в таблицах:

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

GoodBusinessDay: MarketID (FK), SettlementDate (пара является ПК)

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

SecurityPriceHistory: это вопрос - мое предпочтение SecurityID, SettlementDate, SecurityPrice

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

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

Answer 1

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

Аналогично, связь между BusinessDay и SecurityPriceHistory идентифицируеткак отношение между Security и SecurityPriceHistory.

Это означает, что первичный ключ SecurityPriceHistory является составным: security_id, market_id и урегулирование_date.

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

Answer 2

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

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

---

Даже если безопасность может быть продана только на одном рынке, я все равно включил бы marketID в securityPriceHistory.таблица, с двумя составными FKs, MarketDay и MarketSecurity.Проще, ИМО.

Answer 3

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

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