O relație one-to-many într-o bază de date apare atunci când fiecare înregistrare din tabelul A poate avea multe înregistrări legate în Tabelul B, dar fiecare înregistrare din Tabelul B poate avea numai o înregistrare corespunzătoare în Tabelul A. O relație unu-la-mulți în o bază de date este cel mai comun proiect de bază de date relațională și este în centrul unui design bun.
Luați în considerare relația dintre un profesor și cursurile pe care le predau. Un profesor poate preda mai multe cursuri, dar cursul nu ar avea aceeași relație cu profesorul.
Prin urmare, pentru fiecare înregistrare din tabelul Profesori, ar putea exista multe înregistrări în tabelul Cursuri. Aceasta este o relație una-la-multe: un profesor la mai multe cursuri.
De ce este importantă stabilirea unei relații unu-mult
Pentru a reprezenta o relație unu-la-multe, aveți nevoie de cel puțin două mese. Să vedem de ce.
Poate că am creat un tabel în care vrem să înregistrăm numele și cursurile predate. Am putea proiecta astfel:
| Teacher_ID | Numele profesorului | Curs |
|---|---|---|
| Teacher_001 | Carmen | Biologie |
| Teacher_002 | Veronica | Math |
| Teacher_003 | Jorge | Engleză |
Ce se întâmplă dacă Carmen predă două sau mai multe cursuri? Avem două opțiuni cu acest design. Am putea doar să o adăugăm la înregistrarea actuală a lui Carmen, astfel:
| Teacher_ID | Profesor_Nume | Curs |
|---|---|---|
| Teacher_001 | Carmen | Biologie, Matematică |
| Teacher_002 | Veronica | Math |
| Teacher_003 | Jorge | Engleză |
Designul de mai sus, cu toate acestea, este inflexibil și ar putea duce la probleme mai târziu atunci când încercați să inserați, să editați sau să ștergeți date.
Aceasta face dificilă căutarea datelor. Acest proiect î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.
O altă alternativă de design ar putea fi să adaugi pur și simplu un al doilea record pentru Carmen:
| Profesor_id | Profesor_Nume | Curs |
|---|---|---|
| Teacher_001 | Carmen | Biologie |
| Teacher_001 | Carmen | Math |
| Teacher_002 | Veronica | Math |
| Teacher_003 | Jorge | Engleză |
Acest lucru aderă la 1NF, dar este în continuare un design de baze de date slabe deoarece introduce redundanță și ar putea umfla o bază de date foarte mare inutil. Mai important, datele ar putea deveni inconsecvente. De exemplu, dacă numele lui Carmen sa schimbat? Cineva care lucrează cu datele ar putea să își actualizeze numele într-o singură înregistrare și să nu o actualizeze în cea de-a doua înregistrare. Acest proiect încalcă Formularul secundar secundar (2NF), care aderă la 1NF și trebuie, de asemenea, să evite redundanțele mai multor înregistrări prin separarea subseturilor de date în mai multe tabele și crearea unei relații între ele.
Cum de a proiecta o bază de date cu relații one-to-many
Pentru a implementa o relație one-to-many în tabelul Teachers and Courses, rupem tabelele în două și le conectăm folosind o cheie străină.
Aici am eliminat coloana Curs din tabelul Profesorii:
| Profesor_id | Profesor_Nume |
|---|---|
| Teacher_001 | Carmen |
| Teacher_002 | Veronica |
| Teacher_003 | Jorge |
Și aici este masa de cursuri. Rețineți că cheia externă, Teacher_ID, face legătura între un curs și un profesor în tabelul Profesorilor:
| Course_ID | Numele cursului | Teacher_ID |
|---|---|---|
| Course_001 | Biologie | Teacher_001 |
| Course_002 | Math | Teacher_001 |
| Course_003 | Engleză | Teacher_003 |
Am dezvoltat o relație între tabelele profesorilor și cursuri folosind o cheie străină.
Acest lucru ne spune că biologia și matematica sunt predate de Carmen și că Jorge predă limba engleză.
Putem vedea cum acest proiect evită orice posibilă redundanță, permite profesorilor individuali să predea cursuri multiple și implementează o relație unu-la-mulți.
Bazele de date pot implementa, de asemenea, o relație one-to-one și o relație multi-la-multe.
