Dokument y XML w relacyjnych
bazach danych – czyli wojna ś wiatów

Andrzej Ptas znik
Wars zawska Wyższa Szkoła Informatyki
aptas [e-mail]

< 2 >

Informatyka +

Stres zczenie

Przedmiotem wykładu jes t wykorzys tanie dokumentów XML w relacyjnych ba-
zach danych. W pierwszej części wykładu prezentowana jes t krótka his toria
standardu XML i pods tawowe za sady tworzenia dokumentów XML. Omówio-
ne s ą spos oby przeks ztałcania danych relacyjnych do postaci XML oraz zas a-
dy zapytań pobierających dane z dokumentu XML. Prezentowane s ą przykłady
wykorzys tania typu danych XML na etapie projektowania ba z danych, a także
przykłady za s tos owania XML w rozwią zywaniu konkretnych problemów. Omó-
wione s ą także elementy schematów XSD i ich znaczenie w procesie zapewnie -
nia poprawności danych zapis anych w dokumentach XML.

Spis treści

1. Wprowadzenie

3

2. Język XML

3

3. Język XML alternatywą dla relacyjnych baz danych

5

4. Język XML w Micros oft SQL Server 2008

5

5. Podsumowanie

10

Literatura

10

> Dokumenty XML w relacyjnych ba zach danych – czyli wojna ś wiatów

< 3 >

1 WPROWADZENIE

Relacyjne ba zy danych towarzyszą twórcom aplikacji już od wielu lat i ciężko
znaleźć projektanta lub programis tę, który nie zetknął się z tą problematyką.
Podobna s ytuacja występuje w obs zarze zwią zanym z językiem XML. Jego in-
tens ywny rozwój, a właś ciwie dynamiczne rozszerzanie zas tosowań ora z roz-
budowywanie technologii „z otoczki” XML możemy obs erwować od ponad
dziesięciu la t. W takiej s ytuacji jes t doś ć oczywis te, że język XML pojawił się
w otoczeniu relacyjnych ba z danych i rozpoczę ła się ich „współpraca”. Przeja-
wami tej ws półpracy i wzajemnego przenikania się obu technologii zajmiemy
się w niniejs zym wykładzie.

W ramach wykładu zos tanie zaprezentowana geneza oraz pods tawy języ-

ka XML, co ułatwi lepsze poruszanie się po omawianej problematyce. Zasadni-
czą częścią wykładu będzie jednak związek języka XML z s ys temem SQL Server
2008 i wsparcie oferowane przez to narzędzie w zakresie obsługi danych w for-
macie XML. Zaprezentowane zos taną polecenia służące do zwracania rezulta-
tów zapytań w postaci dokumentów XML, przeds tawione będą możliwości typu
danych xml, który służy do przechowywania dokumentów XML w ba zie w po-
staci natywnej, a także zos taną opisane przykłady s tosowania XML Schema do
definiowania dopuszczalnej s truktury dokumentów XML.

2 JĘZYK XML

Wra z z intens ywnym rozwojem Internetu pojawił się (a właś ciwie nabrał więk-
szego znaczenia) problem przeka zywania danych pomiędzy różnymi s ys te-
mami. Problem ten is tniał od momentu pierws zych prób łączenia kompute -
rów w sieć. Od s amego początku istniały dwa podejś cia: korzys tanie z binar-
nego zapisu danych ora z z pos taci teks towej. W okresie, gdy komputery miały
bardzo ograniczone zas oby (pamięć operacyjną, pojemnoś ć dysków, transfer
w sieci) popularniejsze były rozwiązania korzys tające z pos taci binarnej. Is tnie -
jące protokoły binarne powodowały jednak konieczność „tłumaczenia” danych
pomiędzy heterogenicznymi s ys temami (np. w jednym s ys temie liczby całkowi-
te s ą cztero-, a w drugim – dwu-bajtowe), co powodowało wzros t poziomu kom-
plikacji s ys temów rozpros zonych. Równocześnie obserwowano burzliwy roz-
wój usługi WWW, dla której pokonanie bariery pomiędzy różnymi architektura -
mi nie s tanowiło problemu, gdyż stosowanym rozwią zaniem było przeka zywa -

nie danych w pos taci tekstowej, czego przejawem stał się język HTML. Jego suk-
ces i rosnąca popularność ujawniły jednak wiele niedoskonałości. Wys tarczy
wspomnieć o tzw. wojnie przeglądarek, polegającej z grubsza na różnym spo-
sobie interpretowania (czyli renderowania) dokumentu HTML przez różne prze -
glądarki oraz na dodawaniu przez producentów przeglądarek nowych elemen-
tów (spoza specyfikacji HTML), które były interpretowane przez ich produkt.
W efekcie idea HTML – jako języka służącego do przekazywania treści wra z
z informacjami nadającymi znaczenie poszczególnym fragmentom teks tu – zo-
s tała wypaczona, a sam język zos tał sprowadzony do poziomu języka opisu
układu (ang. layout) dokumentu.

Przez kilka lat taka s ytuacja była obowiązującym s tandardem, a twórcy

s tron WWW używali w dokumentach HTML wielu karkołomnych „sztuczek” dla
osiągania konkretnych efektów wizualnych. Koniecznoście było w takiej s ytu-
acji tworzenie kilku wersji s trony WWW, które działały poprawnie w konkret-
nych przeglądarkach. Jednocześnie rosły możliwości komputerów (graficzne,
obliczeniowe) ora z wymagania s tawiane s tronom WWW. Prowadziło to do po-
głębiania się chaosu w ś wiecie technologii internetowych.

