UKJ:n tietokantaratkaisusta (Petteri Kivimäen selvitys)

 

UKJ:n suunnittelun lähtökohtana on ollut aidosti formaattiriippumattoman tietokantaratkaisun toteuttaminen. Mitä tämä oikeastaan käytännössä tarkoittaa?

Formaattiriippumattomuuden ajatuksena on, että järjestelmän sisäinen tietomalli ei ole suoraan sidoksissa mihinkään tiettyyn tallennusformaattiin. Järjestelmä pystyy ottamaan vastaan ja tuottamaan useissa eri tallennusformaateissa olevaa dataa, jonka lisäksi uusien tallennusformaattien tukeminen tulevaisuudessa on myös mahdollista. Järjestelmään tuotava data muunnetaan tuonnissa käytettävästä formaatista järjestelmän sisäisen tietomallin mukaiseksi ennen tietokantaan tallentamista. Dataa järjestelmästä ulospäin vietäessä muunnetaan data vastaavasti järjestelmän omasta tietomallista viennissä käytettävään formaattiin ennen datan uloskirjoittamista.

Datan muuntaminen järjestelmän sisäisen tietomallin ja eri formaattien välillä on pystyttävä tekemään häviöttömästi ns. round trip –periaatteen mukaisesti. Käytännössä tämä tarkoittaa sitä, että esimerkiksi MARC21-tietue on pystyttävä muuntamaan järjestelmän sisäiseen tietomalliin ja takaisin MARC21-muotoon niin, että dataa ei häviä missään konversion vaiheessa. Mikäli dataa häviää jossakin prosessin vaiheessa, ei round trip –periaate toteudu.

Formaattiriippumattomuuden toimiminen käytännön tasolla edellyttää järjestelmän sisäisen tietomallin ja järjestelmän tukemien formaattien välisten mäppäysten tekemistä. Koska kyseessä on UKJ:n oma sisäinen tietomalli, joka ei ole muualla käytössä, on kaikki mäppäykset tehtävä itse. Mäppäyksien teossa voitaneen kuitenkin ainakin osittain hyödyntää jo olemassa olevia eri formaattien välisiä mäppäyksiä.

Vaihtoehdot Kuali OLE:n kannalta

Kuali OLE:n tietokantaratkaisu on periaatteessa formaattiriippumaton, sillä OLE ei aseta rajoituksia tietokantaan tallennettavan datan formaatille. OLE:n suunnittelussa on nimenomaan lähdetty siitä, että järjestelmä ei ole sidottu tiettyihin formaatteihin ja että uusien formaattien lisääminen on mahdollista. Tietokantaan tallennetun datan käyttäminen järjestelmässä kuitenkin edellyttää, että se on järjestelmän ymmärtämässä muodossa. Käytännössä tämä tarkoittaa sitä, että datan tallentaminen tietokantaan on kyllä mahdollista erilaisissa formaateissa, mutta datan käyttäminen järjestelmässä edellyttää uutta formaattia tukevien datan käsittelystä vastaavien osien toteuttamista järjestelmään. Ilman uusien osien toteuttamista järjestelmä ei osaa käsitellä uudessa formaatissa tallennettua dataa.

OLE:n versio 1.0 mahdollistaa datan tallentamisen ja käsittelyn Marc21- ja Dublin Core –formaateissa. Järjestelmä ei kuitenkaan mahdollista datan konvertoimista formaattien välillä, vaan datan jatkokäsittely tapahtuu nimenomaan siinä formaatissa, jossa se on tallennettu järjestelmään. Uuden formaatin lisääminen edellyttää uusien adapterien sekä käyttöliittymien kirjoittamista kaikkiin niihin ohjelman osiin, joissa uudessa formaatissa esitettyä dataa halutaan käsitellä. Toinen vaihtoehto on toteuttaa uuden ja jonkin jo tuetun formaatin välinen konversio. Käytännössä tämä voisi tarkoittaa esimerkiksi itse määritellyssä formaatissa tallennetun datan näyttämistä ja käsittelemistä MARC21-muodossa.

OLE on suunniteltu tukemaan useita rinnakkaisia formaatteja, joten oman sisäisen tietomallin luominen ei tästä näkökulmasta pitäisi olla ongelma. OLE:n tällä hetkellä bibliografisen datan tallennukseen käyttävät formaatit (MARCXML, Dublin Core) ovat siinä suhteessa yhteismitallisia, että kummassakin formaatissa yhtä bibliografista tietuetta vastaa yksi XML-muotoinen tietue. RDA-entiteetteihin perustuvassa tietomallissa yksittäinen MARC-tietue jaetaan sen sijaan neljään erilliseen osaan sekä eri osien välisiin suhteisiin. Järjestelmän näkökulmasta ero on merkittävä ja sen toteuttaminen on varmuudella haastavampaa kuin esimerkiksi uuden yksitasoisen tietomallin lisääminen. Ajatus pitäisi kuitenkin olla täysin toteuttamiskelpoinen, sillä OLE:n on tarkoitus tukea samaan ajatukseen perustuvaa uutta Bibframe-formaattia sen valmistuttua. Mitään aikataulua tuen lisäämiselle, kuten ei myöskään formaatin valmistumiselle kuitenkaan vielä tällä hetkellä ole.

