Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Yhteentoimivuusvälineistön yleisenä tietomallinnusperiaatteena on tietosisältöjen linkittäminen ja uudelleenkäyttö. Käytännössä tämä tarkoittaa eri tahoilla määriteltävien, uudelleenkäytettävien tietokomponenttikirjastojen hyödyntämistä tietojärjestelmien tietomallinnuksessa. Tietomalleja, jotka uudelleenkäyttävät aikaisemmin määriteltyjä tietomalleja ja kansainvälisiä standardeja, kutsutaan soveltamisprofiileiksi.

Soveltamisprofiilin tietomallinnus eroaa perinteisestä tietomallinnuksesta siten, että kaikki määriteltävät tietosisällöt saavat pysyvän URI-tunnisteen, jonka avulla tietomääritys voidaan löytää, linkittää ja uudelleenkäyttää. Perinteinen tietomalli määritellään itsenäisenä kokonaisuutena, jossa tietorakenteet saavat pelkästään paikalliset tunnisteet ja tietomallien välinen uudelleenkäyttö tarkoittaa käytännössä tietomääritysten kopiointia ja uudelleenmäärittelyä. Soveltamisprofiilin määrittelyssä tarkoituksena on uudelleenkäyttää samalla tietoalueella määriteltäviä uudelleenkäytettäviä luokkia (Tietokomponentteja), sekä linkittää tietomalli tietoalueen sanastoihin ja koodistoihin.

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, uudelleenkäytä tietoalueen sanastoa
    1. Ehdota uusia käsitteitä, jos tietosisältöä kuvaavaa käsitettä ei ole määritelty sanastossa
    2. Kirjoita tietosisällölle tarkempi kuvaus tapauskohtaisesti. Kirjoita, miksi tietosisältö on olemassa ja miten sitä vastaavaa tietosisältöä tulee käsitellä.
  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
    3. Kirjoita tarkennettu kuvaus tapauskohtaisesti. Jos tietomallissa on useita samantyyppisiä tietosisältöjä, kerro miten tietosisällöt eroavat toisistaan.

Soveltamisprofiilin mallintaminen

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ö - Miten Mitä tietoa siirretään?
  2. Sovellusrajapinnan tai tietojärjestelmän tietosisältö - Miten Mitä tietoa käsitellään?
  3. Tietovaraston Tietovarannon tietosisältö - Miten 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 attribuuteillaattribuuttien ominaisuuksilla, kuten kentän toistuvuus tai vähimmäispituus, voidaan määritellä sääntöjä tiedon eheydelle.

...

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 Sovellusrajapinnan tietomallinnuksessa pyritään yleensä kuvaamaan tietojärjestelmän tietosisältö riittävän yleisellä tasolla, jotta voidaan kuvata tietyn sanomatyypin useammassa operaatiossa käytettävä 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.

...

...

Tietovarannon kuvaaminen

Soveltamisprofiilin avulla voidaan dokumentoida tietovaraston 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 mikä 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 YhteystietoAssosiaatio kuvaa luokkien välistä suhdetta yhden luokan näkökulmasta.


Kuva 1: Esimerkki henkilön yhteystiedoista.

...

Vastaava tietosisältö voidaan kuvata ER-kaavion avulla usealla eri tavalla. Yksisuuntainen yhteystieto assosiaatio tietomallissa tarkoittaa sitä, että Yhteystiedot luokan suhdetta Henkilö luokkaan ei ole määritelty. Seuraavassa fyysisen tason ER-kaaviossa (Kuva 3.) Esimerkissä on huomioitu kaksi esitetty kolme eri toteutustapaa, jotka eroavat toisistaan tietojen toistuvuuden ja viitteiden eheyden suhteen. Jos assosiaatioita ei ole kuvattu erikseen molempiin suuntiin erikseen, voidaan siitä tehdä erilaisia tulkintoja. 


Image AddedImage Removed

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

...

Henkilo_1 määrittelee pakollisen viiteavaimen Yhteystiedot_1taulusta, joka tarkoittaa sitä että kyseiseen kantaan ei voida tallettaa henkilöä ilman yhteystietoja. Yhteen henkilöön voi kuitenkin liittyä vain yksi yhteystietoYhteystiedot_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

Yhteystiedot_2 määrittelee pakollisen viiteavaimen Henkilo2 taulusta, joka tarkoittaa että kyseiseen kantaan voidaan tallentaa henkilöitä joihin ei liity yhteystietoja. Yhdellä henkilöllä voi kuitenkin nyt olla useampi yhteystieto

Vaihtoehto 23

Henkilo_2 ja 3 ja Yhteystiedot_23 välille määritellään välitaulu, jonka avulla voidaan kuvata, mikä yhteystieto kuuluu millekin henkilölle. Tilanteesta riippuen tämä vaihtoehto voi olla soveltuvin. Yksisuuntaisen assosiaation kardinaliteetin perusteella ei voida suoraan tietää pitääkö luokkien välille muodostaa välitaulu. Välitaulu voidaan muodostaa tapauskohtaisesti kun kardinaliteetti on 1..*. 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, jossa kuvataan tietosisällön semantiikkaa yksittäisten objektien näkökulmasta.  Tietokannan todellista rakennetta vastaava fyysinen ER-kaavio (fyysinen tietomalli) on hyvä tehdä erikseen. Jos soveltamisprofiilissa halutaan määritellä tarkemmin saako samaan yhteystietoon liittyä useampi henkilö, on soveltamisprofiilissa kuvattava erillinen Yhteystiedot -liittyy-(1..*)-> Henkilo -assosiaatio (Kuva 4).


Image Added

Kuva 4. Assosiaatiot molempiin suuntiin

Vastaavassa loogisen tason ER-kaaviossa assosiaatiot voidaan yhdistää yhdeksi kaksisuuntaiseksi assosiaatioksi (Kuva 5).

Image Added

Kuva 5. Assosiaatioiden tulkinta relaatiomallissa


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.

...

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 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:

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

Yksiselitteinen vs. joustava tietomalli

Tietomalleja tehdään eri Tietomalleja voidaan tehdä eri käyttötarkoituksiin, jolloin myös tietosisältöjen karkeus (abstraktiotaso) vaihtelee käyttötarpeen mukaan. Tietomallin tietorakenteet tietorakenteita 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

kun määritellään tiedonsiirtomääritystä tai tietokannan sisältöä. 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ä.

Tietokannan tietosisällön määrittelyssä suositaan yleensä joustavaa tiedon tyypitystä ja roolitusta, 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 tarvitaan vähemmän erillisiä lisätietoja. Tietoa tyypittäviä ja roolittavia koodistoja käytetään kuitenkin tiedonsiirrossa tapauksissa, joissa tietosisällön voidaan olettaa muuttuvan tai tarkentuvan ajan kuluessa. Tiedonsiirrossa siirretään myös yleensä pienempi määrä tietoa, kun vastaavasti tietokanta rakennetaan säilyttämään kaikki sinne tallennettava tieto. 

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  -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ä tallennettava 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. 

...

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.

...

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).

...

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 tietomallimuutostatietomallin muutosta.  

Esimerkki 6: Rooli ajallisena ilmiönä kuvattuna assosiaatioilla 

...

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 9: Vaihtoehtoinen luokka erillisinä assosiaatioina


Roolin kuvaus eri näkökulmista liittyy vahvasti käyttötarpeeseen. Eri käyttötarpeissa tarvitaan rikkaampia ja tarkempia tietoja kuvaamaan tarvittavia tietosisältöjä. Yleisesti voidaan todeta että esimerkkien 1-9 tarkkuus ja rakenteisuuden taso vaihtelee käyttötarpeen mukaan.

Rakenteisuuden taso

Rakenteisuus tietomalleissa tarkoittaa käsiteltävien tietojen esittämistä sopivalla tarkkuustasolla. Sopiva rakenteisuuden taso määrittyy tietojärjestelmien käsittelysääntöjen kautta. Tiedot tulee kerätä riittävän tarkalla tasolla, jotta tietoa voidaan käsitellä automaattisesti erilaisissa prosesseissa.

Rakenteistamattoman tiedon käsittelyyn voidaan käyttää kuvailevia metatietoja ja tiedon tyypittämistä. Esimerkiksi asianhallintaprosessissa käsiteltävän asian tila kuvataan koodiston avulla, jonka tarkoituksena on mahdollistaa asian käsittelyn seuranta.