I tak w 1996 roku pows tał pomysł s tworzenia nowego języka dla potrzeb In-

ternetu. Miał to być pros ty język, z pros tymi regułami dotyczącymi jego skład-
ni, czytelny zarówno dla człowieka jak i dla mas zyn, ora z możliwie uniwers alny
jako nośnik danych i informacji o ich s trukturze. W efekcie tych prac pows tał ję -
zyk XML (ang. Extensible Markup Language). Wizualnie zbliżony do HTML (s to-
sowanie znaczników i elementów atrybutów), choć od samego początku rygo-
rys tycznie podchodzący do poprawnego formułowania dokumentu. Mimo, że
XML jes t tylko podzbiorem is tniejącego od dawna języka SGML (ang. Standa-
rized General Markup Language) o potężnych możliwościach, szybko oka zało
się, że z racji s wojej prostoty, XML wyparł SGML z większoś ci za stos owań.

Wra z ze wzros tem popularności języka XML pojawiły się narzęd zia służą -

ce do jego „obróbki”. Dziś trudno znaleźć jakikolwiek język progra mowania ,
w którym nie byłoby bibliotek obsługujących XML (w zakresie odczytu, two-
rzenia i weryfikacji poprawności). Właśnie łatwoś ć sprawdzenia poprawności
s yntaktycznej i semantycznej dokumentów XML s tanowi jeden z głównych ar-
gumentów przemawiających za jego s tos owaniem. Po co tworzyć dla ka żde -
go s ystemu os obne formaty plików z danymi oraz mechanizmy sprawdzające
ich poprawność, skoro można użyć w ka żdym przypadku jednego i tego same-
go narzędzia?

< 4 >

Informatyka +

Reguły określone dla struktury dokumentu XML są pros te i przejrzys te, ora z

nie zawiera ją wyjątków. Aby dokument XML mógł być uznany za poprawnie
sformułowany (tzn. zgodny z ws zystkimi wymaganiami co do s yntaktyki) musi
spe łniać nas tępujące reguły:

■

składać się z elementów, przy czym jeden z elementów jes t elementem
głównym i zawiera w sobie pozos tałe;

■

element skła da się (podobnie jak w HTML) ze znaczników: otwierającego
i zamykającego. Język HTML dopuszczał brak znacznika zamykającego
w miejscach, w których można się było domyślić, że element powinien
być zamknię ty (np. przy definiowaniu komórek w tabeli znacznik <td> nie
musiał być zamykany, bo wiadomo, że gdy po nim pojawiał się kolejny <td>
to oznaczał początek kolejnej komórki tabeli). W dokumencie XML ka żdy
element musi być zamknięty. Jeżeli element nie ma zawartoś ci to można
zas tosować formę skróconą (zamias t znacznika zamykającego umieszcza się
po na zwie znacznika otwierającego znak /. Na przykład: <br />);

■

elementy mus zą być poprawnie zagnieżdżone – zakres objęty elementem
musi być jednoznacznie określony. Innymi słowy: jeden element może
zawierać w s obie inny, ale tylko w całości (wraz ze znacznikiem zamykającym);

■

ka żdy element może zawierać atrybuty. Są one definiowane wewnątrz
znacznika otwierającego po nazwie elementu. Każdy atrybut musi mieć
wartość – w przeciwieńs twie do HTML, gdzie takiej koniecznoś ci nie było.
Wartość atrybutu musi być ujęta w apos trofy lub cudzysłów;

■

w dokumentach XML jes t rozróżniana wielkoś ć liter i jes t ona is totna.
Elementy <dane />, <Dane /> i <DANE /> to trzy różne elementy; .

■

podobnie ja k w dokumencie HTML, jeżeli w treści dokumentu chcemy umieścić
znak, który mógłby powodować niejasności w interpretacji dokumentu
– zas tępuje my go odpowiednią encją. Na przykład, w przypadku:

<wyrazenie>Ala<Ela</wyrazenie>

Znak < pomiędzy słowami Ela i Ala mógłby zos tać błędnie zinterpretowany jako
początek elementu o nazwie Ala. Po zas tąpieniu go encją otrzymujemy:

<wyrazenie>Ala&lt;Ela</wyrazenie>

Co jes t już p oprawnie interpretowane.

Poprawnoś ć dokumentów XML można rozpatrywać na dwóch poziomach: s yn-
taktycznym i s emantycznym. Pierws zy z nich jes t określony przez opis ane wy-
żej reguły dotyczące tworzenia dokumentów XML Jeżeli dokument pod wzglę -

dem składniowym spełnia te reguły, to jes t dokumentem poprawnie sformuło-
wanym (ang. well formed ).

Jeżeli ten poziom weryfikacji nie wys tarcza, można sięgnąć po dodatkowe

narzędzia , aby nałożyć ograniczenia semantyczne (np. w każdym elemencie
„os oba” musi wys tąpić co najmniej jeden element „imie”, wartością atrybutu
pes el musi być ciąg 11 cyfr). Najczęś ciej s tosowane s ą rozwiązania: DTD (ang.
Document Type Definition) i XML Schema .

DTD jes t rozwią zaniem s tars zym i o ograniczonych możliwoś ciach. Obecnie

znacznie częściej s tosuje się XML Schema , co nie znaczy że zapewnia ono moż-
liwość zdefiniowania dowolnych reguł dotyczących dopus zczalnej zawartoś ci
dokumentu XML. Jako alternatywa dla XML Schema wymieniane jes t też Rela x
NG. Jest to rozwią zanie porównywalne z XML Schema , o nieco innej specyfice
i możliwościach. Zależnie od reguł, które chcemy wymusić, w dokumencie moż-
na s tos ować konkretne rozwiązania. Najis totniejsze jes t jednak to, że niezależ-
nie od platformy sprzętowej jak i programowej, raz określone reguły mogą być
weryfikowane w taki s am spos ób za pomocą narzędzi dostępnych dla konkret-
nej platformy.

