TEEMU IMMONEN VERKKOPALVELUN TIETOMALLI JA INFORMAATIOSISÄLLÖN SÄILYVYYDENHALLINTA KETTERÄSSÄ OHJELMISTOPROJEKTISSA. Diplomityö

TEEMU IMMONEN VERKKOPALVELUN TIETOMALLI JA INFORMAATIOSISÄLLÖN SÄILYVYYDENHALLINTA KETTERÄSSÄ OHJELMISTOPROJEKTISSA Diplomityö Tarkastajat: Erikoistutkija Ossi Nykänen (TTY) Professori Seppo Pohjolainen (TTY) Tarkastajat ja aihe hyväksytty Tietotekniikan osastoneuvoston kokouksessa 20. elokuuta 2007

II TIIVISTELMÄ TAMPEREEN TEKNILLINEN YLIOPISTO Tietotekniikan osasto Hypermedia IMMONEN, TEEMU: Verkkopalvelun tietomalli ja informaatiosisällön säilyvyydenhallinta ketterässä ohjelmistoprojektissa Diplomityö, 75 sivua, 1 liitesivu Kesäkuu 2008 Tarkastajat: erikoistutkija Ossi Nykänen, professori Seppo Pohjolainen Avainsanat: tietomalli, informaatiosisältö, informaation mallintaminen, säilyvyys, säilyvyydenhallinta, tietokanta, ORM, mukautuva verkkopalvelu, ketterä ohjelmistokehitys, sovelluskehys Sovelluksen tietomallin määrittely ja suunnittelu ovat keskeinen osa nykyaikaista ohjelmistokehitysprosessia. Tietomallilla on tärkeä rooli myös sovelluksen koko arkkitehtuurin kannalta ja se mahdollistaa muun muassa sovelluksen informaatiosisällön säilyvyydenhallinnan toteuttamisen. Hyvin suunniteltu ja selkeä tietomalli mahdollistaa omalta osaltaan myös suoraviivaisen ja helposti ylläpidettävän sovelluslogiikan suunnittelun ja toteuttamisen. Tässä työssä perehdytään informaatiosisällön mallintamisen peruskäsitteisiin ja esitellään tietomallin määrittely- ja suunnitteluprosessi sekä informaatiosisällön säilyvyydenhallinta osana koko sovelluksen kehitysprosessia. Työssä esitellään kolme vaihtoehtoista teknologiaa informaatiosisällön säilyvyydenhallinnan toteuttamiseksi sekä arvioidaan niiden vahvuuksia ja heikkouksia tuotekehitysprosessin näkökulmasta. Lisäksi perehdytään Web-sovelluskehyksiin, missä yhteydessä niitä arvioidaan muun muassa niiden tuotekehitysprosessille tuomien etujen ja rajoituksien näkökulmasta. Työn konkreettisena tehtävänä on suunnitella ja toteuttaa Aatu-verkkopalvelun tietomalli ja informaatiosisällön säilyvyydenhallinta valituilla toteutusteknologioilla sekä arvioida teknologiavalintojen soveltuvuutta osana ketterää ohjelmistoprojektia. Kirjoitetun dokumentin lisäksi työn tuloksena syntyy Aatu-verkkopalvelun tietomalli ja informaatiosisällön säilyvyydenhallinnan toteutus. Työ osoittaa, että tietomallin ja säilyvyydenhallinnan suunnittelu sekä toteutus ORM-teknologiaa käyttäen, on parhaimmillaan hyvin suoraviivaista, joustavaa ja tuottavaa tuotekehitysprosessin näkökulmasta. Näin ollen valitut toteutusteknologiat sopivat hyvin myös ketterään ohjelmistokehitykseen. Työ osoittaa myös sen, että vaikka käytetyt teknologiat ja menetelmät mahdollistaisivat tietomallin ketterän suunnittelun, niin tietomalli tulisi silti suunnitella pääpiirteiltään mahdollisimman valmiiksi hyvin aikaisessa vaiheessa kehitysprosessia.

III ABSTRACT TAMPERE UNIVERSITY OF TECHNOLOGY Department of Information Technology Hypermedia IMMONEN, TEEMU: Web Service s Data Model and Information Persistence Management in Agile Software Project Master of Science Thesis, 75 pages, 1 Appendix page June 2008 Examiners: Senior Researcher Ossi Nykänen, Professor Seppo Pohjolainen Keywords: data model, data modeling, information modeling, persistence, persistence management, database, ORM, agile software development, iterative software development, application framework, adaptive web service Defining and designing of application s data model is an essential part of modern software development process. Data model has an important role in application s overall architecture as well and it for instance enables persistence management for application s information content. Well designed and clear data model also enables designing and implementation of straightforward and easily maintainable application logic. This thesis familiarizes oneself with basic concepts of information modeling and represents the design process of data model and information persistence management as a part of application s overall development process. Thesis represents three alternative technologies for information persistence management and evaluates their assets and weaknesses from the software development process s perspective. Web-frameworks are also briefly introduced and evaluated on the grounds of what benefits and restrictions they may bring into software development process. The concrete objective of this thesis is to design and implement the data model and information persistence management for Aatu web service with the chosen technologies and to evaluate technology selections as a part of an agile software project. As a result of this thesis, data model and information persistence management of Aatu web service are designed and implemented. Thesis indicates that data model design and information persistence management using ORM-technology are, in best cases, very straightforward, flexible and productive from the software development process s point of view. Consequently, the chosen technologies are suitable for agile software development. Study shows, on the other hand, that despite the fact that technologies and methods allows the agile design of data model, it should still be designed as ready as possible in the very early phases of the development process.

IV ALKUSANAT Diplomityöni on tehty Raha-automaattiyhdistyksen rahoittamassa Aatu-projektissa Tampereen teknillisen yliopiston Hypermedialaboratoriossa osa-aikaisena tutkimusapulaisena. Haluan kiittää Hypermedialaboratoriota mahdollisuudesta työskennellä erittäin mielenkiintoisessa Aatu-projektissa sekä lisäksi hyvin joustaneista työaikajärjestelyistä ja rennosta työilmapiiristä, jotka omalta osaltaan edesauttoivat tämän työn valmistumista varsinaisen päivätyöni ohessa. Esitän erityisen kiitokseni työn ohjaajana ja tarkastajana toimineelle erikoistutkija Ossi Nykäselle työn sisältöön sekä rakenteeseen liittyvistä parannusehdotuksista ja kommenteista. Kiitän myös työn toista tarkastajaa professori Seppo Pohjolaista ja tutkija Jukka Huhtamäkeä hyvistä kommenteista työhön liittyen. Lopuksi haluan kiittää Aatu-projektin kehitysryhmän jäseniä tasapuolisesti mukavasta projektityöilmapiiristä sekä tuesta tämän työn tekemisen aikana. Tampereella 25.4.2008 Teemu Immonen Sommerinkatu 9 A4 33180 Tampere

