База података као дељива колекција међусобно логичко повезаних података данас је најчешће коришћена метода за чување, организовање, прикупљање и сортирање података, као и смањење редундантности. Базе података у савремено организованом друштву имају велику примену (куповина у супермаркету, подизање готовине на аутомату, осигурање возила, коришћење библиотеке, коришћење интернета, евиденција грађана, катастар и многе друге примене).

За функционисање оваквих система, поред базе података потребан је и апликативни софтвер за комуникацију са базама. Ту функцију омогућује Data Base Management System (скраћено DBMS), или систем за управљање базом података – софтверски систем који омогућује креирање, дефинисање, коришћење, одржавање и контролу приступа бази података. DBMS омогућује крајним корисницима или програмерима да деле податке, односно пружа могућност да се подаци једновремено користе од стране више апликација и лишава нас потребе да свака апликација има своју копију података.

Дефинисање базе података подразумева спецификацију типова и структура података које треба меморисати у базу, као и ограничења над подацима. Као средство за реализацију поменутих дефиниција користи се језик за дефинисање података, енгл. Data Definition Language (скраћено DDL). Дефиниције података се налазе у каталогу система и називају се мета подаци.

Манипулација базама података подразумева претраживање, брисање, додавање и измену података у бази. За остваривање ових манипулација користи се језик за манипулацију базом података, енгл. Data Manipulation Language (скраћено DML). Део DML-а који служи за претраживање базе података назива се упитни језик. Многи DBMS-и уграђују DML и DDL у неке језике опште намене (c, c++, Јаvа, Аdа, COBOL итд.).

Поменули смо у дефиницији шта је и чему служи DBMS. Овде таксативно набрајамо основне функције DBMS-а:

• Меморисање, претраживање и ажурирање података
• Одржавање системског каталога коме корисници могу приступати
• Подршка трансакцијама
• Сервиси контроле конкуренције
• Сервиси опоравка
• Сервиси ауторизације
• Подршка за комуникацију података
• Сервиси интегритета
• Сервиси независности података
• Услужни сервиси (Импортовање, експортовање, пуњење базе из фајлова; Мониторинг рада и коришћења базе; Статистика коришћења и мерење перформанси; Реорганизација индекса; Колекција отпадака и реалокација)

Ево и кратког историјата, односно одговора на питање: како су настале базе података?
На иницијативу Америчког председника Кенедија, у оквиру пројекта Apollo, 60-тих година 20. века, зачета је идеја о базама података . Резултат овог пројекта је Generalized Update Access Method (скраћено GUAM). Средином 60-тих година, IBM је прихватио GUAM идеју и развио Information Managment System (скраћено IMS) познат као хијеархијски DBMS.

Након тога General Electric развија Integrated data Store (скраћено IDS), тзв. мрежни DBMS. Едгар Франк Код из IBM Research Lab је 1970. предложио релациони модел. У прве комерцијалне релационе DBMS који су произведени спадају: пројекат System R (IBM) крајем 70-тих (SQL), DB2 и SQL/DS (IBM) 80-тих и Oracle, такође 80-тих. Данас постоји на хиљаде релационих DBMS-ова као што су: МS SQL Server, DB2, Oracle и MySQL.

Године 1976. Чен предлаже ER модел, а после три године Едгар Франк Код је предложио проширену верзију релационог модела који се убраја у семантичке моделе података. 90-тих година 20-тог века настаје потпуно нови DBMS: Објектно-оријентисани DBMS и Објектно-релациони DBMS. Нова генерација настала је 2000-те године и позната је као NoSQL базе података. Такве су DO (document-ориентед) базе и key-валуе складиштење података. Један тип структурне DO базе су XML базе засноване на атрибутима XML документа.

Модели базе података

1. Хијеархијски модел
2. Мрежни модел
3. ER (Entity Relationship) модел
4. Релациони модел
5. Објектно-оријентисани и објектно релациони модел
6. Документ модел
7. EAV (Entity-Atribute-Value) модел
8. Graf модел

Хијеархијски и мрежни модел, данас нису заступљени, тако да не заслужују велику пажњу. У овом тексту, посветићемо се релационом, објектно оријентисаном, document и graf моделу база података. ER модел такође није много популаран, међутим добра страна овог модела је што лепо објашњава појмове који су важни за схватање основа база података.

