II SEKCIJA. Duomenų bazės ir modeliai

Transcription

1 II SEKCIJA Duomenų bazės ir modeliai

2 VEIKLOS TAISYKLIŲ SAUGYKLA, INTEGRUOTA SU VEIKLOS TAISYKLIŲ IŠKVIETIMO MECHANIZMU 1 Rimantas Butleris, Liudas Motiejūnas Kauno technologijos universitetas Straipsnyje pristatoma veiklos taisyklių saugykla, skirta deklaratyviam veiklos taisyklių saugojimui. Aprašoma, kaip saugomi meta duomenys apie egzistuojančią duomenų bazę, kaip susiejama veiklos taisyklė bei ją suaktyvinantis įvykis. Taip pat pateikiamas metodas, kaip veiklos taisyklės yra iškviečiamos, remiantis įvykiais iš duomenų bazių trigerių bei specifinių įvykių atveju. 1 Veiklos taisyklių saugojimo būdai 1.1 Veiklos taisyklės objektuose Veiklos taisykles ir objektus lengva supainioti ir yra labai svarbu suprasti, kad veiklos taisyklės yra kas kita nei objektai [6]. Objektai atvaizduoja realaus pasaulio esybes. Jie apima duomenis ir elgesį, kurie yra reikalingi atlikti veiklos funkcijas. Taisyklėmis yra realizuota organizacijos politika bei veiklos normos. Veiklos taisyklės kontroliuoja objektų veiklą. Specifikuoti objektams lengvai keičiamas ir nesunkiai pritaikomas veiklos taisykles šiandieniniame elektroninio verslo bei keleto lygių architektūros taikomosiose programose yra nemažas iššūkis. Veiklos taisyklių patikrinimas turi būti esminė kiekvieno objekto realizacijos dalis. Gerai suprojektuotas objektas yra atsakingas už veiklos taisykles, kurios jį valdo. Toks objektų projektavimo būdas supaprastina taisyklių palaikymą bei tobulinimą. Sistemoje kiekvienas objekto būsenos pasikeitimas yra valdomas taisyklių, kurias objektas turi patikrinti prieš pakeičiant būseną. Yra keletas projektavimo principų, kurie skirti tikrinti veiklos taisyklėms objektuose [7]: 1. Veiklos taisyklė turi būti patikrinta kai objektas keičia savo būseną; 2. Veiklos taisyklės patikrinimas iškviečia logiką, kuri gali priklausyti arba nepriklausyti pačiam paveiktam objektui, t.y. taisyklės patikrinimas nebūtinai privalo būti aprašytas pačiame objekte; 3. Veiklos taisyklių patikrinimas yra atskiras nuo logikos taisyklių tikrinimo. Tai yra vienas iš būdų, kaip turėtų būti realizuoti objektai. Kitas būdas prasideda išplečiant į objektus orientuota analizę ir projektavimą taip, kad būtų įtrauktas veiklos taisyklių ir kintamumo taškų identifikavimas veiklos procesuose [11]. Kur galima pasiekti naudos, taisyklės yra laikomos išoriškai nuo programinio kodo ir kintamumo taškai yra pakeičiami į paleidimo (trigger points) taškus. Paleidimo taškas yra specifinis taškas, iš kurio išorėje laikoma taisyklė yra iškviečiama. Paleidimo taško pirminė užduotis yra atrinkti taisykles, kurios yra iškviečiamos. Yra ir kitų būdų kaip apjungti į objektus orientuotą ir veiklos taisyklių požiūrius. Vienas iš jų, tai padaryti kiekvieną taisyklę objektu, tačiau šis būdas greičiausiai sukeltų žymias vykdymo problemas. Dar vienas būdas, tai sukurti dirbtinius objektus, kurie būtų atsakingi už veiklos taisyklių vykdymą [5]. 1.2 Veiklos taisyklės duomenų bazių trigeriuose Nėra vieningos nuomonės apie duomenų bazių trigerių panaudojimą veiklos taisyklėms realizuoti. Tradicinėse informacijos sistemose veiklos taisyklės yra realizuotos taikomojoje programoje, tačiau šis būdas kelia keletą problemų: Veiklos taisyklė yra iškviečiama tik tada, kai taikomoji programa ar įrankis iškviečia paprogramę. Jei duomenų bazės įrašų redagavimui naudojamas koks nors kitas įrankis, tuomet veiklos taisyklė nėra iškviečiama. Sunku suformuoti sąrašą algoritmų, kurie yra naudojami veiklos taisyklėms vykdyti. Tenka pasitikėti dokumentacija (kuri gali būti nevisiškai tiksli) arba peržiūrėti taikomosios programos kodą. Kai kurios kompanijos, tokios kaip Oracle, siūlo mechanizmą, vadinamą duomenų bazių trigeriu, kuris palengvina organizacijos veiklos taisyklių realizavimą. Duomenų bazės trigeris yra blokas PL/SQL ar kitos duomenų manipuliavimo kalbos sakinių, kurie yra įvykdomi, kuomet duomenų bazės lentelei yra taikomas SQL kalbos DELETE, UPDATE arba INSERT sakinys. Trigerius galima naudoti sekančioms užduotims atlikti [8]: Vykdyti sudėtingas saugumą užtikrinančias veiklas; Pakeisti stulpelio reikšmę, priklausomai nuo kitų tos pačios ar kitos lentelės stulpelių reikšmių; 1 Šį darbą remia Lietuvos valstybinis mokslo ir studijų fondas pagal Eureka programos projektą IT-Europe (Reg. Nr. 3473) 11

3 Rimantas Butleris, Liudas Motiejūnas Atlikti sudėtingus stulpelių reikšmių patikrinimus, pvz., gali prireikti patikrinti stulpelio reikšmę, palyginant ją su sudėtinėmis kitos lentelės stulpelių reikšmėmis. Dokumentuoti įrašo pasikeitimus, įrašant pakeistas reikšmes į kitą lentelę. Kai kurie autoriai [4] teigia, kad duomenų bazių trigeriai ir procedūros yra naudojami tam tikrų rūšių, tokių kaip faktų, apribojimų, veiklos, įgalinimo ir išvesties veiklos taisyklėms realizuoti. Trigeriai paprastai yra naudojami realizuoti integralumui, apribojimo tipo taisyklėms, kurios yra transformuojamos į duomenų bazės įvykius. Saugomos procedūros ir trigeriai pagerina taikomosios programos vykdymą. Tačiau jie pažeidžia idealų supratimą apie veiklos taisykles, prijungdami jas prie konkrečios duomenų bazės. Kiti autoriai vis dėlto tvirtina, kad labiausiai paplitęs trigerių panaudojimas yra veiklos taisyklių realizavimas duomenų bazėje. Trigeriai naudojami tada, kai standartiniai apribojimai arba lentelėmis pagrįstas deklaratyvusis integralumas (Declarative Referential Integrity (DRI)) yra neadekvatūs [3, 10]. Tačiau yra ir kitų nuomonių, kurios teigia, kad veiklos taisyklės neturi nieko bendro su programavimu, duomenų bazių trigeriais ar ekspertinėmis sistemomis [2]. Nesvarbu kokio aukšto lygio yra programavimo kalba, ji vis tiek nėra sprendimas sukurti gerą, lengvai pritaikomą, veiklos taisyklėmis pagrįstą sistemą. Norint sukurti iš tikrųjų lengvai pritaikomą sistemą, programos logika privalo būti laikoma atskirai nuo veiklos logikos; kitu atveju programinis kodas praranda pritaikomumą. Duomenų bazių trigeriai kai kada buvo taikomi patenkinti veiklos taisyklių poreikiams, tačiau trigeriai negali patenkinti visų veiklos reikalavimų. Taip yra todėl, kad duomenų bazių trigeriai operuoja vien tik su duomenimis, o veiklos taisyklės yra duomenų ir įvykių kombinacija. Dar svarbiau yra tai, kad trigeriams palaikyti reikia turėti specifinių duomenų bazių ir SQL kalbos įgūdžių. Yra netgi sukurti specialūs įrankiai [12], kurie suteikia geresnę alternatyvą veiklos taisyklėms realizuoti nei įterpti jas į taikomosios programos logiką ar realizuoti jas kaip duomenų bazės trigerius. 1.3 OCL kalba Organizacijos modelio aprašymui projektavimo fazėje galima naudoti OCL (Object Constraint Language) kalbą. Ši kalba apibrėžia apribojimus objektams. Apribojimai suteikia keletą privalumų [14]: 1. Apribojimai papildo modelius informacija apie modelio elementus ir jų tarpusavio ryšius, todėl jie yra gera dokumentavimo forma. Apribojimai turi būti laikomi arti modelio. Apribojimų versijų numeravimas turi būti suderintas su modelio, kuriam apribojimai yra naudojami, versijų numeravimu. 2. Skirtingi žmonės negali apribojimų interpretuoti skirtingai. Apribojimai yra nedviprasmiški ir suteikia modeliui ar sistemai aiškumo. 3. Modeliai yra naudojami bendravimui tarp vartotojų, projektuotojų, programuotojų ir kitų žmonių. Bendravimas, kuris turi trūkumų, priveda prie programinės įrangos projektų žlugimo. Prie daugelio modelių yra pridedamas natūralia kalba parašytas paaiškinimas, kuris padeda geriau suprasti modelį gaunančiajai pusei. Tačiau skaitytojai dažnai turi pasikliauti savo pačių interpretacija. Naudojant OCL apribojimus modeliuotojas gali nedviprasmiškai perduoti savo specifikuotą suvokimą kitoms grupėms. Yra bent du neabejotini tikslai, kuriems įgyvendinti yra naudojama OCL kalba [1]: 1. Tai kalba, skirta aprašyti formaliems teiginiams statiniuose klasių modeliuose, siekiant apibūdinti korektiškumo sąlygas. 2. Kalba, skirta rašyti veiklos taisyklėms. Šiuos du tikslus dažnai painioja projektuotojai. Teiginiai: formalūs sakiniai, kurie apibūdina semantines korektiškumo sąlygas modeliams. Dažniausiai vartojamos trys teiginių kategorijos: prieš-sąlygos (pre-conditions), po-sąlygos (post-conditions) ir klasių invariantai (class invariants). Taip pat galimi keletas kitų teiginių: tikrinimo instrukcijos ir ciklų invariantai. Pirmieji trys yra patys svarbiausi OCL kalboje. Jei modelis yra realizuotas kaip programinė įranga, tuomet visi teiginiai privalo būti teisingi (TRUE) visiems atskiriems klasių atvejams atitinkamu laiku. Bet koks teiginio pažeidimas vykdymo metu bus klaida programinėje įrangoje. Veiklos taisyklės: veiklos taisyklės taip pat yra formalūs sakiniai, tačiau vietoj to, kad jos apibrėžtų modelio ar programinės įrangos korektiškumą, jos apibrėžia realaus pasaulio esybių korektiškumą. Kadangi modelis gali susidėti iš tokių esybių (pvz. banko sąskaitų), kai kurios veiklos taisyklės gali būti painiojamos su modelio teiginiais. Galima charakterizuoti skirtumą tarp šių dviejų dalykų. Veiklos taisyklė yra sakinys, kuris: nėra teisingas (not TRUE) visiems klasės atvejams bet kuriuo metu, todėl negali būti patalpintas į semantinį klasės kontraktą projektavimo ar kompiliavimo metu; gali būti įvertintas bet kuriuo metu ir neprivalo turėti prieš-, po-sąlygų ar invariantų struktūros, naudojamos teiginių apibrėžimui; paprastai yra apibrėžtas iš išorinio požiūrio į objektus; tuo tarpu teiginiai yra apibrėžiami kaip klasės semantikos dalis; 12

4 Veiklos taisyklių saugykla, integruota su veiklos taisyklių iškvietimo mechanizmu gali sukurti ir/arba modifikuoti vartotojas vykdymo metu vykdymo metu įvykęs pažeidimas nereiškia, kad programinėje įrangoje yra klaida. Jis reiškia, kad veiklos reikalavimas ar proceso taisyklė ar kas nors kita veiklos lygyje buvo pažeista; dažnai reikalauja specialios sintaksės, kadangi žiūrint iš vartotojo ar veiklos analitiko perspektyvos būdas, kuriuo dalykai yra išreiškiami ar suprantami įmonėje nėra glaudžiai susijęs su tuo būdu, kuriuo jie atvaizduojami programinėje įrangoje. Tam, kad sukurti patikimą programinę įrangą, teiginiai yra neabejotinai reikalingi, tačiau ar reikalingos veiklos taisyklės ir kaip jos bus išreiškiamos visiškai priklauso nuo to, kam skirta sistema ir kokia veikla užsiima įmonė. Taigi, OCL kalbą galima naudoti ir teiginiams užrašyti, ir veiklos taisyklėms apibrėžti. Tačiau tam, kad OCL kalba būtu absoliučiai tinkama apibrėžti veiklos taisyklėms, ji turėtų turėti tinkamą sintaksę visoms veiklos situacijoms, bet vienareikšmiškai pasakyti, kad tai yra tiesa, negalima. OCL kalba labiau turėtų būti naudojama savo pirminiam tikslui ir tik paskui ją naudoti veiklos taisyklių sintaksei. 1.4 Veiklos taisyklių kalba (RuleML) Taisyklių žymėjimo (markup) kalbos bus pagrindinė priemonė veiklos taisyklių naudojimui tinkle bei paskirstytose sistemose. Jos leidžia išdėstyti, vykdyti, paskelbti bei bendradarbiauti taisyklėmis tinkle. Jos taip pat susilieja į hibridinę kalbą, skirta apsikeisti taisyklėmis tarp skirtingų sistemų bei įrankių. Siaurąja prasme taisyklių žymėjimo kalba yra konkreti (XML pagrįsta) taisyklių sintaksė tinklui. Plačiąja prasme ji privalo turėti abstrakčią sintaksę kaip įprastinę bazę įvairių konkrečių pokalbių apibrėžimui, skirtų skirtingiems tikslams. RuleML tikslas yra leisti daugkartinį panaudojimą ir tarpusavio mainus aukštesniame lygyje. Taisyklės gali būti trijų skirtingų lygių [13]: 1. Veiklos srities lygyje taisyklės yra sakiniai, kurie išreiškia veiklos/srities politiką deklaratyviu būdu, paprastai naudojant natūralią ar vizualinę kalbą. 2. Nepriklausomame nuo platformos lygyje taisyklės yra formalūs sakiniai, išreikšti formalizmais ar skaičiavimo paradigmomis, kurie gali būti prijungiami prie vykdomųjų taikomosios programos platformos sakinių. Šiame lygyje naudojamos taisyklių kalbos yra SQL:1999, OCL2.0 ir ISO prolog. 3. Specifiniame platformai lygyje taisyklės yra sakiniai, išreikšti specifine vykdomąją kalba, tokia kaip Oracle trigeriai, Jess, XSB ar Microsoft Outlook Rule Wizard. Paprastai taisyklės yra savarankiški žinių vienetai. Jos gali specifikuoti: statinius ar dinaminius integralumo apribojimus; išvestis; reakcijas. RuleML kalboje yra keletas pagrindinių taisyklių tipų: išvedimo taisyklės, integralumo apribojimai, reakcijos taisyklės, produkcinės taisyklės ir transformacijos taisyklės. Kiekviena taisyklės dalis yra kokio nors tipo išraiška, atliekanti specifinę rolę taisyklės viduje. Skirtingos RuleML taisyklių dalys kartu su rolėmis, kurias jos atlieka, ir jų tipais yra pavaizduotos 1 lentelėje. 1 lentelė. RuleML taisyklių komponentai ir atitinkami jų tipai RuleML komponentas Apribojimas (Constraint) Sąlyga (Condition) Išvada (Conclusion) Po-sąlyga (PostCondition) Transformacijų Iškvietėjas (TransformationInvoker) Transformacijų Grąžinimas (TransformationReturn) Paleidimo Įvykis (TriggeringEvent) Paleistas Veiksmas (TriggeredAction) Sukeltas Veiksmas (ProducedAction) Tipas Loginis Sakinys (LogicalSentence) Loginė Formulė (LogicalFormula) Loginė Formulė (LogicalFormula) Loginę Formulė (LogicalFormula) Funkcinė Formulė (FunctionalFormula) Funkcinė Formulė (FunctionalFormula) Įvykio Terminas (EventTerm) Veiksmo Terminas (ActionTerm) Veiksmo Terminas (ActionTerm) 2 Veiklos taisyklių saugykla Veiklos taisyklių saugykla yra duomenų bazė, kurioje saugomi visi duomenys apie veiklos taisykles ir visi reikalingi meta duomenys apie esybes, atributus ir ryšius, kurie yra įtraukti į duomenų modelį. Meta duomenys yra duomenų komponentas, kuris aprašo duomenis. Tai duomenys apie duomenis, tačiau tai ne veiklos duomenys. Veiklos duomenys, tai duomenys, kurie yra tiesiogiai naudojami veiklos operacijose ir yra naudojami net ir be kompiuterizuotos sistemos. Meta duomenys yra papildomi duomenys, kurie aprašo ką savyje 13

