Vi erklærer en SQL FK (FOREIGN KEY) begrænsning for at sige, at en underrækkeværdi for en liste med kolonner altid vises andre steder som en underrækkeværdi for en liste over kolonner, der danner en SQL PK (PRIMARY KEY) eller UNIQUE NOT NULL. Erklær det, når det ikke allerede er underforstået af andre erklæringer. Den skal referere til kolonnelisten i en erklæret SQL PK (PRIMARY KEY) eller UNIQUE NOT NULL. Så du skal erklære det i den refererede tabel, selvom det allerede er underforstået af NOT NULLs og en mindre indeholdt PK eller UNIQUE NOT NULL.
Så bemærk, at en SQL PK ikke nødvendigvis er en PK i relationel betydning af at være unik, men ikke indeholde et mindre unikt kolonnesæt, dvs. at være en supernøgle, der ikke indeholder en mindre supernøgle, dvs. være en minimal/irreducerbar supernøgle, dvs. at være en CK ( kandidatnøgle).
Her skal du muligvis erstatte buildingno &roomno FK'er med én, (buildingno, roomno) til Room :
CONSTRAINT SESSION_FK12
FOREIGN KEY(BUILDINGNO,ROOMNO) REFERENCES ROOM(BUILDINGNO,ROOMNO)
Det måske være passende for betydningen af dine tabeller - som du faktisk ikke giver, så vi kan ikke vide det, vi kan kun gætte. F.eks. hvis buildingno kunne også blive erklæret PK eller UNIQUE NOT NULL i lokalet, hvilket når roomno IS NOT NULL er faktisk i overensstemmelse med og indebærer (buildingno, roomno) kunne erklæres PK eller UNIQUE NOT NULL, måske har din FK rigtig men dit Room erklæringer er utilstrækkelige.
Når en underrækkeværdi for en liste over kolonner altid vises et andet sted som en underrækkeværdi for en liste over kolonner, der kaldes en IND (inklusionsafhængighed)-begrænsning. Der er ingen måde at erklære en ikke-FK IND i SQL; vi skal håndhæve med udløsere. Det også kan være det, du har brug for til dit design.
Du kunne holde FK fra buildingno til Building , men det er underforstået af den FK jeg foreslår og FK i buildingno på Room med henvisning til Building .
henvisninger til en del af den sammensatte primærnøgle