dokumendiregister.ee
OtsingAsutusedMCP
Otsing›Tervise- ja heaolu infosüsteemide keskus
Väljaminev kiriAvalik

Pöördumine

Tervise- ja heaolu infosüsteemide keskus · 15. juuni 2026
Seotud ettevõtted
Nortal AS (adressaat)
Viit
6-2/5905-1
Registreeritud
15. juuni 2026
Dokumendi liik
Väljaminev kiri
Adressaat
Nortal AS
Saabumis/saatmisviis
e-post
Funktsioon
6 Projektid ja E-teenuste juhtimine
Sari
6-2 Välisvahenditega seotud projektid ja hankedokumentatsioon
Toimik
6-222/4120
Vastutaja
Ott Mihailov (TEHIK, Äriteenuste osakond, Heaolu valdkond, Arenduste tiim)

Failid

  • 📎Lisa_1_Hankelepingu eseme tehniline kirjeldus.pdf540 KB
  • 📎Lisa_2_Hankelepingu projekt - GAP 1.9 Andmebaasi arhitektuur.pdf290 KB
  • 📎Pakkumuskutse - GAP 1.9 Andmebaasi arhitektuur.pdf176 KB

Sisu (failidest)

Lisa 1 Tehniline kirjeldus 1. Mõisted ja lühendid Mõiste / Lühend Kirjeldus ADR Arhitektuuriline otsus (Architecture Decision Record) AQ Oracle Advanced Queuing — Oracle andmebaasi sisseehitatud sõnumijärjekorra mehhanism Big Bang migratsioon Suur ühekordne migratsioon, kus kogu süsteem viiakse ühe katkestusakna jooksul vanalt platvormilt uuele (vastandina inkrementaalsele teenusepõhisele migratsioonile) BLOB / CLOB Binary / Character Large Object — binaar- või tekstifaili sisu salvestamine andmebaasi Cutover Tootmiskeskkonna ümberlülitus vanalt süsteemilt (Oracle) uuele (PostgreSQL) DoD Valmisoleku kriteeriumid (ingl k Definition of Done) — Tellija ja Täitja vahel kokku lepitud tingimuste kogum, mille täitmisel loetakse töö edukalt lõpetatuks ja vastuvõetuks Dual-database Üleminekuperioodi muster, kus rakendus toimib paralleelselt nii Oracle kui PostgreSQL andmebaasi vastu, võimaldades tagasipööramist EBS Majandustarkvara Oracle E-Business Suite Edasimineku või Ingl k Go/No-Go decision — projekti vaheetapi lõpus tehtav otsus, kas projekt on peatamise otsus järgmise etapi käivitamiseks valmis (edasi minna) või vajab parandusi enne edasiliikumist (peatada) GAP-analüüs Lahknevusanalüüs, olemasoleva SKA infosüsteemi analüüs vastu arhitektuuri tulevikuvisiooni (TO-BE), et selgitada välja ja prioriseerida lahknevuste (GAP) likvideerimiseks vajalikud tööd JPA Java Persistence API — Java rakenduskihi standard relatsiooniandmebaasi kasutamiseks Liquibase changeset Liquibase'i terminoloogias üks andmebaasi muudatuste atomic komplekt, mis on versioonihalduses ja teostatav korrastatud järjestuses POC Kontseptsiooni tõestus (Proof of Concept) PostgreSQL Vabavaraline relatsiooniandmebaasi mootor — käesoleva lepingu sihtplatvorm SKA Sotsiaalkindlustusamet SKAIS1 Sotsiaalkaitse infosüsteem (vananenud platvormil) SKAIS2 Sotsiaalkaitse infosüsteem uus rakendus (hõlmab Ametnikurakendust ja Iseteenindust) 2. Ülevaade Sotsiaalkindlustusamet (SKA) kasutab ülesannete täitmiseks sotsiaalkaitse infosüsteemi, mis koosneb SKAIS1, EBS ja SKAIS2 rakendustest. Tegemist on infosüsteemiga, mida on arendatud hulk aastaid nii, et uute funktsionaalsuste loomise kõrval ei ole jätkunud ressurssi tehnoloogilise ajakohasuse tagamiseks. Süsteemis tekkinud oluliste kitsaskohtade leevendamiseks käivitati 2025. aastal SKA infosüsteemi arhitektuuri tulevikuvisiooni (TO-BE lahenduse) väljatöötamise projekt, mille käigus loodi arhitektuuri reeglistik, millele peavad vastama teostatavad arendused ning migreerimisplaan. Ühtlasi kaardistati probleemid ja eesmärgid, teostati GAP-analüüs, st analüüsiti olemasolevat lahendust vastu TO-BE arhitektuuri, et selgitada välja ja prioriseerida GAP likvideerimiseks vajalikud tööd. Lisaks oli juba varasemast teada kitsaskohti (nt seotud andmebaasidega), mis vajavad lahendamist. Antud leping koondab SKAIS2 andmebaasidega seotud arhitektuuriliste tööde eeltööd, et tagada tuleviku kindlus ja toimepidamine. Selle lepingu tööde tulem võimaldab edasi minna laiapindsemate migratsioonitöödega. Antud lepingu skoobis on andmebaasi arhitektuuri kirjeldus (ADR-ide kujul) ning esimese kolme teenusega POC, mis valideerib eelanalüüsis pakutud lähenemist praktikas ja kalibreerib edasiste etappide töömahuhinnangud. 2.1. GAP 1.9. Andmebaasi arhitektuur Täna on SKAIS-is ajaloolistel põhjustel kasutatud andmebaasi arhitektuuri andmete kirjeldamiseks mitmeid erinevaid viise. Samuti on SKAIS-i paljudel teenustel kasutusel monoliitne andmebaas, mis seab keerukust igale uuele ning muudetavale ärifunktsioonile. GAP 1.9 töö eesmärgiks on kaardistada mõistlikud viisid, kuidas kirjeldada ärilisi ja tehnilisi andmeid. Kuidas rakendada mikroteenuste arhitektuuri toetavat andmebaasi ning kuidas liikuda vabavaralise andmebaasi PostgreSQL poole. 1. Eelnevalt on koostatud SKAIS Oracle → PostgreSQL migratsiooni eelanalüüs (vt lisainfo allpool), mis annab tervikpildi migratsiooni ulatusest, peamistest riskidest, lahtistest arhitektuuriotsustest ja soovituslikust etapilisest tegevuskavast. Eelanalüüsi peamised järeldused: 2. Migratsioon Oracle → PostgreSQL on teostatav, kuid eeldab etapilist teenusepõhist lähenemist; ühtset suurt migratsiooniaega (big bang) ei ole võimalik korraldada. 3. Käesoleva lepingu skoop kattub eelanalüüsis kirjeldatud Etapp 1-ga ja hõlmab paralleelselt nii programmiüleste arhitektuursete lähteotsuste kinnitamist (ADR-ide vormis) kui ka kõrge riskiga teemade praktilist valideerimist POC-idega. Eelanalüüsi Etapid 2–4 (teenusepõhine detailanalüüs, lainete migreerimine ja monoliidi migratsiooniotsus) tellitakse eraldi lepingutega GAP 3.5 ja sellele järgnevate tööde teostamise raames. 4. Eelanalüüs identifitseerib vähemalt 13 lahtist programmiülest arhitektuuriotsust (eelanalüüsi peatükk 4.1), mis tuleb enne suuremate migratsioonitööde alustamist lukustada. 5. Kõrgeima riskiga tehnilised teemad on Oracle AQ asendamine, skeemiülesed sõltuvused, BLOB- failihoidla migreerimine, auditlogi mehhanism ning identiteedikonteksti realiseerimine PostgreSQL-is. 6. Käesoleva lepinguga lukustatakse need lähteotsused ADR-idena ja valideeritakse nende rakendatavust kolme teenuse POC-iga, et anda otsustamiseks kindel alus järgmise faasi (lainete migratsioon) tellimiseks. Käesoleva lepingu skoobist on väljas SKAIS2 monoliidi (`skais2`) andmebaasi migratsioon, süsteemiülene Oracle → PostgreSQL cutover, ajalooliste andmete massmigratsioon ja Oracle-i tootmissüsteemi dekommissioneerimine ning EBS ja SKAIS1 andmebaaside migratsioon. Need on GAP 3.5 (Andmebaasi migratsioon) skoop ning tellitakse eraldi lepinguga käesoleva lepingu väljundite alusel. 2.2. Sõltuvus paralleelsete GAP-töödega GAP 1.9 on eeltingimuseks GAP 3.5 (Andmebaasi migratsioon) tööde sisukokkuleppele — SKAIS Arhitektuur TO-BE GAP-maatriksis on GAP 3.5 sõnastatud nii, et selle töö skoop ja maht sõltuvad GAP 1.9 tulemitest. Käesoleva lepingu väljundid (kinnitatud ADR-id, POC-tulemid ja tagastusringi edasimineku või peatamise otsus on GAP 3.5 detailse migratsiooniplaani ja teenuste lainete kava koostamise sisendiks.  SKAIS Oracle → PostgreSQL migratsiooni eelanalüüs on leitav: o https://wiki.sm.ee/spaces/SKAIS2/pages/441766028/SKAIS+Oracle+- +PostgreSQL+migratsiooni+eelanal%C3%BC%C3%BCs  Seotud GAP-projektid SKAIS Arhitektuur TO-BE lehel: o 3.5 Andmebaasi migratsioon (sõltub GAP 1.9 tulemitest) o 3.9 Andmebaasi schema sõltuvuste kaotamine o 3.10 Andmebaasi versioneerimine o 3.6.1 Andmete krüpteerimine 3. Töö eesmärk Töö eesmärgiks on luua SKAIS2 andmebaaside kasutamise põhimõtted ja neid toetavad arhitektuurilised otsused (ADR-id). Lähtudes seejuures Oracle → PostgreSQL migratsiooni eelanalüüsi tulemist valideeritakse loodud põhimõtteid kolme teenuse POC-i kaudu. Töö tulemina esitatakse järgmiste tööde (GAP 3.5) skoop ja sellest tulenev mahuhinnang. POC-teenuste PostgreSQL-versioonid loovutatakse Tellijale tootmiskvaliteediga lähtekoodina. Tellija (TEHIK või Tellija valitud kolmanda osapoole partner) paigaldab need toodangusse omal valitud aja ja korra alusel. 4. Tellitavad tööd Lepinguga tellitakse SKAIS2 andmebaaside ümberstruktureerimise põhimõtted ja nende valideerimine kolme mikroteenusega vähemalt järgmises ulatuses:  Eelanalüüsi (peatükk 4.1) lahtistele otsuskohtadele ADR-ide loomine — lepinguga lukustatakse vähemalt 13 programmiülest arhitektuuriotsust, sh näiteks: o Oracle AQ ja scheduleri asendamine PostgreSQL-i alternatiividega; o krüpteerimislähenemine ja võtmehalduse infrastruktuur; o identiteedikonteksti tehniline teostus PostgreSQL-is; o auditlogi arhitektuurivalik; o dual-database perioodi mudel ja tagasipööramise strateegia; o JPA päringustrateegia ja uute entiteetide primaarvõtme tüüp.  Kolme SKAIS2 mikroteenuse — `notification`, `offering` ja `disability-application` — andmebaasi detailanalüüs ja POC migratsioon Oracle-ist PostgreSQL-i. Teenused on valitud Tellija ja arhitektuuripartnerite ühisarutelu tulemusena, lähtudes eelanalüüsi peatükis 5.2 toodud kandidaatidest ja riskide katvuse põhimõttest.  Migratsioonilahenduse ja tagasipööramise strateegia tehniline analüüs ja teostus POC-teenuste tasemel, sh dual-database mustri valideerimine ja feature flag'idega juhitavad lugemise ja kirjutamise suunad.  Taaskasutatav migratsioonitestimise ja andmemigratsiooni baasraamistik, mis on aluseks järgnevatele migratsioonilainetele.  Testimisstrateegia ja valmisoleku kriteeriumid (DoD) iga POC-teenuse jaoks — sh vastutuste jaotus testimisel, nõutavate automaattestide minimaalne kogum ja kvaliteedikriteeriumid POC-teenuse vastuvõtuks.  POC-tulemuste tagastusring koos töömahu kalibreerimisega ning edasimineku või peatamise otsus järgmise faasi (GAP 3.5) käivitamiseks.  Muud arendusvajadused, mis selguvad analüüsi käigus ja on olulised realiseerida käesoleva lepingu skoobis.  Tööde loetelu tekib eelnevalt kokkulepitud backlogi alusel ja hallatakse Jiras. 5. Tööprotsess ja tulemid Järgnevalt täpsustatakse täitjaga sõlmitud lepingus kirjeldatud tingimusi tööprotsessi, dokumenteerimise, töökorralduse, testimise ja mittefunktsionaalsete nõuete osas. 5.1. Tööprotsess  Tööraamistik peab tuginema etapiviisilisele planeerimisele, võimaldades arendusmeeskonna prioriteete jooksvalt muuta;  Tööraamistik peab võimaldama süsteemset ülevaadet iga kokkulepitud töö saavutustest;  Tööraamistik peab võimaldama arendusmeeskonna tulemuslikkuse (kasvu) jälgimist ajas;  Tööraamistik peab tagama, et arendusmeeskond tegeleb omal initsiatiivil enda tulemuslikkuse parandamisega ja parendusettepanekute esitamisega.  Täpsem protsess lepitakse kokku tööde käigus. 5.2. Dokumentatsioon Vastavalt tehnilise kirjelduse punktis 4 (tellitavad tööd) tuleb töö käigus luua ja täiendada SKAIS2 dokumentatsiooni, milleks on minimaalselt:  Funktsionaalsuse ja äriprotsesside kirjeldused kokkulepitud kujul (nt BPMN standard, diagrammid ja kirjeldused Confluence’is) koos ärireeglitega, mida peab olema hiljem võimalik täiendada järgnevates etappides lisanduva funktsionaalsuse alusel ning siduda tervikliku protsessi- ja ärireeglite kirjeldusega.  Tehniline dokumentatsioon (nt paigaldusjuhendid, Confluence keskkonnas).  Andmemudel.  Kasutusjuhendid.  Dokumentatsiooni täpsed liigid ja sisu formaat lepitakse kokku tööde käigus, kuid see peab vastama minimaalselt järgnevatele nõuetele: Nõuded arendusprojektide dokumentatsioonile SKAISi näitel - SKAIS2 - Sotsiaalministeeriumi wiki 5.3. Töökorraldus Projekti töökorraldus toetub raamlepingu kodukorrale (lisa 5) ja töökorralduslikele kokkulepetele. Täitja peab tagama piisava kaasamise ja ülevaadete andmise Tellijale. 5.4. Tööde üleandmine Arendustööde lähtekoodi tarne toimub pideva integreerimise (continuous integration) teel. Tööde järjekord, üleandmise aeg ja UAT tagasiside andmise aeg lepitakse kokku tööde käigus taasesitamist võimaldavas vormis (tellija ja täitja poolt). Töö üleandmisel kontrollib tellija üle töö nõuetekohasuse ning annab vajadusel tähtaja töö parandamiseks. Täitja teab, et tellija võib igat üle antud funktsionaalsust paigaldada toodangusse ning täitja peab tagama, et lõplikult valmimata funktsiooni protsessid on võimalik toodangust välja lülitada (feature flags). Funktsioonide sisse-välja lülitamise võimekus lepitakse tellija ja täitja vahel kokku tööde käigus. 5.5. Nõuded automaattestimisele Automaattestimise nõuete täitmisel tuleb lähtuda nõuetest, mis on leitavad siit: Automaattestide nõuded. Testidega kaetakse serveripoolne ja kasutajaliidese kood. Kaetavuse kontrolliks ja raporteerimiseks seatakse tellija koodihoidla keskkonnas (Gitlab) üles pideva integratsiooni töövoog, mis seadistatakse koostoimima SonarQube koodi ja testide kaetavuse analüsaatoriga. Automaattestid peavad üle antavas lähtekoodis continuous-integration’i töövoo edukalt läbima. Samuti peab täitja hoolt kandma, et varasemalt loodud testid jäävad töö lõpetamisel edukalt läbitavaks. Nõuete muutumisel peab täitja viima testid vastavusse uute nõuetega või neid eemaldama, kui selliseid nõudeid enam ei eksisteeri. POC-teenuse PostgreSQL-versioon peab edukalt läbima ka olemasolevad süsteemiülesed regressiooni- ja suitsutestid, tõendamaks, et andmebaasi vahetus ei ole rikkunud teenuse väliseid API-lepinguid. 5.6. Koormustestimised Iseteenindus peab toetama paralleelset minimaalselt 200 päringut (siinkohal on oodatav arendajapoolne hinnang, kas see on piisav päringute maht, vajadusel tõsta arvu). API teenustele ning keskmine päringu teenindamise aeg ei tohi olla suurem kui 2 sekundit. Nõude täitmise kontrolliks tuleb luua koormustestid. Koormustestide tegemine lepitakse tellija ja täitja poolt kokku tööde käigus. Nõudest eraldi tuleb vaadelda staatiliste failide allalaadimist – need tuleb http serveris puhverdada. 5.7. Mittefunktsionaalsed nõuded Mittefunktsionaalsete nõuete täitmisel tuleb lähtuda järgnevast:  Uue funktsionaalsuse loomisel tuleb lähtuda raamlepingu (nr 3-9/3443-1) ja selle lisades kirjeldatud nõuetest  Täpsemad mittefunktsionaalsed nõuded, millest lähtuda on leitavad siit: Mittefunktsionaalsed nõuded 5.8. Tulemid Valminud ja üleantavate tööde tulemid peavad sisaldama:  Eelanalüüsi peatüki 4.1 otsustest lähtuvaid ADR-e;  POC-ide käigus tuvastatud täiendavate otsustuskohtade kaardistust;  Kolme POC-teenuse Liquibase changeseti ja PostgreSQL-versioonide tootmiskvaliteediga lähtekoodi (toimivad dual-database mustris);  Taaskasutatavat migratsioonitestimise ja andmemigratsiooni baasraamistikku;  Töömahu kalibratsioonidokumenti ja tagastusringi protokolli koos edasimineku või peatamise otsusega;  Viiteid dokumentatsioonile Confluence’is;  Viiteid tehtud töödele (Jira piletitena);  Viiteid koodile GitLabis. 5.9. Tööde teostamise tähtaeg Tööde üleandmise (so Jira piletid "Ready for AT" ja toodangu keskkonda paigaldatav kvaliteetne lähtekood) tähtaeg on 18.12.2026, millele järgneb tootejärgne tugiperiood kuni 31.03.2027. Tööde üleandmisele järgneb tellija poolne tööde testimine mõistliku aja jooksul ja vajadusel täitja poolne paranduste või täienduste tegemine, kui tööd ei ole tähtajaks teostatud nõuetekohaselt või tellijal tekib vajadus väiksemamahuliste täienduste koheseks realiseerimiseks. Tööd loetakse teostatuks tööde üleandmise-vastuvõtmise akti tellija poolt allkirjastamise hetkest. Tellijal on õigus pikendada tööde üleandmise tähtaega, kui ilmneb tööde ajakavas täitjast sõltumatuid olulisi viivitusi. Hankeleping nr ... Tervise ja Heaolu Infosüsteemide Keskus (edaspidi tellija), registrikood 70009770, aadress Pärnu mnt 132, 11317 Tallinn, keda esindab põhimääruse alusel direktor Margus Arm ja Nortal AS (edaspidi täitja), registrikood 10391131, aadress Lõõtsa tn 6, 11415 Tallinn, keda esindab volikirja alusel ärijuht Olga Golubeva, edaspidi eraldi pool või koos pooled, sõlmisid raamlepingu nr 3-9/3443-1 alusel käesoleva hankelepingu (edaspidi leping) alljärgnevas: 1. Lepingu ese 1.1. Lepingu esemeks on riigihanke „GAP 1.9 andmebaasi arhitektuur“ dokumentides olevas tehnilises kirjelduses nimetatud tööd (edaspidi tööd). 1.2. Lepingu tööde maht on kuni 300 000 (kolmsada tuhat) eurot ilma käibemaksuta. 2. Töö üleandmise ja vastuvõtmise tingimused 2.1. Täitja annab töö üle hiljemalt 18.12.2026, millele järgneb tootejärgne tugiperiood kuni 31.03.2027. 2.2. Töötunni põhise lepingu korral esitab täitja eelmise kuu töötundide ajaaruande, mis sisaldab teostatud töötunde ja nende jooksul teostatud töid. Ajaaruanne esitatakse allkirjastatult hiljemalt järgmise kalendrikuu 5. tööpäeval. Viimane ajaaruanne esitatakse koos aktiga. 2.3. Tellitavad tööd antakse vastuvõtutestimiseks üle vastavalt lepingu tehnilises kirjelduses kokkulepitud tingimustele. 2.4. Tellija vaatab töö üle vastavalt raamlepingu tingimustele. 2.5. Koos üle antava tööga annab täitja tellijale üle kõik tööde intellektuaalse omandi õigused vastavalt raamlepingus kirjeldatule. 3. Lepingu hind 3.1. Lepingu täitmine toimub töötunnipõhisel arvestusel, tellija tasub üksnes lepingu alusel tellitud ja teostatud töötundide eest. 3.2. Ühe töötunni maksumuseks lepingu täitmisel on ... ( ) eurot käibemaksuta. 3.1. Täitja esitab tellijale e-arve pärast töö üleandmise-vastuvõtmise akti allkirjastamist. 4. Poolte vahelised teated ja kontaktisikud 4.1. Teadete edastamisel ja kätte toimetamisel lähtutakse raamlepingu regulatsioonist. 4.2. Tellija kontaktisikuks lepingu täitmisel on Ott Mihailov, tel 5257813, e-post [email protected] või tema asendaja. 4.3. Täitja kontaktisikuks lepingu täitmisel on Tormis Lilleväli, tel 56615767, e-post [email protected] või tema asendaja. 5. Lõppsätted 5.1. Leping jõustub sellele poolte poolt allakirjutamise hetkest ja kehtib kuni poolte poolt oma lepinguliste kohustuste täitmiseni. 5.2. Lepingu dokumendid koosnevad riigihanke alusdokumentidest, sh lepingu lisadest, lepingu muudatustest ja pakkumusest. 5.3. Lepingu lahutamatuteks osadeks lepingu sõlmimise hetkel on järgmised dokumendid, mida ei allkirjastata koos lepinguga: 5.3.1. Lisa 1 - Tehniline kirjeldus; 5.3.2. Lisa 2 – Pakkumus (ei allkirjastata koos lepinguga) 6. Poolte allkirjad Tellija: Täitja: HANKIJA NIMI: Tervise ja Heaolu Infosüsteemide Keskus Pakkumusettepaneku nimetus: „GAP 1.9 andmebaasi arhitektuur“ Käesolevaga teeb Tervise ja Heaolu Infosüsteemide Keskus (Hankija) Teile ettepaneku esitada pakkumus „GAP 1.9 andmebaasi arhitektuur“ teostamiseks raamlepingu nr 3-9/3443-1 alusel. Pakkumuse esitamise tähtaeg on 18.06.2026 kell 12:00. Pakkumus saata e-posti aadressile [email protected] ja [email protected]. Pakkumus tuleb esitada eesti keeles ja digitaalselt allkirjastatuna. Pakkumus esitatakse Hankelepingu eseme tehnilises kirjelduses (lisa 1) toodud tööde teostamiseks. Alternatiivsete pakkumuste esitamine ei ole lubatav. Pakkumus peab olema jõus minimaalselt 30 päeva. Pakkumusena tuleb esitada: - Tööde teostamiseks planeeritud meeskonnaliikmed isikuliselt, tuues välja ka meeskonnaliikmete roll; - Tööde teostamise ühe töötunni hind (ilma käibemaksuta). Töid teostatakse jooksva tunnihinna arvestuse põhiselt. Tööde ajaaruandes tuuakse välja tööde teostamiseks kulunud töötunnid isikute lõikes, seostades nimetatud isikud Jiras logitud tööülesannete ja kirjeldatud tegevustega. Töid tellitakse mahus kuni 300 000 eurot (ilma km-ta). Pakkumuse esitamisega kinnitab pakkuja, et lepingu tähtaja saabumiseks on teostatud Hankelepingu eseme tehnilises kirjelduse (lisas 1) punktis 4 kirjeldatud tööd. Pakkujal ei ole õigust tööde teostamiseks nõuda ajapikendust, täiendavat tasu või väljamakseid. Küsimuste tekkimise korral palun võtke ühendust enne pakkumuse esitamise tähtaega aadressil [email protected] ja [email protected]. Pakkumusettepanekuga koos edastatavad dokumendid: Lisa 1. Hankelepingu eseme tehniline kirjeldus; Lisa 2. Hankelepingu projekt.
Allikas: Tervise- ja heaolu infosüsteemide keskus dokumendiregister →
dokumendiregister.eeAsutusedEesti avalike dokumendiregistrite otsing · nimistu.ee andmetel