Ce este o cheie primară într-o bază de date? Constrângeri ale cheilor primare și străine Descriere cheie străină primară

Sunt utilizate în orice activitate: în industria bancară și financiară, afaceri turistice, depozite, producție și formare. Sunt o colecție de tabele, au proprietăți clare și sunt supuse unor cerințe stricte. În bazele de date relaționale, tabelele sunt numite relații.

Ce este o cheie primară într-o bază de date

Într-o bază de date, cheia primară a unui tabel este una dintre coloanele acestuia (cheia primară). Să ne uităm la un exemplu despre cum arată asta. Să ne imaginăm o simplă atitudine a studenților (să-i spunem „Studenți”).

Trebuie să identificăm în mod unic un student folosind o singură coloană. Pentru a face acest lucru, informațiile din această coloană trebuie să fie unice pentru fiecare intrare. Dar datele disponibile în acest sens nu ne permit să identificăm fără ambiguitate dosarul, întrucât toponimii, omonimii și studenții cu aceleași nume de familie și prenume pot studia în același curs și aceeași facultate. Cheia primară din baza de date este utilizată pentru a identifica cu precizie rândul necesar într-o relație. Cel mai adesea, un câmp numeric este utilizat în această calitate, crescând automat pe măsură ce se introduce o înregistrare (coloana de identificare cu incrementare automată).

Cheie primară simplă și compusă

Cheia primară poate fi simplă sau compusă. Dacă unicitatea unei înregistrări este determinată de valoarea dintr-un singur câmp, așa cum este descris mai sus, avem de-a face cu o cheie simplă. O cheie compusă este o cheie primară a bazei de date constând din două sau mai multe câmpuri. Luați în considerare următoarea atitudine a clienților băncilor.

NUMELE COMPLET.	Data nașterii	Seria pașapoarte	Pașaport ID
Ivanov P.A.	12.05.1996	75	0553009
Sergheev V.T.	14.07.1958	71	4100654
Krasnov L.V.	22.01.2001	73	1265165

Pașapoartele oamenilor pot conține aceleași serii sau numere, dar nu există pașapoarte cu aceeași serie și combinație de numere. Astfel, câmpurile „Seria pașaport” și „Număr pașaport” vor deveni o cheie compusă a relației specificate, identificând în mod unic persoana.

Legături între relații

Deci, o cheie primară într-o bază de date este una sau mai multe coloane ale unui tabel care permite identificarea unică a unui rând în relația respectivă. Pentru ce este?

Să revenim la primul exemplu cu relația „Elevi”. Pe lângă această relație, baza de date stochează și alte informații, de exemplu, performanța fiecărui elev. Pentru a nu repeta toate informațiile care sunt deja conținute în baza de date, aceștia folosesc o cheie, referitor la înregistrarea dorită. Arata cam asa.

În cele două exemple de relații vedem un câmp ID. Acestea sunt cheile primare din baza de date pentru aceste tabele. După cum puteți vedea, dosarul academic conține doar link-uri către aceste câmpuri din alte tabele, fără a fi nevoie să indicați toate informațiile din acestea.

Cheie naturală și surogat

Cum se determină cheia primară a unui tabel al bazei de date? Cele două exemple pe care le-am analizat - „Studenți” și „Clienții băncii” - ilustrează conceptele de chei naturale și surogat. În tabelul clienților băncii, am definit o cheie formată din câmpurile „Număr” și „Seria pașaport”, folosind coloanele deja existente. Această cheie se numește naturală; În cazul relației „Studenți”, niciun câmp unic sau combinație de câmpuri nu ne-a oferit unicitate. Acest lucru ne-a forțat să introducem un câmp suplimentar de cod de student. Această cheie se numește o cheie surogat, pentru care am adăugat o altă coloană de serviciu la tabel. Această coloană nu conține informații utile și servește doar la identificarea înregistrărilor.

Cheie străină și integritatea datelor în baza de date

Toate cele de mai sus ne duc la cheia externă și integritatea bazei de date. Cheia străină este un câmp care se referă la cheia primară a unei relații străine. În tabelul de progres, acestea sunt coloanele „Student” și „Disciplină”. Datele lor ne trimit la tabele externe. Adică câmpul „Student” din relația „Realizări” este o cheie străină, iar în relația „Student” este cheia primară din baza de date.

Un principiu important pentru construirea bazelor de date este integritatea acestora. Iar una dintre regulile sale este integritatea referenţială. Aceasta înseamnă că o cheie externă a unui tabel nu se poate referi la o cheie primară inexistentă a unei alte relații. Nu puteți șterge o înregistrare cu codul 1000 - Ivan Ivanov din Relația Student dacă este referită printr-o înregistrare din tabelul de performanță academică. Într-o bază de date construită corespunzător, când încercați să o ștergeți, veți primi o eroare că acest câmp este în uz.

Există și alte grupuri de reguli de integritate, precum și alte restricții de baze de date, care merită, de asemenea, atenție și ar trebui luate în considerare de dezvoltatori.

Figura prezintă un tabel (un raport de gradul 5) care conține unele informații despre angajații unei întreprinderi ipotetice. Rândurile de tabel corespund tuplurilor. Fiecare rând este de fapt o descriere a unui obiect din lumea reală (în acest caz, un angajat), ale cărui caracteristici sunt cuprinse în coloane. Relațiile relaționale corespund unor seturi de entități, iar tuplurile corespund entităților. Sunt numite coloanele dintr-un tabel care reprezintă o relație relațională atribute.

Fiecare atribut este definit pe un domeniu, astfel încât un domeniu poate fi considerat ca un set de valori valide pentru un anumit atribut. Mai multe atribute ale aceleiași relații și chiar atribute ale unor relații diferite pot fi definite pe același domeniu.

Este apelat un atribut a cărui valoare identifică în mod unic tuplurile cheie (sau pur și simplu cheie). Cheia este atributul Număr de personal, deoarece valoarea acestuia este unică pentru fiecare angajat al întreprinderii. Dacă tuplurile sunt identificate numai prin concatenarea valorilor mai multor atribute, atunci se spune că relația are o cheie compusă.

Cheia principala- într-un model de date relaționale, una dintre cheile potențiale ale unei relații, selectată ca cheie primară (sau cheie implicită).

O relație poate conține mai multe chei. Una dintre chei este întotdeauna declarată primar, valorile sale nu pot fi actualizate. Toate celelalte chei de relație sunt apelate chei posibile.

Din punct de vedere teoretic, toate cheile de relație potențiale (posibile) sunt echivalente, adică au aceleași proprietăți de unicitate și minimalitate. Cu toate acestea, cheia primară este de obicei selectată dintre cheile potențiale care sunt cele mai convenabile pentru anumite scopuri practice, de exemplu, pentru a crea extern chei în alte privințe sau pentru a crea un index grupat. Prin urmare, de regulă, cea care are cea mai mică dimensiune (stocare fizică) și/sau include cel mai mic număr de atribute este aleasă ca cheie primară.

Dacă cheia principala constă dintr-un singur atribut, se numește cu o cheie simplă.

Dacă cheia principala constă din două sau mai multe atribute, se numește cheie compusă. Deci, prenumele, numele de familie, patronimul, numărul de pașaport, seria de pașapoarte nu pot fi chei primare individual, deoarece pot fi aceleași pentru două sau mai multe persoane. Dar nu există două documente personale de același tip cu aceeași serie și același număr. Prin urmare, într-o relație care conține date despre persoane, cheia primară poate fi un subset de atribute constând din tipul de document personal, seria și numărul acestuia.

