VARNOST PODATKOVNE BAZE PostgreSQL - core.ac.uk · podatkov, ki jih sre čujemo v okviru svetovnega spleta (slike, zvok, animacije, VRML, Java apleti, ipd). Slabost objektnih baz

UNIVERZA V MARIBORU

FAKULTETA ZA ELEKTROTEHNIKO, RAČUNALNIŠTVO IN INFORMATIKO 2000 Maribor, Smetanova ul. 17

Diplomska naloga visokošolskega študijskega programa

VARNOST PODATKOVNE BAZE

PostgreSQL Študent: Zoran KREBS Študijski program: Visokošolski, Računalništvo in informatika Smer: Informatika

Mentor: red. prof. dr. Tatjana WELZER

Maribor, april 2008

Zoran Krebs - diplomsko delo 2


ZAHVALA

Zahvaljujem se mentorici dr. Tatjani Welzer -

Družovec za pomoč in vodenje pri opravljanju

diplomske naloge. Prav tako se zahvaljujem Marku

Hölblu za pomoč.


VARNOST PODATKOVNE BAZE PostgreSQL

Ključne besede: podatkovne baze, varnost podatkovnih baz, replikacija UDK: 004.6.056(043.2) Povzetek

Diplomska naloga obravnava problem varnosti podatkovnih baz, na katere elemente

varnosti in zaščite je potrebno paziti pri načrtovanju podatkovnih baz ter kako pristopiti k

izboljšanju varnosti in zaščiti podatkovnih baz. Spoznanja apliciramo na podatkovno bazo

PostgreSQL, ki je predmet raziskave. Obravnavali bomo varnostne mehanizme in rešitve,

ki prispevajo k večji varnosti podatkovnega strežnika PostgreSQL. Izpostavili bomo

avtentikacijo, avtorizacijo, zaščito pred nekosistentnostjo podatkov, replikacijo podatkovne

baze, načine shranjevanja podatkov ter rešitve v primeru morebitne povrnitve podatkov iz

varnostne kopije.


PostgreSQL SECURITY

Key words: database, database security, replication UDK: 004.6.056(043.2)

Abstract

The diploma work discusses the database security problem, security and protection

elements which have to be considered when designing databases, methodologies and

techniques for securing databases. The security considerations are applied to the

PostgreSQL database. Additionally, we deal with security mechanisms and solutions which

contribute to higher security. In this context authentication, authorization, inconsistency

protection, database replication, data storage modes and data restoration from backup

copies are focused on.


UPORABLJENE KRATICE

PB Podatkovna Baza

SUPB Sistem za Upravljanje s Podatkovno Bazo

SQL Structured Query Language

DBMS Database Management System

IS Informacijski Sistem

WAL Write Ahead Log

DRP Disaster Recovery Plan

VRML Virtual Reality Markup Language

OLAP On Line Analytical Processing

ACID Atomicity Consistency Isolation Durability

MVCC Multi-Version Concurrency Control

PITR Poin In Time Recovery

SSL Secure Sockets Layer Protocol

EMEA območje držav Evrope, Bližnjega Vzhoda in Afrike

2PL Two Phase Locking

€ evro


KAZALO

1. UVOD................................................................................................................................ 9 1.1. Definicija podatkovne baze ...................................................................................... 10 1.2. Klasifikacija podatkovnih baz .................................................................................. 11 1.3. Značilnosti današnjih podatkovnih baz .................................................................... 11 1.4. Kratek opis in zgodovina PostgreSQL ..................................................................... 13

1.4.1. Značilnosti PostgreSQL..................................................................................... 14 1.5. Primerjava z ostalimi produkti ................................................................................. 14

2. VARNOST PODATKOV V PODATKOVNIH BAZAH............................................... 17 2.1. Kratek opis problema varnosti v podatkovnih bazah ............................................... 17

2.1.1. Varnost v spletnem poslovanju (med podjetji).................................................. 18 2.1.2. Varnost v okviru zaključene celote (znotraj podjetja)....................................... 19 2.1.3. Izguba podatkov ................................................................................................ 20 2.1.4. Nekonsistentnost podatkov................................................................................ 22 2.1.5. Okrevalni načrt .................................................................................................. 23

2.2. Zaščita podatkovne baze........................................................................................... 23 2.2.1. Nadzor dostopa .................................................................................................. 24 2.2.2. Zaščita pred nekonsistentnostjo podatkov......................................................... 29 2.2.3. Zaščita pred izgubo podatkov............................................................................ 33 2.2.4. Zaščita pred preveliko obremenitvijo ................................................................ 35

3. VARNOST PODATKOV V PostgreSQL....................................................................... 39 3.1. Logična in fizična urejenost datotek......................................................................... 39 3.2. Nadzor dostopa ......................................................................................................... 41

3.2.1. Avtentikacija...................................................................................................... 41 3.2.2. Avtorizacija ....................................................................................................... 42 3.2.3. Enkripcija .......................................................................................................... 43 3.2.4. Uporabniške skupine ......................................................................................... 44

3.3. Zaščita pred nekonsistentnostjo podatkov................................................................ 46 3.3.1. Transakcije, ACID in PostgreSQL .................................................................... 46 3.3.2. Zaklepanje podatkov.......................................................................................... 48

3.4. Zaščita pred izgubo podatkov................................................................................... 49 3.4.1. Replikacija podatkovne baze ............................................................................. 49 3.4.2. Arhiviranje podatkov v PostgreSQL ................................................................. 51

3.5. Zaščita pred preveliko obremenitvijo ....................................................................... 53 4. POSTAVITEV IN VZDRŽEVANJE PostgreSQL STREŽNIKA .................................. 56

4.1. Opis okolja................................................................................................................ 56 4.2. Namestitev PostgreSQL ........................................................................................... 56

4.2.1. Minimalne zahteve za namestitev...................................................................... 56 4.2.2. Potek namestitve................................................................................................ 56

4.3. Administracija podatkov .......................................................................................... 57 4.3.1. Orodja za vzdrževanje strežnika PostgreSQL ................................................... 57

Vacuuming ...................................................................................................................... 58 4.4. SUPB ....................................................................................................................... 60

4.4.1. Pg Admin III...................................................................................................... 60 4.5. Postavitev podatkovne baze .................................................................................... 60

4.5.1. Omejevanje dostopa do podatkovne baze PostgreSQL..................................... 61 4.5.2. Opis postavitve shem, pravic, uporabnikov ...................................................... 62


4.5.3. Opis izdelave varnostne kopije podatkovne baze.............................................. 64 4.5.4. Povrnitev podatkov iz varnostne kopije ............................................................ 67 4.5.5. Opis postavitve replikacijskega strežnika ......................................................... 69

5. Zaključek ......................................................................................................................... 78 6. Literatura ......................................................................................................................... 80 KAZALO SLIK

slika 1: delitev uporabnikov, povzeto po [25] ..................................................................... 28 slika 2: primer enostavne mrtve zanke ................................................................................ 31 slika 3: gradniki podatkovne baze PostgreSQL, povzeto po [7] ......................................... 40 slika 4: primer pg_hba.conf datoteke .................................................................................. 61 slika 5: kreiranje podatkovne sheme ................................................................................... 62 slika 6: kreiranje nove uporabniške skupine........................................................................ 63 slika 7: kreiranje uporabnika, določitev skupine ................................................................. 64 slika 8: določimo ime ter mesto datoteke ............................................................................ 66 slika 9: poiščemo varnostno kopijo iz katere želimo povrniti podatke ............................... 68 slika 10: obvestilo, da je povrnitev končana........................................................................ 69 Slika 11: na podatkovni bazi »master« napravimo gručo test1 ........................................... 72 Slika 12: dodajanje podatkovne baze »slave1« v gručo test1 ............................................. 72 Slika 13: Podatkovni bazi »master« in »slave1« se zavedata ena druge ............................. 73 Slika 14: v primeru, da »Running PID« na enem izmed vozlišč ni nastavljen je prišlo do napake v enem izmed prejšnjih korakov ............................................................................. 74 Slika 15: na vozlišču »MasterNode« definiramo povezave do podatkovne baze »slave1« 75 Slika 16: na vozlišču »SlaveNode« definiramo parametre povezave do podatkovne baze »master« .............................................................................................................................. 75 Slika 17: prikazuje, kako napravimo replikacijsko množico............................................... 76 Slika 18: prikazuje, kako smo v podatkovni bazi »master« definirali replikacijsko množico »rep set 1«, ki replicira tabelo »testSchematestTable« na podatkovno bazo »slave1« ....... 77 KAZALO TABEL

tabela 1: primerjava produktov – povzeto po [18], [19]...................................................... 16 tabela 2: opis pomena datotek ............................................................................................. 41 tabela 3: opis pomembnejših podimenikov imenika data (/usr/local/data) ......................... 41 tabela 4: shema konfiguracijske datoteke PG_HBA.CONF................................................ 42 tabela 5: pregled pravic........................................................................................................ 42 tabela 6: pregled stopenj izolacije, povzeto po [21] ............................................................ 47 tabela 7: Pregled načinov replikacije skozi zgodovino PostgreSQL................................... 49 tabela 8: parametri ukaza pg_dump..................................................................................... 65 tabela 9: vsebina datoteke master.conf ................................................................................ 71 tabela 10: vsebina datoteke slave1.conf .............................................................................. 71


1. UVOD

V času spletnega poslovanja, v času »velike integracije na vseh nivojih«, v času, ko nas

»veliki modri brat« gleda nekje od daleč, želimo predstaviti podatkovno bazo ter sistem za

upravljanje s podatkovnimi bazami, ki sta odprto kodna, pa kljub temu dovolj zaprta in

varovana pred pogledi iz spleta ter pred pogledi uporabnikov v nekem zaključenem

informacijskem sistemu. Zato smo se odločili predstaviti podatkovno bazo PostgreSQL,

eno izmed redkih odprtokodnih podatkovnih baz, ki ponuja praktično vse značilnosti

velikih komercialnih podatkovnih baz, a je kljub odprtokodni osnovi dovolj zmogljiva,

varna in zanesljiva.

V prvem delu diplomske naloge obravnavamo osnove podatkovnih baz, temu pa sledi

pregled podatkovne baze PostgreSQL, Predstavili bomo glavne značilnosti te odprtokodne

podatkovne baze in jih na kratko primerjati z odprtokodnimi in komercialnimi produkti, ki

so trenutno na tržišču.

V drugem delu se bomo omejili na varnost podatkovnih baz ter pokazali, zakaj je

podatkovna baza PostgreSQL primerna za uporabo tudi v korporacijskih okoljih, kjer

podatkovno bazo uporablja večje število uporabnikov, ki hkrati dostopajo do nje iz

različnih aplikacij znotraj lokalnega omrežja ali interneta. Predstavili bomo osnovne

varnostne mehanizme, s katerimi se izognemo nezaželjeni izgubi podatkov ali vdoru v

podatkovno bazo. Med slednje sodijo omejitev dostopa, enkripcija podatkov, varnostne

kopije in replikacija podatkovne baze.

V tretjem in četrtem poglavju želimo predstaviti praktične rešitve uporabe podatkovne

baze PostgreSQL. Poleg podatkovne baze se bomo seznanili z odprtokodnimi orodji za

upravljanje s podatkovno bazo ter knjižnicami, ki jih potrebujemo za delo v programskem

okolju Visual Studio. Osrednji cilj diplomske naloge bo ugotovitev, ali je PostgreSQL baza

dovolj »zrela« za uporabo v realnih okoljih, za kakšna okolja je primerna in ali je uporaba

le-te sploh smiselna. Glede na relativno nepoznanost podatkovne baze PostgreSQL, želimo

v nalogi prikazati produkt dovolj splošno in ponuditi morebiten uvod v PostgreSQL,

obenem pa želimo opozoriti na varnost podatkovnih baz, ki je v današnjem času zelo

aktualna.


1.1. Definicija podatkovne baze

Podatkovna baza (v nadaljevanju PB) je jedro informacijskega sistema, je srce aplikacij

in ne živi sama zase. Omogoča urejen način hranjenja podatkov, zagotavlja njihovo

dostopnost ter celovitost. Je model okolja, ki lahko služi kot osnova za nadzor, sprejemanje

odločitev in izvajanje akcij. S tehničnega vidika je podatkovna baza zbirka med seboj

pomensko povezanih podatkov, ki so shranjeni v računalniškem sistemu, dostop do njih je

centraliziran ali porazdeljen in omogočen s pomočjo sistema za upravljanje podatkovnih

baz [1].

Za nastanek in razvoj podatkovnih baz je pomembno poznati zgodovino njihovega

nastanka. Na začetku razvoja računalništva je bilo vse podrejeno računalniku. Uporabniki

so se morali prilagajati njegovim zmožnostim. Sestava podatkov je bila prilagojena za

lažjo uporabo na računalnikih. Programska oprema je bila tesno integrirana s podatki,

včasih celo do te mere, da so bili podatki neposredno zakodirani v programu. Sprememba

podatkov je zato večkrat zahtevala tudi spremembo programa. Po podatkovni revoluciji so

v ospredje prišli podatki. Glavni razlog za podatkovno revolucijo je bil razvoj

pomnilniških medijev. S čedalje nižjimi cenami in hkrati s čedalje večjo zmogljivostjo

magnetnih diskov se je spremenila tehnika programiranja. Zmanjševati se je začel

semantični prepad med programskimi jeziki in človeškim mišljenjem, programi pa so se

začeli prilagajati človeku in postajajo čedalje bolj neodvisni od računalnika. Ko podatki

stopijo v ospredje, postane podatkovna baza osnova za nadzor in vodenje poslovnih

procesov, za sprejemanje odločitev in za podporo dejavnosti podjetij. Med programsko

opremo in podatke stopi sistem za upravljanje s podatkovnimi bazami (v nadaljevanju

SUPB), ki mora zagotoviti razpoložljivost podatkov in nadzor nad njihovo uporabo tako

uporabnikov kot tudi programske opreme. Pri tem sistem za upravljanje s podatkovno bazo

skrbi za:

• celovitost in trajnost podatkov,

• učinkovit dostop do podatkov v okviru določenih pravic ter

• omogoča sočasnost uporabniških in sistemskih dostopov


1.2. Klasifikacija podatkovnih baz

Podatkovne baze lahko delimo na več načinov (namembnosti, obliki datotečnega

sistema, ipd). Med ostalim jih klasificiramo tudi glede na čas, kdaj so bile razvite oziroma

uporabljene.

Hierarhični in mrežni podatkovni model sta vezana na fizično organizacijo podatkovne

baze. To je razumljivo, saj sta nastala še v času, ko je bil dostop do podatkov omejen na

zaporedno branje magnetnih trakov. Ker je struktura zapisa v bazi predvidljiva, je dostop

do podatkov zelo enostaven. Zapisi so organizirani v hierarhijo starš-otrok (angl. parent-

child), kjer mrežni podatkovni model dovoljuje tudi dva ali več staršev v razmerju starš-

otrok. Ker moramo za vsako strukturo napisati program za dostop do nje, je programiranje

ob pogostih spremembah strukture podatkov v hierarhičnih podatkovnih bazah precej

zamudno.

Relacijski model izrablja prednost neposrednega dostopa do podatkov, kjer dostopni

čas do podatka na mediju ni več bistveno odvisen od tega, kje na mediju se podatek fizično

nahaja. Podatki in relacije med njimi so urejeni v tabele. Vsaka vrstica v tabeli predstavlja

neki zapis. Vsebina tabel je uporabnikom dostopna s pomočjo povpraševalnih jezikov, ki

temeljijo na relacijski algebri ali relacijskem računu. Najbolj pogost povpraševalni jezik je

gotovo SQL (angl. Structure Query Language).

Objektni podatkovni model je na neki način razširitev mrežnega. Podatki se shranjujejo

v obliki objektov. Vsak objekt ima lahko svoje atribute, ki ga opisujejo, kakor tudi metode,

ki dodajajo objektu določeno obnašanje. Objektne baze so zelo primerne za shranjevanje

podatkov, ki jih srečujemo v okviru svetovnega spleta (slike, zvok, animacije, VRML, Java

apleti, ipd). Slabost objektnih baz je predvsem nerazširjenost ter cena le-teh.

1.3. Značilnosti današnjih podatkovnih baz

Moderne podatkovne baze današnjega dne imajo naslednje značilnosti:

• referenčna integriteta (referential integrity – lastnost, ki ohranja celovitost povezav

med tabelami v okviru podatkovne baze)


• lokalne posebnosti (unicode - standard za kodiranje znakov, ki glede na

implementacijo za zapis znaka uporablja od enega do štiri bajte. To naj bi

zadoščalo za zapis večine svetovnih jezikov)

• indeksi (index - zunanja podatkovna struktura, ki pospeši iskanje)

• kazalci (cursors – kazalci, ki ponujajo hitrejše iskanje v indeksnih datotekah)

• sprožilci (triggers- lahko so omogočitveni, časovni, izvršilni. Omogočitveni

sprožilec je vrsta akcijske omejitve, ki, v kolikor je resnična, dovoljuje obstoj

ujemajočega se objekta. Omejitev je resnična, če objekt obstaja. Časovni sprožilec

je vrsta akcijske omejitve, ki preverja (preizkuša), omogoča/neomogoča, ter

ustvarja oziroma izbriše , če je prag pravilno izpolnjen. Izvršilni sprožilec je

definiran kot vrsta akcijske omejitve, ki povzroči izvajanje ene ali več operacij.

Sprožilci spadajo glede na kategorijo poslovnih pravil med omejitve)

• funkcije (c++ podpora v bazi, ipd..)

• shranjene procedure (stored procedure)

• zunanje rutine (external routine)

• sheme (scheme) - definicija globalne strukture podatkovne baze

• vgnezdeni select stavki (nested select case)

• stabilnost (stability)

• hitrost (speed)

• transakcije (izvedba ažuriranja ene ali več podatkovnih tabel znotraj baze)

• ACID (Atomicity Consistency Isolation Durability, lastnost, ki omogoča, da se

transakcija pravilno dokonča)

• porazdelitev obremenitve (load balancing)

• podatkovne gruče (clustering)

• replikacija (replication)

• sprotno arhiviranje (hot backup)

• varnost (security features)

• avtentikacija (authentication)

• zaklepanje (locking support)


1.4. Kratek opis in zgodovina PostgreSQL

PostgreSQL je objektno relacijska podatkovna baza z dolgo zgodovino. Njeni začetki

segajo v leto 1970, ko so na kalifornijski univerzi Berkeley pričeli z razvojem podatkovne

baze pod imenom Ingres. Relacijska tehnologija je Ingres kmalu obrnila v komercialne

vode, produkt je prevzelo podjetje Computer Associates. Okoli leta 1986 je Michael

Stonebraker na univerzi Berkeley vodil ekipo, ki je relacijski podatkovni bazi »vsadila«

objektno jedro. Novo, objektno relacijsko bazo, so poimenovali Postgres, ki pa je bila

