Projektowanie baz danych XML. Vademecum profesjonalisty

IDZ DO
PRZYK£ADOWY ROZDZIA£

SPIS TRE CI Projektowanie baz
danych XML.
KATALOG KSI¥¯EK Vademecum profesjonalisty
KATALOG ONLINE Autor: Mark Graves
T³umaczenie: Tomasz ¯mijewski
ISBN: 83-7197-667-4
ZAMÓW DRUKOWANY KATALOG Tytu³ orygina³u: Designing XML Databases
Format: B5, stron: 498
TWÓJ KOSZYK
DODAJ DO KOSZYKA „Projektowanie baz danych XML. Vademecum profesjonalisty” — to obszerny
podrêcznik do nauki baz danych XML, wykorzystywanych w Internecie oraz baz
stanowi¹cych czê æ wiêkszych systemów.
CENNIK I INFORMACJE Je li dysponujesz gotow¹ baz¹ danych obs³uguj¹c¹ XML, to dziêki tej ksi¹¿ce poznasz
szczegó³owe techniki, w pe³ni wykorzystuj¹ce tê bazê. Je li natomiast korzystasz
ZAMÓW INFORMACJE z klasycznych relacyjnych baz danych, nauczysz siê tworzyæ aplikacje
O NOWO CIACH z wykorzystaniem XML. Zainteresowani tworzeniem baz danych XML „od zera”,
dowiedz¹ siê jak w pe³ni wykorzystaæ dostêpne narzêdzia.
ZAMÓW CENNIK Dodatkowo autor omawia:
• Najwa¿niejsze techniki projektowe baz danych, systemów obs³uguj¹cych te bazy
CZYTELNIA oraz aplikacji XML
• Przechowywanie danych XML w bazach obiektowych, relacyjnych i opartych
FRAGMENTY KSI¥¯EK ONLINE na plikach p³askich
• Zaawansowane techniki modelowania danych XML
• Zapytania kierowane do baz danych XML (uwagi praktyczne, techniki stosowania
JDBC oraz podstawy teoretyczne)
• Sposób korzystania z sieciowych baz danych XML za pomoc¹ jêzyka XSL
i jêzyka Java
• Architekturê baz danych XML i specjalizowane indeksy
• W³¹czanie baz danych XML do wiêkszych systemów
• Bazy danych XML i ich zastosowanie w nauce
„Projektowanie baz danych XML. Vademecum profesjonalisty” to podstawowe ród³o
informacji dla projektantów i programistów baz danych, twórców aplikacji XML,
projektantów systemów oraz kierowników projektów — szczególnie w rodowiskach
Wydawnictwo Helion o specyficznych wymaganiach.
ul. Chopina 6
44-100 Gliwice
tel. (32)230-98-63
e-mail: helion@helion.pl

5RKU VTG EK
9UVúR
4QFKC 9RTQYCFGPKG
1.1. XML................................................................................................................................16
1.1.1. Czym jest XML? ..................................................................................................16
1.1.2. Skąd się wziął XML? ...........................................................................................19
1.1.3. Czemu akurat XML? ............................................................................................19
1.2. Systemy baz danych........................................................................................................22
1.2.1. Czym jest baza danych? .......................................................................................22
1.2.2. Czym jest baza danych XML?..............................................................................24
1.2.3. Czemu u ywać baz danych XML?.......................................................................25
1.3. Bazy danych dostępne w Sieci........................................................................................26
1.3.1. Baza danych w plikach płaskich...........................................................................26
1.3.2. Systemy zarządzania relacyjnymi bazami danych ...............................................29
1.3.3. Systemy zarządzania bazami danych XML..........................................................30
1.4. Aplikacje .........................................................................................................................31
1.5. Dodatkowe informacje....................................................................................................32
1.5.1. Czasopisma...........................................................................................................32
1.5.2. Witryny ogólne .....................................................................................................32
1.5.3. Portale XML .........................................................................................................33
1.5.4. Narzędzia XML ....................................................................................................33
1.5.5. XSL.......................................................................................................................33
1.5.6. Dokumenty W3C..................................................................................................33
1.5.7. Przykłady specyfikacji XML w konkretnych dziedzinach...................................34
1.5.8. Więcej informacji o XML ....................................................................................34
4QFKC 6YQTGPKG UEJGOCVW
2.1. Projektowanie bazy danych ............................................................................................35
2.2. Modelowanie koncepcyjne .............................................................................................38
2.2.1. Model koncepcyjny w formie grafów ..................................................................38
2.2.2. Proces modelowania koncepcyjnego za pomocą grafu ........................................42
2.2.3. Modelowanie koncepcyjne ...................................................................................46
2.2.4. Model koncepcyjny XML ....................................................................................51
2.3. Modelowanie logiczne ....................................................................................................53
2.3.1. Diagram encji i relacji ..........................................................................................53
2.3.2. Schemat relacyjny.................................................................................................54
2.3.3. Model obiektowy..................................................................................................55
2.3.4. Schemat logiczny XML........................................................................................59
2.4. Modelowanie fizyczne ....................................................................................................61
2.4.1. Schemat fizyczny XML........................................................................................62
2.4.2. Przetwarzanie danych a przetwarzanie dokumentów...........................................65
2.4.3. Przenoszenie danych.............................................................................................67
2.4.4. Atrybuty czy podelementy?..................................................................................68
2.5. Bibliografia .....................................................................................................................71

6 Projektowanie baz danych XML. Vademecum profesjonalisty

