Käyttäjähallinnan ja henkilötietojen hakupalvelun tekninen dokumentaatio

Transkriptio

1 Käyttäjähallinnan ja henkilötietojen hakupalvelun tekninen dokumentaatio Yleinen kuvaus Arkkitehtuuri Sisäiset integraatiot Ulkoiset integraatiot Teknologiat Käyttöliittymät Henkilöiden käsittely Anomusten käsittely Lupien käsittely Käyttöoikeusryhmien käsittely Itserekisteröinti Duplikaattihenkilöiden linkitys Rajapinnat SOAP (vanhentunut) REST Swagger-dokumentaatiot Tietomalli Postgres Muuta Yleinen kuvaus Käyttäjä- ja henkilöhallintapalvelulla hallinnoidaan palvelun eri käyttäjien (oppija, virkailija, palvelu) tietoja, luodaan uusia ja passivoidaan vanhoja sekä hallitaan käyttöoikeuksia ja huolehditaan henkilöiden käyttäjätunnuksista ja salasanoista. Järjestelmällä hallinnnoidaan myös tallennettujen henkilöiden henkilötietoja mm. yhteistietoja ja VRK:sta saatuja tietoja. Palveluiden vastuulla on myös yksilöidä henkilö, jotta varmistutaan ettei ko. henkilöllä ole useita identiteettejä järjestelmässä. Käyttäjä voi esiintyä järjestelmässä eri henkilötyyppeinä: virkailijana, oppijana, palvelukäyttäjänä ja jatkossa mahdollisesti myös OpenDATA-käyttäjänä. Henkilötyyppi vaikuttaa kyseisen käyttäjän pakollisiin henkilötietoihin ja osaan toimintoja, mihin käyttäjä pääsee. Käyttäjä voi anoa tarvittavia oikeuksia käyttäjähallintapalveluun kuuluvalla toiminnallisuudella. Käyttäjähallinta ei automaattisesti myönnä oikeuksia pelkän tunnistautumisen pohjalta vaan anomuksien perusteella, jotka eri organisaatioiden pääkäyttäjät hyväksyvät. Jokaiselle organisaatiolle nimetään pääkäyttäjä, joka hallinnoi ja on vastuussa oman organisaationsa käyttäjistä ja niiden käyttöoikeuksista. Organisaation pääkäyttäjä voi olla hallinnollisesti vastuutettu henkilö, ja varsinaisen operoinnin suorittaa organisaation sisällä joku toinen henkilö hänen puolestaan. Organisaation pääkäyttäjä tai hänen valtuuttamansa henkilö voi lisätä henkilöitä palveluun ja antaa näille käyttöoikeuksia omien oikeuksiensa ja organisaatiorajoitusten sisällä. Kyseisen organisaation käyttäjä voi myös anoa uusia käyttöoikeuksia oman organisaationsa pääkäyttäjältä palvelun sähköisellä virkailijan käyttöoikeuksien anomis- ja myöntämispalvelulla. Organisaatioiden tulee päättää oma käyttöoikeuksiensa hallinnan prosessi omien tarpeidensa perusteella. Henkilöhallinta antaa jokaiselle käyttäjälle kansallisen oppijanumeron, joka on uniikki OID-tunniste, jonka omistaa OPH. Tätä tunnistetta voidaan käyttää asioinnissa henkilötunnuksen sijasta, sillä se ei itsessään paljasta mitään arkaluonteista tietoa henkilöstä. Authentication-palvelukokonaisuuden tehtävänä on tunnistaa käyttäjä eri tunnistusmekanismien avulla, joita voivat olla: Käyttäjätunnus ja salasana (Virkailijan tunnus) Haka (korkeakoulut) Vetuma (Ei tuotaantoon viety, toteutus olemassa, Tunnistaa virkailijan, joka on kirjattu järjestelmän henkilötunnuksella.) Arkkitehtuuri Käyttäjä- ja henkilöhallintapalvelu koostuu kahdesta kerroksesta. Käyttöliittymästä (henkilo/authentication-henkiloui) ja palvelukerroksesta (henkilo/authentication-service). Kaikki sisäiset ja ulkoiset rajapinnat ovat palvelukerroksessa. Rajapinnat ovat REST-tyyppisiä. Vanhoista SOAP rajapinnoista pyritään luopumaan. Niiden käyttämistä ei suositella.

