tehnologije distribuiranih baza podataka distributed ... rad mirko hrnjaz.pdf · distributed...

Univerzitet u Novom Sadu

Tehnički fakultet ”Mihajlo Pupin”

Zrenjanin

Tehnologije distribuiranih baza podataka

Distributed Databases Technologies

-Master rad-

Mentor:

Doc. dr Ljubica Kazi

Student:

Mirko Hrnjaz, MIT 11/15

Informacione tehnologije

- master

Zrenjanin, 2017

1

Univerzitet u Novom Sadu

Tehnički fakultet ,,Mihajlo Pupin“ Zrenjanin

Ključna dokumentacijska informacija

Redni broj:

RBR

Identifikacioni broj:

IBR

Tip dokumentacije:

TD

Monografska dokumentacija

Tip zapisa:

TZ

Tekstualni štampani materijal

Vrsta rada (dipl.mag.dokt.):

VR

Master rad

Ime i prezime autora:

AU

Hrnjaz Mirko

Mentor (titula, ime, prezime, zvanje):

MN

Doc. dr Ljubica Kazi

Naslov rada:

NS

Tehnologije distriburanih baza podataka

Jezik publikacije:

JZ

Srpski

Jezik izvoda:

JI

Srpski/Engleski

Zemlja publikovanja:

ZP

Republika Srbija

Uže geografsko područje:

UGP

Zrenjanin, Vojvodina

Godina:

GO

2017.

Izdavač:

IZ

Autorski reprint

Mesto i adresa:

MS

Tehnički fakultet ''Mihajlo Pupin'', Đure

Đakovića bb

Zrenjanin

2

Fizički opis rada:

FO

Broj poglavlja 7/ strana 67/ slika 13/ listinga

18/

Naučna oblast:

OB

Informacione tehnologije -master

Naučna disciplina:

ND

Distribuirani informacioni sistemi

Predmetna odrednica, ključne reči:

PO

Distribuirane baze podataka,

particionisanje,replikacija,transakcije,oporavak

baze podataka

UDK

Čuva se:

ČU

Biblioteka Tehničkog fakulteta »Mihajlo

Pupin« Zrenjanin

Važna napomena:

VN

Izvod:

IZ

U ovom radu opisane su tehnike koje se

primenjuju u okviru procesiranja

distribuiranih baza podataka, kao i podrška

sistema za upravljanje bazama podataka za

distribuirane baze podataka. Opisane su

osnovne tehnike: replikacija podataka,

particionisanje podataka, distribuirane

transakcije i oporavak baze podataka u

najčešče korišćenim sistemima za

upravljanje bazama podataka. U radu je

prikazan primer Turističke agencije u

okviru kog su realizovane navedene

tehnike. Primer je realizovan korišćenjem

Microsoft SQL Server Management

Studio, PHP MyAdmin (za rad sa MYSQL

bazom podataka) i programsko razvojno

okruženje Microsoft Visual Studio. Datum prihvatanja teme od strane NN veća:

DP

Datum odbrane:

DO

Članovi komisije:

ČK

3

University of Novi Sad

Technical Faculty ,,Mihajlo Pupin“ Zrenjanin

Key word documentation

Accession number:

ANO

Identification number:

INO

Document type:

DT

Monograph documentation

Type of record:

TR

Textual printed material

Concents code:

CC

M.Sc.thesis

Author:

AU

Hrnjaz Mirko

Menthor:

MN

PhD Ljubica Kazi, assistant professor

Title:

TI

Distributed Databases Technologies

Language of text:

LT

Serbian

Language of abstract:

LA

eng./serb

Country of publication:

CP

Republic of Serbia

Locality od publication:

LP

Zrenjanin, Vojvodina

Publication year

PY

2017.

Publisher:

PU

The autor’s reprint

Publication place:

PP

Tehnical faculty '' Mihajlo Pupin'' Đure

Đakovića bb Zrenjanin

4

Physical description:

PD

chapters7/ pages 67/ pictures 13/ lists of code

18/

Scientific field:

SF

Computer Science – M.Sc.

Scientific discipline:

SD

Distributed information systems

Subject, Key words:

SKW

Distributed

database,partitioning,replication,transactions,

recovery databases

UDC

Holding data:

HD

Library of Technical Faculty »Mihajlo Pupin«

Zrenjanin

Note:

N

Abstract:

AB

In this paper techniques are described that

are implemented in the context of

processing distributed databases, as well

as the support system for managing

databases for distributed databases. The

basic techniques are described such as:

data replication, data partitioning,

distributed transactions and recovery

database in the most commonly used

systems for managing databases. The

paper presents example of tourist agency

where are realized the listed techniques.

The example is realized using Microsoft

SQL Server Management Studio, PHP

MyAdmin (to work with the MySQL

database) and software development

environment Microsoft Visual Studio. Accepted on Scientific Board on:

AS

Defended:

DE

Thesis Defend Board:

DB

5

Sadržaj

1. Metodološki okvir istraživanja ................................................................................. 8

1.1 Predmet i problem istraživanja........................................................................... 8

1.2 Vrsta istraživanja ................................................................................................ 8

1.3 Cilj i zadaci istraživanja ..................................................................................... 8

1.4 Hipoteza i podhipoteze ....................................................................................... 8

1.5 Očekivani rezultati ............................................................................................. 9

1.6 Metodološki postupak ........................................................................................ 9

2. Teorijsko istraživanje .............................................................................................. 10

2.1 Particionisanje podataka ................................................................................... 12

2.2 Replikacija baze podataka ................................................................................ 14

2.3 Distribuirane transakcije .................................................................................. 15

2.4 Oporavak baze podataka .................................................................................. 17

2.5 Upravljanje katalogom ..................................................................................... 18

2.6 Sinhronizacija podataka ................................................................................... 18

3. Stručno istraživanje ................................................................................................. 20

3.1 Elementi procesiranja distribuiranih baza podataka u najčešće korišćenim

DBMS ......................................................................................................................... 20

3.1.1 MySQL ..................................................................................................... 20

3.1.1.1 Replikacija podataka ......................................................................... 20

3.1.1.2 Particionisanje podataka .................................................................... 21

3.1.1.3 Distribuirane transakcije .................................................................... 21

3.1.1.4 Opravak baze podataka ...................................................................... 22

3.1.2 MSSQL ..................................................................................................... 22


3.1.2.2 Particionisanje podataka .................................................................... 23


3.1.2.4 Oporavak baze podataka .................................................................... 23

3.1.3 Oracle ........................................................................................................ 24


3.1.3.2 Particionisanje podatka ...................................................................... 25


3.1.3.4 Oporavak baze podataka .................................................................... 27

3.1.4 Sumarni pregled tehnika distribuiranih baza podataka u okviru najčešće

korišćenih sistema za upravljanje bazama podataka ............................................... 28

3.2 Posebni DBMS namenjeni za distribuirane baze podataka .............................. 28

3.2.1 Mariposa-distribuirani sistem baza podataka ........................................... 28

6

3.3 Platforma za sihronizaciju podataka ................................................................ 29

3.3.1 Microsoft Synchronization Services ......................................................... 29

4. Rezultati naučno-stručnih istraživanja .................................................................... 31

4.1 Spanner - Guglova distribuirana baza podataka ............................................... 31

4.2 Transakcioni menadzment u R* DSUPB ......................................................... 33

4.3 Multibaza-integrisani heterogeni distribuirani sistem baza podataka .............. 34

4.4 Distriuirani i paralelni sistemi baza podataka .................................................. 36

5. Implementirano rešenje ........................................................................................... 38

5.1 Opis poslovnog konteksta ................................................................................ 38

5.2 Cilj i opis korišćenih tehnologija ..................................................................... 38

5.2.1 MS SQL Server ......................................................................................... 38

5.2.2 PHP My Admin ........................................................................................ 39

5.2.3 Microsoft Visual Studio 2010 ................................................................... 39

5.2.4 PowerDesigner .......................................................................................... 40

5.3 Modeli .............................................................................................................. 40

5.3.1 Business process model ............................................................................ 41

5.3.2 Use case model ......................................................................................... 41

5.3.3 Dijagram komponenti ............................................................................... 42

5.3.4 Dijagram razmeštaja ................................................................................. 42

5.4 Korisničko uputstvo ......................................................................................... 42

5.5 Opis implementacije ......................................................................................... 44

5.5.1 Šema baze podataka i SQL script za kreiranje baze podataka .................. 44

5.5.2 Delovi programskog koda sa objašnjenjima ............................................. 47

5.5.2.1 Opis osnovnih elemanta realizacije web aplikacije uz primenu tehnika

distribuiranih baza podataka ............................................................................... 47

5.5.2.2 Opsti deo za sve primere ................................................................... 48

5.5.2.3 Implementacija replikacije podataka ................................................. 49

5.5.2.4 Implementacija horizontalnog particionisanja .................................. 50

5.5.2.5 Implementacija vertikalnog particionisanja ...................................... 51

5.5.2.6 Implementacija distribuirane transakcije ........................................... 53

5.5.2.7 Implementacija oporavka baze podataka ........................................... 54

5.5.2.8 Korišćenje web servisa za konsultovanje udaljene baze podataka .... 57

5.5.2.9 Upiti nad više baza podataka ............................................................. 59

6. Zaključak ................................................................................................................ 62

7. Literatura ................................................................................................................. 63

7

Apstrakt

U ovom radu opisane su tehnike koje se primenjuju u okviru procesiranja distribuiranih

baza podataka, kao i podrška sistema za upravljanje bazama podataka za distribuirane

baze podataka. Opisane su osnovne tehnike: replikacija podataka, particionisanje

podataka, distribuirane transakcije i oporavak baze podataka u najčešče korišćenim

sistemima za upravljanje bazama podataka. U radu je prikazan primer Turističke

agencije u okviru kog su realizovane navedene tehnike. Primer je realizovan

korišćenjem Microsoft SQL Server Management Studio, PHP MyAdmin (za rad sa

MYSQL bazom podataka) i programsko razvojno okruženje Microsoft Visual Studio.

Abstrakt

In this paper techniques are described that are implemented in the context of processing

distributed databases, as well as the support system for managing databases for

distributed database. The basic techniques are described such as: data replication, data

partitioning, distributed transactions and recovery database in the most commonly used

systems for managing databases. The paper presents example of tourist agency where

are realized the listed techniques. The example is realized using Microsoft SQL Server

Management Studio, PHP MyAdmin (to work with the MySQL database) and software

development environment Microsoft Visual Studio.

8

1. Metodološki okvir istraživanja

1.1 Predmet i problem istraživanja

Predmet istraživanja predstavljaju različite tehnologije koje se koriste u radu sa

distribuiranim bazama podataka. Problem istraživanja je utvrditi načine implementacije

pojedinih karakterističnih postupaka u radu sa distribuiranim bazama podataka.

1.2 Vrsta istraživanja

U ovom radu predmet istraživanja je izučen sa teorijskog i empirijskog aspekta. U

teorijskom aspektu biće opisane osnovne definicije pojedinih tehnika u radu sa

distribuiranim bazama podataka. U empirijskom delu biće opisana postojeća stručna

rešenja i dat primer kojim se ilustruje primena pojedinačnih tehnika.

1.3 Cilj i zadaci istraživanja

Cilj istraživanja je prikaz elemenata tehnoloških rešenja koja se odnose na distribuirane

baze podataka, prvenstveno replikacija, particionisanje, transakcije i oporavak baze

podataka. Konkretni procesi će biti ilustrovani praktično realizovanim primerom.

1.4 Hipoteza i podhipoteze

Osnovna hipoteza:

U najčešće korišćenim sistemima za upravljanje bazama podataka podržane su

osnovne tehnike za rad sa distribuiranim bazama podataka.

Podhipoteze:

U najčešće korišćenim sistemima za upravljanje bazama podataka podržana je

tehnika rada sa replikacijom podataka.


tehnika rada sa particionisanjem podataka.


tehnika rada za oporavak baze podataka.

9


tehnika rada sa distribuiranim transakcijama.

1.5 Očekivani rezultati

Teorijski prikaz osnovnih koncepata,

Stručno-istraživački rezultati prikaza profesionalnih rešenja u oblasti najčešće

korišćenih sistema za upravljanje bazama podataka i podrške tehnikama rada sa

distribuiranim bazama podataka,

Naučno-istraživački rezultati prikaza aktuelnih istraživanja u oblasti tehnika rada

sa distribuiranim bazama podataka,

Realizovan primer softverske aplikacije (web aplikacije) koja koristi raličite

tehnike rada sa distribuiranim bazama podataka uz prikaz tehnoloških elemenata

prvenstveno replikacija, particionisanje, transakcije i oporavak baze podataka.

1.6 Metodološki postupak

1. Naučno-metodološko koncipiranje istraživanja

2. Teorijska istraživanja

3. Praktična implementacija tehnoloških elemenata

4. Sumiranje i dokumentovanje rezultata

10

2. Teorijsko istraživanje

“Distribuirana baza podataka je kolekcija velikog broja, logički integrisanih baza,

distribuiranih preko određene heterogene računarske mreže. Sistem za upravljanje

distribuiranim bazama podataka je softver koji upravlja mehanizmom pristupa

distribuiranim bazama podataka i čini ga transparentnim za sve korisnike. To je više ili

manje spregnut multiprocesorski računarski sistem sa sinhronizovanom vremenskom

podelom zadataka.” [1]

“Distribuirani sistemi baza podataka imaju sledeće prednosti:

Veću pouzdanost: koja se ogleda u pravljenju kopija ili replika svih

komponenata baze. Greške se pri tome svode na minimum, jer prekinuta

komunikaciona veza ili elemenat obrade ne obara ceo sistem, podaci će se

preuzeti za nekog drugog mesta. Distribuirana obrada transakcija garantuje

doslednost baze podataka i konkurentnost.

Bolje perfomanse: zbog mogućnosti određivanja najkraćeg puta i najboljih

karakteristika mreže u datom trenutku, zbog takvog rasporeda podataka na

distribuiranim serverima baza, da se najčešće korišćeni fragmenti baze mogu

nalaziti u blizini klijenata koji ih potražuju. Na osnovu ovoga se smanjuju

kašnjenja odziva na upite baze sa nekog udaljenog mesta. Međutim, kako je već

napomenuto, to zahteva podršku za fragmentaciju i replikaciju. Veoma je

značajno, u zavisnosti od propusnosti mreže i vremena kašnjenja, pravilno

odabrati relacije i njihove fragmente koji će biti prenošeni sa jedne lokacije na

drugu u cilju obrade upita (globalna optimizacija).”[1]

“Jednostavni sistemski razvoj: omogućuju pojedinačni DBMS sistemi koji se

nalaze na svakoj lokaciji i mogu da rade nezavisno pri izvršavanju upita, jer

svaki nod lokalne baze podataka mora biti ravnopravan sa ostalim nodovima u

bazi i može se koristiti nezavisno od ostatka distribuiranog sistema. Ovo se

naziva lokalnom autonomijom svakog noda. Razvoj sistema prati globalni

katalog, kao sistemska baza podataka (ili njen deo), koji sadrži informacije o

raznim objektima u sistemu kao što su bazne tabele, pogledi, indeksi, baze

podataka, planovi izvršavanja upita, ovlašćenja za pristup objektima, itd. U

11

slučaju distribuiranog sistema, katalog sadrži informacije o načinu i lokacijama

na koje su podaci razdeljeni i (eventualno) ponovljeni. Obično se u realizaciji

koristi kombinovan (katalog je particionisan, ali na jednoj lokaciji postoji

centralna kopija kompletnog kataloga).” [1]

“DSUBP treba da zadovolji sledeće osnovne principe distribucije:

1. Lokalna autonomija svakog čvora - U svakom čvoru lokalna baza podataka

može da se koristi kao da nije deo distribuirane baze,

2. Nepostojanja centralnog čvora distribuirane baze podataka - Svi čvorovi u

distribuiranoj bazi podataka su ravnopravni. Postojanje centralnog čvora u

velikoj meri bi degradiralo pouzdanost i raspoloživost distribuirane baze

podataka. Otkaz centralnog čvora doveo bi do otkaza celokupnog sistema,

3. Transparentnost distribucije, odnosno sakrivanje detalja distribucije od

korisnika. Korisnik treba da jednostavno koristi distribuiranu BP na isti način na

koji koristi i centralizovanu, bez znanja o tome kako je distribucija podataka

fizički izvedena.”[2]

“Podaci u distribuiranom sistemu mogu biti particionisani (eng. partitioned) ili

ponovljeni (eng. replicated), a mogu biti istovremeno i particionisani i ponovljeni. U

slučaju particionisanje podataka, baza je razdeljena na više disjunktnih delova od kojih

je svaki na drugom čvoru komunikacione mreže. Skup podataka sa logičkog nivoa treba

