Baza podataka

Baza podataka' je organizirani skup podataka. Termin je izvorno nastao unutar računalne industrije, a njegovo se značenje proširilo popularnom uporabom toliko da Europska direktiva za baze podataka (koja za baze podataka donosi prava za intelektualno vlasništvo) uključuje i neelektronske baze podataka unutar svoje definicije. Ovaj članak je ograničen više na tehničku upotrebu termina, iako čak i među računalnim profesionalcima neki pripisuju mnogo šire značenje riječi od drugih.

Definicije

Jedna od mogućih definicija baze podataka glasi da je to zbirka zapisa pohranjenih u računalu na sustavan način, tako da joj se računalni program može obratiti prilikom odgovaranja na problem. Svaki se zapis za bolji povratak i razvrstavanje obično prepoznaje kao skup elemenata (činjenica) podataka. Predmeti vraćeni u odgovoru na upitnike postaju informacije koje se mogu koristiti za stvaranje odluka koje bi inače mogle biti mnogo teže ili nemoguće za stvaranje. Računalni program korišten za upravljanje i ispitivanje baze podataka nazvan je sustav upravljanja bazom podataka (SUBP). Svojstva i dizajn sustava baze podataka uključeni su u proučavanje informatičke znanosti.

Koncepti

Središnji koncept baze podataka je jednak onome od zbirke zapisâ ili dijelova znanja. Za danu bazu podataka tipično postoji strukturni opis vrste činjenica sadržanih u toj bazi podataka: taj opis naziva se shema. Shema opisuje predmete koji su prikazani u bazi podataka, te odnose među njima. Postoje brojni različiti načini organiziranja sheme, to jest od modeliranja strukture baze podataka: oni se zovu modeli baza podataka (ili modeli podataka). Model u najraširenijoj upotrebi danas je odnosni model, koji laički rečeno prikazuje sve informacije u obliku mnogostrukih odnosnih tablica od kojih se svaka sastoji od redova i stupaca (prava definicija koristi matematičku terminologiju). Ovaj model prikazuje odnose uporabom vrijednosti koje su zajedničke za više od jedne tablice. Ostali modeli poput hijerarhijskog modela i mrežnog modela koriste prikaze i odnose koji su mnogo eksplicitniji.

Naziv baza podataka se strogo govoreći odnosi na zbirku zapisa, a na softver bi se trebalo odnositi kao na sustav upravljanja bazom podataka ili SUBP. Kada je kontekst nedvojben, mnogi administratori za baze podataka i programeri ipak koriste termin baza podataka da pokriju oba značenja.

Mnogi profesionalci će smatrati da zbirka podataka stvara bazu podataka jedino ako ima određena svojstva: primjerice, ako se podatcima upravlja kako bi osigurali svoj integritet i kvalitetu, ako omogućuje zajednički pristup nekoj zajedinici korisnika, ako ima shemu, ili ako podržava upitni jezik. Ipak dogovorena definicija ovih svojstava ne postoji.

Sustavi upravljanja bazom podataka obično se kategoriziraju prema modelu podataka koji podržavaju: odnosni, orijentirani prema objektu, mrežni i tako dalje. Veliki dio internog inženjerstva SUBP-a, ipak je neovisan o modelu podataka, te je zaokupljen upravljanjem faktorima poput performansi, podudarnosti, integriteta i obnove nakon hardverskih propusta. U ovim područjima postoje velike razlike među proizvodima.

Povijest

Najranija poznata upotreba termina baza podataka potječe iz lipnja 1963. kada je Društvo za razvoj sustava uzelo pod pokroviteljstvo simpozij pod naslovom Razvoj i upravljanje računalno centriranom bazom podataka. Baza podataka (eng. ) kao jedinstvena riječ postala je uobičajena u Europi u ranim 1970-ima, a krajem desetljeća koristila se u glavnim američkim novinama. (Banka podataka, usporedni termin, koristio se vrlo rano u novinama Washington Post, 1966.)

Prvi sustavi upravljanja bazom podataka razvijeni su u 1960-ima. Začetnik u tom polju bio je Charles Bachman. Bachmanovi rani radovi pokazuju da je njegov cilj bio stvaranje djelotvornije upotrebe novih uređaja s izravnim pristupom pohrane koji su postali dostupni: do tada se obrada podataka temeljila na bušenim karticama i magnetskoj vrpci, pa je tako serijska obrada bila dominantna aktivnost. Dva su se ključna modela podataka pojavila u to vrijeme: CODASYL je razvio mrežni model baziran na Bachmanovim idejama, te se (očigledno neovisno) hijerarhijski model koristio u sustavu koji je razvio North American Rockwell, a kojeg je kasnije prihvatio IBM kao kamen temeljac svojeg SUI proizvoda.