2 Käyttäjä- ja henkilöhallintaan on liitetty nopeaan käyttäjätiedon hakemiseen käytettävä LDAP-käyttäjätietokanta, jonka ylläpito ajantasaisella tiedolla on käyttäjä- ja henkilöhallinnan vastuulla. Myös pääsynhallinta ja autentikoituminen on vahvasti riippuvainen käyttäjä- ja henkilöhallinnasta sekä LDAP:sta. Koska autentikoitumiseen vaadittavat tiedot vain luetaan LDAPista, on erittäin tärkeää, että nämä tiedot ovat aina mahdollisimman hyvin ajan tasalla. Tästä huolehtii käyttäjä- ja henkilöhallinnan päässä oleva päivitysjärjestelmä. Nämä kaikki komponentit ovat h enkilo-repositoryssä. Normaali käyttäjätunnus ja salasanalla autentikoitumiseen liittyvä toiminta on toteutettu Jasig CAS:n avulla ja Haka tunnistamiseen vaadittu SAML2 SP tuki on toteutettu Spring Security kirjaston tuella. Nämä kaikki komponentit ovat authentication-repositoryssä. Sisäiset integraatiot

3 Ulkoiset integraatiot Henkilötietolähteenä käytetään Väestörekisterikeskuksen väestötietojärjestelmää (VTJ). VTJ Client on REST palvelu, joka peittää asynkroonisen SOAP yhteydenoton VTJ järjestelmään. Opintopolun virkailijan puolen pääsynvalvonta ja tunnistamisen osa-alue on integroitu muiden toimittajien toimittamiin järjestelmiin. Integraatiot on tehty CASin osalta julkisiin verkko-osoitteisiin QA:n ja tuotannon osalta.

4 Teknologiat Nimi Kuvaus Käyttö palvelussa Linkki Apache CXF Jackson Sovelluskehys rajapintapalveluiden luomiseen. Sillä voidaan luoda esim. JAX-WS ja JAX-RS tyyppisiä palveluita. Se tukee myös useita eri protokollia esim. SOAP, XML/HTTP, RESTful HTTP ja CORBA. Kirjasto JSON-muotoisen informaation käsittelyyn.

5 Hibernate Spring ORM (object-relational mapping) -kirjasto. Se tukee JPA 2.0:aa. Yleinen sovelluskehys Java-ohjelmien tekemiseen. Castor XML XML-Object- mapping kirjasto Jersey JPA AngularJS Kirjasto RESTful Web Services palveluiden tekemiseen (JAX-RS). Spesifikaatio relationaalisen datan hallintaan Java-sovelluksissa. AngularJS on Googlen ylläpitämä avoimen lähdekoodin JavaScript-viitekehys Käyttöliittymät Käyttäjä- ja henkilöhallinnan käyttöliittymät on toteutettu staattisilla html-sivuilla ja AngularJS:n avulla toteutetuilla JavaScripteillä. Käyttöliittymiä on useita vaikka ne kaikki ovat käyttäjä- ja henkilöhallinnan alaisia ja käyttävät viime kädessä samoja REST-rajapintoja. Käyttöliittymät voidaan jakaa viiteen pääkategoriaan: henkilöiden käsittely anomusten käsittely lupien käsittely käyttöoikeusryhmien käsittely itserekisteröinti Nämä viisi pääkategoriaa on sijoitettu koodipuussa seuraaviin hakemistoihin: henkilöiden, anomusten ja lupien käsittelyt: henkilo/authentication-henkiloui kayttöoikeusryhmien käsittelyt: henkilo/authentication-groups itserekisteröinti: henkilo/registration-ui Jokaisen pääkategoria koostuu useasta eri näkymästä ja toiminnallisesta sivusta, jotka on kuvattu pääpiirteittäin seuraavissa alikappaleissa Henkilöiden käsittely Henkilötietojen käsittelyä varten on olemassa kaksi erilaista käyttöliittymää käsitteellisellä tasolla, jolla erotetaan se, että kuka tietoja käsittelee. Käsittelijänä voi olla joko henkilö itse, joka käsittelee omia tietojaan tai sitten kyseessä voi olla virkailija, joka käsittelee toisen henkilön tietoja. Tämä jako on tärkeä sen suhteen, koska virkailijalla ei ole oikeutta käsitellä omia tietojaan virkailijaliittymän kautta. Tämä tarkoittaa esimerkiksi sitä, ettei virkailija voi myöntää itselleen oikeuksia, vaan tähän tarvitaan toinen virkailija. Henkilöiden käsittely tehdään seuraavien näkymien kautta: henkilöiden haku ja listaus (nimellä, OID:lla, käyttäjätunnuksella, käyttöoikeudella, organisaatiolla, jne.) henkilön tietojen katselu virkailijanäkymästä, joka näyttää henkilön kaikki tiedot henkilön tietojen muokkaus virkailijanäkymästä (nimitietojen, yhteystietojen, käyttöoikeuksien, organisaatioiden, yms.) omien tietojen katselu ja muokkaus (nimitietojen, yhteystietojen, yms.) Jokaiselle näkymälle on oma staattinen html-sivunsa, joiden tiedostonimet kuvaavat käyttötarkoitusta. Näitä näkymiä on useita, johtuen useista dialogeista ja alisivuista, joita käytetään määritettäessä käyttöoikeuksia ja organisaatioita henkilöille sekä selvittämään mahdollisia duplikaattihenkilöitä ja yksilöiviä VTJ-tietoja. Alla on kuvattu näkymien suhde toisiinsa alkaen virkailijan raameista.

