Hankeleping nr 3-9/4512-6
Lepingu osa viitenumber 273311 001 003 000
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
Industry62 OÜ (edaspidi täitja), registrikood 11124544, aadress Harju maakond, Tallinn, Põhja-
Tallinna linnaosa, Toompuiestee 35, 10149, keda esindab põhikirja alusel juhatuse liige Andrus Altrov,
edaspidi eraldi pool või koos pooled, sõlmisid raamlepingu nr 3-9/4512-1 alusel käesoleva
hankelepingu (edaspidi leping) alljärgnevas:
1. Lepingu ese
1.1. Lepingu esemeks on riigihanke „Andmeladude ja tööriistade arendus- ja hooldustööd“
alusdokumentides (minikonkursi viitenumber 306284) olevas tehnilises kirjelduses nimetatud
tööd (edaspidi tööd).
1.2. Lepingu tööde maht on kuni 35 000 EUR käibemaksuta maksimaalse mahuna.
2. Töö üleandmise ja vastuvõtmise tingimused
2.1. Täitja annab töö üle igakuiselt alates lepingu sõlmimisest.
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.
2.6. Töö teostamise tähtaeg on 12 kuud alates lepingu sõlmimisest. Leping jõustub sõlmimise
hetkel ja kehtib kuni 13 kuud või kuni poolte poolt oma kohustuste täitmiseni.
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 53,50 (viiskümmend kolm eurot ja 50 senti)
eurot käibemaksuta.
3.3. Täitja esitab tellijale e-arve igakuiselt. Arvel tuleb märkida riigihanke nimetus, lepingu osa
viitenumber, lepingu number ja kontaktisiku andmed.
3. Poolte vahelised teated ja kontaktisikud
3.1. Teadete edastamisel ja kätte toimetamisel lähtutakse raamlepingu regulatsioonist.
3.2. Tellija kontaktisikuks lepingu täitmisel on Sten Martmaa, tel 5333 8534, e-post
[email protected] või tema asendaja.
3.3. Täitja kontaktisikuks lepingu täitmisel on Triin Hommuk, tel 5217166, e-post
[email protected] või tema asendaja.
4. Lõppsätted
4.1. Leping jõustub sellele poolte poolt allakirjutamise hetkest ja lõppeb poolte poolt oma
lepinguliste kohustuste täitmisega.
4.2. Lepingu dokumendid koosnevad riigihanke alusdokumentidest, sh lepingu lisadest, lepingu
muudatustest ja pakkumusest.
4.3. Lepingu lahutamatuteks osadeks lepingu sõlmimise hetkel on järgmised dokumendid:
4.3.1. Lisa 1 - Tehniline kirjeldus koos lisadega nr 1.1-1.4
4.3.2.Lisa 2 – Kodukord
4.3.3. Lisa 3 – Isikuandmete töötlemise tingimused
4.3.4.Lisa 4 – Pakkumus (ei allkirjastata koos lepinguga)
5. Poolte allkirjad
Tellija: Täitja:
Lisa 1 - Tehniline kirjeldus
Andmeladude ja tööriistade arendus- ja hooldustööd
1. Mõisted ja lühendid
See peatükk loob ülevaate käesolevas hankedokumentatsioonis ja tööde käigus enim kasutusel
olevatest mõistetest ja lühenditest ning selgitab nende tähendused.
TEHIK Tervise ja Heaolu Infosüsteemide Keskus
Andmeladu / Andmeait Andmeladu on struktureeritud kogum
integreeritud, kindlale teemale suunatud,
püsiva loomuga ja ajast sõltuvaid andmeid,
mille ülesandeks on toetada otsuste tegemist.
ODS kiht Andmelaos olev kiht (schema, dbspace või muu
andmelao platvormist tulenev objekt), kuhu
kantakse alliksüsteemist andmed sellisel kujul
nagu need alliksüsteemis on.
EDW kiht Andmelaos olev kiht (schema, dbspace või muu
andmelao platvormist tulenev objekt), mis
luuakse vajadusel integratsiooni,
andmemudeldamise ja transformatsiooni
jaoks.
DWH kiht Andmealaos olev presentatsooni kiht (schema,
dbspace või muu andmelao platvormist tulenev
objekt) kuhu luuakse analüütikute töö aluseks
olevad tabelid inimkeelsete nimedega ja
arusaadavate seostega.
Andmed võetakse ODS kihist või EDW kihist
(vastavalt alusandmestikele) ja viiakse
optimaalsele kujule aruannete kokkupaneku
lihtsustamiseks ja päringute kiiruste
optimeerimiseks .
Analüütikakeskkond / analüütikarakendus Analüütikakeskkond on presentatsiooni kihil
töötav visuaalsete aruannete loomise
rakendus, mis toetab äriliste otsuste tegemist
ning mille sisendiks on andmelaos ja muudes
andmeallikates olevad andmed.
Andmete esitlus on visuaalne ja/või
masinloetav.
Tarkvara Tarkvara tähistab baastarkvara või
tarkvaraplatvormi (näiteks Pentaho, Apache
Hop, Vertica, Tableau jms andmeladudega
seotud tarkvara).
Töödekuhi Töödekuhi ehk backlog on tööde / vigade
halduskeskkonnas olev nimekiri töökäskudest.
Tööde / Vigade halduskeskkond Tööde ja vigade halduskeskkond on tellija
keskkonnas asuv rakendus vigade ja arenduste
haldamiseks kasutusel olev programm (nt. Jira).
Dokumentide halduskeskkond Dokumentide halduskeskkond on tellija
keskkonnas asuv rakendus dokumentide ja
informatsiooni (nt. spetsifikatsioonid, juhendid,
koosolekute memod) haldamiseks kasutusel
olev programm (nt. Confluence).
Reageerimisaeg Reageerimisaeg on aeg, mis on täitjal tellija
päringule vastamiseks.
Teenindusaeg / tööaeg
Teenindusaeg ehk tööaeg on vastavalt
arendustööde tingimustele SLA (arendustööde
tingimused / rakenduste teenustasemed)
tabelis sätestatud teenindusaegadele.
Muu aeg on tööväline aeg.
Lahendusaeg Lahendusaeg tähendab perioodi tellimuse
saamisest kuni tööde valmimiseni, mille jooksul
täitja on kohustatud teostama kõik tööd (sh.
arendustöö, jooksva arendustöö, veaparanduse
ning täitma garantiist tulevad kohustused)
vastavalt lahendusaja tabelile ja SLA
(arendustööde tingimused / rakenduste
teenustasemed) tabelile.
Tarne Tarne on hankelepingu alusel teostatud tööde
paketina üleandmine, mis on toodangusse
paigaldamiseks korrektselt konfigureeritud ja
koodihalduskeskkonda lisatud. Täitja lisab
tarne kirjelduse ja spetsifikatsiooni
dokumendihalduskeskkonda. Täitja esitab
tarne kohta tarneteatise, lisades tarnega
seotud testimise juhendi ja vastavalt
hankelepingule automaattestid. Tarneteatise
vormi kehtestab tellija hankelepingu täitmise
käigus.
Paigalduslogi Paigalduslogi on informatsioon rakenduste
igasuguste muudatuste (nt. tarnete
paigaldamise) kohta kirjalikku taas-esitamist
võimaldavas vormis.
RL Raamleping
TK Tehniline kirjeldus
2. Üldine
2.1. Hanke eesmärk on sõlmida hankeleping pakkujaga, kes hakkab teostama TEHIK-u
andmelaoplatvormil paiknevate andmeladude ja nendega seotud rakenduste ja
tööriistade arendus- ja hooldustöid, mis laiendaksid rakenduse funktsionaalsust ning
tagaksid turvalisuse, tehnilise optimeerituse, töökindluse ja edasise haldus- ning
edasiarendussuutlikkuse.
2.2. Tööde skoop sisaldab nii jooksvaid arendustöid (sõltuvalt vajadusest), analüüsi,
dokumenteerimist (sh. olemasoleva dokumentatsiooni täiendamist ja/või uue
dokumentatsiooni loomist) kui konsultatsiooni. Lisaks on tööde skoobis ka hooldustööd,
mida teostatakse jooksvalt vastavalt vajadusele, kui neid peaks tarvis minema.
3. Hanke eseme tutvustus
3.1. Hanke esemeks on TEHIK-u andmelaoplatvormil (Vertica) paiknevad andmelaod ja
skeemid ning nendega seotud rakenduste ja tööriistade (nt laadimisrakendused,
analüütikarakendused, jne ...) arendus- ja hooldustööd.
3.2. Tavapärasteks tööülesanneteks on andmeladudega seotud keskkondades tekkivate
veaolukordade analüüsimine ja parandamine ning arendusvajaduste realiseerimine nt
uute laadimiste loomine ja olemasolevate laadimiste muutmine ja konfigureerimine sh
ka võimalikud migratsioonid erinevate süsteemide vahel, mille eesmärgiks on äritellija
analüütika/aruandluse vajaduste rahuldamine.
3.3. Tööde teostamisel peab arvestama, et:
3.3.1. Hanke skoopi ei kuulu eraldiseisvad Java põhised rakendused nagu VERX ja
Pseudonüümija.
3.3.2. Hanke skoopi ei kuulu SAP (Sybase) IQ andmelaoplatvormi arendus- ega
hooldustööd. Võimalikud tööd, mis loovad väärtust Vertica
andmelaoplatvormile ja mis omavad tööde teostamiseks eelduslikku seost SAP
(Sybase) IQ platvormiga, või kasutavad seda andmeallikana, võivad olla tööde
skoobis.
3.3.3. Konkreetseid ladusid ja andmeskeeme, tekib aja jooksul Vertica platvormile
juurde ja nendega seonduvad arendusvajadused kuuluvad sellisel juhul
käesoleva hankelepingu tööde skoopi.
3.3.4. Mõningatele Vertica platvormil olevatele andmeladudele võidakse sõlmida, või
on varasemalt olemas, eraldi hankelepingud, mille alt arendus- ja hooldustöid
teostatakse ning sellisel puhul ei pruugi kõik antud platvormiga seotud
arendusvajadused olla lahendatavad käesoleva hankelepingu tööde raames.
3.3.5. Kõik loodud töövood, konfiguratsioonid, mudelid ja muud arenduse tulemid
peavad olema dokumenteeritud.
3.4. Konkreetsed funktsionaalsed nõuded täpsustatakse arendustööde käigus loodavates
piletites.
3.5. Vertica andmelaoplatvormil olevate andmeskeemide toimimiseks on vaja, et süsteemile
oleks tugi. Tegeleda tuleb jooksvate vajaduspõhiste arendustöödega. Vaja on partnerit,
kes teostab rakenduste arendustööd ning tagab jooksvate arendustöödega nende
toimimise, et rakendused ei oleks ilma toeta.
3.6. Potentsiaalsed tööd hõlmavad järgnevaid täna teadaolevaid andmelao skeeme, kuid
lisaks ka neid, mis aja jooksul lisanduda võivad:
3.6.1. SKAIS (Sotsiaalkindlustusameti infosüsteemid)
3.6.2. EESSI (Sotsiaalkindlustusandmete vahetamise infosüsteem)
3.6.3. TEIS ja ITI (Tööinspektsiooni infosüsteem)
3.6.4. Jira (Jira andmeladu)
3.6.5. Ravimiameti andmelao skeemid
3.6.6. MEDRE (Tervisehoiukorralduse infosüsteem)
3.6.7. MedSITREP (COVID-19 patsientide ja haigla ressursside andmete edastamise
rakendus)
3.6.8. MEIS (Terviseameti menetlussüsteem)
3.6.9. MTK (Mürgitusteabekeskus)
3.6.10. NAKIS (Nakkushaiguste infosüsteem)
3.6.11. RA, RAR ja RKAB (Ravimiameti registrid)
3.6.12. STAR (Sotsiaalkindlustusameti infosüsteem)
3.6.13. STEEL (Tervisekassa andmeladu)
3.6.14. TUTE (Tubakateavituse infosüsteem)
3.6.15. VSR (Vähi sõeluuringute register)
3.6.16. TIS (Tervise Infosüsteem)
3.6.17. Log (Logi skeem)
3.6.18. ... (..)
3.7. Arhitektuurijoonis:
(Joonis kirjeldab andmete arhitektuuri läbi terviseandmete ökosüsteemi näite)
3.8. Põhilised märksõnad kasutusel olevate tehnoloogiate ja teekide osas on Vertica; DBT;
CI/CD; Apache Hop; Pentaho; Python; Tableau; Oracle; Postgre; SAP HANA; MS SQL;
SQL server.
4. Töö tehnilised nõuded
4.1. Rakenduste tehniline kirjeldus ja nõuded on dokumenteeritud käesolevas dokumendis ja
selle lisades.
4.2. Tööd teostatakse arvestades tellija poolt esitatud dokumenteerimise nõudeid „TEHIK
nõuded infosüsteemi dokumentatsioonile“ ja täiendavaid materjale asukohaga
https://www.tehik.ee/arendusjuhendid (vt. ka „Tööde piirangud“).
5. Tööde teostamine
5.1. Töödeks on arendus- ja veaparandus/hooldustööd, mille hulka kuuluvad raamlepingus
käsitletud tehnoloogiad ja tööd:
5.1.1. analüüsitööd;
5.1.2. arhitektuuritööd;
5.1.3. arendusressurss (Bodylease);
5.1.4. programmeerimistööd;
5.1.5. testimistööd (end-to-end automaatestimine);
5.1.6. juurutustööd;
5.1.7. koolitused;
5.1.8. konsultatsioon;
5.1.9. dokumentatsiooni koostamine;
5.1.10. jooksvate muudatusvajaduste realiseerimine;
5.1.11. veaparandustööd;
5.1.12. hooldustööd;
5.1.13. Dev-ops CI/CD.
5.2. Teenustasemete osas lähtutakse raamlepingu teenustasemetest (SLA) (RL TK punkt 6).
5.2.1. Maksimaalsed reageerimis- ja lahendusajad, mille jooksul peavad
infosüsteemi, tarkvara või rakenduse vead saama hoolduse käigus lahendatud
on toodud raamlepingu tehnilises kirjelduses (RL TK punkt 6.1).
5.3. Tehnilises kirjelduses ja selle lisades kirjeldatud tulemite ära toomiseks teostatakse tööd
tellija poolt sätestatud prioriteetidest lähtuvalt.
5.4. Töö teostamise tähtaeg on 12 kuud alates hankelepingu sõlmimisest. Lepingu
kehtivusaeg on 13 kuud.
5.5. Tööde teostamiseks kasutatakse SCRUM arendusmetoodikat. SCRUMi tseremooniad ja
nende sagedus lepitakse kokku avakoosolekul.
5.6. Nii arendustööde kui ka hooldus- ja veaparandustööde tellimise, teostamise ja
vastuvõtmise täpsem protsess koos nõuetega on kirjeldatud raamlepingu tehnilises
kirjelduses (RL TK punkt 5) kui ka projekti kodukorras.
5.7. Käesolevaks tööks peab pakkuja esitama meeskonna, mis koosneb minimaalselt
järgnevatest rollidest:
5.7.1. Projektijuht
5.7.2. Analüütik
5.7.3. Arhitekt/vanemarendaja
5.7.4. Arendaja
5.8. Kõik raamlepingus esitatud meeskonnaliikmed tuleb esitada hankega kaasas oleva
meeskonna vormil või uue meeskonnaliikme lisamise korral lisaks ka raamlepingu (RL)
meeskonna vormil.
5.8.1. Uue meeskonnaliikme lisamiseks tuleb täita RL meeskonna vormis plokis 2
individuaalse kogemuse andmed: "2. Individuaalsed nõuded kogu pakkuja
meeskonnale (nõuded tuleb täita iga esitatud meeskonna liikme poolt
individuaalselt)"
5.8.2. Uus meeskonnaliige peab omama vähemalt ühte kompetentsi/kogemust
ühiste nõuete plokist ja see tuleb tõendada RL meeskonna vormis vastavas
plokis andmed täites: "3. Ühised nõuded kogu pakkuja meeskonnale (nõuded
tuleb täita esitatud meeskonna peale kokku)".
5.9. Pakkuja peab esitama lepingu sõlmimiseks isikuliselt vähemalt 4 meeskonnaliiget
eelnevalt defineeritud rollidesse.
5.9.1. Rolle ei ole lubatud katta (st sama isik, ei tohi olla esitatud mitmes erinevas
rollis).
5.9.2. Samasse rolli (näiteks mitme arendaja puhul) ei saa määrata sama isikut.
5.9.3. Hankelepingu kehtivuse perioodil võib vastavalt vajadusele tellijaga eelnevalt
kooskõlastades RL punkt 5.2 alusel meeskonda uusi täiendavaid nõuetele
vastavaid liikmeid juurde lisada käesolevas tehnilises kirjelduses punktis 5.8
kirjeldatud viisil.
5.10. Pakkuja peab tagama, et pakutud meeskonna koosseis on tööde teostamiseks tellija
jaoks kogu hanke perioodil täis töömahus olemas.
5.10.1. Hankijal ei ole kohustust tagada täismahus kõigi meeskonnaliikmete hõivatust,
kuid pakkujal peab olema valmidus pakkuda eelpool kirjeldatud mahus
meeskonda kogu hanke perioodil tellitavate tööde teostamiseks.
5.11. Projekti eelduslik töömaht kokku on ~ 560 tundi.
5.12. Projekti eelduslikud töömahud rollide lõikes:
5.12.1. Projektijuht: ca 80 h.
5.12.2. Analüütik: ca 200 h.
5.12.3. Arhitekt/vanemarendaja: ca 80 h
5.12.4. Arendaja: ca 200 h.
5.13. Kõik eelduslikud töömahud on hankija eelduslikud arvutused muuhulgas hanke
eeldatava maksumuse määramiseks.
5.13.1. Märgitud töömahud ei ole hankes siduvad.
5.13.2. Hankijal ei ole kohustust nimetatud töömahtude väljaostmiseks.
5.13.3. Eelduslike töömahtude puhul arvestatakse kogumahtu ning reaalne mahtude
jaotumine rollide lõikes selgub tööde käigus.
5.14. Tellija tagab tööde teostamiseks ligipääsu vajalikele keskkondadele ja vajadusel
omapoolse abi. Ligipääsu tehnilised tingimused jms täpsustatakse tööde teostamise
käigus.
5.15. Hankelepingu täitmise tulemina peab pakkuja andma tellijale üle:
5.15.1. Tööde jooksul tekkivate tellimuste alusel teostatud tööd vastavalt tellimuses,
käesolevas tehnilises kirjelduses ja selle lisades toodud skoobile.
5.15.2. Teostatud tööde dokumentatsioon (sh kasutusjuhend).
6. Tööde aruandlus, testimine ja vastuvõtmine
6.1. Tingimused tööde aruandlusele, tööde testimise ja vastuvõtmise protsess, on kirjeldatud
raamlepingus (RL punkt 7) ja projekti kodukorras.
7. Garantii
7.1. Kõigile lepingu alusel teostatud töödele rakendub garantii.
7.2. Garantiitingimused on kirjeldatud raamlepingus (RL punkt 10).
8. Tööde piirangud
8.1. Kõigi uute loodavate lahenduste puhul tuleb kasutada tehnoloogiaid, mis on kirjeldatud
tellija IT profiilis.
8.2. Tarkvara arenduse käigus tuleb lähtuda suunistest mis on kättesaadaval aadressil
https://tehik.ee/arendusjuhendid.
8.2.1. Automaattestide nõuded
8.2.2. Allkirjastamise teenused SiGa ja SiVa
8.2.3. IT-profiil
8.2.4. Mittefunktsionaalsed nõuded
8.3. Õigusruumi võimalikud piirangud võivad täpsustuda tööde käigus ja täitja peab sellega
tööde teostamise puhul arvestama. Neid piiranguid enne tööde algust täpselt öelda ei
ole võimalik. Õigusruum ei luba valimatult kõike, mis tehniliselt mugav ja need piirangud
võivad täpsustuda kogu hanke perioodil.
8.4. Sõlmitavates hankelepingutes on tellijal ja täitjal õigus kokku leppida täiendavaid
tehnilisi vahendeid (näiteks väliste andmefailide laadimiseks, andmete
presenteerimiseks).
8.5. Nii toodangueelsed kui toodangukeskkonnad asuvad tellija juures. Plaanitavad uued
komponendid nendes keskkondades peab looma täitja, seejuures eeldab tellija, et kui ei
ole spetsifitseeritud teisiti, peab pakkuja eeldama, et tema vastutab projektides
järgnevate tegevuste eest:
8.5.1. mikroteenuste loomine vastavalt tellija poolt esitatud arhitektuuriplaanile;
8.5.2. täies mahus CI/CD töövoogude koostamine;
8.5.3. rakenduste paigaldus tellija DEV keskkonda läbi loodud CI/CD töövoo ning
testkeskkonda koos tellija poolse süsteemiadministraatoriga;
8.5.4. regulaarsete koodiläbivaatuste läbiviimine meeskonna siseselt;
8.5.5. automaatsete testide koostamine vastavalt TEHIKu automaattestide
koostamise juhendile;
8.5.6. peakasutaja(te) koolitamine;
8.5.7. dokumentatsiooni koostamine;
8.5.8. mittefunktsionaalse monitooringu loomine rakendustele;
8.5.9. funktsionaalse monitooringu loomine rakendustele vastavalt kokkuleppele
tellijaga.
8.6. Tarkvara arenduse puhul tuleb eelistada konteiner lahendusi. Esimene eelistus Apache
Hop. Kõik muud alternatiivsed variandid tuleb eelnevalt kooskõlastada TEHIK-u
arhitektiga.
8.7. Tarkvara arenduse käigus võib kasutada ainult tellija repositooriumis olevaid teeke. Juhul
kui on vajadus kasutada mõnda avalikku või mingit muud teeki siis see tuleb see enne
kooskõlastada tellija arhitektiga.
8.8. Kõik kõrvalekalded eelnevast tuleb kooskõlastada tellija arhitektiga.
8.9. Tellija eeldus on, et täitja ei pea enese juures looma ei eraldi arenduskeskkonda ega
keskkondi tööde, dokumentatsiooni ega koodi haldamiseks ja säilitamiseks. Juhul kui
täitja peab vajalikuks luua mõne komponendi jaoks enese juures arenduskeskkonda,
luuakse see täitja kuludega, sh võimalikud täiendavad litsentsitasud.
8.10. Arendustööde läbiviimiseks on vajalik ligipääs olemasolevate ning loodavate
andmeladude toodangueelsetele keskkondadele.
8.11. Andmeladude keskkonnad hõlmavad ladude baase, andmelaadimise funktsioone,
andmeparandusfunktsioone ning aruandluskeskkondi.
8.12. Lähtekoodi ja skriptide tarnimiseks ning töövoogude koostamiseks on kasutusel GitLab.
8.13. Sõltuvuste repositoorium on vaikimisi tellija Artifactory.
8.14. Kubernetese halduseks on kasutusel Rancher.
8.15. Dokumentatsioon ja juhendid tarnitakse tellija Confluence keskkonda
https://wiki.sm.ee.
8.15.1. Tarkvara käivitamise ja kasutamise juhendid peavad lisaks olema ka GIT-is
koodi juures markdown formaadis.
8.16. Tööde halduseks on kasutusel JIRA keskkond https://smjira.sm.ee.
8.17. Aja logimiseks kasutatakse Tempo.
8.18. Aktsepteeritud suhtluskanaliteks on tellija MS Teams, Rocket.Chat, tellija
Jira/Confluence ja e-mail.
8.19. Enamuse rakenduste ja keskkondade ligipääs on arendajale võimalik ainult VPN tunneli
kaudu. IP põhiseid ligipääse vaikimisi ei looda. VPN tunneli kasutamiseks on vajalik Eesti
ID kaart või Digi-ID.
9. Lisad
9.1. Lisa 1.1 - TEHIK mittefunktsionaalsed nõuded arendustele 19082025
9.2. Lisa 1.2 - Andmeladude olemus ja funktsioon juhis 14042023
9.3. Lisa 1.3 - IT-Profiil v3 veebidoc
9.4. Lisa 1.4 - SKANDL-220126-1743-1550
Lisa 2 – Kodukord
1. Sissejuhatus
1.1. Kodukorra eesmärk on täpsustada poolte õiguseid ja kohustusi ja tööde teostamise
korraldust.
2. Nõuete haldus
2.1. Antud peatüki eesmärk on kirjeldada kust ja kuidas nõuded tulevad, kuidas nõuded
kaardistatakse, kuidas neid hallatakse, kuidas hallatakse muudatusi, sh kuidas
kinnitatakse muudatused, kuidas ärilised nõuded seotakse süsteeminõuetega ja kuidas
süsteeminõuded seotakse arenduse taskide, testilugude jms-ga.
2.2. Projekti skoopi kuuluvad tööd on kirjeldatud hanke tehnilises kirjelduses ja selle lisades.
Nende tööde teostamise jälgimiseks loob täitja projektijuht võimalikult sarnase
töömahuga piletid projekti tööhalduskeskkonnas. Pileteid võib samadel tingimustel luua
ka tellija. Projektis ei teostata töid, mida pole hanke tehnilises kirjelduses defineeritud (ja
mille kohta ei ole seega tööhalduskeskkonnas piletit).
2.3. Tööde läbivaatamisel võib tellija tuua välja erinevaid muudatusvajadusi, mis
defineeritakse projekti töörühma poolt tööhalduskeskkonna vastavas piletis nõuetena
või uute tööpiletitena.
2.4. Dokumentatsiooni loomisel tuleb lähtuda suunistest mis on kättesaadaval aadressil
https://tehik.ee/arendusjuhendid („Nõuded infosüsteemi dokumentatsioonile“).
3. Kommunikatsiooni haldus
3.1. Tellija projektijuht säilitab kogu projekti vältel toimuva kommunikatsiooni, mida on
võimalik kirjalikult taas esitada, projekti ja garantiiperioodi kehtivuse vältel.
3.2. Projekti kommunikatsiooni vormid on järgmised, kuid neile võib vastavalt vajadusele
kokkuleppeliselt lisanduda ka muid kommunikatsiooni vorme, mida pole alljärgnevas
tabelis kirjeldatud:
Kommunikatsiooni Sagedus Vastutav Reeglid
vorm roll
Igapäevane Jooksvalt Tellija PJ Tööde läbiviimiseks lepib
teabevahetus Täitja PJ töörühm kokku vestluskanali
(Teams vms), millesse kuuluvad
kõik töörühma liikmed.
Projektijuhid tagavad, et kõigil
osalistel oleks kanalisse ligipääs
Vajadusel lepivad poolte
projektijuhid kokku antud
kanalis täiendavate
alamgruppide loomise
konkreetsete teemade
arutamiseks
Poolte projektijuhid vastutavad,
et ebaturvalistes peetavates
vestluskanalites ei edastataks
tundlikke andmeid (n
delikaatsed isikuandmed, tellija
rakenduste turvalisust puudutav
info).
Vestluskanalis tõstatatud
küsimusele tuleb vastata
koheselt või anda vastamise
tähtaeg.
Mõlema poole projektijuhid
jälgivad jooksvalt vestluskanalit
ning viivituste korral korraldavad
vastamise enda poolel
Vestluskanalis langetatud
otsused tuleb eraldi
dokumenteerida
projektidokumentatsioonis või
tööde halduse keskkonnas.
Ad hoc koosolekud Vastavalt Tellija PJ Keerulisematele küsimuste
vajadustele Täitja PJ arutamiseks võivad tellija ja
täitja projektijuht kokku kutsuda
eraldi koosoleku.
Koosolekule võib kutsuda ka
liikmeid väljastpoolt projekti
töörühma.
Koosolekust antakse ette teada
vähemalt 1 tööpäev.
Koosolekusse tuleb märkida
päevakord, eesmärk ning
toimumise koht.
Koosolek võib toimuda nii
kohapeal kui veebi vahendusel.
Koosoleku tulemina koostab
kokku kutsuja memo või
delegeerib selle koostamise
mõnele koosoleku osalejale.
Kui koosoleku osalejad ei suuda
leida vastust, eskaleerib
koosoleku kokku kutsuja
otsustamise projekti töörühma
üldkoosolekule.
Koosolekut võib tühistada
poolte kokkuleppel hiljemalt 2-
tunnise etteteatamise ajaga
Projekti Jooksvalt Tellija PJ Projekti dokumentatsioon
dokumentatsioon Täitja PJ hoitakse tellija Confluence’i
keskkonnas vastavas ruumis.
Tellija PJ vastutab, et kõigil
töörühma liikmetel oleks sinna
ligipääs.
Dokumentatsiooni struktuur
lepitakse kokku projekti
töörühma koosolekul. Igale
dokumendile määratakse tellija
ja täitja jälgija.
Projektijuhid vastutavad, et
dokumendi jälgijad teostaksid
dokumendi kokkulepitud
täiendused ja muudatused ning
et dokumentatsioon püsiks
ajakohane.
Projekti Iganädalaselt Tellija PJ Projekti kõiki tööülesandeid
tööülesanded Täitja PJ hallatakse tellija Jira keskkonna
vastavas projektis. Selles
keskkonnas registreerimata töid
ei teostata ega arveldata.
Tellija PJ vastutab, et kõigil
töörühma liikmetel oleks
tööhalduskeskkonda ligipääs.
Igal teostamisele määratud
ülesandel peab olema täitja
Ülesande täitja vastutab
ülesande täitmise staatuse
ajakohasena hoidmise eest
Ülesanded vaadatakse läbi kord
nädalas ning märgitakse juurde
vastavad tegevused.
Lepingu täitmist Vastavalt Tellija PJ Lepingu täitmist puudutav
puudutav vajadusele Täitja PJ ametlik teabevahetus, mis pole
teabevahetus kaetud muude
kommunikatsioonivormidega (n
tööülesannete ja
projektidokumentatsiooni
haldus) toimub e-kirja teel.
Ametlikud e-kirjad registreerib
tellija projektijuht tellija
dokumendihalduse keskkonnas
Kui e-kirjale oodatakse vastust,
tuleb see pealkirja real või kirja
alguses üheselt määratleda.
Vastust eeldavale e-kirjale tuleb
vastata hiljemalt järgneva
tööpäeva jooksul. Kui see ei ole
võimalik, tuleb järgneva
tööpäeva jooksul anda sisulise
vastamise tähtaeg.
Lepingu üleandmis-vastuvõtu
akt (ÜVA) tuleb tellija poolsele
lepingu kontaktile edastada
meili teel ja digitaalselt
allkirjastatuna. Tellija korraldab
ÜVA registreerimise ja
allkirjastamise
dokumendihaldussüsteemis
ning täitjale meili teel
tagastamise.
Arved lepingu täitmise eest
esitatakse e-arvete keskkonnas.
Erakorraline Vastavalt Tellija PJ Poolte vaheline teabevahetus,
teabevahetus vajadusele Täitja PJ mis pole kaetud eelnevalt
kirjeldatuga, lepitakse kokku
tellija ja täitja PJ poolt vastavalt
olukorrale.
Projektijuhid lepivad kokku,
millises vormis erakorraline
kommunikatsioon edastada ning
kuidas seda edasi käsitleda.
Reeglina on erakorralise
kommunikatsiooni vormiks
ametlik e-kiri, mis
registreeritakse tellija
dokumendihalduse süsteemis.
Kommunikatsioon
kriisiolukorras on kirjeldatud
käesoleva dokumendi punktis 5.
4. Projekti muudatuste haldus
4.1. Projekti muudatuseks nimetatakse vajadust, mida pole varasemalt kokku lepitud
projekti ressurssides, skoobis (sh nõuetes, tulemites, verstapostides, eeldustes,
piirangutes või seostes) või tööplaanis ja mille realiseerimine toob kaasa muudatusi
varasemalt kokku lepitud:
4.1.1. üle antavates tulemites ja/või
4.1.2.ajakavas, projekti eelarves, inimressurssides ja/või
4.1.3. projekti läbiviimise tööprotsessides
4.2. Muudatustaotlused registreerib ja nende menetlemise seisu jälgib tellija projektijuht
projektidokumentatsiooni keskkonnas.
4.3. Registreeritud muudatustaotlused vaatavad poolte projektijuhid koos läbi,
konsulteerides vastavalt vajadusele projekti töörühmaga. Läbivaatuse käigus
märgitakse taotlusse muudatuse mõju projekti tulemitele, ajakavale, eelarvele ning
inimressursside kasutamisele.
4.4. Enne muudatustaotluse esitamist tuleb tagada, et on olemas vajalikud eeldused
muudatuse teostamiseks.
4.5. Juhul, kui muudatus eeldab lisarahastust, hankes nimetamata ressursside kaasamist
projekti või läheb muul viisil vastuollu riigihanke dokumentatsiooni sõnastusega, peab
tellija projektijuht koostama muudatust põhjendava memo ning kooskõlastama selle
tellija dokumendihaldussüsteemis vastavalt kehtivale asjaajamiskorrale.
4.5.1. Muudatus ei tohi tekitada täitjale eelist võrreldes teiste riigihankes kandideerinud
pakkujatega.
4.6. Muudatuse realiseerimisega alustatakse alles peale vajalike kooskõlastuste saamist ning
vajadusel hankelepingu või projekti kodukorra muudatuse allkirjastamist mõlema poole
poolt.
5. Probleemide haldus
5.1. Kriisiolukorraks loetakse olukorda, kus:
5.1.1. poolte esindajad ei suuda kokkuleppele jõuda;
5.1.2. on muutunud võimatuks võtmeisikute osalemine tööde teostamisel;
5.1.3. on ilmnenud muud asjaolud, mis võivad oluliselt mõjutada tööde edukat elluviimist
ja/või satuvad olulisse ohtu kokkulepitud tähtajad ja/või funktsionaalsus.
5.2. Kriisiolukorra tekkimisel on pool kohustatud sellest teise poole esindajat viivitamatult
teavitama e-maili teel. Poole projektijuht helistab lisaks üle teise poole projektijuhi ning
kontrollib meili kättesaamist.
5.3. Kui telefonikõnele pole võimalik vastata, tuleb tagasi helistada esimesel võimalusel, aga
mitte hiljem kui järgmise tööpäeva lõpus.
5.4. Kriisi tekkel informeerib tellija projektijuht koheselt TEHIK-u andmeanalüüsi ja/või
andmeladude talituse juhte, kes rakendavad täiendavad meetmed kriisi lahendamiseks.
5.5. Kriisist väljumiseks teevad mõlemad pooled kõik endast sõltuva mõlemat poolt
rahuldava lahenduse leidmiseks. Kriisi vältimise ja kriisist väljumise tegevuste edenemise
eest vastutavad poolte projektijuhid.
5.6. Kriisisituatsioonis võivad projektijuhid kokku leppida vajalike isikute kättesaadavuse ka
peale tööpäeva lõppu.
5.7. Kui eelnevate meetmete abil ei suudeta kriisist väljuda, kasutatakse täitja ja tellija
vahelises lepingus sätestatud meetmeid.
6. Kvaliteedi tagamine
6.1. Juhtimise kvaliteet tagatakse käesolevas projektis läbi süstemaatilise ja aktiivse
projektijuhtimise, kus regulaarselt jälgitakse kokkulepitud tööplaani ja tööprotsesse ning
muid hanke- ja projektidokumentatsioonis sõnastatud meetodeid, reegleid ja
põhimõtteid.
6.2. Töö teostaja tagab, et projekti üle antavate tulemite kvaliteedi tagamiseks on tulemid
(tarned) eelnevalt testitud vastu esitatud (sh funktsionaalseid ja mittefunktsionaalseid)
nõudeid ning tuvastatud vead on parandatud enne tellijale üleandmist.
7. Tulemite valideerimine ja kinnitamine
7.1. Selliste tulemite nagu aruanded ja dokumentatsioon valideerimiseks vaatab tellija
analüütik tulemid läbi, rakendades neid toodangukeskkonna andmetele ning kinnitab
tulemite vastavust enda ärivajadustele tellija tööhalduskeskkonnas. Tööd ei võeta vastu
enne, kui tellija analüütik või tema esindaja on tööhalduskeskkonnas kinnitanud loodud
tulemi sobivust.
7.2. Laadimise koodi ja infodomeenile vastava andmemudeli vastavust nõuetele kontrollib
tellija andmelao spetsialist (arendaja, arhitekt) versioonihaldus keskkonnas (GIT).
7.3. Andmeparandusalgoritmide valideerimiseks tuleb tagada, et need on tellija keskkonnas
rakendatud, tellija andmelao arendaja on kinnitanud nende sobivust ning tellija analüütik
on kinnitanud, et aruanded, mille andmekoosseisu algoritmid mõjutavad, on
vastuvõetavad.
7.4. Dokumentatsiooni vastavust kehtivatele mittefunktsionaalsetele nõuetele kontrollib
tellija projektijuht, kaasates vastavalt vajadusele täiendavaid spetsialiste.
8. Riskide haldus
8.1. Riskide haldus hõlmab:
8.1.1. riskide tuvastamist, analüüsi ja riskide prioriseerimist,
8.1.2.riskide juhtimistegevuste planeerimist,
8.1.3. riskide juhtimist,
8.1.4.riskide juhtimistulemuse kontrollimist ning otsustamist, kas risk on kontrolli all või vajab
lisategevusi.
8.2. Riskide halduse reeglid ja protsess on järgmine:
8.2.1. täitja projektijuht koos projektimeeskonnaga koostab esialgse riskiplaani
vastavalt alljärgnevale tabelile:
I Valdkon Riski Riski Risk Riski Skoo Riski Vastutaj
D d kirjeldu realiseerumis i realiseerumis r (S) juhtimise a
s e tagajärg mõj e tõenäosus tegevuse
u (TN) d
(M)
8.2.2. Riskiplaan sisaldab järgmist infot:
8.2.2.1. riski _ID;
8.2.2.2. riski valdkond (nt: kliendist tulenevad riskid, finantsidest tulenevad
riskid, ajahinnangutest tulenevad riskid, skoobist tulenevad riskid,
tehnilisest lahendusest tulenevad riskid jne);
8.2.2.3. riski kirjeldus;
8.2.2.4. riski tagajärg;
8.2.2.5. riski mõju;
8.2.2.6. riski realiseerumise tõenäosus (TN);
8.2.2.7. riskikoefitsient/ skoor;
8.2.2.8. riski juhtimise tegevused ja vastutajad.
8.2.3.Riskiplaan arutatakse läbi kõigi seotud osapooltega.
8.2.4. Riskiplaani muudatusi haldab täitja projektijuht, küsides regulaarselt tagasisidet
projekti meeskonnalt ja tellija projektijuhilt.
8.2.5. Riskiplaanis olevad kõrge prioriteediga riskid ja nende juhtimise tegevused,
vastutajad ja seis vaadatakse üle projekti juhtrühmas.
8.2.6. Riskiplaani hoitakse ning hallatakse tellija dokumendihalduskeskkonnas
(Confluence).
8.3. Riskide hindamine
8.3.1. Riskide hindamine hõlmab riskide tuvastamist, analüüsi ning riskikoefitsiendi/skoori
määramist.
8.3.2.Riskide hindamisel osalevad kõik täitja projektimeeskonna liikmed, projektijuhi
ülesanne on tulemused kaardistada ning tagada riskiplaani aja- ja asjakohasus.
8.3.3. Riskide hindamise reeglid on:
8.3.3.1. riski esinemise tõenäosus 3 palli süsteemis (madal - 1, keskmine – 2,
kõrge - 3);
8.3.3.2. riski mõju 3 palli süsteemis (madal - 1, keskmine – 2, kõrge - 3);
8.3.3.3. skoor on riski esinemise tõenäosuse ja mõju korrutis (S = TN x M);
8.3.3.4. prioriteetsed riskid - koefitsiendiga 4-9 - kuuluvad alati ülevaatamisele
projekti juhtrühmas;
8.3.3.5. partneriga seotud riskide hindamisel kaasatakse partneri esindaja/
projektijuht, kes vajadusel kaasab hindamisprotsessi omapoolsed
spetsialistid.
8.4. Riskide kontroll
8.4.1.Riskide kontroll hõlmab riskide juhtimise tulemuste kontrollimist ning otsustamist, kas
on lisandunud uusi riske, kas on muutunud mõne riski skoor, millised on abinõud riskide
edasiseks juhtimiseks.
8.4.2. Konkreetsete tegevuste täitmise eest vastutajad ning tähtajad kannab täitja
projektijuht üldisesse tööplaani. Nimetatud tegevuste täitmist kontrollib ja esitab
ülevaate täitja projektijuht projekti edenemise seisu raportis.
9. Tööprotsessid
9.1. Antud peatüki eesmärk on kirjeldada olulisemad tööprotsessid selleks, et meeskonnal
oleks ühene arusaam, kes, mida, millal ja kuidas teeb. Nt protsess, kuidas toimub mingite
nõuete ja analüüsitulemite ülevaatus ja kinnitamine projekti erinevate osapoolte vahel.
9.2. Projekti alguses toimub avakoosolek (vajadusel mitu) ning luuakse kõigile osapooltele
vajalikud ligipääsud tööde teostamiseks.
9.3. Täitja teostab arendustööd vastavalt hanke tehnilisele kirjeldusele ja selle lisadele.
9.4. Arendustööd teostatakse täitja poolt tellija poolses keskkonnas, millele tellija
organiseerib täitja jaoks vajalikud ligipääsud.
9.5. Tööde tulemid peavad olema täitja poolt testitud ning vastama tehnilises kirjelduses ja
selle lisades seatud ootustele vastavalt hankelepingus ja tehnilises kirjelduses
ettenähtud ajaraamile ning tähtaegadeks.
9.6. Tööde registreerimiseks teavitab tellija täitjat töö vajadusest, esitades töö ettepaneku
tööde / vigade halduskeskkonnas.
9.7. Täitja kirjeldab eelanalüüsi käigus vastavalt tellija poolt esitatud lähteülesandele
tööle tehnilise lahenduskäigu ning annab tööle mahuhinnangu tundides.
9.7.1. Kui tööd ei ole võimalik enne teostamist hinnata, siis arendaja teavitab sellest tellijat.
9.7.2. Tellija kinnitusel võtab täitja sõltuvalt töö skoobist mõistliku mahu (4 kuni 8h) tööga
tutvumiseks ja annab selle kohta teavituse töö piletisse enne tööga alustamist.
9.7.3. Täitja annab tööga tutvumise järgselt tööle seejärel lõpliku hinnangu alles peale
mainitud aja jooksul tööga tutvumist. Kui töö nende tundide jooksul laheneb, siis
täiendavat hinnangut ei teki.
9.8. Tellija kinnitab töö teostamise ja suunab selle töödekuhja pakkujale teostamiseks.
9.8.1.Tellijal on õigus pakutud mahuhinnang tagasi lükata või töö teostamine peatada ning
arendustööd mitte tellida.
9.9. Täitja teostab tööde osas aruandlust.
9.9.1.Täitja peab tööde osas arvestust rollide kaupa ja esitab tööde kohta aruande tööde
üleandmise ja vastuvõtmise aktis sisalduva tabeli kujul.
9.9.2. Täitja esitab tellijale aruande iga kuu kohta, mis sisaldab täitja poolt veaparandus
ja/või tellimuste alusel tehtud tööde (sh garantiiliste tööde) nimekirja (sh. tarneid ja
vastuvõetud töid) ning mahtu (töötunnid).
9.9.3. Täitja esitab aruanded tellijale vähemalt 1 kord kuus.
9.10. Täitja peab salvestama tööde aruandlust (logima töö teostamiseks kulunud aega)
tööde/vigade halduskeskkonnas (Jira) kasutades selleks tellija poolt aktsepteeritud aja
logimise lahendust (TEMPO).
9.10.1. Täitja peab tööde teostamiseks kulunud aega salvestama vastava töö pileti külge
iga päev kui tööd on tehtud.
9.10.1.1. Ei ole aktsepteeritav, et täitja esitab ajaaruanded töö pileti tasemel
suuremas mahus kui 1 päev (8 tundi) viivitusega.
9.10.2. Tööde aruandluse salvestamine tööde/vigade halduskeskkonda on kohustuslik ja on
tööde akteerimise aluseks.
9.11. Täitja annab aruande alusel tööd üle aktiga.
9.11.1. Akteerimisele kuuluvad ainult tööd, mis on hinnatud või muul juhul tellija poolt töösse
kinnitatud ja peale täitja poolset tööde teostamist tellija poolt tööde / vigade
halduskeskkonnas vastu võetud ja/või jõudnud muu resolutsioonini (nt. katkestatud,
tühistatud, ...), kus tellija kinnitab teostatud tööde akteerimise.
9.11.2. Tellijal on õigus töösse eelnevalt kinnitamata täitja poolt raporteeritud töötunde
mitte akteerida.
9.12. Täitja suunab tööga seotud pileti tellijale kui töö on valmis vastuvõtutestimiseks (test)
keskkonnas.
9.12.1. Piletisse tuleb märkida seos nõuetega, vastavalt hanke tehnilisele kirjeldusele ja selle
lisadele, mida see pilet mõjutab.
9.12.2. Piletisse tuleb lühidalt kirjeldada teostatud töö tulem ning võimalusel viidata tehtud
tööle tellija keskkonnas ja/või koodi asukohale koodihalduskeskkonnas.
9.12.3. Piletisse tuleb märkida viide dokumentatsioonile, mida tööde käigus loodi, muudeti
või täiendati.
9.12.4. Kulupõhise arvelduse puhul peab piletis olema tööde teostamiseks kulunud aeg
(TEMPO).
9.13. Suunamise eest järgmisele täitjale vastutab vaikimisi isik, kelle nimel pilet on.
9.13.1. Uute piletite määramise eest täitjale vastutatavad tellija ja täitja projektijuhid.
9.14. Tööde tarnimine täitja keskkondadest tellija keskkondadesse toimub peale täitjaga
kooskõlastamist ning tarnete puhul lähtutakse tellija muudatuste halduse protsessist.
9.15. Tellija testib tulemeid esialgu võimalusel test keskkonnas ja peale tarnet ka toodangu
(live) keskkonnas.
9.15.1. Juhul kui töös esineb vigu, annab tellija omalt poolt tagasisidet täitjale, et täitja saaks
teha vajalikud parandused.
9.16. Tellija kinnitab tulemid, kui need vastavad tehnilises kirjelduses ja selle lisades seatud
ootustele tulemi suhtes toodangu keskkonnas (live) – Definition of Done (DoD).
10. SCRUM protsessid
10.1. Antud peatükki kohaldatakse juhul, kui projektis on kasutusel SCRUM
arendusmetoodika.
10.2. Tellija on tooteomaniku (Product Owner; PO) rollis.
10.3. Täitja on Scrum Master (SM) rollis.
10.4. SCRUM sündmused
10.4.1. Sprint on Scrum-i konteinersündmus.
10.4.2. Sprint sisaldab kõiki vajalikke töid sh:
10.4.2.1. Analüüs
10.4.2.2. Disain
10.4.2.3. Arhitektuur
10.4.2.4. Arendus
10.4.2.5. Testimine
10.4.2.6. Jne.
10.4.3. Sprint kestab 1-4 nädalat (maksimaalselt 1 kuu).
10.4.3.1. Enamasti on kokkuleppeliselt projektis sprindi kestvuseks 1-2 nädalat.
10.4.4. Sprint võimaldab prognoosimist ja riski piirangut – iga sprindi lõpus on mõõdetav
tulemus.
10.4.5. Sprindi võtmesisendid:
10.4.5.1. Toote backlog
10.4.5.2. Tiimi võimekus (velocity; capacity)
10.4.5.3. Valmimiskriteeriumid (DoD – Definition of Done)
10.4.5.4. Viimane töötav tarkvara versioon (increment) ja tagasiside
retrospektiivist.
10.4.6. Sprindi eesmärk on võtmeväljundina luua töötav ja potentsiaalselt lansseeritav
(tootestatav) tarkvara versioon (increment).
10.4.7. Sprindi sündmused:
10.4.7.1. Sprint planning – Sprindi alustamine õige fookusega.
10.4.7.1.1. Eesmärk:
10.4.7.1.1.1. Määrata, millised tööülesanded lähevad toote backlogist
sprindi backlogi.
10.4.7.1.1.2. Koostada plaan, kuidas sprindi jooksul seatud eesmärk
saavutada.
10.4.7.1.2. Kestvus ja regulaarsus:
10.4.7.1.2.1. Kuni 2 h iga nädala kohta (maksimaalselt 8 h 4-nädalase
sprindi kohta).
10.4.7.1.3. Väljund:
10.4.7.1.3.1. Sprint backlog – konkreetne tööplaan kogu sprindi jaoks.
10.4.7.2. Daily Scrum – Igapäevane lühikoosolek sprindi sujuvaks edenemiseks.
10.4.7.2.1. Eesmärk:
10.4.7.2.1.1. Ülevaade viimase 24h progressist sprindi eesmärgi
suhtes.
10.4.7.2.1.2. Vajadusel sprindi backlogi uuendamine.
10.4.7.2.2. Kestvus ja regulaarsus:
10.4.7.2.2.1. Kuni 15 minutit iga päev samal ajal.
10.4.7.2.3. Väljund:
10.4.7.2.3.1. Järgmise 24h plaan.
10.4.7.3. Sprint Review – Iteratiivne tagasiside sessioon.
10.4.7.3.1. Eesmärk:
10.4.7.3.1.1. Vaadata üle sprindi jooksul valminud versioon
(increment).
10.4.7.3.1.2. Vajadusel uuendata toote backlogi lähtuvalt
tagasisidest.
10.4.7.3.2. Kestvus ja regulaarsus:
10.4.7.3.2.1. Iga sprindi lõpus 1 kord kuni 1 h iga nädala kohta
(maksimaalselt 4 h 4-nädalase sprindi kohta).
10.4.7.3.3. Väljund:
10.4.7.3.3.1. Uuendatud toote backlog.
10.4.7.4. Sprint Retrospective – tiimi eneseanalüüs ja parendamine.
10.4.7.4.1. Eesmärk:
10.4.7.4.1.1. Selgitada välja parendused, mida saab rakendada
järgmise sprindi jooksul.
10.4.7.4.2. Kestvus ja regulaarsus:
10.4.7.4.2.1. Kohe pärast Sprint Review-d 1 kord kuni 1 h ia nädala
kohta (maksimaalselt 4 h 4-nädalase sprindi kohta).
10.4.7.4.3. 1-2 planeeritud parendust järgmisesse sprinti.
11. Tööde piirangud
11.1. Tööde teostamisel peab arvestama, et TEHIKu pärandandmelaod laadivad
infosüsteemide PostgreSQL ja Oracle baasidest Pentaho abil SAP IQ andmeladudesse.
Andmeanalüüsi keskkonnana on kasutusel WebFocus, sh veebipõhine töökeskkond
WebFOCUS InfoAssist.
11.2. Kõigi uute loodavate lahenduste puhul tuleb kasutada tehnoloogiaid, mis on kirjeldatud
tellija IT profiilis. IT profiili ning teiste kohalduvate dokumentide viited
(mittefunktsionaalsed nõuded, nõuded andmeladude arendusele, automaattestimisele)
ning nende materjalide kasutamine ja kohaldamine raamlepingu jooksul on täpsemalt
kirjeldatud raamlepingus.
11.3. Sõlmitavates hankelepingutes on tellijal ja täitjal õigus kokku leppida täiendavaid
tehnilisi vahendeid (näiteks väliste andmefailide laadimiseks, andmete
presenteerimiseks).
11.4. Nii toodangueelsed kui toodangukeskkonnad asuvad tellija juures. Plaanitavad uued
komponendid nendes keskkondades peab looma täitja, seejuures eeldab tellija, et kui ei
ole spetsifitseeritud teisiti, peab pakkuja eeldama, et tema vastutab projektides
järgnevate tegevuste eest:
11.4.1. mikroteenuste loomine vastavalt tellija poolt esitatud arhitektuuriplaanile;
11.4.2. täies mahus CI/CD töövoogude koostamine;
11.4.3. rakenduste paigaldus tellija DEV keskkonda läbi loodud CI/CD töövoo ning
testkeskkonda koos tellija poolse süsteemiadministraatoriga;
11.4.4. regulaarsete koodiläbivaatuste läbiviimine meeskonna siseselt;
11.4.5. automaatsete testide koostamine vastavalt TEHIKu automaattestide koostamise
juhendile;
11.4.6. peakasutaja(te) koolitamine;
11.4.7. dokumentatsiooni koostamine;
11.4.8. mittefunktsionaalse monitooringu loomine rakendustele;
11.4.9. funktsionaalse monitooringu loomine rakendustele vastavalt kokkuleppele tellijaga.
11.5. Tarkvara arenduse käigus tuleb lähtuda suunistest, mis on kättesaadaval aadressil
https://tehik.ee/arendusjuhendid.
11.6. Tarkvara arenduse puhul tuleb eelistada konteiner lahendusi. Esimene eelistus Apache
Hop või custom konteiner (tuleb kooskõlastada arhitektiga).
11.7. Tarkvara arenduse käigus võib kasutada ainult tellija repositooriumis olevaid teeke.
Juhul, kui on vajadus kasutada mõnda avalikku või mingit muud teeki, siis see tuleb see
enne kooskõlastada tellija arhitektiga.
11.8. Kõik kõrvalekalded eelnevast tuleb kooskõlastada tellija arhitektiga.
11.9. Tellija eeldus on, et täitja ei pea enese juures looma ei eraldi arenduskeskkonda ega
keskkondi tööde, dokumentatsiooni ega koodi haldamiseks ja säilitamiseks. Juhul, kui
täitja peab vajalikuks luua mõne komponendi jaoks enese juures arenduskeskkonda,
luuakse see täitja kuludega, sh võimalikud täiendavad litsentsitasud.
11.9.1. Arendustööde läbiviimiseks on vajalik ligipääs olemasolevate ning loodavate
andmeladude toodangueelsetele keskkondadele.
11.9.2. Andmeladude keskkonnad hõlmavad ladude baase, andmelaadimise funktsioone,
andmeparandusfunktsioone ning aruandluskeskkondi.
11.9.3. Lähtekoodi ja skriptide tarnimiseks ning töövoogude koostamiseks on kasutusel
GitLab
11.9.4. Sõltuvuste repositoorium on vaikimisi tellija Artifactory.
11.9.5. Kubernetese halduseks on kasutusel Rancher.
11.9.6. Dokumentatsioon ja juhendid tarnitakse tellija Confluence keskkonda
https://wiki.sm.ee.
11.9.7. Tööde halduseks on kasutusel JIRA keskkond https://smjira.sm.ee.
11.9.8. Aja logimiseks on kasutusel Tempo.
11.9.9. Aktsepteeritud suhtluskanaliteks on tellija Rocket.Chat, Microsoft Teams, tellija
Jira/Confluence ja e-mail.
11.9.10. Enamuse rakenduste ja keskkondade ligipääs on arendajale võimalik ainult
VPN tunneli kaudu. IP põhiseid ligipääse vaikimisi ei looda. VPN tunneli kasutamiseks
on vajalik Eesti ID kaart või Digi-ID.
Tööde üleandmise-vastuvõtmise akt
1. Sisu
Lähtudes Tervise ja Heaolu Infosüsteemide Keskuse, keda esindab /lepingus märgitud kontaktisik/
(edaspidi tellija) ja /ettevõtja nimi/, keda esindab /lepingus märgitud kontaktisik/ (edaspidi täitja)
vahel päev.kuu.aasta sõlmitud hankelepingu nr ___ annab täitja üle ja võtab tellija vastu teostatud
tööd.
1.1. Käesoleva aktiga annab täitja tellijale üle tööd, mis täitja on teostanud vastavalt
hankelepingule ja tellija võtab käesolevas aktis nimetatud tööd vastu.
1.2. Tellija kinnitab, et tema või tema esindajad on käesolevas aktis nimetatud tööd üle vaadanud
ning see vastab hankelepingule.
1.3. Käesolev akt on täitjale tasu maksmise aluseks. Poolte vaheline arveldamine toimub
hankelepingu alusel vastavalt käesolevas aktis sisalduvatele andmetele.
1.4. Käesoleva akti pooled kinnitavad, et aktis sisalduvad andmed on nende parima teadmise
kohaselt õiged.
2. Akteeritavad tööd
Nr Tööde loetelu Roll / Nimi Maht Tunnihind Maksumus
kokku
(ID) töö nimetus (h) (€/h) KM-ta (€) KM-ta
1 Roll 1 ___ €
Roll 2
2 (...)
(...)
3
4
...
___ €
3. Tööde üleandmise tähtaeg
3.1. Tööd on üle antud päev.kuu.aasta /etappide puhul ka etapid/.
3.2. Tööd teostati tähtaegselt.
4. Puudustega tööde nimekiri
4.1. Puuduseid töös ei esine./Esinevad järgmised puudused töös:
4.1.1. ____;
4.1.2. ____;
4.2. Puuduste põhjendus.
4.3. Puuduste kõrvaldamise tähtaeg on päev.kuu.aasta.
5. Poolte allkirjad
Tellija: Täitja:
Lepinguline kontaktisik lepinguline kontaktisik
/allkirjastatud digitaalselt/ /allkirjastatud digitaalselt/
ISIKUANDMETE TÖÖTLEMISE TINGIMUSED
... (edaspidi volitaja), registrikood //, asukohaga //, keda esindab direktor //
ja
..... (edaspidi volitatud töötleja), registrikood //, asukohaga //, keda esindab juhatuse liige/volikirja
alusel //.
on sõlminud käesoleva isikuandmete töötlemise lepingu hankelepingu nr // lisana nr // (edaspidi
leping):
1. Ese ja eesmärk
1.1. Lepingu esemeks on volitaja ja volitatud töötleja (edaspidi koos nimetatud kui pooled)
vaheliste tingimuste sätestamine seoses /...hankelepingu nimetus.../ tööde käigus
käsitletavate andmete töötlemisega.
1.2. Volitatud töötleja töötleb lepingus kirjeldatud isikuandmeid hankelepingu nr //
täitmiseks, millele on volitatud töötlejal õigus saada ligipääs hankelepingus
määratletud tööde teostamiseks vastavalt lepingus sätestatud piirangutele.
1.3. Lepingu täitmiseks on volitatud töötleja isikuandmete töötlemisega seotud tegevused
lepingu alusel piiratud hankelepingu täitmiseks vajalike tegevustega.
1.4. //.
2. Isikuandmed
2.1. Volitatud töötlejale võivad hankelepingu täitmise käigus teatavaks saada volitaja poolt
hallatavas infosüsteemis või // andmekogus töödeldavad isikuandmed järgmises
koosseisus:
2.1.1. /... Infosüsteemi nimetus .../ andmed vastavalt // pp.kk.aaaa määruse nr // /...
määruse nimetus .../ peatükile nr // /... peatüki nimetus .../.
2.1.2. //
2.1.3. VÕI
2.1.4. //
2.1.5. isikuandmed, nt inimese nimi, sünniaeg, isikukood, isikut tõendava dokumendi
andmed;
2.1.6. kontaktandmed, nt aadress, telefoninumber ja e-posti aadress;
2.1.7. eriliigilised isikuandmed, nt andmed isiku või tema pereliikme terviseseisundi,
majandusliku seisundi või perekonna kohta;
2.1.8. ameti- ja kutsesaladust puudutav teave.
2.1.9. //
3. Volitatud töötleja kohustused
3.1. Volitatud töötleja on kohustatud:
3.1.1. tagama lepingueelsete läbirääkimiste ja lepingu täitmise käigus volitajalt ükskõik mis
vormis saadud isikuandmete konfidentsiaalsuse ja mitte edastama ega võimaldama
sellele teabele juurdepääsu kolmandale isikule ilma volitaja sellekohase selgesõnalise
kirjaliku nõusolekuta;
3.1.2. tagama, et lepingu täitmise raames töödeldavaid isikuandmeid ei edastata väljapoole
Euroopa Liidu liikmesriikide ja Euroopa Majandusühendusse kuuluvate riikide
territooriumi ilma volitaja sellekohase selgesõnalise kirjaliku nõusolekuta;
3.1.3. kasutama ja töötlema isikuandmeid üksnes hankelepingu täitmiseks ja volitaja
dokumenteeritud juhiste alusel, välja arvatud juhul, kui volitatud töötleja on
kohustatud teavet töötlema volitatud töötleja suhtes kohalduva õiguse alusel. Viimati
nimetatud juhul teavitab volitatud töötleja volitajat vastava kohustuse olemasolust
enne teabe töötlemist;
3.1.4. võimaldama juurdepääsu isikuandmetele ainult nendele isikutele, kellel on selleks oma
tööülesannete täitmiseks vajadus ning tagab, et need isikud on teadlikud ning järgivad
isikuandmete töötlemis alaseid nõudeid ja õigusakte, nad on saanud asjakohase
koolituse eelmainitud nõuete kohta, on võtnud endale konfidentsiaalsuskohustuse või
neile kehtib asjakohane seadusest tulenev konfidentsiaalsuskohustus;
3.1.5. teavitama volitajat toimunud või põhjendatult kahtlustatavast lepingu punktis 3.1.4.
sätestatud konfidentsiaalsuskohustuse rikkumisest viivitamatult;
3.1.6. täitma kõiki kehtivaid isikuandmete töötlemisalaseid nõudeid, andmete turvalisust
puudutavaid ning isikuandmete kaitse alaseid Euroopa Liidu ja Eesti Vabariigi
õigusakte ja muid eeskirju;
3.1.7. rakendama alltoodud organisatsioonilisi, füüsilisi ja infotehnilisi turvameetmeid
isikuandmete kaitseks juhusliku või tahtliku volitamata muutmise; juhusliku hävimise
ja tahtliku hävitamise eest ning õigustatud isikule andmete kättesaadavuse
takistamise eest, volitamata töötlemise, sh avalikustamise eest:
3.1.7.1. vältima kõrvaliste isikute ligipääsu isikuandmete töötlemiseks kasutatavatele
seadmetele;
3.1.7.2. ära hoidma andmete omavolilist lugemist, kopeerimist ja muutmist
andmetöötlussüsteemis, samuti andmekandjate omavolilist teisaldamist;
3.1.7.3. ära hoidma isikuandmete omavolilist salvestamist, muutmist ja kustutamist ning
tagama, et tagantjärele oleks võimalik kindlaks teha, millal, kelle poolt ja
milliseid isikuandmeid salvestati, muudeti või kustutati või millal, kelle poolt ja
millistele isikuandmetele andmetöötlussüsteemis juurdepääs saadi;
3.1.7.4. tagama, et igal andmetöötlussüsteemi kasutajal oleks juurdepääs ainult temale
töötlemiseks lubatud isikuandmetele ja temale lubatud andmetöötluseks;
3.1.7.5. tagama andmete olemasolu isikuandmete edastamise kohta: millal, kellele ja
millised isikuandmed edastati, samuti selliste andmete muutusteta säilimise;
3.1.7.6. tagama, et isikuandmete edastamisel andmesidevahenditega ja andmekandjate
transportimisel ei toimuks isikuandmete omavolilist lugemist, kopeerimist,
muutmist või kustutamist;
3.1.7.7. pidama arvestust isikuandmete töötlemisel kasutatavate tema kontrolli all
olevate seadmete ja tarkvara üle, dokumenteerides järgmised andmed:
3.1.7.7.1. seadme nimetus, tüüp ja asukoht ning seadme valmistaja nimi;
3.1.7.7.2. tarkvara nimetus, versioon, valmistaja nimi ja kontaktandmed.
3.1.8. teavitama kirjalikult volitajat turvameetmete rikkumisest, mis põhjustab, on
põhjustanud või võib põhjustada töödeldavate isikuandmete juhusliku või
ebaseadusliku hävitamise, kaotsimineku, muutmise või loata avalikustamise või neile
juurdepääsu viivitamata, kuid mitte hiljem kui kakskümmend neli tundi pärast sellest
teada saamist. Juhul, kui rikkumisest teadasaamine langeb nädalavahetusele või
riiklikule pühale, kohustub volitatud töötleja volitajat kirjalikult teavitama
viivitamatult, kuid mitte hiljem kui nelikümmend kaheksa tundi pärast rikkumisest
teada saamist. Kirjeldatud teates tuleb vähemalt:
3.1.8.1. kirjeldada isikuandmetega seotud rikkumise laadi, sealhulgas puudutatud
andmesubjektide liike ja arvu ning puudutatud kirjete liike ja arvu;
3.1.8.2. teatada andmekaitsespetsialisti või mõne teise täiendavat teavet andva
kontaktisiku nimi ja kontaktandmed;
3.1.8.3. soovitada meetmeid isikuandmetega seotud rikkumise võimalike negatiivsete
mõjude leevendamiseks;
3.1.8.4. kirjeldada isikuandmetega seotud rikkumise võimalikke tagajärgi;
3.1.8.5. kirjeldada volitatud töötleja poolt pakutud või võetud meetmeid
isikuandmetega seotud rikkumisega tegelemiseks ja
3.1.8.6. esitada muud teavet, mis on mõistlikult nõutav, et volitaja saaks täita
kohaldatavaid andmekaitse õigusakte, sealhulgas riigiasutustega seotud
teavitamise ja avaldamise kohustusi, näiteks teavet, mis on nõutav
andmesubjekti tuvastamiseks.
3.1.9. lõpetama eelnevalt kirjeldatud rikkumised või tegema kõik endast oleneva nende
lõpetamiseks ja kohaldama meetmeid isikuandmetega seotud rikkumise
lahendamiseks, sealhulgas vajaduse korral rikkumise võimaliku kahjuliku mõju
kõrvaldamiseks ja leevendamiseks;
3.1.10. kustutama, niivõrd kui see on võimalik, lepingu lõppemisel kõik tööde teostamise
käigus teatavaks saanud isikuandmed ja nimetatute koopiad 30 päeva jooksul, v.a
juhul, kui õigusaktidest tuleneb teisiti;
3.1.11. tegema volitajale kättesaadavaks kogu teabe, mida volitaja peab vajalikuks lepingus
sätestatud kohustuste täitmise tõendamiseks;
3.1.12. võimaldama volitajal või volitaja poolt määratud audiitoril teha seoses isikuandmete
töötlemisega auditeid ja kontrolle ning panustama nendesse.
4. Lõppsätted
4.1. Volitatud töötleja ei või oma lepingujärgseid kohustusi anda üle kolmandale isikule ega
kaasata oma lepingujärgsete kohustuste täitmiseks kolmandat isikut.
4.2. Isikuandmete konfidentsiaalsena hoidmise kohustus jääb kehtima ka pärast käesoleva
lepingu lõppemist tähtajatult.
4.3. Isikuandmete konfidentsiaalsena hoidmise kohustus ei laiene teabe avaldamisele
volitatud töötleja audiitorile ja advokaadile.
4.4. Leping on kehtiv poolte poolt allkirjastamisest kuni hankelepingu järgsete kohustuste
täitmiseni, v.a konfidentsiaalsuskohtustus, mis kehtib tähtajatult.
5. Poole allkirjad
Volitaja: Volitatud töötleja:
/Allkirjastatud digitaalselt/ /Allkirjastatud digitaalselt/
Versioon: 2.3
Dokument määrab kvaliteedi- ja mittefunktsionaalsed nõuded (MFN) uutele infosüsteemidele ning nende dokumentatsioonile. Dokumenti hoiavad ajakohasena
Tervise ja Heaolu Infosüsteemide Keskuse (TEHIK) arhitektid.
Dokumenti tuleb vaadata kui arenduste kvaliteedi- ja mittefunktsionaalsete nõuete põhidokumenti. Põhidokumendi ja viidatud dokumentide erisuste puhul tuleb
lähtuda põhidokumendis kirjeldatust. Põhidokumendis viidatud TEHIKu koostatud dokumentide ja kolmandate osapoolte koostatud dokumentide erisuste puhul tuleb
lähtuda TEHIKu dokumentides kirjeldatust.
Kui mõnda nõuet ei ole võimalik või otstarbekas täita, tuleb selle mittetäitmise fakt ja põhjendus välja tuua pakkumuse esitamisel.
Nõudeid tuleb järgida ka olemasolevate infosüsteemide versiooniuuendustel nii palju kui versiooniuuenduse käigus võimalik.
Erandid tuleb kooskõlastada TEHIK'u vastutava arhitektiga kirjalikult taasesitataval kujul projektidokumentatsiooni juures.
Nõude Nõude sisu Seletused Digiriigi Iseteenindus Veebid Karbitoode Koostamise Testimise läbi viib
nr CFR eest vastutaja või kinnitab
1. Vastavus üldistele standarditele
1.1 Lahendus loomisel peab arvestama Kohustus- ja ootustasemel olevad nõuded tuleb V V Arendaja Projektijuht
digiriigi ristfunktsionaalsed nõudeid. rakendada.
Arhitekt
https://koodivaramu.eesti.ee/e-gov/cfr
Administraator
Testija
Erisused tuleb kokku leppida Tellija lahenduse
Turvatestija
arhitektiga.
Infoturbe
spetsialist
Standardija
1.2 Lahenduse X-tee teenused peavad https://X-tee.ee/docs/live/xroad/ V V V Arendaja Testija
vastama nõuetele.
1.3 Lahendus peab vastama Tulevase ja olemasolevate infosüsteemide platvormid V V V Arendaja Projektijuht
Sotsiaalministeeriumi IT-profiilile. (rakendusserver, andmebaas, kolmanda osapoole
Arhitekt
komponendid) ja topoloogia peavad olema loodud
kooskõlas hankes viidatud IT-Profiil versioonile. Administraator
Testija
Turvatestija
Infoturbe
spetsialist
Standardija
1.4 Lahenduse kasutajaliides peab vastama https://tehik.ee/arendusjuhendid V V Arendaja Arhitekt
dokumendis "Front-end arendusreeglid"
Testija
kirjeldatud reeglitele.
1.5 Rakendus peab olema kirjutatud https://eits.ria.ee/ V V V Arendaja Turvatestija
arvestades selle lahenduse äriprotsesside
Arhitekt
ja andmete E-ITS ja ISKE turvaklassi
nõudeid.
1.6 Veebirakenduse kasutajaliides peab https://www.w3.org/TR/WCAG22/ #39 V V V Arendaja Testija
vastama vähemalt WCAG 2.2 tasemele
CFR selgitus: WCAG 2.2 alates 05.10.2023
AA.
1.7 Veebipõhine kasutajaliides peab Valideerimiseks kasutatakse vastavaid validaatoreid: #38 V V Arendaja Testija
ühilduma täielikult standarditega HTML
https://validator.w3.org/
5 ja CSS 3.
Kui on tegu olemasoleva süsteemi edasiarendusega,
siis tuleb järgida olemas olevat HTML ja CSS
versiooni.
1.8 Allkirjastamisel tuleb kasutada Tellija https://www.tehik.ee/arendusjuhendid V V Arendaja Testija
SiGA/SiVa vahendusteenust.
Arhitekt
1.9 Rakendus peab probleemideta läbima Kui pole arenduses eraldi kokku lepitud teisiti, siis on #9 V V V Arendaja Turvatestija
OWASP ASVS baasil põhineva testi. OWASP ASVS tasemeks 2 (https://owasp.org/www-
#10
project-application-security-verification-standard/).
Kinnise lähtekoodiga kommertstoote kasutamisel ei
eeldata ligipääsu kinnisele lähtekoodile.
Tellijapoolset turvatestimist teostab kolmas sõltumatu
osapool. Selline esmane kolmanda osapoole
turvatestimine tellitakse Tellija finantseeringul.
Ilmnenud vigade korral ja peale nende parandamist
peab järeltestimise rahaliselt kompenseerima arendaja,
kui Tellija vastava nõudmise esitab.
1.10 Krüptoalgoritmite ja räsifunktsioonide Krüptoalgoritmite ja räsifunktsioonide kasutamisel #46 V V V Arendaja Arhitekt
kasutamisel tuleb kasutada turvalisi tuleb järgida uusimat RIA kodulehel avaldatud
Administraator
algoritme ja võtmepikkuseid. krüptograafiliste algoritmide kasutusvaldkondade ja
elutsükli uuringut. Turvatestija
Värskeima uuringu leiab aadressilt
https://www.ria.ee/amet-uudised-ja-kontakt/uudised-
pressikontakt/uuringud-ja-analuusid#kruptouuringud
Arendaja loodud lahenduse dokumentatsioonis (nt
detailanalüüs vms) tuleb välja tuua kasutatavad
krüpto- ja räsialgoritmid, nende võtmepikkused,
kasutuskohad, sh sertifikaatide kasutuskohad.
1.11 Andmete edastus peab olema kaitstud Autentimist ei ole vaja ainult avalike andmete V V V Arendaja Turvatestija
kasutades krüpteeritud ning vajadusel edastamisel (nt avaandmed).
Arhitekt
autenditud ja autoriseeritud kanalit.
Autentimise mehhanism tuleb kokku leppida
Tellijapoolse arhitektiga.
1.12 Infosüsteem peab kasutama serveri Kõik mahakirjutatavad ja talletatavad kellaajad tuleb #51 V V V Arendaja Arhitekt
kellaaega. salvestada UTC ajatsoonis koos ajatsooni infoga.
Administraator
Kasutajatele mõeldud kuvades tuleb kasutada sirviku
ajatsooni. Aja esitamisel tekstikujul lähtuda
standardist ISO 8601.
1.13 Süsteemi edasiarendamisel/loomisel peab Süsteemi jõudlus peab vastama kokkulepitud V V V Arendaja Arhitekt
arvestama selle võimaliku laiendamisega topoloogial eelanalüüsi ja lähteülesande käigus välja
Testija
nii andmemahtude kui ka kasutajate arvu toodud jõudlusnäitajatele.
osas.
1.14 Rakendus peab olema tehniliselt Lahenduse arhitektuuris kasutada domeenist juhitud #21 V V Arendaja Arhitekt
tükeldatud vastavalt loogilisele jaotusele. disaini ja mikroteenuste põhimõtteid.
Saadud osised peavad olema eraldi
Näiteks kui rakendus on eraldi turvakontekstidega
versioneeritavad ja paigaldatavad.
liidesed ametnikule ja kodanikule, peab rakendus
olema jagatav kaheks eraldi liidesekomponendiks ning
nende mõlema poolt kasutatavaks andmebaasiks.
https://learn.microsoft.com/en-us/archive/msdn-
magazine/2009/february/best-practice-an-
introduction-to-domain-driven-design
https://microservices.io/
1.15 Avalike e-teenuste loomisel peab https://riigikantselei.ee/valitsuslogo #36 V V V Arendaja Testija
arvestama valitsusasutusele kehtestatud
visuaalse identiteedi stiilijuhiseid.
1.16 Avalike e-teenuste loomisel peab https://veera.eesti.ee/ #36 V V Arendaja Arhitekt
arvestama Veera disainisüsteemiga.
Näiteks kasutada ja laiendada E-Gov CVI projekti
komponente:
https://e-gov.github.io/cvi/
1.17 Lahenduse loomisel peab arvestama https://digiriik.eesti.ee/koostoimeraamistik/ V V V Arendaja Arhitekt
riiklikku koostoimeraamistikuga.
Administraator
1.18 Aadressiandmete sisestamisel, kuvamisel Liidestatakse Maa-ameti ADS teenusega. #53 V V Arendaja Arhitekt
ja hoidmisel tuleb lähtuda Vabariigi
Esitluskihis on lubatud liidestada In-ADS teenusega Standardija
Valitsuse määrusest "Aadressiandmete
otsingu tarvis. Taustsüsteemides toimub liidestamine
süsteem". Testija
X-tee teenusega.
https://www.riigiteataja.ee/akt/115072023005?
leiaKehtiv
1.19 Tegevusalade andmete sisestamisel, https://www.riigiteataja.ee/akt/12910889?leiaKehtiv #54 V V Arendaja Standardija
kuvamisel ja hoidmisel tuleb lähtuda
https://emtak.rik.ee/EMTAK/ Testija
Vabariigi Valitsuse 10. jaanuari 2008. a
määrusest nr 11 "Klassifikaatorite
süsteem" ja kasutada EMTAK
infosüsteemis kehtivat klassifikaatorit.
2. Nõuded rakenduse arhitektuurile
2.1 Rakenduse, andmebaasi ja kolmanda Arendaja loodud lahenduse dokumentatsioonis (nt #7 V V V Arendaja Arhitekt
osapoole komponendid peavad olema analüüs vms) peab olema välja toodud kasutatavate
sellised, mille turbe uuenduste eluea lõpp komponentide nimetused ja versioonid. Lubatud on
(Security Support) pole teadaolevalt kasutada ka tarkvara materjalide loendit (SBOM).
vähem kui 2 aasta pärast. Versiooni eluea lõppu ei loeta võrdseks terve
komponendi eluea lõpuga, st versiooni tugi võib
aeguda, kui uus versioon on välja lastud.
Jätkuarenduse puhul tuleb kaardistada eelneva
arendusperioodi komponentide kaardistus. EOL
komponentide kasutamisest tuleb teavitada
Tellijapoolset arhitekti.
CFR selgitus: Kahjuks täna paljud komponendid
vaatavad tulevikku 1.5 - 2 aastat. Võimalusel valida
komponendid, mis omavad pikka elueatuge, nn LTS
versioon.
2.2 Rakendusserver peab võimaldama V V V Arendaja Administraator
töötamist andmebaasiserverist eraldi
serveril.
2.3 Rakendusserver peab olema Kasutaja sessioonid ei tohi olla rakenduserveri klastri V V V Arendaja Administraator
kõrgkäideldav ja horisontaalselt õla põhised.
skaleeruv.
2.4 Rakendust peab saama ilma Lahenduses ei tohi olla sisse kompileeritud V V V Arendaja Administraator
ümberprogrammeerimata liigutada absoluutseid URI-sid.
erinevate domeenide ja domeeni saitide
vahel.
2.5 Rakenduse komponentide Rakendus peab neid sealt ka kasutama (mitte V V V Arendaja Administraator
konfiguratsiooni peab olema võimalik kopeerima parameetreid käivitamisel kolmandatesse
Testija
ette anda käivitamisel. Konfiguratsiooni kohtadesse), logimise seaded võivad olla rakenduse
muudatus peab olema teostatav ilma konfiguratsioonifailist eraldi ühes
rakendust kompileerimata. lisakonfiguratsioonifailis (nt Log4j). Samuti on
tungivalt soovituslik eraldi konfiguratsioonifailis
hoida arendaja ja administraatori vastutusala
parameetreid.
Infosüsteem peab olema seadistatav
konfiguratsiooniparameetrite(de) abil.
Konfiguratsioonifailiks ei saa lugeda faili, kus
hoitakse lisaks konfiguratsioonile ka muud
programmikoodi.
Näiteks konteinerlahenduste puhul peab kasutama
keskkonnamuutuja põhiseid konfiguratsiooni
parameetreid.
2.6 Rakenduse taaskäivitus, konfiguratsiooni Tavaline käivitusaeg ei tohi ületada 30 sekundit. V V V Arendaja Testija
muutmine vms peab toimuma mõistliku
Kui rakendus vajab indekseeritud sisu ja see pole
aja jooksul.
kättesaadav, siis peab rakendus väljastama selle kohta
selge teate.
2.7 Lahenduse väliste osapoolte Kui rakendusel või mõnel selle komponendil on tihti V V Arendaja Arhitekt
komponentide konfiguratsioonid peavad kasutatav teenus ning sellel teenusel on laetav
Testija
olema puhverdatud. konfiguratsioon, siis tuleb:
Administraator
laadida konfiguratsioon ühekordselt ja seda
korduvkasutada;
konfiguratsiooni automaatselt ja regulaarselt
värskendada; regulaarsuse tarbeks peab saama
määrata intervalli, millise aja järel või täpsed
kellaajad, millal konfiguratsiooni värskendatakse;
luua võimalus värskendada konfiguratsiooni
käsitsi.
Näiteks:
digidoc4j teegi korral laetakse TSL nimekiri
välisvõrgust puhvrisse, et vähendada koormust
kolmandale osapoolele.
OpenID konfiguratsioon
2.8 Kõik andmed, andmebaasid, SQL #50 V V V Arendaja Administraator
skriptid, lähtekood ja rakendus peavad
Testija
kasutama UTF-8 või UTF-16
kodeeringut.
2.9 Rakendusserveri failisüsteemi ei tohi Näiteks objektide talletuseks kasutada objektide V V Arendaja Administraator
salvestada midagi püsivaks kasutamiseks. talletamise lahendust (nt MinIO).
2.10 Ühest relatsioonilise andmebaasi Erinevate skeemide vahelised ühendused on keelatud. V V Arendaja Arhitekt
andmetabelist teise viitamisel tuleb Peab kasutama REST/SOAP/AMQP liidestust.
kasutada väliseid võtmeid (Foreign key).
2.11 Kõik välised võtmed (Foreign Key) Andmebaasis peab kasutama indekseid ja/või muid V V Arendaja Arhitekt
peavad olema indekseeritud. meetmeid, et nõuded rakenduse jõudlusele oleksid
täidetud ka tulevikus. (ühe, kolme, viie või 10 aasta
pärast – vastavalt planeeritud kasutusajale).
2.12 Tuleb kasutada päringumuutujaid SQL päringute väljakutsumisel väljastpoolt V V Arendaja Arhitekt
(Parameter Binding). andmebaasi peab kasutama päringumuutujaid, et
vältida SQL vahemälu fragmentseerumist (When
calling SQL code from outside the database,
Parameter Binding should be used to prevent SQL
cache fragmentation).
2.13 Kõigis andmebaasi tabelites peab olema Kasutada tuleb vastava andmebaasisüsteemi V V Arendaja Arhitekt
defineeritud üks primaarvõti nimetamise parimaid praktikaid.
2.14 Andmebaasi objektide nimetused peavad Kasutada tuleb vastava andmebaasisüsteemi V V Arendaja Arhitekt
olema sisulised ja andma aimu nende nimetamise parimaid praktikaid.
otstarbest.
2.15 Andmebaasis defineeritakse üldjuhul Need õigused, mis on vajalikud ainult rakenduse baasi V V Arendaja Administraator
kaks või enam kasutajat: loomiseks, on eraldi välja toodud ja tuleb peale
installeerimist ära võtta. Karbitoodete puhul tuleb
Rakenduse peakasutaja, kellena
erisused läbi arutada Tellija arhitektiga.
luuakse objektid ja skeemid.
Rakenduse piiratud õigustega Lahenduse puhul, milles kasutatakse andmebaasi
kasutaja, kellena pöördub versiooneerimist, tuleb kasutada mitut andmebaasi
rakendusserver/rakendus. ühendust. Ennem rakenduse käivitumist teostatakse
andmebaasi skeemi muudatused eraldi kasutajaga.
Objektide loomiseks vajalikud õigused ja
Rakendus kasutab enda põhitööks kasutajat, kellel
ressursid on loetletud rakenduse
puudub õigus andmebaasi skeemis muudatusi
dokumentatsioonis.
teostada.
2.16 Failide hoidmise asukoht lepitakse iga Failide hoidmine klassikalises andmebaasis on V V Arendaja Arhitekt
kord kokku, kuid failid ja failide indeks kulukas ja seab kõrgendatud nõudmised ja piirangud
peavad olema replikeeritavad teise andmebaasiserveritele. Lahenduse dokumentatsioonis
asukohta. tuleb ära tuua failide hoidmise asukoht.
Näiteks objektide talletuseks kasutada objektide
talletamise lahendust.
2.17 Peab olema miinimumini viidud vajadus, Halduri haldustoimingud lepitakse Tellijaga kokku V V V Arendaja Testija
et haldur teeb haldustoiminguid otse detailanalüüsi käigus.
baasis. St rakendusel peab olema
haldusliides, mille kaudu rakenduse
haldur saab teha tavapäraseid
haldustoiminguid.
2.18 Andmebaas peab toetama nii külm- kui Ei tohi kasutada teenuseid, mis välistavad andmebaasi V V Arendaja Arhitekt
ka kuumvaru (peegeldamist) teise peegeldamist (nt "MSSQL filestream").
asukohta.
2.19 Sorteerimisreeglistik peab olema Eesti Näiteks PostgreSQL puhul et_EE. V V V Arendaja Testija
tähestikule vastav. Tõusutundlikkus peab
olema välja lülitatud. Diakriitiline
(Accent) peab olema sisse lülitatud.
2.20 Kui infosüsteemid saadavad e-kirju, Saatja ja adressaadid, pealkiri ja sisu ei tohi olla V V V Arendaja Administraator
peavad nad kasutama välist e-maili rakendusse kodeeritud, vaid on muudetavad
serverit. Kirja saatmisel peab rakendus konfiguratsioonifaili kaudu.
veenduma, et e-posti server võttis kirja
Genereeritud kirjade puhul peab tagama kirjade
vastu. E-kirjade vormindamine peab
jälitatavuse (näiteks lisada X-päise kodeeritud kirje,
järgima interneti standardeid (RFC
milles on kirjeldatud, mis protsess/skriptifail/kasutaja
5322).
kirja genereeris jms abistav info).
2.21 Konfiguratsiooniparameetrite nimed Näiteks : X_TEE_TURVASERVER, mitte XTTS või V V Arendaja Administraator
peavad olema sisulised. Kui see ei ole viitenumber, mitte vk_seb jne
võimalik, siis peab kõrval olema seletus. Testija
2.22 Infosüsteemides on eessüsteemid (front Koostöövõime raamistik 2011. Punkt 3.1. #23 V V Arendaja Arhitekt
end; presentatsiooni kiht) ja Tagasüsteemide ülesanneteks on andmete haldamine
#29
tagasüsteemid (back end; äriloogika kiht) ja võrguteenuste pakkumine. Tagasüsteemid ei tegele
arhitektuuriliselt selgelt lahutatud ja lõppkasutaja autentimise ja autoriseerimisega. #64
eraldi paigaldatavad. Lõppkasutaja autoriseerimise tagavad eessüsteemid.
Välise süsteemi tõrge tohib mõjutada ainult sellest
Rakenduse äriloogika tuleb realiseerida
otseselt sõltuvate kasutuslugude toimimist. Välise
andmebaasist eraldi sõltumatus
süsteemi taastumisel peab süsteem olema suuteline
rakenduskihis.
oma tööd jätkama taaskäivitamata.
Andmebaas ei tohi sisaldada äriloogikat, mis muudab
andmetabelites olevaid/sinna kirjutatavaid andmeid,
va trigerid, mis tekitavad logi.
2.23 Konfiguratsioonifailid peavad olema Näiteks IIS: *.config , *.resources Apache: *.conf, V V V Arendaja Administraator
vastavalt rakendusserveri tüübile .htaccess.
vaikimisi kaitstud failid/objektid.
Arendaja peab välja tooma konfifailide listi, kui neid
on mitu.
2.24 Rakenduse failid, mida kasutaja näha ei Näiteks: IIS: Bin,App_Code, App_Data, V V V Arendaja Administraator
tohi, peavad olema vaikimisi kaitstud App_Browsers, App_GlobalResources,
kaustades ja ei tohi olla veebi App_LocalResources, App_Themes,
juurkaustas. App_WebReferences, .git
2.25 Konfiguratsiooniparameetrite Kõiki parameetreid tuleks konfiguratsioonis kirjeldada V V Arendaja Administraator
taaskasutus. Erinevaid sama sisuga vaid korra, dubleerimine on keelatud.
Testija
parameetreid ei tohi konfiguratsioonis
eksisteerida.
2.26 Esitluskihist ei tohi pöörduda otse Tuleb rakendada vähemalt 3 tasandilist arhitektuuri V V V Arendaja Administraator
andmebaasi poole. (three-tier architecture).
Lõppkasutaja lokaalsesse seadmesse paigaldatud
tarkvara loeme esitluskihiks. Ka sellisel juhul ei tohi
teha lõppkasutaja seadmest otse ühendust andmebaasi.
2.27 Keskkonnapõhised muutujad peavad Näiteks WSDL ei tohi sisaldada viiteid V V V Arendaja Administraator
olema konfiguratsiooniparameetritega arendusserveritele.
Testija
seadistatavad.
2.28 Eelistada tuleb tsentraalseid Kui rakendus realiseerib ise autentimist, siis peab #30 V V V Arendaja Arhitekt
autentimislahendusi (nt Tellija SSO olema võimalik piirata ebaõnnestunud logimisi
Testija
lahendus). ajaühiku kohta (mobiil-ID, paroolid) ühelt IP-
aadressilt.
Eelistama peaks IP-aadressipõhist blokeeringut.
Erandina Tellijaga kokkuleppel võib kasutada
captchat või konto lukustamist. Blokeeringute
ajavahemikku ja logimiskatsete arvu peab saama
konfiguratsioonifailist muuta.
Rakenduses realiseeritav autentimise lahendus
peab olema põhjendatud ja omama kirjalikku
taasesitatavat kokkulepet projekti
dokumentatsiooni juures
2.29 Relatsioonilises andmebaasis võib Ei ole soovitav kasutada mingit V V Arendaja Arhitekt
kasutada vaid ISO/IEC 9075 standardiga platvormispetsiifilist lahendust, mille üleviimine
kaetud funktsionaalsusi. Lisaks ei tohi mõnele muule andmebaasiplatvormile ei ole
kasutada ka sama standardi osas 13 võimalik.
kirjeldatud funktsionaalsusi. ISO/IEC 9075 osa 13 spetsifitseerib Javas
kirjutatud programmimoodulite kasutamist
andmebaasis.
2.30 Uniform resource identifier (URI) pikkus Harilikult on piiriks 2048 tähemärki, kuid iga V V V Arendaja Administraator
ei tohi ületada ühegi lahenduse poolt lahenduse puhul tuleb seda eraldi järele uurida
Testija
toetatava sirviku maksimaalset lubatud sõltuvalt lahenduse komponentidest. Asjakohased
väärtust. viited: RFC 3986 ja RFC 7239.
2.31 Veebiteenuseid (REST, SOAP) pakkuv Näiteks WSDL puhul: Alajaotis V V V Arendaja Arhitekt
rakendus peab olema üles ehitatud nii, et definitions/types/schema:
see toetaks teenuste versiooneerimist
complexType defineerimisel tuleb sellele lisada
URL-i ja/või skeemi tasemel.
any element.
2.32 Rakendus peab olema võimeline töötama Koormusjaoturi peal kasutatakse järjestikplaanurit V V V Arendaja Administraator
koormusjaoturitega varustatud taristul. (Round Robin) päringute suunamisel. Samuti võidakse
teostada koormusjaoturil TLS ühenduse lahtivõtmist ja
uuesti kokkupanemist (SSL offload).
2.33 Sidusinfosüsteemide mittekättesaadavus Sidussüsteemi tõrge tohib mõjutada ainult sellest V V V Arendaja Administraator
ei tohi segada rakenduse töötamist. otseselt sõltuvate kasutuslugude toimimist.
Testija
Sidusinfosüsteemidega Sidussüsteemi taastumisel peab süsteem olema
andmevahetamisel tekkinud vead suuteline oma tööd jätkama rakendust taaskäivitamata.
logitakse ja kasutajat hoiatatakse.
Väliste liidestatud süsteemide tõrke korral ei tohi
süsteem hanguda, vaid peab väljastama mõistliku
(võimalikult lühikese) aja jooksul asjakohase veateate.
Võimalusel tuleb kasutada asünkroonseid liideseid.
2.34 Automaatselt käivituvaid taustatöid peab Vajalik juhul, kui automaatsel käivitumisel on V V V Arendaja Testija
saama käsitsi (taas)käivitada. tekkinud viga ja/või taustatöö on pooleli jäänud.
Pärast vea põhjuse korrigeerimist peab saama
taustatöö uuesti käivitada.
Lahendusse on vaja luua taustatööde haldamiseks ja
juhtimiseks võimekus, et võimaldada vastavates
rollides olevatel inimestel lahendust hallata (nt
peakasutaja või rakenduse administraator).
2.35 Kui ajastatult käivitatav taustatöö ei ole Kui lahendus töötab mitmel õlal, ei tohi tööd, mis ei V V Arendaja Administraator
mõeldud käima paralleelselt, peab selles ole mõeldud paralleelselt käima, käivituda korraga
Testija
olema realiseeritud kontrollmehhanism, mitmel õlal. Peab rakendama lukustus põhimõtet.
mis tagab, et sama taustatööd ei ole
võimalik käivitada uuesti enne, kui
eelmisena käivitatud instants on oma töö
lõpetanud.
2.36 Uue toote arenduse ja olemasolevate V V V Arendaja Arhitekt
infosüsteemide versiooniuuendustel
kasutusele võetavate tehnoloogiate ja
standardite valik tuleb kooskõlastada
Tellijapoolse arhitektiga.
2.37 Rakenduse ühenduste (s.h. andmebaasi ja Implementeeritud peab olema vähemalt V V V Arendaja Arhitekt
sidusinfosüsteemide ühendused) maksimaalsete ühenduste arvu piirang, päringu
realiseerimisel tuleb kasutada ühenduste aegumise aeg (request timeout) ja ühenduse elususe
puulimist (connection pooling). periood (keepalive). Rakenduse ühenduste tõrge tohib
mõjutada ainult sellest otseselt sõltuvate
kasutuslugude toimimist. Ühenduste taastumisel peab
rakendus olema suuteline oma tööd jätkama
taaskäivitamata. Tekkinud vead logitakse ja kasutajat
hoiatatakse.
2.38 Rakenduse uuendustega kaasnevad Näiteks Liquibase või Flyway. V V Arendaja Administraator
andmebaasi muudatused tuleb
automatiseerida ja versioneerida.
2.39 Mitterelatsioonilises mudelis andmete Näiteks kui soovitakse kasutada NoSQL lahendusi V V V Arendaja Arhitekt
hoiustamine tuleb eraldi kokkuleppida. püsivaks andmete talletuseks, tuleb see kokku leppida
Tellijapoolse arhitektiga.
2.40 Mikroteenuste arhitektuuris vältida Iga teenus vastutab enda valdkonna andmete eest. Kui V Arendaja Arhitekt
ebavajalikku andmete dubleerimist. on vajadus lisaandmete jaoks, on tal võimalik
pöörduda teise teenuse poole.
2.41 Infosüsteemide vaheline andmevahetus https://www.ria.ee/riigi-infosusteem/andmevahetuse- #22 V V V Arendaja Arhitekt
toimub üle X-tee. platvormid/andmevahetuskiht-X-tee
https://www.riigiteataja.ee/akt/106082019017?
leiaKehtiv
Erandiks on lubatud päringud sama andmekogu
raames. Sellisel juhul tuleb turvalisus tagada
lahenduse loojate poolt. Kasutada kas mTLS või
tõendipõhist autentimist.
3. Turvalisuse tagamisega seotud nõuded
3.1 Asutusesiseseks kasutamiseks mõeldud TEHIKu haldusala kasutajad ja nende rollid on V V V Arendaja Turvatestija
rakenduse kasutajate autoriseerimist peab kirjeldatud Active Directory's. Võimalik on kasutada
saama teha vastu TEHIKu keskset rollide pärimiseks TEHIK SSO teenust.
autoriseerimisteenust.
Täpsem tehniline lahendus leida koos TEHIKu poolse
arhitektiga.
3.2 Kliendi ja serveri vahel peab autenditud V V V Arendaja Turvatestija
kasutajasessioonide korral olema
sessioon krüpteeritud HTTPS-protokolli
kasutades.
3.3 Rakendus tohib kasutada vaid sessiooni V V Arendaja Turvatestija
küpsiseid (cookies). Muude küpsiste
kasutamine tuleb kokku leppida
Tellijapoolse arhitektiga.
3.4 Kui andmebaasis olevate andmete E-ITS St kõik andmemuudatused peavad baasis säilima. #55 V V Arendaja Turvatestija
tervikluse (I ehk integrity) turvaosaklass Andmete muutmisel andmeid ei kustutata, vaid
#49 Arhitekt
on S või VS, siis tuleb kõik andmebaasi tehakse uus kirje uute andmetega. Vana muudetakse
kirjed/tabelid versioneerida. kehtetuks. Iga uus kirje peab sisaldama järgmist
informatsiooni:
viide kirjele, mille ta kehtetuks muutis (kui on)
kasutaja, kes kirje lõi
kirje loomise aeg
sessiooni-ID (kui on olemas)
X-tee ID (kui on olemas)
Iga kehtetuks tunnistatud kirje peab omama järgmist
informatsiooni;
kasutaja, kes kirje kehtetuks tunnistas;
kirje kehtetuks tunnistamise aeg.
Täpne realisatsioon tuleb kokku leppida Tellija
arhitektiga.
3.5 Rakendusega peab kaasas olema Testandmed peavad säilitama kõik toodangu andmete V Arendaja Arhitekt
lahendus, mis suudab toota toodangu omadused (pikkuse, tüübi) ja omavahelised suhted.
andmetest testandmed, mis ei võimalda
Täpsem vajadus ja tegevusplaan tuleb koostada Tellija
siduda konfidentsiaalset informatsiooni
arhitekti ja tooteomanikuga.
päris andmesubjektiga.
3.6 Rakendus ja selle komponendid peavad Arendaja arendab arenduskeskkonnas ja annab tarne V V V Arendaja Turvatestija
võimaldama kasutada keskkondade üle Tellijale paigalduspakkidena. Tellija paigaldab
lahusust. selle testkeskkonda ja testib ning seejärel paigaldab
tarne toodangu keskkonda. Reaalseid andmekogu
andmeid tohib töödelda üksnes toodangu keskkonnas.
Üldjoones on kõik keskkonnad majutatud
Tellija majutuses.
3.7 Rakendusse ja andmetele tohib olla St rakendustes ega andmebaasides ei tohi olla V V V Arendaja Turvatestija
ligipääs vaid dokumenteeritud ja ligipääsemiseks teisi võimalusi.
tellimuses kirjeldatud teid mööda ning
dokumenteeritud autentimisprotseduure
kasutades.
3.8 Rakendus ei tohi teostada X-tee päringut Kasutajaarvutitest otse X-tee päringute tegemine on V V V Arendaja Turvatestija
otse kasutajaarvutist. arvutivõrgu tasemel kinni.
3.9 Veebipõhised välise veebilehega IIS puhul peab kasutama näiteks URL scan, apache V V V Administraator Turvatestija
rakendused peavad kasutama vahendeid, puhul modsecurity või vastavat tööriista. Lubamatud
kaitsmaks rakendust lubamatute päringud on kõik päringud, mis ei ole detailanalüüsi
päringute eest. käigus vastavalt kasutusjuhtudele ette nähtud.
Blacklistingu asemel tuleb kasutada whitelisting
põhimõtet.
3.10 Kasutaja peab saama soovi korral Rakendus peab sisenemisel näitama pärast õnnestunud V V V Arendaja Turvatestija
veenduda, kas keegi pole tema nime all sisselogimist eelmise õnnestunud sisselogimise aega.
vahepeal sisse loginud. Kui on toimunud ebaõnnestunud sisselogimise
katseid, siis peab ka kuvama, millal need toimusid,
mitu neid oli ja mis IP-aadressilt pöörduti.
Ebaõnnestunud logimiste katsete kuvamise nõue
kehtib juhul, kui autentimine ja autoriseerimine
lahendatakse rakenduses lokaalselt.
3.11 Kõigil rakendustel peab olema Aeg peab olema muudetav koos teiste V V V Arendaja Turvatestija
konfigureeritav kasutajasessiooni konfiguratsiooniparameetritega.
aegumise aeg.
Nõue kehtib juhul, kui kasutatakse lahenduse sisest
sessiooni haldust.
3.12 Lahenduses kasutatavate küpsiste sisu Eesmärk on kaitsta kasutaja andmeid, mis on V V Arendaja Turvatestija
peab olema krüpteeritud talletatud sirviku küpsiste hulka.
3.13 LDAP lahenduse (nt Active Directory) Näiteks: konto on lukus, parool aegunud, konto #30 V V V Arendaja Turvatestija
kasutamisel peab rakendus kasutama aegunud, paroolipoliitika jne.
kontoga kaasnevaid
piiranguparameetreid.
3.14 Tagada tuleb rakenduse rollide lahusus. Peakasutajal ja tavakasutajal on erinevad V V V Arendaja Turvatestija
tööülesanded. Rollide/õiguste kirjeldus peab lähtuma
detailanalüüsist ja kasutusjuhtudest.
3.15 Arendus peab olema orienteeritud Toodangukeskkonnas mittevajalikud V V V Arendaja Turvatestija
toodangukeskkonnas toimimiseks. funktsionaalsused peavad olema eraldi juhitavad ja
tavakäivitusel väljalülitatud. Näiteks eraldiseisva
profiiliga Java arenduste puhul. (kasutuseta
funktsionaalsus ja komponendid, mis on mõeldud
testimiseks testkeskkonnas ja arendusabiks
arenduskeskkonnas)
3.16 Kui rakenduse tervikluse turvaosaklass See tagab, et tõestusväärtusega andmeid ei saaks V V V Arendaja Turvatestija
on T3, peavad tõestusväärtust omavad märkamatult kustutada.
andmed olema kas ajatembeldatud,
Konkreetne lahendus tuleb kokku leppida Tellija
digiallkirjastatud või digitembeldatud
arhitektiga.
ning krüptoaheldatud.
3.17 Kui rakenduses on S3 Konkreetne lahendus tuleb kokku leppida Tellija V V V Arendaja Turvatestija
salastatuse astmega andmeid, peavad arhitektiga.
need olema nii transpordi ajal ja ka
salvestatult alati krüpteeritult.
3.18 Rakendus peab võimaldama hõlpsalt Krüptograafiat kasutav rakenduskood ei tohi V V V Arendaja Turvatestija
välja vahetada aegunud ja ebaturvalise nimeliselt välja kutsuda krüptograafilisi algoritme,
krüptoalgoritmi. vaid peaksid seda tegema vahendavate vaheteekide
kaudu üldiste funktsioonide järgi (nt krüpteerimine,
dekrüpteerimine, signeerimine, signatuuri
verifitseerimine jne). Dokumentatsioon peab
kajastama üldist kirjeldust, kuidas vajadusel
ebaturvaline krüptoalgoritm välja vahetada.
Lisaks peavad eksisteerima vahendid juba
olemasolevate krüpteeritud andmete
ümberkrüpteerimiseks.
3.19 Rakenduse andmebaasi krüpteerimisega Andmebaasides kasutatavad V V V Arendaja Turvatestija
seotud andmeväljad peavad olema krüpteerimisfunktsioonidest tingitud lisaväljad peaksid
muudetava pikkusega. olema muudetava pikkusega, et formaati muutmata
saaks kasutada teistsuguste parameetritega
krüpteerimisalgoritme.
3.20 Lahendus peab olema kaitstud HTMLi OWASP soovitab kasutada DOMPurify lahendust #44 V V V Arendaja Arhitekt
süstimiste eest. HTMLi saneerimiseks Turvatestija
4. Logimine
4.1 Logimiseks tuleb kasutada standardseid Näiteks Java raamistikku log4j, SLF4J, logback; V V V Arendaja Arhitekt
komponente kogu logiahela ulatuses. transpordiks syslog, Elastic Beats; logi formaadiks
Administrator
JSON. Logi peab olema loetaval tekstilisel kujul, et
logikirjeid saaks töödelda masinmõistetavalt ja
inimloetavalt.
4.2 Peab kasutama logikomponenti ja peab Seletus: Näiteks peab saama muuta logimise taset ja V V V Arendaja Arhitekt
olema võimalik juhtida logikomponendi logimise formaati.
Administraator
seadistusi.
Testija
4.3 Logisündmused peavad olema loogiliselt Auditlogi (Seansilogi, tegevuslogi) - info #41 V V V Arendaja Arhitekt
eristatavad. sisselogimiste, väljalogimiste ja seansi aegumiste
Administraator
kohta. Vigased sisselogimise katsed. Info õiguste
suurendamise kohta. Peab olema logitud ka tühja või
puuduvate parameetritega logimise katsed. Kogu
informatsioon kasutajate tegevuste kohta koos
tegevuse tüübi, seansi parameetrite (korreleerimaks
seansi- ja tegevuslogi) ja kasutaja poolt esitatud
sisendparameetritega (sh. väliste ressursside
kasutamise kohta). Logida tuleb nii õnnestunud kui ka
ebaõnnestunud tegevusi.
Tehniline logi - rakendusserveri poolt loodud logi
Vealogi - erinevate veaolukordade info
Silumislogi - arendajate jaoks vajalik debug info
4.4 Logimine peab olema optimeeritud. Informatsiooni dubleerimist logides tuleb vältida, kui V V V Arendaja Arhitekt
ei ole nõutud teisiti.
Testija
4.5 Logides peab olema maksimaalselt üks V V Arendaja Administraator
sündmus ühel real.
Testija
4.6 Logikirje peab olema JSON formaadis. V V Arendaja Arhitekt
Testija
4.7 Logiväljade nimed peavad olema Samatüübilised logiväljade nimed peavad olema V V Arendaja Arhitekt
normaliseeritud ja tuleb rakendada ühtsed üle logi. Infoturbespetsialist
Elastic Common Schema
https://www.elastic.co/guide/en/ecs/current/ecs-
spetsifikatsiooni.
reference.html
4.8 Rakendus peab logima kasutaja edukat ja Logima peab ka autentimise ebaõnnestumise koos V V V Arendaja Arhitekt
ebaedukat autentimist ja sessiooni põhjusega (vale juurdepääsumandaat, aegunud konto
Testija
lõpetamist, kasutaja IP-d ja jne). Logida tuleks IP-aadress, meetod ja kui võimalik
autentimismeetodit. kasutajatunnus (mobiil-ID puhul telefoni number; ID-
kaardi või Smart-ID puhul isikukood).
Kui rakendus kasutab kasutajate autentimiseks välist
autentimise/autoriseerimise vahendit, siis leppida
eraldi kokku autentimise detailsus ehk mida
kajastatakse autentimise/autoriseerimise vahendis ja
mida rakenduses.
4.9 Üle terve logi peab olema kasutaja Tegevuste sidumiseks peab olema võimalik logikirjeid #17 V V V Arendaja Arhitekt
sessiooni käigus tehtud tegevusi või sama siduda ühise välja abil. Selleks ei sobi kellaaeg, IP ega
Testija
sündmust võimalik siduda loogiliselt isikukood. Sobib näiteks unikaalne ID, mis ei tohi olla
kokku. sessiooni ID, sest seda saaks logist välja lugeda ja
rünnakuks ära kasutada. Võib olla sessiooni ID räsi
koos transaktsiooni ID'ga.
Konkreetne lahendus tuleb kokku leppida
Tellija arhitektiga.
4.10 Andmete Logikirjes peab sisalduma piisavalt informatsiooni, et V V V Arendaja Testija
loomise/vaatamise/muutmise/kustutamise vastata küsimustele kes?, mida?, kus?, kust?, millal?,
Turvatestija
tegevused peavad olema kajastatud kuidas? ja tulemus.
logides. Logida tuleb ka päringud, mille Infoturbespetsialist
Konkreetne detailsus ja tehniline lahendus tuleb
vastus on puhverdatud.
kokkuleppida Tellija arhitektiga. Näiteks on mõistlik
luua audit teenus, mis annab vastavale rollile
võimaluse näha ja auditeerida tegevusi.
4.11 Administraatorite ja haldurite poolt Lahendus peab tagama, et administraatorid/haldurid ei V V V Arendaja Infoturbespetsialist
tehtavaid andmete vaatamised, saa andmete vaatamise, muutmise logimist ise (ka
Administraator Testija
muutmised sh kustutamised (ka otse tavakasutajate logimist) deaktiveerida või logisid
baasis) tuleb logida. Muutmise puhul kustutada/muuta.
tuleb logida nii uus kui ka vana väärtus.
Konkreetne detailsus ja tehniline lahendus tuleb kokku
leppida Tellija arhitektiga. Näiteks on mõistlik luua
audit teenus, mis annab vastavale rollile võimaluse
näha ja auditeerida tegevusi.
4.12 Süsteemsed logid ei tohi sisaldada Tulenevalt GDPRist ja logi sündmuse subjekti V V V Arendaja Arhitekt
otseseid isikuandmeid. õigustest, ei tohi logide igapäevane analüüsimine ja
Testija
jälgimine riivata sündmuse subjekti õigusi.
Turvatestija
Näiteks kasutada kasutaja nime ja tunnuse asemel
tema süsteemset ID'd. Lahendus peab sisaldama Infoturbespetsialist
võimalust ID ümberpööramist reaalseteks andmeteks.
Antud tegevus peab olema auditeeritav.
Konkreetne detailsus ja tehniline lahendus tuleb
kokkuleppida Tellija arhitektiga.
4.13 Kui parameetri väärtus on tühi, tuleb see Näiteks NULL V V Arendaja Testija
logis märkida asendusväärtusega.
4.14 Logis tuleb kõik mittekuvatavad (non- Näiteks reavahetused -> \n, non-printable sümbolid - V V Arendaja Testija
printable) sümbolid kodeerida. 0x00..0x1f, 0x7f..0xff.
4.15 Rakendus peab logima kõiki rakenduses Logi sisaldab minimaalselt vea tekkimise aega, V V V Arendaja Administraator
tekkivaid tehnilisi vigu. veakoodi, veakirjeldust (stack trace, traceback vms),
Testija
võimalusel kasutaja andmeid, HTTP-, GET- ja POST-
parameetreid ja nende väärtusi. Logimise
detailsusrežiimi (info, warning, errog, debug) peab
saama muuta.
4.16 Rakendus ei tohi X-tee päringuid V V V Arendaja Administraator
salvestada rakenduse logis. Logis peab
Testija
olema X-tee tunnus (ID), et saaks siduda
X-tee logiga.
4.17 Rakenduse funktsionaalsuse kirjeldusega Mida logitakse, kuidas sündmused on logis jagatud, V V V Arendaja Arhitekt
tuleb luua logimise dokumentatsioon ja logiridade näited.
Administraator
loginäidised. Koos funktsionaalsuse
arendamisega tuleb luua ka loodava Infoturbespetsialist
funktsionaalsuse logimine ja selle
dokumentatsioon. Dokumentatsioon peab
sisaldama logis kasutatud
klassifikaatorite kirjeldusi.
5. Testimine
5.1 Rakenduse kõik üleantavad versioonid Testitulemused tuleb edastada Tellijale koos rakenduse #12 V V V Arendaja Testija
peavad enne Tellijale üle andmist olema üleandmisega. Vaata lisaks nõuet 5.2 ja 5.3.
testitud.
Testid peavad olema käivitatavad Tellija pideva
integreerimise (CI) keskkonnas (nt Gitlab) ning olema
dokumenteeritud, kuidas teostada testide seadistamist
ja manuaalset käivitamist.
5.2 Lahendus peab olema minimaalselt 75% Käivitatakse Tellija pideva integreerimise (CI) #12 V Arendaja Arhitekt
ulatuses kaetud automaatsete keskkonnas (nt Gitlab) ja kaetust raporteeritakse
#35 Testija
komponenditestidega (unit test). lähtekoodi analüsaatoris (nt SonarQube).
5.3 Lahendus peab olema minimaalselt 50% Käivitatakse Tellija pideva integreerimise (CI) #12 V Arendaja Arhitekt
ulatuses kaetud automaatsete keskkonnas (nt Gitlab).
#33 Testija
vastuvõtutestidega.
5.4 Rakendusega peab olema kaasas skript Jõudlustestide täpne kirjeldus tuleb kokku leppida #12 V V Arendaja Arhitekt
jõudlustestide tegemiseks. detailanalüüsi käigus. Arendaja peab koos
#34 Administraator
rakendusega tarnima skripti ja vajalikud tarkvaralised
vahendid kokkulepitud jõudlustestide läbiviimiseks. Testija
Jõudlustestide läbiviimine ei tohi nõuda Tellijalt
omapoolset tarkvara arendamist, skriptide kirjutamist
või litsentside ostmist.
Jõudlustestid peavad olema käivitatavad Tellija pideva
integreerimise (CI) keskkonnas (nt Gitlab) ning olema
dokumenteeritud, kuidas teostada testide seadistamist
ja manuaalset käivitamist.
Konkreetne detailsus ja tehniline lahendus tuleb kokku
leppida Tellijapoolse testija esindajaga.
5.5 Testimine toodangu andmetega on Testimiseks tuleb luua vastavad andmekooslused, et V V Arendaja Arhitekt
keelatud. tagada tervik voo testimise võimekus.
Administraator
Testija
5.6 Enne lahenduse esmast tootesse Turbe testide teostamist ja tellimist koordineerib #9 V V Arendaja Arhitekt
lansseerimist peab olema teostatud Tellijapoolne testija esindaja. Samuti tuleb kokku
#10 Administraator
turbetestid ja seal välja toodud leppida põhimõtted, millistel juhtudel turbe testi tuleb
probleemid lahendatud. uuesti teostada. Testija
Parendused ja lahendused tuleb kokku leppida Tellija
arhitektiga.
6. Monitooring
6.1 Rakendusel peab olema masinloetav Testlehe kättesaadavus erinevatest arvutivõrkudest #16 V V Arendaja Arhitekt
tervise testleht (health check) JSON peab olema konfigureeritav. Testleht peab uuendama
Administraator
kujul. ennast lehe pärimisel. Testleht peab sisaldama custom
built rakenduse versiooni numbrit, standardsed
komponendid (veebiserver, andmebaas, CMS'id jms)
ei tohi oma versioone reeta. Samuti peab testlehel
olema infot rakenduse (vajadusel tema erinevate
osade) ja tema kõigi väliste liideste staatuse kohta
(töötab, ei tööta). Rakenduse, andmebaasi ja liideste
töökorda kontrollitakse testpäringute teel, mis tuleb
Tellija arhitektiga kokku leppida. Testleht peab oma
konfiguratsiooni võtma rakenduse üldisest
konfiguratsioonist (baasistring, välised ühendused).
Näiteks java Spring raamistiku puhul kasutada
actuatori võimekust.
6.2 Rakendusel peavad olema elususe ja Näiteks java Spring raamistiku puhul kasutada #16 V Arendaja Arhitekt
tööks valmiduse otspunktid. actuatori võimekust. Konteinerite orkestraatori kiht
Administraator
teostab nende järgi otsuseid. Antud lehekülgede
sisuline poole peab kajastuma ka tervise testlehel.
6.3 Rakendus peab pakkuma monitooringu Tuleb rakendada OpenMetrics spetsifikatsiooni. #16 V V Arendaja Arhitekt
lehte, kus leidub informatsioon
Monitooringu leht peab välja kuvama ka testlehel Administraator
rakenduse funktsionaalsuse toimimise
kuvatud komponentide olukorda.
kohta.
Näiteks kui testleht kuvab infot, et andmebaasi
ühendusega on probleeme, peab see kajastuma ka
monitooringu lehel. Monitooringu lehte kasutame
lahenduse jälgimiseks.
https://openmetrics.io/
7. Nõuded rakenduse lähtekoodile
7.1 Lähtekoodi kommentaarid peavad kõigis NB! Nõuet ei arvestata arendustarkvara poolt #2 V V Arendaja Arhitekt
lahenduse kihtides (rakenduse enda kood, automaatselt genereeritavate koodilõikude puhul –
andmebaas jne) olema kirjutatud inglise neid ei ole vaja tõlkida. Samuti ei rakendata nõuet
keeles. kolmandate osapoolte poolt toodetud lähtekoodile – nt
igasugu erinevad lahtise koodiga koodilõigud jms.
Kui tegu on olemasoleva süsteemi edasiarendusega,
siis peaks kommentaarides kasutama eelnevalt
kasutatud keelt.
7.2 Lähtekoodi genereeritud Rakenduse kood peab olema piisavalt hästi #2 V V Arendaja Arhitekt
dokumentatsioonid peavad olema selged, dokumenteeritud, et erialast haridust omav
arusaadavad ja sisuliselt kirjeldama tarkvaraarendaja on võimeline süsteemile
vastavat koodi, mille juures nad on. jätkuarendusi teostama.
Lähtekoodist genereeritava
Rakendama peab dokumenteerimisel
dokumentatsiooniga tuleb katta kõik
programmeerimiskeele parimaid praktikaid.
avalikud (public) meetodid ja
funktsioonid. Näiteks tarkvara, mis on kirjutatud Java keeles, peab
kasutama javadoc põhimõtteid ja võimekust.
7.3 Muutujate, tüüpide ja funktsioonide Tuleb rakendada Clean Code põhimõtteid. Kui #2 V V Arendaja Arhitekt
nimed peavad olema sisulised ja andma muutuja nimetus vajab kommentaari, siis pigem muuta
aimu nende otstarbest. muutuja nimetust kommenteerimise asemel.
Näiteks muutujate nimed peavad olema selged ja
arusaadavad.
Hea näide muutujast: elapsedTimeInDays
Halb näide muutujast: etid
7.4 Koodis kasutatavad konstandid ja Nt Javas identifikaator --> ID V V Arendaja Arhitekt
lühendid tuleb kirjutada suurte tähtedega,
lähtudes kasutatava
programmeerimiskeele parimast
praktikast.
7.5 Koodis kasutatavaid konstante ei tohi V V Arendaja Arhitekt
selle kasutamise kohta väärtusena
hardcode'da – need tuleb defineerida
muutujatena ja kasutada läbi nende.
7.6 Koodis defineeritud andmetüübid peavad N:Isik; Menetlus; jne. Andmebaaside V V Arendaja Arhitekt
olema nimetava käände ainsuses. Kõik struktuurikirjeldustes/andmemudelis ei tohi kasutada
andmemassiivid tuleb nimetada nimetava täpitähti.
mitmuses (st igasugu collectionid, arrayd,
jms).
7.7 Andmetabelites sisalduvad võõrvõtmed Kasutada tuleb konkreetse andmebaasisüsteemi V V Arendaja Arhitekt
peavad nime järgi seostuma tabeli ja nimetamise parimaid praktikaid. Nt kui tegu on
väljaga millele need viitavad. tabelitega ’Isikud’ ja ’Autod’, siis seos ’isiku autod’
oleks: Isikud.ID=Autod.Isik_ID
7.8 Andmebaasi väljade pikkused tuleb Selle asemel, et eraldada väljale x baiti, tuleb eraldada V V Arendaja Arhitekt
kirjeldada sümbolites, mitte baitides. x tähemärki. (Instead of allocating x bytes of storage
for the field, x chars of storage must be allocated).
7.9 Kui kokku pole teisiti lepitud, siis https://google.github.io/styleguide/ V Arendaja Arhitekt
rakenduse kood peab olema kirjutatud
Kui tarkvara keelel puuduvad Google stiili juhised,
vastavalt Google stiili juhendile.
siis tuleb need kokku leppida Tellija arhitektiga
enne kodeerimist.
7.10 Koodi valideerimiseks kasutatakse Üleantavas koodis ei tohi olla kriitilisi ja kõrgemaid #10 V V Arendaja Arhitekt
minimaalselt Tellija lähtekoodi probleeme.
#40
analüsaatorit.
IT profiil: Lähtekoodi analüüs
7.11 Kasutuses mitteolev kood tuleb Erandina on lubatud koodi osad, mis on valmis tehtud, V V Arendaja Arhitekt
rakenduse lähtekoodist kõrvaldada. aga ei ole veel kasutusse rakendatud ja on peidetud nn.
funktsionaalsuste lippude (feature flag) taha.
7.12 Arendamisel kasutatakse DRY ja SOLID http://en.wikipedia.org/wiki/Don%27t_repeat_yourself V V Arendaja Arhitekt
printsiipe. http://en.wikipedia.org/wiki/SOLID_(object-
oriented_design)
7.13 Üleantavas koodis ei tohi olla paroole, Kehtib ka siis, kui need on välja kommenteeritud. #28 V V Arendaja Arhitekt
mida on kasutatud arenduse käigus. Kõik sellised paroolid tuleb asendada fraasiga
#63
“<password>“.
7.14 Üleantavas koodis ei tohi olla Kui CVE ei ole lahenduses rakendatav ehk tegu on #10 V V Arendaja Arhitekt
komponente, mille CVSS punktid on 7 ja lahenduse mõistes vale-positiivsega, siis võib
kõrgemad ning CVE on rakendatav. komponendi uuendus lükkuda edasistesse etappidesse.
Eeldusel, et tegu ei ole viimase üleantava tarne
versiooniga. Partneri viimane üleantav versioon peab
olema turbevigade vaba.
Mõistlik on kõik CVE'd omavad komponendid
uuendada või välja vahetada. Ajas võib mitme
madalama punkti koosmõjul avalduda kriitiline
turbeprobleem.
7.15 Üleantava lahendusega peab olema SBOM ehk tarkvara materjalide loend. Mõistlik on V V Arendaja Arhitekt
kaasas viis SBOM genereerimiseks. SBOM genereerimine viia üheks järjepideva
integratsiooni voo sammuks.
SBOM publitseerimine ja analüüsimine tuleb kokku
leppida Tellijapoolse arhitektiga.
https://www.sbom.com/
7.16 Tehniliste komponentide API'del Näiteks REST API'de puhul kasutada OpenAPI #20 V Arendaja Arhitekt
eksisteerib automaatselt genereeritud spetsifikatsiooni.
dokumentatsioon.
https://www.openapis.org/
8. Andmekvaliteet
8.1 Andmekorjel kasutatakse Vabatekstivälju tuleb vältida. #61 V V V Arendaja Arhitekt
klassifikaatoreid ja loendeid, kus need on
Testija
olemas.
8.2 Tekstiväljad on mõistliku suurusega. Varchar N tähemärki, kus N on ratsionaalne kaalutlus, V V Arendaja Arhitekt
kui suur lahter võib olla; vältida text/long-varchar
kasutust, kui see pole hädavajalik.
8.3 Rakendus peab automaatselt eeltäitma Välja arvatud logimisvormi lahtrid autentimisel. V V Arendaja Testija
kõik võimalikud andmeväljad, kui need
Näiteks: kirje sisestamise kuupäev, kasutaja nimi,
andmed on varem riigile esitatud või kui
sünnikuupäev jne
nende väärtused on võimalik
automaatselt arvutada.
8.4 Lahenduses peab olema tagatud Kasutaja sama tegevuse kordamisel ei tohi tekkida V V Arendaja Arhitekt
idempotentsus. lahendusse andmeid topelt.
Testija
Näiteks "salvesta" nupu korduval vajutusel ei tohi
tekkida dubleeritud andmeridu.
8.5 Analüüsi tulemusena ja enne esimese Peab olema dokumenteeritud projekti põhi #58 V Arendaja Arhitekt
arendusetapi algust peab infosüsteemi dokumentatsiooni juures. Dokument tuleb hoida
kohta olema koostatud kontseptuaalne ajakohane.
andmemudel olemi-suhte diagrammi
(Entity Relationship Diagram, ERD) või
klassidiagrammina olemite ja nende
semantika kirjeldusega: teenuse nimi ja
selle ärilne kirjeldus, tabeli nimi ja selles
talletatavate andmete semantika ehk
äriline kirjeldus.
8.6 Enne igat arendusetapi algust peab Peab olema dokumenteeritud projekti põhi #58 V Arendaja Arhitekt
infosüsteemi kohta olema koostatud dokumentatsiooni juures. Dokument tuleb hoida
loogiline andmemudel ehk olemi-suhte ajakohane.
diagramm (ERD) koos kirjeldusega:
skeemi ja olemite ehk tabelite nimi ja
semantika, atribuutide ehk tabeli
veergude kirjeldus, sh primaar- ja
välisvõtmete kirjeldus: veeru nimi,
andmetüüp, kohustuslik või
mittekohustuslik (NULL/ NOT NULL),
semantika ehk andmete tähendus.
8.7 Füüsiline andmemudel peab iga Igal skeemil, tabelil ja veerul on kommentaar #58 V Arendaja Arhitekt
iteratsiooni lõpus või tarne tähtajaks selle andmekirjeldusega, mis vastab loogilise andmemudeli
iteratsiooni või tarne ulatuses sisaldama kirjeldusele.
lisaks ajakohasele kontseptuaalsele ja
loogilisele andmemudelile ka
andmekirjeldusi andmebaasis.
9. Kasutajaliides
9.1 Kasutajaliidese kõik disainiotsused V V V Arendaja Projektijuht
peavad olema kooskõlastatud Tellijaga
enne nende realiseerimist.
9.2 Veebipõhine kasutajaliides peab olema Minimaalselt Microsoft Edge, Mozilla Firefox, V V V Arendaja Testija
kasutatav enamlevinud Chrome ja Safari arenduse testimise hetkel tootja poolt
veebibrauseritega, sh nutiseadmetel toetatud versioonid.
(Android, IOS).
Täpsemad nõuded dokumendis "Front-end
arendusreeglid".
9.3 Rakenduse värviskeemi ja logo Kui tegemist on struktuurfondide projektiga, on lisaks V V Arendaja Testija
kasutamine peab vastama Tellija nõutud ka vastav SF sümboolika. Tellija ametlikud
ametlikule visuaalsele identiteedile (CVI) CVI esitluspõhjad, logo kasutusjuhend ja kõik logod
ja disainijuhistele (UIG). (ka jpg-na) küsida Tellijalt.
9.4 Kasutajaliidese kõik osad ja teated Kui soovitakse juurde eraldi ka muid keeli, siis see on V V V Arendaja Testija
peavad olema eestikeelsed. spetsifitseeritud hankedokumentides.
9.5 Sisemiseks kasutamiseks tehtav Toetatud peavad olema töökohaprofiilis loetletud V V Arendaja Testija
rakendus peab olema graafiliselt resolutsioonid.
skaleeruv ja mugavalt kasutatav
Ühegi nimetatud resolutsiooni korral ei tohi tekkida
Tellija töökohaprofiilis loetletud
horisontaalset kerimisriba.
resolutsioonides.
9.6 Kasutajaliideses toiminguni (põhi- ehk Kõik rakenduse kasutajaliidesest tehtavad toimingud V V Arendaja Testija
enamkasutatavad tegevused) tohivad üksteisest olla maksimaalselt 3 hiirekliki
navigeerimiseks peab kehtima 3 kliki kaugusel. Toimingut ei pea nende 3 klikiga tehtud
printsiip, väljalogimiseks 1 kliki saama. Väljalogimise nupp/link peab olema ühe kliki
printsiip. kaugusel ja arusaadavas/intuitiivses kohas.
9.7 Kasutajaliides peab alati küsima V V V Arendaja Testija
kinnituse andmete kustutamise ja
massmuutmiste kohta kui just teisiti
kokku pole lepitud.
9.8 Rakenduse kasutamisel tekkinud veale Veateated peavad olema sellised, mis võimaldavad IT- V V V Arendaja Testija
peab kasutajaliides vastama kasutajale abil võimalikult lihtsalt tuvastada vea olemuse ja
eestikeelse kasutajasõbraliku veateatega, asukoha.
mis sisaldab ka vea koodi. Veateated
peavad olema hallatavad.
9.9 Kasutajaliides peab olema ilma Uue keele lisamine peab olema teostatav V V Arendaja Testija
rakenduse koodi muutmata tõlgitav teise konfiguratsiooni failist või administreerimisliidesest.
keelde, v.a kui ei ole teisiti kokku lepitud.
Konkreetne lahendus tuleb kokku leppida
Tellija arhitektiga.
9.10 Rakenduse kasutajaliides peab teavitama Etteteavitamise aeg peab olema konfigureeritav. V V V Arendaja Administraator
kasutajat ette sessiooni aegumisest.
Testija
9.11 Kui vormile sisestatakse mahukaid Näiteks kui vorm koosneb paljudest väiksest V V Arendaja Testija
andmevälju, peab kasutajaliides kokku andmeväljadest (nt taotlus), siis jagatakse vorm
lepitud ajavahemike järel salvetama välja etappideks ning salvestatakse vastava etapi lõpus.
sisu, et sessiooni aegumisel või võrgu
katkestuse korral juba sisestatud andmed
ei kaoks.
9.12 Interaktiivsete vormide puhul (näiteks V V Arendaja Testija
faili üleslaadimine) ei tohiks lehe
värskendamisega tegevust korrata (faili
taas üles laadida, andmeid saata, avaldust
esitada).
9.13 Esilehel (sisselogimata) ja pärast kasutaja Näiteks võimalikud teavitused: mingi süsteemi osa on V V Arendaja Testija
sisselogimist peab olema lihtne võimalus vigane, tuli mingi uus funktsionaalsus, hetkel on
teavitada kasutajat muudatustest või hooldus, uuendage isikuandmeid jne.
probleemidest. Teavitus peab olema
Mõistlik on hooldusteate võimekiust juhtida
halduri poolt lihtsasti lisatav ja kasutajale
taustteenuse abil. Näiteks läbi esitluskihi jaoks loodud
märgatav.
seadete REST liidese.
10. Dokumentatsioon
10.1 Lõppkasutajatele ja avalikkusele Erandiks võivad olla kolmanda osapoole V V Arendaja Projektijuht
suunatud rakenduse dokumentatsioon komponentide (mis pole kirjutatud Tellija jaoks)
Arhitekt
peab olema kirjutatud eesti keeles. dokumentatsioon. Samuti võib erandiks olla väliste
osapooltega seotud projektid. Erandid tuleb Administraator
kooskõlastada Tellijaga enne dokumentatsiooni
koostamist. Testija
Infoturbe
spetsialist
10.2 Lahendus kirjeldatakse RIHA määruse https://www.riigiteataja.ee/akt/12933746? #57 V Arendaja Projektijuht
nõuete kohaselt. leiaKehtiv#para6
Projektijuht
Tellija RIHA
haldur
10.3 Rakenduse dokumentatsioon peab Dokumentatsioon peab olema versioneeritud, V V Arendaja Projektijuht
vastama dokumendis "Nõuded muutmiskuupäevadega, autori nimedega, korrektse
Arhitekt
infosüsteemi dokumentatsioonile" keelekasutusega, selge struktuuriga.
kirjeldatud nõuetele. Dokumentatsiooni detailsus peab olema piisav, et Administraator
sõltumatu kolmas tehnliste IT baasteadmistega isik
suudaks dokumendist vajalikke järeldusi teha (st Testija
dokument peab olema arusaadav sellele isikule, kuid
Infoturbe
näiteks paigaldusjuhise järgi toimetades ei pea ta
spetsialist
ebaõnnestunud tarnele teostama veaanalüüsi).
Täpsemad nõuded dokumendis "Nõuded infosüsteemi
dokumentatsioonile".
10.4 Rakenduse dokumentatsioon peab Esialgne kirjete mahu hinnang peab tulema V V Arendaja Projektijuht
sisaldama tabelite-andmete-logide mahu lähteülesandest, ning täpsustuma eel- ja detailanalüüsi
Arhitekt
kasvu arvestuslikku hinnangut rakenduse käigus. Mahuhinnang peab sisaldama ka logide
sihipärase kasutamise korral ettenähtud säilitamise, arhiveerimise tähtaegu. Administraator
arvu kasutajate poolt. (MB/GB
kuus/aastas). Infoturbe
spetsialist
10.5 Iga uue versiooniga peab alati välja Release notes peab kajastama kõiki muudatusi eelmise V V V Arendaja Projektijuht
tooma versiooni muudatuse kirjeldused ja uue versiooni vahel.
(release notes).
10.6 Arendaja loodud lahenduse V V Aremdaja Arhitekt
dokumentatsioonis (nt detailanalüüs vms)
Administraator
tuleb välja tuua kasutatavad krüpto- ja
räsialgoritmid, nende võtmepikkused,
kasutuskohad, sh TLS sertifikaatide
kasutuskohad.
11. Versioonihaldus
11.1 Kogu rakenduse testimiseks, koolituseks Arendajale antakse selleks õigused Tellija #1 V V Arendaja Arhitekt
või implementeerimiseks üle antav versioonihalduse repositooriumi, kus ta peab hoidma
Administraator
lähtekood ja tarkvarapaketid peavad oma erinevaid versioone. Versioonihalduse
olema versioneeritud. Kasutama peab repositooriumi juurdepääsutaotlus esitatakse Tellija
Tellija versioonihalduse ja tehiste kasutajatoele läbi projektijuhi.
(artifaktide) repositooriumi.
11.2 Arendaja peab veenduma, et teeb Hea tava on, et paralleelse arendamise puhul võetakse V V Arendaja Arhitekt
muudatusi aktuaalsesse koodi. igal hommikul versioonihalduse repositooriumist
Administraator
viimane seis koodist.
11.3 Nii arendamisel kui ka hoolduslepingute Arendajale antakse selleks õigused Tellija tööde ja V V Arendaja Projektijuht
korral kasutatakse Tellija tööde ja veahalduse keskkonda.
veahalduse keskkonda.
Veahalduse keskkonda juurdepääsutaotlus esitatakse
Tellija kasutajatoele läbi projektijuhi.
11.4 Versioonihaldusesse muudatuste https://www.conventionalcommits.org/ V Arendaja Arhitekt
üleslaadimisel kasutada
üleslaadimissõnumis Conventional
Commits stiili.
12. Paigalduspaketi kooste
12.1 Rakendus on versioneeritud kasutades A.B.C kujul, kus C on veaparandus, B on #15 V Arendaja Arhitekt
semantilise versioneerimise põhimõtet. funktsionaalne uuendus, mis töötab ka vanematel
Administraator
integratsioonidel ja A on integratsioone potentsiaalselt
lõhkuv uuendus.
Versiooni suurt numbrit A kasutatakse ka API
versiooni defineerimiseks.
Lisasoovitus: Kui major versioon saab uuenduse, siis
peavad vanema versiooniga teenused hakkama
tagastama päises teavitust, et versioon on deprecated
(nt. X-API-Deprecated).
https://semver.org/
12.2 Juhul kui versioonihalduse keskkond ei Räsialgoritmiks tuleb kasutada SHA256. Linuxi V V Arendaja Administraator
paku paigalduspaketile kontrollsumma käsurealt kontrollkoodi koostamiseks: $ sha256sum
(checksum) automaatset koostamist, siis filename [filename2] ... > kontrollkood.sum.
koostatakse kontrollsumma arendaja
poolt ja pannakse eraldi .sum failina
tarnele kaasa.
12.3 Tarnitava lahenduse koosseisus üleantava Näiteks võib lahenduse paigalduspaketi koosteprotsess V V Arendaja Projektijuht
lähtekoodiga peavad kaasas olema ette näha, et käivitada tuleb rida shell-käske või
Administraator
kirjeldused sellest paigalduspaketi võivad lahenduse koosseisus olla valmis (ant, ..)
koosteks. koosteskriptid või mistahes muu moodus
paigalduspaketi tekitamiseks.
Eelistatud on kasutada Dockerfile ja Gitlab töövooge.
12.4 Kooste kirjelduste alusel valmiv Näiteks: kompileeritavate keelte puhul ei tohi V V Arendaja Arhitekt
paigalduspakett tohib sisaldada ainult sisaldada lähtekoodi, kui see pole vajalik rakenduse
Administraator
minimaalse rakenduse käitamiseks käitamiseks.
vajamineva failikomplekti.
12.5 Kooste kirjelduste alusel valmivat Näiteks ei tohi tekitada olukorda, kus rakenduse V V Arendaja Administraator
paigalduspaketti peab olema võimalik jooksutamiseks uues serveris tuleb see tingimata just
liigutada erinevate masinate vahel. sealsamas kokku kompileerida.
12.6 Rakenduse kõik sõltuvused peavad olema #4 V V Arendaja Arhitekt
kompileerimisel saadavad Tellija tehiste
repositooriumist.
12.7 Andmebaasi paigalduse skriptid ei tohi Administraator tahab veenduda skripti sisus. V V Arendaja Administraator
olla kompileeritud.
12.8 Rakenduse lähtekoodi juures peab Tellijal peab olema võimalik suuri pingutusi tegemata V V Arendaja Arhitekt
leiduma skriptid rakenduse keskkonnast ja keskkonna erinevusi vältides teha rakendusest
sõltumatult (konteinerlahenduses) kokku paigaldatav pakk.
kompileerimiseks.
12.9 Rakenduse lähtekoodi juures peab Vajadusel peab konteinerlahendus käivitama ka V V Arendaja Arhitekt
leiduma skriptid rakenduse lokaalselt rakenduse muud sõltuvused (näiteks andmebaas).
mõnes konteinerlahenduses (Docker) See on Täitjale uue meeskonnaliikme liitumise
käivitamiseks. lihtsustamiseks ja Tellijale võimalus suuri pingutusi
tegemata süsteemi testimiseks.
12.10 Paigalduspakett koostatakse Tellija #13 V V Arendaja Arhitekt
pideva integratsiooni (continuous
integration - CI) ja paigaldus (continuous
deploy - CD) arendus keskkonnas.
12.11 Kubernetesel (K8s) orkestreeritavate https://helm.sh/ V V Arendaja Arhitekt
lahenduste paigalduste jaoks tuleb luua
Helmi jaoks kasutatava malli annab Tellijapoolne Arhitekt Administraator
Helm chart.
arhitekt.
12.12 Kubernetesel (K8s) orkestreeritavate https://kubernetes.io/docs/tasks/run- V V Arendaja Arhitekt
lahenduste paigalduste jaoks tuleb luua application/horizontal-pod-autoscale/
Arhitekt Administraator
vajalikud automaatsed laienemise
reeglid.
„Andmeladude olemus ja selle funktsioonid“
Selgitav juhis
Majandus- ja Kommunikatsiooniministeerium
14.04.2023
1 / 21
Sissejuhatus ................................................................................................................................ 3
1. Andmeladude olemus ............................................................................................................. 4
1.1. Isikuandmed ja anonüümitud andmed andmelaos ........................................................... 5
1.2. Primaarandmekogu ehk operatiivbaas ja andmeladu ...................................................... 8
1.3. Millest tuleks andmeladude reguleerimisel lähtuda ...................................................... 11
1.3.1. Andmeladu on olemuslikult andmekogu osa, selle reguleerimisvajadus ............... 11
1.3.2. Andmete säilitamine andmelaos ............................................................................. 13
1.3.3. Autoriseerimine, andmete struktureerimine, logid ja muud nõuded ....................... 14
1.3.4. Andmeladu teenindab mitme asutuse andmekogu, selle reguleerimisvajadus ....... 14
2. Kokkuvõte andmelao reguleerimise vajalikkuse osas .......................................................... 17
3. Korduma kippuvad küsimused ............................................................................................. 18
3.1. Kas andmelaost võib „teenindada“ teisi andmekogusid? .............................................. 18
3.2. Kas X-teel võib andmeid vahetada vaid riigi infosüsteemi kuuluvate andmekogude
vahel? .................................................................................................................................... 18
3.3. Mis vahe on andmekogul ja infosüsteemil? Miks vormistada infosüsteemi põhimäärus?
.............................................................................................................................................. 19
3.4. Kas põhiandmeid võiks võtta ka teisest andmekogust, mitte sealt kus need algselt
tekivad? ................................................................................................................................. 20
3.5. Kas ühe andmekogu juurdepääsuhaldust saab kasutada ka teise andmekogu
juurdepääsuhalduse tagamiseks? .......................................................................................... 20
3.6. Kas ühe andmekogu sees peavad andmed liikuma X-tee vahendusel - näiteks andmete
liigutamine andmekogu erinevate kihtide või operatiivbaasi ja lao vahel? .......................... 21
3.7. Mis on andmelao ja -järve vahe lihtsustatult? ............................................................... 21
2 / 21
Sissejuhatus
Aeg-ajalt on tõusetunud vaidlused, et millised andmed andmelaos olla võivad, kas andmelaost
võib „teenindada“ teisi andmekogusid jne. Seda just isikuandmeid sisaldavate andmetöötluste
kontekstis. Seega peaks käesolev juhis tagama selle, et edaspidi on andmekogusid puudutavad
arendused ja õigusloome selgem ning sellega seotud ebakõlasid vähem. Eesmärk on
ühtlustada andmeladudega seonduv tehniline ja õiguslik raamistik.
Juhis on kõige kiirem viis ühtsete arusaamade kujundamiseks. Käesolev juhis keskendub
andmelao olemusele ning püüab selgitada selle kasutusjuhtusid. Juhist saab edaspidi
täiendada, see on ajas muutuv.
Käesolev juhis kinnitab kokkuvõttes neli peamist järeldust, millest juhises ka pikemalt juttu
tuleb:
1. Andmelaos võivad olla nii isikustatud kui isikustamata andmed.
2. Andmelaost võib andmeid õigusliku aluse olemasolul väljastada kolmandale
osapoolele (isikustatult kui isikustamata andmetena).
3. Andmekogu osaks olevasse andmelattu võib andmete laadimiseks kasutada turvalisi
kanaleid ja mitte ainult X-teed.
4. Andmelao mõistet ei tule seaduses defineerida, sellel puudub eraldi väärtus.
5. Andmelao reguleerimine andmekogu põhimääruses ei ole otseselt vajalik, kui
andmeladu toetab andmekogu pidamist andmekogule kehtivate reeglite kohaselt,
küll võib sellele viitamine tagada teatud juhtudel andmekogu kontekstis parema
õigusselguse ning anda realistliku pildi andmekogus toimuvast. Eraldi reguleerimine
on vajalik siis, kui soovitakse teha teatud erandeid.
Tausta selgitamiseks on oluline mainida, et Andmekaitse Inspektsioon (AKI) viis 2021. aastal
läbi andmeladusid puudutava küsitluse (andmeladude seire).1 Seire vastused ei andnud kindlust,
et teabevaldajatel oleks selge arusaam, kuidas andmeladusid pidada ja milliseid hoolsusnõudeid
järgida.2 Tingituna eelnevast lepitigi 2022. aasta esimeses kvartalis valitsuse tasandil kokku
analüüsida täiendavalt andmeladusid puudutavaid järeldusi ja töötada välja andmelao
loomise ja selles isikuandmete töötlemise reeglid, vajaduse korral näha ette asjakohased
seadusemuudatused.
Käesolev juhis on koostatud järgmiste asutuste koostöös: Andmekaitse Inspektsioon,
Justiitsministeerium, Siseministeerium, Sotsiaalministeerium, Haridus- ja Teadusministeerium,
Riigikantselei, Statistikaamet, Politsei- ja Piirivalveamet, Päästeamet, Rahvusarhiiv, Riigi
Infosüsteemi Amet, Tervise ja Heaolu Infosüsteemide Keskus, Siseministeeriumi
infotehnoloogia- ja arenduskeskus, Keskkonnaministeeriumi Infotehnoloogiakeskus, Maa-
amet, Rahapesu Andmebüroo, Keskkonnaagentuur.
Täname kõiki juhise koostamisse panustanud asutusi.
1
Vt lisamaterjali: AKI dokumendiregister, 28.06.2021 nr 2.3.-3/21/2278,
https://adr.rik.ee/aki/dokument/10349149
2
Andmekaitse Inspektsioon. Andmeladude seire kokkuvõte,
https://www.aki.ee/sites/default/files/seired/andmeladude_seire_kokkuvote.pdf
3 / 21
1. Andmeladude olemus
Õigusruumis ei ole üheselt reguleeritud (ei avaliku teabe seaduses ehk AvTS-is,3 ega teistes
Euroopa Liidu õigusaktides) andmelao/-aida või andmejärve mõisteid, ometi neid praktikas
kasutatakse. Andmeladusid kasutatakse sageli igapäevaste ja operatiivsete äriotsuste ja
protsesside tegemiseks ja seda struktureeritud andmetega. Andmejärvi kasutatakse suurte
andmemahtudega ja korrastamata andmetena (nn andmete soo). Seega leiab käesolevas juhises
andmekogude kontekstis kajastamist just andmeladude teema, sest andmekogudesse kogutakse
ja neis töödeldakse just struktureeritud ehk korrastatud andmeid.4 Juhises selgitatakse andmelao
(siin all ka andmeaida) olemust läbi praktiliste näidete ja tuuakse seisukoht, kas see vajaks
eraldi reguleerimist ja kui jah, siis millistel juhtudel.
Eesti õigusruumis on andmeladu või -aita reguleeritud üksikutel juhtudel. Õigusruumist võib
tuua näiteid andmeladude kohta ja neis töödeldakse andmeid viisil, kus isik otseselt tuvastatav
ei ole (näiteks tervise infosüsteemi põhimäärus (vt § 14) 5 või ka sotsiaalteenuste ja -toetuste
andmeregister (vt § 3 lg 3)) 6. See ei tähenda, et andmelaos võikski töödelda andmeid vaid
sellisel kujul. Lisaks ei ole paljude andmekogude juures andmeladu eraldi kirjeldatud, kuigi
praktika näitab, et andmelao funktsionaalsust kasutatakse ja töödeldavateks andmeteks on nii
isikustatud kui isikustamata andmed (nii tuleb välja ka inspektsiooni seire küsimustikule antud
vastustest). Siit ongi tõusetunud küsimus, et kas andmelao kasutus on midagi lubamatut, kui a)
seda ei ole eraldi reguleeritud või kui b) selles töödeldakse näiteks isikuandmeid.
Üldiselt võib kohe öelda, et andmeladu on selline infosüsteemi komponent (eraldi osa,
andmebaas), mis on optimeeritud päringute ja ärianalüüsi jaoks. Isikustatud või
isikustamata andmed ei ole andmelao eristav või oluline tunnus. Täpsemalt, andmelaos nagu
igasuguses infosüsteemis, on selgelt eristatav tehnoloogia kiht (funktsionaalsus, mida tehakse)
ja andmete kiht (millega tehakse). Andmete vaatest on oluline mõista, et anonüümne vs
isikustatud andmete töötlus sõltub asutuse vajadustest ja õiguspärasusest (st kas asutusel
on lubatud sellist andmetöötlust teha), seega on see asutuse enda otsustada ning
tehnoloogia kiht siin otsustust ei piira.
Meelespea:
✓ Kokkuvõttes on käesolevast oluline meeles pidada, et tehnoloogia kiht ehk
funktsionaalsus näitab, mida on võimalik teha ja andmete kiht näitab, milliseid
andmeid selles töödeldakse.
✓ Andmete kuju - anonüümne vs isikustatud - sõltub asutuse vajadustest ning
õiguspärasusest ja tehnoloogia kiht (lao funktsionaalsus) seda kuidagi ei piira.
3
Avaliku teabe seadus (AvTS), https://www.riigiteataja.ee/akt/106082022020
4
AvTS § 431 lg 1: „Andmekogu on riigi, kohaliku omavalitsuse või muu avalik-õigusliku isiku või avalikke
ülesandeid täitva eraõigusliku isiku infosüsteemis töödeldavate korrastatud andmete kogum, mis asutatakse ja
mida kasutatakse seaduses, selle alusel antud õigusaktis või rahvusvahelises lepingus sätestatud ülesannete
täitmiseks.“ Täpsem selgitus on toodud läbi näidete juhise alapunktis 3.7.
5
Vabariigi Valitsuse 1.12.2016 a määrus nr 138 „Tervise infosüsteemi põhimäärus“,
https://www.riigiteataja.ee/akt/103082022004#para14
6
Sotsiaalkaitseministri 27.12.2017 a määrus nr 72 „Sotsiaalteenuste ja -toetuste andmeregistri põhimäärus“,
https://www.riigiteataja.ee/akt/117082022009#para3
4 / 21
1.1. Isikuandmed ja anonüümitud andmed andmelaos
Andmeladu võib täita pelgalt statistilist/analüütilist funktsiooni, aga selles võivad sisalduda ka
isikuandmed. Andmelao tehniline ülesehitus ja selles töödeldavate andmete kuju sõltub
eesmärgist, mida see komponent andmekogu juures tagama peaks. Seega on nii isikustatud
kui ka isikustamata andmete töötlus andmelaos sisuliselt lubatud.
Näitena võib tuua, et kui andmekogus on isikuandmed ja andmekogule seadusega kehtestatud
eesmärgid on seotud isikuandmete töötlemisega, täidab andmeladu andmekogu põhifunktsiooni
ja on enamasti isikustatud, et andmeid omavahel ühitada. Nii näiteks võib „andmelao“
nimetuse all pidada keskkonda, mis andmekogule esitatud alusdokumendid kindlast formaadist
„lahti pakib“ ja eraldi andmeteks teeb (dokumente ei saaks sellisel viisil ühitada, andmeid saab).
Sellise näite puhul on see keskkond selleks, et andmekogu eesmärke üldse täita saaks, tehes
seda tänapäevasel moel. Nii tuleb andmete ühildamiseks viia need samale kujule. Mõlemad nn
filtrid – nii alusdokumendid kui neist „lahti võetud andmed“ - on selle sama andmekogu
olemuslikud osad - mõlemad tehnilised „kihid“ kuuluvad andmekogu juurde ja on vajalikud
õigusaktides seatud eesmärkide täitmiseks. Nii näiteks ei tule lugeda andmekogu kasutamisel
mitte tervikdokumente, vaid saab vaadelda andmeid reastatult, grupeeritult vm viisil. Enamasti
sisaldavad digitaalsed andmekogud neis hõlmatud süsteemides erinevaid otsinguid, andmete
koondvaadet jms.
Kindlasti on oluline mainida, et sama andmelao pinnalt võib olla võimalik luua erinevaid
tasandeid või nn kihte, kus ühele isikule on see pseudonüümitud, teisele anonüümitud andmete
vaade. Viimane tähendab seda, et ka kaudse tuvastuse risk on välistatud. Loomulikult tuleks
lähtuvalt isikuandmete kaitse üldmääruse (IKÜM) põhimõtetest7 rakendada ka igapäevase
töölaua funktsionaalsuses tehnilisi meetmeid, et andmete analüüsimisel ei vaadeldaks
isikustatud andmeid, kui see pole konkreetse ülesande täitmiseks otseselt vajalik. Võimalik, et
seda rolli täidabki andmeladu või üks osa selle funktsionaalsusest, kus dokumendid on nö
„teisendatud“ andmeteks ja neid andmeid saab mugaval viisil töödelda, pseudonüümida ja
hägustada. Näiteks kui andmeladu peetakse haldusülesande täitmiseks, siis eeldatakse andmete
õigsust ja sedagi, et haldusorgan teab, kelle osas menetlust läbi viiakse – näiteks sai haldusorgan
isiku kohta teavituse ja just tema osas tuleks rakendada ka jätkutegevusi (toimub haldusorgani
sisuline töö). Tegevused, kus isiku nimi ei ole relevantne (näiteks piirkondlik ohuhinnang),
piisaks ka hägustatud andmetest, kus isikute nimed või muud isikut tuvastada võimaldavad
andmed ei ole kogu töötluse juures vajalikud ega olulised (mittevajalik nö peidetakse ja
töötlemiseks on avatud vaid vajalik andmestik). Andmeladusid võib olla ka mitu – üks näiteks
isikustatud, teine anonüümitud statistilise vaate jaoks. Ka see ei ole välistatud. Andmeladude
funktsionaalsus ja paljusus sõltub andmekogu andmete töötlemise eesmärkidest ja vajadusest.
Pseudonüümitud andmetel põhinev andmeladu on selline andmete kogumik, kus otseselt
isikustatud (nt isikute nimedega, elukoha aadressidega vms) andmetöötlus vajalik ei ole.
7
IKÜM artiklid 5(1) ja 25(1). Viimane sätestab selgelt, et arvestades teaduse ja tehnoloogia arengut ning nende
rakendamise kulusid ning andmete delikaatsust ja ulatust ja eesmärke, rakendab vastutav töötleja nii
töötlemisvahendite kindlaksmääramisel kui ka isikuandmete töötlemise ajal asjakohaseid tehnilisi ja
korralduslikke meetmeid, nagu pseudonümiseerimine.“, https://eur-lex.europa.eu/legal-
content/ET/TXT/?uri=celex%3A32016R0679.
5 / 21
Pseudonüümitud andmestik võib ühelt poolt olla andmete kogum, mida on võimalik
taasisikustada ehk nt nimeliselt isikustatud kujule tagasi viia - depseudonüümida. Kuid
pseudonüümitud andmed võivad olla ka juba algselt ainult mingi unikaalse ID-ga eristatavad
isiku tegevused (või tegevuste tulemil tekkivad andmed), ilma et nimeliselt üldse on võimalik
konkreetse isikuni jõuda8. Sõltuvalt andmete delikaatsusest või töötlemise eesmärgist võib
seadusandja isegi eraldi ette näha, et andmekogus tervikuna töödeldaksegi andmeid vaid
pseudonüümitult ning sätestada konkreetsed juhud, millal on depseudonüümimine lubatud.
Selline kaitsemeede eeldab muidugi seda, et andmekogu eesmärke saab selliste andmetega
saavutada (näiteks eriti tundlike andmete töötlemine ja kui eesmärgiks on seatud pigem teadus
ja innovatsioon9). Olukorras, kus tegemist on andmekoguga, mille eesmärgiks on seadusandja
sätestanud ka järelevalve tegemise, ei saa igapäevaseks tööks loodud keskkonda (mida võib ka
nimetada andmelaona) kasutada peamiselt pseudonüümitult. Sellisel juhul ühitatakse andmed
konkreetse isikuga sidumiseks, et seatud eesmärke just konkreetse isiku osas täita. Siis on
vajalik, et andmed oleksid just isikustatult. Tõsi, ka eelviidatud näites saab isikustatud
andmetega nö andmekogu ühes alamosas täita analüütika ja statistika vajadusi pseudonüümitud
andmetega või koguni anonüümituna (nii on see ka sissejuhatuses toodud andmekogude näitel),
ehk andmete vorm sõltub nii andmetöötlusele seatud eesmärkidest kui ka andmekogus
rakendatud funktsionaalsustest, sealhulgas rakendatud privaatsustehnoloogiatest (lähtudes
näiteks IKÜM-i artiklist 25 – lõimitud andmekaitse põhimõte).
Sõltumata sellest, kas andmeid hallatakse pseudonüümitult terves andmekogus või selle
alamosas, võib depseudonüümimine olla ilmselt vajalik nii andmete uuendamiseks ja
kontrollimiseks (andmete terviklus)10, kui muudelgi juhtudel. Kui statistikaks või
analüüsimiseks kasutatavate andmete puhul on andmete kontrollimine või nende kvaliteet
(täpsus) oluline, tulebki andmeid hallata pseudonüümituna. Seega on pseudonüümimine ja
depseudonüümimine kindlasti lubatud, kui andmete jada tekitab ebaloogilisi järelmeid ja/või
küsimusi ning andmeid depseudonüümib andmete kontrollimiseks vastutav või volitatud
töötleja (volitatud töötlejale on selline ülesanne delegeeritud). Samamoodi võib
depseudonüümimine olla seotud andmete kontrolliga sisemiste protsesside tarvis näiteks
turvalisuse ehk juurdepääsude kontrollimise kaalutlustel (näiteks logide kontroll selle kohta,
kes mida tegi ehk kuna midagi lisati või kustutati). Kontrollimise vajadus võib tõusetuda nii
andmesubjekti huvist lähtudes, kui ka järelevalve asutuse pöördumise tulemusel.
Anonüümsena mõistetakse andmeladu vaid siis, kui selles olevaid andmeid ei saa konkreetse
isikuga või tema tegevustega taas seostada ehk isikustatud kujule tagasi viia või näiteks tuletada
koos muude andmetega nende pealt muud konfidentsiaalset teavet (ärisaladus vms).
Anonüümitud vaade on tegelikult lõpptulemus, kus üks kiht ehk funktsionaalsus andmelaos
täidab sellist rolli, et hoida andmeid konstantselt ehk neid ei muudeta. Näitena võib tuua
olukorra, kus eesmärgiks ongi vaadelda statistilisi juhuarve ja mitte korduvust - isikuandmed
8
Sarnane olukord on näiteks veebiküpsiste puhul. Veebilehe pidaja ei tea (seda juhul, kui pole sisselogitud
kasutaja), kes nimeliselt arvuti taga on, kuid läbi küpsise omistatud unikaalse ID saab veebilehe pidaja eristada
erinevaid veebilehe külastajaid ja nende kasutusmustreid.
9
Vt näiteks inimgeeniuuringute seadus, § 24, https://www.riigiteataja.ee/akt/113032019064#para24
10
Andmete terviklus on andmete õigsus ja täielikkus. Vt küberturvalisuse seaduse § 7 lõike 5 alusel kehtestatud
ettevõtlus- ja infotehnoloogiaministri 16.12.2022. a määrus nr 101 „Eesti infoturbestandard“,
https://www.riigiteataja.ee/akt/121122022034. Varasemalt tulenes AvTS § 439 lõike 1 punkti 4 alusel
kehtestatud Vabariigi Valitsuse 01.01.2008. a määrusest nr 252 „Infosüsteemide turvameetmete süsteem“,
https://www.riigiteataja.ee/akt/115092020015.
6 / 21
tekivad üksikute kirjetena ja korduvus ei ole oluline (näiteks kogutakse isikute kohta andmeid
- meesterahvas, tema vanus, maakond ja mõni statistiline näitaja nagu haigestumine - andmeid
sama isiku kohta ei uuendata ehk taashaigestumist ei järgita ja andmeid ei kontrollita). Seega,
võivad andmelaos hoitavad andmed kindlasti olla ka anonüümitud andmed, kui konkreetse
asutuse andmekasutus ja andmelao ülesehitus on selline, et andmelattu edastataksegi
isikuandmeid ainult anonüümituna. Ka siin on võimalik kaitsemeetmena ära piiritleda, et
andmeladu ongi vaid anonüümitud statistiline andmestik ja sinna tohibki kanda vaid
anonüümitud andmeid (see oleks nö suuniseks ka volitatud töötlejale). Siinjuures on
andmekogu terviku mõttes oluline taas tuua, et see ei tähenda nagu ei oleks andmekogus endas
muid andmete kogumikke ehk andmeladu, kus algandmed „lahti pakitakse“ ja ühitatakse enne
anonüümitud andmelattu kandmist. Samas võivad need olla ka eraldi kambrid ühes andmelaos.
Nagu eelnevalt juba viidatud, siis võib andmekogu juures olla ladusid ka mitu – üks isikustatud,
teine pseudonüümitud või anonüümitud vaate jaoks, mille kasutajaskond on erinev (seda nii
asutuse siseselt kui väliselt, lähtudes õiguslikest alustest). Nii võib andmekogu terviksüsteemis
olla ka mitu paralleelselt paiknevat andmeladu ja nende eristamiseks võib neid ka erinevalt
nimetada. Samas võib olla süsteemi ülesehituses ka ühe isikustatud andmelao all omakorda
anonüümitud alamandmeladu. Seega erinevad andmeladude ülesehitus ja paiknemine
terviksüsteemis sõltuvalt konkreetse teabevaldaja vajadustest ning ühte ja õiget vastust siin olla
ei saagi. Nimetatud ülevaade esitatakse arhitektuurilises dokumentatsioonis, mis on riigi
infosüsteemi haldussüsteemi (nn RIHA-sse) esitatav materjal.11
Olukorras, kus andmelao andmeid näevad erinevad isikud teenuste raames anonüümsete
andmetena, kuid andmelao andmeid saab iga isiku kohta siiski algandmetes uuendada, on
tegemist ikkagi pseudonüümitud andmelaoga, sest andmelao pidaja saab andmeid kontrollida
ja vajadusel uuendada (näiteks eeltoodud näide meesterahva kohta, kus nüüd oleks eesmärk aga
siduda faktiline teave aasta lõikes sama meestrahvaga – näiteks nakatumiste korduvus ühe isiku
lõikes). Nii ei hinnata andmelao reguleerimisel mitte seda, kuidas kolmandad isikud
andmelao andmeid näevad, vaid seda, kuidas andmeladu ennast peetakse (näiteks kas
isikuandmed on anonüümitult ja need ei muutu ajas või uuenevad või täienevad need ajas sama
isiku kohta). Kui andmekogu haldaja (vastutav või volitatud töötleja) ise saab andmeid
uuendada, kontrollida ja taasisikustada, on õige rääkida ikkagi pseudonüümitud andmelaost ja
seejuures võib kolmandatele isikutele olla juurdepääs anonüümitud andmete vaatele
(andmekogu andmekasutuse juurdepääsude täpsustavas sättes saab sellele näiteks eraldi
viidata12).
Juhul, kui andmelao andmeid soovitakse kontrollida ehk teada, mida sinna teatud
anonüümimise tehnoloogiaid kasutades kanti ja kas need on ka õiged, ei ole andmeladu
anonüümitud kujul (see seisukoht võib tulevikus privaatsustehnoloogiate arenguga muutuda).
Anonüümimine ise võib toimuda kolmes kohas: a) algsüsteemis, b) andmete edastamisel
11
Vt Vabariigi Valitsuse 28.02.2008. a määrus nr 58 „Riigi infosüsteemi haldussüsteem“, § 18 lg 2 p 5 -
andmete üldandmeteks on ka andmekogu tehnilise kirjelduse dokumendid, kus sisalduvad andmekogu
arhitektuuri, talitlusprotsessi, koosvõime nõuetele vastavuse, haldamise reeglite kirjeldused ja muud olulised
andmekogu kohta käivad tehnilised kirjeldused ning andmekogu põhimäärus või selle kavand,
https://www.riigiteataja.ee/akt/106082019018#para18.
12
Vt nt tervise infosüsteemi põhimääruse § 14 normi, kus on toodud andmelao kasutamine, sh selle eesmärk, see
kellele see on suunatud ja kuidas andmetöötlus toimub. Tegemist ei ole küll anonüümitud andmelaoga aga
sarnaselt sellele näitele saab selguse luua ka muudel juhtudel.
7 / 21
andmelattu või c) andmelaos. Ka neist sõltub andmelaos hallatavate andmete tähenduse
sisustamine.
Meelespea:
✓ Kokkuvõttes on oluline rõhutada, et andmelaos ei ole keelatud töödelda
isikuandmeid ja andmelaos peetavate andmete olemus sõltub eesmärgist (mida on
vaja) ja kasutatavast tehnoloogiast (kas saab töödelda vähem riivavamal moel), kuid
kõik versioonid on võimalikud.
1.2. Primaarandmekogu ehk operatiivbaas ja andmeladu
Funktsionaalsuse juures ei saa mööda minna ka tõusetunud diskussioonist – kus andmed siis
asuvad – primaarandmekogus või laos? See on tekitanud diskussiooni selle üle, et kas tegemist
on lubamatu kopeerimisega? Nagu eelnevalt selgitatud, siis on andmekogu eesmärkide
täitmiseks vajalik töödelda andmeid ja seega peavad need olema sobival kujul. Edastatud
andmestiku eristamiseks ja andmekogu eesmärkide täitmiseks võivad olla samad andmed
andmekogus mitmes formaadis – nii algselt edastatud alusdokumendis kui ka teistes
andmekihtides (andmestik, alamandmekogu või andmeladu). Kui andmekogusse esitatakse
andmeid või dokumente teatud kujul (kas dokumendina või näiteks
kinnitatuna/digitembeldatuna), siis salvestatakse need digitaalses andmekogus enamasti ka
eraldi üksikute andmetena, et neid eesmärgipäraselt töödelda ja teiste andmekogudega X-teel
vahetada.13
Andmete töötlemiseks ja andmete vahetamiseks teiste riigi infosüsteemi kuuluvate
andmekogudega või teiste süsteemidega (näiteks teenuse osutajad), ei saa edastada mitte kogu
edastatud andmestikku või kogu dokumenti, vaid konkreetseid andmeid. Vastasel korral
rikutaks andmete edastamisel õigusaktides sätestatud kohustusi (AvTS-ist lähtuvalt
andmeandjad ja edastatavad andmed14 ja IKÜM-ist lähtuvalt minimaalsuse põhimõte15).
Igapäevatööd tehes soovitakse andmeid töödelda nii, et neid saab reastada ja siduda, mitte avada
ja sulgeda edastatud digikonteinerit. Seetõttu on mõistetav, miks tekitatakse andmekogus
erinevate funktsionaalsustega töödeldavaid alamandmestikke või ladusid. See on vajalik
andmekogusiseste funktsioonide täitmiseks, mis omakorda täidavad andmekogu eesmärgina
kehtestatud peamisi eesmärke.
Selliseid näiteid võib tuua ilmselt iga andmekogu pinnalt mitmeid. Sõltuvalt andmekogu
eesmärgist ja selle funktsionaalsustest, on samade andmete eraldi paigutus vältimatu, et
andmekogu eesmärke vastutava ja volitatud töötleja või siis ka andmekogu kasutajate vaatest
13
Vt nt Vabariigi Valitsuse 28.02.2008 a määrust nr 58 „Riigi infosüsteemi haldussüsteem“,
https://www.riigiteataja.ee/akt/106082019018. Selles eeldatakse metaandmete või muu andmekogude vahel
vahetatava teabe andmekirjeldusi. Vt ka Vabariigi Valitsuse 23.09.2016 a määrus nr 105 „Infosüsteemide
andmevahetuskiht“, https://www.riigiteataja.ee/akt/106082019017. Ka see räägib andmetest, mida X-teel
vahetatakse.
14
Vt nt AvTS § 435 lg 1: „Andmekogu põhimääruses sätestatakse andmekogu pidamise kord, sealhulgas
andmekogu vastutav töötleja (haldaja) ja vajaduse korral volitatud töötleja, andmekogusse kogutavate andmete
koosseis, andmeandjad ja vajaduse korral muud andmekogu pidamisega seotud korralduslikud küsimused.“
15
IKÜM, art 5 lg 1 alapunkt c, https://eur-lex.europa.eu/legal-content/ET/TXT/?uri=celex%3A32016R0679.
8 / 21
täita. Seega tekivad tahes tahtmata andmed erineval kujul, kuid see ei tähenda, et tegemist oleks
lubamatu koopiaga.
a) Näiteks selleks, et teha tervishoiuteenuse osutaja edastatud vabad ravijärjekorra
ajad patsiendile digiregistratuuris kättesaadavaks ja siduda vaba vastuvõtuaeg
patsiendile väljastatud saatekirjaga, on vaja andmed omavahel seostada. Samad
andmed teenuse osutaja kohta on esitatud nii vabades ravijärjekorra aegades kui
ka saatekirja dokumendis. Isikuandmed on samuti nii algdokumendis (saatekiri)
kui ka digiregistratuuris, et aeg kinnitada ja saatekiri sellega siduda.
b) Isikuandmete töötlemine toimub ka muude funktsionaalsuste täitmisel. Lisaks
algandmetele, mis teenuse osutaja poolt ravidokumendis edastati, toimub isiku
nime ja isikukoodi töötlus ka kontaktandmetes, mida isik saab näiteks läbi
iseteeninduse esitada. Isikuandmete töötlus on vajalik ka iseteenindusse
sisenemiseks ja samad andmed - isiku nimi ja isikukood - jäädvustatakse ka
näiteks logides.
Seega oleks võimatu täita sellist nõuet, et isiku nimi ja isikukood võiks kogu
andmekogus esineda vaid üks kord. Oluline, et tegevused on andmekogu eesmärke.
silmas pidades lubatud ja eesmärgipärased ning et tegevus logitakse.
Eeltoodud näidetes on andmeladu üks andmekogu funktsionaalsusest. Seega ei saa andmed
asuda „lihtsalt kusagil“ ehk väljaspool andmekogu raamivat süsteemi. Oluline on, et
andmekogu ja seda ümbritsev süsteem oleks terviklik ja kooskõlas õigusaktides sätestatud
raamidega - milliseid andmeid kogutakse ja säilitatakse, kes haldab, kes saab juurde,
kellele andmeid väljastatakse ning kuivõrd on tagatud piisavad turvameetmed jms. Nii
tuleb ka kõikide andmetöötluste korral – ei ole oluline mitmel tasandil – tagada ka logid jm
nõuded (vt rohkem alapunkt 1.3.3).
Võimalikku näidet saab selgitada kõrval
oleva joonisena, kus andmekogu osaks
on nn operatiivbaas ehk dokumendid,
mis sisse tulid, kui ka andmeladu, kus
asuvad andmed. Viimased põhinevad
sisse tulnud dokumentidel, neid saab
mugaval viisil töödelda - reastada,
siduda ja edastada teistele näiteks
teenuste pakkumiseks.
Mõlemad eelviidatud andmekihid
(algdokumendid ja „lahti pakitud“
andmed) moodustavad andmekogu
olemusliku terviku. Selguse huvides
tuleks andmekogu põhimääruses tuua,
et andmekogu on mitmetasandiline/-kihiline ning ühe andmestiku sellest moodustavad alg- või
9 / 21
alusdokumendid.16 Kui seda eraldi määratud ei ole, on see põhjendatav töötlemise eesmärkide
tagamisega, sõltuvalt kehtestatud nõuetest (kas andmeid esitatakse avalduste, taotluste,
deklaratsioonidena ja/või otsetäidetava vormi kaudu jne). Tuues paralleeli võib vaadelda seda
kui sarnast olukorda pabermaterjalidega, kus üks ja sama paber võib olla kahes kohas
(kopeerituna erinevateks eesmärkideks) või on paber kantud arhiivi ja selle andmed sisestatuna
infosüsteemi, lähtudes töötlemise eesmärkidest ja säilitamise tähtaegadest. Samas on oluline
rõhutada, et taas läbipaistvuse huvides tuleks andmekogude puhul selle põhimääruses eristada,
mida sinna kantakse. See tähendab, et siin on sisuline vahe, kas sinna kantakse terve dokument
(mida see sisaldab) või ainult üksikud andmeväljad, mis on olulised (nt kas kohtumäärus
teovõime piiramise kohta või ainult andmeväljana resolutsioon teovõime piiramise ulatuse
kohta). Niisamuti tuleb kaaluda ja eristada erinevate andmestike säilitamise tähtaegasid (nt
alusandmete kui dokumentide säilitamise erisus kui andmed on süsteemi andmetena
salvestunud vms).
Andmekogu funktsionaalsused on ellu kutsutud täitma andmekogule seatud eesmärke ehk
funktsionaalsus aitab täita seda, milleks andmeid üldse koguma hakati. Selleks võib olla vajalik
andmekogu siseselt salvestada andmeid ühes või teises andmekihis (varasemalt toodud näide,
kus on olemas algandmetena saatekiri ning andmete sidumiseks digiregistratuuris esitatakse
isikuandmed, mis esinevad juba digisaatekirjal). Oluline on, et nii ühel kui teisel viisil
salvestatud andmete säilitamisel tuleb järgida säilitamisele kehtestatud tähtaegu (vt täpsemalt p
1.3.2.). Samuti võib tekitada küsitavusi see, kui andmed hakkavad erinema – ehk parandatakse
näiteks ära „lahti pakitud andmed“, kui neis avastatakse viga, kuid algne kinnitatud dokument
jääb andmete edastaja poolt muutmata (vt täpsemalt p 1.3.3).
Meelespea:
✓ Kokkuvõtvalt võib tuua, et andmekogus võib olla eraldi algandmestik ja eraldi
andmeladu nende andmete kiireks töötlemiseks andmeridade pealt (arvutused,
otsingud jms).
✓ Tehniline ja kihiline eristus, kus üks osa on nimetatud andmelaona, aga sisaldab
samu andmeid, ei tähenda, et tegemist on lubamatu koopiaga. Erinevad tehnilised
funktsionaalsused ja andmekihid on loodud kooskõlas andmekogu eesmärkidega
ja aitavad täita andmekogu eesmärke selleks õigustatud isikute poolt.
✓ Oluline on, et andmete kogu töötlemise õiguspärasuse (sh töötlemise eesmärk ja
viis, andmekoosseis, juurdepääs, andmete õigsus, säilitamine, töötlemise
jälgitavus) tagamiseks tuleb järgida kehtestatud nõudeid kogu andmekogu
andmete osas tervikuna.
16
Näiteks tervise- ja tööministri 06.03.2019 a määrus nr 16 „Tuberkuloosiregistri põhimäärus, § 3 lõiked 1 ja 2,
https://www.riigiteataja.ee/akt/112032019021, või 20.05.2016 a määrus nr 40 „Töövõime hindamise ja
töövõimetoetuse andmekogu asutamise ja pidamise põhimäärus, § 3,
https://www.riigiteataja.ee/akt/119022020002.
10 / 21
1.3. Millest tuleks andmeladude reguleerimisel lähtuda
Käesolevas alajaotuses tuuakse peamised alateemad lähtuvalt praktikas üles kerkkinud
küsimustest. Näiteks kas andmeladu peab olema ühe andmekogu osa või kui kaua võivad
andmelaos olla andmed säilitatud jms. Andmelao juures tuleb järgida samu nõudeid –
turvanõuded, juurdepääsuõigused, õiguslik alus jms – nagu kogu andmekogu pidamiselgi.
Rakendada tuleks kõiki asjakohaseid meetmeid, mis tagavad andmetöötluse kooskõla
õigusaktides kehtestatuga. Ei andmelao ühes ega teises nn kihis - olgu siis operatiivbaas või
andmeladu - ei saa olla andmeid, mida pole lubatud koguda seaduse või põhimääruse kohaselt.
Oluline on rõhutada, et andmete töötlemine oleks kooskõlas õigusaktidega, seda nii
andmete kogumise, nende turvalisuse kui ka muude nõuete tagamisel.
1.3.1. Andmeladu on olemuslikult andmekogu osa, selle reguleerimisvajadus
Nagu juhise sissejuhatuses viidatud, on andmeladude kajastamine andmekogude põhimäärustes
erinev – osalt on see sätestatud, osalt mitte ning ka regulatsiooni sisu on väga erinev (mõnel
juhul on see detailsem, mõnel juhul aga mainitud vaid registri ülesehituse juures). Vastus
küsimusele, kas andmeladu tuleks siis alati põhimääruses eraldi reguleerida või mitte, ei ole
ühene ja sõltub teatud erisustest. Teatud juhtudel oleks andmelao eraldi reguleerimine
põhimääruses mõistlik, osadel juhtudel vajalik. Siinkohal saame tuua taas näiteid.
Andmelaos kui andmekogu olemuslikus osas ei saa töödeldavate andmete kategooriad väljuda
andmekogu kohta käivast seadusest või põhimäärusest. Teisisõnu, ei saa andmekogu juurde
kuuluvas andmelaos (olgu siis tehnilises mõttes eraldi alamandmekogu või põhibaasi
funktsionaalsusega töödeldav andmestik) olla andmeid, mis väljuksid selle konkreetse
andmekogu andmetest, mida sinna koguda tohib.
Andmekogu asutatakse konkreetse ülesande täitmiseks ja andmekogu eesmärk ning sellesse
kogutavad andmed peavad olema kaetud andmekogu aluseks oleva seaduse või põhimäärusega
ehk olema piiritletud (seaduslikkus).17 Kogu avaliku võimu tegevus peab olema
põhiseaduspärane ja rajanema seadustel. Mõistagi ei saa iga otsust ja toimingut seadustes
üksikasjalikult kirjeldada, seaduse alusel võib anda täpsustavaid määrusi jt õigusakte, mis
omakorda peavad olema kooskõlas kõrgemat õigusjõudu omava aktiga.18 Seega ei saa
andmelaos, mis on andmekogu osa, olla midagi rohkemat kui see, mida seadus võimaldab. Eriti
oluline on see isikuandmete kogumise puhul, kuid mitte ainult. Ka teiste andmete (ärisaladus,
ettevõtja kohustus esitada riigile andmeid), kogumine peab olema ettenähtav ja seega
piiritletud. Kui töödeldavad andmed ja töötlemise eesmärk ei välju eelviidatud piiridest, jääb
17
Põhiseadus, § 3. Isikuandmete osas vt ka isikuandmete kaitse seaduse rakendamise seaduse (778 SE)
seletuskirja alapunkti 3.2 „Seaduste muutmise põhimõtted“. Selles tuuakse kolm põhilist sammast, mida
seadusloomes järgida – seaduses tuleb tuua andmekategooriad, nende säilitamise tähtaeg ning hinnata
andmekogus toodud tegevusi seaduses toodud volitusnormi piisavusega,
https://www.riigikogu.ee/tegevus/eelnoud/eelnou/9d1420bb-b516-4ab1-b337-17b2c83eedb1. Vt ka
Andmekaitse Inspektsiooni juhist „Andmekogude juhend“, p 2.4 „Kuidas seadusega põhiõiguste riivet
pehmendada?“, https://www.aki.ee/sites/default/files/dokumendid/andmekogude_juhend.pdf.
18
Põhiseaduse kommentaarid, § 3, https://pohiseadus.ee/sisu/3472.
11 / 21
ikkagi üles küsimus, et kas sellisel juhul tuleb andmeladu eraldi välja tuua ja reguleerida või
mitte? Küsimusele vastamiseks tasuks selgitada erinevaid võimalusi.
Näiteks võib infosüsteem või registri regulatsioon olla hõlmatud ühe või mitme andmekoguga
– sealjuures võib olla andmeladu üks selle eraldi osi (näiteks tervise infosüsteem ja
sotsiaalteenuste ja -toetuste andmeregister).19 Oluline on see, kas kogutavad andmed jäävad
andmekogu õiguslikesse raamidesse ja kas eesmärk on andmekogu asutamisel kaetud. Milliseid
funktsioone konkreetselt andmeladu täidab, on erinev. Kindlasti ei tule eraldi reguleerida
olukorda, kui andmeladu täidab igapäevaseid andmekogu eesmärkides seatud ülesandeid
ehk andmete vormile, säilitamisele, juurdepääsudele, turvanõuetele vm nõuete osas
erisusi ette ei nähta. Sellisel juhul ei oma see eraldi tähendust, sest ladu ongi mõeldud näiteks
dokumentidest andmete „lahti pakkimiseks“ ja kogu mugava töötlemise tagamiseks (üldpildi
infosüsteemist saab arhitektuurijooniselt). Samas võib selle äramainimine aidata kaasa
läbipaistvuse tagamisele, ehk tervikpilt peaks olema kooskõlas reaalsetete tegevustega. Näiteks
on tervise infosüsteemis toodud alamandmestikud ja seetõttu ka eraldi andmeladu, moodustades
ühe eraldiseisva andmestike hulga ja mille vorm erineb muudest andmekogu andmetest
(viidatakse kohustusele viia läbi igapäevaanalüüse isikuid otseselt mittetuvastaval viisil). Eraldi
reguleerimine on vajalik selleks, et just sellele eraldi osale anda näiteks kolmandatele
osapooltele juurdepääse (nende jaoks anonüümitud andmestik). Eraldi alamosade eristamine
võib olla vajalik ka isikustatud andmetele juurdepääsude eristamiseks (aitab määratleda
erinevate isikute juurdepääsulatust).20 Andmelao eraldi reguleerimine võib olla põhjendatud ka
siis, kui seal on statistiline andmestik ja näiteks sellel võiks olla seetõttu madalam turvaaste
(saab viidata konkreetsele andmekogu osale, millele kehtib teine reeglistik). Samuti, kui
soovitakse eristada anonüümitud andmelao andmete säilitamist või teha mõni muu erisus.
Andmeid võib avaldada andmelaost ka otse veebilehel anonüümse andmestikuna või näiteks
jagada erinevate õigustega juurdepääse. Kui andmelao pinnalt teenindatakse näiteks teisi
asutusi otsejuurdepääsudega (erinevate õiguste ja vaadetega aknad), sõltub reguleerimise
vajalikkus sellest, millistele andmetele on juurdepääs lubatud.21 Juurdepääs võib olla
isikustatud või isikustamata andmetele ja loomulikult on võimalik rakendada eraldi
autentimisvahendeid.
Kindlasti tuleb toetada lähenemisviisi, kus andmekogu põhimäärus täpsustab erinevaid
töötlemisviise ja andmetele juurdepääsude andmist või andmete avaldamist, suurendades
seeläbi usaldust andmetöötluse vastu.
19
Lisaselgitus: alamregistrite arv ei ole piiratud, nii näiteks on lennuohutuse järelevalve infosüsteemi pidamise
põhimääruse kohaselt ühte infosüsteemi koondatud 11 alamregistrit,
https://www.riigiteataja.ee/akt/117062021008.
20
Näiteks – küll mitte andmelaona aga hea näitena – on eraldi reguleeritud juurdepääsud maksukohuslase
registri alamregistrile, töötamise registrile (https://www.riigiteataja.ee/akt/109082022007#para25b1). Eraldi
hoitavad andmekogumikud võimaldavad määrata eesmärgipäraselt juurdepääse, kus kogu andmestik ei ole
kõigile vajalik, seega on võimalik teatud alustel grupeeritud ja hoitud andmetele anda juurdepääs vaid vajalikus
ulatuses.
21
Vt nt tervise infosüsteemi põhimäärus, § 14 lõiked 1–3, mis selgitavad andmelao juurdepääse ja andmete
avaldamist avaandmetena, https://www.riigiteataja.ee/akt/103082022004#para14.
12 / 21
Järgnevalt ilmestame kasutusviiside erinevaid juhte.
a) Andmeladu kui igapäevane töövahend andmekogu pidajale. Andmeladu võib olla
igapäevategevuste tarbeks loodud töövahend, et töödelda just isikustatud andmeid ja
võimaldades sama andmekogu andmeid erinevatest „nurkadest“ ühitada ja muuta. Selle
funktsioonid võivad olla lähtuvalt asutuste vajadustest erinevad.
b) Andmeladu kui andmestik statistikaks. Andmeid kasutatakse asutuse enda poolt
andmekogu statistiliste eesmärkide täitmiseks (nt poliitika kujundamiseks, igapäevased
raportid jms).
c) Vastavalt õigustele antakse teistele ka teabe saamiseks juurdepääse. Teistele
isikutele/asutustele andmetele juurdepääsu andmine vastavalt andmelaos kavandatud
teenustele. Mida ja kellele näidata – kas isikustatult või anonüümitult - sõltub õigustest.
d) Andmekogu andmelao pealt andmete otse avalikustamine (avaandmed). Üldine
statistiline teave, mida võib avaldada ehk isiku tuvastamine või muu konfidentsiaalse teabe
lubamatu avaldamine on välistatud. Graafiliste avaandmete esitamine toimub turvaliselt
(tulemüür, esitlusserverile puudub juurdepääs jne).
1.3.2. Andmete säilitamine andmelaos
Kui andmeladu on andmekogu osa, siis nagu andmete koosseis ei saa olla laiem kui
andmekogu aluseks oleva seadusega või põhimäärusega lubatu, ei saa ka andmelaos
kasutada andmeid pikemalt, kui õigusaktides kehtestatud andmete säilitamise tähtaeg
ette näeb (AvTS kohustab reguleerima selles hoitavaid andmeid ja seega peab teadma, kui kaua
midagi alles hoitakse, tagades taaskord teabe töötlemise seaduslikkuse). Ka siis, kui andmed
anonüümitakse ja kantakse statistilisse anonüümsesse alamandmebaasi (nn lattu), puudub
isikustamata andmete hoidmisel küll otseselt puude eraelu riivega, kuid kuna ka anonüümitud
andmed moodustavad andmekogus säilitatavate andmete osa, tuleks luua siingi selgus, et kui
kaua riiklikus andmekogus andmed siis hoitakse. Seda teavet võivad soovida teada ettevõtted,
mille kohta andmeid hoitakse ja mis ei ole isikuandmed, aga ka teised isikud, kes neid andmeid
kasutavad, olgu siis haldusülesanneteks või teadustööks.
Lähtekoht, et andmed on Näiteks kui andmelao andmed on anonüümselt olemas, siis võib
anonüümitud ja justkui ka siin näha ette erisuse andmelao anonüümitud andmetele ehk
seetõttu eraldi reguleerimist tuuagi välja, et peetakse ka anonüümitud andmeladu mille
ei vaja, ei ole päris õige. Kui andmed on „x“ tähtajani. Näiteks on andmekogul ühed
teave tekib (andmed) ja see eesmärgid – loa taotlused, menetlused. Kui load on väljastatud
kantakse ja säilitatakse ja kõik menetlused lõppenud ja neid hoitakse näiteks seoses
andmekogus, tuleks seegi vaidlustamisvõimalustega vaid viis aastat, siis võib teatud
selgelt reguleerida. Toome faktiliste andmete säilitamine olla põhjendatud ka statistikaks
pikemalt, et kujundada valdkondlikku poliitikat. Nii täidavad
kõrval sellekohase näite.
menetlusega seotud andmed lühiajalist eesmärki ja
statistika/poliitika kujundamine pikemat eesmärki ja siit ka
pikem säilitamise tähtaeg. Nii tulekski see erisus selgelt
reguleerida.
13 / 21
1.3.3. Autoriseerimine, andmete struktureerimine, logid ja muud nõuded
Andmeladude haldamisel, mis on andmekogu osa, tuleb järgida kõiki samu põhimõtteid nagu
andmekogudegi puhul, see on selle olemuslik osa. Seega andmete struktureeritus, turvanõuded
jms, sealhulgas juurdepääsude haldus ja autoriseerimine, kui andmelaole võimaldatakse
otsejuurdepääse.
Isikustatud andmestike puhul tuleb kindlasti tagada logide haldus, see on sarnane muu
andmetöötlusega terves andmekogus, ehk üldised põhimõtted siin ei muutu. Seega tuleb läbi
mõelda ka logide süsteem, mis võimaldab tuvastada muudatused või andmete vaatamise kas
siis ühes või teises andmekihis. Ehk kui andmekogu kasutajad pärivad dokumente või
pakutavate teenuste raames töödeldakse „lahti pakitud“ andmeid, tuleks isikuandmete
töötlemine logida nii ühel kui teisel juhul. Loomulikult ei pruugi see nõue kehtida anonüümitud
andmete töötlemisel andmelaos, sest nende vaatamine on sarnane avaandmete käsitlusega.
Samas ei tähenda see aga seda, et andmelao osas ei kehtiks muid kohustusi (juurdepääsude
haldus või andmete turvaline avaldamine jms).
Erisusena võib reguleerida ka anonüümitud andmete turvaklassi, kui selles hoitakse vaid
anonüümitud andmeid. Ka see on võimalik andmekogu põhimääruses ära määratleda.
Kindlasti tuleks pöörata tähelepanu ka andmete muutmisele. Olukorras, kus andmed
muudetakse andmelaos, aga andmed jäävad algdokumendis muutmata, erineksid
funktsionaalsustes kasutatavad andmed (lahti pakitult) algandmetest, mis andmekogu pidajale
esitati. Andmete kvaliteet peaks olema aga ühesugune, sõltumata andmete paiknevusest. See
tähendab omakorda protsesside kaardistust andmehalduse kontekstis ja õigusselguse
tagamiseks on vajalik õigused ja kohustused sätestada täpsemalt andmekogu põhimääruses,
nagu seda on enamasti ka tehtud (andmete muutmise/uuendamise protsess).
Meelespea:
✓ Kokkuvõttes võib tuua, et andmekogu juurde kuuluva andmelao andmete koosseis
ja andmete säilitamise tähtaeg ei saa erineda andmekogule kehtestatud nõuetest
(mis andmeid võib koguda ja kaua neid säilitatakse).
✓ Andmeladu kui ühte tehnilist võimalust andmestike halduses ei pea andmekogu
põhimääruses eraldi reguleerima, kui see täidab andmekogu peamisi eesmärke (nt
kui alusdokumendid „võetakse“ andmeteks lahti). Kindlasti tuleks andmelao
puhul eraldi reguleerida see, kui soovitakse kehtestada teatud erisusi - andmete
vorm, juurdepääsude haldus, turvanõuded jms.
1.3.4. Andmeladu teenindab mitme asutuse andmekogu, selle reguleerimisvajadus
Andmelao reguleerimise vajalikkuse osas, kus selle eesmärk on tagada andmetöötlus erinevate
andmekogude osas, tuleks taaskord avada mõtet läbi näidete.
Andmeladu võib olla kui üks laohoone, kus on eraldi üüritavad ruumid. See tähendab, et
laoruumide omanike kaup ehk andmed hoitakse teiste omadest eraldi, igal vastutaval töötlejal
on oma ruum ja oma ruumi võti. Nii on võimalik, et mitu erinevat asutust (vastutavat töötlejat)
14 / 21
kasutavad ühte ja sama volitatud töötlejat ehk tema teenuseid (nö üürivad laos ruumi pinda).
Volitatud töötleja võib omada ühte andmeladu (platvorm), milles üüritakse erinevatele
vastutavatele töötlejatele laoruume. Seega on õigused ja kohustused hoitud lahus, andmeid
ei ristkasutata ja erinevatele „ruumi üürijatele“ üksteise andmeid ei näidata. Volitatud
töötleja peab täitma kõiki kohustusi vastavalt õigusruumis toodule ja lähtuvalt iga vastutava
töötleja juhistest, mis võivad olla erinevate andmekogude kontekstis erinevad. Nii on iga
andmekogu juures näiteks ära toodud, et andmekogul on analüütiline andmeladu, seda haldab
volitatud töötleja X. Tehniliselt ja õiguslikult omab iga andmekogu „oma ruumi“, kus toimub
nende andmetöötlus. Volitatud töötleja X peab tagama, et erinevate andmekogude andmeid (see
tähendab ka analüütilisi) ei näe otse ükski teine andmekogu vastutav töötleja (andmeid saaks
näha sarnaselt teistele isikutele mõeldud teenuste kaudu).
Olukord, kus erinevate asutuste ehk vastutavate töötlejate andmed ühte andmelattu aga kokku
kantakse, eeldab sellekohaseid õiguslikke aluseid. Ehk sellisel juhul tuleb eraldi analüüsida, kes
nimetatud andmeladu peab, millisel eesmärgil ning millisel kujul on selles peetavad andmed.
Anonüümsete andmete korral (kõik mis kanti nii ka jääb) võib tegemist olla nt avaandmetega,
mis koondatakse ühe isiku poolt kokku, kuid kes iseseisvalt alusandmeid ei näe. Sisuliselt
toimuks justkui andmekogudest andmete väljastamine ehk statistiliste näitajate jagamine –
tegemist ei oleks juurdepääsupiiranguga teabega – näiteks väljastatud tegevuslubade arv,
sõidukite arv vms. Sellist eesmärki täidab täna avaandmete teabevärav.22
Isikustatud andmete töötlemise korral tuleb õiguslike aluste olemasolu eraldi hinnata. Kui
erinevate andmekogude andmeid soovitakse isikustatult ühte kokku kuhjata ja neid omakorda
mingitel eesmärkidel töödelda, ei saa enam rääkida andmetöötlustest ühe andmekogu
eesmärkidel ja andmete piires. See eeldab eraldiseisvat alust. Andmekogu asutatakse AvTS-i
kohaselt konkreetse ülesande täitmiseks23 ning luues uue andmete kogumise ja töötlemise
eesmärgi, räägime me uuest riigi infosüsteemi kuuluvast andmekogust (mitte laost, mis võib
olla uue andmekogu funktsionaalsus). Seega ei saa luua „lihtsalt ladu töötluseks“ vaid eraldi
asutades luuakse siiski uuel eesmärgil andmekogu kui selline.
Olemasolevatest andmekogudest nende kõikide andmete koondamisel lihtsalt uude
andmekogusse töötlemise hõlbustamiseks, tekitaks küsimuse aga nii seatud uuest eesmärgist
ehk ülesandest, aga ka algandmekogude vajalikkusest.24 Kui eesmärk on võimaldada erinevate
andmekogude vahel andmete pärimist – olgu siis konkreetse teenuse tagamiseks või ka
statistikaks (kui andmekogu eesmärgina on see seatud), tuleks see reguleerida läbi erinevate
andmekogude ja andmeandjate regulatsiooni. Iga andmeandja ja soovitud andmepäringu puhul
tuleb selgitada nende andmete pärimise vajalikkust ja kooskõla selle andmekogu eesmärgiga,
kuhu neid andmeid siis kandma hakatakse (ehk kuhu need edastatakse).25 Ei ole välistatud, et
kui olemuslikult on vaja näiteks kahe andmekogu andmete pidev ühildamine ja kus tegelikult
22
Vt siit: https://avaandmed.eesti.ee/. AvTS § 29 lõike 6 kohaselt peavad masinloetaval kujul olevad avaandmed
juurdepääsetavad Eesti teabevärava kaudu.
23
AvTS § 431 lg 1: Andmekogu on riigi, kohaliku omavalitsuse või muu avalik-õigusliku isiku või avalikke
ülesandeid täitva eraõigusliku isiku infosüsteemis töödeldavate korrastatud andmete kogum, mis asutatakse ja
mida kasutatakse seaduses, selle alusel antud õigusaktis või rahvusvahelises lepingus sätestatud ülesannete
täitmiseks.
24
Vt ka vt ka AvTS § 433 lg 2: keelatud on asutada ühtede ja samade andmete kogumiseks eraldi andmekogusid.
25
AvTS § § 435 lg 1: andmekogu põhimääruses sätestatakse /../ andmekogusse kogutavate andmete koosseis,
andmeandjad ja vajaduse korral muud ..
15 / 21
täidetakse eesmärke mõlema andmete koostöötlemisel, on mõistlik luua mõlema haldamiseks
üks infosüsteem koos kahe alamregistriga või muutes senise andmehalduse täielikult ümber,
koondades need muul viisil üheks.26 Selleks peab loomulikult olema selge vajadus ja põhjendus
ehk igapäevavajadus, mitte ajutine analüütiline eesmärk.
Kui ühildada soovitakse erinevate riiklike andmekogude andmeid, kus tegemist ei ole püsiva
vajadusega ja neid andmeid ei salvestata nö pikaajaliselt ja eesmärk on uus teadmus või analüüs,
võetakse selleks isikuandmete korral vastav luba (isikuandmete kaitse seadus, § 6).27
Ühekordsete andmete analüüsiks ja täiesti erinevate andmete kokku toomiseks ei pruugi olla
mõistlik ega vajalik asutada uut andmekogu, vaid see peakski käima teadustöö lubade raames
(ajutine eesmärk, andmed muutuvad igakordselt, samuti erinevad tulemuse analüüsiks kuluv
aeg ja ka töötlejad ehk läbiviijad).
Andmete statistilist vajadust kiirkorras ehk näiteks hädaolukorras, saab tagada läbi teiste
õiguslike võimaluste, näiteks läbi erisuste lubade kiiremaks menetluseks või muu erisusena
eriseaduses – näiteks nähes ette teatud olukorras selge õiguse ja erisuse andmeid saada või
pärida.28 Kui detailne on sellekohane normistik ja millised on asjakohased kaitsemeetmed,
sõltub kindlasti andmete tundlikkusest ning nende töötlemise eesmärgist.
Samuti võib avalikus sektoris rakendada Statistikaameti andmejagamisteenust29, kus
kombineeritakse nö asutuse teave muu teabega ja vastuseks saadakse statistiline teave.
Analüüside tegemiseks võib määratleda aga ka püsiva vajaduse korral konkreetsele asutusele
õiguse andmeid saada või juurdepääs pseudonüümitud andmete töötlemiseks30.
Arvestades kõiki võimalikke elulisi erisusi, ei ole võimalik anda käesolevas juhises
ammendavat ülevaadet kõikideks olukordadeks ning vajadus ja võimalused eeldavad igakordset
kaalumist ja põhjendamist.
26
Vt näiteks Terviseameti registrite ühildamist, uue nimega tervishoiukorralduse infosüsteem (tervishoiuteenuste
korraldamise seaduse muutmise ja sellega seonduvalt teiste seaduste muutmise seadus 569 SE),
https://www.riigikogu.ee/tegevus/eelnoud/eelnou/da9c1e85-b29b-437e-9aeb-c1bedc58bc1a
27
Isikuandmete kaitse seadus, § 6, https://www.riigiteataja.ee/akt/104012019011#para6, kooskõlas isikuandmete
kaitse üldmääruse artiklitega 5(1)(b) ja 89.
28
Ka Euroopa Liidu tasandil kavandatakse andmemäärusega luua eraldi õiguslik alus, küsida teatud erijuhtudel
andmeid. Vt viimase kohta ettepaneku 5.ndat peatükki: EUROOPA PARLAMENDI JA NÕUKOGU MÄÄRUS
ühtlustatud õigusnormide kohta, millega reguleeritakse õiglast juurdepääsu andmetele ja andmete kasutamist
(Andmemäärus), https://eur-lex.europa.eu/legal-content/ET/TXT/?uri=CELEX:52022PC0068. Vt ka tänaseid
erisusi hädaolukorras ülesannete määramisel, näiteks HOS § 14 lg 4 1,
https://www.riigiteataja.ee/akt/109082022024#para14 või ka erisust koostöö alusel, HKTS § 18 lg 2,
https://www.riigiteataja.ee/akt/117112021007#para18.
29
Riikliku statistika seadus, § 201, https://www.riigiteataja.ee/akt/111032022002#para20b1.
30
Vt nt sotsiaalseadustiku üldosa seaduse § 391, https://www.riigiteataja.ee/akt/106012023016#para39b1, mille
alusel on antud Sotsiaalministeeriumi analüüsi ja statistikaga tegeleval osakonnale õigus töödelda tervise-, töö-
ja sotsiaalvaldkonna poliitika kujundamiseks isikuandmeid, ilma et isik oleks otseselt tuvastatav.
16 / 21
2. Kokkuvõte andmelao reguleerimise vajalikkuse osas
Käesolevas juhises on toodud selgitused erinevate funktsionaalsuste kohta, mida andmeladu
võib täita. Kokkuvõttes leitakse, et kui andmeladu toetab andmekogu pidamist
andmekogule kehtivate reeglite kohaselt, siis seda eraldi andmekogu põhimääruses
reguleerida ei ole vaja, kuid põhimäärus peaks andma realistliku pildi andmekogus
toimuvast. Kindlasti ei tuleks seaduses tuua andmelao definitsiooni, mis ühest õiguslikku
sisu ei kanna. Andmeladu on vajalik eraldi reguleerida põhimääruses siis kui seoses
sellega soovitakse kehtestada mõni erisus - andmekogu muudest andmetest erinev
andmete vorm, erinev säilitamise tähtaeg, erinev turvaaste vms.
Loomulikult tagab suurem läbipaistvus ühtsed arusaamad andmetöötlusviisidest. Kehtestades
selgelt andmekogu põhimääruses näiteks, et analüüside tarvis peetakse pseudonüümitud või
anonüümitud kujul andmeladu, viitab vastutava töötleja hoolsuskohustusele
31
privaatsustehnoloogiate rakendamisel. Seega ei ole andmelao pidamine halb, vaid hea
lahendus, võimaldades töödelda andmeid viisil, kus isiku nimi või muud tuvastamist
võimaldavad andmed ei ole töötlusprotsessis nähtavad. Mida suurem on andmetöötluse
läbipaistvus, seda enam säilib inimeste usaldus digiriigi vastu. Kui andmeladu täidabki vaid
andmekogu peamisi eesmärke, puudub selle reguleerimise vajadus, sest pelgalt tehniliste
meetmete kirjeldamist ei saa selles eeldada. Eraldi reguleerimine on tarvilik kui selleks on
olemas õiguslik põhjendatus - erisuste loomisel muudest andmekogu reeglitest.
Lähtudes andmeladude eesmärkide kirjeldustest ja funktsionaalsuste selgitustest, ei piira
tehnoloogia andmetöötluse eesmärke – see milleks on andmeid lubatud kasutada, otsustab
üldise raamina seadusandja. Andmelao mõiste reguleerimine ei looks õigust või õigustust teha
midagi kindlal viisil, sest andmeladu võibki täita erinevaid funktsioone.
Kui soovida ühtseid põhimõtteid ja sellest juhisest tulevikus ei piisa, võib kaaluda
andmekogude pidamise sätete täiendamist AvTS-is (tuua selles näiteks peamised põhimõtted,
mida siis põhimäärustes kajastada).32 Need saaksid olla aga tõesti vaid põhimõtted mitte ühtse
andmelao kui sellise reguleerimine, sest funktsioonid võivad andmeladudel olla erinevad ja ka
sama funktsiooni võib täita muu nimetusega funktsionaalsuse kaudu. Põhimõttena võib kaaluda
seega nii arhitektuurilise osa õigusselgemaks tegemist (alamandmestike, alamregistrite jne
väljatoomise näol) või nähes ette kohustuse, kuna andmeladu või muu andmestike üksust eraldi
reguleerida tuleks ( nt andmete vorm, säilitamine vms).
Meelespea:
✓ Andmelao defineerimiseks seaduses puudub vajadus. Seda ei tule reguleerida ka
põhimääruses, kui tegemist on andmekogu ühe osaga ning kus andmeladu toetab
andmekogu pidamist ja mille tegevus lähtub andmekogu aluseks olevast seadusest
ja/või põhimäärusest.
✓ Kui andmeid soovitakse eraldi ühildada mitmest andmekogust, peab selleks olema
õiguslik alus. See ei seostu otseselt andmelao mõistega.
31
IKÜM art 5 ja 25. Minimaalsuspõhimõtte ja lõimitud ning vaikimisi andmekaitse põhimõtete rakendamine,
https://eur-lex.europa.eu/legal-content/ET/TXT/?uri=celex%3A32016R0679.
32
Näiteks AvTS § 435 lg 1 või selle alusel kavandatav volitusnorm.
17 / 21
3. Korduma kippuvad küsimused
Käesolevas jaos selgitatakse praktikas tõusetunud küsimusi. Kuna küsimused võivad ajas
muutuda, saab käesolevat juhist edaspidi ka nendega täiendada.
3.1. Kas andmelaost võib „teenindada“ teisi andmekogusid?
Jah võib. Nagu eelnevalt juhises selgitatud, siis on oluline see, millist funktsiooni see
andmeladu olemuslikult täidab. Tehnilises mõttes ei ole kuidagi piiratud seda, et kuidas või
läbi millise tehnilise funktsionaalsuse andmeid teistele andmekogudele edastatakse.
Oluline on vaid see, et tegemist on andmekoguga (ja ladu selle osa), mis on kohustatud andmeid
teisele riigi infosüsteemi kuuluvale andmekogule edastama.
3.2. Kas X-teel võib andmeid vahetada vaid riigi infosüsteemi kuuluvate
andmekogude vahel?
Eeldatakse, et võib ka laiemalt. X-tee on turvaline andmevahetuskanal ja selle kasutust tuleks
igal juhul toetada. See tähendab, et ka väljaspool riigi infosüsteemi kuuluvad andmekogud
võiks igal juhul kasutada andmete jagamisel turvalist kanalit. Eksitav on ilmselt sätte
asukoht seaduses, mille tõttu on seda vaid andmekogude kesksena tõlgendatud. Nimelt asub
säte AvTS-is andmekogude peatükis, kuigi sedastab konkreetses normis täiesti eraldiseisvana
õiguse, vahetada andmeid ka
(5) Andmevahetus riigi infosüsteemi kuuluvate andmekogudega ja
teiste isikutega (AvTS § 439 lg
riigi infosüsteemi kuuluvate andmekogude vahel toimub läbi riigi
6).33 infosüsteemi andmevahetuskihi.
(6) Käesoleva paragrahvi lõikes 5 toodu ei piira andmevahetust
infosüsteemide andmevahetuskihil muude juriidiliste isikute
vahel.
Eeltoodud tõlgendust, et X-tee ei ole mõeldud pelgalt riigi infosüsteemi kuuluvate
andmekogude vahel teabe vahetamiseks, selgitab ka 2015. a eelnõu seletuskiri34 järgmiselt:
Infosüsteemide andmevahetuskiht (X-tee) on õigusruumis reguleeritud kindlustava süsteemina,
mis on kohustuslik riigi infosüsteemi koosseisus olevate andmekogudele. See on loonud
õiguslikult olukorra, kus X-teed ei tohi kasutada andmekogudesse mitte puutuvas
andmevahetuses ning tuleb teha õigusruumi korrastamises valik, kas piirata X-tee kasutust
ainult selleks ette nähtud juhtudele või legaliseerida reaalne olukord. Näidetest tulenevalt on
otstarbekas legaliseerida X-tee kasutus moel, mis ei piira andmevahetust ainult andmekogude
33
AvTS § 439 lg 6, https://www.riigiteataja.ee/akt/110032022004#para43b9.
34
Riigikogu koduleht: Avaliku teabe seaduse muutmise ja sellega seonduvalt teiste seaduste muutmise seadus 71
SE, https://www.riigikogu.ee/tegevus/eelnoud/eelnou/c32e74a6-2903-4736-8513-d18358fc1ad3.
18 / 21
vahele, vaid võimaldaks X-teed kasutada ka avalikus sektoris jooksutatavate infosüsteemide
vahel ning samuti erasektoris.
Suurema õigusselguse huvides võiks tulevikus täiendada selles osas kas a) andmekogude
peatüki pealkirja (X-tee on rakendatav ka väljaspool seda peatükki) või b) tõsta eelviidatud säte
lõikest 6 seaduse teiste üldiste sätete alla (väljapoole andmekogude peatükki). Samas on normi
mõttena selle laiemat kasutusala eeldatud ning praktikas on sellest ka lähtutud.
3.3. Mis vahe on andmekogul ja infosüsteemil? Miks vormistada infosüsteemi
põhimäärus?
Sisuliselt võib see küsimus puudutada ka andmeladusid, mis on andmekogu osaks. Nimelt on
õigusruumis reguleeritud andmekogusid aga ka infosüsteeme, mille osaks andmekogud on.
Andmekogu on üks võrgu- ja infosüsteemi alamliik. Kõik andmekogud on võrgu- ja
infosüsteemid, aga kõik võrgu- ja infosüsteemid ei ole andmekogud.35 Seega toetab infosüsteem
andmekogu, need mõisted võivad ühtida kuid ei pruugi. Andmekogu haldust toetav infosüsteem
võimaldab määratleda kogu andmehalduse tervikuna. Infosüsteem toetab igal juhul
digitaalselt peetavat andmekogu, ilma selleta ei saaks andmekogu ehk andmete
hoiustamine funktsioneeridagi. Infosüsteemi ülesehituse, selle erinevate alamosade,
alamregistrite või andmestike reguleerimine aitab lihtsal viisil kaasa erinevate õiguste ja
kohustuste realiseerimisele. Seega ei ole infosüsteem pelgalt andmete hoidmiseks, vaid ka
nende töötlemise eesmärkide tagamiseks laiemalt – andmete kuvamiseks, edastamiseks, logide
ja juurdepääsude tagamiseks, kustutamiseks ja muudeks ülesanneteks – kõik see, mis on seoses
kogutud andmete haldamisega reguleeritud. Nii näiteks on võimalik tänu infosüsteemile tuua
ära selle erinevad osad, sest ka andmestikke, alamandmestikke või alamregistreid hallatakse
infosüsteemis. Tänu infosüsteemile on võimalik määrata erinevate osapoolte juurdepääsud ja
ulatus ning võimaldada täita näiteks ka erinevaid õigusi – esitada deklaratsioone, teha
tahteavaldusi, määrata kontaktisik või kontaktandmed jms. Ka andmete endi hoiustamiseks on
olemas infosüsteem, milles neid hoitakse. Nii ei ole digitaalse andmekogu eesmärgiks pelgalt
loetleda riigi infosüsteemi kuuluvate andmete koosseis, vaid näha ette ka nende haldusega
seotud õiguste ja kohustuste realiseerimine.
Infosüsteem on vajalik, et toetada seega kogutud andmete haldust (kasutust, jagamist,
säilitamist ja turvalisuse hoidmist). Õigusi ja kohustusi aitabki hallata ja määrata tehniline
süsteem andmete ümber. Kuigi sisuliselt võib ühe suure andmekogu õiguste halduses olla
rakendatud mitmeid (alam)infosüsteeme, siis õiguslikult moodustab kindla nimega süsteem ühe
ühtse terviku, s.t andmekogu ja selle haldamise – näiteks käsitletakse „tervise infosüsteemi“
puhul selle põhimääruses kogu õiguste ja kohustuste tervikut, mis on seotud sellesse kogutavate
andmetega (digilugu, pildipank, digiregistratuur, andmeladu). Kogu infosüsteemi hõlmav
regulatsioon (mille sees on eraldi süsteemid) loob suurema õigusselguse andmete kogumiga
toimuvast – kuidas neid komplekteeritakse, kellele edastatakse, kas neile on ka juurdepääs ja
kellel jms.
35
Võrgu- ja infosüsteemi mõiste tuleneb küberturvalisuse seadusest. Kui räägime infosüsteemidest, võiksime
seda mõistet silmas pidada.
19 / 21
3.4. Kas põhiandmeid võiks võtta ka teisest andmekogust, mitte sealt kus need
algselt tekivad?
Ennekõike peaks tõesti võtma aluseks teise riigi infosüsteemi kuuluva andmekogu andmed, kui
neid juba kogutakse.36 Näiteks on rahvastikuregister sellel eesmärgil loodudki andmeid
koguma, et oleks üks koht, kus andmete haldus on järjepidev ja andmete õigsus tagatud ning
mida saaksid aluseks võtta teised andmekogud oma andmete töötlemisel (näiteks isiku nimi ja
isikukood, et andmeid inimesega siduda ja teenuseid pakkuda). Rahvastikuregistri näitel on
andmetel ka õiguslik tähendus (sellise suure kaaluga on ka äriregister ja näiteks
kinnistusraamat). Loomulikult tuleb siinjuures arvestada aga ka erinevaid piiranguid, lähtudes
andmete esialgse kogumise eesmärgist ja andmete tundlikkusest, kus näiteks üheks
kaalukausiks laialdasel andmekasutusel võib olla andmete kogumise viis (näiteks mitte
haldusmenetluse käigus tekkiv teave vaid usaldussuhtest tekkiv teave).37 Eriseaduses tehtud
piirangud on erisused üldisest regulatsioonist ehk AvTS-i normidest.
3.5. Kas ühe andmekogu juurdepääsuhaldust saab kasutada ka teise andmekogu
juurdepääsuhalduse tagamiseks?
Küsimus võib seostuda ka andmeladudega, mis on andmekogu osaks ja mille kaudu võib
teenindada ka andmetele juurdepääse. Küsimus seisneb nimelt selles, kas ühe andmekogu
juurdepääsudeks loodud turvalist kanalit võib kasutada ka teise andmelao juurdepääsude
teenindamisel? Vastus on jah, kui tegemist on nn „karbitootega“ ehk standardlahendusega,
mida igaüks oma süsteemis andmekoguga liidestab ilma, et õigussuhted muutuks (keegi ei
halda kellegi eest ja nimel nö juurdepääsukanalit). Juurdepääsukanal peab olema lahutatud
turvanõuete jms kaudu erinevate andmekogude lõikes, sarnaselt laohoone ja selle ruumide
näitega - ehk sama ukse kaudu ei satutaks sinna, kuhu ei või sattuda.
Õige ei ole kasutada ühe andmekogu juurde loodud kanalit teise andmekogu teenindamiseks,
kui selleks puudub selge õiguslik alus (ühe andmekogu juurde kuuluvat funktsionaalsust
kasutatakse ka teise kohta sisenemiseks, sest sellisel juhult toimub õiguslikult ühe andmekogu
kaudu teise juurdepääsuhalduste teenindamine). Ristteenuste pakkumisel tuleks luua suurem
õigusselgus ja sätestadagi norm, mis viitab selgel sellele, et andmekogu (või andmelao)
juurdepääs tagatakse teise andmekogu(lao) kaudu (üle tuleks vaadata siis ka vastutava/volitatud
töötleja suhted ja põhjendada sellise lahenduse valikut).
36
AvTS § 436 lg 2, https://www.riigiteataja.ee/akt/110032022004#para43b6
37
Näiteks MKS § 29 toodud konkreetne ja kinnine loetelu isikutest, kellele andmeid jagada,
https://www.riigiteataja.ee/akt/129122022030#para29 või tervise infosüsteem, mille suur osa põhiandmetest
tekib arsti ja patsiendi usaldussuhtest ning mille töötlusest registris, ei saa pooled keelduda, TTKS § 59 2 lg 1,
https://www.riigiteataja.ee/akt/110102022004#para59b2.
20 / 21
3.6. Kas ühe andmekogu sees peavad andmed liikuma X-tee vahendusel - näiteks
andmete liigutamine andmekogu erinevate kihtide või operatiivbaasi ja lao
vahel?
Andmekogude siseselt ei pea andmed liikuma X-teel. Kui eesmärk on tagada suurem
läbipaistvus, siis seda saab tagada ka andmekogude logide pinnalt ilma, et selleks X-teed
kasutatakse. Kehtiv AvTS viitab täna selgelt, et kohustus X-teed kasutada kehtib andmekogude
vahelises suhtluses ja nendega seotud kolmanda osapoolega (teenused ehk andmevahetus
ettevõtetega). Kui seda põhimõtet soovitakse tulevikus muuta, tuleks ümber vaadata ka
andmekogudele (ja toetavatele süsteemidele) rakenduvad sätted.38
3.7. Mis on andmelao ja -järve vahe lihtsustatult?
Andmejärv on koht, kus on meeletus koguses andmeid, enamus andmed on seal mis iganes
kujul nad sinna saadeti või kuskil mujal talletati. Näiteks kui asutus A on teinud oma
infosüsteemi andmebaasi ja asutus B teinud täiesti teistsuguse infosüsteemi, siis nad mõlemad
võivad panna enda andmed andmejärve "ujuma". Andmed on seega andmejärves sellised, nagu
need olid A ja B infosüsteemides. Andmete suure erinevuse tõttu on andmejärv hea
masinõppeks, aga ei ole väga hea ärianalüütikaks. Kuigi vahel räägitakse ka andmejõest, siis
see on andmejärvega sarnane, lihtsalt selles on andmed lühiajaliselt või siis lisandub neid sinna
jooksvalt.
Andmeladu on aga koht, kuhu on talletatud andmed, mis on teatud põhimõtetele ja mudelitele
vastavalt juba struktureeritud. Eelmise näite jätkamiseks siis võiks asutuse A ja B andmed nüüd
olla andmelaos nii, et nad on omavahel võrreldavad - ehk sarnased andmed (näiteks
isikuandmed) on andmelaos sarnasel kujul, kui andmejärves oleksid nad erinevad. Andmeladu
on tihti eelduseks ärianalüütikaks, andmepõhiseks juhtimiseks, raportiteks jms.
38
Nt sätestab AvTS § 439 lg 5: Andmevahetus riigi infosüsteemi kuuluvate andmekogudega ja riigi infosüsteemi
kuuluvate andmekogude vahel toimub läbi riigi infosüsteemi andmevahetuskihi,
https://www.riigiteataja.ee/akt/110032022004#para43b9.
21 / 21
IT-Profiil (versioon: 3)
Sotsiaalministeeriumi valitsemisala riist- ja tarkvara ning e-teenuste üldine haldamise ja arendamise infotehnoloogiline profiil
Üldsätted
1. Infotehnoloogilise profiili (edaspidi IT profiili) eesmärgid on:
1. kirjeldada Tervise ja Heaolu Infosüsteemide Keskuse (edaspidi TEHIK) hallatava riist- ja tarkvara tüüpkonfiguratsioone ja nende
miinimumparameetreid;
2. haldus-, hooldus- ja koolituskulude vähendamine olemasolevale infosüsteemile;
3. tekkida võivate probleemide ja kulude minimeerimine läbi erinevate infosüsteemi osade integreerimise;
4. jätkuva arengu garanteerimine kõigile kasutatavatele infotehnoloogilistele (edaspidi IT) lahendustele Sotsiaalministeeriumi haldusalas;
5. kasutatava tarkvara ja riistvara ühtsuse saavutamine, mille abil on tsentraliseeritud hangete kaudu võimalik märkimisväärselt kokku hoida;
6. süsteemidele mõjuvate turvariskide minimeerimine;
7. tekitada süsteemide kasutajatele efektiivne, turvaline ja mugav töökeskkond;
2. Karbitoodete valikul ja implementeerimisel rakendada IT profiili võimalikult suurel mahul. IT profiilist kõrvalekalded on lubatud, kui need on
möödapääsmatud ja TEHIK arhitektuurinõukogus kooskõlastatud;
3. IT profiili korrigeeritakse vastavalt vajadusele kuid mitte harvemini kui üks kord aastas. Muudetud IT profiil kinnitatakse TEHIK arhitektuurinõukogu
poolt;
Tehnilised nõuded e-teenustele, lähtudes TEHIK'u hallatavatest infosüsteemidest ja infrastruktuurist
1. IT toodete ja komponentide valiku põhimõtted on:
1. sama funktsionaalsusega, kuid erinevate tootjate komponentide arv peab olema viidud miinimumini. Standard riistvara soetamisel
eelistada soovitavalt ühe tootja seadmeid, mis tagab kogu IT infrastruktuuri parema toimivuse ja seadmete ühilduvuse;
2. kõik valitud tooted peavad vastama kehtivatele standarditele, eelistada tuleb avatud standardeid;
3. testistaadiumis (beta, release candidate jne) tarkvara võib kasutada ainult testimise eesmärgil;
4. komponendid ja tooted peavad vastama asutuse poolt määratud turvareeglitele;
5. komponentide ja toodete, mis ei ole antud dokumendis kajastatud, kasutusele võtmine vajab eelnevat arhitektuurinõukogu heakskiitu;
Kehtib nii olemasolevate süsteemide uuendamise kui ka uute süsteemide loomise kohta (Applies to building brand new systems and also to
refactoring existing systems)
Komponent Eelistatud Aktsepteeritav Mitte valida
Kommentaarid
(Component) (Preferred) (Acceptable) (Do not select)
Kliendi kiht (Client Layer)
Lauaarvuti ja sülearvuti
• Linux
OS / keskkond (Desktop & • Windows
• macOS
laptop client OS /
environment)
Lauaarvuti ja sülearvuti • Safari (väline
• Chromium based • Edge Legacy
kliendi kasutajaliides klient/external
• Firefox • Internet Explorer
(Desktop & laptop client client)
user interface)
• Android perekond
Mobiilse kliendi OS /
(Android family) • Windows Phone
keskkond (Mobile client
• iOS
OS / environment)
• Multi platform
• Multi platform
frameworks
• Chromium based frameworks
Mobiilse kliendi o Flutter
• Firefox o .Net based
kasutajaliides (Mobile o Kotlin
• Safari o Nativescript
client user interface) Multiplatform
o Ionic
• Native app
Esitluskiht (Presentation Layer)
Sisuhaldussüsteem • Strapi[1] • Joomla! [1] Tuleb TEHIKu arhitektiga
• Drupal
(Content management • WikiJS[1] • WordPress kooskõlastada (Must be
system) coordinated with TEHIK architect)
• Java
• JavaScript o JSP
• JavaScript
Esitluskihi raamistik o Next.JS[1] o JSF [1] Tuleb TEHIKu arhitektiga
o Angular
(Presentation framework o Single-SPA • iFrame kooskõlastada (Must be
o React
(View)) o Web-pack • Microsoft .Net coordinated with TEHIK architect)
• Python
• Apache HTTP
• Nginx • Microsoft IIS
Veebiserver (Web server) server
IT-Profiil (versioon: 3)
• Selenium • Cypress[1] [1] Tuleb TEHIKu arhitektiga
Funktsionaalne testimine
• Selenide • Playwright[1] kooskõlastada (Must be
(Functional testing)
coordinated with TEHIK architect)
Rakenduskiht (Application Layer)
• Java
o Micronaut
• C#
[1] Kogu Springi perekond (All
o .Net
• Java Spring family)
• Java o .Net
Rakenduse raamistik o Spring[1]
o Quarkus[2] Framework
(Application framework) o Spring boot [2] Tuleb TEHIKu arhitektiga
o ASP.NET
o Entity kooskõlastada (Must be
coordinated with TEHIK architect)
Framework
Core
Protsessimootor • Zeebe
(Workflow Engine)
• Java • Java
[1] Tuleb TEHIKu arhitektiga
Andmeloogika o JPA o Hibernate[1]
kooskõlastada (Must be
(Persistence framework) o JDBCTemplate o jOOQ
coordinated with TEHIK architect)
Otsingumootori indeks • Elasticsearch
(Search Engine Index)
[1] RabbitMQ
• GraphQL[2]
Integratsioon (External • AMQP [1]
• Oracle Advanced
• gRPC[2]
integration (integration to • REST Queuing [2] Tuleb TEHIKu arhitektiga
• SOAP
other systems)) kooskõlastada (Must be
coordinated with TEHIK architect)
[1] TEHIKu toode (TEHIK's
product)
• Apache Hop • Meltano[2]
Andmete laadimine (Data
• OData consumer [1] • Pentaho[2]
Loading - ETL) [2] Tuleb TEHIKu arhitektiga
kooskõlastada (Must be
coordinated with TEHIK architect)
• Webmethods
Integration Server
• .NET
o MS IIS
• Java
o Apache
• Java JServ
o Tomcat o Sun Java
o Embedded System
• Java
Aplikatsiooniserver ▪ Jetty Application
o WildFly [1] [1] VM põhine (VM based)
(Application server) ▪ Tomcat Server
▪ WildFly o SAP
o GraalVM o IBM
WebSphere
o Oracle iAS
o Oracle
iPlanet
Web Server
o WebLogic
• Insomnia
Funktsionaalne testimine • Postman
• SoapUI
(Functional testing)
• Jmeter
Koormustestimine (Load • Testkube
• Gatling
testing)
Andmekiht (Persistence Layer / Database layer)
Andmebaasi migratsioon • Liquibase • Flyway
(Database migration)
• MS SQL Server
Relatsiooniline [1] Tuleb TEHIKu arhitektiga
• PostgreSQL • MariaDB[1] • Oracle DB
andmebaas (Relational kooskõlastada (Must be
• Sybase
DBMS) coordinated with TEHIK architect)
IT-Profiil (versioon: 3)
[1] Tuleb TEHIKu arhitektiga
• MongoDB [1]
kooskõlastada (Must be
• KeyDB • Redis
Mitte ainult SQL (NoSQL) • Valkey[2] coordinated with TEHIK architect)
[2] https://valkey.io/
Andmeladu (Data • Vertica • Sybase IQ
Warehouse)
Andmete replikatsioon • Spilo
(Data Replication)
• S3 protokollil • Failid
Failide hoiustamine • MinIO põhinevad andmebaasis
(Object Storage) objektihoidlad (BLOB)
Infrastruktuuri kiht (Infrastructure Layer)
• MS Active Directory
Directory services
[1] TEHIK SSO on
Autentimine ja Ühekordne asutuseväliste kasutajate vaates
• GovSSO • TEHIK SSO [1]
sisselogimine (Authentication liikumas toe lõppemise suunas.
and Single Sign On) (TEHIK SSO is moving
towards end of life)
[1] https://www.ria.ee/riigi-
infosusteem/kesksed-
platvormid-avalike-e-teenuste-
pakkumiseks/paasuke
• TEHIK SSO + rollide api [2] On mõeldud siseste kasutajate
• Pääsuke [1]
Kasutajaõiguste haldus teenuse pool[3] rollide jaoks (Is ment for inside
• TEHIK SSO AD realm[2]
(Authorization) • MS AD (siseteenused) user rolls)
[3] TEHIK SSO on asutuseväliste
kasutajate vaates liikumas toe
lõppemise suunas. (TEHIK SSO
for external users is moving
towards end of life)
[1] Tootel on saabumas eluea
lõpp (Product is moving towards
Identiteedi haldus • MIM[1] end of life):
(Identity management) https://learn.microsoft.com/en-
us/lifecycle/products/microsoft-
identity-manager-2016
• Elastic Agent/Elastic • GreyLog
Logihaldus (Log Beats/Logstash • Windows Event
management) • rsyslog Collector
Süsteemi haldamine ja • Prometheus
järelevalve (System • Grafana • Zabbix • Nagios
management and • Elastic APM
monitoring)
Koormusjaotur (Traffic • Nginx • HAProxy
management)
• Squid
• Nginx
Puhverdamine (Caching) • Varnish
• Application specific
decision ie Quartz or
Tööde ajastamine (Job cron, windows
scheduling) scheduler
• k8s CronJob
• Linux (Tootja poolt
viimane pikaajalise • Linux
toega või stabiilne o Debian
Serveri • Windows
versioon) o CentOS
operatsioonisüsteem o MS (64 bit)
o Oracle Linux • IBM AIX
(Server OS)
o RedHat • Other UNIXs
o Ubuntu
IT-Profiil (versioon: 3)
• OCI compliant[1]
Konteinerid (Containers) [1] https://opencontainers.org
Konteinerite
• Kubernetes • Docker Swarm
orkestreerimine (Contaier
orchestration)
• Hyper-V
• QEMU/KVM
Virtualiseerimine • VmWare
• OracleVM
(Virtualization)
• Xen
Serveri riistvara (Server • x86_64 • RISC
hardware)
• VmWare
o Veritas
• Symantec Backup
Netbackup
Varundamine (Backup) Exec
• Kubernetes
o S3
• SAN • SAN
Kettakasti riistvara • iSCSI
o FC >= 32 Gb/s o FC >= 16 Gb/s
(Storage hardware)
Riistvaraline
krüptomoodul (HSM - • Thales • Utimaco
Hardware security
module)
• DPI (Deep packet
inspection) Layer 7
Tulemüür (Firewall) Pahavara tõrje (Anti-
malware)
Muud aspektid (Other Aspects)
• Go[1] [1] Tuleb TEHIKu arhitektiga
• NET
• JavaScript kooskõlastada (Must be
• C/C++/C#
• Java • Kotlin[1] coordinated with TEHIK architect)
Programmeerimiskeeled • Webmethods flow
• TypeScript • Python[1]
(Programming languages) • iWay Functional
• PHP[1] [2] Krüptograafiliste tegevuste
Language
• Rust[1][2] teostamiseks (To perform
cryptographic activities)
Java virtuaalmasina
implementatsioon (Java • OpenJDK • Oracle JDK
vitual machine
implemetation)
• GitLab
o Koodivaramu[1]
• SVN [1] Tuleb TEHIKu arhitektiga
Versioonihaldus (Version o TEHIK • GitHub[1]
• Atlassian Bitbucket kooskõlastada (Must be
control system) haldusalas
coordinated with TEHIK architect)
olev
• DockerHub[1]
• JFrog artifactory [1] Tuleb TEHIKu arhitektiga
Artefaktide repositoorium • GitHub Packages[1]
• Gitlab registry kooskõlastada (Must be
(Artifacts repository) • npmjs.com[1]
coordinated with TEHIK architect)
• Jenkins [1] Tuleb TEHIKu arhitektiga
Pidev integratsioon • Gitlab CI • Github Actions[1]
• Bamboo kooskõlastada (Must be
(Continuous integration)
coordinated with TEHIK architect)
• Ansible
Paigalduse automaatika • GitLab CD (dev/test) • GitHub Actions[1] • Jenkins [1] Tuleb TEHIKu arhitektiga
(Continious Deployment / • Helm (live) • Argo CD[1] • Bamboo kooskõlastada (Must be
Delivery) • Terraform coordinated with TEHIK architect)
Lähtekoodi analüüs (Code • SonarQube
analysis)
Tarkvara materjalide
• CycloneDX SBOM
loend (SBOM - software
bill of materials)
Tarkvara materjalide • Dependency-Track[1]
[1] https://dependencytrack.org
loendi analüsaator
IT-Profiil (versioon: 3)
(software bill of materials
analysis platform)
• Webfocus
• Qlik Sense
[1] Tuleb TEHIKu arhitektiga
• Tableau • Apache Superset[1] • Oracle BI Publisher
Analüütika (Analytics) kooskõlastada (Must be
• SAP® Business
coordinated with TEHIK architect)
Objects
Serverid
1. Riistvara standard
1. X86-64 platvorm
2. Dubleeritud komponendid (toiteplokid, ventilaatorid jms.)
3. Kuumvahetatavad kettad
4. Kaughaldusliidese olemasolu koos vajalike funktsioonide litsentseeritusega (irdmeedia tugi jms.), kaughaldusliides peab toimima
modernsete veebilehitsejatega ilma java/flash toeta)
5. Ostetaval riistvaral peab võimalusel olema vähemalt kaks teineteisest sõltumatut (st. ei tohi olla sama firma/grupi koosseisus) volitatud
hooldus/garantiiteenuse pakkujat
6. Riistvara ostetakse reeglina kolme aastase NBD toega koos nõudega, et kriitiliste varuosade vaheladu peab olema Eestis kohapeal.
1. SKAIS andmeladu info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Serverid ja ühendused . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Arendus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Automaatprotsesside käivitamine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Ligipääsud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5 SLA (arendustööde tingimused / rakenduste teenustasemed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2. SKAIS1 andmeladu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1 SKAIS1 andmemudel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 SKA DW andmebaas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 SKA DW andmete laadimine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 SKA DW süsteemsed tabelid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4.1 COLUMNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.2 DATA_SOURCE_PARAMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.3 DATA_SOURCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.4 DATA_TYPE_CONVERSIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.5 DWH_SCHEMAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4.6 EVENT_LOG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4.7 IMP_COLUMNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.8 IMP_SCHEMAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.4.9 IMP_TABLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4.10 LOAD_LOG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4.11 SCHEMAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4.12 TABLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.5 SKA DWH Pentaho Data-Intergration paigaldusjuhend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.6 SKA DWH Vertica ühendumise juhend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.7 Skeemid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.8 Täislaadimiste tegemine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.9 Logimine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3. SKAIS2 andmeladu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.1 Laadimiste haldus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2 Logid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3 Pentaho PDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.4 SKA SKAIS2 DW andmebaas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.5 SKA SKAIS2 DW andmete laadimine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.6 SKA SKAIS2 DWH Pentaho Data-Intergration paigaldusjuhend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.7 SKA SKAIS2 DWH Vertica ühendumise juhend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.8 SKA SKAIS2 DW süsteemsed tabelid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.8.1 COLUMNS SKAIS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3.8.2 DATA_SOURCE_PARAMS SKAIS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.8.3 DATA_SOURCES SKAIS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
3.8.4 DATA_TYPE_CONVERSIONS SKAIS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
3.8.5 DMARTS SKAIS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.8.6 DWH_SCHEMAS SKAIS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
3.8.7 EVENT_LOG SKAIS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
3.8.8 IMP_COLUMNS SKAIS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
3.8.9 IMP_SCHEMAS SKAIS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
3.8.10 IMP_TABLES SKAIS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
3.8.11 LOAD_LOG SKAIS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
3.8.12 PARAMETERS SKAIS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
3.8.13 ROW_COUNTS SKAIS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
3.8.14 SCHEMAS SKAIS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
3.8.15 TABLES SKAIS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
3.9 Skeemid Skais2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
1
SKAIS andmeladu info
SKAIS andmelaos laaditakse Skais1 ja Skais2 Oracle andmebaasidest andmed lao Vertica andmebaasi - andmelao kihtide skeemidesse.
Laadimist teostab (ühendused loob) Pentaho PDI, millele on ehitatud laadimismootor (PDI skriptid) Resta poolt.
Laadimismootor otsustab Verticas asuva info põhjal (ADM skeemid) - kust, mida, kuidas ja kuhu laadida ning tegeleb logimise, veahalduse ja teavitusega.
Tähtsaimad viited
Serverid ja ühendused
Arendus
Automaatprotsesside käivitamine
SKAIS1
SKA DW andmebaas
SKA DW andmete laadimine
Logimine
Skeemid
SKAIS2
SKA SKAIS2 DW andmebaas
SKA SKAIS2 DW andmete laadimine
Logid
Skeemid Skais2
Kontaktid
2
SKA äripoole kasutaja - Meelis Põlda.
SKAIS2 Oracle kontakt TEHIK-us - RAIN
Pentaho ja Vertica - Matthias Johann Kurs
Graafikuid ja kirjeldusi koostab Resta OÜ.
3
Serverid ja ühendused
Test
Hetkel testkeskkond puudub (SKANDL-82)
Live
Pentaho DI ehk laadimisi käivitav server - pentaho-vertica-1a (10.11.25.27)
Vertica ehk andmelao andmebaas - wrh-db.prd.tehik.ee (10.11.11.182)
Vertica andmebaasil on 4 node-i:
v_wrh_db_node0001 10.11.25.101
v_wrh_db_node0002 10.11.25.102
v_wrh_db_node0003 10.11.25.103
v_wrh_db_node0004 10.11.25.104
Andmebaasid
Vertica (target Skais1 ja Skais2) - wrh-db.prd.tehik.ee:5433/wrh_db
Skais1 ja Skais2 andmeladu asub samas Vertica andmebaasis, eraldatud skeemides
Oracle (source Skais2) - skais2db1.ml.ee:1521/SKAIS2APP
Oracle (source Skais1) - skaprddb1.ml.ee:1521/SKAPRDAPP
Kasutajad (millega PDI loob ühendused baasidega)
Skais1 Oracle ühendus - SKA_ANDMEAIT
Skais2 Oracle ühendus - SKA_ANDMEAIT
Skais1 Vertica ühendus - pentaho
Skais2 Vertica ühendus - pentaho_skais2
Ühendustel vertica baasi kasutada tlsmode=require
4
Arendus
GIT
Arendus toimub Tehik gitlab versioonihaldus platvormil
SKAIS1 PDI skriptid
https://gitlab.sotsiaalministeerium.ee/skandl/skais_dwh/skais1_pentaho.git
SKAIS2 PDI skriptid
https://gitlab.sotsiaalministeerium.ee/skandl/skais_dwh/skais2_pentaho.git
SKAIS2 Vertica skriptid ehk tarned
https://gitlab.sotsiaalministeerium.ee/skandl/skais_dwh/skais2_vertica.git
PDI skriptid
PDI skrtipide (kjb, ktr, kdb) repositooriumi paigaldamisel jälgida, et nendes ei oleks ühenduste paroole (Encrypted *****)
Õigused
Uute objektide lisamisel (tabelid, vaated) lisab arendaja ka õigused. Täpsemalt Ligipääsud
5
Automaatprotsesside käivitamine
SKA andelao laadimised toimuvad ühe peamise Pentaho job faili kaudu, mida käivitatakse crontab olevast sh skriptis.
Hetkel laetakse SKAIS1 ja SKAIS2 andmebaasi andmelao vertica-sse wrh-db.prd.tehik.ee
SKAIS1 laadimise loogika on täpsemalt kirjeldatud lehel SKA DW andmete laadimine
SKAIS2 laadimise loogika on täpsemalt kirjeldatud lehel SKA SKAIS2 DW andmete laadimine
Ajastus
Skais 1 laadimine algab iga öö kell 1:00. Kestab umbes 3h
Skais 2 laadimine algab iga öö kell 2:00, kuid ei lae kuu viimasel päeval ning 1-8 kuupäev kaasaarvatud. Kestab umbes 2h30m
Crontab
Serveris pentaho-vertica-1a käivitatakse sh skript, mis omakorda käivitab PDI job.
Käivitatakse kasutaja pentaho alt
sudo su - pentaho
Lisatud crontab kirjed, kus kutstakse shelli skript välja:
crontab -e
##Skais1 live
00 01 * * * /home/pentaho/load_all_skais1_live.sh
##Skais2 live
00 02 * * * /home/pentaho/load_all_skais2_live.sh
Antud juhul käivitatakse Skais1 laadimine igaöiselt kell 1:00 ja Skais2 2:00.
Laadimise peatamiseks kommenteerida see välja crontab-is # märgiga
Laadimis skripti näide:
###Adjust if needed
PDI_DIR=/opt/etl/data-integration94
REPO=skais2_v2_live
SUBDIR=/dwh_loader
JOB=load_one_ds
LOGLVL=Basic
LOGDIR=/var/logs/pentaho
ADM_SCHEMA=ADM_SKAIS2
LOGNAME=load_all_skais2_live.log
#Lisaks kuupäeva ja logi roteerumise loogika
nohup $PDI_DIR/kitchen.sh -rep=$REPO -dir=$SUBDIR -job=$JOB -param:adm_schema=$ADM_SCHEMA -param:
is_dynamic_model=0 -level=$LOGLVL > $LOGDIR/$CDATE-$LOGNAME 2>&1 &
Ehk käsitsi käivitades SKAIS2 puhul
nohup /opt/etl/data-integration94/kitchen.sh -rep=skais2_v2_live -dir=/dwh_loader -job=load_one_ds -param:adm_schema=ADM_SKAIS2 -param:
is_dynamic_model=0 -level=Basic > /var_logs_pentaho/2025-10-31-load_all_skais2_live.log 2>&1 &
6
Ligipääsud
Uued skeemid
Kui laadimine peaks toimuma uute skeemi, siis arendaja koostab nende lisamiseks itabi (
[email protected]) tellimuse (sh. lisab kirja CC reale TEHIK-u
projektijuhi). Tellimuse kirjeldus allpool.
Selle tellimusega peaks loodama skeemid, vastavad skeeminimi_viewer ja skeeminimi_owner rollid ning antama õigused üldistele ska_owner,ska_viewer,
ska
Uued tabelid
Uute tabelite lisamisel arendaja lisab õigused vastavale skeemi rollidele:
create table ab.abc( c int);
grant select on ab.abc to ab_viewer;
grant all on ab.abc to ab_owner;
Näiteks:
grant select on ACTIVITY_CATEGORY,DOMAIN_CATEGORY,EXP_DEVIATION_ICF_CATEGORY,LOG_ACTIVITY_CATEGORY,LOG_DOMAIN_CATE
GORY,LOG_EXP_DEVIATION_ICF_CATEGORY
to DW_SKAIS_DOCTOR_ASSESSMENT_ODS_VIEWER;
Skais2 andmelao ligipääsude tellimine
Ligipääsud on skeemi põhised ning ligipääsud tellitakse skeemile.
Ligipääsud üldiselt tellitakse rollidele, mitte kasutajatele.
https://gitlab.sotsiaalministeerium.ee/andmelaod/datawarehouse/ska
Ska rollid
ska skeem on ska analüütikute tootearendus/liivakast skeem. Selleks, et ska analüütikud saaksid oma tabeleid ja objekte oma skeemi luua oleks tarvis
neile anda rollid:
ska - teenuskonto(andmebaasi kasutaja) ja andmebaasi skeem
ska_viewer - roll, mis anna vaatmisõigused kõikidele skais1 ja skais2 skeemidele ska_owner - roll, mis anna vaatmisõigused kõikidele skais1 ja skais2
skeemidele ning objektide loomise õiguse ska skeemi
Selleks, et ska_viewer ja ska_owner rollid toimiksid peab iga kord kui luuakse uus ska skeem andma nimetatud rollidele loodud skeemidele SELECT ja
USAGE õigused:
Näiteks DW_SKAIS_DOCUMENT_MANAGEMENT_ODS ja DW_SKAIS_DOCUMENT_MANAGEMENT_STG skeemide loomise järel tuleks andmebaasis
käivitada:
GRANT SELECT,USAGE ON SCHEMA DW_SKAIS_DOCUMENT_MANAGEMENT_ODS to ska_viewer, ska_owner, ska;
GRANT SELECT,USAGE ON SCHEMA DW_SKAIS_DOCUMENT_MANAGEMENT_STG to ska_viewer, ska_owner, ska;
Nimetatud koodijupp tuleks lisada skeemi loomise tellimuse TKT piletisse ning antud repositoorimi ska.sql faili. Täiendada feature harus, ning saata merge
request Karl Kukk:
https://gitlab.sotsiaalministeerium.ee/andmelaod/datawarehouse/ska/-/blob/master/ska.sql
Tellimine
1. Täiendada ska.sql feature harus, ning saata merge request kellele?
2. Peale master jõudmist teha tellimus
a. Lisada SKAIS2 DWH live verticas skeemid - näiteks DW_SKAIS_DOCUMENT_MANAGEMENT_ODS,
DW_SKAIS_DOCUMENT_MANAGEMENT_STG
b. Lisada rollide õigused antud skeemile lähtudes õiguste init failist https://gitlab.sotsiaalministeerium.ee/andmelaod/datawarehouse/ska/-
/blob/master/ska.sql
GRANT SELECT,USAGE ON SCHEMA DW_SKAIS_DOCUMENT_MANAGEMENT_ODS to ska_viewer, ska_owner, ska;
GRANT SELECT,USAGE ON SCHEMA DW_SKAIS_DOCUMENT_MANAGEMENT_STG to ska_viewer, ska_owner, ska;
7
3. Peale skeemi tegemist ja õiguste lisamist saab tabelid laadimisse lisada
Kogu tellimuse näide:
Palun lisada skeemid ja õigused Skais2 DWH live. Seoses task SKANDL-78
CREATE SCHEMA DW_SKAIS2VALINE_STG;
CREATE SCHEMA DW_SKAIS2VALINE_ODS;
GRANT ALL ON SCHEMA DW_SKAIS2VALINE_STG TO pentaho_skais2;
GRANT ALL ON SCHEMA DW_SKAIS2VALINE_ODS TO pentaho_skais2;
GRANT SELECT,USAGE ON SCHEMA DW_SKAIS2VALINE_STG to ska_owner;
GRANT SELECT,USAGE ON SCHEMA DW_SKAIS2VALINE_ODS to ska_owner;
GRANT SELECT,USAGE ON SCHEMA DW_SKAIS2VALINE_STG to ska_viewer;
GRANT SELECT,USAGE ON SCHEMA DW_SKAIS2VALINE_ODS to ska_viewer;
8
SLA (arendustööde tingimused / rakenduste
teenustasemed)
SKA andmeladu
Teenuse parameeter Väärtus
ISKE turvaklass K1T1S2
Rakenduse tööaeg (millal laoplatvorm peab olema 07:00 - 19:00
kättesaadav)
Kasutajatugi (teenindusaeg) E-R 9.00-17.00
Planeeritud hooldusaeg 19.00 – 21.30
01.00 – 05.00
Minimaalne aeg teavitusest plaanilise katkestuseni 48 tundi
Maksimaalne plaanilise katkestuse kestvus 8 tundi
Maksimaalne plaaniliste katkestuste sagedus 8 korda kuus
Maksimaalne planeerimata katkestuste sagedus 8 korda kuus
Ühekordne maksimaalne planeerimata katkestuse 8 tundi
kestus
Summaarne maksimaalne plaanimata katkestuste 16 tundi
kestus kuus
Samaaegsete andmeanalüüsivahendite kasutajate Kuni 40 kasutajat korraga
arv
Samaaegsete aruannete kasutajate/päringute arv Kuni 120 kasutajat korraga
Laadimise piirangud Vaikimisi periood, millal SKAIS2 laadimisi ei tohi teostada on kuu viimasel päeval kuni
järgmise kuu 8 esimest päeva.
Seda perioodi võib Tellija muuta lähtuvalt ärivajadustest.
9
SKAIS1 andmeladu
10
SKAIS1 andmemudel
SKAIS1 andmemudel
11
SKA DW andmebaas
SKA DW andmebaasi (SKA andmelao) andmebaasisüsteemina kasutatakse spetsiaalselt analüütilisteks lahendusteks optimeeritud veerupõhist
andmebaasimootorit OpenText Vertica.
SKA DW andmebaas jaguneb andmete laadimise loogika mõttes kahte kihti:
1. Eellaadimise ala (staging ehk STG-kiht) sisaldab andmete laadimise tööks vajalikke andmetabeleid (ajutised andmed).
STG-kihi andmetabelite struktuur on täpselt sama, mis on lähtesüsteemi andmetabelitel (mõningased erinevused võivad tulla sellest, kuidas
erinevad andmebaasisüsteemid (Oracle ja Vertica) salvestavad sarnaseid andmetüüpe nt varchar2(100) Oracles vs varchar(100) Verticas).
Tüüpiliselt laaditakse igaöise laadimise käigus STG-kihti viimase ööpäeva jooksul lähtesüsteemidesse lisatud ja/või seal muudetud andmed.
Erandjuhtumitel (kui lähtesüsteemis muudetud kirjete tuvastamine ei ole võimalik), teostatakse tabelile igal öösel täislaadimine. Eeskirjad, millist
andmete laadimise meetodit ja see, kas vastava tabeli andmeid üldse SKAIS1 andmelattu laaditakse, on kirjeldatud süsteemses andmetabelis
ADM.TABLES.
2. Operatiivne andmehoidla (Operational Data Store e ODS-kiht) sisaldab kõiki lähtesüsteemide andmebaaside andmeid (st kogu muudatuste
ajalugu alates andmelao laadimise alghetkest). ODS kihi andmemudel on sarnane lähtesüsteemi andmemudelile - igale lähtesüsteemi tabelile
vastab ODS kihis samanimeline tabel, mis sisaldab kõiki vastava andmetabeli välju ning nelja täiendavat välja kirjete versioneerimiseks.
Lisatavateks väljadeks on:
a. dwh_id - Surrogaatvõti (andmelao laadimisprogrammi poolt genereeritud võtmeväli)
b. is_valid - 0/1 väli, mis näitab, kas tegemist on kehtiva kirjega (kõige viimase versiooniga)
c. valid_from - versiooni kehtivuse algusaeg (kuupäev ja kellaaeg)
d. valid_to - versiooni kehtivuse lõppaeg (kuupäev ja kellaaeg)
Lisaks nimetatud kihtidele on eraldi skeem (nimega ADM_SKAIS1), mis sisaldab andmete laadimiseks ning muuks SKA DW toimimiseks vajalikke
andmetabeleid.
12
SKA DW andmete laadimine
Andmete laadimiste üldine loogika
SKA_DW andmete laadimine toimub järgmise skeemi kohaselt
1. Lähtesüsteemi (SKAIS) andmemudeli muudatuste tuvastamine (sh SKA DW andmemudeli uuendamine)
a. Lähteallika (SKAIS) andmebaasi süsteemsetest tabelitest loetakse lähtesüsteemi andmemudel ning salvestatakse see süsteemsetesse
tabelitesse ADM.IMP_SCHEMAS, ADM.IMP_TABLES ja ADM.IMP_COLUMNS
b. Lähteallika andmemudelit võrreldakse SKA DW poolt teada oleva mudeliga (st eelmisel päeval kehtinud andmemudeliga) ning
tuvastatakse muudatused.
c. Kõikide nende andmetabelite korral, mis on laadimisse sisse lülitatud (LOAD_STATUS = 'LOAD' või 'NEW_LOAD') korral SKA DW
andmemudelit (STG-tabeleid ja ODS-tabeleid) muudetakse vastavalt eelmises punktis tuvastatud muudatustele (lisatakse uued väljad,
muudetakse olemasolevate väljade tüüpe, lähtesüsteemist kustutatud väljade laadimine lülitatakse välja (LOAD_STATUS =
'NO_OBJECT').
2. Andmete import ja andmete laadimine STG ja ODS tabelitesse (iga tabeli korral võidakse kasutada erinevat andmete impordi meetodit, erinevat
lähtesüsteemist kustutatud kirjete tühistatuks märkimise meetodit jms Vt tabelite laadimise konfigureerimise võimalusi süsteemsete tabelite ADM_
SKAIS1.TABLES ja ADM_SKAIS1.COLUMNS kirjelduste juurest).
a. (Pärast viimast laadimist lisatud ja/või muudetud) andmete import STG tabelitesse (sh viimati laaditud andmete tuvastamine kasutades
ADM.TABLES.LAST_LOAD_EXPRESSION avaldist)
b. Andmete laadimine ODS tabelitesse (sh lähtesüsteemist kustutatud kirjete märkimine kehtetuks)
c. Lähtesüsteemi ja ODS tabeli kirjete arvu võrdlemine.
Andmelao laadimiste kohta tekib laadimiste logi. Laadimisprotsesside käivitamise ja lõpetamise teated salvestatakse laadimise logi tabelisse LOAD_LOG,
detailsemad tabelite loomise (sündmuste teated) salvestatakse tabelisse EVENT_LOG.
Laadimiste käitumine veaolukordades
Laadimise alguses kontrollitakse, kas eelmine (sama andmeallika) laadimine on lõppenud. Kui eelmine laadimise protsess ei ole lõppenud või lõppes
veaga ning ei ole märgitud, et viga tuleb ignoreerida, siis järgmist sama allika laadimisprotsessi ei käivitata.
Kui eelmise päeva laadimine sai vea ning vigane olukord on parandatud (st järgmisel päeval saab laadimist uuesti jätkata), siis tuleb laadimiste logi tabelis
IS_IGNORE väärtuseks panna 1 (st viga ignoreeritakse).
Juhul, kui mingi STG tabeli laadimise käigus tekib viga, siis STG tabelite laadimine töötab lõpuni, samuti käivitatakse ODS tabelite laadimine kuid vea
saanud tabeli korral vastava ODS tabeli laadimist ei käivitata.
Laadimiste tulemustest teavitamine
Laadimiste tulemuste teavitamiseks saadetakse e-mail aadressile .... (vastava e-mail'i aliase loob ning selle aliase taga paiknevaid konkreetseid e-mail'i
aadresse haldab TEHIK, e-mail'i alias tuleb sisestada tabelisse PARAMETERS parameetri to_email väärtuseks).
Juhul, kui laadimiste käigus ei tekkinud vigu ega hoiatusi, saadetakse e-mail teemaga "Andmeallika SKAIS1 laadimine õnnestus".
Juhul, kui laadimise käigus tekkis hoiatusi, saadetakse e-mail teemaga "Andmeallika SKAIS1 laadimisel esines hoiatusi!".
Juhul, kui laadimise käigus tekkis vigu, saadetakse e-mail teemaga "Andmeallika SKAIS1 laadimine sai vigu!" ning e-mail'i sisuks on vigade logi.
Juhul, kui tavapäraseks laadimise lõppemise ajaks ei ole e-mail'i saabunud, siis tuleb olukorda käsitleda veaolukorrana ning täpsemat infot on võimalik
leida logitabelitest ja/või Pentaho logist.
13
SKA DW süsteemsed tabelid
14
COLUMNS
Väljade/veergude andmed
Välja nimi Välja Selgitus Andmete näited
tüüp
COLUMN_VERSION int Surrogaatvõti 55
_ID
DATA_SOURCE_CO varchar Andmeallika/lähtesüsteemi kood 'SKAIS'
DE (20)
SOURCE_SCHEMA_ varchar Skeemi nimi lähtesüsteemis 'SKA_OWNER'
NAME (128)
SOURCE_TABLE_N varchar Tabeli nimi lähtesüsteemis 'AADRESS'
AME (128)
SOURCE_COLUMN_ varchar Välja/veeru nimi lähtesüsteemis 'AADRESS_KOOD'
NAME (128)
DWH_COLUMN_NA varchar Välja/veeru nimi andmelaos 'AADRESS_KOOD'
ME (128)
SOURCE_COLUMN_ varchar Välja/veeru kirjeldus lähtesüsteemis 'Kommentaar'
COMMENT (4000)
DWH_COLUMN_CO varchar Välja/veeru kirjeldus andmelaos 'Kommentaar'
MMENT (4000)
DATA_TYPE varchar Andmetüüp lähtesüsteemis 'VARCHAR2', 'INTEGER', 'DECIMAL'
(128)
DATA_LENGTH int Andmevälja pikkus lähtesüsteemis 1020
DATA_PRECISION int Andmevälja täpsus lähtesüsteemis 18
DATA_SCALE int Andmevälja täpsus peale koma 0
lähtesüsteemis
DWH_DATA_TYPE varchar Andmetüüp andmelaos 'VARCHAR(1020)'
(255)
NULLABLE char(1) Kas veerg võib sisaldada puuduvaid 1
(NULL) väärtusi (0/1)
IS_KEY int Kas veerg on primaarvõti (0/1) 0
LOAD_STATUS varchar Välja/veeru laadimise staatus 'LOAD' - Välja laadimine on sisse lülitatud
(20) andmelaos
'NEW_LOAD' - Tegemist on uue väljaga (st haldur pole välja laadimise staatust üle vaadanud
/kinnitanud), väli on laadimisse sisse lülitatud
'NEW_NOT_LOAD' - Tegemist on uue väljaga, väli ei ole laadimisse sisse lülitatud
'NOT_LOAD' - välja laadimine ei ole sisse lülitatud
'NO_OBJECT' - välja ei ole enam lähtesüsteemis (varem oli)
DWH_COLUMN_STA varchar Välja staatus andmelaos: 'NEEDS_CREATION' - väli vajab loomist
TUS (30)
'NEEDS_MODIFICATION' - väli vajab muutmist (näiteks lähteallikas on muutunud
andmetüüp)
'READY' - väli on loodud/muudetud
SOURCE_COLUMN_ int Välja/veeru ID lähtesüsteemis 11
ID
IS_VALID int Kas tegemist on kehtiva kirje 1
/versiooniga (0/1)
VALID_FROM timesta Kirje/versiooni kehtivuse algusaeg '2018-05-04 17:26:58'
mp
VALID_TO timesta Kirje/versiooni kehtivuse lõppaeg '2018-05-04 11:22:58'
mp
MODIFIED_BY varchar Kirje looja/muutja 'pentaho'
(32)
15
DATA_SOURCE_PARAMS
Lähtesüsteemi andmebaasi parameetrid
Välja nimi Välja tüüp Selgitus Andmete näited
DATA_SOURCE_CODE varchar(20) Andmeallika/lähtesüsteemi kood 'SKAIS'
DB_SERVER_NAME varchar(32) Serveri nimi või IP aadress 'test-test.ml.ee '
DB_PORT_NR int Pordi number 1234
DB_NAME varchar(32) Andmebaasi nimi 'TSKAIS'
DB_USERNAME varchar(32) Kasutajanimi 'SKAIS_USER_NAME'
DB_PASSWORD varchar(128) Parooli räsi (luuakse pentaho encr.sh abil). Vt täpsemalt paigaldusjuhendist. 'Encrypted 0123456789ABCDEF'
16
DATA_SOURCES
Andmeallikad (lähte-andmebaasid)
Välja nimi Välja Selgitus Andmete näited
tüüp
DATA_SOURCE_VERS int Andmeallika versiooni ID. Surrogaatvõti. 1
ION_ID
DATA_SOURCE_CODE varchar Andmeallika/lähtesüsteemi kood. 'SKAIS'
(32)
DATA_SOURCE_NAME varchar Lätesüsteemi nimetus 'Töötukassa aruandlusmoodul'
(128)
DATA_SOURCE_TYPE varchar Lähtesüsteemi tüüp 'SOURCE_DB' - lähtesüsteemiks on
(20) andmebaas
DBMS_TYPE varchar Andmebaasi tüüp 'ORACLE'
(20)
IS_ACTIVE int Kas lähtesüsteemist andmete laadimine on aktiivne (võimaldab terve lähtesüsteemi 1
laadimise korraga välja lülitada)
IS_LOAD_TABLES int Kas lähtesüsteemist laaditakse andmetabeleid (table) 0
IS_LOAD_VIEWS int Kas lähtesüsteemist laaditakse vaateid (view) 0
IS_LOAD_MVIEWS int Kas lähtesüsteemist laaditakse materialiseeritud vaateis (materialized view) 1
IS_VALID int Kas tegemist on kehtiva kirje/versiooniga (0/1) 1
VALID_FROM timestamp Kirje/versiooni kehtivuse algusaeg '2018-05-04 17:21:26'
VALID_TO timestamp Kirje/versiooni kehtivuse lõppaeg '2018-05-04 17:55:00', NULL
MODIFIED_BY varchar Versiooni lisaja/muutja 'SYSTEM'
(32)
17
DATA_TYPE_CONVERSIONS
Välja tüüpide teisendustabel
Välja nimi Välja tüüp Selgitus Andmete näited
ID int Surrogaatvõti 2
DBMS_TYPE varchar(20) Lähtesüsteemi andmebaasi tüüp 'ORACLE'
DATA_TYPE varchar(128) Andmetüüp lähtesüsteemis 'DATE'
DATA_LENGTH int Andmevälja pikkus lähtesüsteemis 10
DATA_PRECISION int Andmevälja täpsus lähtesüsteemis 1
DATA_SCALE int Andmevälja täpsus peale koma lähtesüsteemis 1
TARGET_DATA_TYPE varchar(128) Andmetüüp (sh pikkus ja täpsus) andmelaos 'DATETIME'
18
DWH_SCHEMAS
Andmelao skeemide andmed.
Iga siin kirjeldatus skeemi kohta luuakse andmelaos vähemalt 2 skeemi (<skeemi nimi>_STG - vastava loogilise andmeallika staging tabelite skeem,
<skeemi_nimi>_ODS - vastava loogilise andmeallika ODS tabelite skeem). Lisaks luuakse vajaduse korral (kui HAS_DMARTS = 1) skeem <skeemi
nimi>_DMART, mis sisaldab vastava andmeallika dimensiooni- ja faktitabeleid ja andmelette.
Välja nimi Välja Selgitus Andmete näited
tüüp
DWH_SCHEMA_VERSIO int Skeemi versiooni ID 1
N_ID
DWH_SCHEMA_NAME varchar(32) Andmelao skeemi/loogilise andmeallika nimi 'ORACLE'
DWH_SCHEMA_COMME varchar Andmelao skeemi kirjeldus 'Töötute registreerimise, tööturuteenuste ja -toetuste menetlemise
NT (255) infosüsteem'
DWH_SCHEMA_STATUS varchar(30) Andmelao skeemi staatus 'NEEDS_CREATION' - skeem on loomata
'NEEDS_MODIFICATION' - skeemis on objekte (tabeleid), mida on
vaja muuta
'READY' - skeem ja kõik seal olevad objektid on loodud/muudetud
HAS_DMARTS int Kas skeem sisaldab andmelette 1
IS_ACTIVE int Kas skeemi/loogilise andmeallika andmete laadimine 1
on aktiivne.
IS_VALID int Kas tegemist on kehtiva kirje/versiooniga (0/1) 0
VALID_FROM Timestamp Kirje/versiooni kehtivuse algusaeg '2018-05-04 17:21:26'
VALID_TO Timestamp Kirje/versiooni kehtivuse lõppaeg '2018-05-04 17:26:57'
MODIFIED_BY varchar(32) Versiooni lisaja/muutja 'pentaho'
19
EVENT_LOG
Sündmuste logi
Välja nimi Välja Selgitus Andmete näited
tüüp
EVENT_ID int Sündmuse ID. Primaarvõti. 1
EVENT_DT Timestamp Sündmuse toimumise/registreerimise kuupäev ja kellaaeg '2018-05-04 17:21:25'
EVENT_CLASS varchar(20) Sündmuse grupi kood. Võimalikud väärtused: 'INSTALLATION',
'LOADING'
INSTALLATION -
EVENT_TYPE varchar(20) Sündmuse tüüp. Võimalikud variandid: 'ERROR'
ERROR - viga, WARNING - hoiatus, SUCCESS - edukas tegevus, INFO - teade
EVENT_MESSAGE varchar(255) Sündmuse kirjeldus 'ERROR in loading STG
table'
RELATED_OBJECT varchar(50) Sündmusega seotud objekt (nt tabeli nimi, lähteallika nimi vms). Konkreetne objekt sõltub sündmuse 'ADM.TABLES'
koodist.
PROCESS_NAME varchar(50) Pentaho protsessi nimi, mis sündmuse tekitas 'run_upgrade'
STEP_NAME varchar(50) Pentaho sammu (step) nimi, mis sündmuse tekitas 'schema & main tables'
20
IMP_COLUMNS
Välja nimi Välja tüüp Selgitus Andmete näited
DATA_SOURCE_CODE varchar(32) Lähtesüsteemi kood 'SKAIS'
SCHEMA_NAME varchar(128) Välja/veeru nimi lähtesüsteemis 'SKA_OWNER'
TABLE_NAME varchar(128) Tabeli nimi lähtesüsteemis 'AADRESSID'
COLUMN_NAME varchar(128) Välja/veeru nimi andmelaos 'AADRESS_KOOD'
COLUMN_COMMENT varchar(4000) Välja/veeru kirjeldus lähtesüsteemis 'Kommentaar'
DWH_COLUMN_COMMENT varchar(4000) Välja/veeru kirjeldus andmelaos 'Kommentaar'
DATA_TYPE int Andmetüüp lähtesüsteems 'VARCHAR2'
DATA_LENGTH int Andmevälja pikkus lähtesüsteemis 1020
DATA_PRECISION int Andmevälja täpsus lähtesüsteemis 18
DATA_SCALE int Andmevälja täpsus peale koma lähtesüsteemis 0
NULLABLE char(1) Kas puuduvad (NULL) väärtused on lubatud 'Y'
IS_KEY int Kas väli/veerg on primaarvõti lähtesüsteemis 0
COLUMN_ID int Välja/veeru identifikaator lähtesüsteemis 18
21
IMP_SCHEMAS
Välja nimi Välja tüüp Selgitus Andmete näited
DATA_SOURCE_CODE varchar(32) Andmeallika/lähtesüsteemi kood. Viide tabelisse DATA_SOURCES 'SKAIS'
SCHEMA_NAME varchar(128) Skeemi nimi lähtesüsteemis 'SKA_OWNER'
22
IMP_TABLES
Välja nimi Välja tüüp Selgitus Andmete näited
DATA_SOURCE_CODE varchar(32) Andmeallika/lätesüsteemi kood. Viide tabelisse DATA_SOURCES 'SKAIS'
SCHEMA_NAME varchar(128) Skeemi nimi lähtesüsteemis 'SKA_OWNER'
TABLE_NAME varchar(128) Tabeli nimi lähtesüsteemis 'AADRESSID'
TABLE_TYPE varchar(20) Tabeli tüüp (TABLE - tabel, VIEW - vaade, MVIEW - materialiseeritud vaade) 'TABLE'
TABLE_COMMENT varchar(4000) Tabeli kirjeldus läthesüsteemis ''
23
LOAD_LOG
Andmete laadimise logi
Välja Välja Selgitus Kommentaar Andmete
nimi tüüp näide
LOG_ID int Logikirje
identifikaator.
Primaarvõti.
PROCE int Laadimise protsessi Iga käivitatud andmete laadimise protsess saab unikaalse identifikaatori. 1
SS_ID identifikaator.
SUBPR varchar Alamprotsessi kood Võimalikud väärtused:
OCESS (50) /nimi
_CODE DATA_LOAD - andmete laadimise põhiprotsess
DMART_LOAD - andmelettide laadimise protsess,
ODS_LOAD - ODS tabelite laadimise protsess
STG_LOAD - STG tabelite laadimise protsess
COMPARE_ROW_COUNTS - kirjete arvu võrdlemise protsess
COMPARE_DATA_MODEL - andmemudeli võrdlemise protsess
UPDATE_DATA_MODEL - andmemudeli muutmise protsess
DATA_S varchar Andmeallika kood. 'SKAIS'
OURCE (32) Viide tabelile ADM.
_CODE DATA_SOURCES
RELATE varchar Protsessiga seotud 'DW_SKAIS
D_OBJE (50) objekti (skeemi, _ODS.
CT andmetabeli vms) AADRESSID'
kood
START_ datetime Protsessi '2018-05-20
DT käivitamise algusaeg 05:30:00'
END_DT datetime Protsessi '2018-05-20
käivitamise lõppaeg 06:30:28'
STATUS varchar Laadimise protsessi Võimalikud väärtused:
(32) (lõpetamise) staatus.
STARTED - protsessi on alustatud aga see pole veel lõppenund
SUCCESS - protsess on lõppenud edukalt
WARNING - protsess on lõppenud hoiatusega, konkreetsed hoiatusteated asuvad tabelis EVENT_LOG
ERROR - protsess on lõppenud veaga, konkreetsed veateated asuvad tabelis EVENT_LOG
IS_IGN int Kas lõpetamise Kui eelmine laadimise protsess ei ole lõppenud (on staatuses STARTED) või lõppes veaga (on staatuses 0
ORE staatust võib ERROR), siis üldjuhul järgmist sama allika laadimisprotsessi ei käivitata. Kui on soov järgmine laadimine
ignoreerida. ikkagi käivitada, siis tuleb eelmisel laadimisprotsessil märkida IS_IGNORE = 1.
24
SCHEMAS
Lähtesüsteemi skeemid
Välja nimi Välja Selgitus Andmete näited
tüüp
SHEMA_VERSION_ID int Skeemi versiooni ID 1
DATA_SOURCE_CODE varchar(32) Andmeallika/lähtesüsteemi kood. Viide tabelile DATA_SOURCES 'SKAIS'
SOURCE_SCHEMA_NA varchar Skeemi nimi lähtesüsteemis 'SKA_OWNER'
ME (128)
DWH_SCHEMA_NAME varchar(32) Skeemi nimi andmelaos 'DW_SKA_OWNER'
STATUS varchar(20) Skeemi andmete laadimise staatus 'LOAD'
IS_ACTIVE int Kas skeemi andmete laadimine on aktiivne (võimaldab terve skeemi andmete laadimise lihtsamalt välja 1
lülitada)
Hetkel ei kasutata
IS_VALID int Kas tegemist on kehtiva kirje/versiooniga (0/1) 1
VALID_FROM timestamp Kirje/versiooni kehtivuse algusaeg '2018-05-04 17:24:
53'
VALID_TO timestamp Kirje/versiooni kehtivuse lõppaeg '2018-05-05 17:24:
53'
MODIFIED_BY varchar(32) Versiooni lisaja/muutja 'pentaho'
25
TABLES
Tabelite andmed.
Välja Välja Selgitus Andmete näited
nimi tüüp
TABLE_VE int Surrogaatvõti 281
RSION_ID
DATA_SO varchar Andmeallika/lähtesüsteemi kood 'SKAIS'
URCE_CO (32)
DE
SOURCE_ varchar Skeemi nimi lähtesüsteemis 'SKA_OWNER'
SCHEMA_ (128)
NAME
SOURCE_ varchar Tabeli nimi lähtesüsteemis 'AADRESSID'
TABLE_NA (128)
ME
DWH_SCH varchar Skeemi nimi andmelaos 'DW_SKA_OWNER'
EMA_NAME (128)
DWH_TAB varchar Tabeli nimi andmelaos 'AADRESSID'
LE_NAME (128)
TABLE_TY varchar Tabeli tüüp (TABLE, VIEW, MVIEW) 'TABLE'
PE (20)
SOURCE_ varchar Tabeli kirjeldus lähtesüsteemis ''
TABLE_C (4000)
OMMENT
DWH_TAB varchar Tabeli kirjeldus andmelaos ''
LE_COMM (4000)
ENT
LOAD_ST varchar Laadimise staatus 'LOAD' - Tabeli laadimine on sisse lülitatud
ATUS (20)
'NEW_LOAD' - Tegemist on uue andmetabeliga (st haldur pole tabeli laadimise staatust üle
vaadanud/kinnitanud), tabel on laadimisse sisse lülitatud
'NEW_NOT_LOAD' - Tegemist on uue andmetabeliga, tabel ei ole laadimisse sisse lülitatud
'NOT_LOAD' - tabeli laadimine ei ole sisse lülitatud
'NO_OBJECT' - tabelit ei ole enam lähtesüsteemis (varem oli)
LOAD_ME varchar Andmete laadimise meetod 'LOAD_MODIFIED' - laaditakse pärast viimast õnnestunud andmete laadimist lisatud
THOD (20) /muudetud andmed
'REWRITE' - andmed kirjutatakse üle (st muudatuste ajalugu ei säilitata)
'LOAD_MODIFIED_WOID' - laaditakse pärast viimast õnnestunud andmete laadimist lisatud
andmed, tabelil puudub võtmeväli st uued andmed lisatakse, kirjete muutmist ei arvestata
(vanade versioonide kehtetuks tunnistamist ei ole).
MODIFIED varchar Filtritingimus, mida kasutatakse muudetud ja/või 'SYS_MUUTMISE_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')'
_FILTER (255) lisatud andmete tuvastamiseks
(LOAD_MODIFIED) laadimismeetodi korra.
LAST_LOA varchar Avaldis, mis tuvastab mis aja seisuga andmed 'timestampadd('hour',-1, max(sys_muutmise_aeg))'
D_EXPRE (255) on laaditud
SSION
DWH_TAB varchar Tabeli staatus andmelaos 'NEEDS_CREATION' - tabel vajab loomist
LE_STATUS (30)
'NEEDS_MODIFICATION - tabel vajab muutmist
'READY' - tabel on loodud/muudetud
LAST_LOA timesta Viimase õnnestunud andmete laadimise '2018-05-15 00:01:10'
D_DT mp kuupäev ja kellaaeg
IS_VALID int Kas tegemist on kehtiva kirje/versiooniga (0/1) 0
VALID_FR timesta Kirje/versiooni kehtivuse algusaeg '2018-05-04 17:24:53'
OM mp
VALID_TO timesta Kirje/versiooni kehtivuse lõppaeg '2018-05-22 21:43:07'
mp
MODIFIED varchar Versiooni lisaja/muutja 'pentaho'
_BY (32)
26
IS_DM_TA int Kas tegemist on andmelettide arvutamisel Kui mõne andmelettide laadimises kasutatava tabeli laadimisel tekib viga, siis andmelettide
BLE kasutatava andmetabeliga. 0/1 tunnus. laadimise osa ei käivitata.
IS_ROW_ int Kas tabeli laadimisel võrreldakse andmelattu
COUNT jõudnud kirjete arvu ja lähteallikas olevat kirjete
arvu. 0/1 tunnus
PRIORITY int Andmetabeli laadimise prioriteetsus. Väiksema
väärtusega andmetabelid laaditakse enne.
OBJECT_ID int Objekti (tabeli) ID. See viitab tabelites XXX_LOG, XXX_LISALOG ja HISTORID kasutatavale object_id-le.
Võimaldab leida vastava tabeli logikirjeid.
DELETED varchar Kirjete kustutamise update lause Üldjuhul kasutatakse lähtesüsteemist kustutatud kirjete märkimiseks järgmist SQL lauset:
_STMT (255)
update <tabel> t1
set is_valid = 2, valid_to = t2.log_kuup
from (select n1, log_kuup from <deleted_log_table> where log_op = 'D' and log_obj_id =
<object_id>) t2
where <key_column_name> = t2.n1
and t1.is_valid = 1
Juhul kui standartne kustutatud kirjete kehtetuks märkimise lause ei sobi, siis saab siia välja
kirjutada vajaliku update lause.
DELETED varchar Millisest logitabelist tuleb võtta vastava tabeli Võimalikud variandid on XXX_LOG, XXX_LISALOG, HISTORID. Kui väärtus on tühi, siis
_LOG_TA (255) kustutatud kirjete info. vaikeväärtusena kasutatakse XXX_LOG.
BLE
27
SKA DWH Pentaho Data-Intergration paigaldusjuhend
Pigem kasutada uuemat juhendit siit: Pentaho PDI
Pentaho Data Integration on ETL tarkvara – andmete eksport, töötlemine ja ümberlaadimine.
Paigaldatakse Pentaho Community Edition (CE), mis on vabavaraline tarkvara
Kasutaja
Pentaho java protsess käivitatakse pentaho kasutaja alt.
sudo useradd pentaho
sudo passwd pentaho
Java JDK
Pentaho jaoks paigaldatakse uusim JDK8 versioon
RPM installi puhul paigaldatakse JDK asukohta /usr/java/default
cd /tmp/java
sudo rpm -Uvh jdk-8u151-linux-x64.rpm
Lisada JAVA_HOME keskkonnamuutuja pentaho kasutajale
vi /home/pentaho/.bash_profile
export JAVA_HOME=/usr/java/default/jre
Install
PDI ei vaja eraldi paigaldust. Arhiiv lahti pakkida ja õigused anda.
Pentaho Data Integration CE versiooni saab alla laadida sourceforge-st:
https://sourceforge.net/projects/pentaho/files/Data%20Integration/
Pentaho alla laadida, lahti pakkida ja õigused sättida.
cd /tmp/pentaho
unzip pdi-ce-8.0.zip
sudo mkdir /opt/data-integration
sudo mv * /opt/data-integration
cd /opt/data-integration
sudo chmod -R u+x *.sh
sudo chown –R pentaho *
JDBC andmeühendused
Pentaho on javal baseeruv ja seega kasutab andmebaasi ühendusteks JDBC ühendusi.
Pentaho ühendub oracle ja vertica andmebaasiga.
28
Andmebaasi draiverid
Paigaldada vertica ja oracle sobilikud andmebaasi draiverid.
Pentaho nimekiri draiveritest:
https://help.pentaho.com/Documentation/5.3/0D0/160/010
Vertica 9.0.0 draiveri leiab:
https://my.vertica.com/download/vertica/client-drivers/
Oracle draiveri versioon valida vastavalt andmebaasimootori versioonile
http://www.oracle.com/technetwork/database/features/jdbc/index-091264.html
Draiverite jar failid liigutada pentaho lib kausta
/opt/pentaho/data-integration/lib
Pentaho repositoorium
Kirjeldada pentaho repositoorium kus hakkavad laadimisskriptid asuma
vi /home/pentaho/.kettle/repositories.xml
Jälgida asukohta – asukoht on osades skriptides sisse kirjutatud
<?xml version="1.0" encoding="UTF-8"?>
<repositories>
<repository> <id>KettleFileRepository</id>
<name>ska</name>
<description>SKA DWH REPO</description>
<is_default>false</is_default>
<base_directory>/home/pentaho/repo</base_directory>
<read_only>N</read_only>
<hides_hidden_files>N</hides_hidden_files>
</repository> </repositories>
Luua repositooriumi kaust
sudo mkdir /home/pentaho/repo
sudo chown pentaho:pentaho /home/pentaho/repo
Repo olemasolu saab kontrollida:
cd /srv/pentaho
./kitchen.sh -listrep
Laadimisskriptid
Kopeerida pentaho failid (laadimisskriptid) pentaho repositooriumi kausta.
cp -R /tmp/laadimisskriptid/* /home/pentaho/repo
29
sudo chown -R pentaho:pentaho /home/pentaho/repo
Andmeühenduste failid
Pentaho repositooriumis asuvad andmeühendusi defineerivad kdb failid. Ühenduse failides tuleb muuta parameetrid live Vertica-le vastavaks
Krüpteerida vertica kasutaja „pentaho“ parool ja SKAIS andmebaasi ühenduse kasutaja. Salvesta väljund, mis on kujul „Encrypted 123456...“
sudo su - pentaho
/opt/data-integration/encr.sh -kettle vertica_pentaho_parool
Conn_ska_wrh on vertica ühendust kirjeldav fail
vi /home/pentaho/repo/conn_ska_wrh.kdb
Muuta vertica ühendusel serverinimi, baasinimi, port, parool(pentaho Vertica kasutaja). Port on kirjeldatud kahes kohas. Nimi conn_ska_wrh peab samaks
jääma
<connection>
<name>conn_ska_wrh</name>
<server>ska-wrh-1a.prd.tehik.ee</server>
<type>VERTICA5</type>
<access>Native</access>
<database>ska_wrh_db</database>
<port>5433</port>
<username>pentaho</username>
<password>Encrypted *****</password>
<servername/>
<data_tablespace/>
<index_tablespace/>
<attributes>
.......
<attribute><code>PORT_NUMBER</code><attribute>5433</attribute></attribute>
Pentaho skriptide jooksutamine
Pentaho skripte on manuaalselt võimalik jooksutada pentaho serveris.
rep määrab repositooriumi nime. dir määrab alamkataloogi repositooriumis. job määrab pentaho job faili nime. Pikemate laadimiste puhul kasutada nohup
&
sudo su - pentaho
nohup /opt/data-integration/kitchen.sh -rep=ska2 -dir=/load_ods -job=load_one_ds -level=Normal > /tmp/prelive1.log &
30
SKA DWH Vertica ühendumise juhend
Kasutaja
Skais vertica kasutajaid haldab Tehik (itabi)
JDBC
Java põhiste klientide kaudu ühendumine Dbeaver näitel
Draiver
Laadi alla Vertica JDBC uusima versiooni draiveri fail ja paiguta oma arvutis kindlasse kohta.
https://www.vertica.com/download/vertica/client-drivers/
https://www.vertica.com/client_drivers/24.2.x/24.2.0-0/vertica-jdbc-24.2.0-0.jar
Dbeaver
Laadi alla ja paigalda Dbeaver Community edition (koos JRE-ga)
https://dbeaver.io/download/
Keskkondade parameetrid
Vaata parameetreid lehelt Serverid ja ühendused
Dbeaver ühendus
Kui dbeaver on käivitatud, siis tuleb luua uus ühendus, määrata draiver ja sättida parameetrid.
New Connection > Connection Type Vertica > Määrata ühenduse parameetrid
Edit Driver Settings alt lisada eelnevalt allalaetud vertica-jdbc-***.jar fail
31
Test connection
Ühendu lisatud ühenduse andmebaasiga
ODBC
ODBC põhiste klientide kaudu ühendamine
Client
Tõmba alla ja paigalda Vertica uusim Windows Client
https://www.vertica.com/client_drivers/24.2.x/24.2.0-0/VerticaSetup-24.2.0-0.exe
ODBC
Lisada ODBC ühendus vastava baasi parameetritega
Start > ODBC Data Sources (64-bit) > Add > Vertica
Määra Database, Server, Port ja kasutaja Basic Settings alt.
32
Kasuta antud ODBC ühendust ODBC toetavas kliendis nagu Excel või mõni teine
33
Skeemid
Skeemi nimi Kirjeldus Staatus
ADM_SKAIS1 Admin tabelid - laadimiste sätted ja logid
ADM_SKAIS1_V2 Vana, pole kasutuses
DW_AES_OWNER_ODS AES Owner ODS
DW_AES_OWNER_STG AES Owner STG
DW_SKA_OWNER_KEYS_ODS SKA OWNER KEYS ODS
DW_SKA_OWNER_KEYS_STG SKA OWNER KEYS STG
DW_SKA_OWNER_ODS SKA OWNER ODS
DW_SKA_OWNER_STG SKA OWNER STG
TEST_SKAIS1 Tühi?
34
Täislaadimiste tegemine
Kuna SKAIS andmebaasis lülitatakse pikemate protsesside tegemisel ajaloo tabeli (HISTORID) täitmine välja, siis on pärast selliseid protsesse vajalik teha
nimetatud tabelite täislaadimine.
Täislaadimise vajadust näitab see, kui kirjete arv lähtebaasis (SKAIS andmebaas) ja andmelao vastavas tabelis on erinev. Laadimise käigus võrreldakse
kirjete arvu lähtebaasis ja andmelaos ning tulemus salvestatakse tabelisse ADM.ROW_COUNTS. Välja STATUS_CODE väärtus WARNING näitab, et
lähtesüsteemi tabelis ja andmelaos on erinev kirjete arv; veerud SOURCE_COUNT ja DWH_COUNT näitavad vastavalt kirjete arvu lähtesüsteemis ja
andmelaos.
NB! Kuna suuremate tabelite täislaadimine võib võtta mitmeid tunde (200 miljonit kirjet võtab üle 10 tunni), siis soovitame seda teha nädalavahetustel.
Samuti tuleb laadimise ajaks välja lülitada andmete regulaarlaadimise käivitamine. Vt Automaatprotsesside käivitamine
Täislaadimiste teostamiseks tabelile TABEL1 tuleb andmelao andmebaasos käivitada järgmine käsk (käsus muuta tabeli nimi ja vajaduse korral ka skeemi
nimi; soovi korral võib korraga muuta mitme erineva tabeli laadimist)
update adm.tables t1
set
load_method = 'REWRITE',
modified_filter = null,
last_load_expression = null
where source_table_name in ('TABEL1')
and source_schema_name = 'SKA_OWNER'
and is_valid = 1
Pärast täislaadimise lõppemist tuleb taas sisse lülitada regulaarlaadimine, Tabeli TABEL1 regulaarlaadimise sisselülitamiseks tuleb käivitada järgmine
käsk (käsus muuta tabeli nimi ja vajaduse korral ka skeemi nimi):
update adm.tables t1
set
load_method = t2.load_method,
modified_filter = t2.modified_filter,
last_load_expression = t2.last_load_expression
from adm_backup.tables t2
where t1.is_valid = 1
and t1.data_source_code = t2.data_source_code and t1.source_schema_name = t2.source_schema_name and t1.
source_table_name = t2.source_table_name and t2.is_valid = 1
and t1.source_schema_name = 'SKA_OWNER'
and t1.source_table_name in ('TABEL1')
35
Logimine
Vertica laadimiste logid
Vertica sql (wrh-db.prd.tehik.ee)
ADM_SKAIS1.LOAD_LOG ja ADM_SKAIS2.LOAD_LOG - laadimiste logitabelid. Vt täpsem kirjeldus logitabelite kirjelduse juurest.
ADM_SKAIS1.EVENT_LOG ja ADM_SKAIS1.EVENT_LOG - sündmuste logi (võimaldab leida täpsema Pentaho protseduuri ja sõlme, kus viga tekkis).
select * from adm_skais1.load_log where status != 'SUCCESS' order by log_id desc;
select * from adm_skais1.event_log order by event_id desc;
LOAD_LOG näide
ERROR ja NOT_LOADED on staatused, mis tähendavad päris viga.
LOG_ID PROCESS_ID SUBPROCESS_CODE DATA_SOURCE_CODE RELATED_OBJECT START_DT END_DT STATUS IS_IGNORE
398,679 997 ODS_LOAD SKAIS1 SKA_OWNER.YLEMAKSED 2025-11-06 04:00:22.934 2025-11-06 04:00:26.988 SUCCESS 0
EVENT_LOG näide
EVENT_ID EVENT_DT EVENT_TYPE EVENT_CLASS EVENT_CODE EVENT_MESSAGE RELATED_OBJECT PROCESS_NAME STEP
_NAME PROCESS_ID DATA_SOURCE_CODE
844 2025-05-30 11:39:41.967 ERROR ODS_LOAD ERROR__ODS_LOAD ERROR in loading ODS table SKA_OWNER.
PENSIONARID load_one_table_from_db_ODS_LOAD prepare_and_run_ods_load 838 SKAIS1
Serveri pentaho logid
Serveris pentaho-vertica-1a logi failid asuvad /var/logs/pentaho. Logifail on kuupäeva eesliitega kujul DDMMYY-load_all_skais1_live.log
/var/logs/pentaho/170422-load_all_skais1_live.log
Tasub otsida märksõnu ERROR, Abort, E=1
36
SKAIS2 andmeladu
37
Laadimiste haldus
Tabelite laadimisse lisamine
Antud juhend kehtib ka Skais1 puhul, kuid skeemideks sel juhul ADM_SKAIS1
1. Tabelid lisatakse laadimisse osalt laadimismootori poolelt automaatselt. Laadimiste kasutajal on ligipääs skeemile,tabelile ning laadimismootor loeb
tabeli metaaandmed (metadata).
Laadimismootor täidab automaatselt skeemi ADM_SKAIS2 tabelid COLUMNS, SCHEMAS, TABLES metaandmetega
2. Kontrollida, et vastav tabel on tabelis TABLES esindatud ning muuta selle LOAD_STATUS, LOAD_METHOD ja vajaduse korral muud laadimis
parameetrid sobivaks.
(Väljade MODIFIED_FILTER ja LAST_LOAD_EXPRESSION väärtused sõltuvalt sellest, millised väljad on antud tabelis nt millise tingimusega tuleb pärida
muutunud anmed jms).
Vt täpsemalt TABLES SKAIS2
update ADM_SKAIS2.TABLES
set LOAD_STATUS = 'LOAD',
LOAD_METHOD = 'LOAD_MODIFIED',
MODIFIED_FILTER = '(case when MUUTM_AEG < DATE ''1900-01-01'' then DATE ''1900-01-01'' else MUUTM_AEG end)
>=TO_DATE(''[LAST_LOAD_DT]'',''yyyy-mm-dd hh24:mi:ss'')',
LAST_LOAD_EXPRESSION = 'timestampadd(''hour'',-1, max(MUUTM_AEG))',
IS_ROW_COUNT = 1,
DWH_SCHEMA_NAME = 'DW_SKAIS2'
where is_valid = 1
and SOURCE_SCHEMA_NAME = 'SKAIS2'
and SOURCE_TABLE_NAME = 'IS_KONTAKT_STAATUS';
3. Lisaks põhitabelile tuleb laadimisse lülitada vastav LOG tabel
update ADM_SKAIS2.TABLES
set LOAD_STATUS = 'LOAD',
LOAD_METHOD = 'LOAD_MODIFIED_WOID',
MODIFIED_FILTER = 'LOG_ACTION in (''D'',''I'') and LOG_LISAM_AEG >=TO_DATE(''[LAST_LOAD_DT]'',''yyyy-mm-dd hh24:
mi:ss'')',
LAST_LOAD_EXPRESSION = 'timestampadd(''hour'',-1, max(LOG_LISAM_AEG))',
IS_ROW_COUNT = 0,
DWH_SCHEMA_NAME = 'DW_SKAIS2',
PRIORITY_STG = 110,
PRIORITY_ODS = 90
where is_valid = 1
and SOURCE_SCHEMA_NAME = 'SKAIS2'
and SOURCE_TABLE_NAME = 'LOG_IS_KONTAKT_STAATUS';
4. Lülitada sisse vastavate tabelite veergude laadimine (tabelis ADM_SKAIS2.COLUMNS) nii tava kui LOG tabeli puhul
update ADM_SKAIS2.COLUMNS
set LOAD_STATUS = 'LOAD'
where is_valid = 1
and SOURCE_SCHEMA_NAME = 'SKAIS2'
and SOURCE_TABLE_NAME in ('IS_KONTAKT_STAATUS', 'LOG_IS_KONTAKT_STAATUS');
Uus skeem
Uue skeemi lisandumisel tellida see itabi kaudu vastavalt:
Ligipääsud
Vead ja parandused
BLOB väljade puhul liiga pikad väärtused. Pikendada välja või muuta pikemaks tüübiks
38
--rows were rejected. Blob. varchar(64000) to long varchar
ALTER TABLE DW_SKAIS_PARENTAL_BENEFIT_STG.STG_SOURCE_INFORMATION add column DATA2 LONG VARCHAR
(300000);
UPDATE DW_SKAIS_PARENTAL_BENEFIT_STG.STG_SOURCE_INFORMATION SET DATA2 = DATA;
ALTER TABLE DW_SKAIS_PARENTAL_BENEFIT_STG.STG_SOURCE_INFORMATION RENAME COLUMN DATA TO
DATA_BAK;
ALTER TABLE DW_SKAIS_PARENTAL_BENEFIT_STG.STG_SOURCE_INFORMATION RENAME COLUMN DATA2 TO DATA;
select count(*) from DW_SKAIS_PARENTAL_BENEFIT_ODS.SOURCE_INFORMATION;
ALTER TABLE DW_SKAIS_PARENTAL_BENEFIT_STG.STG_SOURCE_INFORMATION DROP COLUMN DATA_BAK;
RAW andmetüübi puhul on vaja lisada transform expression
select * from ADM_SKAIS2.COLUMNS
where is_valid = 1
and LOAD_STATUS in ('LOAD', 'NEW_LOAD')
and data_type = 'RAW'
and TRANSFORM_EXPRESSION is NULL
and SOURCE_TABLE_NAME in ('IS_KONTAKT_STAATUS', 'LOG_IS_KONTAKT_STAATUS');
update ADM_SKAIS2.COLUMNS
set TRANSFORM_EXPRESSION = 'rawtohex(' || dwh_column_name || ')'
where is_valid = 1
and LOAD_STATUS in ('LOAD', 'NEW_LOAD')
and data_type = 'RAW'
and TRANSFORM_EXPRESSION is NULL;
Timestamp with timezone puhul vajalik transform expression
update ADM_SKAIS2.COLUMNS
set TRANSFORM_EXPRESSION = 'cast(cast(' || dwh_column_name || ' as timestamp with local time zone) as timestamp)'
where is_valid = 1
and LOAD_STATUS = 'LOAD'
and data_type = 'TIMESTAMP(3) WITH TIME ZONE'
and TRANSFORM_EXPRESSION is NULL
and SOURCE_TABLE_NAME in ('IS_KONTAKT_STAATUS', 'LOG_IS_KONTAKT_STAATUS');
39
Logid
Vertica laadimiste logid
Vertica sql (wrh-db.prd.tehik.ee)
ADM_SKAIS2.EVENT_LOG
ADM_SKAIS2.LOAD_LOG
select * from adm_skais2.load_log where status != 'SUCCESS' order by log_id desc;
select * from adm_skais2.event_log order by event_id desc;
LOAD_LOG näide
Warning staatus on okei, sest see enamasti tähendab kirjete arvu erinevust. ERROR ja NOT LOADED on päris vead.
LOG_ID PROCESS_ID SUBPROCESS_CODE DATA_SOURCE_CODE RELATED_OBJECT START_DT END_DT STATUS IS_IGNORE
896,315 879 ODS_LOAD SKAIS2 SKAIS2.YL_YLESANNE_SEOS 2025-10-30 04:16:29.909 2025-10-30 04:16:39.947 WARNING 0
EVENT_LOG näide
EVENT_ID EVENT_DT EVENT_TYPE EVENT_CLASS EVENT_CODE EVENT_MESSAGE RELATED_OBJECT PROCESS_NAME STEP
_NAME PROCESS_ID DATA_SOURCE_CODE
3,991 2025-09-16 03:11:52.732 ERROR ODS_LOAD ERROR__ODS_LOAD_STG_ERROR STG table loading error - ODS table not
loaded SKAIS2.AE_HINDAMINE_VALDKOND load_one_table_from_db_ODS_LOAD Is STG table OK 844 SKAIS2
Serveri pentaho logid
Serveris pentaho-vertica-1a logi failid asuvad /var/logs/pentaho. Logifail on kuupäeva eesliitega kujul DDMMYY-load_all_skais2_live.log
/var/logs/pentaho/170422-load_all_skais2_live.log
Logidest tasub otsida märksõna ERROR, Abort, E=1
40
Pentaho PDI
Pentaho PDI tarkvara
Pentaho PDI 9.4 versioon pole enam allalaetav tootja poolt. Edasised versioonid on tasulised.
Tarkvara leiab serveritest ja Resta arhiividest.
Asukohad serverites
SKAIS- pentaho-vertica-1a
/opt/etl/data-integration94
Paigaldus
1. Laadida pdi-ce-9.4.0.0-343.zip serverisse ning lahti pakkida soovitud asukohta.
PDI ise võtab ~2GB ruumi ning sisemised logid võivad veel mitu GB võtta.
2. Sättida õigused "pentaho" kasutajal
chown -R pentaho /opt/etl/data-integration94
chmod u+x /opt/etl/data-integration94/*.sh
3. Paigaldada jdbc andmebaasi draiverid lib kausta
Näiteks:
/opt/etl/data-integration94/lib/ojdbc8.jar
/opt/etl/data-integration94/lib/vertica-jdbc-12.0.3-0.jar
4. Sättida mälu piirid vastavalt serveri võimekustele.
NB PDI võib tekitada mitu protsessi ning mitmed laadimised võivad samaaegselt käia.
vi /opt/etl/data-integration94/spoon.sh
if [ -z "$PENTAHO_DI_JAVA_OPTIONS" ]; then
PENTAHO_DI_JAVA_OPTIONS="-Xms1024m -Xmx16624m"
Vajadusel määrata repositooriumid
vi /home/pentaho/.kettle/repositories.xml
Näiteks:
<repository>
<id>KettleFileRepository</id>
<name>skais2_live</name>
<description>SKAIS2 live repo</description>
<is_default>false</is_default>
<base_directory>/home/pentaho/repo_skais2_v2_live</base_directory>
<read_only>N</read_only>
<hides_hidden_files>N</hides_hidden_files>
</repository>
Vajadusel kirjeldada muutujad kettle.properties failis kujul MUUTUJANIMI=vaartus
/home/pentaho/kettle/kettle.properties
Kui laadimiste osa on ssh/sftp vms pöördumised teise serverisse, siis vaja konfigureerida ssh võtmega ligipääs.
41
SKA SKAIS2 DW andmebaas
SKA DW andmebaasi (SKA andmelao) andmebaasisüsteemina kasutatakse spetsiaalselt analüütilisteks lahendusteks optimeeritud veerupõhist
andmebaasimootorit OpenText Vertica.
SKA DW andmebaas jaguneb andmete laadimise loogika mõttes kahte kihti:
1. Eellaadimise ala (staging ehk STG-kiht) sisaldab andmete laadimise tööks vajalikke andmetabeleid (ajutised andmed).
STG-kihi andmetabelite struktuur on täpselt sama, mis on lähtesüsteemi andmetabelitel (mõningased erinevused võivad tulla sellest, kuidas
erinevad andmebaasisüsteemid (Oracle ja Vertica) salvestavad sarnaseid andmetüüpe nt varchar2(100) Oracles vs varchar(100) Verticas).
Tüüpiliselt laaditakse igaöise laadimise käigus STG-kihti viimase ööpäeva jooksul lähtesüsteemidesse lisatud ja/või seal muudetud andmed.
Erandjuhtumitel (kui lähtesüsteemis muudetud kirjete tuvastamine ei ole võimalik), teostatakse tabelile igal öösel täislaadimine. Eeskirjad, millist
andmete laadimise meetodit ja see, kas vastava tabeli andmeid üldse SKAIS2 andmelattu laaditakse, on kirjeldatud süsteemses andmetabelis
ADM_SKAIS2.TABLES.
2. Operatiivne andmehoidla (Operational Data Store e ODS-kiht) sisaldab kõiki lähtesüsteemide andmebaaside andmeid (st kogu muudatuste
ajalugu alates andmelao laadimise alghetkest). ODS kihi andmemudel on sarnane lähtesüsteemi andmemudelile - igale lähtesüsteemi tabelile
vastab ODS kihis samanimeline tabel, mis sisaldab kõiki vastava andmetabeli välju ning nelja täiendavat välja kirjete versioneerimiseks.
Lisatavateks väljadeks on:
a. dwh_id - Surrogaatvõti (andmelao laadimisprogrammi poolt genereeritud võtmeväli)
b. is_valid - 0/1 väli, mis näitab, kas tegemist on kehtiva kirjega (kõige viimase versiooniga)
c. valid_from - versiooni kehtivuse algusaeg (kuupäev ja kellaaeg)
d. valid_to - versiooni kehtivuse lõppaeg (kuupäev ja kellaaeg)
Lisaks nimetatud kihtidele on eraldi skeem (nimega ADM_SKAIS2), mis sisaldab andmete laadimiseks ning muuks SKA DW toimimiseks vajalikke
andmetabeleid.
42
SKA SKAIS2 DW andmete laadimine
Andmete laadimiste üldine loogika
SKA_DW andmete laadimine toimub järgmise skeemi kohaselt
1. Lähtesüsteemi (SKAIS2) andmemudeli muudatuste tuvastamine (sh SKA DW andmemudeli uuendamine)
a. Lähteallika (SKAIS2) andmebaasi süsteemsetest tabelitest loetakse lähtesüsteemi andmemudel ning salvestatakse see süsteemsetesse
tabelitesse ADM_SKAIS2.IMP_SCHEMAS, ADM_SKAIS2.IMP_TABLES ja ADM_SKAIS2.IMP_COLUMNS.
b. Lähteallika andmemudelit võrreldakse SKA DW poolt teada oleva mudeliga (st eelmisel päeval kehtinud andmemudeliga) ning
tuvastatakse muudatused.
c. Kõikide nende andmetabelite korral, mis on laadimisse sisse lülitatud (LOAD_STATUS = 'LOAD' või 'NEW_LOAD') korral SKA DW
andmemudelit (STG-tabeleid ja ODS-tabeleid) muudetakse vastavalt eelmises punktis tuvastatud muudatustele (lisatakse uued väljad,
muudetakse olemasolevate väljade tüüpe, lähtesüsteemist kustutatud väljade laadimine lülitatakse välja (LOAD_STATUS =
'NO_OBJECT').
2. Andmete import ja andmete laadimine STG ja ODS tabelitesse (iga tabeli korral võidakse kasutada erinevat andmete impordi meetodit, erinevat
lähtesüsteemist kustutatud kirjete tühistatuks märkimise meetodit jms. Vt tabelite laadimise konfigureerimise võimalusi süsteemsete tabelite ADM_
SKAIS2.TABLES ja ADM_SKAIS2.COLUMNS kirjelduste juurest)
a. (Pärast viimast laadimist lisatud ja/või muudetud) andmete import STG tabelitesse (sh viimati laaditud andmete tuvastamine kasutades
ADM_SKAIS2.TABLES LAST_LOAD_EXPRESSION avaldist)
b. Andmete laadimine ODS tabelitesse (sh lähtesüsteemist kustutatud kirjete märkimine kehtetuks)
c. Lähtesüsteemi ja ODS tabeli kirjete arvu võrdlemine.
Andmelao laadimiste kohta tekib laadimiste logi. Laadimisprotsesside käivitamise ja lõpetamise teated salvestatakse laadimise logi tabelisse LOAD_LOG,
detailsemad tabelite loomise (sündmuste teated) salvestatakse tabelisse EVENT_LOG.
Laadimiste käitumine veaolukordades
Laadimise alguses kontrollitakse, kas eelmine (sama andmeallika) laadimine on lõppenud. Kui eelmine laadimise protsess ei ole lõppenud või lõppes
veaga ning ei ole märgitud, et viga tuleb ignoreerida, siis järgmist sama allika laadimisprotsessi ei käivitata.
Kui eelmise päeva laadimine sai vea ning vigane olukord on parandatud (st järgmisel päeval saab laadimist uuesti jätkata), siis tuleb laadimiste logi tabelis
(LOAD_LOG) IS_IGNORE väärtuseks panna 1 (st viga ignoreeritakse).
Juhul, kui mingi STG tabeli laadimise käigus tekib viga, siis STG tabelite laadimine töötab lõpuni, samuti käivitatakse ODS tabelite laadimine kuid vea
saanud tabeli korral vastava ODS tabeli laadimist ei käivitata.
Laadimiste tulemustest teavitamine
Laadimiste tulemuste teavitamiseks saadetakse e-mail aadressile .... (vastava e-mail'i aliase loob ning selle aliase taga paiknevaid konkreetseid e-mail'i
aadresse haldab TEHIK, e-mail'i alias tuleb sisestada tabelisse PARAMETERS parameetri to_email väärtuseks).
Juhul, kui laadimiste käigus ei tekkinud vigu ega hoiatusi, saadetakse e-mail teemaga "Andmeallika SKAIS2 andmete laadimine õnnestus".
Juhul, kui laadimise käigus tekkis hoiatusi, saadetakse e-mail teemaga "Andmeallika SKAIS2 andmete laadimine on lõppenud hoiatustega".
Juhul, kui laadimise käigus tekkis vigu, saadetakse e-mail teemaga "Andmeallika SKAIS2 laadimine sai vigu!" ning e-mail'i sisuks on vigade logi.
Juhul, kui tavapäraseks laadimise lõppemise ajaks ei ole e-mail'i saabunud, siis tuleb olukorda käsitleda veaolukorrana ning täpsemat infot on võimalik
leida logitabelitest ja/või Pentaho logist.
Laaditavad tabelid
Kõige täpsema ülevaata, milliseid andmetabeleid (ja milliste meetoditega) laaditakse, saab süsteemsest andmetabelist ADM_SKAIS2.TABLES alljärgneva
päringuga
select source_schema_name ||'.' ||source_table_name,
dwh_schema_name || '.' || dwh_table_name,
load_method, modified_filter
from adm_skais2.tables
where is_valid = 1
and load_status in ('LOAD', 'NEW_LOAD')
order by source_schema_name, source_table_name
43
Alljärgnevas tabelis on laaditavate tabelite nimekiri 30.10.2025 seisuga
SOURCE_TABLE DWH_TABLE LOAD_METHOD MODIFIED_FILTER
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AD_AADRESS AD_AADRESS MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AE_ARST_SPETSIA AE_ARST_SPETSIA MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
LIST LIST
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AE_ARST_SPETSIA AE_ARST_SPETSIA MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
LIST_DOKUMENT LIST_DOKUMENT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AE_EKSPERTARST AE_EKSPERTARST MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
_LEPING _LEPING
SKAIS2.AE_ERIALA DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AE_ERIALA MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AE_HINDAMINE_TE AE_HINDAMINE_TE MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
GEVUS GEVUS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AE_HINDAMINE_TE AE_HINDAMINE_TE MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
GEVUS_KYSIMUS GEVUS_KYSIMUS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AE_HINDAMINE_VA AE_HINDAMINE_VA MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
LDKOND LDKOND
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AE_HINDAMINE_VA AE_HINDAMINE_VA MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
LDKOND_TASE LDKOND_TASE
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AE_HINNANG AE_HINNANG MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AE_HINNANG_DIA AE_HINNANG_DIAG MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
GNOOS NOOS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AE_HINNANG_MOJ AE_HINNANG_MOJ MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
UTATUD UTATUD
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AE_HINNANG_OLEK AE_HINNANG_OLEK MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AE_HINNANG_TEG AE_HINNANG_TEG MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
EVUS EVUS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AE_HINNANG_TEG AE_HINNANG_TEG MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
EVUS_VASTUS EVUS_VASTUS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AE_HINNANG_VAL AE_HINNANG_VAL MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
DKOND DKOND
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AE_HINNANG_YTL AE_HINNANG_YTL MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
US US
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AE_LEPING_PUUD AE_LEPING_PUUD MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
UMINE UMINE
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AE_LEPING_TOO AE_LEPING_TOO MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AE_PIKK_TEKST AE_PIKK_TEKST MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AE_TEHTUD_TOO AE_TEHTUD_TOO MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AE_TOO_LIIK AE_TOO_LIIK MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AE_TOO_LIIK_HIND AE_TOO_LIIK_HIND MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
44
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AK_AKTSEPTEERI AK_AKTSEPTEERI MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
MINE MINE
SKAIS2.AR_ARVE DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_ARVE MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_ARVESTUS_MU AR_ARVESTUS_MU MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
UDATUS UDATUS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_ARVE_RIDA AR_ARVE_RIDA MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_FINANTS_SYN AR_FINANTS_SYND MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
DMUS MUS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_KATUSNOUE AR_KATUSNOUE MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_KINNIPEETUD_ AR_KINNIPEETUD_ MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SUMMA SUMMA
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_KINNIPIDAMINE AR_KINNIPIDAMINE MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_KINNIPIDAMIN AR_KINNIPIDAMINE MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
E_DOKUMENT _DOKUMENT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_KINNIPIDAMIN AR_KINNIPIDAMINE MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
E_HYVITIS _HYVITIS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_KINNIPIDAMIN AR_KINNIPIDAMINE MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
E_HYV_REEGEL _HYV_REEGEL
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_KINNIPIDAMIN AR_KINNIPIDAMINE MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
E_ISIK _ISIK
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_KINNIPIDAMIN AR_KINNIPIDAMINE MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
E_OLEK _OLEK
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_KINNIPIDAMIN AR_KINNIPIDAMINE MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
E_REEGEL _REEGEL
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_KINNIPIDAMIN AR_KINNIPIDAMINE MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
E_REEGEL_DOK _REEGEL_DOK
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_KINNIPIDAMIN AR_KINNIPIDAMINE MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
E_REEGEL_HYV _REEGEL_HYV
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_KOHUSTUS AR_KOHUSTUS MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_KOHUSTUS_M AR_KOHUSTUS_M MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
UUDATUS UUDATUS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_KOHUSTUS_TY AR_KOHUSTUS_TY MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
HISTUS_VIGA HISTUS_VIGA
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_KOHU_NOUE_ AR_KOHU_NOUE_S MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SYNDMUS YNDMUS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_KOHU_VALJAM AR_KOHU_VALJAM MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
AKSE AKSE
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_MAKSEGRAAFIK AR_MAKSEGRAAFIK MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_MAKSEGRAAFI AR_MAKSEGRAAFI MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
K_DOKUMENT K_DOKUMENT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_MAKSEGRAAFI AR_MAKSEGRAAFI MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
K_RIDA K_RIDA
45
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_MAKSEGRAAFI AR_MAKSEGRAAFI MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
K_RIDA_LAEKUMINE K_RIDA_LAEKUMINE
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_MAKSEKANAL AR_MAKSEKANAL MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_MAKSEKANAL_ AR_MAKSEKANAL_ MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
REEGEL REEGEL
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_MAKSM_KOHU AR_MAKSM_KOHU MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
STUS STUS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_MAKSULEPING AR_MAKSULEPING MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_MITTERESIDENT AR_MITTERESIDENT MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_MITTERES_MA AR_MITTERES_MA MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
KSULEPING_TOEND KSULEPING_TOEND
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_MVT_PARING_I AR_MVT_PARING_I MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SIK SIK
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_MVT_SALDO AR_MVT_SALDO MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_MVT_SYNDMUS AR_MVT_SYNDMUS MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2.AR_NOUE DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_NOUE MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_NOUE_LAEKU AR_NOUE_LAEKUM MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
MINE INE
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_PANGAKONTO AR_PANGAKONTO MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2.AR_PANK DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_PANK MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_PANK_PYHA AR_PANK_PYHA MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_PARAMEETER_ AR_PARAMEETER_ MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
HYVITIS HYVITIS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_PROTSESS_VE AR_PROTSESS_VE MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
ATEADE ATEADE
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_RAHALINE_TE AR_RAHALINE_TEH MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
HING ING
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_REGRESSINOUE AR_REGRESSINOUE MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_SAP_HANKIJA AR_SAP_HANKIJA MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_TAGASINOUE AR_TAGASINOUE MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_TAGASINOUE_ AR_TAGASINOUE_ MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
DOKUMENT DOKUMENT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_TAGASINOUE_ AR_TAGASINOUE_ MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
HYVITIS HYVITIS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_TAGASINOUE_I AR_TAGASINOUE_I MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SIK SIK
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_TSD_ESD_KP AR_TSD_ESD_KP MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_TSD_ESD_SM AR_TSD_ESD_SM MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
46
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_TSD_LISA_1A AR_TSD_LISA_1A MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_TSD_LISA_1B AR_TSD_LISA_1B MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_TSD_LISA_2A AR_TSD_LISA_2A MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_TSD_LISA_2B AR_TSD_LISA_2B MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_TSD_VORM AR_TSD_VORM MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_TULUMAKS AR_TULUMAKS MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_TULUMAKSUVA AR_TULUMAKSUVA MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
BASTUS BASTUS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_TULUMAKSUVA AR_TULUMAKSUVA MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
B_DOKUMENT B_DOKUMENT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_VAHEMAKSE_P AR_VAHEMAKSE_P MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
AEV AEV
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
AR_VEATEADE_OB AR_VEATEADE_OB MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
JEKT JEKT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
DO_DOKUMENT DO_DOKUMENT MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
DO_DOKUMENT_F DO_DOKUMENT_F MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
AIL AIL
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
DO_DOKUMENT_O DO_DOKUMENT_O MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
BJEKT BJEKT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
DO_DOKUMENT_S DO_DOKUMENT_S MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
EOS EOS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
DO_DOKUMENT_S DO_DOKUMENT_S MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
EOS_VALINE EOS_VALINE
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
DO_DOKUMENT_T DO_DOKUMENT_T MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
EENUS EENUS
SKAIS2.DO_KAART DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
DO_KAART MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
DO_KYSIMUSTIK DO_KYSIMUSTIK MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
DO_KYSIMUSTIK_K DO_KYSIMUSTIK_K MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
YSIMUS YSIMUS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
DO_KYSIMUSTIK_V DO_KYSIMUSTIK_V MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
ASTUS ASTUS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
DO_KYSIMUSTIK_V DO_KYSIMUSTIK_V MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
ASTUS_VALIK ASTUS_VALIK
SKAIS2.DO_OTSUS DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
DO_OTSUS MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
DO_OTSUS_ALUS DO_OTSUS_ALUS MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
DO_PIKK_TEKST DO_PIKK_TEKST MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
DO_TAOTLUS DO_TAOTLUS MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
DO_TOOVOIMETUS DO_TOOVOIMETUS MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
LEHT LEHT
47
SKAIS_DOCUMENT DW_SKAIS_DOCUM LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else
_MANAGEMENT. ENT_MANAGEMEN LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
DOCUMENT T.DOCUMENT
SKAIS_DOCUMENT DW_SKAIS_DOCUM LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else
_MANAGEMENT. ENT_MANAGEMEN LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
DOCUMENT_BASIS T.
DOCUMENT_BASIS
SKAIS_DOCUMENT DW_SKAIS_DOCUM LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else
_MANAGEMENT. ENT_MANAGEMEN LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
DOCUMENT_DOMA T.
IN DOCUMENT_DOMA
IN
SKAIS_DOCUMENT DW_SKAIS_DOCUM LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else
_MANAGEMENT. ENT_MANAGEMEN LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
DOCUMENT_FILE T.DOCUMENT_FILE
SKAIS_DOCUMENT DW_SKAIS_DOCUM LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else
_MANAGEMENT. ENT_MANAGEMEN LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
DOCUMENT_PERS T.
ON DOCUMENT_PERS
ON
SKAIS_DOCUMENT DW_SKAIS_DOCUM LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
_MANAGEMENT. ENT_MANAGEMEN WOID mm-dd hh24:mi:ss')
LOG_DOCUMENT T.LOG_DOCUMENT
SKAIS_DOCUMENT DW_SKAIS_DOCUM LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
_MANAGEMENT. ENT_MANAGEMEN WOID mm-dd hh24:mi:ss')
LOG_DOCUMENT_ T.
BASIS LOG_DOCUMENT_
BASIS
SKAIS_DOCUMENT DW_SKAIS_DOCUM LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
_MANAGEMENT. ENT_MANAGEMEN WOID mm-dd hh24:mi:ss')
LOG_DOCUMENT_ T.
DOMAIN LOG_DOCUMENT_
DOMAIN
SKAIS_DOCUMENT DW_SKAIS_DOCUM LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
_MANAGEMENT. ENT_MANAGEMEN WOID mm-dd hh24:mi:ss')
LOG_DOCUMENT_ T.
FILE LOG_DOCUMENT_
FILE
SKAIS_DOCUMENT DW_SKAIS_DOCUM LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
_MANAGEMENT. ENT_MANAGEMEN WOID mm-dd hh24:mi:ss')
LOG_DOCUMENT_ T.
PERSON LOG_DOCUMENT_
PERSON
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
ERI_TOOTASU_HY ERI_TOOTASU_HY MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
VITAMINE VITAMINE
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
ERI_TOOTASU_HY ERI_TOOTASU_HY MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
VI_LAPS VI_LAPS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
ERP_S_RAHALINE_ ERP_S_RAHALINE_ MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
TEHING TEHING
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
ERP_S_RAHALINE_ ERP_S_RAHALINE_ MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
TEHING_VIGA TEHING_VIGA
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when to_timestamp(MUUTM_AEG) < DATE '1900-01-01' then DATE '1900-01-01'
ERP_V_KOHUSTUS ERP_V_KOHUSTUS else to_timestamp(MUUTM_AEG) end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd
_SYNDMUS _SYNDMUS hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when to_timestamp(MUUTM_AEG) < DATE '1900-01-01' then DATE '1900-01-01'
ERP_V_NOUE_SYN ERP_V_NOUE_SYN else to_timestamp(MUUTM_AEG) end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd
DMUS DMUS hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
HY_HYVITIS HY_HYVITIS MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
HY_HYVITIS_DOKU HY_HYVITIS_DOKU MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
MENT MENT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
HY_HYVITIS_ISIK HY_HYVITIS_ISIK MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
HY_HYVITIS_ISIK_ HY_HYVITIS_ISIK_K MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
KITSENDUS ITSENDUS
48
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
HY_HYVITIS_RAHA HY_HYVITIS_RAHA MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
LINE LINE
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
HY_HYVITIS_TEEN HY_HYVITIS_TEEN MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
US US
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
HY_MENETLUS HY_MENETLUS MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
HY_MENETLUS_DO HY_MENETLUS_DO MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
KUMENT KUMENT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
HY_MENETLUS_HY HY_MENETLUS_HY MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
VITIS_OLEK VITIS_OLEK
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
HY_MENETLUS_ISIK HY_MENETLUS_ISIK MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
HY_MENETLUS_SA HY_MENETLUS_SA MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
MM MM
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
HY_MENETLUS_SA HY_MENETLUS_SA MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
MM_OLEK MM_OLEK
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
IS_AMETNIK IS_AMETNIK MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
IS_EEMALOLEK IS_EEMALOLEK MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2.IS_ISIK DW_SKAIS2.IS_ISIK LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
IS_ISIK_AADRESS IS_ISIK_AADRESS MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
IS_ISIK_DOKUMENT IS_ISIK_DOKUMENT MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
IS_ISIK_KODAKON IS_ISIK_KODAKON MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
DSUS DSUS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
IS_ISIK_NOUSOLEK IS_ISIK_NOUSOLEK MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
IS_ISIK_OLEK IS_ISIK_OLEK MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
IS_ISIK_SEOS IS_ISIK_SEOS MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
IS_ISIK_SEOS_DO IS_ISIK_SEOS_DOK MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
KUMENT UMENT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
IS_ISIK_TEOVOIME IS_ISIK_TEOVOIME MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
IS_KINNIPIDAMINE IS_KINNIPIDAMINE MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
IS_KOGUMISPENSI IS_KOGUMISPENSI MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
ON ON
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
IS_KONTAKT IS_KONTAKT MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
IS_MUU_IDENTITE IS_MUU_IDENTITEET MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
ET
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
IS_NOUSOLEK IS_NOUSOLEK MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
IS_NOUSOLEK_DO IS_NOUSOLEK_DO MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
KUMENT KUMENT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
IS_OPPIMINE IS_OPPIMINE MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
IS_OPPIMINE_OLEK IS_OPPIMINE_OLEK MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
49
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
IS_POORDUMINE IS_POORDUMINE MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
IS_POORDUMINE_ IS_POORDUMINE_ MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
DOKUMENT DOKUMENT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
IS_PUUDUMINE IS_PUUDUMINE MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
IS_STAATUS IS_STAATUS MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
IS_STAATUS_DOK IS_STAATUS_DOKU MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
UMENT MENT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
IS_TEAVITUS IS_TEAVITUS MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
IS_TEAVITUS_OLEK IS_TEAVITUS_OLEK MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
IS_TOOVOIME IS_TOOVOIME MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
IS_TULU_ALUS IS_TULU_ALUS MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
IS_TULU_DOKUME IS_TULU_DOKUME MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
NT NT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
IS_VOLITUS IS_VOLITUS MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
IS_VOLITUS_DOKU IS_VOLITUS_DOKU MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
MENT MENT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
KA_KASUTAJA_RO KA_KASUTAJA_RO MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
LL_PRIVILEEG LL_PRIVILEEG
SKAIS2.KA_SEOS DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
KA_SEOS MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
KA_TOKEN_LUBA KA_TOKEN_LUBA MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
KA_TOKEN_SAADE KA_TOKEN_SAADE MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
TUD TUD
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
KL_ELEMENT KL_ELEMENT MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
KL_ELEMENT_SEOS KL_ELEMENT_SEOS MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
KL_ELEMENT_TEK KL_ELEMENT_TEK MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
ST ST
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
KL_KLASSIFIKAAT KL_KLASSIFIKAAT MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
OR OR
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AD_AADRESS LOG_AD_AADRESS WOID dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AE_ARST_SP LOG_AE_ARST_SP WOID dd hh24:mi:ss')
ETSIALIST ETSIALIST
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AE_ARST_SP LOG_AE_ARST_SP WOID dd hh24:mi:ss')
ETSIALIST_DOKUME ETSIALIST_DOKUME
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ (DOKUMENT_ID,LOG_LISAM_AEG) in (select DOKUMENT_ID, max(LOG_LISAM_AEG) from
LOG_AE_EKSPERT LOG_AE_EKSPERT WOID SKAIS2.LOG_AE_EKSPERTARST_LEPING where DOKUMENT_ID in (select DOKUMENT_ID
ARST_LEPING ARST_LEPING from SKAIS2.LOG_AE_EKSPERTARST_LEPING where log_action='D') and
LOG_LISAM_AEG>=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss') group by
DOKUMENT_ID)
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AE_ERIALA LOG_AE_ERIALA WOID dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AE_HINDAMI LOG_AE_HINDAMIN WOID dd hh24:mi:ss')
NE_TEGEVUS E_TEGEVUS
50
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AE_HINDAMI LOG_AE_HINDAMIN WOID dd hh24:mi:ss')
NE_TEGEVUS_KYS E_TEGEVUS_KYSIM
IM
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AE_HINDAMI LOG_AE_HINDAMIN WOID dd hh24:mi:ss')
NE_VALDKOND E_VALDKOND
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AE_HINDAMI LOG_AE_HINDAMIN WOID dd hh24:mi:ss')
NE_VALDKOND_TA E_VALDKOND_TASE
SE
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AE_HINNANG LOG_AE_HINNANG WOID dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AE_HINNANG LOG_AE_HINNANG WOID dd hh24:mi:ss')
_DIAGNOOS _DIAGNOOS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AE_HINNANG LOG_AE_HINNANG WOID dd hh24:mi:ss')
_MOJUTATUD _MOJUTATUD
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AE_HINNANG LOG_AE_HINNANG WOID dd hh24:mi:ss')
_OLEK _OLEK
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AE_HINNANG LOG_AE_HINNANG WOID dd hh24:mi:ss')
_TEGEVUS _TEGEVUS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AE_HINNANG LOG_AE_HINNANG WOID dd hh24:mi:ss')
_TEGEVUS_VASTUS _TEGEVUS_VASTUS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AE_HINNANG LOG_AE_HINNANG WOID dd hh24:mi:ss')
_VALDKOND _VALDKOND
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AE_HINNANG LOG_AE_HINNANG WOID dd hh24:mi:ss')
_YTLUS _YTLUS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AE_LEPING_ LOG_AE_LEPING_P WOID dd hh24:mi:ss')
PUUDUMINE UUDUMINE
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AE_LEPING_T LOG_AE_LEPING_T WOID dd hh24:mi:ss')
OO OO
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AE_PIKK_TEK LOG_AE_PIKK_TEK WOID dd hh24:mi:ss')
ST ST
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AE_TEHTUD_ LOG_AE_TEHTUD_ WOID dd hh24:mi:ss')
TOO TOO
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AE_TOO_LIIK LOG_AE_TOO_LIIK WOID dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AE_TOO_LIIK LOG_AE_TOO_LIIK WOID dd hh24:mi:ss')
_HIND _HIND
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AK_AKTSEPT LOG_AK_AKTSEPT WOID dd hh24:mi:ss')
EERIMINE EERIMINE
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_ARVE LOG_AR_ARVE WOID dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_ARVESTU LOG_AR_ARVESTU WOID dd hh24:mi:ss')
S_MUUDATUS S_MUUDATUS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_ARVE_RI LOG_AR_ARVE_RI WOID dd hh24:mi:ss')
DA DA
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_FINANTS LOG_AR_FINANTS_ WOID dd hh24:mi:ss')
_SYNDMUS SYNDMUS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_KATUSN LOG_AR_KATUSNO WOID dd hh24:mi:ss')
OUE UE
51
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_KINNIPEE LOG_AR_KINNIPEE WOID dd hh24:mi:ss')
TUD_SUMMA TUD_SUMMA
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_KINNIPID LOG_AR_KINNIPID WOID dd hh24:mi:ss')
AMINE AMINE
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_KINNIPID LOG_AR_KINNIPID WOID dd hh24:mi:ss')
AMINE_DOKUMENT AMINE_DOKUMENT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_KINNIPID LOG_AR_KINNIPID WOID dd hh24:mi:ss')
AMINE_HYVITIS AMINE_HYVITIS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_KINNIPID LOG_AR_KINNIPID WOID dd hh24:mi:ss')
AMINE_HYV_REEGE AMINE_HYV_REEGE
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_KINNIPID LOG_AR_KINNIPID WOID dd hh24:mi:ss')
AMINE_ISIK AMINE_ISIK
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_KINNIPID LOG_AR_KINNIPID WOID dd hh24:mi:ss')
AMINE_OLEK AMINE_OLEK
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_KINNIPID LOG_AR_KINNIPID WOID dd hh24:mi:ss')
AMINE_REEGEL AMINE_REEGEL
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_KINNIPID LOG_AR_KINNIPID WOID dd hh24:mi:ss')
AMINE_REEGEL_DO AMINE_REEGEL_DO
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_KINNIPID LOG_AR_KINNIPID WOID dd hh24:mi:ss')
AMINE_REEGEL_HY AMINE_REEGEL_HY
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_KOHUST LOG_AR_KOHUSTUS WOID dd hh24:mi:ss')
US
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_KOHUST LOG_AR_KOHUSTU WOID dd hh24:mi:ss')
US_MUUDATUS S_MUUDATUS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_KOHUST LOG_AR_KOHUSTU WOID dd hh24:mi:ss')
US_TYHISTUS_VIGA S_TYHISTUS_VIGA
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_KOHU_N LOG_AR_KOHU_NO WOID dd hh24:mi:ss')
OUE_SYNDMUS UE_SYNDMUS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_KOHU_VA LOG_AR_KOHU_VA WOID dd hh24:mi:ss')
LJAMAKSE LJAMAKSE
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_MAKSEG LOG_AR_MAKSEG WOID dd hh24:mi:ss')
RAAFIK RAAFIK
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_MAKSEG LOG_AR_MAKSEG WOID dd hh24:mi:ss')
RAAFIK_DOKUMENT RAAFIK_DOKUMENT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_MAKSEG LOG_AR_MAKSEG WOID dd hh24:mi:ss')
RAAFIK_RIDA RAAFIK_RIDA
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_MAKSEG LOG_AR_MAKSEG WOID dd hh24:mi:ss')
RAAFIK_RIDA_LAE RAAFIK_RIDA_LAE
KU KU
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_MAKSEK LOG_AR_MAKSEKA WOID dd hh24:mi:ss')
ANAL NAL
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_MAKSEK LOG_AR_MAKSEKA WOID dd hh24:mi:ss')
ANAL_REEGEL NAL_REEGEL
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_MAKSM_ LOG_AR_MAKSM_K WOID dd hh24:mi:ss')
KOHUSTUS OHUSTUS
52
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_MAKSULE LOG_AR_MAKSULE WOID dd hh24:mi:ss')
PING PING
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_MITTERE LOG_AR_MITTERE WOID dd hh24:mi:ss')
SIDENT SIDENT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_MITTERE LOG_AR_MITTERE WOID dd hh24:mi:ss')
S_MAKSULEPING_ S_MAKSULEPING_
TO TO
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_MVT_PAR LOG_AR_MVT_PAR WOID dd hh24:mi:ss')
ING_ISIK ING_ISIK
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_MVT_SAL LOG_AR_MVT_SAL WOID dd hh24:mi:ss')
DO DO
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_MVT_SYN LOG_AR_MVT_SYN WOID dd hh24:mi:ss')
DMUS DMUS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_NOUE LOG_AR_NOUE WOID dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_NOUE_LA LOG_AR_NOUE_LA WOID dd hh24:mi:ss')
EKUMINE EKUMINE
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_PANGAK LOG_AR_PANGAK WOID dd hh24:mi:ss')
ONTO ONTO
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_PANK LOG_AR_PANK WOID dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_PANK_PY LOG_AR_PANK_PY WOID dd hh24:mi:ss')
HA HA
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_PARAME LOG_AR_PARAMEE WOID dd hh24:mi:ss')
ETER_HYVITIS TER_HYVITIS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_PROTSES LOG_AR_PROTSES WOID dd hh24:mi:ss')
S_VEATEADE S_VEATEADE
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_RAHALIN LOG_AR_RAHALIN WOID dd hh24:mi:ss')
E_TEHING E_TEHING
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_REGRES LOG_AR_REGRESS WOID dd hh24:mi:ss')
SINOUE INOUE
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_SAP_HAN LOG_AR_SAP_HAN WOID dd hh24:mi:ss')
KIJA KIJA
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_SAP_VEA LOG_AR_SAP_VEA WOID dd hh24:mi:ss')
TEADE TEADE
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_TAGASIN LOG_AR_TAGASIN WOID dd hh24:mi:ss')
OUE OUE
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_TAGASIN LOG_AR_TAGASIN WOID dd hh24:mi:ss')
OUE_DOKUMENT OUE_DOKUMENT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_TAGASIN LOG_AR_TAGASIN WOID dd hh24:mi:ss')
OUE_HYVITIS OUE_HYVITIS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_TAGASIN LOG_AR_TAGASIN WOID dd hh24:mi:ss')
OUE_ISIK OUE_ISIK
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_TSD_ESD LOG_AR_TSD_ESD WOID dd hh24:mi:ss')
_KP _KP
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_TSD_ESD LOG_AR_TSD_ESD WOID dd hh24:mi:ss')
_SM _SM
53
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_TSD_LISA LOG_AR_TSD_LISA WOID dd hh24:mi:ss')
_1A _1A
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_TSD_LISA LOG_AR_TSD_LISA WOID dd hh24:mi:ss')
_1B _1B
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_TSD_LISA LOG_AR_TSD_LISA WOID dd hh24:mi:ss')
_2A _2A
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_TSD_LISA LOG_AR_TSD_LISA WOID dd hh24:mi:ss')
_2B _2B
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_TSD_VORM LOG_AR_TSD_VORM WOID dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_TULUMAKS LOG_AR_TULUMAKS WOID dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_TULUMAK LOG_AR_TULUMAK WOID dd hh24:mi:ss')
SUVABASTUS SUVABASTUS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_TULUMAK LOG_AR_TULUMAK WOID dd hh24:mi:ss')
SUVAB_DOKUMENT SUVAB_DOKUMENT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_VAHEMA LOG_AR_VAHEMAK WOID dd hh24:mi:ss')
KSE_PAEV SE_PAEV
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_AR_VEATEAD LOG_AR_VEATEAD WOID dd hh24:mi:ss')
E_OBJEKT E_OBJEKT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_DO_DOKUME LOG_DO_DOKUME WOID dd hh24:mi:ss')
NT NT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_DO_DOKUME LOG_DO_DOKUME WOID dd hh24:mi:ss')
NT_FAIL NT_FAIL
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_DO_DOKUME LOG_DO_DOKUME WOID dd hh24:mi:ss')
NT_OBJEKT NT_OBJEKT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_DO_DOKUME LOG_DO_DOKUME WOID dd hh24:mi:ss')
NT_SEOS NT_SEOS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_DO_DOKUME LOG_DO_DOKUME WOID dd hh24:mi:ss')
NT_SEOS_VALINE NT_SEOS_VALINE
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_DO_DOKUME LOG_DO_DOKUME WOID dd hh24:mi:ss')
NT_TEENUS NT_TEENUS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_DO_KAART LOG_DO_KAART WOID dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_DO_KYSIMUS LOG_DO_KYSIMUS WOID dd hh24:mi:ss')
TIK TIK
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_DO_KYSIMUS LOG_DO_KYSIMUS WOID dd hh24:mi:ss')
TIK_KYSIMUS TIK_KYSIMUS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_DO_KYSIMUS LOG_DO_KYSIMUS WOID dd hh24:mi:ss')
TIK_VASTUS TIK_VASTUS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_DO_KYSIMUS LOG_DO_KYSIMUS WOID dd hh24:mi:ss')
TIK_VASTUS_VALIK TIK_VASTUS_VALIK
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_DO_OTSUS LOG_DO_OTSUS WOID dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_DO_OTSUS_A LOG_DO_OTSUS_A WOID dd hh24:mi:ss')
LUS LUS
54
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_DO_PIKK_TE LOG_DO_PIKK_TEK WOID dd hh24:mi:ss')
KST ST
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_DO_TAOTLUS LOG_DO_TAOTLUS WOID dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_DO_TOOVOI LOG_DO_TOOVOIM WOID dd hh24:mi:ss')
METUSLEHT ETUSLEHT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_ERI_TOOTAS LOG_ERI_TOOTAS WOID dd hh24:mi:ss')
U_HYVITAMINE U_HYVITAMINE
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_ERI_TOOTAS LOG_ERI_TOOTAS WOID dd hh24:mi:ss')
U_HYVI_LAPS U_HYVI_LAPS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ (ERP_TEHING_ID,LOG_LISAM_AEG) in (select ERP_TEHING_ID, max(LOG_LISAM_AEG) from
LOG_ERP_S_RAHA LOG_ERP_S_RAHA WOID SKAIS2.LOG_ERP_S_RAHALINE_TEHING where ERP_TEHING_ID in (select ERP_TEHING_ID
LINE_TEHING LINE_TEHING from SKAIS2.LOG_ERP_S_RAHALINE_TEHING where log_action='D') and
LOG_LISAM_AEG>=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss') group by
ERP_TEHING_ID)
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ (ERP_VIGA_ID,LOG_LISAM_AEG) in (select ERP_VIGA_ID, max(LOG_LISAM_AEG) from
LOG_ERP_S_RAHA LOG_ERP_S_RAHA WOID SKAIS2.LOG_ERP_S_RAHALINE_TEHING_VIGA where ERP_VIGA_ID in (select ERP_VIGA_ID
LINE_TEHING_VIGA LINE_TEHING_VIGA from SKAIS2.LOG_ERP_S_RAHALINE_TEHING_VIGA where log_action='D') and
LOG_LISAM_AEG>=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss') group by
ERP_VIGA_ID)
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_ERP_V_KOHU LOG_ERP_V_KOHU WOID dd hh24:mi:ss')
STUS_SYNDMUS STUS_SYNDMUS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_ERP_V_NOUE LOG_ERP_V_NOUE WOID dd hh24:mi:ss')
_SYNDMUS _SYNDMUS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_HY_HYVITIS LOG_HY_HYVITIS WOID dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_HY_HYVITIS_ LOG_HY_HYVITIS_ WOID dd hh24:mi:ss')
DOKUMENT DOKUMENT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_HY_HYVITIS_I LOG_HY_HYVITIS_I WOID dd hh24:mi:ss')
SIK SIK
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_HY_HYVITIS_I LOG_HY_HYVITIS_I WOID dd hh24:mi:ss')
SIK_KITSENDUS SIK_KITSENDUS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_HY_HYVITIS_ LOG_HY_HYVITIS_ WOID dd hh24:mi:ss')
RAHALINE RAHALINE
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_HY_HYVITIS_ LOG_HY_HYVITIS_ WOID dd hh24:mi:ss')
TEENUS TEENUS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_HY_MENETLUS LOG_HY_MENETLUS WOID dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_HY_MENETLU LOG_HY_MENETLU WOID dd hh24:mi:ss')
S_DOKUMENT S_DOKUMENT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_HY_MENETLU LOG_HY_MENETLU WOID dd hh24:mi:ss')
S_HYVITIS_OLEK S_HYVITIS_OLEK
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_HY_MENETLU LOG_HY_MENETLU WOID dd hh24:mi:ss')
S_ISIK S_ISIK
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_HY_MENETLU LOG_HY_MENETLU WOID dd hh24:mi:ss')
S_SAMM S_SAMM
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_HY_MENETLU LOG_HY_MENETLU WOID dd hh24:mi:ss')
S_SAMM_OLEK S_SAMM_OLEK
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_IS_AMETNIK LOG_IS_AMETNIK WOID dd hh24:mi:ss')
55
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_IS_EEMALOL LOG_IS_EEMALOL WOID dd hh24:mi:ss')
EK EK
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_IS_ISIK LOG_IS_ISIK WOID dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_IS_ISIK_AADR LOG_IS_ISIK_AADR WOID dd hh24:mi:ss')
ESS ESS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_IS_ISIK_DOK LOG_IS_ISIK_DOKU WOID dd hh24:mi:ss')
UMENT MENT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_IS_ISIK_KOD LOG_IS_ISIK_KODA WOID dd hh24:mi:ss')
AKONDSUS KONDSUS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_IS_ISIK_NOU LOG_IS_ISIK_NOUS WOID dd hh24:mi:ss')
SOLEK OLEK
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_IS_ISIK_OLEK LOG_IS_ISIK_OLEK WOID dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_IS_ISIK_SEOS LOG_IS_ISIK_SEOS WOID dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_IS_ISIK_SEOS LOG_IS_ISIK_SEOS WOID dd hh24:mi:ss')
_DOKUMENT _DOKUMENT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_IS_ISIK_TEOV LOG_IS_ISIK_TEOV WOID dd hh24:mi:ss')
OIME OIME
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ (STAATUS_ID,LOG_LISAM_AEG) in (select STAATUS_ID, max(LOG_LISAM_AEG) from SKAIS2.
LOG_IS_KINNIPIDA LOG_IS_KINNIPIDA WOID LOG_IS_KINNIPIDAMINE where STAATUS_ID in (select STAATUS_ID from SKAIS2.
MINE MINE LOG_IS_KINNIPIDAMINE where log_action='D') and LOG_LISAM_AEG>=TO_DATE
('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss') group by STAATUS_ID)
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_IS_KOGUMIS LOG_IS_KOGUMIS WOID dd hh24:mi:ss')
PENSION PENSION
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_IS_KONTAKT LOG_IS_KONTAKT WOID dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_IS_MUU_IDEN LOG_IS_MUU_IDEN WOID dd hh24:mi:ss')
TITEET TITEET
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_IS_NOUSOLEK LOG_IS_NOUSOLEK WOID dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_IS_NOUSOLE LOG_IS_NOUSOLE WOID dd hh24:mi:ss')
K_DOKUMENT K_DOKUMENT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_IS_OPPIMINE LOG_IS_OPPIMINE WOID dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_IS_OPPIMINE LOG_IS_OPPIMINE WOID dd hh24:mi:ss')
_OLEK _OLEK
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_IS_POORDUM LOG_IS_POORDUM WOID dd hh24:mi:ss')
INE INE
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_IS_POORDUM LOG_IS_POORDUM WOID dd hh24:mi:ss')
INE_DOKUMENT INE_DOKUMENT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_IS_PUUDUMI LOG_IS_PUUDUMINE WOID dd hh24:mi:ss')
NE
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_IS_STAATUS LOG_IS_STAATUS WOID dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_IS_STAATUS_ LOG_IS_STAATUS_ WOID dd hh24:mi:ss')
DOKUMENT DOKUMENT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_IS_TEAVITUS LOG_IS_TEAVITUS WOID dd hh24:mi:ss')
56
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_IS_TEAVITUS LOG_IS_TEAVITUS WOID dd hh24:mi:ss')
_OLEK _OLEK
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_IS_TOOVOIME LOG_IS_TOOVOIME WOID dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_IS_TULU_ALUS LOG_IS_TULU_ALUS WOID dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_IS_TULU_DO LOG_IS_TULU_DOK WOID dd hh24:mi:ss')
KUMENT UMENT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_IS_VOLITUS LOG_IS_VOLITUS WOID dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_IS_VOLITUS_ LOG_IS_VOLITUS_ WOID dd hh24:mi:ss')
DOKUMENT DOKUMENT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_KA_KASUTAJ LOG_KA_KASUTAJ WOID dd hh24:mi:ss')
A_ROLL_PRIVILEEG A_ROLL_PRIVILEEG
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_KA_SEOS LOG_KA_SEOS WOID dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_KA_TOKEN_L LOG_KA_TOKEN_L WOID dd hh24:mi:ss')
UBA UBA
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_KA_TOKEN_S LOG_KA_TOKEN_S WOID dd hh24:mi:ss')
AADETUD AADETUD
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_KL_ELEMENT LOG_KL_ELEMENT WOID dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_KL_ELEMENT LOG_KL_ELEMENT WOID dd hh24:mi:ss')
_SEOS _SEOS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_KL_ELEMENT LOG_KL_ELEMENT WOID dd hh24:mi:ss')
_TEKST _TEKST
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_KL_KLASSIFI LOG_KL_KLASSIFIK WOID dd hh24:mi:ss')
KAATOR AATOR
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_LX_LIIDES_V LOG_LX_LIIDES_VA WOID dd hh24:mi:ss')
AARTUS_VASTAVUS ARTUS_VASTAVUS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_MT_MALL LOG_MT_MALL WOID dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_MT_MALL_TE LOG_MT_MALL_TE WOID dd hh24:mi:ss')
KST KST
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_PA_PARAME LOG_PA_PARAMEE WOID dd hh24:mi:ss')
ETER TER
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_PA_VAARTUS LOG_PA_VAARTUS WOID dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_PA_VAARTUS LOG_PA_VAARTUS WOID dd hh24:mi:ss')
_M _M
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_PE_MUU_PE LOG_PE_MUU_PEN WOID dd hh24:mi:ss')
NSION SION
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_PE_MUU_PE LOG_PE_MUU_PEN WOID dd hh24:mi:ss')
NSION_DOKUMENT SION_DOKUMENT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_PE_PENSIONI LOG_PE_PENSIONI WOID dd hh24:mi:ss')
LISA LISA
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_PE_PENSIONI LOG_PE_PENSIONI WOID dd hh24:mi:ss')
LISA_DOKUMENT LISA_DOKUMENT
57
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_PE_PENSIONI LOG_PE_PENSIONI WOID dd hh24:mi:ss')
LISA_ISIK LISA_ISIK
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_PE_SOODUS LOG_PE_SOODUST WOID dd hh24:mi:ss')
TUS US
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_PE_SOODUS LOG_PE_SOODUST WOID dd hh24:mi:ss')
TUS_DOKUMENT US_DOKUMENT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_PE_SOODUS LOG_PE_SOODUST WOID dd hh24:mi:ss')
TUS_ISIK US_ISIK
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_PE_STAAZ LOG_PE_STAAZ WOID dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_PE_STAAZ_A LOG_PE_STAAZ_A WOID dd hh24:mi:ss')
RVUTATUD RVUTATUD
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_PE_STAAZ_D LOG_PE_STAAZ_D WOID dd hh24:mi:ss')
OKUMENT OKUMENT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_PE_STAAZ_IS LOG_PE_STAAZ_IS WOID dd hh24:mi:ss')
IK IK
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_PE_STAAZ_RI LOG_PE_STAAZ_RI WOID dd hh24:mi:ss')
DA DA
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_SM_EMTA_S LOG_SM_EMTA_SO WOID dd hh24:mi:ss')
OTSMAKS TSMAKS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_SM_SOTSMA LOG_SM_SOTSMA WOID dd hh24:mi:ss')
KS_AASTA KS_AASTA
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_SM_SOTSMA LOG_SM_SOTSMA WOID dd hh24:mi:ss')
KS_AASTA_RIDA KS_AASTA_RIDA
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_SM_SOTSMA LOG_SM_SOTSMA WOID dd hh24:mi:ss')
KS_ISIKUSTATUD KS_ISIKUSTATUD
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_SM_SOTSMA LOG_SM_SOTSMA WOID dd hh24:mi:ss')
KS_ISIKUSTATUD_ KS_ISIKUSTATUD_
EM EM
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_SM_SOTSMA LOG_SM_SOTSMA WOID dd hh24:mi:ss')
KS_LIIK_REEGEL KS_LIIK_REEGEL
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_SM_SOTSMA LOG_SM_SOTSMA WOID dd hh24:mi:ss')
KS_SKEEM KS_SKEEM
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_SY_SEDEL LOG_SY_SEDEL WOID dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_SY_SEDEL_T LOG_SY_SEDEL_T WOID dd hh24:mi:ss')
EKST EKST
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_SY_TEADE LOG_SY_TEADE WOID dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_TE_TEENUS LOG_TE_TEENUS WOID dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_TE_TEENUS_ LOG_TE_TEENUS_ WOID dd hh24:mi:ss')
OSUTAMINE OSUTAMINE
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_TM_MAATRIKS LOG_TM_MAATRIKS WOID dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_TM_MAATRIK LOG_TM_MAATRIK WOID dd hh24:mi:ss')
S_TINGIMUS S_TINGIMUS
58
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_TM_TINGIMU LOG_TM_TINGIMUS WOID dd hh24:mi:ss')
S_ALUS _ALUS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_TM_TINGIMU LOG_TM_TINGIMUS WOID dd hh24:mi:ss')
S_KONTEKST _KONTEKST
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_TM_TINGIMU LOG_TM_TINGIMUS WOID dd hh24:mi:ss')
S_RIDA _RIDA
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_TM_TINGIMU LOG_TM_TINGIMUS WOID dd hh24:mi:ss')
S_VARIANT _VARIANT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_TM_TINGIMU LOG_TM_TINGIMUS WOID dd hh24:mi:ss')
S_VEERG _VEERG
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_TRY_TRYKIS LOG_TRY_TRYKIS WOID dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_TRY_TRYKIS_ LOG_TRY_TRYKIS_ WOID dd hh24:mi:ss')
ELEMENT ELEMENT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_TRY_TRYKIS_ LOG_TRY_TRYKIS_ WOID dd hh24:mi:ss')
NOUE_REEGEL NOUE_REEGEL
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_TRY_TRYKIS_ LOG_TRY_TRYKIS_ WOID dd hh24:mi:ss')
REEGEL REEGEL
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_TR_PEATAMI LOG_TR_PEATAMI WOID dd hh24:mi:ss')
NE NE
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_TR_TOOTAMI LOG_TR_TOOTAMI WOID dd hh24:mi:ss')
NE NE
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_YL_YLESANNE LOG_YL_YLESANNE WOID dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_YL_YLESANN LOG_YL_YLESANN WOID dd hh24:mi:ss')
E_DOKUMENT E_DOKUMENT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_YL_YLESANN LOG_YL_YLESANN WOID dd hh24:mi:ss')
E_ISIK E_ISIK
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_YL_YLESANN LOG_YL_YLESANN WOID dd hh24:mi:ss')
E_LIIK E_LIIK
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_YL_YLESANN LOG_YL_YLESANN WOID dd hh24:mi:ss')
E_LIIK_ROLL E_LIIK_ROLL
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_YL_YLESANN LOG_YL_YLESANN WOID dd hh24:mi:ss')
E_OLEK E_OLEK
SKAIS2. DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-
LOG_YL_YLESANN LOG_YL_YLESANN WOID dd hh24:mi:ss')
E_SEOS E_SEOS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
LX_LIIDES_VAART LX_LIIDES_VAART MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
US_VASTAVUS US_VASTAVUS
SKAIS2.MT_MALL DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
MT_MALL MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
MT_MALL_TEKST MT_MALL_TEKST MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
PA_PARAMEETER PA_PARAMEETER MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
PA_VAARTUS PA_VAARTUS MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
PA_VAARTUS_M PA_VAARTUS_M MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
59
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
PE_MUU_PENSION PE_MUU_PENSION MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
PE_MUU_PENSION PE_MUU_PENSION MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
_DOKUMENT _DOKUMENT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
PE_PENSIONILISA PE_PENSIONILISA MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
PE_PENSIONILISA_ PE_PENSIONILISA_ MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
DOKUMENT DOKUMENT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
PE_PENSIONILISA_ PE_PENSIONILISA_ MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
ISIK ISIK
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
PE_SOODUSTUS PE_SOODUSTUS MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
PE_SOODUSTUS_ PE_SOODUSTUS_D MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
DOKUMENT OKUMENT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
PE_SOODUSTUS_I PE_SOODUSTUS_I MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SIK SIK
SKAIS2.PE_STAAZ DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
PE_STAAZ MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
PE_STAAZ_ARVUT PE_STAAZ_ARVUT MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
ATUD ATUD
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
PE_STAAZ_DOKUM PE_STAAZ_DOKUM MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
ENT ENT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
PE_STAAZ_ISIK PE_STAAZ_ISIK MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
PE_STAAZ_RIDA PE_STAAZ_RIDA MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
SM_EMTA_SOTSM SM_EMTA_SOTSM MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
AKS AKS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
SM_SOTSMAKS_A SM_SOTSMAKS_AA MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
ASTA STA
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
SM_SOTSMAKS_A SM_SOTSMAKS_AA MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
ASTA_RIDA STA_RIDA
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
SM_SOTSMAKS_ISI SM_SOTSMAKS_ISI MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
KUSTATUD KUSTATUD
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
SM_SOTSMAKS_ISI SM_SOTSMAKS_ISI MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
KUSTATUD_EMTA KUSTATUD_EMTA
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
SM_SOTSMAKS_LII SM_SOTSMAKS_LII MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
K_REEGEL K_REEGEL
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
SM_SOTSMAKS_S SM_SOTSMAKS_SK MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
KEEM EEM
SKAIS2. DW_SKAIS2. REWRITE
SQLN_EXPLAIN_PL SQLN_EXPLAIN_PL
AN AN
SKAIS2.SY_SEDEL DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
SY_SEDEL MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
SY_SEDEL_TEKST SY_SEDEL_TEKST MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2.SY_TEADE DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
SY_TEADE MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
TE_TEENUS TE_TEENUS MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
60
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
TE_TEENUS_OSUT TE_TEENUS_OSUT MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
AMINE AMINE
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
TM_MAATRIKS TM_MAATRIKS MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
TM_MAATRIKS_TIN TM_MAATRIKS_TIN MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
GIMUS GIMUS
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
TM_TINGIMUS_ALUS TM_TINGIMUS_ALUS MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
TM_TINGIMUS_KO TM_TINGIMUS_KO MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
NTEKST NTEKST
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
TM_TINGIMUS_RIDA TM_TINGIMUS_RIDA MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
TM_TINGIMUS_VA TM_TINGIMUS_VAR MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
RIANT IANT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
TM_TINGIMUS_VEE TM_TINGIMUS_VEE MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
RG RG
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
TRY_TRYKIS TRY_TRYKIS MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
TRY_TRYKIS_ELE TRY_TRYKIS_ELEM MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
MENT ENT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
TRY_TRYKIS_NOU TRY_TRYKIS_NOU MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
E_REEGEL E_REEGEL
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
TRY_TRYKIS_REE TRY_TRYKIS_REEG MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
GEL EL
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
TR_PEATAMINE TR_PEATAMINE MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
TR_TOOTAMINE TR_TOOTAMINE MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
YL_YLESANNE YL_YLESANNE MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
YL_YLESANNE_DO YL_YLESANNE_DO MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
KUMENT KUMENT
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
YL_YLESANNE_ISIK YL_YLESANNE_ISIK MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
YL_YLESANNE_LIIK YL_YLESANNE_LIIK MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
YL_YLESANNE_LII YL_YLESANNE_LIIK MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
K_ROLL _ROLL
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
YL_YLESANNE_OL YL_YLESANNE_OL MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
EK EK
SKAIS2. DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
YL_YLESANNE_SE YL_YLESANNE_SE MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
OS OS
SKAIS_ISIK. DW_SKAIS_ISIK. LOAD_MODIFIED (case when coalesce(LAST_MODIFIED_DATE, CREATED_DATE) < DATE '1900-01-01'
INCOME_TAX_EXE INCOME_TAX_EXE then DATE '1900-01-01' else coalesce(LAST_MODIFIED_DATE, CREATED_DATE) end)
MPTION MPTION >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS_ISIK. DW_SKAIS_ISIK. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
LOG_INCOME_TAX LOG_INCOME_TAX WOID mm-dd hh24:mi:ss')
_EXEMPTION _EXEMPTION
SKAIS_ISIK. DW_SKAIS_ISIK. LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
LOG_REQUISITE LOG_REQUISITE WOID mm-dd hh24:mi:ss')
SKAIS_ISIK. DW_SKAIS_ISIK. REWRITE
REQUISITE REQUISITE
61
SKAIS_NOTIFICATI DW_SKAIS_NOTIFI LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
ON.LOG_MESSAGE CATION. WOID mm-dd hh24:mi:ss')
LOG_MESSAGE
SKAIS_NOTIFICATI DW_SKAIS_NOTIFI LOAD_MODIFIED_ LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
ON. CATION. WOID
LOG_MESSAGE_A LOG_MESSAGE_AT
TTACHMENT TACHMENT
SKAIS_NOTIFICATI DW_SKAIS_NOTIFI LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
ON. CATION. WOID mm-dd hh24:mi:ss')
LOG_MESSAGE_I1 LOG_MESSAGE_I1
8N 8N
SKAIS_NOTIFICATI DW_SKAIS_NOTIFI LOAD_MODIFIED_ LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
ON. CATION. WOID
LOG_MESSAGE_S LOG_MESSAGE_S
UBJECT UBJECT
SKAIS_NOTIFICATI DW_SKAIS_NOTIFI LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
ON. CATION. WOID mm-dd hh24:mi:ss')
LOG_NOTIFICATION LOG_NOTIFICATION
SKAIS_NOTIFICATI DW_SKAIS_NOTIFI LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else
ON.MESSAGE CATION.MESSAGE LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS_NOTIFICATI DW_SKAIS_NOTIFI LOAD_MODIFIED (case when coalesce(LAST_MODIFIED_DATE, CREATED_DATE) < DATE '1900-01-01'
ON. CATION. then DATE '1900-01-01' else coalesce(LAST_MODIFIED_DATE, CREATED_DATE) end)
MESSAGE_ATTAC MESSAGE_ATTACH >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
HMENT MENT
SKAIS_NOTIFICATI DW_SKAIS_NOTIFI LOAD_MODIFIED (case when coalesce(LAST_MODIFIED_DATE, CREATED_DATE) < DATE '1900-01-01'
ON.MESSAGE_I18N CATION. then DATE '1900-01-01' else coalesce(LAST_MODIFIED_DATE, CREATED_DATE) end)
MESSAGE_I18N >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS_NOTIFICATI DW_SKAIS_NOTIFI REWRITE
ON. CATION.
MESSAGE_SUBJE MESSAGE_SUBJECT
CT
SKAIS_NOTIFICATI DW_SKAIS_NOTIFI LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else
ON.NOTIFICATION CATION. LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
NOTIFICATION
SKAIS_PAKKUMUS. DW_SKAIS_PAKKU LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else
COMBINED_OFFER MUS. LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
ING COMBINED_OFFER
ING
SKAIS_PAKKUMUS. DW_SKAIS_PAKKU LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else
COMBINED_OFFER MUS. LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
ING_ATTACHMENT COMBINED_OFFER
ING_ATTACHMENT
SKAIS_PAKKUMUS. DW_SKAIS_PAKKU LOAD_MODIFIED_ LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
LOG_COMBINED_O MUS. WOID
FFERING LOG_COMBINED_O
FFERING
SKAIS_PAKKUMUS. DW_SKAIS_PAKKU LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
LOG_COMBINED_O MUS. WOID mm-dd hh24:mi:ss')
FFERING_ATTACH LOG_COMBINED_O
ME FFERING_ATTACH
ME
SKAIS_PAKKUMUS. DW_SKAIS_PAKKU LOAD_MODIFIED_ LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
LOG_OFFERING MUS. WOID
LOG_OFFERING
SKAIS_PAKKUMUS. DW_SKAIS_PAKKU LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
LOG_OFFERING_B MUS. WOID mm-dd hh24:mi:ss')
ENEFIT LOG_OFFERING_B
ENEFIT
SKAIS_PAKKUMUS. DW_SKAIS_PAKKU LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
LOG_OFFERING_G MUS. WOID mm-dd hh24:mi:ss')
ROUP LOG_OFFERING_G
ROUP
SKAIS_PAKKUMUS. DW_SKAIS_PAKKU LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
LOG_OFFERING_S MUS. WOID mm-dd hh24:mi:ss')
UBJECT LOG_OFFERING_S
UBJECT
SKAIS_PAKKUMUS. DW_SKAIS_PAKKU LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
LOG_OFFERING_S MUS. WOID mm-dd hh24:mi:ss')
UBJECT_DETAIL LOG_OFFERING_S
UBJECT_DETAIL
62
SKAIS_PAKKUMUS. DW_SKAIS_PAKKU LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else
OFFERING MUS.OFFERING LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS_PAKKUMUS. DW_SKAIS_PAKKU LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else
OFFERING_ADDITI MUS. LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
ONAL_INFO OFFERING_ADDITI
ONAL_INFO
SKAIS_PAKKUMUS. DW_SKAIS_PAKKU LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else
OFFERING_BENEFIT MUS. LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
OFFERING_BENEFIT
SKAIS_PAKKUMUS. DW_SKAIS_PAKKU LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else
OFFERING_CALCU MUS. LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
LATION_INFO OFFERING_CALCU
LATION_INFO
SKAIS_PAKKUMUS. DW_SKAIS_PAKKU LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else
OFFERING_GROUP MUS. LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
OFFERING_GROUP
SKAIS_PAKKUMUS. DW_SKAIS_PAKKU LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else
OFFERING_SUBJE MUS. LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
CT OFFERING_SUBJE
CT
SKAIS_PAKKUMUS. DW_SKAIS_PAKKU LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else
OFFERING_SUBJE MUS. LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
CT_DETAIL OFFERING_SUBJE
CT_DETAIL
SKAIS_PEREHYVIT DW_SKAIS_PEREH LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else
IS.ALLOWANCE YVITIS. LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
ALLOWANCE
SKAIS_PEREHYVIT DW_SKAIS_PEREH LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else
IS. YVITIS. LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
ALLOWANCE_SUBJ ALLOWANCE_SUBJ
ECT ECT
SKAIS_PEREHYVIT DW_SKAIS_PEREH LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else
IS. YVITIS. LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
CALCULATED_ALL CALCULATED_ALL
OWANCE OWANCE
SKAIS_PEREHYVIT DW_SKAIS_PEREH LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else
IS. YVITIS. LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
CALCULATED_ALL CALCULATED_ALL
OWANCE_PAYMENT OWANCE_PAYMENT
SKAIS_PEREHYVIT DW_SKAIS_PEREH LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else
IS. YVITIS. LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
CALCULATED_ALL CALCULATED_ALL
OWANCE_SUBTYPE OWANCE_SUBTYPE
SKAIS_PEREHYVIT DW_SKAIS_PEREH LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else
IS.DECISION YVITIS.DECISION LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS_PEREHYVIT DW_SKAIS_PEREH LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else
IS. YVITIS. LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
DECISION_BASIS DECISION_BASIS
SKAIS_PEREHYVIT DW_SKAIS_PEREH LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else
IS. YVITIS. LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
DECISION_BASIS_ DECISION_BASIS_
SETTING SETTING
SKAIS_PEREHYVIT DW_SKAIS_PEREH LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else
IS. YVITIS. LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
DECISION_EVALUA DECISION_EVALUA
TION_RESULT TION_RESULT
SKAIS_PEREHYVIT DW_SKAIS_PEREH LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else
IS. YVITIS. LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
EVALUATION_RES EVALUATION_RES
ULT ULT
SKAIS_PEREHYVIT DW_SKAIS_PEREH LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
IS. YVITIS. WOID mm-dd hh24:mi:ss')
LOG_ALLOWANCE LOG_ALLOWANCE
SKAIS_PEREHYVIT DW_SKAIS_PEREH LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
IS. YVITIS. WOID mm-dd hh24:mi:ss')
LOG_ALLOWANCE LOG_ALLOWANCE_
_SUBJECT SUBJECT
SKAIS_PEREHYVIT DW_SKAIS_PEREH LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
IS. YVITIS. WOID mm-dd hh24:mi:ss')
LOG_CALCULATED LOG_CALCULATED
_ALLOWANCE _ALLOWANCE
63
SKAIS_PEREHYVIT DW_SKAIS_PEREH LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
IS. YVITIS. WOID mm-dd hh24:mi:ss')
LOG_CALCULATED LOG_CALCULATED
_ALLOWANCE_PAY _ALLOWANCE_PAY
ME ME
SKAIS_PEREHYVIT DW_SKAIS_PEREH LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
IS. YVITIS. WOID mm-dd hh24:mi:ss')
LOG_CALCULATED LOG_CALCULATED
_ALLOWANCE_SU _ALLOWANCE_SUB
BTY TY
SKAIS_PEREHYVIT DW_SKAIS_PEREH LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
IS.LOG_DECISION YVITIS. WOID mm-dd hh24:mi:ss')
LOG_DECISION
SKAIS_PEREHYVIT DW_SKAIS_PEREH LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
IS. YVITIS. WOID mm-dd hh24:mi:ss')
LOG_DECISION_BA LOG_DECISION_BA
SIS SIS
SKAIS_PEREHYVIT DW_SKAIS_PEREH LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
IS. YVITIS. WOID mm-dd hh24:mi:ss')
LOG_DECISION_BA LOG_DECISION_BA
SIS_SETTING SIS_SETTING
SKAIS_PEREHYVIT DW_SKAIS_PEREH LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
IS. YVITIS. WOID mm-dd hh24:mi:ss')
LOG_DECISION_EV LOG_DECISION_EV
ALUATION_RESULT ALUATION_RESULT
SKAIS_PEREHYVIT DW_SKAIS_PEREH LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
IS. YVITIS. WOID mm-dd hh24:mi:ss')
LOG_EVALUATION LOG_EVALUATION
_RESULT _RESULT
SKAIS_PEREHYVIT DW_SKAIS_PEREH LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
IS.LOG_OFFERING YVITIS. WOID mm-dd hh24:mi:ss')
LOG_OFFERING
SKAIS_PEREHYVIT DW_SKAIS_PEREH LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
IS. YVITIS. WOID mm-dd hh24:mi:ss')
LOG_PARAPHRASE LOG_PARAPHRASE
SKAIS_PEREHYVIT DW_SKAIS_PEREH LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else
IS.OFFERING YVITIS.OFFERING LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS_PEREHYVIT DW_SKAIS_PEREH LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else
IS.PARAPHRASE YVITIS. LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
PARAPHRASE
SKAIS_PROCEEDI DW_SKAIS_PROCE LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else
NG.ALLOWANCE EDING. LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
ALLOWANCE
SKAIS_PROCEEDI DW_SKAIS_PROCE LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else
NG. EDING. LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
ALLOWANCE_STAT ALLOWANCE_STAT
US US
SKAIS_PROCEEDI DW_SKAIS_PROCE LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else
NG. EDING. LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
ALLOWANCE_TRA ALLOWANCE_TRAN
NSITION_EXCLUSI SITION_EXCLUSION
ON
SKAIS_PROCEEDI DW_SKAIS_PROCE LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else
NG. EDING. LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
ALLOWANCE_TRA ALLOWANCE_TRAN
NSITION_STATE SITION_STATE
SKAIS_PROCEEDI DW_SKAIS_PROCE LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else
NG.DECISION EDING.DECISION LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS_PROCEEDI DW_SKAIS_PROCE LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
NG. EDING. WOID mm-dd hh24:mi:ss')
LOG_ALLOWANCE LOG_ALLOWANCE
SKAIS_PROCEEDI DW_SKAIS_PROCE LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
NG. EDING. WOID mm-dd hh24:mi:ss')
LOG_ALLOWANCE LOG_ALLOWANCE_
_STATUS STATUS
SKAIS_PROCEEDI DW_SKAIS_PROCE LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
NG. EDING. WOID mm-dd hh24:mi:ss')
LOG_ALLOWANCE LOG_ALLOWANCE_
_TRANSITION_EXC TRANSITION_EXCLU
LU
64
SKAIS_PROCEEDI DW_SKAIS_PROCE LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
NG. EDING. WOID mm-dd hh24:mi:ss')
LOG_ALLOWANCE LOG_ALLOWANCE_
_TRANSITION_STA TRANSITION_STATE
TE
SKAIS_PROCEEDI DW_SKAIS_PROCE LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
NG.LOG_DECISION EDING. WOID mm-dd hh24:mi:ss')
LOG_DECISION
SKAIS_PROCEEDI DW_SKAIS_PROCE LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
NG.LOG_PAYMENT EDING. WOID mm-dd hh24:mi:ss')
LOG_PAYMENT
SKAIS_PROCEEDI DW_SKAIS_PROCE LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
NG. EDING. WOID mm-dd hh24:mi:ss')
LOG_PAYMENT_C LOG_PAYMENT_CH
HANNEL ANNEL
SKAIS_PROCEEDI DW_SKAIS_PROCE LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
NG.LOG_SUBJECT EDING. WOID mm-dd hh24:mi:ss')
LOG_SUBJECT
SKAIS_PROCEEDI DW_SKAIS_PROCE LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else
NG.PAYMENT EDING.PAYMENT LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS_PROCEEDI DW_SKAIS_PROCE LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else
NG. EDING. LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
PAYMENT_CHANN PAYMENT_CHANN
EL EL
SKAIS_PROCEEDI DW_SKAIS_PROCE LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else
NG.SUBJECT EDING.SUBJECT LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS_TECHNICAL DW_SKAIS_TECHNI REWRITE
AID.ISO CALAID.ISO
SKAIS_TECHNICAL DW_SKAIS_TECHNI REWRITE
AID. CALAID.
ISO_CONDITION ISO_CONDITION
SKAIS_TECHNICAL DW_SKAIS_TECHNI REWRITE
AID. CALAID.
ISO_CONDITION_C ISO_CONDITION_C
ODE ODE
SKAIS_TECHNICAL DW_SKAIS_TECHNI REWRITE
AID. CALAID.
ISO_JUSTIFICATIO ISO_JUSTIFICATIO
N_LIMIT N_LIMIT
SKAIS_TECHNICAL DW_SKAIS_TECHNI REWRITE
AID.JUSTIFICATION CALAID.
JUSTIFICATION
SKAIS_TECHNICAL DW_SKAIS_TECHNI LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
AID.LOG_ISO CALAID.LOG_ISO WOID mm-dd hh24:mi:ss')
SKAIS_TECHNICAL DW_SKAIS_TECHNI LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
AID. CALAID. WOID mm-dd hh24:mi:ss')
LOG_ISO_CONDITI LOG_ISO_CONDITI
ON ON
SKAIS_TECHNICAL DW_SKAIS_TECHNI LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
AID. CALAID. WOID mm-dd hh24:mi:ss')
LOG_ISO_CONDITI LOG_ISO_CONDITI
ON_CODE ON_CODE
SKAIS_TECHNICAL DW_SKAIS_TECHNI LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
AID. CALAID. WOID mm-dd hh24:mi:ss')
LOG_ISO_JUSTIFIC LOG_ISO_JUSTIFIC
ATION_LIMIT ATION_LIMIT
SKAIS_TECHNICAL DW_SKAIS_TECHNI LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
AID. CALAID. WOID mm-dd hh24:mi:ss')
LOG_JUSTIFICATION LOG_JUSTIFICATION
SKAIS_TECHNICAL DW_SKAIS_TECHNI LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
AID. CALAID. WOID mm-dd hh24:mi:ss')
LOG_PROVIDER LOG_PROVIDER
SKAIS_TECHNICAL DW_SKAIS_TECHNI LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
AID. CALAID. WOID mm-dd hh24:mi:ss')
LOG_RENT_PERIOD LOG_RENT_PERIOD
SKAIS_TECHNICAL DW_SKAIS_TECHNI LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
AID. CALAID. WOID mm-dd hh24:mi:ss')
LOG_SPECIAL_RE LOG_SPECIAL_RE
QUEST QUEST
65
SKAIS_TECHNICAL DW_SKAIS_TECHNI LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
AID. CALAID. WOID mm-dd hh24:mi:ss')
LOG_TRANSACTION LOG_TRANSACTION
SKAIS_TECHNICAL DW_SKAIS_TECHNI LOAD_MODIFIED_ LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-
AID. CALAID. WOID mm-dd hh24:mi:ss')
LOG_TRANSACTIO LOG_TRANSACTIO
N_ROW N_ROW
SKAIS_TECHNICAL DW_SKAIS_TECHNI LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else
AID.PROVIDER CALAID.PROVIDER LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS_TECHNICAL DW_SKAIS_TECHNI LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else
AID.RENT_PERIOD CALAID. LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
RENT_PERIOD
SKAIS_TECHNICAL DW_SKAIS_TECHNI LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else
AID. CALAID. LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SPECIAL_REQUEST SPECIAL_REQUEST
SKAIS_TECHNICAL DW_SKAIS_TECHNI LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else
AID.TRANSACTION CALAID. LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
TRANSACTION
SKAIS_TECHNICAL DW_SKAIS_TECHNI LOAD_MODIFIED (case when coalesce(LAST_MODIFIED_DATE, CREATED_DATE) < DATE '1900-01-01'
AID. CALAID. then DATE '1900-01-01' else coalesce(LAST_MODIFIED_DATE, CREATED_DATE) end)
TRANSACTION_ROW TRANSACTION_ROW >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS_TECHNICAL DW_SKAIS_TECHNI LOAD_MODIFIED (case when REQUEST_RECEIVED < DATE '1900-01-01' then DATE '1900-01-01' else
AIDXROAD. CALAIDXROAD. REQUEST_RECEIVED end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
XROAD_INBOUND_ XROAD_INBOUND_
REQUEST REQUEST
SKAIS2VALINE. DW_SKAIS2_VALIN REWRITE
SKAIS1_PRT_DATA E_ODS.
SKAIS1_PRT_DATA
SKAIS_RINAFACADE CASE_INFO LOAD_MODIFIED (case when coalesce(LAST_MODIFIED_DATE, CREATED_DATE) < DATE '1900-01-01'
then DATE '1900-01-01' else coalesce(LAST_MODIFIED_DATE, CREATED_DATE) end)
>=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')
SKAIS_RINAFACADE CASE_STATE LOAD_MODIFIED (case when CREATED_DATE < DATE ''1900-01-01'' then DATE ''1900-01-01'' else
CREATED_DATE end) >=TO_DATE(''[LAST_LOAD_DT]'',''yyyy-mm-dd hh24:mi:ss'')
SKAIS_RINAFACADE LOG_CASE_INFO LOAD_MODIFIED_ LOG_ACTION in (''D'',''I'') and LOG_CREATE_TIME >=TO_DATE
WOID (''[LAST_LOAD_DT]'',''yyyy-mm-dd hh24:mi:ss'')
SKAIS_RINAFACADE LOG_CASE_STATE LOAD_MODIFIED_ LOG_ACTION in (''D'',''I'') and LOG_CREATE_TIME >=TO_DATE
WOID (''[LAST_LOAD_DT]'',''yyyy-mm-dd hh24:mi:ss'')
SKAIS2.IS_KONTAK DW_SKAIS2. LOAD_MODIFIED (case when MUUTM_AEG < DATE ''1900-01-01'' then DATE ''1900-01-01'' else
T_STAATUS IS_KONTAKT_STAA MUUTM_AEG end) >=TO_DATE(''[LAST_LOAD_DT]'',''yyyy-mm-dd hh24:mi:ss'')
TUS
SKAIS2.LOG_IS_KO DW_SKAIS2. LOAD_MODIFIED_ LOG_ACTION in (''D'',''I'') and LOG_LISAM_AEG >=TO_DATE(''[LAST_LOAD_DT]'',''yyyy-
NTAKT_STAATUS LOG_IS_KONTAKT_ WOID mm-dd hh24:mi:ss'')
STAATUS
skais_doctor_assess DW_SKAIS_DOCTO LOAD_MODIFIED (case when MUUTM_AEG < DATE ''1900-01-01'' then DATE ''1900-01-01'' else
ment.activity_catego R_ASSESSMENT_O MUUTM_AEG end) >=TO_DATE(''[LAST_LOAD_DT]'',''yyyy-mm-dd hh24:mi:ss'')
ry DS.activity_category
skais_doctor_assess DW_SKAIS_DOCTO LOAD_MODIFIED (case when MUUTM_AEG < DATE ''1900-01-01'' then DATE ''1900-01-01'' else
ment. R_ASSESSMENT_O MUUTM_AEG end) >=TO_DATE(''[LAST_LOAD_DT]'',''yyyy-mm-dd hh24:mi:ss'')
domain_category DS.domain_category
skais_doctor_assess DW_SKAIS_DOCTO LOAD_MODIFIED (case when MUUTM_AEG < DATE ''1900-01-01'' then DATE ''1900-01-01'' else
ment.exp_deviation_ R_ASSESSMENT_O MUUTM_AEG end) >=TO_DATE(''[LAST_LOAD_DT]'',''yyyy-mm-dd hh24:mi:ss'')
icf_category DS.
exp_deviation_icf_ca
tegory
skais_doctor_assess DW_SKAIS_DOCTO LOAD_MODIFIED_ LOG_ACTION in (''D'',''I'') and LOG_LISAM_AEG >=TO_DATE(''[LAST_LOAD_DT]'',''yyyy-
ment. R_ASSESSMENT_O WOID mm-dd hh24:mi:ss'')
log_activity_category DS.
log_activity_category
skais_doctor_assess DW_SKAIS_DOCTO LOAD_MODIFIED_ LOG_ACTION in (''D'',''I'') and LOG_LISAM_AEG >=TO_DATE(''[LAST_LOAD_DT]'',''yyyy-
ment. R_ASSESSMENT_O WOID mm-dd hh24:mi:ss'')
log_domain_category DS.
log_domain_category
skais_doctor_assess DW_SKAIS_DOCTO LOAD_MODIFIED_ LOG_ACTION in (''D'',''I'') and LOG_LISAM_AEG >=TO_DATE(''[LAST_LOAD_DT]'',''yyyy-
ment.log_exp_deviati R_ASSESSMENT_O WOID mm-dd hh24:mi:ss'')
on_icf_category DS.
log_exp_deviation_ic
f_category
66
SKA SKAIS2 DWH Pentaho Data-Intergration
paigaldusjuhend
Paigaldus üldjuhul sama, nagu Skais1 puhul. Eristab ainult pentaho repositooriumi ehk
laadimisskriptide ja ühendusfailide sisu.
Pentaho Data Integration - kettle
Pentaho Data Integration on ETL tarkvara – andmete eksport, töötlemine ja ümberlaadimine.
Paigaldatakse Pentaho Community Edition (CE), mis on vabavaraline tarkvara
Kasutaja
Pentaho java protsess käivitatakse pentaho kasutaja alt.
sudo useradd pentaho
sudo passwd pentaho
Java JDK
Pentaho jaoks paigaldatakse uusim JDK8 versioon
RPM installi puhul paigaldatakse JDK asukohta /usr/java/default
cd /tmp/java
sudo rpm -Uvh jdk-8u151-linux-x64.rpm
Lisada JAVA_HOME keskkonnamuutuja pentaho kasutajale
vi /home/pentaho/.bash_profile
export JAVA_HOME=/usr/java/default/jre
Install
PDI ei vaja eraldi paigaldust. Arhiiv lahti pakkida ja õigused anda.
Pentaho Data Integration CE versiooni saab alla laadida sourceforge-st:
https://sourceforge.net/projects/pentaho/files/Data%20Integration/
Pentaho alla laadida, lahti pakkida ja õigused sättida.
cd /tmp/pentaho
unzip pdi-ce-8.0.zip
sudo mkdir /opt/data-integration
sudo mv * /opt/data-integration
cd /opt/data-integration
sudo chmod -R u+x *.sh
sudo chown –R pentaho *
67
JDBC andmeühendused
Pentaho on javal baseeruv ja seega kasutab andmebaasi ühendusteks JDBC ühendusi.
Pentaho ühendub oracle ja vertica andmebaasiga.
Andmebaasi draiverid
Paigaldada vertica ja oracle sobilikud andmebaasi draiverid.
Pentaho nimekiri draiveritest:
https://help.pentaho.com/Documentation/5.3/0D0/160/010
Vertica 9.0.0 draiveri leiab:
https://my.vertica.com/download/vertica/client-drivers/
Oracle draiveri versioon valida vastavalt andmebaasimootori versioonile
http://www.oracle.com/technetwork/database/features/jdbc/index-091264.html
Draiverite jar failid liigutada pentaho lib kausta
/opt/pentaho/data-integration/lib
Pentaho repositoorium
Kirjeldada pentaho repositoorium kus hakkavad laadimisskriptid asuma
vi /home/pentaho/.kettle/repositories.xml
Jälgida asukohta – asukoht on osades skriptides sisse kirjutatud
<?xml version="1.0" encoding="UTF-8"?>
<repositories>
<repository> <id>KettleFileRepository</id>
<name>ska</name>
<description>SKAIS2 DWH REPO</description>
<is_default>false</is_default>
<base_directory>/home/pentaho/repo_skais2</base_directory>
<read_only>N</read_only>
<hides_hidden_files>N</hides_hidden_files>
</repository> </repositories>
Luua repositooriumi kaust
sudo mkdir /home/pentaho/repo_skais2
sudo chown pentaho:pentaho /home/pentaho/repo_skais2
Repo olemasolu saab kontrollida:
cd /srv/pentaho
./kitchen.sh -listrep
68
Laadimisskriptid
Kopeerida pentaho failid (laadimisskriptid) pentaho repositooriumi kausta.
cp -R /tmp/laadimisskriptid/* /home/pentaho/repo
sudo chown -R pentaho:pentaho /home/pentaho/repo
Andmeühenduste failid
Pentaho repositooriumis asuvad andmeühendusi defineerivad kdb failid. Ühenduse failides tuleb muuta parameetrid live Vertica-le vastavaks
Krüpteerida vertica kasutaja „pentaho“ parool ja SKAIS andmebaasi ühenduse kasutaja. Salvesta väljund, mis on kujul „Encrypted 123456...“
sudo su - pentaho
/opt/data-integration/encr.sh -kettle vertica_voi_oracle_pentaho_parool
Conn_dwh on vertica ühendust kirjeldav fail
vi /home/pentaho/repo/conn_dwh.kdb
Muuta vertica ühendusel serverinimi, baasinimi, port, parool(pentaho Vertica kasutaja). Port on kirjeldatud kahes kohas. Nimi conn_ska_wrh peab samaks
jääma
<connection>
<name>conn_ska_wrh</name>
<server>ska-wrh-1a.prd.tehik.ee</server>
<type>VERTICA5</type>
<access>Native</access>
<database>ska_wrh_db</database>
<port>5433</port>
<username>pentaho</username>
<password>Encrypted *****</password>
<servername/>
<data_tablespace/>
<index_tablespace/>
<attributes>
.......
<attribute><code>PORT_NUMBER</code><attribute>5433</attribute></attribute>
Conn_oracle on Oracle Skais2 baasi ühendust kirjeldav fail
vi /home/pentaho/repo/conn_oracle.kdb
69
<connection>
<name>conn_oracle</name>
<server/>
<type>GENERIC</type>
<access>Native</access>
<database/>
<port>1521</port>
<username>SKA_ANDMEAIT</username>
<password>******</password>
<servername/>
<data_tablespace/>
<index_tablespace/>
<attributes>
<attribute><code>CUSTOM_DRIVER_CLASS</code><attribute>oracle.jdbc.driver.OracleDriver</attribute></attribute>
<attribute><code>CUSTOM_URL</code><attribute>jdbc:oracle:thin:@//84.50.231.112:1521/PSKAIS2APP</attribute></attribute>
<attribute><code>FORCE_IDENTIFIERS_TO_LOWERCASE</code><attribute>N</attribute></attribute>
<attribute><code>FORCE_IDENTIFIERS_TO_UPPERCASE</code><attribute>N</attribute></attribute>
<attribute><code>IS_CLUSTERED</code><attribute>N</attribute></attribute>
<attribute><code>PORT_NUMBER</code><attribute>1521</attribute></attribute>
<attribute><code>PRESERVE_RESERVED_WORD_CASE</code><attribute>Y</attribute></attribute>
<attribute><code>QUOTE_ALL_FIELDS</code><attribute>N</attribute></attribute>
<attribute><code>SUPPORTS_BOOLEAN_DATA_TYPE</code><attribute>Y</attribute></attribute>
<attribute><code>SUPPORTS_TIMESTAMP_DATA_TYPE</code><attribute>Y</attribute></attribute>
<attribute><code>USE_POOLING</code><attribute>N</attribute></attribute>
</attributes>
</connection>
70
SKA SKAIS2 DWH Vertica ühendumise juhend
Keskkondade parameetrid
Vaata parameetreid lehelt Serverid ja ühendused
Kasutaja
Skais vertica kasutajaid haldab Tehik (itabi)
JDBC
Java põhiste klientide kaudu ühendumine Dbeaver näitel
Draiver
Laadi alla Vertica JDBC uusima versiooni draiveri fail ja paiguta oma arvutis kindlasse kohta.
https://www.vertica.com/download/vertica/client-drivers/
https://www.vertica.com/client_drivers/24.2.x/24.2.0-0/vertica-jdbc-24.2.0-0.jar
Dbeaver
Laadi alla ja paigalda Dbeaver Community edition (koos JRE-ga)
https://dbeaver.io/download/
Dbeaver ühendus
Kui dbeaver on käivitatud, siis tuleb luua uus ühendus, määrata draiver ja sättida parameetrid.
New Connection > Connection Type Vertica > Määrata ühenduse parameetrid
Edit Driver Settings alt lisada eelnevalt allalaetud vertica-jdbc-***.jar fail
71
Test connection
Ühendu lisatud ühenduse andmebaasiga
ODBC
ODBC põhiste klientide kaudu ühendamine
Client
Tõmba alla ja paigalda Vertica uusim Windows Client
https://www.vertica.com/client_drivers/24.2.x/24.2.0-0/VerticaSetup-24.2.0-0.exe
ODBC
Lisada ODBC ühendus vastava baasi parameetritega
Start > ODBC Data Sources (64-bit) > Add > Vertica
Määra Database, Server, Port ja kasutaja Basic Settings alt.
72
73
SKA SKAIS2 DW süsteemsed tabelid
74
COLUMNS SKAIS2
Väljade/veergude andmed
Välja nimi Välja Selgitus Andmete näited
tüüp
COLUMN_VERSION int Surrogaatvõti 6750
_ID
DATA_SOURCE_CO varchar Andmeallika/lähtesüsteemi kood 'SKAIS2'
DE (20)
SOURCE_SCHEMA_ varchar Skeemi nimi lähtesüsteemis 'SKAIS2'
NAME (128)
SOURCE_TABLE_N varchar Tabeli nimi lähtesüsteemis 'AR_PROTSESS_VEATEADE'
AME (128)
SOURCE_COLUMN_ varchar Välja/veeru nimi lähtesüsteemis 'VEATEADE_SYS'
NAME (128)
DWH_COLUMN_NA varchar Välja/veeru nimi andmelaos 'VEATEADE_SYS'
ME (128)
SOURCE_COLUMN_ varchar Välja/veeru kirjeldus lähtesüsteemis 'Kommentaar'
COMMENT (4000)
DWH_COLUMN_CO varchar Välja/veeru kirjeldus andmelaos 'Kommentaar'
MMENT (4000)
DATA_TYPE varchar Andmetüüp lähtesüsteemis 'VARCHAR2', 'INTEGER', 'DECIMAL', 'CLOB'
(128)
DATA_LENGTH int Andmevälja pikkus lähtesüsteemis 4000
DATA_PRECISION int Andmevälja täpsus lähtesüsteemis 18
DATA_SCALE int Andmevälja täpsus peale koma 0
lähtesüsteemis
DWH_DATA_TYPE varchar Andmetüüp andmelaos 'VARCHAR(20000)'
(255)
NULLABLE char(1) Kas veerg võib sisaldada puuduvaid 1
(NULL) väärtusi (0/1)
IS_KEY int Kas veerg on primaarvõti (0/1) 0
LOAD_STATUS varchar Välja/veeru laadimise staatus 'LOAD' - Välja laadimine on sisse lülitatud
(20) andmelaos
'NEW_LOAD' - Tegemist on uue väljaga (st haldur pole välja laadimise staatust üle vaadanud
/kinnitanud), väli on laadimisse sisse lülitatud
'NEW_NOT_LOAD' - Tegemist on uue väljaga, väli ei ole laadimisse sisse lülitatud
'NOT_LOAD' - välja laadimine ei ole sisse lülitatud
'NO_OBJECT' - välja ei ole enam lähtesüsteemis (varem oli)
DWH_COLUMN_STA varchar Välja staatus andmelaos: 'NEEDS_CREATION' - väli vajab loomist
TUS (30)
'NEEDS_MODIFICATION' - väli vajab muutmist (näiteks lähteallikas on muutunud
andmetüüp)
'READY' - väli on loodud/muudetud
SOURCE_COLUMN_ int Välja/veeru ID lähtesüsteemis 7
ID
IS_VALID int Kas tegemist on kehtiva kirje 1
/versiooniga (0/1)
VALID_FROM timesta Kirje/versiooni kehtivuse algusaeg '2019-06-16 20:36:18'
mp
VALID_TO timesta Kirje/versiooni kehtivuse lõppaeg '2019-07-02 11:11:26'
mp
MODIFIED_BY varchar Kirje looja/muutja 'pentaho'
(32)
75
DATA_SOURCE_PARAMS SKAIS2
Lähtesüsteemi andmebaasi (tehnilised) parameetrid.
Välja nimi Välja tüüp Selgitus Andmete näited
DATA_SOURCE_CODE varchar(20) Andmeallika/lähtesüsteemi kood 'SKAIS2'
DB_SERVER_NAME varchar(32) Serveri nimi või IP aadress 'test-test.ml.ee '
DB_PORT_NR int Pordi number 1234
DB_NAME varchar(32) Andmebaasi nimi 'SKAIS2'
DB_USERNAME varchar(32) Kasutajanimi 'SKAIS2_USER_NAME'
DB_PASSWORD varchar(128) Parooli räsi (luuakse pentaho encr.sh abil). Vt täpsemalt paigaldusjuhendist. 'Encrypted 0123456789ABCDEF'
76
DATA_SOURCES SKAIS2
Andmeallikad (lähte-andmebaasid)
Välja nimi Välja Selgitus Andmete näited
tüüp
DATA_SOURCE_VERS int Andmeallika versiooni ID. Surrogaatvõti. 1
ION_ID
DATA_SOURCE_CODE varchar Andmeallika/lähtesüsteemi kood. 'SKAIS2'
(32)
DATA_SOURCE_NAME varchar Lätesüsteemi nimetus 'SKAIS2'
(128)
DATA_SOURCE_TYPE varchar Lähtesüsteemi tüüp 'SOURCE_DB' - lähtesüsteemiks on
(20) andmebaas
'TARGET' - andmelao andmebaas
DBMS_TYPE varchar Andmebaasi tüüp 'ORACLE'
(20)
IS_ACTIVE int Kas lähtesüsteemist andmete laadimine on aktiivne (võimaldab terve lähtesüsteemi 1
laadimise korraga välja lülitada)
IS_LOAD_TABLES int Kas lähtesüsteemist laaditakse andmetabeleid (table) 0
IS_LOAD_VIEWS int Kas lähtesüsteemist laaditakse vaateid (view) 0
IS_LOAD_MVIEWS int Kas lähtesüsteemist laaditakse materialiseeritud vaateis (materialized view) 1
IS_VALID int Kas tegemist on kehtiva kirje/versiooniga (0/1) 1
VALID_FROM timestamp Kirje/versiooni kehtivuse algusaeg '2019-06-14 17:08:06'
VALID_TO timestamp Kirje/versiooni kehtivuse lõppaeg '2019-10-14 17:08:06', NULL
MODIFIED_BY varchar Versiooni lisaja/muutja 'SYSTEM'
(32)
HAS_DEL_REC int Kas selles andmeallika korral kasutatakse kustutatud kirjete tühistamist. 0
77
DATA_TYPE_CONVERSIONS SKAIS2
Välja tüüpide teisendustabel
Välja nimi Välja tüüp Selgitus Andmete näited
ID int Surrogaatvõti 2
DBMS_TYPE varchar(20) Lähtesüsteemi andmebaasi tüüp 'ORACLE'
DATA_TYPE varchar(128) Andmetüüp lähtesüsteemis 'DATE'
DATA_LENGTH int Andmevälja pikkus lähtesüsteemis 10
DATA_PRECISION int Andmevälja täpsus lähtesüsteemis 1
DATA_SCALE int Andmevälja täpsus peale koma lähtesüsteemis 1
TARGET_DATA_TYPE varchar(128) Andmetüüp (sh pikkus ja täpsus) andmelaos 'DATETIME'
78
DMARTS SKAIS2
Andmeletid. Kasutatakse andmelettide laadimise protsessis (hetkel seda SKAIS2 juures kasutusel ei ole).
Välja nimi Välja tüüp Selgitus Andmete näited
DMART_TABLE_ID int Surrogaatvõti 6750
DWH_SCHEMA_NAME varchar(20) Skeemi nimi, kus asub andmelett 'SKAIS2'
DMART_TABLE_NAME varchar(255) Andmeleti nimi 'PUUDED'
LOAD_ORDER_NR int Andmeleti laadimise järjekorranumber 1
IS_ACTIVE int Kas andmeleti laadimine on aktiivne (0/1) 1
DATA_SOURCE_CODE varchar(30) Andmeallika nimi 'SKAIS2'
79
DWH_SCHEMAS SKAIS2
Andmelao skeemide andmed.
Iga siin kirjeldatus skeemi kohta luuakse andmelaos vähemalt 2 skeemi (<skeemi nimi>_STG - vastava loogilise andmeallika staging tabelite skeem,
<skeemi_nimi>_ODS - vastava loogilise andmeallika ODS tabelite skeem). Lisaks luuakse vajaduse korral (kui HAS_DMARTS = 1) skeem <skeemi
nimi>_DMART, mis sisaldab vastava andmeallika dimensiooni- ja faktitabeleid ja andmelette.
Välja nimi Välja Selgitus Andmete näited
tüüp
DWH_SCHEMA_VERSIO int Skeemi versiooni ID 1
N_ID
DWH_SCHEMA_NAME varchar(32) Andmelao skeemi/loogilise andmeallika nimi 'ORACLE'
DWH_SCHEMA_COMME varchar Andmelao skeemi kirjeldus 'SKAIS2 põhiandmed'
NT (255)
DWH_SCHEMA_STATUS varchar(30) Andmelao skeemi staatus 'NEEDS_CREATION' - skeem on loomata
'NEEDS_MODIFICATION' - skeemis on objekte (tabeleid), mida on
vaja muuta
'READY' - skeem ja kõik seal olevad objektid on loodud/muudetud
HAS_DMARTS int Kas skeem sisaldab andmelette 1
IS_ACTIVE int Kas skeemi/loogilise andmeallika andmete laadimine 1
on aktiivne.
IS_VALID int Kas tegemist on kehtiva kirje/versiooniga (0/1) 0
VALID_FROM Timestamp Kirje/versiooni kehtivuse algusaeg '2019-06-14 17:08:06'
VALID_TO Timestamp Kirje/versiooni kehtivuse lõppaeg '2019-06-16 20:50:15'
MODIFIED_BY varchar(32) Versiooni lisaja/muutja 'pentaho'
80
EVENT_LOG SKAIS2
Sündmuste logi
Välja nimi Välja Selgitus Andmete näited
tüüp
EVENT_ID int Sündmuse ID. Primaarvõti. 1
EVENT_DT Timestamp Sündmuse toimumise/registreerimise kuupäev ja kellaaeg '2019-06-14 17:08:04'
EVENT_CLASS varchar Sündmuse grupi kood. Võimalikud väärtused: 'INSTALLATION',
(20) 'LOADING'
INSTALLATION - installimine
LOADING - laadimine
EVENT_CODE varchar Sündmuse tüüp. Võimalikud variandid: 'ERROR'
(20)
ERROR - viga, WARNING - hoiatus, SUCCESS - edukas tegevus, INFO - teade, START - installimise
alustamine,
END_COMPARE_META - metadata võrdlemise lõpp, INSERT DATA- andmete sisestamine,
CREATE_TABLE - tabel loodud,
SCHEMA CREATED - skeem loodud, COLUMN ADDED - veerg lisatud, TABLE CREATED - tabel loodud,
END - installimise lõpp
EVENT_MESSA varchar Sündmuse kirjeldus 'ERROR in loading STG
GE (255) table'
RELATED_OBJ varchar Sündmusega seotud objekt (nt tabeli nimi, lähteallika nimi vms). Konkreetne objekt sõltub sündmuse koodist. 'ADM_SKAIS2.TABLES'
ECT (50)
PROCESS_NA varchar Pentaho protsessi nimi, mis sündmuse tekitas 'run_upgrade'
ME (50)
STEP_NAME varchar Pentaho sammu (step) nimi, mis sündmuse tekitas 'schema & main tables'
(50)
81
IMP_COLUMNS SKAIS2
Välja nimi Välja tüüp Selgitus Andmete näited
DATA_SOURCE_CODE varchar(32) Lähtesüsteemi kood 'SKAIS2'
SCHEMA_NAME varchar(128) Välja/veeru nimi lähtesüsteemis 'SKAIS2'
TABLE_NAME varchar(128) Tabeli nimi lähtesüsteemis 'AD_AADRESS'
COLUMN_NAME varchar(128) Välja/veeru nimi andmelaos 'ADS_ADS_OID'
COLUMN_COMMENT varchar(4000) Välja/veeru kirjeldus lähtesüsteemis 'Kommentaar'
DATA_TYPE varchar(128) Andmetüüp lähtesüsteems 'VARCHAR2'
DATA_LENGTH int Andmevälja pikkus lähtesüsteemis 40
DATA_PRECISION int Andmevälja täpsus lähtesüsteemis 18
DATA_SCALE int Andmevälja täpsus peale koma lähtesüsteemis 0
NULLABLE char(1) Kas puuduvad (NULL) väärtused on lubatud 'Y'
IS_KEY int Kas väli/veerg on primaarvõti lähtesüsteemis 0
COLUMN_ID int Välja/veeru identifikaator lähtesüsteemis 18
82
IMP_SCHEMAS SKAIS2
Välja nimi Välja tüüp Selgitus Andmete näited
DATA_SOURCE_CODE varchar(32) Andmeallika/lähtesüsteemi kood. Viide tabelisse DATA_SOURCES 'SKAIS2'
SCHEMA_NAME varchar(128) Skeemi nimi lähtesüsteemis 'SKAIS2'
83
IMP_TABLES SKAIS2
Välja nimi Välja tüüp Selgitus Andmete näited
DATA_SOURCE_CODE varchar(32) Andmeallika/lätesüsteemi kood. Viide tabelisse DATA_SOURCES 'SKAIS2'
SCHEMA_NAME varchar(128) Skeemi nimi lähtesüsteemis 'SKAIS2'
TABLE_NAME varchar(128) Tabeli nimi lähtesüsteemis 'AE_ERIALA'
TABLE_TYPE varchar(20) Tabeli tüüp (TABLE - tabel, VIEW - vaade, MVIEW - materialiseeritud vaade) 'TABLE'
TABLE_COMMENT varchar(4000) Tabeli kirjeldus läthesüsteemis 'Kommentaar'
84
LOAD_LOG SKAIS2
Andmete laadimise logi
Välja Välja Selgitus Kommentaar Andmete
nimi tüüp näide
LOG_ID int Logikirje identifikaator.
Primaarvõti.
PROCE int Laadimise protsessi Iga käivitatud andmete laadimise protsess saab unikaalse identifikaatori. 1
SS_ID identifikaator.
SUBPR varchar Alamprotsessi kood Võimalikud väärtused: 'STG_LOAD'
OCESS (50) /nimi
_CODE COMPARE_DATA_MODEL - andmemudeli võrdlemise protsess
DMART_LOAD - andmelettide laadimise protsess,
DS_LOAD - andmeallika laadimine
DWH_LOAD - andmelao laadimine (kogu laadimisprotsess)
META_LOAD - metaandmete laadimine
ODS_LOAD - ODS tabelite laadimise protsess
STG_LOAD - STG tabelite laadimise protsess
UPDATE_DATABASE - andmemudeli muutmise protsess
DATA_S varchar Andmeallika kood. 'SKAIS2'
OURCE (32) Viide tabelile
_CODE ADM_SKAIS2.
DATA_SOURCES
RELATE varchar Protsessiga seotud 'SKAIS2.
D_OBJE (50) objekti (skeemi, IS_EEMALO
CT andmetabeli vms) kood LEK'
START_ timesta Protsessi käivitamise '2019-06-16
DT mp algusaeg 21:29:22'
END_DT timesta Protsessi käivitamise '2019-06-16
mp lõppaeg 21:29:25'
STATUS varchar Laadimise protsessi Võimalikud väärtused: 'ERROR'
(32) (lõpetamise) staatus.
STARTED - protsessi on alustatud aga see pole veel lõppenund
SUCCESS - protsess on lõppenud edukalt
WARNING - protsess on lõppenud hoiatusega, konkreetsed hoiatusteated asuvad tabelis EVENT_LOG
ERROR - protsess on lõppenud veaga, konkreetsed veateated asuvad tabelis EVENT_LOG
NOT_LOADED - Laadimist ei teostatud, sest eelmine laadimine lõppes veaga.
IS_IGN int Kas lõpetamise Kui eelmine laadimise protsess ei ole lõppenud (on staatuses STARTED) või lõppes veaga (on staatuses 0
ORE staatust võib ERROR), siis üldjuhul järgmist sama allika laadimisprotsessi ei käivitata. Kui on soov järgmine laadimine
ignoreerida. ikkagi käivitada, siis tuleb eelmisel laadimisprotsessil märkida IS_IGNORE = 1.
85
PARAMETERS SKAIS2
Süsteemi parameetrid (hetkel ei ole kasutusel).
Välja nimi Välja tüüp Selgitus Andmete näited
PARAMETER_ID int Surrogaatvõti 6750
PARAMETER_CODE varchar(30) Parameetri kood 'parallel_process_count'
PARAMETER_VALUE varchar(255) Parameetri väärtus '2'
86
ROW_COUNTS SKAIS2
Kirjete arvu võrdlustabel
Välja nimi Välja tüüp Selgitus Andmete näited
DS_CODE varchar(32) Andmeallika/lähtesüsteemi kood 'SKAIS2'
DWH_SCHEMA_NAME varchar(128) Andmelao skeemi nimi 'SKAIS2'
DWH_TABLE_NAME varchar(128) Andmelao tabeli nimi 'ISIK'
SOURCE_COUNT int Kirjete arv lähtesüsteemis 100
DWH_COUNT int Kehtivate kirjete arv vastavas andmelao tabelis 100
STATUS_CODE varchar(32) Kirjete arvu võrdluse staatus SUCCESS
SUCCESS - kirjete arv on võrdne
WARNING - kirjete arv on erinev
STATUS_DESC varchar(255) Kirjete arvu täpsem kirjeldus. Võimalikud väärtused correct
correct
dwh has less than source
dwh has more than source
EVENT_DT timestamp Kirjete võrdluse teostamise aeg '2021-04-17 03:18:05.469
87
SCHEMAS SKAIS2
Lähtesüsteemi skeemid
Välja nimi Välja Selgitus Andmete näited
tüüp
SHEMA_VERSION_ID int Skeemi versiooni ID 1
DATA_SOURCE_CODE varchar(32) Andmeallika/lähtesüsteemi kood. Viide tabelile DATA_SOURCES 'SKAIS2'
SOURCE_SCHEMA_NA varchar Skeemi nimi lähtesüsteemis 'SKAIS2'
ME (128)
DWH_SCHEMA_NAME varchar(32) Skeemi nimi andmelaos 'DW_SKAIS2'
STATUS varchar(20) Skeemi andmete laadimise staatus 'LOAD'
IS_ACTIVE int Kas skeemi andmete laadimine on aktiivne (võimaldab terve skeemi andmete laadimise lihtsamalt välja 1
lülitada)
Hetkel ei kasutata
IS_VALID int Kas tegemist on kehtiva kirje/versiooniga (0/1) 1
VALID_FROM timestamp Kirje/versiooni kehtivuse algusaeg '2019-06-16 20:36:
01'
VALID_TO timestamp Kirje/versiooni kehtivuse lõppaeg '2019-06-16 20:36:
01'
MODIFIED_BY varchar(32) Versiooni lisaja/muutja 'pentaho'
88
TABLES SKAIS2
Tabelite andmed.
Välja Välja Selgitus Andmete näited
nimi tüüp
TABLE_VE int Surrogaatvõti 411
RSION_ID
DATA_SO varchar Andmeallika/lähtesüsteemi kood 'SKAIS2'
URCE_CO (32)
DE
SOURCE_ varchar Skeemi nimi lähtesüsteemis 'SKAIS2'
SCHEMA_ (128)
NAME
SOURCE_ varchar Tabeli nimi lähtesüsteemis 'AD_AADRESS'
TABLE_NA (128)
ME
DWH_SCH varchar Skeemi nimi andmelaos 'DW_SKAIS2'
EMA_NAME (32)
DWH_TAB varchar Tabeli nimi andmelaos 'AD_AADRESS'
LE_NAME (128)
TABLE_TY varchar Tabeli tüüp (TABLE, VIEW, MVIEW) 'TABLE'
PE (20)
SOURCE_ varchar Tabeli kirjeldus lähtesüsteemis 'Kommentaar'
TABLE_C (4000)
OMMENT
DWH_TAB varchar Tabeli kirjeldus andmelaos 'Kommentaar'
LE_COMM (4000)
ENT
LOAD_ST varchar Laadimise staatus 'LOAD' - Tabeli laadimine on sisse lülitatud
ATUS (20)
'NEW_LOAD' - Tegemist on uue andmetabeliga (st haldur pole tabeli laadimise staatust üle
vaadanud/kinnitanud), tabel on laadimisse sisse lülitatud
'NEW_NOT_LOAD' - Tegemist on uue andmetabeliga, tabel ei ole laadimisse sisse lülitatud
'NOT_LOAD' - tabeli laadimine ei ole sisse lülitatud
'NO_OBJECT' - tabelit ei ole enam lähtesüsteemis (varem oli)
LOAD_ME varchar Andmete laadimise meetod 'LOAD_MODIFIED' - laaditakse pärast viimast õnnestunud andmete laadimist lisatud
THOD (20) /muudetud andmed
'REWRITE' - andmed kirjutatakse üle (st muudatuste ajalugu ei säilitata)
'LOAD_MODIFIED_WOID' - laaditakse pärast viimast õnnestunud andmete laadimist lisatud
andmed, tabelil puudub võtmeväli st uued andmed lisatakse, kirjete muutmist ei arvestata
(vanade versioonide kehtetuks tunnistamist ei ole).
MODIFIED varchar Filtritingimus, mida kasutatakse muudetud ja/või '(case when MUUTM_AEG < DATE '1900-01-01' then DATE '1900-01-01' else
_FILTER (255) lisatud andmete tuvastamiseks MUUTM_AEG end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')'
(LOAD_MODIFIED) laadimismeetodi korra.
LAST_LOA varchar Avaldis, mis tuvastab mis aja seisuga andmed 'timestampadd('hour',-1, max(MUUTM_AEG))'
D_EXPRE (255) on laaditud
SSION
DWH_TAB varchar Tabeli staatus andmelaos 'NEEDS_CREATION' - tabel vajab loomist
LE_STATUS (30)
'NEEDS_MODIFICATION - tabel vajab muutmist
'READY' - tabel on loodud/muudetud
LAST_LOA timesta Viimase õnnestunud andmete laadimise '2019-06-18 14:00:38'
D_DT mp kuupäev ja kellaaeg
IS_VALID int Kas tegemist on kehtiva kirje/versiooniga (0/1) 0
VALID_FR timesta Kirje/versiooni kehtivuse algusaeg '2019-06-16 20:36:15'
OM mp
VALID_TO timesta Kirje/versiooni kehtivuse lõppaeg '2019-07-08 16:30:17'
mp
MODIFIED varchar Versiooni lisaja/muutja 'pentaho'
_BY (32)
89
IS_DM_TA int Kas tegemist on andmelettide arvutamisel Kui mõne andmelettide laadimises kasutatava tabeli laadimisel tekib viga, siis andmelettide
BLE kasutatava andmetabeliga. 0/1 tunnus. laadimise osa ei käivitata.
IS_ROW_ int Kas tabeli laadimisel võrreldakse andmelattu 1
COUNT jõudnud kirjete arvu ja lähteallikas olevat kirjete
arvu. 0/1 tunnus
PRIORITY int Andmetabeli laadimise prioriteetsus. Väiksema 10, 100
väärtusega andmetabelid laaditakse enne.
90
Skeemid Skais2
Skeemi nimi Kirjeldus Staatus
ADM_SKAIS2 Admin skeem - laadimiste sätted
ADM_SKAIS2_V2 Vana, pole kasutuses
DW_SKAIS2_DMART Skais2 Andmeletid
DW_SKAIS2_ODS SKAIS2 ODS
DW_SKAIS2_STG SKAIS2 STG
DW_SKAIS2_VALINE_ODS SKAIS2 VALINE ODS
DW_SKAIS2_VALINE_STG SKAIS2 VALINE STG
DW_SKAIS_BENEFIT_ODS SKAIS BENEFIT ODS
DW_SKAIS_BENEFIT_STG SKAIS BENEFIT STG
DW_SKAIS_CLIENT_INQUIRY_ODS SKAIS CLIENT INQUIRY ODS
DW_SKAIS_CLIENT_INQUIRY_STG SKAIS CLIENT INQUIRY STG
DW_SKAIS_DISABILITY_APPLICATION_ODS SKAIS DISABILITY APPLICATION ODS
DW_SKAIS_DISABILITY_APPLICATION_STG SKAIS DISABILITY APPLICATION STG
DW_SKAIS_DISABILITY_QUESTION_ODS SKAIS DISABILITY QUESTION ODS
DW_SKAIS_DISABILITY_QUESTION_STG SKAIS DISABILITY QUESTION STG
DW_SKAIS_DOCTOR_ASSESSMENT_ODS SKAIS DOCTOR ASSESSMENT ODS
DW_SKAIS_DOCTOR_ASSESSMENT_STG SKAIS DOCTOR ASSESSMENT STG
DW_SKAIS_DOCUMENT_MANAGEMENT_ODS SKAIS DOCUMENT MANAGEMENT ODS
DW_SKAIS_DOCUMENT_MANAGEMENT_STG SKAIS DOCUMENT MANAGEMENT STG
DW_SKAIS_FINANCE_ODS SKAIS FINANCE ODS
DW_SKAIS_FINANCE_STG SKAIS FINANCE STG
DW_SKAIS_FIN_FACADE_ODS SKAIS FIN FACADE ODS
DW_SKAIS_FIN_FACADE_STG SKAIS FIN FACADE STG
DW_SKAIS_ISIK_ODS SKAIS ISIK ODS
DW_SKAIS_ISIK_STG SKAIS ISIK STG
DW_SKAIS_NOTIFICATION_ODS SKAIS NOTIFICATION ODS
DW_SKAIS_NOTIFICATION_STG SKAIS NOTIFICATION STG
DW_SKAIS_PAKKUMUS_ODS SKAIS PAKKUMUS ODS
DW_SKAIS_PAKKUMUS_STG SKAIS PAKKUMUS STG
DW_SKAIS_PARENTAL_BENEFIT_ODS SKAIS PARENTAL BENEFIT ODS
DW_SKAIS_PARENTAL_BENEFIT_STG SKAIS PARENTAL BENEFIT STG
DW_SKAIS_PENSION_SENIORITY_ODS SKAIS PENSION SENIORITY ODS
DW_SKAIS_PENSION_SENIORITY_STG SKAIS PENSION SENIORITY STG
DW_SKAIS_PEREHYVITIS_ODS SKAIS PEREHYVITIS ODS
DW_SKAIS_PEREHYVITIS_STG SKAIS PEREHYVITIS STG
DW_SKAIS_PROCEEDING_ODS SKAIS PROCEEDING ODS
DW_SKAIS_PROCEEDING_STG SKAIS PROCEEDING STG
DW_SKAIS_RFK_CLASSIFIER_ODS SKAIS RFK CLASSIFIER ODS
91
DW_SKAIS_RFK_CLASSIFIER_STG SKAIS RFK CLASSIFIER STG
DW_SKAIS_RINAFACADE_ODS SKAIS RINAFACADE ODS
DW_SKAIS_RINAFACADE_STG SKAIS RINAFACADE STG
DW_SKAIS_TAX_DECLARATION_ODS SKAIS TAX DECLARATION ODS
DW_SKAIS_TAX_DECLARATION_STG SKAIS TAX DECLARATION STG
DW_SKAIS_TECHNICALAIDXROAD_ODS SKAIS TECHNICALAIDXROAD ODS
DW_SKAIS_TECHNICALAIDXROAD_STG SKAIS TECHNICALAIDXROAD STG
DW_SKAIS_TECHNICALAID_ODS SKAIS TECHNICALAID ODS
DW_SKAIS_TECHNICALAID_STG SKAIS TECHNICALAID STG
92