5 Rimantas Butleris, Liudas Motiejūnas laiko kompiuterizuota sistema ir kaip ji veikia arba aprašo veiklos duomenis, tokius, kaip veiklos terminų apibrėžimai. Didelis meta duomenų komponentas, su kuriuo dirba sistemos projektuotojai, yra meta duomenys, kurie apibrėžia taikomosios programos duomenų bazės struktūrą. Šis duomenų tipas yra užfiksuotas duomenų modeliuose, kurie paprastai yra sukurti naudojant duomenų bazių projektavimo technologijas, pagrįstas reliacinių duomenų bazių teorija. Veiklos taisyklių saugykloje šis duomenų tipas labai svarbus, kadangi veiklos taisyklių interpretatorius privalo žinoti, kokiais veiklos duomenimis jis turi naudotis veiklos taisyklės vykdymo metu. 2.1 Veiklos taisyklių saugyklos architektūra Šiame darbe siūloma veiklos taisyklių saugykla yra paremta David o Plotkin o [9] pasiūlytos saugyklos šablonu. Ši veiklos taisyklių saugykla yra lanksti ir lengvai praplečiama, suteikia galimybę aprašyti įvairių tipų veiklos taisykles. Veiklos taisyklių saugyklą galima suskirstyti į tris logines dalis: 1. Bendri duomenys apie veiklos taisykles bei meta duomenys apie egzistuojančią loginę duomenų bazę (1 pav. ); 2. Veiklos taisyklės sąlygos dalis (2 pav.); 3. Veiklos taisyklės veiksmo dalis (3 pav.). Pirmoje dalyje yra saugomi bendri duomenys apie veiklos taisykles, tokie kaip veiklos taisyklės šaltinis, apibrėžimas natūralia kalba, taisyklių aibės ir kt., bei meta duomenys apie egzistuojančią duomenų bazę (duomenys apie lenteles, jas sudarančius stulpelius bei lenteles siejančius ryšius), suteikiama galimybė nurodyti, kaip veiklos taisyklės įtakoja viena kitą ar yra įtakojamos kitų taisyklių. 1 pav. Veiklos taisyklių saugyklos dalis bendrajai informacijai saugoti 14

6 Veiklos taisyklių saugykla, integruota su veiklos taisyklių iškvietimo mechanizmu 2 pav. Veiklos taisyklių saugyklos dalis sąlygai saugoti 3 pav. Veiklos taisyklių saugyklos dalis veiksmui saugoti 15

7 Rimantas Butleris, Liudas Motiejūnas Antrojoje saugyklos dalyje saugomi duomenys apie sąlygą ar kelias sąlygas, kurias turi patikrinti veiklos taisyklė. Tai duomenys apie patikrinimo eiliškumą, patikrinimo, kurį turi atlikti veiklos taisyklė tipą bei kiti patikrinimui reikalingi duomenys. 1 ir 2 paveikslėliuose pavaizduotos veiklos taisyklių saugyklos dalys siejasi per lenteles Veiklos_Taisykle bei Salyga ir šių lentelių atitinkamus atributus VT_Id. Trečiojoje saugyklos dalyje saugomi duomenys apie taisyklės veiksmą ar kelis veiksmus, kuriuos turi atlikti veiklos taisyklė. Tai duomenys apie veiksmų eiliškumą, veiksmų tipą, klaidos pranešimą bei taikomosios programos objektus (įvedimo formos, ataskaitos ir kt.), kuriuos gali iškviesti veiklos taisyklė. Reikia pabrėžti, kad veiklos taisyklės veiksmo dalis nėra privaloma kiekvienai taisyklei, nes taisyklės kartais tik atlieka patikrinimą. 2 ir 3 paveikslėliuose pavaizduotos veiklos taisyklių saugyklos dalys siejasi per lenteles Salyga bei Veiksmas ir šių lentelių atitinkamus atributus Salygos_Id, tačiau šis ryšys nėra privalomas. 2.2 Veiklos taisyklių pavyzdžiai Šiame skyrelyje pateikiami keli veiklos taisyklių pavyzdžiai, kurie parodo, kaip veiklos taisyklės saugomos pasiūlytoje saugykloje. Pateikiami tik esminiai veiklos taisyklės patikrinimui laukai. 4 paveikslėlyje pateikiamas duomenų bazės fragmentas: 2 lentelė. Lentele 4 pav. Duomenų bazės fragmentas Šiam duomenų bazės fragmentui galioja šios veiklos taisyklės: BR1: Nuolaidos Data_iki turi būti didesnė už Data_nuo BR2 :Jei klientas užsisakė paslaugų už daugiau nei Lt, tuomet klientas yra Auksinis klientas Sekančiose lentelėse pateikiami meta duomenys, aprašantys aukščiau pavaizduotą schemą. Lenteles_pav Klientas Uzsakymas Paslauga Nuolaidos 3 lentelė. Stulpelis Esybes_apibrezimas Saugomi duonenys apie klientą Saugomi duomenys apie užsakymą Saugomi duomenys apie paslaugą Saugomi duomenys apie nuolaidas Sulpelio_ID Lenteles_pav Stulpelio_pav Atributo_apib Stulpelis_FK Stulpelis_PK Kl6 Klientas Kliento_tipas False False Nu4 Nuolaidos Data_nuo False False Nu5 Nuolaidos Data_iki False False 4 lentelė. Rysys Rysio_ID Rysio_apibrezimas Tevo_lentele Vaiko_lentele Kl_Uz1 Klientas Uzsakymas Pa_Uz1 Paslauga Uzsakymas Pa_Nu1 Paslauga Nuolaidos 16

8 Veiklos taisyklių saugykla, integruota su veiklos taisyklių iškvietimo mechanizmu 5 lentelė. Rysys_stulpelis Rysio_ID Tevo_stulpelio_ID Vaiko_stulpelio_ID Kl_Uz1 Kl1 Uz2 Pa_Uz1 Pa1 Uz3 Pa_Nu1 Pa1 Nu1 6 lentelė. VT_F_Veik_Ivykis. Ivykio_ID F_Veiksmo_ID VT_ID Lenteles_pav Insert F1 BR1 Nuolaidos Update F2 BR2 Uzsakymas Sekančiose lentelėse pavaizduota, kaip aprašomos pateiktos taisykles veiklos taisyklių saugyklos lentelėse: 7 lentelė. Veiklos_Taisykle VT_ID BR1 BR2 VT_Pavadinimas NuolaidosData KlientasAuksinis 4 paveikslėlyje pavaizduota, koks VT saugyklos vaizdas panaudojamas pirmajai veiklos taisyklei išsaugoti. 4 pav. Veiklos taisyklių saugyklos lentelės, atvaizduojančios veiklos taisyklę BR1 Sekančiose lentelėse parodyta, kokie atributai bei jų reikšmės yra saugomos veiklos taisyklių saugykloje, norint aprašyti veiklos taisyklę BR1. 8 lentelė. Salyga Salygos_ID VT_ID Salygos_tipas Cond1 BR1 Palyg 9 lentelė. S_Palyginimas Palyginimo_ID Salygos_ID Palyginimo_israiska Comp1 Cond1 Nu4 > Nu5 5 paveikslėlyje pavaizduota, koks VT saugyklos vaizdas panaudojamas antrajai veiklos taisyklei išsaugoti. 5 pav. Veiklos taisyklių saugyklos lentelės, atvaizduojančios veiklos taisyklę BR2 Sekančiose lentelėse parodyta, kokie atributai bei jų reikšmės yra saugomos veiklos taisyklių saugykloje, norint aprašyti BR2 veiklos taisyklę. 17

9 Rimantas Butleris, Liudas Motiejūnas 10 lentelė. Salyga Salygos_ID VT_ID Salygos_tipas Cond2 BR2 Palyg 11 lentelė. S_Palyginimas Palyginimo_ID Salygos_ID Veiksmo_ID Palyginimo_išraiška Comp2 Cond2 ActOp2 Kaina > lentelė. Veiksmas Veiksmo_ID Salygos_ID Veiksmo_tipas ActOp2 Cond2 Atv_reiksme 13 lentelė. V_atvejo_reiksme Reiksmes_ID Salygos_ID Reiksme Reiksmes_pav Val1 Cond2 Auksinis Kl6 3 Veiklos taisyklių suaktyvinimas 3.1 Veiklos taisyklių iškvietimas iš duomenų bazių trigerių Vienas didžiausių veiklos taisyklių sistemų taikymo uždavinių suaktyvinti atitinkamas veiklos taisykles ir priversti jas funkcionuoti. Duomenų kontrolės veiklos taisyklės yra naudojamos tam pačiam tikslui kaip ir duomenų bazių trigeriai. Šios taisyklės yra atsakingos už duomenų, saugomų duomenų bazėje, korektiškumą. Jos netgi reaguoja į tuos pačius įvykius kaip duomenų bazių trigeriai. Tačiau taisyklės ir trigeriai nėra tas pats, kadangi veiklos taisyklės yra saugomos autonominėje veiklos taisyklių saugykloje ir privalo būti aktyvuotos prie konkrečių veiksmų. Dažniausiai yra sunku nustatyti įvairius įvykius, kurie galėtų aktyvuoti veiklos taisyklę. Šiuo atveju galima naudoti duomenų bazių trigerius, kadangi juose jau yra realizuotas reagavimas į įvykius INSERT, DELETE ir UPDATE. Tereikia praplėsti duomenų bazių trigerius atitinkama programinio kodo eilute, kuri aktyvuos veiklos taisyklių interpretatorių. Tai gali būti padaryta tokiu būdu: CREATE TRIGGER Trigger_Name ON Table_Name FOR { [ INSERT ] [, ] [ UPDATE ] [, ] [ DELETE ] } CallEngine(Ivykis, Lenteles_pav, Funkc_veiksmas) /* ši eilute aktyvuoja interpretatorių */ Kur: Ivykis tai vienas iš trijų įvykių - Insert, Update, Delete, prie kurio yra aktyvuojamas trigeris; Lenteles_pav tai lentelės, su kurios duomenimis yra atliekami veiksmai, pavadinimas; Funkc_veiksmas funkcijos veiksmo pavadinimas iš veiklos taisyklių saugyklos lentelės VT_F_Veik_Ivykis. Tokiu būdu praplėtus trigerį nebereikia rūpintis veiklos taisyklių interpretatoriaus suaktyvinimu. Tarkime, kad duomenų bazės administratorius nori įterpti (įvykis INSERT) naują nuolaidą. Tuomet veiklos taisyklių interpretatorius privalo patikrinti veiklos taisyklę BR1. Lentelei Nuolaidos turi būti sukurtas trigeris, kuris būtų aktyvuojamas prie įvykio INSERT: CREATE TRIGGER Trig_nuolaidos ON Nuolaidos FOR INSERT CallEngine(Ivykis, Lenteles_pav, Funkc_veiksmas) Šiuo atveju parametras Ivykis turės reikšmę Insert, parametras Lenteles_pav turės reikšmę Nuolaidos, o parametras Funkc_veiksmas turės reikšmę F2. Šiuo momentu veiklos taisyklių interpretatorius turi atlikti SELECT operaciją, kad atrinktų atitinkamas veiklos taisykles. SELECT operacija: SELECT VT_ID FROM VT_F_Veik_Ivykis WHERE Ivykis = Insert AND Lenteles_pav = Nuolaidos AND Funkc_veiksmas = F2 Šiame pavyzdyje bus atrinkta ir perduota tolimesniam vykdymui veiklos taisyklė BR1. 18

10 Veiklos taisyklių saugykla, integruota su veiklos taisyklių iškvietimo mechanizmu 3.2 Veiklos taisyklių iškvietimas specifinių įvykių atveju Kaip jau buvo minėta, sistemose egzistuoja taisyklės, kurios yra iškviečiamos prie specifinių aplinkybių, kurios gali priklausyti nuo vartotojo veiksmų ir nėra susijusios su duomenų kontrole. Šiuo atveju jos negali būti suaktyvinamos duomenų bazių trigerių pagalba. Jos yra suaktyvinamos prie atitinkamų įvykių (vadinamų Events) pasirodančių taikomojoje programoje (Click(), ValueChange(), kt.). Tokiu atveju reikia taikomojoje programoje įrašyti programinio kodo eilutę, kuri iškviestų veiklos taisyklių interpretatorių: CallEngineSE(Ivykis, Funkc_veiksmas) Čia Ivykis tai įvykio pavadinimas (arba ID, bet jį naudoti nelabai patogu), kuris yra saugomas veiklos taisyklių saugyklos lentelėje Veiklos_ivykis; Funkc_veiksmas funkcijos veiksmo pavadinimas iš veiklos taisyklių saugyklos lentelės VT_F_Veik_Ivykis. Skirtingai nei kviečiant taisykles iš duomenų bazių trigerių, kreipinyje nereikia nurodyti lentelės pavadinimo, nes taisyklė nebūtinai turi būti susijusi su konkrečių lentelių duomenimis, o gali operuoti duomenimis, esančiais ekrano formoje. 3.3 Veiklos taisyklių susiejimas su įvykiais Kita problema susijusi su veiklos taisyklėmis kaip sužinoti, kurią veiklos taisyklę reikia iškviesti. Šiam tikslui įgyvendinti reikia perduoti keletą parametrų, pagal kuriuos veiklos taisyklių interpretatorius atsirinks reikiamas veiklos taisykles. Yra du bendri parametrai abiejų tipų taisyklėms, tai Įvykis bei Funkc_veiksmas, o duomenų kontrolės taisyklėms dar ir Lenteles_pav. Veiklos taisyklių saugykloje yra lentelė, kurios pavadinimas yra VT_F_Veik_Ivykis (veiklos taisyklė, funkcijos veiksmas, įvykis). Ši lentelė duomenimis yra užpildoma veiklos taisyklių registracijos proceso metu. Prieš atliekant veiklos taisyklių registracija automatizuotoje sistemoje, jos pirmiau turi būti dokumentuotos. Kuomet turime visas veiklos taisykles, tuomet turime ir informaciją apie įvykius, kurie suaktyvina taisyklę, ir informaciją apie lenteles, kurios priklauso nuo konkrečios veiklos taisyklės. Veiklos taisyklės identifikacinis numeris automatiškai įrašomas veiklos taisyklių redagavimo aplinkos pagalba. Pagal perduotus iš taikomosios programos parametrus, veiklos taisyklių interpretatorius iš šios lentelės atrinks veiklos taisyklių, kurios turi būti vykdomos, identifikacinius numerius. 4 Išvados Šiame straipsnyje pristatyta veiklos taisyklių saugykla, skirta deklaratyvių veiklos taisyklių saugojimui. Saugyklą sudaro trys logiškai atskiros dalys, kuriose saugomi bendri duomenys apie veiklos taisykles ir meta duomenys apie egzistuojančią duomenų bazę bei veiklos taisyklės sąlygos bei veiksmo dalys. Aprašytas veiklos taisyklių iškvietimo metodas naudojant duomenų bazių trigerius ir specifinius įvykius. Panaudoti duomenų bazių trigerius patogu, nes jie reaguoja į tuos pačius įvykius kaip ir duomenų vientisumo kontrolės veiklos taisyklės. Tam tereikia praplėsti trigerį atitinkama eilute, kuri iškviečia veiklos taisyklių interpretatorių. Straipsnyje aprašyti parametrai, kuriuos reikia perduoti taisyklių interpretatoriui, kad būtų galima atrinkti vykdymui atitinkamas veiklos taisykles. Tolesniame darbe numatoma sudaryti veiklos taisyklių interpretatoriaus architektūros modelį bei išvystyti algoritmus, skirtus veiklos taisyklėms apdoroti. Literatūra [1] T. Beale. OCL 2.0 Review Januray, [2] Blaze Advisor from HNC software. Ruling a self-service world. 2001, [3] Creating and Managing Triggers. [4] E. Gottesdiener. Business Rules. Show Power, Promise. Application Development Trends, 1997, March, 4(3). [5] E. Gottesdiener. Merging data and object models with business rules. Application Development Trends, 1997, 38(3). [6] Managing Business Rules: A Repository-Based Approach. 1999, [7] J.Nicola, M. Mayfield, M. Abney. Putting business rules into business objects. [8] Oracle company. Enforcing business rules with database triggers. 19