ponovno komercilazirana, kupilo jo je podjetje Illustra (del Informix Corporation). V

sredini 90-let sta Andrew Yu and Jolly Chen dodala bazi SQL podporo. Prejšnja verzija je

namreč uporabljala specifičen poizvedovalni jezik – postquel1. Leta 1996 so dodali še

nekaj dodatnih funkcionalnosti in izboljšav (MVCC transakcijski model, polna podpora

jezika SQL 92). Dobila je tudi novo ime, pod katero jo poznamo danes, to je PostgreSQL

[7].

Danes za izdelavo PostgreSQL skrbi mednarodna skupina za odprto kodno programsko

opremo poznana pod imenom »The PostgreSQL Global Development Group«. Je odprto

kodni produkt, ki ni v nobenem primeru lastniški. Pred časom je Red Hat poskušal ponuditi

bazo v komercialne namene pod imenom Red Hat Database, vendar PostgreSQL ostaja

odpto kodna ter brezplačna podatkovna baza. Trenutno je na voljo že osma različica

PostgreSQL. Po zaslugi mnogih svetovnih podjetij, med njimi so Red Hat, Fujitsu, Afilias,

Software Research Associates, kakor tudi po zaslugi več sto samostojnih razvijalcev,

prinaša različica 8.x veliko novosti. Ena izmed glavnih novosti je gotovo podpora za

Windows okolje, ki bo razširjenost najnaprednejše odprtokodne podatkovne baze še

povečala, tako med uporabniki kot med razvijalci programske opreme. Tako za neodvisne

proizvajalce programske opreme, podjetja in samostojne razvijalce na sistemu Windows,

predstavlja privlačno alternativo komercialnim rešitvam za delo s podatkovnimi bazami.

1 Gre za prilagoditev prvotnega quel jezika iz Ingres


1.4.1. Značilnosti PostgreSQL

Glavne značilnosti PostgreSQL-a:

• podpora na vseh platformah. Podpira tako UNIX, LINUX, MacOS, Windows in še

mnoge druge

• je objektno – relacijska podatkovna baza, kjer je vsaka tabela objekt. Med tabelami

(objekti) je omogočeno enkratno dedovanje. Funkcije in operatorji so polimorfni.

• sintaksa jezika v Postgre SQL je skladna z standardom SQL, SQL92 in večinoma

tudi z SQL 99

• produkt je in bo ostal odprtokoden ne le po uporabi, temveč tudi po tem, da ga je

možno prilagoditi v vse nacionalne jezike

• transakcije podatkov so zaščitene z MVCC (multi-version concurrency control).

MVCC daje še boljše rezultate, kot ostali podobni produkti

• referenčna integriteta Postgre SQL-a vsebuje vse elemente referenčne integritete

vključno z tujimi in primarnimi ključi, ne le tabel, temveč tudi relacij med tabelami

• razširljivost je ena izmed najpomembnejših značilnosti Postgre SQL-a. Tako lahko

sam dodajaš nove podatkovne tipe, funkcije ali operatorje

