Vad är namnet på den underordnade tabellnyckeln. Nycklar och index

Youtube

Tidigare i den här boken påpekade vi vissa samband som finns mellan vissa fält i typiska tabeller. Snum-fältet i tabellen Kunder motsvarar till exempel snum-fältet i tabellen Säljare och Ordertabellen. Cnum-fältet i tabellen Kunder motsvarar också cnum-fältet i tabellen Order. Vi har kallat denna typ av länk för referensintegritet; och under diskussionens gång har du sett hur det kan användas.

I det här kapitlet kommer du att utforska referensintegritet mer i detalj och ta reda på allt om de begränsningar du kan använda för att upprätthålla den. Du kommer också att se hur den upprätthåller denna begränsning när du använder DML-modifieringskommandon. Eftersom referensintegritet involverar associering av fält eller grupper av fält, ofta i olika tabeller, kan denna åtgärd vara något mer komplex än andra begränsningar. Av denna anledning är det bra att ha en grundlig förståelse för det, även om du inte planerar att skapa tabeller. Dina modifieringskommandon kan göras mer effektiva genom att använda en referensintegritetsbegränsning (som med andra restriktioner, men en referensintegritetsbegränsning kan påverka andra tabeller än de där den är definierad), och vissa frågefunktioner, såsom joins, är strukturerade flera gånger när det gäller referensintegritetslänkar (som betonats i kapitel 8).

EXTERN NYCKEL OCH FÖRÄLDRARNYCKEL

När alla värden i ett fält i en tabell är representerade i ett fält i en annan tabell, säger vi att det första fältet refererar till det andra. Detta indikerar ett direkt samband mellan värdena i de två fälten. Till exempel har var och en av kunderna i tabellen Kunder ett snum-fält som anger säljaren som tilldelats i tabellen Säljare. För varje beställning i ordertabellen finns det en och endast denna säljare och en och endast denna kund. Detta visas med hjälp av snum- och cnum-fälten i Order-tabellen.

När ett fält i en tabell refererar till ett annat kallas det en främmande nyckel; och fältet det refererar till kallas föräldernyckeln. Så snum-fältet i tabellen Kunder är en främmande nyckel, och snum-fältet det refererar till i tabellen Säljare är den överordnade nyckeln.

Likaså är cnum- och snum-fälten i tabellen Order främmande nycklar som refererar till deras överordnade nycklar med namnen i tabellerna Kunder och Leverantörer. Namnen på den främmande nyckeln och föräldernyckeln behöver inte vara samma, det är bara en konvention som vi följer för att göra sammanfogningen tydligare.

EXTERNA NYCKLAR MED FLERA KOLUMN

I verkligheten behöver en främmande nyckel inte bara bestå av ett kön. Liksom en primärnyckel kan en främmande nyckel ha valfritt antal fält, som alla behandlas som en enda enhet. Den främmande nyckeln och den överordnade nyckeln som den refererar till måste naturligtvis ha samma nummer och typ, kön och vara i samma ordning. Främmande nycklar som består av ett kön är de som vi enbart använde i våra exempeltabeller, de vanligaste. För att hålla vår diskussion enkel kommer vi ofta att referera till främmande nyckel som en enda kolumn. Detta är ingen slump. Om detta inte är markerat skulle vem som helst säga om ett fält som är en främmande nyckel att det också gäller för en grupp av fält som är en främmande nyckel.

Innebörden av de yttre och föräldrande nycklarna

När ett fält är en främmande nyckel är det på något sätt associerat med tabellen det refererar till. Du säger faktiskt - "varje värde i detta fält (främmande nyckel) är direkt kopplat till värdet i ett annat fält (föräldernyckel)." Varje värde (varje rad) på en främmande nyckel måste otvetydigt referera till en och endast detta värde (rad) på den överordnade nyckeln. Om så är fallet, kommer faktiskt ditt system, som de säger, att vara i ett tillstånd av referensintegritet. Du kan se detta med ett exempel. Den främmande nyckeln snum i tabellen Kunder är 1001 för raderna Hoffman och Clemens. Anta att vi hade två rader i tabellen Säljare med snum = 1001. Hur vet vi till vilken av de två säljarna kunderna Hoffman och Clemens har tilldelats? På samma sätt, om det inte finns några sådana rader i tabellen Leverantörer, kommer vi att få Hoffman och Clemens tilldelade en leverantör som inte finns!

Det är underförstått att varje värde i en främmande nyckel måste representeras en gång, och endast en gång, i den överordnade nyckeln.

Faktum är att ett givet främmande nyckelvärde bara kan referera till ett överordnat nyckelvärde utan att antyda den motsatta möjligheten: d.v.s. valfritt antal främmande nycklar kan referera till ett värde för en enskild överordnad nyckel. Du kan se detta i våra exempeltabeller. Både Hoffman och Clemens är tilldelade Peel, så båda deras värden för främmande nyckel är samma överordnade nyckel, vilket är ganska bra. Ett värde för en främmande nyckel måste endast referera till ett värde för en överordnad nyckel, men värdet på den överordnade nyckeln kan refereras med valfritt antal värden för främmande nyckel. Som en illustration visas främmande nyckelvärden från tabellen Kunder som matchar deras överordnade nyckel i tabellen Säljare i figur 19.1. För enkelhetens skull har vi utelämnat kön som inte är relaterat till detta exempel.

BEGRÄNSNING AV UTLÄNDSK NYCKEL

SQL upprätthåller referensintegritet med begränsningen FOREIGN KEY. Även om FOREIGN KEY-begränsningen är en ny funktion i SQL, ger den ännu ingen allmänhet. Dessutom är vissa av dess implementeringar mer komplexa än andra. Denna funktion bör begränsa de värden som du kan ange i din databas för att tvinga den främmande nyckeln och överordnade nyckeln att överensstämma med referensintegritetsprincipen. En av åtgärderna för en främmande nyckel-begränsning är att kassera värden för fält som är begränsade som en främmande nyckel som ännu inte är representerade i den överordnade nyckeln. Denna begränsning påverkar också din förmåga att ändra eller ta bort överordnade nyckelvärden (vi kommer att diskutera detta senare i det här kapitlet).

HUR KAN FÄLTEN REPRENTERAS SOM EXTERNA NYCKLAR

Du använder en FOREIGN KEY-begränsning på ett CREATE TABLE (eller ALTER TABLE) kommando som innehåller ett fält som du vill deklarera som en främmande nyckel. Du ger dem en föräldranyckel som du kommer att hänvisa till inom en begränsning av FOREIGN KEY. Att sätta denna begränsning i ett kommando är samma som för de andra begränsningarna som diskuterades i föregående kapitel. Figur 19.1: Utländsk nyckel för kundtabell med överordnad nyckel