11 Rimantas Butleris, Liudas Motiejūnas [9] D. Plotkin. Business Rules Everywhere. Intelligent Enterprise Magazine, 1999 March 09, 2 4, [10] M. Rennhackkamp. Trigger Happy. DBMS, 1996 May, 9(5), pp [11] I. Rouvellou, L. Degenaro, K. Rasmus, D. Ehnebuske, B. McKee. Extending business objects with business rules. 33rd International Conference on Technology of Object-oriented Languages (TOOLS 33), 2000, pp [12] Visual Rule Studio. [13] G. Wagner, S. Tabet, H. Boley. MOF-RuleML: The Abstract Syntax of RuleML as a MOF Model. 2003, [14] J. B. Warmer, K. Anneke. The object constraint language: precise modeling with UML. Addison-Wesley, Business rules repository integrated with business rules activating mechanism In this article business rules repository, which is dedicated for storing declarative business rules is presented. Also we describe how metadata about existing database is stored, how business rule and event that activates it are related. The usage of database triggers for activating business rules is presented.

12 MS ACCESS DUOMENŲ BAZĖS APSAUGOS METODAS, NAUDOJANT DAO OBJEKTUS Vytautas Slivinskas 1,2, Virginija Šimonytė 1 1 Vilniaus pedagoginio universitetas 2 Vilniaus Gedimino technikos unversitetas Straipsnyje, remiantis MS Access saugumo užtikrinimo sistemos modeliu ir duomenų valdymo objektų biblioteka DAO, pateikiamas MS Access duomenų bazės apsaugos metodas. Šis metodas gali būti naudojamas taikomosiose programose, kuriose informacijos saugojimui yra pasirinktas MS Access duomenų bazės failas. 1 Įvadas 1.1 Jet duomenų bazės Duomenų bazes galima suskirstyti į klases pagal duomenų apimties didumą. Microsoft Access (toliau MS Access) yra vidutinės apimties duomenų bazės valdymo sistema [1]. MS Access priemonėmis sukurta reliacinė duomenų bazė, kurią sudaro duomenų bazės struktūra ir duomenys, saugoma atskirame faile, kuriam suteikiamas plėtinys MDB. Failai su plėtiniu MDB, kuriuose yra saugoma MS Access priemonėmis sukurta taikomoji programa ir duomenų objektai, tradiciškai yra vadinami Access duomenų bazėmis. Tačiau kai failuose yra saugomos tik lentelės ir užklausos, o informacijos valdymui naudojami kiti programavimo įrankiai, tokie kaip Visual Basic, tinkamesnis vardas yra Jet duomenų bazė [2]. Pagrindinį darbą su duomenų bazės failais atlieka Microsoft sukurtas variklis (vykdomoji aplinka) Jet. Šis mechanizmas yra įdiegtas tiek MS Access programoje, tiek įvairiose duomenų valdymo objektinėse bibliotekose. 1.2 Informacijos valdymas Jet duomenų bazėse Kuriant taikomąsias programas, valdyti informaciją Jet duomenų bazėse galima, pasitelkus MS Access programą arba pasinaudojus duomenų valdymo objektų bibliotekomis. Šiuo metu žinomiausios duomenų valdymo bibliotekos yra trumpiniais DAO ir ADO žymimos bibliotekos [3, 4]. DAO biblioteka, nors yra anksčiau pasirodžiusi ir, kai kurių autorių tvirtinimu, jau pasenusi, turi ir keletą privalumų. Vienas jos privalumas slypi paprastume, o kitą privalumą sudaro tai, kad ji turi duomenų apsaugą užtikrinančius objektus. ADO biblioteka šių objektų savyje neturi. Duomenų apsaugos objektai yra realizuoti papildomoje objektinėje bibliotekoje, vadinamoje trumpiniu ADOX [4]. Duomenų valdymo objektų DAO 3.6 objektinis modelis yra realizuotas dinaminio prisijungimo bibliotekos faile DAO360.DLL, kuris, instaliuojant MS Office 2000/XP/2003, yra įvedamas į aplanką \Program Files\Common Files\Microsoft Shared\DAO. Vienoje taikomoje programoje galima naudoti keletą objektinių bibliotekų. Straipsnyje siūloma duomenų apsaugai naudoti DAO objektus, o duomenų valdymui - šiuolaikiškesnius ADO objektus. 1 paveikslėlyje yra parodyta taikomosios programos, kuri savo informaciją saugo atskirame duomenų bazės faile DATA.MDB, duomenų apsaugai naudoja DAO objektus, o duomenų valdymui naudoja ADO objektus, schema. TP DATA.MDB DAO ADO 1 pav. Taikomoji programa, naudojanti duomenis, patalpintus mdb faile Galutiniam vartotojui tokia taikomoji programa pateikiama kartu su duomenų bazės failu. Jeigu šis failas turi savyje vertingą informaciją (pavyzdžiui, žodynus, normatyvinių dokumentų bazes,...), apsaugoti šį duomenų bazės failą nuo nelegalaus kopijavimo ir panaudojimo kitoje, konkuruojančioje taikomoje programoje yra būtina. 21

13 Vytautas Slivinskas, Virginija Šimonytė 2 MS Access duomenų bazės vartotojo lygmens saugumo užtikrinimo modelis 2.1 Saugumo modelio elementai Naudojant MS Access duomenų valdymo sistemą, vartotojas gali nepastebėti, kad egzistuoja duomenų bazės apsaugos sistema, darbo aplinkos informacinis failas SYSTEM.MDW, o duomenų bazės failą atidaro vartotojas Admin. Eilinis vartotojas nepastebi, kad naujai sukurtų duomenų bazės objektų savininkas yra Admin. Tokios duomenų bazės yra visiškai neapsaugotos nuo nelegalaus naudojimo. Todėl norint apsaugoti duomenis, būtina išnagrinėti MS Access saugumo užtikrinimo sistemą ir ja tinkamai pasinaudoti. Paprastesnė saugumo užtikrinimo sistema yra suteikti duomenų bazės failui slaptažodį. Tik žinantis šį slaptažodį vartotojas galės atidaryti duomenų bazės failą. Tačiau šis apsaugos būdas neefektyvus. Daug sudėtingesnis saugumo užtikrinimo modelis yra taip vadinamas vartotojo lygmens saugumo modelis. Pirmieji keturi šio modelio elementai yra: Jūsų sprendinio vartotojas. Tai gali būti realus asmuo arba, taikomosios programos atveju, procesas, vykstantis kompiuteryje. Grupė. Tai vartotojų, kurie turi tą patį duomenų bazės objektų panaudojimo lygmenį, aibė. Vartotojai gali priklausyti vienai ar kelioms grupėms. SystemDB arba darbo grupės informacinis failas. Šis failas yra Microsoft Jet duomenų bazė, kurioje saugomi grupių, vartotojų apibrėžimai ir jų slaptažodžiai. Taikomosios programos duomenų bazės failas. Šiame faile yra visi taikomosios programos sprendinio objektai, kartu su bazės objektų kiekvienam vartotojui ir vartotojų grupei užduotais leidimais. Kaip šie elementai sąveikauja tarpusavyje yra pavaizduota 2 paveikslėlyje. Darbo grupės informacinis failas Grupė Vartotojai Taikomosios programos bazė Objektai Leidimai Microsoft Jet vykdomoji programa (variklis) Vartotojas kreipiasi į Jet variklį Vartotojas stengiasi pasiekti bazės objektą Vartotojas 2 pav. Vartotojo lygmens saugumo modelio elementų sąveika 2.2 Vartotojai ir grupės Failas SYSTEM.MDW Raktas į MS Access duomenų saugumo užtikrinimo sistemą yra failas SYSTEM.MDW. Nors vartotojas lyg ir nepastebi šio failo, iš tikrųjų jis egzistuoja aplanke... \Application Data\Microsoft\Access. Šiame faile yra surašyti duomenų bazės vartotojai ir vartotojų grupės. Standartiniame darbo grupės informaciniame faile yra dvi vartotojų grupės : Users, Admins ir vartotojas Admin, kuris priklauso abiem grupėms Saugumo identifikatorius SID ir personalinis identifikatorius PID Microsoft Jet vartotojus apibrėžia dviem būdais: kaip individualius arba kaip vartotojų grupes. 22

14 MS Access duomenų bazės apsaugos metodas, naudojant DAO objektus Vartotojas identifikuojamas taip vadinamu saugumo identifikatoriumi, žymimu trumpiniu SID. Kompiuteryje šis identifikatorius užima iki 128 baitų. Vartotojo sukūrimo metu Jet sukuria SID, užšifruodamas Jūsų pateiktus duomenis: vartotojo vardą ir asmeninį identifikatorių, žymimą trumpiniu PID. Kai vartotojas kreipiasi į sistemą, norėdamas gauti leidimą naudotis kokiu nors bazės objektu, Jet pagal SID identifikuoja vartotoją. Vartotojo vardas ir slaptažodis vartotojo identifikavimui nenaudojamas. Vardas ir slaptažodis naudojamas tik vartotojo autentiškumo nustatymui. Kai vartotojo autentiškumas yra nustatytas, jam suteikiami leidimai pagal jo saugumo identifikatorių SID Numatytasis vartotojas Jet numatytasis vartotojas vadinamas Admin. Jei vartotojo lygmens saugumo sistema nėra sukurta, visi įėję vartotojai suprantami kaip Admin. Be to kiekvienam vartotojui Admin, nepriklausomai nuo Jet variklio instaliacijos, sukuriamas tas pats saugumo identifikatorius SID. Kadangi Admin vartotojui, jei tik jūs nesiėmėte atitinkamų apsaugos priemonių, yra suteikiami leidimai visiems duomenų bazės objektams, tai bet kuris asmuo, pasinaudojęs MS Access, gali atverti jūsų duomenų bazę ir atlikti su jos objektais visus veiksmus. Todėl vartotojo lygmens saugumo sistemos pirmas uždavinys yra neutralizuoti vartotoją Admin Numatytosios vartotojų grupės Jet apibrėžia dvi numatytąsias vartotojų grupes: grupę Admins ir grupę Users. Abiejų grupių nariai turi visus leidimus, reikalingus darbui su duomenų bazės objektais. Numatytasis vartotojas Admin priklauso abiems šioms grupėms. Grupė Admins skirta tiems vartotojams, kurie yra tikri darbo aplinkos administratoriai. Jie gali kurti naujus vartotojus, ištrinti ar keisti senų vartotojų slaptažodžius, suteikti vartotojams leidimus dirbti su duomenų bazės objektais. Grupės Admins saugumo identifikatorius SID kiekvienam darbo aplinkos informaciniam failui yra vienintelis. Darbo aplinkos informaciniam failui sukurti, naudojant darbo aplinkos administravimo priemonę WRKGADM.EXE, darbo grupės Admins SID yra generuojamas, šifruojant įvestas tris simbolių eilutes: jūsų įvesto vardo, organizacijos ir darbo grupės identifikatoriaus WID. Naujai įvedamiems vartotojams numatytoji grupė yra grupė Users. Pagal apibrėžimą visi duomenų bazės vartotojai yra Users grupės nariai. Numatyta, kad Users grupės nariai turi pilnus leidimus visiems naujai sukurtiems duomenų bazės objektams Nuosavybė Nuosavybės supratimas yra esminis, norint suprasti Microsoft Jet saugumo modelį. Vartotojas, kuris sukuria naują duomenų bazės objektą (lentelę, užklausą) yra šio objekto savininkas. Naudojant objektą,objekto nuosavybė suteikia vartotojui specialias privilegijas. Vartotojas gali suteikti visus leidimus, susietus su objektu ar atšaukti anksčiau šio objekto atžvilgiu išduotus leidimus kitiems vartotojams. Nuosavybės privilegijos objekto savininkui negali atimti joks kitas vartotojas, net jei jis ir priklausytų grupei Admins. Prieš vartotojo lygmens saugumo sistemos įvedimą, duomenų bazės ir visų jos objektų savininkas yra vartotojas Admin, todėl norint efektyviai valdyti saugumo modelį, pirmiausia privalu pakeisti duomenų bazės ir jos objektų nuosavybę. 2.3 Priemonės, naudojamos duomenų saugumo modelio elementų sukūrimui ir valdymui Jau minėjome apie darbo aplinkos administravimo priemonę WRKGADM.EXE, su kuria galima prisijungti prie bet kurio darbo aplinkos informacijos failo ar sukurti naują darbo aplinkos informacinį failą. Pradedant MS Access XP versija, ši priemonė yra integruota į pačią MS Access duomenų bazių valdymo sistemą. MS Access valdymo sistemoje yra atskiras meniu, skirtas saugumo sistemai valdyti. Ten yra visos komandos, skirtos naujų grupių ir vartotojų sukūrimui, savininkų teisių pakeitimui, vartotojo slaptažodžių suteikimui ar pakeitimui. Visos šios operacijos pakankamai smulkiai yra aprašytos knygoje [5]. 3 DAO objektai ir jų metodai, susieti su MS Access duomenų saugumo sistema 3.1 DAO objektų hierarchinė schema Duomenų valdymo objektų biblioteka DAO turi daug objektų su savomis savybėmis ir metodais. Vieni objektai yra susieti su duomenų nuskaitymu, įrašymu ir jų redagavimu. Kiti objektai susieti su MS Access vartotojo lygmens saugumo modelio elementais. Mus domina pastarieji objektai ir jų metodai, kadangi juos siekiame integruoti į savąją duomenų apsaugos sistemą. 3 paveikslėlyje pateikiama DAO objektų, susietų su duomenų apsauga, schema. Objektai yra vaizduojami elipsėmis. Schemoje jų yra keturi: DBEngine (JET variklis), workspace (darbo aplinka), groop (vartotojų grupė), user (vartotojas). Objektų rinkiniai vaizduojami stačiakampiais. Kiekvienam objektui shemoje priklauso žemiau esančio objekto rinkiniai. Pavyzdžiui, darbo aplinkos objektui priklauso vartotojų grupių objektų rinkinys, kuris gali būti sudarytas iš keleto vartotojų grupių objektų. Savo ruožtu vartotojo grupės objektui priklauso vartotojų objektų rinkinys. 23