na neki način podeliti, a zatim te delove – fragmente raspodeliti po raznim lokacijama.

Najčešće primenjivana tehnika za očuvanje informacija pri fragmentaciji podataka je

uvodjenje sistemskih identifikatora n-torki (nametnuti ključevi) kao primarnih ključeva,

koji se pamte uz svaki deo pojedine n-torke i omogućuju njenu rekonstrukciju.

U slučaju ponavljanja podataka, jedan logički objekat može imati više fizičkih

reprezentacija (veći broj kopija) na većem broju lokacija. Ukoliko je na svakom od

čvorova fizička reprezentacija čitave baze onda je to distribuirani sistem sa potpuno

ponovljenim podacima, a inače je distribuirani sistem sa delimično ponovljenim

podacima. Prilikom izbora načina organizacije podataka u distribuiranom sistemu, teži

se smanjenju troškova čuvanja podataka, obrade transakcija kao i komunikacije medju

čvorovima.”[7]

12

2.1 Particionisanje podataka

“Particionisanje se često primenjuje u cilju poboljšanja perfomansi, pristupačnosti,

pouzdanosti sistema. U distribuiranom sistemu podaci mogu biti ponovljeni (jedan

logički objekat može imati veći broj kopija na više različitih lokacija) ili particionisani

(logički skup podataka se deli na delove, a zatim se delovi smeštaju u odvojene lokacije,

sa proizvoljnim brojem ponovljenih kopija) u fizičkoj memoriji. Takva ponovljenost

podataka povećava njihovu raspoloživost i efikasnost pristupa podacima, ali u značajnoj

meri usložnjava ažuriranje podataka, koji moraju biti konzistentni u svim svojim

kopijama. Složenost koju sa sobom nosi strategija ponavljanja podataka, mora biti

sakrivena od korisnika. Kod particioniranja podataka, logički skup podatka u

relacionom sistemu je relacija, a prirodni fragment relacije (koji je opet relacija) jeste

neki njen podskup definisan uslovom projekcije i restrikcije. Fragmentacija mora biti

izvedena tako da se spajanjem fragmenata može dobiti polazna relacija.

Postoje dve vrste particionisanja:

Horizontalno,

Vertikalno. “[1]

“Horizontalno particionisanje je fragmentacija slogova i ona se najčešće koristi kod

jednostavnih upita. Iz tog razloga horizontalno particionisanje zovemo i intuitivnim.

Kod njega svaka lokacija bi trebalo da sadrži sve informacije koje se koriste prilikom

upita, dok bi informacije na lokaciji trebale biti fragmentisane kako bi odgovori na

upite bili brži. Horizontalno particionisanje je definisano kao selekcija operacija,

σp(R), što znači da su rezultati kompleksniji, odnosno da, kao za jednostavan upit po

svojoj prirodi ono nije u stanju da izvrši visoku selekciju potrebnih podataka, već

vraća veliku količinu podataka od kojih verovatno jedan deo nije od interesa za

korisnika. Prednost ovog načina selekcije je njegova brzina izvršenja a negativna

strana je cena izvršenja što se manifestuje velikim dotokom podataka na klijentsku

stranu.

Horizontalna fregmentacija može biti:

Primarna horizontana fregmentacija

o Kriterijum fragmentacije je predikat definisan upravo na

fregmentisanoj relaciji

Izvedena horizontalna fregmentacija

13

o Kriterijum fregmentacije je predikat definisan na drugim

relacijama.”[1]

“Vertikalna fragmentacija je usmerena na particionisanje relacije u mnoštvo manjih

relacija tako da više aplikacija može biti pokrenuto na samo jednom fragmentu odnosno

definiše se na neki način paralelizam izvršavanja.Vertikalna fragmentacija relacije R

proizvodi fragmente R1, R2,..., od kojih svaki sadrži podskup osobina relacije R.

Definisana je korišćenjem operacije projekcije relacione algebre : ΠA1,A2,...An (R)

Ono što se odmah vidi je da je vertikalna fragmentacija neizostavno komplikovanija od

horizontalne fragmentacije. Kao prilog ovoj tvrdnji stoji matematički model koji kaže

da je:

u horizontalnom particionisanju: za n prostih predikata, broj mogućih

minterma 2n (neki od njih mogu biti nezadovoljavajući za upit ali je broj

neznatno manji)

u vertikalnom particionisanju: za m ne – primarnih ključnih atributa, broj

mogućih fragmenata je B(m) tj. broj particija sa m stanja B(m) ~ mm.

Važno je reći da optimalno rešenje ne postoji, tako da se primenjuju heuristička rešenja.

Ovde razlikujemo dva tipa:

Grupisanje: gde se svakom fragmentu pridružuje po jedna osobina, i na

svakom koraku, pridružuju se neki fragmenti dok se ne zadovolje

postavljeni kriterijumi (prilaz bottom-up)

Deljenje: gde se počinje sa relacijom i onda se donose odluke za

povoljno particionisanje, zasnovane na ponašanju pristupne aplikacije

prema osobinama (prilaz top-down).”[1]

Slika 1. Prikaz horizonalog i vertikalog particionisanja [1]

14

2.2 Replikacija baze podataka

“Replikacija (engl. replication) je postupak kopiranja i distribuiranja podataka i objekata

iz jedne baze podataka u drugu koji sadrži mehanizam za sinhronizaciju podataka.”[6]

“Replikacija znači da na određenim lokacijama čuvamo više kopija relacija ili

relacionih fragmenata. Tada cela relacija može biti replicirana na više lokacija. Shodno

tome, jedan ili više fragmenata relacije može biti repliciran na više lokacija. Na primer,

ako je relacija P, fragmentisana na relacije P1, P2 i P3, može se predpostaviti da postoji

samo jedna kopija relacije P1, dok bi se P2 replicirala na dve lokacije a P3 replicirala na

svim lokacijama.“[1]

„Postoje dva razloga za primenu replike:

Povećana dostupnost podataka: Ako ”padne” lokacija koja sadrži replike,

možemo pristupiti istim sa drugih lokacija. Slično tome, ako su dostupne lokalne

kopije i sa udaljenih relacija, sistem je otporiniji na neuspeh komunikacione

veze.

Realizacija bržih upita: Upiti se mogu izvršiti brže koristeći lokalnu kopiju

relacije umesto da se upiti realizuju sa udaljenih lokacija.

Pravljenje replike baze podataka je veoma popularna tehnika distribucije podataka.

Znači, ona predstavlja kopiju master baze podataka koja se može ažurirati na različite

načine i treba biti locirana što bliže korisniku. Sinhronizacija master baze podataka sa

replikom se vrši slanjem inkrementalnog imidža sa replike (pri svakoj promeni baze ili

periodično). U ovom slučaju, primarna baza podataka se ne ažurira, već samo njena

kopija (replika). Kada se podaci ažuriraju čim je baza podataka modifikovana

korišćenjem 2PC protokola, govorimo o sinhronoj replici, a kada se podaci ažuriraju

posle nekog vremena radi se asinhronoj replici. Keširanje je dinamčka replika, jer se

privremeno (dinamički) stvara kopija baze podataka ili njenog dela. Primena ovakvog

sistema repliciranja podataka poboljšava performanse sistema naročito ako se jednom

referisani podaci ponovo koriste.”[1]

15

2.3 Distribuirane transakcije

“Transakcija je niz operacija nad bazom podataka koja odgovara jednoj logičkoj jedinici

posla.” [3]

“Svaka transakcija mora zadovoljiti osnovne principe i atribute:

Atomska. Transakcija se mora izvršiti ili u potpunosti, ili nimalo. Ne sme se

dozvoliti mogućnost izvršenja samo dela programa transakcije, jer bi to moglo

dovesti do nekonzistentnog stanja baze.

Konzistentna. Izvršenje transakcije nad bazom podataka koja je konzistentna,

mora prevesti bazu u takođe konzistentno stanje, odnosno očuvati

konzistentnost baze. Očuvanje konzistentnosti baze podrazumeva poštovanje

svih ograničenja integriteta.

Nezavisna. Kaže se da je skup transakcija nezavistan, ako je rezultat njihovog

konkurentnog izvršavanja isti kao da su se izvršavale jedna po jedna, bez

preklapanja izvršavanja. Saglasno tome, osobina nezavisnosti obezbeđuje

konkurentno izvršavanje transakcija.

Trajna. Pod trajnošću se podrazumeva osobina da kada se transakcija završi, sva

ažuriranja podataka su smeštena u memoriju, tipično na disk, koji može

sačuvati podatke i u slučaju kvara sistema. Posle oporavka sistema od kvara,

podaci nisu izgubljeni, a time i rezultati rada transakcije, nego se mogu naći na

odgovarajućem mestu na disku.”[3]

Prema [4], transakcija koji radi sa više izvora podataka se naziva distribuira transakcija.

Ako transakcija ne uspe onda su pogođene izvori podataka biti vraćeni u provobitno

stanje. U System.Transactions, MSDTC (Microsoft Distributed Transaction

Coordinator) upravlja distribuiranim transakcijama. Distribuirana transakcija je mnogo

sporija od lokalne transakcije. Objekat transakcija automatski eskalira lokalnu

transakciju u distribuiranu transakciju kada shvati da je potrebna distribuirana

transakcija.

Prema [4], u svakoj distribiranoj transakciji uključeno je nekoliko elemenata. Svaki deo

ima dve komponente:

Transaction Manager

Transaction Coordinator

16

Transaction Manager - Održava evidenciju i koristi tu evidenciju ako je potrebno

povraćaj podataka. Kontroliše celu transakciju pokretanjem i kompletiranje, upravljanje

trajnošću i automatizacijom transakcije. Takođe koordinira transakcije preko jednog ili

više resursa.

Prema [4], postoje dve vrste tranasction menadžera.

1. Local Transaction Manager – upravlja transakcija gde postoji samo jedan izvor

podataka

2. Global Transaction Manager – upravlja transakcijama gde postoji više izvora

podataka

Transaction Coordinator - Početak izvršenje transakcija koje potiču na licu mesta.

Distribuira subtransakcije na odgovarajućim lokacijama, tako da oni mogu da se izvrše

na tim mestima. Koordinira svaku transakciju na svakoj lokaciji. Kao rezultat toga,

transakcija se ili izvrši ili vrati podatke na prvobitno stanje.

Slika 2.Sistemska arhitektura distribuiranih transakcija[4]

Prema [5], upravljanje zaključavanjem je u distribuiranim bazama podataka, zbog

postojanja replikacija elemenata baze, znatno složenije od zaključavanja u

centralizovanim bazama. Upravljanje zaključavanjem u DSUBP se bazira na metodama

zasnovanim na istaknutoj kopiji elemenata baze podataka ili na metodama glasanja

(voting methods).

“U metodama istaknute kopije jedna od kopija elemenata baze podataka se proglasi za

istaknutu u sve transakcije se obraćaju samo toj kopiji za dobijanje bilo kog lokota.

Kada transakcija dobije lokot na istaknutu kopiju on odgovarajuće operacije može da

izvrši na bilo kojoj drugoj kopiji na drugim čvorovima distribuirane baze. Istaknute

kopije elemenata baze podataka se mogu organizovati na različite načine:

17

Tehnika primarnog čvora. Jedan čvor distribuirane baze podataka se proglasi

za kooridnatora zaključavanja i sve istaknute kopije se nalaze na njemu.

Prednost ovakvog postupka je potpuna analogija sa centralizovanim bazama

podataka i jednostavnost upravljanja zaključavanjem. Tehnika primarnog čvora

smanjuje pouzdanost i raspoloživost DSUBP-a. Otkaz primarnog čvora dovodi

do otkaza celokupnog sistema.

Tehnika primarne kopije. Da bi se distribuiralo opterećenje primarnog čvora,

mogu se distribuirati istaknute kopije. Otkaz jednog čvora prouzrokuje samo

poništenje onih transakcija koje pristupaju istaknutim kopijama na tom čvoru.

Izbor novog koordinatora. U bilo kojoj od prethodnih tehnika, kada čvor

koordinator otkaže, čvorovi distribuirane baze koji su još uvek aktivni biraju

novog koordinatora. Ako postoju “backup čvor” on postaje primarni čvor, a

medju ostalim se bira novi “backup čvor”. ”[5]

Prema [5], u metodama glasanja nema istaknutih kopija, sve su kopije ravnopravne.

Osnovni princip ovoga pristupa je da transakcija dobija globalni lokot na neki elemenat

baze podataka ako je dobila lokot na odredjenom broju kopija tog elementa.Metode

glasanja se mogu tretirati kao potpuno distribuirane metode upravljanja zaključavanjem.

Metode glasanja, po pravilu, zahtevaju veći broj prenosa poruka kroz mrežu nego

metode istaknutih kopija.

2.4 Oporavak baze podataka

“Distribuirani sistem upravljanja bazom podataka je podložan razlićitim otkazima:

otkaz lokalnog SUBP-a,

otkaz komunikacionih linija.

gubitak ili izobličenje poruke izmedju čvorova.”[5]

Prema [5], u svim ovim otkazima neophodno je očuvati integritet distribuirane baze

podataka odnosno obezbediti da sve transakcije zadrže ACID osobine.

“To se u distribuiranim bazama podataka postiže preko dvofaznog protokola

potvrdjivanja (two-phase commit protocol). Svaki lokalni SUBP ima svoj sopstveni

mehanizam za upravljanje transakcijama i svoj sopstveni log. Jedna distribuirana

transakcija koristi više lokalnih baza, odnosno obavlja se preko više lokalnih sistema za

upravljanje transakcijama. Da bi se obezbedila atomnost ovakvih transakcija

neophodino je obezbediti dvonivoski mehanizam oporavka baze podataka. Na prvom

18

nivou se nalaze mehanizmi oporavka lokalnih SUBP, a na drugom tzv. koordinator koji

koordinira mehanizme oporavka sa prvog nivoa. Definišu se dve faze u potvrdivanju

promena koje transakcija izvrši u različitim bazama:

Faza l. Kada svi SUBP na prvom nivou pošalju signal koordinatoru da je deo transakcija

kojim upravijaju završen, koordinator im odgovara porukom, “pripremi se”. SUBP

prvog nivoa tada upisuju neophodne podatke na svoj log i šalju koordinatoru signal OK.

Ako upis na log nije uspeo, šalje se poruka “NOTOK”. Ako koordinator ne dobije

odgovor SUBP-a prvog nivoa u predefinisanom intervalu vremena, podrazumeva se

poruka “nije u redu”.

Faza 2. Ako su svi SUBP prvog nivoa poslali poruke “OK”, vrši se potvrdjivanje

(COMMIT) svih delova transakcije. U protivnom, poništavaju se promene

(ROLLBACK) svih delova transakcije na svim lokalnim SUBP.

Cilj da DSUBP ne bude zasnovan na jednom, “centralnom” čvoru zahteva da se

funkcije koordinatora takodje distribuiraju. Najčešće se to vrši na taj način da čvor sa

koga je neka transakcija startovala ima ulogu koordinatora za tu transakcju. “[5]

2.5 Upravljanje katalogom

“Katalog je sistemska baza podataka koja sadrži podatke o baznim relacijama,

pogledima, indeksima, korisnicima itd, a u slučaju distribuiranog sistema, i o načinu i

lokacijama na koje su podaci razdeljeni i ponovljeni. Sam katalog u distribuiranom

sistemu može biti centralizovan (samo na jednoj lokaciji), potpuno ponovljen (na svim

lokacijama po jedna kopija kataloga), particionisan (na svakoj lokaciji je deo kataloga

koji se odnosi na objekte sa te lokacije) ili kombinovan (katalog je particionisan, ali na

jednoj lokaciji postoji i centralna kopija kompletnog kataloga). Svaki od navedenih

pristupa ima svojih mana (zavisnost od centralne lokacije, visoka cena prenošenja

ažuriranja kataloga ili skup pristup udaljenoj lokaciji) pa pri izboru načina organizacije

treba uzeti u obzir karakteristike samog sistema npr. vreme odziva, veličinu kataloga,

kapacitet lokacije, pouzdanost itd.”[7]

2.6 Sinhronizacija podataka

“Sinhronizacija može biti automatska i manuelna. Manuelna sinhronizacija se koristi za

kopiranje podataka unutar jedne baze, za kopiranje podataka izmedju nepovezanih baza

i za kopiranje podataka izmedju baza koje ne predstavljaju "pravu" distribuiranu bazu.

Može se govoriti i o sinhronizaciji temeljenoj na podacima iz dnevnika (engl. log-based

19

replication) i sinhronizaciji temeljenoj na transakcijama (engl. transactional replication).

Dnevnik je datoteka u kojoj se čuvaju radnje ažuriranja (i/ili rezultati tih radnji) koje su

radjene nad podacima u bazi podataka. Ti podaci uglavnom služe bazi da uspostavi

konzistentno stanje podataka nakon privremenog (npr. zbog nestanka struje) pada baze