Liksom de flesta begränsningar kan det vara en tabell- eller kolumnrestriktion, i form av en tabell, vilket tillåter att flera kön kan användas som en enda främmande nyckel.

EXTERN NYCKEL SOM TABELLBEGRÄNSNING

FOREIGN KEY-tabellens restriktionssyntax: FOREIGN KEY REFERENSER [ ] Den första listan med kolumner är en kommaseparerad lista med en eller flera kolumner i tabellen som kommer att skapas eller ändras av detta kommando. Pktable är en tabell som innehåller den överordnade nyckeln. Det kan vara en tabell som skapas eller modifieras av det aktuella kommandot. Den andra listan med kolumner är listan med kolumner som kommer att utgöra den överordnade nyckeln. Listorna över de två kolumnerna måste vara kompatibla, dvs.:

* De måste ha samma antal kolumner.

* I en given sekvens måste den första, andra, tredje, etc. kolumnerna i kolumnlistan med främmande nyckel ha samma datatyper och storlekar som den första, andra, tredje, etc. kolumnerna i kolumnlistan för överordnade nyckel . .. Kolumnerna i listorna för båda kolumnerna ska inte ha samma namn, även om vi använde den här metoden i våra exempel för att göra sambandet tydligare.

Låt oss skapa en kundtabell med snum-fältet definierat som en främmande nyckel som refererar till tabellen Säljare: CREATE TABLE Kunder (cnum heltal INTE NULL PRIMÄRNYCKEL cname char (10), stad char (10), snum heltal, FOREIGN KEY (snum) REFERENSER Säljare (snum ); Observera att när du använder ALTER TABLE istället för CREATE TABLE för att tillämpa en FOREIGN KEY-begränsning, måste värdena du anger i den främmande nyckeln och överordnade nyckeln vara i referensintegritet annars kommer kommandot att avvisas. Även om ALTER TABLE är mycket användbar från - för bekvämlighets skull måste du i ditt system, när det är möjligt, först bilda strukturella principer, såsom referensintegritet.

EXTERN NYCKEL SOM KOLUMNBEGRÄNSNING

Varianten av kolumnrestriktionen med FOREIGN KEY constraint - annars kallad - referensrestriktionen (REFERENCES), eftersom den faktiskt inte innehåller orden FOREIGN KEY, utan helt enkelt använder ordet REFERENCES, och sedan den överordnade nyckeln, så här: CREATE TABELL Kunder ( cnum heltal INTE NULL PRIMÄRNYCKEL, cname char (10), stad char (10), snum heltal REFERENSER Säljare (snum)); Ovanstående definierar Customers.snum som en främmande nyckel vars överordnade nyckel är Salespeople.snum. Detta motsvarar denna tabellrestriktion: UTLÄNDSK NYCKEL (snum) REGERENSER Säljare (snum)

SPECIFICERA INTE PRIMÄRNYCKELKOLONNLISTA M

Genom att använda FOREIGN KEY-begränsningen i en tabell eller kolumn kan du utelämna listan över kolumner för den överordnade nyckeln om den överordnade nyckeln har en PRIMARY KEY-begränsning. Naturligtvis, när det gäller nycklar med många fält, måste ordningen på kolumnerna i främmande och primärnycklar vara densamma, och i alla fall gäller principen om kompatibilitet mellan de två nycklarna fortfarande. Om vi till exempel sätter en PRIMARY KEY-begränsning i snum-fältet i tabellen Sales, kan vi använda den som en främmande nyckel i tabellen Customers (liknande föregående exempel) i det här kommandot: CREATE TABLE Customers (cnum integer NOT NULL) PRIMÄRNYCKEL, cname char (10) , city char (10), snum heltal REFERENSER Säljare); Den här funktionen har byggts in i språket för att uppmuntra dig att använda primärnycklar som överordnade nycklar.

HUR REFERENSINTEGRITET BEGRÄNSAR VÄRDET PÅ FÖRÄLDERNYCKLEN

Att upprätthålla referensintegritet kräver vissa begränsningar för de värden som kan representeras i fält som deklareras som främmande nyckel och överordnad nyckel. Den överordnade nyckeln måste vara strukturerad för att säkerställa att varje främmande nyckelvärde matchar en angiven sträng. Det betyder att den (nyckeln) måste vara unik och inte innehålla några NULL-värden. Detta räcker inte för föräldranyckeln om ett krav som vid deklaration av en främmande nyckel är uppfyllt. SQL måste vara säker på att inga dubbla eller NULL-värden har angetts i den överordnade nyckeln. Därför måste du se till att alla kön som används som överordnade nycklar har antingen en PRIMARY KEY-begränsning eller en UNIK begränsning som NOT NULL-begränsningen.

PRIMÄRNYCKEL SOM EN UNIK EXTERN NYCKEL

Att endast referera dina främmande nycklar till primärnycklar, som vi gjorde i exempeltabeller, är en bra strategi. När du använder främmande nycklar binder du dem till mer än bara de överordnade nycklar de refererar till; du länkar dem till en specifik rad i tabellen där den överordnade nyckeln finns. Den överordnade nyckeln i sig själv tillhandahåller ingen information som inte redan finns i den främmande nyckeln. Innebörden, till exempel, av snum-fältet som en främmande nyckel i tabellen Kunder är relationen som den ger, inte till värdet av snum-fältet som det refererar till, utan till annan information i tabellen Säljare, som, till exempel namnen på säljarna, deras plats och så vidare. ... En främmande nyckel är inte bara ett förhållande mellan två identiska värden; det är en relation, med dessa två värden, mellan två rader i tabellen som anges i frågan. Detta snum-fält kan användas för att associera all information i en rad från tabellen Kunder med en referensrad från tabellen Säljare - till exempel för att ta reda på om de bor i samma stad, vem som har ett längre namn, om säljaren har alla andra kunder förutom den givna kunden, kunder och så vidare. Eftersom syftet med primärnyckeln är att identifiera radens unika karaktär är detta ett mer logiskt och mindre tvetydigt val för en främmande nyckel. För alla främmande nyckel som använder en unik nyckel som överordnad nyckel måste du skapa en främmande nyckel som använder primärnyckeln i samma tabell för samma åtgärd. En främmande nyckel, som inte har något annat syfte än att sammanfoga strängar, liknar en primärnyckel som endast används för att identifiera strängar, och är ett bra sätt att hålla din databasstruktur tydlig och enkel, och därför mindre krångel.

EXTERNA NYCKELBEGRÄNSNINGAR

En främmande nyckel, i synnerhet, kan bara innehålla de värden som faktiskt är representerade i den överordnade nyckeln eller tomma (NULL). Försök att ange andra värden i denna nyckel kommer att avvisas. Du kan deklarera en främmande nyckel som INTE NULL, men detta är valfritt och i de flesta fall inte önskvärt. Anta till exempel att du anger en kund utan att i förväg veta vilken säljare han kommer att tilldelas. Den bästa vägen ut i denna situation skulle vara att använda ett NOT NULL-värde, som senare måste ändras till ett specifikt värde.

