Raspoloživost i integritet podataka - ef.uns.ac.rs · Druga definicija raspoloživosti je procena vremena u kome sisitem može da se koristi za produktivan rad.Zahtevana raspoloživost

1

5. Raspoloživost i integritet podataka

5.1. Raspoloživost podataka

aspoloživost podataka je svetinja za administratore baze podataka. Ako podaci nisu raspoloživi tj. dostupni, aplikacije ne mogu da rade. Ako aplikacije ne rade , kompanije gube posao. Samim tim, administrator baye podataka je zadužen da uradi sve što je u

njegovoj moći da bi obezbedio da baza podataka bude dostupna sve vreme i da je operativna. Meñutim, potreba za raspoloživosti podataka se povećava.Vreme dugačkih batch-procesa, da baze podataka mogu biti isklučene duži vremenski period da se izvodile noćne obrade je nestalo. Nestanak tog trenda je početak puta ka elektronskom poslovanju. Spajanje poslovanja sa Internetom dramatično se promenio način funkcionisanja firmi . To je izazvalo nova očekivanja os strane poslovnih procesa : bolja povezanost, više fleksibilnosti i, najvažnije, veća raspoloživost podataka .Kada integrišete Internet i upravljanje bazama podataka , stavljaju se visoki zahtevi pred administratora baze podataka da bi održao bazu funkcionalnom , obezbedio bolji rad i sve to na duži vremenski period. Kada poslovanje firme vezano za direktnu povezanost na bazu podataka (on –line ), onda on nikada ne bih trebao da ima prekide. Ljudi očekuju potpunu funkcionalnost na web sajtovima koje posećuju, bez obzira na vreme u koje to čine. Web se proteže širom sveta. Može biti i 3 sata ujutro u Njujorku, ali je to pravo vreme za biznis negde u svetu.Zato i elektronsko poslovanje mora biti sposobno za rad 24 sata dnevno., 7 dana u nedelji ,365 dana (ili 366 za prestupne godine) godišnje.I zato ako kupac u 3 sata ujutro želi da napravi posao, morate i vi biti sposobni za to-inače ćete izgubiti tog kupca i posao vezan za njega. Na internetu je sva konkurencija udaljena samo jedan klik mišem od vas. Studije pokazuju da ako kupac na Internetu ne dobija zadovoljavajući nivo usluge koju želi u roku od tri sekunde, potražiće prodavca negde drugde.I ako je zadovoljan konkurencijom , šanse su velike da se nikada neće vratiti kod vas. Zbog toga,ako je vaš sajt za e-poslovanje trenutno nedostupan, čak i kratak period vremena, to će rezultirati ne samo stotinama ili hiljadama izgubljenih poseta sajtu, već i gubitkom posla. Naravno da e-poslovanje nije jedini uzrok zahteva za povećanom raspoloživosti. Postoje i drugi faktori:

• Mentalitet „brze hrane“ kupaca koji zahtevaju odličnu uslugu i to „sad!“

• „Sindrom časopisa u avionu“-znate, kada vaš rukovodilac, dok putuje na izlet, pročita članak u časopisu u kome se govori o konkurenciji koja nudi neprekidnu uslugu... tako nastaje vaš sledeći projekat koji eće takoñe ponuditi non-stop uslugu.

• Želja za dobijanje prednosti nad konkurencijom na tržištu tako što ćete ponuditi superiorniju uslugu u kraćem vremenu.

• Potreba za reakcijom zbog konkurencije koja nudi bolju uslugu kupcima zbog veće raspoloživosti svojih podataka.

R

2

5.1.1. Definisanje raspoloživost

Jednostavno rečeno, raspoloživost je stanje gde se nekom resursu može pristupiti od strane korisnika. To znači, da ako je baza podataka dostupna, korisnici tih podataka-a to su aplikacije, kupci i zaposleni –mogu da im pristupe. Svako stanje koje uzrokuje da se resursima ne može pristupiti, uzrokuje stanje suprotno raspoloživosti – neraspoloživost. Druga definicija raspoloživosti je procena vremena u kome sisitem može da se koristi za produktivan rad.Zahtevana raspoloživost aplikacije zavisi od firme do firme, unutar firme od sistema do sisitema, pa čak i od korisnika do korisnika. Raspoloživost baze podataka i performanse baze podataka su termini koji se obično mešaju, ali postoje i neke sličnosti meñu njima. Glavne razlike leže u mogućnosti korisnika da pristupa bazi podataka.Moguće je pristupiti bazi podataka koja pati od loših performansi , ali nije nemoguće pristupiti bazi podataka koja je nedostupna. Ako su performanse toliko loše da korisnici ne mogu da završavaju posao, onda baza podataka postaje nedostupna za bilo koje svrhe. Ipak, morate imati na umu da raspoloživost i performanse jesu različiti pojmovi i moraju se različito tretirati od strane administratora baze podataka – čak i kada problemi performansi prelaze u probleme raspoloživosti. Raspoloživost ima četiri komponente, čijom se kombinacijom omogućava da sisitemi rade i izvršavaju poslove.

• MOGUĆNOST UPRAVLJANJA kreiranje i održavanje efikasnog okruženja koje korisniku pruža uslugu.

• MOGUĆNOST OPORAVKA ponovo uspostavljanje usluge u slučaju greške i otkaza komponenti.

• POUZDANOST mogućnost pružanja usluge na zadatom nivou za navedeni period vremena

• MOGUĆNOST SERVISIRANJA utvrñivanje pojave problema, njihovih uzroka i otklanjanje greške.

5.1.2. Zahtevi za povećanom raspoloživošću

Razgovarajte sa grupom administratora u bilo kojoj velikoj korporaciji i saznaćete da održavaju atmosferu kontrolisanog haosa. Oni su stalno u žurbi da bi udovoljili raznim zahtevima, od dizajna novih aplikacija do održavanja kritičnih poslovnih aplikacija operativnim. Sve to vreme, poslovni rukvodioci zahtevaju da se ti poslovi izvršavaju sa minimalnim ili nikakvim mogućnostima isključivanja baze podataka.Što više, poslovni procesi zahtevaju punu raspoloživost sisitema , atroškovi kada sisitem ne radi rastu, vreme koje je dozvoljeno za optimizaciju performansi na kritičnim sisitemima i softveru je sve manje.

Smanjenje okvira za održavanje Svaki posao koji je u porastu akumulira ogromne količine podataka . U stvari analize pokazuju da je proces povećanja baza podataka u periodu od 2005. do 2010. godine desetostruka. Najveća baza podataka koja radi sad, na početku novog milenijuma, otprilike je veličine stotinu petabajta (1 petabajt 1014 terabajtova ).

3

Visoko propusne baze podataka sa velikim transakcijama zahtevaju periodično održavanje i reorganizaciju.

Podrška odlučivanju Sve više i više kompanija nalaze nove načine da koristi ključne poslovne podatke za podršku odlučivanju.Na primer, kompanije koje rade sa kreditnim karticama koriste te osnovne informacije da bi napravile spisak kupovina i mesečni izveštaj.Iste te informacije se mogu koristiti za analizu obrazaca kupovine kod kupca i kreiranje promocije proizvoda u zavisnosti od ciljne demografske grupe, i kao krajnost, pojedinačnih korisnika.

Skladišta podataka Baš kao što je podrška odlučivanju povećala korišćenje operativnih podataka , skladošta podataka su doprinela sveukupnom razvitku baze podataka.Tipično skladište podataka zahteva replikaciju svih podataka da bi se koristili u različitim sektorima firme i od strane različitih korisnika. Učitavanje i snimanje podataka u operativne baze podataka , a zatim i u skladišta podataka , povećalo je broj operacija koja bi trebalo pokrenuti i administrirati.

Potpuna raspoloživost Upravo kada je najnoviji hardver i softver počeo da obezbeñuje 24/7 raspoloživost, zahtevi moderne ekonomije primoravaju informatičke sektore da procene situaciju i prilagode joj se. Sada se govori o raspoloživosti 24/24, zato što se posao odvija u svim vremenskim zonama, a podaci moraju biti dostupni novom spektru korisnika tj.ne samo onima koji rade u istoj vremenskoj zoni i sistemu uoravljanja baza podataka.

Porast složenih informatičkih tehnologija Bilo koji sistem koji je od jednog proizvoñača trebalo bi da bude čist, precizan i predvidiv. Ali danas je teško naći kompaniju bilo koje veličine koje ne radi na različitim okruženjima, što uključuje centralne računare, računare srednje klase i stone sisiteme u klijent/server arhitekturi. Kada se ti sistemi razvijaju u veličini i funkcionalnosti , zaposleni u IT sektoru moraju pronaći način da prilagode operativno podešavanje kroz složeno i heterogeno okruženje. Osim toga, složenost raste i zbog ljudskih faktora. Smanjenje broja zaposlenih u IT primorava stručnjake da postanu stručnjaci za sve oblasti („generalisti“) , na štetu uske specijalizacije za jednu oblast. Kao rezultat toga, poslovi kao što su reorganizacija baze podataka –nešto što je rutinski i jednostavan posao za eksperte –sada su složeni i dugotrajni za „generaliste“.IT sektor nije imun na smanjenje radne snage u korporacijama; sada ima manje zaposlenih koji će se boriti sa svakodnevnim problemima kojih ima više nego što je bilo pre nekoliko godina.