V SISÄLTÖ Tiivistelmä... II Abstract...III Alkusanat...IV Lyhenteet ja merkinnät... VII 1. Johdanto...1 2. Informaatiosisällön mallintaminen osana sovelluksen suunnittelua...3 2.1. Verkkopalvelun pysyvä informaatiosisältö...4 2.2. Tietomallin määrittely- ja suunnitteluprosessi...4 2.3. Ohjelmistotuotannon tiedonmallintamismenetelmiä...8 2.3.1. ER-malli...9 2.3.2. UML-malli...10 3. Informaatiosisällön säilyvyydenhallinta...13 3.1. Tietokannat...14 3.2. Relaatiomalli...16 3.2.1. Periaate...16 3.2.2. Informaation eheys ja relaatiotietokantaoperaatiot...19 3.2.3. Relaatiomalli tuotekehityksen näkökulmasta...20 3.3. Oliotietomalli...20 3.3.1. Periaate...22 3.3.2. Edut tuotekehityksen näkökulmasta...23 3.3.3. Rajoituksia ja haasteita...25 3.4. ORM (Object Relational Mapping)...27 3.4.1. Periaate...28 3.4.2. ORM-sovelluskehystyypeistä...30 3.4.3. ORM-sovelluskehysten yleisiä eroja...32 3.4.4. Edut tuotekehityksen näkökulmasta...33 3.4.5. Rajoituksia ja haasteita...35 3.5. Teknologiavaihtoehtojen arviointi tuotekehityksen näkökulmasta...36 4. Sovelluskehyksistä...39 4.1. Sovelluskehykset ja verkkopalvelut...40 4.1.1. MVC-malli...40 4.1.2. Web-sovelluskehykset...43 4.2. Django...44 4.2.1. Säilyvyydenhallinta ja luokkien väliset yhteydet...44 4.2.2. One-to-many yhteydet...47 4.2.3. Many-to-many yhteydet...48 4.2.4. Mallien perintä ja one-to-one yhteydet...49 4.2.5. MVC-mallin toteutus...51 4.3. Sovelluskehysten arviointi tuotekehityksen näkökulmasta...53 5. Tietomalli ja säilyvyydenhallinta AATU-Projektissa...55

5.1. Sovelluksen kehitysprosessi...56 5.1.1. Ketterä ohjelmistokehitys...57 5.1.2. Ketterien menetelmien soveltaminen AATU-projektissa...58 5.1.3. Odotukset teknologiavalinnoilta kehitysprosessin näkökulmasta...60 5.2. Tietomallin ja säilyvyydenhallinnan suunnittelu...61 5.2.1. Suunnittelun tulokset ja toteutus...62 5.2.2. Tietosisällön hallinnointi osana kehitysprosessia...64 5.3. Suunnittelun ja toteutuksen tulosten arviointi...66 5.4. Jatkokehitysideat...69 6. Yhteenveto...72 Lähteet...74 Liite 1: Aatu-verkkopalvelun tietomalli UML-luokkakaaviona...76 VI

VII LYHENTEET JA MERKINNÄT TTY ER UML CSV SQL ORM DBMS RDBMS OODM OID OODBMS OQL EJB-QL HQL JDOQL ORDBMS MVC GUI URL XML XPath XP DSDM Tampereen teknillinen yliopisto Entity Relationship Unified Modeling Language Comma Separated Values Structured Query Language Object Relational Mapping Database Management System Relational Database Management System Object Oriented Data Model Object Identifier Object Oriented Database Management System Object Query Language Enterprise Java Bean Query Language Hibernate Query Language Java Data Object Query Language Object Relational Database Management System Model View Controller Graphical User Interface Uniform Resource Locator Extensible Markup Language XML Path Language Extreme Programming Dynamic Systems Development Model

1 1. JOHDANTO Sovelluksen tietomallin (data model) määrittely ja suunnittelu ovat keskeinen osa lähes jokaisen nykyaikaisen ohjelmiston kehitysprosessia. Tietomallilla tarkoitetaan tiedon rakenteen määrittelevää kehikkoa ja käsitteistöä [1]. Tässä työssä tietomalli kuvaa sen, minkälaisista rakenteellisista alkioista sovelluksen tai verkkopalvelun käsittelemä informaatio (informaatiosisältö) koostuu ja minkälaisia riippuvuuksia eri tietoalkioiden välillä sovelluksen näkökulmasta on. Tietomalli määrittelee siis sovelluksen informaatiosisällön käsitteistön eli käytännössä sen, mitä ja minkälaista tietoa sovellus käsittelee. Kuvitteellisen verkkokaupan informaatiosisältöä kuvaava tietomalli voisi sisältää esimerkiksi seuraavia tietoalkiota: käyttäjä, tuote, mainos ja ostoskori. Tietomallilla on tärkeä rooli sovelluksen koko arkkitehtuurin kannalta. Tietomalli mahdollistaa muun muassa sovelluksen informaatiosisällön säilyvyydenhallinnan, jolla tarkoitetaan sovelluksen käsittelemien tietojen tallentamista pysyvästi sovelluksen eri käyttökertojen välillä. Säilyvyydenhallinnan toteuttaminen edellyttää siis käytännössä, että tallennettavaksi tarkoitettu informaatiosisältö on ensin mallinnettu jollakin menetelmällä eli sovelluksen tietomalli on olemassa. Esimerkiksi tietokannan käsitteistön ja taulujen rakenteen suunnittelu ei olisi käytännössä mahdollista ilman tietomallia. Hyvin suunniteltu ja selkeä tietomalli mahdollistaa myös suoraviivaisen ja helposti ylläpidettävän sovelluslogiikan sekä käyttöliittymän suunnittelun ja toteuttamisen. Tietomallin keskeisen roolin vuoksi se tulisi suunnitella mahdollisimman aikaisessa vaiheessa kehitysprojektia. Tietomalli saattaa olla lopulta kohtalaisen pieni osa monimutkaista tietojärjestelmää, mutta muutokset siihen voivat tulla hyvin kalliiksi. Pienikin muutos tietomalliin saattaa aiheuttaa suuria muutoksia sovellukseen kokonaisuutena, ja niillä puolestaan voi olla hyvin epäedullisia vaikutuksia projektin aikatauluihin ja kustannuksiin. Tämän työn tarkoitus on perehtyä informaatiosisällön mallintamisen peruskäsitteisiin ja esitellä tietomallin määrittely- ja suunnitteluprosessi sekä informaatiosisällön säilyvyydenhallinnan toteuttaminen osana koko sovelluksen kehitysprosessia. Työssä esitellään kolme vaihtoehtoista teknologiaa informaatiosisällön säilyvyydenhallinnan toteuttamiseksi sekä arvioidaan niiden vahvuuksia ja heikkouksia tuotekehitysprosessin näkökulmasta. Lisäksi perehdytään Web-sovelluskehyksiin, missä yhteydessä esitellään muun muassa työn käytännön osuudessa käytetyt toteutusteknologiat sekä arvioidaan sovelluskehyksiä niiden tuotekehitysprosessille tuomien etujen ja rajoituksien näkökulmasta. Työn konkreettisena tehtävänä on suunnitella ja toteuttaa Aatu-

