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.
img73_8
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).