Odnosni model je predložio E. F. Codd 1970. godine. On je kritizirao postojeće modele zbog zbrke apstraktnih opisa informacijskih struktura s opisima mehanizama fizikalnog pristupa. Ipak je dugo vremena odnosni model ostao samo u području akademskog interesa. Dok su CODASYL sustavi i SUI bili zamišljeni kao rješenja praktičnog inženjerstva, uzimajući u obzir tehnologiju koja je postojala u ono vrijeme, odnosni model je zauzeo mnogo veću teoretsku perspektivu, smatrajući (ispravno) da će hardverska i softverska tehnologija uhvatiti korak s vremenom. Među prvim provedbama bili su Stonebrakerov Ingres na Berkeleyju, te projekt Sustav R u IBM-u. Oba navedena su bili istraživački prototipovi objavljeni tijekom 1976. Prvi komercijalni proizvodi, Oracle i DB2, nisu se pojavili sve do oko 1980.

Tijekom 1980-ih istraživačka aktivnost se usredotočila na sustave distributivnih baza podataka i na strojeve baza podataka međutim taj je napredak imao malen učinak na tržište. Druga važna teoretska zamisao bio je funkcionalni model podataka, ali bez obzira na neke specijalizirane primjene u genetici, molekularnoj biologiji i istraživanju prijevara, svijet nije na njega obratio veliku pažnju.

U 1990-im pažnja se prebacila na baze podataka orijentirane prema objektu. To je polučilo nekakav uspjeh u poljima gdje je bilo potrebno rukovati kompleksnijim podatcima nego što bi se mogli udobno nositi odnosni sustavi: prostorne baze podataka, inženjerski podatci (uključujući odlagališta softverskog inženjerstva), multimedijski podatci. Neke od tih ideja prihvatili su odnosni prodavači, koji su kao posljedicu integrirali nove osobine u svoje proizvode; neovisni prodavači predmetnih baza podataka uvelike su nestali sa scene.

U 2000-im pomodno područje za inovacije postale su XML baze podataka. To je izbacilo, kao s predmetnim bazama podataka, novu zbirku pokrenutih društava, ali su se istovremeno ključne ideje integrirale u uspostavljene odnosne proizvode. XML baze podataka ciljaju ukoniti tradicionalnu podjelu između dokumenata i podataka, dopuštajući svim organizacijskim informacijskim resursima da se drže na jednom mjestu bez obzira da li su visoko strukturirani ili ne.

Modeli baza podataka

Različite tehnike se koriste za strukturu modela podataka. Većina sustava baza podataka se grade oko jednog određenog modela podataka, iako je u porastu zajedničko proizvodima da nude podršku za više od jednog modela. Za bilo koji logički model mogu biti moguće različite fizikalne provedbe, a većina će proizvoda ponuditi korisniku neku razinu kontrole u ugađanju fizikalne provedbe, pošto učinjeni izbori imaju značajan učinak na performansu. Primjer toga je odnosni model: sve ozbiljne provedbe odnosnog modela dopuštaju stvaranje indeksâ, koji omogućuju brzi pristup redovima u tablici, ako su poznate vrijednosti određenih stupaca.

Model podataka nije samo način strukturiranja podataka: on također definira skup operacija koje se mogu izvoditi na podatcima. Odnosni model, primjerice, definira operacije kao što su selekcija ili odabir, projekcija i spajanje. Iako ove operacije ne moraju biti eksplicitne u određenom query jeziku, one omogućuju temelje na kojima je query jezik izgrađen.

Ravni model

Neki se ne bi složili da ovo spada u vrste modela podataka zbog gornje definicije.

Ravni model|Ravni (ili tablični) model sastoji se od pojedinačnog, dvodimenzionalnog reda elemenata podataka, gdje se za sve članove danog stupca pretpostavlja da su slične vrijednosti, te da su svi članovi reda povezani jedni s drugima. Na primjer, stupci za ime i lozinku mogu se koristiti kao dio sigurnosnog sustava baze podataka. Svaki red bi imao specifičnu lozinku povezanu s individualnim korisnikom. Stupci tablice često imaju tip povezan s njima, definirajući ih kao oznake podataka, datum ili vremensku informaciju, cjelinu ili brojeve lebdećih točaka. Ovaj model je slučajno i baza tabličnog računanja.

Mrežni model

