Baze podataka – definicija, vrste, modeli

Baza podataka kao deljiva kolekcija međusobno logičko povezanih podataka danas je najčešće korišćena metoda za čuvanje, organizovanje, prikupljanje i sortiranje podataka, kao i smanjenje redundantnosti. Baze podataka u savremeno organizovanom društvu imaju veliku primenu (kupovina u supermarketu, podizanje gotovine na automatu, osiguranje vozila, korišćenje biblioteke, korišćenje Interneta, evidencija građana, katastar i mnoge druge primene).

Za funkcionisanje ovakvih sistema, pored baze podataka potreban je i aplikativni softver za komunikaciju sa bazama. Tu funkciju omogućuje Data Base Management System (skraćeno DBMS), ili sistem za upravljanje bazom podataka – softverski sistem koji omogućuje kreiranje, definisanje, korišćenje, održavanje i kontrolu pristupa  bazi podataka. DBMS omogućuje krajnim korisnicima ili programerima  da dele podatke, odnosno pruža mogućnost da se podaci jednovremeno koriste od strane više aplikacija i lišava nas potrebe da svaka aplikacija ima svoju kopiju podataka.

Definisanje baze podataka podrazumeva specifikaciju tipova i struktura podataka koje treba memorisati u bazu, kao i ograničenja nad podacima. Kao sredstvo za realizaciju pomenutih definicija koristi se jezik za definisanje podataka, engl. Data definition Language (skraćeno DDL). Definicije podataka se nalaze u katalogu sistema  i nazivaju se meta podaci.

Manipulacija bazama podataka podrazumeva pretraživanje, brisanje, dodavanje i izmenu podataka u bazi. Za ostvarivanje ovih manipulacija koristi se jezik za manipulaciju bazom podataka, engl. Data Manipulation Language (skraćeno DML). Deo DML-a  koji služi za pretraživanje baze podataka naziva se upitni jezik. Mnogi DBMS-i ugrađuju DML i DDL u neke jezike opšte namene (c, c++, Java, Ada, COBOL itd.).

slika1baze

Uprošćen prikaz okoline sistema baze podataka

Pomenuli smo u definiciji šta je i čemu služi DBMS. Ovde taksativno nabrajamo osnovne funkcije DBMS-a:

  • Memorisanje, pretraživanje i ažuriranje podataka
  • Održavanje sistemskog kataloga kome korisnici mogu pristupati
  • Podrška transakcijama
  • Servisi kontrole konkurencije
  • Servisi oporavka
  • Servisi autorizacije
  • Podrška za komunikaciju podataka
  • Servisi integriteta
  • Servisi nezavisnosti podataka
  • Uslužni servisi (Importovanje, eksportovanje, punjenje baze iz fajlova; Monitoring rada i korišćenja baze; Statistika korišćenja i merenje performansi; Reorganizacija indeksa; Kolekcija otpadaka i realokacija)

Evo i kratkog istorjata, odnosno odgovora na pitanje: kako su nastale baze podataka? 
Na inicijativu Američkog predsednika Kenedija, u okviru projekta Apollo, 60-tih godina 20-tog veka, začeta je ideja o bazama podataka . Rezultat ovog projekta je Generalized Update Access Method (skraćeno GUAM). Sredinom 60-tih godina, IBM je prihvatio GUAM ideju i razvio Information Managment System (skraćeno IMS) poznat kao hijearhijski DBMS.

Nakon toga General Electric razvija Integrated data Store (skraćeno IDS), tzv. mrežni DBMS. Edgar F. Codd iz IBM Research Lab  je 1970. predložio relacioni model. U prve komercijalne relacione DBMS koji su proizvedeni spadaju: projekat System R (IBM) krajem  70-tih (SQL), DB2 i SQL/DS (IBM) 80-tih i Oracle, takođe 80-tih. Danas postoji na hiljade relacionih DBMS-ova kao što su: MS SQL Server, DB2, Oracle i MySQL.

