Problematyka integracji danych w hurtowniach danych. Przykład

Problematyka integracji danych w hurtowniach danych.
Przykład rozwi zania opartego o produkty firmy ORACLE
oraz inne produkty niekomercyjne
Jarosław Gramacki, Artur Darulewski
Uniwersytet Zielonogórski
Instytut Informatyki i Elektroniki
ul. Podgórna 50, 65-246, Zielona Góra
e-mail: [email protected]
Abstrakt. W artykule zaprezentowano opracowany i wykonany system słu cy do integracji danych
pochodz cych z ró nych ródeł na potrzeby pó niejszego wykorzystania ich w hurtowniach danych. System
ten opiera si na produktach komercyjnych (baza danych firmy ORACLE) oraz niekomercyjnych (baza
danych MySQL, serwer internetowy APACHE oraz j zyki skryptowe PHP4 i JAVASCRIPT). System
obsługiwany jest z poziomu przegl darki internetowej. Pomimo tego, e stworzony system nie oferuje pełnej
funkcjonalno ci na poziomie pozwalaj cym zaliczy go do klasy OLAP, to jednak mo e on z powiedzeniem
słu y jako proste w obsłudze narz dzie integracyjne – w omawianym przypadku dla baz danych ORACLE
oraz MySQL.
1. Wst p
Popularno hurtowni danych nasiliła si dopiero w ci gu ostatnich kilku lat, ale pocz tków
samej idei tego rozwi zania mo na doszuka si ju w pracach MIT (Massachusetts Institute of
Technology – USA) z lat 70–tych ubiegłego stulecia, prowadzonych w zakresie optymalizacji
architektury komputerów. Wtedy to bowiem przetwarzanie danych zacz ło rozwija si w kierunku
wła ciwego zarz dzania informacj . Naukowcy z MIT jako pierwsi zacz li rozró nia systemy
realizuj ce przetwarzanie operacyjne (OLTP – ang. On-Line Transaction Processing), które odnosi
si do systemów obsługuj cych codzienn działalno przedsi biorstw od systemów analitycznych
(OLAP – ang. On-Line Analitycal Processing), które odnosz si do systemów dostarczaj cych
danych decyzyjnych. Celem podj tych prac było opracowanie podstawowych zalece
architektonicznych dla nowej generacji systemów informacyjnych, które cechował ostro
zarysowany podział przetwarzania operacji bie cych i przetwarzania analitycznego oraz
wykorzystanie oddzielnych składnic danych o radykalnie ró nych zasadach konstrukcyjnych.
Przedsi wzi cie zwi zane z budow hurtowni danych obejmuje wiele etapów, takich jak wybór
platformy sprz towej dla hurtowni danych (chodzi tu głównie o okre lenie mocy serwera), wybór
systemu operacyjnego, systemu zarz dzania baz danych i wreszcie wybór oprogramowania do
budowy i zarz dzania hurtowni danych. Bardzo cz sto decyduj c si na konkretny system
bazodanowy klient wybiera równie oprogramowanie do tworzenia hurtowni u tego samego
producenta. Nie musi to by jednak elazn reguł .
Kompleksowe rozwi zania komercyjne du ych firm informatycznych s niew tpliwie bardzo
dobre (flagowym produktem firmy Oracle słu cym do projektowania, generowania i zasilania
korporacyjnych hurtowni danych jest Oracle Warehouse Builder – patrz [14]). Jednak w przypadku
mniejszych przedsi wzi mo e okaza si , e koszt zakupu, wdro enia i pó niejszego utrzymania
systemów opartych o te rozwi zania mo e by , z ekonomicznego punktu widzenia, nie do
przyj cia. Istniej jednak na rynku niekomercyjne produkty, które w poł czeniu z tymi
komercyjnymi mog znacz co zmniejszy całkowity koszt przedsi wzi cia, zapewniaj c ci gle
wystarczaj c funkcjonalno finalnego systemu (systemów). Cz sto równie jest tak, e tworzenie
du ego, kompleksowego systemu hurtowni danych nie jest opłacalne lub, co cz ciej wyst puje
w praktyce, taki kompleksowy system nie jest u ytkownikowi po prostu potrzebny. U ytkownik
zadawala si systemem ta szym, o mniejszej funkcjonalno ci ale mimo to spełniaj cym, nie zawsze
przecie wygórowane, wymagania. Chce mie system, który pozwoli mu ogarn dane z kilku
mniejszych, niezale nie pracuj cych systemów, które same w sobie spełniaj zadanie, do którego
zostały przeznaczone, jednak z ró nych wzgl dów nie mog ze sob współpracowa (np.
wymienia swoje dane).
Aby ten stan osi gn
nale y dokona automatycznego, lub co bardziej prawdopodobne
w praktyce, półautomatycznego zintegrowania ze sob danych pochodz cych z kilku (lub wi cej)
ró nych ródeł. Etap ten zwany zasilaniem hurtowni danych jest bardzo istotny i w du ym stopniu
decyduje o jako ci docelowego systemu analitycznego hurtowni. Na tym etapie musi odby si
wst pne przetworzenie danych, ich oczyszczenie, swego rodzaju standaryzacja i w ko cu
„sklejenie” informacji z kilku (kilkunastu) ró nych ródeł w spójn i jednolit cało .
Wst pnie przygotowane dane w druj do wła ciwej hurtowni, gdzie podlegaj dalszej obróbce.
Na tym poziomie generowane s odpowiednie agregaty (podsumowania) danych, wykonywane s
stałe raporty i nast puje ko cowe „szlifowanie” danych, które odt d mo na uzna za wła ciwy
materiał analityczny. O wst pnej obróbce danych mo na powiedzie , e jest to proces
przekształcaj cy cał mas „suchych” faktów w przydatne dla analityka informacje.
W niniejszej pracy ograniczamy nasz problem do pierwszego etapu w całym zło onym procesie
tworzenia hurtowni danych a mianowicie do etapu integrowania danych pochodz cych z ró nych
ródeł.
Wi cej informacji na temat zagadnie dotycz cych hurtowni danych mo na znale w bardzo
wielu ksi kach, artykułach (równie tych o charakterze popularnonaukowym) oraz w ogromnej
ilo ci ródeł internetowych. Subiektywny wybór kilkunastu pozycji z tej dziedziny podano w spisie
literatury [2 – 16]. Pozycja [4] uznawana jest za klasyk gatunku, gdy w niej to autor po raz
pierwszy zdefiniował formalnie hurtowni danych oraz podał najwa niejsze zasady i zalecenia
stosowane przy jej projektowaniu.
2. Szczegóły projektu
2.1.
Cel i zakres projektu
Celem omawianego w artykule projektu [1] było opracowanie oraz wykonanie rodowiska
słu cego do integracji danych na potrzeby hurtowni danych w oparciu o popularne produkty
zarówno komercyjne, jak i niekomercyjene. Interfejs u ytkownika został oparty o przegl dark
WWW co pozwoliło na zdaln obsług aplikacji. Cało została oprogramowana za pomoc
JavaScript-u po stronie klienta i PHP4 po stronie serwera. Docelowa baza danych dla hurtowni
działa w systemie MySQL, natomiast dane ródłowe pobierane s z serwera Oracle. Rysunek 1
przedstawia struktur zaprojektowanego systemu.
2.2.
Podstawowe zało enia
W omawianym projekcie nale ało zaprojektowa prost aplikacj słu c do zasilania
przykładowej hurtowni danych. Jej zadaniem miała by przede wszystkim integracja danych
pochodz cych z ró nych i niezale nych od siebie ródeł. Aplikacja powinna mie mo liwo
swobodnego wyboru i ł czenia ze sob ródeł danych wraz z podgl dem ich zawarto ci (jednak bez
mo liwo ci ingerencji w ich struktur i zawarto ). Aplikacja powinna w mo liwie najbardziej
zautomatyzowany sposób wykonywa wszystkie niezb dne operacje maj ce na celu scalanie
danych. Nale
do nich: wst pna analiza danych (pod k tem struktury, typów, długo ci,
nazewnictwa itp.), wyłuskanie wspólnych danych mog cych dalej podlega wspólnej analizie (nie
wszystkie ródłowe bazy danych musz zawiera identyczny zestaw informacji), ewentualne
odrzucenie duplikatów uniemo liwiaj cych wiarygodn i rzeteln analiz danych w hurtowni.
Ostatecznym wynikiem działania aplikacji powinien by spójny obraz jak najwi kszej ilo ci
informacji dostarczonych z systemów ródłowych, który b dzie mógł słu y do dalszej analizy
z punktu widzenia hurtowni danych.
Aplikacja z zało enia działa ma na platformie WWW a dost p do wszystkich baz danych
realizowany ma by poprzez protokół TCP/IP. Dzi ki temu mo liwy stanie si zdalny dost p do
systemu a bazy danych u ywane przez system hurtowni b d mogły znajdowa si fizycznie
w ró nych miejscach. Cało
zaprojektowana zostanie w formie stron WWW dynamicznie
generowanych na serwerze za po rednictwem j zyka skryptowego PHP. J zyk PHP zapewnia du
elastyczno , zadowalaj c pr dko działania a tak e mo liwo współpracy z wieloma systemami
baz danych. Zalet takiego sposobu projektowania aplikacji jest brak konieczno ci u ywania
drogich, komercyjnych pakietów programistycznych a tak e naturalna integracja ze rodowiskiem
sieciowym.
Spełnienie powy szych zało e sprowadzało si w praktyce do zbudowania od podstaw całego
systemu przepływu danych: od ródeł danych wej ciowych, poprzez aplikacj integruj c do bazy
docelowej. Pokazano to na rysunku 2.
medium:
sie LAN / WAN
warstwa 2
APACHE
przegl darka WWW
serwer WWW
TCP/IP
javascript
http
PHP4
j zyk skryptowy
po stronie klienta
prezentacja dancyh
warstwa 1
TCP/IP
j zyk skryptowy
po stronie serwera
import danych,
obróbka danych
dane ródłowe
serwer www
udost pniaj cy aplikacj
oraz poł czenie z bazami
danych
warstwa 3
serwery danych
ródłowych
(oracle 8)
stacje klienckie
z uruchomion
przegl dark WWW
Rys. 1. Struktura systemu
3 ródłowe bazy
danych wej ciowych
docelowa baza danych
dane zintegrowane
dane ródłowe
aplikacja do integracji danych
Rys. 2. Elementy wchodz ce w skład projektowanego systemu
2.3.
ródła danych wej ciowych i ich struktury
ródłem danych wej ciowych, s trzy niezale ne, operacyjne (OLTP) bazy danych pracuj ce
w systemie Oracle 8i. S one uproszczon wersj rzeczywistych systemów działaj cych na wy szej
uczelni do prowadzenia ewidencji ocen zdobywanych przez studentów. Ka da z nich została
zapełniona du (po kilkadziesi t tysi cy rekordów w tabelach głównych) ilo ci przykładowych
danych. Pozwoliło to na przetestowanie finalnego produktu w warunkach zbli onych do
rzeczywistych.
Struktury baz ródłowych zostały przedstawione na rysunkach 3, 4 oraz 5.
Rys. 3. Struktura bazy ródłowej nr 1
Rys. 4. Struktura bazy ródłowej nr 2
Rys. 5. Struktura bazy ródłowej nr 3
Bazy te ró ni si wzajemnie pod wzgl dem struktury przechowywanych danych i sposobu
kodowania warto ci (inne długo ci pól lub typy danych). Ponadto ka da z tych baz zawiera tak e
pewne informacje, które nie mog zosta zintegrowane poniewa nie zawieraj ich pozostałe bazy.
Takie zró nicowanie zawarto ci i struktury ródłowych baz danych podyktowane jest przede
wszystkim konieczno ci stworzenia rzeczywistego obrazu sytuacji, z jak upora si musz
narz dzia do integracji danych.
Poza bazami danych wej ciowych system obejmuje te baz docelow (zbudowan w oparciu
o niekomercyjn baz danych MySQL), do której b d trafia dane zintegrowane. MySQL nie jest
wprawdzie typow korporacyjn , wysokowydajn baz danych, ale dzi ki swojej prostocie,
szybko ci działania i małym zapotrzebowaniu na przestrze dyskow wydaje si by dobrym
rozwi zaniem dla systemu takiego jak hurtownia danych. Wprawdzie wszystkie wspomniane zalety
platformy MySQL okupione s brakiem obsługi transakcji, jednak e w tym przypadku nie jest to
wad , poniewa hurtownia danych nie korzysta z mechanizmów transakcyjno ci. Wad MySQL–a
jest co prawda brak obsługi podzapyta , jednak e wi kszo potrzebnych zapyta mo na zbudowa
przy u yciu zł cze , wi c nie wpływa to znacz co na funkcjonalno samej bazy w zastosowaniach
analitycznych. Mo na si wi c spodziewa , e ogólna wydajno platformy MySQL b dzie
zadowalaj ca.
Baza docelowa, poza zintegrowanymi danymi, zawiera te b dzie tabele słownikowe,
w których przechowywane b d informacje niezb dne do integracji danych, tzw. metadane
i zmienne potrzebne do prawidłowego działania systemu. Metadane to nic innego, jak swego
rodzaju szczegółowy katalog dost pnych informacji.
Poniewa struktury danych docelowych tworzone b d dynamicznie podczas działania aplikacji,
to kolejnym podrozdziale opisana zostanie tylko stała struktura słownikowa systemu integracyjnego
znajduj ce si w bazie docelowej.
Baza ródłowa nr 1 stanowi typowy przykład architektury danych stosowanej w tradycyjnych
relacyjnych systemach baz danych. W odró nieniu od typowej struktury gwia dzistej (stosowanej
powszechnie w hurtowniach danych), wzajemne zale no ci mi dzy tabelami tworz bardziej
zło on hierarchi i nie s ju tak przejrzyste i logiczne dla osoby nie maj cej poj cia
o projektowaniu struktur bazodanowych. Taka znormalizowana struktura jest efektywniejsza przy
obsłudze działa operacyjnych i lepiej zoptymalizowana pod k tem ilo ci miejsca zajmowanego
przez dane w przestrzeni dyskowej. Ju na pierwszy rzut oka wida jednak, e jest to raczej model
nastawiony na operacyjne składowanie danych ni na potrzeby analitycznych systemów klasy
OLAP.
Pozostałe struktury baz ródłowych s celowo zdenormalizowane, aby jeszcze bardziej
zwi kszy wzajemne ró nice i uwypukli podstawowe problemy pojawiaj ce si podczas integracji
danych z ró nych ródeł.
2.4.
Struktura systemu integracji danych
Struktura słownikowa systemu integracji danych znajduje si w tej samej bazie co gromadzone
dane. Struktura ta, przedstawiona na rysunku 6, obejmuje trzy nie poł czone wzajemnymi
zale no ciami tabele.
META_DAT
ID
S_USR_NAME
S_TBL_NAME
S_COL_NAME
S_COL_TYPE
S_COL_SIZE
S_KEY
T_DBS_NAME
T_TBL_NAME
T_COL_NAME
R_TBL_NAME
R_COL_NAME
MERGE_ID
STATUS
DUPLICATES
<pk> INT
CHAR(20)
CHAR(20)
CHAR(20)
CHAR(10)
CHAR(15)
CHAR(1)
CHAR(20)
CHAR(20)
CHAR(20)
CHAR(20)
CHAR(20)
INT
CHAR(1)
CHAR(1)
USER_PREFIX
PFX
USR
<pk>
INT
CHAR(20)
VARS_DAT
MERGE_ID
INT
Rys. 6. Struktura słownikowa systemu integracji danych
W zasadzie główn tabel jest tu META_DAT zawieraj ca dane potrzebne do przeprowadzenia
procesu integracji. Pozostałe dwie tabele zostały wydzielone w celu unikni cia niepotrzebnej
redundancji niektórych informacji.
Ka dy rekord w tabeli META_DAT odpowiada pojedynczej kolumnie danych z systemu
ródłowego. Zawiera on informacje na temat ródła pochodzenia danej kolumny, jej parametrów,
ewentualnych referencji je li jest kluczem obcym oraz dane potrzebne do integracji.
Zapis danych do tabeli META_DAT odbywa si dwufazowo. Najpierw wprowadzane s dane
identyfikacyjne kolumny ródłowej dotycz ce pochodzenia i formatu danych. Jest to swego rodzaju
rejestracja danej kolumny w systemie. Cz sto bowiem mo e si zdarzy , e w procesie integracji
z danej tabeli pobiera si pocz tkowo tylko jedn czy dwie kolumny danych a pozostałe dane nie s
wykorzystywane. Z czasem jednak mo e zaistnie potrzeba wykorzystania dodatkowych kolumn
z tej tabel, a dzi ki jednorazowemu wprowadzeniu kompletnej metryki tabeli do systemu
integracyjnego mo liwe jest analizowanie zale no ci danych bez fizycznego odwoływania si do
ródła.
W projektowanym systemie wygl da to w ten sposób, e przy pierwszym poł czeniu si ze
ródłow baz danych nale y wprowadzi metryki wszystkich jej tabel do tabeli META_DAT. W
takim przypadku nawet po rozł czeniu ze ródłem danych u ytkownik mo e opracowa wzorzec
integracji danych (jest to druga faza wprowadzania danych do META_DAT), stworzy tabele
docelowe w bazie MySQL a samego procesu przeniesienia danych z systemu ORACLE dokona
w innym dowolnym czasie.
Znaczenie kolumn w META_DAT podano w tabeli 1:
Tabela 1. Opis tabeli META_DAT. Kolumny zaznaczone kursyw modyfikowane s w procesie integracji
danych natomiast pozostałe zapisywane s przy wst pnej rejestracji ródeł danych
Kolumna
Opis
id
identyfikator kolumny ródłowej (unikalny)
s_usr_name
nazwa u ytkownika systemu ORACLE, poprzez którego udost pniona jest tabela
zawieraj ca kolumn ródłow
s_tbl_name
nazwa tabeli zawieraj cej kolumn
s_col_name
nazwa kolumny ródłowej
s_col_type
typ danych w kolumnie ródłowej
s_col_size
rozmiar danych ródłowych
s_key
kolumna ta zawiera informacje o tym, czy kolumna
(głównym lub obcym) w swojej tabeli
r_tbl_name
je li kolumna ródłowa jest kluczem obcym, to pole to zawiera nazw tabeli w bazie
ródłowej, do której odwołuje si ten klucz obcy
r_col_name
je li kolumna ródłowa jest kluczem obcym, to pole to zawiera nazw kolumny
(b d cej kluczem głównym) w tabeli okre lonej przez r_tbl_name, do której
odwołuje si ten klucz obcy
t_dbs_name
nazwa docelowej bazy MySQL
t_tbl_name
nazwa tabeli docelowej
t_col_name
nazwa kolumny docelowej
Merge_id
kolumna wspólna dla całej tabeli ródłowej, słu ca do kolejkowania procesu
przenoszenia danych (domy lnie jej warto ustawiona jest na 0 – nie bierze udziału
w procesie przepisywania danych)
Status
kolumna zawieraj ca informacje czy dane z kolumny
przepisane do bazy docelowej (domy lna warto 'N' – nie)
Duplicates
atrybut okre laj cy, czy dane w kolumnie docelowej mog si powtarza (domy lna
warto 'Y' – tak)
ródłow
ródłowa jest kluczem
ródłowej zostały ju
W praktyce powinny si tu jeszcze pojawi takie kolumny jak opis słowny danych wprowadzany
bezpo rednio przez u ytkownika czy nazwa serwera danych ródłowych. Jednak e z uwagi na do
du y stopie skomplikowania procesu integracji, obsługa i wykorzystanie tych danych b d
zrealizowane w dalszej kolejno ci, w ramach rozbudowy systemu.
Tabela USER_PREFIX przechowuje warto ci dodawane do kluczy głównych (inne dla ka dego
u ytkownika – s_usr_name) wszystkich tabel ródłowych podczas przepisywania danych. Jest to
operacja niezb dna poniewa bez tego mogłoby doj do niemo no ci zapisania informacji.
Sytuacja taka zilustrowana jest na rysunku 7a.
Dzi ki wprowadzeniu tabeli prefiksów system nie dopuszcza do gubienia informacji, które nie
mogłyby by zapisane z racji naruszenia ogranicze nało onych przez klucz główny w tabeli
docelowej (rysunek 7b). Oczywi cie nale y odpowiednio okre li warto faktycznie dodawan do
klucza, poniewa w przypadku pokazanym na rysunku 7 system sprawdziłby si tylko wówczas,
gdyby tabele ródłowe miały nie wi cej ni 10 rekordów. W projektowanym systemie prefiks
mno ony jest przez liczb 10.000.000, co pozwala na bezpieczn integracj danych z tabel
o długo ci kilku milionów rekordów. Naturalnie po zako czeniu procesu przepisywania danych
mo na zabra si za doprowadzenie warto ci kluczy głównych do bardziej rozs dnych warto ci,
niemniej jednak jest to prosta i efektywna metoda na omini cie problemu identycznych kluczy
w ró nych tabelach. Ten prosty przykład przedstawia zaledwie jeden z całej masy problemów,
z jakimi upora si musz narz dzia do integracji danych.
Ostatnia z tabel systemu – VARS_DAT została przewidziana troch „na wyrost” do
przechowywania pojedynczych zmiennych jakie potrzebne byłyby do działania procesu integracji
danych. Poniewa ze wzgl du na ogromn czasochłonno projektu nie udało si jak do tej pory
zrealizowa wszystkich zaplanowanych funkcji, to tabela ta zawiera tylko jedn zmienn
okre laj c numer ostatniego procesu importu danych (zwi kszany po ka dym zapisie modelu
integracji kolejnych danych do tabeli META_DAT). Jak wspomniano wcze niej, w celu utrzymania
prawidłowego funkcjonowania systemu integracji danych (na obecnym etapie rozwoju) mo na by
usun tabele USER_PREFIX oraz VARS_DAT i dane w nich zawarte przepisa do dwóch kolumn
dodanych w tabeli META_DAT. Spowodowałoby to jednak niepotrzebne dublowanie si danych
wobec czego struktura systemu nie została zmieniona.
ORACLE
MySQL
a)
usr1:WYDZIAŁY
wydział_id
1
2
nazwa
Wydz. Budownictwa
Wydz. Mechaniczny
usr2:WYDZIAŁY
wydział_id
1
2
nazwa
Wydz. Elektroniki
Wydz. Architektury
W YDZIAŁY
wydział_id
1
2
nazwa
????
????
b)
usr1:WYDZIAŁY
wydział_id
1
2
nazwa
Wydz. Budownictwa
Wydz. Mechaniczny
usr2:WYDZIAŁY
wydział_id
1
2
nazwa
Wydz. Elektroniki
Wydz. Architektury
W YDZIAŁY
wydział_id
11
12
21
22
nazwa
Wydz. Budownictwa
Wydz. Mechaniczny
Wydz. Elektroniki
Wydz. Architektury
USER_PREFIX
pfx
1
2
usr
usr1
usr2
Rys. 7. Ilustracja zastosowania tabeli prefiksów w systemie
Pomimo tego, e uko czony system nie oferuje pełnej funkcjonalno ci na poziomie
pozwalaj cym zaliczy go do klasy OLAP, to jednak spełnia wszystkie zało enia projektowe
i z powodzeniem mo e słu y za przykład prostej integracji i przenoszenia danych z systemu
ORACLE na grunt bazy MySQL (lub w praktyce ka dej innej bazy danych).
3. Aplikacja w rodowisku WWW
W rozdziale poprzednim omówiona została struktura całego projektowanego systemu ze
szczególnym uwzgl dnieniem zastosowanych struktur danych. Niniejszy rozdział dotyczy samej
aplikacji, która stanowi ostatni i najwa niejsz cz
projektu. Dzi ki niej bowiem mo liwe jest
współdziałanie opisanych w poprzednim rozdziale dwóch odmiennych systemów bazodanowych.
Z uwagi na specyficzne rodowisko pracy jakim jest przegl darka WWW przez aplikacj w tym
przypadku nale y rozumie szereg plików skryptowych uruchamianych zarówno na serwerze jak
i na komputerze klienta. Warstwa graficznego interfejsu u ytkownika oparta jest o technologie
HTML, CSS, JavaScript i zaawansowane rozszerzenia DHTML zaimplementowane w przegl darce
Internet Explorer. Dzi ki zastosowaniu wielu funkcji DOM (ang. Document Object Model),
umo liwiaj cych obiektow analiz oraz modyfikacje wy wietlanego w przegl darce dokumentu,
cz
funkcji integracyjnych wykonywanych jest na komputerze klienta. Generalnie jednak
przegl darka wraz z zawarto ci stanowi tylko konsol do zdalnego sterowania procesami
zachodz cymi mi dzy ródłow i docelow baz danych. Mo na powiedzie , e „wła ciwym”
miejscem działania aplikacji jest serwer, na którym uruchamiane s skrypty napisane w j zyku
PHP4. To wła nie warstwa j zyka PHP stanowi serce aplikacji pełni c tak e rol pomostu mi dzy
u ytkownikiem i bazami danych.
Na rysunku 8 przedstawiona jest szczegółowo struktura projektowanej aplikacji. Zarysowane s
tu te granice pomi dzy aplikacj i systemami bazodanowymi (ORACLE i MySQL) oraz granica
mi dzy cz ci aplikacji działaj ca po stronie klienta i jej drug cz ci działaj c na serwerze.
W praktyce ka dy z komponentów całego systemu mo e znajdowa si gdzie indziej, jednak e
podczas pracy nad projektem serwer HTTP (wykonuj cy skrypty PHP) i serwer MySQL znajdowały
na tej samej maszynie. Bazy danych ródłowych testowano na kilku zewn trznych serwerach, jak
i na maszynie lokalnej razem z serwerami MySQL i HTTP.
aplikacja
klient
serwer
okno przegl darki
menu aplikacji
ramka HTML
lista otwartych
baz danych
ramka HTML
główne okno aplikacji
dynamicznie generowane
ramki HTML zawieraj ce
aktualnie wczytane
dokumenty
skrypty PHP
MySQL
ukryte elementy HTML umo liwiaj ce komunikacj pomi dzy
poszczególnymi cz ciami aplikacji w sposób niewidoczny dla
u ytkownika
ORACLE
ORACLE
ORACLE
bazy danych
Rys. 8. Struktura projektowanej aplikacji
Zawarto elementów znajduj cych si w oknie przegl darki dokładnie zostanie omówiona
w dalszej cz ci tego rozdziału, jednak e w tym miejscu na uwag zasługuj ukryte elementy
HTML umo liwiaj ce komunikacj pomi dzy poszczególnymi cz ciami aplikacji w sposób
niewidoczny dla u ytkownika. Nale y wyra nie podkre li , e to co u ytkownik widzi na ekranie
przegl darki to tylko i wył cznie znaczniki HTML i tre pomi dzy nimi. Zastosowanie wszelkiego
rodzaju j zyków skryptowych pozwala jedynie na modyfikacje zawarto ci kodu HTML. Tak wi c
ogólnie przyj ło si , e HTML stanowi warstw wizualn dokumentu a skrypty warstw
funkcjonaln .
W strukturze projektowanej aplikacji zastosowano wiele niekonwencjonalnych rozwi za do
rozwi zania problemów w komunikacji mi dzy jej cz ciami składowymi. Sam protokół HTTP
słu cy w sieci do przesyłania stron WWW jest protokołem bezstanowym. W zwi zku z tym
teoretycznie nie istnieje mo liwo zostawienia przez dokument informacji w przegl darce na
potrzeby innego nowo załadowanego. W praktyce wymian danych pomi dzy stronami realizuje si
za pomoc przesyłania danych w adresie URL Mo na te stosowa formularze lub zapisywa dane
na dysku u ytkownika w tzw. cookies. adne z tych rozwi za nie było wystarczaj co dobre do
wykorzystania w projektowanej aplikacji. Zastosowanie formularze i przekazywanie informacji
w adresie dokumentu sprawdza si je li dane maj by wymieniane mi dzy dwoma ładowanymi po
sobie dokumentami. Co za jednak zrobi gdy zajdzie potrzeba zostawienia pewnej informacji
w charakterze zmiennej globalnej, która mo e przyda si za jaki czas ?
Przekazywanie danych mi dzy dwoma otwartymi jednocze nie dokumentami za pomoc
zmiennych globalnych JavaScriptu nie jest mo liwe poniewa ka dy dokument traktowany jest
przez przegl dark jako oddzielny proces (co jest nawiasem mówi c własno ci konieczn do
poprawnego wy wietlania kilku otwartych na raz stron). Tak wi c jedynym prostym i efektywnym
rozwi zaniem okazało si zastosowanie kilku ramek w dokumencie głównym i przekazywanie
danych poprzez elementy HTML. Ka da z ramek traktowana jest jak samodzielny dokument
w zwi zku z czym przekazywanie danych wprost przez JavaScript nie jest mo liwe bez
przeładowania strony (a przeładowanie w przypadku tej aplikacji oznacza mo e utrat danych
wprowadzonych przez u ytkownika). Dzi ki funkcjom obiektowego modelu dokumentu (DOM)
mo liwe jest swobodne odwoływanie do dowolnego elementu znajduj cego si w oknie
przegl darki. Poniewa ramki tak e s elementami HTML to bez problemu mo na sprawdzi
zawarto pola formularza znajduj cego si w ramce A z poziomu ramki B. Bior c pod uwag fakt,
e ramki w oknie głównym aplikacji tworzone s i usuwane na bie co, to jedynym rozwi zaniem
okazało si umieszczenie kilku ukrytych (za pomoc atrybutów CSS) elementów w dokumencie
głównym aplikacji. S to trzy tekstowe pola formularzowe i trzy niewidoczne ramki, do których
ładowane s na przykład wywołania skryptów PHP.
Przedstawione tu rozwi zanie dotycz ce przekazywania danych jest niezwykle istotne dla
działania aplikacji i dlatego zostało bli ej omówione. Jest ono niespotykane w innych tego typu
rozwi zaniach, gdzie na przykład edycja danych z tabeli wymaga przej cia do osobnej strony (php
MySQL Admin).
Problemem w wielodokumentowych aplikacjach WWW jest te przekazywanie zło onych
danych pomi dzy skryptami działaj cymi na komputerze klienta (w przegl darce) i skryptami
działaj cymi na serwerze. Przez dane zło one nale y w tym wypadku rozumie tablice i inne
wielowymiarowe struktury, które najpierw nale ałoby podda tzw. serializacji (przekształceniu na
jednowymiarowy ci g znaków) a po odebraniu z powrotem zamieni na posta wej ciow .
Rozwi zanie takie wprowadza jednak konieczno przesyłania dodatkowych danych mi dzy
klientem a serwerem.
Problem ten został rozwi zany poprzez dynamiczne generowanie funkcji JavaScript wewn trz
skryptu PHP. Dzi ki temu na podstawie informacji uzyskanych z bazy danych PHP wysyła do
przegl darki nie tylko czysty kod HTML ale tak e kod JavaScript, który modyfikuje odpowiednie
elementy dokumentu załadowanego wcze niej w innej ramce. Wad takiego rozwi zania jest
w zasadzie tylko mniejsza przejrzysto kodu ródłowego, poniewa kod PHP jest przeplatany jest
wielokrotnie z kodem JavaScript.
Z uwagi na specyfik działania wielodokumentowych aplikacji WWW ich projektowanie jest
nieco bardziej pracochłonne ni w przygotowywanie analogicznych aplikacji przy pomocy narz dzi
wizualnych takich jak np. Borland Delphi. Nale y jednak podkre li , e w wielu zastosowaniach
aplikacje WWW nie wymagaj ce skomplikowanych i czasochłonnych algorytmów obliczeniowych
mog konkurowa z programami wykonanymi w „tradycyjnej” technologii.
3.1.
Graficzny interfejs u ytkownika
Wspomniane wcze niej ograniczenie si do pracy tylko z przegl dark Internet Explorer
podyktowane zostało przede wszystkim jej mo liwo ciami w zakresie obsługi zawansowanych
funkcji GUI .W zaprojektowanej aplikacji zastosowano mi dzy innymi technologi drag&drop do
wizualnej integracji danych i obsług menu kontekstowych w celu umo liwienia intuicyjnej
i wygodnej obsługi całego systemu. Układ podstawowych elementów GUI w aplikacji pokazany
jest na rysunku 9.
Cały interfejs graficzny podzielony został na trzy zasadnicze cz ci. Na samej górze znajduje si
belka rozwijanego menu głównego, po lewej stronie znajduje umieszczono panel DataBrowser.
Panel ten słu y poruszania si po zawarto ci dost pnych baz. Jego zawarto wy wietlana jest w
formie tradycyjnego drzewa katalogów, gdzie głównymi elementami hierarchii s aktualnie
podł czone bazy danych a elementami podrz dnymi tabele zawarte w tych bazach. Dzi ki u yciu
własnego menu kontekstowego pod prawym przyciskiem myszy udost pniono funkcje operowania
na bazach i tabelach. Funkcje te s oczywi cie zró nicowane dla baz ródłowych i docelowych (nie
ma np. mo liwo ci skasowania tabeli w bazie ródłowej). Najwi kszym elementem w interfejsie
aplikacji jest robocze okno aplikacji, w którym wy wietlana jest zawarto tabel, interfejs słu cy
do integracji danych i inne okna pomocnicze.
Struktura taka nie jest niczym nowym i celowo została dobrana tak, aby u ytkownik obeznany
z obsług typowych aplikacji okienkowych nie miał problemów z jej u ywaniem. W konsekwencji
cała aplikacja nie sprawia wra enia strony WWW, ale zwykłego skompilowanego „pod system”
programu u ytkowego – zarówno w warstwie wizualnej jak i funkcjonalnej.
Dzi ki gł bokiej integracji Internet Explorer-a z systemem Windows cały interfejs aplikacji
działa płynnie i bez zarzutów. Nie ma problemów nawet z od wie aniem generowanych
w DHTML-u okien a bezwładno wszystkich elementów jest nieporównywalnie mniejsza ni
w przypadku aplikacji napisanych w j zyku Java (działaj cych de facto na wirtualnej maszynie
Javy a nie bezpo rednio systemie), które od pewnego czasu stanowi standardowe oprogramowanie
klienckie serwerów ORACLE. Dodatkowym atutem Internet Explorer-a pracuj cego w systemie
Windows jest mo liwo obsługi tzw. HTML Aplications.
W praktyce polega to na wstawieniu odpowiednich znaczników w kod HTML, zmianie
rozszerzenia pliku głównego na *.hta i cało uruchamia si w systemie na prawach samodzielnej
aplikacji. Daje to mo liwo otwarcia dokumentu HTML w samodzielnym systemowym oknie
(a nie w typowym oknie przegl darki) i zablokowanie standardowych systemowych skrótów
klawiszowych, takich jak np. klawisz F5 słu cy do od wie ania okna. Funkcja ta mo e by
przydatna poniewa przypadkowe od wie enie okna zawieraj cego dokument HTML powoduje
jego przeładowanie z serwera co w przypadku dynamicznie generowanych stron mo e grozi utrat
wprowadzonej informacji. Generalnie rzecz ujmuj c, u ytkownik uruchamiaj c plik hta
z systemowego pulpitu mo e si nawet nie zorientowa , e uruchomiona aplikacja jest
w rzeczywisto ci zwykł stron WWW.
Tak wi c oparcie praktycznej cz ci projektu na przegl darce Internet Explorer ma swoje
uzasadnienie praktyczne a bior c pod uwag popularno systemu Windows w rodowisku aplikacji
bazodanowych nie wydaje pomysłem chybionym. Poza tym obsługa wielu funkcji w j zyku
JavaScript ( który u ywany jest równie w procesie edycji i integracji danych po stronie klienta )
i tak musiałaby zosta zrealizowana oddzielnie dla ka dej wspieranej przegl darki a to
spowodowałoby niepotrzebne wydłu enie czasu pracy nad projektem.
Opracowanie podobnej aplikacji, tak aby działała pod innymi przegl darkami i na innych
systemach jest oczywi cie mo liwe, istniej np. pakiety do administracji serwerami Oracle
i MySQL oparte na poł czeniu technologii HTML, JAVASCRIPT i PHP, jednak e tak rozbudowany
i wygodny interfejs obsługi oferuje jak na razie tylko Internet Explorer.
Przykładowe zrzuty ekranów działaj cej aplikacji pokazano na rysunkach 9 i 10.
Rys. 9. Przykładowy ekran działaj cej aplikacji
Rys. 10. Efekt uzyskany po automatycznym generowaniu modelu
4. Podsumowanie
W pracy podj to prób zilustrowania zagadnienia integracji danych o zró nicowanej strukturze
pochodz cych z ró nych ródeł. Proces integracji danych jest szczególnie ciekawy ze wzgl du na
fakt, e mo e on dotyczy tak e szerszego kr gu aplikacji – nie tylko hurtowni danych. Cz sto
bowiem zachodzi potrzeba zespolenia ró nego rodzaju danych w jedn cało a typowe narz dzia
słu ce do migracji danych nie zawsze wystarczaj do rozwi zania tego problemu. Integracja
danych jest procesem zło onym a przedstawiony projekt, ze wzgl du na okre lone ramy czasowe
i zaanga owane „siły ludzkie”, z zało enia nie mógł osi gn
funkcjonalno ci na poziomie
dost pnych na rynku rozwi za komercyjnych.
Zaprojektowana struktura systemu w pełni odzwierciedla cie k przepływu danych w typowym
przedsi biorstwie (bazy operacyjne – system integracji – baza docelowa hurtowni danych). Nale y
w tym miejscu podkre li du zło ono projektu, która obejmuje w praktyce zarz dzanie dwoma
systemami baz danych, zaprojektowanie trzech oddzielnych struktur ródłowych (i wypełnienie ich
du ilo ci przykładowych danych), opracowanie zasad integracji danych oraz aplikacji spinaj cej
mi dzy sob poszczególne elementy systemu.
Stworzona aplikacja, zbudowana tylko w oparciu o j zyki skryptowe, spełnia wszystkie stawiane
zało enia dodatkowo oferuj c wygod obsługi niespotykan w innych narz dziach zrealizowanych
w tej technologii. Zaawansowany interfejs graficzny ogranicza co prawda mo liwo ci u ytkowania
aplikacji tylko do przegl darki Internet Explorer, jednak bior c pod uwag mo liwo ci jakie ona
oferuje, nie powinno stanowi to znacz cej niedogodno ci. Ponadto stanowi doskonały przykład
mo liwo ci projektowania zło onych systemów w oparciu o technologie niekomercyjne (przy
realizacji projektu nie u yto adnych komercyjnych kompilatorów ani narz dzi wspomagaj cych
projektowanie).
Bibliografia
1.
Darulewski A.: Problematyka integracji danych w hurtowniach danych. Projekt systemu integracji danych
opartego o produkty niekomercyjne. Praca magisterska, Uniwersytet Zielonogórski, Wydział
Elektrotechniki, Informatyki i Telekomunikacji, 2002
2.
Głowi ski C.: Sztuka wysokiego składowania, PCkurier, 12/2000
3.
Grochowski, T.: Od SAS-a do SAP-a, PCkurier 9/2001
4.
Inmon W. H.: Building the Data Warehouse, Wiley, wydanie 3, ISBN: 0-471-08130-2, 2002
5.
Kujawski M.: Technologie przechowywania danych w systemach OLAP, Software, kwiecie 1999
6.
Łakomy M.: Hurtownie danych dla przyszło ci, Computerworld, 1 pa dziernika 2000
7.
Oracle Corporation, Oracle Warehouse Builder User’s Guide, Release 3i, June 15 2002, Part No.
A90361-01
8.
Poe V., Klauer P., Brobst S.: Tworzenie Hurtowni Danych, WNT, Warszawa, 2000
9.
Rzewuski M.: Obieg inteligencji, PCkurier 2/2001
10. Słowikowski P.: Nowe wyzwania dla hurtowni danych, PCkurier 24/2001
11. Wiecka A., Czarnota J.: Hurtownie danych w Polsce - jakie problemy rozwi zuj i komu słu
2.0, stycze 2000
12. http://www.billinmon.com
13. http://www.sas.com/technologies/data_warehouse/index.HTML
14. http://www.oracle.com
15. http://www-3.ibm.com/software/data/informix/redbrick/
16. http://www.its.state.ms.us/et/datawarehouse/et_dwh.htm
?, Software