Mrežni model (definiran prema CODASYL specifikaciji) organizira podatke uporabom dvije fundamentalne konstrukcije, nazvane zapisi i skupovi. Zapisi sadrže polja (koja mogu biti organizirana hijerarhijski kao u COBOL-u). Skupovi (ne treba se zabuniti s matematičkim skupovima) definiraju odnose "jednog naprama svima" između zapisa: jedan vlasnik, mnogo članova. Zapis može biti i vlasnik i član u bilo kojem broju skupova.

Operacije mrežnog modela navigacijske su u stilu da: program održava tekući položaj i upravlja od jednog do drugog zapisa slijedeći odnose u kojima sudjeluje zapis. Zapisi mogu također biti smješteni dobavljanjem ključnih vrijednosti.

Iako nije bitno obilježje modela, mrežna baza podataka općenito provodi skup odnosa sredstvima pokazivača koji izravno adresiraju mjesto zapisa na disku. To daje izvrsne povratne performanse na račun operacija poput učitavanja i reorganizacije baze podataka.

Odnosni model

Odnosni model je uveo E. F. Codd 1970. godine u svom akademskom radu^[1] kao način stvaranja sustava upravljanja bazom podataka neovisnije od bilo koje druge posebne primjene. To je matematički model definiran u terminima predikatne logike i teorije skupova.

Iako je osnovna ideja odnosne baze podataka bila veoma popularna, relativno malen broj ljudi razumije matematičku definiciju, a samo nekoliko njih primjenjuje nejasne SUBP-ove u potpunosti i bez nekakvih dopuna. Oracle baza podataka, primjerice, može se koristiti na čisto relativni način, ali također dopušta i tablicama koje omogućuju dvostruke redove da se definiraju kao—dodatak (ili prijestup) odnosnog modela. U uobičajenoj upotrebi hrvatskog jezika, SUBP se naziva odnosnim ako podržava odnosne operacije, bez obzira da li provodi strogo pristajanje prema formalnom odnosnom modelu. Sljedeće objašnjenje je neformalno, netehničko objašnjenje kako "odnosni" sustavi upravljanja bazom podataka obično funkcioniraju.

Odnosna baza podataka sadrži mnogostruke tablice, svaka slična onoj u "ravnom" modelu baza podataka. Ipak, za razliku od mrežnih baza podataka, tablice nisu povezane pokazivačima. Umjesto toga ključevi se koriste za slaganje redova podataka u različitim tablicama. Ključ je samo jedan ili više stupaca u jednoj tablici koja odgovara stupcima u drugoj tablici. Svaki stupac može biti ključ ili se mnogostruki stupci mogu grupirati zajedno u pojedinačan ključ. Za razliku od pokazivača, nije potrebno definirati sve ključeve unaprijed; stupac se može koristiti kao ključ čak ako nije izvorno namjeravao biti jednim od njih.

Ključ koji se može koristiti za jedinstveno identificiranje reda u tablici naziva se jedinstvenim ključem. Tipično je jedan od jedinstvenih ključeva preferirani način za povezivanje njega s redom; takav ključ definira se kao tablični primarni ključ.

Kada se ključ sastoji od podataka koji imaju vanjsko, realno značenje (poput osobnog imena, ISBN knjige ili serijskog broja automobila), naziva se "prirodni" ključ. Ako nijedan prirodni ključ nije prikladan (razmislite o brojnim ljudima s prezimenom Babić), može se dodijeliti arbitraran ključ (poput davanja zaposlenicima ID brojeve). U praksi većina baza podataka ima i generirane i prirodne ključeve, jer se generirani ključevi mogu koristiti interno za stvaranje poveznica između redova koji ne mogu puknuti, dok se prirodni ključ može koristiti, manje pouzdano, za istraživanja i integraciju s drugim bazama podataka. (Na primjer, zapisi u dvije neovisno razvijene baze podataka mogu se povezati preko broja socijalnog osiguranja, osim kada su brojevi socijalnog osiguranja netočni, nedostaju ili su promijenjeni.)

Odnosne operacije

Korisnici (ili programi) potražuju podatke iz odnosne baze podataka slanjem upitnika koji je napisan u posebnom jeziku, obično dijalektu SQL-a. Iako je SQL izvorno namijenjen za krajnje korisnike, mnogo je uobičajenije za SQL upitnike da se ugrađuju u softver koji omogućuje jednostavnije korisničko sučelje. (Mnoge web stranice izvode SQL upitnike prilikom stvaranja stranice.)

Baza podataka u odgovoru na upitnik vraća skup rezultata, koji je samo popis redova koji sadrže odgovore. Najjednostavniji upitnik je samo vraćanje svih redova iz tablice, ali se mnogo češće redovi filtriraju na određeni način da povrate samo traženi odgovor.

