MODEL RELACIJSKE BAZE PODATAKA: ELEMENTI, KAKO TO UČINITI, PRIMJER - TEHNOLOGIJA - 2026

Model relacijske baze podataka je metoda strukturiranja podataka koristeći odnose, koristeći strukture slične mreži, koja se sastoje od stupaca i redaka. To je idejni princip relacijskih baza podataka. Predložio ga je Edgar F. Codd 1969. godine.

Otada je postao dominantni model baze podataka za poslovne aplikacije u odnosu na druge modele baza podataka, kao što su hijerarhijski, mrežni i objektni.

Izvor: pixabay.com

Codd nije imao pojma koliko će biti izuzetno važan i utjecajan njegov rad kao platforma za relacijske baze podataka. Većina ljudi je vrlo dobro upoznata s fizičkim izrazom odnosa u bazi podataka: tablici.

Relacijski model definiran je kao baza podataka koja omogućuje grupiranje njegovih podatkovnih elemenata u jednu ili više neovisnih tablica, koje se međusobno mogu povezati uporabom polja zajedničkih za svaku srodnu tablicu.

Upravljanje bazama podataka

Tablica baze podataka slična je proračunskoj tablici. Međutim, odnosi koji se mogu stvoriti između tablica omogućuju relacijskoj bazi podataka da učinkovito pohranjuje veliku količinu podataka, što se može učinkovito preuzeti.

Svrha relacijskog modela je pružiti deklarativnu metodu za specificiranje podataka i upita: korisnici izravno izjavljuju koje podatke baza podataka sadrži i koje podatke žele iz njih.

S druge strane, oni ga prepuštaju softveru sustava za upravljanje bazama podataka kako bi opisali strukture podataka za pohranu i postupak pretraživanja kako bi odgovorili na upite.

Većina relacijskih baza podataka koristi SQL jezik za postavljanje upita i definiranje podataka. Trenutno postoje mnogi sustavi za upravljanje relacijskim bazama podataka ili RDBMS (sustav za upravljanje relacijskom bazom podataka), kao što su Oracle, IBM DB2 i Microsoft SQL Server.

Značajke i elementi

- Svi su podaci konceptualno predstavljeni kao uređeni raspored podataka u redovima i stupcima, a nazivaju se relacijom ili tablicom.

- Svaka tablica mora imati zaglavlje i tijelo. Zaglavlje je jednostavno popis stupaca. Tijelo je skup podataka koji ispunjava tablicu, organiziran u redove.

- Sve su vrijednosti skalarne. To jest, u bilo kojem položaju retka / stupca u tablici postoji samo jedna vrijednost.

-Elementi

Sljedeća slika prikazuje tablicu s imenima njegovih osnovnih elemenata, koji čine potpunu strukturu.

torka

Svaki red podataka je zbir, također poznat kao i zapis. Svaki je red n-sloj, ali "n-" se uglavnom odbacuje.

Stupac

Svaki se stupac u množini naziva atributom ili poljem. Stupac predstavlja skup vrijednosti koje određeni atribut može imati.

Ključ

Svaki red ima jedan ili više stupaca zvanih ključ tablice. Ova kombinirana vrijednost jedinstvena je za sve retke u tablici. Pomoću ovog ključa svaki će se krafnik jedinstveno identificirati. Odnosno, ključ se ne može duplicirati. Zove se primarnim ključem.

S druge strane, strani ili sekundarni ključ je polje u tablici koje se odnosi na primarni ključ neke druge tablice. Koristi se za referencu na primarnu tablicu.

- Pravila integriteta

Prilikom dizajniranja relacijskog modela definirate neke uvjete koji moraju biti ispunjeni u bazi podataka, a nazivaju se pravila integriteta.

Ključni integritet

Primarni ključ mora biti jedinstven za sve tupole i ne može biti null (NULL). Inače nećete moći jednoznačno identificirati redak.

Za ključ s više stupaca, nijedan od tih stupaca ne može sadržavati NULL.

Referentni integritet

Svaka vrijednost stranog ključa mora odgovarati vrijednosti primarnog ključa referencirane ili primarne tablice.

Redak sa stranim ključem može se umetnuti u sekundarnu tablicu samo ako ta vrijednost postoji u primarnoj tablici.

Ako se vrijednost ključa promijeni u primarnoj tablici zbog retka koji se ažurira ili briše, sve redove u pomoćnim tablicama s ovim stranim ključem treba ažurirati ili izbrisati u skladu s tim.

Kako napraviti relacijski model?

-Prikupiti podatke

Potrebni podaci moraju se prikupiti za pohranjivanje u bazu podataka. Ti su podaci podijeljeni u različite tablice.

Za svaki stupac mora se odabrati odgovarajuća vrsta podataka. Na primjer: cijeli brojevi, brojevi s pomičnim zarezom, tekst, datum itd.

- Definirajte primarne ključeve

