duomenų bazės ir modeliai - elibrary.lt...savo sudėtyje turi gis dalį, be to leidžia prijungti...

X SEKCIJA Duomenų bazės ir modeliai

KELIŲ TINKLO GEOGRAFINĖ INFORMACINĖ SISTEMA

Kristina Lipnevičiūtė

Kauno technologijos universitetas, Informatikos fakultetas, Informacijos sistemų katedra, S.Daukanto 66, 5610 Telšiai, [email protected]

Straipsnyje apžvelgiami kelių tinklo geografinių informacinių sistemų poreikis šiuolaikinei informacinei visuomenei. Analizuojamos jau sukurtų sistemų savybės. Pateikiama argumentuojanti medžiaga dėl kokių priežasčių nuspręsta kurti naują prototipą. Pristatomas sukurtos sistemos funkcionalumas, priimti projektiniai sprendimai bei kokybės vertinimas

1. Įvadas

Šiuolaikinės geografinės informacinės sistemos funkcionuoja arba yra diegiamos valstybinėse įmonėse ir privačiose struktūrose, padeda tvarkyti ir kontroliuoti įmonės darbą, analizuoti turimus išteklius, rinką, klientų poreikius, modeliuoti tolimesnį vystymąsi [4,10].

Kelių sistemoje geografinės informacinės sistemos kuriamos, tačiau galutinio vartotojo šis produktas dar nepasiekė. Sutvarkyti Lietuvoje esančių kelių tinklą – labai daug resursų ir laiko sąnaudų atimantis darbas.

Paminėsiu pagrindinius GIS diegimo etapus: • esamos situacijos analizė; • būsimos sistemos projektavimas; • projekto realizavimas:

o techninės, programinės įrangos įsigijimas, taikomųjų programinių priemonių kūrimas, juridinių dokumentų, specifikacijų ruošimas, GIS duomenų bazių kūrimas; specialistų apmokymas;

• bandomieji-eksploatacijos darbai ir kt. [7]

2. Tyrimo objektas

Geografinė informacinė sistema susideda iš grafinių duomenų, sujungtų su duomenų baze. Pagrindinės kryptys GIS srityje yra žemės ūkis, teritorinis planavimas ir valdymas, inžineriniai tinklai, keliai. Pritaikius šią technologiją praplečiamos duomenų analizės galimybės, ji atliekama įvairiais pjūviais, ne tik su duomenimis, bet ir su grafine dalimi. Kelių informacinė bazė turėtų susidėti iš šių komponentų – linijinių, taškinių objektų ir duomenų bazėje sukauptos informacijos, kurie yra apjungti į vieną sistemą. Darbo pradžioje reikia išanalizuoti sistemos vartotojų poreikius ir tik po to pradėti projektuoti. Pagrindinė jau sukurtų programų problema – netenkinami specialistų keliami reikalavimai.

Norint sukurti gerą sistemą, jos kūrimui reikia surasti tinkamą programinę įrangą. Žinomiausios yra kelios – ESRI ir Autodesk kompanijų produktai [1-6]. Pasirinkimas –Autodesk kompanijos AutoCAD Map programa, kuri savo sudėtyje turi GIS dalį, be to leidžia prijungti išorines duomenų bazes. Yra dar vienas faktorius, nulėmęs pasirinkimą – VĮ „Telšių regiono keliai“ darbuotojų darbo patirtis su Autodesk produktais yra jau apie 5 metus. Jeigu programinės įrangos projektuotojai ir kūrėjai įvertintų vartotojų poreikius ir galimybes, kaštų sąnaudos būtų mažesnės. Sistema yra kuriama valstybės įmonei, todėl šis faktas labai svarbus. Autodesk kompanijos produktų pasirinkimą lėmė ir tai, kad sistemos kūrime dalyvauja projektuotojai.

3. Kelių tinklo žemėlapio sudarymas

Žemėlapio sudarymui buvo naudojami skaitmeniniai ortofotografiniai žemėlapiai ORT10. Lietuvos skaitme-ninis ortofotografinis M 1:10000 žemėlapis ORT10 yra sudarytas aeronuotraukos pagrindu. . ORT10 duomenys yra pritaikyti valstybinei koordinačių sistemai LKS 94. ORT10 rastriniai duomenys platinami standartiniais lapais pagal valstybinę M 1:10000 teritorijos lapų skaidymo sistemą ir numeraciją. Skaitmeninė šių rastrinių duomenų forma yra TIFF formatas arba suspaustas formatas MrSID. ORT10 rastrinių duomenų skiriamoji geba yra 0.5 m .

– 1 –

mailto:[email protected]

K. Lipnevičiūtė

Ortofotografiniai žemėlapiai analoginėje arba skaitmeninėje formoje naudojami įvairiose gyvenimo srityse. Skaitmeniniai ortofotografiniai žemėlapiai gali būti sėkmingai integruoti į geografines informacines sistemas arba panaudoti kaip kartografinis pagrindas jų sukūrimui.

Ortofotografinis žemėlapis sudaromas, transformuojant aerovaizdus atskirais ploto vienetais, naudojant paviršiaus reljefo modelį. Duomenys įrašomi į kompiuterines laikmenas, paprastai į kompaktinius diskus, ir gaminami leidybiniai originalai, pridedant visą reikalingą atributiką - įbraižant koordinačių tinklelius, įrašant nomenklatūrą ir kitą panašią informaciją.

Ortofotografinių žemėlapių tikslumas yra artimas vektorizavimo ir skaitmeninio procesų tikslumui. Specialistų atlikti tyrimai rodo, kad, naudojant skaitmeninį ortofotografinį žemėlapį ORT10, skirtumai tarp

geodeziškai išmatuotų ir vektorizavimo būdu gautų taškų koordinačių yra pakankamai maži - kinta apytikriai nuo 0.5 iki 1.5 m. Rezultatai gaunami tokie patys tiek su visais, tiek su ryškiai natūroje išreikštais taškais. Geodeziškai išmatuotų ir vektorizuotų taškų koordinačių skirtumams įtakos neturi ir taškų ryškumas.

Skaitmeninio ortofotografinio žemėlapio ORT10 lapų schema parodyta 1 pav.

1 pav. Skaitmeninio ortofotografinio žemėlapio ORT10 lapų schema

– 2 –

Kelių tinklo geografinė informacinė sistema

Skaitmeninis ortofotografinis žemėlapis ORT10 įmonėje naudojamas kartu su programa AutoCAD Map. ORT10 duomenys, esant reikalui papildyti ir patikslinti inžinerinių geodezinių tyrinėjimų medžiaga, leidžia žymiai sparčiau ir kokybiškiau atlikti automobilių kelių bei statinių juose tyrinėjimų ir projektavimo darbus, operatyviau spręsti kitus su įmonės veikla susijusius uždavinius.

Naudojantis skaitmeninio ortofotografinio žemėlapio ORT10 duomenimis, programos AutoCAD Map terpėje sudarytas vektorinis įmonės prižiūrimų kelių tinklo žemėlapis. Šiame žemėlapyje kelių ašys pavaizduotos AutoCAD linijiniais objektais (polyline), kurie susideda iš tam tikro skaičiaus nuosekliai sujungtų tiesių atkarpų ir apskritimų lankų. Objektų padėties nustatymo paklaidos yra ne didesnės kaip 0.5-1.5 m, t.y. atitinka ORT10 duomenų tikslumą [1].

2 pav. ORT10 ortofotografinis žemėlapis užkrautas AutoCad programoje

Naudojant šią technologiją buvo greitai suvesti keliai į vektorinį žemėlapį, kuriame duomenų tikslumas yra iki 1,5 m. Tokie tikslūs duomenys praplečia jo panaudojimo galimybes.

4. Kelių tinklo geografinės informacinės sistemos projektas

Pirmiausia pristatysime kompiuterizuojamų funkcijų hierarchijos modelį. Pirmoje dalyje kompiuterizuojama kelio statinių sustatymas, kurių koordinatės bus nustatytos GPS sistemos

pagalba. Antroje dalyje reikia sukurti DB, suformuotą iš svarbiausių kelią ir statinius aprašančių laukų. Trečioje funkcijų grupėje iš svarbiausių dalių formuojamos grafinės ir tekstinės ataskaitos. Grafinėse ataskaitose atsispindės tokia informacija kaip – keliai pagal kelius prižiūrinčias įmones, pagal dangų tipus, pagal kelio tipus. Tekstinė ataskaita formuojama labai svarbiam tikslui – duomenų įvedimui į GPS sistemą.

Kompiuterizuojamų funkcijų hierarchijos modelis pateiktas 3 paveikslėlyje. Kompiuterizuojama sistema susideda iš kelių dalių – grafinė informacija ir duomenys. Projekte suformuota duomenų bazė –tai duomenų apie kelius ir duomenų apie atributus bazė. Grafiniam vaizdui koncepcinis modelis neformuojamas. Kelių duomenų bazės koncepcinis modelis pateiktas 4 paveikslėlyje. 1. Keliai. Aprašomi kelio numeriu, pavadinimu ir ilgiu. Identifikatorius - kelio numeris. 2. Kelius prižiūrinčios įmonės. Aprašomos įmonės kodu, pavadinimu ir adresu. Identifikatorius - įmonės kodas. 3. Administraciniai vienetai. Aprašomi administracinio vieneto kodu ir pavadinimu. Identifikatorius - administ-

racinio vieneto kodas.

– 3 –

K. Lipnevičiūtė

4. Kelio segmentai - kelio ruožai su tam tikromis pastoviomis charakteristikomis. Aprašomi kelio segmento numeriu, eismo kryptimi, tiesės arba kreivės požymiu, pradžia ir pabaiga, dangos ir kelkraščių pločiais, skiriamosios juostos tipu ir pločiu, duomenų fiksavimo data. Identifikatorius - kelio segmento numeris.

5. Pralaida. Aprašomos X ir Y koordinatėmis, pralaidos numeriu, tipu, žiedų skaičiumi, medžiaga, skersmeniu, susikirtimo kampu, įrengimo metais. Identifikatoriai – X ir Y koordinatės.

6. Tiltas. Aprašomas X ir Y koordinatėmis, tilto numeriu, tipu, sijų skaičiumi, pastatymo metais. Identifikatoriai – X ir Y koordinatės.

7. Kelio ženklai. Aprašomi X ir Y koordinatėmis, ženklo numeriu, stovo aukščiu, stovo medžiaga, atramų skaičiumi, pastatymo data, gamintoju. Identifikatoriai – X ir Y koordinatės.

pa s

įmone

pa s Kelių atvaizdavimas

gal barstymu

Kelio statinių atrinkimas pagal jų tipus

Kelių atvaizdavimas pagal juos prižiūrinčias

Kelių atvaizdavimas gal dangų tipu

Atributų koordinačių nuskaitymas ir jų išvedimas į failą

Analizė

Duomenų apie kelių atributus įvedimas,

koregavimas

Duomenų apie kelius įvedimas, koregavimas

Informacinės sistemos sudarymas

Atributų sudėjimas, jų tvarkymas

Grafinių duomenų suvedimas (kelių

braižymas, jų koregavimas)

Vektorinio žemėlapio sudarymas

Kelių tinklo GIS

3 pav. Kompiuterizuojamų funkcijų hierarchijos modelis

Duomenų struktūra sudaroma remiantis specialistų pateiktomis lentelėmis, jų poreikiais. Todėl tikimasi, kad sistema pateiks norimą ir reikalingą informaciją. Duomenų įvedimas vykdomas bet kurioje sistemoje, pradedant Ms Access, baigiant tokia galinga sistema kaip Oracle. Taip pat duomenis galima įvesti pačiame AutoCad Map pakete. Ši programa skirta grafinių duomenų apdorojimui, bei sujungimui su informacine baze. Šios programos naudojimas priartintų norimus gauti rezultatus prie galutinio tikslo. Vartotojai gaus grafinį vaizdą, kurį papildys informacinė sistema.

Sudarius kelių tinklo vektorinį žemėlapį ir duomenų bazės struktūra, viskas apjungta į vieningą sistemą AutoCAD Map aplinkoje. Autodesk programinė įranga turi vieną programavimo įrankį – programavimo kalbą LISP, kurios pagalba atliekamas visų reikiamų funkcijų sukūrimas. Su šia įranga sukurtos paprogramės veikia visuose Autodesk programų paketuose, todėl nėra problemų keičiant vieną programinę įrangą į kitą [1-2,8].

Atlikus projektavimo darbus buvo realizuotos funkcijos ir sukurta kelių tinklo geografinė informacinė sistema, kuri sėkmingai pritaikyta praktikoje.

Kelių tinklo geografinės informacinės sistemos kokybės tyrimas

– 4 –

Kelių tinklo geografinė informacinė sistema

Praktinė realizacija ir eksploatavimas – pagrindinis ir svarbiausias kriterijus, apsprendžiantis tolimesnį sistemos gyvavimą. Sistema funkcionuoja, nes jos pagalba nuskaitomos kilometrinių ženklų koordinatės ir pervedamos į GPS, atskiruose kelio ruožuose sudėliojami kelio statiniai, kas yra geriausias įrodymas šios sistemos eksploatavimo pagrindimui.

Duomenų tikslumas – šioje vietoje galima paminėti tokias savybes: 1) duomenys nuskaitomi ir pervedami į GPS, toliau kelio ženklai statomi arba koreguojama jų vieta kelyje, pagal nuskaitytą informaciją; 2) GPS pagalba nuskaityta informacija užklojama žemėlapyje ir esančiuose taškuose sustatomi kelio statiniai, tiksliai nužymimos kelių dangos; 3) koreguojamos naujai projektuojamų kelių ašys; 4) naudojamos projekto kūrime technologijos paklaidą leidžia iki 2 metrų

Kelio statinių atitikimas Lietuvos Respublikoje galiojantiems standartams (LST 1405) – visi kelio statiniai kuriami naudojant LKS metodiką, kurioje jie pateikti ant milimetrinio popieriaus, mastelis kinta proporcingai.

Koordinatės LKS 94 sistemoje- aukščiau aprašyti punktai leidžia teigti jog keliai ir kelio statiniai yra Lietuvos Respublikoje priimtai ir galiojančiai LKS 94 koordinačių sistemoje, to rezultate padarinyje nuskaitytas koordinates galime pervesti ir suintegruoti su kitomis sistemomis, o duomenų konvertavimas nereikalingas.

Gal būt šių kriterijų yra per mažai vertinant šią sistemą, tačiau galima teigti, kad jie yra patys svarbiausi. Atributinių duomenų tikslumas priklauso nuo grafinio jų atvaizdavimo, jeigu pirma dalis bus netiksli, tai ir antroje dalyje tikslumo ir duomenų kokybės nebus.

Pralaida #pralaidos koordinatė X#pralaidos koordinatė Ypralaidos numeris pralaidos tipas žiedų skaičius medžiaga skersmuo susikirtimo kampas įrengimo metai

Tiltas #tilto koordinatė X #tilto koordinatė Y tilto numeris tilto tipas tilto sijų skaičius tilto pastatymo metai

sudarosudaro sudaro

Kelio ženklai #ženklo koordinatė X #ženklo koordinatė Y ženklo numeris ženklo stovo aukštis stovo medžiaga ženklo atramų skaičius ženklo pastatymo data ženklo gamintojas

eina priziuri

sudaro

Kelio segmentai #Kelio segmento numeris Eismo kryptis Požymis Segmento pradžia Segmentopabaiga Dangos plotis Kairiojo kelkraščio plotis Dešiniojo kelkraščio plotis Skiriamosios juostos tipas Skiriamosios juostos plotis Duomenų fiksavimo data

Administraciniai vienetai #Administracinio vieneto kodas Administracinio vieneto pavadinimas

Kelius prižiūrinčios įmonės #Įmonės kodas Įmonės pavadinimas

Keliai #Kelio numeris Kelio pavadinimas Kelio ilgis

4 pav. Kelių duomenų bazės koncepcinis modelis

– 5 –

K. Lipnevičiūtė

5. Išvados

1. Išnagrinėtos kelios sistemos, skirtos geografinių informacinių sistemų kūrimui. Autodesk siūloma įranga yra labiau pritaikyta grafinių duomenų įvedimui, be to įmonės darbuotojų darbo patirtis su šia sistema yra didesnė. Apmokymai dirbti su ESRI siūlomomis programomis įmonei kainuotų labai daug, be to jų CAD dalis yra silpnesnė. Buvo atsižvelgta ir į tai, jog pačioje įmonėje atliekami projektavimo darbai.

2. Kuriant projektą buvo įvesti keliai, kas yra visos sistemos pagrindas. Kelių įvedimui naudojami ortofotografiniai žemėlapiai ORT10. Objektų padėties nustatymo paklaidos yra ne didesnės kaip 0.5-1.5 m, t.y. atitinka ORT10 duomenų tikslumą. Tokios tikslios informacijos turėjimas atvėrė galimybes jos naudojimui praktikoje. Žemėlapis papildytas kelio ženklais, kurie atitinka LST 1405 standartus.

3. Viena iš praktinio panaudojimo galimybių, dėl sistemos duomenų tikslumo, yra sąryšis su GPS įrenginiu. Jo pagalba jau atlikta kilometrinių stulpų inventorizacija, ateityje planuojama atlikti kitų kelio statinių inventorizaciją, tačiau tai bus atvirkštinis procesas. Duomenys nuskaitomi su GPS ir gauta informacija sukeliama į sistemą, tada jame sustatomi kelio statiniai su atributine informacija. Vykdant duomenų analizę gaunama tiksli vaizdinė informacija.

Literatūra [1] Autodesk Inc., AutoCad Map User’s Guide 1997. 12902-000000-5010. [2] Autodesk, Inc. Manual. [žiūrėta 2002-10-05]. Prieiga per Internetą:

http://estore.autodesk.com/dr/v2/ec_MAIN.Entry16?SP=10024&PN=29&xid=23288&V1=30016827&V2=30016827&V3=1&V4=&V5=11000241&S1=&S2=&S3=&S4=&S5=&DSP=0&CUR=826&PGRP=0&CACHE_ID=0 .

[3] Baušys R. Geografinių informacinių sistemų pagrindai. [žiūrėta 2003-09-29]. Prieiga per Internetą: http://gsk.vtu.lt/darbuotojai/Romas/destoma/GIS/downloads/ .

[4] ESRI, Inc. GIS and Mapping Software. [žiūrėta 2003-11-20]. Prieiga per Internetą: http://store.esri.com/esri/index.cfm [5] Environmental System Research Institute, INC Understanding GIS The ARC/INFO method, 1994. ISBN 0 582 21432 7. [6] ESRI, Inc. What Is GIS?. [žiūrėta 2002-11-20]. Prieiga per Internetą: http://www.gis.com/whatisgis/whatisgis.html.

[7] ESRI, Inc. GIS: Getting Started. [žiūrėta 2002-11-20]. Prieiga per Internetą: http://www.esri.com/getting_started/gis_professionals/software.html .

[8] HNIT-BALTIC. Geografinė informacinė sistema. [žiūrėta 2003-04-15]. Prieiga per Internetą: http://www.hnit-baltic.lt/gis.htm.

[9] Kūdriacev E.M. AutoLisp Programavimo AutoCad 2000 pagrindai. Moskva, DMK Press 2000. [10] Paršeliūnas E. Geoinformacinės sistemos: Duomenų bazės 1997. Vilnius “Technika”.

– 6 –

DATA MINING TECHNOLOGY AND THE DATA MINING PROCESS OF THE INTELLIGENT MINER

Regina Kulvietienė, Jelena Mamčenko Vilniaus Gedimino technikos universitetas

Saulėtekio al. 11, Vilnius

Information technology has developed very rapidly. Many organizations store increasingly large volumes of data on their computer systems. Useful information might be hidden in the data in the form of implicit patterns and connections that are not easy to discern using conventional data queries and statistical calculations.

Data mining is the process of discovering valid, previously unknown, and ultimately comprehensible information from large store of data. Extracted information could be used to form a prediction or classification model, or to identify similarities between database records. The resulting information can help to make more informed decisions.

The Intelligent Miner supports variety of data mining tasks. For example, a retail store might use the Intelligent Miner to identify groups of customers that are most likely to respond to new products and services or to identify new opportunities for cross-selling. An insurance company might use the Intelligent Miner with claims data to isolate likely fraud indicators.

1. The data mining process

Data mining is an iterative process that typically involves selecting input data, transforming it, running a mining function, and interpreting the results. The Intelligent Miner assists with all the steps in this process. The functions of the Intelligent Miner can be applied independently, iteratively, or in combination. Mining functions use elaborate mathematical techniques to discover hidden patterns in data. After interpreting the results of data mining process, the user can modify selection of data, data processing and statistical functions, or mining parameters to improve and extend results. Figure 1 shows the basic data mining process.

Data

Assimilated Information

Extracted Information

Transformed Data

Selected

Interpret Mine Transform

Logical

Figure 1. The data mining process

1.1 Selecting the input data

The first step in data mining is to specify the input data that you want to mine and analyze. A data source might not contain all the data that you want to use for specific data mining objectives, or it might include irrelevant data, the data that will be mine might be in one or more database tables, views, or flat files.

The Intelligent Miner helps to select data from a variety of data types and sources to create input data to which you can apply preprocessing and mining functions. For example, we can omit data fields or select a subset of records in the table and then combine them with data selected from another table.

– 7 –

R. Kulvietienė, J. Mamčenko

1.2. Exploring the data

At any point in the process, statistical function can be used for exploring and analysing the data. We might want to apply statistical analysis as we consider input data variables for mining function. We can also use statistics functions to transform data to create input fields for mining. In addition, these functions are useful for evaluating the output data generated by the mining functions.

1.3. Transforming the data

After the input data specifying, we can transform it using the Intelligent Miner preprocessing functions. Preprocessing functions such as discretization, filtering, and joining help organize data so that it can mine it effectively.

For example, if data contains the fields Salary and Commission, we might aggregate the values of these fields and create a data field named Total_Salary. We might also use an Intelligent Miner function to remove Null values from input data so that they do not affect the result of the data mining process.

1.4. Mining the data

Transformed data is subsequently mined using one or more mining functions. The Intelligent Miner has the following types of mining functions:

• Associations • Neural Classification • Tree Classification • Demographic Clustering • Neural Clustering • Sequential Patterns • Similar Sequences • Neural Prediction • Radial Basis Function (RBF) – Prediction

1.5. Interpreting the result

We can analyse the results of the data mining process with respect to decision-support objectives. Visualization tools allow you to view the results and identify important information laid bare by the mining process. The results can be exported to a remote workstation so that they can be viewed at a different location. Also it is possible to copy certain results to the clipboard to make them available for other tools, such as spreadsheets or statistical applications.

Data mining can be an iterative process. When we look at previous results, we might want to adjust the mining settings for a further mining run to improve the results quality.

2. Overview of the DB2 Intelligent Miner for Data components, Release 6.1 from IBM®

A data mining operation is typically made up of several distinct steps combining the execution of data mining functions with data preprocessing function. The user of the data mining application wants to be able to select and control the execution of these functions in a flexible way.

The Intelligent Miner provides the means for this section and control. It contains the following features: • A set of data mining function providing the most frequently required data mining technologies. These

include statistical functions that provide various statistical and forecasting methods to help users in analyzing the input data and support the business decision.

• A processing library providing functions for data transformation. • A set of API functions called Environment Layer API to control the execution of the data mining functions. • A set of API functions called Result API to manage the results of data mining runs. • A client/server structure to provide communication between data mining and data preprocessing functions

on the server, and administrative and visualization functions on the client. • An administration Graphical User Interface (Administration GUI) to control the execution of the data

mining functions and the preprocessing functions, and to manage the results of data mining runs.

– 8 –

Data Mining Technology and the Data Mining Process of the Intelligent Miner

• The capability to define and execute sequences of functions and mining operations both through the GUI and the Environment Layer API.

The Intelligent Miner communicates between mining and preprocessing functions on the server, as well as between the administrative and visualization tools on the client. The client component includes a user interface from which functions can be invoked on an Intelligent Miner server. The results are returned to the client where it can be visualized and analysed. The client components are available for AIX, OS/2, Windows 95,Windows 98, and Windows NT operating systems (table 1).

Table 1. Client and server options

Client Options Server Options

AIX OS/2 Windows 95 Microsoft Windows 98 Microsoft Windows NT

AIX OS/390 AS/400 Sun Solaris Windows NT

The server software is available for AIX, OS/2, AS/400, Sun Solaris, and Windows NT systems (table 1). In addition, on AIX, Sun Solaris, and Windows NT systems, the server software supports parallel mining with multiple processors. Possible to have client and server components on the same machine.

Figure 2 shows the client and server components of the Intelligent Miner. User Interface. A program that allows you to define data mining functions a graphical environment. Preferences

for the user interface can be defined, which are stored on the client. Environment layer API. A set of API functions that control the execution of mining runs and results. Sequences

of functions and mining operations can be defined and executed using the user interface through the environment layer API. The environment layer API is available on all server operating systems.

Visualizer. A tool that displays the results produced by mining or statistical function. The Intelligent Miner provides a rich set of visualization tools. It is possible to use other visualization tools.

ng

Mini

Result API (save)Data

Access

Flat Files

Database

Databases

Mining Bases

Processi

Result API(load)

CLIENT

Export Tools

Mining Results

Data access. Data access to flat files, database tables, and database views.

Database tables and flat files. The data types that can be processed. The Intelligent Miner components work directly with data stored in a relational database or in flat files. The data need not be copied to a special format. Input and output data objects, defined by the user, that are logical description of the physical data. This logical description allows changing the physical location of the data without affecting objects that use the data. Only the logical description must be changed.

Figure 2. The Intelligent Miner architecture

– 9 –

R. Kulvietienė, J. Mamčenko

The change might be as simple as changing the name of a database table. Processing library. A library that provides access to database functions. Mining bases. A collection of data mining objects used for a mining objective or business problem. Mining

bases are stored on the server, which allows access from different clients. Mining kernels. The algorithms brought into operation when you run a data mining or statistical function. Mining results, result API, and export tools. The data extracted by running a mining or statistics function. These

