XI SEKCIJA - elibrary.lt

XI SEKCIJA

Duomenų bazės ir modeliai

DUOMENŲ INTEGRAVIMAS

Dainius Jurčikonis, Aurimas Paršonis, Egidijus Kazanavičius Kauno Technologijos Universitetas, Kompiuterių katedra

Studentų g. 50-213, LT-3031 Kaunas

Straipsnyje nagrinėjama tam tikri standartai ir technologijos, kuriais remiantis vyksta duomenų perdavimas tarp skirtingų

duomenų šaltinių. Apžvelgiama esama situacija duomenų integracijos srityje, siūlomi sprendimai, esamos technologijos. Taip pat bus palyginamos tarpininkavimo programos ir jų tipai.

1. Įvadas

Dauguma kuriamų sistemų, kurios operuoja dideliais duomenų kiekiais, naudoja reliacines duomenų bazes. Jos gali veikti skirtingose operacinėse sistemose, naudoti skirtingą programinę įrangą. Taip pat naudojamos skirtingos duomenų bazės (MySQL, Oracle, MS SQL ir kt.), kurių duomenų struktūra skiriasi viena nuo kitos. Atsiranda poreikis plėtojimuisi ir iškyla būtinybė keistis duomenimis. Dėl saugomų duomenų struktūrų nesuderinamumo susiformuoja informacijos apsikeitimo problema, apsikeitimas informacija tampa sudėtingas uždavinys.

Heterogeninėse duomenų bazėse duomenų integracija įmanoma tik naudojant bendrą integruojamų duomenų bazių struktūras apjungiantį standartą. Standartas turi būti pritaikomas skirtingoms duomenų bazėms neatsižvelgiant į jų struktūros specifiką ir pasižymėti universalumu.

2. Duomenų perdavimo standartai

Norint keistis duomenimis tarp heterogeninių duomenų bazių reikia sukurti apibendrintą struktūrą, kuri apimtų visų sistemų duomenis, kurie gali būti tarpusavyje visiškai nesuderinami. Tokiu atveju kiekvienai sistemai reiktų kurti programinius įrankius arba paketus, kurie palaikytų prisijungimą prie kitų sistemos duomenų bazių. Tai yra tikrai nepatogu ir sudėtinga. Dėl to duomenų tarp nehomogeninių duomenų bazių perdavimui patogiausia būtų naudoti tokį duomenų tipą, kuris labiausiai atitiktų sistemos duomenų bazių duomenis ir tiesiogiai nepriklausytų nuo atitinkamos sistemos ar duomenų bazės. Šiuo atveju patogiausia naudoti XML (EXtensible Markup Language) [7].

3. XML technologija

• XML skirta keitimuisi duomenimis; • XML skirta keistis informacija; • XML gali būti naudojama duomenų paskirstymui; • XML gali būti skirta duomenų saugojimui; • XML gali padaryti duomenis labiau prieinamus.

Remiantis aukščiau išvardintais XML požymiais galima daryti išvadą, jog XML kalba tinka duomenų keitimuisi tarp heterogeninių duomenų bazių. Tačiau šis procesas nėra toks paprastas, nes reikia atsižvelgti į įvairių sistemų funkcinius reikalavimus. Sukūrus bendrą šabloną, būtų įmanoma atlikti keitimąsi duomenimis tarp įvairių sistemų. Naudojant XML šabloną duomenų keitimui patogu naudoti XML schemas.

4. XML schemų paskirtis

XML schema nusako XML dokumento struktūrą. XML schemos skirtos apibrėžti [8]:

• dokumente naudojamus elementus • dokumente naudojamus atributus • kurie elementai yra elementai – vaikai • elementų – vaikų tvarką • elementų – vaikų kiekį

– 497 –

A. Paršonis, D. Jurčikonis, E. Kazanavičius

• ar elementas yra tuščias ar gali saugoti tekstinę informaciją • elementų duomenų tipus ir atributus • standartines ir fiksuotas elementų ir atributų reikšmes • ryšius tarp elementų XML schemos paskirties aprašymo struktūra ir sandara yra artima reliacinių duomenų bazių struktūrai. Todėl

norint keistis duomenimis reikia sukurti XML schemą, kuri leistų perduoti duomenis į bet kurią sistemą. Tačiau dėl XML schemų ir reliacinių bazių struktūros neatitikimo iškyla konvertavimo problemos.

Pagal taisykles suformuotas XML dokumentas tai – dokumentas, atitinkantis XML sintaksę ir dokumento tipo aprašymą DTD (Document Type Definition). XML dokumento struktūra yra aprašoma DTD arba XML schema. DTD - tai rinkinys taisyklių, kurios apibrėžia leidžiamą dokumento klasių struktūrą [1].

XML dokumentas yra lengvai pernešamas tarp sistemų ir platformų, nes jo turinys yra paprastas tekstas (plain text).

W3C pasiūlytas standartas yra XSL (eXtensible Stylesheet Language), apibrėžiantis, kaip XML dokumentas bus vaizduojamas naršyklėje [4, 5]. XSL susideda iš trijų dalių: XSLT, XPath ir XSL Formatting Objects. XSLT (eXtensible Stylesheet Language Tranformations) tai – kalba, skirta transformuoti XML dokumentą į kitokio formato dokumentą. XSLT gali būti naudojama XML dokumentą transformuoti į kitą XML dokumentą. XPath tai – kalba skirta identifikuoti XML dokumento dalis. XSL Formatting Objects tai – kalba, kuri formuoja XML dokumento vaizdą po XSLT transformacijos. XSLT gali transformuoti XML dokumentą į dokumentą, kuris gali būti atvaizduotas naršyklėje. XSLT taip pat gali koreguoti informaciją transformuotame dokumente. XSLT elementų, atitinkančių tam tikras sąlygas ir po to atliekančių elementų transformaciją, suradimui XML pradiniame dokumente naudoja XPath.

XSL naudoja vieną ar kelis šablonus, kurie apibrėžia, kaip atvaizduoti XML elementus. Standartas leidžia naudoti sąlygos ir pasirinkimo operacijas, taip pat gali perrūšiuoti pradinį XML dokumentą. Panaudojus XSL, galima pakeisti XML dokumento struktūrizacijos lygmenį, įtraukiant, ištrinant, pergrupuojant elementus. XSL privalumas yra tai, kad galima surasti konkretų elementą, pasinaudojus šablonais, kurie tikrina elementų turinį, ir po to su juo atlikti norimus veiksmus.

5. Duomenų perdavimo technologijos

Tarpininkavimo programos (TP) – tai programinė įranga, tarpininkaujanti tarp skirtingų sistemų [6]. TP sukurta perdavimo sistemoms, komunikacijai ir duomenų sandėliui. Svarbiausia TP funkcija duomenų sandėliavime - sukurti pastovų kelią, pasiekiant duomenų bazę.

Tarpininkavimo programos - bet kokio tipo programinė įranga, kuri palengvina komunikaciją tarp dviejų ar daugiau programų sistemų. TP turi mechanizmą, kuris vienai esybei (taikomajai programai ar duomenų bazei) leidžia komunikuoti su kita esybę ar esybėmis, leidžia paslėpti pirminio šaltinio ir adresato sistemų sudėtingumus.

Taikomųjų programų tipai: • Nutolusių procedūrų iškvietimas (RPC - Remote Procedure Calls); • Į pranešimus orientuotos TP (MOM - Message Oriented MW); • Paskirstytų objektų (Distributed Objects); • Į DB orientuotos TP (DB oriented MW); • Transakcinės TP įtraukiant transakcijų apdorojimo monitorius ir taikomųjų programų darbo stotis

(Transactional MW); • Pranešimų brokeriai (Message brokers).

Į DB orientuotos taikomosios programos

Šio tipo programos supaprastina komunikaciją su duomenų baze. Projektuotojai naudoja į duomenų bazes orientuotas taikomąsias programas, kaip mechanizmą informacijos išgavimui iš lokalinės ar nutolusios duomenų bazės.

Klientas Duomenys

SQL užklausa

Atsakymas 1 pav. Į DB orientuota taikomoji programa

– 498 –

Duomenų integravimas

6. XML produktai ir jų kategorijos

XML dokumentai skirstomi i dvi kategorijas: orientuoti į duomenis, bei orientuoti į dokumentus [5]. • Tarpininkavimo programos (Middleware): programinė įranga, skirta duomenų perdavimui tarp XML

dokumentų bei duomenų bazės. • Duomenų bazės įgalinančios XML (XML-Enabled Databases): duomenų bazės skirtos duomenų

perdavimui tarp XML failų. • XML duomenų bazės (Native XML Databases): XML duomenų bazės. • XML serveriai (XML Servers): WEB serveriai, integravimo varikliai bei specifiniai serveriai palaikantys

XML publikavimą, generavimą ir t.t. • Aplankalai (Wrappers): programinė įranga, traktuojanti XML dokumentus kaip reliacinių duomenų šaltinį.

Dažniausiai šie produktai generuoja XML dokumentus SQL sintaksės pagalba. • Turinio valdymo sistemos (Content Management Systems): programinė įranga, skirta turinio valdymui

(tikrinimas, verifikavimas, redagavimas, versijų kontrolė ir pan.). • XML užklausų varikliai (XML Query Engines): specifinė programinė įranga XML duomenų užklausų

vykdymui. • XML duomenų įrišimas (XML Data Binding): įranga, susiejanti XML dokumentus su objektais. • Nutraukti produktai (Discontinued products): produktai, kurių vystymas ir tolimesnis palaikymas jau

nutraukti. Išskyrus turinio valdymo sistemas, visais kitais atvejais, reikia patiems parašyti atitinkamą kodą, norint

integruoti produktą į savo sistemą. Dažniausiai naudojamos reliacinės DBVS naudojančios ODBC, JDBC arba OLE DB. Tačiau yra ir kitokių

produktų, skirtų duomenų mainams tarp kitokio tipo DB. Žemiau pateikta produktų palyginimo lentelė. Connect for SQL/XML

Connect for SQL/XML yra JDBC tvarkyklė, kuri realizuoja SQL/XML specifikaciją lygiai taip pat kaip JDBC. Užklausų rezultatai gražinami JDBS „ResultSet” pavidalu. XML reikšmės yra gražinamos XML tipo stulpeliuose. Programa pasiima tas reikšmes getObject metodo pagalba.

Connect XML-2-DB

Connect XML-2-DBL yra JAVA programinė įranga skirta perduoti duomenis tarp XML dokumentų bei SQL serverio arba Oracle. Naudoja objektinį-reliacinį duomenų paėmimo būdą.

Connect XML-2-DB gali būti paleista tiek iš kitos JAVA aplikacijos, tiek ir iš komandinės eilutės.

ASP2XML

COM objektas XML dokumentų perdavimui ODBC arba OLE DB duomenų šaltiniams ir atvirkščiai. Produktas supranta XML dokumentą kaip vientisą lentelę. Panaudojus SELECT sakinį, grąžinamas dokumentas su specifiniais elementais bei reikiama informacija. Norint atgalinio ryšio, būtina, kad XML failas turėtų specifinius ASP2XML programos elementus (tags). Šis objektas gali veikti MS ASP puslapiuose, o taip pat kaip atskira aplikacija.

Mysql, mysqldump

„Mysql“ yra komandinėje eilutėje valdomas įrankis, kurio pagalba vykdomos MySQL DBVS užklausos duomenų užkrovimui. „Mysqldump“ – atitinkama aplikacija, tačiau naudojama ne su MySQL, bet su MS SQL serveriu.

– 499 –

A. Paršonis, D. Jurčikonis, E. Kazanavičius

2 lentelė. TP produktų palyginimas

Produktas Gamintojas Licenzija DB tipas DB >XML

XML >DB

eTools XML GA eXpress Komercinis Daugiareikšmis (MultiValue)

x x

Extreme Translator Etasoft Komercinis Reliacinis x x ADO Microsoft Komercinis Reliacinis x x e.Report Actuate Komercinis Reliacinis x -- Easysoft XML-ODBC Server

Easysoft Komercinis Reliacinis x --

DBIx::XMLServer Martin Bright Atviro kodo Reliacinis x -- DBIx::XML_RDB Matt Sergeant Atviro kodo Reliacinis x x DbToXml SoftRUs Komercinis Reliacinis x x DB2XML Volker Turau Atviro kodo Reliacinis x -- Connect XML-2-DB Skyhawk

Systems Komercinis Reliacinis -- x

Connect for SQL/XML DataDirect Technologies

Komercinis Reliacinis x x

Charteris Integration Toolkit

Charteris Komercinis Reliacinis x x

Castor exolab.org Atviro kodo Reliacinis x x XML Lightweight Extractor (XLE)

IBM Analizei Reliacinis x --

XML Spy Altova Komercinis Reliacinis x x XML Junction Data Junction,

Inc. Komercinis Reliacinis,

ISAM ir kt. x x

XML::Generator::DBI Matt Sergeant Atviro kodo Reliacinis x -- XML Gateway SPI Ltd. Komercinis Reliacinis, Word,

teksto failai x x

XML for Tables IBM Tik analizei (Evaluation only)

Reliacinis (DB2) x --

XML-DBMS Ronald Bourret, et al

Atviro kodo Reliacinis x x

XML DataDesk NetBryx Technologies

Komercinis Reliacinis x --

xlinkit xlinkit.com Nemokamas/ Komercinis

Reliacinis x --

X:Forge Bibop Research International

Atviro kodo Reliacinis, XML (Native XML)

x --

SXQL Goetz Hatop Viešoji programa (Shareware)

Reliacinis x x

ASP2XML Stonebroom Komercinis Reliacinis x x mysql, mysqldump MySQL Atviro kodo Reliacinis x --

7. Išvados

Duomenų integracijai dažniausiai naudojamas XML standartas. Jis naudojamas kuriant struktūrinius dokumentus arba aprašant duomenis. Dokumento struktūrai apibrėžti naudojama DTD arba XML schema. XML gali būti transformuotas į kitus formatus naudojant XSL standartą. Tam, kad perduoti duomenis tarp skirtingų tipų duomenų bazių bei XML dokumentų, naudojamos tarpininkavimo programos. Duomenų integracija - ilgas ir didelių darbo bei finansinių resursų reikalaujantis procesas.

– 500 –

Duomenų integravimas

Literatūros sąrašas [1] W3C XML working group, “Extensible Markup Language (XML) 1.0 (Second Edition)”, [žiūrėta 2004-01-03]. Prieiga per

internetą: http://www.w3.org/TR/2000/REC-xml-20001006; [2] David C. Fallside (W3C),“XML Schema Part 0: Prime”, [žiūrėta 2004-01-03]. Prieiga per internetą::

http://www.w3.org/TR/xmlschema-0/; [3] Sharon Adler, Anders Berglund, Jeff Caruso, Stephen Deach, Paul Grosso, Eduardo Gutentag, Alex Milowski, Scott

Parnell, Jeremy Richman, Steve Zilles, “Extensible Stylesheet Language (XSL) Version 1.0”,[žiūrėta 2004-01-03]. Prieiga per internetą: http://www.w3.org/TR/xsl/;

[4] James Clark, “XSL Transformations (XSLT) Version 1.0”, [žiūrėta 2004-01-03]. Prieiga per internetą: http://www.w3.org/TR/xslt.html;

[5] Ronald Bourret, XML Database Products [žiūrėta 2004-01-03]. Prieiga per internetą: http://www.rpbourret.com/xml/XMLDatabaseProds.htm

[6] David S. Linthicum, Application Integration Exposed [žiūrėta 2005-01-03]. Prieiga per internetą : http://www.softwaremag.com/L.cfm?Doc=archive/2000feb/EAI.html

[7] T. Konovalovas, B. Paradauskas. Nehomogeninių duomenų bazių integracija naudojant XML formatus // Informacinės technologijos ir mokslų integracija – 2003 : aštuntoji magistrantų ir doktorantų konferencija : konferencijos pranešimų medžiaga. Kaunas : Technologija, 2003, p. 45 – 48.

[8] „Introduction to XML Schema“, interneto prieiga: http://www.w3schools.com/schema/schema_intro.asp

Data Integration

In this article analyzed some standards and technologies according to data transfer processes between different data sources. Existing situation is reviewed in the data integration sphere, market offers, existing technologies. There will be compared middleware ant their types.

http://www.w3.org/TR/xslt.html

http://www.rpbourret.com/xml/XMLDatabaseProds.htm

http://www.softwaremag.com/L.cfm?Doc=archive/2000feb/EAI.html

http://www.w3schools.com/schema/schema_intro.asp

DUOMENŲ MODELIO SUDARYMAS, INTEGRUOJANT ER SCHEMAS

Aistė Aleksandravičienė, Rimantas Butleris Kauno technologijos universitetas, Informacijos sistemų katedra

Studentų g. 50-308, LT-51368, Kaunas

Straipsnyje parodoma duomenų modelio kokybės svarba ir jo vieta sistemos kūrimo eigoje. Supažindinama su duomenų modeliavimo procesu, kurio pagrindas – informacijos srautų specifikacija; pateikiamas ER schemų integravimo duomenų modelio sudarymo etape apibrėžimas. Pagrindžiama, kodėl projektuotojui reikalingas automatizuotas duomenų modelio sudarymo įrankis. Pabrėžiama, jog kuriamas metodas iš esmės skiriasi nuo jau žinomų integravimo metodų tuo, kad jis skirtas ne diegimo ar palaikymo, o projektavimo etapui. Pateikiami žinomi schemų lygio konfliktų, kuriuos reikia išspręsti integravimo proceso metu, tipai.

Reikšminiai žodžiai: informacijos sistema, ER modelis, funkcinių reikalavimų specifikavimo metodas, informacijos srautų specifikacija, duomenų šaltinis, duomenų srautas, schemų konfliktai, schemų integravimas, schemų konceptai, duomenų bazė.

1. Įvadas

Įrodyta, kad sukurtos ir jau eksploatuojamos sistemos kokybei ir kainai duomenų modeliavimo procesas turi daugiau įtakos negu bet kuris kitas sistemos kūrimo etapas. Siekiant išvengti klaidų, kurios dažniausiai aptinkamos vėlyvuosiuose sistemos kūrimo etapuose, duomenų modeliavimo procesą būtina automatizuoti.

Straipsnyje pristatoma duomenų modeliavimo informacijos srautų specifikacijos pagrindu koncepcija. Analizuojamą duomenų modeliavimo procesą sudaro 3 pagrindiniai etapai: 1) dokumentų formų pavyzdžių atrinkimas ir analizė; 2) atrinktų duomenų šaltinių struktūrą atitinkančių ER schemų sudarymas; 3) ER schemų integravimas. Vienas svarbiausių šio darbo tikslų yra formalizuoti ir automatizuoti trečiąjį etapą, pasinaudojant informacijos srautų specifikacijos meta duomenų baze, kuri aprašo reliacinio duomenų modelio sudarymo taisykles ir apribojimus.

Trijuose pirmuosiuose straipsnio skyriuose aprašoma tyrimų sritis ir tikslai, supažindinama su svarbiausiomis sąvokomis – pateikiamas ER schemų integravimo IS projektavimo kontekste apibrėžimas, paaiškinamos duomenų šaltinio ir duomenų srautų sąvokos, apibrėžiama, kas yra schemų konfliktas. Pateikiamas trumpas ER schemų integravimo proceso aprašymas ir jo iliustracija.

4 skyriuje supažindinama su integravimo metodais. Pateikiama fizinių duomenų bazių žinomų integravimo metodų klasifikacija bei komentuojamos šių metodų charakteringos savybės. 5 skyriuje detaliai aptariami tipiniai schemų lygio konfliktai, o 6 skyriuje pateikiamos darbo išvados.

2. Duomenų modelio kokybės svarba

Nors duomenų modeliavimo procesas, palyginus su kitais sistemos kūrimo etapais, tradiciškai trumpesnis už programinę realizaciją, tačiau įrodyta, kad eksploatuojamos sistemos kokybei jis turi daugiau įtakos negu bet kuris kitas etapas. Duomenų modelis yra vienas iš svarbiausių faktorių, nulemiančių sukurtos sistemos lankstumą bei galimybę integruoti ją į kitas sistemas. Jis taip pat nulemia sistemos kūrimo ir palaikymo kaštus. Apskaičiuota, jog klaidų taisymo kaštai kiekviename sistemos kūrimo etape, pradedant analize ir baigiant palaikymu, didėja eksponentiškai (1 pav.). Klaidos, ištaisytos projektavimo etape, kaštai yra vidutiniškai 3,5 karto didesni už analizės etape pašalintos tos pačios klaidos kaštus. Šią klaidą aptikus sistemos diegimo etape, jos taisymo kaštai išaugtų vidutiniškai iki 50 kartų, o palaikymo etape – iki 170 kartų [6].

Papildomos sąnaudos, susidariusios šalinant klaidas, ženkliai sumažina eksploatuojamos sistemos naudą, todėl vienas iš pagrindinių kokybiškos sistemos kūrimo faktorių yra klaidų prevencija, taikoma pradedant ankstyvaisiais sistemos kūrimo etapais.

Duomenų modelio kokybė labiausiai priklauso nuo projektuotojo kompetencijos, ypač jei darbas atliekamas rankiniu būdu, nenaudojant CASE (Compute Aided Software Engineering) priemonės.

– 502 –

Duomenų modelio sudarymas, integruojant ER

Etapas

$200

Kla

idų

kain

a $150

$100

$50

$0

AnalizėProjekta-

vimasDiegi-mas

Palaiky-mas

1 3,5

50

170

1 pav. Klaidų kaštų augimas, kuriant sistemą

3. Duomenų modelio sudarymas informacijos srautų specifikacijos pagrindu

Siekiant palengvinti projektuotojo darbą ir užtikrinti projektavimo etapo produktų kokybę, sukurta nemaža įvairių CASE priemonių. Iš skirtingoms metodologijoms ir tradicijoms atstovaujančių projektavimo metodų galima išskirti Oracle CASE, Rational Unified Process, F3 [3].

Kauno technologijos universiteto Informacijos sistemų katedroje jau apie 10 metų vystomas funkcinių reikalavimų specifikavimo metodas. Šiuo metu didelis dėmesys yra skiriamas informacinės sistemos (IS) duomenų modelio sudarymui informacijos srautų specifikacijos pagrindu, siekiant šį procesą formalizuoti ir automatizuoti. Informacijos srautų specifikacija yra funkcinių reikalavimų specifikacijos segmentas, charakterizuojantis kompiuterizuojamos organizacijos informacinių srautų objektus, kuriuos galima panaudoti reliaciniam duomenų modeliui sudaryti. Minėtais objektais gali būti įvairios dokumentų formos, žodiniai pranešimai, egzistuojančių kompiuterizuotų sistemų ekraninės formos, elektroniniu būdu perduodami duomenų paketai ir pan. Visiems išvardintiems organizacijos objektams apibrėžti naudojamas vieningas terminas – duomenų šaltinis (DŠ) [1]. Daugiametė patirtis reikalavimų išgavimo analizės srityje parodė, kad iš dalies struktūrizuotos informacijos (pvz., dokumentų formų pavyzdžių pavidalu) panaudojimas kuriamos sistemos statikai nustatyti yra daug patikimesnis būdas už natūralia kalba užrašytų reikalavimų formalizavimą [2, 3].

Projektuotojas

Vartotojas

IS naudojamosdokumentų formos

DB

Informacijos srautųspecifikacijos saugykla

informacijaapie IS

IS duomenų modelis

IS duomenųmodeliavimo CASE

Dokumentų formųanalizės modulis

ER schemossudarymo modulis

ER schemųintegravimo modulis

taisyklėsapribojimaiduomenys

duomenys

2 pav. IS duomenų modelio sudarymas informacijos srautų specifikacijos pagrindu

– 503 –

A. Aleksandravičienė, R. Butleris

Analizuojamą IS duomenų modeliavimo procesą sudaro 3 pagrindiniai etapai: 1. informacinių srautų (pagrinde dokumentų formų) parinkimas ir analizė; 2. atrinktų duomenų šaltinių struktūrą atitinkančių ER schemų sudarymas; 3. ER schemų integravimas. Siekiant sukurti kokybišką CASE priemonę, skirtą IS duomenų modeliui sudaryti informacijos srautų

specifikacijos pagrindu, reikia automatizuoti visus išvardintus duomenų modeliavimo proceso etapus (2 pav.) Vienas iš šio darbo tikslų yra formalizuoti ER schemų integravimo procesą informacijos srautų specifikacijos

pagrindu ir programiškai realizuoti ER schemų integravimo algoritmą. Tolesniuose skyriuose bus supažindinama su ER schemų integravimo procesu, pateikiamos pagrindinės literatūros šaltiniuose aprašomos schemų integravimo problemos ir jų sprendimo būdai, sukurti integravimo metodai, schemų konfliktų tipai.

4. ER schemų integravimas informacijos srautų specifikacijos pagrindu

ER schemų integravimas sistemos projektavimo etape yra suprantamas kaip ER schemų, sudarytų skirtingiems kompiuterizuojamos organizacijos duomenų šaltiniams, apjungimas į vieną, išsprendžiant visus tarp jų iškilusius konfliktus. Tai, kurių duomenų šaltinių ER schemas galima ir reikia integruoti, informacijos srautų specifikacijoje nurodo duomenų srautai. Duomenų srauto (DS) struktūrą sudarantys elementai parodo, kokia informacija sieja du integruojamus duomenų šaltinius. Duomenų šaltinio ir duomenų srauto sąvokos informacijos srautų specifikacijos kontekste detaliai pristatytos A.Aleksandravičienės darbe [1].

2 DŠ ERschema

1 DŠER schema

INTE

GR

AV

IMO

TAIS

YK

LĖS

IntegruotaER schema

DS

1 DŠ 2 DÐER modeliavimo

taisyklėsER modeliavimo

taisyklės

3 pav. Integruotos ER schemos sudarymo procesas

– 504 –


Schemų konfliktai – tai semantiniai, struktūriniai ir kt. prieštaravimai tarp dviejų integruojamų schemų. Norint sudaryti vieningą schemą, reikia išspręsti visų tipų konfliktus tarp integruojamų schemų [5,7]. Šiame straipsnyje schemų konfliktams aprašyti skiriamas atskiras skyrius – “5.2. Žinomi konfliktų tipai”.

ER schemų integravimo procesas yra iteratyvus. Skirtingų duomenų šaltinių struktūrą atitinkančios ER schemos į jau suintegruotą schemos dalį įtraukiamos po vieną.

Integruotos ER schemos sudarymo procesas schematiškai pavaizduotas 3 pav. Integravimo taisyklės – tai visų galimų konfliktų tarp integruojamų schemų sprendimo formalizuoti aprašai. Šios integravimo taisyklės ir ER schemos sudarymo apribojimai yra integruoto duomenų modelio sudarymo veiksmų sekos nustatymo pagrindas. Formaliai aprašyta ir programiškai realizuota ši veiksmų seka būtų vienas iš trijų IS duomenų modelio sudarymo CASE modulių.

5. Integravimo problema įvairių autorių vertinimu

Moksliniuose šaltiniuose integravimo problematika plačiai analizuojama. Analizuoti metodai yra skirti nevienalyčių duomenų bazių integravimui ir taikomi ne sistemos projektavimo, o diegimo ir palaikymo etapuose. Tačiau nepaisant konteksto skirtumų, analizuojamos ir sprendžiamos integravimo problemos yra panašios. Fizinių duomenų bazių integravimo procesas vykdomas dviem lygmenimis:

1. schemų lygiu; 2. duomenų lygiu. Schemų ir duomenų integravimo problema yra žinoma ir aktuali nuo tada, kai siekiant prasmingai panaudoti

didelius kiekius palikuoninėse sistemose saugomų duomenų, jas pradėta integruoti į naujas sistemas. Pagrindinis šios srities specialistų tikslas yra sukurti programinį vartotojui draugišką integravimo įrankį, kuris automatiškai nustatytų konfliktus tarp integruojamų duomenų šaltinių ir pateiktų vartotojui šių konfliktų sprendimo alternatyvas. Išsprendus konfliktus tarp atitinkamų schemų konceptų ir suderinus atitinkamus duomenis, gaunamas visuotinis vaizdinys, kuriuo operuoja multi duomenų bazės vartotojas. Skirtingiems vartotojams pagal jų poreikius gali būti suformuoti skirtingi vaizdiniai [5].

Integravimo problematika ir jos sprendimo būdų paieška yra populiari tyrimų sritis visame pasaulyje. Ji domina ir mokslininkus, ir sistemų inžinierius, todėl įdirbis šioje srityje yra ženklus. R.Lawrence pasiūlė schemų integravimo metodus klasifikuoti į 8 kategorijas:

1. modeliu grindžiami metodai ir euristiniai algoritmai; 2. schemų re-inžinerijos metodai; 3. meta duomenų metodai; 4. objektiškai orientuoti (OO) metodai; 5. integravimo taikomųjų programų lygyje metodai; 6. integravimo, naudojat tarpinę duomenų bazę, metodai; 7. dirbtinio intelekto metodai; 8. leksinės semantikos metodai. Toliau bus detaliau aptarti 2 aukščiau įvardinti schemų integravimo metodai: modelio pagrindu veikiantys ir

meta duomenų metodai. Ne vieno straipsnio autorius, nagrinėjantis nehomogeninių duomenų bazių integravimo problemas, siūlo

pagrindinių konfliktų, iškylančių integravimo proceso metu, sąrašą, kuriame schemų ir duomenų lygio konfliktai yra atskirti ir susisteminti.

5.1. Integravimas, taikant žinomus integravimo metodus

Seniausi ir plačiausiai naudojami integravimo metodai, pasak R.Lawrence [5], yra modeliu grindžiami metodai (angl. model-based methods). Taikant šiuos metodus, informacija apie duomenų bazę surenkama, naudojant semantinius modelius. Integravimo procese būtinas vartotojo dalyvavimas. Modeliu grindžiami metodai pradėti analizuoti apie 1986 metus; nustatyta, kad jie naudojami globalaus vaizdinio (angl. global view) sukūrimui vienoje duomenų bazėje arba paskirstytose duomenų bazėse.

Dauguma šių metodų veikia tokio šabloninio algoritmo pagrindu: 1. veiksmai iki integravimo (atliekama integruojamų schemų analizė ir parenkamas integravimo algoritmas,

nustatomas integravimo veiksmų eiliškumas, surenkama papildoma informacija); 2. schemų palyginimas (palyginami schemų konceptai ir nustatomi schemų konfliktai); 3. schemų suderinimas (išsprendžiami schemų konfliktai);

– 505 –

A. Aleksandravičienė, R. Butleris

4. apjungimas ir pertvarkymas (schemos apjungiamos ir pertvarkomos pagal iš anksto apibrėžtus tam tikrus kriterijus).

Modeliu grindžiami metodai yra silpnai automatizuoti, vartotojas dažnai turi spręsti schemų konfliktus rankiniu būdu. Dėl šių priežasčių modeliu grindžiami metodai netinkami didelės apimties integravimo uždaviniams spręsti.

Meta duomenų metodai (angl. metadata approaches) yra skirti palikuoninėse sistemose specifikuotų schemų integravimui. Kadangi šiuo atveju, schemų meta duomenys ir semantika nežinoma, problemą bandoma spręsti apibrėžiant modelius, kuriuose saugomi meta duomenys. Tai supaprastina integravimo uždavinį.

Meta duomenys yra atributų lygio taisyklių rinkinys, kai taisyklė apibrėžia atributo semantiką schemų ir duomenų lygyje. Naudojantis šiomis taisyklėmis, nustatomas schemų ekvivalentumas ir vykdomas integravimas.

Šie metodai geri tuo, kad automatiškai apdorojamų (angl. machine-processable) taisyklių formoje jie saugo tam tikrą duomenų semantiką. Šias taisykles turi sudaryti sistemos projektuotojas. Be to, iki šiol nėra išspręsta, kaip surinkti meta duomenis į modelį, kurį būtų galima panaudoti automatiniam schemų integravimui be vartotojo pagalbos.

Meta duomenų metodai, pagrįsti taisyklėmis, yra taikomųjų programų lygio integravimo ir mažos žinių bazės, kurioje saugoma informacija, skirta programavimo uždaviniui palengvinti, derinys.

5.2. Žinomi konfliktų tipai

Toliau bus aptarti visi žinomi schemų lygmens konfliktų tipai. Pasak K.Sattler [7], šiuo metu mokslinės literatūros šaltiniuose yra pasiūlytos kelios schemų lygio konfliktų klasifikacijos, kuriomis remiantis, visus šiuos konfliktus teoriškai galima suskirstyti į 4 klases:

1. semantiniai konfliktai; 2. vaizdavimo konfliktai; 3. nevienalytiškumo konfliktai; 4. struktūriniai konfliktai. Praktiškai nustatyti konflikto tipą yra žymiai sudėtingiau, nes integravimo metu paprastai susiduriama su kelių

konfliktų tipų derinių atvejais. Todėl norint išspręsti schemų lygio konfliktą, pirmiausiai būtina jį įvertinti skirtingais aspektais.

Toliau įvardinti schemų lygio konfliktai bus aprašyti detaliau.

5.2.1. Semantiniai konfliktai

Šio tipo konfliktai iškyla tarp dviejų to paties tipo konceptų, priklausančių skirtingoms schemoms, kurias reikia integruoti. Konceptas schemoje atvaizduoja bet kokių realaus pasaulio objektų aibę; priklausomai nuo konkretaus duomenų modelio, tai gali būti klasė, esybė, lentelė ir pan.

Schemos integruojamos nustačius jų persidengiančias dalis ir tai, kaip šios dalys viena kitą atitinka. Dažniausiai šie atitikimai būna netikslūs. Pvz., dvi persidengiančios esybės viena kitą atitikti gali įvairiai. Iš viso galimi 4 atitikimo variantai: ekvivalentumas, priklausomybė, persidengimas ir nepersikirtimas [4,7]. Šiuos atitikimus galima išreikšti matematiškai, naudojant aibių teorijos priemones (4 pav.).

priklausomybė

ab

ekvivalentumas persidengimas nepersikirtimas

ba ba

c

ab

4 pav. Atitikimų topologija

5.2.2. Vaizdavimo konfliktai

Šio tipo konfliktai yra specifiniai, jų neįmanoma tiksliai apibrėžti. Jie iškyla dėl skirtingų konceptų, priklausančių integruojamoms schemoms, savybių (atributų) aibių. Kita dalis šio tipo konfliktų yra homonimų ir sinonimų naudojimo konceptų įvardijimui rezultatas. Homonimai – tai visiškai skirtingos to paties žodžio reikšmės; sinonimai – tai skirtingai skambantys, bet tos pačios arba labai artimos reikšmės žodžiai. Anot [7], schemų lygio konfliktų, iškylančių dėl sinonimų ir homonimų naudojimo, įvardijant schemų konceptus, negalima išspręsti automatiniu būdu, be vartotojo pagalbos.

Be to, dalis įvardijimo konfliktų kyla dėl skirtingų duomenų tipų ar matavimo vienetų.

– 506 –


5.2.3. Nevienalytiškumo konfliktai

Šiam konfliktų tipui priskiriami visi konfliktai, kylantys dėl skirtingų duomenų modeliavimo metodų panaudojimo, sudarant atskiras schemas. Tai reiškia, jog integruojamoms schemoms sudaryti buvo panaudotos skirtingos konceptų aibės. Nevienalytiškumo konfliktai yra glaudžiai susiję su kito tipo konfliktais – struktūriniais.

5.2.4. Struktūriniai konfliktai

Struktūrinio tipo konfliktai integravimo metu iškyla tokiu atveju, kai tam pačiam realaus pasaulio faktui atvaizduoti dviejose schemose buvo panaudoti skirtingų tipų konceptai. Paprastai su šia problema susiduriama, jeigu sudarant duomenų modelį buvo nepaisyta modeliavimo taisyklių.

Ypatinga struktūrinių konfliktų dalis yra vadinama meta konfliktais. Šie konfliktai iškyla tuomet, kai vienoje iš integruojamų schemų ta pati realaus pasaulio objektų aibė yra atvaizduota kaip savybių (atributų) aibė, o kitoje – kaip schemos objektas (klasė, esybė, ir pan.).

Pasak [5], Integruojant reliacinio ER modelio schemas, gali iškilti šie struktūriniai konfliktai: 1. atributo-esybės konfliktas; 2. atributo-ryšio konfliktas; 3. esybės-ryšio konfliktas.

6. Išvados

Straipsnyje aptarta tyrimų sritis ir darbo tikslai, apžvelgiant tolesnių tyrimų erdvę. Nors dėl ribotos tyrimų srities analizės dar negalima atlikti išsamų žinomų metodų vertinimą, akcentuojant silpnąsias ir stipriąsias jų puses, tačiau galimi tam tikri apibendrinimai.

Visi iki šiol išnagrinėti schemų integravimo metodai yra skirti fizinių duomenų bazių integravimui, o ne kuriamos IS integruotam duomenų modeliui sudaryti. Vienas iš svarbiausių aspektų – tai meta modelyje saugomos informacijos panaudojimas integravimo proceso metu. Nemažiau svarbi koncepcija yra žinių bazės panaudojimas integravimo taisyklėms kaupti. Išnagrinėti schemų lygio konfliktų tipai ir nustatyta, kad nevienalytiškumo konfliktai neaktualūs, jei integruojamos schemos sudaromos taikant reliacinio ER modelio sudarymo metodą.

Literatūros sąrašas [1] Aleksandravičienė A., Butleris R., Danikauskas T. Duomenų modeliavimas informacijos srautų specifikacijos pagrindu.

Konferencijos “Informacinės technologijos’ 2004” pranešimų medžiaga, Kaunas: Technologija, 2004, p. 473-478. [2] Barker R. CASE method: Entity-Relationship Modeling. Addison-Wesley Publishing Company, 1996, Chapter 5: p. 1-11. [3] Butkienė R. Informacijos sistemai keliamų funkcinių reikalavimų specifikavimo metodas: daktaro disertacijos santrauka.

Kaunas: Technologija, 2002, p. 3-5. [4] Chao Ch.M. Schema Integration between Object-Oriented Databases. Tamkang Journal of Science and Engineering, Vol.

4, No. 1 (2001), p. 37-44. [5] Lawrence R. Schema Integration Methodologies for Multidatabases and the Relational Integration Model – Candidacy

document. Department of Computer Science of Manitoba, 1999. [6] Moody D.L., Shanks G.G. Improving the quality of data models: empirical validation of a quality management

framework. Pergamon: Information systems, 28 (2003), p. 619-650. [7] Sattler K.U., Conrad S., Saake G. Interactive example-driven integration and reconciliation for accessing database

federations. Pergamon: Information systems, 28 (2003), p. 393-414.

Data Model Design on the Basis of ER Schema Integration

This paper describes the importance of the quality of data model and it’s impact to the successful functionality of the system exploited. The process of data modelling on the basis of the data flow specification is introduced. There are three main phases of the data model design: 1) analysis and selection of document examples (data sources); 2) ER schema design on the basis of the structure of data source; 3) ER schema integration. The purpose of my Ph.D. studies is to create an automated tool of the third phase of data model design on the basis of the data flow specification. Database integration is one of the most common problems in the world. The main difference between analysed integration methods and my research is the differences of the context they are applied. But there are some ideas that can be successfully used. ER schema integration is creating a global ER schema by resolving schema and data conflicts between different schemas. Schema level conflicts are proposed it detail in this paper.

– 507 –

DUOMENŲ SAUGYKLŲ TAIKYMAS MOBILIOSE SISTEMOSE

Andrej Ušaniov, Packevičius Šarūnas, Eduardas Bareiša Kauno Technologijos universitetas, Informatikos fakultetas, Programų Inžinerijos Katedra

Studentų g. 50, LT - 3031 Kaunas

Mobiliųjų įrenginių platus taikymas bei vartojimas informaciniuose sistemose buvo beprasmis dėl pačių įrenginių ribotų galimybių bei mobiliųjų duomenų saugyklų nebuvimo. Informacinės sistemos su mobiliais įrenginiais negalėdavo suteikti savo vartotojams pridėtinės vertės atitinkančios informacinės sistemos kainos. Tačiau situacija pasikeitė, atsiradus priemonėm, leidžiančios organizuoti mobiliąsias duomenų saugyklas. Šiuo metu mobilios informacinės sistemos kūrėjai susiduria su jų poreikius atitinkančios mobilios Duomenų Bazių Valdymo Sistemos pasirinkimo problema.

Pranešime apžvelgiamos duomenų saugyklų mobiliuose įrenginiuose organizavimo būdai bei technologijos: Java Record Management System, Microsoft Pocket PC platformos duomenų bazės, Palm OS platformos duomenų bazės, Išorinių duomenų bazių panaudojimas

1. Įžanga

Mobiliųjų įrenginių platus taikymas bei vartojimas informaciniuose sistemose buvo beprasmis dėl pačių įrenginių ribotų galimybių bei mobiliųjų duomenų saugyklų nebuvimo. Informacinės sistemos su mobiliais įrenginiais negalėdavo suteikti savo vartotojams pridėtinės vertės atitinkančios informacinės sistemos kainos. Tačiau situacija pasikeitė, atsiradus priemonėm, leidžiančios organizuoti mobiliąsias duomenų saugyklas. Šiuo metu mobilios informacinės sistemos kūrėjai susiduria su jų poreikius atitinkančios mobilios Duomenų Bazių Valdymo Sistemos pasirinkimo problema.

Kuriant programinė įranga mobiliems įrenginiams, duomenų bazė mobiliame įrenginyje numatoma norint tiekti vartotojui priėjimą prie jam reikiamų duomenų, greitą duomenų pasiimimą net ir dirbant atsijungus nuo tinklo. Tokio sprendimo atveju būna reikalinga r duomenų sinchronizacijos su pagrindine duomenų baze mechanizmai. Projektuojant tokia programinę įrangą tenka pasirinkti duomenų bazės valdymo sistemą mobiliam įrenginiui. Mobilaus įrenginio techniniai parametrai ir jo programinė įranga apriboja projektuotojo galimybes pasirinkti tinkamą duomenų bazės valdymo sistemą mobiliam įrenginiui.

2. Metrikos

Norint įvertinti duomenų bazių valdymo sistemų mobiliems įrenginiams galimybes ir jų tinkamumą kuriant programinę įrangą mobiliems įrenginiams buvo vertinami tokie parametrai, jie pateikti sekančioje lentelėje.

3. Duomenų bazės mobiliuose įrenginiuose

Analizuojamos tokios duomenų bazių valdymo sistemos mobiliems įrenginiams: • Java Record Management System • Microsoft SQL CE Server • Oracle Database Lite • DB2 Everyplace

3.1. Java Record Management System

Kaip ir daugeliui desktop-based programų, MIDletams (Java mobiliosios programos) reikalinga pastovi duo-menų saugojimo priemonė. Skirsime duomenys į dvi grupes: vartotojo duomenys ir programos duomenys. Vartotojo duomenų saugojimas yra labai svarbus. Tačiau mobiliųjų įrenginių galimybės, lyginant su desktop sistemomis, yra labai ribotos. Dėl šių apribojimų mobilus įrenginiai neturi įprastos failų sistemos koncepcijos. J2ME (Java 2 Micro Edition) bazinės klasės skirtos darbui su duomenų saugykla, neatvaizduoja duomenų paskirstymo į vartotojo ir programos grupes.

– 508 –

Duomenų saugyklų taikymas mobiliose sistemose

1 lentelė. Duomenų bazių valdymo sistemų mobiliems įrenginiams palyginimo kriterijai.

Kriterijus Aprašymas Platforma Kokiuose delniniuose įrenginiuose galima naudoti. (PocketPC, PalmOS, Windows CE ir

pan.) Atminties sunaudojimas

Kiek reikia atminties mobiliame įrenginyje, kad suktųsi duomenų bazės valdymo sistema.

Duomenų bazės dydis

Kokio dydžio galima sukurti duomenų bazę mobiliame įrenginyje.

Duomenų bazės tipas

Reliacinė, failų sistema paremta.

Ryšys su kitomis DB

Ar yra galimybė sinchronizuoti duomenis su duomenų bazėmis esančiomis serveriuose.

Sinchronizavimo protokolas

Koks protokolas naudojamas sinchronizuoti duomenų bazes tarp mobilių įrenginių ir serverių. SyncML, ActiveSync ir pan.

Sinchronizavimo konfliktų sprendimas programiškai

Ar yra galimybės programiškai išspręsti sinchronizavimo metu iškilusias problemas. T.y. ar yra galimybė rašyti kokius plug-ins sinchronizavimo protokolui.

Sinchronizavimo konfliktų sprendimo vieta.

Serveryje, mobiliame įrenginyje. Programuojama atskirai.

Duomenų bazių kiekis

Kiek duomenų bazių galiam sukurti mobiliame įrenginyje.

Lentelių kiekis Kiek galima sukurti lentelių duomenų bazėje mobiliame įrenginyje. Laukų kiekis Kiek galima sukurti lentelėje laukų. Stored Procedūrų palaikymas

Ar galima naudoti Stored procedūras duomenų bazėje mobiliame įrenginyje.

SQL palaikymas Kuria SQL versiją palaiko duomenų bazė mobiliame įrenginyje. Palaikomi duomenų tipai.

Kokius duomenų tipus palaiko mobili duomenų bazė.

Duomenų bazės valdymo įrankiai

Ar yra duomenų bazės valdymo įrankiai pasiekiami mobiliame įrenginyje.

Programavimo priemonės.

Ar yra bibliotekos skirtos ADO.NET, ADO, ODBC, JDBC, native biblioteka.

Index palaikymas Ar palaiko duomenų bazė indeksavimą. Foreighn key palaikymas

Ar palaiko duomenų bazė Foreighn key.

Primary Key Palaikymas

Ar palaiko duomenų bazė Primary key.

Sinchronizavimas iš kelių serverių.

Ar galiam sinchronizuoti duomenis iš kelių serverių į ta pačia duomenų bazę mobiliame įrenginyje.

Sinchronizavimo stebėjimas

Ar yra programinės priemonės stebėti sinchronizavimo progresą.

Sinchronizavimas laukų.

Ar galima sinchronizuoti tik kelis laukus lentelėje vietoj visos eilutės.

Programų kiekis Ar gali kelios programos mobiliame įrenginyje pasiekti tą pačią duomenų bazę. Saugumas Ar yra priemonės apsaugoti duomenų bazę mobiliame įrenginyje (šifravimas,

autentifikavimas, autorizavimas) Kaina Kieka kainuoja licenzija vienam mobiliam įrenginiui.

Record Management System (RMS) tai įrašų pagrindu veikianti duomenų bazė. Įrašas – tai susijusios informacijos rinkinys apie esybę/objektą. Kiekvienas įrašas turi vienodą aibę laukų, kurių ilgiai yra fiksuoto dydžio.

– 509 –

A. Ušaniov, Š. Packevičius, E. Bareiša

Įrašų skaitymas/rašymas atliekamas per unikalų įrašų identifikatorių recordId, kuris yra pirminis raktas. RMS sistema yra atsakinga už recordId valdymą: naujų išskirimą, unikalumo palaikymą. Įrašų skaitymas vyksta ne baitų lygmenys, o įrašų lygmenyje, t.y. per vieną kartą galima įrašyti arba nuskaityti tik vieną įrašą. Įrašo turinys nėra svarbus RMS sistemai, ji mato įrašus kaip baitų masyvą. Vienintelis dalykas kuris rupi RMS tai recordId. Įrašų koncepcija RMS sistemoje pavaizduota 1 paveikslėlyje.

1 pav. Įrašų koncepcija RMS sistemoje

MIDletai yra pristatomi MIDletų rinkiniuose. Viename MIDletų rinkinyje yra mažiausiai vienas MIDletas. MIDletui sukūrus įrašų saugyklą, ji yra prieinama visiems MEDletų rinkinio MIDletams. Įrašų saugyklos pavadinimas turi būti unikalus MIDletų rinkinyje. MIDletas gali pasiekti įrašų saugyklą tik savo MIDletų rinkinyje.

Programos kūrėjai tūrėtų skirti dėmesio RMS veikimo greitaveikos analizei. Kadangi priklausomai nuo J2ME platformos realizacijos, skirtingos RMS funkcijos veikia skirtingu greičiu. Pvz. Kai kuriose sistemose dirbant su dideliais duomenų kiekais ir norint atlinkti tam tikrų įrašų modifikacija yra efektyviau perskaityti visą saugyklos (RecordStore) turinį, ištrinti saugyklą ir sukurti naują, kurioje užsaugoti modifikuotus įrašus vietoj to, kad atnaujinti(update) įrašus skirtus modifikavimui.

3.2. Microsoft SQL CE Server

SQL Server CE yra maža duomenų bazė skirt avis dažniau kuriamoms programoms kurios išplečia duomenų valdymo galimybes iki mobilių įrenginių. SQL Server CE yra pilnateisis narys tarp SQL Server 2000 šeimos produktų. Turi įrankius skirtus DB valdymui, programavimo sąsajas (API), ir SQL sintakse, kuri yra pažystama visiems programuotojams dirbantiems su SQL Server produktais. SQL CE yra vienintelis produktas iš SQL Server 2000 šeimos, kuris teikia reliacinės duomenų bazės galimybes Windows CE paremtiems įrenginiams. SQL CE turi:

• optimizuojantį užklausų procesorių • Transakcijų palaikymą. • Duomenų tipų palaikymą. • Mažai naudoja sistemos resursų. • Remote Data Access ir Merge Repclication per HHTP protokolą.

3.3. Oracle Database Lite

2 pav. Oracle Database Lite sistemos sudėtis

Oracle Database Lite yra priedas prie Oracle duomenų bazės naudojamas dažnam kūrimui ir diegimui didelės svarbos, mission-critical programoms skirtoms mobiliems įrenginiams. Oracle Database Lite naudoja duomenų sinchronizavimą, kad patikimai ir saugiau apsikeistų duomenimis tarp Oracle Database ir nutolusios aplinkos. Darbuotojai gali naudotis kompanijos informacija ir atlikti jiems riekiamas funkcijas būdami atsijungę nuo kompanijos duomenų bazės. Kompanijos naudojamos Oracle Database Lite gali apdidinti darbuotojų produktyvumą,

– 510 –


sumažinti darbų sąnaudas, ar padidinti klientų pasitenkinimą. Sekančiame paveikslėlyje pateikta Oracle Database Lite sistemos vaizdas.

3.4. DB2 Everyplace

IBM DB2 Everyplace yra IBM produktas teikiantis duomenų bazės paslaugas mobiliems įrenginiams. DB2 Everyplace susideda iš trijų pagrindinių komponentų, tokių kaip duomenų bazės variklis, kuris sukasi mobiliame įrenginyje, sinchronizavimo serveris ir pagrindinė duomenų bazė, kuri sukasi desktop PC arba enterprise serveryje.

DB2 Everyplace leidžia vartotojams įsidėti fragmentus pagrindinės duomenų bazės į savo mobilius įrenginius ir sinchronizuoti juos su pagrindine duomenų baze. Duomenų bazės variklis mobiliame įrenginyje yra gana nereikus resursams jam užtenka net 200KB atminties.

Prie DB2 Everyplace teikiamas DB2 Everyplace’s MAB įrankis leidžiantis sukurti programas, naudojančias DB2 Everyplace duomenų bazę nerašant kodo. Šis įrankis sugeneruoja programą kuri gali būti pritaikyta konkrečiam mobiliam įrankiui arba tiesiog J2SE kodas, kuris gali būti vykdomas betuokiame įrenginyje.

Duomenų sinchronizavimams vyksta naudojantis HTTP protokolu, sinchronizavimo serveryje yra java servletas, kursi gali būti patalpintas betuokiame servletus palaikančiame serveryje (Tomcat, WebSphere ir pan.).

DB2 Everyplace teikia įvairias priemones dirbti su duomenų baze, tokais kaip C/C++, Java, Visual Basic, .NET bibliotekas.

4. Palyginimo rezultatai

Išanalizavimus duomenų bazių valdymo sistemas skirtas mobiliems įrenginiams palyginimo rezultatai yra pateikti žemiau esančioje 2 lentelėje.

2 lentelė. Duomenų bazių valdymo sistemų mobiliems įrenginiams palyginimo kriterijai

DBMS Kriterijus

Java Record Management

System Microsoft SQL CE Server Oracle Database

Lite DB2 Everyplace

Platforma PocketPC, PalmOS, Symbian, kitos

Windows CE, Pocket PC, Windows Mobile

Windows CE, Pocket PC, Windows Mobile, Windows NT/XP/2000/98, PalmOS, Linux

Linux, Neutrino, PalmOS, Symbian, Windows, Windows CE, Windows Pocket PC

Atminties sunaudojimas.

Priklauso nuo JVM realizacijos

Nedidelis 150KB – 1MB 137 KB

Duomenų bazės dydis

Ribojamas mobilaus įrenginio laisvos atminties kiekiu

Iki 2 GB Iki 4 GB Ribojamas mobilaus įrenginio laisvos atminties kiekiu

Duomenų bazės tipas

Įrašų pagrindu

Reliacinė. Reliacinė. Reliacinė

Ryšys su kitomis DB

Nėra Tik Microsoft SQL Server. Oracle Per “DB2 Everplace’s synchronization server” su DB2, Oracle, Microsoft SQL server, Domino and Exchange

Sinchronizavimo protokolas

Atskirai programuojamas

Vidinis (RDA, Merge Repclication). Publish/Subscription modelis. Push modelis.

SyncML

– 511 –

A. Ušaniov, Š. Packevičius, E. Bareiša

Sinchronizavimo konfliktų

sprendimas programiškai

Atskirai programuojamas

Yra Yra Yra

Sinchronizavimo konfliktų

sprendimo vieta.

Programos projektuotojas sprendžia

Mobiliame įrenginyje, programiškai. Sisteminė ir programuojama.

Sisteminė ir programuojama.

Duomenų bazių kiekis

Ribojamas mobilaus įrenginio laisvos atminties kiekiu

Neribotas. Neribotas. Neribotas

Lentelių kiekis Ribojamas mobilaus įrenginio laisvos atminties kiekiu


Laukų kiekis Ribojamas mobilaus įrenginio laisvos atminties kiekiu


Stored Procedūrų palaikymas

Nėra Nėra Yra. Yra

SQL palaikymas Nėra Yra. Yra. (SQL-92) Yra. (SQL-99) Palaikomi

duomenų tipai. Byte INT, FLOAT, CHAR, VARCHAR. Oracle DB tipai. IBM DB2 tipai

Duomenų bazės valdymo įrankiai

Nėra Yra (SQLCE Query) Yra. Yra

Programavimo priemonės.

J2ME API ADOCE, ADO.NET, ADO. JDBC, ADOCE, ADO, ADO.NET.

JDBC, ADO.NET

Index palaikymas Nėra Nėra. Yra Yra Foreighn key palaikymas

Nėra Yra. Yra Yra

Primary Key Palaikymas

Yra Yra. Yra Yra

Sinchronizavimas iš kelių serverių.

Programuojamas atskirai

Nėra. Nėra. Nėra.

Sinchronizavimo stebėjimas

Nėra Nėra. Nėra. Nėra.

Sinchronizavimas laukų.

Programuojamas atskirai

Nėra. Tik eilutės. Nėra. Yra

Programų kiekis Neribotas 1 programa prie 1 duomenų bazės. Neribotas. Neribotas. Saugumas Programuoja

mas atskirai Duomeny bazės šifravimas. Autentifikavimas.

Autentifikavimas, Autorizavimas, šifravimas.

Autentifikavimas, Autorizavimas, šifravimas.

Kaina Nemokama Nemokamai SQL Server 2000 Developer Edition vartotojams.

Nemokama. Nemokama.

5. Išvados

SQL CE tinka jei programinės įrangos pagrindinės duomenų bazės yra realizuotos SQL Server 2000 duomenų bazėse. Jei aplinkoje naudojamos Oracle ar kitokios duomenų bazės SQL CE nebeturi prasmės, nes negali su jomis sinchronizuoti duomenų.

– 512 –


Nepaisant ribotų mobiliųjų įrenginių galimybių, RMS suteikia patogią ir lengvai naudojamą infrastruktūrą ilgalaikiam pastoviam duomenų kaupimui.

Oracle Database Lite yra gana puikus sprendimas, jei yra poreikis naudoti įvairaus tipo mobiliuose įrenginiuose. Galimybėmis aplenkia Microsoft SQL CE Server. Vienas minusas, kad sinchronizuojasi tik su Oracle duomenų bazėmis.

IBM DB2 Everyplace panašiai kaip Oracle Database Lite veikia įvairiose platformose teikia puikias sinchronizavimo galimybes. Bet taip pat kaip ir Oracle sinchronizuojasi tik su DB2 duomenų baze.

Literatūros sąrašas [1] Access data anywhere with Everyplace. [žiūrėta 2004-12-15], prieiga internete

http://www.infoworld.com/DB2_Everyplace_Enterprise_8.1.4/product_46523.html?view=1&curNodeId=0 [2] Java Database Review Places PointBase At The Top. [žiūrėta 2004-11-09], prieiga internete

http://wirelessdev.weblogsinc.com/entry/4868643664242743/ [3] Mobile Memories: The MIDP Record Management System. [žiūrėta 2004-11-14], prieiga internete

http://today.java.net/pub/a/today/2004/11/16/J2ME-3.html [4] Oracle Database Lite Overview. [žiūrėta 2004-11-10], prieiga internete

http://www.oracle.com/technology/products/lite/lite_datasheet_10g.pdf [5] Palm OS Database Applications. [žiūrėta 2004-12-13], prieiga internete http://www.the-gadgeteer.com/databases-

review.html [6] SQL Server 2000 Product Overview. [žiūrėta 2004-11-16], prieiga internete

http://www.microsoft.com/sql/evaluation/overview/default.asp

Data Stores Usage in Mobile Systems

Wide usage of mobile devices was quite useless because of the lack of resources in these devices and the lack of data storages for them. Information systems with mobile devices were unable to add additional value to theirs user for a given price. Though, situation has changed with increased resources and processing power on mobile devices. There are a lot of products of data storage systems in market. And developers of information systems encounter problems such as choosing a best Data Base Management System for mobile device.

In this article are described and analyzed data storages for mobile devices (Java Record Management System, DBMSD for Microsoft Pocket PC platform and Palm OS platform), and possibilities of using remote data bases.

– 513 –

PAKLAUSOS PROGNOZAVIMO ALGORITMŲ ĮJUNGIMAS Į KOMPIUTERIZUOTUS ĮMONIŲ VEIKLOS PROCESUS

Edgaras Bencevičius, Andrius Kriaučiūnas, vadovė doc. Lina Nemuraitė Kauno technologijos universitetas, Informacijos sistemų katedra, Studentų g. 50, Kaunas

Straipsnyje nagrinėjami paklausos prognozavimo poreikiai ir problemos prekybos sistemose, analizuojami galimi prognozavimo algoritmai. Prekybos sistemose su dideliu prekių asortimentu ir skirtingais prekių paklausos kitimo procesais tikslinga naudoti keletą algoritmų, kurių parametrai, laikui bėgant, perskaičiuojami. Pasiūlyta užsakymų informacinė sistema su paklausos prognozavimu, kuri pateikia vartotojui (tiekimo vadybininkui) rekomenduojamus prekių užsakymų dydžius, paremtus prognozavimo algoritmų duomenimis.

1. Įvadas

Žmogus visada nori numatyti ateitį, spėti ar prognozuoti, kaip keisis aplinka. Senovėje dažniausiai buvo bandoma nuspėti orus. Šiais laikais orai, tiksliau, meteorologija, yra tik viena iš daugelio sričių, kur naudojamas prognozavimas. Be gamtos reiškinių, svarbi prognozavimo naudojimo sritis – ekonomika. Akcijų, valiutų kurso ir kitų finansinių rodiklių prognozavimas reikalingas daugelio investavimo klausimų sprendimui. Prognozavimas vaidina svarbų vaidmenį darbo tvarkaraščių sudaryme, gamybos planavime, kadangi tikslus produkcijos poreikio numatymas yra svarbus optimalaus gamybos plano sudarymo faktorius.

Siekiant didesnio prognozavimo tikslumo, kuriami nauji metodai, modifikuojami jau sukurtieji ar pritaikomi tam tiesiogiai neskirti metodai, pavyzdžiui, ekspertinės sistemos. Ir atvirkščiai, prognozavimui skirti metodai pritaikomi klasifikavimo/diagnozavimo uždaviniams spręsti, pavyzdžiui, medicinoje, nustatant paciento priklausymą vienai ar kitai rizikos grupei.

Analizuojant prekybos įmonių problemas susijusias su tiksliu, savalaikiu ir teisingu prekių atsargų valdymu, išryškėjo, kad smulkioms ir vidutinėms įmonėms, kurioms per brangūs galingi duomenų analizės paketai, yra reikalinga lengvai įdiegiama informacinė sistema, kuri vienu metu pateiktų informaciją apie prekių atsargas, turėtų galimybę prognozuoti prekių kiekio dydžius ir leistų sudaryti prekių užsakymus.

Tokia sistema padidina prekybinės ar gamybinės veiklos ekonominį efektyvumą, nes užtikrina paklausai artimus atsargų kiekius ir neleidžia kauptis perteklinėms atsargoms. Ši sistema pranašesnė už esamus paketus tuo, kad prognozavimas yra įjungtas į vartotojo veiklos procesą, todėl jis vyksta greitai ir vadybininkas nesugaišta papildomo laiko.

Prieš kuriant sistemą buvo išnagrinėti teoriniai prognozavimo metodai, jų taikymo ypatumai, ir prognozavimo savybės ir nuspręsta informacinėje sistemoje adaptuoti keturis prognozavimo metodus:

1. Slenkančio vidurkio; 2. Paprasto eksponentinio glodinimo; 3. Dvigubo eksponentinio glodinimo; 4. Įvairialypio sezoninio prognozavimo. Pasirinkti metodai apima praktikoje dažniausiai pasitaikančius paklausos kitimo atvejus ir leidžia skirtingoms

prekėms pritaikyti tiksliausiai jų paklausą atitinkančius metodus. Norint nustatyti siekiamos sistemos savybes, buvo išnagrinėti „Forecasting Tools Graph“, „Captain Toolbox“

[1] ir „Forecast Pro“ prognozavimo paketai, kurie turi įvairiapusiškas prognozavimo galimybes, tačiau juose trūksta metodų parinkimo ir sujungimo su kita veikla galimybių. Išnagrinėti paketai turi savus prognozavime svarbius privalumus, kurių dalį buvo siekiama sukurti ir savo sistemoje, įgyvendinant atrinktus prognozavimo metodus taip, kad prognozavimas būtų suintegruotas su užsakymų dydžių skaičiavimu.

Kadangi prekybinėse organizacijose atskirais laikotarpiais dažnai yra taikomos įvairios akcijos, sistemoje įdiegta akcijų įvedimo ir valdymo galimybė.

Siekiant geriau pritaikyti sistemą prie realių situacijų, kai paklausos vidurkis ar net jos pobūdis kinta, nuspręsta įdiegti galimybę perskaičiuoti algoritmų koeficientus ar keisti prognozavimo metodus. Sistema buvo kuriama taip, kad ateityje būtų galima įvesti naujus prognozavimo algoritmus, nekeičiant jau esamos sistemos dalies.

– 514 –

Paklausos prognozavimo algoritmų įjungimas į kompiuterizuotus įmonių veiklos procesus

Programinėje įrangoje įgyvendinti uždaviniai: • Skirtingų prognozavimo metodų taikymas, svarbus prekybinėms įmonėms, turinčioms didelį prekių

asortimentą, kur įvairių prekių paklausos pobūdis yra skirtingas ir negalima taikyti vieno prognozavimo algoritmo;

• Prognozavimo algoritmo parinkimas, esant didelei prognozuojamų objektų įvairovei; • Pradinių algoritmų parametrų nustatymas pagal turimus faktinius proceso duomenis; • Prognozavimo paklaidų įvertinimas; • Prognozavimo algoritmų parametrų adaptavimas, kaupiantis faktiniams duomenims. Prekybinėms įmonėms ypatingai aktualu, kad informacinė sistema padėtų įvertinti algoritmų parametrus,

palyginti skirtingų algoritmų paklaidas. Pasirinkti algoritmai turi būti nuolat peržiūrimi, perskaičiuojami jų parametrai arba, reikalui esant, prekei parenkamas kitas algoritmas.

2. Duomenų analizės metodai

Duomenų analizės metodai naudojami įvairiose taikomosiose programose, kurias pagal paskirtį galima suskirstyti į grupes:

• pirkimo krepšelio analizė; • klientų segmentacija ir įvertinimas; • klaidingų situacijų identifikavimas; • pardavimų prognozavimas; • kainų politikos sudarymas. Prognozavimas – būsimų įvykių nusakymas, remiantis praeities duomenimis. Prognozavimo metodų yra daug:

prognozavimas pagal analogiją, pagal sukauptus duomenis, atsakomųjų veiksmų prognozavimas (kai priemonių imamasi tik po įvykio) ir kt. Bet kokiam prognozavimui reikia žinių bazės, naujos informacijos, kuri lyginama su turima, ir parengiamos išvados.

Prognozavimas remiasi tokiais principais: • Problema – tikslų nustatymas ir problemos struktūrizavimas; • Informacija – informacijos šaltinių paieška, duomenų rinkimas ir duomenų paruošimas; • Metodai – metodų parinkimas, metodų realizavimas ir prognozavimo derinimas; • Analizė – metodų ir neapibrėžtumų įvertinimas; • Prognozės naudojimas – apibendrinimas ir nagrinėjimas [5]; Darbų grafikų sudaryme, gamybos planavime, atsargų valdyme prognozavimas taip pat vaidina svarbų

vaidmenį, kadangi tikslus produktų poreikio numatymas yra svarbus optimalaus gamybos plano sudarymo faktorius. Prekybinėms įmonėms svarbi prognozavimo taikymo sritis – pardavimų prognozavimas. Paklausos prognozavimas apsprendžia tikslų ir teisingą įmonės atsargų valdymą, kas ypač svarbu platų prekių asortimentą turinčioms įmonėms. Daugiamate paklausa vadinamas įvairių prekių tipų paklausos vektorius. Norint prognozuoti daugiamatę paklausą, galima naudoti specialius daugiamatės paklausos prognozavimo algoritmus, tačiau jie pasiteisina tik tada, kai skirtingų prekių paklausa yra tarpusavyje susijusi. Priklausomybėms tarp skirtingų tipų prekių nustatyti būtų galima naudoti duomenų gavybos metodus [2]. Šiame darbe einama kitokiu keliu – kiekvienam prekių tipui parenkamas geriausiai tos prekės paklausos pobūdį atitinkantis prognozavimo algoritmas. Toks metodas aktualus supermarketams ar prekybos tinklams, prekiaujantiems įvairių rūšių prekėmis, kai skirtingų prekių paklausos kitimas gali turėti labai įvairų pobūdį. Siekiant įgyvendinti tokį metodą, buvo:

• Ištirti įvairūs prognozavimo algoritmai (autoregresinis, su trendu, su ciklais, su trūkiais, su sezoninėm komponentėm ) bei jų adaptavimo ir paklaidų skaičiavimo metodai;

• Sudarytas apsimokantis daugiamatės paklausos prognozavimo algoritmas paskirstytų atsargų valdymo informacinei sistemai, kur prognozavimas atliekamas vienam ar keliems intervalams į priekį, periodiškai patikslinant prognozavimo parametrus pagal sukauptas faktines reikšmes;

• Sukurta prekių atsargų valdymo sistema, kuri pateikia vartotojui (tiekimo vadybininkui) rekomenduojamus prekių užsakymų dydžius, apskaičiuotus remiantis paklausos prognoze.

– 515 –

E. Bencevičius, A. Kriaučiūnas, L. Nemuraitė

3. Prognozavimo metodų analizė

Laiko eilučių analizės metodai [3], [4], [6] duoda patikimus rezultatus, jei jie paremti tuo pačiu standartiniu nuokrypiu ir jei tos pačios sąlygos galioja praeityje ir ateityje. Laiko eilutėms dažniausiai priimtini keturi komponentai: trendai (Trend), sezoniniai (Seasonally), cikliniai (Cyclical) ir atsitiktiniai (Random):

• Trendų komponentai rodo prieaugio ar nuosmukio vidurkį per nustatytą laiką. Trendų komponentus leidžia nustatyti dvigubo eksponentinio sulyginimo, tiesinio ir eksponentinio glodinimo metodai (Double Exponential Smoothing, Linear and Exponential Growth methods).

• Sezoniniai komponentai rodo reikšmių kaitą su pasikartojimais atitinkamuose intervaluose. Pavyzdžiui, kai kurių produktų pardavimai labai priklauso nuo metų laiko (sezono).

• Cikliniai komponentai rodo judėjimus, kurių dažnis daugiau nei kartą per metus, dažniausiai taikomi ekonominiuose cikluose (infliacija, ekonominiai nuosmukiai). Šie komponentai neturi specifinių modelių.

• Atsitiktiniai komponentai rodo reikšmes, kurių kitimui negalima pritaikyti kokio nors modelio. Labiausiai atitinkantys metodai yra slankiojančio vidurkio (Moving Average) ir paprasto eksponentinio sulyginimo (Simple Exponential Smoothing).

Metodo pasirinkimas priklauso nuo prognozavimo tikslo ir laiko eilutės pobūdžio. Laiko eilučių modelius yra įprasta taikyti prognozavimo uždaviniuose.

3.1. Slenkančio vidurkio metodas

Šio metodo esmė – vietoj visų laiko eilutėje esančių duomenų prognozavimui atlikti imami tik naujausi pasirinkto ilgio intervalo duomenys. Kiekviena nauja prognozė anksčiausiai gautą faktinę reikšmę iš pasirinkto ilgio intervalo išstumia ir vėliausiai gauta reikšme intervale tampa gautoji prognozė. Tai galima traktuoti kaip skaičiavimų poslinkį laiko eilutėje. Ft+1=At; (1) Čia At = (Dt + Dt-1 + Dt-2 + ... + Dt-N+1)/N; N – intervalo ilgis; Dt – stebėjimai laiko eilutėje.

Kyla klausimas kaip pasirinkti teisingą intervalo ilgį? Didėjant intervalo ilgiui N didėja suglodinimas ir prognozavimo stabilumas ir, atvirkščiai, mažėjant N, mažėja suglodinimas ir prognozavimo stabilumas. Slenkančio vidurkio algoritmai pasižymi tuo, kad prognozei nutolus toliau nuo vidurkio, tas vidurkis vis labiau ją traukia prie savęs, todėl šis metodas lėtai reaguoja į pasikeitimus.

3.5 Paprasto eksponentinio glodinimo metodas

Tai specialus metodas, kuriame imami visi praeities stebėjimai, tačiau prognozei didesnę reikšmę turi paskutiniai stebėjimai laiko intervale nei įvykę daug anksčiau, taigi jei 0<α <1, tai laiko eilutėje stebėjimų svoriai bus: α ,α (1-α ), α (1-α )2, α (1-α )3,… Kiekvienam laiko periodui t, glodinimo reikšmė Ft yra randama taip:

[ ]L

L

+−−+−−+−=

+−−+−−+−=

3)1(2)1(1

32)1(2)1(1

tYatYtYtFtYtYtYtF

αααα

ααααα → (2) 1)1(1 −−+−= tFtYtF αα

čia α - glodinimo parametras; Ft – prognozė periodui t; Ft-1 – paskutinio periodo prognozė; Yt-1 - paskutinio periodo faktinė reikšmė.

Koeficiento a apskaičiavimo formulė: ;)(

))((

1

2

1

∑

∑

=

=

−

−−= n

iii

n

iiiii

YX

YXYZα (3)

3.6. Dvigubo eksponentinio glodinimo metodas

Dvigubas eksponentinis glodinimas naudojamas, atsiradus trendui. Trendas – glodi determinuota funkcija, atspindinti ilgalaikes kitimo tendencijas. Kai egzistuoja trendas, prognozavimo algoritmas turi skaičiuoti trendą, nes serijos vidurkis ignoruoja trendą, dėl ko prognozė visada bus žemesnė (su didėjančiu trendu ) ar aukštesnė (su mažėjančiu trendu), nei faktinė paklausa.

Dvigubas eksponentinis glodinimas sulygina (suglodina) vidurkius: serijos vidurkį ir trendą. Prognozė periodui t+1:

Ft+1 = At + Tt (4)

– 516 –


Čia vidurkis: At = aDt + (1 - a) (At-1 + Tt-1) = aDt + (1 - a) Ft ; trendo vidurkis: Tt = β CTt + (1 – β ) Tt-1 ; Einamas vidurkis: Tt = At - At-1 .At - eksponentiškai suglodintas vidurkis serijos periode t; Tt - eksponentiškai suglodintas vidurkis trendo periodo t; CTt - einamas stebėjimas trendo periode t;a - glodinimo parametras tarp 0 ir 1 vidurkių suglodinimui.;β - glodinimo parametras tarp 0 ir 1 trendo suglodinimui;

Koeficiento β perskaičiavimo formulė: ;)(

))((

1

211

1111

∑

∑

=−−

=−−−

−−

−−−= n

iiii

n

iiiiii

TAA

TAATTβ (5)

3.7. Įvairialypis sezoninis metodas

Sezoniškumo faktoriai pasireiškia tuo, kad bendras vidurkis intervale lieka pastovus, bet yra intervalai, kuriuose vidurkis ryškiai skiriasi. Tai gali būti sritis nuo tikrųjų svyravimų tarp sezonų iki svyravimų tarp mėnesių, savaičių, dienų savaitėje ir t.t. Dirbant su sezoniniu efektu, prognozavimui iškyla du spręstini uždaviniai:

1. Prognozė esamam periodui (metams) turi būti padaryta, naudojant bet kurį prognozavimui tinkamą metodą. 2. Prognozė laiko intervalui, kuris turi sezoniškumą, turi būti priderinta, kad atspindėtų sezoninį efektą

kiekviename periode (pvz.: mėnuo ar ketvirtis ). Įvairialypis sezoninis metodas pritaikytas gauti prognozę įvertinant sezoninius faktorius. Tarkime, kad metuose

yra keli sezonai, todėl apibrėžiame sezonų skaičių p. Skaičiuojamas metų vidurkis: At = (Dt + Dt-1 + Dt-2 + ... + Dt-

N+1)/N; Čia N – metuose įvykęs stebėjimų skaičius; Skaičiuojami sezoniniai koeficientai:

SK1= A1/At, SK2=A2/At,…, SKp=Ap/At; (6) Skaičiuojama prognozė slenkančio vidurkio metodu: At = (Dt + Dt-1 + Dt-2 + ... + Dt-N+1)/N; Čia N- intervalo

ilgis; Gaunama prognozė atsižvelgiant į sezono koeficientą:

Ft+1= At*SKp (7)

3.8. Prognozavimo paklaidų įvertinimas

Paklaidų skaičiavimas laiko eilutėse leidžia nustatyti prognozavimo metodo kokybę ir palyginti skirtingus metodus. Skaičiuojamos keturių tipų paklaidos :

n

n

t tFtAMAD

∑=

−= 1 ;

n

n

t tFtAMSE

∑=

−= 1

2)(;

tA

n

t tFtA

nMPE

∑=

−=

1100

; ∑=

−=

n

t tAtFtA

nMAPE

1100

;

čia At – yra faktinė reikšmė, Ft – prognozuojama reikšmė, n – stebėjimų skaičius; MAD – vidurkio absoliutinis nuokrypis MAD (Mean Absoliute Deviation) skaičiuojama vidurkio absoliutinė

paklaida laiko eilutėje; MSE – vidurkio kvadratinė paklaida MSE (Mean Squared Error) šio paklaidos skaičiavimo metodo pranašumas

yra tas, kad jis gerai įvertina dideles paklaidas. Šį metodą tikslinga pasirinkti skirtingų prognozavimo metodų palyginimui ir optimizavimui;

MPE – vidurkio santykinė paklaida MPE (Mean Percentage Error) ši paklaida duoda reikšmes, kurias lengva analizuoti ir lyginti su prieš tai jau minėtomis paklaidomis;

MAPE – vidurkio absoliutinė procentinė paklaida MAPE (Mean Absolute Percentage Error). Ši paklaida skiriasi nuo prieš tai minėtos tik tuo, kad skaičiuojama santykinės paklaidos absoliutinė reikšmė.

Prognozavime didelis dėmesys turi būti skiriamas modelių teoriniam ir eksperimentiniam palyginimui, taip pat ir modelio tinkamumo prognozavimo uždaviniams spręsti nustatymui. Renkantis vieną iš nurodytų paklaidų, patogiausia yra naudoti vidurkio santykinę paklaidą, nes ši paklaida duoda reikšmes, kurias lengva analizuoti ir lyginti. Ši paklaida ir buvo pasirinkta vertinant rezultatus bei priimant galutinį sprendimą. Galimi įvairūs duomenų paklaidos įvertinimui surinkimo būdai:

• Prognozuoti vieną žingsnį į priekį; • Prognozuoti n žingsnių į priekį, neperskaičiuojant koeficientų, kiekvienam žingsnyje priimant, jog turime

realių duomenų seką iki pat prognozuojamo momento;

– 517 –


• Prognozuojant n žingsnių į priekį ir kiekvieną kartą perskaičiuojant koeficientus; • Prognozuoti n žingsnių į priekį, visuose n žingsnių, išskyrus pirmąjį, kaip dalį duomenų imant ne realius, bet prognozuotus duomenis.

Visi šie prognozavimo paklaidos įvertinimo būdai nėra lygiaverčiai. Šiame darbe naudojama vidurkio santykinė paklaida ir kas tam tikrą laiko intervalą atliekamas prognozavimo algoritmo parametrų koregavimas. Atsižvelgiant į paklaidos reikšmes, kiekvienai prekių rūšiai yra parenkamas geriausias (duodantis mažiausią vidurkio santykinę paklaidą) prognozavimo algoritmas; vėliau, stebint prognozavimo paklaidas, daromos algoritmų parametrų korekcijos.

4. Užsakymų informacinės sistemos realizacijos ypatumai 4.1. Sistemos panaudojimo atvejų modelis

Užsakymų informacinė sistema yra pritaikyta dviejų tipų vartotojams: metodų analitikui ir vadybininkui. Kiekvienas iš šių vartotojų naudojasi tik jam priskirtomis sistemos atliekamomis funkcijomis (panaudojimo atvejais). Metodų analitikas tvarko algoritmų informaciją, priskiria prekėms prognozavimo metodus, vadybininkas sudaro prekių užsakymus (1 pav.).

IS

Prisijungti

Tvarkyti prekiu informacija

Skaiciuoti uzsakymus

Prognozuoti

<<include>>

Perziureti prognozavimo rezultatusVadybininkas

Sudaryti uzsakymus

Tvarkyti algoritmu informacija

Modeliu administratorius Priskirti prognozavimo algoritma

1 pav. Panaudojimo atvejų diagrama

4.2. Prognozavimo algoritmų realizacija informacinėje sistemoje

Kaip jau buvo minėta, informacinės sistemos prognozavimo komponente adaptuoti keturi prognozavimo metodai: slenkančio vidurkio; paprasto eksponentinio glodinimo; dvigubo eksponentinio glodinimo; įvairialypio sezoninio. Pasirinkti metodai turi skirtingas taikymo savybes, tai leidžia skirtingoms prekėms pritaikyti tiksliausiai jų paklausą atitinkantį metodą.

Prognozavimo tikslumas, naudojant įvairius algoritmus, skiriasi. Prognozavimo paklaidai skaičiuoti naudojama vidurkio santykinė paklaida. Naudojant bet kurį metodą, reikalingos faktinės reikšmės, kurių pagrindu atliekamas prognozavimas.

– 518 –


Veiksmų seka iliustruojanti prognozės skaičiavimą eksponentinio glodinimo metodu, pateikta 2 paveiksle. Analogiškai yra atliekami ir kitais metodais atliekami prognozių skaičiavimai, skiriasi tik formulių išraiškos.

Skirtingiems metodams prognozes ar koeficientų perskaičiavimo formulės skiriasi: 1. Slenkančio vidurkio metodas – naudojama (1) formulė prognozei apskaičiuoti. 2. Paprasto eksponentinio glodinimo metodas – koeficientai perskaičiuojami pagal (3) formulę, o prognozė

pagal (2). 3. Dvigubo eksponentinio glodinimo metodas – koeficientai perskaičiuojami pagal (3) ir (5) formules, o

prognozė pagal (4). 4. Įvairialypis sezoninis metodas – koeficientai skaičiuojami pagal (6) formulę, o prognozė pagal (7) formulę. Visiems metodams yra skaičiuojama vidurkio santykinė paklaida.

Naudoti duomenis is priskirto intervalo

Perskaiciuoti koeficientus pagal formule

Skaiciuoti prognnoze pagal formule

Skaiciuoti paklaida pagal formule

Paklaidatenkina

Praplesti intervala

[T]

[F]

2 pav. Prognozės skaičiavimo algoritmas

4.3. Kompiuterizuoto užsakymų skaičiavimo proceso ir duomenų modelis

Siūloma užsakymų informacinė sistema su paklausos prognozavimu yra pritaikyta dviejų tipų vartotojams: vadybininkas turi galimybę peržiūrėti esamus prognozavimo algoritmus, juos palyginti ir atlikti grafinę analizę bei prognozavimą, inicijuoti algoritmų koeficientų perskaičiavimą; administratorius turi visas vartotojo teises bei algoritmų įvedimo, koregavimo teises; gali įvedinėti, redaguoti naujų prekių sąrašus ir įvestoms prekėms priskirti prognozavimo algoritmus, jų koeficientus bei juos redaguoti.

Ši sistema palengvina ir pagreitina prekių užsakymo procesą. Ji leidžia atlikti tikslesnę prekių analizę ir prognozuoti tikslesnius prekių užsakymo kiekius tam tikram laiko intervalui, kas sąlygoja įmonės apyvartinių lėšų mažėjimą. Prognozavimo algoritmų parinkimo ir adaptavimo procesas parodytas 3 paveiksle.

Įmonės kataloge atsiradus naujai prekei, nustatomas jos prognozavimo intervalas ir parenkamas prognozavimo algoritmas. Pradinis pasirinkimas gali būti labai netikslus, nes gali nebūti naujos prekės paklausos duomenų, tačiau laikui bėgant duomenys kaupiami ir algoritmų parametrai perskaičiuojami. Sistemoje numatytas automatinis algoritmo parinkimas, tačiau tą gali atlikti ir verslo analitikas, jei pagal turimus duomenis jis gali nuspėti, kuris algoritmas geriausiai tinka. Sistema įvertina prognozavimo paklaidą ir, jei ji tenkina nustatytas ribas, priskiria algoritmą prekės paklausai prognozuoti; jei ne, ji peržiūri visus galimus algoritmus ir išrenka tą algoritmą, kurio paklaida mažiausia. Analitikas gali stebėti sistemos atliktus skaičiavimus ir patvirtinti parinktą variantą arba parinkti kitą.

– 519 –


[ F ]

Nustatyti prognozavimo parametrus (prekė, laiko intervalas)

Nustatyti prognozavimo algoritmo parametrus

Pasirinkti prognozavimo algoritmą

Įvertinti prognozavimo paklaidą

Paklaida tenkina?

Priskirti algoritmą prekei

[ T ]

[ F ]

[ F ]

Visi algoritmai peržiūrėti?

Išrinkti algoritmą su minimalia paklaida

[ T ]

Skaičiuoti prekės užsakymą

Įvertinti prognozavimo paklaidą

Paklaida tenkina?

Perskaičiuoti algoritmo ir prognozavimo

parametrus

[ F ]

Paklaida tenkina? [ T ]

Laikas skaičiuotiužsakymą

Laikas skaičiuotialg.parametrus

Nauja prekė

3 pav. Prognozavimo algoritmų parinkimo ir patikslinimo procesas prekybos informacinėje sistemoje

Atėjus laikui skaičiuoti tiekimo užsakymus, sistema naudoja priskirtus algoritmus, nereikalaudama vadybininko įsikišimo, tačiau jis taip pat gali stebėti skaičiavimų rezultatus ir, reikalui esant, perskaičiuoti algoritmo parametrus arba kreiptis į analitiką, kad peržiūrėtų prognozavimo algoritmą. Sistema periodiškai perskaičiuoja algoritmų parametrus, įvertindama naujus sukauptus prekės paklausos duomenis. Informacinės sistemos loginė architektūra pateikta 4 paveiksle.

Dalykinės srities modelyje yra pavaizduotas kuriamos sistemos duomenų modelis. Projektuojant sistemą buvo prieita prie tokios duomenų modelio struktūros, kuris susideda iš šių esybių: Prekes, Pirkimai, Pardavimai, Metodai, Koeficientai, Akcijos, PrekesMetodas. Detali dalykinės srities modelio diagrama pateikta 5 paveiksle.

Prognozavimas

Metodo parinkimas

Metodo adaptavimas

Prognozių ir paklaidų skaičiavimas

Užsakymų sudarymas

Vadybininko sąsaja

Metodų analitiko sąsaja

Prekybos sistemos dalykinės srities modelis

Prognozavimo dalykinės srities modelis

4 pav. Prekybos sistemos loginė architektūra

4.4. Programinių komponentų realizacija

Užsakymų informacinės sistemos su prognozavimo komponentu programinė realizacija sudaryta iš šių komponentų:

Formų - Modeliuanalitikosasaja.exe, MetodoParinkimas.exe, UzsakymuSudarymas.exe, VadybininkoSasaja.exe;

Objektų bibliotekos - Prognozavimas.dll; Prekybos sistemos duomenų bazės. Detali programinių komponentų ir jų tarpusavio ryšių diagrama pateikta 6 paveiksle.

– 520 –


-PrekesVardas : Char-PrekeID : Char-PrekesKodas : Char-Kaina : Char

Prekes-PirkimoID : Char-Kiekis : Char-PrekeID : Char-Prognoze : Char

Pirkimai

-PardavimoID : Char-Kiekis : float-Data : Date-PrekeID : Char-TrendVid : float-VidA : float

Pardavimai

-MetodoPavadinimas : Char-MetodoID : Char

Metodai

-MetodoID : Char-PrekeID : Char-Paklaida : float-Periodas : float-Intervalas : float-alfa : float-beta : float

PrekesMetodas

-data1 : Date-data2 : Date-koef : float-PrekesID : char

Akcijos-PrekesID : char-data1 : char-data2 : char-koef : float

Koeficientai

0..1 1

0..n

1

1

0..n

1

0..n

1 0..n

1

0..n

5 pav. Dalykinės srities modelis

VadybininkoSasaja.exe <<Vartotojo sąsaja>>

ModeliuAnalitikoSasaja.exe <<Vartotojo sąsaja>>

Prognozavimas.dll

UžsakymuSudarymas.exe<<EXE>>

Prekybos sistemos duomenų bazė

MetodoParinkimas.exe

6 pav. Prekybos sistemos programinių komponentų architektūra

<<Form>> Kliento PK

<<Server>> Taikomuju programu serveris

<<ODBC drivers>>

<<DB Server>> MS SQL SERVER

Vyykdomi procesai:Prognozavimas, Metodo parinkimas,Užsakymų sudarymas

*

*

<<TCP/IP>>

*

*

<<ODBC>>

*

*

<<ODBC>>

7 pav. Sistemos paskirstymo diagrama

– 521 –


Sistema buvo realizuota naudojant MS Visual Studio .NET ir MS SQL Server technologijas. Programinės įrangos paskirstymo vaizdas pateiktas 7 paveiksle.

Priklausomai nuo to, kiek vartotojų naudosis sistema yra dvi diegimo ir konfigūravimo galimybės: klientinė ir serverinė dalys įdiegta tame pačiame kompiuteryje (6is atvejis galėtu būti taikomas, kai sistema naudojasi ne daugiau negu 2 vartotojai), ir kitas – kai klientinė ir serverinė dalys įdiegtos atskiruose kompiuteriuose. Šis atvejis taikomas, kai sistema naudojasi daugiau nei 2 vartotojai, atsižvelgiant į kitas technines specifikacijas pavyzdžiui, tinklo pralaidumas, naudojamų kompiuterių techninės galimybės.

Sukurta informacinė sistema gana tiksliai prognozuoja reikiamus prekių kiekius pagal joms parinktus algoritmus. Vadybininkas gali stebėti prognozavimo paklaidas ir perskaičiuoti algoritmų koeficientus, jei paklaida didėja, arba inicijuoti algoritmo metodo pakeitimą, kurį atlieką modelių administratorius (analitikas), jei paklausos pobūdis pasikeičia.

Kadangi prekybos įmonėse vykdomos akcijos daro įtaką prognozavimo rezultatams, sistemoje realizuota galimybė užfiksuoti atitinkamas akcijas su atitinkamu koeficientu tam tikrame laiko intervale, ir jos bus įvertintos atliekant skaičiavimus.

Pasirinkus norimą prognozuoti prekę ir inicijavus prognozės skaičiavimą, programa pateikia skaičiavimo rezultatus, kuriais remiantis yra sudaromi užsakymai. Kad analizė būtų vaizdesnė, rezultatus galima peržiūrėti grafiniam pavidale. Naudojantis grafinės analizės funkcija, lengviau nustatyti paklausos kitimo tendencijas bei numatyti prognozavimo elgsenos ypatybes. Sistemos pateikiamos grafinės analizės pavyzdys pateiktas 8 paveiksle.

Kiekvienai prekybinės įmonės sąrašuose esančiai prekei yra priskirtas tiksliausiai jos paklausą prognozuojantis algoritmas. Prognozavimo metodai konkrečiai prekei priskiriami remiantis testavimų rezultatais. Lemiamas veiksnys priimant sprendimą yra prognozavimo paklaida. Prekei priskiriamas metodas, kurio prognozavimo paklaida testavimo metu yra mažiausia.

Paklaidų kitimo grafikas pagal metodus

0

2

4

6

8

10

12

Pienas Alus Mandarinai Ledai

Pakl

aido

s, %

Kintančio vidurkio metodasPaprasto eksponentinio glodinimo metodasDvigubo eksponentinio glodinimo metodasĮvairialypis sezoninis metodas

8 pav. Prognozavimo paklaidų kitimo grafikas

Kaip matyti iš 10 paveikslo, skirtingoms prekėms su įvairiu paklausos pobūdžiu tinka skirtingi metodai, kuriuos taikant gaunama mažiausia prognozavimo paklaida. Jei paklausos pobūdis pasikeičia ir paklaida išauga, sistemoje realizuota galimybė pakeisti prognozavimo algoritmą.

Testuojant prekės „Pienas“ pardavimo duomenis, tinkamiausias pasirodė kintančio vidurkio metodas. Šis metodas gali būti taikomas tuo atveju, kai prekės paklausa yra tolygi ir žymiai nekinta ilgalaikiame intervale. Toks metodas geriausiai tinka kasdieninio vartojimo prekėms, kurių paklausa kiekvieną dieną yra stabili.

Prekės „Alus“ paklausos pobūdį geriausiai atitinka paprasto eksponentinio glodinimo metodas. Štai kaip atrodo prekės „Alus“ prognozių ir faktinių reikšmių grafikas (10 pav.).

Prekei, kurios paklausa turi trendą, reikia taikyti dvigubą eksponentinį metodą, nes kiti metodai eliminuoja trendą. Kaip matyti iš 10 paveikslo, prekei „Mandarinai“ yra taikomas dvigubo eksponentinio glodinimo metodas. Prekės „Mandarinai“ paskutinės 2004 metų savaitės prognozių ir faktinių reikšmių grafikas pavaizduotas 11 paveiksle.

Kai kurioms prekėms labai ryškiai skiriasi skirtingų sezonų paklausa. Pavyzdžiui, sezoninis metodas geriausiai atitinka prekės „Ledai“ paklausą. Sezoninio metodo ypatumai gerai atsispindi 12 paveiksle, kur pavaizduota prekės „Ledai“ paklausa skirtingais metų ketvirčiais (sezonais).

– 522 –


9 pav. Prekės „Pienas“ duomenys ir prognozė, skaičiuota kintančio vidurkio metodu

10 pav. Prekės „Alus“ duomenys ir prognozė, skaičiuota eksponentinio glodinimo metodu

11 pav. Dvigubo eksponentinio glodinimo metodo su prekės „Mandarinai“ duomenimis pavyzdys

– 523 –


– 524 –

12 pav. Prekės „Ledai“ paklausos svyravimai skirtingais metų sezonais

5. Išvados

Prognozavimas gali pagerinti įmonių veiklos rezultatus, ypatingai prekybos įmonėse su didele prekių įvairove ir nuolat kintančia paklausa. Esami prognozavimo paketai gerai tinka analitikams, tačiau jie nepritaikyti kasdieninei įmonių veiklai, pavyzdžiui, tiekimo užsakymų skaičiavimui, įvertinant paklausą. Todėl siūlomas prekybos informacinės sistemos modelis su prognozavimo komponentu, kuris palengvintų tokių įmonių vadybininkų darbą atsargų valdymo srityje.

Prekybos informacinės sistemos daugiamatės paklausos prognozavimo komponentas naudoja rinkinį prognozavimo algoritmų, iš kurių kiekvienam prekių tipui parenkamas tinkamas algoritmas, duodantis mažiausią prognozavimo paklaidą. Pradiniai algoritmų parametrai nustatomi pagal turimas faktines reikšmes, vėliau, kaupiantis duomenims, parametrų įvertinimai periodiškai koreguojami, naudojant nustatytą kiekį paklausos duomenų reikšmių..

Sistemą galima naudoti automatiniam režime, kai vadybininkas tik stebi sistemos atlikto prognozavimo paklaidas, tačiau reikalui esant jis gali inicijuoti algoritmų parametrų perskaičiavimą arba kreiptis į analitiką dėl parinkto algoritmo pakeitimo. Algoritmų rinkinys apima įvairius paklausos modelius: slankiojančio vidurkio, sezoninius, su trūkiais, su trendu. Paklaidos skaičiavimui naudojama absoliutinė santykinė paklaida.

Sukurtą informacinę sistemą galima pritaikyti įvairiems paklausos kitimo procesams, įvesti naujus prognozavimo metodus, skaičiuoti jų paklaidas, koreguoti koeficientus, taikyti akcijas, parinkti skirtingoms prekėms tinkamus prognozavimo algoritmus, nuolat efektyviai vykdant reikalingų užsakyti prekių kiekio prognozavimą.

Pagrindinis darbo privalumas yra teorinių prognozavimo metodų pritaikymas prekybos įmonių paklausai prognozuoti, integruojant prognozavimą su kasdienine vadybininkų veikla. Tokios savybės trūksta esamiems prognozavimo įrankiams, kurie veikia kaip atskiri paketai.

Literatūros sąrašas [1] Captain Toolbox. Lancaster University. [Interaktyvus] 2003 [Žiūrėta 2003 12 15] Prieiga per internetą:

http://www.es.lancs.ac.uk/cres/captain/overview.html. [2] Rūta Šileikienė. Duomenų gavyba – naujas informacinių sistemų procesas. Žurnalas „Informacinės

technologijos“. 2000m. pavasaris (11), 24 psl. [3] Introduction to Time Series Models (ARFIMA) [Interaktyvus]. 2004 [Žiūrėta 2004 02 10]. Prieiga per internetą :

http://www.pcgive.com/volume3.html ]. [4] The ARIMA Procedure [Interaktyvus]2004 [Žiūrėta 2004 02 15] Prieiga per internetą :

http://www.css.orst.edu/sasdocs/books/ets/chap7/sect1.htm.]. [5] Armstrong J.S. Diffusion of Forecasting Principles by Software [Interaktyvus]. 2004 [Žiūrėta 2004 02 20.] Prieiga per

internetą: http://www-marketing.wharton.upenn.edu/forecast/softwareprinciplessumary.html] [6] Introduction to Time Series Analysis [Interaktyvus] 2004 [Žiūrėta 2004 03 08] Prieiga per internetą:

http://www.itl.nist.gov/div898/handbook/pmc/pmc.htm]

http://www.pcgive.com/volume3.html

http://www-marketing.wharton.upenn.edu/forecast/softwareprinciplessumary.html

http://www.itl.nist.gov/div898/handbook/pmc/pmc.htm

http://www.itl.nist.gov/div898/handbook/pmc/pmc.htm

VERSLO PROCESŲ MODELIAVIMO KALBŲ ANALIZĖ IR SPECIFIKAVIMO PRIEMONIŲ SUKŪRIMAS

Inga Pašilskytė, doc. Lina Nemuraitė Kauno Technologijos universitetas, Informacijos sistemų katedra

Siekiant, kad verslo modeliavimo, projektavimo, analizavimo procesas būtų suprantamas tiek informacinių technologijų specialistams, tiek verslo dalyviams, vis dažniau naudojamos grafinio modeliavimo kalbos. Grafinio modeliavimo privalumai

– standartiniai žymėjimai, vieninga terminologija, intuityvus supratimas. Kadangi atvaizduoti verslo procesą visuose jo kompiuterizavimo etapuose vienos kalbos nepakanka, buvo analizuojamos trys veiklos procesų modeliavimo kalbos: UML 2.0, BPMN bei BPEL4WS, gilinantis į jų galimybes elektroninio verslo procesams modeliuoti bei vykdyti. Išsamiam verslo

proceso modeliui sudaryti UML 2.0 siūloma papildyti BPMN elementais, sukuriant tam skirtus stereotipus. Taip pat iškeliama idėja išplėsti grafinę proceso apibrėžimo sąsają, kurioje proceso taisyklės būtų susiejamos su dalykinės srities

objektais.

1. Įvadas Atsiradus verslo modeliavimo standartizavimo poreikiui, sukurta daug įvairių modeliavimo standartų,

kalbų, kurios akcentuoja skirtingas verslo modelių savybes [1] ir nėra nė vienos, kuri tenkintų visus verslo modeliavimo poreikius. Be to, daugelis kalbų yra tekstinio pavidalo ir verslo ekspertams neprieinamos. Nuolat keičiantis reikalavimams, modeliavimo metodika turi prie jų prisitaikyti. Viena iš plačiausiai naudojamų grafinio modeliavimo kalbų yra UML, kuri nuolat tobulinama. Naujausia UML versija yra 2.0 [2], kuri turi išplėstas galimybės veiklai modeliuoti.

Plačias verslo modeliavimo galimybes palaiko naujas verslo modeliavimo standartas BPMN (Business process modelling notation) [3][4], kuris palengviną projektavimo kelią nuo projektavimo iki realizavimo, ir projektavimo procesą padaro prieinamą ir aiškų visiems verslo kūrimo dalyviams.

UML 2.0 versijos veiklos diagramos savo galimybėmis tolygios BPMN, tačiau neturi tokios išbaigtos stereotipų aibės. Tačiau UML turi tų privalumų, kad ji leidžia modeliuoti ne tik verslo procesus, bet ir duomenis bei paslaugas, kurios reikalingos verslo procesams įgyvendinti. Šaime darbe yra siųloma UML 2.0 papildyti BPMN stereotipais, taip modelį priartinant prie realizacijos. BPMN siųloma plati stereotipų aibė supaprastina modeliavimo procesą, padaro jį aikesnį ir lengvesnį.

Siekiant grafinę proceso apibrėžimo sąsają sieti su dalykinės srities objektais buvo pasirinkta BPEL4WS(Business Process Execution Language for Web Services)[5 ] vykdomoji kalba. Šios vykdomosios kalbos pagalba UML 2.0 BPMN stereotipais papildyti elementai atvaizduojami į BPEL4WS taip susiejant dalykinę sritį su grafiniais veiklos procesais. Analizuojant transformuotą kodą sudaromi šablonai vartotojo procesui palengvinti. Pagal sudarytus šablonus sudaromas išbaigtas struktūrinis veiklos proceso metamodelis.

Šaime darbe trumpai analizuojamos UML 2.0 ir BPMN. Šių notacijų pranašumai ir skirtumai parodomi atvaizduojant to paties proceso modelį UML 2.0 bei UML 2.0 papildžius BPMN stereotipai. Straipsnio pabaigoje trumpai analizuojamas transformavimas į vykdomąją kalbą BPEL4WS ir sudaromas struktūrinis veiklos proceso metamodelis. Modeliavimas atliktas įrankiais Enterprise Architect 4.0[6] bei Magic Draw 7.2[7] . Enterprise Architect 4.0 buvo pasirinktas, todėl, kad jis palaiko UML 2.0, juo patogu braižyti šio standarto modelius. O Magic Draw 7.2 buvo pasirinktas, todėl, kad šiuo įrankiu patogu įvesti naujus stereotipus. Šis įrankis buvo naudojamas UML 2.0 modeliams papildytiems BPMN stereotipais braižyti.

2. Trumpa UML 2.0 ir BPMN notacijų analizė

2.1. UML UML modeliavimo kalba gana paplitusi, lengvai išmokstama ir patogi realizavimui, specifikavimui,

dokumentavimui. UML modeliavimo kalbai būdinga diagramų įvairovė, todėl ši modeliavimo kalba labai lanksti ir patogi įvairiam projektavimui. UML modeliavimo kalboje diagramos skirstomos į tris kategorijas: statines, dinamines bei organizavimo, valdymo. Ši modeliavimo kalba nuolat tobulina ir papildoma. Nauja modeliavimo kalbos UML, versija UML 2.0. UML 2.0 suteikia galimybę taip suprojektuoti sistemą, kad ji būtų labai artima realizuojamai sistemai. Šis standartas papildytas elementais, skirtais projektuoti verslo modeliams (duomenų saugykla, daugybė taškų tipų, veiklos suskaidymas, pertraukimas ir kt.). UML 2.0 yra universali kalba, ir verslo procesų modeliavimas yra tik viena jos naudojimo krypčių. Kadangi vienas iš darbo tikslų yra papildyti šią notaciją naujais veiklos procesų stereotipais, dėmesys koncentruojamas į UML 2.0 veiklos diagramas.

Veiklos diagramos yra trijų lygių (trečio lygio šiame darbe nenagrinėjamos): Pirmo lygio diagrama abstrakčiai vaizduoja veiklą.

– 525 –

I. Pašilskytė, L. Nemuraitė

Antro lygio diagramos gali būti dviejų tipų : tarpinės veiklos (IntermediateActivities) diagramos aprašo veiklos grafus, veiklos valdymo bei duomenų srautus; struktūrinės veiklos (StructuredActivities) leidžia aprašyti darinius, panašius į naudojamus programose; trečio lygio diagramose aprašomos tokios konstrukcijos kaip lanko svoris, srautų suskaidymas ir t.t

2.2. Veiklos procesų modeliavimo notacija BPMN BPMN yra naujas modeliavimo standartas. Jis suteikia galimybę suprasti vidinius verslo procesus

grafiškai juos atvaizduojant ir suteikia galimybę šiuos procesus standartizuoti. BPMN procesų modeliavimo pagrindas ir metodologija. Ji suteikia galimybę žmonėms iš skirtingų įmonių suprasti vieni kitų verslo procesus, sujungti verslus, ar juos suskaidyti į skirtingus. BPMN standartas padeda suprasti visiškai skirtingų verslo procesų gyvavimo ciklą nuo sukūrimo iki vystymo, realizavimo, vykdymo, analizavimo. Taip pat šis standartas suteikia galimybę suprasti bendradarbiavimą ir transakcijas tarp organizacijų. BPMN standartas leidžia numatyti galimas gyvavimo ciklo eigos išimtis, klaidas. Suteikia galimybę naudoti verslo taisykles, ciklus, sprendimų taškus, trigerius.

BPMN yra vienintelio tipo diagrama, kurią galima naudoti įvairiais pavidalais: Vidinių verslo procesų diagramos( Private (internal) business processes). Tai vidinis įmonės darbų

srautų modelis (orkestruotė). Jeigu projektuojamos vidinės verslo diagramos naudojant juostas, tai vidinė diagrama negali išeiti už jos ribų. Jeigu dvi juostos sujungtos, tai reiškia, kad ne jų atskiri elementai, o vidinės diagramos siejasi viena su kita.

Sąveikų procesų diagramos (Abstract (public) processes). Jos rodo, kaip sąveikauja skirtingi verslo procesai (choreografija). Į diagramas įtraukiami tik tie procesai kurie veikia vidinių verslo procesų išorėje.

Bendradarbiavimo proceso diagramos (Collaboration (global) processes). Šios diagramos parodo globalius procesus. Šios diagramos gali būti vaizduojamos be juostų. Veiksmai priklausantys tam pačiam vidiniam procesui šiose diagramose gali būti susieti.

Naudojant BPMN verslo modeliavimo diagramos taip pat gali būti kelių tipų: • Aukšto lygio vidinių procesų veiklos. • Detalizuotas vidinis verslo procesas. • Senas verslo procesas. • Naujas verslo procesas. • Detalizuotas verslo procesas su sąsajomis, bei išoriniais verslo dalyviais. • Du ar daugiau sąveikaujantys verslo procesai. • Detalizuoto vidinio proceso ryšys su sąsajos procesu. • Detalizuoto vidinio proceso ryšys su bendradarbiavimo procesu. • Sąsajos ir bendradarbiavimo procesas. • Du ar daugiau verslo procesų sąveikaujantys su sąsaja • Du ar daugiau verslo procesų sąveikaujantys su bendradarbiavimu. • Du ar daugiau verslo procesų sąveikaujantys su sąsajų ir bendradarbiavimo procesais. UML 2.0 daugelis elementų atitinka BPMN notaciją, kaip pavyzdžiui: pradžios pabaigos taškas,

sprendimų mazgas, išsišakojimas, veiklos pertraukimas, ciklas, jungimų mazgas ir t.t. Bet BPMN kalba turi daugiau elementų skirtų dar labiau supaprastinti verslo projektavimo procesą. Todėl siūloma UML 2.0 papildyti kai kuriais BPMN elementais.

2.3. BPMN notacijos verslo modeliavimo elementai, kuriais siūloma papildyti UML 2.0 notaciją Trigeriai Tarpinis įvykis (Event).

Tarpinis įvykis įvyksta tik po to kai procesas prasidėjęs. Jis turi įtakos proceso eigai, bet nei pradėti, nei nutraukti proceso negali.

Pranešimo trigeriai (Message triggers).

Pranešimo trigeriai gali būti pradžios, tarpiniai ir pabaigos. Pradžios trigeris paleidžia proceso pradžią, tarpinis trigeris tęsia procesą, o pabaigos trigeris veikia jei buvo tarpinis trigeris, ir jis praneša apie proceso pabaigą.

Laiko trigeriai (Timer trigger).

Laiko trigeriai gali būti tik pradžios ir tarpiniai. Jie užduoda tam tikrą laiko ciklą, kurio neviršijus procesas bus tęsiamas.

Taisyklių trigeriai (Rule trigger).

Taisyklių trigeriai gali būti tik pradžios arba tarpiniai. Procesas tęsiamas jei užduota taisyklė yra tenkinama.

– 526 –

Verslo procesų modeliavimo kalbų analizė ir specifikavimo priemonių sukūrimas

Ryšio trigeriai (Link trigger).

Ryšio trigeriai gali būti pradžios, tarpiniai ir pabaigos. Ryšio trigeriai naudojami jei procesas gali prasidėti tik pasibaigus kitam procesui, ar pasiekus tarpinę būseną ir t.t.

Išsišakojantis trigeris (Multiple trrigers).

Išsišakojantis trigeris gali būti pradžios, tarpinis ir pabaigos. Išsišakojantys trigeriai naudojami tada kai gali būti keli įvykio variantai. Procesas paleidžiamas(tęsiamas, baigiamas) kai kuris nors viena iš galimų alternatyvų tenkinama.

Klaidos trigeris (Exception trriger).

Klaidos trigeris gali būti tik tarpinis arba pabaigos. Tarpinis trigeris užfiksuoja išimtį arba klaidą proceso eigoje, O pabaigos išimties trigeris sustabdo procesą .

Kompensavimas trigeris (Compensation trigger).

Kompensavimo trigeris gali būti tik tarpinis arba pabaigos. Šis trigeris naudojamas kai procesą prireikus galima grąžinti atgal.

Atšaukimo trigeris (Cancel trriger ).

Atšaukimo trigeris gali būti tarpinis ir pabaigos. Jis naudojamas tik tuomet, kai procesas yra nutraukiamas savo noru.

Priverstinės pabaigos trigeris (Terminate trriger).

Priverstinės pabaigos trigeris gali būti tik pabaigos. Jis naudojamas tuomet kai įvyko klaida ir dėl to procesas nutraukiamas priverstiniu būdu.

Sprendimų taškai (Gateway control type) – kontroliuoja išsiskiriančius sekų srautus. Jie apibrėžia išskaidymą bei sujungimą. Išimtinis (Exclusive) sprendimų taškas. Duomenimis pagrįstas (Data-based).

Įvykiais pagrįstas(Event-based).

Kai reikalinga srautų kontrolė BPMN naudojamas sprendimų taškas. Atėjus srautui, tikrinama, kuri sąlyga yra išpildoma. Ta atšaka, kurioje sąlyga yra išpildoma tęsiamas srautas. Tarp visų alternatyvių srautų gali būti tik vienas kuris užbaigs srautų eigą Šis sprendimas ypatingas tuo , kad lygiagretus išsišakojimas grįstas įvykiais atsirandančiais procese. Šis taškas atlieka papildomą sekų kontrolę. Po šio sprendimų taško seka tarpiniai įvykiai. Kai įvykis atvyksta tikrinama, kuris kelias tenkinamas, tuo keliu srautas siunčiamas toliau. Kiti įvykiai nepraleidžiami, jie gali būti naudojami kaip taimeriai.

Apimantis (Inclusive) sprendimų taškas(or).

Šis taškas priėmęs ateinantį srautą išskaido į tiek lygiagrečių kelių , kiek sąlygų yra tenkinama. Nuo išplėtimų taško skiriasi tuo, kad galima pasirinkti ne vieną, o nulį ir daugiau išeinančių alternatyvių srautų. Suteikiama galimybė nesirinkti nė vienos alternatyvos.

Sudėtinis (Complex) sprendimų taškas.

Sudėtinis sprendimų taškas BPMN naudojamas , kad būtų galima apibrėžti kiek ateinančiu srautų gali būti tęsiami. Likę srautai užblokuojami sprendimų taške.

Lygiagretus (Parallel) sprendimų taškas.

Lygiagretus išskaidymas – tai vieno kelio išskaidymas į du ir daugiau kelių einančius lygiagrečiai

Ciklai (Loops) – ciklai gali būti dviejų rūšių : Veiksmų ciklai (Activity looping).

– 527 –


Veiksmų cikluose užduotys ir procesai bus sustabdyti, jei šie įvykiai įvyks tik vieną kartą.

Sekų ciklai (Sequence flow looping).

Sekų ciklai sudaromi sekos srautą jungiant su prieš tai einančiais objektais. Sekų ciklai naudojami ne tada kai tam tikras įvykis kartojamas keltą kartų, o kai tam tikra įvykių seka kartojama tam tikrą kiekį kartų.

3. Modeliai naudojant UML 2.0 bei BPMN notacijas Modeliavimui buvo pasirinkta nuotolinio mokymo sistema. Šiame eksperimentiniame modelyje

panaudota daugelis elementų, kuriais siūloma papildyti UML 2.0. Kad vaizdžiai parodyti modelio skirtumus tarp UML 2.0, papildytos BPMN stereotipais, ir BPMN, pateiktos sistemos veiklos diagramos naudojant abi notacijas.

Pirmas modelis – nuotolinės mokymosi sistemos modelis nenaudojant juostų ir konteinerių, bet naudojant anotacijas. Šis diagramos tipas paprastesnis ir aiškesnis. Aiškiai matoma kokią veiklą koks darbuotojas kokio proceso eigoje atlieka. Eksperimentinis modelis pateiktas 1 paveiksle.

Antras modelis – nuotolinės mokymosi sistemos modelis realizuotas UML 2.0, papildyta BPMN notacija. Eksperimentinis modelis pateiktas 2 paveiksle.

Eksperimentinio modelio scenarijus: 1ž. Prisijungimas. Vartotojas jungiasi prie sistemos. Užduodamas prisijungimo laikas. Prisijungimo

metu tikrinami ar teisingi vartotojo pateikti duomenys. Jei įvesti duomenys teisingi atliekamas 2 žingsnis. 2 ž. Informacijos peržiūra ir redagavimas. Vartotojui prisijungus tikrinama ar sumokėta už mokslą. Jei

mokesti už mokslą nesumokėtas tuomet galima atlikti tik 2.1 ir 2.2 žingsnį. Jei mokestis sumokėtas galima atlikti 2.2 , 2.3 ir 2.4 žingsnius.

2.1 ž. Mokėjimo už mokslą procesas. Vartotojas gali sumokėti už mokslą pirmų dviejų semestro savaičių bėgyje. 2.2 ž. Informacijos peržiūrėjimo procesas. Jei už mokslą nesumokėta tuomet užduodamas laikas per kurį vartotojas gali peržiūrėti naujienas ir tvarkaraštį. Užduotam laikui pasibaigus vartotojo paklausiama ar jis nori sumokėti už mokslą. Jei vartotojas pageidauja sumokėti už mokslą t, tuomet atliekamas 2.1 žingsnis, jei ne atliekamas 3 žingsnis. 2.3 ž. Mokslų nutraukimo procesas. Jei vartotojas sumokėjęs reikiamus mokesčius mokymosi įstaigai gali nutraukti mokslus 2.3.1 arba paprašyti akademinių atostogų 2.3.2

2.3.1 ž. Prašymas akademinių atostogų. Vartotojas siunčia pranešimą bei prašymo dokumentą dekanui apie akademines atostogas. Dekanas atsiunčia patvirtinimo dokumentą ir vartotojo mokslas laikinai sustabdomas, atliekamas 3 žingsnis. 2.3.2 ž. Prašymas nutraukti mokslus. Vartotojas siunčia pranešimą bei prašymo dokumentą dekanui apie mokslo nutraukimą. Dekanas atsiunčia patvirtinimo dokumentą ir vartotojo mokslas sustabdomas atliekamas 3 žingsnis.

2.4 ž. Mokymosi ir atsiskaitymų procesas. Mokymosi atsiskaitymo procesas susideda iš semestro darbų atsiskaitymo 2.4.1, Sesijos 2.4.2 ir video konferencijos su dėstytojais 2.4.3. Mokymosi ir atsiskaitymų trukmė - semestro laikas. Atlikus reikiamas operacijas ir panorėjus atsijungti nuo sistemos atliekamas 3 žingsnis.

2.4.1 ž. Semestro darbų atsiskaitymas. Semestro darbų atsiskaitymas susideda iš atsiskaitymų ciklo bei darbų atlikimo ir sudėjimo ciklo. Darbai ir atsiskaitymai negalimi jei neparsiųsta reikiama medžiaga. 2.4.2 ž. Sesija. Savaitę iki sesijos pradžios galima redaguoti sesijos tvarkaraštį. Sesijos metu vyksta egzaminų ir rezultatų registravimo ciklas. Esant neigiamiems rezultatams galimas kompensavimo ciklas, kurio metu pakartotinai laiko egzaminai ir registruojami rezultatai. 2.4.3 ž. Video konferencija su dėstytojais. Video konferencijos metu galima klausyti paskaitas, bendrauti su dėstytojais ir t.t. abiem pusėms patogiu laiku.

3 ž. Atsijungimas. Vartotojai atsijungia savo noru arba atjungiami priverstinai. BPMN yra specializuota verslo procesų vaizdavimui ir turi išsamią tam skirtą notaciją UML 2.0 yra

universali kalba, ir verslo procesų modeliavimas yra tik viena jos naudojimo krypčių. Verslui modeliuoti UML 2.0 turi panašias galimybes, kaip ir BPMN, tačiau UML 2.0 elementų aibė mažesnė.

Kadangi BPMN notacijoje didesnė elementų įvairovė, aiškiau suprantamas modelis. Kaip matome iš pateiktų diagramų vien sprendimo taškų, bei trigerių gausa padeda greičiau įsisavinti visą veiklos procesą. Tuo tarpu UML 2.0 visi sprendimų taškai gali būti realizuoti, bet modelis tuomet tampa sudėtingesnis ir sunkiau suprantamas sprendimo taškų specifiškumas. Pagrindinis BPMN trūkumas – nėra priemonių dalykinei sričiai

– 528 –


vaizduoti. Dokumentai gali būti parodyti tik kaip pastabos. UML veiklos diagramose dokumentai vaizduojami kaip objektai, kurie dalyvauja veiklos procese ir turi įtakos jo eigai. Greta veiklos diagramų UML 2.0 yra išsamus priemonių rinkinys informacinei sistemai projektuoti. Abiejose kalbose galima aprašyti verslo taisykles, tačiau jų apdorojimo priemonių ar rekomendacijų nėra

EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Version EA 4.00 Unregistered Trial Vers



























Mokymosi procesas

[Vartotojas]Prisijungti

Prisijungimo laiko

pabaiga

Prisijungimo duomenys [Sistema]

Tikrinti duomenisDuomenys[Dekanas]

Tvirtinti duomenis Patvirtinimo dokumentas

[Vartotojas]Mokejimo procesas

Pirmos dvi

semestro savaites

[Sistema]Informacijos perziurejimo procesas

[Vartotojas]Perziureti naujienas

[Vartotojas]Perziureti tvarkarasti

Prisijungimo laikas

nesumokejus

[Sistema]Mokslu nutraukimo procesas

[Vartotojas]Paprasyti akademiniu atostogu

[Vartotojas]Nutraukti mokslus

Pranesimas apie akademines atostogas

Pranesimas apie mokslu nutraukima

Akademiniu atostogu prasymo dokumentas

Mokslu nutraukimo prasymo dokumentas

[Dekanas]Tvirtinti akademines atostogas

[Dekanas]Tvirtinti mokslu nutraukima

Akademiniu atostogu

patvirtinimo dokumentas

Mokslu nutraukimo patvirtinimo dokumentas

[Sistema]«Ciklas»

Mokymosi/atsisikaitymo procesas

[Vartotojas]Parsisiusti medziaga

Medziaga [Vartotojas]«Ciklas»

Atsiskaitineti

[Vartotojas]«Ciklas»

Patalpinti atliktus darbusDarbai

[Sistema]«Ciklas»

Skaiciuoti rezultatus

[Sistema]Video konferencija su destytojais

[Vartotojas]Redaguoti sesijos tvarkarasti

Savaite iki

sesijos

[Vartotojas]«Ciklas»

Laikyti egzaminus

Sesijos trukme

Ivertinimai[Dekanas]Tvirtinti semestro darbus

Prileidimo prie egzamino dokumentas

[Sistema]«Ciklas»

Registruoti sesijos rezultatusSesijos rezultatai

Prasyti skolos lapelioSkolos lapelio isdavimo prasymas[Dekanas]

Leisti isduoti skolos lapeliSkolos lapelis

Semestro trukme

Tikrinti ar sumoketa

Visi egzaminai islaikyti

[T]

[N]

[N]

[T]

1 pav. Nuotolines mokymosi sistemos veiklos modelis UML 2.0.

4. BPEL metamodelis Šiame skyriuje 3 pav. pateikiamas struktūrinių veiklos procesų metamodelis, sudarytas sujungiant BPMN,

UML 2.0 ir BPEL4WS kalbų savybes. 3 pav. pateiktas metamodelis buvo sudaromas analizuojant ir papildant anksčiau sudarytus

modelius[8][9]. Metamodelyje vaizduojamas veiklos procesas, kuris susideda iš sudėtinės veiklos, veiklos partnerio bei turi sąsają su kintamųjų aibe. Veiklos procese veikla yra sudėtinė susidedanti iš veiksmo ir įvairių veiklų tipų. Veikla gali būti įvairi: vaizduojama kaip veiklų seka, srautas, sąlyga, sritis, pasirinkimas. Veiksmai priklausomai nuo veiklos proceso elementų gali būti įvairios paskirties: sužadinti, atsakyti, nutraukti ir t.t. Kad atvaizduoti kiekvieną veiksmą reikalinga aprašyti tam veiksmui reikalingus tipus ir elementus. Projektavimo etape reikalingi kintamieji susideda iš įvairių tipų pranešimų. Koks pranešimo tipas toks ir kintamojo tipas. Pranešimams duomenys imami iš duomenų modelio. Kintamieji per pranešimus susieja projektuojamą modelį su dalykine sritimi.

5. Atvaizdavimas Į BPEL4WS Kadangi siekiama išplėsti grafinę proceso apibrėžimo sąsają, kurioje proceso taisyklės būtų susiejamos

su dalykinės srities objektais reikėjo pasirinkti realizacijos kalbą į kuria butų patogu sudarytus modelius transformuoti. Buvo pasirinkta BPEL4WS[10][11] realizacijos kalba. Šioje notacijoje paliekama didelė atvaizdavimo laisvė. Atvaizduojant suprojektuotus modelius į BPEL4WS reikalingi realizavimui duomenys imami iš duomenų modelio sudaryto UML 2.0(dalykinės srities modelis straipsnyje nepateikiamas).

Šiame straipsnyje pateikiamas nedidelis vykdymo į BPEL4WS pavyzdys, kaip pranešimo siuntimas atvaizduojamas į minėtą vykdomąją kalba. Pateikiamas pranešimo atvaizdavimo šablonas ir vieno

– 529 –


pranešimo(pranešimas apie akademines atostogas) paimto 2 pav. (nuotolinės mokymosi sistemos modelis BPMN) pavyzdys.

3 pav. BPEL metamodelis

2.1. Pranešimo vaizdavimo šablonas Pranešimo (taisyklių, ryšio) trigeris atvaizduojamas į gavimo (receive) elementą Siunčiamas pranešimas

sužadina(invoke) kažkokį tai įvykį. Jeigu siunčiamas pranešimas yra vienpusis, tai sužadintas įvykis atvaizduojamas tik į sužadinimo(invoke) elementą. Jei dvipusis, tuomet siunčiamas ataskas(reply) sužadinusiam įvykiui.

Kad atvaizduotume į ankščiau paminėtus elementus, reikia apsirašyti šiuose elementuose naudojamus tipus bei reikalingus elementus. Elementai aprašomi tokia seka:

Apsirašomi visi reikalingi pranešimų tipai. Duomenys pranešimams imami iš UML duomenų modelio: <message name=“Pranešimo pavadinimas“> <part name=”Pranešimo duomenys” type=”xsd:Pranešimo tipas”/> ... <part name=…/> </message>

Aprašoma jungtis(port), per kurią siunčiamas pranešimas. Išėjimo klaidos pranešimų gali ir nebūti, jei pranešimas tik sužadina įvykį: <portType name=”Siunčiamo pranešimo jungties pavadinimas”> <operation name=”Operacijos pavadinimas”> <input message=“pos:Įėjimo pranešimo pavadinimas“/> <output message=“pos:Išėjimo pranešimo pavadinimas“/> <fault name=“Klaidos pranešimas“/> message=”pos:Klaidos pranešimo pavadinimas” </operation> </portType>

Aprašomas partnerių sąsajos tipas: <plnk:partnerLinkType name=“Sąsajos tipo pavadinimas“> <plnk:role name=“Sąsajos pavadinimas“> <plnk:portType name“ Siunčiamo pranešimo jungties pavadinimas“> </plnk:role> </plnk:partnerLinkType>

Aprašomos sąsajos:

– 530 –


<partnerLinks> <partnerLink name=“Sąsajos pavadinimas“> </partnerLinks> partnerLinkType =” Sąsajos tipo pavadinimas” myRole=”Rolės pavadinimas” </partnerLinks>

Aprašomi siuntimo kintamieji (kiekvienam pranešimui sukuriamas kintamasis): <variables> <variable name=”Kintamojo vardas” messageType=”lns:Pranešimo pavadinimas”> </variables>

Visi aukščiau paminėti elementai rašomi tiek kartų kiek yra pranešimų, jungčių ir t.t. Jie užrašomi vienas paskui kita.

Aprašomas pranešimo siuntimo klaidos elementas: <faultHandlers> <catch faultName=“ Klaidos pranešimo pavadinimas“ faultVariable=“Klaidos kintamojo pavadinimas“> <reply partnerLink=“Sąsajos pavadinimas“ portType=” Siunčiamo pranešimo jungties pavadinimas” operation= “Operacijos pavadinimas” variable=“ Kintamojo vardas“ faultName=“Klaidos pranešimas“ </catch> </faultHandlers>

Aprašius visus reikiamus tipus ir elementus užrašomas atvaizdavimas į receive elementą, kuris sužadina kitą procesą(invoke) , ir jei reikia(jei ne siuntimas ne vienpusis) gauna atsaką(reply): <receive partnerLink=“Sąsajos pavadinimas“ portType=“ Siunčiamo pranešimo jungties pavadinimas“ operation=“ Operacijos pavadinimas“ variable=”Kintamojo pavadinimas” </receive> <links> <link name=”Partnerių sąsajos pavadinimas”/> </links> <invoke partnerLink=” Sąsajos pavadinimas” portType=” Gavejo jungties pavadinimas” operation=”Gavėjo operacija” inputVariable=”Gavėjo įėjimo duomenys” outputVariable=”Gavėjo išėjimo duomenys”/> <source linkName=”Partnerių sąsajos pavadinimas”/> </invoke> <reply partnerLink=”Sąsajos pavadinimas” portType=”Siunčiamo pranešimo jungties pavadinimas” operation=”Operacijos pavadinimas” variable=”Atsako kintamasis”/>

Pranešimas(taisyklė, ryšys) gali būti atvaizduojami į aktyvuotą pranešimą (onMessage), kuris įtraukiamas į įvykį reguliuojantį elementą(eventHandler). Aktyvuotas pranešimas (onMessage) yra atvaizduojamas analogiškai kaip gavimo(recieve) elementas(su tokiais pat atributais). <eventHandlers> <onMessage partnerLink=“Sąsajos pavadinimas“ portType=“ Siunčiamo pranešimo jungties pavadinimas“ operation=“ Operacijos pavadinimas“ variable=”Kintamojo pavadinimas”/> veikla </onMessage> </eventHandlers>

Veikla gali būti sužadinimas(invoke), klaidos metimas(throw) ir t.t.

2.2. Pranešimo vaizdavimo pavyzdys

4 pav. Fragmentas iš 2pav. (nuotolinės mokymosi sistemos modelis BPMN) modelio

– 531 –


Vartotojas siunčia pranešimą apie akademines atostogas dekanui. Iš duomenų modelio vartotojas siuntimui paimami reikalingi duomenys: prašymas(tipo dokumentas), vardas(tipo string), pavardė(tipo string), bei vartotojo studento numeris(tipo string),. Pranešimo siuntimui apsirašomi reikalingi elementai ir tipai tokie kaip: pranešimo tipas, sąsajos tipas, sąsaja, siuntimo partneriai, kintamieji. Jei pranešimas nusiunčiamas be trikdžių ir patvirtinamas(sužadinamas gavėjo procesas), partneris(dakanas) siunčia atsaką(pranešimą apie patvirtinimą) ir patvirtinimo dokumentą. Jei dėl tam tikrų priežasčių dokumentas nepasiekia adresato siunčiamas klaidos pranešimas siuntėjui(vartotojui). <message name=“Akademinės atostogas“> <part name=”Vartotojas.Prašymas” type=”xsd:dokumentas”/> <part name=“Vartotojas.vardas“ type=“xsd:string“/> <part name=“Vartotojas.pavadė“ type=“xsd:string“/> <part name=“Vartotojas.studento_numeris“ type=“xsd:string“/> </message> <message name=“Pranešimas nepatvirtintas“> <part name=”Pranešimas.Siuntimo klaida” type=”xsd:string”/> </message> <message name=“Akademinės patvirtintos“> <part name=”Dekanas.Dokumentas” type=”xsd:dokumentas”/> </message> <portType name=”Prašymo siuntimas”> <operation name=”Siųsti prašymą”> <input message=“pos: Akademinės atostogas“/> <fault name=“Prašymas negalimas“/> message=”pos: Pranešimas nepatvirtintas” </operation> </portType> <portType name=”Prašymo tvirtinimas”> <operation name=”Tvirtinti”> <input message=“pos: Akademinės atostogas“/> </operation> </portType> <plnk:partnerLinkType name=“Siuntimas“> <plnk:role name=“siuntimo aptarnavimas“> <plnk:portType name“ Prašymo siuntimas“> </plnk:role> </plnk:partnerLinkType> <partnerLinks> <partnerLink name=“Pranešimo siuntimas“> myRole=”siuintimo aptarnavimas” < partnerLinkType =” Siuntimas”> myRole=”patvirtinimo aptarnavimas” </partnerLinks> <variables> <variable name=”Pranešimas apie akademines atostogas” messageType=”lns:Akademinės atostogos”> <variable name=”Klaida” messageType=”lns: Pranešimas nepatvirtintas”> <variable name=”Akademinės atostogos patvirtintos” messageType=”lns: Akademinės patvirtintos”> </variables> <faultHandlers> <catch faultName=“ Pranešimas nepatvirtintas“ faultVariable=“Klaida“> <reply partnerLink=“ Pranešimo siuntimas“ portType=” Prašymo siuntimas” operation= “Siųsti prašymą” variable=“ Klaida“ faultName=“ Pranešimas nepatvirtintas“ </catch> </faultHandlers <receive partnerLink=“ Pranešimo siuntimas“ portType=“ Prašymo siuntimas“ operation=“ Siųsti prašymą“ variable=” Pranešimas apie akademines atostogas” </receive> <links> <link name=”Siųsti-Priimti”/> </links> <invoke partnerLink=”Siuntimas” portType=” Prašymo tvirtinimas” operation=”Tvirtinti” inputVariable=” Pranešimas apie akademines atostogas” outputVariable=” Akademinės atostogos patvirtintos”/> <source linkName=”Siųsti_Priimti”/> </invoke>

– 532 –


– 533 –

6. Išvados

Šiame darbe buvo analizuojamos dviejų naujų projektavimo kalbų UML 2.0 ir BPMN savybės. BPMN yra specializuota verslo procesų vaizdavimui ir turi išsamią tam skirtą notaciją UML 2.0 yra universali kalba, ir verslo procesų modeliavimas yra tik viena jos naudojimo krypčių. Verslui modeliuoti UML 2.0 turi panašias galimybes, kaip ir BPMN, tačiau UML 2.0 elementų aibė mažesnė. Pagrindinis BPMN trūkumas – nėra priemonių dalykinei sričiai vaizduoti. Dokumentai gali būti parodyti tik kaip pastabos. UML veiklos diagramose dokumentai vaizduojami kaip objektai, kurie dalyvauja veiklos procese ir turi įtakos jo eigai. Greta veiklos diagramų yra išsamus priemonių rinkinys informacinei sistemai projektuoti. Abiejose kalbose galima aprašyti verslo taisykles, tačiau jų apdorojimo priemonių ar rekomendacijų nėra. Kadangi verslo procesams projektuoti nepakanka vienos kurios notacijos buvo siūloma UML 2.0 papildyti BPMN stereotipais. Kad projektavimo procesai būtų pilnai išbaigtas grafinis modelis turi būti siejamas su dalykinės srities modeliu, todėl buvo pasirinkta viena iš realizavimo kalbų BPEL4WS. Išanalizuotas atvaizdavimas į šia kalbą ir sudarytas metamodelis jungiantis visas anksčiau paminėtas kalbas.

Literatūra [1] Buisiness porcess modeling notation. Prieiga per internetą:

http://dwdemos.dfw.ibm.com/wstk/common/wstkdoc/ettk/wstk/services/demos/uml2bpel/docs/UMLProfileForBusinessProcesses1.1.pdf

[2] Unified Modeling Language: Superstructure version 2.0. Prieiga per internetą: http://www.u2-partners.org/uml2-submissions.htm

[3] Prieiga per internetą: http://bpmi-notation-wg.netfirms.com/Documents/NWG-2002-11-02R1%20BPMN%200-9-1.pdf

[4] Buisiness porcess modeling notation version 1.0 may 3, 2004. Prieiga per internetą: http://www.google.com/search?q=BPMN+V1-0+May+3+2004(1).pdf&sourceid=opera&num=0&ie=utf-8&oe=utf-

82 [5] Business process execusion language for Web services version 1.1 “ Prieiga per internetą: http://www-128.ibm.com/developerworks/webservices/library/ws-bpel1/Business Process Execution Language for

Web Services Version 1_1.htm [6] Users manual 7.2. Prieiga per internetą: www.magicdraw.com [7] Users guide. Prieiga per internetą: http://www.sparxsystems.com.au/bin/EAUserGuide.pdf [8] Simanaitytė K., Nemuraitė L. Veiklos procesų modeliavimas naudojant veiklos procesų modeliavimo notaciją: 9-oji

tarpuniversitetinė magistrantų ir doktorantų konferencija [2004m. balandžio 15 d., Kaunas]: pranešimų medžiaga. Kaunas, 2004, p. 254-259.

[9] WS-BPEL. Prieiga per internetą: http://www.ebpml.org/bpel4ws.htm [10] Business process execution language for web services“Prieiga per internetą http://www.oasis-pen.org [11] XML Schema Part 2: Datatypes Second Editon“ Prieiga per internetą: http://www.w3.org/TR/xmlschema-2

Analysis of Business Process Modelling Languages and Specification Means

Visual languages are used for understability of business analysis, modelling and computerisation processes for business analysts as soon as system developers. The advantages of visual modeling are standard notation, unified concepts, intuitivity of use. There is no single language suitable for all phases of business process evolution. Three languages were analysed: UML 2.0, BPMN bei BPEL4WS, with regards of their possibilities to represent and execute e-business processes. For making comprehensive e-business model, it is proposed to extend UML 2.0 with BPMN stereotypes and to implement them in UML CASE tool. The exclusive feature of proposed way of modelling lies in integration of of business process model with object types of problem domain.



http://www.u2-partners.org/uml2-submissions.htm

http://www.u2-partners.org/uml2-submissions.htm

http://bpmi-notation-wg.netfirms.com/Documents/NWG-2002-11-02R1 BPMN 0-9-1.pdf

http://bpmi-notation-wg.netfirms.com/Documents/NWG-2002-11-02R1 BPMN 0-9-1.pdf

http://www.google.com/search?q=BPMN+V1-0+May+3+2004(1).pdf&sourceid=opera&num=0&ie=utf-8&oe=utf-82

http://www.google.com/search?q=BPMN+V1-0+May+3+2004(1).pdf&sourceid=opera&num=0&ie=utf-8&oe=utf-82

http://www-128.ibm.com/developerworks/webservices/library/ws-bpel1/Business Process Execution Language for Web Services Version 1_1.htm

http://www-128.ibm.com/developerworks/webservices/library/ws-bpel1/Business Process Execution Language for Web Services Version 1_1.htm

http://www.magicdraw.com/

http://www.sparxsystems.com.au/bin/EAUserGuide.pdf

http://www.ebpml.org/bpel4ws.htm

http://www.w3.org/TR/xmlschema-2

META DUOMENYS VEIKLOS TAISYKLĖMS SU DUOMENŲ BAZE INTEGRUOTI

Rimantas Butleris, Liudas Motiejūnas Informacijos sistemų katedra, Kauno technologijos universitetas

Studentų 50, LT-51368, Kaunas

Straipsnyje apžvelgiami pagrindiniai veiklos taisyklių sistemos komponentai: veiklos taisyklių redagavimo sąsaja, veiklos taisyklių derinimo aplinka, veiklos taisyklių saugykla bei interpretatorius. Analizuojami veiklos taisyklių saugyklai aptarnauti reikalingi duomenys – informacija apie duomenų modelį sudarančias esybes, atributus ir ryšius tarp jų. Taip pat apžvelgiami du veiklos taisyklių tipai, besiskiriantys pagal jų iškvietimą iš veiklos taisyklių saugyklos.

1.Įvadas

Šiuo metu yra sukurta nemažai veiklos taisyklėmis grįstų informacinių sistemų (IS) modelių [1,2]. Komponentų skaičius ir jų paskirtis gali skirtis skirtingose veiklos taisyklių sistemose, tačiau galima išskirti keletą pagrindinių komponentų, kurie yra būtini veiklos taisyklių sistemos funkcionalumui palaikyti. Be šių komponentų veiklos taisyklių sistema negali tinkamai funkcionuoti. Svarbiausi veiklos taisyklių sistemos komponentai ir ryšiai tarp jų pavaizduoti 1 pav.

Veiklos taisyklių saugykla

Veiklos taisyklių

interpretatorius

Veiklos taisyklių derinimo aplinka

Veiklos taisyklių redagavimo

aplinka

1 pav. Apibendrinta veiklos taisyklių sistemos architektūra

Kiekvienas iš šių komponentų gali susidėti iš kitų komponentų, priklausomai nuo pasirinktos realizacijos, tačiau jų nedetalizuosime, nes pristatome tik pagrindinę koncepciją.

2. Esminiai veiklos taisyklių sistemos komponentai 2.1. Veiklos taisyklių redagavimo aplinka

Kiekvienoje veiklos taisyklių sistemoje yra įrankis, skirtas veiklos taisyklių redagavimui. Šis komponentas turi aprūpinti vartotoją paprasta ir vartotojui suprantama grafine aplinka, kuri būtų suprantama ne tik patyrusiems vartotojams. Tai aplinka, kuri padeda vartotojui specifikuoti veiklos taisykles nuo pradžios iki pabaigos, sukurta paprastam veiklos taisyklių kūrimui ir tiesiogiai skirta vartotojams/kūrėjams. Skirtingos realizacijos vartotojus aprūpina skirtingomis veiklos taisyklių redagavimo galimybėmis [3-6]. Veiklos taisyklių redagavimo aplinka privalo užtikrinti teisingą veiklos taisyklių sintaksę.

Žinoma, savybės, kurios charakterizuoja veiklos taisyklių redagavimo aplinką, priklauso nuo sistemos tipo, architektūros ar veiklos taisyklių, su kuriomis dirba sistema, tipų, tačiau ši aplinka privalo teikti vartotojui kiek įmanoma daugiau veiklos taisyklių įvedimo ir redagavimo galimybių.

2.2 Veiklos taisyklių saugykla

Veiklos taisyklių saugykla fiziškai yra autonominis veiklos taisyklių rinkinys, kuris gali būti keičiamas bet kuriuo metu [7]. Yra du veiklos taisyklių saugojimo būdai:

– 534 –

Meta duomenys veiklos taisyklėms su duomenų baze integruoti

1. Parametrais grindžiamas būdas. Šiuo atveju taisyklės yra saugomos duomenų bazėje, kurioje jos charakterizuojamos įvairių atributų reikšmėmis. Skirtingi tyrinėtojai parodė, kad veiklos taisyklių saugykla gali būti suprojektuota kaip nepriklausoma duomenų bazė [8] arba kaip dalis loginio duomenų modelio [9]. Vis dėlto pirmasis būdas suteikia daugiau lankstumo ir galimybių saugoti sudėtingas veiklos taisykles.

2. Nepriklausomas procesais pagrįstas būdas. Šis būdas yra panašus į tradicines metodologijas, kur taisyklės tiesiogiai realizuojamos programos kode, tik šiuo atveju kodas, atvaizduojantis veiklos taisykles, saugomas atskirai nuo kitų IS sluoksnių ir todėl taisyklės sistemoje yra aprašomos tik vieną kartą.

Veiklos taisyklių saugykla yra taisyklių bazė, kurioje saugomi visi duomenys apie veiklos taisykles. Visuotinai priimtinos veiklos taisyklių struktūros tikriausiai neįmanoma sukurti, kadangi įvairūs autoriai ar organizacijos išskiria įvairius veiklos taisyklių tipus bei jų aprašymo būdus [10-13]. Vis dėlto galima išskirti keletą privalomų atributų, kurie turėtų būti saugomi veiklos taisyklių saugykloje, kad veiklos taisykles būtų galima greitai ir patogiai vykdyti. Tai aptariama trečiajame skyriuje.

2.3. Veiklos taisyklių derinimo aplinka

Veiklos taisyklių įvedimo sąsajos pagalba įvestos taisyklės sintaksiškai bus teisingos. Tačiau ar įvestų veiklos taisyklių semantika yra teisinga, ar jos neprieštarauja viena kitai, ar atlieka tokius veiksmus, kuriuos norėjo apibrėžti vartotojas, ar veiklos taisyklių grupavimas yra teisingas ir t.t., turi užtikrinti veiklos taisyklių derinimo aplinka. Derinimas turi būti prieinamas kūrimo/testavimo aplinkoje ir jų vykdymo sistemose. Vykdymo stebėjimas turi būti prieinamas tam, kad surasti laiką eikvojančias operacijas ir nenaudojamas ar per daug intensyviai naudojamas taisykles [14].

Jame turi būti galimybės patikrinti, kaip veikia viena ar keletas taisyklių su jau esamais duomenimis, suteikti galimybę vykdyti taisykles po žingsnį ar nustatyti kritinius taškus taisyklių rinkiniuose. Tam, kad tai būtų įmanoma, veiklos taisyklių saugykloje turi būti laikoma visa informacija, susijusi su veiklos taisyklėmis, o tai reiškia, kad privalome saugoti ne tik pačias veiklos taisykles, bet ir meta duomenis apie duomenų bazės lenteles, atributus ir ryšius.

2.4. Veiklos taisyklių interpretatorius

Saugomų taisyklių vykdymas yra valdomas specialaus veiklos taisyklių interpretavimo mechanizmo, vadinamo veiklos taisyklių interpretatoriumi. Toks interpretatorius laikomas monolitiniu mechanizmu, tačiau parodyta [15], kad užduočių taisyklių vykdymas ar realizavimas gali būti atliktas daugiau ar mažiau nepriklausomų servisų.

Veiklos taisyklių interpretatorius iškviečia veiklos taisykles iš veiklos taisyklių saugyklos bei įvykdo taisyklėse aprašytus veiksmus. Kaip ir veiklos taisyklių saugykla, taisyklių interpretatorius gali būti realizuotas įvairiais būdais [16, 17], kadangi jo architektūra bei veikimo principai tiesiogiai priklauso nuo saugyklos, nuo to, kokia forma saugomos veiklos taisyklės ir kiti reikalingi duomenys. Šiame straipsnyje yra kalbama apie taisyklių interpretatorių, kuris tiesiogiai dirba su duomenų bazėmis. Veiklos taisyklių interpretatorius privalo įvertinti su kokiais duomenimis jis turės dirbti veiklos taisyklės vykdymo metu. Dėl to būtina saugoti papildomus duomenis taisyklių saugykloje apie lenteles, atributus ir ryšius egzistuojančioje duomenų bazėje.

Tačiau nesvarbu kaip ir kokiu būdu realizuotas veiklos taisyklių interpretatorius, jis privalo užtikrinti teisingą veiklos taisyklių vykdymą.

3. Veiklos taisyklių saugykloje saugomi duomenys

Veiklos taisyklių saugykla pati savaime 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, tačiau nesusiję su konkrečia veikla. Veiklos duomenys yra tiesiogiai naudojami operacijose ir naudojami net ir be kompiuterizuotos sistemos. Meta duomenys yra papildomi duomenys, kurie aprašo, ką savyje laiko kompiuterizuotos sistemos ir kaip jos dirba arba aprašo veiklos duomenis, tokius kaip veiklos terminų apibrėžimai. Didelis meta duomenų komponentas, su kuriuo turi dirbti sistemos projektuotojai yra meta duomenys, kurie aprašo taikomosios sistemos duomenų bazės struktūrą.

Veiklos taisyklių saugykloje šie duomenys yra svarbūs, nes veiklos taisyklių interpretatorius pagal tai nustato, su kokiais srities duomenimis jam reikės dirbti veiklos taisyklės vykdymo metu. Kaip parodyta 2 pav., veiklos taisyklių saugykla gali būti padalinta į dvi pagrindines dalis.

Toks atskyrimas nereiškia, kad duomenys apie duomenų bazę ir veiklos taisyklės yra saugomos atskirai. Tai parodo, kad saugykloje yra dvi pagrindinės duomenų rūšys, kurios skiriasi savo prasme. Kai kuriose duomenų bazių valdymo sistemose (DBVS) meta duomenys apie esybes, atributus, ryšius ir t.t. išsaugomi tarnybinėje DB dalyje, tačiau skirtingose DBVS yra skirtingi meta duomenys ar bent jau jie skiriasi savo saugojimo struktūra. Dėl to turime

– 535 –

R. Butleris, L. Motiejūnas

išgauti šiuos meta duomenis iš pirminės duomenų bazės ir laikyti juos veiklos taisyklių saugykloje bendroje formoje.

Veiklos taisyklės

Duomenų bazės metaduomenys

Veiklos taisyklių saugykla

2 pav. Veiklos taisyklių saugykla

3.1. Meta duomenys apie duomenų bazės lenteles

Duomenų bazė yra sudaryta iš lentelių, kurios turi laukus ir ryšių tarp jų. Reikalinga autonomiškai išsaugoti tam tikrą informaciją apie šią struktūrą, kadangi veiklos taisyklių interpretatoriui reikia identifikuoti su kokios lentelės atributais jam reikia dirbti.

Veiklos taisyklių saugykla pati savaime yra duomenų bazė. Pirmiausia saugykloje turi būti lentelė, kurioje saugosime duomenis, susijusius su duomenų bazės lentelėmis. Ši lentelė yra pavadinta Lentele. Kiekviena lentelė duomenų bazėje turi savo unikalų fizinį vardą, kuris turi būti laikomas veiklos taisyklių saugykloje, kadangi interpretatorius tiesiogiai dirba su duomenų bazės lentelėmis. Kadangi šis vardas unikalus, jis gali būti naudojamas kaip pirminis raktas veiklos taisyklių saugyklos esybėje Lentele. Šį vardą saugosime atribute, pavadintame Lenteles_pav. Antras atributas yra Lentelės_aprasas, kuriame saugosime lentelės paskirties apibrėžimą. Lentelės apibrėžimas yra svarbus analitikams, programuotojams bei vartotojams, kad jie galėtų geriau suprasti, kam ši lentelė yra skirta. Esybės Lentele struktūra pavaizduota 3 pav.

Lentele

Lenteles_pav (PR) Lenteles_aprasas

3 pav. Esybės Lentele stru

Meta duomenys apie lentelę nebūtinai turi būti įvedami ramodeliavimo įrankių. Yra nemažai duomenų modeliavimo įrankių iduomenų pateikimo šaltinis.

3.2. Meta duomenys apie lentelių laukus

Fizinėje duomenų bazėje lentelės atvaizduoja esybes, o laukai privalo turėti galimybę saugoti meta duomenis apie laukus, kurie ssaugykloje skirta lentelė, pavadinta Laukas. Toliau aptarsime atribu

Pirmasis atributas yra Lauko_ID. Kartais skirtingose duomenpačiais pavadinimais, bet skirtingomis prasmėmis. Pavyzdžiui, gPavarde bei lentelė Darbuotojas su tokiu pačiu pavadinimu. Didentifikatorių, kuris gali būti sugeneruotas automatiškai.

Veiklos taisyklių interpretatoriui svarbu identifikuoti su kokiaitaisyklėmis metu. Fiziniai laukų pavadinimai saugomi atribute Lauk

Taip pat kaip ir su meta duomenimis apie lenteles, reikia apibrėžimas (atributo_aprasas). Jis padės vartotojams ir projektuoto

Veiklos taisyklių interpretatoriui svarbu identifikuoti, kurie lesaugoma atribute Laukas_PR. Šis atributas įgauna reikšmę TRUEreikšmė - FALSE.

Taip pat reikia identifikuoti ar laukas yra išorinis raktas. Ši infobus TRUE, jei laukas yra pirminis raktas ir FALSE, jei laukas nėra p

– 536 –

PR – pirminis raktas;IR – išorinis raktas

ktūra

nkiniu būdu. Juos galima išgauti iš duomenų r kurių dauguma gali būti panaudotas kaip tokių

atvaizduoja atributus. Veiklos taisyklių saugykla uformuoja duomenų bazės lenteles. Šiam tikslui tus, laikomus šioje lentelėje. ų bazės lentelėse gali būti atributai su tokiais ali būti lentelė Pirkėjas, kurioje yra atributas ėl šios priežasties reikia turėti unikalų lauko

s fiziniais laukais reikės operuoti manipuliavimo o_pav. turėti atributą, kuriame bus laikomas atributo jams suprasti atributo reikšmę.

ntelės laukai yra pirminiai raktai. Ši informacija , jei laukas yra pirminis raktas, kitu atveju jo

rmacija saugoma atribute Laukas_IR. Jo reikšmė irminis raktas.


Kiekvienas laukas priklauso vienai lentelei. Veiklos taisyklių interpretatoriui yra būtina identifikuoti šią lentelę. Tai gali būti padaryta įtraukiant atributą Lenteles_pav iš esybės Lentele.

Jei laukas yra išorinis raktas, veiklos taisyklių saugykloje turi būti saugoma informacija apie tėvo lentelę, iš kurios paimtas išorinis raktas. Tai gali būti padaryta įvedant dar vieną ryšį su esybe Lentele ir ši informacija bus saugoma atribute IR_tevo_lentele.

Jei laukas yra išorinis raktas, vadinasi turi būti atitinkamas laukas “tėvo” lentelėje. Veiklos taisyklių interpretatoriui reikia identifikuoti ir šį lauką. Tam reikia žinoti “tėvo” lentelėje esantį Lauko_ID. Ši informacija saugoma atribute IR_tevo_lauko_ID ir reikalauja rekursyvaus ryšio Laukas esybei. Esybės Laukas struktūra pavaizduota 4 pav.

Laukas

Lauko_ID (PR) Lauko_pav Atributo_aprasas Laukas_PR Laukas_IR Lenteles_pav (IR) IR_tevo_lentele(IR) IR tevo lauko ID (IR)

Lentele

Lenteles_pav (PR) Lenteles_aprasas

4 pav. Esybės Laukas struktūra

Meta duomenis apie laukus, taip pat kaip ir meta duomenis apie lenteles, galima išgauti iš duomenų modeliavimo įrankio.

3.3. Meta duomenys apie ryšius

Ryšiai tarp esybių yra trečiasis duomenų komponentas, su kuriuo dirba veiklos taisyklių interpretatorius. Esybė, sauganti duomenis apie ryšius, turi būti įtraukta į statinį veiklos taisyklių saugyklos modelį. Šią esybę pavadinsime Rysys. Ryšys gali būti tik tarp dviejų esybių – “tėvo” esybės ir “vaiko” esybės. Tačiau gali būti daugiau nei vienas ryšys tarp tų pačių esybių. Dėl to reikia turėti unikalų identifikatorių, kuris identifikuotų ryšį. Tam tikslui skirtas Rysio_ID atributas.

Savaime suprantama, kad reikia turėti “tėvo” ir “vaiko” lentelių vardus. Ši informacija saugoma dviejuose atributuose Tevo_lentele bei Vaiko_lentele.

Atributas Rysio_aprasas skirtas tam, kad būtų galima geriau suprasti ryšio prasmę. Kuomet pirminis tėvo lentelės raktas pereina į vaiko lentelę, atributas ne visuomet turi tokį patį pavadinimą.

Veiklos taisyklių interpretatorius turi “žinoti”, kaip tokie atributai vadinami vaiko esybėse. Šios problemos sprendimui sukurta nauja esybė, pavadinta Rysys_laukas. Ši esybė turi pirminį raktą Rysio_ID ir Tevo_lauko_ID. Tevo_lauko_ID yra tėvo lauko lauko_ID, kuris perėjo iš tėvo lentelės į vaiko lentelę.

Atributas Vaiko_lauko_ID yra atitinkamas Lauko_ID iš vaiko lentelės. Esybių Rysys bei Rysys_laukas struktūra pavaizduota 5 pav.

Rysys_laukas Rysio_ID (PR) Tevo_lauko_ID (IR) Vaiko_lauko_ID (IR)

Rysys Rysio_ID (PR) Tevo_lentele (IR) Vaiko_lentele (IR) Rysio_aprasas

4 pav. Esybių Rysys bei Rysys_laukas struktūra

Taip pat kaip meta duomenis apie lenteles ir laukus, meta duomenis apie ryšius galima išgauti iš duomenų modeliavimo įrankio.

– 537 –

R. Butleris, L. Motiejūnas

4. Veiklos taisyklės meta duomenų pavyzdys

Skirtingose įmonių kompiuterizuotose sistemose saugomi skirtingi duomenys. Tačiau skirtingos sistemos gali naudoti tokį patį veiklos taisyklių interpretatorių. Veiklos taisyklių meta duomenys reikalingi tam, kad būtų galima susieti konkrečias veiklos taisykles su esamais realiais srities duomenimis. Kitaip tariant, meta duomenys nusako interpretatoriui su kokia duomenų bazės struktūra bei kokiais duomenimis dirba kompiuterizuota sistema. Sekančiame pavyzdyje pateikta paprasta veiklos taisyklė ir parodyta, kaip aprašomi šios taisyklės meta duomenys. Tarkime, kad turime tokią veiklos taisyklę:

Kiekvienas tiekėjas privalo turėti adresą. <Tiekėjas.adresas < >.NULL> Šioje taisyklėje dalyvauja viena duomenų bazės lentelė Tiekėjas. Šios lentelės meta duomenys pavaizduoti 1

lentelėje.

1 lentelė. Meta duomenys apie duomenų bazės lentelę Tiekėjas

Lenteles_pav Lenteles_aprasas Tiekėjas …

Taip pat į veiklos taisyklę įtrauktas vienas lentelės laukas – Adresas. Meta duomenys apie šį lauką parodyti 2

lentelėje.

2 lentelė. Meta duomenys apie lentelės lauką Adresas

Lauko_ID Lauko_ID Lauko_aprsas

Laukas_PK Laukas_FK Lenteles_pav

IR_tevo_lentele

IR_tevo_lauko_ID

Adres1 Adresas … FALSE FALSE Tiekėjas - -

Turėdamas tokią informaciją apie veiklos taisyklėje dalyvaujančius realios srities duomenis, veiklos taisyklių interpretatorius galės atrinkti ir įvykdyti reikiamą taisyklę.

5. Išvados

Straipsnyje pristatyti pagrindiniai meta duomenys apie lenteles, laukus ir ryšius, kurie turi būti saugomi veiklos taisyklių saugykloje. Veiklos taisyklių saugykloje šie duomenys yra būtini, kadangi veiklos taisyklių interpretatorius privalo atsirinkti, su kokiais veiklos duomenimis jam reikia dirbti veiklos taisyklės vykdymo metu. Šių duomenų saugojimui buvo sukurtos Lentele, Laukas, Rysys bei Rysys_laukas esybės. Žinant meta duomenis apie egzistuojančią duomenų bazę, veiklos taisyklių interpretatorius turės visus reikalingus duomenis, kad galėtų susieti veiklos taisykles su realiais srities duomenimis bei teisingai įvykdyti taisykles.

Tolesniame darbe numatoma sudaryti veiklos taisyklių saugyklos modelį, kuris kartu apjungtų ir meta duomenis apie duomenų bazę ir pačias veiklos taisykles. Be to planuojama sukurti veiklos taisyklių interpretatoriaus architektūros modelį, kad būtų galima tas taisykles atrinkti ir apdoroti.

Literatūros sąrašas 1. B. Von Halle. Business rules applied: building better systems using the business rules approach. John Wiley & Sons, New

York, 2001. 2. L. Motiejūnas, R. Butleris. Veiklos taisyklių manipuliavimo mechanizmų analizė. Informacines Technologijos 2003.

Kaunas, Technologija, 2003, p. XIV-82 - XIV-90. 3. Developing Real-World Java Applications with Blaze Advisor. Technical White Paper.

http://www.blazesoft.com/brwhitepapers/advisor_java_apps.pdf. 4. Detailed Solution report. Blaze Advisor. http://www.blazesoft.com/support_training/tech_support.html. 5. The Power of Rules Driven Processing. http://www.blazesoft.com/International/UK/white_papers/index.html. 6. Infrex – where business rules. http://www.tcs.com/0_products/infrex/index.htm. 7. R. Butleris, K. Kapocius. The Business Rules Repository for Information Systems Design. 6th East-European Conference

ADBIS'2002". Research Communications. Vol.2, - Bratislava: STU, 2002, p. 64 -77. 8. D. Plotkin. Business Rules Everywhere. Intelligent Enterprise Magazine, March 09, 2 – 4, 1999.

http://www.iemagazine.com.

– 538 –

http://www.blazesoft.com//brwhitepapers/advisor_java_apps.pdf

http://productfinder.infoworld.com/infoworld/ActivityServlet?ksAction=optInReq&solId=47582&trkpg=solsummary_solname

http://www.blazesoft.com/International/UK/white_papers/index.html

http://www.tcs.com/0_products/infrex/index.htm

http://www.iemagazine.com/


9. A. Perkins. Business Rules Are Meta Data. Business Rules Journal, Vol. 3, No. 1, (Jan. 2002), http://www.BRCommunity.com/a2002/b097.html.

10. Meta data coalition open engineering model, business engineering model, business rules. Review draft. Kista, Dept. of Comp. and Systems Sci., Royal Inst. of Technology, (KTH) and Stockholm Univ., July 1999. http://www.mdcinfo.com/OIM/models/BRM.html.

11. Response to MDC/Microsoft Business Rules Metamodel by the Business Rules Group. Business Rules Group, 1999. http://www.businessrulesgroup.org/brg-mdc/BRG-MDC.pdf.

12. R. G. Ross. The business Rule Book (2nd ed.). Business Rule Solutions, Houston, 1997. 13. P. Kardasis, P. Loucopoulos. Expressing and organising business rules. Information and Software Technology 2004 (in

press). 14. K. Molay. A practical guide to business rules management software. www.eaijournal.com/PDF/Aug03Molay.pdf. 15. C. Mariano, C. Bornhövd and A. P. Buchmann. Moving Active Functionality from Centralized to Open Distributed

Heterogeneous Environments. Lecture Notes in Computer Science, Vol. 2172, 2001, p. 195-211. 16. K. D. Wilson. Business Rules, Platforms, and Inferencing, Business Rules Journal, Vol. 4, No. 10 (October 2003),

http://www.BRCommunity.com/a2003/b169.html. 17. R. G. Ross. Principles of the Business Rule Approach. Addison-Wesley, 2003.

The Metadata for Business Rules Integration with Database Schema

In this article we discuss about main business rules components: business rules editing interface, business rules debugging interface, business rules repository and business rules engine. Business rules repository is a database that stores all the data about business rules and all needed metadata about entities, attributes and relationships. This kind of the metadata is analysed.

http://www.brcommunity.com/a2002/b097.html

http://www.mdcinfo.com/OIM/models/BRM.html

http://www.businessrulesgroup.org/brg-mdc/BRG-MDC.pdf

http://www.eaijournal.com/PDF/Aug03Molay.pdf


WVERSLO VALDYMO SISTEMOS NAVISION ATTAIN IR OLAP DUOMENŲ ANALIZĖS INTEGRACIJA

Algirdas Kepežinskas, Line Nemuraitė Kauno technologijos universitetas

Informacijos sistemų katedra, Studentų 50-308

Straipsnyje analizuojama verslo valdymo sistemos Navision Attain duomenų išgavimas, transformacija ir galiausiaipanaudojimas OLAP duomenų analizės priemonėse. Nagrinėjamos šių dviejų sistemų integracijos savybės, reikalingos transformacijos bei dažniausiai kylančios problemos. Sudarytas pavyzdinis duomenų kubas prekių apyvartai stebėti. Sukurtas automatinis kubo atnaujinimas, apibendrintos platesnės panaudojimo galimybės.

1. Įvadas

Lietuvoje vis daugiau ir daugiau vidutinių ir stambių įmonių diegiasi verslo valdymo sistemas. Ar tai būtų Navision Attain, SAP, Axapta, ar bet kuri kita VVS, jos suteikia įmonėms įrankį efektyviai valdyti resursus, išteklius, finansus, gamybą, bei kitus įmonėje vykstančius verslo procesus. Visos šios sistemos savyje turi numatytas ataskaitų generavimo priemonės, tačiau vis dažniau ir dažniau šių sąlyginai paprastų priemonių nebeužtenka norint patenkinti vis augančius vartotojų poreikius.

Ar dėl patogumo, ar dėl resursų stygiaus, ar dėl plėtimo galimybių, vis daugiau įmonių renkasi duomenų analizę atlikti naudojantis OLAP priemonėmis. Naudojantis šiomis priemonėmis, dalis realios duomenų bazės duomenų, reikalingų analizei, perkeliami į duomenų saugyklą (data warehouse), kur jie transformuojami, pritaikant juos specifiniams poreikiams, saugomi specifinėse duomenų saugyklose (data marts) ir toliau apdorojami OLAP priemonėmis. Iš jų kuriami duomenų analizės kubai, kurie leidžia duomenis matyti įvairiais pjūviais, analizuoti juos pagal įvairias dimensijas, grupuoti, skirstyti, laisvai pasirenkant jų pateikimo formą.

Microsoft SQL Server Analysis Services suteikia galimybę atlikti visas šias operacijas, tuo labai palengvindamas didelių duomenų kiekių analizę. Duomenų išgavimui ir transformavimui naudojama SQL Server Data Transformation Services, kurie įgalina duomenis pakeisti bei pritaikyti taip kaip reikalauja konkretus atvejis. Pakeisti duomenys saugojami tame pačiame SQL Serveryje, toje pačioje ar naujose duomenų bazėse. Iš ten juos paima Analysis Services, ir pagal suprojektuotą kubų schemą juos apdoroja, bei saugo galutinėje jų saugykloje (priklausomai nuo saugyklos tipo – pasirinkus saugyklos tipą MOLAP, duomenys perkeliami į Analysis Services duomenų bazę, pasirinkus ROLAP ar HOLAP tipą, duomenys lieka originalioje bazėje).

2. Navision Attain įdiegimo variantai

Navision Attain ir OLAP duomenų analizės priemonių integracijos architektūra, priklauso nuo Navision Attain įdiegimo tipo. Šiuo metu yra siūlomi du Navision Attain diegimo variantai: 1) Naudojant SQL Server 2000 duomenų bazę. Šis variantas skirtas didesnės apimties įmonėms, reikalaujančioms

didesnių galimybių bei našumo. Jis supaprastina Navision Attain ir OLAP duomenų analizės integraciją, nes visi Navision Attain duomenys jau yra saugomi SQL Serveryje, t.y. galima praleisti vieną išgavimo žingsnį. Tokiu atveju, integracijos architektūra atrodo taip:

2) Naudojant Navision Attain gimtąją (native) duomenų bazę. Šiuo atveju visi sistemos duomenys yra saugomi Navision Attain serverio gimtojoje duomenų bazėje. Norint juos sėkmingai panaudoti OLAP analizėje, juos reikia perkelti į SQL Serverį, o tam reikalingas papildomas išgavimo žingsnis naudojant C/ODBC duomenų bazės tvarkyklę. Nepriklausomai nuo to, koks diegimo variantas yra pasirinktas įmonėje, šią integraciją pilnai galima atlikti

naudojantis SQL Server 7.0 esančiomis priemonėmis.

– 540 –

Verslo valdymo sistemos Navision Attain ir OLAP duomenų analizės integracija

SQL Serveris Duomenų transformacijos Duomenų saugykla Analizės servisai Vartotojai

1 pav. Integracijos architektūra naudojant SQL Server duomenų bazę

Navision duomenų bazė

Duomenų saugyklaAnalizės servisai Vartotojai

C/ODBC tvarkyklė

Duomenų transformacijos

Duomenų transformacijos

SQL

2 pav. Integracijos architektūra naudojant Navision Attain gimtąją duomenų bazę

2. Navision Attain duomenų išgavimas, transformavimas, ir užkrovimas

Šiame straipsnyje analizuosime atvejį, kai Navision Attain sistema įdiegta naudojant SQL Server duomenų bazę.

Norint atlikti sėkmingą Navision Attain ir OLAP duomenų analizės integraciją, reikia atlikti šiuos etapus: 1) Identifikuoti reikalingas duomenų bazės lenteles. Navision Attain sistemoje yra apie 1000 skirtingų

lentelių, todėl ypač svarbu yra tiksliai bei teisingai identifikuoti reikalingas analizei. Priešingu atveju, rizikuojama susidurti su našumo problemomis, atsiranda didesnė klaidų tikimybė, bei sudėtingėja projektavimo ir kūrimo procesas.

2) Sukurti rodinius (views) ir DTS (data transformation services) atliekančius reikiamas duomenų transformacijas. Navision Attain naudojami specifiniai lentelių bei laukų pavadinimai, kurie dažniausiai sukelia problemų dirbant su Analysis Services paketu. Be to, daugelis operacijų nereikalauja būtinų klasifikatorių (ir kitų dimensijų) reikšmių, todėl šiuo atveju reikia užtikrinti, kad net ir nesant tuštiems įrašams dimensijų lentelėse, faktų lentelės įrašai vistiek bus įtraukti į kubą (tai aktualu, nes Analysis Services neleidžia kurti OUTER JOIN tipo ryšių). Šios problemos lengvai išsprendžiamos panaudojus minėtus rodinius bei DTS.

3) Suprojektuoti bei sukurti kubo schemą. Šiame žingsnyje yra svarbu numatyti ir tinkamai sukurti sąryšius tarp skirtingų lentelių, užtikrinti jų korektiškumą ir teisingumą.

– 541 –

A. Kepežinskas, L. Nemuraitė

4) Sukurti automatinį kubo atnaujinimo mechanizmą, nustatyti atnaujinimo intervalus ir patikrinti jo veikimą.

3. Pavyzdinis analizės kubas

Vaizdumui, bus sukurtas pavyzdinis Navision Attain duomenų analizės kubas, skirtas prekių apyvartai stebėti. Šiam kubui mus reikės šių lentelių: Prekė, Prekės knygos įrašas, Vertės įrašas. Sukūrus pavyzdinę diagramą,

iškart matyti kokie sudėtingi yra Navision Attain lentelių sąryšiai. Mes naudosimės tik keliais iš jų: Prekės knygos įrašas.Prekės Nr. -> Prekė.Nr. ir Vertės įrašas.Prekės knygos įrašo Nr. -> Prekės knygos įrašas.Įrašo Nr.

3 pav, Pavyzdinio kubo lentelių schema

Iš schemos matyti, jog yra daugybė mums nereikalingų laukų. Taip pat matyti, jog laukų pavadinimai turi savyje tarpų, kas sukeltų problemų dirbant su kubais. Vadinasi, teks parašyti keletą rodinių kad ištaisyti šias problemas

Atsargos – vertes irasai: CREATE VIEW dbo.[Atsargos - vertes irasai] AS SELECT [Item Ledger Entry No_] AS PrekesKnIrasoNr, SUM([Cost Amount (Actual)]) AS Suma FROM dbo.[CRONUS Lithuania u_a_b_$Value Entry] GROUP BY [Item Ledger Entry No_] Atsargos – preke: CREATE VIEW dbo.[Atsargos - preke] AS SELECT No_ AS PrekesNr, Description AS PrekesPavadinimas FROM dbo.[CRONUS Lithuania u_a_b_$Item] Atsargos – pagrindinis: CREATE VIEW dbo.[Atsargos - pagrindinis] AS SELECT pki.[Entry No_] AS IrasoNr, pki.[Posting Date] AS RegistravimoData, pki.[Item No_]AS PrekesNr, pki.[Document No_] AS DokumentoNr, pki.[Location Code] AS VietosKodas, pki.Quantity AS Kiekis, vi.Suma FROM dbo.[CRONUS Lithuania u_a_b_$Item Ledger Entry] pki INNER JOIN dbo.[Atsargos - vertes irasai] vi ON pki.[Entry No_] = vi.PrekesKnIrasoNr

– 542 –


Atsargos – pagrindinis rodinys tarnaus kaip faktų lentelė, Atsargos – prekė – kaip dimensijų lentelė. Sudėjus lenteles į kubų redaktorių, sukūrus sąryšius bei dimensijas, gautas naujasis kubas:

4 pav. Gautasis atsargų kubas

5 pav. Naujojo kubo duomenų pavyzdys

– 543 –

A. Kepežinskas, L. Nemuraitė

Kuriant automatinį kubo atnaujinimą, pasinaudosime SQL Server DTS įrankiais – sukursime pakuotę kubo atnaujinimui, ir nustatysime kad jį būtų paleidžiama kiekvieną naktį.

6 pav. Sukurtas automatinis kubo atnaujinimas

Norint sukurti kubą, išgaunantį duomenis iš Navision Attain sistemos įdiegtas gimtojoje bazėje, reikėtų papildomų žingsnių išgaunant duomenis naudojantis C/ODBC tvarkyklėmis ir saugant juos SQL bazėje. Sekantys žingsniai išlieka tokie patys.

5. Dažniausiai kylančios problemos

Būtina paminėti, jog naudojant Navision Attain duomenis OLAP duomenų analizės priemonėse, susiduriama su keletu rimtų problemų. Kai kurių iš jų sprendimas yra paprastas, kitų sudėtingesnis, tačiau norint sukurti optimaliai veikiančią sistemą, būtina atsižvelgti į jas visas. 1. Navision Attain naudoja specialius laukų tipus, vadinamus FlowFields ir FlowFilters. Šie laukų tipai skirti

greitam duomenų filtravimui ir išrinkimui iš susietų lentelių. Kadangi tai yra virtualūs laukai, jie SQL duomenų bazėje neturi atitikmens, ir norint juos panaudoti tenka išrinkimo užklausas formuoti atskirai. Tam galima naudoti du būdus: • naudoti Navision Attain kuriamas ir palaikomas FlowFields skaičiavimas skirtas lenteles. Šiose lentelėse

saugomos dalinės sumos ir kiti skaičiavimai, naudojami laukų atvaizdavimui. Tai yra didžiausią spartą užtikrinantis būdas, tačiau sunkiai pritaikomas praktiškai – bet koks pakeitimas Navision Attain sistemoje padarytų šiuos skaičiavimus nebetinkamais.

• naudoti atskirus rodinius šių laukų skaičiavimui. Tokiu būdu formuojamos užklausos kurių pagalba galima imituoti virtualius laukus. Rodiniai toliau naudojami pagrindinėje užklausoje.

2. Lėtas kubų atnaujinimo procesas. Šią problemą dažniausiai sukelia keletas veiksnių: • Didelis naudojamų dimensijų kiekis. Dažniai dimensijų kiekio sumažinti negalima, todėl reikia ieškoti kitų

sprendimų, kaip pavyzdžiui kuo daugiau dimensijų iškelti į dimensijų lenteles, kad kuo mažiau jų liktų faktų lentelėje. Taip pat svarbu datos dimensijoms naudoti atskiras lenteles, nes jų išrinkimas ir atnaujinimas trunka labai ilgai.

• Pagrindinės duomenų bazės apkrovimas. Šiuo atveju reikia apsvarstyti galimybę duomenis replikuoti į tik OLAP analizei skirtą duomenų saugyklą, ir kubų atnaujinimus vykdyti iš ten.

3. Lėtas pjūvių generavimas. Dažniausiai šią problemą nulemia tai, jog generuojami labai smulkūs pjūviai, to visai nenorint. Todėl reikėtų dimensijas grupuoti į logines grupes, pvz.: Prekių kategorija, Prekių grupė, Prekė. Tai atlikus, pjūvius galima generuoti stambesnius, tuo sumažinant reikalingų skaičiavimų kiekį, ir tuo pačių jų atlikimo trukmę.

4. Per didelis dimensijų narių kiekis. Norint analizuoti duomenis pagal, pvz., dokumento numerį, susiduriama su 64 tūkstančių dimensijų narių apribojimu. Tokiu atveju šias dimensijas reikia grupuoti pagal, pvz., pirmus simbolius, pagal datą, ar panašiai.

6. Išvados

Apibendrinant Navision Attain verslo valdymos ir OLAP duomenų analizės integraciją, reiktų pasakyti, kad: 1) Poreikis naudoti galingesnes duomenų analizės priemonės verslo valdymo sistemų duomenims analizuoti

vis didėja. 2) Galimybė panaudoti OLAP duomenų analizės priemones Navision Attain sistemoms duomenims analizuoti

yra visada – nesvarbu ar Navision Attain serveris įdiegtas SQL Server bazėje, ar gimtojoje bazėje. 3) Analizuojant Navision Attain duomenis kyla keletas standartinių kliučių, tačiau visoms joms išspręsti

pakanka turimų priemonių. 4) Analizės galimybės yra neribotos – jas riboja tik turimi techninės įrangos resursai. Galima išgauti bet kokį

norimą duomenų vaizdą. 5) OLAP duomenų analizę galima panaudoti bet kurioje įmonėje, nepriklausomai nuo joje vykstančių verslo

procesų tipo bei sudėtingumo.

– 544 –


Reikia manyti, jog laikui bėgant tokių diegimų ir integracijų su Navision Attain bei kitomis VVS tik daugės, todėl jau dabar yra svarbu įsisavinti pagrindus, kad prireikus būtų galima greitai ir efektyviai pritaikyti juos konkrečiai integracijai. Tai yra sąlyginai nauja ir perspektyvi rinka Lietuvoje, todėl būtina kuo plačiau ją išnaudoti, siekiant tiek naudos sau, tiek informacinių sistemų plėtrai Lietuvoje.

Literatūra [1] T.BAIN, M. BENKOVICH ir kiti, „Professional SQL Server 2000 Data Warehousing with Analysis Servines“, 2nd. ed.,

Wrox Press, 2001. [2] S. GOIL, A. CHOUDHARY, “High Performance Multidimensional Analysis and Data Mining“. [3] R. JACOBSON, „Microsoft SQL Server 2000 Analysis Services Step by Step“, Microsoft, 2000. [4] D. MOODY, M.KORTINK, „From Enterprise Models to Dimensional Models: A Methodology for Data Warehouse and

Data Mart Design // Proceedings of the International Workshop on Design and Management of Data Warehouses“, Stockholm, Sweden, 2000. Prieiga per internetą: http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-28/paper5.pdf

[5] Microsoft Corp., „Designing and Implementing OLAP Solutions with Microsoft SQL Server 2000“, 2000. [6] Microsoft Corp., „Delivery Guide Populating a Data Warehouse with Microsoft® SQL Server™ 2000 Data

Transformation Services“, 2001. [7] S. PAUL, N. GUATAM, R. BALINT, „Preparing and Mining Data with Microsoft SQL Server 2000 and Analysis

Services“, Microsoft, 2002. [8] E. THOMSON, „OLAP Solutions. Building Multidimensional Information Systems“, 2nd. ed., John Wiley & Sons, 2002.

MICROSOFT BUSINESS SOLUTIONS NAVISION ATTAIN AND OLAP DATA ANALYSIS INTEGRATION

This work covers data extraction, transformation and loading (ETL) for analyzing Navision Attain data using OLAP data analysis tools. Different integration architectures, aswell as needed transformations and most often problems are also covered, together with possible solutions to them. A sample data cube is created from Navision Attain, for item inventory tracking. In addition, an example schedule for cube updating is created, and wider usage guidelines are provided.

– 545 –

http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-28/

http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-28/

DUOMENŲ SAUGYKLOS KONCEPTŲ MODELIS

Jurgita Tonkūnaitė, Lina Nemuraitė Informacijos sistemų katedra, Kauno technologijos universitetas

Studentų g. 50, LT-3031 Kaunas

Duomenų saugykla (warehouse) – tai iš operacinių duomenų gauta integruota, laike kintanti informacijos visuma, kurią naudoja analitinio apdorojimo priemonės strateginiams sprendimams paremti. Nors žvaigždės ir snaigės pavidalo saugyklos schemos daugeliui pažįstamos, šiuo metu nėra plačiai paplitusių būdų greitai išgauti tokią schemą iš operacinės duomenų bazės. Tradiciniai saugyklų kūrimo metodai išskaido šį procesą į fazių ar žingsnių seką, kuri trunka per ilgai ir turi keletą rimtų trūkumų: mažai dėmesio skiriama vartotojų poreikiams bei schemos normalizavimui, kurio paskirtis – užtikrinti saugyklos duomenų kokybę ir apsaugoti nuo agregavimo anomalijų. Šiame straipsnyje siekiama apibrėžti duomenų saugyklos konceptų modelį ir kūrimo proceso principus, kurie padėtų sutrumpinti kūrimo laiką bei pagerinti saugyklos schemos kokybę.

1. Įvadas

Duomenų saugykla – kompiuterinė sistema, skirta organizacijos veiklos informacijai saugoti duomenų bazėje. Ši bazė turi būti suprojektuota taip, kad būtų patogu atlikti duomenų analizę ir formuoti ataskaitas, kurių tikslas – gauti strateginę informaciją sprendimams paremti. Esamieji duomenų saugyklų projektavimo procesai trunka pernelyg ilgai ir neužtikrina reikiamos duomenų kokybės. Nors praktikoje duomenų saugyklos naudojamos jau seniai, galima teigti, kad jų projektavimo metodai nėra tokie ištobulinti kaip operacinių duomenų bazių.

Šiame straipsnyje analizuojamas saugyklos konceptų modelis bei jo norminės formos, apibrėžtos [4]. Duomenų saugyklos konceptų modelio tikslas yra aprašyti vartotojų reikalavimus kuriamai saugyklai nepriklausomai nuo technologinių sprendimų. Tai aukšto abstrakcijos lygio modelis, kuris turi būti suprantamas vartotojui. Vartotojų reikalavimai saugyklai, pateikti jiems suprantama forma, turi būti formalūs ir aprašyti taip, kad juos būtų galima vienareikšmiškai transformuoti į loginę schemą [7].

Šis modelis turi užtikrinti bendravimą tarp analitiko ir vartotojo bei ankstyvą projektavimo klaidų aptikimą [5]. Panašiai kaip ir konceptualusis duomenų modelis, saugyklos konceptų modelis yra projektavimo metodologijos dalis, kuri yra įprasta duomenų bazių aplinkoje. Jis gaunamas po vartotojų reikalavimų analizės ir specifikavimo fazės, po kurios seka loginis projektavimas ir realizacija konkrečioje technologinėje aplinkoje.

Straipsnyje nagrinėjama, kaip gauti saugyklos schemą iš konceptualios operacinės duomenų bazės schemos. Konceptualiojo projektavimo metu reikia nustatyti dimensijas, jų hierarchijas, matavimus bei atributų priklausomybes. Pirmiausia reikia nuspręsti, kurie atributai yra dimensiniai, kurie – faktų atributai. Pateikiami grafinio saugyklos konceptų modelio kūrimo proceso principai, padedantys gauti projektuojamą saugyklos schemą daugiamatėje norminėje formoje (DMNF).

Duomenų saugyklų architektūros projektavimo procesas susideda iš keturių nuoseklių fazių: Reikalavimų analizė ir specifikacija. Jei operacinė E/R schema yra prieinama saugyklos architektui, ji duoda

pagrindinę informaciją, apibrėžiančią daugiamatės analizės galimybes. Šioje fazėje verslo sferos ekspertai atrenka strategiškai svarbius operacinės duomenų bazės atributus bei nurodo, kaip jie turėtų būti naudojami –kaip dimensijos ar kaip matavimai. Reikalavimų specifikacija yra dimensinių ir nuo jų priklausančių faktų atributų sąrašas. Papildoma informacija, pavyzdžiui, vientisumo apribojimai, svarbiausios strateginės užklausos, gali būti užrašytos tekstu ir pateiktos kaip priedas.

Konceptuali architektūra. Konceptualios architektūros fazėje atliekamas pusiau formalių veiklos reikalavimų specifikacijos transformavimas į formalizuotą konceptualią daugiamatę schemą. Formalizavimo rezultatai gaunami grafinėje daugiamatėje diagramoje, kurią sudaro faktų schema su atitinkamais matavimais bei dimensijų hierarchijomis. Apibendrinimo apribojimai kiekvienam faktų schemos matavimui pateikiami papildomoje lentelėje.

Loginė architektūra. Loginės architektūros fazėje abstrakčios schemos verčiamos loginėmis, atsižvelgiant į loginį objekto duomenų modelį (dažniausiai reliacinį arba daugiamatį). Loginė schema sukuriama pagal transformavimo taisykles, kurios tinka tik išplėtotoms abstrakčioms diagramoms bei apibendrinimo apribojimams.

Fizinė architektūra. Duomenų saugyklos sudarymas baigiamas loginės schemos įgyvendinimu, atsižvelgiant į savitas objekto duomenų bazės sistemos ypatybes, taip pat ir į optimizavimo metodus: indeksų sudarymą, paskirstymą ir pan. [3].

– 546 –

Duomenų saugyklos konceptų mo

2. Duomenų saugyklos konceptų modelio sąvokos

Pagrindinės saugyklos duomenų struktūros sudėtinės dalys yra faktai ir dimensijos. Faktas susideda iš išmatuojamų reikšmių, saugomų matavimuose, ir kokybinio konteksto, kurį apibrėžia dimensijų lygiai. Kiekvienas dimensijos lygis turi egzempliorių (elementų) aibę. Agregavimo trajektorija yra dimensinių lygių seka, kuri baigiasi galutiniu dimensijos lygiu. Kiekviena dimensija turi bent vieną galutinį dimensijos lygį. Savybės atributas rodo papildomą informaciją, susijusią su dimensiniu lygiu. Savybių atributai gali būti neprivalomi (turėti <null> dydžius. Savybių atributus galima naudoti užklausose rezultatams apriboti, bet negalima naudoti agregavimo lygiams nustatyti. Panaudosime grafinę schemą (1 pav.) schemai išreikšti [1].

s

profesija

veikla

pirkėjoTipas pirkėjoID

p

b

sąskaitosIDsąskaita

metai

laikas

efektyviDiena

mėnuo

ketvirtis

Sąskaita Faktai

s

s♦

1 pav. Konceptuali

Kreivė, susidedanti iš visų dimensijos agregavimohierarchijos klasifikuojamos į du pagrindinius tipus.

Paprastoji hierarchija susideda iš būtent vienos limėnuo!metai dimensijoje laikas). Sudėtinė dimensijųagregavimo trajektorijas (pvz., dimensija sąskaita).

Agregavimo trajektorijų grupė, išsišakojusi paprkiekvienas d elementas priklauso būtent vienam kiekvienoturi du ar daugiau aukštesnių lygių, jog kiekvienam dl kuriam tas elementas priklauso.

Grafinėje notacijoje paprastosios hierarchijos bei paprastomis rodyklėmis, nukreiptomis nuo žemesnio dtrajektorijų grupės žymimos dvigubomis strėlėmis. Privalygiu naudojant rombo simbolį, o pasirenkamasis savybės

Intuityviai aišku, kad agregacijos kartu su įvairiomtą patį rezultatą. Tačiau, jei grupė yra pasirinktinė, tada ag(dalinius) agregavimo rezultatus tarpusavyje nesikertanPažymėtina, kad jei kuris nors elementas ar dimensijos lygvisi duomenys, susiję su tuo elementu, aukštesniajame agrrezultatus. Tam, kad išvengti tokių dalinių žymėjimų, siūlir kiekvieną nepriklausomą žemesnio lygio elementą prisk

2 pav. Konceptual

– 54

pirkėjoAmžiu

pirkėjoVarda

orgID orgGrupe

orgTipas

verslosektoriu

♦ s
palūkanos
ro

a

a

d

n

a e

ailo aisretieoi

i

orgVarda

apyvarta

balansa

kredito riba

produktoTipasduktoID

lansoKlasė

pyvarta

imensinė schema.

trajektorijų, vadinama dimensijos hierarchija. Dimensijų

ijinės agregavimo trajektorijos (pvz., trajektorija diena! hierarchija turi bent dvi skirtingas tos pačios dimensijos

stame dimensijos lygyje d, vadinama alternatyvia, jei aukštesnio lygio elementui. Kai kurie dimensijos lygiai dl lementui yra būtent vienas aukštesnio lygio elementas,

lternatyviosios agregavimo trajektorijų grupės žymimos mensinio lygio į aukštesnį. Pasirenkamos agregavimo mas savybės atributas yra sujungtas su savo dimensijos tributas – be. agregavimo trajektorijomis alternatyvioje grupėje duoda gacijos kartu su įvairiomis trajektorijomis grupėje duoda

iems baigtinio agregavimo lygio elementų poaibiams. s nepriklauso kurio nors aukštesniojo lygio elementui, tai gavimo lygyje prarandami ir užklausos duoda klaidingus ma įterpti <other> elementą į aukštesnį dimensijos lygį, rti elementui <other> aukštesniajam [9].

operacinė schema

7 –

L. Nemuraitė, J. Tonkūnaitė

3. Duomenų saugyklos konceptų modelio kūrimo procesas

Svarbiausia fazė, t.y. konceptualios architektūros fazė, turi sutvarkyti dimensijas, atitinkamas dimensijų hierarchijas, matavimus, bei nustatyti, kurie iš esamų atributų yra faktai, dimensijos, nuo ko jie priklauso ir pan.

Duomenų saugyklos konceptų modelio kūrimo procesas susideda iš trijų kūrimo fazių: kontekstinis matavimų apibrėžimas; dimensinės hierarchijos kūrimas; sumavimo apribojimų apibrėžimas. Kontekstinis matavimų apibrėžimas Atsižvelgiant į matavimų rinkinį M = {m1,...,mk}, apibūdintą vykdant reikalavimų analizę bei dimensinių

atributų rinkinį D, kiekvienas faktas gali būti suvoktas kaip kažkokios funkcijos diagrama, nuo dimensinių lygių iki matavimų. Vadinasi, konceptuali kūrimo fazė prasideda, nustatant funkcines priklausomybes (FDs) tarp dimensinių lygių ir matavimų.

Pirmiausia nustatome (minimalų) raktą Di ⊆ D kiekvienam mi matavimui; tuomet nustatome grupę Fkey susidedančią iš visų Di modelio FDs, taip gaudami Di→mi.

Taigi atsižvelgiant į funkcinę priklausomybę Di→mi ∈Fkey, dimensiniai Di lygiai funkcionaliai apibrėžia mi, bet patys nėra apibrėžiami jokio kito lygio. Vadinasi, jie tampa galutiniais dimensiniais lygiais ir yra naudojami kaip dimensinių hierarchijų pagrindas. Kiekvienam galutiniam dimensiniam lygiui nustatome atitinkamą dimensiją. Šiame pavyzdyje gaunama tokia funkcinė priklausomybė

(sąskaitosID, efektyviDiena)→ balansas ∈ Fkey matavimui balansas. Be to, visi matavimai mi, mj su Di = Dj yra sugrupuojami į tą pačią faktų schemą, kadangi jie dalinasi tuo pačiu

dimensiniu kontekstu. Lentelė 1. FD tarp galutinių dimensijos lygių ir matavimų

Faktų schema

Sąskaitos Faktai

Matavimai

Balansas Apyvarta Kredito riba Palūkanos

Dimensijos

Sąskaita

Laikas

Galutinių dimensijų lygis

SąskaitaID

efektyviDiena

1 lentelėje pateiktas proceso rezultatas, pritaikytas matavimams balansas, apyvarta, kredito riba, ir palūkanos. Visi matavimai yra funkciškai priklausomi nuo tų pačių galutinių dimensinių lygių, t.y. sąskaitosID ir efektyviDiena, kurie savo ruožtu priklauso sąskaita ir laikas dimensijoms. Taigi tai reiškia, jog visi matavimai yra sujungiami į bendrą faktų schemą sąskaitos-faktai. Nuo čia pradedamas grafinis konceptų modelio kūrimas modeliuojant jį iki galutinių dimensinių lygių (Pav.3.).

efektyviDienalaikas

sąskaitosID sąskaita sąskaitos- faktai

kredito riba palūkanosbalansas apyvarta 3 pav. Pradinė konceptų modelio schema.

Dimensinės hierarchijos kūrimas Toliau palaipsniui kiekvienai dimensijai bus formuojamos dimensinės hierarchijos. Šiuo tikslu reikia nustatyti

visas FD (funkcines priklausomybes) tarp dimensijos lygių, priklausančių dimensijai dim kartu su galutine dimensija dj : įsivaizduokime, kad turime dimensinius lygius dk, dl ∈ D t.y. dk →dl yra galiojanti FD bei egzistuoja tokia funkcinė priklausomybė dk, nuo dj, tuomet pridedame dk →dl prie Fdim rinkinio. Pateiktame pavyzdyje sąskaitosID ir efektyviDiena, kaip galutiniai dimensijos lygiai, įeina į faktų schemą sąskaitos-faktai. Pradedant nuo dimensijos laikas galutinio dimensijos lygio, apibrėžiamos tokios funkcinės priklausomybės:

Flaikas = { efektyviDiena → mėnuo, mėnuo → ketvirtis, ketvirtis → metai } Grafiškai išvedame paprastą dimensijų hierarchiją (pateikta Pav. 4.).

– 548 –


metai ketvirtis efektyviDiena laikas mėnuo

4 pav. Dimensijos laikas dimensinė hierarchija

Dimensijos sąskaita dimensiniai lygiai atskleidžia štai tokias funkcines priklausomybes: Fsąskaita = {sąskaitosID → orgID, sąskaitosID → pirkėjoID, sąskaitosID →apyvartosKlasė,sąskaitosID → balansoKlasė, sąskaitosID → produktoID,

produktoID → produktoTipas,

orgID → orgGrupė, orgID → orgTipas, orgID → orgVardas,

orgTipas → verslosektorius,

orgGrupe → verslosektorius,

pirkėjoID → profesija, pirkėjoID →veikla,

pirkėjoID → pirkėjoVardas, pirkėjoID → pirkėjoAmžius

profesija → pirkėjoTipas,

veikla → pirkėjoTipas}

Toliau naudosime kaip pavyzdį dimensiją sąskaita (5 pav.) kompleksinių dimensijų hierarchijų kilmei nustatyti. Visų pirma, remiantis analizės reikalavimais, turi būti atskirti nuosavybės požymiai bei dimensiniai lygiai. Pavyzdžiui, orgVardas ženklina nuosavybės požymį, tačiau agregacijos pagal orgVardas verslo analitikams yra bereikšmės. Taip pat pirkėjoVardas ir pirkėjoAmžius yra laikomi nuosavybės požymiais, tuo tarpu visi likusieji dimensiniai požymiai žymi dimensinius lygius.

Sukurdami tiesioginę diagramą, kurios susikirtimo taškai yra dimensiniai lygiai, apytikriai priartėjame prie dimensinės hierarchijos [10]. Šioje diagramoje pavaizduota riba tarp dimensinio lygio di ir dj, jei di nelygu dj ir di →dj yra nepereinama FD, pvz., jei di →dj lieka ir nesama jokio dimensinio lygio dk (dk ≠ di,dj) tokie kaip di →dk →dj lieka.

Gauta diagrama dabar yra papildoma nuosavybės požymiais: nuosavybės požymis dp yra prijungiamas prie dimensinio lygio dl, jei FD dl →dp yra nepereinanti. Informacija apie nuosavybės požymio būtinumą yra išrenkama iš reikalavimų specifikacijos.

Galiausiai reikia patikrinti ar daugialypės dimensijų hierarchijos turi laisvai pasirenkamų agregavimo kelių grupių [6]. Jei visi dimensiniai lygiai privalomai remiasi reikalavimų specifikacija, tuomet visos agregacijos kelių grupės yra alternatyvinės. Jei kai kurie dimensiniai lygiai yra laisvai pasirenkami (kaip profesija ir veikla pavyzdyje), tuomet šie lygiai pradeda nebūtinų agregacijos grupių kelius.

Sumavimo apribojimų apibrėžimas Ne visos galimos matavimų agregacijos pagal tam tikrą pritaikomumo scenarijų turi prasmę. Konceptų modelis

turėtų numatyti būdų atskirti reikšmingas agregacijas nuo bereikšmių, kadangi ši informacija padeda analitikams formuoti užklausas. Šiuo atveju, saugyklos schema turėtų aiškiai parodyti, kuris matavimas galėtų būti agreguojamas kartu su kokia dimensine hierarchija bei kokia agregacine funkcija remiantis [2].

Remdamiesi pora (m,d), sudaryta iš matavimo m ir dimensinio lygio d, pritaikome 1 apribojimo lygį, jei visos agregavimo funkcijos galėtų būti pritaikytos pakelti m nuo dimensinio lygio d iki bet kurio aukštesnio, funkcionaliai priklausomo lygio.

2 apribojimo lygis yra susijęs su tomis poromis (m,d), kurioms visos agregavimo funkcijos, išskyrus SUM operatorių, yra tinkamos.

apribojimo lygis parodo didžiausią ribotumą, kur agregacija vis dar galima, tačiau tik skaičiavimo sąlygomis (pvz., pastoviems matavimams).

apribojimo lygis nustato, jog negalima vykdyti jokios agregavimo funkcijos. Sekančiame žingsnyje reikia nustatyti apribojimo lygius visiems matavimams kartu su skirtingomis agregavimo

trajektorijomis kiekvienoje faktų schemoje. Kiekvienai porai matavimų ir dimensinių lygių apribojimo lygis nustatomas taip, kad kiekviena daugiamatė užklausa, suformuota remiantis leidžiamomis agregavimo funkcijomis kartu su kiekviena trajektorija, yra reikšminga [8]. Padarome pasirinktą dimensinio lygio apribojimą besąlygiškai galiojantį visiems aukštesniems priklausomiems dimensiniams lygiams. Tai neatima galimybės kitus apribojimus padaryti didesnio lygio atitinkamai aukštesniems dimensiniams lygiams. Šio proceso rezultatai yra išdėstomi sumavimo apribojime (3 lent.), kuris taip pat apima ir matavimų apribojimo lygius faktų schemoje (1 pav.).

– 549 –

L. Nemuraitė, J. Tonkūnaitė

Lentelė 3. Sumavimo apribojimo lygiai.

Apribojimo lygis 1 2 1 1 2 2

Dimensijos lygis

sąskaitosID efektyviDiena sąskaitosID efektyviDiena sąskaitosID efektyviDiena

Matavimai

balansas

apyvarta

Faktų schema Sąskaitos faktai

Matavimas balansas pridedamas dimensiniame lygyje sąskaitaID, taigi jam priskiriame 1 apribojimo lygį

visoms agregavimo trajektorijoms, pradedant nuo sąskaitaID. Susumavę matome, jog balansas yra bereikšmis dimensiniame lygyje efektyviDiena. Kaip ten bebuvę, vidutinės vertės ar kito statistinio skaičiaus analizė yra prasminga, taigi dimensiniam lygiui efektyviDiena yra skiriamas 2 apribojimo lygis.

♦orgVardas

pirkėjoVardas♦pirkėjoAmžius

sąskaita sąskaitosID

apyvarta

balansoKlasė

produktoID produktoTipas

verslosektoriu

orgTipas

orgGrupeorgID

pirkėjoID pirkėjoTipas

veikla

profesija

5 pav. Dimensijos sąskaita hierarchija.

4. Dimensinės schemos apibendrinimas

Dimensinė schema – tai dimensinių atributų grupė D, kur visiems di ∈ D yra dj ∈ D\{di}, taip gauname di →dj arba dj →di modelio FD.

Daugiamatė schema – tai pora M = ({D1,...,Dk}, S), kurioje {D1,...,Dk} yra dimensinių schemų grupė ir S – funkcionaliai apribotas matavimas, atributai iš {D1,...,Dk}.

Dimensinis atributas di € D yra galutinis, jei nėra d ∈ D\{dt}, tuomet d→dt. Dimensinis atributas d D\{d∈ t} yra kategorijos atributas, jei d yra privalomas ir yra d‘∈ D\{dt,d}, taip, kad

d‘→d ar d‘ yra privalomas ir d→d‘; visi kiti atributai yra nuosavybės atributai. Tegul dt – galutinis atributas, dp – nuosavybės atributas, o dc – kategorijos atributas ir visi jie priklauso bendrai

dimensijai. dc elementas c yra dp galimumo kontekstas, jei (a) kiekvienas dt elementas, priklausantis c yra dp vertė ir (b) kiekvienas dt elementas, nepriklausantis c nėra dp reikšmė.

Dimensinė schema D yra įprastame dimensiniame modelyje, jei: a) esama vieno tikslaus galutinio atributo dp ∈ D; b) dt elementai yra išbaigti; c) visi dimensiniai atributai yra privalomi [1]. Daugiamatė schema M = ({D1,...,Dk}, S) yra apibendrintos daugiamatės norminės formos (GMNF), jei

tenkinamos sąlygos: a) kiekvienam nuosavybės požymiui dp ∈ Di egzistuoja kategorijos atributo elementas dc D∈ i, reiškiantis dp

galiojimą; b) kiekviena dimensinė schema, apribota kategorijos atributais, yra dimensinėje norminėje formoje; c) dimensijos yra viena kitai statmenos, t.y. tarp atskirų dimensijų schemų atributų nėra jokių FD. Faktų schema yra GMNF, jei:

– 550 –


– 551 –

a) kiekviena dimensinė hierarchija, nustatyta kuriant abstrakčią konstrukciją, yra dimensinė schema, kuri turi vieną galutinį atributą;

b) dimensijos yra viena kitai statmenos; c) dimensijose be laisvai pasirenkamų hierarchijų visi dimensijų lygiai yra privalomi; d) jei dimensijoje yra laisvai pasirenkamos hierarchijos, tuomet prisijungimo lygio elementai ženklina

nuosavybės atributų galiojimą; e) visi matavimai yra visiškai funkcionaliai apibrėžti galutinių dimensinių lygių rinkiniu.

5. Išvados

Šiame straipsnyje nagrinėjamas konceptualios duomenų saugyklos architektūros projektavimo etapas, artimas operacinių duomenų bazių konceptualiojo projektavimo etapui, tačiau jame yra specifinės savybės, susijusios su strateginės informacijos saugyklų projektavimu.

Saugyklos schemos kokybės kriterijumi gali būti laikoma daugiamatė norminė forma, kuri padeda išvengti duomenų agregavimo anomalijų, panašiai kaip operacinių duomenų bazių norminės formos padeda išvengti duomenų bazių atnaujinimo anomalijų, ir todėl yra vienas svarbiausių aspektų norint užtikrinti teisingas užklausas.

Konceptų modelyje faktų schema gali būti įprastoje bei apibendrintoje daugiamatėje norminėje formoje. Saugyklos konceptų modelio pagrindu būtų galima patobulinti esamus saugyklų projektavimo procesus,

nuosekliai suformuojant saugyklos schemą iš esamos operacinės duomenų bazės ir užtikrinant jo normiškumą.

Literatūros sąrašas

[1] Tryfona N., Busborg F., Christiansen J.G.B. A Conceptual Model for Data Warehouse Design, DCS, 2000. [2] Golfarelli M., Maio D., Rizzi S. Conceptual design of data warehouses from E/R schemes, Proc. 32th HICSS 1998. [3] Hüsemann B., Lechtenbörger J., Vossen G. Conceptual data warehouse design. Proc. DMDW’00 (2000) [4] Golfarelli M., Rizzi S. A methodological framework for data warehousing design, ACMWorkshop on Data

Warehousing and OLAP, 1998. [5] Tryfona N., Busborg F., Christiansen J.. StarER: A Conceptual Model for Data Warehouse Design. Proc. DOLAP’99

(1999). [6] Lehner W., Albrecht J., Wedekind H. Normal forms for multidimensional databases, Proc. 10th SSDBM 1998, 63–

72. [7] Cabibbo L., Torlone R., A logical approach to multidimensional databases, Proc. 6th EDBT 1998, LNCS 1377, 183–

197. [8] Trujillo J., Palomar M., Gómez J. Designing Data Warehouses with OO Conceptual Models. IEEE Computer 34(12),

pp. 66-75, 2001. [9] Kimbal R., Reeves L., Ross M., Thornthwaite W.. The Data Warehouse Lifecycle Toolkit: Expert Methods for

Designing, Developing, and Deploying Data Warehouses. John Wiley & Sons, February 1998. [10] Theodoratos D., Bouzeghoub M. A general framework for the view selection problem for data warehouse design and evolution. In Proc. of the 3rd ACM Int. Workshop on Data Warehousing and OLAP, DOLAP, 2000.

Data Warehouse Concept Model

Modeling data warehouses is a complex task focusing, very often, into internal structures and implementation issues. In this paper, it is argued that, in order to accurately reflect the users requirements into an error-free, understandable, and easily extendable data warehouse schema, special attention should be paid at the conceptual modeling phase. Based on a real world example, we present a set of user modeling requirements and we discuss the involved concepts. Understanding the semantics of these concepts, allow us to build a conceptual model.

KONCEPTUALIOJO MODELIO VIENTISUMO APRIBOJIMŲ TAKSONOMIJA

Lina Nemuraitė, Elita Miliauskaitė

Kauno technologijos universitetas, Studentų g. 50

Geros kokybės konceptualusis modelis turi būti išsamus, semantiškai turtingas, turi tenkinti normines formas. Šiame straipsnyje pateikta šiam tikslui skirta konceptualiųjų modelių vientisumo apribojimų aibė, kurios elementai apibrėžiami natūralia kalba bei UML diagramomis su OCL išraiškomis. Apribojimams, kurie neturi grafinių žymėjimų UML klasių diagramoje, siūloma įvesti papildomus stereotipus ir žymėjimus, kad būtų galima padidinti grafiškai vaizduojamų apribojimų aibę. Pateiktas sudarytas konceptualiojo modelio metamodelis, kuriame pavaizduoti pagrindiniai jo elementai bei vientisumo apribojimai.

1 Įvadas Informacinės sistemos (IS) kūrimo analizės etape konceptualieji modeliai naudojami aprašyti dalykinės srities struktūroms bei vientisumo apribojimams, kurie yra neatskiriama konceptualiosios schemos dalis. Vientisumo apribojimai susiję su duomenų modelio korektiškumu, jo gebėjimu teisingai atspindėti dalykinės srities semantiką, ir yra nagrinėjami visuose žinomuose konceptualiojo modeliavimo metoduose. Transformuoti į DBVS vientisumo apribojimų užtikrinimo sistemą, jie apsaugo nuo neleistinų, atsitiktinių duomenų pakeitimų, kurie gali iššaukti nepageidaujamas situacijas funkcionuojančioje informacinėje sistemoje. Esant didelėms, sudėtingoms dalykinėms sritims, saugančioms daug įrašų ir turinčioms daug apribojimų, iškyla eilė problemų, susijusių su jų valdymu, kadangi pertekliniai apribojimai blogina veikimą, o prieštaringi ar konfliktiniai apribojimai iššaukia klaidas ir begalinius ciklus [12], [13]. Konceptualusis modelis su vientisumo apribojimais yra semantiškai prasmingas, jeigu vientisumo apribojimai suderinti tarpusavyje ir nėra jų pertekliaus.

Vientisumo apribojimai laikomi suderintais, jeigu pereidama iš vienos būsenos į kitą informacinė sistema išlieka leistinoje būsenoje. Vientisumo apribojimas laikomas pertekliniu, jeigu jis dengiasi su kitų vientisumo apribojimų aibe arba niekada nebus pažeidžiamas. Nėra tokių metodų, kurie galėtų garantuoti pilną duomenų modelio suderinamumą, tačiau galima rasti tam tikrų tipų nesuderinamumus.

Konceptualiajame me modelyje vientisumo apribojimas yra loginė formulė, priklausoma nuo dalykinės srities, ir ji turi galioti visoms prasmingoms informacinės sistemos būsenoms. Vientisumo apribojimai gali būti realizuojami 2 būdais: taikomosiomis programomis ir DBVS priemonėmis. Duomenų bazėje vientisumo apribojimas yra schemoje specifikuota sąlyga, kuri apriboja galimus saugoti duomenis. Šio darbo tikslas yra sudaryti išsamų konceptualiojo duomenų modeliavimo metodą, apimantį dalykinės srities esybių, ryšių ir struktūrinių apribojimų klasifikaciją, jų vaizdavimo taisykles bei situacijas, kada modelyje reikia įvesti tam tikrų tipų apribojimus; sukurti metodus ir priemones konceptualiojo modelio apribojimų suderinamumui patikrinti; galiausiai, pasiūlyti šiuo metu plačiai naudojamos programų sistemų modeliavimo kalbos UML [17], [18] profilį konceptualiesiems modeliams vaizduoti bei jų transformacijas į reliacinių duomenų bazių schemas. Toks profilis reikalingas todėl, kad šiuo metu nėra patvirtinto UML duomenų modeliavimo profilio, kuris leistų aprašyti duomenų struktūras loginiame lygmenyje, o praktiškai naudojami duomenų modeliavimo profiliai neturi galimybių apribojimams vaizduoti, lygiai kaip ir UML CASE įrankiuose įdiegtos DB schemų generavimo priemonės nesugeba sugeneruoti trigerių ir check funkcijų.

Mūsų požiūriu, dalykinės srities apribojimus reikia specifikuoti ne loginio, bet konceptualiojo modeliavimo etape, kadangi jie vaidina svarbų vaidmenį ne tik duomenų bazių schemų, bet ir programų, XML, tinklo paslaugų bei kitų artefaktų projektavime, kurį daugeliu atvejų galima atlikti automatiškai, tam naudojant vieną ir tą patį konceptualųjį modelį. Tai sumažintų atotrūkį tarp duomenų bazių ir programinės įrangos projektavimo, kuris susiklostė istoriškai ir tebeegzistuoja dabar, kadangi remiasi skirtingomis technologijomis.

Kitas svarbus šio darbo motyvas yra didėjantys reikalavimai duomenų modelio kokybei. To reikalauja su DBVS susisiejančios sritys – duomenų saugyklos (Data Warehouses) ir OLAP, paskirstytųjų duomenų bazių integravimas, ateinančios semantinio žiniatinklio technologijos. Geros kokybės duomenų modelis turi ne tik adekvačiai atspindėti dalykinę srities semantiką, bet ir tenkinti tam tikras normines formas. Norminės formos [8] liečia ne tik duomenų struktūras, bet ir vientisumo apribojimus, kurie yra pirmos klasės konceptualiojo modelio konceptai. Išanalizavus ryškiausius konceptualiojo modeliavimo metodus P.Chen Esybių Ryšių (ER) modelį [8], [9], Hainaut išplėstąjį ER (EER) [14], [19], B.Thalheim Higher-Order ER (HERM) [10], B.Paradausko Object Property (OP) [5], T.Halpin Object-Role Modeling (ORM) [1] [2] [4] [6] [11] ir L.Starr Executable UML [16], sudaryta vientisumo apribojimų taksonomija, apimanti gana didelę šių apribojimų tipų aibę. Kiekvienas

– 552 –

Konceptualiojo modelio vientisumo apribojimų taksonomija

apribojimas aprašytas tipine OCL išraiška, pasiūlyti UML stereotipai, kurie turėtų palengvinti apribojimų užrašymą bei generavimą (kiekvieno tipo apribojimas transformuojamas pagal tam tikrą šabloną). Šio straipsnio 2 skyriuje yra pateikiami konceptualiojo modeliavimo metoduose nagrinėjami vientisumo apribojimų tipai bei jų specifikavimas UML diagramose OCL išraiškomis, siūlomi stereotipai; 3 skyriuje nagrinėjamos tipinės situacijos, reikalaujančios vientisumo apribojimų; 4 skyriuje apibendrinama atlikta analizė, pateikiant vientisumo apribojimų taksonomiją.

2 Apribojimai Šiame skyriuje aprašomi vientisumo apribojimų tipai, kurie turėtų būti nagrinėjami sudarant geros kokybės konceptualųjį modelį.

2.1 Pirminio identifikatoriaus apribojimas Šis apribojimas naudojamas unikaliai identifikuoti esybės tipo objektui iš tam tikro esybės tipo

objektų aibės [1], [4], [6], [9]. Jis reikalauja, kad identifikuojantis atributas arba atributų grupė visada turėtų reikšmes ir kad šios reikšmės būtų unikalios.

Apribojimo kontekstas. Apribojimas naudojamas atributui arba atributų grupei. Apribojimo apibrėžimas tipine OCL išraiška. 1 paveiksle (a) pateikto apribojimo OCL išraiška:

context Asmuo inv:self->exists(a1,a2:Asmuo|a1.asmensKodas=a2.asmensKodas implies a1=a2)

Apribojimo pavyzdys. Esybės „Asmuo“ identifikatoriumi gali būti atributas „AsmensKodas“, kadangi jis unikaliai identifikuoja asmenį. Esybės „Kambarys“ identifikatoriumi atributas „KambarioNumeris“ negali būti, kadangi jis yra unikalus tik tam tikro pastato kontekste. Todėl esybės „Kambarys“ identifikatorius turėtų būti atributai „KambarioNumeris“ ir „PastatoNumeris“.

Apribojimo vaizdavimas UML. UML neturi specialios grafinės notacijos pirminiam identifikatoriui žymėti, kadangi objektinėje metodologijoje kiekvienas klasės egzempliorius pagal nutylėjimą identifikuojamas sistemos suteikiamu identifikatoriumi, kuriuo gali būti atminties adresas arba objekto identifikatorius (oid) [4]. Tačiau konceptualiajame modelyje dažnai reikalingas matomas, atributais išreikštas identifikatorius, o papildomas identifikatorius arba oid gali būti naudojamas realizacijos lygmenyje. Tokiais atvejais pirminis identifikatorius turėtų būti naudojamas konceptualiajame modelyje, jam žymėti galima įvesti nestandartinę grafinę notaciją – UML stereotipą. [4], [6] identifikatoriaus atributus siūlo žymėti {P}. 1(a) paveiksle pirminis identifikatorius sudarytas iš vieno atributo „AsmensKodas“, 1(b) – iš dviejų. Toks žymėjimas neįpareigoja šiuos atributus reliacinėje schemoje naudoti kaip pirminį raktą, daugiau tai tik pažymi veiklos sprendimą. Tačiau identifikatoriaus apribojimas reikalauja, kad ši atributų grupė būtų unikali.

AsmensKodas {P}VardasPavardėAdresasTelefonas

Asmuo

KambarioNumeris {P}PastatoNumeris {P}KambarioTipas

Kambarys

PastatoNumeris {P}PastatoPavadinimas

Pastatas-priklauso

*

-turi

1

a b

1 pav. Pirminio identifikatoriaus apribojimas atributui (a) ir atributų grupei (b).

2.2 Paprastas būtinumo apribojimas. Šis apribojimas naudojamas atributo arba esybės tipo objekto atliekamos rolės būtinumui pažymėti [1],

[2], [4], [6]. Atributo būtinumas rodo, kad visose leistinose informacinės sistemos būsenose esybės tipo objekto atributas būtinai turi turėti reikšmę. Pažymėjimas, kad esybės tipo objektas būtinai atlieka tam tikrą rolę, rodo, kad objektas gali egzistuoti tik ryšyje su kita esybe.

Apribojimo kontekstas. Apribojimas naudojamas atributui arba ryšiui tarp esybių. Apribojimo apibrėžimas tipine OCL išraiška. Paprasto būtinumo apribojimas išreiškiamas grafiškai

(pagal nutylėjimą UML atributai yra privalomi, rolės būtinumas žymimas, nurodant minimalų kardinalumą „1”), todėl OCL išraiškų jam nereikia..

Apribojimo pavyzdys. Esybės tipo objektas „Knyga“ identifikuojamas knygos atributu „Numeris“ ir turi tris paprasto būtinumo apribojimus (2 pav.). Tai reiškia, kad visi esybės „Knyga“ egzemplioriai turi turėti apibrėžtas atributų „Pavadinimas“, „Tipas“ ir „Leidykla“ reikšmes.

– 553 –

L. Nemuraitė, E. Miliauskaitė

Norint pažymėti, kad kiekviena knyga būtinai turi turėti autorių, reikia naudoti privalomą rolės apribojimą. Žodelis „būtinai“ sako, kad esybės „Knyga“ egzemplioriai privalo turėti ryšį su esybės „Autorius“ egzemplioriais ir negali egzistuoti esybės „Knyga“ egzempliorių, neturinčių ryšio su esybės „Autorius“ egzemplioriais, t.y. esybė „Knyga“ turi privalomo ryšio apribojimą su esybe „Autorius“. Jis nurodo, kad esybėje „Knyga“ išorinio ryšio atributas „Autorius“ tampa privalomu, jeigu knyga gali turėti tik vieną autorių. Jeigu knyga gali turėti kelis autorius, tuomet tarp esybių „Knyga“ ir „Autorius“ egzistuoja m:n ryšys, kuris yra privalomas esybei „Knyga“.

Apribojimo vaizdavimas UML. Pagal nutylėjimą visi UML objektų atributai laikomi privalomais. Prie atributų pridėtas pažymėjimas [0..1] rodo, kad atributas yra neprivalomas [11]. 2 paveiksle parodyta, kad objektas „Knyga“ turi neprivalomus atributus: „PuslapiųSkaičius“ ir „LeidybosMetai“, o atributai: „Pavadinimas“, „Tipas“ ir „Leidykla“ yra privalomi.

Asociacijos būtinumo apribojimas yra vaizduojamas kartu su asociacijos kardinalumo (dažnumo) apribojimu. Pažymėjimas 1..* arba 1..1 nurodo, kad ryšys yra privalomas. Paveiksle 2 pavaizduota, kad ryšys yra privalomas objektui „Knyga“, o „Autorius“ objektui jis yra neprivalomas.

Numeris {P}PavadinimasTipasLeidyklaPuslapiųSkaičius [0..1]LeidybosMetai [0..1]

Knyga

VardasPavardėGimimoData [0..1]

Autorius

0..* 1

2 pav. Paprasto būtinumo apribojimas atributams ir asociacijai.

2.3 Disjunktyvaus būtinumo apribojimas. Šis apribojimas rodo, kad esybės atributų būtinumas yra paskirstomas keliems atributams, t.y. visose

leistinose IS būsenose bent vienas iš esybės atributų, kuriems nurodytas disjunktyvaus būtinumo apribojimas, būtinai turi turėti reikšmę [1], [4], [6].

Apribojimo kontekstas. Šis apribojimas naudojamas neprivalomiems esybių atributams. Apribojimo apibrėžimas tipine OCL išraiška.

context Darbuotojas inv:not(self.PasoNr isUndefined()) or not(self.SocDraudimoNr isUndefined())

Apribojimo pavyzdys. Esybės tipo objektas „Darbuotojas“ identifikuojamas darbuotojo atributu „Numeris“ ir dviem neprivalomiems atributams „PasoNumeris“ ir „SocDraudimoNr“ nurodytas disjunktyvaus būtinumo apribojimas. Šis apribojimas nurodo, kad bent vienas iš šių atributų privalo turėti reikšmę, t.y. kiekvienam darbuotojui turi būti nurodytas arba paso numeris arba socialinio pažymėjimo numeris.

Apribojimo atvaizdavimas su UML. UML neturi grafinės notacijos pažymėti disjunktyviam būtinumo apribojimui. Šis apribojimas gali būti išreiškiamas ne formaliai arba tam tikra formalia kalba kaip pastaba prie apribojamo objekto (žr. paveikslą 3(a)). Norint šį apribojimą pavaizduoti grafiškai, reikia papildyti UML notaciją, įvedant papildoma pažymėjimą {Dindeksas}. Indeksas žymi skirtingas atributų grupes. Objekto „Darbuotojas“ atveju, yra tik viena atributų grupė {„PasoNr“ ir „SocDraudimoNr“}, kuriai naudojamas disjunktyvaus būtinumo apribojimas, todėl indeksas lygus vienam (žr. paveikslą 3(b)).

Numeris {P}Vardas [0..1]PavardėAdresas [0..1]Pareigos [0..1]GimimoDataPasoNr [0..1]SocDraudimoNr [0..1]

Darbuotojas

{PasoNr ne tuščia reikšmėarbaSocDraudimoNr ne tuščia reikšmė}

Numeris {P}Vardas [0..1]PavardėAdresas [0..1]Pareigos [0..1]GimimoDataPasoNr {D1}SocDraudimoNr {D1}

Darbuotojas

– 554 –


a b

3 pav. Disjunktyvaus būtinumo apribojimo žymėjimas kaip pastaba objektui (a) ir žymėjimas specialiu simboliu (b).

2.4 Unikalumo apribojimas. Unikalumo apribojimas rodo, kad esybės egzempliorių aibėje bet kurių dviejų egzempliorių atributų

reikšmės yra skirtingos [1], [4], [6]. Apribojimo kontekstas. Šis apribojimas naudojamas atributui arba jų grupei. Apribojimo apibrėžimas tipine OCL išraiška. 4 paveiksle (a) pateikto apribojimo OCL išraiška:

context Šalis inv:self->exists(s1,s2:Šalis|s1.pavadinimas=s2.pavadinimas implies s1=s2)

Apribojimo pavyzdys. Jei esybės tipo objektas „Šalis“, identifikuojamas atributu „SKodas“, turi unikalumo apribojimą atributui „Pavadinimas“, negali egzistuoti kelių šalių, turinčių tokį patį pavadinimą. Unikali gali būti ne tik vieno atributo reikšmė, bet ir kelių atributų reikšmių kombinacija. Pavyzdžiui, esybė „Tvarkaraštis“ turi užtikrinti, kad tam tikram kabinete tam tikru laiku vyktų tik vienas užsiėmimas. Tuomet bet kurių dviejų esybės „Tvarkaraštis“ atributų „Laikas“, „KabinetoNr“ ir „Užsiėmimas“ reikšmių kombinacija turi būtų unikali.

Apribojimo vaizdavimas UML. UML neturi specialios grafinės notacijos unikalumo apribojimui žymėti. [14] siūloma unikalius atributus žymėti paryškintu šriftu, tačiau taip negalima pažymėti atributų grupės reikšmių unikalumo, kadangi vienoje esybėje gali būti kelios grupės, kurioms turi būti užtikrintas unikalumas. Todėl siūloma išplėsti UML notaciją, šalia atributų pridedant tekstinį apribojimo pažymėjimą {Ui}. Indeksas ir nurodys grupes, kuriose atributų reikšmių kombinacijos turi būti unikalios. 4 (a) paveiksle pavaizduotas atributo unikalumo apribojimas. 4(b) paveikslas iliustruoja unikalumo apribojimą atributų grupei.

SKodas {P}Pavadinimas {U1}Kalba [0..1]Santvarka [0..1]

Šalis

Laikas {U1}KabinetoNr {U1}Užsiėmimas {U1}Pastaba [0..1]

Tvarkaraštis

a b

4 pav. Unikalumo apribojimas atributui (a) ir jų grupei (b).

2.5 Išorinio unikalumo apribojimas. Šis apribojimas neformaliai gali būti apibrėžiamas panašiai kaip unikalumo apribojimas skirtingų

esybių atributams [1], [4], [6]. Konceptualiai sujungtų atributų reikšmės turi būti skirtingos visoje konceptualiai sujungtų atributų reikšmių aibėje.

Apribojimo kontekstas. Šis apribojimas naudojamas atributams iš skirtingų esybių. Apribojimo apibrėžimas tipine OCL išraiška. 4 paveiksle pateikto apribojimo OCL išraiška:

context Miestas inv:self->exists(m1,m2:Miestas|m1.Šalis.skodas=m2.Šalis.skodas and m1.mkodas=m2.mkodas implies m1=m2)

Apribojimo pavyzdys. Esybės „Šalis“ atributo „SKodas“ reikšmė poroje su esybės „Miestas“ atributo „MKodas“ reikšme unikaliai identifikuoja miestą. Šalies kodas paprastai identifikuoja šalį (pvz., Australijos šalies kodas yra 61), tačiau ne visada (pvz., ir Jungtinių Amerikos Valstijų ir Kanados kodas yra 1). Tačiau šalies kodas ir miesto kodas unikaliai identifikuoja miestą (pvz., šalies kodas 61 ir miesto kodas 7 identifikuoja Australijos miestą Brisbane). Šiuo atveju skirtingų esybių konceptualiai sujungtų atributų reikšmių poros turi būti unikalios.

Apribojimo vaizdavimas UML. 5(a) paveiksle parodytas tokio apribojimo pavyzdys.

– 555 –


SKodasPavadinimas {U1}Kalba [0..1]Santvarka [0..1]

ŠalisMKodasPavadinimasDydis [0..1]Gyventojų sk . [0..1]

Miestas

1 1..*

Kiekviena miesto kodo ir šalies kodo kombinacija yra asocijuojama tik su viena šalimi ir tik vienu tos šalies miestu .

SKodas {EU1}Pavadinimas {U1}Kalba [0..1]Santvarka [0..1]

ŠalisMKodas {EU1}PavadinimasDydis [0..1]Gyventojų sk . [0..1]

Miestas

1 1..*

a b

5 pav. Išorinio unikalumo apribojimo žymėjimas pastaba objektui (a) ir naudojant specialius pažymėjimus (b).

UML neturi specialios grafinės notacijos išorinio unikalumo apribojimams žymėti, todėl siūloma tam naudoti neformalų komentarą pastaboje prie atitinkamų modelio elementų. Komentarą galima pakeisti OCL kalbos išraiška.

5(b) paveiksle pavaizduota UML klasių diagrama su siūlomu UML notacijos išplėtimu, skirtu grafiškai žymėti išorinio unikalumo apribojimą {EUi} šalia atributų, kurie dalyvauja šiame apribojime. Indeksas leidžia atskirti išorinio unikalumo apribojamas atributų grupes.

2.6 Atributo reikšmės apribojimas. Šis apribojimas naudojamas apriboti atributo įgyjamų reikšmių aibę išvardinant visas galimas

įgyti reikšmes, nurodant įgyjamų reikšmių intervalą specifikuojant intervalo pradžią ir pabaigą [1], [4], [6]. Taip pat galimi įvairūs mišrūs variantai.

Apribojimo kontekstas. Šis apribojimas naudojamas esybės atributams. Apribojimo apibrėžimas tipine OCL išraiška. Apribojimo pavyzdys. Atributas „Lytis“ gali įgyti tik dvi reikšmes: „M“, jeigu asmuo yra moteriškos

lyties ir „V“ jeigu vyriškos. Egzamino atributas „Rezultatas“ gali įgyti reikšmę iš galimų reikšmių intervalo {1..10}.

Apribojimo atvaizdavimas su UML. UML‘e išvardinamų reikšmių sąrašas gali būti modeliuojamas kaip <<enumeration>> stereotipo klasė [14], [15], kurioje atributai yra išvardintos reikšmės (žr. paveikslą 6(a)). Intervalai ir mišrios kombinacijos gali būti deklaruojamos kaip tekstiniai apribojimai šalia atributo. Pavyzdys reikšmės apribojimo pateikiant galimų reikšmių intervalą yra pateikiamas 6(b) paveiksle.

MV

«enumeration»LytiesTipas

-Pavadinimas-Data-Rezultatas {reikšmė iš intervalo 1..10}-Pastaba [0..1]

Egzaminas

a b

6 pav. Išvardinamų reikšmių sąrašo modeliavimo UML‘e pavyzdys (a) ir reikšmių intervalo modeliavimo UML klasių diagramoje pavyzdys (b).

2.7 Ekvivalentiškumo apribojimas. Ekvivalentiškumo apribojimas tarp esybės ryšių su kitomis esybėmis nurodo, kad jeigu esybės

egzempliorius dalyvauja viename ryšyje, tai jis būtinai turi dalyvauti ir kitame [14], [1], [4], [6]. Esybės egzemplioriui dalyvauja viename iš ryšių, kitas ryšys tampa privalomu. Analogiškai ekvivalentiškumo apribojimas tarp atributų nurodo, kad jeigu vienas iš atributų įgyja reikšmę tai būtinai ir kitas atributas turi įgyti reikšmę, t.y. įgijus reikšmę vienam iš atributų, kitas atributas irgi tampa privalomu. Ekvivalentiškumo apribojimas galimas ir tarp atributo bei ryšio tarp esybių, tačiau šis atvejis yra išvestinis iš prieš tai pateiktų dviejų ir labai specifinis, todėl toliau jo nenagrinėsim.

Apribojimo kontekstas. Šis apribojimas naudojamas neprivalomiems esybių atributams arba ryšiams. Apribojimo pavyzdys. Išmatavus žvaigždės danguje padėtį yra nustatomos visos trys koordinatės: x, y

ir z arba nenustatoma nė viena. Tuomet esybės „Žvaigždė“ atributai „Xkoordinatė“, „Ykoordinatė“ ir „Zkoordinatė“ turi ekvivalentiškumo apribojimą. Taigi, visuose esybės egzemplioriuose arba visi atributai turi reikšmes arba nė vienas.

– 556 –


Apribojimo vaizdavimas UML. UML ekvivalentiškumo apribojimą specifikuoja kaip tekstinį apribojimą pastaboje objektui. Apribojimo pavyzdys standartine UML būtų modeliuojamas kaip pateikta 7(a) paveiksle. 7(b) paveiksle pavaizduotas UML grafinės notacijos išplėtimas įvedant ekvivalentiškumo apribojimo žymėjimą neprivalomų atributų grupei {equi}. Čia indeksas naudojamas atskyrimui atributų grupių. Apribojimo pažymėjimą siūloma žymėti šalia atributų.

2.8 Poaibio apribojimas. Poaibio apribojimas tarp dviejų esybės ryšių su kitomis esybėmis nurodo, kad aibė esybės egzempliorių dalyvaujančių abiejuose ryšiuose yra poaibis esybės egzempliorių dalyvaujančių viename ryšyje. Analogiškai poaibio apribojimas tarp dviejų esybės egzempliorių nurodo, kad aibė esybės egzempliorių su atributų reikšmėmis yra poaibis esybės egzempliorių turinčių reikšmes tik dalies atributų [5], [11], [4], [6].

Apribojimo kontekstas. Šis apribojimas naudojamas neprivalomiems esybės atributams arba nebūtiniems esybės ryšiams.

PavadinimasXkoordinatė [0..1]Ykoordinatė [0..1]Zkoordinatė [0..1]

Žvaigždė

{Xkoordinatė reikšmė tuščiairYkoordinatė reikšmė tuščiairZkoordinatė reikšmė tuščiaarbaXkoordinatė reikšmė tuščiairYKoordinatė reikšmė tuščiairZkoordinatė reikšmė tuščia}

PavadinimasXkoordinatė [0..1] {equ1}Ykoordinatė [0..1] {equ1}Zkoordinatė [0..1] {equ1}

Žvaigždė

a b

7 pav. Ekvivalentiškumo apribojimo neprivalomų atributų grupei žymėjimas pastaboje (a) ir specialiu simboliu (b).

Apribojimo apibrėžimas tipine OCL išraiška. 7 paveiksle (a) pateikto apribojimo OCL išraiška: context Studentas inv: not(self.vardas.isUndefined()) implies not(self.pavarde.isUndefined())

7 paveiksle (c) pateikto apribojimo OCL išraiška: context Asmuo inv: self.susideda->notEmpty() implies self.susideda-> includesAll(self.vadovaujamas) context Komitetas inv: self.narys-> includes(self.vadovauja)

Apribojimo pavyzdys. Apribojimas, kad registruojant studentus nurodomas vardas tik tuo atveju, jeigu yra nurodoma ir pavardė, yra vadinamas poaibio apribojimu tarp esybės egzempliorių. Šiuo atveju esybės „Studentas“ egzempliorių su nurodytais vardais aibė yra poaibis aibės esybės „Studentas“ egzempliorių su nurodytomis pavardėmis.

Poaibio apribojimas tarp esybės „Studentas“ ir „Kursas“ ryšių, apibrėžia, kad studentas gali laikyti kurso egzaminus, jeigu jis užsisakė tą kursą. Vadinasi studento atsiskaitytų kursų aibė yra poaibis jo užsisakytų kursų aibės.

Poaibio apribojimas tarp esybės „Asmuo“ ir „Komitetas“ ryšių, apibrėžia, kad asmuo vadovaujantis komitetui turi būti jos nariu. Vadinasi komitetui vadovaujančių asmenų aibė yra poaibis komitetą sudarančių asmenų aibės.

Apribojimo atvaizdavimas UML. UML galima grafiškai pavaizduoti poaibio apribojimą tarp asociacijų sujungiant jas punktyrine linija su rodykle ir šalia jos pridedant apribojimo pažymėjimą {subset}. Rodyklė nukreipiama iš asociacijos, kuri yra poaibis egzempliorių dalyvaujančių asociacijoje į kurią rodo rodyklė (žr. paveikslą 7(c)).

Tačiau UML neturi grafinės notacijos pažymėti poaibio apribojimui tarp objekto egzempliorių. Apribojimą, kad studentų, turinčių vardo reikšmę, aibė yra poaibis studentų, turinčių pavardės reikšmę, UML galima pažymėti kaip pastabą objektui „Studentas“ (7 pav., a). Šiam apribojimui žymėti grafiškai siūloma pridėti tekstinį apribojimą {subset} šalia punktyrine rodykle žymimos asociacijos į tą patį objektą. Šalia atributų,

– 557 –


apibrėžiančių poaibį, nurodomas apribojimas {subseti}, o šalia atributų, apibrėžiančių aibę, nurodomas apribojimas {seti}. Indeksas naudojamas, kai yra kelios priklausomybės tarp atributų grupių (7 pav., b).

2.9 Išskirtinumo apribojimas. Išskirtinumo apribojimas tarp esybės ryšių su kitomis esybėmis rodo, kad tas pats esybės egzempliorius gali dalyvauti tik viename iš kelių ryšių su kitos esybės objektais. Analogiškai išskirtinumo apribojimas tarp esybės atributų rodo, kad iš kelių neprivalomų esybės egzemplioriaus atributų reikšmę gali turėti tik vienas [5], [11], [4], [6].

Apribojimo kontekstas. Šis apribojimas naudojamas neprivalomiems esybių atributams arba ryšiams.

NumerisVardas [0..1]Pavardė [0..1]Adresas [0..1]

Studentas

{"Pavardė" turi ne tuščią reikšmęarba"Vardas" turi tuščią reikšmę}

NumerisVardas [0..1] {subset1}Pavardė [0..1] {set1}Adresas [0..1]

STUDENTAS

{subset}

AsmensKodas {P}VardasPavardė [0..1]Adresas [0..1]

Asmuo

PavadinimasVeikla

Komitetas

-narys

1..*

-susideda

0..*

-vadovauja

1

-vadovaujamas

0..*

{subset}

a b c

7 pav. Poaibio apribojimo žymėjimas pastaboje objektui pavyzdys (a) ir poaibio apribojimo klasės egzemplioriui pavyzdys (b) ir poaibio apribojimo asociacijoms žymėjimas specialiu apribojimu pavyzdys (c).

Apribojimo apibrėžimas tipine OCL išraiška. 8 paveiksle (a) pateikto apribojimo OCL išraiška: context Bauda inv: self.apmokejimoData.isUndefined() implies not(self.anuliavimoData.isUndefined()) and self.anuliavimo data.isUndefined() implies not(self.apmokejimoData.isUndefined()) inv: not(self.apmokejimoData.isUndefined()) implies not(self.kvitoNr.isUndefined())

8 paveiksle (c) pateikto apribojimo OCL išraiška: context Knyga inv: self.recenzentas->notEmpty() implies not(self.autorius->includesAll(self.recenzentas)) context Autorius self.recenzuota->notEmpty implies (if self.parasyta->notEmpty() then not( self.parasyta->includes(self.recenzuota)) endIf)

Apribojimo pavyzdys. Sumokėjus baudą už kelių eismo taisyklių pažeidimą, nurodoma sumokėjimo data; baudą anuliavus, nurodoma baudos anuliavimo data ir priežastis. Šiuo atveju esybės „Bauda“ atributų grupei „AnuliavimoData“ ir „Priežastis“ bei atributų grupei „ApmokėjimoData“, „KvitoNr“ turi būti taikomi ekvivalentiškumo apribojimai, o atributams „AnuliavimoData“ ir „SumokėjimoData“ turi būti taikomas dar ir išskirtinumo apribojimas.

Išskirtinumo apribojimas tarp ryšių naudojamas užtikrinti, kad knyga negali būti parašyta ir recenzuota to paties asmens. Tokiu atveju skirtingi esybės „Asmuo“ egzemplioriai turi dalyvauti sąryšiuose su esybės „Knyga“ egzemplioriumi.

Apribojimo atvaizdavimas su UML. UML turi specialų grafinį pažymėjimą išskirtinumo apribojimui tarp asociacijų. Jis žymimas sujungiant asociacijas punktyrine linija ir prie jos pridedant tekstinį apribojimą {xor}. Paveiksle 8(c) pavaizduota kaip UML klasių diagramoje būtų galima sumodeliuoti išskirtinumo apribojimą tarp esybių KNYGA ir ASMUO asociacijų. Tai leistų užtikrinti, kad visiems klasės KNYGA ir ASMUO objektams būtų teisingas tik vienas teiginys: tas asmuo parašė tą knygą arba tas asmuo recenzavo tą knygą, tačiau negali būti taip, kad abu teiginiai būtų teisingi.

Išskirtinumo apribojimas atributams UML užrašomas tekstiniu apribojimu arba OCL išraiška (8 pav., (a)). Norint grafiškai pažymėti išskirtinumo apribojimą atributams, reikia įvesti nestandartinį UML išplėtimą {xori} šalia atributų, kuriems taikomas šis apribojimas. Indeksas leidžia atskirti atributų grupes, kurioms

– 558 –


taikomas išskirtinumo apribojimas. Toks grafinis apribojimo žymėjimas pavaizduotas paveiksle 8(b). Klasės „Bauda“ objektai gali turėti baudos anuliavimo datą arba baudos apmokėjimo datą, tačiau negali egzistuoti objektų su abiem nurodytomis datomis.

NumerisPažeidimasApmokėjimoDataKvitoNrAnuliavimoData

Bauda

{"ApmokėjimoData" reikšmė yra tuščiaarba"AnuliavimoData" reikšmė yra tuščia}

NumerisPažeidimas {equ1}Anuliavimo data {equ1} {xor1}ApmokėjimoData {equ2}{xor1}KvitoNr {equ2}

Bauda

Numeris {P}PavadinimasTipasLeidyklaPuslapių sk. [0..1]Leidybos metai [0..1]

KNYGA

Asmens kodas {P}VardasPavardėGim.data [0..1]

ASMUO

-parašyta 10..*

-recenzuota11

{xor}

a b c

8 pav. Išskirtinumo apribojimo pažymėjimas pastaboje objektui pavyzdys (a) ir išskirtinumo apribojimo atributams žymėjimas specialiu apribojimu pavyzdys (b) ir išskirtinumo apribojimo asociacijoms žymėjimas specialiu apribojimu pavyzdys (c).

2.10 Specializacijos/apibendrinimo ryšio apribojimai. Galimi keli apibendrinimo ir potipių apribojimo atvejai [5]: • Jeigu potipių esybių egzemplioriai tarpusavyje nepersidengia ir pilnai apima supertipo esybės

egzempliorių aibę, tuomet specializacijos/apibendrinimo ryšys vadinamas suskaidymo; • Jeigu potipių esybių egzemplioriai tarpusavyje nepersidengia, tačiau pilnai nepadengia supertipo

esybės egzempliorių aibės, tuomet specializacijos/apibendrinimo ryšys vadinamas išskirtinumo; • Jeigu potipių esybių egzemplioriai tarpusavyje persidengia ir pilnai padengia supertipo esybės

egzempliorių aibę, tuomet specializacijos/apibendrinimo ryšys yra pilnasis; • Jeigu potipių esybių egzemplioriai tarpusavyje persidengia ir pilnai nepadengia supertipo esybės

egzempliorių aibę, tuomet specializacijos/apibendrinimo ryšys yra laisvasis. Apribojimo kontekstas. Šis apribojimas naudojamas specializacijos/apibendrinimo ryšiui. Apribojimo apibrėžimas tipine OCL išraiška. 8 paveiksle pateikto pilno apibendrinimo apribojimo

OCL išraiška: context Asmuo inv: self->forAll(a:Asmuo|Vyras->exists(v|v.Asmuo=a or Moteris->exists(m|m.Asmuo=a))

8 paveiksle pateikto nesikertančių potipių apribojimo OCL išraiška: context Asmuo inv:Vyras->forAll(v:Vyras| and Moteris->forAll(m:Moteris|v.asmuo<>m.asmuo))

Apribojimo pavyzdys. Norint pažymėti, kad visi asmenys skirstomi į vyrus arba moteris yra naudojamas suskaidymo apribojimas specializacijos/apibendrinimo ryšiui. Skirstant klientus į organizacijas arba asmenis ir panaudojus išskirtinumo apribojimą specializacijos/apibendrinimo ryšiui yra nurodoma, kad klientai gali būti arba organizacijos arba asmenys, tačiau gali būti klientų nepriskirtų nei vienai grupei.

Apribojimo vaizdavimas UML. UML specializacijos/apibendrinimo ryšio apribojimus žymi kaip tekstinius apribojimus šalia punktyrinės linijos, jungiančios atitinkamus potipius. UML standarte yra apibrėžti keturi apribojimai [17], [18]:

• „overlapping“ kai potipiai persidengia, • „disjoint“ kai potipiai nesikerta, • „complete“ kai visi subtipai apibrėžti, • „incomplete“ kai papildomi sustipai dar gali būti apibrėžti vėliau. Tokie apibrėžimų įvardinimai ne visai atspindi konceptualiojo modeliavimo sąvokas, todėl siūloma

vietoj šių naudoti aukščiau apibrėžtus specializacijos/apibendrinimo ryšio apribojimus ir juos žymėti taip (8 pav):

• {Total, overlapping} žymėti pilną apibendrinimą su persidengiančiomis potipių aibėmis,

– 559 –


• {Partial, disjoint} žymėti dalinį apibendrinimą su nesikertančiomis potipių aibėmis, • {Total, disjoint} žymėti pilną apibendrinimą su nesikertančiomis potipių aibėmis apribojimą, • {Partial, overlapping} žymėti dalinį apibendrinimą su persidengiančiomis potipių aibėmis.

Asmuo

MoterisVyras

Klientas

OrganizacijaAsmuo

{Total, disjoint} {Partial, disjoint}

8 pav. Išskirtinumo ir suskaidymo apribojimo žymėjimo UML klasių diagramoje pavyzdys.

2.11 Refleksyviojo ryšio apribojimai. Galimi šeši refleksyviojo ryšio apribojimai [1], [4], [6]: • Apribojimas „Nerefleksyvus“ (angl. Irreflexive) reikalauja, kad ta pati esybė nedalyvautų abiejose

ryšio rolėse tuo pačiu metu, t.y., esybės egzempliorius A negali turėti ryšio pats su savimi. • Apribojimas „Asimetrinis“ (angl. Asymmetric) apriboja priešingos rolės egzistavimą tarp dviejų

skirtingų esybės egzempliorių. Jei esybės egzempliorius A turi ryšį su tos pačios esybės egzemplioriumi B, egzempliorius B negali turėti ryšio su tokia pat role su tuo pačiu esybės A egzemplioriumi (jei A yra tėvas, o B sūnus, tai A negali būti B sūnus).

• Apribojimas „Neciklinis“ (angl. Acyclic) nurodo, kad negali egzistuoti ciklų tarp esybės egzempliorių susietų refleksyviuoju ryšiu. Jeigu esybės egzempliorius A turi ryšį su tos pačios esybės B egzemplioriumi ir egzempliorius B turi ryšį su tos pačios esybės C egzemplioriumi, egzemplioriaus C ryšys su A egzemplioriumi yra negalimas.

• Apribojimas „Netranzityvus” (angl. Intransitive) užtikrina, kad egzistuoja tik tiesioginis „tėvo“ – „vaiko“ ryšys. Jeigu esybės egzempliorius A turi ryšį su tos pačios esybės B egzemplioriumi ir egzempliorius B turi ryšį su tos pačios esybės C egzemplioriumi, egzemplioriaus A ryšys su C egzemplioriumi yra negalimas.

• Apribojimas „Simetrinis“ (angl. Symmetric) reikalauja, kad priešinga rolė taip pat būtų teisinga. Jeigu egzistuoja egzemplioriaus A ryšys su B, tuomet egzistuoja ir egzemplioriaus B ryšys su A.

• Apribojimas „Nesimetrinis“ (angl. Antisymmetric) kaip ir „Asimetrinis“ apribojimas neleidžia egzistuoti priešingai rolei tarp skirtingų esybės egzempliorių, tačiau priešingai negu „Nerefleksyvus“ apribojimas leidžia, kad ta pati esybė dalyvautų abiejose ryšio rolėse. Šis apribojimas leidžia esybės egzemplioriui A turėti ryšį su tos pačios esybės A egzemplioriumi ir leidžia egzemplioriui A turėti ryšį su egzemplioriumi B, tačiau draudžia egzemplioriui B turėti ryšį su egzemplioriumi A.

Apribojimo kontekstas. Šis apribojimas naudojamas refleksyviam ryšiui. Apribojimo apibrėžimas tipine OCL išraiška. Prieš užrašant OCL išraišką 9 paveiksle pavaizduotam

nerefleksyvumo apribojimui, reikia apibrėžti dengties operaciją [15] context Darbuotojas:: vadovaujaDengtis(v:darbuotojas):Darbuotojas post: result=d.vadovauja->iterate(d:Darbuotojas;acc:Set(Darbuotojas) =v.vadovauja|if acc.includes(d) then acc else acc.union(d.vadovaujaDengtis())endIf

Tuomet 9 paveiksle pateikto nerefleksyvaus apibendrinimo apribojimo OCL išraiška: context Darbuotojas inv: self->forAll(d:Darbuotojas| not(d.vadovaujaDengtis->includes(self)))

9 paveiksle pateikto nesimetrinio apibendrinimo apribojimo OCL išraiška: context Darbuotojas inv: self.vadovauja->exists(v:Darbuotojas|

not(v.vadovauja->exists(p:Darbuotojas|p=self))) Apribojimo pavyzdys. Teiginys, kad vaikas negali būti savo tėvu, yra „Nerefleksyvus“ apribojimas

refleksyviajam ryšiui. Teiginys, kad jeigu komanda A nugalėjo komandą B, tai tuo pačiu metu komanda B negali būti nugalėtoja prieš komandą B, yra „Asimetrinis“ apribojimas. Teiginys, kad vaikas negali būti tėvo seneliu

– 560 –


yra „Neciklinis“ apribojimas. Jeigu nurodyta, kad asmuo A yra brolis asmeniui B, tuomet ir asmuo B yra brolis asmeniui A. Tai būtų „Simetrinio“ apribojimo pavyzdys.

Apribojimo vaizdavimas UML. Standartiniame UML nėra žymėjimų refleksyviojo ryšio apribojimams. Modeliuotojas juos gali žymėti kaip tekstinius apribojimus pastabose, sujungtose su atitinkamais ryšiais. Grafiniam vaizdavimui reikia įvesti papildomus žymėjimus šalia refleksyviojo ryšio kaip pavaizduota 9 paveiksle. Figūriniuose skliausteliuose naudojami raktiniai žodžiai „Irreflexive“(„Nerefleksyviam“ apribojimui), „Asymmetric“ („Asimetriniam“), „Acyclic“ („Necikliniam“), „Intransitive“ („Netranzityviam“), „Symmetric“ („Simetriniam“) ir „Antisymmetric“ („Nesimetriniam“).

Darbuotojas

-revizuoja *

-revizuojamas

*

{Irreflexive}

Darbuotojas

-vadovauja *

-vadovaujamas

*

{Asymmetric}

9 pav. Nerefleksyvaus ir nesimetrinio apribojimo refleksyviajamm ryšiui žymėjimo UML klasių diagramoje pavyzdys.

2.12 Egzempliorių susiejimo ryšiais apribojimas. Šis apribojimas ryšiui nurodo, kad ne visi esybės egzemplioriai gali dalyvauti ryšyje, o tik tie esybės egzemplioriai, kurie dalyvauja nurodytų ryšių aibėje [16].

Apribojimo kontekstas. Šis apribojimas naudojamas ryšiui. Apribojimo apibrėžimas tipine OCL išraiška. 10 paveiksle (a) pateikto apribojimo OCL išraiška:

Context Scenarijus inv:self.žingsniai->forAll(s|s.vykdomasPoDengtis->not(includes(s))) Context Žingsnis::vykdomasPoDengtis(ž:Žingsnis):Set(Žingsnis) result = ž.vykdomasPo->iterate (p:Žingsnis; acc:Set(Žingsnis) = ž.vykdomasPo|acc->if p.vykdomasPo->notEmpty() then if acc.includes(p) then acc else acc.union(p.vykdomasPoDengtis) endIf endIf)

Apribojimo pavyzdys. Susiejant scenarijaus žingsnius, reikia įsitikinti, kad jie priklauso tam pačiam scenarijui. Tokiu atveju refleksyviam ryšyje gali dalyvauti ne visi esybės „Žingsnis“ egzemplioriai, o tik tie, kurie priklauso tam pačiam scenarijui. Ryšys R1 padalina esybės „Žingsnis“ egzempliorius į aibes egzempliorių, kurie gali būti susieti refleksyviaisiais ryšiais.

Studentui renkantis jam vadovaujantį profesorių, galima rinktis tik iš profesorių, kurie dirba tame pačiame fakultete, kuriame specializuojasi studentas. Ryšys R1 padalina esybės „Dėstytojas“ egzempliorius į poaibius, priklausančius tam tikriems fakultetams. Ryšys R2 panašiai padalina esybės „Studentas“ egzempliorius. Susiejant esybės „Dėstytojas“ ir „Studentas“ egzempliorius, būtina užtikrinti, kad būtų susiejami tik to paties fakulteto poaibiams priklausantys dėstytojai ir studentai.

Apribojimo vaizdavimas UML. Egzempliorių susiejimo ryšiais apribojimas nėra grafiškai vaizduojamas UML, tačiau jį galima užrašyti kaip pastabą apribojamam ryšiui. Grafiškai šį apribojimą siūloma žymėti kaip pavaizduota 10 paveiksle. 10 paveiksle (a) refleksyviojo ryšio apribojimai išvardinami, atskiriant juos kableliais. Taip nurodoma, kad refleksyvusis ryšys turi būti neciklinis ir jungti egzempliorius iš poaibių, į kuriuos padalina ryšys R1. 10 paveiksle (b) R3 asociacijai nurodyta, kad egzemplioriai, kuriuos galima susieti, turi būti priklausyti tiems patiems asociacijų R1 ir R2 egzemplioriams.

Scenarijus

Žingsnis

-turi1

-priklauso1..*

-vykdomas po0..*

-vykdomas prieš

0..*

R1

{R1, acyclic }

Fakultetas Studentas

Dėstytojas

-teikia specializaciją

1

-specializuojasi

1..*

-yra darbovietė1

-dirba0..*

-vadovaujamas0..*

-vadovauja

0..1

R1

R2

R3 {R1+ R2}

– 561 –


a b

10 pav. Egzempliorių susiejimo ryšiais apribojimo refleksyviajam ryšiui (a) ir asociacijai pavyzdys (b).

3 Kada reikia naudoti apribojimus Galima išskirti kelias situacijas, kuriose yra didelė tikimybė, kad bus reikalingi vientisumo apribojimai.

Šiose situacijose neįvedus reikiamų vientisumo apribojimų atsiranda informacinės sistemos būsenų suderinamumo problemos.

Vientisumo apribojimai dažnai reikalingi neprivalomiems atributams. Jeigu neprivalomus atributus galima suskirstyti į poaibius, tuomet didelė tikimybė, kad bus reikalingi ekvivalentiškumo, išskirtinumo arba poaibio apribojimai.

Modeliuojant neprivalomus ryšius tarp esybių, reikia atkreipti dėmesį, ar nereikalingi apribojimai, kurie rodytų, kurie ryšiai tam tikrais atvejais yra privalomi arba pan.

Refleksyviajam ryšiui dažniausiai reikalingi apribojimai, kurie rodo, kokius egzempliorius galima susieti.

Esant ciklui, t.y. ryšių trajektorijai, kuri prasideda ir baigiasi toje pačioje esybėje, dažnai reikalingi apribojimai. 10 paveiksle (b) pavyzdyje apribojimo nebuvimas lestų studentams rinktis vadovą iš visų fakultetų dėstytojų. Jeigu tokia situacija leistina, tuomet šiam ciklui apribojimas nereikalingas.

Jeigu esybė, turinti refleksyvųjį ryšį, turi ir privalomą ryšį su kita esybe, tuomet didelė tikimybė, kad refleksyviajam ryšiui, be jam būdingų apribojimų, reikia dar nurodyti ir egzempliorių susiejimo ryšiais apribojimą. 10 paveiksle (a) pateiktame pavyzdyje apribojimas {R1} yra būtinas, jeigu galima susieti tik to paties scenarijaus žingsnius. Tačiau, jeigu leistina susieti ir skirtingų scenarijų žingsnius, tuomet šis apribojimas nereikalingas.

4 Konceptualiojo modelio vientisumo apribojimų metamodelis Konceptualusis modeliavimas yra labai svarbus informacinės sistemos projektavimo etapas. Jo metu

sudaromas konceptualus modelis atspindi dalykinės srities būsenas. Jį galima specifikuoti tekstu arba grafiškai naudojant įvairiausias notacijas. Labiausiai taikomi ir plačiai žinomi anksčiau minėti konceptualiojo modeliavimo metodai (esybių-ryšių, išplėstasis esybių-ryšių, aukštesnės eilės esybių-ryšių, objektų rolių modelis ir unifikuota modeliavimo kalba) turi savų privalumų ir trūkumų, tačiau visi jie gali būti laikomi konceptualiojo modeliavimo „tėvo“ ER modelio išplėtimais. Galima įžvelgti, kad jie visi naudoja tuos pačius pagrindinius konceptus (10 pav.): esybės objekto tipas, kuris apibrėžia realaus pasaulio dalykus; atributas – žymi kokybines arba kiekybines esybės objekto tipo savybes; apribojimas – konceptualiojo modelio elementas, kuris naudojamas kartu su kitu apibrėžtu modelio elementu.

– 562 –


Esybė

Atributas

-apibūdina 1-priklauso 0..*

Ryšys

Asociacija

Specializavimo /apibendrinimo

Ryšio esybė -yra1-dalyvauja

0..*

-susideda

0..*

-priklauso 1

Vientisumo apribojimas atributams

Apribojami atributai

-yra 1-apribojamas 0..*

-susideda 0..*-priklauso 1

Vientisumo apribojimas asociacijai

Vientisumo apribojimas specializavimui /apibendrinimui

Vientisumo apribojimas

Apribojama asociacija

Apribojamas specializavimas /apibendrinimas

-yra 1-apribojamas 0..*

-susideda 0..*

-priklauso 1

-yra 1-apribojama 0..*

-susideda 0..*-priklauso 1

{Partial, disjoint}

10 pav. Konceptualiojo modelio pagrindiniai elementai ir ryšiai tarp jų.

Minėti metodai labai skiriasi pagal nagrinėjamų vientisumų apribojimų aibę. Vieni jų apima tik pačius

pagrindinius apribojimus [10], kiti [10], [14], [5] į savo modelius stengiasi įtraukti sudėtingus apribojimus ryšiams bei atributams ir surinkti kuo daugiau semantinės informacijos.

Pagal tai kokiems konceptualiojo modelio elementams apibrėžti taikomi vientisumo apribojimai, juos galima klasifikuoti į:

• Vientisumo apribojimus esybių atributams, • Vientisumo apribojimus asociacijų ryšiams tarp esybių, • Vientisumo apribojimus specializacijos/apibendrinimo ryšio tipui. 14 paveiksle pateikta apribojimų klasifikacija, kurioje išskirti apribojimų potipiai nesidengia

tarpusavyje, tačiau vientisumo apribojimų aibė nėra išsami, čia pateikiami tik pagrindiniai, dažniausiai taikomi apribojimai.

Vientisumo apribojimų atributams potipiui priskiriami apribojimai taikomi vienam atributui (reikšmės, paprasto būtinumo apribojimas), atributui arba jų grupei (pirminio identifikatoriaus apribojimas, vidinio unikalumo apribojimas), skirtingų esybių atributams (išorinio unikalumo apribojimas), neprivalomų atributų grupėms (disjunktyvaus būtinumo, ekvivalentiškumo, poaibio ir išskirtinumo apribojimai) (14 pav.).

Vientisumo apribojimų ryšiams tarp esybių potipiui priskiriami apribojimai taikomi vienam ryšiui tarp esybių (dažnumo apribojimas) ir neprivalomiems esybių ryšiams su kitomis esybėmis (disjunktyvaus būtinumo, ekvivalentiškumo, poaibio ir išskirtinumo apribojimai). Kadangi refleksyvusis ryšys yra atskiras ryšio atvejis, todėl refleksyviojo ryšio apribojimai taip pat priskiriami prie apribojimų ryšiui potipio (14 pav.).

Vientisumo apribojimų specializacijos/apibendrinimo ryšio potipiui priskiriami apribojimai taikomi tik specializacijos/apibendrinimo ryšiu jungiamiems esybių potipiams. Šie apribojimai nagrinėjami tik tuose metoduose, kuriuose naudojami specializacijos/apibendrinimo ryšiai [5], [10], [14].

– 563 –


Žiedinės asociacijos apribojimai

Aibės apribojimai asociacijai

Dažnumo apribojimas

Aciklinis

Asimetrinis

Intranzityvus

Simetrinis

Irefleksyvus

Antisimetrinis

Poaibio apribojimas asociacijai Išskirtinumo apribojimas asociacijai

Ekvivalentiškumo apribojimas asociacijai

Vientisumo apribojimas atributamsVientisumo apribojimas asociacijai

Vientisumo apribojimas specializavimui /apibendrinimui

Vientisumo apribojimas

Disjunktyvus būtinumas

Pilnumo apribojimas Suskaidymo apribojimas

Laisvumo apribojimasIšskirtinumo apribojimas

Pirminis identifikatoriaus

Vidinis unikalumasIšorinis unikalumas

Paprastas būtinumas

Disjunktyvus būtinumas

Reikšmės apribojimas

Aibės apribojimai atributams

Poaibio apribojimas atributams Išskirtinumo apribojimas atributams

Ekvivalentiškumo apribojimas atributams

{Partial, disjoint}

14 pav. Vientisumo apribojimų klasifikacija.

5 Išvados Išanalizavus informacinių sistemų schemų vientisumo apribojimus, kuriuos galima realizuoti DBVS

priemonėmis, buvo sudaryta apribojimų taksonomija. Pagrindiniai dalykinės srities apribojimai, kuriuos tikslinga vaizduoti informacinės sistemos konceptualiajame modelyje, aprašyti neformaliais apibrėžimais ir užrašyti formalia OCL kalba, pateikti jų vaizdavimo UML pavyzdžiai. Apribojimams, kurie neturėjo UML grafinių žymėjimų, pasiūlyti stereotipų žymėjimai, kurie išplečia UML konceptualiojo modeliavimo semantinės išraiškos galimybes.

Ši analizė yra pirmas etapas, norint sukurti metodus ir priemones konceptualiojo modelio apribojimų suderinamumui patikrinti ir išsamiam konceptualiajam modeliui transformuoti į reliacinių duomenų bazių schemas, apimančias ne tik lenteles ir atributus, bet ir trigerius bei check funkcijas, kurie užtikrintų aukštos kokybės informacinės bazės sukūrimą.

Tolimesniame darbe taip pat siekiama apibrėžti UML profilį, kuriame būtų tinkami stereotipai įvairių tipų apribojimams žymėti, kas palengvintų modeliuotųjų darbą. Tipiniai apribojimai pagal šablonus bus transformuojami į DBVS realizacijas tipinių transformavimo priemonių pagalba.

Literatūros sąrašas [1] Halpin T., Bloesch A. Data modeling in UML and ORM: a comparison. Journal of Database Management, vol. 10

no. 4, October 1999, p. 4-13. [2] Halpin T. Integrating fact-oriented modeling with object-oriented modeling. Information Modeling in the New

Millennium, Idea Group, 2001, ISBN 1-878289-77-2, p. 150-166. [3] David C. Hay. A comparison of data modeling techniques. [žiūrėta 2004-10-26] Prieiga per Internetą:

http://www.essentialstrategies.com/publications/modeling/compare.htm. [4] Halpin T. Verbalizing Business Rules (part 1-9). Business Rules Journal, vol. 4, no. 4, April 2003. Prieiga per

Internetą: http://www.BRCommunity.com/a2003/b138.html. [5] Paradauskas B., Nemuraitė L. Duomenų bazės ir semantiniai modeliai, Technologija, 2002, ISBN 9955-09-436-2,

p. 13-45. [6] Halpin T. UML Data Models from an ORM Perspective: Part 1 – 10. Journal of Conceptual Modeling, Prieiga per

Internetą: http://www.orm.net/uml_orm.html. [7] Warmer J.B., Kleppe A.G. Object Constraint Language, The: Getting Your Models Ready for MDA, Addison

Wesley, August 29, 2003. [8] Ullman J., Widom J. A first course in database systems. - 2nd ed. Prentice-Hall, 2002. [9] Elmasri, Navathe. Fundamentals of Database Systems. 3 chapter.

– 564 –

https://portal.acm.org/poplogin.cfm?dl=GUIDE&coll=GUIDE&comp_id=COMPONENT030&want_href=citation%2Ecfm%3Fid%3D334638&CFID=29850920&CFTOKEN=15160800

https://portal.acm.org/poplogin.cfm?dl=GUIDE&coll=GUIDE&comp_id=COMPONENT030&want_href=citation%2Ecfm%3Fid%3D334638&CFID=29850920&CFTOKEN=15160800

http://www.essentialstrategies.com/publications/modeling/compare.htm


http://www.orm.net/uml_orm.html


[10] Thalheim B. Foundations of Entity-Relationship modeling. [11] Halpin T. Data modeling in UML and ORM revisited. [12] Demuth B., Hussmann H. Using UML/OCL Constraints for Relational Database Design. [13] Behrend A., Manthey R., Pieper B. An Amateur’s Introduction to Integrity Constraints and Integrity Checking in

SQL. [14] Hainaut J.L. DB-Main tutorial, 1999. [15] Gogolla M., Richters M. Expressing UML class diagrams properties with OCL. Lecture Notes in Computer Science,

Vol. 2263, 2002, pp. 85-114. [16] Starr, L. Executable UML. How to build class models, Prentice Hall, Upper Saddle River, 2002, p. 418. [17] Unified Modeling Language. Infrastructure Specification Version 2.0. OMG document ptc/03-09-15, 2003. Prieiga

per Internetą: http://www.omg.org. [18] Unified Modeling Language. Superstructure Specification Version 2.0. OMG document ptc/03-08-02, 2003. Prieiga

per Internetą: http://www.omg.org. [19] Hainaut J. L. DB-Main Reference Manual. Version 6.5. Dept. of Computer Science, University of Namur, Belgium,

2002

Taxonomy of Integrity Constraints of Conceptual Model Conceptual model of good quality should be comprehensive, semantically rich, satisfying normal forms.

This article presents set of integrity constraints defined to satisfy the conceptual model described above and witch elements are defined with formal language and displayed in UML class diagrams with OCL expressions. In order to expand graphically captured set of constraints, it is suggested to enter additional stereotypes and notations for constraints that doesn’t have graphical notation in UML class diagram. In this article is also presented main concepts of conceptual model with classification of integrity constraints.

http://www.omg.org/

http://www.omg.org/

NATURAL LANGUAGE UNDERSTANDING BY MEANS OF MOBILE AGENTS ARCHITECTURE

Algirdas Laukaitis, Raimondas Berniunas, Olegas Vasilecas VGTU

In this paper we present architecture of natural language understanding (NLU) system by means of mobile agents and IBM NLU toolbox. Agents can travel to different machines and aggregate information needed for natural language understanding from local knowledge bases stored internally into IBM NLU toolbox. In our distributed environment each user can store knowledge locally using local IBM NLU agent. On the other hand by using mobile agents each use can benefits from global distributed knowledge if local NLU storage can’t answer the questions. We show that both techniques (IBM NLU and Aglets) combined presents powerful and flexible framework for building natural language understanding systems. On the presented framework we build a personal assistant, which automatically generates small web applications for information extraction from DBMS. All presented modules a realized as the open source project JMining Dialog.

1. Introduction

Data environments are becoming more and more complex as the amount of information a company manages continues to grow. Information delivery web portals have emerged as the preferred way to bring together information resources. Using information delivery web portal, your organization's employees, customers, suppliers, business partners, and other interested parties can have a customized, integrated, personalized, and secure view of all information with which they need to interact. But one big challenge remains for organization: how to teach employees or costumers to use and understand complex database environment without involving experts and IT resources which are costly and time consuming. One of the solutions use natural language database interfaces (NLDBIS). Natural language database interfaces are systems that allow users to access information stored in a database by formulating requests in natural language. For example a NLDBI would typically be able to answer questions like the following.

“Show me the latest prices of IBM shares” The system that supports (NLDBIS) functionality automatically would translate user sentences to adequate SQL

script, query some DBMS and return results to the user. NLDBIS have received particular attention within the natural language processing community (see [2] for reviews of the field), and they constitute one of the first areas of natural language technology that have given rise to commercial applications. But we will mention several problems with the available systems:

1. Most systems supports only simple one sentence translation into SQL. They do not support complex dialog, which is the most usual case in real life when we want interactively to build adequate request.

2. Most systems are commercial products [2] and because they are close systems there is difficulties in extending such systems. And we think that only open source projects can bring more attention from researchers to NLDBIS field.

To tackle mentioned problems we propose our system JminingDialog, which is constituent part of our open source information delivery web portal JMining. We have no intention to describe JMining architecture in details and for details about it implementation as open source project we refer to [4] and [7]. Instead, we describe architecture of natural language understanding (NLU) module for building small web applications using only natural language. For NLU module we propose an architecture that is based on using mobile intelligent agents. The basic point for such architecture in our work can be related to the approach, which argues that knowledge consists largely of a personal, stored locally data files. Mobile agents can travel to various hosts where local knowledge is stored and gather necessary information that meets user request.

The paradigm of agents is a very promising approach to overcome some of the problems connected with heterogeneity on the side of the data sources as well as on the side of the users. As agents should operate autonomously and can be loosely coupled, they are well suited for the integration of distributed heterogeneous data sources, building unifying wrappers around them. This becomes especially beneficial, if agents can learn to extract information from an information source automatically (see for example [3] and [5]). On the side of the users, the paradigm of Personal Information Agents offers a way to encapsulate the interests, the knowledge as well as the

– 566 –

Natural language understanding by means of mobile agents architecture

preferences of individual users. Personal Agents can take the role of mediators between users and information sources, as well as between users among each other (see also [3] and [6]).

Furthermore we present an agent architecture consisting of a set of asynchronously operating agents. This architecture enables us to perform sophisticated data and interaction analysis, without loosing the property of short respond times essential for interactive work in real-time. Based on the paradigm of mobile agents, we present a model for expressing knowledge that has been acquired continuously by individuals and groups of users and for using this as a means for semantic identification of various elements to build necessary web applications.

2. General architecture

Figure 1. Architecture of the JMining systems NLU modules by means of mobile agents.

User – user uses Internet/Intranet browser and communicates with JminingDialog. Figure 6 shows the main front-end window from which user interacts with the system. JMiningDialog – is integrated into web server and is responsible for local dialog manager as well as for the communication NLU mobile agents. Jmining Information presentation layer – is integrated into web server and is responsible for local dialog manager as well as for the communication NLU mobile agents. Agents management layer – manages all agents to get the semantic mapping of user request. Local knowledge hosts – each host maintain local knowledge and local semantic mapping modules. Mobile agent cal travel to remote host and acquire necessary knowledge,

3. Mobile Agents

Mobile agents are computational software processes capable of roaming wide area networks (WANs) such as the WWW, interacting with foreign hosts, gathering information on behalf of its owner and coming ‘back home’ having performed the duties set by its user. These duties may range from a flight reservation to managing a telecommunications network. Mobile agents may cooperate or communicate by one agent making the location of some of its internal objects and methods known to other agents. By doing this, an agent exchanges data or information with other agents without necessarily giving all its information away [1].

The mobile agents need not be stationary; indeed, the idea is that there are significant benefits to be accrued, in certain applications, by putting away static agents in favour of their mobile counterparts. These benefits are largely non-functional, i.e. we could do without mobile agents, and only have static ones but the costs of such a move are

– 567 –

A. Laukaitis, R. Berniūnas, O. Vasilecas

high. For example, in our case consider the scenario when mobile agent is requested to find some knowledge structures related to the words arrangement and accounts from several users computers.

A static single-agent program would need to request for all files residing on the remote knowledge sharing host, which may total to several gigabytes. Each of these actions involves sifting through plenty of extraneous information which could/would clog up the network.

And consider the alternative. JMining NLU module encapsulates, user sentences to the entire program within an agent which consumes may be only several kilobytes which roams the other hosts included in the knowledge sharing network, arrive safely and queries these hosts locally, and returns ultimately to the home computer. This alternative obviates the high communications costs of shifting, possibly, gigabytes of information to user local computer. Hence, mobile agents provide a number of practical, though non-functional, advantages, which escape their static counterparts. So their motivation include the following anticipated benefits. • Reduced communication costs: there may be a lot of raw information that need to be examined to determine

their relevance. Transferring this raw information can be very time-consuming and clog of the networks. Imagine having to transfer many images just to pick out one. It is much more natural to get your agents to “go” to that location, do a local search/pruning and only transfer the chosen compressed image back across the network. It obviates the need for costly network connections between remote computers as required in remote procedure calls (RPC). It provides a much cheaper alternative as we pay increasingly for network bandwidth and time.

• Limited local resources: the processing power and storage on the local machine may be very limited (only perhaps for processing and storing the results of a search), thereby necessitating the use of mobile agents.

• Easier coordination: it may be simpler to coordinate a number of remote and independent requests and only collate all the results locally.

• Asynchronous computing: you can ‘set off’ your mobile agents and do something else and the results will be back in your mailbox, say, at some later time. They may operate when you are not even connected.

• It provides a natural development environment for implementing ‘free market’ trading services. New services can come and go dynamically and much more flexible services may co-exist with inferior ones, providing more choices for consumers.

• A flexible distributed computing architecture: mobile agents provide a unique distributed computing architecture which functions differently from the static set-ups. It provides for an innovative way of doing distributed computation.

4. Aglets as mobile agents

Aglets are Java objects that can move from one host on the network to another. That is, an aglet that executes on one host can suddenly halt execution, dispatch to a remote host, and start executing again. When the aglet moves, it takes along its program code as well as the states of all the objects it is carrying. A built-in security mechanism makes it safe to host untrusted aglets.

The main reasons for choosing aglets was that they • Provide an easy and comprehensive model for programming mobile agents without requiring modifications to

Java VM or native code. • Support dynamic and powerful communication that enables agents to communicate with unknown agents as

well as well-known agents. • Design a reusable and extensible architecture. • Design a harmonious architecture with existing Web/Java technology. • Provide security mechanisms that are comprehensive and simple enough to allow end users to trust mobile

agents The Aglet API defines the fundamental functionality of mobile agents. The following figure 2 shows the major

interfaces and classes defined in the Aglet API and the relationship between these interfaces. The Aglet abstract class defines the fundamental methods (for example, dispatch(URL)) used to control

the mobility and life cycles of mobile agents. All mobile agents defined in Aglet have to extend this abstract class. The Aglet.dispatch(URL) primitive causes an aglet to move from the local machine to the destination specified as its argument. The Aglet.deactivate(long time) primitive allows an aglet to be stored in secondary storage, and the Aglet.clone() primitive spawns a new instance of the aglet that has the same state as the original aglet. Note that the object returned by the clone primitive is not an Aglet object but an AgletProxy object.

– 568 –


Figure 2. Major interfaces and classes defined in the Aglet API

The Aglet class is also used to access the attributes associated with an aglet. The com.ibm.aglet.AgletInfo object, which can be obtained by the Aglet.getAgletInfo() primitive, contains an aglet's inherent attributes, such as its creation time and codebase, as well as its dynamic attributes, such as its arrival time and the address of its current context.

Aglet Object and Its Life Cycle. The com.ibm.aglet.Aglet class provides the basic functionality for a mobile object, and every aglet (aglet objects) has to be an instance of a subclass of it. To use an aglet, you first has to instantiated it. There are two ways to create a new instance of an aglet. The first is to instantiate a completely new aglet from class definitions by calling AgletContext.createAglet(URL codebase, String name, Object init). This primitive creates a new instance within the specified context and initializes it if necessary, then invokes Aglet.onCreation(Object init) on the created object along with the initializer object passed to the createAglet primitive. The other way is to create a copy of an existing aglet by using the Aglet.clone() primitive. The cloned aglet has the same state as the original one but has a different AgletID object, an thus a distinct identity.

Once created, an aglet object can be dispatched to and/or retracted from a remote server, deactivated and placed in secondary storage, then activated later.

Figure 3. Aglet Object and Its Life Cycle

An aglet can dispatch itself to a remote server by calling the Aglet.dispatch(URL dest) primitive. To be more precise, an aglet occupies the aglet context and can move from this context to others during its execution. Because the server may serve multiple contexts within one Java VM, and one host may serve multiple servers in one host the context are named as the following set

the address of the host, typically IP-address. the port number to which the server is listening. the name of context within the server. Example: http://aglets.ibm.com:1434/context_name Dispatching causes an aglet to suspend its execution, serialize its internal state and bytecode into the standard

form and then to be transported to the destination. On the receiver side, the Java object is reconstructed according to the data received from the origin, and a new thread is assigned and executed.

– 569 –


Aglets can be persistent. Since a mobile aglet needs to be serializable into a bit-stream, all mobile aglet can be persistent in nature. The Aglet.deactivate(long timeout) primitive causes an aglet to be stored in secondary storage and to sleep for a specified number of milliseconds. After the given time has passed or another program has requested its activation, the aglet is activated within the same context where as that in which it was deactivated.

Unlike normal Java objects, which are automatically released by garbage collector, an aglet object, since it is active, can decide whether or not to die. If you call the dispose() method to kill the aglet, onDisposing() is called to perform the finalization suitable for the current state of the aglet. (Note that this is different from Java's finalizer(), which is invoked when the object is garbage-collected.) Aglet programmers are responsible for releasing allocated resources such as file descriptors or DB connections, because these may not be released automatically.

The Aglets architecture consists of two layers, and two APIs that define interfaces for accessing their functions

Figure 4. The Aglets architecture

The Aglets runtime layer is the implementation of the Aglet API, and defines the behavior of the API components, such as AgletProxy and AgletContext. It provides the fundamental functions for aglets to be created, managed, and dispatched to remote hosts. The communication layer is primarily responsible for transferring a serialized agent to a destination and receiving it. It also supports agent-to-agent communication and facilities for agent management.

The following figure 5 shows the architecture of the communication layer. com.ibm.maf.MAFAgentSystem is an abstract class that defines a set of methods equivalent to the MASIF interface. There are two kinds of class that extend this abstract class. One is an implementation class that provides the agent system facility, and the other is a stub object that transfers a request to a destination.

Figure 5. Architecture of the communication layer

An application or client uses a stub object to send a request to the destination. An agent system must have a stub class for each protocol it supports. Applications or clients can then get and use a stub object for a given protocol. Note that it is an agent system's responsibility to instantiate and manage stub objects. The latest beta (as of this writing) version of Aglets supports two protocols, ATP and RMI.

– 570 –


5. Natural Language Understanding

Natural Language Understanding combines breakthrough research and development in the fields of voice recognition, linguistics, statistics, human factors, and artificial intelligence. The technology can make the interaction between people and computer applications more intuitive and effective. When NLU is combined with speech recognition, the user is able to speak in a more unstructured, conversational style, resulting in a more comfortable and productive user experience.

NLU Components Conceptually, NLU technology is comprised of two components: Natural Language Dialog – The way in

which a user can provide input to the application and the way the application responds to the user. Natural Language Processing - The work done by the software to process what the user said. Essentially, this means that meaning is extracted from the dialog and from the conversation history [8].

NLU capability (and mixed initiative dialog, for that matter) extends system design complexity significantly. Speech recognition must allow a much broader variety of input. Additional technology must be employed to be able to resolve abstractions, glean the meaning of arbitrary inputs, and to allow complex transitions from one type of transaction to another. At the same time, conversational history must be used to "inherit" parameters.

IBM Natural Language Understanding (NLU) technology [9] allows a user to interact with computer applications in much the same way as they would when dealing with a person. IBM NLU adds a natural dimension to speech technology by supporting unstructured, conversational dialog rather than requiring the user to speak specific commands. It puts the user in control of the interaction, eliminating long menu options, keypad-driven transactions, and hard-to-remember commands for easy, transparent access to information and services.

NLU technology can take the convenience and usability of information delivery portal systems to another level by enabling a more intuitive, comfortable and productive interaction for end user, which can increase customer satisfaction and retention. NLU solutions offer significant benefits to both the enterprise and the end user. They allow users to not only get things done for themselves (self-service means decreased cost of business), but also to get those things done in a manner that’s comfortable and pleasant.

Figure 6 show NLU interface that we adapted from IBM NLU toolbox for web applications generation. User can enter request for information from one of the DBMS that are available and if the system is not able to answer user can correct the request following hints produced by JMining system.

Figure 6. Front-end of the JMiningDialog.

– 571 –


6. Conclusion

We presented basic architecture components for querying DBMS using natural language. Our research shows that distributed knowledge architecture is more flexible and adaptable for such tasks then centralised solutions. By establishing open source project in this field we hope to attract more attention to this field from other researches. Finally we recommend for the readers of this pepper constantly to check JMining official page [7] for changes and new research results.

References [1] Aglets Specification. http://www.trl.ibm.com/aglets/spec10.htm 1997. [2] I. Androutsopoulos, G.D. Ritchie, and P. Thanisch. Natural Language Interfaces to Databases – An Introduction. Natural

Language Engineering, 1(1):29–81, 1995. [3] M. N. Huhns and Larry M. Stephens. Intelligent Agents, in Multiagent Systems: A Modern Approach to Distributed

Artificial Intelligence. G. Weiss (Ed.), MIT Press, Cambridge, MA. (1999). [4] A. Laukaitis, O. Vasilecas, R. Berniunas. JMining - information delivery web portal architecture and open source

implementation. Information Systems Development: Advances in Theory, Practice and Education. Edited by O. Vasilecas et al., Springer, 2005. To appear.

[5] H. S. Nwana. The Potential Benefits of Software Agent Technology to BT. Internal Technical Report, Project NOMADS, Intelligent Systems Research, AA&T, BT Labs, UK (1996).

[6] N. I. Takeuchi. The Knowledge-Creating Company. Oxford University Press (1995). [7] Vilnius Gedimino Technical University. JMining project. http://fmisl-09.vtu.lt/Portal 2004. [8] IBM. An Introduction to IBM Natural Language Understanding. An IBM White Paper. 2003. [9] IBM Voice Toolkit V5.1 for WebSphere® Studio. http://www-306.ibm.com/software/pervasive/voice_toolkit/ 2004.

http://www.trl.ibm.com/aglets/spec10.htm

http://fmisl-09.vtu.lt/Portal

http://www-306.ibm.com/software/pervasive/voice_toolkit/

DUOMENŲ BAZIŲ LYGMENS ĮSISKVERBIMŲ DETEKTAVIMO SISTEMOS

Lukas Radvilavičius1, Nikolaj Goranin1 ,Antanas Čenys1,2, Darius Rainys2,3 1 VGTU, Saulėtekio 11, LT-10223, Vilnius, Lietuva

[email protected] 2 Puslaidininkių fizikos institutas

A.Goštauto11, LT-01108, Vilnius, Lietuva [email protected]

3.UAB ”BlueBridge”, Jasinskio g. 16, Vilnius, Lietuva [email protected]

Vertingiausia organizacijų ir firmų informacija dažniausiai yra sukaupta duomenų bazėse. Todėl duomenų bazių apsauga yra labai svarbi informacinių sistemų saugumo politikos dalis. Tačiau būtent duomenų bazių apsauga yra pakankamai sudėtinga, kadangi saugumą užtikrinančios sistemos turi neriboti didelio skaičiaus legalių vartotojų veiklos.Vienas iš naujų ir labai perspektyvių duomenų bazių apsaugos metodų yra taip vadinamų “medaus puodynių” (hoenypot) tipo sistemų taikymas. “Medaus puodynės” naudoja falsifikuotus informacinius resusrsus tikslu pritraukti nelegalių vartotojų dėmesį ir juos identifikuoti.Darbe išnagrinėta galimybė sukurti “medaus puodynės” tipo sistemą Oracle duomenų bazei. Išnagrinėti būdai kaip stebėti tam tikras lenteles ir apie užklausas joms pranešti sistemos administratoriui. Sukruta visa tokiai sistemai reikalinga programinė įranga.

1. Įvadas

Kompiuterizuotos informacinės sistemos ir kompiuteriniai tinklai šiuo metu yra neatskiriama beveik visų organizacijų ir įmonių dalis. Firmose kaupiamos ir saugomos informacijos vertė dažnai sudaro labai žymią dalį firmų rinkos vertės. Informacija tapo labai svarbia vertybe ir preke. Tačiau kartu su naujomis galimybėmis atsirado ir nauji pavojai bei problemos. Jau seniai praėjo tie laikai kada firmos ir organizacijos į informacijos apsaugą galėjo nekreipti dėmesio ir nenorėjo į tai investuoti nei laiko nei lėšų.

Didžioji dalis grėsmių informacijos saugumui kyla iš interneto. Atsirado nemažai kompiuteriniais nusikaltimais užsiimančių grupuočių, vienos jų žemesnės kvalifikacijos – tik paaugliai ar studentai, pradėję domėtis tamsiąja kompiuterinio pasaulio dalimi, kiti profesionalai. Būtent jie yra ypač pavojingi, tačiau “mėgėjų” žaidimui sukurtų virusų padaryti nuostoliai gali būti milžiniški. Neretai kompanijų konkurentai naudojasi nelegaliomis priemonėmis siekdami gauti jiems reikalingą informaciją ar apsunkinti konkurentų veiklą.

Šiuo metu jau yra sukurta labai įvairių ir gan efektyvių priemonių apsisaugojimui nuo informacijos vagysčių. Visų pirma tai labai įvairios autentiškumą užtikrinančios sistemos, paremtos slaptažodžiais, įvairiomis kodavimo priemonėmis ar net biometriniais duomenimis. Apsauga nuo grėsmių, ateinančių iš tinklo, dažniausiai paremta įvairaus tipo ugniasienėmis. Norint aptikti jau įvykusį įsilaužimą, naudojamos įsilaužimų detektavimo sistemos ( IDS – intrusion detection systems). Pastaruoju metu tokio tipo sistemų yra sukurta labai daug ir jos plačiai naudojamos. Vienas iš svarbiausių tokių sistemų trūkumų yra didelis skaičius netikrų pavojaus aliarmų, kas labai apsunkina sistemos saugumo administratorių darbą ir kartais priveda prie to, kad yra nepastebimi tikri pavojaus signalai. Dėl šios priežasties pastaruoju metu vis labiau darosi populiarios “medaus puodynės” tipo apsaugos priemonės. Tokiose sistemose yra sukuriamas specialus informacinis resursas, kuriuo legaliai nėra naudojamasi. Todėl bet koks bandymas prieiti prie tokio resurso yra nelegalus ir beveik visi tokios sistemos generuojami pavojaus signalai yra tikri.

Viena iš labiausiai pažeidžiamų informacinių sistemų dalis yra duomenų bazės, kuriose dažnai yra saugoma svarbiausia informacija. Šiais laikais jose saugoma beveik visa įmonių informacija, pradedant darbuotojų sąrašais, baigiant klientų, užsakymais ar net galimų ateities klientų sąrašais. Tokios informacijos patekimas į konkurentų rankas nesunkiai gali privesti įmones prie bankroto. Norint apsaugoti duomenų bazėse saugomą informaciją, labai svarbu teisingai ir savalaikiškai administruoti vartotojų teises ir privilegijas, užtikrinant kiekvieno vartotojo priėjimą tik prie jam reikalingų informacijos resursų. Taip pat yra ribojamas tiesioginis priėjimas prie duomenų bazės, daugumą priėjimų organizuojant per specialias aplikacijas.

Tačiau tai dar neužtikrina visiško saugumo, kadangi slaptažodžių administravimas yra labai sudėtinga problema, kuri niekada nėra pilnai išsprendžiama. Slaptažodžiai gali būti nulaužti, pasakyti draugams, nesaugiai

– 573 –

mailto:[email protected]



L. Radvilavičius, N. Goranin, D. Rainys, A. Čenys

užrašyti ar laiku neanuliuoti. Todėl, nežiūrint visų apsaugos priemonių, labai aktualu yra stebėti, kas ir ką daro jūsų duomenų saugyklose. Mažose duomenų bazėse, esant nedideliam transakcijų skaičiui, tai galima pilnai realizuoti. Tačiau, esant tūkstančiams transakcijų per valandą, toks stebėjimas nebetenka prasm, nes neįmanoma analizuoti gautų duomenų.

Vienas iš galimų šios problemos sprendimo būdų yra “medaus puodynės” tipo sistemos realizavimas duomenų bazės lygmenyje. Tokiam atvejui turėtų būti sukurtas koks nors objektas, pvz. lentelė, kuri savo pavadinimu ir turiniu pritrauktų nelegalaus vartotojo dėmesį. Bet koks kreipimasis į tokią lentelę būtų akivaizdus pavojaus signalas, parodantis, kad kažkas, net ir turėdamas priėjimo teises, bando naudotis informacija, kuri nėra jam skirta. Tokia stebėjimo sistema labai neapkrauna normalaus duomenų bazės funkcionavimo ir jos generuojamų pavojaus signalų skaičius yra labai nedidelis. Atskira tokios “medaus puodynės” posistemė gali informuoti sistemos administratorių realiame laike, siekiant kaip galima anksčiau identifikuoti nelegalią veiklą ir užkirti kelią jau pačioje jos pradžioje.

2. Informacija apie “Medaus puodynes”, IDS sistemas ir Oracle duomenų bazę

2.1. Informacijos apsaugos tipai

Informacijos saugumas įgyja vis didesnę reikšmę mūsų gyvenime. Organizacijos stengiasi apsaugoti ją vis įvairesniais būdais ir sudėtingesnėmis sistemomis. Tradiciniai apsaugos būdai remiasi dviem pagrindiniais metodais: a) Pagal įvairius požymius yra tikrinamas autentiškumas, bandant prileisti prie informacijos tik tuos vartotojus,

kuriems galima naudotis šia informacija. Tam naudojama labai daug įvairių tipų sistemų, kurios tikrina vartotojų autentiškumą slaptažodžių, magnetinių kortelių, kodavimo, biometrinės informacijos ir t.t. pagalba. Prie šio metodo galima priskirti ir ugniasienes.

b) Įsilaužėlio aptikimo sistemos (IDS) – tai sistemos, kurios stebi viską, kas vyksta jūsų sistemoje ar tinkle ir lygina visus veiksmus su savo duomenų baze, kurioje yra surašyta didelė dalis žinomų įsilaužimo “schemų”, kitaip dar vadinamų parašais. Sutapus parašui, skelbiamas aliarmas (pranešama sistemos administratoriui). Tokių sistemų pagrindinis trūkumas – didėlė dalis aliarmų klaidingi ir dėl didelio informacijos kiekio sunku atrinkti tikrus puolimus.

Abu šie metodai yra efektyvūs, saugant informaciją nuo jos vagysčių, bet nėra tinkami, norint tirti įsilaužėlio veiksmų seką ir naujus metodus, taip pat norit gauti naujausių įsilaužimo priemonių (exploit) pavyzdžius. Tokiam tikslui siūlyčiau naudoti “Medaus puodynes” (HoneyPot).

2.2. Medaus puodynės veikimo principas

“Medaus puodynė” dažniausiai siejama su dedikuotu serveriu. Šio metodo tikslas - duomenų srautą, ateinantį į “Medaus puodynę”, paskelbti įtartinu, nes normaliomis aplinkybėmis niekas neturi kreiptis į ją. Taigi, “Medaus puodynė“ galėtų buti ir normalus (be programinių saugumo spragų) serveris, kuris realiame gyvenime nieko nedaro, t.y. neturi gauti tikrų kreipinių. Jei ši sąlyga išpildyta, tai visą duomenų srautą galima laikyti įtartinu ir analizuoti kaip galimus įsilaužimus.[1-2]

Labai svarbu apsaugoti visą likusį organizacijos tinklą nuo galimo įsilaužėlio, kuris gali viešpatauti mūsų “Medaus puodynėje”. Todėl dažniausia “Medaus puodynė” yra iškeliama už ugniasienės (į išorę) (Schema numeris 1). Tačiau patraukti“Medaus puodynę” per toli nuo realiai veikiančių serverių negalima, nes tada iš jos neliks jokios naudos. Taip pat “Medaus puodynė” nebebus patraukli įsilaužėliui, nes ji nebus visos sistemos dalis. Labai svarbu parinkti tinkamą adresą. Jis turėtu būti įsimaišęs kažkur tarp realiai veikiančių serverių, tada viso potinklio skanavimo metu bus įtrauktas į serverių tarpą.

“Medaus žymės” (“honeytoken”) terminas buvo pirmą kartą paminėtas Augusto Paes De Barros 2003 metais. Honeytoken panašus į honeypot. Jūs jį instaliuojate ir paliekate, laukdami, kol kas nors pradėtų juo domėtis. Kiekvienas honeytoken “lietimas” – tai greičiausiai neautorizuotas arba kenkėjiškas vartojimas. [3]

2.2.1. Oracle duomenų bazės saugumo priemonių struktūra

Duomenų bazės saugumui yra skirta nemažai dėmesio. Saugumo priemonių visuma susideda iš daugelio dalykų, tokių kaip auditas, rolės, privilegijos, grupės. Visa tai leidžia lanksčiai tvarkyti duomenų bazę. Kiekvienas vartotojas turi jam priskirtas roles, grupes, ir t.t. Jos yra aprašytos tam tikromis taisyklėmis, kurios leidžia atlikti tam tikrus veiksmus, visa kita draudžiama. Svarbu paminėti, kad vartotojas gali turėti ne vieną , o kelias roles, taip pat priklausyti kelioms grupėms. Tai leidžia lanksčiau suskirstyti vartotojų teises. Tai yra labai svarbu, nes kaip jau minėta ankščiau, iš aplikacijų, tiesiogiai dirbančių su duomenų baze, nėra sunku ištraukti slaptažodžius ir, prisijungus per komandinę eilutę, išgauti daugiau informacijos.

– 574 –

Duomenų bazių lygmens įsiskverbimų detektavimo sistemos

Duomenų bazėje yra standartinių rolių, grupių ir t.t, jos leidžia greitai organizuoti darbą, tačiau reikia nepamiršti, kad yra plačios galimybės kuriant ir keičiant jas patiems.

Pav.1. Vidinio tinklo srtruktūra

2.2.2. Išoriniai procesai

Oracle turi galimybę naudotis išorinėmis bibliotekomis, tokia savybė, įgalinanti ką nors prijungti prie jau veikiančios duomenų bazės, yra labai naudinga. Detali schena aprašymas pateikta Pav.2.

Pav.2. DBVS Oracle sąveika su išoriniais procesais

Ši schema atvaizduoja duomenų bazės sąsają su išorinėmis procedūromis. Tam tikslui yra specialiai paruoštas procesas, vadinamas Extproc. Šį procesą iškviečia Oracle “listener’is”. “Listener’is” – tai programa, atsakinga už

– 575 –


ryšio sudarymą tarp Oracle duomenų bazės ir vartotojo klientinės dalies. Oracle kūrėjai pasirinko labai nestandartinį būdą komunikacijai su išorinėmis bibliotekomis. Todėl labai svarbu gerai suprasti, kaip jis veikia.

Pasirinkdami tokį būdą, Oracle kūrėjai norėjo pateikti tik vieną galimybę susisiekimui tarp išorės ir vidaus - tai “listener” procesas.

3. Reikalavimai duomenų bazės “honeytoken” moduliui

Realiai veikiančios sistemos sukūrimui labai svarbu laiku suformuluoti sistemos struktūrą, tikslus ir laukiamus rezultatus.

3.1. Tikslai ir uždaviniai

Panaudojimas:

• Nelegalios veikos fiksavimas;

• Reagavimas;

• Bet kurio objekto, esančio duomenų bazėje, stebėjimas;

• Bet kokių automatinių veiksmų atlikimas.

“Honeytoken’ų” naudojimas pasireiškia tuo, kad:

• Gerėja duomenų bazės apsaugos lygis,

• Nustatomi vidiniai vartotojai-piktadariai,

• Log’ai gali būti panaudoti įsilaužimo bei duomenų vagystės metodų analizei.

3.2. Reikalavimai

Atsižvelgiant į “honeytoken” apibrėžimą ir naudojimo tikslus, buvo parengti tokie reikalavimai “honeytoken” moduliui:

1. modulis turi būti ne atskira sistema, o DBVS integruota dalimi;

2. modulyje neturi būti specialiai neužlopytų saugumo skylių;

3. modulis turi būti specializuotas vidinių įsilaužėlių detektavimui, nes 80% beveik duomenų vagysčių įvykdo kompanijos darbuotojai;

4. modulis neturi atrodyti įtartinas įsilaužėliui ir saugoti panašius-į-tiesą duomenis. Pavyzdžiui, lentelėje “DARBUOTOJAI” turi būti dideli kiekiai tikrų vardų bei pavardžių su atitinkamais nerealiais atlyginimais ir socialinio draudimo numeriais.

5. modulis negali generuoti false-positives ir false-negatives;

6. modulio naudojimas neturi prieštarauti valstybės ir tarptautiniams įstatymams;

7. modulio realizavimas turi būti pigus , paprastas diegimas ir administravimas paprasti;

8. modulis turi mokėti stebėti bet kokio tipo duomenų bazės objektą.

4. Realizacija

Aprašomos “honeytoken” modulių koncepcijos buvo pirmą kartą pasiūlytos ir aptartos [4-5].

4.1. Mūsų siūlomi sprendimai duomenų bazių apsaugai

1. panaudoti lentele apsimetančia funkciją (pipelined function), kuri kreipsis į išorinę procedūrą.

2. panaudoti trigger’į, kuris savo ruožtu kreipsis į išorinę procedūrą. Šis metodas išpildo visus iškeltus reikalavimus. Vienintelis jo minusas - jo sudėtingumas.

3. panaudoti Oracle Fine Grained Auditing (FGA) ir, pasinaudojus šia Oracle galimybe, kreiptis į išorinį procesą. Šis metodas yra universaliausias ir paprasčiausias, vienintelis jo minusas – jis atsirado tik pradedant Oracle 9i versija.

– 576 –


4.2. Apribojimai

1. lentele apsimetanti funkcija (piplined function) nėra parodoma bendrame lentelių sąraše, taigi įsilaužėlis gali tiesiog jos nepastebėti.

2. Trigger’is gali stebėti tik “insert” ir “update” funkcijas, o svarbiausia yra stebėti duomenų vagystę (select), o ne pakeitimą. Tačiau Oracle turi galimybę registruoti įvykius (log), visi įrašai apie atliktus veiksmus bus įrašomi į specialią lentelę, čia atsiranda galimybė trigger’iui stebėti “insert” funkciją ir reaguoti.

3. Geriausias būdas Fine Grained Auditing (FGA), tačiau, kaip jau minėta, jis neveiks ankstesnėse nei Oracle 9i versijose.

4.3. Specialios funkcijos (pipelined function) realizacija

• Sukuriame objektą, analogišką musų lentelei :

CREATE OR REPLACE type tabview as object

(Reg_Date Timestamp,

Surname varchar2(20),

Name varchar2(15),

Personal_number varchar2(11));

• sukuriame tabview table:

create type tabview_table as table of tabview;

• sukuriame:

CREATE or REPLACE function Salaries

return tabview_table pipelined as

cursor c1 is

select Reg_Date, Name, Surname, Personal_number

from Salaries;

begin

for c1_row in c1 loop

shellas('/usr/bin/aliarmas);

PIPE ROW(tabview(c1_row.Reg_Date, c1_row.Name, c1_row.Surname, c1_row.Personal_number));

end loop;

return;

end Salaries;

Dabar, vos tik įsilaužėlis pabandys išgauti informaciją iš šios funkcijos, apie tai iškart bus pranešta administratoriui.

4.4. Trigerių ir išorinių procedūrų kombinacija

Pav. 3 matome mūsų DB “honeypot’o” schemą Oracle viduje. Pseudo ryšiai parodyti punktyrinėmis linijomis. 1. DBMS Oracle gali paleisti išorines bibliotekas, tačiau nėra numatyta galimybė paleidinėti išorines programas,

taigi mes sukuriame biblioteką, kuri tiesiog paleidinės išorinę nurodytą progamą : void sh(char *);

int sh( char *cmd ) {

int num;

num = system(cmd);

return num;

}

Ši biblioteka turi būti sukompiliuota su specialiomis Oracle bibliotekomis. Po kompiliavimo proceso,

– 577 –


gautąją biblioteką (shelllib.so) reikia užregistruoti:

CREATE OR REPLACE LIBRARY shell_lib is ‘/opt/oracle/product/9.2.0/lib/shelllib.so';

Pav. 3. Honeytoken modulio schema trigerių/išorinių procedūrų atveju.

2. Sekantis žingsnis - aliarmo programos kūrimas. Tam demonstraciniais tikslais parašėme paprastą “bash skriptą”, kuris paprasčiausiai išsiunčia pranešima administratoriui:

(GNU bash, version 2.05b.0(1)-release (i686-pc-linux-gnu)).

#!/bin/bash

echo "===============================" >> /var/log/orcl.alerm

echo "Beginning of the record" `date` >> /var/log/orcl.alerm

lsof -i |grep oracle >> /var/log/orcl.alerm

echo "End of the record"

echo `date` >> /tmp/tmp.orc

lsof -i |grep oracle >> /tmp/tmp.orc

cat /tmp/tmp.orc | sendmail [email protected]

rm /tmp/tmp.orc

log file’as atrodys

==========================================

– 578 –


Beginning of the record Tue Jun 1 18:34:21 EEST 2004

oracle 1032 1758 12u IPv4 3115 UDP localhost:32768

oracle 1032 1758 13u IPv4 3144 TCP herkus.stml.lan:32770->herkus.stml.lan:1521 (ESTABLISHED)



oracle 1050 1758 13u IPv4 3139 TCP *:32769 (LISTEN)

oracle 21079 1758 14u IPv4 73200 TCP herkus.stml.lan:1521->212.122.76.172:3645 (ESTABLISHED)


oracle 21083 1758 14u IPv4 73210 TCP herkus.stml.lan:1521->212.122.76.172:3651

...

oracle 21224 1758 14u IPv4 95660 TCP herkus.stml.lan:1521->b25.vtu.lt:62514 (ESTABLISHED)


oracle 21230 1758 14u IPv4 95674 TCP herkus.stml.lan:1521->b25.vtu.lt:63189 (ESTABLISHED)

...

End of the record

3. Sekantis žingsnis - TNSNAMES.ORA ir LISTENER.ORA konfigūravimas, suteikiantis galimybę kreiptis į išorines bibliotekas.

4. Toliau galime sukurti Oracle procedūrą, kurią kviesime kiekvieną kartą, kai įsilaužėlis bandys prieiti prie mūsų stebimos lentelės:

CREATE or REPLACE procedure shellas(cmd IN char) as external name "sh" library shell_lib language C parameters (cmd string);

5. Toliau kuriame lentelę su “saldžiu” pavadinimu: CREATE TABLE Salaries (

Reg_Date Timestamp,

Surname varchar2(20),

Name varchar2(15),

Personal_number varchar2(11));

6. Paskutinis žingsnis – audito įjungimas: CREATE trigger danger

after insert

on Salaries_audit

for each row

begin

shellas('/usr/bin/alert’);

end danger;

Nuo šiol, kiekvieną kartą, kai įsilaužėlis bandys prieiti prie lentelėje saugomų duomenų, aktyvuosis trigger’is “danger” ir bus išsiunčiamas pranešimas administratoriui.

3.5. Oracle Fine Grained Auditing (FGA) ir išorinės procedūros kombinacija.

FGA mums suteikia galimybę stbėti užklausas “select” ir paleidinėti procedūras, nenaudojant trigerio:

• FGA įjungimas:

execute dbms_fga.add_policy

(object_schema=>'employee',

object_name=>Salaries,

policy_name=>'Salaries_ACCESS',

– 579 –


handler_schema=>'sys',

handler_module=>'shellas');

• Pažiūrėti audito rezultatus:

SELECT timestamp,

db_user,

os_user,

object_schema,

object_name,

sql_text

FROM dba_fga_audit_trail

WHERE object_name = ‘Altyginimai’;

4. Išvados

“Honeytoken” – tai viena iš naujausių duomenų bazių apsaugos priemonių. Jie gali pagerinti duomenų bazės ir bendrą sistemos saugumą.

Mes pasiūlėme tris koncepcinius “honeytoken” modulius DBVS Oracle 9i EE. Jie remiasi “honeypot” technologijos principu, kuris padaro atskirą, neturintį realios vertės resursą pažeidžiamu, ir pritraukia tokiu būdu įsilaužėlius kaip iš išorės, taip ir iš vidaus.

Šitie moduliai buvo sukurti atsižvelgiant į “honeytoken’ų” naudojimo tikslus bei uždavinius, kurie taip pat buvo aptarti šitam straipsnyje. “Honeytoken” moduliai buvo sukurt, naudojanis nemokamomis programinėmis priemonėmis, instaliuoti ir išbandyti Vilniaus Gedimino technikos universiteto Skaičiavimo technikos mokomojoje laboatorijoje.

Duomenų bazėms su dideliu įrašų bei vartotojų skaičiumi”honeytoken” moduliai gali būti labai efektyvia priemone, nustatant įsilaužimus bei duomenų vagyses. Bet reikia atkreipti dėmesį ir į tai, kad, nepaisant daugelio pliusų, tokių kaip koncepcijos paprastumas ir efktyvumas, “honeytoken” tipo produktai negali pilnai apsaugoti duomenų bazės nuo visų pavojų ir atstoti klasikinių apsaugos priemonių.

Literatūros sąrašas [1] L. Spitzner, “Honeypots: Definitions and Value of Honeypots”, http://www.tracking-hackers.com/papers/honeypots.html,

2003. [2] B.Cheswick, “An evening with Berferd in which a Cracker is Lured, Endured, and Studied”, http://www.tracking-

hackers.com/papers/berferd.pdf , 1991 [3] L. Spitzner, “Honeytokens: The Other Honeypot”, http://www.securityfocus.com/infocus /1713, 2003. [4] D. Rainys, A. Bielko, A. Čenys, “Enhancing IDS - Honeypot Systems”, 4th Conference on Informatics and Information

Technology, Macedonia: 2003 in press. [5] D. Rainys, L.Radvilavičius, A. Čenys, “Development of Honeypot System Emulating Functions of Database Server”,

NATO konferencijos “Symposium on Adaptive Defense in Unclassified Networks” 2004 balandžio 19-20, Tulūza, Prancūzija.

[6] C. Stoll, “Cuckoo's Egg: Tracking a Spy Through the Maze of Computer Espionage”, Pocket Books, New York, 1990. [7] B. Schneier, J. Wiley, “Secrets And Lies: Digital Security in a Networked World”, John Wiley & Sons, 2000.

Database Level Intrusion Detection Systems

The most valuable information often is stored in databases. Due to this database security is of great importance. It is very complex task, however, to ensure database security without limiting capabilities and speed for legal users Honeytokens are one of the new methods to increase information security. The method uses fake information resources to attract illegal users and identify them. In this work the implementation of honeytoken module for Oracle 9iR2 database management system is described. Original module was programmed to combine Oracle Fine-Graned auditing features, internal triggers and functions reporting on illegal access to fake resource.

– 580 –

http://www.tracking-hackers.com/papers/honeypots.html

http://www.tracking-hackers.com/papers/berferd.pdf

http://www.tracking-hackers.com/papers/berferd.pdf

http://www.securityfocus.com/

RELIACINIŲ DUOMENŲ BAZIŲ VALDYMO SISTEMŲ SAUGUMO PRINCIPAI IR JŲ ĮGYVENDINIMAS

Nikolaj Goranin1 ,Antanas Čenys1,2, Darius Rainys2,3 1 VGTU, Saulėtekio 11, LT-10223, Vilnius, Lietuva

[email protected] 2 Puslaidininkių fizikos institutas

A.Goštauto11, LT-01108, Vilnius, Lietuva [email protected]

3.UAB ”BlueBridge”, Jasinskio g. 16, Vilnius, Lietuva

[email protected]

Šiuo metu dideli informacijos kiekiai saugomi reliacinių duomenų bazių valdymo sistemų (RDBVS) pagalba. Duomenų koncentracija vienoje vietoje padidina jautrumą rizikos faktoriams. Straipsnio tikslas yra trumpai apibrėžti grėsmių tipus, jų lokalizaciją, aprašyti teorinius ir praktinius saugumo užtikrinimo principus, audito procedūras, paaiškinti jų svarbą. Atliktas saugumo auditas parodė, kad net komercinės RDBVS turi daugybę saugumo “skylių”. Saugumo auditas buvo atliktas pagal autorių paruoštą programą. Buvo testuojamas RDBVS Oracle 9i EE, veikianti Gentoo Linux 1.4 pagrindu. Audito rezultatai buvo palyginti su komercinių paketų pagalba (AppDetective for Oracle) gautais rezultatais.

1.Įvadas

Duomenų saugumo užtikrinimo problema yra labai aktuali šiuolaikiniame pasaulyje. Besivystant šiuolaikinėms kompiuterinėms technologijoms, augant jų naudojimui kasdieniniame gyvenime ir didėjant duomenų bankams, iškyla ir duomenų saugumo klausimas.

Neįmanoma užtikrinti duomenų saugumo, neapibrėžus pačios problemos, jos ribų. Tokia pat svarbi ir duomenų bazių pastovaus ir patikimo darbo problema. Tai ypač svarbu tokiose verslo srityse, kaip: bilietų rezervavimo sistemos, elektroninė bankininkystė, elektroninės parduotuvės. Seniai paruoštos bendros saugumo rekomendacijos kaip kompiuterinėms sistemoms apskritai, taip ir RDBVS sistemoms, kurias reikia adaptuoti ir pritaikyti kiekvienai konkrečiai eksploatuojamai sistemai. Bendrų ir konkrečių saugumo principų bei strategijų integracija, šiuolaikinių kompiuterinių ir nekompiuterinių saugumo priemonių panaudojimas, padeda užtikrinti saugų ir patikimą RDBVS sistemos darbą.

Ruošiant saugumo reikalavimus, būtina atlikti egzistuojančių grėsmių analizę, apsisaugojimo nuo jų priemones bei atlikti tų priemonių efektyvumo analizę. Ypatingas dėmesys buvo yra skiriamas DBVS auditui, nes tik veikiančios sistemos saugumo nuodugni analizė, tiksliai parodanti jos silpnas vietas, gali būti naujos patikimos saugumo sistemos, teisingų sprendimų priėmimo pagrindu. Šiuo metu Lietuvoje nėra įmonių, besispecializuojančių DBVS saugumo testavimo srityje. Tuo tarpu DBVS naudojimas sparčiai plinta (įmonių vidinei informacijai saugoti, MySQL naudojimas WEB aplikacijose, Oracle/DB2 bankininkystėje ir kitur). Bet kaip parodė atliktas veikiančios RDBVS sistemos testavimas, net brangūs komerciniai produktai (pvz. Oracle DBVS), netinkamai sukonfigūruoti ar prižiūrimi, gali turėti daugybę klaidų. Nekomerciniai produktai (MySQL, PostrgreSQL) irgi turi klaidų. Pavojus RDBVS sistemoms gali būti paslėptas serverio operacinėje sistemoje, darbo stotyse, nesaugiuose ryšio kanaluose ir daugelyje kitų vietų. Auditas padeda laiku nustatyti sistemos silpnas vietas, apsaugoti įmonę nuo svarbios informacijos praradimo ar išslaptinimo, jos vientisumo pažeidimo, išlaikyti gerą vardą bei reputaciją.

2. Grėsmės ir jų klasifikacija

Bet koks įvykis arba situacija, tyčiniai arba ne, galintys neigiamai paveikti sistemą, traktuojami kaip grėsmės. Duomenų bazės apsauga – duomenų bazės saugumo užtikrinimas prieš bet kurias tyčines ir netyčines grėsmes,

naudojant įvairias kompiuterines ir nekompiuterines priemones. (Šitas ir kiti 2–o skyriaus apibrėžimai pagal [1]). Apsaugos sąvoka taikoma ne tik duomenims ir DBVS. Saugumo “skylės” gali būti ar atsirasti ir kitose sistemos

dalyse, tokiose kaip: operacinė sistema, kiti programiniai paketai, aparatiniai trūkiai, kas savo ruožtu kelia grėsmę duomenims ir DBVS. Taigi, duomenų bazės apsauga turi aprėpti naudojamą aparatinę įrangą, programinius

– 581 –




N. Goranin, D. Rainys, A. Čenys

produktus, personalą ir pačius duomenis. Efektyviai apsaugai įgyvendinti reikalingos specialios kontrolės priemonės, kurių pasirinkimą lemia konkretūs reikalavimai, priklausantys nuo eksploatuojamos sistemos ypatumų.

Duomenų bazės apsaugos tikslas yra padėti išvengti žalos, keliamos grėsmėmis, arba ją minimizuoti. Saugumo sprendimai turi efektyviai išnaudoti skirtas lėšas ir kuo mažiau trukdyti sistemos vartotojams.

Duomenų bazė – pagrindinis įmonės informacinis resursas. Duomenų praradimas ar laikinas neprieinamumas gali padaryti didžiulę ekonominę žalą, sukelti reputacijos praradimą arba net bankrutavimą.

Duomenų vagystė gali įvykti ne tik iš DBVS terpės, tai liečia visą organizaciją. Konfidencialumas suprantamas kaip būtinybė išlaikyti duomenis slaptai. Konfidencialiais dažniausiai laikomi

tie duomenys, kurie yra laikomi gyvybiškai svarbiais visai organizacijai, tuo tarpu neliečiamumo sąvoka taikoma asmeniniams darbuotojų duomenims.

Vientisumo praradimas suprantamas kaip saugomos informacijos iškraipymas arba praradimas (pilnas arba dalinis).

Prieinamumo praradimas ypač pavojingas organizacijoms, teikiančioms paslaugas klientams visą parą be išeiginių. Prieinamumo praradimas reikš, kad arba duomenys, arba paslauga bus neprieinama vartotojams. Taip pat veiksmai, sukėlę neprieinamumą, gali tuo pat metu sukelti ir duomenų praradimą.

Žalingų veiksmų ir veiksnių poveikis dažnai būna kombinuotas, tai yra vienos iš sistemos dalių saugumo pažeidimas padidina visos sistemos pažeidžiamumą. Kai kurie įvykiai, tokie kaip asmeninių duomenų neliečiamumo pažeidimas arba duomenų vagystė yra sunkiai aptinkami, nes dažniausiai nebūna duomenų keitimo pėdsakų.

Žala taip pat gali būti klasifikuojama kaip tiesioginė (įrangos, programų, duomenų praradimas) ir netiesioginė (perspektyvių klientų praradimas, partnerių nepasitikėjimas).

Kiekvienos organizacijos tikslas yra visų galimų grėsmių išsiaiškinimas, kaip tyčinių (grėsmės šaltinis – autorizuotas arba neautorizuotas vartotojas), taip ir netyčinių.

Žemiau pateikiamoje lentelėje 1 parodoma, kokią žalą duomenų bazei gali padaryti įvairūs vartotojų veiksmai, nelaimingi įvykiai, avarijos ir kenkimo būdai:

1 lentelė. Žalą sukeliantys įvykiai

Žala

Veiksmai/įvykiai

duomenys pavogti arba falsifikuoti

prarastas duomenų

konfidencialumas

pažeistas asm. duom.

neliečiamumas

vientisumo praradimas

duomenų laikinas

neprieinamumas

Kito žmogaus teisių naudojimas X X X

Nesankcionuotas duomenų keitimas ar kopijavimas X

Programų keitimas X X X Konfidencialių ir eilinių duomenų saugojimas tame pačiame dokumente

X X X

Nesankcionuotas prisijungimas prie tinklų X X X

Piktybinis duomenų keitimas piktadariais X X X

Saugumo “skylės” sistemoje X X X

Sistemos lūžiai dėl didelio užklausų kiekio X X X X

Personalo trūkumas X X Personalo žemas profesionalumo lygis X X X X

Užslaptintų duomenų nesankcionuotos išslaptinimas

X X X

Elektromagnetinių bangų bei spinduliavimo poveikis įrangai

X X

Elektros įtampos dingimas X X Gaisrai, diversijos, stichinės nelaimės X X

Fiziniai įrangos gedimai X X

– 582 –

Reliacinių duomenų bazių valdymo sistemų saugumo principai ir jų įgyvendinimas

Kabelių nutrūkimas X X Kompiuteriniai virusai X X

Nuostolių lygis priklauso nuo daugelio faktorių, tokių kaip numatytos atsakomosios priemonės ir saugumo

politika. Kiekvienai organizacijai, naudojančiai savo veikloje kompiuterines duomenų bazių valdymo sistemas, būtina

įvertinti rizikos faktorius, suskirstyti juos pagal tikimybes. Tačiau finansavimas apsaugai turi būti skiriamas ne tik pagal grėsmės tikimybę, bet ir pagal jos padaromą žalą, tai yra neapsimoka skirti didelių pastangų ir finansavimo apsaugai nuo grėsmės, padarančios mažą žalą. Paveikslėlis 1 parodo ryšį tarp grėsmių ir jų atsiradimo vietų.

1 pav. Grėsmės ir jų lokalizacija.

3. Apsaugos priemonės

Duomenų bazės apsaugai nuo aukščiau išvardytų grėsmių taikomos įvairios priemonės, pradedant fiziniu stebėjimu ir baigiant administraciniais-organizaciniais nurodymais. Nepaisant plataus kompiuterinės kontrolės bei apsaugos priemonių spektro, bendras DBVS apsaugotumo lygis labiausiai priklauso nuo naudojamos operacinės sistemos, kadangi šių dviejų komponentų darbas yra tampriais susijęs.

3.1. Bendri IT sistemų saugumo principai ir strategijos

DBVS apsaugos mechanizmai gali remtis vienu ar keliais saugumo principais bei strategijomis. Principai:

• Paranojos principas – DBVS turi užtikrinti visus reikalingus veiksmus, kad vartotojas u negalėtų prieiti prie nustatyto duomenų rinkinio S(U), kuris turi išlikti slaptas vartotojui.

• Atsargios kooperacijos principas – Jeigu vartotojo užklausa gali būti įvykdyta, naudojantis viešąja informacija, tuomet užklausų tarpininkas atsakys į užklausą, nebent tai tiesiogiai gali paveikti sistemos

– 583 –


globalius saugumo nustatymus. Taip pat atsižvelgiama į tai, ar kiekvienas iš paketų nepažeidžia lokalių saugumo nustatymų.

• Atsargios ir konservatyvios kooperacijos principas - Jeigu vartotojo užklausa gali būti įvykdyta, naudojantis viešąja informacija, tuomet užklausų tarpininkas atsakys į užklausą, nebent tai sukels seką užklausų, kuri gali paveikti sistemos globalius saugumo nustatymus. Taip pat atsižvelgiama į tai, ar kiekvienas iš paketų nepažeidžia lokalių saugumo nustatymų. [2]

Bet kokiai kompiuterinei sistemai apsaugoti gali būti pasirinkta viena ar kelios iš žemiau išvardytų strategijų : • Mažiausių privilegijų – Ši strategija pabrėžia, jog bet kuris su sistema susijęs objektas (vartotojas,

administratorius, programa, sistema) privalo turėti ne platesnes privilegijas nei tos, kurių reikia atlikti visiems objektui priskirtiems uždaviniams.

• „Gilios“ apsaugos strategija – Remiantis šia strategija, negalima pasikliauti priklausomybe nuo vienintelio saugumo mechanizmo, kad ir koks nepažeidžiamas jis atrodytų. Būtinas saugumo sistemų dubliavimas.

• Saugumo požiūrių strategija – Ši strategija grindžiama vieno iš dviejų fundamentalių požiūrių į saugumo politiką pasirinkimu (1. Leista tik tai, kas yra oficialiai leista; 2. Leista viskas, kas nėra oficialiai uždrausta)

• Paprastumo strategija – Naudojant paprastą saugumo sistemą išvengiama konfigūravimo klaidų, rekomendacijų vykdymo vengimo, neaiškumų.

• Saugumo per neaiškumą strategija – Šios strategijos esmė yra neįprasta konfigūracija, arba ta, kurią sunku suprasti. Tai gali būti nestandartinių prieigų parinkimas teikiamiems servisams, netradicinė duomenų ar konfigūracinių failų lokalizacija.

3.2. Kompiuterinės apsaugos priemonės

Pagrindinės kompiuterinės apsaugos priemonės: • vartotojų autorizacija; • atvaizdavimai (“views”); • rezervinis kopijavimas ir atstatymas; • vientisumo palaikymas; • kopijavimas/atstatymas • kitos

Vartotojų autorizacijos priemonės dažniausiai yra integruotos į programinę įrangą ir valdo ne tik vartotojo teises į sistemą ir jos objektus, bet ir nustato rinkinį operacijų, kurį vartotojas gali taikyti kiekvienam konkrečiam prieinamam objektui. Taikomosios programos taip pat traktuojamos kaip vartotojai ir turi pateikti DBVS slaptažodį. Rekomenduojama saugoti duomenų bazės vartotojų identifikatorius ir slaptažodžius atskiroje užkoduotoje lentelėje. Tai leidžia lengvai vesti vartotojų apskaitą ir kontrolę. [3] DBVS vartotojui turi tam tikras privilegijas,kurių suteikimas remiasi vienu iš dviejų pagrindinių saugumo mechanizmų: mandatų ir diskretinio.

Mandatų saugumo mechanizmas (MLS –multilevel secure) – naudojamas, kai reikia užtikrinti kelių lygių saugumo sistemą, klasifikuojančią duomenis ir vartotojus į kelias klases arba lygius, įgyvendinančius organizacijos saugumo sistemą. Tipiniu pavyzdžiu galėtų būti skirstymas į tokias klases: TS (Top Secret – Visiškai Slapta), S (Secret - Slaptas), C (Confidencial - Konfidencialus), U(Unclassified - Nenustatytas), kur TS>S>C>U. Tuomet vartotojas, priklausantis S klasei, galės naudotis S, C ir U klasės duomenimis. Šitas tipas dažniausiai naudojamas karinėse, valstybinėse bei mokslinėse organizacijose. Šiuo metu nėra plačiai naudojamas ir toliau detaliau nenagrinėjamas [3].

Diskretinis saugumo mechanizmas – naudojamas daugelyje komercinių produktų, kurio pagrindas yra teisių ir privilegijų suteikimas ir atėmimas. Valdymas grindžiamas priėjimo matricos bei modeliu. Diskretinis saugumo mechanizmas realizuotas standartuose SQL ir SQL2. [3]

Atvaizdavimas – vienos ar kelių reliacinių operacijų, atliktų su bazinėmis lentelėmis, dinaminis rezultatas. Atvaizdavimas – tai virtuali lentelė, kurios realiai duomenų bazėje neegzistuoja, bet sukuriama, vartotojui į ją kreipiantis. Atvaizdavimų mechanizmas – tai galinga ir lanksti duomenų apsaugos priemonė, leidžianti apsaugoti nuo tam tikrų grupių vartotojų dalį duomenų. Atvaizdavimas gali būti kuriamos vienos ar kelių lentelių pagrindu. Vėliau vartotojas gauna teises į atvaizdavimą, o ne į bazines lenteles. Tokiu būdu atvaizdavimas – tai griežtesnis priėjimo kontrolės mechanizmas, negu teisių išdavimas kiekvienai iš bazinių lentelių.

Rezervinis kopijavimas – periodiškai atliekama duomenų bazės ir žurnalinio failo (file journal) kopijavimo į informacijos kaupiklį, saugomą atskirai nuo sistemos, procedūra. Kaip nurodoma dokumente [4], sistemos, naudojamos surūšiuotos ar svarbios informacijos apdorojimui, privalo užtikrinti individualų žurnalinimą, nepriklausomai nuo to, naudojama mandatų ar diskretinė saugumo sistema.

– 584 –


Vientisumo palaikymo priemonės - taip pat svarbi duomenų bazės saugumo palaikymo dalis. Jų tikslas yra apsaugoti duomenis nuo perėjimo į nesuderintą būseną. Taip išvengiama nekorektiškų ar klaidingų rezultatų gavimo.

Šifravimas – duomenų kodavimas, naudojant specialų algoritmą, kurio dėka duomenų nuskaitymas tampa neįmanomas asmenims ar programoms, neturintiems specialaus dešifravimo rakto. Jeigu duomenų bazėje laikoma labai svarbi konfidenciali informacija, turi prasmę ją apsaugoti šifravimu, apsaugai nuo nesankcionuoto priėjimo iš išorės. Kai kurios DBVS turi tam pritaikytas integruotas šifravimo priemones. Tačiau šifravimo panaudojimas reikš tam tikrą darbo sulėtėjimą. Šifravimas taip pat naudojamas perduodant informaciją ryšio linijomis.

Procedūros, reglamentuojančios rezervinių kopijų kūrimą, nusakomos eksploatuojamos duomenų bazės tipu ir dydžiu, o taip pat atitinkamų įrankių rinkiniu, kurį turi DBVS. Didelės duomenų bazės turi būti kartą per savaitę ar net mėnesį, o inkrementinį (dalių) kopijavimą reikia atlikti žymiai dažniau. Kopijavimo laiką nustato atsakingi asmenys. Atstatymo procedūros, taip pat kaip ir kopijavimo, turi būti kruopščiai apgalvotos ir reglamentuotos. Vykdomos procedūros tipas priklauso nuo įvykusio gedimo tipo (kaupiklio lūžimas, programinės įrangos klaidos, įrangos gedimai). Atstatymo procedūrų patikimumas turi būti detaliai testuojamos. Taip galėsime garantuoti, kad duomenys bus atstatyti įvykus realiam lūžiui. Idealiu atveju, atstatymo procedūros turi būti testuojamos reguliariai su tam tikru nustatytu intervalu.

Tarp kitų gyvybiškai svarbių DBVS saugumo užtikrinimo priemonių negalima nepaminėti DBVS ir OS saugumo atnaujinimo diegimo, tinkamo kompiuterinio tinklo topologijos parinkimo (tarnybinės stotys turi būti atskirtos į DMZ), nebūtinų servisų pašalinimo, root vartotojo ribojimas,

3.3. Nekompiuterinės apsaugos priemonės

Nekompiuterinės apsaugos priemonės apima tokias priemones, kaip apribojimų, susitarimų ir administracinių priemonių, kūrimas. Jos nėra tiesiogiai susiję su kompiuterinių sistemų palaikymu.

Kaip yra žinoma, pagrindinis pavojus organizacijai labiau susijęs su pačios organizacijos darbuotojais, negu su išorinėm grėsmėm. Todėl aukštas personalo kontrolės lygis leidžia minimizuoti galimą pavojų.

Fizinės kontrolės reikalavimai dažniausiai numato, kad pagrindinė sistemos aparatinė įranga, o taip pat spausdintuvai, jei jie naudojami konfidencialiai informacijai spausdinti, turi būti laikomi atskiroje rakinamoje patalpoje, kuri prieinama tik ribotam specialistų skaičiui. Visa kita įranga turi būti saugoma patalpose su įrengta signalizacija. Taip pat turi būti numatyta atskira patalpa rezervinėms kopijoms laikyti (rezervinės duomenų bazių kopijos, sistemos kopijos, dokumentacija). Informacijos nešėjai (diskai, magnetinės juostos) turi būti laikomos nedegiuose seifuose. Kopijų registravimo tvarka numatyta specialiai parengtose procedūrose.

Svarbų vaidmenį vaidina ir įvairūs teisiniai aktai. Duomenų bazėse saugoma informacija neturi prieštarauti LR įstatymams. Būtinos duomenų bazėje saugomų asmeninių duomenų konfidencialumo garantijos [5]. Žemiau pateikiami Lietuvos standartai, apibrėžiantys reikalavimus DBVS ir kitų IT sistemų saugumo srityje:

• LST 15408 — Lietuvai adaptuotas ISO/IEC 15408 informacijos apsaugos vertinimo kriterijai (Information technology — Security techniques — Evaluation criteria for IT security). [6]

• LST 13335 — Lietuvai adaptuotas ISO/IEC 13335 standartas: IT saugumo valdymas (Information technology — Guidelines for the management of IT Security). [7]

3.4. Auditas

Vienas iš audito procedūros tikslų – nustatyti, ar visos numatytos apsaugos priemonės yra panaudotos ir ar apsaugos lygis atitinka nustatytus reikalavimus. Inspekcijos metu auditoriai turi ištirti naudojamas rankines procedūras, kompiuterines sistemas ir turimą dokumentaciją. Auditorių patikrinimas numato tokių procedūrų ir mechanizmų patikrinimą:

1. įvedamų duomenų tikslumo palaikymas; 2. duomenų apdorojimo procedūrų tikslumo palaikymas; 3. korektiškas testavimas, dokumentavimas ir palaikymas sukurtų programinių paketų; 4. nesankcionuoto programų keitimo perspėjimas; 5. vartotojų teisių, privilegijų išdavimo ir jų panaudojimo kontrolė; 6. dokumentacijos palaikymas aktualioje būsenoje; 7. saugumo politikos ir reagavimo į fors-mažorines aplinkybes planų analizė; 8. OS ir DBVS programinės įrangos instaliavimo ir palaikymo saugioje būsenoje analizė; 9. tinklo topologijos ir tinklinių apsaugos priemonių (ugniasienių, IAS ir kt.) analizė; 10. aparatinės įrangos atitikimo saugumo standartams analizė;

– 585 –


11. esamų saugumo reikalavimų pažeidimų paieška. Norėtume atkreipti dėmesį į ypatingą DBVS saugumo audito svarbą, tarp visų kitų saugumo priemonių, nes tik

veikiančios sistemos saugumo nuodugni analizė, tiksliai parodanti jos silpnas vietas, gali būti naujos patikimos saugumo sistemos, teisingų sprendimų priėmimo pagrindu.

4. RDBVS Oracle 9iR2 EE auditas

Oracle Enterprise 9iR2 RDBVS, kaip testavimo ir audito objekto pasirinkimą lėmė kelios priežastys. RDBVS Oracle Database 9iR2 yra viena iš klasikinių, seniausių ir plačiai naudojamų sistemų. [8]duomenimis, Oracle RDBVS užima pirmas eilutes visose „nominacijose“, išskyrus „Populiariausia RDBVS Windows platformai“), todėl jos audito programos sukūrimas turi ekonominę prasmę. Taip pat būtent šita RDBVS naudojama VGTU įrašams apie studijas saugoti, Fundamentinių mokslų fakulteto studentams ruošti, jai parengti ir dėstomi kursai ( http://medeine.vtu.lt ).

Audito programos sudarymas prasideda nuo tikrinamos DBVS bendros ir saugumo užtikrinimo mechanizmų analizės [9].

Schemoje (Pav.2) parodomi tarnybinės stoties herkus.stml.lan, kurioje instaliuota RDBVS Oracle ryšiai su lokaliu ir išoriniu tinklais, IP adresai, naudojami portai.

Kompiuterinės

klasėsVidinio tinklo(192.168.0.*) šakotuvas

Kiti serveriai herkus.stml.lan

eth0=192 168 0 201lotes.vtu.lt eth0=193.219.145.200 eth0 alias herkus.vtu.lt(193.219.145.201) eth1=192.168.0.254 redirect (193 219 145 201:1521 ->

WORLD

Prisijungimai: 1. iš klasių (LAN) 2. iš išorės per herkus.vtu.lt

SC

2 pav. RDBVS padėtis tinkle.

Atlikto audito esmė buvo net tik ir ne tiek patikrinti konkrečios RDBVS instaliacijos saugumą (nes daugelio reikalavimų universitete negalima įvykdyti dėl finansinių apribojimų bei mokymo proceso reikalavimų), kiek patikrinti pačios audito programos audito efektyvumą ir korektiškumą (palyginus su komerciniais produktais). Taip pat buvo siekiama įrodyti, kad net galingos komercinės RDBVS gali būti nesaugios, jei naudojama instaliacija “pagal nutylėjimą” bei nėra aiškios administravimo ir saugumo politikos. Oracle Enterprise 9iR2 RDBVS audito programa buvo rengiama pagal [10-12] reikalavimus. Remiantis audito rezultatais, buvo parengtos rekomendacijos, kaip “užlopyti” surastas saugumo spragas.

4.1. Duomenų rinkimo etapas.

Pradiniame audito etape renkami duomenys apie OS ir RDBVS: • Pateikiama tinklo diagrama (pav.2) • spausdinamos OS (inicializacijos skriptai) ir RDBVS konfigūracinių bylų išklotinės

(init<System/InstanceID>.ora, config.ora, listener.ora ); • spausdinamos OS (/etc/passwd, /etc/group) ir RDBVS (dba_users) vartotojų išklotinės; • renkama informacija apie vartotojų teises ir privilegijas (check_roles.sql) • specialų SQL skriptų pagalba tikrinama, ar nėra palikta DBA ir DB vartotojų su slaptažodžiais

pagal nutylėjimą (scanner.sql) • renkama informacija apie sisteminius nustatymus (konfigūracinių failų apribojimus, OS vartotojų

galimybes leisti tam tikras komandas, naudojamus servisus);

– 586 –

http://medeine.vtu.lt/


• renkama informacija apie saugumo atnaujinimų diegimą OS ir RDBVS; • sudaromas turimos dokumentacijos sąrašas; • renkami duomenys apie organizacijos saugumo politiką; • renkami duomenys apie aparatinę įrangą; • renkami duomenys apie duomenų bazės lenteles, ryšius, indeksus (layout.sql); • atliekami pagalbiniai testavimai; • renkama informacija apie tarnybinės stoties ir tinklų fizinę apsaugą; • renkama informacija apie DB naudojimo tikslus ir metodus.

4.2. Duomenų analizės etapas

Antram etape analizuojama pirmam audito etape gauta informacija. Vadovaujantys pradine informacija nustatyta daugybe saugumo pažeidimų OS (Gentoo Linux 1.4) ir RDBVS konfigūracijoje. Pateiksime tik keletą pavyzdžių:

• RDBVS tarnybinė stotis nėra izoliuota DMZ; • Procesas listener nėra apsaugotas slaptažodžiu (listener.ora) • Priėjimą prie tarnybinės stoties OS turi du nebūtini ir potencialiai pavojingi vartotojai; iš didelės grupės DB

vartotojų (pernai universitetą baigusių studentų) neatimtos vartotojų teisės; • Visi DB vartotojai gali laisvai gauti informaciją apie kitus vartotojus tiesiog įvykdžius SQL užklausą select

* from all_users; • Rasti DB vartotojai su nepakeistais slaptažodžiais pagal nutylėjimą

Check default user passwords ============================ Default : DBSNMP passwd is :DBSNMP Default : SCOTT passwd is :TIGER Default : ORDPLUGINS passwd is :ORDPLUGINS Default : LBACSYS passwd is :LBACSYS Default : OLAPSYS passwd is :MANAGER Default : ORDSYS passwd is :ORDSYS

Default : OUTLN passwd is :OUTLN • Vykdomieji Oracle failai turi nustatymus 0755, kai pagal Oracle security administrator guide turėtų būti

pakeisti į 0750 • Tarnybinėje stotyje veikia nereikalingi ir potencialiai pavojingi servisai:

nmap herkus.stml.lan

Starting nmap 3.50 ( http://www.insecure.org/nmap/ )

Interesting ports on herkus.stml.lan (192.168.0.201): (The 1651 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 21/tcp open ftp 1080/tcp open socks 1521/tcp open oracle 3333/tcp open dec-notes 4444/tcp open krb524 5555/tcp open freeciv 6666/tcp open irc-serv 8080/tcp open http-proxy

– 587 –


• Nėra įdiegti paskutinieji saugumo atnaujinimai nei operacinėje sistemoje, nei RDBVS. Tokiu būdu sistema tampa pažeidžiama standartinėms atakoms.

• Nėra aiškios saugumo politikos bei už jos vykdymą atsakingo asmens. • Aparatinė įranga neatitinka saugumo reikalavimų, prie tarnybinės stoties gali prieiti pašaliniai žmonės.

Čia nebuvo išvardyti visi standartinių RDBVS Oracle 9i saugumo reikalavimų pažeidimai, bet net tokio kiekio pažeidimų užtektų, kad praktiniais tikslais naudojama komercinė ar valstybinė duomenų bazė taptų pažeidžiama: tai yra galėtų būti prarastas konfidencialus, prieinamumas, vientisumas.

4.3. Rezultatų palyginimas.

Rezultatai, gauti naudojantis autorių parengta audito programa buvo palyginti su rezultatai, naudojant komercinį paketą AppDetective for Oracle [13]. Jie patvirtino pradinius audito rezultatus.

3 pav. Pažeidžiamumo testavimo rezultatai

4 pav. Audito rezultatai

5. Išvados

Audito rezultatai parodė, kad net moderni komercinė RDBVS gali būti lengvai pažeidžiama ir sėkmingai atakuojama, jei administruojant sistemą nesilaikoma saugumo reikalavimų, nėra vykdoma sisteminga saugumo politika. Parengtos audito programos ir AppDetective rezultatų palyginimas parodė programos korektiškumą ir išryškino jos lankstumą, galimybę analizuoti žymiai didesni kiekį sistemos parametrų (tokių kaip OS saugumas, dokumentacijos analizė, fizinės ir saugumo politikos analizė ir kt.), ko negali automatizuoti komerciniai produktai. Galima rekomenduoti naudoti mūsų programą kartu su automatizuotais įrankiais. Ateityje numatoma tartis dėl komerciniais tikslais naudojamų RDBVS Oracle 9i testavimo komercinėse ar valstybinių įstaigose, kad būtų galima nustatyti realią padėti RDBVS saugumo administravimo srityje bei daryti išvadas apie audito programos tobulinimo aktualumą.

– 588 –


Literatūros sąrašas [1] Т.Конноли, К.Бегг, А.Страчан. Базы данных. Проектирование, реализация и сопровождение. Теория и

практика.. Москва: Издательский дом “Вильямс”, 2001,1120p. [2] K.S. Candan, S. Jajodia, V.S. Subrahmaniant. Secure Mediated Databases. 12th International Conference on Data

Engineering (ICDE '96), 1996. [3] R.Elmasri, S.B.Navathe. Fundamentals of Database Systems. Redwood City: The Benjamin/Cummings Publishing

Company Inc, 1994, 1234 p. [4] Trusted Computer System Evaluation Criteria. DOD 5200.28-STD, GPO 1986-623-963. USA: Department of Defense,

1985 [5] S. Petniūnaitė. A. Markin. Reikalavimai duomenų apsaugai. “BlueBridge” seminaro "Informacijos apsaugos valdymas

įmonėje", įvykusio Vilniuje 2003 m. spalio 7-8 d. medžiaga. [6] ISO. International standard ISO/IEC 15408. Geneva: ISO copyright office, 1999. [7] ISO. International standard ISO/IEC 13335. Geneva: ISO copyright office, 2000. [8] DBMS Popularity. http://www.wintercorp.com [9] Oracle Corporation official site. http://www.oracle.com/ [10] Oracle Database Audit Program. http://www.auditnet.org [11] Oracle Penetration Test. http://www.pentest.co.uk [12] Pete Finnigan site. http://petefinnigan.com [13]] AppDetective site. http://www.appsecinc.com/products/appdetective/

Relational Database Security Principals and Their Realization

Huge amounts of information nowadays are stored by the means of relational database management systems (RDBMS). Concentrated data storage is sensitive to different threats. The goal of this paper is to describe threats, their types, theoretical and practical security principals, audit procedures. Article explains the necessity of these measures. Security audit has shown that there are “security holes” even in commercial RDBMS. Security audit was done according to the authors’ program using Application Security Inc program AppDetective. RDBMS Oracle 9i Database on Gentoo Linux 1.4 was tested. Additional security audit was done using with commercial products and results were compared.

– 589 –

http://www.wintercorp.com/

http://www.oracle.com/

http://www.auditnet.org/

http://www.pentest.co.uk/

http://petefinnigan.com/

http://www.appsecinc.com/products/appdetective/

LIETUVOS MAGISTRANTŪROS STUDENTŲ BAIGIAMŲJŲ DARBŲ, DAKTARO DISERTACIJŲ IR JŲ SANTRAUKŲ ELEKTRONINIŲ

DOKUMENTŲ INFORMACIJOS SISTEMA

Arūnas Franckevičius, Saulius Grigonis, Aleksandras Targamadzė, Antanas Štreimikis Kauno technologijos universitetas, Informatikos fakultetas, Informacinių technologijų diegimo centras

Studentų g. 50, LT-51368 Kaunas, [email protected], [email protected], [email protected], [email protected]

Straipsnyje nagrinėjamas Lietuvos magistrantūros studentų baigiamųjų darbų, daktaro disertacijų ir jų santraukų elektroninių dokumentų informacijos sistemos (IS) kūrimo poreikis. Nagrinėjami svarbiausi IS kūrimo etape iškylantys klausimai. Apibrėžiamos detalesnės analizės ir tyrimo reikalaujančios sritys, glaudžiai susijusios su IS kūrimu.

1. Įvadas

Magistrantūros studentų baigiamųjų darbų, daktaro disertacijų ir jų santraukų elektroninių dokumentų (toliau – ETD) kūrimas, saugojimas ir pateikimas pasaulinei akademinei visuomenei yra aktualus[12]. Nuo 1996 m. interneto tinkle veikia projektas “Tinklinė skaitmeninė tezių ir disertacijų biblioteka“ (angl. Networked Digital Library of Theses and Dissertations, NDLTD, http://www.ndltd.org), kuris aktyviai skatina naujų ir pilotinių ETD projektų vykdymą visame pasaulyje. 2005 m. pradžioje NDLTD dalyvauja 217 narys, vykdantis arba nusprendęs vykdyti savo ETD projektus, iš įvairių pasaulio universitetų (182) ir jų susivienijimų (7), kitų institucijų (28) [1].

2002 m. buvo parengtas projekto „Lietuvos ETD pilotinis projektas Baltijos šalims“ pasiūlymas UNESCO paramai gauti. Šis projektas buvo patvirtintas ir vykdytas nuo 2003 m. gruodžio 15 d. iki 2004 m. kovo 31d. Jame dalyvavo 14 Lietuvos universitetinių aukštųjų mokyklų ir Rygos technikos universitetas. Šio projekto rėmuose pradėtas Lietuvos magistrantūros studentų baigiamųjų darbų, daktaro disertacijų ir jų santraukų elektroninių dokumentų informacijos sistemos (toliau – ETD IS) kūrimas. Tolimesnis Lietuvos ETD IS kūrimas ir palaikymas siejamas su vykdomos nacionalinės programos “Informacinės technologijos mokslui ir studijoms” [2] (toliau – ITMiS) paprogramės „Lietuvos akademinis bibliotekų tinklas“ [3] (toliau – LABT) plėtra.

2. Lietuvos ETD IS poreikis

Greitas tinkamos mokslinės literatūros pasiekiamumas pagerina mokslinius tyrimus. Naudojant internetą nereikia vykti į biblioteką, laukti atsiunčiamos knygos ir gaišti laiką, ieškant kataloguose reikalingo šaltinio. Kiekvienas norėtų skaityti jam priimtinu laiku savo darbo vietoje.

Lietuvos ETD IS kūrimas atitinka pagrindinius NDLTD projekto siekius [1]: Tobulinti universitetinį išsimokslinimą, sudarant magistrantams ir doktorantams modernias sąlygas kurti elektroninius dokumentus, naudotis skaitmeninėmis bibliotekomis ir suprasti e. leidybą.

•

• • •

• •

Didinti mokslinių tyrinėjimų rezultatų, saugomų skaitmenine forma, pasiekiamumą. Mažinti tezių ir disertacijų pateikimo ir tvarkymo kaštus. Įgalinti studentus perteikti savo mintis turtingesniais apibūdinimais, realizuojamais daugialypės terpės technologijomis. Skatina universitetus plačiau atverti savo mokslinės informacijos lobynus. Pažangiau naudoti skaitmeninės bibliotekos technologiją.

Lietuvos ETD IS kūrimo darbus remia ir skatina Lietuvos Respublikos Švietimo ir mokslo ministerija. 2004 metų gruodžio 14 d. Lietuvos Respublikos švietimo ir mokslo ministro įsakymu Nr. ĮSAK-1955 buvo patvirtinti Lietuvos magistrantūros studentų baigiamųjų darbų, daktaro disertacijų ir jų santraukų elektroninių dokumentų informacijos sistemos kūrimo nuostatai [4][5]. Šių nuostatų parengimas ir patvirtinimas skatina Lietuvos universitetus aktyviau dalyvauti kuriant Lietuvos ETD IS.

– 590 –


3. Lietuvos ETD IS projektavimas

Lietuvos ETD IS kuriama kaip sudėtinė ITMiS paprogramės LABT dalis, kuri turi užtikrinti Lietuvos akademinėse institucijose parengtų magistrantūros studentų baigiamųjų darbų, daktaro disertacijų ir jų santraukų elektroninių dokumentų konvertavimą, įrašymą, saugojimą ir pateikimą Lietuvos ir pasaulio akademinei bendruomenei.

Kuriant Lietuvos ETD IS būtina pasirinkti perspektyvius ETD ir juos lydinčių metaduomenų pateikimo, saugojimo, paieškos ir keitimosi su NDLTD ir kitais nacionaliniais ETD projektais formatus ir standartus. Tuo tikslu buvo išnagrinėti plačiausiai pasaulyje ETD projektuose naudojami formatai, standartai ir protokolai, pvz.: XML, PDF, Dublin Core, UNIMARC, Z39.50, OAI-PMH ir kt.

Kiekvienam ETD turi būti taikomos autorių ir gretutinės teisės. ETD turi būti apsaugoti nuo atgaminimo ir platinimo, papildomai naudojant techninės apsaugos priemones. Būtina gauti autoriaus arba jo teisių savininko sutikimą įrašyti e. dokumentą į Lietuvos ETD IS.

Išanalizavus užsienyje vykdomus ETD projektus, galima išskirti Lietuvos ETD IS 4 pagrindinių teikiamų servisų grupes (1 paveikslas):

1. Dokumentų įrašymo servisai. Servisai skirti ETD ir juos lydinčių metaduomenų įrašymui į Lietuvos ETD IS.

2. Paieškos servisai. Servisai užtikrinantys ETD paiešką pagal įvairius kriterijus. 3. Dokumentų pateikties servisai. Šie servisai turi užtikrinti, kad ETD, saugoma saugykloje, bus pateikta

skaitytojams. 4. Metaduomenų surinkimo servisai. Užtikrina ETD metaduomenų pateikimą į NDLTD suvestinį

katalogą. Tikslinga iškirti dvi pagrindines ETD sudedamąsias dalis (1 paveikslas):

ETD - magistrantūros studentų baigiamųjų darbų, daktaro disertacijų ir jų santraukų elektroninis dokumentas;

•

• Metaduomenys – ETD lydintys metaduomenys.

1 pav. Lietuvos ETD IS teikiami servisai

Kuriant Lietuvos ETD IS vienas iš svarbiausių uždavinių yra ETD dokumento ilgalaikio saugojimo formato pasirinkimas.

– 591 –

A. Franckevičius, S. Grigonis, A. Štreimikis

3.1. ETD dokumento ilgalaikio saugojimo formatas

Paprastai ETD yra rengiami naudojant įprastus teksto redagavimo įrankius (tokius kaip MS Word, WordPerfect ir t.t.). Tačiau taip parengti ETD negarantuoja ilgalaikio saugojimo.

Išanalizavus ETD vykdomus projektus nustatyta, kad elektroninio dokumento ilgalaikiam saugojimui plačiausiai naudojami PDF (www.adobe.com) ir XML formatai [6]. Tačiau daugelis ekspertų pripažįsta, kad netolimoje ateityje PDF formatą gali tekti keisti XML formatu, kuris pradėtas plačiai taikyti kuriant elektroninių išteklių ilgalaikio saugojimo archyvus.

Pagrindinis PDF formato privalumas – jo orientacija į dokumento turinio atvaizdavimą tokiu, kokiu jį norėjo pateikti autorius. Tačiau PDF iki šiol negarantuoja ilgalaikio saugojimo.

Ilgalaikio saugojimo galimybes realizuoti geriau tiktų XML formatas. XML formatas turi ir kitų privalumų: XML yra žymių kalba, kuri įgalina įvairiapusišką atvaizdavimą, kuris nepriklauso nuo jo struktūros;

•

• XML leidžia tvarkyti metaduomenis lanksčiau ir dinamiškiau. ETD saugant XML formatu garantuojamas invariantinis ETD pateikimas iš archyvų įvairiais formatais, pvz.,

PDF, HTML, XML ir suteikiamos žymiai platesnės galimybės kuriant, saugojant ir pateikiant ETD su daugialypės terpės elementais (garsais, vaizdais ir pan.)[6].

Tačiau ETD dokumento, paremto XML formatu, kūrimas reikalauja daugiau pastangų, didesnio žinių kiekio bei papildomų apmokymų nei taikant PDF. XML ETD DTD (angl. Document Type Definition, liet. dokumento tipo aprašas) sukūrimas yra sudėtingas, reikalaujantis daug laiko ir žmoniškųjų resursų. Šiuo metu dar nėra efektyvių priemonių saugoti daugialypės terpės objektus XML dokumentuose. Šie klausimai reikalauja detalesnio tyrimo.

3.2. Metaduomenys ir ETD paieška

Viena geriausių informacijos paieškos sistemų yra bibliotekinės informacijos sistemos viešo naudojimo katalogas (OPAC). Taip yra todėl, kad bibliotekų e. katalogai sudaryti iš struktūrizuoto formato (Lietuvoje naudojamas UNIMARC) bibliografinių įrašų, kurie leidžia atlikti išsamią paiešką pagal norimus požymius. Tačiau išsamius bibliografinius įrašus gali parengti tik kvalifikuoti bibliotekininkai, nes įrašų parengimo kokybė lemia pačios paieškos galimybę ir kokybę. LABT projekte e. katalogai kuriami naudojant pasaulyje pripažintą bibliotekinę sistemą ALEPH 500 (toliau – ALEPH 500 BIS) [7].

Įvertinus visą sukauptą LABT projekte naudojamų ALEPH 500 BIS, Metalib [8] ir SFX [9] programinių produktų taikymo patirtį teikiant e. bibliotekos servisus, galima teigti, kad nereikia kurti atskiros ETD dokumentų paieškos sistemos [10]. LABT projekte naudojamos ALEPH 500 BIS, Metalib ir SFX užtikrintų efektyvią ETD dokumentų paiešką ir pateikimą, jeigu šių dokumentų rengėjai kartu pateiktų tinkamai struktūrizuotus ir standartizuotus duomenis (metaduomenys) apie pateikiamus dokumentus. Metaduomenimis vadinamas elementų ir požymių rinkinys, būtinas aprašyti spausdintam dokumentui ar e. ištekliui. Tam tikslui yra patvirtintas Dublin Core standartas, kuris apibrėžia 15 metaduomenų elementų (angl.: Title, Creator, Subject, Description, Publisher, Contributor, Date, Type, Format, Identifier, Source, Language, Relation, Coverage, Rights). Tikslinga, kad ETD, teikiamų į Lietuvos ETD IS, autoriai kartu pateiktų ir savo baigiamuosius darbus aprašančius metaduomenis automatiškai pervedamus į Dublin Core standartą.

Dublin Core standarto panaudojimas leidžia automatizuotai įkelti ETD archyve saugomus metaduomenis į ALEPH 500 BIS ETD e. katalogą UNIMARC formatu. Tokiu būdu garantuojama ETD dokumento paieška naudojant Metalib ir ALEPH 500 BIS.

Dublin Core metaduomenų standartas naudojamas ir pateikiant duomenis NDLTD suvestiniam katalogui (OAI-PMH protokolo pagalba). Taip užtikrinama galimybė pateikti Lietuvos ETD IS sukauptus ETD ir pasaulio akademinei visuomenei.

3.3. Ilgalaikis saugojimas

Viena iš pagrindinių Lietuvos ETD IS funkcijų yra garantuoti patikimą, saugią ir užtikrinančią ilgalaikį saugojimą skaitmeninę saugyklą. Kuriant tokią saugyklą reikia taikyti pasaulyje pripažintus ir plačiai naudojamus duomenų ilgalaikio saugojimo standartus, kurie užtikrintų ETD pateikimą kitom kartom.

Iki šiol nėra patvirtintų standartų ar plačiai naudojamų metodų užtikrinančių daugialypės terpės objektų saugojimą XML formatu. Todėl daugialypės objektų ilgalaikiam saugojimui paprastai taikomi plačiai paplitę skaitmeniniai duomenų saugojimo formatai, pvz., BMP, AVI, MP3, JPEG, DWG [6].

Dauguma žinomų skaitmeninių saugyklų naudoja XML savo vidiniu formatu. Siekiant paspartinti Lietuvos ETD IS tinklinės skaitmeninės saugyklos kūrimo darbus tikslinga atlikti populiariausių pasaulyje atviro kodo tinklinių skaitmeninių saugyklų, tokių kaip Fedora, DSpace, ePrints, CDSware ir pan., detalią analizę. Tikslinga

– 592 –

susipažinti ir su komerciniais skaitmeninių saugyklų projektais, pvz. Adobe korporacijos veikla ETD dokumentų rengimo ir ilgalaikio saugojimo srityje.

Kuriant ilgalaikio saugojimo skaitmeninę saugyklą, reikėtų atsižvelgti, kad dauguma internetinių nuorodų į e. objektus remiasi konkrečia e. šaltinio buvimo vieta. Pasikeitus e. šaltinio saugojimo vietai ar jį teikiančiai informacijos sistemai tokie e. šaltiniai tampa nepasiekiami. Projektuojant skaitmeninę saugyklą reikia užtikrinti, kad tokie e. šaltiniai būtų visuomet pasiekiami tuo pačiu internetiniu adresu.

Vienas iš galimų šios problemos sprendimų yra nuolatinio identifikavimo sistemos (angl. Persistent identification systems) [11]. Yra daug įvairių identifikavimo sistemų, tokių kaip DOI, URN, Handle, ISBN, SICI, BICI. Atlikus kitų pasaulyje vykdomų ETD projektų e. dokumento identifikatoriaus pasirinkimo analizę, pastebėta, kad dažniausiai naudojamas URN (angl. Uniform Resource Name) identifikatorius. Todėl tikslinga URN identifikatorių taikyti ir Lietuvos ETD IS kūrime.

4. Išvados

• Lietuvos ETD IS projektas yra aktualus Lietuvos akademinei visuomenei; • Lietuvos ETD IS projektas atitinka NDLTD projekto siekius; • XML formatas geriau tinkamas ilgalaikiam dokumentų saugojimui nei PDF. Reikalingi detalesni XML formato

taikymo ilgalaikiam saugojimui tyrimai; • Tikslinga, kad kartu su ETD turi būti įvedami ir ETD metaduomenys Dublin Core formatu; • Prieš kuriant Lietuvos tinklinę skaitmeninę saugyklą yra tikslinga atlikti panašių saugyklų kūrimo projektų

analizę.

Literatūros sąrašas [1] The Networked Digital Library of Theses and Dissertations (NDLTD) [online]. [cited 2005-01-12]. Available from:

<http://www.ndltd.org> [2] Informacinės technologijos mokslui ir studijoms [interaktyvus]. [cituotas 2005-01-12]. Prieiga per internetą:

<http://www.itmis.lt> [3] Lietuvos akademinių bibliotekų tinklas [interaktyvus]. [žiūrėta 2005-01-12]. Prieiga per internetą:<http://www.labt.lt> [4] Įsakymas dėl Lietuvos magistrantūros studentų baigiamųjų darbų, daktaro disertacijų ir jų santraukų elektroninių

dokumentų informacijos sistemos kūrimo nuostatų patvirtinimo [interaktyvus]. [cituotas 2005-01-12]. Prieiga per internetą: <http://www.labt.lt/etd/Isakymas_del_Lietuvos_ETD_IS_nuostatu_patvirtinimo.pdf>

[5] Lietuvos magistrantūros studentų baigiamųjų darbų, daktaro disertacijų ir jų santraukų elektroninių dokumentų informacijos sistemos kūrimo nuostatai [interaktyvus]. [cituotas 2005-01-12]. Prieiga per internetą: <http://www.labt.lt/etd/Lietuvos_ETD_IS_nuostatai.pdf>

[6] V. Kučiukas, R. Abramčikienė, B. Butkevičienė, G. Duobinienė, J. Jaučkojis, M. Jurgutis, M. Kretavičienė, V. Labašauskas, V. Sadauskas, A. Štreimikis, A. Targamadzė. Lietuvos mokslo ir studijų institucijų e. leidybos, visateksčių dokumentų duomenų bazių ir virtualios bibliotekos poreikių ir galimybių studija, Kauno technologijos universitetas. Kaunas, 2004. 151 p.

[7] The ALEPH 500 – integrated library system [online]. [cited 2005-01-15]. Available from: <http://www.exlibris.co.il/aleph.htm>

[8] MetaLib - library portal system [online]. [cited 2005-01-15]. Available from: <http://www.exlibris.co.il/metalib.htm> [9] SFX – Content sensitive linking [online]. [cited 2005-01-15]. Available from: <http://www.exlibris.co.il/sfx.htm> [10] B. Butkevičienė, G. Duobinienė, V. Kučiukas, A. Štreimikis, P. Šulcas, A. Targamadzė, D. Žižys. LABT plėtros

koncepcija: Lietuvos virtuali biblioteka, Mokslo ir studijų departamentas prie Švietimo ir mokslo ministerijos. Vilnius, 2001. 26 p.

[11] Persistent Identification Systems [online]. [cited 2005-01-16]. Available from: <http://www.nla.gov.au/initiatives/persistence/PIcontents.html>

[12] A. Targamadzė, A. Štreimikis, A. V. Valiulis, A. Žalys. The creation of electronic text databases in Lithuanian higher education institutions. Iš: 4th Global Congress on Engineering Education: in collaboration with King Mongkut's University of Technology Thonburi Bangkok, Thailand 5-9 July 2004: congress proceedings. Melbourn, 2004, p. 219-222

– 593 –

http://www.labt.lt/../etd/Lietuvos_ETD_IS_nuostatai.pdf

http://www.labt.lt/../etd/Lietuvos_ETD_IS_nuostatai.pdf

A. Franckevičius, S. Grigonis, A. Štreimikis

Lithuanian Networked Digital Library of Thesis and Dissertations Information System

The article investigates the necessity to establish and develop an information system of Lithuanian Networked Digital Library of Thesis and Dissertations. Fundamental issues and questions raised during the IS development process are discussed. Topics particularly relevant to the development of IS, which require a more detailed and in depth analysis and research are defined.