15 Vytautas Slivinskas, Virginija Šimonytė DBEngine Workspaces Workspace Groups Group Users User 3 pav. DAO objektų, skirtų duomenų saugumo modeliui, hierarchinė schema DBEngine objektas DBEngine objektas yra aukščiausio lygio objektas DAO objektų modelyje. Jis valdo visus likusius objektus DAO objektų hierarchijoje. Pats DBEngine objektas yra vienintelis ir nėra jokio rinkinio elementas. DBEngine objektas turi savyje darbo aplinkų objektų Workspace rinkinius Workspaces. Svarbi. DBEngine objekto savybė yra SystemDB savybė, kuria galima nurodyti darbo aplinkos informacinį failą. Pavyzdžiui, DBEngine.SystemDB = C:\temp\manosystem.mdw Vienas iš svarbesnių DBEngine objekto metodų yra metodas CreateWorkspace. Pavyzdžiui, Set wrk =DBEngine.CreateWorkspace( manowrk, Admin,,dbUseJet). Šiame sakinyje pirmas parametras yra darbo aplinkos vardas, antras vartotojo vardas, trečias slaptažodis, o ketvirtas konstantė, nurodanti, kad naudojamas Microsoft JET variklis Workspace objektas. Darbo aplinkos objektas Workspace naudojamas einamajam duomenų bazės seansui valdyti. Numatytoji darbo aplinka yra pirmoji darbo aplinka rinkinyje DBEngine.Workspaces(0). Jūs galite sukurti darbo aplinką, naudodamiesi objekto DBEngine metodu CreateWorkspace. Objektas Workspace apibrėžia vartotojui darbo su duomenų baze seansą. Jis turi tokias savybes : Name (vardas), UserName (vartotojo vardas), Type (tipas). Workspace objektas taip pat turi daug metodų. Keletas iš jų yra tokie: Close (uždaryti), OpenDatabase (atverti duomenų bazę), CreateDatabase (sukurti duomenų bazę), CreateGroup (sukurti vartotojų grupę), CreateUser (sukurti vartotoją). Pavyzdžiui, Dim usrnaujas as User Set usrnaujas =DBEngine.Workgroups(0).CreateUser( manovardas, AAA , slaptzodis ), 24

16 MS Access duomenų bazės apsaugos metodas, naudojant DAO objektus čia pirmas parametras yra sukurto vartotojo vardas, antras vartotojo PID, trečias vartotojui suteiktas slaptažodis. 4 Duomenų apsaugos metodas 4.1 Naujo darbo aplinkos informacinio failo MANOSYSTEM.MDW sukūrimas Pirmoji duomenų apsaugos metodo dalis yra naujo darbo aplinkos informacinio failo, kurį sąlyginai pavadinome MANOSYSTEM.MDW, sukūrimas. Šiame faile vartotojas Admin išmetamas iš grupės Admins ir paliekamas tik grupėje Users. Jet neleidžia išmesti Admin iš grupės Users. Todėl mes sukuriame naują vartotoją manoadmin, jį įkeliame į grupę Admins, po to įeiname į sistemą kaip naujas vartotojas manoadmin ir jau kaip naujas administratorius pašaliname vartotoją Admin iš grupės Admins. Tada sukuriame naują duomenų bazę DATA.MDB. Jos savininku tampa vartotojas manoadmin. Po to nuimame visus leidimus grupei Users. Sukuriame naują vartotoją, sąlyginiu manoprograma pavadinimu ir suteikiame jam reikiamus leidimus objektams. Šių priemonių išsidėstymas pavaizduotas 4 paveikslėlyje. Sukurti failą manosystem.mdw Sukurti vartotoją manoadmin Užsiregistruoti vartotojo vardu manoadmin Išmesti ADMIN iš grupės ADMINS Sukurti naują duomenų bazės failą DATA.MDB Nuimti visus objektų leidimus grupei USERS Sukurti vartotoją manoprograma Suteikti vartotojui manoprograma leidimus objektams 4 pav. Naujo darbo aplinkos failo sukūrimo veiksmų schema 5 MS Access duomenų bazės apsaugos metodo programinė dalis Sukūrus apsaugotos duomenų bazės darbo aplinkos informacinį failą ir naują duomenų bazę DATA.MDB, kurios savininkas yra naujasis administratorius MANOADMIN, o vartotojas MANOPROGRAMA ir importavus duomenis iš neapsaugotos duomenų bazės, dar turime sukurti programines procedūras, su kuriomis galėtume sukurti laikiną darbo aplinkos failą ir laikiną vartotoją MANOPROGRAMA. Mes negalime perduoti taikomosios programos vartotojams failo MANOSYSTEM.MDW ir atskleisti jiems vartotojo MANOPROGRAMA slaptažodžio. Turime įtraukti į savo taikomąją programą procedūras, realizuojančias 5 paveikslėlyje pateiktą schemą. Užšifruoti laikino vartotojo vardą, personalinį identifikatorių ir slaptažodį reikia tam, kad nebūtų galima jų atpažinti, peržiūrint kompiliuotą programos kodą su žemo lygio teksto redaktoriumi. Rekomenduotina laikiną vartotoją kurti tik prisijungimo prie duomenų bazės metu. Atlikus užklausą, reikia tuoj pat ištrinti failą sss.tmp. Kadangi darbo aplinkos informacinio failo struktūra nesikeičia, tai jis yra gana gerai hakerių ištyrinėtas. Todėl geriau, kad jo vieta ir atsiradimo momentas liktų nepastebėti. Taip pat rekomenduotina kiekvienam taikomųjų programų kūrėjui kurti originalias, niekam nežinomas vardo, slaptažodžio, PID šifravimo procedūras. Galutiniam vartotojui pateikiamas MS Access priemonėmis užšifruotas duomenų bazės failas. Norint padidinti saugumą, duomenų bazės failui dar galima suteikti slaptažodį. 25

17 Vytautas Slivinskas, Virginija Šimonytė Standartinis System.mdw kopijuojamas į laikiną aplanką TEMP vardu sss.tmp DBEngine.SystemDB = C:\temp\sss.tmp Set usrlaik = DBEngine.Workspaces(0).CreateUser (VARD AS,PID) Vardo MANOPROGRAMA dešifravimo procedūra usrlaik.password = SLAPTAZODIS PID dešifravimo procedūra Set wrk = DBEngine.Workspaces (0) wrk.users.append usrlaik Vartotojo MANOPRGRAMA slaptažodžio dešifravimo procedūra 5 pav. Laikino taikomosios programos vartotojo sukūrimo schema 6 Išvados Straipsnyje pateiktas MS Access duomenų bazės apsaugos metodas, grindžiamas duomenų apsaugos sistema, kuri yra integruota į MS Access duomenų bazių valdymo sistemą, ir duomenų valdymo objektų biblioteka DAO. Nors DAO biblioteka yra truputį pasenusi, tai visai neturi įtakos taikomosios programos efektyvumui. Pačioje programoje duomenų valdymui galima naudoti šiuolaikiškesnius ADO ar ADO.NET bibliotekų metodus. Literatūra [1] V. Sekliuckis, S. Gudas, G. Garšva. Informacijos sistemos ir duomenų bazės. Technologija, 2004, 338 p. [2] R. Jennings. Special Edition Using Microsoft Office Access QUE Publishing, 2004, 1502 p. [3] H. Feddema. DAO Object Model: The Definitive Guide. O Reilly, [4] D. Sussman, J. M. Conard, B. Matsik, I. Blackburn, T. McCarthy, J. Papa, S. Robinson. Professional ADO 2.5 Programming. Wrox, 2000, 973 p. [5] T.M.O Brien,S.J. Pogge, G.E.White. Microsoft Access 97 Developer s Handbook. Microsoft Press, 1997, 596 p. MS Access database security method based on DAO objects In the paper the method of MS Access database security using MS Access security model and DAO object library is presented. The method can be used in applications where the data is stored in a MS Access database file. 26

18 METHOD FOR AUTOMATING THE DEVELOPMENT OF DATA WAREHOUSE 1 Jurgita Tonkūnaitė, Lina Nemuraitė, Kristina Paulavičiūtė Kauno technologijos universitetas Data Warehouse development processes may be far more automated using set of standard transformations for schema concepts and data. Transformations between Primary Concept Model (representing operational schema) to Warehouse Concept Model (representing warehouse schema) are proposed. The illustration of the method is presented by the set of principal transformations applied for development of warehouse for analysis of student grades. 1 Introduction Data stored in data bases would be worthless, if it would not be possible to access them through various user required views. It is the only way this data becomes valuable information, which can be used for business development and planning, client segmentation and risk handling, costing, enterprise process and resource optimization. The development of data warehouse makes it possible for user to analyze available data by using various multidimensional database views, derive new indexes, compare them, group them according to interested criteria, and analyze across different modular layers. One of the most substantial problems in data warehouse technology is the way of modeling database structure, that it would be capable to handle infinite user queries. Kimball has proposed a new data modeling technology, precisely adjusted to data warehouse, which was called as dimensional modeling [1, 8, 9]. The aim of dimensional modeling is to supply structures of data base so that it would be understandable to end-users, who need to supply and analyze queries. The second aim is to increase efficiency of these queries. To reach these aims the number of tables must be reduced and relations between them must be set. This decreases complication of databases and minimizes the number of coupling operations for user queries [3], [4], [18]. Data warehouse technology was formed as a response to business management and analysis needs. After the extraction of data from transactional systems to query-oriented databases, users are available to analyze data of warehouses in real time, without executing business operations. Data warehouse is the environment of decision handling when data are collected from different sources and organized for decision making by different employees, despite of what kind of computers they are using and what level of technical preparation he has [10], [12] The main authors of date warehouse development methods are B. Inmon, R. Kimball, M. Jarke, and J. Lechtenbörger [2], [9], [16], [20], [21]. However, in all theoretical methods we can notice gaps, which do not satisfy practical implementation needs. The main imperfection is that there is a lack of attention given to user needs and normalization of scheme. Another holdout of practical usage is that it is a hard problem to develop warehouse by oneself. Tools for development of data warehouses exist in commercial DBVS products (MS SQL server, Oracle, DB2), yet, there is a lack of efficient methodologies in these tools, and this is the reason why they are inefficiently used. In Lithuania, differently from foreign countries, data warehouses are not widely spread, but in recent years the need of practical using of data warehouses was increased. Main deficiencies of methods for development of the data warehouse: - Long lasting development process; - Development without evaluating needs of users (business analysts); - Too-little attention to warehouse schema normalization this affects the quality of warehouse and takes away the possibility to use the content of the warehouse effectively. The warehouse schemes are views and queries on existing (operational) database. Views and queries are derivable from the base schema of data. The idea of this work to afford ground for user to define requirements for warehouse using schemes of existing databases and to generate on-demand warehouses filled with data from existing databases, using a set of transformations. Every well-formed database may be represented by the schema of primary concepts. We are using the term of primary concept for entities and attributes (features of entities) making no difference between them as entities and attributes can become the concepts of the same kind in the warehouse schema. Sophisticated data models as Object Role Modeling (ORM) [16] Object Property (OP) Model [17] and the original Entity- Relationship model by Chen are using primary concepts (really, in different ways). Primary Concept Model for 1 1 The work is supported by Lithuanian State Science and Studies Foundation according to Eureka programme project IT-Europe (Reg. No 3473) 27

19 Jurgita Tonkūnaitė, Lina Nemuraitė, Kristina Paulavičiūtė Warehouse development is specific model with specific properties. The main steps of advanced method for Data Warehouse development are shown in the Figure 1. Figure 1. Steps for automated development of data warehouse 2 Primary Concept Model We have defined yet another Primary Concept model for Data Warehouse development because existing models as ORM, OP or ER have too-many concepts that are not relevant for Warehouse development. In Figure 2, the example of Primary Concept model is presented.. <<Entity>> Forest_type <<PI>> mtip_id <<PI>> mr_id <<PI>> skl_id code name <<PI>> Kv_ID <<PI>> Gir_ID <<PI>> Ur_ID <<Entity>> Tree_kind code name bulk <<Entity>> Parcel code area date <<Entity>> Quarter code <<PI>> viet_id <<Entity>> Forestry code name <<PI>> admr_id <<Entity>> Forest enterprise code name <<PI>> apskr_id age dominant <<Entity>> Location <<Entity>> Region <<Entity>> District code code code name name name Figure 2. Primary Concept Model example for Forest database On the ground of this model users will be able to form their requirement anytime for data analysis for the development of warehouse and data sets that are needed will be formed from present date base. This model can be constantly saved in company s meta-data warehouse. This model is specified by a metamodel in Figure 3 below. 28

20 Method for Automating the Development of Data Warehouse Figure 3. Primary Concept Metamodel 3 Data Warehouse Concept Model Although it is generally agreed that warehouse design is a non-trivial problem and that multidimensional data models and star or snowflake schemata are relevant in this context, hardly any methods exist to date for deriving such a schema from an operational database. Traditional warehouse design methods [12], [13] structure the design process into a sequence of phases or steps, which lasts too long and has several serious lacks: a lack of attention given to user needs and normalization of scheme which purpose is to ensure the quality of data in a warehouse and to protect from aggregation anomalies. In this paper it is aimed to define the model of data warehouse concepts and the principals of development process, which would help to reduce time of development and improve the quality of warehouse scheme. Model called the model of warehouse concepts is close to conceptual multidimensional scheme proposed by J. Lechtenbörger [9]. As an example, the warehouse schema, corresponding to Warehouse Concept model, is presented in Figure 4. Forest_enterprise PK for_ent_key for_ent_code for_ent_name Forestry PK for_key for_code for_name FK1 for_ent_key PK PK Quarter quar_key quar_code FK1 for_key Forest_type f_type_key f_type_code f_type_name PK Parcel parcel_key FK3 f_type_key FK4 tk_key FK1 loc_key FK2 quar_key FK5 time_key area bulk age dominant PK Location PK loc_key loc_code loc_name FK1 reg_key Tree_kind tk_key tk_code tk_name Region PK reg_key reg_code reg_name FK1 distr_key PK District distr_key distr_code distr_name Time PK time_key year Figure 4. Data Warehouse schema example for forest database Requirements of a concept model for a data warehouse include a) providing a modeling construct to represent business facts and their properties, b) connecting temporal dimensions to facts, c) relating objects with their properties and associations, d) defining relationships between objects and business facts, and e) outlining dimensions and their respective hierarchies [5], [6], [7]. Data Warehouse Concept model is specified by a metamodel in a Figure 5 below. 29

21 Jurgita Tonkūnaitė, Lina Nemuraitė, Kristina Paulavičiūtė Figure 5. Data Warehouse Metamodel 4 The scheme transformation The modeling of data warehouse involves modeling of scheme of data warehouse and data transformations. The type of scheme of data warehouse depends on queries that are executed in warehouse. While data transformations depends on various things: what kind of data user wants to see in warehouse, what level of detail this data should be and etc. That is why data transformation is enough complicated and long lasting. If the creation of patterns of transformations from schemes of typical data base (DB) to schemes of data warehouse was successful this stage would become more simple and faster. The placement of data to data warehouse and its updates are performed using ETL software. On purpose to make a transformation from model of primary concepts to scheme of warehouse concepts, it is needed to point out between which data and what transformations will be made. Thes following transformations are possible [8]: operational data elimination; data warehouse key structure supplement with time element; structure supplement with derived data; data relationship transformation to relations artifacts; applying of different levels of data detail in data warehouse; merging different tables; data arrays creation; data partition according to their changeability; The main objective of data warehouse is to collect all needed data, so transformations of all kinds are not indispensable. Some transformations can be moved to analysis (OLAP) level, but others cannot be automated. In example, removing operational data is logical operational data rejection, which is performed by user, while defining data warehouse requirements. There is no reason to transfer only currently urgent data into data warehouse (notes, comments, description, and so on). Bringing derived, different levels data, creating arrays, and so on, is purposeful to move into data analysis level and realize it by OLAP operations. In the following Figure 6 is introduced transformation model with joint of two metamodels using transformation types. If user chose particular facts and dimensions transformation from primary concept scheme to scheme of warehouse would happen automatically. The main data warehouse creation transformations are relational structures reorganization to warehouse dimensions and facts structures, as well creation of time dimensions (if it is used, but this happens frequently). 30

22 Method for Automating the Development of Data Warehouse Primary Concept Metamodel Transformations Warehouse Concept Metamodel T1 T2 T3 T4 T5 Figure 6. Transformations between primary concept and warehouse concept models Transformation model is specified by a metamodel in a Figure 7 below. Figure 7. Tranformation Metamodel 5 Rule execution In order to generate the DW schema, the design rules invoke predefined schema transformations which are successively applied to the source schema. Primary concept model, warehouse concept model and mappings are the input of the transformation rule. If conditions are verified, the rule calls a transformation, which generates a new table transforming the input ones. Table 1 shows a table with the proposed set of rules. The rules marked with * represent families of rules, oriented to solve the same type of problem with different design strategies. 31