components allow you to visualize results the client. Results can be exported for further processing or use with visualization tools.

3. Exploring the Features and Components of Enterprise Miner, Release 4.1 from SAS® 3.1 Client/Server Capabilities

The Enterprise Miner client/server architecture enables users to employ large UNIX servers or mainframes to access and process enormous data sources from different database management systems.

Specifically, the Enterprise Miner client/server functionality provides the following advantages: • Distributes data-intensive processing to the most appropriate machine. • Minimizes network traffic by processing the data on the source machine. • Minimizes data redundancy by maintaining one central data source. • Distributes server profiles to multiple clients. • Enables user to regulate access to data sources. • Enables user to toggle between remote and local processing.

3.2 Client/Server requirements

The following table lists the client and server options available in Release 4.1 of Enterprise Miner.

Table 2. Client and server options

Client Options Server Options Microsoft Windows 98 Microsoft Windows NT Microsoft Windows 2000

ABI+ for Intel AIX (32, 64 bit) Compaq Tru64 UNIX (32,64 bit) HP – UX (32, 64 bit) Intel Linux MVS/ESA (or prior releases) including all releases of OS/390 Solaris (32, 64 bit) Microsoft Windows NT and 2000

Base SAS and SAS/STAT are required on the same server or mainframe on which the Enterprise Miner server component resides and processes data.

4. Conclusion

The IBM DB2 Intelligent Miner for Data is a suite of mining, processing, and statistics function that can be used to analyze large databases. It is also provides visualization tools for viewing and interpreting mining results.

Scalable and with support for multiple platforms, DB2 Intelligent Miner for Data provides a suite of tools to provide a single framework for database mining. This framework supports the iterative process, offering data processing, statistical analysis, and results visualization to complement a variety of mining methods.

DB2 Intelligent Miner for Data uses proven mining algorithms, either individually or in combination to address a wide range of business problems and deliver measurable business results, provides a scalable solution, focused on the technical issues of large-scale mining, such as large volumes of data, parallel data mining on AIX, Windows NT,

– 10 –

Data Mining Technology and the Data Mining Process of the Intelligent Miner

Sun Solaris, and OS/390, directly mining DB2* data, long-running mining operations, and optimization of mining algorithms.

DB2 Intelligent Miner for Data has an application programming interface, enabling the development of customized, industry-specific mining applications by customers, IBM, and IBM Business Partners.

Enterprise Miner can uncover valuable information hidden in large amounts of data. This software fully integrates all steps of the data mining process beginning with the sampling of data, through sophisticated data analyses and modeling, to the dissemination of the resulting information. The functionality of Enterprise Miner is provided through a flexible GUI that enables users, who have different degrees of statistical expertise, to plan, implement, and refine their data mining projects.

References [1] Berry, Michael J. A. and Gordon Linoff. 1997. Data Mining Techniques. New York: John Wiley & Sons, Inc. [2] IBM’s Data Mining Technology. White paper. Data Management Solution. - First edition, April 1996, psl. 1-11. [3] Mining your own business in Telecom, IBM Redbooks, 2001. [4] R.S. Michalski, K.A. Kaufman. Data Mining and Knowledge discovery: a review of issues and multistrategy approach. –

Machine Learning and Data mining: Methods and Applications, West Sussex, England 1998, psl. 71-105. [5] SAS Institute Inc. 1997. (White Paper) “Business Intelligence Systems and Data Mining.” [6]. SAS Institute Inc. 2001. (White Paper) “Finding the Solution to Data Mining.” P. 28-32

Duomenų gavybos technologijos ir duomenų gavybos procesas Intelligent Miner pavyzdžiu

Duomenų gavybos technologijų sistemos realizuoja naują duomenų analizės formą, paremtą intelektualiais sprendimais, leidžia gauti iš duomenų bazės žymiai gilesnes žinias, negu sudėtingiausios užklausos ir iš jų suformuotos ataskaitos.

Šiame straipsnyje yra pateikti DB2 Intelligent Miner for Data ir SAS Enterprise Miner programinių produktų kliento/serverio architektūros. Pateikti produktų galimybės bei reikalavimai.

– 11 –

DUOMENŲ SAUGYKLOS PROJEKTAVIMO PROCESO MODELIS

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

Studentų g. 50, LT-3031 Kaunas

Duomenų saugyklų sukūrimas leidžia vartotojui nagrinėti turimus duomenis, naudojant įvairius daugiamačius duomenų bazės pjūvius, kurti naujus išvestinius rodiklius, juos palyginti, grupuoti pagal dominančius kriterijus, analizuoti skirtingais agregavimo lygiais. Šiame darbe detaliai išanalizuotas duomenų saugyklos projektavimo procesas, kurio metu, remiantis naudotojų poreikiais ir esamos duomenų bazės schema, sukuriama saugyklos schema, pirminių duomenų transformavimo ir perkėlimo į saugyklą procesai, duomenų analizės modeliai ir saugyklos duomenų transformavimo į analizės modelius bei saugyklos atnaujinimo procesai. Sudaryta projektavimo metodika, kurioje didelis dėmesys skiriamas schemų tipų pasirinkimui, kelių schemų jungimui, duomenų normalizavimui ir saugyklos lankstumui. Metodika suformuluota remiantis literatūros šaltinių analize ir praktine patirtimi, įgyta kuriant saugyklą Miškų informacinei sistemai MS SQL serverio priemonėmis.

1. Įvadas

Duomenų saugyklos autoriumi laikomas B. Inmon, kuris apibūdino duomenų saugyklas taip: „Duomenų saugykla yra analizės sritims (temoms) orientuotas (angl. subject oriented), integruotas, laiko chronologijos tvarka išdėstytas nemodifikuojamų duomenų rinkinys, skirtas valdymo sprendimams paremti“[3]. Ji aprūpina vadybininkus ir analitikus patikima informacija, kuri reikalinga operacinei analizei ir sprendimų priėmimui. Gali kilti klausimas, kodėl reikia kurti duomenų saugyklas – juk jos kaupia didelius perteklinės informacijos kiekius, dubliuodami gausią informaciją, kuri ir taip registruojama duomenų bazėse ar operacinių sistemų failuose. Saugyklos reikalingos todėl, kad analizuoti duomenis operacinėse sistemose tiesiog neįmanoma arba labai sudėtinga. Taip yra dėl daugelio priežasčių, tame tarpe ir dėl duomenų paskirstymo bei skirtingų DBVS formatų. Net jeigu visi įmonės duomenys saugomi viename serveryje, analitikui bus sunku vykdyti paiešką sudėtingose, kartais supainiotose struktūrose. Norėdamas atlikti analizę, vartotojas su duomenimis turi vykdyti įvairias operacijas: sumuoti, transformuoti, prognozuoti, ir panašiai. Tam jis turi turėti veikimo erdvę ir nesupainioti faktinių duomenų su skaičiuojamaisiais, o dar svarbiau – netyčia jų nesugadinti. Tokiu būdu saugyklos tikslas – sukaupti duomenis analizei vienoje vietoje ir juos pateikti tam pritaikytomis, suprantamomis struktūromis. Yra dar viena priežastis, pagrindžianti saugyklos atsiradimą – sudėtingos analitinės užklausos stabdo įmonės darbą, atliekamą su operatyviais duomenimis, ilgam blokuodamos lenteles ir užimdamos serverio resursus.

2. Duomenų saugyklų schemos

Duomenų saugyklos duomenų modelis skiriasi nuo įprasto reliacinių ar objektinių/reliacinių struktūrų, kuriomis saugomi duomenys kasdieninių operacijų duomenims kaupti skirtose duomenų bazėse. Tai daugiamatis duomenų modelis, vadinamas kubu. Jei saugykla kuriama reliacinėje duomenų bazėje, daugiamatis modelis atvaizduojamas reliaciniu tam tikros struktūros modeliu.

Pagrindinės reliacinėje bazėje kuriamos saugyklos duomenų struktūros sudėtinės dalys yra faktų ir dimensijų lentelės. Centrinis saugyklos taškas yra faktų lentelė. Paprastai joje saugomi agreguoti operaciniai duomenys apie analizuojamus objektus ir įvykius. Faktų lentelės atributai vadinami matavimais (angl. measures). Jie išreiškia analizuojamas dalykinės srities savybes.

Saugyklos naudojimo metu faktų reikšmės nuolat atnaujinamos, įtraukiant naujus duomenis, atsiradusius įmonės operacinėje duomenų bazėje. Dimensijų lentelės turi nekeičiamus arba retai keičiamus duomenis, dažnai jos sudaro dimensijų hierarchijas. Faktų lentelių pirminiai raktai būna sudaryti iš išorinių raktų rinkinio, kuriame kiekvienas elementas yra atitinkamos dimensijos pirminis raktas. Saugyklų schemos turi kelias tipines struktūras, kurios buvo nagrinėtos [7 ]: plokščia, terasinė, žvaigždės, žvaigždyno, snaigės tipo schema. 1 paveiksle žvaigždės tipo schemos struktūra pavaizduota UML klasių diagrama.

Projektuojant duomenų saugyklas, reikia išanalizuoti naudotojų reikalavimus bei operacinės duomenų bazės schemą, apibrėžti analizės sritis, kubus, faktus ir matavimus, dimensijas, jų elementus ir hierarchijas, faktų skaičiavimo formules. Tai sudėtingas uždavinys, skirtingas nuo įprastų duomenų bazių projektavimo.

– 12 –

Duomenų saugyklos projektavimo proceso modelis

Miško tipasVietovė

Organizacija

Medžių rūšis Laikas

Sklypas 0..n

1

0..n1

0..n

1

0..n

1

0..n

1

1

0..n 1

0..n10..n

1

0..n1

0..n

1 pav. Žvaigždės tipo schemos struktūra

Būdingas dimensinio modelio kūrimo veiksmas yra objektų klasifikavimas į tris kategorijas: • Operaciniai objektai, kurie aprašo specifinių verslo įvykių, pavyzdžiui, užsakymų, savybes. Tai svarbūs

objektai, iš kurių sudaromos faktų lentelės žvaigždės tipo schemoje • Komponentiniai objektai, kurie tiesiogiai susiję su operaciniu objektu ryšiu „vienas su daug“. Šie objektai

detaliau nurodo kiekvienos verslo operacijos komponentus. Komponentiniai objektai atsako į šiuos klausimus apie verslo įvykį: „kas“, „ką“, „kada“, „kur“, „kaip“ ir „kodėl“. Iš šių objektų sudaromos dimensijų lentelės žvaigždės tipo schemoje.

• Klasifikavimo objektai, susiję su operaciniais objektais ryšiu „vienas su daug“, t.y. operaciniai objektai funkcionaliai priklauso nuo komponentinio objekto. Klasifikavimo objektai vaizduoja duomenų modelio hierarchijas, kurias taip pat galima sujungti į dimensijų lenteles žvaigždės schemoje [1].

Kitas svarbus veiksmas – identifikuoti hierarchijas. Hierarchijos yra ypač svarbi koncepcija dimensiniame modeliavime. Hierarchija vadinama maksimalia, jeigu jos negalima išplėsti į viršų arba į apačią, įtraukiant kitą objektą. Objektas vadinamas minimaliu, jei tai yra maksimalios hierarchijos apačioje ir maksimaliu, jei yra viršuje. Minimalius ir maksimalius objektus lengva identifikuoti, kadangi minimalūs objektai neturi „vienas su daug“ ryšių, o maksimalūs objektai neturi „daug su vienu“ ryšių.

Trečias žingsnis – sudaryti dimensinius modelius, naudojant hierarchijų sutraukimą ir agregavimą.

3. Duomenų saugyklos projektavimo procesas

Projektuojant duomenų saugyklą, organizacijos duomenų bazė paprastai jau egzistuoja. Saugyklos tikslas – pateikti juos kiekvienam naudotojui jo užklausų vykdymui tinkamu būdu. Šiame darbe suformuluotas projektavimo procesas paremtas [2, 3, 4, 5] šaltinių analize ir eksperimentiniu kūrimu. Projektavimo procesui buvo keliami tokie reikalavimai:

• Saugyklos schema turi agreguoti duomenis, bet iki tokio laipsnio, kad galėtų tenkinti detaliausias kiekvieno vartotojų užklausas. Todėl projektuojant saugyklą turi būti išanalizuoti visi esami ir numatomi vartotojų poreikiai.

• Saugyklos schema turi būti lanksti, kad būtų galima ją keisti arba plėsti, palaipsniui įtraukiant naujas sritis. Netikslinga sukurti visą didžiulę saugyklą iš karto, nes kūrimo metu gali išryškėti klaidos ar galimi efektyvesni sprendimai. Tikslinga kurti ją palaipsniui, iteracijomis, kiekvienoje iteracijoje tobulinant rezultatus.

Formuluojant reikalavimus saugyklai, pirmiausia atliekama vartotojų poreikių analizė ir išskiriamos pagrindinės analizės sritys arba temos (angl. subjects) [2, 3, 6]. Analizės sritys dažnai sutampa su funkcinių padalinių ar atskirų specialistų atliekamos analizės sritimis.

Analizės srities reikalavimus pateikia tos srities naudotojas. Pradiniai reikalavimų duomenys yra naudotojų užklausų aibė ir saugyklos atributų aibė. Kadangi visų užklausų iš anksto numatyti negalima, stengiamasi įvertinti galimai didesnę numatomų užklausų aibę. Kiekvienas naudotojas taip pat nurodo jį dominančių matavimų ir dimensijų atributus bei jų išvedimo būdus, kurie aprašomi lentelėmis. Kartu su naudotojo apibrėžtais reikalavimais nagrinėjama pirminė duomenų bazės schema ir naudotojų ataskaitos. Šie reikalavimai lyginami tarpusavyje. Atskirų analizės sričių faktai dažnai būna tarpusavyje nepriklausomi, tačiau dimensijos dažnai sutampa. Duomenų saugyklos projektavimo procesas susideda iš kelių etapų, kurie pavaizduoti 2 paveiksle. Kiekvienai analizės sričiai išskiriami faktai ir dimensijos bei sudaroma tos srities saugyklos schema. Faktai atitinka ataskaitų skaitines reikšmes ir pirminės duomenų bazės transakcijų atributus. Dimensijos atitinka ataskaitų stulpelius ir pirminės duomenų bazės komponentines bei klasifikacines esybes. Sulyginant ataskaitų stulpelius, transakcijų atributus ir naudotojo išreikštus

– 13 –

J. Tonkūnaitė, L. Nemuraitė

poreikius, šiame darbe siūloma sudaryti faktų ir dimensijų matricas pradžioje kiekvienai sričiai, po to sujungti šias matricas į bendrą matricą. Pagrindiniai principai: didžiausio detalumo faktų nustatymas ir dimensijų nepriklausomumas. Esant nepriklausomoms dimensijoms, gaunama normalizuota saugyklos schema. Priklausomos dimensijos vaizduojamos hierarchijomis, tai yra, schema įgauna snaigės pavidalą.

2 pav. Duomenų saugyklos projektavimo procesas

Kalbant apie duomenų saugyklas, pabrėžiama, kad jose dažniausiai saugomi nenormalizuoti, pertekliniai duomenys ir tokiu būdu pasiekiamas skaitymo užklausų efektyvumas. Tačiau ir daugiamačiams duomenims galima nustatyti kokybinius reikalavimus. Tačiau tokius reikalavimus nagrinėja nedaug autorių. [5] šaltinyje apibrėžtos daugiamatės norminės formos:

• Pirma daugiamatė norminė forma (1DNF) reikalauja, kad faktų schema ir dimensijos būtų susieti dalykinės srities funkcinėmis priklausomybėmis, faktų schema išsaugotų dalykinės srities apibendrinimo ir detalizavimo galimybes bei įkūnytų daugiamatį matavimų kontekstą. Taigi 1DNF užtikrina daugiamačio modelio tikslumą, pilnumą ir nepertekliškumą.

• Jei schema yra 2DNF, galima atskirti, kurie dimensijų lygiai neprivalomi. 2DNF užtikrina galimybę išvengti prieštaringų užklausų ir žinoti, kada dirbama su nepilna informacija.

• 3DNF – dimensijos išdėstytos į hierarchijas ir faktų schema negali turėti nulinių reikšmių.

Pagal daugiamačių norminių formų reikalavimus sudaryta schema susideda iš faktų bei dimensijų schemos ir agregavimo apribojimų. Šiame darbe siūloma saugyklos projektavimo metodika užtikrina trečios daugiamatės norminės formos modelį.

Norint sudaryti saugyklos schemą, kuri tenkintų daugiamatės normalizacijos reikalavimus, pirmiausia reikia identifikuoti faktų lenteles. Tam nagrinėjami naudotojų reikalavimai ir pirminės duomenų bazės schema. Dažnai viena analizės sritis turi vieną faktų lentelę. Norint gauti tam tikro fakto dimensijas iš pirminės duomenų bazės schemos, reikia identifikuoti visas lenteles, kurios turi ryšį su fakto lentele 1:N. Kiekvienai dimensijos lentelei taip pat reikia identifikuoti lenteles, kurios turi su ja ryšį 1:N, kol pasiekiamos nepriklausomos esybės. Taip gaunamos dimensijų hierarchijos. Reikia pažymėti, kad nustatant dimensijų hierarchijas, gali būti sudėtingesnių atvejų, kai tarp skirtingų hierarchijos lygių egzistuoja tarpinės lentelės. Tai taip vadinamosios silpnos esybės, kurios rodo, kad žemesnio ir aukštesnio dimensijos lygio yra daugiamatis ryšys. Tarpinių lentelių duomenys priskiriami aukštesniam dimensijos lygiui. Jungiant atskirų sričių schemas į bendrą saugyklos schemą, kai kuriems faktams naudojamos tos pačios dimensijos. Tai leidžia daugkartinį dimensijų duomenų naudojimą, bet saugyklos schema darosi painesnė.

– 14 –


Daugiamatės schemos projektavimo ir pirminių duomenų perkėlimo į saugyklą metu atliekami transformavimo procesai detaliau parodyti 3 paveiksle.

Pradinės faktų sc hemo s projektavimas

St ruk tūros lentelės

Fun kcinės prik lausomybės

Kontek sto len telės

Pradinė fak tų schema

Matavimų schema

Dimens ijų hierarchijų projektavimas

Daugiamatė s chema

Agrega vimo apriboj imų apibrėž imas

Dau giamatė sc hema su agre gavimo apribojimais

a

Operacinių duomenų pašalinimas

Laiko dimensijos pridėjimas

Išvestinių duomenų įvedimas

Ryšių artefaktų sukūrimas

Duomenų stambumo keitimas

Skirtingų lentelių duomenų sujungimas

Duomenų eilučių sukūrimas

Organizavimas pagal stambumą

b

3 pav. Duomenų saugyklos schemos projektavimo metodika (a) ir užpildymo metu atliekamos transformacijos (b)

4. Miškų informacinės sistemos pirminės duomenų bazės schemos analizė

Sudarant duomenų saugyklos modelį, svarbu skirti tris modelių tipus, dalyvaujančius transformacijos procese iš operacinės aplinkos į sprendimų paramos sistemą:

• bendras įmonės duomenų modelis; • saugyklos duomenų modelis; • duomenų saugyklos analizės srities modelis (dažnai atitinkantis įmonės posistemio duomenų modelį).

Pradinis duomenų saugyklų kūrimo taškas yra bendras įmonės duomenų modelis. Be šito modelio yra labai sunku organizuoti duomenų saugyklos struktūrą ir jos duomenų turinį. Jis apima visas įmonės operacines duomenų bazes (duomenų šaltinius) ir duoda pagrindą integravimui ir suvienodinimui intelektualiame lygyje. Šiame darbe saugyklos kūrimas buvo lengvesnis, kadangi visi nagrinėjamos Miškų informacinės sistemos (IS) duomenys saugomi centrinėje duomenų bazėje, kurios schemos fragmentas parodytas 4 paveiksle. Ši bazė turi virš 200 lentelių ir gilias ryšių hierarchijas. Suprojektuoti pilnos apimties saugyklą būtų labai didelis uždavinys, be to, bazė nuolat plečiasi, atsiranda naujos analizės sritys. Šiame darbe buvo sukurta saugykla kelioms pagrindinėms analizės sritims, tačiau tam tikslui buvo analizuojama visa pirminės DB struktūra.

5. Saugyklos schema

Kuriamai duomenų saugyklai pasirinkta snaigės schema. Sklypų snaigės schema pateikta 5 paveiksle. Snaigės schemos centre yra faktų lentelė, kurią naudoja dimensinės užklausos. Joje saugomi realūs duomenys (faktai). Faktų lentelės raktas susideda iš dimensijų pirminių raktų, faktų matavimai yra skaitiniai atributai – kiekiai, kurie gali būti sumuojami, agreguojami įvairioms statistinėms operacijoms, skaičiuojamas jų vidurkis, maksimali/minimali reikšmė. Dimensijos rodo, nuo ko priklauso faktai, kokiais pjūviais galima juos nagrinėti.

Sudarant schemas kitoms analizės sritims, buvo naudojamos tos pačios dimensijos, todėl gautą schemą būtų galima pavadinti snaigių spiečiumi (6 pav.)

SQL serveryje sukurtos saugyklos schema parodyta 7 paveiksle. Toliau šią saugyklą reikia užpildyti duomenimis iš transakcijų duomenų bazės. Tam su duomenimis reikia atlikti eilę operacijų, parodytų 3 paveiksle, b.

– 15 –


Ardai

PK ard_id

U1 ard_nrU2 ard_vard

Ardu_sudetis

PK as_id

FK1,I1,U1 m10_idU1 sud_el_nrFK2,I2 mr_id

amziuskfhdpspgim_metaiskskilme

Maketas10

PK m10_id

FK3,I3 skl_idFK1,I1 ard_id

ntvskalturis

FK2,I2 nv_id

Maketas1

PK m1_id

FK1,I1 mr_idFK3,I3 skl_id

bon_kodskl_turamz_kl_kod

FK4,I4 up_idbrg_kod

FK2,I2 mtip_idatv

Misku_tipai

PK mtip_id

U3 mtip_rkodU4 mtip_skodU1 mtip_liet_vardU2 mtip_lot_vard

Medziu_rusys

PK mr_id

FK1,I1 mgen_idU1 kl_kodU2 mr_rkodU3 mr_vardFK4,I4 pmr_tur_idFK5,I5 pmr_turj_idFK2,I2 pmr_bon_idFK3,I3 pmr_kirt_id

svorisSklypai

PK,FK2 skl_id

FK1,I1 dtg_idnusau_zem

Geo_objektai

PK skl_id

FK4,I6 zk_idplplanes

I4 nuoI1 ikiFK2,I5 pr_idFK3,I2 keit_idFK1,I3 klaid_id

snakt_metai

Uredijos

PK mu_id

I2,U1 mu_kodmu_reg_kod

U2 mu_vardFK1,I4 ukat_idI3,U1 nuoI1,U1 iki

Ur_gir

PK ur_gir_id

FK2,U1,I3 mu_idU1,I2 gir_kodI3 gir_vardFK1,I1 gir_kat_idI5 nuoI4 iki

Kv_skl

PK kv_skl_id

FK1,I9 skl_idFK5,U1,I4 kv_idU1,I10 skl_nrU1,I8 skl_dalisFK6,U1,I11 ur_gir_idFK7,U1,I5 mu_idI6 nuoU1,I1 ikiFK2,I7 pr_idFK3,I2 keit_idFK4,U1,I3 klaid_id

Girininkiju_kateg

PK gir_kat_id

U1 gir_kat_kodU2 gir_kat_vard

Gir_kvar

PK gir_kv_id

FK6,U1,I6 mu_idFK5,U1,I9 ur_gir_idFK4,I4 kv_idU1,I5 kv_nrI7 nuoI1,U1 ikiFK2,I8 pr_idFK3,I2 keit_idFK1,I3,U1 klaid_id

Kvartalai

PK kv_id

kv_plkv_plakv_nes


Apskritys

PK apskr_id

U1 apskr_kodU2 apskr_vard

eil_nrnuoiki

Vietoves

PK kdv_id

U1,I3 kdv_kodasI3 kdv_vardasFK1,I1 admr_idI4 nuoI2 iki

Rajonai

PK admr_id

U1 admr_kodasU2 admr_vardas

eil_nrFK1,I1 apskr_idI3 nuoI2 iki

Rysiai_su_viet

PK skl_viet_id

FK2,I1 kdv_idFK1,I2 skl_id

Zemes_naudm_kateg

PK zk_id

U1 zk_kod1FK1,I1 zng_idU2 zk_vard

Zemes_naudmenu_grupes

PK zng_id

U1 zng_kodU2 zng_vard

4 pav. Miškų IS duomenų bazės schemos fragmentas (MS Visio duomenų bazės modelio formate)

Miško tipas

kodasvardas

Medžių rūšis

kodasvardas

Laikas

metai

Urėdija

kodasvardas

Girininki ja

kodasvardas

0..n

1

Kvartalas

kodasnumeris

0..n

1

Sklypas

plotastūris

0..n1

0..n1

0..n1

0..n1

0..n

1

0..n

1

0..n

1

Apskritis

kodasvardas

Rajonas

kodasvardas

0..n

1

Vietovė

kodasvardas

0..n

1

0..n

1

0..n1

1

0..n

1

0..n

1

0..n

10..n

1

0..n

5 pav. Duomenų saugyklos schema sklypų analizės sričiai

– 16 –


Apskritiskodasvardas

Urėdijakodasvardas

Rajonaskodasvardas

0..n

1

0..n

1Girininkija

kodasvardas

0..n

1

0..n

1

Įmonėkodasvardas

Medienos tipas

kodasvardas

Kirtim o projektas

numeris

0..n

1

0..n

1

Miško tipaskodasvardas

Ardastūrisskalsumasaukštisamžiusskersmuo

0..n

1

0..n

1

Vietovėkodasvardas

0..n1

0..n1 Kvartalas

kodasnum eris

0..n1

0..n1

KirtimasiškirstasPlotasiškirstasTūris0..n

1