Spre deosebire de modelele de date ierarhice și de rețea, cel relațional nu are conceptul de relație de grup. Pentru a reflecta asocierile dintre tupluri cu diferite relații, se folosește duplicarea cheilor acestora.

Sunt numite atributele care sunt copii ale cheilor altor relații chei externe.

De exemplu, relația dintre relațiile DEPARTAMENT și ANGAJAT este creată prin copierea cheii primare „Număr_departament” de la prima relatie la a doua. Astfel, pentru a obține o listă de angajați ai unui anumit departament, este necesar: ​​1) Din tabelul DEPARTAMENT, setați valoarea atributului „Număr_departament” , corespunzătoare acestui „Department_Name”. 2) selectați toate înregistrările din tabelul ANGAJAT, valoarea atributului „Număr_departament” care este egal cu cel obţinut la pasul precedent. Pentru a afla în ce departament lucrează un angajat, trebuie să efectuați operația inversă: 1) Determinați „Număr_departament” din tabelul ANGAJAT. 2) Folosind valoarea obtinuta, gasim intrarea in tabelul DEPARTAMENT.

18. Normalizarea în baze de date relaționale, conceptul de formă normală în proiectarea bazelor de date.

Forma normală - o proprietate a unei relații într-un model de date relaționale, care o caracterizează din punct de vedere al redundanței, care poate duce la rezultate logic eronate ale eșantionării sau modificării datelor. Forma normală este definită ca un set de cerințe pe care o relație trebuie să le satisfacă.

Procesul de conversie a unei baze de date în formă normală este numit normalizare . Normalizarea are scopul de a aduce structura bazei de date într-o formă care oferă redundanță minimă, adică normalizarea nu are scopul de a reduce sau de a crește productivitatea muncii sau de a reduce sau de a crește volumul bazei de date. Scopul final al normalizării este de a reduce potențiala inconsecvență a informațiilor stocate în baza de date.

Eliminarea redundanței se realizează, de regulă, prin descompunerea relațiilor în așa fel încât în ​​fiecare relație să fie stocate doar fapte primare (adică fapte care nu sunt deduse din alte fapte stocate).

Dependențe funcționale.

O bază de date relațională conține atât informații structurale, cât și semantice. Structura unei baze de date este determinată de numărul și tipul de relații pe care le conține și de relațiile unu-la-mulți care există între tuplurile acestor relații. Partea semantică descrie setul de dependențe funcționale care există între atributele acestor relații. Să definim dependența funcțională.

19. 1NF: Definiții de bază și reguli de transformare.

Pentru a discuta prima formă normală, sunt necesare două definiții:

Atribut simplu - un atribut ale cărui valori sunt atomice (indivizibile).

Atribut complex - se obtine prin conectarea mai multor atribute atomice care pot fi definite pe acelasi domeniu sau pe domenii diferite (se mai numeste si vector sau agregat de date).

Definiția primei forme normale:

o relație este în 1NF dacă valorile tuturor atributelor sale sunt atomice. . În caz contrar, nu este deloc un tabel și astfel de atribute trebuie descompuse.

Să ne uităm la un exemplu:

În baza de date a departamentului HR al întreprinderii, este necesar să se stocheze informații despre angajați care pot fi încercate să fie prezentate în legătură cu

ANGAJAT(NUMĂRUL_ANGAJAT, NUME, DATA NAȘTERII, ISTORICUL_MUNCĂ, COPII).

Dintr-o analiză atentă a acestei relaţii rezultă că atributele "istoria muncii"Și "copii" sunt complexe, de altfel, atributul "istoria muncii" include un alt atribut complex „istoric_salariu”.
Aceste unități arată astfel:

 JOB_HISTORY (DATA_RECEPTION, NUME, SALARY_HISTORY),

 SALARY_HISTORY (NUMIREA_DATA, SALARIU),

 COPII (CHILD_NAME, BIRTH_YEAR).

Legătura lor este prezentată în Fig. 3.3.

Fig.3.3. Atitudine inițială.

Pentru a aduce relația originală SERVANT la prima formă normală, este necesar să o descompuneți în patru relații, așa cum se arată în figura următoare:

Fig.3.4. Ansamblu normalizat de relații.

Aici, cheia primară a fiecărei relații este evidențiată cu un cadru albastru, numele cheilor străine sunt cu font albastru. Amintiți-vă că cheile externe sunt folosite pentru a reprezenta dependențe funcționale care există în relația sursă. Aceste dependențe funcționale sunt indicate prin linii cu săgeți.

Algoritmul de normalizare este descris de E.F. Codd după cum urmează:

• Începând cu relația din partea de sus a arborelui (Figura 3.3.), este luată cheia sa primară și fiecare relație imediat subordonată este extinsă prin inserarea unui domeniu sau a unei combinații de domenii ale acelei chei primare.
• Cheia Primară a fiecărei relații extinse în acest fel constă din Cheia Primară pe care relația o avea înainte de extensie și Cheia Primară adăugată a relației părinte.
• După aceasta, toate domeniile non-simple sunt șterse din relația părinte, nodul superior al arborelui este eliminat și aceeași procedură se repetă pentru fiecare dintre subarborele rămase.

20. 2NF: Definiții de bazăși regulile de transformare.

Foarte des, cheia primară a unei relații include mai multe atribute (caz în care este numită compozit) - vezi, de exemplu, relația COPII prezentată în Fig. 3.4 întrebarea 19. În același timp, se introduce conceptul dependență funcțională deplină.

Definiție:

un atribut non-cheie este complet dependent din punct de vedere funcțional de o cheie compusă dacă este dependent funcțional de întreaga cheie ca un întreg, dar nu este dependent funcțional de niciunul dintre atributele sale constitutive.

Exemplu:

Să existe o relație SUPPLY (N_SUPPLIER, PRODUCT, PRICE).
Un furnizor poate furniza produse diferite, iar același produs poate fi furnizat de diferiți furnizori. Atunci cheia relației este „N_furnizor + produs”. Lăsați toți furnizorii să furnizeze bunuri la același preț. Apoi avem următoarele dependențe funcționale:

• N_furnizor, produs -> Preț
• produs -> Preț

Dependența funcțională incompletă a atributului preț de cheie duce la următoarea anomalie: atunci când prețul unui articol se modifică, este necesară o vizualizare completă a relației pentru a modifica toate înregistrările despre furnizorii săi. Această anomalie este o consecință a faptului că două fapte semantice sunt combinate într-o singură structură de date. Următoarea extindere oferă relațiile din 2NF:

• LIVRARE (N_FURNITOR, PRODUS)
• PRODUCT_PRICE (PRODUCT, PRICE)

Deci poți da

Definiția celei de-a doua forme normale: O relație este în 2NF dacă este în 1NF și fiecare atribut non-cheie este complet dependent funcțional de cheie.

21. 3NF: Definiții de bazăși regulile de transformare.

Înainte de a discuta a treia formă normală, este necesar să introducem conceptul: dependență funcțională tranzitivă.

Definiție:

Fie X, Y, Z trei atribute ale unei relații. În acest caz, X --> Y și Y --> Z, dar nu există corespondență inversă, adică. Z -/-> Y și Y -/-> X. Atunci Z depinde tranzitiv de X.
Să existe o relație DEPOZITARE ( FIRMĂ, DEPOZIT, VOLUM), care conține informații despre companiile care primesc mărfuri din depozite și volumele acestor depozite. Atribut cheie - "firmă". Dacă fiecare companie poate primi mărfuri dintr-un singur depozit, atunci în acest sens există următoarele dependențe funcționale:

• firmă -> stoc
• stoc -> volum

În acest caz, apar anomalii:

• dacă în momentul de față nicio companie nu primește mărfuri din depozit, atunci datele privind volumul acestuia nu pot fi introduse în baza de date (deoarece atributul cheie nu este definit)
• dacă se modifică volumul depozitului, este necesar să vizualizați întreaga relație și să schimbați cardurile pentru toate companiile asociate acestui depozit.

Pentru a elimina aceste anomalii, este necesar să descompunem relația inițială în două:

• DEPOZITARE ( FIRMĂ, STOC)
• STORAGE_VOLUME ( STOC, VOLUME)

Definiția a treia formă normală:

O relație este în 3NF dacă este în 2NF și fiecare atribut non-cheie nu depinde tranzitiv de cheia primară.

Mai devreme în această carte, am subliniat anumite relații care există între anumite câmpuri ale tabelelor tipice. Câmpul snum din tabelul Clienți, de exemplu, corespunde câmpului snum din tabelul Vânzători și tabelul Comenzi. Câmpul cnum din tabelul Clienți corespunde și câmpului cnum din tabelul Comenzi. Am numit acest tip de relație integritate de referință; și în timpul discuției, ați văzut cum poate fi folosit.

În acest capitol, veți explora integritatea referințelor mai detaliat și veți afla totul despre constrângerile pe care le puteți utiliza pentru a o menține. Veți vedea, de asemenea, cum se aplică această limitare atunci când utilizați comenzi de modificare DML. Deoarece integritatea referințelor implică relaționarea câmpurilor sau a grupurilor de câmpuri, adesea în tabele diferite, această acțiune poate fi oarecum mai complexă decât alte constrângeri. Din acest motiv, este bine să fii pe deplin familiarizat cu el, chiar dacă nu ai de gând să creezi tabele. Comenzile dvs. de modificare pot fi făcute mai eficiente prin utilizarea unei constrângeri de integritate referință (ca și în cazul altor constrângeri, dar o constrângere de integritate referință poate afecta alte tabele decât cele pe care este definită), iar anumite funcții de interogare, cum ar fi îmbinările, sunt structurate iterativ în termeni se referă la relaţiile de integritate (după cum este subliniat în capitolul 8).

CHEIA STRĂINĂ ȘI CHEIA PĂRINȚILOR

Când toate valorile dintr-un câmp de tabel sunt reprezentate într-un câmp dintr-un alt tabel, spunem că primul câmp se referă la al doilea. Aceasta indică o relație directă între valorile celor două câmpuri. De exemplu, fiecare dintre clienții din tabelul Clienți are un câmp snum care indică vânzătorul atribuit în tabelul Vânzători. Pentru fiecare comandă din tabelul Comenzi, există unul și numai acest vânzător și unul și numai acest client. Acesta este afișat folosind câmpurile snum și cnum din tabelul Comenzi.

Când un câmp dintr-un tabel se referă la altul, se numește cheie externă; iar câmpul la care se referă se numește cheia părinte. Deci câmpul snum din tabelul Customers este o cheie străină, iar câmpul snum la care se referă în tabelul Vendors este cheia părinte.

De asemenea, câmpurile cnum și snum din tabelul Comenzi sunt chei străine care se referă la cheile lor părinte numite în tabelul Clienți și în tabelul Furnizori. Numele cheii externe și ale cheii părinte nu trebuie să fie aceleași, este doar o convenție pe care o respectăm pentru a face unirea mai clară.

CHEI STRĂINE MULTI COLONNE

În realitate, o cheie străină nu constă neapărat dintr-un singur gen. La fel ca o cheie primară, o cheie străină poate avea orice număr de câmpuri, care sunt toate tratate ca o singură unitate. Cheia externă și cheia părinte la care se referă trebuie, desigur, să aibă același număr și același tip de gen și să fie în aceeași ordine. Cheile străine care constau dintr-un singur gen - cele pe care le-am folosit exclusiv în tabelele noastre standard, sunt cele mai comune. Pentru a menține discuția simplă, ne vom referi adesea la o cheie externă ca o singură coloană. Nu este o coincidență. Dacă acest lucru nu este notat, oricine va spune despre un câmp care este o cheie străină că aparține și unui grup de câmpuri care este o cheie străină.

SEMNIFICAȚIA CHEILOR STRĂINE ȘI PĂRINȚILOR

Când un câmp este o cheie străină, este legat într-un fel de tabelul la care se referă. Ceea ce spui în esență este „fiecare valoare din acest câmp (cheia străină) este direct legată de o valoare dintr-un alt câmp (cheia părinte).” Fiecare valoare (fiecare rând) a unei chei străine trebuie să se refere fără ambiguitate la una și numai acea valoare (rând) a cheii părinte. Dacă acesta este cazul, atunci de fapt sistemul dumneavoastră va fi, după cum se spune, într-o stare de integritate de referință. Puteți vedea asta cu un exemplu. Numărul cheii externe din tabelul Clienți are valoarea 1001 pentru rândurile Hoffman și Clemens. Să presupunem că am avut două rânduri în tabelul Vendors cu o valoare a câmpului snum = 1001. Cum știm cărora dintre cei doi furnizori au fost alocați clienții Hoffman și Clemens? De asemenea, dacă nu există astfel de rânduri în tabelul Vânzători, vom ajunge cu Hoffman și Clemens alocați unui furnizor care nu există!

Este clar că fiecare valoare dintr-o cheie străină trebuie să fie reprezentată o dată, și o singură dată, în cheia părinte.

De fapt, o anumită valoare a cheii străine se poate referi doar la o singură valoare a cheii părinte, fără ca inversul să fie posibil: i.e. orice număr de chei străine se poate referi la o singură valoare a cheii părinte. Puteți vedea acest lucru în tabelele tipice ale exemplelor noastre. Atât Hoffman, cât și Clemens sunt alocați lui Peel, așa că ambele valori ale cheii lor străine sunt aceleași cu aceeași cheie părinte, ceea ce este un lucru bun. O valoare cheie străină trebuie să facă referire la o singură valoare a cheii părinte, dar o valoare a cheii părinte poate fi referită prin orice număr de valori cheie străină. De exemplu, valorile cheii străine din tabelul Clienți care se potrivesc cu cheia lor părinte din tabelul Vânzători sunt prezentate în Figura 19.1. Pentru comoditate, nu am luat în considerare genul care nu este relevant pentru acest exemplu.

LIMITARE CHEIE STRĂINE

SQL menține integritatea referențială cu constrângerea FOREIGN KEY. Deși constrângerea FOREIGN KEY este o caracteristică nouă în SQL, încă nu o face universală. În plus, unele dintre implementările sale sunt mai complexe decât altele. Această funcție ar trebui să limiteze valorile pe care le puteți introduce în baza de date pentru a forța cheia externă și cheia părinte să respecte integritatea referențială. Una dintre acțiunile unei constrângeri cheie străină este de a renunța la valori pentru câmpurile constrânse ca cheie străină care nu sunt deja reprezentate în cheia părinte. Această restricție afectează și capacitatea dvs. de a modifica sau șterge valorile cheii părinte (vom discuta acest lucru mai târziu în acest capitol).

