1. Razvoj sistemima za upravljanje podacima

Prvobitni DBMS su bili veliki, skupi softver koji se

izvršavao na velikim kompjuterima. Velièina je bila

neophodna, zbog skladištenja velike kol. podataka.

Danas, DBMS staje na PC, pa DBMS postaje uobièajeni

alat za kompjuterske aplikacije, kao ranije Word ili

Excel. S druge strane, GB nije više veliki kolièina

podataka. Baze preduzeæa (korporacija) skladište

terabajte Ipak ima mnogih baza koje èuvaju PB.

-Programsko upravljanje zapisima (1955-1970)

-On-line (hijerarhijske/mrežne) BP

-Relacione baze podataka

-Objektno-orijentisane baze podataka

(dopuna – I objektno-relacione baze podataka)

2. Šta je baza podataka ?

BP: zajednièki korišcena kolekcija logicki povezanih

podataka i opisa tih podataka, projektovana da

zadovolji informacione potrebe preduzeca.

BP: samo-opisna kolekcija integrisanih rekorda?

NEZAVISNOST programa od podataka. Definicija

podataka je razdvojena od aplikacionog programa i

èuva se u BP.

3. Šta je DBMS ?

DBMS je softverski sistem koji omoguæava

korisnicima da definišu, kreiraju, održavaju i kontrolišu

pristup BP. DBMS interaguje i sa aplikacionim

programom korisnika i sa BP.

4. Šta je ANSI/SPARC arhitektura ?

ANSI/x3/SPARC (Standards Planning and

Requirements Comittee) predložio (1975.) 3-nivovsku

arhitekturu sa sistemskim katalogom, koji omogucava

logicku i fizicku nezavisnost podataka.

• Eksterna/spoljna šema: opisuje deo BP

koji je relevantan za pojedinaènog korisnika

• Konceptualna šema: opisuje sve entitete, atribute,

njihove relacije, ogranièenja, informacije o sigurnosti i

integritetu.

• Fizièka šema: opisuje kako su podaci memorisani u

BP, alokacija memorijskog prostora za podatke I

indekse.

• Eksterno-konceptualno preslikavanje, omoguæava

logièku nezavisnost podataka.

• Konceptualno-interno preslikavanje, omoguæava

fizièku nezavisnost podataka.

• DBMS je odgovoran (održava) za

preslikavanje izmeðu ova tri nivoa.

5. Kategorije savremenih DBMS, podela i osnovne

karakteristike

• Relacioni sistem za upravljanje BP (RDBMS)

• Objektno orijentisani sistemi za upravljanje BP (OO

DBMS)

• Objektno-relacioni sistem za upravljanje BP (OR

DBMS)

Kategorizacija nije jednostavna, ovde je

diferencijacija izvršena na osnovu:

– Modela podataka

– Upitnog jezika

– Racunskog modela / navigacija pristupom

• Moguca alternativna klasifikacija modela

podataka pa time i DBMS:

– Modeli zasnovani na rekordima:

• Hijerarhijski

• Mrežni

• Relacioni

– Modeli zasnovani na objektima

Relacione baze podataka

• Standardizovan struktuirani upitni jezik –SQL

(neproceduralan: važan je rezultat, a ne objašnjava

naèin kako se do njega dolazi).

• Entiteti i relacije su prikazani na uniformni

nacin putem tabela.

• BP-tabele-rekordi (redovi) – atributi

(kolone)

• Svaka kolona ima tip podataka

• Relacije implicitne- spoljni kljuc

• Jedinstven jezik za definisanje podataka,

navigaciju i manipulaciju.

• 1970. Originalno razvijen od strane COD-a

• Programi znatno jednostavniji od navigacionih

• Pretraživanje podataka na osnovu vrednosti u polju

• Pregled rezultat upita se vrši pod kontrolom kursora

• Ogranicen broj podržanih tipova podataka

(boolean, string, number, date, currency).

Objektno relacioni sistemi za upravljanje BP

• Pokušaj ujedinjenja relacionih i objektnih BP:

proširene-relacione (ER) ili objektno-relacione (OR).

• Koristi model pod kojim tabelama BP dodaje

objektnu orijentisanost

• Ne postoji enkapsulacija procedura (metoda) sa

podacima, ogranièena podrška drugim OO svojstvima.

• Podržavaju prošireni oblik SQL-a (SQL-3)

– Ukljucuje: upite sa ugnježdenim obj., atribute sa

skupom vrednosti, ukljucivanje metoda u iskaze

pretraživanja, kao i upite koji ukljucuju ADT.

Objektno orijentisani sistem za upravljanje BP

Osnovne komponente ODMG arhitekture OODBMS:

– Objektni model OM

– Jezik za definisanje objekata ODL

– Jezik upita objekta OQL

– Veza sa programskim jezicima

• Ne postoji oficijelni standard za objekte BP, de-facto

standar je ODMG v.3.0 definisan od strane Object

Database Management Group. (ODBMG)

• Objektne BP koriste model podataka koji ima OO

koncepte: klasa, koja obezbeðuje OID (objekt

identifikator) za svaku peristentnu instancu klase,

enkapsulaciju, višestruko nasleðivanje, i podržava

ADT.

• Objektna BP proširuje funkcionalnost obj.

Programskih jezika (C++, Java, Smalltalk).

• OODBMS je baziran na šemi koja je definisana u ODL

• Objektno orijentisani jezik predstavlja jezik, kako za

aplikaciju, tako i za bazu podataka

• OODBMS je do sada integrisan sa C++, C, Smalltalk,

Javom, Lispom…

• ODMG-93 definiše i deklarativni jezik OQL za upit DB

objekata. OQL nije 100% kompatibilan sa SQL-om.

• Veæina obj. BP podržava i SQL putem ODBC-a.

• U okviru OODBMS primarni interfejs za kreiranje i

modifikovanje objekata je direktno putem objektnog

jezika, korišcenjem nativne sintakse jezika.

• Svakom objektu se automatski dodeljuje jedinstven

nepromenjiv identifikator (OID).

6. Prednosti i ogranicenja OODBMS

Prednosti:

– Moguænost predstavljanja kompleksnih objekata.

– Poveæana produktivnost programiranja

– Jedinstveni jezik podataka. Objektno-orijentisani

jezici su proceduralni jezici opštenamene, koji

poseduju i sintaksu zadefinisanje šema baze podataka.

– Potencijalno bolje performanse

• Evolucija šeme,

• Fleksibilnost,

• Ogranièenost ponašanja,

• snaga semantièke izdržljivosti,

• pogodnost za multimedijalne podatke

Ogranicenja objektno-orijentisanog DBMS-a

• Objektni model (strukturalno orijentisan) i nacin

ostvarivanja njegovih veza (direktno preko

pokazivaca) nije pogodan za realizaciju upitnih jezika.

• Kompleksnost OODBMS u odnosu na RDBMS ima

uticaja na komplikovanije korišcenje, kao I na cenu

• Ne postojanje adekvatnih mehanizama zaštite

• Nepostojanje standarda, iskustva

7. Funkcije DBMS

• Memorisanje, pretraživanje i ažuriranje podataka

(osnovna f-ja DBMS)

• Sistemski katalog dostupan korisniku

• Podrška transakcijama

• Upravljanje konkuretnim pristupom

• Servisi oporavka

• Servisi autorizacije

• Podrška komunikaciji

• Servisi integriteta

• Servisi za unapreðenje nezavisnosti podataka

• Uslužni servisi

• DBMS mora korisnicima omoguæiti da memorišu,

pretražuju i ažuriraju podatke u BP.

• DBMS mora obezbediti katalog dostupan korisniku

koji sadrži opise pojedinih podataka.

• DBMS mora posedovati mehanizam koji ce

obezbediti da ce se, ili sva ažuriranja koja odgovaraju

datoj transakciji izvesti ili se ni jedna od njih nece

sprovesti.

• DBMS mora posedovati mehanizam koji obezbeðuje

da se korektno ažuira BP.

• DBMS mora posedovati mehanizam za oporavak BP

u slucaju da je BP oštecena, bilo na koji nacin

• DBMS mora posedovati mehanizam koji obezbeðuje

da samo autorizovani korisnici mogu pristupati i

obavljati akcije nad BP.

• DBMS mora biti sposoban da se integriše sa

komunikacionim softverom.

• DBMS mora posedovati mehanizam koji obezbeðuje

da i podaci i njihove promene u BP poštuju odreðena

pravila.

• DBMS mora ukljuèiti sredstva za podršku

nezavisnosti programa od stvarne strukture BP.

• DBMS mora obezbediti skup uslužnih servisa.

8. Oracle DB server arhitektura

• Tri osnovne strukture u Oracle DB arhitekturi

servera:

– Memorijske strukture

– Procesne strukture

– Strukture za skladištenje (storage)

• Osnova Oracle DB (Server) sistema se sastoji od baze

podataka i instance.

• Baza podataka sastoji od fizicke i logicke strukture.

Pošto su fizièka i logièka strukture odvojene, fizickom

može da se upravlja bez uticaja na pristup logicke

strukture.

9. Instanca

• Instanca se sastoji od:

– Memorijskih procesa i

– Pozadinskih procesa povezanih sa instancom.

• Svaki put kad se pokrene Instanca, SGA se alocira i

pokrecu se pozadinski procesi.

• Proces je definisan kao mehanizam u OS koji može

da izvršava niz koraka.

• Nakon pokretanja instance, Oracle sw povezuje