0..n

1

0..n

1

0..n

1

Medžių rūšiskodasvardas

0..n

1

0..n

1

0..n

1

0..n

1

Laikasmetai

0..n

1

0..n

1

0..n0..n

Atkūrimo projektas

numeris

0..n

1

0..n

1

AtkūrimasatkurtasPlotas

0..n

1..n

0..n

1..n

0..n

1

0..n

1

0..n

1

0..n

1

Sklypasplotastūris

0..n1

0..n1

0..n

1

0..n

10..n

10..n

1

0..n

1

0..n

1

0..n

1

0..n

1

0..n

1

0..n

1

0..1

1

0..1

1

0..n

1

0..n

1

6 pav. Miškų IS faktų lentelės (parodytos tamsesne spalva), naudojančios bendras dimensijas

7 pav. Sklypų faktų schema MS SQL serveryje

– 17 –


6. Duomenų transformavimo užklausos Yra du pagrindiniai faktoriai reikalingi aprašyti duomenų transformavimui iš operacinės aplinkos į duomenų saugyklos aplinką: duomenų pasirinkimas ir transformacijos taisyklės, kurios aprašo, kaip duomenys perkeliami į saugyklą. Duomenų perkėlimui į saugyklos duomenų struktūras buvo naudojamas Microsoft SQL DBVS įrankis DTS (Data Transformation Service), atliekantis duomenų transformacijas.

DTS pagalba galima kopijuoti

duomenų struktūras bei pačius duomenis iš vienos duomenų bazės į kitą, kurti duomenų perdavimo aplinkas, taip pat papildyti saugyklas duomenimis iš operacinių šaltinių.

Norint saugyklą užpildyti duome-nimis, reikalingas DTS paketo sukūrimas ir jo vykdymas. Sukurti DTS paketą galima DTS Package Editor įrankiu. Jo paleidimui reikia prisijungti prie serverio naudojant SQL Server Enterprise Manager, kuris palaiko duomenų sau-gyklą, po to Data Transformation Service aplinkoje susikurti naują paketą. Jame sukuriami keli duomenų šaltiniai. Sekan-čiame 6 paveiksle matomas DTS paketas su jame sukurtais duomenų šaltiniais ir transformacija tarp jų.

8 pav. Duomenų transformavimo paketai (DTS)

Pirmame transformavimo žingsnyje panaikinami ryšiai tarp lentelių bei pirminiai raktai. Pvz.: ryšiui panaikinti tarp Apskritis ir Rajonas lentelių yra užrašoma tokia užklausa:

if exists (select * from dbo.sysobjects where id =object_id(N'[dbo].[FK_Rajonas_Apskritis]')

and objectproperty(id, N'IsForeignKey') = 1) alter table [dbo].[Rajonas] drop constraint FK_Rajonas_Apskritis go

Prieš transformuojant duomenis į saugyklą, reikia panaikinti pirminius raktus duomenų lentelėse. Pirminiams raktams panaikinti yra užrašoma tokia užklausa:

alter table [dbo].[Apskritis] drop constraint [PK_Apskritis] go.

Antrame transformacijos žingsnyje saugykla užpildoma duomenimis. Norint įvykdyti transformaciją tarp skirtingų šaltinių, pirma reikia nurodyti tarp kokių šaltinių bei kokia transformacija bus vykdoma. Kuriant saugyklos faktų lentelės užklausą, reliacinėje duomenų bazėje Užklausai įvykdyti naudojamos tokios lentelės bei ryšiai tarp jų pavaizduoti 7 paveiksle. Užklausai vykdyti generuojamas SQL sakinys:

SELECT Medziu_rusys.mr_id, Vietoves.kdv_id, Misku_tipai.mtip_id, Zemes_naudm_kateg.zk_id, Geo_objektai.pr_id, Geo_objektai.pl AS Plotas, Maketas1.amz_kl_kod, Maketas10.turis, Kv_skl.kv_id FROM Misku_tipai INNER JOIN Maketas1 INNER JOIN Medziu_rusys ON Maketas1.mr_id = Medziu_rusys.mr_id ON Misku_tipai.mtip_id = Maketas1.mtip_id INNER JOIN Geo_objektai INNER JOIN Rysiai_su_viet ON Geo_objektai.skl_id = Rysiai_su_viet.skl_id INNER JOIN Vietoves ON Rysiai_su_viet.kdv_id = Vietoves.kdv_id INNER JOIN Zemes_naudm_kateg ON Geo_objektai.zk_id = Zemes_naudm_kateg.zk_id INNER JOIN Sklypai ON Geo_objektai.skl_id = Sklypai.skl_id INNER JOIN Uredijos INNER JOIN Kv_skl ON Uredijos.mu_id = Kv_skl.mu_id ON Geo_objektai.skl_id = Kv_skl.skl_id ON Maketas1.skl_id = Sklypai.skl_id INNER JOIN Maketas10 ON Sklypai.skl_id = Maketas10.skl_id

– 18 –


Medziu_rusys

PK mr_id

FK1,I1 mgen_idU1 kl_kodU2 mr_rkodU3 mr_vardFK4,I4 pmr_tur_idFK5,I5 pmr_turj_idFK2,I2 pmr_bon_idFK3,I3 pmr_kirt_id

svoris

Misku_tipai

PK mtip_id

U3 mtip_rkodU4 mtip_skodU1 mtip_liet_vardU2 mtip_lot_vard

Maketas1

PK m1_id

FK1,I1 mr_idFK3,I3 skl_id

bon_kodskl_turamz_kl_kod

FK4,I4 up_idbrg_kod

FK2,I2 mtip_idatv

Maketas10

PK m10_id

FK3,I3 skl_idFK1,I1 ard_id

ntvskalturis

FK2,I2 nv_id

Sklypai

PK,FK2 skl_id

FK1,I1 dtg_idnusau_zem

Geo_objektai

PK skl_id

FK4,I6 zk_idplplanes


snakt_metai

Rysiai_su_viet

PK skl_viet_id

FK2,I1 kdv_idFK1,I2 skl_id

Vietoves

PK kdv_id

U1,I3 kdv_kodasI3 kdv_vardasFK1,I1 admr_idI4 nuoI2 iki

Kv_skl

PK kv_skl_id

FK1,I9 skl_idFK5,U1,I4 kv_idU1,I10 skl_nrU1,I8 skl_dalisFK6,U1,I11 ur_gir_idFK7,U1,I5 mu_idI6 nuoU1,I1 ikiFK2,I7 pr_idFK3,I2 keit_idFK4,U1,I3 klaid_id

Zemes_naudm_kateg

PK zk_id

U1 zk_kod1FK1,I1 zng_idU2 zk_vard

Kvartalai

PK kv_id

kv_plkv_plakv_nes


7 pav. Užklausos naudojamų lentelių stulpeliai ir ryšiai tarp jų faktų lentelei

7. Duomenų analizės kubai

OLAP kubai buvo kuriami naudojantis MS SQL Server 2000 Analysis Services įrankiu. Buvo sukurti trys kubai imantys duomenis iš saugyklos su skirtingomis duomenų dimensijomis. Kubo kūrimo etapai:

• Duomenų šaltinio pasirinkimas • Fakto lentelės pasirinkimas • Matavimų išskyrimas • Dimensijų išskyrimas • Kubo apdorojimas Prieš kuriant duomenų kubą pir-

miausia reikia nurodyti duomenų serverį bei duomenų bazę, iš kur bus imami duomenys. Pasirinkus faktų lentelę, iš-skyrus fakto matavimus, bei pasirinkus dimensijas turime tokią duomenų kubo struktūrą (8 pav.), kur fakto matavimai yra sumuojami duomenys.

8 pav. Sklypo analizės srities kubo struktūra

Suprojektavus duomenų kubą, reikia atlikti jo apdorojimą. Jis rekomenduojamas, kad užtikrinti tikslius rezultatus vartant kubą. Jei apdorojimas vyksta sėkmingai, suprojektuotas kubas yra teisingas ir duoda teisingus rezultatus teisingi, priešingu atveju apdorojimo metu išmetamas klaidos pranešimas, kad apdorojimas nesėkmingas, tuo atveju reikia ieškoti klaidų projektavimo žingsniuose.

Yra trys atvejai, kai kubą reikia apdoroti: jei buvo pakeista kubo struktūra, reikia atlikti pilną kubo apdorojimą; jei duomenų saugykla pasipildė naujais duomenimis, reikia atlikti atnaujintų duomenų apdorojimą; ištrynus arba pakeitus kubo duomenų šaltinį, reikia atlikti viso duomenų kubo apdorojimą.

8. Sukinio lentelės ir vartotojų ataskaitos

Sukinio (angl. pivot) lentelės paslauga yra pirminė programos sąsaja bendraujanti su MS SQL Server 2000 Analysis Services. Ji naudojama kurti vartotojų programas, kurios bendrauja su daugiamačiais duomenimis. Sukinio lentelės pagalba vartotojas gali analizuoti duomenų kubą jam patogiu būdu, realiu laiku keisti informacijos peržiūros pjūvį, gali vartyti pateiktą informacinį kubą, analizuoti informaciją grafikų pavidalu. Toliau pateiktas pavyzdys, kaip galima analizuoti duomenis sukinio lentelės pagalba.

– 19 –


Duomenų analizei atlikti pirmiausia reikia nurodyti duomenų šaltinį, t.y. kur yra sukurtas duomenų kubas Išsirinkus duomenų kubą, konstruojame sukinio lentelę. Pavyzdžiui, mus domina tokia informacija: koks minkštųjų lapuočių plotas, tūris ir aukštis Vilniaus (Tolkūno) bei Kauno (Švendubrės) apskrityse, kai miško tipas yra kiškiakopūstinė ir viksvinė-vilkdalginė bei žemių kategorija yra savaiminis medynas, ir 2002 metais.

Dimensijas bei faktų matavimus sudedame tokia tvarka:

• į duomenų vietą sukeliame visus faktų matavimus, t.y. plotas, tūris, amžius; 9 pav. Sukinio lentelės ruošimas

• į stulpelius - metus bei žemių kategorijos dimensijas; • į eilutes – miško tipus, medžių rūšis bei geografines vietovių dimensijas.

Paruošus sukinio lentelę reikia nurodyti konkrečius duomenis, kurie mus domina: • miško žemių tipą pasirenkame

kiškiakopūstinį bei viksvinį vilkdalginį;

• medžių rūšis - kiti minkštieji lapuočiai;

• metai - 2002; • žemių kategorija – savaiminis

medynas; • geografinės vietovės: • Vilniaus(Anykščių raj., Tolkūno

vietovė) • apskritis; • Kauno (Druskininkų raj.,

Švendubrės vietovė) apskritis.

10 pav. Sklypo analizės srities vartotojo ataskaita

Pasirinkę mus dominančius kriterijus, gauname ataskaitą (10 pav.). Suformuotai ataskaitai galima suformuoti grafinį vaizdą.

Formuojant sukinio lentelę, galimi įvairiausi sukiniai duomenų analizei atlikti. Jeigu duomenų saugykla pasipildo naujais duomenimis, vartotojui reikia atnaujinti sukinio lentelės duomenis.

9. Išvados

• Duomenų saugyklų projektuotojams sudaryta saugyklų kūrimo metodika, apimanti projektavimo procesą ir schemų tipų pasirinkimą. Formuojant schemą, kompleksiškai nagrinėjami vartotojų poreikiai ir esama duomenų bazės schema, laikomasi daugiamačio modelio normalizavimo, didžiausio reikiamo detalumo principų, siūlomas praktiškai pasiteisinęs iteracinio kūrimo metodas. Remiantis šiais principais, galima sukurti lanksčią saugyklos schemą, kurią galima plėsti naujoms analizės sritims.

• Pasiūlyti principai naudingi dar ir todėl kad netikslinga sukurti visą didžiulę saugyklą iš karto, nes kūrimo metu gali išryškėti klaidos ar galimi efektyvesni sprendimai. Tikslinga kurti ją palaipsniui, iteracijomis, kiekvienoje iteracijoje tobulinant rezultatus.

• Pasiūlyta metodika formalizuota sudarant saugyklos projektavimo proceso, saugyklos schemos, transformavimo ir atnaujinimo procesų modelius.

• Išanalizuotos ir įsisavintos MS SQL serverio saugyklų kūrimo ir analizės (OLAP) priemonės, aprašyta DTS duomenų transformavimo, daugiamačio kubo modelio sudarymo OLAP įrankio aplinkoje bei sukinio lentelių sukūrimo ir naudojimo metodika.

• Išanalizuotas Miškų informacinės sistemos duomenų modelis, operacinės duomenų bazės schema ir veiklos analizės poreikiai. Šios analizės pagrindu suprojektuota duomenų saugykla svarbiausioms analizės sritims: sklypų, medynų, kirtimų ir atkūrimo analizei. Saugyklos schema paremta snaigės tipo schema.

• MS SQL Server 2000 priemonėmis sukurta eksperimentinė Miškų IS saugykla pagrindinėms analizės sritims, realizuoti duomenų transformavimo komponentai, skirti saugyklos užpildymui duomenimis bei jų

– 20 –


atnaujinimui. Saugykla užpildyta duomenimis, sukurti analizės kubai ir sukinio lentelės vartotojams. Numatytos saugyklos plėtimo galimybės naujų analizės sričių ar pirminės duomenų bazės plėtimo atveju.

Literatūros sąrašas [1] Moody D., Kortink M.. 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, 2000m. [žiūrėta 2002-11-06]. Prieiga per Internetą:http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-28/paper5.pdf

[2] Kimball R. The Data Warehouse Toolkit: Practical Techniques for Building Dimensional Data Warehouses, John Wiley & Sons, 2002.

[3] Inmon W.H. Building the Data Warehouse. John Wiley & Sons, 2002. [4] Silverston L.,Inmon. The Data Model Resource Book.-Willey Computer Publishing,1997 [5] Lechtenberger J. Data Warehouse Schema Design. Extended Abstract of Doctoral Thesis. Dept. of Information Systems.

University of Munster, Berlin, 2001. [6] Kimball R. The Data Webhouse Toolkit: Building the Web-Enabled Data Warehouse", John Wiley & Sons, 2000. [7] Nemuraitė L., Tonkūnaitė J. Duomenų saugyklos projektavimo metodika // Informacinės technologijos ir mokslų

integracija – 2003. VU, 2003, p. 121-124.

Data Warehouse Development Process Model

Data stored in databases would be worthless if it is impossible to view it in different, customized profiles. Only that way the data becomes valuable information that can be used for business development and planning, customer segmentation and risk management or optimization of costs, business processes and resources. Creation of data warehouse enables the user to study the available data by using various multidimensional database profiles, to derive new indexes and compare them, to group according to respective criteria, to study in respect of different levels of aggregation. In this paper the process for development of data warehouse is proposed. Process was studied using MS SQL Server Data Warehousing tools and applied for creation of warehouse for analysis of forest resources.

– 21 –

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

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

LYGINAMOJI OLAP PRIEMONIŲ ANALIZĖ IR TAIKYMAS INTERNETO SVETAINĖSE

Marius Vilimas, Lina Nemuraitė Kauno Technologijos Universitetas

Informacijos sistemų katedra, Studentų 50-308

Straipsnyje nagrinėjamos interneto svetainėse kaupiamų duomenų analizės galimybės naudojant analitinio duomenų apdorojimo priemones. Nagrinėjami šių priemonių rinkiniai, įeinantys į Lietuvoje plačiausiai naudojamų duomenų bazių valdymo sistemų - Microsoft SQL ir Oracle serverių – programinę įrangą, lyginamos jų galimybės.

1. Įvadas

Pastaruoju metu sparčiai daugėja interneto svetainių ir jose besilankančių žmonių. Interneto sistemose apie lankytojus sukaupiami dideli duomenų kiekiai. Tačiau daugelyje svetainių šie duomenys taip ir lieka nepanaudoti. Norint juos analizuoti ir panaudoti svetainės tobulinimui reikalingos specialios sistemos. Straipsnyje siūloma šiam tikslui naudoti analitinio duomenų apdorojimo priemones

Interneto svetainės lankomumo analizės sistemoje naudojamos dvi pagrindinės metrikos: vartotojo vizitų ir puslapio užklausų skaičius. Vizitas – tai vartotojo apsilankymas interneto svetainėje apskritai. Pavyzdžiui, jei lankytojas naršyklėje surinko kokios nors svetainės adresą ir pateko į kažkurį šios svetainės puslapį tai jis atliko vizitą. Puslapio užklausa - tai vartotojo kreipimasis į kažkurį svetainės puslapį. Vieno vizito metu vartotojas gali atlikti daug užklausų skirtinguose puslapiuose. Pagal vizito metu atliekamas užklausas galima daryti išvadas kokia informacija vartotoją labiausiai domina, kuriuos puslapius jis dažniausiai lanko.

2. Daugiamatis duomenų modelis

Duomenis apdoroti analitiškai galima perkėlus juos į specialiai analitiniam apdorojimui pritaikytą daugiamatę duomenų struktūrą – duomenų kubą (1 pav.).

FaktasDimensijų nariai

Matavimas

Dimensijos

1 pav. Duomenų kubas

Pagrindinės daugiamačio duomenų modelio sąvokos [4]: Dimensija - viena pagrindinių sąvokų daugiamačiame duomenų modelyje. Kiekviena dimensija saugo

informaciją apie tą patį faktą skirtingame kontekste. Tai padeda gauti ar apskaičiuoti kažkokią reikšmę tam tikrame detalizacijos lygyje. Dimensijos dažnai turi hierarchinę struktūra. Pavyzdžiui, nagrinėjant tam tikro laikotarpio pardavimus, savaitės dimensijos jungiamos į mėnesių dimensijas, o šios savo ruožtu į metų ir taip toliau. Tam tikras

– 22 –

Lyginamoji OLAP priemonių analizė ir taikymas interneto svetainėse

duomenų lygis be jį sudarančių dimensijų gali turėti papildomų savybių, pavyzdžiui prekės matavimo vienetą, kuris tam tikroje dimensijoje nekinta ir nedidina dimensijų skaičiaus.

Faktas kube vaizduoja subjektą – analizuojamą šabloną ar įvykį. Faktą dažniausiai identifikuoja dimensijų kombinacija. Faktas egzistuoja tik tada, jei yra jį atitinkanti visų dimensijų reikšmių kombinacija. Dauguma daugiamačių duomenų modelių reikalauja, kad faktas turėtų bent jau žemiausio hierarchijos lygio dimensijų reikšmių kombinaciją (Aukštesnio lygio dimensijų reikšmės gali būti gaunamos agreguojant žemesniųjų lygių reikšmes). Kiekvienas faktas turi savo detalumą. Kurį nulemia jį sudarančių dimensijų detalumas bei vieta dimensijų hierarchijoje. 1 paveikslėlio pavyzdyje fakto detalumas yra: metai pagal miestą ir produktą. Detalumai sudaryti iš aukštesnių arba žemesnių hierarchijų dimensijų yra detalesni (angl. finer) arba labiau apibendrinti (angl. coarser).

Matavimus sudaro dvi dalys: Skaitmeninė išraiška (pavyzdžiui prekės kaina) ir formulė – dažniausiai parasta aritmetinė išraiška, tokia kaip „sum“ funkcija, kuri gali apjungti keletą matavimų reikšmių į vieną. Daugiamačiame duomenų modelyje matavimai dažniausiai išreiškia faktų savybes, kurias vartotojas nori optimizuoti. Tai yra skirtingos reikšmės įvairioms matavimų kombinacijoms. Savybė ir formulė parenkama taip, kad matavimas turėtų prasmę įvairiose dimensijų kombinacijose. Pati formulė yra modelio metaduomuo.

Pirmame paveiksle pateiktas duomenų kubo su pardavimų duomenimis pavyzdys. Jį sudaro 3 dimensijos: laiko, vietos ir prekių. Faktas yra parduotų prekių kiekis kažkuriame mieste kažkuriais metais, o matavimas – šio kiekio skaitinė išraiška.

3. Daugiamačio duomenų modelio algebra

Duomenų kubams ir operacijoms su jais aprašyti galima naudoti specialią daugiamačių duomenų algebrą. Kubas joje apibrėžiamas 4 kortežais : <D, M, A, f>. Taigi kubą apibūdina 4 komponentai:

• D - n dimensijų aibė d = {d1, d2,…dn}, kur kiekviena di priklauso domenui domdim(i). • M - k matavimų aibė m={m1, m2, … mk}, kur kiekvienas mi priklauso domenui dommeasure(i) • Dimensijų ir matavimų aibės nesikerta 0=MD I .

• A- t atributų aibė a={a1, a2,… at}, kur kiekvienas ai atributo pavadinimas iš domeno domattr(i) • Vienas-su-daug vaizdas f: egzistuoja kiekvienai dimensijai priklausanti atributų aibė. Vaizdas yra

toks, kad atributų aibės, priklausančios dimensijoms poromis nesusikerta:

AD →

