BAZA PODATAKA DISTRIBUIRANE BAZE PODATAKA

 

 

Distribuirane baze podataka i distribuirana obrada

 

Motivi za pojavu koncepcije distribuiranih baza podataka i distribuirane obrade podataka su, jednim dijelom, isti kao i motivi koji su doveli do pojave klijent-server arhitek­ture i klijent-server modela obrade podataka, mada su se koncepti distribuiranih baza poda­taka pojavili desetak godina ranije.

S jedne strane, postojao je jedan "jaki" računar, na kojem su se nalazili sistem za upravljanje podacima, sami podaci, kao i aplikacije, a koji je morao opsluživati veliki broj krajnjih korisnika, što je određivalo da informacioni sistem, u tehnološkom smislu, funkcioniše u dominantno centralizovanom okruženju. S druge strane, postoji ne mali broj institu­cija za koje se razvijaju informacioni sistemi, čija je bitna odrednica da funkcionišu u lokacijski "razuđenom" okruženju, počev od toga da poslovanje takve institucije pokriva jedan manji region, do toga da ono pokriva nekoliko različitih država, ili se proteže na različite kontinente. Priroda organizacije centralizovanog informacionog sistema je suprotna prirodi poslovanja realnog sistema koji obuhvata širi geografski prostor. "Zaoštravanje" između ovih suprotnosti se poslednjih godina izrazito inteziviralo. Uzrok tome je, u osnovi, globalizacija svjetskog tržišta, koja je dovela do potrebe intenzivnog komuniciranja i razmene in­formacija, koje je potrebno dostaviti ili preuzeti za vrlo kratko vreme. "Odziv" koji bi dali centralizovani informacioni sistemi, u smislu zadovoljenja korisničkih zahtjeva, ili bi ostao isti kao prije nekoliko godina, ili bi najverovatnije bio i lošiji. Zato centralizovani informaci­oni sistemi ne mogu na pravi način da odgovore potrebama savremenog poslovanja. Izolovana primjena klijent-server modela obrade podataka, o kojem je bilo reči u glavi 14, u opštem slučaju, takođe, ne bi mogla odgovoriti potrebama geografski razuđenog poslova­nja, koje podrazumjeva da podaci nastaju i koriste se simultano na više međusobno udaljenih lokacija. To znači da arhitektura informacionog sistema, koja sadrži samo jedan server baze podataka, vjerovatno ne predstavlja zadovoljavajuće rješenje u takvim situacijama.

 

 

1.1.Koncepcija distribuiranih baza podataka i distribuirane obrade podataka

 

 

Definicija 1.1. Distribuirana baza podataka predstavlja takvu bazu podataka u kojoj su podaci fizički smješteni na najmanje dva servera baze podataka.

 

Pojam servera baze podataka, koji se koristi u prethodnoj definiciji, kao i pojmovi aplikacionog servera i klijenta, koji će u ovom tekstu takođe biti korišćeni, uvedeni su u okviru glave 14, odnosno tačke 14.2.2.

Posljedice navedene definicije distribuirane baze podataka su sljedeće.

·       Bez obzira što su dijelovi distribuirane baze podataka fizički raspodjeljeni na više servera, riječ je o jednoj bazi podataka, što znači da ona, u logičkom smislu, mora predstavljati jedinstvenu cjelinu.

·       Preduslov za formiranje i korišćenje distribuirane baze podataka je da svi serveri baze podataka, koji participiraju u distribuciji, moraju biti povezani komunikacionom mre­žom, na barem trećem nivou referentne ISO/OSI arhitekture mreže.

 

Definicija 1.2. Obrada podataka nad distribuiranom bazom podataka, pri čemu se zadaci logike obrade podataka i upravljanja obradom podataka mogu, u opštem slučaju, raspodjeliti na sve servere koji participiraju u distribuciji, predstavlja distribuiranu obradu podataka.

 

Na osnovu ove definicije, proizilazi da obrada podataka, kod koje su djelovi baze podataka smješteni na više različitih računara, ili različitih memorijskih uređaja, pri čemu je sama obrada podataka uvijek centralizovana, odnosno nije moguće izvršiti distribuciju zada­taka logike obrade i upravljanja obradom, ne predstavlja distribuiranu obradu. U tom slu­čaju, ni tako organizovana baza podataka se ne može smatrati distribuiranom bazom poda­taka.

Informacioni sistemi koji podržavaju distribuiranu obradu podataka, nad distribui­ranom bazom podataka se, takođe, mogu nazvati distribuiranim informacionim sistemima. Da bi takvi informacioni sistemi mogli uspješno da funkcionišu, potrebno je da svi serveri baze podataka, aplikacioni serveri, klijenti, terminali i ostali ulazno/izlazni uređaji neophodni za funkcionisanje informacionog sistema, budu povezani sistemom komunika­cionih mreža. Povezivanje hardverskih komponenti informacionog sistema u jedinstveni komunikacioni sistem je bitan preduslov za ispunjenje zahteva da svaki korisnik, nezavisno od lokacije na kojoj se nalazi, može u zadovoljavajuće kratkom vremenu dobiti odgovor na postavljeni informacioni zahtev. Pri tome se, svakako, misli samo na one informacione zahtjeve koji su, u procesu razvoja informacionog sistema, blagovremeno identifikovani i podržani odgovarajućim aplikacijama.

Glavni razlog za izgradnju distribuiranog informacionog sistema i distribuirane baze podataka je da se na odgovarajući način obezbjedi podrška informacionih zahtjeva ko­risnika realnog sistema, čije poslovanje obuhvata šire geografsko područje. Očekuje se, da će u takvoj situaciji, distribuirani informacioni sistem, u odnosu na centralizovani informacioni sistem posjedovati:

·       višu raspoloživost, u smislu da će sistem, u vremenu kada je to potrebno, biti u stanju da odgovori na predviđene informacione zahtjeve korisnika,

·       bolje performanse, u smislu kraćeg "odziva" sistema na predviđene informacione zahteve korisnika i

·       bolje preduslove za obezbeđenje integriteta baze podataka.

Viša raspoloživost se može očekivati zbog toga što kod centralizovanih informaci­onih sistema, otkaz centralnog računara, koji je, najčešće, u isto vrijeme i server baze podata­ka i aplikacioni server, znači otkaz cijelog informacionog sistema, dok kod distribuiranog sistema, otkaz jednog servera, u krajnjoj liniji, ne smije uticati na prestanak funkcionisanja ostalih servera u sistemu.

Bolje performanse se mogu očekivati zbog činjenice da se, u distribuiranom siste­mu, očekuje da je hardverska konfiguracija sistema mnogo bolje prilagođena potrebama korisnika i njihovoj raspodjeli po lokacijama, nego što je to slučaj u centralizovanom siste­mu. Naravno, pri tome se pretpostavlja da su hardverska konfiguracija i komunikaciona infrastruktura, u cjelini, isprojektovane i realizovane tako da mogu, na odgovarajući način, podržati distribuiranu obradu podataka.

Bolji preduslovi za obezbjeđenje integriteta baze podataka se odnose na činjenicu da centralizovani informacioni sistemi, zbog svoje potencijalne neprilagođenosti potrebama korisnika, često teže dezintegraciji i raspadu na nepovezane komponente, a u tom slučaju se ne može garantovati očuvanje integriteta baze poda­taka, dok kod distribuiranih informacionih sistema postoji više mogućnosti da se tendencije ka dezintegraciji sistema eliminišu, ili bar svedu na minimum.

Na današnjem nivou razvoja, primjena koncepcije distribuiranih baza podataka i distribuiranih informacionih sistema zahtjeva da se za realizaciju takvog informacionog sis­tema:

·       predvidi upotreba sistema za upravljanje bazama podataka koji u potpunosti podržava izgradnju i korišćenje distribuiranih baza podataka,

·       u okviru metodologije projektovanja i realizacije informacionog sistema, predvidi izvo­đenje aktivnosti projektovanja distribucije sistema, koje uopšte ne postoje u slučaju raz­voja centralizovanih sistema i

·       sprovedu organizaciono-tehničke mjere, koje će obezbjediti uspješno uvođenje u upotrebu, eksploataciju i održavanje distribuiranog informacionog sistema.

U okviru ove glave, nešto kasnije, biće posvećeno više pažnje prvim dvjema tačkama.

Distribuirana baza podataka, u opštem slučaju, može biti organizovana kao homo­gena ili kao heterogena. Karakteristika homogene distribuirane baze podataka je ta da je, pri njenoj realizaciji, upotrebljen samo jedan sistem za upravljanje bazama podataka. Dist­ribuirana baza podataka se smatra heterogenom ako je za njenu podršku upotrebljeno naj­manje dva različita sistema za upravljanje bazama podataka.

 

Koncepcija distribuirane baze podataka dovodi do pojma lokalnog i globalnog nivoa upotrebe podataka. Pri tome, definišu se pojmovi lokalne i globalne transakcije, lo­kalnog i globalnog upita, lokalnog i globalnog ažuriranja baze podataka i lokalnog i global­nog korisnika.

·       Lokalna transakcija je transakcija koja se u potpunosti izvršava nad dijelom baze podata­ka koji je smješten na tačno jedan server baze podataka, u okviru sesije koja je otvorena na tom serveru baze podataka.

·       Globalna (distribuirana) transakcija je transakcija koja se izvršava nad dijelovima baze podataka, smještenim na najmanje dva servera baze podataka.

·       Lokalni upit je upit koji se realizuje putem lokalne transakcije.

·       Globalni (distribuirani) upit je upit koji se realizuje putem globalne transakcije.

·       Lokalno ažuriranje dijela baze podataka je ažuriranje koje se sprovodi putem lokalne transakcije.

·       Globalno (distribuirano) ažuriranje dijela baze podataka je ažuriranje koje se sprovodi putem globalne transakcije.

·       Lokalni korisnik je korisnik baze podataka koji sve svoje korisničke zahtjeve nad bazom podataka realizuje samo putem lokalnih transakcija.

·       Globalni korisnik je korisnik baze podataka koji, za realizaciju svojih korisničkih zahtjeva nad bazom podataka, koristi barem jednu globalnu transakciju.

 

Primjer 1.1. Na slici 1.1 je prikazana jedna moguća arhitektura sistema za dis­tribuiranu obradu podataka, opšteg karaktera. Elementi te arhitekture su globalna mreža G1, lokalne mreže L1 i L2, dva servera baze podataka (S1 i S3), dva aplikaciona servera (S4 i S5), računar koji je, istovremeno, i aplikacioni i server baze podataka (S2), veći broj računara u funkciji klijenta, kao i terminala. Na serverima S1, S2 i S3 se nalazi instaliran sistem za upravljanje bazom podataka koji omogućava distribuiranu obradu podataka.

 

 

 

Slika 1.1.

 

 

Treba naglasiti da se, kao sastavni dio komunikacionih mreža G1, L1 i L2, u prin­cipu, u sistemu pojavljuju i drugi računari, a ne samo oni koji su prikazani na slici 15.1. To mogu biti, na primjer, računari koji imaju ulogu komunikacionih servera u računarskoj mreži. Preko takvih računara i terminali T1 i udaljeni terminali U1 ostvaruju vezu s ostat­kom sistema. Pošto je reč o računarima koji ne participiraju direktno u distribuiranoj obradi podataka, jer nemaju ni jednu od sljedećih uloga: server baze podataka, server aplikacija, klijent, ili emulator terminala, oni na slici 15.1 nisu ni prikazani.

Pretpostavlja se da je ovom, zamišljenom arhitekturom, obezbjeđeno da korisnici koji upotrebljavaju klijente K1, udaljene terminale U1, ili terminale T1, mogu koristiti us­luge aplikacija, instaliranih na serverima S2 i S4, kao i da mogu otvarati nove sesije na serveru S1, S2 ili S3. Nadalje, korisnici terminala T2 mogu pokretati aplikacije, ili otvarati sesije na serveru S2, dok korisnici klijenata K2 mogu pokretati aplikacije na serveru S4. Korisnici klijenata K3 mogu pokretati aplikacije na serveru S5, ili otvarati sesije na serveru S3.

 

Predviđeno je da bilo koja globalna transakcija, pokrenuta na bilo kom serveru baze podataka može, po potrebi, zatražiti usluge ostalih servera baze podataka u sistemu, u cilju realizacije upita ili sprovođenja ažuriranja. Na taj način, svaki korisnik ovog sistema se može pojaviti bilo u ulozi globalnog ili u ulozi lokalnog korisnika.

 

Na slici 1.2 je prikazan globalni pogled na arhitekturu distribuiranog sistema sa slike 1.1, kojim se sasvim zanemaruju detalji vezani za mrežnu arhitekturu sistema. Njime se ilustruje činjenica da je sve resurse sistema moguće, po potrebi, staviti na raspolaganje svakom krajnjem korisniku. Krajnji korisnici distribuiranog informacionog sistema, u prin­cipu, ne treba da poznaju njegovu arhitekturu. Isto tako, ni programer aplikacija informaci­onog sistema ne treba da poznaje način distribucije baze podataka po serverima, već aplikacije treba da funkcionišu nezavisno od toga kako je izvršena distribucija baze podata­ka.

 

 

Slika 1.2.

 

 

Prethodnim primjerom je ilustrovana osobina po kojoj arhitektura jednog distribui­ranog informacionog sistema mora omogućiti realizaciju bilo kog, unapred predviđenog, informacionog zahtjeva, nezavisno od lokacije korisnika koji taj zahtjev pokreće. Ova osobi­na se naziva distribuciona nezavisnost ili distribuciona transparentnost baze podataka, odnosno informacionog sistema. Distribuciona nezavisnost traži da sve aplikacije informa­cionog sistema budu nezavisne od distribucije podataka po serverima, što znači da izmjene u načinu distribuiranja podataka po serverima ne smiju uticati na rad aplikacija. Isto tako, svaki korisnik sistema mora biti u mogućnosti da s bilo koje, unapred predviđene lokacije, može pokrenuti aplikaciju koja mu je neophodna za realizaciju njegovog informacionog zahtjeva.

Uvođenje koncepta distribuirane baze podataka, dovodi i do uvođenja koncepta replikacije podataka. Replikacija podataka ("ponavljanje", "multipliciranje") predstavlja postupak namjernog uvođenja kontrolisane redundanse u bazu podataka, smještanjem istih podataka na najmanje dva servera baze podataka. Replikacija podataka se sprovodi u cilju povišenja stepena raspoloživosti podataka i obezbeđenja zadovoljavajućih performansi rada informacionog sistema.

U nastavku ove glave, biće posvećena dodatna pažnja sistemima za upravljanje bazama podataka koji podržavaju koncept distribuirane baze podataka i replikacije, kao i nekim aktivnostima projektovanja distribuirane baze podataka.

 

 

 

1.2.Distribuirani sistemi za upravljanje bazama podataka

 

Zadatak distribuiranog sistema za upravljanje bazom podataka (SUBP) jeste da omogući izgradnju, kao i efikasno korišćenje i ažuriranje distribuiranih baza podataka. Dis­tribuirani sistem za upravljanje bazama podataka treba da ima sve opšte karakteristike jed­nog SUBP. Opštim karakteristikama sistema za upravljanje bazama podataka je posvećeno posebno poglavlje u [ML].

Kao i bilo koji drugi SUBP i distribuirani SUBP mora posjedovati jezik za definisanje strukture i uslova integriteta baze podataka i jezik za manipulisanje podacima. Pri tome, jezik za definisanje strukture baze podataka mora biti proširen elementima koji omo­gućavaju opis distribucije šeme baze podataka i replikacije podataka po serverima. Jezik za manipulisanje podacima mora, takođe, biti proširen elementima koji omogućavaju simulta­no korišćenje i ažuriranje podataka, distribuiranih na različite servere baze podataka.

Opšti zahtjevi koje SUBP treba da ispuni i za koje SUBP posjeduje posebne meha­nizme, a koji se odnose na:

·       upravljanje transakcijama,

·       očuvanje konzistentnosti baze podataka u višekorisničkom režimu rada,

·       zaštitu od neovlašćenog pristupa podacima od strane korisnika,

·       zaštitu baze podataka od uništenja i

·       obezbjeđenje efikasnog korišćenja baze podataka,

·       treba, svakako, da ispuni i distribuirani SUBP. Ispunjenje ovih zahtjeva u distribuiranom okruženju, međutim, postaje znatno složenije, tako da i odgovarajući mehanizmi koje dis­tribuirani SUBP treba da posjeduje, postaju složeniji. U nastavku ove tačke će biti više pažnje posvećeno mehanizmima za upravljanje transakcijama i očuvanje konzistentnosti baze podataka u višekorisničkom režimu rada, u distribuiranom okruženju, bez namjere da se umanji važnost ostalih nabrojanih zahtjeva.

Pored opštih zahtjeva koje treba da zadovolji bilo koji SUBP, distribuirani SUBP treba da zadovolji i zahtjev za mogućnošću upravljanja distribuiranim djelovima baze poda­taka uz obezbjeđenje distribucione nezavisnosti. To znači da, kada su u pitanju mehanizmi za upravljanje transakcijama, distribuirani SUBP mora da omogući referenciranje dijelova baze podataka koji su smješteni na različitim serverima, u okviru jedne globalne transakcije. Kada je u pitanju očuvanje konzistentnosti baze podataka u višekorisničkom režimu rada, distribuirani SUBP mora omogućiti:

·       jedinstveno potvrđivanje ili poništavanje celokupne globalne transakcije,

·       automatsko ažuriranje svih kopija repliciranih dielova baze podataka i

·       očuvanje integriteta baze podataka pri automatskom ažuriranju svih kopija repliciranih podataka.

Dodatni zahtjev, koji distribuirani SUBP treba da podrži, predstavlja obezbjeđenje što višeg stepena robusnosti pri radu sistema, što znači da privremeni prestanak funkcionisanja jednog servera treba što manje da utiče, ili čak uopšte da ne utiče na operativnost "ostatka" sistema. Ovaj zahtjev je, međutim, u koliziji sa prethodno pobrojanim zahtjevima, koji se odnose na obezbjeđenje konzistentnosti baze podataka.

 

Rječnik podataka predstavlja bazu podataka samog sistema za upravljanje bazom podataka. Rječnik podataka distribuiranog sistema za upravljanje bazama podataka može, kao i sama baza podataka, biti, u određenoj mjeri, distribuiran, a njegovi dijelovi replicirani na više servera. Stepen distribucije rječnika podataka definiše i stepen autonomnosti servera baze podataka u sistemu. Rječnik podataka može, u opštem slučaju biti organizovan kao:

·       potpuno centralizovan rječnik, ukoliko je njegov kompletan sadržaj smješten samo na jedan server baze podataka u sistemu,

·       potpuno autonomni rečnik, ukoliko se na svakom serveru baze podataka održava samo lokalni rječnik podataka i

·       replicirani rječnik, ukoliko se na svakom serveru baze podataka održava lokalni rječnik podataka, a dijelovi rječnika koji se tiču informacija o distribuiciji i replikaciji same baze podataka, takođe se repliciraju na druge (samo neke li sve) servere baze podataka.

SUBP koji je organizovan nad potpuno centralizovanim rječnikom podataka obezbjeđuje vrlo nizak stepen autonomnosti servera, jer je koordinacija aktivnosti sistema za upravljanje bazama podataka centralizovana. Otkazom servera na kojem je instaliran rječnik podataka dolazi i do otkaza sistema u cjelini. Može se očekivati da je ovakav SUBP jeftiniji i jednostavniji kada je u pitanju administriranje sistemom tokom eksploatacije i održavanja, ali se, generalno, ne može smatrati povoljnim rješenjem sa stanovišta zahtjeva koje postavlja distribuirana logika obrade podataka.

SUBP koji je organizovan nad potpuno autonomnim rječnikom, ili repliciranim rječnikom, obezbeđuje visok stepen autonomnosti servera, jer otkaz jednog servera ne dovo­di do otkaza kompletnog sistema, već postoje osnove da "ostatak" sistema zadrži dio funk­cionalnosti. Nedostatak sistema koji funkcioniše nad potpuno autonomnim rječnikom jeste u tome što je, prilikom izvođenja svake distribuirane transakcije, neophodno čitati podatke o distribuciji i replikaciji iz lokalnih rječnika svih servera baze podataka koji učestvuju u iz­vođenju transakcije. To može značajno povećati intenzitet transporta podataka kroz komu­nikacionu mrežu. S druge strane, sistem koji funkcioniše nad repliciranim rječnikom obezbeđuje da se svi potrebni podaci o distribuciji i replikaciji, ili bar većina tih podataka, pri izvođenju transakcije, pronađu u lokalnom rečniku podataka, što bitno poboljšava per­formanse rada sistema. Pri tome, usložnjava se postupak ažuriranja repliciranih delova reč­nika podataka, do kojeg dolazi prilikom implementacije šeme distribuirane baze podataka, korišćenjem jezika za definiciju podataka. Ipak, promjene u šemi baze podataka nisu tako česte kao što je samo ažuriranje podataka u bazi, tako da se može smatrati daje izbor siste­ma za upravljanje bazama podataka koji radi nad repliciranim rječnikom najefikasnije rješenje.

 

1.2.1.   Distribucija podataka i distribuciona transparentnost

 

U cilju implementacije distribuirane baze podataka, na svakom serveru baze po­dataka koji treba da participira u distribuciji, neophodno je da bude instaliran distribuirani SUBP. Time je omogućeno da se na svakom serveru, uz pomoć uobičajenih tehnika, im­plementira potrebni dio šeme baze podataka. Pošto dijelovi šeme baze podataka, koji su im­plementirani na više servera, treba da sačinjavaju jedinstvenu cjelinu, kao prvo, postavlja se uslov da svaki objekat šeme baze podataka (npr. tabela, procedura, itd) ima jedinstven naziv na nivou cjelokupne šeme baze podataka, a ne samo na nivou onog dijela koji je instaliran na lokalnom serveru.

 

Problem imenovanja objekata se, u principu, rješava tako što svaki naziv automatski dobija prefiks ili sufiks, koji uključuje naziv servera baze podataka na kojem je objekat implementiran. Na taj način, formiraju se globalni nazivi objekata.

 

 

Primjer 1.2. Posmatra se distribuirani informacioni sistem jedne banke koja je tako organizovana da, osim centrale, sadrži određeni broj filijala, a svaka filijala sadrži određeni broj ekspozitura. Neka je predviđeno da se u centrali, svakoj filijali i svakoj eks­pozituri nalazi po jedan server distribuirane baze podataka. Neka je naziv servera u filijali oblika Fk, gdje je k redni broj filijale, a u ekspozituri oblika En, gdje je n redni broj ekspo­ziture u okviru date filijale. Naziv servera u centrali neka bude C.

 

