Professional Documents
Culture Documents
Пoстoje рaзличитe врстe бaзa пoдaтaкa, зaвиснo oд тoгa, нa кojи нaчин су пoдaци интeрнo
oргaнизoвaни. Taкo сe рaзликуjу:
хиjeрaрхиjскe,
мрeжнe,
EР (Entity Relationship) модел
рeлaциoнaлнe,
oбjeктнo-oриjeнтисaнe,
oбjeктнo-рeлaциoнe,
прилaгoђeнe зa ВЕБ,
Документ модел (XML)
EAV (Entity-Atribute-Value) модел
Graf модел
мултимeдиjaлнe бaзe пoдaтaкa.
Свaки oд oвих мoдeлa имa свoje прeднoсти и нeдoстaткe.
Хијеархијски и мрежни модел, данас нису заступљени, тако да не заслужују велику пажњу. У овом
тексту, посветићемо се релационом, објектно оријентисаном, document и graf моделу база података. ER
модел такође није много популаран, међутим добра страна овог модела је што лепо објашњава појмове
који су важни за схватање основа база података.
Ентитет (Entity) је скуп објеката из реалног света који имају нека заједничка својства. Својства ентитета
се називају атрибутима и атрибути описују ентитет. Име ентитета и скуп атрибута који га описују
одређује тип ентитета. Може постојати већи број примерака (појава) ентитета задатог типа (на пример
КЊИГА је тип чији су примерци „Десет малих црнаца“, „Изгубљени симбол“, и тако даље).
Скуп атрибута или атрибут, чије вредности једнозначно одређују примерак ентитета задатог типа
представљају кандидате за кључ. Уколико један тип ентитета има више кандидата за кључ тада бирамо
једног од њих и називамо га примарним кључем, а остали представљају алтернативне кључеве.
Не могу постојати два или више примерака одређеног типа ентитета са истим кључем. Уколико неки
тип ентитета нема кључ, називамо га слаби тип ентитета. Између два или више типова ентитета могу се
успостављати везе. Веза ентитета представља именовану бинарну релацију између неких примерака
ентитета задатих типова. Постоји неколико врста веза:
Један-према-један – код овог типа везе елемент првог скупа може бити повезан са највише једним
елементом другог скупа. Истовремено и сваки елемент из другог скупа може бити повезан само са
једним елементом из првог скупа.
Више-према-један – код овог типа везе сваки елемент из првог скупа може бити повезан са највише
једним елементом из другог скупа. Истовремено сваки елемент из другог скупа може бити повезан са
више елемената првог скупа.
Један-према-више – сваки елемент из првог скупа може бити повезан са више елемената из другог скупа
и истовремено сваки елемент из другог скупа може бити повезан са само једним елементом из првог.
Више-према-више – сваки елемент из првог скупа може бити повезан са више елемената из другог скупа
и истовремено сваки елемент из другог скупа може бити повезан са више елемената из првог.
Свака веза може имати своје аттрибуте које не можемо приписати ни једном од типова ентитета.
ER шему можемо представити ER дијаграмом.
Пример ER дијаграма
Једноставни пример ER дијаграма са слике говори нам да имамо два ентитета: VOZILO и VLASNIK.
Ентитети у ER дијаграму се представљају као правоугаоници са уписаним именом. Ентитет VOZILO има
четири атрибута. Атрибути се приказују у облику елипсе са уписаним називом.
Атрибут RegBroj је подвучен зато што представља примарни кључ. Између ентитета VOZILO и
VLASNIK постији веза POSEDUJE коју представљамо као ромб са уписаним именом. Веза је типа N:1
што значи да сваки елеменат из скупа VOZILO поседује само један елемент из скупа VLASNIK, а
истовремено и сваки елеменат из скупа VLASNIK може да поседује више елемената из скупа VOZILO.
Атрибут Ime код ентитета VLASNIK је сложени атрибут чије су компоненте LicnoIme и Prezime.
Свака колона у релацији представља вредност атрибута за одређени ентитет или везу и због тога је
поистовећујемо са атрибутом. Сваки атрибут има свој тип података и своје јединствено име, како бисмо
могли да га разликујемо у оквиру релације у којој се појављује. Оно што је веома битно за неку релацију
је дефинисање кључа те релације. Кључ се дефинише као минимални скуп атрибута такав да важе
правила:
1. кључ једнозначно одређује n-торку, што значи да немамо две или више n-торки са истим кључем,
2. уколико избацимо из кључа било који атрибут, тада се нарушава својсво број један
Постоје ситуације када имамо више кључева кандидата, у таквим ситуацијама се бира само један
примарни кључ исто као код ER модела. Релације можемо описати шемама релације.
Пример: Листа гостију у неком хотелу
У горњој шеми Broj_licne_karte представлла примарни кључ релације. Њега представљамо тако што
пуном линијом подвлачимо атрибут који представља примарни кључ.
Код релационог модела базе података имамо исте врсте веза које се помињу у ER моделу (1:1, 1:N, N:1,
N:М). Основне скуповне операције над релацијама су:
Унија
Пресек
Разлика
Пример резултата уније, пресека и разлике између релација r и s
Пример селекције са селектовањем свих торки из релације r са условом да је плата већа од 4000 и
да раде на пројекту са шифром 11
Пројекција (издвајање вредности појединих колона из релације)
Пример пројекције са издвајањем свих пилота (P) и типова авиона (А) на којима лете
Природни спој (спајање торки различитих релација по основу истих вредности заједничких обележја)
Објекат је кориснички дефинисани, комплексни тип података који има своју структуру и стање
(атрибути и својства), као и понашање (методе и операције). Објекти програмског језика се без икакве
трансформације памте и чувају у бази, а можемо их описати са четири карактеристике:
Део UML-а (Unified Modeling Language) који приказује класе Student и Osoba
Osoba представља супер класу, Student представља подкласу. Класа Student наслеђује све атрибуте и
операције класе Osoba. Атрибут Ime у класи Osoba је сложени атрибут. Сваки атрибут је представљен у
формату име_атрибута: тип_атрибута. Поред атрибута BrojIndexa у класи Student стоји ознака {PK} која
означава примарни кључ. Операције су представљене у облику име_операције(параметри_операције):
повратна_вредност_операције.
Изглед класног дијаграма са претходне слике у ODL-у (енгл. Object Definition Language)
Недостаци у односу на RDMBS били би: проблематична еволуација шеме базе података, недостатак
подршке за различите програмске језике, оптимизација упита, ограничења, тригери и друго.
1. Када је потребна беспрекорна интеграција оперативних система, базе података, табела и сл.
2. Када се захтева дељење информација, производа, софтвера,
3. У апликацијама где је наслеђивање као особина ОО модела битно
Објектно релациона база података представља релациону базу података са елементима објектног модела
као што су објекти, класе и наслеђивање. Овај модел је настао са циљем да се превазиђу разлике које
постоје између рлационих модела и објектних модела база података. Примери оваквих модела базе
података су PostgreSQL, MS SQL Server, Oracle, IBM DB2. Многи елементи OR модела базе података су
уграђени у SQL. Основне каракеристике OR модела:
Комплексни подаци – дефинишу се коришћењем User Data Type (скраћено UDT) механизма који је
саставни део SQL спецификације
Наслеђивање
Типови садрже процедуралне елементе што значи да објекти садрже методе који мењају стање података
Разлике између објетних и релационих модела података се могу превазићи и О/R маперима, мада су
данас популарније решење објектно-релациони модели података.
Документ оријентисани модели података
Документ оријентисана база података представља категорију NoSQL базе података. Ове базе података
су организоване око апстрактног концепта – документ и представљају колекцију докумената. Јасно је
изражена разлика у односу на релационе базе које су организоване око концепта релација.
Све информације се налазе у самом документу и не постоји повезивање табела. За разлику од релационе
базе података у којој све врсте имају исте колоне, код document база података, сви документи не морају
да имају исту структуру и нема потребе за стриктним дефинисањем шеме базе података.
Објекти се чувају као документи без објектно – релационог неслагања. Објектни модел се снима у
document и памти у бази података
Читав објектни модел може да се сними одједном тако да нема потребе за великим бројем атомичних
CRUD операција.
Подаци се најчешће чувају коришћењем отворених формата: XML, JSON, BSON (Binary JSON), YAML.
Постоје и базе података које чувају и документа у бинарним форматима (PDF или Office документи).
Документи су независни чиме се повећавају перформансе и смањују проблеми везани за конкуретан
приступ подацима.
Као што је поменуто, не постоји шема базе података тако да се подаци могу додавати без промене
докумената у бази, овиме се повећава и флексибилност система.
Данас постоје многа решења за чување информација о претходним верзијама која користе базе података
за похрањивање информација.
Познате су и document базе са Key/Value структуром код којих Value представља полу-структуирани
документ чија је структура разумљива бази података. За приступ документима у бази података најчешће
се користи вредност кључа. Кључ је најчешће стринг али може бити URI или неки облик путање. База је
индексирана по вредности кључа како би приступ документима био оптималан.
Пример key/value структуре
Осим приступа документима коришћењем механизама кључа, већина документ база података нуди API
или упитни језик за претраживање докумената. Циљ је пронаћи документе код којих одређено поље има
наведену вредност. Често документ базе података обезбеђују http сервере који обрађују стандардне
HTTP захтеве за подацима (PUT/GET/POST/DELETE).
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 базе за везе између података
Graf базе података су погодне за нередовне, сложене структуре, док су релационе погодне за редовне,
релативно једноставно структуре које се и већином захтевају у реалном свету, па због тога релационе
базе и преовладавају.
Код Кеy/Value складиштења података подаци су организовани у структури стабла, а код graf базе
података подаци могу бити организовани у различите комплексне структуре. Још једна битна разлика је
што су Кеy/Value складиштења података оптимизована за једноставне „lookup“ претраге, а graf базе
података за обиласке повезаних података. Најпознатије graf базе података су Neo4j, AllegroGraph, Sones,
Virtuoso, HyergraphDB и др.
Закључак
У савременом свету, употреба база података је веома раширена. Корисницима апликација или сервиса,
наравно није битно који модел базе података се користи, али за дизајнера апликације бирање модела
базе података може да представља проблем. Као што смо видели из овог кратког преледа, постоје
бројни модели са различитим карактеристикама. Пре него се започне дизајнирање конкретне базе
података, најбоље је направити анализу онога што је на располагању и стећи увид колико понуђена
решења задовољавају пројектоване потребе. Осим наведених модела базе података, постоје и други
модели који се ређе користе, неки који се више не користе и они који су у фази развоја.
Навешћемо асоцијативни модел, семантички модел, XML базе података, а у моделе који се ретко или
уопште не користе убројаћемо мрежни и хијеархирски модел.
ER модел се углавном користи само као помагало при креирању релационе базе података. Најчешће
коришћени модели данас су релациони, објектно оријентисани и документ модел базе података.
Употреба graf модела базе података тек почиње и добија на популарности.
Његова употреба се огледа у социјалним мрежама које свакодневно окупирају пажњу великог броја
људи. Оно што је неспорно јесте да базе података кроз бројне апликације и системе постају битан део
стварности и света који нас окружује и самим тиме захтевају стално унапређење и побољшање
карактеристика.