• Created by Unknown User (miika.alonen@gofore.com), last modified on 20.2.2019

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 35 Next »

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 tietojärjestelmän tietosisältöjä eri tarkkuustasoilla. Sisällöllisesti soveltamisprofiili on sopimus siitä miten yhteisesti sovittua kieltä ja tietorakenteita käytetään tietyssä käyttötarkoituksessa.

Soveltamisprofiilin käyttötarkoitukset

Soveltamisprofiilin tietosisältö kuvataan aina tietojärjestelmän kannalta olennaisella tarkkuudella, joka määrittyy käyttötarkoituksen mukaan.  Käyttötarkoitus voidaan jakaa karkealla tasolla neljään eri ryhmään:

  1. Tiedonsiirtorajapinnan tietosisältö - Mitä tietoa siirretään?
  2. Sovellusrajapinnan tai tietojärjestelmän tietosisältö - Mitä tietoa käsitellään?
  3. Tietovaraston tietosisältö - Mitä tietoa säilytetään?
  4. Yleinen tietosisällön kuvaus - Mitä tietoja tarvitaan?

Tiedonsiirtorajapinnan tietosisällön kuvaaminen

Tiedonsiirtomääritys tehdään tietojärjestelmien välisen tiedonsiirron toteuttamiseksi. Määritys kuvaa tietosisällön rakenteisena asiakirjana, jonka avulla tietosisältö voidaan validoida ja siirtää tietojärjestelmien välillä. Tiedonsiirron kohteena on yleensä pienempi tietokokonaisuus suuremmasta tietojoukosta. Tiedonsiirtomäärityksissä suositaan yleensä yksiselitteistä tietomallia, joka kuvaa siirrettävän tietosisällön tietorakenteet siten, ettei siirrettävän tiedon tulkitsemiseen tarvita erillisiä tietolähteitä. Tietosisällön validoinnissa voidaan käyttää myös koodistoja, jotka toteutetaan yleensä enumeraatioina osana tiedonsiirtomääritystä.

Tiedonsiirtorajapinta (REST tai WSDL) tukee yleensä JSON- tai XML-formaattia. Soveltamisprofiilin avulla voidaan määritellä ja dokumentoida siirrettävät tietosisällöt ja tuottaa XML- tai JSON-skeema, jota voidaan hyödyntää rajapinnan toteutuksessa. Soveltamisprofiilissa rakenteisen asiakirjan voi kuvata määrittelemällä tietomallille juurisolmun. Juurisolmu (Root element) on rakenteisen asiakirjan ensimmäinen elementti, jonka alle tietosisältö kuvataan hierarkkisena tietorakenteena. Luokkamäärityksissä kuvattavilla luokan ominaisuuksien attribuuteilla, kuten kentän toistuvuus tai vähimmäispituus, voidaan määritellä sääntöjä tiedon eheydelle.

Jotkin tiedonsiirtorajapinnat käyttävät toimialakohtaisia teknisiä standardeja tiedonsiirtoon, kuten esimerkiksi taloushallinnossa käytössä oleva XBRL tai paikkatiedossa käytetty INSPIRE -suositus. Soveltamisprofiilin avulla voidaan suomentaa ja dokumentoida, mitä standardeja elementtejä kansallisessa toteutuksessa on käytössä. Varsinaisen tietosisällön kuvaaminen soveltamisprofiilin avulla on kuitenkin mahdotonta tapauksissa, joissa standardin mukainen tietorakenne ei määrittele tietosisältöä. Esimerkiksi XBRL-tietomääritysten tapauksessa varsinainen tietosisältö kuvataan erilaisissa koodistoissa, esimerkiksi Kirjanpidon koodistot 2019. Kaikissa tapauksissa teknisen standardin käytön dokumentointi soveltamisprofiilina ei ole mielekästä. Soveltamisprofiili kannattaa kuitenkin tehdä aina tapauksissa, joissa määritellään uusia tietorakenteita tai kansainvälisistä standardeista halutaan poiketa (soveltaa).

Esimerkkejä tiedonsiirtomäärityksistä:

Sovellusrajapinnan tai tietojärjestelmän kuvaaminen

Rajapinnan tai tietojärjestelmän tietomallinnuksessa pyritään yleensä kuvaamaan tietosisältö yleisellä tasolla, jolloin tietomalli kuvaa kaikkia yleisiä tapauksia. Eri tyyppisten operaatioiden vaatimien tarkempien tietosisältöjen kuvaaminen tietomallin avulla voi olla hyvin työlästä. Otetaan esimerkiksi tapaus, jossa haluttaisiin toteuttaa rajapinta, jonka avulla voidaan hakea sähköisestä kaupasta tuotteita. Mallinnetaanko erikseen kaikki parametrit, joilla tuotteita voi hakea? Entä mallinnetaanko kaikki erilaisia attribuutteja sisältävät tuotetyypit erillisinä luokkina?

