Darmowy fragment publikacji:
IDZ DO
IDZ DO
PRZYK£ADOWY ROZDZIA£
PRZYK£ADOWY ROZDZIA£
SPIS TREĎCI
SPIS TREĎCI
KATALOG KSI¥¯EK
KATALOG KSI¥¯EK
KATALOG ONLINE
KATALOG ONLINE
ZAMÓW DRUKOWANY KATALOG
ZAMÓW DRUKOWANY KATALOG
TWÓJ KOSZYK
TWÓJ KOSZYK
DODAJ DO KOSZYKA
DODAJ DO KOSZYKA
CENNIK I INFORMACJE
CENNIK I INFORMACJE
ZAMÓW INFORMACJE
ZAMÓW INFORMACJE
O NOWOĎCIACH
O NOWOĎCIACH
ZAMÓW CENNIK
ZAMÓW CENNIK
CZYTELNIA
CZYTELNIA
FRAGMENTY KSI¥¯EK ONLINE
FRAGMENTY KSI¥¯EK ONLINE
Projektowanie baz
danych XML.
Vademecum profesjonalisty
Autor: Mark Graves
T³umaczenie: Tomasz ¯mijewski
ISBN: 83-7197-667-4
Tytu³ orygina³u: Designing XML Databases
Format: B5, stron: 498
„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.
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
z klasycznych relacyjnych baz danych, nauczysz siê tworzyæ aplikacje
z wykorzystaniem XML. Zainteresowani tworzeniem baz danych XML „od zera”,
dowiedz¹ siê jak w pe³ni wykorzystaæ dostêpne narzêdzia.
Dodatkowo autor omawia:
oraz aplikacji XML
na plikach p³askich
• Najwa¿niejsze techniki projektowe baz danych, systemów obs³uguj¹cych te bazy
• Przechowywanie danych XML w bazach obiektowych, relacyjnych i opartych
• Zaawansowane techniki modelowania danych XML
• Zapytania kierowane do baz danych XML (uwagi praktyczne, techniki stosowania
• Sposób korzystania z sieciowych baz danych XML za pomoc¹ jêzyka XSL
• 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
JDBC oraz podstawy teoretyczne)
i jêzyka Java
„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
o specyficznych wymaganiach.
Wydawnictwo Helion
ul. Chopina 6
44-100 Gliwice
tel. (32)230-98-63
e-mail: helion@helion.pl
5RKUVTGħEK
9UVúR
4QFKCđ 9RTQYCFGPKG
1.1. XML...................................................y...................................................y..........................16
1.1.1. Czym jest XML? ...................................................y...............................................16
1.1.2. Skąd się wziął XML? ...................................................y........................................19
1.1.3. Czemu akurat XML? ...................................................y.........................................19
1.2. Systemy baz danych...................................................y...................................................y..22
1.2.1. Czym jest baza danych? ...................................................y....................................22
1.2.2. Czym jest baza danych XML?..................................................y............................24
1.2.3. Czemu używać baz danych XML?...................................................y....................25
1.3. Bazy danych dostępne w Sieci...................................................y.....................................26
1.3.1. Baza danych w plikach płaskich...................................................y........................26
1.3.2. Systemy zarządzania relacyjnymi bazami danych ...............................................29
1.3.3. Systemy zarządzania bazami danych XML...................................................y.......30
1.4. Aplikacje...................................................y...................................................y...................31
1.5. Dodatkowe informacje...................................................y.................................................32
1.5.1. Czasopisma...................................................y...................................................y.....32
1.5.2. Witryny ogólne ...................................................y..................................................32
1.5.3. Portale XML ...................................................y...................................................y...33
1.5.4. Narzędzia XML ...................................................y.................................................33
1.5.5. XSL...................................................y...................................................y...............
..33
1.5.6. Dokumenty W3C...................................................y...............................................33
1.5.7. Przykłady specyfikacji XML w konkretnych dziedzinach...................................34
1.5.8. Więcej informacji o XML ...................................................y.................................34
6YQTGPKGUEJGOCVW
2.1. Projektowanie bazy danych ...................................................y.........................................35
2.2. Modelowanie koncepcyjne ...................................................y..........................................38
2.2.1. Model koncepcyjny w formie grafów ...................................................y...............38
2.2.2. Proces modelowania koncepcyjnego za pomocą grafu ........................................42
2.2.3. Modelowanie koncepcyjne ...................................................y................................46
2.2.4. Model koncepcyjny XML ...................................................y.................................51
2.3. Modelowanie logiczne...................................................y.................................................53
2.3.1. Diagram encji i relacji ...................................................y.......................................53
2.3.2. Schemat relacyjny..................................................y...............................................54
2.3.3. Model obiektowy...................................................y...............................................55
2.3.4. Schemat logiczny XML...................................................y.....................................59
2.4. Modelowanie fizyczne...................................................y.................................................61
2.4.1. Schemat fizyczny XML...................................................y.....................................62
2.4.2. Przetwarzanie danych a przetwarzanie dokumentów...........................................65
2.4.3. Przenoszenie danych.................................................y............................................67
2.4.4. Atrybuty czy podelementy?...................................................y...............................68
2.5. Bibliografia ...................................................y...................................................y...............71
4QFKCđ
6
Projektowanie baz danych XML. Vademecum profesjonalisty
4QFKCđ
4QFKCđ
2QFUVCY[VGQTGV[EPG
3.1. Typy danych ...................................................y...................................................y.............73
3.1.1. XML Schema...................................................y...................................................y..74
3.1.2. Wprowadzanie strukturalnych typów danych ...................................................y...75
3.1.3. Aplikacje sterowane schematem ...................................................y.......................76
3.2. Systemy zarządzania bazami danych...................................................y...........................79
3.3. Standardy XML ...................................................y...................................................y........80
3.3.1. XML Schema (XSDL) ...................................................y......................................83
3.3.2. XSL...................................................y...................................................y...............
..83
3.3.3. Łącza, wskaźniki i ścieżki XML ...................................................y.......................83
3.3.4. XML Query ...................................................y...................................................y....84
3.3.5. Przestrzenie nazw XML ...................................................y....................................84
3.3.6. DOM...................................................y...................................................y...............85
3.4. Bazy danych XML...................................................y...................................................y....85
3.4.1. Schemat koncepcyjny ...................................................y........................................86
3.4.2. Zadania ...................................................y...................................................y...........87
3.4.3. Operacje...................................................y...................................................y..........88
3.5. Modelowanie danych...................................................y...................................................y89
3.5.1. Istniejące modele danych.................................................y.....................................91
3.5.2. Prosty model danych XML ...................................................y...............................94
3.5.3. Model danych XML zgodny ze specyfikacją W3C..............................................98
3.5.4. Relacyjny model danych XML ...................................................y.........................99
3.5.5. Model danych XML oparty na węzłach ...................................................y..........106
3.5.6. Model danych XML zbudowany na podstawie krawędzi ..................................110
3.5.7. Ogólny model danych XML...................................................y............................113
3.6. Bibliografia ...................................................y...................................................y.............118
2TGEJQY[YCPKGFCP[EJ
4.1. Funkcje przechowywania danych ...................................................y..............................121
4.1.1. Baza danych oparta na plikach płaskich...................................................y..........121
4.1.2. Obiektowa baza danych...................................................y...................................124
4.1.3. Relacyjna baza danych ...................................................y....................................130
4.2. Drobnoziarnisty schemat relacyjny ...................................................y...........................130
4.2.1. Projekt logiczny...................................................y...............................................131
4.2.2. Projekt fizyczny...................................................y...............................................134
4.2.3. Przykłady ...................................................y...................................................y......139
4.2.4. Implementacja ...................................................y.................................................142
4.3. Gruboziarnisty schemat relacyjny ...................................................y.............................165
4.4. Schemat relacyjny o średniej granulacji ...................................................y....................166
4.4.1. Punkty podziału ...................................................y...............................................167
4.4.2. Projekt bazy danych.................................................y...........................................168
4.4.3. Implementacja ...................................................y.................................................170
4.5. Uwagi praktyczne ...................................................y...................................................y...180
4QFKCđ #TEJKVGMVWTCU[UVGOWDCFCP[EJ
5.1. Architektura systemu ...................................................y.................................................181
5.1.1. Klient-serwer ...................................................y...................................................y183
5.1.2. Architektura trzywarstwowa..................................................y.............................185
5.2. Serwer sieciowy XML ...................................................y...............................................186
5.2.1. Możliwości implementacji ...................................................y..............................186
5.2.2. Dostęp klienta ...................................................y..................................................188
5.2.3. Ładowanie danych...................................................y...........................................189
5.2.4. Generacja XML ...................................................y...............................................202
5.3. Relacyjny serwer danych ...................................................y...........................................202
5.3.1. Żądania adresu URL...................................................y........................................204
5.3.2. Tworzenie zapytań SQL ...................................................y..................................205
4QFKCđ
4QFKCđ
4QFKCđ
5RKUVTGħ EK
7
5.3.3. Formatowanie wyników jako XML ...................................................y................206
5.3.4. Pobieranie danych słownikowych ...................................................y...................207
5.3.5. Implementacja ...................................................y.................................................210
5.4. Serwer danych XML...................................................y..................................................232
5.4.1. Implementacja ...................................................y.................................................235
5.5. Hybrydowy serwer łączący technologię relacyjną i XML ...........................................252
5.5.1. Implementacja ...................................................y.................................................253
5[UVGO[MQOGTE[LPG
6.1. Przegląd dostępnych rozwiązań...................................................y.................................259
6.2. Adaptery do baz danych ...................................................y............................................260
6.2.1. Narzędzia warstwy pośredniej...................................................y.........................261
6.2.2. Komercyjne relacyjne bazy danych...................................................y.................261
6.2.3. Narzędzia do obsługi zapytań...................................................y..........................262
6.3. Systemy zarządzania bazami danych...................................................y.........................262
6.4. Serwery danych XML...................................................y................................................263
6.4.1. dbXML ...................................................y...................................................y.........263
6.4.2. eXcelon...................................................y...................................................y.........263
6.4.3. Tamino...................................................y...................................................y..........263
6.5. Serwery dokumentów XML ...................................................y......................................263
6.6. Zasoby i witryny ...................................................y...................................................y....
.264
+PVGTHGLUWľ[VMQYPKMC
7.1. Przegląd ...................................................y...................................................y..................267
7.2. Interfejsy użytkownika XSL...................................................y......................................268
7.2.1. Arkusze stylów XSL...................................................y........................................268
7.2.2. Prezentacja danych XML jako tabeli...................................................y...............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...................................................y..280
7.3. Formy prezentacji wykorzystujące technologię Java ...................................................y284
7.3.1. Budowa klienta ...................................................y................................................284
7.3.2. Przykład z drzewem...................................................y.........................................287
7.4. Aplikacje prototypowe...................................................y...............................................293
CR[VCPKC
8.1. Rodzaje zapytań...................................................y...................................................y......299
8.2. Reprezentacja...................................................y...................................................y..........302
8.2.1. Dokumenty opisujące strukturę a dane opisujące relacje...................................302
8.2.2. Reprezentacje wykorzystujące węzły a reprezentacjey
wykorzystujące krawędzie...................................................y..............................303
8.2.3. Reprezentacja łączy ...................................................y.........................................305
8.2.4. Łącza XML zapisywane jako krawędzie...................................................y.........307
8.2.5. Zapisywanie łączy ...................................................y...........................................308
8.3. Mechanizmy obsługi zapytań ...................................................y....................................310
8.3.1. Zapytania według ścieżki ...................................................y................................310
8.3.2. Zapytania według drzewa...................................................y................................313
8.4. Zapytania wykorzystujące grafy ...................................................y................................314
8.4.1. Model danych korzystający z grafów...................................................y..............315
8.4.2. Wzorce korzystające z grafów...................................................y.........................316
8.4.3. Wizualizacja ...................................................y...................................................y.318
8.4.4. Implementacja SQL...................................................y.........................................319
8.4.5. Algorytm zapytań według grafu ...................................................y......................340
8.5. Narzędzia do tworzenia raportów ...................................................y..............................345
8.5.1. Użycie XSL do zapytań według ścieżek ...................................................y.........345
8.5.2. Zapytania według grafu ...................................................y...................................347
8
Projektowanie baz danych XML. Vademecum profesjonalisty
4QFKCđ
4QFKCđ
+PFGMUQYCPKG
9.1. Wprowadzenie ...................................................y...................................................y........349
9.2. Struktury danych elementów ...................................................y.....................................350
9.3. Strategie indeksowania ...................................................y..............................................350
9.3.1. Brak indeksowania ...................................................y..........................................351
9.3.2. Pełne indeksowanie ...................................................y.........................................351
9.3.3. Indeksowanie częściowe..................................................y...................................355
9.3.4. Indeksowanie związków między dokumentami .................................................358
9.4. Identyfikacja dokumentu ...................................................y...........................................360
9.5. Metody przeszukiwania ...................................................y.............................................362
+ORNGOGPVCELC
10.1. System notatek...................................................y...................................................y......365
10.2. Podstawy biologii ...................................................y...................................................y.366
10.3. Wymagania użytkownika ...................................................y........................................367
10.4. Model koncepcyjny...................................................y..................................................368
10.5. Opis aplikacji ...................................................y...................................................y........371
10.5.1. Klient ...................................................y...................................................y..........371
10.5.2. Warstwa pośrednia ...................................................y........................................378
10.6. Ograniczenia i rozszerzenia ...................................................y.....................................403
10.7. Uwagi praktyczne ...................................................y...................................................y.404
10.8. Skalowanie...................................................y...................................................y............404
10.8.1. Zarządzanie transakcjami ...................................................y..............................404
10.8.2. Bezpieczeństwo ...................................................y.............................................405
10.8.3. Odzyskiwanie danych...................................................y....................................405
10.8.4. Optymalizacja...................................................y................................................406
QFCVGM# 0CTúFKC,CXC
A.1. Domyślne ustawienia systemowe ...................................................y.............................407
A.2. Połączenie z relacyjną bazą danych ...................................................y..........................409
A.3. Wyniki działania serwleta...................................................y.........................................415
A.4. Interaktywny interfejs dostępu...................................................y..................................417
QFCVGM$
2CTUGT5#:
QFCVGM :/.5EJGOC úħè NGOGPVCT
Rekomendacja W3C, 2 maja 2001 r. ...................................................y................................423
Spis treści...................................................y...................................................y..............
.........424
1. Wprowadzenie ...................................................y...................................................y...........425
2. Podstawowe pojęcia: Zamówienie...................................................y................................426
2.1. Schemat opisujący zamówienia...................................................y..........................427
2.2. Definicje typów złożonych, deklaracje elementów i atrybutów............................429
2.3. Typy proste ...................................................y...................................................y......433
2.4. Definicje typów anonimowych...................................................y...........................438
2.5. Treść elementów...................................................y.................................................439
2.6. Adnotacje...................................................y...................................................y.........442
2.7. Tworzenie modeli zawartości...................................................y.............................443
2.8. Grupy atrybutów...................................................y.................................................444
2.9. Wartości Nil...................................................y...................................................y.....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 ...................................................y.....................449
3.3. Deklaracje globalne a deklaracje lokalne ...................................................y...........452
3.4. Niezadeklarowane docelowe przestrzenie nazw ...................................................y453
5RKUVTGħ EK
9
4. Zagadnienia zaawansowane II: Zamówienie międzynarodowe ......................................453
4.1. Schemat w szeregu dokumentów ...................................................y.......................454
4.2. Wyprowadzanie typów przez rozszerzenie ...................................................y........457
4.3. Użycie typów pochodnych w dokumentach...................................................y.......457
4.4. Wyprowadzanie typów złożonych przez ograniczanie .........................................458
4.5. Przedefiniowywanie typów i grup...................................................y......................460
4.6. Grupy podstawienia...................................................y............................................462
4.7. Elementy i typy abstrakcyjne ...................................................y.............................463
4.8. Kontrolowanie tworzenia i użycia typów pochodnych .........................................464
5. Zagadnienia zaawansowane III: Raport kwartalny...................................................y.......466
5.1. Wymuszanie niepowtarzalności ...................................................y.........................468
5.2. Definiowanie kluczy i wskaźników...................................................y....................469
5.3. Reguły w XML Schema a atrybut ID XML 1.0 ...................................................y.469
5.4. Importowanie typów...................................................y...........................................469
5.5. Dowolny element, dowolny atrybut ...................................................y...................472
5.6. schemaLocation ...................................................y..................................................475
5.7. Zgodność ze schematem...................................................y.....................................476
A. Podziękowania ...................................................y...................................................y..........478
B. Typy proste i ich fazy...................................................y...................................................y478
C. Użycie encji...................................................y...................................................y...............478
D. Wyrażenia regularne ...................................................y...................................................y.480
E. Indeks ...................................................y...................................................y........................481
5MQTQYKF
Rozdział 5.
#TEJKVGMVWTC
U[UVGOWDCFCP[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.
#TEJKVGMVWTCU[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ć nśa 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 poszśczegó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.
182
Projektowanie baz danych XML. Vademecum profesjonalisty
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 trzyśwarstwowej 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ć technolośgię jednej firmy?
Czy system powinien być niezależny od dostawcy oprograśmowania warstwy
pośredniej?
Czy interfejs użytkownika ma przyjmować schemat bazy dśanych
(minimalizowanie wpływu częstych zmian opisywanej dzieśdziny)?
Czy, z uwagi na duże ilości danych, należy ograniczśać ilość przesyłanych
informacji z bazy danych?
Czy — by spełnić wymogi bezpieczeństwa — kontrola dostępu dśo 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 rśozszerzaniu 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.
184
Projektowanie baz danych XML. Vademecum profesjonalisty
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ć wyśgodne.
9[FTWM Kod SQL generujący fragment tabeli wydziałów przyknładowej bazy danych Scott/Tiger
UGNGEV FGRVFGRVPQ ^^FGRVPQ^^ FPCOG ^^FPCOGR^^ NQE ^^NQE^^
HTQOFGRV
9[FTWM Skrypt generujący dokument XML dla tabeli wydziałów przykładowej bazy danych Scott/Tiger
DKPUJ
GEJQ !ZONXGTUKQP !
GEJQ EQNNGEVKQP
USNRNWUUEQVVVKIGT 1(
UGNGEV FGRVFGRVPQ ^^FGRVPQ^^ FPCOG ^^FPCOGR^^ NQE ^^NQE^^
HTQOFGRV
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ć informśacje 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 atnrybutów XML
RTQEGFWTGYTKVG:/.#VVTKDWVGU
VCDNG
RTKPV !ZONXGTUKQP !
RTKPV EQNNGEVKQP
HQTGCEJTQYKPVCDNG
RTKPV VCDNGPCOG
HQTGCEJEQNWOPKPTQY
RTKPVEQNWOPPCOG XCNWG
4QFKC đ Architektura systemu baz danych
185
GPF
RTKPV
GPF
RTKPV EQNNGEVKQP
GPF
9[FTWM Procedura zapisu danych z relacyjnej tabeli jako pondelementów
RTQEGFWTGYTKVG:/. ODGF NGOGPVU
VCDNG
RTKPV !ZONXGTUKQP !
RTKPV EQNNGEVKQP
HQTGCEJTQYKPVCDNG
RTKPV TGEQTF
HQTGCEJEQNWOPKPTQY
RTKPV EQNWOPPCOG
RTKPVXCNWG
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ść.
#TEJKVGMVWTCVT[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 baśzy
danych i udostępniać te dane klientowi. Można zastosśować zwykły serwer
sieciowy, serwer sieciowy ze skryptami CGI, serwer z sśerwletami, serwer z JSP,
komercyjne oprogramowanie warstwy pośredniej z dostęśpem do baz danych
lub serwer aplikacji.
186
Projektowanie baz danych XML. Vademecum profesjonalisty
4[UWPGM
Trzywarstwowa
architektura
sieciowego systemu
baz danych
Klient — zawiera interfejs użytkownika, który pozwala korzysśtać 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?
5GTYGTUKGEKQY[:/.
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 serśwera.
/QľNKYQħEKKORNGOGPVCELK
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
4QFKC đ Architektura systemu baz danych
187
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 wszysśtkimi 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ć, zanśim 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.
188
Projektowanie baz danych XML. Vademecum profesjonalisty
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 prototyśpu 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 obiektowśe 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úRMNKGPVC
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 baśzy 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 jesśt metodą POST
i jako parametry GET.
Różne adresy URL, które spełniają różne funkcje.
4QFKC đ Architektura systemu baz danych
189
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 zśapisany w HTTP.
ĐCFQYCPKGFCP[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; dśane 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 danycśh.
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łaszcześnia” danych.
190
Projektowanie baz danych XML. Vademecum profesjonalisty
OKCPCUVTWMVWT[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órśe połączyły się z DNA matrycy.
9[FTWM Zagnieżdżone rekordy przeznaczone do załadowania
!ZONXGTUKQP !
TQQV
URQV
ITKF ITKF
XGTUKQP
RQUKVKQP # RQUKVKQP
IGPG
PCOG 6;4 PCOG
FGUETKRVKQP *; 41) 0 #24 ( 0#67 FGUETKRVKQP
RCVJYC[ $+15;06 #6;41 ;0; RCVJYC[
QTICPKUO FTQľFľG QTICPKUO
IGPG
URQV
URQV
ITKF ITKF
XGTUKQP
RQUKVKQP # RQUKVKQP
IGPG
PCOG )4 PCOG
FGUETKRVKQP 4 6 0 ,#)1.)+2416 +0; FGUETKRVKQP
RCVJYC[ 9; + .#0+ RCVJYC[
QTICPKUO FTQľFľG QTICPKUO
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.
4QFKC đ Architektura systemu baz danych
191
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.
ĐCFQYCPKGFCP[EJLCMQRCTCOGVTÎY74.
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 UGSWGPEGAIGPGTCVGUGSWGPEG VTCPUCEVKQPAUGS .
192
Projektowanie baz danych XML. Vademecum profesjonalisty
ĐCFQYCPKGFCP[EJFQMWOGPVÎ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 ładowaniśe danych. Na przykład
dokument z wydruku 5.7 można przekształcić za pomocą arkśusza 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 dokuśmencie. Poza tym
rekord przeznaczony do jednej tabeli może być zagnieżśdżony w rekordzie
ładowanym do innej tabeli. Upraszcza to generację dokuśmentu XML TNQCF.
Informują o tym, czy rekord zagnieżdżony ma być załadowśany przed,
czy za rekordem, w którym jest zagnieżdżony. Wpływa toś na większą
elastyczność definiowania, zwłaszcza w przypadku rekorśdó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ę zatrudnśionych w nim osób.
W trakcie ładowania rekord niezależny może zostać utwśorzony jako pierwszy,
potem mogą być tworzone rekordy zależne, bez względu nśa to który rekord
jest zagnieżdżonym, a który elemente
Pobierz darmowy fragment (pdf)
