Odnos od jedne do mnogih u bazi podataka se javlja kada svaki zapis u Tabeli A može imati mnogo povezanih zapisa u Tabeli B, ali svaki zapis u Tabeli B može imati samo jedan odgovarajući zapis u Tabeli A. Jedno-prema-mnogi odnos u baza podataka je najčešći dizajn relacijske baze podataka i nalazi se u srcu dobrog dizajna.
Razmotrite odnos između nastavnika i predmeta koje predaju. Nastavnik može da predaje više kurseva, ali kurs ne bi imao isti odnos sa nastavnikom.
Stoga, za svaki zapis u tabeli Teachers, u tabeli Kursevi može biti mnogo zapisa. Ovo je odnos od jednog do drugog: jedan nastavnik na višestruke kurseve.
Zašto je uspostavljanje veze od jednog do drugog važno
Za predstavljanje veze od jednog do drugog potrebno vam je najmanje dve tabele. Da vidimo zašto.
Možda smo stvorili Teachers tabu u kojoj smo želeli da zabeležimo ime i predavanja. Možemo ga dizajnirati ovako:
Teacher_ID | Teacher_Name | Kurs |
---|---|---|
Teacher_001 | Carmen | Biologija |
Teacher_002 | Veronica | Matematika |
Teacher_003 | Jorge | Engleski |
Šta ako Carmen uči dva ili više kurseva? Imamo dve mogućnosti sa ovim dizajnom. Mogli bismo samo dodati u Carmenov postojeći zapis, ovako:
Teacher_ID | Nastavnik _Name | Kurs |
---|---|---|
Teacher_001 | Carmen | Biologija, matematika |
Teacher_002 | Veronica | Matematika |
Teacher_003 | Jorge | Engleski |
Dizajn iznad, međutim, je nefleksibilan i može dovesti do problema kasnije prilikom pokušaja umetanja, uređivanja ili brisanja podataka.
Otežava pretraživanje podataka. Ovaj dizajn krši prvi princip normalizacije baze podataka, First Normal Form (1NF) , koji navodi da svaka ćelija tablice treba da sadrži jedan pojedinačni diskretni podatak.
Druga alternativa dizajna mogla bi biti samo dodavanje drugog rekorda za Carmen:
Učitelj _ID | Nastavnik _Name | Kurs |
---|---|---|
Teacher_001 | Carmen | Biologija |
Teacher_001 | Carmen | Matematika |
Teacher_002 | Veronica | Matematika |
Teacher_003 | Jorge | Engleski |
Ovo se pridržava 1NF, ali je i dalje loš dizajn baze podataka, jer uvodi redundantnost i može se nepotrebno pretvoriti u veliku bazu podataka. Što je još važnije, podaci bi mogli postati nedosledni. Na primjer, šta ako se Carmenovo ime promijeni? Neko ko radi sa podacima može ažurirati svoje ime u jedan rekord i ne uspjeti ga ažurirati u drugom zapisu. Ovaj dizajn krši drugu normalnu formu (2NF), koja se pridržava 1NF, a takođe mora izbjeći višak nivoa višestrukih zapisa tako što odvaja podgrupe podataka u više tabela i stvara odnos između njih.
Kako dizajnirati bazu podataka sa jednoručnim odnosima
Da bismo implementirali odnos jedan-na-mnoge u tabeli Nastavnici i kursevi, razbijamo tabele na dva i povezujemo ih koristeći inostrani ključ .
Ovdje smo uklonili kolonu kursa u Tabeli Teachers:
Učitelj _ID | Nastavnik _Name |
---|---|
Teacher_001 | Carmen |
Teacher_002 | Veronica |
Teacher_003 | Jorge |
A ovdje je tabela Kursa. Imajte na umu da njegov inostrani ključ, Teacher_ID, povezuje kurs sa nastavnikom u Tabeli Nastavnika:
Course_ID | Course_Name | Teacher_ID |
---|---|---|
Course_001 | Biologija | Teacher_001 |
Course_002 | Matematika | Teacher_001 |
Course_003 | Engleski | Teacher_003 |
Razvili smo odnos između tabele nastavnika i kursa koristeći inostrani ključ.
Ovo nam govori da i Biologija i matematiku podučava Karmen i da Jorge drži engleski jezik.
Vidimo kako ovaj dizajn izbjegava bilo kakve moguće suvišne radne sposobnosti, omogućava pojedinačnim nastavnicima da predaju višestruke kurseve i sprovode odnos od jednog do drugog.
Baze podataka takođe mogu sprovesti jedan-na-jedan odnos i odnos mnogih prema mnogima.