• PITR (point in time recovery, ki omogoča popolno obnavljanje podatkov iz

samodejno in nepretrgoma arhiviranih dnevnikov transakcij

• replikacijska rešitev Slony

1.5. Primerjava z ostalimi produkti

Primerjavo smo izvedli na osnovi podatkov, ki smo jih pridobili na spletišču [13], [14].

V primerjavo smo ob PostgreSQL vključili še štiri znane komercialne produkte (DB2,

Interbase, MS SQL ter Oracle) ter odprtokodni produkt MySQL. V tabeli so prikazane

lastnosti iz primerjave na prej navedenem spletnem naslovu (tabela 1). Glede na navedeno

lahko rečemo, da v primerjavi z ostalimi, PostgreSQL ne zaostaja za komercialnimi

produkti glede hitrosti, stabilnosti ter mnogih ostalih funkcionalnosti. Glede na to, da je

PostgreSQL odprtokoden in seveda brezplačen, ima na voljo funkcionalnosti, ki so sicer

rezervirane le za plačljive podatkovne baze. Tako je na voljo popolnoma podprt SQL jezik


(standard SQL92, deloma SQL99), na voljo so rešitve iz komercialnih produktov kot so

referenčna integriteta, transakcije, ACID tehnologija, kazalci, sprožilci ter zunanje

procedure, še več, podpira tudi vse pogosto znane operacijske sisteme (Windows, Linux,

BSD, Unix, MAC Os). Ima tudi vse varnostne in zaščitne mehanizme, ki jih podatkovna

baza mora imeti. Tu mislimo predvsem na avtentikacijo, avtorizacijo, funkcionalnost

»ACID«, vodenje dnevnika transakcij, sprotno arhiviranje ter replikacijo, ki je značilna za

porazdeljene podatkovne baze. Zaostaja pa pri povezljivosti s programskimi orodji kot so

Visual Studio, Delphi, Eclipse, TIBCO. Povezljivost za okolje .NET je na voljo s pomočjo

odprto kodnih komponent Npgsql, dobimo pa tudi plačljive dodatke, ki so nekoliko bolj

dodelani.

Glede na vse omenjeno lahko zaključimo, da je PostgreSQL gotovo najboljša

odprtokodna podatkovna baza, ki lahko v povezavi z ostalimi odprotokodnimi produkti,

kot so operacijski sitem Linux, nekatera programerska orodja, ki podpirajo jezik PHP,

Java, ter spletnim strežnikom Apache, tvori osnovo za delovno okolje vsakega podjetja ali

kakšne druge organizacije. Res pa je, da je za komercialne produkte na voljo veliko več

organiziranih tečajev za delo s produkti, veliko več literature ter raznih dodatkov, ki pri

vpeljavi nove tehnologije v podjetje jeziček na tehtnici pogosto prevalijo na stran

komercialnih produktov.


tabela 1: primerjava produktov – povzeto po [18], [19]

DB2

InterBase

MS SQL

Podjetje IBM Borland Microsoft MySQL AB

Oracle

Corporation

PostgreSQL

Global

Development

Group

Datum izdelave 1982 1985 1989 1996 1979 1989

Zadnja verzija 9 7.5.1 9.00.3042 5.0 10g, release2 8.2.3

Osnovne

Informacije

Licenca Plačljiva Plačljiva Plačljiva GPL ali Plačljiva Plačljiva BSD

Windows Da Da Da Da Da Da

Mac Osx Ne Ne Ne Da Da Da

Linux Da Da Ne Da Da Da

BSD Ne Ne Ne Da Ne Da

OS

UNIX Da Da Ne Da Da Da

ACID Da Da Da Da Da Da

Referenčna integriteta Da Da Da Da Da Da

Transakcije Da Da Da Da Da Da

Glavne

značilnosti

Unicode Da Da Da Partial Da Da

Začasne tabele Da Da Da Da Da Da Tabele in

pogledi Pogled Da Ne Da Ne Da Ne

R-/R+tree Ne Ne ? MyISAM EE edition Da

Hash ? Ne Non/Cluster Ne Cluster tables Da

Izrazi Ne Ne Da Ne Da Da

Delne particije Ne Ne Da Ne Da Da

Referenčnost Da Ne Da Ne Da Da

Slike Da Ne Ne Ne Da Da

Indeksi

GiST Ne Ne Ne Ne Ne Da

Domene Ne Da Da Ne Da Da

Kurzorji Da Da Da Da Da Da

Sprožilci Da Da Da Da Da Da

Funkcije Da Da Da Da Da Da

Procedure Da Da Da Da Da Da

Drugi

objekti

Zunanje metode Da Da Da Da Da Da

Range Da Ne Da Da Da Da

Hash Da Ne Ne Da Da Da

Composite

(Range+Hash) Da Ne Ne Da Da Da

Particije

List Da Ne Ne Da Da Da


2. VARNOST PODATKOV V PODATKOVNIH BAZAH

2.1. Kratek opis problema varnosti v podatkovnih bazah

S pojmom zaščite in varovanja podatkov se človeštvo srečuje že veliko časa. Tako so

zaščito podatkov poznali že v Egiptu pred 4000 leti. Pomen zaščite in varovanja

informacij, podatkov se poveča dodatno še v vsaki vojni. V današnjem času je varnost

podatkov aktualna na vseh področjih. Vse več govorimo o varovanju osebnih podatkov,

varovanju tehnoloških podatkov, varovanju podatkov, ki so nujni za nacionalno varnost,

ipd. V nalogi se bomo omejili na varnost podatkov shranjenih v podatkovnih bazah.

Pojem varnosti lahko opišemo z nalogami zaščite in varovanja kot so [4]:

• zaupnost (samo pooblaščene osebe smejo videti zaščitene podatke)

• celovitost (celovitost ali integriteta pomeni, natančnost, točnost, nespremenjenost2)

• razpoložljivost (pomeni prisotnost objektov ali storitev v uporabni obliki,

zadovoljive kapacitete za opravljanje storitve, omejen čas čakanja, zadovoljiv

odzivni čas)

Da zadovoljimo varnosti, je potrebno izvajati ukrepe zaščite pred [4]:

• naravnimi nesrečami (potresi, požar, poplave)

• vsiljivci (kraja, poškodba opreme, kršitev tajnosti, vpogled v občutljive podatke)

• nepooblaščenim dostopom

• ostalimi podatkovnimi nesrečami (virusi, napake v strojni opremi, napake v

programski opremi, človeške napake)

Osnovni namen zaščite podatkovne baze je zaščita pred grožnjami z uporabo

tehničnega in administrativnega nadzora. Grožnje zaščiti podatkovne baze prihajajo iz

različnih virov:

2 Dovoljena je sprememba s strani pooblaščenega uporabnika s pooblaščenimi procesi in po sprejemljivih poteh


• fizično okolje (varno okolje za datoteke, procese in opremo, varno pred sevanjem)

• zunanje procedure (zaščita pri posamezniku, zaščita gesel, nadzor aplikacijskih

programov)

• shranjevanje podatkov (kodiranje in prikrivanje podatkov, rezervne kopije)

• programska oprema (nadzor dostopa, napad na transakcije)

• procesor (zaščita pomnilnika, stanje privilegija, zanesljivost delovanja)

• komunikacije (prikrivanje podatkov med prenosom)

Problem varnosti podatkovne baze v podjetjih lahko razdelimo na dva velika sklopa:

• varnost v spletnem poslovanju (zunaj – med podjetji, organizacijami)

• varnost v okviru zaključene celote, to je v zaprtem okolju (znotraj podjetja,

organizacije)

2.1.1. Varnost v spletnem poslovanju (med podjetji)

Varnost je najbolj zaskrbljujoč parameter pri selitvi poslovanja v svetovni splet, zato

bomo v nadaljevanju izpostavili nekatere principe, ki vodijo k varnejši, če že ne popolno

varni, izmenjavi podatkov. Pri nekaterih objektnih jezikih (npr. Java) za varnost skrbi

upravitelj varnosti. Implementirajo ga različna podjetja, ki izdelujejo Java navidezne stroje

(pogosto gre za pregledovalnike). Vanj je vgrajen določen varnostni vzorec, ki apletom3 s

proženjem izjeme in zaustavitvijo izvajanja, preprečuje nedovoljene aktivnosti (dostop do

lokalnih zbirk, povezavo s poljubnim spletnim strežnikom, uporabo različnih protokolov,

klice metod drugih programskih jezikov, itd.). Nekaj več svobode lahko ponudimo

zaupanja vrednim apletom. To dosežemo z uvedbo digitalnega podpisa.

Digitalni podpis temelji na enkripciji podatkov s pomočjo ključa. Ključ je podatek, ki

ga uporabimo pri pretvorbi začetnih podatkov v obliko, ki je nerazumljiva (šifrirana). Če

želimo ponovno prvotno obliko podatkov, potrebujemo isti ali nek drug ustrezen (ne

katerikoli) ključ. Z njim podatke dešifriramo. V ta namen je razvitih več postopkov.

Digitalni podpis temelji na postopku uporabe javnega ključa (angl. public key encryption).

3 aplet je javanski program, ki teče znotraj brskalnika. Je del določene spletne strani in se na računalnik naloži ob odpiranju strani. Za aplet veljajo določene varnostne omejitve, da onemogočimo morebitno škodo.


Postopek je sledeč: uporabnik si ustvari dva ključa. Prvi se imenuje javni, drugi pa

privatni. Privatni ključ dešifrira podatke šifrirane z javnim ključem. Javni ključ je dobil

ime na podlagi njegove uporabe. Uporabnik namreč le tega javno objavi (prenese ga na

ustrezen temu namenjen strežnik) in s tem omogoči vsem, ki mu želijo poslati podatke

njegovo uporabo. Podatke šifrirane z javnim ključem dešifrira privatni ključ. Z javnim

ključem lahko podatke samo šifriramo. Prav tako je iz javnega ključa praktično nemogoče

dobiti privatni ključ.

Tehniko javnega ključa lahko uporabimo za podpisovanje apletov. Postopek je sledeč:

z uporabo privatnega ključa izdelamo digitalni podpis, ki temelji na določenem apletu.

Uporabnik, ki želi preveriti verodostojnost tega apleta, potrebuje originalni aplet, digitalni

podpis, ki temelji na tem apletu in javni ključ uporabljenega privatnega ključa. Z uporabo

javnega ključa lahko preverimo, ali se podpis in aplet ujemata.

Uporaba zgolj digitalnega podpisa ima vrzeli, ki se lahko zaradi uporabe protokola http

manifestirajo v obliki zlorab. Primer tega je lažno predstavljanje, kjer naslovimo spletni

strežnik, ki se predstavlja kot drug spletni strežnik. Uporaba varnega protokola (npr. SSL –

angl. Secure Sockets Layer Protocol) in s tem strežnika, ki tak protokol podpira, nam

tovrsten problem odpravi. Zagotovi nam avtentičnost strežnika, podatke pa pred

pošiljanjem samodejno šifrira. Šifriranje se vrši na nivoju protokola. Za varno poslovanje

moramo tudi pri apletih temeljiti na varnem protokolu. Za doslednost pri uporabi

protokolov poskrbi upravitelj varnosti, ki ne dopušča uporabe različnih protokolov znotraj

apleta. Praktično to pomeni, da moramo aplet naložiti s protokolom https, če želimo, da

aplet pošilja podatke po tem protokolu torej šifrirane. Omejitev je v tem primeru logična.

Če želimo varno pošiljanje podatkov, moramo tudi sam aplet naložiti s pomočjo protokola,

ki ne dopušča poneverb. Protokol SSL [3] je v takšnem primeru vgrajen v spletni strežnik

oziroma pregledovalnik, zato je dovolj, če aplet pri komunikaciji uporabi razred URL.

2.1.2. Varnost v okviru zaključene celote (znotraj podjetja)

Na spletnih straneh Computer World-a [8] so poročali, da se 80 odstotkov vdorov v

podatkovne baze izvrši od zunaj, kar pomeni, da je v 20 odstotkih možno, da v bazo

podatkov vdre zaposleni v (napadenem) podjetju. Tveganje, da ukradene podatke

posamezniki zlorabijo, se ne more izničiti. »Posledično s tem, je to eden največjih virov


podatkov varnostne ranljivosti in ena največjih nevarnostih, proti kateri se podjetja le

stežka zavarujejo.«

Če upoštevamo dejstvo, da administrator podatkovnih baz upravlja s programsko

opremo za upravljanje s podatkovnimi bazami in odloča o načinih organizacije in shrambe

vseh občutljivih podatkov, bi lahko bil on popoln vohun, ki bi kopiral ali uporabljal

podatke o podjetju, zaposlenih ali o strankah, v škodoželjne namene. Že preprosta

nemarnost, namerna ali nenamerna, lahko podjetju povzroči obilo preglavic in škodo. Nek

uslužbenec, ki ima običajen dostop do podatkov, bi lahko določene podatke spravil na svoj

prenosni računalnik in ga nesel na poslovno potovanje ... kaj bi se zgodilo v primeru, če bi

prenosnik ukradli, ali če bi ga uslužbenec kje pozabil in bi bili podatki na voljo vsem?

Tovrstnih prevar ni lahko odkriti, še posebej ne tistih, ki prihajajo od znotraj. Vseeno pa je

sedaj na voljo programska oprema, s pomočjo katere lahko varujemo podatke pred

notranjimi grožnjami (Protegrity, Ingrian Networks,...)

Vidimo, da so poleg vdorov od zunaj zelo pogosti vdori od znotraj na račun

pomanjkljivega fizičnega varovanja računalniške opreme ali slabega izkoriščanja

varnostnih možnosti, ki so v okviru podatkovne baze. Prepogosto se dodeli uporabnikom

kar administratorske pravice nad celotno podatkovno bazo ali celo nad celotnim SUPB. Tu

imamo veliko možnosti: od definiranja shem (shema je posamezni imenski prostor znotraj

podatkovne baze), dodelitve uporabniških računov in gesel uporabnikom, definiranja

minimalnih pravic pri delu s podatkovno zbirko.

2.1.3. Izguba podatkov

Podjetje Hitachi, proizvajalec trdih diskov in shranjevalnih rešitev, je v okviru svojih

rednih raziskav (Hitachi Data Systems Storage Index 2004) [23] [24] naredilo anketo med

840 vodji informatike v 21 državah območja EMEA (Europe, Middle East and Africa) in

ugotovilo, da jih 81% enači pojem dostopnosti podatkov (angl. data availability) s pojmom

neprekinjenega poslovanja (angl. business continuity). To vsekakor jasno kaže, da

zanesljiv dostop do podatkov v vsakem trenutku pogojuje uspešno poslovanje podjetja. Če

lahko sodimo po rezultatih raziskave o izgubi podatkov v Evropi, bo vsaj 6% osebnih


računalnikov utrpelo izgubo podatkov v enem izmed naslednjih let, kar predstavlja 1,7

milijona "incidentov".

Stanje naj bi bilo precej podobno tudi v ZDA in drugod po svetu. Hitachi navaja nekaj

glavnih razlogov za izgubo podatkov:

• strojna okvara, vključno z okvarami zaradi prenapetosti in odpovedi trdih diskov

(42%);

• človeške napake, kar vključuje pomotoma izbrisane datoteke, neizvajanje ali

napačno izvajanje arhiviranja ipd. (31%);

• programska napaka, napake v programski kodi, ki imajo za posledico

nekonsistentne podatke ali njihovo brisanje (13%);

• virus (raziskava varnostnega podjetja ICSA.NET je pokazala, da je kar 40%

podjetij prijavilo izgubo podatkov zaradi virusov);

• kraja, še posebej kraja prenosnih računalnikov (5%);

• uničenje infrastrukture (poplave, požari, udari strele in prenapetosti, skupaj 3%)

2.1.3.1. Kakšna je (lahko) škoda?

Pri posameznem primeru reševanja podatkov po takšnih incidentih se običajno zgodi

ena od dveh "robnih" možnosti: uspešno povrnemo podatke ali pa jih izgubimo za vedno.

K sreči je po izjavah strokovnjakov podatke možno povrniti v približno 80% vseh

primerov, seveda za določeno ceno [24]. Tako naj bi na primer delo internega strokovnjaka

v podjetju podjetje stalo okrog 30 € na uro, povrnitev podatkov pa naj bi v povprečju

trajala 6 ur, kar torej znese 180 €. Vpoklic pomoči od zunaj pa naj bi ta strošek podvojil,

povprečni znesek torej naraste na 360 €. Že zgoraj omenjene številke niso majhne, še večji

strošek pa predstavlja izguba zaradi nižje produktivnosti uporabnikov, kar vpliva na

prodajo in dobičkonosnost. Nižja produktivnost pomeni v povprečju 25 € na uro, kar v

primeru 6-urnega nedelovanja doda 150 € k stroškom reševanje problema.

Ne pozabimo, to je bila optimistična možnost, ko nam je uspelo izgubljene podatke

povrniti. Kot smo omenili zgoraj, pa je približno 20% primerov reševanja neuspešnih.

Stroški lahko v takem primeru dosežejo vrtoglave vsote. Običajno v teh primerih posežejo

po edini preostali možnosti, to je ponovno ustvarjanje podatkov, kar zahteva več sto ur


človeškega dela. Tega pa večkrat, posebej kadar gre za izgubo raziskovalnih ali

zgodovinsko pomembnih podatkov, sploh ni možno izvesti. Podobno velja tudi za podatke,

ki jim pravimo intelektualni kapital podjetja, kot so npr. podatkovne baze in baze znanja.

Nekateri viri navajajo, da lahko povprečna vrednost 1 MB poslovno pomembnih podatkov

presega 10.000 €.

Torej lahko ocenimo stroške, ki nastanejo pri takšnem incidentu, ki mu pravimo

reševanje izgubljenih podatkov. Znesek 500 € je povprečen strošek reševanja v primeru

uspešne povrnitve. Kot rečeno so stroški ob popolni izgubi nepredvidljivi, a vsekakor

izjemno visoki, zato lahko kakšno podjetje pripeljejo tudi na rob prepada.

Izguba podatkov evropska podjetja vsako leto stane 4 milijarde evrov, kar pa ne

vključuje stroškov izgube strank, izgube iz poslovanja, izgube tržnega deleža in stroškov

zaradi nenadne neusklajenosti z zakoni, do katere lahko pride ob izgubi določenih

elektronskih dokumentov ali obrazcev. Človeški dejavnik pri izgubi podatkov je zelo

pomemben. Nešteto primerov obstaja, ko so nezadovoljni, odpuščeni ali kako drugače

jezni sodelavci podjetju ali organizaciji povzročili ogromno škodo z namernim uničenjem

ali poškodovanjem podatkov.

2.1.4. Nekonsistentnost podatkov

Nekonsistentnost podatkov je stanje, ko podatkovna baza izgubi celovitost v smislu

enovitosti podatkov. Podatki se pri tem podvajajo, izgubljajo, lahko le povezave med njimi

- »padajo ključi«. V tem primeru govorimo tudi o podatkovni nesreči. Do tega lahko pride

zaradi:

• v primeru izpada komunikacijskih povezav med porazdeljenimi podatkovnimi

bazami (rešitev je ustrezno načrtovanje omrežja - vzpostavitev vzporednih poti)

• slabe dokumentiranosti podatkovne baze, posledično slabo načrtovanje aplikacij

• problem programske napake, napake v programski kodi,

• heterogeni sistemi uporabljajo podatke v različnih formatih, posledica je podvajanje

podatkov

• načrtovanja informacijskega sistema na »tradicionalen način« (razvoj se

osredotoča na posamezne aplikativne segmente, ne upošteva pa se problematika


razvoja podjetja kot takega. Programske rešitve so ponavadi med sabo operativne

neodvisne )

V primeru, da pride do podatkovne nesreče, je potrebno PB obnoviti. Obnavljanje PB

je v domeni SUPB, ki poteka pod nadzorom upravitelja PB. V namen zagotavljanja

konsistentnosti podatkov se lahko uvede dvojna PB. V primeru, da pride do izpada ene PB,

se lahko ta nadomesti z drugo, kajti diskovna kontrolna enota izpisuje sočasno podatke na

dva fizično ločena diska (se izplača za zelo velike PB, saj olajša delo upravitelja SUPB).

Tovrstna zaščita je precej draga in zato mnogokrat uporabljajo metodo kopiranja.

2.1.5. Okrevalni načrt

Backup4 je dober le toliko, kolikor je dobro restavriranje podatkov. Le to dosežemo z

izdelavo okrevalnih načrtov. Okrevalni načrt ali DRP (angl. Disaster Recovery Plan) je del

procesa, ki omogoča hitro vzpostavitev prvotnega stanja IS. Okrevalni načrt opisuje

postopek, pri katerem element informacijskega sistema (operacijski sistem in druge

programske rešitve) restavriramo iz varnostne kopije, po možnosti na drugi lokaciji in na

drugi strojni opremi (sicer ista platforma, drugačno diskovje, drug model strežnika). Pri

tem se natančno dokumentirajo vsi koraki, potrebni za ponovno vzpostavitev sistema, iz

katerih nastane podrobna dokumentacija, ki opisuje vsa opozorila, ukaze in pasti na katera

lahko naletimo v primeru kritičnih napak in s tem restavriranje celotnega operacijskega

sistema in programskih produktov.

2.2. Zaščita podatkovne baze

Varnost podatkovne baze se odraža skozi zaščito pred grožnjami z uporabo tehničnega

in administrativnega nadzora. Grožnje zaščiti podatkovne baze prihajajo iz različnih virov:

• fizično okolje (varno okolje za datoteke, procese in opremo, varno pred sevanjem)

4 Backup je proces ki opravi hranjenje podatkov na druge medije


• zunanje procedure (zaščita pri posamezniku, zaščita gesel, nadzor aplikacijskih

programov)

Varnost se odraža (povečuje/zmanjšuje=rezultira) skozi različne ukrepe, predvsem pa

se je potrebno posvetiti varnosti in zaščiti podatkovne baze v fazi načrtovanja podatkovne

baze (analiza tveganja, lastnosti okolja v katerem bodo umeščene podatkovne baze),

implementacije (nevidnost podatkov pred vsiljivci, preprečevanja izmikanja varnostnim

mehanizmom, varnostno testiranje) ter izdelavi različnih varnostnih zahtev in politik

varovanja s področja sistemskega varovanja, varovanja podatkov, zapisovanje dnevnikov

pristopa, transakcij, ipd.

Če želimo, da podatkovna baza zaživi v realnem življenju, mora imeti poleg

funkcionalnosti, kot so varnost, zanesljivost, visoko razpoložljivost, dostopnost,

učinkovitost, tudi ustrezen nadzor nad podatkovnimi bazami. To omogoča sistem za

upravljanje s podatkovnimi bazami (SUPB).

2.2.1. Nadzor dostopa

Varnost (angl. security) pomeni, da so podatki varni pred vsiljivci ter ostalimi

nepoklicanimi uporabniki. Tako je potrebno zagotoviti, da samo pooblaščeni (avtorizirani)

uporabniki podatkovne baze lahko počnejo v bazi to, kar je potrebno in nič več.

Začnimo kar z največjo grožnjo varnosti podatkovne baze, ki jo predstavljajo

uporabniška imena, ki so del standardne namestitve in imajo gesla enaka uporabniškim

imenom, oziroma so njihova gesla javno znana, kot je na primer uporabniško ime SYS,

SYSTEM, ROOT, POSTGRES (ime baze). Namestitvene procedure nekaterih

programskih produktov že zahtevajo od uporabnika svoje geslo, oziroma so ta uporabniška

imena in gesla onemogočena. Začne se torej že ob namestitvi, nadaljuje pa se ob odpiranju

novih uporabnikov, ki imajo geslo največkrat enako uporabniškemu imenu. Če nekomu

uspe dobiti seznam uporabnikov, kar hitro najde nekega uporabnika, ki ima dovolj pravic,

da lahko začne svoj uničevalni pohod po podatkovni bazi. Vidimo, da je politika gesel za

podatkovno bazo ravno tako pomembna kot kakšen drug del sistema [16].


Na drugo mesto bi lahko postavili neustrezne, prevelike uporabniške pravice. Številni

programski paketi, ki niso dovolj premišljeno zasnovani, zahtevajo določene uporabniške

pravice, brez katerih bi lahko sicer ravno tako delovali, vendar bi bilo potrebno več

administracije in predvsem drugačen pristop od začetka razvoja aplikacije. Na tem mestu

se moramo zavedati, da je najprimernejša strategija dodeljevanja minimalnih pravic

oziroma zgolj tistih, ki jih uporabnik zares potrebuje za svoje redno delo.

Učinkovit nadzor dostopa do podatkovne baze lahko dosežemo skozi:

• ustrezno dodeljevanje uporabniških imen ter gesel uporabnikom (minimalne

pravice)

• ustreznega definiranje baz, shem ter dostopov do njih (pravilno načrtovanje

podatkovne baze)

• definiranje pravic dela nad podatkovnimi tabelami

• enkripcijo podatkov med odjemalcem in podatkovno bazo

• beleženjem dostopov do podatkov ter vrste transakcij (log file)

2.2.1.1. Avtentikacija

Avtentikacija je proces, v katerem se mora strežnik prepričati, da je uporabnik res tisto,

kar trdi, da je. Opravi se preko vnosa uporabniškega imena in gesla uporabnika, ali

uporabe digitalnih potrdil. Avtentikacija se opravlja na nivoju operacijskega sistema ali

podatkovne baze.

Običajna ranljivost statičnih gesel so dobre poznane, še več, gesla že od nekdaj veljajo

za neučinkovito metodo overjanja identitete. Vse več sistemov tako uporablja varnostni

sistem, ki generira enkratno kodo. Koda se generira v posebnem ključu in jo je mogoče

uporabiti le enkrat. Uporabnik tako vnese kodo skupaj s njegovo osebno PIN številko

(pozna jo le uporabnik), v prijavno okno, s čimer je postopek avtentikacije zaključen.

Na tržišču je kar nekaj takšnih rešitev (SafeWord, RSA SecurID,...), ki so vključene v

omrežne produkte kot so Citrix, Nortel Networks, ...


2.2.1.2. Avtorizacija

Z avtorizacijo določimo do katerih delov aplikacij in do katerih programskih funkcij je

uporabniku odobren dostop in kakšen je nivo dostopa. Avtorizacija se vrši na dveh nivojih,

in sicer:

• na nivoju skupine uporabnikov ali

• na nivoju uporabnika.

V primeru spremembe pravic skupine, se pravice spremenijo tudi uporabniku v okviru

te skupine.

Avtorizacija v podatkovni bazi je postopek, ko strežnik ugotavlja do katerih

podatkovnih zbirk in objektov ima določen uporabnik dostop. Strežnik MS SQL podpira

dva načina verifikacije uporabnikov: avtentikacijo Windows in avtentikacijo SQL

(poseben način, pri katerem se geslo prek omrežja prenese v prikriti obliki). Tudi ostale

podatkovne baze izvajajo avtorizacijo na podoben način.

2.2.1.3. Enkripcija

Enkripcija ali šifriranje je proces v kriptografiji, pri katerem se izvede zamenjava

znakov v sporočilu, tako, da sporočilo, informacija postane nečitljiva za nepooblaščene

osebe oziroma osebe, ki nimajo ustreznega ključa za dešifriranje.

Enkripcija je torej prikrivanje, postopek pri katerem odprto sporočilo spremenimo v

prikrito. Z enkripcijo varujemo podatke pred nezaželenimi vpogledi. Največkrat se

uporablja enkripcija pri prenosu podatkov, sporočil, uporablja pa se tudi v druge namene

(na primer pri zavarovanju podatkov na medijih kot so diski, USB ključi, ipd; zavarovanju

podatkovnih baz, ipd.)

V primeru podatkovnih baz se uporabljajo različni mrežni protokoli za komunikacijo

med strežnikom in odjemalcem. Eden izmed mrežnih protokolov, ki uporablja enkripcijo,

je Kerberos. Kerberos je mrežni avtentikacijski protokol za zagotavljanje varne povezave

med odjemalcem in strežnikom. Kerberos nudi močno avtentikacijsko zaščito, ki temelji na


kriptografiji z uporabo skritega ključa. Kerberos so razvili 1988 na Massachussets Institute

of Technology (MIT) v okviru projekta Athena. Poznane so še druge metode enkripcije kot

so SHA1, MD5, SSH,...

Ena izmed rešitev zaščite in varovanja podatkovnih baz je tudi enkripcija ali šifriranje

vseh občutljivih podatkov. Šifriranje podatkov je rešitev, seveda pa priporočamo uporabo

pripomočkov tretje osebe od prodajalcev kot na primer Protegity ali Ingrian Networks saj,

če šifriranje opravi podatkovni stroj, ima administrator dostop do ključa in če administrator

res krade podatke, ga šifriranje zagotovo ne bo ustavilo.

Po drugi strani pa, če bodo ključi shranjeni v podatkovni bazi in če postanejo

pokvarjeni, bo obnovitev podatkov izredno težka. »Šifriranje tretje osebe onemogoči

administratorju dostop do ključev, kar omogoči, da se odgovornost porazdeli med

upravljanje in varnost podatkovne baze. Rešitev vključevanja tretje osebe drži ključ stran

od podatkovne baze in vsebuje napredno upravljanje s ključem, kar omogoči lažjo obnovo

podatkov v primeru, da se ključi pokvarijo.«

2.2.1.4. Uporabniške skupine

Uporabniške skupine se definirajo z namenom ustvariti pravice dostopa do podatkov za

skupine uporabnikov. Uporabniki so vsi, ki kakorkoli uporabljajo podatkovno bazo (slika

4.). Delimo jih na neposredne in posredne uporabnike ter upravitelje podatkovne baze.

Neposredni uporabniki komunicirajo s podatkovno bazo preko terminalov ali delovnih

postaj, posredni pa le okvirno podajajo svoje podatkovne zahteve, njihovo izvedbo pa

prepuščajo neposrednim uporabnikom. Neposredni uporabniki so končni uporabniki ali

programerji. Končni uporabniki podatke v podatkovno bazo vnašajo s pomočjo vnaprej

pripravljenih vnosnih mask ter jih pregledujejo z vnaprej pripravljenimi poročili (reports)

oziroma s pomočjo povpraševalnega jezika (SQL). Programerji predstavljajo servis

končnim uporabnikom. Glede na dodeljene pravice spreminjajo strukturo podatkovne baze,

pripravljajo vnosne maske, poročila ter nasploh omogočajo uporabnikom čim lažjo ter

funkcionalno uporabo podatkov.


Neposredni uporabniki

Upravitelj PB

Končni uporabniki

Programerji

Menijsko vodeni

uporabniki

Aplikacijski programerji

Sistemski programerji

Posredni uporabniki

Parametrični uporabniki

Uporabniki povpraševaln

ega jezika

uporabniki

slika 1: delitev uporabnikov, povzeto po [25]

Upravitelj podatkovne baze (lahko jih je več) ima množico zadolžitev, ki jih je potrebno

izvajati, da se zagotovi razpoložljivost, celovitost in uporabnost podatkov v podatkovni

bazi. Naloge upravitelja:

• definiranje ter ažuriranje notranje, konceptualne ter zunanjih shem;

• kreiranje in inicializacija fizične podatkovne baze;

• skrb za razvoj in vzdrževanje programskih orodij za podporo končnim

uporabnikom in uporabniškim programerjem;

• skrb za zaščito podatkovne baze pred nesrečami in njeno obnavljanje po nesrečah;

• definiranje postopkov za vzdrževanje kvalitete podatkovne baze;

• vzdrževanje sistema gesel in pristopnih dovoljenj za uporabnike;

• nadzorovanje zmogljivosti in uporabe podatkovne baze ter izvajanje ustreznih

reorganizacij in prilagoditev;

• pomoč uporabnikom pri planiranju in uporabi podatkov ter uporabi programskih

orodij, ki so na voljo v okviru SUPB;

Te naloge lahko opravlja ena ali več oseb ob podpori SUPB. Nekatere naloge (npr.

kreiranje shem) lahko v nekaterih okoljih opravljajo tudi končni uporabniki.


2.2.2. Zaščita pred nekonsistentnostjo podatkov

Delo v podatkovni bazi mora biti pregledno, transparentno. Podatkovne baze ponujajo

v okviru produkta različne rutine, ki zagotavljajo transparentnost, zanesljivost ter seveda s

tem tudi konsistentnost podatkov. Podatkovna baza tako mora izpolnjevati / zagotavljati

lastnosti kot so: zanesljivost, razpoložljivost ter učinkovitost.

Zanesljivost (angl. reliable) pomeni, da je možnost vpogleda v podatke zanesljiva brez

morebitne izgube. Vsaka transformacija podatkovne baze mora biti pričakovana ne

naključna. Razpoložljivost, dostopnost (angl. availability) pomeni, da je podatkovna baza

na voljo, ko jo potrebujemo. S tem ko se uporabnik prijavi v podatkovno bazo pričakuje,

da so mu podatki na voljo v realnem času. Učinkovitost (angl. performance) pomeni, da

uporabnik učinkovito izvaja zahtevane operacije v sprejemljivem, to je v kratkem

odzivnem času.

2.2.2.1. Transakcije, ACID

Transakcija je definirana kot množica akcij, ki pripadajo enemu uporabniku ali

aplikaciji podatkovne baze, ter so nedeljiva celota. Transakcija ima štiri lastnosti in sicer

nedeljivost (angl. Atomicity), veljavnost (angl. Consistency), neodvisnost (angl. Isolation)

ter trajnost (angl. Durability). Funkcionalnost srečamo tudi pod okrajšavo ACID [17]. Je

lastnost podatkovne baze, ki omogoča, da se vsaka transakcija v podatkovni bazi izvede

zanesljivo. Atomicity oziroma nedeljivost označuje pojem, s katerim opišemo pravilo »vse

ali nič«. Vsaka transakcija v podatkovni bazi je nedeljiva in lahko samo popolnoma uspe,

ali pa ne uspe, kar pomeni, da bodo uspele vse spremembe hkrati ali pa nobena.

Consistency oziroma konsistentnost zagotavlja, da je stanje v podatkovni bazi pred in po

transakciji stabilno in da pravila niso porušena. Kadar poskusimo izvršiti transakcijo, s

katero porušimo pravila, ki veljajo v podatkovni bazi, transakcija ne sme uspeti, stanje pa

mora ostati enako, kot je bilo pred njo. V primeru, da transakcija uspe, morajo vse

spremembe postati vidne naenkrat in ne vsaka posebej. Govorimo, da je podatkovna baza

veljavna pred in po izvedeni transakciji. Isolation oziroma izolacija, neodvisnost, nam

zagotavlja, da si transakcije, ki tečejo paralelno in delujejo nad fizično istimi podatki, ena

drugi ne spreminjajo podatke. Durability oziroma trajnost nam zagotavlja da, ko dobi


uporabnik potrditev uspešnosti transakcije nad podatki, bo transakcija izvršena in ni

mogoča njena zaustavitev. Ponavadi se transakcija zapiše v log file, ki omogoča, da se

transakcija izvede tudi ob nenadni prekinitvi delovanja (angl. system failure).

Transakcija označuje enoto za interakcijo s podatkovnim sistemom, v okviru katere se

zgodi ena ali več interakcij. Transakcija se drži ACID načel in na tak način omogoča

integriteto podatkovnega sistema. Transakcija se zaključi (angl. commit) ali ne

(angl.abort). Transakcije se izvajajo zaporedno ali sočasno.

Transakcije prav tako zagotavljajo, da se lahko posamezne operacije na podatkovni

bazi med sabo povežejo v neko celoto, ki uspe ali ne uspe v enem koraku in za sabo pušča

konsistentno stanje. Danes transakcija za delovanje tipično uporablja »two phase commit«

protokol. Ta protokol zagotavlja, da se vse strani, ki nastopajo v neki transakciji, najprej

dogovorijo, ali je transakcija uspela ali ne, šele nato se zgodi dejanski zapis. To pomeni, da

kadar ena izmed operacij ne uspe, vse ostale pa, se transakcija označi kot neuspela. Seveda

spremembe ne bodo potrjene in vidne v podatkovni bazi. To se bo zgodilo samo, kadar se

bodo vse strani strinjale, da je transakcija uspela.

Kadar govorimo o transakcijah, velikokrat naletimo na naslednje pojme:

• povrnitev v prvotno stanje (angl. Rollback) je proces, ki zagotavlja, da v primeru,

ko transakcija ni bila uspešno zaključena, povrnemo stanje podatkovne baze na

prejšnje stanje.

• povrnitev naprej (angl. Rollforward) je proces, ki zagotavlja, da lahko v primeru

okvare podatkovne baze, le-to restavriramo na točko pred okvaro tako, da ponovno

izvršimo transakcije, ki so že bile izvršene. V primeru okvare, podatkovno bazo

ponavadi obnovimo na neko prejšnjo točko (npr. na včerajšnje stanje). Nato s

pomočjo procesa povrnitve naprej ponovno izvršimo že izvršene transakcije in tako

pridemo na stanje, ki je bilo pred napako. Ponavadi se takšen proces ne izvaja

ročno, ampak s pomočjo orodij, ki jih ponuja podatkovna baza.

• smrtni primež-mrtva zanka (angl. Deadlock) je stanje, ki nastopi, kadar transakcije

čakajo ena drugo, da se dokončajo in sprostijo zapise v tabelah, nad katerimi

delujejo. Na primer, da imamo v sistemu dve transakciji T1 inT2. Prva transakcija

(T1) se bo izvedla na podatku A in nato na podatku B. Druga transakcija (T2) se bo

izvedla najprej na podatku B in nato na podatku A. Če se obe transakciji sprožita

hkrati, potem transakcija T1 zaseže podatek A in transakcija T2 zaseže podatek B.


Sedaj poskuša transakcija T1 zaseči podatek B, vendar mora počakati, da ga

transakcija T2 sprosti. Hkrati pa poskuša transakcija T2 zaseči podatek A, ki ga je

že zasegla transakcija T1. Ta čaka, da transakcija T2 sprosti podatek, transakcija T2

pa čaka, da transakcija T1 sprosti podatek. Medsebojno čakanje transakcij, da

sprostijo podatke, je pogost problem, ki se pojavlja pri zaseganju podatkov. Sistem

za upravljanje s podatkovno bazo mora poskrbeti za ugotavljanje in reševanje

zaseganj, pri katerih lahko pride do mrtve zanke (slika 5.). Za ugotavljanje, ali je

prišlo do mrtve zanke, se najpogosteje uporabljajo grafi »čaka-na« (wait-for

graphs) ali Petrijeve mreže [12].

Podatek A

Podatek B

Transakcija T1 Transakcija T2

zasežen

zaseženČaka na

Čaka na

slika 2: primer enostavne mrtve zanke

Sistem za upravljanje s podatkovno bazo ugotovi, da je prišlo do mrtve zanke, ko najde

cikel v grafu »čaka-na«. Takrat lahko eno izmed transakcij prekine, razveljavi vse njene

akcije in jo izvede kasneje. S tem drugim transakcijam omogoči izvajanje brez nastopa

mrtve zanke.

Poznamo več tipov transakcij:

• distribuirane transakcije (angl. Distributed transactions) so transakcije, ki delujejo

nad več izvori podatkov (npr dveh podatkovnih bazah). Sistemi, ki podpirajo

distribuirane transakcije, so zelo kompleksni. Verjetno najbolj znani sistem za

podporo distribuiranim transakcijam je MS COM+.


• vgnezdene transakcije (angl. Nested transactions) so transakcije, ki se zgodijo

znotraj že obstoječe transakcije. Najbolj pomembno je to, da spremembe v

vgnezdeni transakciji niso vidne, dokler ni potrjena glavna transakcija.

• dolgotrajne transakcije (angl. Longrun transactions) so transakcije, ki potrebujejo

dlje časa, da se zaključijo. Za razliko od navadnih transakcij ne vemo, kdaj točno se

bodo zaključile. Prav tako takšne transakcije komunicirajo z viri, nad katerimi

nimamo popolne kontrole (npr. z nekim tujim podjetjem, osebo, ...). V tem primeru

povrnitev v prvotno stanje zagotavljamo z kompenzacijskimi metodami.

Podatkovne baze, ki podpirajo transakcije, se imenujejo transakcijske podatkovne

baze. V to kategorijo spada večina modernih podatkovnih baz, vključno z PostgreSQL.

Transakcijske podatkovne baze zagotavljajo, da jo lahko vzdržujemo na enostaven in

konsistenten način tako, da so vse operacije na njej medsebojno odvisne, kar pomeni, da

se vse naenkrat uspešno zaključijo ali pa sploh ne.

2.2.2.2. Zaklepanje podatkov

Zaklepanje podatkov v primeru podatkovnih baz je postopek, ki ga uporabljamo za

nadzor sočasnega dostopa do podatkov. Ko ena transakcija dostopa do nekega podatka,

zaklepanje onemogoči, da bi ga istočasno uporabljale tudi druge, kar bi lahko pripeljalo do

napačnih rezultatov. Transakcija, ki izvaja ažuriranje (vnos, spremembo ali brisanje)

zapisa, mora biti transparentna. V primeru, da pride do napake med potrjevanjem

transakcije, bo stanje v podatkovni bazi enako, kot je bilo pred pričetkom transakcije.

Zaklepanje je nujno za zaščito integritete podatkov v podatkovni bazi. Sistemi za

upravljanje podatkovnih baz ponujajo mehanizme/metode zaklepanja podatkov. Obstaja

več načinov izvedbe, ki je lahko deljeno (angl. shared locking) ali ekskluzivno zaklepanje

(angl. exclusive lock). Pri tem gre lahko za zaklepanje na nivoju strani (angl. page level

locking) ali zapisov/polja (angl. row-level locking). Namen zaklepanja je zagotovitev

serializacije. Najbolj znan protokol je dvofazno zaklepanje (angl. 2PL-Two phase locking)

[17].

Serializacija je način, kako identificirati načine izvedbe transakcij, ki zagotovijo

ohranitev skladnosti in celovitosti podatkov. Pri tem se držimo urnika, to je zaporedja


operacij iz množice sočasnih transakcij, ki ohranja vrstni red operacij posameznih

transakcij. Urniki so lahko zaporedni ali nezaporedni. Namen serializacije je poiskati

nezaporedne urnike, ki omogočajo vzporedno izvajanje transakcij brez konfliktov, pri tem

pa dosežemo rezultat, kot če bi se transakcije izvedle zaporedno. Serializacijo je mogoče

zagotoviti z različnimi metodami za nadzor sočasnosti. Metode za nadzor sočasnosti

delimo na:

• optimistične (angl. Optimistic locking): izhajamo iz predpostavke, da je konfliktov

malo, zato dovolimo vzporedno izvajanje, morebitne konflikte preverjamo na

koncu izvedbe transakcije.

• pesimistične (angl. Pesimistic locking): v primeru, da bi lahko prišlo do konfliktov,

se izvajanje ene ali več transakcij zadrži (zaklepanje, časovno označevanje)

2.2.3. Zaščita pred izgubo podatkov

Zanesljivost, varnost ter zaščita podatkov so med seboj povezani pojmi, ki so pogoj za

uspešno poslovanje podjetja. Kljub temu se v podjetjih posveča premalo pozornosti tej

temi, še več, o zaščiti pričnejo razmišljati takrat, ko pride do težav, do izgube podatkov.

Zaščita podatkovnih baz je različna. Lahko se uredi v okviru sistemskega varovanja

strežnika, na katerem je nameščena podatkovna baza, lahko se uredi parcialno (izvajamo

hranjenje le dela diskovja), določene vrste zaščit so urejene v okviru sistema za upravljanje

s podatkovnimi bazami oz. v okviru same podatkovne baze. Metode so odvisne od same

konfiguracije informacijskega sistema, v katerem je podatkovna baza umeščena ter od

potreb podjetja / organizacije.

Najpogostejše metode zaščite so naslednje:

• replikacija podatkovne baze

• sprotno arhiviranje

• dnevno arhiviranje

• zaščita pred veliko obremenitvijo

2.2.3.1. Replikacija podatkovne baze


Replikacija je proces kopiranja in vzdrževanja podatkovnih objektov, kot so zapisi in

tabele, med podatkovnimi bazami, ki sestavljajo porazdeljen sistem. Razloga za uporabo

replikacije podatkov med strežniki sta večja dostopnost podatkovnih baz (če izpade en ali

več strežnikov) in hitrejši dostop do podatkov (več strežnikov lahko opravi več transakcij

na časovno enoto). Replicirane podatkovne baze so ponavadi razdeljene na lokacijsko

neodvisne računalniške sisteme.

Računalniški sistemi, ki uporabljajo replikacijo, se lahko nahajajo na istem ali ločenih

omrežnih segmentih. S tem, ko jih postavimo na isti omrežni segment, dosežemo predvsem

hitrejši dostop do podatkov. Tako ustvarjena množica sistemov omogoča izvajanje večjega

števila transakcij. Če so uporabniki podatkov locirani na več segmentih, je smiselno

postaviti podatke v njihovo neposredno bližino. Na omrežne segmente, kjer zaradi količine

uporabnikov pričakujemo pogoste dostope do podatkov, postavimo strežnik (ali več) in

podatke repliciramo med oddaljenimi segmenti. Tako dosežemo višjo hitrost dostopa do

podatkov in redundanco strežnikov na ravni omrežja. Vsaka replicirana baza dovoljuje

dostop do vseh podatkov. S pomočjo mehanizma replikacije pa si prizadevamo, da

vsebujejo vse porazdeljene podatkovne baze vedno enake podatke.

Največja prednost replikacije je dosegljivost podatkov v primeru izpada enega izmed

strežnikov. Uporabniki so v tem primeru enostavno in hitro preusmerjeni na enega

(ponavadi najbližjega) izmed drugih strežnikov in izpada ne opazijo. Edina občutna

sprememba zanje je lahko daljši dostopni čas. Druga velika prednost repliciranih

podatkovnih baz je lokalnost dostopov do podatkov. Če so podatki postavljeni na strežnike

na lokalnih omrežnih segmentih, je dostopni čas bistveno krajši v primerjavi s povprečnim

dostopnim časom od centralno lociranih podatkov. Ker uporabniki dostopajo do lokalno

postavljenih podatkov, se tudi omrežje razbremeni in omogoči boljše odzivne čase drugim

aplikacijam.

Pomanjkljivost replikacije je podvajanje podatkov. Vse replicirane podatkovne baze

morajo vsebovati določene ali celo vse podatke, ki se pojavljajo v kateri koli izmed njih.

Pomanjkljivosti replikacije je tudi kompleksnost upravljanja in medsebojne komunikacije

med repliciranimi podatkovnimi bazami. Delno replicirane podatkovne baze vsebujejo le

podmnožico vseh podatkov, ki jih porazdeljene baze hranijo. S tem se zmanjša količina

potrebnega pomnilniškega prostora. Rešitev je kompromis med ceno popolne replikacije


(zasedanje pomnilniškega prostora) in dostopnostjo podatkov ob izpadu omrežja (določeni

podatki so nedosegljivi).

2.2.3.2. Sprotno arhiviranje

V principu gre za postopek, ki omogoča popolno povrnitev (angl. full recovery)

podatkov v primeru, da pride do izpada računalnika, na katerem je inštalirana podatkovna

baza (npr. okvara diska). Podatkovni strežnik v ta namen ponavadi tvori dnevnik vseh

transakcij, iz katerih potem z orodji naredimo povrnitev podatkov od trenutka, ko smo

pričeli voditi dnevnik. Tu ne gre za klasično hranjenje podatkov, temveč za poseg nad

določeno podatkovno bazo. Proizvajalci so ta način arhiviranja različno poimenovali on-

line backup, Hot backup, PITR-PostgreSQL, prav tako tudi povrnitev podatkov na osnovi

tega načina arhiviranja.

2.2.3.3. Dnevno arhiviranje

Odvisnost podjetij od delovanja informacijskih sistemov in varnosti njihovih podatkov

se hitro povečuje, še zlasti z rastjo obsega e-poslovanja, izmenjave e-pošte in

povečevanjem kompleksnosti spleta elektronskih oziroma digitalnih storitev. Večina

informatikov – pa tudi podjetnikov, menedžerjev in drugih uporabnikov – ve, da moramo

podatke varovati. Koliko pa jih sme verjeti, da so podatki res dovolj dobro varovani, da

bodo arhivski (angl. backup) sistemi delovali, ko jih bodo res potrebovali?

Za izdelovanje arhivskih kopij so na voljo namenske programske kot strojne rešitve

varovanja podatkov. Za potrebe vzdrževanja podatkovnih baz pa so na voljo tudi rešitve, ki

so razvite v okviru samega sistema za upravljanje s podatkovnimi bazami.

2.2.4. Zaščita pred preveliko obremenitvijo


Podatkovna baza v nekem informacijskem sistemu ponavadi predstavlja eno izmed

ključih točk. Podatkovna baza na nekem manjšem informacijskem sistemu se ponavadi

nahaja na enem strežniku, kar je v primeru manjše obremenitve popolnoma ustrezna

rešitev. Ko naš informacijski sistem raste, se ustrezno povečuje tudi obremenitev

podatkovne baze. Kaj hitro se zato zgodi, da baza postane ozko grlo (angl. bottleneck)

sistema, saj ne more obdelati tako velikega števila zahtev.

Problem lahko rešimo tako, da nadgradimo strojno konfiguracijo našega podatkovnega

strežnika tako, da mu dodamo večje število procesorjev, dodamo pomnilnik ali povečamo

hitrost diskovnih pogonov. To je ponavadi le kratkotrajna rešitev, saj je ponavadi zelo

draga in ne zadostuje, kadar naš informacijski sistem in s tem obremenitev, še nadalje

rasteta.

Da se lahko takšnim situacijam uspešno izognemo, uporabljamo tehnike, s katerimi

porazdelimo obremenitev na nivoju podatkovne baze in s tem povečamo prepustnost

sistema.

2.2.4.1. Podatkovne gruče

Rešitev zgornjega problema predstavlja podatkovna gruča (cluster), ki je sestavljena iz

dveh ali več strežnikov, na katerih teče svoja instanca podatkovne baze, vse instance pa

delujejo nad fizično isto podatkovno bazo, torej nad istimi tabelami in podatki. V grobem

lahko podatkovno gručo opišemo kot:

• podatkovna gruča je sestavljena iz enega ali več strežnikov

• na vsakem strežniku teče svoja instanca podatkovne baze

• vse instance delajo nad enako fizično podatkovno bazo, torej nad istimi tabelami in

podatki

• vse instance uporabljajo skupno konfiguracijo

• vsaka instanca ima oziroma si vodi svoj arhiv in ima možnost povrnitve v primeru

napake

• vse instance paralelno izvajajo transakcije nad fizično enako podatkovno bazo

Takšna ureditev ima kar nekaj prednosti:

• obremenitev se porazdeli med fizično različnimi enotami


• prepustnost se drastično poveča

• sistem je zelo skalabilen, kar pomeni, da lahko na enostaven način dodamo dodatni

strežnik in z njim še eno instanco podatkovne baze

• strežnik ima lahko relativno poceni strojno konfiguracijo, saj prepustnost

povečujemo tako, da dodajamo dodatne strežnike namesto da nadgrajujemo strojno

opremo

Seveda bore malo podatkovnih baz omogočajo podatkovne gruče. Med njimi so

predvsem komercialne podatkovne baze kot so Oracle, SQL Server, DB2 ter tudi nekaj

odprtokodnih. Po podatkih iz svetovnega spleta tudi MySQL (dopolnjena verzija 5) ter

seveda PostgreSQL. Tako v primeru velikega pomena dostopa do podatkov (24 ur / 7 dni v

tednu) izvedemo postavitve podatkovne gruče. V gručo vedno postavimo dva identična

strežnika s popolnoma enako konfiguracijo. Za postavitev enega vozlišča je dovolj

standarni SQL strežnik. Gručo povežemo z diskovnim poljem. Porazdeljena gruča je

skupina dveh strežnikov, fizično ločena. Ob napakah je mogoče delo brez preklopov in

prekinitev. Gruče ne zagotavljajo varovanja podatkov pred izgubami zaradi napak ali okvar

podatkovnih nosilcev. Tehnologija gruč je pri različnih proizvajlcih znana pod različnimi

imeni (na primer pri Oraclu: Oracle 10g ASM, Oracle 10g RAC)

2.2.4.2. Porazdelitev obremenitve

V informatiki si pod pojmom porazdelitev obremenitve predstavljamo tehniko, s katero

porazdelimo obremenitev med več fizično različnimi enotami, npr. računalniki, procesorji,

diskovnimi pogoni, procesi, podatkovnimi bazami.

Tu se pojavljata dva pojma oziroma dve zahtevi in sicer:

• visoka dostopnost (angl. high availability)

• porazdelitev obremenitve (angl. load balancing).

Kadar govorimo o visoki dostopnosti do podatkov, mislimo predvsem o tem, da v

primeru izpada glavnega strežnika, prevzame delo drugi podatkovni strežnik. Kadar pa

govorimo o porazdelitvi obremenitve, govorimo o tem, da je omogočeno, da različni

računalniki ponujajo iste podatke. V primeru spletnega strežnika lahko dokaj enostavno in


hitro zagotovimo, da spletne strani ponuja več strežnikov hkrati, prav tako tudi v primeru

podatkovnega strežnika, kjer podatke le beremo. Na žalost pa je v primeru podatkovnega

strežnika potrebno podatke tudi zapisovati. Pri tem je potrebno vedeti, da podatke, ki jih

samo beremo, zapišemo na vse strežnike le enkrat, v primeru spremembe podatkov pa je

potrebno zahtevo zapisati na vse strežnike v istem trenutku. Samo to nam zagotavlja tudi

konsistenco podatkov. V osnovi je takšna sinhronizacija delovanja strežnikov zelo

zapletena. Pri tem na sinhronizacijo ne vpliva le posamezna rešitev za določen podatkovni

strežnik, temveč rešitve za vse strežnike. Enaka rešitev za različni strežnik lahko različno

vpliva Nekatere rešitve ponujajo sinhronizacijo strežnikov tako da dovoljujejo spremembo

podatkov le na enem strežniku, branje pa z vseh (»read/write master server metoda«). Pri

tem velja, da strežniki, s katerih podatke le beremo imenujemo pomožni strežniki »slave

servers«, strežnik na katerega podatke zapisujemo spremembe pa glavni strežnik »master

server«. Porazdelitve obremenitve so lahko sinhrone ali asinhrone. Pri sinhroni porazdelitvi

govorimo v primeru, ko se transakcija, kjer pride do spremembe podatkov ne upošteva,

dokler se ne zaključi na vseh strežnikih. To zagotavlja konsistenco podatkov na vseh

strežnikih hkrati. Asihrona porazdelitev pa dopušča, da pride do zakasnitve med časom

zaključka transakcije in njenim razširjanjem na ostale strežnike. Pri tem obstaja možnost,

da se posamezne transakcije izgubijo, stanje podatkov se izenači šele ob kopiranju z

arhivskega strežnika. Za asinhrono rešitev se odločimo takrat, ko je sinhrona porazdelitev

prepočasna. Moramo namreč vedeti, da je v primeru počasnejšega omrežja sinhrona rešitev

dvakrat ali več počasnejša od asinhrone.

V kontekstu podatkovne baze pojem porazdelitve obremenitve povezujemo z

podatkovnimi gručami. Kadar imamo podatkovno bazo urejeno kot podatkovno gručo,

potrebujemo tudi način, da z njo komuniciramo. V ta namen ponavadi definiramo vstopno

točko-vozlišče, preko katere naš informacijski sistem uporablja podatkovno gručo.

Vstopna točka ponavadi predstavlja enega izmed strežnikov v podatkovni gruči, ki mu naš

informacijski sistem pošilja vse zahteve. Vstopno točko imenujemo tudi gospodar (load

balancer). Njegova naloga je preverjati obremenitev posameznih strežnikov v podatkovni

bazi in glede na to usmerjati zahteve na enega izmed njih. Na takšen način dosežemo

optimalno prepustnost.


3. VARNOST PODATKOV V PostgreSQL

Kot administrator podatkovne baze smo odgovorni, da uporabniki baze lahko dostopajo

do podatkov, ko jih potrebujejo. Prav tako smo odgovorni, da dodelimo uporabnikom

pravice, ki jih potrebujejo za svoje delo. Tako, glede na varnost in dostop do podatkovne

baze, lahko ločimo dva aspekta. Prvi je, kako dodeliti uporabniško ime in geslo

posameznemu uporabniku, ki se z svojo identifikacijo – prijavo v sistem tudi identificira,

drugi pa je, katere pravice dobi posamezen uporabnik za delo v podatkovni bazi. Tu velja

vse bolj načelo, da dobi pravice, ki jih zares potrebuje za delo in nič več. Tako je naloga

administratorja , da vsakemu uporabniku ali skupini uporabnikov dodeli uporabniška

imena in gesla, ki niso predvidljiva, vodi politiko gesel skozi celotno življenjsko dobo

podatkovne baze ter dodeljuje ravno pravšnje pravice, ki zaživijo ob prijavi uporabnika v

podatkovno bazo.

Kot administrator podatkovne baze smo tako odgovorni za dodeljevanje uporabniških

imen, gesel in uporabniških skupin. Prva izmed nalog pri administraciji podatkovne baze

je, kako dodeliti uporabniška imena. Ena možnost je, da vsakemu uporabniku dodelimo

enolično uporabniško ime in geslo. To je sicer dober način, ni pa vedno praktično. V

primeru dostopa do podatkovne baze preko spleta si verjetno ne želimo, da vsakemu

obiskovalcu spletne strani, dodelimo svoje uporabniško ime in geslo. Dobra rešitev v

takšnih primerih je, da znanemu uporabniku dodelimo enolično uporabniško ime,

nepoznanim gostom pa generično uporabniško ime. Administrator mora prav tako poznati,

kakšno avtentikacijsko metodo izbrati. PostgreSQL ima na voljo več metod avtentikacije,

razvrščene glede na stopnjo varnosti od metode »TRust« do metode »Kerberos«. Katero

metodo bomo uporabili je odvisno, kakšna je občutljivost podatkov, ki jih hranimo[7].

Za administratorja je prav tako pomembno, da pozna, kako je baza zgrajena ter kje se

fizično nahaja, ter kako je PostgreSQL organiziran na logičnem nivoju.

3.1. Logična in fizična urejenost datotek

Gruča (angl. cluster) vsebuje eno ali več podatkovnih baz. Je najvišji člen hierarhije

PostgreSQL sistema hrambe podatkov. Gruča nima imena, dostop do njega pa je mogoč

izključno preko podatkovnega strežnika (postmasterja). Vsaka gruča obstaja le na enem


imeniku (privzeto je to na mestu inštalacije PostgreSQL-a, to je v delovni mapi C:\Program

Files\PostgreSQL\8.2\data). Podatke lahko zapišemo tudi na drugi delovni imenik, tako da

najprej določimo podatkovni prostor (angl. tablespace), nato pa kreiramo podatkovno bazo

v okviru tega prostora. Podatkovna baza (angl. database) je skupek shem. Ime podatkovne

baze mora biti unikatno za vsako gručo posebej. Shema je zbirka – imenski prostor

posameznih tabel. Imeti mora unikatno ime v vsaki podatkovni bazi. Tabela (angl. table) je

sestavljena iz stolpcev ter vrstic. Vsaka vrstica pomeni en zapis v tabeli. Omogoča

shranjevanje podatkov različnih tipov (slika 6.).

Gruča

Podatkovna zbirka Podatkovna zbirka

Shema Shema Shema Shema

Tabela Tabela Tabela Tabela Tabela Tabela

slika 3: gradniki podatkovne baze PostgreSQL, povzeto po [7]

Glede na organizacijo lahko uporabnik dostopa do podatkovne baze na različnih

nivojih, odvisno od uporabniških pravic, ki mu jih dodelimo. V primeru, ko za določen

objekt ni točno določeno, kam spada, se smatra, da ga lahko vsi vidijo (public).

Po inštalaciji se PostgreSQL nahaja na delovnem imeniku

C:\ProgramFiles\PostgreSQL\8.2. (v nadaljevanju /usr/local/psql) in

vsebuje več podimenikov (bin, data, doc, include, jdbc, lib, npgsql, pgAdminIII,share). Za

nas sta zanimiva predvsem prva dva, to je bin in data. Izvršne datoteke, kot so psql, initdb,

postmaster ter razne »shell procedure«, so shranjene v imeniku »bin« (/usr/local/psql/bin).

V podimenik »data« se hranijo vse informacije o podatkovnih bazah, njihovi strukturi,

uporabnikih, pravicah, ipd. v okviru sistemskih datotek. To so datoteke pg_hba.conf,

pg_ident.conf, pg_VERSION, postgresql.conf, postmaster.opts in postmaster.pid. Pomen

posameznih datotek lahko vidimo v tabeli 2.


tabela 2: opis pomena datotek

Datoteka Opis pg_hba.conf Podatki o uporabniških računih (vsebuje vrsto povezave, ime podatkovne

baze, uporabniško ime, naslov odjemalca ter avtentikacijsko metodo) za vsak uporabniški račun posebej

pg_ident.conf Podatki o uporabnikih Pg_VERSION Podatki o verziji programskega produkta PostgreSQL postgresql.conf Podatki o nastavitvah PostgreSQL Postmaster.opts Podatki za zagon upravljalca strežnika PostgreSQL, to je postmasterja Postmaster.pid Bližnjica s podatki, kje se upravljalec nahaja

Podimenik »data« prav tako vsebuje 8 podimenikov, in sicer: global, base, pg_log,

pg_xlog, pg_clog, pg_subtrans in pg_tblspc, pg_twophase ter pg_multixact (velja za

verzijo 8.2). Podimenik global povezuje gruče, sheme, podatkovne baze med seboj; imenik

base vsebuje podatke vseh podatkovnih baz, ki pa so razvrščeni zopet v podimenike

/usr/local/psql/data/base/1, 10290. Podrobnejši pregled se nahaja v tabeli 3.

tabela 3: opis pomembnejših podimenikov imenika data (/usr/local/data)

Imenik Opis /global imenik vsebuje informacije o uporabniških računih (pg_shadow),

skupinah uporabnikov (pg_group) ter podatkovnih bazah (pg_database). /base imenik vsebuje podatke vseh podatkovnih baz urejeno po podimenikih /pg_clog imenik vsebuje podatke o vseh uspešnih zapisih v podatkovne baze /pg_xlog imenik vsebuje podatke o neizvedenih transakcijah. V primeru

nenadnega izpada strežnika, se transakcije izvedejo po ponovnem zagonu

/pg_subtrans imenik vsebuje podatke o vgnezdenih transakcijah (nested transactions) /pg_tblspc imenik vsebuje podatke o linkih o navideznih lokacijah podatkov /pg_log imenik vsebuje podatke o dostopu do podatkovne baze, čas dostopa,

kateri uporabnik je dostopal, transakcije katere je izvedel

3.2. Nadzor dostopa 3.2.1. Avtentikacija

Avtentikacija odjemalca se določi s pomočjo konfiguracijske datoteke, ki se tradicionalno

imenuje pg_hba.conf (HBA pomeni host-based authentication). V datoteki je vrsta zapisov,

ki vsebujejo vrsto povezave (local,host,hostssl,hostnossl), ime podatkovne baze,

uporabniško ime, naslov odjemalca ter avtentikacijsko metodo (trust, md5, crypt,


password, kerberos, ident, pam), po kateri se opravi avtentikacija (tabela 4.). Metode

avtentikacije so bolj podrobno opisane v nadaljevanju, glej poglavje 3.2.3. Ko se aplikacija

na odjemalcu skuša povezati z bazo (npr. psql), pošlje postmasterju uporabniško ime in

ime podatkovne baze. Po sprejemu zahteve postmaster poišče v sistemski datoteki

pg_hba.conf podatke o uporabniku, podatkovni bazi, naslov odjemalca in tip povezave.

Vsakokrat išče od začetka datoteke do trenutka, ko najde ustrezen zapis (vsi podatki se

ujemajo z dobljeno zahtevo s strani odjemalca). V primeru, da pride do konca datoteke, pri

tem pa ustreznega zapisa ni našel, postmaster zavrne dostop do podatkovne baze. Zatem,

ko postmaster pridobi potrjene podatke o ustrezni prijavi, iz zapisa uporabi še dodatne

podatke , kakšno avtentikacijsko metodo uporablja (npr., če je iz zapisa razvidno, da je

avtentikacijska metoda tipa password, zahteva od odjemalca ustrezno geslo). V splošnem

velja, da močnejša kot je avtentikacijska metoda, bolj nadležna je, vendar pa ne smemo

pozabiti, da so ob tem tudi podatki bolj varni [7].

tabela 4: shema konfiguracijske datoteke PG_HBA.CONF Tip povezave Ime podatkovne

baze Uporabnik Naslov odjemalca Avtentikacijska metoda

Local host hostssl hostnossl

IP-address, IP-mask CIDR-adress

Trust, md5, ident, crypt, password, kerberos, pam

Host Test Zoran 127.0.0.1 255.555.555.0

Password

Local Postgres All 127.0.0.1 /32 Ident sameuser

3.2.2. Avtorizacija

Uporabniške pravice so shranjene v datoteki pg_shadow. Do nje dostopamo preko meta

ukaza psql \d pg_shadow, do podatkov v tabeli pg_shadow pa s pomočjo ukaza SELECT.

Pravice, ki jih lahko dodeljujemo posameznemu uporabniku oziroma skupini, so prikazane

v tabeli 5.

tabela 5: pregled pravic Stavek / ukaz Lokacija, kjer je pravica

na voljo Kratek opis

SELECT Tabele, Pogledi, Sekvence

Kontrola pravic pri dostopu do vrstice v tabeli oz. pogledu. Prav tako kontrolira pravice povpraševanja nad sekvencami.

INSERT Tabele, Pogledi, Sekvence

Kontrola pravic pri vnosu novih zapisov v tabelo, pogledi ali sekvenco.

UPDATE Tabele, Pogledi, Kontrola pravic pri spremembi podatkov v tabeli, pogledu


Sekvence ali sekvenci DELETE Tabele, Pogledi,

Sekvence Kontrola pravic pri brisanju podatkov v tabeli, pogledu ali sekvenci

RULE Tabele, Pogledi, Sekvence

Kontrola pravic pri kreiranjem novih pravil na tabeli ali pogledu.

REFERENCES Tabele Kontrola pravice nad povezavo dveh tabel s pomočjo zunanjega ključa.

TRIGGER Tabele Kontrola pravic pri kreiranju sprožilcev na tabeli. CREATE Podatkovne baze,

Podatkovni prostori, Sheme

Kontrola pravic pri kreiranju new schemas within a database, new objects within a schema, or new indexes (or tables) within a tablespace.

TEMPORARY Podatkovne baze Kontrola pravic pri kreiranju začasnih tabel v okviru podatkovne baze.

EXECUTE Funkcije Kontrola pravic pri izvajanju funkcij. USAGE Sheme,Jeziki Kontrola številčenja objektov znotraj sheme, kontrola

pravic pri kreiranju novih funkcij.

3.2.3. Enkripcija

PostgreSQL ponuja šifriranje podatkov na različnih stopnjah in zagotavlja fleksibilnost

v zaščiti podatkov pred razkritjem, katerih povzročitelji so lahko podatkovne kraje,

brezvestni administratorji ali nezanesljiva/nezaščitena omrežja.

Uporabniška gesla so shranjena s pomočjo šifriranja tipa MD5, tako administrator ne

ve, katero geslo ima uporabnik, ter ga ne more uporabiti. Šifriranje je zagotovljeno v

vsakem primeru, tudi če je uporabnik začasno prijavljen na strežnik, ker šifriranje MD5

zagotavlja, da se podatki šifrirajo, preden se pošljejo preko mreže.

Šifriranje določenih stolpcev v tabeli omogoča, da se prikrijejo podatki, ki so vsebinsko

občutljivi (npr, deli zdravniških kartotek, finančne transakcije, ipd). V tem primeru

odjemalec zagotovi/priskrbi od strežnika ključ za dešifriranje, podatke dešifrira in jih

pošlje uporabniku.

Zaščita sistemske particije diska preprečuje vpogled v podatke, ki se nahajajo na disku.

Šifriranje je odvisno od vsakega operacijskega sistema posebej (Linux – loopback device,

FreeBSD – GBDE). Mehanizem preprečuje vpogled v podatke v primeru kraje diska ali

medija, na katerem so podatki shranjeni, ne preprečuje pa vpogleda v podatke v primeru

napada na računalnik. Namreč v času, ko računalnik oziroma disk deluje (disk mounted),

so podatki nezaščiteni / odprti.

Šifriranje gesel skozi omrežje (MD5) je dvostopenjsko šifriranje gesla odjemalca,

preden se zahteva pošlje strežniku. Izvede se na osnovi uporabniškega imena ter


naključnega števila, ki je poslan od strežnika, ko je povezava vzpostavljena.

Dvostopenjsko šifriranje preprečuje ne le razkritja uporabniškega gesla, temveč tudi še eno

povezavo z enakim ključem.

Šifriranje podatkov skozi omrežje (SSL) poteka s pomočjo povezav tipa SSL. Pri tem

se šifrirajo gesla, povpraševanja ter vrnjeni podatki. V datoteki pg_hba.conf administrator

nastavi, kdo lahko uporablja odprte in kdo zaprte povezave.

Tu so še možnosti zaščite s strani odjemalca (SSL Host , Client-Side Encryption), prav

tako podpira varne povezave odjemalca do strežnika (SSL, SSH Tunnels)

3.2.4. Uporabniške skupine

Kot administrator podatkovne baze smo dolžni skrbeti za uporabnike, uporabniške

skupine ter pravice, ki jim omogočajo delo s podatki. Odgovorni smo za dodelitev (angl.

grant) ter odvzem (angl. revoke) pravic uporabnikom. V večini primerih se računalniško

okolje nastavi tako, da so uporabniška imena in gesla enaka za dostop do sistemskega

okolja ter podatkovne baze.

Definiranje uporabnika

Novega uporabnika lahko kreiraš s tem, da poženeš ukaz CREATE USER iz odjemalca

(konzola psql), ali pa uporabiš skripto createuser shell.

sintaksa ukaza:

CREATE USER user-name

[[WITH] option ]...

option := SYSID user-id-number

| [NO]CREATEDB

| [NO]CREATEUSER

| IN GROUP groupname [, ...]

| [[UN]ENCRYPTED ] PASSWORD 'password'

| VALID UNTIL 'expiration'


primer uporabe:

CREATE GROUP uporabniki;

CREATE USER zoran IN GROUP uporabniki;

Uporabniško ime user-name je lahko dolžine največ 31 znakov, prvi znak mora biti črka ali

podčrtaj. Vsa uporabniška imena, gesla in pravice so zapisana v sistemski datoteki

pg_shadow.

Uporabna je opcija SYSID, ki vsakemu uporabniku dodeli tudi identifikacijsko številko

(od 100 dalje). V primeru kreiranja tabele, ki ji določimo lastnika, se tabeli zabeleži tudi

identifikacijska številka uporabnika.

Priprava skupine

Kot administrator podatkovne zbirke lahko definiramo skupine uporabnikov s uporabo

ukaza CREATE GROUP. Skupini uporabnikov kasneje lahko dodeljujemo ali odvzemamo

pravice na enak način kot posameznemu uporabniku. To pride zelo prav, v primeru, ko

odpiraš ali zaključuješ kakšen projekt. Uporabnik lahko pripada več skupinam.

Sintaksa ukaza:

CREATE GROUP group-name [[WITH] option [...]]

option := SYSID group-id-number

| USER username, ...

primer uporabe:

CREATE GROUP uporabniki;


3.3. Zaščita pred nekonsistentnostjo podatkov

3.3.1. Transakcije, ACID in PostgreSQL

Transakcija je skupina SQL ukazov, ki se smatrajo kot celota. PostgreSQL obljublja,

da se vsi ukazi v okviru ene transakcije zaključijo oziroma nobeden izmed njih. V primeru,

ko se transakcija izvede v celoti, govorimo, da se zaključi (angl. committed). Če se

transakcija ne zaključi, PostgreSQL poskrbi, da se stanje podatkovne baze povrne pred

začetkom izvajanja transakcije. PostgreSQL tako uporablja »Rollback« način zagotavljanja

celovitosti podatkov.

Začetek transakcije zapišemo z ukazom BEGIN, zaključimo pa z ukazom COMMIT.

Vsi ukazi med ukazoma BEGIN in COMMIT so tako ena transakcija, v nasprotnem

primeru je vsak ukaz samostojna transakcija. V času trajanja transakcije so podatki, ki so

predmet transakcije, zaklenjeni pred ostalimi uporabniki, na voljo so le lastniku

transakcije, po zaključku transakcije pa so spremembe v podatkovni bazi logično

zaključene, trajne. Podatki so ponovno na voljo ostalim uporabnikom. Stanje pred

transakcijo dosežemo z ukazom ROLLBACK5.

Izolacija

Pri izolaciji podatkov dostikrat govorimo o problemu zapisovanja »Dirty read«.

Rešitev tega problema v PostgreSQL je mogoča z enim izmed dveh načinov izolacije, to je

z izvedbo ukaza READ COMMITTED. Drugi način izolacije je serializacija

(SERIALIZABLE), ki odpravlja tudi t.i. problem »phantom read«. Ta poleg tega

odpravlja tudi problem »nonrepeatable read«. Pri tem je potrebno povedati, da v splošnem

poznamo štiri stopnje izolacije, PostgreSQL pa ima na voljo le prej omenjena načina, ki pa

po standardih SQL 92 zadostujeta – po principu bolje je več, kot manj [21]. Na tabeli 6. so

prikazane posamezne stopnje izolacije ter problemi, ki jih posamezna stopnja odpravlja.

Izolacije, ki jih PostgreSQL podpira, so obarvane v sivi barvi.

5 Ukaz BEGIN lahko zapišemo tudi kot BEGIN WORK ali BEGIN TRANSACTION, prav tako tudi ukaza COMMIT ter ROLLBACK (COMMIT WORK, COMMIT TRANSACTION, ROLLBACK WORK, ROLLBACK TRANSACTION)


tabela 6: pregled stopenj izolacije, povzeto po [21] Vrsta problema

Stopnja izolacije

Dirty Read Nonrepeatable Read Phantom Read

Read uncommitted � � �

Read commited - � �

Repeatable read - - �

Serializacija - - -

Legenda: � problem je še zmerom prisoten, mogoč,

- odpravljen

Primer uporabe –sintaksa ukaza:

SET TRANSACTION ISOLATION LEVEL { READ COMMITTED │ SERIALIZABLE}

PostgreSQL ima na voljo pri izvedbi transakcije še eno posebnost. Podatkovna baza ima

možnost, da si zapomni stanje na določenem mestu izvedbe transakcije. To dosežemo tako,

da označimo mesto transakcije, do katere se je transakcija še uspešno izvedla. Označitev

opravimo z zagonom ukaza SAVEPOINT. V primeru preklica transakcije lahko prekličemo

spremembe vse do označene točke.

sintaksa ukaza:

SAVE POINT savepoint-name

ROLLBACK TO SAVEPOINT savepoint-name

primer:

START TRANSACTION;

INSERT INTO artikel VALUES (5,....);

SAVE POINT p1;

INSERT INTO artikel VALUES (6,....);

ROLLBACK TO SAVEPOINT p1;


Vidimo, da se v primeru preklica transakcije (ROLLBACK) zbrišejo vse spremembe (oba

vnosa v tabelo artikel), če pa izvedemo preklic spremembe do točke p1 (ROLLBACK TO

SAVEPOINT p1), potem se ne vpiše le zadnji vnos v tabelo artikel.

3.3.2. Zaklepanje podatkov

Večina komercialnih, kot tudi odprtokodnih baz, uporablja metodo zaklepanja

podatkov, da lahko koordinira delo med uporabniki. V kolikor posodabljamo tabelo, je

tabela zaklenjena pred spremembami in poizvedbami drugih uporabnikov. Nekatere baze

uporabljajo zaklepanje na nivoju strani (angl. page-level locking) ali zaklepanje na nivoju

vrstice (angl. row-level locking), toda princip zaklepanja je vselej enak, to je, da drugi

uporabniki čakajo, da izvedejo spremembo nad podatki tako dolgo, dokler prejšnji

uporabnik ne zaključi z delom in sprosti zaklenjenih vrstic.

PostgreSQL uporablja drugačen model zaklepanja od ostalih podatkovnih baz. Model

se imenuje večkratno verzioniranje (angl. multi-versioning), skrajšano MVCC način

zaklepanja [15]. Pri tem načinu se princip zaklepanje še zmerom uporablja, vendar dosti

manj pogosto, kot bi pričakovali. Podatkovna baza izdela kopijo vrstic v tabeli, ki jo

nameravamo uporabljati. Drugi uporabnik v primeru dostopa do iste tabele sicer vidi

originalno vsebino le-te, nima pa je možnosti spreminjati ali delati poizvedb - njegova

transakcija čaka na izvedbo naše transakcije, dokler mi ne zaključimo z delom. V primeru,

ko transakcija ne uspe, ne pride do zaključka transakcije (angl. rollback), to ne vpliva na

delo drugega uporabnika. V primeru, ko se transakcija zaključi (angl. commit), originalni

zapis označimo kot zastarel (angl. obsolete). Vse transakcije, ki so tipa READ COMMITTED

takoj vidijo spremembe, transakcije tipa SERIALIZABLE pa še naprej uporabljajo kopijo,

na njej ni dovoljena sprememba ali poizvedba podatkov. Kopija podatkov, ki smo jo

prvotno kreirali, torej zastareli zapisi, se žal ne izbrišejo sami, potrebno jih je ročno

izbrisati iz podatkovne baze. To stori administrator podatkovne baze s pomočjo ukaza

VACUUM. Od verzije 8.2 PostgreSQL že izvaja avtomatično brisanje nepotrebnih zapisov iz

baze.

Transakcijski model MVCC zagotavlja višjo zmogljivost kot ostali modeli, saj

omogoča hkratni dostop do podatkov. Čeprav PostgreSQL uporablja MVCC model, v

določenih primerih še vedno zaklene podatke[21].


3.4. Zaščita pred izgubo podatkov

3.4.1. Replikacija podatkovne baze

Replikacija je proces pošiljanja ter pomnjenja podatkov v več podatkovnih bazah.

Ponavadi se izvaja na fizično ločenih računalnikih, po možnosti tudi prostorsko ločenih.

PostgreSQL podpira različne replikacijske mehanizme, skozi leta se je prijel predvsem

Slony (tabela 7.). Potrebno je vedeti, da PostgreSQL replikacije nima direktno vgrajene, je

pa mogoča preko prej omenjenih dodatkov. Prejšnje rešitve so bile tehnično zastarele.

tabela 7: Pregled načinov replikacije skozi zgodovino PostgreSQL

Opis Način

replikacije

v uporabi okolje

Windows XP

Slony (trenutno delujoča verzija je Slony-a je

Slony-I ver.1.2.11, v pripravi Slony-II)

Master/Slave 8.x DA

Statement-Based replikacija, Pgpool,Sequoia Master/Slave 7.0.- 7.4 NE

Pgpool-II (Paralelno večstrežniško procesiranje oz.

»Multi-server parallel Query Execution«)

Multi server Višje od

7.4

NE

s pomočjo eRServer rešitve-addOn (Enterprise

Replication Server project)

Master/Slave ver 7.x NE

Slony-I

Slony-I je proces, ki ponuja asinhrono enosmerno replikacijo podatkov v Master/Slave

načinu dela tako, da iz originalne podatkovne baze prenese podatke v poljubno število

kopiranih podatkovnih baz. Asinhronost pomeni, da je stanje podatkov v posamezni

podatkovni bazi v določenem trenutku različno, podatki se ne sinhronizirajo v trenutku,

enosmernost pa, da je spreminjanje podatkov mogoče le v originalni/osnovni podatkovni

bazi. Master/Slave način zapisa pomeni, da se spremembe zapisujejo v glavni strežnik

(master), branje je mogoče z ostalih pomožnih strežnikov (slave). Pri tem Slony-I skrbi, da


na tabeli, ki jo ažurira, doda kazalec, ki onemogoča njeno spremembo s strani uporabnika.

Slony je kaskadno zasnovan in omogoča, da se spremembe v repliciranih tabelah izvajajo

postopno po posameznih segmentih, glede na original. Sporočilo o spremembi potuje od

osnovne podatkovne baze preko vozlišč do kopiranih podatkovnih baz. Tako se zmanjša

zasedenost mreže med osnovno bazo in ostalimi, ker komunikacija o spremembi poteka

tudi med kopiranimi bazami. Replikacija je zelo uporabna za podatkovna skladišča, za

zahtevnejše poizvedbe, ki lahko poberejo precej sistemskih sredstev. Trenutna verzija

Slony-a je verzija 1.2.11, v načrtovanju je že Slony-II, ki bo podpiral istočasni zapis na

več glavnih strežnikov ter več pomožnih strežnikov (sinhroni multi Master / multi Slave

način replikacije). Slony-I ne omogoča kontrole posameznih vozlišč, ker tudi zato ni

namenjen. Tako ne more ugotoviti, ali je posamezno vozlišče odprto ali ne. V primeru

nestabilnosti vozlišč je potrebno uporabljati še kakšno dodatno orodje, ki podpira to

funkcionalnost. Za uspešno izvajanje replikacije je nujna časovna sinhronizacija vozlišč v

realnem času (Real Time Clocks). Prav tako je potrebna dvosmerna komunikacija med

vsemi vozlišči v okviru posamezne gruče (clustra). Za pravilno nastavitev poteka

replikacije med vozlišči, moramo imeti pravilne, enolično določene poti do le-teh.

Preden se lotimo same replikacije, je pomembno, da se seznanimo z osnovnimi pojmi

replikacije:

• gruča (angl. cluster) je zbirka več podatkovnih baz med katerimi poteka replikacija.

Gručo definiramo iz imena gruče ter imena vozlišč, ki sodelujejo v replikaciji.

• vozlišče (angl. node) je podatkovna baza, ki sodeluje v replikaciji.

• replikacijski set (angl. replication set) je definiran kot zbirka podatkovnih tabel ter

sekvenc, ki so replicirane znotraj gruče. Lahko imamo več takšnih setov, potek

replikacije posameznih setov ni nujno,da je enak.

• izvorno-glavno mesto ter naslovnik

• vsak replikacijski set ima svoj izvor, ki je prostor, kjer je dovoljeno spreminjati

podatke. Je glavno mesto, od koder se ostala vozlišča, ki sodelujejo v replikaciji,

oskrbujejo. Ostala vozlišča imenujemo naslovniki, to so vozlišča, ki sodelujejo v

replikaciji, vendar podatke le prejemajo.

• slon daemons je program - servis, ki omogoča delovanje same replikacije. Pri tem

kontrolira dogodke, ki jih določa replikacijski set. Dogodke delimo na


konfiguracijske ter sinhronizacijske dogodke. Konfiguracijski dogodki so dogodki,

ki so potrebni za delovanje samega servisa, sinhronizacijski dogodki pa opisujejo

vsebino, potek replikacije. Aktivira se za vsako vozlišče posebej.

• slonik je ukazni – konzolni urejevalnik, v katerem urejujemo konfiguracijo servisa

(odvzem, dodajanje vozlišč, spreminjanje poti do vozlišč, urejanje replikacijskih

setov).

3.4.2. Arhiviranje podatkov v PostgreSQL

V podatkovni bazi PostgreSQL so na voljo trije načini hranjenja-arhiviranja podatkov:

• preko sistemskega/ file system level backupa

• arhiviranje s pomočjo SQL skripte

• sprotno arhiviranje (angl. on-line backup)

System level backup

Vsaka od metod arhiviranja ima svoje prednosti in slabosti. Prva metoda kreira

sistemsko datoteko, v kateri so fizično shranjeni vsi podatki. Metoda uporablja arhivsko

orodje (tar, cpio oziroma backup) za arhiviranje vseh datotek v clustru. Ta način ima kar

nekaj pomanjkljivosti, ki metodo naredijo nepraktično. Prva pomanjkljivost je ta, da je

potrebno podatkovni strežnik zaustaviti, da se vse spremembe zapišejo na disk, šele potem

je mogoče izvesti arhiviranje. Arhivska orodja, kot so tar in podobna orodja, namreč niso

sposobna arhivirati stanja datotek, ki so v spominu, temveč le datoteke, ki so fizično

zapisana disku. Druga pomanjkljivost je v tem, da je velikost arhivske datoteke večja od

ustrezne skripte, ker arhivska datoteka vsebuje podatke o tabelah, indeksih. Prav tako je

nemogoče povrniti le dele gruče, na primer posamezno podatkovno bazo ali posamezno

tabelo. To ni mogoče zaradi tega, ker se podatki o posamezni tabeli zapišejo v dveh delih,


vsebina tabele je zapisana v datotekah, shranjene v mapi /base, informacija o strukturi pa je

zapisana v dnevniku, ki se nahaja v mapi /pg_clog .

sintaksa ukaza:

Tar –cf backup.tar /usr/local/psql/data

SQL Dump

Druga metoda, tudi največkrat uporabljena, je metoda, ki ustvari SQL skripto, s

pomočjo katere je mogoče opraviti rekonstrukcijo podatkovne baze v primeru porušitve le

te. SQL skripta vsebuje vse informacije, v kateri so shranjene informacije, kako ponovno

generirati podatkovno baz ter obnoviti podatke v njej. V primeru potrebe preprosto

zaženemo skripto za obnovitev podatkov (pg_restore). Za izdelavo arhive se uporabljata

dva ukaza za kreiranje arhivskih skript, in sicer pg_dump in pg_dumpall.

Program/ukaz pg_dump je klient aplikacija in ustvari SQL skripto, ki lahko ponovno

kreira tabele in podatke v podatkovni bazi. V skripti so zajete vse informacije za ponovno

kreiranje sprožilcev, transakcij ter indeksov za vsako podatkovno tabelo posebej. Pri

uporabi ukaza pg_dump je na voljo veliko opcij. Podobno deluje tudi ukaz pg_dumpall.

Ukaz pg_dumpall je primeren za shranjevanje celotnega clustra, ignorira pa podporo

uporabniškega formata zapisa izhodne datoteke (tar, custom), temveč zapiše skripto le v

plain tekst formatu. Žal pa plain format zapisa datoteke ne zna shraniti velikih objektov,

zato ima ukaz pg_dumpall omejeno rabo. Ukaz pg_dump / pg_dumpall lahko zažene le

uporabnik s posebnimi pravicami, to je administrator baze (superuser).

sintaksa ukaza:

pg_dump [options] dbname ime_arhivskega_niza«

Povrnitev podatkov je mogoča z uporabo ukaza pg_restore. Ukaz pg_restore ne zna

povrniti podatkov v plain tekst načinu zapisa datoteke, tu je možna povrnitev v psql

konzolnem načinu dela.


sintaksa ukaza:

pg_restore clean -d dbname ime_arhivskega_niza

Sprotno arhiviranje (On-line backup) je tretja možnost hranjenja podatkov v

PostgreSQL in deluje s pomočjo dnevnika (WAL – write ahead log). Dnevnik se kreira ves

čas delovanje strežnika in vodi vse spremembe, ki so se zgodile nad podatkovno bazo,

vključno do zadnje kontrolne točke. V dnevniku so zapisane vse transakcije, ki so

povzročile spremembe v podatkovni bazi. Dnevnik se nahaja v mapi pg_xlog. Vodi se

zaradi predvidevanja, da pride do nenadnega izpada strežnika. V tem primeru je mogoče

povrniti podatke na osnovi izdelanega dnevnika. Metodo je priporočljivo kombinirati z

metodo, ki izdela sistemsko datoteko. V kolikor moramo povrniti podatke, izvedemo

restore celotnega sistema ter poženemo dnevnik WAL, ki obnovi podatke vse od zadnje

kontrolne točke do trenutka, ko je strežnik PostgreSQL še deloval.

Primer uporabe –sintaksa ukaza:

1. preverimo, če je WAL funkcija na voljo

2. zaženemo strežnik psql , izvedemo ukaz SELECT pg_start_backup ('label');

3. po izhodu iz strežnika , izvedemo ukaz archive_command = 'cp –i %p

/mnt/server/archivedir/%f </dev/null'

4. se ponovno prijavimo v strežnik psql, izvedemo ukaz SELECT pg_stop_backup();

3.5. Zaščita pred preveliko obremenitvijo

V primeru podatkovnih skladišč velikosti več gigabajtov ima PostgreSQL na voljo

možnost razporejanja podatkovnih baz na ločene trde diske ali diskovna polja. Tej

možnosti pravimo razporejanje podatkov na podatkovne prostore (tablespaces). Na

posamezni podatkovni prostor je mogoče zapisati več podatkovnih baz. Podatkovni prostor

je potrebno predhodno kreirati na nivoju sistema tako, da kreiramo delovno mapo-imenik

na disku. Delovna mapa ne sme biti prazna, ime mape mora biti krajše od 991 znakov,


lastnik delovne mape mora biti uporabnik v posmaster procesu, ponavadi je to superuser

(postgres).

sintaksa ukaza:

CREATE DATABASE database-name

[WITH [TEMPLATE=template-database-name]

[ENCODING=character-encoding]

[OWNER=database-owner]

[LOCATION=pathname]]

primer uporabe:

CREATE DATABASE testdb;

sintaksa ukaza:

CREATE TABLESPACE tablespace-name

[OWNER=database-owner]

[LOCATION=pathname]]