Cena prestanka rada Cena neaktivnosti sisitema razlikuje se od kompanije do kompanije. Firma Contingencz Planning and Reserch (koja je deo kompanije Edge Rock Alliance Ltd. ) procenila je da je cena neaktivnosti u proseku 6,5 miliona dolara po času u prodajnim i brokerskim firmama. Pogledajte tabelu 8.1. za dodatne primere prosečne cene neaktivnosti po času, po granama.

4

Tip posla procenjeni finansijski efekat po času ( $ )

Prodajni i brokerski 6,45 miliona Provera kreditnih kartica 2,6 miliona Kanali za kupovinu od kuće 113.750 Centri kataloške prodaje 90.000 Rezervacije avio karte 89.000 Usuge isporuke paketa 28.250

Prava istina je da prekid rada sistema utiče na svaki posao, i bilo koji veći prekid će se finansijski osetiti u firmi. Kada procenjujete cenu prekida rada ; uzmete u obzir sve faktore koji utiču na tu cenu, uključujući i :

• Izgubljene poslove zbog prekide ,

• Cenu ponovnog izlaska na tržište nakon što je sisitem proradio,

• Troškove pravilnika za voñenje parnica,

• Uticaj pada vrednosti akcija ( naročito e-poslovanje koje kompletno zavisi od računarskog sisitema)

Koliko raspoloživosti je dovoljno ? Tradicionalno se raspoloživost meri procentima ukupnog vremena od koga usluge treba da budu dostupne .Na primer, sisitem sa 99% raspoloživosti će biti u funkciji 99% vremena i 1% vremena će biti nefunkcionalan. Drugi termin koji se koristi za definisanje raspoloživosti je srednje vreme izmeñu otkaza ( „Mean Time Between Failure“-MTBF). Tačnije, MTBF je bolji za opis pouzdanosti nego raspoloživosti. Meñutim, pouzdanost ima značajan uticaj na raspoloživost. Što je sisitem pouzdaniji to će biti i raspoloživiji. Pa ipak, koliko je raspoloživost dovoljna ? U današnje vreme interneta , postoji pritisak da se obezbedi neprestani rad sisitema ,365 dana u godini, 24 sata dnevno. Za 60 min po času, to je godišnje 525.600 minuta rada. Postizanje 100% raspoloživosti je optimističan, ali nerazuman cilj. Termin pet devetki se često koristi za opis visokoraspoloživih siistema. To znači da je sistem aktivan 99,999% vremena, a to je približno 100% raspoloživosti, ali sa mogućnošću da je neko kratko vreme neaktivnost neizbežna . Čak i ako 100% raspoloživost nije razuman cilj, neki sisitemi dostižu raspoloživost od pet devetki. Administratori baze podataka mogu da dizajniraju bazu podataka i izgrade sisitem koji su sposobni da dostignu visok nivo raspoloživosti. Meñutim, to što visoka raspoloživost može biti ugrañena u sisitem ne znači da svaki sisitem mora biti izgrañen sa takvim dizajnom. Razlog je to što visokoraspoloživi sisitemi koštaju mnogo puta više nego tradicionalni, koji imaju „ugrañenu“ izvesnu neraspoloživost.

Gubitak centra za obradu podataka Očigledno je da podaci neće biti dostupni ako centar za obradu podataka pogoñen prirodnom nepogodom ili nekom drugom katastrofom. Iako je gubitak relativno mali iz poslovne perspektive i imaju uticaj samo na računarske resurse ,ili je veliki i imaju uticaj na celu zgradu ili firmu, gubitak računarskih resursa znači i gubitak baze podataka i svih podataka u njoj.

5

Da bi se povratila raspoloživost podataka u slučaju gubitka, obično je neophodno ponovno kreiranje okruženja baze podataka ( a ponekad i mnogo više toga ) na nekoj udaljenoj lokaciji. Iz perspektive raspoloživosti podataka, gubitak centra za obradu je najgori tip problema sa kojima se administrator baze podataka ikada može susresti. Čak i ako se podaci i baza podataka mogu obnoviti na udaljenoj lokaciji , ozbiljna pitanja raspoloživosti se i dalje postavljaju.

Greške u radu zbog diskova Pošto baze podataka počivaju na fizičkoj strukturi na disku za smeštanje podataka , raspoloživost baze podataka je veoma zavisna od greške na disku.Naravno od stepena raspoloživosti baze podataka zavisi od tipa sisitema diskova i tipa greške koji se pojavio na disku. Greške na diskovima se javljaju iz različitih razloga: zbog fizičkog mehanizma diska, kontrolera ili možda zbog logičkih kablova. Jedna od najjednostavnijih implementacija baze podataka je postavljanje datoteka baze podataka na lokalni podsisitem diskova koji je direktno povezan na server baze podataka. Oporavak iz te situacije obično zahteva zamenu ili ponovnu konfiguraciju podsisitema diskova, na koji će se izvršiti i oporavak podataka. Drugi metod oporavka je podizanje potpuno novog servera baze podataka i prebacivanje baze podataka na njega . Ni jedna od ovih opcija nije potrebna ako greška na jedinicama diskova može da se otkloni.

Greške u radu operativnog sisitema Nisu svi problemi neraspoloživosti podataka baze podataka nastali zbog hardvera. Softver takoñe može stvoriti probleme. Na primer, podaci neće biti dostupni u slučaju greške u radu ili prekida rada operativnog sistema,čak i ako sav hardver potpuno funkcionalan. Tipične greške koje se javljaju kod operativnog sistema su ošta nestabilnost zbog neotklonjenih grešaka , problemi kod nadogradnje na novu verziju OS ili problemi sa programima za otklanjanje grešaka u operatvnom sisitemu. Kada se desi prekid rada operativnog sisitema , jedina opcija koju možete primeniti za vraćanje raspoloživosti podataka je oporavak baze podataka na novom serveru safunkcionalnim operativnim sisitemom.

Greške u radu SUBP softvera Slično greškama u radu operativnog sistema , greška u SUBP softvera će uzrokovati neraspoloživost podataka. Ako je SUBP neoperativan, podacima u njegovoj bazi podataka se ne može pristupiti. Ovakve greške nastaju iz sličnig razloga kao i one kod operativnih sisitema: opšta nestabilnost SUBP zbog grešaka u softveru, problemi tokom nadogradnje verzije ili problemi sa programima za otklanjanje grešaka. SUBP može postati neoperativan i zbog nedostatka odreñenih resursa potrebnih za njegov rad – kao što su startni parametri, odreñene sistemske datoteke i memorijske strukture.

Problemi sa aplikacijama Aplikativni softver takoñe može dovesti do problema nedostupnosti pdataka. Ako je aplikacija jedini način da korisnik doñe do podataka, problemi raspoloživosti podataka rastu ako aplikacija prijavi grešku i prekine rad. Greške u radu aplikativnog softvera najverovatnije neće uzrokovati

6

prekid rada baze podataka, ali korisnicima to malo znači ukoliko ne mogu da koriste svoje uobičajne aplikacije za pristup podacima.

Problemi bezbednosti i autorizacije Problemi koji se odnose na bezbednost su sledeći uzrok nedostupnosti baze podataka . Ovaj problem se javlja usled nepravilnog korišćenja ili administracije baze podataka. Pre nego što se podacima pristupi, bilo direktno od strane krajnjeg korisnika , bilo preko aplikacije , mora se izvršiti autorizacija pristupa – obično od administratora baze podataka ili administratora za bezbednost. Ako iz bilo kog razloga korisnik nema dozvolu za pristup bazi podataka , podaci će za njega biti nedostupni. Problemi vezani za bezbednost se javljaju odmah nakon prelaska aplikacije u radni režim ili kada novi korisnik pokuša da koristi sistem bez predhodnog dobijanja odgovarajućih dozvola.