Jeżeli dokument jes t poprawnie sformułowany ora z spe łnia reguły opisane

w DTD lub XML Schema, to jes t dokumentem poprawnym (ang. valid ). Istnieje
wiele narzędzi służących do sprawdzania poprawności dokumentów XML, s ą to
tzw. pars ery walidujące. Połączenie XML z XML Schema, przy wsparciu ze s tro-
ny narzędzi, umożliwia bardzo łatwe rozwią zywanie problemów z projektowa-
niem formatów przeka zywania czy przechowywania danych. Wysta rczy opra-
cować dla konkretnego problemu dokument XML Schema i przekazać zaintere -
sowanym s tronom. Twórcy dokumentów XML będą mieli wszys tkie informacje,
niezbędne do utworzenia dokumentów w pos taci zgodnej z założeniami. Z ko-
lei, twórcy oprogramowania, które ma takie dane interpretować, będą wiedzie-
li czego mogą spodziewać się w dokumencie ora z będą mieli możliwoś ć łatwe -
go sprawdzenia poprawnoś ci dokumentu przed rozpoczęciem jego przetwarza-
nia. Taki s chemat sprzyja rozkwitowi technologii zwią zanych ze s tos owaniem
XML. Można tu wymienić dla przykładu język SVG (ang. Scalable Vector Gra-
phics) czy MathML. Oba definiują pos tać dokumentu XML, który na s tępnie jes t
przetwarzany na grafikę wektorową lub równanie matematyczne.

Pods umowując kwestię weryfikacji dokumentów XML: dla dowolnego problemu,

dla którego specyfikuje się format dokumentu XML, można za pomocą s tandardo-
wych narzędzi zdefiniować dodatkowe reguły semantyczne i weryfikować automa -

> Dokumenty XML w relacyjnych ba zach danych – czyli wojna ś wiatów

< 5 >

tycznie ich spełnienie. Dzięki temu można ujednolicić wstęp do proce su przet wa -
rzania danych z dokumentu XML do pos taci sprawdzenia poprawności sformułowa-
nia i poprawności dokumentu. Dalsze przet warzanie odbywa się już przy założeniu
poprawnoś ci dokumentu, co upras zcza ten proces ze względu na gwarancję co to
struktury i zawartoś ci przetwarzanego dokumentu.

3 JĘZYK XML ALTERNATYWĄ

DLA RELACYJNYCH BAZ DANYCH

Skoro język XML umożliwia łatwe budowanie dokumentów o hierarchicznej
strukturze, to czy może s tanowić alternatywę dla relacyjnych ba z danych? Moż-
na przecież zas tąpić relacje odpowiednim zagnieżdżaniem elementów. Teore-
tycznie jes t to jak najbardziej możliwe, ale praktycznie raczej nie.

W dokumencie XML, co prawda , można za stąpić relacje odpowiednim za -

gnieżdżanie m elementów oraz s tosowaniem atrybutów, ale to podejś cie spraw-
dza się wyłącznie przy małej iloś ci danych. Przy niewielkim rozmiarze doku-
mentu może on śmiało rywalizować z ba zą danych, lecz wra z ze wzros tem roz-
miaru dokumentu, XML szybko zos taje w tyle i osiąga „masę krytyczną” co po-
woduje ogromny spadek wydajności przy jego przetwarzaniu. Podobnie wyglą -
da definiowanie ograniczeń s tos owanych do zawartoś ci i s truktury dokumen-
tu XML. Narzędzie XML Schema, mimo rozbudowanych możliwości, okazuje się
jednak niewys tarczające i powstaje konieczność dobudowywania własnych
mechanizmów służących zapewnieniu spójności danych. To wszys tko powodu-
je, że s tos owanie języka XML w charakterze bazy danych s taje się coraz bar-
dziej złożone, co s zybko przera sta stopień złożonoś ci prawdziwej bazy relacyj-
nej zas tosowanej do rozwiązania tego s amego problemu, a co za tym idzie s to-
sowanie XML w tym przypadku staje się ekonomicznie nieuzas adnione.

Obs zarem, w którym XML sprawdza się jednak bardzo dobrze w roli ba zy da-

nych jes t pe łnienie funkcji maga zynu danych off-line. Polega to na tworzeniu
aplikacji, które łącząc się z ba zą danych, pobierają dane niezbędne do pracy
aplikacji i przechowują je na komputerze użytkownika w pos taci XML. Dals za
praca odbywa się na danych z XML już bez połączenia z ba zą danych i dopie -
ro w momencie s ynchronizacji dane s ą uaktualniane w bazie. Przykładem tego
typu rozwiązania jest kla sa DataSet z .NET Framework. Ma ona bardzo rozbudo-
wane możliwoś ci przechowywania danych i śledzenia ich modyfikacji

Za sadniczo jednak język XML należy raczej rozpatrywać jako pe wnego ro-

dzaju uzupe łnienie funkcjonalnoś ci baz danych, które może być s tosowane
w przypadkach, wymagających tworzenia rozbudowanej s truktury tabel, aby
zamodelować zbiór cech informacyjnych o zróżnicowanej strukturze. Tu XML
sprawdza się znakomicie, co potwierdza coraz większe wsparcie dla korzys ta-
nia z XML w relacyjnych ba zach danych oferowane przez pos zczególnych pro-
ducentów. W ramach niniejszego wykładu prezentowane będą takie właśnie
mechanizmy w odniesieniu do s ys temu SQL Server 2008.

4 JĘZYK XML W MICROSOFT SQL SERVER 2008

Klauzula FOR XML pole cenia SELECT
Pierwszym zagadnieniem dotyczącym zas tos owania języka XML w bazach da-
nych było zwracanie wyników zapytań w formie dokumentów XML. Jes t to wy-
godny mechanizm, szczególnie gdy aplikacja korzys ta z danych o bardziej zło-
żonej strukturze. Zbudowanie dokumentu XML umożliwia stworzenie s truktu-
ry adekwatnej do wymagań i pozwala uniknąć np. wielokrotnego komuniko-
wania się z bazą danych w celu pobierania różnych fragmentów potrzebnych
danych. Ba za w odpowiedzi na jedno zapytanie zwraca odpowiedni dokument
XML, a aplikacja zajmuje się jego przetworzeniem, co zwykle odbywa się z wy-
korzys taniem gotowych narzędzi i rozwią zań (np. jako trans formacja dokumen-
tu XML do postaci s trony HTML lub do dokumentu PDF czy XLS).

SQL Server począws zy od wersji 2000 dopus zcza zwracanie rezultatu wy-

konania polecenia SELECT w pos taci fragmentu lub kompletnego dokumentu
XML. Żeby skorzystać z tej możliwości należy dobrać odpowiedni wa riant klau-
zuli FOR XML. Wys tępuje ona w czterech wariantach:

■

RAW

■

AUTO

■

EXPLICIT

■

PATH

W pros ts zych przypadkach mogą to być tryby RAW albo AUTO. Służą one do t wo-
rzenia pros tej reprezentacji zbioru wynikowego jako fra gmentu dokumentu XML
z opcją ujęcia go w zdefiniowany element główny (root). W przypadku is tnienia wy-
magań generowania bardziej złożonej struktury dokumentu XML, mamy do dyspo-

< 6 >

Informatyka +

zycji klauzulę FOR XML w wariantach EXPLICIT ora z PATH. Wariant PATH, podobnie
jak RAW czy AUTO, można za stos ować do większoś ci zapyta ń, gdyż bardzo łatwo
dostos ować zapytanie do postaci wymaganej przez ten wariant klauzuli FOR XML.
Inaczej wygląda s ytuacja w przypadku wariantu EXPLICIT, który ma ściśle określo-
ne wymagania co do pos taci zbioru wynikowego, który ma być przeks ztałcony na
postać XML, tzw. tablica uniwersalna. Taka tablica jes t zwykle generowana za po-
mocą wieku zapytań łączonych klauzulą UNION. Pos zczególne zapytania zwracają
wartoś ci różnych kolumn zbiorczego wyniku zapytania .

Najpros tszym do zas tos owania jes t tryb RAW. Jego działanie sprowadza się

do wygenerowania dla ka żdego wiersza ze zbioru wynikowego jednego ele -
mentu XML o domyślnej nazwie row. Wartości poszczególnych kolumn dla wier-
sza s tają się wartościami atrybutów elementu row. Można także określić wła-
sną nazwę dla elementu row oraz zamias t atrybutów wybrać generowanie war-
toś ci z kolumn jako elementów XML o takiej nazwie jak nazwa kolumny. W ra-
mach trybu RAW można s tos ować dodatkowe opcje:

■

Opcja ROOT powoduje dodanie do rezultatu zapytania elementu głównego
o domyślnej na zwie root, bądź dowolnej innej określonej w ramach opcji.

■

Korzys tanie z opcji ROOT jes t pows zechną praktyką, gdyż tylko wtedy
zwrócony dokument XML spełnia reguły składni i jes t poprawnie
sformułowa ny, co umożliwia jego dals ze przetwarzanie.

■

Opcja ELEMENTS powoduje, że zamia st atrybutów, do umieszczenia
zawartości kolumn s ą wykorzys tane elementy o na zwach takich, jak
poszczególne kolumny.

W tym momencie na suwa się pytanie: Czy s tos ować elementy czy atrybuty?
Jes t ono jednym z częściej zadawanych pytań dotyczących planowania struktu-
ry dokumentów. Nies tety nie ma na nie jednoznacznej odpowiedzi, warto nato-
mias t zdawać s obie sprawę, że korzys tanie z atrybutów:

■

zmniejsza rozmiar wynikowego dokumentu,

■

uniemożliwia nadawanie s truktury zawartości atrybutu,

■

ogranicza liczebność wys tąpień atrybutów o tej samej na zwie w ramach
elementu do jednego.

Korzys tanie z elementów natomia s t:

■

zwięks za rozmiar wynikowego dokumentu,

■

umożliwia w ra zie potrzeby nadawanie s truktury wartościom elementu.

Dla przykładu weźmy dwa elementy:

<dane osoba=‘Jan Nowak’/>

i

<dane><osoba>Jan Nowak</osoba></dane>

Widać, że pierwszy wariant jes t bardziej zwięzły. Nie można natomia st wyko-
nać w nim dodania drugiej „os oby” do elementu dane, chyba , że w karkołom-
ny sposób:

<dane osoba=‘Jan Nowak’ osoba2=‘Tomasz Kowalski’ />

W drugim wariancie nie ma takiego problemu:

<dane><osoba>Jan Nowak</osoba><osoba>Tomasz Kowalski

</osoba></</dane>

Podobnie, gdy chcemy nadać zawartoś ci atrybutu czy elementu osoba jaką ś
s trukturę, to pierwszy wariant skutecznie to uniemożliwia.