primer uporabe:

CREATE TABLESPACE mytablespace LOCATION 'D:/test/baza;

Raba diska in pomnilnika sta bili izboljšani skozi uporabo »Adaptive Replacement

Cache« algoritma, uvedbo zakasnitve v izvajanju vacuum ukaza in posebnega procesa

»bgwriter«, ki opravlja zapisovanje podatkov. To zagotavlja bolj predvidljivo zasedenost

strežnika in enakomernejšo zmogljivost v času najvišje obremenitve.

Vidimo, da podatkovna baza PostgreSQL tako nima vgrajenega sistema za podporo

podatkovnim gručam in nadzoru obremenitve. Trenutno je v PostgreSQL na voljo le

odprtokodni sistem Slony-I, ki je bil narejen z namenom replikacije velikih podatkovnih

baz na razumno veliko število sužnjev. Na žalost Slony-I ni:

• sistem za upravljanje z mrežo

• ne zaznava napak v replikaciji, prav tako ne zna napredovati sužnja v

gospodarja


• ni sistem več gospodarjev – več sužnjev, zato ne pozna porazdeliti obremenitve

med več podatkovnih baz

Vse to naj bi bilo na voljo v prihajajočem sistemu Slony-II, ki pa še za enkrat ni na voljo.


4. POSTAVITEV IN VZDRŽEVANJE PostgreSQL STREŽNIKA

