Stvaranje veza (odnosa) u bazama podataka

Stvaranje veza u bazama podataka

– Kada saznamo koje ćemo podatke skladištiti u našoj bazi podataka, moramo razmisliti o tome kako su ti delovi podataka međusobno povezani.
Neke baze podataka se mogu koristiti bez povezivanja zapisa u različitim tabelama. Baza podataka može jednostavno preuzeti zapise iz jedne ili druge tabele. Ali kako modeliramo složenije informacije u našoj bazi podataka, moraćemo da izgradimo odnose. Postoje tri vrste odnosa za povezivanje podataka.

To su odnosi jedan-prema-više (one-to-many), odnosi više-prema-više (many-to-many) i odnosi jedan-na-jedan (one-to-one).

Odnos nije nešto što moramo eksplicitno definisati u našoj šemi baze podataka ili u alatu DBMS. To može biti više način razmišljanja o tome kako su delovi podataka međusobno povezani u našem informacionom modelu.

Kada planiramo bazu podataka, povući ćemo linije koje predstavljaju veze.
Koristićemo te podatke za kreiranje polja, organizovanje tabela, smanjenje viška zaposlenih i poboljšanje integriteta naših podataka.
A kada su odnosi definisani, možemo konfigurisati našu bazu podataka da ih primeni.
U ovom poglavlju ćemo pogledati svaki odnos redom i videti kako se oni primenjuju na našu bazu podataka. (TABELA 1)

Odnos jedan-prema-više (one-to-many)

-Hajde da pogledamo odnos jedan prema više. Ovo je najčešći tip odnosa koji koriste baze podataka. Povezuje jedan deo podataka, jedan red tabele sa jednim ili više drugih podataka. Ovaj odnos je predstavljen linijom koja izgleda ovako: (TABELA 2).
Hajde da na trenutak razmotrimo tabelu naših gostiju i našu tabelu jela. (TABELA 3)
Želimo da predstavimo omiljeno jelo našeg kupca u tabeli „Gosti“.
Za svakog gosta bismo napisali naziv jela u kolonu „Omiljeno jelo“.
Ali ovo je mnogo posla i ako ikada promenimo naziv jela, možda bismo primetili pravopisnu grešku u tabeli sa jelima, morali bismo biti savesni i ažurirati ime u tabeli naših gostiju.

U maloj bazi podataka ovo možda i nije veliki problem, ali u velikoj bazi podataka ova vrsta praktičnog održavanja i administracije brzo bi postala dugotrajan problem za rešavanje i veliki problem za doslednost i integritet našeg podataka. Umesto toga, koristićemo primarni ključ za jelo za predstavljanje podataka u tabeli gostiju.
Korišćenje ključa ima nekoliko prednosti, ključ se nikada ne menja i garantovano je jedinstven. Takođe ima prednost što zauzima mnogo manje prostora od imena u punom tekstu, što pomaže da baza podataka bude manja kako se dodaje više unosa. Ovde koristimo odnos jedan prema više jer jedno jelo može biti omiljeno mnogim kupcima.

(TABELA 3) Tako ovo izgleda kao jedan prema više.
Mnogi gosti na jedno jelo.
U odnosu jedan prema više, strani ključ će biti na strani mnogih.
Redni broj jela je strani ključ u koloni „Omiljeno jelo“ u tabeli „Gosti“, tako da je ovaj odnos jedno jelo za mnoge goste, pa je jedan-prema-više.
Bez obzira na to u kom pravcu se odnos pojavljuje na papiru ili dijagramu, on je i dalje jedan prema više.
Sada, naša kolona sa omiljenim jelom ima podatak koji predstavlja čitav red u tabeli „Jelo“ i ne moramo da brinemo o promenama koje uzrokuju probleme koje ćemo morati da popravimo ili ažuriramo da bismo održali integritet naših podataka.

Ovaj odnos možemo takođe koristiti za modeliranje drugih veza između stavki. Da bismo pratili rezervacije, imali bismo unos za svaku rezervaciju u posebnoj tabeli. Svaka rezervacija će imati jednog gosta, ali jedan gost može imati mnogo rezervacija, barem se nadamo da hoće :). Korišćenje odnosa jedan-prema-više ne zahteva da kraj mnogih ima mnogo instanci. Mogle bi postojati samo dve različite vrednosti sa više strana, ili čak jedna. Poenta je u tome da ovaj odnos omogućava da se jedan zapis poveže sa mnogim zapisima.