instancu sa specificnom bazom, tzv. “mountovanje”

baze (MOUTINING).

• Baza je spremna za otvaranje, i mogu da joj pristupe

autorizovani korisnici.

Instanca: konfiguracija

• Svaka DB instanca je povezana sa 1 i SAMO JEDNOM

bazom;

• Ako ima više baza podataka na istom serveru, tada

postoji odvojene instance za svaku bazu.

• Instanca se ne može deliti

10. Oracle memorijske strukture baze podataka

• Da bi se pristupilo podacima u bazi instanca mora

biti pokrenuta, cime se dodeljuje podrucje zajednicke

memorije(SGA-System Global Area) i pokrecu

pozadinski procesi

• Dve osnovne memorijske strukture se u povezana sa

instancom:

– System Global Area (SGA).

– Program Global Area (PGA)

SGA

System Global Area (SGA): podruèje zajednièke

memorije sadrži podatke i kontroliše informacije za

jednu DB instancu. SGA dele serverski i pozadinski

procesa.

Primeri podataka sacuvanih u SGA ukljucuju keširane

blokove podataka i deljene SQL delove.

Kad se pokrene instanca (npr. iz SQl*Plusa) kolicina

memorije alocirana za SGA se prikazuje.

• Zajednièke (deljene) zalihe (engl. shared pool), koji

memoriše skoro korišæene SQL naredbe, kao i skoro

korišæene podatke iz reènika podataka,

• Keš bafera baze podataka (engl. data buffer cache),

• Keš bafera dnevnika izmena (engl. redo log cache),

• Velike zalihe, predstavlja opcionalno memorijsko

podruèje koje služi za smanjenje optereæenja kojem

je izložena zajednièka zaliha,

• Java zalihe, koja je opcionalna i nužna u sluèaju da

se koristi programski jezik Java.

Zajednièke (deljene) zalihe

• deo SGA sadrži: keš biblioteke naredbi, keš reènika,

keš rezultata SQL upita, keš rezultata PL/SQL fun.,

bafere za paralen izvršavanje poruka i kontrolnu

stukturu.

• Reènik podataka (Data dictionary) je skup DB tabela

i pogleda koji sadrže referentne informacije o bazi,

njene strukture i korisnike.

• Keš biblioteke naredbi koji memoriše skoro

korišæene SQL instrukcije, i koji se koristi od strane

serverskog procesa u procesu kompilacije SQLnaredbi,

• Keš reènika podataka koji memorišeskoro korišæene

definicije u bazi podataka, i koji se koristi od strane

serverskog procesa u cilju razrešenja imena objekata

koji su specificirani u SQL naredbama.

Keš bafera

• Deo SGA

• Sadrži delove blokova podataka koji se èitaju iz

fajlova podataka

• Deljen je od svih konkurentih korisnika

• Keš bafera baze koristi se za memorisanje skoro

korišæenih podataka. Ovi podaci se èitaju iz, i upisuju

u fajlove podataka (u BP).

• Serverski proces traži potrebne blokove podataka u

sklopu ovog bafera, pa tek za sluèaj negativnog

rezultata, traženi blok se uèitava iz data fajla baze. Na

taj naèin se popravljaju performanse sistema. Broj i

velièina ovih bafera odreðeni su konfiguracionim

parametrima.

Keš bafera dnevnika

Keš bafera dnevnika izmena koristi se za pracenje

promena koje u bazi podataka, posredstvom instance,

izvedu serverski i pozadinski procesi. Navedena

informacijase koristi u sluèaju potrebe oporavka baze

podataka.

Velike zalihe (Large pool)

• Velike zalihe (Large pool): obezbeðuje veliku

alokaciju memorije za:

– Memoriju sesije za shared server

– I/O serverske procese

– Oracle DB backup i operacije oporavka.

Java zalihe- memorija se koristi za cuvanje svih

specificnog Java koda sesije i podataka u JVM.

PGA

je privatni deo memorije koji sadrži podatke i

kontrolne informacije za serveske procese.

Svaki serverski proces ima poseban PGA. Pristup PGA

je ekskluzivan tom serverskom procesu, i PGA èita i

upisuje samo Oracle-ov kod koji deluje u njeno ime.

PGA je podeljen u dve glavna dela: stack prostor i UGA

(Userglobal area).

• PGA: Memorijski regioni koji sadrže podatke I

kontrolne informacije za serverske ili pozadinske

proces.

• PGA NIJE DELJENA memorija koju kreira Oracle DB

kada server ili pozadinski proces pocinje.

• Oracle serverski proces servisira klijentske zahteve.

11. Arhitektura procesa kod Oracle-a; detaljnije DB

procesi

• Procesi u Oracle bazi mogu biti podeljeni u tri glavne

grupe:

1. Korisnicki procesi: aplikacija ili alati koja povezuje

na Oracle DB

2. DB procesi:

– Serverski procesi: Povezuje se na Oracle instanu i

uspostavlja se kada korisnik uspostavi sesiju.

– Pozadinski procesi: pokreæu se kada se pokrene

Oracle instanca

3. Deamon/procesi aplikacije, npr. Networking

listeners

DB procesi, koji za korisnika obavljaju razlièite funkcije

mogu se podeliti u dve grupe:

– serverske procese (koji upravljaju zahtevima koji

dolaze od konektovanih korisnièkih procesa) i

– pozadinske procese (koji obavljaju asinhroni I/O i

omogucavaju veci paralelizam pa time I bolje

performanse).

Pozadinski procesi mogu biti obavezni i

opcionalni.

Pozadinski procesi (Oracle 11g)

– Database writer process (DBWn)

– Log writer process (LGWR)

– Checkpoint process (CKPT)

– System monitor proces (SMON)

– Process monitor process (PMON)

– Recovery process (RECO)

– Job queue coordinator (CJQ0)

– Job slave processes(Jnnn)

– Archiver processes (ARCn)

– Queue monitor processes (QMNn)

• DBWR proces ima zadatak da modifikovane blokove

podataka iz SGA bafer keša upiše u fajlove podataka

na disku. DBWR omoguæava odlaganje upisivanja

promena na disk do pojave specificiranih uslova èime

se unapreðuju performanse.

• LGWR proces ima zadatak da prepisuje podatke iz

SGA redo log bafera u aktivni redo log fajl na disku.

• Ova operacija se obavlja sekvencijalno, za sluèaj

pojave specificiranih uslova (posle commita

transakcije, itd.).

• CKPT proces ima zadatak da ažurira informaciju o

statusu baze podataka u kontrolnim i data fajlovima

svaki put kada se promene u keš baferima

permanentno registruju u fajlovima baze podataka, tj.

CKPT proces se koristi za sinhronizaciju fajlova baze

podataka.

• Zapisuje checkpoint informacije u:

– Kontrolni fajl

– Svaki data file heder

• SMON proces ima zadatak da proverava

konsistentnost baze podataka, i u slucaju potrebe

inicira oporavak baze.

• U suštini SMON proces vrši automatski oporavak

instance u sluèaju njenog kvara.

• PMON proces ima zadatak da prati korisnicke

procese koji pristupaju bazi podataka i da ih oporavlja

posle eventualnog “pada”.

Proces oporavka

• Koristi se sa distribuiranom konfiguracijom baze

• Automatski se povezuje na druge baze ukljucene u

sumljive distribuiranu transakciju

• Automatski “rastura” sve sumljive transkacije.

• Uklanja sve redove koji odgovaraju sumljivim

transakcijama.

12. Logicka i fizicka struktura podataka

DB je logièki podeljena u 2 ili više prostor za tabele.

Jedan ili više fajlova su eksplicitno kreirani za svaki

prostor za tabele da fizièko saèuvaju podatke svih

segmenata u prostor za tabele.

• Prostor za tabele (tablespace): DB je podeljena

u logièke jedinice skladištenja – TABLESPACE,

koje grupišu povezane logièke strukture ili

fajlove podataka zajedno.

• Blokovi podatka: na najfinijem nivou

granularnosti, Oracleova DB podaci se èuvaju u

blokovima podataka.

• Ekstenti- Ekstent je specifièan broj kontinuiranih

Oracle db blokova (dobijenih u jednoj alokaciji) koji se

koriste da sacuvaju specificni tip informacije.

• Segmenti- Segment je skup ekstenata alociran za

odreðenu logicku sturkturu

13. Komande SQL-a – podela

• Jezik za definisanje podataka (engl. Data

Definition Language, DDL)

• Jezik za manipulaciju podacima (engl.

Data Manipulation Language, DML)

• Naredbe za kontrolu

• DDL komande imaju momentalni efekat na bazu

podataka (tj. Oracle implicitno izvršava COMMIT i

informacije se momentalno upisuju u recnik

podataka).

Jezik za manipulaciju podacima (DML)

• Jezik za manipulaciju podacima je podskup SQL

komandi za prikazivanje (SELECT), unošenje (INSERT),

ažuriranje (UPDATE) i brisanje podataka (DELETE),

ispitivanje plana izvršavanja upita (EXPLAIN PLAN) i

zakljuèavanje tabela (LOCK TABLE);

• Naredbe za kontrolu:

– transakcija, kojima se omoguæava startovanje,

završavanje i postavljanje parametara transakcije;

– sesije, kojima se dinamièki menjaju karakteristike

sesije korisnika;

– sistema, kojima se dinamièki upravlja

karakteristikama Oracleove instance.

14. Šema baze podataka

- sastoji se od objekata šeme, logièkih sruktura baze

podataka, kao što su: tabele, pogledi, sekvence,