2 verkkopalvelun tietomalli sekä informaatiosisällön säilyvyydenhallinta valituilla toteutusteknologioilla sekä arvioida teknologiavalintojen soveltuvuutta osana ketterää ohjelmistoprojektia. Verkkopalvelulla tarkoitetaan tässä työssä Internetin välityksellä toimivaa sovellusta tai järjestelmää. Ketterällä ohjelmistoprojektilla tarkoitetaan tässä yhteydessä puolestaan ohjelmistoprojektia, joka soveltaa niin sanottuja ketteriä ohjelmistokehityksen menetelmiä. Ketterät menetelmät esitellään tässä työssä tarkemmin myöhemmin. Työn ensimmäinen luku määrittelee työn aihealueen kannalta keskeisiä käsitteitä sekä kuvaa työlle asetettavat yleiset tavoitteet. Toisessa luvussa perehdytään sovelluksen informaatiosisällön mallintamisen peruskäsitteisiin sekä kuvataan tietomallin määrittely- ja suunnitteluprosessi osana sovelluksen koko suunnitteluprosessia. Lisäksi esitellään ohjelmistotuotannon tarjoamia tiedonmallintamismenetelmiä tietomallin käytännön suunnittelutyön tueksi. Kolmas luku keskittyy informaatiosisällön säilyvyydenhallintaan. Luvussa esitellään kolme vaihtoehtoista teknologiaa sovelluksen informaatiosisällön pysyvään tallentamiseen sekä arvioidaan kunkin vaihtoehdon vahvuuksia ja heikkouksia tuotekehitysprosessin näkökulmasta. Neljännessä luvussa kuvataan sovelluskehyksien yleisiä periaatteita sekä arvioidaan sovelluskehyksien käytön vaikutuksia tuotekehitysprosessille. Luvussa esitellään myös tässä työssä käytetty sovelluskehys soveltuvin osin. Viides luku keskittyy tapausesimerkkinä käytetyn Aatu-verkkopalvelun tietomallin ja säilyvyydenhallinnan suunnittelun ja toteutuksen käsittelyyn sekä työn tulosten arviointiin. Luvussa esitellään lyhyesti myös Aatu-projektin taustat ja tarkoitus sekä se, kuinka tämä työ liittyy kyseiseen projektiin. Lisäksi luvussa perehdytään ketterän ohjelmistokehityksen perusperiaatteisiin sekä niiden soveltamiseen Aatu-projektissa. Kuudennessa ja viimeisessä luvussa on työn yhteenveto, joka tiivistää ja kertaa lyhyesti työn keskeisen sisällön sekä tulokset.

3 2. INFORMAATIOSISÄLLÖN MALLINTAMINEN OSANA SOVELLUKSEN SUUNNITTELUA Nykyaikaisen verkkopalvelun tekninen määrittely, suunnittelu ja toteutus muistuttavat hyvin paljon perinteistä ohjelmistotuotantoa eri vaiheineen. Verkkopalvelun tekninen toteutusprojekti onkin käytännössä monesti kuin perinteinen ohjelmistoprojekti, jonka lopputuloksena syntyy jokin tuotteeksi miellettävä kokonaisuus. Näin ollen verkkopalveluiden kehitykseen soveltuvat myös monet perinteisen ohjelmistokehityksen suunnittelu- ja toteutusmenetelmät. Verkkopalveluiden suunnittelu eroaa kuitenkin jossakin määrin perinteisten ohjelmistojen suunnittelusta muun muassa sisällöntuotannon osalta. Verkkopalveluiden yhteydessä palvelun sisältö voi esimerkiksi tulla kokonaan tai osittain ulkopuolisilta sisällöntuottajilta, kuten uutispalveluiden uutiset niitä tuottavilta toimittajilta. Perinteisten ohjelmistojen tapauksessa täysin ulkopuolinen sisällöntuotanto on hieman harvinaisempaa, sillä monesti ohjelmistojen sisältö on miellettävissä kiinteäksi osaksi tuotteita itseään, jota ei ole mahdollista päivittää kuten verkkopalveluiden sisältöä tai sisältöä ei ole ollenkaan sen varsinaisessa merkityksessä. Ohjelmistoja saatetaankin käyttää monesti varsinaisen sisällön tuottamiseen, kuten tekstinkäsittelyohjelmia tekstin tuottamiseen tai piirto-ohjelmia kuvien piirtämiseen sekä käsittelyyn. Verkkopalveluiden sisällöntuotanto on melko laaja ja itsenäinen kokonaisuus, joka on luonteva erottaa verkkopalveluiden teknisestä määrittelystä ja suunnittelusta omaksi osaprojektikseen, joten siihen ei tässä yhteydessä keskitytä tämän tarkemmin, vaan verkkopalveluiden suunnitteluprosessia tarkastellaan jatkossa puhtaasti toteutusteknisestä näkökulmasta. Todetaan kuitenkin, että verkkopalveluiden ja perinteisten ohjelmistojen tekninen suunnittelu ja toteutus on hyvin samankaltaista, vaikka erojakin muun muassa edellä mainitun sisällöntuotannon alueelta on löydettävissä. Sisällöntuotantoa käsitellään myöhemmin toteutettavaa verkkopalvelua käsittelevässä luvussa. Verkkopalvelun teknisen suunnittelun ja toteutuksen vaiheisiin kuuluvat muun muassa palvelun tekninen määrittely, suunnittelumenetelmien valinta, tekninen suunnittelu sekä varsinainen toteutustyö valituilla teknologioilla. Yksi keskeinen vaihe verkkopalvelun tai ohjelmiston kehitystyössä on sovelluksen tietomallin määrittely ja suunnittelu. Tietomallin suunnittelusta puhuttaessa käytetään tässä työssä myös termiä informaatiosisällön mallintaminen, joka käsittää sekä tietosisällön käsitteistön että eri