Godine 1976. Chen predlaže ER model, a posle tri godine Codd je predložio proširenu verziju relacionog modela koji se ubraja u semantičke modele podataka. 90-tih godina 20-tog veka nastaje potpuno novi DBMS: Objektno-orijentisani DBMS i Objektno-relacioni DBMS. Nova generacija nastala je 2000-te godine i poznata je kao NoSQL baze podataka. Takve su DO (document-oriented) baze i key-value skladištenje podataka. Jedan tip strukturne DO baze su XML baze zasnovane na atributima XML dokumenta.

Modeli baze podataka

  1. Hijearhijski  model
  2. Mrežni model
  3. ER (Entity Relationship) model
  4. Relacioni model
  5. Objektno-orijentisani i objektno relacioni model
  6. Dokument model
  7. EAV  (Entity-Atribute-Value) model
  8. Graf model

Hijearhijski i mrežni model, danas nisu zastupljeni, tako da ne zaslužuju veliku pažnju. U ovom tekstu, posvetićemo se relacionom, objektno orijentisanom, document i graf modelu baza podataka. ER model takođe nije mnogo popularan, međutim dobra strana ovog modela je što lepo objašnjava pojmove koji su važni za shvatanje osnova baza podataka.

ER (Entity Relationship) model

ER model se koristi za oblikovanje šeme baze podataka zasnovane na pravilima relacionog modela. Ovo je samo pomoćna faza modelovanja iz koje kasnije možemo preslikati ER šemu u relacionu. Ovaj model je takođe bitan za objašnjenje pojma entiteta, atributa i veze koji su ključni elementi svih baza podataka.

Entitet (Entity) je skup objekata iz realnog sveta koji imaju neka zajednička svojstva. Svojstva entiteta se nazivaju atributima i atributi opisuju entitet. Ime entiteta i skup atributa koji ga opisuju određuje tip entiteta. Može postojati veći broj primeraka (pojava) entiteta zadatog tipa (na primer KNJIGA je tip čiji su primerci „Deset malih crnaca“, „Izgubljeni simbol“, i tako dalje).

Postoji više vrsta atributa:

  • Prosti atribut – atribut je prost ako se dalje ne može dekomponovati,
  • Složeni atribut – atribut je složen ako je sastavljen od više elementarnih (prostih) atributa.
  • Izvedeni atribut – to je atribut čija se vrednost dobija primenom nekog algoritma na vrednosti drugih atributa,
  • Jednovrednosni atribut – atribut koji za jedan entitet može imati samo jednu vrednost,
  • Viševrednosni atribut  – atribut koji za jedan entitet može imati više vrednosti.

Skup atributa ili atribut, čije vrednosti jednoznačno određuju primerak entiteta zadatog tipa predstavljaju kandidate za ključ. Ukoliko jedan tip entiteta ima više kandidata za ključ tada biramo jednog od njih i nazivamo ga primarnim ključem, a ostali predstavljaju alternativne ključeve. Ne mogu postojati dva ili vise primeraka određenog tipa entiteta sa istim kljucem. Ukoliko neki tip entiteta nema ključ, nazivamog ga slabi tip entiteta. Između dva ili više tipova entiteta mogu se uspostavljati veze. Veza entiteta predstavlja imenovanu binarnu ili k-narnu relaciju između nekih primeraka entiteta zadatih tipova. Postoji nekoliko vrsta veza:

  • Jedan-prema-jedan  – kod ovog tipa veze element prvog skupa može biti povezan sa najviše jednim elementom drugog skupa. Istovremeno i svaki element iz drugog skupa može biti povezan samo sa jednim elementom iz prvog skupa.
  • Više-prema-jedan – kod ovog tipa veze svaki element iz prvog skupa može biti povezan sa najviše jednim elementom iz drugog skupa. Istovremeno svaki element iz drugog skupa može biti povezan sa više elemenata prvog skupa.
  • Jedan-prema-više – svaki element iz prvog skupa može biti povezan sa više elemenata iz drugog skupa i istovremeno svaki element iz drugog skupa može biti povezan sa samo jednim elementom iz prvog.
  • Više-prema-više  – svaki element iz prvog skupa može biti povezan sa više elemenata iz drugog skupa i istovremeno svaki element iz drugog skupa može biti povezan sa više elemenata iz prvog.