Pretpostavlja se da je za realizaciju distribuirane baze podataka izabran SUBP ORACLE V.8.*, koji je instaliran na svakom serveru baze podataka. Neka je lokalni naziv kreirane baze podataka na svakom serveru IISB, što znači da je i vrijednost parametra inicijalizacije sistema DB_NAME za svaki server ista: DB_NAME = IISB. U cilju obezbjeđenja jedinstvenosti naziva, prilikom uspostavljanja konfiguracije sistema, za svaki server se definiše različita vrijednost parametra inicijalizacije DB_DOMAIN, koji predstavlja naziv servera. Tako, na primjer, za server C će biti zadato DB_DOMAIN = C.BAN, za prvu filijalu će biti DB_DOMAIN = F1.BAN, a za prvu ekspozituru u prvoj filijali će biti DB_DOMAIN- E1.F1.BAN. Sufiks BAN, u ovom slučaju, ima za cilj da naglasi da svi serveri pripadaju jedinstvenoj internoj mreži banke. Prema navedenoj šemi imenovanja, globalni naziv baze podataka na serveru E1.F1.BAN će imati oblik IISB.E1.F1.BAN. Globalni nazivi svih objekata rečnika ovog dijela baze podataka će, takođe, biti formirani dodavanjem sufiksa IISB.E1.F1.BAN na osnovni (lokalni) naziv objekta.

 

Kao što je već rečeno, distribuirani SUBP treba da posjeduje mehanizme za korišćenje i ažuriranje podataka, smještenih na različite servere, u okviru iste transakcije. Ako je riječ o relacionom SUBP, zahtjev je da se podacima sa različitih servera može manipulisati putem jedne SQL naredbe, pri čemu se objekti distribuiranih dijelova šeme baze podataka moraju referencirati putem svojih globalnih naziva. Pri tome, SUBP mora biti u mogućnosti da, putem svojih mehanizama, pronađe u rječniku objekte, referencirane putem globalnih naziva.

 

Primjer 1.3. Posmatra se konfiguracija distribuiranog informacionog sistema iz primjera 1.2. Neka je u lokalnoj šemi baze podataka IISB.F1.BAN predviđeno postojanje šeme relacije Ugovor({UGGOD, UGIDB, UGDAT, PPIDB}, {UGGOD+UGIDB}), gdje je UGGOD oznaka poslovne godine, UGIDB broj ugovora, UGDAT  datum formiranja ugovo­ra, a PPIDB identifikacioni broj poslovnog partnera, dok je u lokalnoj šemi baze podataka IISB.C.BAN predviđeno postojanje šeme relacije Posl_Partner({PPIDB, PPNAZ}, {PPIDB}), gde je PPNAZ naziv poslovnog partnera i važi referencijalni integritet Ugovor[PPIDB] Í Posl_Partner[PPIDB].

Korisnik lokalne baze podataka IISB.F1.BAN želi da, nad tabelama Ugovor i Posl_Partner, u okviru svoje sesije, pokrene SQL upit oblika:

 

SELECT    u.UGIDB, u.UGDAT, u.PPIDB, p.PPNAZ

FROM       Ugovor u, Posl_Partner p

WHERE     u.UGGOD = '1999' AND u.PPIDB = p.PPIDB.

 

Pošto tabela Posl_Partner ne postoji u lokalnoj bazi podataka IISB.F1.BAN, ovakav upit neće biti validan, već se tabela Posl_Partner mora referencirati putem svog globalnog imena.

U cilju obezbjeđenja globalnog referenciranja objekata, SUBP ORACLE posjeduje poseban mehanizam, pod nazivom "database link", ili skraćeno "db link". Mehanizam db link-a omogućava upisivanje u rječnik podataka informacije o načinu formiranja i referenci­ranja globalnog imena objekta. Db link se deklariše putem DDL naredbe

CREATE DATABASE LINK <naziv_db_linka>.

 

Detaljan opis ove naredbe izlazi izvan okvira ove knjige. Na ovom mjestu se samo navodi najjednostavniji oblik ove naredbe, neophodan za ilustraciju samog primjera. SQL naredbom definicionog jezika:

CREATE DATABASE LINK IISB.C.BAN

 

obezbjeđuje se upis informacije o serveru baze podataka i lokalnoj bazi podataka IISB.C.BAN u lokalni rječnik podataka. IISB.C.BAN sada predstavlja, istovremeno, i naziv samog db link-a. Naziv db link-a mora, i u opštem slučaju, da odgovara globalnom nazivu lokalne baze podataka. Nakon kreiranja DB link-a IISB.C.BAN, svi objekti ove lokalne baze se, u okviru SQL naredbi, mogu referencirati putem sintaksne konstrukcije:

 

<naziv_objekta>@<naziv_db_linka>.

 

To znači da se prethodna SELECT naredba transformiše u oblik:

 

SELECT    u.UGIDB, u.UGDAT, u.PPIDB, p.PPNAZ

FROM      Ugovor u, Posl_Partner@IISB.C.BAN p

WHERE    u.UGGOD = '1999' AND u.PPIDB = p.PPIDB.

 

Preduslovi za izvršenje ove SQL naredbe su da: server baze podataka C.BAN, server F1.BAN i komunikaciona mreža, koja spaja ova dva servera, moraju biti raspoloživi za upotrebu, u momentu izvršenja naredbe.

 

Naglašeno je, takođe, i to da distribuirani SUBP mora posjedovati mehanizme za obezbjeđenje distribucione transparentnosti podataka. Jedan od mehanizama koji se može iskoristiti i za obezbeđenje distribucione transparentnosti upita, kod relacionih SUBP, jeste mehanizam pogleda, podržan SQL naredbom CREATE VIEW. SUBP ORACLE, pored ovog, posjeduje i mehanizam sinonima, podržan naredbom CREATE SYNONYM za gene­ralno obezbeđenje distribucione transparentnosti podataka. Primjena ova dva mehanizma se ilustruje putem sljedećih primjera.

 

Primjer 1.4. Posmatra se SELECT naredba iz primjera 1.3. Kreiranjem pogleda Ugovor_Poslpart, putem SQL naredbe:

 

CREATE VIEW Ugovor_Poslpart

(UGGOD, UGIDB, UGDAT, PPIDB, PPNAZ)

AS

SELECT  u.UGGOD, u.UGIDB, u.UGDAT, u.PPIDB, p.PPNAZ

FROM    Ugovor u, Posl_Partner@IISB.C.BAN p

WHERE  u.PPIDB = p.PPIDB,

 

posmatrana SELECT naredba se može transformisati u oblik:

 

SELECT    UGIDB, UGDAT, PPIDB, PPNAZ

FROM        Ugovor_Poslpart

WHERE     UGGOD = '1999'.

 

Očigledno je da ovakva SELECT naredba ne zavisi od toga na koji način je izvršena distri­bucija baze podataka po serverima.

 

 

Primjer 1.5. Posmatra se SELECT naredba iz primjera 1.3. Kreira se sinonim pod nazivom Posl_Partner, za tabelu Posl_Partner u lokalnoj bazi IISB.C.BAN, putem SQL naredbe:

 

CREATE SYNONYM Posl_Partner

FOR Posl_Partner@IISB.C.BAN,

 

koja koristi prethodno kreirani db link IISB.C.BAN. Umjesto konstrukcije Posl_Partner@IISB.C.BAN, sada se može koristiti sinonim Posl_Partner pa se pomenuta SELECT naredba transformiše u početni oblik:

SELECT    u.UGIDB, u.UGDAT, u.PPIDB, p.PPNAZ

FROM       Ugovor u, Posl_Partner p      

WHERE     u.UGGOD = '1999' AND u.PPIDB = p.PPIDB.

 

Ovakva SELECT naredba, takođe, ne zavisi od izvršene distribucije baze podataka po serverima.

 

Osim putem sinonima i pogleda, distribuciona transparentnost se može obezbjediti i korišćenjem procedura baze podataka. Naime, distribuirani SUBP mora omogućiti korišćenje naredbi jezika za manipulaciju podacima u okviru procedura baze podataka. Na taj način, programer ili korisnik baze podataka, koristeći samo poziv procedure, ne mora biti svjestan načina distribucije podataka po serverima. Pri tome, moguće je ostvariti poziv udaljene procedure ili poziv lokalne procedure baze podataka. Lokalna procedura je pro­cedura koja se nalazi u lokalnom rječniku podataka onog servera na kojem je otvorena sesija krajnjeg korisnika, dok je udaljena procedura ona procedura koja se nalazi u nekom drugom rečniku podataka.

Pri razvoju informacionog sistema, moguće je kombinovati sva tri mehanizma za obezbjeđenje distribucione transparentnosti podataka.

 

1.2.2.          Upravljanje globalnom transakcijom

 

Distribucija baze podataka po serverima ne smije uticati na logiku izvođenja bilo koje transakcije. To znači da efekat izvođenja transakcije sa stanovišta programera i krajnjeg korisnika mora biti isti, bez obzira da li je primjenjena distribucija baze podataka po serverima, ili ne. Programer ili korisnik, kao i u nedistribuiranom okruženju, ima mo­gućnost da označi uspešan kraj transakcije zahtjevom za njeno potvrđivanje putem SQL naredbe COMMIT, ili da zahtjeva njeno poništavanje, putem naredbe ROLLBACK.

U distribuiranom okruženju, pod pretpostavkom da je obezbjeđena puna distribuciona nezavisnost programa od podataka, projektovanje i programiranje samog transakcionog programa ne bi trebalo da se razlikuju u odnosu na iste aktivnosti, koje se primenjuju pri razvoju centralizovanih informacionih sistema.

 

1.2.2.1.             Izvođenje globalne transakcije

 

Izvođenje globalne transakcije započinje na serveru baze podataka na kojem je otvorena sesija krajnjeg korisnika, putem koje korisnik ostvaruje vezu s bazom podataka. Taj server baze podataka se naziva globalni koordinator transakcije. Globalni koordinator transakcije, po potrebi, zahtjeva uslugu drugih servera baze podataka i čeka na odgovor, a ovi, zatim, po potrebi, zahtjevaju uslugu "trećih" servera baze podataka i čekaju na njihov odgovor, itd. Na taj način, formira se stablo transakcije.

Svaki čvor stabla transakcije predstavlja jedan server baze podataka koji učest­vuje u izvođenju transakcije. Globalni koordinator predstavlja korijen stabla transakcije. Svaki čvor u stablu transakcije, osim korena, direktno je podređen čvoru koji je zahtijevao uslugu od datog čvora. Čvor koji nije list ili korijen u stablu, naziva se lokalni koordinator transakcije, a njegov direktno podređeni čvor se naziva uslužni server. Prema tome, svaki čvor koji ima svog direktnog prethodnika i direktnog sledbenika je, istovremeno, i lokalni koordinator i uslužni server. Listovi stabla su samo uslužni serveri.

Globalni koordinator šalje SQL naredbe i obrađuje odgovore, dobijene nakon izvr­šenja naznačenih SQL naredbi. Uloga globalnog koordinatora je vrlo značajna za postupak završetka transakcije, o čemu će posebno biti riječi u tački 1.2.2.3. Lokalni koordinator, pored toga što je zadužen da prima i prosljeđuje SQL naredbe i odgovore nakon izvršenja tih SQL naredbi, ima zadatak i da prosljeđuje podatke o statusu same transakcije. Uslužni server je samo zadužen da prima SQL naredbe i da šalje odgovore nakon izvršenja tih SQL naredbi, kao i da prima i šalje podatke o statusu transakcije.

 

Primjer 1.6. Posmatra se scenario iz primjera 1.3. Neka je u lokalnoj šemi baze podataka IISB.F2.BAN kreiran db link pod nazivom IISB.F1.BAN, za pristup istoimenoj lokalnoj bazi podataka. Neka jednu transakciju, koja započinje na serveru IISB.F1.BAN, sačinjava sljedeća SQL naredba:

 

SELECT  u.UGIDB, u.UGDAT, u.PPIDB, u.PPNAZ

FROM    Ugovor_Poslpart@IISB.F1.BAN u

WHERE  U.UGGOD = '1999' AND u.UGIDB = 100 AND u.PPIDB = 1100;

 

Stablo ove transakcije je prikazano na slici 1.3. Server IISB.F2.BAN je globalni koordinator transakcije i, zbog realizacije SELECT naredbe transakcije, traži uslugu od servera IISB.F1.BAN. Da bi realizovao prosljeđenu SELECT naredbu, saglasno definiciji pogleda Ugovor_Poslpart, server IISB.F1.BAN traži uslugu servera IISB.C.BAN i, na taj način, postaje lokalni koordinator za ovaj server. IISB.C.BAN postaje uslužni server ove transakcije.

 

 

 

Slika 1.3

 

 

1.2.2.2.  Zaključavanje podataka

 

U cilju obezbjeđenja konzistentnosti podataka u višekorisničkom režimu transakcione obrade podataka, distribuirani SUBP mora, pri izvođenju transakcije, primjenjivati odgovarajuće mehanizme zaključavanja podataka. Princip dvofaznog protokola zaključava­nja resursa, s pravilom da se zaključani resursi mogu osloboditi samo u toku postupka potvrđivanja ili poništavanja transakcije, koji je detaljnije diskutovan u [ML], primjenjuje se i kod distribuiranih SUBP. Na svakom serveru baze podataka pojedinačno, vrši se lokalno zaključavanje podataka, prema zahtjevima transakcije.

Pomenuti princip polazi od činjenice da baza podataka sadrži samo jednu kopiju istih podataka i, u tom slučaju, njegova primjena garantuje očuvanje konzistentnosti podata­ka u višekorisničkom režimu rada, odnosno garantuje očuvanje serijabilnosti redoslijeda i eliminaciju problema gubitka i privremenosti ažuriranja [ML]. Ukoliko se, međutim, nad distribuiranom bazom podataka primjeni tehnika replikacije podataka, polazna pretpostavka navedenog principa zaključavanja, po kojoj baza podataka sadrži samo jednu kopiju istih podataka, više nije ispunjena, tako da ni sam dvofazni protokol zaključavanja, lokalno primjenjen na svakom serveru, nije dovoljan da garantuje konzistentnost podataka u višekoris­ničkom režimu rada. Tehnike očuvanja konzistentnosti podataka u slučaju ažuriranja repli­ciranih dijelova baze podataka će biti, u određenoj mjeri, diskutovane u tački 1.2.3, dok se uticaj transakcije na globalnu konzistenciju baze podataka razmatra u narednoj tački.

 

1.2.2.3.             Potvrđivanje i poništavanje globalne transakcije

 

Kako bi se očuvala konzistentnost podataka u distribuiranom okruženju, svaka globalna transakcija treba da bude globalno potvrđena, ili poništena. To znači da se na svim čvorovima stabla transakcije mora, koordinisano, sprovesti ista akcija: potvrđivanje, ili poništavanje transakcije. Globalni koordinator, pri tome, ima zadatak da:

·       vremenski sinhronizuje postupak završetka globalne transakcije i

·       donese jedinstvenu odluku o načinu njenog završetka.

Svi ostali čvorovi stabla transakcije treba ovu odluku dosljedno da sprovedu, bez mogućno­sti da je, separatno, mijenjaju. Ideja globalnog potvrđivanja transakcije jeste da se transakcija može potvrditi samo ako su svi čvorovi u stanju da, lokalno, sprovedu traženu potvrdu tran­sakcije. U protivnom, ako makar jedan čvor stabla transakcije nije u stanju da potvrdi tran­sakciju, ili se programskim putem zahtjeva poništavanje transakcije, tada svi čvorovi moraju sprovesti postupak njenog poništavanja.

Na zahtev globalnog koordinatora, svaki čvor u stablu transakcije sprovodi i svoj, lokalni postupak završetka transakcije. Opšti principi lokalnog postupka završetka transak­cije su opisani u [ML] i, kada je u pitanju distribuirano okruženje, taj postupak trpi neznatne izmjene u samoj logici izvođenja.

Završetak globalne transakcije se odvija prema postupku koji se naziva dvofazni protokol završetka distribuirane transakcije i koji će u daljem tekstu biti opisan. Dvofazni protokol završetka distribuirane transakcije ne treba povezivati s pojmom dvofaznog proto­kola (lokalnog) potvrđivanja transakcije, koji je uveden u prilogu 2, knjige "Principi baza podataka" [ML], jer je riječ o potpuno nezavisnim pojmovima.

Dvofazni protokol završetka distribuirane transakcije definiše dvije faze postupka završetka. To su:

·       faza pripreme završetka i

·       faza realizacije završetka.

Osnovna ideja dvofaznog protokola završetka distribuirane transakcije je da, u fazi pripreme, globalni koordinator šalje poruku svim direktno podređenim čvorovima, da se "pripreme" za završetak transakcije. Ova poruka se prosljeđuje kroz stablo transakcije do svih uslužnih servera. Svaki čvor, na taj način, treba da započne postupak lokalnog završetka transakcije, u okviru kojeg donosi zaključak da li se transakcija lokalno može potvrditi, ili ne. Umesto da čvor i obavi lokalno potvrđivanje ili poništavanje transakcije, on odluku o tome prosljeđuje svom direktno nadređenom čvoru. Nakon što globalni koordinator dobije povratnu informaciju od svojih direktno podređenih čvorova o spremnosti za potvrđivanje, prestaje prva faza i započinje druga faza dvofaznog protokola. Globalni koor­dinator je u mogućnosti da donese odluku o tome da li će se transakcija globalno potvrditi ili poništiti. U ovoj fazi, globalni koordinator šalje komandu kojom zahtjeva potvrđivanje ili poništavanje transakcije od svih servera u stablu transakcije. Serveri stabla transakcije, na­kon što dobiju komandu, sprovode odluku globalnog koordinatora i, nakon toga, izvještavaju o sprovođenju te odluke svoj direktno nadređeni čvor. Kada globalni koordinator dobije informacije od svojih direktno podređenih čvorova o tome da su svi čvorovi izvršili zahtevanu akciju, i sam završava započetu transakciju.

 

Faza pripreme

           

Na početku faze pripreme, globalni koordinator obezbjeđuje bezuslovno zapisiva­nje sadržaja blokova sistemskog dnevnika na disk (vidjeti prilog 2 u [ML]) i upisuje u sis­temski dnevnik slog tipa [priprema_transakcije, T], gde je T oznaka transakcije. Nakon toga, šalje poruku tipa "izvrši pripremu" direktno podređenim čvorovima u stablu transak­cije i aktivira "mjerač vremena", za koji se u daljem tekstu koristi naziv satni mehanizam[1]. Ukoliko globalni koordinator dobije u zadatom intervalu vremena satnog mehanizma odgo­vor od podređenih čvorova, transakcija se nastavlja prema svom scenariju. U protivnom, donosi se odluka o poništavanju transakcije.

Kada čvor dobije poruku tipa "izvrši pripremu", ukoliko je to lokalni koordinator, tada prosljeđuje poruku svojim direktno podređenim čvorovima i čeka odgovor od njih. Čvor, zatim, započinje postupak lokalnog potvrđivanja transakcije. U okviru tog postupka čvor obavlja sljedeće aktivnosti.

·       Provjerava da li je lokalni dio transakcije, u okviru njegovog podstabla, upitnog tipa ili je zahtjevano i ažuriranje podataka.

·       Ako je lokalni dio transakcije upitnog tipa, ostale aktivnosti se preskaču, a direktno nadređenom čvoru se šalje poruka "samo upit". Lokalni dio transakcije dobija status "upitna transakcija". Ako je lokalnim dijelom transakcije zahtjevano ažuriranje podataka, obavljaju se naredne aktivnosti.

·       Analizira uslove za uspješan završetak lokalnog dijela transakcije.

·       Ukoliko su uslovi za uspješan završetak ostvareni, obezbjeđuje bezuslovno zapisivanje sadržaja blokova sistemskog dnevnika na disk i upisivanje u sistemski dnevnik sloga tipa [spremna_transakcija, T], čime lokalni dio transakcije dobija status "spremna transak­cija". Nakon toga, prosljeđuje nadređenom čvoru poruku "spreman" i čeka dalje koman­de od svog koordinatora.

·       Ukoliko uslovi za potvrdu transakcije nisu ostvareni, čvor prosljeđuje svom koordinatoru poruku "prekini", a lokalni deo transakcije dobija status "prekinuta transakcija". U ovom slučaju, postoji mogućnost da se u sistemski dnevnik ne upisuje odgovarajući slog i da se poništavanje lokalnog dijela transakcije samo na tom čvoru dovrši do kraja, uz oslobađa­nje zaključanih resursa.

 

Bilo da globalni koordinator u zadatom intervalu vremena dobije od svih svojih direktno podređenih čvorova odgovor, ili da je zadati interval vremena istekao, nastavlja se postupak završetka transakcije izvođenjem druge faze.

 

 

 

Faza realizacije

 

U ovoj fazi, globalni koordinator prvo odlučuje da li transakciju treba globalno potvrditi ili poništiti. Odluka o potvrdi transakcije se donosi samo ako su u zadatom inter­valu vremena svi direktno podređeni čvorovi globalnog koordinatora proslijedili odgovor "spreman", ili "samo upit". U protivnom, odlučuje se da se transakcija poništi.

Globalni koordinator, nakon donošenja odluke, obezbjeđuje bezuslovno zapisivanje sadržaja blokova sistemskog dnevnika na disk i upisuje u sistemski dnevnik slog tipa [globalna_potvrda_transakcije, T], ili [globalno_poništenje_transakcije, T] i oslobađa zaključane resurse. Nakon toga, šalje odgovarajuću poruku tipa "potvrdi", ili "poništi", di­rektno podređenim čvorovima. Ukoliko je u pitanju poruka tipa "potvrdi", globalni koordi­nator mora da čeka na odgovor podređenih čvorova. Ukoliko je, pak, u pitanju poruka tipa "poništi" globalni koordinator poništava transakciju i oslobađa zaključane resurse i ne mora da čeka na odgovor podređenih čvorova.

Kada čvor u stablu transakcije dobije poruku "potvrdi", ili "poništi":

·       ukoliko je to lokalni koordinator, tada prosljeđuje poruku svojim direktno podređenim čvorovima,

·       ukoliko je stigla poruka potvrde transakcije, obezbjeđuje bezuslovno zapisivanje sadržaja blokova sistemskog dnevnika na disk i upisuje u sistemski dnevnik slog [potvrda_transakcije, T],

·       oslobađa zaključane resurse,

·       ukoliko je stigla poruka tipa "potvrdi", čeka na povratnu poruku tipa "potvrđeno", od svojih direktno podređenih čvorova. Kada je dobije, sam šalje povratnu poruku "potvr­đeno" direktno nadređenom čvoru.

Kada globalni koordinator, nakon slanja poruke tipa "potvrdi", dobije od direktno podređenih čvorova i povratnu poruku tipa "potvrđeno", ponovo obezbjeđuje bezuslovno zapisivanje sadržaja blokova sistemskog dnevnika na disk i upisuje u sistemski dnevnik slog tipa [završena_transakcija, T]. Time se postupak dvofaznog potvrđivanja transakcije okon­čava.

 

1.2.2.4.             Pojava grešaka i oporavak baze podataka

 

Dvofazni protokol završetka distribuirane transakcije je tako osmišljen da omogući uspješan oporavak baze podataka ne samo u slučaju poništavanja transakcije i pojave tran­sakcijske ili konkurencijske greške, već i u slučaju pojave sistemske greške*. Ključnu ulogu u sprovođenju postupaka oporavka baze podataka ima sistemski dnevnik.