4 tietoalkioiden välisten riippuvuuksien määrittelyn sekä näiden kuvauksen jollakin tiedonmallintamismenetelmällä. Tiedonmallintamismenetelmiä käsitellään tarkemmin myöhemmin. Luku perustuu pääasiassa lähteisiin [2; 3]. 2.1. Verkkopalvelun pysyvä informaatiosisältö Verkkopalvelun informaatiosisältöä voidaan tarkastella eri näkökulmista ja abstraktiotasoilla. Edellä mainittiin jo käsitetaso (kohdetaso, conceptual level), joka määrittelee mitä tietoja käsitellään, miten tiedot liittyvät yhteen ja millainen on se kohde, jota tiedoilla pitäisi kuvata; asiat, joita pitäisi esittää. Rakennetaso (looginen taso, structural level) puolestaan määrittelee minkälaisia käsiteltäviä rakenteita tieto muodostaa esimerkiksi eri ohjelmointikielten tai tietokantojen näkemykset tiedosta. Talletustaso (fyysinen taso, physical level) määrittelee, minkälaisina koneenläheisinä rakenteina tiedot tallennetaan ja miten niitä voidaan käsitellä minkälaiset rakenteet tehostavat hakua ja ovatko tiedot hajautettu vai keskitetysti samassa paikassa. [1] Verkkopalvelun pysyvällä informaatiosisällöllä tarkoitetaan tässä yhteydessä sellaista tietoa, joka säilyy muuttumattomana sovelluksen eri käyttökertojen välillä. Pysyvä informaatiosisältö määrittelee sovelluksen käsittelemien tietojen käsitteistön ja rakenteen siten, että tietojen ohjelmallinen käsittely ja säilyvyydenhallinta on mahdollista toteuttaa. Pysyvällä informaatiosisällöllä ei tässä yhteydessä siis tarkoiteta esimerkiksi pelkästään tietokantaan talletettua dataa itsessään vaan pikemminkin tallennuksen mahdollistavaa määritelmää tallennettavasta tiedosta ja sen rakenteesta. Varsinaisesta verkkopalvelun käyttämästä datasta puhuttaessa käytetään termiä verkkopalvelun käyttämä informaatio tai tieto. Verkkopalvelun pysyvän informaatiosisällön mallintamisen prosessi sisältää usein kaikki edellä mainitut informaatiosisällön abstraktiotasot, sovelluksen käsitteistön määrittelystä sekä tiedon rakenteen kuvauksesta aina mahdolliseen talletustason määrittelyyn ja valintaan asti. Pysyvän informaatiosisällön mallintaminen mahdollistaa siis palvelun käsittelemän informaation säilyvyydenhallinnan, joka yleensä hoidetaan jonkin ulkoisen tietovaraston kuten tietokannan tai tiedoston avulla. Säilyvyydenhallintaa käsitellään tarkemmin omassa luvussaan. Tässä yhteydessä todetaan kuitenkin, että jotta palvelun käsittelemän informaation säilyvyydenhallinta olisi mahdollista käytännössä toteuttaa, on tallennettava tieto sitä ennen yleensä mallinnettava jollakin menetelmällä. 2.2. Tietomallin määrittely- ja suunnitteluprosessi Tietomallin määrittely ja suunnittelu voidaan nähdä prosessina, jonka tuloksena syntyy verkkopalvelun tai ohjelmiston vaatimusmäärittelyä vastaava tietomalli. Tunnettu ja yleinen menetelmä tämän prosessin läpiviemiseksi on niin sanottu ER-malli (Entity

5 Relationship Model), jossa tietomallin suunnittelu alkaa sovellusalueen entiteettien (reaalimaailman oliot, sovelluksen substantiivit) tunnistamisesta ja nimeämisestä. Entiteetit (oliot) voivat olla joko abstrakteja tai konkreettisia, mutta yhteistä niille on se, että niillä on jokin merkitys sovelluksen kannalta. Entiteetit esimerkiksi määrittelevät mitä ja minkä tyyppistä tietoa sovellus hallinnoi, käsittelee ja mahdollisesti tallentaa. Verkkokaupan tapauksessa sovellusalueen konkreettisia entiteettejä voisivat olla muun muassa käyttäjä, ostoskori, tuote, lasku ja mainos tai esimerkiksi hieman abstraktimpi, kuten ostotapahtuma. Entiteettien tunnistamisen ja nimeämisen jälkeen niiden ominaisuuksia tarkennetaan attribuuteilla, jotka kuvaavat ja kapseloivat nimetyn olion sekä sen sisältämät tiedot loogiseksi kokonaisuudeksi. Attribuutteja ovat mitkä tahansa tiedot, jotka kuvaavat entiteetin (olion) ominaisuuksia ja määrittelevät mistä tiedon osasista sovelluksen käsittelemä informaatio lopullisesti koostuu. Tuotteen attribuutteja voisivat olla esimerkiksi nimi, tuotteen kuvaus ja hinta. Entiteettien on oltava yksilöllisesti tunnistettavissa sekä näin ollen erotettavissa muista saman tyypin olioista. Näin esimerkiksi verkkokaupan eri tuotteet on erotettavissa toisistaan, vaikka kukin niistä tuotetta entiteettitasolla edustaakin. Entiteettien tunnistaminen tehdään perusavaimeksi (primary key) kutsutulla attribuutilla, jonka arvo näin ollen on yksilöllinen jokaisella oliolla. Monesti perusavaimen arvona käytetään automaattisesti tuotettua lukuarvoa, IDtunnistetta, koska muuta luonnollista tapaa yksilöidä olioita harvemmin löytyy. Entiteettien väliset yhteydet (relationship, relaatio) sekä rajoitukset on mahdollista määritellä ja kuvata sitten, kun kaksi tai useampi sovellusalueen entiteeteistä on tunnistettu sekä niiden ominaisuudet on määritelty attribuuteilla. Entiteettien välinen yhteys voi olla periaatteessa mikä hyvänsä assosiaatio, linkki tai yhdistävä tekijä, jolle on annettu nimi ja jolla on merkitystä suunniteltavan sovelluksen kannalta. Yhteys voi olla kahden eri entiteetin välinen tai se voi olla entiteetin sisäinen, jolloin relaatio viittaa entiteettiin itseensä. Entiteettien välisten yhteyksien rajoituksia kuvataan muuan muassa lukumääräsuhteilla sekä perintä- ja koostehierarkioilla. Ostoskorin ja tuotteen välillä voi olla esimerkiksi yhteydet nimeltä sisältää ja kuuluu Asiaa havainnollistetaan kuvassa 3.1 yksinkertaisen ER-kaavion (Entity Relationship Diagram) avulla. Kuva 3.1. ER-kaavio entiteettien välisestä yhteydestä. ER-kaavio on kuvallinen esitysmuoto sovellusalueen entiteeteistä ja niiden välisistä yhteyksistä. Entiteetit kuvataan niissä laatikoina ja yhteydet entiteettien väliin piirretyillä viivoilla. Yhteyksien rajoitukset, kuten lukumääräsuhteet, voidaan

