MODEL RELACIJSKE BAZE PODATKOV: ELEMENTI, KAKO TO STORITI, PRIMER - TEHNOLOGIJA - 2026

Model relacijske baze podatkov je metoda strukturiranja podatkov z uporabo odnosov z uporabo mrežno podobnih struktur, sestavljenih iz stolpcev in vrstic. Gre za konceptualno načelo relacijskih baz podatkov. Leta 1969 jo je predlagal Edgar F. Codd.

Odtlej je postal prevladujoč model baze podatkov za poslovne aplikacije v primerjavi z drugimi modeli baz podatkov, kot so hierarhični, omrežni in objektni.

Vir: pixabay.com

Codd ni imel pojma, kako izjemno pomembno in vplivno bo njegovo delo kot platforma za relacijske baze podatkov. Večina ljudi je zelo dobro seznanjena s fizičnim izražanjem odnosa v bazi podatkov: tabela.

Relacijski model je opredeljen kot baza podatkov, ki omogoča razvrščanje svojih podatkovnih elementov v eno ali več neodvisnih tabel, ki se lahko med seboj povežejo z uporabo polj, ki so skupna vsaki povezani tabeli.

Upravljanje z bazami podatkov

Tabela zbirke podatkov je podobna preglednici. Vendar lahko razmerja, ki jih je mogoče ustvariti med tabelami, omogočajo, da relacijska baza podatkov učinkovito shrani veliko količino podatkov, kar je mogoče učinkovito pridobiti.

Namen relacijskega modela je zagotoviti deklarativno metodo za določanje podatkov in poizvedb: uporabniki neposredno izjavijo, katere podatke vsebuje baza podatkov in katere podatke iz njih želijo.

Po drugi strani pa ga prepustijo programski opremi sistema za upravljanje baz podatkov, da opišejo podatkovne strukture za shranjevanje in postopek pridobivanja za odgovor na poizvedbe.

Večina relacijskih baz podatkov uporablja jezik SQL za poizvedovanje in definiranje podatkov. Trenutno obstaja veliko sistemov za upravljanje relacijskih baz podatkov ali RDBMS (sistem za upravljanje relacijskih podatkovnih baz), kot so Oracle, IBM DB2 in Microsoft SQL Server.

Funkcije in elementi

- Vsi podatki so konceptualno predstavljeni kot urejena razporeditev podatkov v vrsticah in stolpcih, imenovana relacija ali tabela.

- Vsaka tabela mora imeti glavo in telo. Glava je preprosto seznam stolpcev. Telo je niz podatkov, ki napolni tabelo, organiziran v vrstice.

- Vse vrednosti so skalarne. To pomeni, da je v katerem koli položaju vrstic / stolpcev v tabeli le ena sama vrednost.

-Elementi

Naslednja slika prikazuje tabelo z imeni njenih osnovnih elementov, ki tvorijo popolno strukturo.

Tuple

Vsaka vrstica podatkov je nabor, znan tudi kot zapis. Vsaka vrstica je n-kornik, vendar je "n-" na splošno zavrženo.

Stolpec

Vsak stolpec v naboru se imenuje atribut ali polje. Stolpec predstavlja niz vrednosti, ki jih lahko ima določen atribut.

Ključ

Vsaka vrstica ima en ali več stolpcev, imenovanih ključ tabele. Ta kombinirana vrednost je edinstvena za vse vrstice v tabeli. S pomočjo tega ključa bo vsak nabor enkratno identificiran. Se pravi, ključa ni mogoče podvajati. Imenuje se primarni ključ.

Po drugi strani je tuji ali sekundarni ključ polje v tabeli, ki se nanaša na primarni ključ neke druge tabele. Uporablja se za sklicevanje na primarno tabelo.

- Pravila integritete

Pri načrtovanju relacijskega modela določite nekatere pogoje, ki jih mora izpolnjevati v bazi podatkov, imenovane pravila integritete.

Ključna celovitost

Primarni ključ mora biti edinstven za vse tupole in ne sme biti ničen (NULL). V nasprotnem primeru ne boste mogli enolično prepoznati vrstice.

Za ključ z več stolpci noben od teh stolpcev ne more vsebovati NULL.

Referenčna celovitost

Vsaka vrednost tujega ključa se mora ujemati z vrednostjo primarnega ključa referenčne ali primarne tabele.

Vrstico s tujim ključem lahko vstavite v sekundarno tabelo samo, če ta vrednost obstaja v primarni tabeli.

Če se vrednost ključa v primarni tabeli spremeni, ker je vrstica posodobljena ali izbrisana, je treba vse vrstice v sekundarnih tabelah s tem tujim ključem ustrezno posodobiti ali izbrisati.

Kako narediti relacijski model?

-Zbira podatke

Za shranjevanje v bazi podatkov je treba zbrati potrebne podatke. Ti podatki so razdeljeni v različne tabele.

Za vsak stolpec je treba izbrati ustrezno vrsto podatkov. Na primer: cele številke, številke s plavajočo vejico, besedilo, datum itd.

-Definirajte primarne ključe