ili spašavanja podataka nakon oštećenja diska sa podacima baze. Osim svoje primarne

uloge, ova datoteka se često koristi i za druge svrhe, pa i za sinhronizaciju podataka u

distribuiranom sistemu. Jedan od pionira u korišćenju dnevnika za sinhronizaciju

podataka je baza Sybase. Prednost sinhronizacije temeljene na dnevniku je njena

jednostavnost i mogućnost ponavljanja i sinhronizacije daleko veće količine podataka.

Sinhronizacija podataka se još može podeliti na sinhronu i asinhronu. Kod sinhrone,

proces ažuriranja kopija izvodi se u istoj transakciji kao i proces ažuriranja primarne

baze. Prednost je automatska sinhronizacija podataka u svim bazama (sinhronizacija je

ili svuda ili nigde uspela, što je osigurano mehanizmom dvofaznog protokola

potvrdjivanja), dok kod asinhrone može doći do konflikta izmedju vrednosti podataka

na različitim bazama i te konflikte mora rešavati programer (kod programiranja

aplikacije) ili administrator baze (DBA).Nažalost, sinhrona sinhronizacija ima i veliku

manu – sve baze moraju biti raspoložive da bi uspela.”[7]

Prema[7], može se govoriti o podeli na sekvencijalnu i proceduralnu sinhronizaciju.

Kod sekvencijalne sinhronizacije promene nad kopijom podataka rade se red po red,

iako su se na izvornoj bazi možda izvodile samo jednom naredbom. Za razliku od toga,

proceduralna sinhronizacija poziva udaljenu proceduru koja može na udaljenoj bazi

kroz jednu naredbu ažurirati više redova.

“Treba još pomenuti jednosmernu i dvosmernu sinhronizaciju. Jednosmerna je ona kod

koje samo jedna baza može ažurirati odredjenu tabelu i slati kopije podataka drugoj

bazi, a kod dvosmerne dve ili više baza mogu ažurirati istu lokalnu tabelu, pa

sinhronizacija treba da ide u dva smera.”[7]

20

3. Stručno istraživanje

3.1 Elementi procesiranja distribuiranih baza podataka u najčešće

korišćenim DBMS

Prema [8], medju najčešće korišćene baze podataka i DBMS spadaju: MySQL,

MSSQL, Oracle.

3.1.1 MySQL

3.1.1.1 Replikacija podataka

“Replikacija omogućava da se podaci iz jedne MySQL baze podataka (master)

kopiraju na jednu ili više MySQL baza podataka (slave). U zavisnosti od konfiguracije,

mogu se replicirati sve baze podataka, odabrane baze podataka, ili čak i izabrane tabele

unutar baze podataka.”[9]

Prema [9], prednosti replikacije u MySQL uključuju:

Scale-out rešenja - širenje opterećenja između više slave-ova da bi se poboljšale

performansie. U takvom okruženju, unošenja i ažuriranja se moraju obavljati na

glavnom serveru (master). Čitanje se može obavljati na jednoj ili više baza

podataka (slave).

Sigurnost podataka – podaci se replicaju na slave, a slave može pauzirati proces

replikacije. Moguće je radit backup podataka na slave bez uticaja na

odgovarajuće matične podatke.

Distribuciju podataka na daljinu – replikacijom se moze stvoriti lokalna kopija

podataka za udaljene lokacije, bez stalnog pristupa master-u.

Prema [9], MySQL 8.0 podržava različite metode replikacije. Tradicionalna metoda se

zasniva na tome da replicira događaje iz binarnog loga master. Zahteva datoteke

evidencije i pozicije i u njima će biti sinhronizovana između master i slave. Novija

metoda bazirana na globalnoj transakciji identifikatora (GTIDs) je transakcijska i stoga

ne zahteva rad sa log datoteke ili pozicijama unutar ove datoteke, što znatno

pojednostavljuje replikaciju. Replikacija koristeći GTIDs garantuje konzistentnost

između master i slave sve dok su sve transakcije uradjene na master primjenje i na

slave.

21

3.1.1.2 Particionisanje podataka

Prema [10], horizontalno particionisanje je podela različitih redova tabele može na

različite fizičke particije. MySQL 8.0 ne podržava vertikalno particionisanje, u kojem

različite kolone tabele se dodjeljuju na različite fizičke particije. Trenutno nema planova

za uvođenje vertikalnog particionisanja u MySQL.Za particionisane tabele mora se

koristiti jednu mašinu za skladištenje. U MySQL 8.0, sve particije iste particionisane

tabele moraju da koriste isti mašinu za skladištenje. Međutim, za različite particionisane

tabele se mogu koristiti različite mašine na istom MySQL serveru.

“Neke prednosti particonisanja su:

Particionisanje omogućuje skladištenje više podataka u jednoj tabeli nego što se

može održati na jednom disku.

Podaci koji nisu potrebni se mogu lako ukloniti iz particionisane tabele,

smeštanjem na particiju koja sadrži samo te podatke. Nasuprot tome, proces

dodavanja novih podataka može u nekim slučajevima biti znatno olakšan

dodavanjem jedne ili više novih particija za skladištenje posebno tih podataka.

Neki upiti mogu biti znatno optimizovani i samom činjenicom da podaci koji

zadovoljavaju dati WHERE uslov mogu biti skladišteni samo na jednoj ili više

particija, koji automatski isključuje sve preostale particije iz pretrage.”[10]

3.1.1.3 Distribuirane transakcije

Kao što smo naveli da sve transakcije moraju obezbediti četiri osnovna svojstva, tako i

u MySQL transakcije su nedeljive, uskladjene, izolovane i trajne.

“START TRANSACTION i BEGIN naredba označavaju početak nove

transakcije.

COMMIT potvrđuje tekuću transakciju, čineći promene nastale tom transakcijom

stalnim.

ROLLBACK poništava tekuću transakciju, otkazujući sve promene koje su u

okviru nje izvršene.

Naredba SET AUTOCOMMIT uključuje ili isključuje autocommit mod za aktivnu

konekciju”[25]

Prema[25], predefinisano je da MySQL radi sa uključenim autocommit modom. To

znači da čim izvršite SQL naredbu koja ažurira neku tabelu, MySQL promenu zapisuje

22

u bazi. Ako se korist transaction-safe storage engine (kao što su InnoDB, BDB ili NDB

Cluster), može se isključiti autocommit mod na sledeći način:

SET AUTOCOMMIT=0;

3.1.1.4 Opravak baze podataka

Prema [11], oporavak se može opisati kao proces kroz koji novi učesnik dobija podatke

koji mu nedostaju od servera na mreži. Tokom oporavka server prati dogadjaje učesnka,

kao i transakcije koje se dešavaju dok oporavak traje.Oporavak se odvija u dve faze.

U prvoj fazi učesnik bira jedan od servera na mreži da mu bude donator za podatke koji

mu nedostaju. Donator je odgovoran za sve podatke koje nedostaju učesniku do ulaska

u grupu. Ovo se postiže preko standardnog asihrlonog kanala za replikaciju,

uspostavljenog izmedju donatora i učesnika. U drugoj fazi, učesnik prelazi na izvršenje

transakcija. Kad izvrši sve transakcije postaje član grupe.

3.1.2 MSSQL


Prema [12], replikacija je skup tehnologija za kopiranje i distribuciju podataka i

objekata baze podataka iz jedne baze u drugu, kao i za sinhronizuju između baza

podataka za održavanje konzistentnosti.SQL nudi tri vrste replikacije za korištenje u

distribuiranim aplikacijama:

Transakciona replikacija,

Merge replikacija,

Snapshot replikacija.

“Transakciona replikacija se obično koristi u server-to-server scenariju, koji zahtevaju

veliku propusnu moć, uključujući: poboljšanje prilagodljivosti i rasprostranjenosti,

skladištenje podataka i izveštavanje, integrisanje podataka iz više lokacija, integrisanje

heterogenih podataka.

Merge replikacija je prvenstveno namenjena za mobilne aplikacije ili distribuirane

server aplikacije koje imaju moguće sukobe podataka. Uobičajeni scenariji uključuju:

razmene podataka sa mobilnim korisnicima i integracija podataka iz više lokacija.

Snapshot replikacija se koristi da obezbedi početne podatke za transakcion i marge

replikaciju.” [12]

23

Prema [12], sa ove tri vrste replikacija SQL Server pruža snažan i fleksibilan sistem za

sinhronizaciju podataka.Kao alternativa replikacije, baze podataka se može

sinhronizovati pomoću Microsoft Sync Framework. Okvir za sinhronizaciju sadrži

komponente i intuitivan i fleksibilan API za lakšu sinhronizaciju između SQL Server,

SQL Server Express, SQL Server Compact, i SQL Azure baze podataka. Okvir Sync

uključuje klase koje se mogu adaptirati za sinhronizaciju između SQL Server bazom

podataka i bilo koje druge baze koja je kompatibilana sa ADO.NET.

3.1.2.2 Particionisanje podataka

Prema [13], SQL Server podržava i horizontalno i vertikalno particionisanje. To

podrazumeva delenje tabela u manje tabele, koje imaju manji broj redova a iste kolone,

odnosno, manji broj kolona a isti broj redova. Oba načina particionisanja omogučavaju

upitu skeniranje manje količine podataka. To dovodi do poboljšavanja performansi

upita.


“SQL Server ima alat DTC (Distributed Transaction Coordinator) koji održava

integritet distribuiranih transakcija u SQL okruženju. Distribuirana transakcija se deli

na dve faze:

Pripremna faza zahteva da se svi servisi koji učestvuju u transakciji navedu zajedno sa

svim zadacima koji su mu dodeljeni. DTC svakoj instanci dodeljuje poslove. Instanca

izvršava posao transakcije, bez potvrde.

Faza potvrđivanja. DTC očekuje od servisa obaveštenje za mogućnost potvrde o

izvršavanju transakcije. Servisi šalju odgovor u vremenskom roku i mogućnost

potvđivanja izvršenog posla. U suprotnom, šalje se Abort poruka „transakcija se ne

izvršava“.”[14]

3.1.2.4 Oporavak baze podataka

“SQL Server-u postoje tri modela oporavljanja baze podataka:

Full – sve se beleži. Pod ovim modelom ne bi trebalo da ima nikakavih gubitaka

podataka u slučaju otkaza sistema, pod pretpostavkom da su rezervne kopije

podataka dostupne i da korisnik ima sve dnevnike transakcija od tog rezervog

kopiranja. Ukoliko nema dnevnik ili ima neki koji je oštećen, onda će moći da

24

oporavi sve podatke do poslednjeg netaknutog dnevnika koji ima na

raspolaganju.

Bulk-Logged – je lakša verzija potpunog oporavka. Obične transakcije beleže se

u dnevnik isto kao kod metode potpunog oporavka, ali ne i masovne operacije.

Rezultat je taj da će u slučaju otkaza sistema oporavljene rezervne kopije

sadržati sve promene nad stranicama podataka koje nisu imale udela i masovne

operacije moraju se ponovo obaviti. Dobra vest kod ove metode je da se

masovne operacije ponašaju mnogo bolje. Uz ovakvu performansu dolazi i

pridruženi rizik, pa vam kilometraža može biti različita.

Simple-pod - ovim modelom dnevnik transakcija u suštini postoji samo kao

podrška transakcijama dok se one dešavaju. Dnevnik transakcija se redovno

skraćuje, pri čemu se sve završene ili opozvane transakcije u suštini uklanjaju iz

dnevnika (ne baš tako jednostavno, ali to je krajnji ishod). Ovo nam daje uredan

i lep dnevnik koji je manji i često se ponaša malo bolje, ali dnevnik koji nije ni

od kakve koristi za oporavak od otkaza sistema.”[26]

3.1.3 Oracle


Prema[15], replikacija je proces kreiranja kopija podataka i sihronizacija podataka u

bazama koje čine distribuiranu bazu podataka. Sve promene koje se naprave na jednoj

bazi moraju se odraziti i na kopije podataka u ostalim bazama. Replikacija omogućava:

veću raspoloživost sistema,

bolje performanse,

nastavak rada i kad lokalna baza izgubi vezu sa ostalim bazama,

smanjenje protoka podataka kroz mrežu.

“Oracle, osim replikacije, ima i neke druge mehanizme koji omogućavaju neke od

navedenih osobina. Npr. Oracle Data Guard (postoji u Oracle 9i i 10g, a sličan

mehanizam u prethodnim verzijama zove se Standby Database) omogućava da se na

temelju log datoteka primarne baze ažurira sekundardna baza, koja je kopija primarne

baze. Ako primarna baza doživi pad, na njeno mesto uskače sekundarna baza. U

verzijama 9i i 10g moguće je tu sekundarnu bazu podataka iskoristiti za čitanje, tako da

se npr. svi ili neki korisnički upiti preusmere na tu bazu, i time odtereti primarna baza.

25

Dakle, kao i replikacija, i Data Guard može povećati raspoloživost sistema, a ponekad i

povećati performanse. “[15]

“Oracle replikacija tzv. “stara” pojavila se prvi put u bazi 7. Osnovne varijante

replikacije iz baze 7 postoje i u bazi 10g. Tokom vremena povećavale su se mogućnosti

i performanse, olakšalo se administrovanje, povećao se broj mogućnosti. Oracle

replikacija temelji se na transakcijama a ne na log podacima.”[15]

Prema [15], Oracle Streams replikacija temelji se na log podacima. Log datoteke u

Oracle bazi dele se na on-line i archived log datoteke. Uvek moraju postojati barem dve

(Oracle preporučuje barem tri) on-line log datoteke u koje Oracle baza zapisuje

promene "u krug". Ako je Oracle baza postavljena u tzv. ARCHIVELOG način rada,

onda se podaci iz on-line datoteka ne gube, jer se on-line datoteke prenose u arhivu.

Oracle Streams replikacija je isključivo asinkrona, dvosmerna replikacija, a može

replicirati i DML i DDL naredbe.

“Oracle polaže velike nade u Oracle Streams i namenio ga je za više stvari, a ne samo za

replikaciju. Oracle Streams namenjen je i za punjenje skladišta podataka (Data

Warehousing) i za upravljanje redovima poruka (Message Queuing). Oracle Streams se

pojavio u bazi 9.2, ali je u bazi 10g značajno poboljšan.”[7]

3.1.3.2 Particionisanje podatka

“Oracle particionisanje nudi tri osnovne metode distribucije podataka kao osnovne

strategijae koje kontrolišu kako se podaci smešteju u zasebne particije:

Range,

Hash,

List.

Range-podela podataka na particije zasnovan na vrednošću particionog ključa koji se

uspostavlja za svaku particiju.

Hash particionisanje zasnovano je na hash algoritmu koji koristi Oracle za

particionisanje. Hash algoritam distribuira vrste prema particijama tako da particije

budu iste veličine. Hash particionisanje je idealna metoda za distribuciju podataka

izmedju uredjaja. Hash particionisanje je takodje alternativni, način za particionisanje

posebno kada podaci za particionisanje nisu istorijski ili nemaju jedinstveni particioni

ključ.

List particionisanje omogućuje, eksplicitnu kontrolu kako vrste u mapi će biti

particionisane prema listi diskretnih vrednosti particionog ključa za svaku particiju. List

26

takodje daje prednost što može da se grupiše i organizuje liste podataka koji nisu

organizovani i nisu sredjeni u normalan redosled. ” [30]


“Distribuirana transakcija koristi tzv. dvofazni commit protokol, koji ima faze Prepare i

Commit. U Oracle realizaciji on se zapravo, sastoji od tri faze – treća faza je Forget.

Ovako možemo ukratko prikazati postupak kod usješne distribuirane transakcije, koja

završava sa COMMIT i kod koje nije bilo nikakvih problema:

1. Klijentska aplikacija šalje DML naredbe (ili/i pozive udaljenih procedura) po

distribuiranoj bazi i na kraju završava sa COMMIT.

2. Ovde počinje prva faza. Globalni koordinator (baza na koju je direktno vezana

klijentska aplikacija) odredjuje koja će baza biti tzv. commit point site (u tome

pomažu i ostale baze, lokalni koordinatori).

3. Globalni koordinator svim bazama, osim commit point site bazi, šalje naredbu

da se pripreme.

4. Sve baze javljaju potvrdan odgovor (Prepared).

5. Ovde počinje druga faza. Globalni koordinator javlja commit point site bazi da

izvrši lokalni COMMIT.

6. Commit point site baza izvršava lokalni COMMIT i obaveštava globalnog

koordinatora.

7. Globalni i lokalni koordinatori javljaju svim ostalim bazama da naprave lokalni

COMMIT.

8. Sve baze rade lokalni COMMIT i obaveštavaju koordinatore.

9. Ovde počinje treća faza. Globalni koordinator obavještava commit point site

bazu da zaboravi distribuiranu transakciju.

