Baze de date

Relațiile baze de date reprezintă coloana vertebrală a tuturor bazelor de date relaționale

Se stabilește o relație între două tabele de baze de date atunci când o tabelă are o cheie străină care face trimitere la cheia primară a altui tabel. Acesta este conceptul de bază din spatele termenului de bază de date relațională.

Cum funcționează o cheie străină pentru a stabili o relație

Să analizăm elementele de bază ale cheilor primare și străine. O cheie primară identifică în mod unic fiecare înregistrare din tabel. Este un tip de cheie candidat care este, de obicei, prima coloană dintr-un tabel și poate fi generată automat de către baza de date pentru a se asigura că este unică.

O cheie străină este o altă cheie candidat (nu cheia primară) folosită pentru a lega o înregistrare de datele dintr-un alt tabel.

De exemplu, luați în considerare aceste două tabele care identifică ce profesor predă cursul.

Aici, cheia primară a tabelului Cursuri este ID-ul cursului. Cheia externă este Teacher_ID:

Cursuri
Course_ID Numele cursului Teacher_ID
Course_001 Biologie Teacher_001
Course_002 Math Teacher_001
Course_003 Engleză Teacher_003

Puteți vedea că cheia externă din Cursuri se potrivește cu o cheie primară din cadrul profesorilor:

Profesori
Teacher_ID Numele profesorului
Teacher_001 Carmen
Teacher_002 Veronica
Teacher_003 Jorge

Putem spune că cheia străină Teacher_ID a ajutat la stabilirea unei relații între mesele cursurilor și profesorilor.

Tipuri de relații baze de date

Folosind chei străine sau alte chei candidate, puteți implementa trei tipuri de relații între mese:

One-to-One : Acest tip de relație permite doar o înregistrare pe fiecare parte a relației.

Cheia primară se referă la o singură înregistrare - sau nu - într-un alt tabel. De exemplu, într-o căsătorie, fiecare soț are un singur soț. Acest tip de relație poate fi implementat într-o singură masă și, prin urmare, nu utilizează o cheie străină.

One-to-many : O relație one-to-many permite ca o singură înregistrare într-un singur tabel să fie legată de mai multe înregistrări dintr-un alt tabel.

Luați în considerare o afacere cu o bază de date care are tabele pentru clienți și comenzi.

Un singur client poate achiziționa mai multe comenzi, dar o singură comandă nu poate fi legată de mai mulți clienți. Prin urmare, tabelul Comenzi ar conține o cheie străină care corespunde cheii primare a tabelului Clienți, în timp ce tabela Clienți nu ar avea o cheie străină care să indice tabelul Ordine.

Multe-la-multe : Aceasta este o relație complexă în care multe înregistrări dintr-un tabel se pot conecta la mai multe înregistrări dintr-un alt tabel. De exemplu, afacerea noastră are probabil nevoie nu numai de tabelele clienților și a comenzilor, dar probabil are nevoie și de un tabel Products.

Din nou, relația dintre tabelul Clienți și Ordine este una-la-multe, dar ia în considerare relația dintre tabelul Comenzi și Produse. O comandă poate conține mai multe produse și un produs poate fi legat de mai multe comenzi: mai mulți clienți ar putea trimite o comandă care conține unele dintre aceleași produse. Acest tip de relație necesită minimum trei tabele.

Care sunt relațiile bazelor de date importante?

Stabilirea relațiilor consecvente între tabelele bazei de date ajută la asigurarea integrității datelor, contribuind la normalizarea bazei de date. De exemplu, dacă nu am legat niciun tabel printr-o cheie străină și combinând datele din tabelele Cursuri și profesori, cum ar fi:

Profesori și cursuri
Teacher_ID Numele profesorului Curs
Teacher_001 Carmen Biologie, Matematică
Teacher_002 Veronica Math
Teacher_003 Jorge Engleză

Acest design este inflexibil și încalcă primul principiu al normalizării bazei de date, First Normal Form (1NF), care prevede că fiecare celulă de tabelă trebuie să conțină o singură bucată de date discrete.

Sau poate am decis să adăugăm pur și simplu un al doilea record pentru Carmen, pentru a impune 1NF:

Profesori și cursuri
Teacher_ID Numele profesorului Curs
Teacher_001 Carmen Biologie
Teacher_001 Carmen Math
Teacher_002 Veronica Math
Teacher_003 Jorge Engleză

Acesta este încă un design slab, introducând duplicări inutile și ceea ce se numește anomalii de inserare a datelor , ceea ce înseamnă doar că ar putea contribui la date incoerente.

De exemplu, dacă un profesor are mai multe înregistrări, ce se întâmplă dacă unele date trebuie editate, dar persoana care efectuează editarea datelor nu realizează existența mai multor înregistrări? Tabelul ar conține apoi date diferite pentru aceeași persoană, fără o modalitate clară de a le identifica sau de a le evita.

Ruperea acestui tabel în două tabele, Profesori și cursuri (așa cum este vizualizat mai sus), creează relația corectă între date și, prin urmare, ajută la asigurarea consecvenței și acurateței datelor.