0)( =jd)(,,, ∩≠∀ i fdfjijiPavyzdys: pardavimų kubas (3.1. pav.): D={LAIKAS, PREKĖ, VIETA} Vartotoją domina matavimai: M={pardavimų_suma, kiekis} Kubo dimensijos turi tokius atributus: A={diena, metai, mėnuo, prekės_pavadinimas, svoris, spalva, parduotuvės_pavadinimas, miestas,

valstybė} Vaizdas f priskiria atributus konkrečiai dimensijai: f(LAIKAS) = {diena, metai, mėnuo} f(PREKĖ) = {prekės_pavadinimas, svoris, spalva} f(VIETA) = {parduotuvės_pavadinimas, miestas, valstybė} Reikia pastebėti, kad pateiktos atributų aibės nesikerta.

Naudojant šį apibrėžimą, duomenų kubams galima pritaikyti tokius operatorius: • Apribojimas (angl. restriction)– apribojimo operatorius apriboja reikšmių aibę viename ar keliuose

matavimuose (viename kube). • Agregavimas (angl. agregation)- vykdo aritmetines operacijas viename ar daugiau matavimų. Jis yra

sukurtas reliacinės algebros operatoriaus vykdančio MAX, MIN, AVG, SUM funkcijas bazėje ir taikomas kubuose su viena ar daugiau dimensijų sudaromų iš „grupuojančių atributų“ (angl. grouping atributes).

• Dekarto sandauga (X): Dekarto sandauga yra dvejetainis operatorius, kuris gali būti panaudotas susiejant du kubus.

• Ryšio operatorius (angl. join) – tai ypatingas Dekarto sandaugos operatoriaus atvejis, naudojamas susieti dviems kubams, turintiems po vieną ar dvi tokius pačias dimensijas ir identiškus atitikmenis į tų dimensijų atributų rinkinius.

– 23 –

M. Vilimas, L. Nemuraitė

• Sąjungos operatorius : sąjungos operatorius suranda dviejų kubų sąjungą. ( )∪• Skirtumo (angl. difference ) operatorius (-): skirtumo operatorius suranda skirtumą tarp dviejų kubų. • Traukos operatorius (angl. pull - φ ) – konvertuoja matavimus į dimensijas.

• Stūmimo operatorius (angl. push - ψ ) – konvertuoja dimensijas į matavimus.

4. OLAP priemonių naudojimas interneto svetainėje kaupiamų duomenų analizei

Norint atlikti svetainėje kaupiamų duomenų analizę naudojant OLAP priemones, reikia atlikti eilę transformacijų [1], [2], [3]. Transformacijų seka pateikta 2 paveiksle:

Ataskaitos

Svetainė

Lankytojo duomenų kaupimas

Įrašai tekstiniuose failuose

Tekstinių failų transformavimas į reliacinę struktūrą

R1 : Įrašai reliacinės DB lentelėse

R2 : Įrašai reliacinės DB lentelėse

Duomenų transformavimas į žvaigždės/snaigės schemą

Duomenys duoemnų saugykloje

Duomenų perkelimas į daugiamatę struktūrą

Daugiamačiai duomenys (MOLAP)

Daugiamačių kubų peržiūros priemonių naudojimas

2 pav. Svetainėje kaupiamų duomenų perkėlimo į OLAP įrankius transformacijų seka

Transformavimo žingsnių aprašymas: 1. Lankomumo duomenų kaupimas – daugumoje internete veikiančių sistemų fiksuojamas kiekvienas

puslapio parodymas. Galime sužinoti kokiu metu ir koks svetainės puslapis buvo žiūrėtas. Kartais turime ir daugiau informacijos: koks vartotojas puslapį žiūrėjo, kokia geografinė vartotojo buvimo vieta, jo amžius ir t.t.

Dažniausiai šie duomenys rašomi į tekstinius failus. Tai mažiausiai sistemos resursų reikalaujanti ir greičiausiai atliekama duomenų saugojimo operacija. Kai kuriose svetainėse, kurių apkrautumas (vartotojų skaičius) santykinai nedidelis, lankomumo duomenys gali būti rašomi tiesiai į kokios nors DBVS reliacines lenteles. Tokiu atveju tekstinių duomenų failų transformavimo į reliacinę struktūrą žingsnis praleidžiamas.

– 24 –


2. Tekstinių failų transformavimas į reliacinę struktūrą – norint analizuoti tekstinių failų pavidalu sukauptus lankomumo duomenis pirmiausia juos reikia transformuoti į reliacinę struktūrą. Tekstiniuose failuose duomenys atskiriami tam tikrais skyrikliais (dažniausiai kableliais arba kabliataškiais) skyrikliais atskirti duomenys importuojami į atitinkamus reliacinės lentelės stulpelius. Kiekvienas naujas įrašas faile pradedamas nauja eilute. Taigi, lentelėje po importo turėsime tiek pat įrašų, kiek eilučių buvo tekstiniame faile.

3. Duomenų transformavimas į žvaigždės/snaigės struktūra – iš tekstinių failų importuoti duomenys patenka į vieną duomenų bazės lentelę. Tam, kad galėtume juos analizuoti naudojant OLAP priemones, duomenys turi būtų žvaigždės arba snaigės daugiamatėje duomenų struktūroje. Formuojamos dimensijos, kuriomis duomenis norėsime nagrinėti, bei faktų lentelė. Pirmiausiai suformuojamos dimensijos atrenkant skirtingus (angl. DISTINCT) duomenis, pagal kuriuos darysim dimensijas iš bendros lankomumo duomenų lentelės. Tada formuojama faktų lentelė, kurioje kiekvienas įrašas atitinka viena svetainės puslapio parodymą. Visų rišančiųjų su dimensijomis stulpelių duomenys gaunami paimant (angl. look-up) atitinkamus identifikatorius iš dimensijų lentelių. Šį procesą detaliai galima pavaizduoti veiklos diagrama, pateikta 2 paveiksle.

4. Duomenų perkėlimas į daugiamatę struktūra (MOLAP). Daugiamačius duomenis galima peržiūrėti vykdant užklausas reliacinėje duomenų bazėje (ROLAP). Tačiau procesas žymiai pagreitėja duomenis perkėlus į daugiamačių duomenų saugojimo bazę ir paskaičiavus kai kurias sumas (MOLAP). Šiame žingsnyje reliacinius duomenis perkeliame į daugiamatę saugyklą. Kai kuriose sistemose toks perkėlimas gali būti ir neatliekamas. Pvz. MS SQL Analizės servisuose (angl. Analysis services) daugiamačiai duomenys būtinai turi būti transformuojami į MOLAP kubus tolimesniam apdorojimui. ORACLE duomenų bazės naujausioje versijoje 9iR2 daugiamačių duomenų užklausos atliekamos tiesiog reliacinėje duomenų bazėje. Skaičiavimams pagreitinti gali būti naudojamos tarpinės iš anksto paskaičiuotos lentelės - materializuoti vaizdai (angl. Metherialized Views). Taigi šiuo atveju turime ROLAP arba HOLAP. ROLAP atveju užklausos atliekamos tiesiog reliacinėje duomenų bazėje, o HOLAP atveju prieš jas atliekant dar reikia suformuoti tarpines lenteles.

5. Daugiamačių kubų peržiūros priemonių naudojimas. Galutinis duomenų transformacijų tikslas – pateikti juos analitikui suprantama forma. Tam naudojamos analitinės duomenų peržiūros ir ataskaitų generavimo priemones. Šios priemonės daugiamačius duomenis saugomus reliacinėje ar daugiamatėje duomenų bazėje pateikia vartotojui suprantama interaktyvių kubų bei ataskaitų forma.

Svetainės duomenų analizės sistemos architektūra parodyta 3 paveiksle.

WEB svetainės PI

Lankytojo duomenu kaupimo posisteme

Duomenu importo posisteme

Reliacine duomenu baze

Duomenu saugyklaDaugiamate

duomenu baze

Kubu perziuros priemones

WEB serveris

Reliavines DBVS serveris OLAP serveris

Kubu kurimo priemones

Duomenu transformavimo posisteme

3 pav. Svetainės duomenų analizės sistemos architektūra

5. OLAP priemonių, kurių pagalba gali būti atliekama duomenų analizė, apžvalga

Į daugumos šiuolaikinių duomenų bazių valdymo sistemų sudėtį įeina vienokios ar kitokios analitinio duomenų apdorojimo priemonės. Panagrinėsime du šių priemonių rinkinius, įeinančius į plačiausiai Lietuvoje naudojamus duomenų bazių valdymo sistemų paketus: Microsoft SQL serverį ir Oracle serverį.

5.1. Microsoft SQL serverio priemonės

Bendra sistemos architektūra, naudojant Microsoft SQL serverio analitinio duomenų apdorojimo priemones, pateikta 4 paveiksle.

– 25 –


5.1.1. Duomenų transformavimo servisai

MSSQL duomenų bazių valdymo sistemoje duomenų transformacijoms, importavimui ir eksportavimui naudojami DTS (angl. data transformation services) (duomenų transformavimo servisai). Jie puikiai tinka ir OLTP sistemos duomenų perkėlimui į duomenų saugyklą, kurioje vėliau bus atliekama duomenų analizė.

4 pav. Sistemos architektūra, naudojant MS SQL priemones

DTS pateikia priemonių rinkinį, kuris leidžia išgauti, transformuoti ir susieti duomenis esančiuose skirtinguose šaltiniuose, prisijungimą prie kurių palaiko DTS prisijungimų posistemė.

5.1.2. Analizės servisai

Naudojant DTS servisus galima suformuoti tolesniam duomenų apdorojimui reikalingas struktūras - duomenų kubus. Duomenų kubų užpildymui reliacinėse duomenų bazėse saugomais duomenimis ir kubų peržiūrai naudojami į MS SQL programų paketą įeinantys analizės servisai (angl. Analysis services).

OLAP serveris yra tarpinė grandis tarp duomenų saugyklos (realizuotos DBVS pagalba) ir kliento aplikacijos. Tokiu atveju OLAP serveris turi versti duomenis iš reliacinio pavidalo, į pavidalą patogesnį analitinių ataskaitų formavimui – OLAP kubus. Todėl pagrindinis šio paketo komponentas yra Analizės serveris (angl. Analysis Server) - operacinės sistemos Windows NT/2000 servisas. Šis serveris skirtas OLAP kubų kūrimui iš reliacinės duomenų bazės duomenų, bei prieigai prie šių duomenų iš klientinių aplikacijų.

Teoriškai OLAP kubas, sukurtas naudojant Microsoft analizės servisus, gali talpinti visus faktų lentelės duomenis ir agreguotas išraiškas toms įrašų grupėms iš šios lentelės, kurios atitinka viršutinį matavimų hierarchijos lygį. Kai reikia, galima dinamiškai atnaujinti kubą, jeigu faktų lentelėje įvyko duomenų pakeitimai. Taip pat leidžiama pasirinkti ar žemesniu hierarchijos lygių duomenys bus saugomi pačiame kube (atitinka MOLAP duomenų saugojimo modelį), ar bus gaunami iš faktų lentelė (ROLAP ar HOLAP). Kubo duomenis peržiūrinčiam vartotojui nėra jokio skirtumo, koks duomenų saugojimo modelis naudojamas kube.

Analizės servisai saugo tik paprasčiausių agreguojančių funkcijų agreguotus duomenis (sumas, įrašų skaičių minimalias ir maksimalias reikšmes). Tačiau esant reikalui galima sudaryti taip vadinamus skaičiuojamus elementus (angl. calculated members) panaudojant žymiai daugiau analitinių funkcijų.

Sukūrus keletą kubų, turinčių tas pačias dimensijas, juos galima sugrupuoti į vieną daugiamatę duomenų bazę, o dimensijas apjungti į vieną biblioteką (angl. library). Tokios dimensijos bus prieinamos visiems kubams (angl. shared dimensions)

Galiausiai Analizės servisai leidžia sudaryti taip vadinamus virtualius kubus, kurie yra vaizdų (angl. views) analogas reliacinėje duomenų bazėje.

5.1.3. Pivot Tables komponentas

Tai yra COM+ komponentas, kurį galime panaudoti į Microsoft Office paketą įeinančiose ofiso programose, pavyzdžiui Excel. Jis leidžia prisijungti prie Analizės serveryje saugomų duomenų kubų, vykdyti čia daugiamačių duomenų (MDX) užklausas ir pateikia duomenis lenteline forma arba grafikais. Šio komponento privalumas, kad jis pilnai integruojasi į tokias vartotojams įprastas programas kaip Microsoft Excel. Juo paprasta naudotis tiems, kas turi bent bazines šios taikomosios programos. Šis komponentas leidžia keisti kubo dimensijas, kubo detalumus (atlikti einančias gilyn (angl. drill-down), ir apibendrinančias (angl. drill-up) užklausas). Grafinės ataskaitos vaizdas, gautas naudojant Pivot Tables komponentą Microsoft Excel taikomojoje programoje, pateiktas 5 paveiksle.

– 26 –


0

50000

100000

150000

200000

250000

300000

2clu

b

2con

tent

2film

s

2for

um 2fun

2girl

s

2mes

sagi

ng

2nav

i

2not

ice

2sm

s

2use

r

2uzs

ak

3clu

b

3for

um

4clu

b

4con

tent

addo

n

cont

ent

flirt

mai

n

navi

revi

ew sh

2003 - May2003 - April

Click

Module Name

YearMonth

5 pav. Grafinė ataskaita Microsoft Excel taikomojoje programoje

5.2. Oracle serverio priemonės

Bendra sistemos architektūra, naudojant Oracle serverio analitinio duomenų apdorojimo priemones pateikta 5 paveiksle.

5 pav. Sistemos architektūra naudojant Oracle priemones

5.2.1. Duomenų saugyklų kūrėjas (angl. Warehouse Builder)

Saugyklų kūrėjas yra bendra duomenų saugyklų ir verslo analizės sistemų projektavimo ir realizacijos priemonė. Joje apjungiami pagrindiniai duomenų išgavimo, transformacijos ir įdėjimo (ETL) komponentai ir projektavimo aplinka.

Saugyklų kūrėjas architektūriškai susideda iš dviejų komponentų: kūrimo ir vykdymo aplinkų. Kūrimo aplinka dirba su saugyklos metaduomenis, o vykdymo aplinka su fiziniais duomenimis.

• Pagrindinės saugyklų kūrėjo funkcijos: • Duomenų šaltinių aprašų importas. • Duomenų bazės schemos projektavimas ir kūrimas • Duomenų perkėlimo ir transformavimo tarp šaltinio ir imtuvo aprašymas • Priklausomybių tarp ETL procesų aprašymas • Duomenų šaltinių aprašymų tvarkymas ir atnaujinimas • Analitinių (ad-hoc) užklausų aplinkos kūrimas • OLAP aplinkos kūrimas

Saugyklų kūrėjas generuoja DDL ir PL/SQL kodus kurie vėliau vykdomi ORACLE duomenų bazėse. Šie kodai optimizuojami, norint pasiekti kuo didesnį duomenų bazės produktyvumą.

5.2.2. Kubų kūrimo priemonės OEM konsolėje

Visi pagrindiniai ORACLE duomenų bazės administravimo bei duomenų struktūrų keitimo veiksmai gali būti atliekami naudojant vieningą administravimo priemonę – OEM (angl. Oracle Enterprise Management) konsolę. Ji taip pat leidžia kurti OLAP dimensijas bei kubus. Kuriant šiuos OLAP objektus galima naudotis vedliais (angl. wizards). Į OEM programinių priemonių sudėtį įeina ir duomenų kubų peržiūros priemonė Cube Viewer. Jos pagalba galima peržiūrėti ką tik sukurtus duomenų kubus. ORACLE‘e duomenų bazėje kubai neperkeliami į kitą saugyklą (naudojamas HOLAP). Todėl kubus galima peržiūrėti vos tik juos sukūrus. Nereikia jokio papildomo duomenų

– 27 –


perkėlimo (angl. cube processing). Kubų peržiūroms pagreitinti naudojamos specialios ORACLE duomenų bazės tarpinės lentelės – Materializuoti vaizdai (angl. Matherialized Views). Juose gali būti saugomos visos iš anksto paskaičiuotos kubų sumos.

5.2.3. „BI Beans“ OLAP prieiga

BI Beans tai JAVA komponentų rinkinys leidžiantis naudotis ORACLE OLAP API (programinę prieigą). Šie komponentai turi vizualias duomenų kubų atvaizdavimo priemones. Juos galima naudoti tiek įprastinėse JAVA programose tiek JSP technologijos pagalba rašomose internete veikiančiose programose. Grafinės ataskaita interneto sistemoje pateikta 6 paveiksle.

6 pav. Grafinė ataskaita interneto sistemoje

6. Analitinio duomenų apdorojimo priemonių palyginimas 6.1. OLAP priemonių įgyvendinimas 1 lentelė. Pagrindiniai priemonių architektūrinio įgyvendinimo skirtumai

Savybė MSSQL Oracle Daugiamačių duomenų saugyklos vieta

Atskiras servisas (Analizės servisai)

Reliacinėje ORACLE duomenų bazėje

Užklausų vykdymo mechanizmas Vykdomos analizės servisuose Vykdomos pagrindinės duomenų bazės branduolyje

Microsoft SQL serverio analizės serveriai praktiškai yra atskirti nuo paties DBVS serverio. Tuo tarpu ORACLE kompanija renkasi kitokią strategiją ir naujausioje duomenų bazės versijoje Oracle9iR2 OLAP serverį integravo į pagrindinės duomenų bazės branduolį (1 lentelė). Šis sprendimas suteikia tokius privalumus lyginant su dviejų atskirų (reliacinės ir daugiamatės) bazių naudojimu:

• Supaprastėjęs konfigūravimas ir priežiūra. Visi priežiūros veiksmai atliekami vienoje duomenų bazėje, naudojant vieną programinę priemonę: angl. Oracle Enterprise Manager, PL/SQL konsolę ar k.t.

• Aukštas patikimumas. Oracle OLAP turi tas pačias plėtimo bei prieigos galimybės kaip ir Oracle reliacinė duomenų bazė. Oracle OLAP patikimumas yra labai aukštas. Ši sistema gali veikti realiuose sistemų klasteriuose.

• Aukštas saugumo lygis. Oracle užtikrina vieningą saugumo mechanizmą visiems duomenims esantiems duomenų bazėje. Tai taikoma ir daugiamačiams kubams. Informacija apie visus reliacinės ir daugiamatės

– 28 –


duomenų bazės vartotojus saugoma bendrame kataloge, jiems bendrai suteikiamos atitinkamos rolės ir privilegijos.

• Atvira prieiga. Ir reliaciniai ir daugiamačiai duomenys gali būti pasiekiami per SQL arba OLAP API. Programų kūrėjai gali rinktis, ar naudoti OLAP API teikiamus privalumus ar kreiptis į duomenų bazę naudojant paprastas SQL užklausas.

6.2. Duomenų perkėlimo bei transformavimo priemonės

Duomenų perkėlimo bei transformavimo priemonių MS SQL serveryje ir Oracle lyginamoji analizė pateikta 2 lentelėje.

2 lentelė. Duomenų perkėlimo ir transformavimo priemonių skirtumai

Savybė DTS (MS SQL) Saugyklų kūrėjas (ORACLE) Pagrindinės metaduomenų saugyklos vieta

MSSQL duomenų bazė (msdb) ORACLE duomenų bazė (schema bet kurioje bazėje)

Galimos alternatyvios metaduomenų saugojimo vietos

Struktūriniai failai, VisualBasic failai

Struktūriniai failai, OMG CWM standartą suprantančios sistemos

Objektų vykdymo vieta Operacinė sistema (Windows) Duomenų bazė (Oracle) Naudojamos programavimo kalbos VB script PL/SQL

Didžiausias skirtumas tarp ETL priemonių įgyvendinimo MS SQL ir Oracle yra šiomis priemonėmis sukurtų objektų vykdymo būdas. DTS (duomenų transformavimo servisų) objektai vykdomi operacinėje sistemoje. Taikant tokį vykdymo būdą sumažinama duomenų bazės apkrova bei supaprastinamas šių objektų įdiegimas, tačiau atsiranda daug kitų problemų:

• Tinklo apkrovimas (jei objektai vykdomi ne toje pačioje sistemoje kurioje yra duomenų bazės). • Prisijungimų prie duomenų bazių nevienareikšmiškumas. Objektai gali būti vykdomi bet kuriame

kompiuteryje kuriam leidžiama prisijungti prie duomenų bazių serverio saugančio DTS. Tačiau jungiantis iš skirtingų potinklių prisijungimų aprašai esantys DTS‘uose gali skirtis. Tokiu atveju duomenų šaltiniai ar imtuvai bus nepasiekiami, arba dar blogiau, bus naudojami ne tie šaltiniai ar imtuvai kuriuos DTS kūrėjas buvo numatęs naudoti.

• Vieningos vykdymo terpės nebuvimas. Nėra apsaugos nuo situacijos, kai tas pats objektas dviejuose skirtinguose kompiuteriuose vykdomas tuo pačiu metu. Tokiu atveju imtuvo duomenys gali būti negrįžtamai sugadinami.

Oracle ETL priemonėje „Saugyklų kūrėjas“ (angl. Warehouse Builder) išvengiama aukščiau išvardintų problemų. Tačiau sukurtų objektų diegimas (ir vykdymas) yra žymiai sudėtingesnis.

Lyginant funkcines šių dviejų ETL priemonių savybes, Warehouse Builder turi didesnes iš anksto sukurtų transformacijų bibliotekas ir leidžia transformacijų pagalba gauti daugiau duomenų bazės objektų tipų. (ne tik lenteles ir vaizdus (angl. view), bet ir dimensijas, kubus ir k.t.)

6.3. Kubų peržiūros per WEB galimybės

3 lentelė. Kubų peržiūros per WEB galimybės

Savybė Pivot Tables servisas BI beans Jungimosi prie DB būdas Per WEB servisą iš kliento pusės Tiesiogiai prie DB iš serverio Serverio pusės objektai Neturi Turi lenteliniai ir grafiniai

pateikimo formai Kliento pusės objektai Turi lentelinei ir grafinei duomenų

pateikimo formai Neturi

ORACLE priemonės yra universalesnės, nes norint jomis naudotis nereikia jokių papildomų komponentų kliento pusėje. Duomenis peržiūrėti galima su bet kokia Interneto naršykle, palaikančia HTML ir JavaScript. Tuo tarpu norint peržiūrėti „Pivot Tables“ komponentu paremtus WEB puslapius, šis komponentas turi būti kiekvieno kliento kompiuteryje (instaliuojamas kartu su Office XP). Kadangi komponentas pasiekiamas naudojant COM+, jis gali būti matomas tik Internet Explorer 5.0 (arba naujesnėje) naršyklėje. Naudojant tokį modelį kiekviename

– 29 –


kompiuteryje turį būti Office XP (kurio reikia norint naudoti „Pivot Tables“ komponentą) licenzijuota versija. Taigi tuo atveju, kai turime daug darbo vietų tokios technologijos naudojimas yra žymiai brangesnis nei technologijos paremtos „BI beans“.

6.4. Kubų peržiūros naudojant ofiso programas galimybės

4 lentelė. Kubų peržiūros galimybės naudojant ofiso programas

Savybė MSSQL Oracle Kubo peržiūra MS Excel pagalba „Pivot Tables“ komponentas Neturi

Plačiausiai naudojama ofiso analizės programa Microsoft Excel yra to paties gamintojo kaip ir SQL serveris. Taigi šie produktai gali būti integruojami duomenų lygyje. „Pivot Tables“ komponento pagalba MS Excel programoje galima peržiūrėti analizės servisuose saugomus kubus. Oracle priemonės tokių galimybių neturi (6.7 lentelė).

7. Išvados

Straipsnyje supažindinama su analizei naudojamu daugiamačiu duomenų modeliu ir pateikiama bendra metodika, kaip perkelti svetainėse kaupiamus duomenis į šiuolaikinių DBVS analizės įrankius. Pagal šią metodiką sukurti du prototipai, kurių pagalba atliktas plačiai naudojamų MS SQL Server ir Oracle analizės priemonių galimybių tyrimas ir nustatyti šių įrankių trūkumai bei privalumai:

MSSQL privalumai ir trūkumai Privalumai:

• Lengviau instaliuojamas. • Mažesnė kaina už panašaus funkcionalumo paketą. • OLAP priemonės gali būti prieinamos naudojant plačiausiai paplitusius biuro programinės įrangos rinkinius

Microsoft Office 2000 ir Microsoft Office XP. • Mažesnės dokumentacijos apimtys.

Trūkumai: • Veikia tik Windows operacinėje sistemoje. • Ne itin patogios OLAP priemonėmis sukurtų ataskaitų pateikimo Interneto svetainėje galimybės. • Nėra bendro reliacinės duomenų bazės ir daugiamatės duomenų bazės serverių saugumo mechanizmo.

ORACLE privalumai ir trūkumai Privalumai:

• Veikia beveik visose plačiau paplitusiose operacinėse sistemose. • Lankstesnė architektūra. Didesnis instaliavimo ir konfigūracijos variantų pasirinkimas, daugiau procesų

galima paskirstyti keliems kompiuteriams. • Patogios OLAP priemonėmis suformuotų ataskaitų pateikimo Interneto svetainėje priemonės. Ataskaitas

galima peržiūrėti bet kokia naršykle. • OLAP serverio integravimas į pagrindinį duomenų bazės serverį užtikrina didesnį saugumą ir sistemos

stabilumą. Trūkumai:

• Sudėtingiau instaliuoti ir konfiguruoti. • Didelė kaina. • Nėra integravimo į biuro programų paketus priemonių.

Literatūros sąrašas [1] Федоров A., Елманова H.. Введение в OLAP: часть 3. Архитектура Microsoft Analysis Services. КомпьютерПресс

6, 2001. [2] Oracle Corporation. Oracle9i Warehouse Builder User’s Guide Release 2 (9.2). 2003-07, p.41-49. [3] Oracle Corporation. Oracle9i OLAP User’s Guide Release 2 (9.2) 2002-03, p. 39-48.

– 30 –


[4] Datta A., Thomas H. The cube data model: a conceptual model and algebra for on-line analytical processing in data warehouses // Decision Support Systems, Vol. 27, 1999, p. 289–301

Olap for Web Data Analysis

In current paper the multidimensional data model is described which is used for analysis of data in Data Warehouses and OLAP. The possibilities to analyse data gathered from Web sites are studied and methodological framework for transfer of these data to OLAP tools is defined. Comparative analysis of Microsoft SQL Server and Oracle OLAP tools is presented.

– 31 –

ELEKTRONINIO VERSLO PROCESŲ MODELIAVIMO IR TINKLO PASLAUGŲ KŪRIMO METODIKA

Lina Nemuraitė, Aidas Oželis Kauno Technologijos Universitetas

Informacijos sistemų katedra, Studentų 50-308

Straipsnyje analizuojama verslo procesų vykdymo kalba BPEL4WS, skirta verslo procesams automatizuoti tinklo paslaugų technologijų pagrindu. Tai viena naujausių verslo modeliavimo kalbų, jungianti struktūrinio ir srautinio modeliavimo metodus. Straipsnyje pateikta UML verslo modelių transformavimo į BPEL4WS metodika, kuri pritaikyta įgyvendinant eksperimentinę B2B sistemą, automatizuojančią tiekimo procesą.

1. Įvadas

Šiuolaikinės e.verslo sistemos turi leisti bendradarbiauti bet kam su bet kuo. Tai reikalauja automatizuoto įvairių duomenų tipų bei verslo logikos palaikymo. Šiam tikslui reikia sukurti išplečiamas tarpininkavimo paslaugas XML pagrindu. Tokios paslaugos teikiamos keičiantis XML dokumentais Web servisų pagalba. Verslo procesų automatizavimas reikalauja kurti procesų pagrindu veikiančias programas (process-based applications). Tai tokios programos, kurių struktūra dalijama į du atskirus sluoksnius: viršutinis sluoksnis – verslo proceso sluoksnis – XML kalba aprašyta programos vykdymo logika (šiame darbe ji aprašoma Business Process Execution Language (BPEL)), o apatiniame sluoksnyje esantys Web servisai atitinka programos funkcinę logiką ir yra vykdomi pagal viršutinio sluoksnio scenarijų.

Tokia architektūra turi keletą ženklių privalumų: tiek verslo procesą, tiek pačius Web servisus galima keisti ir modifikuoti, jiems tiesiogiai neįtakojant vienas kito. Tai suteikia sistemai labai didelį lankstumą, kas svarbu sąveikaujant su kitomis sistemomis bei įmonėmis.

Automatizuotų elektroninio verslo procesų kūrimas reikalauja ne tik išsamios verslo srities analizės bei aiškaus Web servisų kūrimo technologijų suvokimo, bet ir efektyvios metodikos, leidžiančios taikliai nustatyti verslo sąveikų tipus, dalyvius bei proceso veiklų sekas, efektyviai organizuoti jų vykdymo eiliškumą.

2. Vykdomosios elektroninio verslo kalbos BPEL4WS apžvalga 2.1. Tinklo paslaugų kompozicija į procesus BPEL4WS kalboje

Web servisų esmė yra universalus programų sąveikavimas naudojant egzistuojančius interneto standartus. Technologiniu požiūriu Web servisai sudaryti iš trijų lygmenų, kurių kiekvienas atsakingas už atskiras Web serviso funkcionavimo sritis:

UDDI – The Universal Description, Discovery, and Integration – klientams teikia Web Servisų suradimo ir registravimo paslaugas. Naudojant UDDI interfeisą, galima dinamiškai susirasti reikalingus ar partnerio siūlomus Web Servisus.

WSDL – Web Services Description Language – apibūdina Web serviso prieigą ir protokolus. SOAP – Simple Object Access Protocol – pranešimų schema, apibūdinanti vienodą XML aprašytų duomenų

siuntimą ir transportavimo formatą. Sistemų sąveikai reikia daugiau nei galimybės paprastai sąveikauti, naudojant standartinius protokolus. Web

servisų technologija kaip įkomponavimo platforma įgyja pilną potencialą tik tuomet, kai programos bei verslo procesai gali integruoti sudėtingas sąveikas, naudodami standartizuotą procesų sujungimo modelį. WSDL teikiamas sąveikos modelis iš esmės yra būsenų neišsaugančių (stateless) sinchroninių ar nesusijusių asinchroninių sąveikų modelis. Verslo procesų sąveikos modeliai reikalauja sinchroninių bei asinchroninių pranešimų apsikeitimo, išsaugant būseną ilgai trunkančiose sąveikose, apimančiose du ar kelis partnerius. Tokių sąveikų apibrėžimui reikalingas formalus pranešimų apsikeitimo protokolo apibrėžimas. Tokių verslo protokolų apibrėžimas apima tikslias visiems proceso dalyviams matomų pranešimų apsikeitimų specifikacijas, neatskleidžiančias jų vidinio realizavimo.

Business Process Execution Language For Web Services – BPEL4WS (sutrumpintai BPEL) suteikia galimybę specifikuoti verslo procesus ir jų sąsają su Web servisais. Ši kalba jungia ankstesnes IBM Web Services Flow

– 32 –

Elektroninio verslo procesų modeliavimo ir tinklo paslaugų kūrimo metodika

Language – WSFL bei Microsoft XLANG specifikacijas į bendrą standartą, kurio tikslas yra tapti visuotinu Web servisų komponavimo standartu.

Vidinio (privataus) procesų realizavimo atskyrimas nuo viešos proceso elgsenos aprašo turi dvi priežastis. Pirmoji yra akivaizdi, jog nėra norima verslo partneriams atskleisti vidinių sprendimų priėmimo bei duomenų tvarkymo aspektų. Kita priežastis yra ta, jog atskirta privačių procesų realizacija gali laisvai kisti, neįtakodama paties verslo protokolo.

BPEL4WS naudoja pranešimų savybių notaciją identifikuoti su pačiu protokolu susijusią informaciją. Savybės gali būti traktuojamos kaip „skaidrūs“ duomenys, kurie siejasi su viešaisiais protokolo aspektais, priešingai nei „nematomi“ duomenys, naudojami vidinėse/privačiose funkcijose. Skaidrūs duomenys veikia viešą verslo protokolą tiesiogiai, o nematomi duomenys pirma apdorojami vidinėse „back-end“ sistemose ir jų įtaka verslo protokolui neapibrėžiama, kadangi sprendimų priėmimo būdas yra neatskleidžiamas. Iš esmės protokolo vykdymą įtakojantys duomenys turi būti skaidrūs, t.y. traktuojami kaip savybės. Pavyzdžiui, užsakymo protokole pardavėjas turi servisą, kuris priima užsakymą ir siunčia sutikimą ar nesutikimą jį vykdyti priklausomai nuo įvairių kriterijų (prekių buvimo sandėlyje, pasitikėjimo pirkėju). Žinoma, sprendimo priėmimo procesas yra nematomas, tačiau viešame verslo protokole sprendimo faktas turi būti atvaizduotas kaip elgsenos alternatyvos. Kitaip tariant, protokolas turi turėti pasirinkimo veiksmą pardavėjo serviso elgsenoje, tačiau kaip pasirenkama, lieka neapibrėžta. Tokį neapibrėžtumą galima modeliuoti, leidžiant priskirti nematomus duomenis pranešimo savybei, dažniausiai iš išvardintų galimų variantų aibės. Savybė tuomet gali būti panaudota apibrėžiant sąlyginį elgesį, apimantį elgsenos alternatyvas, neatskleidžiančias paties sprendimo priėmimo proceso. BPEL4WS leidžia parodyti viešą elgseną ir paslėpti privačius aspektus, naudojant neapibrėžtus duomenis.

Pagrindinės BPEL4WS sąvokos pritaikomos dviem būdais. Naudojant abstraktaus proceso notaciją, BPEL4WS procesas gali apibrėžti verslo protokolo rolę. Pavyzdžiui, tiekimo grandinės protokole pirkėjas ir pardavėjas yra dvi atskiros rolės, kiekviena su savais abstrakčiais procesais. Ryšys tarp šių rolių modeliuojamas kaip serviso sąsaja (service link). Abstraktūs procesai apdoroja tik su protokolu susijusius duomenis. BPEL4WS teikiamas su protokolu susijusių duomenų identifikavimo būdas yra pranešimų savybės (message properties). Abstraktūs procesai naudoja neapibrėžtus duomenis tam, kad paslėpti privačius elgsenos aspektus.

BPEL4WS taip pat leidžia apibrėžti vykdomąjį verslo procesą (executable business process). Proceso logika bei būsena nustato Web servisų vykdymo seką. Taip apibrėžti procesai nuosekliai vykdomi nepriklausomai nuo platformos, patį procesą realizuoja programavimo kalba skirtinguose sąveikaujančiuose partnerių Web servisuose. BPEL4WS duoda modelį ir sintaksę apibrėžti verslo procesų elgsenai, paremtai sąveika tarp partnerių ir paties proceso. Sąveika su kiekvienu partneriu vyksta per Web servisų interfeisus, o ryšio tarp partnerių struktūra apibrėžiama servisų sąsajomis (service link). BPEL4WS taip pat apibrėžia, kaip suderinti sudėtines sąveikas, logiką bei būsenas, būtinas tokiam suderinimui. Taip pat yra nustatytas mechanizmas apibrėžti išimtinėms situacijoms bei klaidų apdorojimui, ir kas svarbiausia, yra nustatytas mechanizmas apibrėžti kaip kompensuoti įvykdytus veiksmus, kurių vykdymo metu buvo klaidos ar išimtinės situacijos.

BPL4WS sluoksnis yra aukščiau kitų XML specifikacijų: WSDL, XML Schema bei XPath. WSDL pranešimų ir XML Schema tipų apibrėžimai sudaro duomenų modelį, kurį naudoja BPEL4WS procesai. XPath naudojamas duomenų manipuliavimui. Visi išoriniai resursai bei partneriai yra vaizduojami kaip WSDL servisai.

2.2. BPEL4WS struktūra

BPL4WS susideda iš dviejų pagrindinių dalių: WSDL pranešimų ir XML Schema tipų apibrėžimų bei paties proceso apibrėžimo. BPL4WS naudoja tik dalį WSDL specifikacijos duomenims apibrėžti: kokie pranešimai bus siunčiami, kokios operacijos bus vykdomos ir kokiems portų tipams priklauso tos operacijos. Tokiu būdu BPL4WS procesas tampa Web servisu. 1 pav. pavaizduota BPEL4WS naudojama WSDL struktūros dalis.

BPL4WS WSDL apibrėžimas yra išplečiamas serviso ryšiu (service link). Serviso ryšio tipas apibūdina ryšį tarp dviejų servisų apibrėžiant roles, kurios dalyvauja servisų sąveikoje bei nurodo tų rolių portų tipus. Užsakymų priėmimui naudojamas serviso ryšys:

<slnk:serviceLinkType name="PirkimoUzsakymoProcesas:Saskaita"> <slnk:role name="SaskaitosServisas"> <slnk:portType name="Uzsakymas:KainosSkaiciavimas"/> </slnk:role> <slnk:role name="SaskaitosUzklausimas"> <slnk:portType name="Uzsakymas:SaskaitosAtsakymas"/> </slnk:role> </slnk:serviceLinkType>

– 33 –

L. Nemuraitė, A. Oželis

Nurodžius vieną rolę serviso ryšio apibrėžime, reiškia, kad servisas gali turėti ryšį su bet kokiu kitu servisu. Taigi XML Schema tipai, WSDL pranešimai (messages), operacijos, portų tipai bei servisų ryšiai apibrėžia proceso duomenis ir užrašomi į *.wsdl failą.

BPEL4WS naudojami WSDL elementai

1 pav. BPEL4WS naudojami WSDL struktūros elementai

1.1 BPEL4WSspecifikacijoje pakeista įVariable

2 pav. BPEL4WS proceso komponentai

– 34 –


2.3. BPEL4WS proceso sudėtis

Surašius visus proceso reikalavimus į *.wsdl failą toliau kuriamas pats procesas. Proceso apibrėžimas rašomas <process> elemente. Po to dažniausiai seka WSDL bei XML Schemų importavimas. BPEL4WS proceso komponentai pavaizduoti 2 paveiksle.

Sekančiu žingsniu apibrėžiami proceso dalyviai. Kiekvienas partneris apibūdinamas nurodant serviso ryšio tipą. Svarbu atkreipti dėmesį į myRole/partnerRole atributą. Šis atributas nurodo, kaip sąveikauja partneris su procesu per nurodytą serviso ryšio tipą. myRole nurodo, kokią serviso ryšio rolę atliks procesas, o partnerRole – atitinkamo partnerio rolę. Be to, BPEL4WS partnerių kiekis nebūtinai turi atitikti realų partnerių skaičių, jis gali būti didesnis, kai partneris atlieka keletą funkcijų, jis skaidomas į keletą partnerių. Užsakymo vykdymo BPEL4WS proceso apraše partneriai pavaizduoti 3 paveiksle.

<partners>

<partner name="Klientas" xmlns:ns1="http://localhost/Tiekejas/PirkimoUzsakymoProcesas/" serviceLinkType="ns1:Uzsakymas" myRole="UzsakymoServisas"/>

<partner name="SaskaitosSiuntimas" xmlns:ns2="http://localhost/Tiekejas/PirkimoUzsakymoProcesas/" serviceLinkType="ns2:saskaita" myRole="SaskaitosUzklausimas" partnerRole="SaskaitosServisas"/>

<partner name="pristatymoSiuntimas" xmlns:ns3="http://localhost/Tiekejas/PirkimoUzsakymoProcesas/" serviceLinkType="ns3:Pristatymas" myRole="pristatymoUzklausimas" partnerRole="Pristatymas"/>

<partner name="grafikoSiuntimas" xmlns:ns4="http://localhost/Tiekejas/PirkimoUzsakymoProcesas/" serviceLinkType="ns4:Grafikas" partnerRole="Grafikas"/>

</partners>

<partners>

3 pav. Proceso partnerių BPEL aprašas

Apibrėžus partnerius, toliau galima aprašyti proceso veiklas (activities): <receive>, <reply>, <invoke>, <assign>, <throw>, <terminate>, <wait>, <empty>, <sequence>, <switch>, <while>, <pick>, <flow>, <scope>, <compensate>. 4 paveiksle pavaizduoti veiklų tipai bei struktūra.

Procesas gali turėti tik vieną veiklą, o veiklos gali susidėti iš kitų veiklų. „sequence” veikla reiškia, kad šiame elemente išvardintos veiklos bus vykdomos nuosekliai. Procesas

dažniausiai turi „sequence” veiklą ir joje išvardinamos kitos veiklos. Sąveikai su kitais Web servisais ir BPEL4WS procesu naudojamos trys veiklos: „receive“, „invoke“ ir „reply“.

Jos yra pagrindinės BPEL4WS veiklos. Kiekvienai veiklai nurodžius porto tipą, operaciją bei partnerį, apibrėžiamas konkretus kreipimasis į Web servisą. „invoke“ veikla naudojama, kai procesas kreipiasi į kitus Web servisus ir papildomai reikia nurodyti įėjimo bei išėjimo kintamuosius (variable, 1,0 versijoje container), kurie yra kviečiamos operacijos įėjimo-išėjimo parametrai. Kreipimasis gali būti sinchroninis ar asinchroninis.

Verslo procesas savo paslaugas teikia per „receive“ ir „reply“ veiklas. „receive“ atitinka tam tikros WSDL operacijos įėjimo parametrus. Jei šis kvietimas reikalauja atsakymo, būtina sukurti „reply“ veiklą, kuri atitinka proceso išėjimo parametrus.

Duomenų manipuliacijos vyksta „assign“ veikloje, kurioje galima kopijuoti duomenis iš vieno kintamojo į kitą, taip pat įterpti ar konstruoti duomenis naudojant XPath išraiškas. Kintamojo savybes galima gauti parašius šią išraišką:

bpws:getVariableProperty ('variableName', 'propertyName')

Šių bazinių veiklų vykdymo eigą kontroliuoja struktūrinės veiklos, kurios apibūdina proceso struktūrą komponuojant bazines veiklas į struktūras, atitinkančias valdymo šablonus, duomenų srautus, klaidų gaudymą, pranešimų koordinavimą tarp protokolo procesų.

„sequence“ veikloje esančios veiklos vykdomos nuosekliai tokia tvarka, kokia jos yra surašytos. „switch“ veikla atitinka tradicinių programavimo kalbų „switch“ išraišką, kai vykdymui iš veiklų sąrašo

parenkama viena veikla, atitinkanti <case> elemente nurodytą XPath išraiškos sąlygą. „while“ veikla atlieka veiklas tol, kol įvykdoma XPath nurodyta sąlyga. „pick“ veikla sudaryta iš įvykių apdorojimo elementų (event handlers), kurių kiekvienas turi po vieną veiklą.

Įvykus kuriam nors įvykiui, bus vykdoma atitinkama veikla. „scope“ veikla grupuoja joje esančias veiklas į tam tikrus loginius vienetus, kurie atitinkamai reaguoja į klaidas. „flow“ yra viena iš sudėtingesnių veiklų, naudojama lygiagrečiam veiklų vykdymui kontroliuoti. Kiekvienai

veiklai sukuriami ryšiai su kitomis veiklomis, ant kurių galima užrašyti vykdymo sąlygas XPath išraiška (guard condition).

– 35 –


Container 1.1 BPEL4WSspecifikacijoje pakeista įVariable

4 pav. BPEL4WS veiklų tipai ir struktūra

3. BPEL4WS procesų vaizdavimas UML

Automatizuoto verslo proceso sąvoka naudojama, turint omenyje laisvai susietų programinės įrangos kompo-nentų sąveiką, realizuojančią santykinai ilgai trunkančias verslo užduotis. BPEL4WS kalba skirta automatizuotiems verslo procesams ir jų vykdymo semantikai apibrėžti. Ji naudoja XML žymėjimus.

Verslo analitikams labiau prieinamos ir suprantamos yra aukštesnio konceptualiojo lygio kalbos, pavyzdžiui, UML. Todėl šiame darbe buvo nagrinėjama, kaip atvaizduoti BPEL ir Web servisais realizuojamus daugelio partnerių procesus UML modeliais. Nagrinėjamas vykdomasis (executable) automatizuoto verslo proceso pavyzdys yra pirkimo užsakymo vykdymo procesas. Šis procesas, gavęs pirkimo užsakymą iš pirkėjo-tarpininko, sukuria tris lygiagrečias veiksmų sekas, kurios vykdomos pas skirtingus verslo partnerius: galutinės kainos skaičiavimas, kurjerio parinkimas bei užsakymo įvykdymo ir pristatymo planavimas. Kai visos šios užduotys baigtos, siunčiama sąskaita pirkėjui.

3.1. Modelių struktūrizavimas

UML modeliai struktūrizuojami į paketus. UML paketai atitinka BPEL vardų erdves ar atitinkamus pakartotino panaudojimo vienetus. Paketai sugrupuoja tam tikrus komponentus suteikdami jiems bendrą vardų erdvę. Priklau-somybės tarp paketų vaizduojamos <<import>> tipo priklausomybėmis.

Modelio paketų hierarchija atitinka XML vardų laukų hierarchiją. Modelio vardas atitinka aukščiausio paketo vardą ir atitinkamai aukščiausio lygmens paketo vardą. Generuojant kodą iš modelio, tiems paketams, kurie siejasi su XSD ar WSDL elementais, sukuriami atitinkami failai. Protokolų paketams nauji failai nekuriami, o informacija talpinama WSDL faile, atitinkančiame viršutinį paketą. BPEL procesas rašomas į atskirą failą. 5 paveiksle pavaiz-duota nagrinėjamo proceso paketų hierarchija. Paketas „Uzsakymas“ bus sugeneruotas į failą Uzsakymas.wsdl, o „UzsakymoProcesas“ atitinka vardų lauko pavadinimą faile PirkimoUzsakymas.bpel.

– 36 –


«external»UzsakymoDuomenuTipai

Uzsakymas

UzsakymoProcesas

«import»

«import»

5 pav. Užsakymo proceso modelio paketų hierarchija

6 paveiksle pavaizduotas sugeneruoto Uzsakymas.wsdl failo fragmentas, iliustruojantis <<import>> priklauso-mybės tarp paketų realizavimą į vardų laukų importavimą.

<wsdl:definitions

targetNamespace="http://localhost/Tiekejas/PirkimoUzsakymoProcesas/Uzsakymas/"

xmlns:Uzsakymas="http://localhost/Tiekejas/PirkimoUzsakymoProcesas/Uzsakymas/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"

xmlns:UzsakymoDuomenuTipai="http://localhost/Tiekejas/PirkimoUzsakymoProcesas/UzsakymoDuomenuTipai/">

<wsdl:import namespace="http://localhost/Tiekejas/PirkimoUzsakymoProcesas/UzsakymoDuomenuTipai/" location="http://localhost/Tiekejas/PirkimoUzsakymoProcesas/UzsakymoDuomenuTipai.wsdl"/>

...............

6 pav. WSDL vardų laukų deklaravimo fragmentas

Modelis gali būti priklausomas nuo elementų, kurie apibrėžiami už modelio ribų. Tokie elementai vadinami išoriniais. Išorinių paketų komponentai yra apibrėžiami kitame modelyje arba yra specifiniai nuo platformos priklausomi elementai. Išorinius paketus labai patogu naudoti vartotojo duomenų tipų sukūrimui. Nagrinėjamame procese išorinis paketas „UzsakymoDuomenuTipai“ turi stereotipą <<external>>, reiškiantį, kad paketo elementai apibrėžti ne modelyje. Šiuo atveju generuojamas UzsakymoDuomenuTipai.xsd failas su reikalingų tipų vardais, o jų apibrėžimas paliekamas vartotojui. Tai suteikia modeliui lankstumo. Užsakymo proceso duomenų tipų deklaracijos pavaizduotos 7 paveiksle.

<?xml version="1.0"?>

<xsd:schema

targetNamespace="http://localhost/Tiekejas/PirkimoUzsakymoProcesas/UzsakymoDuomenuTipai/"

xmlns:UzsakymoDuomenuTipai="http://localhost/Tiekejas/PirkimoUzsakymoProcesas/UzsakymoDuomenuTipai/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<xsd:complexType name="PirkimoUzsakymas"/>

<xsd:element name="PirkimoUzsakymas" type=" UzsakymoDuomenuTipai:PirkimoUzsakymas"/>

<xsd:complexType name="KlientoInfo"/>

<xsd:element name="KlientoInfo" type=" UzsakymoDuomenuTipai:KlientoInfo"/>

<xsd:complexType name="PristatymoInfo"/>

<xsd:element name=" PristatymoInfo " type=" UzsakymoDuomenuTipai: PristatymoInfo "/>

<xsd:complexType name="Saskaita"/>

<xsd:element name=" Saskaita " type="UzsakymoDuomenuTipai: Saskaita "/>

<xsd:complexType name="GrafikoInfo"/>

<xsd:element name=" GrafikoInfo " type="UzsakymoDuomenuTipai: GrafikoInfo "/>

</xsd:schema>

7 pav. „UzsakymoDuomenuTipai“ tipų deklaracijos

– 37 –


3.2. Web servisų vaizdavimas Automatizuotų verslo procesų sritis remiasi Web servisų srities koncepcijomis bei infrastruktūra. Esminis

automatizuotų procesų koncepcijos elementas yra tiesioginis (peer-to-peer) komunikavimas tarp Web servisų, kur ir procesas ir partneriai yra apibrėžti kaip atitinkami Web servisai.

Web servisų terminologijoje portų tipai apibrėžia susijusių operacijų aibę. Portų tipai UML diagramose vaizduojami kaip interfeisai. Operacijoms perduodami parametrai, kurių tipą nusako atitinkamo pranešimo tipas. Pranešimo tipas savo ruožtu turi kelias dalis, kurių tipas apibrėžtas duomenų tipu. Duomenų tipai modeliuojami kaip klasės su stereotipu <<data>>; pranešimų tipai modeliuojami kaip klasės su stereotipu <<messageContent>>. Pranešimų tipų modeliuoti nebūtina, jei jie susideda tik iš vienos dalies, tuomet tiesiog naudojamas duomenų tipas. Duomenų tipus derėtų kurti tik tuomet, kai jie prasmingai sugrupuoja keletą atributų ir naudojami ne tik vienoje operacijoje. Pranešimų tipus pravartu kurti, kai grupavimas turi prasmę tik operacijos kontekste. <<data>> klasių atributų tipai gali būti baziniai arba sukurti vartotojo. 8 pav. pavaizduoti nagrinėjamo proceso duomenų tipai, kurių atributai yra bazinių tipų. „Uzsk“ pranešimo tipas sudarytas iš dviejų vartotojo apibrėžtų dalių. <<data>> klasių atributai tiesiogiai siejami su XSD schemų atributais.

«external» UzsakymoDuomenuTipai

Uzsakymas

«messageContent» Uzsk

«data»PirkimoUzsakymas

+ pirkimoUzsakymas

«data» KlientoInfo

+ klientoInfo

«data» Saskaita

«data» UzsakymoKlaidosTipas

«data»Grafikas

«data» PristatymoInfo

«data» PristatymoUzklausimas

«import»

8 pav. Užsakymo proceso duomenų tipai

9 paveiksle pavaizduoti pranešimų tipų WSDL aprašai gauti generuojant kodą iš modelio.

<wsdl:message name="Uzsk">

<wsdl:part name="pirkimoUzsakymas" type="UzsakymoDuomenuTipai:PirkimoUzsakymas"/>

<wsdl:part name="klientoInfo" type="UzsakymoDuomenuTipai:KlientoInfo"/>

</wsdl:message>

<wsdl:message name="PristatymoInfo">

<wsdl:part name="part" type=" UzsakymoDuomenuTipai:PristatymoInfo"/>

</wsdl:message>

9 pav. WSDL operacijų pranešimų fragmentas

Kiekvienas paketas, turintis interfeisų, yra susiejamas su atskiru WSDL dokumentu. Kiekvienas paketo inter-feisas yra susiejamas su WSDL porto tipu atitinkamame WSDL dokumente. Kiekviena klasė su <<data>> stereotipu yra susiejama su XSD tipu, o kiekviena <<messageContent>> klasė siejama su WSDL pranešimo tipu. WSDL draudžia tiesiogiai naudoti XSD tipus kaip operacijų parametrus. Tam tikslui yra sugeneruojami pranešimų tipai su

– 38 –


viena dalimi iš tų <<data>> klasių, kurios yra panaudotos kaip operacijų parametrai. Tačiau jei reikalingas skirtingas tipų panaudojimas, būtina sukurti skirtingus pranešimus, nes bus generuojamas tik vienas pranešimo tipas.

Procesas dalyvauja protokole per kiekvieną iš savo portų. Protokolas susieja porą rolių ir vaizduoja jų sąveiką. Kiekviena rolė gali turėti kelis interfeisus reikalingus kitai rolei. 8 pav. pavaizduota UML klasių diagrama, vaizduojanti proceso duomenų tipus, išreikštus UML klasėmis, kurios yra naudojamos kaip operacijų parametrų tipai. Operacijas turi arba jos yra iškviečiamos per rolių interfeisus.

Užsakymo pakete taip pat yra ir užsakymo procesui reikalingi ar jo teikiami interfeisai, jie pavaizduoti 10 pav.

«interface»KainosSkaiciav imas

pradetiKianosSkaiciavima ( [in] uzsk : Uzsk )siustiPristatymoKaina ( [in] pristatymoInfo : PristatymoInfo )

«interface»PristatymoAtsakymas

siustiGrafika ( [in] grafikas : Grafikas )

«interface»PirkimoUzsakymas

siustiPirkimoUzsakyma ( [in] uzsk : Uzsk ) : Saskaita

«interface»SakaitosAtsakymas

siustiSaskaita ( [in] saskaita : Saskaita )

«interface»Pristatymas

uzklaustiPristatymo ( [in] pristatymoUzklausimas : PristatymoUzklausimas ) : PristatymoInfo

«interface»Grafikas

uzklaustiGamybosPlanavima ( [in] pristatymoInfo : PristatymoInfo )siustiPristatymoGrafika ( [in] grafikas : Grafikas )

10 pav. Užsakymo proceso naudojami interfeisai

11 paveiksle Iš „Uzsakymas“ paketo atitinkamai sugeneruotame Uzsakymas.wsdl faile bus sukurti tokie portų tipai, atitinkantys pavaizduotus interfeisus su jų operacijomis:

<wsdl:portType name="KainosSkaiciavimas">

<wsdl:operation name="pradetiKainosSkaiciavima">

<wsdl:input name="input" message="UzsakymoDuomenuTipai:Uzsk"/>

</wsdl:operation>

<wsdl:operation name="siustiPristatymoKaina">

<wsdl:input name="input" message="UzsakymoDuomenuTipai:PristatymoInfo"/>

</wsdl:operation>

</wsdl:portType>

<wsdl:portType name="SaskaitosAtsakymas">

<wsdl:operation name="siustiSaskaita">

<wsdl:input name="input" message="UzsakymoDuomenuTipai:Saskaita"/>

</wsdl:operation>

</wsdl:portType>

11 pav. „Uzsakymas“ paketo WSDL fragmentas

12 paveiksle pavaizduoti protokolai, kuriuose pirkimo užsakymo procesas atliks tam tikras roles ir sąveikaus su partneriais, atliekančiais savas atitinkamas roles. Užsakymo proceso atliekamos rolės pavaizduotos kairiau. Kiekvienas protokolas atitinka paketo „Uzsakymas“ atitinkamą subpaketą, į kurį talpinamos protokolo rolės. Paketas „Uzsakymas“ apima ir protokolų naudojamas klases bei interfeisus.

Protokolai „Uzsakymas“ bei „Grafikas“ turi tik po vieną rolę teikiančią interfeisą, kita rolė apibūdina serviso užklausą. Protokolas „Saskaita“ turi „SaskaitosServisas“ rolę, kuri teikia „KainosSkaiciavimas“ interfeisą ir

– 39 –


reikalauja, kad sąveikaujanti rolė teiktų „SaskaitosAtsakymas“ interfeisą, būtiną asinchroniniam atsakymo pranešimui nusiųsti. Analogiška situacija protokole „Pristatymas“.

«protocol»Pristatymas

«protocol»Grafikas

«protocol»Saskaita

«protocol»Uzsakymas

KainosSkaiciav imas

SakaitosAtsakymas

PirkimoUzsakymas

Pristatymas

«role»GrafikoServ isas

«role»UzsakymoServ isas

«role»SaskaitosUzklausimas

«role»SaskaitosServ isas

«role»PristatymoServ isas

«role»PristatymoUzklausimas

Grafikas

«role»UzsakymoUzklausimas

«role»GrafikoUzklausimas

PristatymoAtsakymas «use»

«use»

«use»

«use»

«use»

«use»

12 pav. Pirkimo užsakymo protokolai bei rolės

saskaitosUzklausimas : «role» saskaitosSiuntimas : «role»

1 : pradetiKianosSkaiciavima ( uzsk )

2 : siustiPristatymoKaina ( pristatymoInfo )

3 : siustiSaskaita ( saskaita )

Kainos skaiciavimas gali buti pradetas kuomet uzsakymo deteles yra

Pristatymo kaina reikalinga skaiciavimo

Kai kainos skaiciavimas baigtas, siunciamasasinchroninis atsakymas

13 pav. Protokolo „Saskaita“ pranešimų sekų diagrama

Taigi ryšiui tarp verslo proceso ir partnerio realizuoti gali prireikti vienpusio ar abipusio pranešimų siuntimo. Protokolas susieja dvi viena kitą papildančias roles ir specifikuoja interfeisus, kuriuos teikia ar reikalauja kiekvieną rolė. Rolių struktūros modeliavimas nėra būtinas, tačiau dėl aiškumo kartais naudinga pavaizduoti teisingas pranešimų sekas. Sąveikų diagramos puikiai tinka tokiam atvaizdavimui. 13 paveiksle pavaizduota sekų diagrama,

– 40 –


detalizuojanti „Saskaita“ protokolą. Šiuo atveju tėra viena teisinga pranešimų seka, todėl vienos diagramos pakanka. Analogiška pranešimų seka vykdoma protokole „Pristatymas“.

Kiekvienas protokolo paketas UML modelyje susiejamas su BPEL serviso ryšio tipu. Protokolo rolės tampa serviso ryšio tipo rolėmis, o jų interfeisai tampa serviso ryšio tipo rolių portų tipais. 14 pav. pavaizduoti sugeneruoti servisų ryšio tipai

<slnk:serviceLinkType name="PirkimoUzsakymoProcesas:Saskaita">

<slnk:role name="SaskaitosServisas">

<slnk:portType name="Uzsakymas:KainosSkaiciavimas"/>

</slnk:role>

<slnk:role name="SaskaitosUzklausimas">

<slnk:portType name="Uzsakymas:SaskaitosAtsakymas"/>

</slnk:role>

</slnk:serviceLinkType>

14 pav. Užsakymo proceso servisų ryšių tipų fragmentas

3.3. Procesų vaizdavimas

Automatizuotas biznio procesas apibūdina kelių partnerių atliekamas su verslu susijusias užduotis. Procesas išlaiko būseną sąveikaudamas su keliais partneriais per apibrėžtus protokolus. Procesas gali sąveikauti per kelis protokolus su skirtingais partneriais, bei per tą patį protokolą su keliais partneriais.

15 pav. vaizduoja klasę „PirkimoUzsakymoProcesas“ su stereotipu <<process>>. Ši klasė atvaizduoja pirkimo užsakymo procesą. Procesas turi keturis portus, kurie apibrėžti ankstesniuose modeliuose. Portai atitinka keturis partnerius su kuriais sąveikauja procesas. Kiekvienas portas yra atitinkamo partnerio ryšio taškas su procesu. Per portą teikiami ar reikalaujami interfeisai yra apibrėžiami role, kurią procesas vykdo protokole. Portas vaizduojamas agregavimo ryšiu su stereotipu <<port>> nukreiptu į rolę, kurią vykdo procesas. Proceso būsena atvaizduota kaip „PirkimoUzsakymoProcesas“ klasės atributai, kurių tipai nurodyti pakete „Uzsakymas“ ar importuoti iš paketo „UzsakymoDuomenuTipai“.

UzsakymoProcesas

«Process»PirkimoUzsakymoProcesas

Uzsk : UzskpristatymoInfo : PristatymoInfopristatymoUzklausimas : PristatymoUzklausimaspristatymoGrafikas : PristatymoGrafikassaskaita : Saskaita

«role»Uzsakymas::UzsakymoServ isas

«role»Saskaita::SaskaitosUzklausimas

«role»Pristatymas::PristatymoUzklausimas

«role»Grafikas::GrafikoUzklausimas

+ saskaitosSiuntimas«port»

+ pristatymoSiuntimas«port»

+ grafikoSiuntimas«port»

Uzsakymas

+ klientas

«port»

«import»

15 pav. Užsakymo proceso struktūrinis modelis

– 41 –


16 paveiksle pavaizduota užsakymo proceso UML veiklos diagrama vaizduoja nagrinėjamo BPEL proceso portus, atitinkančius veiklos diagramos juostas (angl. swimlane). Veiklos, kurios apima pranešimų siuntimą ar gavimą partnerių Web servisams per kurį nors iš 4 portų (klientas, saskaitosSiuntimas, pristatymoSiuntimas, grafikoSiuntimas) yra pavaizduotos atitinkamoje porto juostoje. Rodyklės vaizduoja proceso veiklų vykdymo seką.

klientas «receive» gautiUzsk

«reply» grazintiSaskaita

sakaitosSiuntima

«invoke» pradetiKainosSkaiciavima

«invoke» siustiPristatymoKaina

«receive» gautiSaskaita

pristatymoSiuntimas

«invoke»uzklaustiPristatymo

«receive»gautiGrafika

grafikoSiuntimas «invoke»

uzklaustiGrafiko

«invoke» siustiPristatymoGrafika

«assign»pradetiPristatymoUzklausima

16 pav. Užsakymo vykdymo proceso UML veiklų diagrama

4. Automatizuotų procesų modeliavimo UML metodika

Automatizuotų procesų modeliavimo UML metodika pavaizduota 17 paveiksle.

BPEL proceso, bei WSDL failu uzkrovimas i BPEL4WS

varikliuka

Strukturiniu proceso WSDL failu papildymas fizine realizuotu web servisu

informacija

realizavimasWeb servisu

kurimasXML Schemu

Programuotojas

Veiklos dalyviu identifikavimas

Veiklos procesu identifikavimas

Verslo esybiu identifikavimas

Verslo analitikas

modeliavimasProceso eigos

modeliavimasstrukturos Proceso

projektavimasvienetu

Proceso duomenu

Sistemos architektas

17 pav. Automatizuotų procesų modeliavimo UML metodika

– 42 –


5. Išvados

Darbe analizuojama Web servisų komponavimo į automatizuotus verslo procesus problema, kurios sprendimas padėtų išnaudoti naujausių interneto technologijų potencialą ir paversti internetą globalia bendrai vykdomo verslo platforma. Analizuojama nauja BPES4WS kalba, kuri šiuo metu turi didžiausias perspektyvas Web servisų komponavimui, nes apima kelių ankstesnių kalbų savybes, o už labiausiai išvystytą ebXML standartą ji pranašesnė tuo, kad bendro verslo automatizavimui nereikalauja tiek daug standartų ir papildomų išteklių.

Išanalizuota BPEL4WS specifikacija bei vykdomų procesų modeliavimas su BPWS4J moduliu IBM Eclipse platformoje. Nors ši kalba turi dideles perspektyvas, į ją gilinasi programuotojai, mėgstantys naujoves, arba teoretikai. Kol kas nėra sukauptos jos naudojimo patirties nei taikymo metodikos, nėra praktinių pavyzdžių. Skirtingai nuo darbų sekų tipo procesų modeliavimo priemonių, ši kalba nėra intuityviai suprantama. Norint padaryti šią kalbą prieinamesnę analitikams, programuotojams ir projektuotojams, išnagrinėtos BPEL4WS procesų modeliavimo galimybės standartine UML kalba bei Rational Rose paketu ir sudaryta tam skirta metodika.

Sukūrus tam tikslui programines priemones, iš sudarytų verslo proceso modelių BPEL4WS scenarijus būtų galima generuoti automatiškai. Šiame darbe UML modeliai buvo panaudoti tradiciškai kaip gairės programuotojui. Buvo realizuotas eksperimentinis trijų dalyvių verslo procesas, kuris veikia BPWS4J varikliuke. Web servisai realizuoti Microsoft .NET platformoje ir ištestuoti tam sukurtu trasavimo mechanizmu.

BPEL4WS kalba ir modeliavimo įrankiai turėtų būti toliau tobulinami ir plečiami. Reikalinga vieninga proceso elementų notacija, nes vien UML stereotipai modelius daro painiais, o įvairių paketų (BizTalk, Collaxa, IBM Web Sphere) notacijas reikia suprasti kiekvieną atskirai. Būtina tobulinti ir modeliavimo aukštesniame lygyje metodiką, padaryti ją intuityviau suprantamą, užtikrinti modelio teisingumo tikrinimo galimybes. Didieji programinės įrangos gamintojai rodo didelį susidomėjimą, tačiau realiai veikiančių produktų kol kas nėra, todėl rinka vis dar atvira BPEL4WS modeliavimo produktams, procesų vykdymo varikliukams ar serveriams.

Būtų galima išvardinti tokius BPEL4WS privalumus: gryna sąveikaujančių Web servisų koncepcija: procesas yra Web servisas ir standartinėmis priemonėmis sąveikauja su kitais servisais; duomenų tipų ir jų struktūrų laisvas sudarymas, paveldėjimas bei atskyrimas nuo proceso, todėl vartotojas gali laisvai keisti duomenų tipus, nekeisdamas proceso struktūros, duomenų tipai apibrėžiami XML Schema; galimybė naudoti kaip programų integravimo priemonę; proceso aprašas „programuotojiško“ pobūdžio: WSDL, XPath, XSD; viskas aprašoma XML, todėl nereikalingos papildomos technologinės žinios ar programinė integravimo įranga; koordinuojamas asinchroninis komunikavimas tarp servisų, o tai labai svarbus aspektas Web servisų kompozicijoje, vykdant ilgai trunkančias veiklas, nes sinchroninis komunikavimas realaus pasaulio programose būtų neįmanomas.

Procesus galima modeliuoti naudojant standartinę UML ir gauti sugeneruotą BPEL scenarijų. Nėra būtinumo įsisavinti naujas modeliavimo aplinkas, pakanka suprasti BPEL4WS struktūrą ir specifinius UML išplėtimus. Galimas ilgai vykdomų transakcijų palaikymas: nors pati BPEL4WS specifikacija nepalaiko transakcijų, tačiau ją galima išplėsti WS-Transaction bei WS-Coordination specifikacijomis ir gauti šį būtiną automatizuotiems verslo procesams funkcionalumą. Sumodeliuotas procesas jau pateikia būtinus integravimo interfeisus, todėl sprendžiant partnerio integravimo problemas lieka tik sukurti Web servisą, realizuojantį reikalingus interfeisus. Nereikalauja didelės specializuotos kvalifikacijos – BPEL4WS sąlyginai paprasta lyginant su ebXML, kuris teikia daug abstrakčių procesų, duomenų tipų ir servisų šablonų bei specializuotų verslo konteksto procesų šablonų ir reikalauja gilaus ne tik pačios specifikacijos, bet ir šablonų bei duomenų tipų bibliotekų žinių. Pranešimų mainų koreliavimas tarp verslo partnerių leidžia sąveikauti su proceso egzemplioriumi, vykdant kelis procesus iš karto. Realizuojamas lygiagretus veiklų vykdymas – automatizuotiems verslo procesams vykdyti svarbu ne tik veiksmų vykdymo seka, bet ir jų vykdymas lygiagrečiai. Kartais kai kurios veiklos reikalauja duomenų iš kitų lygiagrečiai vykdomų veiklų – šią galimybę BPEL4WS taip pat palaiko. Klaidų apdorojimo mechanizmas – kadangi Web servisų kompozicija pagrįsti procesai yra priklausomi nuo keleto servisų, vykdomų pas skirtingus partnerius, yra didelė klaidų tikimybė, todėl gebėjimas jas apdoroti yra svarbus privalumas.

Galima išvardinti ir BPEL4WS trūkumus: sunku testuoti, nes modelio testavimas atliekamas tik vykdant visa procesą ir lyginant rezultatus su tikėtinais gauti duomenimis. Nėra trasavimo ir tarpinių duomenų stebėjimo galimybės, kadangi pati kalba neteikia šios galimybės. Nėra tiesioginio transakcijų palaikymo – norint vykdyti transakcijas, BPEL4WS scenarijų būtina papildyti WS-Transaction bei WS-Coordination specifikacijomis. Modeliavimo procesas nėra intuityvus nes partnerių išskyrimas, duomenų tipų ir paties proceso sudarymas reikalauja specifinio suvokimo. Sudėtingo proceso BPEL modelį darosi sunku suprasti. Nėra duomenų transformavimo specifikavimo.Nespecifikuojama žmogaus veiksmų seka. Nėra partnerių susitarimų ar derybų specifikavimo, kuris yra svarbus verslo procesuose

Įmonėms BPEL4WS suteikia sąveikavimo terpę su verslo partneriais vykdyti verslo procesus. Įmonių paslaugos gali būti ne tik publikuojamos internete Web servisų pagalba, bet ir dalyvauti automatizuotuose procesuose. Sistemų projektuotojams galimybė BPEL4WS modelius kurti standartinėmis priemonėmis bei programuotojams naudoti standartines technologijas leidžia nesunkiai įsisavinti šią kalbą, o didelis programinės įrangos rinkos lyderių susidomėjimas garantuoja visuotiną šios specifikacijos palaikymą bei paplitimą.

– 43 –


Literatūros sąrašas [1] Specifikacija. Business Process Execution Language for Web Services (BPEL4WS) 1.1 Prieiga per Internetą:

http://www-106.ibm.com/developerworks/webservices/library/ws-bpel/ [2] P. Brown. BPEL for Programmers and Architects [interaktyvus] 2003 [žiūrėta 2003 10 22]. Prieiga per Internetą:

http://blog.fivesight.com/prb/space/BPEL/BPEL4ProgArchies.pdf [3] M. Lehmann. BPEL: Business Processes with Web Services [interaktyvus]. 2003 10 02, [žiūrėta 2003 11 15]. Prieiga

per Internetą: http://blog.fivesight.com/prb/space/Other+sources+of+information+on+BPEL/Oracle_BPEL_08_13_03.pdf

[4] IBM Corp. Business processes with BPEL4WS: Learning BPEL4WS. Iš IBM, developerWorks [interaktyvus]. 2003, [žiūrėta 2003 12 22]. Prieiga per Internetą: http://www-106.ibm.com/developerworks/views/webservices/articles.jsp

[5] B. Darrow, E. Montalbano. IBM Exec Touts Need For BPEL Support, SOAs [interaktyvus]. 2003, [žiūrėta 2003 12 22]. Prieiga per Internetą: http://www.crn.com/sections/BreakingNews/dailyarchives.asp?ArticleID=44275

[6] M. C. Daconta, L. J. Obrst, K. T. Smith. The Semantic Web: A Guide to the Future of XML, Web Services, and Knowledge Management. – John Wiley & Sons, 2003. – 281 p.

[7] D. Kaye. Loosely Coupled: The Missing Pieces of Web Services. – RDS Press, 2003. – 334 p.

Method for E-Business Process Modelling and Development of Web Services

The Business Process Execution Language for Web Services (BPEL4WS) is an XML-based standard for defining how you can combine Web services to implement business processes. It builds upon the Web Services Definition Language (WSDL) and XML Schema Definition (XSD). A BPEL4WS process is defined in terms of its interactions with partners. A partner may provide services to the process, require services from the process, or participate in a two-way interaction with the process. Thus BPEL orchestrates Web Services by specifying the order in which it is meaningful to call a collection of services, and assigns responsibilities for each of the services to partners. You can use it to specify both the public interfaces for the partners and the description of the executable process. This article describes methodology how to define BPEL processes in the Unified Modeling Language (UML) and get the corresponding BPEL and WSDL files to implement that process. This capability is used to highlight some of the benefits of the Object Management Groups (OMGs) Model Driven Architecture (MDA) initiative: raising the level of abstraction at which development occurs, which, in turn, will deliver greater productivity, better quality, and insulation from underlying changes in technology.

– 44 –

http://www-106.ibm.com/developerworks/webservices/library/ws-bpel/

http://blog.fivesight.com/prb/space/BPEL/BPEL4ProgArchies.pdf

http://blog.fivesight.com/prb/space/Other+sources+of+information+on+BPEL/Oracle_BPEL_08_13_03.pdf

http://www-106.ibm.com/developerworks/views/webservices/articles.jsp

http://www.crn.com/sections/BreakingNews/dailyarchives.asp?ArticleID=44275

ŠABLONŲ NAUDOJIMAS KURIANT DUOMENŲ APDOROJIMO SISTEMAS INTERNETE

Ramunė Rutkauskaitė, Lina Nemuraitė Kauno technologijos universitetas, Informacijos sistemų katedra

Studentų 50-308

Straipsnyje analizuojami atvirojo kodo PHP programavimo technologijos privalumai ir trūkumai palyginus su kitomis interneto informacinių sistemų kūrimo priemonėmis. Nagrinėjamos galimybės PHP naudoti projektavimo šablonus. Sudarytas šablonų rinkinys, tinkamas kurti nesudėtingoms interneto informacinėms sistemoms, kuriose reikia atlikti duomenų apdorojimo operacijas, užtikrinti duomenų saugumą ir lankstų darbą skirtingas teises turintiems vartotojams. Šablonų rinkinys išbandytas įgyvendinant Miškų informacinės sistemos posistemio prototipą nutolusiems vartotojams ir galėtų būti naudojamas panašių sistemų kūrimui.

1. Įvadas

Tobulėjant interneto sistemoms, tapo įprasta naudoti dinaminius tinklo puslapius, kurie reaguoja į vartotojo įvestį. Serveryje veikiančių puslapių kūrimas - Active Server Pages (ASP) ir Java Server Pages (JSP) leidžia kūrėjams tiesiogiai įdėti tekstus į HTML puslapius, tokiu būdu suprastinant programavimo modelį. Sudėtingesniems įmontuotų tekstų taikymams atsirado poreikis atskirti veiklos logiką nuo pateikties logikos puslapių lygyje. Deja, nėra vienos kūrimo strategijos, kuri tiktų visoms situacijoms. Dėl programinės įrangos kūrimo priemonių konkurencijos atsirado būtinybė pašalinti perdėtą įvairovę ir sudėtingumą.

Galima apsiriboti paprastais puslapiais, į kuriuos įdedami skriptai, bet greitai veiklos logika pradeda kartotis ir sistemos palaikymas bei pratęsimas darosi sudėtingas. Šią pasikartojančią logiką galima iškelti į atskirą komponentą ir sudaryti bendradarbiaujančių komponentų rinkinius. Tai pašalintų pertekliškumą, bet padidėtų sprendimo sudėtingumas. Sudėtingumui valdyti įvairiose srityse, tame tarpe ir programavime, naudojami šablonai. Bendro naudojimo objektinio projektavimo šablonai aprašyti [6], kur pateikti 23 šablonai, bet jų yra ir daugiau. Pavyzdžiui, yra atskira šablonų grupė, taikoma interneto sistemų kūrimui.

Klasikinis interneto sistemoms taikomas šablonas yra Modelis/Vaizds/Valdiklis (angl. Model-View-Controller (MVC)). Tai senas modelis, kuris atlaikė laiko testą ir atskyrė pateikties logiką nuo veiklos logikos. Nors šis modelis nėra naujas, projektuotojui jo reikšmė yra labai didelė. Šiame darbe MVC nagrinėjamas projekto lygmenyje, o po to taikomas PHP kodui. Paprasčiausiu atveju vienam puslapiui skiriamas vienas valdiklis. Dar tolesnis patobulinimas yra priekinis (angl. Front Page) valdiklis. Naudojant šį šabloną, visos užklausos nukreipiamos vienam valdikliui, kuris dažnai būna sudarytas iš dviejų dalių. Pirma dalis yra prižiūrėtojas (angl. handler), o kita – komandos šablonų hierarchija. Priekinis valdiklis nukreipia užklausas į kitus valdiklius. Paprastai šis šablonas naudoja konfigūravimo failą, kuriame užklausoms priskiriami veiksmai, todėl jį lengva pakeisti. Priekinio valdiklio šablonas panašus į bendros paskirties fasado šabloną (angl. Facade). Filtro šablonas leidžia įgyvendinti standartinį užklausų apdorojimą: saugumo tikrinimą, registravimą, suspaudimą, kodavimą/dekodavimą. Paprastai vienas filtras atlieka vieną užduotį. Jei reikia atlikti kelias užduotis, filtrai jungiami į grandines. Pavienis objektas (angl. singleton) yra projektavimo šablonas, naudojamas kai reikia sukurti vieną objektą, kuris būtų prieinamas skirtingoms programos dalims. Jei tas objektas apima didelius informacijos kiekius, daugelio objektų keitimas atskirose dalyse būtų labai neproduktyvus. Antra priežastis, kodėl naudojamas pavienis objektas, yra ta, kad reikia užtikrinti, kad tas objektas bus vienodas visoms programos dalims, kad jis atsitiktinai nebus modifikuotas ar ištrintas. Pavyzdžiui, konfigūravimo failas. Prieigai prie duomenų sukuriamas duomenų prieigos šablonas (angl. Data access object), kuris atlieka priėjimą prie duomenų bazės, skaitymą, rašymą.

2. Interneto technologijos ir PHP

HTML (HyperText Markup Language) – tai WWW puslapių aprašymo kalba, kuria kalba pasaulinio tinklo World Wide Web (WWW) serveriai ir kurią supranta tinklo naršyklės. Interneto, kuris atsirado dar šaltojo karo įkarštyje, dabar negalima įsivaizduoti be spalvingų WWW puslapių. HTML - tai vienas iš SGLM (Structured Generalized Markup Language) kalbos variantų. Pastarasis dokumentų struktūros aprašymo būdas buvo sukurtas dar 1980-1984 metais ir patvirtintas ISO 8779 standartu. SGLM kalba vartojama pavyzdžiui siekiant standartizuoti didelių tarptautinių organizacijų raštvedybą ir tarpusavio susirašinėjimą. Interneto standartu tapusi HTML - tai ne programavimo kalba ir ne griežtas dokumento formatas. HTML visų pirma aprašo loginę WWW puslapių struktūrą:

– 45 –

R. Rutkauskaitė, L. Nemuraitė

dokumentų bei juos sudarančių skyrių ir poskyrių antraštes, pastraipas, iliustracijas, lenteles, nuorodas į kitus dokumentus ar kitokius duomenis ir t.t. HTML buvo sumanyta kaip grynai loginės struktūros aprašymo kalba, bet greitai paaiškėjo, jog WWW puslapių kūrėjams bei skaitytojams to nepakanka. Todėl HTML, be loginių savybių, gali aprašyti ir fizines dokumento savybes, pavyzdžiui, šrifto parametrus, lentelių, iliustracijų bei kitų elementų dydžius ir pan. [1]

JavaScript (angl. script – rankraštis, scenarijus) – programavimo kalba, skirta dinaminio valdymo veiksmams atlikti HTML dokumente. Tai Netscape Communications organizacijos sukurta programavimo kalba, kuria siekiama praplėsti tinklapio kūrėjų galimybes. JavaScript kalba yra daug paprastesnė už Java, tačiau gali suteikti tinklapiui daugiau interaktyvumo nei paprastos HTML priemonės. Dėl to JavaScript turėtų pamėgti tinklapių kūrėjai, kurie nelabai mėgsta grynąjį programavimą, bet nori kurti savitus tinklapius. JavaScript programos tekstas yra rašomas HTML dokumento viduje, tarp <script> nuorodų. Netscape Navigator ir Microsoft Explorer apdoroja tekstą vidiniu interpretatoriumi. Dėl to, kad kai kurie veiksmai atliekami vartotojo kompiuteryje, sumažėja tinklų apkrovimas ir paspartėja duomenų kaita tarp vartotojo kompiuterio ir tinklo tarnybinės stoties. JavaScript priemonės buvo palankiai įvertintos pirmaujančių kompiuterijos įmonių tarpe.

Kaskadiniai stiliai. Sukurti paprastą tinklapį nesunku. Daug sunkiau pasiekti gero svetainės apipavidalinimo. Tam gali padėti pakopiniai stilių šablonai (angl. Cascading Style Sheets (CSS)), tinklapių išvaizdos pagrindas. CSS - neatskiriama didžiųjų portalų ir mažų asmeninių svetainių dalis. CSS kūrėjai - Pasaulio voratinklio konsorciumas (angl. World Wide Web Consorcium (W3C)). Ši organizacija kartu su didžiosiomis IT bendrovėmis kuria HTML ir kitus interneto standartus. Interneto naršyklių kūrėjai (Microsoft, Netscape, Opera Software ir t.t.) laikosi W3C rekomendacijų. Stiliai vadinami pakopiniais, nes tai atitinka HTML dokumentų apipavidalinimo principą. Naudojant daug stilių, jie veikia pagal svarbą, tarsi pakopomis. Žinant, jog internetui nėra nė penkiolikos metų, CSS – sąlyginai senas ir pripažintas būdas paprasčiau ir tiksliau išdėstyti tinklapio turinį.

Serverių puslapiai yra technologijos dinaminiams tinklo puslapiams kurti. Iš pradžių buvo naudojami Microsoft Active Server Pages (ASP), bet vėliau pasirodė kita populiari interneto technologija, pavadinta PHP – ateities tinklo kūrimui. PHP yra artimiausia ASP kodo filosofijai. ASP palaiko daugelį programavimo kalbų (dažniausiai naudojama VBScriptas), bet jos architektūra iš prigimties yra lėtesnė ir užimanti daugiau atminties nei PHP modelis, kadangi kiekviena ASP programa kompiliuoja paleidimą nuosavu procesu. PHP turi panašias į ASP laiko ir tipų valdymo funkcijas. HTTP antraštės valdymo funkcijos ASP yra lengviau naudojamos. Vienintelis dalykas, kurio trūksta PHP, yra ASP atitikmuo taikomųjų programų kitimui, kuris yra pasiekiamas tinklo serveriui.

ASP yra gera ir naudinga technologija, tačiau laikui bėgant paaiškėjo PHP privalumai: • Greitis • Aukštesnės kokybės atminties valdymas • Maža kaina (daugelis PHP priemonių yra nemokamos) • Gera sąsaja su MySQL DBVS daro PHP programavimą ir veikimą dar efektyvesnį • Artimas Java/C++ programavimo stilius • Tinka įvairioms platformoms Programuotojai PHP dažnai naudoja greitam kūrimui, todėl neteikia didelės reikšmės programos architektūrai

tobulinti. Tuo galima paaiškinti tą faktą, kad PHP kalboje mažai naudojami šablonai, paplitę Java, C, .NET programavimo technologijose. Tačiau ši kalba duoda ne mažesnes galimybes naudoti šablonus ir sukurti gerą programos architektūrą.

3. Interneto sistemų kūrimo šablonų naudojimo metodika Tradiciškai šablonai aprašomi laikantis tam tikros struktūros. Greta pateikiamos jų UML diagramos ir

naudojimo rekomendacijos [2]. Šablonų naudojimas leidžia patobulinti standartinį Rational Unified projektavimo procesą, kuriame yra nurodyti

proceso etapai ir projektavimo principai, bet nėra apibrėžtų taisyklių, kaip formuoti taikomųjų programų architektūrą. Projektas kuriamas pagal panaudojimo atvejų žingsnius. Jau analizės etape siūloma suskirstyti kuriamos sistemos klases į ribines, valdiklių ir esybių klases. Esybių klasės nustatomos iš dalykinės srities analizės. Tačiau ribinės ir valdiklių klasės dažniausiai parenkamos remiantis intuicija. Patyrę projektuotojai naudoja projektavimo šablonus, kurie padeda sukurti geresnę taikomosios programos architektūrą.

Toliau pateiktas šablonų rinkinys, kurį siūloma naudoti kuriant interneto sistemas.

3.1. Modelis/Vaizdas/Valdiklis

Daugelio interneto sistemų paskirtis yra paimti duomenis iš duomenų bazės ir parodyti juos vartotojui, o kai vartotojas juos modifikuoja – išsaugoti. Kadangi tarp duomenų bazės ir vartotojo sąsajos nuolat perduodamas

– 46 –

Šablonų naudojimas kuriant duomenų apdorojimo sistemas internete

duomenų srautas, šias dvi dalis tikslinga sujungti, kad sumažinti kodavimo apimtį ir pagerinti užduočių vykdymą. Vis dėlto šis atrodytų natūralus suartinimas turi keletą ryškių problemų. Viena iš problemų yra ta, kad vartotojo sąsaja turi tendenciją keistis daug dažniau, nei duomenų saugojimo sistema. Kita problema, susijusi su duomenų ir vartotojo sąsajos susijungimu, yra ta, kad veiklos logika reikalinga ne tik duomenų perdavimui.

Modelis/vaizdas/valdiklis atskiria dalykinės srities modeliavimą, pateiktį ir veiksmus, pagrįstus vartotojo įvestimi, į tris atskiras klases:

• Modelis valdo dalykinės srities elgseną ir duomenis, reaguoja į užklausas apie jo būseną ir į instrukcijas pakeisti būseną.

• Vaizdas valdo informacijos pateiktį. • Valdiklis interpretuoja vartotojo įvestį pele ir klaviatūra, informuoja modelį ir/ar vaizdą apie reikalavimą

keistis. 1 paveikslas rodo trijų objektų tipų tarpusavio ryšius:

Valdiklis

VaizdasModelis

ModelisDalykinės srities logika

Vaizdas

Generuot i HTML()

Puslapio valdiklis

Apdoroti HTTP užklausą()Atnaujinti modelį()Identifikuoti vaizdą()

1 pav. MVC šablonas 2 pav. Puslapio valdiklio struktūra

Naudojant MVC šabloną, pagerėja testavimas. Kai komponentai yra stipriai tarpusavyje susiję, ypač su

vartotojo sąsajos komponentais, testavimas tampa labai sudėtingas. Testavimo komponentų tipai dažnai reikalauja sudėtingo nustatymo net ir testuojant paprastą funkciją. Jei pasitaiko klaidos, sunkiau atskirti ir ištaisyti specifinio komponento klaidą.

3.2. Puslapio vadiklis

MVC šablone dažnai visų pirma pabrėžiamas modelio ir vaizdo atskyrimas, mažiau dėmesio skiriant valdikliui. Dinaminėse tinklo programose skirtingi vartotojų veiksmai gali reikalauti skirtingos valdiklių logikos, išlaikant tą patį vaizdą. Taikant MVC interneto programų kūrimui, reikia pastebėti, kad tinklo puslapių turinys yra dinaminis, bet navigavimas tarp puslapių dažniausiai statinis. Daugeliui dinaminių puslapių valdiklių kodas apima tuos pačius žingsnius: tikrinti vartotojo autentiškumą, išgauti puslapio parametrus iš užklausos eilutės ar formos lauko, komplektuoti sesijos informaciją, atkurti duomenis iš duomenų šaltinio, perduoti dinamines puslapio dalis, pridėti antraštes ir apatines eilutes. Tai gali vesti prie didelio kodo dubliavimo, todėl kiekvienam puslapiui galima naudoti tokį patį valdiklį.

Naudojant puslapio valdiklio modelį, įvestis priimama iš puslapio užklausos, modeliui taikomi reikalaujami veiksmai ir nustatomas teisingas vaizdas, kuris pateikiamas rezultato puslapyje. Veiklos logika atskiriama nuo užklausos apdorojimo kodo. Puslapio valdiklis gauna puslapio užklausą, išrenka reikiamus duomenis, vykdo modelio atnaujinimą ir siunčia užklausą vaizdui. Modifikuojant duomenis, vaizdas priklauso nuo modelio. Apibrėžiant atskirus puslapių valdiklius, modelis izoliuojamas nuo veiksmų, kurie priklauso nuo užklausų apdorojimo tinkle: sesijos valdymo, parametrų išgavimo ir pan.. 2 paveiksle parodytas puslapio valdiklio šablonas.

Puslapių valdiklis reikalingas daugelyje interneto technologijų, kadangi daugelis jų įtraukia puslapio valdiklį į serverio puslapio formą (pvz.: ASP, PHP). Serverio puslapiai faktiškai jungia vaizdo ir valdiklio funkcijas ir neteikia norimo atskyrimo tarp pateikties kodo ir valdiklio kodo. Tai mažina pakartotino panaudojimo galimybes. Pavyzdžiui, jei skirtingi veiksmai duoda tą patį puslapį, negalima naudoti to paties vaizdo, kadangi jis supintas su valdiklio kodu.

3.3. Priekinis valdiklis

Priekinis valdiklis sprendžia decentralizavimo problemą, nukreipdamas visas užklausas per vieną valdiklį. Jis dažnai susideda iš dviejų dalių: palaikymo ir komandų hierarchijos (3 pav.).

– 47 –


Klientas

Konkreti komanda 1

Konkreti komanda 2

Prižiūrėtojas Komanda

Vykdyti() : Void

<<Interface>>

0..n0..n

3 pav. Priekinio valdiklio šablonas

3.4. Tarpinis filtras

Daugeliu atvejų filtrai naudojami atlikti manipuliacijoms, kurios nepriklauso nuo situacijos. Pavyzdžiui, HTTP antraščių apdorojimas, saugumo užtikrinimas, simbolių kodavimas ir pan. Filtrai yra nepriklausomi vienas nuo kito, todėl labai lankstūs. Bet kokią filtrų kombinaciją galima sujungti į grandinę nekeičiant jų kodo.

Paprastai tarpiniai filtrai jungiami į grandinę, kurią sudaro filtrų sąrašas. Prieš patekdama į taikomosios programos logikos valdiklį, tinklo užklausa pereina per filtrų grandinę. 4 paveiksle parodyta tarpinio filtro klasių diagrama.

ValdiklisUžklausos prižiūrėtojas

Filtrų grandinė

Kartoti filtrų sąrašui()Filtras

<<Interface>>

0..n0..n

Filtras 1 Filtras 2

Užklausos valdiklis

Užklausos šablonas

Vykdy ti užklausą()Format1()Format2()

Užklausa 1

Format1()Format2()

Užklausa 2

Format1()Format2()

4 pav. Tarpinio filtro klasių diagrama 5 pav. Šabloninis metodas

Kai tinklo serveris gauna puslapio užklausą, užklausos prižiūrėtojas perduoda valdymą pirmam filtro grandinės objektui. Prižiūrėtojo objektas eilės tvarka aplanko kiekvieną filtrą. Jei reikia atlikti dinaminę filtrų kompoziciją, filtrų grandinė gali skaityti vieną po kito filtrus iš konfigūracijos failo. Kiekvienas filtras gali modifikuoti įeinančias užklausas.

3.5. Šabloninis metodas

Šabloninis metodas (angl. Template Method) padeda abstrakčiai aprašyti procesą, susidedantį iš panašių, tačiau kiek skirtingai realizuojamų žingsnių. Kitaip sakant, viršesnėje klasėje aprašomas algoritmo karkasas, kuris skirtingai įgyvendinamas poklasėse. Pavyzdžiui, norint išgauti tam tikrus duomenis, reikia prisijungti prie duomenų bazės, rasti reikiamus įrašus, skaityti, jungti ir t.t. 5 paveiksle parodyta šabloninio metodo struktūra.

4. Eksperimentinė miškų informacinės sistemos realizacija nutolusiems vartotojams

Aprašytas šablonų rinkinys buvo išbandytas, kuriant Miškų informacinės sistemos prototipą interneto vartotojams. Šios sistemos funkcionalumą rodo panaudojimo atvejų diagrama 6 paveiksle. Sistemą naudos 4 tipų vartotojai: taksatorius, kuris stebi ir registruoja miško sklypų duomenis (miško sklypų plotus, kategorijas, medžių tipus, medienos tūrius); projektuotojas, kuris planuoja, kokius sklypus ir medžių tūrius reikia kirsti; vykdytojas, kuris vykdo kirtimus ir registruoja iškirstus sklypų plotus ir medienos tūrius; administratorius, kuris prižiūri sistemą ir suteikia vartotojams teises. Kadangi tikroji miškų informacinė sistema yra labai sudėtinga, prototipas supaprastintai atspindi sistemos struktūrą ir pagrindines funkcijas.

– 48 –


Suteikti vartotojui teises

taksatorius

registruoti sklypu sistema

Projektuotojas

rengti kirtimo projektus

Vykdytojas registruoti vykdyma

Prisijungti

Naudoti misku IS

Atsijungti

<<include>>

<<include>>

reg_misko tipareg_uredija

reg_medziu tipa

reg_misko kategorija

Adminstruoti

6 pav. Miškų informacinės sistemos panaudojimo atvejų diagrama

Dalykinės srities klasių diagrama pateikta 7 paveiksle. Ji rodo pagrindinius objektų tipus, apie kuriuos reikės įvesti ir saugoti informaciją.

7 pav. Dalykinės srities klasių diagrama

8 paveiksle parodytas principinis interfeiso navigavimo planas. Prie pagrindinio puslapio su skirtingomis teisėmis prisijungę vartotojai gali matyti visus puslapius, tačiau gali redaguoti tik jiems skirtą informaciją.

8 pav. Interfeiso navigavimo planas

– 49 –


Sistemos projekto modelis pateiktas 9 paveiksle. Šio modelio tikslas buvo parodyti, kaip veikia sistema, pereinant nuo pagrindinio iki duomenų tipo puslapių. Užklausos patenka į pagrindinę klasę (priekinį valdiklį), kuris nukreipia jas į teisių tikrinimo klasę, kuri tarnauja kaip filtras. Kreipiantis pirmą kartą, vartotojui pateikiamas prisijungimo langas, kur jis turi įvesti vardą ir slaptažodį (prisijungusio vartotojo užklausos taip pat pereina per filtrą, kad būtų užtikrintas duomenų saugumas). Jei vartotojo vardas ir slaptažodis tinkami, vartotojui pateikiamas jam skirtas puslapis, kuriame jis gali pasirinkti veiksmus ir duomenų tipus.

Pagal perduodamus duomenis pagrindinė klasė nustato, kokiai vykdomajai daliai reikia perleisti vykdymą, tuomet sukuriamos reikalingos klasės ir joms perduodami paruošti vartotojo duomenys.

Norint sukurti nuo duomenų bazės nepriklausančią sistemą, visi kreipiniai į duomenų bazę turi eiti per abstrahuojančią klasę „duomenų prieiga”. Klasės eksportuojami duomenys tiesiogiai nesiriša su DB galimybėmis, todėl perėjimui prie kitos DB pakanka sukurti papildomą konkrečią klasę.

Sistemoje naudojamos kelios globaliai pasiekiamos klasės (pavieniai objektai): puslapio valdiklis, duomenų prieiga, teisių valdiklis. Jos realizuoja metodus, kurie reikalingi daugeliu atvejų, neturi vidinės būsenos (arba ji turi būti vienoda visoje sistemoje). Puslapio valdiklio klasė skirta patogiam HTML kodo generavimui iš paprastų duomenų struktūrų. Dažniausiai naudojami metodai greitam pasirinkimų (įvairių sąrašų), lentelių sudarymui. Teisių valdiklio klasė, kaip jau minėta, naudojama vartotojo teisių tikrinimui, prisijungusio vartotojo informacijos saugojimui.

Sistemoje naudojama keletas paprastų sąrašų lentelių (pvz., medžių tipai), vartotojui reikia suteikti galimybę jas patogiai redaguoti. Išvengiant kodo dubliavimo, naudojamas šabloninis metodas ir tobulinamų klasių strategija: bazinė klasė elementas suteikia pačius paprasčiausius metodus įrašo įtraukimui, išmetimui, viso sąrašo gražinimui. Tokių operacijų pakanka kelių tipų sąrašams, atvaizduojamų miško tipas, urėdija, medžių tipas, miško kategorija klasėmis. Klasė Išplėstas elementas paveldi elemento metodus ir papildo metodais, reikalingais naudojant lenteles, kuriose kiekvienas elementas turi „tėvą”, pavyzdžiui, kiekviena girininkija priklauso kažkokiai urėdijai. Klasės kvartalai ir girininkijos konkretizuoja išplėstą elementą.

Kaip vyksta vartotojo užklausų apdorojimas, rodo sekų diagramos: 10 paveiksle parodytas vartotojo įėjimas į sistemą, 11 – pasirinkto tipo duomenų apdorojimas.

Teisių valdiklis

Tikrinti()Tikrinti teises()Tikrinti prisijungimą()Registruoti prisijungimą()Naikinti prisijungimą()

Puslapio valdiklis

Generuoti lentelę()Generuoti sąrašo langą()Generuoti sąrašą()Klaidos pranešimas()

acinis pranešimas()

Duomenų prieiga

rinkti()apildyti()

Sąrašas()

Pagrindinė

Meniu()Parengti()Užverti()

Elementas

Sukurti()Pavadinimas()Ident ifikuoti pavadinimą()Išmesti()Apdoroti()

Išplėstas elementas

Tėvas

Sukurti tėvą()Grąžinti tėvą()

irininkija

rininkija()

Kvartalas

Kvartalas()

Miško tipas

iško tipas()

Urėdija

Urėdija()

Medžių tipas

Medžių tipas()

Miško kategorija

Miško kategorija()

Tarpinis filtras

MŠabloninis metodas

Priekinis valdiklis

InformPuslapio valdiklis,

PaP

Pavienis objektas

G

Gi

Duomenų objektas, Pavienis objektas

9 pav. Sistemos projekto modelis

5. Išvados

Tyrimo dalyje buvo išanalizuoti objektiniame programavime bei interneto sistemų kūrime naudojami šablonai ir sudarytas šablonų rinkinys, kurį tikslinga taikyti kuriant interneto sistemas, apdorojančias duomenų bazėse saugomus duomenis. Rinkinį sudaro modelio/vaizdo/valdiklio, puslapio valdiklio, priekinio valdiklio, pavienio objekto, šabloninio metodo, filtro ir duomenų prieigos šablonai. Šiuos šablonus galima įvairiai jungti ir sudaryti naujus reikiamus šablonus. Šablonų naudojimas leidžia patobulinti universalų kūrimo procesą Rational Unified, kadangi padeda efektyviau suprojektuoti programinių klasių struktūrą. Šio darbo naujumas yra tame, kad pasirinkti

– 50 –


šablonai buvo realizuoti PHP programavimo kalba, kurioje šablonai yra mažai taikomi. Daugiausiai jie naudojami Java, C, .NET programavimui. Tačiau PHP kalba yra besivystanti ir turi nemažai privalumų, svarbiausia, ji yra laisvai prieinama. Atlikta programinė realizacija parodė šablonų taikymo privalumus. Atlikus nedidelius modifikavimus, sudaryti šablonai gali būti panaudoti Miškų informacinės sistemos realizacijai bei kitų panašaus funkcionalumo sistemų kūrimui.

: taksatoriusf_pagrindine m_teisiu

valdiklisDuomenys DB htmlpag Taksatoriaus

puslapis

atidarytiprisijungti Registruoti prisijungima

tikrinti teises

parinkimas skaityti

sug_lent Atidaryti

10 pav. Taksatoriaus įėjimo į sistemą sekų diagrama

Irasymas OK

: taksatorius Taksatoriaus forma

htmlpag m_miskotipas m_teisiu_vadiklis

DBDuomenys

sukurti misko tipasug_listbox atidaryti

ivesti varda

ivesti aprasyma

issaugoti

tikrinti teises

Sukurti misko tipa issaugoti

13 pav. Miškų tipo registravimo sekų diagrama

Literatūros sąrašas [1] Jacobson I.,Booch G., Rumbaugh J. The Unified Modeling Language. User Guide. Adison Wesley, 2000m. [2] Eriksson H-E, Penker M, UML Toolkit, Wiley Computer publishing, 1998m, 397 psl.. [3] The definitive JavaScript Resource: JavaScript Tutorials and Free JavaScript [ žiūrėta 2003 12 12] prieiga per Internetą

:http://javascript.com/ [4] Trowbridge D., Mancini D. et all.Enterprise Solution Patterns Using Microsoft .NET. Microsoft Software Corporation,

Model-View-Controller 2003. [5] Lim J. 7 Reasons Why PHP is Better than ASP. Journal of Dabase Programming, Sep 14, 2000. [6] Shalloway A., Trott J.R.Design Patterns Explained. Addison-Wesley, 2002.

Patterns For Development Of Data Processing System On The Web

In this work object-oriented patterns were used for development of data processing system on the Web. Model-View-Controller, Page Controller, Front Controller, Intercepting Filter and other patterns were analyzed. These patterns are popular in object-oriented development, but in PHP they are rarely used because of rapid style of development. In this work patterns were used for development of internet prototype of Information System of Forest Resources Management. Implementation in PHP has demonstrated the efficiency of such approach.

– 51 –

http://javascript.com/

XML TAIKYMO METODIKA KURIANT DUOMENŲ APDOROJIMO SISTEMAS INTERNETE

Ilma Žederštreimaitė, Lina Nemuraitė Informacijos sistemų katedra, Kauno technologijos universitetas

Studentų g. 50, LT-3031 Kaunas

Dideliems duomenų kiekiams saugoti geriausiai tinka reliacinės duomenų bazės. Perduoti duomenis tinklu geriausiai naudojant XML. Kuriant interneto informacines sistemas, dažnai daug kartų tenka vykdyti transformacijas iš reliacinių schemų į XML ir atgal. Straipsnyje analizuojami esami transformavimo metodai ir daroma išvada, kad projektuojant sistemą reikia remtis bendresniu UML modeliu, iš kurio galima generuoti tiek reliacinę, tiek XML schemą. Daugelis DBVS turi savo transformavimo priemones. Straipsnyje nagrinėjamos ir konkrečios MS SQL serverio XML transformavimo priemonės, pateikiamos jų taikymo rekomendacijos, pristatoma šių priemonių pagrindu sukurta eksperimentinė Miško atkūrimo informacinė sistema.

1. Įvadas

Dauguma sistemų naudoja skirtingų formatų duomenis, todėl atsiranda įvairių problemų bei sunkumų perduodant duomenis iš vienos sistemos į kitą. Šios problemos sprendimas yra naudoti tokį duomenų struktūros aprašymą, kurį suprastų visos sistemos. Toks aprašymas turėtų būti universalus. Šiuo metu labiausiai išvystytas ir plačiai naudojamas standartas duomenų aprašymui yra XML (angl. eXtensible Markup Language) [3-5].

XML dokumentai gali būti naudojami pačiose įvairiausiose srityse: e.komercijoje, bendraujant su verslo partneriais ar organizacijos viduje integruojant programinę įrangą bei duomenų bazes. Dauguma sistemų naudoja skirtingų formatų duomenis, todėl joms keistis duomenimis yra sunku. XML yra standartinis formatas, kurį įvairios programos supranta vienodai, todėl duomenys gali būti transformuoti į XML ir laisvai perduoti kitai sistemai ar programai [1].

Microsoft SQL Server 2000 turi integruotas aukščiausios kokybės XML priemones, kurios yra lanksčios ir nesunkiai naudojamos interneto puslapių kūrėjų ir duomenų bazių programuotojų. Reikšmingos naujos SQL Server 2000 savybės siejasi su XML, kuri suteikia jam papildomą funkcionalumą. Tai suteikia galimybę naudoti XML dokumentus duomenų bazei papildyti, pasiekti SQL serverį per naršyklę ir susigrąžinti duomenis iš duomenų bazės XML formatu ir t.t. Šiuo metu Microsoft SQL Server 2000 yra vienas iš reliacinių duomenų bazių valdymo sistemų lyderių. Jis yra vėliausiai išleistas šios verslo klasės produktas ir turi naujas XML funkcionalumą palaikančias duomenų operacijas ir mainus [2].

2. XML paremtų DB taikomųjų programų projektavimo metodika

Šiame darbe buvo siekiama įjungti XML schemos kūrimą į bendrą informacinės sistemos projektavimo procesą. Universalus projektavimo procesas Rational Unified naudoja universalią UML kalbą. Norint kurti informacinę sistemą bendro konceptualiojo modelio pagrindu, tikslinga sudaryti dalykinės srities modelį UML kalba ir atvaizduoti jį į reliacinės duomenų bazės schemą bei XML schemą (1 pav). XML schemos sandara yra artimesnė UML klasių diagramai negu reliacinei schemai (2 pav.). Tiesa, kai kurių XML schemos savybių nėra UML diagramoje, todėl esant reikalui projektuotojas turi papildyti XML schemą reikiamomis savybėmis.

1 pav. UML modelio transformavimas

– 52 –

XML taikymo metodika kuriant duomenų apdorojimo sistemas internete

2 pav. XML schema, UML klasių diagrama ir reliacinė duomenų bazės schema

Sudarytoje reliacinių DBVS prieigos per internetą programinės įrangos kūrimo metodikoje, naudojame MS SQL Serverio 2000 XML apdorojimo galimybes. Metodikos kūrimo proceso etapai pavaizduoti 3 paveiksle. Metodika apima:

• Apibrėžtos struktūros duomenų išgavimą ir įrašymą, panaudojant XML schemas; • Duomenų pateikimą internete, panaudojant XSL (XML Stylesheet Language). • Privalumai: • UML modelio privalumas - pakartotinas konceptualiojo lygio modeliu panaudojimas. Jei XML ir reliacinei

schemai nenaudojamas bendras UML modelis, gali būti sunkiau suderinti reliacines DB ir XML schemos savybes.

• XML schemos privalumas - pakartotinas panaudojimas loginiame lygyje. Lengvai projektuojama ir suprantama.

• Updategrams arba FOR XML - papildomo programos kodo sumažėjimas, nereikia naudoti dar vienos programavimo kalbos, pvz., .NET, kūrimas vyksta aukštesniame lygyje. Updategrams kodas suprantamas ir ji turi galimybę perduoti parametrus.

3. XPath įrankio taikymas ir XSL panaudojimas

Tradicinės SQL užklausos yra geras įrankis, kurio pagalba filtruojamos ir sujungiamos reliacinės lentelės ir peržiūros. XML peržiūrai naudojamas užklausų mechanizmas yra XPath (antl. XML Path language) užklausų kalba. XPath yra grafinė navigacinė kalba, kuri naudojama pažymėti XML dokumente rinkinį šaknų. SQL serveryje XML palaiko XPath kalbos poaibį kuris leidžia vartotojui vykdyti užklausas naudojantis XML Schemas.

– 53 –

I. Žederštreimaitė, L. Nemuraitė

Sudaryti dalykinės srities UML klasių diagramą

Reikalavimai sistemai (Panaudojimo atvejų modelis ir specifikacijos)

Dalykinės srities UML klasių diagrama

Sudaryti reliacinės DB schemą Sudaryti XML

schemą

Reliacinės DB schema

XML schema

Sukurti reliacinę DB

Reliacinė DB

Sukurti svetainę

Sukurti duomenų atnaujinimo puslapi

Sukurti duomenų vaizdavimo pus lapį

Aprašyti Updategram'ą

Aprašyti FOR XML

Aprašyti XPath

Aprašyti XSL

Sukurti duomenų atnaujinimo puslapi

Sukurti duomenų vaizdavimo pus lapį

Aprašyti Updategram'ą

Aprašyti FOR XML

Aprašyti XPath

Aprašyti XSL

Sudaryti vartotojų interfeiso modelį

Vartotojų interfeiso klasių diagrama

Updategram'ų aprašai

XSL aprašai

XPath aprašai

3 pav. Veiklos diagrama, rodanti duomenų apdorojimo internetinių sistemų kūrimo procesą, paremtą MS SQL serverio XML

technologijomis

4 pav. Duomenų peržiūros veiklos diagrama

4 pav. pavaizduotoje diagramoje galima suprasti, kaip vyksta peržiūros procesas. Atkūrimo projektų kūrėjas, norėdamas peržiūrėti turimus inventorizacijos duomenis, paspaudęs atitinkamą nuorodą peržiūrai iš karto pamato lentelę su gautais duomenimis, kur XML failas jau yra sugeneruotas ir XSL įvykdyta transformacija. XML

– 54 –

XML taikymo metodika kuriant duomenų apdorojimo sistemas internete

dokumente aprašyta XPath užklausa kreipiasi į XML schemą, nes joje yra aprašytos visos duomenų bazės lentelės elementai bei atributai. Toliau duomenys yra paimami iš DB ir rezultatas grąžinamas XML formate, kur įvykdžius transformaciją duomenys atvaizduojami HTML.

Atvaizdavimui buvo pasirinktas XSLT priemonė, kuri transformuoja XML dokumentą į dokumentą, kuris atvaizduojamas naršyklėje. XSLT naudoja XPath užklausas surasti elementus XML pradiniame dokumente, kurie atitinka tam tikras sąlygas ir po to atlieka elementų transformaciją (4 pav.).

4 pav. Xpath užklausų ir XSL transformacijos panaudojimas

4. Updategrams įrankio taikymas

Updategrams įrankis yra įspūdingas būdas išgauti ir atnaujinti XML duomenis SQL serveryje. Šios naujos savybės kartu su XPath užklausomis, šablonais (templates) ir HTTP priėjimu prie SQL duomenų suteikia dideles galimybes. Privalumas tai, kad palaiko duomenų bazėje vienos ar kelių lentelių atnaujinimą, atitinkantį XML hierarchinį sąryšį.

6 pav. pagalba pavaizduotas duomenų įterpimo procesas. Kai atkūrimo projektų kūrėjas patvirtina įvestus duomenis, dokumentas visų pirma kreipiasi į updategrama, kurioje aprašyti visų įvedamų atributų vardai. Updategrama pradžioje kreipiasi į XML schema ir tik tuomet įrašo duomenis į DB. Paskutiniame žingsnyje, vartotojas gauna patvirtinimą apie sėkmingą duomenų įvedimą.

– 55 –

I. Žederštreimaitė, L. Nemuraitė

5 pav. Updategrama

6 pav. Duomenų įvedimo veiklos diagrama

5. Išvados

Darbe buvo tiriami internetinių duomenų apdorojimo sistemų kūrimo metodai, naudojantys XML. Tam tikslui išnagrinėti XML dokumentų struktūros aprašymo būdai ir duomenų transformavimo iš reliacinės duomenų bazės į XML dokumentus galimybės. Nors tokios priemonės yra realizuotos daugelyje DBVS, transformacijos vykdomos toli gražu nevienodai ir yra daug būdų, kaip atvaizduoti duomenų bazės turinį XML dokumentais. Pavyzdžiui, MS SQL serverio XML priemonėmis galima tą padaryti įvairiais variantais.

Pateikta siūloma informacinės sistemos projektavimo metodika, kurioje XML ir reliacinės duomenų bazės schemos sudaromos iš UML klasių modelio. Parodyta galimybė grafiškai aprašyti XML schemos struktūrą UML klasių diagrama, įvedus reikiamus stereotipus. Aprašyta konkrečių MS SQL serverio priemonių (SQL FOR XML, XPath, Updategrams) naudojimo metodika, skirta tokios sistemos įgyvendinimui.

Atliktas konkrečių MS SQL serverio XML priemonių tyrimas parodė, kad duomenų pateikimui galima naudoti paprastesnes priemones, pavyzdžiui, SQL užklausas, grąžinančias duomenis XML dokumentų pavidale. Norint atnaujinti duomenis, reikalingos sudėtingesnės priemonės, kurios naudoja XML schemas. Reikia ir kitų papildomų priemonių: XML užklausų kalbos XPath, stilių aprašymo kalbos XSL ir pan.

Literatūra [1] Simon St. Laurent. XML: A Primer. - IDG Books Worldwide, Inc., 1997. – 348p. [2] Vieira R. SQL Server 2000 XML Integration, 2000 [žiūrėta 2002-11-20]. Prieiga per internetą:

http://www.perfectxml.com/. [3] W3C XML working group. Extensible Markup Language (XML) 1.0 (Second Edition), 6 spalio 2000, [žiūrėta 2002-12-

10]. Prieiga per internetą: 6 October 2000 http://www.w3.org/TR/2000/REC-xml-20001006. [4] Michael J. Young. XML Step by Step, Second Editon. - USA: Microsoft Press, 2001. – 382 p. [5] XML Schema Part 0: Prime, W3C, 2001 [žiūrėta 2002-12-10]. Prieiga per internetą: http://www.w3.org/TR/xmlschema-0/.