6 tarvittaessa myös lisätä kaavioon. ER-kaaviot kuvaavat suunniteltavan sovelluksen tietomallin joskus hieman karkealla, mutta kuitenkin ilmaisuvoimaisella tavalla. ERkaavioita on mahdollista myöhemmin käyttää esimerkiksi tietokannan taulujen rakenteen suunnittelussa. Kuvan 3.1 kaavio ilmaisee siis sen, että ostoskorissa voi olla yksi tai useampi tuote ja tuote saattaa kuulua yhteen tai useampaan ostoskoriin. Entiteettien väliset yhteydet voidaan jakaa kolmeen eri tyyppiin sen perusteella, kuinka entiteetit suhtautuvat toisiinsa niiden lukumääräsuhteiden kautta. Nämä tyypit ovat oneto-one (1:1), one-to-many (1:N) ja many-to-many (M:N). Kuvan 3.1 kaaviossa ostoskorin ja tuotteen välillä on many-to-many -tyyppinen yhteys, koska yksi ostoskori voi sisältää useampia tuotteita ja tuote voi kuulua useampaan ostoskoriin. Seuraavissa kuvissa on puolestaan esimerkit one-to-one ja one-to-many - yhteyksistä. Kuva 3.2. ER-kaavio one-to-one - yhteydestä. Kuva 3.3. ER-kaavio one-to-many - yhteydestä. Kuvan 3.2 ER-kaavio ilmaisee, että sormenjälki kuuluu vain yhdelle käyttäjälle ja yksi käyttäjä omistaa vain yhden sormenjäljen. Kuvan 3.3 ER-kaavio puolestaan ilmaisee, että kategoria voi sisältää yhden tai useampia tuotteita, mutta kukin yksittäinen tuote kuuluu vain yhteen kategoriaan. One-to-one yhteys kuvaa siis tilannetta, jossa yksittäinen entiteetti A on yhteydessä toiseen yksittäiseen entiteettiin B ja päinvastoin. One-to-many yhteys puolestaan kuvaa tilannetta, jossa yksittäinen entiteetti A on yhteydessä yhteen, useampaan kuin yhteen tai ei yhteenkään entiteetin B instanssiin. Yksittäinen entiteetti B on kuitenkin yhteydessä vain yhteen entiteetin A instanssiin. Many-to-many yhteys on kyseessä silloin, kun yksittäinen entiteetti A on yhteydessä yhteen, useampaan kuin yhteen tai ei yhteenkään entiteetin B instanssiin ja päinvastoin. Aikaisemmin todettiin, että tietokannan taulujen rakenne on muodostettavissa ERmallin avulla. ER-kaavion laatikot (entiteetit) vastaavat relaatiotietokannan tauluja ja entiteettien väliset viivat puolestaan kuvaavat taulujen välisiä viiteavaimia (foreign key). Viiteavain on taulun sarake, joka sisältää toisen taulun perusavaimen arvoja. Kuvan 3.3

7 kaavion perusteella on mahdollista muodostaa taulut Kategoria ja Tuote. Tuote-taulu sisältää myös viiteavaimen, jonka arvot ovat Kategoria-taulun perusavaimen arvoja. Monet reaalimaailman yhteydet ovat many-to-many tyyppisiä, kuten aikaisemmin esimerkkinä käytetyn ostoskorin ja tuotteen välinen suhde. Nämä relaatiot ovat tietokannan suunnittelun kannalta ongelmallisia, koska niistä ei voida suoraan muodostaa relaatiotietokannan tauluja käyttäen viiteavaimia. Tuotteessa ei esimerkiksi voida säilöä viiteavainta ostoskoriin, koska tuote saattaa kuulua yhteen tai useampaan ostoskoriin. Tämä rajoitus on puhtaasti tietokantajärjestelmien sisäisestä toteutustavasta aiheutuva, sillä sovelluslogiikkakerrokselle näiden monimutkaisten relaatioiden hallinta ei ole mikään ongelma, koska ohjelmointikielten syntaksi mahdollistaa paljon monimutkaisempienkin tietorakenteiden käyttämisen. Ongelma on ratkaistavissa korvaamalla many-to-many yhteys uudella entiteetillä (association entity) ja yhdistämällä alkuperäiset entiteetit sitten tähän uuteen entiteettiin one-to-many ja many-to-one yhteyksillä. Ostoskorin ja tuotteen välinen many-to-many tyyppinen yhteys on ratkaistu seuraavassa kuvassa. Kuva 3.4. Ostoskorin ja tuotteen välisen many-to-many - relaation ratkaisu. Kuvan 3.4 kaavio tulkitaan siten, että ostoskori sisältää yhden tai useamman ostotapahtuman ja tuote saattaa kuulua yhteen tai useampaan ostotapahtumaan. Ratkaisua kutsutaan many-to-many yhteyden normalisoiduksi muodoksi, joka on mahdollista toteuttaa myös relaatiotietokannan tauluina viiteavaimia käyttäen. Ratkaisun pohjalta luotavaan tietokantaan tulisi näin ollen taulut Ostoskori, Ostotapahtuma ja Tuote. Ostotapahtuma sisältäisi viiteavainkentät, jotka saisivat Ostoskori- ja Tuote taulujen perusavaimen arvoja. Näin ollen alkuperäinen normalisoimaton many-to-many yhteys olisi johdettavissa näiden kolmen taulun avulla. Many-to-many yhteyksien normalisointi tulisi tehdä hyvin pian niiden tunnistamisen jälkeen, koska kuten aikaisemmin todettiin, ne estävät muuten tietomallin perusteella toteutettavan tietokannan taulurakenteen suunnittelun etenemisen.