sinonimi, indeksi, klasteri, linkovi baze podataka,

procedure, funkcije i paketi.

• Objekti šeme se logicki cuvaju u prostoru za tabele

(tablespace) baze podataka, pri cemu se objekti jedne

šeme mogu nalaziti u više prostora za tabele, a jedan

prostor za tabele može da ima više objekata šeme.

• Podaci svakog objekta se fizièki èuvaju u jednom ili

više fajlova na disku. Prilikom kreiranja tabele može se

specificirati koliko ce Oracle alocirati prostora nadisku.

16. Transakcija (naredbe)

Naredbe za kontrolu transakcija omoguæavaju

startovanje, završavanje i postavljanje parametara

transakcije: COMMIT, ROLLBACK, SAVEPOINT i SET

TRANSACTION

Osobine transakcija

• Osnovne osobine transakcije su sledece:

– nedeljivost (engl. atomicity), transakcija se izvršava

u potpunosti (tj. kao celina), ili se ne izvršava ni jedan

njen deo;

– konsistentnost (engl. consistency), pomoæu

transakcije baza se prevodi iz jednog u drugo

ispravno (konsistentno) stanje;

– izolacija (engl. isolation), rezultat transakcije vidljiv

je ostalim korisnicima tek kada se transakcija potvrdi;

– postojanost (engl. durability), kad se transakcija

potvrdi, njen ucinak je trajan.

Transakcija zapoèinje prvom naredbom DDL-a ili DML-

a, a može se završiti:

– eksplicitnim naredbama COMMIT ili ROLLBACK (kod

DML-a),

– izlaskom iz SQL*Plusa (implicitni COMMIT),

– uspešnom DDL naredbom (im-pli-citni COMMIT),

– padom sistema (implicitni ROLLBACK)

17. Recnik podataka

• Svaki DBMS ima reènik podataka (Data dictionary)

u kome su smešteni metapodaci, tj. podaci o strukturi

baze podataka (tabelama, ogranièenjima, korisnicima)

• Cesto se reènik podataka naziva metabaza podataka

• Sastoji se od tabela i pogleda

• Recnik podataka sadrži: definicije svih objekata

šeme u bazi podataka, informacije o ogranièenjima

integriteta, imena Oracleovih korisnika, njihove

privilegije i role.

Postoje tri prefiksa pogleda reènika podataka:

– USER_ za sopstvene objekte korisnika,

– ALL_ za sve objekte kojima korisnik može da

pristupi (sopstveni objekti i drugi objekti za koje

korisnik ima privilegije),

– DBA_ za sve objekte u bazi.

18. Izvršavanje transakcija

• n aktivnih transakcija

• Način izvršavanja:

– Serijski (prvo se kompletno izvrši 1 transakcija, pa

druga transakcija…)

– Konkurentno (Neserijski): pre kompletnog

izvršavanja I transakcije, krene druga…

Prekidi u izvršavanju transakcije

• U toku izvršavanja transakcije može dodi

do kvara računarskog sistema zbog:

– Otkazivanja hardverskih/softverskih delova

računarskog sistema

– Prestanka napajanja

– Ljudskih grešaka

– Elementarnih nepogoda.

Nedeljivost: ako se transakcija prekine između 3 i 6 koraka, system mora da obezbedi da ažuriranja nisu upisana u bazu, jer de baza predi u nekozistentno stanje. Nezavisnost: ako se između koraka 3 i 6 dozovli drugoj transakciji pristup delimično ažuriranoj bazi, ona de videti nekozistentnu bazu (A+B <50) Trajna: posle obaveštenja da je transakcija izvršena, baza mora zadržati stanje uprkos mogudim kvarovima. 19. Mehanizam za upravljanje transakcijama • Integralni deo savremenih DBMS je i mehanizam za upravljanje transakcijama. • Mehanizam za Upravljanje transakcijama omogudava da rezultati konkurentnog izvršavanja transakcija budu ekvivalentni rezultatima njihovog serijskog izvršavanja.

20. Transakcija (osobine) Transakcija je izvršenje programa koji predstavlja neku interakciju u realnom okruženju i obezbeđuje očuvanje konzistentnosti baze podataka, kojom je okruženje modelirano. Osnovne osobine transakcije su sledede: 1. nedeljivost (engl. atomicity), “sve ili ništa” transakcija se izvršava u potpunosti (tj. kao celina), ili se ne izvršava ni jedan njen deo; osiguranje nedeljivosti je odgovornost DBMS podsistema za oporavak. 2. konzistentnost (engl. consistency), pomodu transakcije baza se prevodi iz jednog u drugo ispravno (konsistentno) stanje; očuvanje konzistentnosti – poštovanja svih ograničenja integriteta. 3. izolacija (engl. isolation), rezultat transakcije vidljiv je ostalim korisnicima tek kada se transakcija potvrdi; - zadatak DBMS podsistema za kontrolu konkurentno pristupa 4. postojanost (engl. durability), kad se transakcija potvrdi, njen učinak je trajan; - zadatka DBMS podsistem za oporavak 21. Deo DBMS koji upravlja konkurentnim pristupom Raspodeljivač (Scheduler) je modul koji je odgovoran za izvršavanje određene strategije za kontrolu konkurentnog pristupa. Zadatak Scheduler-a je da max konkurentnost pristupa, a da transakcije ne smetaju jedna drugoj (da se ugrozi integritet i konzistentnost baze). 22. Serijalizovano izvršavanje Uporedo izvršavanje skupa transakcija je serijalizovano (linearno) ako proizvodi isti rezultat kao i neko serijsko izvršenje istog skupa transakcija. 23. Problemi kod konkurentnih (neupravljanih) transakcija Prljavo čitanje se javlja kada je transakcijama dozvoljeno da vide i koriste rezultate drugih transakcija pre nego što se one potvrde (COMMIT). Neponovljivo čitanje Kad transakcija pročita nekoliko vrednosti iz baze podataka, ali druga transakcija ažurira neke od tih vrednosti, za vreme izvršavanja prve transakcije. Fantomski redovi - Prva transakcija pročita željene vrednosti iz BP, a druga istovremeno ubacuje nove redove u BP, na mestu gde su smešteni podaci prethodno pročitani od strane prve transakcije. Izgubljeno ažuriranje - kada jedan korisnik naizgled uspešno izvrši operaciju ažuriranja, dok drugi korisnik preko tog ažuriranog podatka prepiše sopstveni rezultat.

25. Serijalizovanost (konfliktna i view) serijalizovanost- glavni kriterijum ispravnosti konkurentnog izvršavanja transakcija. Neki neserijski redosled je serijalizovan ako je ekvivalentan serijskom redosledu. Dve vrste ekivalentnosti redosleda, tj. serijalizovanosti: – “conflict” serijalizovanost – “view” serijalizovanost Konfliktna Serijalizovanost Konflikt-serijalizovanost situacija u kojoj izmena redosleda dve operacije u izvršenju dovodi do izmene efekata na bazu barem jedne od transakcija iz posmatranog izvršenja. • Ako se redosled S može transformisati u redosled S’ promenom redosleda nekonfliktnih instrukcija, kažemo da su redosledi S i S’ konfliktno ekvivalentni. • Redosled S je konfliktno serijalizovan ako je konfliktno ekvivalentan serijskom redosledu. VIEW Serijalizovanost • S i S’ dva redosleda sa istim skupom transakcija. S I S’ su view ekvivalentni ako važe slededa tri uslova: – Za svaki podatak Q, ako transakcija Ti čita početnu vrednost Q u redosledu S, tada transakcija Ti mora u redosledu S’, takođe čitati početnu vrednost Q. – Za svaki podatak Q, ako transakcija Ti izvršava read(Q) u redosledu S, a tu vrednost je upisala transakcija Tj, tada transakcija Ti mora i u redosledu S’ takođe čitati vrednost Q koju je upisala transakcija Tj. – Za svaki podataka Q, transakcija koja poslednja izvršava write (Q) u redosledu S mora poslednja izvršavati write(Q) i u redosledu S’. 26. Tehnike konkuretnog pristupa • Pesimističke (konzervativne): – Metoda zaključavanja (– Metoda vremenskog markiranja • Optimistički metodi (do konflikta dolazi retko, pa se transakcije izvršavaju bez sinhronizacije, i tek na kraju transakcije provera da li je došlo do greške il konflikta) Transakcija zaključa (postavi lokot) na objekat baze podataka da bi onemogudila da druga transakcija nekorektno operiše sa istim objektom) • Ekskluzivno (exclusive X ili write lock): ako neka transakcija postavi ekskluzivni lokot na objekat baze podataka, nijedna druga transakcija ne može na taj objekat da postavi bilo koji drugi lokot. • Deljivo zaključavanje (shared (S) lock ili read lock) Ako T1 postavi deljivi lokot na objekat baze podataka, T2 može da postavi deljivi lokot na isti objekat, ali nijedna druga transakcija ne može da postavi X lokot na taj objekat. 27. Mrtvi čvor – predavanje 5, strana 53