6 Kuten kuvasta näkyy, pääjako käyttöliittymässä omien tietojen ja virkailijapuolen välillä tehdään virkailijan raameissa alasvetovalikossa. Henkilötietojen käsittelyn nimellä kulkeva käyttöliittymä on siis virkailijan näkymä ja omat tiedot on itsestään selvä. Suurin ero näiden kahden käyttöliittymän välillä on se, mihin REST-rajapintakutsuihin niiden tuottamat pyynnöt kohdistetaan. Taustapalvelimella tapahtuva viestinkäsittely myös eroaa hieman, koska virkailijan tekmät muutokset pystyvät yliajamaan tiettyjä asioita henkilön tietoihin liittyen. Anomusten käsittely Anomusten käsittely hoidetaan samoilla komponenteilla, mitä henkilöidenkin käsittelyssä on käytössä. Anomuksille ja niiden käsittelylle on neljä erilaista näkymää: anomusten teko omien tietojen kautta anomusten hakeminen ja listaus (nimellä, yms.) anomuksen katselu anomuksen hyväksyntä tai hylkäys Näille näkymille on myös omat staattiset html-sivut, joiden käyttötarkoitus selviää niiden tiedostonimistä. Alla on kuvattu näkymien suhde toisiinsa

7 alkaen virkailijan raameista. Anomusten käsittelyyn liittyy tärkeimpänä ominaisuutena anomuksen hyväksymisessä käyttöoikeuksien myöntäminen, joka on riippuvainen Organisaatiopalvelusta. Tämä prosessi on hyvinkin monitahoinen ja mutkikas, johtuen kohdeorganisaatioiden ja oikeuksia myöntävien henkilöiden rajoitteista. Tämä myöntöprosessi on kuvattu alla: Tässä prosessissa lähtöpisteenä voi toimia joko anomuksen hyväksyminen tai suora käyttöoikeuden myöntäminen henkilötietojen kautta. Lupien käsittely