Za vsako tabelo mora biti kot primarni ključ izbran stolpec (ali nekaj stolpcev), ki bo enolično opredelil vsako vrstico v tabeli. Primarni ključ se uporablja tudi za sklicevanje na druge tabele.

-Ustvarite razmerja med tabelami

Baza podatkov, sestavljena iz neodvisnih, nepovezanih tabel, je le malo namenjena.

Najpomembnejši vidik pri oblikovanju relacijske baze podatkov je prepoznavanje razmerij med tabelami. Vrste odnosov so:

Eden mnogim

V bazi podatkov o seznamih razredov lahko učitelj poučuje nič ali več razredov, medtem ko pouk poučuje en sam učitelj. Ta vrsta razmerja je znana kot eden do mnogih.

Tega razmerja ni mogoče predstaviti v eni tabeli. V bazi «Seznam razredov» imate lahko tabelo z naslovom Učitelji, v kateri so shranjeni podatki o učiteljih.

Če želite shraniti razrede, ki jih poučuje vsak učitelj, bi lahko ustvarili dodatne stolpce, vendar bi imeli težave: koliko stolpcev ustvariti.

Po drugi strani pa, če imate tabelo z imenom Razredi, v kateri so shranjeni podatki o razredu, lahko ustvarite dodatne stolpce za shranjevanje podatkov o učitelju.

Ker pa učitelj lahko poučuje veliko razredov, bi se njegovi podatki podvajali v več vrsticah v tabeli Razredi.

Oblikujte dve tabeli

Zato morate oblikovati dve tabeli: tabelo Razredi za shranjevanje informacij o razredih, pri čemer je primarni ključ Class_Id, in tabela Učitelji za shranjevanje podatkov o učiteljih, pri čemer je učitelj_Id primarni ključ.

Razmerje med mnogimi lahko nato ustvarite s shranjevanjem primarnega ključa iz glavne tabele (Master_Id) v tabelo Razredi, kot je prikazano spodaj.

Stolpec Master_Id v tabeli Razredi je znan kot tuji ali sekundarni ključ.

Za vsako vrednost Master_Id v tabeli Master lahko v tabeli Classes obstaja nič ali več vrstic. Za vsako vrednost Class_Id v tabeli Razredi je v tabeli Učitelji le ena vrstica.

Veliko do mnogih

V bazi podatkov o prodaji izdelkov lahko naročilo kupcev vsebuje več izdelkov, izdelek pa se lahko pojavi v več naročilih. Ta vrsta odnosa je znana kot marsikdo.

Podatkovno zbirko "Prodaja izdelkov" lahko začnete z dvema tabelama: Izdelki in naročila. Tabela Izdelki vsebujejo podatke o izdelkih, pri čemer je primarni ključ productID.

Po drugi strani pa tabela Naročila vsebuje naročila stranke, pri čemer je primarni ključ orderID.

Naročenih izdelkov ne morete shraniti v tabeli Naročila, saj ne veste, koliko stolpcev lahko rezervirate za izdelke. Iz istega razloga naročil ni mogoče shraniti v tabelo Izdelki.

Če želite podpirati razmerje med mnogimi, morate ustvariti tretjo tabelo, znano kot pridružena tabela (OrderDetails), kjer vsaka vrstica predstavlja element v določenem vrstnem redu.

Za tabelo OrderDetails primarni ključ sestavljata dva stolpca: orderID in productID, ki enotno identificirata vsako vrstico.

Stolpci orderID in productID v tabeli OrderDetails se uporabljajo za sklicevanje na tabele Naročila in izdelki. Zato so tudi tuji ključi v tabeli OrderDetails.

Eno za drugo

V bazi podatkov "Prodaja izdelkov" ima lahko izdelek neobvezne informacije, na primer dodaten opis in njegovo sliko. Če ga hranite v tabeli Izdelki, bi ustvarili veliko praznih prostorov.

Zato je mogoče ustvariti drugo tabelo (ProductExtras) za shranjevanje neobveznih podatkov. Za izdelke z izbirnimi podatki bo ustvarjen samo en zapis.

Obe tabeli, Produkti in ProductExtras, imajo odnos med seboj. Za vsako vrstico v tabeli Izdelki je v tabeli ProductExtras največ ena vrstica. Za obe tabeli je treba uporabiti isti izdelekID.

Prednost

Strukturna neodvisnost

V modelu relacijske baze podatkov spremembe strukture baze podatkov ne vplivajo na dostop do podatkov.

Kadar je mogoče spremeniti strukturo baze podatkov, ne da bi to vplivalo na sposobnost DBMS, da dostopa do podatkov, lahko rečemo, da je bila dosežena strukturna neodvisnost.

Konceptualna preprostost

Model relacijske baze podatkov je celo bolj konceptualno preprost kot hierarhični ali mrežni model baze podatkov.

Ker model relacijske baze podatkov oblikovalca razbremeni podrobnosti fizičnega shranjevanja podatkov, se lahko oblikovalci osredotočijo na logični pogled baze podatkov.

Enostavnost načrtovanja, izvajanja, vzdrževanja in uporabe

