Ние декларираме ограничение на SQL FK (FOREIGN KEY), за да кажем, че стойност на подред за списък от колони винаги се появява другаде като стойност на подред за списък с колони, който формира SQL PK (PRIMARY KEY) или UNIQUE NOT NULL. Декларирайте го винаги, когато вече не се подразбира от други декларации. Той трябва да препраща към списъка с колони в деклариран SQL PK (PRIMARY KEY) или UNIQUE NOT NULL. Така че трябва да декларирате това в референтната таблица, дори ако това вече се подразбира от NOT NULL и по-малък съдържащ се PK или UNIQUE NOT NULL.
Така че имайте предвид, че SQL PK не е непременно PK в релационния смисъл на това, че е уникален, но не съдържа по-малък уникален набор от колони, т.е. е суперключ, който не съдържа по-малък суперключ, т.е. е минимален/нередуцируем суперключ, т.е. е CK ( кандидат ключ).
Тук може да се наложи да замените buildingno &roomno FKs по един, (buildingno, roomno) до Room :
CONSTRAINT SESSION_FK12
FOREIGN KEY(BUILDINGNO,ROOMNO) REFERENCES ROOM(BUILDINGNO,ROOMNO)
Това може да са подходящи за значенията на вашите таблици - които всъщност вие не давате, така че не можем да знаем, можем само да гадаем. Например ако buildingno може също да бъде обявено за PK или UNIQUE NOT NULL в Room, което, когато roomno IS NOT NULL всъщност е в съответствие с и предполага (buildingno, roomno) може да бъде обявен за PK или UNIQUE NOT NULL, може би вашият FK е правилен но вашата Room декларациите са неадекватни.
Когато стойност на подред за списък с колони винаги се появява другаде като стойност на подред за списък с колони, това се нарича ограничение IND (зависимост от включване). Няма начин да декларирате не-FK IND в SQL; трябва да наложим чрез тригери. Това също може да е това, от което се нуждаете за вашия дизайн.
Можете да запазите FK от buildingno до Building , но се подразбира от FK, който предлагам, и FK в buildingno в Room препращане към Building .
позоваване на част от съставния първичен ключ