Za svaku tablicu kao primarni ključ mora biti odabran stupac (ili nekoliko stupaca), koji će jedinstveno identificirati svaki red u tablici. Primarni ključ koristi se i za upućivanje na druge tablice.

-Napravite odnose između tablica

Baza podataka koja se sastoji od neovisnih nepovezanih tablica malo služi.

Najvažniji aspekt u dizajniranju relacijske baze podataka je utvrđivanje odnosa između tablica. Vrste odnosa su:

Jedan mnogima

U bazi podataka "Popis klasa" nastavnik može podučavati nulu ili više klasa, dok jedan razred predaje jedan nastavnik. Ova vrsta odnosa poznata je kao jedan-prema-mnogima.

Taj se odnos ne može predstaviti u jednoj tablici. U bazi podataka «Popis predavanja» možete imati tablicu pod nazivom Učitelji, koja pohranjuje podatke o nastavnicima.

Da biste spremili časove koje podučava svaki nastavnik, mogli biste stvoriti dodatne stupce, ali suočili biste se s problemom: koliko stupaca stvoriti.

S druge strane, ako imate tablicu pod nazivom Klase koja pohranjuje podatke o razredu, mogli biste stvoriti dodatne stupce za spremanje podataka o učitelju.

No, kako učitelj može podučavati više razreda, njegovi će se podaci umnožavati u mnogim redovima u tablici Klase.

Dizajnirajte dvije tablice

Stoga trebate dizajnirati dvije tablice: tablicu Klase za spremanje podataka o klasama, s Class_Id kao primarnim ključem i tablicu Učitelji za spremanje podataka o učiteljima, a Teacher_Id je primarni ključ.

Odnos jedan prema mnogima tada se može stvoriti spremanjem primarnog ključa iz matične tablice (Master_Id) u tablicu Klase, kako je dolje prikazano.

Stupac Master_Id u tablici Klase poznat je kao inozemni ili sekundarni ključ.

Za svaku vrijednost Master_Id u tablici Master može biti nula ili više redaka u tablici Klase. Za svaku vrijednost Class_Id u tablici Klase postoji samo jedan redak u tablici Učitelji.

Mnogima mnogima

U bazi podataka "Prodaja proizvoda" narudžba kupca može sadržavati više proizvoda, a proizvod se može pojaviti u više narudžbi. Ova vrsta odnosa poznata je kao i mnogima.

Bazu podataka "Prodaja proizvoda" možete započeti s dvije tablice: Proizvodi i narudžbe. Tablica Proizvodi sadrži podatke o proizvodima, s primarnim ključem productID.

S druge strane, tablica Narudžbe sadrži narudžbe korisnika, s orderID-om kao primarnim ključem.

Naručene proizvode ne možete pohraniti u tablicu Narudžbe jer ne znate koliko stupaca rezervirati za proizvode. Iz istog razloga niti se narudžbe mogu pohraniti u tablicu Proizvodi.

Da biste podržali odnos mnogih prema mnogima, morate stvoriti treću tablicu, poznatu kao pridružujuća tablica (OrderDetails), gdje svaki red predstavlja stavku određenog reda.

Za tablicu OrderDetails primarni se ključ sastoji od dva stupca: orderID i productID, jedinstveno identificirajući svaki red.

Stupci orderID i productID u tablici OrderDetails koriste se za upućivanje u tablice Narudžbe i proizvodi. Stoga su i strani ključevi u tablici OrderDetails.

Jedan po jedan

U bazi podataka "Prodaja proizvoda" proizvod može imati neobavezne informacije, poput dodatnog opisa i njegove slike. Ako ga držite unutar tablice Proizvodi, stvorit će se puno praznih mjesta.

Stoga se može spremiti druga tablica (ProductExtras) za pohranu neobveznih podataka. Stvorit će se samo jedan zapis za proizvode s neobaveznim podacima.

Dvije tablice, Proizvodi i ProductExtras, imaju odnos jedan na jedan. Za svaki red u tablici Proizvodi nalazi se najviše jedan red u tablici ProductExtras. Isti productID mora se upotrijebiti kao primarni ključ za obje tablice.

Prednost

Strukturna neovisnost

U modelu relacijske baze podataka promjene strukture baze podataka ne utječu na pristup podacima.

Kad je moguće izvršiti promjene u strukturi baze podataka bez utjecaja na sposobnost DBMS-a da pristupi podacima, može se reći da je postignuta strukturna neovisnost.

Konceptualna jednostavnost

Model relacijske baze podataka je još konceptualno jednostavniji od hijerarhijskog ili mrežnog modela baze podataka.

Budući da model relacijske baze podataka dizajner oslobađa detalja fizičkog pohranjivanja podataka, dizajneri se mogu fokusirati na logički prikaz baze podataka.

Jednostavnost dizajna, implementacije, održavanja i uporabe