28. Dvofazni protokol zaključavanja – Pre nego što operiše sa nekim objektom baze podataka, transakcija mora da postavi lokot na njega. – Posle oslobađanja nekog lokota, transakcija ne može da postaviti lokot ni na jedan objekat baze podataka. • TEOREMA: Ako u nekom skupu sve transakcije poštuju dvofazni protokol zaključavanja, taj skup se uvek serijalizovano izvršava. 29. Vremensko označavanje Transakcije se označavaju da bi se na osnovu dobijene oznake uređivao redosled njihovog izvršavanja. • Svakoj transakciji – UID • Fizička ažuriranja sa COMMIT naredbom. • Svakom objektu baze podataka se pridružuju dve oznake: – RMAX najvedi identifikator transakcije koja je uspešno izvršila čitanje posmatranog objekta – UMAX, najvedi identifikator transakcije koja je uspešno izvršila ažuriranje posmatranog objekta. • Integritet je očuvan, nema lokota • Tehnika vremenskog označavanja dovodi do toga da se veliki broj transakcija poništava i ponovo startuje. • Sva ažuriranja neke transakcije obavljaju zajedno sa naredbom COMMIT u toj transakciji zahteva da se upisivanja transakcija baferuju u neku memoriju I prenesu u bazu tek sa COMMIT. 30. Pesimističko i optimističko zaključavanje Pesimističko zaključavanje • Veruje se da postoji velika verovatnoda da neko izmeni iste one podatke koje upravo čitamo. Pošto demo možda ažurirati podatke zaključademo red u bazi podataka, sprečavajudi da druge sesije ažuriraju isti red. • PESIMISTIČKI jer verujemo da postoji velika šansa ako izmenimo podatke u datom redu da de neko drugi da uradi događaj. • Zaključavamo podatak pre nego što pokušamo da ga Izmenimo Prednosti pesmističkog zaključavanja • Korisnik ima poverenja u podatke na ekranu. • Mogude je postaviti vremensko ograničenje za neaktivne sesije; npr. Neko zaključa podatke i napusti radno mesto. OPTIMISTIČKO ZAKLJUČAVANJE. • Čuva staru i novu vrednost u aplikaciji • Prilikom vršenja izmene podataka, koristimo ažuriranje koje postavlja kolone na nove vrednosti, u isto vreme proveravajudi da li red u bazi podataka ima istu vrednost kao prilikom prvog čitanja. • PRETPOSTAVKA da podatak nije izmenjen

Pesimističko vs optimističko • Prednost pesimističkog što korisnik otkriva na vreme da ne može da se izvrši izmena. • Zaključavanjem reda drugi korisnici bide sprečeni da uđu u taj red. • Zaključavanje reda ne ometa čitanje tog reda. 31. Distribuirana baza podataka Distribuirana baza podataka (distributed database, DDB) je logički povezan skup deljenih podatka (i opisa tih podataka) fizički distribuiranih preko računarske mreže. Distribuirani DBMS je softver koji upravlja DDB i omogudava da distribucija bude transparentna za korisnika. DDBMS se sastoji od jedne logičke DB koja je podeljena na fragmente. • Svaki fragment se nalazi na jednom ili vise kompjutera pod kontrolom odvojenog DBMSa, sa kompjuterima povezanim preko mreže. • Korisnici pristupaju distribuiranim bazama preko aplikacije, koje mogu biti: – Lokalne (ne zahtevaju podatke sa drugih lokacija) – Globalne (zahtevaju podatke sa drugih lokacija) • DDBMS ima bar jednu globalnu aplikaciju 32. Distribuirani DBMS, osnovne karakteristike • Skup logički povezanih deljenih podataka • Podaci su razdvojeni u brojne fragmente • Fragmenti mogu biti replicirani • Fragmenti/replike su alocirani na različite lokacije • Lokacije su povezane pomodu računarske mreže • Podaci na svakoj lokaciji su pod kontrolom DBMSa • DBMS na svakoj lokaciji može autonomno obavljati lokalne aplikacije • Svaki DBMS učestvuje bar u jednoj globalnoj aplikaciji. 33. Prednosti i mane distribuiranih DBMS (DDBMS) Prednosti DDBMS • Odražava organizacionu strukturu (mnoge organizacije su distribuirane preko nekoliko lokacija). • Poboljšana deljivostivost podataka, kao i lokalna autonomija • Poboljšana dostupnost • Poboljšana pouzdanost • Poboljšane performanse • Ekonomičnost • Modularni rast Mane DDBMS • Kompleksnost • Cena (povedana za održavanje) • Bezbednost • Teža kontrola integriteta

• Nedostatak standarda • Nedostatak iskustva • Dizajn baze podataka je mnogo kompleksniji 34. Funkcionalnosti DDBMS DDBMS pored funkcionalnosti centralizovane DBMS, DDBMS bi trebao da ima sledede funkcionalnosti: – Proširene servise komunikacije da obezbedi pristup udaljenim lokacijama i omogudi transfer upitima I podacima među lokacijama korišdenjem mreže. – Proširenje sistemskog kataloga da bi se sačuvali detalji distribucije podataka. – Distribuirana obrada upita, uključujudi optimizaciju upita I udaljeni pristup podacima. – Proširenu kontrolu bezbednosti da se održe odgovarajudi autorizovani/pristup privilegijama distribuiranih podataka. – Proširenje kontrole konkurentnosti da se održi konzistentnost repliciranih podataka. – Proširenje servisa oporavka da bi se obezbedili ispadi individualnih sajtova i ispadi komunikacionih linkova. 35. Arhitektura DDBMS Arhitektura DDBMS sastoji se od: •Skup globalnih eksternih šema •Globalnih konceptualnih šema •Šema fragmentacije I alokacija •Skupa šema za svaki lokalni DBMS prema ANSISPARC arhitekturi. • Globalna šema je logički opis cele baze, kao da nije distribuirana (konceptualan nivo u ANSI-SPARC arhitekturi, i sadrži definicije entiteta, relacija, ograničenja, bezbednosti i integriteta informacija). – Obezbeđuje fizičku nezavisnost od distribuiranog okruženja. – Obezbeđuje logičku nezavisnost podataka. • Šema fragmentacije je opis kako da podaci se logički particioniraju. • Šema alokacije je opis je gde de podaci biti locirani (vodedi računa o svakoj replikaciji). • Lokalne šeme: svaki lokalni DBMS ima svoj skup šema: lokalne konceptualne i interne šeme odgovaraju ekvivalentnim nivoima ANSISPARC arhitekture. 36. Multidatabase systme (MDBS) Multidatabase systems: je distribuirani DBMS kod koga je na svakom sajtu obezbeđena kompletna autonomija. • MDBMS se nalazi transparentno na vrhu postojede baze i fajl sistema, I korisnik vidi jednu bazu. • Održava globalnu šemu preko koje korisnici izvršavaju upite i ažuriranja;

MDBS održava samo globalne šeme a lokalni DBMS održavaju sve korisničke podatke. • MDBS omogudava korisnicima pristup i deljenje informacija bez zahtevanja pune integracije DB šeme. Ipak, omogudavaju korisnicima administriranje sopstvene baze bez centralizovane kontrole (kao kod prave DDBMS). • DBA lokalne DBMS može autorizovati pristup određenom delu njegove/njene baze specifikovanjem eksportne šeme, što definiše deo baze kojoj mogu da pristupaju ne-lokani korisnici. 37. Komponente DDBMS Četiri osnovne komponente arhitekture: – Lokalne DBMS komponente (LDBMS): standardan DBMS odgovoran za kontrolu lokalnih podatka na svakoj lokaciji koja ima bazu podataka. – Komponente komunikacije podataka (DC): softver koji omogudava komunikaciju među lokacijama. – Globalni sistem katalog (GSC): sadrži informacije specifične za distribuirani sistem (fragmentacija, alokacija i replikacija). – Distribuirane DBMS komponente (DDBMS):-kontrolna jedinica celog sistema. 38. Distribuirani relacioni dizajn baze (detaljnije fragmentacija, alokacija I replikacija) Relacija može biti podeljena u brojne podrelacija (fragmente), koji su alocirani na jednu ili vise lokacija. Fragmenti se repliciraju da bi poboljšali dostupnosti i performanse. • Dizajn de se bazirati na kvantitativnim (alokaciju) i kvalitativnim informacijama (fragmentaciju) – Kvantitativne informacije mogu da obuhvate: frekvencu sa kojoj transakcija radi, lokaciju sa koje transakcija se izvršava, kriterijum performanse za transakciju. Tri pravila korektne fragmentacije su: – kompletnost, – rekonstrukcija i – disjunktivnost (min. redudantnost podataka) Četiri tipa fragmentacije: – Horizontalna – Vertikalna – Mešovita – Izvedena (Derived) – Kvalitativne informacije (relacije, atribute i torke kojima se pristupa), tip pristupa (pisanje/čitanje), predikate operacija čitanja. Replikacija • Proces generisanja i reprodukovanja vise kopija podataka na jednu ili više lokacija. • ASIMETRIČNA REPLIKACIJA: Master site

