Projektowanie baz danych XML. Vademecum profesjonalisty

2,293 views

Published on

"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:

* Najważniejsze techniki projektowe baz danych, systemów obsługujących te bazy oraz aplikacji XML
* Przechowywanie danych XML w bazach obiektowych, relacyjnych i opartych 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 o specyficznych wymaganiach.

Published in: Technology, News & Politics
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,293
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Projektowanie baz danych XML. Vademecum profesjonalisty

  1. 1. 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
  2. 2. 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
  3. 3. 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
  4. 4. 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
  5. 5. 8 Projektowanie baz danych XML. Vademecum profesjonalisty 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
  6. 6. 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
  7. 7. 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.
  8. 8. 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 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.
  9. 9. 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.
  10. 10. 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ć 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
  11. 11. 4QFKC Architektura systemu baz danych 185 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.
  12. 12. 186 Projektowanie baz danych XML. Vademecum profesjonalisty 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
  13. 13. 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 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.
  14. 14. 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 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.
  15. 15. 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 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.
  16. 16. 190 Projektowanie baz danych XML. Vademecum profesjonalisty 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.
  17. 17. 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. 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 .
  18. 18. 192 Projektowanie baz danych XML. Vademecum profesjonalisty 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.
  19. 19. 4QFKC Architektura systemu baz danych 193 9[FTWM Kod Java programu ładującego dane XML, rLoad
  20. 20. .QCF:/.LCXC
  21. 21. RCEMCIG EQOZYGCXGZONFDTNQCF
  22. 22. ) ÎYPC MNCUC CFWLæEC FCPG :/. FQ TGNCE[LPGL DC[ FCP[EJ
  23. 23. KORQTV QTIZONUCZ
  24. 24. KORQTV QTIZONUCZJGNRGTU2CTUGT(CEVQT[ KORQTV EQOKDOZONRCTUGTU1/2CTUGT KORQTV QTIYEFQOQEWOGPV KORQTV LCXCKQ+1'ZEGRVKQP KORQTV EQOZYGCXGZONFDWVKNTFD
  25. 25. 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 _ _
  26. 26. 194 Projektowanie baz danych XML. Vademecum profesjonalisty RWDNKE UVCVKE XQKF UGV1TCENG$ 1TCENG$ PGY8CNWG ] .QCF:/.QTCENG$ PGY8CNWG _ _
  27. 27. 4GEQTFLCXC
  28. 28. RCEMCIG EQOZYGCXGZONFDTNQCF
  29. 29. CYKGTC KPHQTOCELG Q TGMQTFKG
  30. 30. KORQTV LCXCNCPI
  31. 31. KORQTV EQOZYGCXGZONFDWVKNTFD4$ RWDNKE ENCUU 4GEQTF ] RWDNKE 5VTKPI VCDNG RTQVGEVGF 5VTKPI$WHHGT HKGNF0COG$WHHGT PWNN RTQVGEVGF 5VTKPI$WHHGT HKGNF8CNWG$WHHGT PWNN RTQVGEVGF 5VTKPI$WHHGT UWDS9JGTG$WHHGT PWNN RTQVGEVGF 5VTKPI$WHHGT UWDS(TQO$WHHGT PWNN RTKXCVG KPV PWO5WDS RTKXCVG DQQNGCP KP5WDS HCNUG RTKXCVG DQQNGCP FGNC[ HCNUG RWDNKE 4GEQTF ] UWRGT _ RWDNKE XQKF CFF(KGNF'ZRT 5VTKPI XCNWG ] KH IGV(KGNF8CNWG$WHHGT NGPIVJ ] IGV(KGNF8CNWG$WHHGT CRRGPF _ KP5WDS HCNUG IGV(KGNF8CNWG$WHHGT CRRGPF XCNWG _ RWDNKE XQKF CFF(KGNF0COG 5VTKPI PCOG ] KH IGV(KGNF0COG$WHHGT NGPIVJ ] IGV(KGNF0COG$WHHGT CRRGPF _ IGV(KGNF0COG$WHHGT CRRGPF PCOG _ RWDNKE XQKF CFF(KGNF5WDS 5VTKPI XCNWG ] KH IGV5WDS9JGTG$WHHGT NGPIVJ ] IGV5WDS9JGTG$WHHGT CRRGPF #0 IGV5WDS(TQO$WHHGT CRRGPF _ RQFKC U QYC MNWEQYGIQ PC KPV KPFGZ XCNWGKPFGZ1H KPV KH KPFGZ ] IGV5WDS9JGTG$WHHGT CRRGPF $ ä XCNWG PKGPCP[ TGVWTP _ 5VTKPI VCDNG XCNWGUWDUVTKPI KPFGZ 5VTKPI EQNWOP XCNWGUWDUVTKPI KPFGZ FQFCPKG FQ DWHQTÎY PWO5WDS CFF(KGNF'ZRT USV +PVGIGTVQ5VTKPI PWO5WDS KF KP5WDS VTWG IGV5WDS9JGTG$WHHGT CRRGPF USV +PVGIGTVQ5VTKPI PWO5WDS EQNWOP IGV5WDS(TQO$WHHGT CRRGPF VCDNG USV +PVGIGTVQ5VTKPI PWO5WDS _
  32. 32. 4QFKC Architektura systemu baz danych 195 RWDNKE XQKF CFF(KGNF8CNWG 5VTKPI XCNWG ] KH KP5WDS VTWG ] PQVG KPVGTCEVKQP YKVJ CFF(KGNF5WDS IGV5WDS9JGTG$WHHGT CRRGPF XCNWG KP5WDS HCNUG TGVWTP _ KH IGV(KGNF8CNWG$WHHGT NGPIVJ ] IGV(KGNF8CNWG$WHHGT CRRGPF _ 9 TCKG RQVTGD[ 1TCENG RQRTCYPKG KPVGTRTGVWLG C EWEJ LCMQ NKEDú IGV(KGNF8CNWG$WHHGT CRRGPF XCNWG _ RTQVGEVGF DQQNGCP IGVGNC[ ] TGVWTP FGNC[ _ RTQVGEVGF 5VTKPI$WHHGT IGV(KGNF0COG$WHHGT ] KH HKGNF0COG$WHHGT PWNN ] HKGNF0COG$WHHGT PGY 5VTKPI$WHHGT _ TGVWTP HKGNF0COG$WHHGT _ RTQVGEVGF 5VTKPI$WHHGT IGV(KGNF8CNWG$WHHGT ] KH HKGNF8CNWG$WHHGT PWNN ] HKGNF8CNWG$WHHGT PGY 5VTKPI$WHHGT _ TGVWTP HKGNF8CNWG$WHHGT _ RWDNKE UVCVKE 4GEQTF IGV(TGG4GEQTF ] TGVWTP PGY 4GEQTF _ RWDNKE 5VTKPI IGV53.+PUGTV5VTKPI ] 5VTKPI$WHHGT DWH PGY 5VTKPI$WHHGT DWHCRRGPF KPUGTV KPVQ DWHCRRGPF IGV6CDNG DWHCRRGPF IGV(KGNF0COG$WHHGT KH PWO5WDS ] DWHCRRGPF UGNGEV DWHCRRGPF IGV(KGNF8CNWG$WHHGT DWHCRRGPF HTQO IGV5WDS(TQO$WHHGT DWHCRRGPF YJGTG IGV5WDS9JGTG$WHHGT _ GNUG ] DWHCRRGPF XCNWGU DWHCRRGPF IGV(KGNF8CNWG$WHHGT _ TGVWTP DWHVQ5VTKPI _ RTQVGEVGF 5VTKPI$WHHGT IGV5WDS(TQO$WHHGT ] KH UWDS(TQO$WHHGT PWNN ] UWDS(TQO$WHHGT PGY 5VTKPI$WHHGT _ TGVWTP UWDS(TQO$WHHGT _ RTQVGEVGF 5VTKPI$WHHGT IGV5WDS9JGTG$WHHGT ] KH UWDS9JGTG$WHHGT PWNN ] UWDS9JGTG$WHHGT PGY 5VTKPI$WHHGT _
  33. 33. 196 Projektowanie baz danych XML. Vademecum profesjonalisty TGVWTP UWDS9JGTG$WHHGT _ RWDNKE 5VTKPI IGV6CDNG ] TGVWTP VCDNG _ RWDNKE XQKF RTKPV ] 5[UVGOQWVRTKPVNP IGV53.+PUGTV5VTKPI VT[ ] KH .QCF:/.IGV1TCENG$ GZGEWVG7RFCVG IGV53.+PUGTV5VTKPI ] 5[UVGOQWVRTKPVNP PKG CFKC C Q _ GNUG ] 5[UVGOQWVRTKPVNP CFKC C Q _ _ ECVEJ LCXCUSN53.'ZEGRVKQP GZ ] GZRTKPV5VCEM6TCEG 5[UVGOQWVRTKPVNP PKG CFKC C Q _ _ RTQVGEVGF XQKF UGVGNC[ DQQNGCP PGY8CNWG ] VJKUFGNC[ PGY8CNWG _ RTQVGEVGF XQKF UGV(KGNF0COG$WHHGT 5VTKPI$WHHGT PGY8CNWG ] VJKUHKGNF0COG$WHHGT PGY8CNWG _ RTQVGEVGF XQKF UGV(KGNF8CNWG$WHHGT 5VTKPI$WHHGT PGY8CNWG ] VJKUHKGNF8CNWG$WHHGT PGY8CNWG _ RTQVGEVGF XQKF UGV5WDS(TQO$WHHGT 5VTKPI$WHHGT PGY8CNWG ] VJKUUWDS(TQO$WHHGT PGY8CNWG _ RTQVGEVGF XQKF UGV5WDS9JGTG$WHHGT 5VTKPI$WHHGT PGY8CNWG ] VJKUUWDS9JGTG$WHHGT PGY8CNWG _ RWDNKE XQKF UGV6CDNG 5VTKPI PGY8CNWG ] VJKUVCDNG PGY8CNWG _ _
  34. 34. ,$%.QCF*CPFNGTLCXC
  35. 35. RCEMCIG EQOZYGCXGZONFDTNQCF
  36. 36. CFQYCPKG FCP[EJ :/. FQ TGNCE[LPGL DC[ FCP[EJ
  37. 37. KORQTV QTIZONUCZ
  38. 38. KORQTV LCXCWVKN
  39. 39. RWDNKE ENCUU ,$%.QCF*CPFNGT GZVGPFU QTIZONUCZ*CPFNGT$CUG ] RTKXCVG 4GEQTF EWTTGPV4GEQTF PWNN RTKXCVG 5VCEM TGEQTF5VCEM PWNN RTKXCVG 8GEVQT RTKPV8GEVQT PWNN RTKXCVG DQQNGCP KP(KGNF HCNUG RTKXCVG DQQNGCP HKGNF'ORV[ VTWG RTKXCVG UJQTV YJKVGURCEG1R RTKXCVG HKPCN UVCVKE KPV 9*+6'52#%'A12A010' RTKXCVG HKPCN UVCVKE KPV 9*+6'52#%'A12A64+/ RTKXCVG HKPCN UVCVKE KPV 9*+6'52#%'A12A4'/18' RWDNKE ,$%.QCF*CPFNGT ] UWRGT _
  40. 40. 4QFKC Architektura systemu baz danych 197 RWDNKE XQKF EJCTCEVGTU EJCT=? EJCTU KPV UVCTV KPV NGPIVJ ] HKGNF'ORV[ HCNUG KH KP(KGNF ] UYKVEJ YJKVGURCEG1R ] ECUG 9*+6'52#%'A12A64+/ EWTTGPV4GEQTFCFF(KGNF8CNWG 5VTKPIXCNWG1H EJCTU UVCTV NGPIVJVTKO DTGCM ECUG 9*+6'52#%'A12A4'/18' 5VTKPI$WHHGT UD PGY 5VTKPI$WHHGT HQT KPV K UVCTV K UVCTV NGPIVJ K ] KH %JCTCEVGTKU9JKVGURCEG EJCTU=K? ] UDCRRGPF EJCTU=K? _ _ EWTTGPV4GEQTFCFF(KGNF8CNWG UDVQ5VTKPI DTGCM FGHCWNV FGHCWNV NWD 010' TGE[YK EKG WUWYCPKG PCMÎY EWTTGPV4GEQTFCFF(KGNF8CNWG 5VTKPIXCNWG1H EJCTU UVCTV NGPIVJVTKO _ _ _ RWDNKE XQKF GPF'NGOGPV 5VTKPI PCOG ] KP(KGNF HCNUG KH PCOGGSWCNU+IPQTG%CUG TGEQTF ] GPF4GEQTF TGVWTP _ KH PCOGGSWCNU+IPQTG%CUG HKGNF ] GPF(KGNF TGVWTP _ _ RTQVGEVGF XQKF GPF(KGNF ] KH KP(KGNF HKGNF'ORV[ ] EWTTGPV4GEQTFCFF(KGNF8CNWG _ _ RTQVGEVGF XQKF GPF4GEQTF ] KH IGV%WTTGPV4GEQTF IGVGNC[ ] IGV2TKPV8GEVQT CFF'NGOGPV IGV%WTTGPV4GEQTF UGV%WTTGPV4GEQTF PWNN TGVWTP _ IGV%WTTGPV4GEQTF RTKPV UGV%WTTGPV4GEQTF PWNN KH IGV2TKPV8GEVQT KU'ORV[ ] PCLRKGTY PKGQRÎ PKQP[ TGMQTF MQ EQY[ YKúE FTWMWLGO[ TGMQTF[ QRÎ PKQPG 'PWOGTCVKQP G IGV2TKPV8GEVQT GNGOGPVU YJKNG GJCU/QTG'NGOGPVU ] 4GEQTF GPGZV'NGOGPV RTKPV _ IGV2TKPV8GEVQT TGOQXG#NN'NGOGPVU _ _
  41. 41. 198 Projektowanie baz danych XML. Vademecum profesjonalisty RTQVGEVGF 4GEQTF IGV%WTTGPV4GEQTF ] TGVWTP EWTTGPV4GEQTF _ RTQVGEVGF LCXCWVKN8GEVQT IGV2TKPV8GEVQT ] KH RTKPV8GEVQT PWNN ] RTKPV8GEVQT PGY LCXCWVKN8GEVQT _ TGVWTP RTKPV8GEVQT _ RTQVGEVGF LCXCWVKN5VCEM IGV4GEQTF5VCEM ] KH TGEQTF5VCEM PWNN ] TGEQTF5VCEM PGY LCXCWVKN5VCEM _ TGVWTP TGEQTF5VCEM _ RTQVGEVGF XQKF UGV%WTTGPV4GEQTF 4GEQTF PGY8CNWG ] KH PGY8CNWG PWNN ] ENGCT EWTTGPV4GEQTF KH IGV4GEQTF5VCEM GORV[ ] VJKUEWTTGPV4GEQTF PWNN _ GNUG ] VJKUEWTTGPV4GEQTF 4GEQTF IGV4GEQTF5VCEM RQR _ TGVWTP _ KH IGV%WTTGPV4GEQTF PWNN ] GODGFFGF TGEQTF IGV4GEQTF5VCEM RWUJ IGV%WTTGPV4GEQTF _ VJKUEWTTGPV4GEQTF PGY8CNWG _ RTQVGEVGF XQKF UGV2TKPV8GEVQT LCXCWVKN8GEVQT PGY8CNWG ] VJKURTKPV8GEVQT PGY8CNWG _ RTQVGEVGF XQKF UGV4GEQTF5VCEM LCXCWVKN5VCEM PGY8CNWG ] VJKUTGEQTF5VCEM PGY8CNWG _ RWDNKE XQKF UVCTV'NGOGPV 5VTKPI PCOG #VVTKDWVG.KUV CVVT.KUV ] 5[UVGOQWVRTKPVNP PCOG KP(KGNF HCNUG YJKVGURCEG1R 9*+6'52#%'A12A010' KH PCOGGSWCNU+IPQTG%CUG TGEQTF ] UVCTV4GEQTF CVVT.KUV TGVWTP _ KH PCOGGSWCNU+IPQTG%CUG HKGNF ] UVCTV(KGNF CVVT.KUV TGVWTP _ _ RTQVGEVGF XQKF UVCTV(KGNF #VVTKDWVG.KUV CVVT.KUV ] KH EWTTGPV4GEQTF PWNN ] 5[UVGOQWVRTKPVNP 9 TGMQTFKG PKG OC RQNC CVVT.KUVVQ5VTKPI _ KP(KGNF VTWG HKGNF'ORV[ VTWG HQT KPV K K CVVT.KUVIGV.GPIVJ K ]
  42. 42. 4QFKC Architektura systemu baz danych 199 KH CVVT.KUVIGV0COG KGSWCNU+IPQTG%CUG PCOG ] EWTTGPV4GEQTFCFF(KGNF0COG CVVT.KUVIGV8CNWG K _ KH CVVT.KUVIGV0COG KGSWCNU+IPQTG%CUG UGSWGPEGIGPGTCVGF ] EWTTGPV4GEQTFCFF(KGNF'ZRT CVVT.KUVIGV8CNWG K 0GZV8CN KP(KGNF HCNUG _ KH CVVT.KUVIGV0COG KGSWCNU+IPQTG%CUG UGSWGPEGXCNWG ] EWTTGPV4GEQTFCFF(KGNF'ZRT CVVT.KUVIGV8CNWG K %WTT8CN KP(KGNF HCNUG _ KH CVVT.KUVIGV0COG KGSWCNU+IPQTG%CUG MG[UGCTEJ ] EWTTGPV4GEQTFCFF(KGNF5WDS CVVT.KUVIGV8CNWG K _ KH CVVT.KUVIGV0COG KGSWCNU+IPQTG%CUG YJKVGURCEG ] KH CVVT.KUVIGV8CNWG KGSWCNU+IPQTG%CUG PQPG ] YJKVGURCEG1R 9*+6'52#%'A12A010' _ GNUG KH CVVT.KUVIGV8CNWG KGSWCNU+IPQTG%CUG VTKO ] YJKVGURCEG1R 9*+6'52#%'A12A64+/ _ GNUG KH CVVT.KUVIGV8CNWG KGSWCNU+IPQTG%CUG TGOQXG ] YJKVGURCEG1R 9*+6'52#%'A12A4'/18' _ _ _ _ RTQVGEVGF XQKF UVCTV4GEQTF #VVTKDWVG.KUV CVVT.KUV ] UGV%WTTGPV4GEQTF 4GEQTFIGV(TGG4GEQTF HQT KPV K K CVVT.KUVIGV.GPIVJ K ] KH CVVT.KUVIGV0COG KGSWCNU+IPQTG%CUG VCDNG ] EWTTGPV4GEQTFUGV6CDNG CVVT.KUVIGV8CNWG K _ KH CVVT.KUVIGV0COG KGSWCNU+IPQTG%CUG FGNC[ ] KH CVVT.KUVIGV8CNWG KGSWCNU+IPQTG%CUG HCNUG ] EWTTGPV4GEQTFUGVGNC[ VTWG _ _ _ _ _ 9[FTWM Przykład wprowadzanych danych !ZON XGTUKQP ! TQQV GZRGTATGUWNV URQV ITKF ITKF XGTUKQP RQUKVKQP #RQUKVKQP IGPG PCOG R QTICPKUO E QYKGM URQV GZRGTKOGPV GZRGTAEQPF VUGZRGTAEQPF GZRGTKOGPV XCTKCPV XCTKCPV
  43. 43. 200 Projektowanie baz danych XML. Vademecum profesjonalisty XCNWG XCNWG GZRGTATGUWNV GZRGTATGUWNV URQV ITKF ITKF XGTUKQP RQUKVKQP #RQUKVKQP IGPG PCOG $4%# QTICPKUO E QYKGM URQV GZRGTKOGPV GZRGTAEQPF VUGZRGTAEQPF GZRGTKOGPV XCTKCPV XCTKCPV XCNWG XCNWG GZRGTATGUWNV GZRGTATGUWNV URQV ITKF ITKF XGTUKQP RQUKVKQP #RQUKVKQP IGPG PCOG 2CM QTICPKUO E QYKGM URQV GZRGTKOGPV GZRGTAEQPF VUGZRGTAEQPF GZRGTKOGPV XCTKCPV XCTKCPV XCNWG XCNWG GZRGTATGUWNV TQQV 9[FTWM Rekordy zagnieżdżone do ładowania z wartościami zapytań do bazy danych !ZON XGTUKQP ! 4116 TGEQTF VCDNG GZRGTATGUWNV HKGNF PCOG KF UGSWGPEGIGPGTCVGF GZRGTATGUWNVAU TGEQTF VCDNG URQV HKGNF PCOG KF UGSWGPEGIGPGTCVGF URQVAU HKGNF PCOG ITKF HKGNF HKGNF PCOG XGTUKQP HKGNF PCOG RQUKVKQP #HKGNF HKGNF PCOG IGPG MG[UGCTEJ IGPGPCOG RHKGNF TGEQTF TGEQTF VCDNG GZRGTKOGPV HKGNF PCOG KF UGSWGPEGIGPGTCVGF GZRGTKOGPVAU HKGNF PCOG GZRGTAEQPF VUHKGNF TGEQTF HKGNF PCOG XCTKCPV HKGNF HKGNF PCOG XCNWG HKGNF TGEQTF TGEQTF VCDNG GZRGTATGUWNV HKGNF PCOG KF UGSWGPEGIGPGTCVGF GZRGTATGUWNVAU TGEQTF VCDNG URQV HKGNF PCOG KF UGSWGPEGIGPGTCVGF URQVAU HKGNF PCOG ITKF ITKF HKGNF PCOG XGTUKQP HKGNF PCOG RQUKVKQP #HKGNF
  44. 44. 4QFKC Architektura systemu baz danych 201 HKGNF PCOG IGPG MG[UGCTEJ IGPGPCOG $4%#HKGNF TGEQTF HKGNF PCOG GZRGTKOGPV UGSWGPEGXCNWG GZRGTKOGPVAU HKGNF PCOG XCTKCPV HKGNF HKGNF PCOG XCNWG HKGNF TGEQTF 4116 9[FTWM Arkusz XSL przekształcający dane XML z przykładu na XML rLoad !ZON XGTUKQP ! #TMWU UV[NÎY CFWLæE[ FCPG Q IGPCEJ ZUNUV[NGUJGGV XGTUKQP ZONPUZUN JVVRYYYYQTI:5.6TCPUHQTO ZUNQWVRWV OGVJQF ZON ZUNVGORNCVG OCVEJ ZUNCRRN[VGORNCVGU UGNGEV
  45. 45. ZUNVGORNCVG ZUNVGORNCVG OCVEJ TQQV 4116 ZUNCRRN[VGORNCVGU UGNGEV
  46. 46. 4116 ZUNVGORNCVG ZUNVGORNCVG OCVEJ IGPG TGEQTF VCDNG )'0' HKGNF PCOG KF UGSWGPEGIGPGTCVGF IGPGAU ZUNCRRN[VGORNCVGU UGNGEV
  47. 47. ZUNCRRN[VGORNCVGU TGEQTF ZUNVGORNCVG ZUNVGORNCVG OCVEJ PCOG HKGNF PCOG PCOG ZUNXCNWGQH UGNGEV HKGNF ZUNVGORNCVG ZUNVGORNCVG OCVEJ FGUETKRVKQP HKGNF PCOG FGUETKRVKQP ZUNXCNWGQH UGNGEV HKGNF ZUNVGORNCVG ZUNVGORNCVG OCVEJ RCVJYC[ HKGNF PCOG RCVJYC[ ZUNXCNWGQH UGNGEV HKGNF ZUNVGORNCVG ZUNVGORNCVG OCVEJ QTICPKUO HKGNF PCOG QTICPKUO ZUNXCNWGQH UGNGEV HKGNF ZUNVGORNCVG ZUNUV[NGUJGGV Implementacja w języku Java składa się z trzech klas: głównej klasy .QCF:/., klasy ,$%.QCF*CPFNGT u ywanej z parserem SAX oraz klasy 4GEQTF, zawierającej informacje dotyczące wszystkich ładowanych rekordów. Metoda OCKP klasy .QCF:/. pobiera plik XML TNQCF jako dane wejściowe i wywołuje metodę RCTUG, tworzącą obiekt parsera SAX
  48. 48. 202 Projektowanie baz danych XML. Vademecum profesjonalisty z procedurą obsługi ,$%.QCF*CPFNGT. ,$%.QCF*CPFNGT tworzy obiekt 4GEQTF i wypełnia w miarę parsowania jego pola. Jeśli element XML TGEQTF wymaga więcej ni jednego rekordu relacyjnego, tworzonych jest odpowiednio wiele obiektów 4GEQTF. )GPGTCELC :/. Istnieje kilka sposobów generowania dokumentów XML na podstawie danych z relacyjnej bazy danych. Przedstawimy pięć mo liwości: C Dokument XML mo na wygenerować na podstawie danych z tabeli relacyjnej bazy danych. Tabela jest formatowana jako dokument XML, zaś kluczy obcych u ywa się do określenia hierarchii elementów dokumentu. Nazwy typów elementów to nazwy tabeli i kolumn. Takie rozwiązanie przydaje się do przeglądania danych z bazy. D To rozwiązanie jest podobne do poprzedniego: o strukturze dokumentu decyduje struktura bazy danych, ale mo liwe jest te u ycie widoków (perspektyw). Ka dy widok jest zamieniany na dokument XML. Dzięki temu tworzenie dokumentów jest bardziej elastyczne, gdy struktura dokumentu nie zale y bezpośrednio od postaci tabel. Hierarchię elementów określają klucze obce i (lub) relacje jawnie określające, które wartości i jak mają być rozwijane. E Dokumenty mo na tworzyć na podstawie formułowanych ad hoc zapytań. Hierarchia elementów nadal zale y od struktury bazy danych (i ewentualnie widoków). F Szablon dokumentu mo na zdefiniować, podając jego części w formie zapytań. Zapytania są wykonywane i przekształcane na XML jak poprzednio, ale wyniki wielu zapytań są zbierane w jednym dokumencie. G Mo na podać zapytanie z podzapytaniami, wtedy strukturę dokumentu określa struktura zapytań. Takie rozwiązanie sprawdza się tylko wtedy, gdy generacja XML odbywa się bezpośrednio w maszynie bazy danych. Rozwiązania wymienione w punktach od a) do c) są wykorzystywane w oprogramowaniu, o którym mówi punkt 5.3. Rozwiązanie d) mo e być przydatne, kiedy generacja XML jest powiązana z serwerem sieciowym obsługującym generację dokumentów po stronie serwera, jak Java Server Pages (JSP). 4GNCE[LP[ UGTYGT FCP[EJ Sterownik relacyjnej bazy danych udostępnia dane z relacyjnego DBMS w XML. Do bazy danych kierowane jest zapytanie, po czym wyniki z bazy są formatowane jako XML. W punkcie 6.2 opisano zastosowanie rozwiązań komercyjnych. Relacyjny serwer danych jest sterownikiem bazy danych wraz z serwerem sieciowym. Podstawowy schemat pracy u ytkownika, ądającego raportu XML z relacyjnej bazy danych przez przeglądarkę sieciową, wygląda następująco (rysunek 5.2): U ytkownik podaje w przeglądarce sieciowej w formie adresu URL zapytanie do relacyjnej bazy danych. Przeglądarka przesyła ądanie adresu URL do serwera danych.
  49. 49. 4QFKC Architektura systemu baz danych 203 4[UWPGM Przetwarzanie żądania użytkownika w trzywarstwowej strukturze relacyjnego serwera danych Serwer danych analizuje ądanie URL i tworzy zapytanie SQL. Serwer danych przekazuje zapytanie SQL do serwera baz danych. Serwer baz danych wykonuje zapytanie. Serwer baz danych zwraca do serwera danych wyniki zapytania w formie tabelarycznej. Serwer danych formatuje wyniki jako XML. Serwer danych zwraca dane w postaci XML do przeglądarki. Przeglądarka sieciowa parsuje dane XML i wyświetla je. Jeśli arkusz stylów został u yty, konieczne jest pobranie i przeanalizowanie w przeglą- darce tak e arkusza. Jeśli chcemy stworzyć relacyjny serwer danych, powinniśmy odpowiedzieć na wiele pytań, między innymi: Czy oprócz tabel przewidujemy wyświetlanie danych z widoków? Czy dane będą aktualizowane, czy są przeznaczone tylko do odczytu? Czy u ytkownik mo e wybierać jednocześnie dane z wielu tabel? Jak obsługiwane są złączenia? Jak zło one mogą być odwzorowania relacji na strukturę XML? Czy mają być obsługiwane (mo e specjalnie) tabele pomocnicze lub tabele złączające? Czy wiązania będą analizowane przez klucze obce? Do ilu poziomów? Jak są obsługiwane cykliczne powiązania kluczy obcych? Jak są obsługiwane powiązania między tabelami? Co pozwalają zrealizować zapytania? Jak du o danych ma być zwracanych? Du e porcje czy niewielkie fragmenty? Na te pytania trzeba było odpowiedzieć, opracowując relacyjny serwer danych w języku Java, rServe (opisano go szczegółowo w punkcie 5.3.5). Przykładowe dane dotyczące bazy danych mikromatrycy pokazano na rysunku 5.3. Przykład sformatowano, korzy- stając z arkusza stylów opisanego w rozdziale 7. Warto zauwa yć, e niektóre kolumny to hiperłącza, za którymi kryją się kolejne dane generowane przez rServe.
  50. 50. 204 Projektowanie baz danych XML. Vademecum profesjonalisty 4[UWPGM Przykład danych z rServe z bazy danych mikromatryc æFCPKC CFTGUW 74. API do relacyjnego serwera danych mo na zrealizować jako ądania URL. Zanim zaj- miemy się szczegółami rServe, opiszemy takie API. rServe umo liwia korzystanie z danych tylko do odczytu za pośrednictwem adresu URL. Serwlet jest wywoływany z parametrami takimi, jak: nazwa tabeli, ograniczenia na ko- lumny, konto w relacyjnej bazie danych. Alternatywna implementacja umo liwiałaby podawanie instrukcji SQL w adresie URL. Oto przykłady adresów URL dla rServe: http://127.0.0.1/servlets/com.xweave.xmldb.rserve.XMLServlet?tablename=company — pobiera wszystkie rekordy z tabeli EQORCP[. http://127.0.0.1/servlets/com.xweave.xmldb.rserve.XMLServlet?tablename=company stylesheet=/ss/generic1.xsl — pobiera wszystkie rekordy z tabeli EQORCP[, następnie formatuje dane według arkusza stylów /ss/generic1.xsl. http://127.0.0.1/servlets/com.xweave.xmldb.rserve.XMLServlet?tablename=company id=12 — pobiera z tabeli EQORCP[ rekord o identyfikatorze 12. http://127.0.0.1/servlets/com.xweave.xmldb.rserve.XMLServlet?tablename=company stylesheet=/ss/generic1.xslname=Acme — pobiera z tabeli EQORCP[ rekord, który w kolumnie PCOG ma wartość „#EOG”, następnie otrzymane dane zwraca, stosując arkusz stylów /ss/generic1.xsl.

×