Objektinių programų projektavimo metodai ir priemonės kursinis darbas

Įvadas Apžvelgiama egzistuojančių GIS sistemų sprendimų privalumai ir trūkumai. Pateikiamas sprendimas kuris išspręstų dinamiško erdvinių ir verslo duomenų integravimo problemą. Pristatomos Oracle DBVS panaudojimo galimybės minėtos problemos sprendime, bei suprojektuota dinamiškos GIS sistemos veikimo schema. Tokios siste­mos veikimui užtikrinti suprojektuotas komponentas, kurio veikimo principas paremtas veiklos taisyklių koncepcija. Komponento veikimui patikrinti, pateiktas teorinis tokios GIS sistemos panaudojimo pavyzdys. Sėkmingam verslo funkcionavimui nepakanka vien tik sukaupti duomenis apie įmonės veiklą. Efektyvus operavimas duomenimis ir greitas bei aiškus rezultatų pateikimas yra aktuali problema šių dienų įmonėse nepriklausomai nuo veiklos srities. Nenaudojant specialių priemonių duomenų valdymas darosi sudėtingas. Erdvinės informacijos analizės naudą pripažįsta ir vis labiau vertina verslo įmonės ir organizacijos, per GIS technologijas atrasdamos naujus verslo sprendimus, klientus ir tolimesnės plėtros galimybes [1]. Darbo objektas -objektinis projektavimas- sistemų projektavimas, naudojant savarankiškus objektus ir objektų klases. Uždaviniai: 1. Išaiškinti kaip programinės įrangos projektavimas gali būti pristatytas kaip sąveikaujančių objektų rinkinys, kurie kontroliuoja savo stovį ir operacijas 2. Aprašyti veiksmus objektinio projektavimo procese 3. Pristatyti įvairius modelius, kurie apibūdina objektinį projektavimą 4. Parodyti kaip UML gali būti panaudota šių modelių atvaizdavimui 1.Objektinio projektavimo charakteristikos 1.1. Objektinio projektavimo sistemos sandara Objektai yra realaus pasaulio arba sistemos būsenų abstrakcijos ir valdo patys save. Objektai yra nepriklausomi ir apjungia būvio ir atvaizdavimo informaciją. Sistemos funkcionalumas išreiškiamas objekto servisais. Bendros duomenų sritys yra eliminuotos. Objektai bendrauja perduodami pranešimus. Objektai gali būti paskirstyti ir gali būti vykdomi nuosekliai arba lygiagrečiai. 1 pav. Sąveikaujantys objektai Geografinė informacinė sistema (GIS) - informacinė sistema skirta darbui su erdvine ir aprašomąja informacija. Sistema skirta skaitmeninių koordinuotų erdvėje duomenų kaupimui, saugojimui, vaizdavimui, redagavimui, integ­ravimui bei analizei. GIS sudaro programinė įranga, kuri jungia geografinę informaciją (kur objektai lokalizuoti) su aprašomąja infor­macija (į ką objektai panašus). Skirtingai nuo plokščio popierinio žemėlapio, GIS gali turėti daug sluoksnių infor­macijos po jo paviršiumi. Tokiu būdu galima matyti struktūrą ar tendencijas verslui būdingoje informacijoje, rodyti ir apskaičiuoti optimalius transporto priemonės maršrutus, sukurti norimas linijas ir daug daugiau. Tipinę GIS sistemos architektūrą sudaro trys skirtingos dalys [3]: 1.Duomenų laikymas - apima įvairių erdvinių ir aprašomųjų duomenų sandėliavimą organizacijos viduje. Šitie duomenų sandėliai paprastai turi savyje informaciją keliuose nesuderinamuose duomenų formatuose. Taikomosios paslaugos - susideda iš GIS Taikomojo Serverio ir Tinklo Serverio, kurie yra atsakingi už duome­nų prieigą, apdorojimą ir vartotojo aptarnavimą per kliento darbo vietą (klientinę programinę įrangą). Tinklo Serveris, tai GIS Tinklo Serveris, kuris leidžia komunikuoti su vartotojų standartiniais interneto serveriais to­kiais kaip Apache, Microsoft HS ir pan. Taikomasis GIS Serveris yra funkcinis GIS paslaugų pagrindas jis sutei­kia erdvinių duomenų integravimą ir transformavimą. 2.Klientinė darbo vieta - klientais gali būti visi informacinių sistemų vartotojai esantys bet kuriame pasaulio taš­ke. Klientas paprastai kreipiasi į GIS taikomąsias paslaugas prašydamas atvaizduoti tam tikrą erdvinių duomenų sluoksnį ir jame esančius objektus. Kliento darbo vieta gali būti interneto naršyklės, mobilieji įrenginiai ir t.t. Ši trijų dalių architektūra yra ideali įmonės sistemoms, nes ji įgalina portatyvių ir išplečiamų sistemų konstravimą. Ji leidžia GIS sistemoms supaprastinti skirtingų duomenų šaltinių integraciją, suteikiant funkcionalumo karkasą, kuris leidžia keistis žemėlapiais ir duomenimis tinkle. 1.2. Objektinio projektavimo privalumai Paprastesnis palaikymas. Objektai gali būti suprantami kaip atskiros esybės. Objektai yra atitinkami pakartotinio panaudojimo komponentai. Kai kurių sistemų objektams gali būti priskiriamos realaus pasaulio esybės. Objektinė analizė, projektavimas ir programavimas yra susiję bet skirtingi. Objektinė analizė rūpinasi taikomosios programos objektinio modelio srities vystymu. Objektinis projektavimas rūpinasi objektiniais sistemos modeliais reikalavimų realizavimui. Objektinis programavimas rūpinasi objektinio projektavimo realizavimu, naudojant objektinę programavimo kalbą tokią kaip Java arba C++. Objektai ir objektų klasės. Objektai yra programinės įrangos sistemų dalys, kurios atstovauja realaus pasaulio daiktus arba sistemos esybes. Objektų klasės yra objektų šablonai. Jie gali būti panaudojami objektų kūrimui. Objektų klasės gali paveldėti kitų objektų klasių savybes ir metodus. 1. Objektai 2. Objektas yra esybė, kuri turi būseną ir apibrėžtą aibę operacijų, 3. kurios veikia jo būseną. Būvis yra pristatomas kaip objekto savybių 4. rinkinys. Su objektu susietos operacijos teikia servisus kitiems 5. objektams, kurie jų reikalauja kai reikalingas koks nors apskaičiavimas. 6. Objektai yra kuriami pagal objektų klasių apibrėžimą. Objekto klasės 7. apibrėžimas naudojamas kaip objekto šablonas. Joje yra nurodytos 8. visos savybės bei servisai kurie turėtų būti susieti su šios klasės objektu 9. Unifikuota modeliavimo kalba (UML) 10. Keletas skirtingų objektinio projektavimo žymėjimų buvo pasiūlyti 1980’ais ir 1990’ais 11. UML (Unified Modeling Language ) yra šių žymėjimų suvienijimas UML apibudina įvairių modelių žymėjimus, kurie gali būti pateikti per objektinę analizę ir projektavimą Dabar tai de facto standartas objektiniam modeliavimui Darbuotojo objekto klasė (UML) Per paskutinius dešimtį metų sukurta daugybė GIS taikomųjų sistemų , kurios užtikrino sėkmingą erdvinės infor­macijos produktų pateikimą tiek viešajame, tiek ir privačiuose sektoriuose. Neabejotinai šios sistemos buvo naudingos, tačiau dauguma organizacijų vis dar susiduria su GIS aplikacijų diegimo savo veiklos srityje proble­momis. Pavyzdžiui, Kauno miesto teritoriją apimantis Verslo GIS sprendimas [4] vartotojui suteikia daug informa­cijos apie Kaune esančias įmones. Jų pateikiamą informaciją galima peržiūrėti įvairiais pjūviais, tačiau naudojimasis šia informacija tampa ribotas, kadangi ją galime tik peržiūrėti, o rezultatus turime atsirinkti patys ir negalime patys pasirinkti rezultatų vaizdavimo būdo. Panašaus tipo sistemų apstu tiek Lietuvoje, tiek ir užsienyje (Maps.lt Žemė­lapis.It, multiMap ir t.t.). Google maps API suteikia lanksčias funkcijas, kurių dėka galima operuoti Google duome­nų bazėje sukaupta erdvine informacija. Tačiau šių funkcijų naudojimas reikalauja papildomų programavimo žinių ir darbų norint pridėti naują funkciją konkrečiame vartotojo intemetiniame puslapyje kuriame jis pateikia erdvinę informaciją. Mažos ir vidutinio dydžio įmonės nori naudotis optimaliais GIS sprendimais už mažiausią kainą. Dėl šios prie­žasties kiekviena įmonė negali sau leisti įsigyti nuosavų skaitmeninių žemėlapių bei reikiamos programinės įrangos jų administravimui bei apdorojimui. Akivaizdu, kad yra tikslinga sukurti vieną erdvinės informacijos saugyklą, kurioje būtų talpinama erdvinė informacija ir šia informaciją galėtų naudoti daugelis įmonių. Taip pat yra būtina maksimaliai sumažinti programinės įrangos kiekį, kurį turi įsidiegti įmonė tam, kad savo taikomosiose programose galėtų naudotis GIS paslaugomis. Norint įgyvendinti šiuos tikslus, reikia sukurti internetinę paslaugą, kuri sugebės aptarnauti įmonių poreikius nuotoliniu būdu. Siekiamas sprendimas realizuojamas naudojantis Oracle programine įranga. Ši įranga papildoma nauju kompo­nentu, kuris realizuoja duomenų integravimo dalį. Kuriamos GIS sistemos sudedamosios dalys buvo paminėtos ankstesniame skyrelyje, 2 paveikslėlyje pateikiama schema, kuri parodo kaip šios dalys susiję tarpusavyje. Oracle DB Server i Oracle application server 2 pav. Dinamiškos GIS sistemos architektūra Oracle DataBase - Oracle DBVS serveris, kuriame saugomos duomenų bazės su erdvinių erdvine informacija [5]- Oracle application server - taikomųjų uždavinių serveris, kuriame veikia MapViewer komponentas, turintis galimybę komunikuoti su Oracle DataBase serveriu ir naudoti erdvinius duomenis žemėlapių generavimui. [6] Business VVeb Server - šiame serveryje yra vartotojo taikomojo programa, kuri naudoja duomenų integravimo komponentą. Vartotojo taikomoji programa aprūpina komponentą reikalingais parametrais, kad šis galėtų atlikti duomenų integravimo funkciją. 2.Objektinių programų projektavimo prieones 2.1. Dinamiškos sistemos modelis Paveldimumo privalumai 1. Tai abstrakcijos mechanizmas, kuris gali būti panaudotas įvairių esybių klasifikavimui 2. Tai yra pakartotinio panaudojimo mechanizmas tiek projektavimo, tiek programavimo lygyje 3. Paveldimumo grafas yra organizacinių žinių apie sritis ir sistemas šaltinis Paveldėjimo problemos 1. Objektinės klasės nėra savarankiškos ( self-contained ) ir savyje turinčios visą objekto kodą. Jas sunku suprasti nesiremiant jų superklasėmis 2. Projektuotojai turi tendenciją pakartotinai pasinaudoti analizės metu sukurtu paveldimumo grafiku. Tai gali iššaukti reikšmingą efektyvumo praradimą 3. Paveldimumo grafai analizei , projektavimui ir realizavimui turi skirtingas funkcijas ir turi būti palaikomi atskirai Paveldimumas ir objektinis projektavimas Yra įvairių požiūrių sprendžiant klausimą ar paveldimumas yra fundamentalus objektiniam projektavime ◦ Požiūris 1. Paveldimumo hierarchijos identifikavimas arba tinklas yra fundamentali OOD dalis. Akivaizdžiai tai gali būti realizuota naudojant OOPL ◦ Požiūris 2. Paveldimumas yra naudinga realizacijos koncepcija, kuri leidžia atributų ir operacijų apibrėžimų pakartotinį panaudojimą. Identifikuojant paveldimumą projektavimo stadijoje suformuojami realizacijai nebūtini apribojimai Paveldimumas įveda sudėtingumą ir tai yra nepageidaujama, ypač kritinėse sistemose Objektai ir objektų klasės santykiauja su kitais objektais ir objektų klasėmis UML’e apibendrinti ryšiai yra parodyti asocijacijomis Asociacijos gali turėti pastabas, kurios aprašo asociaciją Asociacijos yra bendros bet gali iš anksto skelbti, kad objekto atributas yra asocijuotas objektas, arba kad metodas remiasi asocijuotu objektu Kuriama GIS sistema turės palengvinti verslo duomenų ir erdvinės informacijos integravimą nepriklausomai nuo duomenų struktūros. Tokiu būdu naudojantis ta pačia sistema ir tais pačiais erdviniais duomenimis, skirtingo tipo verslo duomenys galės būti susiejami su erdvine informacija. Operavimui erdvinais duomenimis buvo pasirinkta Oracle DBVS, kadangi ji turi visas reikalingas funkcijas bei komponentus, kurie užtikrina erdvinės informacijos įrašymą, saugojimą, skaitymą bei apdorojimą formuojant skaitmeninius žemėlapius su Ajax funkcionalumu. Šios paslaugos realizavimui reikalingi šie komponentai: • Erdvinių duomenų (Oracle spatial) serveris; • MapVievver serveris; • Duomenų integravimo komponentas. Erdvinių duomenų (Oracle spatial) serveris Oracle Spatial yra Oracle DBVS komponentas, kuris suteikia galimybę naudotis efektyviais GIS ir LBS (Vietovės nustatymo paslaugos) sprendimais ir yra pagrindas sudėtingoms GIS taikomosioms programoms, kurios reikalauja didelės erdvinės informacijos apdorojimo spartos. Oracle Spatial palaiko visus pagrindinius erdvinės informacijos tipus bei duomenų modelius. MapVievver serveris Taikomasis Oracle Serveris MapVievver (OracleAS MapVievver) yra programuojamas įrankis kuris skirtas tam, kad generuotų žemėlapius, naudodamas erdvinius duomenis, valdomus Oracle Spatial ar Oracle Locator (taip pat vadinamo tiesiog Locator). OracleAS MapVievver suteikia įrankius, kurie paslepia erdvinių duomenų užklausų ir žemėlapio generavimo sunkumą, suteikdami įvairių pasirinkimų galimybę labiau pažangiems vartotojams. Šitie įrankiai gali būti išdėstyti nepriklausomu nuo platformos būdu ir yra suprojektuoti taip, kad būtų integruojami su žemėlapius teikiančiomis paslaugomis. OracleAS MapVievver yra traktuojamas kaip Taikomojo Oracle Serverio dalis. Jo svarbiausia dalis yra J2EE taikomojo programa, kuri gali būti įdiegta į J2EE konteinerį. 2.2.Duomenų integravimo komponentas Šis komponentas atlieka verslo duomenų parengimą integravimui su erdviniais duomenimis. Kadangi daugelis įmonių žemėlapius nori vaizduoti internetiniuose puslapiuose, bei suteikti tam tikrą žemėlapių ir objektų juose val­dymą, komponentas suteikia sąsają, kurios dėka įmonės intemetiniame puslapyje būtų galima pavaizduoti žemėlapį bei suteikti jam norimą funkcionalumą. Komponentas turi metodus, kurie susieja verslo duomenis su erdviniais duomenimis nereikalaujant didelių vartotojo pastangų. T.y. vartotojas nežino ir neturi nieko bendra su tuo, kokiu būdu ir kokiam pavidale yra saugomi erdviniai duomenys. Jis žino tik tai tą, ką jis nori matyti. Šiam tikslui pasiekti, galima iš anksto parengti veiklos taisyklių šablonus, kurių dėka verslo duomenys būtų susiejami su erdvine infor­macija. Veiklos taisyklių aprašymui reiktų naudoti standartizuotą metodą. Vienas iš tokių priimtiniausiųjų metodų būtų Business Rules Solutions RuleSpeak [7]. Šis metodas turi nestruktūrinių veikios taisyklių aprašymo šablonais galimybę. Erdvinių ir verslo aprašomųjų duomenų integravimui nestruktūrizuotų veiklos taisyklių pilnai pakanka. Duomenų integravimo komponentas veikia kaip tarpininkas tarp žemėlapį generuojančios programinės įrangos ir klientinės darbo vietos. Kadangi siekiama dinamiško duomenų integravimo, todėl žemėlapio generavimas taip pat turi būti dinamiškas. Tai reiškia, jog šis komponentas išanalizavęs vartotojo pateikiamus verslo duomenis ir atsižvelgęs į vartotojo nurodytus parametrus turi pateikti atitinkamą žemėlapio fragmentą. Žemėlapio vaizdavimo parametrai nurodomi veiklos taisyklių pagalba. Tokiu būdu vartotojas naudojantis šį komponentą savo aplikacijoje nieko nežino apie GIS informacijos struktūrą esančią GIS serveriuose. Kaip buvo pateikiama 3 pav. duomenų integravimo komponentas gali būti naudojamas kaip API įvairiose varto­tojų aplikacijose. Vartotojas išlaisvinamas nuo komponento programavimo darbų. Norint tinkamai panaudoti šį komponentą tereikia jį tinkamai sukonfigūruoti: • Reikia nurodyti verslo duomenų šaltinį. Gali būti atmintyje laikomos struktūros arba informacija vartotojo duo­menų bazėje. Reikia nurodyti prisijungimą prie žemėlapius generuojančios paslaugos. Šiuo atveju tai yra MapVievv'er. Šis Oracle DBVS komponentas tradicinėse GIS sistemose yra valdomas javaScript'ais tokiu būdu generuojantis žemėlapius su Ajax funkcionalumu. Duomenų integravimo komponento paskirtis yra realizuoti funkcijas, kurios dinamiškai generuotų reikiamus parametrus šioms Java Script funkcijoms, tokiu būdu galima gauti dinamiškus žemėlapius. • Reikia nurodyti taisyklių rinkinį pagal kurį būtų filtruojami verslo duomenys ir susiejami su erdviniais duome­nimis pagal veiklos taisyklėse nurodytus kriterijus. Duomenų integravimo komponentas turi būti aprūpintas duomenų srautu iš išori­nės duomenų bazės. Taip pat vartotojas turi nurodyti pagal kokias veiklos taisykles jis nori interpretuoti duomenis. Surinkus visą reikimą informaciją, įvyksta komunikacija su MapVievver'iu ir gaunamas norimas žemėlapis. Vartotojo taikomojoje programoje tereikia vieną kartą nurodyti veiklos taisykles pagal kurias turės būti interpre­tuoti duomenys. Kitaip tariant komponentas yra įprogramuojamas vartotojo internetiniame puslapyje ir kiekviena kartą veiklos taisyklių nurodinėti nereikia. Kuriant kita puslapį galima nurodyti kitokias taisykles. Taip pat pakanka vieną karta nurodyti verslo duomenų srautą ENTERPRISE DATA LOADER moduliui. Vėliau šie duomenys bus di­namiškai integruojami su erdvine informacija pagal užduotas veiklos taisykles. Supaprastintas veiklos taisyklių šablonas galėtų atrodyti taip: 1. tai duomenys apibūdinantys verslo objektą kuris yra ir erdvinis objektas; 2. kriterijus pagal kurį atrenkamas verslo duomenų objektas; 3. veiksmas ką su apibūdintais objektais daryti. Panagrinėkim kaip komponentas reaguos į veiklos taisyklę parengtą pagal pateiktą šabloną. „[1. Kelius] [2.kuriuose avarijų skaičius > 10] [3. nuspalvinti raudonai]" 1. ENTERPRISE DATA LOADER užkrauna visus komponentui skiriamus verslo duomenis. 1. VT ENGINE pagal šabloną atskiria kad iš verslo duomenų nagrinėsim tik tuos, kurie susiję su keliais ir sukuria filtrą pagal nurodyta VT. 3. DATA FILTER filtruoja verslo duomenis pagal nurodytą filtrą išrinkdamas tik tuos kelius, kuriuose avarijų skaičius didesnis nei 10. 4. DRAW RULES GENERATOR sugeneruoja kreipinį į MapViewer kuris sugeneruoja žemėlapį iš nurodytų kelių nuspalvindamas juos raudonai. Google pateikia lankstų, visiems interneto naudotojams prieinamą GIS duomenų (žemėlapių) naudojimo spren­dimą tačiau jis yra ribotas. Google laisvam naudojimui atiduoda ištisus terabaitus sukauptos erdvinės infor­macijos, tačiau apribojimai atsiranda, kai trečioji šalis turi pati suprogramuoti kodo dalį kuri realizuoja ką, kur ir kokioje formoje norima matyti. T.y. verslo ir erdvinių duomenų integravimas yra statiškas. 2.3.Objektinių ir reliacinių schemų integracijos modelis Šiame darbe aprašomas objektinių ir reliacinių schemų integracijos algoritmas. Pasiūlytas kanoninis duomenų modelis, kurį sudaro atributai ir apribojimai: funkcinės, jungimo/projekcijos ir poaibio priklausomybės. Aprašytos transformacijos iš reliacinių ir objektinių schemų į kanoninę schemą, algoritmas kanoninėms schemoms integruoti, kanoninės schemos transformacija į struktūrinius tipus, naudojant modifikuotą sintezės algoritmą, ir OWL. Susidomėjimas duomenų bazių schemų integracija yra didelis jau keletą dešimtmečių [3]. Centralizuotas vienos duomenų bazės projektavimas organizacijose yra sunkiai realizuojamas dėl jos sudėtingumo. Dažniausiai organiza­cijos padaliniai turi savo duomenų bazes, kurių schemos yra bendros schemos komponentai ir gali būti integruoja­mos į vieną globalią duomenų bazės schemą. Informacijos sistemos dažnai kinta, nes keičiasi vartotojų poreikiai. Dažniausiai netikslinga ir neįmanoma vietoj organizacijoje naudojamų skirtingų, netgi skirtingais duomenų modeliais pagrįstų duomenų bazių, naudoti vieną duomenų bazę, todėl šiuo atveju naudojamos federacinės duomenų bazės. Globali federacinė duomenų bazė pateikia visų duomenų bazių schemas kaip vieną bendrą schemą, nors kiekviena lokali duomenų bazė dirba autonomiškai. Sudarant federacines duomenų bazes, skiriamos penkių lygių schemos: lokaliosios schemos, komponentų sche­mos, eksporto schemos, federacinė schema, išorinė schema. Kiekvienos duomenų bazės lokalioji schema transfor­muojama iš duomenų modelio, kurį palaiko duomenų bazė, į kanoninio modelio komponentinę schemą. Komponentinėse schemose išrenkami schemų poaibiai, eksporto schemos, kurios integruojamos į federacinę schemą. Iš federacinės schemos išvedamos vartotojams pritaikytos išorinės schemos. Lokaliosios schemos dažniausiai būna reliacinės, o komponentinės remiasi kanoniniu duomenų modeliu. Kano­niniu duomenų modeliu gali būti pasirinktas tiek semantiškai skurdus, tiek turtingas duomenų modelis. Duomenų modelį sudaro struktūros, operacijos ir integralumo apribojimai [5]. Duomenų modelio galimybė atspindėti realų pasaulį susideda iš dviejų faktorių: išraiškingumo ir semantinio reliatyvumo [9]. Dažniausiai, sudarant federacines duomenų bazes, kanoniniais duomenų modeliais pasirenkami turtingi, objektinių charakteristikų turintys duomenų modeliai. Literatūroje minima, kad kanoniniu duomenų modeliu neretai pasirenkamas EER modelis, literatūroje aprašomi ir kiti kanoniniai duomenų modeliai (pavyzdžiui, skurdus bendrinis integracijos modelis [10]). Darbe siūlomas kanoninis duomenų modelis duomenų bazių schemoms integruoti ir aprašomi algoritmai reliacinėms ir objektinėms schemoms transformuoti į kanonines schemas, schemoms integruoti ir išvesti OWL struktūras. Kiekvieną schemą siūloma transformuoti į kanoninį duomenų modelį, kurį sudaro atributai ir apribojimai (apribojimais laikomos funkcinės, jungimo/projekcijos, poaibio priklausomybės). Kanoninio duomenų modelio grafinė interpretacija pavaizduota (1 pav., b). Kai kuriais atvejais funkcinės priklausomybės nevisiškai apibūdina dalykinę sritį, todėl kanoniniame modelyje naudojamos ir jungimo/projekcijos priklausomybės. Pateikiamas algoritmas kelių duomenų bazių schemoms integruoti: 1. Kiekvieną duomenų bazės schemą transformuoti į kanoninį duomenų modelį. 2. Komponentinės schemas sujungti į vieną globalią schemą, randant atributų ir apribojimų sąjungą. Jungiant komponentinės schemas į vieną, gali tekti pertvarkyti esamus apribojimus ir įvesti apribojimų tarp skirtingose schemose esančių struktūrų. 3. Įvertinti poaibio priklausomybes tarp skirtingose duomenų bazėse saugojamų egzempliorių. 4. Schemose rasti semantiškai ekvivalenčias struktūras ir išspręsti struktūrinius konfliktus. 5. Naudojant modifikuotą sintezės metodą, rasti struktūrinius tipus. Modifikuotas sintezės metodas struktūriniams tipams sudaryti įvertina ne tik funkcines, bet ir jungimo/projekcijos priklausomybes. Iš gautų struktūrinių tipų apskaičiuoti OWL struktūras ir modelį atvaizduoti OWL kalba. Transformacijų tarp ontologijų ir kitų duomenų modelių literatūroje yra siūloma, tačiau nedaug (pavyzdžiui, [12]). Reliacinėms duomenų bazėms atvaizduoti į ontologijas yra pasiūlyta kalbų [1,2,11], tačiau pasiūlyti sprendimai nėra automatizuoti. 2.4.Reliacinių ir objektinių schemų transformacijos į kanoninį modelį Funkcinių priklausomybių apskaičiavimas iš turimos reliacinės schemos nėra trivialus uždavinys. Paprasčiausias būdas - universaliąją schemą gauti išvardinant visų santykių schemų atributus, o funkcines priklausomybes išvesti tik iš rakto priklausomybių - gerai veikia tik esant paprastoms schemoms (kai dvi santykių schemas jungia tik viena išorinio rakto priklausomybė, o schemoje nėra ciklų). Neretai reliacinėse schemose dvi santykių schemos siejamos daugiau nei viena išorinio rakto priklausomybe, o universaliojoje schemoje atributai kopijuojami kiekvienai rolei, taigi atributų skaičius labai stipriai išauga. Siūlomas algoritmas reliacinei schemai transformuoti į kanoninę (jo taikymo pavyzdys pateiktas: 1. Iš kiekvienos santykio schemos atkurti rakto/unikalaus atributų rinkinio priklausomybes (santykio schema be vaidmens). Iš kiekvienos santykio schemos R = {Ą,A2,...,A„} atkurti funkcines priklausomybes X, -^ R,X2 -> R,...,Xm ->rt ,čia Xt = {Ą ,Ą ,...tĄr}, i = \,2,...,m - santykio schemos identifikatoriai. 2. Analizuojant kiekvieną santykio schemos vaidmenį, kopijuoti atributus ir funkcines priklausomybes, atkurtas iš santykio schemos be vaidmens, t.y. santykio schemos R = {AifA2,...,A„) vaidmeniui FK sukurti funkcines priklausomybes X,'-> R\X^ R',...,Xm'-> /?', čia X,'= {/1(',42',...,4 'į , i = l,2,...,m, W={Ą\A2\...,An T , struktūrinį tipą palikti, priešingu atve­ju, struktūrinį tipą pertvarkyti - pašalinti atributą 7] ir iš naujo ieškoti atributo, kurį galima būtų pašalinti. 2.5.OWL struktūrų radimas Gauti struktūriniai tipai gali būti pertvarkyti į OWL [6] duomenų modelį pagal šias taisykles: 1. Kiekvienam atributui sukuriama klasė su šiuo atributu. Struktūriniuose tipuose atributams priskiriamas tipas -atributo klasė. Nurodoma, kad atributo reikšmė yra unikali. Šis žingsnis reikalingas dėl OWL savitumo: ryšiai tarp klasių suprantami kaip funkcijos, o funkcijų apibrėžimo ir reikšmių sritimis gali būti tik klasės. 2. Kiekvienam ryšiui (struktūrinio tipo identifikatoriui) sukuriama klasė, jei jį sudaro daugiau nei vienas atributas. Klasės C, neidentifikuojanti atributų grupė, susieta poaibio priklausomybe su klase C2, keičiama vienu tos kla­sės tipo atributu, jei į ją įeina C2 identifikatorius. Taip užtikrinama, kad kiekvienoje asociacijoje tarp struktūri­nių tipų dalyvautų tik vienas atributas. 3. Įvertinant poaibio priklausomybes tarp atributų, sukuriama klasių hierarchija. Klasė C, paveldi klasę C2, jei C, identifikatorius poaibio priklausomybe susietas su C, identifikatoriumi. Įvertinant atributų poaibio priklau­somybes, C, ir C, atitinkami atributai tarpusavyje susiejami poaibio priklausomybe (rdfs:subPropertyOf) [8]. 4. Jei klasė C, paveldi C2, klasės C, ir C2 sujungiamos į vieną, jei tenkinamos dvi sąlygos: a) C, ir C2 atributų aibės sutampa (klasės išskiriamos bendrų atributų pagrindu); b) Sujungimas neduoda funkcinių priklausomybių nuostolių. Jei klasių C, ir C2 atributų aibės sutampa, o C] egzemplioriams teisinga funkcinė priklausomybė X —>Y, X c: C,, Y c C], kuri neteisinga C2 egzemp­lioriams, klasių sujungti negalima. 5. Kiekvienam „vienas-daug" ryšiui tarp klasių sukuriamas daugiareikšmis atributas klasėje, kuri ryšyje dalyvauja daug kartų. Įsimenama, kad šie atributai priklauso tam pačiam ryšiui (owl:inverseO/). 6. Jei struktūrinis tipas C sudarytas tik iš C, ir C2 tipo atributų ir identifikuojamas Šiais dviem atributais, C, ir C2 sieja ryšys „daug-daug". Sukuriami daugiareikšmiai atributai klasėse C, ir C2. Įsimenama, kad šie atributai priklauso tam pačiam ryšiui. 7. Jei klasė C nėra paveldima, ją sudaro vienintelis atributas, su klase poaibio priklausomybe susietas vienintelis klasės C" atributas ir visi klasės C egzemplioriai dalyvauja šiame ryšyje, klasė C panaikinama, o atributui, susietam poaibio priklausomybe su klase C, keičiamas tipas į panaikintos klasės atributo tipą. Taip gali būti panaikinama dalis pirmajame algoritmo etape sukurtų klasių, sudarytų iš vieno atributo. Naudojant pateiktą algoritmą, gaunama schema nėra semantiškai normalizuota. Siekiant gauti semantiškai nor­malizuotą schemą, reiktų įvertinti atributų kardinliai ūmus ir coexist priklausomybes: kiekvienai neprivalomai klasės atributų grupei, susietai coexist ryšiu, reiktų sukurti poklasį. Tačiau taip būtų gaunama labai daug klasių (praktiškai duomenų bazių schemose daug atributų yra neprivalomi) ir dalykinės srities vaizdas taptų sudėtingas. Schemoms integruoti pasiūlytas integracijos modelis, kurį naudojant galima pasiekti vienareikšmiškumą ir iš dalies automatizuotumą. Aprašyti algoritmai schemoms integruoti, dalis pasiūlytų algoritmų žingsnių gali būti vykdomi automatiškai, tačiau visiškai automatizuotas schemų integravimas yra labai sunkus. Schemoms integruoti pasiūlytas kanoninis duomenų modelis, kurį sudaro atributai ir apribojimai (funkcinės, jungimo/projekcijos, poaibio priklausomybės). Integracijos algoritmas geriausiai veikia, kai schemų egzemp­liorius sieja nesudėtingi ryšiai (poaibio priklausomybės), esant sudėtingesniems ryšiams tarp egzempliorių (iš dalies persidengiančioms egzempliorių aibėms) geriau tinka kiti integracijos modeliai (pavyzdžiui, bendrinis). Kanoniniu modeliu pasirinktas semantiškai skurdus duomenų modelis, tačiau pasiūlytos taisyklės semantiškai turtingam OWL modeliui išvesti iš kanoninio. Semantiškai skurdžias schemas yra paprasčiau integruoti, tačiau vartotojui patogiau turėti semantiškai turtingą modelį. Aprašytos transformacijos integruojamoms reliacinėms schemoms transformuoti į kanoninę schemą, kanoninei schemai pertvarkyti į struktūrinius tipus ir OWL. Reliacinio modelio atvaizdavimas į kanoninį duomenų modelį yra lengviau automatizuojamas nei objektinio. Pasiūlytas modifikuotas sintezės algoritmas duoda kokybiškesnius rezultatus nei standartinis sintezės algorit­mas, kai schemoje egzistuoja jungimo/projekcijos priklausomybės (standartinis algoritmas jungimo/projekcijos priklausomybių neįvertina). Literatūroje nėra pasiūlyta pakankamai transformavimo tarp ontologijų ir kitų duomenų modelių algoritmų. Pasiūlytas vienareikšmius rezultatus duodantis algoritmas struktūriniams tipams pertvarkyti į OWL, besire­miantis žinomomis objektinių struktūrų išvedimo iš reliacinių taisyklėmis. OWL modelis pasirinktas dėl turtin­gumo, standartiškumo, vienareikšmiškumo, jam interpretuoti sukurtos programinės įrangos gausos. Integracijos modelis gali būti išplėtotas, pasiūlant automatizuotą jungimo/projekcijos priklausomybių perskai­čiavimo algoritmą, apibendrinant vaidmenų suteikimą santykių schemoms ir klasėms bei numatant, kaip galima įvertinti sudėtingesnius nei poaibio priklausomybės ryšius tarp schemų egzempliorių. 3.Duomenų koncepcinių schemų vaizdavimas Veiklos analitikos projektuose dažnai susiduriama su brangiai kainuojančiomis agregavimo klaidomis dėl neteisin­gai suprojektuoto daugiamačio koncepcinio modelio. Šiandien verslo analizės paslaugų paklausa auga labai sparčiai, kadangi įmonių verslo sėkmė dinamiškoje rin­koje labai priklauso nuo laiku gaunamos, patikimos ir lengvai suprantamos verslo informacijos, kurią galima naudoti planuojant įmonės strategiją, sprendžiant kasdieninius uždavinius ir vertinant veiklos rezultatus. Verslo sąvoka suprantama plačiąja prasme, kadangi veiklos analizė svarbi bet kokio tipo organizacijai. Patikima informacija vadovui ar atsakingam darbuotojui turi būti pateikta tinkamu metu, tinkamu formatu ir tinkama forma - tik tuomet ši informacija suteiks organizacijai galimybę siekti aukščiausių rezultatų. Būtent šiam tikslui ir naudojami saugyklų kūrimo bei analizės įrankiai. Tačiau projektuojant duomenų saugyklas susiduriama su daugybę neaiškumų. Nėra vi­sų pripažinto ir naudojamo metodo, kuris padėtų išvengti su projektavimu susijusių klaidų. Jei projektavimo metu daromos klaidos, duomenų saugykla bus neefektyvi ir galima gauti klaidingus analizės rezultatus. Darbe analizuojama, kokie turėtų būti duomenų saugyklos projektavimo žingsniai, su kokiomis proble­momis susiduriama vaizduojant duomenų koncepcines schemas saugyklų schemomis, nagrinėjami sprendimai, kurie leistų kurti efektyvias duomenų saugyklas. Kuriant duomenų saugyklą svarbu suprasti, kokios savybės būdingos transakcijų apdorojimo OLTP (angį. Online Transactional Processing) ir veiklos analizės OLAP (angį. Online Analytical processing) sistemoms. OLAP skirta veiklos analizei, bet ne kasdieniniam transakcijų registravimui. OLAP užklausos atliekamos daug greičiau, negu reliacinėse DB. OLAP suteikia interaktyvumą ir užklausų lanks­tumą, kai bet kurią dimensiją, lygį ar narį galima peržiūrėti kaip eilutę ar stulpelį. Tačiau kad verslo intelekto (angį. Business Intelligence) sprendimai būtų efektyvūs, reikia, kad OLAP kubų duomenys būtų tvarkingi (angį. clean) ir integruoti. Šiam tikslui pasiekti reikalingos ETL (angį. Extract Transform Load) procesus palaikantys įrankiai, pvz., MS SQL Server 2005 ,Jntegration Services". Daugiamačiai duomenų modeliai atsirado vėliau, nei visiems gerai žinomas reliacinis ar koncepciniai ER, UML modeliai, vaizduojantys kasdieninių transakcijų (OLTP) duomenis. Daugiamačius duomenis galima vaizduoti ER ar UML modeliais, tačiau sukurta nemažai specifinių notacijų, kuriomis galima geriau pavaizduoti daugiamačių schemų savybes. OLAP priemonių taikymas yra paprastas ir efektyvus, jei daugiamatė schema yra taisyklinga, o tai reiškia, kad analizuojamos (faktų) lentelės duomenis galima sumuoti įvairiais pjūviais (vaizduojamais dimensijomis) ir gauti teisingus rezultatus. Šiame skyriuje nagrinėjamos galimybės padidinti duomenų analizės efektyvumą taikant daugiamačių duomenų už­klausų bei analizės kalbas MDX ir DMX. Šios kalbos yra mažai žinomos ir jų galimybės nėra pilnai išnaudojamos. Pavyzdžiui, duomenų saugyklos užklausas galima papildyti duomenų gavybos metodų funkcijomis, kurios iš karto pateikia reikiamus rezultatus. Šiame straipsnyje nagrinėjamos DMX šablonų taikymo galimybės prognozuojant trūks­tamas duomenų reikšmes. Didelė dalis įmonių kuria arba yra numatę artimiausioje ateityje kurti duomenų saugyklas ir naudoti duomenų analizės bei verslo intelekto priemones. Šioje srityje teorija yra gana jauna ir nėra daugiamačių užklausų kalbos standarto, analogiško SQL (angį. Structured Query Language). SQL kalba galima kurti daugiamačių duomenų už­klausas, tačiau pačios užklausos ir jų rašymas nėra efektyvus. Patyrę duomenų saugyklų kūrėjai naudoja daugia­mačių duomenų reiškinių MDX (angį. Multidimensional Expressions) ir duomenų gavybos išplėtimų DMX (angį. Data Mining Extensions) užklausų kalbas, kurios yra efektyvesnės daugiamačių duomenų analizei, nei SQL, ir turi plėtimo galimybes. Tačiau šios kalbos kol kas nėra pripažintos standartu ir jų potencialios galimybės nėra iki galo išnaudojamos. Šio straipsnio tikslas - parodyti vieną iš galimybių, kaip galima paspartinti duomenų analizei ir veik­los intelektui skirtų sprendimų kūrimą, pritaikant DMX šablonus. Aprašytas DMX šablonų taikymas realiai problemai spręsti. Pavyzdžiui, Lietuvos miškų informaci­nėje sistemoje faktiniai duomenys apie medžių aukštį, storį, brandumą ir tinkamumą kirtimui įvairiose vietovėse renkami tik kas penkeri metai. Kadangi medžiai auga gana tolygiai, užpildyti trūkstamas reikšmes galima panaudo­jant prognozavimo algoritmus. Šią užduoti efektyviai galima atlikti, sukuriant miškų istorinės informacijos saugyklą ir pritaikant DMX. Tipinė duomenų saugykla skiriasi nuo reliacinės duomenų bazės. Pirmiausiai, paprastos duomenų bazės skirtos tam, kad padėtų vartotojams atlikti kasdieninį darbą, o duomenų saugyklos skirtos sprendimų priėmimui. Paprastos duomenų bazės duomenis keičiasi labai greitai, o duomenų saugyklos duomenis keičiasi žymiai lėčiau: duomenis dažniausiai atnaujinami pagal tvarkaraštį (kas valandą kas savaitę, kas mėnesį), priklausomai nuo poreikio [5]. Idealiu atveju duomenų saugyklos papildymo procesas yra paprastas tam tikro laiko tarpo agreguotų duomenų įkėli­mas nekeičiant saugykloje esančių duomenų. Tam tikslui naudojama ETL (angį. Extract, Transform, Load) techno­logija, kurios esmė yra paimti duomenis iš duomenų šaltinio, transformuoti juos pagal duomenų saugyklos struktūrą ir įrašyti juos į duomenų saugyklą [1]. Duomenų šaltiniu dažniausiai būna reliacinės duomenų bazės, bet gali būti ir struktūrizuoti dokumentai. Daugiamatę duomenų saugyklą sudaro faktų lentelė ir dimensijų lentelės. Faktų lentelė yra pagrindinė duomenų saugykloje. Joje saugoma informacija apie objektus arba įvykius, kurie bus analizuojami. Dažniausiai naudojami faktai susiję su transakcijomis, momentiniais įvykiais, objekto būsena ir t.t. Dimensijų lentelės detalizuoja analizuo­jamus faktus pagal įvairius pjūvius. Išskiriami du daugiamačių saugyklų struktūros tipai: žvaigždė ir snaigė. Esminė žvaigždės schemų savybė yra dimensijų paprastumas. Tokios schemos dimensijos neturi hierarchijų. Snaigės tipo duomenų saugyklos gali būti sudėtingesnės, nes dimensijos gali turėti hierarchijas [2]. Tipinės daugiamačių saugyklų struktūros nėra normalizuotos, o tai leidžia pasiekti labai didelį duomenų išrinki­mo greitį bei labai aukštą duomenų analizės lankstumo lygį. Duomenų išrinkimui iš daugiamačių duomenų struktūrų naudojama speciali kalba MDX. Ši užklausų kalba skirta darbui su daugiamatėmis struktūromis. Nors MDX kalbos sintaksė gali pasirodyti labai panaši į SQL kalbos sintaksę, bet tarp šitų užklausų kalbų yra labai didelis skirtumas. SQL kalbą galima naudoti darbui su daugiamatėmis struktūromis, bet ji tam nėra labai tinkama, nes užklausų sudėtingumas būtų labai didelis, o duomenų išrinkimo laikas nebūtų optimalus. MDX kalba pritaikyta darbui tik su daugiamačiais duomenimis ir leidžia pasiekti labai didelį duomenų išrinkimo greitį [6]. Viena iš geriausių, populiariausių ir sparčiausiai besivystančių veiklos intelekto (angį. Business Intelligencė) sistemų yra Microsoft SQL Server Analysis Services. Egzistuoja ir daug kitų veiklos intelekto sistemų, pavyzdžiui Oracle Database for Business Intelligencė and Data Warehousing, IBM InfoSphere JVarehouse, SAS Business Intelligencė kartu su SAS Analytics. Išvardinti produktai palaiko OLAP (angį. Online Analytical Processing) ir duo­menų gavybos (angį. Data Mining) technologijas, bet jų išvystymo lygis labai skiriasi. Pavyzdžiui, kiekvienas pro­duktas turi savo duomenų gavybos algoritmus, kurių kiti produktai gali neturėti. Nėra priimtų standartų nei duomenų gavybos algoritmams, nei duomenų gavybos kalbai. Bet DMG (angį. Data Mining Group) grupė aktyviai dirba ties to ir vysto PMML (angį. Predictive Mining Model Language) kalbą, kuri XML pagalba leidžia aprašyti universalius nuo veiklos intelekto sistemos nepriklausomus duomenų gavybos šablonus. Į šią grupė įeina tokios korporacijos kaip Microsoft, IBM, Oracle, SAS ir kiti didžiausi verslo intelekto sistemų kūrėjai. Šiuo metu didžioji dalis siūlomų duomenų gavybos algoritmų yra nesuderinami su PMML klaba aprašytais šablonais, todėl šiuo metu šablono kūri­mas ir naudojimas labai priklauso nuo pasirinktos sistemos. Duomenų gavyba yra naudingų duomenų apie tam tikrą veiklą gavimo metodų aibė. Si technologija suteikia funkcijas, kurios leidžia aptikti duomenų saugykloje esančių duomenų dėsningumus, panašumus ir atlikti duomenų prognozavimą, klasifikavimą, grupavimą. Tai naudinga, nes saugomų duomenų kiekiai auga labai greitai, ir visus duomenis išnagrinėti yra labai sudėtinga, o duomenų gavybos funkcijos gali aptikti nematomas duomenų savybes, kurių analizė padės priimti teisingą veikios strategiją. Su veiklos intelekto funkcijomis galima išspręsti tokius uždavinius: investicijų grąžos analizė, pardavimų analizė ir prognozavimas, apgavysčių nustatymas, rizikos valdymas, klientų skaidymas, reklamos efektyvumo analizė. Visus spręstinus uždavinius pagal sprendimo būdą galima sugrupuoti į kelias grupes ir apibrėžti universalius sprendimo metodus: • Klasifikavimas - šiš metodas priskiria tam tikrus požymius duomenų aibėms, turinčioms tam tikins bendrus atributus. Tokius atributus dažniausiai reikia aptikti, nes jie nėra akivaizdūs. Klasifikavimas gali būti atliekamas naudojant sprendimų medžių, Naive Bayes algoritmus ir neuroninius tinklus [4], • Grupavimas {skaidymas) - šis metodas naudojamas tada, kai pagal tam tikrus atributus reikia aptikti natūralias duomenų grupes. Visi įėjimo atributai apdorojami vienodai ir tam, kad aptikti atributų bendrus požymius, reikia atlikti labai daug duomenų apdorojimo iteracijų, kurios stabdomos tada, kai stabilizuojasi grupių ribos [4], • Asociacijų paieška - šis metodas randa dažnai kartu naudojamų objektų aibes. Pavyzdžiui, prekės, kurios daž­niausiai patenka į vieną krepšelį. Dauguma algoritmų, su kuriais realizuojamas šis metodas, skenuoja duomenis kelis kartus, be to, dažniausiai dar reikia nurodyti pasikartojimo dažnio slenkstį ir bendrų objektų aibės dydį [4]. • Regresija - šis metodas yra panašus į klasifikavimą, Pagrindinis skirtumas yra tas, kad nuspėjamas atributas yra tolydus skaičius. Regresijos tipo uždaviniams spręsti dažniausiai naudojami linijinės ir loginės regresijos meto­dai, bet sprendimui taip pat galima regresijos medžius ir neuroninius tinklus [4]. • Prognozavimas - šis metodas dažniausiai naudojamas pardavimų prognozėms daryti. Įėjimas dažniausiai būna laiko dimensija. Tokių uždavinių sprendimui dažniausiai naudojamas ARIMĄ (angį. Autoregressive Integrated Moving Average) metodas [4]. • Sekų analizė - šis metodas naudojamas tada, kai reikia rasti bendras savybes diskrečių reikšmių aibėje. Tai yra pakankamai nauja uždavinių aibė, kurių sprendiniui galima pritaikyti Markovo grandinių metodą. Mokslininkai šiuo metu ieško naujų algoritmų, kurie būtų tinkami tokiems uždaviniams spręsti [4], • Nukrypimų analizė - šis metodas taikomas tada, kai reikia rasti tokius objektus, kurie labai skiriasi nuo bendros objektų aibės. Šiuo metu nėra standartinių metodų nukrypimo analizei atlikti ir šitoje srityje vykdoma daug tyrimų, bet dažniausiai naudojamos sprendimų medžių grupavimo ir neuroninių tinklų algoritmų modifikacijos [4]. Pateiksime vieną iš Data Mining prilaikymo pavyzdžių, naudojant duomenų gavybos išplėtimų kalbą DMX. Ši kalba naudojama Microsoft SQL Server Analysis Services sistemoje. Viena iŠ perspektyviausių DMX galimybių -pritaikyti šablonus, kurie leidžia tipizuoti veiklos analizės sprendimus. Duomenų gavybos šabloną galima įsivaiz­duoti kaip lentelę į kurią įrašius duomenų porciją galima gauti apdorotų duomenų porciją. Duomenų gavybos šablo­nas įvade aprašytai miškų informacijos sistemos duomenų prognozavimo problemai spręsti. Tai yra prognozavimo šablono modelis, kuris turėtų prognozuoti medžių augimą laikui bėgant. Šablonas turi įėjimus ir išėjimus, kuriems suteikiami tam tikri požymiai. Pavyzdžiui, laikas yra atratninis laukas, pagal kuri vyk­doma analizė, o tūris ir aukštis yra analizuojami ir prognozuojami laukai. Duomenis į šabloną gali būti perduodami su MDX užklausų pagalba, kurios grąžinamų duomenų formatas turi būti suderinamas su šablono įėjimais [3]. DMX kalba leidžia sukurti šablonus, kurie duomenų analizei naudoja tokius algoritmus: sprendimo medžių algo­ritmus; grupavimo algoritmus; Naive Bayes algoritmus; asociacijų paieškos algoritmus; sekų grupavimo algoritmus; laiko eilučių prognozavimo algoritmus; neuroninių tinklų algoritmus; strateginės regresijos algoritmus; tiesinės re­gresijos algoritmus. Dažniausiai, vieno tipo šabloną galima pritaikyti panašiems uždaviniam spręsti [7]. Kaip pavyzdį paimsime žmo­nių analizės sistemą, kurioje saugomi skirtingų pasaulio regiono žmonių fizinių parametrų duomenys (ūgis, kūno sudėjimas, amžius). Tokia sistema leistų analizuoti žmonių fizinius parametrus pagal regionus ir kaip tie parametrai keičiasi laikui bėgant. Šablonams, kurie naudoja kitus algoritmus, galioja ta pati taisyklė - vieną šabloną galima taikyti keliems uždaviniams. Pavyzdžiui, šabloną, naudojantį sprendimo medžių algoritmą galima pritaikyti užduočiai, kai reikia priimti sprendimą į kurį produktą geriausiai investuoti pinigus. Toks uždavinys gali pasitaikyti daugelyje gamybos sričių, o uždavinio sprendimo įėjimai ir išėjimai bus vienodi. Prieš pradedant kurti, duomenų gavybos šabloną, reikia gerai ištirti uždavinį, ir suprasti jo tikslus. Tai padės pasirinkti uždavinio sprendimui tinkamą algoritmą. Gali atsitikti taip, kad uždavinio sprendimui tinka keli algorit­mai. Tada galima sukurti kelis šablonus ir šablono derinimo eigoje išsirinkti geriausius rezultatus parodantį šabloną. Šablono derinimas atliekamas paduodant jam daugiamačių duomenų pjūvius ir nagrinėjant gautus rezultatus. Tokias operacijas reikia atlikti kelis kartus, kiekvieną katrą paduodant skirtingus duomenų pjūvius. Derinimo metu šablonas įsimena analizuojamų duomenų savybes, kurias vėliau galės taikyti analizuojant realius duomenis. Kadangi duomenis pastoviai keičiasi, tai šablono derinimą reikia daryti reguliariai. Kartais naudinga išvalyti visas šablono atmintyje saugomas duomenų savybes ir iš naujo suderinti jau tuščią šabloną. Derinimo rezultatus kartais gali būti labai sudėtinga suprasti. Taip gali atsitikti dėl kelių priežasčių. Kartais duomenys gali turėti labai aukštą atsitikti­numo lygį ir neturėti jokių dėsningumų, nors realūs duomenis dažniausiai juos turi. Kitas atvejis gali būti toks, kad šablonui paduodami netinkamo formato duomenis. Tada tikslinga būtų peržiūrėti duomenų transformavimo ir išgryninimo procedūras ir pagerinti parametrų kokybę [3]. Aprašyto šablono testavimo rezultatai pateikiami 3 paveiksle. Diagrama parodo medžių augimą procentais, pri­klausomai nuo amžiaus. Dešinėje grafiko pusėje, punktyrine linija pavaizduota medžio augimo prognozė dešimčiai metų į priekį. Šablono algoritmas akivaizdžiai atrado medžių auginio koeficientus ir suprognozavo, kad medžių augimas išliks tolygus. Grįžkime prie Lietuvos mišką informacinės sistemos. Faktiniai duomenys apie medžių augimą įvairiose vieto­vėse renkami kas penkeri metai, o kirtimai gali būti vykdomi kiekvienais metais, reiškia duomenų saugykloje atsi­randa duomenų trūkumas. DMX šabloną galima integruoti į ETL procesą ir saugyklą pildyti duomenimis iš tos pačios saugyklos pritaikius duomenų prognozavimo šabloną. Tai gali išspręsti duomenų trūkumo problemą ir leis naudoti nuspėjamus duomenis medžių kirtimo veikloje. Faktinė informacija, kuri surinkinėjama kas penkeri metai sumažina bendros informacijos paklaidas ir yra pagrindinė informacija, pagal kurią galima daryti augimo prognozes Užklausų kalba MDX skirta darbui su daugiamačiais duomenimis, todėl ji pralenkia SQL užklausų kalbą šitoje srityje. Taip pat egzistuoja DMX kalba, skirta duomenų gavybai, kuri gali būti naudojama tiek su reliaciniais, tiek su daugiamačiais duomenimis. Remiantis tokiais faktais galima teigti, jog daugiamačių duomenų analizei geriausiai naudoti MDX ir DMX kalbų derinį. MDX ir DMX kalbų taikymas gali padidinti veiklos analizės efektyvumą. Tai rodo duomenų prognozavimui su­darytas DMX šablonas, kuris išbandytas su pavyzdiniais duomenimis miškų informacijos prognozavimui. Naudojant vien tik SQL, prognozavimui realizuoti reikėtų kurti sudėtingus algoritmus. Sprendžiant duomenų trūkumo problema, MDX šabloną galima integruoti į ETL procesą, kas leidžia papildyti duomenų saugyklą pagal turimus duomenis prognozuojamais duomenimis. Objektinio programavimo mokymas. Objekti­nio programavimo svarba informatikos mokymo pro­gramose auga visų pirma dėl poreikio mokėti kurti šiuo­laikines sudėtingos struktūros taikomąsias programas, sprendžiančias įvairiausių sričių uždavinius. Pedago­ginio universiteto studentai tradiciškai pirmiausiai mo­komi Turbo Paskalio, nes Ši programavimo kalba ilgą laiką vyravo mokyklinės informatikos mokymo pro­gramose. Nors dabartinėje informatikos programoje Lietuvos mokykloms bendrajame informacinių tech­nologijų kurse programavimo nėra, jis šioje progra­moje yra viena iš išplėstinio kurso krypčių [71. Pabrė­žiama, kad Šis kursas svarbus tiems mokiniams, kurie rinksis informatiko profesiją. Taigi pedagoginio uni­versiteto studentams taip pat reikalingas šiuolaikinis programavimo mokymas. Perėjimas nuo struktūrinio prie objektinio programavimo jiems nėra elementa­rus. Objektinio programavimo mokymo problemos dažnai svarstomos mokslinėje literatūroje [8; 11], Ne­įmanoma per paskaitą rodyti ilgų programų tekstų, programos veikimo rezultatų, tuo labiau per trumpą pratybų laiką sukurti programų, akivaizdžiai rodančių objektinio programavimo pranašumas. Tikėdamiesi mokymo supaprastinimo virtualių mokomųjų aplinkų kūrimo įrankiuWeb CT mes pa­rengėme Programavimo C++ kalba virtualią aplinką internete [9; 10]. Jau treji metai kaip VPU magistro studijų studentai mokosi C++ kalbos, kartu su paskai­tomis ir laboratoriniais darbais naudodami įvairias ap­linkos teikiamas galimybes: elektroninę kurso medžiagą su betarpiškai paleidžiamais vykdyti programų pavyz­džiais, žinyną, paiešką, testus savikontrolei ir bendra­vimo galimybes aplinkos viduje. Mokslo metų pabai­goje apklausdami studentus išsiaiškiname jų nuomo­nę apie Šią mokomąją aplinką. Visų trijų metų patirtis labai panaši: naudodami mokomąją aplinką kaip pa­pildomą priemonę, studentai teikia pirmenybę kurso medžiagai ir testams. Visi pripažįsta, kad tokia moky­mo aplinka naudinga, bet kai kurias galimybes nau­doja mažai studentų, tą rodo 4 pav. Šiame paveikslė­lyje pateikti trijų metų rezultatų vidurkiai. Web CT teikia daug papildomų galimybių dėsty­tojui, stebinčiam mokymo procesą aplinkoje. Vyksta automatinis studentų darbo stebėjimas ir statistinių re­zultatų apibendrinimas. Vaizdinio programavimo mokymas. Vaizdinio programavimo technologijos yra greito taikomųjų pro­gramų kūrimo įrankis, naudojantis vaizdinių paruoš­tų komponentų rinkinius. Studentai su dideliu entu­ziazmu mokosi kurti programas C++ Builder aplinko­je. Tai akivaizdus įrodymas, kad juos domina Šiuolai­kinės sąsajos projektavimas. Netgi tie studentai, ku­riems sunkiai sekėsi C++ kalbos sintaksė, labai stengė­si gavę šiuolaikinį įrankį C++ Builder. Išvados 1. Objektinio projektavimo metu gali būti taikomi įvairūs modeliai. Jie būna statiniai ir dinaminiai. Objektų sąsajos turėtų būti apibrėžiamos tiksliai naudojant pavyzdžiui Java programavimo kalbą. Objektinis projektavimas supaprastina sistemos vystymą. 2. Objektinis projektavimas yra projektavimo metodas kai projektavimo komponentai turi privačias būsenas ir operacijas. Objektai turi turėti konstruktorius bei stebėjimo operacijas. Jos teikia servisus kitiems objektams. Objektai turi būti realizuojami nuosekliai arba lygiagrečiai. UML pateikia skirtingas notacijas apibrėžiant skirtingus objektų modelius. 3. Norint operuoti erdviniais duomenimis, reikia įsidiegti visą eilę brangios programinės įrangos. Tai yra nepriim­tina mažoms ir vidutinėms verslo įmonėms. Yra tikslinga šią programinę įrangą įdiegti serverio dalyje, tokiu būdu įmonės išlaisvinamos nuo papildomų investicijų. Egzistuojantys žemėlapių generavimo komponentai yra efektyvūs, tačiau pertekliniai ir per brangūs siekiant optimalaus sprendimo verslui. Žemėlapio įkėlimui į internetinį puslapį reikia naudoti kiek įmanoma paprastesnį komponentą. 4. Maksimalų panaudojimo efektyvumą atitiktų toks komponentas, kurio konfigūravimui siekiant gauti norimus rezultatus reikėtų kiek galima mažiau pastangų. Toliau numatoma kurti ir realizuoti verslo ir erdvinių duomenų integravimo pagal veiklos taisykles algoritmą. Literatūra 1. D. Andes. What is GIS? Informational site on GIS, 2007. 2. A. lonita, M. Foca, M.l. Popovici. GIS in Business Processes, 2006. 3. Inlernetinė nuoroda. http://www.hitachisoft-gi5.com/content-en/GWSENProd_Any_Arch.htm 4.2006 m. balandžio 4 d. "VERSLO ŽINIŲ" PASKUTINIS PUSLAPIS: Planuodami verslą kauniečiai gali pasitelkti ir geografinę informacinę sistemą. http://www.affecto.lt/itweh/affecto.nsf/Akt4/ E4IEI4D6F409FECBC225714600287AEA 5. J.Farley. Oracle lOg. A Locatiott-enabled Platform for Enterprise GIS and Core Business Applications. Earth observalion magazine, 2004. 6. Oracle. Oracle® Application Server. MapViewer User's Guide. Release 10.1.3.1. B14036-03, 2005. 7.Kapočius, R. Butleris. Repository for Business Rules Basecl IS reųuirements. Informalica, VolM, No A, 2006, 503- 518. 8.Horstmann, Cay S., Cornell, G. (2003). Core Java2 Volume I Fundamentais. Sun Microsystem Press. 9.Eckel, B. (2003). Thinking in JAVA. 3rd Editon. President, MindVievv Inc. 10.Riškus, A. (2002). Programavimas JAVA. Kaunas: Technologija. 11.Holder W. (1998). Java Game Programming For Dummies.' 12. Barrasa, O. Corcho, A. Gomez-Perez. R20, an Extensible and Semantically Based Database-lo-ontology Mapping Language. Toronto, Canada, 2004. Prieiga per internetu:

Daugiau informacijos...

★ Klientai rekomenduoja

Šį rašto darbą rekomenduoja mūsų klientai. Ką tai reiškia?

Mūsų svetainėje pateikiama dešimtys tūkstančių skirtingų rašto darbų, kuriuos įkėlė daugybė moksleivių ir studentų su skirtingais gabumais. Būtent šis rašto darbas yra patikrintas specialistų ir rekomenduojamas kitų klientų, kurie po atsisiuntimo įvertino šį mokslo darbą teigiamai. Todėl galite būti tikri, kad šis pasirinkimas geriausias!