CC BY
83
UNIA EUROPEJSKA
EUROPEJSKI FUNDUSZ SPOtECZNY
mgr inz. Marcin Michaï MIRONCZUK
Politechnika Bialostocka Wydzial Elektryczny
SYSTEMY ZARZ^DZANIA BAZ^ DANYCH I ARCHITEKTURA AGENTOWA W SLUZBACH RATOWNICZYCH PANSTWOWEJ STRAZY POZARNEJ
Database management system and agent architecture into fire service
Praca naukowa wspolfinansowana ze srodkow Europejskiego Funduszu Spolecznego, srodkow Budzetu Panstwa oraz ze Srodkow Budzetu Wojewodztwa Podlaskiego w ramach projektu "Podlaska Strategia Innowacji
- budowa systemu wdrazania
Streszczenie
W artykule przedstawiono autorsk^ klasyfikacjç Systemow Zarz^dzania Baz^ Danych (SZBD) oraz opisano mozliwosc zastosowania architektury agentowej w sluzbach ratowniczych Panstwowej Strazy Pozarnej PSP. W pierwszej czçsci artykulu dokonano autorskiej klasyfikacji, przegl^du i opisu SZBD juz od pewnego czasu dobrze znanych i opisanych np. rozwi^zania katalogowe, relacyjne jak i aktualnie rozwijaj^cych siç np. rozwi^zania obiektowe, koncepcyjne czy tez oparte o rozszerzony jçzyk znacznikow (ang. extensible markup language - XML). Dotychczas zastosowanie samych baz danych i SZBD w sluzbach ratowniczych PSP jest mocno ograniczone. Zazwyczaj ich uzycie sprowadza siç do ewidencji i rejestracji zdarzen z ewentualnym minimalnym ich wsparciem od strony informacyjnej dla Kieruj^cego Dzialaniami Ratowniczymi KDR. Przedstawienie wiçc przekrojowej analizy SZBD daje mozliwosc szerszego spojrzenia na ewentualne zastosowania niektorych rozwi^zan w sluzbach ratowniczych, w szczegolnosci tych maj^cych na celu wspieranie akcji ratowniczo-gasniczych. W drugiej czçsci artykulu skupiono siç na wlasnie takim rozwi^zaniu. Przedstawiono w nim zarys systemu opartego o architekturç agentow^. Opisano podstawowe funkcje oraz sposob dzialania systemu opartego o tak^, architekturç. Na koncu dokonano podsumowania z wyszczegolnieniem technik i powstaj^cych problemow projektowych przy realizacji omawianej platformy.
Summary
This article describes a new approaches and classification of Database Management System DBMS. In this article also describe potential using of agent architecture into fire service. The first part of this article is a review of DBMS. In this section describes DBMS historically oldest solutions like a hierarchical database model, relational database model and describes the newest solutions like a object oriented database model, conceptual model or model base on extensible markup language - XML. Actually applying of DBMS in polish fire service is strongly limited. Usually their use moves to keep a record of fire service events. Eventually DBMS are used to the minimum support of decision-makers. The proposed review gives the wider glance on uses DBMS in rescue services. In the second part author describes a outline decision support system for fire service which based on agent data base management system. This section describes a system's functions and his way of working. The end the article consist of summary where author describes techniques and problems appears in project cycle of agent based platform.
Slowa kluczowe: systemy zarz^dzania baz^ danych, SZBD, architektura agentowa, programowanie agentowe, projektowanie agentowe, przegl^d systemów zarz^dzania baz^. danych
Keywords: Data base management system, agent architecture, agent programming, agent architecture, review of data base management system
1. Wst^p
W obecnych Systemach Zarz^dzania Baz^ Danych (SZBD) termin „dane" moze bye definiowany, w zaleznosci od stopnia zlozonosci, rodzaju i typu skladowanych w nich tresci, na trzy sposoby [1-3]:
Definicja 1. Szcz^tkowe, nieuporz^dkowane sygnaly, ktore mog^. pochodzie ze zrodel pierwotnych albo wtornych, tworzonych wewn^trz jak i na zewn^trz organizacji
Definicja 2. Synonim slowa „informacja" okreslaj^cy w ten sposob rezultat integrowania i porz^dkowania danych, ktore w ten sposob nabieraj^ znaczenia
Definicja 3. Wyrazenie rownoznaczne dla wiedzy - informacji wartosciowej i zaakceptowanej, integruj^cej dane, fakty i informacje. Wiedza moze bye dost^pna oraz ukryta. Wiedza dost^pna jest wiedzy spisan^, skodyfikowan^, ogolnie dost^pn^. przez wszystkich, ktorzy s^. ni^ zainteresowani. Wiedza ukryta jest natomiast wiedzy indywidualn^, specyficzn^, znan^. tylko jej posiadaczowi (decydentowi), trudn^. do sformalizowania.
Traktowanie danych w SZBD wedlug pierwszej definicji nie ma praktycznego znaczenia, ze wzglçdu na to, iz w systemie przechowujemy z reguly juz w pewien sposob uporzidkowani informacjç. Definicja 2. odzwierciedla dzisiejsze (czas w jakim powstalo niniejsze opracowanie) podejscia do danych zebranych w roznego rodzaju SZBD. Definicja 3. nawiizuje natomiast do aktualnie budowanych i badanych Systemow Zarzidzania Wiedzi. W dalszej czçsci tego tekstu, pod nazwi SZBD bçdi rozumiane systemy zarzidzania informacji jak i wiedzi. Aktualnie, jesli SZBD rozpatrywane si w kontekscie zarzidzania wiedzi, mozna spotkac gamç roznorodnych terminow, ktore na poziomie semantycznym si synonimami. Do grupy tych terminow nalez^: System Zarzidzania Bazi Informacji SZBI lub System Zarzidzania Informacji SZI oraz System Zarzidzania Bazi Wiedzy SZBW lub System Zarzidzania Wiedzy SZW.
Na potrzeby badan nad zastosowaniem (SZBD) w sluzbach ratowniczych Panstwowej Strazy Pozarnej (PSP) budowany byl system o roboczej nazwie FINE (Fine it's not EWID), ktorego celem mialo byc uzupelnienie o potrzebne funkcje oprogramowania dostarczanego przez firmç Abakus o nazwie EWID 9x (EWID99 lub EWID 93) [4, 5]. Kontynuacjç i rozszerzenie tych badan stanowic ma platforma Hybrydowego Inteligentnego Systemu Wspomagania Decyzji (HSWD), oparta o katalogowi lub obiektowi, rozproszoni bazç danych. HSWD koncepcyjnie stanowi System Zarzidzania Bazi Wiedzy o architekturze rozproszonej z wnioskowaniem na podstawie przypadkow CBR [6-9]. Rownolegle prowadzone si takze badania nad przechowywaniem i pozyskiwaniem, potrzebnych atrybutow do przestrzennej bazy przeciwpozarowej GIS [10]. Wyniki z tych badan mogi zostac wykorzystane do budowy systemu oraz wniesc dodatkowi wiedzç na temat reprezentowania i tworzenia formalnych raportow w planowanym systemie, ktore mozna by bylo w latwy i efektywny sposob przetwarzac (wyszukiwac, zapisywac) w wybranym typie -rozproszonym, zcentralizowanym - zarzidzania bazi danych [6, 10-12]. Rozpatrywane jest takze wykorzystanie, obok katalogowej bazy, natywnej bazy XML, jako bazy wiedzy, w ktorej bçdzie mozna przechowywac i wydobywac opis ontologiczny poszczegolnych przypadkow. Rozwiizanie to zostalo zaproponowane ze wzglçdu na to, iz baza natywna XML moze przechowywac bogaty opis semantyczny zdarzen i akcji ratowniczo-gasniczych, w ktorych biori udzial sily i srodki sluzb ratowniczych PSP [8, 13].
Jak widac w zespole badawczym operuje siç duzi iloscii terminologii i pojçc z zakresu SZBD. W zwiizku z tym, w celu zachowania przejrzystosci komunikacji i zrozumienia pomiçdzy czlonkami zespolu badawczego, powstala idea utworzenia formalnego slownika pojçc, ktorymi mozna operowac w kontekscie SZBD. W wyniku jego
tworzenia, powstala prezentowana w artykule klasyfikacja SZBD wraz z omówieniem konkretnego zastosowania polegaj^cego na wykorzystaniu architektury agentowej.
W pierwszej cz?sci artykulu (rozdzial 2) autor przedstawil klasyfikacja i przegl^d SZBD ze szczególnym naciskiem na opis nowych trendów, poj?c i rozwi^zañ w dziedzinie baz danych. W drugiej cz?sci artykulu (rozdzial 3) autor opisal zarys mozliwosci wykorzystania architektury agentowej do rozwi^zywania problemów: decyzyjnych pojawiaj^cych si? podczas akcji ratowniczo-gasniczych oraz analitycznych.
2. Klasyfikacja i przegl^d Systemów Zarz^dzania Baz^ Danych
Klasyfikacja i zarazem przegl^d opisowy SZBD powstal na podstawie analizy dost?pnej dla autora literatury opisuj^cej zagadnienia zwi^zane z ogólnie poj?tymi SZBD [11, 14-19]. Klasyfikacja t? przedstawia Rycina 1.
Ryc. 1 Klasyfikacja wspólczesnych SZBD
Zródlo: Opracowanie wlasne
Ryc. 1. przedstawia diagram autorskiego podzialu wspólczesnych SZBD w zaleznosci od ich: architektury (podrozdzial 2.1), modelu danych (podrozdzial 2.2), liczby w?zlów (podrozdzial 2.3), rodzaju warstwy przetwarzania danych (podrozdzial 2.4) i aktywnosci
(podrozdzial 2.5). Poszczegolne galçzie i liscie ww. kategorii zostaly rozwiniçte i omowione w dalszych sekcjach niniejszego artykulu.
2.1. Architektura Systemow Zarzidzania Bazq Danych
Architektura ZSBD rozumiana jest jako specyfikacja procesu komunikacji, ktory zawiera przetwarzanie i przesylanie danych, informacji oraz wiedzy w obrçbie systemu informacyjnego, pomiçdzy jego poszczegolnymi jednostkami skladowymi [20]. Do architektury SZBD zaliczamy rozwiizania komunikacji typu: klient-serwer (podrozdzial
2.1.1), bezserwerowa (podrozdzial 2.1.2) oraz agentowa (podrozdzial 2.1.3).
2.1.1. Architektura klient-serwer
Architektura klient-serwer (ang. client-server) jest to architektura aplikacji, w ktorej przetwarzanie jest podzielone miçdzy maszynami (procesami) dzialajicymi jako klienci i maszynami dzialajicymi jako serwery np. aplikacji lub baz danych [15]. Klienci pozyskuji zasoby informacji poprzez proces komunikacji z serwerem, na ktorym si one skladowane. Klient ma mozliwosc pozyskiwania informacji z jednego (architektura scentralizowana -podpunkt 2.3.1) lub wielu serwerow jednoczesnie (architektura rozproszona - podpunkt
2.3.2). Architektura oprogramowania klient-serwer rozdziela funkcjonalnosc oraz odciiza system, tym samym zwiçkszajic jego elastycznosc. Ulatwia ona przy tym wprowadzanie zmian w rozne czçsci tego systemu. Nie ma wymagan formalnych odnosnie lokalizacji obu procesow, teoretycznie mogi one znajdowac siç na jednym komputerze (baza lokalna). W praktyce jednak serwer umieszczany jest na innym komputerze niz procesy klienta, a komunikacja odbywa siç poprzez siec (model dwuwarstwowy przetwarzania danych). Mozliwa jest rowniez sytuacja, w ktorej serwer baz danych udostçpnia dane klientom bezposrednio lub posrednio przez inny serwer posredniczicy (np. serwer WWW lub aplikacji). Wowczas architektura taka nazywana jest architekturi klient-serwer trzy lub wielowarstwowi (wielowymiarowi).
Glowni roli klienta jest: dostarczenie graficznego lub tekstowego interfejsu uzytkownika do komunikacji z bazi danych, akceptowanie i kontrola syntaktyki zgloszen uzytkownika do systemu, generowanie zapytan do bazy danych i transmisja ich do serwera oraz odbieranie odpowiedzi od systemu bazy danych. Natomiast do glownych rol serwera nalezi: akceptowanie i realizacja zidan klienta do bazy danych, kontrola autoryzacji, kontrola wiçzow integralnosci, wykonywanie zapytan i transmisja odpowiedzi do klienta, obsluga
katalogu systemowego, sterowanie prac^ wspólbiezn^. oraz sterowanie odtwarzaniem stanu bazy danych.
Do zalet architektury rozproszonej (ang. distributed system) klient-serwer mozna zaliczyc m.in. to, ze [б, 12]: umozliwia szeroki dostçp do istniej^cych baz danych, poprawia wspólczynnik przetwarzania (chociazby przez fakt rezydowania na róznych komputerach serwera i klienta), umozliwia pracç równolegl^. aplikacji, co w pewnym zakresie redukuje koszty sprzçtu (maszyna, na której posadowiony jest serwer, musi byc komputerem o dobrych parametrach, w odniesieniu do stacji klienckich wymagania nie s^. az tak wysokie), zmniejsza koszty komunikacji w sieci (czçsc przetwarzania odbywa siç po stronie klienta, serwer przesyla z bazy tylko dane wynikowe), zwiçksza spójnosci i bezpieczenstwa bazy danych (serwer kontroluje wiçzy integralnosci, a wiçc s^. one obowi^zuj^ce dla wszystkich pracuj^cych aplikacji). Za wadç uznaje siç [б]: zlozonosc i skomplikowanie oprogramowania, zaleznosc od jakosci i architektury sieci, mniejsze bezpieczenstwo i odpornosc na blçdy.
2.1.2. Architektura bezserwerowa
Architektura bezserwerowa wystçpuje wówczas, kiedy stosowanie procesu serwera nie jest konieczne. Istniej^. bazy danych, które nie musz^ byc wspóldzielone przez wielu uzytkowników w tym samym czasie. W tym celu uzywane s^. bezserwerowe bazy danych, które instalowane s^. na maszynie klienta i do których tylko on ma dostçp w ramach uzywanych przez niego aplikacji.
2.1.3 Architektura agentowa
Architektur^ agentow^, w kontekscie systemów zarz^dzania bazami danych, mozna traktowac jako czçsc architektury typu klient-serwer. Niemniej zostala ona przydzielona do osobnej galçzi klasyfikacji z tego wzglçdu, ze w stosunku do architektury i rozwi^zañ typu klient-serwer jest w dalszym ci^gu, od jej powstania w 1994 roku malo rozpropagowana i implementowana. Rozwi^zañ technologicznych opartych na agentach i metodologii tworzenia oprogramowania agentowego nie l^czy siç aktualnie bezposrednio z bazami danych i systemami ich zarz^dzania. Do takiego pol^czenie i wyodrçbnienia galçzi powinno jednak dojsc poniewaz agenci czerpi^. dane do swego dzialania z SZBD poprzez komunikacjç z warstw^. aplikacji do ich obslugi. Zachodzi wiçc proces komunikacji z innym komputerem, który jest jednym z wyrózników podejscia agentowego [21]. Agent powolywany jest do zycia po to, aby dostarczyc informacji lub wiedzy klientowi, który go wywolal, na zadany przez niego temat. Tak wiçc jednym z elementów agenta jest zdolnosc do komunikowania siç
z istniejicymi systemami obslugujicymi zródla danych czy tez wiedzy. Policzenie elementu dotyczicego tego, iz agent moze wspólpracowae z warstwi aplikacji obslugujici SZBD oraz moze sam przenosie siç miedzy systemami, stal siç czynnikiem dostatecznym do wydzielenia nowego liscia w opisywanej klasyfikacji. Dodatkowo w architekturze agentowej, aplikacja klienta czy tez serwer aplikacji klienta nie musi podtrzymywae policzenia ze zródlem danych i oczekiwae zwrotu informacji. Moze ona natomiast odpytywae czy agent wrócil z poszukiwani informacji lub tez zostae powiadomiona o jego powrocie.
Do tej pory nie powstala jedna zwarta definicja agenta, z tego wzglçdu ponizej zostaly przytoczone dwie definicje najlepiej pasujice do kontekstu SZBD [2l]:
Definicja 1. Jednostki programowe podejmujice dzialania w imieniu uzytkownika lub innych programów, w pewnym stopniu niezalezne lub autonomiczne, które dzialajic stosuji pewni wiedzç lub reprezentacjç celów.
Definicja 2. Zamkniçty system komputerowy znajdujicy siç w pewnym otoczeniu, posiadajicy umiejçtnosé elastycznego dzialania w tymze otoczeniu, polegajicego na wypelnianiu celów dla jakich zostal stworzony.
Wspólni cechi definicji jest to, iz agent stosuje pewni swoji wiedzç o tym, jak rozwiizae zadany problem i gdzie szukae ewentualnych danych. Podczas swego dzialania moze on kontaktowae siç z innymi agentami i systemami. Z tego wzglçdu agentom, jak i systemom agentowym, przypisuje siç pewne cechy, np. [22]: proaktywnose (ang. proactivity), kooperatywnose (ang. cooperavity) czy tez adaptywnose (ang. adapivity). Natomiast w zaleznosci od zastosowan agentów mozna wyróznie ich trzy grupy [2l]: agenci do zarzidzania i przetwarzania informacji stosowani np. w przetwarzaniu obrazów [2З, 24], negocjacji cen [25], grach [26] etc.; agenci w systemach rozproszonych np. róznego rodzaju boty internetowe; agenci modelujicy systemy zlozone. W zastosowaniach najczçsciej mamy do czynienie z systemami mieszanymi, nie dajicymi siç w latwy i przejrzysty sposób zakwalifikowae do jednej z trzech wymienionych grup.
2.2. Model danych Systemów Zarzidzania Bazi Danych
Przez model danych rozumiana jest architektura danych oraz zintegrowany zbiór wymagan w odniesieniu do danych [l5]. Jako model danych (a w odniesieniu do konkretnej realizacji mówi siç czçsto o architekturze systemu baz danych) mozna tez rozumiee zbiór ogólnych zasad poslugiwania siç danymi. W latach szesedziesiitych i siedemdziesiitych XX wieku ujrzalo swiatlo dzienne wiele pomyslów dotyczicych rozwiizania problemu zarzidzania powtarzaj icymi siç danymi. W wyniku róznych eksperymentów powstalo kilka
modeli systemow baz danych. Sam problem magazynowania danych i szybkiego dostçpu do nich istnial juz znacznie wczesniej, jednakze rozwiizywany byl przy pomocy bardzo prymitywnych pomyslow i jçzykow programowania [14]. Model danych sklada siç z takich podkategorii modeli, jak: prosty model danych (podrozdzial 2.2.1), zlozony model danych (podrozdzial 2.2.2) oraz model silnie semantyczny utozsamiany i stosowany w systemach zarzidzania bazi wiedzy (podrozdzial 2.2.3).
2.2.1. Prosty model danych
W prostym modelu danych, dane reprezentowane si za pomoci rekordow zgrupowanych w strukturach plikow. W tym przypadku dostçpnymi operacjami na rekordach si: odczyt i zapis rekordu [15]. Do prostego modelu danych zaliczane si: model pliku plaskiego, model hierarchiczny oraz model sieciowy, ktore zostaly omowione ponizej. Model pliku plaskiego
Model pliku plaskiego, nazywany inaczej modelem kartotekowym (kartotekowe bazy danych, ang. flat file database), ,model ten stanowi najprostszi organizacjç bazy danych. Informacje w tym modelu przechowywane si w jednym plaskim pliku lub ich zbiorze -kartotece. Pliki nie si policzone ze sobi w zaden sposob, a ich interpretacja dokonywana jest poprzez zewnçtrzni aplikacjç [11]. Model hierarchiczny
Model hierarchiczny przypomina obecny schemat zapisu systemu plikow. Zaklada, ze zwiizki pomiçdzy danymi mogi zachodzic tylko typu jeden do wielu (1:N) tj. rekord typu ojciec moze posiadac wiele powiizan z rekordami typu syn [11]. Do operowania i przetwarzania danych w tym modelu uzywa siç funkcji wbudowanych w bazç danych, napisanych w wybranym jçzyku programowania (w tak zwanym jçzyku gospodarza). Integralnosc danych jest przestrzegana poprzez kontrolç nastçpujicych wiçzow: rekordu podrzçdnego nie mozna wstawic dopoki nie zostanie powiizany on z rekordem nadrzçdnym, skasowanie rekordu nadrzçdnego powoduje usuniçcie wszystkich powiizanych z nim rekordow podrzçdnych (dzieci), jezeli podrzçdny typ rekordu ma zwiizane dwa lub wiçcej nadrzçdnych typow rekordow, to rekord podrzçdny musi zostac powielony dla kazdego rekordu podrzçdnego [15]. Model sieciowy
Model sieciowy, w przeciwienstwie do modelu hierarchicznego, zakladal, ze mogi istniec zwiizki miçdzy danymi typu wiele do wielu (N:N) [11]. Pod wzglçdem historycznym sieciowy model danych jest uwazany za nastçpcç modelu hierarchicznego. Do operowania
i przetwarzania danych w tym modelu, tak jak w modelu hierarchicznym, uzywa siç funkcji napisanych w wybranym jçzyku programowania. Wazne jest przy tym, aby pamiçtac, ze jçzyk programowania gospodarza i system bazy danych to dwa oddzielne systemy oprogramowania, ktôre l^czy siç poprzez wspôlny interfejs programowania aplikacji (ang. application programming interface - API). Integralnosc w modelu sieciowym dotyczy glôwnie okreslenia czlonkostwa w kolekcji i trybu wstawiania [15].
2.2.2. ZIozony model baz danych
W przeciwienstwie do prostych modeli danych, modele zlozone najczçsciej traktuj^. dane w sposôb zdyscyplinowany poprzez uzycie scislych narzçdzi matematycznych np. teorii zbiorôw do poslugiwania siç danymi w przypadku modelu relacyjnego. Ponadto istnieje duza niezaleznosc pomiçdzy programami operjcymi na danych, a danymi skladowanych w bazie danych. Dane w tym modelu mog^. przybierac tez inny niz tekstowy charakter np. binarny w przypadku baz multimedialnych lub obiektôw w przypadku baz obiektowych etc. Do zlozonego modelu danych zaliczane s^.: model relacyjny, model obiektowy, model strumieniowy, model relacyjno-obiektowy, model temporalny, model multimedialny, model natywny, model mobilny oraz model hurtowni danych. Wszystkie ww. modele zostaly opisane ponizej. Model relacyjny
Model relacyjny zostal opracowany przez E. F. Codda w latach 70-80 [27] i od mniej wiçcej polowy lat osiemdziesi^tych stal siç podstaw^. architektury wiçkszosci popularnych systemôw baz danych. Podstawow^. struktur^, danych w tym modelu jest relacja. W bazach danych relacja przedstawiana jest w postaci tabeli. Relacja jest zbiorem rekordôw, z ktôrych kazdy ma tak^, sam^, struktur^, lecz rôzne wartosci. Kazdy rekord odpowiada jednemu wierszowi tablicy. Kazdy wiersz (rekord) musi posiadac co najmniej jeden atrybut, odpowiadaj^cy jednej kolumnie tablicy. Caly model relacyjny bazuje na dwôch galçziach matematyki - teorii mnogosci (zbiorôw) oraz rachunku predykatôw pierwszego rzçdu [28]. Wykorzystanie formalnej matematycznej struktury relacyjnej wplynçlo na sukces relacyjnych baz i pozwolilo m.in. na [11]: przeprowadzanie automatycznego sprawdzania konstrukcji, zagwarantowalo wykonalnosc operacji i spôjnosc zbiorôw danych oraz, najwazniejsze, - dalo mozliwosc zadawania dowolnych zapytan wyrazanych w strukturalnym jçzyku zapytan (ang. structured query language - SQL) [29] przez uzytkownikôw, a nie tylko zdefiniowanych przez projektantôw systemôw opartych o bazy danych.
Relacyjny model danych jest wydajniejszy od wczesniej omawianych prostych modeli np. plikow tekstowych. W przeciwienstwie do modeli prostych, w bazach relacyjnych pola si okreslonego typu, dlatego mozna w nich latwo przechowywac teksty, liczby, daty czy tez wartosci binarne Dziçki wykorzystaniu jçzyka SQL obsluga relacyjnych baz danych stala siç prosta i wszechstronna. Dziçki jçzykowi SQL w relacyjnych bazach danych kolejnosc rekordow przestala miec jakiekolwiek znaczenia, poniewaz jçzyk SQL umozliwil nie tylko wybranie rekordow, aktualizacje i wstawianie, ale rowniez ich sortowanie (funkcja manipulacji danymi, ang. data manipulation language - DML). SQL oprocz manipulowania danymi umozliwia takze wprowadzanie zmiany danych w bazie i jej strukturze (funkcja opisu danych, ang. data definition language - DDL).
Systemy bazodanowe do zarzidzania danymi opartymi o model relacyjny okreslane si jako - Relacyjny System Zarzidzania Bazi Danych RSZBD (ang. relational database managament system - RDBMS). Model obiektowy
Termin obiektowy w dzisiejszej informatyce ma wiele roznych znaczen. Po raz pierwszy zostal on zastosowany przez tworcç paradygmatu obiektowego Norwega Kristena Nygarrda i odnosil siç do pierwszego obiektowego jçzyka programowania Simula, a potem do ich calej grupy np. Smalltak, Java, C++. Od niedawna terminem tym operuje siç w dziedzinie baz danych. Zasadniczi roznici miçdzy obiektowymi jçzykami programowania a obiektowymi bazami danych jest to, ze te pierwsze nie wymagaji skladowania i operacji na trwalych obiektach tj. obiekty programowe istnieji tylko w czasie wykonywania programu. W obiektowych bazach danych natomiast mamy do czynienia z tym, iz obiekty zostaji zapisane w sposob trwaly w pamiçci pomocniczej przed i po wykonaniu programu [15].
Obiektowe bazy danych nie stanowily rozszerzenia oraz nie byly ewolucji baz relacyjnych, staly siç natomiast dla nich alternatywi. Relacyjne bazy danych w przeciwienstwie do obiektowych baz si ubozsze semantycznie tj. do dyspozycji uzytkownik dostaje ograniczoni ilosc typow danych (tekst, data, liczby, wspolrzçdne przestrzenne) oraz nie sprawdzaji siç w pewnych zastosowaniach np. w modelowaniu zagniezdzen wielopoziomowych. Ponadto model relacyjny zapewnia slabi reprezentacjç modelowanej dziedziny wynikajici z podzialu encji lub klas na liczne relacje w procesie denormalizacji [15, 30]. Zasadniczi roznici miedzy modelami jest to, iz w tradycyjnych bazach relacyjnych, dane oraz procedury operujice na tych danych si przechowywane oddzielnie (dane i relacje w bazie natomiast procedury w programie uzytkownika) [11]. W przypadku modelu obiektowego dane w postaci skladowych i procedury w postaci metod
sy skladowane i hermetyzowane [31] w jednym miejscu - obiekcie przechowywanym w bazie. Otrzymujemy wiçc w pelni semantyczny model danych, w którym z jednej strony mamy reprezentacjç danych za pomocy klas i skladowych, natomiast z drugie strony otrzymujemy mechanizm do operowania na nich za pomocy metod.
Branze stosujyce systemy z obiektowymi bazami danych to przede wszystkim [32, 33]: badania naukowe, transport, komunikacja, wydawnictwo, rozwój oprogramowania, lotnictwo, consulting, finanse, bankowosc, zdrowie, medycyna, produkcja. Systemy bazodanowe do zarzydzania danymi opartymi o model obiektowy okreslane sy jako -Obiektowy System Zarzydzania Bazy Danych OSZBD (ang. object-oriented database management system - OODBMS) lub (ang. object database management system - ODBMS). Model strumieniowy
W modelu strumieniowym dane sy przedstawione w postaci zbioru strumieni danych, w czasie rzeczywistym ciyglego, uporzydkowanego, naplywajycego ciygu elementów (zdarzen) w postaci danych do bazy [34]. W konwencjonalnym, relacyjnym modelu danych, sy one modyfikowane w zbiorze danych jedynie na zydanie uzytkownika. W swiecie rzeczywistym istniejq, jednak zjawiska, których próba opisu poprzez model relacyjny konczy siç w praktyce niepowodzeniem. Zwiyzane jest to zazwyczaj z nieuwzglçdnieniem ciyglego i nieograniczonego w czasie i z czasem lawinowego naplywu danych [34]. W zwiyzku z tymi i innymi ograniczeniami modelu relacyjnego [35] oraz w celu ich zniesienia powstala nowa koncepcja modelu i realizujycego go systemu zarzydzania danymi. Model ten jest oparty na aktywnej bazie danych (ang. database active human passive - DAHP). Do manipulacji danymi w DAHP wykorzystywany i implementowany jest jçzyk ciyglych zapytan oparty na SQL-u [3б]. Prowadzone sy róznego rodzaju prace nad przedstawieniem rozwiyzania uniwersalnego w postaci kompleksowego Systemu Zarzydzania Strumieniowy Bazy Danych SZSBD (ang. data stream management system - DSMS), który sluzy do zarzydzania danymi opartymi o model strumieniowy. Aktualnie rozwijanymi projektami z zakresu strumieniowych baz danych sy [37-43]: Niagara, STREAM, Telegrach, OpenCQ, Hancock, MEDUSA, AURORA. Model relacyjno-obiektowy
Model relacyjno-obiektowy (post relacyjny) umozliwia manipulowanie danymi jako zestawem obiektów, przy zachowaniu bazy relacyjnej z wewnçtrznym mechanizmem przechowywania danych. Model relacyjno-obiektowy jest pierwszym modelem post relacyjnym, który rozszerza i uzupelnia braki m.in. ograniczony ilosc typów danych, wystçpujycych w modelu relacyjnym. Badaniami, które przyczynily siç do powstania tej
nowej grupy modeli i zwiizanych z nimi systemow zarzidzania bazami danych, staly siç badania Michaela Stonebrakera [11]. W odroznieniu od relacyjnego modelu danych nowe systemy posiadaly dodatkowe mozliwosci w postaci [44]: obslugi rozszerzonych abstrakcyjnych typow danych (ang. abstract data types - ATD) definiowanych przez uzytkownikow, obslugi obiektow przez ustrukturyzowany jçzyk zapytan SQL i jego rozszerzenie w postaci obiektowego jçzyka zapytan (ang. object query language - OQL) umozliwiajice realizacjç mocnej kontroli typow czy dziedziczenia [45]. Wprowadzono tez tzw. wyzwalacze czyli procedury uruchamiane automatycznie w przypadku zaistnienia zdefiniowanych przypadkow. Mechanizm ten w dzisiejszych relacyjnych systemach baz danych jest powszechnie uzywany i stosowany.
Systemy do zarzidzania danymi relacyjno-obiektowymi okreslane si jako Relacyjno-Obiektowych Systemow Zarzidzania Bazi Danych ROSZBD (ang. object relational database management system - ORDBMS). Model temporalny
Model temporalny stanowi odmianç modelu relacyjnego i strumieniowego z tego wzglçdu, ze kazdy rekord posiada stempel czasowy, okreslajicy czas, w jakim wartosc jest prawdziwa. Tak wiçc oprocz danych „wlasciwych" dla danej modelowanej dziedziny przechowuje siç tez czas waznosci tych danych z czasem transakcji. Czas waznosci jest to czas kiedy zdarzenie (fakt) reprezentowane przez dane „wlasciwe" mialo miejsce w opisywanej przez bazç rzeczywistosci, zas czas transakcji to czas kiedy dane si przechowywane w bazie danych (okres od ich wprowadzenia do ewentualnego usuniçcia) [46, 47]. Jçzykiem zapytan do bazy danych opartej o model temporalny jest jçzyk logiki temporalnej I rzçdu [46] lub temporalny strukturalny jçzyk zapytan (ang. temporal query language - TSQL2) [48]. Oba podejscia bazuji na algebrze relacyjnej i posiadaji operatory algebry relacyjnej, ktore pozwalaji operowac na danych temporalnych (wyciigac historic).
System obslugi baz danych oparty na modelu temporalnym znajduje zastosowanie przy tworzeniu: aplikacji finansowych, aplikacji ubezpieczeniowych, systemow rezerwacji hoteli/biletow, systemow zarzidzania danymi medycznymi, systemow wspierania decyzji. Przykladowymi temporalnymi bazami danych si m.in. TimeDB i Tiger [49, 50]. Model multimedialny
System zarzidzania bazi danych oparty o model multimedialny umozliwia skladowanie i analizç informacji w postaci obrazow, dzwiçkow, nagran wideo i tekstu. Do podstawowych funkcji, ktore system ten powinien zawierac, nalezi m.in.: [51, 52]: rozwijanie formalnych technik modelowania semantycznego dla informacji multimedialnych
w szczególnosci dla danych wideo i obrazów, projektowanie elastycznych i mocnych metod indeksowania, wyszukiwania i organizowania danych multimedialnych, rozwijanie modelu przystosowanego do spelnienia wymagan takich, jak synchronizacja i integracja danych, implementacja i rozwijanie formalnego multimedialnego jçzyka zapytan (ang. multimedia query languages - MQL), rozwijanie efektywnego skladowania baz danych na fizycznych nosnikach danych, projektowanie i rozwijanie uzytecznej architektury i wspierajycych ich systemów operacyjnych, zarzydzanie rozproszonymi danymi multimedialnymi.
Systemy zarzydzania multimedialnymi bazami danych SZMBD (ang. multimedia database management system - MMDBMS) budowane sy najczçsciej na bazie relacyjnych i relacyjno-obiektowych modeli lub ich systemów zarzydzania, do których wprowadza siç rozszerzenia multimedialne [51]. Powód stosowania relacyjnych, relacyjno-obiektowych systemów a nie specjalizowanych (dedykowanych) systemów tworzonych od podstaw nie jest przypadkowy. Liczba plików multimedialnych skladowanych w takich systemach aktualnie siçga kilkudziesiçciu milionów. Bioryc pod uwagç wyszukiwanie jedynie informacji alfanumerycznych w takich zbiorach, mozliwosci wydajnosciowe przytaczanych SZBD sy wystarczajyce [53]. Model natywny
Baza danych z natywnym modelem rozszerzalnego jçzyka znaczników (ang. extensible markup language - XML) pozwala na przechowywanie danych wewnytrz bazy w postaci dokumentów XML [54]. Taki sposób zapisu ma duze znaczenie ze wzglçdu na popularnosc metajçzyka XML w wielu zastosowaniach, co wiyze siç z jego bogaty semantyky, a wiçc i mozliwosciy do elastycznego i wszechstronnego modelowania róznych zjawisk i zaleznosci. Systemy obslugi baz danych oparte na modelu XML noszy nazwç -Native XML Database Systems. Nazywane sy takze semistrukturalnymi systemami zarzydzania bazy danych. Informacje w tego rodzaju systemach sy przetwarzane za pomocy zapytan wyrazonych w jçzyku sciezek rozszerzalnego jçzyka znaczników (ang. XML path language - XPath) lub w jçzyku zapytan rozszerzalnego jçzyka znaczników (ang. XML query language - Xquery) [55]. Prezentacja tresci i jej ewentualne transformacje odbywajy siç za pomocy przeksztalcenia rozszerzalnego jçzyka arkuszy stylów (ang. extensible stylesheet language transformations - XSLT). Model mobilny
Model mobilny skladaja siç z przenosnych baz danych, które sy fizycznie odseparowane od serwera scentralizowanej bazy danych. Bazy zaprojektowane w oparciu o ten model majy mozliwosc komunikacji z serwerem z odleglych lokalizacji. Dziçki temu pozwalajy one na
wspoldzielenie danych organizacji. Rozwoj tych baz jest nastçpstwem rozwoju komunikacji bezprzewodowej [28]. Model hurtowni danych
Hurtownie danych (ang. data warehause) nazywane takze magazynami danych, si tematycznie zorientowanymi podmiotowo, zintegrowanymi, zroznicowanymi czasowo trwalymi kolekcjami danych przeznaczonych do wspomagania procesu podejmowania decyzji [28]. W hurtowniach danych, w przeciwienstwie do np. relacyjnych baz danych, wykorzystywana jest warstwa przetwarzania analitycznego (ang. on-line analytical processing - OLAP) a nie transakcyjnego (ang. on-line transaction processing - OLTP). (podpunkt 2.4.1 i 2.4.2). Aktualnie wysuwane si postulaty projektowania i tworzenia tzw. aktywnych hurtowni danych (ang. active data warehouse) liczicych i wykorzystuj icych obie warstwy przetwarzania analitycznego (OLAP) i transakcyjnego (OLTP) [56]. Postulaty te wysuwane si ze wzglçdu na to, ze procesy decyzyjne wymagaji zazwyczaj oczyszczonych i odpowiednio przetransformowanych danych np. o roznego rodzaju trendach, ktore z natury zastosowan relacyjnego operacyjnego modelu mogi nie byc tam przechowywane.
Hurtownie danych mozna podzielic na dwa rodzaje. Podzial jest uwarunkowany wykorzystaniem przez nie modelu danych. Pierwszi grupç stanowii magazyny danych wykorzystuj ice model relacyjny, w ktorych warstwç przetwarzania danych okresla siç jako relacyjny OLAP (ang. relational OLAP - ROLAP). Hurtownie danych typu relacyjnego budowane si wedlug dwoch schematow: gwiazdy (ang. star schema) i platka sniegu (ang. snowflake schema). Drugi grupç stanowii magazyny danych wykorzystuj ice wielowymiarowy model danych, w ktorych warstwç przetwarzania okresla siç jako wielowymiarowy OLAP (ang. multidimensional OLAP - MOLAP). Hurtownie danych wykorzystuj ice wielowymiarowy model budowane si wedlug schematu wielowymiarowej tablicy (ang. multidimensional array) [17].
Drugim wyznacznikiem podzialu w przypadku hurtowni danych moze byc ich architektura przestrzenna (lokalizacja i liczba hurtowni). Mogi one wystçpowac w architekturze scentralizowanej lub sfederowanej tj. dane si zorganizowane logicznie, lecz fizycznie si przechowywane w osobnych bazach danych (magazynach danych) [17, 57]. 2.2.3. Model silnie semantyczny
Model silnie semantyczny okreslany jest takze jako model wiedzy zarzidzany przez systemy zarzidzania bazi wiedzy. Model semantyczny umozliwia modelowanie, przetwarzanie i operowanie na modelach zawieraj icych glçboki, bogati semantykç. Systemy
te oferujy notacjç o duzej ekspresji sluzycy do reprezentowania faktôw, wiçzôw integralnosci, zapytan i funkcji modyfikacji [15].
Do grupy modeli silnie semantycznych nalezy: dedukcyjny model danych (ang. deductive database system - DDS) oraz model zorientowany koncepcyjnie nazywanym takze modelem zorientowany na pojçcia (ang. concept oriented model - COM). Dedukcyjny model danych
Dedukcyjny model danych (ang. deductive database system - DDS) zwiyzany jest z systemami ekspertowymi lub regulowo-modelowymi systemami ekspertowymi [2, 58]. Model ten obejmuje zastosowanie logiki formalnej do definiowania oraz operowania na danych i utrzymania ich integralnosci. Logika odgrywa tutaj rolç formalnych podstaw wyrazania, w jednolity sposôb, pewnej liczby tych trzech aspektôw technologii baz danych. Rozszerza ona rôwniez pojçcia konwencjonalnej bazy danych o narzçdzia dedukcyjne [15]. Pierwsze badania nad zastosowaniem i zwiyzkiem logiki formalnej z bazami danych siçgajy pôznych lat siedemdziesiytych. Obecnie w modelach dedukcyjnych baz danych jako jçzyk „zapytan" operacyjny uzywa siç Datalogu bçdycego pochodny jçzyka Prolog uzywanego w zagadnieniach sztucznej inteligencji (ang. artificial intelligence - AI) [59]. Model zorientowany koncepcyjnie
Model zorientowany koncepcyjnie lub model zorientowany na pojçcia (ang. concept oriented model - COM) zaproponowany zostal przez Alexandra Savinova w 2004 [60]. Model ten stanowi nowe podejscie do modelowania danych i bazuje na trzech glôwnych zasadach [61, 62]: zasadzie dwoistosci (ang. duality principle) môwiycej, ze kazdemu elementowi (pojçciu) przypisana jest tozsamosc (ang. identity ) oraz encja (ang. entity), zasadzie wlyczenia (ang. inclusion principle) dotyczycej uzywania hierarchicznej struktury dla modelowania tozsamosci oraz zasadzie porzydku (ang. order principle), ktôra môwi
0 uzywaniu matematycznej zasady porzydku czçsciowego (ang. partial order) do reprezentowania semantyki danych.
Glôwnym celem nowo powstalego modelu opartego o ww. zasady jest dostarczenie prostego i efektywnego sposobu do reprezentacji i manipulacji wielowymiarowymi
1 hierarchicznymi danymi z zachowaniem mozliwosci do reprezentowania danych fizycznie [63]. Odrôzniajycym go elementami od innych modeli jest to, iz bazuje na teorii porzydku zbiorôw (ang. order theory set), w szczegôlnosci na matematycznej zasadzie porzydku. W duzej mierze COM zostal zainspirowany przez teorie sieci (ang. lattice theory) [64] i formalny analizç pojçc (ang. formal concept analysis - FCA) [65] wprowadzony (po raz pierwszy uzyte pojçcie) przez Rudolfa Willea w 1984 roku a zbudowany na teorii sieci
i czçsciowego porzidku, ktore zostaly rozwiniçte przez Birkhoff i innych w latach 30 XIX wieku. Podobienstwo miçdzy COM a FCA tkwi w tym iz uzywaji silnego matematycznego formalizmu w postaci sieci (ang. lattice), ktore si bogate w interpretacje semantyczne. Roznica polega na tym iz FCA zostalo zaprojektowane po to aby uzywac go w obszarach takich, jak: nabywanie wiedzy, klasyfikacja i przetwarzanie informacji. Natomiast COM przeznaczony jest bardziej do efektywnego modelowania i przechowywania danych [61].
2.3. Liczba wçztôw Systemow Zarzidzania Bazi Danych
Przez liczbç wçzlow nalezy rozumiec liczbç jednostek w systemie informatycznym, na ktorych mozliwe jest przechowywanie i przetwarzanie danych, informacji czy tez wiedzy. Ze wzglçdu na liczbç wçzlow mowi siç o bazach scentralizowanych (podrozdzial 2.3.1) oraz rozproszonych (podrozdzial 2.3.2).
2.3.1. Bazy scentralizowane
Bazy scentralizowane zawieraji jedni centralni bazç danych z systemem jej zarzidzania, do ktorej przychodzi zgloszenia. Zgloszenia stanowii zidania pochodzice z aplikacji klienckiej w architekturze dwuwarstwowej bidz z aplikacji serwerowych w architekturze wielowarstwowej [66-68].
2.3.2. Bazy rozproszone
Baza rozproszona lub architektura rozproszona zarzidzania bazami danych wystçpuje wowczas, gdy baza danych istnieje fizycznie na dwoch lub wiçkszej liczbie komputerow i traktowana jest jak jedna logiczna calosc. Dziçki takiemu podejsciu, zmiany w zawartosci bazy w jednym komputerze si uwzglçdniane rowniez w innych maszynach. Z punktu widzenia uzytkownika wszystkie te bazy logicznie stanowii jedni bazç danych. Rozproszone bazy danych si stosowane ze wzglçdu na zwiçkszoni wydajnosc przetwarzania na wielu komputerach jednoczesnie oraz na to iz znoszi pewne ograniczenia baz scentralizowanych [7, 12, 69].
2.4. Warstwa przetwarzania w Systemach Zarzidzania Bazi Danych
Przez termin warstwa przetwarzania nalezy rozumiec technologie, techniki i algorytmy, za pomoci ktorych dokonuje siç operacji na danych zebranych w bazie danych poprzez SZBD lub poprzez oddzielne, wyspecjalizowane do tego zewnçtrzne programy. Dzialania te maji na celu dostarczenie uzytkownikowi informacji, wiedzy na interesujicy go
temat. Do warstw przetwarzania w SZBD nalezy: warstwa aplikacji ciyglego przetwarzania transakcyjnego (podrozdzial 2.4.1), warstwa aplikacji przetwarzania analitycznego (podrozdzial 2.4.2) oraz warstwa eksploracji danych (podrozdzial 2.4.3).
2.4.1. Warstwa aplikacji ciyglego przetwarzania transakcyjnego
Narzçdzia do transakcyjnego przetwarzania ciyglego wbudowane sy najczçsciej w SZBD i majy za zadanie na biezyco obslugiwac transakcje dokonywane przez uzytkownikôw w systemie. SZBD oparty o transakcje posiada mechanizm ich obslugi umozliwiajycy obslugiwanie wielu uzytkownikôw w jednym czasie bez wzglçdu na ich lokalizacjç czasoprzestrzenny.
Transakcje obslugiwane przez OLTP powinny spelniac wymagania atomowosci, spôjnosci, izolacji i trwalosci (ang. atomicity, consistency, isolation, durability - ACID) [70]. Atrybutem OLTP opatrywane sy operacyjne bazy danych. Systemy OLTP ukierunkowane sy na realizacjç operacji: aktualizacji, tworzenia, zastçpowania i kasowania (ang. create, replace, update, delete - CRUD) danych [70].
2.4.2. Warstwa aplikacji przetwarzania analitycznego
Narzçdzia do ciyglego przetwarzania analitycznego uzywajy wielowymiarowych perspektyw zagregowanych danych w celu zapewnienia szybkiego dostçpu i obslugi strategicznych informacji przeznaczonych do zaawansowanych analiz. Technologia OLAP pozwala uzytkownikom na uzyskanie glçbszego zrozumienia oraz dodatkowej wiedzy o rôznorodnych aspektach danych organizacji. Mozliwe jest to poprzez szybkie, konsekwentne i interakcyjne dostçpy do wielu odmian mozliwych sposobôw widzenia danych [71].
2.4.3. Warstwa eksploracji danych
Eksploracja danych (ang. data mining - DM) stanowi interdyscyplinarny dziedzinç naukowy, ktôra wywodzi siç z dziedziny nauki i techniki jaky jest informatyka. Zajmuje siç ona wizualizacjy i wydobywaniem ukrytej implicite informacji z duzych zasobôw informacyjnych (baz danych) [72]. Wykorzystuje w tym celu technologie przetwarzania informacji oparte o statystykç i sztuczny inteligencjç: uczenie maszynowe, metody ewolucyjne, logikç rozmyty oraz zbiory przyblizone. Nieodlycznie zwiyzana jest z rôznego rodzaju omawianymi w tym artykule zrôdlami i modelami danych. Ogôlnie eksploracja danych (ED) przeprowadzana jest na bardzo duzych bazach danych w celu wyekstrahowania z nich wartosciowej wiedzy. Eksploracja danych ukierunkowana jest na zastosowania.
Problemy badawcze a zatem tez zastosowania metod i algorytmów z zakresu ED, które za jej pomoci siç podejmuje, sí mocno zalezne od specyfikacji dostçpnych zbiorów danych dotyczicych swiata rzeczywistego [2O, 73]. Na potrzeby eksploracyjne budowane sí takze specjalne platformy i jçzyki posredniczice, wspomagajice eksploracjç danych. Do takich rozwiizan posredniczicych (ang. middleware) zalicza siç jçzyk znaczników odkrywania wiedzy w bazach danych (ang. knowladge discovery in databse markup language - KDDML). Platforma ta i wspierany przez nii jçzyk zostala zaprojektowana w celu wspierania rozwoju finalnych aplikacji lub wysoko poziomowych systemów, które wykorzystují: mieszany dostçp do danych, wstçpne przetwarzanie danych, ekstrakcjç oraz wdrazanie modeli eksploracji danych. Cala platforma zostala oparta o struktur^ jçzyka znaczników XML [74, 75].
2.5. Aktywnosc Systemów Zarzidzania Bazi Danych
Poprzez termin aktywnosc nalezy rozumiee zdolnose lub brak zdolnosci do dokonywania dodatkowych operacji w obrçbie bazy danych lub systemu zarzidzania. Do przeprowadzania dodatkowych operacji sluzy mechanizm przetwarzania danych wykonywany poza glówni sesji zidan uzytkownika. Umozliwia on np. wykonywanie dodatkowych operacji na danych poza kwerendi (zapytaniem) wyslani do SZBD. Ze wzglçdu na aktywnose bazy danych mozemy podzielie na aktywne (podrozdzial 2.5.1) oraz nieaktywne (podrozdzial 2.5.2).
2.5.1. Systemy aktywne
Termin aktywny system okresla grupç platform zarzidzania bazi danych, które pozostaji czynne nawet wtedy, gdy nie sí do nich jawnie kierowane zidania transakcyjne czy zadania tworzone przez uzytkownika. Mozliwa jest wiçc zmiana stanu poza glówni sesji uzytkownika i najczçsciej wystçpuje ona na skutek [7б]: zajscia okreslonego zdarzenia zewnçtrznego lub wewnçtrznego, zakonczenia realizacji okreslonego zbioru transakcji kierowanych do SZBD, uplywu okreslonego kwantu czasu lub kombinacji dwóch powyzszych przypadków.
W odróznieniu od opisanych w nastçpnym podpunkcie systemów nieaktywnych (pasywnych), systemy aktywne baz danych sí wyposazone w mechanizm definiowania i przetwarzania aktywnych regul (ang. event condition action - EGA), których logika inspirowana byla regulami z systemów eksperckich [14, 77]. Wykorzystuje siç zatem operatory zdarzeniowe, modele aktywnosci i zaleznosci czasowych oraz przyczynowo skutkowe do obslugi zdarzen powstaj icych miçdzy akcjami uzytkownika.
2.5.2. Systemy nieaktywne
Nieaktywne bazy danych nazywane takze pasywnymi bazami lub pasywnymi systemami baz danych charakteryzujy siç tym, iz nie wykonujy zadnych dodatkowych zadan np. zwiyzanych z zapytaniem uzytkownika do bazy danych. Nie posiadajy one takze jakiegokolwiek mechanizmu mogycego takie dodatkowe zadania obslugiwac.
3. Zarys projektu platformy agentowej dla Panstwowej Strazy Pozarnej
W sluzbach ratowniczych PSP istnieje problem w stworzeniu jednolitego, funkcjonalnego, komputerowego systemu wspomagania decyzji z elementami edukacyjno-szkoleniowymi, przeznaczonego dla Kierujycego Dzialaniami Ratowniczymi (KDR) [78]. Dotychczas w szkole glôwnej PSP opracowano kilka przykladowych rozwiyzan i koncepcji. Rozwiyzania te dotyczyly glôwnie: tworzenia modelu i architektury systemu [79], opisu jego wymagan i specyfikacji [78] oraz wyboru metod opartych o wyznaczenie, analizç i rozwiyzania problemôw wystçpujycych na poczytkowych etapach realizacji systemu [80]. Ze wzglçdu na wystçpujyce problemy, wynikajyce m.in. ze zlozonosci analizowanej dziedziny, dotychczas nie powstal jeszcze dzialajycy, w pelni funkcjonalny prototyp, w dalszym ciygu sy to badania laboratoryjne. Dodatkowo pojawiajy siç kwestie dotyczyce tego, jak zorganizowac architekturç sprzçtowo-programowy systemu, jakie technologie wybrac do tego celu, w jaki sposôb reprezentowac i pozyskiwac wiedzç w systemie oraz jaki proces budowy systemu wybrac. Problematyka procesu budowy obejmuje wymienione kwestie jak i problem dotyczycy tego czy znajdy siç odbiorcy na tego rodzaju rozwiyzanie i wyniki analiz.
W niniejszym rozdziale skupiono siç na opisie i rozwiyzaniu pierwszego wymienionego problemu, ktôry stanowi dobôr architektury sprzçtowo-programowej i technologicznej. W szczegôlnosci skoncentrowano siç w tej sekcji artykulu na opisie zastosowania koncepcji architektury agentowej (podpunkt 2.1.3). Dokonano analizy mozliwosci jej zastosowania w sluzbach ratowniczych PSP. Zaproponowano takze podstawowy struktur^ aplikacyjny do rozwiyzywania problemôw zwiyzanych z ciyglym naplywem danych. Dane te naplywajy z akcji ratowniczo-gasniczej od jej zgloszenia do dyspozytora przez obserwatora do jej rozwiyzania przez KDR - model transakcyjny. W nastçpnej kolejnosci zaproponowano zastosowanie architektury agentowej do rozwiyzywania zadan analitycznych, do ktôrych nalezy np. analiza zuzycia sprzçtu, jego zakup etc. A wiçc zadan dlugofalowych - model analityczny.
3.1. Transakcyjna architektura agentowa
Przed omowieniem konkretnej realizacji architektury agentowej dla sluzb ratowniczych PSP, opisano relacje jakie zachodz^ pomi?dzy trzema podstawowymi warstwami z jakimi projektant oprogramowania styka si? podczas jego projektowania. Warstwami tymi s^: srodowisko (ang. environment layer), oprogramowanie (ang. program layer) oraz ludzie (ang. human layer). Ich wzajemne relacje wyznaczaj^ obszary modelowanej na pewnym wybranym poziomie koncepcji, wybranej cz?sci rzeczywistosci. Poszczegolne warstwy wraz z mozliwymi relacjami przedstawia Rycina 2.
Ryc. 2 Podzial rzeczywistosci projektanta oprogramowania na warstwy ze wzgl?du na
mozliwosci jej modelowania
Zródlo: Opracowanie wlasne
Rycina 2 przedstawia podzial rzeczywistosci projektanta oprogramowania na warstwy ze wzgl?du na mozliwosci jej modelowania. Na wymienionej rycinie, okr?gi wyznaczaj^ warstwy, które bior^ udzial w modelowaniu, natomiast przeci?cia si? okr?gów wyznaczaj^ powstale modele w wyniku interakcji warstw. Cz?sc wspóln^ stanowi kontroler, którego zadaniem jest nadzorowanie przeplywu danych, informacji, wiedzy mi?dzy poszczególnymi warstwami oraz modelami i reagowanie na zachodz^ce zmiany. Na przedstawionym rysunku warstwy srodowiska tworz^ wszelkie mozliwe interakcje i procesy, jakie zachodz^ w swiecie rzeczywistym pomi?dzy wszystkimi jego uczestnikami. Programowe modelowanie wybranego elementu srodowiska np. pomiaru poziomu wody, zapisu go w bazie danych i dalszej obróbce programowej, tworzy tzw. programowy model srodowiska. Jesli dla wybranego elementu srodowiska, dotycz^cego obszaru dzialan czlowieka, tworzone s^ formalne procedury czy tez schematy dzialan wyrazone np. za pomoc^ planów ratowniczych, wówczas tworzone s^ tzw. modele w postaci heurystyk, schematów i planów procesów oraz
dzialan. Wdrozenia ich dokonuje siç w warstwie ludzkiej w celu znormalizowania procesôw zwiyzanych z komunikacjy czy przeprowadzaniem akcji ratowniczo-gasniczej.
Warstwa ludzka jest wyodrçbnionym, pod pewnym wzglçdem, znormalizowanym i ujednoliconym wycinkiem rzeczywistosci, w ktôrej zachodzy interakcje miçdzy ludzkie ograniczone przez wyznaczone normy i procedury. Jesli istnieje mozliwosc komputerowego, programowego wsparcia utworzonych procesôw w warstwie ludzkiej wôwczas otrzymywany jest tzw. programowy model procesôw, ktôry moze zostac wykorzystany do wspomagania ludzi, w tym kontekscie nazywanych KD, w ich decyzjach. W takim przypadku systemy wspierajyce lub ulatwiajyce i automatyzujyce pewne aspekty procesu zachodzycego w warstwie ludzkiej nazywane sy powszechnie systemami wspomagania decyzji lub systemami wspomagania pracy.
Wyzej opisany model warstwowy mozna zaadoptowac na potrzeby np. modelowania systemu wspomagania decyzji z rozproszony warstwy programowy dla sluzb ratowniczych PSP. Schemat implementacji z wyrôznieniem stosu programowego w warstwie programowej przedstawia Rycina 3.
Ryc. 3 Dynamiczne oddzialywanie pomiçdzy warstwami z wyszczegôlnieniem stosu programowego w warstwie programowej n-tego wçzla Zrôdlo: Opracowanie wlasne
Rycina 3 przedstawia dynamiczne oddzialywanie pomiçdzy warstwami z wyszczegôlnieniem stosu programowego w warstwie programowej n-tego wçzla. Przez
termin wçzel nalezy rozumiec fizyczny lokalizacjç sprzçtowo-programowy w systemie przestrzennym np. w komendzie Bialostockiej, Warszawskiej etc. W warstwie srodowiska zostaly umieszczone tzw. koncowki. Koncôwki stanowiy sensory: ludzkie oraz pomiarowe (analogowe, cyfrowe, analogowo-cyfrowe). Sensory te nadzorujy wybrane parametry otoczenia, w ktôrym umieszczone sy koncowki pomiarowe np. wskaznikôw poziomu wody. Koncowkami ludzkimi mogy byc np. osoby obserwujyce bezposrednio poziom wody na rzece lub odczytujyce jej poziom z terminali programowych, wizualizujycych jej poziom lub dostarczajycych informacji o jej konkretnej wartosci w wybranym punkcie. Rejestracja danych za pomocy koncôwek pomiarowych najczçsciej odbywa siç przez system akwizycji danych pomiarowych, ktôry wchodzi w sklad warstwy programowej i dodatkowo w omawianym kontekscie stanowi tzw. warstwçprogramowq zewnçtrznq. Zbudowany jest on najczçsciej z bazy danych, w ktôrej rejestrowane dane pomiarowe, zapisywane i zarzydzane sy przez wybrany system zarzydzania bazy danych, (model koncôwek aktywny). Dane z koncôwek sy odczytywane i zapisywane przez zewnçtrzne aplikacje. Aplikacje te zazwyczaj dostarczane sy takze z ich interfejsem programowania aplikacji. Dodatkowymi dostarczanymi rozwiyzaniami w omawianej warstwie mogy byc:
• system wizualizacji, ktôry sluzy do graficznej reprezentacji rejestrowanych zmiennych,
• system powiadamiania, ktôry sluzy do zwracania uwagi dyspozytorowi na wybrane stany systemu, dziçki czemu moze on podjyc odpowiednie dzialania,
• uslugi sieciowe (ang. web service), dziçki ktôrym mozliwa jest zdalna komunikacja z systemem przez niezalezne aplikacje pisane przez niezaleznych programistôw.
Termin programowa warstwa zewnçtrzna oznacza, ze aplikacje te nie wchodzy bezposrednio w sklad warstwy oprogramowania dla sluzb ratowniczych PSP. Sy one dostarczane przez zewnçtrznych dostawcôw oprogramowania i dzialajy niezaleznie od systemu wspomagania decyzji. Dziçki swojemu API i uslugom sieciowym mogy dzialac jak wtyczki (ang. plugins) i tym samym rozszerzac funkcjonalnosc wspomnianej platformy. W przypadku, gdy ktôras z obserwowanych przez koncôwki ludzkie lub pomiarowe wartosci zmiennych srodowiska zostanie przekroczona, wôwczas uruchamiane sy przewidziane procedury w warstwie ludzkiej. Przykladowy sytuacjç moze stanowic scenariusz przypadku (ang. event case), w ktôrym obserwator na rzece, lub dyspozytor na stacji pomiarowej poziomu wody, dostrzega znaczne przekroczenie poziomu lub o takim stanie zostaje
poinformowany przez system monitujicy. Stan taki grozi zalaniem terenow, w takiej sytuacji dyspozytor uruchamia procedure dzialania przeciwko powodzi i zawiadamia odpowiednie jednostki sluzb ratowniczych. Wybrane jednostki mogi zostac juz wczesniej powiadomione (system wczesnego powiadamiania) o zaistnialym zagrozeniu, dziçki czemu mogi odpowiednio przyszykowac siç do dzialania np. opracowujic odpowiednii strategic dzialan ratowniczych. Wczesniejsze powiadomienie odbywa siç na drodze komunikacji warstwy programowej zewnçtrznej z warstwq programowq wewnçtrznq stanowiici wlasciwe oprogramowanie dla sluzb ratowniczych PSP. Dokladniej, komunikacja ta zachodzi na poziomie uslug sieciowych warstwy programowej wewnqtrznej. Wowczas programisci odpowiedzialni za zewnçtrzne aplikacje dopisuji rozszerzenia komunikujice siç z systemem PSP, w ktorych przesylaji komunikaty o stanie nadzorowanego obiektu. Mozliwa jest takze sytuacja odwrotna, w ktorej to programisci wewnçtrzni dopisuji rozszerzenia pomiarowe, monitorujice stan wybranych obiektow, wykorzystujic ich zewnçtrzne uslugi sieciowe z ich API. Po dotarciu zawiadomienia, zidania (ang. request) do kontrolera zarowno programowego jak i ludzkiego, w postaci np. dyspozytora, i wstçpnym rozpoznaniu sytuacji za posrednictwem wszelkich mozliwych dostçpnych sensorow, wyzwalany jest proces akcji ratowniczo-gasniczej. Etapy procesu przeprowadzania akcji ratowniczo-gasniczej przez KDR mogi byc wspierane przez warstwçprogramowq wewnçtrznq. W jej sklad wchodzi aplikacje komunikujice siç z modelem zawierajicym tzw. czçsc aktywnq oraz pasywnq. W cz^sci aktywnej zawarte si wszelkie informacje dotyczice biezicego stanu systemu np. ilosci wolnych i zalokowanych zasobow (sprzçtu i ludzi), ich miejsca zalokowania jak i najszybszych tras dojazdu do miejsca zdarzenia. Z czçsci tej mogi takze pochodzic zdjçcia satelitarne obiektu ktorego dotyczi dzialania ratowniczo-gasnicze lub przestrzeni, na ktorej rozgrywa siç dane zdarzenie. Dodatkowo model ten moze byc uzupelniany informacjami z modeli zewnçtrznych np. z dostçpnych czujnikow itd. W modelu pasywnym znajduji siç archiwalne raporty z odbytych zdarzen ratowniczo-gasniczych. Zorganizowane i opisane si one wedlug wybranej ontologii wyrazonej np. w technice obiektowej [20, 31]. Wewnçtrzny system aplikacji odpowiedzialny jest za wypracowanie jak najlepszej odpowiedzi dla KDR, w postaci wskazowek. Odpowiedz uzyskuje siç na podstawie dopasowania informacji z modelu aktywnego oraz informacji dostarczonych z miejsca zdarzenia przez KDR, do modelu pasywnego. Dopasowanie polega na wyszukaniu informacji (ang. information retrieval - IR) historycznej. Informacja ta ma postac najbardziej podobnego przypadku zdarzenia, ktory zawarty jest w modelu pasywnym.
Przeliczenie na tryb agentowy nastçpuje w przypadku, gdy:
• powstale zagrozenie jest na tyle duze, iz swym zasiçgiem obejmuje obszar lub obiekt w taki sposób, ze zadysponowane sily i srodki si niewystarczajice do jego neutralizacji,
• nie mozna wyszukae odpowiedniego, dajicego najlepsze wskazówki raportu archiwalnego w wçzle lokalnym aplikacji na podstawie dostarczanych do niego aktualnych danych.
Tryb ten polega na tym, iz w wydzielonej czçsci systemu informatycznego tworzy siç aplikacjç programowi tzw. agencjç której roli jest:
• nadzór nad agentami m.in. powolywanie ich do zycia oraz przyjmowanie ich z innych systemów,
• przekazywanie wyników dzialan agentów do wewnçtrznej aplikacji lokalnej, która wysyla je do dowódców akcji.
Agenci si wiçc niezaleznymi programami mogicymi przemieszczae siç miçdzy wybranymi wçzlami systemu, wedlug wybranej strategii. Agencja podzielona jest na dwie czçsci. Pierwsza zawiera agentów aktywnych. Druga natomiast agentów pasywnych. Agenci aktywni i pasywni komunikuji siç poprzez agencjç wçzla, do którego zostali wyslani z jego czçscii aktywni natomiast agenci pasywni z jego czçscii pasywni. W ten sposób mozliwe jest pozyskanie informacji na temat m.in.: dodatkowych sil i srodków, które mogi zostae zadysponowane na miejscu zdarzenia w razie zajscia takiej koniecznosci oraz sposobów likwidowania zdarzenie, poprzez przeszukiwanie modelu pasywnego wybranego wçzla.
3.1.2. Realizacja transakcyjnej architektury agentowej
Przykladowa realizacja transakcyjnej architektury agentowej opisanej w punkcie 3.1 zostala przedstawiona na Rycinie 4.
Ryc. 4 Przykladowa realizacja architektury agentowej dla warstwy programowej skladaj^cej
si? z trzech w?zlow glownych Zrodlo: Opracowanie wlasne
Rycina 4 przedstawia realizacja architektury agentowej dla warstwy programowej skladaj^cej si? z trzech w?zlow glownych. W?zly te zawieraj^ opisywan^. w punkcie 3.1. konfiguracj? programow^. skladaj^c^. si? z: aplikacji (serwer aplikacji), modelu danych (serwer baz danych) oraz agencji (serwer agentowy). Do przykladowych w?zlow na stopniu wojewodzkim nalez^: komenda wojewodzka w Warszawie, Bialymstoku oraz Olsztynie. W przykladzie, do komend wojewodzkich kierowane s^. z^dania obslugi akcji ratowniczo-gasniczych z obszaru calego wojewodztwa oraz z obszarow podleglych komendom miejskim i powiatowym. Do systemu maj^. wi?c dost?p Miejskie Stanowiska Kierowania MSK jak i Powiatowe Stanowiska Kierowania PSK. Wszystkie komendy wojewodzkie rejestruj^ dzialalnosc sluzb ratowniczych na wybranym terenie (model aktywny) jak i pozyskuj^ opisy zneutralizowanych zdarzen, w ktorych braly udzial sily i srodki podlegle komendom miejskim i powiatowym (model pasywny). Komendy nizszego szczebla, miejskie i powiatowe, nie przechowuj^. fizycznie danych i calej warstwy serwerowej. L^cz^ si? one natomiast z warstwy aplikacji poprzez terminale w celu pozyskania lub dostarczenia odpowiedniej informacji, wiedzy o zaistnialym zdarzeniu i przeprowadzonej akcji ratowniczo-gasniczej. W przypadku gdy w w?zle na stopniu wojewodzkim nie uda si? odnalezc satysfakcjonuj^cego rozwi^zania, wowczas przeszukiwane s^ najblizsze w?zly pod
wzglçdem odleglosci jak i profilu zdarzen. Zdarzenia np. w wojewodztwie podlaskim stanowii glownie pozary torfowisk i lasow [81], z tego wzglçdu powinny byc przeszukane najblizsze komendy wojewodzkie, o zblizonym profilu, ktore przechowuji najwiçkszi ilosc zdarzen tego typu interwencji [7]. Profile zdarzen w postaci metadanych mogi byc utrzymywane w Komendzie Glownej (KG). Trasa agenta (ang. routing), w takim przypadku, moze wyglidac nastçpujico: agent udaje siç do warstwy aplikacji KG, z ktorej kierowany jest do warstwy aplikacji najblizszej komendy wojewodzkiej po czym po pobraniu danych wraca bezposrednio do wçzla aplikacji, z ktorego zostal wyslany.
3.2. Analityczna architektura agentowa
Analityczna architektura agentowa konfiguracji sprzçtowo-programowi nie rozni siç od architektury transakcyjnej opisanej w podpunkcie 3.1. Roznice si funkcjonalne, architektura transakcyjna przeznaczona jest do obslugi akcji w trybie on-line i aktywnego podsuwania rozwiizan dla KDR. Architektura analityczna przeznaczona jest natomiast do badania zaistnialych zdarzen np. pod kitem zuzytych sil i srodkow w czasie akcji czy tez planowania zakupu nowego sprzçtu. Zakup nowego sprzçtu specjalistycznego moze byc podyktowany analizi:
• zgromadzonych informacji o zuzyciu sprzçtu i zapotrzebowania na nowy (model pasywny),
• informacji o sprzçcie na rynku oferowanych przez zewnçtrznych dostawcow (model aktywny) wedlug profilu i czçstotliwosci wystçpowania zdarzen w danym rejonie.
Zewnçtrzny model aktywny, ktory nalezy do warstwy programowej zewnçtrznej n-tego wçzla, moze byc reprezentowany przez elektroniczni ofertç firmy specjalizujicej siç w dostarczaniu specjalistycznego sprzçtu ratowniczo-gasniczego. Oferty mogi byc dostçpne poprzez serwisy internetowe. Analizi ich zajmuji siç wowczas aktywni agenci typu analitycznego, ktorzy aktywnie poszukuji jak najlepszej oferty, pod wzglçdem cenowym i wymogow. Aktualnie probç takiego rodzaju systemow podejmuje siç w obrçbie systemow handlu elektronicznego (ang. e-commerce) np. do negocjacji cen [25]. Podobne rozwiizania mogi zostac zastosowane w obrçbie omawianego modulu analitycznego do wyboru jak najlepszej oferty.
4. Podsumowanie
Proces projektowania i implementacji zintegrowanego systemu, na poziomie warstwy programowej, dla sluzb ratowniczych PSP jest zadaniem skomplikowanym. Swiadczye o tym moze fakt zlozonosci samej analizowanej dziedziny. W obrçbie dzialan PSP obsluguje siç bowiem zdarzenia o róznym charakterze np. pozary, zagrozenia miejscowe czy tez falszywe alarmy. Kazde z tych zdarzen wymaga innego sposobu i planów reagowania oraz uzycia sprzçtu. Ponadto dla kazdego rodzaju interwencji i zadan z nimi zwiizanych powinny zostae opracowane struktury danych, w postaci baz danych (modeli pasywnych oraz aktywnych) bçdacych wlasnoscii PSP, z którymi bçdi mogly komunikowae siç, dziçki wewnçtrznej wartwie aplikacji, dowolne aplikacje spelniajice kryteria integralnosci i bezpieczenstwa. Komunikacja powinna odbywae siç takze w drugi stronç np. z czujnikami monitorujicymi istotne zmienne dla newralgicznych obiektów oraz obszarów. Komunikacja w obu kierunkach moze odbywae siç poprzez spelnienie kontraktu programowego [31] i wykorzystanie technik oraz protokolów komunikacyjnych w postaci [82-84]: protokolu wywolywania zdalnego dostçpu do obiektów (ang. simple object access protocol - SOAP), zdalnego wywolania procedur (ang. remote procedure call - RPC) czy architektury zapewniajicej komunikacjç pomiçdzy obiektami pracuj icymi w heterogenicznych systemach komputerowych (ang. common object request broker architecture - COREA). W przypadku tworzenia jednolitego oprogramowania dla aplikacji wqztów wewnçtrznych mozna oprzee siç na technologi Java oraz dostarczanej wraz z nii technik zdalnego wywolywania metod (ang. remote method invocation - RMI) [83] czy tez szkieletu aplikacji do rozwijania oprogramowania agentowego (ang. java agent dEvelopment framework - JADE) [85]. Przy opracowaniu odpowiedniej konfiguracji, system moze pracowae tez jako platforma do wczesnego ostrzegania np. przed powodziami. Konfiguracja taka wymagalaby utworzenia strategi komunikacji miçdzy wçzlami ich policzenie i skonfigirowania. Otwarti kwestii pozostaje sposób rozmieszczenia w^zlów oraz ich ilose. W przedstawianym opracowaniu zalozono, ze Komendy Wojewódzkie przechowuji caly rejestr, zwiizany z opisem zdarzen (model pasywny) i z nadzorem dysponowanych zasobów (model aktywny), pochodzicy z komend podleglych tj. miejskich oraz powitowych. Taka konfiguracja moze prowadzie do przeciizen systemu (ang. overloading). Przeciizenie nastçpuje, gdy do systemu zaczynaji naplywae zgloszenia, w ilosci której nie bçdzie on w stanie przetworzye. Jednym z mozliwych wówczas rozwiizan jest replikacja oraz skalowanie sprzçtowe. Dokonae mozna rozbudowy mocy obliczeniowej jednostek, do których sí kierowane zidania i projektowanie
ich na najwyzsze mozliwe obciyzenia, ktore z gory ciçzko jest przewidziec i oszacowac. Drugim wyjsciem moze byc skalowanie poprzez wiçksze rozproszenie aplikacji, a wiçc instalacji na stopniach powiatu i gminy podobnego oprogramowania jak na stopniu wojewodzkim, przez co serwer wojewodzki zostaje odciyzony. W przypadku tym zostaje skomplikowana struktora aplikacyjna przez co problem kontroli i utrzymania calej aplikacji we wszystkich wçzlach staje siç bardziej klopotliwy. Architektura taka zwiçksza rowniez koszty - nalezy zakupic dodatkowy sprzçt i oprogramowanie. Mozna postawic hipotezç, ze struktora rozproszona jest optymalna i efektywna ze wzglçdu na proces przeszukiwania i wyszukiwania przypadkow zdarzen oraz sprawuje siç lepiej w przypadku duzego obciyzenia systemu zwiyzanego np. z wysylaniem do niego zydan, zwiyzanych z pojawieniem siç duzej ilosci porzarow lasow na terenie wojewodztwa. Obecnie w Zakladzie Informatyki i Lycznosci SGSP prowadzone sy badania nad zastosowaniem architektury rozproszonej baz danych w sluzbach ratowniczych PSP [6, 12, 86, 87].
Aktualnie w warstwie ludzkiej istnieje rozbudowana baza heurystyczna, na ktory sklydajy siç dobrze udokomunentowane precesy, regulaminy, plany i akty prawne [88-90]. Wszytkie one wyznaczajy zakres kompetecji i dzialan odpowiednich jednostek organizacyjcnych PSP takich jak np. Komend Wojewodzkie, miejskie, powiatowe czy tez stanowisk kierowania na roznym szczeblu. Stanowiy one zatem dobry punkt wyjsciowy do projektowania, budowy i organizacji nowoczesnej oraz sprawnej, opisywanej w niniejszym artykule warstwy aplikacyjnej w postaci systemu do obslugi zdarzen i zwiyzanych z nimi akcji ratownoczo-gasniczych dla sluzb ratowniczych PSP.
Literatura
1. Nonaka I., Takeuchi H., Kreowanie wiedzy w organizacji, Poltext, Warszawa, 2002;
2. Sostaric B., Przeglqdowa analiza systemów do zarzqdzania wiedzq z elementami systemów ekspertowych, Studia i materialy polskiego stowarzyszenia zarzadzania wiedza, Bydgoszcz 2005. s. 150 - 158;
3. Kuc B. R., Zemigala M., Zarzqdzanie wiedzq - postulat czy fakt? Inzynieria wiedzy i systemy ekspertowe, Akademicka Oficyna Wydawnicza EXIT, Warszawa 2009;
4. Krasuski A., Kreñski K., Ewid9x i co dalej ? Przeglyd Pozarniczy, nr 6, 2006;
5. Strona firmy abakus. [on-line] [dost^p: 1 marca 2009] Dost^pny w Internecie: http://www.ewid.pl/?set=main&gr=aba;
6. Krasuski A., Maciak T., Rozproszone bazy danych, mozliwosci ich wykorzystania w Panstwowej Strazy Pozarnej, Zeszyty Naukowe SGSP, nr. 34, 2006, s. 23-42;
7. Krasuski A., Maciak T., Wykorzystanie rozproszonej bazy danych oraz wnioskowania na podstawie przypadköw w procesach decyzyjnych Panstwowej Strazy Pozarnej, Zeszyty Naukowe SGSP, nr. 36, 2008, s. 17-35;
8. Mironczuk M., Krenski K., Koncepcja systemu ekspertowego do wspomagania decyzji w Panstwowej Strazy Pozarnej. [w:] Grzech A., Juszczyn K., Kwasnicka H. and Nguyen N.T., editors. Inzynieria Wiedzy i Systemy Ekspertowe, Akademicka Oficyna Wydawnicza EXIT, Warszawa 2009;
9. Kempa A., Modelowanie procesow biznesowych z wykorzystaniem metody Case-Based Reasoning, Studia i materialy polskiego stowarzyszenia zarzadzania wiedzi. Bydgoszcz 2005, s. 50-56;
10. Maciak T., Krenski K., Dobor atrybutow bazy przeciwpozarowej budynkow systemu informacji przestrzennej sluzb ratowniczych, Zeszyty Naukowe SGSP, nr 32, 2005, s. 59;
11. Krasuski A., Maciak T., Historia rozwoju Systemow zarzqdzania bazami danych, Bezpieczenstwo i Technika Pozarnicza, Wydawnictwo CNBOP Jozefow 2006,
s. 213-226;
12. Krasuski A., Maciak T., Rozproszone bazy danych - architektura funkcjonalna, Bezpieczenstwo i Technika Pozarnicza, nr. 01/ 2007, Wydawnictwo CNBOP, Jozefow 2007;
13. Krenski K., Maciak T., Krasuski A., An overview of markup languages and appropriateness of XML for description of fire and rescue analyses, Zeszyty Naukowe SGSP, nr. 37, 2008, s. 27-39;
14. Krolikowski Z., Wprowadzenia do kursu: Zawansowane systemy baz danych, [on-line] [dostçp: 27 sierpnia 2009] Dostçpny w Internecie: http://osilek.mimuw.edu.pl/index.php?title=Zaawansowane_systemy_baz_danych.
15. Beynon-Davies P., Systemy baz danych, Wydawnictwa Naukowo-Techniczne, Warszawa 2003;
16. Morawski O., Hurtownie danych i systemy wspomagania decyzji, [dostçp: 15 sierpnia 2009] Dostçpny w Internecie: http://ptf.fuw.edu.pl/fens/studia/ekonofizyka/olaf.morawski.pdf.;
17. Wrembel R., Krolikowski Z., Morzy M., Magazyny danych - stan obecny i kierunki rozwoju. Poznan, ProDialog, 2000. [dostçp: 10 czerwca 2009] Dostçpny w Internecie: http://www.cs.put.poznan.pl/mmorzy/papers/prodialog01.pdf.;
18. Mironczuk M., System gromadzenia i przetwarzania medycznych danych pomiarowych w klinice urologii. Politechnika Bialystok, Bialystok, 2007;
19. Staniszkis W., Architektura Systemu Zarzqdzania wiedzq, Studia i materialy Polskiego Stowarzyszenia Zarzadzania Wiedzi, 2005. s. 150 - 158;
20. Mironczuk M., Eksploracja Danych w kontekscie procesu Knowledge Discovery In Databases (KDD) i metodologii Cross-Industry Standard Process for Data Mining (CRISP-DM), Metody Informatyki Stosowanej, nr 2, 2009;
21. Paprzycki M., Agenci programowi jako metodologia tworzenia oprogramowania, [dostçp: 31 maja 2010] Dostçpny w Internecie: http://www.e-informatyka.pl/wiki/Agenci_programowi_jako_metodologia_tworzenia_oprogramowa nia.;
22. Case S., Azarmi N., Thint M., Ohtani T., EnhancingE-Communities with Agent-Based Systems, Computer, nr. 34 2001;
23. Chandra J. M., Siddhartha M., Multi agent based approach for analyzing spatial image data, Page Help Intelligent Agent & Multi-Agent Systems, 2009 IAMA 2009, 2009;
24. Lieberman H., Rozenweig E., Singh P., Aria: An Agent for Annotating and Retrieving Images, Computer, nr. 34, 2001;
25. Wang J., Chen Y., Agent-Based Price Negotiation System for Electronic Commerce, Proceedings of the Seventh International Conference on Intelligent Systems Design and Applications, 2007;
26. Laird J. E., Using a Computer Game to Develop Advanced AI, Computer, nr. 37, 2001, s. 70-75;
27. Codd E. F., A relational model of data for large shared data banks, Communication of the ACM, nr. 13, 1970;
28. Connolly T., Begg C., Systemy Baz Danych - projektowanie, wdrazanie i zarzqdzanie w praktyce. Warszawa, 2003;
29. McJones P., The 1995 SQL Reunion: People, Projects, and Politics, 1995. [dostçp: 24 listopada 2009] Dostçpny w Internecie: http://www.mcjones.org/System_R/SQL_Reunion_95/SRC-1997-018.pdf.;
30. Stones R., Matthew N., Bazy danych i MySQL, Od podstaw, 2003;
31. Meyer B., Programowanie zorientowane obiektowo 2005;
32. db4o, Industry Solutions, [dostçp: 19 listopad 2009] Dostçpny w Internecie: http://www.db4o.com/about/solutions/;
33. ObjectivityDB, [dostçp: 19 listopad 2009] Dostçpny w Internecie: http://www. obj ectivity.com/solutions/ ;
34. Golab L., Özsu M. T., Issues in data stream management, ACM SIGMOD Record, nr. 32, 2003, s. 5-14;
35. Babcock B., Babu S., Datar M., Motwani R., Widom J., Models and Issues in Data Stream Systems. Symposium on Principles of Database Systems Proceedings of the twenty-first ACM SIGMOD-SIGACT-SIGART symposium on Principles of database systems, 2002;
36. Arasu A., Widom: J., A Denotational Semantics for Continuous Queries over Streams and Relations. ACM Sigmod Record, nr. 33, 2004, s. 6-11;
37. Maier D., Tufte K., Fernández-Moctezuma R. J., Tucker P., Li J., Papadimos V., Niagara. [dostçp: 20 listopad 2009] Dostçpny w Internecie: http://datalab. cs.pdx.edu/niagara/ ;
38. Stanford stream data manager. [dostçp: 20 listopad 2009] Dostçpny w Internecie: http://infolab. stanford.edu/ stream/;
39. Telegraph. [dostçp: 20 listopad 2009] Dostçpny w Internecie: http ://tel egraph .cs.b erkel ey. edu/index. html. ;
40. Liu L., Pu C., Buttler D., Han W., Paques H., Tang W., The Continual Queries Dostçpny w Internecie: [dostçp: 20 listopad 2009] http ://www.cc. gatech. edu/proj ects/disl/CQ/;
41. Fisher K., Hogstedt K., Rogers A., Smith F., Hancock. [dostçp: 19 listopada 2009] Dostçpny w Internecie: http://www2.research.att.com/~kfisher/hancock/;
42. Balakrishnan H., Stonebraker M., Medusa. [dostçp: 20 listopad 2009] Dostçpny w Internecie: http://nms.lcs.mit.edu/projects/medusa/#people;
43. Berg B., The Aurora Project. [dostçp: 20 listopad 2009] Dostçpny w Internecie: http://www. cs.brown.edu/research/aurora/ ;
44. Cattell R. G. G., Object Data Management, Object-Oriented and Extended Relational Database Systems. Object Data Management, Object-Oriented and Extended Relational Database Systems, Addison-Wesley, 1991;
45. IBM. Introduction to OQL. [dostçp: 20 listopad 2009] Dostçpny w Internecie: http://publib.boulder.ibm.com/infocenter/tivihelp/v8r1/index.jsp?topic=/com.ibm.netc ool_precision.doc/pr35se/xF1118340.html.;
46. Giero M., Nilewski R., Wykorzystanie BTBD do zapisywania i rzeszukiwania danych
0 leczeniu nieptodonosci metodami IVF. [Holny Majera]: Technologie Eksploracji
1 Reprezentacji Wiedzy - Holny Majera 2008, 2008;
47. Praca zbiorowa, Temporal Database. [dostçp: 20 listopad 2009] Dostçpny w Internecie: http://en.wikipedia.org/wiki/Temporal_database;
48. Snodgrass R. T., The TSQL2 Temporal Query Language. Computer Science Department of the University of Arizona, Retrieved 14 July 2009;
49. TimeDB. [dostçp: 19 listopad 2009] Dostçpny w Internecie: http://www.timeconsult.com/Software/Software.html.;
50. Sellis T., Frank A. U., Grumbach S., Güting R. H., Jensen C. S., et al., SpatioTemporal Databases The CHOROCHRONOSApproach. 2003. s. 297-307;
51. Vries A. P. D., Content and multimediadatabase management systems. Centre for Telematics and Information Technology, University of Twente, 1999;
52. Ghafoor A., Multimedia database management systems. ACM Computing Surveys (CSUR), nr. 27, 1995;
53. Kozielski S., Malysiak B., Kasprowski O., Mrozek D., Bazy danych: Struktury, Algorytmy, Metody, WKL, 2006;
54. Nicola M., Linden B., Native XML Support in DB2 Universal Database, Very Large Data Bases archive Proceedings of the 31st international conference on Very large data bases, 2005;
55. Georgiadis H., Vassalos V., Xpath on steroids: exploiting relational engines for xpath performance, International Conference on Management of Data archive Proceedings of the 2007 ACM SIGMOD international conference on Management of data, 2007;
56. Morzy M., Aktywne hurtownie danych, [Warszawa]: Najnowsze rozwiqzania i praktyczne zastosowania: hurtownie danych i business intelligence, Centrum Promocji Informatyki, 2004. [dostçp: 23 March 2004];
57. Traczyk T., Hurtownie danych - wprowadzenie. Infofestiwal'98, 1998;
58. Niederlinski A., Regutowo-Modelowe Systemy Ekspertowe, Gliwice, PKJS, 2006;
59. Praca zbiorowa, Deductive database, [dostçp: 17 grudnia 2009] Dostçpny w Internecie: http://en.wikipedia.org/wiki/Deductive_database;
60. Savinov A., Principles of the Concept-Oriented Data Model, 2004. [dostçp: 22 grudnia 2009] Dostçpny w Internecie: http://conceptoriented.com/savinov/publicat/imi-reporf04.pdf.
61. Savinov A. A., Concept-Oriented Model and Query Language, CoRR, nr. abs/0901.2224, 2009;
62. Savinov A., Informal introduction into the Concept-Oriented Data Model, 2005. [dostçp: 22 grudnia 2009] Dostçpny w Internecie: http://conceptoriented.org/papers/ComInformalIntroduction.pdf.;
63. Savinov A., Concept-Oriented Model. In: Ferraggine V.E., Doorn J.H. and Rivero L.C., editors. Handbook of Research on Innovations in Database Technologies and Applications: Current and Future Trends: IGI Global, 2009;
64. Wille R., Franzke C., Formal Concept Analysis: Mathematical Foundations, Springer Verlag, 1999;
65. Wolff K. E., A first course in formal concept analysis, 1994. [dostçp: 22 grudnia 2009] Dostçpny w Internecie: http://www.fbmn.fh-darmstadt.de/home/wolff/Publikationen/A_First_Course_in_Formal_Concept_Analysi s.pdf.
66. Griffin J., Architektura dwu-, trzy- i n-warstwowa. XML I SQL Server 2000, 2002. s. 136-139;
67. Wçgrzyn A., Malecki M., Oracle JDeveloper Suite 2.0 jako wydajne srodowisko do tworzenia aplikacji intra- i internetowych, na przykladzie sklepu elektronicznego, [Zakopane]: V Konferencja PLOUG, 1999. [dostçp: Pazdziernik 1999] Dostçpny w Internecie: http://www.ploug.org.pl/konf_99/pdf/10.pdf.
68. Sienkiewicz J. E., Syty P., Architektura warstwowa aplikacji internetowych, [dostçp: 10 listopad 2009] Dostçpny w Internecie: http://www.mif.pg.gda.pl/homepages/sylas/articles/art_2008_elblag.pdf.;
69. Krasuski A., Uslugi katalogowe w architekturze rozproszonej bazy danych w procesie wspomagania decyzji w Panstwowej Strazy Pozarnej, Seminarium Zakladu Logiki Matematycznej, 2009;
70. Praca zbiorowa, OLTP. [dostçp: 10 listopad 2009] Dostçpny w Internecie: http://it-portal.pl/pl/baza-wiedzy/slownik-kategorii-it/246-online-transaction-processing-oltp.html.;
71. OLAP Council White Paper, [dostçp: 10 listopad 2009] Dostçpny w Internecie: www. olapcouncil. org/research/whtpaply.htm.;
72. Wilk-Kolodziejczyk D., Pozyskiwanie wiedzy w sieciach komputerowych z rozproszonych zrodel informacji. [w:] Leslaw H.H., editor. Spoleczenstwo informacyjne Wizja czy rzeczywistosc? [on-line] Krakow: Uczelniane Wydawnictwa Naukowo - Dydaktyczne, 2003, 30 maja. [dostçp: 16 listopada 2007] Dostçpny w Internecie: http://winntbg.bg.agh.edu.pl/skrypty2/0095/285-295.pdf.;
73. Kryszkiewicz M., Eksploracja danych w telekomunikacji, III edycja konferencji HURTOWNIE DANYCH I BUSINESS INTELLIGENCE - problematyka, rozwiizania, zastosowania, 2004;
74. Romei A., Ruggieri S., Turini F., KDDML: a middleware language and system for knowledge discovery in databases, Data & Knowledge Engineering, 2006. s. 179-220;
75. KDDML, Knowledge Discovery in Databases Markup Language;
76. Paton N. W., Diaz O., Active database systems, ACM Computing Surveys (CSUR), nr. 31, 1999, s. 63-103;
77. Bailey J., Poulovassilis A., Wood P. T., An event-condition-action language for XML, International World Wide Web Conference archive Proceedings of the 11th international conference on World Wide Web, 2002;
78. Mironczuk M., Maciak T., Hybrydowy system wspomagania decyzji w otoczeniu komponentow platformy planowania zasobow przedsi^biorstwa dla Panstwowej Strazy Pozarnej, Zeszyty Naukowe SGSP, nr. 42, 2010 (preprint);
79. Mironczuk M., Maciak T., Problematykaprojektowania modelu hybrydowego systemu wspomagania decyzji dla Panstwowej Strazy Pozarnej, Zeszyty Naukowe SGSP, nr. 39, 2009;
80. Mironczuk M., Maciak T., Projektowanie hybrydowego systemu wspomagania decyzji dla sluzb ratowniczych PSP - wybrane problemy i ich rozwiqzania, Zeszyty Naukowe SGSP, nr. 42, 2010 (preprint);
81. Podlaski Urzid Wojewodzki w Bialymstoku Urzid Marszalkowski Wojewodztwa Podlaskiego, System Zarzqdzania Kryzysowego w woj. podlaskim. Bialystok, 2003;
82. Schlossnagle G., RPC - wspolpraca ze zdalnymi uslugami. PHP Zaawansowane programowanie Vademecumprofesjonalisty, Warszawa: Helion, 2004. s. 393;
83. Horstmann C. S., Cornell G., Obiekty rozproszone. Core Java Techniki zaawansowane, Warszawa: Helion, 2009. s. 851;
84. OMG. CORBA BASICS. [dostçp: 13 czerwca 2010] Dostçpny w Internecie: http://www.omg.org/gettingstarted/corbafaq.htm.;
85. JADE, [dostçp: 13 czerwca 2010] Dostçpny w Internecie: http://jade.tilab.com/;
86. Krasuski A., Maciak T., Rozproszone bazy danych w Panstwowej Strazy Pozarnej -model systemu. [w:] Kozielski T., editor. Bazy danych, technologie, narzçdzia. Warszawa WKL, 2005. s. 135-142;
87. Krasuski A., Rozproszona baza danych - mozliwosci wykorzystania w PSP, Przeglid Pozarniczy, nr. 5, 2006, s. 30-33;
88. Rozporzidzenie Ministra Spraw Wewnçtrznych i Administracji z dnia 29 grudnia 1999 r. w sprawie szczegolowych zasad organizacji krajowego systemu ratowniczo-gasniczego. Dz.U.99.111.1311 § 34 pkt. 5 i 6;
89. Regulamin Powiatowego Stanowiska Kierowania. [dostçp: 13 czerwca 2010] Dostçpny w Internecie: http://www.kppspblonie.pl/psk_regulamin.htm.;
90. BIP. Powiatowe Stanowisko Kierowania. [dostçp: 13 czerwca 2010] Dostçpny w Internecie: http://bip-kppsp.spsieradz.finn.pl/index.jsp?bipkod=/003/007.
Recenzenci:
prof. dr hab. inz. Tadeusz Maciak mgr inz. Jerzy Maciak