Oštećeni podaci Oštećeni podaci takoñe mogu uzrokovari njihovu nedostupnost. Čak i ako su hardver i sistemski softver ispravni, baza podataka može postati nedostuwpna zbog njenog sadržaja koji je neažuran. Poslovne odluke koje se donose na osnovu takvih podataka mogu negativno da utiču na poslovanje firme. Oštećeni podaci mogu nastati iz mnogih razloga: greška u aplikativnim programima, greška u SUBP softvera, lošeg dizajna baze podataka ili greške korisnika. Stari podaci takoñe mogu postati neispravni ako su novi podaci izloženi rigoroznijoj kontroli i proverama pre ažuriranja. Ako dovoljna količina podataka postane oštećena, administrator baze podataka mora da isključi bazu podataka za pristup korisnika. Mnogi SUBP obezbeñuju komande za to. Ako ne isključite korisnika iz baze podataka, neće se samo donositi loše odluke na osnovu loših podataka, već će podaci postati još više oštećeni, jer procesi koji ih koriste mogu da oštetei ostale, povezane podatke. Što pre administrator podataka reaguje , to će se manje podataka oštetiti. Nije potrebno reći da je isključivanje baze podataka jednako mogućem izgubljenom poslu. Kada se podaci oštete, administrator baze podataka mora da radi sa ostalim specijalistima za razvoj aplikacija da bi tačno utvrdio koji su podaci neažurni i da bi razradio plan za njihovu korekciju. Drugi tip nedostupnosti podataka se može javiti kada dodje do greške u prenosu podataka. Ako se korisnici oslone na činjenicu da su podaci u bazi podataka tačni i ažurni, pogrešno čitanje iz baze podataka može učiniti bazu podataka nekorisnom čak ako se u njoj nalaze ispravni podaci, jer će biti nemoguće odrediti koji su podaci ažurni , a koji ne.

Gubitak objekata baze podataka Slučajno brisanje objekata baze podataka je još jedan uzrok neraspoloživosti podataka. Kada se baza podataka ili prostor tabele obriše, podaci iz njih nisu više dostupni. Administrator baze podataka u tom slučaju mora da pokrene skriptove za ponovno kreiranje objekata ( uključujući i povezane objekte koji su takoñe obrisani ) ,postavi ponovo referencijalna ograničenja, postavi bezbednosne parametre i tek onda učita podatke, koji fizički moža još postoje na disku. Neki SUBP ili dodatni alati omogućavaju lak povratak takvih podataka. Ako takve tehnike nisu dostupne, podaci će se morati oporaviti iz zaštitnih kopija ili arhivskih dnevnika baze podataka.

7

Ako je obrisan indeks, podaci će biti dostupni , ali će performanse obično biti slabije. Veoma loše performanse uzrokuju da korisnici imaju isti efekat kao i kod nedostupne baze podataka. Pogrešno brisanje objekata u bazi podataka je obično rezultat ljudske tj. greške administratora baze podataka. Meñutim, može se desiti da nezavisni ili neiskusni korisnici sa privilegjama administratora uzrokuju takve greške. Možete smanjiti pojave slučajnog brisanja objekata iz baze podataka tako što ćete postaviti odgovarajuće bezbednosne mehanizme i obezbediti sveobuhvatnu i temeljnu obuku administratora baze podataka.

Prekid rada: planirani i neplanirani Kada se raspravlja o prekidima rada sistema , mnogi iz tehničkog osoblja odmah pomisle na neplenirane prekide. Ljudske greške, greške u programima i neispravnosti hardvera uzrokuju neplanirane prekide rada. Medjutim, mnogi prekidi rada su u stvari planirani prekidi. Planirani prekidi rada su uzrokovani planiaranim i redovnim održavanjem sistema i baze podataka i zato zahtevaju da baza podataka bude neaktivna za druge korisnike – na primer reorganitacija baze podataka ili promene u njoj. Planirani prekidi predstavljaju 70 % ukupnih prekida, dok 30% predstavljaju neplanirani. Osim toga, studije pokazuju da više od 50% neplaniranih prekida otpada na probleme koji su se javili tokom planiranih prekida.

Obezbeñivanje raspoloživosti Sada kada smo ustanovili da je posao administratora baze podataka vrlo izazovan, pomerićemo temu na neke tehnike koje će pomoći većoj raspoloživosti podataka. Suočene sa smanjenim budžetom i resursima i narastajućom količinom podataka kojom moraju da upravljaju, IT firme treba da ocene kritične potrebe i da kreiraju niz ključnih strateških koraka da bi obezbedile raspoloživost. Dobra strategija može sprovesti korake ka :

• Izvoñenju rutinskog održavanja dok sistem ostaje operativa

• Automatizovanju funkcija administratora baze podataka

• Eksplotaciji mogućnosti koje nudi SUBP za obezbeñivanje raspoloživosti,

• Eksplotaciji hardverskih tehnologija.

Izvoñenje rutinskog održavanja dok sistem ostaje operativan Da biste sproveli optimizaciju performansi – dok se suočavaju sa sve manjim brojem zaposlenih u IT sektoru i sve manjim budžetom – treba razmotriti korišćenje proizvoda koji pojednostavljuju i automatizuju funkciju održavanja, a ti proizvodi su ključ uspeha. Administratorima baze podataka trebaju alati koji će vreme održavanja svesti sa sata na minute ili ga potpuno ukinuti dozvoljavajući korisnicima da pristupaju podacima i obavljaju svoje poslove. Neki SUBP obezbeñuju ugrañene funkcije za izvoñenje nekih poslova održavanja dok je baza i dalje dostupna korisnicima. Ako SUBP ne obezbeñuje takve ugrañene funkcije, postoje alati nezavisnih proizvoñača koji obezbeñuju dodatnu raspoloživost baze podataka. Ključ je u iskorišćenju funkcionalnosti besprekidnih alata za baze podataka. Besprekidni alat izvršava posao koji dozvoljava istovremeni pristup radi ažuriranja i čitanja baze podataka dok traje izvršenje procesa održavanja baze – i sve to radi bez narušavanja integriteta podataka.

8

Tipovi besprekidnih poslova koji su najviše potrebni jesu :

• Reorganizacija baze podataka radi održavanja performansi

• Zaštitno snimanje podataka da bi se obezbedili podaci za oporavak u slučaju greške u aplikacijama ili hardveru, a i slučaju dešavanja prirodnih nepogoda ili katastrofe

• Rešenja za oporavak baze podataka koja mogu vratiti podatke bez zahteva za prekidom rada

• Učitavanje i iščitavanje podataka za potrebe prenosa podataka izmeñu glavne baze i operativnih skladišta podataka sisitema za podršku odlučivanju,

• Alati za statističko prikupljanje podataka koji mogu analizirati karakteristike podataka i beležiti statistike koje kasnije koristi alat za optimizaciju baze podataka,

• Alati za proveru referencijalnog i strukturnog integriteta

Automatizacija funkcija administratora baze podataka Ugrañivanje više funkcionalnosti u proceduru administratora baze podataka može povećavati ukupnu raspoloživost baze podataka i aplikacija. Kada se ispravno primene, automatizovani procesi će mnogo reñe praviti greške nego ručno izvedeni poslovi. Ljudi greše. Računari ne greše (osim ako ih ljudi ne programiraju pogrešno ) Što je posao složeniji , više ćete koristi dobiti automatizacijom. Sprovoñenje izmena u bazi podataka je složen posao. Činjenica je da automatizacija promena može poboljšati raspoloživost baze podataka. Korišćenjem automatizovanog alata za administraciju baze podataka koji zna kako SUBP sprovodi izmene na objektima baze podataka, smanjuju se potencijalne ljudske greške. Osim toga, vreme da administrator baze podataka, generiše skriptove za izmenu je mnogo puta veće nego što je potrebno alatu za upravljanje izmenama. Takoñe alat verovatno neće praviti greške pri tome. Automatizacijom promena u bazi podataka , manje vremena je potrebno za analizu zahtevanih izmena, razvoj skriptova za izvršavanje promena i njihovo startovanje da bi se izmene i izvršile. Sve u svemu, automatizovani proces izmena je definitivno koristan za održavanje raspoloživosti.

9

5.2. Integritet podataka

bezbeñenje integriteta baze podataka u firmi ključna je komponenta posla administratora baze podataka. Baza podataka je od male koristi ako su njeni podaci neažurni i ako im se ne može pristupiti zbog problema integriteta. Administrator baze

podataka poseduje mnoge alate koji će obezbediti integritet podataka.

Tipovi integriteta U odnosu na bazu podataka razmatraćemo dva aspekta integriteta:

• Strukturni integritet baze podataka

• Semantički integritet podataka. Praćenje svakog objekta baze podataka radi odgovarajućeg kreiranja, formatiranja i održavanja cilj je strukturnog integriteta baze podataka. Svaki SUBP koristi svoj format i strukture da bi održao baze podataka, prostore tabela, tabele i indekse pod svojom kontrolom. Sistemske i aplikativne greške mogu uzrokovati pogrešan rad sa tim internim strukturama, a posao odministratora baze podataka je da takve probleme otkrijei otkloni pre nego što oni postanu nepremostivi. Drugi tip integriteta je semantički integritet podataka. On se odnosi na značenje podataka i veze medju njima koje se moraju održavati. SUBP obezbedjuje opcije, kontrole i procedure da bi se obezbedio semntički integritet podataka koji se nalazi u bazi. Administratori moraju znatti kako sisitem obezbeñuje automatsku proveru integriteta podataka. I najzad, kao najvažniji deo posal, administratori moraju ugraditi semantički integritet podataka u dizajn baze , kao i da iniciraju proces provere i korekcije problema integriteta koji stalno prete bazi podataka.