8 Lupien käsittely hoidetaan samoilla komponenteilla, millä henkilötkin käsitellään. Lupien käsittelylle on kaksi samanlaista näkymää, jotka avautuvat dialogiin henkilötietojen muokkaussivulla ja omat tiedot -sivulla olevasta Hae luvat -painikkeesta. Dialogissa esitetään henkilön voimassa olevat luvat checkboxien ja kuvaustekstien avulla. Luvan voi lisätä tai poistaa checkboxien rukseista. Lupia varten kannassa on kolme taulua: lupa, henkilo_lupa ja henkilo_lupa_historia. Lupa-taulu sisältää (base-tietojen lisäksi) koodiarvo- ja optype-kentät, molemmat merkkijonoja. Koodiarvo-kentän tieto yhdistää luvan koodistosta saatavaan koodiarvoon ja lokalisoituun kuvaustekstiin. Opttype-kenttä sisältää (TODO: fill this). Henkilo_lupa-taulu on henkilö- ja lupa-taulujen monen-suhde-moneen yhteystaulu ja sisältää vain voimassa olevia yhteyksiä henkilöiden ja lupien välillä. Myös Henkilo_lupa_historia-taulu sisältää viittaukset sekä henkilöön että lupaan, mutta sisältää lisäksi luvan aloitus- ja mahdollisen lopetuspäivän sekä alkupera- ja alk_per_oid-tiedot. Sinne jää siis tieto myös lopetetuista luvista. Lupien massalisäystä varten on kaksi REST-rajapintaa (ja toteutusta). Molemmat ovat post-tyyppisiä. Ensimmäisen kutsuosoite on /authentication-service/resources/luvat/batchsave ja bodyssa annettava lupadata on muotoa: [ "asetuspvm": " ", "henkilooid": " ", "alkupera": "VIRKAILIJA", "alkuperaoid": " ", "luvat": [ "koodiarvo": "1", "selected": "false" "koodiarvo": "2", "selected": "true" "koodiarvo": "3", "selected": "true" "koodiarvo": "4", "selected": "true" } ] "asetuspvm": " ", "henkilooid": " ", "alkupera": "HAKEMUS", "alkuperaoid": " ", "luvat": [ "koodiarvo": "1", "selected": "true" "koodiarvo": "2", "selected": "false" "koodiarvo": "3", "selected": "true" "koodiarvo": "4", "selected": "true" } ]

9 "asetuspvm": " ", "henkilooid": " ", "alkupera": "OMATIEDOT", "alkuperaoid": " ", "luvat": [ "koodiarvo": "1", "selected": "false" "koodiarvo": "2", "selected": "false" "koodiarvo": "3", "selected": "true" "koodiarvo": "4", "selected": "true" }

10 ] ] } missä asetuspvm on pakollinen lupatiedon alkuperän päivämäärä, sql-timestamp yyyy-mm-dd [ hh:mm:ss.s], henkilooid on pakollinen henkilon yksiloiva oid, alkupera on pakollinen koodiston arvo, alkuperaoid on vapaaehtoinen alkuperään liittyvä oid ja luvat on oliotaulukko, jonka oliot sisältävät koodiarvon (koodistosta) ja selected-booleanin (onko kyseinen lupa voimassa). Toisen REST-rajapinnan kutsuosoite on /authentication-service/resources/luvat/batchsaveb ja bodyssa annettava lupadata on muotoa: [ "asetuspvm": " ", "henkilooid": " ", "alkupera": "VIRKAILIJA", "alkuperaoid": " ", "markkinointi": "true", "tulosnet": "false", "tuloslah": "true", "etenesms": "true" "asetuspvm": " ", "henkilooid": " ", "alkupera": "HAKEMUS", "alkuperaoid": " ", "markkinointi": "true", "tulosnet": "false", "tuloslah": "false", "etenesms": "false" "asetuspvm": " ", "henkilooid": " ", "alkupera": "OMATIEDOT", "alkuperaoid": " ", "markkinointi": "false", "tulosnet": "false", "tuloslah": "true", "etenesms": "false" } ] missä asetuspvm on pakollinen lupatiedon alkuperän päivämäärä, sql-timestamp yyyy-mm-dd [ hh:mm:ss.s], henkilooid on pakollinen henkilon yksiloiva oid, alkupera on pakollinen koodiston arvo, alkuperaoid on vapaaehtoinen alkuperään liittyvä oid ja markkinointi ("1"), tulosnet ("2"), tuloslah ("3") ja etenesms ("4") ovat vapaaehtoisia boolean-arvoja, jotka kertovat, onko kyseinen lupa voimassa - suluissa on vastaava lupa-taulun ja koodiston koodiarvo. Lisäyslogiikka on molemmissa REST-toteutuksissa sama: jos lupadata sisältää luvan aloituksen (esim. koodiarvo: 1, selected: true}) eikä vastaavaa löydy kannasta (ei henkilo_lupa- eikä henkilo_lupa_historia-tauluista), molempiin lisätään uusi tietue. jos lupadata sisältää luvan lopetuksen (esim. koodiarvo: 2, selected: false}) eikä vastaavaa löydy kannasta, ei tehdä mitään kannassa. jos lupadata sisältää luvan aloituksen ja kannasta löytyy vastaava/-ia henkilo_lupa_historia-tietueita, tutkitaan, onko viimeisin löytynyt (vertaillaan sekä aloitus- että lopetuspvm-arvot) tyypiltään luvan aloitus vai lopetus jos viimeisin kannasta löytynyt on luvan aloitus ja lupadata sisältää uudemman asetuspäivän, päivitetään kannassa olevaan uudet arvot (aloituspvm, alkupera ja alkuperaoid).

11 jos viimeisin kannasta löytynyt on luvan lopetus ja lupadata sisältää uudemman asetuspäivän, sekä henkilo_lupa- että henkilo_lupa_historia-tauluihin lisätään uusi tietue. jos lupadata sisältää luvan lopetuksen ja kannasta löytyy vastaava/-ia henkilo_lupa_historia-tietueita, tutkitaan, onko viimeisin löytynyt tyypiltään luvan aloitus vai lopetus jos viimeisin kannasta löytynyt on luvan lopetus ja lupadata sisältää uudemman asetuspäivän, päivitetään kannassa olevaan uudet tiedot (lopetuspvm, alkupera ja alkuperaoid). jos viimeisin kannasta löytynyt on luvan aloitus ja lupadata sisältää uudemman asetuspäivän, henkilo_lupa_historia- tietue päivitetään lopetetuksi (lopetuspvm, alkupera ja alkuperaoid) ja vastaava henkilo_lupa-tietue poistetaan. Käyttöoikeusryhmien käsittely Käyttöoikeusryhmien käsittely on eriytetty henkilötietojen käsittelyn käyttöliittymistä omaksi kokonaisuudeksi ja erilliseksi komponentiksi. Tämä toteutus on koostuu vain kahdesta erilaisesta näkymästä: käyttöoikeusryhmien listaus ja haku nimellä käyttöoikeursyhmien luonti ja muokkaus Käyttöoikeusryhmät ovat itsessään hyvin moniosaisia ja koostuvat käyttöoikeuskokonaisuutena hyvinkin monesta osasta. Koska näiden muokkaaminen on sallittu vain OPH:n omille virkailijoille, on tämä komponentti hyvä pitää erillään henkilöiden käsittelystä selkeyden vuoksi. Alla on kuvattu näkymien suhde toisiinsa alkaen virkailijan raameista. Itserekisteröinti Tällä hetkellä virkailijoita on mahdollisuus tuoda järjestelmään itserekisteröinnin kautta, jossa henkilön pitää syöttää tarvittavat tunnistetiedot itsestään, jotta hän voi päästä järjestelmän käyttäjäksi. Tätä varten on tehty itserekisteröinnin käyttöliittymät, jotka koostuvat kahdesta samankaltaisesta näkymästä: itserekisteröinti Haka-kirjautumisessa itserekisteröinti sähköpostilinkillä Nämä kaksi näkymää ovat vain yksinkertaisia perustietojen syöttönäkymiä, joissa henkilöt täyttävät puuttuvat tiedot (nimet, henkilötunnus, ) järjestelmästä päästäkseen. Itserekisteröinnin toimintalogiikka on riippuvainen näistä syötetyistä tiedoista ja tätä komponenttia kutsutaan aina, kun henkilö kirjautuu Hakalla sisään. Alla on kuvattu näkymien hallinta, koska näihin näkymiin ei ole suoraa yhteyttä virkailijan raameista, vaan pääsy tapahtuu toimintalogiikan kautta.

12 Duplikaattihenkilöiden linkitys Järjestelmässä on mahdollista linkittää saman henkilön duplikaatti-ilmentymät ja luoda primäärihenkilö, joka on ensisijainen ja aktiivinen ilmentymä käyttäjästä. Duplikaattihenkilöt ovat passiivisia, niihin liittyvillä tunnuksilla ei voi kirjautua järjestelmään. Duplikaattien linkitykseen liittyvät säännöt ja prosessi on kuvattu ao. vuokaaviossa.

13 Primäärihenkilö voidaan vaihtaa myös jälkikäteen. Vaihtoon liittyvät säännöt ja prosessi kuvattu alla.

14