Odnos više-prema-više (many-to-many)

-Drugi odnos koji se često koristi u bazama podataka naziva se odnos više prema više. Ovaj model je koristan kada želimo da povežemo više stvari sa više stvari. Hajde da razmotrimo naređenja i kako ih pratimo. Naša tabela porudžbina prati pojedinačne porudžbe gostiju. Postoji samo jedan gost po porudžbi i svaki gost bi mogao imati više od jedne porudžbe, tako da je to odnos jedan prema više. Ali porudžbine se mogu sastojati od više stavki.

Da bismo pratili koja su jela deo nekog redosleda, mogli bismo da počnemo da dodajemo kolone u tabelu „Porudžbine“ i da u svaku stavimo ključ jela, ali ne bismo trebali da počnemo da dodajemo kolone ovde u tabelu porudžbi jer ne znamo šta najveći broj stavki koje neko može da poruči. A ako napravimo 50 kolona, po jednu za svako potencijalno jelo koje gost može poručiti, većina naših polja će ostati prazna. Da bismo efikasno rešili ovaj problem, koristićemo odnos više prema više. Mnoge porudžbine mogu imati mnogo jela, a mnoga jela mogu biti uključena u mnoge porudžbe.

To je ono što crtamo kada otkrijemo da nam je potreban ovakav odnos, linija sa krakom na svakom kraju. I to nam je signal da moramo da uradimo još malo posla.
U većini DBMS alata ne možemo direktno da modeliramo odnos više prema više, pa moramo da napravimo povezujuću tabelu koja ima odnos jedan prema više sa obe tabele koje želimo da koristimo. Nazvat ćemo ga jela za poručivanje.
Ove povezujuće tabele se obično imenuju kombinovanjem tabele sa leve strane odnosa više prema više sa imenom tabele sa desne strane. Tabeli za povezivanje su potrebne samo dve kolone, Redni broj porudžbine i Redni broj jela. Za svaku stavku u porudžbini dodaćemo red za svako jelo.

Zatim, kada želimo da pozovemo informacije o porudžbama kupaca, od baze podataka ćemo tražiti redove koji odgovaraju brojevima porudžbina i vratićemo listu jela, tačnije,
Redne brojeve jela koji su bili deo svake porudžbe. To može biti samo jedan, a može biti i pet, 10 ili 50. Na taj način naša tabela porudžbi ostaje ljepa i čista, a istovremeno nam omogućava da zabeležimo detalje o tome šta je svaka porudžba uključila. Takođe, lako ćemo saznati u koliko porudžbina je uključeno određeno jelo.

Mogli bismo stvoriti druge odnose „više prema više“ koristeći povezujuće tabele za druga udruženja, na primer, ako želimo da pratimo više jela koja se sviđaju gostima, mogli bismo da gostima napravimo sto sa jelima, ili da imamo spisak sastojaka ili alergena, mogli bismo da napravimo tabelu sa sastojcima jela ili tabelu alergena u jelima, pa bismo te podatke mogli da imamo nadohvat ruke za štampanje detaljnih menija ili dodavanje upozorenja stavke na meniju za nekoga ko bi mogao biti alergičan na neki sastojak.

Takođe bismo mogli modelirati tabelu povezivanja događaja korisnika.
Ako gost prisustvuje ili je zainteresovan da prisustvuje raznim događajima koji se nude tokom cele godine.
Kao i prethodna tabela povezivanja, ovo bi uključivalo samo redni broj gosta i redni broj događaja sa jednim redom za svaki događaj kome gost planira da prisustvuje.
U izgradnji ovoga, moći ćemo i da dobijemo listu događaja za koje su određeni gosti zainteresovani da nam pomognu u planiranju.

Odnosi „više prema više“ prilično su česti, ali se zaista sastoje od odnosa jedan prema više sa dodatkom tabele za povezivanje. Dok modelirate svoju bazu podataka, imajte na umu da ćete možda morati da dodate neke tabele za povezivanje da biste ispunili određene odnose. Zapamtite, dizajniranje baze podataka sa ER dijagramima je iterativni proces. Ne morate to da uradite baš iz prvog pokušaja. (TABELA 4)

Odnosi jedan na jedan (one-to-one)