– 56 –

http://www.perfectxml.com/

http://www.w3.org/TR/2000/REC-xml-20001006

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

FEDERACINĖS DUOMENŲ BAZĖS

Vilius Kontrimas Kauno Technologijos universitetas, Informacijos sistemų katedra

Studentų g. 50, Kaunas, [email protected]

Duomenų šaltinių integravimo poreikis lėmė federacinių informacijos sistemų atsiradimą ir spartų populiarėjimą. Federacinė informacijos sistema integruoja autonomiškus, heterogeniškus duomenų šaltinius ir suteikia vartotojui globalų priėjimą prie šaltiniuose saugomų duomenų. Federacinės duomenų bazės yra populiariausias federacinių informacijos sistemų tipas, išsiskiriantis tuo, kad egzistuoja globali duomenų schema ir duomenų šaltiniais gali būti tik duomenų bazės. Išnagrinėtos federacinių informacijos sistemų ir federacinių duomenų bazių savybės, taikymo pavyzdžiai parodė pagrindines problemas ir vystymo kryptis, kuriomis bus dirbama toliau.

1. Įvadas Federacinė informacijos sistema yra sistema, integruojanti palikuoninius duomenų šaltinius ir taikomąsias

programas. Palikuoninių sistemų, sukurtų skirtingu laiku, naudojant skirtingus duomenų modelius, technologijas yra daugelyje organizacijų. Jų naudojimo skirtumai, migracijos į naujas sistemas dideli kaštai lemia, kad šias sistemas tikslinga integruoti į vieną visumą federacinės informacijos sistemos pagalba, o ne kurti naują globalią sistemą nuo pagrindų.

