ВИСОКА ЗДРАВСТВЕНА ШКОЛА СТРУКОВНИХ СТУДИЈА

"МЕДИКА"

Предмет: Информатика

Семинарски рад

БАЗЕ ПОДАТАКА

Ментор: Студент:
Доц. др Зоран Катанић Душанка Дукић

Београд, јануар, 2020.

 САДРЖАЈ

1. Увод ............................................................................................................................................. 2
2. Безбедност базе података .......................................................................................................... 3
3. Заштита система од неовлашћеног приступа .......................................................................... 3
3.1. Модел сигурности базе података ....................................................................................... 4
4. Проблем услед пада система ..................................................................................................... 6
5. Опоравак система ..................................................................................................................... 10
5.1 Опоравак од пада трансакције .......................................................................................... 12
5.2. Креирање резервних копија ............................................................................................. 14
6. Закључак.................................................................................................................................... 16
7. Литература ................................................................................................................................ 17

1
 1. Увод

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

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

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

Дефинисање базе података подразумева спецификацију типова и структура података које

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

Манипулација базама података подразумева претраживање, брисање, додавање и измену

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

1
Благојевић, В., Релационе базе података, Клуб НТ, Београд, 2003., стр. 17.

2
 2. Безбедност базе података

Заштиту података похрањених у бази, омогућава енкрипција односно шифровање података

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

Подједнако важна мера заштите је хешовање, што подразумева рачунање нумеричке

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

3. Заштита система од неовлашћеног приступа

Под сигурношћу базе података подразумева се заштита базе од неовлашћеног приступа.

Постоји мноштво различитих разлога због којих је неопходно заштитити базу података:
 Законски прописи, друштвени односи и етичке норме налажу да се спречи
неовлашћено коришћење многих података;
 Многи подаци у државној управи, предузећима и другим институцијама морају бити
заштићени;

2
Ђорђевић, С., Стојменов, Л., Структуре и базе података, Практикум за вежбе, Електронски факултет Ниш,
2004., стр. 82.

3
  У самом СУБП, неки подаци, на пример подаци у каталогу, доступни су само
администратору базе и неким специфичним апликацијама. Подаци о идентификацији
корисника и њиховим лозинкама, такође морају бити заштићени.3

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

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

3.1. Модел сигурности базе података

Основни модел сигурности базе података се може дефинисати преко скупа ауторизација
односно скупа четворки:

Ауторизација: <корисник, објекат, операција, услов>

Ауторизација исказује којим објектима базе посматрани корисник може да приступи, које
операције над њим може да изврши и под којим условима. Поред основног, постоје и други
модели сигурности. СУБП треба да омогући да се модел сигурности ускладишти и да се
операције над базом података обављају на основу дефинисаног модела. Део СУБП који
обавља овај задатак назива се подсистем сигурности (security subsystem) или подсистем
ауторизације (autorization subsystem).4

Дискрециони механизам сигурности (Discretionary mechanism) подржава основни модел у

коме се појединим корисницима дају специфична права приступа (привилегије) за
различите објекте.

3
Базе података – дефиниција, врсте, модели, https://kompjuteras.com/baze-podataka/ (приступ сајту:
11.12.2019.)
4
Риордан, Р., Пројектовање базе података, Микро књига, Београд, 2006., стр. 238.

4
Механизам овлашћења (mandatory mechanism) подржава специфичан модел сигурности у
коме је, с једне стране сваком објекту базе података додељен неки степен тајности (на
пример, државна тајна, строго поверијиво, поверљиво, јавно), а са друге корисницима дато
право да приступе објектима дефинисаног степена тајности. Подразумева се хијерархија
овлашћења, корисник са овлашћењем вишег степена, може да приступи и свим објектима
нижег степена тајности.

Статистичке базе података се, са тачке гледишта сигурности, посебно анализирају.

Статистичке базе података дају статистичке, збирне информације о феноменима за групу
ентитета дефинисане по неком критеријуму (популацију). На пример, нека статистика
становништва даје неке збирне податке о популацијама становништва дефинисане на основу
старости, прихода, нивоа образовања и слично. Механизам сигурности статистичких база
мора да онемогући да се из збирних података извуку закључци о вредностима појединачних
података за неки ентитет. То се најчешће постиже спречавањем добијања статистичких
информација за популацију мању од неког унапред задатог броја и/или спречавањем
извршења секвенце упита над истом популацијом. Проблем сигурности статистичких база
података добијаће на значају са већим коришћењем стоваришта података (data warehouse).5