8 Tietomallin suunnitteluprosessi etenee siis sovellusalueen entiteettien tunnistamisesta ja nimeämisestä (käsitetaso) niiden sisältämien tietojen tarkempaan määrittelyyn attribuuttien avulla (rakennetaso). Entiteettien väliset suhteet kuvataan vielä relaatiolla, jotka normalisoidaan tarvittaessa aikaisemmin kuvatulla tavalla, jonka jälkeen sovelluksen tietomallin voidaan katsoa olevan määritelty. Tämän jälkeen verkkopalvelun tai ohjelmiston kehitystyö jatkuu usein tietomallia vastaavan tietokannan suunnittelulla (talletustaso). Tietokannan taulujen rakenteen määrittely ja suunnittelu on oma laaja kokonaisuutensa, jota ei kuitenkaan tässä kohtaa käsitellä, koska tässä yhteydessä keskitytään pääasiassa sovellusalueen tietomallin määrittelyyn, joka ei ole tallennus- tai sovelluslogiikkatasojen toteutuksesta riippuvainen. Tietomallin määrittely- ja suunnitteluprosessi kuvattiin edellä käyttäen ER-mallia esimerkkinä. Sama toimintatapa on kuitenkin sovellettavissa moniin muihinkin tiedonmallintamismenetelmiin, kuten esimerkiksi UML- (Unified Modeling Language) tai oliomallinnukseen. Eri menetelmien käyttämä terminologia saattaa erota hieman toisistaan, mutta tiedonmallintamisprosessin periaate on kaikissa hyvin samankaltainen. Prosessissa pyritään löytämään sovellusaluetta kuvaavat reaalimaailman ilmentymät (oliot, substantiivit), nimetään ne ja määritellään niiden sisältämät yksityiskohtaiset tiedot attribuuttien avulla sekä kuvataan olioiden väliset suhteet relaatioiden avulla. Ohjelmistotuotannon eri tiedonmallintamismenetelmiä käsitellään lyhyesti kohdassa 2.3, jossa edellä mainitun ER-mallin notaatiotakin tarkastellaan yksityiskohtaisemmin. 2.3. Ohjelmistotuotannon tiedonmallintamismenetelmiä Ohjelmistotuotanto tarjoaa joitakin jo vakiintuneitakin ja yleisesti tunnettuja menetelmiä ja työkaluja ohjelmistojen tietomallin käytännön suunnittelutyön tueksi. Näitä tiedonmallintamismenetelmiä ovat muun muassa ER- ja UML-mallit, jotka mahdollistavat informaation mallintamisen hyvin ilmaisuvoimaisella tavalla. Menetelmien avulla on mahdollista kuvailla tietomallin määrittely ja suunnittelutyön tulokset tietyllä usein projektikohtaisesti sovitulla tavalla. Näin ollen kehitysprojektin eri henkilöiden ja sidosryhmien välinen kommunikointi tietomalliin liittyvissä asioissa helpottuu huomattavasti, koska käytössä on yksi yhteinen käytäntö ja kieli kyseisestä asiasta keskustelemiseen. ER- ja UML-mallit sopivat hyvin informaation käsite- ja rakennetason suunnittelutyön tueksi, koska niiden avulla muodostetut mallit ovat riippumattomia järjestelmän lopullisista teknisistä toteutustavoista. Menetelmien avulla on siis mahdollista visualisoida mallinnettavan järjestelmän tietosisältö ilmaisuvoimaisesti sekä käsite- että rakennetasolla ilman, että riippuvuuksia syntyy esimerkiksi toteutustekniikaksi valittavasta ohjelmointikielestä tai tietokannan tyypistä. Seuraavassa esitellään edellä mainitut menetelmät lyhyesti sekä pohditaan hieman niiden sopivuutta suunnittelutyön tueksi tietomallin määrittelyprosessin näkökulmasta.