Drugi wariant umożliwia natomia st s wobodne wykonanie:

<dane>

<osoba>

<imie>Jan</imie>

<nazwisko>Nowak</nazwisko>

</osoba>

</dane>

Kolejnym trybem dos tępnym w ramach klauzuli FOR XML jes t tryb AUTO. Ma
on możliwości zbliżone do RAW z tą różnicą , że potrafi budować pros te hierar-
chie w dokumencie XML. Proces budowania hierarchii jes t oparty o heurys ty-
ki. Analizowane s ą kolejne wiers ze i wartoś ci kolumn. Umożliwia to przy od-
powiednim skons truowaniu zapytania (s ortowanie, kolejność złączeń) na s te -
rowanie pos tacią wyjściowej hierarchii dokumentu XML. Umożliwia także (po-
dobnie jak RAW) os adzenie w wyjś ciowym dokumencie XML wyge nerowane -
go dla niego dokumentu XML Schema , opisującego pos tać wyjś ciowego do-
kumentu XML.

W przypadku pojawienia się w wyniku zapytania pól binarnych, są one do-

myślnie kodowane metodą URL Encode. Jeżeli nie jes t to odpowiednie rozwią -
zanie można skorzys tać z opcji BINARY BASE64.

> Dokumenty XML w relacyjnych ba zach danych – czyli wojna ś wiatów

< 7 >

Klauzula FOR XML w wariancie EXPLICIT ma największe możliwoś ci, ale jes t

też najbardziej złożona i trudna w s tos owaniu. Nie nadaje się w przeciwień-
stwie do RAW i AUTO do za s tos owania w dowolnym zapytaniu. Żeby skorzys tać
z trybu EXPLICIT, tabela wejś ciowa musi być tzw. tabelą uniwersalną . Składa
się ona z kolumn o us talonej kolejnoś ci, na zwach i znaczeniu:

Tabela 1.
Przykład tabeli uniwersalnej

Przykładowo (patrz tab. 1) pierws zą kolumną musi być kolumna Tag, która za-
wiera unikatowy numer dla ka żdego elementu, który będzie generowany. Dru-
ga kolumna ma nazwę Parent i określa wartość Tag dla rodzica elementu.
Kolejne kolumny definiują składowe elementów XML. Na zwy tych kolumn są
tworzone w oparciu o schemat na zwaElementu!Tag!Na zwa Atrybutu!Dyrekty-
wa. Umożliwia to dokładne s terowanie procesem definiowania s truktury ele -
mentów i atrybutami. Dokładne omówienie mechanizmu działania trybu EXPLI-
CIT wykracza poza zakres niniejs zego opracowania. Klauzula FOR XML EXPLI-
CIT pomimo dużych możliwoś ci definiowania struktury wynikowego dokumen-
tu XML jes t obarczona wadami związanymi z trudnościami w przygotowaniu od-
powiedniego zapytania wejś ciowego. Szczególnie nieprzyjemne jes t modyfiko-
wanie już is tniejącej struktury. Jes t to proces żmudny i podatny na błędy, czę -
sto skutkujący pis aniem zapytania od nowa.

Wraz z SQL Server 2005 pojawił się tryb PATH. Jes t on rozs ądnym kompromi-

sem pomiędzy możliwościami w zakresie definiowania s truktury XML, a łatwo-
ścią zapisu tych reguł. W uproszczeniu, tryb PATH ba zuje na na zwach nadawa-
nych kolumnom zapytania. Mają one pos tać zbliżoną do wyra żeń języka XPath
(znanego ka żdemu, kto uważa się za eksperta od XML) wska zujących elementy
bądź atrybuty. Na ich pods tawie budowana jes t wyjściowa s truktura XML. Moż-
na ją dodatkowo komplikować poprzez zagnieżdżanie zapytań. Pamiętać nale -
ży jedynie o odpowiedniej kolejnoś ci wys tępowania kolumn w zapytaniu – te

definiujące atrybuty elementu muszą wystąpić przed definiującymi kolejne lub
zagnieżdżone elementy.

Jeżeli kolumna w wyniku zapytania ma być elementem, to domyślną jego

nazwą będzie nazwa kolumny. Jeżeli ma być atrybutem – należy nadać kolum-
nie alias zaczynający się od znaku @ (małpki). Alias może zawierać także zna-
ki ukośnika, które określają kolejne poziomy zagnieżdżenia. Z kolei znak *
(gwia zdka) powoduje, że w przypadku kolumny typu XML, jej zawartoś ć będzie
os adzona w wyniku zapytania wpros t. Dla kolumn innych typów ws tawiony bę -
dzie węze ł teks towy z zawartoś cią.

Wszys tkie opisane warianty klauzuli FOR XML mają jes zcze kilka opcji,

z którymi warto się zapoznać. Jako przykład można podać opcję TYPE powo-
dującą, że zwrócona wartość jes t traktowana jak zmienna typu XML, co umoż-
liwia wygodne dals ze jej przetwarzanie. Równie ciekawa jest opcja XSNIL, któ-
ra umożliwia umies zczenie w wynikowym dokumencie XML elementów, które
mają w wejściowym zapytaniu wartość null i domyślnie nie byłyby umieszczone
w wyniku. Jes t to s zczególnie is totne przy przetwarzaniu zwróconych danych
w aplikacji, która niekoniecznie ma skąd wziąć pe łną lis tę dopuszczalnych ele-
mentów, które można w ramach przetwarzania uzupełnić. Oczywiś cie można
próbować ten problem rozwią zać za pomocą osadzania XML Schema, ale jest
to bardziej złożone i pracochłonne.