CUM POT FI REPREZENTATĂ CÂMPURI CA CHEI STRĂINE

Utilizați o constrângere FOREIGN KEY într-o comandă CREATE TABLE (sau ALTER TABLE) care conține câmpul pe care doriți să îl declarați ca o cheie străină. Le oferiți cheia părinte la care veți face referire în interiorul constrângerii FOREIGN KEY. Plasarea acestei constrângeri în comandă este aceeași ca și pentru celelalte constrângeri discutate în capitolul anterior. Figura 19.1: Cheia externă a tabelului Client cu cheia părinte

La fel ca majoritatea constrângerilor, poate fi o constrângere de tabel sau de coloană, sub formă de tabel, permițând utilizarea mai multor câmpuri ca o singură cheie străină.

CHEIE străină ca constrângere de masă

Sintaxa constrângerii tabelului FOREIGN KEY: FOREIGN KEY REFERINȚE [ ] Prima listă de coloane este o listă separată prin virgulă de una sau mai multe coloane de tabel care vor fi create sau modificate prin această comandă. Pktable este tabelul care conține cheia părinte. Poate fi un tabel care este creat sau modificat de comanda curentă. A doua listă de coloane este lista coloanelor care vor alcătui cheia părinte. Cele două liste de coloane trebuie să fie compatibile, adică:

* Trebuie să aibă același număr de coloane.

* În această secvență, prima, a doua, a treia coloană etc. din lista de coloane cu chei străine trebuie să aibă aceleași tipuri și dimensiuni de date ca prima, a doua, a treia coloană etc. din lista de coloane a cheii părinte . Coloanele din listele ambelor coloane nu ar trebui să aibă aceleași nume, deși am folosit această metodă în exemplele noastre pentru a clarifica relația.