5.2.1. Strukturni integritet baze podataka

Strukturni integritet i konzistetnost baze podataka je od najveće važnosti u obavljanju poslova administracije baze podataka. SUBP koristi interne strukture i pokazivače da bi održao objekte baze podataka u odgovarajućem stanju. Ako sete strukture oštete na bilo koji način, pristup bazi podataka će biti onemogućen.

Tipovi problema u internim strukturama baze podataka Jedan od najčešćih problema koji se javljaju u relacionim bazama podataka je oštećenje indeksa. Podsetite se iz predhodnih poglavlja da indeks obezbeñuje alternativne putanje do podataka u bazi korišćenjem ureñenog B-stabla. Stranice na listovima indeksa sadrže pokazivače ka fizičkim lokacijama podataka u baznoj tabeli. Ako ti pokazivači ne pokazuju na ispravne podatke, indeksi su beskorisni. Ideksi se mogu oštetiti na različite načine, u zavisnosti od sistema koji se koristi i operacija koje se izvršavaju nad indeksom i pripadajućom tabelom. Na primer, ako je tabela oporavljena sa zaštitnih kopija, a indeksi nisu ažurirani , onda oni neće tačno odslikavati trenutno stanje podataka. Medjutim, indeksi nisu jedini objekti baze podataka koji koriste pokazivače. Pri korišćenju odreñenih tipova podataka, sisitem može zahtevati pokazivače. Na primer, veliki objekti, kao što

O

10

su kod DB2 LOB kolone ili kod SQL Servera Text ili Image kolone, ne smeštaju se u tabelu sa ostalim podacima. Moguće je da ovi pokazivači izgube sihronizaciju sa podacima, uzrokujući nemogućnost prustupanja, Još jedan, ali dosta reñi problem strukturnog integriteta baze podataka je oštećenje zaglavlja

stranice. Svaka fizička stranica (ili blok ) u datoteci baze podatakasadrži interne podatke poznate kao zaglavlje, koji se nalaze u njenom početku. Zaglavlje omogućava da se sadržaj stranice lako i brzo pročita. Ukoliko se zaglavlje ošteti, SUBP neće moći da interpretira podatke koji se nalaze na toj stranici. Takve situacije obično zahtevaju da se podaci oporave sa zaštitinih kopija . Podaci na zaštitnim kopijama su još jedan potencijalni izvor problema strukturnog integriteta. Svaki SUBP formatira i primenjuje specifične strukture tih kopija. Ako one nisu pravilno formatirane , ili su podaci na pogrešnoj lokaciji unutar kopija , ne mogu se koristiti u svrhu oporavka podataka.

Rešavanje problema strukturnog integriteta Svaki sistem obezbeñuje različite uslužne programe za proveru mnogi aspekata strukturnog integriteta baze podataka. Ovi uslužni programi omogućuju ispitivanje integriteta baze podataka. Na primer, Sybase i Microsoft SQL Server obezbedjuje DBCC alat, DB2 ima CHECK i REPAIR, a Informix nudi TBCHECK. Da bi smo obrazložili funkcionisanje ovih uslužnih programa, fokusiraćemo se na DBCC. Slika pokazuje neke situacije u kojima se ovaj nprogram može da koristi.

Opcije za proveru konzistetnosti Uslužni program DBCC obezbedjuje sve opcije za osnovnu proveru konzistetnosti:

• DBCC CHECKTABLE (ime_table) provera konzistetnosti podataka i indeksnih stranica tabele. Kada se DBCC startuje sa ovom opcijom , on će prijaviti ukupan broj stranica sa

11

podacima, broj slogova, broj kolona tekstualnog ili binarnog tipa , kao i narušavanje bilo kog tipa integriteta.

• DBCC REINDEX (ime_table) proverava konzistetnost indeksa i njegov oporavak ukoliko naiñe na oštećenje strukture.

Provera baze podataka Dodatne opcije DBCC-a koje su na raspologanju služe za proveru integritetabaze podataka:

• DBCC CHECKDB ( ime_baze_podataka) izvršava prvo CHECKTABLE nad svakom tabelom navedene baze podataka

• DBCC CHECKKCATALOG (ime_baze_podataka) proverava konzistetnost sistemskog kataloga navedene baze podataka.

• DBCC CHECKALLOC (ime_baze_podataka) proverava konzistetnost navedene baze podataka i izveštava o trenutnoj strukturi proširenja datoteke.

Korišćenje memorije Program DBCC se može koristiti za nadgledanje dodeljivanja memorije i njenog korišćenja. Navodjenjem opcije MEMUSAGE ( DBCC MEMUSAGE ) će se dobiti izveštaj o dodeljivanju memorije za 20 najzahtevnijih korisnika. Izveštaj sadrži sledeće iformacije:

• KONFIGURISANJE MEMORIJE količina memorije koja je dodeljena SUBP-a .

• VELIČINA PROGRAMSKOG KODA Količina memorije koja je upotrebljena za programski kod

• JEZGRO SISTEMA I INTERNE STRUKTURE količina memorije iskorišćena za jezgro i za server.

• KEŠ STANICA količina memorije koja je iskorišćena za keš podatke

• BAFERI I ZAGLAVLJA PROCEDURA količina memorije iskorišćena za keš podatke

• DETALJNE INFORMACIJE O KEŠU PODATAKA Spisak 20 korisnika koji najviše koriste keš podatke, zajedno sa spiskom objekata kojima pristupaju, i koliko je bafera od 2K iskorišćeno

• DETALJNE INFORMACIJE O KEŠU PROCEDURA Spisak 20 korisnika koji najviše koriste keš procedure, navodeći tip pristupa i raspodelu memorije

5.2.2. Semantički integritet podataka

Semantički integritet baze podataka se odnosi na mogućnosti i procese sisitema koji se mogu koristiti da bi obezbedili tačnost i funkcionalnost sadržaja baze podataka. Dok se strukturni integritet baze podataka odnosi na stukture koje sadrže podatke (objekte baze podataka ) , semantički integritet ukazuje na konzistetnost samih podataka. Administratori baze podataka se konstantsno bore sa pitanjem kako najbolje održati semantički integritet podataka –korišćenjem opcija sisitema ili aplikativnim kodom. Ovo je veoma važno pitanje o kome se stalno vodi rasprava. Obično se smatra da je korišćenje SUBP-a za održavanje integriteta podataka najbolje rešenje i to iz nekoliko razloga.

12

Lakše je kreirati i održavati pravila semantičkog integriteta korišćenjem SUBP-a neko kreirati i održavti programski kod za te namene.

Integritet entiteta Integritet entiteta je najosnovniji nivo integriteta podataka koji SUBP može da izvršava. Integritet entiteta znači da svako pojavljivanje entiteta mora biti jedinstveno indetifikovano. Drugim rečima , zahteva se definisanje primarnog ključa za svaki entitet, kao i da ni jedna komponenta primarnog ključa ne može biti Null. U praksi ni jedan SUBP ne forsira primenu integriteta entiteta zato što se entiteti ili tabele mogu kreirati bez definisanje primarnog ključa.Osim toga, veoma je loša praksa kreirati tabele bez primarnog ključa zato što to otežava indetifikaciju slogova. Primarni ključ je potreban da bi se postavila pravila referencijalnog integriteta izmeñu tabela. Ograničenje primarnog ključa se može sastojati od jedne ili više kolona iste tabele koje su jedinstvene unutar nje.Tabela može imati samo jedan primarni ključ koji ne može biti Null. Sledi primer kreiranja primarnog ključa: CREATE TABLE RADNIK ( SifRad INTEGER PRIMARY KEY, AdresaRad VARCHAR (70), TipRad CHAR (10), If0rgRad CHAR (3) NOT NULL WITH DEFAULT, Zarada DECIMAL (7,2) NOT NULL, Procenat0dProfita DECIMAL (7,2) Dodatak DECIMAL (7,2), ) IN db.ts; Ovaj primer ukazuje na specifičnosti ograničenja primarnog ključa na nivou kolone: ono se primenjuje na koloni SifRad, koji je definisan kao primarni ključ za ovu tabelu. Medjutim u praksi je vrlo često da se primarni ključ sastoji od više kolona. Iz tog razloga ograničenja primarnog kluča se mogu postaviti na nivou tabele. Na primer ako se primarni ključ ove tabele definiše kao kombinacija kolona SifRad i TipRad, možete zadati ovakvu specifikaciju na kraju definicije tabele, odmah posle navodjenja poslednje kolone: PRIMARY KEY PK_RAD ( SifRad, TipRad )

