Arhitektura SUPB

Arhitektura SUPB

Arhitektura SUPB je dokaj kompleksna. V osnovi je sestavljen in štirih osnovnih modulov:

1. Uporabniški vmesnik - namenjen upravitelju PB, sofisticiranim uporabnikom, ...; lahko je tekstovni ali grafični.

2. Procesor poizvedb (query processor), ki ima naslednje podmodule:

> - DML prevajalnik (DML compiler),
> - vgrajen DML predprevajalnik (Embedded DML precompiler): DML stavke, vgrajene v aplikacijske programe, prevede v običajne klice procedur gostiteljskega jezika,
> - DDL interpreter, ki pretvori DDL stavke v množico tabel z metapodatki (opisi podatkov); tabele se shranijo v podatkovnem slovarju,
> - modul za ovrednotenje poizvedb (Query evaluation engine) ki prevede (in optimizira) stavke poizvedovalnega jezika v nizkonivojske instrukcije, ki jih razume upravitelj shranjevanja.

3. Upravitelj transakcij (transactions manager) - njegova naloga je, da zaklepa, beleži in izvaja transakcije.

4. Upravitelj shranjevanja (storage manager), ki ima naslednje podmodule:

- upravitelj avtorizacij in celovitosti (authorization and integrity manager) - nadzoruje dostope in celovitost podatkov,
- upravitelj datotek (file manager) - dostopa do datotek na disku
- upravitelj izravnalnika (buffer manager) - prepisuje bloke podatkov med trdim diskom in RAM pomnilnikom.

Moduli SUPB
Arhitektura SUPB-ja - uporabniški vmesnik

SUPB ima uporabniški vmesnik, ki omogoča komunikacijo med uporabniki SUPB-ja in samim programom.
Večina (današnjih) SUPB-jev ima grafične uporabniške vmesnike. Le ti so uporabnikom prijazni in enostavni za uporabo. Še vedno obstajajo (predvsem prostodostopni SUPB-ji), ki v osnovi imajo le tekstovne vmesnike.

Arhitektura SUPB-ja - procesor poizvedb

Osnovna naloga je procesorja poizvedb:

- prevzem poizvedb, ki jih načeloma dobi v obliki stavkov SQL in
- prevajanje le teh v zaporedje zahtevkov po podatkih.

Velikokrat je najzahtevnejši del procesiranja optimizacija poizvedb. Opomba: izdelava dobre poizvedovalne strategije je ključnega pomena za učinkovitost sistema.

Arhitektura SUPB-ja - upravitelj transakcij

SUPB zagotavlja ACID lastnost vsake transakcije.
ACID = Atomicity (atomarnost) + Consistency (konsistentnost) + Isolation (samostojnost/ izolacija/neodvisnost) + Durability (trajnost)

Atomarnost pomeni, da

- se ena transakcija mora izvesti do konca ali pa v celoti zavrniti;
- je treba opraviti bodisi vse zahtevane spremembe ali pa nobene.

Konsistentnost

- Transakcija transforima stanje podatkovne baze iz enega veljavnega stanja v drugo veljavno stanje. Transakcija je veljavna / legalna le, če upošteva vse integritetne omejitve podatkovne baze. Če stanje po izvedbi transakcije ni več veljavno, se transakcija zavrne v celoti (vrnemo se v prejšnje veljavno stanje podatkovne baze).

Izolacija

- Rezultat izvedbe transakcije je drugim transakcija prikrit, dokler se transakcija ne izvede do konca.

Trajnost

- Rezultati uspešno izvedene transakcije so trajno shranjeni in dostopni tudi, če se takoj po izvedbi transakcije sistem poruši

Postopek zagotavljanja atomarnosti transakcij:

1. beleži se 'log' oz. zgodovina vseh izvedenih akcij;
2. pred izvedbo katerekoli sprememba v PB mora biti ustrezen log zapis shranjen na varnem mestu. V primeru nesreče je enostavno razveljaviti učinek le delno izvedene transakcije.

Arhitektura SUPB-ja - upravitelj shranjevanja

> Upravitelj izravnalnika (buffer manager)

- ravna s prostorom v glavnem pomnilniku,
- s pomočjo upravitelja datotek pridobiva bloke podatkov z diska in izbira stran v glavnem pomnilniku, v katero se podatki prepišejo,
- algoritem ostranjevanja določa, koliko časa bo posamezna stran (blok podatkov) ostala v pomnilniku.

> Upravitelj datotek (file manager)

- beleži lokacije datotek na disku in na zahtevo upravitelja izravnalnika pridobiva blok ali bloke podatkov iz datoteke. Opomba: področje diska je največkrat razdeljeno na bloke neprekinjenega prostora velikost med 212 in 214 zlogov (od 4K do 16KB).