Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Tworzenie i zastosowanie <strong>XML</strong> Schema<br />
Laboratorium Baz Danych 3<br />
Materiały pomocnicze<br />
Opracował:<br />
Michał Świderski
2 / 11<br />
1. <strong>XML</strong> Schema<br />
Źródło: http://www.w3.org/TR/xmlschema-0/, punkty od 2 <strong>do</strong> 2.4.<br />
<strong>XML</strong> Schema służy <strong>do</strong> definiowania klas <strong>do</strong>kumentów <strong>XML</strong>, dlatego często stosuje się termin “instancja”<br />
określający <strong>do</strong>kument <strong>XML</strong> zgodny z danych schematem <strong>XML</strong>. Dokument po.xml opisuje zamówienie<br />
wygenerowane przez aplikację <strong>do</strong> zamawiania produktów.<br />
<br />
<br />
<br />
Alice Smith<br />
123 Maple Street<br />
Mill Valley<br />
CA<br />
90952<br />
<br />
<br />
Robert Smith<br />
8 Oak Avenue<br />
Old Town<br />
PA<br />
95819<br />
<br />
Hurry, my lawn is going wild!<br />
<br />
<br />
Lawnmower<br />
1<br />
148.95<br />
Confirm this is electric<br />
<br />
<br />
Baby Monitor<br />
1<br />
39.98<br />
1999-05-21<br />
<br />
<br />
<br />
Dokument po.xml<br />
Dokument składa się z elementu głównego, purchaseOrder, podelementów shipTo, billTo, comment, i<br />
items. Te podelementy (z wyjątkiem comment) zawierają kolejne podelementy, aż <strong>do</strong> poziomu USPrice, który<br />
zawiera liczbę zamiast podelementy. Elementy zawierające podelementy lub atrybuty są nazywane typami<br />
złożonymi (complex types), natomiast elementy, które zawierają liczby, łańcuchy, daty itd., ale nie zawierają<br />
podelementów, są nazywane typami prostymi (simple types). Niektóre elementy mają też atrybuty: atrybuty są<br />
zawsze typami prostymi.<br />
Typy złożone w <strong>do</strong>kumencie instancji i niektóre typy proste są zdefiniowane w schemacie dla <strong>do</strong>kumentów<br />
zamówień. Inne typy proste są zdefiniowane jako typy wbu<strong>do</strong>wane <strong>XML</strong> Schema.<br />
1.1 Schemat <strong>do</strong>kumentu zamówienia<br />
Schemat <strong>do</strong>kumentu zamówienia jest zawarty w pliku po.xsd:<br />
<br />
<br />
<br />
Purchase order schema for Example.com.<br />
Copyright 2000 Example.com. All rights reserved.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
3 / 11<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Schemat <strong>do</strong>kumentu zamówienia, po.xsd<br />
Schemat <strong>do</strong>kumentu zamówienia składa się z elementu schema i wielu podelementów, z których najważniejsze to<br />
element, complexType i simpleType, które określają pojawianie się elementów i ich zawartość w<br />
<strong>do</strong>kumentach instancji.<br />
Każdy element w schemacie ma prefiks xsd:, który jest powiązany z przestrzenią nazw <strong>XML</strong> Schema poprzez<br />
deklarację postaci xmlns:xsd="http://www.w3.org/2001/<strong>XML</strong>Schema", która pojawiła się w elemencie<br />
schema. W przykładzie użyto prefiksu xsd:, ale może być tu użyty każdy inne prefiks. Ten sam prefiks, i dlatego<br />
to samo powiązanie, pojawił się przy nazwach wbu<strong>do</strong>wanych typów prostych np.: xsd:string. Powiązanie to<br />
istnieje by określić elementy i typy proste jako należące <strong>do</strong> słownictwa języka <strong>XML</strong> Schema. W dalszej części<br />
będziemy pomijać prefiksy by nie zaciemniać przykładów.<br />
1.2 Definicje typów złożonych, deklaracje elementów i atrybutów<br />
W schemacie <strong>XML</strong> (<strong>XML</strong> Schema) istnieje podstawowa różnica pomiędzy typami złożonymi, które mogą zawierać<br />
elementy i atrybuty, a typami prostymi, które nie mogą zawierać elementów ani atrybutów. Istnieje również<br />
rozróżnienie pomiędzy definicjami, które tworzą nowe typy (proste i złożone), a deklaracjami, które pozwalają<br />
elementom prostym i złożonym z określonymi nazwami i typami pojawiać się w <strong>do</strong>kumentach instancji.<br />
Nowe typy złożone (complex types) są definiowane za pomocą elementu complexType i definicje te zazwyczaj<br />
zawierają zbiór deklaracji elementów, referencji <strong>do</strong> elementów oraz deklaracji atrybutów. Elementy są deklarowane<br />
z użyciem elementów element, atrybuty są deklarowane z użyciem elementów attribute.<br />
Na przykład typ USAddress jest zdefiniowany jako typ złożony i wewnątrz definicji widzimy pięć deklaracji<br />
elementów i jedną deklarację atrybutu:
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Definicja typu USAddress<br />
4 / 11<br />
Konsekwencją tej definicji jest fakt, że każdy element pojawiający się w <strong>do</strong>kumencie instancji o typie<br />
zadeklarowanym jako USAddress (np.: shipTo w po.xml) musi składać się z pięciu elementów i jednego<br />
atrybutu. Te elementy muszą być nazwane name, street, city, state oraz zip tak jak to zostało określone w<br />
deklaracjach za pomocą atrybutu name, i <strong>do</strong>datkowo elementy te muszą pojawić się <strong>do</strong>kładnie w kolejności<br />
(sequence), w której zostały zadeklarowane. Pierwsze cztery będą zawierały łańcuchy, piąty będzie zawierał<br />
liczbę. Element typu USAddress może pojawić się z atrybutem country, który musi zawierać łańcuch US.<br />
Definicja USAddress zawiera deklaracje korzystające jedynie z typów prostych: string, decimal oraz NMTOKEN.<br />
Definicja PurchaseOrderType zawiera deklaracje elementów korzystające z innych typów złożonych np.<br />
USAddress. Pomimo tego, obie deklaracje używają tego samego atrybutu type by określić swój typ, niezależnie<br />
od tego czy jest to typ prosty, czy złożony.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Definicja typu PurchaseOrderType<br />
W definicji typu PurchaseOrderType dwie deklaracje elementów (shipTo i billTo) łączą różne nazwy<br />
elementów z tym samym typem złożonym (USAddress). W konsekwencji, każdy element pojawiający się w<br />
<strong>do</strong>kumencie instancji (np. po.xml), którego typ został zadeklarowany jako PurchaseOrderType, musi składać<br />
się z elementów shipTo i billTo, z których każdy zawiera 5 podelementów (name, street, city, state i<br />
zip), które zostały zadeklarowane w USAddress. Elementy shipTo i billTo mogą <strong>do</strong>datkowo zawierać atrybut<br />
country, który został zadeklarowany jako część USAddress.<br />
Definicja PurchaseOrderType zawiera deklarację atrybutu orderDate, która po<strong>do</strong>bnie jak deklaracja atrybutu<br />
country, odnosi się <strong>do</strong> typu prostego. Tak naprawdę wszystkie deklaracje atrybutów muszą odnosić się <strong>do</strong> typów<br />
prostych, ponieważ, w przeciwieństwie <strong>do</strong> elementów, atrybuty nie mogą zawierać innych elementów ani<br />
atrybutów.<br />
Deklaracje elementów opisane <strong>do</strong> tej pory łączą nazwę z istniejącą definicją typu. Czasem lepiej jest użyć<br />
istniejącego elementu niż deklarować nowy. Np.:<br />
<br />
Ta deklaracja tworzy referencję <strong>do</strong> istniejącego elementu comment, który został zadeklarowany w innym miejscu<br />
schematu. Ogólnie, wartość atrybutu ref musi wskazywać na element globalny, tzn. zadeklarowany pod<br />
elementem schema, a nie wewnątrz definicji typu złożonego. W konsekwencji tej deklaracji, element comment<br />
może pojawić się w <strong>do</strong>kumencie instancji i jego zawartość musi być zgodna z typem elementu, w tym przypadku,<br />
string.<br />
1.2.1 Ograniczanie liczności wystąpień<br />
Element comment jest określony wewnątrz PurchaseOrderType jako opcjonalny, ponieważ wartość atrybutu<br />
minOccurs w jego deklaracji wynosi 0. Ogólnie, wystąpienie elementu jest wymagane kiedy wartość minOccurs<br />
wynosi 1 lub więcej. Maksymalna liczba wystąpień elementu jest określona przez wartość atrybutu maxOccurs w<br />
jego deklaracji. Wartość ta może być liczbą całkowitą <strong>do</strong>datnią (np. 41), lub może być określona terminem<br />
unbounded, oznaczającym, że nie narzucamy maksymalnej ilości wystąpień. Domyślna wartość obydwu<br />
atrybutów minOccurs i maxOccurs wynosi 1. Oznacza to, że kiedy element taki jak comment jest zadeklarowany<br />
bez atrybutu maxOccurs, nie może wystąpić więcej niż raz. W przypadku określania wartości jedynie dla atrybutu
5 / 11<br />
minOccurs należy upewnić się, że jest on mniejszy lub równy <strong>do</strong>myślnej warości atrybutu maxOccurs, tzn.<br />
wynosi 0 lub 1. Po<strong>do</strong>bnie, jeśli określamy wartość jedynie dla atrybutu maxOccurs, musi być ona większa lub<br />
równa <strong>do</strong>myślnej wartości minOccurs, tzn. 1 lub więcej. Jeśli oba atrybuty są pominięte, element musi pojawić się<br />
<strong>do</strong>kładnie raz.<br />
Atrybuty mogą pojawić się raz albo w ogóle, ale nie inną ilość razy, dlatego składnia określania liczności wystąpień<br />
atrybutów jest inna niż elementów. W szczególności atrybuty mogą być deklarowane z atrybutem use by określić<br />
czy atrybut jest wymagany (required), opcjonalny(optional), lub zabroniony (prohibited).<br />
Atrybut fixed jest używany w deklaracjach zarówno atrybutów jak i typów, by zapewnić, że są ustawione na<br />
konkretną wartość. Na przykład, schemat po.xsd zawiera deklarację atrybutu country, który jest zadeklarowany<br />
z wartością fixed równą US. Ta deklaracja oznacza, że obecność atrybutu country w <strong>do</strong>kumencie instancji jest<br />
opcjonalna (<strong>do</strong>myślną wartością use jest optional). Jeśli atrybut się pojawi, jego wartość musi wynosić US, a<br />
jeśli się nie pojawi, procesor <strong>XML</strong> Schema <strong>do</strong>starczy atrybut country z wartością US. Zauważmy, że pojęcia<br />
wartości fixed i wartości <strong>do</strong>myślnej są wzajemnie wykluczające i dlatego deklaracja zawierająca jednocześnie<br />
atrybuty fixed i default jest błędna.<br />
1.2.2 Elementy i atrybuty globalne<br />
Globalne elementy i atrybuty są tworzone poprzez umieszczenie ich deklaracji jako dzieci elementu schema. Raz<br />
zadeklarowany, globalny element czy atrybut, może zostać umieszczony w jednej lub więcej deklaracji poprzez<br />
użycie atrybutu ref, jak opisano powyżej. Dekaracja z referencją <strong>do</strong> elementu globalnego umożliwia temu<br />
elementowi pojawienie się w <strong>do</strong>kumencie instancji w kontekście tej deklaracji. Na przykład element comment<br />
pojawi się na tym samym poziomie co elementy shipTo, billTo i items ponieważ deklaracja odwołująca się <strong>do</strong><br />
comment pojawia się w definicji typu złożonego na tym samym poziomie, co deklaracje pozostałych trzech<br />
elementów.<br />
Deklaracja elementu globalnego umożliwia także pojawienie się tego elementu jako korzeń w <strong>do</strong>kumencie<br />
instancji, dlatego właśnie purchaseOrder, który jest zadeklarowany jako element globalny w po.xsd, może<br />
pojawić się jako element główny w po.xml. Oznacza to także, że element comment może pojawić się jako<br />
element główny w <strong>do</strong>kumencie takim jak po.xml.<br />
1.3 Typy proste<br />
Schemat po.xsd deklaruje kilka elementów i atrybutów jako typy proste. Niektóre z tych typów prostych, takie jak<br />
string i decimal, są wbu<strong>do</strong>wane w <strong>XML</strong> Schema, podczas gdy inne są wyprowadzone z wbu<strong>do</strong>wanych. Na<br />
przykład atrybut partNum ma typ nazwany SKU, który jest wyprowadzony ze string. Zarówno wbu<strong>do</strong>wany typ<br />
prosty jak i typ z niego wyprowadzony mogą być użyte w deklaracjach elementów i atrybutów. Poniżej w tabeli<br />
wypisano ważniejsze wbu<strong>do</strong>wane typy proste oraz przykłady możliwych wartości.<br />
Niektóre Typy proste wbu<strong>do</strong>wane w <strong>XML</strong> Schema<br />
Typ prosty Przykłady oddzielone przecinkami<br />
string Confirm this is electric<br />
byte -1, 126<br />
integer -126789, -1, 0, 1, 126789<br />
int -1, 126789675<br />
long -1, 12678967543233<br />
decimal -1.23, 0, 123.4, 1000.00<br />
float<br />
-INF, -1E4, -0, 0, 12.78E-2, 12, INF,<br />
NaN<br />
<strong>do</strong>uble<br />
-INF, -1E4, -0, 0, 12.78E-2, 12, INF,<br />
NaN<br />
boolean<br />
true, false<br />
1, 0<br />
time 13:20:00.000, 13:20:00.000-05:00<br />
dateTime 1999-05-31T13:20:00.000-05:00<br />
QName po:USAddress<br />
Nowe typy proste są definiowane przez wyprowadzanie ich z już istniejących typów prostych (wbu<strong>do</strong>wanych lub<br />
wyprowadzonych). W szczególności możemy wyprowadzić nowy typ prosty poprzez ograniczenie istniejącego typu<br />
prostego, co skutkuje ograniczeniem zbioru przyjmowanych wartości dla typu <strong>do</strong> jego podzbioru. Element<br />
simpleType służy <strong>do</strong> definiowania nazwy nowego typu prostego, element restriction <strong>do</strong> wskazania<br />
istniejącego (bazowego) typu prostego oraz <strong>do</strong> określenia aspektów (ang. facets) , które służą <strong>do</strong> ograniczenia<br />
zakresu wartości. Pełna lista aspektów znajduje się na stronie http://www.w3.org/TR/xmlschema-0/#SimpleTypeFacets.<br />
Załóżmy, że chcemy stworzyć nowy typ integer zwany myInteger, który przyjmuje wartości od 10000 <strong>do</strong> 99999<br />
(włącznie). Zbudujemy naszą definicję na wbu<strong>do</strong>wanym typie prostym integer poprzez ograniczenie zakresu<br />
typu integer z wykorzystaniem dwóch aspektów minInclusive i maxInclusive:
6 / 11<br />
<br />
<br />
<br />
<br />
<br />
<br />
Definiowanie myInteger w zakresie 10000-99999<br />
Kolejny typ prosty nazwany SKU jest wyprowadzony poprzez ograniczenie typu string z wykorzystaniem aspektu<br />
pattern w połączeniu z wyrażeniem regularnym "\d{3}-[A-Z]{2}", które oznacza: "trzy cyfry, potem myślnik,<br />
potem dwie wielkie litery ASCII". Wykorzystanie wyrażeń regularnych jest opisane pełniej w<br />
http://www.w3.org/TR/xmlschema-0/#regexAppendix.<br />
<br />
<br />
<br />
<br />
<br />
Definiowanie typu prostego “SKU”<br />
<strong>XML</strong> Schema definiuje piętnaście aspektów. Pośród nich aspekt enumeration jest szczególnie użyteczny i może<br />
być wykorzystany <strong>do</strong> ograniczenia każdego typu prostego, z wyjątkiem typu boolean. Aspekt enumeration<br />
ogranicza typ prosty <strong>do</strong> zbioru konkretnych wartości; np.: możemy użyć go by zdefiniować nowy typ prosty<br />
USState wyprowadzony ze string, którego wartościami będą skróty stanów USA.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Wykorzystanie aspektu wyliczenia<br />
USState byłby <strong>do</strong>bry <strong>do</strong> zastąpienia deklaracji elementu state. Po takim zastąpieniu, poprawne wartości<br />
elementu state byłyby ograniczone <strong>do</strong> jednej z AK, AL, AR, itd. Trzeba także pamiętać, że wartości wyliczenia<br />
muszą być unikalne.<br />
1.4 Definicje typów anonimowych<br />
Definicja typu Items w po.xsd zawiera dwie deklaracje elementów, które używają typów anonimowych (item i<br />
quantity). Ogólnie, można odróżnić typ anonimowy po braku atrybutu type= w deklaracji elementu lub atrybutu<br />
oraz poprzez obecność nie nazwanej definicji typu prostego lub złożonego.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Dwie anonimowe definicje typów
7 / 11<br />
W przypadku elementu item widzimy anonimowy typ złożony składający się z elementów productName,<br />
quantity, USPrice, comment,shipDate oraz atrybutu partNum. Element quantity ma anonimowy typ<br />
prosty wyprowadzony z integer, którego wartości należą <strong>do</strong> przedziału od 1 <strong>do</strong> 99.<br />
1.5 Spinanie <strong>XML</strong> Schema z <strong>do</strong>kumentem instancji<br />
W <strong>do</strong>kumencie instancji atrybut xsi:schemaLocation <strong>do</strong>starcza informacje procesorowi <strong>XML</strong> Schema,<br />
określające jakiemu schematowi dana instancja podlega. Możemy określić lokalizację schematu dla <strong>do</strong>kumentów<br />
zamówień z poprzednich przykładów:<br />
<br />
<br />
targetNamespace="http://www.example.com/PO" <br />
<br />
elementFormDefault="qualified" <br />
<br />
attributeFormDefault="unqualified"> <br />
<br />
<br />
<br />
<br />
<br />
xmlns:xsi="http://www.w3.org/2001/<strong>XML</strong>Schema-instance" <br />
xsi:schemaLocation="http://www.example.com/PO <br />
http://www.example.com/po.xsd" <br />
orderDate="1999-10-20"><br />
<br />
<br />
Użycie schemaLocation<br />
Atrybut schemaLocation składa się z pary wartości: pierwsza jest przestrzenią nazw, dla której druga wartość<br />
jest ścieżką <strong>do</strong> konkretnego <strong>do</strong>kumentu schematu. Jeśli schemat nie zawiera własnej przestrzeni nazw, należy<br />
wykorzystać atrybut noNamespaceSchemaLocation, który określa lokalizację <strong>do</strong>kumentu schematu:<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
orderDate="1999-10-20"><br />
<br />
<br />
Użycie noNamespaceSchemaLocation
2. <strong>XML</strong> Spy<br />
8 / 11<br />
Schemat <strong>XML</strong> jest zwykłym, poprawnym <strong>do</strong>kumentem <strong>XML</strong>, dlatego można go pisać w <strong>do</strong>wolnym edytorze.<br />
Istnieją jednak specjalizowane narzędzia umożliwiające graficzną edycję <strong>XML</strong> Schema i sprawdzające ich<br />
poprawność, np.: Microsoft Visual Studio .NET lub <strong>XML</strong> Spy. Podczas laboratorium proponujemy wykorzystanie<br />
narzędzia <strong>XML</strong> Spy firmy Altova http://www.altova.com/.<br />
2.1 Tworzenie <strong>XML</strong> Schema<br />
Program <strong>XML</strong> Spy <strong>do</strong>myślnie uruchamia się z aktywnym paskiem zadań „Examples”. Można obejrzeć tam<br />
przykła<strong>do</strong>we schematy tworzone za pomocą programu. Szczegółowe informacje znajdują się w systemie pomocy:<br />
• Help\Tutorial\Creating a schema from scratch<br />
• Help\Tutorial\Creating an <strong>XML</strong> <strong>do</strong>cument<br />
2.2 Annotacje Oracle <strong>XML</strong> DB<br />
O annotacjach Oracle <strong>XML</strong> DB przeczytaj punkt 3.3.<br />
Obsługa annotacji w <strong>XML</strong> Spy jest opisana w systemie pomocy:<br />
Help\User Reference\Menus\Schema Design Menu\Enable Oracle Schema extensions<br />
3. Oracle 9iR2 <strong>XML</strong> DB<br />
Na rynku pojawia się coraz więcej natywnych baz <strong>XML</strong>, jednak niewiele z nich może poszczycić się za<strong>do</strong>walającą<br />
wydajnością i funkcjonalnością. Do niniejszego ćwiczenia wybrano bazę danych Oracle 9i Release 2, która ma<br />
możliwości przechowywania danych w postaci relacyjnej i w postaci <strong>XML</strong> oraz umożliwia jednoczesne<br />
wykorzystanie obu reprezentacji danych za pomocą języka SQL/<strong>XML</strong>.<br />
3.1 Sposoby przechowywania <strong>XML</strong> w Oracle 9iR2 <strong>XML</strong> DB<br />
Przechowując <strong>do</strong>kumenty <strong>XML</strong> w bazie Oracle9i można wykorzystać wiele podejść:<br />
• Dokumenty można analizować składniowo w zewnętrznej aplikacji i przechowywać dane jako wiersze w jednej<br />
lub więcej tabel. W tym scenariuszu baza danych nie wie, że przechowuje dane <strong>XML</strong>.<br />
• Można przechowywać <strong>do</strong>kumenty <strong>XML</strong> z wykorzystaniem kolumny typu CLOB lub VARCHAR. W tym<br />
scenariuszu baza także nie wie, że przechowuje <strong>XML</strong>, ale można tu wykorzystać specjalne pakiety XDK by<br />
przetwarzać tak skła<strong>do</strong>wany <strong>XML</strong>.<br />
• Można przechowywać <strong>do</strong>kumenty <strong>XML</strong> w bazie Oracle9i wykorzystując typ <strong>XML</strong>Type. Dwie opcje są <strong>do</strong>stępne<br />
w tym scenariuszu:<br />
1. Przechowywanie <strong>do</strong>kumentów <strong>XML</strong> w kolumnie typu <strong>XML</strong>Type,<br />
2. Przechowywanie <strong>do</strong>kumentów <strong>XML</strong> w tabeli typu <strong>XML</strong>Type.<br />
CREATE TABLE Przyklad31<br />
(<br />
KEYVALUE varchar2(10) primary key,<br />
KOLUMNA_<strong>XML</strong> <strong>XML</strong>Type<br />
);<br />
Tworzenie tabeli z kolumną <strong>XML</strong>Type<br />
CREATE TABLE TABELA_<strong>XML</strong> OF <strong>XML</strong>Type;<br />
Tworzenie tabeli <strong>XML</strong>Type<br />
Obie opcje oznaczają, że baza danych jest świa<strong>do</strong>ma tego, że obsługuje zawartość <strong>XML</strong>. Wybór takiego podejścia<br />
pozwala na wykorzystanie wielu u<strong>do</strong>godnień bazy Oracle 9i, dzięki którym można wydajnie i wygodnie przetwarzać<br />
zawartość <strong>XML</strong>. Dodatkowo dane <strong>XML</strong> mogą być przechowywane jako typ <strong>XML</strong>Type na dwa sposoby:<br />
1. W sposób niestrukturalny, bez schematu <strong>XML</strong> Schema,<br />
2. W sposób strukturalny, opisany schematem <strong>XML</strong> Schema.<br />
W naszym ćwiczeniu wykorzystamy strukturalne przechowywanie <strong>do</strong>kumentów <strong>XML</strong> w tabeli typu <strong>XML</strong>Type.<br />
3.2 Cechy strukturalnego przechowywania <strong>XML</strong><br />
1. Zawartość kolumn i tabel typu <strong>XML</strong>Type jest przechowywana jako obiekty SQL. Domyślnie <strong>do</strong>kumenty <strong>XML</strong><br />
opisane schematem <strong>XML</strong> Schema są przechowywane w postaci strukturalnej. Powoduje to lekki narzut
9 / 11<br />
czasowy przy wprowadzaniu i pobieraniu <strong>do</strong>kumentów <strong>XML</strong> z bazy danych, ponieważ <strong>do</strong>kument musi zostać<br />
rozłożony na części podczas wprowadzania oraz złożony z części podczas pobierania.<br />
2. Kiedy schemat <strong>XML</strong> Schema jest rejestrowany, Oracle <strong>XML</strong> DB generuje zbiór obiektów, które odpowiadają<br />
typom złożonym zdefiniowanym w schemacie <strong>XML</strong>. Wyrażenia XPath wysyłane <strong>do</strong> funkcji Oracle <strong>XML</strong> DB są<br />
tłumaczone na zapytania SQL operujące bezpośrednio na wygenerowanych obiektach. To przepisywanie<br />
operacji na typie <strong>XML</strong>Type <strong>do</strong> zapytań obiektowo-relacyjnych SQL powoduje znaczny wzrost wydajności w<br />
porównaniu z wykonaniem tych samych operacji na <strong>do</strong>kumentach <strong>XML</strong> przechowywanych w sposób<br />
niestrukturalny.<br />
3. Przechowywanie strukturalne <strong>XML</strong> pozwala bazie Oracle <strong>XML</strong> DB minimalizować użycie pamięci i<br />
optymalizować operacje na DOM typu <strong>XML</strong>Type przez wykorzystanie:<br />
• Lazy Manifestation (LM): Oracle <strong>XML</strong> DB, zamiast konstruować całą strukturę DOM dla <strong>do</strong>kumentu <strong>XML</strong>,<br />
tworzy tylko węzły potrzebne <strong>do</strong> wykonania danej operacji. Gdy inne części <strong>do</strong>kumentu są potrzebne,<br />
odpowiednie węzły są dynamicznie <strong>do</strong>dawane <strong>do</strong> DOM.<br />
• Least Recently Used (LRU): Strategia odrzucania z DOM węzłów, które nie były ostatnio używane.<br />
4. Istnieje możliwość edycji poszczególnych elementów, atrybutów i węzłów bez przepisywania całego<br />
<strong>do</strong>kumentu <strong>XML</strong>. Dodatkowo operacja update<strong>XML</strong>() może zostać automatycznie przepisana na operację<br />
SQL UPDATE, która operuje na kolumnach lub obiektach określonych w wyrażeniach XPATH.<br />
5. Przy przechowywaniu strukturalnym <strong>do</strong>kumentów <strong>XML</strong> można wykorzystywać indeksy B*Tree oraz indeksy<br />
Oracle Text inverted list indexes. Konfiguracja przechowywania kolekcji umożliwia tworzenie indeksów na<br />
wszystkich elementach, atrybutach i kolekcjach.<br />
6. Ponieważ <strong>XML</strong> podlega schematowi <strong>XML</strong> Schema, nie ma konieczności przechowywania wszystkich<br />
znaczników, co w znaczący sposób redukuje rozmiar <strong>XML</strong>.<br />
7. Umożliwia nakładanie więzów integralności, które sprawdzają poprawność wprowadzanych danych <strong>XML</strong><br />
względem innych danych skła<strong>do</strong>wanych w bazie danych.<br />
8. Można zaopatrzyć schemat w annotacje by kontrolować: sposób generowania obiektów SQL i sposób ich<br />
przechowywania w bazie danych; sposób zarządzania kolekcjami; użycie przestrzeni tabel, partycjonowanie<br />
tabel; nazwy tabel przechowujących obiekty SQL; sposób tłumaczenia typów prostych <strong>XML</strong> Schema na typy<br />
SQL.<br />
3.3 Annotacje Oracle <strong>XML</strong> DB<br />
Aby korzystać z annotacji Oracle <strong>XML</strong> DB należy w schemacie zadeklarować przestrzeń nazw annotacji w<br />
elemencie schema: xmlns:xdb=http://xmlns.oracle.com/xdb. Poniżej opiszemy tylko dwie najistotniejsze dla nas<br />
konstrukcje.<br />
Oracle <strong>XML</strong> DB używa predefiniowanego algorytmu <strong>do</strong> generowania nazw SQL dla atrybutów, elementów i typów<br />
zdefiniowanych w <strong>XML</strong> Schema. Nazwy te są nieprzewidywalne podczas generowania i jeśli nie zostaną określone<br />
jawnie przez użytkownika, wygenerowane obiekty mogą okazać się trudne w obsłudze. Annotacja xdb:SQLName<br />
może być użyta <strong>do</strong> nadania jawnych nazw dla obiektów schematu.<br />
Aby zdefiniować nazwę tabeli, w której mają być przechowywane <strong>do</strong>kumenty <strong>XML</strong>, należy <strong>do</strong>dać atrybut<br />
xdb:defaultTable <strong>do</strong> definicji elementu głównego w schemacie.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Przykład annotacji Oracle <strong>XML</strong> DB dla schematu Osoba.xsd<br />
W powyższym przykładzie deklarujemy przestrzeń nazw xdb: jako przestrzeń nazw annotacji, określamy nazwę<br />
tabeli w której będziemy przechowywać <strong>do</strong>kumenty instancji na Osoba, i określamy nazwy elementów w bazie<br />
danych na ID, Imie i Nazwisko.<br />
<br />
1<br />
Michal<br />
Swiderski<br />
<br />
Przykład <strong>do</strong>kumentu <strong>XML</strong> zgodnego ze schematem Osoba.xsd, osoba1.xml
10 / 11<br />
3.4 Rejestracja schematu <strong>XML</strong> Schema w bazie Oracle 9i<br />
Aby korzystać ze strukturalnego przechowywania <strong>do</strong>kumentów <strong>XML</strong> podlegających schematowi <strong>XML</strong> Schema<br />
należy wykonać kilka czynności:<br />
• Wprowadzić schemat <strong>do</strong> bazy danych (patrz pkt. 3.5),<br />
• Zarejestrować schemat w bazie danych – w tym momencie generowane są odpowiednie typy obiektów <strong>do</strong><br />
obsługi schematu,<br />
• Stworzyć tabelę lub kolumnę <strong>XML</strong>Type zgodną z zarejestrowanym schematem,<br />
• Wprowadzić <strong>do</strong>kumenty <strong>do</strong> bazy danych.<br />
Wiele z tych czynności można wykonać automatycznie. Oracle <strong>XML</strong> DB umożliwia generowanie <strong>do</strong>myślnej tabeli<br />
<strong>XML</strong>Type już podczas rejestrowania schematu. Specyficzną cechą takiej tabeli jest to, że jest ona opisana jako<br />
hierarchically enabled. Oznacza to, że gdy <strong>do</strong> Repozytorium (patrz pkt. 3.5) wprowadzany jest <strong>do</strong>kument <strong>XML</strong> z<br />
elementem głównym i schematem zgodnym ze schematem naszej tabeli <strong>do</strong>myślnej, zawartość <strong>do</strong>kumentu <strong>XML</strong><br />
jest automatycznie wstawiona <strong>do</strong> tej tabeli jako kolejny wiersz. Dodatkowo, jeśli za pomocą SQL usuniemy ten<br />
wiersz z naszej tabeli, <strong>do</strong>kument <strong>XML</strong> zostanie usunięty także z Repozytorium.<br />
Do rejestrowania schematu i generowania <strong>do</strong>myślnej tabeli <strong>XML</strong>Type służy procedura registerSchema z pakietu<br />
DBMS_<strong>XML</strong>SCHEMA.<br />
procedure registerSchema(<br />
schemaURL IN VARCHAR2,<br />
schemaDoc IN CLOB,<br />
local IN BOOLEAN := TRUE,<br />
genTypes IN BOOLEAN := TRUE,<br />
genbean IN BOOLEAN := FASLE,<br />
force IN BOOLEAN := FALSE,<br />
owner IN VARCHAR2 := null);<br />
Składnia procedury registerSchema<br />
Parametry:<br />
schemaURL – <strong>do</strong>wolny URL unikalnie opisujący <strong>do</strong>kument schematu.<br />
schemaDoc - poprawny <strong>do</strong>kument <strong>XML</strong> Schema.<br />
local – określa czy schemat jest lokalny czy globalny. Domyślnie jest lokalny, czyli nie<strong>do</strong>stępny z zewnątrz bazy<br />
danych.<br />
genTypes – czy kompilator powinien generować typy obiektowe. Domyślnie TRUE.<br />
genbean – czy kompilator powinien generować Java beans. Domyślnie FALSE.<br />
genTables - czy kompilator powinien generować <strong>do</strong>myślne tablice. Domyślnie TRUE.<br />
force – jeśli ten parametr jest ustawiony na TRUE, rejestracja schematu nie będzie zgłaszać błędów, ale oznaczy<br />
błędny schemat jako niepoprawny. Domyślnie FALSE.<br />
owner – określa nazwę właściciela obiektów schematu. Domyślnie jest nim użytkownik rejestrujący schemat.<br />
begin<br />
dbms_xmlschema.registerSchema(<br />
'http://www.oracle.com/xsd/Osoba.xsd',<br />
xdbURIType('/home/xsd/Osoba.xsd').getClob(),<br />
TRUE, TRUE, FALSE, TRUE);<br />
end;<br />
/<br />
Rejestracja schematu Osoba.xsd z poprzedniego przykładu<br />
Uwaga!<br />
1. Plik Osoba.xsd powinien znaj<strong>do</strong>wać się w Repozytorium w katalogu /home/xsd/.<br />
2. Procedura tworzy tabelę <strong>do</strong>myślą o nazwie ”Osoba”. Opis tabeli wyglądałby: desc "Osoba”.<br />
3.5 Dostęp <strong>do</strong> <strong>do</strong>kumentów <strong>XML</strong><br />
Temat pobierania <strong>do</strong>kumentów <strong>XML</strong> z baz danych będzie omówiony szerzej na następnym laboratorium<br />
o tematyce <strong>XML</strong>, tutaj przedstawimy zakres materiału potrzebny <strong>do</strong> wykonania tego ćwiczenia. Dwa proste<br />
sposoby obsługi <strong>do</strong>kumentów <strong>XML</strong> to:<br />
• Umieszczanie <strong>do</strong>kumentów <strong>XML</strong> w bazie danych poprzez Repozytorium,<br />
• Pobieranie <strong>do</strong>kumentów <strong>XML</strong> z bazy danych z wykorzystaniem prostych zapytań SQL/<strong>XML</strong>.
11 / 11<br />
3.5.1 Repozytorium<br />
Repozytorium Oracle <strong>XML</strong> DB jest hierarchicznym wi<strong>do</strong>kiem zasobów przechowywanych w relacyjnych<br />
strukturach. Dostęp <strong>do</strong> repozytorium możemy uzyskać poprzez standar<strong>do</strong>we protokoły: FTP na porcie 2100, HTTP<br />
na porcie 8080 i WebDAV. Podczas <strong>do</strong>stępu <strong>do</strong> Repozytorium należy zalogować się jako istniejący użytkownik<br />
bazy danych.<br />
ftp://system:oracle@localhost:2100<br />
Przykład połączenia z Repozytorium<br />
W powyższym przykładzie łączymy się z Repozytorium na komputerze lokalnym za pomocą przeglądarki Internet<br />
Explorer, jako użytkownik system o haśle oracle. Za pomocą protokołu FTP możemy tworzyć nowe podkatalogi<br />
oraz umieszczać lub kasować <strong>do</strong>wolne pliki w Repozytorium.<br />
3.5.2 SQL/<strong>XML</strong><br />
Po zarejestrowaniu schematu Osoba.xsd i umieszczeniu pliku osoba1.xml w Repozytorium, możemy<br />
zaprezentować podstawowe możliwości języka SQL/<strong>XML</strong> w Oracle 9iR2 na kilku przykładach:<br />
set long 10000<br />
set pagesize 10000<br />
select * from "Osoba";<br />
SYS_NC_ROWINFO$<br />
--------------------------------------------------------------------------------<br />
<br />
1<br />
Michal<br />
Swiderski<br />
<br />
Proste pobranie całej zawartości tabeli <strong>XML</strong>Type<br />
select value(o)<br />
from "Osoba" o<br />
where o.xmldata."ID"=1;<br />
Zapytanie traktujące <strong>XML</strong>Type jak typ obiektowy<br />
select extractValue(value(o),'/Osoba/Nazwisko') as Nazwisko<br />
from "Osoba" o<br />
where extractValue(value(o),'/Osoba/Imie') = 'Michal';<br />
Zapytanie wykorzystujące operator SQL/<strong>XML</strong> i XPath<br />
4. Przebieg ćwiczenia<br />
1. Zadanie konkretnej struktury <strong>XML</strong> Schema przez prowadzącego,<br />
2. Zapoznanie się z edytorem <strong>XML</strong> Spy,<br />
3. Tworzenie schematu,<br />
4. Kopiowanie schematu <strong>do</strong> Repozytorium,<br />
5. Rejestrowanie schematu w <strong>XML</strong> DB,<br />
6. Tworzenie, umieszczanie i wy<strong>do</strong>bywanie <strong>do</strong>kumentów <strong>XML</strong> zgodnych ze schematem.