Scenario realizacije korisničkog zahtjeva za poništavanjem globalne transakcije, kao i scenario poništavanja globalne transakcije usljed nastanka transakcijske greške su obuhvaćeni samim opisom dvofaznog protokola završetka transakcije, te se ovome ne pos­većuje dalja pažnja.

 

 

Međusobna blokada transakcija

 

Tipičnu konkurencijsku grešku predstavlja međusobna blokada transakcija. I u slučaju distribuiranih SUBP, za rješenje međusobne blokade transakcija (zastoja) se može djelovati preventivno ili korektivno. Generalno, problem prevencije zastoja, ili njegovog otkrivanja i eliminacije, u distribuiranom okruženju je znatno složeniji nego u slučaju centralizovanih SUBP.

Preventivno djelovanje se odnosi na uvođenje pravila po kojem transakciji neće biti dozvoljeno da čeka na zaključavanje već zaključanog resursa, ukoliko to može dovesti do zastoja, već se, u tom slučaju, jedna od transakcija nasilno poništava i ponovo pokreće. Ovo pravilo se, obično, realizuje uvođenjem protokola o redoslijedu transakcija. Transakcije se, prema nekom kriterijumu, urede u rastući niz T₁,..., Tn. Pri tome, dozvoljava se da transak­cija Ti uđe u red čekanja na zaključani resurs od strane transakcije Tj, ako i samo ako je i < j. Na taj način, nikada se ne može dogoditi da transakcjia Tj čeka na resurs zaključan od strane transakcije Ti, a da istovremeno i transakcija Ti čeka na resurs zaključan od strane transakcije Tj. Kriterijum uređivanja transakcija u rastući niz je obično zasnovan na podatku o vremenu nastajanja transakcije.

Uobičajenije rješenje je, međutim, da se dozvoli eventualna pojava međusobne blokade transakcija, uz obezbjeđenje mehanizama za detekciju i otklanjanje blokade. Jedan od takvih mehanizama je, kao i u slučaju nedistribuiranih SUBP, mehanizam detekcije cik­lusa u grafu zavisnosti transakcija po zaključavanju (vidjeti [ML]). Bitno je da se kod distri­buiranih SUBP ovaj graf mora formirati globalno, na nivou cjelokupne baze podataka, što bitno usložnjava postupak detekcije zastoja. Zbog toga se, češće, problem međusobne blo­kade transakcija u distribuiranom okruženju rješava putem satnog mehanizma, odnosno predefinisanog vremena trajanja transakcije. U slučaju da dođe do zastoja, istećiće predefinisano vreme trajanja transakcije, prije nego što je transakcija okončana, što je znak globalnom koordinatoru da pokrene postupak poništavanja transakcije. Ova metoda, međutim, ima nedostatak da nije lako dobro odrediti predefinisano vreme trajanja transakcije. S jedne strane, može doći do bitnog pogoršanja performansi rada sistema, ukoliko su te performanse već loše. Naime, u situaciji kada je odziv sistema loš, može se dogoditi da predefinisano vreme transakcije istekne iako nije došlo do zastoja. Transakcija se poništava i najverovatnije ponovo pokreće, što dodatno angažuje resurse sistema. Ukoliko je, s druge strane, pre­definisano vrijeme trajanja transakcije predugo, međusobno blokirane transakcije će nepo­trebno dugo angažovati resurse sistema prije nego jedna od njih bude poništena.

 

 

Primjer 1.7. Distribuirani sistem za upravljanje bazama podataka ORACLE V.8.* omogućava zadavanje predefinisanog vremena trajanja transakcije putem parametra inicijalizacije sistema pod nazivom DISTRIBUTED_LOCK_TIMEOUT. Ukoliko drugačije nije zadato, prilikom inicijalizacije sistema, predefinisana vrednost ovog parametra će iznositi 60 sekundi. Ukoliko se transakcija ne završi u zadatom roku, poništava se, a korisnik dobija poruku "ORA-02049: time-out: distributed transaction waiting for lock".

 

 

Sistemske greške

 

Sistemske greške su greške koje se odnose na privremeni prestanak rada bar jed­nog servera baze podataka, ili dijela komunikacione mreže. Ukoliko je riječ o privremenom prestanku rada servera baze podataka, sistemska greška izaziva gubitak sadržaja operativne memorije tog servera. Pri tome, pretpostavlja se da je sadržaj datoteka na diskovima ostao neoštećen. U suprotnom, sistemska greška prerasta u grešku na disku, ili katastrofalnu fizičku grešku, kada je, u cilju oporavka baze podataka, potrebno primjeniti i tehniku restau­racije posljednje arhivirane kopije baze podataka.

Sa stanovišta dvofaznog protokola završetka distribuirane transakcije, sistemske greške, koje se mogu dogoditi u toku trajanja transakcije, mogu se klasifikovati na greške ispada servera i greške izgubljenih poruka, usljed prekinute komunikacije. U greške ispada servera spadaju:

 

·       ispad uslužnog servera pre zapisa u sistemski dnevnik sloga tipa [spremna_transakcija,T],

·        ispad    uslužnog    servera    nakon    zapisa    u    sistemski    dnevnik    sloga    tipa [spremna_transakcija,T],

·       ispad globalnog koordinatora pre zapisa u sistemski dnevnik sloga tipa  [pripre-ma_transakcije, T],

·       ispad globalnog koordinatora nakon zapisa u sistemski dnevnik sloga tipa [priprema_transakcije, T], ali prije zapisa sloga tipa [potvrda_transakcije, T] i

·       ispad globalnog koordinatora nakon zapisa u sistemski dnevnik sloga tipa [potvrda_transakcije, T], ali prije zapisa sloga tipa [završena_transakcija, T].

Greške izgubljenih poruka mogu biti:

·       izgubljena poruka globalnog koordinatora "izvrši pripremu",

·       izgubljena poruka uslužnog servera "samo upit", "spreman", ili "prekini",

·       izgubljena poruka globalnog koordinatora "potvrdi", ili "poništi" i

·       izgubljena poruka uslužnog servera "potvrđeno".

U slučaju da nastane bilo koja od navedenih grešaka, distribuirani SUBP je, na osnovu sadržaja sistemskog dnevnika, u mogućnosti da, nakon oporavka komunikacione mreže, ili servera baze podataka, obezbjedi očuvanje konzistentnosti baze podataka, bilo poništavanjem i, eventualno, ponovnim pokretanjem prekinute transakcije, ili nastavkom rada na transakciji prema samoj logici transakcije.

Oporavak od grešaka pri realizaciji dvofaznog protokola završetka transakcije, u slučaju kratkotrajnih ispada dijelova sistema, u principu, traje vrlo kratko, tako da je moguće da krajnji korisnici ili administratori sistema čak i ne primjete da je do greške došlo.

Duži ispadi dijelova sistema, međutim, mogu dovesti do toga da transakcija u cjelosti, ili lokalni dijelovi transakcije ostanu duže vreme nerazriješeni. Lokalni dio transakcije se smatra nerazrješenim ukoliko se nalazi u stanju nazvanom "spremna transakcija", što znači da u sistemskom dnevniku postoji slog tipa [spremna_transakcija, T], ali od koordinatora još nije dobijena komanda tipa "potvrdi", iii "poništi". Nerazrješeni dio transakcije i dalje zauzima sve zaključane resurse, što znači da druge transakcije ne mogu tim resursima da pristupe. Uobičajeno je da, ukoliko druga transakcija zahjeva pristup resursima koji su zaključani od strane nerazrješene transakcije, transakcija koja traži resurse bude poništena, a korisnik na odgovarajući način o tome obavješten.

Problem nerazriješenih dijelova transakcija, usljed dugotrajnih ispada dijelova sistema, može uticati na znatno sniženje stepena raspoloživosti sistema. Zbog toga se, kada je to zaista neophodno, pribjegava postupku separatnog (nasilnog) razrješavanja nerazrješenih transakcija. Distribuirani SUBP, u tom cilju, omogućava da administrator lokalne baze po­dataka zahtijeva separatno ("nasilno") potvrđivanje, ili poništavanje nerazrešenog lokalnog dela transakcije, u cilju oslobađanja zaključanih resursa. Ovakvo razrješavanje transakcije se naziva nasilnim zbog činjenice da se ono sprovodi bez "znanja" globalnog koordinatora transakcije i može dovesti bazu podataka u nekonzistentno stanje!

Podaci o statusu svake transakcije se nalaze u rječniku podataka. Ukoliko je tran­sakcija nasilno razriješena, njen status će biti "nasilno potvrđena transakcija", ili "nasilno poništena transakcija". Nakon sprovođenja procedura oporavka sistema od nastale greške, u rječniku podataka će automatski biti evidentirano da li je transakcija u cjelini, na svim čvo­rovima razriješena na isti način, što je od velike važnosti za očuvanje globalne konzistentnosti podataka.

Ukoliko administrator lokalne baze podataka pribjegne postupku separatnog razrješavanja transakcije, odluka o načinu razrješavanja transakcije treba da bude donijeta na jedan od sljedeća dva načina:

·       uvidom u rječnik globalnog koordinatora, ili ako to nije moguće, uvidom u rječnik nekog drugog servera baze podataka iz stabla transakcije, u cilju pribavljanja informacije da li je transakcija generalno potvrđena, odnosno poništena, kako bi se sprovela ista akcija i nad posmatranom lokalnom bazom podataka, ili

·       ukoliko prvi način nije izvodljiv, onda se odluka donosi u koordinaciji s administratori­ma drugih servera baze podataka koji učestvuju u stablu transakcije.

 

 

Primjer 1.8. Distribuirani sistem za upravljanje bazama podataka ORACLE V.8.* automatski održava, u okviru svog rječnika podataka, podatke o statusu nezavršenih ili nekonzistentno razriješenih distribuiranih transakcija. U katalogu riječnika lokalne baze podataka postoji pogled pod nazivom DBA_2PC_PENDING. Svaka torka ovog pogleda ukazuje na jednu nerazrešenu ili loše razriješenu distribuiranu transakciju. Između ostalih, ovaj pogled sadrži obilježja LOCAL_TRAN_ID i GLOBAL_TRAN_ID čije vrijednosti ukazuju, redom, na lokalni i globalni identifikacioni broj transakcije. Svaka distribuirana transakcija ima jedinstvenu vrijednost globalnog identifikacionog broja u okviru cijelog sistema. Obilježje STATE, ovog pogleda, može imati vrijednosti:

 

·       collecting, ukoliko lokalni, ili globalni koordinator čeka na poruke od direktno podređe­nih čvorova tipa "samo upit", "spreman", ili "prekini", kako bi donio odluku o mogućem načinu završetka transakcije,

·       prepeared, ako je lokalni dio transakcije u stanju "spremna transakcija", ali još nije od koordinatora stigla poruka o načinu završetka transakcije,

·       committed, ako je transakcija na serveru potvrđena, ali još uvijek nije generalno potvrđena na svim čvorovima u stablu transakcije,

·              forced commit, ako je transakcija separatno potvrđena na serveru i

·       forced abort (rollback), ako je transakcija separatno poništena na serveru, dok obilježje MIXED može imati dvije vrijednosti:

·              yes, ukoliko je transakcija nekonzistentno razriješena, odnosno ukoliko je na nekim serverima potvrđena, a na nekim poništena, ili

·       no, u svim ostalim slučajevima, dok je transakcija nerazriješena.

Na osnovu sadržaja pogleda DBA_2PC_PENDING i, po potrebi, pogleda pod nazivom DBA_2PC_NEIGHBORS, koji se u ovom primjeru ne razmatra, administrator baze podataka ima, u dosta situacija, mogućnost da donese pravilnu odluku o načinu separatnog razrješavanja transakcije.

 

 

1.2.2.5.             Server globalne potvrde transakcije

 

Postoje rješenja, u okviru distribuiranih SUBP, kod kojih je, u cilju poboljšanja dvofaznog protokola završetka transakcije, odnosno smanjenja vjerovatnoće da će transak­cija ostati, većim dijelom, nerazriješena, primjenjen koncept servera globalne potvrde transak­cije*. Ideja je da se, od svih čvorova u stablu transakcije, izabere onaj koji sadrži "najkri­tičnije" podatke sa stanovišta transakcije i da se proglasi serverom globalne potvrde tran­sakcije.

 Transakcija se, na početku faze realizacije, prvo potvrđuje ili poništava na ovom serveru, a tek potom i ostali čvorovi dobijaju odgovarajuću komandu od globalnog koordi­natora.

Primjenom ovako modifikovanog dvofaznog protokola završetka distribuirane tran­sakcije, globalni koordinator garantuje da će, na svim ostalim čvorovima, transakcija biti razriješena na isti način kao što je razriješena i na serveru globalne potvrde transakcije. U slu­čaju da se javi potreba za separatnim završetkom transakcije, potrebno je da se administra­tor lokalne baze podataka informiše o tome da li je i kako je ista transakcija završena na serveru globalne potvrde transakcije i primjeni istu odluku o načinu završetka transakcije.

Efekat primjene koncepta servera globalne potvrde transakcije treba da bude smanjenje očekivane složenosti algoritma završetka distribuirane transakcije. Na taj način, povećava se pogodnost sistema za upotrebu u uslovima nedovoljno pouzdanih komunika­cija.

 

Primjer 1.9. Kod SUBP ORACLE, dvofazni protokol završetka distribuirane tran­sakcije je zasnovan na primjeni koncepta servera globalne potvrde transakcije.

Izbor servera globalne potvrde transakcije vrši globalni koordinator, na početku faze pripreme, u momentu kada je naišao zahtjev za potvrdu transakcije. Ukoliko se pojavi zahtjev za poništavanje transakcije, server globalne potvrde se ne bira. Kandidati za server globalne potvrde transakcije su samo čvorovi iz stabla transakcije na kojima je transakcija zahtjevala nekakvo ažuriranje podataka. Za server globalne potvrde transakcije se bira takav kandidat koji ispunjava sljedeće uslove:

·       ima najviši definisani prioritet i

·       ako više kandidata ima isti, najviši prioritet i ako je među njima globalni koordinator, bira se on, a inače se bira kandidat koji je u stablu transakcije najbliži globalnom koordi­natoru.

Prioritet servera baze podataka se definiše prilikom konfigurisanja SUBP, putem parametra inicijalizacije sistema COMMIT_POINT_STRENGTH, čija vrijednost predstavlja cio broj iz intervala [O, 255].

Nakon izbora servera globalne potvrde transakcije, globalni koordinator sprovodi fazu pripreme završetka transakcije, na način kako je to već opisano, pri čemu server globalne potvrde transakcije ne učestvuje u fazi pripreme.

Ukoliko, na početku druge faze, globalni koordinator donese odluku o potvrđiva­nju transakcije, poruku tipa "potvrdi" prosljeđuje prvo serveru globalne potvrde transakcije. Ovaj kompletno potvrđuje svoj dio transakcije i šalje nazad poruku tipa "potvrđeno". Na­kon toga, globalni koordinator šalje ostalim serverima poruku "potvrdi" i, kada dobije sve povratne poruke tipa "potvrđeno", izvještava o tome server globalne potvrde transakcije. To omogućava da i server globalne potvrde transakcije i globalni koordinator proglase transakciju kompletno razriješenom i izbrišu je iz tabele nerazrešenih transakcija. Ukoliko globalni koordinator, na početku druge faze, donese odluku o poništavanju transakcije, poruku tipa "poništi" šalje svim serverima, uključujući i server globalne potvrde transakcije.

 

1.2.3.            Replikacija podataka

 

Pojam replikacije podataka je uveden u tački 1.1. Smatra se da distribuirani SUBP, ukoliko se želi njegova uspješna primjena u praksi, mora posjedovati mehanizme za podršku replikacije podataka. Namjerno uvođenje kontrolisane redundanse u bazu podataka, putem replikacije, može bitno povisiti stepen raspoloživosti podataka i značajno uticati na obezbjeđenje zadovoljavajućih performansi rada informacionog sistema.

 

Distribuirani SUBP treba, u principu, da podrži dve vrste replikacije podataka:

·       osnovnu i

·       simetričnu.

Osnovna (jednosmjerna) replikacija podrazumijeva da se nad repliciranim dijelovima baze podataka mogu samo sprovoditi upiti, putem operacije selekcije podataka. Simetrična (dvosmjerna) replikacija omogućava da se nad repliciranim delovima baze podataka mogu sprovoditi i operacije ažuriranja. Saglasno činjenici da simetrična replikacija dozvoljava simultano ažuriranje različitih kopija istih podataka, pokazuje se da standardni mehanizmi za očuvanje konzistentnosti centralizovane baze podataka u višekorisničkom režimu rada nisu dovoljni, već se, u tom smislu, moraju primjeniti posebne tehnike, o kojima će u ovoj tački biti govora.

 

1.2.3.1.             Replikaciona kopija

 

Osnovni koncept replikacije baze podataka je replikaciona kopija. Replikaciona kopija, ili kraće kopija*, u relacionom SUBP predstavlja relaciju, odnosno tabelu, koja se formira i ažurira preuzimanjem (kopiranjem) podataka iz jedne ili više drugih tabela. Te druge tabele se, u principu, ne nalaze na istom serveru baze podataka na kojem se nalazi replikaciona kopija. Glavna karakteristika replikacione kopije je da se ona, u unapred odre­đenim vremenskim trenucima, ažurira posredno, propagacijom operacija ažuriranja koje su sprovedene nad osnovnim tabelama, na osnovu kojih je replikaciona kopija i definisana. Ovakvo ažuriranje replikacione kopije se još naziva i osvježavanje* kopije. Replikaciona kopija može biti:

·       statička, ukoliko su nad njom samo dozvoljene operacije selekcije podataka, ili

·       dinamička, ukoliko su nad njom dozvoljene i operacije ažuriranja.

Osnovna replikacija dozvoljava izgradnju samo statičkih kopija, dok simetrična replikacija dozvoljava izgradnju i statičkih i dinamičkih kopija. Pri tome, statička kopija se ažurira isključivo posredno, tehnikom osvežavanja, te se, zbog toga, i osnovna replikacija naziva i jednosmjernom replikacijom. S druge strane, dinamička kopija se može ažurirati na dva načina: osvežavanjem, ili direktnim ažuriranjem, kada je neophodno identične operacije ažuriranja sprovesti i nad tabelama od kojih je dinamička kopija nastala. Zbog toga se simetrična replikacija naziva i dvosmernom replikacijom.

 

Neki SUBP omogućavaju formiranje replikacionih kopija samo na osnovu jedne tabele, pri čemu kopija ili može po sadržaju biti identična tabeli, ili sadržaj kopije može predstavljati dio sadržaja tabele, dobijen primjenom operacija projekcije ili selekcije nad tabelom. Savremenija rješenja replikacije omogućavaju formiranje replikacionih kopija putem SQL naredbe SELECT, na sličan način kao što se kreiraju i SQL pogledi baze poda­taka. U tom slučaju, opseg mogućnosti za definisanje sadržaja kopije je sveden na široki dijapazon mogućnosti SELECT naredbe.

U daljem tekstu, pretpostavlja se da se replikaciona kopija definiše putem SELECT naredbe. Ukoliko važi da je replikaciona kopija deklarisana tako da:

·       će uvijek obuhvatati samo dio sadržaja jedne tabele, dobijen primjenom operacija projek­cije ili selekcije nad tabelom, ili će po sadržaju biti identična tabeli i

·       skup obilježja kopije sadrži primarni ključ polazne tabele,

tada se ona naziva osnovnom replikacionom kopijom. U svim drugim situacijama, riječ je o složenoj replikacionoj kopiji. Na taj način, da bi se formirala osnovna replikaciona kopija, odgovarajuća SELECT naredba ne smije da sadrži, na primjer, opcije GROUP BY, HAVING, CONNECT BY, skupovne operatore tipa UNION i INTERSECT, spajanje tabela, pozive skupovnih funkcija tipa SUM, COUNT, itd. Neki SUBP, pri tome, dozvoljavaju da WHERE opcija sadrži afirmativne podupite, kao što je podupit oblika EXISTS (SELECT...).

Ukoliko se kopija deklariše kao statička, tada ne postoje posebna ograničenja u primjeni SELECT naredbe za strukturiranje kopije i takva kopija može biti formirana bilo kao osnovna, ili kao složena. Ukoliko se, međutim, kopija deklariše kao dinamička, tada ona mora biti formirana isključivo kao osnovna replikaciona kopija.

 

Primjer 1.10. Posmatra se konfiguracija distribuiranog informacionog sistema iz primjera 1.2, šema relacije Ugovor, definisana u lokalnoj šemi baze podataka IISB.F1.BAN i šema relacije Posl_Partner, u lokalnoj šemi baze podataka IISB.C.BAN. Neka su u lokal­noj šemi baze podataka IISB.F2.BAN kreirani db linkovi pod nazivom IISB.F1.BAN i IISB.C.BAN, za pristup istoimenim serverima baze podataka.

SQL naredba za kreiranje jednog tipa replikacione kopije u ORACLE V.8.*, naz­vanog replikaciona slika* je CREATE SNAPSHOT. Bez zalaženja u detalje sintakse ove naredbe, u nastavku je data naredba za kreiranje jedne osnovne, dinamičke replikacione kopije, nad tabelom Ugovor, u okviru lokalne baze podataka IISB.F2.BAN:

CREATE SNAPSHOT SNP_Ugovor

FOR UPDATE

AS

SELECT   u.UGGOD, u.UGIDB, u.UGDAT, u.PPIDB

FROM     Ugovor@IISB.F1.BAN u

WHERE   u.UGGOD = '1999'.

Opcija FOR UPDATE deklariše replikacionu sliku dinamičkom, dok struktura SELECT naredbe deklariše sliku osnovnom. Izvršenjem ove naredbe se, na serveru IISB.F2.BAN, deklariše replikaciona slika, pod nazivom SNP_Ugovor, koja treba da sadrži kopije svih torki relacije Ugovor, za koje je godina formiranja ugovora 1999.

Koncept replikacione slike se realizuje putem koncepta tabele, pogleda i indeksa. U ovom slučaju će, izvršenjem naredbe CREATE SNAPSHOT, na serveru baze podataka IISB.F2.BAN, biti kreirani sledeći objekti:

·       tabela   sa   stvarno   repliciranim   podacima,   čiji   se   naziv   formira   prema   šemi SNAP$_<naziv_slike>, što znači da se ona, u ovom primjeru, zove SNAP$_SNP_Ugovor. Primami ključ ove tabele će biti isti kao i primarni ključ polazne tabele Ugovor,

·       indeks  nad  primarnim  ključem  tabele  SNAP$_SNP_Ugovor,   odnosno   obilježjima UGGOD+UGIDB i

·       pogled, s istim nazivom kao što je i naziv replikacione slike, Što znači da je to u ovom primjeru SNP_Ugovor.

Sljedeća naredba predstavlja primjer kreiranja jedne statičke, složene replikacione slike:

 

CREATE SNAPSHOT SNP_Ugovor_Poslpart

AS

SELECT u.UGGOD, u.UGIDB, u.UGDAT, u.PPIDB, p.PPNAZ

FROM     Ugovor@IISB.F1.BAN u, Posl_Partner@IISB.C.BAN p

WHERE  u.PPIDB = p.PPIDB.

 