ER (Entity Relationship) модел

ER модел се користи за обликовање шеме базе података засноване на правилима релационог модела. Ово је само помоћна фаза моделовања из које касније можемо пресликати ER шему у релациону. Овај модел је такође битан за објашњење појма ентитета, атрибута и везе који су кључни елементи свих база података.

Ентитет (Entity) је скуп објеката из реалног света који имају нека заједничка својства. Својства ентитета се називају атрибутима и атрибути описују ентитет. Име ентитета и скуп атрибута који га описују одређује тип ентитета. Може постојати већи број примерака (појава) ентитета задатог типа (на пример КЊИГА је тип чији су примерци „Десет малих црнаца“, „Изгубљени симбол“, и тако даље).

Постоји више врста атрибута:

• Прости атрибут – атрибут је прост ако се даље не може декомпоновати,
• Сложени атрибут – атрибут је сложен ако је састављен од више елементарних (простих) атрибута.
• Изведени атрибут – то је атрибут чија се вредност добија применом неког алгоритма на вредности других атрибута,
• Једновредносни атрибут – атрибут који за један ентитет може имати само једну вредност,
• Вишевредносни атрибут – атрибут који за један ентитет може имати више вредности.

Скуп атрибута или атрибут, чије вредности једнозначно одређују примерак ентитета задатог типа представљају кандидате за кључ. Уколико један тип ентитета има више кандидата за кључ тада бирамо једног од њих и називамо га примарним кључем, а остали представљају алтернативне кључеве.

Не могу постојати два или више примерака одређеног типа ентитета са истим кључем. Уколико неки тип ентитета нема кључ, називамо га слаби тип ентитета. Између два или више типова ентитета могу се успостављати везе. Веза ентитета представља именовану бинарну релацију између неких примерака ентитета задатих типова. Постоји неколико врста веза:

• Један-према-један – код овог типа везе елемент првог скупа може бити повезан са највише једним елементом другог скупа. Истовремено и сваки елемент из другог скупа може бити повезан само са једним елементом из првог скупа.
• Више-према-један – код овог типа везе сваки елемент из првог скупа може бити повезан са највише једним елементом из другог скупа. Истовремено сваки елемент из другог скупа може бити повезан са више елемената првог скупа.
• Један-према-више – сваки елемент из првог скупа може бити повезан са више елемената из другог скупа и истовремено сваки елемент из другог скупа може бити повезан са само једним елементом из првог.
• Више-према-више – сваки елемент из првог скупа може бити повезан са више елемената из другог скупа и истовремено сваки елемент из другог скупа може бити повезан са више елемената из првог.

Свака веза може имати своје аттрибуте које не можемо приписати ни једном од типова ентитета.
ER шему можемо представити ER дијаграмом.

Једноставни пример ER дијаграма са слике говори нам да имамо два ентитета: VOZILO и VLASNIK. Ентитети у ER дијаграму се представљају као правоугаоници са уписаним именом. Ентитет VOZILO има четири атрибута. Атрибути се приказују у облику елипсе са уписаним називом.

Атрибут RegBroj је подвучен зато што представља примарни кључ. Између ентитета VOZILO и VLASNIK постији веза POSEDUJE коју представљамо као ромб са уписаним именом. Веза је типа N:1 што значи да сваки елеменат из скупа VOZILO поседује само један елемент из скупа VLASNIK, а истовремено и сваки елеменат из скупа VLASNIK може да поседује више елемената из скупа VOZILO. Атрибут Ime код ентитета VLASNIK је сложени атрибут чије су компоненте LicnoIme и Prezime.

Уколико би постојали вишевредносни атрибути у ER дијаграму, њих би смо означавали двоструком елипсом са уписаним именом, изведени атрибути се приказују елипсом која је исцртана испрекиданом линијом са уписаним именом. Напоменимо да поред основног постоји и ЕER (проширени модел објекти – везе) који омогућује детаљније дефинисање веза између објеката.

Релациони модел података

Релациони модел података је популаран модел који се заснива на математичком појму релација. База података се у овом моделу састоји од скупа табела, тзв.релација. Свака релација има своје име како би је разликовали од осталих релација у бази и састоји се од колона и врста. Врсте у релацијама означавају n-торку, а по правилу у табели не смемо имати две исте n-торке (у ER моделу то би били ентитети).