Svaka veza može imati svoje attribute koje ne možemo pripisati ni jednom od tipova entiteta.
ER šemu  možemo predstaviti ER dijagramom.

slika2baze

Primer ER dijagrama

Jednostavni primer ER dijagrama sa slike govori nam da imamo dva entiteta: VOZILO i VLASNIK. Entiteti u ER dijagramu se predstavljaju  kao pravougaonici sa upisanim imenom. Entitet VOZILO ima četiri atributa. Atributi se prikazuju u obliku elipse sa upisanim nazivom.

Atribut RegBroj je podvučen zato što predstavlja primarni ključ. Između entiteta VOZILO I VLASNIK postiji veza POSEDUJE koju predstavljamo kao romb sa upisanim imenom. Veza je tipa N:1 što znači da svaki elemenat iz skupa VOZILO poseduje samo jedan element iz skupa  VLASNIK, a istovremeno i svaki elemenat iz skupa VLASNIK može da poseduje više elemenata iz skupa VOZILO.  Atribut Ime kod entiteta VLASNIK je složeni atribut čije su komponente LičnoIme i Prezime.

Ukoliko bi postojali viševrednosni atributi u ER dijagramu, njih bi smo označavali dvostrukom elipsom sa upisanim imenom, izvedeni atributi se prikazuju elipsom koja je iscrtana isprekidanom linijom sa upisanim imenom. Napomenimo da pored osnovnog postoji i EER (prošireni model objekti – veze) koji omogućuje detaljnije definisanje veza između objekata.

Relacioni model podataka

Relacioni model podataka je popuaran model koji se zasniva na matematičkom pojmu relacija. Baza podataka se u ovom modelu sastoji od skupa tabela, tzv.relacija. Svaka relacija ima svoje ime kako bi je razlikovali od ostalih relacija u bazi i  sastoji se od kolona i vrsta. Vrste u relacijama označavaju n-torku, a po pravilu u tabeli ne smemo imati dve iste n-torke (u ER modelu to bi bili entiteti).

Svaka kolona u relaciji predstavlja vrednost atributa za određeni entitet ili vezu i zbog  toga je poistovećujemo sa atributom. Svaki atribut ima svoj tip podataka i svoje jedinstveno ime, kako bismo mogli da ga razlikujemo u okviru relacije u kojoj se pojavljuje. Ono što je veoma bitno za neku relaciju je definisanje ključa te relacije. Ključ se definiše kao minimalni skup atributa takav da važe pravila:

  1. ključ jednoznačno određuje n-torku, što znači da nemamo dve ili više n-torki sa istim ključem,
  2. ukoliko izbacimo iz ključa bilo koji atribut, tada se narušava svojsvo broj jedan

Postoje situacije kada imamo više ključeva  kandidata, u takvim situacijama se bira samo jedan primarni ključ isto kao kod ER modela. Relacije možemo opisati šemama relacije.
Primer: Lista gostiju u nekom hotelu

GOST(Broj_licne_karte, Ime, Prezime, Datum_dolaska, Datum_odlaska, Soba)

U gornjoj šemi Broj_licne_karte predstavlla primarni ključ relacije. Njega predstavljamo tako što punom linijom podvlačimo atribut  koji predstavlja primarni kjuč.

Tabelarni prikaz rezervacija u nekom hotelu

Tabelarni prikaz rezervacija u nekom hotelu