Izostavljanje iz naredbe opcije FOR UPDATE deklariše sliku statičkom, dok činjenica da SELECT naredba definiše spoj tabela Ugovor i Posl_Partner deklariše sliku složenom.

 

 

 

1.2.3.2.             Propagacija ažuriranja

 

Ažuriranje sadržaja osnovnih tabela baze podataka zahteva da se operacije ažuri­ranja sprovedu i nad odgovarajućim replikacionim kopijama, odnosno da se izvrši osvežavanje sadržaja kopija. Isto tako, ažuriranje sadržaja dinamičke kopije zahteva da se iste ope­racije ažuriranja sprovedu i nad odgovarajućom osnovnom tabelom. Ovakvo ažuriranje baze podataka se naziva ažuriranje s propagacijom. Pri tome, propagacija ažuriranja označava postupak prosleđivanja naredbi za ažuriranje ka drugim serverima baze podataka.

Propagacija ažuriranja, sa stanovišta vremena pokretanja, može biti:

·       sinhrona, ili

·       asinhrona.

Sinhrona (trenutna) propagacija ažuriranja se izvršava neposredno nakon sa­mog ažuriranja podataka tabele ili kopije, u okviru iste transakcije. Njome se obezbjeđuje da, nakon završetka transakcije, sve tabele i njihove odgovarajuće kopije budu usaglašene po sadržaju. To znači da za očuvanje konzistentnosti podataka u višekorisničkom režimu rada nisu potrebni dodatni mehanizmi, već su dovoljni mehanizmi dvofaznog potvrđivanja transakcije i zaključavanja podataka, o kojima je već bilo govora u prethodnom tekstu.

          Asinhrona (odložena) propagacija ažuriranja se izvršava naknadno, u opštem slučaju, nakon što je transakcija ažuriranja podataka već završena. Asinhrona propagacija ažuriranja se realizuje putem odloženih transakcija. Pri tome, odložena transakcija će biti pokrenuta u unapred određeno vrijeme u budućnosti. Projektant replikacije podataka zadaje, u principu, dva vremenska parametra:

·       datum i vrijeme prve asinhrone propagacije i

·       vremensku odrednicu svake sljedeće asinhrone propagacije.

Obično se zahtijeva da datum i vrijeme prve asinhrone propagacije označe trenutak u buduć­nosti s obzirom na momenat zadavanja ovih parametara. Vremenska odrednica svake sljede­će asinhrone propagacije može biti relativna u odnosu na datum i vreme prve asinhrone propagacije (na primjer: svakog dana u isto vreme, svakog sata, itd), ili može biti apsolutna (na primjer: svakog ponedeljka u 01.00, svakog dana u 05.00, svakog prvog dana u mjesecu u 12.00, itd). Vremenski interval između dvije sukcesivne propagacije mora biti dovoljno veliki da se postupak propagacije u cjelini izvrši. Postoje i drugi kriteriji, na osnovu kojih se određuje vreme pokretanja asinhrone propagacije, a projektant se može opredijeliti i za rješenje po kojem se asinhrona propagacija ne vrši po zadatom automatizmu, već po posebnom zahtjevu.

Sinhrona propagacija predstavlja, u opštem slučaju, bolje rješenje od asinhrone, jer ne postoji vremenski raskorak u ažurnosti repliciranih i osnovnih podataka. Ovaj vremenski raskorak je prisutan u slučaju primjene asinhrone propagacije, što dodatno usložnjava prob­lem očuvanja konzistentosti podataka u višekorisničkom režimu rada. S druge strane, preduslov za uspješnu primjenu sinhrone propagacije je da se distribuirani informacioni sis­tem temelji na vrlo pouzdanim hardverskim resursima i komunikacionoj infrastrukturi, što u praksi, često, nije lako i jeftino da se obezbjedi. Zato se može reći da asinhrona propagacija predstavlja, u ne malom broju slučajeva, jedini mogući izbor.

Projektant simetrične replikacije treba da ima mogućnost da posebno zada način i parametre propagacije ažuriranja za "oba smjera", odnosno i za osvježavanje replikacionih kopija i za propagaciju ažuriranja ka osnovnim tabelama. Izbor načina i parametara propa­gacije ne mora za oba smjera biti isti. Uobičajeno je, ili je to kod nekih SUBP čak i jedina mogućnost, da se osvježavanje replikacionih kopija vrši samo u asinhronom režimu.

Propagacija ažuriranja, sa stanovišta logike izvođenja, može biti:

·       na nivou torke, ili

·       proceduralna.

Propagacija na nivou torke* je tako osmišljena da se na osnovu svake SQL naredbe transakcije, koja ažurira podatake, pomoću internih okidača (trigera), koje na nivou tabele ili replikacione kopije kreira sam SUBP, izvršavaju pozivi procedura čiji je zadatak da izvrše istu operaciju ažuriranja podataka nad ostalim kopijama podataka. Ukoliko je propagacija sinhrona, pozivi procedura predstavljaju sastavni dio tekuće transakcije. Uko­liko je, međutim, propagacija asinkrona, pozivi procedura se grupišu u posebne, odložene transakcije. Odložene transakcije se smještaju u red čekanja odloženih transakcija lokalnog servera baze podataka. Ovakav red čekanja postoji na svakom serveru koji participira u distribuciji podataka. Saglasno vrijednostima parametara asinhrone propagacije, odložene transakcije se, u određenom trenutku vremena, aktiviraju i, tek nakon uspješnog završetka, uklanjaju iz reda čekanja.

Proceduralna propagacija je tako osmišljena da se jednim pozivom (korisnički definisane) procedure sprovedu sve operacije propagacije ažuriranja, na nivou celokupne transakcije. Takva procedura, po svom karakteru, može biti kompleksna, jer mora obuhva­titi propagaciju ažuriranja za sve replikacione kopije u sistemu i za svaku izvršenu naredbu ažuriranja podataka. U slučaju sinhrone propagacije, poziv pomenute procedure predstavlja sastavni dio tekuće transakcije, a u slučaju asinhrone propagacije, poziv procedure se organizuje kao posebna, odložena transakcija. Pošto je teško očekivati da SUBP posjeduje predefinisane procedure za izvođenje proceduralne propagacije, znači da projektanti moraju, u te svrhe, oblikovati sopstvene procedure, a time preuzimaju i dio odgovornosti za očuvanje konzistentnosti podataka.

Propagacija na nivou torke je, načelno, bolji izbor za kratke transakcije, koje su karakteristične za obradu podataka u interaktivnom režimu. Kada je u pitanju paketna* obrada podataka, koja se, često, sprovodi putem dugačkih i kompleksnih transakcija,

tada se bolje performanse mogu očekivati ukoliko se primjeni proceduralna propagacija ažuriranja.

Propagacija ažuriranja, kada je u pitanju optimizacija izvođenja, može biti:

·       serijska, ili

·       paralelna.

Serijska propagacija je propagacija kod koje se operacije ažuriranja prosljeđuju i izvršavaju nad repliciranim podacima u istom redosljedu, kao i u polaznoj transakciji.

Paralelna propagacija dozvoljava izmjenu redoslijeda i paralelizaciju pri prosljeđivanju i izvršavanju operacija ažuriranja nad repliciranim podacima. Pri tome, SUBP koji podržava ovu vrstu propagacije, posjeduje i posebne mehanizme putem kojih se obezbjeđuje da paralelizacija propagacije ažuriranja ne naruši serijabilnost postupka.

Osim što se osvježavanje replikacionih kopija može sprovesti trenutnim ili odlože­nim prosljeđivanjem naredbi za ažuriranje, postoje i sledeće tehnike osvežavanja:

·       kompletno osvježavanje i

·       brzo osvježavanje.

Obje navedene tehnike osvježavanja su asinhronog karaktera i bitna odrednica im je da se, u cilju propagacije ažuriranja, kroz mrežu ne prosljeđuju naredbe, već sami podaci.

Kompletno osvježavanje je osvježavanje kod kojeg se sadržaj replikacione kopije u cjelosti obnavlja ispočetka, kao da prethodni sadržaj nije ni postojao. Ukoliko se definicija replikacione kopije temelji na SELECT naredbi, to znači da se ona pri kompletnom osvježavanju izvršava kao i pri prvom kreiranju replikacione kopije. Kompletno osvježavanje, najčešće, predstavlja jedinu moguću tehniku za ažuriranje sadržaja složenih replikacionih kopija, a može se primeniti i u slučaju osnovnih replikacionih kopija.

Brzo osvježavanje je efikasnija tehnika ažuriranja replikacionih kopija, zasnovana na prosljeđivanju podataka. Primjenljiva je isključivo za osnovne replikacione kopije. Sastoji se u tome da se, uz osnovnu tabelu, formira posebna tabela, pod nazivom replikacioni dnevnik. Skup obilježja replikacionog dnevnika obavezno sadrži:

·       obilježja primarnog ključa osnovne tabele,

·       obilježje tipa datum i vrijeme, koje kao vrijednost sadrži trenutak nastanka torke i često se naziva vremenska markica* obilježje koje označava tip sprovedene operacije ažuriranja (dodavanje, brisanje, ili modifikacija) i

·       obilježja za memorisanje starih i novih vrijednosti obilježja torke.

 

Svako ažuriranje podataka u osnovnoj tabeli, putem internih okidača koje nad osnovnom tabelom generiše sam SUBP, inicira upis jedne torke u replikacioni dnevnik. Pri tome, u replikacionom dnevniku se za svaku elementarnu operaciju ažuriranja, evidentiraju: vrijed­nost primarnog ključa torke koja se briše, stare i nove vrijednosti obilježja torke koja se modifikuje, ili vrijednosti obilježja novododate torke u tabelu. Prosljeđivanjem dijela ili kompletnog sadržaja replikacionog dnevnika, sprovodi se ažuriranje replikacionih kopija date osnovne tabele. Kada neka torka u replikacionom dnevniku postane neaktuelna, obezbjeđeno je njeno automatsko brisanje.

 

Primjer 1.11. Posmatraju se replikacione slike iz primjera 1.10 SNP_Ugovor i SNP_Ugovor_Poslpart. SUBP ORACLE, generalno, omogućava da se replikacione slike osvježavaju prosljeđivanjem podataka, pomoću tehnike brzog, ili kompletnog osvježavanja.

SNP_Ugovor predstavlja osnovnu replikacionu sliku, za koju može da se obezbjedi brzo osvježavanje. Potrebno je za osnovnu tabelu Ugovor kreirati replikacioni dnevnik na serveru IISB.F1.BAN, putem SQL naredbe CREATE SNAPSHOT LOG. Za ovaj primjer, osnovni oblik ove naredbe je:

 

CREATE SNAPSHOT LOG ON Ugovor.

 

Izvršenjem naredbe CREATE SNAPSHOT LOG, SUBP ORACLE automatski formira ta­belu za podršku osvježavanja, čiji se naziv zadaje prema šemi MLOG$_<naziv_tabele>, što znači da će u ovom primjeru njen naziv biti MLOG$_Ugovor. Ova tabela reprezentuje dnev­nik promjena, koji se koristi pri osvježavanju osnovnih replikacionih slika. Pored toga, ako je reč o dinamičkoj replikacionoj slici, kreira se još jedna tabela, s nazivom koji se zadaje prema šemi USLOG$_<naziv_tabele>. Struktura ove tabele je gotovo ista kao i struktura tabele MLOG$_<naziv_tabele>. Njena uloga je da predstavlja dnevnik promjena za ažuri­ranje osnovne tabele, te se u nju upisuju torke pri ažuriranju same replikacione slike. U ovom primjeru, pošto je riječ o dinamičkoj slici, ta tabela će biti kreirana i zvaće se USLOG$_Ugovor.

SNP_Ugovor_Poslpart predstavlja složenu replikacionu sliku. Za njeno ažuriranje se može primjeniti samo tehnika kompletnog osvježavanja, bez obzira da li nad osnovnim tabelama Ugovor i Posl_Partner postoji kreiran replikacioni dnevnik.

 

 

 

 

 

1.2.3.3.             Replikaciona grupa

 

Posmatraju se dvije različite replikacione kopije. Pretpostavlja se da postoji koris­nički zahtjev koji traži da se sprovodi selekcija sa spajanjem torki ovih replikacionih kopija. Pretpostavlja se, nadalje, da se propagacija ažuriranja organizuje kao asinhrona, pri čemu se vremenski parametari asinhrone propagacije zadaju posebno za jednu i posebno za drugu replikacionu kopiju. Usljed različito zadatih vremenskih parametara, može se dogoditi da replikacione kopije ne predstavljaju sliku stanja originalnih podataka u istom vremenskom trenutku. U tom slučaju, zahtjevana selekcija sa spajanjem će dati lažnu sliku stanja, što upućuje na zaključak da konzistentnost baze podataka nije obezbjeđena. Da bi se ovakva situacija izbjegla, uvodi se pojam replikacione grupe.

Replikaciona grupa predstavlja skup replikacionih kopija i osnovnih tabela, za koji se, jedinstveno, zadaju način i parametri propagacije ažuriranja, ili samo osvježavanja podataka. Tako se obezbjeđuje da svi članovi replikacione grupe sadrže podatke koji preds­tavljaju presjek stanja u istom vremenskom trenutku. Pored toga, olakšava se i adminisrriranje replikacijom podataka, jer se čitav niz administratorskih aktivnosti sprovodi nad replikacionom grupom, umjesto nad pojedinačnim tabelama i replikacionim kopijama. Pri tome, važi ograničenje da se jedna replikaciona kopija, ili tabela, može smjestiti u najviše jednu replikacionu grupu.

 

Primjer 1.12. SUBP ORACLE, u cilju obezbjeđenja replikacije podataka, na sva­kom replikacionom serveru održava rječnik replikacije podataka, koji se još naziva i replikacioni katalog. Aktivnosti implementacije i administriranja replikacije podataka se mogu sprovesti uz pomoć alata ORACLE Replication Manager. Na slici 1.4 su, putem ER dijagrama, u notaciji koju podržava CASE proizvod Designer 2000* prikazani osnovni koncepti ORACLE replikacije podataka, kao i njihovi međusobni odnosi. Prikazani ER dijagram je načelnog karaktera i nema za cilj opisivanje stvarne strukture replikacionog kataloga.

SUBP ORACLE podržava osnovnu i simetričnu replikaciju. Pri tome, replikaciona kopija podataka može biti:

·       sama tabela, ili

·       replikaciona slika.

Saglasno tome, postoje, u osnovi, dve tehnike replikacije podataka i drugih obje­kata baze podataka:

·       replikacija glavnih grupa* i

·       replikacija slika*,

koje se mogu kombinovati. U nastavku teksta se nešto detaljnije razmatraju obje tehnike.

Replikacija glavnih grupa dozvoljava proglašavanje cjelokupne tabele replikacio­nom kopijom. To je uvek simetrična replikacija. Replikaciona grupa se, u slučaju primjene ovog tipa replikacije, naziva glavnom replikacionom grupom (vidjeti sliku 1.4). Glavna grupa se uvijek nalazi na jednom, matičnom serveru baze podataka, koji se, u tom slučaju, naziva glavni server, a može biti replicirana na više drugih, glavnih servera. Replikacioni server predstavlja glavni server, ako na njemu postoji najmanje jedna glavna grupa.

 

Slika 1.4.

 

Glavna grupa može sadržati više objekata replikacije. Svaki objekat baze podataka koji treba replicirati predstavlja objekat replikacije (slika 1.4) i mora se pojaviti u jednoj i samo jednoj glavnoj grupi. Osim tabele, objekat replikacije može biti okidač, indeks, paket, pogled i sinonim. To znači da će se, u okviru replikacione grupe, definicija okidača, indeksa, paketa, pogleda, ili sinonima, replicirati na svim glavnim serverima, koji su u vezi s posmatranom glavnom grupom.

Način i parametri propagacije ažuriranja se definišu za svaku replikaciju glavne grupe, putem koncepta pod nazivom dijeljeni link (slika 1.4). Dijeljeni link se bazira na kon­ceptu db linka i ukazuje na tačno jedan server baze podataka u sistemu. Alokacija glavne grupe na glavni server se vrši izborom dijeljenog linka. Prilikom alokacije glavne grupe na server, definiše se način propagacije ažuriranja (sinhrona ili asinhrona). Važni atributi de­ljenog linka su vremenski parametri asinhrone propagacije i, ako je izabrana asinhrona propagacija, oni se primjenjuju pri ažuriranju svih kopija podataka grupe. ORACLE dozvoljava da se realizuje sinhrona ili asinhrona, na nivou reda ili proceduralna, kao i serijska ili paralelna propagacija. Svi glavni serveri, na koje je neka glavna grupa alocirana, ravnopravno komuniciraju u cilju sprovođenja propagacije ažuriranja.

Replikacija slika je zasnovana na, već opisanom, konceptu replikacione slike. Može biti organizovana kao osnovna, ili kao simetrična replikacija. Replikacionu kopiju, u ovom slučaju, predstavlja replikaciona slika, koja se može formirati referenciranjem tabela, pogleda, ili sinonima za tabele i poglede (slika 1.4). Replikaciona grupa se, kod ovog tipa replikacije, naziva grupom replikacionih slika. Grupa replikacionih slika može sadržati više osnovnih replikacionih slika, koje se, u tom slučaju, nazivaju vezanim replikacionim slikama. Složene replikacione slike se oblikuju nezavisno od bilo koje grupe slika i direkt­no se vezuju za server replikacije, kojem pripadaju. Ukoliko su sve replikacione slike u grupi statičke, riječ je o osnovnoj replikaciji, a ako u grupi postoji makar jedna dinamička slika, riječ je o simetričnoj replikaciji.

Replikaciona grupa se formira za jednu i samo jednu glavnu grupu (koja se naziva matična glavna grupa replikacione grupe) i može sadržati samo replikacione slike, takve da referenciraju isključivo objekte iz te glavne grupe. Grupa replikacionih slika pripada tačno jednom serveru baze podataka, koji se, tada, naziva server replikacionih slika (slika 1.4). Saglasno tome, replikacioni server može, istovremeno, biti i glavni server i server replikacionih slika, ako na njemu postoji barem jedna glavna grupa i barem jedna grupa replikacionih slika. Na slici 1.4 je to naznačeno kardinalitetom IS-A hijerarhije (1:N) uz naziv tipa entiteta SERVER REPLIKACIJE.

Način i parametri propagacije ažuriranja u smjeru od replikacione slike ka tabeli se definišu izborom dijeljenog linka, pri kreiranju grupe slika. Nakon što se, na početku kreira­nja grupe slika, izabere dijeljeni link, dozvoljava se izbor samo one glavne grupe, koja je alocirana na server baze podataka na koji izabrani dijeljeni link ukazuje. Projektant replika­cije može izabrati sinhroni ili asinhroni način propagacije ažuriranja. Kao i u slučaju repli­kacije glavnih grupa, dijeljeni link definiše vremenske parametre propagacije ažuriranja, koji se primjenjuju u slučaju asinhrone propagacije. U slučaju da je jedna glavna grupa alocirana na najmanje dva glavna servera, propagacija ažuriranja u smeru od replikacione slike ka tabeli se uvek vrši ka odabranom, matičnom glavnom serveru, a ovaj, zatim, propagira ažu­riranje ka ostalim glavnim serverima na koje je matična glavna grupa alocirana.

Osvježavanje replikacionih slika se uvijek vrši u asinhronom režimu, propagacijom samih podataka. Moguće je realizovati brzo, ili kompletno osvježavanje. Replikacione slike se raspoređuju u grupe za osvježavanje. Grupa za osvježavanje može sadržati više replikaci­onih slika sa istog servera, kojoj i sama pripada (slika 1.4). U istu grupu za osvježavanje se mogu rasporediti slike iz različitih grupa replikacionih slika, ali se jedna slika može smjestiti u najviše jednu grupu za osvježavanje. U atribute grupe za osvježavanje spadaju i vremenski parametri osvježavanja (trenutak prvog i trenutak svakog sljedećeg osvježavanja slike). Sve slike jedne grupe za osvježavanje se istovremeno osvježavaju, dok se replikacione slike koje nisu raspoređene ni u jednu grupu za osvježavanje, osvježavaju saglasno individualno zadatim vremenskim parametrima osvježavanja.

Osnovne razlike u primeni tehnike replikacije glavnih grupa i replikacije slika su sljedeće:

·       replikacija glavnih grupa dozvoljava repliciranje definicija okidača, indeksa, paketa, po­gleda i sinonima, što replikacija slika ne omogućava,

·       replikacija glavnih grupa dozvoljava samo repliciranje sadržaja kompletne tabele, dok replikacija slika dozvoljava i repliciranje dijelova tabele i repliciranje podataka iz više ta­bela,

·       propagacija ažuriranja pri replikaciji glavnih grupa može, u oba smjera, biti sinhrona ili asinhrona, a propagacija ažuriranja pri replikaciji slika može, samo u smjeru od replikacione slike ka tabeli, biti bilo sinhrona ili asinhrona, dok je osvježavanje replikacionih slika uvijek asinhrono i realizuje se propagacijom podataka, a ne naredbi i

·       glavni server obavlja zadatake otkrivanja i razrješavanja kolizija ažuriranja, o kojima će u sljedećoj tački biti više riječi, dok server replikacionih slika te zadatake ne izvršava.

 

 

15.2.3.4.          Konvergencija podataka i kolizije ažuriranja

 

Već je konstatovano da, pri sinhronoj propagaciji ažuriranja, za očuvanje konzistentnosti podataka u višekorisničkom režimu rada nisu potrebni dodatni mehanizmi, osim mehanizama dvofaznog potvrđivanja transakcije i zaključavanja podataka. To znači da se, uz potpunu primjenu mehanizama SUBP za kontrolu ograničenja baze podataka i punu raspoloživost sistema, može očekivati da će distribuirana baza zadovoljiti uslov globalne konzistentnosti.

Primjena asinhrone propagacije, međutim, uvodi vremensko kašnjenje pri ažurira­nju različitih kopija istih podataka, što dovodi do privremene globalne nekonzistentnosti baze podataka. Da bi se replikacija podataka uspješno primjenila, potrebno je da SUBP posjeduje dodatne mehanizame, čija primjena može garantovati dovođenje baze podataka u konzistentno stanje. Postupno dovođenje baze podataka u konzistentno stanje, koje je bilo narušeno usljed primjene tehnike asinhrone propagacije ažuriranja, naziva se konvergencija podataka.

Ukoliko se primjenjuje osnovna replikacija, propagacija ažuriranja je uvijek jednosmjerna, od osnovnih tabela ka replikacionim kopijama, što znači da će, nakon konačnog vremena, sve replikacione kopije biti osvježene, odnosno dovedene u konzistentno stanje, s obzirom na sadržaj osnovnih tabela. Saglasno tome, konstatuje se da osnovna replikacija s asinhronom propagacijom ažuriranja garantuje konvergenciju podataka.

Ukoliko se primjenjuje simetrična replikacija, propagacija ažuriranja postaje dvosmjerna, od osnovnih tabela ka replikacionim kopijama i obratno. U slučaju primjene asinhro­ne propagacije, može se dogoditi da se isti podaci ažuriraju na različitim lokacijama, u okviru istog intervala vremena između dvije propagacije. To dovodi do problema koji se naziva kolizija ažuriranja. Kolizije ažuriranja dovede bazu podataka u trajno nekonzistentno stanje, što znači da se konvergencija podataka, u takvoj situaciji, ne može garantovati. Zbog toga, kada su u pitanju kolizije ažuriranja, postoje različiti mehanizmi preventivnog i korektivnog djelovanja, čijom primjenom se može garantovati konvergencija podataka.