Свака колона у релацији представља вредност атрибута за одређени ентитет или везу и због тога је поистовећујемо са атрибутом. Сваки атрибут има свој тип података и своје јединствено име, како бисмо могли да га разликујемо у оквиру релације у којој се појављује. Оно што је веома битно за неку релацију је дефинисање кључа те релације. Кључ се дефинише као минимални скуп атрибута такав да важе правила:

1. кључ једнозначно одређује n-торку, што значи да немамо две или више n-торки са истим кључем,
2. уколико избацимо из кључа било који атрибут, тада се нарушава својсво број један

Постоје ситуације када имамо више кључева кандидата, у таквим ситуацијама се бира само један примарни кључ исто као код ER модела. Релације можемо описати шемама релације.
Пример: Листа гостију у неком хотелу

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

У горњој шеми Broj_licne_karte представлла примарни кључ релације. Њега представљамо тако што пуном линијом подвлачимо атрибут који представља примарни кјуч.

Код релационог модела базе података имамо исте врсте веза које се помињу у ER моделу (1:1, 1:N, N:1, N:М). Основне скуповне операције над релацијама су:

• Унија
• Пресек
• Разлика

  

• Селекција (селектовање торки релације по неком критеријуми или без критеријума)

  

• Пројекција (издвајање вредности појединих колона из релације)

  

• Природни спој (спајање торки различитих релација по основу истих вредности заједничких обележја)

  

Набројмо неке погодности релационих база података:

• Омогућавају спровођење сложених упита
• Задовољавају будуће потребе – имајући у виду да се подаци чувају у посебним табелама, увек постоји могућност да се убаце подаци који сада нису потребни, али ће бити у будућности
• Побољшана безбедност – подаци су распоређени по табелама, а одређене табеле се могу заштитити (бити поверљиве). Када се корисник улогује корисничким именом и лозинком систем може да му ограничи приступ одређеним табелама.
• Подаци су у табели запамћени само једном – нема вишестрког понављања истих података.

Као недостатке релационих база података могли би смо навести, пре свега скупо успостављање и одржавање система оваквих база, проблем обиља информација (сложеност информација изазива додатне проблеме), структурне границе (при пројектовању релационе базе података мора се одредити количина података која може стати у поље – уколико се појави податак који је дужи, може довести до губитка података) и изолованост база података (комплексни системи релационих база података могу довести до тзв. „острва информација“ где се информације не могу лако делити између више великих система).

Објектно-оријентисани и објектно-релациони модел података

Обекно-оријентисани модел података омогућује представљање података у форми објеката, у смислу ОО програмских језика. Примери оваквих модела података су: Versant db4o, Ontos, Matisse, GemStone и други. Карактеристике објектно оријентисаних база података су следеће:

• Подаци су представљени као објекти
• Декларативни језик за ad-hoc упите
• Веза са ОО програмским језицима
• Проширива хијерархија типова у смислу кориснички дефинисани типови, апстрактни типови, наслеђивање и вишеструко наслеђивање, overloading, overriding, late binding.
• Перзистентност објеката (могућност да неки објекти преживе крај извршења апликације)

Објекат је кориснички дефинисани, комплексни тип података који има своју структуру и стање (атрибути и својства), као и понашање (методе и операције). Објекти програмског језика се без икакве трансформације памте и чувају у бази, а можемо их описати са четири карактеристике:

1. Идентификатор – јединствен идентиификаторобјекта на нивоу система
2. Име – објекат може, али и не мора да има јединствено име у бази података
3. Животни век – одређује да ли је објекат привремен или перзистентан
4. Структура – креирање објеката коришћењем конструктора типа података

У ОО моделу базе података не постоји концепт примарног кључа, већ ООDBMS за сваки објекат памти јединствени и неприменљиви идентификатор – Object Identifier (скраћено OID) који се користи за референцирање објекта у оквиру базе података. Овај идентификатор није доступан апликацији, сто знаци да га не можемо сами дефинисати нити мењати. Сам систем додељује овај тзв. екстерни идентификатор.

Osoba представља супер класу, Student представља подкласу. Класа Student наслеђује све атрибуте и операције класе Osoba. Атрибут Ime у класи Osoba је сложени атрибут. Сваки атрибут је представљен у формату име_атрибута: тип_атрибута. Поред атрибута BrojIndexa у класи Student стоји ознака {PK} која означава примарни кључ. Операције су представљене у облику име_операције(параметри_операције): повратна_вредност_операције.