može da sadrži celokupnu relaciju, dok ostale lokacije imaju samo read-only kopiju fragmenata . 39. Transparentnost kod DDBMS (podela, detaljnije) Transparentnost sakriva detalje implementacije za korisnika. U centralizovanom DBMS nezavisnost podataka je forma transparentnosti – sakriva promene u definiciji i organizaciji podataka od korisnika. Postoje razni nivoi transparentnosti. Glavna ideja: napraviti korišdenje distribuirane baze podataka ekvivalentno centralizovanoj bazi podataka. Četiri glavan tipa transparentnosti u DDBMS: 1. Transparentnost distribucije 2. Transparentnost transakcije 3. Transparentnost performansi 4. DBMS transparentnost Retko se svi tipovi transparentnosti nalaze u 1 sistemu. 1.Transparentnost distribucije • Transparentnost distribucije omogudava da korisnik vidi bazu kao jedan, logički entitet. Ako DDBMS ispunjava transparentnost distribucije, onda korisnik ne treba da zna da su podaci fragmentovani (transparentnost fragmentacije) ili lokaciju samih podataka (transparentnost lokacije). • Ako je potrebno da korisnik zna da su podaci fragmentovani i lokacije fragmenata onda se zove transparetnost lokalnog mapiranja . • 1.1 Transparentnost fragmentacije • 1.2. Transparentnost lokacije • 1.3. Transparentnost replikacije • 1.4. Transparentnost lokalnog mapiranja • 1.5. Transparentnost imenovanja 2. Transparentnost transakcije Obezbeđuje da sve distribuirane transakcije održavaju integritet i konzistentnost distribuirane baze. Distribuirane transakcije pristupaju podacima na više od jedne lokacije. Svaka od transakcija je podeljena u brojne podtransakcije, jedna za svaku lokaciju kojoj mora da se pristupi. DDBMS mora da obezbedi nevidljivost globalnih transakcija i svake od podtransakcija. 3. Transparentnost performanse • DDBMS mora da izgleda kao da je centralizovana DBMS – DDBMS ne bi trebalo da ima degradaciju performansi s obzirom na distribuiranu arhitekturu. – DDBMS treba da odredi najefikasniju strategiju da izvrši zahtev.

• Distribuirani procesor upita (DQP – Distribute Query Processor) mapira zahteve podataka u uređene sekvence operacija u lokalnoj bazi. • Mora se uzeti u obzir šeme fragmentacije, replikacije I alokacije. • DQP treba da odluči: – Kojem fragmentu da pristupi – Koju kopiju fragmenta da koristi – Koju lokaciju da koristi. 4. DBMS transparentnost • DBMS transparentnost sakriva da lokalne DBMS mogu biti različite, i prema tome je samo primenljivo na heterogene DDBMS. • Ovo je jedna od najtežih transparentnosti za ostvarivanje. Sa korisničke tačke gledišta, kompletna transparentnost je krajnje poželjna. S stanovišta lokalnog DBA potpuna transparentnost je komplikovana za kontrolu, npr. Sigurnost. Sa korisničke tačke gledišta, kompletna transparentnost je krajnje poželjna. S stanovišta lokalnog DBA potpuna transparentnost je komplikovana za kontrolu, npr. sigurnost. 40. Upravljanje distribuiranom transakcijom • Distribuirana transakcija pristupa podacima koje se nalaze na više od 1 lokacije. • Podeljene u brojne podtransakcije, svaki za 1 sajt kojoj treba da se pristupi • Nedeljivost distribuirane transakcije je dalje fundamentalna za koncept transakcija. • DDBMS takođe mora da obezbedi nedeljivost svake pod-transakcije. • DDBMS mora da obezbedi: – Sinhronizaciju podtransakcija sa lokalnim transakcijama koje se izvršavaju konkurentno na lokaciji. – Sinhronizaciju podtransakcija sa globalnim transakcijama koje se izvršravaju simultano na istom ili različitim sajtovima. – Globalni menadžer transakcija (coordinator transakcija) na svakom sajtu, da kooridinira globalne i lokalne transakcije inicirane na tom sajtu. 41. DBMS podsistem transakcija Menadžer transakcija kordinira transakcije u ime aplikativnih programa SCHEDULER: modul odgovoran za implementiranje određene strategije za kontrolu konkurentnosti; Recovery manager- vrada bazu u prethodno konzistentno stanje, ako dođe do neuspeha tokom transakcije. Buffer manager- odgovoran za efikasan transfer podataka između diska i gl. Memorije.

U DDBMS, ovakav modul postoji na svakom lokalnom DBMSu. Pored toga postoji KORDINATOR TRANSAKCIJA (ili globalni menadžer transakcija) na svakoj lokaciji da koordiniše izvršavanje i globalnih i lokalnih transakcija na tom sajtu. 42. Koordinacija distribuiranih transakcija Procedura izvršavanja globalne transakcije inicira na lokaciji S1 : – Koordinator transakcija TC1 na sajtu S1 deli transakciju u podtransakcije korišdenjem informacija sadržanih u katalogu globalnog sistema. – Komponente komunikacije na sajtu S1 šalju podtransakcije odgovarajudim sajtovima S2 i S3. – Kordinatori transakcijama na lokacijma S2 i S3 upravjaju ovim podtransakcijama. Rezultati podtransakcija se vradaju do TC1 preko komponenti komunikacije podataka.

43. Kontrola distribuirane konkurentnosti • Pored problema neupravljanih transakcija kod centralizovanog DBMS, kod DDBMS postoje dodatni problemi kao: multiple-copy problem konzistentnosti, koji se dešava kad su podaci replicirani na različitim lokacijama. • Da bi se održala konzistentnost globalne baze, kada su replicirani podaci ažurirani na jednom sajtu sve druge kopije podatka moraju takođe da budu ažurirane. Ako kopije se ne ažuriraju, baza postaje nekonzistentna. Distribuirana serijalizovanost • Koncept serijalizovanosti može se proširiti na distribuirano okruženje. • Ako raspored izvršavanja transakcija na svakom sajtu je serijalizovan, onda globalni schedule (unija svih lokalinih schedule) je takođe serijalizovan. • Ovo zahteva da sve podtransakcije se pojavljuju istim redosledom u ekvivalentnom serijskom rasporedu na svim sajtovima. 44. 2PC (two-phase commit) • 2PC (two-phase commit) protokol obuhvata faze glasanja i odluke, gde koordinator pita sve učesnike da li su spremni za COMMIT. • Ako jedna učesnik glasa za poništavanje (abort), globalna transakcija i sve podtransakcije moraju se

poništiti. Jedino ako svi učesnici glasaju za COMMIT, globalna transakcija se izvršava (COMMIT) • 2PC protokol može ostavi lokacije blokirane u slučaju otkaza. • Protokol pretpostavlja da svaka lokacija ima sopstveni log, i da prema tome može da uradi rollback ili commit transakcije. • 2PC uključuje čekanje za poruke od ostalih sajtova. Da bi izbegli nepotrebno blokiranje procesa, koristi se vremensko ograničenje. • 2PC je ne non-bloking protokol, pošto je mogude da lokacije budu blokirane u određenim uslovima. Npr. proces kome je isteklo vreme nakon glasanja za commit, ali pre dobijanja globalne instrukcije od koordinatora, je blokiran ako može samo da komunicira sa lokacijom koja slično ne zna za globalnu odluku. • Verovatnoda blokiranja u praksi je poprilično mala, pa vedina sistema koristi 2PC. • Pored 2PC, postoji alternativni ne-blokirajudi protokol, 3PC (three-phase commit). 45. 3PC (three-phase commit) • Osnovna ideja 3PC je da se ukloni period neizvesnosti učesnika koji su glasali za COMMIT i čekanja na GLOBALNU odluku. • Uvodi se nova (treda) faza, pre-commit, između glasanja i globalne odluke. • 3PC three-phase commit, koordinator šalje dodatne poruke između faze glasanje i odluke svim učesnicima pitajudi ih za pre-commit transakcije, između glasanja i globalne odluke. Kad dobije sve glasove od učesnika, kordinator šalje PRE-COMMIT poruku. Učesnik koji je dobio PRE_COMMIT poruku zna da su svi ostali učesnici glasali za COMMIT,, i učesnik de da definitivno commituje, sem ako podbaci (fail). • ABORT glas od obrađuje na isti način kao i kod 2PC. 46. Primeri DDBMS funkcionalnosti kod Oracle-a • Oracle 9i • Kao i mnoge komercijalne DDBMS, Oracle ne podržava tipove mehanizma fragmentacije, iako DBA može ručno da distribuira podatke I postigne sličan efekat. Na ovaj način se menja odgovornost na krajnjeg-korisnika da zna kako tabela je fragmentirana i da ugradi ovo u aplikaciju. • Drugim rečima, Oracle DDBMS ne podržava transparentnost fragmentacije, iako podržava transparentnost lokacije. 47. Šta je X/Open Distributed Transaction Processing (DTP) Model • Open Group nezavisno, međunarodni konzorcijum korisnika, sw/hw kuda čiji je cilj da pokrene stvaranje globalnih infrastuktura. • X/Open ustanovili Distrirbuted TransactionProcessing

(DTP) working group sa cilje specifikovanja I podsticanja odgovarajudeg programskog interfejsa za obradu transakcija; • Osnovno grupa se fokusira na ostvarivanje ACID osobina. • X/Open DTD standard tri komponente: aplikacija, menadžer transakcije (TM) i menadžer resursa (RM). • Svaki podsistem koji ima implementiran transakcione podatke može biti RM (npr. DBMS, transackionalni file sistem..). • TM je odgovoran za definisanje opsega transakcije i za dodeljivanje jedinstvenog IDa. • Aplikacija zove TM da započne transakciju, zove RM da upravlja podacima, i zove TM da završi transakciju. • TM komunicira sa RM u koordinaciji transakcije, TM koordinira distriburianom transkacijom. • Aplikacija može koristi TX interfejs za komunicira sa TM. • TX obezbeđuje pozive koji definišu opseg transakcije, i da li se vrši commit/abort transakcije. • TM komunicira informacije transakcije sa RM preko XA interfejsa. • Na kraju, aplikacije mogu da komuniciraju direktno sa RM preko nativnih API-ja, kao što je SQL .

