Rola testowania w projektowaniu XML-owych baz danych

Rozdział 18 Rola testowania w projektowaniu XML-owych baz danych 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. 1 Wstęp 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:udione@wp.pl,lech.tuzinkiewicz@pwr.wroc.pl

Ł. Drzewiecki, L. Tuzinkiewicz Ś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. 2 Architektury systemów XML Native i XML Enabled 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. 176

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 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. 177

Ł. Drzewiecki, L. Tuzinkiewicz Rys. 1. Model z poziomu konceptualnego opisujący testowy wycinek rzeczywistości 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

Rola testowania w projektowaniu XML - owych baz danych 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 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 Treść zapytania 1.. 2. /Test/Zagniezdzenie[Napis='This is a text number one'] 3. /Test/Zagniezdzenie[Identyfikator=1] 4. /Test 5. /Test/Zagniezdzenie[Data<'2004-01-02'] 6. /Test/Zagniezdzenie[Identyfikator >50 and Identyfikator < 100] 7. /Test/Zagniezdzenie[Napis='This is a text number four'] 179

Ł. 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) Lp EXist Xindice 100 1000 10000 50000 100 1000 10000 50000 1a. 8 5 20 8 1 5 7 135 2a. 10 24 238 1335 8 96 5523 129809 3a. 10 26 212 1038 8 93 5222 136040 4a. 7 10 10 6 110 390 2969 11023 5a. 10 26 219 1119 14 204 5435 139136 6a. 17 50 393 2096 123 218 5469 137362 7a. 15 93 1100 5496 148 1038 9650 49107 Lp MS SQL Server Oracle 100 1000 10000 50000 100 1000 10000 50000 1a. 9 38 414 1853 10 66 18787 ** 2a. 4 20 189 951 8 12 187 ** 3a. 1 9 66 346 30 2231 * ** 4a. 10 67 740 3511 36 152 18236 ** 5a. 3 17 202 960 10 14 270 ** 6a. 10 23 224 1193 74 2249 * ** 7a. 11 85 921 4761 14 98 3722 ** 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 EXist Xindice 100 1000 10000 50000 100 1000 10000 50000 1. 5 8 7 11 5 5 3 ** 2. 9 26 238 1305 13 247 5837 ** 3. 7 25 193 1158 13 139 5758 ** 4. 5 5 6 8 149 618 3727 ** 5. 11 26 201 1213 10 267 5928 ** 6. 14 45 401 2418 164 308 5780 ** 7. 14 89 1014 5511 182 983 9364 ** Lp MS SQL Server Oracle 100 100 10000 50000 100 1000 10000 50000 1. 32 32 493 2236 13 71 13475 ** 2. 12 12 275 1364 52 10 147 ** 3. 7 7 95 456 70 2263 * ** 4. 11 11 838 4038 27 120 9153 ** 5. 5 5 284 1385 18 10 254 ** 6. 16 16 273 1510 94 2313 * ** 7. 25 25 1017 5288 24 100 1185 ** 180

Rola testowania w projektowaniu XML - owych baz danych 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 181

Ł. 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) Lp Treść zapytania 8. //Zagniezdzenie[Napis='This is a text number one']"; 9. //Zagniezdzenie[Identyfikator=5] 10. //Zagniezdzenie[Identyfikator >50 and Identyfikator < 100] 11. //Zagniezdzenie[Identyfikator >100][./Napis='This is a text number four'] 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 Lp Exist Xindice MS SQL Server Oracle 1 5 10 1 5 10 1 5 10 1 5 10 8. 30 25 30 81437 881 1233 31 35 35 25366 23524 23774 9. 30 28 25 78543 651 1432 14 12 42 25226 23674 23664 10. 50 48 65 78322 751 1316 35 42 40 25327 23794 23815 11. 152 121 127 93865 1793 3751 122 288 1987 32206 228518 436908 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

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. 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 Ms SQL Server Oracle Class Table Conrete Table Class Table Conrete Table 1000 10000 1000 10000 1000 10000 1000 10000 12. 34 329 40 360 36 181 13 140 13. 24 220 29 229 2729 * 2921 * 14. 103 1228 104 1273 119 2524 117 2523 15. 200 1963 191 2196 113 2223 123 2304 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. 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

Ł. 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 Xindice MS SQL Server Oracle 100 1000 100 1000 100 1000 100 1000 16. 15 39 451 * 12 70 6919 * 17. 201 17105 388 * 20 165 7169 * 18. 13 34 368 * 13 79 2869 * 19. 154 14625 7289 * ** ** 12839 * 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 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

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 1. 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 185