При обсуждении реляционной модели используются несколько разные понятия FK (внешний ключ) и ограничения FK, а в SQL используются другие. Не имеет значения, в каких отношениях / таблицах NF (нормальные формы) находятся.
Обычно в реляционной модели мы говорим, что существует ограничение FK из набора атрибутов в одном отношении (значение, основание или выражение), ссылающееся на этот набор в другом отношении, когда значения каждого атрибута набора в ссылочном отношении должны появляться под ним в указанное отношение и набор атрибутов - это CK (ключ-кандидат) в указанном отношении.
(В SQL FK таблицы ссылается на набор, объявленный как PK (первичный ключ) или UNIQUE. Это более или менее то, что мы могли бы назвать реляционным внешним суперключом, ссылающимся на суперключ, а не на CK, а SQL PK более или менее является superkey. Но на самом деле нет смысла говорить о суперключе или CK в SQL, и данный реляционный термин обычно означает другое в SQL.)
Мы называем эталонный набор FK. Связанное ограничение также небрежно называется FK. Мы объявляем достаточные ограничения FK, поэтому, когда одни, которые мы объявляем, удерживаются, другие также должны удерживаться.
Чтобы использовать базу данных (интерпретировать или обновлять), нам нужно знать, какие строки должны входить в каждое базовое отношение в данной ситуации. Чтобы определить ограничения (суперключи, CK, FK и т. Д.), Нам также необходимо знать, какие возможные значения каждая база должна содержать в зависимости от того, какие ситуации могут возникнуть.
Бронирование (идентификатор бронирования, номер комнаты, leadGuestID, guest2ID, guest3ID, [...])
Гость (guestID , [...])
Предположительно значения для каждого из leadGuestID, guest2ID и guest3ID в Reservation должны отображаться как значение в Guest guestID, которое вы показываете как CK гостя. Если это так, то выполняются следующие ограничения FK:
Reservation (leadGuestID) references Guest (guestID)
Reservation (guest2ID) references Guest (guestID)
Reservation (guest3ID) references Guest (guestID)
Re FK при нормализации:
При нормализации к более высоким NF мы заменяем базовое отношение множественными его проекциями. Таким образом, исходные компоненты & имеют одинаковый набор значений для каждого атрибута. Таким образом, для каждого CK компонента каждый другой компонент с этими атрибутами должен иметь под собой одни и те же подгруппы. Таким образом, каждый раз, когда все атрибуты CK компонента появляются в другом компоненте, в другом компоненте появляется FK для этого CK. Когда два компонента имеют заданный набор как CK, существуют FK в обоих направлениях.
Точно так же, если было ограничение FK от оригинала к CK некоторой базы, тогда каждый компонент со ссылочными атрибутами имеет ограничение FK для этой базы. Аналогично, если существует FK от некоторой базы к оригиналу, тогда для каждого компонента с атрибутами CK оригинала в качестве CK существует ограничение FK от базы к этому CK. Даже если компонент имеет только некоторые атрибуты ссылочного или ссылочного набора своего оригинала в ограничении FK с базой, компонент может иметь ограничение FK с этой базой, включающее подмножества этого предшествующего FK.
Когда вы заменяете базу компонентами, вы теряете FK, связанные с базой, поэтому, помимо добавления объявлений для новых FK выше, вам, возможно, придется добавить другие объявления для FK, которые подразумевались потерянными.
PS В относительном смысле PK - это некий CK, который вы решили назвать PK; PK не имеют значения для FK или нормализации. В SQL PK - это просто UNIQUE NOT NULL, который вы решили назвать PK.
person
philipxy
schedule
22.02.2018