4.1. Opis okolja

Podatkovne baze se danes uporabljajo skoraj povsod. Od najmanjših lokalnih mrež do

velikih, več uporabniških okolij. Tukaj je še posebno pomembno kakšno podatkovno bazo

uporabljamo in kako jo zaščitimo. Eden izmed ciljev te diplomske naloge je ugotoviti, ali

je podatkovna baza PostgreSQL primerna za takšno uporabo. Tukaj mislimo na veliko

število uporabnikov (preko 100), ki lahko hkrati dostopajo do podatkovne baze. V tem

poglavju bomo na kratko predstavili, kaj vse podatkovna baza PostgreSQL zmore in kako

to naredimo.

4.2. Namestitev PostgreSQL

4.2.1. Minimalne zahteve za namestitev

Programski produkt Postgre SQL je namenjen za različna okolja kot so Unix, Linux,

Windows. Omejili se bomo na okolje Windows. Deluje na računalnikih, ki imajo inštaliran

operacijski sistem Windows XP, 2000, 2003 in NTFS datotečni sistem. V ostalih Windows

okoljih inštalacija ni možna.

4.2.2. Potek namestitve

Namestitev poteka s pomočjo InstallShield Setup Wizard-a. V raziskovalcu (Windows

Explorer) zaženemo datoteko postgresql-8.2-int.msi, ki jo predhodno naložimo s spleta, na