Opisane pokrótce możliwości SQL Server 2008 w zakresie zwracania wy-

ników zapytań w pos taci XML nie wyczerpuje ws zys tkich możliwoś ci is tnieją-
cych w tym narzędziu, s ygnalizują jedynie pods tawowe mechanizmy i ich za-
s tos owanie,

Typ danych XML
Kolejnym obszarem zas tos owania XML w SQL Server 2008 jes t typ danych XML.
Służy on do przechowywania dokumentów lub fragmentów dokume ntów XML
bezpośrednio w bazie danych oraz do wygodnego manipulowania nimi i wali-
dowania z za stosowaniem XML Schema . Dane XML w bazie mogą wys tępować
w dwóch wariantach:

■

skojarzone z kolekcją dokumentów XML Schema (typed XML),

■

nieskojarzone z XML Schema (untyped XML).

Skojarzenie kolumny typu XML ze schemą powoduje nadanie ograniczeń s truk-
turze dokumentów XML które mogą być umies zczone w tej kolumnie. Ograni-

< 8 >

Informatyka +

czenia te s ą weryfikowane automatycznie przy ka żdej operacji dodania czy mo-
dyfikacji zawartości kolumny XML.

Zanim skorzysta się z typu danych XML warto zapoznać się z jego dokumen-

tacją. Szczególnie chodzi tu o sposób przechowywania dokumentu ora z o ogra-
niczenia zwią zane z s amym typem danych. Warto również zas tanowić się nad
korzys taniem z kolekcji XML Schema ora z indeksów XML. Is totną informacja
jes t to, że dokument nie jes t zapis ywany w bazie wprost, tylko przechodzi pro-
ces normalizacji (modyfikacja dokumentu, kodowanie w Unicode, eliminowa-
nie niepotrzebnych ciągów i znaków itp.). Eliminuje to możliwoś ć korzys tania
z tego typu danych wszędzie tam, gdzie wa żna jest oryginalna pos tać doku-
mentu (np. kwes tie podpisu elektronicznego)

Deklarowanie kolumn typu xml nie odbiega od deklarowania kolumn ka żde -

go innego typu. Jedyną specyficzną rzeczą jes t – w przypadku kolumny ze sko-
jarzoną kolekcja dokumentów XML Schema – umies zczenie w nawia sie w de -
klaracji typu na zwy tej kolekcji.

Sama kolekcja dokumentów XML Schema zawierać może jedną bądź wiele

pojedynczych s chem, które zapisuje się jedna pod drugą. Po skojarzeniu kolek-
cji z kolumną typu xml, ka żda wartoś ć wpis ywana do tej kolumny będzie wali-
dowana pod kątem zgodnoś ci z którą ś ze schem z kolekcji. W przypadku braku
zgodnoś ci – operacja zapisu zos tanie anulowana.

Tworzenie dokumentów XML Schema (zwane też modelowaniem dopus z-

czalnej s truktury dokumentów XML) jes t zagadnieniem bardzo rozbudowanym
i wykracza poza ramy niniejszego wykładu. Przy założeniu, że mamy już okre-
śloną pos ta ć dokumentu XML Schema, stworzenie kolekcji schem jes t pros te
i ogranicza s ię do wykonania jednego polecenia. Od tego momentu można uży-
wać zdefiniowanej w ten sposób kolekcji przy deklaracjach kolumn typu xml.

Kiedy w praktyce należy s tosować typ danych xml? W tej kwes tii zdania

są podzielone. Jedni z definicji odrzucają xml traktując go jako niepotrzebny
a wręcz s zkodliwy wodotrysk (s tawiając m.in. zarzuty co do kiepskiej wydajno-
ści), drudzy używają go gdzie tylko się da , zas tępując jedną kolumną xml s truk-
turę kilku ta bel lub tworząc procedury składowane, którym przekazuje się tylko
jeden parametr typu xml, z którego s ą potem „wydłubywane” konkretne warto-
ści. W skrajnych przypadkach cała komunikacja z ba zą danych sprowadza się
do wymiany dokumentów XML. Z aplikacji przychodzi żądanie z parametrami
w pos taci xml, na które ba za odpowiada zwracając dokument xml z odpowied-
nią strukturą danych. Sprowadza to komunikację z bazą danych do pos taci zbli-

żonej do korzystania z usług sieciowych (webservices), które s tają s ię w os tat-
nich latach cora z bardziej popularne.

W przypadku niniejs zego wykładu, z typu danych xml skorzys taliśmy

w dwóch tabelach w przykładowej ba zie danych, patrz rys . 1.

Rysunek 1.
Tabele przykładowej ba zy danych

W pierws zej tabeli (Klient) kolumna xml służy do przechowywania danych tele-
adresowych klienta (różne rodzaje adres ów, identyfikatorów z komunikatorów
itp.). W drugiej tabeli (Produkt), xml zos tało za stos owane do przechowywania
specyfikacji produktu. Ze względu na to, że produkty różnych kate gorii mogą
być opis ywane zupe łnie innym zbiorem cech – za stosowanie xml w połączeniu
z kolekcja s chem zapewni wygodny mechanizm przechowywania specyfikacji
produktów. Podobnie wygląda s ytuacja w przypadku pierws zej kolumny – tu
kolekcja schem ma zapewnić opisanie i wymuszenie odpowiedniej p os taci lis ty
adresów/ kontaktów klienta. W skład takiej lis ty mogą wchodzić adres y poczto-
we, email czy identyfikatory różnych komunikatorów internetowych.

Skorzys tanie z typu danych XML przyczyniło się do znacznego upros zcze -