10. Commit point site baza briše svoje podatke o distribuiranoj transakciji i

obavještava globalnog koordinatora.

11. Globalni koordinator briše svoje podatke o distribuiranoj transakciji.”[16]

Prema [16], kod ovog commit protokola postoji period u kojem je transakcija osetljiva

na pad (nekog) servera baze ili veze izmedju baza. Greške koje se mogu desiti jesu:

pao je sistem na računaru na kojem radi Oracle baza,

prekinula se veza izmedju dvije ili više baza koje učestvuju u distribuiranoj

transakciji,

desio se neki softverski problem.

27

3.1.3.4 Oporavak baze podataka

“Postoje različiti tipovi grešaka i problema koji se mogu javiti u radu s bazom podataka.

Oporavak od nekih grešaka je automatski, dok druge zahtevaju intervenciju

administratora. Ako SQL naredba uzrokuje grešku, baza automatski poništava efekte

naredbe korištenjem undo podataka i transformacijskih vektora. Greška se može

dogoditi i na nivo korisničkog procesa koji je pokrenuo transakciju. Najčešći je uzrok

prekid veze izmedju klijenta i servera. Ovakve slučajeve rešava pozadinski proces

PMON na način da poništava efekte transakcije i gasi serverski proces te oslobadja

zauzetu memoriju. Tipičan problem koji svakako zahteva angažman administratora je

oštećenje diskova koji čuvaju podatke. Kontrolna datoteka i redo log datoteke moraju u

svakom trenutku biti zaštićene multipleksiranjem. Ako se dotične datoteke

multipleksiraju na različite diskove, uvek je moguće upotrebiti kopije s ispravnih

diskova. Budući da postoji mala verovatnoća da se pokvare svi diskovi na kojima se

nalaze multipleksirane kopije, dodatna je mera sigurnosti arhiviranje kontrolne i redo

log datoteka. Podatkovne datoteke se ne mogu multipleksirati, stoga je jedina opcija

kreiranje sigurnosnih arhivskih kopija. Kako bi se podaci doveli u konzistentno stanje,

na arhivske je kopije potrebno primeniti transformacijske vektore iz arhiviranih i

aktualnih redo log datoteka. Koriste se oni transformacijski vektori u kojima su zapisane

promene koje su se dogodile u periodu izmeñu trenutka kreiranja arhivske kopije

podatkovne datoteke i kvara na mediju.”[27]

“Oracle baza je inicijalno u NOARCHIVELOG načinu rada. To znači da se

transformacijski vektori ne arhiviraju i podaci su nezaštićeni u slučaju kvara medija.

Iskusan će administrator zbog toga odmah nakon instalacije bazu prebaciti u

ARCHIVELOG način rada. To rezultira pokretanjem pozadinskog procesa koji brine o

arhiviranju redo log datoteka nakon svake izmene aktivne redo log grupe. Lokacija za

arhiviranje se eksplicitno odredjuje. Dodatna je zaštita multipleksiranje arhiviranih redo

log datoteke na različite diskove. Trajanje oporavka zavisi o frekfenciji arhiviranja

podatkovnih datoteka. Što je arhiva svežija, potrebno je primijeniti manji broj

transformacijskih vektora na podatke pa je oporavak kraći. Medjutim, arhiviranje

podataka usporava bazu. Stoga administrator mora odabrati optimalno rešenje čijom

primjenom baza neće biti preopterećena arhiviranjem dok će potencijalni oporavak od

kvara medija biti izvršen u razumnom vremenu.”[27]

28

3.1.4 Sumarni pregled tehnika distribuiranih baza podataka u okviru

najčešće korišćenih sistema za upravljanje bazama podataka

U ovom odeljku su prikazane osnovne tehnike rada sa distribuiranim bazama podataka

uporedno za tri najčešće korišćena sistema za upravljanje bazama podataka. Opis načina

rada sa pojedinačnim tehnikama u odgovarajućem DBMS sistemu dat je u prethodnim

odeljcima, a ovde je dat sumarni pregled referenci u kojima se te tehnike spominju,

čime se potvrđuju podhipoteze i glavna hipoteza.

SUBP Replikacija Particionisanje Transakcije Oporavak

Oracle [15] [30] [16] [27]

MSSQL [12] [13] [14] [26]

MySQL [9] [10] [25] [11]

Tabela 1. Uporedni prikaz tehnika distribuiranih baza podataka

za 3 najčešće korišćena SUBP

3.2 Posebni DBMS namenjeni za distribuirane baze podataka

3.2.1 Mariposa-distribuirani sistem baza podataka

„Mariposa je sistem za upravljanje distribuiranim bazama podataka koji je nastao kao

istraživački projekat na Univerzitetu Kalifornije u Berkliju. Mariposa objedinjuje

pristup koji se uzima pri radu sa distribuiranim fajl sistemima i distribuiranim bazama.

Kao takav, omogućuje sveobuhvatnu fleksibilnu platformu za izradu novih algoritama

za optimizaciju distribuiranih upita, upravljanje memorijom i skalabilne strukture za

čuvanje podataka. Fleksibilnost se primarno koristi za korišćenje veće autonomije koja

dozvoljava izvršenje lokalnih naredbi nezavisno od mesta gde se podatak nalazio u

memoriji, mesta izvršenja upita i upravljanja memorijom.“[17]

Postoje četiri pristupa koji se odnose na upravljanje distribuiranim podacima

koji su se istraživali:

distribuirani bazni sistemi

klijent-server distribuirani fajl sistemi

"deep store" fajl sistemi

objektno-orijentisani bazni sistemi

Prema[18], fundametnalni zadaci Maripose su ujedinjenje različitih pristupa

distribuiranju baza podataka, keširanja distribuiranih fajl sistema, "duboko skladištenje"

fajl sistema i servera za objekte. Mariposa distribuira podatke preko puteva koji su

povezani nekom lokalnom ili širokopojasnom mrežom (LAN/WAN). Svaka lokacija

29

ima uređaj za skladištenje, koju smatramo glavnom memorijom u ovom slučaju, disk ili

tercijalna memorija.

Prema [18], bitno je naglasiti da ni jedna lokacija ne poseduje globalne informacije o

stanju baze podataka. Druga bitna stvar, je sam optimizer koji ima opciju prenosa upita

do lokacije gde misli da se podaci nalaze ili obrnut proces. Odabir koja će se strategija

koristiti predstavlja odluku optimizacije. I ako je poznato da se samostalni upit

optimalno izvršava prenosom upita do podataka, ako optimizer prosudi da je veća

verovatnoća da će upit pre biti viđen od strane lokacije, postoji mogućnost da je transfer

podataka bolja opcija. Mariposa optimizer uzima u obzir obe opcije.Treće, ako bi se

Mariposa odlučila da prenese podatake do upita, mora da odabere koju će kopiju da

prenese ili da odluči da napravi novu kopiju, što dalje dovodi do veće kompleksnosti

sistema.Četvrto, pretpostavlja se da je Mariposa sistem heterogen, tj da poseduje

različite brzine, kapacitet i osobine. Na primer, nemoguće je izrvšiti sve operacije na

svim, lokacijama zbog limita u kapacitetu memorije. Pored toga,u nadogradivom

DBMS okruženju, lokalni DBMS na svakoj lokaciji mogu imati drugačije tipove

biblioteka.

Kao rezultat dobijamo glavne aspekte Mariposa sistema:

1. sistem organizovan pravilima koji radi na mehanizmu koji je zasnovan na tom

setu pravila

2. algoritmi za kretanje fragmenata radi veće mobilnosti podataka

3. optimizer upita i mehanizam za izvršenje istih

4. dozvoljava multipliciranje kopija za ovo okruženje.

3.3 Platforma za sihronizaciju podataka

3.3.1 Microsoft Synchronization Services

“Microsoft Sync Framework je platforma za sinhronizaciju podataka. Sync Framework

ima arhitekturu koja ne zavisi od specifičnog transportnog protokola i u koju mogu biti

uključeni specifični sinhronizacioni provajderi implementirani kroz ADO.NET API.

Sync Framework se može koristiti za oflajn pristup podacima, pri čemu se lokalno radi

sa poslednjom prevučenom verzijom podataka, a promene se u paketima šalju udaljenoj

server bazi, za sinhornizaciju promena na svim čvorovima u mreži, kao i za

sinhronizaciju većeg broja direktno povezanih (engl. peer-to-peer) čvorova. Sync

Framework ima ugradjenu podršku za otkrivanje konflikta korišćenjem oznaka

30

konfliktnih podataka pri čemu korisnik naknadno razrešava konflikt (podaci su već

ažurirani) ili primenom definisane politike za rešavanje konflikta. Sync Services

uključuje i ugradjenu bazu SQL Server Compact za čuvanje meta podataka o procesu

sinhronizacije.”[19]

Prema [19], Sync Framework omogućava sinhronizaciju bez obzira na specifično

skladište podataka kao i na transportni protokol. Kroz specifične sinhronizacione

provajdere (engl. synchronization providers), bilo koji izvor podataka može biti

podržan. Postoje tri sinhronizaciona provajdera: Microsoft Sync Services for

ADO.NET, Sync Services for File Systems, i Sync Services for SSE.

“Sync Services API kreira sinhronizacionu sesiju, (Session objekat). Sinhronizacija se u

sesiji odvija korišćenjem dva sinhronizaciona provajdera – jedan za izvorišno skladište

podataka i jedan za odredišno skladište podataka. Tokom procesa sinhronizacije

odredišni provajder šalje skup podataka, izvorišni provajder uporedjuje ovaj skup sa

skupom promena na izvorištu i dobijene razlike šalje odredištu. Odredišni provajder

ispituje da li postoje konflikti i ažurira podatke na odredištu.”[19]

31

4. Rezultati naučno-stručnih istraživanja

4.1 Spanner - Guglova distribuirana baza podataka

“Spanner je skalabilna, globalna distribuirana baza podataka dizajnirana, izgradjena i

razvijena od strane Gugla. Sa gledišta visokog nivoa apstrakcije, to je baza podataka

koja deli podatke kroz mnoge setove Paxosa, kao statičke mašine u data centrima iz

celog sveta. Replikaicja se koristi za globalnu dostupnost i geografski lokalitet. Spanner

automatski deli podatke kroz mašine kao ogromnu kolicinu podataka ili brojeva ili

izmena servera i automatski migrira podatke kroz mašine (cak i kroz datacentre) kako bi

balansirao očitavanje i odgovore na greške. Spanner je dizajniran da pojača milione

mašina kroz hiljade datacentara i trilione redova baza podataka.” [23]

Prema [23], aplikacije mogu da koriste Spanner za široku namenu, cak i u pogledu

područja prirodnih katastrofa što se postiže repliciranjem njihovih podataka u okviru

odredjenih ili preko razlicitih kontinenata. Njihov glavni klijent bio je F1, kopija Gugl

marketinskog bekenda (AdWords). F1 koristi 5 replika raširenih širom USA. Većina

aplikacija verovatno bi replicirala svoje podatke u preko 3 do 5 datacentara u okviru

jednog geografskog regiona, ali sa relativno nezavisnim neuspelim režimima. Na taj

način, većina aplikacija će izabrati nižu latentnost (zadržavanje od inputa u sistem do

željenog izlaza; u pravom značenju skrivanje) nego visoku dostupnost, dok god mogu

da prežive 1 ili 2 neuspeha datacentara.

Prema [23], Spannerov glavni fokus je upravljvanje cross-datacenter repliciranim

podacima, ali takodje troši se značajno vreme za dizajniranje i implementaciju bitnih

karakteristika baza podataka koje se nalaze na vrhu infrastrukture distribuiranih sistema.

Iako mnogi projekti uspešno koriste Bigtable oni isto tako primaju pritužbe od mnogih

korisnika Bigtable-a kako sam Bigtable može biti veoma težak za korišćenje odredjenih

aplikacija: one koje su složene, razvijaju šeme ili one koje zahtevaju snažnu

konzistentnost u okviru prisustva širokog područja replikacije. Mnoge Gugl aplikacije

su izabrane da koriste Megastore zbog njihovog polurelacionog modela podataka i

podrške za sinhronu replikaciju, uprkos njihovom relativno slabom protoku. Kao

posledica, Spanner se razvio od Bigtable skladišta za verzioniranje koda u privremenu

32

multiverzionu bazu podataka. Podaci su uskladišteni u šematizovane polurelacione

tabele. Podaci su verzionirani i svaka verzija je automatski vremenski označena sa

njenim izvršenim vremenom. Stare verzije podataka su podložne prilagodjavanju

politikama sakupljaču smeća (garbage-collection – automatsko upravljanje memorijom),

i aplikacije mogu da čitaju podatke u uskladištene vremenske odrednice (timestamp –

vremenska odrednica kad se desi neki dogadjaj pa računar uzme to vreme kad se desio

dogadjaj). Spanner podržava opšte-namenske transakcije i obezbedjuje SQL upitni

jezik.

Prema [23], kao globalna distribuirana baza podataka, Spanner obezbedjuje nekoliko

interesantnih karakteristika. Prvo, replikacije konfigurisane za podatke mogu da se

dinamički kontrolišu veoma precizno od strane aplikacija. Aplikacije mogu da

specificiraju ograničenja za kontrolu koje sadrže datacentri, koliko su podaci dostupni

korisnicima (za kontrolu latentnosti čitanja), koliko su replike udaljene jedna od druge

(za kontrolu latentnosti upisa) i koliko puno replika je održivo(za kontrolu trajnosti,

dostupnosti i performansi za čitanje). Podaci mogu takodje da budu dinamički i

transparentno pomerani izmedju datacentara od strane sistema za balansiranje resursa

koji se koriste izmedju data centara. Drugo, Spanner ima dve karakteristike koje je teško

implementirati u distribuirane baze: on obezbedjuje eksternu konzistentnost čitanja i

pisanja i globalnu konzistentnost čitanja . Ove karakteristike omogućavaju Spanneru da

podrži konzistentne rezerve, konzistentna MapReduce izvršenja, i izmene atomičnih

šema (koje ne zavise od drugih šema), sve na globalnom nivou, čak i u prisustvu

odlazećih transakcija.Ove karakteristike su omogućene zahvaljujući činjenici da

Spanner dodeljuje globalno značajne tajmstampove za transakcije (kako bi se lakše

upravljalo transakcijama), čak iako transakcije mogu da budu distribuirane.

Tajmstampovi reflektuju red serijalizacije. Dodatno, red serijalizacije zadovoljava

eksternu konzistentnost: ako transakcija T1 se izvrši pre nego sto druga transakcija T2

počne, tada T1 izvršeni tajmstamp je manji od T2. Spanner je prvi sistem koji

obezbedjuje takve garancije na globalnom nivou.

“Ključ koji omogućava ove karakteristike je novi TrueTime API i njegova

implementacija. Ovaj API direktno prikazuje čas nesigurnosti (vremenska razlika

izmedju dva vremenska dogadjaja) i garancije na Spannerovim tajmstampovima koji

zavise od granica koje implementacija stvara. Ako je čas nesigurnosti ogroman, Spanner

33

usporava da bi sačekao taj čas nesigurnosti. Guglov klaster menadzment softver

obezbedjuje implementaciju TrueTime API-ja. Ova implementacija čuva čas

nesigurnosti malim (manji od 10ms) koristeći višestruke moderne časovne reference

(GPS i atomski sat). Konzervativno raportovon čas nesigurnosti je neophodan za

ispravnost. Čuvanje granica ovog časa na niskom nivou je neophodno za

učinkovitost.”[23]

4.2 Transakcioni menadzment u R* DSUPB

“R* je eksperimentalni, distribuirani sistem za upravljanje bazom podataka (DDBMS)

razvijen i pokrenut u IBM San Hose istraživačkoj laboratoriji. U distribuiranom sistemu

baze podataka akcije transakcije (atomična jedinica konzistentnosti i oporavka) mogu da

se pojave u više sajtova. Njihov model transakcije, dozvoljava višestruku manipulaciju

podacima i definisanje izveštaja za konstituisanje jedne transakcije. Kada izvršavanje

transakcije krene, njene operacije i akcije nisu ograničene. Uslovno izvršavanje i za

sada SQL izveštaji su dostupni u aplikacionim programima. Cela transakcija treba da

bude potpuno specificirana i otkrivena sistemu unapred. Distribuirana transakcija

izvršava protokol koji je potreban da osigura da svi efekti transakcije istraju ili da

nijedan od efekata istraje, uprkos neprekidnim sajtovima ili neuspešnim

komunikacionim linkovima. Drugim rečima, izvršeni protokol (commit protokol) je

neophodan da osigura jednoliku privrženost distribuiranih transakcionih izvršenja.”[24]

Prema [24], garantovana jednolikost zahteva da odredjene karakteristike postoje u

dstribuiranom sistemu baze podataka. Svaki proces transakcije je sposoban da