15 Rajapinnat SOAP (vanhentunut) Huom! Ei enää käytössä virallisesti, tullaan poistamaan tulevaisuudessa, kun muut liitännäisjärjestelmät lopettavat SOAP-rajapintojen käytön. REST Käyttäjä- ja henkilötietojen hallintapalvelu käyttää REST-rajapinnoissa Spring security -auktorisointiin roolimäärityksiä, joissa on mukana palvelun omat spesiaalioikeudet yleiskäyttöisten oikeuksien lisäksi. Oikeudet määritetään aina roolialiaskokonaisuuksina, joihin kuuluu käyttäjä- ja henkilöhallinnan osalta useampi etuliite, joka yhdistetään varsinaiseen rooliin. Jos henkilön roolimääre-ehto täyttyy, on hänellä tämän jälkeen mahdollisuus käyttää kaikkia metodin sisällä olevia toimintoja. Tällä hetkellä ei ole mitään lisärajoitteita metodin sisäiselle toiminnalle riippuen roolista. Roolialiaksen etuliite ROLE_APP_HENKILONHALLINTA_... ROLE_APP_KOOSTEROOLIENHALLINTA_... ROLE_APP_ANOMUSTENHALLINTA_... Kuvaus Käyttäjä- ja henkilötietojen käsittelyyn tarvittava oikeusmääre Käyttöoikeusryhmien hallintaan tarvittava oikeusmääre Anomusten käsittelyyn tarvittava oikeusmääre Yllä olevat roolialiasetuliitteet yhdistetään aina alla olevan taulukon roolialiakseen, jolloin muodostuu varsinainen rooli palvelukerrokseen. Roolinimi Roolialias Lyhyt kuvaus Tarkennus Lukuoikeus READ Käytetään sellaisissa metodeissa, joissa tehdään vain lukuoperaatioita Tämä on tarkoitettu vain sellaisille käyttäjille, jotka tarvitsevat vain lukuoperaatioita Luku- ja muokkausoikeus READ_UPDATE Käytetään metodeissa, joissa ei tehdä lisäys- eikä poistotoimintoja Tämä rooli mahdollistaa tietojen muokkaamisen sekä käyttöoikeuksien myöntämisen Luku-, muokkausja poisto-oikeus CRUD Käytetään lähes kaikissa metodeissa, joissa pitää tehdä lisäys- ja poisto-operaatioita Tämä mahdollistaa lähes kaikkien metodien kutsumisen poislukien muutamat erikoistapaukset OPH-rekisterinpitäjä OPHREKISTERI Admin-tason rooli, jolla pystyy kutsumaan mitä tahansa metodia Tämä rooli on tarkoitus myöntää vain admin-tason henkilöille Opinto-ohjaajat ja -virkailijat OPOTVIRKAILIJAT EI KÄYTÖSSÄ! Ei ole määritelty vielä mihin metodeihin lisätään! Tämä rooli on alustavasti sellaiseen käyttöön, missä pelkkä lukuoikeus ei riitä, vaatii lisää määrittelyä asteen vastuukäyttäjä 2ASTEENVASTUU EI KÄYTÖSSÄ! Ei ole määritelty vielä mihin metodeihin lisätään! Tämä rooli on alustavasti sellaiseen käyttöön, missä luku- ja muokkausoikeus ei riitä, vaatii lisää määrittelyä... Korkeakoulun vastuukäyttäjä KKVASTUU Tämä oikeus on varattu korkeakoulujen käyttöön. Tämä rooli mahdollistaa READ_UPDATE oikeuksia laajemmat mahdollisuudet henkilöiden hakuun jayksilöintiin liittyviin toimintoihin. Ylläkuvatut roolivaatimukset on lisätty swagger-dokumentaatioon mukaan, joten niitä ole tässä jokaista metodikutsua kohti eritelty. Jotkut REST-rajapinnat vaativat vain sen, että käyttäjä on kirjautunut järjestelmään, jolloin näissä rajapinnoissa ei ole mitään roolivaatimuksia listattuna. Swagger-dokumentaatiot Käyttäjä- ja henkilöhallinnan REST-rajapintojen dokumentaatio on liitetty rajapintojen Java-koodiin, jotta kuvaukset pysyisivät mahdollisimman hyvin ajan tasalla. Näitä kuvauksia ei ole tästä johtuen lisätty tähän Confluence-sivuun. Kehitysympäristön dokumentaatio: QA-ympäristön dokumentaatio: Tuotantoympäristön dokumentaatio:

16 Tietomalli Postgres Kuva Postgres-kannassa olevasta tietomallista. Muuta Tähän muut dokumentoitavat asiat jotka eivät sovi muiden otsikkojen alle (esimerkiksi erilaiset tausta-ajot jne.).