23 Jurgita Tonkūnaitė, Lina Nemuraitė, Kristina Paulavičiūtė Table 1. Design rules Rule Transformation R1 Merge Combines two tables generating a new one. R2 Higher Level Names Renames attributes, using the names of an item that maps to it. R3 Materialize Calculation * Adds an attribute to a table to materialize a calculation or an aggregation. R4 Materialize Extern * Adds an attribute to a table to materialize an external expression. R5 Eliminate Non Used Data Deletes not-mapped attributes, grouping by the other attributes and applying a roll-up function to measures. R6 Roll-Up * Reduces the level of detail of a fact table, performing a roll-up of a dimension. R7 Update Key Changes a table primary key, so as to agree the key of a fragment or cube with the attributes that it maps. R8 Data Constraint Deletes from a table the tuples that don t verify a condition. The proposed rules intend to automate the sequence of design decisions that trigger the application of schema transformations and consequently the generation of the DW schema. Rules are specified in 5 sections: Description section is a natural language description of the rule behaviour. Target Structures section enumerates the refined conceptual schema structures that are input to the rule. Input State section enumerates the rule input state consisting of tables and mapping functions. Conditions section is a set of predicates that must be fulfilled before applying the rule. Output State section is the rule output state, consisting of the tables obtained by applying transformations to the input tables, and mapping functions updated to reflect the transformation. The following scheme sketches a rule: Rule name: TargetStructures InputState < mapping, tables > Conditions OutputState < mapping, tables > 6 Trial implementation The prototype of ETL tool, dedicated to star scheme and having the main transformation for data warehouse establishment, was created. The principle can be used to automate other transformations and other scheme types. Main data transformation patterns were created: Dimension transformation it is transferring of entire or part of relational data table or merging of several relational data tables attributes into one table, as well as merging two attributes. Fact transformation it is obtaining of needed data out of one or few relational tables and creation of relations with dimension tables. Time dimension transformation it is dividing of relational data element into the time dimension. Time dimension can have different types: Year month day, Year quarter month day. The implementation of Entity-to-Fact transformation for relational database of students, lecturers, students, subjects and students evaluations is presented on the Figure 8. 32

24 Method for Automating the Development of Data Warehouse Figure 8. Fact transformation pattern for data warehouse 7 Conclusions This methodology and automation would help to accelerate and facilitate the hard process of warehouse development which lasts very long and does not ensure good quality of data. The existing tools for warehouse development in the universal DBVS automate only a part of ETL operations without using the potential possibilities to accelerate the development process. The proposed method would allow to develop the warehouse automatically or semi-automatically what would suit changeful business analytics needs: to really fast gain data sets that are prepared for analysis of present situation, forming multidimensional schemes of data models from factual data stored in organization in operational databases. References [1] E. Franconi and U. Sattler. A Data Warehouse Conceptual Data Model for Multidimensional Aggregation, Proceedings of the Intl. Workshop on DMDW 99, Heidelberg, Germany, June 14-15, [2] E. Franconi and U. Sattler. A Data Warehouse Conceptual Data Model for Multidimensional Aggregation, Proceedings of the Intl. Workshop on DMDW 99, Heidelberg, Germany, June 14-15, [3] M. Golfarelli, D. Maio, and S. Rizzi. The Dimensional Fact Model: a Conceptual Model for Data Warehouses, International Journal of Cooperative Information Systems, Vol. 7, Nos. 2 and 3, pp , [4] K. Hahn, C. Sapia, and M. Blaschka. Automatically Generating OLAP Schemata from Conceptual Graphical Models, Proceedings of the ACM DOLAP 2000 Workshop, pp 9-16, [5] N. Tryfona, F. Busborg, and J. G. B. Christiansen. StarER: A Conceptual Model for Data Warehouse Design, Proceedings of the ACM DOLAP99 Workshop, Missouri, November 2-6, [6] N. Tsois, Karayannidis, and T. Sellis. MAC: Conceptual Data Modeling for OLAP, Proceedings of the Intl. Workshop on DMDW 2001, Interlaken, Switzerland, June 4, [7] I.-Y. Song, W. Rowen, C. Medsker, and E. Ewen. An Analysis of Many-to-Many Relationships between Fact and Dimension Tables in Dimensional Modeling, Proceedings of the Intl. Workshop on DMDW 01, Interlaken, Switzerland, June 4, [8] C. Phipps, K. Davis. Automating data warehouse conceptual schema design and evaluation, Proceedings of the Intl. Workshop on DMDW'02, Canada, [9] Marotta, A. Ruggia, R. Data Warehouse Design:A schema-transformation approach, SCCC Chile [10] Hüsemann, B.; Lechtenbörger, J. Vossen, G. Conceptual Data Warehouse Design, Proceedings of the Intl. Workshop on DMDW 00, Sweden, [11] Hahn, K.; Sapia, C.; Blaschka. M. Automatically Generating OLAP Schemata from Conceptual Graphical Models, Proceedings of the ACM DOLAP 2000 Workshop, USA,

25 Jurgita Tonkūnaitė, Lina Nemuraitė, Kristina Paulavičiūtė [12] Golfarelli, M.; Maio, D.; Rizzi, S. Conceptual Design of Data Warehouses from E/R Schemes, HICSS 98, IEEE, Hawaii, [13] Abello, A.; Samos, J.; Saltor, F. A Data Warehouse Multidimensional Data Models Classification, Technical Report LSI Dept. Lenguages y Sistemas Informáticos, Universidad de Granada, [14] D. Moody, M. Kortnik. From Enterprise Models to Dimensionals Models: A Methodology for Data Warehouse and Data Mart Design, Proceedings of the Intl. Workshop on DMDW 00, Sweden, [15] M. Golfarelli, S. Rizzi. Methodological Framework for Data Warehouse Design, Proceedings of the ACM DOLAP 98, USA, [16] T.A. Halpin. Entity Relationship Modeling from an ORM Perspective, Parts 1-5, Journal of Conceptual Modeling, InConcept, Minneapolis USA, [17] Paradauskas B., Nemuraitė L. Data bases and semantiuc models : monograph. ; Kauno technologijos universitetas. -Kaunas : Technologija, p. - ISBN [18] Kimball R. The Data Warehouse Toolkit: Practical Techniques for Building Dimensional Data Warehouses, John Wiley & Sons, [19] J. Trujillo, M. Palomar, J. Gómez. Applying Object-Oriented Conceptual Modeling Techniques to the Design of Multidimensional Databases and OLAP Applications, Proc. of the First International Conference on Web-Age Information Management (WAIM-00) pp , Shanghai, China, June [20] N. Tryfona, F. Busborg, J.G.B. Christiansen. starer: A Conceptual Model for Data Warehouse Design, In ACM Second International Workshop on Data Warehousing and OLAP DOLAP 99, pp.3-8, November 1999, Missouri, USA. [21] S.C. Brandt, M. Schlüter, M. Jarke. A Process Data Warehouse for Tracing and Reuse of Engineering Design Processes, The Second Internationl Conference on Innovations in Information Technology - IIT'05, Dubai, United Arab Emirates, Sept [22] Inmon W.H. Building the Data Warehouse. John Wiley & Sons, Duomenų saugyklos kūrimo automatizavimo metodas Duomenų saugyklos kūrimas gali būti žymiai daugiau automatizuotas naudojant tipinių transformacijų sekas schemų ir duomenų transformavimui iš pirminių konceptų (vaizduojančių rekliacinę duomenų bazės schemą) į saugyklos konceptų modelį (vaizduojantį saugyklos schemą). Siūlomą metodą realizuojančio įrankio prototipas, realizuojantis pagrindines saugyklos kūrimo transformacijas, sukurtas SQL serverio duomenų bazių sistemoms. Pateiktas studentų pažymių duomenų bazės transformavimo į saugyklą pavyzdys.

26 VEIKLOS ŽINIŲ IŠGAVIMAS IŠ PALIKUONINIŲ SISTEMŲ: SCHEMŲ IŠGAVIMAS IR SEMANTINĖ ANALIZĖ Bronius Paradauskas, Aurimas Laurikaitis Kauno technologijos universitetas Straipsnyje nagrinėjamas veiklos žinių išgavimas iš palikuoninių sistemų reliacinės duomenų bazės ir taikomosios programos kodo. Aptariamos palikuoninių sistemų problemos ir pagrindinės jų sprendimų alternatyvos. Analizuojamos atvirkštinės duomenų inžinerijos ir kodo išgavimo metodikų panaudojimo galimybės, siekiant automatiškai išgauti kiek įmanoma tikslesnes palikuoninės informacinės sistemos schemas ir semantiką. Pateikiamas aštuonių žingsnių algoritmas išgauti žinias iš palikuoninių sistemų. Pristatomas hipotetinis veiklos žinių išgavimo iš palikuoninės sistemos pavyzdys. 1. Palikuoninių sistemų problema Palikuoninė sistema tai bet kokia informacinė sistema, kuri pastebimai priešinasi modifikavimui ar evoliucijai, skirtų atitikti naujus, nuolat kintančius verslo reikalavimus [1]. Palikuoninės sistemos paprastai apima neįtikėtinai detalias veiklos taisykles ir sudaro organizacijos informacinių srautų pagrindą, kuris sutelkia verslo procesų informaciją [2]. Vienos iš šių sistemų sutrikimas gali turėti rimtų padarinių verslui. Palikuoninės sistemos sukelia nemažai problemų jas eksploatuojančioms organizacijoms. Svarbiausios palikuoninių sistemų problemos: sistemas paprastai palaiko techniškai pasenusi, pernelyg lėta aparatūra, kurios palaikymo kaštai pakankamai dideli; programinės įrangos palaikymas yra brangus; trūksta dokumentacijos ir bendro sistemos vidinio funkcionalumo supratimo, todėl klaidų aptikimas brangus ir ilgai trunka; nėra aiškiai apibrėžtų sistemos sąsajų, todėl sunku integruoti; palikuoninių sistemų funkcionalumą yra labai sunku arba net neįmanoma praplėsti. Siekiant išspręsti šias problemas, buvo pasiūlyta keletas palikuoninių sistemų modifikavimą ar pakeitimą apimančių metodų. Jie skirstomi į tris klases [7]: perkūrimas, įpakavimas ir migravimas. Perkūrimo procesą sudaro egzistuojančių programų sukūrimas nuo nulio, panaudojant naują aparatūros platformą, architektūrą, įrankius ir duomenų bazes. Įpakavimas apima programos komponentų, vadinamų apvalkalais, kūrimą, kurie kitiems komponentams leidžia prieiti prie egzistuojančių programinės įrangos komponentų. Migravimas leidžia palikuonines sistemas perkelti į naujas aplinkas, kurios leistų lengviau palaikyti informacines sistemas ir jas pritaikyti naujiems verslo reikalavimams, tačiau tuo pat metu turi būti išlaikytas pradinių palikuoninių sistemų funkcionalumas, nereikia visiškai perkurti jų. Gana dažnai palikuonės sistemos keičiamos, naudojant visus tris paminėtus metodus. Bet kuriuo atveju, siekiant sėkmingai išspręsti palikuoninių sistemų problemas, reikia turėti aiškų informacinės sistemos vaizdą. Todėl pirmiausia reikia įvykdyti atvirkštinę inžineriją, kurios tikslas atrasti ir išgauti kiek įmanoma detalesnes veiklos žinias iš palikuoninių šaltinių. 2. Žinių išgavimas Žinių išgavimo iš palikuoninių šaltinių tikslas yra pusiau automatiškai atrasti ir išgauti palikuoniniuose šaltiniuose sukauptą informaciją, t.y. sudaryti detalų palikuoninės sistemos šaltinių aprašymą, apimantį esybes, ryšius, programoms būdingas esybių ir ryšių reikšmes, veiklos taisykles, duomenų formatų ir pranešimų apribojimus ir t.t. Ši informacija vadinama veiklos žiniomis. Schemos informacija išgaunama (1 pav.) iš palikuoninės sistemos duomenų bazių valdymo sistemos (DBVS). Po to šią informaciją galima semantiškai pagerinti panaudojant semantinės analizės surinktas detales iš prieinamo taikomosios programos kodo, verslo ataskaitų ir kitokios elektroniniu būdu saugomos informacijos, galinčios užkoduoti verslo duomenis (pvz. e- pašto korespondencija, kolektyvinės atmintinės ir pan.). Šiame straipsnyje pateikiamas atvirkštinės duomenų inžinerijos (ADI) algoritmas, susidedantis iš schemos išgavimo (SI) ir semantinės analizės (SA). Taip pat aptariamas ADI veikimą iliustruojantis ir metodo veiksmingumą patvirtinantis pavyzdys. 35

27 Bronius Paradauskas, Aurimas Laurikaitis Peržiūrėti, patvirtinti Atvirkštinė duomenų inžinerija (ADI) Schemos išgavimas (SI) Schemos informacija Įterptos užklausos Semantinė analizė (SA) Palikuoninė DB Palikuoniniai šaltiniai Ataskaitos Palikuoninės programos kodas Šaltinio schema, Semantika, Veiklos taisyklės 1 pav. Žinių išgavimo konceptuali diagrama 3. Atvirkštinė duomenų inžinerija Atvirkštinė duomenų inžinerija nusakoma kaip analitinių metodų taikymas vienam ar daugiau palikuoninių duomenų šaltinių, siekiant iš pastarųjų išgauti struktūrinę informaciją (pvz. sąvokų apibrėžimus, schemų aprašymus), kad būtų pagerintas duomenų bazės projektas arba pateikta trūkstama schemų dokumentacija [5]. Straipsnyje pateiktas metodas atvirkštinę duomenų inžineriją taiko tik reliacinėms duomenų bazėms. Kadangi reliacinis modelis turi ribotą semantinį išraiškingumą, tai ADI algoritmas prie schemos papildomai pateikia palikuoninėje schemoje tiksliai neapibrėžtus (tačiau egzistuojančius netiesiogiai) esybes ir ryšius, naudodamas panašų į ER atvaizdavimą. Formaliai ADI gali būti aprašyta taip: duotai palikuoninei duomenų bazei DB L, apibrėžtai kaip ({ R1, R2,..., Rn }, D), kur Ri žymi i-tojo ryšio schemą su atributais A1, A2,..., A m ( i), raktais K1, K 2,..., K m ( i) ir duomenimis D = { r 1( R1 ), r2 ( R2 ),..., r n ( Rn )}, tokiais kad ri ( Ri ) žymi R i schemos duomenis t laiku. Be to, DB L turi funkcines priklausomybes F = { F 1, F 2,..., F k ( i ) } ir įjungimo priklausomybes I = { I, I 1 2,..., I l( i ) }, kurios išreiškia ryšius tarp DB L ryšių. ADI tikslas yra pirma išgauti { R 1, R 2,..., R n }, I ir F, o tada panaudoti I, F, D ir C L (programos kodas), kad pateikti semantiškai pagerintą { R1, R 2,..., R n } aprašymą, apimantį visus DB L ryšius (taip pat ir numanomus), semantinius ryšių aprašymus bei DB ir C užkoduotas veiklos žinias. Šis reliacinių šaltinių atvirkštinės duomenų inžinerijos metodas yra pagrįstas egzistuojančiais Čiango [3, 4] (Chiang) ir Petito [8] (Petit) algoritmais. Siekiant sumažinti priklausomybę nuo žmogaus valdymo, pašalinti tam tikrus algoritmų apribojimus (pvz. nuoseklus raktinių atributų įvardinimas ir reikalavimas, kad palikuoninė sistema būtų 3 normalinės formos) bei pateikti semantiškai turtingesnį schemos aprašymą, jų metodologijos pagerintos keliais būdais. ADI algoritmas susideda iš dviejų pakaitomis veikiančių dalių: schemos išgavimo ir semantinės analizės. Dviejų algoritmų, susidedančių iš aštuonių žingsnių, vaizdas yra pateiktas 2 pav. Be modulių, vykdančių kiekvieną iš šių žingsnių, 2 pav. pavaizduota architektūra apima ir 3 palaikančius komponentus. Konfigūruojamą prisijungimą prie pagrindinio palikuoninio šaltinio palaiko duomenų bazės sąsajos modulis (viršutinis dešinysis kampas). Pažymėtina, kad šis komponentas yra vienintelis nuo šaltinio priklausantis architektūros komponentas: siekiant žinias išgauti iš skirtingų šaltinių, tereikia pakeisti tik sąsajos modulį. Žinių užkodavimo modulis (apatinis dešinysis kampas) išgautas žinias atvaizduoja XML dokumento forma. Metaduomenų saugykla yra vidinis ADI komponentas, saugantis įvairiems algoritmams (vartotojo sąsajos parametrai, abstraktus kodo sintaksės medis (pvz. iš ankstesnio kreipimosi) ir pan.) reikalingą tarpinę vykdymo informaciją. 36 L L