Kod relacionog modela baze podataka imamo iste vrste veza koje se pominju u ER modelu (1:1, 1:N, N:1, N:M). Osnovne skupovne operacije  nad relacijama su:

  • Unija
  • Presek
  • Razlika
    Primer rezultata unije, preseka i razlike između relacija r i s

    Primer rezultata unije, preseka i razlike između relacija r i s

  • Selekcija (selektovanje torki relacije po nekom kriterijumi ili bez kriterijuma)
    Primer selekcije sa selektovanjem svih torki iz relacije r sa uslovom da je plata veća od 4000 i da rade na projektu sa šifrom 11

    Primer selekcije sa selektovanjem svih torki iz relacije r sa uslovom da je plata veća od 4000 i da rade na projektu sa šifrom 11

  • Projekcija (izdvajanje vrednosti pojedinih kolona iz relacije)
     Primer projekcije sa izdvajanjem svih pilota (P) i tipova aviona (A) na kojima lete

    Primer projekcije sa izdvajanjem svih pilota (P) i tipova aviona (A) na kojima lete

  • Prirodni spoj (spajanje torki različitih relacija po osnovu istih vrednosti zajedničkih obeležja)
    Primer prirodnog spoja

    Primer prirodnog spoja

Nabrojmo neke pogodnosti relacionih baza podataka:

  • Omogućavaju sprovođenje složenih upita
  • Zadovoljavaju buduće potrebe – imajući u vidu da se podaci čuvaju u posebnim tabelama, uvek postoji mogućnost da se ubace podaci koji sada nisu potrebni, ali će biti u budućnosti
  • Poboljšana bezbednost – podaci su raspoređeni po tabelama, a određene tabele se mogu zaštititi (biti poverljive). Kada se korisnik uloguje korisničkim imenom i lozinkom sistem može da mu ograniči pristup određenim tabelama.
  • Podaci su u tabeli zapamćeni samo jednom – nema višestrkog ponavljanja istih podataka.

Kao nedostatke relacionih baza podataka mogli bi smo navesti, pre svega skupo uspostavljanje i održavanje  sistema ovakvih baza, problem obilja informacija (složenost informacija izaziva dodatne probleme), strukturne granice (pri projektovanju relacione baze podataka mora se odrediti količina podataka koja može stati u polje – ukoliko  se pojavi podatak koji je duži, može dovesti do gubitka podataka) i izolovanost baza podataka (kompleksni sistemi relacionih baza podataka mogu dovesti do tzv. “ostrva informacija” gde se informacije ne mogu lako deliti između više velikih sistema).

Objektno-orijentisani i objektno-relacioni model podataka

Obekno-orijentisani model podataka omogućuje predstavljanje podataka  u formi objekata, u smislu OO programskih jezika. Primeri ovakvih modela podataka su: Versant db4o, Ontos, Matisse, GemStone i drugi. Karakteristike objektno orijentisanih baza podataka su sledeće:

  • Podaci su predstavljeni kao objekti
  • Deklarativni jezik za ad-hoc upite
  • Veza sa OO programskim jezicima
  • Proširiva hijearhuja tipova u smislu korisnički definisani tipovi, apstraktni tipovi, nasleđivanje i višestruko nasleđivanje, overloading, overriding, late binding.
  • Perzistentnost objekata (mogućnost da neki objekti prežive kraj izvršenja aplikacije)
Karakteristike OO baze podataka

Karakteristike OO baze podataka

Objekat je korisnički definisani, kompleksni tip podataka koji ima svoju strukturu i stanje (atributi i svojstva), kao i  ponašanje (metode i operacije). Objekti programskog jezika se bez ikakve transformacije pamte i čuvaju u bazi, a možemo ih opisati sa četiri karakteristike:

    1. Identifikator – jedinstven identiifikatorobjekta na nivou sistema
    2. Ime – objekat može, ali i ne mora da ima jedinstveno ime u bazi podataka
    3. Životni vek – određuje da li je objekat privremen ili perzistentan
    4. Struktura – kreiranje objekata korišćenjem konstruktora tipa podataka

U OO modelu baze podataka ne postoji koncept primarnog ključa, već OODBMS za svaki objekat pamti jedinstveni i neprimenljivi identifikator – Object IDentifier (skraćeno OID) koji se koristi  za referenciranje objekta u okviru baze podataka. Ovaj identifikator nije dostupan aplikaciji, sto znaci da ga ne mozemo sami definisati niti menjati. Sam sistem  dodeljuje ovaj tzv. eksterni identifikator.

