Rozdział monografii: `Bazy Danych: Struktury, Algorytmy, Metody

Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006
Rozdział 19
w
Hybrydowe bazy danych XML
w
w
Streszczenie. Rozdział opisuje nowy hybrydowy model bazy danych. Prezentowane są najistotniejsze zagadnienia związane z budową systemów operujących danymi relacyjnymi i dokumentami XML. Jednocześnie zaprezentowana jest pierwsza implementacja tego modelu w postaci bazy danych IBM
DB2 Viper.
1 Wprowadzenie
da
.b
Aktualnie dominującym w większości zastosowań modelem danych jest model relacyjny.
Od lat rozwijane relacyjne bazy danych oferują wysoką wydajność przetwarzania nawet
dużych zbiorów danych, wysoki poziom bezpieczeństwa i niezawodność.
Zaistniała potrzeba integracji systemów spowodowała powstanie standardu, który miał być
interfejsem łączącym różne systemy, a dokładnie umożliwiającym wymianę danych pomiędzy nimi. Standardem tym jest metajęzyk XML. Początkowo XML był traktowany rzeczywiście jako „transportowy” format służący bardziej do importu lub eksportu danych niż do
właściwego ich przechowywania. Szybko jednak okazało się, że w pewnych rozwiązaniach
jest on wygodniejszy niż inne struktury (relacyjne czy obiektowe). Przyjęcie języka XML
jako formatu przechowywania danych [5] wymusiło stworzenie narzędzi zarządzających
dokumentami XML, czyli systemów XMLowych baz danych.
pl
s.
2 Dotychczas tworzone rozwiązania dla XML
Systemy zarządzające bazami danych obsługujące dokumenty XML rozwijały się do tej pory w dwóch głównych nurtach: systemów dedykowanych (natywnych) oraz w postaci modułów dołączanych do tradycyjnych systemów baz danych, rozszerzających ich funkcjonalność o obsługę dokumentów XML. Systemy dedykowane organizują struktury składowania
w oparciu o hierarchiczny charakter dokumentów XML. Systemy rozszerzone o XML organizują składowanie na poziomie całych dokumentów, zapisując je w postaci bloków
znakowych lub binarnych, lub na poziomie poszczególnych wartości elementów i atrybutów dokonując pełnej dekompozycji i mapowania na struktury czysto relacyjne [4].
Dokumenty tworzone z wykorzystaniem języka XML mogą mieć dwojaką strukturę [7],
[8]. Z jednej strony spotyka się dokumenty zorientowane na dane (ang. data-centric XML
documents), z drugiej na dokument (document-centric XML documents). Pierwsze z nich
Karolina Nurzyńska, Adam Duszeńko: Politechnika Śląska, Instytut Informatyki,
ul. Akademicka 16, 44-100 Gliwice, Polska
email: [email protected], [email protected],
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2006
Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006
K. Nurzyńska, A. Duszeńko
w
wykorzystywane są zazwyczaj do przenoszenia danych między różnymi systemami.
W związku z tym największą wagę przywiązuje się do danych w nich zawartych. Nie jest
ważna w tym przypadku kolejność elementów. Ponadto dokumenty te charakteryzują się
regularną strukturą i równomierną granulacją. Istnieją także dokumenty zorientowane
na dokument, których struktura jest nieregularna oraz charakteryzuje się zróżnicowaną granulacją. Kolejność elementów w tym przypadku ma znaczenie. Dokumenty te powstają zazwyczaj nieautomatycznie lub mogą być wynikiem transformacji z innego formatu tekstu.
Na początku struktura dokumentu XML wymuszała na użytkowniku wybór odpowiedniej bazy danych ułatwiającej składowanie wybranego typu dokumentu. Jednak najnowsze
wersje systemów bazodanowych, natywnych [3] jak i XML enabled, umożliwiają składowanie dowolnego typu dokumentu. Autorzy [6] dokonali porównania pracy systemów składujących różne dokumenty XML. Porównywali oni relacyjny system zarządzania bazą danych wspierający XML (ang. XML enabled) na przykładzie DB2 z systemem natywnym na
przykładzie SZBD (systemu zarządzającego bazami danych) Tamino [10].
Obydwa systemy charakteryzowały się podobną funkcjonalnością, jednak sposób, w jaki
poszczególne bazy radziły sobie ze składowaniem dokumentów, był inny. Opisywane systemy umożliwiały zarządzanie zarówno dokumentami XML jak i informacją w nich zawartą. Bazy danych zapewniały zachowanie równoważności w składowaniu dokumentów poprzez wykorzystanie modelu danych. Zwracały uwagę na zarządzanie kolejnymi wersjami
typu dokumentów tak, aby struktura dokumentu mogła się zmieniać w czasie oraz umożliwiały zastosowanie indeksów na elementach struktur dokumentu, co ma na celu szybsze
wykonywanie zapytań w kierunkach innych niż zgodne z hierarchią dokumentu. Zwracały
także uwagę, na odpowiednią autoryzację użytkowników i ich uprawnienia w dostępie do
dokumentów lub ich części.
Niestety w omawianych systemach pozostały kwestie jeszcze nierozwiązane. W przypadku systemów bazy danych typu XML enabled składowanie dokumentów zorientowanych
na dokument wiąże się ze znaczącym nakładem pracy związanym z przełożeniem niestrukturalnych hierarchicznych danych XML na nieelastyczną postać relacyjnych tabel. Tabele
te w rezultacie tych przekształceń są rzadko wypełnione i wymagają wykonywania licznych
złączeń podczas realizacji zapytań, co znacząco wydłuża czas ich realizacji [11]. Dodatkowo należy spodziewać się utraty kolejności elementów oraz utraty istotnych informacji, takich jak definicja typu dokumentu, instrukcji przetwarzania czy komentarzy. Powoduje to
utratę równoważności dokumentu ładowanego do bazy danych i dokumentu z niej odzyskiwanego.
Kolejnymi elementami systemu, które wymagają dopracowania jest poprawienie możliwości baz XML począwszy od zdefiniowania standardów związanych z XML jak i implementacja już istniejących standardów we wszystkich dostępnych bazach. Dodatkowo w bazach natywnych nie został rozwiązany problem nakładania blokad na poziomie niższym niż
dokument XML.
da
.b
w
w
pl
s.
3 Hybrydowy model danych
Jak widać żadne z powyższych rozwiązań nie jest pozbawione istotnych wad. Wady te stały
się czynnikiem sprawczym dla opracowania nowego podejścia do budowy systemów zarządzania danymi relacyjnymi i dokumentami XML. To właśnie na połączeniu tych dwóch
dziedzin pojawia się najwięcej problemów. Tworzenie interfejsu pomiędzy właściwym silnikiem relacyjnym i składowanymi w postaci obiektów CLOB lub BLOB dokumentami
XML stwarza poważne problemy wydajnościowe. Nawet stosując specjalne tabele pomoc188
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2006
Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006
Hybrydowe bazy danych XML
w
nicze [2] (wprowadzające kosztowną redundancję) pełniące role struktur podręcznych oraz
stosowanie indeksów pełno tekstowych nie pozwala zniwelować kłopotów wydajnościowych. Z drugiej strony łączenie systemów relacyjnych z dedykowanymi systemami stwarza
jeszcze większe problemy i praktycznie nie jest stosowane.
Dodatkowo coraz szersze wykorzystanie dokumentów XML o zróżnicowanych typach
(opisanych różnymi dokumentami DTD) wymusza poszukiwanie nowych, a co najważniejsze, elastycznych rozwiązań. Dąży się do tego, aby pojedynczy system zapewniał obsługę
zarówno dokumentów XML zorientowanych na dane jak i na dokument [6]. Dotychczasowe próby stworzenia takiego systemu, chociaż umożliwiały składowanie obu typów dokumentu w jednej bazie, borykały się z wieloma problemami.
W tej sytuacji pojawiła się koncepcja połączenia silnika relacyjnego z dedykowanym
dokumentom XML. W ten sposób powstał model, który pod jednolitym interfejsem kryje
dwa systemy niezależnie zarządzające danymi relacyjnymi i dokumentami XML. W proponowanym rozwiązaniu zakłada się istnienie wbudowanego nowego typu danych, jakim jest
XML. Prawie każdy komponent jak i narzędzie wykorzystywane w bazie DB2 rozpoznaje
i potrafi współpracować z tym typem danych. W związku, z czym nowy paradygmat składowania danych pozostawia XML w hierarchicznej formie drzewa przypominającej XML
DOM (ang. XML Document Object Model). Dane XML są formatowane oraz stronicowane
dla przyspieszenia nawigacji i wykonywania zapytań jak i uproszczenia indeksowania.
System ten, opisany przez Bhambhri, składa się z dwóch poziomów. W górnej warstwie
prezentowanej architektury znajduje się hybrydowy silnik bazy danych wyposażony
w możliwość przetwarzania zapytań w językach XQuery, XPath, SQL oraz SQL/XML [9].
Użytkownik może zadawać zapytania w dowolnym z wymienionych języków lub nawet łączyć je ze sobą. Na drugim poziomie dane przechowywane mogą być albo w relacyjnej bazie danych, albo bezpośrednio jako dokument XML (patrz rys. 1). Dzięki takiemu zaprojektowaniu bazy danych, gdzie system na każdym poziomie rozumie oraz wspiera obydwa
modele dokumentów XML, system zapewnia skalowalność oraz szybkość wykonywania
zapytań, zarządzanie kopiami bezpieczeństwa, odzyskiwanie, optymalizację oraz wysoką
dostępność, tak jak to jest w przypadku systemów relacyjnych baz danych. Jednym słowem
zostaje zachowany cały dorobek dotychczas rozwijanych relacyjnych systemów baz danych
z pełnym wykorzystaniem zalet i możliwości dawanych przez dedykowane dokumentom
XML rozwiązania.
Składowanie dokumentów XML w strukturach drzewiastych umożliwia eksport tych dokumentów poza struktury bazy bez żadnych dodatkowych operacji. Tymi dodatkowymi
operacjami są zazwyczaj bardzo kosztowne i angażujące wiele zasobów złączenia. Uniknięcie tych złączeń jest bardzo dużą zaletą szczególnie widoczną przy dużych dokumentach.
W początkowych generacjach baz danych wspierających XML, jak już wspomniano, dokumenty XML ulegały bądź dekompozycji, bądź były przechowywane jako CLOB
(ang. Character Large Objects) lub BLOB (ang. Binary Large Object). Takie wymuszenie
relacyjnego formatu danych miało poważne ograniczenia, niemniej w celu zachowania
zgodności z poprzednimi wersjami są one nadal wspierane. Jednak w pełni natywne [3]
składowanie danych oferuje dodatkowe zalety:
– składowanie dokumentów z granulacją na poziomie węzłów a nie dokumentów,
– indeksowanie na podstawie wyrażeń wzorcowych XML (ang. XML pattern
expression),
– tworzenie zapytań za pomocą dwujęzykowego kompilatora wspierającego języki
XQuery oraz SQL.
da
.b
w
w
pl
s.
189
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2006
Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006
K. Nurzyńska, A. Duszeńko
w
w
w
Rys. 1. Architektura systemu bazy danych DB2 [6]
da
.b
4 Składowanie node-level granularity
pl
s.
Wspomniane problemy wydajnościowe w systemach XML Enabled głównie związane są
ze sposobem składowania dokumentów w bazie. Pozostawienie dokumentu w postaci strumienia znaków zapisanego w bloku CLOB lub BLOB nie sprzyja wydajnemu poruszaniu
się po jego elementach. Również pełna dekompozycja nie stanowi w pełni satysfakcjonującego rozwiązania.
Koszt, jakim obarczony jest dostęp do danych, ich odczytywanie, modyfikowanie czy
usuwanie, wpływa na wydajność systemu [3]. W przypadku relacyjnych baz danych operacje te wykonywane są bardzo szybko, co stanowi jedną z zalet dla składowania dokumentów XML w taki sposób. W przypadku składowania dokumentów XML jako strumienie
znakowe lub strumienie bitowe (CLOB, BLOB) pobieranie informacji o pojedynczym elemencie jest zapewniane dzięki odpowiedniemu indeksowaniu, jednak próba usunięcia czy
modyfikacji takiego pliku wymaga całkowitego nadpisania pliku, a często również uaktualnienia tablic z indeksami. Również w bazach natywnych podstawową jednostką składowania dokumentów XML był dokument, co utrudniało dostęp do jego elementów składowych.
Naturalną dla XML granulacją składowania jest poziom poszczególnych elementów.
W implementacji hybrydowej bazy danych opisanych w [1] i [3] składowanie całego dokumentu wirtualnie nadal jest traktowane jako ciągły strumień bitów, jednak indywidualne
węzły mogą być zmieniane przy minimalnym wpływie na pozostałe węzły jak i tabele
indeksów. Jest to możliwe, dzięki założeniu, że podstawową jednostką składowania danych
jest węzeł. Taki węzeł istnieje na stronie razem z innymi węzłami z tego samego lub innych
dokumentów. Każdy węzeł jest powiązany z węzłem nadrzędnym oraz podrzędnym, co daje wysoką efektywność nawigacji po dokumencie. Węzły mogą zmieniać swój rozmiar,
mogą być przenoszone na inne strony bez potrzeby przepisania całego dokumentu. Dzięki
temu podejściu jakiekolwiek zmiany w dokumencie XML dokonywane są bardzo wydajnie
jak również łatwo można zapewnić dostęp tylko do wybranych części dokumentu. Zapisy190
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2006
Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006
Hybrydowe bazy danych XML
w
wanie dokumentu jako zbioru połączonych węzłów pozwala stworzyć optymalne warunki
do poruszania się po nich i wykonywania typowych dla bazy danych operacji.
Dotychczas spotykane rozwiązania posiadają na poziomie struktur składowania całych
dokumentów XML bardzo istotne ograniczenie w postaci konieczności uprzedniej deklaracji struktury składowanych dokumentów. Wymusza to znajomość na przykład dokumentów
DTD (Document Type Definition) dokładnie opisujących budowę dokumentów, które będą
składowane. Znacząco ogranicza to swobodę posługiwania się tymi narzędziami. Podobnie
rozwiązania bazujące na dekompozycji dokumentów XML wymagają jednoznacznie zdefiniowanego schematu dekompozycji w oparciu o zadeklarowany schemat dokumentu.
w
5 Indeksacja dokumentów XML
da
.b
w
Jak zawsze kluczowym dla wydajności rozwiązania okazuje się możliwość zastosowania
odpowiednich indeksów, które stworzone pod kontem konkretnych zastosowań, przechowując zagregowane informacje w łatwej do zaadresowania formie, mogą znacząco przyspieszyć operacje, niwelując konieczność sekwencyjnego przeszukiwania danych.
Wybranie elementu dokumentu XML jako podstawowego ziarna granulacji składowania
daje możliwość budowy indeksów wskazujących bezpośrednio interesujące elementy bez
użycia dodatkowych narzędzi jak na przykład indeksów tekstowych. Operowanie przez bazę danych na dokumentach XML na poziomie elementów pozwala budować indeksy w odniesieniu do konkretnych poddrzew dokumentu. Dodatkowo rezygnacja z predefiniowania
struktury składowanych dokumentów daje możliwość, a jednocześnie wyzwanie budowy
indeksów w oparciu o elementy dokumentów XML posiadających semantyczną zbieżność
przy niekoniecznie syntaktycznej zgodności. Można to uzyskać tworząc indeksy w oparciu
o definicję za pomocą alternatywnych wyrażeń określających indeksowane elementy oraz
z użyciem wyrażeń uniwersalnych.
Uwzględniając budowę dokumentów XML oraz specyfikę najczęściej definiowanych
predykatów można zdefiniować dwa zasadnicze rodzaje indeksów XML. Pierwszym rodzajem będą indeksy dotyczące konkretnych elementów lub atrybutów. Indeksy te można nazwać atomowymi, gdy dotyczą podstawowych porcji danych w dokumencie XML, jakimi są
treść elementu lub atrybuty lub nie atomowymi gdy są tworzone na podstawie całych węzłów XML. Nie atomowe indeksy tworzone są przez konkatenację tekstowej wartości
wszystkich elementów i atrybutów składających się na węzeł dokumentu XML. Do określenia indeksowanych elementów można użyć języka XPath. Brak definicji struktury składowanych dokumentów XML powoduje konieczność jawnego określenia rzutowania typów,
jakie ma być zastosowane przy wyznaczaniu indeksowanej wartości. Przykładem takiego
indeksu może być następująca konstrukcja:
pl
s.
CREATE INDEX index_1 ON tabela_1(kolumnaXML_1) GENERATE KEYS USING
XMLPATTERN ‘/*:id/text()’ AS SQL double
Druga grupa indeksów to indeksy pełno tekstowe. Zwłaszcza w dokumentach ukierunkowanych na treść a nie na strukturę często zachodzi potrzeba przeszukiwania pełno tekstowego. Pełna kontrola nad treścią dokumentu daje możliwość definiowania indeksowania
pełno tekstowego w oparciu o cały dokument lub o wybrany fragment zgodnie z drzewem
dokumentu.
Dodanie dokumentu XML jako typu traktowanego na równi z pozostałymi typami wbudowanymi bazy danych pozwala budować indeksy charakteryzujące się wyższą selektywnością (bardziej dokładną selekcją), co znacząco podwyższa wydajność. Równie ważny,
a często nawet istotniejszy niż koszt tworzenia indeksów jest koszt utrzymania już istnieją191
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2006
Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006
K. Nurzyńska, A. Duszeńko
cych indeksów. Posługiwanie się wskaźnikami do stron zawierających zmieniane elementy
dokumentów XML pozwala sprowadzić konserwację indeksu dokumentu tylko do modyfikacji wpisów w indeksie dotyczących modyfikowanych elementów bez konieczności przebudowy całego indeksu.
6 Język zapytań hybrydowego systemu zarządzania bazami danych
w
da
.b
w
w
Jak wyżej zostało wspomniane system zarządzania bazą danych o architekturze hybrydowej
reprezentuje jednolity interfejs dla mechanizmów obsługi danych relacyjnych i dokumentów XML. Podstawowym i najbardziej widocznym dla użytkowników elementem tego
interfejsu jest język zapytań systemu bazy danych. Oba typy danych zarówno relacyjne jak
i dokumenty XML posiadają już ujednolicone języki zapytań w postaci odpowiednio SQL
oraz XQuery. Hybrydowy system zarządzania bazą danych powinien nie tylko niezależnie
w pełni zamiennie obsługiwać oba języki, ale co ważne powinien umożliwiać tworzenie zapytań łączonych składających się po części ze składni SQL a po części z XQuery. Dla uzyskania takiej funkcjonalności niezbędne jest zdefiniowanie funkcji działających na pograniczu danych relacyjnych i dokumentów XML zwracanych przez zapytania XQuery. Pomocnym w tym zadaniu jest rozwijane rozszerzenie języka SQL dla XML czyli SQL/XML.
Dzięki funkcjom SQL/XML możliwe jest formatowanie wyników zapytań relacyjnych
w postać dokumentów XML.
7 Przykład realizacji modelu hybrydowego – DB2 Viper
pl
s.
Pierwszą bazą danych realizującą opisany hybrydowy sposób obsługi danych relacyjnych
i dokumentów XML jest DB2 firmy IBM. W najnowszej bazie o wersji 9.0 Viper zintegrowano silniki relacyjny z natywnym XMLowym.
W systemie bazy danych DB2 Viper, podobnie jak w przypadku wykorzystania pakietu
XML Extender, dokumenty XML widziane są przez perspektywę abstrakcji kolumny
XML. W odróżnieniu od poprzednich rozwiązań nie występują tu ograniczenia wielkości
dokumentu XML uwarunkowane maksymalnymi rozmiarami pól CLOB lub BLOB,
ani konieczność uprzedniej deklaracji formatu dokumentu. Każdy poprawnie sformatowany
dokument może zostać umieszczony w kolumnie XML, co znacząco zwiększa elastyczność
narzędzia i tworzonych rozwiązań. Tworzenie tabeli z kolumną XML jest w pełni analogiczne do tworzenia tabeli z dowolnymi innymi predefiniowanymi typami bazy danych:
CREATE TABLE projektXML (id INT, lokalizacja VARCHAR(30), grupa XML)
Wspomniane wyżej mechanizmy łączenia języków SQL i XQuery realizowane jest przez
funkcje “db2-fn:xmlcolumn” i “db2-fn:sqlquery”. Wyszukanie nazwiska pracownika o numerze 334, którego dane składowane są w dokumencie XML w kolumnie GRUPA w tabeli
PROJEKTXML ma na przykład postać:
XQUERY for $p in db2-fn:xmlcolumn("PROJEKTXML.GRUPA")/grupa/pracownik
where $p/numer = 344
return $p/nazwisko
co zwraca w wyniku:
<?xml version="1.0" encoding="windows-1252" ?>
<nazwisko>Duszenko</nazwisko>
192
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2006
Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006
Hybrydowe bazy danych XML
Gdyby do powyższego zapytania dodać warunek, że szukamy pracownika, który pracuje
w Gliwicach wymagałoby to dodania warunku w dziedzinie danych relacyjnych, gdyż lokalizacja (w naszym przykładzie) jest polem tekstowym w tabeli PROJEKT. Takie zapytanie
łączące w sobie SQL i XQuery miałoby postać:
w
XQUERY for $p in db2-fn:sqlquery('select GRUPA
from PROJEKTXML
where lokalizacja = “Gliwice”')/grupa/pracownik
where $p/numer = 344
return $p/nazwisko
Wykorzystanie konstrukcji SQL/XML pozwala dane relacyjne zamieniać na postać węzłów XML i integrować z pozostałymi danymi składowanymi bezpośrednio w postaci dokumentów XML, np.:
w
da
.b
w
XQUERY let $p := db2-fn:sqlquery('select XMLELEMENT(NAME “pracownik”,
XMLFOREST(ID, nazwisko, funkcja))
from pracownicy where ID > 100’)
return <raport>
<pracownicy>{$p}</pracownicy>
</raport>
w wyniku otrzymamy:
<?xml version="1.0" encoding="windows-1252" ?>
<raport>
<pracownicy>
<pracownik>
<ID>101</ID>
<NAZWISKO>Duszenko</NAZWISKO>
<FUNKCJA>koordynator</FUNKCJA>
</pracownik>
<pracownik>
<ID>102</ID>
<NAZWISKO>Nurzynska</NAZWISKO>
<FUNKCJA>koordynator</FUNKCJA>
</pracownik>
<pracownik>
<ID>103</ID>
<NAZWISKO>Baczek</NAZWISKO>
<FUNKCJA>wykonawca</FUNKCJA>
</pracownik>
</pracownicy>
</raport>
pl
s.
Zwrócenie wszystkich identyfikatorów projektów wraz z nazwiskami osób zlokalizowanych w Gliwicach może mieć postać następującego zapytania:
select id, xmlquery('for $p in $gr/grupa/pracownik
where $e/lokalizacja = "Gliwice"
return $e/nazwisko'
passing by ref pr.grupa as “gr"
returning sequence)
from projekt pr
where id > 20;
Wynik tego zapytania łączący dane relacyjne i fragment dokumentu XML zostanie
przedstawiony przez klienta bazy danych w następujący sposób:
193
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2006
Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006
K. Nurzyńska, A. Duszeńko
w
da
.b
w
w
Rys. 2. Wizualizacja wyniku zapytania łączącego dane relacyjne z fragmentem dokumentu
XML
Bardzo silnym narzędziem jest możliwość dowolnego tworzenia warunków selekcji
w oparciu o przedstawione wyżej konstrukcje. Na przykład wyznaczenie nazwisk wszystkich pracowników, którzy są kierownikami w grupach (kierownikami pracowników o stażu
przekraczającym 5 lat) wraz z numerami tych grup ma postać:
pl
s.
select p.nazwisko, pr.id
from projekt pr, pracownicy p
where xmlserialize(content
xmlquery(‘$gr/grupa/pracownik[@staz>5]/kierownik/text()’
passing by ref pr.grupa as “gr“
returning sequence) as char(20)
) = p.nazwisko
8 Wnioski
Powstanie mechanizmów obsługi hybrydowego modelu danych dla dokumentów XML
i danych relacyjnych jest bezpośrednim wynikiem rywalizacji, jaka od jakiegoś czasu była
widoczna pomiędzy systemami dedykowanymi i systemami relacyjnymi rozbudowanymi
o obsługę XML. Rozwiązanie to czerpie najlepsze zalety z obu modeli jednocześnie oferując wiele nowych możliwości integracji danych, dzięki czemu pozwala przypuszczać, iż
niedługo stanie się ogólnie przyjętym schematem tworzenia baz danych XML. Jednocześnie jest to przykład jak w innych analogicznych sytuacjach można postępować z obsługą
194
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2006
Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006
Hybrydowe bazy danych XML
specyficznych typów danych nie poddających się łatwo adaptacji w środowisku relacyjnym. Dodanie do zbioru wewnętrznych typów danych systemu bazy danych, typu XML
wydaje się być naturalnym efektem dostosowywania systemów baz danych do danych złożonych zawierających nie tylko opis świata rzeczywistego, ale zasoby będące zapisem zjawisk lub obiektów tego świata. Innym przykładem takich rozszerzeń mogą być multimedialne bazy danych posiadające wiele analogii z opisywanym zagadnieniem składowania
dokumentów XML.
w
Literatura
A. Bhambhri, Firing up the hybrid engine, DB2 magazine QUARTER 3, 2005.
IBM Software Group, Comparing XML and relational storage: A best practices guide, IBM
Corporation, March 2005.
3. IBM Software Group, The IBM approach to unified XML/relational databases, IBM
Corporation, March 2005.
4. L. Ennser, C. Delporte, M. Oba, K. M. Sunil, Integrating XML with DB2 XML Extender and
DB2 Text Extender, IBM December 2000.
5. B. Steegmans, R. Bourret, O. Cline, O. Guyennet, S. Kulkarni, S. Priestley, V. Sylenko, Ueli
Wahli, XML for DB2 Information Integration, IBM July 2004.
6. M. Kozielski, A. Duszeńko, Bazy danych XML, Bazy Danych; Modele, Technologie, Narzędzia,
WKŁ, Gliwice, 2005.
7. R. Bourret, XML and Databases, November, 2003.
8. Graves, M.: Projektowanie baz danych XML, Wydawnictwo Helion, Gliwice, 2002.
9. IBM Corporation: Information technology - Database languages - SQL - Part 14: XML-Related
Specifications (SQL/XML) ISO/IEC 9075-14:2003, December 2003.
10. Software AG: Tamino XML Server Documentation (version 4.1.4), 2003.
11. A. Vakali, B. Catania, A. Maddalena: XML Data Stores: Emerging Practices, IEEE Internet
Computing, marzec-kwiecień 2005.
da
.b
w
w
1.
2.
pl
s.
195
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2006
Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006
w
da
.b
w
w
pl
s.
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2006