Federacinės duomenų bazės yra vienas iš federacinių informacijos sistemų tipų. Toks skirstymas dar nėra visuotinai pripažintas, straipsnyje juo remiamasi dėl šio skirstymo logiškumo ir lankstumo.

Duomenų, patalpintų skirtingose sistemose, integracijos klausimas nagrinėjas jau kelis dešimtmečius. Devintame dešimtmetyje buvo stengiamasi visus duomenis, išskirstytus po savarankiškas ir nesuderinamas sistemas perkelti į vieną centralizuotą duomenų bazę. Tuo tarpu paskutiniame XX a. dešimtmetyje dėmesys buvo perkeltas į skirtingose duomenų bazėse saugomų duomenų integravimą. Pirmas tyrimas buvo atliktas D. Heimbigner ir D. McLeod dar 1985 metais. 1990 metais pasirodė W. Litwin, L. Mark, N. Roussoupoulos bei A.P. Sheth, J.A. Larson straipsniai, aprašę būdus, kaip sukurti globalų priėjimą prie palikuoninių duomenų bazių ir įtvirtinę terminą „federacinė duomenų bazė“. A.P. Sheth ir J.A. Larson aprašyta penkių lygių federacinės duomenų bazės architektūra yra aktuali iki šiol.

Vystantis programinės įrangos kūrimo paradigmoms, centralizuotas, monolitines sistemas keičia modernios sistemos, sukurtos iš nepriklausomų, bendradarbiaujančių komponentų, kliento – serverio architektūrą keičia daugiasluoksnės sistemos, kuriose apjungiama eilė duomenų šaltinių, bendraujančių eile skirtingų protokolų. Atsirado vadinamos mediatoriais arba tarpininkais pagrįstos sistemos (mediator based systems). Šie mediatoriai yra komponentai, kurie duomenis specialių protokolų pagalba gauna iš kitų mediatorių arba duomenų šaltinių apvalkalų (wrapper), kurie pateikia duomenis reikiamu formatu. Todėl tokių sistemų duomenų šaltiniais gali būti ne tik duomenų bazės. Lygiagrečiai mediatorias pagrįstoms sistemoms atsirado federacinės duomenų bazių sistemos, kuriose dėl noro išlaikyti absoliutų duomenų šaltinių autonomiškumą, buvo atsisakyta globalios schemos. Šios sistemos pavadintos silpnai susietomis sistemomis (loosely coupled system). Federacinės duomenų bazės terminas negalėjo apimti visų šių sistemų, todėl atsirado terminas „federacinė informacijos sistema“, kuri apima silpnai susietas sistemas, federacines duomenų bazes ir mediatiorias pagrįstas sistemas.