Model relacijske baze podatkov dosega tako neodvisnost podatkov kot neodvisnost strukture, kar olajša oblikovanje, vzdrževanje, upravljanje in uporabo baze podatkov kot drugi modeli.

Zmogljivost ad-hoc poizvedbe

Prisotnost zelo zmogljive, prilagodljive in enostavne uporabe poizvedb je eden glavnih razlogov za izjemno priljubljenost modela relacijske baze podatkov.

Poizvedbeni jezik modela relacijske baze podatkov, imenovan strukturirani poizvedbeni jezik, ali SQL, naredi ad hoc poizvedbe resničnost. SQL je jezik četrte generacije (4GL).

4GL omogoča uporabniku, da sam določi, kaj naj stori, ne da bi določil, kako naj to stori. Tako lahko s SQL uporabniki določijo, katere podatke želijo in pustijo podrobnosti, kako podatke pridobiti v bazo.

Slabosti

Stroški strojne opreme

Model relacijske baze podatkov skriva zapletenosti njegove izvedbe in podrobnosti fizičnega shranjevanja uporabniških podatkov.

Če želite to narediti, relacijski sistemi baz podatkov potrebujejo računalnike z zmogljivejšo strojno opremo in napravami za shranjevanje podatkov.

Zato RDBMS za nemoteno delovanje potrebujejo zmogljive stroje. Ker pa se procesna moč sodobnih računalnikov narašča z eksponentno hitrostjo, potreba po večji procesni moči v današnjem scenariju ni več velik problem.

Enostavnost oblikovanja lahko privede do slabe zasnove

Relacijsko bazo podatkov je enostavno oblikovati in uporabljati. Uporabnikom ni treba poznati zapletenih podrobnosti fizičnega shranjevanja podatkov. Za dostop do njih jim ni treba vedeti, kako so podatki dejansko shranjeni.

Ta enostavnost načrtovanja in uporabe lahko privede do razvoja in implementacije slabo zasnovanih sistemov za upravljanje baz podatkov. Ker je baza podatkov učinkovita, se te neučinkovitosti načrtovanja ne bodo pokazale, ko bo baza podatkov zasnovana in ko bo le majhna količina podatkov.

Z rastjo baze podatkov bodo slabo zasnovane zbirke podatkov upočasnile sistem in povzročile poslabšanje uspešnosti in korupcijo podatkov.

Fenomen "informacijskih otokov"

Kot smo že omenili, je sisteme relacijskih baz podatkov enostavno in uporabno uporabljati. To bo ustvarilo situacijo, ko bo preveč ljudi ali oddelkov ustvarilo lastne podatkovne baze in aplikacije.

Ti otoki informacij bodo preprečili vključevanje informacij, kar je bistveno za nemoteno in učinkovito delovanje organizacije.

Te posamezne zbirke podatkov bodo ustvarile tudi težave, kot so nedoslednost podatkov, podvajanje podatkov, odveč podatkov itd.

Primer

Predpostavimo bazo podatkov, ki jo sestavljajo tabele dobaviteljev, delov in pošiljk. Struktura tabel in nekaterih vzorčnih zapisov je naslednja:

Vsaka vrstica v tabeli dobaviteljev je označena z edinstveno številko dobavitelja (SNo), ki enotno identificira vsako vrstico v tabeli. Prav tako ima vsak del edinstveno številko dela (PNo).

Poleg tega za določeno kombinacijo dobavitelja / dela v tabeli pošiljk ne more biti več kot ena pošiljka, saj je ta kombinacija primarni ključ pošiljk, ki služi kot združevalna tabela, saj gre za razmerje med mnogimi.

Razmerje med tabelami delov in pošiljk je določeno s skupnim poljem PNo polja (številka dela) in razmerje med dobavitelji in pošiljkami nastane s skupnim poljem SNo (dobaviteljeva številka).

Če analiziramo tabelo pošiljk, lahko pridobimo informacije, da je od dobaviteljev Suneet in Ankit poslanih 500 oreškov, vsak po 250.

Podobno je bilo od treh različnih dobaviteljev odposlanih 1.100 vijakov. 500 modrih vijakov je bilo poslanih od dobavitelja Suneet. Ni pošiljk rdečih vijakov.

Reference

1. Wikipedija, brezplačna enciklopedija (2019). Relacijski model. Izvedeno iz: en.wikipedia.org.
2. Tehopedija (2019). Relacijski model. Vzeto iz: zgornja meja.
3. Dinesh Thakur (2019). Relacijski model. Opombe o elektronskem računalniku. Vzeto iz: ecomputernotes.com.
4. Geeks za Geeks (2019). Relacijski model. Izvedeno iz: geeksforgeeks.org.
5. Tehnološka univerza Nanyang (2019). Navodila za hitri začetek o oblikovanju relacijskih podatkovnih baz. Vzeto iz: ntu.edu.sg.
6. Adrienne Watt (2019). Poglavje 7 Model relacijskih podatkov. BC Odprti učbeniki. Izvedeno iz: opentextbc.ca.
7. Toppr (2019). Relacijske baze podatkov in sheme. Vzeto iz: toppr.com.