naslovu http://www.postgresql.org. Verzija, ki smo jo za naše potrebe uporabljali, je bila

8.2. Sledimo navodilom. Namestitveni program od nas zahteva, da izberemo jezik

namestitve, obseg funkcionalnosti , kaj vse želimo inštalirat, mesto inštalacije (privzeto je

C:\ProgramFiles\PostgreSQL\8.1). V nadaljevanju (okno Service Configuration) določimo

ime servisa (ponavadi postmaster ali ime različice PostgreSQL-a), administratorsko ime,


domeno in geslo za dostop do podatkovne baze. Določimo še vhodna vrata, preko katerih

dostopamo do baze, disk na katerem se nahaja servis (Locale), kodno tabelo (Encoding) ter

uporabniško ime administratorja SUPB in njegovo geslo. Za zaključek inštalacije določimo

katere dodatne module poleg standardnih modulov še želimo inštalirati.

4.3. Administracija podatkov

Kot administrator podatkovne baze v PostgreSQL se kmalu srečamo s problemom

administracije podatkovne baze v okviru sistema, kot takega. Tako moramo vedeti, kje se

posamezni segmenti podatkovne baze nahajajo, kako lahko dostopamo do podatkov preko

konzole, kako nastaviti določene parametre v datotečnem strežniku, da stvari tečejo hitreje,