Straipsnyje pirmiausia yra nagrinėjami trys informacijos sistemų aspektai, kurie yra federacinių informacijos sistemų pagrindas. Sekančiame skyrelyje yra apibūdinami federacinių sistemų vertinimo kriterijai, kurių pagrindu jos skirstomos į silpnai susietas sistemas, federacines duomenų bazes ir mediatoriais pagrįstas sistemas. Toliau atlikta pačių federacinių duomenų bazių analizė, pateiktos jų savybės, egzistuojančios architektūros, taikymo pavyzdžiai, esamos problemos ir vystymo kryptys.

2. Informacijos sistemų klasifikavimo principai Norint apibrėžti federacinę informacijos sistemą ir jos vietą informacinių sistemų klasifikacijoje reikia iš-

nagrinėti tris informacinių sistemų savybes – autonomiškumą, heterogeniškumą ir paskirstymą. Naudojama „kom-ponento“ sąvoka apima duomenų šaltinį, nebūtinai duomenų bazę, esantį federacinėje informacijos sistemoje [2].

– 57 –

mailto:[email protected]

V. Kontrimas

Autonomiškumas yra federacinės sistemos komponento nepriklausomybė nuo federacijos. Jis skirstomas į 3 grupes: • Struktūros autonomiškumas. Tai komponento galimybė naudoti duomenų modelį, kalbą, savas pavadinimų

