Leping

Dokumendiregister	Tervise- ja heaolu infosüsteemide keskus
Viit	3-9/4512-6
Registreeritud	08.04.2026
Sünkroonitud	13.04.2026
Liik	Riigihankeleping
Funktsioon	3 Finantsarvestus ja asutuse varade haldus
Sari	3-9 Riigihankelepingud
Toimik	3-9/2025
Juurdepääsupiirang	Avalik
Juurdepääsupiirang
Adressaat
Saabumis/saatmisviis
Vastutaja	Sten Martmaa (TEHIK, Äriteenuste osakond, Analüütika lahenduste valdkond)
Originaal	Ava uues aknas

Dokument on kokkuvõtte tegemiseks liiga mahukas (376518 tm).

Failid

Hankeleping_306284.asice

Hankeleping_306284.pdf

Lisa 1 - Tehniline kirjeldus 08022026.pdf

Lisa 11 - TEHIK mittefunktsionaalsed nouded arendustele 19082025.pdf

Lisa 12 - Andmeladude olemus ja funktsioon juhis 14042023.pdf

Lisa 13 - IT-Profiil v3 veebidoc.pdf

Lisa 14 - SKANDL-220126-1743-1550.pdf

Lisa 2 - Kodukord.pdf

Lisa 4 - Toode uleandmise ja vastuvotmise akt.pdf

Lisa 5 - Isikuandmete tootlemise tingimused (solmitakse vastavalt vajadusele toode teostamise ajal).pdf

Hankeleping_306284.pdf

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 08022026.pdf

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 11 - TEHIK mittefunktsionaalsed nouded arendustele 19082025.pdf

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 nr

Nõude sisu Seletused Digiriigi CFR

Iseteenindus Veebid Karbitoode Koostamise eest vastutaja

Testimise läbi viib või kinnitab

1. Vastavus üldistele standarditele

1.1 Lahendus loomisel peab arvestama digiriigi ristfunktsionaalsed nõudeid.

Kohustus- ja ootustasemel olevad nõuded tuleb rakendada.

https://koodivaramu.eesti.ee/e-gov/cfr

Erisused tuleb kokku leppida Tellija lahenduse arhitektiga.

V V Arendaja Projektijuht

Arhitekt

Administraator

Testija

Turvatestija

Infoturbe spetsialist

Standardija

1.2 Lahenduse X-tee teenused peavad vastama nõuetele.

https://X-tee.ee/docs/live/xroad/ V V V Arendaja Testija

1.3 Lahendus peab vastama Sotsiaalministeeriumi IT-profiilile.

Tulevase ja olemasolevate infosüsteemide platvormid (rakendusserver, andmebaas, kolmanda osapoole komponendid) ja topoloogia peavad olema loodud kooskõlas hankes viidatud IT-Profiil versioonile.

V V V Arendaja Projektijuht

Arhitekt

Administraator

Testija

Turvatestija

Infoturbe spetsialist

Standardija

1.4 Lahenduse kasutajaliides peab vastama dokumendis "Front-end arendusreeglid" kirjeldatud reeglitele.

https://tehik.ee/arendusjuhendid V V Arendaja Arhitekt

Testija

1.5 Rakendus peab olema kirjutatud arvestades selle lahenduse äriprotsesside ja andmete E-ITS ja ISKE turvaklassi nõudeid.

https://eits.ria.ee/ V V V Arendaja Turvatestija

Arhitekt

1.6 Veebirakenduse kasutajaliides peab vastama vähemalt WCAG 2.2 tasemele AA.

https://www.w3.org/TR/WCAG22/

CFR selgitus: WCAG 2.2 alates 05.10.2023

#39 V V V Arendaja Testija

1.7 Veebipõhine kasutajaliides peab ühilduma täielikult standarditega HTML 5 ja CSS 3.

Valideerimiseks kasutatakse vastavaid validaatoreid:

https://validator.w3.org/

Kui on tegu olemasoleva süsteemi edasiarendusega, siis tuleb järgida olemas olevat HTML ja CSS versiooni.

#38 V V Arendaja Testija

1.8 Allkirjastamisel tuleb kasutada Tellija SiGA/SiVa vahendusteenust.

https://www.tehik.ee/arendusjuhendid V V Arendaja Testija

Arhitekt

1.9 Rakendus peab probleemideta läbima OWASP ASVS baasil põhineva testi.

Kui pole arenduses eraldi kokku lepitud teisiti, siis on OWASP ASVS tasemeks 2 (https://owasp.org/www- 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.

#10

V V V Arendaja Turvatestija

1.10 Krüptoalgoritmite ja räsifunktsioonide kasutamisel tuleb kasutada turvalisi algoritme ja võtmepikkuseid.

Krüptoalgoritmite ja räsifunktsioonide kasutamisel tuleb järgida uusimat RIA kodulehel avaldatud krüptograafiliste algoritmide kasutusvaldkondade ja elutsükli uuringut.

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.

#46 V V V Arendaja Arhitekt

Administraator

Turvatestija

1.11 Andmete edastus peab olema kaitstud kasutades krüpteeritud ning vajadusel autenditud ja autoriseeritud kanalit.

Autentimist ei ole vaja ainult avalike andmete edastamisel (nt avaandmed).

V V V Arendaja Turvatestija

Arhitekt

Autentimise mehhanism tuleb kokku leppida Tellijapoolse arhitektiga.

1.12 Infosüsteem peab kasutama serveri kellaaega.

Kõik mahakirjutatavad ja talletatavad kellaajad tuleb salvestada UTC ajatsoonis koos ajatsooni infoga.

Kasutajatele mõeldud kuvades tuleb kasutada sirviku ajatsooni. Aja esitamisel tekstikujul lähtuda standardist ISO 8601.

#51 V V V Arendaja Arhitekt

Administraator

1.13 Süsteemi edasiarendamisel/loomisel peab arvestama selle võimaliku laiendamisega nii andmemahtude kui ka kasutajate arvu osas.

Süsteemi jõudlus peab vastama kokkulepitud topoloogial eelanalüüsi ja lähteülesande käigus välja toodud jõudlusnäitajatele.

V V V Arendaja Arhitekt

Testija

1.14 Rakendus peab olema tehniliselt tükeldatud vastavalt loogilisele jaotusele. Saadud osised peavad olema eraldi versioneeritavad ja paigaldatavad.

Lahenduse arhitektuuris kasutada domeenist juhitud disaini ja mikroteenuste põhimõtteid.

Näiteks kui rakendus on eraldi turvakontekstidega 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/

#21 V V Arendaja Arhitekt

1.15 Avalike e-teenuste loomisel peab arvestama valitsusasutusele kehtestatud visuaalse identiteedi stiilijuhiseid.

https://riigikantselei.ee/valitsuslogo #36 V V V Arendaja Testija

1.16 Avalike e-teenuste loomisel peab arvestama Veera disainisüsteemiga.

https://veera.eesti.ee/

Näiteks kasutada ja laiendada E-Gov CVI projekti komponente:

https://e-gov.github.io/cvi/

#36 V V Arendaja Arhitekt

1.17 Lahenduse loomisel peab arvestama riiklikku koostoimeraamistikuga.

https://digiriik.eesti.ee/koostoimeraamistik/ V V V Arendaja Arhitekt

Administraator

1.18 Aadressiandmete sisestamisel, kuvamisel ja hoidmisel tuleb lähtuda Vabariigi Valitsuse määrusest "Aadressiandmete süsteem".

Liidestatakse Maa-ameti ADS teenusega.

Esitluskihis on lubatud liidestada In-ADS teenusega otsingu tarvis. Taustsüsteemides toimub liidestamine X-tee teenusega.

https://www.riigiteataja.ee/akt/115072023005? leiaKehtiv

#53 V V Arendaja Arhitekt

Standardija

Testija

1.19 Tegevusalade andmete sisestamisel, kuvamisel ja hoidmisel tuleb lähtuda Vabariigi Valitsuse 10. jaanuari 2008. a määrusest nr 11 "Klassifikaatorite süsteem" ja kasutada EMTAK infosüsteemis kehtivat klassifikaatorit.

https://www.riigiteataja.ee/akt/12910889?leiaKehtiv

https://emtak.rik.ee/EMTAK/

#54 V V Arendaja Standardija

Testija

2. Nõuded rakenduse arhitektuurile

2.1 Rakenduse, andmebaasi ja kolmanda osapoole komponendid peavad olema sellised, mille turbe uuenduste eluea lõpp (Security Support) pole teadaolevalt vähem kui 2 aasta pärast.

Arendaja loodud lahenduse dokumentatsioonis (nt analüüs vms) peab olema välja toodud kasutatavate komponentide nimetused ja versioonid. Lubatud on kasutada ka tarkvara materjalide loendit (SBOM). 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.

#7 V V V Arendaja Arhitekt

2.2 Rakendusserver peab võimaldama töötamist andmebaasiserverist eraldi serveril.

V V V Arendaja Administraator

2.3 Rakendusserver peab olema kõrgkäideldav ja horisontaalselt skaleeruv.

Kasutaja sessioonid ei tohi olla rakenduserveri klastri õla põhised.

V V V Arendaja Administraator

2.4 Rakendust peab saama ilma ümberprogrammeerimata liigutada erinevate domeenide ja domeeni saitide vahel.

Lahenduses ei tohi olla sisse kompileeritud absoluutseid URI-sid.

V V V Arendaja Administraator

2.5 Rakenduse komponentide konfiguratsiooni peab olema võimalik ette anda käivitamisel. Konfiguratsiooni muudatus peab olema teostatav ilma rakendust kompileerimata.

Rakendus peab neid sealt ka kasutama (mitte kopeerima parameetreid käivitamisel kolmandatesse kohtadesse), logimise seaded võivad olla rakenduse konfiguratsioonifailist eraldi ühes 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.

V V V Arendaja Administraator

Testija

Näiteks konteinerlahenduste puhul peab kasutama keskkonnamuutuja põhiseid konfiguratsiooni parameetreid.

2.6 Rakenduse taaskäivitus, konfiguratsiooni muutmine vms peab toimuma mõistliku aja jooksul.

Tavaline käivitusaeg ei tohi ületada 30 sekundit.

Kui rakendus vajab indekseeritud sisu ja see pole kättesaadav, siis peab rakendus väljastama selle kohta selge teate.

V V V Arendaja Testija

2.7 Lahenduse väliste osapoolte komponentide konfiguratsioonid peavad olema puhverdatud.

Kui rakendusel või mõnel selle komponendil on tihti kasutatav teenus ning sellel teenusel on laetav konfiguratsioon, siis tuleb:

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

V V Arendaja Arhitekt

Testija

Administraator

2.8 Kõik andmed, andmebaasid, SQL skriptid, lähtekood ja rakendus peavad kasutama UTF-8 või UTF-16 kodeeringut.

#50 V V V Arendaja Administraator

Testija

2.9 Rakendusserveri failisüsteemi ei tohi salvestada midagi püsivaks kasutamiseks.

Näiteks objektide talletuseks kasutada objektide talletamise lahendust (nt MinIO).

V V Arendaja Administraator

2.10 Ühest relatsioonilise andmebaasi andmetabelist teise viitamisel tuleb kasutada väliseid võtmeid (Foreign key).

Erinevate skeemide vahelised ühendused on keelatud. Peab kasutama REST/SOAP/AMQP liidestust.

V V Arendaja Arhitekt

2.11 Kõik välised võtmed (Foreign Key) peavad olema indekseeritud.

Andmebaasis peab kasutama indekseid ja/või muid meetmeid, et nõuded rakenduse jõudlusele oleksid täidetud ka tulevikus. (ühe, kolme, viie või 10 aasta pärast – vastavalt planeeritud kasutusajale).

V V Arendaja Arhitekt

2.12 Tuleb kasutada päringumuutujaid (Parameter Binding).

SQL päringute väljakutsumisel väljastpoolt 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).

V V Arendaja Arhitekt

2.13 Kõigis andmebaasi tabelites peab olema defineeritud üks primaarvõti

Kasutada tuleb vastava andmebaasisüsteemi nimetamise parimaid praktikaid.

V V Arendaja Arhitekt

2.14 Andmebaasi objektide nimetused peavad olema sisulised ja andma aimu nende otstarbest.

Kasutada tuleb vastava andmebaasisüsteemi nimetamise parimaid praktikaid.

V V Arendaja Arhitekt

2.15 Andmebaasis defineeritakse üldjuhul kaks või enam kasutajat:

Rakenduse peakasutaja, kellena luuakse objektid ja skeemid. Rakenduse piiratud õigustega kasutaja, kellena pöördub rakendusserver/rakendus.

Objektide loomiseks vajalikud õigused ja ressursid on loetletud rakenduse dokumentatsioonis.

Need õigused, mis on vajalikud ainult rakenduse baasi loomiseks, on eraldi välja toodud ja tuleb peale installeerimist ära võtta. Karbitoodete puhul tuleb erisused läbi arutada Tellija arhitektiga.

Lahenduse puhul, milles kasutatakse andmebaasi versiooneerimist, tuleb kasutada mitut andmebaasi ühendust. Ennem rakenduse käivitumist teostatakse andmebaasi skeemi muudatused eraldi kasutajaga. Rakendus kasutab enda põhitööks kasutajat, kellel puudub õigus andmebaasi skeemis muudatusi teostada.

V V Arendaja Administraator

2.16 Failide hoidmise asukoht lepitakse iga kord kokku, kuid failid ja failide indeks peavad olema replikeeritavad teise asukohta.

Failide hoidmine klassikalises andmebaasis on kulukas ja seab kõrgendatud nõudmised ja piirangud andmebaasiserveritele. Lahenduse dokumentatsioonis tuleb ära tuua failide hoidmise asukoht.

Näiteks objektide talletuseks kasutada objektide talletamise lahendust.

V V Arendaja Arhitekt

2.17 Peab olema miinimumini viidud vajadus, et haldur teeb haldustoiminguid otse baasis. St rakendusel peab olema haldusliides, mille kaudu rakenduse haldur saab teha tavapäraseid haldustoiminguid.

Halduri haldustoimingud lepitakse Tellijaga kokku detailanalüüsi käigus.

V V V Arendaja Testija

2.18 Andmebaas peab toetama nii külm- kui ka kuumvaru (peegeldamist) teise asukohta.

Ei tohi kasutada teenuseid, mis välistavad andmebaasi peegeldamist (nt "MSSQL filestream").

V V Arendaja Arhitekt

2.19 Sorteerimisreeglistik peab olema Eesti tähestikule vastav. Tõusutundlikkus peab olema välja lülitatud. Diakriitiline (Accent) peab olema sisse lülitatud.

Näiteks PostgreSQL puhul et_EE. V V V Arendaja Testija

2.20 Kui infosüsteemid saadavad e-kirju, peavad nad kasutama välist e-maili serverit. Kirja saatmisel peab rakendus veenduma, et e-posti server võttis kirja vastu. E-kirjade vormindamine peab järgima interneti standardeid (RFC 5322).

Saatja ja adressaadid, pealkiri ja sisu ei tohi olla rakendusse kodeeritud, vaid on muudetavad konfiguratsioonifaili kaudu.

Genereeritud kirjade puhul peab tagama kirjade jälitatavuse (näiteks lisada X-päise kodeeritud kirje, milles on kirjeldatud, mis protsess/skriptifail/kasutaja kirja genereeris jms abistav info).

V V V Arendaja Administraator

2.21 Konfiguratsiooniparameetrite nimed peavad olema sisulised. Kui see ei ole

Näiteks : X_TEE_TURVASERVER, mitte XTTS või viitenumber, mitte vk_seb jne

V V Arendaja Administraator

võimalik, siis peab kõrval olema seletus. Testija

2.22 Infosüsteemides on eessüsteemid (front end; presentatsiooni kiht) ja tagasüsteemid (back end; äriloogika kiht) arhitektuuriliselt selgelt lahutatud ja eraldi paigaldatavad.

Rakenduse äriloogika tuleb realiseerida andmebaasist eraldi sõltumatus rakenduskihis.

Koostöövõime raamistik 2011. Punkt 3.1. Tagasüsteemide ülesanneteks on andmete haldamine ja võrguteenuste pakkumine. Tagasüsteemid ei tegele lõppkasutaja autentimise ja autoriseerimisega. Lõppkasutaja autoriseerimise tagavad eessüsteemid. Välise süsteemi tõrge tohib mõjutada ainult sellest otseselt sõltuvate kasutuslugude toimimist. Välise süsteemi taastumisel peab süsteem olema suuteline oma tööd jätkama taaskäivitamata.

Andmebaas ei tohi sisaldada äriloogikat, mis muudab andmetabelites olevaid/sinna kirjutatavaid andmeid, va trigerid, mis tekitavad logi.

#23

#29

#64

V V Arendaja Arhitekt

2.23 Konfiguratsioonifailid peavad olema vastavalt rakendusserveri tüübile vaikimisi kaitstud failid/objektid.

Näiteks IIS: *.config , *.resources Apache: *.conf, .htaccess.

Arendaja peab välja tooma konfifailide listi, kui neid on mitu.

V V V Arendaja Administraator

2.24 Rakenduse failid, mida kasutaja näha ei tohi, peavad olema vaikimisi kaitstud kaustades ja ei tohi olla veebi juurkaustas.

Näiteks: IIS: Bin,App_Code, App_Data, App_Browsers, App_GlobalResources, App_LocalResources, App_Themes, App_WebReferences, .git

V V V Arendaja Administraator

2.25 Konfiguratsiooniparameetrite taaskasutus. Erinevaid sama sisuga parameetreid ei tohi konfiguratsioonis eksisteerida.

Kõiki parameetreid tuleks konfiguratsioonis kirjeldada vaid korra, dubleerimine on keelatud.

V V Arendaja Administraator

Testija

2.26 Esitluskihist ei tohi pöörduda otse andmebaasi poole.

Tuleb rakendada vähemalt 3 tasandilist arhitektuuri (three-tier architecture).

Lõppkasutaja lokaalsesse seadmesse paigaldatud tarkvara loeme esitluskihiks. Ka sellisel juhul ei tohi teha lõppkasutaja seadmest otse ühendust andmebaasi.

V V V Arendaja Administraator

2.27 Keskkonnapõhised muutujad peavad olema konfiguratsiooniparameetritega seadistatavad.

Näiteks WSDL ei tohi sisaldada viiteid arendusserveritele.

V V V Arendaja Administraator

Testija

2.28 Eelistada tuleb tsentraalseid autentimislahendusi (nt Tellija SSO lahendus).

Kui rakendus realiseerib ise autentimist, siis peab olema võimalik piirata ebaõnnestunud logimisi 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

#30 V V V Arendaja Arhitekt

Testija

2.29 Relatsioonilises andmebaasis võib kasutada vaid ISO/IEC 9075 standardiga kaetud funktsionaalsusi. Lisaks ei tohi kasutada ka sama standardi osas 13 kirjeldatud funktsionaalsusi.

Ei ole soovitav kasutada mingit platvormispetsiifilist lahendust, mille üleviimine mõnele muule andmebaasiplatvormile ei ole võimalik. ISO/IEC 9075 osa 13 spetsifitseerib Javas kirjutatud programmimoodulite kasutamist andmebaasis.

V V Arendaja Arhitekt

2.30 Uniform resource identifier (URI) pikkus ei tohi ületada ühegi lahenduse poolt toetatava sirviku maksimaalset lubatud väärtust.

Harilikult on piiriks 2048 tähemärki, kuid iga lahenduse puhul tuleb seda eraldi järele uurida sõltuvalt lahenduse komponentidest. Asjakohased viited: RFC 3986 ja RFC 7239.

V V V Arendaja Administraator

Testija

2.31 Veebiteenuseid (REST, SOAP) pakkuv rakendus peab olema üles ehitatud nii, et see toetaks teenuste versiooneerimist URL-i ja/või skeemi tasemel.

Näiteks WSDL puhul: Alajaotis definitions/types/schema:

complexType defineerimisel tuleb sellele lisada any element.

V V V Arendaja Arhitekt

2.32 Rakendus peab olema võimeline töötama koormusjaoturitega varustatud taristul.

Koormusjaoturi peal kasutatakse järjestikplaanurit (Round Robin) päringute suunamisel. Samuti võidakse teostada koormusjaoturil TLS ühenduse lahtivõtmist ja uuesti kokkupanemist (SSL offload).

V V V Arendaja Administraator

2.33 Sidusinfosüsteemide mittekättesaadavus ei tohi segada rakenduse töötamist. Sidusinfosüsteemidega andmevahetamisel tekkinud vead logitakse ja kasutajat hoiatatakse.

Sidussüsteemi tõrge tohib mõjutada ainult sellest otseselt sõltuvate kasutuslugude toimimist. Sidussüsteemi taastumisel peab süsteem olema suuteline oma tööd jätkama rakendust taaskäivitamata.

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.

V V V Arendaja Administraator

Testija

2.34 Automaatselt käivituvaid taustatöid peab saama käsitsi (taas)käivitada.

Vajalik juhul, kui automaatsel käivitumisel on 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).

V V V Arendaja Testija

2.35 Kui ajastatult käivitatav taustatöö ei ole mõeldud käima paralleelselt, peab selles olema realiseeritud kontrollmehhanism, mis tagab, et sama taustatööd ei ole

Kui lahendus töötab mitmel õlal, ei tohi tööd, mis ei ole mõeldud paralleelselt käima, käivituda korraga mitmel õlal. Peab rakendama lukustus põhimõtet.

V V Arendaja Administraator

Testija

võimalik käivitada uuesti enne, kui eelmisena käivitatud instants on oma töö lõpetanud.

2.36 Uue toote arenduse ja olemasolevate infosüsteemide versiooniuuendustel kasutusele võetavate tehnoloogiate ja standardite valik tuleb kooskõlastada Tellijapoolse arhitektiga.

V V V Arendaja Arhitekt

2.37 Rakenduse ühenduste (s.h. andmebaasi ja sidusinfosüsteemide ühendused) realiseerimisel tuleb kasutada ühenduste puulimist (connection pooling).

Implementeeritud peab olema vähemalt maksimaalsete ühenduste arvu piirang, päringu aegumise aeg (request timeout) ja ühenduse elususe 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.

V V V Arendaja Arhitekt

2.38 Rakenduse uuendustega kaasnevad andmebaasi muudatused tuleb automatiseerida ja versioneerida.

Näiteks Liquibase või Flyway. V V Arendaja Administraator

2.39 Mitterelatsioonilises mudelis andmete hoiustamine tuleb eraldi kokkuleppida.

Näiteks kui soovitakse kasutada NoSQL lahendusi püsivaks andmete talletuseks, tuleb see kokku leppida Tellijapoolse arhitektiga.

V V V Arendaja Arhitekt

2.40 Mikroteenuste arhitektuuris vältida ebavajalikku andmete dubleerimist.

Iga teenus vastutab enda valdkonna andmete eest. Kui on vajadus lisaandmete jaoks, on tal võimalik pöörduda teise teenuse poole.

V Arendaja Arhitekt

2.41 Infosüsteemide vaheline andmevahetus toimub üle X-tee.

https://www.ria.ee/riigi-infosusteem/andmevahetuse- 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.

#22 V V V Arendaja Arhitekt

3. Turvalisuse tagamisega seotud nõuded

3.1 Asutusesiseseks kasutamiseks mõeldud rakenduse kasutajate autoriseerimist peab saama teha vastu TEHIKu keskset autoriseerimisteenust.

TEHIKu haldusala kasutajad ja nende rollid on kirjeldatud Active Directory's. Võimalik on kasutada rollide pärimiseks TEHIK SSO teenust.

Täpsem tehniline lahendus leida koos TEHIKu poolse arhitektiga.

V V V Arendaja Turvatestija

3.2 Kliendi ja serveri vahel peab autenditud kasutajasessioonide korral olema sessioon krüpteeritud HTTPS-protokolli kasutades.

V V V Arendaja Turvatestija

3.3 Rakendus tohib kasutada vaid sessiooni küpsiseid (cookies). Muude küpsiste kasutamine tuleb kokku leppida Tellijapoolse arhitektiga.

V V Arendaja Turvatestija

3.4 Kui andmebaasis olevate andmete E-ITS tervikluse (I ehk integrity) turvaosaklass on S või VS, siis tuleb kõik andmebaasi kirjed/tabelid versioneerida.

St kõik andmemuudatused peavad baasis säilima. Andmete muutmisel andmeid ei kustutata, vaid tehakse uus kirje uute andmetega. Vana muudetakse 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.

#55

#49

V V Arendaja Turvatestija

Arhitekt

3.5 Rakendusega peab kaasas olema lahendus, mis suudab toota toodangu andmetest testandmed, mis ei võimalda siduda konfidentsiaalset informatsiooni päris andmesubjektiga.

Testandmed peavad säilitama kõik toodangu andmete omadused (pikkuse, tüübi) ja omavahelised suhted.

Täpsem vajadus ja tegevusplaan tuleb koostada Tellija arhitekti ja tooteomanikuga.

V Arendaja Arhitekt

3.6 Rakendus ja selle komponendid peavad võimaldama kasutada keskkondade lahusust.

Arendaja arendab arenduskeskkonnas ja annab tarne üle Tellijale paigalduspakkidena. Tellija paigaldab 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.

V V V Arendaja Turvatestija

3.7 Rakendusse ja andmetele tohib olla ligipääs vaid dokumenteeritud ja tellimuses kirjeldatud teid mööda ning dokumenteeritud autentimisprotseduure kasutades.

St rakendustes ega andmebaasides ei tohi olla ligipääsemiseks teisi võimalusi.

V V V Arendaja Turvatestija

3.8 Rakendus ei tohi teostada X-tee päringut otse kasutajaarvutist.

Kasutajaarvutitest otse X-tee päringute tegemine on arvutivõrgu tasemel kinni.

V V V Arendaja Turvatestija

3.9 Veebipõhised välise veebilehega rakendused peavad kasutama vahendeid,

IIS puhul peab kasutama näiteks URL scan, apache puhul modsecurity või vastavat tööriista. Lubamatud

V V V Administraator Turvatestija

kaitsmaks rakendust lubamatute päringute eest.

päringud on kõik päringud, mis ei ole detailanalüüsi käigus vastavalt kasutusjuhtudele ette nähtud. Blacklistingu asemel tuleb kasutada whitelisting põhimõtet.

3.10 Kasutaja peab saama soovi korral veenduda, kas keegi pole tema nime all vahepeal sisse loginud.

Rakendus peab sisenemisel näitama pärast õnnestunud sisselogimist eelmise õnnestunud sisselogimise aega. 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.

V V V Arendaja Turvatestija

3.11 Kõigil rakendustel peab olema konfigureeritav kasutajasessiooni aegumise aeg.

Aeg peab olema muudetav koos teiste konfiguratsiooniparameetritega.

Nõue kehtib juhul, kui kasutatakse lahenduse sisest sessiooni haldust.

V V V Arendaja Turvatestija

3.12 Lahenduses kasutatavate küpsiste sisu peab olema krüpteeritud

Eesmärk on kaitsta kasutaja andmeid, mis on talletatud sirviku küpsiste hulka.

V V Arendaja Turvatestija

3.13 LDAP lahenduse (nt Active Directory) kasutamisel peab rakendus kasutama kontoga kaasnevaid piiranguparameetreid.

Näiteks: konto on lukus, parool aegunud, konto aegunud, paroolipoliitika jne.

#30 V V V Arendaja Turvatestija

3.14 Tagada tuleb rakenduse rollide lahusus. Peakasutajal ja tavakasutajal on erinevad tööülesanded. Rollide/õiguste kirjeldus peab lähtuma detailanalüüsist ja kasutusjuhtudest.

V V V Arendaja Turvatestija

3.15 Arendus peab olema orienteeritud toodangukeskkonnas toimimiseks.

Toodangukeskkonnas mittevajalikud 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)

V V V Arendaja Turvatestija

3.16 Kui rakenduse tervikluse turvaosaklass on T3, peavad tõestusväärtust omavad andmed olema kas ajatembeldatud, digiallkirjastatud või digitembeldatud ning krüptoaheldatud.

See tagab, et tõestusväärtusega andmeid ei saaks märkamatult kustutada.

Konkreetne lahendus tuleb kokku leppida Tellija arhitektiga.

V V V Arendaja Turvatestija

3.17 Kui rakenduses on S3 salastatuse astmega andmeid, peavad need olema nii transpordi ajal ja ka salvestatult alati krüpteeritult.

Konkreetne lahendus tuleb kokku leppida Tellija arhitektiga.

V V V Arendaja Turvatestija

3.18 Rakendus peab võimaldama hõlpsalt välja vahetada aegunud ja ebaturvalise krüptoalgoritmi.

Krüptograafiat kasutav rakenduskood ei tohi nimeliselt välja kutsuda krüptograafilisi algoritme, 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.

V V V Arendaja Turvatestija

3.19 Rakenduse andmebaasi krüpteerimisega seotud andmeväljad peavad olema muudetava pikkusega.

Andmebaasides kasutatavad krüpteerimisfunktsioonidest tingitud lisaväljad peaksid olema muudetava pikkusega, et formaati muutmata saaks kasutada teistsuguste parameetritega krüpteerimisalgoritme.

V V V Arendaja Turvatestija

3.20 Lahendus peab olema kaitstud HTMLi süstimiste eest.

OWASP soovitab kasutada DOMPurify lahendust HTMLi saneerimiseks

#44 V V V Arendaja Arhitekt Turvatestija

4. Logimine

4.1 Logimiseks tuleb kasutada standardseid komponente kogu logiahela ulatuses.

Näiteks Java raamistikku log4j, SLF4J, logback; transpordiks syslog, Elastic Beats; logi formaadiks JSON. Logi peab olema loetaval tekstilisel kujul, et logikirjeid saaks töödelda masinmõistetavalt ja inimloetavalt.

V V V Arendaja Arhitekt

Administrator

4.2 Peab kasutama logikomponenti ja peab olema võimalik juhtida logikomponendi seadistusi.

Seletus: Näiteks peab saama muuta logimise taset ja logimise formaati.

V V V Arendaja Arhitekt

Administraator

Testija

4.3 Logisündmused peavad olema loogiliselt eristatavad.

Auditlogi (Seansilogi, tegevuslogi) - info sisselogimiste, väljalogimiste ja seansi aegumiste 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

#41 V V V Arendaja Arhitekt

Administraator

4.4 Logimine peab olema optimeeritud. Informatsiooni dubleerimist logides tuleb vältida, kui ei ole nõutud teisiti.

V V V Arendaja Arhitekt

Testija

4.5 Logides peab olema maksimaalselt üks sündmus ühel real.

V V Arendaja Administraator

Testija

4.6 Logikirje peab olema JSON formaadis. V V Arendaja Arhitekt Testija

4.7 Logiväljade nimed peavad olema normaliseeritud ja tuleb rakendada Elastic Common Schema spetsifikatsiooni.

Samatüübilised logiväljade nimed peavad olema ühtsed üle logi.

https://www.elastic.co/guide/en/ecs/current/ecs- reference.html

V V Arendaja Arhitekt Infoturbespetsialist

4.8 Rakendus peab logima kasutaja edukat ja ebaedukat autentimist ja sessiooni lõpetamist, kasutaja IP-d ja autentimismeetodit.

Logima peab ka autentimise ebaõnnestumise koos põhjusega (vale juurdepääsumandaat, aegunud konto jne). Logida tuleks IP-aadress, meetod ja kui võimalik 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.

V V V Arendaja Arhitekt

Testija

4.9 Üle terve logi peab olema kasutaja sessiooni käigus tehtud tegevusi või sama sündmust võimalik siduda loogiliselt kokku.

Tegevuste sidumiseks peab olema võimalik logikirjeid siduda ühise välja abil. Selleks ei sobi kellaaeg, IP ega isikukood. Sobib näiteks unikaalne ID, mis ei tohi olla 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.

#17 V V V Arendaja Arhitekt

Testija

4.10 Andmete loomise/vaatamise/muutmise/kustutamise tegevused peavad olema kajastatud logides. Logida tuleb ka päringud, mille vastus on puhverdatud.

Logikirjes peab sisalduma piisavalt informatsiooni, et vastata küsimustele kes?, mida?, kus?, kust?, millal?, kuidas? ja tulemus.

Konkreetne detailsus ja tehniline lahendus tuleb kokkuleppida Tellija arhitektiga. Näiteks on mõistlik luua audit teenus, mis annab vastavale rollile võimaluse näha ja auditeerida tegevusi.

V V V Arendaja Testija

Turvatestija

Infoturbespetsialist

4.11 Administraatorite ja haldurite poolt tehtavaid andmete vaatamised, muutmised sh kustutamised (ka otse baasis) tuleb logida. Muutmise puhul tuleb logida nii uus kui ka vana väärtus.

Lahendus peab tagama, et administraatorid/haldurid ei saa andmete vaatamise, muutmise logimist ise (ka tavakasutajate logimist) deaktiveerida või logisid kustutada/muuta.

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.

V V V Arendaja

Administraator

Infoturbespetsialist

Testija

4.12 Süsteemsed logid ei tohi sisaldada otseseid isikuandmeid.

Tulenevalt GDPRist ja logi sündmuse subjekti õigustest, ei tohi logide igapäevane analüüsimine ja jälgimine riivata sündmuse subjekti õigusi.

Näiteks kasutada kasutaja nime ja tunnuse asemel tema süsteemset ID'd. Lahendus peab sisaldama võimalust ID ümberpööramist reaalseteks andmeteks. Antud tegevus peab olema auditeeritav.

Konkreetne detailsus ja tehniline lahendus tuleb kokkuleppida Tellija arhitektiga.

V V V Arendaja Arhitekt

Testija

Turvatestija

Infoturbespetsialist

4.13 Kui parameetri väärtus on tühi, tuleb see logis märkida asendusväärtusega.

Näiteks NULL V V Arendaja Testija

4.14 Logis tuleb kõik mittekuvatavad (non- printable) sümbolid kodeerida.

Näiteks reavahetused -> \n, non-printable sümbolid - 0x00..0x1f, 0x7f..0xff.

V V Arendaja Testija

4.15 Rakendus peab logima kõiki rakenduses tekkivaid tehnilisi vigu.

Logi sisaldab minimaalselt vea tekkimise aega, veakoodi, veakirjeldust (stack trace, traceback vms), võimalusel kasutaja andmeid, HTTP-, GET- ja POST- parameetreid ja nende väärtusi. Logimise detailsusrežiimi (info, warning, errog, debug) peab saama muuta.

V V V Arendaja Administraator

Testija

4.16 Rakendus ei tohi X-tee päringuid salvestada rakenduse logis. Logis peab olema X-tee tunnus (ID), et saaks siduda X-tee logiga.

V V V Arendaja Administraator

Testija

4.17 Rakenduse funktsionaalsuse kirjeldusega tuleb luua logimise dokumentatsioon ja loginäidised. Koos funktsionaalsuse arendamisega tuleb luua ka loodava funktsionaalsuse logimine ja selle dokumentatsioon. Dokumentatsioon peab sisaldama logis kasutatud klassifikaatorite kirjeldusi.

Mida logitakse, kuidas sündmused on logis jagatud, logiridade näited.

V V V Arendaja Arhitekt

Administraator

Infoturbespetsialist

5. Testimine

5.1 Rakenduse kõik üleantavad versioonid peavad enne Tellijale üle andmist olema testitud.

Testitulemused tuleb edastada Tellijale koos rakenduse üleandmisega. Vaata lisaks nõuet 5.2 ja 5.3.

Testid peavad olema käivitatavad Tellija pideva integreerimise (CI) keskkonnas (nt Gitlab) ning olema dokumenteeritud, kuidas teostada testide seadistamist ja manuaalset käivitamist.

#12 V V V Arendaja Testija

5.2 Lahendus peab olema minimaalselt 75% ulatuses kaetud automaatsete komponenditestidega (unit test).

Käivitatakse Tellija pideva integreerimise (CI) keskkonnas (nt Gitlab) ja kaetust raporteeritakse lähtekoodi analüsaatoris (nt SonarQube).

#12

#35

V Arendaja Arhitekt

Testija

5.3 Lahendus peab olema minimaalselt 50% ulatuses kaetud automaatsete

Käivitatakse Tellija pideva integreerimise (CI) keskkonnas (nt Gitlab).

#12

#33

V Arendaja Arhitekt

Testija

vastuvõtutestidega.

5.4 Rakendusega peab olema kaasas skript jõudlustestide tegemiseks.

Jõudlustestide täpne kirjeldus tuleb kokku leppida detailanalüüsi käigus. Arendaja peab koos rakendusega tarnima skripti ja vajalikud tarkvaralised vahendid kokkulepitud jõudlustestide läbiviimiseks. 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.

#12

#34

V V Arendaja Arhitekt

Administraator

Testija

5.5 Testimine toodangu andmetega on keelatud.

Testimiseks tuleb luua vastavad andmekooslused, et tagada tervik voo testimise võimekus.

V V Arendaja Arhitekt

Administraator

Testija

5.6 Enne lahenduse esmast tootesse lansseerimist peab olema teostatud turbetestid ja seal välja toodud probleemid lahendatud.

Turbe testide teostamist ja tellimist koordineerib Tellijapoolne testija esindaja. Samuti tuleb kokku leppida põhimõtted, millistel juhtudel turbe testi tuleb uuesti teostada.

Parendused ja lahendused tuleb kokku leppida Tellija arhitektiga.

#10

V V Arendaja Arhitekt

Administraator

Testija

6. Monitooring

6.1 Rakendusel peab olema masinloetav tervise testleht (health check) JSON kujul.

Testlehe kättesaadavus erinevatest arvutivõrkudest peab olema konfigureeritav. Testleht peab uuendama 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.

#16 V V Arendaja Arhitekt

Administraator

6.2 Rakendusel peavad olema elususe ja tööks valmiduse otspunktid.

Näiteks java Spring raamistiku puhul kasutada actuatori võimekust. Konteinerite orkestraatori kiht teostab nende järgi otsuseid. Antud lehekülgede sisuline poole peab kajastuma ka tervise testlehel.

#16 V Arendaja Arhitekt

Administraator

6.3 Rakendus peab pakkuma monitooringu lehte, kus leidub informatsioon rakenduse funktsionaalsuse toimimise kohta.

Tuleb rakendada OpenMetrics spetsifikatsiooni.

Monitooringu leht peab välja kuvama ka testlehel kuvatud komponentide olukorda.

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/

#16 V V Arendaja Arhitekt

Administraator

7. Nõuded rakenduse lähtekoodile

7.1 Lähtekoodi kommentaarid peavad kõigis lahenduse kihtides (rakenduse enda kood, andmebaas jne) olema kirjutatud inglise keeles.

NB! Nõuet ei arvestata arendustarkvara poolt automaatselt genereeritavate koodilõikude puhul – neid ei ole vaja tõlkida. Samuti ei rakendata nõuet 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.

#2 V V Arendaja Arhitekt

7.2 Lähtekoodi genereeritud dokumentatsioonid peavad olema selged, arusaadavad ja sisuliselt kirjeldama vastavat koodi, mille juures nad on. Lähtekoodist genereeritava dokumentatsiooniga tuleb katta kõik avalikud (public) meetodid ja funktsioonid.

Rakenduse kood peab olema piisavalt hästi dokumenteeritud, et erialast haridust omav tarkvaraarendaja on võimeline süsteemile jätkuarendusi teostama.

Rakendama peab dokumenteerimisel programmeerimiskeele parimaid praktikaid.

Näiteks tarkvara, mis on kirjutatud Java keeles, peab kasutama javadoc põhimõtteid ja võimekust.

#2 V V Arendaja Arhitekt

7.3 Muutujate, tüüpide ja funktsioonide nimed peavad olema sisulised ja andma aimu nende otstarbest.

Tuleb rakendada Clean Code põhimõtteid. Kui muutuja nimetus vajab kommentaari, siis pigem muuta muutuja nimetust kommenteerimise asemel.

Näiteks muutujate nimed peavad olema selged ja arusaadavad.

Hea näide muutujast: elapsedTimeInDays

Halb näide muutujast: etid

#2 V V Arendaja Arhitekt

7.4 Koodis kasutatavad konstandid ja lühendid tuleb kirjutada suurte tähtedega, lähtudes kasutatava programmeerimiskeele parimast praktikast.

Nt Javas identifikaator --> ID V V Arendaja Arhitekt

7.5 Koodis kasutatavaid konstante ei tohi selle kasutamise kohta väärtusena

V V Arendaja Arhitekt

hardcode'da – need tuleb defineerida muutujatena ja kasutada läbi nende.

7.6 Koodis defineeritud andmetüübid peavad olema nimetava käände ainsuses. Kõik andmemassiivid tuleb nimetada nimetava mitmuses (st igasugu collectionid, arrayd, jms).

N:Isik; Menetlus; jne. Andmebaaside struktuurikirjeldustes/andmemudelis ei tohi kasutada täpitähti.

V V Arendaja Arhitekt

7.7 Andmetabelites sisalduvad võõrvõtmed peavad nime järgi seostuma tabeli ja väljaga millele need viitavad.

Kasutada tuleb konkreetse andmebaasisüsteemi nimetamise parimaid praktikaid. Nt kui tegu on tabelitega ’Isikud’ ja ’Autod’, siis seos ’isiku autod’ oleks: Isikud.ID=Autod.Isik_ID

V V Arendaja Arhitekt

7.8 Andmebaasi väljade pikkused tuleb kirjeldada sümbolites, mitte baitides.

Selle asemel, et eraldada väljale x baiti, tuleb eraldada x tähemärki. (Instead of allocating x bytes of storage for the field, x chars of storage must be allocated).

V V Arendaja Arhitekt

7.9 Kui kokku pole teisiti lepitud, siis rakenduse kood peab olema kirjutatud vastavalt Google stiili juhendile.

https://google.github.io/styleguide/

Kui tarkvara keelel puuduvad Google stiili juhised, siis tuleb need kokku leppida Tellija arhitektiga enne kodeerimist.

V Arendaja Arhitekt

7.10 Koodi valideerimiseks kasutatakse minimaalselt Tellija lähtekoodi analüsaatorit.

Üleantavas koodis ei tohi olla kriitilisi ja kõrgemaid probleeme.

IT profiil: Lähtekoodi analüüs

#10

#40

V V Arendaja Arhitekt

7.11 Kasutuses mitteolev kood tuleb rakenduse lähtekoodist kõrvaldada.

Erandina on lubatud koodi osad, mis on valmis tehtud, aga ei ole veel kasutusse rakendatud ja on peidetud nn. funktsionaalsuste lippude (feature flag) taha.

V V Arendaja Arhitekt

7.12 Arendamisel kasutatakse DRY ja SOLID printsiipe.

http://en.wikipedia.org/wiki/Don%27t_repeat_yourself http://en.wikipedia.org/wiki/SOLID_(object- oriented_design)

V V Arendaja Arhitekt

7.13 Üleantavas koodis ei tohi olla paroole, mida on kasutatud arenduse käigus.

Kehtib ka siis, kui need on välja kommenteeritud. Kõik sellised paroolid tuleb asendada fraasiga “<password>“.

#28

#63

V V Arendaja Arhitekt

7.14 Üleantavas koodis ei tohi olla komponente, mille CVSS punktid on 7 ja kõrgemad ning CVE on rakendatav.

Kui CVE ei ole lahenduses rakendatav ehk tegu on lahenduse mõistes vale-positiivsega, siis võib 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.

#10 V V Arendaja Arhitekt

7.15 Üleantava lahendusega peab olema kaasas viis SBOM genereerimiseks.

SBOM ehk tarkvara materjalide loend. Mõistlik on SBOM genereerimine viia üheks järjepideva integratsiooni voo sammuks.

SBOM publitseerimine ja analüüsimine tuleb kokku leppida Tellijapoolse arhitektiga.

https://www.sbom.com/

V V Arendaja Arhitekt

7.16 Tehniliste komponentide API'del eksisteerib automaatselt genereeritud dokumentatsioon.

Näiteks REST API'de puhul kasutada OpenAPI spetsifikatsiooni.

https://www.openapis.org/

#20 V Arendaja Arhitekt

8. Andmekvaliteet

8.1 Andmekorjel kasutatakse klassifikaatoreid ja loendeid, kus need on olemas.

Vabatekstivälju tuleb vältida. #61 V V V Arendaja Arhitekt

Testija

8.2 Tekstiväljad on mõistliku suurusega. Varchar N tähemärki, kus N on ratsionaalne kaalutlus, kui suur lahter võib olla; vältida text/long-varchar kasutust, kui see pole hädavajalik.

V V Arendaja Arhitekt

8.3 Rakendus peab automaatselt eeltäitma kõik võimalikud andmeväljad, kui need andmed on varem riigile esitatud või kui nende väärtused on võimalik automaatselt arvutada.

Välja arvatud logimisvormi lahtrid autentimisel.

Näiteks: kirje sisestamise kuupäev, kasutaja nimi, sünnikuupäev jne

V V Arendaja Testija

8.4 Lahenduses peab olema tagatud idempotentsus.

Kasutaja sama tegevuse kordamisel ei tohi tekkida lahendusse andmeid topelt.

Näiteks "salvesta" nupu korduval vajutusel ei tohi tekkida dubleeritud andmeridu.

V V Arendaja Arhitekt

Testija

8.5 Analüüsi tulemusena ja enne esimese arendusetapi algust peab infosüsteemi kohta olema koostatud kontseptuaalne 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.

Peab olema dokumenteeritud projekti põhi dokumentatsiooni juures. Dokument tuleb hoida ajakohane.

#58 V Arendaja Arhitekt

8.6 Enne igat arendusetapi algust peab infosüsteemi kohta olema koostatud loogiline andmemudel ehk olemi-suhte 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

Peab olema dokumenteeritud projekti põhi dokumentatsiooni juures. Dokument tuleb hoida ajakohane.

#58 V Arendaja Arhitekt

mittekohustuslik (NULL/ NOT NULL), semantika ehk andmete tähendus.

8.7 Füüsiline andmemudel peab iga iteratsiooni lõpus või tarne tähtajaks selle iteratsiooni või tarne ulatuses sisaldama lisaks ajakohasele kontseptuaalsele ja loogilisele andmemudelile ka andmekirjeldusi andmebaasis.

Igal skeemil, tabelil ja veerul on kommentaar andmekirjeldusega, mis vastab loogilise andmemudeli kirjeldusele.

#58 V Arendaja Arhitekt

9. Kasutajaliides

9.1 Kasutajaliidese kõik disainiotsused peavad olema kooskõlastatud Tellijaga enne nende realiseerimist.

V V V Arendaja Projektijuht

9.2 Veebipõhine kasutajaliides peab olema kasutatav enamlevinud veebibrauseritega, sh nutiseadmetel (Android, IOS).

Minimaalselt Microsoft Edge, Mozilla Firefox, Chrome ja Safari arenduse testimise hetkel tootja poolt toetatud versioonid.

Täpsemad nõuded dokumendis "Front-end arendusreeglid".

V V V Arendaja Testija

9.3 Rakenduse värviskeemi ja logo kasutamine peab vastama Tellija ametlikule visuaalsele identiteedile (CVI) ja disainijuhistele (UIG).

Kui tegemist on struktuurfondide projektiga, on lisaks nõutud ka vastav SF sümboolika. Tellija ametlikud CVI esitluspõhjad, logo kasutusjuhend ja kõik logod (ka jpg-na) küsida Tellijalt.

V V Arendaja Testija

9.4 Kasutajaliidese kõik osad ja teated peavad olema eestikeelsed.

Kui soovitakse juurde eraldi ka muid keeli, siis see on spetsifitseeritud hankedokumentides.

V V V Arendaja Testija

9.5 Sisemiseks kasutamiseks tehtav rakendus peab olema graafiliselt skaleeruv ja mugavalt kasutatav Tellija töökohaprofiilis loetletud resolutsioonides.

Toetatud peavad olema töökohaprofiilis loetletud resolutsioonid.

Ühegi nimetatud resolutsiooni korral ei tohi tekkida horisontaalset kerimisriba.

V V Arendaja Testija

9.6 Kasutajaliideses toiminguni (põhi- ehk enamkasutatavad tegevused) navigeerimiseks peab kehtima 3 kliki printsiip, väljalogimiseks 1 kliki printsiip.

Kõik rakenduse kasutajaliidesest tehtavad toimingud tohivad üksteisest olla maksimaalselt 3 hiirekliki kaugusel. Toimingut ei pea nende 3 klikiga tehtud saama. Väljalogimise nupp/link peab olema ühe kliki kaugusel ja arusaadavas/intuitiivses kohas.

V V Arendaja Testija

9.7 Kasutajaliides peab alati küsima kinnituse andmete kustutamise ja massmuutmiste kohta kui just teisiti kokku pole lepitud.

V V V Arendaja Testija

9.8 Rakenduse kasutamisel tekkinud veale peab kasutajaliides vastama kasutajale eestikeelse kasutajasõbraliku veateatega, mis sisaldab ka vea koodi. Veateated peavad olema hallatavad.

Veateated peavad olema sellised, mis võimaldavad IT- abil võimalikult lihtsalt tuvastada vea olemuse ja asukoha.

V V V Arendaja Testija

9.9 Kasutajaliides peab olema ilma rakenduse koodi muutmata tõlgitav teise keelde, v.a kui ei ole teisiti kokku lepitud.

Uue keele lisamine peab olema teostatav konfiguratsiooni failist või administreerimisliidesest.

Konkreetne lahendus tuleb kokku leppida Tellija arhitektiga.

V V Arendaja Testija

9.10 Rakenduse kasutajaliides peab teavitama kasutajat ette sessiooni aegumisest.

Etteteavitamise aeg peab olema konfigureeritav. V V V Arendaja Administraator

Testija

9.11 Kui vormile sisestatakse mahukaid andmevälju, peab kasutajaliides kokku lepitud ajavahemike järel salvetama välja sisu, et sessiooni aegumisel või võrgu katkestuse korral juba sisestatud andmed ei kaoks.

Näiteks kui vorm koosneb paljudest väiksest andmeväljadest (nt taotlus), siis jagatakse vorm etappideks ning salvestatakse vastava etapi lõpus.

V V Arendaja Testija

9.12 Interaktiivsete vormide puhul (näiteks faili üleslaadimine) ei tohiks lehe värskendamisega tegevust korrata (faili taas üles laadida, andmeid saata, avaldust esitada).

V V Arendaja Testija

9.13 Esilehel (sisselogimata) ja pärast kasutaja sisselogimist peab olema lihtne võimalus teavitada kasutajat muudatustest või probleemidest. Teavitus peab olema halduri poolt lihtsasti lisatav ja kasutajale märgatav.

Näiteks võimalikud teavitused: mingi süsteemi osa on vigane, tuli mingi uus funktsionaalsus, hetkel on hooldus, uuendage isikuandmeid jne.

Mõistlik on hooldusteate võimekiust juhtida taustteenuse abil. Näiteks läbi esitluskihi jaoks loodud seadete REST liidese.

V V Arendaja Testija

10. Dokumentatsioon

10.1 Lõppkasutajatele ja avalikkusele suunatud rakenduse dokumentatsioon peab olema kirjutatud eesti keeles.

Erandiks võivad olla kolmanda osapoole komponentide (mis pole kirjutatud Tellija jaoks) dokumentatsioon. Samuti võib erandiks olla väliste osapooltega seotud projektid. Erandid tuleb kooskõlastada Tellijaga enne dokumentatsiooni koostamist.

V V Arendaja Projektijuht

Arhitekt

Administraator

Testija

Infoturbe spetsialist

10.2 Lahendus kirjeldatakse RIHA määruse nõuete kohaselt.

https://www.riigiteataja.ee/akt/12933746? leiaKehtiv#para6

#57 V Arendaja

Projektijuht

Tellija RIHA haldur

Projektijuht

10.3 Rakenduse dokumentatsioon peab vastama dokumendis "Nõuded infosüsteemi dokumentatsioonile" kirjeldatud nõuetele.

Dokumentatsioon peab olema versioneeritud, muutmiskuupäevadega, autori nimedega, korrektse keelekasutusega, selge struktuuriga. Dokumentatsiooni detailsus peab olema piisav, et sõltumatu kolmas tehnliste IT baasteadmistega isik

V V Arendaja Projektijuht

Arhitekt

Administraator

suudaks dokumendist vajalikke järeldusi teha (st dokument peab olema arusaadav sellele isikule, kuid näiteks paigaldusjuhise järgi toimetades ei pea ta ebaõnnestunud tarnele teostama veaanalüüsi).

Täpsemad nõuded dokumendis "Nõuded infosüsteemi dokumentatsioonile".

Testija

Infoturbe spetsialist

10.4 Rakenduse dokumentatsioon peab sisaldama tabelite-andmete-logide mahu kasvu arvestuslikku hinnangut rakenduse sihipärase kasutamise korral ettenähtud arvu kasutajate poolt. (MB/GB kuus/aastas).

Esialgne kirjete mahu hinnang peab tulema lähteülesandest, ning täpsustuma eel- ja detailanalüüsi käigus. Mahuhinnang peab sisaldama ka logide säilitamise, arhiveerimise tähtaegu.

V V Arendaja Projektijuht

Arhitekt

Administraator

Infoturbe spetsialist

10.5 Iga uue versiooniga peab alati välja tooma versiooni muudatuse kirjeldused (release notes).

Release notes peab kajastama kõiki muudatusi eelmise ja uue versiooni vahel.

V V V Arendaja Projektijuht

10.6 Arendaja loodud lahenduse dokumentatsioonis (nt detailanalüüs vms) tuleb välja tuua kasutatavad krüpto- ja räsialgoritmid, nende võtmepikkused, kasutuskohad, sh TLS sertifikaatide kasutuskohad.

V V Aremdaja Arhitekt

Administraator

11. Versioonihaldus

11.1 Kogu rakenduse testimiseks, koolituseks või implementeerimiseks üle antav lähtekood ja tarkvarapaketid peavad olema versioneeritud. Kasutama peab Tellija versioonihalduse ja tehiste (artifaktide) repositooriumi.

Arendajale antakse selleks õigused Tellija versioonihalduse repositooriumi, kus ta peab hoidma oma erinevaid versioone. Versioonihalduse repositooriumi juurdepääsutaotlus esitatakse Tellija kasutajatoele läbi projektijuhi.

#1 V V Arendaja Arhitekt

Administraator

11.2 Arendaja peab veenduma, et teeb muudatusi aktuaalsesse koodi.

Hea tava on, et paralleelse arendamise puhul võetakse igal hommikul versioonihalduse repositooriumist viimane seis koodist.

V V Arendaja Arhitekt

Administraator

11.3 Nii arendamisel kui ka hoolduslepingute korral kasutatakse Tellija tööde ja veahalduse keskkonda.

Arendajale antakse selleks õigused Tellija tööde ja veahalduse keskkonda.

Veahalduse keskkonda juurdepääsutaotlus esitatakse Tellija kasutajatoele läbi projektijuhi.

V V Arendaja Projektijuht

11.4 Versioonihaldusesse muudatuste üleslaadimisel kasutada üleslaadimissõnumis Conventional Commits stiili.

https://www.conventionalcommits.org/ V Arendaja Arhitekt

12. Paigalduspaketi kooste

12.1 Rakendus on versioneeritud kasutades semantilise versioneerimise põhimõtet.

A.B.C kujul, kus C on veaparandus, B on funktsionaalne uuendus, mis töötab ka vanematel 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/

#15 V Arendaja Arhitekt

Administraator

12.2 Juhul kui versioonihalduse keskkond ei paku paigalduspaketile kontrollsumma (checksum) automaatset koostamist, siis koostatakse kontrollsumma arendaja poolt ja pannakse eraldi .sum failina tarnele kaasa.

Räsialgoritmiks tuleb kasutada SHA256. Linuxi käsurealt kontrollkoodi koostamiseks: $ sha256sum filename [filename2] ... > kontrollkood.sum.

V V Arendaja Administraator

12.3 Tarnitava lahenduse koosseisus üleantava lähtekoodiga peavad kaasas olema kirjeldused sellest paigalduspaketi koosteks.

Näiteks võib lahenduse paigalduspaketi koosteprotsess ette näha, et käivitada tuleb rida shell-käske või võivad lahenduse koosseisus olla valmis (ant, ..) koosteskriptid või mistahes muu moodus paigalduspaketi tekitamiseks.

Eelistatud on kasutada Dockerfile ja Gitlab töövooge.

V V Arendaja Projektijuht

Administraator

12.4 Kooste kirjelduste alusel valmiv paigalduspakett tohib sisaldada ainult minimaalse rakenduse käitamiseks vajamineva failikomplekti.

Näiteks: kompileeritavate keelte puhul ei tohi sisaldada lähtekoodi, kui see pole vajalik rakenduse käitamiseks.

V V Arendaja Arhitekt

Administraator

12.5 Kooste kirjelduste alusel valmivat paigalduspaketti peab olema võimalik liigutada erinevate masinate vahel.

Näiteks ei tohi tekitada olukorda, kus rakenduse jooksutamiseks uues serveris tuleb see tingimata just sealsamas kokku kompileerida.

V V Arendaja Administraator

12.6 Rakenduse kõik sõltuvused peavad olema kompileerimisel saadavad Tellija tehiste repositooriumist.

#4 V V Arendaja Arhitekt

12.7 Andmebaasi paigalduse skriptid ei tohi olla kompileeritud.

Administraator tahab veenduda skripti sisus. V V Arendaja Administraator

12.8 Rakenduse lähtekoodi juures peab leiduma skriptid rakenduse keskkonnast sõltumatult (konteinerlahenduses) kokku kompileerimiseks.

Tellijal peab olema võimalik suuri pingutusi tegemata ja keskkonna erinevusi vältides teha rakendusest paigaldatav pakk.

V V Arendaja Arhitekt

12.9 Rakenduse lähtekoodi juures peab leiduma skriptid rakenduse lokaalselt

Vajadusel peab konteinerlahendus käivitama ka rakenduse muud sõltuvused (näiteks andmebaas).

V V Arendaja Arhitekt

mõnes konteinerlahenduses (Docker) käivitamiseks.

See on Täitjale uue meeskonnaliikme liitumise lihtsustamiseks ja Tellijale võimalus suuri pingutusi tegemata süsteemi testimiseks.

12.10 Paigalduspakett koostatakse Tellija pideva integratsiooni (continuous integration - CI) ja paigaldus (continuous deploy - CD) arendus keskkonnas.

#13 V V Arendaja Arhitekt

12.11 Kubernetesel (K8s) orkestreeritavate lahenduste paigalduste jaoks tuleb luua Helm chart.

https://helm.sh/

Helmi jaoks kasutatava malli annab Tellijapoolne arhitekt.

V V Arendaja

Arhitekt

Arhitekt

Administraator

12.12 Kubernetesel (K8s) orkestreeritavate lahenduste paigalduste jaoks tuleb luua vajalikud automaatsed laienemise reeglid.

https://kubernetes.io/docs/tasks/run- application/horizontal-pod-autoscale/

V V Arendaja

Arhitekt

Arhitekt

Administraator

Lisa 12 - Andmeladude olemus ja funktsioon juhis 14042023.pdf

1 / 21

„Andmeladude olemus ja selle funktsioonid“

Selgitav juhis

Majandus- ja Kommunikatsiooniministeerium

14.04.2023

2 / 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

3 / 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

4 / 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

5 / 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.

6 / 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.

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

8 / 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.

9 / 21

täita. Seega tekivad tahes tahtmata andmed erineval kujul, kuid see ei tähenda, et tegemist oleks

lubamatu koopiaga.

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

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.

10 / 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.

11 / 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.

12 / 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.

13 / 21

Järgnevalt ilmestame kasutusviiside erinevaid juhte.

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

anonüümitud ja justkui

seetõttu eraldi reguleerimist

ei vaja, ei ole päris õige. Kui

teave tekib (andmed) ja see

kantakse ja säilitatakse

andmekogus, tuleks seegi

selgelt reguleerida. Toome

kõrval sellekohase näite.

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

Näiteks kui andmelao andmed on anonüümselt olemas, siis võib

ka siin näha ette erisuse andmelao anonüümitud andmetele ehk

tuuagi välja, et peetakse ka anonüümitud andmeladu mille

andmed on „x“ tähtajani. Näiteks on andmekogul ühed

eesmärgid – loa taotlused, menetlused. Kui load on väljastatud

ja kõik menetlused lõppenud ja neid hoitakse näiteks seoses