Često se podatci iz mnogostrukih tablica spajaju u jednu, tj. provodi se spajanje. To se radi koncepcijski uzimanjem svih mogućih kombinacija redova ("presječni proizvod") te zatim filtriranjem svega osim odgovora. U praksi sustavi upravljanja odnosnim bazama podataka prepisuju ("optimiziraju") upitnike da se izvode brže, uporabom različitih tehnika.

Fleksibilnost odnosnih baza podataka dopušta programerima pisanje upitnikâ u kojem nisu sudjelovali dizajneri baza podataka. Kao rezultat, odnosne se baze podataka mogu koristiti u mnogostrukim primjenama na načine koje originalni dizajneri nisu predvidjeli, što je naročito važno za baze podataka koje su se možda koristile desetljećima. To je učinilo vrlo popularnim ideju i primjenu odnosnih baza podataka u trgovini.

Dimenzijski model

Dimenzijski model je specijalizirana preradba odnosnog modela korištenog za prikazivanje podataka u spremištima podataka na način na koji se podtaci mogu lako sažeti uporabom OLAP upitnika. U dimenzijskom modelu baza podataka se sastoji od jedne velike tablice činjenica koje su opisane uporabom dimenzija i veličina. Dimenzija omogućuje kontekst činjenice (poput tko je sudjelovao, kada i gdje se dogodilo i njezin tip), a koristi se u upitnicima za zajedničko grupiranje srodnih činjenica. Dimenzije teže da budu zasebne, a često su i hijerarhijske; na primjer, mjesto može uključivati zgradu, regiju i državu. Veličina je količina koja opisuje činjenicu kao što je dohodak. Važno je da veličine mogu biti značajno nagomilane - na primjer, dohodak s različitih mjesta može se zajedno pridodati.

U OLAP upitniku dimenzije su odabrane, a činjenice grupirane te pridodane zajedno da stvore sažetak.

Dimenzijski model se često provodi na vrhu odnosnog modela uporabom zvjezdaste sheme koja se sastoji od jedne tablice koja sadrži činjenice i okolne tablice koja sadrži dimenzije. Komplicirane dimenzije mogu posebice biti prikazane uporabom mnogostrukih tablica, rezultirajući u pahuljičnoj shemi.

Spremište podataka može sadržavati mnogostruke zvjezdaste sheme koje međusobno dijele dimenzijske tablice, omogućujući im da se zajedno koriste. Pojavljivanje sa standardnim skupom dimenzija važan je dio dimenzijskog modeliranja.

Provedbe i indeksiranje

Sve ovdje navedene vrste baza podataka stječu mogu steći prednost indeksiranja za povećanje svoje brzine, pa se ta tehnologija užasno unaprijedila od svojih ranih upotreba u 1960-im i 1970-im. Najuobičajenija vrsta indeksa je razvrstani popis sadržaja nekog posebnog stupca u tablici, s pokazivačima u redu kojem je pridružena vrijednost. Indeks omogućuje skupu redova tablice da poveže neki kriterij radi bržeg pronalaženja. Obično se koriste različite metode indeksiranja: B-stabla, heševi i povezani popisi. Sve navedene su uobičajene tehnike indeksiranja.

Odnosni SUBP-ovi imaju prednost u kojoj se indeksi mogu stvoriti ili ispustiti bez promjene postojećih aplikacija, jer aplikacije ne koriste izravno indekse. Umjesto toga softver baze podataka odlučuje o prednosti aplikacije ako se upotrijebe najpogodniji indeksi. Pri tom baza podataka odabire među mnogim različitim strategijama utemeljenima na onoj za koju procjeni da će joj omogućiti najbrži rad.

Odnosni SUBP-ovi upotrebljavaju mnoge različite algoritme radi izračunavanja rezultata SQL tvrdnje. OSUBP-ovi će proizvesti plan kako izvršiti upitnik, koji je stvoren analiziranjem vremena rada različitih algoritama i odabirom najbržeg. Neki od ključnih algoritama koji se bave sa spajanjima jesu slaganje ugniježđenih prstenova, spajanje složi-spoji i heš slaganje.

Kartiranje predmeta u bazama podataka

Tijekom nedavnih godina paradigma orijentirana prema predmetu primjenjivala se jednako i na baze podataka, stvarajući tako novi programski model poznat kao predmetne baze podataka. Ove baze podataka pokušavaju nadvladati neke poteškoće pri upotrebi predmeta sa SQL SUBP-ovima. Program orijentiran prema predmetu omogućuje predmetima istog tipa da se različito provode i ponašaju onoliko dugo dok imaju isto sučelje (polimorfizam). To se ne uklapa dobro sa SQL bazama podataka gdje se korisničko-određeni tipovi teško definiraju i koriste, te gdje opstaju Dvije velike zablude: identifikacija razreda tablicama (ispravna identifikacija je od razreda s tipovima i od predmeta s vrijednostima) i upotreba pokazivača.