Osnovni preduslov da bi se kolizije ažuriranja sprečile, ili otkrile i otklonile, jeste da se zabrani modifikacija vrijednosti primarnog ključa tabele, jer zadavanje vrednosti pri­marnog ključa predstavlja jedini način da se podaci u relacionoj bazi adresiraju. Saglasno toj pretpostavci, identifikuju se sljedeće kolizije ažuriranja:

·       kolizija integriteta entiteta,

·       kolizija brisanja i

·       kolizija modifikacije.

Kolizija integriteta entiteta nastaje narušavanjem ograničenja ključa šeme relacije. I pored zabrane modifikacije primarnog ključa, do ove kolizije može doći sprovođenjem sljedećih operacija:

·       dodavanje novih torki s istom vrijednošću ključa u tabelu ili njenu replikacionu kopiju, na najmanje dva različita servera baze podataka,

·       dodavanje nove torke v, u tabelu, ili njenu replikacionu kopiju, na jednom serveru baze podataka, i modifikacija vrijednosti neprimarnog ključa K torke u, takve da je u[Kp(R)] = v[Kp(R)], na drugom serveru baze podataka, pri čemu je u[K] ≠ v[K] i

·       modifikacija vrijednosti neprimarnog ključa, za torke koje imaju iste vrijednosti primarnog ključa, na najmanje dva različita servera baze podataka.

Kolizija brisanja nastaje sprovođenjem sljedećih operacija:

·       brisanje torke s istom vrijednošću primarnog ključa iz tabele, ili njene replikacione kopije, na najmanje dva servera baze podataka i

·       brisanje torke iz tabele, ili njene replikacione kopije, na jednom serveru baze podataka i modifikacija torke s istom vrijednošću primarnog ključa, na drugom serveru baze podata­ka.

Kolizija modifikacije nastaje pokušajem modifikacije vrijednosti istih obilježja u torkama s istom vrijednošću primarnog ključa, na dva različita servera baze podataka.

 

 

Sprječavanje kolizija ažuriranja

 

Da bi se govorilo o postupcima za sprječavanje, ili otkrivanje i razrešavanje navedenih tipova kolizija, neophodno je uvesti tri vrste prava ažuriranja: ekskluzivno, di­namičko i dijeljeno.

Ekskluzivno pravo ažuriranja uvodi ograničenje po kojem se ažuriranje tabele, ili njene replikacione kopije, može sprovoditi samo na jednom serveru baze podataka. Taj server baze podataka ima vremenski neograničeno i isključivo pravo ažuriranja.

Dinamičko pravo ažuriranja takođe uvodi ograničenje po kojem se unos, modifi­kacija ili brisanje bilo koje torke tabele, ili torke njene replikacione kopije, može sprovesti na najviše jednom serveru baze podataka, ali se to pravo prenosi s jednog na drugi server dinamički, tokom vremena. Pri tome, prenos prava ažuriranja torke sa servera na server najčešće biva inicirano modifikacijom vrijednosti nekog, "statusnog" obilježja na serveru koji ima pravo ažuriranja, ili modifikacijom obilježja koje sadrži globalni naziv servera s pra­vom ažuriranja. Neposredno nakon izvršene modifikacije, server gubi pravo ažuriranja. Kada se izvrši propagacija ažuriranja na ciljni server, na njemu se pojavljuje nova vrijednost statusnog obilježja, odnosno vrijednost obilježja s globalnim nazivom servera, i time on automatski dobija pravo ažuriranja.

Dinamičkim pravom ažuriranja se obezbjeđuje da jedan server u sistemu, inicijalno, dobije pravo upisa nove torke u tabelu. Pravo ažuriranja za datu torku se, tokom vremena, može prenositi na ostale servere u sistemu. Pravo ažuriranja za svaku pojedinačnu torku je ekskluzivno, ali je moguće da različiti serveri u sistemu, u istom trenutku, posjeduju pravo ažuriranja za različite torke iste tabele.

 

Primjer 1.13. Data je šema relacije Dokument({DOKIDB, DOKSTAT, DOKDKR, DOKDRE}, {DOKIDB}) pri čemu je DOKIDB identifikacioni broj dokumenta, DOKSTAT status dokumenta, DOKDKR datum kreiranja, a DOKDRE datum realizacije. Za DOKSTAT važi dom(Dokument, DOKSTAT) = {I, K, R}. Vrijednost I označava da dokument ima status "u izradi", vrijednost K označava status "kompletiran", dok vrijednost R označava status "rea­lizovan". Važe, takođe, uslovi integriteta torke:

·       DOKSTAT = I =>  (DOKDKR = ω Λ DOKDRE = ω)*

·       DOKSTAT = K =>  (DOKDKR ≠ ω Λ DOKDRE ≠ ω) i

·       DOKSTAT = R =>  (DOKDKR ≠ ω Λ DOKDRE ≠ ω)

kao i sljedeća pravila poslovanja, koja se implementiraju putem odgovarajućih okidača:

·       dokument inicijalno, pri kreiranju, obavezno dobija status "u izradi" (DOKSTAT = I),

·       dokument koji ima status "u izradi", može promjeniti status samo tako da bude "kompleti­ran",

·       pri modifikaciji statusa dokumenta u "kompletiran" (DOKSTAT = K), zadaje se datum kreiranja i on se, kasnije, ne može modifikovati,

·       kada dokument dobije status "kompletiran" (DOKSTAT = K), njegov status se više ne može modifikovati tako da bude "u izradi",

·       pri modifikaciji statusa dokumenta u "realizovan" (DOKSTAT = R), zadaje se datum realizacije i on se, kasnije, ne može modifikovati i

·       kada dokument dobije status "realizovan" (DOKSTAT = R), njegov status se više ne može modifikovati.

Može se zapaziti da životni ciklus dokumenta započinje statusom "u izradi", koji se, zatim, mijenja u "kompletiran" i, u poslednjoj fazi, prelazi u "realizovan".

Pretpostavlja se da je na server baze podataka A.COM smještena tabela Dokument, a daje na serveru B.COM kreirana replikaciona slika:

CREATE SNAPSHOT SNP_Dokument

FOR UPDATE

AS

SELECT d.DOKIDB, d.DOKSTAT, d.DOKDKR, d.DOKDRE

FROM     Dokument@A.COM d

WHERE  d.DOKSTAT <> T.

Dok će tabela Dokument sadržati sve torke, replikaciona slika SNP_Dokument će sadržati samo one torke koje reprezentuju dokumente sa statusom "kompletiran" i "realizovan". Pri tome, uvodi se pravilo poslovanja po kojem se zabranjuje bilo kakva modifikacija doku­menta na serveru A.COM, nakon što dokument dobije status "kompletiran".

Ovako osmišljeni model obezbjeđuje primjenu tehnike dinamičkog prava ažuriranja. Na početku, nakon kreiranja novog dokumenta, pravo ažuriranja posjeduje jedino server A.COM, jer se jedino na njemu nalaze podaci o novokreiranom dokumentu. Ovaj server zadržava pravo ažuriranja sve dok dokument ima status "u izradi". Modifikacijom vrijednosti obilježja DOKSTAT, kojom dokument dobija status "kompletiran", saglasno identifikovanim pravilima poslovanja, server A.COM gubi pravo ažuriranja dokumenta. Osvježavanjem replikacione slike SNP_Dokument, posmatrani dokument će biti repliciran na server B.COM. S obzirom da je riječ o dinamičkoj replikacionoj slici, zaključuje se da pravo ažuri­ranja dokumenta, sada, pripada isključivo serveru B.COM.

 

Dijeljeno pravo ažuriranja ne uvodi posebna ograničenja na prava ažuriranja po­dataka. To znači da se može dogoditi da isti podaci, na dva različita servera, budu ažurirani u toku istog intervala, između dve sukcesivne propagacije ažuriranja.

Primjena ekskluzivnog ili dinamičkog prava ažuriranja u potpunosti sprečava nastajanje svih nabrojanih kolizija ažuriranja, jer se ne može dogoditi da se u vremenskom intervalu između dvije sukcesivne propagacije, ažuriraju, na primjer, i osnovna tabela i njena replikaciona kopija na drugom serveru. Problem navedenih vrsta prava ažuriranja je, među­tim, u tome što su one, dosta često, neprimjenljive u praksi, jer je priroda nastajanja podata­ka upravo takva da se oni kreiraju na različitim lokacijama u sistemu, što favorizuje primjenu tehnike dijeljenog prava ažuriranja.

Primjena tehnike dijeljenog prava ažuriranja dozvoljava da se, putem posebnih me­hanizama, spriječi nastajanje kolizije integriteta entiteta. Kolizija brisanja i modifikacije obilježja se, u ovom slučaju, ne može spriječiti, već se samo može otkriti i otkloniti.

Kolizija integriteta entiteta se, kod dijeljenog prava ažuriranja, može spriječiti preprojektovanjem dijela šeme baze podataka na dva načina. Prvi od njih je da se, umjesto konk­retne tabele i njene replikacione slike, na svakom od servera predvidi postojanje po jednog horizontalnog fragmenta, sačinjenog putem uslova koji obezbjeđuju zoniranje vrijednosti svih ekvivalentnih ključeva. Pri tome, ovaj način se može smatrati praktično primjenljivim kada odgovarajuća šema relacije posjeduje samo primarni ključ, pošto zoniranje vrijednosti neprimarnog ključa, u praksi, često nije lako ostvariti. Drugi način predstavlja preprojektovanje primarnih ključeva, dodavanjem u ključ obilježja koje predstavlja identifikacionu oznaku servera baze podataka. Drugi način se, u opštem slučaju, ne preporučuje, jer se njime problem ove kolizije rješava samo formalno, a ne i suštinski.

 

 

 

 

Otkrivanje kolizija ažuriranja

 

Ukoliko se donese odluka de se ne sprečava nastajanje kolizija ažuriranja, to znači da se sve kolizije moraju otkriti i razrešiti, kako bi se obezbedila konvergencija podataka ka konzistentnom stanju. Pri tome, SUBP poseduje mehanizme za automatsko otkrivanje koli­zija.

Automatska detekcija kolizija se sprovodi u toku postupka propagacije ažuriranja, na odredišnom serveru, ukoliko se na njemu nalazi makar jedna tabela, ili dinamička repli­kaciona kopija, koja predstavlja predmet propagacije ažuriranja. Pri tome, odredišni server je server na koji se operacije ažuriranja propagiraju, dok polazni server baze podataka predstavlja server na kojem je postupak propagacije iniciran. Ukoliko se na odredišnom serveru nalaze samo statičke replikacione kopije, a ažuriranje statičkih kopija nije dozvolje­no, na takvom serveru nema potrebe ni sprovoditi postupak automatske detekcije kolizija. U tom slučaju, postupcima osvježavanja kopija se garantuje očuvanje konzistentnosti baze podataka.

Ukoliko program za detekciju kolizija, koji se izvršava na odredišnom serveru, pri propagaciji ažuriranja, ustanovi:

·       da je na odredišnom serveru došlo do narušavanja ograničenja primarnog ili nekog dru­gog, ekvivalentnog ključa, smatra se da je nastupila kolizija integriteta entiteta,

·       da ne postoji torka nad kojom treba primjeniti propagiranu operaciju brisanja ili modifi­kacije vrijednosti obilježja, smatra se da je nastupila kolizija brisanja i

·       da se postojeća vrijednost obilježja na odredišnom serveru i prosljeđena stara vrijednost s polaznog servera razlikuju, smatra se da je došlo do kolizije modifikacije.

 

 

Razrješavanje kolizija ažuriranja

 

U opštem slučaju, razrješavanje otkrivenih kolizija može biti:

·       ručno, ili

·       automatsko.

U slučaju da se želi ručno razrješavanje kolizija, SUBP će u rječnik podataka samo upisati informacije o otkrivenim kolizijama i neće biti primjenjeni nikakvi posebni automa­tizmi za razrješavanje tih kolizija. Očekuje se da će otkrivene kolizije razriješiti administrator baze podataka, u saradnji s krajnjim korisnicima.

Primjena automatskog razjrešavanja kolizija podrazumijeva da će projektant tran­sakcija unapred kreirati, ili samo izabrati jednu ili više postojećih predefinisanih metoda za razrješavanje otkrivenih kolizija.

Kolizija integriteta entiteta se, u slučaju primjene dijeljenog prava ažuriranja, može razriješiti tako što se svakom ograničenju ekvivalentnog ključa pridružuje procedura koja će obezbjediti dovođenje podataka u konzistentno stanje. Procedura se pokreće automatski, neposredno nakon detektovanja kolizije integriteta entiteta. Ukoliko je reč o korisnički definisanoj proceduri, odgovornost za očuvanje konzistentnosti leži na projektantu procedure. SUBP može posjedovati i predefinisane procedure za razrješavanje kolizije ovog tipa. Neki od predefinisanih postupaka mogu biti: dodavanje naziva servera ponovljenoj vrijednosti ključa, dodavanje rednog broja ponovljenoj vrijednosti ključa, ili zabrana upisa torke s iden­tičnom vrijednošću ključa.

Kolizija brisanja se, kod dijeljenog prava ažuriranja, može razriješiti primjenom sljedeće tehnike. Dozvoljava se samo logičko brisanje torke, modifikacijom vrijednosti obilježja koje predstavlja indikator aktuelnosti torke. Na taj način, do kolizije brisanja, u formalnom smislu, ne može doći pa SUBP nije u mogućnosti takve kolizije ni da otkrije. Zato se postu­pak otkrivanja kolizija brisanja i dovođenja podataka u konzistentno stanje, koji uključuje i fizičko brisanje neaktuelnih (logički izbrisanih) torki, sprovodi posebno, u režimu paketne obrade, putem korisnički definisanog programa. I u ovom slučaju, projektant takvog prog­rama preuzima odgovornost za očuvanje konzistentnosti baze podataka.

Kolizija modifikacije se odnosi na vrijednosti pojedinačnih obilježja relacije. To znači da, u slučaju primjene dijeljenog prava ažuriranja, SUBP mora omogućiti definisanje postupaka za razrješavanje otkrivene kolizije za svako obilježje, pojedinačno. Kod nekih SUBP postoji mogućnost da se obilježja šeme relacije organizuju u grupe i da se postupak razrješavanja kolizija definiše za svaku grupu obilježja. Pri tome, jedno obilježje šeme rela­cije mora pripadati tačno jednoj grupi.

U nastavku se navode nazivi i načini primjene mogućih metoda za razrješavanje kolizije modifikacije. Svaka od navedenih metoda, kao ulazne argumente, prihvata novu vrijednost obilježja, proslijeđenu u postupku propagacije ažuriranja (novoproslijeđenu vrijednost) i postojeću (staru) vrijednost obilježja na datom serveru baze podataka.

·       Metode "prepiši" i "odbaci" obezbjeđuju da se novoproslijeđena vrijednost obeležja, redom, prihvati kao aktuelna, ili odbaci i zadrži postojeća vrijednost na datom serveru baze po­dataka.

·       Metode "minimalna vrijednost" i "maksimalna vrijednost" obezbjeđuju da se kao aktuelna vrijednost izabere, redom, manja, odnosno veća vrijednost, pri komparaciji postojeće i novoprosljeđene vrijednosti.

·       Metode "najranija vrijednost" i "najkasnija vrijednost" obezbjeđuju da se kao aktuelna vrijednost prihvati, redom, hronološki starija, odnosno hronološki mlađa vrijednost, pri komparaciji postojeće i novoproslijeđene vrijednosti. Ove metode su primjenljive samo za obilježja tipa datum i vrijeme.

·       Metoda "kumulirana vrijednost" obezbjeđuje da se kao aktuelna vrijednost prihvati postoje­ća vrijednost, uvećana za razliku nove i stare prosljeđene vrijednosti. Pri tome, ova metoda, kao argument, prihvata i staru prosljeđenu vrijednost, u postupku propagacije ažuriranja.

·       Metoda "srednja vrijednost" obezbjeđuje da se kao aktuelna vrijednost prihvati aritmetička sredina postojeće i novoprosleđene vrednosti.

·       Metoda "prioritet čvora" obezbjeđuje da se, između postojeće i novoprosljeđene vrijednos­ti, kao aktuelna prihvati ona, koja je nastala na serveru s višim prioritetom. Prioritet servera je, pri tome, potrebno zadati pri konfigurisanju sistema za upravljanje bazama podataka.

·       Metoda "prioritet vrijednosti" obezbjeđuje da se, između postojeće i novoprosljeđene vrijed­nosti, kao aktuelna prihvati ona, za koju je definisan viši prioritet. Prioritet vrijednosti je potrebno, u tom slučaju, zadati unapred.

Treba naglasiti da ne mora svaka od navedenih metoda, u svakoj situaciji, dovesti do razrješavanja identifikovane kolizije. Ukoliko su, na primjer, novoprosljeđena i postojeća vrijednost iste, primjena metoda "minimalna vrijednost" i "maksimalna vrijednost" ne razrješava koliziju modifikacije. Zato postoji mogućnost da se jednoj grupi obeležja ili, u krajnjoj liniji jednom obilježju, može pridružiti više metoda za razrješavanje kolizije modifikacije, pri čemu se uvodi redoslijed primjene metoda. U tom slučaju, na početku se primjenjuje prva me­toda. Ukoliko se njime ne otkloni kolizija, prelazi se na primjenu druge metode. Postupak se, na taj način, nastavlja sve do otklanjanja kolizije, ili do iscrpljivanja i poslednje metode.

Postoje situacije u kojima neke od navedenih metoda nisu u mogućnosti da garantuju konvergenciju podataka. To znači da se može dogoditi da, nakon svih izvršenih propagacija ažuriranja, na dva različita servera baze podataka vrijednost istog obilježja u istoj ta­beli ili replikacionoj kopiji, ne bude ista. Pretpostavlja se da je, u opštem slučaju, replikacija podataka organizovana tako da se, nakon modifkacije podataka u replikacionoj kopiji, ta izmjena propagira samo ka serveru na kojem se nalazi osnovna tabela, a ovaj server inicira osvježavanje svih replikacionih kopija. Taj server je, pri tome, jedini koji u datoj situaciji sprovodi postupak razrješavanja eventualnih kolizija. Može se pokazati da, u tom slučaju, sve metode za razrješavanje kolizija modifikacije garantuju konvergenciju podataka. Pri tome, za metode "najranija vrijednost" i "najkasnija vrijednost" treba predvideti i rezervnu metodu, koja će razrješiti koliziju ukoliko se dogodi da se modifikacija istog podataka, na dva različita servera, dogodila u istom momentu.

 

Primjer 1.14. Posmatra se model replikacije podataka iz primjera 1.12, koji podržava SUBP ORACLE.

Ukoliko se replikacija podataka organizuje samo pomoću tehnike replikacije slika, ostvaren je uslov da se izmena podataka dinamičke replikacione slike propagira samo ka serveru na kojem se nalazi osnovna tabela, a ovaj server inicira osvježavanje svih replikacionih slika. To znači da će sve pobrojane metode razrješavanja kolizije modifikacije garantovati konvergenciju podataka.

Ukoliko se replikacija podataka oranizuje kombinovanom primjenom tehnike repli­kacije glavnih grupa i replikacije slika, postoje dvije mogućnosti: da je bilo koja glavna grupa replicirana na tačno dva servera, ili da je replicirana na više od dva servera baze po­dataka.

U prvom slučaju, konvergenciju podataka garantuju sve metode osim metoda "prepiši", "odbaci" i "srednja vrijednost". Metoda "prioritet vrijednosti" može garantovati kon­vergenciju podataka, pod uslovom da prioritet vrijednosti obilježja odgovara rastućem ili opadajućem redoslijedu same vrijednosti obilježja. Za metode "najranija vrijednost" i "najkas­nija vrijednost" treba, i u ovom slučaju, predvidjeti rezervnu metodu.

U drugom slučaju, bezuslovnu konvergenciju garantuje samo metoda "kumulirana vrijednost". Metoda "prioritet vrijednosti" može garantovati konvergenciju podataka, pod uslo­vom da, kao i u prethodnom slučaju, prioritet vrijednosti obilježja odgovara rastućem ili opadajućem redoslijedu same vrijednosti obilježja. Metoda "najkasnija vrijednost" može garantovati konvergenciju podataka, uz primjenu rezervne metode, a metode "minimalna vrijed­nost" i "maksimalna vrijednost" mogu garantovati konvergenciju podataka samo ako su modifikacije vrijednosti obilježja takve da se vrijednost obilježja samo smanjuje, za metodu "minimalna vrijednost", odnosno samo povećava, za metodu "maksimalna vrijednost".

 

1.3.  Metodološki aspekti projektovanja distribuiranih informacionih sistema

 

Izgradnja i eksploatacija distribuiranog informacionog sistema počiva na istovre­menoj primeni koncepata distribuiranih baza podataka i klijent-server modela obrade po­dataka. U cilju projektovanja distribucije informacionog sistema, potrebno je, pored aktiv­nosti koje se inače sprovode pri projektovanju informacionih sistema, obaviti i sljedeće zadatke:

·       sprovesti analizu opravdanosti realizacije distribuiranog informacionog sistema,

·       identifikovati tipove lokacija distribuiranog informacionog sistema,

·       oblikovati rješenje hardversko-softverske konfiguracije distribuiranog  informacionog sistema i

·       isprojektovati distribuciju informacionog sistema.

Prva tri zadatka se obavljaju putem aktivnosti, koje se, u principu, realizuju u okviru faze strategije, metodologije životnog ciklusa. Projektovanje distribucije informacionog sistema se odnosi na niz aktivnosti koje treba sprovesti u fazama strategije, analize i projektovanja, životnog ciklusa.

 

 

 

1.3.1.          Analiza opravdanosti, tipovi lokacija i konfiguracija distribuiranog informacionog sistema

 

 

Zadatak analize opravdanosti relizacije distribuiranog informacionog sistema je da pruži odgovor na pitanje da li realni sistem, sa stanovišta ciljeva i organizacije poslovanja, uopšte ima, i u kojoj mjeri, potrebe za uvođenjem distribuiranog informacionog sistema i kakve su mogućnosti za uvođenje takvog sistema u upotrebu. U tom smislu, bitno je i da li se mogu, i u kom roku, obezbjediti tehničko-tehnološki, organizacioni, kadrovski i finansij-ski preduslovi za uvođenje distribuiranog informacionog sistema i kakvi se efekti primene distribuiranog sistema očekuju. Na sprovođenje ostalih pobrojanih aktivnosti se može preći samo ako rezultati sprovedene analize budu pozitivni i usvojeni od strane najvišeg rukovod­stva iz realnog sistema.

