Soveltamisprofiilin tarkoituksena on kuvata yksittäisen tietojärjestelmän (tai sen osan) tietosisältö ja tietoon liittyviä vaatimuksia ja rajoituksia. Tarkoituksena on vähentää tietojärjestelmän kehitys ja ylläpitokustannuksia hyvällä suunnittelulla ja dokumentoinnilla. Tietosisällön dokumentointi tukee tietojärjestelmän ymmärrettävyyttä, tiedon uudelleenkäyttöä ja vähentää uudelleenmäärittelyn tarvetta.
Tietorakenteet kuvataan soveltamisprofiilissa siten, että niiden perusteella voidaan muodostaa fyysinen tietomalli eri tekniikoilla tai syntakseilla. Tietomallit.suomi.fi sovelluksella toteutetun soveltamisprofiilin tietorakenteet ovat määritelty rakenteisesti linkitettynä datana, siten että tietorakenteet ovat yhteensopivia XML tai JSON skeemojen rakenteiden kanssa. Työkalusta voi ladata tietomallia vastaavan XML, JSON tai SHACL (RDF) skeeman, jonka avulla määriteltyä tietosisältöä voidaan hyödyntää tiedon validoinnissa tai rajapinnan tietosisältömäärityksen pohjana.
Soveltamisprofiili voi kuvata tietosisältöjä eri tarkkuustasoilla
Soveltamisprofiilin tietosisältö kuvataan aina tietojärjestelmän kannalta olennaisella tarkkuudella, joka määrittyy käyttötarpeen mukaan. Sisällöllisesti soveltamisprofiili on sopimus siitä miten yhteisesti sovittua kieltä ja rakenteita käytetään tietyssä käyttötarkoituksessa. Käyttötarkoitus voidaan jakaa karkealla tasolla kolmeen eri ryhmään:
- Tiedonsiirtorajapinnan tietosisältö - Miten tietoa siirretään?
- Sovellusrajapinnan tai tietojärjestelmän tietosisältö - Miten tietoa käsitellään?
- Tietovaraston tietosisältö - Miten tietoa säilytetään?
- Yleinen tietosisällön kuvaus - Mitä tietoja tarvitaan?
Tarkemmin eri käyttötarkoituksia tukevia mallinnustapoja ja hyviä käytäntöjä on listattu tämän ohjeen lopussa.
Yleisiä mallinnusperiaatteita
- Määrittele soveltamisprofiilille ja mallinnettavalle tietosisällölle selkeä käyttötarkoitus. Selitä käyttötarkoitus tietomallin kuvauksessa.
- Kun määrittelet uuden tietosisällön, käytä tietoalueen sanastoa
- Ehdota uusia käsitteitä, jos tietosisältöä kuvaavaa käsitettä ei ole määritelty sanastossa
- Uudelleenkäytä luokkia, attribuutteja ja assosiaatioita julkisen hallinnon tietokomponenttikirjastosta
- Ennen uuden tietosisällön määrittelyä, tutki onko vastaava tietosisältö määritelty aiheeseen liittyvillä tietoalueilla
- Jos luokkaan joudutaan tekemään usein tietoaluekohtaisia lisäyksiä, määrittele luokasta alaluokka tietoalueelle
Nimeämiskäytännöt
Tietosisältöjen nimeäminen tehdään selkokielisesti hyödyntäen tietoalueen vakiintunutta sanastoa. Luokat, attribuutit ja assosiaatiot nimetään kieliversioituna ihmisluettavasti sekä teknisellä nimellä.
Sisältö lokalisoidaan käyttötarpeen mukaan eri kielillä, yleensä suomi, englanti ja ruotsi. Ihmisluettavissa nimissä ei saa olla kyseiseen kieleen kuulumattomia erikoismerkkejä.
Tekninen nimi määritellään aina alphanumeerisesti ja ainoat sallitut merkit ovat pienet ja isot kirjaimet, numerot, sekä alaviiva ja väliviiva. Teknisen nimen lisäksi resurssille voidaan määritellä paikallinen tunnus, joka kertoo millä nimellä resurssia kutsutaan paikallisessa toteutuksessa. Paikallisen nimen avulla voidaan myös tuottaa XML tai JSON skeema erilaisten teknisten nimeämiskäytäntöjen mukaisesti.
Tietomallin nimeäminen
Tietomallille määritellään ihmisluettava nimi ja etuliite. Tietomallin nimen tulee olla mahdollisimman hyvin käyttötarkoitusta kuvaava, esimerkiksi: "Tutkimusinfrastruktuurien tiedonsiirtomääritys". Lisäksi käyttötarkoitusta on hyvä tarkentaa tietomallin kuvauksessa.
Etuliite on yksilöllinen lyhyt tunniste josta muodostetaan tietomallin tekninen nimi, eli nimiavaruus. Tietomallin nimiavaruus on URI-tunnus, jonka avulla tietomallissa määriteltäviin resursseihin voidaan viitata.
Etuliitteen valinta
Etuliitteen määrittely voi tuntua vaikealta uutta tietomallia tehtäessä. Etuliite muodostetaan yleensä tietoalueella tai projektissa yleisesti käytössä olevasta akronyymistä. Etuliitteen määrittelyssä kuitenkin olennaisinta on se, että se on yksilöivä merkkijono. Esimerkiksi "abc" on yhtä hyvä etuliite kuin "henkilo" tai "personinfo". Lyhyt etuliite kuitenkin helpottaa tunnisteen kirjoittamista lyhennetyssä muodossa, esim: abc:Person. Etuliitettä voi jatkossa vaihtaa tietomallin versioinnin yhteydessä. Etuliitettä vaihtaessa uusi sekä vanha malli voivat jatkaa omaa elämäänsä.
Luokan nimeäminen
Luokka nimetään yleensä yksikkömuodossa.
Luokan tekninen nimi määritellään ns. CamelCase kirjoitusasulla:
- Tekninen nimi alkaa aina isolla alkukirjaimella, esim. Person
- Useamman sanan yhdistelmä esim. SalesContract
- Luokan teknisestä nimestä muodostetaan yksilöivä URI-tunniste, esimerkiksi: http://uri.suomi.fi/datamodel/ns/myexample#Person
Attribuutin nimeäminen
Attribuutit nimetään yleensä yksikkömuodossa. Poikkeustapauksissa attribuutti voidaan nimetä monikossa, jos attribuuttiin tallennetaan useampi tieto, esim. Etunimet.
Nimessä ei kannata toistaa luokan nimeä, esim. "Nimi" ennemmin kuin "Henkilön nimi". Säännöstä saa poiketa jos ei ole selvää mikä "Nimi" on kyseessä esim. jos luokka on denormalisoitu kokoelma Henkilön ja Organisaation tietoja.
Attribuutin tekninen nimi määritellään ns. CamelCase kirjoitusasulla:
- Alkaa pienellä alkukirjaimella, esim: numberOfPages
Assosiaation nimeäminen
Assosiaatiot nimetään yleensä verbimuodossa tai roolin nimellä, esim. purchaced tai customer
Assosiaation tekinen nimi määritellaan CamelCase kirjoitusasulla:
- Alkaa pienellä alkukirjaimella, esim: relatedProduct
Tietosisältöjen tietomallinnus eri käyttötarpeisiin
Tietomalleja voidaan tehdä eri käyttötarkoituksiin, jolloin myös tietosisältöjen karkeus (abstraktiotaso) vaihtelee käyttötarpeen mukaan. Tietomallin tietorakenteet kuvataan myös eri tavoin, esimerkiksi riippuen siitä, määritelläänkö tiedonsiirtomääritystä vai tietokannan kuvausta. Relaatiotietokannan määrittelyssä suositaan yleensä joustavaa tiedon tyypitystä ja roolistusta, jolloin tietokannan rakennetta ei tarvitse muuttaa vaikka tietokantaan haluttaisiin tallentaa uuden tyyppistä tietoa. Tiedonsiirtomäärityksissä suositaan taas usein yksiselitteisempiä tietorakenteita, jolloin tietosisällön ymmärtämiseen ei tarvita niin paljon erillisiä lisätietoja, kuten tietoa tyypittäviä koodistoja.
Yksiselitteinen vs. joustava tietomalli
Joustava tietomalli (dynaaminen) ottaa huomioon tietojärjestelmän muutostarpeen nostamalla tietomallin abstraktiotasoa tyypityksen ja roolituksen avulla. Yksiselitteinen tietomalli (staattinen) määrittelee tietorakenteet ilman tyypityksiä ja rooleja mahdollisimman tarkalla tasolla. Yleensä tietomallinnus on tasapainoilua joustavuuden ja yksiselitteisyyden välillä.
Tiedon tyypitys
Tyypittäminen on tiedon yleistämistä ja luokittelemista tiedon ominaisuuksien avulla. Tietomallissa voidaan kuvata esimerkiksi luokka Auto, mutta sama tieto voidaan yleistää Liikenneväline luokaksi lisäämällä luokalle liikennevälineen tyyppi niminen attribuutti. Tyypittävälle attribuutille voidaan määritellä sallitut arvot koodiston avulla, esimerkiksi tässä tapauksessa arvot 1=Henkilöauto ja 2=Kuorma-auto. Sallitut arvot määritellään yleensä koodistona, jolloin tiedonsiirrossa siirrettävä tietomäärä on vähäisempi ja koodien ihmisluettavat termit ja kuvaukset voivat täydentyä kehityksen edetessä ilman tietojärjestelmien muutostarpeita. Joissain tapauksissa tyypit voivat olla myös tietojärjestelmän sisäisiä referenssitietoja, jotka kertyvät sovellusta käytettäessä.
Tiedon roolitus
Roolittaminen on tiedon tyypittämistä jonkin toisen asian suhteen. Rooliin liittyy siis aina jokin assosiaatio kahden luokan välillä. Rooleja tietomalleissa voi olla esimerkiksi Henkilön rooli Projektissa tai Osoitteen rooli Henkilön yhteystiedoissa.
Myös rooli voidaan määritellä joustavasti tai yksiselitteisesti. Joustavia roolimäärittelyjä ovat esimerkiksi Rooli-luokka tai roolikoodi-attribuutti. Yksiselitteisiä roolimäärittelyjä ovat taas rooli-assosiaatio tai rooliKytkin-attribuutti.
Rooli voi olla myös ajan suhteen muuttuva, jolloin roolitieto kertoo myös millä ajanhetkellä kyseisellä tiedolla on ollut kyseinen rooli.
Esimerkkejä tyypeistä ja rooleista
Sama tietosisältö voidaan kuvata monesta eri näkökulmasta käyttäen erilaisia tietorakenteita. Esimerkiksi Projektiin liittyvät Henkilöt voidaan kuvata Henkilön tai Projektin näkökulmasta (Esimerkki 1 ja 2). Esimerkeissä on käytetty tiedon tyypittämistä ja roolittamista eri tavoin. Projektiin liittyvien henkilöiden rooli voidaan kuvata yksiselitteisesti Projektin ja Henkilön välisenä assosiaationa (Esimerkki 1) tai Henkilön ominaisuutena (Esimerkki 2). Roolitus ja tyypitys ovat yksiselitteisiä kun niiden arvojen esittämiseen ei tarvita koodistoja.
Esimerkki 1: Projektin henkilöt
Esimerkki 2: Henkilön projektit
Rooli voidaan kuvata myös joustavasti koodiston avulla. Tilanteesta riippuen tietomallissa voidaan määritellä Rooli niminen attribuutti tai assosiaatio Rooli nimiseen luokkaan (Esimerkki 3 ja 4). Erillisen tyyppi/rooli koodistojen avulla tietomallista tulee joustavampi, jolloin koodiston arvoja voidaan muuttaa myöhemmin muuttamatta itse tietomallia.
Esimerkki 3: Henkilön rooli attribuutti
Esimerkki 4: Henkilön rooli luokkana
Rooli voidaan kuvata tarpeen mukaan myös ajallisenä ilmiönä, jolloin tietty henkilö voidaan määritellä olevan tietyssä roolissa tiettyyn aikaan (Esimerkki 5).
Esimerkki 5: Rooli ajallisena ilmiönä
Rooliin liittyviä tehtäviä voidaan kuvata myös ilman varsinaista roolimäärittelyä assosiaatioiden avulla (Esimerkki 6). Tämä tietomalli kuvaa saman asian kuin aiempi esimerkki, mutta sen tietosisältöä ei voida laajentaa ilman tietomallimuutosta.
Esimerkki 6: Rooli ajallisena ilmiönä kuvattuna assosiaatioilla
Roolia ja vastuuta voidaan kuvata myös tarkemmin käyttämällä assosiaatioita ja määrittelemällä rooleille omat tarkennetut luokat (Esimerkki 7). Roolikohtaisien assosiaatioiden ja tarkennettujen luokkien avulla voidaan määritellä roolikohtaisia lisätietoja.
Esimerkki 7: Rooliluokkien määrittely
Joissain tapauksissa mallinnettava toimija halutaan määritellä abstraktina luokkana. Tällöin voidaan määritellä abstrakti "kuori"-luokka (Esimerkki 8). Tässä esimerkissä Projektitoimija voi olla joko Henkilö tai Organisaatio. Kyseinen mallinnustapa vastaa XML skeemassa choice tai JSON skeemassa oneOf -määrityksiä.
Esimerkki 8: Vaihtoehtoinen luokka
Vaihtoehtoinen luokka voidaan määritellä myös yksiselitteisesti assosiaatiolla ilman roolia ja kuori-luokkaa (Esimerkki 9). Tällöin kuvataan erilliset assosiaatiot eri tyyppisille tietosisällöille.
Esimerkki 9: Vaihtoehtoinen luokka erillisinä assosiaatioina
Tiedonsiirtomäärityksen kuvaaminen
Tiedonsiirtomääritys kuvataan tietojärjestelmien välisen tiedonsiirron toteuttamiseksi. Tiedonsiirtomääritys kuvaa tietosisällön rakenteisena asiakirjana, jonka avulla tietosisältö voidaan validoida ja siirtää tietojärjestelmien välillä. Tiedonsiirron kohteena on yleensä yksittäinen tietokokonaisuus suuremmasta tietojoukosta. Tietoa siirrettäessä suositaan yleensä yksiselitteistä tietomallia, jolloin tietosisältö on paremmin tulkittavissa ilman erillisiä koodistoja.
Soveltamisprofiilin avulla voidaan määritellä ja dokumentoida siirrettävät tietosisällöt ja tuottaa XML tai JSON skeema jota voidaan hyödyntää tiedonsiirron toteutuksessa. Soveltamisprofiilissa rakenteisen asiakirjan voi määritellä kuvaamalla tietomallille juurisolmun. Juurisolmu (Root element) on rakenteisen asiakirjan ensimmäinen elementti, jonka alle siirrettävä tietosisältö on kuvattu hierarkkisena tietorakenteena.
Sovellusrajapinnan tai tietojärjestelmän kuvaaminen
Sovellusrajapinnan tai tietojärjestelmän tietosisältöä muuttavien operaatioiden kuvaaminen tietomallin avulla voi olla hyvin työlästä. Jos esimerkiksi toteutetaan rajapinta jonka avulla voidaan hakea sähköisestä kaupasta tuotteita, mallinnetaanko erikseen kaikki pyynnöt joilla tuotteita voi hakea? Entä mallinnetaanko erilaisia attribuutteja sisältävät tuotetyypit erillisinä tarkennettuina luokkina?
Rajanveto tarkan ja abstraktin tietomallinnuksen välillä on hyvin tapauskohtaista. Rajapinnan tietomallinnuksessa pyritään yleensä kuvaamaan tietojärjestelmän tietosisältö riittävän yleisellä tasolla, jotta voidaan kuvata tietyn sanomatyypin tietosisältö yhdellä luokalla / tietomallilla. Yleistä tietomallia voidaan käyttää rajapintakuvauksessa lähtökohtana (Base-skeemana), jonka päälle tarkemmat kuvaukset rakentuvat.
Tietovaraston tai tietokannan kuvaaminen
Tietomallit työkalu ei tue relaatiokannan teknistä kuvaamista. Soveltamisprofiilin avulla voidaan kuitenkin tehdä ns. tietokannan käsiteanalyysi, jossa tietokannan tietosisältö kuvataan sisällöllisesti. Attribuuteille voidaan myös määritellä sovellusriippumattomat tietotyypit ja arvoaluerajoituksia, joita tehdään yleensä loogisen tason tietomallissa. Soveltamisprofiilia mallintaessa on hyvä huomioida että tietosisältöjen väliset relaatiot kuvataan suunnattuina assosiaatioina (Directed association), esimerkiksi. Henkilö → Osoite. Tämä eroaa perinteisestä ER-mallista jossa assosiaatio määritellään viiteavaimien avulla. Soveltamisprofiilissa assosiaatiot kuvataan tarvittaessa molempiin suuntiin yksiselitteisesti, esimerkiksi: Henkilö -työskentelee→ Organisaatio ja Organisaatio -työntekijä→ Henkilö.
(Tähän esimerkki ER mallista ja vastaavasta soveltamisprofiilista)
Tietosisällön yleinen mallintaminen
Tietomallit työkalulla määriteltävien soveltamisprofiilien ensisijaisena tarkoituksena on toimia ihmisten välisinä sopimuksina käytettävistä tietosisällöstä. Tämä tarkoittaa sitä että tietomalleja voidaan tehdä dokumentoimaan eri tyyppisiä asioita. Uuden soveltamisprofiilin voi tehdä esim. projektisuunnitelman yhteydessä hahmotelmaksi tulevan tietojärjestelmän tallentamista tiedoista. Yhtä hyvin tietomallin voi määritellä selventämään käsitteellisiä erimielisyyksiä suunniteltaessa kahden eri organisaation välistä tiedonsiirtoa.
Osa soveltamisprofiileista voi siis olla hyvin abstraktilla tasolla määriteltyjä käsitemalleja. Kaikki erityyppiset tietomallit ovat kuitenkin eri näkökulmista arvokkaita, vaikka tietomallista ei olisi olemassa fyysistä toteutusta.