Na obrázku je uvedená tabuľka (podiel stupňa 5) obsahujúca niektoré informácie o zamestnancoch hypotetického podniku. Riadky tabuľky zodpovedajú n-ticám. Každý riadok je vlastne popisom jedného objektu reálneho sveta (v tomto prípade zamestnanca), ktorého charakteristiky sú obsiahnuté v stĺpcoch. Relačné vzťahy zodpovedajú množinám entít, zatiaľ čo n-tice zodpovedajú entitám. Stĺpce v tabuľke predstavujúce relačný vzťah sa nazývajú atribúty.
Každý atribút je definovaný na doméne, takže doménu možno považovať za množinu platných hodnôt pre daný atribút. Na tej istej doméne možno definovať niekoľko atribútov toho istého vzťahu a dokonca aj atribúty rôznych vzťahov.
Zavolá sa atribút, ktorého hodnota jednoznačne identifikuje n-tice kľúč (alebo jednoducho kľúč). Kľúčom je atribút „Personálne číslo“, pretože jeho hodnota je jedinečná pre každého zamestnanca podniku. Ak sú n-tice identifikované iba zreťazením hodnôt niekoľkých atribútov, potom sa hovorí, že vzťah má zložený kľúč.
primárny kľúč- v relačnom dátovom modeli jeden z potenciálnych kľúčov vzťahu, zvolený ako hlavný kľúč (alebo predvolený kľúč).
Vzťah môže obsahovať viacero kľúčov. Vždy je deklarovaný jeden z kľúčov primárny, jeho hodnoty nie je možné aktualizovať. Všetky ostatné kľúče vzťahov sú volané možné kľúče.
Z hľadiska teórie sú všetky potenciálne (možné) kľúče vzťahu ekvivalentné, to znamená, že majú rovnaké vlastnosti jedinečnosti a minimality. Ako primárny sa však zvyčajne vyberie jeden z potenciálnych kľúčov, ktorý je najvhodnejší na určité praktické účely, napríklad na vytváranie externé kľúče inými spôsobmi alebo na vytvorenie zoskupeného indexu. Preto sa ako primárny kľúč zvyčajne vyberie ten, ktorý má najmenšiu veľkosť (fyzické úložisko) a/alebo obsahuje najmenej atribútov.
Ak primárny kľúč pozostáva z jediného atribútu, tzv jednoduchý kľúč.
Ak primárny kľúč pozostáva z dvoch alebo viacerých atribútov, tzv kompozitný kľúč. Meno, priezvisko, priezvisko, číslo pasu, séria pasov teda nemôžu byť primárnymi kľúčmi samostatne, pretože môžu byť rovnaké pre dvoch alebo viacerých ľudí. Neexistujú však dva osobné doklady rovnakého typu s rovnakou sériou a číslom. Preto vo vzťahu obsahujúcom údaje o osobách môže byť primárnym kľúčom podmnožina atribútov pozostávajúca z typu osobného dokladu, jeho série a čísla.
Na rozdiel od hierarchických a sieťové modelyúdaje v relácii neexistuje pojem skupinového vzťahu. Na vyjadrenie asociácií medzi n-ticemi rôznych vzťahov sa používa duplikácia ich kľúčov.
Atribúty, ktoré sú kópiami kľúčov iných vzťahov, sa nazývajú cudzie kľúče.
Napríklad vzťah medzi ODDELENÍM a ZAMESTNANCOM sa vytvorí skopírovaním primárneho kľúča "Číslo_oddelenia" z prvého vzťahu do druhého. Ak teda chcete získať zoznam zamestnancov daného pododdelenia, je potrebné: 1) V tabuľke ODDELENIE nastavte hodnotu atribútu "Číslo_oddelenia" Zodpovedajúce danému "Názov_oddelenia". 2) vybrať všetky záznamy z tabuľky ZAMESTNANC, hodnota atribútu "Číslo_oddelenia" ktorá sa rovná tomu, ktoré bolo získané v predchádzajúcom kroku. Aby ste zistili, na ktorom oddelení zamestnanec pracuje, musíte vykonať opačnú operáciu: 1) Určite "Číslo_oddelenia" z tabuľky ZAMESTNANCOV. 2) Na základe získanej hodnoty nájdeme záznam v tabuľke ODDELENIE.
18. Normalizácia v relačných databázach, koncept normálnej formy v návrhu databázy.
normálna forma - vlastnosť vzťahu v relačnom dátovom modeli, ktorá ho charakterizuje z hľadiska redundancie, čo môže potenciálne viesť k logicky chybným výsledkom vzorkovania alebo zmeny údajov. Normálna forma je definovaná ako súbor požiadaviek, ktoré musí vzťah spĺňať.
Proces konverzie databázy do formátu normálnej formy sa nazýva normalizácie . Normalizácia je určená na uvedenie štruktúry databázy do formy, ktorá poskytuje minimálnu redundanciu, to znamená, že normalizácia nie je určená na zníženie alebo zvýšenie výkonu alebo zníženie alebo zvýšenie veľkosti databázy. Konečným cieľom normalizácie je znížiť potenciálnu nekonzistentnosť informácií uložených v databáze.
Redundancia sa zvyčajne eliminuje rozkladom vzťahov takým spôsobom, že v každom vzťahu sú uložené len primárne fakty (teda fakty, ktoré nie sú odvodené od iných uložených faktov).
funkčné závislosti.
Relačná databáza obsahuje štrukturálne aj sémantické informácie. Štruktúra databázy je určená počtom a typom vzťahov, ktoré sú v nej zahrnuté, a vzťahmi jedna k mnohým, ktoré existujú medzi n-ticami týchto vzťahov. Sémantická časť popisuje množinu funkčných závislostí, ktoré existujú medzi atribútmi týchto vzťahov. Uveďme definíciu funkčnej závislosti.
19. 1NF: Základné definície a transformačné pravidlá.
Na diskusiu o prvej normálnej forme je potrebné uviesť dve definície:
jednoduchý atribút - atribút, ktorého hodnoty sú atómové (nedeliteľné).
Komplexný atribút - získava sa spojením niekoľkých atómových atribútov, ktoré možno definovať na rovnakých alebo rôznych doménach (nazýva sa aj vektorový alebo dátový agregát).
Definícia prvej normálnej formy:
vzťah je v 1NF, ak sú hodnoty všetkých jeho atribútov atómové. . Inak to vôbec nie je tabuľka a takéto atribúty treba rozložiť.
Zvážte príklad:
HR databáza podniku potrebuje uchovávať informácie o zamestnancoch, ktorých sa môžete pokúsiť reprezentovať vo vzťahu k nim
EMPLOYEE(EMPLOYEE_NUMBER, MENO, BIRTH_DATE, WORK_HISTORY, CHILDREN).
Z pozorného skúmania tohto vzťahu vyplýva, že atribúty "história práce" A "deti" sú zložité, navyše, atribút "história práce" obsahuje ďalší komplexný atribút "história_platu".
Tieto jednotky vyzerajú takto:
HISTORY_WORK (DATE_RECEPTION, NAME, HISTORY_SALARY),
HISTORY_SALARY (DATE_APPOINTMENT, SALARY),
CHILDREN (CHILD_NAME, BIRTH_YEAR).
Ich vzťah je znázornený na obr. 3.3.
Obr.3.3. Počiatočný vzťah.
Aby sa pôvodný vzťah ZAMESTNANEC dostal do prvej normálnej formy, je potrebné ho rozložiť na štyri vzťahy, ako je znázornené na nasledujúcom obrázku: 
Obr.3.4. Normalizovaná množina vzťahov.
Tu je primárny kľúč každého vzťahu zvýraznený modrou farbou, názvy cudzích kľúčov sú písané písmom modrej farby. Pripomeňme, že sú to cudzie kľúče, ktoré slúžia na reprezentáciu funkčných závislostí, ktoré existujú v pôvodnom vzťahu. Tieto funkčné závislosti sú označené čiarami so šípkami.
Normalizačný algoritmus opísal E.F. Codd takto:
- Počnúc vzťahom v hornej časti stromu (obrázok 3.3) sa vezme jeho primárny kľúč a každý bezprostredne podriadený vzťah sa rozšíri vložením domény alebo kombinácie domén tohto primárneho kľúča.
- Primárny kľúč každého takto rozšíreného vzťahu pozostáva z primárneho kľúča, ktorý mal vzťah pred rozšírením, a pridaného primárneho kľúča nadradeného vzťahu.
- Potom sa z rodičovského vzťahu odstránia všetky nejednoduché domény, odstráni sa horný uzol stromu a rovnaký postup sa zopakuje pre každý zo zostávajúcich podstromov.
20. 2NF: Základné definície a transformačné pravidlá.
Primárny kľúč vzťahu veľmi často obsahuje niekoľko atribútov (v takom prípade sa nazýva zložený) - pozri napríklad vzťah DETI znázornený na obr. 3.4 otázka 19. Týmto sa zavádza pojem plná funkčná závislosť.
Definícia:
Nekľúčový atribút je funkčne závislý od zloženého kľúča, ak je funkčne závislý od kľúča ako celku, ale nie je funkčne závislý od žiadneho z jeho základných atribútov.
Príklad:
Nech existuje relácia PONUKA (N_SUPPLIER, PRODUCT, PRICE).
Dodávateľ môže dodať rôzny tovar a ten istý tovar môžu dodať rôzni dodávatelia. Potom kľúč vzťahu je "N_dodávateľ + produkt". Nech všetci dodávatelia dodávajú tovar za rovnakú cenu. Potom máme nasledujúce funkčné závislosti:
- N_dodávateľ, položka -> cena
- produkt -> cena
Neúplná funkčná závislosť atribútu „cena“ od kľúča vedie k nasledujúcej anomálii: plné zobrazenie vzťah za účelom zmeny všetkých záznamov svojich dodávateľov. Táto anomália je dôsledkom skutočnosti, že dva sémantické fakty sú spojené v jednej dátovej štruktúre. Nasledujúce rozšírenie dáva vzťah v 2NF:
- DORUČENIE (N_SUPPLIER, PRODUKT)
- PRODUCT_PRICE (COMMODITY, PRICE)
Človek teda môže dať
Definícia druhej normálnej formy: Vzťah je v 2NF, ak je v 1NF a každý nekľúčový atribút je funkčne závislý od kľúča.
21. 3NF: Základné definície a transformačné pravidlá.
Pred diskusiou o tretej normálnej forme je potrebné predstaviť koncept: tranzitívna funkčná závislosť.
Definícia:
Nech X, Y, Z sú tri atribúty nejakého vzťahu. V tomto prípade X --> Y a Y --> Z, ale nedochádza k spätnej korešpondencii, t.j. Z -/-> Y a Y -/-> X. Potom Z tranzitívne závisí od X.
Nech existuje vzťah STORAGE ( FIRMA, SKLAD, OBJEM), ktorý obsahuje informácie o firmách prijímajúcich tovar zo skladov a objemy týchto skladov. Kľúčový atribút - "pevný". Ak každá firma môže prijímať tovar iba z jedného skladu, potom v tomto ohľade existujú tieto funkčné závislosti:
- firma -> zásob
- zásob -> objem
To vytvára anomálie:
- ak je v tento momentžiadna firma neprijíma tovar zo skladu, potom nie je možné zadať údaje o jeho objeme do databázy (pretože nie je definovaný atribút kľúča)
- ak sa zmení objem skladu, je potrebné si pozrieť celý vzťah a zmeniť karty pre všetky firmy spojené s týmto skladom.
Na odstránenie týchto anomálií je potrebné rozložiť pôvodný vzťah na dva:
- SKLADOVANIE ( FIRMA, SKLAD)
- STOCK_VOLUME ( STOCK, VOLUME)
Definícia tretej normálnej formy:
Vzťah je v 3NF, ak je v 2NF a každý nekľúčový atribút nie je prechodne závislý od primárneho kľúča.
Ide o elektronické úložiská informácií, ku ktorým sa pristupuje pomocou jedného alebo viacerých počítačov. Databázy sa zvyčajne vytvárajú na ukladanie a prístup k údajom obsahujúcim informácie o určitej tematickej oblasti, to znamená o určitej oblasti ľudskej činnosti alebo časti skutočného sveta.
DBMS je softvér na vytváranie, plnenie, aktualizáciu a mazanie databázy.
Jednotkou informácií uložených v databáze je tabuľka. Každá tabuľka je súborom riadkov a stĺpcov, kde riadky zodpovedajú inštancii objektu, konkrétnej udalosti alebo javu a stĺpce zodpovedajú atribútom (vlastnostiam, charakteristikám, parametrom) objektu, udalosti alebo javu. Každý riadok obsahuje informácie o konkrétnej udalosti.
Z hľadiska databázy sa stĺpce tabuľky nazývajú polia a jej riadky sa nazývajú záznamy.
Medzi jednotlivými databázovými tabuľkami môžu existovať vzťahy, to znamená, že informácie z predchádzajúcej tabuľky môžu byť pridané do inej. Databázy, medzi jednotlivými tabuľkami, ktorých prepojenia sú, sa nazývajú relačné. Tá istá tabuľka môže byť hlavnou databázovou tabuľkou a potomkom inej.
Vzťahové tabuľky interagujú vo vzťahu majster-dieťa. Tá istá tabuľka môže byť hlavnou databázovou tabuľkou a potomkom inej.
Objekt je niečo, čo existuje a je rozlíšiteľné a má súbor vlastností. Rozdiel medzi jedným objektom a iným objektom je určený špecifickými hodnotami vlastností.
Esencia - odraz predmetu v pamäti človeka alebo počítača.
Atribút - konkrétna hodnota niektorej z vlastností entity.
Lúka je element s jednou položkou, ktorý uchováva konkrétnu hodnotu atribútu.
Komunikačné pole – je pole, ktorým súvisia dve tabuľky.
Primárny a sekundárny kľúč
Každá tabuľka databázy môže mať primárny kľúč – ide o pole alebo množinu polí, ktoré jednoznačne identifikujú záznam.
Hodnota primárneho kľúča v databázovej tabuľke musí byť jedinečná, to znamená, že v tabuľke nesmú byť dva alebo viac záznamov s rovnakou hodnotou primárneho kľúča.
Primárne kľúče uľahčujú vytváranie vzťahov medzi tabuľkami. Keďže primárny kľúč musí byť jedinečný, nemožno naň použiť všetky polia v tabuľke.
Ak tabuľka nemá polia, ktorých hodnoty sú jedinečné, na vytvorenie primárneho kľúča sa do nej zvyčajne vloží ďalšie číselné pole, s hodnotami ktorých môže DBMS disponovať podľa vlastného uváženia.
Sekundárne kľúče sa nastavujú podľa poľa, ktoré sa často používa pri vyhľadávaní alebo triedení údajov: indexy postavené na sekundárnych kľúčoch pomôžu systému oveľa rýchlejšie nájsť potrebné hodnoty uložené v zodpovedajúcich poliach.
Na rozdiel od primárnych kľúčov môžu polia pre sekundárne kľúče obsahovať nejedinečné informácie.
Relačné vzťahy medzi tabuľkami
Jeden na jedného. Vzťah jedna k jednej existuje vtedy, keď jeden záznam v nadradenej tabuľke zodpovedá jednému záznamu v podradenej tabuľke.
Tento vzťah je oveľa menej bežný ako vzťah jeden k mnohým, používa sa, ak nechcete, aby tabuľka databázy narástla zo sekundárnej tabuľky. Vzťah jedna k jednej spôsobuje, že viaceré čítania čítajú súvisiace informácie vo viacerých tabuľkách, čím sa spomalí získavanie informácií, ktoré potrebujete. Okrem toho databázy, ktoré obsahujú tabuľky so vzťahom jedna k jednej, nemožno považovať za úplne normalizované.
Podobne ako vzťah jeden k mnohým, aj vzťah jeden k jednému môže byť buď rigidný, alebo nerigidný.
Takto sme nenápadne pristúpili k veľmi dôležitej téme – primárnemu a cudziemu kľúču. Ak prvý používa takmer každý, potom druhý z nejakého dôvodu ignoruje. Ale márne. Cudzie kľúče nie sú problémom, sú skutočným pomocníkom v integrite dát.
1.2.5. primárny kľúč
O kľúčových poliach sme už veľa hovorili, ale nikdy sme ich nepoužili. Najzaujímavejšie je, že všetko fungovalo. To je výhoda, alebo možno nevýhoda základne údaje spoločnosti Microsoft SQL Server a MS Access. V tabuľkách Paradox tento trik nebude fungovať a bez prítomnosti kľúčového poľa bude tabuľka len na čítanie.
Do určitej miery sú kľúče obmedzenia a mohli by sa zvážiť spolu s príkazom CHECK, pretože deklarácia prebieha podobným spôsobom a dokonca sa používa aj príkaz CONSTRAINT. Pozrime sa na tento proces na príklade. Na tento účel si vytvoríme tabuľku dvoch polí „guid“ a „vcName“. V tomto prípade je pole „guid“ nastavené ako primárny kľúč:
CREATE TABLE Globally_Unique_Data (jedinečný identifikátor guid DEFAULT NEWID(), vcName varchar(50), CONSTRAINT PK_guid PRIMARY KEY (Guid))
Najchutnejšia vec je tu rad CONSTRAINT. Ako vieme, za týmto kľúčovým slovom nasleduje názov obmedzenia a deklarácia kľúča nie je výnimkou. Na pomenovanie primárneho kľúča odporúčam použiť PK_name, kde name je názov poľa, ktoré by sa malo stať hlavným kľúčom. Skratka PK pochádza z primárneho kľúča (primárny kľúč).
Potom je namiesto kľúčového slova CHECK, ktoré sme použili v obmedzeniach, príkaz PRIMARY KEY, čo znamená, že nepotrebujeme kontrolu, ale primárny kľúč. Zátvorky označujú jedno alebo viac polí, ktoré budú tvoriť kľúč.
Pamätajte, že kľúčové pole nemôže obsahovať rovnakú hodnotu dva riadky, v tomto ohľade je obmedzenie primárneho kľúča totožné s obmedzením jedinečného. To znamená, že ak z poľa na uloženie priezviska urobíte primárny kľúč, tak do takejto tabuľky nebude možné zapísať dvoch Ivanov s rôznymi menami. Toto porušuje obmedzenie primárneho kľúča. To je dôvod, prečo sú kľúče obmedzeniami a sú deklarované ako rovnaké ako obmedzenie CHECK. To však neplatí len pre primárne kľúče a sekundárne kľúče s jedinečnosťou.
IN tento príklad, primárny kľúč je pole typu uniqueidentifier (GUID). Predvolená hodnota pre toto pole je výsledkom vykonania procedúry servera NEWID.
Pozornosť
Pre tabuľku je možné vytvoriť iba jeden primárny kľúč
Pre jednoduchosť príkladov je žiaduce použiť ako kľúč číselný typ a ak to databáza umožňuje, bude lepšie, ak bude typu "autoincrement" (automaticky sa zvyšuje / znižuje číslo). V MS SQL Server je takýmto poľom IDENTITA a v MS Access je to pole typu „počítadlo“.
Nasledujúci príklad ukazuje, ako vytvoriť tabuľku produktov s automatickým prírastkovým celočíselným poľom ako primárnym kľúčom:
CREATE TABLE Products (id int IDENTITY(1, 1), product varchar(50), Price money, Množstvo numeric (10, 2), CONSTRAINT PK_id PRIMARY KEY (id))
Práve tento typ kľúča budeme používať najčastejšie, pretože čísla, ktoré sú dobre čitateľné, sa uložia do poľa kľúča a práca s nimi je jednoduchšia a názornejšia.
Primárny kľúč môže obsahovať viac ako jeden stĺpec. Nasledujúci príklad vytvorí tabuľku, v ktorej polia „id“ a „Product“ tvoria primárny kľúč, čo znamená, že pre obe polia sa vytvorí jedinečný index:
CREATE TABLE Products1 (id int IDENTITY(1, 1), Product varchar(50), Price money, Množstvo numeric (10, 2), CONSTRAINT PK_id PRIMARY KEY (id, [Názov produktu]))
Programátori veľmi často vytvárajú databázu s kľúčovým poľom v tvare celého čísla, no zároveň je v úlohe jasné, že určité polia musia byť jedinečné. A prečo hneď nevytvoriť primárny kľúč z tých polí, ktoré by mali byť jedinečné a nebude potrebné vytvárať samostatné riešenia tohto problému.
Jedinou nevýhodou viacstĺpcového primárneho kľúča je problém s vytváraním vzťahov. Tu sa musíte dostať von rôznymi metódami, ale problém je stále riešiteľný. Stačí zadať pole typu uniqueidentifier a nadviazať spojenie. Áno, v tomto prípade získame jedinečný primárny kľúč a pole typu uniqueidentifier, ale táto redundancia v dôsledku toho nebude väčšia ako tá istá tabuľka, kde je primárnym kľúčom jedinečný identifikátor, a obmedzenia jedinečnosti sú nastavené na polia, ktoré by mali byť jedinečný. Čo si vybrať? Závisí to od konkrétnej úlohy a od toho, s čím sa vám viac pracuje.
1.2.6. Externý kľúč
Cudzí kľúč je tiež obmedzením CONSTRAINT a predstavuje vzťah medzi dvoma tabuľkami. Povedzme, že máte dve tabuľky:
- Mená – obsahuje mená osôb a skladá sa z polí identifikátora (pole kľúča), mena.
- Telefóny je tabuľka telefónov, ktorá pozostáva z identifikátora (pola kľúča), cudzieho kľúča na prepojenie s tabuľkou mien a poľa reťazca na uloženie telefónneho čísla.
Jedna osoba môže mať viacero telefónov, preto sme ukladanie dát rozdelili do rôznych tabuliek. Obrázok 1.4 vizuálne znázorňuje vzťah medzi týmito dvoma tabuľkami. Ak ste už pracovali s prepojenými tabuľkami, bude vám to stačiť. Ak počujete o spojeniach prvýkrát, skúsme sa na problém pozrieť bližšie.
Vezmime si napríklad stôl troch ľudí. Tabuľka 1.3 zobrazuje obsah tabuľky „Názvy“. Existujú iba tri riadky a každý má svoj vlastný jedinečný hlavný kľúč. Pre jedinečnosť pri vytváraní tabuľky spravíme z kľúča automaticky inkrementované pole.
Tabuľka 1.3 Obsah tabuľky Názvy
Tabuľka 1.4. Obsah tabuľky Telefóny
Tabuľka 1.4 obsahuje päť telefónnych čísel. Pole hlavného kľúča má tiež jedinečný hlavný kľúč, ktorý sa môže tiež automaticky zvyšovať. Sekundárny kľúč je vzťah k primárnemu kľúču tabuľky Názvy. Ako toto spojenie funguje? Petrov má v tabuľke Mená ako hlavný kľúč číslo 1. V tabuľke Telefóny hľadáme v sekundárnom kľúči číslo 1 a získame Petrovove telefónne čísla. To isté platí pre ostatné položky. Vizuálne je zapojenie vidieť na obrázku 1.5.
Takéto ukladanie dát je veľmi pohodlné. Ak by nebolo možné vytvárať prepojené tabuľky, tak v tabuľke Mená by sme museli vyplniť všetky telefónne čísla do jedného poľa. Je to nepohodlné z hľadiska používania, podpory a získavania údajov.
V tabuľke môžete vytvoriť viacero polí názvov, otázkou však je, koľko. Jedna osoba môže mať len 1 telefón a ja ich mám napríklad 3, nerátajúc pracovníkov. Veľký počet polí vedie k redundancii údajov.
Pre každý telefón v tabuľke Mená je možné mať samostatný riadok s priezviskom, ale je to jednoduché len pre toto jednoduchý príklad keď potrebujete zadať iba priezvisko a môžete ľahko urobiť niekoľko záznamov pre Petrov s niekoľkými telefónnymi číslami. A ak je tam 10 alebo 20 polí? Takže vytvorenie dvoch tabuliek spojených cudzím kľúčom je možné vidieť vo výpise 1.6.
Výpis 1.6. Vytváranie tabuliek prepojených cudzím kľúčom
CREATE TABLE Mená (idName int IDENTITY(1,1), vcName varchar(50), CONSTRAINT PK_guid PRIMARY KEY (idName),) CREATE TABLE Phones (idPhone int IDENTITY(1,1), idName int, vcPhone varchar(10), OBMEDZENIE PK_idPhone PRIMÁRNY KĽÚČ (idPhone), OBMEDZENIE FK_idName CUDZÍ KĽÚČ (idName) REFERENCIE Mená (idName))
Pozorne si prečítajte obsah zoznamu. Je to dosť zaujímavé, pretože používa niektorých operátorov, ktorých sme už prebrali, a ďalší príklad by bol fajn. Pre obe tabuľky sa vytvorí kľúčové pole, ktoré je na prvom mieste, je typu int a automaticky sa zvyšuje od 1 v prírastkoch po jednej. Pole kľúča sa stane hlavným kľúčom s obmedzením CONSTRAINT.
V popise tabuľky Telefóny posledný riadok obsahuje pre nás novú deklaráciu, a to deklaráciu cudzieho kľúča pomocou operátora FOREIGN KEY. Ako vidíte, aj toto je obmedzenie a o niečo neskôr uvidíte prečo. Zátvorky označujú pole tabuľky, ktoré by malo byť prepojené s inou tabuľkou. Nasleduje kľúčové slovo REFERENCES (odkaz), názov tabuľky, s ktorou má byť vzťah (Names) a v zátvorke názov poľa ("idName"). Takto sme nadviazali spojenie, ktoré je znázornené na obrázku 1.4.
Pozor!
Cudzí kľúč môže odkazovať iba na primárny kľúč inej tabuľky alebo na jedinečné obmedzenie. To znamená, že za kľúčovým slovom REFERENCES musí nasledovať názov tabuľky a v zátvorkách možno zadať iba primárny kľúč alebo pole s obmedzením UNIQUE. Iné polia nie je možné zadať.
Teraz, ak môžete vyplniť tabuľky údajmi. Nasledujúce tri príkazy pridávajú tri priezviská, ktoré sme videli v tabuľke 1.3:
INSERT INTO Names(vcName) VALUES("Petrov") INSERT INTO Names(vcName) VALUES("Ivanov") INSERT INTO Names(vcName) VALUES("Sidorov")
Ak ste už pracovali s SQL, môžete pridať záznamy aj pre telefónny stôl. Tieto príkazy vynechám, ale môžete si ich pozrieť v súbore Foreign_keys.sql v adresári Chapter1 na CD.
Našou úlohou je teraz zistiť, aké sú obmedzujúce akcie cudzieho kľúča, poďme na to. Naznačili sme explicitný vzťah medzi dvoma poľami v rôznych tabuľkách. Ak sa pokúsite pridať do telefónneho stola záznam s identifikátorom v poli "idName", ktorý neexistuje v poli s rovnakým menom (meno sa mohlo zmeniť) v tabuľke s priezviskami, dôjde k chybe . Tým sa preruší vzťah medzi týmito dvoma tabuľkami a obmedzenie cudzieho kľúča zabráni existencii záznamov bez vzťahu.
Obmedzenie platí aj pri zmene alebo vymazaní záznamov. Ak sa napríklad pokúsite odstrániť riadok s priezviskom Petrov, zobrazí sa chyba obmedzenia cudzieho kľúča. Nemôžete odstrániť záznamy, ktoré majú externe súvisiace riadky. Najprv musíte vymazať všetky telefóny pre tento záznam a až potom bude možné vymazať samotný riadok s názvom Petrov.
Počas vytvárania cudzieho kľúča je možné zadať ON DELETE CASCADE alebo ON UPDATE CASCADE. V tomto prípade, ak vymažete záznam Petrov z tabuľky Mená alebo zmeníte identifikátor, všetky záznamy v tabuľke Telefóny priradené k riadku Petrov sa automaticky aktualizujú. Nikdy. Nie, musíte napísať veľkými písmenami: NIKDY to nerobte. Všetko je potrebné odstrániť alebo zmeniť ručne. Ak používateľ omylom vymaže záznam z tabuľky Mená, vymažú sa aj príslušné telefóny. Potom má zmysel vytvoriť cudzí kľúč, ak zmizne polovica jeho obmedzujúcej sily! Všetko sa musí robiť iba ručne a vôbec sa neodporúča meniť identifikátory.
Mazanie samotných tabuliek musí začínať aj podriadenou tabuľkou, teda Telefónmi a až potom je možné vymazať hlavnú tabuľku Mená.
Nakoniec vám ukážem, ako krásne spájať mená a telefónne čísla z dvoch tabuliek:
SELECT vcName, vcPhone FROM Mená, Telefóny WHERE Names.idName=Phones.idName
Viac o týchto typoch dotazov si povieme v kapitole 2. Zatiaľ som uviedol príklad, aby som vám ukázal silu prepojených tabuliek.
Tabuľka môže obsahovať až 253 cudzích kľúčov, čo stačí aj pre tie najzložitejšie databázy. Osobne som musel pracovať s databázami, kde počet cudzích kľúčov nepresiahol 7 na tabuľku. Ak viac, potom je s najväčšou pravdepodobnosťou databáza navrhnutá nesprávne, aj keď existujú výnimky.
Aj samotná tabuľka môže mať maximálne 253 cudzích kľúčov. Cudzie kľúče v tabuľke sú menej bežné, väčšinou nie viac ako 3. Najčastejšie môže mať tabuľka veľa odkazov na iné tabuľky.
Cudzí kľúč môže odkazovať na rovnakú tabuľku, v ktorej je vytvorený. Napríklad máte tabuľku pozícií v organizácii, ako je uvedené v tabuľke 1.5. Tabuľka pozostáva z troch polí: primárny kľúč, cudzí kľúč a pracovná pozícia. V každej organizácii môže byť veľa pozícií, ale bolo by celkom logické zobraziť ich názvy a štruktúru podriadenosti v jednej tabuľke. Na tento účel musí byť cudzí kľúč spojený s primárnym kľúčom tabuľky úloh.
Tabuľka 1.5. Tabuľka s interným odkazom
V dôsledku toho dostaneme, že CEO má nulový cudzí kľúč, t.j. táto pozícia je na čele všetkých ostatných. Pre obchodného riaditeľa a generálneho riaditeľa je cudzím kľúčom riadok generálneho riaditeľa. To znamená, že tieto dve pozície sú priamo podriadené generálnemu riaditeľovi. A tak ďalej.
Pozrime sa, ako to všetko môžeme vytvoriť vo forme SQL dotazu:
CREATE TABLE Pozície (idPosition int IDENTITY(1,1), idParentPosition int, vcName varchar(30), OBMEDZENIE PK_idPosition PRIMÁRNY KĽÚČ (idPosition), OBMEDZENIE FK_idParentPosition CUDZÍ KĽÚČ (idParentPosition) REFERENCES Pozície)
Ako vidíte, cudzí kľúč jednoducho odkazuje na rovnakú tabuľku, ktorú vytvárame. Na CD v adresári Chapter1 vidíte v súbore Foreign_keys_to_self.sql príklad vytvorenia tejto tabuľky, jej naplnenia údajmi a zobrazenia pozícií s prihliadnutím na ich podriadenosť. V ďalšej kapitole sa pozrieme na možnosť práce s takýmito tabuľkami podrobnejšie.
Vzťah jeden k jednému
Doteraz sme uvažovali o klasickom vzťahu, kedy jeden riadok hlavnej tabuľky údajov zodpovedá jednému riadku z pridruženej tabuľky. Takýto vzťah sa nazýva one-to-many. Existujú však aj iné vzťahy a teraz zvážime ďalší - jeden k jednému, keď jeden záznam v hlavnej tabuľke súvisí s jedným záznamom v druhom. Na implementáciu stačí prepojiť primárne kľúče oboch tabuliek. Keďže primárne kľúče sa nedajú opakovať, v oboch tabuľkách môže súvisieť iba jeden riadok.
Nasledujúci príklad vytvorí dve tabuľky, ktoré majú vzťah medzi primárnymi kľúčmi:
CREATE TABLE Mená (idName uniqueidentifier DEFAULT NEWID(), vcName varchar(50), CONSTRAINT PK_guid PRIMARY KEY (idName)) CREATE TABLE Phones (iPhone uniqueidentifier DEFAULT NEWID(), vcPhone varchar(10), CONSTRAINT (PRIIDMARYidPhoKEY) OBMEDZENIE FK_idPhone CUDZÍ KĽÚČ (idPhone) REFERENCIE Mená (idName))
Iba jedna z tabuliek potrebuje cudzí kľúč. Keďže vzťah je jedna k jednej, nezáleží na tom, v ktorej tabuľke sa vytvorí.
veľa mnohým
Najkomplexnejší vzťah je mnoho k mnohým, kde sa veľa záznamov z jednej tabuľky zhoduje s mnohými záznamami z inej tabuľky. Na implementáciu nestačia dve tabuľky, sú potrebné tri tabuľky.
Najprv musíte pochopiť, kedy možno použiť vzťah „mnohý k mnohým“? Povedzme, že máte dve tabuľky: zoznam obyvateľov domu a zoznam telefónnych čísel. V jednom byte môže byť aj viac čísel, čo znamená, že k rovnakému priezvisku môžu patriť dva telefóny. Takže je to vzťah jeden k mnohým. Na druhej strane môžu byť v jednom byte dve rodiny (obecný byt alebo len nájomník, ktorý používa telefón majiteľa), čo znamená, že aj vzťah medzi telefónom a obyvateľom je jeden k mnohým. A najťažšou možnosťou je mať dva telefóny v spoločnom byte. V tomto prípade viacerí obyvatelia bytu používajú obe čísla. Ukazuje sa teda, že „veľa“ rodín môže používať „veľa“ telefónov (komunikácia medzi mnohými).
Ako implementovať vzťah mnoho k mnohým? Na prvý pohľad je to v relatívnom modeli nemožné. Pred 10 rokmi som hľadal rôzne varianty Výsledkom je vytvorenie jednej tabuľky, ktorá bola preplnená redundanciou údajov. Jedného dňa som však dostal jednu úlohu, vďaka ktorej vyšlo na povrch vynikajúce riešenie už z podmienky - musíte vytvoriť dve tabuľky obyvateľov bytov a telefónov a implementovať do nich iba primárny kľúč. V tejto tabuľke nie sú potrebné cudzie kľúče. A tu komunikácia medzi stolmi musí prebiehať cez tretí, spojovací stôl. Na prvý pohľad je to ťažké a nejasné, ale keď pochopíte túto metódu, uvidíte plnú silu tohto riešenia.
Tabuľky 1.6 a 1.7 zobrazujú príklady tabuliek priezvisk a telefónov. A tabuľka 1.8 zobrazuje tabuľku odkazov.
Tabuľka 1.6. Tabuľka priezvisk
Tabuľka 1.7. Telefónny stolík
Tabuľka 1.8. Telefónny stolík
Pozrime sa teraz, aká bude logika vyhľadávania údajov vo vzťahu mnoho k mnohým. Povedzme, že musíme nájsť všetky telefóny, ktoré patria Ivanovovi. Ivanov má primárny kľúč rovný 1. V prepájacej tabuľke nájdeme všetky záznamy, v ktorých sa pole „Vzťah s menom“ rovná 1. Pôjde o záznamy 1 a 2. V týchto záznamoch sa nachádzajú identifikátory 1 a 2 v poli „Vzťah s telefónom“, a tak Ivanov vlastní čísla z telefónneho stola, ktoré sa nachádzajú v riadkoch 1 a 2.
Teraz poďme vyriešiť inverzný problém - určiť, kto má prístup k telefónnemu číslu 567575677. Toto číslo v tabuľke telefónov má kľúč 3. Hľadáme všetky záznamy v tabuľke odkazov, kde sa pole "Spojenie s telefónom" rovná až 3. Ide o záznamy s číslami 4 a 5, ktoré v poli „Vzťah k názvu“ obsahujú hodnoty 2 a 3. Ak sa teraz pozriete na tabuľku priezvisk, pod číslami 2 a 3 uvidíte Petrova a Sidorova. Čiže práve títo dvaja obyvatelia používajú telefónne číslo 567575677.
Prejdite si všetky tri tabuľky a uistite sa, že rozumiete, ktoré telefónne čísla patria ktorým obyvateľom a naopak. Ak uvidíte toto spojenie, pochopíte, že je to jednoduché ako tri groše a rýchlo ho môžete implementovať do svojich projektov.
CREATE TABLE Mená (idName uniqueidentifier DEFAULT NEWID(), vcName varchar(50), CONSTRAINT PK_guid PRIMARY KEY (idName)) CREATE TABLE Phones (idPhone uniqueidentifier DEFAULT NEWID(), vcPhone varchar(10), CONSTRAINT)hone (PRIIDMARYidPneKEY) CREATE TABLE LinkTable (idLinkTable uniqueidentifier DEFAULT NEWID(), idName uniqueidentifier, idPhone uniqueidentifier, CONSTRAINT PK_idLinkTable PRIMÁRNY KĽÚČ (idLinkTable), CONSTRAINT FK_idPhone CUDZÍ KĽÚČ (idPhone) Nazov REFERENCIE Telefóny (idPhone FOREIGN) CONFERENCE idPhone FOREIGN )
Spojovacia tabuľka má dva cudzie kľúče, ktoré sa spájajú s tabuľkami mien a telefónov, a jeden primárny kľúč, ktorý robí záznamy jedinečnými.
Ako primárny kľúč som zvolil pole GUID, pretože je vhodnejšie na riešenie tejto konkrétnej úlohy. Ide o to, že záznamy potrebujeme vložiť do dvoch tabuliek a v oboch prípadoch je potrebné zadať rovnaký kľúč. Hodnotu GUID je možné vygenerovať a následne použiť pri vkladaní údajov do oboch tabuliek.
Ako kľúč môžete použiť aj pole s automatickým prírastkom, ale v tomto prípade sa problém rieši trochu ťažšie, presnejšie povedané, je nepohodlné problém vyriešiť. Napríklad pri pridávaní telefónneho čísla musíte najskôr vložiť príslušný riadok do tabuľky, potom ho nájsť, určiť kľúč, ktorý bol priradený riadku, a potom nadviazať spojenie.
V tejto fáze sa obmedzujeme len na vytváranie tabuliek a v časti 2.8 sa k tejto téme vrátime a naučíme sa a naučíme sa pracovať so súvisiacimi tabuľkami. Práca so vzťahmi one-to-one a one-to-many sa príliš nelíši, pretože v tejto schéme sú zahrnuté iba dve tabuľky. Vzťah many-to-many je trochu komplikovanejší kvôli tabuľke spájania, preto sa mu budeme venovať samostatne v časti 2.27.
Posledná aktualizácia: 27.04.2019
Cudzie kľúče umožňujú vytvárať vzťahy medzi tabuľkami. Cudzí kľúč je nastavený na stĺpce zo závislej, podriadenej tabuľky a ukazuje na jeden zo stĺpcov z hlavnej tabuľky. Cudzí kľúč zvyčajne ukazuje na primárny kľúč zo súvisiacej hlavnej tabuľky.
Všeobecná syntax pre nastavenie cudzieho kľúča na úrovni tabuľky je:
CUDZÍ KĽÚČ (stĺpec1, stĺpec2, ... stĺpecN) ODKAZY hlavná_tabuľka (hlavná_tabuľka_stĺpec1,_hlavná_tabuľka_stĺpec2, ... hlavná_tabuľka_stĺpecN)
Ak chcete vytvoriť obmedzenie cudzieho kľúča, za CUDZÍM KĽÚČOM nasleduje stĺpec tabuľky, ktorý bude reprezentovať cudzí kľúč. Za kľúčovým slovom REFERENCES nasleduje názov súvisiacej tabuľky, za ktorým nasleduje názov súvisiaceho stĺpca v zátvorkách, na ktorý bude cudzí kľúč ukazovať. Po výraze REFERENCES nasledujú výrazy ON DELETE a ON UPDATE, ktoré definujú akciu, ktorá sa má vykonať pri vymazaní a aktualizácii riadka z hlavnej tabuľky.
Napríklad definujme dve tabuľky a prepojme ich s cudzím kľúčom:
CREATE TABLE Zákazníci (Id INT PRIMARY KEY AUTO_INCREMENT, Vek INT, Meno VARCHAR(20) NOT NULL, Priezvisko VARCHAR(20) NOT NULL, Phone VARCHAR(20) NOT NULL UNIQUE); CREATE TABLE Orders(Id INT PRIMARY KEY AUTO_INCREMENT, CustomerId INT, CreatedAt Date, FOREIGN KEY(CustomerId) REFERENCIE Customers(Id));
V tomto prípade sú definované tabuľky Zákazníci a Objednávky. Zákazníci sú hlavnými a zastupujú zákazníka. Objednávky sú závislé a predstavujú objednávku zadanú zákazníkom. Tabuľka Objednávky je prepojená prostredníctvom stĺpca CustomerId s tabuľkou Customers a jej stĺpcom Id. To znamená, že stĺpec CustomerId je cudzí kľúč, ktorý ukazuje na stĺpec Id z tabuľky Customers.
Pomocou príkazu CONSTRAINT môžete zadať názov obmedzenia cudzieho kľúča:
CREATE TABLE Objednávky (Id INT PRIMARY KEY AUTO_INCREMENT, CustomerId INT, CreatedAt Date, CONSTRAINT orders_custonmers_fk CUDZÍ KĽÚČ (CustomerId) REFERENCIE Zákazníci (Id));
PRI VYMAZANÍ a AKTUALIZÁCII
Pomocou príkazov ON DELETE a ON UPDATE môžete nastaviť akcie, ktoré sa vykonajú pri odstránení a aktualizácii súvisiaceho riadka z hlavnej tabuľky. Nasledujúce možnosti možno použiť ako akciu:
CASCADE : Automaticky vymaže alebo zmení riadky zo závislej tabuľky, keď sa vymažú alebo zmenia súvisiace riadky v hlavnej tabuľke.
SET NULL : Pri odstraňovaní alebo aktualizácii súvisiaceho riadka z hlavnej tabuľky nastaví stĺpec cudzieho kľúča na hodnotu NULL . (V tomto prípade musí stĺpec cudzieho kľúča podporovať nastavenie NULL)
OBMEDZENIE : Odmietne vymazanie alebo úpravu riadkov v hlavnej tabuľke, ak sú v závislej tabuľke súvisiace riadky.
ŽIADNA AKCIA: rovnaké ako OBMEDZENIE.
SET DEFAULT : Pri odstraňovaní súvisiaceho riadka z hlavnej tabuľky nastaví stĺpec cudzieho kľúča na predvolenú hodnotu, ktorá sa nastaví pomocou atribútov DEFAULT. Aj keď je táto možnosť v zásade dostupná, engine InnoDB tento výraz nepodporuje.
Kaskádové odstránenie
Kaskádové odstránenie vám umožňuje automaticky odstrániť všetky súvisiace riadky zo závislej tabuľky, keď odstránite riadok z hlavnej tabuľky. Ak to chcete urobiť, použite možnosť CASCADE:
VYTVORENIE TABUĽKY Objednávky (Id INT PRIMARY KEY AUTO_INCREMENT, CustomerId INT, CreatedAt Date, CUDZÍ KĽÚČ (CustomerId) REFERENCIE Zákazníci (Id) ON DELETE CASCADE);
Príkaz ON UPDATE CASCADE funguje podobným spôsobom. Zmena hodnoty primárneho kľúča automaticky zmení hodnotu priradeného cudzieho kľúča. Keďže sa však primárne kľúče menia veľmi zriedkavo a vo všeobecnosti sa neodporúča používať stĺpce s meniteľnými hodnotami ako primárne kľúče, príkaz ON UPDATE sa v praxi používa len zriedka.
Nastavenie NULL
Nastavenie cudzieho kľúča na SET NULL vyžaduje, aby stĺpec cudzieho kľúča mohol mať hodnotu null:
CREATE TABLE Objednávky (Id INT PRIMARY KEY AUTO_INCREMENT, CustomerId INT, CreatedAt Date, FOREIGN KEY (CustomerId) REFERENCIE Zákazníci (Id) ON DELETE SET NULL);
Posledná aktualizácia: 07/09/2017
Cudzie kľúče sa používajú na vytvorenie vzťahov medzi tabuľkami. Cudzí kľúč je nastavený na stĺpce zo závislej, podriadenej tabuľky a ukazuje na jeden zo stĺpcov z hlavnej tabuľky. Hoci cudzí kľúč spravidla ukazuje na primárny kľúč z pridruženej hlavnej tabuľky, nemusí to byť sine qua non. Cudzí kľúč môže ukazovať aj na iný stĺpec, ktorý má jedinečnú hodnotu.
Všeobecná syntax pre nastavenie cudzieho kľúča na úrovni stĺpca je:
REFERENCIE main_table (column_main_table)
Ak chcete vytvoriť obmedzenie cudzieho kľúča na úrovni stĺpca, za kľúčovým slovom REFERENCES nasleduje názov súvisiacej tabuľky a v zátvorkách názov súvisiaceho stĺpca, na ktorý bude cudzí kľúč ukazovať. Tiež sa zvyčajne pridáva Kľúčové slová CUDZÍ KĽÚČ , ale v zásade nie je potrebné ich špecifikovať. Po výraze REFERENCES nasleduje výraz ON DELETE a ON UPDATE.
Všeobecná syntax pre nastavenie cudzieho kľúča na úrovni tabuľky je:
CUDZÍ KĽÚČ (stĺpec1, stĺpec2, ... stĺpecN) REFERENCIE main_table (main_table_column1, main_table_column2, ... main_table_column)
Napríklad definujme dve tabuľky a prepojme ich s cudzím kľúčom:
VYTVORIŤ TABUĽKU Zákazníci (ID INT IDENTITA PRIMÁRNEHO KĽÚČA, Vek INT VÝCHOZÍ 18, Meno NVARCHAR(20) NIE JE NULL, Priezvisko NVARCHAR(20) NIE JE NULL, E-mail VARCHAR(30) JEDINEČNÉ, Telefón VARCHAR(20) JEDINEČNÉ); CREATE TABLE Orders (Id INT PRIMAR KEY IDENTITY, CustomerId INT REFERENCES Customers(Id), CreatedDat Date);
Tu sú definované tabuľky Zákazníci a Objednávky. Zákazníci sú hlavnými a zastupujú zákazníka. Objednávky sú závislé a predstavujú objednávku zadanú zákazníkom. Táto tabuľka je prepojená prostredníctvom stĺpca CustomerId s tabuľkou Customers a jej stĺpcom Id. To znamená, že stĺpec CustomerId je cudzí kľúč, ktorý ukazuje na stĺpec Id z tabuľky Customers.
Definícia cudzieho kľúča na úrovni tabuľky by vyzerala takto:
VYTVORENIE TABUĽKY Objednávky (Id INT PRIMÁRNY KĽÚČ IDENTITA, CustomerId INT, Dátum vytvorenia, CUDZÍ KĽÚČ (CustomerId) REFERENCIE Zákazníci (Id));
Na zadanie názvu pre obmedzenie cudzieho kľúča môžete použiť príkaz CONSTRAINT. Tento názov zvyčajne začína predponou „FK_“:
VYTVORENIE TABUĽKY Objednávky (Id INT PRIMÁRNY KĽÚČ IDENTITA, CustomerId INT, Dátum vytvorenia, OBMEDZENIE FK_Orders_To_Customers CUDZÍ KĽÚČ (CustomerId) REFERENCIE Zákazníci (Id));
V tomto prípade má obmedzenie cudzieho kľúča CustomerId názov "FK_Orders_To_Customers".
PRI VYMAZANÍ a AKTUALIZÁCII
Pomocou príkazov ON DELETE a ON UPDATE môžete nastaviť akcie, ktoré sa vykonajú, keď sa príslušný riadok vymaže a aktualizuje z hlavnej tabuľky. A na definovanie akcie môžeme použiť nasledujúce možnosti:
CASCADE : Automaticky vymaže alebo zmení riadky zo závislej tabuľky, keď sa vymažú alebo zmenia súvisiace riadky v hlavnej tabuľke.
NO ACTION : Zabráni akejkoľvek akcii v závislej tabuľke, keď sa vymažú alebo upravia súvisiace riadky v hlavnej tabuľke. To znamená, že v skutočnosti neexistujú žiadne akcie.
SET NULL : Pri odstraňovaní súvisiaceho riadku z hlavnej tabuľky nastaví stĺpec cudzieho kľúča na hodnotu NULL.
SET DEFAULT : Pri odstraňovaní súvisiaceho riadka z hlavnej tabuľky nastaví stĺpec cudzieho kľúča na predvolenú hodnotu, ktorá sa nastaví pomocou atribútov DEFAULT. Ak stĺpec nemá predvolenú hodnotu, ako hodnota stĺpca sa použije NULL.
Kaskádové odstránenie
V predvolenom nastavení, ak niektorý riadok zo závislej tabuľky odkazuje na riadok z hlavnej tabuľky cudzím kľúčom, potom nebudeme môcť tento riadok z hlavnej tabuľky odstrániť. Najprv budeme musieť odstrániť všetky súvisiace riadky zo závislej tabuľky. A ak je pri odstraňovaní riadku z hlavnej tabuľky potrebné, aby sa odstránili všetky súvisiace riadky zo závislej tabuľky, použije sa kaskádové vymazanie, to znamená možnosť CASCADE:
VYTVORENIE TABUĽKY Objednávky (ID INT PRIMÁRNY KĽÚČ, ID zákazníka INT, Dátum vytvorenia, CUDZÍ KĽÚČ (ID zákazníka) REFERENCIE Zákazníci (ID) PRI VYMAZANÍ KASKÁDY)
Podobne funguje aj príkaz ON UPDATE CASCADE. Zmena hodnoty primárneho kľúča automaticky zmení hodnotu priradeného cudzieho kľúča. Keďže však primárne kľúče majú tendenciu sa meniť veľmi zriedkavo a vo všeobecnosti sa neodporúča používať stĺpce s meniteľnými hodnotami ako primárne kľúče, v praxi sa príkaz ON UPDATE používa zriedka.
Nastavenie NULL
Nastavenie cudzieho kľúča na SET NULL vyžaduje, aby stĺpec cudzieho kľúča mohol mať hodnotu null:
VYTVORENIE TABUĽKY Objednávky (Id INT PRIMÁRNY KĽÚČ IDENTITA, CustomerId INT, Dátum vytvorenia, CUDZÍ KĽÚČ (CustomerId) REFERENCIE Zákazníci (Id) ON DELETE SET NULL);