Енкрипција података. Да би се осигурали посебно осетљиви подаци у бази података

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

Регистар и ревизија корисникових акција (Audit Trail). Неопходно је претпоставити да

системи сигурности базе података није савршен. То значи да је могуће да он понекад буде
разбијен. Због тога је неопходно водити посебан лог који се назива Регистар корисникових
акција и повремено вршити преглед (ревизију) овог регистра. Запис у регистру садржи: (1)
изворни текст корисниковог захтева, (2) идентификатор терминала са којег је захтев
постављен, (3) идентификатор корисника који је поставио захтев, (4) датум и време, (5)
релације, н-торке и атрибути којима је приступљено, (6) нову и стару вредност.

5
Вељовић, А., Његуш, А., Основе релационих и аналитичких база података, Мегатренд, Београд, 2004., стр.
179.

5
Коришћењем безбедносних функција система, администратор базе података може подесити
окружење тако да само одређени корисници или одређене апликације могу извршавати
одређене операције над одређеним подацима у бази. Свакој корисничкој функцији у фирми
треба доделити одређени безбедносни ниво приступа бази података. На пример, програмери
главне базе података, батцх послови и програми могу вршити измене у главној бази
података. Могу се извршавати различите провере за сваки тип приступа сваком типу
информација, а различитим корисницима се могу доделити различита права приступа
различитим објектима базе података.6

Изазов за ефикасно управљање безбедношћу нараста јер постављање и управљање

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

4. Проблем услед пада система

Данашњи пословни процеси захтевају већу пропусност података и непрестану

расположивост, у исто време захтевајући повећање обима података и обраде. Сада многе
фирме управљају терабајтима података на једном серверу базе података. Самим тим се
захтева да више података буде константно расположиво и да се њихова обрада заврши у што
краћем времену. Фирме се ослањају на податке да би успеле да извршавају пословне
процесе. Добар план креирања резервних копија и опоравка података се може схватити као
добра полиса осигурања система.7

6
Арсовски, З., Увод у информационе системе, Економски факултет, Крагујевац, 2003., стр. 84.
7
Mulins, K., Администрација база података, Компјутер библиотека, Чачак, 2003., стр. 146.

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

Прекиди рада базе података који могу захтевати опоравак са резервних копија могу се
поделити у три категорије:
 Прекиди рада инстанце су резултат интерне грешке у раду система, оперативног
система или другог софтвера који користи СУБП. У неким случајевима овакви
прекиди рада изазивају оштећење података и захтевају њихов опоравак, али обично
се то не дешава. Довољно ће бити рестартовање система да би се успоставило
нормално функционисање.
 Грешке у раду апликација (или трансакција) се јављају када се програми и скриптови
извршавају у погрешно време, када се стартују са погрешним улазним подацима, или
погрешним редоследом стартовања. Овакве грешке обично изазивају оштећење
података и потребу њиховог опоравка са резервних копија. Што пре се овакве грешке
открију и исправе, мањи ће бити степен оштећења података.
 Грешке на медијумима за смештање података такође узрокују њихово оштећење. Ово
се односи на грешке на дисковима, систему датотека оперативног система, оштећењу
магнетне траке. Иако се ретко дешава, квар на меморијским чиповима такође може
оштетити податке у бази. Након грешке на медијумима, база података неће читати
исправне податке, читаће неисправне или ће бити нарушен њихов интегритет.
Прекид рада услед ове грешке се често може избеци постављањем дискова модерније
технологије, као што су RAID дискови.8

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

8
Риордан, Р., Пројектовање базе података, Микро књига, Београд, 2006., стр. 116.

7
идентификовати читањем системског лога уназад, као трансакције за које постоји BEGIN
TRANSACTION слог али не постоји COMMIT слог. Да би се смањила количина посла
везана за поништавање трансакција, уводе се, у правилним интервалима, обично после
одређеног броја уписаних слогова у лог датотеку, тачке памћења. У моменту који одређује
тачку памћења, физички се уписују подаци и информације из лог бафера и бафера података
(који су у унутрашњој меморији) у лог датотеку и у базу података, редом, и уписује се слог
тачке памћења у лог датотеку. Овај слог садржи информацију о свим активним
трансакцијама у моменту тачке памћења, адресе последњих слогова тих трансакција у лог
датотеци, а може садржати и низ других информација о стању базе података у том тренутку.
Адреса слога тачке памћења уписује се у датотеку поновног стартовања (енгл. restart file).9