Ograničenje jedinstvene vrednosti Ograničenje jedinstvene vrednosti je slično ograničenju primarnog ključa. Svaka tabela može imati nula, jednu ili više takvih ograničenja koja se sastoji od jedne ili više kolona. Vrednosti tih kolona ili njihove kombinacije mora biti jedinstvena unutar tabele – što znači da ni jedan drugi slog ne može sadržati iste vrednosti tih kolona. Ova ograničenja se razlikuju od primarnog ključa u tome što se ne mogu koristiti za podršku referencijalnim ograničenjima.

13

Kao i u slučaju ograničenja primarnog ključa, SUBP će zahtevati kreiranje jedinstvenog indeksa nad kolonama ovog ograničenja da bi se zabranila pojava duplih vrednosti tih kolona.

Ograničenje jedinstvene vrednosti Tipovi podataka i dužina podataka su najosnovnija ograničenja integriteta koja se primenjuju nad podacima u bazi. Jednostavno navoñenje tipa podataka za svaku kolonu prilikom kreiranja tabele omogućiće sistemu da obezbedi smeštanje koreknih podataka u kolonu. Procesi koji pokušavaju da upišu vrednost pogrešnog tipa biće odbijeni. Osim toga, maksimalna dužina dodeljenenoj koloni zabranjuje unošenje većih vrednosti od onih koje su definisane. Administrator baze podataka mora pažljivo da izabere tip i dužinu za svaku kolonu tabele. Bajbolje je napraviti izbor tipa podataka koji će se najbolje poklopiti sa domenom korektnih vrednosti te kolone.

Korisnički tipovi podataka Korisnički tipovi podataka ( „user defined data type“ –UDT ), obezbeñuju mehanizam za proširenje tipova podataka koji se mogu definisati u bazi, kao i način na koji se podacima može upravljati. Drugim rečima, administrator baze podataka može kreirati korisničke tipove podataka radi dodatne definicije ispravnih vrednosti kolone . Kada se korisnički tipovi podataka jednom definišu, proširuje se funkcionalnost SUBP-a tako što se omogućava administratoru da ih navede u CREATE TABLE DDL-u baš kao i ugrañene tipove podataka. Korisnički tipovi podataka su korisni kada želite modelirati podatke koji su specijalno prilagoñeni zahtevima firme. Na primer, oni se mogu koristiti kada baratate različitim valutama. Možda firma koristi monetarne vrednosti Kanade, SAD-a, Evropske unije i Japana. Administrator baze podataka može kreirati četiri korisnička tipa podataka kao što su: CREATE DISTINCT TYPE Kanadski_Dolar AS DECIMAL ( 11,2) ; CREATE DISTINCT TYPE Americki_Dolar AS DECIMAL ( 11,2 ) ; CREATE DISTINCT TYPE Euro AS DECIMAL ( 11,2) ; CREATE DISTINCT TYPE Japanski_Jen AS DECIMAL (15,2) ; Nakon kreiranja ovih tipova podataka,oni se mogu koristiti na isti način kao i ugrañeni tipovi. Naravno, tačna sintaksa kreiranja korisničkih tipova razlikuje se od sistema do sistema. Kreiranje odvojenih tipova podataka, sistem primenjuje strogo odvajanje tipova ; drugim rečima, sistem će zabraniti izvoñenje nedefinisanih operacija izmeñu različitih tipova. Na primer, sledeća operacija se neće dozvoliti zbog pomenutog strogog odvajanja tipova: UKUPAN_ISNOS = AMERIČKI_DOLAR + KANADSKI_DOLAR

Podrazumevane vrednosti Kada se kreiraju kolone u tabelama , može im se dodeliti podrazumevana vrednost koja će biti upotrebljena kada se u SQL INSERT naredbi eksplicitno ne navede vrednost te kolone. Ovo omogućava programerima da izostave tu kolonu i ostave sistemu da joj automatski dodeli podrazumevanu vrednost.

14

Svaka kolona može imati samo jednu podrazumevanu vrednost. Tip kolone, dužina i njena svostva moraju podržati podrazumevanu vrednost koja je definisana.

Ograničenja provere vrednosti Ograničenja provere vrednosti je restrikcija koja se postavlja na vrednost podataka koji se mogu uneti u kolone tabele. Kada se definiše ovo ograničenje , ona postavlja restrikcije na sadržaj kolone kao logičke izraze. Logički izraz je esplicitno definisan u DDL-u tabele i formulisan je na isti način kao i SQL WHERE izraz. Bilo koji pokušaj promene sadržaja kolona naredbom INSERT ili UPDATE uzrokovaće izračunavanje logičkog izraza.Ako izmene zadovoljavaju uslove logičkog izraza, dozvoljava se izvršenje izmene. Ograničenje provere vrednosti se može definisati prilikom kreiranja tabele,ili se dodati kasnije naredbom ALTER TABLE. Ime ograničenja indetifikuje ograničenje u bazi podataka. Isto ime ograničenja se ne može definisati više od jednom za istu tabelu. Ako ime ograničenja nije navedeno, sistem će automatski generisti jedintsveno ime za njega. Svaki SUBP koristi različite algoritme za definisanje imena ograničenja ,ali se ono obično izvodi iz imena prve kolone u uslovu provere. Uslov provere definiše konkretnu logiku ograničenja. On se može definisati korišćenjem bilo kojih osnovnih operacija (>,<,=,<>,<=, >=) kao i BETWEEN, IN, LIKE i NULL. Osim njih se mogu i koristiti i OR ili AND da bi se logički spojili zadati uslovi u ograničenju. Ipak postoje odreñene restrikcije u korišćenju provere vrednosti:

• Ograničenje provere vrednosti se može jedino pozivati na kolone tabele u kojoj se ono kreira

• Unutar provere vrednosti, dozvoljen je ograničen podskup SQL konstrukcija. Obično su zabranjeni podupiti, funkcije nad kolonama, globalne prominjive i negacija ( NOT ).

• Prvi operand ograničenja provere vrednosti je kolona tabele, a drugi je ili kolona ili konstanta

• Ako je drugi operand konstanta, ona mora biti kompatibilna sa tipom podataka prvog operanda.

Koristi od ograničenja provere vrednosti Glavna korist je direktna mogućnost primene poslovnih pravila u bazi podataka bez potrebe za definisanjem dodatne aplikativne logike. Kada se poslovno pravilo definiše i fizički implementira, ono se ne može zaobići. Zbog toga što nije potrebno dodatno programiranje , administrator baze podataka može implementirati ograničenja provere vrednosti bez uključenja programera aplikacije. Na ovaj način se efikasno smanjuje količina koda koju programeri moraju napisati. Ona obezbeñuje bolje održavanje integriteta podataka. Pošto se izvršavaju uvek kada su podaci u koloni na kojom su definisane promene, poslovna pravila koja su definisana ograničenjem se poštuju i tokom ad hac obrade i izvršavanja dinamičkih SQL-a . Provere vrednosti obezbeñuju konzistetnost podataka. Zbog toga što se definišu jednom – u DDL-u tabele – svako od njih uvek primenjuje.

15

Primeri ograničenja provere vrednosti Ograničenja provere vrednosti omogućavaju administratoru ili dizajneru baze podataka da primene robusnija pravila integriteta podataka direktno u bazu. Sledeći primer CREATE TABLE RADNIK ( SifRad INTEGER PRIMARY KEY CONSTRAINT provera_sifre Check ( sifRad BETWEEN 100 AND 25000 ), AdresaRad VARCHAR (70), Tiprad CHAR (10) CHECK (TipRad IN ( ’odredjeno’,’neodredjeno’,’ugovor’)), Sif0rgRad CHAR /3) NOT NULL WITH DEFAULT, Zarada DECIMAL (7,2) NOT NULL CONSTRAINT provera_zarada Check ( zarada <50000.00) Procenat0dProfita DECIMAL (7,2), Dodatak DECIMAL (7,2), ) in db.ts ; Naredba CREATE za tabelu RADNIK sadrži tri različita ograničenja provere vrednosti:

• Ime prvog ograničenja je provera_šifre. Ono se definiše nad kolonom SifRad i osigurava da se unete vrednosti mogu kretati u rasponu od 100 do 25000 (umesto domena svih celih brojeva)

• Drzgo ograničenje u ovoj tabeli je nad kolonom TipRad. Ovo je primer neimenovanog ograničenja što. Iako je dozvoljeno , ipak nije preporučljivo.najbolje je da uvek zadate ime ograničenju da bi se ono lakše održavala i adminisrirala. Tačno odreñene vrednosti se mogu upisati u ovu kolonu:’odredjeno’,’neodreñeno’ i ’ugovori’; ni jedna druga vrednost neće biti prihvaćena

• Poslednje definisano ograničenje je nazvano proevra?zarade. Njime se efikasno obezbeñuje da se ni jednom radniku ne može uspisati veća zarada od 50 000.