VAD HÄNDER OM DU UTFÖR MODIFIKATIONSKOMMANDOET

Låt oss komma överens om att alla främmande nycklar som skapas i våra exempeltabeller deklareras och upprätthålls med begränsningar för främmande nyckel enligt följande: SKAPA TABELL Säljare (snum heltal INTE NULL PRIMÄRNYCKEL, namntecken (10) INTE NULL, stadstecken (10) , kommadecimal) ; SKAPA TABELL Kunder (cnum heltal INTE NULL PRIMÄRNYCKEL, cname char (10) NOT NULL, city char (10), rating heltal, snum heltal, FOREIGN KEY (snum) REFERENSER Säljare, UNIKA (cnum, snum); SKAPA TABELL Orders ( cnum heltal INTE NULL PRIMÄRNYCKEL, amt decimal, odate datum INTE NULL, cnum heltal NOT NULL snum heltal INTE NULL UTLÄNDSK NYCKEL (cnum, snum) REFERENSER KUNDER (cnum, snum);

INKLUSIVE TABELLBESKRIVNINGAR

Det finns flera attribut för sådana definitioner att tala om. Anledningen till att vi bestämde oss för att göra cnum- och snum-fälten i Order-tabellen till en enda främmande nyckel är en garanti för att för varje kund som ingår i orderna, är säljaren som krediterar denna order densamma som specificeras i Customers-tabellen. För att skapa en sådan främmande nyckel måste vi placera den UNIKA tabellbegränsningen i två fält i tabellen Kunder, även om det inte är nödvändigt för själva tabellen. Så länge som cnum-fältet i den här tabellen har en PRIMÄR KEY-begränsning, kommer det att vara unikt i alla fall, och därför är det omöjligt att få en annan kombination av cnum-fältet med något annat fält. Att skapa en främmande nyckel på detta sätt bibehåller databasens integritet, även om det hindrar dig från att avbryta internt av misstag och låna ut till någon annan leverantör än den som tilldelats just den kunden.

Ur synvinkel att upprätthålla databasens integritet är interna avbrott (eller undantag) naturligtvis oönskade. Om du tillåter dem och samtidigt vill behålla integriteten för din databas, kan du deklarera snum- och cnum-fälten i Order-tabellen som oberoende främmande nycklar för dessa fält i tabellerna Säljare respektive Kunder. Att använda snum-fält i Order-tabellen som vi gjorde är faktiskt valfritt, även om det var användbart att göra det för en förändring. Cnum-fältet som länkar varje order av kunder i tabellen Kunder, i tabellen Order och i tabellen Kunder, måste alltid vara gemensamt för att hitta rätt snum-fält för en given order (inte tillåta några undantag). Detta innebär att vi registrerar en bit information - vilken kund som är tilldelad vilken leverantör - två gånger, och ytterligare arbete kommer att behöva göras för att säkerställa att båda versionerna är konsekventa. Om vi inte har en begränsning för främmande nyckel som nämnts ovan kommer denna situation att vara särskilt problematisk, eftersom varje beställning måste kontrolleras manuellt (tillsammans med begäran) för att säkerställa att rätt säljare har krediterat varje respektive försäljning. Att ha denna typ av informationsredundans i din databas kallas denormalisering, vilket är oönskat i en idealisk relationsdatabas, även om det i praktiken kan lösas. Demoralisering kan göra att vissa frågor körs snabbare eftersom en fråga på en enskild tabell alltid är mycket snabbare än en koppling.

EFFEKTEN AV BEGRÄNSNINGAR

Hur påverkar sådana begränsningar din förmåga och oförmåga att använda DML-modifieringskommandon? För fält som definieras som främmande nycklar är svaret ganska enkelt: alla värden som du infogar i dessa fält med ett INSERT- eller UPDATE-kommando måste redan finnas i deras överordnade nycklar. Du kan sätta NULL-värden i dessa fält, även om NULL-värden inte är tillåtna i överordnade nycklar, så länge de har en NOT NULL-begränsning. Du kan RADERA vilken främmande nyckelrad som helst utan att använda föräldernycklar alls.

Eftersom det berör frågan om att ändra värden för överordnad nyckel, är svaret, enligt ANSI-definition, ännu enklare, men kanske något mer begränsat: något värde på föräldernycklar som refereras till av ett främmande nyckelvärde kan inte tas bort eller ändras. Det betyder till exempel att du inte kan ta bort en kund från tabellen Kunder medan den fortfarande har order i tabellen Order. Beroende på hur du använder dessa tabeller kan detta vara antingen önskvärt eller besvärligt. Detta är dock säkerligen bättre än att ha ett system som låter dig radera en kund med aktuella beställningar och lämna ordertabellen med hänvisning till icke-existerande kunder. Innebörden av detta begränsningssystem är att skaparen av ordertabellen, med hjälp av tabellen Kunder och tabellen Leverantörer som överordnade nycklar, kan införa betydande begränsningar för åtgärderna i dessa tabeller. Av denna anledning kommer du inte att kunna använda en tabell som du inte kontrollerar (dvs. du har inte skapat den och du äger den inte), förrän ägaren (skaparen) av denna tabell specifikt ger dig rätt att göra detta (vilket förklaras i kapitel 22). Det finns några andra möjliga åtgärder för att ändra den överordnade nyckeln som inte är en del av ANSI men som finns i vissa kommersiella program. Om du vill ändra eller ta bort det aktuella referensvärdet för den överordnade nyckeln, finns det i huvudsak tre möjligheter:

Du kan begränsa eller neka ändringar (ANSI-sätt) genom att ange att ändringar av den överordnade nyckeln är begränsade.

Du kan göra en ändring i den överordnade nyckeln och därmed göra ändringen i den främmande nyckeln automatisk, vilket kallas en kaskadändring.

Du kan göra en ändring i den överordnade nyckeln och ställa in den främmande nyckeln till NULL, automatiskt (förutsatt att NULLS är tillåtet i den främmande nyckeln), vilket kallas en tom främmande nyckel-ändring.

Även inom dessa tre kategorier kanske du inte vill hantera alla modifieringskommandon på detta sätt. INSERT är naturligtvis vid sidan om. Den lägger in de nya värdena för den överordnade nyckeln i tabellen så att inget av dessa värden kan anropas för tillfället. Men du kanske vill tillåta att ändringar kaskadkopplas utan raderingar, och vice versa. En bättre situation kan vara en som låter dig definiera någon av de tre kategorierna, oavsett kommandona UPDATE och DELETE. Vi kommer därför att hänvisa till uppdateringseffekterna och raderingseffekterna, som avgör vad som händer om du utfärdar en UPPDATERING eller DELETE på föräldranyckeln. Dessa effekter vi pratade om kallas BEGRÄNSADE förändringar, CASCADES förändringar och NULL förändringar. De faktiska funktionerna i ditt system bör vara i en strikt ANSI-standard – ändrings- och raderingseffekter, båda automatiskt begränsade – för den mer idealiska situationen som beskrivs ovan. Som illustration visar vi några exempel på vad du kan göra med hela uppsättningen av ändringar och borttagningseffekter. Naturligtvis saknar modifierings- och raderingseffekter, som är icke-standardiserade medel, standardtillståndssyntax. Syntaxen vi använder här är lätt att skriva och kommer att fungera som en guide för att illustrera dessa effekters funktioner.

För fullständigheten av experimentet, låt oss anta att du har en anledning att ändra snum-fältet i tabellen Leverantörer i fallet när vår Leverantörstabell byter sektion. (Att byta primärnycklar är vanligtvis inget vi rekommenderar att göra i praktiken. Det är bara ytterligare ett skäl till att befintliga primärnycklar inte gör något annat än att agera som primärnycklar: de bör inte ändras.) När du ändrar leverantörsnumret vill du att alla sina kunder ska räddas. Men om den här säljaren lämnar sitt företag eller företag kanske du inte vill ta bort hans kunder när du tar bort honom från databasen. Istället vill man se till att kunderna tilldelas någon annan. För att göra detta måste du ange en UPPDATERING med en Cascading-effekt och en DELETE med en Constrained-effekt. SKAPA TABELL Kunder (cnum heltal INTE NULL PRIMÄRNYCKEL, cname char (10) NOT NULL, city char (10), betygsheltal, snum heltal REFERENSER Säljare, UPPDATERING AV Säljare CASCADES, DELETE OF Säljare BEGRÄNSAT); Om du nu försöker ta bort en Peel från leverantörstabellen, kommer kommandot inte att vara giltigt förrän du ändrar Hoffman och Clemens kundnummer-fält för en annan utsedd leverantör. Alternativt kan du ändra Peels snum-golvvärde till 1009, och Hoffman och Clemens kommer också att ändras automatiskt.

Den tredje effekten är NULL-ändringar. Det händer att när säljare lämnar företaget överförs inte deras nuvarande beställningar till en annan säljare. Däremot vill du avbryta alla beställningar automatiskt för de kunder vars fakturor du raderar. Genom att ändra säljarens eller kundens nummer kan du enkelt överföra dem till honom. Exemplet nedan visar hur du kan skapa en beställningstabell med dessa effekter. SKAPA TABELL Beställningar (onum heltal INTE NULL PRIMÄRNYCKEL, amt decimal, odate date NOT NULL cnum heltal INTE NULL REFERENSER Kunder snum heltal REFERENSER Säljare, UPPDATERING AV kunder CASCADES, DELETE OF Customers CASCADES, UPDATE UPDATE; Naturligtvis, i ett DELETE-kommando med effekten av en nolländring i tabellen säljare, måste begränsningen NOT NULL tas bort från snum-fältet.

EXTERNA NYCKLAR SOM hänvisar TILL TILLBAKA TILL SINA SLAVBORD

Som nämnts tidigare kan FOREIGN KEY-begränsningen representera denna privata tabell för dem som de överordnade nyckeltabellerna. Långt ifrån enkel, den här funktionen kan komma väl till pass. Anta att vi har en tabell för anställda med ett chefsfält. Detta fält innehåller numren på var och en av de anställda, av vilka några också är administratörer. Men eftersom varje handläggare samtidigt förblir anställd kommer han naturligtvis också att vara representerad i denna tabell. Låt oss skapa en tabell där anställds nummer (en kolumn med namnet empno) deklareras som en primärnyckel och administratören kommer att referera till det som en främmande nyckel: CREATE TABLE Anställda (empno heltal NOT NULL PRIMÄRNYCKEL, namn char (10) NOT NULL UNIOUE , chef heltal REFERENSER Anställda); (Eftersom en främmande nyckel är en refererad primärnyckel i en tabell, kan listan över kolumner uteslutas.) Innehållet i denna tabell är: EMPNO NAME MANAGER _____ ________ _______ 1003 Terrence 2007 2007 Atali NULL 1688 McKenna 1003 2002 Collier 2007 Collier kan se, var och en av dem (men inte Atali), hänvisar till en annan anställd i tabellen som sin administratör. Atali, som har det högsta numret i tabellen, måste sättas till NULL. Detta ger en annan princip för referensintegritet. En främmande nyckel som refererar tillbaka till en privat tabell måste tillåta värden = NULL. Om inte, hur skulle du infoga den första raden? Även om denna första rad hänvisar till sig själv, måste det överordnade nyckelvärdet redan ha ställts in när det främmande nyckelvärdet matas in. Denna princip kommer att gälla även om den främmande nyckeln inte refererar tillbaka till den privata tabellen direkt, utan genom en referens till en annan tabell, som sedan refererar tillbaka till den främmande nyckeltabellen. Anta till exempel att vår säljaretabell har ett extra fält som hänvisar till tabellen Kunder, så att varje tabell hänvisar till en annan, som visas i följande CREATE TABLE-sats: CREATE TABLE Säljare (snum heltal INTE NULL PRIMARY KEY, sname char (10) ) NOT NULL, city char (10), comm declmal, cnum heltal REFERENSER Kunder); SKAPA TABELL Kunder (cnum heltal INTE NULL PRIMÄRNYCKEL, cname char (10) NOT NULL, city char (10), betyg heltal, snum heltal REFERENSER Säljare); Detta kallas korsreferens. SQL stödjer detta i teorin, men i praktiken kan det vara problematiskt. Varje tabell av de två som skapas av den första är en referenstabell som ännu inte finns för den andra. I syfte att korsreferens tillåter SQL faktiskt detta, men ingen av tabellen kommer att vara användbar medan båda håller på att skapas. Å andra sidan, om de två tabellerna skapas av olika användare, blir problemet ännu svårare. Korsreferenser kan vara ett användbart verktyg, men det är inte utan tvetydighet och faror. Det tidigare exemplet är till exempel inte helt användbart: eftersom det begränsar säljaren till en enda kund, och dessutom är det inte alls nödvändigt att använda en korshänvisning för att uppnå detta. Vi rekommenderar att du är försiktig med att använda den och analyserar hur dina program hanterar effekterna av ändring och radering, såväl som privilegier och dialogbearbetning av förfrågningar, innan du skapar ett korsreferensintegritetssystem. (Behörigheter och interaktiv frågebehandling kommer att diskuteras i respektive kapitel 22 OCH.)

SAMMANFATTNING

Du har nu tillräckligt bra kontroll över referensintegriteten. Grundidén är att alla främmande nyckelvärden refererar till den angivna överordnade nyckelsträngen. Detta innebär att varje främmande nyckelvärde måste representeras en gång, och endast en gång, i den överordnade nyckeln. Närhelst ett värde placeras i en främmande nyckel, kontrolleras den överordnade nyckeln för att säkerställa att dess värde representeras; annars kommer kommandot att avvisas. Den överordnade nyckeln måste ha en PRIMARY KEY eller UNIQUE begränsning för att säkerställa att värdet inte presenteras mer än en gång. Ett försök att ändra värdet på den överordnade nyckeln som för närvarande är representerad i den främmande nyckeln kommer att avvisas helt och hållet. Ditt system kan dock erbjuda dig valet att få det främmande nyckelvärdet satt till NULL, eller att få det nya värdet för överordnad nyckel, och ange vilket som kan hämtas oberoende för UPDATE- och DELETE-kommandon. Detta avslutar vår diskussion om kommandot CREATE TABLE. Därefter kommer vi att introducera dig för en annan typ av kommando - CREATE. I kapitel 20 kommer du att lära dig att representera dataobjekt som ser ut och fungerar som en tabell, men som faktiskt är resultatet av frågor. Vissa av funktionerna för begränsningar kan också utföras av vyer, så att du bättre kan bedöma ditt behov av begränsningar efter att du har läst de kommande tre kapitlen.

ARBETA MED SQL

1. Skapa en tabell med namnet Cityorders. Den måste innehålla samma onum-, amt- och snum-fält som ordertabellen, och samma cnum- och stad-fält som Customers-tabellen, så varje kunds ordning kommer att anges i tabellen tillsammans med deras stad. Onum-fältet kommer att vara den primära nyckeln för Cityorders. Alla våningar i Cityorders måste ha restriktioner jämfört med kund- och ordertabellerna. Det antas att de överordnade nycklarna i dessa tabeller redan har lämpliga begränsningar.

2. Låt oss komplicera problemet. Omdefiniera ordertabellen enligt följande: lägg till en ny kolumn med namnet prev för att identifieras för varje order, ett tidigare orderonum-fält för den aktuella kunden. Gör detta med en främmande nyckel som refererar till själva ordertabellen. Den främmande nyckeln måste också referera till kundens cnum-fält, vilket ger en viss föreskriven relation mellan den aktuella ordern och den refererade.

(Se bilaga A för svar.)

F oreign Key (främmande nyckel) är nyckeln som används för att sammanfoga två tabeller. Det kallas ibland också en referensnyckel.

En främmande nyckel är en kolumn eller kombination av kolumner vars värden motsvarar en primärnyckel i en annan tabell.

Relationen mellan de två tabellen matchar primärnyckeln i en av de främmande nyckeltabellerna i den andra tabellen.

Om en tabell har en primärnyckel definierad på ett eller flera fält, kan du inte ha två poster som har samma värde för det eller de fälten.

Exempel

Tänk på strukturen i följande två tabeller.

KUNDERS bord

SKAPA TABELLKUNDER (ID INT EJ NULL, NAMN VARCHAR (20) EJ NULL, ÅLDER INT EJ NULL, ADRESSTECKN (25), LÖNDECIMAL (18, 2), PRIMÄRNYCKEL (ID));

BESTÄLLNINGStabell

SKAPA TABELLORDER (ID INT INTE NULL, DATUM DATUMTIDEN, CUSTOMER_ID INT refererar till KUNDER (ID), BELOPP dubbelt, PRIMÄRNYCKEL (ID));

Om tabellen ORDERS redan har skapats och den främmande nyckeln ännu inte har ställts in, används syntaxen för att ställa in den främmande nyckeln genom att modifiera tabellen.

ÄNDRA TABELLORDER LÄGG TILL UTLÄNDSK NYCKEL (Customer_ID) REFERENSER KUNDER (ID);

Ta bort en främmande nyckel-begränsning

Använd följande SQL-syntax för att ta bort en främmande nyckel.

ÄNDRA TABELLORDNINGAR SLÄPP UTLÄNDSK NYCKEL;

I det här ämnet, med hjälp av exemplet med två tabeller, definieras de grundläggande begreppen för relationsdatabaser, nämligen:

primärnyckel;
extern nyckel;
enkel och sammansatt nyckel;
attityd, typer av relationer;
konstgjorda och naturliga nycklar;
master- och detaljtabeller.

Indata

Låt databasen över anställda i företaget ges, som består av två tabeller. Den första tabellen innehåller uppgifter om den anställde. Den andra tabellen innehåller information om den anställdes lön.

Tabellerna är uppbyggda enligt följande.

"Arbetstagare"... Innehåller uppgifter om medarbetaren "Lön"... Innehåller information om anställdas löner.

Fråga Svar

1. Vad är primärnyckeln i en databastabell? Vad används primärnycklar till?

Vid arbete med tabeller i relationsdatabaser är det önskvärt (nödvändigt) att varje tabell har en s.k. primärnyckel.

PrimärnyckelÄr ett fält som används för att säkerställa unika data i tabellen. Detta innebär att värdet (informationen) i primärnyckelfältet i varje rad (post) i tabellen kan vara unikt.

Unikitet är nödvändigt för att undvika oklarheter, när det inte är känt vilken tabellpost som kan nås om det finns dubbla poster i tabellen (två poster har samma värden i alla tabellfält).

Exempel. För tabellen "Anställd" kan du ange ytterligare ett fält som kommer att vara primärnyckeln. Fältet "Personalnummer" (attribut) ger dock också unikhet. Eftersom det teoretiskt sett inte kan finnas två identiska personalnummer. I praktiken kan det finnas fall då samma personalnummer anges av misstag och värdena för alla fält i tabellen matchar. Som ett resultat kommer det att finnas två identiska poster i tabellen. För att undvika ett sådant fel är det bättre att skapa ett extra räknarfält i tabellen, vilket säkerställer unikhet.

Även för tabellen "Lön" kan du ange ett extra fält, som kommer att vara den primära nyckeln.

2. Vad är en relation (relation) mellan tabeller (relation)? Exempel

Tabeller i en relationsdatamodell kan ha relationer med varandra. Dessa kopplingar kallas relationer. För tabellerna "Anställd" och "Lön" kan du skapa en länk i fältet "Personalnummer".

Exempel. Låt oss analysera tabellerna "Anställd" och "Lön". I dessa tabeller kan du upprätta en relation mellan tabeller baserat på fältet Personalnummer. Det vill säga relationen mellan tabeller baseras på fältet "Personalnummer" (attribut).

Det betyder följande. Om du behöver hitta de upplupna lönerna i tabellen "Lön" för den anställde Ivanov I.I., måste du göra följande:

hitta personalnumret för den anställde Ivanov I.I. i tabellen "Anställd". Personalnumret är 7585;
i tabellen "Lön", hitta alla värden som är lika med 7585 (personalnummer);
välj från tabellen "Lön" alla värden i fältet "Upplupna" som motsvarar personalnumret 7585.

Ris. 1. Illustration av förhållandet mellan tabeller. Personalnummer 2145 i tabellen "Anställd" visas i tabellen "Lön"

Ris. 2. Relation (relation) mellan tabellfält

3. Vad är en främmande nyckel? Exempel

Begreppet "främmande nyckel" är viktigt när man överväger relaterade tabeller.

Extern nyckelÄr ett eller flera fält (attribut) som är primära i en annan tabell och vars värde ersätts av värdena för primärnyckeln i en annan tabell.

Exempel. Låt det finnas ett samband mellan tabellerna "Anställd" och "Lön" i fältet "Personalnummer". I det här fallet kan fältet "Personalnummer" i tabellen "Anställd" vara den primära nyckeln, och fältet "Personalnummer" i tabellen "Lön" kan vara en främmande nyckel. Detta innebär att värdena i fältet "Personalnummer" i tabellen "Lön" ersätts med värdena i fältet "Personalnummer" i tabellen "Anställd".

4. Vad är en rekursiv främmande nyckel?

Rekursiv främmande nyckelÄr en främmande nyckel som refererar till samma tabell som den tillhör. I det här fallet är fältet (attributet) som motsvarar den främmande nyckeln nyckeln för samma relation (relation).

5. Kan primära och främmande nycklar vara enkla eller sammansatta (komplexa)?

Primära, sekundära och främmande nycklar kan vara enkla eller sammansatta (komplexa). Enkla nycklarÄr nycklar som bara innehåller ett fält (ett attribut). Sammansatt(komplexa) nycklar är nycklar som innehåller flera fält (attribut).

6. Vad är skillnaden mellan artificiell och naturlig nyckel? Exempel

Naturlig nyckel ger unikhet från själva essensen av domänen. Det finns fall då värdena för poster i vissa fält i tabellen är unika. Detta fält kan vara en naturlig nyckel.

Konstgjord nyckel introduceras dessutom för att ge unika värden. Oftast är den konstgjorda nyckeln ett fält av typen räknare (räknare). I ett sådant fält, när en ny post (rad) läggs till i tabellen, ökas räknarvärdet med 1 (eller ett annat värde). Om en post raderas från tabellen sänks inte maxvärdet för radräknaren längre utan förblir som det är. Som regel övervakas allt av databashanteringssystemet.

Exempel. I tabellen "Anställd" är den naturliga nyckeln fältet (attributet) "Personalnummer". Fältet "Personalnummer" är unikt i sig, eftersom det inte kan finnas två anställda med samma personalnummer.

I tabellen "Lön" kan värdet i alla fyra fälten upprepas av misstag. Därför är det lämpligt att lägga till ett extra räknarfält här, vilket kommer att vara en konstgjord nyckel. I det här fallet kan tabellen "Lön" med ett extra fält se ut så här:

där "Number"-fältet är en konstgjord nyckel som säkerställer unikhet.

7. Vilka är sätten att välja en primärnyckel?

Det finns tre sätt att välja en primärnyckel:

använd inkrementfältet (räknarfältet) som en konstgjord nyckel;
välj från data ett fält som kan ge unikhet;
välj flera fält från data som kan ge unikhet. I det här fallet kommer nyckeln också att kallas komplex (komposit).

8. Vad betyder termerna "huvudtabell" och "detalj"?

Om det finns en relation mellan tabellerna kan en av dem vara master (master) och den andra underordnade (detalj). Huvudtabellen visar alla poster som passar i den. Den underordnade tabellen visar endast de poster som motsvarar värdet på nyckeln i huvudtabellen, som för närvarande är aktiv (aktuell). Om den aktuella posten för huvudtabellen ändras, ändras uppsättningen av tillgängliga poster för den underordnade tabellen.

Exempel. Om vi betraktar tabellerna "Anställd" och "Lön", så är tabellen "Anställd" den huvudsakliga, och tabellen "Lön" är underordnad.

9. Vilka typer av relationer (länkar) finns mellan tabeller?

Det finns fyra huvudtyper av relationer mellan tabeller:

"en till en"... I detta fall motsvarar varje post i en tabell endast en post i en annan tabell;
En till många... Detta är när en post i huvudtabellen motsvarar flera poster i den underordnade tabellen (detalj). Det vill säga att varje post, som är den primära nyckeln i en tabell, motsvarar flera poster i den relaterade tabellen;
"Många till en"... Detta är när flera poster i huvudtabellen motsvarar en post i den underordnade tabellen;
"Många till många"... Det är när det finns flera relaterade poster i båda tabellerna.

Exempel. Om vi betraktar förhållandet mellan tabellerna "Anställd" och "Lön", så är detta förhållande av typen "en-till-många". Tabellen "Anställd" är den viktigaste. Tabellen "Lön" är underordnad.

Dessa är elektroniska arkiv med information, till vilka åtkomst sker med hjälp av en eller flera datorer. Vanligtvis skapas databaser för att lagra och komma åt data som innehåller information om ett visst ämnesområde, det vill säga ett visst område av mänsklig aktivitet eller en del av den verkliga världen.

DBMS är programvara för att skapa, fylla, uppdatera och ta bort en databas.

Den informationsenhet som lagras i databasen är en tabell. Varje tabell är en samling rader och kolumner, där raderna motsvarar en instans av ett objekt, en specifik händelse eller ett fenomen, och kolumnerna motsvarar attributen (egenskaper, egenskaper, parametrar) för ett objekt, händelse eller fenomen. Varje rad innehåller information om en specifik händelse.

När det gäller en databas kallas kolumnerna i en tabell för fält, och dess rader kallas för poster.

Relationer kan finnas mellan individuella databastabeller, det vill säga information i föregående tabell kan läggas till en annan. DBs, mellan de individuella tabellerna som det finns länkar till, kallas relationella. En och samma tabell kan vara den huvudsakliga i förhållande till en databastabell och underordnad i förhållande till en annan.

Tabeller kopplade av relationer interagerar på en master-slav basis. En och samma tabell kan vara master till en databastabell och barn till en annan.

Ett objekt Är något som finns och är särskiljbart, med en uppsättning egenskaper. Skillnaden mellan ett objekt och ett annat bestäms av specifika egenskapsvärden.

Kärnan - reflektion av ett föremål i minnet av en person eller en dator.

Attribut - det specifika värdet av någon av enhetens egenskaper.

Fält Är en enskild artikel i en post som lagrar ett specifikt värde för ett attribut.

Kommunikationsfält – detta är fältet där de två tabellerna är länkade.

Primära och sekundära nycklar

Varje databastabell kan ha en primärnyckel - detta är ett fält eller en flik med fält som unikt identifierar en post.

Det primära nyckelvärdet i databastabellen måste vara unikt, det vill säga att det inte ska finnas två eller flera poster i tabellen med samma primärnyckelvärde.

Primära nycklar gör det lättare att upprätta relationer mellan tabeller. Eftersom primärnyckeln måste vara unik kan inte alla tabellfält användas för den.

Om det inte finns några fält i tabellen vars värden är unika, för att skapa en primärnyckel, skrivs vanligtvis ett extra numeriskt fält in i den, vars värden DBMS kan förfoga över efter eget gottfinnande.

Sekundära nycklar ställs in av fält, som ofta används vid sökning eller sortering av data: index byggda på sekundära nycklar hjälper systemet att hitta de nödvändiga värdena som lagras i motsvarande fält mycket snabbare.

Till skillnad från primärnycklar kanske fält för sekundära nycklar inte innehåller unik information.

Relationella relationer mellan tabeller

En till en. En en-till-en-relation uppstår när en post i den överordnade tabellen matchar en post i den underordnade tabellen.

Denna relation är mycket mindre vanlig än en en-till-många-relation, den används om du inte vill att databastabellen ska svälla från en sekundär tabell. En en-till-en relation leder till att för att kunna läsa relaterad information i flera tabeller måste flera läsoperationer utföras, vilket saktar ner inhämtningen av nödvändig information. Dessutom kan databaser som innehåller tabeller med en en-till-en-relation inte anses vara helt normaliserade.

Liksom en en-till-många-relation kan en en-till-en-relation vara stel eller icke-stel.

DET GÄLLER: SQL Server (från och med 2016) Azure SQL Database Azure SQL Data WarehouseParallel Data Warehouse

Primära och främmande nycklar är två typer av begränsningar som kan användas för att upprätthålla dataintegriteten i SQL Server-tabeller. Dessa är viktiga databasobjekt.

Det här ämnet beskrivs i följande avsnitt.

Primära nyckelbegränsningar

Utländska nyckelbegränsningar

Relaterade uppgifter

Vanligtvis har en tabell en kolumn, eller en kombination av kolumner, som innehåller värden som unikt identifierar varje rad i tabellen. Denna kolumn, eller kolumnerna, kallas för tabellens primärnyckel (PK) och säkerställer integriteten för tabellens enhet. Primära nyckelbegränsningar definieras ofta i identitetskolumnen eftersom de garanterar att data är unika.

När du ställer in en primärnyckelrestriktion på en tabell, garanterar databasmotorn att data är unika genom att automatiskt skapa ett unikt index på primärnyckelkolumnerna. Detta index ger också snabb åtkomst till data när du använder primärnyckeln i frågor. Om en primärnyckelbegränsning är specificerad på mer än en kolumn, kan värdena dupliceras inom samma kolumn, men varje kombination av värdena för alla kolumner i definitionen av primärnyckelbegränsningen måste vara unik.

Som visas i följande figur, kolumnerna Serienummer och Leverantörs-ID i bordet Inköp.Produktleverantör bildar en sammansatt primärnyckelrestriktion för en given tabell. I det här fallet är det garanterat att varje rad i tabellen Produktleverantör har en unik kombination av värderingar Serienummer och Leverantörs-ID... Detta förhindrar att dubbletter av rader infogas.

Det kan bara finnas en primärnyckelrestriktion i en tabell.

Primärnyckeln får inte ha fler än 16 kolumner och den totala nyckellängden får inte överstiga 900 byte.

Ett index som bildas av en primärnyckelbegränsning kan inte orsaka att antalet index i en tabell överstiger 999 icke-klustrade och 1 klustrade index.

Om den primära nyckelbegränsningen inte anger om indexet är klustrat eller icke-klustrat, skapas ett klustrat index om ett sådant inte finns i tabellen.

Alla kolumner med en primärnyckelbegränsning måste definieras som icke-nullbara. Om nullbar inte anges, ställs alla kolumner med en primärnyckelbegränsning in som icke-nullbara.

Om primärnyckeln är definierad på en kolumn i en CLR UDD, måste implementeringen av den typen stödja binär sammanställning.

En främmande nyckel (FK) är en kolumn eller kombination av kolumner som används för att framtvinga en relation mellan data i två tabeller för att kontrollera data som kan lagras i en främmande nyckeltabell. Om en eller flera kolumner som innehåller primärnyckeln för en tabell refereras i en eller flera kolumner i en annan tabell, skapas en relation mellan de två tabellerna i den främmande nyckelreferensen. Denna kolumn blir en främmande nyckel i den andra tabellen.

Till exempel bord Sales.SalesOrderHeader kopplad till tabell Säljare. Säljare använder en främmande nyckel eftersom det finns ett logiskt samband mellan försäljningsorder och säljare. Kolumn Säljare-ID i bordet Sales.SalesOrderHeader matchar primärnyckelkolumnen i tabellen Försäljare... Kolumn Säljare-ID i bordet Sales.SalesOrderHeaderär en främmande nyckel till bordet Försäljare... Genom att etablera denna främmande nyckel relation, värdet för Säljare-ID kan inte infogas i tabellen SalesOrderHeader om det för närvarande inte finns i tabellen Försäljare.

Det maximala antalet tabeller och kolumner som en tabell kan referera till som främmande nycklar (utgående referenser) är 253. SQL Server 2016 ökar gränsen för antalet andra tabeller och kolumner som kan refereras av kolumner i samma tabell (inkommande referenser) från 253 upp till 10 000. (Kräver en kompatibilitetsnivå på minst 130.) Ökningen har följande begränsningar:

Överskridande av 253 främmande nyckelreferenser stöds endast för DML DELETE-operationer. UPDATE- och MERGE-operationer stöds inte.

Att överskrida 253 främmande nyckelreferenser är för närvarande inte tillgängligt för kolumnlagerindex, minnesoptimerade tabeller, Stretch-databas eller partitionerade främmande nyckeltabeller.

Indexer i främmande nyckelbegränsningar

Till skillnad från primärnyckelbegränsningar skapas inte motsvarande index automatiskt när du skapar en främmande nyckelbegränsning. Det är dock ofta nödvändigt att manuellt skapa ett index för en främmande nyckel av följande skäl:

Kolumner för främmande nyckel används ofta i kopplingskriterier när de används tillsammans för att söka efter data från relaterade tabeller. Den gör detta genom att mappa en kolumn eller kolumner i en främmande nyckelrestriktion i en tabell till en eller flera primära eller unika nyckelkolumner i en annan tabell. Ett index gör att databasmotorn snabbt kan hitta relaterade data i en främmande nyckeltabell. Det är dock valfritt att skapa ett index. Data från två relaterade tabeller kan kombineras även om inga begränsningar för primärnyckel eller främmande nyckel definieras mellan tabellerna, men en främmande nyckelrelation mellan de två tabellerna visar att de två tabellerna är optimerade för att användas tillsammans i en fråga där nycklar används som kriterier.

Restriktioner för främmande nyckel används för att validera ändringar av primärnyckelrestriktionerna på relaterade tabeller.

Referensintegritet

Huvudsyftet med en främmande nyckel-restriktion är att kontrollera data som kan lagras i främmande nyckeltabellen, men restriktionen styr också hur data i primärnyckeltabellen ändras. Till exempel när du tar bort en rad för en säljare från en tabell Säljare. Säljare vars ID används i försäljningsorder i en tabell Sales.SalesOrderHeader, kommer de två tabellernas referensintegritet att kränkas. Remote Manager försäljningsorder i en tabell SalesOrderHeader bli ogiltig utan att länka till data i tabellen Försäljare.

Den främmande nyckelbegränsningen förhindrar att denna situation uppstår. Begränsningen upprätthåller länkintegritet på följande sätt: den förhindrar att data i den primära nyckeltabellen ändras om sådana ändringar skulle ogiltigförklara referensen i den främmande nyckeltabellen. Om man, när man försöker ta bort en rad i primärnyckeltabellen eller ändra värdet på denna nyckel, upptäcker att det raderade eller ändrade värdet på primärnyckeln motsvarar ett specifikt värde i främmande nyckelbegränsningen i en annan tabell, då åtgärden kommer inte att utföras. För att framgångsrikt uppdatera eller ta bort en rad med en främmande nyckel-begränsning måste du först ta bort främmande nyckeldata i främmande nyckeltabellen, eller ändra data i främmande nyckeltabellen som länkar den främmande nyckeln till data från en annan primärnyckel.

Kaskadande referensintegritet

Med överlappande referensintegritetsbegränsningar kan du definiera åtgärden som databasmotorn vidtar när en användare försöker ta bort eller uppdatera en nyckel som fortfarande refereras av befintliga främmande nycklar. Följande kaskadåtgärder kan definieras.

INGEN ACTION
Databasmotorn genererar ett fel och återställer sedan borttagnings- eller uppdateringsoperationen på en rad i den överordnade tabellen.

KASKAD
Matchande rader uppdateras eller tas bort från den refererade tabellen om den givna raden uppdateras eller tas bort från den överordnade tabellen. CASCADE-värdet kan inte anges om kolumnen är av typen tidsstämpelär en del av en främmande eller refererad nyckel. Åtgärden ON DELETE CASCADE kan inte specificeras i en tabell för vilken en INSTEAD OF DELETE-utlösare är definierad. ON UPDATE CASCADE kan inte anges i tabeller för vilka INSTEAD OF UPDATE-utlösare är definierade.

SÄTT NULL
Alla värden som utgör en främmande nyckel sätts till NULL när motsvarande rad i den överordnade tabellen uppdateras eller tas bort. De yttre nyckelkolumnerna måste vara nullbara för att uppfylla denna begränsning. Kan inte ställas in på tabeller för vilka INSTEAD OF UPDATE-utlösare är definierade.

SÄTTA SOM NORMALT
Alla värden som utgör den främmande nyckeln är inställda på sina standardvärden när motsvarande rad i den överordnade tabellen raderas eller uppdateras. För att möta denna begränsning måste alla yttre nyckelkolumner ha standarddefinitioner. Om en kolumn är nullbar och en standard inte är explicit definierad, blir standardinställningen för kolumnen NULL. Kan inte ställas in på tabeller för vilka INSTEAD OF UPDATE-utlösare är definierade.

Nyckelorden CASCADE, SET NULL, SET DEFAULT och NO ACTION kan kombineras på tabeller som har ömsesidiga länkar. Om databasmotorn stöter på nyckelordet NO ACTION, stoppar den och rullar tillbaka de associerade CASCADE-, SET NULL- och SET DEFAULT-operationerna. Om en DELETE-sats innehåller en kombination av nyckelorden CASCADE, SET NULL, SET DEFAULT och NO ACTION, utförs alla CASCADE-, SET NULL- och SET DEFAULT-operationer innan databasmotorn söker efter NO ACTION.

Utlösare och överlappande referensåtgärder

Cascading referensåtgärder utlöses EFTER UPPDATERING eller EFTER DELETE utlöser enligt följande:

Alla överlappande referensåtgärder som anropas direkt av den ursprungliga DELETE- eller UPDATE-satsen exekveras först.

Om det finns några AFTER-utlösare definierade i de modifierade tabellerna, aktiveras dessa utlösare efter att alla kaskadåtgärder har utförts. Dessa utlösare utlöses i omvänd ordning av kaskadåtgärderna. Om flera triggers har definierats för samma tabell, aktiveras de i slumpmässig ordning, såvida inte den första och sista triggern i tabellen är markerade. Denna ordning bestäms av proceduren.

Om sekvenserna av kaskadåtgärder kommer från en tabell som var det direkta målet för DELETE- eller UPDATE-åtgärderna, anges inte i vilken ordning utlösare aktiveras av dessa sekvenser av åtgärder. Men en sekvens av åtgärder utlöser alltid alla dess utlösare före nästa.

AFTER-utlösaren för en tabell som var det direkta målet för en DELETE- eller UPDATE-åtgärd aktiveras oavsett om några rader har ändrats. I det här fallet påverkas inga andra tabeller av överlappningen.

Om en av de tidigare triggarna utför DELETE- eller UPDATE-operationer på andra tabeller, kan dessa operationer anropa sina egna kaskadsekvenser. Dessa sekundära arbetsflöden bearbetas för varje DELETE- eller UPDATE-operation efter att alla utlösare av de primära arbetsflödena har exekveras. Denna process kan upprepas rekursivt för efterföljande DELETE- eller UPDATE-operationer.

Utförande av CREATE, ALTER, DELETE eller andra DDL-operationer inuti triggers kan orsaka att DDL-triggers utlöses. Detta kan leda till ytterligare DELETE- eller UPDATE-operationer som startar ytterligare kaskadsekvenser och aktiverar deras utlösare.

Om ett fel inträffar i någon speciell sekvens av kaskadreferensåtgärder kommer inga AFTER-utlösare att aktiveras i den sekvensen, och DELETE- eller UPDATE-operationer som genereras av den sekvensen kommer att återställas.

En tabell som har en INSTEAD OF-trigger definierad kan också ha en REFERENCES-sats som indikerar en specifik kaskadåtgärd. En AFTER-utlösare på en överlappande måltabell kan dock köra en INSERT-, UPDATE- eller DELETE-sats på en annan tabell eller vy som utlöser en INSTEAD OF-utlösare på det objektet.

Följande tabell listar vanliga uppgifter relaterade till primärnyckel- och främmande nyckelbegränsningar.