Să creăm un tabel Customers cu câmpul snum definit ca o cheie străină care face referire la tabelul Vânzători: CREATE TABLE Customers (cnum integer NOT NULL PRIMARY KEY cname char(10), city char(10), snum integer, FOREIGN KEY (snum) REFERINȚE Vânzători (snum ); Rețineți că atunci când utilizați ALTER TABLE în loc de CREATE TABLE, pentru a aplica constrângerea FOREIGN KEY, valorile pe care le specificați în cheia externă și cheia părinte trebuie să fie în starea de integritate de referință, altfel ALTER Comanda TABLE va fi respinsă - pentru confortul acesteia, va trebui mai întâi să formulați principii structurale, cum ar fi integritatea de referință, în sistemul dvs., ori de câte ori este posibil, de fiecare dată.

CHEIE STRĂINĂ CA CONSTRINGERE DE COLANĂ

Opțiunea de a limita o coloană cu o constrângere FOREIGN KEY se mai numește și constrângere REFERENCES, deoarece nu conține de fapt cuvintele FOREIGN KEY, ci pur și simplu folosește cuvântul REFERENCES, urmat de cheia părinte, astfel: CREATE TABLE Customers ( cnum integer NOT NULL PRIMARY KEY, cname char(10), city char(10), snum integer REFERINȚE Vânzători (snum)); Cele de mai sus definesc Customers.snum ca o cheie străină a cărei cheie părinte este Salespeople.snum. Aceasta este echivalentă cu o constrângere de tabel ca aceasta: CHEIE STRĂINĂ (snum) REGERENCES Vânzători (snum)

NU SPECIFICAȚI LISTA COLOANELE CHEIE PRINCARE

Folosind o constrângere FOREIGN KEY pe un tabel sau coloană, puteți omite lista de coloane a cheii părinte dacă cheia părinte are o constrângere PRIMARY KEY. Desigur, în cazul cheilor cu multe câmpuri, ordinea coloanelor în cheile străine și primare trebuie să se potrivească și, în orice caz, principiul compatibilității între cele două chei încă se aplică. De exemplu, dacă am plasat o constrângere PRIMARY KEY în câmpul snum al tabelului Sales, am putea să o folosim ca o cheie externă în tabelul Customers (similar cu exemplul anterior) cu această comandă: CREATE TABLE Customers (cnum integer NOT NULL CHEIE PRIMARĂ, cname char(10) , city char(10), snum întreg REFERINȚE Vânzători); Această funcție a fost încorporată în limba pentru a vă încuraja să utilizați cheile primare ca chei părinte.

CUM LIMITEAZĂ INTEGRITATEA REFERINȚEI VALORILE CHEIEI PĂRINTE

Menținerea integrității referențiale necesită anumite restricții asupra valorilor care pot fi reprezentate în câmpurile declarate ca cheie externă și cheie părinte. Cheia părinte trebuie să fie structurată pentru a se asigura că fiecare valoare a cheii externe corespunde unui rând specificat. Aceasta înseamnă că aceasta (cheia) trebuie să fie unică și să nu conțină valori goale (NULL). Acest lucru nu este suficient pentru cheia părinte dacă este îndeplinită aceeași cerință ca atunci când se declară o cheie străină. SQL trebuie să se asigure că valorile duble sau valorile nule nu sunt introduse în cheia părinte. Prin urmare, trebuie să vă asigurați că toate câmpurile care sunt utilizate ca chei părinte au fie o constrângere PRIMARY KEY, fie o constrângere UNIQUE, cum ar fi constrângerea NOT NULL.

CHEIA PRIMARĂ CA O CHEIE STRĂINĂ UNICĂ

Conectarea cheilor străine numai la cheile primare, așa cum am făcut în tabelele standard, este o strategie bună. Când utilizați chei străine, nu le asociați doar cu cheile părinte la care se referă; le asociați cu un anumit rând de tabel în care va fi găsită cheia părinte. Cheia părinte în sine nu furnizează nicio informație care nu este deja prezentă în cheia externă. Semnificația, de exemplu, sex snum ca cheie străină în tabelul Clienți este relația pe care o oferă, nu cu valoarea sexului snum la care se referă, ci cu alte informații din tabelul Vânzări, cum ar fi numele oamenii de vânzări, locațiile lor și așa mai departe. O cheie externă nu este doar o relație între două valori identice; aceasta este o relație, folosind aceste două valori, între două rânduri ale tabelului specificate în interogare. Acest câmp snum poate fi folosit pentru a asocia orice informație dintr-un rând din tabelul Clienți cu un rând de referință din tabelul Vânzători - de exemplu, pentru a afla dacă locuiesc în același oraș, cine are un nume mai lung, dacă vânzătorul are orice alți clienți în afară de acest client și așa mai departe. Deoarece scopul unei chei primare este de a identifica unicitatea unui rând, este o alegere mai logică și mai puțin ambiguă pentru o cheie străină. Pentru orice cheie externă care utilizează o cheie unică ca cheie părinte, trebuie să creați o cheie externă care folosește cheia primară a aceluiași tabel pentru același efect. O cheie străină, care nu are alt scop decât legarea rândurilor, este similară cu o cheie primară folosită exclusiv pentru a identifica rândurile și este o modalitate bună de a menține structura bazei de date clară și simplă și, prin urmare, mai puțin complexă.

CONSTRINGRI CHEIE STRĂINE

O cheie străină, în special, poate conține numai valori care sunt de fapt prezente în cheia părinte sau sunt goale (NULL). Orice încercare de a introduce alte valori în această cheie va fi respinsă. Puteți declara o cheie străină ca NOT NULL, dar acest lucru nu este necesar și, în majoritatea cazurilor, nedorit. De exemplu, să presupunem că introduceți un client fără să știți în prealabil cărui agent de vânzări va fi repartizat. Cea mai bună cale de ieșire în această situație este să folosiți o valoare NOT NULL, care trebuie schimbată ulterior cu o anumită valoare.

CE SE INTAMPLA DACĂ EXECUTATI O COMANDĂ DE MODIFICARE

Să prevedem că toate cheile străine create în tabelele noastre de exemplu sunt declarate și aplicate cu constrângeri de cheie străină, după cum urmează: CREATE TABLE Vânzători (snum integer NOT NULL PRIMARY KEY, sname char(10) NOT NULL, city char(10) , comm decimal ); CREATE TABLE Clienți (cnum integer NOT NULL PRIMARY KEY, cname char(10) NOT NULL, city char(10), rating integer, snum integer, FOREIGN KEY (snum) REFERINȚE Vânzători, UNIQUE (cnum, snum) ; CREATE TABLE Comenzi ( cnum integer NOT NULL CHEIE PRIMARĂ, amt zecimal, data date NOT NULL, cnum integer NU NULL snum integer NU NUL CHEIE STRĂINĂ (cnum, snum) REFERINȚE CLIENTI (cnum, snum);

INCLUSIV DESCRIEREA TABELUI

Există mai multe atribute ale unor astfel de definiții care trebuie discutate. Motivul pentru care am decis să facem etajele cnum și snum din tabelul Comenzi o singură cheie străină este să ne asigurăm că pentru fiecare client conținut în comenzi, vânzătorul care creditează această comandă este același cu cel indicat în tabelul Clienți. Pentru a crea o astfel de cheie străină, ar trebui să plasăm o constrângere de tabel UNIQUE pe două etaje ale tabelului Client, chiar dacă nu este cerută de acel tabel în sine. Atâta timp cât câmpul cnum din acest tabel are o constrângere PRIMARY KEY, acesta va fi unic în orice caz și, prin urmare, este imposibil să se obțină o altă combinație a câmpului cnum cu un alt câmp. Crearea unei chei externe în acest fel menține integritatea bazei de date, chiar dacă vă împiedică să întrerupeți din greșeală intern și să creditați orice furnizor, altul decât cel alocat acelui client anume.

Din punctul de vedere al menținerii integrității bazei de date, întreruperile interne (sau excepțiile) sunt desigur nedorite. Dacă le permiteți și, în același timp, doriți să mențineți integritatea bazei de date, puteți declara câmpurile snum și cnum din tabelul Comenzi ca chei externe independente ale acestor câmpuri în tabelul Furnizori și, respectiv, în tabelul Clienți. De fapt, folosirea sex snum în tabelul Order așa cum am făcut noi nu este necesară, deși este util să facem acest lucru pentru varietate. Câmpul cnum care leagă fiecare comandă client în tabelul Client, în tabelul Comenzi și în tabelul Client trebuie întotdeauna să fie partajat pentru a găsi câmpul snum corect pentru acea comandă (fără a permite vreo excepție). Aceasta înseamnă că înregistrăm o informație - care client i-a fost atribuit și cărui furnizor - de două ori și va trebui făcută muncă suplimentară pentru a ne asigura că ambele versiuni sunt consecvente. Dacă nu avem o constrângere de cheie străină așa cum sa menționat mai sus, această situație va fi deosebit de problematică deoarece fiecare comandă va trebui verificată manual (împreună cu interogarea) pentru a ne asigura că vânzătorul corespunzător a creditat fiecare vânzare corespunzătoare. A avea acest tip de redundanță de informații în baza ta de date se numește denormalizare, ceea ce este nedorit într-o bază de date relațională ideală, deși în practică poate fi rezolvată. Demoralizarea poate face ca unele interogări să ruleze mai rapid, deoarece o interogare pe un tabel este întotdeauna mult mai rapidă decât o interogare pe o alăturare.

EFECTUL RESTRICȚILOR

Cum vă afectează astfel de restricții capacitatea și incapacitatea de a utiliza comenzile de modificare DML? Pentru câmpurile definite ca chei externe, răspunsul este destul de simplu: orice valoare pe care le introduceți în acele câmpuri cu o comandă INSERT sau UPDATE trebuie să fie deja prezentă în cheile lor părinte. Puteți plasa valori NULL în aceste câmpuri, deși valorile NULL nu sunt permise în cheile părinte dacă au o constrângere NOT NULL. Puteți ȘTERGE orice rând cu chei străine fără a utiliza cheile părinte.

Deoarece se pune problema schimbării valorilor cheii părinte, răspunsul, așa cum este definit de ANSI, este și mai simplu, dar poate ceva mai limitat: orice valoare a cheii părinte la care se face referire de către o valoare a cheii străine nu poate fi ștearsă sau modificată. Aceasta înseamnă, de exemplu, că nu puteți elimina un client din tabelul Clienți în timp ce acesta are încă comenzi în tabelul Comenzi. În funcție de modul în care utilizați aceste mese, acest lucru poate fi fie de dorit, fie o bătaie de cap. Cu toate acestea, acest lucru este cu siguranță mai bun decât a avea un sistem care vă permite să ștergeți un client cu comenzi curente și să părăsiți tabelul Comenzi referindu-se la clienți inexistenți. Ideea acestui sistem de restricții este că creatorul tabelului Comenzi, folosind tabelul Clienți și tabelul Vânzători ca chei părinte, poate impune restricții semnificative asupra acțiunilor din aceste tabele. Din acest motiv, nu veți putea folosi un tabel pe care nu îl controlați (adică nu l-ați creat și nu sunteți proprietarul acestuia) până când proprietarul (creatorul) acelui tabel vă acordă în mod expres dreptul de a face deci (după cum este explicat în capitolul 22). Există și alte posibile acțiuni de modificare a cheii părinte care nu fac parte din ANSI, dar pot fi găsite în unele programe comerciale. Dacă doriți să modificați sau să ștergeți valoarea de referință curentă a unei chei părinte, există în esență trei posibilități:

Puteți restricționa sau interzice modificările (în mod ANSI) specificând că modificările la cheia părinte sunt restricționate.

Puteți face o modificare în cheia părinte și, prin urmare, puteți efectua modificări automate în cheia externă, care se numește modificare în cascadă.

Puteți face o modificare la cheia părinte și puteți seta automat cheia externă la NULL (presupunând că NULLS este permis în cheia externă), ceea ce se numește modificare a cheii externe nulă.

Chiar și în cadrul acestor trei categorii, este posibil să nu doriți să gestionați toate comenzile de modificare în acest fel. INSERT, desigur, este irelevant. Pune noile valori ale cheii părinte în tabel, astfel încât niciuna dintre aceste valori să nu poată fi apelată momentan. Cu toate acestea, este posibil să doriți să permiteți modificarea în cascadă fără ștergeri și invers. O situație mai bună ar putea fi una care vă permite să definiți oricare dintre cele trei categorii, independent de comenzile UPDATE și DELETE. Prin urmare, ne vom referi la efectele de actualizare și la efectele de ștergere, care determină ce se întâmplă dacă lansați o comandă UPDATE sau DELETE pe o cheie părinte. Aceste efecte despre care am vorbit se numesc: modificări RESTRICTED, modificări CASCADE și modificări NULL. Capacitățile reale ale sistemului dvs. ar trebui să se încadreze în standardul ANSI strict - efectele de modificare și de ștergere sunt ambele limitate automat - pentru situația mai ideală descrisă mai sus. Pentru a ilustra, vom arăta câteva exemple de ceea ce puteți face cu o gamă completă de efecte de modificare și eliminare. Desigur, efectelor de modificare și ștergere, care sunt mijloace non-standard, le lipsește sintaxa de stare standard. Sintaxa pe care o folosim aici este ușor de scris și va servi pentru a ilustra funcțiile acestor efecte mai târziu.

De dragul caracterului complet al experimentului, să presupunem că aveți un motiv pentru a modifica câmpul snum al tabelului Vendors în cazul în care tabelul nostru Vendors schimbă partițiile. (De obicei, schimbarea cheilor primare nu este ceva ce recomandăm să facem în practică. Este doar un alt motiv pentru cheile primare existente care nu știu cum să facă altceva decât să acționeze ca chei primare: acestea nu ar trebui să se schimbe.) Când schimbați comerciantul numărul, doriți ca toți clienții săi să fie salvați. Cu toate acestea, dacă acest agent de vânzări își părăsește firma sau compania, este posibil să nu doriți să-i eliminați clienții în timp ce îl eliminați din baza de date. În schimb, veți dori să vă asigurați că clienții sunt alocați altcuiva. Pentru a face acest lucru trebuie să specificați UPDATE cu efect în cascadă și DELETE cu efect limitat. CREATE TABLE Clienți (cnum integer NOT NULL PRIMARY KEY, cname char(10) NOT NULL, city char(10), rating integer, snum integer REFERINȚE Vânzători, UPDATE OF Vânzători CASCADE, DELETE OF Salepeople RESTRICTED); Dacă încercați acum să eliminați Peel din tabelul Vânzători, comanda nu va fi valabilă până când nu modificați valoarea sexului snum a clienților Hoffman și Clemens pentru un alt furnizor atribuit. Pe de altă parte, puteți modifica valoarea sexului snum pentru Peel la 1009, iar Hoffman și Clemens vor fi modificați automat și ele.

Al treilea efect este modificările goale (NULL). Se întâmplă ca atunci când vânzătorii părăsesc o companie, comenzile lor curente să nu fie transferate altui vânzător. Pe de altă parte, doriți să anulați automat toate comenzile pentru clienții ale căror conturi le ștergeți. Schimbând numerele vânzătorului sau clientului, pur și simplu le puteți transfera acestuia. Exemplul de mai jos arată cum puteți crea un tabel de comandă folosind aceste efecte. CREATE TABLE Comenzi (onum integer NOT NULL PRIMARY KEY, amt decimal, odate date NOT NULL cnum integer NOT NULL REFERINȚE Clienți snum întreg REFERINȚE Vânzători, ACTUALIZARE CASCADE Clienți, ȘTERGERE CASCADE Clienți, ACTUALIZARE CASCADE Vânzări, ȘTERGERE Vânzări); Desigur, într-o comandă DELETE cu efectul unei modificări Empty pe tabelul Vendors, constrângerea NOT NULL trebuie eliminată din câmpul snum.

CHEI STRĂINE CARE FAC REFERINȚĂ LA TABELELOR SUBIECTE

După cum am menționat mai devreme, o constrângere FOREIGN KEY poate reprezenta acest tabel privat ca un tabel de chei părinte. Departe de a fi simplă, această caracteristică poate fi utilă. Să presupunem că avem un tabel de angajați cu un câmp de manager. Acest câmp conține numerele fiecărui angajat, dintre care unii sunt și administratori. Dar din moment ce fiecare administrator rămâne angajat în același timp, în mod natural va fi și el reprezentat în acest tabel. Să creăm un tabel în care numărul angajatului (o coloană numită empno) este declarat ca cheie primară, iar administratorul, ca cheie străină, va face referire la el: CREATE TABLE Angajații (empno integer NOT NULL PRIMARY KEY, name char(10) NOT NULL UNIOUE , manager întreg REFERINȚE Angajații); (Deoarece cheia externă este cheia primară referită a tabelului, lista de coloane poate fi exclusă.) Există conținutul acestui tabel: EMPNO NAME MANAGER _____ ________ _______ 1003 Terrence 2007 2007 Atali NULL 1688 McKenna 1003 2002 As you 2002 Collier pot vedea, fiecare dintre acestea (dar nu Atali), se referă la un alt angajat din tabel ca administrator al său. Atali, care are cel mai mare număr din tabel, trebuie să aibă valoarea setată la NULL. Acest lucru dă un alt principiu al integrității referențiale. O cheie străină care trimite înapoi la un tabel privat trebuie să permită valori = NULL. Dacă nu este cazul, cum ați introduce primul rând? Chiar dacă acest prim rând se referă la el însuși, valoarea cheii părinte trebuie deja setată atunci când este introdusă valoarea cheii străine. Acest principiu va fi adevărat chiar dacă cheia străină se referă înapoi la tabelul privat nu direct, ci printr-o referire la un alt tabel, care apoi se referă la tabelul cheii străine. De exemplu, să presupunem că tabelul nostru de vânzări are un câmp suplimentar care face referire la tabelul Clienți, astfel încât fiecare tabel să facă referire la celălalt, așa cum se arată în următoarea instrucțiune CREATE TABLE: CREATE TABLE Salespeople (snum integer NOT NULL PRIMARY KEY, sname char(10) NOT NULL, city char(10), comm declmal, cnum integer REFERINȚE Clienți); CREATE TABLE Clienti (cnum integer NOT NULL PRIMARY KEY, cname char(10) NOT NULL, city char(10), rating integer, snum integer REFERINȚE Vânzători); Aceasta se numește referință încrucișată. SQL acceptă acest lucru în teorie, dar în practică poate fi o problemă. Oricare tabel dintre aceste două este creat primul este un tabel de referință care nu există încă pentru celălalt. În interesul referințelor încrucișate, SQL permite de fapt acest lucru, dar niciunul dintre tabelele nu va fi utilizabil în timp ce ambele sunt în proces de creare. Pe de altă parte, dacă cele două tabele sunt create de utilizatori diferiți, problema devine și mai dificilă. Referențele încrucișate pot fi un instrument util, dar nu este lipsit de ambiguitate și pericole. Exemplul anterior, de exemplu, nu este în întregime utilizabil deoarece limitează vânzătorul la un singur client și nu este necesar să se folosească o referință încrucișată pentru a realiza acest lucru. Vă recomandăm să fiți atenți în utilizarea acestuia și să analizați modul în care programele dumneavoastră gestionează efectele modificării și ștergerii, precum și procesele de privilegii și procesare interactivă a interogărilor, înainte de a crea un sistem de integritate cu referințe încrucișate. (Privilegiile și procesarea interactivă a cererilor vor fi discutate, respectiv, în capitolele 22 și 1.)

REZUMAT

Acum aveți un control destul de bun asupra integrității referințelor. Ideea de bază este că toate valorile cheii străine se referă la rândul de chei părinte specificat. Aceasta înseamnă că fiecare valoare a cheii externe trebuie să fie reprezentată o dată și o singură dată în cheia părinte. Ori de câte ori o valoare este plasată într-o cheie străină, cheia părinte este verificată pentru a se asigura că valoarea acesteia este reprezentată; în caz contrar, comanda va fi respinsă. Cheia părinte trebuie să aibă o constrângere PRIMARY KEY sau UNIQUE pentru a se asigura că valoarea nu este reprezentată de mai multe ori. O încercare de a schimba valoarea unei chei părinte care este reprezentată în prezent într-o cheie străină va fi respinsă cu totul. Totuși, sistemul dumneavoastră vă poate oferi alegerea de a obține valoarea cheii străine setată la NULL sau de a obține noua valoare a cheii părinte și de a specifica care poate fi obținută independent pentru comenzile UPDATE și DELETE. Aceasta încheie discuția noastră despre comanda CREATE TABLE. În continuare vă vom prezenta un alt tip de comandă - CREATE. În capitolul 20, veți învăța cum să reprezentați obiecte de date care arată și acționează ca un tabel, dar sunt de fapt rezultatele interogărilor. Unele funcții de constrângere pot fi efectuate și de vizualizări, astfel încât veți putea să vă evaluați mai bine nevoia de constrângeri după ce veți citi următoarele trei capitole.

LUCRU CU SQL

1. Creați un tabel numit Cityorders. Ar trebui să conțină aceleași câmpuri onum, amt și snum ca și tabelul Comenzi și aceleași câmpuri cnum și oraș ca și tabelul Clienți, astfel încât comanda fiecărui client să fie introdusă în acest tabel împreună cu orașul său. Câmpul onum va fi cheia principală a Cityorders. Toate etajele din Cityorder trebuie să aibă restricții în comparație cu tabelele Clienți și Comenzi. Este posibil ca cheile părinte din aceste tabele să aibă deja restricții adecvate.

2. Să complicăm problema. Redefiniți tabelul Comenzi astfel: adăugați o nouă coloană numită prev care va fi identificată pentru fiecare comandă, câmpul onum al comenzii anterioare pentru acel client curent. Faceți acest lucru folosind o cheie străină care face referire la tabelul Order în sine. Cheia externă trebuie, de asemenea, să facă referire la câmpul cnum al clientului, oferind o relație specifică prescrisă între comanda curentă și cea referită.

(Vezi Anexa A pentru răspunsuri.)

CHEIE EXTERNĂ folosit pentru restricții de link.
Când toate valorile dintr-un câmp de tabel sunt reprezentate într-un câmp dintr-un alt tabel, se spune că primul câmp se referă la al doilea. Aceasta indică o relație directă între valorile celor două câmpuri.

Când un gen dintr-un tabel se referă la altul, acesta este numit cheie externă; iar câmpul la care se referă se numește cheia părintelui. Numele cheii externe și ale cheii părinte nu trebuie să fie identice. O cheie externă poate avea orice număr de câmpuri, care sunt toate procesate ca o singură unitate. O cheie externă și cheia părinte la care se referă trebuie să aibă același număr de câmp și același tip de câmp și să fie în aceeași ordine. Când un câmp este o cheie străină, este legat într-un fel de tabelul la care face referire. Fiecare valoare (fiecare rând) a unei chei străine trebuie să se refere fără ambiguitate la una și numai acea valoare (rând) a cheii părinte. Dacă această condiție este îndeplinită, atunci baza de date este în stare integritate referenţială.

SQL menţine integritatea referenţială cu constrângere CHEIE EXTERNĂ. Această funcție trebuie să limiteze valorile care pot fi introduse în baza de date pentru a forța cheia externă și cheia părinte să respecte integritatea referențială. Una dintre acțiunile de restricție CHEIE EXTERNĂ este eliminarea valorilor pentru câmpurile care sunt constrânse ca o cheie străină care nu sunt încă reprezentate în cheia părinte. Această restricție afectează și capacitatea de a modifica sau șterge valorile cheii părinte

Prescripţie CHEIE EXTERNĂ utilizat într-o comandă CREATE TABLE (sau ALTER TABLE (destinată să modifice structura tabelului)) care conține un câmp care este declarat o cheie străină. Cheia părinte primește un nume care este referit în constrângere CHEIE EXTERNĂ.

La fel ca majoritatea constrângerilor, poate fi o constrângere de tabel sau de coloană, sub formă de tabel, permițând utilizarea mai multor câmpuri ca o singură cheie străină.

Sintaxa constrângerii tabelului CHEIE EXTERNĂ:

CHEIE EXTERNĂ REFERINȚE

[ ]

Prima listă de coloane este o listă separată prin virgulă de una sau mai multe coloane de tabel care vor fi create sau modificate prin această comandă.

Pktable- acesta este tabelul care conține cheia părinte. Poate fi un tabel care este creat sau modificat de comanda curentă.

A doua listă de coloane este lista coloanelor care vor alcătui cheia părinte. Cele două liste de coloane trebuie să fie compatibile, adică:

• au același număr de coloane
• într-o anumită secvență, prima, a doua, a treia coloană etc. din lista de coloane cu chei străine trebuie să aibă aceleași tipuri și dimensiuni de date ca și prima, a doua, a treia coloană etc. din lista de coloane a cheii părinte.
• coloanele din listele ambelor coloane nu trebuie să aibă aceleași nume.

CHEIE STRĂINĂ Exemplul 1

CREATE TABLE Student
(Kod_stud întreg NOT NULL PRIMARY CHEIE,
Kod_spec întreg NOT NULL,

Adrese char(50),
bile zecimală),
CHEIE EXTERNĂ(Kod_spec) REFERINȚE Specificație (Kod_spec)
);

Când utilizați ALTER TABLE în loc de CREATE TABLE pentru a aplica o constrângere CHEIE EXTERNĂ, valorile specificate în cheia externă și cheia părinte trebuie să fie în stare de integritate referențială. În caz contrar, comanda va fi respinsă.

Utilizarea constrângerii CHEIE EXTERNĂ tabel sau coloană, puteți omite lista de coloane a cheii părinte dacă cheia părinte are o constrângere PRIMARY CHEIE. Desigur, în cazul cheilor cu multe câmpuri, ordinea coloanelor în cheile străine și primare trebuie să se potrivească și, în orice caz, principiul compatibilității între cele două chei încă se aplică.

CHEIE STRĂINĂ Exemplul 2

CREATE TABLE Student (
Kod_stud întreg NOT NULL PRIMARY CHEIE,
Fam char(30) NOT NULL UNIQUE,
Adrese char(50),
bile zecimală),
Kod_spec întreg REFERINȚE Spec
);

Menținerea integrității referențiale necesită anumite restricții asupra valorilor care pot fi reprezentate în câmpurile declarate ca cheie externă și cheie părinte. Cheia părinte trebuie să fie structurată pentru a se asigura că fiecare valoare a cheii externe corespunde unui rând specificat. Aceasta înseamnă că aceasta (cheia) trebuie să fie unică și să nu conțină valori goale (NULL).

Acest lucru nu este suficient pentru cheia părinte dacă o astfel de cerință este îndeplinită, cum ar fi atunci când se declară o cheie străină. SQL trebuie să vă asigurați că nu au fost introduse valori duble sau valori nule în cheia părinte. Prin urmare, trebuie să vă asigurați că toate câmpurile care sunt utilizate ca chei părinte au fie o constrângere PRIMARY CHEIE sau o constrângere UNIQUE, cum ar fi constrângerea NOT NULL.

Trimiterea cheilor externe numai la cheile primare este o strategie bună. Când sunt folosite chei străine, acestea nu sunt asociate pur și simplu cu cheile părinte la care se referă; sunt asociate cu un anumit rând de tabel în care va fi găsită cheia părinte. Cheia părinte în sine nu furnizează nicio informație care nu este deja prezentă în cheia externă.

Deoarece scopul unei chei primare este de a identifica unicitatea unui rând, este o alegere mai logică și mai puțin ambiguă pentru o cheie străină. Pentru orice cheie externă care utilizează o cheie unică ca cheie părinte, trebuie să creați o cheie externă care folosește cheia primară a aceluiași tabel pentru același efect. O cheie străină, care nu are alt scop decât legarea rândurilor, este similară cu o cheie primară, folosită exclusiv pentru a identifica rândurile și este un mijloc bun de a menține structura bazei de date clară și simplă. O cheie străină poate conține doar valori care sunt prezente efectiv în cheia părinte sau care sunt goale (NULL). Orice încercare de a introduce alte valori în această cheie va fi respinsă.

CHEIE STRĂINĂ Exemplul 3

CREATE TABLE plata (
sh_payout întreg,
sh_eml întreg,
data_data de plată,
sum_payout real,
CHEIE EXTERNĂ(sh_eml) REFERINȚE k_sotr2 (eid)
);

În acest exemplu CHEIE EXTERNĂ coloana sh_eml este asociată cu coloana eid din tabelul k_sotr2.

Cheile sunt elemente fundamentale ale unei baze de date relaționale deoarece stabilesc o relație între o pereche de tabele și oferă o identificare unică pentru fiecare înregistrare din tabel. Cheile sunt mai importante decât stabilirea de relații; ele ajută și la integritatea referențială și sunt o componentă majoră a integrității la nivel de tabel. Tabelele stochează bucăți uriașe de date care se întind de obicei pe mii de înregistrări, toate nesortate și dezorganizate. Preluarea datelor specifice din aceste înregistrări multiple poate fi uneori dificilă sau imposibilă. Aici apar Cheile. Aici vom analiza două chei foarte importante ale schemei bazei de date relaționale și diferența dintre ele: cheia primară și cheia externă.

Ce este o cheie primară?

O cheie primară este o cheie specială care identifică în mod unic fiecare înregistrare dintr-un tabel. Într-o bază de date relațională, este foarte important să aveți un identificator unic în fiecare rând al unui tabel, iar o cheie primară este pur și simplu ceea ce aveți nevoie pentru a identifica în mod unic un tuplu într-un tabel. Un tuplu este o colecție de atribute de valoare dintr-o bază de date relațională. O cheie primară se poate referi la o coloană sau la un set de coloane dintr-un tabel al bazei de date relaționale care este folosit pentru a identifica implicit toate înregistrările din tabel. Cheia primară trebuie să fie unică pentru fiecare înregistrare, deoarece acționează ca un identificator unic și nu trebuie să conțină valori nule. Fiecare bază de date trebuie să aibă una și o singură cheie primară.

Ce este o cheie străină?

O cheie străină se referă la un câmp sau o colecție de câmpuri dintr-o înregistrare a bazei de date care identifică în mod unic câmpul cheie al unei alte înregistrări a bazei de date dintr-un alt tabel. În termeni simpli, stabilește o relație între înregistrările din două tabele diferite dintr-o bază de date. Ar putea fi o coloană dintr-un tabel care indică coloanele cheii primare, ceea ce înseamnă că cheia externă definită în tabel se referă la cheia primară a unui alt tabel. Legăturile sunt critice în bazele de date relaționale pentru stabilirea relațiilor între înregistrări, care sunt necesare pentru sortarea bazelor de date. Cheile externe joacă un rol important în normalizarea bazelor de date relaționale, mai ales atunci când tabelele au nevoie de acces la alte tabele.

Diferența dintre cheia primară și cheia externă

Elementele de bază ale cheii primare și ale cheii externe

O cheie primară este o cheie specială dintr-o bază de date relațională care acționează ca un identificator unic pentru fiecare înregistrare, ceea ce înseamnă că identifică în mod unic fiecare rând/înregistrare dintr-un tabel și valoarea acesteia trebuie să fie unică pentru fiecare rând al tabelului. Pe de altă parte, o cheie străină este un câmp dintr-un tabel care leagă două tabele împreună. Se referă la o coloană sau un grup de coloane care identifică în mod unic un rând al altui tabel sau al aceluiași tabel.

Relația cheie primară și cheie străină

O cheie primară identifică în mod unic o înregistrare într-un tabel al bazei de date relaționale, în timp ce o cheie străină se referă la un câmp dintr-un tabel care este cheia primară a unui alt tabel. Cheia primară trebuie să fie unică și o singură cheie primară este permisă într-un tabel care trebuie definit, în timp ce mai mult de o cheie străină este permisă într-un tabel.

Duplicați valorile cheii primare și ale cheii externe

O cheie primară este o combinație de constrângeri UNIQUE și Not Null, astfel încât unui câmp de cheie primară dintr-un tabel al bazei de date relaționale nu i se poate permite să aibă valori duplicate. Nu există două rânduri care pot conține valori duplicate pentru un atribut al cheii primare. Spre deosebire de o cheie primară, o cheie străină poate conține valori duplicate, iar un tabel dintr-o bază de date relațională poate conține mai multe chei străine.

Cheie primară NULL și cheie străină

Una dintre principalele diferențe dintre cele două este că, spre deosebire de cheile primare, cheile străine pot conține și valori NULL. Un tabel dintr-o bază de date relațională poate avea o singură cheie primară, care nu poate fi anulată.

Tabel temporar al cheii primare și al cheii externe

O constrângere de cheie primară poate fi definită implicit pe tabelele temporare și variabilele acestora, în timp ce o constrângere de cheie străină nu poate fi aplicată tabelelor temporare locale sau globale.

Eliminarea unei chei primare și a unei chei străine

O valoare a cheii primare nu poate fi ștearsă dintr-un tabel părinte care este menționat ca o cheie străină într-un tabel copil. Înainte de a putea arunca un tabel părinte, trebuie să aruncați mai întâi tabelul copil. În schimb, o valoare a cheii străine poate fi ștearsă dintr-un tabel copil chiar dacă valoarea aparține cheii primare a tabelului părinte.

Cheie primară sau cheie străină: tabel de comparație

Rezumatul tastelor cheie

Cheile joacă un rol crucial în existența unei scheme de baze de date pentru a stabili relații între tabele și în interiorul unui tabel. Cheile stabilesc relații și impun diferite tipuri de integritate, în special integritatea la nivel de tabel și la nivel de relație. În primul rând, ei cred că un tabel conține înregistrări unice, iar câmpurile pe care le utilizați pentru a stabili relații între tabele trebuie să conțină valori corespunzătoare. Cheia primară și cheia externă sunt cele mai importante și comune tipuri de chei utilizate în bazele de date relaționale. O cheie primară este o cheie specială folosită pentru a identifica în mod unic înregistrările dintr-un tabel, în timp ce o cheie externă este folosită pentru a stabili o relație între două tabele. Ambele sunt identice ca structură, dar joacă roluri diferite într-o schemă de baze de date relaționale.

vederi