Aktivnost identifikovanja tipova lokacija distribuiranog informacionog sistema se bazira na pretpostavci da u realnom sistemu postoji više lokacija, na kojima se izvode pre­težno isti procesi. Jedan tip lokacije reprezentuje sve lokacije u realnom sistemu na kojima se izvode isti, ili gotovo isti procesi. Ideja je da se, grupisanjem sličnih ili istih lokacija po tipovima, postupci projektovanja distribucije baze podataka i aplikacija generalizuju i, samim tim, pojednostave.

 

Primjer 1.15. Posmatra se realni sistem banke, čija organizacija je, u osnovi, opisana u okviru primjera 1.2. Pretpostavlja se da su, analizom funkcionalne, organizacione i prostorne strukture banke, projektanti informacionog sistema došli do zaključka da se u svim ekspoziturama odvijaju procesi približno istih tipova, iako postoje manje razlike, kada su u pitanju: vrste usluga koje pojedine ekspoziture mogu pružiti svojim korisnicima i način organizacije rada samih ekspozitura. Pri tome, težnja rukovodstva banke je da se, u dogledno vrijeme, sve ekspoziture osposobe za pružanje svih predviđenih usluga, što znači da svaku ekspozituru, kada su u pitanju funkcije informacionog sistema, treba tretirati na isti način. Saglasno tome, uvodi se tip lokacije EKSPOZITURA, koji reprezentuje sve ekspozi­ture u sistemu. Na sličan način, sve filijale u sistemu će biti reprezentovane tipom lokacije FILIJALA, dok će za centralu banke biti uveden tip lokacije CENTRALA, bez obzira što on reprezenruje samo jednu lokaciju u sistemu.

 

Projektovanje hardversko-softverske konfiguracije informacionog sistema se, ge­neralno, odnosi na:

·       oblikovanje idejnog rješenja hardverske i komunikacione infrastrukture sistema i

·       definisanje   konfiguracije   sistemskog   softvera   (operativnih   sistema,   sistema   za upravljanje bazama podataka, kao i programskih paketa za eksploataciju i razvoj aplikacija informacionog sistema).

Kada je u pitanju ova aktivnost, sa stanovišta projektovanja distribucije sistema, potrebno je:

·       za svaki tip lokacije da se specificira da li, i u kom broju, postoje računari koji imaju ulogu servera baze podataka i servera aplikacija,

·       za svaki tip lokacije da se uvede šema imenovanja servera baze podataka i servera aplikacija, koja će obezbjediti jedinstvenu identifikaciju servera i budućih lokalnih baza podataka, u sistemu i

·       za svaku lokaciju u sistemu, saglasno specifikaciji konfiguracije po tipu lokacije, naznačiti servere baze podataka, aplikacione servere i klijente i imenovati servere, sagla­sno uvedenoj šemi imenovanja.

Važno je da se oblikovanje idejnog rješenja komunikacione infrastrukture i izbor sistemskog softvera obave tako da distribuirani informacioni sistem može, za što duži pe­riod, zadovoljiti zahtjeve traženog stepena: integrisanosti, pouzdanosti, raspoloživosti, performantnosti pri radu, fleksibilnosti za održavanje i fleksibilnosti za nadogradnju, kako arhitekture, tako i samog informacionog sistema.

 

1.3.2.          Projektovanje distribucije informacionog sistema

 

Postupci projektovanja distribucije informacionog sistema se realizuju u sljedećim fazama metodologije životnog ciklusa: strategija, analiza i projektovanje. Ovi postupci se sprovode u cilju dobijanja sljedećih dokumenata:

·       specifikacija distribucije aplikacija po tipovima lokacija,

·       specifikacija distribucije baze podataka po tipovima lokacija i konkretnim lokacijama i

·       specifikacija replikacije podataka u distribuiranoj bazi podataka.

Specifikacija distribucije aplikacija po tipovima lokacija treba da sadrži, za svaki tip lokacije i svaki predviđeni aplikacioni server na tom tipu lokacije, listu aplikacija infor­macionog sistema, koje će na tom aplikacionom serveru biti instalirane. Takva specifikacija se naziva distribuciona šema aplikacija.

Specifikacija distribucije baze podataka po tipovima lokacija i konkretnim lokaci­jama treba, za svaki tip lokacije i svaku konkretnu lokaciju, da sadrži dio šeme baze poda­taka, koji se na tom tipu lokacije, odnosno lokaciji, implementira. Ovakva specifikacija se naziva distribuciona šema baze podataka.

Specifikacija replikacije podataka treba da, za svaki tip lokacije, kao i svaku konk­retnu lokaciju, definiše sve replikacione kopije, kao i načine njihovog ažuriranja. Ova speci­fikacija definiše replikacionu šemu baze podataka.

U nastavku teksta, više pažnje se posvećuje konceptualnom, a zatim i implementacionom projektovanju distribucije informacionog sistema.

 

 

1.3.2.1               Konceptualno projektovanje distribucije informacionog sistema

 

Konceptualno projektovanje distribucije informacionog sistema obuhvata aktiv­nosti projektovanja:

·       distribucione šeme transakcionih programa i

·       konceptualne distribucione šeme baze podataka.

 

Distribuciona šema transakcionih programa

 

Distribuciona šema transakcionih programa sadrži specifikaciju raspodjele tran­sakcionih programa po tipovima lokacija. Za svaki transakcioni program informacionog sistema*, zadaju se tipovi lokacija, na kojima će se on izvoditi. Distribuciona šema transak­cionih programa se može organizovati u obliku matrice Transakcioni programi/Tipovi lo­kacija. Za svaki element ove matrice, koji reprezentuje vezu jednog programa s jednim tipom lokacije, zadaju se sljedeći parametri:

·       učestalost izvršavanja programa P na tipu lokacije L, u oznaci UP (P, L), s mogućim vrijednostima opisnog karaktera: V (visoka), S (srednja) i N (niska) i

·       kritičnost izvršavanja programa P za ukupno poslovanje na tipu lokacije L, u oznaci KP(P, L), s mogućim vrijednostima opisnog karaktera: V (visoka), S (srednja) i N (niska).

Ukoliko transakcioni program P nije raspoređen na tip lokacije L, parametri UP(P, L) i KP(P, L) postaju nedefinisani, a odgovarajuća polja matrice ostaju prazna.

Matrica Transakcioni programi/Tipovi lokacija se može izraditi na osnovu informacija o organizacionoj, funkcionalnoj i prostornoj strukturi realnog sistema i informacija o povezanosti elementarnih procesa s organizacionim jedinicama i organizacionih jedinica s lokacijama u sistemu.

Distribuciona šema transakcionih programa predstavlja osnov za izradu koncep­tualne distribucione šeme baze podataka i distribucione šeme aplikacija. Distribuciona šema aplikacija se izrađuje u toku implementacionog projektovanja.

 

Primjer 1.16. Posmatra se studija slučaja "Komercijalna funkcija", koja je razma­trana i u glavi 11, glavi 12 i prilogu P6. Neka su u realnom sistemu ove studije slučaja identifikovana tri tipa lokacije: CENTRALA, PREDSTAVNIŠTVO i SKLADIŠTE i neka je, na svakom od ovih tipova lokacija, predviđeno postojanje jednog servera baze podataka i jednog aplikacionog servera. Posmatraju se elementarne funkcije "Provjera kupca i eviden­tiranje porudžbine" i "Izdavanje robe i izrada otpremnice", koja objedinjava funkcije:

 

"Izdavanje robe i ažuriranje zaliha" i "Izrada otpremnice"*. Neka ove elementarne funk­cije reprezentuju istoimene transakcione programe. Na slici 1.5 je prikazana matrica Tran­sakcioni programi/Tipovi lokacija. Uočljivo je da se na tipu lokacije PREDSTAVNIŠTVO izvode oba programa. To je posljedica načina organizacije realnog sistema, po kojoj preds­tavništva imaju ovlašćenja za obavljanje poslova prodaje, a u okviru svakog predstavništva, nalazi se priručno skladište robe.

 

 

Slika 1.5.

 

Konceptualna distribuciona šema baze podataka

 

Cilj projektovanja konceptualne distribucione šeme baze podataka je izrada speci­fikacije u kojoj će se, za svaki tip lokacije, prikazati nazivi potrebnih tipova s potrebnim skupom obilježja i ulogama na toj lokaciji. Ova specifikacija se može prikazati putem mat­rice ER Tipovi/Tipovi lokacija. Za svaki element ove matrice, koji reprezentuje vezu jednog tipa T s jednim tipom lokacije L, zadaju se sljedeći podaci:

·       skup obilježja tipa T na tipu lokacije L, u oznaci Q(T, L),

·       uloga tipa tipa T na tipu lokacije L, u oznaci Role(T, L), pri čemu je Role(T, L)Î{R, U}. Simbol R ("read") označava da se na tipu lokacije L može obavljati samo operacija čita­nja podataka, dok U ("update") označava da se na tipu lokacije L može obavljati i čitanje i ažuriranje podataka,

·       selektivnost pojava tipa T na tipu lokacije L, u oznaci Sel(T, L), pri čemu je Sel(T, L)Î{S, D}. Ukoliko na svim lokacijama datog tipa lokacije mogu, u principu, egzistirati sve pojave tipa T, tada se zadaje Sel(T, L) = S ("sve"), a ako na konkretnim lokacijama datog tipa mogu egzistirati samo određene pojave tipa T (takve da zadovoljavaju neko svojstvo), tada se zadaje Sel(T, L) = D ("djelimično"),

·       aktuelnost pojava tipa T na tipu lokacije L, u oznaci Akt(T, L), pri čemu je Akt(T, L)Î{T, D, N}. Ukoliko se na tipu lokacije zahtjeva trenutna aktuelnost podataka, zadaje se Akt(T, L) = T ("trenutna"), ako se zahtjeva dnevna aktuelnost, zadaje se Akt(T, L) = D ("dnevna"), a ako je aktuelnost nedeljna, ili višenedeljna, zadaje se Akt(T, L) = N ("nedjeljna") i

·       stepen raspoloživosti pojava tipa T na tipu lokacije L, u oznaci Ras(T, L), pri čemu je Ras(T, L)Î{V, Z, N}. Ukoliko se na tipu lokacije zahtjeva visoka raspoloživost podata­ka, sa stanovišta kritičnosti poslovanja, zadaje se Ras(T, L) = V ("visoka"), ako se zahtje­va značajna raspoloživost,  zadaje  se Ras(T,  L) = Z ("značajna"),  a  ako  stepen raspoloživosti nije značajan za poslovanje, zadaje se Ras(T, L) = N ("niska").

Ukoliko tip T nije u vezi s tipom lokacije L, odgovarajuća polja matrice se ne popunjavaju, a vrijednosti Q(T, L), Role(T, L), Sel(T, L), Akt(T, L) i Ras(T, L) ostaju nedefmisane.

Da bi se formirala matrica ER Tipovi/Tipovi lokacija, koristi se matrica Transak­cioni programi/Tipovi lokacija i specifikacije eksternih šema za transakcione programe. Tip lokacije treba da obuhvati sve one ER tipove, koji se pojavljuju u eksternoj šemi makar jednog transakcionog programa koji se na tom tipu lokacije izvodi. Pri tome, Q(T, L) pred­stavlja uniju svih skupova obeležja tipa T u eksternim šemama transakcionih programa koji se na tom tipu lokacije izvršavaju. Zadaje se Role(T, L) = R, ako u svim eksternim šemama, vezanim za tip lokacije L, važi daje Role(T) = {r}, što znači da je dozvoljena samo opera­cija čitanja podataka. U suprotnom, ako postoji eksterna šema, vezana za L, takva da je {r}ÌRole(T), što znači da je dozvoljeno i ažuriranje podataka, zadaje se Role(T, L) = U. Informacije, neophodne za zadavanje vrijednosti parametara Sel(T, L), Akt(T, L) i Ras(T, L), neophodno je prikupiti u postupku snimanja i analize korisničkih zahtjeva.

Konceptualnu distribucionu šemu baze podataka čine konceptualna ER šema baze podataka i matrica ER Tipovi/Tipovi lokacija. Ona predstavlja osnov za izgradnju distribucione i replikacione šeme baze podataka, na implementacionom nivou.

 

Primjer 1.17. Posmatra se studija slučaja "Komercijalna funkcija". Tipovi loka­cija su definisani u primjeru 1.16, matrica Transakcioni programi/Tipovi lokacija je data na slici 1.5, specifikacija eksterne šeme za transakcioni program "Provjera kupca i evidentiranje porudžbine" je data putem slika 11.11, 11.12, 11.13 i 11.14, specifikacija eksterne šeme za transakcioni program "Izdavanje robe i izrada otpremnice" je data putem slika 11.16, 11.17 i 11.18, dok je specifikacija konceptualne šeme baze podataka data putem slika 11.16, 11.31 i 11.32. Na osnovu svih navedenih specifikacija, kao i na osnovu rezul­tata snimanja i analize korisničkih zahtjeva, dolazi se do matrice ER Tipovi/Tipovi lokacija, koja je prikazana na slikama 1.6 i 1.7.

Pošto se transakcioni program "Izdavanje robe i izrada otpremnice" ne koristi na tipu lokacije CENTRALA, zaključuje se da ni ER tipovi Zag_Otp, Prima, Postaje, Stav_Otp i Pretvara_se_u nisu prisutni na tipu lokacije CENTRALA. To znači da ni vrijednosti Q(T, L), Role(T, L), sel(T, Z,), Akt(T, L) i Ras(T, L), u matrici ER Tipovi/Tipovi lokacija, za navedene ER tipove i tip lokacije CENTRALA, nisu definisane.

 

Tipovi lokacija	CENTRALA	PREDSTA VNIŠTVO	SKLADIŠTE
ER tipovi	Q	Q	Q
Skladište	IDS, NAS	IDS, NAS	IDS, NAS
Roba	IDR, NAR, JEM	IDR, NAR, JEM	IDR, NAR, JEM
Kupac	JDK, NAK, ADR, BON	IDK, NAK, ADR, BON	IDK, N AK, ADR
Zaliha	RAS	RAS, ŽAL	ŽAL
Zag Nal	BRN, OSN, STN	BRN, OSN, STN	BRN, OSN, STN
Pravi se za	IDK	IDK	IDK
Stav Nal	KOL, STA	KOL, STA	KOL, STA
Zag Otp		BRO	BRO
Prima		IDK	IDK
Postaje		BRN	BRN
Stav_Otp		Ø	Ø
Pretvara se u		Ø	Ø

 

Slika 1.6.

 

 

 

Tipovi lokacija

CENTRALA

PREDSTAVNIŠTVO

SKLADIŠTE

ER tipovi

Role

Sel

Akt

Ras

Role

Sel

Akt

Ras

Role

Sel

Akt

Ras

Skladište

R

S

D

Z

R

s

T

V

R

D

T

V

Roba

R

S

D

Z

R

s

T

V

R

S

T

V

Zaliha

U

s

D

Z

U

s

T

V

U

S

T

V

Kupac

U

s

D

Z

U

s

T

V

R

S

T

V

Zag Nal

U

s

D

Z

U

D

T

V

R

D

T

V

Pravi se za

u

s

D

Z

U

S

T

V

R

S

T

V

Stav Nal

u

s

D

Z

U

D

T

V

U

D

T

V

Zag Otp

U

D

T

V

U

D

T

V

Prima

U

S

T

V

U

S

T

V

Postaje

U

D

T

V

u

D

T

V

Stav Otp

U

D

T

V

u

D

T

V

Pretvara se u

U

D

T

V

u

D

T

V

 

Slika 1.7.

 

 

Saglasno činjenici da se transakcioni program "Provjera kupca i evidentiranje porudžbine" ne koristi na tipu lokacije SKLADIŠTE, ali da se na ovom tipu lokacije koristi program "Izdavanje robe i izrada otpremnice" i da za eksternu šemu ovog programa važi da je Role(Kupac) = {r}, Role(Zag_Nal) = {r} i Role(Pravi_se_za) = {r}, slijedi da je Role(Kupac, SKLADIŠTE) = R, Role(Zag_Nal, SKLADIŠTE) = R i Role(Pravi_se_za, SKLADIŠTE) = R.

Može se zapaziti da u matrici ER Tipovi/Tipovi lokacija, za ER tipove Stav_Otp i Pretvara_se_u i za tipove lokacija PREDSTAVNIŠTVO ili SKLADIŠTE, važi Q(T, L) = Ø. Ovo je posljedica toga da ni sami ER tipovi Stav_Otp i Pretvara_se_u nemaju definisano ni jedno obilježje u ER šemi baze podataka. Na lokacijama tipa PREDSTAVNIŠTVO i SKLADIŠTE će, bez obzira što za ER tipove Stav_Otp i Pretvara_se_u, važi Q(T, L) = Ø, biti prisutne pojave ovih tipova. S druge strane, isti ER tipovi na tipu lokacije CENTRALA nemaju definisane vrijednosti za Q(T, L), Role(T, L), Sel(T, L), Akt(T, L) i Ras(T, L), odakle slijedi da njihova upotreba na tipu lokacije CENTRALA nije predviđena.

 

15.3.2.2.          Implementaciono projektovanje distribucije informacionog sistema

 

Implementaciono projektovanje distribucije informacionog sistema obuhvata ak­tivnosti projektovanja:

·       distribucione šeme aplikacija,

·       distribucione šeme baze podataka i

·       replikacione šeme baze podataka.

 

 

Distribuciona šema aplikacija

 

Dok se na konceptualnom nivou sprovodio postupak projektovanja distribucione šeme transakcionih programa, na implementacionom nivou se vrši raspoređivanje cjelokupnih aplikacija informacionog sistema na tipove lokacija, odnosno vrši se projektovanje dis­tribucione šeme aplikacija.

Distribuciona šema aplikacija sadrži specifikaciju raspodjele aplikacija informaci­onog sistema po tipovima lokacija i aplikacionim serverima, predviđenim na tipu lokacije. Za svaku aplikaciju, zadaju se tipovi lokacija i aplikacioni serveri, na kojima će se ona iz­voditi. Distribuciona šema aplikacija se može organizovati u obliku matrice Aplikacije/Tipovi lokacija. Svaki element ove matrice, koji reprezentuje vezu jedne aplikacije s jednim tipom lokacije i aplikacionim serverom, predstavljen je pomoću parametra Install(A, L, AS)Î{I, ◊}, pri čemu vrijednost I ("instalira se") označava da aplikaciju A treba instalirati na tipu lokacije L i aplikacionom serveru AS, dok simbol ◊ predstavlja "praznu" vrijednost u matrici i označava da se aplikacija A ne instalira na tipu lo­kacije L i aplikacionom serveru AS. Simbol ◊ se, u prikazu matrice, izostavlja.

Distribuciona šema aplikacija se formira na osnovu matrice Transakcioni programi/Tipovi lokacija. Pri tome, pretpostavlja se da su aplikacije strukturirane tako da svaka pokriva potrebe jednog radnog mjesta u realnom sistemu. To znači da se, nakon sprovedenog postupka raspoređivanja aplikacija na tipove lokacija, ne bi smjelo dogoditi da na ne­kom tipu lokacije ostane transakcioni program, koji nije obuhvaćen ni jednom aplikacijom, niti da je na tip lokacije instaliran transakcioni program, koji se neće tu i koristiti.                                                                                                                                                                                                                                                                                                                                                                                                                                         

Odluka o tome da li aplikaciju treba na posmatranom tipu lokacije i aplikacionom serveru instalirati, donosi se ekspertskom procjenom, na osnovu sadržaja matrice Transakci­oni programi/Tipovi lokacija. Ukoliko aplikacija, pretežno, sadrži transakcione programe za koje na tipu lokacije važi da su vrijednosti za učestanost i kritičnost: visoka ili srednja (UP(T, L) =V, ili UP(T, L) = S, KP(T, L) = V, ili KP(T, L) = S), donosi se odluka da se aplikacija instalira na tom tipu lokacije, a u matrici Aplikacije/Tipovi lokacija se, za odab­rane aplikacione servere na tipu lokacije, zadaje lnstall(A, L, AS) = I. Ukoliko se, eksperts­kom procjenom, dođe do zaključka da aplikaciju ne treba na posmatranom tipu lokacije in­stalirati, iako ona sadrži transakcione programe koji su za taj tip lokacije bitni, to ne znači da korisnici aplikaciju ne mogu da upotrebljavaju. To samo znači da se korisnicima mora obezbjediti mogućnost korišćenja "usluga" alternativnog aplikacionog servera na udaljenoj lokaciji, na kojem je posmatrana aplikacija instalirana.

 

Primjer 1.18. Posmatra se studija slučaja "Komercijalna funkcija". Pretpostavlja se da je, za potrebe izvođenja radnih zadataka, vezanih za studiju slučaja, na tipovima loka­cija CENTRALA i SKLADIŠTE predviđeno postojanje po jednog aplikacionog servera, koji su, redom, označeni kao AS.<lok>.C.X i AS.<lok>.S.X, gde <lok> predstavlja oznaku konkretne lokacije datog tipa, na kojoj će se server nalaziti. Na tipu lokacije PREDSTAVNIŠTVO je predviđeno postojanje dva aplikaciona servera- jednog za podršku komercijal­nih poslova, označenog kao AS1.<lok>.P.X, a drugog za podršku skladišnog poslovanja, označenog kao AS2.<lok>.P.X. Pretpostavlja se, takođe, da su formirane dvije aplikacije: "Prodaja" i "Skladišno poslovanje". Aplikacija "Prodaja" sadrži i transakcioni program "Provjera kupca i evidentiranje porudžbine", dok aplikacija "Skladišno poslovanje" obuhvata i transakcioni program "Izdavanje robe i izrada otpremnice". Na slici 1.8 je pri­kazan izgled matrice Aplikacije/Tipovi lokacija.

 

 

Tipovi lokacija	CENTRALA	PREDSTAVNIŠTVO		SKLADIŠTE
Aplikacije	AS.<lok>.C.X	AS1<lok>.P.X	AS2.<lok>.P.X	AS.<lok>.S.X
Prodaja	I	I
Skladišna poslovanje			I	I

 

Slika 1.8.

 

Distribuciona šema baze podataka

 

Kao što je već rečeno, ideja formiranja distribucione šeme baze podataka je da se za svaki tip lokacije i svaku konkretnu lokaciju specificira dio šeme baze podataka, koji se na tom tipu lokacije, odnosno lokaciji, implementira. Pri tome, distribuciju šeme baze po­dataka po lokacijama treba tako organizovati, da se izbjegne svako nepotrebno ponavljanje (redundansa) podataka u bazi. Drugim riječima, kao i u slučaju oblikovanja implementacone šeme baze podataka koja se nalazi u najmanje trećoj normalnoj formi, teži se svođenju redundanse podataka na minimum.

 

 

 

Slika 1.9.

 

 

Može se postići, što će u daljem tekstu biti detaljnije obrazloženo, da se uvođe­njem distribucije šeme baze podataka, osim kada je riječ o ponavljanju vrijednosti primarnih ključeva, ne povisi stepen redundantnosti podataka, određen samom implementacionom

šemom baze podataka. Ovako sačinjena distribucija se naziva i čistom distribucijom šeme baze podataka. Tehnika koja omogućava ostvarenje čiste distribucije je fragmentacija šeme baze podataka.