Do sada su isprobani različiti načini spremanja predmeta u bazu podatka, ali ipak ne postoji velika suglasnost kako bi se to trebalo učiniti. Provedba predmetnih baza podataka uklanja pogodnosti odnosnog modela uvođenjem pokazivača i stvaranjem mnogo teže ad hoc upitnika. To je zato što su oni bitne adaptacije zastarjele mreže i hijerarhijskih baza podataka na programiranju orijentiranome prema predmetu. Posljedica predmetne baze podataka teže da budu korištene u specijaliziranim primjenama, dok opće namjenske predmetne baze podataka nisu veoma popularne. Umjesto toga predmeti se često spremaju u SQL baze podataka uporabom softvera s kompliciranim kartiranjem. Istovremeno prodavači SQL SUBP-a su nadodali obilježja kako bi omogućili predmetima mnogo pouzdaniju pohranu, razvijajući dalje do odnosnog modela.

Primjene baza podataka

Baze podataka se koriste u mnogim aplikacijama, protežući se na stvarno čitav opseg programske podrške. Baze podataka su poželjna metoda spremanja velikih multikorisničkih aplikacija gdje je potrebna koordinacija između mnogih korisnika. Čak ih individualni korisnici smatraju pouzdanima, iako se mnogi elektronički poštanski programi i osobni organizatori temelje na standardnoj tehnologiji baza podataka. Softverski pokretači baza podataka su dostupni za većinu platformi baza podataka tako da aplikacijski softver može koristiti zajedničko aplikacijsko programsko sučelje (APS) kako bi povratio informacije pohranjene u bazi podataka. Jedan primjer APS pokretača baze podataka je JDBC.

Transakcije i podudarnost

Pored njihovog modela podataka većina praktičnih baza podataka ("transakcijske baze podataka")pokušava provesti model transakcije baze podataka koji ima poželjna svojstva za integraciju podataka. Softver baze podataka bi trebao prema zamisli provoditi ACIP pravila sažeta ovdje:

Atomnost - Ili sve zadaće u transakciji trebaju biti napravljene ili nijedna. Transakcija mora biti dovršena ili se mora poništiti (vratiti natrag).
Dosljednost - Svaka transakcija mora sačuvati integritetnu prinudnost—izričita pravila dosljednosti—baze podataka. Ona ne može smjestiti podatke u kontradiktornom položaju.
Izolacija - Dvije simultane transakcije ne mogu interferirati, tj. križati se. Međurezultati unutar transakcije nisu vidljivi drugim transakcijama.
Postojanost - Dovršene transakcije se ne mogu kasnije prekinuti ili da se njihovi rezultati odbace. One se moraju nastaviti kroz (na primjer) ponovo pokretanje SUBP-a nakon njegova kraha.

U praksi mnogi SUBP-ovi dopuštaju većini ovih pravila da se selektivno ublaže radi bolje performanse.

Kontrola podudarnosti je naziv za metodu korištenu radi osiguravanja da se transakcije izvršavaju na siguran način i da slijede ACIP pravila. SUBP mora osigurati da su dopušteni serijabilni, nadoknadni rasporedi, te da nijedna radnja počinjenih transakcija nije izgubljena prilikom poništenja prekinutih transakcija.

Prema sadržaju

Prema sadržaju podatkovne baze mogu biti baze podataka s cijelim tekstom, citatne baze podataka i bibliografske baze podataka. Osim njih, postoje i platforme koje preko jednog sučelja za pretraživanje nude pristup cijelom nizu podatkovnih baza. Primjer tih platforma su EBSCO i Ovid.^[2]

Više informacija

Izvori

↑ Arhivirana kopija. Inačica izvorne stranice arhivirana 12. lipnja 2007.. http://www.acm.org/classics/nov95/toc.html Pristupljeno 16. listopada 2005.
↑ Repozitorij PMF Zagreb Bibliografske baze podataka, str. 1.-2. (pristupljeno 27. studenoga 2018.)

[1] Arhivirana kopija. Inačica izvorne stranice arhivirana 12. lipnja 2007.. http://www.acm.org/classics/nov95/toc.html Pristupljeno 16. listopada 2005.

[2] Repozitorij PMF Zagreb Bibliografske baze podataka, str. 1.-2. (pristupljeno 27. studenoga 2018.)

[1]

[2]