Физички упис у тачки памћења значи да ће се садржај бафера преписати на спољни медиј
без обзира да ли су бафери пуни или не. То даље значи да се физички упис свих ажурираних
података успешно комплетиране трансакције може гарантовати тек у тачки памћења која
следи за успешним комплетирањем трансакције. Комплетирање трансакције (упис
COMMIT слога у лог датотеку) и дефинитивни упис свих ажурирања те трансакције у базу
– су две одвојене радње, за које се не сме догодити да се једна изврши а друга не. Механизам
који то обезбеђује је протокол унапредног уписивања у лог (енгл. WAL – Write Ahead Log).
Према овом протоколу, при извршењу операције COMMIT прво се одговарајући слог
физички уписује у лог датотеку, па се затим подаци уписују из бафера података у базу. Ако
дође до пада система после уписа COMMIT слога у лог датотеку а пре него што је садржај
бафера података преписан у базу, тај се садржај може рестаурисати из системског лога
REDO логиком. При поновном стартовању система, после пада система, могуће је према
садржају лог датотеке идентификовати неуспеле трансакције – кандидате за поништавање,
и успеле трансакције – кандидате за поновно извршавање.

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

9
Риордан, Р., Пројектовање базе података, Микро књига, Београд, 2006., стр. 118.

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

Могуће је елиминисати физичко уписивање бафера података у базу података у тачки

памћења, а у фази опоравка од пада система поништавати само оне радње неуспелих
трансакција чији су ефекти уписани у базу, односно поново извршавати само оне радње
успелих трансакција чији ефекти нису уписани у базу. У том циљу уводи се, у сваки слог
системског лога, у време његовог уписа у лог, јединствена ознака – серијски број у логу
(енгл. LSN – Log Sequence Number). Серијски бројеви су у растућем поретку. Осим тога, кад
год се ажурирана страница физички уписује у базу података, у страницу се уписује и ЛСН
слога системског лога који одговара том ажурирању (слика 1).

Слика 1. Опоравак од пада система коришћењем серијских бројева 11

У системском логу може бити више слогова који одговарају ажурирању исте странице базе
података. Ако је серијски број уписан у страницу П већи или једнак серијском броју слога

10
Риордан, Р., Пројектовање базе података, Микро књига, Београд, 2006., стр. 118.
11
исто, стр. 120.

9
лога, ефекат ажурирања коме одговара тај слог физички је уписан у базу; ако је мањи, ефекат
није уписан.

Да би се слог из базе података ажурирао, потребно је прочитати (из базе) страницу на којој
се слог налази. После ажурирања слога, страница је (у баферу података) спремна за упис у
базу, при чему и даље носи серијски број свог претходног уписа у базу. Сада се у процедуру
регистровања тачке памћења, осим што се елиминише физички упис бафера података у базу,
може додати упис, у слог тачке памћења, вредности ЛСН м најстарије странице бафера
података, тј. најмањег ЛСН страница из бафера података, које су ажуриране али још нису
уписане у базу. Слог системског лога са серијским бројем м одговара тачки у системском
логу од које треба, уместо од тачке памћења, при опоравку од пада система поново
извршавати успеле трансакције. Како тачка м претходи тачки памћења, може се десити да
нека трансакција која је успешно комплетирана пре тачке памћења, упадне у скуп активних
(успелих) трансакција. На такву трансакцију примениће се процедура опоравка, мада се то
не би догодило у претходној варијанти опоравка; то је цена смањеног броја поништавања,
поновног извршавања и физичког уписа које обезбеђује овај поступак.

5. Опоравак система

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

Како је трансакција логичка јединица посла, њене радње морају или све успешно извршене
или ниједна, па је у случају немогућности успешног комплетирања неопходно поништити

12
Вељовић, А., Његуш, А., Основе релационих и аналитичких база података, Мегатренд, Београд, 2004., стр.
95.

10
ефекте парцијално извршених трансакција. Са друге стране, може се догодити да у тренутку
пада система неки ефекти успешно комплетираних трансакција још нису уписани у базу
(нпр. ажурирани слогови су још у унутрашњој меморији – у баферу података чији се садржај
при паду система губи); зато може постојати потреба за поновним (делимичним) извршењем
неких претходно успешно комплетираних трансакција. То поништавање односно поновно
извршавање у циљу успостављања конзистентног стања базе представља системску
активност опоравка од пада трансакције или система. Трансакција је према томе и логичка
јединица опоравка. У случају пада медија, опоравак укључује пре свега преписивање
архивиране копије базе (нпр. са траке) на исправан медиј, а затим, евентуално, поновно
извршење трансакција комплетираних после последњег архивирања а пре пада медија.