4QFKC 2QFUVCY[ VGQTGV[EPG
3.1. Typy danych ...................................................................................................................73
3.1.1. XML Schema........................................................................................................74
3.1.2. Wprowadzanie strukturalnych typów danych ......................................................75
3.1.3. Aplikacje sterowane schematem ..........................................................................76
3.2. Systemy zarządzania bazami danych..............................................................................79
3.3. Standardy XML ..............................................................................................................80
3.3.1. XML Schema (XSDL) .........................................................................................83
3.3.2. XSL.......................................................................................................................83
3.3.3. Łącza, wskaźniki i ście ki XML ..........................................................................83
3.3.4. XML Query ..........................................................................................................84
3.3.5. Przestrzenie nazw XML .......................................................................................84
3.3.6. DOM.....................................................................................................................85
3.4. Bazy danych XML..........................................................................................................85
3.4.1. Schemat koncepcyjny ...........................................................................................86
3.4.2. Zadania .................................................................................................................87
3.4.3. Operacje................................................................................................................88
3.5. Modelowanie danych ......................................................................................................89
3.5.1. Istniejące modele danych......................................................................................91
3.5.2. Prosty model danych XML ..................................................................................94
3.5.3. Model danych XML zgodny ze specyfikacją W3C..............................................98
3.5.4. Relacyjny model danych XML ............................................................................99
3.5.5. Model danych XML oparty na węzłach .............................................................106
3.5.6. Model danych XML zbudowany na podstawie krawędzi ..................................110
3.5.7. Ogólny model danych XML...............................................................................113
3.6. Bibliografia ...................................................................................................................118
4QFKC 2TGEJQY[YCPKG FCP[EJ
4.1. Funkcje przechowywania danych .................................................................................121
4.1.1. Baza danych oparta na plikach płaskich.............................................................121
4.1.2. Obiektowa baza danych......................................................................................124
4.1.3. Relacyjna baza danych .......................................................................................130
4.2. Drobnoziarnisty schemat relacyjny ..............................................................................130
4.2.1. Projekt logiczny..................................................................................................131
4.2.2. Projekt fizyczny..................................................................................................134
4.2.3. Przykłady ............................................................................................................139
4.2.4. Implementacja ....................................................................................................142
4.3. Gruboziarnisty schemat relacyjny ................................................................................165
4.4. Schemat relacyjny o średniej granulacji .......................................................................166
4.4.1. Punkty podziału ..................................................................................................167
4.4.2. Projekt bazy danych............................................................................................168
4.4.3. Implementacja ....................................................................................................170
4.5. Uwagi praktyczne .........................................................................................................180
4QFKC #TEJKVGMVWTC U[UVGOW DC FCP[EJ
5.1. Architektura systemu ....................................................................................................181
5.1.1. Klient-serwer ......................................................................................................183
5.1.2. Architektura trzywarstwowa...............................................................................185
5.2. Serwer sieciowy XML ..................................................................................................186
5.2.1. Mo liwości implementacji .................................................................................186
5.2.2. Dostęp klienta .....................................................................................................188
5.2.3. Ładowanie danych..............................................................................................189
5.2.4. Generacja XML ..................................................................................................202
5.3. Relacyjny serwer danych ..............................................................................................202
5.3.1. ądania adresu URL...........................................................................................204
5.3.2. Tworzenie zapytań SQL .....................................................................................205

5RKU VTG EK 7

5.3.3. Formatowanie wyników jako XML ...................................................................206
5.3.4. Pobieranie danych słownikowych ......................................................................207
5.3.5. Implementacja ....................................................................................................210
5.4. Serwer danych XML.....................................................................................................232
5.4.1. Implementacja ....................................................................................................235
5.5. Hybrydowy serwer łączący technologię relacyjną i XML ...........................................252
5.5.1. Implementacja ....................................................................................................253
4QFKC 5[UVGO[ MQOGTE[LPG
6.1. Przegląd dostępnych rozwiązań....................................................................................259
6.2. Adaptery do baz danych ...............................................................................................260
6.2.1. Narzędzia warstwy pośredniej............................................................................261
6.2.2. Komercyjne relacyjne bazy danych....................................................................261
6.2.3. Narzędzia do obsługi zapytań.............................................................................262
6.3. Systemy zarządzania bazami danych............................................................................262
6.4. Serwery danych XML...................................................................................................263
6.4.1. dbXML ...............................................................................................................263
6.4.2. eXcelon...............................................................................................................263
6.4.3. Tamino................................................................................................................263
6.5. Serwery dokumentów XML .........................................................................................263
6.6. Zasoby i witryny ...........................................................................................................264
4QFKC +PVGTHGLU W [VMQYPKMC
7.1. Przegląd ........................................................................................................................267
7.2. Interfejsy u ytkownika XSL .........................................................................................268
7.2.1. Arkusze stylów XSL...........................................................................................268
7.2.2. Prezentacja danych XML jako tabeli..................................................................269
7.2.3. Prezentacja fragmentów XML jako kolejnych rekordów...................................275
7.2.4. Prezentacja identyfikatorów elementów zastępczych jako hiperłączy...............276
7.2.5. Zmiana formatowania w zale ności od treści.....................................................280
7.3. Formy prezentacji wykorzystujące technologię Java ...................................................284
7.3.1. Budowa klienta ...................................................................................................284
7.3.2. Przykład z drzewem............................................................................................287
7.4. Aplikacje prototypowe..................................................................................................293
4QFKC CR[VCPKC
8.1. Rodzaje zapytań ............................................................................................................299
8.2. Reprezentacja................................................................................................................302
8.2.1. Dokumenty opisujące strukturę a dane opisujące relacje...................................302
8.2.2. Reprezentacje wykorzystujące węzły a reprezentacje
wykorzystujące krawędzie.................................................................................303
8.2.3. Reprezentacja łączy ............................................................................................305
8.2.4. Łącza XML zapisywane jako krawędzie............................................................307
8.2.5. Zapisywanie łączy ..............................................................................................308
8.3. Mechanizmy obsługi zapytań .......................................................................................310
8.3.1. Zapytania według ście ki ...................................................................................310
8.3.2. Zapytania według drzewa...................................................................................313
8.4. Zapytania wykorzystujące grafy ...................................................................................314
8.4.1. Model danych korzystający z grafów.................................................................315
8.4.2. Wzorce korzystające z grafów............................................................................316
8.4.3. Wizualizacja .......................................................................................................318
8.4.4. Implementacja SQL............................................................................................319
8.4.5. Algorytm zapytań według grafu .........................................................................340
8.5. Narzędzia do tworzenia raportów .................................................................................345
8.5.1. U ycie XSL do zapytań według ście ek ............................................................345
8.5.2. Zapytania według grafu ......................................................................................347


4QFKC +PFGMUQYCPKG
9.1. Wprowadzenie ..............................................................................................................349
9.2. Struktury danych elementów ........................................................................................350
9.3. Strategie indeksowania .................................................................................................350
9.3.1. Brak indeksowania .............................................................................................351
9.3.2. Pełne indeksowanie ............................................................................................351
9.3.3. Indeksowanie częściowe.....................................................................................355
9.3.4. Indeksowanie związków między dokumentami .................................................358
9.4. Identyfikacja dokumentu ..............................................................................................360
9.5. Metody przeszukiwania ................................................................................................362
4QFKC +ORNGOGPVCELC
10.1. System notatek ............................................................................................................365
10.2. Podstawy biologii .......................................................................................................366
10.3. Wymagania u ytkownika ...........................................................................................367
10.4. Model koncepcyjny.....................................................................................................368
10.5. Opis aplikacji ..............................................................................................................371
10.5.1. Klient ................................................................................................................371
10.5.2. Warstwa pośrednia ...........................................................................................378
10.6. Ograniczenia i rozszerzenia ........................................................................................403
10.7. Uwagi praktyczne .......................................................................................................404
10.8. Skalowanie..................................................................................................................404
10.8.1. Zarządzanie transakcjami .................................................................................404
10.8.2. Bezpieczeństwo ................................................................................................405
10.8.3. Odzyskiwanie danych.......................................................................................405
10.8.4. Optymalizacja...................................................................................................406
QFCVGM # 0CTúFKC ,CXC
A.1. Domyślne ustawienia systemowe ................................................................................407
A.2. Połączenie z relacyjną bazą danych .............................................................................409
A.3. Wyniki działania serwleta............................................................................................415
A.4. Interaktywny interfejs dostępu.....................................................................................417
QFCVGM $ 2CTUGT 5#:
QFCVGM % :/. 5EJGOC %ú è 'NGOGPVCT
Rekomendacja W3C, 2 maja 2001 r. ...................................................................................423
Spis treści.............................................................................................................................424
1. Wprowadzenie .................................................................................................................425
2. Podstawowe pojęcia: Zamówienie...................................................................................426
2.1. Schemat opisujący zamówienia.............................................................................427
2.2. Definicje typów zło onych, deklaracje elementów i atrybutów............................429
2.3. Typy proste ............................................................................................................433
2.4. Definicje typów anonimowych..............................................................................438
2.5. Treść elementów....................................................................................................439
2.6. Adnotacje...............................................................................................................442
2.7. Tworzenie modeli zawartości................................................................................443
2.8. Grupy atrybutów....................................................................................................444
2.9. Wartości Nil...........................................................................................................446
3. Zagadnienia zaawansowane I: Przestrzenie nazw, schematy i kwalifikacja ...................447
3.1. Docelowe przestrzenie nazw i niekwalifikowane elementy i atrybuty lokalne.....447
3.2. Kwalifikowane deklaracje lokalne ........................................................................449
3.3. Deklaracje globalne a deklaracje lokalne ..............................................................452
3.4. Niezadeklarowane docelowe przestrzenie nazw ...................................................453

5RKU VTG EK 9

4. Zagadnienia zaawansowane II: Zamówienie międzynarodowe ......................................453
4.1. Schemat w szeregu dokumentów ..........................................................................454
4.2. Wyprowadzanie typów przez rozszerzenie ...........................................................457
4.3. U ycie typów pochodnych w dokumentach..........................................................457
4.4. Wyprowadzanie typów zło onych przez ograniczanie .........................................458
4.5. Przedefiniowywanie typów i grup.........................................................................460
4.6. Grupy podstawienia...............................................................................................462
4.7. Elementy i typy abstrakcyjne ................................................................................463
4.8. Kontrolowanie tworzenia i u ycia typów pochodnych .........................................464
5. Zagadnienia zaawansowane III: Raport kwartalny..........................................................466
5.1. Wymuszanie niepowtarzalności ............................................................................468
5.2. Definiowanie kluczy i wskaźników.......................................................................469
5.3. Reguły w XML Schema a atrybut ID XML 1.0 ....................................................469
5.4. Importowanie typów..............................................................................................469
5.5. Dowolny element, dowolny atrybut ......................................................................472
5.6. schemaLocation .....................................................................................................475
5.7. Zgodność ze schematem........................................................................................476
A. Podziękowania ................................................................................................................478
B. Typy proste i ich fazy......................................................................................................478
C. U ycie encji.....................................................................................................................478
D. Wyra enia regularne .......................................................................................................480
E. Indeks ..............................................................................................................................481
5MQTQYKF

Rozdział 5.
#TEJKVGMVWTC
U[UVGOW DC FCP[EJ
Język XML świetnie nadaje się do wymiany danych, dlatego te często wykorzystujemy
go w komunikacji między systemami. Pojęcia „architektura systemu baz danych” u y-
wamy w odniesieniu do sposobu, w jaki aplikacje i u ytkownicy korzystają z danych oraz
zarządzają nimi. W przypadku baz danych XML u ytkownicy i aplikacje muszą załado-
wać dane do bazy, przekształcić je na dokumenty XML, pobrać XML z bazy i powiązać
dane relacyjne z kodem XML. Architektura systemu baz danych mo e być typu klient-
serwer — wtedy aplikacja klienta współpracuje bezpośrednio z bazą danych albo mo e
to być struktura trzywarstwowa, w której między klientem a bazą danych pojawia się
dodatkowo serwer.

#TEJKVGMVWTC U[UVGOW
Architektura systemu to sposób funkcjonowania systemu i jego poszczególnych modułów.
Ka dy moduł jest komponentem systemu i realizuje powiązane ze sobą funkcje. Dobrą
architekturę systemu tworzy się przez odpowiednie pogrupowanie wymagań funkcjonal-
nych w moduły i łączenie modułów w system, który spełnia wszystkie zało one zadania.
Definiując architekturę systemu, nale y odpowiedzieć na następujące pytania:
Ile jest modułów?
Jak są ze sobą powiązane? (Czy liniowo, czy w drzewo albo graf?)
Na czym polega ich działanie? Czyli jakie są funkcje poszczególnych modułów?

Z systemami spotykamy się wszędzie — poznawanie większości dziedzin naukowych
wią e się ze studiowaniem konkretnych systemów. Fizyka bryły sztywnej opisuje, jak
nale ące do systemu obiekty oddziałują na siebie, a w przypadku biologii dokładnie anali-
zuje się systemy o „organicznej” naturze. In ynieria polega na tworzeniu zło onych sys-
temów o zało onych funkcjach. W budownictwie przez termin „architektura” rozumie
się projekt budynku, jego wygląd i sposób funkcjonowania.

Architektura systemu to obszerne zagadnienie związane z projektowaniem komponentów,
które współpracując ze sobą, realizują całościowe zadania. W tej ksią ce będziemy mówić
o architekcie systemu, którego zadanie polega na zaprojektowaniu deterministycznych
komponentów programowych baz danych XML.


Du e systemy zwykle mają hierarchiczną budowę: większe podsystemy zawierają mniejsze,
a te z kolei tworzone są z jeszcze mniejszych podsystemów, i tak dalej, a do pakietów,
które zawierają podstawowe składniki programów, czyli klasy obiektów, funkcje i proce-
dury. W tym rozdziale zajmiemy się abstrakcyjnymi aspektami projektowania i podziałem
pracy na ró ne maszyny dostępne w Sieci.

Pierwsze systemy baz danych były monolityczne. Obsługiwała je jedna stacja robocza.
U ytkownicy korzystali z systemu za pomocą prostych terminali lub kart perforowanych.
Z czasem, kiedy stacje robocze zaczęły mieć coraz większą moc obliczeniową, część
obliczeń i funkcji została wydzielona z monolitycznego systemu i przeniesiona na stacje
robocze (klientów), w architekturze klient-serwer. Podsystem klienta przeprowadzał for-
matowanie i proste przetwarzanie, zaś serwer zarządzał większością danych. W miarę
jak powiększały się bazy danych i włączano je do systemów korporacyjnych, konieczne
stało się zastosowanie architektury trzywarstwowej. Dzięki zastosowaniu odrębnego
serwera uproszczono dostęp klientów do wielu baz danych. Warstwa pośrednia umo -
liwiła aplikacjom klienta łączenie się z wieloma bazami danych przez jednolity interfejs.
Jednocześnie projektanci starali się znaleźć odpowiednie miejsce dla reguł biznesowych,
które opisują zasady u ycia danych. Przetwarzanie reguł mogło przecie „zatkać” serwer
lub wymagało powtórzenia tych operacji na stacjach klientów, szczególnie w du ych
systemach, w których wiele aplikacji przetwarza reguły. Jeśli reguły biznesowe znajdowały
się w warstwie pośredniej, to ró ne aplikacje, nie troszcząc się o wydajność czy utrzyma-
nie serwera baz danych, mogły z nich korzystać. Wzrost liczby baz danych i aplikacji
przyczynia się do tego, e konieczne staje się stosowanie dodatkowych warstw pośred-
nich, a co z tym związane — zmiana architektury trzywarstwowej na wielowarstwową.

Sieciowy system baz danych zawiera — jako jeden ze swoich modułów — serwer sieciowy.
Do komunikacji między poszczególnymi warstwami u ywa się protokołu nośnego sieci,
na przykład JVVR. Sieciowy system baz danych mo e mieć architekturę klient-serwer,
architekturę trzywarstwową lub wielowarstwową. Najczęściej stosuje się rozwiązanie
trzywarstwowe — w takim wypadku baza danych wysyła dane do serwera sieciowego.
Jeśli bierzemy pod uwagę architekturę wielowarstwową, to wiele baz danych i serwerów
aplikacji wysyła dane do jednego lub wielu serwerów sieciowych, które następnie przeka-
zują dane klientom. Języka XML mo na u yć do komunikacji pomiędzy komponentami
struktury wielowarstwowej. Mo na równie zastosować układ klient-serwer — zwykle
serwer sieciowy jest wtedy wbudowany w bazę danych.

Jedną z zalet sieciowych baz danych jest uproszczenie aplikacji przez zastosowanie
przeglądarek sieciowych obsługujących aplety Javy. W przypadku apletów kod języka
Java jest przenoszony przez Sieć w chwili kiedy jest wywoływany, zaś przeglądarka za-
pewnia podstawowe formatowanie danych, obsługę formularzy i prostych języków skrypto-
wych; jej mo liwości mogą być rozszerzone przez zastosowanie apletów. Chęć poprawienia
przepustowości i uruchamiania coraz bardziej zło onych aplikacji w coraz mniejszych
systemach powoduje, e funkcje, które były dostępne w aplikacjach klienta, są wykony-
wane na serwerach lub w warstwach pośrednich (mówimy wtedy o aplikacjach „cienkiego
klienta”). I tak na przykład aplety Javy mogą sięgać do bazy danych za pośrednictwem
połączenia JDBC, zamiast stosować natywne sterowniki. Aplety mogą te korzystać
z udostępnianych w pośredniej warstwie programów analitycznych, zamiast lokalnie
wykonywać wszystkie obliczenia.

4QFKC Architektura systemu baz danych 183

Dobrze opracowaną architekturę systemu rozpoznaje się po tym, e odpowiednie funkcje
umieszczono w odpowiednich modułach. Wyboru mo na dokonać na podstawie ró nych
kryteriów, na przykład takich jak unikanie zale ności od stosowanych technologii lub
określenie zale ności pojęć w opisywanej dziedzinie. Takie niefunkcjonalne wymagania
to podstawowe kryteria stosowane w początkowych etapach projektowania. Zdefiniowanie
odpowiednich kryteriów warunkuje dobrą architekturę systemu, jest te podstawą udanego
projektu. W niektórych sytuacjach w doborze kryteriów mogą pomóc następujące pytania:
Czy funkcje baz danych powinny być wydzielone jako odrębny moduł, by
ułatwić uruchamianie systemu w ró nych środowiskach?
Czy w całym systemie będzie mo na zastosować technologię jednej firmy?
Czy system powinien być niezale ny od dostawcy oprogramowania warstwy
pośredniej?
Czy interfejs u ytkownika ma przyjmować schemat bazy danych
(minimalizowanie wpływu częstych zmian opisywanej dziedziny)?
Czy, z uwagi na du e ilości danych, nale y ograniczać ilość przesyłanych
informacji z bazy danych?
Czy — by spełnić wymogi bezpieczeństwa — kontrola dostępu do danych
powinna być wydzielona jako odrębny moduł?

Najwa niejsza jest równowaga między podstawowymi wymaganiami, tak aby zanadto
nie ograniczać systemu. Elastyczność i spełnianie precyzyjnych wymagań to sprzeczne
oczekiwania wobec systemu. Proces rozszerzania mo liwości systemu często jest hamo-
wany przez jego realne uwarunkowania. W oprogramowaniu wa nym dla działania przed-
siębiorstwa du o pracy wkłada się w tworzenie architektury dopasowanej do konkretnych
wymagań i pozwalającej wykorzystywać dostępne zasoby. W przypadku szybko tworzo-
nych systemów architekturze poświęca się niewiele uwagi. Wielu autorów skryptów Perl
czy CGI łączy instrukcje języków SQL z generacją HTML i specyficznymi dla danej
dziedziny regułami biznesowymi, w efekcie w szybkim tempie tworzą sprawnie działający
system. Niestety, trudności wią ą się z utrzymaniem takiego systemu, a wzrastają przy
ka dej zmianie schematu bazy danych, przeglądarki i rozszerzaniu reguł biznesowych.

-NKGPVUGTYGT
Przetwarzanie XML mo e się odbywać na serwerze baz danych. Baza danych XML lub
program generujący XML mogą być włączone do innego serwera baz danych. (Rozwią-
zania, które oferują komercyjne relacyjne bazy danych opiszemy w punkcie 6.2.2). Poza
tym mo na tak modyfikować kod serwera, aby zwracał kod HTML. By uzyskać taki efekt,
nale y skorzystać z darmowego serwera relacyjnej bazy danych, na przykład mysql, który
potrafi generować XML. Inny sposób polega na dodaniu do obiektowej bazy danych obiek-
tów obsługujących XML (tę metodę wykorzystano w systemie eXcelon; opis mo na znaleźć
w punkcie 4.1.2). W tym punkcie zajmiemy się kilkoma prostymi metodami generowania
XML z relacyjnego serwera baz danych. W końcowej części tego rozdziału opiszemy
serwery baz danych, które charakteryzuje trzywarstwowa architektura i które mo na włą-
czać do serwerów baz danych, korzystających z języków programowania takich jak Java.


XML mo na generować bezpośrednio w instrukcji SQL. Jeśli mamy tabelę '26 z kolum-
nami: '2601, 0#/' i .1% (jak w bazie danych Oracle UEQVVVKIGT), to kod z wydruku 5.1
wygeneruje dokument XML. Aby stworzyć dokument XML, nale y otoczyć dane znacz-
nikiem EQNNGEVKQP . Istnieje jeszcze jeden warunek, który powinien zostać spełniony,
byśmy mogli osiągnąć cel — serwer lub aplikacja klienta powinny obsługiwać funkcje
agregujące, tak jak to pokazuje wydruk 5.2. Wprawdzie nie jest to rozwiązanie zbyt ogólne,
ale stosując SQL, mo na w prosty sposób generować kod XML z relacyjnej bazy danych.
Co wa ne, w przypadku prostych zastosowań mo e to być wygodne.

9[FTWM Kod SQL generujący fragment tabeli wydziałów przykładowej bazy danych Scott/Tiger
UGNGEV FGRV FGRVPQ ^^FGRVPQ^^ FPCOG ^^FPCOG^^ NQE ^^NQE^^
HTQO FGRV

9[FTWM Skrypt generujący dokument XML dla tabeli wydziałów przykładowej bazy danych Scott/Tiger
DKPUJ
GEJQ !ZON XGTUKQP !
GEJQ EQNNGEVKQP
USNRNWU UEQVVVKIGT '1(
UGNGEV FGRV FGRVPQ ^^FGRVPQ^^ FPCOG ^^FPCOG^^ NQE ^^NQE^^
HTQO FGRV
'1(
GEJQ EQNNGEVKQP

Jeśli uniezale nimy się od konkretnych kolumn, to otrzymamy bardziej uniwersalne rozwią-
zanie. Na serwerze mo na stworzyć funkcję, która wartości kolumny otoczy znacznikami,
których nazwy są nazwą kolumny, wiersze — nazwą tabeli, a dokument — elementem
EQNNGEVKQP.

Rekord relacyjnej tabeli mo na przekształcić w pojedynczy element, a wartości zapisy-
wać w atrybutach tego elementu, mo na te stworzyć element z podelementami. Zapis
rekordów jako atrybutów jest prostszy, ale u ycie podelementów — bardziej uniwersalne.
Kiedy korzystamy z podelementów, mo emy zastosować sekcje CDATA do zapisywania
znaków zastrze onych. Atrybuty mogą przechowywać informacje o formatowaniu, mo na
je zastąpić kompletniejszymi danymi ze wskaźnikami kluczy obcych. Ró nice między
zastosowaniem atrybutów i elementów opisano w punkcie 2.4.4.

Pseudokod, za pomocą którego mo na przekształcić rekordy tabeli w atrybuty, podano
w wydruku 5.3, zaś ten, za pomocą którego przekształca się rekordy na elementy z po-
delementami, przedstawia wydruk 5.4. Wielu sprzedawców baz danych proponuje takie
rozwiązania, w których wyniki zapytania przekształcane są na dokumenty XML. Pro-
pozycje firm IBM, Oracle i Microsoft opisano w rozdziale 6.

9[FTWM Procedura zapisu danych z relacyjnej tabeli jako atrybutów XML
RTQEGFWTG YTKVG:/.#VVTKDWVGU
VCDNG
RTKPV !ZON XGTUKQP !
RTKPV EQNNGEVKQP
HQT GCEJ TQY KP VCDNG
RTKPV VCDNGPCOG
HQT GCEJ EQNWOP KP TQY
RTKPV EQNWOPPCOG XCNWG


GPF
RTKPV
GPF
RTKPV EQNNGEVKQP
GPF

9[FTWM Procedura zapisu danych z relacyjnej tabeli jako podelementów
RTQEGFWTG YTKVG:/.'ODGF'NGOGPVU
VCDNG
RTKPV !ZON XGTUKQP !
RTKPV EQNNGEVKQP
HQT GCEJ TQY KP VCDNG
RTKPV TGEQTF
HQT GCEJ EQNWOP KP TQY
RTKPV EQNWOPPCOG
RTKPV XCNWG
RTKPV EQNWOPPCOG
GPF
RTKPV TGEQTF
GPF
RTKPV EQNNGEVKQP
GPF

Niektóre przykłady kodu Java zaprezentowane w dalszej części tego rozdziału uruchomią
się w systemie o architekturze dwuwarstwowej, która pozwala rozwijać klucze obce,
pobierać pojedyncze rekordy oraz narzucać warunki na zapytania. Przetwarzanie XML
bezpośrednio na serwerze baz danych, z właściwą mu architekturą klient-serwer, ma
kluczowe znaczenie dla wydajności w du ych zbiorach danych. Jednak oprogramowanie
jest opisywane jedynie w architekturze trzywarstwowej, gdy wtedy wymogi związane ze
znajomością ró nych procesów i ich działaniem są mniejsze ni w przypadku architektury
dwuwarstwowej. Jeśli trzeba skorzystać z systemu o architekturze klient-serwer, to funkcjo-
nalność warstwy pośredniej i serwera z systemu o architekturze trzywarstwowej mo na ze
sobą połączyć, tworząc serwer odpowiedni dla modelu opartego na strukturze dwuwar-
stwowej. Zdarza się, e nawet jeśli przetwarzanie odbywa się na serwerze, to i tak mogą wy-
stąpić problemy z komunikacją między jądrem bazy danych a rozszerzeniami obsługujący-
mi XML — w przypadku struktury trzywarstwowej łatwiej mo na poprawić wydajność.

#TEJKVGMVWTC VT[YCTUVYQYC
Prostą trzywarstwową architekturę sieciowego systemu baz danych pokazano na rysun-
ku 5.1. System ten składa się z trzech modułów:
DBMS — realizuje funkcje bazy danych i umo liwia dostęp do bazy.
Mo na zastosować relacyjną, obiektową bazę danych, bazę danych XML
lub system plików.
Warstwa pośrednia — zawiera serwer sieciowy, który mo e korzystać z bazy
danych i udostępniać te dane klientowi. Mo na zastosować zwykły serwer
sieciowy, serwer sieciowy ze skryptami CGI, serwer z serwletami, serwer z JSP,
komercyjne oprogramowanie warstwy pośredniej z dostępem do baz danych
lub serwer aplikacji.


4[UWPGM
Trzywarstwowa
architektura
sieciowego systemu
baz danych

Klient — zawiera interfejs u ytkownika, który pozwala korzystać z funkcji
warstwy pośredniej. Klient mo e być te inną aplikacją. Zwykle rolę tę pełni
przeglądarka, aplet Javy lub aplikacja napisana w języku Java.

W ró norodny sposób mo na określać zawartość poszczególnych modułw i sposób ich
łączenia. Protokołem komunikacyjnym z klientem mo e być TCP/IP, HTML lub XML,
przenoszone przez HTTP lub CORBA. Komunikacja między bazą danych lub warstwą
pośrednią mo e się odbywać za pomocą JDBC lub CORBA. Zwykle wybór jednej tech-
niki komunikacji wpływa na inne decyzje.

Oczywiście, zawsze mo na zastosować inne typy architektury i inne techniki. Niezale nie
od dokonanego wyboru, projektując system, warto i nale y zadać kilka pytań, między
innymi:
W jaki sposób dane są ładowane do bazy danych?
Za pomocą jakich zapytań dane będą pobierane z bazy?
W którym module jest generowny XML?
W którym module odbywa się przetwarzanie XML?

5GTYGT UKGEKQY[ :/.
Serwer XML umo liwia sieciowy dostęp do bazy danych. Obsługuje takie operacje baz
danych, jak: przechowywanie, pobieranie, aktualizowanie dokumentów. Baza danych
mo e opierać się na dowolnym modelu danych, ale dane pobierane zawsze mają postać
XML. Kiedy serwer danych ładuje dane do bazy innej ni XML, mo e przyjmować dane
w formie XML lub w formacie odpowiednim dla konkretnej bazy.

W następnym punkcie opiszemy niektóre mo liwości implementacji, zaś w punkcie 5.2.2
sposób, w jaki mo na sięgać do danych na serwerze. W punktach 5.2.3 i 5.3 przedstawimy
kolejno zapisywanie danych z bazy relacyjnej jako XML i odczyt tych danych. W punk-
cie 5.4 — pobieranie i odczyt danych XML z serwera bazy danych XML, zaś w punkcie 5.5
— pobieranie danych relacyjnych i XML ze wspólnego serwera.

/Q NKYQ EK KORNGOGPVCELK
Serwer danych XML mo na stworzyć „od zera”, na przykład modyfikując serwer sieciowy
albo korzystając z serwera sieciowego z obsługą CGI, z serwera sieciowego z obsługą
serwletów, z obsługą JSP, mo na tak e wykorzystać serwer aplikacji lub po prostu kupić
gotowy system. Jeśli tworzymy serwer danych XML „od zera”, to nale y pamietać, e
serwer sieciowy jest podstawą, na której tworzy się funkcje dostępu do danych, funkcje


formatowania XML i zwracania odpowiedzi zgodniez podanymi adresami URL. Gotowy
serwer sieciowy (na przykład niewielki, darmowy serwer) mo na zmodyfikować lub
rozszerzyć o funkcje dostępu do bazy danych, formatowanie XML i odpowiadanie na
ądania w formie adresów URL. W przypadku u ywania serwera z obsługą CGI, ser-
wletów lub serwera aplikacji trzeba zrobić to samo. Korzystanie z serwera aplikacji ma
jedną zaletę, serwery te posiadają wbudowaną funkcję połączeń z bazą danych. Dobry
system komercyjny zazwyczaj od razu dysponuje wszystkimi potrzebnymi funkcjami.

Do serwera danych mo na dodać funkcje, które wykonują określone zadania przed zwró-
ceniem, wprowadzeniem lub zmodyfikowaniem danych XML w bazie. Na przykład
niektóre zapytania mogą wymagać agregacji lub wyliczeń statystycznych. W przypadku
wprowadzania danych i ich modyfikowania konieczne mo e być sprawdzenie poprawności
danych lub reguł biznesowych. Warto o tym pamiętać, zanim wybierzemy serwer danych.

Najlepszym rozwiązaniem jest, oczywiście, komercyjny serwer danych XML, gdy spełnia
wszystkie wymagania. Warto tak e rozwa yć mo liwość zakupu serwera aplikacji, który
mo na łatwo połączyć ze środowiskiem projektowym (jeśli spełnia nasze wymagania)
i który posiada odpowiednie funkcje baz danych. Wadą niektórych serwerów aplikacji
jest to, e często projektanci są ograniczani przez dostępne interfejsy u ytkownika lub
niestandardową metodę łączenia się z bazą danych — wymaga to od nich dodatkowego
wysiłku. Jednak tworzenie od początku pakietu łączności z bazą danych (na przykład
opartego na JDBC) jest trudnym zadaniem i w przypadku du ych aplikacji komercyjnych
nale y to uznać za ostateczność (chyba e postawiliśmy sobie za cel stworzenie serwera
danych XML — wtedy, oczywiście, rzecz jest warta zachodu). Pakiety łączności z bazą
danych w przypadku małych aplikacji mogą być proste. Wystarczy otwarcie połączenia
z bazą danych, wykonanie transakcji i zamknięcie połączenia. Taki prosty pakiet opisano
w dodatku A. Jednak wykonanie pakietów łączności z bazą danych staje się du o bardziej
odpowiedzialnym zsadaniem, kiedy trzeba utrzymywać połączenia dla wielu transakcji
przeprowadzanych z ró nych kont, dbać o wydajność (wymaga to zarządzania połącze-
niami, czasem rozłączania się) i bezpieczeństwo połączeń.

Wa ną decyzją związaną z implementacją serwera danych jest wybór języka programo-
wania.

Jeśli do stworzenia serwera danych u ywamy Javy, serwer sieciowy powinien obsługiwać
serwlety. Komunikacja bazy danych z serwerem sieciowym mo e mieć formę „cienkiego
klienta” lub „grubego klienta”. Wybór jednego z tych rozwiązań zale y od mo liwości
bazy danych. W przypadku „grubego klienta” cała aplikacja ma bezpośredni dostęp do
bazy. W przypadku „cienkiego klienta” serwer sieciowy mo e sięgać do bazy danych za
pomocą odpowiedniego protokołu, który zwykle nie obsługuje specjalnych funkcji bazy.
Połączenie z bazą „cienkiego klienta” mo na zrealizować jako bezpośrednie, zapisane
w języku C z obudową w języku Java. Rozwiązanie „cienkiego klienta” zwykle realizuje
się za pomocą JDBC (ODBC zrealizowane w Javie), czyli standardowego mechanizmu
dostępu do danych w bazach relacyjnych, typowego dla większości (a mo e nawet dla
wszystkich) baz danych. Niektóre bazy danych oferują tak e bezpośrednie połączenie
Javy oparte na JDBC lub innym protokole. Porównanie tych dwóch rozwiązań: „cienkiego
klienta” i „grubego klienta” mo na znaleźć w ka dej dobrej ksią ce o JDBC. „Gruby klient”
mo e być wydajniejszy. W tym rozdziale skorzystamy z JDBC („cienki klient”), gdy
jest to rozwiązanie ogólne, dostępne w większości baz danych — zwykle wystarczające.


Alternatywa dla Javy to u ycie języka skryptowego Tcl/Tk. Ma on kilka zalet: łatwo mo na
go rozszerzać, bez trudu mo na go łączyć z językiem C i ró nymi pakietami oprogramo-
wania. Niestety, nie jest tak popularny jak Java czy JavaScript, ale warto się zastanowić
nad tym wyborem, szczególnie jeśli Tcl/Tk jest dostępny w u ywanym systemie. Język
Tcl/Tk świetnie nadaje się do tworzenia prototypów, gdy nie są uwzględniane typy danych,
a struktury danych są elastyczne, poza tym język ten dysponuje wieloma wbudowanymi
mo liwościami. W Sieci są dostępne rozszerzenia łączności z bazami Oracle, Sybase i in-
nymi, istnieją darmowe serwery HTTPD dostępne wraz z kodem źródłowym, w tym jeden
autorstwa Scriptics. Znane są jeszcze lepsze serwery sieciowe i aplikacje napisane w Tcl/Tk,
w tym serwer działający na stronie AOL, którego zaletą jest wbudowana łączność z bazami
danych. Wadą jest mała popularność Tcl/Tk, co wpływa na utrudnienia w dostępie do
pomocy i mniejszą liczbę darmowych pakietów, skromniejsze mo liwości i wolniejszą
reakcję na pojawiające się nowinki techniczne. Jednak ci, którzy znają Tcl/Tk, mogą
w kilka dni stworzyć dobrze działający serwer danych XML, korzystając z darmowych
komponentów. Jest to świetna metoda tworzenia prototypu takiego serwera.

Inne języki skryptowe to Perl i Python. Perl zawiera mnóstwo modułów obsługujących
CGI i umo liwia łączność z bazami danych. Coraz większa grupa programistów korzysta
z tego języka, gdy umo liwia programowanie obiektowe oraz posiada sprawne algorytmy.

Osoby, które chciałyby zbudować serwer danych XML oparty na relacyjnej bazie danych,
a nie mają dostępu do bazy komercyjnej, mogą skorzystać z darmowej bazy mysql, która
jest obsługiwana w wielu językach skryptowych.

QUVúR MNKGPVC
Kiedy u ywamy sieciowego serwera danych, aplikacje klienckie uzyskują do niego dostęp
za pomocą adresu URL. Adres ten mo e zawierać większość informacji, a nawet wszyst-
kie, które są potrzebne, by mieć dostęp do danych, zaś dane zapisywane w bazie mogą
być wysyłane metodą POST. Jeśli chcielibyśmy mieć dostęp do danych z serwera XML,
trzeba zastanowić się nad takimi zagadnieniami:
W jaki sposób zyskamy dostęp do serwera sieciowego?
Jak nale y podawać adres URL, aby umo liwić dostęp do bazy danych?
Jakie są najwa niejsze wyzwania projektowe?
Nale y u yć jednego adresu URL czy wielu?
Jakie warunki decydują o konstrukcji adresu URL?

Oto sposoby, mo liwości tworzenia adresu URL:
Jeden adres URL, wszystkie informacje przekazywane są metodą POST
pojedynczego dokumentu.
Jeden adres URL, większość informacji przekazywana jest metodą POST
i jako parametry GET.
Ró ne adresy URL, które spełniają ró ne funkcje.


Wszystkie dane i polecenia mogą być umieszczane w dokumencie, a następnie przesyłane
pod jednym adresem URL. Zaletą takiego rozwiązania jest przenoszenie wszystkich danych
jako XML (dzięki czemu rozwiązanie jest zgodne z innymi metodami). Wada to koniecz-
ność parsowania dokumentów (przynajmniej wstępnego), zanim zostanie podjęta decyzja,
które dane mają być wysłane. Jeśli na przykład mo na wprowadzić nowe dane lub zak-
tualizować istniejące, to wybór odpowiedniej operacji mo e wymagać częściowego przy-
najmniej parsowania dokumentu. Przekazywanie częściowo sparsowanego strumienia
danych innemu parserowi jest trudne, o ile w ogóle mo liwe. Jednak takie rozwiązanie
jest przydatne, kiedy mo na od razu przeanalizować cały dokument. U ycie pojedyn-
czego dokumentu to optymalne rozwiązanie, kiedy z serwerem danych XML współpra-
cuje wiele aplikacji.

Kiedy u ytkownicy kontaktują się z serwerem danych XML za pośrednictwem stron
sieciowych i formularzy HTML, łatwiejsze jest przekazywanie danych metodami POST
i GET. Jest to najlepsze rozwiązanie, kiedy mamy do czynienia z niewielkim zbiorem
poleceń i niewielką ilością strukturalnych danych. Jeśli na przykład nale y przeglądać
dane i zadawać zapytania za pośrednictwem prostych formularzy, parametry mo na prze-
kazywać w wierszu adresu. W tej ksią ce postąpimy najlepiej jak potrafimy — z peda-
gogicznego punktu widzenia — u yjemy metod POST/GET, dane strukturalne przeka emy
jako XML, podając kod XML jako część adresu URL.

Zastosowanie odrębnych adresów URL i przypisanie ich do innej funkcji lub jednego
adresu i wskazywanie funkcji w parametrach to kwestia stylu programowania, choć
w zale ności od stosowanych technik programistycznych jedno z tych rozwiązań mo e
być prostsze w implementacji.

Adresy URL mo na podawać w przeglądarce sieciowej, w formularzu HTML, z apletu,
aplikacji, ze skryptu CGI lub w jakikolwiek inny sposób zapisany w HTTP.

CFQYCPKG FCP[EJ
Załadowanie danych XML do istniejącej bazy relacyjnej (lub obiektowej) stanowi po-
dwójne wyzwanie: semantyczne i techniczne. Pierwsze polega na odwzorowaniu semantyki
XML, czyli przekształceniu danych XML w relacje — na przykład elementu RGTUQP
w tabelę RGTUQPPGN. Kiedy dokument XML jest projektowany z myślą o istniejącej bazie
relacyjnej, odwzorowania powinny być proste. W dokumencie XML mogą wystąpić takie
znaczniki, którym nie odpowiadają adne obiekty bazy; dane tego rodzaju mo na pominąć
lub nale y tak zmodyfikować bazę, aby je uwzględnić.

Trudność odwzorowywania dokumentów XML w relacje pojawia się, kiedy semantyka
XML i relacyjnej bazy danych częściowo się pokrywa. Na przykład dane XML, które
pochodzą z jednego systemu, mogą zawierać informacje o pracownikach zatrudnionych
etatowo, tymczasowo i na umowę zlecenia, zaś w bazie relacyjnej wszystkim tym gru-
pom pracowników mogą odpowiadać odrębne relacje. W zasadzie problem jest podobny
do tego, który wią e się z łączeniem wielu baz danych. W takiej sytuacji przydają się
doświadczenia związane z du ymi bazami danych oraz scalaniem ró nych baz, szcze-
gólnie jeśli bazy oparte były na ró nych modelach danych.

Drugi rodzaj problemu, techniczny — to sposób odwzorowania hierarchicznych danych
XML, przekształcenia ich na płaskie relacje. Chodzi o to, ekiedy dojdzie do odwzoro-
wania, zapis danych w formie relacji wymaga „spłaszczenia” danych.


OKCPC UVTWMVWT[ FCP[EJ :/.

W przypadku przechowywania danych XML w gotowej bazie relacyjnej lub obiektowej
mogą się przydać cztery wymienione rozwiązania.

Specjalny skrypt — to najprostszy, choć najmniej ogólny sposób. Polega na stworzeniu
specjalnego programu, który odczyta i sparsuje dokument XML, a następnie wstawi dane
do odpowiednich tabel.

Ograniczenie struktury — dokument XML mo na przekształcić (na przykład za pomocą
XSLT) w strukturę podobną do relacji bazy danych. Elementy zagnie d one mo na za-
stąpić wartościami odpowiednich identyfikatorów, zaś ich treść umieścić w innej czę-
ści dokumentu, która zostanie utworzona później. Połączenie elementu „rodzica” z elemen-
tem w nim zagnie d onym dokonuje się przez klucz obcy lub tabelę łączącą w relacyjnej
bazie danych. W wydruku 5.5 mikromatryca podło y z zagnie d onymi informacjami
o genach mo e być zastąpiona dwoma zbiorami płaskich rekordów, gdzie podło a będą od-
woływały się do genów, korzystając z identyfikatora. Przykłady doświadczeń z mikro-
matrycą są podobne do opisanych w punkcie 2.3.3 eksperymentów hybrydyzacji na filtrze,
ale przy okazji mierzona jest tak e liczba genów, które połączyły się z DNA matrycy.

9[FTWM Zagnieżdżone rekordy przeznaczone do załadowania

!ZON XGTUKQP !
TQQV
URQV
ITKF ITKF
XGTUKQP
RQUKVKQP #RQUKVKQP
IGPG
PCOG 6;4PCOG
FGUETKRVKQP '*;41)'0'# 24'('0#67FGUETKRVKQP
RCVJYC[ $+15;06'# 6;41;0;RCVJYC[
QTICPKUO FTQ F GQTICPKUO
IGPG
URQV
URQV
ITKF ITKF
XGTUKQP
RQUKVKQP #RQUKVKQP
IGPG
PCOG )4PCOG
FGUETKRVKQP 4'6'0%,# )1.)+ 2416'+0;FGUETKRVKQP
RCVJYC[ 9;+'.#0+'RCVJYC[
QTICPKUO FTQ F GQTICPKUO
IGPG
URQV
TQQV

Tworzenie połączeń — w czasie ładowania mo na sprawdzać na przykład format danych
poprzez proste zapytania. Ułatwia to ładowanie tabel mających klucze obce.


Przekształcenia — jeśli u ywamy bazy danych opartej na innym modelu danych ni XML,
dobrym pomysłem mo e być przekształcenie XML. Kiedy rolę klienta pełni u ytkownik,
a nie inna aplikacja, właściwe będzie sformatowanie danych jako XML, zanim zostaną
załadowane do bazy, szczególnie w przypadku interaktywnego procesu wprowadzania
lub edycji danych, gdy drobne poprawki pojawiają się na zmianę z zapytaniami. Du ym
atutem stosowanego w takich systemach XML jest realizacja zapytań. Istnieją ró ne
techniki, za pomocą których mo na tworzyć dane i korzystać z formularzy do edycji.

W niektórych sytuacjach, aby załadować dane XML do bazy relacyjnej, mo na u yć ogól-
nego narzędzia. Warunkiem jest, eby preprocesor mógł przekształcać hierarchiczne dane
XML w płaskie relacje. Jedna z mo liwości to zastosowanie arkuszy stylów XSL do prze-
kształcenia specyficznej postaci XML na ogólną postać rekordów, które mo na załadować
za pomocą aplikacji języka Java. Jeśli jednak danych jest du o, konieczne mo e być za-
stosowanie mechanizmu, który nie będzie przetwarzał danych w pamięci — na przykład
u ycie parsera SAX (opisanego w dodatku B).

Aplikacja ładująca dane mo e być samodzielnym programem lub znajduje się na serwerze,
co pozwala przesłać dane XML do serwera HTTP i ładować do bazy. Poprzez Sieć dane
mo na ładować na dwa sposoby: przez dokument XML lub metodami HTTP — POST/GET.
Informacje o bazie danych i transakcjach mo na podać w parametrach POST/GET lub
w dokumencie XML. Dokument ten mo e zawierać informacje potrzebne do załadowania
danych w formie elementów lub atrybutów, zaś ładowane dane mogą być jednym z ele-
mentów dokumentu. U ycie dokumentu XML jest ogólniejszą metodą ładowania danych
generowanych przez aplikację, ale u ycie metod POST/GET pozwala wprowadzać dane
ręcznie w formularzach HTML.

CFQYCPKG FCP[EJ LCMQ RCTCOGVTÎY 74.

Parametrów POST mo na u yć do przekazania informacji o ładowaniu danych, elemen-
tów oraz atrybutów. W przypadku elementu płaskiego parametry są wyliczane według
nazwy. Struktury hierarchiczne są bardziej skomplikowane, ale mo na je tworzyć, wyko-
rzystując hierarchię nazw. W takiej hierarchii podelementy elementu głównego są wyliczane
według nazw, z kolei ich podelementy są nazywane przez połączenie ich nazw z nazwami
„rodziców” (z u yciem separatora).

Innym problemem, związanym ze stosowaniem formularzy HTML do przekazywania
informacji w parametrach, jest to, e niektóre parametry mogą być potrzebne aplikacji.
Na przykład formularz mo e ustawiać zmienną 5WDOKV, konto bazy danych i punkt wejścia
(nazwę tabeli lub klasę obiektu). Mo na postępować na cztery sposoby: jednoznacznie
identyfikować zmienne aplikacji, jednoznacznie identyfikować zmienne u ytkownika,
jednoznacznie identyfikować jedne i drugie lub w ogóle się tym nie przejmować. Nazwy
zmiennych identyfikuje się, stosując przedrostki, na przykład A, XCTA, ZONA, CRRA lub WUGTA.

By uprościć tworzenie formularza, mo na umieszczać polecenia XML w wartościach
parametrów. Jeśli na przykład konieczne jest utworzenie niepowtarzalnego identyfikatora,
mo na u yć polecenia nakazującego utworzyć taki identyfikator w trakcie ładowania, na
przykład UGSWGPEGAIGPGTCVG UGSWGPEG VTCPUCEVKQPAUGS .


CFQYCPKG FCP[EJ FQMWOGPVÎY :/.
Dokumenty XML, które chcemy załadować, mogą pochodzić z innej aplikacji, źródła
zewnętrznego (bazy danych, zwykłego pliku) lub z formularza. Jednym ze sposobów
utworzenia dokumentu XML na podstawie danych z formularza jest wykorzystanie
skryptu lub programu formatującego dane z formularza HTML jako XML. Mo na te
u yć apletu języka Java. Dokładniej temat ten omówimy w rozdziale 7.

Autor napisał w języku Java program ładujący dane do bazy relacyjnej, T.QCF. Wydruk 5.6
pokazuje kod źródłowy T.QCF. Aplikacja ładuje dane XML w dwóch etapach:
Pierwszy polega na przekształceniu danych XML za pomocą arkuszy XSL
na dokument XML, składający się ze znaczników TGEQTF i HKGNF, które odpowiadają
ładowanym tabelom oraz metadanych opisujących ładowanie danych. Na przykład
dokument z wydruku 5.7 mo na przekształcić za pomocą arkusza stylów
na dokument XML T.QCF (zobacz wydruk 5.8). Arkusze stylów zostaną
dokładniej omówione w rozdziale 7., ale prosty arkusz, który w przykładzie
z mikromatrycą przekształca geny, przedstawia wydruk 5.9.
Drugi etap to ładowanie danych TGEQTFHKGNF do bazy za pomocą parsera SAX.
Dokument XML TGEQTFHKGNF, nazywany dokumentem TNQCF, składa się
z elementów TGEQTF i HKGNF, a tak e metadanych, które spełniają następujące
zadania:
Wskazują, w której tabeli powinien być umieszczony dany rekord. Rekordy
przeznaczone do ró nych tabel mogą się przeplatać w dokumencie. Poza tym
rekord przeznaczony do jednej tabeli mo e być zagnie d ony w rekordzie
ładowanym do innej tabeli. Upraszcza to generację dokumentu XML TNQCF.
Informują o tym, czy rekord zagnie d ony ma być załadowany przed,
czy za rekordem, w którym jest zagnie d ony. Wpływa to na większą
elastyczność definiowania, zwłaszcza w przypadku rekordów, które mo na
zdefiniować w arkuszu XSL bez względu na klucz obcy. Na przykład
w dokumencie XML pracownik mo e zawierać wydział, w którym dana osoba
pracuje, tak samo wydział mo e zawierać listę zatrudnionych w nim osób.
W trakcie ładowania rekord niezale ny mo e zostać utworzony jako pierwszy,
potem mogą być tworzone rekordy zale ne, bez względu na to który rekord
jest zagnie d onym, a który elementem otaczającym.
Wskazują, e wartość pola powinna być u yta do generacji wartości
przez generator sekwencji w bazie danych.
Wskazują, e wartość pola ma być pobrana z generatora sekwencji bazy danych.
Tak więc rekord zale ny mo e odwoływać się do niepowtarzalnego identyfikatora
wygenerowanego dla rekordu nadrzędnego.
Wskazują, e białe znaki powinny być z wartości odrzucone bądź znormalizowane.
Wskazują, e wartość powinna być identyfikatorem rekordu w innej tabeli,
której dana kolumna ma wartość równą polu elementu. Pozwala to tworzyć
klucze obce na podstawie identyfikatorów generowanych przez bazę danych,
zaś klucze alternatywne lub kolumny o niepowtarzalnych wartościach mogą
być u ywane przy wprowadzaniu i ładowaniu danych.


9[FTWM Kod Java programu ładującego dane XML, rLoad

) ÎYPC MNCUC CFWLæEC FCPG :/. FQ TGNCE[LPGL DC[ FCP[EJ

KORQTV QTIZONUCZJGNRGTU2CTUGT(CEVQT[
KORQTV EQOKDOZONRCTUGTU1/2CTUGT
KORQTV QTIYEFQOQEWOGPV
KORQTV LCXCKQ+1'ZEGRVKQP
KORQTV EQOZYGCXGZONFDWVKNTFD

RWDNKE ENCUU .QCF:/. ]
RWDNKE UVCVKE 1TCENG$ QTCENG$ PWNN
RWDNKE .QCF:/.
]
UWRGT

_
RWDNKE UVCVKE 1TCENG$ IGV1TCENG$
]
KH
QTCENG$ PWNN ]
VT[ ]
QTCENG$ PGY 1TCENG$
PGY ,$%#EEV
OITCXGUOITCXGU
QTCENG$EQPPGEV

_ ECVEJ
LCXCUSN53.'ZEGRVKQP GZ ]
GZRTKPV5VCEM6TCEG

_
_
TGVWTP QTCENG$
_
RWDNKE UVCVKE XQKF OCKP
LCXCNCPI5VTKPI=? CTIU ]
6WVCL YUVCYKè MQF KPKELWLæE[ CRNKMCELú
KH
CTIUNGPIVJ ]
5[UVGOGTTRTKPVNP
:/..QCF Y[OCICP[ LGUV RNKM LCMQ CTIWOGPV
_

PGY .QCF:/.
RCTUG
CTIU=?
_
RWDNKE XQKF RCTUG
5VTKPI ZON(KNG ]
5VTKPI RCTUGT%NCUU EQOKDOZONRCTUGTU5#:2CTUGT
VT[ ]
2CTUGT RCTUGT 2CTUGT(CEVQT[OCMG2CTUGT
RCTUGT%NCUU
*CPFNGT$CUG JCPFNGT PGY ,$%.QCF*CPFNGT

RCTUGTUGVQEWOGPV*CPFNGT
JCPFNGT
RCTUGTUGV'TTQT*CPFNGT
JCPFNGT
VT[ ]
RCTUGTRCTUG
ZON(KNG
_ ECVEJ
5#:'ZEGRVKQP UG ]
UGRTKPV5VCEM6TCEG

_ ECVEJ
+1'ZEGRVKQP KQG ]
KQGRTKPV5VCEM6TCEG

_
_ ECVEJ
%NCUU0QV(QWPF'ZEGRVKQP GZ ]
GZRTKPV5VCEM6TCEG

_ ECVEJ
+NNGICN#EEGUU'ZEGRVKQP GZ ]
GZRTKPV5VCEM6TCEG

_ ECVEJ
+PUVCPVKCVKQP'ZEGRVKQP GZ ]
GZRTKPV5VCEM6TCEG

_
_


RWDNKE UVCVKE XQKF UGV1TCENG$
1TCENG$ PGY8CNWG ]
.QCF:/.QTCENG$ PGY8CNWG
_
_

Projektowanie baz danych XML. Vademecum profesjonalisty

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (8)

Ähnlich wie Projektowanie baz danych XML. Vademecum profesjonalisty

Ähnlich wie Projektowanie baz danych XML. Vademecum profesjonalisty (20)

Mehr von Wydawnictwo Helion

Mehr von Wydawnictwo Helion (20)

Projektowanie baz danych XML. Vademecum profesjonalisty