nia s truktury ba zy danych. W przypadku obu tabel przechowywane dane były-
by w pos taci zmiennego zbioru cech i ich wartości przypis anych do konkretne -
go klienta czy produktu Przy takim rozumieniu problemu jedna kolumna XML

> Dokumenty XML w relacyjnych ba zach danych – czyli wojna ś wiatów

< 9 >

eliminuje ze s truktury bazy co najmniej dwie tabele (słownik cech ora z przypi-
sanie cechy i jej wartości do klienta/ produktu). Dodatkowo, ze względu na nie -
wielki rozmiar danych XML i spos ób korzys tania z nich, nie ma co się zbytnio
przejmować spadkiem wydajności. W innych przypadkach jest to jednak bar-
dzo is totne kryterium, które częs to staje się jedną z głównych przyczyn zarzu-
cenia s tos owania typu danych XML w konkretnym projekcie.

Manipulowa nie danymi t ypu XML
Oprócz samej możliwości przechowywania dokumentów XML w kolumnie w ba-
zie danych, typ danych xml oferuje jes zcze inne możliwości. Są one udostęp-
niane jako metody, które można wywoływać na rzecz kolumny. Umożliwiają za-
awans owane odpytywanie dokumentu XML ora z manipulowanie jego struktu-
rą. Mechanizm ten działa w oparciu o język XQuery oraz wyra żenia XPath. War-
to za znaczyć, że implementacja XQuery i XPath w SQL Server 2008 nie zawiera
wszys tkich możliwoś ci wynikających z ich specyfikacji.

Język XQuery, jak i wspomniany już wcześniej XPath są rozwiązaniami stwo-

rzonymi i rozwijanymi przez organizacje W3C (ang. World Wide Web Consor-
tium). Zas tosowanie ich w miejsce własnych (Microsoftu) rozwiązań jes t prze -
jawem przykładania cora z więks zej wagi do otwartych technologii, co jes t ce -
chą charakterys tyczna całego ś wiata XML. Język XPath jest zaprojektowany do
wska zywania (wybierania) odpowiednich węzłów dokumentu XML. Wyra żenia
XPath z reguły nie funkcjonują samodzielnie, są natomias t s zeroko s tos owane
w innych rozwiązaniach (np.: XSLT, XQuery).

Rola XQuery, jak sama nazwa wskazuje, polega na odpytywaniu dokumentu XML.

Oprócz proste go wariantu bazującego na wyrażeniach XPath, można s tosować roz-
budowane wyra żenia FLWOR (na zwa pochodzi od s łów: For, Let, Where, Order by,
Return). XQuery bywa częs to porównywany do polecenia SELECT znanego z języka
SQL, i mówi s ię że XQuery jes t dla XML tym, czym SELECT dla SQL.

Wróćmy jednak do możliwości t ypu danych XML. Otóż zawiera on pięć metod,

które mają za zadanie ułatwienie korzys tania z danych zawartych wewnątrz doku-
mentu XML oraz modyfikowanie s amego dokumentu. Dodatkowo dają one możli-
wość wykonania operacji odwrotnej do działania klauzuli FOR XML – czyli do prze -
trans formowania danych z XML w wiers z zbioru wyników (rowset).

Aby korzys tać z metod typu XML, należy opanować dodatkowo pods tawy

wspomniane go języka XQuery ora z XPath, gdyż wyra żenia zbudowane w opar-
ciu o nie s ą stosowane w parametrach wywołania metod typu xml

Krótki opis metod typu XML zawiera poniżs ze zestawienie:

■

Metoda value(xquery,typ) służy do wskazania poprzez wyrażenie XPath
elementu lub atrybutu, którego wartość będzie pobrana z dokumentu XML
a nas tępnie skonwertowana do typu wska zanego w drugim parametrze
wywołania metody value().

■

Metoda exist(xquery) służy do sprawdzenia czy kolumna XML zawiera
w s wojej wartoś ci element lub atrybut wska zany przez wyra żenie XQuery.
Podobny efekt da się osiągnąć za pomocą metody value(). Jeżeli je dnak nie
ma konieczności pobierania wartoś ci z xml, a tylko sprawdzenia jej istnienia,
to metoda exist() jest zalecana ze względu na s zybs ze działanie.

■

Metoda query(xquery) służy do wskazania przez wyrażenie xquery
zbioru węzłów z dokumentu XML, które są na stępnie zwracane także jako
zmienna typu XML.

■

Metoda nodes(xquery) służy do przetworzenia danych zawartych
w dokumencie XML na pos tać relacyjną. Z jej pomocą (ora z z wykorzys taniem
operatora CROSS APPLY) można wybrać węzły dokumentu, które będą
tworzyły kolumny wiers za danych w zbiorze wynikowym zapytania SELECT.
Rezultatem działania metody nodes() jest zbiór wierszy zawierający logiczne
kopie węzłów dokumentu XML wybranych przez wyra żenie xquery. Funkcja
ta jes t s zczególnie użyteczna i wygodna gdy tworzymy zapytanie, które
ma zawierać w kolumnach pos zczególne informacje zas zyte w s trukturze
elementów i atrybutów dokumentu XML

■

Metoda modify(xmldml) służy do modyfikowania zawartoś ci dokumentu
XML. Modyfikacje te s ą realizowanie za pomocą poleceń języka XML DML
(ang. XML Data Manipulation Language). W skład XML DML wchodzą trzy
polecenia:

■

insert

– służące do dodawania nowych węzłów (elementów, atrybutów,

węzłów teks towych itp.) do dokumentu XML

■

delete

– służące do usuwania węzłów z dokumentu

■

replace value of

– służące do zas tępowania zawartoś ci wę zła