9 2.3.1. ER-malli ER-malli (Entity Relationship Model), johon kohdan 2.2 esimerkeissä käytetyt kaaviot perustuvat, on käsitteellinen tietomalli, joka kuvaa reaalimaailmaa entiteettien ja niiden välisten relaatioiden avulla. Mallin peruskomponentti on ER-kaavio, jonka avulla visualisoidaan varsinaisen mallin entiteetit ja niiden väliset suhteet. Malli esiteltiin alun perin 1970-luvulla menetelmäksi, jonka tavoitteena oli yhdenmukaistaa eri tietokantatyyppien näkymien kuvaustekniikat. Mallia on laajennettu tämän jälkeen vuosien kuluessa ja nykyisin se on yleisesti käytetty tietokantojen suunnittelumenetelmä. ER-mallin yleistymistä tietokantasuunnittelun menetelmänä ovat edesauttaneet muun muassa seuraavat seikat. Se soveltuu hyvin relaatiomallin kuvaamiseen, jolloin ER-mallin mukainen suunnitelma on yleensä suoraviivaista toteuttaa relaatiotietokannan tauluina. ER-malli on myös suhteellisen yksinkertainen ja helppo oppia sekä hyvin ilmaisuvoimainen, joten se sopii hyvin sekä tietokantasuunnittelijoiden että muiden tuotekehitysprojektin sidosryhmien väliseen kommunikointiin. ER-mallin avulla on lisäksi mahdollista suunnitella tietokannan rakenne siten, että se ei ole riippuvainen mistään tietystä tietokantatuotteesta tai tietokannanhallintajärjestelmästä Näin ollen suunnitelma tietokannan rakenteesta on tarvittaessa mahdollista tehdä ennen kuin esimerkiksi tiedetään mitä tietokantatuotetta tuotekehityksessä tullaan käyttämään. ER-malli siis määrittelee järjestelmän tietomallin käsite- ja rakennetasolla entiteettien ja niiden välisten suhteiden avulla sekä visualisoi mallin käyttäen ER-kaaviota. ERkaavioiden esittämiseen ei ole olemassa standardia, joten näin ollen ER-malliin perustuvien eri mallintamismenetelmien käyttämät notaatiot eroavat silloin tällöin hieman toisistaan. Toisaalta eri notaatioiden väliset erot eivät ole yleensä merkittäviä, joten hieman erilaisella kuvaustekniikalla tehtyjen kaavioiden tulkitseminen yhden notaation hyvin hallitsevalle henkilölle ei ole yleensä ongelma. Standardin puuttumisesta huolimatta eri notaatiolla on hyvin paljon yhteisiä piirteitä. Esimerkiksi entiteetit esitetään poikkeuksetta suorakulmaisina laatikoina ja niiden väliset relaatiot niitä yhdistävinä viivoina. Entiteetit nimetään melkein poikkeuksetta yksittäisillä substantiiveilla ja relaatiot puolestaan verbeillä. Attribuutit sijoitetaan entiteettien sisään ja nimetään yksittäisillä substantiiveilla. Suurimmat erot eri notaatioiden välillä liittyvät yleensä relaatioita kuvaavien lukumääräsuhteiden eli kardinaliteettien (cardinality, multiplicity) ja olemassa olon (existence) esittämiseen. Relaatiota kuvaava viiva loppuu yleensä haaroitukseen kardinaaliluvun ollessa suurempi kuin yksi. Jos viiva ei haaroitu, niin kardinaaliluku on yksi. Entiteettien välisen relaation olemassa oloa puolestaan kuvataan usein relaatiota esittävän viivan päähän lisättävällä ympyrällä tai kohtisuoralla viivalla. Kohtisuora viiva entiteetin vieressä tarkoittaa sitä, että kyseisen entiteetin instanssin olemassa olo on pakollinen ja ympyrä puolestaan sitä, että entiteetti on vaihtoehtoinen. Kuva 3.5 havainnollistaa erästä ER-kaavioiden kuvaamisessa käytettyä notaatiota.

10 Kuva 3.5. Esimerkki ER-kaaviosta [3]. ER-malli on siis käsitteellinen malli, joka kuvaa reaalimaailmaa entiteeteillä, niiden välisillä relaatioilla ja entiteettien ominaisuuksilla eli attribuuteilla sekä esittää mallintamisen tulokset ER-kaavioiden avulla. Se sopii erityisen hyvin relaatiomalliin perustuvien relaatiotietokantojen suunnitteluun sekä mahdollistaa muun muassa tehokkaan kommunikoinnin tuotekehitysprojektin eri sidosryhmien välillä järjestelmän tietomalliin liittyvissä kysymyksissä. 2.3.2. UML-malli UML (Unified Modeling Language) on graafinen kieli, jolla on mahdollista ilmaisuvoimaisesti kuvata muuan muassa ohjelmistoille ja tietojärjestelmille asetettavia vaatimuksia, arkkitehtuuria sekä määrittely- ja suunnitteluprosessia yleensä. UML julkaistiin vuonna 1997 ja sen tarkoitus oli määritellä yhtenäinen syntaksi, jolla voitaisiin mallintaa sekä ohjelmistojen komponentit sekä sovelluksien informaatiosisältö eli tietomalli. UML on julkaisunsa jälkeen saavuttanut suuren suosion ohjelmistoteollisuudessa ja on tällä hetkellä yksi yleisimmin käytetyistä suunnittelutyön tulosten dokumentointimenetelmistä ohjelmistojen ja järjestelmien kehityksessä. UML on standardoitu ja hyvin monipuolinen mallintamiskieli, joka koostuu joukosta erilaisia kaavioita (diagrams), jotka on kehitetty helpottamaan ohjelmistojen ja järjestelmien suunnittelijoita suorittamaan muun muassa seuraavia tehtäviä: määrittely, arkkitehtuurisuunnittelu, oliosuunnittelu sekä dokumentointi ja visualisointi. UML tarjoaa useita erilaisia menetelmiä ja malleja esimerkiksi ohjelmistojen toiminnallisen määrittely- ja suunnittelutyön tueksi. Tässä yhteydessä keskitytään kuitenkin tarkastelemaan UML:ää ainoastaan sovellusten tietomallin määrittelyn näkökulmasta.

11 Kuten aikaisemmin todettiin, niin ER-malli sopi hyvin relaatiomallin mukaisten relaatiotietokantojen tietomallien suunnitteluun. ER-malli on hyvin tietokeskeinen (data-oriented) suunnittelumenetelmä, joka keskittyy entiteettien ja niiden välisten relaatioiden suunnitteluun informaatiosisällölle asetettujen vaatimusten perusteella. Informaatiosisällölle asetettavat vaatimukset sitten määrittelevät muut ohjelmistoa koskevat suunnitteluratkaisut. Tätä lähestymistapaa tai paradigmaa kutsutaan tietokeskeiseksi suunnitteluksi (data-oriented design). Oliokeskeisissä (object-oriented) suunnittelumenetelmissä ohjelmistot mallinnetaan puolestaan joukkona olioita, jotka keskenään kommunikoiden muodostavat ohjelmiston toiminnallisuuden. Olioille asetettavat vaatimukset (olioanalyysi) määrittelevät muut ohjelmistoa koskevat suunnitteluratkaisut. Oliokeskeisen suunnittelun (olioparadigman) mukaan sovellukset koostuvat siis olioista, jotka sisältävät sekä sovelluksen käsittelemän informaation että toiminnallisuuden. Tämä erottaa oliot ER-mallin käyttämistä entiteeteistä, vaikka niillä molemmilla mallinnetaan periaatteessa samoja asioita reaalimaailman asioita ja ilmiöitä. UML tarjoaa paljon erilaisia työkaluja ja menetelmiä myös oliokeskeisten järjestelmien määrittelyyn ja suunnitteluun, mutta kuten aikaisemmin todettiin, niin tässä yhteydessä keskitytään ainoastaan sovellusten tietomallin suunnitteluun tarkoitettuihin menetelmiin. UML:ssa sovellusten tietomalli määritellään luokkakaavioiden (class diagram) avulla. Luokkakaaviot ovat UML:n looginen vastine ER-mallin ER-kaavioille sillä erolla, että ne määrittelevät luokkien sisältämien tietojen lisäksi tarvittaessa myös niiden sisältämän toiminnallisuuden eli operaatiot. Luokkakaavio muodostuu siis luokista, joilla mallinnetaan reaalimaailman asioita aivan kuten ER-mallin entiteeteillä. Luokat sisältävät ominaisuuksia eli attribuutteja, jotka määrittelevät kyseisen luokan olioiden sisältämät tiedot. Luokkakaavio sisältää tiedon myös luokkien välisistä yhteyksistä eli assosiaatioista. Periaatteessa UML:n luokkakaaviot tuovat lisää ER-kaavioihin nähden ainoastaan mahdollisuuden esittää kaaviossa myös olioiden operaatiota. Toisaalta UML:n avulla oliokeskeisen järjestelmän mallintaminen onnistuu ER-mallia hieman luontevammin, koska UML:n tarjoaa erityisesti olioparadigmaa tukevia piirteitä hyvin kattavasti. Näitä ovat muun muassa oliojärjestelmille hyvin tyypilliset olioiden kooste- ja perintäsuhteet. Koostesuhde on kyseessä silloin kun olio koostuu toisista olioista ja perinnässä luokka puolestaan laajentaa perittävän kantaluokan ominaisuuksia jollakin tavalla. Kuvassa 3.6 havainnollistetaan UML:n käyttöä esittämällä kuvan 3.5 ER-malli luokkakaavion avulla. Kaaviossa on käytetty lisäksi myös kooste- ja perintäsuhdetta.

