Dichiariamo un vincolo SQL FK (FOREIGN KEY) per dire che un valore subrow per un elenco di colonne appare sempre altrove come valore subrow per un elenco di colonne che forma un SQL PK (PRIMARY KEY) o UNIQUE NOT NULL. Dichiaralo ogni volta che non è già implicito in altre dichiarazioni. Deve fare riferimento all'elenco di colonne in una PK SQL dichiarata (CHIAVE PRIMARIA) o UNIQUE NOT NULL. Quindi devi dichiararlo nella tabella di riferimento, anche se è già implicito da NOT NULL e un PK contenuto più piccolo o UNIQUE NOT NULL.
Quindi si noti che una PK SQL non è necessariamente una PK nel senso relazionale di essere univoca ma non contenente un insieme di colonne univoco più piccolo, cioè essendo una superchiave non contenente una superchiave più piccola, cioè essendo una superchiave minima/irriducibile, cioè essendo una CK ( chiave candidata).
Qui potrebbe essere necessario sostituire buildingno &roomno FK per uno, (buildingno, roomno) a Room :
CONSTRAINT SESSION_FK12
FOREIGN KEY(BUILDINGNO,ROOMNO) REFERENCES ROOM(BUILDINGNO,ROOMNO)
Questo potrebbe sia appropriato per i significati delle tue tabelle - che in realtà non dai, quindi non possiamo sapere, possiamo solo indovinare. Ad esempio, se buildingno potrebbe anche essere dichiarato PK o UNIQUE NOT NULL in Room, che quando roomno IS NOT NULL è effettivamente coerente con e implica (buildingno, roomno) potrebbe essere dichiarato PK o UNIQUE NOT NULL, forse il tuo FK è giusto ma la tua Room le dichiarazioni sono inadeguate.
Quando un valore subrow per un elenco di colonne viene sempre visualizzato altrove come valore subrow per un elenco di colonne chiamato vincolo IND (dipendenza di inclusione). Non c'è modo di dichiarare un IND non FK in SQL; dobbiamo far rispettare dai trigger. Questo anche potrebbe essere ciò di cui hai bisogno per il tuo design.
Potresti mantenere l'FK da buildingno a Building , ma è implicito nell'FK che suggerisco e nell'FK in buildingno su Room facendo riferimento a Building .
riferimento a parte della chiave primaria composita