Ideja uvođenja pojma fragmentacije šeme baze podataka je u tome da se izvrši "particioniranje" šeme baze podataka na dijelove, koji će predstavljati lokalne šeme baze podataka. Particioniranjem se formira fragmentaciona šema baze podataka. Raspoređiva­njem fragmenata šeme baze podataka na tipove lokacija dobija se distribuciona šema baze podataka, koja sadrži lokalne šeme baze podataka, koje se implementiraju na odgovaraju­ćim serverima baze podataka. Ilustracija ovog postupka je data na slici 1.9. U nastavku teksta, uvode se, i detaljnije objašnjavaju, pojmovi fragmentacione i distribucione šeme baze podataka.

Pojam fragmentacije će, u ovoj tački, biti uveden koristeći se relacionim modelom podataka i pojmom šeme relacije N(R, C), s nazivom N, skupom obilježja R i skupom ograničenja C, koji obuhvata skup ključeva K i specifikaciju integriteta torke (R). Primarni ključ šeme relacije simbolizuje oznaka Kp(R).

 

Definicija 1.3. Fragment šeme relacije N(R, C), C = K È { (R)}, u oznaci F(N), ili alternativno F(R, C), predstavlja šemu:

 

(RF,CF),

 

gde je RF skup obilježja fragmenta za koji važe uslovi RF Í R i Kp(R) Î RF, a CF skup lokal­nih ograničenja fragmenta, oblika CF  = KF È  { (RF)}, za koji je KF  skup ključeva, takav da važi

 

KF = {K Î K|K Í RF} Λ Kp(RF) = Kp(R),

 

a  (RF) specifikacija integriteta torke fragmenta*, oblika:

 

(RF) ={(F(N),A)|A Î RF }.

 

Za svaki integritet vrijednosti obilježja (F(N),A)Î(RF), čija specifikacija ima oblik

 

(Dom(F(N), A), Con(F(N), A), Null(F(N), A), Def(F(N), A)),

 

moraju da budu ispunjeni sljedeći uslovi:

 

·       specificirani domen obilježja je isti kao kod polazne šeme relacije:

 

Dom(F(N), A) = Dom (N, A),

 

·       specifikacija nula vrijednosti je ista kao kod polazne šeme relacije:

 

Null(F(N), A) = Null(N, A),

 

·       specifikacija uslova integriteta vrednosti obeležja je oblika:

 

Con(F(N), A) = Con(N, A)|RF Λ ConF (A),

 

gde je sa Con(N, A)|RF  označena projekcija uslova integriteta torke Con(N, A) na skup obilježja RF, a sa ConF (A) je označen uslov horizontalne fragmentacije, koji se definiše na slobodan način, poštujući pravila za formiranje regularnog izraza Con(F(N), A),

·       predefinisana vrijednost obilježja fragmenta je, ako je to moguće, ista kao i predefinisana vrijednost obilježja šeme relacije, a inače je to proizvoljno izabrana vrijednost iz skupa mo­gućih vrijednosti obilježja u fragmentu, odnosno:

 

Def(N,A) Í dom(F(N), A) =>  Def(F(N), A)  = Def(N,A) Λ

   Def(N,A) Ë dom(F(N), A) =>  Def(F(N), A) Í dom(F(N), A).

 

Iz prethodne definicije je uočljivo da fragment šeme relacije N(R, C) može sadržati sva, ili samo neka obilježja skupa R, ali da, obavezno, sadrži primarni ključ šeme relacije Kp(R). Skup uslova horizontalne fragmentacije ograničava koje torke iz relacije r(N) mogu biti sadržane i u odgovarajućoj pojavi fragmenta F(N). Pri tome, za formiranje uslova integ­riteta torke Con(F(N), A) se mogu upotrebiti samo obilježja iz skupa RF.

Kada je u pitanju odnos skupova ograničenja C i CF, može se zaključiti da važi KF = K|RF i (RF) |= (R)|RF, što znači da važi implikacija CF  |= C| RF .

Saglasno mogućnostima koje daje definicija 1.3, postoje sljedeće vrste fragme­nata:

·       trivijalni fragment, u oznaci F(N) = N, ako važi RF = R i CF º C,

·       vertikalni fragment, ako važi RF Ì R i CF º C| RF,

·       horizontalni fragment, ako važi RF = R i CF ¹ C i

·       kombinovani (horizontalno-vertikalni) fragment, ako važi RFÌR i CF ¹ C| RF.

 

Zahtjev za vertikalni fragment CF º C|RF se svodi na to da mora biti obezbjeđena ekvivalencija (RF) |º (R)|RF, što znači da su svi uslovi horizontalne fragmentacije ConF (A), A Î RF, u tom slučaju, nedefinisani (ConF (A) = Δ), ili trivijalni.

Zahtjev za horizontalni fragment CF ¹ C znači da ne važi implikacija (R) |= (RF) odakle slijedi da bar jedan uslov horizontalne fragmentacije ConF (A), A Î RF, nije trivijalan. Slično, u slučaju zahtjeva kombinovanog fragmenta CF ¹ C| RF  mora bar jedan uslov hori­zontalne fragmentacije ConF (A), A Î RF, biti definisan i netrivijalan.

Skup fragmenata implementacione šeme baze podataka se može označiti kao

 

SF={F1(N1),...,Fn(Nk)}.

 

Posmatra se bilo koja šema relacije N(R, C)ÎS. Sa SF(N) će biti označen skup svih fragmenata koji odgovara šemi relacije N(R,C):

 

SF(N)={F(N)|F(N)ÎSF}.

 

Neka je data bilo koja relacija nad šemom N(R, C), r(N)ÎSAT(R, C). Korespodentna pojava fragmenta F(N), s obzirom na relaciju r(N), u oznaci r(F(N)), formira se projektovanjem relacije r na skup obilježja RF i selekcijom samo onih torki koje zadovolja­vaju uslove horizontalne fragmentacije ConF (A), za svaki A Î RF:

 

r(F(N))=sSel(pRF(r(N))),

 

pri čemu formula selekcije Sel ima oblik konjunkcije:

 

Sel=   Λ       (ConF (A)).

                                                             A Î RF

 

Jedan od ciljeva projektovanja distribucione šeme baze podataka je formiranje skupa fragmenata SF, koji će zadovoljiti uslove kompletnosti, disjunktnosti i konzervacije ograničenja.

Uslov kompletnosti (potpunosti) skupa fragmenata SF zahtjeva da, za svaku šemu relacije N(R, C) šeme baze podataka (S,I), važi da su sva obilježja iz skupa R obuhvaćena nekim fragmentom F(N)ÎSF, odnosno:

 

 

(1.3)                                       ("N(R, C)ÎS)("AÎR)($F(N)ÎSF)(AÎRF).

 

Saglasno ovoj formuli, zaključuje se da uslov kompletnosti daje garanciju da će svako obilježje šeme baze podataka biti obuhvaćeno barem jednim fragmentom iz skupa SF.

Uslov disjunktnosti (nepresječnosti) skupa fragmenata SF zahtjeva da, za bilo koja dva različita fragmenta Fi(N) i Fj(N), nad istom šemom relacije N, sa skupovima obeležja Rfi i RFj, budu ispunjeni sljedeći uslovi:

·       ako je Rfi = RFj, ne sme da postoji torka relacije r(N) takva da bi, istovremeno, njena restrikcija na skup obeležja Rfi bila sadržana i u pojavi fragmenta r(Fi (N))  i u pojavi fragmenta r(Fj,(N)):

 

(1.2)

   ("r(N)ÎSAT(R,C))("Fi(N),Fj(N)ÎSF(N))(Fi(N)¹Fj(N)ΛRfi=RFjÞr(Fi(N))Çr(Fj,(N))=Æ)  i

·       ako je Rfi ¹ RFj, presek ova dva skupa obilježja mora da bude primarni ključ šeme rela­cije, odnosno:

 

