车讯:北斗星E/M50电动版 昌河公布新能源计划
Baza podataka je organizirana zbirka podataka. Termin je izvorno nastao unutar ra?unalne industrije, a njegovo se zna?enje pro?irilo popularnom upotrebom 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.
Jedna od mogu?ih definicija baze podataka glasi da je to zbirka zapisa pohranjenih u ra?unalu na sustavni na?in, takav 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.
Sredi?nji koncept baze podataka je jednak onome od zbirke zapisa 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 upotrebom 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 podacima 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, iapk 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.
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 podacima nego ?to bi se mogli udobno nositi odnosni sustavi: prostorne baze podataka, in?enjerski podaci (uklju?uju?i odlagali?ta softverskog in?enjerstva), multimedijski podaci. 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.
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 indeksa, 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 podacima. 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.
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 (definiran prema CODASYL specifikaciji) organizira podatke upotrebom 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 je uveo E. F. Codd 1970. godine u svom akademskom radu Arhivirano 2025-08-14 na Wayback Machine-u 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.)
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 podaci 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, upotrebom razli?itih tehnika.
Fleksibilnost odnosnih baza podataka dopu?ta programerima pisanje upitnika 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 je specijalizirana preradba odnosnog modela kori?tenog za prikazivanje podataka u spremi?tima podataka na na?in na koji se podaci mogu lako sa?eti upotrebom OLAP upitnik. U dimenzijskom modelu baza podataka se sastoji od jedne velike tablice ?injenica koje su opisane upotrebom 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 upotrebom 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 upotrebom 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.
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.
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 s 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 jer 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 upotrebom 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.
Baze podataka se koriste u mnogim aplikacijama, prote?u?i se na stvarno ?itav opseg ra?unalnog softvera. 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 orgnizatori 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.
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.
- Klijent-poslu?itelj
- Popis sustava za upravljanje relacijskim bazama podataka
- Sustav upravljanja bazom podataka
- Jezik rukovanja podacima
- Normalizacija baze podataka
- Baze podataka u Hrvatskoj
- Mrtva to?ka
- Deduktivna baza podataka
- Dimenzijska baza podataka
- Distibutivna baza podataka
- Model entitetskog odnosa
- Baza podataka ravne datoteke
- Hijerarhijska baza podataka
- Klju?no polje
- Baza podataka glavne memorije
- MUMPS
- Multidimenzijski hijerarhijski pribor
- Multidimenzijska baza podataka
- OLAP
- Skup zapisa : dinaskup, snimak (ra?unalna pohrana)
- Odnosni model
- SQL (Strukturirani jezik upitnika)
- Predmetna baza podataka
- Va?ne publikacije u bazama podataka
- Redundantnost (baze podataka)
- Softversko in?enjerstvo i Popis tema softverskog in?enjerstva
- Vremenska baza podataka
- Vrlo velika baza podataka
