pobierz plik referatu

Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006
Rozdział 18
w
Rola testowania w projektowaniu XML-owych baz
danych
w
1 Wstęp
da
.b
w
Streszczenie. W opracowaniu zostały przedstawione aspekty związane z projektowaniem baz danych XML. Przeprowadzono szereg testów mających
wykazać wpływ sposobu transformacji modelu konceptualnego do modelu
logicznego na wydajność przetwarzania danych. Niezależnej ocenie poddano
dwa typy systemów zarządzania bazami danych XML (Native, Enabled)
w kontekście realizacji zapytań typowych konstrukcji języka XPath. Do modelowania na poziomie logicznym został wykorzystany profil UML for
XML.
pl
s.
Na rynku baz danych dominują dwa podejścia składowania dokumentów XML. Pierwsze
z nich zakłada wykorzystanie modelu danych bazującego na drzewiastej strukturze dokumentów XML-systemy operujące na tym modelu są określane mianem XML Native. Drugie podejście zakłada mapowanie drzewiastej struktury dokumentu XML do wewnętrznego
modelu danych (np. relacyjnego lub obiektowego) – systemy wykorzystujące ten wariant to
systemy XML Enabled. Oba podejścia mają swoje wady i zalety.
Projektowanie baz danych o strukturze XML jest procesem wieloetapowym i polega na
tworzeniu modeli na różnych poziomach abstrakcji (modele konceptualny, logiczny i fizyczny) w oparciu o przyjęte reguły transformacji. Transformacja modelu logicznego do
modelu fizycznego może być zrealizowana w różny sposób, w zależności od ustalonych
kryteriów dotyczących środowiska implementacji, złożoności modelu logicznego (liczba
elementów i relacji pomiędzy nimi). W pracy zostaną przedstawione wyniki testów, które
mogą być podstawą opracowania reguł transformacji modeli logicznych do poziomu fizycznego z uwzględnieniem wymagań niefunkcjonalnych dotyczących aspektu wydajnościowego.
Zakres badań obejmował między innymi:
− Kontekst modelowania
– sposoby modelowania związków generalizacji,
– odwołania referencyjne,
– zasady transformacji atrybutów modelu logicznego w elementy lub atrybuty
modelu fizycznego XML.
Łukasz Drzewiecki, Lech Tuzinkiewicz: Politechnika Wrocławska,
Instytut Informatyki Stosowanej,
ul. Wybrzeże Wyspiańskiego 27, 50-370 Wrocław, 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
Ł. Drzewiecki, L. Tuzinkiewicz
w
− Środowiska implementacji
– Realizacja zapytań dla struktur XML zagnieżdżonych wielopoziomowo (dokumenty rozbudowane w głąb)
Testy zostały przeprowadzone w dwóch typach systemów. W grupie XML Native: eXist –
projekt „open source” oraz Xindice – projekt związany z grupą projektów Apache. Drugą
grupę stanowią systemy XML Enabled, a do eksperymentu zostały wybrane popularne systemy zarządzania bazami danych Oracle 9i (typ XMLType) oraz MS SQL Server 2005 (typ
xml). Przygotowane i przeprowadzone testy pozwoliły ocenić efektywność wybranych systemów, przy określonych wewnętrznych modelach reprezentacji danych XML oraz obsługi
typowych zapytań XPath. W testach nie uwzględniono dodatkowych mechanizmów mających wpływ na efektywność przetwarzania dokumentów XML np. indeksowanie.
w
2 Architektury systemów XML Native i XML Enabled
da
.b
w
Aby lepiej zidentyfikować mocne i słabe strony poszczególnych systemów należy bliżej
przyjrzeć się ich architekturom.
Według definicji podanej przez Ronalda Bourret’a, natywna baza danych XML to taka,
która określa logiczny model dla dokumentu XML, a następnie składuje i zwraca dokumenty zgodnie z tym modelem [4]. Najczęściej stosowane modele to XML Information Set [5],
XPath 1.0 [6], Document Object Model [7], XQuery i XPath 2.0 [8]. Każdy z tych modeli
traktuje dokument XML jako etykietowane drzewo zawierające elementy z tekstową zawartością i atrybuty z ich wartościami. Modele te różnią się jednak między sobą
w kontekście dopuszczalnych konstrukcji XML-owych. Opis tych różnic można znaleźć
w [4]. Część baz typu XML Native przewidują opcje rejestrowania schematu XML Schema
w celu walidowania dokumentu, jednak nie wpływa on z reguły na model składowania
danych. Bazy testowane w tym opracowaniu nie udostępniają takiej funkcjonalności.
Fizycznie dokumenty XML składowane są w kolekcjach, które mogą być odpowiednikiem
schematów z relacyjnych baz danych.
Alternatywnym rozwiązaniem są bazy typu XML Enabled, które zostały rozszerzone
o mechanizmy dające wsparcie dla danych w formacie XML. Systemy te umożliwiają obsługę dokumentów XML w ograniczonym zakresie. W popularnych komercyjnych systemach jak Oracle i MS SQL Server został wprowadzony typ dedykowany do struktur XML
oraz zbiór funkcji operujących na tym typie. W systemach tych dane XML mogą być przechowywane jako CLOB i wówczas przetwarzanie danych sprowadza się do parsowania dokumentu umieszczonego w bazie przy każdorazowym odwołaniu, co negatywnie wpływa
na efektywność przetwarzania. W związku z powyższym, systemy tej klasy umożliwiają
zdefiniowanie schematu XSD w celu zbudowania wewnętrznej struktury, która poprawia
efektywność przetwarzania dokumentów XML. Podczas rejestracji schematu systemy zarządzania tworzą dedykowane typy danych dziedziczące po wbudowanym typie danych
XML. Pozwala to na walidację dokumentów w trakcie ich zapisu do bazy danych. Minusem takiego rozwiązania jest konieczność każdorazowej modyfikacji schematu bazy danych przy zmianie struktur składowanych dokumentów. Rozwiązanie to ma uzasadnienie
wówczas, gdy logiczny model danych jest stabilny. Fizycznie dokument składowany jest
w komórce wiersza tabeli, której typ jest typem wygenerowanym podczas rejestracji schematu odpowiadającemu składowanemu dokumentowi.
Wydobywanie fragmentów dokumentów XML odbywa się za pomocą funkcji udostępnianych przez system, umożliwiających kierowanie zapytań języka XPath czy XQuery.
pl
s.
176
(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
Rola testowania w projektowaniu XML - owych baz danych
Funkcje te mogą być umieszczane w klauzulach SELECT lub WHERE. Więcej szczegółów
na temat przetwarzania dokumentów XML w poszczególnych systemach można znaleźć
w [10], [11].
3 Modele testowe
w
da
.b
w
w
Na podstawie analizy architektur systemów XML Native i XML Enabled można sądzić że:
− XML Native w krótszym czasie zrealizują zapytania definiowane dla dokumentów
o zagnieżdżonych strukturach. Wynika to z tego, iż relacyjne systemy w celu realizacji takich zapytań będą musiały dokonywać operacji wielu złączeń, które należą do
najbardziej kosztownych.
− XML Enabled lepiej poradzą sobie z zapytaniami wykorzystującymi odwołania referencyjne. Jest to spowodowane tym, iż jedną z podstaw systemów relacyjnych jest
obsługa odwołań referencyjnych; systemy o drzewiastym modelu danych w celu zrealizowania operacji złączenia po odwołaniu referencyjnym będą musiały wydobyć
informacje z dwóch części drzewa danych - w żaden logiczny sposób ze sobą nie
powiązanych.
− Modelowanie atrybutów z poziomu logicznego za pomocą atrybutów na poziomie fizycznym może przyspieszyć przetwarzanie w przypadku niektórych systemów XML
Native (opartych na DOM), natomiast w przypadku XML Enabled nie powinno to
mieć znaczenia. Wynika to z tego, iż w przypadku baz XML Enabled informacja
o tym czy jest to atrybut czy element jest przechowywana w formie znacznika, natomiast w przypadku baz XML Native wydobycie danych o wartości atrybutu powinien wymagać przeanalizowania jednego poziomu drzewa mniej niż w przypadku
atrybutu.
− Modelowanie związków generalizacji przy pomocy wzorca Conrete Table Inheritance powinno skutkować szybszym czasem odpowiedzi w przypadku systemów XML
Enabled, w przypadku systemów XML Native zastosowanie tego wzorca czy wzorca
Class Table Inheritance nie powinno mieć większego znaczenia. Jest to spowodowane tym, iż systemy XML Enabled w celu wydobycia danych będą musiały wykonać
dodatkową operację złączenia.
W celu sprawdzenia przedstawionych hipotez został przygotowany testowy wycinek rzeczywistości. Model konceptualny przedstawiający ten wycinek został opisany za pomocą
diagramu UML (rys.1.). Model ten został przetransformowany do modelu logicznego przy
użyciu profilu UML, pochodzącego z narzędzia Enterprise Architect [2], przeznaczonego
do modelowania struktur XML. Profil ten zawiera struktury będące odpowiednikami typowych konstrukcji języka XML Schema [9] (rys. 2.). Klasy z modelu konceptualnego są
transformowane przy wykorzystaniu następujących reguł:
− klasy z modelu konceptualnego w modelu logicznym są oznaczane stereotypem
<<XSDcomplexType>>
− aby atrybuty z poziomu logicznego były traktowane jako atrybuty XML muszą być
oznaczone stereotypem <<XSDAttribute>>
− brak oznaczenia atrybutów na poziomie logicznym stereotypem, oznacza traktowanie
ich jako elementów XML
Model konceptualny został przetransformowany do kilku modeli na poziomie logicznym
w celu zbadania wpływu modelowania elementów z modelu konceptualnego na czas realizacji zapytań wykonywanych na dokumentach opartych o poszczególne konstrukcje zdefiniowane w modelu logicznym.
pl
s.
177
(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
Ł. Drzewiecki, L. Tuzinkiewicz
w
w
Rys. 1. Model z poziomu konceptualnego opisujący testowy wycinek rzeczywistości
da
.b
w
pl
s.
Rys. 2. Diagram przedstawiający elementy profilu UML for XML
Rys. 3. Modele logiczne przedstawiające różne sposoby modelowania klasy Zagniezdzenie
z modelu konceptualnego. Po lewej klasa zamodelowana z wykorzystaniem reguł 1 i 2. Po
prawej z wykorzystaniem reguł 1 i 3. Modele te posłużą do wygenerowania schematów
XSD, które zostaną wykorzystane do porównania wydajności systemów w realizacji zapytań operujących na atrybutach i elementach XML
178
(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
Rola testowania w projektowaniu XML - owych baz danych
w
da
.b
w
w
Rys. 4. Model logiczny powstały w wyniku transformacji klas Obiekt i Odwolanie przy
wykorzystaniu reguły pierwszej. Model ten posłuży do wygenerowania schematów, które
zostaną wykorzystane do sprawdzenia wydajności systemów pod kątem zapytań wykorzystujących odwołania referencyjne
Rys. 5. Modele logiczne obrazujące różne sposoby modelowania związków generalizacji.
Po lewej stronie klasy wygenerowane przy wykorzystaniu wzorca Class Table Inheritance.
Po prawej przy wykorzystaniu wzorca Conrete Table Inheritance
4 Wyniki testów
pl
s.
Tabela 1. Zapytania wykorzystane w testach wydajnościowych, sprawdzających czas realizacji zapytań opartych o atrybuty i elementy XML. Dokumenty wykorzystane w tych testach zostały wygenerowane na podstawie schematów opartych na modelach z rys. 3.
Lp
1.
2.
3.
4.
5.
6.
7.
Treść zapytania
.
/Test/Zagniezdzenie[Napis='This is a text number one']
/Test/Zagniezdzenie[Identyfikator=1]
/Test
/Test/Zagniezdzenie[Data<'2004-01-02']
/Test/Zagniezdzenie[Identyfikator >50 and Identyfikator < 100]
/Test/Zagniezdzenie[Napis='This is a text number four']
179
(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
Ł. Drzewiecki, L. Tuzinkiewicz
Tabela 2. Tabela prezentuje wyniki testów modelowania atrybutów z modelu konceptualnego jako atrybutów w modelu fizycznym. Czasy podane są w milisekundach. Nad każdą
kolumną umieszczona jest ilość węzłów w testowanym dokumencie. Zapytania oznaczone
literką “a” to zapytania odpowiadające zapytaniom tabeli 1, ale działające na atrybutach
(np. @Napis zamiast Napis)
w
Xindice
100 1000
1
5
8
96
8
93
110 390
14
204
123 218
148 1038
50000
135
129809
136040
11023
139136
137362
49107
100
10
8
30
36
10
74
14
50000
**
**
**
**
**
**
**
10000
7
5523
5222
2969
5435
5469
9650
Oracle
1000 10000
66
18787
12
187
2231
*
152 18236
14
270
2249
*
98
3722
da
.b
w
w
Lp EXist
100
1000 10000 50000
1a. 8
5
20
8
2a. 10
24
238
1335
3a. 10
26
212
1038
4a. 7
10
10
6
5a. 10
26
219
1119
6a. 17
50
393
2096
7a. 15
93
1100
5496
MS SQL Server
Lp
100
1000 10000 50000
1a.
9
38
414
1853
2a.
4
20
189
951
3a.
1
9
66
346
4a.
10
67
740
3511
5a.
3
17
202
960
6a.
10
23
224
1193
7a.
11
85
921
4761
Tabela 3. Tabela prezentuje wyniki testów modelowania atrybutów z modelu konceptualnego jako elementów w modelu fizycznym. Czasy podane są w milisekundach. Nad każdą
kolumną umieszczona jest ilość węzłów w testowanym dokumencie(*- czas odpowiedzi
powyżej 200 sekund,** - nie udało się wprowadzić tak dużego dokumentu)
Lp
1.
2.
3.
4.
5.
6.
7.
100
5
9
7
5
11
14
14
100
32
12
7
11
5
16
25
50000
11
1305
1158
8
1213
2418
5511
100
5
13
13
149
10
164
182
50000
2236
1364
456
4038
1385
1510
5288
100
13
52
70
27
18
94
24
Xindice
1000 10000
5
3
247 5837
139 5758
618 3727
267 5928
308 5780
983 9364
Oracle
1000 10000
71 13475
10
147
2263
*
120 9153
10
254
2313
*
100 1185
50000
**
**
**
**
**
**
**
pl
s.
1.
2.
3.
4.
5.
6.
7.
Lp
EXist
1000 10000
8
7
26
238
25
193
5
6
26
201
45
401
89
1014
MS SQL Server
100 10000
32
493
12
275
7
95
11
838
5
284
16
273
25
1017
180
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2006
50000
**
**
**
**
**
**
**
Rozdział monografii: 'Bazy Danych: Struktury, Algorytmy, Metody', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2006
Rola testowania w projektowaniu XML - owych baz danych
w
Jak pokazują wyniki testów z tabel (2 i 3) nie wszystkie hipotezy dotyczące przetwarzania
XML-owych atrybutów i elementów przez testowane systemy zostały potwierdzone. Tylko
w jednym systemie typu XML Native, w Xindice, udało się zaobserwować szybsze przetwarzanie dokumentów opartych na atrybutach w stosunku do dokumentów opartych na
elementach. W przypadku systemu eXist nie można zaobserwować większych różnic. Różnice w tym aspekcie mogą być spowodowane różnicami w wewnętrznych modelach danych
odpowiedzialnych za składowanie danych XML.
W przypadku systemów typu XML Enabled, także tendencje różnią się w zależności od testowanego systemu. W przypadku systemu MS SQL Server szybciej przetwarzane były
dokumenty oparte o atrybuty. Tendencja ta może być spowodowana fizyczną wielkością
zwracanego wyniku (dokumenty oparte na atrybutach są około 30% mniejsze od dokumentów opartych na elementach). Różnice w czasie mogą więc być spowodowane dłuższym
czasem generowania wynikowego dokumentu z wewnętrznych struktur reprezentujących
dane. W przypadku systemu Oracle nie można dostrzec przewagi w wykorzystaniu w dokumencie XML atrybutów zamiast elementów.
Na podstawie prezentowanych wyników można wywnioskować iż nie we wszystkich systemach występują różnice pomiędzy stosowaniem atrybutów a elementów w dokumentach
XML, więc przy podejmowaniu decyzji w trakcie projektowania XML-owych baz danych
należy brać pod uwagę jaki będzie docelowy system odpowiedzialny za przechowywanie
dokumentów XML. Podczas wyboru pomiędzy atrybutami a elementami XML należy także wziąć pod uwagę następujące fakty: Dokumenty wykorzystujące atrybuty zajmują około
30% mniej miejsca od dokumentów z opartych na elementach, więc w przypadku dużych
rozmiarów dokumentów lub wielkiej ich ilości należało by zamodelować atrybuty z poziomu konceptualnego jako atrybuty XML-owe na poziomie fizycznym. Drugim aspektem,
który należy rozważyć jest problem czytelności dokumentów XML. Dokumenty oparte na
elementach są o wiele bardziej przejrzyste niż dokumenty oparte na atrybutach. Jeśli z dokumentami mają kontakt jedynie aplikację to oczywiście nie ma to żadnego znaczenia. Jeśli
jednak użytkownicy są zaangażowani w fizyczną ingerencję w dokument XML, obejmującą jego zmiany w jakimś narzędziu tekstowym to problem ten zyskuje na wadze. Należy
wtedy rozważyć czy ewentualne zyski w składowaniu dokumentów nie zostaną zaprzepaszczone w innym miejscu procesu wykorzystującego projektowane dokumenty.
Inne tendencje, które można zaobserwować na podstawie powyższych wyników:
a) systemy typu XML Native mają znaczną przewagę w zapytaniach zwracających całość
lub wskazane poddrzewo dokumentu XML. Niepokonany w tym aspekcie jest system
eXist, dla którego praktycznie nie ma znaczenia rozmiar dokumentu, jeśli zapytania wskazuje konkretne miejsce z dokumentu i nie posiada żadnego warunku ograniczającego wynik. Przyczyną takiego stanu rzeczy może być fakt, iż wewnętrzny model składowania
danych systemu eXist jest najbardziej zbliżony do modelu [XP 1.0]. W zapytaniach dotyczących całych dokumentów nawet system Xindice, który jest raczej tylko systemem składującym pliki z interfejsem wykorzystujący prosty model DOM, wyprzedza MS SQL Server i Oracle’a. Jest to spowodowane tym, iż systemy XML Enabled rozparcelowują dokument do wewnętrznych struktur, podczas gdy systemy XML Native trzymają dokument
w całości.
b) Biorąc pod uwagę wszystkie zapytania z tej części testów najlepszymi systemami okazały się MS SQL Server i eXist. Wszystkie systemy odpowiadały podobnie w przypadku
niewielkiej ilości węzłów w dokumencie, a różnice w czasach odpowiedzi mieściły się
w granicach błędu obliczeniowego (około 20 milisekund). Przy większych dokumentach
systemy Xindice i Oracle traciły już sporo do wcześniej wspomnianych systemów.
W przypadku Xindice pogorszenie czasu odpowiedzi dotyczy wszystkich testowych zapytań, natomiast w przypadku Oracle’a wzrost czasu odpowiedzi dotyczył głównie zapytań na
da
.b
w
w
pl
s.
181
(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
Ł. Drzewiecki, L. Tuzinkiewicz
elementach (atrybutach) przyjmujących wiele wartości („Identyfikator” był elementem
zawierającym unikatowe wartości).
Tabela 4. Zapytania wykorzystane w testach wydajności systemów w realizacji zapytań
zagnieżdżonych. Dokumenty wykorzystane w tych testach zostały wygenerowane na podstawie schematu opartego na modelu z rysunku (rys. 3)
Treść zapytania
//Zagniezdzenie[Napis='This is a text number one']";
//Zagniezdzenie[Identyfikator=5]
//Zagniezdzenie[Identyfikator >50 and Identyfikator < 100]
//Zagniezdzenie[Identyfikator >100][./Napis='This is a text number four']
w
Lp
8.
9.
10.
11.
w
Tabela 5. Wyniki testów dla zapytań z tabeli 4. Nad każdą kolumną umieszczona jest ilość
poziomów zagnieżdżeń w dokumencie XML. Wszystkie testy były przeprowadzane na
dokumencie posiadającym 1000 węzłów
1
Exist
5
10
1
Xindice
5
10
MS SQL Server
1
5
10
1
Oracle
5
30
25
30
81437
881
1233
31
35
10
35
25366
23524
23774
30
28
25
78543
651
1432
14
50
48
65
78322
751
1316
35
12
42
25226
23674
23664
42
40
25327
23794
152
121
127
93865
1793
3751
122
23815
288
1987
32206
228518
436908
da
.b
8.
9.
10.
11.
w
Lp
pl
s.
W zakresie zapytań zagnieżdżonych ponownie najlepsze wyniki osiągnęły systemy eXist
i MS SQL Server. Przy czym przy zapytaniach dotyczących elementów znajdujących się na
różnych poziomach w drzewie dokumentu XML – owego system eXist był zdecydowanie
najlepszy. Zdecydowanie najgorzej w tej kategorii zapytań zachowywał się system Oracle.
Ciekawe zachowanie można zaobserwować w przypadku systemu Xindice. W przypadku
dokumentów zawierających tylko jeden poziom system potrzebuje niemal 100 sekund na
realizację zagnieżdżonych zapytań. Fakt ten jest spowodowany, tym iż system ten dla każdej gałęzi drzewa uruchamia przetwarzanie zapytania, ponieważ jest tylko jeden poziom,
więc ilość gałęzi jest równa ilości węzłów w dokumencie. Przy dokumencie zawierającym
5 poziomów ilość gałęzi, a co za tym idzie czas realizacji, spada logarytmicznie. Przykład
ten pokazuje jak ważny może się okazać wybór modelu składowania danych w kontekście
realizacji poszczególnych zapytań.
Tabela 6. Zapytania wykorzystane w testach wydajnościowych sprawdzających czas realizacji zapytań odnoszących się do struktur XML zbudowanych na podstawie różnych wzorców modelowania związków generalizacji (Class Table Inheritance lub Conrete Table Inheritance)
Lp
Treść zapytań
12. /TestTableInheritance/Podtyp[Napis=''This is a text number one'']
13. /TestTableInheritance /Podtyp[Napis=''This is a text number one'' and Liczba2 < 50]
14. /TestTableInheritance /Podtyp
15. /TestTableInheritance/Podtyp[Liczba2 = Liczba]
182
(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
Rola testowania w projektowaniu XML - owych baz danych
W testach mających porównać modelowanie związków generalizacji za pomocą wzorca
Concrete Table Model w stosunku do wzorca Class Table Model brane były pod uwagę
tylko systemu w których wymagana jest rejestracja schematów XSD, gdyż przy systemach
nie wykorzystujących schematów do budowania struktur, w których składowane są dokumenty takie testy były by bezcelowe.
w
Tabela 7. Wyniki testów modelowania związków generalizacji za pomocą wzorca Class
Table Inheritance lub Conrete Table Inheritance(*- czas odpowiedzi powyżej 200 sekund)
Lp
Class Table
Oracle
Conrete Table
1000
10000
1000
10000
1000
10000
1000
10000
34
24
103
200
329
220
1228
1963
40
29
104
191
360
229
1273
2196
36
2729
119
113
181
*
2524
2223
13
2921
117
123
140
*
2523
2304
w
w
12.
13.
14.
15.
Ms SQL Server
Class Table
Conrete Table
da
.b
Nie potwierdziły się hipotezy dotyczące różnic w czasie realizacji zapytań dotyczących
struktur zamodelowanych za pomocą wzorców projektowych Class Table Inheritance
i Concrete Table Inheritance. Różnice w czasie odpowiedzi mieściły się w granicach błędu
obliczeniowego. Brak różnic spowodowany jest zapewne „odpornością” wewnętrznego
modelu składowania dokumentów XML na problem dziedziczenia między typami.
W systemie Oracle dane składowane są w tabelach zbudowanych na typie obiektowym
odpowiadającym typowi złożonemu ze schematu XSD. Więc nawet jeśli mapujemy klasy
z modelu konceptualnego przy pomocy wzorca Class Table Inheritance to elementy z dokumentu XML – owego fizycznie są składowane w jednej tabeli, odpowiadającej danemu
typowi – nie są rozdzielane na tabele odpowiadające obiektom biorącym udział w hierarchii
dziedziczenia – nie ma więc problemu realizacji kosztownych operacji złączeń.
Autorom nie udało się dotrzeć do reguł mapowania struktur XML do wewnętrznych
struktur w MS SQL Serverze, więc przyczyna braku różnicy w czasie realizacji poszczególnych zapytań w tym systemie nie została wyjaśniona.
pl
s.
Tabela 8. Zapytania wykorzystane w testach wydajności systemów w realizacji zapytań
wykorzystujących odwołania referencyjne. Dokumenty wykorzystane w tych testach zostały wygenerowane na podstawie schematu opartego na modelu z rys. 4.
Lp Treść zapytań
/TestReference/Obiekt[Identyfikator=/TestReference/Odwolanie[Identyfikator=1]/Ref
16. erencja]
/TestReference/Obiekt[Identyfikator != /TestReference/Odwolanie[Referencja =
17. 11]/Referencja]
/TestReference/Odwolanie[Referencja = /TestReference/Obiekt[Identyfikator =
18. 11]/Identyfikator]
19. /TestReference/Obiekt[Identyfikator = ../Odwolanie/Referencja]
183
(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
Ł. Drzewiecki, L. Tuzinkiewicz
Tabela 9. Wyniki testów wydajności systemów w realizacji zapytań wykorzystujących odwołania referencyjne(*- czas odpowiedzi powyżej 200 sekund,** - MS SQL Server nie obsługuje w „podwyrażeniach” XPath zapytań mogących zwrócić więcej niż jedną wartość)
Lp
eXist
w
16.
17.
18.
19.
Xindice
100
1000
100
15
201
13
154
39
17105
34
14625
451
388
368
7289
MS SQL Server
Oracle
1000
100
1000
100
*
*
*
12
20
13
**
70
165
79
**
6919
7169
2869
12839
*
1000
*
*
*
*
da
.b
w
w
Wyniki i ograniczone możliwości niektórych systemów w zakresie możliwych operacji
świadczą (tabela 9.), iż drzewiasta struktura dokumentu XML nie jest stworzona do przetwarzania odwołań referencyjnych – tak popularnych w systemach relacyjnych. Jedynym
systemem, którego czasy odpowiedzi nie wzrósł drastycznie w porównaniu z innymi zapytaniami. System ten ma jednak spory mankament, gdyż nie obsługuje w „podwyrażeniach”
XPath zapytań zwracających mogących zwrócić więcej niż jedną wartość, co powoduje
brak możliwości realizacji wielu operacji. W przypadku innych systemów czas operacji
wzrósł nawet o trzy rzędy wielkości, a czasy odpowiedzi dla dokumentów o tysiącu elementów przekraczające 10 sekund mogą być w wielu aplikacjach nie do zaakceptowania.
Dlatego lepiej jest modelować asocjacje z modelu konceptualnego jako agregacje na poziomie fizycznym, nawet kosztem redundancji danych.
5 Podsumowanie
pl
s.
W projektowanie baz danych XML istotne znaczenie odgrywa sposób odwzorowania modelu konceptualnego w model logiczny. Przeprowadzona analiza wpływu, różnych transformacji pomiędzy poziomem konceptualnym i logicznym oraz, na wydajność przetwarzania zapytań prowadzi do następujących wniosków:
− Sposób reprezentowania atrybutów obiektów modelu konceptualnego w modelu logicznym XML, nie ma większego wpływu na wydajność przetwarzania, ma natomiast znaczenia dla rozmiarów docelowej bazy danych XML.
− Reprezentowanie związków asocjacji z modelu konceptualnego za pomocą odwołań
referencyjnych na poziomie fizycznym wpływa niekorzystnie na wydajność przetwarzania zapytań.
− Sposób implementacji związków generalizacji z modelu konceptualnego na poziomie
fizycznym, za pomocą wzorca Class Table Inheritance lub wzorca Concrete Table
Inheritance, nie miał znaczenia dla efektywności realizacji testowanych zapytań.
Testy wydajnościowe przeprowadzone w różnych systemach zarządzania bazami danych
XML wykazały, że:
− W przypadku konieczności stosowania zapytań zagnieżdżonych odwołujących się do
różnych poziomów drzewa dokumentów lepszą platformą implementacyjną (poziom
fizyczny) są systemy XML Native.
− Bazy XML Enabled nie ustępują bazom XML Native w przetwarzaniu prostych zapytań, co może przemawiać za ich stosowaniem, gdy zachodzi konieczność integracji
danych z dokumentów XML z innymi źródłami danych.
Uzyskane wyniki prac zachęcają do podjęcia prac w zakresie wykorzystania podejścia
MDA w projektowaniu baz danych typu XML. Z przeprowadzonych testów wynika, że wybór zbioru reguł transformacji wpływa istotnie na wydajność przetwarzania i rozmiary bazy
danych. Z tego względu transformacja pomiędzy modelem konceptualnym (model PIM),
184
(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
Rola testowania w projektowaniu XML - owych baz danych
a modelem fizycznym (model PSM) może być realizowana wielowariantowo w oparciu
o charakterystyki dotyczące modelu konceptualnego (m.in. liczba i własności asocjacji,
rodzaje relacji, liczba atrybutów).
Literatura
w
1.
da
.b
w
w
David Carlson, Modeling XML Vocabularies with UML: Part I,II,III (artykuły
z http://XMLmodeling.com)
2. Enterprise Architect 5.0 – documentation – UML profile for XML
3. Ronald Bourret, XML and Datbases
4. Airi Salminen, Frank wm. Tompa, Requeirments for XML Document Database Systems
5. XML Information Set (Second Edition), W3C Recommendation 4 February 2004
6. XML Path Language(XPath),Version 1.0,W3C Recommendation 16 November 1999
7. XQuery 1.0 and XPath 2.0 Data Model (XDM), W3C Candidate Recommendation 3 November
2005
8. Document Object Model (DOM) Level 2 Core Specification Version 1.0, W3C
Recommendation 13 November
9. XML Schema Part 0: Primer Second Edition,W3C Recommendation 28 October 2004
10. Oracle Database 10 gXML & SQL, Chapter 9
11. SQL Server 2005 Books Online, Using XML in SQL Server
pl
s.
185
(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