privremeno obavlja akcije transakcije tako da transakcija može da se ne izvrši ili da se

prekine. Takodje, svaka baza distribuiranog sistema baze podataka ima evidenciju koja

se koristi za povraćaj zapisa o promenama stanja transakcija tokom izvršavanja

protokola i transakcionih promena u bazi (UNDO/REDO evidencija). Evidencija zapisa

pažljivo je zapisana sekvencijalno u fajlu koji se cuva u stabilnom skladištu.Kada je

evidencioni zapis napravljen, moze da se izvrši sinhrono ili asinhrono. Transakciono

pisanje evidencionih zapisa ne dozvoljava da nastavi izvršavanje dok se operacija ne

završi. Ovo znaći da ako je sajt srušen (pretpostavljamo da rušenje rezultira u gubitku

sadržaja iz virtuelne memorije) nakon sto je prisiljen zapis kompletiran, tada prisiljen

zapis i onaj koji mu prethodi preživljavaju rušenje i postaju dostupni, iz stabilnog

skladišta, kada se sajt povrati. Veoma je važno da bude dostupan da gomila prisiljene

34

zapise za visoku performansu. R* vrsi elementarno gomilanje prisiljenih zapisa.S druge

strane, u asinhronom slucaju, zapis biva zapisan u bafer skladištu virtuelne memorije i

dozvoljeno je da migrira kasnije u stabilno skladište (tokom sledećeg prisiljavanja ili

kada se bafer log stranice popuni). Transakciono pisanje zapisa je dozvoljeno da nastavi

izvršavanje pre nego što migracija zauzme poziciju. Ovo znači da ako je sajt srušen

nakon upisa evidencije, tada zapis može biti dostupan za čitanje kada se sajt oporavi.

Važna tacka napomene je da sinhrono pisanje povećava vreme odgovora transakcije u

poredjenju sa asinhronim pisanjem.

R* koji je evolucija centralizovanog SUBP sistema R, kao njegov prethodnik, podržava

serijabilnost transakcije i koristi dvofazni zaključavajući protokol (2PL) kao paralelni

kontrolni mehanizam. Korist od 2Pl-a pokazuje mogućnost pojave dedloka (mrtve

petlje). R* umesto zaštite od dedloka, dozvoljava im (čak i distribuirani) da se dese i

onda ih rešava preko dedlok detekcije i žrtvena transakcija se prekida.

Neke od karakteristika u distribuiranom dedlok detekcionom protokolu su:

1. svi dedlokovi su rešeni uprkos neuspesima sajtova i linkova,

2. svaki dedlok je detektovan samo jednom,

3. prekoračenje u smislu razmene poruka je malo i

4. jednom distribuiran dedlok koji je detektovan, vreme za njegovo

rešavanje je malo.

4.3 Multibaza-integrisani heterogeni distribuirani sistem baza

podataka

Prema [28], Multibaza je softverski sistem koji pomaže integraciju neintegracionih,

heterogenih, distribuiranih baza podataka. Njen glavni cilj je da predstavi iluziju

integracione baze korisnicima bez zahteva da baza bude fizički integrisana. To se

ostvaruje dozvoljavajući korisnicima da vide bazu podataka kroz jednu globalnu šemu i

dozvoljavajući im pristup podacima koristeći upitni jezik visokog nivoa. Upiti

postavljeni preko ovog jezika su kompletno obradjeni od Multibaze ako je baza

integrisana, homogena i nedistribuirana. Multibaza koristi funkcionalni model podataka

da definise globalnu šemu i jezik DAPLEX kao upitni jezik visokog nivoa.

35

Prema [28], predložena arhitektura sistema Multibaze sastoji se od dve bazne

komponente: pomoćne dizajnerske šeme i pokretačkog podsistema za obradu upita.

Pomoćna dizajnerska šema obezbedjuje alate za integrisane baze podataka dizajnirane

da dizajniraju globalnu šemu i da definišu mapiranje od lokalne baze do globalne šeme.

Pokretački podsistem za obradu upita tada koristi definisano mapiranje za prevod

globalnih upita u lokalne upite, obezbedjujući da lokalni upiti budu izvršeni korektno i

efikasno od strane lokalno SUBP-a.

Šema arhitekture. Arhitektura Multibaze ima tri nivoa šeme, globalnu šemu na

gornjem nivou (GS), integracionu šemu (IS) i jednu lokalnu šemu (LS) po lokalnoj bazi

na srednjem nivou i jednu lokalnu domaću semu po lokalnoj bazi na donjem nivou.

Lokalna domaća je originalna postojeća sema definisana u lokalnom modelu podataka i

korišćena od strane SUBP-a. Izražavanjem LS-a u jednom modelu podataka, viši nivoi

sistema moraju da budu zabrinuti za razlike modela podataka medju lokalnim SUBPa.

U prilog tome, postoji integraciona šema koja opisuje bazu podataka koja sadrži

informacije potrebne za integrisanje baza podataka. Primera radi, pretpostavimo da

jedna baza evidentira brzinu brodova u miljama po satu, dok druga evidentira to sve u

kilometrima po satu. Da bi se integrisale ove dve baze, potrebna nam je informacija o

mapiranju izmedju ove dve mere. Ova informacija je uskladištena u integracionoj bazi

podataka.

Arhitektura obrade upita. Arhitektura pokretačkog podsistema obrade upita sastoji se

od softvera Multibaze i lokalnog SUBP-a. Korisnici prosledjuju upite preko globalne

šeme (nazvani globalni upiti) u softver Multibaze, koji ih prevodi u podupite preko

lokalne šeme (nazvani lokalni upiti). Ovi lokalni upiti se tada šalju u lokalni SUBP da

budu izvrseni.Pošto su globalni upiti postavljeni protivno globalnoj šemi bez ikakvog

znanja o distribuciji podataka i dostupnosti “brzo pristupajućih puteva”, softver

Multibaze mora da optimizuje upite kako bi se mogli efikasno izvršiti. U prilog tome,

proces prevodjenja mora takodje da bude korektan. To je da lokalni upiti moraju da

povrate tačne informacije koje originalni globalni upit zahteva.[28]

36

4.4 Distriuirani i paralelni sistemi baza podataka

“Distribuirane baze predstavaljaju kolekciju višestrukih, logički interrelacionih baza

podataka distribuiranih preko računarske mreže. Distribuirani SUBP je definisan kao

softverski sitem koji dozvojljava upravljanje distribuiranim bazama i čini da distribucija

bude distupna svima.

Istinski distribuiran SUBP ne razlikuje klijentsku i serversku mašinu. U idealnom

trenutku, svaki sajt moze da izvrši funkcionalnost klijenta i servera. Takva arhitektura,

nazvana peer-to-peer (P2P – jednak jednakom), zahteva sofisticirane protokole da

upravlja distribuiranim podacima preko višestrukih sajtova. Kompleksnost zahtevanog

softvera kasni u ponudi P2P distribuiranih proizvoda SUBP.

Baza podataka je fizički distribuirana preko sajtova podataka fragmentacijom i

replikacijom podataka. Pružajući relacionalnu šemu baze, fragmentacija deli svaku

relaciju u horizontalne ili vertikalne particije. Fragmentacija je poželjna zato što čini

mogućim da se postave podaci u neposrednoj blizini takvog mesta za korišćenje tako da

se smanje troškovi prenosa i smanji veličina relacija uključenih u korisničke upite.

Paralelni SUBP može da bude definisan kao SUBP implementiran na čvrsto spojenom

multiprocesoru. Razlika izmedju paralelnog SUBP i distribuiranog SUBP je malo

nejasna. Možda va-na razlika je ta da distribuirani SUBP pretpostavimo gubi

interkonekciju izmedju procesora koji imaju svoje vlastite operativne sistema i rade

nezavisno. Paralelni SUBP iskorišćavaju skorašnje multiprocesorske rečunarske

arhitekture u cilju da izgrade visoke performanse i visoku dostupnost servera baze

podataka po znatno nižoj ceni nego ekvivalentni mejnfrejm računari.” [29]

Prema [29], distribuirani i paralelni SUBP obezbedjuju istu funkcionalnost kao

centralizovani SUBP osim u okruženju gde su podaci distribuirani preko sajtova na

mreži ili preko čvorova multiprocesorskog sistema. Ova funkcionalnost obezbedjuje

transparentnost; tako su korisnici nesvesni distribucije podataka, fragmentacije i

replikacije.

“Obrada upita i optimizacija. U distribuiranim SUBP, obrada upita i optimizacione

tehnike moraju da adresiraju poteškoće koje pristižu od fragmentacije i distribucije

podataka. U obradi, mogućnosti za paralelno izvršavanje su identifikovane i neophodni

rad je eliminisan. Globalna optimizacija upita uključuje permutovanje reda operacija u

37

upitu, odredjivanje izvršavanja sajtova za različite distribuirane operacije i

identifikovanje najboljeg distribuiranog izvršnog algoritma za distribuirane operacije.

Paralelna optimizacija upita uzima prednost od intraoperacionog paralelizma i

interoperacionog paralelizma. Intraoperacioni paralelizam je postignut izvršavanjem

operacija na nekoliko čvorova multiprocesorske mašine. Paralelna optimizacija pri

korišćenju intraoperacionog paralelizma može da ima korist od nekih tehnika

osmišljenih za distribuirane baze. Interoperacioni paralelizam dešava se kada dve ili

više operacija se izvršavaju paralelno, ili kao dataflow (protok podataka) ili nezavisno.

Nezavisni paralelizam dešava se kada operacije se izvršavaju u istom trenutku ili u

arbitražnom redu. Nezavisni paralelizam je moguć samo kada operacije ne uključuju

same podatke.

Kontrola konkurentnosti. U distribuiranim SUBP, izazov u sinhronizovanju

konkuretntnih korisničkih transakcija je da proširi i argument serijabilnosti i algoritme

za kontrolu konkurentnosti u distribuiranoj izvršnoj okolini. U ovim sistemima,

operacije datih transakcija mogu da se izvrše u višestrukim sajtovima gde imaju pristup

podacima. Tako globalna serijabilnost zahteva:

a) Da izvršenje setova transakcija na svakom sajtu bude serijabilno

b) Da serijalizaciona naredjenja ovih transakcija na svim sajtovima budu identicne

Ako se koriste algoritmi za zaključavanje, zaključane tabele i menadžment odgovornosti

zaključavanja (lock menadzment odgovornosti) mogu da budu centralizovani ili

distribuirani. Dobro poznate nuspojave svih algoritama za zaključavanje kontrole

konkurentnosti su one koje uzrokuju dedlokove.

Replikacioni protokoli. U replikacionim distribuiranim bazama podataka, svaka logička

stavka podatka ima odredjen broj fizičkih instanci. Problem u ovom tipu sistema baze

podataka je da održi neke pojmove konzistentnosti medju kopijama fizičkih instanci

kada korisnici transparentno vrše ažuriranje logičkih stavki podataka. Pravi kriterijum

konzistentnosti je jednokopijska ekvivalentnost koja ističe da vrednost svih fizičkih

kopija logičkih stavki podataka treba da bude identicne kada transakcija koja se ažurira

se prekine. Tipični protokol za kontrolu replikacije koji primenjuje jednokopijsku

serijabilnost je poznat kao Čitaj-Jednom/Piši-sve (ROWA) protokol. Ovaj protokol je

jednostavan i jasan, ali zahteva da sve kopije logičkih stavki podataka budu ažurirane od

strane transakcije kako bi bili pristupačne za transakcije koje se prekidaju. Neuspeh

jednog sajta može da blokira transakciju, smanjujući dostupnost baze podataka.” [29]

38

5. Implementirano rešenje

5.1 Opis poslovnog konteksta

Primer poslovnog procesa koji je izabran za ilustrovanje primerima implementacije je

rezervisanje turističkih destinacija.

Radnik turističke agencije evidentira nove destinacije, na osnovu prethodne prijave

same destinacije (hotela i slično). Klijent turističke agencije pregleda ponudu destinacija

i bira jednu destinaciju, pri čemu navodi i željene karakteristike samog smeštaja.

Turistička agencija kontaktira destinaciju i proverava rasploživost i karakteristike

raspoloživih kapaciteta. Ukoliko je slobodan smeštaj željenih karakteristika, klijent

potvrdjuje rezervaciju i evidentira se rezervacija. Agencija kontaktira destinaciju i

obaveštava o rezervisanju.

5.2 Cilj i opis korišćenih tehnologija

Cilj je ilustrovati tehnike procesiranja u distribuiranoj bazi podataka. Biće prikazani

primeri za sledeće tehnologije: replikacija, particionisanje, transakcije i oporavak baze

podataka.Tehnologije koje su korištene u realizaciji primera su: MS SQL Server i

Visual Studio 2010 kao i Power Designer za modele.

5.2.1 MS SQL Server

“SQL je skraćenica za „Structured Query Language“ što u prevodu znači

strukturirani jezik za upite. “[20]

Prema[20], relacioni upitni jezici predstavljaju praktičan rezultat formalnih istraživanja

relacionog modela i relacionih jezika. Mada su oni, u suštini, zasnovani na relacionoj

algebri, relacioni upitni jezici poseduju znatno širi spektar mogućnosti za opštije

izražavanje radnji nad tabelama relacione baze. Način na koji se formulišu upiti u ovim

jezicima prilagođen je širokom krugu korisnika baza podataka, posebno korisnicima sa

skromnim znanjima iz matematike i programiranja.

“SQL razvrstava kategorije SQL naredbi u sedam kategorija :

Naredbe za šemu baze podataka (SQL-schema statements) - za kreiranje, izmenu

i izbacivanje šema i objekata šema (CREATE, ALTER, DROP)

39

Naredbe za podatke (SQL-data statements) - za prikaz i ažuriranje podataka baze

(SELECT, INSERT, UPDATE, DELETE)

Naredbe za transakcije (SQL-transaction statements) - za startovanje,

završavanje i postavljanje parametara za transakcije(COMMIT, ROLLBACK)

Naredbe za kontrolu (SQL-contol statements), koje se koriste za kontrolu

izvršavanja sekvence SQL naredbi (CALL, RETURN)

Naredbe za konekcije (SQL-connection statements) - za uspostavljanje i

prekidanje SQL konekcije (CONNECT, DISCONNECT)

Naredbe za sesije (SQL-session statements) - za postavljanje default vrednosti i

drugih parametara SQL sesije (SET)

Naredbe za dijagnostiku (SQL-diagnostic statements) - signalizuju izuzetke u

SQL rutinama (GET DIAGNOSTIC)”[20]

5.2.2 PHP My Admin

Ovaj alat predstavlja sastavni deo XAMPP paketa koji sadrži različite alate potrebne za

rad sa PHP (Web server Apache) i MYSQL bazom podataka (PHP MyAdmin).

U okviru ovog alata postoje opcije:

Kreiranje baze podataka, tabela, pogleda, stored procedura

Rad sa SQL skriptom

Unos podataka

Eksport podataka

Grafički prikaz structure relacione baze podataka.

5.2.3 Microsoft Visual Studio 2010

Prema [21], Microsoft Visual Studio predstavlja integrisano razvojno okruženje (IDE)

napravljeno od strane Microsofta. Koristi se za pravljenje programa za Microsoft

Windows forme, takođe za veb sajtove, veb aplikacije i veb servise.

Visual Studio koristi Microsoft platforme za kreiranje softvera kao što su:

Windows API,

Windows Forms,

Windows Presentatation Foundation,

40

Windows Store i

Microsoft Silverlight.

5.2.4 PowerDesigner

Prema [22], PowerDesigner je vodeći softverski alat za modelovanje procesa

raznorodnih sistema i podataka koji se u njima pojavljuju. Optimizovan za kolaboraciju

više korisnika, PowerDesigner je projektovan za Windows okruženje kao host

aplikacija, koja za pluginove (dodatke) koristi Java platformu i programsko okruženje

Eclipse. PowerDesigner nudi mnogo mogućnosti u oblasti modelovanja:

Modelovanje poslovnih procesa (u daljem tekstu BPM – Business

ProcessModeling),