28 Veiklos žinių išgavimas iš palikuoninių sistemų: schemų išgavimas ir semantinė analizė DB sąsajos modulis Duomenys Programos kodas Palikuoniniai šaltiniai Konfigūracija 1 ASM generavimas ASM Užklausos 2 Žodyno išgavimas 4 Įjungimo priklausomybių tyrinėjimas 5 Ryšių klasifikavimas 3 Kodo analizė Veiklos žinios Metaduomenų saugykla 6 Atributų klasifikavimas 7 Esybių nustatymas Žinių užkodavimas Schema XML DTD 8 Ryšių nustatymas XML DOC 2 pav. Koncepcinis ADI algoritmo vaizdas Siekiant paaiškinti kiekvieną iš 2 pav. pateiktų žingsnių ir jų susijusias veiklas, naudojamas trivialus palikuoninės sistemos pavyzdys. Tarkime, kad yra palikuoninė duomenų bazė DB L, kurią valdo reliacinė duomenų bazių valdymo sistema. Kad būtų paprasčiau nagrinėti šį pavyzdį, tarkime, kad egzistuoja tik šie DB L ryšiai: Projektai [Proj_ID,...] Prieinamumas [Proj_ID, Priein_UID,...] Ištekliai [Proj_ID, Išt_UID,...] Užduotys [Proj_ID, Užd_UID,...] Paskyrimas [Proj_ID, Pask_UID,...] Siekiant paaiškinti kodo analizę ir parodyti, kaip ji pagerina schemos išgavimą, naudojamas C kodo fragmentas, atspindintis paprastą, hipotetinę sąveiką su palikuonine duomenų baze. char *areiksme, *creiksme; int zyme = 0; int breiksme = 0; EXEC SQL SELECT U_Pr_D, U_Pab_D INTO :areiksme,:creiksme FROM UŽDUOTYS WHERE U_Tr = :breiksme; if (creiksme < areiksme) { zyme = 1; } printf( Užduoties pradžios data %s, areiksme); printf( Užduoties pabaigos data %s, creiksme); 3.1 ASM sukūrimas ADI procesas pradedamas nuo abstrakčios sintaksės medžio (ASM) sukūrimo (3 pav.). 1 žingsniu sudarytą ASM naudoja semantinis analizatorius (3 žingsnis) tyrinėti kodą. ASM generavimo tikslas yra sudaryti 37

29 Bronius Paradauskas, Aurimas Laurikaitis prielaidas pasirinktų programos kodo dalių reikšmės išgavimui ir sujungimui su programos kintamaisiais. Pvz. įėjimo/išėjimo sakinių formato eilutės apima semantinę informaciją, kuri gali būti susieta su įėjimo/išėjimo sakinio kintamaisiais. Šie programos kintamieji savo ruožtu gali būti susieti su palikuoninės duomenų bazės stulpeliais lentelėse. 1 dclns beginsql columnlist <id> U_Pr_D <id> 2 U_Pab_D embsql Program 2 embsql 3 SQLselectone if hostvariablelist <id> areiksme <id> creiksme 4 print 5 print SQLAssignment <id> U_Tr <id> breiksme 3 pav. Nuo programos priklausanti kodo analizė, naudojant ASM dekompoziciją ir kodo dalinimą. Dalinimo kryptis yra atvirkštinė (tiesioginė), jei tikrinamas kintamasis yra išėjimo (atitinkamai įėjimo arba deklaravimo) sakinyje. 3.2 Žodyno išgavimas 2 žingsnio tikslas yra iš palikuoninių šaltinių išgauti ryšių ir atributų vardus. Kad tai realizuoti, vykdomos palikuoninės duomenų bazės DB L duomenų žodyno, saugomo vienos ar daugiau sistemos lentelių forma, užklausos. Jei pirminio rakto informacijos negalima tiesiogiai išgauti iš duomenų žodyno, tada pretenduojančių raktų rinkinys kartu su iš anksto užduotais atmetimo šablonais perduodami į kodo analizatorių. Kodo analizatorius programos kode ieško šių šablonų ir pašalina atmetimo šablone esančius atributus iš pretendentų rinkinio. Kai programuotojas tikisi pasirinkti kortežų rinkinį, tuomet programos kode naudoja SQL užklausas, kurias galima panaudoti kaip atmetimo šablonus. Atsižvelgiant į pirminio rakto apibrėžimą, šios taisyklės atmeta galimybę, kad atributai a 1 Kan sudarytų pirminį raktą. Trys pavyzdiniai atmetimo šablonai yra: 1. SELECT DISTINCT <rinkinys> FROM LENTELĖ WHERE a 1 =<išraiška 1 > AND a 2 =<išraiška 2 > AND AND a n =<išraiška n > 2. SELECT <rinkinys> FROM LENTELĖ WHERE a 1 =<išraiška 1 > AND a 2 =<išraiška 2 > AND AND a n =<išraiška n > GROUP BY 3. SELECT <rinkinys> FROM LENTELĖ WHERE a 1 =<išraiška 1 > AND a 2 =<išraiška 2 > AND AND a n =< išraiška n > ORDER BY Jei po kodo analizės pirminis raktas vis dar nebuvo nustatytas, tai sumažintas pretenduojančių raktų rinkinys turi būti pateikiamas vartotojui, kad šis galutinai pasirinktų pirminius raktus. Rezultatas. Iš pavyzdžio palikuoninės duomenų bazės išgauti šie ryšiai ir jų atributai: Projektai [Proj_ID,...] Prieinamumas [Proj_ID, Priein_UID,...] Ištekliai [Proj_ID, Išt_UID,...] Užduotys [Proj_ID, Užd_UID,...] 38

30 Veiklos žinių išgavimas iš palikuoninių sistemų: schemų išgavimas ir semantinė analizė Paskyrimas [Proj_ID, Pask_UID,...] 3.3 Kodo analizė 3 žingsnį apimančios programos kodo analizės tikslas yra dvejopas: (1) 2 žingsniu išgautas esybes papildyti srities semantika ir (2) nustatyti tiesiogiai duomenų bazėje nesaugomas, tačiau atvirkštinės inžinerijos proceso išeigai svarbias veiklos taisykles ir apribojimus. Kodo analizės metodas pagrįstas kodo tyrinėjimu, apimančiu kodo dalinimą [6] ir šablonų lyginimą [9]. Pirmas požingsnis yra prieš-dalinimas. Iš programos kodo abstrakčios sintaksės medžio prieš-dalinimo modulis nustato visus su įėjimo, išėjimo ir įterptiniais SQL sakiniais susijusius mazgus. ASM peržiūrint pirmine tvarka, prieš-dalinimo modulis prideda sakinio mazgo pavadinimą ir identifikatorių sąrašą į masyvą. Pvz. 3 pav. abstrakčios sintaksės medžiui masyvas apima 1 lentelėje pateiktą informaciją. Šioje prieš-dalinimo modulio palaikomoje duomenų struktūroje esantys identifikatoriai sudaro dalinimo kintamųjų aibę. 1 lentelė. Prieš-dalinimo modulio palaikoma informacija Mazgo numeris Sakinys 2 embsql (įterptinio SQL sakinio mazgas) Tekstinė eilutė (tik spausdinimo mazgams) areiksme creiksme Identifikatoriai Dalinimo kryptis Atvirkštinė Kiekvienam prieš-dalinimo surastam dalinimo kintamajam vieną kartą atliekami kodo dalinimas ir analizė, kurie apima atitinkamai 2 ir 3 požingsnius. Aukščiau pateiktame pavyzdyje SQL ir išėjimo sakiniuose pasitaikantys dalinimo kintamieji yra areiksme ir creiksme. Priklausomai nuo to, ar nagrinėjamas kintamasis yra išėjimo (atvirkštinė) ar įėjimo (tiesioginė) sakinio dalis, dalinimo kryptis yra atvirkštinė arba tiesioginė. Dalinimo kriterijus yra tikslus dalinimo kintamąjį atitinkantis sakinio (SQL, įėjimo arba išėjimo) mazgas. Kodo dalinimo modulis peržiūri visą išeities kodo ASM ir palieka tik tuos mazgus, kurie apima dalinimo kintamąjį atitinkamame pomedyje (sumažintas ASM pateiktas 4 pav.). dclns embsql 4 pav. Sumažintas ASM Vykdant analizės požingsnį, algoritmas peržiūri sumažintą ASM pirmine tvarka ir išgauna 2 lentelėje pateiktą informaciją. 1. Jei aptinkamas dcln mazgas, tuomet paaiškėja identifikatoriaus duomenų tipas. 2. embsql talpina identifikatoriaus pavadinimo atvaizdavimo į atitinkamo duomenų bazės stulpelio ir lentelės pavadinimus informaciją. 3. printf/scanf mazgai talpina atvaizdavimo iš tekstinės eilutės į identifikatorių informaciją. Kitais žodžiais tariant, iš tekstinės eilutės galima išgauti kontekstinę identifikatoriaus prasmę. if print 2 lentelė. Analizės požingsnio išgauta informacija Identifikatoriaus pavadinimas areiksme creiksme Prasmė Galima veiklos taisyklė Duomenų tipas Užduoties pradžios data Užduoties pabaigos data if (creiksme<areiksme) {} if (creiksme<areiksme) {} Char * => string Char * => string Stulpelio pavadinimas U_Pr_D U_Pab_D Lentelės pavadinimas Užduotys Užduotys Analizės požingsnio rezultatai įrašomi į ataskaitos failą. Po to, kai kodo dalinimas ir analizė įvykdomi kiekvienam prieš-dalinimo nustatytam dalinimo kintamajam, vartotojui turi būti pristatomas ataskaitos failas. Atsižvelgdamas į pateiktą informaciją, vartotojas turi nuspręsti, ar reikalinga gilesnė analizė. Jei vartotojas nusprendžia neatlikti gilesnės analizės, kodo analizė perduoda valdymą įjungimo priklausomybių aptikimo moduliui. 39

31 Bronius Paradauskas, Aurimas Laurikaitis Be šios programos semantikos, šablonus palyginus su ASM kodo fragmentais galima nustatyti kitas veiklos žinias. Reikalingi šablonai veiklos taisyklėms atrasti, kurios užkoduotos kilpos struktūrose ir / arba sąlygos sakiniuose ir matematinėse formulėse, kurios užkoduotos kilpos struktūrose ir / arba priskyrimo sakiniuose. Pažymėtina, kad nors priskyrimo sakinys nebūtinai nurodo matematinės formulės buvimą, tačiau sakiniui talpinant vieną iš dalinimo kintamųjų dažniausiai padidina svarbumą. 3.4 Įjungimo priklausomybių aptikimas 4 žingsnio tikslas yra nustatyti apribojimus, kurie padėtų klasifikuoti 2 žingsniu išgautos reliacinės schemos ryšius, atvaizduojančius tiek realaus pasaulio esybes, tiek ir ryšius tarp jų. Kad realizuoti šį tikslą, naudojamos įjungimo priklausomybės, parodančios tarpryšinių apribojimų egzistavimą, tarp jų ir klasės / poklasio ryšius. Tegul A ir B yra 2 ryšiai, o X ir Y yra atitinkamai A ir B atributai arba atributų aibė. Įjungimo priklausomybė A. X << B. Y reiškia, kad A. X reikšmių aibė yra B. Y poaibis. Įjungimo priklausomybes galima nustatyti ištyrus visus įmanomus poaibio ryšius tarp bet kokių dviejų palikuoninių šaltinių ryšių A ir B. Šioms priklausomybėms atrasti naudojama nuodugni paieška: kiekvienai palikuonių šaltinių schemos ryšių porai A ir B reikia palyginti kiekvienos neraktinių atributų kombinacijos X iš A reikšmes su kiekvienos pretenduojančių raktinių atributų kombinacijos Y iš B reikšmėmis (pažymėtina, kad X ir Y gali būti atskiri atributai). Įjungimo priklausomybė A.X << B.Y gali egzistuoti, jei: 1. X ir Y turi tą patį atributų skaičių. 2. X ir Y apima tą pačią dalykinę sritį (tas pats duomenų tipas ir toks pat maksimalus atributų ilgis). 3. A. X B. Y. Kad patikrinti poaibio kriterijų, kiekvienai palikuoninių šaltinių ryšių ir atributų kombinacijų porai reikia įvykdyti SQL užklausas, kurių šablonai tokie: C1 = SELECT count (*) FROM R1 WHERE U NOT IN (SELECT V FROM R2); C2 = SELECT count (*) FROM R2 WHERE V NOT IN (SELECT U FROM R1); Jei C1 yra nulis, tada gali egzistuoti įjungimo priklausomybė R 1. U << R2. V, ir atvirkščiai, jei C2 yra nulis, tada gali egzistuoti įjungimo priklausomybė R 1. V << R2. U. Pažymėtina, kad galimi atvejai, kai ir C1, ir C2 yra nulis. Tuomet galima daryti išvadą, kad dvi atributų aibės U ir V yra lygios. Šios nuodugnios paieškos blogiausio atvejo sudėtingumas, duotiems N lentelių ir M atributų kiekvienoje lentelėje (iš viso atributų), yra O N 2 M 2. Tačiau paieškos intervalas sumažėja tais atvejais, kai programos kode galima nustatyti lygių sujungimų užklausas (atliekant semantinę analizę). Kiekviena lygių sujungimų užklausa nurodo vieną ar daugiau schemos įjungimo priklausomybių. Be to, naudojant atitinkamų skaičiavimo užklausų rezultatus galima nustatyti priklausomybių kryptį. Tai leidžia sumažinti nuodugnią paiešką iki išgautose užklausose nepaminėtų ryšių. Rezultatai: Išgautos tokios įjungimo priklausomybės: Paskyrimas [Užd_UID, Proj_ID] << Užduotys [Užd_UID, Proj_ID] Paskyrimas [Išt_UID, Proj_ID] << Ištekliai [Išt_UID, Proj_ID] Prieinamumas [Išt_UID, Proj_ID] << Ištekliai [Išt_UID, Proj_ID] Ištekliai [Proj_ID] << Projektai [Proj_ID] Užduotys [Proj_ID] << Projektai [Proj_ID] Paskyrimas [Proj_ID] << Projektai [Proj_ID] Prieinamumas [Proj_ID] << Projektai [Proj_ID] NM ( ) 40