48. Dvoslojna klijent-server arhitektura • Sredinom 90-tih, aplikacije su postale kompleksije i mogu potencijalno da se koriste za stotine ili hiljade krajnih korisnika, klijentska strana predstavlja dva problema koja sprečavaju pravu skalabilnost: – “Debeo” klijent, zahteva značajne resurse na klijentovom računaru da bi se izvršravao efikasno. Ovo uključuje prostor na disku, RAM i snagu CPUa. – Značajna administracija sa strane klijenta. 49. Troslojna (i n-slojna) klijent-server arhitektura • Do 1995, nova varijanta tradicionalnog dvoslojnog klijent server modela se pojavila da reši problem skalabilnosti preduzeda. Ova nova arhitektura je predložila 3 nivoa, svaki potencijalno se izvršava na različitoj platformi: 1. Korisnički nivo interfejsa, koji se izvršava na korisničkom računaru (klijentu) 2. Poslovna logika i nivo obrade podataka. Srednji sloj se izvršava na serveru i često se zove aplikacioni server. 3. DBMS, koji čuva podatke potrebne srednjem sloju. Ovaj sloj može da se izvršava na posebnom serveru, DB serveru.

• Klijent je odgovoran samo za korisnički interfejs aplikacija (i neke jednostavne obrade, npr. kao što je validacija ulaza) • Srž poslovne logike aplikacije se sada nalazi na sopstvenom nivou, fizički povezana sa klijentom i DB serverom preko LANa ili WANa. Jedan aplikacioni serverje kreiran da uslužuje više klijenata. • Prednosti: – “Mršav” klijent, zahteva manje skup hardver. – Aplikacije ostaje centralizovane – Jednostavnije menjanje ili zamena jednog nivoa bez uticaja na druge. – Odvajanje poslovne logike od funkcija baze čini ih jednostavnijim za implementaciju balansiranog opteredenja. – Mapira se jednostavno u Web okruženje. N-slojna arhitektura • Troslojna arhitektura može da se proširiti u n-slojnu arhitekturu, sa dodatnim slojevima koji obezbeđuju više fleksibilnosti I sklabilnosti. Npr. srednji sloj arhitekture može biti podeljen na dva, sa jednim nivom za web server a drugim nivoom za aplikativni server. 50. Aplikativni server Aplikativni server hostuje API da bi izložili poslovnu logiku i poslovne procese da bi ostale aplikacije mogle da koriste. • Aplikacioni server je neophodno da izvršava brojna kompleksna stavke: – Konkurentnost – Upravljanje mrežnom konekcijom – Obezbeđuje pristup svim database serverima – Balansirano opteredenje Primeri aplikativnih servera Java Platform, Enterprise Edition (JEE) specifikacija za platformu za serversko programirnje u Java programskom jeziku;JEE aplikativni serveri: – WebLogic Server i OC4J (Oracle Container for Java) – Jboss (Red Hat) – WebSphere Application Server from IBM – open source Glassfish Application Server • .NET Framework (Microsoft) podržava razvoj srednjeg sloja • Oracle Application Server obezbeđuje skup servisa za skalabilni višenivousku infrastrukturu da podrži e-Business. 51. Middleware Middleware je kompjuterski softver koji povezuje softverske komponente ili aplikacije. • Middleware je opšti termin koji se koristi da opiše softver koji posreduje sa drugim softverom i

dozvoljava komunikaciju između različitih aplikacija u heterogenim sistemima. • Middleware potreban kad distribuirani sistemi postaju previše kompleksni da bi efikasno moglo njima da se upravlja bez zajedničkog interfejsa. • Potreba da heterogeni sistemi efikasno upravljaju preko mreže i budu dovoljno fleksibilni za modifikacije vodi do razvoja middleware, koji sakriva donju kompleksnost distribuiranog sistema. Hurwitz (1998) definiše 6 osnovnih tipova middleware: 1. Asinhroni Remote Procedure Call (RPC): 2. Sinhroni RPC 3. Publish/subscribe 4. Message-oriented middleware (MOM): 5. Object-requested broker 6. SQL-oriented data access 52. Web servisi Web servisi: Softverski sistem dizajniran da podrži interoperablilnu interakciju na mreži, mašina-mašini. • Za razliku od drugih aplikacija, Web servisi nemaju korisnički interfejs i nisu namenjeni za Web browser. • Web servisi dele poslovnu logiku, podatke i procese preko programskog interfejsa preko mreže. Na taj način, veza je aplikacije - aplikacija, ne između korisnika. Developeri kasnije mogu da dodaju Web servis Web strani (ili izvršnom programu) da bi obezbedili funkcionalnost korisniku. Ključno za Web servise je korišdenje široko prihvadenih tehnologija i standarada: – XML (eXtensible Markup Language) – SOAP (Simple Object Access Protokol) je komunikacioni protokol za razmenu struktuiranih informacija preko Interneta I korišdenje poruka u formatu XMLa; nezavisan od platforme I jezika. – WSDL (Web Service Description Language) protokol, baziran na XMLu, se koristi da opiše i locira Web servise. – UDDI (Universal Discovery, Description and Integration) protocol koje je platformski-nezavisan, XML baziran registy za poslove da ih prikaže na internetu. Iz perspektive baze, Web servisi mogu se koristiti iz baze (za pozivanje eksternog Web servisa kao “consumera”) i Web servis sam može da pristupi sopstvenoj bazi (kao “provider”) da održava podatke potrebe da obezbedi zahtevani servis. 53. Data Warehouse Podaci u DW su opisani kao : – Subject-oriented, pošto se warehouse organizuje oko glavnih subjekta (predmeta) u organizaciji; kao što su (kupci, proizvodi) pre nego oko oblasti aplikacije (fakturisanje, kontrola zaliha) – Integrisani,

– Vremenski zavisni, pošto podaci u warehouse su tačni samo u nekom momentu/periodu vremena – Nonvolatile (nepromenljivi) pošto podaci se ne ažuriraju u realnom vremenu ali se osvežavaju od operativnih sistema na regularnoj bazi. Novi podaci se uvek dodaju kao dodaci bazi, pre nego zamene. Prednosti DW • Potencijalno visok povratak investicija • Kompetetivna prednost • Povedava produktivnost korporativnog donošenja odluka Glavna svrha DW je da se obezbede informacije poslovnim korisnicima za strateško donošenje odluka; • DW mora efikasno da podrži ad hoc I analize rutine kao i kompleksnije analize podataka. • Tipovi end-user alata za pristup uključuju izveštavanje i upite, alate za razvoj aplikacija, data mining tools. Problemi sa DW • Razumevanje resursa za učitavanje podatak • Skriveni problemi sa izvornim sistemima • Potreni podaci nisu “uneseni • Povedanje zahteva krajnih korisnika • Homogenizacija podataka. • Visoki zahtevi za resures, • Vlasništvo podataka • Visoka cena održavanja • Dugo trajanje projekta • Kompleksnost integracije 54. Glavne komponente DBMS DBMS je podeljen u nekoliko softverskih komponenti (ili modula), svakome je pridružena specifičnan operacija. • Dizajn DBMS mora uzeti u obzir interfejs između DBMS i operativnog sistema. Procesor upita (query processor) transformiše upit u seriju instrukcija niskog nivoa koje se šalju DB menadžeru • DB menadžer: prihvata upit i ispituje spoljne I konceptualne šeme da otkrije koji konceptualni rekordi su potrebni da se zadovolji zahtev. DM šalje zahtev fajl menadžeru. • Fajl menadžer upravlja sačuvanim fajlovima I upravlja alokacijom prostora na disku. Ustanovljuje i održava listu struktura i indeksa definisanih u internoj šemi. Ipak fajl menadžer direktno ne upravlja fizičkim U/I podataka. • DML preprocesor: konvertuje DML naredne iz aplikativnih programa u standardne pozive funkcija u host jeziku. DML preprocesor zajedno sa procesorom upita generiše odgovarajudi kod. • Katalog menadžer: upravlja pristupom i održava sistemski katalog

55. Komponente DB menadžera - Scheduler: odgovoran za konkurentne operacije u bazi; kontroliše relativni poredak. - Buffer manager (cahe manager) 56. Ograničenja RDBMSa Relacioni model i relacioni sistemi, imaju ograničenja kao što je: – ograničenja u predstavljanju entiteta “realnog sveta”, – sematički overloading, – ograničena podrška za integritete i ograničenja, – ograničene operacije i – nesaglasnost impedanse. • Ograničene mogudnosti modelovanje relacionog DBMS su ga učinili neadekvatnim za naprednije aplikacije baze. • Kao odgovor na povedanu kompleksnost DB aplikacija, dva nova modela su se pojavila OODM (Object-Oriented Data Model) i ORDBM (Object-Relational Data Model). Ova evolucija je predstavlja tredu generaciju DBMSa 57. Navesti osnovne karakteristike ORDBMSa OO karakteristike koje su dodate u ORDBMS su: – Korisnički-prošireni tipovi, – Enkapsulacija – Nasleđivanje – Polimorfizam – Dinamičko vezivanja metoda – Kompleksni objekti uključujudi i objekte koji nisu u 1NF – Identitet objekta. ORDBMS - Karakteristike • Ne postoji jedinstveno proširenje relacionog modela. • Svi modeli – Dele osnovne relacione tabele i upitne jezike – Svi imaju neke koncepte objekata – Neki mogu čuvati metode (ili procedure ili trigere) • Neki analitičari predviđaju da de ORDBMS imati 50% vedi udeo na tržištu od RDBMS. 58. Prednosti i mane ORDBMSa Prednosti ORDBMS • Rešili su mnoge slabosti RDBMS • Ponovno korišdenje i deljenje: – Ponovo korišdenje – proširenje mogudnosti da se standardne funkcionalnosti izvršavaju na centralno. – Povedava produktivnost i programera I krajnjeg korisnika. – Zadržava značajan korpus znanja i iskustva u razvoju relacionih aplikacija.