Vrlo često poslovna pravila nalažu pristup u više kolona istovremeno u jednoj tabeli. U takvoj situaciji je potrebno kreirati poslovno pravilo kao ograničenje provere vrednosti na nivou tabele, umesto na nivou kolone. Naravno, istovremeno mogu postojati i provere vrednosti nad kolonama. U smislu funkcionalnosti, nema razlike ako se ograničenje proere vrednosti zada na nivou tabele ili kolone. Proširimo gornji primer sa nekoliko provera vrednosti na nivou tabele:

CREATE TABLE RADNIK ( SifRad INTEGER PRIMARY KEY CONSTRAINT provera_sifre CHECK (SifRad BETWEEN 100 AND 25000), AdresaRad VARCHAR (70), TipRad (CHAR) CHECK (TipRad IN (’odreñeno’,’neodreñeno’,’ugovor’)), Sif0rgRad CHAR(3) NOT NULL WITH DEFAULT,

16

Zarada DECIMAL (7,2) NOT NULL CONSTRAINT proevra_zarade CHECK ( Zarada <50000.00) Procenat0fProfita DECIMAL (7,2), Dodatak DECIMAL (7,2), CONSTRAINT zarada_proc Check ( Zarada > Procenat0dProfita ), CONSTRAINT proc_dodatak CHECK ( Procenat0Profita=0 OR Dodatak=0 ) ) IN db.ts ; Sad se naredbom CREATE promenila tako da sadrži dve provere vrednosti na nivou tabele sa sledećim značenjem:

• Prva provera vrednosti za tabelu RADNIK ima naziv zarada_proc. Ona obezbeñuje da ni jedan radnik ne može od procenta profita zaraditi više nego što mu je zarada.

• Druga provera vrednosti ima naziv proc_dodatak. Ovo ograničenje obezbeñuje da radnik ne može istovremeno imati procenat od profita i dodatak na zaradu.

Null i ostali potencijalni problemi .Sledeće razmatranje ograničenja provere vrednosti je relacioni Null.Bilo koja kolona koja može biti Null i za koju postoje provera vrednosti može se postaviti na Null. Korišćenjem uslužnih programa može uzrokovati probleme sa ograničenjima provere vrednosti. Na primer, u zavisnosti od sistema, LOAD može ili ne mora izvršavati definisane provere vrednosti dok se podaci učitavaju u tabelu. Još jedan potencijalni problem koji se javlja kod provere vrednosti je njihovo kodiranje u više tabela. Moguće je da slične kolone istog tipa podataka i dužine mogu postojati u različitim tabelama baze podataka. Kao i provere vrednosti pravila definišu parametre za proveru podataka. Kad god se podaci ubacuju ili ažuriraju, pravila se proveravaju da bi se utvrdilo da li se izmene podataka poklapaju sa zadatim pravilima. Ona se mogu definisati i na korisničkim tipovima podataka i na kolonama. Nakon kreiranja, pravila moraju biti dodeljena kolonama ili korisničkim tipovima podataka pre nego što budu upotrebljena u bazi podataka. Povezivanje se vrši sistemskom procedurom SP_BINDRULE. Na primer, sledeće naredbe se mogu koristiti za kreiranje pravila koje proverava skraćenice američkih država Ilinois, Viskonsis i Indijana, a zatim povezuje pravilo sa kolonama u dve različite tabele:

CREATE RULE Pravilo_Drzava AS @drzava IN (’IL’,’WI’,’IN’)

EXEC SP_BINDRULE “Pravilo_Država”, „izdavac.drzava“ EXEC SP_BINDRULE „Pravilo_Država“, „autor.drzava“

Kada se pravilo pridruži koloni ili korisničkom tipu podataka, ono će funkcionisati kao ograničenje provere vrednosti. Pravila mogu biti mnogo pouzdanija jer se kreiraju samo jednom, nakon čega se povezuju sa odgovarajućim kolonama i tipovima podataka.

17

Osim toga, moguće je definisati neprimenjivo pravilo provere vrednosti nad tabelom. Relacioni SUBP obezbeñuje dodatnu mogućnost definisanja podrazumevane vrednosti. Kada se slog ubacuje ili učitava u tabelu a za kolonu nije data vrednost, kolona će dobiti onu vrednost koja je definisana kao podrazumevana vrednost za TipRad naše tabele RADNIK kao što sledi:

TipRad CHAR(10) DEFAULT ’neodreñeno’ CHECK ( TipRad IN ( ’odredjeno’,’neodreñeno’,’ugovor’)),

Ako se ubaci slog bez navedene vrednosti za TipRad ,kolona će dobiti podrazumevanu vrednost ’neodreñeno’. Meñutim, neki sistemi nisu dizajnirani za izvoñenje semantičke provere ograničenja i podrazumevanih vrednosti.

Okidači Okidači su specijalizovane procedure koje se izvršavaju pojavom odreñenog dogañaja. To je programski kod koji se izvršava kao odgovor na naredbe za izmenu podataka, kao što su INSERT, UPDATE ili DELETE. Da budemo malo precizniji, okidači su specijalizovane procedure zasnovane na dogañajima koji su smešteni u sistemu i kojima sistem upravlja. Svaki okidač se dodeljuje samo jednoj odreñenoj tabeli. Okidači se mogu zamiliti kao napredni oblik pravila koji se kodira korišćenjem priširene forme SQL-a. Oni se ne mogu direktno pozvati ili izvršiti; oni se automatski izvršavaju ( ili okidaju ) oda strane sistema kao rezultat neke akcije – izmenom podataka u odreñenoj tabeli. Kada se okidač kreira, onse uvek izvršava kada se pojavi „okidajući“ dogañaj ( UPDATE, INSER ili DELETE ). Osim toga, okidači su automatski, implicitni i nezaobilazni. Baza podataka sa definisanim okidačimase naziva aktivna baza podataka zato što jednostavne izmene podataka uzrokuje dodatne akcije koje se izvršavaju –one koje su definisane u kodu okidača. Oni su slični uskladištenim procedurama. I jedni i drugi sadrže proceduralnu logiku koja se smešta u bazi i kojom ona upravlja. Meñutim, uskladištene procedure nisu voñene dogañajimai nisu pridružene ni jednoj tabeli. Okidači su korisni za implementaciju koda koji se mora izvršiti svaki put kad se odreñeni dogañaj pojavi. Okidači se mogu koristiti u mnoge praktične svrhe. Vrlo često je nemoguće isprogramirati poslovno pravilo u bazi podataka korišćenjem DDL-a. Okidači su vrlo fleksibilni i mogu se kodirati za razne svrhe. Na primer, oni mogu:

• Pristupiti drugim tabelama i izmeniti podatke u njima

• Prikazati informativne poruke

• Ozvoditi složena ograničenja

Kako se okidači izvršavaju Okidači se mogu programirati da se startuju na dva različita načina: pre okidajuće aktivnosti ili posle nje. Okidači „pre“ ( before) se izvršavaju pre ne što se okidajući dogañaj pojavi ; okidači „posle“ (after) se izvršavaju nakon završetka okidajućeg dogañaja. Neki sistemi podržavaju oba tipa okidača, dok neki samo jedan. Poznavanje rada okidača u sistemu koji koristite je obavezan. Bez njihovog poznavanja oni se ne mogu ispravno kodirati i održavati.

18

Na primer, prepostavite slučaj gde se okidajući dogañaj pojavljuje pre nego što okidač startuje. Drugim rečima , UPDATE, INSERT ili DELETE se pojavljuju prvi, a kao rezultat tih akcija se izvršava programska logika okidača. Ako je potrebno, okidači mogu poništiti načinjene izmene podataka. A šta ako se okidač startuje pre okidajućeg dogañaja ? U ovakvoj situaciji poništene izmene podataka nije potrebno zato što se okidajući dogañaj još nije desio. Meñutim, mogu se poništiti ostale promene podataka koje su se pojavile pre izvršenja okidača unutar iste transakcije.

Ugnježdeni okidači Kao što smo već načuli , okidači se startuju akcijama INSERT, UPDATE ili DELETE. Meñutim, okidači u sebi mogu sadržati iste te naredbe. To znači da izmene podatakauzrokuju startovanje okidača, koji uzrokuju nove izmene podataka, a one startuju nove okidače. Kada okidač sadrži u sebi naredbe INSERT, UPDATE ili DELETE , kaže se da su to ugnježdeni okidači. Meñutim, mnogi sistemi postavljaju limit broja ugnježdenih okidača koji se mogu izvršiti jednim okidajućim dogañajem. Ako se to ne bi uradilo, vrlo verovatno bi okidači mogli da se startuju u beskonačnosti sve dok se svi podaci ne izbrišu iz baze podataka. Ako se pravila referencijalnog integriteta (RI) kombinuju sa okidačima, mogu se javiti dodatno kaskadno ažuriranje ili brisanje podataka. Ako UPDATE ili DELETE inicira dodatno ažuriranje ili brisanje koja se moraju izvršiti na drugim tabelama, mogu se aktivirati i okidači vezani za UPDATE ili DELETE tih tabela. Ovakva kombinacija okidača i pravila referencijalnih integriteta može uzrokovati višestruke izmene u bazi podataka. Mogućnost kreiranja ugnježdenih okidača obezbeñuje efikasan metod za primenu automatskog održavanja integriteta podataka. Pošto se okidači generalno ne mogu zaobići, oni obezbeñuju elegatni metod prisiljavanja aplikacija da poštuje poslovna pravila.

