Blogi: Suunnitellako tietokantaa vai ei?

Kun hallittavien tietojen määrä on pieni, on lopputuloksen kannalta miltei yhdentekevää onko tietokanta kunnolla suunniteltu tai onko se jollain muulla tavalla orgaanisena sivutuotteena muotoutunut.
Kun taas tietoja on enemmän kuin karkkipussillinen, tilanne muuttuu dramaattisesti.
Miksi uutta järjestelmää ideoivaa, pohtivaa tai suunnittelevaa tulisi tietokannan edes kiinnostaa? Ja mikä se edes on?!
Tuo viimeinen kysymys on joidenkin vuosien takaa, ajalta ennen Consultoria. Asiakas sen kysyi projektin suunnittelupalaverissa. Seuraavaksi jätimmekin varsinaisen suunnittelun hetkeksi ja lähdimme selvittämään asiaa yhtäläisyyksien ja eroavaisuuksien kautta vertailussa Exceliin. Tässä ei nyt mennä siihen aihepiiriin, tietoa on tarpeeksi olemassa muutenkin.

Taustatietona niille, jotka eivät ole joutuneet tietokantoihin vielä perehtymään: kyseessä on varasto, jossa tiedot pidetään asianmukaisesti järjestyksessä ja turvassa. Tiedot löytyvät varastostaan tunnisteillaan tai muilla hakuehdoilla, niitä voidaan yhdistellä ja ynnätä, sekä paljon muuta.


Järjestelmän hyvä suorituskyky joko mahdollistetaan tai estetään tietokannan rakennetta koskevilla ratkaisuilla. Tietokannan hyvä rakenne ei siis vielä tarkoita, että lopputulos olisi suorituskyvyltään hyvä, se ratkaistaan lopullisesti tietokannan varaan toteutettavilla asioilla.

Tietokannan hyvä suorituskyky voi toteutua vain, jos suunnittelun lähtötietoina on käytettävissä oikean kokoluokan arviot tallennettavien tietojen määristä. On paljon esimerkkejä tilanteista, joissa pientä järjestelmää on päätetty kasvattaa isompaan tarpeeseen, jolloin hyvin toimivasta pienestä järjestelmästä on saatu huonosti toimiva iso järjestelmä. Kottikärryillä on oma perusteltu tarpeensa, maansiirtodumpperilla omansa. Ei niitä oikein voi toistensa käyttötarkoituksiin käyttää.

Aivan suunnittelun ytimessä on tarpeita ja todellisuutta mahdollisimman hyvin vastaavan käsitemallin luominen. Mitä käsitteitä voisi olla? Asiakas, tili, tilaus, asiakkaan tilaukset, tuoteluettelo…
Seuraavaksi punnitaan käsitteiden väliset suhteet. Munkkilatinassamme vilahtelevat termit ”yhden suhde moneen”, ”constraintit”, ”primary key/foreign key”, normalisointi, surrogaattiavaimet ja koodistotaulut… anteeksi, tarkoitamme kuitenkin ihan hyvää, nuo ovat asioita, joihin pitää ottaa kantaa.
Käsitemallin avulla luodaan sellainen malli todellisuudesta, johon todellisuutta kuvaavat tiedot saadaan luontevasti talteen. Jos malli ei osu maaliinsa, ei sovelluksessakaan saada tietoja oikein.

Jos järjestelmää ei tarvitse kehittää edelleen tulevaisuudessa, paine tietokannan ylläpidettävyyden suhteen on pienempi. Useimmiten teemme kuitenkin järjestelmiä, joiden toivottu ja suunniteltu elinkaari on 10 vuotta tai enemmänkin.

Yleensä kerättyjä tietoja halutaan hyödyntää, raakatiedoista halutaan jalostaa raportteja, tilastoja, trendejä. Päätöksenteon tueksi voidaan tarvita kertaluonteisia tietoja. Pahoittelut – jos tietokannan rakenteen suunnittelussa ei ole huomioitu raportointitarpeita, ei tietoja välttämättä ole mahdollista edes saada halutussa muodossa.
Tietokantojen suunnitteluun liittyy paljon muitakin näkökulmia. Se on mielestäni sellainen projektin osa-alue, jota ei kannattaisi ohittaa olankohautuksella.
Yleensä se on muutakin kuin ns. insinöörityötä – keitokseen tarvitaan myös luovuutta, nokkeluutta ja ripaus taidetta!
Tapio Roine
Senior Consultant
etunimi.sukunimi@consultor.fi