Недостаци у односу на RDMBS били би: проблематична еволуација шеме базе података, недостатак подршке за различите програмске језике, оптимизација упита, ограничења, тригери и друго.

Где користимо ОО модел базе података?

1. Када је потребна беспрекорна интеграција оперативних система, базе података, табела и сл.
2. Када се захтева дељење информација, производа, софтвера,
3. У апликацијама где је наслеђивање као особина ОО модела битно

Објектно релациони модел

Објектно релациона база података представља релациону базу података са елементима објектног модела као што су објекти, класе и наслеђивање. Овај модел је настао са циљем да се превазиђу разлике које постоје између рлационих модела и објектних модела база података. Примери оваквих модела базе података су PostgreSQL, MS SQL Server, Oracle, IBM DB2. Многи елементи OR модела базе података су уграђени у SQL. Основне каракеристике OR модела:

• Комплексни подаци – дефинишу се коришћењем User Data Type (скраћено UDT) механизма који је саставни део SQL спецификације
• Наслеђивање
• Типови садрже процедуралне елементе што значи да објекти садрже методе који мењају стање података

Разлике између објетних и релационих модела података се могу превазићи и О/R маперима, мада су данас популарније решење објектно-релациони модели података.

Документ оријентисани модели података

Документ оријентисана база података представља категорију NoSQL базе података. Ове базе података су организоване око апстрактног концепта – документ и представљају колекцију докумената. Јасно је изражена разлика у односу на релационе базе које су организоване око концепта релација.

Све информације се налазе у самом документу и не постоји повезивање табела. За разлику од релационе базе података у којој све врсте имају исте колоне, код document база података, сви документи не морају да имају исту структуру и нема потребе за стриктним дефинисањем шеме базе података.

Карактеристике document оријентисаних база су:

• Објекти се чувају као документи без објектно – релационог неслагања. Објектни модел се снима у document и памти у бази података
• Читав објектни модел може да се сними одједном тако да нема потребе за великим бројем атомичних CRUD операција.
• Подаци се најчешће чувају коришћењем отворених формата: XML, JSON, BSON (Binary JSON), YAML. Постоје и базе података које чувају и документа у бинарним форматима (PDF или Office документи).
• Документи су независни чиме се повећавају перформансе и смањују проблеми везани за конкуретан приступ подацима.
• Као што је поменуто, не постоји шема базе података тако да се подаци могу додавати без промене докумената у бази, овиме се повећава и флексибилност система.
• Данас постоје многа решења за чување информација о претходним верзијама која користе базе података за похрањивање информација.

Један документ би могао изгледати овако:

Познате су и document базе са Key/Value структуром код којих Value представља полу-структуирани документ чија је структура разумљива бази података. За приступ документима у бази података најчешће се користи вредност кључа. Кључ је најчешће стринг али може бити URI или неки облик путање. База је индексирана по вредности кључа како би приступ документима био оптималан.

Осим приступа документима коришћењем механизама кључа, већина документ база података нуди API или упитни језик за претраживање докумената. Циљ је пронаћи документе код којих одређено поље има наведену вредност. Често документ базе података обезбеђују http сервере који обрађују стандардне HTTP захтеве за подацима (PUT/GET/POST/DELETE).

Једна од основних карактеристика ових база података је евентуална конзистенција (Eventual consistency) која омогућује корисницима да мењају документе у бази података. Измене на документима нису видљиве у истом тренутку свим клијентима који им приступају, али свима постају видљиве у неком тренутку. Као последица овога повремено се јавља неконзистентност у подацима. Познате документ оријентисане базе података су CouchDB, RavenDB и MongoDB.

Када користити овај модел података?

1. када је потребно складиштити динамичке податке, у системима као што су Content Management System (скраћено CMS) и Customer Relationship Management (скраћено CMR) ентитети, које крајњи корисник може да мења по потреби,
2. код Веб података (Web Related Data), као што су корисничке сесије, логови, shoping cart и други подаци који се одржавају за потребе Веб апликација. Документ складиштења омогућују да се подацима приступа као целини једним захтевом ка удаљеном серверу.
3. код динамичких ентитета, као што су кориснички прилагодљиви ентитети, ентитети са великим бројем изборних области, итд.
4. код перзистентног модела погледа (Persistent View Models) – уместо поновног отварања и приказа модела од нуле на сваки захтев, може се приказ сачувати у свом коначном облику документа података. Ово доводи до смањења рачунања, удаљених позива и побољшање укупних перформанси.
5. код складиштења великих количина података.