dokumentu inna zawartością
Możliwoś ci tych trzech poleceń s ą dość ograniczone i łatwe do za stosowa-
nia wyłącznie w przypadku pros tych modyfikacji operujących z reguły na
wartościach podawanych w pos taci s tałych łańcuchów znaków. Gdy po-
trzebne s ą możliwości dynamicznego budowania wartoś ci, która ma być
ws tawiona do dokumentu to s zybko oka zuje się, że jes t to trudne bądź

< 10 >

Informatyka +

wręcz nie możliwe. Dlatego, gdy wymagane s ą bardziej złożone operacje na
dokumencie XML, to s ą realizowane one po s tronie aplikacji a ich gotowy
wynik jes t przekazywany do bazy.

Możliwości manipulowania danymi zapisanymi w kolumnach lub zmiennych
typu XML s ą istotnym elementem składowym funkcjonalnoś ci obsługi XML
w ba zie danych. Umożliwiają realizowanie typowych operacji na danych XML
w sposób zbliżony do znanego ze ś wiata XML. Jest to bardzo istotne ze względu
na łatwoś ć zas tos owania tych rozwiązań w praktyce.

5 PODSUMOWANIA

W ramach niniejs zego wykładu zaprezentowany zos tał pokrótce język XML oraz
rozwa żyliśmy możliwoś ci korzys tania z niego w relacyjnych ba zach danych.
Z racji rosną cej popularnoś ci tego języka oraz coraz bogatszego wsparcia ze
strony producentów s erwerów ba z danych, warto się nim zainteres ować, aby
móc rozwa żać go jako jedną z opcji przy projektowaniu baz danych. Jako przy-
kład serwera baz danych, oferującego wsparcie dla XML, wykorzys tany zos tał
SQL Server 2008. W ramach omawiania jego możliwoś ci w kontekście XML, za-
s ygnalizowa ne zostały główne obszary, w których serwer oferuje narzędzia słu-
żące do obsługi dokumentów XML. Przyjrzeliśmy się klauzuli FOR XML s tos owa -
nej do zwra cania wyników zapytania w pos taci dokumentów lub fragmentów
dokumentów XML. Zapoznaliśmy się także z typem danych xml, który służy nie
tylko do przechowywania danych w tym formacie, ale także do zaawans owa-
nego odpytywania dokumentów XML oraz manipulowania ich zawartością. Do-
datkowo, ws pomnieliśmy o wykorzys tywanych w ramach SQL Server 2008 in-
nych technologiach i narzędziach wspierających XML. Warto tu wymienić choć-
by XQuery, XPath oraz XML Schema. Wszys tkie te rozwiązania s ą otwarte, nie
stanowią własności żadnej firmy i s ą rozwijane przez konsorcjum W3C i s ze -
roko adoptowane w ś wiecie IT. Umożliwia to ekspertom od XML na łatwe wy-
korzys tanie nabytej wiedzy również przy korzys taniu z serwerów baz danych.

Jes t jednak także druga s trona medalu. Jeśli zachłyśniemy się wsparciem

dla XML w SQL Server 2008, to bardzo szybko może nas czekać rozczarowanie.
Otóż mechanizmy wspierające XML na pierwszy rzut oka wyglądają na potę ż-
ne i wygodne. Faktycznie jes t tak ale tylko w zakresie przewidzianym przez ich

twórców. Okazuje się, że nie zaimplementowali oni w pełni s tandardów XQuery
i XPath (można s zybko natrafić na wiele nieobsługiwanych funkcji bądź ogra-
niczeń). Podobnie jes t w przypadku XML Schema. Nie ws zys tkie możliwoś ci tej
technologii s ą dopus zczalne w ramach SQL Server 2008. W zakresie manipulo-
wania s trukturą dokumentów XML również oka zuje się, że metoda modify()
z poleceniami XML DML ma bardzo dużo ograniczeń, szczególnie gd y chce się
polecenia tworzyć bardziej dynamicznie. To wszys tko nie umniejs za jednak fak-
tu, ze wsparcie XML w relacyjnych ba zach danych jes t ciekawą możliwoś cią,
z której warto korzystać, po uprzednim gruntownym zapoznaniu s ię z doku-
mentacją, aby uniknąć przykrych niespodzianek w trakcie realizacji projektu.

LITERATURA

1. Liberty J., Kraley M., XML od podstaw, Translator, Warszawa 2001
2. Rizzo T., Machanic A., Dews on R., Walters R., Sack J., Skin J., SQL Server 2005,

WNT, Wars zawa 2008

3. Vieira R., SQL Server 2005. Programowanie. Od Podstaw, Helion, Gliwice 2007
4. Walmsley P., Wszystko o XML Schema, Helion, Gliwice 2007

> Dokumenty XML w relacyjnych ba zach danych – czyli wojna światów

Notatki < 11 >

< 12 > Nota tki

Informatyka +

W projekcie Informat yka +, poza wykładami i warsztatami,

przewidziano nas tępujące działania:

■

24-godzinne kurs y dla uczniów w ramach modułów tematycznych

■

24-godzinne kurs y metodyczne dla nauczycieli, przygotowujące do pracy z uczniem zdolnym

■

nagrania 60 wykładów informatycznych, prowadzonych przez wybitnych specjalistów

i nauczycieli akademickich

■

konkurs y dla uczniów, trzy w ciągu roku

■

udział uczniów w pracach kół naukowych

■

udział uczniów w konferencjach naukowych

■

obozy wypoczynkowo-naukowe.

Szczegółowe informacje znajdują się na stronie projektu www.informat ykaplus .edu.pl