Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
01148 011031 11044668 na godz. na dobę w sumie
Projektowanie baz danych XML. Vademecum profesjonalisty - książka
Projektowanie baz danych XML. Vademecum profesjonalisty - książka
Autor: Liczba stron: 504
Wydawca: Helion Język publikacji: polski
ISBN: 83-7197-667-4 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> bazy danych >> inne
Porównaj ceny (książka, ebook, audiobook).
'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:

'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.
Znajdź podobne książki Ostatnio czytane w tej kategorii

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  !  RTKPVEQNNGEVKQP  HQTGCEJTQYKPVCDNG RTKPVVCDNGPCOG  HQTGCEJEQNWOPKPTQY RTKPVEQNWOPPCOGXCNWG 4QFKC đ   Architektura systemu baz danych 185 GPF RTKPV  GPF RTKPVEQNNGEVKQP  GPF 9[FTWM Procedura zapisu danych z relacyjnej tabeli jako pondelementów RTQEGFWTGYTKVG:/. ODGF NGOGPVU VCDNG RTKPV!ZONXGTUKQP  !  RTKPVEQNNGEVKQP  HQTGCEJTQYKPVCDNG RTKPVTGEQTF  HQTGCEJEQNWOPKPTQY RTKPVEQNWOPPCOG  RTKPVXCNWG RTKPVEQNWOPPCOG  GPF RTKPVTGEQTF  GPF RTKPVEQNNGEVKQP  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;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 )4 PCOG 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. 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 UGSWGPEGAIGPGTCVGUGSWGPEGVTCPUCEVKQPAUGS . 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)

Gdzie kupić całą publikację:

Projektowanie baz danych XML. Vademecum profesjonalisty
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: