Scenarij 3: Obstoječa podatkovna baza

5.3 Scenarij 3: Obstoječa podatkovna baza

Kaj imamo?

Pogosto so podatki shranjeni in arhivirani v podatkovni bazi, ki je bila primarno ustvarjena za delovanje aplikacije, ki podpira določen poslovni proces. Ker so te podatkovne baze optimizirane za podporo aplikacijam in ne za odpiranje podatkov, je treba pred izvozom opraviti določene transformacije. Tipično so te podatkovne baze sestavljene iz več tabel, ki so medsebojno povezane s podatkovnimi ključi (relacijski model). Aplikacije so navadno razvite za interne namene v enem od notranjih okolij (npr. razvita v Javi, .NET ali APEX), podatkovna baza pa je navadno ena od standardnih baz, ki so uporabljene v javnem sektorju (npr. Oracle, SQLServer, PostgreSQL ipd.). 

Kaj naredimo?

Cilj je pridobiti eno ali več nepovezanih datotek (flat file), ki v celoti predstavljajo vsebino podatkovne baze. Le v redkih primerih, ko je produkcijska podatkovna baza zelo enostavna (ne vsebuje relacij), lahko podatke izvozimo s preprosto kopijo podatkovne baze. V večini primerov je pred izvozom treba opraviti kompleksno transformacijo. Pred izvozom je tako treba pridobiti in pretvoriti podatke iz aplikacijske podatkovne baze, in sicer na način, da bodo tabele pripravljene za izvoz oziroma odpiranje. Proces transformacije zahteva natančno načrtovanje izhodnih tabel in mapiranje podatkov, združevanje več tabel, vključevanje vrednosti iz šifrantov v osnovno tabelo, nadomeščanje indeksov z referenciranimi vrednostmi itd. Zaradi kompleksnosti je navadno treba opraviti več korakov, da pridobimo enovito in celovito različico podatkovne baze. Pristopi k pridobitvi podatkov iz aplikacijske podatkovne baze Večina sistemov za upravljanje podatkovnih baz (DBMS) že vsebuje standardne tehnike za izvoz nepovezanih datotek (flatfiles): Oracle: orodje EXPORT Microsoft: čarovnik (wizard) SQL Server Import in Export MySQL: orodje mysqldump PostgreSQL: procedura SQL Dump Kadar se podatki v podatkovni bazi spreminjajo pogosto, je smiselno razviti program, ki bo sposoben redno izvažati podatke iz DBMS prek gonilnikov ODBC in JDBD. Smiselno je tudi, da se podatki v preoblikovani obliki začasno ali permanentno shranjujejo v osnovni podatkovni bazi oziroma da so procedure zasnovane na način, ki omogoča vsakokratno pridobitev ažurne kopije celotne podatkovne baze v preoblikovani obliki.

Glede na velikost podatkovne baze in nespremenljivost podatkovnih struktur (tabel, atributov, relacij…) se tudi odločimo za enega od načinov za objavljanje sprememb podatkov:

• vsakokratni izvoz celotne podatkovne baze z vsemi podatki ali

• po inicialnem izvozu celotne podatkovne baze se objavljajo redni»popravki« oziroma spremembe v podatkih.

Pristopi k transformaciji podatkov

Po oblikovanju nepovezanih datotek je podatke skoraj vedno treba dodatno preoblikovati, da postanejo prijaznejši do človeškega branja oziroma da postanejo razumljivi tudi tistim, ki se prvič srečajo s podatki iz podatkovne baze. Imena polj in vrednosti je treba poenotiti, v primeru okrajšav se (kjer je to smiselno in izvedljivo) uporabijo polna poslovenjena imena (namesto "TMSTMP" se zapiše "Časovni žig" ali "CASOVNI_ZIG"), namesto indeksov se vnesejo nadomestne vsebinsko opisne vrednosti (namesto "0" v polju "SPOL" se zapiše "Moški"), hkrati je treba podatke anonimizirati in poskrbeti za enotno zrnatost podatkov (granularity) – npr. naslov se lahko zapiše v enem polju (Naslov: "Celovška cesta 140, 1000 Ljubljana") ali v štirih poljih (Ulica:"Celovška cesta", Številka ulice:"140", Poštna številka:"1000", Ime pošte:"Ljubljana").