Erilaisten kombinaatioiden määrä voi olla suuri. Tämän takia rajanveto yksiselitteisen ja joustavan 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. Yleisemmin määriteltyä joustavaa tietomallia voidaan käyttää rajapintakuvauksessa lähtökohtana (Base-skeemana), jonka päälle tarkemmat kuvaukset rakentuvat. Tarpeen mukaan samasta tietojärjestelmästä voidaan tehdä useita tietomalleja, jotka kuvaavat tietojärjestelmän erilaisia rajapintoja.

Esimerkkejä sovellusrajapinnan tai tietojärjestelmää kuvaavista tietomalleista:

Tietovarannon kuvaaminen

Soveltamisprofiilin avulla voidaan dokumentoida tietovarannon tai tietokannan tietosisältö. Tietomallit-työkalu soveltuu kuitenkin huonosti relaatiokannan tekniseen tietomallintamiseen eikä se tue SQL-lauseiden generointia. Työkalussa voidaan kuitenkin tehdä ns. tietokannan käsiteanalyysi, jossa tietokannan tietosisältö kuvataan sisällöllisesti. Tietosisältöjä voidaan kuvata myös loogisella tasolla määrittelemällä attribuuteille sovellusriippumattomia tietotyyppejä ja arvoaluerajoituksia. Soveltamisprofiilia mallintaessa on hyvä huomioida, että tietosisältöjen väliset relaatiot kuvataan suunnattuina assosiaatioina (Directed / Uni-directional association), esimerkiksi. Henkilö → Yhteystiedot. Tämä eroaa perinteisestä ER-mallista jossa assosiaatio määritellään yleensä kaksisuuntaisten assosiaatioiden (Bi-directional association) avulla. Soveltamisprofiilissa yksisuuntaiset assosiaatiot kuvataan tarvittaessa molempiin suuntiin, esimerkiksi: Henkilö -työskentelee → Organisaatio ja Organisaatio -työntekijä → Henkilö.

Tietosisältöä mallintaessa tulee siis ottaa huomioon suhteiden käsitteellinen merkitys. Assosiaation semantiikka kuvataan soveltamisprofiilissa aina luokkakohtaisesti, joka on välttämätöntä eri syntaksien yhteentoimivuuden kannalta. Esimerkiksi henkilön yhteystietoja mallintaessa (Kuva 1) pitää siis määritellä onko henkilöllä yhteystiedot vai yhteystiedoilla henkilö? Tässä tapauksessa on määritelty, että Henkilöllä voi olla yksi tai useampi Yhteystieto. 


Kuva 1: Esimerkki henkilön yhteystiedoista.


Vakionäkymässä visualisoidaan tietosisällön ihmisluettavat nimet (Kuva 1). Lisäksi alla on esitetty kaksi vaihtoehtoista visualisointia, joissa näytetään joko paikallinen tekninen nimi tai pysyvä tunniste (Kuva 2). Eri tyyppisten visualisointien tarkoitus on viestiä tietosisällöstä erilaisille kohderyhmille. Esimerkiksi liiketoiminnan omistajaa kiinnostavat ihmisluettavat nimet, tietomallintajaa tietokannassa käytettävät tekniset nimet, ja integrointisuunnittelijaa määritysten URI-tunnisteet.


Kuva 2: Vaihtoehtoisia nimiä visualisoinnissa. 1 = Tietokannan tai skeeman tekniset nimet. 2 = Pysyvät URI-tunnisteet.


Vastaava tietosisältö voidaan kuvata ER-kaavion avulla usealla eri tavalla (Kuva 3.) Esimerkissä on huomioitu kaksi eri toteutustapaa, jotka eroavat toisistaan tietojen toistuvuuden ja viitteiden eheyden suhteen.


Kuva 3: Esimerkki tietosisällöstä relaatiokannassa.


Vaihtoehto 1

