U jednoj od mnogih veza u bazi podataka dolazi kada svaki rekord u tablici A može imati mnogo povezanih zapisa u tablici B, ali svaki zapis u tablici B može imati samo jedan odgovarajući zapis u tablici A. Odnos jednog do više u baza podataka je najčešći dizajn relacijske baze podataka i nalazi se u srcu dobrog dizajna.
Razmislite o odnosu između učitelja i tečajeva koje podučavaju. Učitelj može podučavati više tečajeva, ali tečaj ne bi imao isti odnos s učiteljem.
Stoga, za svaki zapis u tablici Nastavnici, moglo bi postojati mnogo zapisa u tablici Tečajeva. Ovo je jedan-na-mnogo odnos: jedan učitelj na više tečajeva.
Zašto je važno uspostavljanje jednog-na-mnogo odnosa
Da biste predstavljali jedan-na-mnogo odnosa, trebate barem dvije tablice. Pogledajmo zašto.
Možda smo stvorili tablicu učitelja u kojoj smo željeli snimiti ime i tečajeve. Možemo ga dizajnirati ovako:
Teacher_ID | Nastavnik TEACHER_NAME | Tečaj |
---|---|---|
Teacher_001 | Carmen | Biologija |
Teacher_002 | veronika | matematika |
Teacher_003 | Jorge | Engleski |
Što ako Carmen poučava dva ili više kolegija? Imamo dvije mogućnosti s ovim dizajnom. Možemo je samo dodati Carmenovom postojećem zapisu, ovako:
Teacher_ID | Učitelj _Name | Tečaj |
---|---|---|
Teacher_001 | Carmen | Biologija, matematika |
Teacher_002 | veronika | matematika |
Teacher_003 | Jorge | Engleski |
Dizajn iznad, međutim, je nepopustljiv i može uzrokovati probleme kasnije prilikom pokušaja umetanja, uređivanja ili brisanja podataka.
To otežava pretraživanje podataka. Ovaj dizajn krši prvi princip normalizacije baze podataka, Prvi normalni obrazac (1NF) , koji navodi da svaka ćelija tablice treba sadržavati jedan pojedinačni, diskretni dio podataka.
Druga alternativa za dizajn mogla bi biti jednostavno dodati drugi zapis za Carmen:
Učitelj _ID | Učitelj _Name | Tečaj |
---|---|---|
Teacher_001 | Carmen | Biologija |
Teacher_001 | Carmen | matematika |
Teacher_002 | veronika | matematika |
Teacher_003 | Jorge | Engleski |
To se pridržava 1NF, ali još uvijek je loša izvedba baze podataka, jer uvodi redundantnost i nepotrebno može nadvladati vrlo veliku bazu podataka. Još važnije, podaci mogu postati nedosljedni. Na primjer, što ako se Carmenovo ime promijenilo? Netko tko radi s podacima može ažurirati njeno ime u jednom zapisu i ne ažurirati ga u drugom zapisu. Ovaj dizajn krši drugi normalan obrazac (2NF) koji se pridržava 1NF i mora također izbjeći višak zapisnika odvajanjem odvojenih podskupina podataka u više tablica i stvaranje odnosa između njih.
Kako dizajnirati bazu podataka s jednim do mnogim odnosima
Da bismo implementirali odnos jednog do drugog u tablici Učitelji i tečajevi, razvrstavamo tablice u dva i povezujemo ih pomoću stranog ključa .
Ovdje smo uklonili stupac Tečaj u tablici Učitelji:
Učitelj _ID | Učitelj _Name |
---|---|
Teacher_001 | Carmen |
Teacher_002 | veronika |
Teacher_003 | Jorge |
Evo tablice tečajeva. Imajte na umu da njezin strani ključ, Teacher_ID, povezuje tečaj s učiteljem u tablici Učitelji:
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 tablice učitelja i tečajeva pomoću stranog ključa.
Ovo nam govori da je i biologiju i matematiku učio Carmen i da Jorge uči engleski.
Možemo vidjeti kako ovaj dizajn izbjegava moguće otkazivanje, omogućuje individualnim učiteljima da poučavaju više tečajeva i implementiraju jedan-na-više odnosa.
Baze podataka također mogu implementirati jedan-na-jedan odnos i mnogo-na-mnogo odnosa.