Овако конципиран опоравак нужно се заснива на постојању поновљених (дуплираних)

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

Компонента СУБП одговорна за опоравак базе података од пада трансакције, система или
медија је управљач опоравка. Његова активност се глобално састоји од следећих радњи:
 периодично преписује (енгл. dump) целу базу података на медиј за архивирање;
 при свакој промени базе података, уписује слог промене у лог датотеку, са типом
промене и са новом и старом вредношћу при ажурирању, тј. са новом вредношћу при
уношењу у базу и старом вредношћу при брисању из базе;
 у случају пада трансакције или система, стање базе података може бити
неконзистентно; управљач опоравка користи информације из лог датотеке да
поништи дејства парцијално извршених трансакција односно да поново изврши неке
комплетиране трансакције; архивирана копија базе података се не користи;
 у случају пада медија (нпр. диска на коме је база података), најсвежија архивирана
копија базе података се преписује на исправни медиј (диск), а затим се користе

13
Mulins, K., Администрација база података, Компјутер библиотека, Чачак, 2003., стр. 142.

11
 информације из лог датотеке за поновно извршење трансакција комплетираних после
последњег архивирања а пре пада медија.

Да би се омогућило управљачу опоравка да поништи односно да поново изврши

трансакције, потребно је обезбедити процедуре којима се поништавају односно поново
извршавају појединачне радње тих трансакција којима се мења база података. База података
мења се операцијама ажурирања (у ужем смислу), уношења или брисања података, па поред
процедура за извршење тих операција, СУБП мора бити снабдевен и одговарајућим
процедурама за поништавање односно поновно извршење тих операција, на основу старих
односно нових вредности запамћених у системском логу. Другим речима, СУБП поседује,
осим тзв. DO-логике (уради), и тзв. UNDO (поништи) и REDO (поново уради) логику.

Пад система или медија може се догодити и у фази опоравка од претходног пада. Зато може
доћи до поновног поништавања већ поништених радњи, односно до поновног извршавања
већ извршених радњи. Ова могућност захтева да UNDO и REDO логика имају својство
идемпотентности, тј. да је: UNDO(UNDO(x)) ≡ UNDO(x) и REDO(REDO(x)) ≡ REDO(x) за
сваку радњу x.14

У лог датотеци показивачима су повезани слогови који се односе на једну трансакцију. То

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

5.1 Опоравак од пада трансакције

14
Риордан, Р., Пројектовање базе података, Микро књига, Београд, 2006., стр. 174.

12
Један апликативни програм моˇзе се састојати од ве´цег броја трансакција. Извршење једне
трансакције може да се заврши планирано или непланирано. До планираног завршетка
долази извршењем COMMIT операције којом се успешно комплетира трансакција, или
експлицитне ROLLBACK операције, која се извршава када дође до грешке за коју постоји
програмска провера (тада се радње трансакције поништавају а програм наставља са радом
извршењем следеће трансакције). Непланирани завршетак извршења трансакције догађа се
када дође до грешке за коју не постоји програмска провера; тада се извршава имплицитна
(системска) ROLLBACK операција, радње трансакције се поништавају а програм прекида
са радом.15

Извршавањем операције COMMIT , ефекти свих ажурирања трансакције постају трајни, тј.
више се не могу поништити процедуром опоравка. У лог датотеку се уписује одговарајући
слог о комплетирању трансакције (COMMIT слог), а сви катанци које је трансакција држала
над објектима – ослобађају се. Извршење COMMIT операције не подразумева физички упис
свих ажурираних података у базу (неки од њих могу бити у баферу података, при чему се,
ефикасности ради, са физичким уписом у базу чека док се бафери не напуне). Чињеница да
ефекти ажурирања постају трајни значи да се може гарантовати да ће се упис у базу
догодити у неком наредном тренутку; у случају пада система, на пример, после COMMIT
операције а пре физичког уписа података из бафера у базу, упис се гарантује РЕДО-
логиком.16