ipd.

4.3.1. Orodja za vzdrževanje strežnika PostgreSQL

Podatkovni strežnik je potrebno vzdrževati, da deluje zanesljivo, gladko. Za to obstaja

kar nekaj opravil oziroma orodij. Opravila je mogoče avtomatizirati preko batch fajlov

(izvršnih procedur) v okviru operacijskega sistema, odgovornost administratorja pa je, da

preveri, ali se je rutina uspešno izvedla. Povsem razumljiva naloga je, da administrator

poskrbi za shranjevanje podatkov, prav tako pomembno opravilo je tudi, da sprostimo

diskovni prostor zapolnjen z nepotrebni zapisi v bazi t.i., »Vacuuming« podatkovne baze

ter izvajamo periodično kontrolo log fajlov. PostgreSQL je preprost za vzdrževanje v

primerjavi z ostalimi podatkovnimi sistemi, kljub temu pa moramo vseeno nekaj

pozornosti nameniti tudi tem opravilom. Za prijazno in produktivno delo z PostgreSQL

izvajamo naslednja opravila:

• vacuuming (obnovitev datotečnega prostora-recovering diskspace, updating planner

statistics, auto vacuum)

• ponovno indeksiranje podatkovnih tabel (reindexing)

• shranjevanje dnevnikov (log file maintenance).


Vacuuming

Vacuuming je proces, ki odstrani vse zastarele zapise v naši podatkovni bazi. Redna

uporaba procesa je na PostgreSQL strežniku pogoj za konsistentnost podatkov ter

ohranitev zmogljivosti strežnika. Tako je priporočljivo omogočiti pg_avtovacuum kot

prikriti proces, in sicer z nastavitvijo možnosti parametra autovacuum , stats start_collector

ter stats_row_level na vrednost on. Parametri se nahajajo v konfguracijski datoteki

strežnika, to je postgresql.conf. Ob zanemarljivih vplivih na delovanje strežnika zaradi

sledenja sprememb podatkov pridobimo avtomatično izvajanje procesa.

Proces je bil sprva prepuščen administratorju (pg_avtovacuum) kot dodatna storitev, od

verzije 8.2 pa je vključen v osnovni paket. Proces se avtomatično zažene, ko pride do

določene količine sprememb podatkov. Možno ga je zagnati tudi ročno z ukazom VACUUM.

sintaksa ukaza: VACUUM [ VERBOSE ] [ ANALAYZE ] [table]

primer uporabe:

VACUUM; fizično pobriše vse neuporabne zapise iz podatkovne baze

VACUUM artikel; fizično pobriše vse neuporabne zapise iz tabele artikel

VACUUM FULL; fizično pobriše vse neuporabne zapise iz tabele artikel

Reindex

Ukaz REINDEX ponovno generira indekse, ki se hranijo v indeksnih datotekah za vsako

podatkovno tabelo. Pri tem se glede na postavitev ključev v celoti izdelajo nove indeksne

datoteke, stare se pri tem prepišejo z novimi. Razlogov za uporabo ukaza je več,

najpogostejši je korupcija indeksov. Do korupcije indeksov v praksi pride predvsem pri

programskih napakah oziroma pri strojnih okvarah. Ukaz REINDEX je mogoče uporabiti na

nivoju posameznega indeksa v tabeli, na nivoju podatkovne tabele ali celotne podatkovne

baze. Ukaz REINDEX se ne more uporabljati znotraj transankcije.


sintaksa ukaza: REINDEX {INDEX|TABLE|DATABASE|SYSTEM} name [FORCE]

primer uporabe:

REINDEX artikli; ponovno izdela vse indeksne datoteke glede na

podatkovno tabelo artikli

Analyze

Analyze zbira podatke oziroma pripravi statistiko dostopov do podatkovne baze.

Podatke o tem shrani v sistemsko datoteko pg_statistic, ki jo kasneje plan povpraševanja

(query planner) s pridom uporablja. Pri poizvedovanjih nam pomaga določiti čim boljšo

odzivnost strežnika, saj ima za najpogostejša poizvedovanja optimirano pot. V primeru

poizvedovanja tako hitro pridemo do podatkov. Brez dodatnih parametrov ukaz ANALYZE

pregleda vsako tabelo v podatkovni zbirki , v kolikor pa v parametru podamo tabelo,

opravi analizo le po tej tabeli. Ukaz deluje pritajeno, parameter VERBOSE omogoči prikaz

napredka analize na zaslon.

sintaksa ukaza: ANALYZE [VERBOSE][tabela]

primer uporabe:

ANALYZE artikli; ponovno izdela vse indeksne datoteke glede na

podatkovno tabelo artikli

Kot administrator je dobro, da analizo pripravimo periodično ali vsaj pri velikih

spremembah podatkov v podatkovni bazi. Splošna praksa je, da se za učinkovito izrabo

strežnika, proces požene enkrat na dan, v času manjše obremenitve strežnika.


4.4. SUPB

Za podatkovno bazo PostgreSQL je na voljo več sistemov za upravljanje z

podatkovnimi bazami (SUPB). Nekaj je komercialnih, med katerimi je najbolj znan EMS.

Trenutna verzija je 3.1.; na voljo pa je seveda brezplačen, odprtokoden SUPB, ki se

inštalira ob inštalaciji same podatkovne baze - PgAdmin III.

4.4.1. SUPB - Pg Admin III

Orodje za administracijo podatkov – sistem za upravljanje podatkovnih baz, ki je

priloženo k PostgreSQL, se imenuje Pg Admin III. Zadnja verzija, ki je na voljo, nosi

številko 1.6.3. Je odprtokodnega tipa, tako kot celoten paket, pod pogoji uporabe, ki ne

dovoljuje spreminjanje grafičnega vmesnika (»artistic terms«). Na voljo je v operacijskih

sistemih kot so UNIX, LINUX ter Windows. Pisan je v jeziku C++. Z orodjem je mogoče

dostopati do podatkovnega strežnika PostgreSQL verzije 7.3 in višje. Za starejše različice

PostgreSQL-a je potrebno uporabiti Pg Admin II.

Pg Admin III pričnemo uporabljati tako, da se najprej povežemo s podatkovnim

strežnikom PostgreSQL. V kolikor nimamo shranjenega gesla, je za dostop potrebno

vpisati geslo. Po prijavi v strežnik, se nam na zaslonu prikažejo podatkovne baze, ki so na

voljo. Za dostop do posameznih tabel, izdelavo povpraševanj, ipd.se je potrebno povezati s

podatkovno bazo. To storimo s klikom na željeno podatkovno bazo. Po uspešni povezavi

(podatkovna baza ni prekrižana), so nam na voljo različne funkcije od administracijskih

opravil (določanja pravic, uporabnikov, pravil), do vnašanja podatkov, priprav poizvedb,

ipd.

4.5. Postavitev podatkovne baze

Avtentikacija in avtorizacija sta pojma, ki smo ju bolj podrobno opisali v tretjem

poglavju. Tam smo tudi omenili, kako pomembna je varnost podatkovne baze. V osnovi pa

varnost zagotovimo tako:


• da fizično omejimo dostop do podatkovne baze

• da tiste, ki imajo dostop do baze, ustrezno preverjamo (avtentikacija)

• da različnim uporabnikom ustrezno dodelimo njihove pravice (avtorizacija)

4.5.1. Omejevanje dostopa do podatkovne baze PostgreSQL

Dostop do podatkovne baze mora biti omejen. Kot primer lahko vzamemo spletno

trgovino. Trgovina ponavadi hrani podatke v podatkovni bazi, ki se nahaja na nekem

ločenem podatkovnem strežniku. Ponavadi ne želimo, da lahko do baze pride vsak

obiskovalec spletne trgovine, ampak samo strežnik, na katerem teče vaša spletna

aplikacija. To lahko dosežemo tako, da ustrezno omejimo dostop do strežnika ter še

dodatno omejimo dostop do same podatkovne baze na strežniku preko njenih nastavitev.

Dostop do podatkovne baze PostgreSQL nastavljamo v pg_hba.conf datoteki. Tam

lahko določimo, za koga je baza vidna ter do katerih baz bo lahko dostopal kateri

uporabnik in kakšno šifriranje bo uporabljeno. Privzeto je PostgreSQL nastavljen tako, da

je dostopen samo za procese, ki tečejo na istem strežniku, za enkripcijo pa se uporablja

algoritem MD5. Na spodnji (sliki 4.1.), ki je sicer izrez konfiguracijskih nastavitev

datoteke pg_hba.conf, vidimo nekaj tipičnih nastavitev dostopa do podatkovne baze [21].

# Dovolimo da se vsak lokalni uporabnik lahko poveže do vsake

# podatkovne baze in pri tem ne uporablja enkripcije.

#

# TYPE DATABASE USER CIDR-ADDRESS METHOD

local all all trust

# Enako kot zgoraj vendar omejimo dostop še z IP-MASK atributom.

#

# TYPE DATABASE USER IP-ADDRESS IP-MASK METHOD

host all all 127.0.0.1 255.255.255.255 trust

# Dovolimo dostop vsakemu uporabniku, ki ima IP 192.168.93.x

# do pb postgresql

#


host postgres all 192.168.93.0/24 ident sameuser

# Uporabniku z IP-jem 192.168.12.10 dovolimo dostop do pb

# "postgres", pri tem pa preverjamo password, ki mora biti

# enkriptiran z md5 algoritmom

#


host postgres all 192.168.12.10/32 md5

slika 4: primer pg_hba.conf datoteke


4.5.2. Opis postavitve shem, pravic, uporabnikov

Avtentikacija in avtorizacija se v praksi zagotovita tako, da na podatkovni bazi

naredimo več uporabnikov, nato pa vsakemo točno določimo njegove pravice. Vsaka

podatkovna baza PostgreSQL ima v osnovi samo eno podatkovno shemo, to je shema z

imenom »public«. Kot že samo ime nakazuje, lahko do nje dostopajo vsi uporabniki in

imajo tudi polni dostop. Seveda takšen pristop ni najbolj varen. Priporočljivo je, da

uporabimo več podatkovnih shem in v njih razporedimo tabele glede na funkcionalnost, ki

jo uporabljajo. Tako načrtujemo, da tabele, v katerih se nahajajo dnevniki (logs) in sledi

(trace), aplikacije zagotovo umestimo v drugo shemo kot na primer podatke o izdanih ali

prejetih računih.

Naslednji sliki (slika 8., slika9.) prikazujeta, kako v orodju pgAdmin naredimo novo

shemo in ji določimo nivo dostopa za posamezne skupine uporabnikov oziroma za

določene uporabnike. Za potrebe diplomske naloge smo naredili tri podatkovne sheme:

• sch_products, kjer so tabele, ki so povezane s poslovanjem

• sch_logs, kjer so tabele z dnevniki aplikacij.

• sch_trace, kjer so tabele z sledmi aplikacij.

slika 5: kreiranje podatkovne sheme


Uporabniki podatkovne baze PostgreSQL lahko glede na njihove fukcije razdelimo v

različne skupine (group roles), ki jim določimo do katerih shem oziroma tabel bodo lahko

dostopali in kakšne pravice bodo imeli.

slika 6: kreiranje nove uporabniške skupine

Skupine so ponavadi različne, ampak že v osnovi bi morali imeti vsaj dve skupini, to

sta: skrbniki podatkovne baze (Administrators) in uporabniki (Users). Administratorji

imajo ponavadi polni dostop do vseh shem, tabel, funkcij. Le-te lahko poljubno

spreminjajo. Navadni uporabniki imajo veliko bolj omejen dostop do podatkovne baze.

Ponavadi lahko iz nje le berejo in brišejo, ne morejo pa dodajati ali brisati tabel, ključev ali

funkcij.

Za potrebe diplomske naloge smo naredili tri skupine:

• Administrators: skupina z polnim dostopom

• Data: skupina, ki lahko na določenih shemah kreira in briše tabele, ključe, ...

• ReadWrite skupina, ki lahko samo bere in spreminja podatke


Ko dodajamo nove uporabnike podatkovne baze, jim najprej določimo ime, geslo in

datum, ko veljavnost računa preneha, nato pa uporabnike razporedimo v uporabniške

skupine, kar prikazuje spodnja slika (slika 10.).

slika 7: kreiranje uporabnika, določitev skupine

PostgreSQL nam torej omogoča, da zelo natančno opredelimo dostop do podatkovne baze

in tako ustrezno poskrbimo za varnost.

4.5.3. Opis izdelave varnostne kopije podatkovne baze

Kot smo že v 3. poglavju videli, je kar nekaj možnosti za pripravo varnostne kopije

podatkovne baze. Glede na potrebe izberemo način arhiviranja, ki nam najbolj ustreza. V

nalogi smo pogledali dva načina, in sicer:

• uporaba ukaza pg_dump v konzolnem načinu dela

• uporaba orodja v sklopu SUPB PgAdminIII


4.5.3.1. Uporaba ukaza pg_dump v konzolnem načinu dela

Je proces, ki je shranjen v \bin imeniku. Uporabljamo ga v konzolnem načinu dela.

Shell proceduro smo zapisali v batch datoteko backup.bat, ki napravi s pomočjo ukaza

pg_dump varnostno kopijo baze. Izvršno datoteko (angl. batch file) lahko kasneje s

pomočjo razporejevalnika opravil (Scheduled task manager) periodično avtomatično

poganjamo. Parametri ukaza so zapisani v tabeli 8. Proces deluje zamesljivo ter hitro.

Strežnik (postmater) pri tem ni potrebno izključiti.

Sintaksa: pg_dump -i -h localhost -p 5432 -U root -F c -b -v -f

ime_arhivske datoteke ime_podatkovne baze

tabela 8: parametri ukaza pg_dump

- a Shranjevanje podatkov, brez sheme - b Dodajanje velikih objektov v varnostno datoteko - c Brisanje sheme pred ponovnim kreiranjem - C Vsebuje tudi ukaze za kreiranje podatkovne baze - f Ime varnostne datoteke - F {c|t|p} Tip zapisa varnostne datoteke (c=custom,t=tar format,p=plain text) - h Ime lokalnega strežnika - i Izdelava varnostne kopije, kljub nesoglasjim med verzijami pg_dump ter

psql - p Številka vrat, preko katerih teče povezava - s Shranjevanje sheme, brez podatkov - S Ime administratorja baze (ponavadi: superuser, postgres, root) - t Shranjevanje določene tabele - U Ime uporabnika baze za dostop do le-te - v Verbose - W Geslo uporabnika, ki dostopa do baze - Z {0-9} Način, stopnja kompresije-stiskanja varnostne datoteke (od 0 do 9) primer uporabe:

"C:\Program Files\PostgreSQL\8.2\bin\pg_dump.exe" -i -h localhost

-p 5432 -U root -F c -b -v -f "E:\arhiv\ myBackup.backup" sbm


4.5.3.2. Uporaba orodja v sklopu SUPB PgAdminIII

Varnostno kopijo v PgAdmin III pripravimo s pomočjo nekaj klikov skozi menijske ukaze.

Ti skozi uporabniško vodeni meni nadomeščajo konzolni način uporabe ukaza pg_dump.

Po zagonu PgAdmin III izberemo najprej strežnik na katerem želimo delati. PgAdmin III

od nas zahteva administratorsko ime in geslo za dostop do strežnika. Po uspešni prijavi na

strežnik, se na zaslonu prikažejo podatkovne baze, ki so nam na voljo. Odpremo željeno

podatkovno bazo ter poiščemo meni Orodja, opcijo Varnostna kopija. V oknu Varnostna

kopija izberemo mesto ter ime datoteke, kamor se shrani varnostna kopija naše podatkovne

baze (slika 11.). Okno potrdimo z gumbom Ok. Varnostna kopija podatkovne baze se

shrani v datoteko s končnico .backup. Okno zapremo s pritiskom na gumb Done. Za

dnevno arhiviranje podatkov ta princip ni primeren, ker nima možnosti avtomatiziranja

procesa. Varnostno kopijo na ta način izvedemo v primeru administracije podatkovne baze

večjega obsega, npr. preselitve podatkovne baze na drug računalnik.

slika 8: določimo ime ter mesto datoteke


4.5.4. Povrnitev podatkov iz varnostne kopije

Povrnitev podatkov je tako uspešna, kot smo predhodno dobro izdelali varnostno

kopijo. Pri tem je pomembna lokacija, kot tudi medij, kamor hranimo varnostne kopije.