Mane ORDBMS • Kompleksnost • Povedanje cene • Zagovornici relacionog pristupa veruju da jednostavnost i “čistota” relacionog modela je izgubljena. • Neki veruju da RDBMS je proširen za minorne aplikacije. • OO zagovornici nisu zadovoljni proširenjem • SQL je sada veoma kompleksan. 59. Šta je definisano u CADF (Committee for Advanced DBMS Function) manifestu i u Tredem manifestu (Darwen/Date) CADF, 1989 (Stonebraker et al.): – 3rd generacija DBMS mora da ima bogat sistem tipova – Nasleđivanje je dobra ideja – Funkcije, uključujudi procedure baze podataka I metode i enkapsulacija su dobra ideja. – Jedinstveni identifikatori za rekorde treba da budu dodeljeni DBMS jedino ako korisnički definisani primarni ključ nije dostupan. CADF Manifest • Pravila (trigeri, ograničenja) postade glavne karakteristike u bududnosti. Nede biti povezani sa određeno funkcijom ili kolekcijom. • Esencijalno svi programerski pristupi bazi trebaju da budu preko ne-proceduralnog, jezika pristupa visokog nivoa. • Trebalo bi da bude bar dva načina da se specifikuje kolekcija, jedan korišdenjem nabrajanjem članova i jedan korišdenjem upitnog jezika. CADF Manifest • Pogledi koji se ažuriraju su esencijalni • Indikatori performansi nemaju ništa da rade sa modelima podataka i ne mogu da se pojavljuju u njima • III gen. DBMS mora da se pristupa iz nekoliko jezika višeg-nivoa. • Postojane forme jezika visokog nivoa, je dobra ideja. • SQL je “integalactic dataspeak” • Upiti i njihovi odgovarajudi odgovori trebaju da budu najniži nivo komunikacije između klijenta i servera. CADF Manifest Tredi manifest • Darwen/Date definisali su RDM u Tredem Manifestu (1995, 2000) • Potvrđeno je da su određene OO karakteristike poželjne, ali veruju da karakteristike su ortogonalne prema RDM. • Prema tome, RDM NE treba: ekstenziju, korekciju, subsumtion, i povrh svega “iskrivljenje” • Ipak, SQL je nedvosmisleno odbačen, i umesto toga

jezik D je predložen. Tredi Manifest • Domen je primarni objekat- imenovani skup enkapsuliranih vrednosti, proizvoljne kompleksnosti, ekvivalentno tipu podataka ili klasi objekata. • Skalari (domenske vrednosti) manipulisani su samo pomodu operatora definisanih za domen. • Predloženo je nasledstvo za domene • Ugnježdene transakcije trebaju da budu podržane. 60. SQL:2003 OO karakteristike • Tipovi konstuktora za nove tipove redova i tipove referenci • Korisnički definisani tipovi koji mogu učestvovati u nadtipovi/ pod-tipovi relacijama • Korisnički definisane procedure, funkcije, metode i operatori • Tipovi konstuktora za tipove kolekcija (nizovi, skupovi, liste i mulitsets) • Podrška za velike objekte BLOB i CLOB • Rekurzija 61. Korisnički definisani tipovi SQL:2003 dozvoljava definiciju UDT • Mogu se koristiti na isti način kao built-in tipovi. • Podela na: – Distinct – Structured • Distinct tipovi dozvoljavaju razliku između istih underlying osnovnih tipova: • CREATE TYPE OwnerNoType AS VARCHAR(5) FINAL; • CREATE TYPE StaffNoType AS VARCHAR(5) FINAL; • Rezultat je greška ako se tretira instanca jednog tipa kao instanca drugog tipa. • Nije isti kao SQL domen, koji sadrži skup validnih vrednost koje se mogu čuvati. • U opštem slučaju, UDT definicija se sastoji od jedne ili više definicija atributa. • Definicija takođe se sastoji od deklaracije rutina • Može se takođe definisati jednakost i relacija poredka korišdenjem CREATE ORDERING FOR. Korisnički definisani tipovi – Enkapsulacija i get/set funkcije • Vrednostima atributa se pristupa korišdenjem uobičejene notacije: p.fName • SQL enkapsulira svaki atribut preko get/set funkcije • Ove funkcije može redefinisati korisnik u UDT definiciji FUNCTION fName(p PType) RETURNS VARCHAR(15) RETURN p.fName;

Konstruktor i NEW izraz • (Javni) konstruktor funkcija se automatski definiše da kreira nove instance tipa: SET p = NEW PersonType; • Funkcija konstruktor ima isto ime kao tip, sadrži 0 argumenata, i vrada novu instancu sa atributima postavljenim na njihove default vrednosti. 62. Trigeri • SQL (složeni) iskazi se izvršavaju automatski od strane DBMS kao bočni efekt modifkacije imenovane tabele. • Korišdenje trigera obuhvata: – Validaciju ulaznih podataka i manipulaciju kompleksnim ograničenjima integriteta što je drugačije teško/nemogude – Podržavanje alerta – Održavanje audit informacija – Podržavanje replikacije. • Za jednu tabelu može se definisati vise trigera. Redosled: 1. Izvršavanje bilo kog BEFORE trigera nad tabelom 2. Za svaki red izazvan naredbom: • Izvršiti bilo koji BEFORE triger na nivou reda. • Izvršiti iskaz sam • Izvršiti bilo koji referencijalno ograničenje • Izvršiti bilo koji AFTER row-level triger 3. Izvršiti bilo koji AFTER triger nad tabelom. Trigeri – prednosti i mane • Preddnost: standardne funkcije mogu se čuvati u bazi izvršavati konzistentno, čime se značajno smanjuje kompleksnost aplikacije • Postoje mane: – Kompleksnost, skrivena funkcionalnost, performance overhead . 63. Veliki objekti (LOB) • Polja tabela koja sadrže velike količine podataka • Tri različita tipa podataka: BLOB (Binary Large Object), CLOB (Character LOB), National CLOB • BLOB- ne interpretirani niz podataka • Polje tabele koje ima veliku količinu podataka • Tri različita tipa: – BLOB (Binary Large Object) – CLOB (Character BLOB) – NCLOB (National CLOB) 64. Korisnički definisani tipovi podataka podržani u Oracleu • Mnoge od objektno-orijentisanih funkcija koje su se pojavile u novom SQL:2003 standardu se u Oracle-u nekoj od formi. • Oracle podržava dve korisnički definisane tipove podataka: – Objektne tipove

– Tipove kolekcija Objektni tipovi u Oracle • Tip objekta je objekat šeme koji ima ime, skup atributa zasnovan na Oracleovim ugrađenim tipovima podataka (ili drugih tipovima objekata), i skup metoda • PRAGMA klauzua je poništava funkcije read/write pristup baznim tabelama i/ili paket varijablama. • Sada je mogude kreirati Branch (Object) tabelu: CREATE TABLE Branch OF BranchType (branchNo PRIMARY KEY); 65. Zahtevi za Web –DBMS integraciju • Mogudnost pristupanja važnim korporativnim podacima na bezbedan način. • Nezavisno (od podataka i proizvođača) povezivanje koje dozvoljava slobodu izbora DBMSa • Mogudnost povezivanja na bazu podataka nezavisno od bilo kog browsera ili Web servera. • Mogudnost konekcije koja uzima prednosti svih karakteristika DBMS organizacije. • Otvorena arhitektura koja dozvoljava interoperabilnost sa brojnim sistemima i tehnologijama. Na primer: – Različiti Web serveri; – Microsoft (Distributed) Common Object Model (DCOM/COM) – CORBA/IIOP ( Common Object Request Broker Architecture/Internet Inter- ORB protocol); – Java/Remote Method Invocation (RMI); – XML – Web servisi (SOAP, WSDL, UDDI); • Isplativo rešenje koje dozvoljava skalabilnost, rast i promene u strateškim pravcima i pomaže smanjivanje cene razvoja aplikacije. • Podržava transakcije koje obuhvataju više HTTP zahteva. • Podrška za sesije i autentifikaciju zasnovanu na aplikacijama. • Prihvatljive performanse • Minimalno administrativno prekoračenje. • Skup visoko produktivnih alata koji dozvoljavaju da aplikacije se razvijaju, održavaju relativno brzo i lako. 66. Prednosti i ograničenja Web-DBMS pristupa • Jednostavnost (potiče od HTMLa, ali dodavanjem skriptig jezika narušava se) • Platformska nezavisnost (web klijent- browser- uglavnom platformski nezavisan i nije potrebena modifikacija aplikacija) • Grafički korisnički interfejs • Standardizacija (HTML de facto standard za browsere, XML za razmenu podataka) • Podrška za razne platforme • Transparentan pristup mreži • Skalabilan razvoj (troslojna arhitektura) • Inovacije.