Пад трансакције настаје када трансакција не заврши своје извршење планирано. Тада систем
извршава имплицитну – принудну ROLLBACK операцију, тј. спроводи активност опоравка
од пада трансакције. Појединачне радње ажурирања у оквиру једне трансакције, као и
операција почетка трансакције (експлицитна или имплицитна BEGIN TRANSACTION
операција), извршавају се на начин који омогућује опоравак базе у случају пада трансакције.
Опоравак података у бази и враћање базе у конзистентно стање омогућује се уписом свих
информација о овим радњама и операцијама у системски лог. При извршавању операција
ажурирања (у ужем смислу), осим што се ажурира база, у лог се бележе вредности сваког

15
Благојевић, В., Релационе базе података, Клуб НТ, Београд, 2003., стр. 152.
16
исто, стр. 153.

13
ажурираног објекта пре и после ажурирања (уз остале информације о том ажурирању).
Извршавањем операције BEGIN TRANSACTION (било да је експлицитна или имплицитна)
у лог датотеку се уписује слог почетка трансакције.

Операција ROLLBACK, било експлицитна или имплицитна, састоји се од поништавања

учињених промена над базом. Извршава се читањем уназад свих слогова из лог датотеке
који припадају тој трансакцији, до BEGIN TRANSACTION слога. За сваки слог, промена се
поништава применом одговарајуће UNDO-операције. Активност опоравка од пада
трансакције не укључује REDO логику.

5.2. Креирање резервних копија

Основна компонента плана креирања резервних копија и опоравка података је процес

креирања копије. Када се појави грешка у раду која наруши интегритет података, могу се
искористити копије да би се подаци опоравили.

Осигуравање базе података значи константно креирање копија података, обично у виду
пресликаних података, које се креирају наредбом COPY. Име ове наредбе варира од система
до система. Уобичајна имена ове наредбе су Б BACKUP, COPY, DUMP или EXPORT. Неки
СУБП се ослањају на наредбе оперативног система за креирање резервних копија. Међутим,
иако СУБП подржава наредбе копирања, администратор базе података се може одлучити да
тај процес изводи и ван СУБП-а.17

Свеже и ажурне копије података представљају основу могућности опоравка података.

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

17
Ђорђевић, С., Стојменов, Л., Структуре и базе података, Практикум за вежбе, Електронски факултет Ниш,
2004., стр. 258.

14
време потребно за опоравак тог објекта. Време трајања опоравка је одређено многим
факторима, као што су:
 број записа из дневника који се мора обрадити да би се подаци опоравили,
 да ли је дневник базе података компримован,
 време потребно да оператер монтира или скине одговарајуће траке,
 време потребно да се прочита део дневника базе који је потребан за опоравак,
 време потребно за поновну обраду измењених страница података.18

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

18
Ђорђевић, С., Стојменов, Л., Структуре и базе података, Практикум за вежбе, Електронски факултет Ниш,
2004., стр. 260.

15
 6. Закључак

Развој модерних информационих система у великој мери се базира на манипулацији

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

Апликације које раде с базама података постоје преко 30 година и многе су направљене
применом мрежних технологија познатих давно пре него што је Wеб уопште постојао.
Такозвани поинт-оф-сервице системи који омогућавају подизање новца из банке очигледан
су пример првобитних умрежених апликација за рад са базама података. У експозитурама
су инсталирани терминали банке, а централној бази података приступа се преко мреже за
широко подручје. Те првобитне апликације биле су погодне само за организације које су
могле да плате специјализовану терминалску опрему и, у неким случајевима, да изграде и
користе сопствену мрежну инфраструктуру.

Базе података се користе у многим апликацијама, протежући се на стварно читав опсег

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

16
 7. Литература

1. Арсовски, З., Увод у информационе системе, Економски факултет, Крагујевац, 2003.

2. Базе података – дефиниција, врсте, модели, https://kompjuteras.com/baze-podataka/
(приступ сајту: 11.12.2019.)
3. Благојевић, В., Релационе базе података, Клуб НТ, Београд, 2003.
4. Вељовић, А., Његуш, А., Основе релационих и аналитичких база података,
Мегатренд, Београд, 2004.
5. Ђорђевић, С., Стојменов, Л., Структуре и базе података, Практикум за вежбе,
Електронски факултет Ниш, 2004.
6. Mulins, K., Администрација база података, Компјутер библиотека, Чачак 2003.
7. Риордан, Р., Пројектовање базе података, Микро књига, Београд, 2006.

17