(1.3)                        ("Fi(N),Fj(N)ÎSF(N))( Rfi ¹ RFjÞ RfiÇRFj=Kp(R)).

 

Uslov (1.3) zahtjeva da svako obilježje šeme baze podataka, koje nije sadržano ni u jednom primarnom ključu, mora pripadati najviše jednom fragmentu skupa SF. U kombinaciji s uslovom kompletnosti, to znači da svako obilježje koje ne pripada ni jednom primarnom ključu, mora pripadati tačno jednom fragmentu.

Konjunkcija uslova (1.2) i (1.3) garantuje da će skup SF biti tako formiran da za svaku torku t, bilo koje relacije r(N), N(R, C)ÎS, važi da njena restrikcija na skup obilježja RF, bilo kog fragmenta F(N), pri čemu je Kp(R)ÌRF, pripadala pojavi tačno jednog fragmenta F'(N)ÎSF.

Na slici 1.10 je dat vizuelni prikaz horizontalne fragmentacije šeme relacije, dok je na slici 1.11 dat vizuelni prikaz vertikalne fragmentacije šeme relacije, pri čemu je gra­fička predstava fragmentacije takva da simbolizuje zadovoljenje uslova kompletnosti i dis­junktnosti.

 

 

 

 

 

 

 

 

 

 

          Slika 1.10.

 

 

 

 

           Slika 1.11.

 

Uslov konzervacije ograničenja skupa fragmenata SF zahtjeva da je, za svaku šemu relacije N(R, C)ÎS i svako od lokalnih ograničenja iz skupa C, zadovoljeno da postoji fragment F(N)ÎSF, takav da navedeno ograničenje pripada skupu CF, odnosno moraju da važe uslovi:

 

(1.4)               ("N(R, C)ÎS)("KÎK)($F(N)ÎSF)(KÎKF)  i

 

(1.5)                          ("N(R, C)ÎS)("(N,A)Î (R))( $F(N)ÎSF)(( RF)|= (N,A)).

 

Ostvarenjem uslova kompletnosti i disjunktnosti, obezbjeđuje se da se vrijednost nekog obilježja, koje nije sadržano u primarnom ključu, za bilo koju pojavu šeme relacije, pojavljuje na tačno jednom mestu, odnosno u okviru pojave tačno jednog fragmenta. Uslov konzervacije ograničenja i uslov CF |= C|RF, koji je posljedica definicije 1.3, obezbjeđuju da se fragmentacijom šema relacija ne izgube postojeća ograničenja šeme baze podataka. Pos­ljedica definicije 1.3, po kojoj je KF = K|RF i ( RF) |= (R)| RF, i uslov konzervacije ograničenja, impliciraju da se u šemi baze podataka jedino mogu "postrožiti" ograničenja torke, uslovima horizontalne fragmentacije. Osim uslova horizontalne fragmentacije, ni­jedno drugo ograničenje se ne može, fragmentacijom, dodati u šemu baze podataka.

 

 

Definicija 1.4. Fragmentaciona šema baze podataka predstavlja strukturu

(S, I, SF),

 

pri čemu je (S, I) relaciona šema baze podataka, a SF skup fragmenata koji zadovoljava uslove kompletnosti, disjunktnosti i konzervacije ograničenja.

 

Krajnji cilj projektovanja distribucione šeme baze podataka je izrada specifikacije u kojoj će se, za svaku lokaciju, prikazati fragmenti koji se na tu lokaciju smještaju, pri čemu se svaki fragment mora pojaviti na tačno jednoj lokaciji. Koraci projektovanja distribucione šeme baze podataka su sljedeći:

·           formiranje matrice Šeme relacija/Tipovi lokacija,

·           vertikalna fragmentacija implementacione šeme baze podataka i formiranje matrice Ver­tikalni fragmenti/Tipovi lokacija i

·           horizontalna fragmentacija vertikalno fragmentirane šeme baze podataka i formiranje matrice Fragmenti/Lokacije.

Prvi korak projektovanja distribucione šeme baze podataka predstavlja

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

formiranje specifikacije u kojoj će se, za svaki tip lokacije, prikazati nazivi neophodnih šema relacija s potrebnim skupom obilježja i ulogama na toj lokaciji. Drugim rečima, formira se matrica Šeme relacija/Tipovi lokacija, na osnovu sadržaja matrice ER Tipovi/Tipovi lokacija, relacione šeme baze podataka i specifikacija podšema. Sadržaj matrice Šeme relacija/Tipovi lokacija je analogan sadržaju matrice ER Tipovi/Tipovi lokacija. Za svaki element ove mat­rice, koji reprezentuje vezu jedne šeme relacije N s jednim tipom lokacije L, zadaju se skup obilježja R(N, L), uloga Role(N, L)Î{R, U}, selektivnost torki Sel(N, L)Î{S, D}, aktuelnost podataka Akt(N, L)Î{T, D, N} i stepen raspoloživosti Ras(N, L) Î{V, Z, N}. Znače­nje parametara Role(N, L), Sel(N, L), Akt(N, L) i Ras(N, L) je isto kao i kod matrice ER Tipovi/Tipovi lokacija, te se ovde ne navodi posebno.

 

Primjer 1.19. Posmatra se studija slučaja "Komercijalna funkcija". Matrica ER Tipovi/Tipovi lokacija je data na slikama 1.6 i 1.7, skup šema relacija implementacione šeme baze podataka je prikazan u primjeru 12.2, a specifikacija podšeme za transakcioni program "Provjera kupca i evidentiranje porudžbine" je data putem primjera 12.29, kao i slika 12.9, 12.11 i 12.12. Na osnovu navedenih elemenata, formirana je matrica Šeme rela­cija/Tipovi lokacija, koja je prikazana na slikama 1.12 i 1.13.

Tipovi lokacija	CENTRALA	PREDSTAVNIŠTVO	SKLADIŠTE
Šeme relacija	R	R	R
Skladište	IDS, NAS	IDS, NAS	IDS, NAS
Roba	IDR, NAR, JEM	IDR, NAR, JEM	IDR, NAR, JEM
Kupac	IDK, NAK, ADR, BON	IDK, NAK, ADR, BON	IDK, NAK, ADR
Zaliha	fDS, IDR, RAS	IDS, IDR, RAS, ŽAL	IDS, IDR, ŽAL
Zag_Nal	IDS, BRN, OSN, STN, IDK	IDS,   BRN,   OSN,   STN, IDK	IDS, BRN, OSN, STN, IDK
Stav_Nal	IDS, BRN, IDR, KOL, STA	IDS,   BRN,   IDR,   KOL, STA	IDS, BRN, IDR, KOL, STA
Zag_Otp		IDS, BRO, BRN	IDS, BRO, BRN
Stav_Otp		IDS, BRO, IDR	IDS, BRO, IDR

Slika 1.12.

 

Tipovi lokacija

CENTRALA

PREDSTA VNIŠTVO

SKLADIŠTE

Šeme relacija

Role

Sel

Akt

Ras

Role

Sel

Akt

Ras

Role

Sel

Akt

Ras

Skladište

R

S

D

Z

R

S

T

V

R

D

T

V

Roba

R

S

D

Z

R

S

T

V

R

S

T

V

Kupac

U

S

D

Z

U

S

T

V

R

S

T

V

Zaliha

U

s

D

Z

U

s

T

V

U

S

T

V

Zag_Nal

U

s

D

Z

U

D

T

V

R

D

T

V

Stav_Nal

U

s

D

Z

U

D

T

V

U

D

T

V

Zag_Otp

U

D

T

V

U

D

T

V

Stav_Otp

U

D

T

V

U

D

T

V

 

Slika 1.13.

 

Sljedeći korak, nakon formiranja matrice Šeme relacija/Tipovi lokacija, jeste verti­kalna fragmentacija skupa šema relacija šeme baze podataka (S, I). Vertikalnom fragmen­tacijom, formira se skup vertikalnih fragmenata SFn, takav da zadovoljava uslove komplet­nosti, konzervacije ograničenja i, trivijalno, disjunktnosti.

Kada se formira skup vertikalnih fragmenata, vrši se raspoređivanje vertikalnih fragmenata po tipovima lokacija. Vertikalna fragmentacija i raspoređivanje fragmenata se vrši na osnovu matrice Šeme relacija/Tipovi lokacija, informacija prikupljenih u toku sni­manja i analize korisničkih zahtjeva i ekspertske procene projektanta. Na taj način, dobija se matrica Vertikalni fragmenti/Tipovi lokacija. Svaka vrijednost ove matrice je reprezentovana parametrom Exist(F, L)e{x, ◊}, pri čemu vrijednost x ("postoji") označava da vertikalni fragment F egzistira na tipu lokacije L, dok vrijednost ◊ predstavlja "praznu" vrijednost u matri­ci (ne navodi se u prikazu) i označava da vertikalni fragment F ne egzistira na tipu lokacije L.

Vertikalni fragmenti iz skupa SFn se ne raspoređuju na konkretne lokacije, već se raspodjela vrši samo po tipovima lokacija. Formiranje skupa vertikalnih fragmenata SFn je samo "međukorak" da bi se došlo do konačnog skupa fragmenata SF. Saglasno tome, za skup SFn nije primjenljiv zahtjev da se jedan fragment raspoređuje na tačno jednu lokaciju. Prilikom formiranja matrice Vertikalni fragmenti/Tipovi lokacija, mora se poštovati sljedeće pravilo: vertikalni fragment se, u sljedećem koraku, transformiše u onoliko horizontalnih fragmenata, na koliko se konkretnih lokacija pojavljuje, odakle sledi da, ako se jedan verti­kalni fragment veže za više tipova lokacija, tada se podrazumjeva da će on biti transformisan u više horizontalnih fragmenata.

U principu, potrebno je poštovati i pravilo da se vertikalni fragment F(N) ne raspoređuje na tip lokacije L, na kojem nije predviđeno nikakvo ažuriranje podataka odgo­varajuće relacije, odnosno ako za polaznu šemu relacije N važi daje Role(N, L) = R.

 

Primjer 1.20. Posmatra se studija slučaja "Komercijalna funkcija". Matrica Šeme relacija/Tipovi lokacija, je prikazana na slikama 1.12 i 1.13, a skup šema relacija implementacione šeme baze podataka je prikazan u primjeru 12.2. Prema sadržaju matrice sa slike 1.12, zaključuje se da su jedini kandidati za vertikalnu fragmentaciju šeme relacija Kupac \ Zaliha, jer jedino za ove dvije šeme relacije postoje razlike u skupovima obilježja R(N, L), za različite tipove lokacija.

S obzirom na činjenicu da je većina obilježja šeme relacije Kupac u upotrebi na više lokacija različitog tipa, projektant se odlučuje da ne vrši njenu vertikalnu fragmentaci­ju. Kada je u pitanju šema relacije Zaliha, projektant takođe odlučuje da ne vrši vertikalnu fragmentaciju, na osnovu činjenice se na tipu lokacije PREDSTAVNIŠTVO koriste sva obilježja ove šeme relacije. Na osnovu ovako donijetih odluka, postupak vertikalne fragmentacije proizvodi trivijalan rezultat, po kojem je svaka šema relacije, istovremeno, i jedan vertikalni fragment.

Na slici 1.14 je prikazan sadržaj matrice Vertikalni fragmenti/Tipovi lokacija. Iz matrice se vidi da je predviđeno da se cjelokupan sadržaj relacija Skladište, Roba i Kupac nađe na lokacijama tipa CENTRALA, odnosno na jednoj jedinoj lokaciji ovog tipa u siste­mu. Kada su u pitanju relacije Roba i Kupac, takva odluka je donijeta zbog činjenice da se svi podaci iz ovih relacija ravnopravno mogu koristiti na više lokacija u sistemu, bez obzira što je Akt(Roba, CENTRALA) ¹ T i Ras(Roba, CENTRALA) ¹ V, kao i Akt(Kupac, CENTRALA) ¹ T i Ras(Kupac, CENTRALA) ¹ V. Pri tome je Role(Roba, CENTRALA) = R, samo zbog toga što studijom slučaja nije obuhvaćen transakcioni program za održavanje evidencije robe u sistemu. Inače bi bilo Role(Roba, CENTRALA) = U. Podaci za relaciju Skladište se kreiraju isključivo na lokaciji tipa CENTRALA, iako se koriste na više drugih lokacija. Zbog toga je i šema relacije Skladište smještena na pomenuti tip lokacije, mada je, samo zbog granica studije slučaja, Role(Skladište, CENTRALA) = R. Ostale šeme relacija su kandidati za formiranje horizontalnih fragmenata.

Za šemu relacije - vertikalni fragment Zaliha je predviđeno da bude alociran na lokacije tipa PREDSTAVNIŠTVO i SKLADIŠTE, što znači da će se, za svaku konkretnu lokaciju tipa PREDSTAVNIŠTVO i SKLADIŠTE, u sljedećem koraku, vršiti njegova hori­zontalna fragmentacija.

 

 

Tipovi lokacija   Vertikalni fragmenti	CENTRALA	PREDSTAVNIŠTVO	SKLADIŠTE
Skladište	X
Roba	X
Kupac	X
Zaliha		X	X
Zag_Nal	X	X
Stav_Nal	X	X
Zag_Otp		X	X
Stav_Otp		X	X

Slika 1.14.

 

 

Može se, takođe, primjetiti da iako su šeme relacija Zag_Nal i Stav_Nal potrebne i na tipu lokacije SKLADIŠTE, ovom raspodjelom nije predviđeno da se bilo koji dio relacije r(Zag_Nal) i r(Stav_Nal) nađe samo na lokaciji tipa SKLADIŠTE. Razlog za to je što se nalozi za otpremu ne formiraju na ovom tipu lokacije, već se tu samo preuzimaju i ažurira­ju, a pri tome važi i Role(Zag_Nal, SKLADIŠTE) = R.

 

Vertikalna fragmentacija šema relacija se, u praksi, ne vrši često. Ima smisla vršiti vertikalnu fragmentaciju u slučajevima kada postoji veći broj obilježja šeme relacije koji se gotovo isključivo koristi samo na jednom tipu lokacije. U tom slučaju, na primjer, fragmen­tacija se može izvršiti tako da jedan vertikalni fragment, pored primarnog ključa, sadrži samo obilježja bitna za posmatrani tip lokacije, a drugi fragment, osim primarnog ključa, sadrži sva ostala obilježja.

Treći korak projektovanja distribucione šeme baze podataka predstavlja horizon­talna fragmentacija vertikalno fragmentirane šeme baze podataka i formiranje matrice Fragmenti/Lokacije. Horizontalnom fragmentacijom, od skupa vertikalnih fragmenata, formira se konačni skup fragmenata SF, fragmentacione šeme baze podataka. Po definiciji fragmentacione šeme, moraju biti zadovoljeni uslovi kompletnosti, disjunktnosti i konzervacije ograničenja. Horizontalna fragmentacija skupa SF se vrši uporedo s formiranjem matrice Fragmenti/Lokacije. Ovi postupci se sprovode na osnovu matrice Vertikalni frag­menti/Tipovi lokacija, specifikacije konkretnih lokacija po tipovima lokacija, specifikacije integriteta torki skupa šema relacija S i informacija, prikupljenih tokom snimanja i analize korisničkih zahteva, koje su neophodne za zadavanje integriteta torke fragmenta, odnosno skupa uslova horizontalne fragmentacije.

Pri formiranju matrice Fragmenti/Lokacije, mora se poštovati pravilo da se svaki fragment smješta na tačno jednu lokaciju u sistemu. Lokacija na koju je fragment smješten se naziva matična lokacija fragmenta.

Matrica Fragmenti/Lokacije se može organizovati tako da se, kao vrste, pojave obilježja vertikalnog fragmenta, zajedno s nazivom vertikalnog fragmenta, a kao kolone oznake lokacija. U presjeku jedne vrste i jedne kolone, specificira se vrijednost parametra Distrib(Fn, A, KL)Î{ConF(A), ◊}, gde je Fn naziv vertikalnog fragmenta, a A oznaka obilježja fragmenta na lokaciji s oznakom KL. ConF(A) predstavlja uslov horizontalne fragmen­tacije, koji može biti definisan ili nedefinisan (ConF(A) = A). Simbol ◊ reprezentuje "praznu" vrijednost u matrici. Pri tome, ili se za sva obilježja vertikalnog fragmenta zadaje Distrib( Fn, A, KL) =◊, što znači da se fragment Fn ne distribuira na lokaciju KL, ili se za svako obilježje vertikalnog fragmenta zadaje uslov ConF(A).

 

Primjer 1.21. Posmatra se studija slučaja "Komercijalna funkcija". Matrica Verti­kalni fragmenti/Tipovi lokacija je prikazana na slici 1.14, a specifikacije integriteta torki za šeme relacija iz skupa S su date na slici 12.2. Pretpostavlja se da tip lokacije CENTRALA predstavlja samo jednu, istoimenu lokaciju Centrala, označenu kao CEN. Tip lokacije SKLADIŠTE predstavlja dvije lokacije: Centralno skladište 1, označeno kao CS1 i Centralno skladište 2, označeno kao CS2. Tip lokacije PREDSTAVNIŠTVO obuhvata dve lokacije Predstavništvo Novi Sad, označeno kao PNS i Predstavništvo Beograd, označeno kao PBG. Na svakoj lokaciji je predviđeno postojanje jednog servera baze podataka. Naziv lokalne baze podataka, na svakom od ovih servera, treba da bude BPIS.

Na slikama 1.15 i 1.16 je prikazan izgled matrice Fragmenti/Lokacije. Iz sadr­žaja matrice je uočljivo da se šeme relacija - trivijalni fragmenti Skladište, Roba i Kupac implementiraju, u cjelosti, u okviru lokalne baze podataka BPIS.CEN.C.X, koja pripada lo­kaciji Centrala.

 

Lokacije		CENTRALA	PREDSTAVNIŠTVO
Fragmenti		BPIS.CEN.C.X	BPIS.PNS.P.X	BPIS.PBG.P.X
Skladište	IDS	Δ
	NAS	Δ
Roba	IDR	Δ
	NAR	Δ
	JEM	Δ
Kupac	IDK	Δ
	NAK	Δ
	ADR	Δ
	BON	Δ
Zaliha	IDS		IDS = 21	IDS = 22
	IDR		Δ	Δ
	RAS		Δ	Δ
	ZAL		Δ	Δ
Zag_Nal	IDS	Δ	Δ	Δ
	BRN	100000 £ BRN Λ BRN < 120000	120000 £ BRN Λ BRN < 140000	140000 £ BRN Λ BRN < 180000
	OSN	Δ	Δ	Δ
	STN	Δ	Δ	Δ
	IDK	Δ	Δ	Δ
Stav_Nal	IDS	Δ	Δ	Δ
	BRN	1 00000 £ BRN Λ BRN < 120000	1 20000 £ BRN Λ BRN < 140000	140000 £ BRN Λ BRN< 180000
	IDR	Δ	Δ	Δ
	KOL	Δ	Δ	Δ
	STA	Δ	Δ	Δ
Zag_Otp	IDS		Δ	Δ
	BRO		240000 £ BRO Λ BRO < 260000	260000 £ BRO Λ BRO < 300000
	BRN		Δ	Δ
Stav_Otp	IDS		Δ	Δ
	BRO		240000 £ BRO Λ BRO < 260000	260000 £ BRO Λ BRO < 300000
	IDR		Δ	Δ

 

Slika 1.15.

Lokacije		SKLADIŠTE
Fragmenti		BPIS.CSI.C.X	BPIS.CS2.C.X
Skladište	IDS
	NAS
Roba	IDR
	NAR
	JEM
Kupac	IDK
	NAK
	ADR
	BON
Zaliha	IDS	IDS =10	IDS=11
	IDR	Δ	Δ
	RAS	Δ	Δ
	ZAL	Δ	Δ
Zag_Nal	IDS
	BRN
	OSN
	STN
	IDK
Stav_Nal	IDS
	BRN
	IDR
	KOL
	STA
Zag_Otp	IDS	Δ	Δ
	BRO	200000 £ BRO Λ BRO < 220000	220000 £ BRO Λ BRO < 240000
	BRN	Δ	Δ
Stav_Otp	IDS	Δ	Δ
	BRO	200000 £ BRO Λ BRO < 220000	220000 £ BRO Λ BRO < 240000
	IDR	Δ	Δ

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Slika 1.16.

 

 

Šema relacije Zaliha je particionirana na četiri horizontalna fragmenta, saglasno vrijednosti primarnog obilježja IDS. Svaki od tih fragmenata se implementira na posebnoj lokaciji, na kojoj se nalazi skladište, čija identifikaciona oznaka odgovara zadatoj vrijednosti obilježja IDS. Može se, na osnovu specifikacije integriteta torki za šeme relacija iz skupa S, zapaziti da je dozvoljeni opseg vrijednosti obilježja IDS zadat formulom 10 £ IDS Λ IDS £ 99. Saglasno izvršenoj horizontalnoj fragmentaciji šeme relacije Zaliha, zaključuje se da su sve druge vrijednosti obilježja IDS, osim vrednosti 10, 11, 21 i 22, trenutno neaktuelne i, samim tim, rezervisane za kasniju upotrebu. Šeme relacija Zag_Nal i Stav_Nal su particionirane, horizontalnom fragmentacijom, na identičan način, "zoniranjem" vrednosti pri­marnog obeležja BRN. Na analogan načinje izvršena horizontalna fragmentacija šema rela­cija Zag_Otp i Stav_Otp, "zoniranjem" vrednosti primarnog obeležja BRO.

 

Distribucionu šemu baze podataka čine fragmentaciona šema baze podataka (S, I, SF) i matrica Fragmenti/Lokacije.

Deo fragmentacione šeme baze podataka koji se implementira na jednom serveru baze podataka, odnosno na jednoj lokaciji, predstavlja lokalnu šemu baze podataka.

Opisani postupak projektovanja distribucione šeme baze podataka je imao za cilj da obezbjedi takvo particioniranje i distribuiranje implementacione šeme baze podataka po lokacijama, da se redundansa podataka u bazi, po osnovu distribucije, svede na minimum, a da, pri tome, svaka podšema ostane u potpunosti pokrivena konceptima šeme baze podata­ka, čime se obezbjeđuje da svaki transakcioni program uspješno može funkcionisati u distri­buiranom okruženju. Nasuprot tome, postupak izgradnje replikacione šeme baze podataka ima za cilj namjerno uvođenje kontrolisane redundanse podataka, u cilju poboljšanja per­formansi rada informacionog sistema. Postupku projektovanja replikacione šeme baze po­dataka je posvećen nastavak teksta.

 

Replikaciona šema baze podataka

 

Replikaciona šema baze podataka se formira nad distribucionom šemom baze po­dataka. Na osnovu fragmentacione šeme (S, I, SF), matrica Fragmenti/Lokacije i Šeme relacija/Tipovi lokacija i informacija, dobijenih u postupku snimanja i analize korisničkih zahtjeva, formira se skup replikacionih kopija SK i matrica Replikacione kopije/Lokacije.

Projektovanje skupa replikacionih kopija se bazira na analizi sadržaja matrica Šeme relacija/Tipovi lokacija i Fragmenti/Lokacije. Na osnovu prve matrice se dobija in­formacija na kojim sve lokacijama treba da se nađu torke iz jedne relacije. Druga matrica sadrži informacije o tome na koje lokacije su fragmenti šeme relacije alocirani. Analizom matrica, izvodi se zaključak koje lokacije predstavljaju potencijalne kandidate za replikaciju određenih fragmenata.

Skup replikacionih kopija SK i matrica Replikacione kopije/Lokacije se formiraju paralelno. Postupak projektovanja replikacije se odvija u dva koraka:

·       projektovanje skupa osnovnih replikacionih kopija i

·       projektovanje skupa složenih replikacionih kopija.

Da bi se donijela odluka o tome da li na jednoj lokaciji KL tipa L, treba, na osnovu šeme relacije N(R, C) i skupa fragmenata F(N), formirati osnovnu ili složenu replikacionu kopiju i kakve treba da budu njene karakteristike i struktura, potrebno je analizirati sadržaj matrice Šeme relacija/Tipovi lokacija. Pri tome se mogu primjeniti sljedeća pravila rezonovanja.

·       Skup R(N, L) predstavlja osnov za formiranje skupa obilježja replikacione kopije. Ukoli­ko je skup R(N, L) sadržan u skupu obilježja barem jednog fragmenta, i jedan od tih fragmenata, po uslovima horizontalne framgentacije, odgovara potrebama replikacije, tada se može pristupiti projektovanju osnovne replikacione kopije. U suprotnom, ukoliko se želi replikacija na lokaciji KL, mora se pristupiti projektovanju složene replikacione kopije.

·       Stepen raspoloživosti podataka Ras(N, L)Î{V, Z, N} predstavlja osnov za odluku da li praviti replikacionu kopiju. Ukoliko je Ras(N,L) = N, replikacionu kopiju, u principu, ne treba kreirati, već se podacima pristupa na matičnoj lokaciji fragmenta. U ostalim slu­čajevima, replikaciona kopija se, u principu, formira.

Projektovanje skupa osnovnih replikacionih kopija polazi od činjenice da svaka osnovna kopija nastaje od jednog fragmenta iz skupa SF. Pri tome, važe sljedeća pravila projektovanja osnovne replikacione kopije.

·       Za formiranje osnovne replikacione kopije na lokaciji tipa L, bira se fragment koji sadrži sva obilježja iz R(N, L) i, po uslovima horizontalne framgentacije, odgovara potrebama replikacije.

·       Na osnovu skupa obilježja fragmenta, formira se skup obilježja replikacione kopije, selektovanjem svih obilježja iz R(N, L).

·       Uloga Role(N, L)Î{R, U} određuje da li će replikaciona kopija biti statička (Role(N, L) = R) ili dinamička (Role(N, L) = U). Za dinamičke kopije se podrazumjeva primjena brzog načina osvježavanja, a ista odluka se, u principu, primjenjuje i za statičke osnovne replikacione kopije.

·       Aktuelnost podataka Akt(N, L)Î{T, D, N} određuje da li izabrati sinhronu ili asinhronu propagaciju ažuriranja. U principu, ako je Akt(N, L) = T, bira se sinhrona propagacija ažuriranja, a u ostalim slučajevima se bira asinhrona.

·       Selektivnost torki Sel(N, L)Î{S, D} pomaže pri formiranju WHERE uslova naredbe SELECT za replikacionu kopiju.

Projektovanje složenih replikacionih kopija se razlikuje u nekim detaljima, ukoliko složena kopija nastaje od jedne šeme relacije, ili nastaje od više šema relacija.

 

Za formiranje skupa složenih replikacionih kopija, od kojih svaka nastaje od jedne šeme relacije N(R, C), primjenjuju se sljedeća pravila.

·       Za formiranje složene replikacione kopije na lokaciji tipa L, bira se minimalan skup fragmenata iz skupa SF(N) koji sadrži sva obilježja iz R(N, L) i, po uslovima horizontal­ne framgentacije, odgovara potrebama replikacije.

·       Formira se SELECT naredba kopije, tako da sadrži odgovarajuće uslove spajanja verti­kalnih fragmenata, ili skupovne operatore UNION za objedinjavanje torki horizontalnih fragmenata. Moguće je da se, u slučaju referenciranja kombinovanih fragmenata, u SE­LECT naredbi pojave, istovremeno, i uslovi spajanja i skupovni operator UNION.

·       Podrazumjeva se da je složena replikaciona kopija statička, s asinhronim i kompletnim osvježavanjem.

·       Selektivnost torki Sel(N, L)Î{S, D} pomaže pri formiranju WHERE uslova naredbe SE­LECT za replikacionu kopiju.

Formiranje skupa složenih replikacionih kopija, od kojih svaka nastaje od više šema relacija, prati logiku oblikovanja pogleda nad šemom baze podataka. U tom smislu, od koristi može biti matrica Aplikacije/Tipovi lokacija, iz koje se vidi koje se aplikacije insta­liraju na lokaciji tipa L. Ukoliko neka od tih aplikacija koristi definicije pogleda, te defini­cije mogu predstavljati osnov i za kreiranje složenih replikacionih kopija. Da bi se donijela odluka o tome da li kreirati složenu kopiju, potrebno je analizirati da li su svi fragmenti, koji bi učestvovali u formiranju replikacione kopije, već obuhvaćeni nekim drugim replikacionim kopijama na lokaciji. Ukoliko je ovo ispunjeno, replikaciona kopija se ne kreira, već se definiše pogled, koji koristi postojeće replikacione kopije. U suprotnom, ponovo se analiziraju stepeni raspoloživosti Ras(N, L), za sve potrebne šeme relacija i odlučuje se o tome da li kreirati složenu replikacionu kopiju.

Specifikacija replikacione kopije može imati oblik imenovane, uređene četvorke:

 

Naziv_replikacione_kopije(SELECT, Type, Refresh, Propag, Method),

 

pri čemu SELECT predstavlja kompletnu SELECT naredbu replikacione kopije, TypeÎ{S, D} označava tip kopije i može biti statički (S), ili dinamički (D), RefreshÎ{F, C} predstavlja način osvježavanja i može biti kompletni (C) ili brzi (F), PropagÎ{A, S} označava da li je riječ o sinhronoj (S), ili asinhronoj (A) propagaciji ažuriranja, a Method označava strukturu metoda:

 

(M_Ent, M_Del, M_Upd)

 

 

koji se primjenjuju za razrješavanje kolizija ažuriranja. Pri tome, M_Ent označava skup metoda oblika M_Ent(K), KÎK, koje se koriste za razrješavanje kolizije integriteta entiteta, M_Del označava metodu za razrješavanje kolizije brisanja, a M_Upd označava skup me­toda oblika M_Upd(A), AÎR, za razrješavanje kolizije modifikacije obilježja. Ukoliko je Type = S, ili Propag  = S, tada je obavezno Method = (Æ, ◊, Æ), gdje simbol ◊ označava nedefinisanu metodu.

Matrica Replikacione kopije/ Lokacije se formira tako da se za svaku replikacionu kopiju RK i lokaciju KL, zadaje vrijednost parametra Install(RK, KL) Î{x, ◊}. Simbol x označava da se replikaciona kopija RK instalira na lokaciji KL, dok je ◊ simbol za prazno mjesto u matrici i znači da se replikaciona kopija RK ne instalira na lokaciji KL.

Replikacionu šemu baze podataka čine: struktura (S, I, SF, SK), matrica Frag­menti/Lokacije i matrica Replikacione kopije /Lokacije. Pri tome je (S, I, SF) fragmentaciona šema, a SK skup replikacionih kopija.

 

Primjer 1.22. Posmatra se studija slučaja "Komercijalna funkcija". Matrica Šeme relacija/Tipovi lokacija je prikazana na slikama 1.12 i 1.13, dok je na slikama 1.15 i 1.16 prikazana matrica Fragmenti/ Lokacije.

U nastavku primjera date su specifikacije isprojektovanih replikacionih kopija iz skupa SK.

• Skladiše_S(SELECT, S, F, A, (Æ, ◊, Æ)), gde je SELECT:

 

SELECT IDS, NAS

FROM Skladiste@BPIS.CEN.C.X.

 

• Roba_S(SELECT, S, F, A, (Æ, ◊, Æ)), gde je SELECT:

 

SELECT IDR, NAR, JEM

FROM Roba@BPIS.CEN.C.X.

 

• Kupac_P(SELECT, D, F, A,

({M_Ent(IDK) = "zabrani"}, ◊, {M_Upd(IDK)= "prepiši", M_Upd(NAK)= "prepiši", MJUpd(ADR) = "prepiši", M_Upd(BON} = "kumulirana vrijednost"})),

gde je SELECT:

 

SELECT IDK, NAK, ADR, BON

FROM Kupac@BPIS.CEN.C.X.

 

• Kupac_S(SELECT, S, F, A, (Æ, ◊, Æ)), gde je SELECT:

 

SELECT IDK, NAK, ADR

FROM Kupac@BPIS.CEN.C.X.

 

• Zaliha_C(SELECT, S, C, A, (Æ, ◊, Æ)), gde je SELECT:

 

SELECT IDS, IDR, RAS

FROM Zaliha@BPIS.CS1.C.X

UNION

SELECT IDS, IDR, RAS

FROM Zaliha@BPIS.CS2.C.X

UNION

SELECT IDS, IDR, RAS

FROM Zaliha@BPIS.PNS.P.X

UNION

SELECT IDS, IDR, RAS

FROM Zaliha@BPIS.PBG.P.X.

 

• Zag_Nal_S(SELECT, S, F, S, (Æ, ◊, Æ)), gde je SELECT:

 

SELECT IDS, BRN, OSN, STN, IDK

FROM Zag_Nal@BPIS.CEN.C.X.

 

• Stav_Nal_S(SELECT, D, F, S, (Æ, ◊, Æ)), gde je SELECT:

 

SELECT IDS, BRN, IDR, KOL, STA

FROM Stav_Nal@BPIS.CEN.C.X.

 

Na slici 1.17 je prikazana matrica Replikacione kopije/Lokacije.

 

 

Lokacije	CENTRALA	PREDSTAVNIŠTVO		SKLADIŠTE
Replikacione kopije	BPIS.CEN.C.X	BPIS.PNS.P.X	BPIS.PBG.P.X	BPIS.CS1.C.x	BPIS.CS2.C.X
Skladište_S		´	´	´	´
Roba_S		´	´	´	´
Kupac_P		´	´
Kupac_S				´	´
Zaliha_C	´
Zag_Nal_S				´	´
Stav_Nal_S				´	´

 

Slika 1.17.

 

 

Može se zapaziti da je predviđeno formiranje statičkih replikacionih kopija za šeme relacija Roba i Skladište na svim lokacijama u sistemu, osim na lokaciji CENTRALA, pošto je to matična lokacija za ove šeme relacija.

Na lokacijama tipa PREDSTAVNIŠTVO je predviđeno formiranje dinamičkih rep­likacionih kopija šeme relacije Kupac, jer je na ovom tipu lokacije dozvoljeno ažuriranje osnovnih podataka bilo kog kupca. Na lokacijama tipa SKLADIŠTE je predviđeno postoja­nje statičkih replikacionih kopija šeme relacije Kupac, pri čemu, saglasno sadržaju matrice Šeme relacija/Tipovi lokacija, obeležje BON nije obuhvaćeno replikacijom.

Zbog potrebe uvida u raspoloživo stanje zaliha bilo koje robe u bilo kom skladištu, na lokaciji tipa CENTRALA je formirana statička, složena replikaciona kopija Zaliha_C. Ova kopija ne može zadovoljiti potrebe ažuriranja obilježja RAS na tipu lokacije CENTRALA. Iako je stepen raspoloživosti podataka relacije Zaliha na tipu lokacije CENTRALA zna­čajan, nije formirana dinamička replikaciona kopija, koja bi dozvolila modifikaciju obilježja RAS. Razlog za to leži u činjenici, identifikovanoj u toku postupka snimanja i analize koris­ničkih zahtjeva. Naime, na tipu lokacije CENTRALA se vrši modifikacija vrijednosti obilježja RAS samo za zalihe za koje vrijednost obilježja IDS iznosi 10 ili 11. Riječ je o centralnim skladištima, koja nisu suviše udaljena od lokacije Centrala i koja su obuhvaćena lokalnom računarskom mrežom visokog stepena pouzdanosti i velike brzine. Zbog toga je donijeta od­luka da se modifikacija vrijednosti obilježja RAS s lokacije Centrala sprovodi direktno, putem distribuiranih transakcija koje obuhvataju server BPIS.CS1.C.X ili BPIS.CS2.C.X. Saglasno tome, dinamička replikaciona kopija na lokaciji Centrala nije potrebna.

Replikacione kopije Zag_Nal_S i Stav_Nal_S su formirane zbog potrebe preuzimanja naloga za otpremu, formiranih na tipu lokacije CENTRALA, na tip lokacije SKLADIŠTE. Predviđena je sinhrona propagacija ažuriranja, jer je izrazito važno ostvariti što bržu raspoloživost naloga za otpremu na tipu lokacije SKLADIŠTE, a s druge strane, postoje tehničke mogućnosti da se sinhrona propagacija uspješno sprovodi.

Može se primjetiti daje za sve replikacione kopije, za koje je Type  = S, postavljeno Method = (Æ, ◊, Æ).

Za dinamičku replikacionu kopiju Kupac_P, metoda za razrješavanje kolizije brisa­nja nije specificirana, odnosno postavljeno je M_Del = ◊, jer se pretpostavlja da je, organizacionom mjerom u realnom sistemu, obezbjeđeno da se brisanje torki iz evidencije kupaca smije obavljati samo po posebnom odobrenju, i to isključivo na lokaciji Centrala, tako da do kolizija brisanja ne može doći.

Za dinamičku replikacionu kopiju Stav_Nal_S, takođe, nije specificirana ni jedna metoda za razrešavanje kolizija, jer je Propag  = S, te do kolizija ažuriranja nikada ne može ni doći.

 

Cilj dijela teksta s podnaslovom "Replikaciona šema baze podataka" je bio da bliže objasni pojam replikacone šeme baze podataka i ilustruje jedan opšti postupak njenog projektovanja. Na kraju, potrebno je naglasiti da taj opšti postupak, u praksi, treba da bude usaglašen i s mogućnostima koje pruža izabrani SUBP, jer on, u ne maloj mjeri, zavisi od mogućnosti i koncepata replikacije koje konkretni SUBP podržava.

 

 

---

[1]Na engleskom: timeout mechanism.

* Pomenuti tipovi grešaka su opisani u [ML]

* Na engleskom: Commit Point Site.

* Na  engleskom: Replica.

* Na engleskom: Refresh.

* Na engleskom: Snapshot.

 

* Na engleskom: Row Level.

* Na engleskom: Batch.

 

* Na engleskom: Timestamp Column.

 

* Notacija za ER dijagrame, koju podržava Designer 2000, prikazana je u okviru glave 13.

* Na engleskom: Multimaster Replication.

* Na engleskom: Snapshot Replication.

 

* Simbol ω predstavlja oznaku za nula vrednost.

 

* Umjesto distribucione šeme transakcionih programa, može se formirati distribuciona šema elementarnih procesa (aktivnosti, elementarnih funkcija) iz dijagrama toka podataka, pri čemu se pretpostavlja da svaki elementarni proces reprezentuje transakcioni program.

* Vidjeti dijagrame tokova podataka, prikazane na slikama 11.2 i 11.3, kao i dijagram dekompozicije funkcija, prikazan na slici P6.1.

 

 

* Pojam integriteta torke je uveden u glavi 6.