Tietoarkkitehtuurista

Onko tietoarkkitehtuurin (informaatioarkkitehtuurin) laatiminen vaikeaa, onko se työlästä ja kalenteriaikaa vievää? Miten liiketoimntaihmiset saa mukaan?

Jos oikeat liiketoimintaihmiset saadaan mukaan käsitemallinnukseen, voidaan yllättävänkin nopeasti saada aikaan hyvät mallit ja kuvaukset organisaation keskeisistä tiedoista eri tietojärjestelmissä. Samalla myös määritellään käsitteet, jolloin sovitaan yhdessä onko se artikkeli, tuote tai materiaali sama vai eri asia. On tärkeää että mallinnuksen vetäjä on kokenut ja osaa ratkoa ristiriitoja. Liiketoimintaihmiset ovat aina kiireisiä, joten tehdä työpajojen on oltava mahdollisimman tehokkaita. Oikein organisoituna, ja hyviä menetelmiä käyttämällä on saatu aikaan hyvät kuvaukset ja mallit rasittamatta käyttäjiä liikaa - muuten he helposti jäävät tulematta seuraaviin istuntoihin. Mallinnuksessa osallistujat lisäksi oppivat toisiltaan ja sitoutuvat.

Tietoarkkitehtuurin rooli kokonaisarkkitehtuurissa on keskeinen. Käsitteiden määrittely tukee ja helpottaa sovellus- ja prosessiarkkitehtuurien laatimista.

ERP-järjestelmien hankinnassa keskitytään yleensä prosesseihin ja tiedot, tietorakenteet ja niiden määritelmät jäävät taka-alalle. Tietomalleja ei juuri käsitellä. Tämä voi pysäyttää tietokeskeisen ajattelun jopa vuosiksi. Tiedot ja tietojen rakenteet ovat kuitenkin huomattavasti pysyvämpiä ajan saatossa kuin prosessit – vähän kuin talon perustukset. Koskaan ei kuitenkaan ole myöhäistä aloittaa tietojen saamista hallintaan tietoarkkitehtuurimenetelmien avulla.

Pakko-SQL?

Pakkoruotsi lopetettiin, tarvittaisiinko pakko-SQL?

SQL on levinnyt käytännössä ainoaksi tietokantakieleksi. Oracle, SQL Server, DB2, MySQL ja monet muut tietokannat ovat SQL-pohjaisia Itse asiassa ne eivät ymmärrä muuta kieltä kuin SQL.

SQL näyttää helpolta ja alkuun pääseekin aika vaivattomasti. Toisaalta se on myös hyvin voimakas ja ilmaisuvoimainen kieli. Yllättävän moni DW/BI –alueella toimiva henkilö ei kuitenkaan osaa SQL:aa kovin syvällisesti. Monet BI-tuotteethan generoivat SQL:aa, joten syntyy vaikutelma, että ei sitä tarvitse osatakaan. Itse olen sitä mieltä, että SQL:n hyvästä hallinnasta on suurta hyötyä lataustoimissa, tietovarastotietokannan tutkimisessa ja testaamisessa, raporttien laatimisessa – itse asiassa sille on käyttöä lähes koko ajan. Tiukoissa paikoissa vain SQL:aa kirjoittamalla saadaan riittävä suorituskyky.

Olen harrastanut ja käyttänyt SQL-kieltä siitä lähtien, kun ensimmäisen kerran pääsin sitä kokeilemaan. Kyseessä oli Oraclen 4.2 –versio IBM:n ensimmäisessä PC:ssä. ”Uskomatonta miten paljon ohjelmointia voin säästää muutamilla liitoksilla” ajattelin tuolloin innostuneena. Sittemmin olen kirjoittanut pari kirjaakin aiheesta. Olen vuosien saatossa hionut esimerkkejä ja harjoitustehtävia ja koulutan edelleen SQL- peruskurssia ja laajempaa SQL syventävät päivät kurssia. Ideana on runsaiden harjoitustehtävien ja väliin lomitetun teorian avulla saada mukaan työpaikalle heti käyttöön otettavissa olevaa osaamista.

No – pakko-SQL:aa en kannata, mutta suosittelen lämpimästi vapaaehtoista opiskelua.

Osaatko indeksoida tietokantasi?

Relaatiotietokannan käytännön suorituskykyyn vaikuttaa ratkaisevasti se, minkälaiset indeksit tauluille on määritelty (jos termi ei ole tuttu, kerrottakoon lyhyesti: indeksit ovat erillisiä tietorakenteita, jotka nopeuttavat tietojen hakuja; tietokantojen optimoijat käyttävät indeksejä automaattisesti hyväksi; indekseihin ei viitata ohjelmissa, joten tietokantaa voi tehostaa indeksejä virittämällä – koskematta ohjelmiin ja kyselyihin).

Vaikka indeksien vaikutus suorituskykyyn tunnetaan yleisesti, asiasta on yllättävän vähän tietoa saatavissa. Tiedossani ei esimerkiksi ole kuin yksi nimenomaan indekseihin syvällisesti paneutuva kirja. Kyseessä on ”Relational Database Index Design and the Optimizers”, kirjoittajina Tapio Lahdenmäki ja Mike Leach.

Kirjan kirjoittaja, ystäväni Tapio Lahdenmäki on vuosikausia tutkinut indeksointia ja kehittänyt ainutlaatuisia menetelmiä ja kaavoja tälle alueelle. Hän on myös käytännössä konsultoinut ja testannut menetelmiään ja niillä on saatu hämmästyttäviä tuloksia. Tapahtumankäsittely-ympäristössä joidenkin tapahtumien vastausaika saattaa hidastua, jopa pariin minuuttiin. Tapsan indeksointimenetelmillä vastausaika saadaan pariin sekuntiin tai jopa alle sekuntiin. Aikamoinen prosentuaalinen parannus! Ja mikä parasta: parannus tehdään indeksointia muuttamalla: ohjelmiin ei tarvitse koskea!

Uskon, että monet sovellukset ja tietovarastoratkaisut tälläkin hetkellä tekevät aivan turhaa ja hidasta levylukutoimintaa. Ongelmaa ratkotaan pahimmillaan vaihtamalla isompaan koneeseen – kun ratkaisuksi riittäisivät suhteellisen yksinkertaiset indeksointitoimet.

Miten oppia indeksoimaan? Lahdenmäen Tapsan kirja on hyvä tietolähde. Tapsa on myös kehittänyt yli kymmenen vuoden ajan indeksointikurssiaan ja sen hyvin tarkkaa ja havainnollista materiaalia. Tapsa on tehnyt pitkän päivätyön IBM:n spesialistina ja itsenäisenä konsulttina ja on nyt vetäytynyt ansaitulle eläkkeelle. Onneksi toinen tietokantaguru Lauri Pietarinen jatkaa kurssin pitämistä Tapsan aineistolla ja tuella. Lauri on pitkän tietokantakokemuksensa avulla päässyt hyvin sisään aiheeseen ja onkin jo pitänyt kurssia menestyksellä useaan kertaan. Lauri on myös luontaisesti hyvä kouluttaja.

Väittäisin, että näin syvällistä indeksointikurssia ei ole USA:ssakaan saatavissa. Jos haluat kehittää asiantuntemustasi todellisen ekspertin tasolle, kannattaa kurssille osallistua. Lisätiedot: www.arihovi.com.