Vaihtoehto 1

Kuali OLE:n MARC21-tallennusformaatin käyttäminen.

• otettavissa käyttöön kohtuullisen nopeasti
• järjestelmää täydennetään niin, että se täyttää UKJ:n vaatimusmäärittelyn vähimmäisvaatimukset
  • omat lisäykset pyritään pitämään minimissä ja rajoittamaan pelkästään OLE:n Describe-moduuliin
    • ei aiheuttane muutoksia OLE:n muihin osiin
      • poikkeuksena konsortio-ominaisuudet, jotka eivät riipu käytettävästä tietomallista
• omia täydennyksiä mm.
  • kenttien ja tietueiden omistajuus
  • kenttien ja tietueiden versiohistoria
  • replikointi (+ sen vaatimat rakenteet ja rajapinnat)
  • järjestelmän kehityksessä seurataan OLE:n yleistä kehitystä
    • Bibframen ja linkitetyn datan tuelle ei ole aikataulua
      • tuen mukana tulevat tod. näk. myös tarvittavat konversiot ja työkalut
      • FRBR:ää tuskin voidaan tukea käyttöliittymässä
        • RDA:n käyttö MARC:issa työlästä

Vaihtoehto 2

Oman tietomallin lisääminen OLE:en.

• tietomalli voidaan suunnitella UKJ:n vaatimusmäärittelyn mukaisesti
• tietovarannon käyttämä sisäinen tietomalli täysin omissa käsissä
  
  • mäppäykset tuettaviin formaatteihin tehdään itse
  • tietomallia voidaan laajentaa/kehittää omien tarpeiden mukaan
  • oman tietomallin käyttö hankaloittaa OLE:n yleisten muutosten tuomista UKJ:hin
    
    • uudet ominaisuudet eivät lähtökohtaisesti toimi ilman omaan tietomalliin liittyviä lisäyksiä ja muutoksia
    • vaatii resursseja ja teknistä osaamista
    • omien lisäysten vaatimaa työmäärää on hankala arvioida
      
      • OLE:n nyt tukemat mallit yksitasoisia – omassa mallissa monia tasoja (vrt. MARC21 vs. RDA-entiteetit)
        
        • uuden yksitasoisen mallin lisääminen olisi todennäköisesti melko yksinkertaista
          
          • tätä OLE nimenomaan tukee
• ei tietoa hankintaan ja lainaukseen tarvittavien muutosten määrästä
• osa muihin moduuleihin tarvittavista muutoksista voi paljastua vasta myöhemmin hankinnan ja käytönhallinnan toteutukseen siirryttäessä
• FRBR:ää voidaan tukea käyttöliittymässä

Vaihtoehto 3

Kuali OLE:n ”halkaiseminen” siten, että bibliografisen tiedon käsittely irrotetaan OLE:sta ja toteutetaan erillisessä OLE:sta irrallisessa järjestelmässä. Hankinnan ja käytönhallinnan toimintojen toteuttamiseen käytetään OLE:n tarjoamaa toiminnallisuutta.

• tietovaranto voidaan suunnitella UKJ:n vaatimusmäärittelyn mukaiseksi
• tietovarannon käyttämä sisäinen tietomalli täysin omissa käsissä
  • mäppäykset tuettaviin formaatteihin tehdään itse
  • tietomallia voidaan laajentaa/kehittää omien tarpeiden mukaan
  • tietovarannon jatkokehitys täysin itse päätettävissä
    • esim. uusien formaattien tukeminen itse päätettävissä
    • OLE:n ”halkaisemisen” vaatimaa työmäärää mahdotonta arvioida
      • ei tietoa kuinka ”siististi” tehtävissä – bibliografista tietoa tarvitaan myös hankinnassa ja käytönhallinnassa
        • optimitilanteessa halkaisu ei aiheuta merkittäviä muutoksia hankintaan ja käytönhallintaan, jolloin OLE:n päivittäminen tulevaisuudessa mahdollista
        • pahimmassa tapauksessa vaatii erittäin suuria muutoksia hankintaan ja käytönhallintaan, joka tekee OLE:n päivittämisestä merkittävästi työläämpää
• osa muihin moduuleihin tarvittavista muutoksista voi paljastua vasta myöhemmin hankinnan ja käytönhallinnan toteutukseen siirryttäessä
  • OLE:n myöhempi kehitys voi pahimmassa tapauksessa hankaloittaa oman metatietovarannon integrointia entisestään
  • FRBR:ää voidaan tukea käyttöliittymässä