Deo UML-a (Unified Modeling Language) koji prikazuje klase Student i Osoba

Deo UML-a (Unified Modeling Language) koji prikazuje klase Student i Osoba

Osoba predstavlja super klasu, Student predstavlja podklasu. Klasa Student nasleđuje sve atribute i operacije klase Osoba. Atribut Ime u klasi Osoba je složeni atribut. Svaki atribut je predstavljen u formatu ime_atributa: tip_atributa. Pored atributa BrojIndeksa u klasi Student stoji oznaka {PK} koja označava primarni ključ. Operacije su predstavljene u obliku ime_operacije(parametri_operacije): povratna_vrednost_operacije.

Izgled klasnog dijagrama sa prethodne slike u ODL-u (engl. Object Definition Language )

Izgled klasnog dijagrama sa prethodne slike u ODL-u (engl. Object Definition Language )

Nedostaci u odnosu na RDMBS bili bi: problematična evoluacija šeme baze podataka, nedostatak podrške za različite programske jezike, optimizacija upita, ograničenja, trigeri i drugo.

Gde koristimo  OO model baze podataka?

  1. Kada je potrebna besprekorna integracija operativnih sistema, baze podataka, tabela i sl.
  2. Kada se  zahteva deljenje informacija, proizvoda, softvera,
  3. U aplikacijama gde je nasledjivanje kao osobina OO modela bitno

Objektno relacioni model

Objektno relaciona baza podataka predstavlja relacionu bazu podataka sa elementima objektnog modela kao što su objekti, klase i nasleđivanje. Ovaj model je nastao sa ciljem da se prevaziđu razlike koje postoje između rlacionih modela i objektnih modela baza podataka. Primeri ovakvih modela baze podataka su PostgreSQL, MS SQL Server, Oracle, IBM DB2. Mnogi elementi OR modela baze podataka su ugrađeni u SQL. Osnovne karakeristike OR modela:

  • Kompleksni podaci – definišu se korišćenjem User Data Type (skraćeno UDT ) mehanizma koji je sastavni deo SQL specifikacije
  • Nasleđivanje
  • Tipovi sadrže proceduralne elemente što znači da objekti sadrže metode koji menjaju stanje podataka

Razlike između objetnih i relacionih modela podataka se mogu prevazići i O/R maperima, mada su danas popularnije rešenje objektno-relacioni modeli podataka.

Dokument orijentisani modeli podataka

Dokument  orijentisana baza podataka predstavlja kategoriju  NoSQL baze podataka. Ove baze podataka su organizovane oko apstraktnog koncepta – dokument i predstavljaju kolekciju dokumenata. Jasno je izražena razlika u odnosu na relacione baze koje su organizovane oko koncepta relacija.

Sve informacije se nalaze u samom dokumentu i ne postoji povezivanje tabela. Za razliku od relacione baze podataka u kojoj sve vrste imaju iste kolone, kod document baza podataka, svi dokumenti ne moraju  da imaju istu strukturu i nema potrebe za striktnim definisanjem šeme baze podataka.

Karakteristike document orijentisanih baza su:

  • Objekti se čuvaju kao dokumenti bez objektno – relacionog neslaganja. Objektni model se snima u document i pamti u bazi podataka
  • Čitav objektni model može da se snimi odjednom tako da nema potrebe za velikim brojem atomičnih CRUD operacija.
  • Podaci se najčešće čuvaju korišćenjem otvorenih formata: XML, JSON, BSON (Binary JSON), YAML. Postoje i baze podataka koje čuvaju i dokumenta u binarnim formatima (PDF ili Ofice doumenti).
  • Dokumenti su nezavisni čime  se povećavaju  performanse i smanjuju problemi vezani za konkuretan pristup podacima.
  •  Kao što je pomenuto, ne postoji šema baze podataka tako da se podaci mogu dodavati bez promene dokumenata u bazi, ovime se povećava i fleksibilnost sistema.
  • Danas postoje mnoga rešenja za čuvanje informacija o prethodnim verzijama  koja koriste baze podataka za pohranjivanje informacija.