Prav tako je pomembno glede na frekventnost podatkov, koliko kopij izdelujemo. V

nadaljevanju bomo pregledali dve vrsti povrnitve, in sicer:

• s pomočjo pg_restore ukaza v konzolnem načinu dela

• s pomočjo orodja Restore v SUPB PgAdmin III

4.5.4.1. Uporaba ukaza pg_restore v konzolnem načinu dela

Je proces, ki je shranjen v \bin imeniku. Namenjen je obnovi podatkov, ki so bili shranjeni na medij s pomočjo pg_dump. Uporabljamo ga v konzolnem načinu dela. Sintaksa: pg_restore ime_arhivske datoteke ime_podatkovne baze

Primer: "C:\Program Files\PostgreSQL\8.2\bin\pg_restore.exe" "E:\arhiv\

myBackup.backup" sbm

4.5.4.2. PgAdminIII

Postopek obnovitve podatkov v PgAdmin III je podoben kot pri izdelavi varnostne kopije.

Prijavimo se v podatkovni strežnik ter povežemo s podatkovno bazo, ki jo želimo povrniti.

V primeru, ko podatkovna baza ne obstaja, jo je potrebno predhodno kreirati. Označimo

podatkovno bazo, v kateri želimo obnoviti podatke. V meniju Orodja izberemo opcijo

povrnitev podatkov. Na zaslonu se nam pojavi novo okno, v katerem izberemo varnostno

kopijo. Izbiro potrdimo z gumbom Ok (slika 4.11.). Po zaključku se na zaslonu pokaže

sporočilo o uspešnosti povrnitve (slika 4.12.). Pri tem je potrebno vedeti, da tabele, ki jo

želimo povrniti, ne smemo imeti predhodno kreirane.


Obnovo podatkov je priporočljivo izvesti s pomočjo PgAdmin III., kjer določimo, ali

je obnova delna ali popolna. V primeru popolne obnove kreiramo podatkovno bazo z

enakim imenom kot je bila originalna (originalno pred tem pobrišemo), pri delni obnovi pa

obnovimo le tisto, kar je v originalni podatkovni bazi manjka. Obnovo na nivoju vrstice

izvajamo s pomočjo dnevnika WAL (poglavje 3.4). Vsekakor pa moramo paziti kaj in na

kakšen način obnovimo podatke. Celotna obnovitev podatkov, prav tako obnovitev

posamezne tabele v realnih okoljih je redka, v večini situacijah neprimerna. V primeru

povrnitve celotne podatkovne baze, pod pogojem, da imamo konsistetno rezervno kopijo,

so ti podatki kljub vsemu stari nekaj ur. Tako kljub uspešni povrnitvi manjkajo podatki za

tisti čas, ko baza ni bila arhivirana. V primeru obnovitve podatkov posamezne tabele je

obnova z vidika zagotavljanja konsistentnega stanja podatkovne baze nedopustna. Zlasti v

realnih okoljih je podatkovna baza sestavljena iz velikega števila med seboj povezanih

tabel. Že entitetno-relacijski model nakazuje na pogosto vplivanje akcij oziroma sprememb

ene potrjene transakcije na podatke, shranjene v več med seboj povezanih tabelah. Tukaj

ne gre zgolj za neposredne povezave. Iz vidika zagotavljanja konsistentnega stanja

podatkovne baze so med tabelami pomembne vse povezave, tudi posredne [22].

slika 9: poiščemo varnostno kopijo iz katere želimo povrniti podatke


slika 10: obvestilo, da je povrnitev končana

4.5.5. Opis postavitve replikacijskega strežnika

Replikacijo podatkovne baze PostgreSQL lahko naredimo na dva načina:

• s pomočjo uporabe konzolnega načina dela

• uporaba orodja v sklopu SUPB PgAdminIII (verzija1.6.3)

V primeru, ko uporabimo orodje PgAdminIII, nam le-ta olajša delo, saj namesto nas

zgradi in zažene ukaze, ki so potrebni za postavitev replikacije. V diplomskem delu smo se

tako osredotočili na replikacijo s pomočjo orodja PgAdminIII.

Replikacija [21] v osnovi sestoji iz štirih osnovnih korakov:

1. Inštalacija replikacijskega mehanizma Slony-I na vsakem strežniku, kjer se nahaja

PostgreSQL in ki bo sodeloval v replikaciji.

2. Kreiranje najmanj dveh identičnih podatkovnih baz (gospodarja in enega ali več

sužnjev).

3. Registracija in konfiguracija Slony-I servisov.

4. Uglasitev podatkovnih baz in Slony-I servisov.


Inštalacija replikacijskega mehanizma Slony-I

Slony-I se je do verzije 8.2.5 namestil kot samostojni dodatek h podatkovni bazi

PostgreSQL. Vse novejše verzije sedaj vsebujejo Slony-I kot del podatkovne baze in ga na

željo uporabnika tudi namestijo.

Kreiranje podatkovnih baz

Da lahko postavimo replikacijo, moramo najprej imeti najmanj dve, lahko pa tudi več,

podatkovnih baz. Le te morajo imeti identično strukturo shem, tabel in ostalih elementov.

V nasprotnem primeru bo replikacija nemogoča. Seveda si pri tem lahko enostavno

pomagamo tako, da najprej ustvarimo podatkovno bazo, ki jo imenujemo gospodar

(master). Na ustvarjeni podatkovni bazi napravimo varnostno kopijo (poglavje 4.5.3), ki jo

nato povrnemo (poglavje 4.5.4) na vseh ostalih podatkovnih bazah, ki jih imenujemo

sužnji (slave). To najlažje opišemo z naslednjimi stavki:

pg_dump –s –U root master > testschema.sql

psql –U root slave1 < testschema.sql

Rezultat zgornjih stavkov sta torej dve identični podatkovni bazi (gospodar in suženj1). Po

potrebi lahko seveda naredimo več podatkovnih baz.

Registracija in konfiguracija Slony-I servisev

Vsaka podatkovna baza ponavadi teče na svojem strežniku. Če nameravamo

podatkovno bazo uporabiti v replikaciji, mora na strežniku teči Slony-I servis, kar lahko

enostavno naredimo z naslednjim ukazom, ki ga poženemo na vsakem strežniku:

slon –regservice Slony-I


Posledično se servis Slony registrira kot windows servis in se bo tudi avtomatično

zagnal ob zagonu strežnika. Ko Slony uspešno teče na vsakem strežniku, ga moramo

povezati s podatkovno bazo, ki teče na strežniku. To naredimo tako, da kreiramo dve

konfiguracijski datoteki, ki jo poimenujemo master.conf in slave1.conf. Obe vsebujeta dve

vrstici, kjer prva definira ime gruče (cluster name), druga pa povezavo do podatkovne

baze.

tabela 9: vsebina datoteke master.conf

cluster_name='test1'

conn_info='host=127.0.0.1 port=5432 user=root dbname=master

password=root'

tabela 10: vsebina datoteke slave1.conf

cluster_name='test1'

conn_info='host=127.0.0.1 port=5432 user=root dbname=slave1

password=root'

Nato na strežniku, kje imamo podatkovno bazo »master« poženemo ukaz:

slon –addengine Slony-I »c:\slony\master.conf«

Enako naredimo tudi na strežniku, kjer se nahaja podatkovna baza »slave1«

slon –addengine Slony-I »c:\slony\slave1.conf«

Uglasitev podatkovnih baz in Slony-I servisev.

Če smo zgornje zaporedje dobro izvedli, imamo sedaj dva strežnika, na katerih se

nahajata dve podatkovni bazi, na vsakem pa ustrezno teče tudi Slony-I proces, ki je že

povezan s podatkovno bazo. V tem trenutku se Slony-I proces zaveda, da na strežniku

obstaja podatkovna baza »master« oziroma »slave1«, vendar pa podatkovne baze ne vedo,

da morajo delovati v replikacijskem načinu. Da to dosežemo, moramo izvršiti naslednjih

nekaj korakov. V prvem koraku izvedemo kreiranje nove gruče »test1« na podatkovni bazi

»master« (slika 14.), v drugem koraku pa dodajanje podatkovne baze »slave1« v obstoječo

gručo »test1« (slika 15.).


Slika 11: na podatkovni bazi »master« napravimo gručo test1

Slika 12: dodajanje podatkovne baze »slave1« v gručo test1


V tem trenutku se podatkovni bazi že zavedata ena druge, prav tako se zavedata procesa

Slony-I, ki bo izvajal replikacijo (slika 16.).

Slika 13: Podatkovni bazi »master« in »slave1« se zavedata ena druge

Omeniti je potrebno, da smo imeli ob izdelavi replikacije obilico problemov, saj se v

nekaterih primerih podatkovna baza ni znala povezati s Slony-I servisom, ki teče na obeh

strežnikih. To najlažje preverimo tako, tako da v orodju PgAdminIII pogledamo vozlišča

MasterNode in SlaveNode. Na obeh mora biti nastavljen parameter Running PID, kar

pomeni, da se je podatkovna baza uspešno povezala s Slony-I windows procesom, ki bo

izvajal replikacijo (slika 17.).


Slika 14: v primeru, da »Running PID« na enem izmed vozlišč ni nastavljen je prišlo do napake v enem

izmed prejšnjih korakov

V koraku 3 izvedemo ustvarjanje komunikacijskih poti med podatkovnima bazama. Da se

obe podatkovni bazi med seboj lahko pogovarjata, je potrebno na vsakem vozlišču

ustrezno nastaviti poti (path). Tako moramo na vozlišču »MasterNode« na podatkovni bazi

»master« nastaviti pot do podatkovne baze »slave1«, na vozlišču »SlaveNode« na

podatkovni bazi »slave1« pa nastaviti pot do podatkovne baze »master«. To najbolj

nazorno prikazujejo naslednje slike (slika 18. in slika 19.).


Slika 15: na vozlišču »MasterNode« definiramo povezave do podatkovne baze »slave1«

Slika 16: na vozlišču »SlaveNode« definiramo parametre povezave do podatkovne baze »master«


V koraku 4 pripravimo konfiguracijo replikacijske množice. Ko imamo replikacijo

ustrezno nastavljeno, je potrebno nastaviti samo še to, katere tabele in sekvence bomo

pravzaprav replicirali. Nesmiselno bi bilo seveda replicirati popolnoma vse tabele in

zaporedja. To bi zelo obremenilo povezavo med obema podatkovnima bazama. Slony-I to

rešuje tako, da uporablja replikacijske množice (replication sets), v katerih določimo katere

tabele in zaporedja bomo replicirali in kdo bo prejemnik (slika 20.).

Slika 17: prikazuje, kako napravimo replikacijsko množico

Naslednja slika (slika 21.) prikazuje primer, ko v podatkovni bazi »master« napravimo

replikacijsko množico »rep set 1« v kateri povemo, da bomo replicirali tabelo

»testSchema.testTable« v istoimensko tabelo na podatkovni bazi »slave1«. Rezultat je

seveda očiten; kadar spremenimo podatke v tabeli »testSchema.testTable«, v podatkovni

bazi »master« so spremembe vidne tudi v podatkovni bazi »slave1«. Kot zanimivost naj

povemo še to, da obratni postopek ni možen. PostgreSQL nam namreč ne dovoli

spreminjati podatkov v podatkovni bazi »slave1«. To izhaja iz dejstva, da je replikacija

Slony enosmerna »Master – Slave« replikacija.


Slika 18: prikazuje, kako smo v podatkovni bazi »master« definirali replikacijsko množico »rep set 1«,

ki replicira tabelo »testSchematestTable« na podatkovno bazo »slave1«


5. Zaključek

V diplomskem delu smo prikazali osnovne pojme, kaj podatkovna baza je, se

sprehodili skozi zgodovino podatkovnih baz ter pregledali trenutne komercialne in

odprtokodne podatkovne baze, ki so trenutno na tržišču. Nakazali smo probleme varnosti

podatkovnih baz nasploh ter opisali procese kot so avtorizacija, avtentikacija, enkripcija,

transakcije in zaklepanje podatkov. V nadaljevanju smo se omejili na zaščito in varnost

podatkovne baze PostgreSQL. Opisali smo osnovne varnostne mehanizme, s katerimi se

izognemo nazaželjenemu vdoru v našo podatkovno bazo oziroma nezaželjeni izgubi

podatkov. Za konec smo prikazali praktične rešitve v zvezi s tem.

V nalogi smo opisali možnosti varovanja in zaščite podatkov, replikacije ter nakazali

rešitve v tej smeri. Shranjevanje podatkov, obnova podatkov delujeta hitro in zanesljivo.

Strežnika pri tem ni potrebno izključiti. Opravilo lahko zapišemo v izvršno (batch)

datoteko, s pomočjo razporejevalnika opravil (Scheduled task manager) pa določimo

periodično ponavljanje opravila. Vidimo, da je uporaba preprosta. Pri obnovi podatkov pa

je potrebno upoštevati kaj in kako obnoviti podatke, da konsistentnost podatkovne baze

ostane nedotaknjena.

Posebno pozornost smo namenili rešitvi replikacije, ki sicer deluje v sklopu

PostgreSQL-a, vendar je samostojno orodje. Replikacija podatkovnih baz še do nedavnega

ni bila lastnost odprtokodnih podatkovnih baz. Šele z zadnjimi izdajami je lastnost prišla

tudi v odprto kodne produkte, katerih predstavnik je tudi PostgreSQL. Replikacija ni

vezana na posamezno verzijo PostgreSQL-a, temveč deluje v različnih verzijah. Glede

replikacije je treba povedati, da je potrebno kar nekaj truda, da se jo postavi. V tem

pogledu nas je podatkovna baza PostgreSQL razočarala, saj bi pričakovali manj nastavitev.

V kolikor v replikacijski set dodamo vse tabele, ki so v podatkovni bazi, postane delovanje

strežnika počasno. Ugotovili smo, da je za optimalno delovanje strežnika potrebno zelo

paziti, katere datoteke določimo za podvajanje v replikacijskem setu. Prav tako se je

Slony-I izkazal za dokaj neuporabnega, saj ne omogoča »multiple master to multiple

slave« replikacije, kar je pravzaprav največja odlika komercialnih podatkovnih baz, kot sta

Oracle ali SQL Server. Replikacija »single master to multiple slaves« sicer zagotavlja

možnost, da v primeru okvare gospodarja njegovo vlogo prevzame eden izmed sužnjev,

vendar je to potrebno napraviti ročno. Slony-I namreč ne zazna, da je prišlo do napake na


gospodarju. V velikih okoljih, kjer se dnevno skozi bazo prebere ali zapiše velika količina

podatkov, sta omenjeni pomankljivosti nujno potrebni in pričakovani lastnosti. Brez dvoma

lahko rečemo, da za takšna okolja podatkovna baza PostgreSQL ni primerna, čeprav lahko

še vedno brez dvoma trdimo, da gre za najboljšo odprtokodno podatkovno bazo. Po

napovedih je v pripravi replikacijski sistem Slony-II, ki bi naj omogočal sinhrono

replikacijo večih strežnikov v realnem času, torej odpravlja vse zgoraj naštete

pomanjkljivosti.

Podatkovna baza PostgreSQL ima prihodnost, saj za njo skrbi zelo velika odprtokodna

skupnost. Prav tako bi lahko uporabo le-te priporočili vsakomur, ki načrtuje majhne do

srednje velike aplikacije, saj gre za zelo zrel in stabilen produkt. Mislimo tudi, da bo s

prihodom Slony-II replikacijskega mehanizma PostgreSQL posegel tudi v velika in visoko

zahtevna okolja, za katera trenutno še ni primeren.

PostgreSQL je v tem trenutku zagotovo ena izmed najbolj zmogljivih odprtokodnih

podatkovnih baz. Uveljavlja se na vseh področjih dela, tako v povezavi s spletnim

strežnikom Apache kot tudi v samostojnem načinu dela. Rešitve, tudi slovenske (Slo-tech

forum, projekt AVRIS za avtobusne prevoznike, ipd.), prav to potrjujejo.


6. Literatura

[1] Mohorič, Tomaž: Podatkovne baze, Fakulteta za računalništvo in informatiko,

Univerza v Ljubljani, Ljubljana, 2002.

[2] Prosojnice: Podatkovne baze I, Tatjana Welzer-Družovec, 2002,2003

[3] Prosojnice: Podatkovne baze II, Tatjana Welzer-Družovec, 2001,2002

[4] Prosojnice: Zaščita podatkov, Tatjana Welzer-Družovec, 2002

[5] Mohorič, Tomaž:Načrtovanje relacijskih podatkovnih baz, Ljubljana 1997

[6] Mohorič, Tomaž: Podatkovne baze, Fakulteta za elektrotehniko in

računalništvo,Univerza v Ljubljani, Ljubljana 1991

[7] Korry, Susan Douglas: PostgreSQL second edition, Sams Publishing 2006

[8] Computer World Magazine, http://si.zone-h.org/content/view, zadnjič obiskano

28.01.2008

[9] Bell David, Grimson Jane: Distributed Database System, Workingham, Addison-

Wesley Publishing Company, 1992

[10] David Knox: Effective Oracle Database 10g security by design, New York, 2004

[11] A. Romero, L. Ashdown, Oracle Database Backup and Recovery Basic, 10g

Release 1 (10.1), 2003

[12] Matthew Hart, Oracle Database 10g Rman Backup & Recovery, McGraw-Hill,

2007

[13] Relational Database Dictionary, Chase, 2006

[14] Begining PHP and PostgreSQL 8 From Novice to Professional, W.Jason Gilmore

and Robert H.Treat, Apress, 2006

[15] http: //www.postgresql.org, zadnjič obiskano 01.12.2007

[16] http://www.mojmikro.si/?id=807&n=news&start=50, zadnjič obiskano 20.06.2007

[17] Concurrency: Deadlock and Starvation. URL: http://www.lincoln.edu/math, zadnjič

obiskano 12.12.2007

[18] http://www.geocities.com/mailsoftware42/db/, zadnjič obiskano 12.12.2007

[19] http://www.devx.com, zadnjič obiskano 12.12.2007

[20] http://databases.about.com, zadnjič obiskano 12.12.2007

[21] PostgreSQL 8.2.5. Documentation, The PostgreSQL Global Development Group,

2007


[22] Petra Grm, Obnova podatkovne baze - diplomsko delo, Univerza v Mariboru-

Fakulteta za računalništvo in informatiko, januar 2006

[23] http://blog.rsh.si/pages/180.aspx, zadnjič obiskano 22.01.2008

[24] http://www.erevir.si/Moduli/Clanki/Clanek.aspx?ModulID=2&KategorijaID=21&

ClanekID=318, zadnjič obiskano 22.01.2008

[25] Mohorič, Tomaž: Uvod v podatkovne baze, Ljubljana 1995

Documents

VARNOST PODATKOVNE BAZE PostgreSQL - core.ac.uk · podatkov, ki jih sre čujemo v okviru svetovnega spleta (slike, zvok, animacije, VRML, Java apleti, ipd). Slabost objektnih baz