Lär dig hur du skapar en relation mellan två tabeller i SQL Server.
I relationsdatabasdesign, en relation är där två eller flera tabeller länkas samman eftersom de innehåller relaterade data. Detta gör det möjligt för användare att köra frågor för relaterade data över flera tabeller.
Den här delen av handledningen förklarar hur du skapar följande relationer:
Det finns två samband i det diagrammet. Det finns ett samband mellan Albums och Artists tabeller, och det finns en annan relation mellan Albums och Genres tabeller.
Genom att titta på det diagrammet kan vi se att en artist kan ha många album. I det här fallet behöver vi bara ha en rad som innehåller artistens namn, oavsett hur många album de har. Detta beror på att vi kan skapa en post i Artists tabell med ett unikt ArtistId . Alla album för den artisten kommer att finnas i Albums tabell, och de kommer att innehålla samma artist-ID i sitt eget ArtistId kolumn. Genom att göra detta kan vi köra en fråga över båda tabellerna och returnera artistens namn, plus alla album de har släppt. Detta är fördelen med relationer.
Tidigare skapade vi en databas som innehåller de tre ovanstående tabellerna. När vi gjorde det skapade vi också en av relationerna som avbildas i diagrammet ovan. Vi skapade relationen mellan Albums tabellen och Artists tabell (där ArtistId kolumnen i Albums Tabell refererar till ArtistsId kolumnen i Artists tabell).
Här är koden vi körde för att skapa tabellerna:
Den markerade koden är den del som skapar en relation mellan Albums tabellen och Artists tabell. Den gör detta genom att ställa in ArtistId kolumnen i Albums för att referera till ArtistId kolumnen i Artists bord.
Ett mer tekniskt sätt att säga detta är att Albums.ArtistId blir en främmande nyckel för Artists.ArtistId (som i sig är den primära nyckeln i den tabellen). Detta är en främmande nyckelrestriktion.
Vad är en utländsk nyckelbegränsning?
En främmande nyckelbegränsning definierar en relation mellan denna tabell och en annan tabell. När du skapar en främmande nyckel-begränsning skapar du den mot en specifik kolumn i underordet tabell, för att referera till en specifik kolumn i förälder bord.
Detta gör den kolumnen i den underordnade tabellen till en främmande nyckel . Begränsningen säkerställer att alla värden som går in i denna (främmande nyckel) kolumn motsvarar ett värde i primärnyckelkolumnen i den överordnade tabellen. Om någon försöker ange ett värde som inte överensstämmer med ett värde i den överordnade tabellens primärnyckelkolumn, kommer SQL Server att ge ett felmeddelande.
Detta hjälper till att upprätthålla referensintegritet. Det hindrar oss från att ha föräldralösa register (underordnade register som inte har någon förälder). Eller i vårt exempel, album som inte är associerade med någon artist.
Om du använder ett GUI-databashanteringsverktyg som SSMS eller Azure Data Studio, kommer relationen att visas under Keys nod för tabellen med den främmande nyckeln:
Låt oss dekonstruera koden:
CONSTRAINT FK_Albums_Artists FOREIGN KEY (ArtistId)
REFERENCES dbo.Artists (ArtistId)
ON DELETE NO ACTION
ON UPDATE NO ACTION
De två första raderna skapar relationen. De skapar en främmande nyckel-begränsning mellan
Albums.ArtistId
kolumnen och
Artists.ArtistId
kolumn. I det här fallet kallar vi den främmande nyckelbegränsningen FK_Albums_Artists .
De sista två raderna anger vad SQL Server ska göra om någon försöker ta bort eller uppdatera en överordnad post som refereras av en post i den underordnade tabellen. I det här fallet, NO ACTION betyder att raderingen/uppdateringen inte kommer att genomföras. Användaren får bara ett felmeddelande.
Du kan ändra detta till ON DELETE CASCADE om du vill kunna radera föräldern och barnet på en gång (dvs raderingen kommer att kaskaderas från föräldern till barnet). Samma logik gäller för uppdateringar, genom att använda ON UPDATE CASADE .
NO ACTION är standardvärdet, så vi kunde ha klarat oss utan de två sista kodraderna. Men jag inkluderade det eftersom det är en viktig faktor att tänka på när man skapar begränsningar för främmande nyckel.
Lägg till en relation till en befintlig tabell
Det föregående exemplet skapar en relation samtidigt som tabellerna skapas. Det kan dock finnas tillfällen då du behöver lägga till en relation till en befintlig tabell.
Låt oss lägga till en ny relation mellan Genres och Albums tabeller.
Kör följande kod:
USE Music; ALTER TABLE Albums ADD CONSTRAINT FK_Albums_Genres FOREIGN KEY (GenreId) REFERENCES dbo.Genres (GenreId) ON DELETE NO ACTION ON UPDATE NO ACTION ;
Detta skapar en ny främmande nyckel på Albums tabell. Det resulterar i Albums.GenreId blir en främmande nyckel som refererar till Genres.GenreId .
Så att köra den satsen resulterar i att en ny främmande nyckel visas under Keys nod:
Enkelkolumns främmande nycklar
Enkolumns främmande nycklar (som den ovan) kan också anges på kolumnnivå. Så ett annat sätt att skapa Albums tabellen och dess främmande nyckel är så här:
CREATE TABLE Albums ( AlbumId int IDENTITY(1,1) NOT NULL PRIMARY KEY, AlbumName nvarchar(255) NOT NULL, ReleaseDate date NOT NULL, ArtistId int NOT NULL REFERENCES Artists(ArtistId), GenreId int NOT NULL );
Den här metoden kan inte användas på nyckelbegränsningar med flera kolumner, så för dessa, använd syntaxen i det ursprungliga exemplet ovan.
Utländska nycklar med flera kolumner
En främmande nyckel med flera kolumner är där mer än en kolumn används för den främmande nyckeln. Detta används vanligtvis när den överordnade tabellen använder flera kolumner för sin primärnyckel. Detta kan vara fallet om den överordnade tabellen kombinerar värdena från två kolumner för att skapa ett unikt värde.
Främmande nycklar med flera kolumner kan skapas med hjälp av syntaxen i det ursprungliga exemplet ovan. Lägg bara till varje kolumnnamn avgränsade med kommatecken.
Så om vi föreställer oss att Albums tabellen har också en ArtistName kolumnen (och att Artists tabellen använder ArtistId och ArtistName som primärnyckel) skulle en främmande nyckel med flera kolumner se ut så här:
CONSTRAINT FK_Albums_Artists FOREIGN KEY (ArtistId, ArtistName)
REFERENCES dbo.Artists (ArtistId, ArtistName)