Jedan dokument bi mogao izgledati ovako:

Primer strukture jednog dokumenta u bazi

Primer strukture jednog dokumenta u bazi

Poznate su i document baze sa Key/Value strukturom kod kojih Value predstavlja polu-strukturiani dokument čija je struktura razumljiva bazi podataka. Za pristup dokumentima u bazi podataka najčešće se koristi vrednost ključa. Ključ je najčešće string ali može biti URI ili neki oblik putanje. Baza je indeksirana po vrednosti ključa kako bi pristup dokumentima bio optimalan.

Primer key/value strukture

Primer key/value strukture

Osim pristupa dokumentima korišćenjem mehanizama ključa, većina dokument baza podataka nudi API ili upitni jezik za pretraživanje dokumenata. Cilj je  pronaći dokumente kod kojih određeno polje ima navedenu vrednost. Često dokument baze podataka obezbeđuju http servere koji obrađuju standardne HTTP zahteve za podacima (PUT/GET/POST/DELETE).

Jedna od osnovnih karakteristika ovih baza podataka je eventualna konzistencija (Eventual consistency) koja omogućuje korisnicima da menjaju dokumente u bazi podataka. Izmene na dokumentima nisu vidljive u istom trenutku svim klijentima koji im pristupaju, ali svima postaju vidljive u nekom trenutku. Kao posledica ovoga povremeno se javlja nekonzistentnost u podacima. Poznate dokument orijentisane baze podataka su CouchDB, RavenDB i MongoDB.

Kada koristiti ovaj model podataka?

  1. kada je potrebno skladištiti dinamičke podatke, u sistemima kao što su Content Management System (skraćeno CMS ) i Customer Relationship Management (skraćeno CMR )  entiteti, koje krajnji korisnik može da menja po potrebi,
  2. kod Web podataka (Web Related Data), kao što su korisničke sesije, logovi,  shoping cart i drugi podaci koji se održavaju za potrebe Web aplikacija. Dokument skladištenja omogućuju da se podacima pristupa kao celini jednim zahtevom ka udaljenom serveru.
  3. kod dinamičkih entiteta, kao što su korisnički prilagodljivi entiteti, entiteti sa velikim brojem izbornih oblasti, itd.
  4. kod perzistentnog modela pogleda (Persistent View Models) – umesto ponovnog otvaranja i prikaza modela od nule  na svaki zahtev, može se prikaz sačuvati u svom konačnom obliku dokumenta podataka. Ovo dovodi do smanjenja računanja, udaljenih poziva i poboljšanje ukupnih performansi.
  5. kod skladištenja velikih količina podataka.

Problemi mogu nastati kada se zahteva transakciona obrada (nema podrške za ACID transakcije) i kada  je neophodno koristiti veliki broj spojeva.

Graf baze podataka

Graf baze podataka takođe spadaju u NoSQL baze podataka. Koriste strukturu podataka tipa graf (čvorovi, potezi i svojstva) za reprezentaciju i skladištenje podataka. Kod graf baze podataka svaki element može da sadrži direktan pokazivač ka drugim elementima bez potrebe za postojanje indeksnih struktura.  Najočigledniji primer graf baza podataka su veze između ljudi na socijalnim mrežama.

Elementi graf baze podataka su čvorovi, potezi i svojstva. Čvorovi se koriste za reprezentaciju entiteta. Svaki čvor u bazi može da ima neograničen broj svojstava. Svojstva su podaci koji opisuju čvorove i  možemo ih izjednačiti sa atributima. Potezi su relacije koje povezuju čvorove međusobno ili čvorove sa svojstvima i mogu imati sopstvena svojstva. Koncept poteza je sličan konceptu objekta u OO programiranju.

Primer graf baze podataka

Primer graf baze podataka