12 Kuva 3.6. Esimerkki UML:n luokkakaaviosta. UML- ja ER-mallien avulla saavutetaan hyvin pitkälti samoja etuja tuotekehitysprojektin näkökulmasta. Molemmat mahdollistavat ohjelmiston informaatiosisällön mallintamisen hyvin ilmaisuvoimaisella tavalla sekä helpottavat projektin eri sidosryhmien välistä kommunikointia erityisesti sovelluksen tietomalliin liittyvissä kysymyksissä. ER-malli sopii ehkä hieman UML-mallia paremmin relaatiotietokantojen suunnitteluun ja UML-mallien vahvuus tulee puolestaan hyvin esille puhtaasti oliokeskeisiä järjestelmiä suunniteltaessa. Oliojärjestelmien monimutkaiset oliohierarkiat eivät välttämättä sellaisenaan sovi kovin suoraviivaisesti relaatiotietokantojen relaatiomalliin, jolloin niiden mallintaminen niille suunnatuilla työkaluillakaan ei välttämättä ole kovin tuottavaa tuotekehitysprojektin näkökulmasta. UML-kaaviot puolestaan tukevat hyvin oliosuunnittelua ja mahdollistavat näin ollen tehokkaan ja suoraviivaisen oliomallintamisen. Oliojärjestelmien ja relaatiotietokantojen yhteensovittamisesta aiheutuviin haasteisiin perehdytään tarkemmin myöhemmin säilyvyydenhallintaa käsittelevässä luvussa.

13 3. INFORMAATIOSISÄLLÖN SÄILYVYYDENHALLINTA Informaatiosisällön säilyvyydenhallinta mahdollistaa ohjelmistojen käsittelemien tietojen tallentamisen siten, että ne ovat myöhemmin luettavissa uudelleen sovelluksen käyttöön. Toisin sanoen sovelluksen käsittelemät tiedot tallennetaan usein järjestelmän kovalevylle ja luetaan sieltä tarvittaessa myöhemmin. Näin ollen informaatio on mahdollista varastoida myös sovelluksen eri käyttökertojen välillä. Säilyvyydenhallinta on mahdollista toteuttaa useilla eri tavoilla, joista jokaisella on myös etunsa ja haittansa. Näihin eri tapoihin perehdytään myöhemmin tässä luvussa. Yhteistä näille eri menetelmille on kuitenkin se, että jokainen niistä edellyttää, että sovelluksen tietomalli on ainakin jollakin tasolla olemassa eli verkkopalvelun tai ohjelmiston käsittelemä informaatiosisältö on mallinnettu jollakin tavalla. Luku perustuu pääasiassa lähteisiin [3; 4; 6; 9; 10]. Perinteinen säilyvyydenhallinnan toteutusmekanismi on säilöä sovelluksen käsittelemä informaatio johonkin tietyn tiedostomuodon omaavaan (formaattiseen) tiedostoon. Eräs yleisesti tunnettu tiedostoformaatti on niin sanottu CSV-tiedosto (Comma Separated Values), joka on selkokielinen tekstitiedosto, jonka jokainen yksittäinen rivi edustaa yhden säilöttävän entiteetin tietoja pilkulla toisistaan erotettuna. CSV-tiedostojen tai vastaavien formaattien käyttö sovellusten käyttämien tietojen tallentamiseen on usein hyvin yksinkertaista ja suoraviivaista. Eri ohjelmointikielet tukevat tiedostoihin kirjoitusta ja niistä lukua varsin kattavasti, joten informaation tallentaminen ei yleensä vaadi näin ollen mitään erityistoimenpiteitä tai esimerkiksi jonkin kolmannen osapuolen tuotteita. Tiedostot sopivat hyvin tietomäärällisesti pienten ja yksinkertaisten sovellusten informaation tallentamisvälineiksi. Ne menettävät yksinkertaisuuden mukanaan tuomat etunsa kuitenkin melko nopeasti sovelluksen käsittelemien tietomäärien kasvaessa suuremmiksi. Tietojen käsittely, muokkaaminen ja monimutkaisten hakujen tekeminen käyvät suurilla tietomäärillä nopeasti suhteellisen työläiksi operaatioiksi, jos sovellus käyttää tiedostoja pääasiallisena informaation tallennusmekanisminaan. Edellä mainitut selkokieliset tekstitiedostoformaatit aiheuttavat myös joitakin tietoturvallisuuteen ja informaation eheyteen kohdistuvia riskejä, koska sovelluksen käyttämän tietovaraston sisällön muokkaaminen muualta kuin sovelluksen tai verkkopalvelun itsensä toimesta on hyvin helppoa. Datan muokkaamiseen tietovarastossa riittää periaatteessa mikä tahansa tekstinkäsittelyohjelma, joten on hyvin mahdollista, että jossain vaiheessa