32 Veiklos žinių išgavimas iš palikuoninių sistemų: schemų išgavimas ir semantinė analizė Paskutines dvi įjungimo priklausomybes galima pašalinti, kadangi 2, 3 ir 4 įjungimo priklausomybės per tranzityvumo ryšį jas netiesiogiai apima. 3.5 Ryšių klasifikavimas Atvirkštinę inžineriją taikant reliacinei schemai yra svarbu suprasti, kad dėl riboto reliacinio modelio išraiškingumo, visos realaus pasaulio esybės, neatsižvelgiant į jų tipus ir vaidmenis modelyje, yra atvaizduotos kaip ryšiai. Šio žingsnio tikslas yra nustatyti skirtingus ryšių tipus: vieni atitinka realaus pasaulio esybes, kiti atvaizduoja ryšius tarp tokių esybių ar tarp ryšių. Šiuo žingsniu visiems duomenų bazės ryšiams priskiriamas vienas iš keturių tipų: stiprus, silpnas, reguliarus arba specifinis. Klasifikavimas atliekamas naudojant 2 žingsniu išgautą pirminių raktų informaciją ir 4 žingsnio įjungimo priklausomybes. Stipri esybė-ryšys atvaizduoja realaus pasaulio esybę, kurios narius galima atpažinti tik per jų pačių savybes. Silpna esybė-ryšys atvaizduoja esybę, kuri neturi savo pačios savybių, padedančių atpažinti jos narius. Reliaciniame modelyje silpnų esybių-ryšių pirminiai raktai paprastai apima kitų (stiprių) esybių-ryšių pirminius raktus. Tiek reguliarus, tiek specifinis yra ryšiai, kurie atvaizduoja ryšius tarp dviejų realaus pasaulio esybių (dažniau nei pačias esybes). Tačiau yra atskirų atvejų, kai ne visos iš (nnariniame) ryšyje dalyvaujančių esybių yra pateiktos duomenų bazės schemoje (pvz. normalaus duomenų bazės schemos evoliucijos proceso metu buvo pašalintas vienas ar daugiau ryšių). Atliekant atvirkštinę duomenų bazės inžineriją, tokie ryšiai nustatomi kaip specialūs ryšiai. Rezultatai: Stipri esybė: Projektai Silpnos esybės: Ištekliai, Užduotys, Prieinamumas Reguliarus ryšys: Paskyrimas 3.6 Atributų klasifikavimas Atributai klasifikuojami kaip a) pirminiai (PRA) arba išoriniai (IRA) raktai, b) kabantys (KRA) arba bendri (BRA), c) neraktiniai (NRA) (likę). Rezultatai: 3 lentelė iliustruoja iš pavyzdinio palikuoninio šaltinio išgautus atributus. 3 lentelė. Atributų klasifikavimo pavyzdys Projektai PRA KRA BRA IRA NRA Proj_ID Ištekliai Proj_ID Išt_UID Užduotys Proj_ID Užd_UID Prieinamumas Proj_ID Priein_UID Išt_UID+Proj_ID Paskyrimas Proj_ID Assn_UID Išt_UID+Proj_ID, Užd_UID+Proj_ID Visi likę atributai 3.7 Esybių tipų nustatymas 5 žingsniu išgautos stiprios (silpnos) esybės-ryšiai tiesiogiai verčiamos į stiprias (atitinkamai silpnas) esybes. Rezultatai: klasifikuotos šios esybės: Stiprios esybės: Projektai su raktu Proj_ID. Silpnos esybės: Užduotys su raktu Užd_UID ir valdančia esybe Projektai. Ištekliai su raktu Išt_UID ir valdančia esybe Projektai. Prieinamumas su raktu Priein_UID ir valdančia esybe Ištekliai. 3.8 Ryšių tipų nustatymas 4 žingsniu atrastos įjungimo priklausomybės leidžia nustatyti ryšių tipą tarp anksčiau aptiktų esybių. Tai yra dviejų žingsnių procesas: 1. Identifikuotus ryšius pristatyti kaip ryšius reliacinėje duomenų bazėje. Ryšių klasifikavimo metu (5 žingsnis) išgauti ryšių tipai (reguliarūs ir specifiniai) yra verčiami į ryšius. Dalyvaujantys esybių tipai aptinkami iš įjungimo priklausomybių. Kad išgautoji schema būtų išbaigta, konceptualizuojant specialų ryšį galima sukurti naują esybę. Kardinalumas tarp esybių yra M : N. 41

33 Bronius Paradauskas, Aurimas Laurikaitis 2. Nustatyti ryšius tarp esybių tipų (stiprių ir silpnų), kurie nebuvo pristatyti kaip reliacinės duomenų bazės ryšiai, naudojant šią klasifikaciją: IS-A ryšiai nustatomi naudojant stiprių esybių ryšių PRA ir įjungimo priklausomybes tarp PRA. Jei yra įjungimo priklausomybė, kurioje stiprios esybės-ryšio pirminis raktas rodo į kitos stiprios esybės pirminį raktą, tada tarp šių dviejų esybių nustatomas IS-A ryšys. IS-A ryšio kardinalumas tarp stiprių esybių 1 :1. Priklausymo ryšys: kiekvienos silpnos esybės tipo šeimininkas nustatomas patikrinant įjungimo priklausomybes, apimančias atitinkamas silpnas esybes-ryšius. Priklausymo ryšio tarp šeimininko ir silpnos esybės kardinalumas yra 1 : N. Agregavimo ryšys: jei bet kokio reguliaraus ar specifinio ryšio išorinis raktas nurodo į vienos iš stiprių esybių ryšių PRA, tuomet nustatomas agregavimo ryšys. Agregatinio ryšio kardinalumas tarp stiprios esybės ir agregatinės esybės ( M : N ryšys ir jo konceptualiajame lygyje dalyvaujančios esybės) yra toks: jei išorinis raktas apima unikalias reikšmes, tada kardinalumas yra 1 :1, priešingu atveju kardinalumas yra 1 : N. Kiti binariniai ryšiai: kiti binariniai ryšiai yra nustatomi, jei IRA nėra naudojami nustatant aukščiau pateiktus ryšius. Binarinio ryšio tarp esybių kardinalumas yra toks: jei išorinis raktas apima unikalias reikšmes, tada kardinalumas yra 1 : 1, priešingu atveju kardinalumas yra 1 : N. Rezultatai: Rasti 1 : N binariniai ryšiai tarp šių silpnų esybių tipų: Tarp Projektai ir Užduotys Tarp Projektai ir Ištekliai Tarp Ištekliai ir Prieinamumas Kadangi egzistuoja 2 įjungimo priklausomybės, kurios apima Paskyrimas (t.y. tarp Užduotys ir Paskyrimas ir tarp Ištekliai ir Paskyrimas), tai nėra poreikio apibrėžti naują esybę. Vadinasi Paskyrimas tampa M : N ryšiu tarp Užduotys ir Ištekliai. 3.9 Žinių atvaizdavimas 8 ADI žingsniai iš palikuoninės duomenų bazės leidžia išgauti šią schemos informaciją: Visų esybių pavadinimus ir klasifikaciją; Atributų pavadinimus; Pirminius ir išorinius raktus; Duomenų tipus; Paprastus apribojimus (pvz. Null, Unique) ir tikslius teiginius; Ryšius ir jų kardinalumus; Veiklos taisykles. Konceptualus išgautos schemos vaizdas atvaizduojamas esybių-ryšių diagrama (5 pav.). Proj_ID Išt_UID Projektai 1 Turi N Užduotys 1 N Turi N Paskyrimas M Ištekliai 1 Turi N Prieinamumas Užd_UID Priein_UID 5 pav. Išgautą schemą atvaizduojanti ER diagrama 4. Išvados Palikuoninės sistemos turi sukaupusios neįtikėtinai detalias veiklos taisykles ir sudaro organizacijos informacinių srautų pagrindą, tačiau jų palaikymas brangus, o bandymai praplėsti funkcionalumą labai sudėtingi arba neįmanomi. Atvirkštinė inžinerija yra esminis žingsnis atnaujinant ir sutvarkant palikuoninių sistemų 42

34 Veiklos žinių išgavimas iš palikuoninių sistemų: schemų išgavimas ir semantinė analizė pajėgumus. Jos tikslas yra atrasti ir išgauti palikuoniniuose šaltiniuose sukauptas veiklos žinias. Atvirkštinė inžinerija efektyvaus IT sistemos modernizavimo, suteikiančio galimybę integruotai dirbti su naujomis technologijomis ir programomis, pagrindas. Straipsnyje pateikiamas atvirkštinės duomenų inžinerijos algoritmas apima schemos išgavimą ir semantinę analizę. Semantinę analizę sudarantys programų dalinimo, šablonų lyginimo ir tradiciniai leksinės / sintaksinės analizės metodai iš duomenų bazės išgautą schemą papildo semantine informacija. Du pakaitomis veikiantys algoritmai leidžia gerokai sumažinti žmogaus sprendimų poreikį lyginant su egzistuojančiais metodais. 8 atvirkštinės duomenų inžinerijos žingsniai iš palikuoninės duomenų bazės išgauna esybių pavadinimus ir klasifikaciją, atributų pavadinimus, pirminius ir išorinius raktus, duomenų tipus, paprastus apribojimus ir tikslius teiginius, ryšius ir jų kardinalumus, veiklos taisykles. Šios žinios gali būti panaudotos modifikuojant ar keičiant palikuonines sistemas, t.y. perkūrimo, įpakavimo ir migravimo metoduose. Literatūra [1] G. Bakehouse, T. Wakefield. Legacy Information Systems. ACCA [interaktyvus]. 2005, [žiūrėta ]. Prieiga per Internetą: [2] J. Bisbal, D. Lawless ir kt. Legacy Information System Migration: A Brief Review of Problems, Solutions and Research Issues. Trinity College [interaktyvus], 1999, [žiūrėta ]. Prieiga per Internetą: [3] R. H. Chiang. A Knowledge-Based System for Performing Reverse Engineering of Relational Database. Decision Support Systems, 1995, 13, p [4] R. H. L. Chiang, T. M. Barron, ir V. C. Storey. Reverse Engineering of Relational Databases: Extraction of an EER Model from a Relational Database. Data and Knowledge Engineering, 1994, 12:1, p [5] J. Hammer, M. Schmalz ir kt. Knowledge Extraction in the SEEK Project Part I: Data Reverse Engineering. University of Florida [interaktyvus], 2002, [žiūrėta ]. Prieiga per Internetą: [6] S. Horwitz, T. Reps. The Use of Program Dependence Graphs in Software Engineering. Proceedings of the Fourteenth International Conference on Software Engineering [interaktyvus], 1992, [žiūrėta ]. Prieiga per Internetą: [7] J. L. Nhampossa. Strategies to Deal with Legacy Information Systems: A Case Study From the Mozambican Health Sector. University of Oslo [interaktyvus], 2004, [žiūrėta ]. Prieiga per Internetą: [8] J. M. Petit, F. Toumani ir kt. Towards the Reverse Engineering of Denormalized Relational Databases. Proceedings of the Twelfth International Conference on Data Engineering (ICDE), 1996, p [9] P. Santanu, A. Prakash. A Framework for Source Code Search using Program Patterns. Software System Research Laboratory [interaktyvus], 1994, [žiūrėta ]. Prieiga per Internetą: ruple.ieee_tse.pdf/paul94framework.pdf. Knowledge Extraction from Legacy Information Systems: Schema Extraction and Semantic Analysis This article discusses the process of enterprise knowledge extraction from relational database and source code of legacy information systems. Problems of legacy systems and main solutions for them are briefly described here. The use of data reverse engineering and code mining techniques to automatically infer as much as possible the schema and semantics of a legacy information system is analyzed. Eight step data reverse engineering algorithm for knowledge extraction from legacy systems is provided. Hypothetical example of knowledge extraction of legacy information system is presented. 43

35 INVESTICINIŲ IR STATISTINIŲ SKAIČIUOKLIŲ INTEGRAVIMAS NEKILNOJAMOJO TURTO RINKOS INFORMACINIUOSE PORTALUOSE Beata Valeiko, Dainius Golubavičius, Dalia Krikščiūnienė Vilniaus universitetas, Kauno humanitarinis fakultetas Straipsnyje tiriamos elektroninės komercijos modelių taikymo galimybės nekilnojamojo turto rinkoje. Įvertinami portalų privalumai, apdorojant nekilnojamojo turto informacijos gausą bei kuriant informacines sistemas, prieinamas kiekvienam rinkos dalyviui. Aptariamos nekilnojamojo turto tipinio portalo savybės ir šio modelio tobulinimo variantai, pasitelkiant dviejų tipų skaičiuokles: investicijų patarėjus bei nekilnojamojo turto veiklos statistines skaičiuokles. Detaliai aptariami portalų su integruotomis skaičiuoklėmis modeliai. Aptariamos jų funkcinės galimybės bei įtaka nekilnojamojo turto rinkai. 1. Įvadas Nekilnojamojo turto rinka užima didelę pasaulio ekonomikos dalį ir turi tendencijas plėstis. Ši tendencija būdinga ir Lietuvos ekonomikos plėtrai. Šiuolaikinėje nekilnojamojo turto rinkoje gausu informacijos, todėl svarbu tinkamai tą informaciją apdoroti. Straipsnyje tiriama informacinė nekilnojamojo turto bazė, apžvelgiami nekilnojamojo turto portalai, pripažįstami kaip viena iš efektyviausių priemonių sužinoti naujausius nekilnojamojo turto rinkos pasiūlymus ir surasti aktualiausią informaciją, kadangi portalų elektroniniai katalogai operatyviai atnaujinami. Nors nekilnojamojo turto portalai turi didžiausias bei įvairiausias duomenų bazes apie nekilnojamojo turto objektus,.rinką ir jos vystymąsi, tačiau klientams nepakanka esamų informacijos paieškos funckijų. Straipsnyje siūloma praplėsti nekilnojamojo turto portalų interaktyvias funkcijas, juose integruoti nekilnojamojo turto investicines bei statistines skaičiuokles. Investicijos į nekilnojamojo turto portalų plėtrą ir jų informacinių modelių tobulinimą padėtų išsamiau informuoti visuomenę apie nekilnojamojo turto rinkos pokyčius bei galimybes, padidinti konkurencingumą tarptautiniame lygmenyje ir sudaryti sąlygas taikyti modernesnius informacijos valdymo būdus.. 2. Informacinės sistemos nekilnojamojo turto rinkoje Nekilnojamojo turto rinka tai sudėtinga struktūra, kurią sąlygoja įstatymais ir kitais norminiais dokumentais apibrėžtas mechanizmų rinkinys, kurių dėka yra perduodama nuosavybės teisė bei su ja susiję interesai, nustatoma objekto kaina, suskirstoma žemė pagal jos naudojimo būdą. Per pastaruosius metus nekilnojamojo turto rinkos efektyvumas išaugo brokerių, vertintojų, juristų, nekilnojamojo turto kompanijų, finansinių agentūrų ir valdžios organų glaudaus bendradarbiavimo dėka, sustiprėjo informacijos mainų poreikis tarp šių institucijų ir klientų Nekilnojamojo turto rinka bei jos specifika Pastaruoju laikotarpiu Lietuvos nekilnojamojo turto rinka yra ypač aktyvi. Paskelbus, jog Lietuva ketina tapti Europos Sąjungos (ES) nare, nekilnojamojo turto rinkoje ėmė kilti būstų, komercinių patalpų ir statybos darbų kainos. Lietuvai įstojus į ES, nekilnojamojo turto rinkos aktyvumas nemažėja (1 ir 2 pav.), o būstų kainos vis labiau kyla Dirbančiųjų skaičius Įmonių skaičius Metai pav. Nekilnojamojo turto rinkos statistika 2 pav. Pajamos už parduotas prekes ir paslaugas nekilnojamojo turto rinkos sektoriuje, tūkst. Lt (Šaltinis: Statistikos departamentas, autorių apdoroti duomenys) 44