Model relacijske baze podataka postiže neovisnost podataka i neovisnost strukture, što projektiranje, održavanje, upravljanje i korištenje baze podataka čini mnogo lakšim od ostalih modela.

Kapacitet ad-hoc upita

Prisutnost vrlo snažne, fleksibilne i lako upitane mogućnosti jedan je od glavnih razloga ogromne popularnosti modela relacijske baze podataka.

Jezik upita modela relacijske baze podataka, koji se naziva strukturirani jezik upita ili SQL, stvarnost ad-hoc upita čini. SQL je jezik četvrte generacije (4GL).

4GL omogućava korisniku da odredi što treba učiniti, bez navođenja kako to treba učiniti. Tako, pomoću SQL-a, korisnici mogu odrediti koje informacije žele i ostaviti detalje kako doći do podataka u bazu podataka.

Nedostaci

Troškovi hardvera

Model relacijske baze podataka skriva složenosti njegove implementacije i detalje fizičkog pohranjivanja korisničkih podataka.

Da bi se to postiglo, sustavi relacijskih baza podataka trebaju računala s snažnijim hardverom i uređajima za pohranu podataka.

Stoga RDBMS-u su potrebni snažni strojevi za nesmetano pokretanje. Međutim, kako se procesna moć suvremenih računala eksponencijalno povećava, potreba za većom procesijskom snagom u današnjem scenariju više nije veliki problem.

Jednostavnost dizajna može dovesti do lošeg dizajna

Relacijsku bazu podataka lako je oblikovati i koristiti. Korisnici ne trebaju znati složene detalje fizičkog pohranjivanja podataka. Ne moraju znati kako se podaci pohranjuju da bi im pristupili.

Ova jednostavnost dizajna i uporabe može dovesti do razvoja i implementacije loše dizajniranih sustava upravljanja bazama podataka. Budući da je baza podataka učinkovita, ove neučinkovitosti u dizajnu neće se pojaviti kada je baza podataka dizajnirana i kada postoji samo mala količina podataka.

Kako baza podataka raste, loše dizajnirane baze podataka usporit će sustav i dovesti do degradacije performansi i oštećenja podataka.

Fenomen «informativnih otoka»

Kao što je prethodno spomenuto, sustavi relacijskih baza podataka lako se provode i koriste. To će stvoriti situaciju kada će previše ljudi ili odjela stvoriti vlastite baze podataka i aplikacije.

Ti će otoci informacija spriječiti integraciju informacija, što je neophodno za nesmetano i učinkovito funkcioniranje organizacije.

Te pojedinačne baze podataka također će stvoriti probleme poput nedosljednosti podataka, umnožavanja podataka, redundiranosti podataka itd.

Primjer

Pretpostavimo bazu podataka koja se sastoji od tablica dobavljača, dijelova i pošiljaka. Struktura tablica i nekih primjera zapisa je sljedeća:

Svaki red u tablici dobavljača identificiran je jedinstvenim brojem dobavljača (SNo), jedinstveno identificirajući svaki red u tablici. Isto tako, svaki dio ima jedinstveni broj dijela (PNo).

Nadalje, ne može biti više pošiljaka za određenu kombinaciju dobavljača / dijela u tablici pošiljaka, budući da je ova kombinacija primarni ključ pošiljki, koji služi kao sindikalna tablica, jer je odnos između mnogih i mnogih.

Odnos između tablica Dijelovi i Pošiljke dan je zajedničkim poljem PNo (broj dijela), a odnos između Dobavljača i Pošiljaka nastaje spajanjem SNovog polja (dobavljačkog broja).

Analizom tablice Otpreme mogu se dobiti informacije da se od dobavljača Suneet i Ankit šalje ukupno 500 oraha, svaki po 250.

Slično je bilo isporučeno i 1.100 svornjaka od tri različita dobavljača. 500 plavih vijaka isporučeno je od dobavljača Suneet. Nema isporuka crvenih vijaka.

Reference

1. Wikipedija, besplatna enciklopedija (2019). Relacijski model. Preuzeto sa: en.wikipedia.org.
2. Tehopedija (2019). Relacijski model. Preuzeto sa: zgornja ploča.hr.
3. Dinesh Thakur (2019). Relacijski model. Bilješke o elektroničkom računalu. Preuzeto sa: ecomputernotes.com.
4. Geeks za Geeks (2019). Relacijski model. Preuzeto sa: geeksforgeeks.org.
5. Nanyang Tehnološko sveučilište (2019). Vodič za brzi početak o relacijskom dizajnu baza podataka. Preuzeto sa: ntu.edu.sg.
6. Adrienne Watt (2019). Poglavlje 7 Model relacijskih podataka. BC Otvoreni udžbenici. Preuzeto sa: opentextbc.ca.
7. Toppr (2019.). Relacijske baze podataka i sheme. Preuzeto sa: toppr.com.