-Postoji još jedna vrsta odnosa koja se zove jedan na jedan. Ovo se ne koristi često, jer obično ako postoji samo jedan red koji je povezan samo sa jednim drugim redom, to sugeriše da bi dva reda trebala biti samo jedan red i jedna tabela. Naša baza podataka ovde nema ništa što zahteva odnos jedan na jedan.
Ali, stvarni primer odnosa jedan na jedan uključuje sigurnost. Tabelu naših gostiju mogli bismo da podelimo u dve tabele, stavljajući samo ime i redni broj gosta u jednu tabelu, a njihove lične podatke u drugu. Tada bismo imali odnos jedan-na-jedan između tabela.

Možemo odlučiti da zaštitimo lične podatke gostiju (poput njihovog rođendana ili e-mail adrese) od pogleda od strane naših zaposlenih, ostavljajući njihovo ime i ključ na raspolaganju za upotrebu u drugim odnosima, poput štampanja kartica mesta ili traženja rezervacije. Takođe bismo mogli da koristimo odnos jedan-na-jedan ako bismo iz stola opreme dodeljivali neke vrste resursa, poput kecelja, kuvarske kape itd. Ako jednu stavku dodelimo jednoj osobi, nije moguće dodeliti je drugoj osobi.

I jednoj osobi nije moglo biti dodeljeno više od jedne stavke. Odnosi jedan na jedan označeni su linijom sa samo jednom krajnjom tačkom sa obe strane. Neki alati DBMS -a će vam omogućiti da zaštitite pojedinačne kolone podataka. Dakle, u zavisnosti od vaše implementacije, izgradnja ovakvog odnosa možda neće biti potrebna za zaštitu informacija. Svakako da ima smisla čuvati povezane informacije zajedno, ali različita ograničenja mogu zahtevati da razdvojite informacije. To je primer denormalizacije, o čemu ćemo pisati uskoro

Pravila odnosa i referencijalni integritet

– Nakon što odlučimo kakvi će biti naši odnosi, šta predstavljaju i kako povezuju podatke, vreme je da odlučimo da li ćemo ih primeniti.
Baze podataka nam omogućavaju da imamo koristi od referencijalnog integriteta, što znači da će baza biti svesna odnosa i neće dozvoliti vama ili drugom korisniku da menja podatke na način koji krši taj odnos.
To nam pomaže da održimo doslednost baze podataka.
Pogledajmo ponovo tabelu naših kupaca i našu tabelu jela. (TJ TABELU BROJ 3)
Kolona „Omiljeno jelo“ nekog gosta je strani ključ iz tabele „Jelo“.

To je zaista samo broj, ali bazi podataka možemo reći kada kreiramo ovu tabelu, da broj u ovom polju takođe mora postojati u polju u drugoj tabeli.
Ne bi imalo smisla postaviti omiljeno jelo gosta na nešto što ne postoji.
Dakle, ako smo uneli gosta ili ažurirali njegov zapis i pokušali da unesemo nešto što ne postoji, baza podataka bi odbila unos ili promenu.
Mogli bismo da izvršimo promenu tek nakon što je to jelo dodato u bazu podataka, ili promenimo unos tako da odražava nešto što se već nalazi u tabeli „Jelo“.
Ovaj referentni integritet pomaže u održavanju baze podataka doslednom i tačnom.

Ne želimo da brinemo o tome da li u tabelama imamo loših podataka. Korišćenje ovakvih pravila integriteta omogućava bazi podataka da održava stvari doslednima, umesto da to radimo sami. Još jedna prednost referencijalnog integriteta je ta što ga možemo koristiti za brisanje zapisa ili sprečavanje brisanja zapisa. Ako bismo izbrisali zapis o gostu, moguće je da želimo da se porudžbine tih gostiju obrišu zajedno sa njima. U zavisnosti od vaših ograničenja privatnosti ili poslovnih zahteva, ovo bi moglo biti nešto što morate da uradite.

To se može uraditi ručno, ali ova pravila nam omogućavaju da baza podataka izvrši kaskadno brisanje, pri čemu se povezani zapisi uklanjaju radi održavanja doslednosti.
U suprotnom, kada se gost izbriše, njegove porudžbe bi se odnosile na nepostojećeg gosta.
Međutim, ovo nije nešto što želimo da uradimo sa svim našim podacima. Ako izbrišemo gosta, ne želimo da se njegovo omiljeno jelo ukloni sa naše tabele „Jelo“.
To jelo je i dalje dostupno drugim gostima, a i dalje je na našem jelovniku.
Zato je važno ne samo definisati odnose, već i odlučiti kako će ih primenjivati baza podataka. Doslednost je funkcija koju nudi baza podataka i morate odlučiti kako se primenjuje na vašu konkretnu situaciju.