Проблеми могу настати када се захтева трансакциона обрада (нема подршке за ACID трансакције) и када је неопходно користити велики број спојева.

Graf базе података

Graf базе података такође спадају у NoSQL базе података. Користе структуру података типа Граф (чворови, потези и својства) за репрезентацију и складиштење података. Код graf базе података сваки елемент може да садржи директан показивач ка другим елементима без потребе за постојање индексних структура. Најочигледнији пример graf база података су везе између људи на социјалним мрежама.

Елементи graf базе података су чворови, потези и својства. Чворови се користе за репрезентацију ентитета. Сваки чвор у бази може да има неограничен број својстава. Својства су подаци који описују чворове и можемо их изједначити са атрибутима. Потези су релације које повезују чворове међусобно или чворове са својствима и могу имати сопствена својства. Концепт потеза је сличан концепту објекта у ОО програмирању.

Најједноставнија graf база, податак садржи само један чвор. Поред генералних graf база података које могу да складиште било који граф, постоје и специјализоване graf базе података као што су „triplestore“ (складиштење података у облику субјекат-предикат-објекат, RDF) и мрежне базе података које се заснивају на коришћењу мрежног модела.

Зашто graf базе података?

• Због велике количине података које не захтевају скупе операције споја
• Директно мапирање из graf базе података на ОО модел
• Решење за асоцијативне скупове података
• Погодне су за развој ad-hoc апликације или апликације које брзо еваулирају због своје флексибилне шеме
• Погодне за операције типа: обилазак графа, провере да ли постоји пут између два чвора, одређивање суседа, тражење најкраћег пута између два чвора и сл.

Разлике између graf базе података и релационе базе:

• Релационе базе података су брже код упита при огромним количинама података јер не морају испитати сваки запис током упита
• Релационе базе података користе мање простора, јер не морају да памте све везе које памте graf базе
• Релационе базе су оптимизоване за агрегацију података, а graf базе за везе између података
• Graf базе података су погодне за нередовне, сложене структуре, док су релационе погодне за редовне, релативно једноставно структуре које се и већином захтевају у реалном свету, па због тога релационе базе и преовладавају.

Код Кеy/Value складиштења података подаци су организовани у структури стабла, а код graf базе података подаци могу бити организовани у различите комплексне структуре. Још једна битна разлика је што су Кеy/Value складиштења података оптимизована за једноставне „lookup“ претраге, а graf базе података за обиласке повезаних података. Најпознатије graf базе података су Neo4j, AllegroGraph, Sones, Virtuoso, HyergraphDB и др.

Закључак

У савременом свету, употреба база података је веома раширена. Корисницима апликација или сервиса, наравно није битно који модел базе података се користи, али за дизајнера апликације бирање модела базе података може да представља проблем. Као што смо видели из овог кратког преледа, постоје бројни модели са различитим карактеристикама. Пре него се започне дизајнирање конкретне базе података, најбоље је направити анализу онога што је на располагању и стећи увид колико понуђена решења задовољавају пројектоване потребе. Осим наведених модела базе података, постоје и други модели који се ређе користе, неки који се више не користе и они који су у фази развоја.

Навешћемо асоцијативни модел, семантички модел, XML базе података, а у моделе који се ретко или уопште не користе убројаћемо мрежни и хијеархирски модел.
ER модел се углавном користи само као помагало при креирању релационе базе података. Најчешће коришћени модели данас су релациони, објектно оријентисани и документ модел базе података. Употреба graf модела базе података тек почиње и добија на популарности.

Његова употреба се огледа у социјалним мрежама које свакодневно окупирају пажњу великог броја људи. Оно што је неспорно јесте да базе података кроз бројне апликације и системе постају битан део стварности и света који нас окружује и самим тиме захтевају стално унапређење и побољшање карактеристика.

Текст је преузет са угашеног блога ИТ модул и оригинална ауторка овог текста је Сања Димковић. Компјутераш ИТ блог ће објављивати текстове са тог блога како ризница знања са те локације не би отишла у заборав.