vaidlustamisvõimalustega vaid viis aastat, siis võib teatud

faktiliste andmete säilitamine olla põhjendatud ka statistikaks

pikemalt, et kujundada valdkondlikku poliitikat. Nii täidavad

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.

14 / 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)

15 / 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 ..

16 / 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 41,

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.

17 / 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

privaatsustehnoloogiate rakendamisel.31 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.

18 / 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

teiste isikutega (AvTS § 439 lg

6).33

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.

(5) Andmevahetus riigi infosüsteemi kuuluvate andmekogudega ja

riigi infosüsteemi kuuluvate andmekogude vahel toimub läbi riigi

infosüsteemi andmevahetuskihi.

(6) Käesoleva paragrahvi lõikes 5 toodu ei piira andmevahetust

infosüsteemide andmevahetuskihil muude juriidiliste isikute

vahel.

19 / 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.

20 / 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 § 592 lg 1,

https://www.riigiteataja.ee/akt/110102022004#para59b2.

21 / 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.

Lisa 13 - IT-Profiil v3 veebidoc.pdf

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

(Component)

Eelistatud

(Preferred)

Aktsepteeritav

(Acceptable)

Mitte valida

(Do not select) Kommentaarid

Kliendi kiht (Client Layer)

Lauaarvuti ja sülearvuti OS / keskkond (Desktop & laptop client OS / environment)

• Windows • Linux • macOS

Lauaarvuti ja sülearvuti kliendi kasutajaliides (Desktop & laptop client user interface)

• Chromium based • Firefox

• Safari (väline klient/external client)

• Edge Legacy • Internet Explorer

Mobiilse kliendi OS / keskkond (Mobile client OS / environment)

• Android perekond (Android family)

• iOS • Windows Phone

Mobiilse kliendi kasutajaliides (Mobile client user interface)

• Chromium based • Firefox • Safari

• Multi platform frameworks

o Flutter o Kotlin

Multiplatform • Native app

• Multi platform frameworks

o .Net based o Nativescript o Ionic

Esitluskiht (Presentation Layer)

Sisuhaldussüsteem (Content management system)

• Drupal • Strapi[1] • WikiJS[1]

• Joomla! • WordPress

[1] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

Esitluskihi raamistik (Presentation framework (View))

• JavaScript o Angular o React

• JavaScript o Next.JS[1] o Single-SPA o Web-pack

• Java o JSP o JSF

• iFrame • Microsoft .Net • Python

[1] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

Veebiserver (Web server) • Nginx

• Apache HTTP server

• Microsoft IIS

IT-Profiil (versioon: 3)

Funktsionaalne testimine (Functional testing)

• Selenium • Selenide

• Cypress[1] • Playwright[1]

[1] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

Rakenduskiht (Application Layer)

Rakenduse raamistik (Application framework)

• Java o Spring[1] o Spring boot

• Java o Quarkus[2]

• Java o Micronaut

• C# o .Net o .Net

Framework o ASP.NET o Entity

Framework Core

[1] Kogu Springi perekond (All Spring family)

[2] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

Protsessimootor (Workflow Engine)

• Zeebe

Andmeloogika (Persistence framework)

• Java o JPA o JDBCTemplate

• Java o Hibernate[1] o jOOQ

[1] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

Otsingumootori indeks (Search Engine Index)

• Elasticsearch

Integratsioon (External integration (integration to other systems))

• AMQP[1] • REST

• GraphQL[2] • gRPC[2] • SOAP

• Oracle Advanced Queuing

[1] RabbitMQ

[2] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

Andmete laadimine (Data Loading - ETL)

• Apache Hop • OData consumer [1]

• Meltano[2] • Pentaho[2]