Henkilo_1 määrittelee pakollisen viiteavaimen Yhteystiedot_1, joka tarkoittaa sitä että kyseiseen kantaan ei voida tallettaa henkilöä ilman yhteystietoja. Yhteystiedot_1 tauluun voi kuitenkin tallettaa useita yhteystietoja jotka eivät liity mihinkään henkilöön. Soveltamisprofiililla kuvattu tietomalli (Kuva 1) ei ota kantaa siihen onko kyseinen tilanne sallittu, ellei asia ole kuvattu tekstimuotoisena lisädokumentaationa. Yksisuuntainen assosiaatio tietomallissa tarkoittaa sitä, että Yhteystiedot "ei tiedä" Henkilön olemassaolosta. 

Vaihtoehto 2

Henkilo_2 ja Yhteystiedot_2 välille määritellään välitaulu, jonka avulla voidaan kuvata, mikä yhteystieto kuuluu millekin henkilölle. Henkilöllä voi tässä tapauksessa olla useampi yhteystieto ja kahdella eri henkilöllä voi olla sama yhteystieto. Tilanteesta riippuen tämä vaihtoehto voi olla soveltuvampi. Soveltamisprofiilissa kuvattu tietomalli ei ota kantaa siihen miten tieto talletetaan relaatiotietokantaan.

Soveltamisprofiilissa määritelty tietosisältö voidaan siis toteuttaa relaatiokantana eri tavoin. On huomioitava että tietovarastoa kuvattaessa soveltamisprofiili on ensisijaisesti tietosisällön dokumentaatio. Tietokannan todellista rakennetta vastaava ER-kaavio (fyysinen tietomalli) on hyvä tehdä erikseen.

Esimerkkejä tietovaraston tietosisältöä kuvaavista tietomalleista:

Käsitemallinnus ja tietosisällön yleinen kuvaaminen

Soveltamisprofiilien ensisijaisena tarkoituksena on toimia ihmisten välisinä sopimuksina käytettävistä tietosisällöstä. Tietomallinnusta voidaan siis tehdä jo ennen varsinaista tietojärjestelmäkehitystä. Tällöin puhutaan yleisesti käsitemallinnuksesta tai tietosisällön yleisestä kuvaamisesta. Tietomallien avulla voidaan hahmotella kerättävien tai siirrettävien tietojen kokonaisuutta. Soveltamisprofiilin voi tehdä esimerkiksi projektisuunnitelman yhteydessä tai kesken projektia selventämään käsitteellisiä erimielisyyksiä eri toimijoiden kanssa.

Tietomallit voivat siis olla hyvin abstraktilla tasolla määriteltyjä käsitemalleja. Käsitemallien osalta tietosisältö voi myös tarkentua ajan myötä, jolloin eroa käsitemallinnuksen ja loogisen mallinnuksen välillä ei enää käytännössä ole. Tietomallinnus voidaan esimerkiksi aloittaa hahmottelemalla soveltamisprofiiliin yleisiä käsitteitä ja päätyä lopulta kuvaamaan tiedonsiirtomääritys. Tilanne on yleinen, koska ymmärrys tietosisällöstä kasvaa vähitellen ja vaatimukset tarkentuvat projektin edetessä.

Esimerkkejä yleisistä tietosisältöä kuvaavista tietomalleista:

Yleisiä mallinnusperiaatteita

  1. Määrittele soveltamisprofiilille ja mallinnettavalle tietosisällölle selkeä käyttötarkoitus. Selitä käyttötarkoitus tietomallin kuvauksessa.
  2. Lisää tietomalliin tietoalueella käytössä olevat olennaiset sanastot ja koodistot
  3. Kun määrittelet uuden tietosisällön, käytä tietoalueen sanastoa
    1. Ehdota uusia käsitteitä, jos tietosisältöä kuvaavaa käsitettä ei ole määritelty sanastossa
  4. Uudelleenkäytä luokkia, attribuutteja ja assosiaatioita julkisen hallinnon tietokomponenttikirjastosta
    1. Ennen uuden tietosisällön määrittelyä tutki, onko vastaava tietosisältö määritelty aiheeseen liittyvillä tietoalueilla
    2. Jos luokkaan joudutaan tekemään usein tietoaluekohtaisia lisäyksiä, määrittele luokasta alaluokka tietoalueelle
  5. Kirjoita luokalle tarkka kuvaus tapauskohtaisesti. Kirjoita luokan kuvaukseen, miksi luokka on olemassa ja miten vastaavaa tietosisältöä tulee käsitellä.

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 aakkosnumeerisesti 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ä täsmentää 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 kirjainlyhenne. 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ä vaihdettaessa sekä uusi että 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:

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.

Lisätään:

  • Englanninkielinen ontologiamuotoinen nimeäminen esim. "hasPart"
  • Geneerinen nimeäminen vs. tarkka nimeäminen

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











  • No labels