Korišćenjem okidača za primenu referencijalnog integriteta Jedna od najčešćih upotreba okidača je podrška pravilima referencijalnog integriteta. Okidači se mogu kodirati na mestima deklarativnih pravila referencijalnog integriteta da bi podržali referencijalna ograničenja koja želite postaviti na bazu.

Prelazne promenljive i tabele Da biste uspešno koristili okidače za podršku pravilima referencijalnog integriteta, ponekad je važno da znate vrednosti na koje su iticala izvršena pravila. Slog i sve njegove vrednosti su već obrisani zbog toga što se okidač izvršava nakon pojave okidajućeg dogañaja. Svaki SUBP ima različite metode pristupa podacima iz okidača pre i posle izvršene izmene.

19

Svaki okidač ima dve tabele –jednu sa slikom podataka „pre“ i drugi sa slikom podataka „posle“ Njima mogu pristupiti samo okidači. Sybase i Microsoft SQL Server koristi te tabele na sledeći način:

• Kada se pojavi INSERT, table INSERTED sadrži upisane slogove tabele za koju je definisan okidač.

• Kada se pojavi DELETED , tabela DELETED sadrži slogove koji su upravo izbrisani iz tabele za koju je definisan okidač

• Kada se pojavi UPDATE , on se tretira kao DELETE, praćen akcijom INSERT, tako da tabela INSERTED sadži nove vrednosti za slogove koji su upravo ažurirani , a tabela DELETED sadrži stare vrednosti tih slogova ( pre ažuriranja )

Kod Oraclea i DB2 je implementacija polaznih tabela ( ili promenjivih) jednostavnija, i radi na sledeći način:

• Kada se pojavi INSERT, vrednostima koje su dodate se može pristupiti preko promenjive NEW.

• Kada se pojavi DELETE, obrisanim vrednostima se može pristupiti preko promenjive OLD

• Kada se pojave UPDATE , novim podacima se može pristupiti preko promenjive NEW a starim preko OLD

Primer okidača Ponekad analiza dela koda može pomoći u razjašnjenju nekih koncepata. Zbog toga pogledajte sledeći primer ( DB2 ) okidača: CREATE TRIGGER azuriranje_zarade BEFORE UPDATE OF Zarada ON Radnik FOR EACH ROW MODE DB2SQL WHEN ( new.Zarada > ( old.Zarada *1.5)) BEGIN atomic SIGNAL SQLSTATE ’75001’ ( ’Uvećanje zarade prelazi 50%’); END;

20

Ovaj okidač obezbeñuje da vrednost kolone Zarada ne može biti povećana više od 50% za svako pojedinačno ažuriranje.

Osetljivost okidača Zbog toga što je SQL jezik baziran na skupovima podataka, svaka SQL naredba ima uticaj na više slogova. Na primer, jedna naredba DELETE može u stvari obrisati nula, jedan ili više slogova.Prilikom kodiranja okidača morate uzeti u obzir. Samim tim, postoje dva nivoa osetljivosti okidača. Okidači na nivou naredbe se izvršavaju jedamput nakon okidanja, bez obzira na stvari broj slogova koje je izmenjen, dodat ili obrisan. Okidači na nivou sloga se, nakon okidanja, izvršavaju po jednom za svaki slog koji se menja, dodaje ili briše.

Referencijalni integritet Referencijalni integritet je metod obezbeñivanja korektnosti podataka unutar SUBP-a. Obično se radi pojednostavljenja, kaže da je to indetifikacija veza meñu relacionim tabelama. U stvari, on je mnogo više od toga. Meñutim, indetifikacija primarnih i stranih ključeva izmeñu tabela jeste komponenta definisanja referencijalnog integriteta. Referencijalni integritet objedinjuje integritet i mogućnosti korišćenja veza uspostavljanjem pravila koja će upravljati tim vezama. Kombinacija kolona primarnih i stranih ključeva i pravila koja diktiraju kako će se podacima rukovati u tim kolonama početak su procesa razumevanja i korišćenja RI da bi se obezbedile korektne i korisne baze podataka. Pravila referencijalnog integriteta se primenjuju na svaku vezu i odreñuju status kolone stranih ključeva prilikom upisivanja ili ažuriranja , ili zavisnih slogova kada se slog primarnog ključa obriše ili ažurira.. Koncept referencijalnog integriteta se može sažeti u brzoj i jednostavnoj definiciji : on garantuje da su prihvatljive vrednosti uvek u kolonama stranog ključa. Termin „prihvatljive“ se definiše u odnosu na vrednosti u odgovarajućoj koloni primarnog ključa,ili Null. Dva važna termina referencijalnog integriteta su nadreñena tabela („parent table“) i podreñena

tabela („child table“). Za bilo koje zadato referencijalno ograničenje , nadreñena je ona tabela koja sadži primarni ključ, a podreñena tabela je ona koja sadrži strani ključ. Tako, primarni ključ (recimo, Sif0org) postoji u tabeli ORG, a odgovarajući strani ključ istog tipa podataka i dužine, ali ne nužno i u koloni istog imena, postoji u tabeli RADNIK.

ORG

RADNIK

zapošljava

Je_zaposlen_u

Pravilo dodavanja Pravilo dodavanja ( INSERT rule ) kazuje šta će se dogiditi ako pokušavate dodavanje vrednosti u strani ključbez odgovarajuće vrednosti za primarni ključ u nadreñenoj tabeli. Postoje sva aspekta ovog pravila:

21

• Nikada se ne dozvoljava dodavanje sloga u zavisnoj tabeli sa vrednošću stranog ključa koji se ne poklapa sa vrednošću primarnog ključa. Ovo je poznato kao restriktivo pravilo dodavanja

• Da li se strvarne vrednosti moraju biti zadate umesto Null ? Administrator baze podataka mora da za svaku vezu odluči da li se vrednost(i)stranog ključa moraju navesti kada se slog upisuje u tabelu. Da bi to utvrdio, treba da postavi sledeće pitanje: „Da li u poslovnom procesu ima smisla poznavati vrednosti primarnog ključa u nadreñenoj tabeli kada dodajem slog u podreñenoj tabeli.?“

Pravilo ažuriranja Glavna svrha pravila ažuriranja je kontrola izmena u bazi ,kao što je zabrana ažuriranja vrednosti stranog ključa na vrednost koja se ne poklapa sa vrednošću primarnog ključa u nadreñenoj tabeli. Ovo pravilo se može sagledati iz dva ugla: iz perspektive primarnog ključa i perspektive stranog ključa. Perspektiva stranog ključa Kada slogu dodelite vrednosti staranog kluča, bilo prilikom dodeljivanja ili kasnije , morate odlučiti da li se ta vrednost može menjati. Ali, da napomenemo još jednom, to je odreñeno poslovnom definicijom veze i tabela koja su njome spojene. Perspektive primarnog kluča Kada se vrednost primarnog ključa promeni, posto tri načina ožuriranja odgovarajućeg stranog ključa:

• RESTRIKTIVNO AŽURIRANJE (UPDATE RESTRICT) Izmena podataka u kolonama primarnog ključa kada postoji odgovarajući strani ključ nije dozvoljena.

• NEUTRALIZACIJA AŽURIRANJA (UPDATE NEUTRALIZE) Sve vrednosti stranog ključa koje su jednake promenivoj vrednosti primarnog ključa se postavljaju na Null. Naravno,ovo zahteva da Null bude dozvoljen za kolone stranog ključa.

• KASKADNO AŽURIRANJE (UPDATE CASCADE) Sve vrednosti stranog ključa koje su jednake promenjivoj vrednosti primarnog ključa ažuriraju se na novu vrednost primarnog ključa.

Pravilo brisanja Pravilo referencijalnog integriteta za brisanje definiše šta se dešava kada se pokuša brisanje sloga iz neodreñene tabele. Slično perspektivi primarnog ključa za ažuriranje za ažuriranje, postoje tri opcije kada se briše slog iz nadreñene tabele:

• RESTRIKTIVNO BRISANJE (DELETE RESTRICT) Brisanje sloga primarnog ključa nije dozvoljeno ako postoje iste vrednosti stranog ključa.

• NEUTRALIZACIJA BRISANJA (DELETE NEUTRALIZE) Sve vrednosti stranog ključa jednake primarnom ključu se postavljaju na Null kada se primarni ključ obriše.