taisykles ir keisti savo struktūrą atskirai nuo visos sistemos. • Komunikavimo autonomiškumas. Tai komponento galimybė išeiti iš federacinės sistemos, patekti į federacinę

sistemą bet kuriuo metu bei pasirinkti su kuriais komponentais komunikuoti. • Vykdymo autonomiškumas. Tai komponento galimybė nepriklausomai nuo kitų vykdyti ateinančias užklausas.

Praktiškai neįmanomas jei naudojamas globalus transakcijų kontrolės mechanizmas. Heterogeniškumas, atsirandantis dėl autonomiško sistemos komponentų kūrimo, apibrėžia sintaksinius, duomenų modelio ir loginius komponentų skirtumus: • Sintaksinis heterogeniškumas. Pirmiausia tai techniniai skirtumai – nevienodos kompiuterinės įrangos plat-

formos, operacinės sistemos, prieigos metodai. Čia priskiriami ir sąsajų skirtumai, pasireiškiantis nevienodomis užklausų kalbomis, nevienodais kalbų ir pačių užklausų apribojimais.

• Duomenų modelio heterogeniškumas. Tai skirtingų duomenų modelių naudojimas. Tai lemia, jog reikia pasirinkti vieningą duomenų modelį federacijos lygyje, per kurį visi komponentai gali pateikti savo duomenis. Esant skirtingiems duomenų modeliams egzistuoja atskiras sluoksnis, atliekantis reikalingas duomenų trans-formacijas.

• Loginis heterogeniškumas. Pirmiausia tai semantinis heterogeniškumas, pasireiškiantis skirtinga duomenų ir schemos semantika, pvz. homonimų ir sinonimų problema. Čia priskiriamas schematinis heterogeniškumas, pasireiškiantis tos pačios informacijos kodavimu skirtingais duomenų modelio elementais, bei struktūrinis heterogeniškumas, pasireiškiantis skirtingu informacijos struktūrizavimu. Kuriant logines duomenų schemas pagal tam duomenų modeliui galiojančias taisykles, šių dviejų heterogeniškumų galima išvengti. Paskirstymo lygis - tai fizinis duomenų ir funkcijų paskirstymo lygis tarp komponentų. Paskirstyti komponentai

nesinaudoja ta pačia pastoviąja atmintimi. Remiantis pateiktas informacijos sistemų vertinimo kriterijais, galime teigti, kad federacinė informacijos

sistema – tai paskirstyta informacijos sistema, sudaryta iš heterogeniškų ir autonomiškų komponentų. Būtina pabrėžti, kad paskirstymas, heterogeniškumas ir autonomiškumas gali būti daliniai ir nėra griežtos ribos, kada sistema nebelaikoma federacine.

-----------

-------------

-----------

-------------

-----------

-------------

-----------

-------------

-----------

-------------

-----------

-------------

Duomenų šaltinių lygis

Apvalkalų lygis

Federacijos lygis

Pateikimo lygis

1 pav. Federacinė informacijos sistema

Vartotojai, esantys pateikimo lygyje, turi globalų priėjimą prie duomenų šaltinių per federacijos lygį. Fede-racijos lygis apima vieningą priėjimo kalbą, schemą, metaduomenis arba bent kelis iš šių komponentų. Apvalkalų lygyje atliekamos reikiamos transformacijos, leidžiančios apjungti duomenų šaltinius į vieną visumą.

Pateikimo lygyje nuolatos atsiranda poreikis naujoms informacinėms paslaugoms, duomenų šaltinių lygyje vyksta duomenų šaltinių kaita, keičiasi patys šaltiniai, prijungiami nauji, pašalinami nebenaudingi, todėl federacijos lygis turi būti kuo lankstesnis, lengvai vystomas.

– 58 –

Federacinės duomenų bazės

3. Federacinių informacijos sistemų klasifikavimo principai

Egzistuoja dešimt kriterijų, pagal kuriuos yra vertinamos ir klasifikuojamos federacinės informacijos sistemos. 1. Komponentų struktūrizavimo lygis. Komponentai skirstomi į struktūrizuotus, pusiau struktūrizuotus ir nestruk-

tūrizuotus. Struktūrizuoti komponentai turi aiškiai apibrėžtą schemą ir visi duomenys yra sutvarkyti pagal ją, nestruktūrizuoti duomenys negali būti įtraukti į tokį šaltinį. Pusiau struktūrizuoti komponentai turi struktūrą, bet ji nėra apibrėžta aiškia bei griežta schema. Nestruktūrizuoti komponentai struktūros visai neturi, pavyzdžiui, tekstinių dokumentų aibė.

2. Federacijos stiprumas. Jei federacinė informacijos sistema turi globalią schemą, tai federacija laikoma stipria. Silpnoje federacijoje yra tik unifikuota kalba, leidžianti išgauti duomenis iš duomenų šaltinių. Silpnos federacijos atveju dažniausiai naudojama multi-duomenų bazių užklausų kalba MDBQL ir integruoti vaizdiniai.

Federacinė IS su globalia schema

Schemosintegracija

Federacinė IS su integruotaisvaizdiniais

Vaizdiniųapibrėžimas

Vartotojas

2 pav. Stipri ir silpna federacijos

3. Duomenų modelis. Federacinis lygis būna pagrįstas duomenų modeliu, kurio pagalba integruojami visi šaltiniai. Jis egzistuoja ir silpnose federacijose, nes užklausų kalba grindžiama kokiu nors duomenų modeliu. Šiuo metu populiariausia yra naudoti ODMG 3.0 standartu apibrėžtas struktūras. Federacinio lygio duomenų modelio parinkimas priklauso nuo šaltiniuose naudojamų duomenų modelių.

4. Semantinė integracija. Ši savybė yra būdinga stiprios federacijos sistemoms, nes silpnos federacijos atveju duomenys surenkami jų nekeičiant. Semantinė integracija gali būti keturių tipų: kolekcija, lydinys, abstrakcija, papildymas. Kolekcijos atveju duomenys surenkami iš šaltinių nepakeisti (silpnos federacijos atvejis). Lydinio atveju surinkti duomenys yra peržiūrimi, pašalinama besikartojanti informacija, panaikinami prieštaravimai. Abstrakcijos atveju surinkti duomenys yra perkeliami į federacinės schemos numatytą abstrakcijos lygį, o papildymo atveju surinkti duomenys praturtinami reikalinga informacija, apibūdinančia duomenų semantiką.

5. Užslėpimo lygis (transparency). Idealiu atveju vartotojui turi atrodyti, kad jis dirba su centralizuota, lokalia, homogenine sistema. Veikimo mechanizmo užslėpimas gali būti trijose sferose – duomenų fizinės buvimo vietos užslėpimas, duomenų schemų skirtumų užslėpimas, duomenų apibrėžimo ir manipuliavimo kalbų skirtumų užslėpimas.

6. Užklausų paradigma. Užklausos gali būti struktūrizuotos ir išgaunančios informaciją. Pirmųjų atveju egzistuoja užklausos struktūra, kurios rėmuose galima užduoti paieškos parametrus, antrosios yra pagrįstos panašumų ieškojimu, pavyzdžiui, paieška tekstiniuose dokumentuose, video ir audio informacijoje.

7. Kūrimo strategija. Skirstoma į iš viršaus žemyn, kai pirmiausia yra kuriamas federacijos ir pristatymo lygiai, po to integruojami reikalingi šaltiniais, ir iš apačios į viršų, kai turima eilė duomenų šaltinių ir jie integruojami į federaciją [1].

8. Integracijos virtualumas. Integracija yra virtuali, kai gauti duomenys nėra išsaugomi federacijos lygyje. Kai gauti duomenys arba jų dalis yra išsaugomi federacijos lygyje, integracija yra materializuota.

9. Duomenų keitimo galimybė. Skirstoma į galimybę tik skaityti duomenis ir galimybe duomenis skaityti bei rašyti.

10. Prieigos prie duomenų metodai. Vartotojas gali naudoti užklausų kalbą kaip SQL, OQL, parametrizuotas iš anksto paruoštas užklausas arba naršyti po duomenis.

– 59 –

V. Kontrimas

Federacinėsinformacijos

sistemos

Globali schema yra

Globalios schemosnėra Silpnai susietos

informacijossistemos

Šaltiniai tikduomenų bazės

Įvairūs duomenųšaltiniai

Mediatoriais pagįstosinformacijos sistemos

Federacinėsduomenų bazės

3 pav. Federacinių informacijos sistemų klasifikacija

Pagrindiniai informacijos sistemų klasifikavimo kriterijai yra federacijos stiprumas, lemiantis globalios sche-mos buvimą ar nebuvimą ir naudojami duomenų šaltiniai.

4. Federacinės duomenų bazės

Pagrindiniai kriterijai, išskiriantys federacines duomenų bazes iš kitų federacinių informacijos sistemų yra globalios schemos egzistavimas federacijos lygyje ir duomenų šaltinio lygio sudėtyje tik duomenų bazės. Federacinėse duomenų bazėse egzistuoja visų tipų heterogeniškumas, išskyrus užklausų apribojimų skirtumus, vykdymo autonomiškumas, duomenų šaltinių vietos, schemų ir dalinai kalbų užslėpimas nuo vartotojo, stipri federacija, kolekcijos ir lydinio tipo semantinė integracija, virtuali ar dalinai virtuali integracija. Federacinės duomenų bazių sistemos kuriamos principu „iš apačios aukštyn“, priėjimui prie duomenų naudojamos užklausų kalbos, federacijos lygio lankstumas yra žemas, nes komponentų kaita įtakoja globalią schemą.

Išorinė schemaIšorinė schema

Eksporto schemaEksporto schema

Išorinė schema

Federacinė schema

Eksporto schema

Komponentinėschema

Lokali schema

Duomenų bazė



Išorinė schema

Federacinė schema

Eksporto schema

Komponentinėschema

Lokali schema

Duomenų bazė



Išorinė schema

Federacinė schema

Eksporto schema

Komponentinėschema

Lokali schema

Duomenų bazė

Pirminisduomenųmodelis

Kanoninisduomenųmodelis

Vartotojoduomenųmodelis

Duomenųmodelio iružklausųtransformavimas

Schemosintegracija,užklausųdekompozicija

4 pav. Federacinės duomenų bazės penkių lygių architektūra

Kiekviena duomenų bazė turi savo lokalią schemą. Šios lokalios schemos yra transformuojamos į kanoninį duomenų modelį, kuris yra pasirinktas kaip bendras federacijos duomenų modelį [5]. Transformacijos rezultatas yra komponentinė schema. Dažniausiai vartotojui yra reikalinga tik dalis duomenų arba duomenų bazė gali teikti tik tam tikrus duomenis, todėl eksporto schema yra šių „derybų“ rezultatas, komponentinės schemos projekcija, skirta federacijos lygiui [7]. Federacinės schemos apima vieną ar kelias eksporto schemas, kiekviena federacinė schema yra skirta tam tikrai vartotojų klasei. Išorinė schemos pagalba yra atrenkama informacija, skirta konkretiems vartotojams, nedidelėms jų grupėms ar taikomosioms programoms. Vartotojų naudojamas duomenų modelis gali skirtis nuo kanoninio federacinės duomenų bazės duomenų modelio, tokiu atveju atliekamos atitinkamos transformacijos.

Kai vartotojo duomenų modelis skiriasi nuo kanoninio duomenų modelio, federacijos komponentai yra federacinės duomenų bazės, egzistuoja kelios semantikos federacinėje schemoje, yra naudojama išplėsta federacinių duomenų bazių architektūra [6]. Joje yra trys papildomos schemos – derybų schema, vartotojo išorinė schema ir

– 60 –

Federacinės duomenų bazės

– 61 –

taikomųjų atvejų schema. Derybų schema, sudaroma iš lokalios schemos, leidžia kaip komponentą naudoti kitą federaciją, naudojant tik dalį jos duomenų resursų. Vartotojo išorinė schema yra išorinė schema, transformuota į vartotojo duomenų modelį, besiskiriantį nuo kanoninio duomenų modelio. Taikomųjų atvejų schema apima vieną federacinės schemos semantiką, skirtą vienai ar kelioms vartotojų grupėms.

Egzistuoja eilė federacinių duomenų bazių taikymo pavyzdžių. Tai Multibase sistema, skirta integruoti autonomiškas sąryšines, tinklines ir hierarchines duomenų bazes, vartotojas naudojasi unifikuota užklausų kalba DAPLEX, visų komponentų schemos yra transformuojamos į DAPLEX duomenų modelį, vėliau integruojamos į bendrą schema [3]. Mermaid sistema, leidžia integruoti sąryšines duomenų bazes, vartotojas gali naudotis SQL, Quel, ARIEL užklausų kalbomis, kaip kanoninis duomenų modelis naudojamas sąryšinis duomenų modelis. Pegasus sistema leidžia integruoti sąryšines ir objektinės orientacijos duomenų bazes, kanoninis duomenų modelis – objektiškai orientuotas, unifikuota užklausų kalba – HOSQL. VHDBS integruoja įvairių tipų duomenš bazes, kanoninis duomenų modelis – objektiškai orientuotas, atitinkantis ODMG 2.0 standarta, vartotojai gali duomenis peržiūrėti naršyklėje per grafinę sąsają, kuri formuoja užklausas naudodama OQL kalbą [4].

Eilė atliktų tyrimų ir įgyvendintų projektų parodė svarbiausias federacinių duomenų bazių vystymo ir tobulinimo kryptis. Tai visų pirma schemų transformavimas, schemų integravimas, prieigos prie duomenų kontrolė, užklausų valdymas ir optimizavimas, globalus transakcijų valdymas.

5. Išvados

Federacinės informacijos sistemos yra paskirstytos sistemos, integruojančios autonimiškus, heterogeniškus duomenų šaltinius. Paskirstymas, heterogeniškumas ir autonomiškumas gali būti daliniai ir nėra griežtos ribos, kada sistema nebelaikoma federacine.

Federacinės duomenų bazės išsiskiria iš visų federacinių informacijos sistemų tuo, kad egzistuoja globali schema federacijos lygyje ir duomenų šaltiniais gali būti tik duomenų bazės. Tipinė federacinės duomenų bazės architektūra yra penkių lygių, tačiau kai skiriasi vartotojo duomenų modelis nuo kanoninio, federacinėje schemoje egzistuoja kelios semantikos, kaip duomenų šaltinis naudojama kita federacinė duomenų bazė, ši architektūra praplečiama iki aštuonių lygių.

Federacinių duomenų bazių aktualiausios problemos, kurios sprendžiamos šiuo metu, yra schemų trans-formavimas, schemų integravimas, prieigos prie duomenų kontrolė, užklausų valdymas ir optimizavimas, globalus transakcijų valdymas.

Literatūros sąrašas [1] Busse S., Kutsche R.,Leser U., Strategies for the conceptual design of federated information systems,

http://citeseer.nj.nec.com 2003 12 01 [2] Busse S., Kutsche R.,Leser U., Weber H. Federated information systems: concepts, terminology and architecture,

http://citeseer.nj.nec.com 2003 12 01 [3] Gardarin G., Gannouni S., Finance B. A distributed system federating object and relational databases,

http://citeseer.nj.nec.com 2003 12 08 [4] Holtkamp B., Wu X., VHDBS: a federated database system for electronic commerce, http://citeseer.nj.nec.com 2003 12

10 [5] Paradauskas B., Salelionis L., Targamadzė A. Vaizdiniai federacinėse duomenų bazėse. Informacinės technologijos

2002, Konferencijos pranešimų medžiaga, Technologija, Kaunas, 2002, [6] Samos J., Saltor F., Sistac J., Bardes A. Database architecture for data warehousing: an evolutionary approach,

http://citeseer.nj.nec.com 2003 12 05 [7] Strassler M., Schonhoff M., Integrating engineering databases: how does the application domain influence the FDBMS

architecture ?, http://citeseer.nj.nec.com 2003 12 12

Federated databases

Federated information systems are integrating layer over existing legacy data sources. Information systems can be classified in three dimensions: degree of autonomy, heterogeneity and distribution, this classification leads us to definition of federated information system. There are ten more dimensions which apply to classification of federated information systems, they are discussed in article. Federated databases are federated information systems, which have global schema in federative layer and uses only databases as data sources. Their common architecture is composed of five levels and may be advanced to eight level architecture. The main federated databases problems, which must be solved, are schemas translation and integration, data access control, queries processing and optimization, global transactions management.

http://citeseer.nj.nec.com/






duomenų bazės ir modeliai - elibrary.lt...savo sudėtyje turi gis dalį, be to leidžia prijungti...

Documents