36 Beata Valeiko, Dainius Golubavičius, Dalia Krikščiūnienė Statistikos departamento duomenimis nekilnojamojo turto rinka sparčiai vystosi. Nekilnojamojo turto sektorius kasmet sudaro nuo 5,45% iki 9,11% (nuo 1999 iki 2005 metų) bendro vidaus produkto. Ebiz duomenimis [6] Lietuvoje pastaruoju metu gerokai išaugo statyboms ir nekilnojamajam turtui skirtų informacinių sistemų, o ypač interneto svetainių. Lietuvoje labiausiai paplitusios dviejų tipų nekilnojamojo turto svetainės: nekilnojamojo turto įmonių tinklapiai ir nekilnojamojo turto portalai. Nekilnojamojo turto informacinė sistema tai nekilnojamojo turto komercinės veiklos vykdymas, pagrįstas informacijos (teksto, vaizdo, garso) apdorojimu ir persiuntimu, pasitelkiant elektronines priemones. Nekilnojamojo turto internetinės sistemos taikomos daugeliui veiklos rūšių: elektroninei prekybai turtu ir paslaugomis, skaitmeninės informacijos pateikimui, reklamai Internete, tiesioginiam marketingui, garantinėms konsultacijoms, pasitelkiant elektroninio ryšio priemones ir daugeliui kitų. Nekilnojamojo turto internetinė komercija- dar jauna tradicinės prekybos atmaina, tačiau paskutiniojo dešimtmečio statistiniai kiekybiniai bei kokybiniai rodikliai rodo milžinišką jos vystymosi potencialą. Lyginant IT intensyvumą keturių IT taikymo erdvių atžvilgiu (bendrojo IT išvystymo, elektroninio verslo, produktų bei paslaugų pasiūlos internetu ir bendravimo su vartotoju), informacinių technologijų vystymasis nekilnojamojo turto šakoje beveik prilygsta bendrajam IT vidurkiui visų verslo šakų (logistika, metalurgija, maisto pramonė, laivininkystė, tekstilė, chemija ir kt.) atžvilgiu (3 pav.). visos šakos; vidurkis; nekilnojamojo turto įmonės; Keturiose erdvėse: A IT išvystymas; B elektroninis verslas; C produktų ir paslaugų pasiūla Internetu; D bendravimas su vartotojais 3 pav. Nekilnojamojo turto IT sektoriaus intensyvumas Ištyrus paieškos sistemų ir duomenis, nustatyta, kad apie 25 procentus Lietuvos nekilnojamojo turto įmonių turi interneto svetaines (4 pav.). Interneto sistemas įdiegusių įmonių pasiskirstymas Lietuvos miestuose labai netolygus (5 pav.), nors internetines technologijas naudojantys vartotojai domisi visoje Lietuvos teritorijoje esančiu nekilnojamuoju turtu ir juo prekiaujančių įmonių pasiūlymais. 2 Turinčios interneto svetainę Vilnius Kaunas 75% Neturinčios interneto svetainės 60% Klaipėda Šiauliai Kiti 18% 4 pav. Įmonės, organizacijos, kurių veikla susijusi su nekilnojamuoju turtu, turinčios interneto svetainę (Šaltinis: Lietuvos internetinės paieškos sistemos, autorių apdoroti duomenys) 25% % 5 pav. Interneto sistemas turinčių įmonių pasiskirstymas Lietuvos miestuose 2.2. E-komercijos modelių panaudojimas nekilnojamojo turto informacinėms sistemoms kurti Informacinės duomenų bazės Mūsų Lietuva statistika liudija, kad šiemet interneto svetainių lankytojai dažniausiai ieškojo informacijos apie nekilnojamąjį turtą ir su jo valdymu susijusiais klausimais. Šia rinka internetu domėjosi beveik 100 tūkstančių žmonių. Nekilnojamojo turto rinkoje egzistuoja daug informacijos keitimosi procesų bei specializuotų e-ryšių tarp rinkos dalyvių. Rinkos dalyviai tai verslo įmonės (B), valstybinės ir valdžios institucijos (G), klientai (C). Dažniausiai naudojami e-komercijos modelių tipai pavaizduoti 6 paveikslėlyje. Tai e-komercijos modeliai verslas-verslui (B2B), verslas-klientui (B2C), verslas- valstybinės institucijos (B2G). 3% 9% 45

37 Investicinių ir statistinių skaičiuoklių integravimas nekilnojamojo turto rinkos informaciniuose portaluose 6 pav. E-komercijos procesai tarp nekilnojamojo turto rinkos dalyvių (Šaltinis: autoriai) Pastaraisiais metais nekilnojamo turto rinkoje Lietuvoje pasiūla atsilieka nuo paklausos vos pasirodęs patrauklus objektas nuperkamas per kelias valandas. Todėl būsto ar komercinių patalpų paieška ir įsigijimas tampa vis labiau panašūs į varžybas kas pirmiau pamatys ar sužinos apie naujausią pirkimo-pardavimo pasiūlymą. Nekilnojamojo turto rinka pasižymi ypatinga informacijos gausa. Prieš kelis metus nekilnojamo turto sektoriuje pirkėjai ir pardavėjai skelbė informaciją specialiuose leidiniuose, ieškojo reklaminių skelbimų prekybos centruose arba naršė nekilnojamo turto agentūrų interneto svetainėse. Tačiau šiandieninių pirkėjų ir pardavėjų poreikių nebetenkina čia skelbiama neišsami ir pasenusi informacija. Informacijai aptikti ar įvairių šaltinių informacijai integruoti vienoje paieškos sistemoje kuriami nekilnojamojo turto portalai. Juose galima rasti klientų ir įmonių skelbimus, didžiausių statybos bendrovių pasiūlymus ir nemažai kitos informacijos, naudingos investuojant į nekilnojamąjį turtą. 3. Nekilnojamojo turto informacinių portalų modeliai Šiuo metu Lietuvoje sukurta nemažai nekilnojamo turto portalų, tokių kaip aruodas.lt, namai.lt, e- namai.lt, city24.lt, domoplius.lt, edomus.lt. Lietuvoje nekilnojamo turto portalai skirti daugiausia privatiems vartotojams, norintiems įsigyti ar nuomoti būstą. Mažiau dėmesio skiriama pardavėjams - nekilnojamo turto agentūroms ir statybos bendrovėms. Nekilnojamojo turto informacinių portalų kūrimas vystomas dviem pagrindinėmis kryptimis: didinant jų funkcionalumą klientų ar įmonių poreikių atžvilgiu ir tobulinant jų užbaigtumą, t.y. pasiūlant tokį funkcijų rinkinį, kuris leistų pilnai atlikti paieškos, įsigijimo ar kitus pasirinktus nekilnojamojo turto valdymo scenarijus (7 pav.). 7 pav. Nekilnojamojo turto portalo užbaigtumas lyginant su funkcionalumu (Šaltinis: [2]) Nekilnojamo turto interneto portalai bet kuriuo paros metu leidžia atlikti informacijos paiešką, rūšiavimą ar nuolat gauti naujausią informaciją apie dominančius objektus elektroniniu paštu pagal nurodytus paieškos kriterijus. Nekilnojamojo turto portaluose informacija gali būti lengvai ir operatyviai atnaujinama. Skelbimo dydis Internete neribojamas, o dominantis objektas surandamas greitai. Apie objektą pateikiama labai išsami informacija (planai, nuotraukos, virtualūs turai), todėl su juo galima pakankamai gerai susipažinti jo net 46

38 Beata Valeiko, Dainius Golubavičius, Dalia Krikščiūnienė neaplankius. Taupomas klientų laikas ir pinigai, naudos turi investuotojai, savininkai bei nekilnojamojo turto įmonės (7 pav.). Nekilnojamojo turto Interneto puslapiuose dažnai skelbiama ir papildoma informacija, susijusi su nekilnojamo turto sektoriumi juridinė informacija, notarų, lizingo įmonių kontaktai, paskolų teikimas, ekspertų patarimai, apžvalginiai straipsniai bei tyrimai. Interneto tyrimų agentūros Niesen//NetRatings neseniai atliktas tyrimas rodo, kad vartotojai, užsiimantys nekilnojamo turto paieška, pasižymi pastovumu ir ypatingai dažnai lankosi pasirinktuose portaluose: suteikę pirmenybę kuriam nors resursui, jie bemaž nebesilanko kituose. Vidutiniškai per dieną kiekvieną iš šių portalų aplanko iki 6000 besidominčių nekilnojamuoju turtu, skelbimų skaičius siekia Kad vartotojas galėtų lengviau bei geriau suprasti, kur palankiausia dabartiniu metu investuoti pinigus, jam būtina nuolat analizuoti rinkos būklę. Tam reikalingos įvairios skaičiuoklės, padedančios apibendrinti sukauptą informaciją ir priimti spendimus. Nekilnojamojo turto rinkoje naudingos dviejų tipų skaičiuoklės: Skaičiuoklės investicijų patarėjai. Jos padeda ne tik nuspręsti, ar verta investuoti į nekilnojamąjį turtą, bet ir apskaičiuoti įvairius rodiklius rinkos būklei įvertinti. Jos tinka tiek pavienių asmenų turto valdymo klausimams spręsti, tiek stambiausiems investiciniams projektams. Statistinės nekilnojamojo turto veiklos skaičiuoklės portalai sukaupia pačią didžiausią nekilnojamojo turto informacijos bazę, todėl turi palankiausias sąlygas statistiniams skaičiavimams atlikti. Pagal šiuos skaičiavimus galima pakankamai patikimai įvertinti rinkos svyravimus, tendencijas ir numatyti būsimus rodiklius. Ši informacija reikalinga tiek eiliniam vartotojui, tiek valstybės institucijoms. Siūlomas tipinis nekilnojamojo turto portalo modelis su jame integruotomis skaičiuoklėmis pateiktas 8 pav. 8 pav. Nekilnojamojo turto portalo modelis(šaltinis: autoriai) 4. Nekilnojamojo turto portalo skaičiuoklės Nekilnojamojo turto skaičiuoklės yra skirtos nekilnojamojo turto brokerių, investuotojų, vertintojų darbinei veiklai, jų sprendimų kokybei gerinti. Jos padeda realiai įvertinti finansinę padėtį ir galimybes, norint pirkti ar parduoti nekilnojamąjį turtą. Naudojant kompiuterines projektų vertinimo programas bei statistinius duomenis, supaprastėja ir patogiau tampa formuoti patį investicinį projektą, nereikia papildomai skirti laiko finansiniams ir rizikos įvertinimo rodikliams skaičiuoti. Tačiau Lietuvoje kol kas tokio pobūdžio rinkiniai nėra prieinami. Viena iš svarbiausių tokios programinės įrangos riboto taikymo internete problemų- tai kompanijų dirbančių nekilnojamojo turto rinkoje, nuostata nesidalinti turima informacija. Todėl nesukuriamos prielaidos sukurti išsamią duomenų bazę, tinkamą patikimai analizei atlikti. Taigi investuotojas, norėdamas atlikti nekilnojamojo turto investicijų analizę, neturi galimybių atlikti tai elektroniniu būdu, o turi pasitelkti į pagalbą įvairių sričių specialistus ir konsultantus (finansininkus, mokesčių patarėjus, teisininkus ir pan.). Sukaupus tiek pradinių duomenų, tiek ekspertų turimą patirties informaciją bei realizavus metodus analitiniams skaičiavimams atlikti, pagerėtų visų sritčių nekilnojamojo turto specialistų darbo kokybė. Galima išskirti tokius pagrindinius rinkos dalyvius, kuriems naudingas būtų skaičiuoklių naudojimas kasdieniniame darbe: nekilnojamojo turto agentai; vertintojai ir patarėjai; turto vadybininkai; bankininkai; mokesčių patarėjai ir teisininkai; nekilnojamojo turto pirkėjai bei pardavėjai, nuomininkai bei nuomotojai; Valstybinės institucijos; 47

39 Investicinių ir statistinių skaičiuoklių integravimas nekilnojamojo turto rinkos informaciniuose portaluose kiti dalyviai. Inžinieriai, architektai, komercinių bankų darbuotojai bei sutarties dalyviai gali prisidėti analizuojant turtą ir padėti išspręsti problemas ar atsakyti į tam tikrus klausimus Nekilnojamojo turto skaičiuoklės investicijų patarėjai Nekilnojamojo turto valdymo tikslams skaičiuoklės buvo pradėtos naudoti sudėtingiems matematiniams skaičiavimams su nedaug pradinių duomenų atlikti, vėliau atvirkščiai reikalaujantiems daug darbo techniniu požiūriu, tačiau nesudėtingiems matematiniu. Šiuo metu paprastai reikia daug duomenų ir naudojami sudėtingesni jų apdorojimo metodai. Užsienio šalių internetiniuose tinklalapiuose pateikiama daugybė nekilnojamojo turto investicijų skaičiuoklių. Lietuvoje jos nėra plačiai naudojamos bei žinomos bendrame vartotojų rate, dažniausiai prieinamos specializuotoms įmonėms, teikiančioms mokamas paslaugas. Esant dabartiniam nekilnojamojo turto rinkos aktyvumui, šios skaičiuoklės turėtų būti viešai prieinamos. Automatinis investicijų pelningumo nustatymas turi daug privalumų: kompiuteriai apdoroja duomenis daug sparčiau už žmogų; programa galima spręsti problemas, kurias yra sunku išspręsti žmogui. Galima taikyti sudėtingesnius modelius, kurie gali atspindėti turto rinkos jėgas; didelės atminties apimtys leidžia saugoti ir apdoroti didelius reikalingos informacijos kiekius; sumažinamas investuotojo darbo krūvis. Investuotojas ir kiti specialistai gali darbą atlikti daug greičiau ir kokybiškiau. Lietuvoje 2005 metų rudenį naujas nekilnojamojo turto portalas city24 pradėjo naudoti paskolų skaičiuokles ( 9 pav.). Nekilnojamojo turto portalo city24 paskolų siūlomos skaičiuoklės. 9 pav. Nekilnojamojo turto portalo city24 paskolų siūlomos skaičiuoklės (Šaltinis: city24 NT portalas) Toliau pateikiamas investicijų patarėjų skaičiuoklių modelis nekilnojamojo turto portale, 10 pav. Nekilnojamojo turto skaičiuoklių investicijų patarėjų modelis. 10 pav. Nekilnojamojo turto skaičiuoklių investicijų patarėjų modelis (Šaltinis: autoriai) 48

40 Beata Valeiko, Dainius Golubavičius, Dalia Krikščiūnienė Skaičiuoklių duomenų suvestinių pavyzdžiai, 11 pav. Jautrumo analizės lango dalies pavyzdys (JAV NT portalo skaičiuoklė) ir 12 pav. Nuomos suvestinės bei analizės lango dalies pavyzdys (JAV NT portalo skaičiuoklė). Jautrumo analizė. Leidžia vartotojui įvesti skirtingus finansinius kintamuosius ir atlikti pokyčių įtakos investicijų struktūrai ir laukiamam pinigų srautui naalię. Šioje analizėje ir visuose languose esančiuose laukeliuose informacija gali būti pakeista bet kuriuo metu. Rezultatų laukuose pateikiami apskaičiavimai. 11 pav. Jautrumo analizės lango dalies pavyzdys (Šaltinis: JAV NT portalo skaičiuoklė) Nuomos suvestinė bei analizė. Investicijų į biurų/komercinės paskirties turtą analizė pateikia nuomos santrauką/suvestinę tikslesniam neužimto ploto ir nuomos priemokų (dėl kainų kilimo) modeliui sudaryti. Įvedus numatomą neužimtą plotą bei nuomininkų pageidaujamus pagerinimus, galima įvertinti pagerinimų išlaidas ploto vienetui tiek išnuomotam, tiek ir neužimtam plotui. 12 pav. Nuomos suvestinės bei analizės lango dalies pavyzdys (Šaltinis: JAV NT portalo skaičiuoklė) 4.2. Nekilnojamojo turto statistinės skaičiuoklės Nekilnojamojo turto rinkoje vos ne kasdien atsiranda papildomos informacijos reikalingos konkrečiam sprendimui priimti. Siekiant ją inkamai naudoti, būtina informaciją pdoroti ir saugoti duomenų bazėse. Sprendimams skirtos informacijos vertinimą galima sieti su tais tiesioginiais informacinių pranešimų poveikiais, kurie gali padėti rengiant, priimant ir net realizuojant atitinkamus sprendimus. Pavyzdžiui, galima vertinti informacijos gavimą laiko požiūriu: kai ji gaunama laiku ir kai sulaukiama visa reikalinga sprendimams informacija, t. y. jos operatyvumą, išsamumą, patikimumą ir naudingumą. Sprendimams naudojama informacija gali būti nepakankama, pakankama ir perteklinė. Remiantis tokia informacija, sprendimai priimami esant neapibrėžtumui. Informacijos naudingumą gali lemti jos detalumas, aiškumas, išsamumas, duomenų naudingumo ir kainos santykis (vertingumas), palyginamumas, patikimumas, skaitmeninis informacijos pateikimas, duomenų pateikimo formos tinkamumas. Siekiant naudoti portalus sprendimams priimti, sudaromi trijų komponenčių skaičiuoklės modelis: duomenų įvedimo, apdorojimo bei pateikimo (13 pav.). 13 pav. Statistinės skaičiuoklės modelis (Šaltinis: autoriai) 49