Najjednostavnija graf baza, podatak sadrži samo jedan čvor. Pored generalnih graf baza podataka koje mogu da skladište bilo koji graf, postoje i specijalizovane graf baze podataka kao što su triplestore (skladištenje podataka u obliku subjekat-predikat-objekat, RDF) i mrežne baze podataka koje se zasnivaju na korišćenju mrežnog modela.

Zašto graf baze podataka?

  1. Zbog velike količine podataka koje ne zahtevaju skupe operacije spoja
  2. Direktno mapiranje iz graf baze podataka na OO model
  3. Rešenje za asocijativne skupove podataka
  4. Pogodne su za razvoj ad-hoc aplikacije ili aplikacije koje brzo evauliraju zbog svoje fleksibilne šeme
  5. Pogodne za operacije tipa: obilazak grafa, provere da li postoji put  između dva čvora, određivanje suseda, traženje najkraćeg puta između dva čvora i sl.

Razlike između graf baze podataka i relacione baze:

    • Relacione baze podataka su brže kod upita pri ogromnim količinama podataka jer ne moraju ispitati svaki zapis tokom upita
    • Relacione baze podataka koriste manje prostora, jer ne moraju da pamte sve veze koje pamte graf baze
    • Relacione baze su optimizovane za agregaciju podataka, a graf baze za veze između podataka
    • Graf baze podataka su pogodne za neredovne, složene strukture, dok  su relacione pogodne  za redovne,  relativno jednostavno strukture koje se i većinom zahtevaju u realnom svetu, pa zbog toga relacione baze i preovladavaju.

Kod Key/Value skladištenja  podataka podaci su organizovani  u strukturi stabla, a kod graf baze podataka podaci mogu biti organizovani u različite kompleksne strukture. Još jedna bitna razlika je što su Key/Value skladištenja podataka optimizovana za jednostavne lookup pretrage, a graf baze podataka za obilaske povezanih podataka. Najpoznatije graf baze podataka su Neo4j, AllegroGraph, Sones, Virtuoso, HyergraphDB i dr.

Zaključak

U savremenom svetu, upotreba baza podataka je veoma raširena. Korisnicima aplikacija ili servisa, naravno nije bitno koji model baze podataka se koristi, ali za dizajnera aplikacije biranje modela baze podataka može da predstavlja problem. Kao što smo videli iz ovog kratkog preleda, postoje brojni modeli sa razlicitim karakteristikama. Pre nego se započne dizajniranje konkretne baze podataka, najbolje je napraviti analizu onoga što je na raspolaganju i  steći uvid koliko ponuđena rešenja zadovoljavaju projektovane potrebe. Osim navedenih modela baze podataka, postoje i drugi modeli koji se ređe koriste, neki koji  se više ne koriste i oni koji su u fazi razvoja.

Navešćemo asocijativni model, semanticki model, XML baze podataka, a u modele koji se retko ili uopšte ne koriste ubrojaćemo mrežni i hijearhirski model.
ER model se uglavnom koristi samo kao pomagalo pri kreiranju  relacione baze podataka. Najčešće korišćeni modeli danas su relacioni, objektno orijentisani i dokument model baze podataka. Upotreba graf modela baze podataka tek počinje i dobija na popularnosti.

Njegova upotreba se ogleda u socijalnim mrežama koje svakodnevno okupiraju paznju velikog broja ljudi. Ono što je nesporno jeste da  baze podataka kroz brojne aplikacije i sisteme postaju bitan deo stvarnosti i sveta koji nas okružuje i samim time zahtevaju stalno unapređenje i poboljšanje karakteristika.

itmogul-logoTekst je preuzet sa ugašenog bloga IT modul i originalna autorka ovog teksta je Sanja Dimković. Kompjuteraš IT blog će objavljivati tekstove sa tog bloga kako riznica znanja sa te lokacije ne bi otišla u zaborav.

Komentarišite

Email neće biti javno objavljen. Sajt je neobavezan podatak, svi ostali su obavezni.