• KASKADNO BRISANJE (DELETE CASCADE) Svi slogovi sa vrednošću stranog ključa jednakom primarnom ključu brišu se zajedno sa slogovima primarnog ključa.

Uslovno brisanje Ovo je poslednji tip referencijalnog ograničenja. Ovaj specijalni slučaj se odnosi na rukovanje slogovima u nadreñenoj tabeli kada u podreñenoj tabeli ne postoje slogovi sa odgovarajućom

22

vrednošću stranog ključa. Uslovljeno brisanje nalaže da se slog u nadreñenoj tabeli obriše nakon što se obriše poslednja vrednost stranog ključa za odreñeni primarni ključ. Pogledajte tabelu 13.1. za sumarne karakteristike referencijalnog integriteta i pravila koja se primenjuju u aplikacijama koje ih održavaju.

Tabela 5.1: Pravila referencijalnog integriteta

Restriktivno brisanje Ako postoje slogovi u podreñenoj tabeli, slog primarnog ključa u

nadreñenoj tabeli se ne može brisati Kaskadno brisanje Ako postoje slogovi u podreñenoj tabeli , slog primarnog ključa se

briše, kao i svi zavisni slogovi u podreñenoj tabeli. Neutralizacija brisanja Ako postoje slogovi u podreñenoj tabeli, slog primarnog ključa se

briše, a kolone stranih ključeva za sve zavisne slogove se postavljaju na Null

Restriktivno ažuriranje Ako potoje slogovi u podreñenoj tabeli, kolone primarnog ključa nadreñene tabele se ne mogu ažurirati.

Kaskadno ažuriranje Ako postoje slogovi u podreñenoj tabeli , kolone primarnog ključa nadreñene tabele se ažuriraju, a sve vrednosti stranog ključa u podreñenoj tabeli se ažuriraju na istu vrednost.

Neutralizacija ažuriranja Ako postoje slogovi u podreñenoj tabeli, kolone primarnog ključa nadreñene tabele se ažuriraju, a sve vrednosti stranog ključa u podreñenoj tabeli se postavljaju na Null.

Restriktivno upisivanje vrednost stranog ključa se ne može upisati u podreñenu tabelu sve dok ta vrednost primarnog ključa ne postoji u nadreñenoj tabeli.

Postavljanje relacija Deklarativno referencijalno ograničenje se dodaje kodiranjem primarnog ključa u nadreñenoj tabeli i jednog od stranih ključeva u podreñenim tabelama. Ograničenja se mogu zadati korišćenjem naredbi CREATE TABLE i AFTER TABLE. Kada primenjujemo deklarativni referencijalni integritet izmeñu nadreñene i podreñene tabele, moraju se poštovati odreñena pravila. Za nadreñenu tabelu :

• Mora se definisati primarni ključ u naredbama CREATE TABLE ili ALTER TABLE.

• SQL Server automatski definiše jedinstveni grupisani indeks za primarni ključ kada se on pojavi u naredbama CREATE TABLE ili ALTER TABLE. Ostali SUBP, na primer DB2 zahtevaju da administrator baze podataka ručno kreira jedinstveni indeks da bi podržao primarni ključ

Za podreñenu tabelu

• Strani ključ koji se odnosi na neodreñenu tabelu se mora definisati u naredbama CREATE TABLE ili ALTER TABLE.

• Iako obično nije potrebno , vrlo je preporučljivo da se kreira indeks i za strane ključeve. On neće biti jedinstven sve dok ne definiše vezu jedan-prema-jedan za njega.

23

Ostala pitanja primene referencijalnog integriteta Ponekad se referencijalni integritet mora definisati nad jednom tabelom. Na primer, tabela organizacionih jedinica firme možda mora obezbediti informacije o tome koja jedinica je podreñena drugoj. Kolona Nadreñena_Sif0rg može biti strani ključ primarnog ključa Sif0rg-i sve to unutar jedne tabele. Tabela je sposobna da ukazuje sama na sebe u deklarativnom referencijalnom ograničenju. To se naziva referencijalno ograničenje prema sebi. Zadata ograničenja se proveravaju pre nego što se okidači izvrše. Ako deklarativna ograničenja referencijalnog integriteta postoje nad istim tabelama, pazite da su kompatibilna jedna prema drugima.

Podrška SUBP-a referencijalnom integritetu Imajte na umu da različiti sistemi podržavaju različite nivoe deklarativnog referencijalnog integriteta i različite opcije za njegovo korišćenje. Administrator baze podataka mora znati koje opcije su podržane od strane sistema da bi ukazao programerima aplikacija na to šta je podržano od strane sistema , a šta mora kodirati u aplikaciji.

Korišćenje okidača za održavanje referencijalnog integriteta Ako SUBP koji koristite ne podržavaju dovoljno opcija deklarativnog referencijalnog integriteta koji se zahteva, umesto njega se moraju kreirati okidači. Korišćenjem okidača moguće je podržati sva poslovna pravila referencijalnog integriteta. Naravno, njihovo korišćenje zahteva pisanje proceduralnog koda za svako pravilo svakog ograničenja . Kompletan referencijalni integritet se može podržati sa četiri tipa okidača za svako ograničenje:

1. DELETE okidač se može koristiti za kodiranje

• Restriktivnog brisanja,

• Kaskadnog brisanja

• Neutralizacije brisanja. 2. UPDATE okidačse može koristiti za kodiranje

• Restriktivnog ažuriranja

• Kaskadnog ažuriranja

• Neutralizacije ažuriranja 3. INSERT OKIDAČ se može koristiti u podreñenoj tabeli za kodiranje

• Restriktivnog dodavanja 4. UPDATE okidači se može koristiti na podreñenoj tabeli da zabrani ažuriranje stranog

ključa na vrednost koja ne postoji u koloni primarnog ključa nadreñene tabele. Ugnježdeni i rekurzivni okidači se zaista mogu koristiti za robusnu implementaciju referencijalnog integriteta. Osim toga, okidači mogu biti i jedini automatski metod za implementaciju integriteta kojom upravlja sam sistem, pod odreñenim okolnostima:

• Kada se obrisanim, ažuriranim ili dodatnim informacijama treba pristupiti da bi se na osnovu toga odredila dalja akcija. Okidači obezbeñuju metode za to,

• Kada je potrebna primena referencijalnog integriteta koji nije podržan od strane sistema. Na primer, Sybase podržava samo deklarativni referencijalni integritet restriktivnog brisanja i restriktivnog ažuriranja; DB2 podržava restriktivno brisanje, restriktivno

24

ažuriranje, neutralizaciju brisanja i ažuriranja, kaskadno brisanje ,ali ne i kaskadno ažuriranje.

• Kada se zahteva uslovljeno brisanje .To se ponekad i naziva „reverzni“ referencijalni integritet, a podrazumeva da se nadreñeni slog mora obriati kada se poslednji zavisni slog iz podreñene tabele obriše.

Pogledajmo neke primere okidača da bisno razjasnili kako se pravilno koriste prelazne tabele i promenjive. Sledeći ( SQL Server ) okidač obezbeñuje pravila kaskadnog brisanja: CREATE TRIGGER brisanje_naslova ON Naslovi FOR DELETE AS IF @@ROWCOUNT=0 RETURN DELETE AutorNaslova FROM AutorNaslova, Deleted, Naslov WHERE Naslov.ID_Naslov=Deleted.ID_Naslova RETURN Kada se slog u nadreñenoj tabeli ( Naslov ) obriše, kaskadno se brišu slogovi u podreñenoj tabeli ( AutorNaslova). Drugi primer pokazuje pravilo restriktivnog upisivanja. Kada se upiše slog u podreñenu tabelu ( AutorNaslova ), prvo se mora proveriti da li ta vrednost postoji kao primarni ključ u nadreñenoj tabeli ( Naslov ): CREATE TRIGGER upis_naslova ON AutorNaslova FOR INSERT AS DECLARE @rc int SELECT @rc = @@rowcount IF @rc=0 RETURN IF ( SELECT count (*) FROM Naslov, Inserted WHERE Naslov.Id_Naslov=Inserted.ID_Naslova) != @rc BEGIN RAISERROR 20001 “Neispravan naslov:ID_Naslova ne postoji u tabeli Naslovi !” ROLLBACK TRANSACTION RETURN END RETURN Poslednji primer ( SQL Server ) prikazuje neutralizaciju ažuriranja:

25

CREATE TRIGGER Naslov_Azurir ON Naslovi FOR UPDATE AS IF UPDATE ( ID_Naslovi ) IF (SELECT count (*) FROM Deleted, Naslov WHERE Deleted.ID_Naslova =Naslov.ID_Naslova)=0 BEGIN UPDATE AutorNaslova SET AutorNaslova.IDNaslova=Null FROM AutorNaslova, Deleted WHERE AutorNaslova.ID_Naslova=Deleted.ID_Naslova END RETURN.