Generisanje programskog koda (Java, C#, VB.NET, JSF, PowerBuilder itd),

Modelovanje podataka (rad sa vodećim sistemima za upravljanje bazama

podataka),

Modelovanje DataWarehouse-a,

Eclipse programiranje,

Objektno modeliranje (UML2.0 dijagrami),

Generisanje izveštaja,

Rad sa repozitorijumima,

Generisanje XML šema u DTD standardu itd.

5.3 Modeli

U ovom odeljku će biti prikazan business process model kojim se opisuje tok poslovnog

procesa u turističkoj agenciji. Na osnovu BPM modela uradjen je use case koji

predstavlja softverske funkcije budućeg softverskog rešenja. Modeli podataka nisu

predstavljeni u ovom odeljku, jer je u odeljku implementacije data šema baze podataka

koja je implementirana. Na kraju, predstavljen je dijagram komponenti i razmeštaja.

41

5.3.1 Business process model

Slika 3. Biznis process model

5.3.2 Use case model

<<extend>>

<<extend>>

<<extend>>

<<extend>>

<<extend>>

<<extend>>

<<access>>

<<access>>

<<access>>

<<access>>

<<access>>

<<include>>

<<include>>

<<access>>

Radnik TA

Klijent TA

Turisticka destinacija

Unos nove destinacije

TAbelarni prikaz destinacija sa podacima o raspolozivosti kapaciteta

Filtriranje destinacija

Brisanje destinacije

Izmena destinacije

Stampa svih destinacija fi ltrirano

Tabelarni prikaz destinacija i raspolozivosti kapaciteta za kli jente

Filtriranje destinacija prema mestu, drzavi, tipu desticije

Stampanje spiska destinacija fi ltrirano

Izbor zeljene destinacije i pojedinacni prikaz

Stampa pojedinacne destinacije

Unos rezervacije za izabranu destianciju *

Tabelarni prikaz svih unetih destinacija

Tabelarni prikaz rezervacija i zauzeca za tu destinaciju

Automatsko azuriranje statusa zauzetosti smestajnih kapaciteta

Unos podataka o zauzimanju smestajnog kapaciteta

Slika 3. Use case model

42

5.3.3 Dijagram komponenti

Softverska podrska turisticke agencije Softverska podrska turisticke destinacije

DBMS TA

DBMS TD

Web aplikacija turisticke agencijeWeb servis za proveru smestajnih kapaciteta Web aplikacija za turisticku destinaciju

Web servis za distribuiranu transakciju i sinhronizaciju azuriranja stanja zauzetosti kapaciteta

Centralna baza podataka

Bekap baza podataka

Horizontalno particionisana baza podataka

Vertikalno particionisana baza podataka

Baza podataka turisticke desinacije

Slika 5. Dijagram komponenti

5.3.4 Dijagram razmeštaja

Slika 6. Dijagram razmeštaja

5.4 Korisničko uputstvo

Implementiran je deo programa koji se odnosi na unos podataka o rezervaciji koji

posledično snima podatke u bazu podataka turističke agencije i druge baze podataka,

koristeći razne tehnike distribuiranih baza podataka (replikacija – rezervna kopija baze,

udaljeni pristup drugoj bazi podataka putem web servisa, horizontalno i vertikalno

particionisanje, distribuirane transakcije i oporavak baze).

U ovom odeljku je dat izgled osnovnog ekrana za unos podataka o rezervaciji. Ostale

softverske funkcije web aplikacije za turističku agenciju i destinaciju nisu realizovane.

43

Slika 7. Izgled osnovnog ekrana za unos podataka o rezervaciji

Slika 8. Ekran za primenom web servisa za proveru kapaciteta

44

5.5 Opis implementacije

5.5.1 Šema baze podataka i SQL script za kreiranje baze podataka

U realizaciji ovog rada imamo 2 baze podataka (za obe su date shema baze podataka i

SQL script za kreiranje BP):

1. Baza podataka turističke agencije ,

2. Baza podataka turističke destinacije.

Slika 9. Shema baze podataka turističke agencije

USE [master] GO

CREATE DATABASE [TuristickaAgencija]

GO

USE [TuristickaAgencija]

GO

CREATE TABLE [dbo].[TipDestinacije](

[Id] [int] NOT NULL,

[Naziv] [nvarchar](50) NULL )

GO

45

ALTER TABLE [dbo].[TipDestinacije] ADD CONSTRAINT [PK_TipDestinacije] PRIMARY KEY CLUSTERED

( [Id] ASC

)

GO

CREATE TABLE [dbo].[TipBoravka](

[Id] [int] NOT NULL, [Naziv] [nvarchar](50) NULL

)

GO ALTER TABLE [dbo].[TipBoravka]

ADD CONSTRAINT [PK_TipBoravka] PRIMARY KEY CLUSTERED

( [Id] ASC

)

GO

CREATE TABLE [dbo].[Drzava](


[Naziv] [nvarchar](50) NULL )

GO

ALTER TABLE [dbo].[Drzava] ADD CONSTRAINT [PK_Drzava] PRIMARY KEY CLUSTERED

( [Id] ASC

)

GO CREATE TABLE [dbo].[Mesto](


[Naziv] [nvarchar](50) NULL, [Id_Drzave] [int] NULL

)

GO

ALTER TABLE [dbo].[Mesto]

ADD CONSTRAINT [PK_Mesto] PRIMARY KEY CLUSTERED

( [Id] ASC

)

GO CREATE TABLE [dbo].[Destinacija](


[PIB] [nvarchar](50) NULL, [Naziv] [nvarchar](50) NULL,

[Id_Mesta] [int] NULL,

[Adresa] [nvarchar](50) NULL, [Email] [nvarchar](50) NULL,

[Telefon] [nvarchar](50) NULL,

[Id_Tipa_Destinacije] [int] NULL )

GO

ALTER TABLE [dbo].[Destinacija] ADD CONSTRAINT [PK_Destinacija] PRIMARY KEY CLUSTERED

(

[Id] ASC )

GO

CREATE TABLE [dbo].[Rezervacija]( [Id] [int] NOT NULL,

[Prezime] [nvarchar](50) NULL,

[Ime] [nvarchar](50) NULL, [Datum_Rodjenja] [date] NULL,

[Telefon] [nvarchar](50) NULL,

[Adresa] [nvarchar](50) NULL, [Id_Mesta] [int] NULL,

[Id_Destinacije] [int] NULL,

[Datum_Boravka_Od] [date] NULL, [Datum_Boravka_Do] [date] NULL,

[Id_Tip_Boravka] [int] NULL,

[Ukupna_Cena_Aranzmana] [decimal](18, 2) NULL )

GO

ALTER TABLE [dbo].[Rezervacija]

ADD CONSTRAINT [PK_Rezervacija] PRIMARY KEY CLUSTERED

46

( [Id] ASC

) GO

CREATE TABLE [dbo].[Cenovnik](

[Id] [int] NOT NULL, [Kalendarska_godina] [int] NULL,

[Id_Destinacije] [int] NULL,

[Id_Tipa_Boravka] [int] NULL, [Cena_Za_Dan] [decimal](18, 2) NULL

)

GO ALTER TABLE [dbo].[Cenovnik]

ADD CONSTRAINT [PK_Cenovnik] PRIMARY KEY CLUSTERED

( [Id] ASC

)

GO

Listing 1. SQL script baze podataka turističke agencije

Slika 10. Shema baze podataka turističke destinacije

USE [master]

GO

CREATE DATABASE [TuristickaDestinacija]

GO

USE [TuristickaDestinacija]

GO

CREATE TABLE [dbo].[Soba](


[PIB] [nvarchar](50) NULL,

[Oznaka] [nvarchar](50) NULL,

[Opis] [nvarchar](50) NULL

)

GO

ALTER TABLE [dbo].[Soba]

47

ADD CONSTRAINT [PK_Soba] PRIMARY KEY CLUSTERED

(

[Id] ASC

)

GO

CREATE TABLE [dbo].[ZauzueceSobe](


[Id_Sobe] [int] NULL,

[Datum_Zauzeta_Od] [date] NULL,

[Datum_Zauzeta_Do] [date] NULL

)

GO

ALTER TABLE [dbo].[ZauzeceSobe]

ADD CONSTRAINT [PK_ZauzeceSobe] PRIMARY KEY CLUSTERED

(

[Id] ASC

)

GO

Listing 2. SQL script baze podataka turistička destinacija

5.5.2 Delovi programskog koda sa objašnjenjima

5.5.2.1 Opis osnovnih elemanta realizacije web aplikacije uz primenu tehnika distribuiranih baza podataka

U ovom delu biće opisana implementacija osnovnih koncepata rada sa distribuiranim

bazama podataka u okviru opisa realizacije web aplikacije i web servisa, koristeći

Visual Studio .NET razvojno okruženje, ASPX/C# programiranje i MSSQL Server bazu

podataka. Realizovani primer ilustruje za sledeće koncepte:

1. Replikacija: podaci iz jedne baze podataka se kopiraju u drugu bazu podataka.

Podaci iz baze podataka Turistička agencija se kopiraju u bazu Backup

Turistička agencija.

2. Particionisanje:

– Horizontalno: podaci se snimaju prilikom unosa u jednu od dve baze

podataka i razvrstavaju se po kriterijumu države destinacije u: bazu

podataka Turistička agencija Svet i Turistička agencija Srbija.

– Vertikalno: podaci se istovremeno snimaju u 2 baze podataka koje

imaju istoimenu tabelu Rezervacija, ali imaju deo polja u odnosu na

celovitu tabelu rezervacija. Odvojeni su podaci o klijentu i podaci o

samom aranžmanu koji je klijent rezervisao.

3. Distribuirane transakcije – prilikom unosa podataka, podaci se snimaju u više

baza podataka i svi upiti tipa insert into koji idu nad različitim bazama podataka

su objedinjeni objektom klase Transaction Scope čime se upravlja svim

pojedinačnim transakcijama kao celinom.

48

4. Oporavak baze podataka – simulacija iskljucivanja jedne baze podataka u

odnosu na skup svih baza podataka i nakon ponovnog uključivanja, detektovanje

koji su nedostajući podaci i nadoknadjivanje nedostajućih podataka.

5.5.2.2 Opsti deo za sve primere

U sledećem listing je prikazan kod za konektovanje na bazu podataka u okviru web

config.

<connectionStrings>

<add name="ApplicationServices"

connectionString="data source=.\SQLEXPRESS;Integrated

Security=SSPI;AttachDBFilename=|DataDirectory|\aspnetdb.mdf;User Instance=true"

providerName="System.Data.SqlClient" />

<add name="KonekcijaTuristickaAgencija"

connectionString="Data Source=MIRKO-PC\SQLEXPRESS; Initial Catalog=TuristickaAgencija; Integrated

Security=True;"


<add name="KonekcijaTuristickaAgencijaSrbija"

connectionString="Data Source=MIRKO-PC\SQLEXPRESS; Initial Catalog=TuristickaAgencijaSrbija;

Integrated Security=True;"


<add name="KonekcijaTuristickaAgencijaSvet"

connectionString="Data Source=MIRKO-PC\SQLEXPRESS; Initial Catalog=TuristickaAgencijaSvet;



<add name="KonekcijaTuristickaAgencijaBackup"

connectionString="Data Source=MIRKO-PC\SQLEXPRESS; Initial Catalog=TuristickaAgencijaBackup;



<add name="KonekcijaTuristickaAgencijaLicniPodaci"

connectionString="Data Source=MIRKO-PC\SQLEXPRESS; Initial Catalog=TuristickaAgencijaLicniPodaci;



<add name="KonekcijaTuristickaAgencijaAranzman"

connectionString="Data Source=MIRKO-PC\SQLEXPRESS; Initial Catalog=TuristickaAgencijaAranzman;



</connectionStrings>

Listing 3. Konektovanje na baze podataka

protected void btnSnimi_Click(object sender, EventArgs e)

{

// PREUZIMANJE VREDNOSTI IZ KORISNICKOG INTERFEJSA

objRezervacija = new clsRezervacija();

objRezervacija.Id = int.Parse(txtID.Text);

objRezervacija.Ime = txtIme.Text;

objRezervacija.Prezime = txtPrezime.Text;

objRezervacija.DatumRodjenja = txtDatumRodjenja.Text;

objRezervacija.Telefon = txtTelefon.Text;

objRezervacija.Mesto = ddlMesto1.Text;

objRezervacija.Adresa = txtAdresa.Text;

objRezervacija.Id_Destinacije = ddlNazivDestinacije.Text;

objRezervacija.Datum_Boravka_Od = txtDatumBoravkaOd.Text;

objRezervacija.Datum_Boravka_Do = txtDatumBoravkaDo.Text;

objRezervacija.Id_Tip_Boravka = ddlTipBoravka.Text;

Listing 4. Preuzimanje vrednosti iz korisničkog interfejsa

49

Svi delovi koji se odnose na poziv procedure snimi podatke biće prikazani u nastavku.

Svaki rad sa pojedinačnom bazom podataka rezultuje uspehom ili neuspehom, koji se

beleži u okviru statusa.

if (brojSlogovaUspesnoSnimljeno > 0) {

TekstStatusa = TekstStatusa + " KonekcijaTuristickaAgencija =U;";

}

else {

TekstStatusa = TekstStatusa + " KonekcijaTuristickaAgencija =N;";

}

}

catch (Exception greska) {

TekstStatusa = TekstStatusa + " KonekcijaTuristickaAgencija =G=" + greska.Message;

}

// PRIKAZ STATUSA ZA SVE BAZE

lblStatus.Text = TekstStatusa;

Listing 5.Prikaz statusa uspeha

5.5.2.3 Implementacija replikacije podataka

Replikacija podataka je implementirana kao istovremeno snimanje, pored osnovne, u

bekap bazu podataka. Listing 6. opisuje proceduru za snimanje, koja se poziva u okviru

tastera Snimi na korisničkom interfejsu (Listing 7.). U okviru algoritma za snimanje na

tom tasteru nalaze se 2 bloka koda- za snimanje u osnovnu i bekap bazu podataka.

private int SnimiPodatke(string NazivStringaKonekcije, string Id, string Prezime string Ime, string

Datum_Rodjenja, string Telefon, string Adresa, string Id_Mesta, string Id_Destinacije, string Datum_Boravka_Od,

string Datum_Boravka_Do, string Id_Tip_Boravka)

{

int brojslogova = 0;

// konektovanje na bazu

SqlConnection Veza = new

SqlConnection(ConfigurationManager.ConnectionStrings[NazivStringaKonekcije].ConnectionString);

Veza.Open();

// snimanje podataka

String strSQL = "";

strSQL = "Insert into Rezervacija (Id, Prezime, Ime, Datum_Rodjenja, Telefon, Adresa, Id_Mesta,

Id_Destinacije, Datum_Boravka_Od, Datum_Boravka_Do, Id_Tip_Boravka ) values (" + Id + ", '" + Prezime + "','" +

Ime + "', '" + Datum_Rodjenja + "', '" + Telefon + "', '" + Adresa + "', '" + Id_Mesta + "', '" + Id_Destinacije + "', '" +

Datum_Boravka_Od + "', '" + Datum_Boravka_Do + "', '" + Id_Tip_Boravka + "' )";

SqlCommand Komanda = new SqlCommand(strSQL, Veza);

brojslogova = Komanda.ExecuteNonQuery();

// diskonektovanje sa baze

Veza.Close();

Veza.Dispose();

return brojslogova;

}

Listing 6.Procedura za snimanje

50


{

// snimanje u glavnu bazu podataka

try

{

brojslogovarezervacija = SnimiPodatke("KonekcijaTuristickaAgencija", txtId.Text, txtPrezime.Text,

txtIme.Text, txtDatumRodjenja.Text, txtTelefon.Text, txtAdresa.Text, ddlMesto1.Text, ddlNazivDestinacije.Text,

txtDatumBoravkaOd.Text, txt.DatumBoravkaDo.Text, ddlTipBoravka.Text);

if (brojslogovarezervacija > 0)

{

porukauspeharezervacija = "Uspesno dodavanje nove!";

}

else

{

porukauspeharezervacija = "Neuspeh dodavanja!";

}

}

catch (Exception ex)

{

porukauspeharezervacija = ex.Message.ToString();

}

// kopiranje u bekap bazu

try

{

brojslogovarezervacija = SnimiPodatke("KonekcijaTuristickaAgencijaBackup", txtId.Text,

txtPrezime.Text, txtIme.Text, txtDatumRodjenja.Text, txtTelefon.Text, txtAdresa.Text, ddlMesto1.Text,

ddlNazivDestinacije.Text, txtDatumBoravkaOd.Text, txt.DatumBoravkaDo.Text, ddlTipBoravka.Text);


{


}

else

{


}

}

Listing 7. Snimanje podataka u glavnu i backup bazu

5.5.2.4 Implementacija horizontalnog particionisanja

Horizontalno particionisanje podataka podrazumeva snimanje istih podataka u različite

baze podataka po nekom kriterijumu razvrstavanja (snima se samo u jednu od baza

podataka ako odgovara tom kriterijumu). U ovom primeru, u zavisnosti od vrednosti

lblDrzava vrši se razvrstavanje na bazu za rezervacije za Srbiju i druge države.

string vrstadrzave = lblDrzava.Text;

if (vrstadrzave.Equals (“Srbija”)

{

try

{

brojslogovasrbija = SnimiPodatke("KonekcijaTuristickaAgencijaSrbija", txtId.Text, txtPrezime.Text,



51

if (brojslogovasrbija > 0)

{

porukauspehasrbija = "Uspesno dodavanje novog!";

}

else

{

porukauspehasrbija= "Neuspeh dodavanja!";

}

}


{

porukauspehasrbija = ex.Message.ToString();

}

}

else

{

try

{

brojslogovasvet = SnimiPodatke("KonekcijaTuristickaAgencijaSvet", txtId.Text, txtPrezime.Text,



if (brojslogovasvet > 0)

{

porukauspehasvet = "Uspesno dodavanje novog!";

}

else

{

porukauspehasvet = "Neuspeh dodavanja!";

}

}


{

porukauspehasvet = ex.Message.ToString();

}

}

Listing 8. Implementacija horizontalnog particionisanja

5.5.2.5 Implementacija vertikalnog particionisanja

Kod implementacije vertikalnog particionisanja podaci se upisuju u obe baze podataka

istovremeno, ali se deo podataka snima u jednu bazu podataka, a deo u drugu. U ovom

primeru smo odvojili lične podatke i podatke o aranžmanu koji se inače čuvaju u

zajedničkoj tabeli u osnovnoj bazi podataka. U listingu 9. je data procedura Snimi

podatke koja omogućava izvršavanje različitih SQL upita tipa insert into u zavisnosti da

li se snimaju podaci u celu bazu podataka (“full”) ili deo podataka za vertikalno

particionisanje. U listing 10 je prikazano pozivanje ove procedure na 2 načina –

parcijalno snimanje.

private int SnimiPodatke(string nazivStringaKonekcije, string tipUpisa, clsAerodrom

objNovaRezervacija)

{



52


SqlConnection(ConfigurationManager.ConnectionStrings[nazivStringaKonekcije].ConnectionString);

Veza.Open();


String strSQL = "";

switch (tipUpisa)

{

case "full":

strSQL = "Insert into Rezervacija(Id, Prezime, Ime, Datum_Rodjenja, Telefon, Adresa, Id_Mesta,

Id_Destinacije, Datum_Boravka_Od, Datum_Boravka_Do, Id_Tip_Boravka) values (" + objNovaRezervacija.Id + ",

'" + objNovaRezervacija.Prezime + "'," + objNovaRezervacija.Ime + ",'" + objNovaRezervacija.Datum_Rodjenja +

"'," + objNovaRezervacija.Telefon + "," + objNovaRezervacija.Adresa + ",'" + objNovaRezervacija.Id_Mesta + "','" +

objNovaRezervacija.Id_Destinacije + "','" + objNovaRezervacija.Datum_Boravka_od + "','" +

objNovaRezervacija.Datum_Boravka_Do + "','" + objNovaRezervacija.Id_Tip_Boravka + "')";

break;

case "LicniPodaci":

strSQL = "Insert into Rezervacija(Id, Prezime, Ime, Datum_Rodjenja, Telefon, Adresa, Id_Mesta) values

(" + objNovaRezervacija.Id + ", '" + objNovaRezervacija.Prezime + "'," + objNovaRezervacija.Ime + ",'" +

objNovaRezervacija.Datum_Rodjenja + "'," + objNovaRezervacija.Telefon + "," + objNovaRezervacija.Adresa + ",'"

+ objNovaRezervacija.Id_Mesta + "')";

break;

case "Aranzman":

strSQL = "Insert into Rezervacija(Id, Id_Destinacije, Datum_Boravka_Od, Datum_Boravka_Do,

Id_Tip_Boravka) values ('" + objNovaRezervacija.Id_Destinacije + "','" + objNovaRezervacija.Datum_Boravka_od +

"','" + objNovaRezervacija.Datum_Boravka_Do + "','" + objNovaRezervacija.Id_Tip_Boravka + "') ";

break;

};




Veza.Close();

Veza.Dispose();

return brojslogova;

}

Listing 9.Implementacija vertikalnog particionisanja

// =========== VERTIKALNO PARTICIONISANJE

// licni podaci

try

{

int brojSlogovaUspesnoSnimljeno = SnimiPodatke("KonekcijaTuristickaAgencijaLicniPodaci",

"LicniPodaci", objRezervacija);

if (brojSlogovaUspesnoSnimljeno > 0)

{

TekstStatusa = TekstStatusa + "KonekcijaTuristickaAgencijaLicniPodaci =U;";

}

else

{

TekstStatusa = TekstStatusa + "KonekcijaTuristickaAgencijaLicniPodaci =N;";

}

}

catch (Exception greska)

{

TekstStatusa = TekstStatusa + "KonekcijaTuristickaAgencijaLicniPodaci =G;"; //+ greska.Message;

}

// aranzman– odmah iza, oba se upisuju

53

try

{

int brojSlogovaUspesnoSnimljeno = SnimiPodatke("KonekcijaTuristickaAgencijaAranzman ",

"Aranzman", objRezervacija);


{

TekstStatusa = TekstStatusa + "KonekcijaTuristickaAgencijaAranzman =U;";

}

else

{

TekstStatusa = TekstStatusa + "KonekcijaTuristickaAgencijaAranzman;";

}

}


{

TekstStatusa = TekstStatusa + "KonekcijaTuristickaAgencijaAranzman =G=" + greska.Message;

}

Listing 10. Pozivanje u okviru dugmeta snimi

5.5.2.6 Implementacija distribuirane transakcije

Dodajemo iz standardnog paketa .NET biblioteka klasa – biblioteku

System.Transactions, da bismo mogli da koristimo TransactionScope klasu. Inače, u

System.Data.SQLClient postoji SQLTransaction klasa, ali radi samo sa jednom bazom

podataka.

Slika 11. Dodavanje biblioteke System.Transactions

U nastavku u listingu 11 se nalazi deo koda kojim se koristi TransactionScope objekat

kojim se objedinjuje izvršavanje upita nad više baza podataka. Pojedini blokovi koda

kojima se pristupa pojedinačnim bazama podataka opisani su u prethodnim odeljcima,

pa su ovde navedeni samo komentarima.

54


{

// preuzimanje vrednosti KI

using (TransactionScope scope = new TransactionScope())

{

// snimanje TuristickaAgencija

// snimanje TuristickaAgencijaBackup

// snimanje TuristickaAgencijaSrbija

// snimanje TuristickaAgencijaSvet

// snimanje TuristickaAgencijaLicniPodaci

// snimanje TuristickaAgencijaAranzman

scope.Complete();

} // zatvaranje transaction scope

} // zatvaranje procedure btnSnimi_Click

Listing 11. Implementacija TransactionScope-a

Ceo kod sa svim delovima snimanja u svih šest baza podataka koje su objedinjene u

zajednički TransactionScope biće prikazan u prilogu.

5.5.2.7 Implementacija oporavka baze podataka

U ovom odeljku ćemo simulirati privremenu nemogućnost rada sa jednom bazom

podataka i njen oporavak. Simulacija se izvršava u više koraka, uz korišćenje Kataloga

distribuirane baze podataka.

1. Korak - Obrada unosa podataka u više baza podataka realizuje se zajedničkim

programskim kodom za pristup svakoj bazi podataka (čitanjem u for ciklusu

redom jedne po jedne stavke kataloga koja opisuje jednu po jednu iz niza

distribuiranih baza podataka) i izvršavanjem specifičnog koda koji se odnosi na

poseban tip baze koja se obrađuje.

Katalog distribuirane baze podataka – XML sa strukturom koja sadrži naziv

baze podataka, tip baze i connection string.

<?xml version="1.0" encoding="UTF-8"?>

<Katalog>

<BazaPodataka>

<naziv>TuristickaAgencija</naziv>

<tip>full</tip>

<StringKonekcije>Data Source= MIRKOPC\SQLEXPRESS;InitialCatalog=TuristickaAgencija; Integrated

Security=True;";</ StringKonekcije >

</BazaPodataka>

<BazaPodataka>

<naziv>TuristickaAgencijaBackup</naziv>

<tip>full</tip>

<StringKonekcije>Data Source= MIRKOPC\SQLEXPRESS;InitialCatalog=TuristickaAgencijaBackup;

Integrated Security=True;";</ StringKonekcije >

</BazaPodataka>

<BazaPodataka>

<naziv>TuristickaAgencijaSvet</naziv>

<tip>full</tip>

55

<StringKonekcije>DataSource=MIRKOPC\SQLEXPRESS;InitialCatalog=TuristickaAgencijaSvet;

Integrated Security=True;";

</ StringKonekcije >

</BazaPodataka>

<BazaPodataka>

<naziv>TuristickaAgencijaSrbija</naziv>

<tip>full</tip>

<StringKonekcije>Data Source= MIRKOPC\SQLEXPRESS;InitialCatalog=TuristickaAgencijaSrbija;


</BazaPodataka>

<BazaPodataka>

<naziv>TuristickaAgencijaLicniPodaci</naziv>

<tip>LicniPodaci</tip>

<StringKonekcije>Data Source=

MIRKOPC\SQLEXPRESS;InitialCatalog=TuristickaAgencijaLicniPodaci; Integrated Security=True;";</

StringKonekcije >

</BazaPodataka>

<BazaPodataka>

<naziv>TuristickaAgencijaAranzman</naziv>

<tip>Aranzman</tip>

<StringKonekcije>Data Source= MIRKOPC\SQLEXPRESS;InitialCatalog=TuristickaAgencijaAranzman;


</BazaPodataka>

</Katalog>

Listing 12. XML kataloga distribuirane baze podataka

Listing 13. prikazuje izmenjene procedure za snimi podatke koja dobija string konekcije

kao parameter, a ne naziv stringa konekcije koji je ranije omogućavao čitanje iz Web

Config. Ovako omogućavamo univerzalno učitavanje podataka:

private int SnimiPodatke(string StringKonekcije, string tipUpisa, clsAerodrom objNovaRezervacija)

{



SqlConnection Veza = new SqlConnection(StringKonekcije);

Veza.Open();


String strSQL = “”;

switch (tipUpisa)

{

case “full”:

strSQL = “Insert into Rezervacija(Id, Prezime, Ime, Datum_Rodjenja, Telefon, Adresa, Id_Mesta,

Id_Destinacije, Datum_Boravka_Od, Datum_Boravka_Do, Id_Tip_Boravka) values (“ + objNovaRezervacija.Id + “,

‘” + objNovaRezervacija.Prezime + “’,” + objNovaRezervacija.Ime + “,’” + objNovaRezervacija.Datum_Rodjenja +

“’,” + objNovaRezervacija.Telefon + “,” + objNovaRezervacija.Adresa + “,’” + objNovaRezervacija.Id_Mesta + “’,’”

+ objNovaRezervacija.Id_Destinacije + “’,’” + objNovaRezervacija.Datum_Boravka_od + “’,’” +

objNovaRezervacija.Datum_Boravka_Do + “’,’” + objNovaRezervacija.Id_Tip_Boravka + “’)”;

break;

case “LicniPodaci”:

strSQL = “Insert into Rezervacija(Id, Prezime, Ime, Datum_Rodjenja, Telefon, Adresa, Id_Mesta) values

(“ + objNovaRezervacija.Id + “, ‘” + objNovaRezervacija.Prezime + “’,” + objNovaRezervacija.Ime + “,’” +

objNovaRezervacija.Datum_Rodjenja + “’,” + objNovaRezervacija.Telefon + “,” + objNovaRezervacija.Adresa +

“,’” + objNovaRezervacija.Id_Mesta + “’)”;

break;

case “Aranzman”:

strSQL = “Insert into Rezervacija(Id, Id_Destinacije, Datum_Boravka_Od, Datum_Boravka_Do,

Id_Tip_Boravka) values (‘” + objNovaRezervacija.Id_Destinacije + “’,’” + objNovaRezervacija.Datum_Boravka_od

+ “’,’” + objNovaRezervacija.Datum_Boravka_Do + “’,’” + objNovaRezervacija.Id_Tip_Boravka + “’) “;

break;

};

56




Veza.Close();

Veza.Dispose();

return brojslogova;

}

Listing 13. Izmena procedure snimi podatke

int max= dsKatalogDistribuiraneBaze.Tables[0].Rows.Count;

for (i=0; i<max; i++)

{ string StringKonekcijeIzKataloga = dsKatalogDistribuiraneBaze.Tables[0].Rows[i].ItemArray[2].ToString();

string TipBazePodataka = dsKatalogDistribuiraneBaze.Tables[0].Rows[i].ItemArray[1].ToString();

try

{

int brojSlogovaUspesnoSnimljeno = SnimiPodatke(StringKonekcijeIzKataloga, TipBazePodataka,

objAerodrom);


{

TekstStatusa = StringKonekcijeIzKataloga +"=U;";

}

else

{

TekstStatusa = StringKonekcijeIzKataloga +"=N;";

}

}


{

TekstStatusa = StringKonekcijeIzKataloga +"=G;"; //+ greska.Message;

}

}

Listing 14. Primena Kataloga

2. Korak - izostaviti jednu bazu podataka iz Kataloga i pokrenuti program. Podaci

neće biti snimljeni u tu bazu podataka.

3. Korak – ponovno pokretanje programa uz ponovno aktiviranje te baze podataka

nadoknađivanje podataka koji su izostali. Ovaj deo bi mogao biti realizovan na

sledeći način:

- Dodavanje Time stamp polja u strukturu svake tabele svih baza

podataka.

- Algoritam provere – izdvoji vrednost poslednjeg TimeStamp za

osnovnu bazu i uporedi sa poslednjim TimeStamp iz isključene

57

baze. Ako postoji razlika, ciklusom se svi zapisi koji ne postoje

(nemaju taj Time Stamp koji ima osnovna baza) ponovo unose iz

osnovne baze podataka.

5.5.2.8 Korišćenje web servisa za konsultovanje udaljene baze podataka

Projekat tipa web servisa je kreiran u VSNET framework 3.5.

Slika 12. Web Servis turističke destinacije

Ideja primene web servisa je pristup udaljenim bazama podataka. Turistička destinacija

nudi web servis kojim turističke agencije mogu da proveravaju raspoloživost soba, uz

mogućnost čak i da snimaju promene statusa zauzeća soba putem drugog web servisa

(ili druge metode istog web servisa).

U našem primeru kreiran je web servis koji treba da obezbedi podatke o zauzeću soba

koji bi se prikazivali u okviru web aplikacije turističke agencije, nakon izbora

destinacije - u tabelarnim prikazu (Slika 8). se prikazuju sobe od izabrane destinacije.

PIB Destinacije iz tabele Destinacija (Baza podataka turističke agencije) i PIB

destinacije iz tabele Soba (Baza podataka same turističke destinacije) se upoređuju i na

osnovu PIB destinacije se izdvajaju odgovarajuće sobe.

private DataSet DajDataSet(DataTable dt)

{

DataSet ds = new DataSet();

ds.Tables.Add(dt);

return ds;

}

private DataTable UcitajSve(string NazivKonekcije, string Upit)

{

DataTable TabelaPodataka = new DataTable();

// konekcija na bazu


SqlConnection(ConfigurationManager.ConnectionStrings[NazivKonekcije].ConnectionString);

Veza.Open();

// preuzimanje podataka

58

String strSQL;

strSQL = Upit;


SqlDataReader dr = Komanda.ExecuteReader();

if (dr.HasRows)

{

TabelaPodataka.Load(dr);

}

dr.Close();

Veza.Close();

Veza.Dispose();

return TabelaPodataka;

}

[WebMethod]

public DataSet DajDataSetSoba(string PIBDestinacije)

{

DataSet dsSoba = new DataSet();

dsSoba = DajDataSet (UcitajSve (“KonekcijaDestinacija”, “select Datum_zauzeta_od, D

Datum_zauzeta_do from zauzece_sobe inner join soba on zauzece_sobe.Id_sobe=soba.id where

soba.PIB=’” + PIBDestinacije + “’”));

return dsSoba;

}Listing 15. Kod za čitanje

5.5.2.8. Tabelarni prikaz objedinjenih podataka iz horizontalno particionisanih

baza podataka

private DataSet DajDataSet(DataTable dt)

{

DataSet ds = new DataSet();

ds.Tables.Add(dt);

return ds;

}

private DataTable UcitajSve(string NazivKonekcije)

{

DataTable TabelaPodataka = new DataTable();

// konekcija na bazu


SqlConnection(ConfigurationManager.ConnectionStrings[NazivKonekcije].ConnectionString);

Veza.Open();

// preuzimanje podataka

String strSQL;

strSQL = "Select * from Rezervacija";


SqlDataReader dr = Komanda.ExecuteReader();

// transformacija datareader u data table

// - ne mora, u web aplikaciji se moze povezati direktno

// grid sa data readerom, ali postoji problem zbog zatvaranja konekcije

// pa je bolje ipak da se podati postave u datatable, koji nije direktno povezan sa bazom

if (dr.HasRows)

{

TabelaPodataka.Load(dr);

}

dr.Close();

Veza.Close();

Veza.Dispose();

return TabelaPodataka;

59

}

private DataSet UcitajIntegrisanePodatke()

{

DataSet dsTASrbija = DajDataSet(UcitajSve("KonekcijaTuristickaAgencijaSrbija "));

DataSet dsTASvet = DajDataSet(UcitajSve("KonekcijaTuristickaAgencijaSvet "));

DataSet dsTASpojeno = SpojPodatke(dsTASrbija, dsTASvet);

return dsTASpojeno;

}

// integrisanje dva data seta

private System.Data.DataSet SpojPodatke(System.Data.DataSet ds1, System.Data.DataSet ds2)

{

System.Data.DataSet dsZajedno;

dsZajedno = ds1.Copy();

dsZajedno.Merge(ds2);

return dsZajedno;

}

// vezivanje data seta za grid

private void PrikaziPodatke(GridView gv, DataTable TabelaPodataka)

{

gv.DataSource = TabelaPodataka;

gv.DataBind();

}

private void PrikaziPodatke(GridView gv, DataSet ds)

{

gv.DataSource = ds.Tables[0];

gv.DataBind();

}

// dogadjaji

protected void Page_Load(object sender, EventArgs e)

{

if (!IsPostBack)

{

DataSet dsIntegrisano =UcitajIntegrisanePodatke();

PrikaziPodatke(gvSpisakRezervacija, dsIntegrisano);

}

}

protected void btnSvi_Click(object sender, EventArgs e)

{

txtFilter.Text = “”;

DataSet dsIntegrisano = UcitajIntegrisanePodatke();

PrikaziPodatke(gvSpisakRezervacija, dsIntegrisano);

}

Listing16 . Tabelarni prikaz horizontalnog particionisanja

5.5.2.9 Upiti nad više baza podataka

U ovom odeljku će biti demonstrirano kako se postavljaju upiti nad više različitih baza

podataka, koristeći DBMS MySQL.

Za prethodni primer urađen je drugi SQL script koji se odnosi na MySQL sintaksu.

CREATE DATABASE `TuristickaAgencija` CHARACTER SET utf8 COLLATE utf8_general_ci;

create table `TuristickaAgencija`.`TipDestinacije`

(

Id int NOT NULL AUTO_INCREMENT PRIMARY KEY,

Naziv varchar(50) NULL

60

);

create table `TuristickaAgencija`.`TipBoravka`(



);

create table `TuristickaAgencija`.`Drzava`(



);

create table `TuristickaAgencija`.`Mesto`(


Naziv varchar(50) NULL,

Id_Drzave int NULL

);

create table `TuristickaAgencija`.`Destinacija`(


PIB varchar(50) NULL,

Naziv varchar(50) NULL,

Id_Mesta int NULL,

Adresa varchar(50) NULL,

Email varchar(50) NULL,

Telefon nvarchar(50) NULL,

Id_Tipa_Destinacije int NULL

);

create table `TuristickaAgencija`.`Rezervacija`(


Prezime varchar(50) NULL,

Ime varchar(50) NULL,

Datum_Rodjenja date NULL,

Telefon varchar(50) NULL,

Adresa varchar(50) NULL,

Id_Mesta int NULL,

Id_Destinacije int NULL,

Datum_Boravka_Od date NULL,

Datum_Boravka_Do date NULL,

Id_Tip_Boravka int NULL,

Ukupna_Cena_Aranzmana decimal(18, 2) NULL

);

create table `TuristickaAgencija`.`Cenovnik`(


Kalendarska_godina int NULL,

Id_Destinacije int NULL,

Id_Tipa_Boravka int NULL,

Cena_Za_Dan decimal(18, 2) NULL

);

CREATE DATABASE `TuristickaDestinacija` CHARACTER SET utf8 COLLATE utf8_general_ci;

create table `TuristickaDestinacija`.`Soba`(


PIB varchar(50) NULL,

Oznaka varchar(50) NULL,

Opis nvarchar(50) NULL

);

create table `TuristickaDestinacija`.`ZauzeceSobe`(


Id_Sobe int NULL,

Datum_Zauzeta_Od date NULL,

Datum_Zauzeta_Do date NULL

);

Listing 17. MySQL sintaksa za kreiranje baza

61

Postavljen je upit kojim se povezuju 2 baze podataka:

select `TuristickaAgencija`.`Destinacija`.`Naziv`,`TuristickaDestinacija`.`Soba`.`Oznaka` from

`TuristickaAgencija`.`Destinacija` inner join `TuristickaDestinacija`.`Soba` on

`TuristickaAgencija`.`Destinacija`.`PIB` = `TuristickaDestinacija`.`Soba`.`PIB`

Listing 18. Upit za povezivanje dve baze podataka

Rezultat izvršavanja upita je dat na sledećoj slici.

Slika 13. Rezultat izvršenja upita

62

6. Zaključak

U ovom radu predmet istraživanja bio je predstavljanje različitih tehnologija koje se

koriste u radu sa distribuiranim bazama podataka. Cilj istraživanja je bio prikaz

elemenata tehnoloških rešenja koja se odnose na distribuirane baze podataka,

prvenstveno particionisanje, transakcije i oporavak baze podataka. Konkretni procesi su

ilustrovani praktično realizovanim primerom.

Osnovna hipoteza je bila da najčešće korišćeni sistemi za upravljanje bazama podataka

podržavaju tehnike rada sa distribuiranim bazama podataka. Hipoteza je dokazana za

najčešće korišćene DBMS – Oracle, MS SQL i MySQL kroz prikaz različitih tehnika

koje su u tim DBMS prisutne (replikacija, particionisanje, distribuirane transakcije i

oporavak baze podataka). Na ovaj način, kroz dokazivanje podhipoteza dokazana je i

glavna hipoteza. Ovaj deo je prikazan u okviru opisa stručno-istraživački rezultati

profesionalnih rešenja u oblasti najčešće korišćenih sistema za upravljanje bazama

podataka i podrške tehnikama rada sa distribuiranim bazama podataka.

Osim rezultata koji se odnose na dokazivanje hipoteze i podhipoteza, realizovan je

teorijski prikaz osnovnih koncepata i prikazani naučno-istraživački rezultati u oblasti

tehnika rada sa distribuiranim bazama podataka. Realizovan je primer softverske

aplikacije (web aplikacije) koja koristi raličite tehnike rada sa distribuiranim bazama

podataka uz prikaz tehnoloških elemenata prvenstveno replikacija, particionisanje,

transakcije i oporavak baze podataka.

Dalja istraživanja koja se odnose na distribuirane baze podataka mogla bi se odnositi na

druge tipove baza podataka (dakle baze podataka koje nisu zasnovane na relacionom

modelu), kao što su NoSQL baze podataka, document-orentisane baze podataka (npr.

Mongo) i slične.

Takođe, dalje bi se mogli izučavati i pojedinačni problemi koje se odnose na rad sa

distribuiranim bazama podataka, kao što je problem očuvanja referencijalnog integriteta

u fizički odvojenim bazama podataka koje imaju logičku vezu između tabela.

63

7. Literatura

1. Borivoje Milošević, Obrada podataka u disribuiranim bazama ,Visoka tehnička

škola strukovnih studija, Niš

2. http://www.link-university.com/lekcija/Distribuirane-arhitekture/5517

3. Borivoje Milošević, Distribuirane Transkcije, Visoka tehnička škola strukovnig

studija, Niš

4. https://www.codeproject.com/Articles/690136/All-About-TransactionScope

5. Branislav Lazarević, Zoran Marjanović, Nenad Aničić, Sladjan Babarogić, Baze

podataka, treće izdanje, Beograd,2006

6. Borivoje Milošević, Replikacija i fragmentacija podataka u distribuiranim bazama,

Visoka tehnička škola strukovnig studija, Niš

7. Milica Janačkov, Sinhronizacija podataka u distribuiranim bazama podataka:

ponovljeni podaci i lenjo ažuriranje-master rad, Beograd 2011

8. http://www.itcareersuccess.com/tech/database.htm

9. https://dev.mysql.com/doc/refman/8.0/en/replication.html

10. https://dev.mysql.com/doc/refman/8.0/en/partitioning-overview.html

11. https://dev.mysql.com/doc/refman/8.0/en/group-replication-basics.html

12. https://docs.microsoft.com/hr-hr/sql/relational-databases/replication/sql-server-

replication

13. https://technet.microsoft.com/en-us/library/ms178148(v=sql.105).aspx

14. http://www.link-university.com/lekcija/Upravljanje-transakcijama/4861

15. Zlatko Sirotić, Replikacija podataka u Oracle bazi, Istra informatički inženjering

d.o.o., Pula

16. Zlatko Sirotić, Transakcije i Oracle-baza,forms,Adf, Istra informatički inženjering

d.o.o., Pula

17. http://mariposa.cs.berkeley.edu/about.html

18. Michael Stonebraker, Paul M. Aoki, Witold Litwin, Avi Pfeffer, Adam Sah, Jeff

Sidell, Carl Staelin, Andrew Yu, Mariposa: a wide-area distributed database

system, The VLDB Journal (1996) 5: 48–63

19. https://en.wikipedia.org/wiki/Microsoft_Sync_Framework

http://www.link-university.com/lekcija/Distribuirane-arhitekture/5517

https://www.codeproject.com/Articles/690136/All-About-TransactionScope

http://www.itcareersuccess.com/tech/database.htm

https://dev.mysql.com/doc/refman/8.0/en/replication.html

https://dev.mysql.com/doc/refman/8.0/en/partitioning-overview.html

https://dev.mysql.com/doc/refman/8.0/en/group-replication-basics.html

https://docs.microsoft.com/hr-hr/sql/relational-databases/replication/sql-server-replication

https://docs.microsoft.com/hr-hr/sql/relational-databases/replication/sql-server-replication

https://technet.microsoft.com/en-us/library/ms178148(v=sql.105).aspx

http://www.link-university.com/lekcija/Upravljanje-transakcijama/4861

http://mariposa.cs.berkeley.edu/about.html

https://en.wikipedia.org/wiki/Microsoft_Sync_Framework

64

20. http://www.gimeko.edu.rs/wp-content/uploads/2011/12/SqlPriru%C4%8Dnik.pdf

21. https://bs.wikipedia.org/wiki/Microsoft_Visual_Studio

22. http://poslis.fon.rs/download/vezbe/PD%20Skripta.pdf

23. Corbett, J. C., Dean, J., Epstein, M., Fikes, A., Frost, C., Furman, J. J., Ghemawat,

S., Gubarev, A., Heiser,C., Hochschild, P., Hsieh, W., Kanthak, S., Kogan, E., Li,

H., Lloyd, A., Melnik, S., Mwaura, D., Nagle,D., Quinlan, S., Rao, R., Rolig, L.,

Saito, Y., Szymaniak, M., Taylor, C., Wang, R., Woodford, D.,Spanner: Google’s

globally distributed database, ACM Trans. Comput. Syst. 31, 3, August 2013

24. C. Mohan, B Lindsay, R. Obermarck, Transaction Menagment in the R* Distributed

Database Menagment System, ACM Transactions on Database Systems, Vol. 11,

No. 4, December 1966, Pages 373-396.

25. http://www.pmf.ni.ac.rs/pmf/licne_prezentacije/230/prezentacija/MySQL-2-1.pptx

26. http://www.link-elearning.com/lekcija-Kreiranje-rezervnih-kopija-i-restauracija-

baze_5942

27. http://sigurnost.zemris.fer.hr/ostalo/2009_vrbanic/Sigurnost_podataka_u_Oracle_ba

zi.pdf

28. John Miles Smith, Phili A. Bernstein, Umeshwar Dayal, Nathan Goodman, Terry

Landers, Ken W.T. Lin, Eugene Wong, Multibase-integrating heterogeneous

distributed database systems, National Computer Conference,1981

29. M. Tamer Ozsu, Patrick Valduriez, Distributed and Parallel Database Systems,

ACM Computing Surveys, Vol. 28, No. 1, March 1996

30. https://docs.oracle.com/cd/B28359_01/server.111/b32024/partition.htm#i468016

31. Materijali sa vežbi iz predmeta Distribuirani informacioni sistemi, Tehnički fakultet

“Mihajlo Pupin” Zrenjanin, http://www.tfzr.uns.ac.rs/Predmet/distribuirani-

informacioni-sistemi

http://www.gimeko.edu.rs/wp-content/uploads/2011/12/SqlPriru%C4%8Dnik.pdf

https://bs.wikipedia.org/wiki/Microsoft_Visual_Studio

http://poslis.fon.rs/download/vezbe/PD%20Skripta.pdf

http://www.pmf.ni.ac.rs/pmf/licne_prezentacije/230/prezentacija/MySQL-2-1.pptx

http://www.link-elearning.com/lekcija-Kreiranje-rezervnih-kopija-i-restauracija-baze_5942

http://www.link-elearning.com/lekcija-Kreiranje-rezervnih-kopija-i-restauracija-baze_5942

http://sigurnost.zemris.fer.hr/ostalo/2009_vrbanic/Sigurnost_podataka_u_Oracle_bazi.pdf

http://sigurnost.zemris.fer.hr/ostalo/2009_vrbanic/Sigurnost_podataka_u_Oracle_bazi.pdf

https://docs.oracle.com/cd/B28359_01/server.111/b32024/partition.htm#i468016

http://www.tfzr.uns.ac.rs/Predmet/distribuirani-informacioni-sistemi

http://www.tfzr.uns.ac.rs/Predmet/distribuirani-informacioni-sistemi

65

Prilozi protected void btnSnimi_Click(object sender, EventArgs e)

{

using (TransactionScope scope = new TransactionScope())

{

// snimanje u glavnu bazu podataka

try

{

brojslogovarezervacija = SnimiPodatke("KonekcijaTuristickaAgencija", txtId.Text, txtPrezime.Text,




{


}

else

{


}

}


{

porukauspeharezervacija = ex.Message.ToString();

}

// kopiranje u bekap bazu

try

{

brojslogovarezervacija = SnimiPodatke("KonekcijaTuristickaAgencijaBackup", txtId.Text,

txtPrezime.Text, txtIme.Text, txtDatumRodjenja.Text, txtTelefon.Text, txtAdresa.Text, ddlMesto1.Text,

ddlNazivDestinacije.Text, txtDatumBoravkaOd.Text, txt.DatumBoravkaDo.Text, ddlTipBoravka.Text);


{


}

else

{


}

}

// snimanje TuristickaAgencijaSrbija

// snimanje TuristickaAgencijaSvet

try

{

brojslogovasrbija = SnimiPodatke("KonekcijaTuristickaAgencijaSrbija", txtId.Text, txtPrezime.Text,



if (brojslogovasrbija > 0)

{

porukauspehasrbija = "Uspesno dodavanje novog!";

}

else

{

porukauspehasrbija= "Neuspeh dodavanja!";

}

}


{

porukauspehasrbija = ex.Message.ToString();

}

66

}

else

{

try

{

brojslogovasvet = SnimiPodatke("KonekcijaTuristickaAgencijaSvet", txtId.Text, txtPrezime.Text,



if (brojslogovasvet > 0)

{

porukauspehasvet = "Uspesno dodavanje novog!";

}

else

{

porukauspehasvet = "Neuspeh dodavanja!";

}

}


{

porukauspehasvet = ex.Message.ToString();

}

// snimanje TuristickaAgencijaLicniPodaci

// snimanje TuristickaAgencijaAranzman

try

{

int brojSlogovaUspesnoSnimljeno = SnimiPodatke("KonekcijaTuristickaAgencijaLicniPodaci",

"LicniPodaci", objRezervacija);


{

TekstStatusa = TekstStatusa + "KonekcijaTuristickaAgencijaLicniPodaci =U;";

}

else

{

TekstStatusa = TekstStatusa + "KonekcijaTuristickaAgencijaLicniPodaci =N;";

}

}


{

TekstStatusa = TekstStatusa + "KonekcijaTuristickaAgencijaLicniPodaci =G;"; //+ greska.Message;

}

// aranzman– odmah iza, oba se upisuju

try

{

int brojSlogovaUspesnoSnimljeno = SnimiPodatke("KonekcijaTuristickaAgencijaAranzman ",

"Aranzman", objRezervacija);


{

TekstStatusa = TekstStatusa + "KonekcijaTuristickaAgencijaAranzman =U;";

}

else

{

TekstStatusa = TekstStatusa + "KonekcijaTuristickaAgencijaAranzman;";

}

}


{

TekstStatusa = TekstStatusa + "KonekcijaTuristickaAgencijaAranzman =G=" + greska.Message;

}

scope.Complete();

} // zatvaranje transaction scope

} // zatvaranje procedure btnSnimi_Click

Prilog 1. Listing celog primera snimanja sa primenom transaction scope i svi blokovi

tehnologije distribuiranih baza podataka distributed ... rad mirko hrnjaz.pdf · distributed...

Documents