Ograničenja Web-DBMS pristupa • Pouzdanost (ne postoji garantovana isporuka, posebno kada je preoptredenje). • Bezbednost • Cena (2004. Forrester Research za komercijalne Web sajtove US$300,000 - US$3.4 million) • Skalabinost (web aplikacije mogu imate neočekivane i potencijalno velike pikove; uvedene su web farme- gde 2 ili više server opslužuju isti sajt . • Ograničena funkcionalnost HTMLa • Protok • Performanse • Nezrelost razvojnih alata. 67. Pristupi za Integraciju Weba i DBMS • Scripting jezici • Common Gateway Inteface (CGI) • HTTP Cookies • Proširenje Web servera • Java, J2EE, JDBC, SQLJ, JDO, Servlets and JSP. • Microsoft Web Solution Platform: .NET, ASP and ADO. • Oracle Internet Platform. 68. CGI • Specifikacija transfera informacija između Web servera I CGI programa. • Server šalje dokument i šalje browseru koja vrsta dokumenta je to. • Ali server takođe zna kako da pokrene druge programe • Kada sever vidi da URL pokazuje na program (skript), izvršava skript i šalje nazad izlaz skripta browseru kao da je fajl. • CGI definišu kako skriptovi komuniciraju sa Web serverima. • CGI skript je bilo koji skript koji je kreiran da prihvati I vrati podatke u skladu sa CGI specifikacijom. • Pre nego što server pokrene skript, pripremaju se brojne varijable okruženja predstavljajudi trenutno stanje servera, koje zahteva informaciju, i dr. CGI - Prednosti • CGI je de facto standard za povezivanje Web server sa aplikacijama. • Najčešde korišden metod za povezivanje Web aplikacijama sa izvorima podataka. • Prednosti: – Jednostavnost, – Jezička nezavisnost – Nezavisnost web servera – Široka prihvadenost. CGI - ograničenja • Komunikacija između klijenta i server baze podataka mora uvek idi preko Web servera. • Manjak efikasnosti i podrške transakciji;

kao i teškode validacije korisničkog upita zbog statelessness HTTP protokola. • Server treba da generiše nove procese ili thread za svaki CGI skript. • Bezbednost. 69. Proširenje Web server • Da se prevaziđe ograničenje CGI, mnogi serveri obezbeđuju API koji dodaje funkcionalnost serveru. • Skriptovi se učitavaju kao deo servera, dajudi back-end aplikacijama pun pristup svim I/O funkcijama servera. • Jedna kopija aplikacije je učitana i podeljena između više zahteva servera. • Pristup je mnogo kompleksniji nego CGI, verovatno zahteva specijalizovane programere. • Može obezbediti veoma fleksibilno i modno rešenje. • API proširenje može obezbediti istu funkcionalnost kao CGI program, ali API se izvršava kao deo na serveru, API pristup može da se izvršava značajno bolje nego CGI. • Prošireni Web server je potencijalno opasan, pošto izvršavanje servera je promenjeno. 70. JDBC • Modelovan nakon ODBC, JDBC API podržava osnovne SQL funkcionalnosti • Sa JDBC, Java može se koristi kao host jezik za pisanje aplikacija baze podataka. • Na vrhu JDBC-a, može se izgradi API višeg nivoa. • Trenutno, dva tipa APIja višeg nivoa: – Embeded SQL for Java (SQLJ) – Direktno mapiranje tabela relacione baze u Java klase (npr. TopLink from Oracle). JDBC • JDBC API se sastoji od dva glavna interfejsa: API za pisanje aplikacija i nižeg nivoa API drajver za pisanje drajvera. • Aplikacije i apleti mogu pristupati bazi korišdenjem: – ODBC drajvera i postojedih klijentskih biblioteka. – JDBC API sa “čistim” JAVA JDBC drajverima JDBC – Prednosti/Mane • Prednosti korišdenja ODBC drajvera je da su oni de facto standard za PC pristup bazama i da su dostupni (i jeftini) za mnoge DBMS. • Mane ovog pristupa: – Ne čist JDBC drajver nede neophodno raditi sa Web browserom. – Trenutno downloadovan aplet može da se poveže samo sa bazom podataka na host mašini.

71. SQLJ • Drugi JDBC-based pristup koristi Java sa statički ugrađenim (embeded) SQL-om. • SQLJ obuhvata skup naredni koje proširuju Javu da obuhvati SQL structure (naredbe i izraze) • SQLJ prevodilac transformiše SQLJ iskaz u standardni Java kod koji pristupa bazama preko CLIa. Poređenje JDBC i SQLJ • SQLJ je baziran na statičkom ugnježdenju SQLa dok JDBC je baziran na dinamičkom SQLu. • Prema tome, SQLJ olakšava statičku analizu za proveru sintakse, a koje mogu proizvesti više pouzdanih programa uz gubitak određene funkcionalnosti. • Takođe potencijalno dozvoljava DBMS da generiše strategiju izvršavanja za upit, time se poboljšavaju performanse upita. • JDBC je middleware niskog nivoa sa karakteristikama da poveže Java aplikacije sa RDBMSom. • Developeri je potrebno da kreiraju relacionu šemu u koju de mapirati Java objekte, i pisati kod da mapiraju Java objekte u redove relacije. • Problemi: – Potreba da se bude svestan dve različite paradigme (objektne I relacione) – Potreba da se dizajnira relaciona šema za mapiranje u objektni dizajn. – Potreba da se piše kod za mapiranje. 72. OLE DB arhitektura • Microsoft je definisano skup objekata podataka, poznat kao OLE DB. • OLE arhitekura omogudava aplikacijama da koriste deljene objekte koji obezbeđuju specifičnu funkcionalnost. • Dozvoljava OLE-orijentisanim aplikacijama da dele i manipulišu skup podataka kao objekte. • OLE DB je objektno-orijentisana specifikacija bazirana na C++API-ju. • Komponente se mogu tretirati kao “data consumers” I “data providers”. Consumers uzimaju podatke iz OLE DB interfejsa i provajderi izlažu OLE DB interfejse. 73. Active Server Pages • ASP je programski model koji dozvoljava dinamičke, interaktivne Web strane da budu kreirane na serveru. • ASP obezbeđuje fleksibiblost CGI-a, bez preopteredenja performanse. • ASP se izvršava kao proces na serveru, i optimizovan je da upravlja velikim obimom korisnika. • Kada “.asp” fajl se zahteva, Web server zove ASP, koji zove zahtevani fajl, izvršava bilo koje komande, i šalje generisane HTML strane nazad browseru.

Poređenje ASP i JSP • Oba su dizajnirana da obezbede developerima razdvajanje dizajn strane od programske logike preko komponenti koje se pozivaju. • Razlike: – JSP je u osnovi platformski i serveski nezavisan dok ASP je primarno ograničen na MS Window platforme. – JSP možda više proširivo kako JSP developeri mogu da prošire dostupne JSP tagove. – JSP komponente su ponovo iskoristive preko platformi. – JSP ima prednost zbog ugrađenog Java bezbednosnog modela. 74. Mobilne baze • Povedani zahtev za mobilnim računarima da obezbedi tipove podrške potrebne za povedani broj ljudi koji rade preko mobilnog. • Rade kao i na poslu ali u realnosti rade sa udaljenih lokacije. • Udaljeni radnici mogu imati laptop, PDA (Personal Digital Asistant) ili druge Internet servise pristupa. • Baze podatka koje su portabilne i fizički odvojene od centralizovanog servera baze podatka ali je sposobna za komuniciranje sa serverom sa udaljenog sajta dozvoljava deljenje korporacijskih podataka. Komponente okruženja mobilne baze obuhvataju: Korporativne DB servere i DBMS koji upravlja I skladišti korporativne podatke i obezbeđuje korporativne aplikacije 1.Udaljene baze i DBMS koji upravlja i skladišti mobilne podatke i obezbeđuje mobilne aplikacije. 2.Mobilne DB platforme koje uključuju laptopove, PDA, ili druge Internet pristupne uređaje. 3.Dvostrani linkovi za komunikaciju između korporativnih i mobilnih DBMSa Mobilne baze • Komunikacije između “corporate” i mobilne baze je naizmenična i obično se uspostavlja za kratak period vremena za neregularne intervale. • Iako neuobičajeno, postoje neke aplikacije koje zahtevaju direktnu komunikaciju između mobilnih baza. Dva glavna pitanja povezana sa mobilnim bazama je upravljanje mobilnih baza I komunikacija između mobilnih i korporacijskih baza. • Funkcionalnost potrebna za mobilnu bazu obuhvata sposobnost za: – Komunicira sa centralizovanim DB serverom preko wireless-a ili Interneta. – Replicira podatke na centralizovanom DB serveru i mobilnim uređajima. – Sinhroniše podatke na centralizovanim DB serverima i mobilnim uređajima.

– “Hvata” podatke iz različitih izvora kao što je Internet. – Upravlja/analizira podatke na mobilnim uređajima. – Kreira po narudžbini mobilne aplikacije. • Klasični transakcioni model možda nije odgovarajudi za mobilno okruženje. • Prekid je glavni problem, posebno kad transakcije dugo traju i postoji veliki broj prekida- POUZDANOST je prvi zahtev pri obradi transakcija u mobilnom okruženju. • Za optimizaciju upita, u mobilinom distribuiranom okruženju cena komunikacije je mnogo teža da se proceni, pošto mobilni hostovi se nalaze na različitim lokacijama. • Najbolji sajt za pristup podacima zavisi od toga gde su mobilini hostovi locirani. U opštem slučaju, nije dovoljno proračunavati planove i njihove pridružene troškove statistički; radije, dinamičke optimizacione strategije su potrebne u ovom mobilinom distribuiranom kontekstu.