[1] TEHIKu toode (TEHIK's product)

[2] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

Aplikatsiooniserver (Application server)

• Java o Tomcat o Embedded

▪ Jetty ▪ Tomcat ▪ WildFly

o GraalVM

• Java o WildFly [1]

• Webmethods Integration Server

• .NET o MS IIS

• Java o Apache

JServ o Sun Java

System Application Server

o SAP o IBM

WebSphere o Oracle iAS o Oracle

iPlanet Web Server

o WebLogic

[1] VM põhine (VM based)

Funktsionaalne testimine (Functional testing)

• Insomnia • SoapUI

• Postman

Koormustestimine (Load testing)

• Jmeter • Gatling

• Testkube

Andmekiht (Persistence Layer / Database layer)

Andmebaasi migratsioon (Database migration)

• Liquibase • Flyway

Relatsiooniline andmebaas (Relational DBMS)

• PostgreSQL • MariaDB[1] • MS SQL Server • Oracle DB • Sybase

[1] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

IT-Profiil (versioon: 3)

Mitte ainult SQL (NoSQL) • KeyDB

• MongoDB[1] • Valkey[2]

• Redis

[1] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

[2] https://valkey.io/

Andmeladu (Data Warehouse)

• Vertica • Sybase IQ

Andmete replikatsioon (Data Replication)

• Spilo

Failide hoiustamine (Object Storage)

• MinIO • S3 protokollil

põhinevad objektihoidlad

• Failid andmebaasis (BLOB)

Infrastruktuuri kiht (Infrastructure Layer)

Directory services • MS Active Directory

Autentimine ja Ühekordne

sisselogimine (Authentication

and Single Sign On)

• GovSSO • TEHIK SSO[1]

[1] TEHIK SSO on asutuseväliste kasutajate vaates liikumas toe lõppemise suunas. (TEHIK SSO is moving towards end of life)

Kasutajaõiguste haldus (Authorization)

• Pääsuke [1] • TEHIK SSO AD realm[2]

• TEHIK SSO + rollide api teenuse pool[3]

• MS AD (siseteenused)

[1] https://www.ria.ee/riigi- infosusteem/kesksed- platvormid-avalike-e-teenuste- pakkumiseks/paasuke

[2] On mõeldud siseste kasutajate rollide jaoks (Is ment for inside 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)

Identiteedi haldus (Identity management)

• MIM[1]

[1] Tootel on saabumas eluea lõpp (Product is moving towards end of life): https://learn.microsoft.com/en- us/lifecycle/products/microsoft- identity-manager-2016

Logihaldus (Log management)

• Elastic Agent/Elastic Beats/Logstash

• rsyslog

• GreyLog • Windows Event

Collector

Süsteemi haldamine ja järelevalve (System management and monitoring)

• Prometheus • Grafana • Elastic APM

• Zabbix • Nagios

Koormusjaotur (Traffic management)

• Nginx • HAProxy

Puhverdamine (Caching) • Nginx

• Squid • Varnish

Tööde ajastamine (Job scheduling)

• Application specific decision ie Quartz or cron, windows scheduler

• k8s CronJob

Serveri operatsioonisüsteem (Server OS)

• Linux (Tootja poolt viimane pikaajalise toega või stabiilne versioon)

o Oracle Linux o RedHat o Ubuntu

• Windows o MS (64 bit)

• Linux o Debian o CentOS

• IBM AIX • Other UNIXs

IT-Profiil (versioon: 3)

Konteinerid (Containers) • OCI compliant[1] [1] https://opencontainers.org

Konteinerite orkestreerimine (Contaier orchestration)

• Kubernetes • Docker Swarm

Virtualiseerimine (Virtualization)

• VmWare

• Hyper-V • QEMU/KVM • OracleVM • Xen

Serveri riistvara (Server hardware)

• x86_64 • RISC

Varundamine (Backup)

• VmWare o Veritas

Netbackup • Kubernetes

o S3

• Symantec Backup

Exec

Kettakasti riistvara (Storage hardware)

• SAN o FC >= 32 Gb/s

• SAN o FC >= 16 Gb/s

• iSCSI

Riistvaraline krüptomoodul (HSM - Hardware security module)

• Thales • Utimaco

Tulemüür (Firewall)

• DPI (Deep packet inspection) Layer 7 Pahavara tõrje (Anti- malware)

Muud aspektid (Other Aspects)

Programmeerimiskeeled (Programming languages)

• Java • TypeScript

• Go[1] • JavaScript • Kotlin[1] • Python[1] • PHP[1] • Rust[1][2]

• NET • C/C++/C# • Webmethods flow • iWay Functional

Language

[1] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

[2] Krüptograafiliste tegevuste teostamiseks (To perform cryptographic activities)

Java virtuaalmasina implementatsioon (Java vitual machine implemetation)

• OpenJDK • Oracle JDK

Versioonihaldus (Version control system)

• GitLab o Koodivaramu[1] o TEHIK

haldusalas olev

• GitHub[1] • SVN • Atlassian Bitbucket

[1] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

Artefaktide repositoorium (Artifacts repository)

• JFrog artifactory • Gitlab registry

• DockerHub[1] • GitHub Packages[1] • npmjs.com[1]

[1] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

Pidev integratsioon (Continuous integration)

• Gitlab CI • Github Actions[1] • Jenkins • Bamboo

[1] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

Paigalduse automaatika (Continious Deployment / Delivery)

• Ansible • GitLab CD (dev/test) • Helm (live) • Terraform

• GitHub Actions[1] • Argo CD[1]

• Jenkins • Bamboo

[1] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

Lähtekoodi analüüs (Code analysis)

• SonarQube

Tarkvara materjalide loend (SBOM - software bill of materials)

• CycloneDX SBOM

Tarkvara materjalide loendi analüsaator

• Dependency-Track[1] [1] https://dependencytrack.org

IT-Profiil (versioon: 3)

(software bill of materials analysis platform)

Analüütika (Analytics) • Tableau • Apache Superset[1]

• Webfocus • Qlik Sense • Oracle BI Publisher • SAP® Business

Objects

[1] Tuleb TEHIKu arhitektiga kooskõlastada (Must be coordinated with TEHIK architect)

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.

Lisa 14 - SKANDL-220126-1743-1550.pdf

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

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

SKA äripoole kasutaja - Meelis Põlda. SKAIS2 Oracle kontakt TEHIK-us - RAIN Pentaho ja Vertica - Matthias Johann Kurs Graafikuid ja kirjeldusi koostab Resta OÜ.

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

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

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 &

1. 2.

Ligipääsud

Uued skeemid

Kui laadimine peaks toimuma uute skeemi, siis arendaja koostab nende lisamiseks itabi ( ) tellimuse (sh. lisab kirja CC reale TEHIK-u [email protected] 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

Täiendada ska.sql feature harus, ning saata merge request kellele? Peale master jõudmist teha tellimus

Lisada SKAIS2 DWH live verticas skeemid - näiteks DW_SKAIS_DOCUMENT_MANAGEMENT_ODS, DW_SKAIS_DOCUMENT_MANAGEMENT_STG 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;

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;

SLA (arendustööde tingimused / rakenduste teenustasemed)

SKA andmeladu

Teenuse parameeter Väärtus

ISKE turvaklass K1T1S2

Rakenduse tööaeg (millal laoplatvorm peab olema kättesaadav)

07:00 - 19:00

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 kestus

8 tundi

Summaarne maksimaalne plaanimata katkestuste kestus kuus

16 tundi

Samaaegsete andmeanalüüsivahendite kasutajate arv

Kuni 40 kasutajat korraga

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.

SKAIS1 andmeladu

SKAIS1 andmemudel

SKAIS1 andmemudel

a. b. c. d.

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:

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

dwh_id - Surrogaatvõti (andmelao laadimisprogrammi poolt genereeritud võtmeväli) is_valid - 0/1 väli, mis näitab, kas tegemist on kehtiva kirjega (kõige viimase versiooniga) valid_from - versiooni kehtivuse algusaeg (kuupäev ja kellaaeg) 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.

1. a.

b. c.

SKA DW andmete laadimine Andmete laadimiste üldine loogika SKA_DW andmete laadimine toimub järgmise skeemi kohaselt

Lähtesüsteemi (SKAIS) andmemudeli muudatuste tuvastamine (sh SKA DW andmemudeli uuendamine) 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 Lähteallika andmemudelit võrreldakse SKA DW poolt teada oleva mudeliga (st eelmisel päeval kehtinud andmemudeliga) ning tuvastatakse muudatused. 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').

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_

ja kirjelduste juurest). SKAIS1.TABLES ADM_SKAIS1.COLUMNS (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) Andmete laadimine ODS tabelitesse (sh lähtesüsteemist kustutatud kirjete märkimine kehtetuks) 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.

SKA DW süsteemsed tabelid

COLUMNS Väljade/veergude andmed

Välja nimi Välja tüüp

Selgitus Andmete näited

COLUMN_VERSION _ID

int Surrogaatvõti 55

DATA_SOURCE_CO DE

varchar (20)

Andmeallika/lähtesüsteemi kood 'SKAIS'

SOURCE_SCHEMA_ NAME

varchar (128)

Skeemi nimi lähtesüsteemis 'SKA_OWNER'

SOURCE_TABLE_N AME

varchar (128)

Tabeli nimi lähtesüsteemis 'AADRESS'

SOURCE_COLUMN_ NAME

varchar (128)

Välja/veeru nimi lähtesüsteemis 'AADRESS_KOOD'

DWH_COLUMN_NA ME

varchar (128)

Välja/veeru nimi andmelaos 'AADRESS_KOOD'

SOURCE_COLUMN_ COMMENT

varchar (4000)

Välja/veeru kirjeldus lähtesüsteemis 'Kommentaar'

DWH_COLUMN_CO MMENT

varchar (4000)

Välja/veeru kirjeldus andmelaos 'Kommentaar'

DATA_TYPE varchar (128)

Andmetüüp lähtesüsteemis 'VARCHAR2', 'INTEGER', 'DECIMAL'

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

DWH_DATA_TYPE varchar (255)

Andmetüüp andmelaos 'VARCHAR(1020)'

NULLABLE char(1) Kas veerg võib sisaldada puuduvaid (NULL) väärtusi (0/1)

IS_KEY int Kas veerg on primaarvõti (0/1) 0

LOAD_STATUS varchar (20)

Välja/veeru laadimise staatus andmelaos

'LOAD' - Välja laadimine on sisse lülitatud

'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 TUS

varchar (30)

Välja staatus andmelaos: 'NEEDS_CREATION' - väli vajab loomist

'NEEDS_MODIFICATION' - väli vajab muutmist (näiteks lähteallikas on muutunud andmetüüp)

'READY' - väli on loodud/muudetud

SOURCE_COLUMN_ ID

int Välja/veeru ID lähtesüsteemis 11

IS_VALID int Kas tegemist on kehtiva kirje /versiooniga (0/1)

VALID_FROM timesta mp

Kirje/versiooni kehtivuse algusaeg '2018-05-04 17:26:58'

VALID_TO timesta mp

Kirje/versiooni kehtivuse lõppaeg '2018-05-04 11:22:58'

MODIFIED_BY varchar (32)

Kirje looja/muutja 'pentaho'

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'

DATA_SOURCES Andmeallikad (lähte-andmebaasid)

Välja nimi Välja tüüp

Selgitus Andmete näited

DATA_SOURCE_VERS ION_ID

int Andmeallika versiooni ID. Surrogaatvõti. 1

DATA_SOURCE_CODE varchar (32)

Andmeallika/lähtesüsteemi kood. 'SKAIS'

DATA_SOURCE_NAME varchar (128)

Lätesüsteemi nimetus 'Töötukassa aruandlusmoodul'

DATA_SOURCE_TYPE varchar (20)

Lähtesüsteemi tüüp 'SOURCE_DB' - lähtesüsteemiks on andmebaas

DBMS_TYPE varchar (20)

Andmebaasi tüüp 'ORACLE'

IS_ACTIVE int Kas lähtesüsteemist andmete laadimine on aktiivne (võimaldab terve lähtesüsteemi 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 (32)

Versiooni lisaja/muutja 'SYSTEM'

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'

DWH_SCHEMAS Andmelao skeemide andmed.

Iga siin kirjeldatus skeemi kohta luuakse andmelaos vähemalt 2 skeemi (<skeemi nimi>_STG - vastava loogilise andmeallika tabelite skeem, staging <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 tüüp

Selgitus Andmete näited

DWH_SCHEMA_VERSIO N_ID

int Skeemi versiooni ID 1

DWH_SCHEMA_NAME varchar(32) Andmelao skeemi/loogilise andmeallika nimi 'ORACLE'

DWH_SCHEMA_COMME NT

varchar (255)

Andmelao skeemi kirjeldus 'Töötute registreerimise, tööturuteenuste ja -toetuste menetlemise 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 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'

EVENT_LOG Sündmuste logi

Välja nimi Välja tüüp

Selgitus Andmete näited

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 -

'INSTALLATION', 'LOADING'

EVENT_TYPE varchar(20) Sündmuse tüüp. Võimalikud variandid:

ERROR - viga, WARNING - hoiatus, SUCCESS - edukas tegevus, INFO - teade

'ERROR'

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

'ADM.TABLES'

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'

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

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'

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

LOAD_LOG Andmete laadimise logi

Välja nimi

Välja tüüp

Selgitus Kommentaar Andmete näide

LOG_ID int Logikirje identifikaator. Primaarvõti.

PROCE SS_ID

int Laadimise protsessi identifikaator.

Iga käivitatud andmete laadimise protsess saab unikaalse identifikaatori. 1

SUBPR OCESS _CODE

varchar (50)

Alamprotsessi kood /nimi

Võimalikud väärtused:

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 OURCE _CODE

varchar (32)

Andmeallika kood. Viide tabelile ADM. DATA_SOURCES

'SKAIS'

RELATE D_OBJE CT

varchar (50)

Protsessiga seotud objekti (skeemi, andmetabeli vms) kood

'DW_SKAIS _ODS. AADRESSID'

START_ DT

datetime Protsessi käivitamise algusaeg

'2018-05-20 05:30:00'

END_DT datetime Protsessi käivitamise lõppaeg

'2018-05-20 06:30:28'

STATUS varchar (32)

Laadimise protsessi (lõpetamise) staatus.

Võimalikud väärtused:

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 ORE

int Kas lõpetamise staatust võib ignoreerida.

Kui eelmine laadimise protsess ei ole lõppenud (on staatuses STARTED) või lõppes veaga (on staatuses ERROR), siis üldjuhul järgmist sama allika laadimisprotsessi ei käivitata. Kui on soov järgmine laadimine ikkagi käivitada, siis tuleb eelmisel laadimisprotsessil märkida IS_IGNORE = 1.

SCHEMAS Lähtesüsteemi skeemid

Välja nimi Välja tüüp

Selgitus Andmete näited

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 ME

varchar (128)

Skeemi nimi lähtesüsteemis 'SKA_OWNER'

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

TABLES Tabelite andmed.

Välja nimi

Välja tüüp

Selgitus Andmete näited

TABLE_VE RSION_ID

int Surrogaatvõti 281

DATA_SO URCE_CO DE

varchar (32)

Andmeallika/lähtesüsteemi kood 'SKAIS'

SOURCE_ SCHEMA_ NAME

varchar (128)

Skeemi nimi lähtesüsteemis 'SKA_OWNER'

SOURCE_ TABLE_NA ME

varchar (128)

Tabeli nimi lähtesüsteemis 'AADRESSID'

DWH_SCH EMA_NAME

varchar (128)

Skeemi nimi andmelaos 'DW_SKA_OWNER'

DWH_TAB LE_NAME

varchar (128)

Tabeli nimi andmelaos 'AADRESSID'

TABLE_TY PE

varchar (20)

Tabeli tüüp (TABLE, VIEW, MVIEW) 'TABLE'

SOURCE_ TABLE_C OMMENT

varchar (4000)

Tabeli kirjeldus lähtesüsteemis ''

DWH_TAB LE_COMM ENT

varchar (4000)

Tabeli kirjeldus andmelaos ''

LOAD_ST ATUS

varchar (20)

Laadimise staatus 'LOAD' - Tabeli laadimine on sisse lülitatud

'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 THOD

varchar (20)

Andmete laadimise meetod 'LOAD_MODIFIED' - laaditakse pärast viimast õnnestunud andmete laadimist lisatud /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 _FILTER

varchar (255)

Filtritingimus, mida kasutatakse muudetud ja/või lisatud andmete tuvastamiseks (LOAD_MODIFIED) laadimismeetodi korra.

'SYS_MUUTMISE_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')'

LAST_LOA D_EXPRE SSION

varchar (255)

Avaldis, mis tuvastab mis aja seisuga andmed on laaditud

'timestampadd('hour',-1, max(sys_muutmise_aeg))'

DWH_TAB LE_STATUS

varchar (30)

Tabeli staatus andmelaos 'NEEDS_CREATION' - tabel vajab loomist

'NEEDS_MODIFICATION - tabel vajab muutmist

'READY' - tabel on loodud/muudetud

LAST_LOA D_DT

timesta mp

Viimase õnnestunud andmete laadimise kuupäev ja kellaaeg

'2018-05-15 00:01:10'

IS_VALID int Kas tegemist on kehtiva kirje/versiooniga (0/1) 0

VALID_FR OM

timesta mp

Kirje/versiooni kehtivuse algusaeg '2018-05-04 17:24:53'

VALID_TO timesta mp

Kirje/versiooni kehtivuse lõppaeg '2018-05-22 21:43:07'

MODIFIED _BY

varchar (32)

Versiooni lisaja/muutja 'pentaho'

IS_DM_TA BLE

int Kas tegemist on andmelettide arvutamisel kasutatava andmetabeliga. 0/1 tunnus.

Kui mõne andmelettide laadimises kasutatava tabeli laadimisel tekib viga, siis andmelettide laadimise osa ei käivitata.

IS_ROW_ COUNT

int Kas tabeli laadimisel võrreldakse andmelattu 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 _STMT

varchar (255)

Kirjete kustutamise update lause Üldjuhul kasutatakse lähtesüsteemist kustutatud kirjete märkimiseks järgmist SQL lauset:

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 _LOG_TA BLE

varchar (255)

Millisest logitabelist tuleb võtta vastava tabeli kustutatud kirjete info.

Võimalikud variandid on XXX_LOG, XXX_LISALOG, HISTORID. Kui väärtus on tühi, siis vaikeväärtusena kasutatakse XXX_LOG.

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.

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"?>

<repository> <id>KettleFileRepository</id>

<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

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

<server> </server>ska-wrh-1a.prd.tehik.ee

<type>VERTICA5</type>

<access>Native</access>

<username>pentaho</username>

<password>Encrypted *****</password>

<data_tablespace/>

<index_tablespace/>

.......

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

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

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.

Kasuta antud ODBC ühendust ODBC toetavas kliendis nagu Excel või mõni teine

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?

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

Logimine Vertica laadimiste logid

Vertica sql (wrh-db.prd.tehik.ee)

ADM_SKAIS1.LOAD_LOG ja - laadimiste logitabelid. Vt täpsem kirjeldus logitabelite kirjelduse juurest.ADM_SKAIS2.LOAD_LOG

ADM_SKAIS1.EVENT_LOG ja - sündmuste logi (võimaldab leida täpsema Pentaho protseduuri ja sõlme, kus viga tekkis). ADM_SKAIS1.EVENT_LOG

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

SKAIS2 andmeladu

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

--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');

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

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

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. Sättida õigused "pentaho" kasutajal chown -R pentaho /opt/etl/data-integration94 chmod u+x /opt/etl/data-integration94/*.sh 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 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.

a. b. c. d.

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:

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

Lisaks nimetatud kihtidele on eraldi skeem (nimega ADM_SKAIS2), mis sisaldab andmete laadimiseks ning muuks SKA DW toimimiseks vajalikke andmetabeleid.

1. a.

b. c.

SKA SKAIS2 DW andmete laadimine Andmete laadimiste üldine loogika SKA_DW andmete laadimine toimub järgmise skeemi kohaselt

Lähtesüsteemi (SKAIS2) andmemudeli muudatuste tuvastamine (sh SKA DW andmemudeli uuendamine) 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. Lähteallika andmemudelit võrreldakse SKA DW poolt teada oleva mudeliga (st eelmisel päeval kehtinud andmemudeliga) ning tuvastatakse muudatused. 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').

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_

ja kirjelduste juurest)SKAIS2.TABLES ADM_SKAIS2.COLUMNS (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) Andmete laadimine ODS tabelitesse (sh lähtesüsteemist kustutatud kirjete märkimine kehtetuks) Lähtesüsteemi ja ODS tabeli kirjete arvu võrdlemine.

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

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

Alljärgnevas tabelis on laaditavate tabelite nimekiri 30.10.2025 seisuga

SOURCE_TABLE DWH_TABLE LOAD_METHOD MODIFIED_FILTER

SKAIS2. AD_AADRESS

DW_SKAIS2. AD_AADRESS

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. AE_ARST_SPETSIA LIST

DW_SKAIS2. AE_ARST_SPETSIA LIST

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. AE_ARST_SPETSIA LIST_DOKUMENT

DW_SKAIS2. AE_ARST_SPETSIA LIST_DOKUMENT

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. AE_EKSPERTARST _LEPING

DW_SKAIS2. AE_EKSPERTARST _LEPING

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.AE_ERIALA DW_SKAIS2. AE_ERIALA

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. AE_HINDAMINE_TE GEVUS

DW_SKAIS2. AE_HINDAMINE_TE GEVUS

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. AE_HINDAMINE_TE GEVUS_KYSIMUS

DW_SKAIS2. AE_HINDAMINE_TE GEVUS_KYSIMUS

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. AE_HINDAMINE_VA LDKOND

DW_SKAIS2. AE_HINDAMINE_VA LDKOND

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. AE_HINDAMINE_VA LDKOND_TASE

DW_SKAIS2. AE_HINDAMINE_VA LDKOND_TASE

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

DW_SKAIS2. AE_HINNANG

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. AE_HINNANG_DIA GNOOS

DW_SKAIS2. AE_HINNANG_DIAG NOOS

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. AE_HINNANG_MOJ UTATUD

DW_SKAIS2. AE_HINNANG_MOJ UTATUD

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

DW_SKAIS2. AE_HINNANG_OLEK

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. AE_HINNANG_TEG EVUS

DW_SKAIS2. AE_HINNANG_TEG EVUS

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. AE_HINNANG_TEG EVUS_VASTUS

DW_SKAIS2. AE_HINNANG_TEG EVUS_VASTUS

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. AE_HINNANG_VAL DKOND

DW_SKAIS2. AE_HINNANG_VAL DKOND

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. AE_HINNANG_YTL US

DW_SKAIS2. AE_HINNANG_YTL US

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. AE_LEPING_PUUD UMINE

DW_SKAIS2. AE_LEPING_PUUD UMINE

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

DW_SKAIS2. AE_LEPING_TOO

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

DW_SKAIS2. AE_PIKK_TEKST

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

DW_SKAIS2. AE_TEHTUD_TOO

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

DW_SKAIS2. AE_TOO_LIIK

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

DW_SKAIS2. AE_TOO_LIIK_HIND

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. AK_AKTSEPTEERI MINE

DW_SKAIS2. AK_AKTSEPTEERI MINE

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.AR_ARVE DW_SKAIS2. AR_ARVE

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. AR_ARVESTUS_MU UDATUS

DW_SKAIS2. AR_ARVESTUS_MU UDATUS

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

DW_SKAIS2. AR_ARVE_RIDA

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. AR_FINANTS_SYN DMUS

DW_SKAIS2. AR_FINANTS_SYND MUS

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

DW_SKAIS2. AR_KATUSNOUE

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. AR_KINNIPEETUD_ SUMMA

DW_SKAIS2. AR_KINNIPEETUD_ SUMMA

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

DW_SKAIS2. AR_KINNIPIDAMINE

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. AR_KINNIPIDAMIN E_DOKUMENT

DW_SKAIS2. AR_KINNIPIDAMINE _DOKUMENT

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. AR_KINNIPIDAMIN E_HYVITIS

DW_SKAIS2. AR_KINNIPIDAMINE _HYVITIS

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. AR_KINNIPIDAMIN E_HYV_REEGEL

DW_SKAIS2. AR_KINNIPIDAMINE _HYV_REEGEL

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. AR_KINNIPIDAMIN E_ISIK

DW_SKAIS2. AR_KINNIPIDAMINE _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. AR_KINNIPIDAMIN E_OLEK

DW_SKAIS2. AR_KINNIPIDAMINE _OLEK

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. AR_KINNIPIDAMIN E_REEGEL

DW_SKAIS2. AR_KINNIPIDAMINE _REEGEL

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. AR_KINNIPIDAMIN E_REEGEL_DOK

DW_SKAIS2. AR_KINNIPIDAMINE _REEGEL_DOK

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. AR_KINNIPIDAMIN E_REEGEL_HYV

DW_SKAIS2. AR_KINNIPIDAMINE _REEGEL_HYV

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

DW_SKAIS2. AR_KOHUSTUS

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. AR_KOHUSTUS_M UUDATUS

DW_SKAIS2. AR_KOHUSTUS_M UUDATUS

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. AR_KOHUSTUS_TY HISTUS_VIGA

DW_SKAIS2. AR_KOHUSTUS_TY HISTUS_VIGA

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. AR_KOHU_NOUE_ SYNDMUS

DW_SKAIS2. AR_KOHU_NOUE_S YNDMUS

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. AR_KOHU_VALJAM AKSE

DW_SKAIS2. AR_KOHU_VALJAM AKSE

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

DW_SKAIS2. AR_MAKSEGRAAFIK

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. AR_MAKSEGRAAFI K_DOKUMENT

DW_SKAIS2. AR_MAKSEGRAAFI K_DOKUMENT

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. AR_MAKSEGRAAFI K_RIDA

DW_SKAIS2. AR_MAKSEGRAAFI K_RIDA

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. AR_MAKSEGRAAFI K_RIDA_LAEKUMINE

DW_SKAIS2. AR_MAKSEGRAAFI K_RIDA_LAEKUMINE

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

DW_SKAIS2. AR_MAKSEKANAL

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. AR_MAKSEKANAL_ REEGEL

DW_SKAIS2. AR_MAKSEKANAL_ REEGEL

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. AR_MAKSM_KOHU STUS

DW_SKAIS2. AR_MAKSM_KOHU STUS

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

DW_SKAIS2. AR_MAKSULEPING

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

DW_SKAIS2. AR_MITTERESIDENT

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. AR_MITTERES_MA KSULEPING_TOEND

DW_SKAIS2. AR_MITTERES_MA KSULEPING_TOEND

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. AR_MVT_PARING_I SIK

DW_SKAIS2. AR_MVT_PARING_I SIK

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

DW_SKAIS2. AR_MVT_SALDO

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

DW_SKAIS2. AR_MVT_SYNDMUS

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.AR_NOUE DW_SKAIS2. AR_NOUE

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. AR_NOUE_LAEKU MINE

DW_SKAIS2. AR_NOUE_LAEKUM INE

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

DW_SKAIS2. AR_PANGAKONTO

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.AR_PANK DW_SKAIS2. AR_PANK

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

DW_SKAIS2. AR_PANK_PYHA

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. AR_PARAMEETER_ HYVITIS

DW_SKAIS2. AR_PARAMEETER_ HYVITIS

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. AR_PROTSESS_VE ATEADE

DW_SKAIS2. AR_PROTSESS_VE ATEADE

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. AR_RAHALINE_TE HING

DW_SKAIS2. AR_RAHALINE_TEH ING

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

DW_SKAIS2. AR_REGRESSINOUE

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

DW_SKAIS2. AR_SAP_HANKIJA

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

DW_SKAIS2. AR_TAGASINOUE

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. AR_TAGASINOUE_ DOKUMENT

DW_SKAIS2. AR_TAGASINOUE_ DOKUMENT

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. AR_TAGASINOUE_ HYVITIS

DW_SKAIS2. AR_TAGASINOUE_ HYVITIS

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. AR_TAGASINOUE_I SIK

DW_SKAIS2. AR_TAGASINOUE_I SIK

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

DW_SKAIS2. AR_TSD_ESD_KP

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

DW_SKAIS2. AR_TSD_ESD_SM

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

DW_SKAIS2. AR_TSD_LISA_1A

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

DW_SKAIS2. AR_TSD_LISA_1B

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

DW_SKAIS2. AR_TSD_LISA_2A

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

DW_SKAIS2. AR_TSD_LISA_2B

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

DW_SKAIS2. AR_TSD_VORM

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

DW_SKAIS2. AR_TULUMAKS

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. AR_TULUMAKSUVA BASTUS

DW_SKAIS2. AR_TULUMAKSUVA BASTUS

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. AR_TULUMAKSUVA B_DOKUMENT

DW_SKAIS2. AR_TULUMAKSUVA B_DOKUMENT

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. AR_VAHEMAKSE_P AEV

DW_SKAIS2. AR_VAHEMAKSE_P AEV

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. AR_VEATEADE_OB JEKT

DW_SKAIS2. AR_VEATEADE_OB JEKT

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

DW_SKAIS2. DO_DOKUMENT

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. DO_DOKUMENT_F AIL

DW_SKAIS2. DO_DOKUMENT_F AIL

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. DO_DOKUMENT_O BJEKT

DW_SKAIS2. DO_DOKUMENT_O BJEKT

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. DO_DOKUMENT_S EOS

DW_SKAIS2. DO_DOKUMENT_S EOS

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. DO_DOKUMENT_S EOS_VALINE

DW_SKAIS2. DO_DOKUMENT_S EOS_VALINE

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. DO_DOKUMENT_T EENUS

DW_SKAIS2. DO_DOKUMENT_T EENUS

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.DO_KAART DW_SKAIS2. DO_KAART

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

DW_SKAIS2. DO_KYSIMUSTIK

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. DO_KYSIMUSTIK_K YSIMUS

DW_SKAIS2. DO_KYSIMUSTIK_K YSIMUS

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. DO_KYSIMUSTIK_V ASTUS

DW_SKAIS2. DO_KYSIMUSTIK_V ASTUS

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. DO_KYSIMUSTIK_V ASTUS_VALIK

DW_SKAIS2. DO_KYSIMUSTIK_V ASTUS_VALIK

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.DO_OTSUS DW_SKAIS2. DO_OTSUS

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

DW_SKAIS2. DO_OTSUS_ALUS

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

DW_SKAIS2. DO_PIKK_TEKST

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

DW_SKAIS2. DO_TAOTLUS

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. DO_TOOVOIMETUS LEHT

DW_SKAIS2. DO_TOOVOIMETUS LEHT

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

SKAIS_DOCUMENT _MANAGEMENT. DOCUMENT

DW_SKAIS_DOCUM ENT_MANAGEMEN T.DOCUMENT

LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_DOCUMENT _MANAGEMENT. DOCUMENT_BASIS

DW_SKAIS_DOCUM ENT_MANAGEMEN T. DOCUMENT_BASIS

LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_DOCUMENT _MANAGEMENT. DOCUMENT_DOMA IN

DW_SKAIS_DOCUM ENT_MANAGEMEN T. DOCUMENT_DOMA IN

LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_DOCUMENT _MANAGEMENT. DOCUMENT_FILE

DW_SKAIS_DOCUM ENT_MANAGEMEN T.DOCUMENT_FILE

LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_DOCUMENT _MANAGEMENT. DOCUMENT_PERS ON

DW_SKAIS_DOCUM ENT_MANAGEMEN T. DOCUMENT_PERS ON

LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_DOCUMENT _MANAGEMENT. LOG_DOCUMENT

DW_SKAIS_DOCUM ENT_MANAGEMEN T.LOG_DOCUMENT

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_DOCUMENT _MANAGEMENT. LOG_DOCUMENT_ BASIS

DW_SKAIS_DOCUM ENT_MANAGEMEN T. LOG_DOCUMENT_ BASIS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_DOCUMENT _MANAGEMENT. LOG_DOCUMENT_ DOMAIN

DW_SKAIS_DOCUM ENT_MANAGEMEN T. LOG_DOCUMENT_ DOMAIN

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_DOCUMENT _MANAGEMENT. LOG_DOCUMENT_ FILE

DW_SKAIS_DOCUM ENT_MANAGEMEN T. LOG_DOCUMENT_ FILE

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_DOCUMENT _MANAGEMENT. LOG_DOCUMENT_ PERSON

DW_SKAIS_DOCUM ENT_MANAGEMEN T. LOG_DOCUMENT_ PERSON

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS2. ERI_TOOTASU_HY VITAMINE

DW_SKAIS2. ERI_TOOTASU_HY VITAMINE

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. ERI_TOOTASU_HY VI_LAPS

DW_SKAIS2. ERI_TOOTASU_HY VI_LAPS

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. ERP_S_RAHALINE_ TEHING

DW_SKAIS2. ERP_S_RAHALINE_ TEHING

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. ERP_S_RAHALINE_ TEHING_VIGA

DW_SKAIS2. ERP_S_RAHALINE_ TEHING_VIGA

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. ERP_V_KOHUSTUS _SYNDMUS

DW_SKAIS2. ERP_V_KOHUSTUS _SYNDMUS

LOAD_MODIFIED (case when to_timestamp(MUUTM_AEG) < DATE '1900-01-01' then DATE '1900-01-01' else to_timestamp(MUUTM_AEG) end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS2. ERP_V_NOUE_SYN DMUS

DW_SKAIS2. ERP_V_NOUE_SYN DMUS

LOAD_MODIFIED (case when to_timestamp(MUUTM_AEG) < DATE '1900-01-01' then DATE '1900-01-01' else to_timestamp(MUUTM_AEG) end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS2. HY_HYVITIS

DW_SKAIS2. HY_HYVITIS

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. HY_HYVITIS_DOKU MENT

DW_SKAIS2. HY_HYVITIS_DOKU MENT

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

DW_SKAIS2. HY_HYVITIS_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. HY_HYVITIS_ISIK_ KITSENDUS

DW_SKAIS2. HY_HYVITIS_ISIK_K ITSENDUS

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. HY_HYVITIS_RAHA LINE

DW_SKAIS2. HY_HYVITIS_RAHA LINE

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. HY_HYVITIS_TEEN US

DW_SKAIS2. HY_HYVITIS_TEEN US

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

DW_SKAIS2. HY_MENETLUS

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. HY_MENETLUS_DO KUMENT

DW_SKAIS2. HY_MENETLUS_DO KUMENT

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. HY_MENETLUS_HY VITIS_OLEK

DW_SKAIS2. HY_MENETLUS_HY VITIS_OLEK

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

DW_SKAIS2. HY_MENETLUS_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. HY_MENETLUS_SA MM

DW_SKAIS2. HY_MENETLUS_SA MM

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. HY_MENETLUS_SA MM_OLEK

DW_SKAIS2. HY_MENETLUS_SA MM_OLEK

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

DW_SKAIS2. IS_AMETNIK

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

DW_SKAIS2. IS_EEMALOLEK

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

DW_SKAIS2. IS_ISIK_AADRESS

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

DW_SKAIS2. IS_ISIK_DOKUMENT

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. IS_ISIK_KODAKON DSUS

DW_SKAIS2. IS_ISIK_KODAKON DSUS

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

DW_SKAIS2. IS_ISIK_NOUSOLEK

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

DW_SKAIS2. IS_ISIK_OLEK

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

DW_SKAIS2. IS_ISIK_SEOS

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. IS_ISIK_SEOS_DO KUMENT

DW_SKAIS2. IS_ISIK_SEOS_DOK UMENT

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

DW_SKAIS2. IS_ISIK_TEOVOIME

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

DW_SKAIS2. IS_KINNIPIDAMINE

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. IS_KOGUMISPENSI ON

DW_SKAIS2. IS_KOGUMISPENSI ON

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

DW_SKAIS2. IS_KONTAKT

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. IS_MUU_IDENTITE ET

DW_SKAIS2. IS_MUU_IDENTITEET

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

DW_SKAIS2. IS_NOUSOLEK

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. IS_NOUSOLEK_DO KUMENT

DW_SKAIS2. IS_NOUSOLEK_DO KUMENT

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

DW_SKAIS2. IS_OPPIMINE

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

DW_SKAIS2. IS_OPPIMINE_OLEK

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

DW_SKAIS2. IS_POORDUMINE

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. IS_POORDUMINE_ DOKUMENT

DW_SKAIS2. IS_POORDUMINE_ DOKUMENT

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

DW_SKAIS2. IS_PUUDUMINE

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

DW_SKAIS2. IS_STAATUS

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. IS_STAATUS_DOK UMENT

DW_SKAIS2. IS_STAATUS_DOKU MENT

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

DW_SKAIS2. IS_TEAVITUS

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

DW_SKAIS2. IS_TEAVITUS_OLEK

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

DW_SKAIS2. IS_TOOVOIME

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

DW_SKAIS2. IS_TULU_ALUS

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. IS_TULU_DOKUME NT

DW_SKAIS2. IS_TULU_DOKUME NT

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

DW_SKAIS2. IS_VOLITUS

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. IS_VOLITUS_DOKU MENT

DW_SKAIS2. IS_VOLITUS_DOKU MENT

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. KA_KASUTAJA_RO LL_PRIVILEEG

DW_SKAIS2. KA_KASUTAJA_RO LL_PRIVILEEG

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.KA_SEOS DW_SKAIS2. KA_SEOS

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

DW_SKAIS2. KA_TOKEN_LUBA

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. KA_TOKEN_SAADE TUD

DW_SKAIS2. KA_TOKEN_SAADE TUD

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

DW_SKAIS2. KL_ELEMENT

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

DW_SKAIS2. KL_ELEMENT_SEOS

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. KL_ELEMENT_TEK ST

DW_SKAIS2. KL_ELEMENT_TEK ST

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. KL_KLASSIFIKAAT OR

DW_SKAIS2. KL_KLASSIFIKAAT OR

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

DW_SKAIS2. LOG_AD_AADRESS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AE_ARST_SP ETSIALIST

DW_SKAIS2. LOG_AE_ARST_SP ETSIALIST

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AE_ARST_SP ETSIALIST_DOKUME

DW_SKAIS2. LOG_AE_ARST_SP ETSIALIST_DOKUME

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AE_EKSPERT ARST_LEPING

DW_SKAIS2. LOG_AE_EKSPERT ARST_LEPING

LOAD_MODIFIED_ WOID

(DOKUMENT_ID,LOG_LISAM_AEG) in (select DOKUMENT_ID, max(LOG_LISAM_AEG) from SKAIS2.LOG_AE_EKSPERTARST_LEPING where DOKUMENT_ID in (select DOKUMENT_ID 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. LOG_AE_ERIALA

DW_SKAIS2. LOG_AE_ERIALA

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AE_HINDAMI NE_TEGEVUS

DW_SKAIS2. LOG_AE_HINDAMIN E_TEGEVUS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AE_HINDAMI NE_TEGEVUS_KYS IM

DW_SKAIS2. LOG_AE_HINDAMIN E_TEGEVUS_KYSIM

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AE_HINDAMI NE_VALDKOND

DW_SKAIS2. LOG_AE_HINDAMIN E_VALDKOND

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AE_HINDAMI NE_VALDKOND_TA SE

DW_SKAIS2. LOG_AE_HINDAMIN E_VALDKOND_TASE

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AE_HINNANG

DW_SKAIS2. LOG_AE_HINNANG

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AE_HINNANG _DIAGNOOS

DW_SKAIS2. LOG_AE_HINNANG _DIAGNOOS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AE_HINNANG _MOJUTATUD

DW_SKAIS2. LOG_AE_HINNANG _MOJUTATUD

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AE_HINNANG _OLEK

DW_SKAIS2. LOG_AE_HINNANG _OLEK

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AE_HINNANG _TEGEVUS

DW_SKAIS2. LOG_AE_HINNANG _TEGEVUS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AE_HINNANG _TEGEVUS_VASTUS

DW_SKAIS2. LOG_AE_HINNANG _TEGEVUS_VASTUS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AE_HINNANG _VALDKOND

DW_SKAIS2. LOG_AE_HINNANG _VALDKOND

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AE_HINNANG _YTLUS

DW_SKAIS2. LOG_AE_HINNANG _YTLUS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AE_LEPING_ PUUDUMINE

DW_SKAIS2. LOG_AE_LEPING_P UUDUMINE

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AE_LEPING_T OO

DW_SKAIS2. LOG_AE_LEPING_T OO

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AE_PIKK_TEK ST

DW_SKAIS2. LOG_AE_PIKK_TEK ST

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AE_TEHTUD_ TOO

DW_SKAIS2. LOG_AE_TEHTUD_ TOO

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AE_TOO_LIIK

DW_SKAIS2. LOG_AE_TOO_LIIK

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AE_TOO_LIIK _HIND

DW_SKAIS2. LOG_AE_TOO_LIIK _HIND

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AK_AKTSEPT EERIMINE

DW_SKAIS2. LOG_AK_AKTSEPT EERIMINE

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_ARVE

DW_SKAIS2. LOG_AR_ARVE

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_ARVESTU S_MUUDATUS

DW_SKAIS2. LOG_AR_ARVESTU S_MUUDATUS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_ARVE_RI DA

DW_SKAIS2. LOG_AR_ARVE_RI DA

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_FINANTS _SYNDMUS

DW_SKAIS2. LOG_AR_FINANTS_ SYNDMUS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_KATUSN OUE

DW_SKAIS2. LOG_AR_KATUSNO UE

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_KINNIPEE TUD_SUMMA

DW_SKAIS2. LOG_AR_KINNIPEE TUD_SUMMA

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_KINNIPID AMINE

DW_SKAIS2. LOG_AR_KINNIPID AMINE

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_KINNIPID AMINE_DOKUMENT

DW_SKAIS2. LOG_AR_KINNIPID AMINE_DOKUMENT

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_KINNIPID AMINE_HYVITIS

DW_SKAIS2. LOG_AR_KINNIPID AMINE_HYVITIS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_KINNIPID AMINE_HYV_REEGE

DW_SKAIS2. LOG_AR_KINNIPID AMINE_HYV_REEGE

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_KINNIPID AMINE_ISIK

DW_SKAIS2. LOG_AR_KINNIPID AMINE_ISIK

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_KINNIPID AMINE_OLEK

DW_SKAIS2. LOG_AR_KINNIPID AMINE_OLEK

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_KINNIPID AMINE_REEGEL

DW_SKAIS2. LOG_AR_KINNIPID AMINE_REEGEL

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_KINNIPID AMINE_REEGEL_DO

DW_SKAIS2. LOG_AR_KINNIPID AMINE_REEGEL_DO

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_KINNIPID AMINE_REEGEL_HY

DW_SKAIS2. LOG_AR_KINNIPID AMINE_REEGEL_HY

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_KOHUST US

DW_SKAIS2. LOG_AR_KOHUSTUS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_KOHUST US_MUUDATUS

DW_SKAIS2. LOG_AR_KOHUSTU S_MUUDATUS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_KOHUST US_TYHISTUS_VIGA

DW_SKAIS2. LOG_AR_KOHUSTU S_TYHISTUS_VIGA

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_KOHU_N OUE_SYNDMUS

DW_SKAIS2. LOG_AR_KOHU_NO UE_SYNDMUS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_KOHU_VA LJAMAKSE

DW_SKAIS2. LOG_AR_KOHU_VA LJAMAKSE

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_MAKSEG RAAFIK

DW_SKAIS2. LOG_AR_MAKSEG RAAFIK

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_MAKSEG RAAFIK_DOKUMENT

DW_SKAIS2. LOG_AR_MAKSEG RAAFIK_DOKUMENT

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_MAKSEG RAAFIK_RIDA

DW_SKAIS2. LOG_AR_MAKSEG RAAFIK_RIDA

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_MAKSEG RAAFIK_RIDA_LAE KU

DW_SKAIS2. LOG_AR_MAKSEG RAAFIK_RIDA_LAE KU

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_MAKSEK ANAL

DW_SKAIS2. LOG_AR_MAKSEKA NAL

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_MAKSEK ANAL_REEGEL

DW_SKAIS2. LOG_AR_MAKSEKA NAL_REEGEL

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_MAKSM_ KOHUSTUS

DW_SKAIS2. LOG_AR_MAKSM_K OHUSTUS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_MAKSULE PING

DW_SKAIS2. LOG_AR_MAKSULE PING

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_MITTERE SIDENT

DW_SKAIS2. LOG_AR_MITTERE SIDENT

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_MITTERE S_MAKSULEPING_ TO

DW_SKAIS2. LOG_AR_MITTERE S_MAKSULEPING_ TO

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_MVT_PAR ING_ISIK

DW_SKAIS2. LOG_AR_MVT_PAR ING_ISIK

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_MVT_SAL DO

DW_SKAIS2. LOG_AR_MVT_SAL DO

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_MVT_SYN DMUS

DW_SKAIS2. LOG_AR_MVT_SYN DMUS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_NOUE

DW_SKAIS2. LOG_AR_NOUE

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_NOUE_LA EKUMINE

DW_SKAIS2. LOG_AR_NOUE_LA EKUMINE

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_PANGAK ONTO

DW_SKAIS2. LOG_AR_PANGAK ONTO

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_PANK

DW_SKAIS2. LOG_AR_PANK

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_PANK_PY HA

DW_SKAIS2. LOG_AR_PANK_PY HA

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_PARAME ETER_HYVITIS

DW_SKAIS2. LOG_AR_PARAMEE TER_HYVITIS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_PROTSES S_VEATEADE

DW_SKAIS2. LOG_AR_PROTSES S_VEATEADE

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_RAHALIN E_TEHING

DW_SKAIS2. LOG_AR_RAHALIN E_TEHING

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_REGRES SINOUE

DW_SKAIS2. LOG_AR_REGRESS INOUE

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_SAP_HAN KIJA

DW_SKAIS2. LOG_AR_SAP_HAN KIJA

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_SAP_VEA TEADE

DW_SKAIS2. LOG_AR_SAP_VEA TEADE

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_TAGASIN OUE

DW_SKAIS2. LOG_AR_TAGASIN OUE

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_TAGASIN OUE_DOKUMENT

DW_SKAIS2. LOG_AR_TAGASIN OUE_DOKUMENT

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_TAGASIN OUE_HYVITIS

DW_SKAIS2. LOG_AR_TAGASIN OUE_HYVITIS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_TAGASIN OUE_ISIK

DW_SKAIS2. LOG_AR_TAGASIN OUE_ISIK

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_TSD_ESD _KP

DW_SKAIS2. LOG_AR_TSD_ESD _KP

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_TSD_ESD _SM

DW_SKAIS2. LOG_AR_TSD_ESD _SM

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_TSD_LISA _1A

DW_SKAIS2. LOG_AR_TSD_LISA _1A

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_TSD_LISA _1B

DW_SKAIS2. LOG_AR_TSD_LISA _1B

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_TSD_LISA _2A

DW_SKAIS2. LOG_AR_TSD_LISA _2A

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_TSD_LISA _2B

DW_SKAIS2. LOG_AR_TSD_LISA _2B

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_TSD_VORM

DW_SKAIS2. LOG_AR_TSD_VORM

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_TULUMAKS

DW_SKAIS2. LOG_AR_TULUMAKS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_TULUMAK SUVABASTUS

DW_SKAIS2. LOG_AR_TULUMAK SUVABASTUS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_TULUMAK SUVAB_DOKUMENT

DW_SKAIS2. LOG_AR_TULUMAK SUVAB_DOKUMENT

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_VAHEMA KSE_PAEV

DW_SKAIS2. LOG_AR_VAHEMAK SE_PAEV

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_AR_VEATEAD E_OBJEKT

DW_SKAIS2. LOG_AR_VEATEAD E_OBJEKT

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_DO_DOKUME NT

DW_SKAIS2. LOG_DO_DOKUME NT

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_DO_DOKUME NT_FAIL

DW_SKAIS2. LOG_DO_DOKUME NT_FAIL

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_DO_DOKUME NT_OBJEKT

DW_SKAIS2. LOG_DO_DOKUME NT_OBJEKT

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_DO_DOKUME NT_SEOS

DW_SKAIS2. LOG_DO_DOKUME NT_SEOS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_DO_DOKUME NT_SEOS_VALINE

DW_SKAIS2. LOG_DO_DOKUME NT_SEOS_VALINE

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_DO_DOKUME NT_TEENUS

DW_SKAIS2. LOG_DO_DOKUME NT_TEENUS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_DO_KAART

DW_SKAIS2. LOG_DO_KAART

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_DO_KYSIMUS TIK

DW_SKAIS2. LOG_DO_KYSIMUS TIK

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_DO_KYSIMUS TIK_KYSIMUS

DW_SKAIS2. LOG_DO_KYSIMUS TIK_KYSIMUS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_DO_KYSIMUS TIK_VASTUS

DW_SKAIS2. LOG_DO_KYSIMUS TIK_VASTUS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_DO_KYSIMUS TIK_VASTUS_VALIK

DW_SKAIS2. LOG_DO_KYSIMUS TIK_VASTUS_VALIK

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_DO_OTSUS

DW_SKAIS2. LOG_DO_OTSUS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_DO_OTSUS_A LUS

DW_SKAIS2. LOG_DO_OTSUS_A LUS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_DO_PIKK_TE KST

DW_SKAIS2. LOG_DO_PIKK_TEK ST

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_DO_TAOTLUS

DW_SKAIS2. LOG_DO_TAOTLUS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_DO_TOOVOI METUSLEHT

DW_SKAIS2. LOG_DO_TOOVOIM ETUSLEHT

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_ERI_TOOTAS U_HYVITAMINE

DW_SKAIS2. LOG_ERI_TOOTAS U_HYVITAMINE

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_ERI_TOOTAS U_HYVI_LAPS

DW_SKAIS2. LOG_ERI_TOOTAS U_HYVI_LAPS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_ERP_S_RAHA LINE_TEHING

DW_SKAIS2. LOG_ERP_S_RAHA LINE_TEHING

LOAD_MODIFIED_ WOID

(ERP_TEHING_ID,LOG_LISAM_AEG) in (select ERP_TEHING_ID, max(LOG_LISAM_AEG) from SKAIS2.LOG_ERP_S_RAHALINE_TEHING where ERP_TEHING_ID in (select ERP_TEHING_ID 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. LOG_ERP_S_RAHA LINE_TEHING_VIGA

DW_SKAIS2. LOG_ERP_S_RAHA LINE_TEHING_VIGA

LOAD_MODIFIED_ WOID

(ERP_VIGA_ID,LOG_LISAM_AEG) in (select ERP_VIGA_ID, max(LOG_LISAM_AEG) from SKAIS2.LOG_ERP_S_RAHALINE_TEHING_VIGA where ERP_VIGA_ID in (select ERP_VIGA_ID 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. LOG_ERP_V_KOHU STUS_SYNDMUS

DW_SKAIS2. LOG_ERP_V_KOHU STUS_SYNDMUS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_ERP_V_NOUE _SYNDMUS

DW_SKAIS2. LOG_ERP_V_NOUE _SYNDMUS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_HY_HYVITIS

DW_SKAIS2. LOG_HY_HYVITIS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_HY_HYVITIS_ DOKUMENT

DW_SKAIS2. LOG_HY_HYVITIS_ DOKUMENT

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_HY_HYVITIS_I SIK

DW_SKAIS2. LOG_HY_HYVITIS_I SIK

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_HY_HYVITIS_I SIK_KITSENDUS

DW_SKAIS2. LOG_HY_HYVITIS_I SIK_KITSENDUS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_HY_HYVITIS_ RAHALINE

DW_SKAIS2. LOG_HY_HYVITIS_ RAHALINE

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_HY_HYVITIS_ TEENUS

DW_SKAIS2. LOG_HY_HYVITIS_ TEENUS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_HY_MENETLUS

DW_SKAIS2. LOG_HY_MENETLUS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_HY_MENETLU S_DOKUMENT

DW_SKAIS2. LOG_HY_MENETLU S_DOKUMENT

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_HY_MENETLU S_HYVITIS_OLEK

DW_SKAIS2. LOG_HY_MENETLU S_HYVITIS_OLEK

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_HY_MENETLU S_ISIK

DW_SKAIS2. LOG_HY_MENETLU S_ISIK

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_HY_MENETLU S_SAMM

DW_SKAIS2. LOG_HY_MENETLU S_SAMM

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_HY_MENETLU S_SAMM_OLEK

DW_SKAIS2. LOG_HY_MENETLU S_SAMM_OLEK

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_IS_AMETNIK

DW_SKAIS2. LOG_IS_AMETNIK

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_IS_EEMALOL EK

DW_SKAIS2. LOG_IS_EEMALOL EK

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_IS_ISIK

DW_SKAIS2. LOG_IS_ISIK

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_IS_ISIK_AADR ESS

DW_SKAIS2. LOG_IS_ISIK_AADR ESS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_IS_ISIK_DOK UMENT

DW_SKAIS2. LOG_IS_ISIK_DOKU MENT

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_IS_ISIK_KOD AKONDSUS

DW_SKAIS2. LOG_IS_ISIK_KODA KONDSUS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_IS_ISIK_NOU SOLEK

DW_SKAIS2. LOG_IS_ISIK_NOUS OLEK

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_IS_ISIK_OLEK

DW_SKAIS2. LOG_IS_ISIK_OLEK

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_IS_ISIK_SEOS

DW_SKAIS2. LOG_IS_ISIK_SEOS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_IS_ISIK_SEOS _DOKUMENT

DW_SKAIS2. LOG_IS_ISIK_SEOS _DOKUMENT

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_IS_ISIK_TEOV OIME

DW_SKAIS2. LOG_IS_ISIK_TEOV OIME

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_IS_KINNIPIDA MINE

DW_SKAIS2. LOG_IS_KINNIPIDA MINE

LOAD_MODIFIED_ WOID

(STAATUS_ID,LOG_LISAM_AEG) in (select STAATUS_ID, max(LOG_LISAM_AEG) from SKAIS2. LOG_IS_KINNIPIDAMINE where STAATUS_ID in (select STAATUS_ID from SKAIS2. 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. LOG_IS_KOGUMIS PENSION

DW_SKAIS2. LOG_IS_KOGUMIS PENSION

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_IS_KONTAKT

DW_SKAIS2. LOG_IS_KONTAKT

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_IS_MUU_IDEN TITEET

DW_SKAIS2. LOG_IS_MUU_IDEN TITEET

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_IS_NOUSOLEK

DW_SKAIS2. LOG_IS_NOUSOLEK

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_IS_NOUSOLE K_DOKUMENT

DW_SKAIS2. LOG_IS_NOUSOLE K_DOKUMENT

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_IS_OPPIMINE

DW_SKAIS2. LOG_IS_OPPIMINE

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_IS_OPPIMINE _OLEK

DW_SKAIS2. LOG_IS_OPPIMINE _OLEK

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_IS_POORDUM INE

DW_SKAIS2. LOG_IS_POORDUM INE

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_IS_POORDUM INE_DOKUMENT

DW_SKAIS2. LOG_IS_POORDUM INE_DOKUMENT

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_IS_PUUDUMI NE

DW_SKAIS2. LOG_IS_PUUDUMINE

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_IS_STAATUS

DW_SKAIS2. LOG_IS_STAATUS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_IS_STAATUS_ DOKUMENT

DW_SKAIS2. LOG_IS_STAATUS_ DOKUMENT

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_IS_TEAVITUS

DW_SKAIS2. LOG_IS_TEAVITUS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_IS_TEAVITUS _OLEK

DW_SKAIS2. LOG_IS_TEAVITUS _OLEK

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_IS_TOOVOIME

DW_SKAIS2. LOG_IS_TOOVOIME

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_IS_TULU_ALUS

DW_SKAIS2. LOG_IS_TULU_ALUS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_IS_TULU_DO KUMENT

DW_SKAIS2. LOG_IS_TULU_DOK UMENT

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_IS_VOLITUS

DW_SKAIS2. LOG_IS_VOLITUS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_IS_VOLITUS_ DOKUMENT

DW_SKAIS2. LOG_IS_VOLITUS_ DOKUMENT

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_KA_KASUTAJ A_ROLL_PRIVILEEG

DW_SKAIS2. LOG_KA_KASUTAJ A_ROLL_PRIVILEEG

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_KA_SEOS

DW_SKAIS2. LOG_KA_SEOS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_KA_TOKEN_L UBA

DW_SKAIS2. LOG_KA_TOKEN_L UBA

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_KA_TOKEN_S AADETUD

DW_SKAIS2. LOG_KA_TOKEN_S AADETUD

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_KL_ELEMENT

DW_SKAIS2. LOG_KL_ELEMENT

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_KL_ELEMENT _SEOS

DW_SKAIS2. LOG_KL_ELEMENT _SEOS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_KL_ELEMENT _TEKST

DW_SKAIS2. LOG_KL_ELEMENT _TEKST

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_KL_KLASSIFI KAATOR

DW_SKAIS2. LOG_KL_KLASSIFIK AATOR

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_LX_LIIDES_V AARTUS_VASTAVUS

DW_SKAIS2. LOG_LX_LIIDES_VA ARTUS_VASTAVUS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_MT_MALL

DW_SKAIS2. LOG_MT_MALL

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_MT_MALL_TE KST

DW_SKAIS2. LOG_MT_MALL_TE KST

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_PA_PARAME ETER

DW_SKAIS2. LOG_PA_PARAMEE TER

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_PA_VAARTUS

DW_SKAIS2. LOG_PA_VAARTUS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_PA_VAARTUS _M

DW_SKAIS2. LOG_PA_VAARTUS _M

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_PE_MUU_PE NSION

DW_SKAIS2. LOG_PE_MUU_PEN SION

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_PE_MUU_PE NSION_DOKUMENT

DW_SKAIS2. LOG_PE_MUU_PEN SION_DOKUMENT

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_PE_PENSIONI LISA

DW_SKAIS2. LOG_PE_PENSIONI LISA

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_PE_PENSIONI LISA_DOKUMENT

DW_SKAIS2. LOG_PE_PENSIONI LISA_DOKUMENT

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_PE_PENSIONI LISA_ISIK

DW_SKAIS2. LOG_PE_PENSIONI LISA_ISIK

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_PE_SOODUS TUS

DW_SKAIS2. LOG_PE_SOODUST US

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_PE_SOODUS TUS_DOKUMENT

DW_SKAIS2. LOG_PE_SOODUST US_DOKUMENT

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_PE_SOODUS TUS_ISIK

DW_SKAIS2. LOG_PE_SOODUST US_ISIK

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_PE_STAAZ

DW_SKAIS2. LOG_PE_STAAZ

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_PE_STAAZ_A RVUTATUD

DW_SKAIS2. LOG_PE_STAAZ_A RVUTATUD

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_PE_STAAZ_D OKUMENT

DW_SKAIS2. LOG_PE_STAAZ_D OKUMENT

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_PE_STAAZ_IS IK

DW_SKAIS2. LOG_PE_STAAZ_IS IK

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_PE_STAAZ_RI DA

DW_SKAIS2. LOG_PE_STAAZ_RI DA

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_SM_EMTA_S OTSMAKS

DW_SKAIS2. LOG_SM_EMTA_SO TSMAKS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_SM_SOTSMA KS_AASTA

DW_SKAIS2. LOG_SM_SOTSMA KS_AASTA

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_SM_SOTSMA KS_AASTA_RIDA

DW_SKAIS2. LOG_SM_SOTSMA KS_AASTA_RIDA

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_SM_SOTSMA KS_ISIKUSTATUD

DW_SKAIS2. LOG_SM_SOTSMA KS_ISIKUSTATUD

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_SM_SOTSMA KS_ISIKUSTATUD_ EM

DW_SKAIS2. LOG_SM_SOTSMA KS_ISIKUSTATUD_ EM

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_SM_SOTSMA KS_LIIK_REEGEL

DW_SKAIS2. LOG_SM_SOTSMA KS_LIIK_REEGEL

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_SM_SOTSMA KS_SKEEM

DW_SKAIS2. LOG_SM_SOTSMA KS_SKEEM

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_SY_SEDEL

DW_SKAIS2. LOG_SY_SEDEL

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_SY_SEDEL_T EKST

DW_SKAIS2. LOG_SY_SEDEL_T EKST

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_SY_TEADE

DW_SKAIS2. LOG_SY_TEADE

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_TE_TEENUS

DW_SKAIS2. LOG_TE_TEENUS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_TE_TEENUS_ OSUTAMINE

DW_SKAIS2. LOG_TE_TEENUS_ OSUTAMINE

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_TM_MAATRIKS

DW_SKAIS2. LOG_TM_MAATRIKS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_TM_MAATRIK S_TINGIMUS

DW_SKAIS2. LOG_TM_MAATRIK S_TINGIMUS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_TM_TINGIMU S_ALUS

DW_SKAIS2. LOG_TM_TINGIMUS _ALUS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_TM_TINGIMU S_KONTEKST

DW_SKAIS2. LOG_TM_TINGIMUS _KONTEKST

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_TM_TINGIMU S_RIDA

DW_SKAIS2. LOG_TM_TINGIMUS _RIDA

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_TM_TINGIMU S_VARIANT

DW_SKAIS2. LOG_TM_TINGIMUS _VARIANT

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_TM_TINGIMU S_VEERG

DW_SKAIS2. LOG_TM_TINGIMUS _VEERG

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_TRY_TRYKIS

DW_SKAIS2. LOG_TRY_TRYKIS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_TRY_TRYKIS_ ELEMENT

DW_SKAIS2. LOG_TRY_TRYKIS_ ELEMENT

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_TRY_TRYKIS_ NOUE_REEGEL

DW_SKAIS2. LOG_TRY_TRYKIS_ NOUE_REEGEL

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_TRY_TRYKIS_ REEGEL

DW_SKAIS2. LOG_TRY_TRYKIS_ REEGEL

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_TR_PEATAMI NE

DW_SKAIS2. LOG_TR_PEATAMI NE

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_TR_TOOTAMI NE

DW_SKAIS2. LOG_TR_TOOTAMI NE

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_YL_YLESANNE

DW_SKAIS2. LOG_YL_YLESANNE

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_YL_YLESANN E_DOKUMENT

DW_SKAIS2. LOG_YL_YLESANN E_DOKUMENT

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_YL_YLESANN E_ISIK

DW_SKAIS2. LOG_YL_YLESANN E_ISIK

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_YL_YLESANN E_LIIK

DW_SKAIS2. LOG_YL_YLESANN E_LIIK

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_YL_YLESANN E_LIIK_ROLL

DW_SKAIS2. LOG_YL_YLESANN E_LIIK_ROLL

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_YL_YLESANN E_OLEK

DW_SKAIS2. LOG_YL_YLESANN E_OLEK

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LOG_YL_YLESANN E_SEOS

DW_SKAIS2. LOG_YL_YLESANN E_SEOS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_LISAM_AEG >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm- dd hh24:mi:ss')

SKAIS2. LX_LIIDES_VAART US_VASTAVUS

DW_SKAIS2. LX_LIIDES_VAART US_VASTAVUS

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.MT_MALL DW_SKAIS2. MT_MALL

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

DW_SKAIS2. MT_MALL_TEKST

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

DW_SKAIS2. PA_PARAMEETER

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

DW_SKAIS2. PA_VAARTUS

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

DW_SKAIS2. PA_VAARTUS_M

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

DW_SKAIS2. PE_MUU_PENSION

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. PE_MUU_PENSION _DOKUMENT

DW_SKAIS2. PE_MUU_PENSION _DOKUMENT

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

DW_SKAIS2. PE_PENSIONILISA

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. PE_PENSIONILISA_ DOKUMENT

DW_SKAIS2. PE_PENSIONILISA_ DOKUMENT

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. PE_PENSIONILISA_ ISIK

DW_SKAIS2. PE_PENSIONILISA_ 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. PE_SOODUSTUS

DW_SKAIS2. PE_SOODUSTUS

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. PE_SOODUSTUS_ DOKUMENT

DW_SKAIS2. PE_SOODUSTUS_D OKUMENT

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. PE_SOODUSTUS_I SIK

DW_SKAIS2. PE_SOODUSTUS_I SIK

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.PE_STAAZ DW_SKAIS2. PE_STAAZ

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. PE_STAAZ_ARVUT ATUD

DW_SKAIS2. PE_STAAZ_ARVUT ATUD

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. PE_STAAZ_DOKUM ENT

DW_SKAIS2. PE_STAAZ_DOKUM ENT

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

DW_SKAIS2. PE_STAAZ_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. PE_STAAZ_RIDA

DW_SKAIS2. PE_STAAZ_RIDA

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. SM_EMTA_SOTSM AKS

DW_SKAIS2. SM_EMTA_SOTSM AKS

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. SM_SOTSMAKS_A ASTA

DW_SKAIS2. SM_SOTSMAKS_AA STA

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. SM_SOTSMAKS_A ASTA_RIDA

DW_SKAIS2. SM_SOTSMAKS_AA STA_RIDA

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. SM_SOTSMAKS_ISI KUSTATUD

DW_SKAIS2. SM_SOTSMAKS_ISI KUSTATUD

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. SM_SOTSMAKS_ISI KUSTATUD_EMTA

DW_SKAIS2. SM_SOTSMAKS_ISI KUSTATUD_EMTA

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. SM_SOTSMAKS_LII K_REEGEL

DW_SKAIS2. SM_SOTSMAKS_LII K_REEGEL

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. SM_SOTSMAKS_S KEEM

DW_SKAIS2. SM_SOTSMAKS_SK EEM

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. SQLN_EXPLAIN_PL AN

DW_SKAIS2. SQLN_EXPLAIN_PL AN

REWRITE

SKAIS2.SY_SEDEL DW_SKAIS2. SY_SEDEL

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

DW_SKAIS2. SY_SEDEL_TEKST

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.SY_TEADE DW_SKAIS2. SY_TEADE

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

DW_SKAIS2. TE_TEENUS

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. TE_TEENUS_OSUT AMINE

DW_SKAIS2. TE_TEENUS_OSUT AMINE

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

DW_SKAIS2. TM_MAATRIKS

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. TM_MAATRIKS_TIN GIMUS

DW_SKAIS2. TM_MAATRIKS_TIN GIMUS

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

DW_SKAIS2. TM_TINGIMUS_ALUS

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. TM_TINGIMUS_KO NTEKST

DW_SKAIS2. TM_TINGIMUS_KO NTEKST

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

DW_SKAIS2. TM_TINGIMUS_RIDA

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. TM_TINGIMUS_VA RIANT

DW_SKAIS2. TM_TINGIMUS_VAR IANT

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. TM_TINGIMUS_VEE RG

DW_SKAIS2. TM_TINGIMUS_VEE RG

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

DW_SKAIS2. TRY_TRYKIS

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. TRY_TRYKIS_ELE MENT

DW_SKAIS2. TRY_TRYKIS_ELEM ENT

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. TRY_TRYKIS_NOU E_REEGEL

DW_SKAIS2. TRY_TRYKIS_NOU E_REEGEL

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. TRY_TRYKIS_REE GEL

DW_SKAIS2. TRY_TRYKIS_REEG EL

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

DW_SKAIS2. TR_PEATAMINE

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

DW_SKAIS2. TR_TOOTAMINE

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

DW_SKAIS2. YL_YLESANNE

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. YL_YLESANNE_DO KUMENT

DW_SKAIS2. YL_YLESANNE_DO KUMENT

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

DW_SKAIS2. YL_YLESANNE_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. YL_YLESANNE_LIIK

DW_SKAIS2. YL_YLESANNE_LIIK

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. YL_YLESANNE_LII K_ROLL

DW_SKAIS2. YL_YLESANNE_LIIK _ROLL

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. YL_YLESANNE_OL EK

DW_SKAIS2. YL_YLESANNE_OL EK

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. YL_YLESANNE_SE OS

DW_SKAIS2. YL_YLESANNE_SE OS

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

SKAIS_ISIK. INCOME_TAX_EXE MPTION

DW_SKAIS_ISIK. INCOME_TAX_EXE MPTION

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_ISIK. LOG_INCOME_TAX _EXEMPTION

DW_SKAIS_ISIK. LOG_INCOME_TAX _EXEMPTION

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_ISIK. LOG_REQUISITE

DW_SKAIS_ISIK. LOG_REQUISITE

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_ISIK. REQUISITE

DW_SKAIS_ISIK. REQUISITE

REWRITE

SKAIS_NOTIFICATI ON.LOG_MESSAGE

DW_SKAIS_NOTIFI CATION. LOG_MESSAGE

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_NOTIFICATI ON. LOG_MESSAGE_A TTACHMENT

DW_SKAIS_NOTIFI CATION. LOG_MESSAGE_AT TACHMENT

LOAD_MODIFIED_ WOID

LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_NOTIFICATI ON. LOG_MESSAGE_I1 8N

DW_SKAIS_NOTIFI CATION. LOG_MESSAGE_I1 8N

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_NOTIFICATI ON. LOG_MESSAGE_S UBJECT

DW_SKAIS_NOTIFI CATION. LOG_MESSAGE_S UBJECT

LOAD_MODIFIED_ WOID

LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_NOTIFICATI ON. LOG_NOTIFICATION

DW_SKAIS_NOTIFI CATION. LOG_NOTIFICATION

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_NOTIFICATI ON.MESSAGE

DW_SKAIS_NOTIFI CATION.MESSAGE

LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_NOTIFICATI ON. MESSAGE_ATTAC HMENT

DW_SKAIS_NOTIFI CATION. MESSAGE_ATTACH MENT

SKAIS_NOTIFICATI ON.MESSAGE_I18N

DW_SKAIS_NOTIFI CATION. MESSAGE_I18N

SKAIS_NOTIFICATI ON. MESSAGE_SUBJE CT

DW_SKAIS_NOTIFI CATION. MESSAGE_SUBJECT

REWRITE

SKAIS_NOTIFICATI ON.NOTIFICATION

DW_SKAIS_NOTIFI CATION. NOTIFICATION

LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_PAKKUMUS. COMBINED_OFFER ING

DW_SKAIS_PAKKU MUS. COMBINED_OFFER ING

LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_PAKKUMUS. COMBINED_OFFER ING_ATTACHMENT

DW_SKAIS_PAKKU MUS. COMBINED_OFFER ING_ATTACHMENT

LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_PAKKUMUS. LOG_COMBINED_O FFERING

DW_SKAIS_PAKKU MUS. LOG_COMBINED_O FFERING

LOAD_MODIFIED_ WOID

LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_PAKKUMUS. LOG_COMBINED_O FFERING_ATTACH ME

DW_SKAIS_PAKKU MUS. LOG_COMBINED_O FFERING_ATTACH ME

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_PAKKUMUS. LOG_OFFERING

DW_SKAIS_PAKKU MUS. LOG_OFFERING

LOAD_MODIFIED_ WOID

LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_PAKKUMUS. LOG_OFFERING_B ENEFIT

DW_SKAIS_PAKKU MUS. LOG_OFFERING_B ENEFIT

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_PAKKUMUS. LOG_OFFERING_G ROUP

DW_SKAIS_PAKKU MUS. LOG_OFFERING_G ROUP

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_PAKKUMUS. LOG_OFFERING_S UBJECT

DW_SKAIS_PAKKU MUS. LOG_OFFERING_S UBJECT

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_PAKKUMUS. LOG_OFFERING_S UBJECT_DETAIL

DW_SKAIS_PAKKU MUS. LOG_OFFERING_S UBJECT_DETAIL

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_PAKKUMUS. OFFERING

DW_SKAIS_PAKKU MUS.OFFERING

LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_PAKKUMUS. OFFERING_ADDITI ONAL_INFO

DW_SKAIS_PAKKU MUS. OFFERING_ADDITI ONAL_INFO

LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_PAKKUMUS. OFFERING_BENEFIT

DW_SKAIS_PAKKU MUS. OFFERING_BENEFIT

LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_PAKKUMUS. OFFERING_CALCU LATION_INFO

DW_SKAIS_PAKKU MUS. OFFERING_CALCU LATION_INFO

LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_PAKKUMUS. OFFERING_GROUP

DW_SKAIS_PAKKU MUS. OFFERING_GROUP

LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_PAKKUMUS. OFFERING_SUBJE CT

DW_SKAIS_PAKKU MUS. OFFERING_SUBJE CT

LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_PAKKUMUS. OFFERING_SUBJE CT_DETAIL

DW_SKAIS_PAKKU MUS. OFFERING_SUBJE CT_DETAIL

LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_PEREHYVIT IS.ALLOWANCE

DW_SKAIS_PEREH YVITIS. ALLOWANCE

LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_PEREHYVIT IS. ALLOWANCE_SUBJ ECT

DW_SKAIS_PEREH YVITIS. ALLOWANCE_SUBJ ECT

LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_PEREHYVIT IS. CALCULATED_ALL OWANCE

DW_SKAIS_PEREH YVITIS. CALCULATED_ALL OWANCE

LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_PEREHYVIT IS. CALCULATED_ALL OWANCE_PAYMENT

DW_SKAIS_PEREH YVITIS. CALCULATED_ALL OWANCE_PAYMENT

LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_PEREHYVIT IS. CALCULATED_ALL OWANCE_SUBTYPE

DW_SKAIS_PEREH YVITIS. CALCULATED_ALL OWANCE_SUBTYPE

LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_PEREHYVIT IS.DECISION

DW_SKAIS_PEREH YVITIS.DECISION

LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_PEREHYVIT IS. DECISION_BASIS

DW_SKAIS_PEREH YVITIS. DECISION_BASIS

LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_PEREHYVIT IS. DECISION_BASIS_ SETTING

DW_SKAIS_PEREH YVITIS. DECISION_BASIS_ SETTING

LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_PEREHYVIT IS. DECISION_EVALUA TION_RESULT

DW_SKAIS_PEREH YVITIS. DECISION_EVALUA TION_RESULT

LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_PEREHYVIT IS. EVALUATION_RES ULT

DW_SKAIS_PEREH YVITIS. EVALUATION_RES ULT

LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_PEREHYVIT IS. LOG_ALLOWANCE

DW_SKAIS_PEREH YVITIS. LOG_ALLOWANCE

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_PEREHYVIT IS. LOG_ALLOWANCE _SUBJECT

DW_SKAIS_PEREH YVITIS. LOG_ALLOWANCE_ SUBJECT

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_PEREHYVIT IS. LOG_CALCULATED _ALLOWANCE

DW_SKAIS_PEREH YVITIS. LOG_CALCULATED _ALLOWANCE

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_PEREHYVIT IS. LOG_CALCULATED _ALLOWANCE_PAY ME

DW_SKAIS_PEREH YVITIS. LOG_CALCULATED _ALLOWANCE_PAY ME

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_PEREHYVIT IS. LOG_CALCULATED _ALLOWANCE_SU BTY

DW_SKAIS_PEREH YVITIS. LOG_CALCULATED _ALLOWANCE_SUB TY

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_PEREHYVIT IS.LOG_DECISION

DW_SKAIS_PEREH YVITIS. LOG_DECISION

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_PEREHYVIT IS. LOG_DECISION_BA SIS

DW_SKAIS_PEREH YVITIS. LOG_DECISION_BA SIS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_PEREHYVIT IS. LOG_DECISION_BA SIS_SETTING

DW_SKAIS_PEREH YVITIS. LOG_DECISION_BA SIS_SETTING

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_PEREHYVIT IS. LOG_DECISION_EV ALUATION_RESULT

DW_SKAIS_PEREH YVITIS. LOG_DECISION_EV ALUATION_RESULT

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_PEREHYVIT IS. LOG_EVALUATION _RESULT

DW_SKAIS_PEREH YVITIS. LOG_EVALUATION _RESULT

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_PEREHYVIT IS.LOG_OFFERING

DW_SKAIS_PEREH YVITIS. LOG_OFFERING

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_PEREHYVIT IS. LOG_PARAPHRASE

DW_SKAIS_PEREH YVITIS. LOG_PARAPHRASE

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_PEREHYVIT IS.OFFERING

DW_SKAIS_PEREH YVITIS.OFFERING

LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_PEREHYVIT IS.PARAPHRASE

DW_SKAIS_PEREH YVITIS. PARAPHRASE

LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_PROCEEDI NG.ALLOWANCE

DW_SKAIS_PROCE EDING. ALLOWANCE

LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_PROCEEDI NG. ALLOWANCE_STAT US

DW_SKAIS_PROCE EDING. ALLOWANCE_STAT US

LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_PROCEEDI NG. ALLOWANCE_TRA NSITION_EXCLUSI ON

DW_SKAIS_PROCE EDING. ALLOWANCE_TRAN SITION_EXCLUSION

LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_PROCEEDI NG. ALLOWANCE_TRA NSITION_STATE

DW_SKAIS_PROCE EDING. ALLOWANCE_TRAN SITION_STATE

LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_PROCEEDI NG.DECISION

DW_SKAIS_PROCE EDING.DECISION

LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_PROCEEDI NG. LOG_ALLOWANCE

DW_SKAIS_PROCE EDING. LOG_ALLOWANCE

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_PROCEEDI NG. LOG_ALLOWANCE _STATUS

DW_SKAIS_PROCE EDING. LOG_ALLOWANCE_ STATUS

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_PROCEEDI NG. LOG_ALLOWANCE _TRANSITION_EXC LU

DW_SKAIS_PROCE EDING. LOG_ALLOWANCE_ TRANSITION_EXCLU

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_PROCEEDI NG. LOG_ALLOWANCE _TRANSITION_STA TE

DW_SKAIS_PROCE EDING. LOG_ALLOWANCE_ TRANSITION_STATE

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_PROCEEDI NG.LOG_DECISION

DW_SKAIS_PROCE EDING. LOG_DECISION

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_PROCEEDI NG.LOG_PAYMENT

DW_SKAIS_PROCE EDING. LOG_PAYMENT

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_PROCEEDI NG. LOG_PAYMENT_C HANNEL

DW_SKAIS_PROCE EDING. LOG_PAYMENT_CH ANNEL

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_PROCEEDI NG.LOG_SUBJECT

DW_SKAIS_PROCE EDING. LOG_SUBJECT

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_PROCEEDI NG.PAYMENT

DW_SKAIS_PROCE EDING.PAYMENT

LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_PROCEEDI NG. PAYMENT_CHANN EL

DW_SKAIS_PROCE EDING. PAYMENT_CHANN EL

LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_PROCEEDI NG.SUBJECT

DW_SKAIS_PROCE EDING.SUBJECT

LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_TECHNICAL AID.ISO

DW_SKAIS_TECHNI CALAID.ISO

REWRITE

SKAIS_TECHNICAL AID. ISO_CONDITION

DW_SKAIS_TECHNI CALAID. ISO_CONDITION

REWRITE

SKAIS_TECHNICAL AID. ISO_CONDITION_C ODE

DW_SKAIS_TECHNI CALAID. ISO_CONDITION_C ODE

REWRITE

SKAIS_TECHNICAL AID. ISO_JUSTIFICATIO N_LIMIT

DW_SKAIS_TECHNI CALAID. ISO_JUSTIFICATIO N_LIMIT

REWRITE

SKAIS_TECHNICAL AID.JUSTIFICATION

DW_SKAIS_TECHNI CALAID. JUSTIFICATION

REWRITE

SKAIS_TECHNICAL AID.LOG_ISO

DW_SKAIS_TECHNI CALAID.LOG_ISO

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_TECHNICAL AID. LOG_ISO_CONDITI ON

DW_SKAIS_TECHNI CALAID. LOG_ISO_CONDITI ON

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_TECHNICAL AID. LOG_ISO_CONDITI ON_CODE

DW_SKAIS_TECHNI CALAID. LOG_ISO_CONDITI ON_CODE

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_TECHNICAL AID. LOG_ISO_JUSTIFIC ATION_LIMIT

DW_SKAIS_TECHNI CALAID. LOG_ISO_JUSTIFIC ATION_LIMIT

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_TECHNICAL AID. LOG_JUSTIFICATION

DW_SKAIS_TECHNI CALAID. LOG_JUSTIFICATION

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_TECHNICAL AID. LOG_PROVIDER

DW_SKAIS_TECHNI CALAID. LOG_PROVIDER

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_TECHNICAL AID. LOG_RENT_PERIOD

DW_SKAIS_TECHNI CALAID. LOG_RENT_PERIOD

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_TECHNICAL AID. LOG_SPECIAL_RE QUEST

DW_SKAIS_TECHNI CALAID. LOG_SPECIAL_RE QUEST

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_TECHNICAL AID. LOG_TRANSACTION

DW_SKAIS_TECHNI CALAID. LOG_TRANSACTION

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_TECHNICAL AID. LOG_TRANSACTIO N_ROW

DW_SKAIS_TECHNI CALAID. LOG_TRANSACTIO N_ROW

LOAD_MODIFIED_ WOID

LOG_ACTION in ('D','I') and LOG_CREATE_TIME >=TO_DATE('[LAST_LOAD_DT]','yyyy- mm-dd hh24:mi:ss')

SKAIS_TECHNICAL AID.PROVIDER

DW_SKAIS_TECHNI CALAID.PROVIDER

LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_TECHNICAL AID.RENT_PERIOD

DW_SKAIS_TECHNI CALAID. RENT_PERIOD

LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_TECHNICAL AID. SPECIAL_REQUEST

DW_SKAIS_TECHNI CALAID. SPECIAL_REQUEST

LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_TECHNICAL AID.TRANSACTION

DW_SKAIS_TECHNI CALAID. TRANSACTION

LOAD_MODIFIED (case when LAST_MODIFIED_DATE < DATE '1900-01-01' then DATE '1900-01-01' else LAST_MODIFIED_DATE end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS_TECHNICAL AID. TRANSACTION_ROW

DW_SKAIS_TECHNI CALAID. TRANSACTION_ROW

SKAIS_TECHNICAL AIDXROAD. XROAD_INBOUND_ REQUEST

DW_SKAIS_TECHNI CALAIDXROAD. XROAD_INBOUND_ REQUEST

LOAD_MODIFIED (case when REQUEST_RECEIVED < DATE '1900-01-01' then DATE '1900-01-01' else REQUEST_RECEIVED end) >=TO_DATE('[LAST_LOAD_DT]','yyyy-mm-dd hh24:mi:ss')

SKAIS2VALINE. SKAIS1_PRT_DATA

DW_SKAIS2_VALIN E_ODS. SKAIS1_PRT_DATA

REWRITE

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_ WOID

LOG_ACTION in (''D'',''I'') and LOG_CREATE_TIME >=TO_DATE (''[LAST_LOAD_DT]'',''yyyy-mm-dd hh24:mi:ss'')

SKAIS_RINAFACADE LOG_CASE_STATE LOAD_MODIFIED_ WOID

LOG_ACTION in (''D'',''I'') and LOG_CREATE_TIME >=TO_DATE (''[LAST_LOAD_DT]'',''yyyy-mm-dd hh24:mi:ss'')

SKAIS2.IS_KONTAK T_STAATUS

DW_SKAIS2. IS_KONTAKT_STAA TUS

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.LOG_IS_KO NTAKT_STAATUS

DW_SKAIS2. LOG_IS_KONTAKT_ STAATUS

LOAD_MODIFIED_ WOID

LOG_ACTION in (''D'',''I'') and LOG_LISAM_AEG >=TO_DATE(''[LAST_LOAD_DT]'',''yyyy- mm-dd hh24:mi:ss'')

skais_doctor_assess ment.activity_catego ry

DW_SKAIS_DOCTO R_ASSESSMENT_O DS.activity_category

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

skais_doctor_assess .ment

domain_category

DW_SKAIS_DOCTO R_ASSESSMENT_O DS.domain_category

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

skais_doctor_assess exp_deviation_ment.

icf_category

DW_SKAIS_DOCTO R_ASSESSMENT_O DS. exp_deviation_icf_ca tegory

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

skais_doctor_assess ment. log_activity_category

DW_SKAIS_DOCTO R_ASSESSMENT_O DS. log_activity_category

LOAD_MODIFIED_ WOID

LOG_ACTION in (''D'',''I'') and LOG_LISAM_AEG >=TO_DATE(''[LAST_LOAD_DT]'',''yyyy- mm-dd hh24:mi:ss'')

skais_doctor_assess .ment

log_domain_category

DW_SKAIS_DOCTO R_ASSESSMENT_O DS. log_domain_category

LOAD_MODIFIED_ WOID

LOG_ACTION in (''D'',''I'') and LOG_LISAM_AEG >=TO_DATE(''[LAST_LOAD_DT]'',''yyyy- mm-dd hh24:mi:ss'')

skais_doctor_assess exp_deviatiment.log_

on_icf_category

DW_SKAIS_DOCTO R_ASSESSMENT_O DS. log_exp_deviation_ic f_category

LOAD_MODIFIED_ WOID

LOG_ACTION in (''D'',''I'') and LOG_LISAM_AEG >=TO_DATE(''[LAST_LOAD_DT]'',''yyyy- mm-dd hh24:mi:ss'')

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 *

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"?>

<repository> <id>KettleFileRepository</id>

<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

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

<server> </server>ska-wrh-1a.prd.tehik.ee

<type>VERTICA5</type>

<access>Native</access>

<username>pentaho</username>

<password>Encrypted *****</password>

<data_tablespace/>

<index_tablespace/>

.......

<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

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

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

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.

SKA SKAIS2 DW süsteemsed tabelid

COLUMNS SKAIS2 Väljade/veergude andmed

Välja nimi Välja tüüp

Selgitus Andmete näited

COLUMN_VERSION _ID

int Surrogaatvõti 6750

DATA_SOURCE_CO DE

varchar (20)

Andmeallika/lähtesüsteemi kood 'SKAIS2'

SOURCE_SCHEMA_ NAME

varchar (128)

Skeemi nimi lähtesüsteemis 'SKAIS2'

SOURCE_TABLE_N AME

varchar (128)

Tabeli nimi lähtesüsteemis 'AR_PROTSESS_VEATEADE'

SOURCE_COLUMN_ NAME

varchar (128)

Välja/veeru nimi lähtesüsteemis ' 'VEATEADE_SYS

DWH_COLUMN_NA ME

varchar (128)

Välja/veeru nimi andmelaos 'VEATEADE_SYS'

SOURCE_COLUMN_ COMMENT

varchar (4000)

Välja/veeru kirjeldus lähtesüsteemis 'Kommentaar'

DWH_COLUMN_CO MMENT

varchar (4000)

Välja/veeru kirjeldus andmelaos 'Kommentaar'

DATA_TYPE varchar (128)

Andmetüüp lähtesüsteemis 'VARCHAR2', 'INTEGER', 'DECIMAL', 'CLOB'

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 lähtesüsteemis

DWH_DATA_TYPE varchar (255)

Andmetüüp andmelaos 'VARCHAR(20000)'

NULLABLE char(1) Kas veerg võib sisaldada puuduvaid (NULL) väärtusi (0/1)

IS_KEY int Kas veerg on primaarvõti (0/1) 0

LOAD_STATUS varchar (20)

Välja/veeru laadimise staatus andmelaos

'LOAD' - Välja laadimine on sisse lülitatud

'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 TUS

varchar (30)

Välja staatus andmelaos: 'NEEDS_CREATION' - väli vajab loomist

'NEEDS_MODIFICATION' - väli vajab muutmist (näiteks lähteallikas on muutunud andmetüüp)

'READY' - väli on loodud/muudetud

SOURCE_COLUMN_ ID

int Välja/veeru ID lähtesüsteemis 7

IS_VALID int Kas tegemist on kehtiva kirje /versiooniga (0/1)

VALID_FROM timesta mp

Kirje/versiooni kehtivuse algusaeg '2019-06-16 20:36:18'

VALID_TO timesta mp

Kirje/versiooni kehtivuse lõppaeg '2019-07-02 11:11:26'

MODIFIED_BY varchar (32)

Kirje looja/muutja 'pentaho'

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'

DATA_SOURCES SKAIS2 Andmeallikad (lähte-andmebaasid)

Välja nimi Välja tüüp

Selgitus Andmete näited

DATA_SOURCE_VERS ION_ID

int Andmeallika versiooni ID. Surrogaatvõti. 1

DATA_SOURCE_CODE varchar (32)

Andmeallika/lähtesüsteemi kood. 'SKAIS2'

DATA_SOURCE_NAME varchar (128)

Lätesüsteemi nimetus 'SKAIS2'

DATA_SOURCE_TYPE varchar (20)

Lähtesüsteemi tüüp 'SOURCE_DB' - lähtesüsteemiks on andmebaas

'TARGET' - andmelao andmebaas

DBMS_TYPE varchar (20)

Andmebaasi tüüp 'ORACLE'

IS_ACTIVE int Kas lähtesüsteemist andmete laadimine on aktiivne (võimaldab terve lähtesüsteemi 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 (32)

Versiooni lisaja/muutja 'SYSTEM'

HAS_DEL_REC int Kas selles andmeallika korral kasutatakse kustutatud kirjete tühistamist. 0

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'

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'

DWH_SCHEMAS SKAIS2 Andmelao skeemide andmed.

Välja nimi Välja tüüp

Selgitus Andmete näited

DWH_SCHEMA_VERSIO N_ID

int Skeemi versiooni ID 1

DWH_SCHEMA_NAME varchar(32) Andmelao skeemi/loogilise andmeallika nimi 'ORACLE'

DWH_SCHEMA_COMME NT

varchar (255)

Andmelao skeemi kirjeldus 'SKAIS2 põhiandmed'

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

EVENT_LOG SKAIS2 Sündmuste logi

Välja nimi Välja tüüp

Selgitus Andmete näited

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 (20)

Sündmuse grupi kood. Võimalikud väärtused:

INSTALLATION - installimine

LOADING - laadimine

'INSTALLATION', 'LOADING'

EVENT_CODE varchar (20)

Sündmuse tüüp. Võimalikud variandid:

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

'ERROR'

EVENT_MESSA GE

varchar (255)

Sündmuse kirjeldus 'ERROR in loading STG table'

RELATED_OBJ ECT

varchar (50)

Sündmusega seotud objekt (nt tabeli nimi, lähteallika nimi vms). Konkreetne objekt sõltub sündmuse koodist. 'ADM_SKAIS2.TABLES'

PROCESS_NA ME

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'

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

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'

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'

LOAD_LOG SKAIS2 Andmete laadimise logi

Välja nimi

Välja tüüp

Selgitus Kommentaar Andmete näide

LOG_ID int Logikirje identifikaator. Primaarvõti.

PROCE SS_ID

int Laadimise protsessi identifikaator.

Iga käivitatud andmete laadimise protsess saab unikaalse identifikaatori. 1

SUBPR OCESS _CODE

varchar (50)

Alamprotsessi kood /nimi

Võimalikud väärtused:

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

'STG_LOAD'

DATA_S OURCE _CODE

varchar (32)

Andmeallika kood. Viide tabelile ADM_SKAIS2. DATA_SOURCES

'SKAIS2'

RELATE D_OBJE CT

varchar (50)

Protsessiga seotud objekti (skeemi, andmetabeli vms) kood

'SKAIS2. IS_EEMALO LEK'

START_ DT

timesta mp

Protsessi käivitamise algusaeg

'2019-06-16 21:29:22'

END_DT timesta mp

Protsessi käivitamise lõppaeg

'2019-06-16 21:29:25'

STATUS varchar (32)

Laadimise protsessi (lõpetamise) staatus.

Võimalikud väärtused:

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.

'ERROR'

IS_IGN ORE

int Kas lõpetamise staatust võib ignoreerida.

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'

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 - kirjete arv on võrdne

WARNING - kirjete arv on erinev

SUCCESS

STATUS_DESC varchar(255) Kirjete arvu täpsem kirjeldus. Võimalikud väärtused

correct

dwh has less than source

dwh has more than source

correct

EVENT_DT timestamp Kirjete võrdluse teostamise aeg '2021-04-17 03:18:05.469

SCHEMAS SKAIS2 Lähtesüsteemi skeemid

Välja nimi Välja tüüp

Selgitus Andmete näited

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 ME

varchar (128)

Skeemi nimi lähtesüsteemis 'SKAIS2'

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

TABLES SKAIS2 Tabelite andmed.

Välja nimi

Välja tüüp

Selgitus Andmete näited

TABLE_VE RSION_ID

int Surrogaatvõti 411

DATA_SO URCE_CO DE

varchar (32)

Andmeallika/lähtesüsteemi kood 'SKAIS2'

SOURCE_ SCHEMA_ NAME

varchar (128)

Skeemi nimi lähtesüsteemis 'SKAIS2'

SOURCE_ TABLE_NA ME

varchar (128)

Tabeli nimi lähtesüsteemis 'AD_AADRESS'

DWH_SCH EMA_NAME

varchar (32)

Skeemi nimi andmelaos 'DW_SKAIS2'

DWH_TAB LE_NAME

varchar (128)

Tabeli nimi andmelaos 'AD_AADRESS'

TABLE_TY PE

varchar (20)

Tabeli tüüp (TABLE, VIEW, MVIEW) 'TABLE'

SOURCE_ TABLE_C OMMENT

varchar (4000)

Tabeli kirjeldus lähtesüsteemis 'Kommentaar'

DWH_TAB LE_COMM ENT

varchar (4000)

Tabeli kirjeldus andmelaos 'Kommentaar'

LOAD_ST ATUS

varchar (20)

Laadimise staatus 'LOAD' - Tabeli laadimine on sisse lülitatud

'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 THOD

varchar (20)

Andmete laadimise meetod 'LOAD_MODIFIED' - laaditakse pärast viimast õnnestunud andmete laadimist lisatud /muudetud andmed

'REWRITE' - andmed kirjutatakse üle (st muudatuste ajalugu ei säilitata)

MODIFIED _FILTER

varchar (255)

Filtritingimus, mida kasutatakse muudetud ja/või lisatud andmete tuvastamiseks (LOAD_MODIFIED) laadimismeetodi korra.

'(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_LOA D_EXPRE SSION

varchar (255)

Avaldis, mis tuvastab mis aja seisuga andmed on laaditud

'timestampadd('hour',-1, max(MUUTM_AEG))'

DWH_TAB LE_STATUS

varchar (30)

Tabeli staatus andmelaos 'NEEDS_CREATION' - tabel vajab loomist

'NEEDS_MODIFICATION - tabel vajab muutmist

'READY' - tabel on loodud/muudetud

LAST_LOA D_DT

timesta mp

Viimase õnnestunud andmete laadimise kuupäev ja kellaaeg

'2019-06-18 14:00:38'

IS_VALID int Kas tegemist on kehtiva kirje/versiooniga (0/1) 0

VALID_FR OM

timesta mp

Kirje/versiooni kehtivuse algusaeg '2019-06-16 20:36:15'

VALID_TO timesta mp

Kirje/versiooni kehtivuse lõppaeg '2019-07-08 16:30:17'

MODIFIED _BY

varchar (32)

Versiooni lisaja/muutja 'pentaho'

IS_DM_TA BLE

int Kas tegemist on andmelettide arvutamisel kasutatava andmetabeliga. 0/1 tunnus.

Kui mõne andmelettide laadimises kasutatava tabeli laadimisel tekib viga, siis andmelettide laadimise osa ei käivitata.

IS_ROW_ COUNT

int Kas tabeli laadimisel võrreldakse andmelattu 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.

10, 100

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

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

Lisa 2 - Kodukord.pdf

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

vorm

Sagedus Vastutav

roll

Reeglid

Igapäevane

teabevahetus

Jooksvalt Tellija PJ

Täitja PJ

 Tööde läbiviimiseks lepib

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

vajadustele

Tellija PJ

Täitja PJ

 Keerulisematele küsimuste

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

dokumentatsioon

Jooksvalt Tellija PJ

Täitja PJ

 Projekti dokumentatsioon

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

tööülesanded

Iganädalaselt Tellija PJ

Täitja PJ

 Projekti kõiki tööülesandeid

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

puudutav

teabevahetus

Vastavalt

vajadusele

Tellija PJ

Täitja PJ

 Lepingu täitmist puudutav

ametlik teabevahetus, mis pole

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

teabevahetus

Vastavalt

vajadusele

Tellija PJ

Täitja PJ

 Poolte vaheline teabevahetus,

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:

Valdkon

Riski

kirjeldu

Riski

realiseerumis

e tagajärg

Risk

mõj

(M)

Riski

realiseerumis

e tõenäosus

(TN)

Skoo

r (S)

Riski

juhtimise

tegevuse

Vastutaj

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.

Lisa 4 - Toode uleandmise ja vastuvotmise akt.pdf

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

(ID) töö nimetus

Roll / Nimi Maht

(h)

Tunnihind

(€/h) KM-ta

Maksumus

kokku

(€) KM-ta

1 Roll 1 ___ €

Roll 2

2 (...)

(...)

...

___ €

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/

Lisa 5 - Isikuandmete tootlemise tingimused (solmitakse vastavalt vajadusele toode teostamise ajal).pdf

ISIKUANDMETE TÖÖTLEMISE TINGIMUSED

... (edaspidi volitaja), registrikood //, asukohaga //, keda esindab direktor //

..... (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/

Seosed

Nimi	K.p.	Δ	Viit	Tüüp	Org	Osapooled

Leping

Failid

Digiallkirjad

Seosed