Diplomová práce Ukládání geodat do XML nativních databází

Transkript

ZÁPADOČESKÁ UNIVERZITA V PLZNI
FAKULTA APLIKOVANÝCH VĚD
KATEDRA MATEMATIKY
Diplomová práce
Ukládání geodat do XML nativních
databází
Plzeň, 2007
Zdeňka Albrechtová
Prohláš
ení
Př
edkládám tímto k posouzení a obhajobědiplomovou práci, vypracovanou na závě
r studia
na Fakultěaplikovaných vě
d Západoč
eské univerzity v Plzni.
Prohlaš
uji, ž
e jsem tuto diplomovou práci zpracovala samostatně
, pouze s použitím
pramenů, uvedených v seznamu, který je její souč
ástí.
V Plzni, dne 25. kvě
tna 2007
………………………………
Podě
kování
Na tomto místěbych chtě
la podě
kovat vš
em, kteř
í mi pomáhali a podpoř
ili př
i vypracování
této diplomové práce.
Zvláš
tědě
kuji vedoucímu diplomové práce panu Ing. et Mgr. Otakaru Čerbovi.
Klíč
ová slova
XML, nativní XML databáze, geodata, dotazovací jazyky, XPath, XQuery, SŘBD
Abstrakt
Základní myš
lenkou této práce je otestování mož
ností využ
ití nativních XML databází pro
ukládání geografických dat. Po stručném seznámení se základy XML (XML, XPath,
XQuery, XSLT, …), s nativními XML databázemi (druhy, základní charakteristiky, …)
a s XML formáty geodat (GML, cGML, …) je na vybraných tř
ech databázových
systémech (4Suite, Berkeley DB XML, eXist) za pomoci š
esti souborůs geodaty př
ímo
ukázáno, zda by bylo v geoinformatice mož
né tento druh databází využít k ř
eš
ení
konkrétních úkolů.
Key words
XML, native XML database, geodata, query languages, XPath, XQuery, DBMS
Abstract
The basic idea of my work is possibility testing to use native XML databases for saving
geographical data. After the brief acquaintance with the basics of XML (XML, Xpath,
Xquery, XSLT, ...), native XML databases (kinds, basic charackteristics, ...) and XML
formats (GML, cGML, ...) of geodata, it can be directly seen in six geodata files of three
chosen database systems (4Suite, Berkeley DB XML, eXist) whether it is possible to use
this kind of databases in geoinformatics for solutions of concrete projects.
-i-
Obsah
Abstrakt
i
Obsah
ii
Seznam zkratek
v
Seznam obrázků
viii
Seznam tabulek
x
ÚVOD
1
1
ÚVOD DO XML
2
1.1
Historie XML
3
XML dokumenty
4
1.2
1.2.1
1.2.2
1.3
Základy XML
5
1.4
Jmenné prostory
7
1.5
Jazyky pro popis dokumentů
7
1.5.1
1.5.2
1.6
1.7
DTD (Document Type Definition) .............................................................7
XML Schema ..............................................................................................8
Dotazovací jazyky
1.6.1
1.6.2
1.6.3
9
XPath ..........................................................................................................9
XQuery .....................................................................................................11
SQL/XML .................................................................................................13
Jazyky pro odkazování
1.7.1
1.7.2
2
Datověorientované XML dokumenty ........................................................4
Dokumentověorientované XML dokumenty .............................................4
14
XPointer ....................................................................................................14
XLink ........................................................................................................15
1.8
Stylové jazyky (XSLT)
15
1.9
Jazyk pro aktualizaci XML dokumentu (XUpdate)
18
XML A DATABÁZE
20
2.1
21
Obecné způ
soby ulož
ení XML dokumentů
2.1.1
2.1.2
Uložení v systému souborů.......................................................................22
Uložení v relač
ní databázi ........................................................................22
- ii -
2.1.3
2.1.4
2.2
Ukládání dokumentověorientovaných XML dokumentů
2.2.1
2.2.2
Ukládání datověorientovaných XML dokumentů
24
2.4
Mapovací metody
25
Generické mapování .................................................................................25
Schématem ř
ízené mapování ....................................................................27
Mapování definované už
ivatelem .............................................................28
NATIVNÍ XML DATABÁZE
30
3.1
31
Architektura
3.1.1
3.1.2
3.2
3.3
Textové nativní XML databáze ................................................................31
Modelové nativní XML databáze .............................................................32
Základní charakteristiky XML nativních databází
3.2.1
3.2.2
3.2.3
3.2.4
3.2.5
3.2.6
3.2.7
32
Kolekce dokumentů..................................................................................32
Dotazování a aktualizace ..........................................................................32
Transakce, zamykání a víceuživatelský př
ístup........................................33
Aplikač
ní programové rozhraní (API) ......................................................33
Round tripping ..........................................................................................33
Indexování ................................................................................................34
Normalizace a referenč
ní integrita............................................................34
Nekomerč
ní XML nativní databáze
3.3.1
3.3.2
3.3.3
3.3.4
3.3.5
3.3.6
3.3.7
3.3.8
3.3.9
4
23
Ukládání v systému souborů.....................................................................23
Ukládání v BLOB .....................................................................................24
2.3
2.4.1
2.4.2
2.4.3
3
Uložení v objektové databázi....................................................................22
Uložení v objektověrelační databázi........................................................23
35
DBDOM ...................................................................................................36
dbXML .....................................................................................................36
myXMLDB ...............................................................................................38
Ozone ........................................................................................................38
Sedna XML DBMS ..................................................................................39
Timber.......................................................................................................41
XDBM ......................................................................................................43
Xindice......................................................................................................43
XpSQL ......................................................................................................44
GEODATA A XML
46
4.1
Geography Markup Language (GML)
46
4.2
compact Geographical Markup Language (cGML)
47
4.3
Geospatial-eXtensible Markup Language (G-XML)
49
4.4
LandXML
50
- iii -
5
UKLÁDÁNÍ GEODAT DO XML NATIVNÍCH DATABÁZÍ
52
5.1
54
XQuery a XPath dotazy pro vybrané databáze
5.1.1
5.1.2
5.1.3
5.1.4
5.2
4Suite … objektově
-orientovaná databáze
5.2.1
5.2.2
5.2.3
5.3
5.5
98
Obecné poznatky a závě
ry o databázi 4Suite ...........................................98
ry o databázi Berkeley DB XML .......................99
ry o databázi eXist .............................................99
Výsledky dotazování ..............................................................................100
ZÁVĚR
106
Seznam použ
ité literatury a zdrojů
1.
2.
89
Instalace ....................................................................................................91
Pracovní prostř
edí a základní funkce ........................................................91
Geodata a eXist .........................................................................................95
Zhodnocení použ
itých databází
5.5.1
5.5.2
5.5.3
5.5.4
75
Instalace ....................................................................................................76
Pracovní prostř
edí a základní funkce........................................................77
Geodata a Berkeley DB XML ..................................................................80
eXist … databáze s vlastním modelem
5.4.1
5.4.2
5.4.3
64
Instalace ....................................................................................................65
Pracovní prostř
edí a základní funkce........................................................66
Geodata a 4Suite .......................................................................................71
Berkeley DB XML … databáze typu klíč
-hodnota
5.3.1
5.3.2
5.3.3
5.4
Atributové XQuery dotazy .......................................................................54
Prostorové XQuery dotazy .......................................................................59
Atributové XPath dotazy ..........................................................................62
Prostorové XPath dotazy ..........................................................................64
107
Použ
itá literatura ..............................................................................................107
Internetové odkazy ...........................................................................................107
Př
íloha A … Konfigurační soubor „4ss.conf“
111
Př
íloha B … Struktura př
ilož
eného CD
112
- iv -
Seznam zkratek
ACID – Atomic, Consistent, Isolated, Durale – seznam pož
adavkůna bezpeč
ný transakční
systém.
ANSI – American National Standards Institute – americká standardizač
ní organizace.
API – Application Programmers Interface – rozhraní pro programování aplikací.
BLOB – Binary Large Object – datový typ užívaný v databázích nejč
astě
ji pro ukládání
audia, videa, obrázků.
BSD – Berkeley Software Distribution – operač
ní systém vycházející z UNIXu.
CLOB – Charakter Large Object – datový typ už
ívaný v databázích nejč
astě
ji pro ukládání
textu.
CORBA – Common Object Request Brooker Archive – prostř
edí pro tvorbu objektově
orientovaných aplikací; jazykověnezávislý objektový model.
DBMS – DataBase Management System – Systém ř
ízení báze dat (SŘBD).
DOM – Dokument Object Model – objektový model dokumentu.
DTD – Dokument Type Definition – jazyk pro popis dokumentu.
FTP – File Transfer Protocol – protokol pro př
enos souborů.
GCA – Graphic Communications Association – Asociace grafické komunikace.
GIS – Geographic Information System – geografický informač
ní systém.
GNU GPL – GNU General Public Licence – licence pro volnědostupný software.
GUI – Graphical User Interface – grafické uživatelské rozhraní.
HTTP – Hyper-Text Transfer Protocol - hypertextový př
enosový protokol.
IBM – International Business Machines Corporation – př
ední svě
tová společ
nost v oboru
informač
ních technologií.
InfoSet – XML Information Set – základní datový model XML dokumentu.
IPA – Information-technology Promotion Agency – japonská společ
nost zabývající se
informač
ními technologiemi.
ITER – malá mezinárodní skupina vývojář
ůzabývajících se XML databázemi.
JDBC – Java DataBase Connectivity – SQL rozhraní pro Javu.
JDK – Java Developer Kit – soubor programůpro vývoj aplikací v Javě
.
Mac OS – Macintosh Operating System – je označení operač
ního systému pro poč
ítače
Macintosh firmy Apple.
MODIS – Management Of Data & Information Systems – výzkumný a vývojový tým
Institutu systémového programování ruské Akademie vě
d.
-v-
MS – Microsoft – softwarová firma.
ODBC – Open DataBase Connectivity – API pro př
ístup k databázovým systémům.
ODMG – Object Data Management Group – standard pro objektověorientované
databázové systémy.
OGC – OpenGis Consorcium – mezinárodní neziskové konsorcium v oblasti GIS.
OQL – Object Query Language – dotazovací jazyk.
PHP – PHP: Hypertext Preprocessor – skriptovací programovací jazyk.
PLT – skupina lidí, která vytvář
í PLT Scheme, jenžobsahuje různé implementace
programovacího jazyka Scheme.
POSIX – Portable Operating System Interface – př
enositelné rozhraní pro operační
systémy, standardizované jako IEEE 1003 a ISO/IEC 9945. Vychází ze systémů
UNIX.
PSVI – Post-Schema Validation Infoset – datový model XML.
RAM – Random Access Memory – pamě
ťs náhodným př
ístupem.
RDBMS – Relational DataBase Management System – SŘBD pro relač
ní databáze.
RDF – Resource Description Framework – obecný mechanismus pro zápis metadat.
RELAX NG – REgular LAnguage for XML Next Generation –
jazyk pro popis
dokumentu.
RPC – Remote Procedure Calling – vzdálené volání procedur.
SAX – Simple API for XML – jednoduché API pro XML.
SDK – Software Development Kit – soubor vývojových nástrojů.
SGML – Standard Generalized Markup Language – značkovací jazyk.
SOAP – Simple Object Access Protocol – protokol používaný pro komunikací (použ
ívání
XML zpráv).
SQL – Structured Query Language – dotazovací jazyk relač
ních databází.
TAX – A Tree Algebra for XML – algebra pracující se stromy XML.
UNIX – Unary Information and Computing Service – operač
ní systém.
URI – Uniform Resource Identifier – jedinečná identifikace zdroje.
W3C – World Wide Web Consorcium – konsorcium pro vývoj webových standardů.
WebDAV – Web-based Distributed Authoring and Versioning – protokol pro vzdálený
př
ístup.
WFS – Web Feature Service – definuje rozhraní mezi mapou a klientem.
X2QL – eXtensible XML Query Language – dotazovací jazyk pro XML.
- vi -
XInclude – XML Inclusions – XML jazyk, který umožňuje vkládat XML dokumenty (nebo
č
ásti) do XML dokumentů.
XLink – XML Linking Language – odkazovací jazyk pro XML.
XML – eXtensible Markup Languague – znač
kovací jazyk.
XPath – XML Path Language – jazyk pro identifikaci č
ástí XML dokumentu.
XPointer – XML Pointer Language – odkazovací jazyk pro XML.
XQL – XML Query Language – dotazovací jazyk pro XML.
XQuery – XML Query – dotazovací jazyk pro XML.
XSLT – eXtensible Stylesheet Language Transformations – transformační stylový jazyk
pro XML.
XUpdate – XML Update Language – jazyk pro aktualizaci XML dokumentu.
ZABAGED – Základní báze geografických dat - digitální geografický model území České
republiky.
- vii -
Seznam obrázků
Obrázek 1.1: Vztahy mezi uzly ve stromové reprezentaci XML dokumentu (př
evzato z [24]) ........ 9
Obrázek 1.2: Ukázka stromové struktury XML dokumentu ............................................................ 10
Obrázek 1.3: Formátování XML dokumentu (př
evzato z [11])....................................................... 16
Obrázek 1.4: Výsledek XSLT transformace .................................................................................... 18
Obrázek 3.1: Architektura – Sedna XML DBMS (př
evzato z [28]) ................................................ 40
Obrázek 3.2: Architektura – Timber (př
evzato z [46]) .................................................................... 41
Obrázek 4.1: Architektura cGML – Klient/Server (př
evzato z [13])............................................... 49
Obrázek 4.2: Struktura G-XML verze 1.0 (př
evzato z [20])............................................................ 50
Obrázek 5.1: 4Suite – pracovní prostř
edí Python GUI .................................................................... 67
Obrázek 5.2: 4Suite – GUI na URL: http://localhost:8800/ ............................................................. 69
Obrázek 5.3: 4Suite – XPath dotazy ................................................................................................ 70
Obrázek 5.4: 4Suite – kolekce dokumentů....................................................................................... 72
Obrázek 5.5: Architektura – Berkeley DB XML (př
evzato z [31]) ................................................. 75
Obrázek 5.6: Berkeley DB XML – pracovní prostř
edí .................................................................... 77
Obrázek 5.7: Berkeley DB XML – nápově
da .................................................................................. 78
Obrázek 5.8: Architektura – eXist (př
evzato z [4]).......................................................................... 89
Obrázek 5.9: eXist – webové rozhraní............................................................................................. 91
Obrázek 5.10: eXist – př
ipojení k databázi ...................................................................................... 92
Obrázek 5.11: eXist – Java rozhraní ................................................................................................ 92
Obrázek 5.12: eXist – dotazovací dialog.......................................................................................... 94
Obrázek 5.13: eXist – chyba př
i ukládání souboru .......................................................................... 95
Obrázek 5.14: eXist – kolekce dokumentů...................................................................................... 96
Obrázek 5.15: eXist – ukázka vyhodnocení dotazu ........................................................................ 97
Obrázek 5.16: Grafické znázorně
ní č
asu vyhodnocení atributových XQuery dotazůjednotlivých
databází.................................................................................................................... 101
ní č
asu vyhodnocení prostorových XQuery dotazůjednotlivých
databází.................................................................................................................... 101
ní č
asu vyhodnocení XQuery dotazůdabáze Berkeley DB XML –
seř
azeno vzestupně.................................................................................................. 102
ní č
asu vyhodnocení XQuery dotazůdatabáze eXist – seř
azeno
vzestupně................................................................................................................. 102
ní č
asu vyhodnocení XPath dotazův jednotlivých databázových
systémech ................................................................................................................ 103
- viii -
ní č
asu vyhodnocení XPath dotazůdatabáze 4Suite – seř
azeno
vzestupně................................................................................................................. 103
ní č
asu XPath dotazůdatabáze Berkeley DB XML – seř
azeno
vzestupně................................................................................................................. 104
ní č
asu XPath dotazůdatabáze eXist – seř
azeno vzestupně...... 104
- ix -
Seznam tabulek
Tabulka 1.1: Př
íklad SQL/XML – relace Studenti(jmeno,prijmeni,pohlavi,typ_studia) ................. 14
Tabulka 2.1: Výsledná tabulka po generickém tabulkovém mapování - př
íklad............................. 25
Tabulka 3.1: Komerč
ní nativní XML databáze................................................................................ 31
Tabulka 3.2: Nekomerč
ní nativní XML databáze............................................................................ 35
Tabulka 4.1: Srovnání GML a cGML tagů...................................................................................... 48
Tabulka 5.1: Velikosti použ
itých souborůs geodaty ....................................................................... 53
Tabulka 5.2: Výsledné č
asy vyhodnocení XQuery dotazův sekundách........................................ 100
asy vyhodnocení XPath dotazův sekundách .......................................... 103
Tabulka 5.4: Sumarizace č
asůjednotlivých databází po vyhodnocení vš
ech dotazů.................... 105
-x -
ÚVOD
V souč
asné doběse v oblasti geografických vě
d stále více uplatňují různé formáty
značkovacího jazyka XML (např
. GML, G-XML), a to př
edevš
ím z důvodu jejich
nenároč
nosti na software. S rostoucím využ
itím tě
chto formátůse dá př
edpokládat, ž
e data
ulož
ená tímto způsobem musí být ně
kde uskladně
na a spravována.
Jako i v jiných oblastech i zde se nabízí využ
ití databázových systémů. Pro ukládání
a spravování XML dat existuje speciální druh databázových systémů. Jedná se o nativní
XML databáze, jejichžhlavní př
edností je př
ímé (nativní) ukládání XML dokumentů. Zda
by bylo možné tě
chto databází využ
ít také v oblasti geově
d, se pokusím v této práci
objasnit.
Vlastní obsah práce je rozdě
len do dvou základních č
ástí.
V první č
ásti (jedná se
o kapitoly 1, 2, 3 a 4) se může čtenářseznámit s problematikou znač
kovacího jazyka XML
a s jeho technologiemi, se vztahem XML jazyka k databázím, s vlastními nativními XML
databázemi a v neposlední ř
adětaké s různými XML formáty geografických dat.
Druhá část, př
ibliž
něo stejném rozsahu, se jižzabývá konkrétními nativními XML
databázovými systémy (4Suite, Berkeley DB XML, eXist) a jejich mož
nostmi př
i správě
náhodněvybraných XML souborůs geodaty. Mimo struč
ného popisu základních funkcí
jednotlivých databází a ukázek správy dat, je vztah těchto databází ke geodatům ukázán
př
edevš
ím na testování atributových a prostorových dotazů, které jsou pro tato data
typické.
-1-
1 ÚVOD DO XML
XML, neboli rozš
iř
itelný znač
kovací 1 jazyk (eXtensible Markup Language), byl vyvinut
konsorciem W3C. Pro pochopení úč
elu tohoto jazyka se zamě
ř
ím na jeho název, protože
právěten vystihuje vš
e podstatné, co od XML můžeme oč
ekávat.
Co je myš
leno pod pojmem rozš
iř
itelný (eXtensible)? Jazyk XML je vysoce flexibilní a je
tedy schopen př
izpůsobit se jakémukoli úč
elu využ
ití, např
. v knihovnictví, matematice,
hudbě
, právěpomocí znač
kovacího jazyka (Markup Language). Základním principem
značkovacího jazyka je označ
ování dat pro č
lověka srozumitelnými znač
kami. Daty jsou
myš
leny textové ř
etězce a znač
kami textové značky, které tato data popisují, např
.
<student>, <jmeno>, <prijmeni>. XML se tak tedy stává ideálním formátem
k ukládání strukturovaného a semi-strukturovaného2 textu určeného pro š
íř
ení a publikaci
na celé ř
aděmédií. Popis struktury dokumentu zaruč
uje právěznač
kování, které ale již
neř
íká nic o tom, jak má být ve výsledku dokument zobrazen. K tomuto určení se využívají
stylové jazyky.
Z flexibility tohoto jazyka je zř
ejmé, ž
e neexistuje ž
ádná koneč
ná množ
ina
př
eddefinovaných znač
ek, což v ně
kterých př
ípadech může vést i k problémům či
nepř
ehlednosti. Tomu se dá př
edejít využ
itím jazykůpro popis dokumentů, které urč
ují,
kdy a jak mohou být jednotlivé znač
ky v dokumentu použ
ity. Se schématem se pak
konkrétní dokumenty porovnávají. Vyhovují-li, označ
ujeme je jako platné (validní),
v opač
ném př
ípadě jako neplatné. Platnost a neplatnost souvisí pouze s urč
itým
schématem, a proto některé neplatné dokumenty mohou být i př
es svoji neplatnost vůči
konkrétnímu schématu formálněsprávné. Využití schématu je ryze dobrovolné. Více
informací o schématech dokumentů je uvedeno v kapitole 1.5 (Jazyky pro popis
dokumentů).
XML obsahuje mimo základní syntaktické specifikace dalš
í doplňkové standardy č
i
pracovní verze týkající se dotazování (kapitola 1.6), odkazů(kapitola 1.7), výstupního
formátování (kapitola 1.8), kódování matematických vzorců, chemických vzorců…
1
2
Norma ČSN EN 28879 př
ekládá slovo „markup“ jako „vyznač
ovací“.
Data mají nepravidelnou strukturu a požadují uspoř
ádání elementů.
-2-
Zdroje vztahující se k celé kapitole 1: [1], [3], [5], [23], [24], [33], [36], [40]
1.1 Historie XML
Jazyk XML rozhodněnení prvním značkovacím jazykem. Jižv 60. letech minulého století
se objevila nutnost popisu textu podle jeho významu, nikoli podle výsledného vzhledu.
V té doběexistovaly dva mož
né způsoby formátování textu, a to tzv. specifické kódování,
které mimo písmen, č
íslic a interpunkce obsahovalo speciální znaky urč
ené pro
formátování, a tzv. generické kódování, ve kterém se poprvé objevily pro popis vzhledu
značky (tagy). U zrodu myš
lenky generického kódování stáli nezávisle na sobědva muži,
William Tunnicliffe z GCA, který v zář
í roku 1967 zavedl myš
lenku rozdě
lení
informač
ního obsahu od vlastního vzhledu dokumentu, a newyorský grafik Stanley Rice,
který publikoval svojí ideu textové struktury tagů. Smysl tě
mto dvěma myš
lenkám dal
ř
editel GCA Herman Scharpf prostř
ednictvím výboru zabývajícím se př
ímo generickým
kódováním, jehožvýsledkem bylo vytvoř
ení konceptu GenCode. Dva základní poznatky
z vývoje tohoto konceptu, a to: „pro různé druhy dokumentůje zapotř
ebí různých druhů
kódů“, „menš
í dokumenty by mohly být jako elementy zač
leně
ny do vě
tš
ích“, byly využ
ity
v následujících letech (př
edevš
ím v SGML).
V roce 1969 se americký vě
dec (původněprávník) Charles Goldfarb úč
astnil výzkumného
projektu na integrovaných informač
ních systémech v oblasti práv, v němžse mu spolu
s Edwardem Mosherem a Raymondem Loriem podař
ilo vyvinout jazyk GML1
(Generalized Markup Language). Také GML vycházel z myš
lenek Tunnicliffa a Rice.
Jednalo se o první jazyk, který formálně definoval typ dokumentu se stanovenou
strukturou elementů(Dnes je často označován jako první známý znač
kovací jazyk.). Po
dokonč
ení GML pokrač
oval Goldfarb ve výzkumu, jeho dalš
í návrhy vš
ak byly zač
leně
ny
aždo jazyka SGML (Standard Generalized Markup Language).
Po úspěchu jazyka GML zač
ala v roce 1978 americká standardizač
ní společnost ANSI
pracovat na vývoji nového obecného značkovacího jazyka (SGML), který by umož
ňoval
už
ivatelům definovat si vlastní znač
kovací jazyk. Př
i vývoji se vycházelo př
edevš
ím z již
známého GML a také z GenCode. Ke koneč
nému výsledku se dospělo ažv ř
íjnu roku
Často se uvádí, že zkratka GML vychází z počáteč
ních písmen př
íjmení jednotlivých autorůtohoto jazyka
(Goldfarb, Mosher, Lorie).
1
-3-
1985, kdy byla zveř
ejněna poslední pracovní verze SGML a v následujícím roce, po
zapracování vš
ech př
ipomínek, byl vydán koneč
ný standard SGML jako ISO 8879:1986.
Jazyk SGML byl vš
ak př
ílišobecný, a tak k průlomu ve znač
kovacích jazycích doš
lo ažpř
i
vyvinutí jazyka HTML ze SGML pomocí DTD. Jazyk HTML má tedy pouze omezenou
množ
inu znač
ek určenou jen k popisu webových stránek, cožpro jiné oblasti samozř
ejmě
nebylo dostač
ující. Proto v roce 1996 zač
ala práce na „jednoduš
š
í“ verzi SGML. Tato
verze si ponechala větš
inu vlastností SGML, ale vynechala vě
ci, které se v př
edchozích
letech jevily jako př
íliškomplikované a nadbyteč
né (např
. volba délky znač
ky, volba
oddě
lovač
e znač
ek). Výsledkem byla 10. února 1998 první verze jazyka XML 1.0.
V souč
asné doběexistuje jižč
tvrté vydání XML verze 1.0 vydané 29. zář
í 2006 (př
edchozí
vydání: 6. ledna 2000, 4. února 2004).
Souběž
něs tř
etí edicí XML 1.0 vydalo konsorcium W3C doporuč
ení XML 1.1, jehož
druhé vydání vyš
lo opě
t spolu se čtvrtým vydáním XML 1.0.
1.2 XML dokumenty
Do XML dokumentůlze ukládat data různého původu. V praxi se data ukládaná do XML
rozdě
lují na dokumentověorientovaná (dokument-centric) a datověorientovaná (datacentric). V závislosti na ulož
ených datech se pak vyskytují i dva druhy XML dokumentů.
1.2.1
Datověorientované XML dokumenty
Datověorientované XML dokumenty slouží př
edevš
ím pro př
enos dat. Větš
inou jsou
urč
eny pro využití v jiných programech, zpracování lidmi se př
ílišnepř
edpokládá. Př
íklady
takovýchto dokumentů: objednávky, faktury, jízdní ř
ády, vě
decká data (např
. záznamy
mě
ř
ení), …
Charakteristickým znakem tě
chto dokumentůje pravidelná struktura, co nejmenš
í logické
jednotky dat v elementech a atributech a malý nebo ž
ádný výskyt smíš
eného obsahu.
1.2.2
Dokumentověorientované XML dokumenty
Dokumentověorientované XML dokumenty jsou dokumenty obvykle využ
ívané pro
lidskou potř
ebu. Velmi dobrým př
íkladem jsou knihy.
-4-
Vyznač
ují se méněpravidelnou, č
asto ažnepravidelnou, strukturou, hrubým č
leně
ním dat
a velkým výskytem smíš
eného obsahu. Nejčastě
ji jsou tyto dokumenty psány ruč
něpř
ímo
v XML nebo v jiných formátech, jako např
. RTF, PDF, …, které jsou následnědo XML
př
evedeny.
1.3 Základy XML
Existují dva druhy znač
ek, a to poč
áteční značka <student> a koncová značka
</student>. Poč
áteční a k ní odpovídající koncová znač
ka tvoř
í spolu s textem uvnitř
tě
chto značek element. Jednotlivé elementy se mohou do sebe vnoř
ovat. Pokud element
neobsahuje mezi značkami žádný text ani dalš
í elementy, jedná se o tzv. prázdný element
a je mož
né ho zapsat jako <student/> . Elementy v XML dokumentu musí splňovat
ně
kolik pravidel:
 Kaž
dá poč
áteč
ní znač
ka musí mít koncovou znač
ku.
 Elementy se nesmě
jí kř
ížit.
 Musí existovat právějeden koř
enový element (např
. <studenti></studenti>
viz níž
e).
<studenti>
<student>
<jmeno>Pavel</jmeno>
<prijmeni>Nový</prijmeni>
</student>
<student/>
</studenti>
V počáteč
ní znač
ce elementu se můž
e vyskytovat libovolný poč
et atributů, tj. prvků, které
upř
esňují význam elementu. Atribut je tvoř
en názvem a hodnotou, která musí být uzavř
ena
v uvozovkách č
i apostrofech. Element nesmí obsahovat dva atributy stejného názvu.
<student pohlavi=“muž“ typ_studia=“prezenční“>
Názvy prvkův XML dokumentu mohou obsahovat libovolné alfanumerické znaky, vč
etně
tř
ech interpunkč
ních, tj. podtrž
ítko, pomlčka a teč
ka, př
ičemžnesmí zač
ínat č
íslicí, teč
kou
č
i pomlčkou. Dalš
í použ
ití interpunkč
ních znaků, jako uvozovka, apostrof, $, ^, % nebo
stř
edník, je zakázáno. Délka názvu můž
e být libovolná, ale je nutné dbát na dodrž
ování
malých a velkých písmen.
-5-
Pokud XML dokument neodporuje výš
e uvedeným zásadám, lze jej vyjádř
it stromovou
strukturou, kde koř
enový element je hlavním uzlem stromu a jeho podelementy tvoř
í dílčí
uzly tohoto stromu.
Pro př
ípad nutnosti jakýchkoli poznámek umož
ňuje standard XML vytvář
ení komentář
ů.
Komentářzač
íná znaky  .

Pokud by námi vytvář
ený dokument mě
l obsahovat např
íklad č
ást kódu jiného
značkovacího jazyka, jistěvyuž
ijeme sekci CDATA. Vš
e, co se nachází mezi znač
kou
<![CDATA[ a znač
kou ]]>, se považuje za holý znakový text.
<![CDATA[
Připojení stylu k dokumentu:
<?xml version="1.0" encoding=”windows-1250”?>
<?xml-stylesheet href="mujstyl.xsl" type=”text/xsl”?>
<dokument>
.
.
</dokument>
]]>
V př
ípaděizolovaných znaků, které mají př
i znač
kování speciální význam (<, >, &, "
a '), lze využít př
eddefinovaných entit, např
. < , >, & (<, >, &).
Kdekoli v dokumentu (mimo znač
ky) se mohou vyskytovat instrukce pro zpracování
(procesní instrukce), které obsahují informace požadované konkrétní aplikací, která bude
data XML zpracovávat. Často se využívají pro určení souboru stylů, který dokument
formátuje.
<?xml-stylesheet href=“mujstyl.xsl“ type=“text/xsl“?>
Nepsaným pravidlem př
i vytvář
ení XML dokumentůje uvedení deklarace XML. Deklarace
XML vypadá jako procesní instrukce s názvem xml, která obsahuje atributy version
(povinný – verze XML – např
. „1.0“), standalone (volitelný – používání externích
souborů– „yes“, „no“) a encoding (volitelný1 – kódování – např
. „ISO-8859-2“).
<?xml version=“1.0“ encoding=“windows-1250“?>
1
„Volitelný“ je v tomto př
ípaděrelativní pojem, pokud dokument nepíš
eme v UTF-8 (popř
. v UTF-16)
musíme kódování v deklaraci uvést. Pokud totižtento parametr neuvedeme, bude se př
edpokládat kódování
„UTF-8“.
-6-
1.4 Jmenné prostory
Standard XML Namespaces (XML jmenné prostory) vznikl za účelem rozliš
ení elementů
a atributůse stejným názvem pocházejících z různých aplikací XML, a také pro snazš
í
rozpoznání souvisejících elementůa atributů.
Vlastní implementace spoč
ívá pouze v doplně
ní př
ísluš
ného prefixu př
ed název elementu
č
i atributu a v definování jmenného prostoru.
<... xmlns:prefix = „URI“>
.
.
.
<prefix:nazev_elementu>
...
<xsl:stylesheet xmlns:xsl='http://www.w3.org/1999/XSL/Transform'
version='1.0'>
<xsl:output ...>
1.5 Jazyky pro popis dokumentů
Jazyky pro popis dokumentů(schémové jazyky) definují, jaké elementy a atributy můž
eme
v XML dokumentu použ
ít, co př
esněmohou obsahovat a jak s nimi můž
eme nakládat.
Schématem si vlastněkaž
dý vytvář
í svůj vlastní XML jazyk, protože v něm nadefinuje své
vlastní značky pro svůj vlastní úč
el.
Kontrolu platnosti XML dokumentůprovádí tzv. validátory XML dat nebo také XML
procesory.
V souč
asné doběpatř
í mezi nejznámějš
í schémové jazyky DTD (kapitola 1.5.1), XML
Schema (kapitola 1.5.2), Relax NG č
i Schematron.
1.5.1
DTD (Document Type Definition)
Schémový jazyk DTD je mimo vlastní specifikace obsaž
en i ve specifikaci XML. Pochází
př
ímo z jazyka SGML a stal se výchozím jazykem pro nově
jš
í schémové jazyky. Je velmi
jednoduchý, proto se stále tě
š
í velké oblibě
. Pro složitě
jš
í aplikace č
i pro př
esnějš
í definici
struktury XML dokumentu je vš
ak jižnepostač
ující – nepodporuje jmenné prostory ani
datové typy.
-7-
<!ELEMENT studenti (student)+>
<!ELEMENT student ((jmeno,prijmeni)|(prijmeni,jmeno))>
<!ATTLIST student pohlavi (muž|žena)#REQUIRED>
<!ATTLIST student typ_studia CDATA #IMPLIED>
<!ELEMENT krestni (#PCDATA)>
<!ELEMENT prijmeni (#PCDATA)>
1.5.2
XML Schema
XML Schema je dalš
í specifikací konsorcia W3C, vyvinul se z XML-Data a XDR (XML
Data-Reduced). Je to druhý nejpoužívaně
jš
í schémový jazyk (hned po DTD).
Protož
e XML Schema vychází př
ímo z jazyka XML může využ
ívat vš
ech nástrojů
vytvoř
ených pro práci s XML dokumenty. Oproti jazyku DTD podporuje jmenné prostory
(samotné schéma využívá vlastních elementů, proto musí být jmenných prostorůvyuž
ito
př
ímo ve schématu), a také datové typy (např
. string, boolean, date), př
ič
emžumožňuje
i vlastní už
ivatelsky definované datové typy. K dalš
ím výhodám tohoto jazyka patř
í
využívání objektově
-orientovaných rysů, definice elementůmnoha různými způsoby,
apod.
<xs:schema xmlns:xs=“http://www.w3.org/2001/XMLSchema“>
<xs:element name=“studenti“>
<xs:complexType>
<xs:sequence>
<xs:element name=“student“ maxOccurs=“unbounded“>
<xs:complexType>
<xs:all>
<xs:element name="jmeno" type="xs:string"/>
<xs:element name="prijmeni" type="xs:string"/>
</xs:all>
<xs:attribute name=“pohlavi“ use=“required“>
<xs:simpleType>
<xs:restriction base=“xs:string“>
<xs:enumeration value=“muž“/>
<xs:enumeration value=“žena/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name=“typ_studia“ type=“xs:string“/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
-8-
1.6 Dotazovací jazyky
Základním principem tě
chto jazykůje získávání č
ástí XML dokumentůza urč
itých
podmínek, které pak mohou být využ
ívány i dále, např
íklad se mohou tyto části podílet na
vzniku nových dokumentů.
Od vzniku XML 1.0 se objevilo velké množ
ství různěpropracovaných dotazovacích
jazyků, např
. XML-QL (XML Query Language), XQL, X2QL, XPath (kapitola 1.6.1),
XQuery (kapitola 1.6.2).
1.6.1
XPath
Jazyk XML Path Language (XPath) umož
ňuje adresování k jednotlivým částem
dokumentu, a kromětoho poskytuje ně
kolik základních funkcí pro práci s ř
etězci, čísly,
apod. Jedná se také o standard W3C konsorcia, v současné doběve verzi 1.0 a nověi 2.0.
S jazykem XML toho př
ílišspolečného nemá, jeho notace je úplněodliš
ná, ale i př
esto je
tento jazyk hojněvyužíván v jiných XML jazycích (XPointer, XQuery, XSLT).
Datovým modelem XPath je strom, který obsahuje 7 typůuzlů: koř
enový uzel, element,
atribut, text, komentář
, procesní instrukce, jmenný prostor. Koř
enový uzel není totož
ný
s uzlem koř
enového elementu. Mezi uzly můžeme procházet po tzv. osách (obrázek 1.1),
cožjsou relace, které umožňují velikou variabilitu výrazůjazyka XPath.
Obrázek 1.1: Vztahy mezi uzly ve stromové reprezentaci XML dokumentu (převzato z [24])
-9-
Výsledkem vyhodnocení XPath výrazu můž
e být množ
ina uzlů, č
íslo, ř
etě
zec nebo
booleovská hodnota.
Obrázek 1.2: Ukázka stromové struktury XML dokumentu
Na obrázku 1.2 je znázorně
na stromová struktura XML dokumentu ukázkového př
íkladu,
pro snazš
í pochopení ně
kterých př
íkazůuvedených níž
e.
/studenti/student - výběr všech elementů student, které jsou dětmi
elementu studenti, který je kořenovým elementem
dokumentu
/studenti/student[1] - výběr prvního elementu student, který je
dítětem elementu studenti, který je kořenovým
elementem dokumentu
student/@pohlavi - výběr atributu pohlavi elementu student, který
je dítětem aktuálního uzlu
//student[@pohlavi=’žena’]/jmeno - výběr všech elementů jmeno,
které jsou dětmi elementu student s atributem
pohlavi=“žena“
. - výběr aktuálního uzlu
* - výběr všech elementů, které jsou dětmi aktuálního uzlu
.. - výběr rodiče aktuálního uzlu
@* - výběr všech atributů aktuálního uzlu
//jmeno - výběr všech elementů jmeno
./prijmeni - výběr všech elementů prijmeni, které jsou dětmi
aktuálního uzlu
*/prijmeni - výběr všech elementů prijmeni, které jsou vnoučaty
aktuálního uzlu
self::prijmeni - výběr aktuálního uzlu, pokud je to element se
jmenem prijmeni
preceding::*[1] - výběr posledního elementu, který se nachází před
aktuálním uzlem
preceding-sibling::*[1] - výběr posledního elementu, který se
nachází před aktuálním uzlem a je jeho sourozencem
following::*[1] - výběr prvního elementu, který se nachází za
aktuálním uzlem
Funkce jazyka XPath jsou k dispozici na http://www.w3.org/TR/xpath-functions/.
- 10 -
1.6.2
XQuery
XQuery vznikl z experimentálního dotazovacího jazyka Quilt, jehož základní rysy
vycházely z ně
kolika dalš
ích jazyků, včetněXPath 1.0, XQL, XML-QL, SQL a OQL.
Verze 1.0 jazyka XQuery velice úzce souvisí s verzí 2.0 jazyka XPath. Jedná se o velmi
komplexní dotazovací jazyk, který mimo základních výrazů, které jsou známé jižz jazyka
XPath 1.0 (tj. cesty, množ
inová porovnávání, aritmetické výrazy, filtrující predikáty),
zahrnuje pokroč
ilejš
í konstrukce jako FLWOR1 výrazy, tř
ídě
ní, podmíně
né výrazy nebo
konstruktory.
Mimo standardu datového modelu PSVI, který je striktním rozš
íř
ením datového modelu
InfoSet, využívá XQuery i vlastního datového modelu, který definuje povolené hodnoty
vš
ech výrazůi podvýrazůXQuery 1.0, XPath 2.0 a XSLT 2.0. Mezi základní rozš
íř
ení
vlastního datového modelu patř
í zejména možnost využití kolekcí dokumentůa slož
ených
hodnot, atomické hodnoty a podpora uspoř
ádaných heterogenních posloupností.
Posloupnosti jsou základní jednotkou datového modelu. Mohou obsahovat dva základní
druhy polož
ek, a to: atomické (string, celé č
íslo atd.) a uzly definované svým druhem
(koř
en dokumentu, element, atribut, text, komentář
, jmenný prostor, procesní instrukce),
jménem a typem.
K obecným operátorům porovnání ( <, > , <=, >=, = , !=), které definoval jazyk XPath 1.0,
př
idává XQuery spolu s jazykem XPath 2.0 ješ
tětzv. hodnotová porovnání v podobě
operátorůlt , gt, le, ge, eq, ne („menš
í, „větš
í“, „menš
í nebo rovno“, „vě
tš
í nebo
rovno“, „rovno“, „nerovno“) a tzv. uzlové porovnání is. Pro porovnání poř
adí uzlů
v dokumentu se využ
ívá operátorů << („př
ed“) a >> („následující po“). Logickými
operátory potom jsou and, or a not().
Pro snazš
í práci s daty má XQuery př
eddefinováno ně
kolik vstupních funkcí, a to: doc() –
vrací dokument identifikovaný URI, collection() – vrací kolekci dokumentů, která je
spojena s URI, root() – vrací koř
en aktuálního dokumentu, id() – vrací posloupnosti
uzlůnálež
ící danému jménu, idref() – vrací posloupnost uzlů, které odkazují př
ed ID –
IDREF na uzly daného typu. Tyto funkce jsou často spojeny s cestou určující bližš
í výskyt
uzlů, jednotlivé cesty samozř
ejměvycházejí z XPath výrazů. Mimo vstupních funkcí lze
využít př
i dotazování i velkého množství vestavě
ných funkcí (např
. min(), max(),
1
Vyslovováno „flower“.
- 11 -
concat(), string-length(), starts-with(), empty(), exists()) nebo funkcí,
které si sám už
ivatel může definovat.
--- Deklarace funkce --define function název_funkce(vstupní_hodnoty)
as výstupní_hodnoty
{
.
tělo funkce
.
}
--- Volání funkce --nazev_funkce(vstupni_hodnoty)
Př
i dotazovaní si může už
ivatel vytvoř
it vlastní XML data, tento „nadstandard“ umož
ňují
tzv. konstruktory, které jsou vymezeny slož
enými závorkami {} . Pro konstrukci dat lze
použ
ít také konstrukci typ_uzlu název {obsah}.
element osoba{
attribute pohlavi {"muž"},
element krestni_jmeno{"Jaroslav"},
element prijmeni{"Bureš"}
}
--<osoba pohlavi="muž">
<krestni_jmeno>Jaroslav</krestni_jmeno>
<prijmeni>Bureš</prijmeni>
</osoba>
Velmi podstatnou konstrukcí jazyk XQuery jsou tzv. FLWOR výrazy, které jsou obdobou
výrazu SELECT-FROM-WHERE z SQL. Název je složen z prvních písmen klauzulí:
 for – př
iř
azuje jednu nebo více proměnných jednotlivým výrazům,
 let – př
iř
azuje promě
nným celé výsledky výrazů, ke kterým se proměnná
vztahuje,
 where – funguje jako filtr na jižzískané výsledky,
 order by – tř
ídí výsledky podle zadaného kritéria,
 return – umož
ňuje dát výsledkům urč
itou podobu.
<seznam_osob>
{
for $i in doc('pracovni.xml')//student
where ($i/@typ_studia = "prezenční")
order by $i/prijmeni
return
<osoba pohlavi="{ $i/@pohlavi }">
<krestni_jmeno>{ $i/jmeno/text() }</krestni_jmeno>
{ $i/prijmeni }
- 12 -
</osoba>
}
</seznam_osob>
--<seznam_osob>
<osoba pohlavi="žena">
<krestni_jmeno>Jana</krestni_jmeno>
<prijmeni>Krátká</prijmeni>
</osoba>
<osoba pohlavi="muž">
<krestni_jmeno>Pavel</krestni_jmeno>
</osoba>
</seznam_osob>
V klauzuli where je mož
né využ
ít kvantifikátorů, a to jak existenčního (some ), tak
i obecného (every), což umož
ňuje ovlivně
ní výsledné filtrace výsledků. Oba
kvantifikátory lze samozř
ejmětaké nahradit funkcemi exists() resp. empty().
some proměnná satisfies podmínka
<=>
exists (for proměnná where podmínka return 1)
--every proměnná satisfies podmínka
<=>
empty (for proměnná where not(podmínka) return 1)
1.6.3
SQL/XML
Tento dotazovací jazyk není XML jazykem. Do této kapitoly jsem ho zař
adila z důvodu
jeho využ
ívání př
i práci s XML dokumenty, a to př
i zpracování v relač
ních databázových
systémech. Hlavním úkolem SQL/XML je poskytnout mož
nost vytvoř
it XML data
z relač
ních dat, bohužel je využ
itelný pouze v jižexistujícím SQL prostř
edí.
Jak je patrné z názvu, vychází z jazyka SQL, vlastněse jedná pouze o rozš
íř
ení SQL 2003,
umož
ňující práci s XML daty. Tě
mito rozš
íř
eními jsou:
 funkce pro práci s XML,
 datový typ XML,
 mapovací pravidla – určují jak prezentovat SQL hodnoty jako XML data.
Funkce pro práci s XML jsou př
ímo aplikovatelné v SQL dotazu, jedná se o xmlelement() –
vytvoř
í element se zadaným jménem, xmlattributes() – vytvoř
í atributy elementu ze
sloupcůtabulky, xmlroot() – vytvoř
í koř
enový uzel dokumentu, xmlcomment() –
vytvoř
í XML komentář
, xmlpi() – vytvoř
í procesní instrukci, xmlparse() - zanalyzuje
ř
etě
zec a vytvoř
í z ně
j XML strukturu, xmlforest()– vytvoř
í elementy ze sloupců
- 13 -
tabulky, xmlconcat() – slouč
í více XML hodnot do jedné, xmlagg() – vytvoř
í kolekci
elementů.
Podle [36] je implementace SQL/XML dostupná v aplikacích Oracle a IBM, Microsoft
tento jazyk nepodporuje.
Studenti
jmeno prijmeni pohlavi
typ_studia
Pavel
Jana
prezenční
prezenční
Nový
Krátká
muž
žena
Tabulka 1.1: Př
íklad SQL/XML – relace Studenti(jmeno,prijmeni,pohlavi,typ_studia)
select xmlelement(„student“,
xmlforest(s.jmeno as krestni_jmeno,s.prijmeni))
from Studenti s
where s.pohlavi = „muž“;
--<student>
<krestni_jmeno>Pavel</krestni_jmeno>
</student>
1.7 Jazyky pro odkazování
V souč
asné doběexistují dvěspecifikace jazykůpř
ímo zamě
ř
ených na odkazování, a to
XPointer (kapitola 1.7.1) a XLink (kapitola 1.7.2). Obětyto specifikace se oddě
lily od
původního odkazovacího jazyka XLL (eXtensible Linking Language), který definoval
konstrukce pro tvorbu odkazůumož
ňujících propojení dokumentůXML do hypertextové
sítě
.
1.7.1
XPointer
Standard XPointer úzce souvisí se standardem XPath. Jeho hlavním úkolem je adresace na
jednotlivé části XML dokumentu, na tyto č
ásti odkazuje právěpomocí jazyka XPath.
Př
ič
emžmimo základních datových typůXPath využ
ívá ješ
těsvých dvou, a to bodů
(point) a rozsahů(range). Body umož
ňují př
ímou adresaci k elementům nebo jednotlivým
znakům v dokumentu a rozsahy vybírají část dokumentu mezi dvě
ma body.
xpointer(/studenti/student/point[position()=2])
xpointer(range-to(//student/jmeno))
- 14 -
Pokud odkazujeme na objekty v jiných dokumentech, pak je výraz XPointeru př
idán na
konec URL za identifikátorem fragmentu (#).
http://.../x.xml#xpointer(/studenti/student[2])
1.7.2
XLink
Úkolem jazyka XLink je popis spojení mezi dokumenty.
Spojení, která odkazy XLink umožňují, mohou být od klasických jednosměrných, která
známe z HTML (element a ), př
es dvousmě
rné ažk vícesměrným. Typ spojení je definován
atributem type , který můž
e nabývat hodnot simple, extended, locator, arc, title
a resource, z nichžasi nejvíce využ
ívaným je typ pro vazby jednoduché (simple )
a rozš
íř
ené ( extended).
<jednoduchy_odkaz xlink:type=“simple“
xlink:href=“http://www.w3.org/“> W3C </jednoduchy_odkaz>
<kniha xlink:type=“extended“>
<nazev>Čaroděj ze země Oz</nazev>
<autor> L. Frank Baum</autor>
<edice xlink:type=“locator“ xlink:href=“...“/>
</kniha>
1.8 Stylové jazyky (XSLT)
Protož
e nám samotný XML dokument nic neř
íká o tom, v jaké podoběse data v něm
ulož
ená mají zobrazit, bylo nutné získat nějaký nástroj, který by tento problém ř
eš
il.
HTML na rozdíl od XML stylový jazyk př
ímo nepotř
ebuje, má jižpř
eddefinované znač
ky,
které formátování obstarají, ale i př
esto pro tento jazyk byl vyvinut standard pro styly.
Jedná se o jazyk CSS, který byl vytvoř
en roku 1996. Protož
e tento jazyk obsahuje
vlastnosti pro aplikaci stylůna elementy mimo sadu HTML, může být využ
íván i v rámci
XML. Pro XML vš
ak tento standard nebyl dostač
ující, a proto byl navržen formát XSL.
Bě
hem př
íprav standardu XSL byly vytvoř
eny jakési dvějeho podmnož
iny. Jednou je
transformač
ní jazyk XSLT (XSL Transformations), jehožpomocí lze vytvář
et styly, které
definují, jak se XML dokumenty mají př
evádě
t do formátu HTML, XHTML, do XML
dokumentůs jinou strukturou nebo do obyčejných textových dokumentů. Druhá č
ást, tzv.
- 15 -
formátovací část, pak slouží k př
esnému popisu vzhledu dokumentu a je označována jako
XSL-FO.
Jazyk XSLT využívá také dalš
ích XML jazykůjako jazyk XPath či XML Namespaces, ten
je obzvláš
tědůležitý pro mož
nost kombinace různých sad elementůzajiš
ť
ujících smysl
transformace XML dokumentu. Vě
tš
inou je pro jmenný prostor použ
ívaný prefix xsl.
Základním stavebním kamenem stylového dokumentu jsou tzv. š
ablony, v nichžse pomocí
XPath výrazu definuje místo (uzly) v původním XML dokumentu, které má být
zpracováno. Tyto uzly jsou následněukládány do výsledného stromu i s úpravami
definovanými obsahem š
ablony.

<xsl:template match='XPath_výraz'>

</xsl:template>
Aby mohlo dojít k vlastní transformaci, musíme aplikovat na vstupní XML data a XSLT
styl procesor, který vygeneruje výstupní data. K dispozici je dnes celá ř
ada softwarových
procesorů, které umož
ňují zpracování XML dokumentůna základěXSLT stylu, např
.
Saxon, Xalan, XT, MS XML. XSLT procesor na zač
átku své práce nač
te do pamě
ti vstupní
XML dokument a vytvoř
í si jeho stromovou strukturu. Tento strom je pak postupně
procházen od koř
ene v poř
adí, v jakém jsou elementy seř
azeny v dokumentu, a pokud
nalezne uzel odpovídající š
abloně
, zač
ne ho zpracovávat. Potomci tohoto uzlu ale
automaticky zpracováváni nejsou, pokud tedy chceme zpracovat i tyto potomky, musíme
vš
abloněpoužít instrukci <xsl:apply-templates>. Ta ř
íká, že se má daná vě
tev
prohledávat dále a mají se pro její uzly hledat odpovídající š
ablony. Nepovinný atribut
select nám umož
ňuje opět XPath výrazem specifikovat vě
tev dokumentu ke zpracování.
Obrázek 1.3: Formátování XML dokumentu (př
evzato z [11])
Variabilita jednotlivých š
ablon je, dalo by se ř
íci, témě
ř„bezmezná“. Už
ivatel si může
nastavením v počáteč
ním elementu š
ablony pomocí atributůurč
ovat, kdy má být tato
- 16 -
š
ablona volána, dokonce je mož
né využívat š
ablon jako funkcí (nahrazení atributu match
v deklaraci š
ablony atributem name – volání funkce pomocí xsl:call-template). Což
bylo velkou př
edností XSLT verze 1.0, poně
vadžtato verze deklaraci funkcí neobsahovala,
ale př
i tvorběstylu bylo takových č
ástí kódu č
asto zapotř
ebí. Vzhledem k existenci funkcí
pak jižnikoho nepř
ekvapí mož
nost využívání cyklů(xsl:for-each), podmíněných
zpracování(xsl:if, xsl:choose), ř
azení (xsl:sort), promě
nných (xsl:variable)
č
i parametrů(xsl:param).
I př
es velký komfort, který verze 1.0 př
i tvorběstylu umož
ňovala, mě
la ř
adu nedostatků,
které mě
ly být odstraně
ny v nové verzi a to verzi 2.0. Specifikace této verze vyš
la 21. ř
íjna
2006. Mezi základní zdokonalení patř
í jasná deklarace funkcí (není tř
eba využ
ívat š
ablon),
mož
nost využ
ití datových typů, mož
nost výstupu do více souborů(to dř
íve umož
ňovaly
pouze některé procesory, možnost seskupování apod.
<xsl:stylesheet xmlns:xsl='http://www.w3.org/1999/XSL/Transform'
version='1.0'>
<xsl:output method="html" encoding="windows-1250" />
<xsl:template match='/'>
<html>
<head>
<title>Priklad</title>
</head>
<body>
<h2 align="center">Seznam studentů</h2>
<p>Výpis příjmení jednotlivých studentů:</p>
<ul><xsl:apply-templates select="studenti/student"
mode="prijmeni" /></ul>
<hr/>
<xsl:apply-templates select="studenti/student"/>
</body>
</html>
</xsl:template>
<xsl:template match="student" mode="prijmeni">
<li><xsl:value-of select="prijmeni"/></li>
</xsl:template>
<xsl:template match='student'>
<h3>Pohlaví: <xsl:value-of select="@pohlavi"/></h3>
<ul><xsl:apply-templates/></ul>
<hr/>
</xsl:template>
<xsl:template match='jmeno'>
<li>Jméno: <xsl:apply-templates/></li>
- 17 -
</xsl:template>
<xsl:template match='prijmeni'>
<li>Příjmení: <xsl:apply-templates/></li>
</xsl:template>
</xsl:stylesheet>
Výsledek po transformaci:
Obrázek 1.4: Výsledek XSLT transformace
1.9 Jazyk pro aktualizaci XML dokumentu (XUpdate)
Jazyk XUpdate je doposud jediným značkovacím jazykem, který umožňuje měnit obsah
a strukturu jižexistujícího XML dokumentu. Na jeho vývoji od úplného poč
átku pracuje
XML:DB1.
1
Iniciativa utvoř
ená organizacemi: SMB Gesellschaft für Softwareentwicklung mbH (Lipsko), dbXML
Group L.L.C, OpenHealth Care Group.
- 18 -
Jako vš
echny XML jazyky, je i XUpdate velice dobř
e strukturovaný. K výběru č
ástí
dokumentů, kterých se má týkat aktualizace, využ
ívá XUpdate jazyka XPath. Principielně
je tento jazyk velice podobný transformač
nímu jazyku XSLT.
Celý
XUpdate
dokument
je
uzavř
en
do
koř
enového
elementu
<xupdate:modification> , z č
ehožvyplývá jasná podpora jmenných prostorů. Mimo
jmenného prostoru specifikovaného v tomto elementu je zde ješ
těpovinný atribut pro
stanovení verze (v souč
asné doběverze 1.0). Koř
enový element může obsahovat
následující podelementy: xupdate:insert-before (vlož
í uzel př
ed vymezený uzel),
xupdate:insert-after (vlož
í uzel za vymezený uzel), xupdate:append (vloží
uzel jako dě
tský podelement do vymezeného uzlu), xupdate:update (aktualizuje obsah
uzlu),
xupdate:remove
xupdate:variable
(odstraní uzel),
(př
ejmenuje uzel),
xupdate:rename
(definuje proměnnou),
xupdate:value-of
(vrátí hodnotu
vymezeného uzlu), xupdate:if (konstrukce pro podmíněné zpracování).
Vkládanými
uzly
mohou
(xupdate:attribute),
prostý
být
elementy
text
(xupdate:element),
(xupdate:text),
procesní
(xupdate:processing-instruction ) č
i komentář
e (xupdate:comment).
<?xml version="1.0"?>
<xupdate:modifications version="1.0"
xmlns:xupdate="http://www.xmldb.org/xupdate">
<xupdate:insert-after select="/studenti/student[1]" >
<xupdate:element name="student">
<xupdate:attribute name="pohlavi">
muž
</xupdate:attribute>
<xupdate:attribute name="typ_studia">
prezenční
</xupdate:attribute>
<jmeno>Martin</jmeno>
<prijmeni>Lhoták</prijmeni>
</xupdate:element>
</xupdate:insert-after>
</xupdate:modifications>
- 19 -
atributy
instrukce
2 XML A DATABÁZE
Celá př
edchozí kapitola byla věnována znač
kovacímu jazyku XML, a proto nebudu
v úvodu této kapitoly jazyk XML nadále popisovat, ale zamě
ř
ím se pouze na popis
databází a nástrojůs nimi souvisejích.
Databáze je určitá uspoř
ádaná množ
ina informací (dat) ulož
ená na pamě
ťovém médiu
poč
ítač
e, která je spravována systémem ř
ízení báze dat (SŘBD – z anglického DataBase
Management System – DBMS). SŘBD zahrnuje softwarové prostř
edky umožňující
definování struktury dat, ukládání dat, výběr dat, ochranu dat, komunikaci mezi uživatelem
a systémem apod. Databáze spolu se SŘBD tvoř
í tzv. databázový systém, který bývá také
č
asto označován slovem „databáze“, a to hlavnětam, kde je z kontextu zř
ejmé, ž
e se jedná
o databázový systém nikoli o samotnou databázi. Ve své práci jsem pro označ
ení
databázového systému využ
ívala obou tě
chto výrazů.
Na základězpůsobu ukládání dat a vazeb mezi nimi se můžeme setkat s několika druhy
databázových modelů, z nichžnejznámě
jš
í jsou určitěrelač
ní databáze1 , které mě
ly být
nahrazeny v 90. letech minulého století databázemi objektovými2, cožse ale nezdař
ilo
a doš
lo ke vzniku objektověrelačních databází3, tedy kompromisu mezi obě
ma tě
mito
druhy databázových systémů. Za zmínku také stojí dva starš
í modely, a to síťové databáze4
(první byla vytvoř
ena roku 1965) a o ně
co mladš
í hierarchické databáze 5 (z počátku
70. let).
Z výš
e uvedeného popisu, co je databáze, by se dalo usoudit, že vlastní XML dokument je
také databází, ale pokud by byl takovýto dokument označ
en za databázi, mohl by být
databází jakýkoli jiný soubor zpracovávaný počítač
em. XML dokument má ale pro toto
označení daleko vě
tš
í př
edpoklady, je totižvelmi dobř
e strukturovaný na základěznaček,
je platforměnezávislý, atd.
1
Databázový systém založ
ený na relač
ním modelu a relač
ní algebř
e. Data jsou uspoř
ádána do relací
(tabulek), nad kterými lze provádět př
ípustné operace.
2
Databázový systém založený na objektověorientovaném př
ístupu (OOP). Do databáze ukládá př
ímo
objekty, poskytuje nástroje pro objektověorientované dotazy.
3
Databázový systém, který rozš
iř
uje relač
ní databázi o mož
nost práce s objekty.
4
Databázový systém založený na síť
ovém modelu. Data jsou uspoř
ádána jako uzly rovinného grafu.
5
Databázový systém založený na hierarchickém modelu. Data jsou uspoř
ádána do stromové struktury.
- 20 -
K databázi ale samozř
ejmětaké nálež
í SŘBD. Můž
e být XML se svými doplňkovými
standardy a rozš
íř
eními takovýmto systémem? Dalo by se ř
íci, ž
e ano: ukládání dat je
zajiš
tě
no př
ímo XML dokumentem, strukturu dat definují jazyky pro popis dokumentu
(DTD, XML Schema, …), výbě
r dat umož
ňují dotazovací jazyky (XPath, XQuery, …),
komunikaci mezi už
ivatelem a systémem poskytují programová rozhraní pro XML (SAX,
DOM, …). Bohuž
el má ale XML celou ř
adu nedostatků, pro ně
žnemůž
e být tento jazyk
ř
azen k plnohodnotným SŘBD. Postrádá např
íklad efektivní ukládání dat, indexování,
bezpeč
nost, transakce, integritu dat, víceuživatelský př
ístup, a dalš
í.
Pro malé množství dat, uživatelůa nízké požadavky na výkon můž
e XML naprosto
postač
ovat i jako databázový systém, př
i zvýš
ení nárokůpouze s XML vystač
it nelze. Tím
ale XML nemusíme úplněodepisovat, pro uložení XML dokumentůmůžeme využ
ít jiné
strategie: uložení s využ
itím systému souborů, ulož
ení v relač
ním databázovém systému,
ulož
ení v objektověorientovaném č
i objektověrelač
ním databázovém systému a př
ímé
(nativní) uložení XML dat (viz kapitola 3 – Nativní XML databáze).
S databázemi souvisí i druhy XML dokumentů. Datověorientovaný XML dokument je
svojí pravidelnou strukturou př
ímo př
edurč
en k využ
ití v databázovém systému (č
asto jsou
takové dokumenty př
ímo databázovým výstupem), a to př
edevš
ím v databázových
systémech nenavrž
ených př
ímo pro zpracování XML (např
. relační, objektověorientované
databázové systémy). Dokumentověorientované XML dokumenty sice nejsou vhodné pro
př
ímé ukládání do „ne-XML“ databází kvůli své malé strukturovanosti, ale s využitím
nativních XML databázových systémůlze i těchto dokumentův databázích využ
ívat
a zpracovávat.
Zdroje vztahující se k celé kapitole 2: [5], [6], [9]
2.1 Obecné způsoby ulož
ení XML dokumentů
Jak jižbylo uvedeno výš
e, existuje několik mož
ností, jakým způsobem XML dokumenty
spravovat. Vš
echny způsoby mají ř
adu výhod i nevýhod, ale jejich už
ití užzálež
í pouze na
posouzení konkrétního uživatele v závislosti na spravovaných datech. Jasným favoritem
pro ukládání XML dokumentůjsou samozř
ejměnativní XML databáze, pro něje ale
vyhrazena celá hlavní kapitola (kapitola 3), proto se jim zde nebudu vě
novat.
- 21 -
2.1.1
Ulož
ení v systému souborů
Tento způsob je pro svoji nenároč
nost a jednoduchost velice oblíbený, je založ
en pouze na
správěsouborův systému.
Př
i dotazování obvykle dochází k vyhledání, nač
tení a analýze pož
adovaných XML
souborů. Veš
kerá data jsou pak uložena do speciálních struktur (např
. stromůW3C DOM).
Hlavními nevýhodami je nutná analýza celých dokumentůa uchovávání vytvoř
ených
stromůpo celou dobu dotazování. Těmto nevýhodám lze zamezit vhodným indexováním,
ale tím vznikne dalš
í (dost podstatná) nevýhoda, a to nemož
nost aktualizace dokumentu.
S využitím jiného druhu indexování, tzv. blokových stromůnebe klasických B-stromů, je
i tento problém z č
ásti ř
eš
itelný, ale pak užtento způsob ztrácí svoji hlavní výhodu, tedy
jednoduchost implementace.
2.1.2
Ulož
ení v relač
ní databázi
Protož
e se relač
ní databáze č
asto využívají, existuje možnost ukládat XML data i tímto
způsobem.
Vhodnými kandidáty pro tento způsob uložení jsou datověorientované XML dokumenty.
Po jejich př
evedení do relač
ních tabulek (s využ
itím mapovacích metod – viz kapitola 2.4)
je s nimi možné nakládat obvyklými způsoby pro relační databáze.
Dotazování je v tomto systému samozř
ejměmož
né, ale př
i slož
itých dotazech dochází již
k obtížně
jš
í implementaci, v některých př
ípadech je dokonce nutné využít, mimo SQL,
ně
jakého vyš
š
ího programovacího jazyka.
2.1.3
Ulož
ení v objektové databázi
Př
i využití objektových databází se pohlíž
í na jednotlivé XML elementy jako na
samostatné objekty, které jsou automaticky uloženy do databázového systému.
- 22 -
2.1.4
Ulož
ení v objektověrelač
ní databázi
Objektověrelační databáze spravují data v tabulkách shodněs relač
ními databázemi,
mohou ale navíc aplikovat abstraktní datové typy1, které umožňují „rozvětvit“ ně
které
polož
ky do bohatš
ích struktur.
Abstraktních datových typůvyuž
ívají objektověrelační systémy i pro ukládání XML dat,
nutná je vš
ak existence DTD – pokud není k dispozici, odvodí si ho systém sám. Definice
typu dokumentu napoví systému, jak bude vypadat výsledná struktura tabulek pro ulož
ení
dat. Způsob př
evodu dat je obdobný uložení dokumentu do relač
ní databáze.
2.2 Ukládání dokumentověorientovaných XML dokumentů
Základním pož
adavkem na ukládání tě
chto dokumentůje zachování XML dokumentu jako
celku, tedy zachování poř
adí elementů, komentář
ů, sekcí CDATA atd. Úroveňround
trippingu2 musí být znač
něvysoká, tj. výsledkem rekonstrukce uloženého dokumentu musí
být dokument co nejpodobně
jš
í dokumentu původnímu (nejlépe dokument totož
ný).
V zásadě existují tř
i mož
né způsoby ukládání dokumentově orientovaných XML
dokumentů:
 ukládání v systému souborů,
 ukládání jako BLOB (nebo CLOB) v relač
ních databázích,
 využítí nativních XML databázových systémů(kapitola 3).
2.2.1
Ukládání v systému souborů
Ukládání pomocí tohoto systému je nejsnazš
ím způsobem ukládání dokumentově
orientovaných XML dokumentů, ale ne vž
dy je úplněvýhodné. Hodí se př
edevš
ím pro
správu vě
tš
ího množství malých dokumentů. Dotazování je v tomto systému velice
omezené, lze využ
ít pouze standardního fulltextového vyhledávání (např
. prohledávání
obsahu souborůve Windows).
1
Vedle struktury obsahují také zapouzdř
ené funkce a operace.
Výraz round tripping (v př
ekladu „okružní jízda“) znač
í operaci ulož
ení XML dokumentu do systému a
jeho zpě
tnou rekonstrukci.
2
- 23 -
2.2.2
Ukládání v BLOB
Poněkud propracovaně
jš
í je ukládání obsahu dokumentůdo sloupce tabulky typu BLOB
(č
i CLOB). Tento způsob užposkytuje ně
které výhody databázových systémů(kontrola
transakcí, víceuživatelský př
ístup, …). Navíc, mnoho relač
ních databází má nástroje pro
fulltextové vyhledávání, vyhledávání sousedů, duplicit, … a v př
ípadědatabázových
systémůpodporujících XML se často stává situace ješ
tělepš
í - umož
ňují práci s obsahem
dokumentu na vyš
š
í úrovni nežjen jako s prostým textem.
Také lze využ
ít jednoduchého indexování, např
íklad prostř
ednictvím dvou tabulek, kde
jedna tabulka obsahuje sloupec primárních klíčů1 a sloupec typu BLOB a druhá tabulka
sloupec s hodnotou indexůa sloupec cizích klíč
ů2 odkazující na sloupec primárních klíč
ů
první tabulky.
2.3 Ukládání datověorientovaných XML dokumentů
Z velmi dobré strukturovanosti datověorientovaných XML dokumentůvyplývá vhodnost
pro využ
ití v klasických databázových systémech. Základní myš
lenkou je tedy ukládání a
zpracování XML dat v relač
ní (nebo objektověrelač
ní) databázi. Pro př
evod XML dat do
tabulek se využ
ívá tzv. mapovacích metod.
Na tento druh dokumentůse nejč
astě
ji aplikují databáze s XML rozš
íř
ením (XML enabled
database), tedy klasický SŘBD s rozš
íř
eními, nebo se využívá XML middleware, cožje
samostatný software pro př
enos XML dat mezi XML dokumenty a tabulkami vybrané
databáze. Pro ukládání a zpracování dat v objektověrelač
ních systémech jsou také velmi
důležité XML data binding nástroje, které se zabývají mapováním XML dat na objekty
vybraného objektověorientovaného jazyka.
Velkým usnadně
ním př
i zpracování je to, ž
e není nutné zachovat dokument jako celek, tj.
není důlež
ité poř
adí elementů, nezachovávají se komentář
e, sekce CDATA atd. Úroveň
round trippingu stačí nízká.
1
Primární klíčje atribut nebo množina atributů
, která jednoznačněurč
uje prvek v relaci (ř
ádek v tabulce).
Cizí klíčje atribut nebo množ
ina atributůodkazující na jiný prvek v relaci (vě
tš
inou jiné), tento prvek musí
mít s tímto klíč
em totož
ný primární klíč
.
2
- 24 -
2.4 Mapovací metody
Př
i využití relačních nebo objektověrelač
ních databázových systémůje prvním krokem
př
evedení XML dokumentu do tabulek těchto systémůpomocí mapovacích metod.
Mapování je provádě
no pouze nad elementy, atributy a prostým textem, nedochází tedy
k uchovávání komentář
ů, procesních instrukcí apod., z č
ehožje zř
ejmé, že tabulky databází
neobsahují vš
echny informace z XML dokumentu, a tak využ
ití těchto metod není vhodné
pro dokumentově orientované XML dokumenty, u nichž se vyžaduje jejich úplné
zachování.
V základu existují tř
i typy mapovacích metod – generické, schématem ř
ízené a už
ivatelsky
definované mapování. Základním rozdílem mezi prvními dvěma typy mapování je využití
XML schématu. Generické mapování mapuje XML dokument nezávisle na schématu, č
ímž
umož
ňuje ukládat libovolné XML dokumenty, na rozdíl od schématem ř
ízených metod,
které využívají existující XML schéma pro definici databázového schématu a umož
ňují
ukládat pouze validní dokumenty. Poslední typ – už
ivatelsky definované mapování –
ponechává celý proces na uživateli.
2.4.1
Generické mapování
Jak jsem jižuvedla výš
e, př
i generickém mapování lze do databáze ulož
it jakýkoli XML
dokument, cožale nemusí být vždy pravda. Jediným omezením původního dokumentu
můž
e být výsledné databázové schéma. Toto omezení je skuteč
něvyužíváno, týká se pouze
jedné, ale hojněvyužívané, skupiny metod generického mapování, a to tabulkového
mapování. Dalš
í metody Gengeric-tree mapping, Stucture-centred mapping a Simple-path
mapping užmohou opravdu ulož
it libovolný XML dokument.
Př
edpokladem pro využ
ití tabulkového mapování je existence XML dokumentu, který
př
ímo definuje databázové schéma. Tedy př
i náhledu na dokument je ihned zř
ejmé
rozdě
lení př
ísluš
ných dat do jedné č
i více tabulek. Např
íklad pro tuto tabulku:
Studenti
jmeno prijmeni pohlavi
typ_studia
Pavel
Jana
prezenční
prezenční
Nový
Krátká
muž
žena
Tabulka 2.1: Výsledná tabulka po generickém tabulkovém mapování - příklad
- 25 -
mě
l XML dokument tuto strukturu:
<studenti>
<student>
<pohlavi>muž</pohlavi>
<typ_studia>prezenční</typ_studia>
</student>
<student>
<jmeno>Jana</jmeno>
<pohlavi>žena</pohlavi>
<typ_studia>prezenční</typ_studia>
</student>
</studenti>
Metoda Generic-tree mapping vidí vstupní dokument jako orientovaný strom, u ně
hožmají
vnitř
ní uzly jednoznačné identifikátory a listy obsahují hodnoty atributůnebo textové
obsahy jednotlivých elementů. Pomocí názvůelementůjsou označ
eny hrany stromu.
...
<student id=“1“ pohlavi="muž">
</student>
<student id=“2“ pohlavi="žena">
<jmeno>Jana</jmeno>
</student>
...
student
student
1
2
pohlavi
pohlavi
jmeno
jmeno
prijmeni
muž
Pavel
prijmeni
ž
ena
Jana
Krátká
Nový
Na základětohoto stromu je pak XML dokument ukládán do databáze různými způsoby,
např
.
 mapováním hran - ukládá vš
echny hrany stromu do jediné tabulky (jeden ř
ádek
tabulky obsahuje popis jedné hrany stromu),
 atributovým mapováním – snaží se udržovat pohromadě pouze data spolu
související (každý název hrany má vlastní tabulku),
 univerzálním mapováním – také ukládá vš
echny hrany stromu do jediné tabulky
(výsledná tabulka je shodná se sjednocením vš
ech tabulek atributového mapování),
 normalizovaným univerzálním mapováním – zpracovává data obdobným
způsobem jako př
edchozí mapování, ale pro kaž
dý název hrany obsahuje pouze
jeden záznam, ostatní záznamy jsou ulož
eny ve speciálních tabulkách se stejnou
strukturou jako tabulky atributového mapování.
Také dalš
í metoda, Structure-centred mapping, vychází ze zobrazení XML dokumentu
jako orientovaného stromu, ale s jinou strukturou. Kaž
dý uzel stromu odpovídá č
tveř
ici
- 26 -
N = (t, l, c, n), kde t je typ uzlu, l název uzlu, c textový obsah a n seznam dě
tí.
Získání poslední hodnoty je poně
kud obtížné, a proto existuje několik variant tohoto
algoritmu:
 využití primárních a cizích klíč
ůtabulek – každý uzel má př
iř
azen primární klíč
a také cizí klíčodkazující na rodič
ovský uzel,
 DF (depth first) algoritmus – každý uzel je identifikován dvojicí čísel znač
ící
poř
adí navš
tívení a opuš
tě
ní daného uzlu př
i průchodu stromem do hloubky,
 SICF (simple continued fraction) algoritmus – kaž
dému uzlu je př
iř
azena
jednoznač
ná SICF hodnota.
I poslední metoda, Simple-path mapping, vychází z orientovaného stromu, navíc ale
př
edpokládá, že vš
echny dotazy nad ulož
enými daty budou v jazyce XPath. Strom
obsahuje tř
i typy uzlů– elementové uzly (obsahují název a seznam dě
tí), atributové uzly
(obsahují název a textovou hodnotu) a textové uzly (obsahují textovou hodnotu).
Algoritmus pak vychází z myš
lenky ulož
it do databáze př
ímo plné cesty (jednoduché cesty
jazyka XPath – např
. /student/jmeno) do vš
ech uzlůgrafu. Zároveňje ale nutné
zohlednit pozici uzlu a jeho poř
adí vzhledem k sousedním uzlům. Databázové schéma má
tedy následující strukturu:
Element(ID_dokumentu, ID_cesty, pořadí, pozice)
Atribut(ID_dokumentu, ID_cesty, hodnota, pozice)
Text(ID_dokumentu, ID_cesty, hodnota, pozice)
Cesta(ID_cesty, text_cesty)
2.4.2
Schématem ř
ízené mapování
Metody schématem ř
ízeného mapování vychází z existence XML schématu, ze kterého se
snaž
í nač
erpat maximální množ
ství informací o ukládaných XML dokumentech. Př
ed
vlastním ulož
ení validních dokumentůdo databáze je nutné provést mapování XML
schématu na databázové schéma.
Pro zdrojová schémata je nejč
astě
ji využ
íván jazyk DTD, méněpak jazyk XML Schema,
a pro cílová schémata relační schéma, popř
ípaděobjektověrelač
ní schéma (ve spojení
s XML Schema).
- 27 -
Obecné charakteristiky a společ
né principy:
 Podelementy s maximálním výskytem jedna jsou mapovány do tabulky
nadelementu (tzv. inlining).
 Inlinované podelementy s nepovinným výskytem jsou mapovány na sloupce
s prázdnými hodnotami.
 Podelementy s vícenásobným výskytem jsou mapovány do samostatných tabulek,
kde vztahy element-podelement jsou mapovány pomocí primárních, cizích klíč
ů
a referenč
ní integrity1.
 Alternativní podelementy jsou mapovány do samostatných tabulek, nebo do jediné
univerzální tabulky s mnoha prázdnými hodnotami.
 Pokud je tř
eba zachovat poř
adí sousedních elementů, je tato informace obvykle
ulož
ena do speciálního sloupce.
 Elementy se smíš
eným obsahem obvykle vůbec podporovány nejsou. Důvodem je
následek zkomplikování a zpomalení algoritmu.
Podle způsobu optimalizace existují dva základní typy metod – fixní a flexibilní. Fixní
metody pracují pouze s daným XML schématem. Úkolem flexibilních metod je dalš
í
optimalizace výsledného databázového schématu.
Hlavními př
edstaviteli fixního mapování využívající jazyk DTD jsou algoritmy Basic,
Shared a Hybrid. Zástupcem fixní metody využívající XML Schema je algoritmus
Constrainst preserving, jehožcílovým schématem je relační schéma. Obětyto skupiny
algoritmůvyužívají př
i mapování konstrukcí pomocných modelů– algoritmy Basic,
Shared a Hybrid konstruují DTD graf a algoritmus Constraints preserving tzv. EER model
(Extended Entity-Relationship Model), cožje rozš
íř
ený ER model 2.
Ze zástupcůflexibilních metod bych uvedla LegoDB mapping a Hybrid object-relational
mapping.
2.4.3
Mapování definované uživatelem
Jak již vyplývá z označ
ení poslední metody mapování, tj. už
ivatelsky definované
mapování, je celý mapovací proces pouze v rukou uživatele, který si sám nejprve definuje
1
2
Kontroluje správné použ
ití cizích klíč
ů– zda k cizímu klíči existuje totožný primární klíč
.
Soubor pojmů, s jejichžpomocí se popisuje realita.
- 28 -
databázové schéma a pak pomocí ně
jakého rozhraní (např
. dotazovací jazyk, anotace
v XML dokumentech) specifikuje požadované mapování.
- 29 -
3 NATIVNÍ XML DATABÁZE
Nativní XML databáze jsou speciální databázové systémy př
ímo urč
ené k ukládání XML
dat. Také jako klasické databáze podporují transakce, zabezpeč
ení, víceuž
ivatelský př
ístup,
dotazovací jazyky apod. Jediným rozdílem těchto databázových systémůje jejich vnitř
ní
model, který je celý založ
en jen na XML.
Hlavní rysy nativních XML databází se dají shrnout do tř
ech bodů:
 Objekty k uskladně
ní v nativních XML databázích jsou XML data.
 XML dokument je považován za základní jednotku ulož
ení dat.
 Nativní XML databáze ukládá XML dokumenty v „nativní“ (př
irozené) formě
, ale
nemusí se jednat o samostatný databázový systém.
Termín „nativní XML databáze“ (v originále „native XML database“) se poprvé objevil př
i
marketingové kampani projektu Tamino, nativní XML databáze od Software AG, a hned
po ní se celosvětověuchytil. Bohuž
el doposud neexistuje ž
ádná formální definice „nativní
XML databáze“.
XML dokumenty ukládané do nativních XML databází mohou být libovolné struktury,
v praxi se vš
ak do tě
chto systémů ukládají č
astě
ji dokumentověorientované XML
dokumenty, protože s využ
itím dotazovacích jazyků dostupných právě v tě
chto
databázových systémech je možné rychle a jednoduš
e získat odpově
ďna téměřjakoukoli
otázku. Dalš
ím důvodem pro použ
ití tě
chto systémůje zachovávání struktury, procesních
instrukcí, sekcí CDATA, komentář
ů, ... , coždatabáze založ
ené na XML (XML-enabled
Database) neumožňují.
V souč
asné doběexistuje velké množ
ství nativních XML databází, a to jak komerč
ních,
tak i nekomerčních, př
ič
emžvětš
ina z nich má bě
ž
nou funkcionalitu:
 Vš
echny ukládají XML data na úrovni dokumentůa mnoho z nich tyto dokumenty
seskupuje do tzv. kolekcí, nad kterými potom pracuje.
 Vš
echny podporují aspoň jeden dotazovací jazyk, vě
tš
ina podporuje XPath.
Některé podporují i aktualizace.
 Témě
řvš
echny využ
ívají indexování nad kolekcemi dokumentů, nebo dokonce
př
ímo nad elementy a atributy.
- 30 -
Př
íklady komerč
ních databází podle [9]:
Název databáze
Typ databáze
Vývojář
/Tým vývojář
ů
post-relač
ní
M/Gateway Developments Ltd.
vlastní model
Infonyte GmbH
vlastní model, relač
ní
QuiLogic Inc.
vlastní model, relační (ODBC)
Software AG
vlastní model
X-Hive Corporation
eXtc
Infonyte
SQL/XML-IMDB
Tamino
X-Hive/DB
Tabulka 3.1: Komerč
ní nativní XML databáze
Zástupci nekomerč
ních nativních XML databází jsou uvedeny v kapitole 3.3.
Zdroje vztahující se k úvodu kapitoly 3 a podkapitolám 3.1, 3.2: [9], [41]
3.1 Architektura
Architektura nativních XML databází se dě
lí do dvou kategorií: textověa modelově
založ
ené databáze.
3.1.1
Textové nativní XML databáze
Textověorientované nativní XML databáze ukládají XML dokumenty jako prostý text,
a to např
. do souborového systému, jako BLOB (nebo CLOB) v relač
ní databázi nebo
v jiném textovém formátu.
Společ
ným znakem vš
ech textovězalož
ených XML nativních databází je využ
ívání
indexů, které umožňují rychlejš
í vyhledání požadovaného místa dokumentu. Ke zrychlení
dojde př
edevš
ím př
i získávání celého XML dokumentu nebo jeho č
ástí, protože př
i
takových operacích stač
í využít pouze jednoho indexu.
Obecnělze ř
íci, ž
e př
i získávání XML dokumentu nebo jeho jednotlivých částí ve stejné
struktuř
e jako má původní dokument se dospěje k výsledku velice rychle, v opač
ném
př
ípadě
, pokud chceme dát výslednému dokumentu (či ně
jakému fragmentu) jinou
strukturu, bude tato operace č
asověnáročná.
- 31 -
3.1.2
Modelové nativní XML databáze
Druhá kategorie, modelověorientované nativní XML databáze, př
istupuje k problému
jiným způsobem. XML dokumenty neukládá jako text, ale vytvář
í jejich objektové modely,
které následněukládá do relač
ních č
i objektověorientovaných databází nebo do databází
s vlastním modelem.
Modelovězaložené XML databáze vystavě
né nad relač
ními, objektovými nebo objektově
orientovanými databázemi mají s tě
mito databázemi srovnatelnou výkonnost. Zatímco
databáze vystavě
né nad vlastním databázovým modelem jsou srovnatelné s textově
orientovanými nativními databázemi, tedy pokud nač
ítají data ve stejné struktuř
e jako
výchozí XML dokument.
Také modelověorientované databáze se setkávají s výkonnostními problémy př
i získávání
a vracení dat v jiné formě
, nežve kterém byly ulož
eny.
3.2 Základní charakteristiky XML nativních databází
3.2.1
Kolekce dokumentů
Větš
ina nativních XML databází využívá př
i ukládání XML dokumentůtzv. kolekcí.
Kolekce plní podobnou funkci jako tabulka v relačních databázích. V jedné kolekci mohou
být ulož
eny XML dokumenty různého (nebo také ž
ádného) XML schématu, odliš
nost
dokumentůmůže mít vš
ak za následek problémy s provádě
ním operací (např
. vyhledávání,
aktualizace, ...).
3.2.2
Dotazování a aktualizace
Dotazovací jazyky ke XML nativním databázím neodmyslitelněpatř
í, kaž
dý takovýto
systém podporuje alespoň jeden dotazovací jazyk. K nejč
astě
ji podporovaným patř
í
samozř
ejměXPath, dále pak XQuery.
Aktualizaci ukládaných dokumentů ř
eš
í jednotlivé nativní XML databáze různými
způsoby. Ně
které podporují jazyk XUpdate nebo rozš
íř
ení nad jazykem XQuery.
- 32 -
3.2.3
Transakce, zamykání a víceuživatelský př
ístup
Vš
echny nativní XML databáze podporují transakce. Zamykání je č
asto pouze na úrovni
celých XML dokumentů, než na jednotlivých č
ástech dokumentu. Proto také
víceuž
ivatelský př
ístup může v ně
kterých př
ípadech způsobovat znač
né obtíž
e, záleží
ovš
em na stylu ukládání dokumentů– pro velké množství malých dokumentůmůže být
zamykání transakcí na úrovni celých dokumentůoptimální.
3.2.4
Aplikační programové rozhraní (API)
Témě
řvš
echny nativní XML databáze dávají už
ivatelům mož
nost využ
ít ně
jakého API
(v ně
kterých př
ípadech i vlastního), které jsou obvykle ve formě ODBC rozhraní
umož
ňující správu dat a metadat. Výsledky ze zpracování bývají č
asto vráceny jako prostý
text, v DOM stromu nebo v SAX.
V roce 2004 byly vyvinuty dvěXML API:
 XML:DB API od XML:DB – je programověnezávislý, jako dotazovací jazyk už
ívá
XPath, podporuje XQuery
 JSR 225: XQuery API for Java (XQJ) – je založ
ený na JDBC, jako dotazovací
jazyk už
ívá XQuery
3.2.5
Round tripping
Vš
echny nativní XML databáze mohou zrekonstruovat dokument z původního dokumentu
na úrovni elementů, atributů, sekcí CDATA a struktury. V jaké míř
e lze tento round
tripping ješ
tězdokonalit, závisí pouze na jednotlivých databázích.
Obecnělze ř
íci, ž
e textověorientované nativní XML databáze jsou schopné dosáhnout
nejvyš
š
í možné úrovněround trippingu, tedy dokáž
í vrátit XML dokument totož
ný
s původním. To užale neplatí u modelovězalož
ených nativních XML databází, které jsou
vhodně
jš
í pro ukládání datověorientovaných XML dokumentů, takž
e zde nemusí být
úroveňround trippingu tak vysoká.
- 33 -
3.2.6
Indexování
Pro nativní XML databáze je typické využívání indexůke zrychlení dotazování. Základní
typy:
 hodnotové indexy – označují texty elementůnebo atributy (využití - např
. „Najdi
vš
echny elementy nebo atributy, jejichžhodnota je ‘muž’.”),
 strukturální indexy – označují umístě
ní elementůa atributů(využ
ití – např
. „Najdi
vš
echny elementy s touto adresou: ...“),
 full-textové indexy – označ
ují jednotlivé znaky v textu a hodnotách atributů
(využití – např
. „Najdi vš
echny dokumenty, které obsahují slovo ‘muž
’“).
Větš
ina databází podporuje hodnotové a strukturální indexování, full-textovými indexy
disponují jen ně
které nativní XML databáze.
3.2.7
Normalizace a referenční integrita
Základním principem normalizace je navrž
ení takového databázového schématu, který
zajistí, aby se data ulož
ená v databázi zbytečněneopakovala – sniž
uje redundanci
(nadbytečnost) dat. I v XML lze normalizaci aplikovat, např
íklad navrž
ením správného
XML schématu. Ne vž
dy je ale normalizace na místě
. Př
i ukládání dokumentově
orientovaných XML dokumentů by normalizace způsobila ztrátu smyslu využití
takovýchto dokumentů, které mají ulehč
ovat práci svojí př
esnou dokumentovou strukturou,
i př
es drobné redundance, ježč
asto obsahují.
V relač
ních databázích referenč
ní integrita zajiš
ť
uje, ž
e cizí klíč
e vž
dy odkazují na
existující primární klíč
e, v nativních XML databázích pak, ž
e ukazatel v XML dokumentu
ukazuje na validní dokumenty nebo jejich č
ásti. Ukazateli v XML dokumentech mohou být
atributy ID nebo IDREF, pole typu key a keyref (definované v XML Schema), odkazy
XLink nebo vlastní mechanizmy jednotlivých nativních XML databází. V nativních XML
databázích existují dva druhy referenční integrity:
 integrita vnitř
ních ukazatelů – uvnitř jednoho XML dokumentu: Už
ívá
mechanizmůID, IDREF, key nebo keyref, lze ji tedy zajistit validací. Zajiš
tě
ní této
integrity je možné ve vě
tš
iněnativních XML databází jen z č
ásti, protože často
nedochází k validaci po aktualizaci dat, ale pouze př
i vkládání XML dokumentu.
 integrita vnějš
ích ukazatelů– mezi XML dokumenty: Tato referenční integrita
nebývá v nativních XML databázích podporována. V zajiš
tě
ní integrity mezi XML
- 34 -
dokumenty v rámci jedné databáze nejsou žádné př
ekáž
ky, problémem je integritu
zabezpečit př
i odkazování mimo databázi, např
. na nějakou URL adresu.
3.3 Nekomerč
ní XML nativní databáze
Obsahem této kapitoly je stručné seznámení se zástupci nekomerčních XML nativních
databází podle [9]:
Název databáze
Typ databáze
Vývojář
/Tým vývojář
ů
objektověorientovaná
FourThought
klíč- hodnota
Sleepycat Software
DBDOM
relační
K. Ari Krupnikov
dbXML
vlastní model
dbXML Group
eXist
vlastní model
Wolfgang Meier
MySQL
Mladen Adamovic
objektověorientovaná
ozone-db.org
vlastní model
ISP RAS MODIS1
Timber
Shore, Berkeley DB
University of Michigan
XDBM
vlastní model
Matthew Perry, Paul Sokolovsky
Xindice
vlastní model
Apache Software Foundation
XpSQL
relační
Makato Yui
4Suite
Berkeley DB XML
myXMLDB
Ozone
Sedna XML DBMS
Tabulka 3.2: Nekomerční nativní XML databáze
Protož
e každá databáze je vytvoř
ena jinými subjekty, nebylo mož
né př
es veš
kerou moji
snahu sehnat o vš
ech výš
e uvedených databázích totož
né informace (např
. historie vývoje,
maximální velikost zpracovávané databáze a ukládáných dokumentů,… ), proto se obsah
jednotlivých podkapitol v ně
kterých př
ípadech velmi odliš
uje.
1
Management Of Data & Information Systems, Institute for System Programming of the Russian Academy
of Science.
- 35 -
3.3.1
DBDOM
Základním principem XML databáze DBDOM je aplikace DOM v SQL na relač
ní
databázi, a vzhledem k tomu, že se jedná o aplikaci pracující s XML, tak užívá RDBMS
právěna XML.
DBDOM se od ostatních aplikací, které rovně
žně
jakým způsobem využívají DOM, liš
í
př
edevš
ím tím, ž
e pomocí RDBMS dokáž
e ukládat data a zároveňuchovávat jejich
vzájemné vztahy. Ostatní aplikace totižpro stromovou strukturu DOM použ
ívají RAM
a pro vlastní uložení dat pak textové soubory (flat soubory), které jsou vhodné pouze pro
nevelkou manipulaci s daty a malé množství už
ivatelů.
Pro efektivně
jš
í práci s databází je mož
né i zde využ
ít indexování a i dalš
í optimalizační
techniky.
DBDOM dokáže využ
ívat knihovny programovacího jazyka Java implementující DOM.
Tato rozš
íř
ení zahrnují i JDBC a umožňují tak veš
kerou práci s daty pomocí SQL.
DBDOM můž
e pracovat nad jakýmikoli RDBMS, zatím jsou k dispozici verze pro
PostgreSQL, Oracle, DB2 a MS SQL-Server.
Tuto aplikaci vyvinul K. Ari Krupnikov z mezinárodní skupiny vývojář
ůITER.
Zdroje: [19], [41]
3.3.2
dbXML
Databáze dbXML je nativní XML databáze, která je napsána v programovacím jazyce
Java. Pro její už
ívání je tedy nutné mít nainstalované Java 2 SDK 1.4.2 a vyš
š
í.
Vývoj dbXML zač
al koncem roku 1999, u zrodu stál Tom Bradford. V úplném poč
átku byl
dbXML psán v jazyce C++ a př
edpokládalo se, ž
e bude slouž
it pouze k ukládání XML
dokumentů. Teprve po roce se př
eš
lo k programovacímu jazyku Java a k modelu
klient/server. Na poč
átku roku 2001 byla verze 1.0 dbXML Core rozdělena na dvěč
ásti.
První část byla př
ejmenována na Xindice a darovaná Apache Software Foundation. Druhá
č
ást pak byla ponechána dbXML Group, která z ní mě
la vyvinout komerč
ní produkt. Což
se také podař
ilo. Tato „komerč
ní verze“ byla uveř
ejně
na i jako Open Source za podmínek
GNU General Public License (GPL).
- 36 -
V souč
asné dobětedy existují dvěverze tohoto programu, a to verze 1.0 a 2.0. Mezi obě
ma
tě
mito verzemi jsou znač
né rozdíly, protože verze 2.0 je, dalo by se ř
íct, úplným
př
epracováním verze př
edeš
lé. Celková architektura zůstala v podstatěstejná, a také
ně
které základní API jsou si velmi podobné, ale z vě
tš
íč
ásti je verze 2.0 úplněnovým
produktem.
Mezi hlavní novinky verze 2.0 patř
í:
 protokolování transakcí,
 tř
i typy zabezpeč
ení správců,
o NoSecurityManager
–
nezahrnuje
žádné
zabezpeč
ení
a
dovoluje
kterémukoli už
ivateli př
ístup k databázi,
o SimpleSecurityManager – pro př
ístup k databázi vyžaduje už
ivatelské
jméno a heslo,
o DefaultSecurityManager – jediný už
ivatel (správce), který má př
ístup
k databázi,
 webové služ
by,
 zlepš
ení funkcí př
íkazové ř
ádky,
 jednoduché už
ívání GUI Administratora,
 nová databáze API,
 zlepš
ení dotazování.
Verze 1.0 používala pro komunikaci klient/server systém CORBA, nově
jš
í verze užpro
tuto komunikaci volí webové služ
by (př
edevš
ím Labrador).
Pro práci s dbXML je mož
né využít tř
ech typůrozhraní:
 GUI Administrator,
 rozhraní př
íkazové ř
ádky,
 tř
ídy API.
Dokumenty, které jsou spravovány dbXML, jsou ř
azeny do kolekcí. Systém dbXML se
zamě
ř
uje spíš
e na vě
tš
í množství malých XML dokumentů, které jsou potom ukládány do
jednotlivých kolekcí. Shodná struktura jednotlivých dokumentův kolekcích není př
íliš
důležitá. Samozř
ejmě
, pokud bychom chtě
li vytvoř
it spíš
e relač
ní databázi, musely by této
podmínce odpovídat i dané soubory, ale př
edností dbXML je, ž
e právěstruktura
dokumentůmůže být v rámci jedné kolekce jakákoli. Úplněodliš
ná struktura dokumentů
- 37 -
se ale samozř
ejměodrazí na pozdě
jš
í kvalitězpracování a dotazování. Jedna kolekce může
souviset s různými indexy, rozš
íř
eními, triggery a jinými kolekcemi.
Databáze dbXML podporuje rozš
íř
ení různými knihovnami Javy, ale i scripty psanými
v JavaScriptu č
i Pythonu.
XML jazyky, které dbXML už
ívá, jsou: XPath, XSLT, XUpdate. K vyhledávání slov
v dokumentu využívá fulltextové vyhledávání.
dbXML můž
e pracovat v operač
ních systémech Mac OS (Mac OS X), Solaris, Linux,
Windows.
Zdroje: [32], [39], [42], readme.txt
3.3.3
myXMLDB
myXMLDB je XML databázový server realizovaný pomocí MySQL. Ukládá dokumenty
jako BLOB a můž
e pracovat s dokumenty ažo velikosti 256 MB. Pro podporu XPath
a XQuery využ
ívá procesor Saxon a poskytuje implementaci XML:DB API v Javě
. Má
grafické už
ivatelské rozhraní.
Práce s velkými dokumenty (vě
tš
ími než8 MB) je pro tento systém jedineč
ná. Vě
tš
ina
nativních XML databázových systémů, totižpouž
ívá DOM, cožneumož
ňuje zpracování
takto velkých dokumentů, protož
e je DOM velice nároč
ný na paměť
.
Zdroje: [26]
3.3.4
Ozone
Ozone je objektověorientovaný databázový systém vytvoř
ený v Javěa distribuovaný GNU
Library General Public License. Původní myš
lenka vytvoř
it takovýto systém vznikla
v druhé polovinědevadesátých let minulého století jako multimediální studijní projekt od
Falka Braeutigama. Oficiálněbyl databázový systém Ozone poprvé př
edveden v bř
eznu
roku 1999 a ješ
těv č
ervnu téhožroku zač
aly práce na vytvoř
ení rozš
íř
ení pro tento systém
nazvaném ozone/XML, které by umožňovalo spravovat XML data.
Základem ozone/XML je implementace DOM nad základní systém Ozone. Tato DOM
implementace, nazývána jako MonsterDOM, je specifikována W3C DOM Level 1, a je
- 38 -
mož
né ji aplikovat prostř
ednictvím DOM API nebo jazyka XPath. Výhodou využ
ití tohoto
modelu je to, ž
e využívá databázi k ukládání uzlů.
Poněvadž se jedná o objektově orientovaný databázový systém, pracuje Ozone
s dokumenty jako s objekty a každý uložený soubor zpracovává v objektověorientovaném
modelu.
Ozone není závislý na ž
ádné jiné databázi, ani na mapovacích technologiích. Má pouze
vlastní nástroje na ovládání klasických objektů Javy. V základní verzi, mimo
implementace DOM kompatibilní s W3C specifikací, zajiš
ť
uje podporu ODMG 3.0
standardu. Pro práci s XML obsahuje podpůrné tř
ídy pro softwarový procesor Xalan
a XML parser Xerces.
Vzhledem k tomu, že Ozone využ
ívá procesor Xalan, je pro dotazování využ
íván jazyk
XPath, který je ale bohuž
el jediným dotazovacím jazykem využívaným v tomto systému.
Zdroj: [45], [30], [27], [10]
3.3.5
Sedna XML DBMS
Sedna je nativní XML databázový systém, který byl vyvinut úplně od poč
átku
v programovacích jazycích C/C++ a Scheme1 . Jedná se o plnohodnotný databázový
systém, který podporuje dotazování, aktualizace, ACID transakce, zabezpeč
ení, apod. Byl
vyvinut týmem MODIS Institutu pro systémové programování ruské Akademie vě
d a je
dostupný pod Apache License 2.0.
Př
i návrhu a zpracování mě
la Sedna dva základní cíle:
 systém musí být plněfunkč
ní – to znamená, že musí obsahovat vš
echny nástroje
databázových systémů,
 systém musí být uzpůsoben práci s XML.
Z toho vyplývá tě
sné spojení databázového systému s jazykem XML.
Základem pro realizaci se stal jazyk XQuery 1.0 a jeho datový model. Pro podporu
aktualizace byl ješ
těpouž
it jazyk XUpdate.
1
Dialekt funkcionálního programovacího jazyka Lisp.
- 39 -
Architektura systému je znázorně
na na obrázku 3.1, ze kterého je patrná úroveň
jednotlivých součástí:
 regulátor (governer) slouž
í jako ř
ídící stř
edisko systému – registruje vš
echny
zbývající souč
ásti; ví s jakými databázemi se pracuje a dohlíž
í na provádě
ní
transakcí,
 posluchač (listener) buduje pro každého nového klienta složku př
ipojení
(connection) a nastavuje jejich vzájemné propojení. Př
i kaž
dém pož
adavku klienta
začít novou transakci se vytvoř
í slož
ka transakce (transaction). V této slož
ce se
uvádě
jí dílč
í složky provádě
ných požadavků:
o parser – př
etvoř
í dotaz na logickou reprezentaci, cožje strom podobný
XQuery,
o optimizer – př
ebírá logickou reprezentaci od parseru a formuluje plán
vyř
ízení dotazu – strom nízkoúrovňových operací nad fyzickou strukturou
dat,
o executor – interpretuje plán vyř
ízení.
Kaž
dý př
ípad je v manažeru databáze př
eveden na jednotlivou databázi. Manažer
databáze zahrnuje: index manager – sleduje indexy nad databází, buffer manager –
odpovídá za vazby mezi diskovou a operač
ní pamě
tí, transaction manager –
zabezpeč
uje korektnost soubě
žněprovádě
ných transakcí.
Obrázek 3.1: Architektura – Sedna XML DBMS (převzato z [28])
- 40 -
Organizace dat je ř
eš
ena tak, aby docházelo k efektivnímu vyhledávání i aktualizaci. Pro
popsání vztahůmezi blízkými uzly XML dokumentu (tj. rodič
, dítě
, sourozenci) jsou
využívány př
ímé ukazatele. Pro celkový popis dokumentu slouž
í strom, tedy popisné
schéma, které vzniká př
i ukládání a spoč
ívá ve shlukování uzlůz XML dokumentu podle
jejich pozic v popisném schématu dokumentu, které vychází z dat dokumentu
a př
edstavuje struč
ný a př
esný strukturovaný př
ehled (nejedná se o DTD, XML Schema,
apod.).
Pro administraci je mož
né využít př
íkazové ř
ádky.
Programátoř
i mohou využ
ít Java API, C API, Scheme API (Chicken, Gambit, PLT), PHP
API, Python API, .Net API, OmniMark API a dalš
í (využití client/server).
Sedna umož
ňuje spojení s dtSearch a s Apache HTTP serverem. Byla navrž
ena jako
univerzální software neomezující se na určitou platformu. V souč
asné doběje dostupná
v operač
ních systémech Windows (Windows XP, Windows 2000) a Linux (Linux x86
kernel verze 2.4 a vyš
š
í).
Zdroje: [18], [28]
3.3.6
Timber
Tento nativní XML databázový systém vyvinula „Database Group“ z Katedry
elektrotechniky a informatiky Michiganské univerzity. Projekt byl dotován IBM a National
Science Foundatin (grant: IIS-9986030 a IIS-0208852).
Obrázek 3.2: Architektura – Timber (převzato z [46])
- 41 -
Základní myš
lenkou projektu Timber 1 bylo vytvoř
ení XML databáze co nejvíce podobné
relační databázi. Jedná se tedy o systém, který využ
ívá stejné základní charakteristiky jako
relační databázový systém, včetněalgebry, optimalizátoru dotazůa př
ístupových metod
urč
ených pro správné zhodnocení dat.
Relač
ní algebru zde samozř
ejměnebylo možné využít, a proto se př
istoupilo k jakémusi
ekvivalentu algebry pro XML, k algebř
e TAX, která manipuluje se soubory stromů.
Základním problémem je ale komplikovaná a promě
nná struktura stromů a potíže
s organizací.
XML dokumenty jsou reprezentovány stromy a jsou ř
azeny do kolekcí, se kterými se
následněpracuje.
Timber podporuje dotazování ve standardu XQuery 1.0. Každý dotaz je rozebrán do
algebraické reprezentace a ta je následnězpracována optimalizátorem, jenžvybere vhodný
plán dotazu a dotaz vyhodnotí.
Protož
e XQuery nedovoluje aktualizace, poskytuje Timber vlastní rozš
íř
ení k XQuery,
např
. mazání, modifikace, vkládání elementů, uzlů. Mimo tě
chto funkcí pro rozš
íř
ení
XQuery Timber ješ
těumož
ňuje př
idávat XML dokumenty do souboru, který je jižuložený.
Nutná znalost př
esné struktury dokumentu pro zadání korektního dotazu (cožje typické
pro XQuery) také není podmiňující, byla totižvytvoř
ena funkce pro dotazování, která
povoluje i omezené znalosti struktury XML dokumentu a př
itom podává smysluplné
výsledky.
Uživatel tohoto systému má mož
nost využ
ití př
íkazové ř
ádky, GUI a rozhraní pro př
ístup
k Timberu př
es web.
Jako základní DBMS užívá Timber Shore, nebo je také mož
né použ
ít Berkeley DB.
Pro správné fungování systému je nutné mít:
a) Windows 2000 nebo Windows XP
b) Visual Studio 2002 nebo 2003
Zdroje: [46]
Timber je ve skuteč
nosti akronym pro: Tree-structured native XML database Implemented at the
University of Michigan by Bright :-) Energetic Researchers.
1
- 42 -
3.3.7
XDBM
XDBM je databáze navržená speciálněpro práci s XML daty. Jako verze 1.0 byla poprvé
př
edvedena v lednu roku 2000 společ
ností Bowerbird Computing. Tato společ
nost
spravuje XDBM a zároveň spolupracuje s externími vývojář
i, kteř
í se podílejí na
zdokonalování tohoto systému.
Př
edností tohoto systému je mož
nost využití ve vlastních softwarech. Je navržen tak, aby
umož
ňoval snazš
í práci s XML soubory v aplikacích, které tento formát podporují. Lehč
í
práci zaruč
uje př
edevš
ím:
 ulož
ení př
edem zanalyzovaného XML souboru – formátovací program nemusí př
i
práci nač
ítat celý soubor,
 vytvoř
ení spojového seznamu, který zajiš
ť
uje rychlejš
í a snadně
jš
í prohledávání,
 použ
ívání vyhledávacích funkcí, které umožňují už
ivatelům práci s libovolnými
č
ástmi XML dokumentu.
XDBM API je založeno na DOM standardu.
Bowerbird Computing vyvinul dalš
í aplikaci, která je využ
itelná pro XDBM. Jedná se
o freeDOM, cožje jakési rozhraní urč
ené pro tento systém, které může být využ
íváno
různými objektověorientovanými programovacími jazyky.
XDBM je urč
en pro operační systémy Linux a Windows (32bitové).
Zdroje: [22]
3.3.8
Xindice
Databázový server Xindice1 byl od základu navržen k ukládání XML dat. Je velice
flexibilní svým př
ístupem k datům – semi-strukturovaný př
ístup a model dat nezávislý na
schématu.
Xindice navazuje na projekt dbXML Core. Zdrojový kód tohoto projektu byl roku 2001
darován Apache Software Foundation. V souč
asné doběje k dispozici ve verzi 1.0.
Programovatelná API podporují DOM a SAX.
1
Správná výslovnost je [zýn-dý-čej].
- 43 -
Dokumenty se ukládají do kolekcí, které mohou být dotazovány jako celek. Je možné
vytvoř
it kolekce, jenžobsahují jen dokumenty stejného typu, nebo kolekce ukládající
vš
echny dokumenty společ
ně
. Kolekce se ukládají v hierarchii podobné souborovému
systému UNIX či Windows. Pro dotazování nad kolekcemi dokumentůa dokumenty se
použ
ívá XPath.
Za úč
elem zlepš
ení dotazování
nad velkým množstvím dokumentů je k dispozici
indexování elementůa atributů, cožmůže velice podstatným způsobem snížit č
as potř
ebný
k vykonání dotazu.
Také změna dat v kolekcích dokumentů, ani v dokumentech jednotlivých, není pro Xindice
neznámou, pro tento úč
el využ
ívá XUpdate.
Xindice server můž
e být zpř
ístupně
ný buďpomocí API, nebo z př
íkazové ř
ádky pomocí
př
íkazů. V souč
asné doběXindice nabízí tř
i mož
nosti API, které je možné využ
ít k vývoji
aplikací:
 XML: DB API – pro aplikace psané v jazyce Java; jedná se o koncept z 7. kvě
tna
roku 2001,
 Xindice XML-RPC API – pro zpř
ístpuně
ní Xindice jiným jazykům nežje Java,
 Core Server API – vnitř
ní Java API pro jádro databázového systému. Toto API je
už
ívané pro vybudování XML-RPC API a pro vlož
ení XML:DB API rozš
iř
ující
funkč
nost Xindice.
Př
íkazová ř
ádka má vš
echny nástroje, které poskytuje API.
Zdrojový kód Xindice je napsán v Javě
. Systém by mě
l tedy pracovat ve vš
ech operač
ních
systémech podporující JDK. Oficiální testování úspě
š
něprobě
hlo na tě
chto operač
ních
systémech: Linux, Windows (Windows NT), Solaris, Mac OS (Mac OS X).
Zdroje: [38], readme.txt
3.3.9
XpSQL
XpSQL je multifunkč
ní XML databázové prostř
edí užívající PostgreSQL. Tento systém
rozkládá XML dokumenty na č
ásti a PostgreSQL už
ívá k vytvoř
ení relací mezi tě
mito
č
ástmi.
- 44 -
Pro zpř
ístupně
ní dokumentůvyužívá:
 funkce DOM ke konstrukci a prozkoumání XML dokumentů,
 XPath k získávání informací z dokumentů,
 aktualizač
ní funkce pro modifikaci dokumentů.
Základní projekt byl sponzorovaný IPA v Japonsku roku 2002. Pozdě
ji byl vydaný pod
licencí GNU GPL.
Zdroje: [17]
Pozn. Databáze 4Suite, Berkeley DB XML a eXist budou popsány ažv př
ísluš
ných podkapitolách kapitoly 5
(Ukládání geodat do XML nativních databází), protož
e právětyto tř
i databázové systémy byly vybrány jako
vzorové pro ukládání geodat do XML nativních databází a tedy i podrobněji prozkoumány (instalace, funkce,
atd.).
- 45 -
4 GEODATA A XML
V oblasti geografických vě
d se pod pojmem geodata (nebo též geografická data,
geoprostorová data) rozumí data zahrnující zároveňpopisnou (atributovou) a prostorovou
slož
ku popisující objekty reálného světa. Př
esná definice podle ČSN EN ISO 19109 zní:
„Geografická data jsou data s implicitní nebo explicitní referencí k místu vztaž
enému
k Zemi.“
Geodata jsou zpracovávána v geografických informač
ních systémech (GIS), jejichž
hlavním úkolem je správa a následné zpracování tě
chto dat (např
. analýzy dat, tvorba
map).
Jižv polovině80. let minulého století doš
lo k velkému rozmachu GIS v oblasti komerční
sféry. A jak tomu bylo i v jiných oblastech, zač
ala se i oblast geografických vě
d potýkat
s nekompatibilitou jednotlivých formátůGIS aplikací. Po vzniku jazyka XML bylo zř
ejmé,
ž
e právětento jazyk může problémy s nekompatibilitou vyř
eš
it. Proto hned po vydání
prvního standardu zač
aly ně
které instituce (např
. OGC) pracovat na vývoji formátů
umož
ňující spravovat geografická data.
Asi nejznámě
jš
ím XML formátem pro správu geodat je GML (kapitola 4.1), z dalš
ích bych
uvedla cGML (kapitola 4.2), G-XML (kapitola 4.3), LandXML (kapitola 4.4), SOTF
(Spatial Object Transfer Format), …
Zdroje: [7], [8]
4.1 Geography Markup Language (GML)
V roce 1994 bylo za úč
elem definování jednotného výmě
nného formátu pro práci
s geodaty založ
eno OpenGIS Consorcium (OGC). Velký rozmach využívání jazyka XML,
jenžje pro jednotný výměnný formát velmi vhodný, vedl konsorcium k vytvoř
ení
značkovacího jazyka, který by umož
ňoval na bázi znač
kování správu geodat. Tímto
jazykem se stal Geography Markup Language (GML). Obecnělze ř
íci, ž
e GML je XML
aplikace určená pro modelování, transport a ukládání geografických informací, které
zahrnují mimo geometrie také vlastnosti geografických prvků.
- 46 -
Od verze 2.0 je GML napsán v XML Schema, první verze GML 1.0 z 20. dubna 2000 byla
definována pomocí DTD.
Do verze 3.0 byla geometrie omezena jen na tzv. jednoduché prvky (Simple Features), jež
byly definovány pouze dvourozměrnými souř
adnicemi a kř
ivky byly vytvář
eny lineární
interpolací. Pro znázorně
ní skuteč
ného svě
ta jednoduché prvky dostač
ovaly. Od verze 3.0
se vš
ak setkáváme mimo jednoduchých 2D lineárních prvků s prvky komplexními,
nelineárními,
s 3D
geometrií,
s prvky
s 2D
topologií,
sč
asovými
vlastnostmi,
s dynamickými prvky, mě
ř
ením, ... Rozvoj GML je patrný i ze schémat GML verze 3,
která jsou osmkrát vě
tš
í nežzákladní schémata GML verze 2. Původními schématy GML
byly geometry.xsd (zahrnuje geometrické slož
ky), xlink.xsd (poskytuje XLink vlastnosti
pro odkazování mezi elementy nebo dokumenty), feature.xsd (definuje jednotlivé prvky).
Tato tř
i základní schémata byla nahrazena schématy jako gml.xsd, observation.xsd,
dynamicFeature.xsd,
topology.xsd,
coordinateReferenceSystems.xsd,
feature.xsd,
valueObjects.xsd, grids.xsd, geometryComplexes.xsd, datums.xsd, a dalš
ími.
Protož
e je GML značkovacím jazykem, nepopisuje vlastnosti pro zobrazení. Pro vytvoř
ení
grafického výstupu je nutné GML soubor transformovat stylovým jazykem XSLT, ve
kterém si sám uživatel definuje v jaké formědojde k zobrazení – zda bude zobrazení
grafického rázu ve formátu SVG, X3D (eXtensible 3D Graphics) č
i VML (Vector Markup
Language) nebo bude zobrazení v textové podoběve formátu HTML, RTF či PDF.
Jazyk GML je hojněvyuž
íván po celém svě
těnapř
. ve Velké Británii, v Nizozemí,
v Kanadě- ani Česká republika není výjimkou (Český úř
ad zeměmě
ř
ický a katastrální
poskytuje v tomto formátu data ze ZABAGED – [15] ). Mnohdy se stal i základním
stavebním kamenem dalš
ího jazyka určeného pro práci s geografickými daty.
Zdroje: [14], [16], [44]
4.2 compact Geographical Markup Language (cGML)
cGML je XML specifikace vytvoř
ená CRS4 1 a zamě
ř
ená na poskytování digitálních map
na malých bezdrátových zař
ízeních. Tento jazyk byl testován na J2ME zař
ízeních (Nokia
1
Center for Advanced Studies, Research and Development in Sardinia.
- 47 -
7650, Nokia 3650, Nokia 6600 a Palm) a na PersonalJava PDA (Compaq iPAQ). První
model cGML byl vytvoř
en v ř
íjnu roku 2002, první veř
ejný koncept cGML schématu byl
uvolně
n v dubnu 2003 a od dubna roku 2004 se jižmůžeme setkávat s verzí 1.0.
cGML vychází z jazyka GML (Geogpraphy Markup Lanquage) př
edevš
ím pro jeho
platformní nezávislost a nenáročnost na hardware. Samotné využití GML v mobilních
zař
ízeních vš
ak není mož
né, a to pro jeho velikost, která by vyžadovala velkou paměť
a vlnový rozsah. Proto byly dlouhé GML tagy (znač
ky) nahrazeny tagy krátkými (tabulka
4.1), čímžse velikost souboru samozř
ejmězmenš
ila a náklady na pamě
ťa př
enosovou
rychlost klesly ažo 60 %.
GML
cGML
_FeatureCollection
_FeatureMember
LineStringMember
coordinates
FtCl
FtMb
LnStMb
cds
Tabulka 4.1: Srovnání GML a cGML tagů
Př
i aplikaci v mobilních zař
ízeních posílá klient cGML ž
ádost k serveru, ve které stanoví
absolutní souř
adnice zájmové plochy, referenč
ní systém, požadované rozliš
ení a název
vrstvy pro maximální definování. Tato žádost je pak př
evedena na datový model, který
pomocí WFS definuje GML dokument zájmového území. GML dokument je upraven pro
využití v mobilním zař
ízení a pomocí XSL transformace př
eveden na výsledný cGML
soubor. Vlastní zobrazení zajiš
ť
uje opě
t datový model, k ně
mužse data dostala př
es XML
parser. Už
ivatel pak s takto zobrazenými daty můž
e nakládat různým způsobem, např
.
ukládat, zvětš
ovat a zmenš
ovat, vybírat nebo vyhledávat body podle názvu, zjiš
ťovat
vzdálenost mezi dvěma body.
- 48 -
Obrázek 4.1: Architektura cGML – Klient/Server (př
evzato z [13])
Zdroje: [13]
4.3 Geospatial-eXtensible Markup Language (G-XML)
Jazyk G-XML vznikal pod záš
titou Database Promotion Center, Japan a neziskové
organizace, která je pod patronací japonského Ministry of Economy, Trade and Industry
(METI) od roku 1999. Hlavním cílem projektu G-XML bylo vytvoř
it protokol pro
kódování prostorových dat pomocí XML. Protož
e G-XML vznikal soubě
ž
něs jazykem
GML, snažili se japonš
tí vývojář
i o tě
snou spolupráci s OGC.
První verze tohoto jazyka, tedy verze 1.0, byla oficiálněuvedena na konci bř
ezna roku
2000 a měla č
tyř
i DTD schémata (Real World, Point and Direction, Semantic a Graphic …
obrázek 4.2). Druhá verze, verze 2.0, vyš
la jako nová JIS specifikace 25. srpna 2001. Úzké
spojení s GML mě
la vyř
eš
it verze 2.5, na které byly práce dokonč
eny v bř
eznu 2001.
Nejvě
tš
ího rozš
íř
ení se dočkala verze 3.0 z konce bř
ezna 2003, která mimo podpory GML,
umož
ňovala např
íklad využ
ití G-XML v mobilních telefonech nebo už
ivatelská rozš
íř
ení.
Poslední verze 3.1 byla jako specifikace vydána v dubnu roku 2004.
- 49 -
Obrázek 4.2: Struktura G-XML verze 1.0 (převzato z [20])
V Japonsku se tento jazyk neč
astě
ji využívá k navigaci už
ivatelůmobilních telefonů,
automobilůa v administrativě
.
Zdroje: [20], [21]
4.4 LandXML
Tvorbu jazyka LandXML má na starosti celosvětová organizace LandXML.org, která
vznikla v prosinci roku 1999 př
edevš
ím na popud firmy Autodesk a US DOT EAS-E(U.S.
Department of Transportation Engeneering and Survey – Exchange). V bř
eznu roku 2000
mě
la 26 členů. Postupem č
asu se tato organizace rozš
íř
ila po celém svě
tě
. Vř
íjnu roku
2006 měla již600 př
edstavitelůze 511 členských společ
ností a státních orgánůve 37
zemích svě
ta.
LandXML je specializovaný formát XML dat zaměř
ující se na stavební inž
enýrství a
správu měř
ených dat obvykle už
ívaných v územním plánování, př
i terénních úpravách,
v dálkovém průzkumu Zeměa v dopravním inženýrství. Obědosud vydané verze, tedy
verze 1.0 ze 17. č
ervence 2002 a verze 1.1 z 21. č
ervence 2006, splňují základní cíle
projektu, a to:
 umož
nit využ
ití v jakémukoli softwaru,
- 50 -
 vytvoř
it takový datový formát, který by umož
nil dlouholetou archivaci,
 vytvoř
it snadno zobrazitelný datový formát – data uložená ve formátu LandXML
lze pomocí XSL transformace zobrazit jakýmkoli způsobem.
Oběverze jsou vytvoř
eny takovým způsobem, aby už
ivatel nebyl omezen verzí, ve které
svá data spravuje, tj. data poprvé uložená ve verzi 1.1 lze zpracovávat ve verzi 1.0.
Schémovým jazykem je XML Schema.
V souč
asné doběpodporuje LandXML více jak 55 registrovaných softwarových aplikací,
např
. Autodesk, CAiCE, Carlson, Eagle Point, Leica GeoSystems, MicroSurvey, Trimble
Navigation, Tripod Data Systems, Topcon.
V praxi je tento jazyk využitý např
íklad pro katastrální systém Landonline na Novém
Zélandu a EPlan v Queenslandu v Austrálii, ve Slovinsku pro zobrazení 3D modelu silnic,
v USA pro Interactive Highway Safety Design Model (IHSDM).
Zdroje: [12], [14]
- 51 -
5 UKLÁDÁNÍ GEODAT DO XML NATIVNÍCH DATABÁZÍ
Výbě
r databází
Př
iř
eš
ení problematiky ukládání geodat do XML nativních databází bylo nutné v úplném
poč
átku vybrat zástupce nekomerč
ních XML nativních databází, poně
vadžnekomerč
ních
databázových systémůje poměrněvelký poč
et a zaobírat se každou databází by pro
názornost nemě
lo velký smysl.
Protož
e se jednotlivé databázové systémy liš
í př
edevš
ím typem, byla tato charakteristika
zvolena jako zásadní, a tak na základětypu doš
lo k výbě
ru kandidátů. V dalš
ím kroku byl
brán zř
etel na rozš
íř
enost a známost každého jednotlivého databázového systému, př
ič
emž
se samozř
ejměupř
ednostnily známě
jš
í a rozš
íř
eně
jš
í aplikace. V koneč
ném výsledku byly
vybrány č
tyř
i databázové systémy, ze kterých ale pouze tř
i mohly být použ
ity:
 4Suite (kapitola 5.2) jako zástupce objektově
-orientovaných databází,
 Berkeley DB XML (kapitola 5.3) jako zástupce databáze typu klíč
-hodnota,
 eXist (kapitola 5.4) jako zástupce databází s vlastním modelem, ježv rámci
nekomerčních XML nativních databází tvoř
í nejobsáhlejš
í skupinu.
Čtvrtým vybraným databázovým systémem, a tedy nakonec nepoužitým, byl DBDOM
jako zástupce relač
ních databází. Zač
átky práce s touto aplikací probíhaly bez jakéhokoli
problému. Po instalaci v systému PostgreSQL, který byl jedním z mož
ných systémů
využitelných pro chod databázového systému DBDOM, byla vytvoř
ena databáze, v nížse
automaticky vytvoř
ilo 19 tabulek a 57 funkcí urč
ených pro vkládání dat do př
ipravených
tabulek. V dalš
í fázi „vytvoř
ení XML dokumentu v databázi“ se jižvyskytly podstatné
problémy s př
eddefinovanými funkcemi, které se nepodař
ilo odstranit. Podle mého míně
ní
by ani př
i správné funkci vš
ech funkcí nebylo mož
né vlož
it jižexistující XML dokument,
anižby byla vytvoř
ena dalš
í, tj. 58, funkce, která by umožňovala, samozř
ejměs využitím
př
eddefinovaných funkcí, i tento způsob vlož
ení dat do databáze. Databáze DBDOM se tak
stala zcela nevyhovující a tudížnepouž
itelná.
DBDOM není jediným relač
ním databázovým systémem, dalš
ím, a zároveň také
posledním možným kandidátem této skupiny byl systém XpSQL. Nad operač
ním
systémem Windows se vš
ak tato aplikace nepodař
ila nainstalovat, a tak nakonec není
skupina relač
ních nekomerč
ních XML nativních databází bohužel zastoupena.
- 52 -
Geodata
Volba vhodného vzorku geodat pro ulož
ení do jižvybraných databázových systémůtaké
nebyla triviální záležitostí. Pro objektivní posouzení možnosti využ
ití XML nativních
databází v oblasti geografických vě
d bylo vhodné vybrat reálná data.
Západočeská univerzita spolupracovala př
i tvorběAtlasu mezinárodních vztahů, který
vznikal př
edevš
ím s využ
itím XML technologií. Zdrojová data pro tento atlas, která
pochází z databáze ESRI Data and Maps, byla tedy také v XML formátu, př
esně
ji ve
formátu JML1 (JUMP GML).
Protož
e zdrojová data Atlasu mezinárodních vztahůbyla př
ímo v XML formátu a jednalo
se o reálná data, bylo několik z tě
chto zdrojových souborůvybráno pro využití v nativních
databázích. Šest získaných souborů se nemusí jevit jako dostatečný počet, ale
jejich odliš
né, a ve tř
ech př
ípadech velmi velké, velikosti poskytnou podle mého názoru
dobrý nástin využití nativních XML databází v oblasti geografických vě
d.
Název souboru
Velikost souboru [B]
body_miny1.jml
body_miny2.jml
magda.jml
miny.jml
zbrojeni.jml
zbrojeni_popisky.jml
5 974
27 182
14 720 878
14 612 497
14 625 758
6 673
Tabulka 5.1: Velikosti použitých souborůs geodaty
Dotazování
Na vš
echny druhy dat lze v rámci běž
ných databázových systémůvytvář
et různé druhy
dotazů, jejichžvýsledkem je vž
dy výbě
r vš
ech dat splňujících urč
itou podmínku. Ani
geodata nejsou výjimkou.
Protož
e geodata obsahují atributovou a zároveňtaké prostorovou slož
ku (kapitola 4), lze
nad těmito druhy dat vykonávat v zásadětř
i druhy dotazů:
a) atributové dotazy – výsledkem těchto dotazůjsou vš
echny geografické objekty
splňující urč
itou vlastnost,
1
Tento formát má základ ve formátu GML (Geography Markup Language) a je využíván př
edevš
ím v rámci
Open Source programůJUMP a openJUMP. Soubory formátu JML mají v sobějižzabudovanou strukturu
dokumentu, tedy jakési schéma v úvodu vlastního dokumentu, narozdíl od klasických souborůve formátu
GML.
- 53 -
b) prostorové dotazy – výsledkem tě
chto dotazůjsou vš
echny geografické objekty
s určitou prostorovou závislostí,
c) kombinované dotazy – u tě
chto dotazů se zohledňuje prostorová př
ísluš
nost
s př
ísluš
ností atributovou.
Př
iř
eš
ení dotazůnad geodaty ve formátu XML by se mohl potř
ít rozdíl mezi jednotlivými
druhy dotazů, poně
vadžvš
echna data ulož
ená v XML souboru se jeví naprosto stejně(tj.
souř
adnice jsou pouhým textem, stejnějako název státu), a tak v př
ípaděprostorové slož
ky
není na první pohled patrné žádné prostorové urč
ení. V této práci vš
ak byly vytvoř
eny jak
atributové, tak prostorové dotazy, př
ič
emžza prostorové dotazy byly označ
eny vš
echny ty,
které se jakýmkoli způsobem dotýkaly geometrie č
i souř
adnic.
5.1 XQuery a XPath dotazy pro vybrané databáze
Dotazování nad geodaty v prostř
edí XML nativních databází je zř
ejmějediná oblast, ve
které se geodata od ostatních dat podstatněodliš
ují. Vzhledem k existenci prostorové
slož
ky roste i nároč
nost dotazů, obzvláš
těprostorových, které se samozř
ejměnad bě
ž
nými
daty nevytvář
ejí. Proto bylo nutné vytvoř
it ně
kolik jednoduchých i poně
kud slož
itě
jš
ích
dotazů, jak atributových, tak prostorových, aby bylo mož
né zhodnotit vhodnost využ
ití
dané databáze pro ukládání geodat.
Protož
e vě
tš
ina XML nativních databází podporuje dva základní dotazovací jazyky, XPath
a XQuery, vznikaly dotazy právěv tě
chto formátech, a to pomocí softwaru Altova XML
Spy® 2007 Enterprise Edition.
Prvotněbyly zformulovány dotazy v jazyce XQuery. Konečný poč
et těchto dotazůje
dvanáct – osm atributových dotazůa čtyř
i dotazy prostorové1. Z ně
kterých jednoduš
š
ích
dotazůpak vycházely obdobné dotazy v jazyce XPath, koneč
ný poč
et XPath dotazůje pět
– tř
i atributové a dva prostorové.
5.1.1
Atributové XQuery dotazy
Prvním atributovým dotazem, dále (XQ_1), je ř
ádkový dotaz nad kolekcí dokumentů
geodata, jehožvýstupem jsou vš
echny elementy property prvku (elementu feature),
který v elementu property obsahuje hodnoty „Czech Republic“ nebo „CZE“.
Prostorové dotazy byly vzhledem k vnitř
ní struktuř
e *.jml souborůvelmi časověnároč
né, proto byl jejich
poč
et omezen.
1
- 54 -
 atrib_dotaz_CR_radka.xquery ... (XQ_1)
collection("geodata")//feature[contains(property,("Czech
Republic","CZE"))] /property
Výsledek dotazu:
<property name="GMI_CNTRY">CZE</property>
<property name="CNTRY_NAME">Ceska republika</property>
<property name="miny">B</property>
<property name="CNTRY_NAME">Czech Republic
</property>
<property name="kod"/>
<property name="REGION">Eastern Europe
</property>
<property name="CONTINENT">Europe
</property>
<property name="FIPS_CNTRY">EZ</property>
<property name="GMI_CNTRY">CZE</property>
<property name="hustota">129.5</property>
<property name="CNTRY_NAME">Czech Republic
</property>
<property name="SOVEREIGN">Czech Republic
</property>
<property name="TAB1_COLOR">B</property>
<property name="TAB2_COLOR">C</property>
<property name="TAB3_COLOR">A</property>
<property name="TAB4_COLOR">B</property>
<property name="TAB5_COLOR">A</property>
<property name="TAB6_COLOR">C</property>
Dalš
ími dvěma dotazy jsou atributové dotazy se stejnou myš
lenkou, tedy i výsledkem, ale
pouze jinou strukturou. Jeden dotaz je opě
tř
ádkový a ve druhém je využit cyklus FOR.
Výstupem tě
chto dotazůjsou názvy vš
ech států, ježpatř
í pod suverenitu Spojeného
království.
 atrib_dotaz_UK_radka.xquery ... (XQ_2), atrib_dotaz_UK.xquery ... (XQ_3)
collection("geodata")//feature[property[@name="SOVEREIGN"]="United
Kingdom
"]/property[@name="CNTRY_NAME"]/text()
...
for $i in collection('geodata')//feature
where $i/property[@name="SOVEREIGN"] = "United Kingdom
return
$i//property[@name="CNTRY_NAME"]/text()
Výsledek dotazů:
Anguilla
Bermuda
Cayman Islands
Falkland Islands (Islas Malvinas)
Gibraltar
Guernsey
Man, Isle of
British Indian Ocean Territory
Jersey
Montserrat
Pitcairn Islands
- 55 -
"
St. Helena
South Georgia and the South Sandwich Is
Turks and Caicos Islands
United Kingdom
British Virgin Islands
Výstupem následujícího dotazu, dále (XQ_4), je výpis hodnot hustoty v intervalu (200;300),
př
ič
emžvýsledné hodnoty jsou seř
azené podle velikosti (order by).
 atrib_dotaz_hustota_200_300.xquery ... (XQ_4)
for $i in doc('magda.jml')//feature
where some $j in $i/property[@name ="hustota"] satisfies ($j > 200 and $j
< 300)
order by $i/property[@name ="hustota"]
return
$i/property[@name ="hustota"]/text()
Výsledek dotazu:
215.6
224.0
231.2
241.0
245.2
246.1
250.8
261.4
265.8
290.5
291.5
292.9
299.4
Dotaz k získání názvůvš
ech kontinentů(XQ_5) využ
ívá pro získání výsledku mimo jiné
odstraně
ní duplicit ( distinct-values()). Stejnějako dotaz př
edchozí ř
adí výsledné
hodnoty (order by).
 atrib_dotaz_kontinenty.xquery ... (XQ_5)
let $kontinenty :=
collection("geodata")//feature/property[@name="CONTINENT "]
for $kontinent in distinct-values($kontinenty)
order by $kontinent
return
$kontinent
Výsledek dotazu:
Africa
Antarctica
Asia
Australia
Europe
North America
Oceania
South America
- 56 -
Dalš
í dotaz (XQ_6) využ
ívá př
eddefinovaných funkcí pro získání průmě
ru, maximální
a minimální hodnoty. Tě
chto funkcí využ
ívá k získání průměrné, minimální a maximální
hustoty zalidně
ní svě
ta. Zároveňtaké vytvář
í nové elementy, do nichžjsou pomocí
konstruktorů({}) př
ísluš
né výsledky umístěny.
 atrib_dotaz_hustoty.xquery ... (XQ_6)
<prumer_hustota>{avg(doc("magda.jml")//feature/property[@name="hustota"])
}</prumer_hustota>,
<min_hustota>{min(doc("magda.jml")//feature/property[@name="hustota"])}</
min_hustota>,
<max_hustota>{max(doc("magda.jml")//feature/property[@name="hustota"])}</
max_hustota>
Výsledek dotazu:
<prumer_hustota>257.38804780876484</prumer_hustota>
<min_hustota>0</min_hustota>
<max_hustota>16717.9</max_hustota>
Následující atributový dotaz (XQ_7) vytvář
í nové elementy hustota s hustotou zalidně
ní
evropských států a v nich atributy stat (název evropského státu) a zkr (zkratka
evropského státu).

atrib_dotaz_hustota_Evropa.xquery ... (XQ_7)
where $i/property[@name ="CONTINENT"] = "Europe
"
return
for $j in doc('magda.jml')//feature
where
contains($j/property[@name="CNTRY_NAME"]/text(),substring($i/property[@na
me="CNTRY_NAME"]/text(),1,20))
return
element hustota {
attribute stat{$i/property[@name="CNTRY_NAME"]/text()},
attribute zkr {$j/property[@name="GMI_CNTRY"]/text()},
$j/property[@name="hustota"]/text()}
Výsledek dotazu (49 států):
<hustota stat="Albania
zkr="ALB">109.3</hustota>
<hustota stat="Andorra
zkr="AND">145.7</hustota>
<hustota stat="Austria
zkr="AUT">96.6</hustota>
.
.
.
<hustota stat="Czech Republic
zkr="CZE">129.5</hustota>
.
.
.
<hustota stat="United Kingdom
zkr="GBR">245.2</hustota>
"
"
"
"
"
- 57 -
<hustota stat="Ukraine
zkr="UKR">78.6</hustota>
<hustota stat="Russia
zkr="RUS">8.5</hustota>
"
"
Poslední atributový XQuery dotaz (XQ_8) je zároveňnejslož
itě
jš
ím atributovým dotazem.
Využívá už
ivatelem definovanou funkci, pomocí nížje schopen určit průmě
rnou hustotu
zalidně
ní jednotlivých kontinentů.
 atrib_dotaz_prum_hustota_svet.xquery ... (XQ_8)
declare function local:prum_hustota ($kontinent)
{avg(
for $i in doc('zbrojeni.jml')//feature
where $i/property[@name ="CONTINENT"] = $kontinent
return
for $j in doc('magda.jml')//feature
where
return
$j/property[@name="hustota"])
};
<prumer_hustota kontinent="Afrika">{
local:prum_hustota("Africa
")}
</prumer_hustota>,
<prumer_hustota kontinent="Antarktida">{
local:prum_hustota("Antarctica
")}
</prumer_hustota>,
<prumer_hustota kontinent="Asie">{
local:prum_hustota("Asia
")}
</prumer_hustota>,
<prumer_hustota kontinent="Australie a Oceanie">{
local:prum_hustota(("Australia
","Oceania
"))}
</prumer_hustota>,
<prumer_hustota kontinent="Evropa">{
local:prum_hustota("Europe
")}
</prumer_hustota>,
<prumer_hustota kontinent="Jizni a Severni Amerika">{
local:prum_hustota(("South America","North America"))}
</prumer_hustota>
Výsledek dotazu:
<prumer_hustota kontinent="Afrika">63.458064516129035</prumer_hustota>
<prumer_hustota kontinent="Antarktida">0</prumer_hustota>
<prumer_hustota kontinent="Asie">582.6472727272726</prumer_hustota>
<prumer_hustota kontinent="Australie a
Oceanie">56.806451612903224</prumer_hustota>
<prumer_hustota kontinent="Evropa">467.18163265306123</prumer_hustota>
<prumer_hustota kontinent="Jizni a Severni
Amerika">78.46666666666667</prumer_hustota>
- 58 -
5.1.2
Prostorové XQuery dotazy
Prvním prostorovým dotazem (XQ_9) je bě
ž
ný dotaz porovnávající, zda př
ísluš
ný element
obsahuje danou hodnotu. V naš
em př
ípadě
, zda element gml:coordinates obsahuje
souř
adnice "152.258246352413,4992.122441603189" .
Výsledkem
tedy bude
zjiš
tě
ní, jaký stát má ve svých hranicích dané souř
adnice.
 prostor_dotaz_souradnice.xquery ... (XQ_9)
declare namespace gml="http://www.opengis.net/gml";
let $souradnice := "152.258246352413,4992.122441603189"
where
some
$j
in
$i[property/@name="CONTINENT"]//gml:coordinates
satisfies contains($j/text(),$souradnice)
return
element stat{$i/property[@name!="kod"]}
Výsledek dotazu:
<staty>
<stat>
<property
</property>
<property
<property
</stat>
<stat>
<property
</property>
<property
<property
</stat>
</staty>
name="CNTRY_NAME">Czech Republic
name="REGION">Eastern Europe
name="CONTINENT">Europe
</property>
</property>
name="CNTRY_NAME">Germany
name="REGION">Western Europe
name="CONTINENT">Europe
</property>
</property>
U dalš
ího dotazu (XQ_10) by se dalo pochybovat o jeho zař
azení, v základu ř
eš
í pouze
poč
et výskytůurč
itého elementu (gml:MultiPolygon, gml:Polygon ), ale poně
vadžby
i tento dotaz mohl pomoci např
íklad př
i vyhledávání státůs komplikovanými hranicemi
(cožje jasná prostorová tématika), je zař
azen do skupiny prostorových dotazů.
 prostor_dotaz_multipolygony.xquery ... (XQ_10)
element multipolygony{
attribute celkovy_pocet {
count(doc("magda.jml")//feature[boolean(geometry/gml:MultiPolygon)]
)},
for
$i
doc("magda.jml")//feature[boolean(geometry/gml:MultiPolygon )]
return
element stat {
attribute pocet_polygonu {count($i//gml:Polygon)},
$i/property[@name="CNTRY_NAME"]/text()
}
}
- 59 -
in
Výsledek dotazu byl poněkud rozsáhlejš
í, pro př
edstavu je uvedena pouze zkrácená verze:
<multipolygony celkovy_pocet="114">
<stat pocet_polygonu="2">Antigua and Barbuda
</stat>
<stat pocet_polygonu="4">Azerbaijan
</stat>
<stat pocet_polygonu="2">Armenia
</stat>
.
.
.
<stat pocet_polygonu="5">Yemen
<stat pocet_polygonu="194">Russia
</stat>
<stat pocet_polygonu="6">Fiji
</stat>
</multipolygony>
</stat>
Poslední dva dotazy jsou jižklasickými prostorovými dotazy, ř
eš
ícími př
ímo ně
jaký
problém. Jejich zdrojový kód je poně
kud komplikovaně
jš
í, a č
as potř
ebný k vyhodnocení
i v bě
žném softwaru (nikoliv ješ
těv databázi) byl také velmi znač
ný – první z dotazů
potř
eboval na svůj průběh cca 5 min, druhý, ješ
těsložitějš
í pak č
as vysoce př
ekračující
30minutovou hranici.
První ze slož
itě
jš
ích dotazů(XQ_11) zjiš
ť
uje, jaké sousední státy má Česká republika. Za
dlouhý č
asový průběh dotazu mohou př
edevš
ím četná porovnávání hranič
ních souř
adnic
jednotlivých států.
 prostor_dotaz_sousedi.xquery ... (XQ_11)
<sousedni_staty nazev="Česká republika">
{
let
$retezec
:=
doc('magda.jml')//feature[property="CZE"]//gml:coordinates/text()
let $souradnice1_0 := substring($retezec,0,30)
for $k in (0 to string-length($retezec) idiv 40)
let
$souradnice1
:=
substring(substringafter(substring($retezec,$k*40,150),"
"),0,30)
let
$souradnice2
:=
substring(substringafter(substring($retezec,($k+1)*40,150),"
"),0,30)
where some $j in $i//gml:coordinates satisfies (
if($k = 0) then (contains($j/text(),$souradnice1_0) and
not(contains($j/text(),$souradnice2 )))
else(contains($j/text(),$souradnice1) and
not(contains($j/text(),$souradnice2)) ))
return
element nazev_statu {$i/property[@name ="CNTRY_NAME"]/text()}
}
</sousedni_staty>
- 60 -
Výsledek dotazu:
<sousedni_staty nazev="Česká republika">
<nazev_statu>Germany
<nazev_statu>Poland
<nazev_statu>Slovakia
<nazev_statu>Austria
</sousedni_staty>
</nazev_statu>
</nazev_statu>
</nazev_statu>
</nazev_statu>
Druhý slož
itý dotaz (XQ_12), který č
inil velké problémy i klasickému ne-databázovému
softwaru, ř
eš
í problematiku výskytu státův urč
itém okolí, př
esně
ji výskyt státůod urč
ité
souř
adnice v okruhu 1000 km. V tomto př
ípaděbyly vytvoř
eny dvěuž
ivatelsky definované
funkce, v nichžjedna je volána druhou. Toto ř
eš
ení kód znač
nězpř
ehlednilo ale ke
zrychlení rozhodněnedoš
lo. Velkou mě
rou se na dlouhém č
ase podílí prohledávání
a porovnávání vš
ech souř
adnic (pro kaž
dou dvojici souř
adnic X,Y muselo dojít k jejich
rozdě
lení a př
evedení na numerickou hodnotu) bez ohledu na to, že daný stát užnapř
íklad
svými souř
adnice podmínku splnil – č
ásteč
ným ř
eš
ením by mohlo být násilné ukonč
ení
cyklu v př
ípadě
, že tato situace nastane (tato myš
lenka se vš
ak nepodař
ila zrealizovat).
 prostor_dotaz_okruh_1000km.xquery ... (XQ_12)
declare function local:porovnani($retezec, $X_0 ,$Y_0 )
{
let $souradnice := substring(substringafter(substring($retezec,$k*40,150), "
"),0,35)
let $X := number(substring-before($souradnice,","))
let $Y := number(substring-after($souradnice,","))
where (($X - $X_0)*($X - $X_0) + ($Y - $Y_0)*($Y - $Y_0))<(1000*1000)
return
element souradnice{
attribute x {$X},
attribute y {$Y}}
};
declare function local:oblast($i, $X_0 ,$Y_0 )
{
for $LinearRing in $i/geometry//gml:LinearRing
let $retezec := $LinearRing//gml:coordinates/text()
return
local:porovnani($retezec,$X_0 ,$Y_0 )
};
let $X_0 := 500
let $Y_0 := 5000
return
element okruh_1000km{
attribute X_0 { $X_0 },
attribute Y_0 { $Y_0 },
return
if (boolean(local:oblast($i,$X_0 ,$Y_0 )))
- 61 -
then(
<nazev_statu>{$i/property[@name
/nazev_statu>
)
else ()
}
="CNTRY_NAME"]/text()}<
Výsledek dotazu:
<okruh_1000km X_0="500" Y_0="5000">
<nazev_statu>Albania
<nazev_statu>Austria
<nazev_statu>Belgium
<nazev_statu>Bosnia and Herzegovina
<nazev_statu>Byelarus
<nazev_statu>Bulgaria
<nazev_statu>Denmark
<nazev_statu>Czech Republic
<nazev_statu>France
<nazev_statu>Germany
<nazev_statu>Greece
<nazev_statu>Croatia
<nazev_statu>Hungary
<nazev_statu>Italy
<nazev_statu>Latvia
<nazev_statu>Lithuania
<nazev_statu>Slovakia
<nazev_statu>Liechtenstein
<nazev_statu>Luxembourg
<nazev_statu>Moldova
<nazev_statu>Macedonia
<nazev_statu>Montenegro
<nazev_statu>Netherlands
<nazev_statu>Poland
<nazev_statu>Romania
<nazev_statu>Slovenia
<nazev_statu>San Marino
<nazev_statu>Serbia
<nazev_statu>Sweden
<nazev_statu>Switzerland
<nazev_statu>Ukraine
<nazev_statu>Russia
</okruh_1000km>
5.1.3
</nazev_statu>
</nazev_statu>
</nazev_statu>
</nazev_statu>
</nazev_statu>
</nazev_statu>
</nazev_statu>
</nazev_statu>
</nazev_statu>
</nazev_statu>
</nazev_statu>
</nazev_statu>
</nazev_statu>
</nazev_statu>
</nazev_statu>
</nazev_statu>
</nazev_statu>
</nazev_statu>
</nazev_statu>
</nazev_statu>
</nazev_statu>
</nazev_statu>
</nazev_statu>
</nazev_statu>
</nazev_statu>
</nazev_statu>
</nazev_statu>
</nazev_statu>
</nazev_statu>
</nazev_statu>
</nazev_statu>
</nazev_statu>
Atributové XPath dotazy
První atributový XPath dotaz, dále (XP_1), vychází z prvního atributového XQuery dotazu
vyhledávajícího vš
echny elementy property týkající se České republiky. Tento dotaz je na
rozdíl od XQuery vztaž
en nikoli k celé kolekci dokumentů, ale pouze k jednomu
dokumentu (magda.jml), a proto je upravena i podmínka pro urč
ení správného elementu
feature, který se České republiky týká. Výsledek není výpis elementůproperty, ale
výpis př
ímo jejich hodnot.
 XPath_atrib_dotaz_CR_magda.txt ... (XP_1)
//feature[property=’CZE’]/property/text()
- 62 -
Výsledek:
EZ
CZE
129.5
Czech Republic
Czech Republic
B
C
A
B
A
C
Dalš
ím vhodným XQuery dotazem pro odvození dotazu XPath (XP_2) byl dotaz vypisující
názvy vš
ech státůpod suverenitou Spojeného království. XPath dotaz podává naprosto
stejný výsledek, opět pracuje s dokumentem magda.jml. Vzhledem k problémům př
i
dotazování v databázi 4Suite (více v podkapitole 5.2.3) je i v tomto dotazu podmínka pro
správné vyhodnocení odliš
ná od dotazu v XQuery.
 XPath_atrib_dotaz_UK_magda.txt … (XP_2)
//feature[contains(property[@name=’SOVEREIGN’],’Kingdom’)]/property[@name
="CNTRY_NAME"]/text()
Výsledek:
Anguilla
Bermuda
Cayman Islands
Falkland Islands (Islas Malvinas)
Gibraltar
Guernsey
Man, Isle of
British Indian Ocean Territory
Jersey
Montserrat
Pitcairn Islands
St. Helena
South Georgia and the South Sandwich Is
Turks and Caicos Islands
United Kingdom
British Virgin Islands
Posledním atributovým XPath dotazem (XP_3) je dotaz pro zjiš
tě
ní průměrné hustoty
světa. V jazyce XPath neexistuje žádná funkce pro př
ímé zjiš
tě
ní průmě
ru, proto je zde
využit klasický výpočet – souč
et vš
ech hodnot hustoty je vydě
len poč
tem uzlůs hustotou
zalidně
ní.
 XPath_atrib_dotaz_prum_hustota_sveta_magda.txt ... (XP_3)
sum(//feature/property[@name=’hustota’])div(count(//feature/property[@nam
e=’hustota’]))
- 63 -
Výsledek:
257.3880478087649402390438247011952
5.1.4
Prostorové XPath dotazy
Pro odvození prostorových XPath dotazůbyly vhodné pouze dva jednoduš
š
í prostorové
dotazy XQuery, tj. dotaz zjiš
ť
ující státy, které obsahují ve svých hranič
ních souř
adnicích
urč
itou souř
adnici, a dotaz zabývající se element gml:MultiPolygon.
První z XPath dotazů(XP_4) je schopen vrátit naprosto totož
ný výsledek jako XQuery
dotaz, tedy výpis vš
ech států, které obsahují ve svých hranicích danou souř
adnici. Př
ed
vlastní aplikací XPath dotazu na dokument musí ale v rámci př
ísluš
ného databázového
systému př
edcházet definování jmenného prostoru (gml="http://www.opengis.net/gml"),
tato podmínka by vš
ak nemě
la č
init problémy.
 XPath_prostor_dotaz_souradnice_magda.txt ... (XP_4)
//feature[.//gml:coordinates[contains(.,’152.258246352413,4992.1224416031
89’)]]/property[@name=’CNTRY_NAME’]/text()
Výsledek dotazu:
Czech Republic
Germany
Druhý prostorový XPath dotaz (XP_5) jižs dotazem XQuery př
ílišspolečného nemá,
zjiš
ťuje pouze celkový počet elementůgml:MultiPolygon v dokumentu. I zde je nutná
deklarace jmenného prostoru gml.
 XPath_prostor_dotaz_multipolygony_magda.txt ... (XP_5)
count(//feature[boolean(geometry/gml:MultiPolygon)])
Výsledek dotazu:
114
5.2 4Suite … objektově
-orientovaná databáze
Obecné charakteristiky
4Suite, navrž
ený pro XML zpracování a správu objektověorientovaných databází, je
vyvinut př
edevš
ím firmou Fourthought, Inc.
- 64 -
4Suite umož
ňuje už
ivatelům využívat standardů XML a také např
íklad zdokonalit své
webové aplikace, protože podporuje mnoho metod pro př
ístup k datům, dotazování
a indexování.
Celý programový systém je vytvoř
en v programovacím jazyce Python s rozš
íř
eními
v programovacím jazyce C.
Podporuje vzdálený př
ístup pomocí HTTP, RPC, FTP
a CORBA. Je realizovatelný na platformách:
 POSIX - Linux, FreeBSD, OpenBSD, NetBSD, Solaris, Cygwin, Mac OS, atd.
 Windows - Windows 2000, XP nebo Server 2003; pro Windows 98, Me nebo NT
není účinnost programu garantována.
Pro správný chod programu musí být nainstalován Python 2.2.1 nebo nově
jš
í, a pro
př
ípadné zasahování do zdroje je nutný mít kompilátor jazyka C.
Základním prvkem 4Suite je knihovna nástrojů (vč
etně těch, které mohou být
implementovány i pomocí př
íkazové ř
ádky) pro XML zpracování, tj. DOM, SAX, XSLT,
XInclude, XPointer, XLink, XPath, XUpdate, RELAX NG a XML/SGML.
Pomocí 4Suite je tedy např
íklad mož
né:
 popsat dokument pomocí struktury DOM – tj. znázornit strukturu objektů, které
tvoř
í XML dokument,
 analyzovat dokument na základěsystému SAX,
 vytvoř
it XPath dotazy nad jižzanalyzovaným dokumentem,
 použ
ít XSLT a tedy využ
ít možnost vytvoř
it jinou strukturu vstupního XML
dokumentu,
 aktualizovat dokument pomocí XUpdate,
 zvalidovat dokument prostř
ednictvím RELAX NG.
Zdroje: [25], [37], [41], README.txt
5.2.1
Instalace
Jak jižbylo uvedeno výš
e, pro správný chod programu je nutné mít nainstalován
programovací jazyk Python, př
ič
emžkaždá verze 4Suite odpovídá urč
ité verzi Python.
Pro svoji práci jsem zvolila 4Suite verze 1.0b1 pro Python verze 2.3, protože tato verze
4Suite umož
ňuje také správu dokumentůa práci s RDF. Vyš
š
í a tedy i novějš
í verze tato
- 65 -
„rozš
íř
ení“, která byla ve starš
ích verzích označována jako 4Suite Server (4ss), již
neobsahují.
Postup instalace:
a) Instalace Python 2.3
Z internetové
adresy
http://www.python.org/download/releases/2.3/
jsem
stáhla
instalač
ní soubor Python-2.3.exe pro Windows, z č
ehožje zř
ejmé, ž
e jeho instalace
nebyla vůbec složitá.
b) Instalace 4Suite
Z adresy ftp://ftp.4suite.org/pub/4Suite/4Suite-1.0b1.win32-py2.3.exe jsem si stáhla
instalač
ní soubor a prostř
ednictvím instalátoru pro Windows jednoduš
e nainstalovala.
Pro využívání 4Suite Serveru je nutné nastavení konfiguračního souboru (4ss.conf), který
je umístě
n v …/Python23/Share/Settings/4Suite. Server můž
e pracovat na dvou různých
bázích. První způsob práce můž
e být vykonáván nad databázovým serverem PostgreSQL
a druhý pak využívá systému „FlatFile“. Tento způsob je sice pomalejš
í, ale stačí mu
pouze prázdný adresářa ně
jaké místo na disku.
c) Nastavení konfigurač
ního souboru
Konfigurač
ní soubor 4ss.conf obsahuje nastavení pro oba způsoby práce. Už
ivatel
pouze zakomentováním urč
í, zda bude využívat PostgreSQL č
i „FlatFile“. Já zvolila
druhou mož
nost, tedy „souborový“ způsob práce s 4Suite Serverem, protož
e ani
zbývající testované nativní XML databázové systémy (Berkeley DB XML, eXist)
nepracují
nad
jiným
databázovým
systémem.
Část
pro
PostgreSQL jsem
zakomentovala a následnějsem odstranila komentářz č
ásti určené pro „FlatFile“.
Posledním krokem př
ed uložením nového konfiguračního souboru bylo nastavení cest
pro PidFile a LogFile. Ukázka mého konfigurač
ního souboru je v př
íloze A
(Konfigurač
ní soubor „4ss.conf“).
5.2.2
Pracovní prostř
edí a základní funkce
Pracovat s databázovým systémem 4Suite lze dvě
ma způsoby, buď v prostř
edí
programovacího jazyka Python pomocí vestavěných knihoven a pro Python obvyklých
- 66 -
operací, nebo v klasické př
íkazové ř
ádce DOS s využ
itím nástrojůpř
ímo určených pro
př
íkazovou ř
ádku.
Vestavě
né knihovny se samozř
ejměpro mnou zvolenou verzi 4Suite od jiných verzí ve
svém obsahu liš
í, a to př
edevš
ím v poskytovaných funkcích jednotlivých modulů.
Poněvadžklasifikace jednotlivých modulůa jejich porovnání s jinými verzemi 4Suite je již
nad rámec mé práce, uvedu zde pouze pro př
edstavu 4 základní knihovny, ježmohou
obsahovat dalš
í moduly:
 Ft.Lib – různé knihovny, které je možné využ
ívat nezávisle na sobě
,
 Ft.Rdf – nástroje pro RDF zpracování, vč
etnědotazovacích jazyků,
 Ft.Server – umožňuje webový př
ístup,
 Ft.Xml – obsahuje dalš
í moduly pro práci s XML (např
. modul XUpdate, Xslt,
XPath, XPointer, XLink).
Python je bě
žněspustitelný pomocí:
 Nabídka Start => Programy => Python 2.3 => IDLE (Python GUI),
 Nabídka Start => Programy => Python 2.3 => Python (command line),
 C:\Python23\Python.exe.
Protož
e jsem pro svoji práci využívala př
edevš
ím klasické př
íkazové ř
ádky DOS, ukáži
pracovní prostř
edí Pythonu na jednoduchém př
íkladu vytvoř
ení XML dokumentu:
Obrázek 5.1: 4Suite – pracovní prostř
edí Python GUI
- 67 -
Výsledkem tě
chto programových př
íkazůje vytvoř
ení XML dokumentu „studenti.xml“
s následující strukturou:
<?xml version="1.0" encoding="UTF-8"?>
<studenti>
<student typ_studia="prezencni">
</student>
<student/>
</studenti>
Pro ukládání XML dokumentůdo databáze klasická př
íkazová ř
ádka plněvyhovuje, a to
díky nástrojům urč
eným př
ímo pro př
íkazovou ř
ádku:
 4xml – analýzy XML dokumentů, ...,
 4xpath – vyhodnocení výrazůXPath,
 4xslt – nástroj pro zpracování pomocí XSLT,
 4xupdate – XUpdate zpracování,
 4rdf – RDF/XML analýzy, dotazování, ...,
 4ss_manager – správa dokumentůa RDF zdrojů,
 4ss – př
íkazy už
ivatele na dokumenty a RDF,
 4versa – dotazovaní pomocí jazyka Versa1.
Vytvoř
ení kolekce dokumentůa operace s jižexistující kolekcí
Kolekce dokumentůje v př
ípadě4Suite označována stejnějako v Berkeley DB XML jako
kontejner. Vytvoř
ení první kolekce dokumentů musí př
edcházet inicializace 4Suite
Serveru. Protož
e nově
jš
í verze 4Suite mají pouze čtyř
i nástroje pro př
íkazovou ř
ádku
(4xml, 4xpath, 4xupdate, 4xslt) a neobsahují ani vestavě
né knihovny určené pro práci se
serverem a RDF (Ft.Server, Ft.RDF), nelze server jakýmkoli způsobem inicializovat a tedy
ani vytvoř
it kolekci dokumentů. Právěz tohoto důvodu jsem zvolila starš
í verzi, která
vytvoř
ení kolekcí dokumentůa zároveňjejich správu umožňuje.
4Suite Server lze zinicializovat následujícím způsobem:
...> 4ss_manager init
You are about to initialize 4Suite Server. This will erase ALL
DATA in the databases.
Are you sure (yes/no)? y
Add super user name (or just "enter" to pass): uzivatelske_jmeno
1
Speciální jazyk vytvoř
ený pro dotazování nad RDF daty. Př
estož
e byl pro vývoj tohoto jazyka velkou
inspirací jazyk XPath (Versa podporuje vš
echny XPath funkce), podobá se po své funkční stránce spíš
e
jazyku Lisp.
- 68 -
Password: heslo
Reenter password: heslo
Add super user name (or just "enter" to pass):
Installing Repository
Create Container: /ftss
Create Container: /ftss/users
Create Container: /ftss/groups
Create User: /ftss/users/h
docDef=None
Create Group: /ftss/groups/super-users
.
.
.
...>
Po úspě
š
nědokonč
ené inicializaci, která trvá ně
kolik minut, a spuš
tě
ní pomocí dalš
ího
př
íkazu:
...> 4ss_manager start
4SS Manager Name: uzivatelske_jmeno
Password for uzivatelske_jmeno:heslo
4ssd started (pid 1620)
lze využít pro práci s databázemi, správu serveru a uživatelůdalš
í pracovní prostř
edí, a to
GUI na URL: http://localhost:8800/.
Obrázek 5.2: 4Suite – GUI na URL: http://localhost:8800/
- 69 -
Pro vytvoř
ení kolekce dokumentůmůž
e už
ivatel využít:
 př
íkazové ř
ádky – 4ss create container /nazev (pro úspě
š
né vytvoř
ení
musí už
ivatel uvést své uživatelské jméno a heslo),
 GUI – v rozbalovacím menu č
ásti „Adding Content“ vybrat Container a potvrdit
tlač
ítkem „Add Resource“, následněstačí jen uvést název kontejneru a dojde
k vytvoř
ení.
Pro práci s kolekcí je mož
né opě
t použít př
íkazovou ř
ádku i GUI. Operace nad kolekcí
vš
ak v př
ípadě4Suite nejsou př
ílišrozsáhlé, mimo vytvoř
ení kolekce poskytuje v obou
pracovních prostř
edích pouze mazání stávající kolekce (4ss delete /nazev ).
Vkládání dokumentůdo kolekce dokumentůa operace s nimi
Vlož
ení dokumentůdo kolekce funguje na podobném principu jako př
i vytvoř
ení kolekce
dokumentů:
 pomocí
př
íkazové
ř
ádky
–
4ss
create
document
--type=...
/nazev_contejneru/nazev_dokumentu URI_zdrojoveho_dokumentu –
typem dokumentu (--type=...) můž
e být např
íklad XML dokument (xml),
XSLT
dokument
(xslt),
dokument
schémového
jazyka
Schematron
(schematron), RDF dokument (rdf),
 pomocí GUI – v rozbalovacím menu č
ásti „Adding Content“ vybrat př
ísluš
ný typ
dokumentu (XML Document, XSLT Document, DocumentDefinition, RDF
Document, File ) a potvrdit tlač
ítkem „Add Resource“, následněstač
í jen urč
it
zdroj dokumentu nebo dokument př
ímo vytvoř
it.
Operace s dokumenty jsou také velice omezené, obdobnějako u kolekcí, lze dokumenty
pouze mazat. V GUI je mož
né navíc využít editaci dokumentů.
Dotazování, aktualizace a transformace dat
Základním dotazovacím jazykem 4Suite je jazyk XPath, pro nějžje vytvoř
en vlastní
nástroj př
íkazové ř
ádky.
Obrázek 5.3: 4Suite – XPath dotazy
- 70 -
V rámci serveru lze ješ
těvyužít dotazovací jazyk Versa. Pro jeho využ
ití vš
ak musí
př
edcházet vytvoř
ení RDF dokumentu pro XML dokumenty. Dotaz je pak vykonán př
ímo
nad RDF dokumentem. Tuto informaci, kterou jsem získala z [29] se mi bohuž
el
nepodař
ilo ově
ř
it.
Pro aktualizaci dat lze ve 4Suite využ
ít jazyka XUpdate, který je plněpodporován. Stejně
jako XPath má i XUpdate vlastní nástroj př
íkazové ř
ádky. Pro aktualizaci dat pak stač
í
aplikovat
př
íkaz
4xupdate
--out-file=nazev_vysledneho_souboru
URI_zdroje_XML URI_souboru_XUpdate.
Naprosto stejným způsobem jako aktualizace probíhá transformace dat podporovaným
jazykem
XSLT
–
4xslt
--outfile=nazev_transformovaneho_souboru
URI_zdroje_XML URI_souboru_XSLT.
5.2.3
Geodata a 4Suite
Po úspě
š
ném zinicializování a př
ihláš
ení se k 4Suite Serveru jsem jižmohla př
istoupit
k vytvoř
ení kolekce dokumentůgeodata:
...> 4ss create container /geodata
4SS user name: zalbi
Password for zalbi:
Host (localhost):
Port (8803):
...>
Do vytvoř
ené kolekce jsem pomocí př
íkazové ř
ádky vlož
ila vš
echny JML dokumenty jako
XML dokumenty s př
íponou *.jml, což4Suite umož
ňuje:
...>
4ss
create
e:/Data/body_miny1.jml
Password for zalbi:
Host (localhost):
Port (8803):
document
–type=xml
/geodata/body_miny1.jml
...>
4ss
create
e:/Data/body_miny2.jml
Password for zalbi:
Host (localhost):
Port (8803):
document
–type=xml
/geodata/body_miny2.jml
...> 4ss create document –type=xml /geodata/magda.jml e:/Data/magda.jml
Password for zalbi:
Host (localhost):
Port (8803):
- 71 -
...> 4ss create document –type=xml /geodata/miny.jml e:/Data/miny.jml
Password for zalbi:
Host (localhost):
Port (8803):
...>
4ss
create
e:/Data/zbrojeni.jml
Password for zalbi:
Host (localhost):
Port (8803):
document
...>
4ss
create
document
e:/Data/zbrojeni_popisky.jml
Password for zalbi:
Host (localhost):
Port (8803):
–type=xml
–type=xml
/geodata/zbrojeni.jml
/geodata/zbrojeni_popisky.jml
...>
Př
i vkládání jednotlivých dokumentů nebylo mož
né rozpoznat rozdíl ve velikosti
vkládaných dokumentů, vš
echny dokumenty byly vlož
eny př
ibliž
něve stejném č
ase (cca
2 s). Pro ově
ř
ení správnosti vložení vš
ech dokumentů(vč
etnějejich velikosti) stač
ilo
využít GUI (obrázek 5.4).
Obrázek 5.4: 4Suite – kolekce dokumentů
- 72 -
Př
i dotazování jsem bohuž
el narazila na problém v př
ístupu ke kolekci dokumentů. Vlastní
vyhledání dokumentu v kolekci probě
hlo v poř
ádku, ale 4Suite Server nepracoval zř
ejmě
tak, jak by měl, a proto k vyhodnocení dotazu kvůli chyběnemohlo vůbec dojít:
...> 4xpath http://localhost:8800/geodata/magda.jml //feature
XML parse error in u’http://localhost:8800/geodata/magda.jml’ at line 7,
column 22: mismatched tag
...>
Protož
e 4Suite z dotazovacích jazykůpodporuje XPath, neměla by vytvoř
ená kolekce
dokumentůna průbě
h dotazování zř
ejměž
ádný vliv, také by se muselo pracovat pouze
s jednotlivými soubory, a proto jsem př
istoupila ke klasickému souborovému ulož
ení
dokumentůa XPath dotazy aplikovala na dokumenty ulož
ené v bě
ž
ném souborovém
systému.
Př
i dotazování nepodává 4Suite žádné informace o čase potř
ebném k vyhodnocení dotazu,
abych vš
ak získala př
edstavu o tomto údaji, měř
ila jsem průbě
h jednotlivých dotazůna
stopkách. Protože mohou být reflexy č
lově
ka zpož
dě
né, zopakovala jsem dotaz vž
dy
pě
tkrát a každý č
as jsem zaznamenala. Za výsledný č
asový údaj pak považuji průmě
rnou
hodnotu z namě
ř
ených hodnot.
I př
esto, že má databázový systém 4Suite normálněpodporovat XPath, vyskytly se př
i
testování jednotlivých XPath dotazůprávěv tomto systému problémy se znakovou sadou.
Př
i dotazování v této aplikaci bylo nutné nahradit uvozovky vymezující ř
etě
zce v dotazu
jednoduchými apostrofy, a pokud se v podmínce vyskytla mezera, bylo nutné př
istoupit
k jiné formulaci dotazu. Druhý př
ípad se týkal dotazu (XP_2), v ně
mžbyl původně
porovnáván určitý ř
etě
zec s „United Kingdom“ a nikoli jen s „Kingdom“. Kvůli porovnání
tohoto databázového systému s jinými vš
ak byly tyto změny natrvalo zohledněny u vš
ech
XPath dotazůurč
ených k testování.
Po odstraně
ní výš
e uvedených nedostatkůprobě
hlo testování vš
ech dotazův poř
ádku:
 (XP_1) – č
as potř
ebný k vyhodnocení dotazu = 2,078 s (mě
ř
ené č
asy: 2,14 s;
2,06 s; 2,04 s; 2,04 s; 2,11 s)
...> 4xpath e:/Data/magda.jml //feature[property=’CZE’]/property/text()
Result (XPath node-set):
========================
<Text at 0x01AFA800: u’EZ’>
<Text at 0x01AFA800: u’CZE’>
<Text at 0x01AFA878: u’129.5’>
<Text at 0x01AFA8F0: u’Czech Republic...\xc68\x00’>
<Text at 0x01AFA968: u’Czech Republic...\xc68\x00’>
- 73 -
<Text
<Text
<Text
<Text
<Text
<Text
at
at
at
at
at
at
0x01AFA9E0:
0x01AFAA58:
0x01AFAAD0:
0x01AFAB48:
0x01AFABC0:
0x01AFAC38:
u’B’>
u’C’>
u’A’>
u’B’>
u’A’>
u’C’>
...>
 (XP_2) – č
as potř
ř
ené č
asy: 2,81 s;
3,25 s; 2,14 s; 2,11 s; 2,11 s)
...> 4xpath e:/Data/magda.jml //feature[contains(property[@name=
’SOVEREIGN’],’Kingdom’)]/property[@name=’CNTRY_NAME’]/text()
========================
<Text at 0x01247BC0: u’Anguilla
...\u02d6H\x00’>
<Text at 0x01260AD0: u’Bermuda
...\u02d6H\x00’>
<Text at 0x0194BD28: u’Cayman Islands...\u02d6H\x00’>
<Text at 0x01B05440: u’Falkland Islan...\u02d6H\x00’>
<Text at 0x01B1B468: u’Gibraltar
...\u02d6H\x00’>
<Text at 0x01B1E288: u’Guernsey
...\u02d6H\x00’>
<Text at 0x01F6F968: u’Man, Isle of ...\u02d6H\x00’>
<Text at 0x01F77350: u’British Indian...\u02d6H\x00’>
<Text at 0x01F8C260: u’Jersey
...\u02d6H\x00’>
<Text at 0x021E5080: u’Montserrat
...\u02d6H\x00’>
<Text at 0x0238CEB8: u’Pitcairn Islan...\u02d6H\x00’>
<Text at 0x025A2BC0: u’St. Helena
...\u02d6H\x00’>
<Text at 0x02728850: u’South Georgia ...\u02d6H\x00’>
<Text at 0x02734BE8: u’Turks and Caic...\u02d6H\x00’>
<Text at 0x028F65D0: u’United Kingdom...\u02d6H\x00’>
<Text at 0x02925AF8: u’British Virgin...\u02d6H\x00’>
...>
 (XP_3) – č
as potř
ř
ené č
asy: 3,59 s;
2,43 s; 2,36 s; 2,39 s; 2,47 s)
...> 4xpath e:/Data/magda.jml sum(//feature/property[@name=’hustota’])div
(count(//feature/property[@name=’hustota’]))
Result (XPath number):
======================
257.388047809
...>
 (XP_4) – č
as potř
ř
ené č
asy: 4,24 s;
2,99 s; 2,97 s; 3,01 s; 3,00 s)
...> 4xpath --namespace=gml=http://www.opengis.net/gml e:/Data/magda.jml
//feature[.//gml:coordinates[contains(.,’152.258246352413,4992.1224416031
89’)]]/property[@name=’CNTRY_NAME’]/text()
========================
<Text at 0x01AFBAF8: u’Czech Republic...\u02d6H\x00’>
<Text at 0x01C62C10: u’Germany
...\u02d6H\x00’>
...>
- 74 -
 (XP_5) – č
as potř
ř
ené č
asy: 2,81 s;
1,67 s; 1,73 s; 1,63 s; 1,59 s)
...> 4xpath --namespace=gml=http://www.opengis.net/gml e:/Data/magda.jml
count(//feature[boolean(geometry/gml:MultiPolygon)])
Result (XPath number):
======================
114.0
...>
5.3 Berkeley DB XML … databáze typu klíč
-hodnota
Berkeley DB XML je nativní XML databáze, která pracuje s dokumenty ulož
enými do tzv.
kontejnerů1, v nichžje ve vě
tš
iněpř
ípadůješ
těuž
ité indexování pro snazš
í př
ístup k datům,
pomocí jazyka XQuery.
Berkeley DB XML byla napsána v jazyce C/C++ a vystavěna nad klasickou (ne XML)
databází Berkeley DB, ze které př
evzala veš
keré rysy a vlastnosti (ACID transakce,
automatické zotavování, zápis š
ifrovaných dat,
repliky, …), a zdokonalila př
idáním
urč
itých rozš
íř
ení (parsery, indexování, XQuery,...) její funkci. Stejnějako Berkeley DB je
i Berkeley DB XML pouze knihovnou, která poskytuje pro vývojář
e programové API a př
i
svém „provozu“ nepotř
ebuje žádnou lidskou správu.
Obrázek 5.5: Architektura – Berkeley DB XML (převzato z [31])
1
Kontejner je ve skuteč
nosti kolekce XML dokumentůa informací o tě
chto dokumentech.
- 75 -
Obrovskou výhodou tohoto systému je mož
nost zpracování XML dat s daty, které
nevycházejí z XML standardů. Př
irozené ukládání a zpě
tné získávání XML i ne-XML dat
je provádě
no stejnými operacemi pro oba typy těchto dat – není vyž
adováno ž
ádné
mapování ani jiné př
etvář
ení dat. Také nabízí dvěmožná ř
eš
ení pro ukládání velkých
dokumentů. Dokumenty mohou být ponechány neporuš
ené, bez jakéhokoli dě
lení (zde jsou
zachovávány „white space“), nebo mohou být „rozbity“ na jednotlivé uzly, př
ič
emžje
umož
něno úč
inné vyhledávání, a také částečná aktualizace dokumentu.
XML dokumenty jsou logicky seskupovány do kontejnerů, ve kterých je možné provést
validaci.
V rámci kontejneru umožňuje Berkeley DB XML různé způsoby indexování, které velkou
mě
rou usnadňují př
ístup k datům. Asi základním druhem je uzlové indexování, které
umož
ňuje snadné vyhodnocování dotazů nad velkými dokumenty. Tento způsob
indexování je standardněnastavený, ale jeho užití není povinné. Za zmínku stojí i flexibilní
indexování XML uzlů, elementů, atributůa metadat, ježmá také velký vliv na kvalitní
a rychlé vyhledávání dat. Dalš
ím typem indexu, který Berkeley DB XML užívá, je složený
index vytvář
ený v průběhu probíhání programu.
Dotazování pomocí jazyka XQuery je pro typ databází, které ř
eš
í Berkeley DB XML,
typické, stejnějako jazyk SQL pro relač
ní databáze. Dotazy mohou být realizovány
v rámci jednoho, nebo i více kontejnerů. Vš
echny dotazy jsou optimalizovány tak, aby
potř
eba programových aktivit byla co nejniž
š
í.
Berkeley DB XML podporuje XQuery 1.0 a XPath 2.0, XML Namespaces, XML Schema,
… a z programovacích jazykůpak C++, Java, Perl, Python, PHP, Tcl, Ruby, atd.
Maximální velikost zpracovávané databáze je 256 TB.
Berkeley DB XML můž
e být využívána v operač
ních systémech Windows, Linux, BSD,
Mac OS (Mac OS X), atd.
Zdroje: [31], [34], [35]
5.3.1
Instalace
Z adresy http://www.oracle.com/technology/software/products/berkeley-db/xml/index.html
stač
í stáhnout pouze uživatelem zvolenou verzi programu. Já jsem zvolila př
ímo instalační
- 76 -
program pro Windows dbxml-2.2.13.msi, tj. verzi 2.2.13, a pomocí instalač
ního průvodce
nainstalovala.
5.3.2
Pracovní prostř
Pracovním prostř
edím databáze Berkeley DB XML je pouze př
íkazová ř
ádka, která je vš
ak
vzhledem k př
ehlednosti nápově
dy a jednoduchosti př
íkazůplněpostač
ující. Spuš
tění
aplikace je možné dvojím způsobem:
 Nabídka Start => Programy => Berkeley DB XML 2.2.13 => Berkeley DB XML
Shell
 C:\Program Files\Sleepycat Software\Berkeley DB XML 2.2.13\bin\dbxml.exe
Obrázek 5.6 : Berkeley DB XML – pracovní prostř
edí
Pomocí nápově
dy lze jižs databázovým systémem pohodlněpracovat. Základní nápově
du
zobrazí př
íkaz:
dbxml> help
a jakoukoli dalš
í podrobně
jš
í nápově
du k jednotlivým př
íkazům umož
ňuje pouhé doplnění
daného př
íkazu za výraz help:
dbxml> help createContainer
Základní nápově
da zobrazí vš
echny dostupné funkce (př
íkazy) databázového systému
i s jednoduchým popisem.
- 77 -
Obrázek 5.7: Berkeley DB XML – nápově
da
Vytvoř
Pozn. Jak jižbylo uvedeno výš
e Berkeley DB XML označ
uje jakoukoli kolekci dokumentůjako kontejner
(Container).
Vytvoř
ení kontejneru je základní počáteč
ní operací s tímto databázovým systémem.
Berkeley DB XML poskytuje čtyř
i možné způsoby vytvoř
ení kontejneru. Standardním
druhem kontejneru je kontejner pro uložení uzlů dokumentů s jejich indexováním
(createContainer
nazev_kontejnteru
nebo
in
createContainer
nazev_kontejneru), z č
ehožplyne jasné zamě
ř
ení na datověorientované dokumenty.
Dalš
í mož
ností pro datověorientované dokumenty je obdobný kontejner jako standardní
ovš
em bez indexování (createContainer nazev_kontejneru n). Pro dokumentově
orientované dokumenty jsou pak urč
eny př
edevš
ím poslední dva druhy kontejnerů, a to
kontejnery pro ukládání dokumentově orientovaných dokumentů bez indexování
(createContainer
nazev_kontejneru d)
nebo
s
uzlovým
indexování
(createContainer nazev_kontejneru id ).
Př
i tvorběkontejneru jakéhokoli druhu si už
ivatel může zároveňnadefinovat, ž
e vš
echny
soubory do tohoto kontejneru ukládané budou validovány – createContainer
nazev_kontejneru druh_kontejneru(n,in,d,id) validate .
S existujícím kontejnerem lze provádě
t jen ně
kolik operací:
 Otevř
ení – openContainer nazev_kontejneru .
 Př
eindexování – reindexContainer nazev_kontejneru d (př
eindexování
kontejneru
s indexováním
dokumentově
- 78 -
orientovaných
dokumentů),
reindexContainer
nazev_kontejneru
n
(př
eindexování
kontejneru
s uzlovým indexováním).
 Mazání – removeContainer nazev_kontejneru .
I př
i vkládání dokumentůexistuje více způsobů, jak tuto důlež
itou operaci provést.
Základní mož
ností je vlož
ení dokumentu vytvoř
ením dokumentu př
ímo v prostř
edí
Berkeley DB XML:
dbxml> putDocument nazev_dokumentu ‘
... XML dokument ... ‘ s
Obdobným způsobem je pak vlož
ení dokumentu získaného z dotazu XQuery:
dbxml> putDocument nazev_dokumentu ‘
... XQuery ... ‘ q
Posledním mož
ným způsobem vložení dokumentu je samozř
ejměvložení jižexistujícího
dokumentu:
dbxml> putDocument nazev_dokumentu adresa f
S dokumenty, jako takovými (nikoli s daty, ježzahrnují), lze nakládat pouze dvojím
způsobem:
 Opětovné získání uloženého dokumentu – getDocument
(získá vš
echny
dokumenty ulož
ené v otevř
eném kontejneru), getDocument nazev_dokumentu
– získané dokumenty lze zobrazit pomocí př
íkazu print.
 Odstraně
ní dokumentu – removeDocument nazev_dokumentu.
Aktualizace dat
Protož
e Berkeley DB XML nepodporuje jazyk XUpdate, má tento databázový systém
vlastní funkce určené k modifikaci a aktualizaci dat uvnitřdokumentůkontejneru:
 Vkládání uzlů – append XPath_vyraz
obsah_objektu
typ_objektu
insertAfter
(vloží
„do“
uzlu);
nazev_objektu
typ_objektu
insertBefore
obsah_objektu
XPath_vyraz
typ_objektu
nazev_objektu
XPath_vyraz
(vlož
í „př
ed“
uzel);
nazev_objektu
obsah_objektu (vlož
í „za“ uzel).
Pozn. typ_objektu = (element, attribute, text, comment, processinginstruction)
 Př
ejmenování uzlů– renameNodes XPath_vyraz nove_jmeno .
 Mazání uzlů– removeNodes
XPath_vyraz .
- 79 -
 Změ
na obsahu uzlů– updateNodes XPath_vyraz novy_obsah .
Dotazování
Podporovaným dotazovacím jazykem v rámci Berkeley DB XML je XQuery, a proto je
dotazování v tomto ohledu relativnějednoduché:
dbxml> query ‘
... XQuery ... ‘
Vlastní indexování
Berkeley DB XML umožňuje už
ivateli vložit vlastní způsob indexování, jenžmůže
významným způsobem ovlivnit č
as potř
ebný k vyhodnocení dotazu – addIndex
URI_jmenneho_prostoru_uzlu nazev_uzlu deklarace_indexu.
Indexy (deklarace_indexu) jsou specifikovány č
tyř
mi č
ástmi: typem cesty, typem uzlu,
typem klíč
e a jedineč
ností. Typ cesty může nabývat hodnot node č
i edge, typ uzlu node
nebo element , typ klíč
e presence, equality a substring a jedineč
nost none,
boolean, decimal , double , time, … např
. node-element-presence-node.
5.3.3
Geodata a Berkeley DB XML
Protož
e struktura souborůs geodaty je rozhodněbližš
í datověorientovaným dokumentům,
bylo v prvotní fázi př
i vytvář
ení kolekce dokumentůnutné zvážit pouze to, zda budou uzly
v kolekci indexovány či nikoli. Pro velké soubory (cca 50 MB) se indexování kvůli
dalš
ímu zvě
tš
ení souboru př
ílišnedoporuč
uje, takovou velikost ale zdrojové soubory
nemají, a proto jsem zvolila př
eddefinovaný typ kontejneru s indexováním, č
ímžse
celková velikost kolekce dokumentůvyš
plhala na 57 794 560 B.
dbxml> createContainer geodata.dbxml
Creating node storage container with nodes indexed
dbxml>
Podobnějako v databázovém systému 4Suite nerozliš
uje ani Berkeley DB XML neznámé
př
ípony souborů(*.jml). Vš
echny soubory byly tedy ulož
eny bez jakékoli změny v č
asech
nepř
esahujících ani u velkých souborů2 s.
dbxml> putDocument body_miny1 E:/Data/body_miny1.jml f
Document added, name = body_miny1
dbxml> putDocument body_miny2 E:/Data/body_miny2.jml f
Document added, name = body_miny2
dbxml> putDocument magda E:/Data/magda.jml f
Document added, name = magda
- 80 -
dbxml> putDocument miny E:/Data/miny.jml f
Document added, name = miny
dbxml> putDocument zbrojeni E:/Data/zbrojeni.jml f
Document added, name = zbrojeni
dbxml> putDocument zbrojeni_popisky E:/Data/zbrojeni_popisky.jml f
Document added, name = zbrojeni_popisky
dbxml>
Př
ed vlastním př
ístupem k dotazování bylo nutné spustit službu, kterou Berkeley DB XML
poskytuje, a to výpis protokolu průbě
hu dotazu, ve kterém je uveden i př
esný č
as nutný
k získání výsledku. Tento č
as je uvádě
n vž
dy š
estimístnou č
íslicí s oddě
lovač
em
desetinných č
ísel (nebo š
estimístnou číslicí bez oddě
lovač
e) v milisekundách.
dbxml> setVerbose 2 2
Protož
e Berkeley DB XML podporuje mimo XPath také dotazovací jazyk XQuery, bylo
mož
né v této databázi aplikovat vš
echny dotazy, XQuery i XPath. Automatický výpis
výsledku dotazu Berkeley neposkytuje, pro ověř
ení správnosti bylo nutné použ
ít př
íkaz
print. Vš
echny dokonč
ené dotazy podaly správné výsledky, jediné odliš
nosti se vyskytly
u dotazůs poč
etními úkony, kde byly výsledné hodnoty uvedeny na mnohem vě
tš
í poč
et
desetinných míst.
 (XQ_1) – č
as potř
ebný k vyhodnocení dotazu = 2 168,68 ms
dbxml> query ‘
collection("geodata.dbxml")//feature[contains(property,”Czech Republic”)
or contains(property,”CZE”)]/property ‘
Query - Starting eager query execution
Query - geodata.dbxml - U : [6] 2 3 4 5 6 7
Query - Finished eager query execution, time taken = 2168.68ms
18 objects returned for eager expression '
collection("geodata.dbxml")//feature[contains(property,”Czech Republic”)
or contains(property,”CZE”)]/property ‘
dbxml>
 (XQ_2) – č
as potř
dbxml> query ‘
collection("geodata.dbxml")//feature[property[@name="SOVEREIGN"]="United
Kingdom
"]/property[@name="CNTRY_NAME"]/ text()‘
collection("geodata.dbxml")//feature[property[@name="SOVEREIGN"]="United
Kingdom
"]/property[@name="CNTRY_NAME"]/ text()‘
dbxml>
- 81 -
 (XQ_3) – č
as potř
dbxml> query ‘
for $i in collection("geodata.dbxml")//feature
return
$i/property[@name="CNTRY_NAME"]/text()’
for $i in collection(“geodata.dbxml”)//feature
return
$i/property[@name="CNTRY_NAME"]/text()’
"
"
dbxml>
 (XQ_4) – č
as potř
ebný k vyhodnocení dotazu = 551,657 ms
dbxml> query ‘
for $i in doc("geodata.dbxml/magda")//feature
where some $j in $i/property[@name ="hustota"] satisfies ($j > 200 and $j
< 300)
order by $i/property[@name ="hustota"]
return
$i/property[@name ="hustota"]/text()’
Query - geodata.dbxml – D(‘magda’,U) : [1] 4
for $i in doc('geodata.dbxml/magda')//feature
... ’
dbxml>
 (XQ_5) – č
as potř
dbxml> query ‘
let $kontinenty := collection("geodata.dbxml")//feature/property[@name="CONTINENT"]
for $kontinent in distinct-values($kontinenty)
order by $kontinent
return
$kontinent‘
let $kontinenty := collection("geodata.dbxml")//feature/property[@name="CONTINENT"]
... ’
dbxml>
- 82 -
 (XQ_6) – č
as potř
dbxml> query ‘
<prumer_hustota>{avg(doc("geodata.dbxml/magda")//feature/property[@name="
hustota"])}</prumer_hustota>,
<min_hustota>{min(doc("geodata.dbxml/magda")//feature/property[@name="hus
tota"])}</min_hustota>,
<max_hustota>{max(doc("geodata.dbxml/magda")//feature/property[@name="hus
tota"])}</max_hustota>’
<prumer_hustota>{avg(doc("geodata.dbxml/magda")//feature/property[@name="
hustota"])}</prumer_hustota>,
... ’
dbxml>
 (XQ_7) – č
as potř
dbxml> query ‘
where $i/property[@name ="CONTINENT"] = "Europe
"
return
for $j in doc("geodata.dbxml/magda")//feature
where
return
element hustota {
attribute stat{$i/property[@name="CNTRY_NAME"]/text()},
attribute zkr {$j/property[@name="GMI_CNTRY"]/text()},
$j/property[@name="hustota"]/text()}’
.
.
.
... ’
- 83 -
dbxml>
 (XQ_8) – č
as potř
ebný k vyhodnocení dotazu = 226 688 ms
dbxml> query ‘
{avg(
for $i in doc("geodata.dbxml/zbrojeni")//feature
where $i/property[@name ="CONTINENT"] = $kontinent
return
for $j in doc("geodata.dbxml/magda")//feature
where
return
$j/property[@name="hustota"])
};
<prumer_hustota kontinent="Afrika">{
local:prum_hustota("Africa
")}
</prumer_hustota>,
<prumer_hustota kontinent="Antarktida">{
local:prum_hustota("Antarctica
")}
</prumer_hustota>,
<prumer_hustota kontinent="Asie">{
local:prum_hustota("Asia
")}
</prumer_hustota>,
<prumer_hustota kontinent="Australie a Oceanie">{
local:prum_hustota(("Australia
","Oceania
"))}
</prumer_hustota>,
<prumer_hustota kontinent="Evropa">{
local:prum_hustota("Europe
")}
</prumer_hustota>,
<prumer_hustota kontinent="Jizni a Severni Amerika">{
local:prum_hustota(("South America","North America"))}
</prumer_hustota>’
Query - geodata.dbxml – D(‘zbrojeni’,U) : [1] 6
Query - geodata.dbxml – D(‘zbrojeni’,U) : [1] 6
.
.
.
Query - Finished eager query execution, time taken = 226688ms
- 84 -
... ’
dbxml>
 (XQ_9) – č
as potř
dbxml> query ‘
let $souradnice := "152.258246352413,4992.122441603189"
where
some
$j
in
$i[property/@name="CONTINENT"]//gml:coordinates
satisfies contains($j/text(),$souradnice)
return
element stat{$i/property[@name!="kod"]}’
... ’
dbxml>
 (XQ_10) – č
as potř
dbxml> query ‘
element multipolygony {
attribute celkovy_pocet {
count(doc("geodata.dbxml/magda")//feature[boolean(geometry/gml:MultiPolyg
on)])},
for $i in doc("geodata.dbxml/magda")//feature[boolean(geometry/gml:Mu
ltiPolygon)]
return
element stat {
attribute pocet_polygonu {count($i//gml:Polygon)},
$i/property[@name="CNTRY_NAME"]/text()
}}’
... ’
dbxml>
 (XQ_11) – tento dotaz pro nedostatek pamě
ti nemohl probě
hnout
dbxml> query ‘
<sousedni_staty nazev="Ceska republika">
{
- 85 -
let $retezec := doc("geodata.dbxml/magda")//feature[property="CZE"]//gml:
coordinates/text()
let $souradnice1_0 := substring($retezec,0,30)
let $souradnice1 := substring(substring-after(substring($retezec,$k*40,15
0),"
"),0,30)
let $souradnice2 := substring(substring-after(substring($retezec,($k+1)*4
0,150),"
"),0,30)
for $i in doc(("geodata.dbxml/magda")//feature
where some $j in $i//gml:coordinates satisfies (
if($k = 0) then (contains($j/text(),$souradnice1_0) and not(contains($j/t
ext(),$souradnice2 )))
else(contains($j/text(),$souradnice1) and not(contains($j/text(),$souradn
ice2))))
return
element nazev_statu {$i/property[@name ="CNTRY_NAME"]/text()}
}
</sousedni_staty>’
.
.
.
stdin:256: query failed, Error: BaseMemoryManager::allocate(): Out of memory
dbxml>
 (XQ_12) – tento dotaz pro nedostatek pamě
ti nemohl probě
hnout
dbxml> query ‘
declare function local:porovnani($retezec, $X_0 ,$Y_0 )
{
let $souradnice := substring(substring-after(substring($retezec,$k*40,150
),"
"),0,35)
let $X := number(substring-before($souradnice,","))
let $Y := number(substring-after($souradnice,","))
where (($X - $X_0)*($X - $X_0) + ($Y - $Y_0)*($Y - $Y_0))<(1000*1000)
return
element souradnice{
attribute x {$X},
attribute y {$Y}}
};
declare function local:oblast($i, $X_0 ,$Y_0 )
{
for $LinearRing in $i/geometry//gml:LinearRing
let $retezec := $LinearRing//gml:coordinates/text()
return
local:porovnani($retezec,$X_0 ,$Y_0 )
};
let $X_0 := 500
- 86 -
let $Y_0 := 5000
return
element okruh_1000km{
attribute X_0 { $X_0 },
attribute Y_0 { $Y_0 },
for $i in doc("geodata.dbxml/magda")//feature
return
if (boolean(local:oblast($i,$X_0 ,$Y_0 )))
then(
<nazev_statu>{$i/property[@name ="CNTRY_NAME"]/text()}</nazev_statu>
)
else ()
}’
stdin:256: query failed, Error: BaseMemoryManager::allocate(): Out of memory
dbxml>
Aby byl průbě
h dotazování pomocí jazyk XPath korektní vůč
i databázovému systému
4Suite, byly vš
echny XPath dotazy př
evedeny na jednoduché XQuery dotazy, ke změně
doš
lo pouze definováním souboru, nad kterým tento dotaz má probě
hnout. Pokud by k této
úpravěnedoš
lo, neprobě
hl by žádný dotaz, protože databázový systém Berkeley DB XML
nerozpozná, k jakým datům se dotaz bez udání zdrojových dat vztahuje – nelze u ně
ho tedy
př
edpokládat, že bez udání zdroje by byl dotaz aplikován na celou aktuální kolekci.
Dalš
í korekce, která musela být v XPath dotazech provedena byla změna apostrofů,
označující ř
etě
zce, na uvozovky. Apostrof je v rámci Berkeley DB XML už
íván
k vymezení pole dotazu, proto použ
ití apostrofu uvnitřzdrojového kódu dotazu tento
systém nepovoluje.
 (XP_1) – č
as potř
ebný k vyhodnocení dotazu = 792,896 ms
dbxml> query ‘
doc("geodata.dbxml/magda")//feature[property="CZE"]/property/text()’
doc("geodata.dbxml/magda")//feature[property="CZE"]/property/text()’
dbxml>
 (XP_2) – č
as potř
ebný k vyhodnocení dotazu = 730,648ms
dbxml> query ‘
doc("geodata.dbxml/magda")//feature[contains(property[@name="SOVEREIGN"],
"Kingdom")]/property[@name="CNTRY_NAME"]/text()’
- 87 -
doc("geodata.dbxml/magda")//feature[contains(property[@name="SOVEREIGN"],
"Kingdom")]/property[@name="CNTRY_NAME"]/text()’
dbxml>
 (XP_3) – č
as potř
ebný k vyhodnocení dotazu = 1 406,54ms
dbxml> query ‘
sum(doc("geodata.dbxml/magda")//feature/property[@name="hustota"])div(cou
nt(doc("geodata.dbxml/magda")//feature/property[@name="hustota"]))’
sum(doc("geodata.dbxml/magda")//feature/property[@name="hustota"])div(cou
nt(doc("geodata.dbxml/magda")//feature/property[@name="hustota"]))’
dbxml>
 (XP_4) – č
as potř
ebný k vyhodnocení dotazu =1 735,60 ms
dbxml> query ‘
doc("geodata.dbxml/magda")//feature[.//gml:coordinates[contains(.,"152.25
8246352413,4992.122441603189")]]/property[@name="CNTRY_NAME"]/text()’
doc("geodata.dbxml/magda")//feature[.//gml:coordinates[contains(.,"152.25
8246352413,4992.122441603189")]]/property[@name="CNTRY_NAME"]/text()’
dbxml>
 (XP_5) – č
as potř
ebný k vyhodnocení dotazu = 593,325ms
dbxml> query ‘
on)])’
- 88 -
on)])’
dbxml>
5.4 eXist … databáze s vlastním modelem
Databáze eXist je celá napsána v programovacím jazyce Java. Může bě
žet jako nezávislá
databáze, nebo být vložena do jiné aplikace (knihovna Javy, webová aplikace).
Nejvě
tš
í důraz je kladen na účinné indexovězalož
ené dotazování. eXist byl navržen
kř
eš
ení XPath dotazůpř
i použ
ívání indexůpro vš
echny uzly typu element, text a atribut.
Vývoj této databáze zač
al v lednu 2001 a stále je zdokonalována.
Obrázek 5.8: Architektura – eXist (př
evzato z [4])
Data jsou ukládána do B+ stromů1 nebo stránkovacích souborů. Uzly jsou uchovávány
v DOM.
U dokumentů, se kterými eXist pracuje, není pož
adováno, aby splňovaly ně
jaké urč
ité
schéma nebo př
esný typ dokumentu. Toto opatř
ení vychází i z toho, ž
e mnoho dokumentů
nemá př
esné vymezení, nebo má DTD, ale bohuž
el, psaný pouze pro sebe.
1
B+ stromy jsou speciálním př
ípadem B stromů. Na rozdíl od B stromůmají vš
echna data ulož
ená v listech,
vnitř
ní uzly obsahují jen klíče a ukazatele. Vš
echny listy lež
í na stejné, nejniž
š
í, úrovni, zároveňjsou také
propojené spojovým seznam, cožumožňuje snadné vyhledávání.
- 89 -
Dokumenty jsou hierarchicky uspoř
ádané v kolekcích, jejich celkový poč
et je, dalo by ř
íci,
neomezený, poněvadžmaximální poč
et dokumentůukládaný do databáze je 231 . Každá
kolekce může obsahovat různé typy dokumentůo libovolné velikosti. Uživatelé se pak
mohou dotazovat na kolekci pomocí XPath, buďpodle jejího hierarchického uspoř
ádání,
nebo na vš
echny dokumenty v ní obsaž
ené.
Pro kvalitní dotazování použ
ívá eXist numerické indexování. Toto indexování umož
ňuje
odkazovat př
ímo na DOM uzly, ale také dokáž
e velice rychle odvodit vztah mezi
jednotlivými uzly, jako např
. vztah rodič
-dítě
, př
edek-potomek. Indexy jsou př
iř
azeny
vš
em prvkům v dokumentu, tj. elementům, atributům, textůi komentář
ů. Vš
echny indexy
jsou pak spravovány v databázi. Samozř
ejměje také mož
né omezit full-textové indexování
př
ímo na ně
jakou část dokumentu.
Dotazy jsou ř
eš
eny př
ímo podle XPath výrazu, který odkazuje př
ímo na urč
itý uzel
dokumentu, na rozdíl od obvyklých př
ístupů, kdy se strom dokumentu prochází zdola
nahoru nebo shora dolů.
eXist také umožňuje pomocí různých rozš
íř
ení full-textové dotazování, urč
ené př
edevš
ím
pro dokumentověorientované dokumenty.
Aktualizace je provádě
na pomocí XUpdate a aktualizač
ními rozš
íř
eními XQuery.
Databáze si vede „deník“ o provedených transakcích a pokud dojde k havárii, jsou
provedeny zapsané transakce a nedokonč
ené se odstraní.
Používané XML standardy, které tento systém využívá, jsou XQuery 1.0, XPath, XInclude
(ně
které prvky chybí), XPointer (z části), XSLT (př
es rozš
íř
ení XQuery), XUpdate.
K vývoji aplikací slouž
í XML DB:API.
Vzdálený př
ístup podporuje eXist pomocí HTTP/REST, XML-RPC, SOAP, WebDAV.
Operač
ním systémem, nad kterým by eXist mě
l pracovat, může být jakýkoli. Testy byly
provádě
ny v operačních systémech Linux, FreeBSD (verze 5.4 a 6.0), Solaris (Sun Solaris
10), Windows (Windows 2000, Windows XP, Windows XP Server Edition).
Zdroje: [4], [43]
- 90 -
5.4.1
Instalace
Na internetové adrese http://exist.sourceforge.net/index.html#download si uživatel může
zvolit verzi programu. Já jsem se rozhodla pro eXist verze 1.0 a proto jsem stáhla soubor
eXist-1.0.1-build4311.jar. (Pro spuš
tění instalač
ního programu je nutné mít Java 2 SDK
1.4.2 nebo vyš
š
í.). Dvojklikem na staž
ený soubor se spustí instalační průvodce, pomocí
ně
hožse jednoduš
e eXist nainstaluje.
Pro správné fungování programu jsem si nainstalovala Apache server. Využila jsem
jednoduchého způsobu: Na adrese http://www.slunecnice.cz/product/PHP-Triad/ jsem si
stáhla phptriad2-2-1.exe, cožje instalač
ní program, který nainstaluje webserver Apache
s podporou PHP a zároveňtaké databázový server MySQL.
5.4.2
Pracovní prostř
eXist poskytuje už
ivatelům dva druhy pracovního prostř
edí. Prvním jednoduš
š
ím
pracovním prostř
edím je webové rozhraní na http://localhost:8080/exist/, kde po př
ihláš
ení
jako administrátor databáze může uživatel vykonávat základní správu databáze
a jednoduché dotazování.
Obrázek 5.9: eXist – webové rozhraní
- 91 -
Druhým pracovním prostř
edím je administrátorské Java rozhraní, spustitelné př
es:

na http://localhost:8080/exist/index.xml,
 Nabídka Start => Programy => eXist XML Database => eXist Client Shell,
 C:\Program Files\eXist\start.jar,
které umožňuje více administrátorských č
inností, jako např
íklad nastavení zabezpeč
ení,
správu uživatelůči zálohování a obnovu dat. Po spuš
tě
ní si uživatel (klient) musí urč
it
způsob př
ipojení k databázi (obrázek 5.10). Jednou mož
ností je vzdálené př
ipojení
k serveru (Remote ) urč
eného URI v poli URL. Druhým způsobem je př
ipojení k databázi
v místním systému (Embedded), tedy př
ímo v systému klienta.
Obrázek 5.10: eXist – př
ipojení k databázi
Obrázek 5.11: eXist – Java rozhraní
- 92 -
V dalš
ím popisu se zamě
ř
ím pouze na administrátorské Java rozhraní, poněvadžoperace
př
es webové rozhraní jsou velmi podobné.
Vytvoř
Kolekci dokumentůvytvář
í eXist tř
emi možnými způsoby:
 př
íkazem v př
íkazové ř
ádce – mkcol „nazev_kolekce“,
 pomocí ikony,
 pomocí nástroje Create Collection v nabídce File.
Operace nad jižvytvoř
enou kolekcí, tj. mazání, př
ejmenování, kopírování a vkládání, jsou
stejné jako operace s ulož
enými dokumenty. Otevř
ení kolekce se provádí „dvojklikem“ na
př
ísluš
nou kolekci v poli s jednotlivými kolekcemi (popř
ípaděsoubory) nebo pomocí
př
íkazu cd „nazev_kolekce“.
Princip vkládání dokumentůje stejný jako př
i vytvář
ení nové kolekce dokumentů, tj:
 př
íkazem v př
íkazové ř
ádce – put „adresa_dokumentu“ ,
 pomocí ikony,
 pomocí nástroje Store files/directories v nabídce File.
Ostatní operace jako mazání, př
ejmenování, kopírování a vkládání lze realizovat př
es
nabídku File a př
ísluš
né nástroje nebo také pomocí př
íkazůzjiš
tě
ných pomocí „?“
v př
íkazové ř
ádce.
Stručný popis ikon
– umož
ňuje př
echod na kolekci „rodič
“.
– obnoví pohled na kolekci dokumentů.
– vytvoř
í novou kolekci dokumentů.
– vlož
í dokument/-y do kolekce dokumentů.
– odstraní vybrané dokumenty, kolekce dokumentů.
– umožňuje editaci vlastností vybraných dokumentů, kolekcí dokumentů(oprávnění
k už
ívání, vlastník, …).
– vytvoř
í zálohu.
- 93 -
– obnoví dokumenty ze zálohy.
– spravuje uživatele.
– zobrazí dotazovací dialog.
Dotazování a aktualizace dat
Podporovanými dotazovacími jazyky v eXist jsou XQuery a samozř
ejměXPath. Pro
vlastní aplikaci tě
chto dotazovacích jazykůje nejvhodnějš
í využití dotazovacího dialogu
(obrázek 5.12), který mimo jiné umož
ňuje otevř
ení jižexistujícího souboru s dotazem.
Obrázek 5.12: eXist – dotazovací dialog
- 94 -
Dotazovací dialog lze také aplikovat př
i aktualizaci pomocí rozš
íř
ení nad XQuery, které
umož
ňuje:
 vkládání – update insert „objekt“ (into | following | preceding)
„XPath_vyraz“,
 př
ejmenování – update rename „XPath_vyraz“ as „nove_jmeno“,
 nahrazování – update replace „XPath_vyraz“ with „objekt“,
 aktualizaci obsahu – update value „XPath_vyraz“ with „XPath_vyraz“,
 mazání – update delete „XPath_vyraz“.
Pro aktualizace pomocí jazyka XUpdate, který je podle [43] podporován, samozř
ejmě
nelze použít dotazovací dialog, protože jazyk XUpdate je od XQuery velmi vzdálený,
proto se využ
ívá klasické př
íkazové ř
ádky:
bin/client.bat –c /db/nazev_kolekce/nazev_dokumentu –X xupdate.xml
5.4.3
Geodata a eXist
Po př
ipojení k databázovému systému a následném vytvoř
ení kolekce geodata jsem již
mohla v klidu př
istoupit k ulož
ení dokumentůdo kolekce. Protož
e je pracovním prostř
edím
GUI, které využ
ívá běž
ných zvyklostí př
i vybírání, nač
ítání a otevírání souborů,
neoč
ekávala jsem žádné vě
tš
í komplikace. Bohužel se ale vyskytly př
i pokusu nač
tení
souboru s př
íponou *.jml (obrázek 5.13). Tuto př
íponu nebyl eXist ochoten akceptovat,
protož
e nepovaž
al tento soubor za XML dokument. Pro odstraně
ní této chyby stač
ilo
pouze uvést př
íponu *.jml v souboru „mime-types.xml“. Následněužnebylo ž
ádných
př
ekážek a vš
echny soubory byly v poř
ádku vloženy do př
ipravené kolekce.
Obrázek 5.13: eXist – chyba př
i ukládání souboru
- 95 -
Obrázek 5.14: eXist – kolekce dokumentů
Čas potř
ebný k ulož
ení různých souborůnebyl tak jednoznač
ný jako v př
ípaděpř
edchozích
dvou databázových systémů – č
as ulož
ení menš
ích souborů (body_miny1.jml,
body_miny2.jml, zbrojeni_popisky.jml) nepř
ekročil 2 s, ale vě
tš
í soubory (magda.jml,
miny.jml, zbrojeni.jml) potř
ebovaly ke svému ulož
ení cca 30 s.
Způsob dotazování byl v prostř
edí eXist velice triviální. V dotazovacím dialogu (obrázek
5.12) stač
ilo vždy jen nač
íst př
ísluš
ný xquery-soubor s dotazem a dotaz nechat proběhnout.
Ve spodním poli dialogu se objevil výsledek dotazu a čas bylo mož
né zjistit na spodní liš
tě
dialogu (obrázek 5.14). Vš
echny XQuery dotazy probě
hly a výsledky byly v naprostém
poř
ádku.
 (XQ_1) – č
as potř
ebný k vyhodnocení dotazu = 2 454 ms.
 (XQ_2) – č
as potř
ebný k vyhodnocení dotazu = 240 ms.
 (XQ_3) – č
as potř
 (XQ_4) – č
as potř
 (XQ_5) – č
as potř
 (XQ_6) – č
as potř
 (XQ_7) – č
as potř
- 96 -
 (XQ_8) – č
as potř
ebný k vyhodnocení dotazu = 1 257 899 ms.
 (XQ_9) – č
as potř
 (XQ_10) – č
as potř
 (XQ_11) – č
as potř
 (XQ_12) – č
as potř
Pro aplikaci XPath dotazůbylo nutné stejnějako v Berkeley DB XML upř
esnit zdrojový
soubor pro dotaz, ale v tomto př
ípaděto bylo nutné z důvodu, ž
e eXist XPath dotaz
zpracoval nad celou kolekcí, tudížse výsledné hodnoty liš
ily od př
edpokládaných hodnot
pro jeden soubor. Po zavedení definice žádoucího dokumentu byly vš
echny výsledky již
korektní.
 (XP_1) – č
as potř
 (XP_2) – č
as potř
 (XP_3) – č
as potř
 (XP_4) – č
as potř
 (XP_5) – č
as potř
Obrázek 5.15: eXist – ukázka vyhodnocení dotazu
- 97 -
5.5 Zhodnocení použ
itých databází
Na první pohled by se mohlo zdát, ž
e vš
echny použ
ité nativní XML databázové systémy
by bylo mož
né, samozř
ejměbez velkých nároků, využít pro ukládání jakýchkoli dat, tedy
i geodat. Vš
echny tř
i databázové systémy umožňovaly snadné vytvoř
ení kolekcí
dokumentů, podporovaly alespoňjeden dotazovací jazyk, aktualizace byla v systémech
také zajiš
těna (v ně
kterých databázích lépe, v jiných hůř
e) a ani správa dokumentů
a samotné databáze nebyla př
ílišzanedbána. Bohuž
el ale, tyto základní ukazatele neukazují
vhodnost dané databáze k využ
ití pro ukládání geodat.
5.5.1
ry o databázi 4Suite
Databáze 4Suite byla první
z aplikovaných databázových systémů. Její základní
nedostatek byl hned z poč
átku zř
ejmý – databáze 4Suite nepodporuje dotazovací jazyk
XQuery ani ž
ádný jiný obdobněvyvinutý dotazovací jazyk, proto nemůž
e př
i dotazování
poskytovat ani trochu podobné výsledky jako př
i dotazování v prostorových databázích.
Podporovaným dotazovacím jazykem je jazyk XPath, který by ale mohl být př
i
jednoduchých úkonech dostačující a ve spojení s 4Suite Serverem by mohl získávat
pohodlné výsledky. 4Suite Server sice umožňoval vytvoř
ení kolekce dokumentůa z č
ásti
i správu uložených dokumentů, ale bohužel nebylo mož
né této nadstavby využ
ít př
i vlastní
aplikaci dotazu, a tak mohly být dotazy aplikovány pouze na dokumenty ulož
ené
v bě
ž
ných souborových úlož
iš
tích.
Pro práci umožňoval 4Suite společ
něs 4Suite Serverem používat tř
i pracovní prostř
edí:
klasickou př
íkazovou ř
ádku, pracovní prostř
edí programovacího jazyka Python a GUI
serveru. Protož
e podle mého názoru nemusí být už
ivatel ani správce databáze zdárným
programátorem, testovala jsem 4Suite pouze v prostř
edí př
íkazové ř
ádky a GUI. Př
íkazová
ř
ádka byla pro práci, i př
es chudou nápovědu, př
íjemným pracovním prostř
edím bez
zjevných
nedostatků. V GUI
se
vyskytovaly
nesč
etné
problémy,
jako
jeden
z nejnápadně
jš
ích bych uvedla nemož
nost mazání ulož
ených dokumentů(tuto operaci bylo
mož
né provést pouze z př
íkazové ř
ádky), proto nebylo mož
né toto prostř
edí př
ílišvyužívat.
Obrovskou př
edností tohoto systému je podpora XSLT a XUpdate. Právědíky této velké
výhoděbych 4Suite pro ukládání geodat nezavrhovala, a pokud by bylo možné načítat
soubory i z kolekcí dokumentůna serveru (tuto skuteč
nost znemož
ňovala serverová
- 98 -
chyba), bych spíš
e vě
ř
ila, že by měl tento systém velkou budoucnost alespoňv oblastech
transformací XML souborůs geodaty.
5.5.2
ry o databázi Berkeley DB XML
Dalš
ím vybraným zástupcem z nativních XML databázových systémůbyl Berkeley DB
XML. Tato databáze je velice dobř
e uzpůsobená práci s různými XML i ne XML soubory
ulož
enými v kolekci dokumentů, cožby mohlo být velmi vhodné např
íklad ve spojení
geodat (ve formátu XML) s rastry.
Protož
e z dotazovacích jazyků podporuje Berkeley jak XPath, tak XQuery, může
teoreticky v dotazování, právědíky jazyku XQuery, podat také velmi dobré výsledky.
Z ostatních XML technologií, které se týkají ně
jakým způsobem př
ímo dokumentů,
nepodporuje Berkeley DB XML bohuž
el žádný, tedy ani XSLT ani XUpdate. Aktualizace
je zajiš
těna vestavěnými funkcemi a pro transformaci dat do jiné podoby musí kaž
dý
už
ivatel sáhnout do jiného systému. Pro geografická data je nemož
nost využ
ití XSLT dost
nevýhodná, ale pro celkové využ
ití Berkeley DB XML pro ukládání tě
chto dat zase není
prioritou, tudíži př
es tento nedostatek by mohla být databáze Berkeley DB XML pro
ukládání geodat snadno, a myslím si, že vcelku úspěš
ně, využ
ita.
Pracovní prostř
edí by se mohlo mnohým uživatelům jevit jako velice strohé, vš
ak se také
jedná pouze o prostř
edí př
íkazové ř
ádky, ale z vlastní zkuš
enosti mohu s klidným
svědomím tvrdit, že GUI je zde zcela zbyteč
né, protož
e díky kvalitní nápovědě
a jednoduchým vě
cným př
íkazům si každý uživatel brzy osvojí základní pracovní postupy
a zdánlivá poč
áteč
ní nepř
ehlednost zcela zmizí.
5.5.3
ry o databázi eXist
Poslední využ
itou nativní XML databází byla databáze eXist. Tento systém je jistěpro
už
ivatele na první pohled z hlediska pracovního prostř
edí nejpř
íjemně
jš
í. Dokumenty
ulož
ené v kolekcích jsou dobř
e viditelné, editovatelné, a způsob jejich nač
ítání či
odstraňování se ničím neliš
í od způsobu v
bě
žných programových vybaveních.
Nedostatečná nápově
da systému je nahrazena obrovským zázemím na webových
stránkách, kde se dá zjistit témě
řcokoli.
- 99 -
I pro uživatele pracujícího s geodaty by mohl být tento systém velice atraktivní, a to nejen
díky př
íjemnému pracovnímu prostř
edí. Jsou zde opět podporovány dva dotazovací jazyky,
XQuery a XPath, př
ičemžXQuery má v rámci eXistu dalš
í podstatná rozš
íř
ení umožňující
např
íklad aktualizace č
i transformace dokumentů. Jazyk XSLT je vš
ak tímto způsobem
zcela nahrazen a tedy bohuž
el dále jižnení nijak podporován.
5.5.4
Výsledky dotazování
Základním mě
ř
ítkem kvality nativního XML databázového systému pro ukládání geodat je
schopnost správně
, a pokud možno v co nejkratš
ím č
ase, vyhodnocovat atributové
a obzvláš
těpak prostorové dotazy.
Př
i vytvář
ení dotazůjsem získala př
ibližnou př
edstavu o tom, jak dlouho by mohl průbě
h
kaž
dého dotazu trvat. Nemohla jsem tedy oč
ekávat, že výsledky dotazů (XQ_11)
a (XQ_12) budou známy v ně
kolika málo sekundách, kdyžv nedatabázovém programu
vyhodnocení těchto dotazůbylo mě
ř
eno na minuty či desítky minut. Př
esto vš
ak zastávám
názor, ž
e vyhodnocení dotazu, které trvá více než10 sekund, není optimální. Bohuž
el ale,
jak je patrné z tabulky 5.2 uvádě
jící vš
echny časy XQuery dotazů odzkouš
ených
v databázích Berkeley DB XML a eXist (4Suite dotazovací jazyk XQuery nepodporuje!),
dotazůpř
ekrač
ujících 10vteř
inou hranici není málo.
Berkeley DB XML
(XQ_1)
2,169
2,454
2,130
0,240
1,898
68,538
0,552
4,286
1,473
0,661
1,716
0,271
46,160
289,816
226,688
1 257,899
2,415
9,543
1,054
0,531
atrib_dotaz_CR_radka.xquery
(XQ_2)
atrib_dotaz_UK_radka.xquery
(XQ_3)
atrib_dotaz_UK.xquery
(XQ_4)
atrib_dotaz_hustota_200_300.xquery
(XQ_5)
atrib_dotaz_kontinenty.xquery
(XQ_6)
atrib_dotaz_hustoty.xquery
(XQ_7)
atrib_dotaz_hustota_Evropa.xquery
(XQ_8)
atrib_dotaz_prum_hustota_svet.xquery
(XQ_9)
prostor_dotaz_souradnice.xquery
(XQ_10)
prostor_dotaz_multipolygony.xquery
(XQ_11)
prostor_dotaz_sousedi.xquery
(XQ_12)
prostor_dotaz_okruh_1000km.xquery
eXist
"out of memory"
2 028,918
"out of memory"
24 762,647
asy vyhodnocení XQuery dotazův sekundách
- 100 -
Protož
e kaž
dý dotaz má jinou strukturu a obědatabáze pracovaly př
i jejich zpracovávání
jiným způsobem, není mož
né najisto ř
íci, která z databází si poradila s vyhodnocením
XQuery dotazůlépe. Databáze Berkeley DB XML zpracovávala v koneč
ném výsledku
vš
echny dotazy v rychlejš
ím č
ase (tabulka 5.4) a rovnoměrně
ji (obrázky 5.15, 5.16), ale
nebyla schopna pro nedostatek pamě
ti vyhodnotit složité prostorové dotazy. Naproti tomu
databáze eXist ve svých výsledcích velice kolísala (obrázky 5.15, 5.16), ale dokázala
vyhodnotit dotazy vš
echny – otázkou vš
ak zůstává, zda výsledný čas dotazu (XQ_12)
6 h 52 min 42,647 s ( = 24 762,647 s) je v praxi akceptovatelný.
Pozn. Pro grafické znázornění č
asůvyhodnocení dotazůjsem z důvodu velkých rozdílůjednotlivých hodnot
použ
ila pro větš
í př
ehlednost na ose y logaritmické měř
ítko.
10000,00
Čas [s]
1000,00
100,00
10,00
1,00
0,10
(XQ_1) (XQ_2) (XQ_3) (XQ_4) (XQ_5) (XQ_6) (XQ_7) (XQ_8)
Berkeley DB XML
eXist
Obrázek 5.16: Grafické znázornění času vyhodnocení atributových XQuery dotazůjednotlivých
databází
100000,00
10000,00
Čas [s]
1000,00
100,00
10,00
1,00
0,10
(XQ_9)
(XQ_10)
(XQ_11)
Berkeley DB XML
(XQ_12)
eXist
Obrázek 5.17: Grafické znázornění č
asu vyhodnocení prostorových XQuery dotazůjednotlivých
databází
- 101 -
1000,000
Čas [s]
100,000
10,000
(XQ_12)
(XQ_11)
(XQ_8)
(XQ_7)
(XQ_9)
(XQ_1)
(XQ_2)
(XQ_3)
(XQ_6)
(XQ_5)
(XQ_4)
0,100
(XQ_10)
1,000
Berkeley DB XML
asu vyhodnocení XQuery dotazůdabáze Berkeley DB XML –
seř
azeno vzestupně
100000
Čas [s]
10000
1000
100
10
1
(XQ_12)
(XQ_11)
(XQ_8)
(XQ_7)
(XQ_3)
(XQ_9)
(XQ_4)
(XQ_1)
(XQ_5)
(XQ_10)
(XQ_6)
(XQ_2)
0,1
eXist
asu vyhodnocení XQuery dotazůdatabáze eXist – seř
azeno
vzestupně
Vytvoř
ené XPath dotazy byly vyzkouš
eny ve vš
ech použitých databázových systémech.
Protož
e struktura tě
chto dotazůsi je mnohem bližš
í, nežtomu bylo u dotazůXQuery, bylo
jejich vyhodnocení v rámci jednotlivých databází velice podobné – z hlediska č
asu vš
ak
kvůli různým př
ístupům jednotlivých databází opě
t odliš
né. Např
íklad u databází 4Suite a
eXist bylo po srovnání č
asových hodnot podle velikosti dosaž
eno totožných výsledků
(obrázky 5.20, 5.22), tj. poř
adí dotazůse shoduje.
U těchto dotazůjižnedocházelo
k výkyvům, pouze databáze eXist vyhodnotila dotaz (XP_4) nad 10vteř
inovou hranici, což
byl celkověnejhorš
í dotaz celého testování XPath dotazů(13,389 s), který tomuto
databázovému systému velmi ovlivnil celkový č
as potř
ebný k vyhodnocení vš
ech XPath
dotazů(tabulka 5.4).
- 102 -
(XP_1)
XPath_atrib_dotaz_CR_magda.txt
(XP_2)
XPath_atrib_dotaz_UK_magda.txt
(XP_3)
XPath_atrib_dotaz_prum_hustota_sveta_magda.txt
(XP_4)
XPath_prostor_dotaz_souradnice_magda.txt
(XP_5)
XPath_prostor_dotaz_multipolygony_magda.txt
4Suite
Berkeley DB XML
eXist
2,078
0,793
0,074
2,484
0,731
0,108
2,648
1,407
0,138
3,242
1,736
13,389
1,886
0,593
0,058
asy vyhodnocení XPath dotazův sekundách
100
Čas [s]
10
1
0,1
0,01
(XP_1)
(XP_2)
4Suite
(XP_3)
(XP_4)
Berkeley DB XML
(XP_5)
eXist
Obrázek 5.20: Grafické znázornění času vyhodnocení XPath dotazův jednotlivých databázových
systémech
3,5
3
Čas [s]
2,5
2
1,5
1
0,5
0
(XP_5)
(XP_1)
(XP_2)
(XP_3)
(XP_4)
4Suite
ní č
asu vyhodnocení XPath dotazůdatabáze 4Suite – seř
azeno
vzestupně
- 103 -
2
Čas [s]
1,5
1
0,5
0
(XP_5)
(XP_2)
(XP_1)
(XP_3)
(XP_4)
Berkeley DB XML
Obrázek 5.22: Grafické znázornění času XPath dotazůdatabáze Berkeley DB XML – seřazeno
vzestupně
Pozn. Pro grafické znázorně
ní č
asůvyhodnocení dotazůna obrázcích 5.20 a 5.21 nemělo logaritmické
měř
ítko př
íliš
nou vypovídací hodnotu, proto jsem pouze v tě
chto dvou př
ípadech zvolila mě
ř
ítko klasické.
100
Čas [s]
10
1
0,1
0,01
(XP_5)
(XP_1)
(XP_2)
(XP_3)
(XP_4)
eXist
Obrázek 5.23: Grafické znázornění času XPath dotazůdatabáze eXist – seř
azeno vzestupně
Po dokonč
ení testování XQuery a XPath dotazůjsem dospě
la k závě
ru, ž
e ze vš
ech
použ
itých databází pracovala nejrychleji a nejstabilně
ji databáze Berkeley DB XML. Pro
ukládání geodat by vš
ak tato databáze zř
ejměmusela pracovat na výkonně
jš
ím poč
ítači,
aby dokázala vyhodnotit i složitějš
í dotazy. Databáze eXist sice byla schopná dokonč
it
vš
echny dotazy, ale celkový potř
ebný čas k jejich vyhodnocení je pro praktické využ
ití
(alespoňna počítač
i s podobnou konfigurací) př
ílišvysoký, cožje patrné z tabulky 5.4.
- 104 -
Databáze 4Suite dokázala vyhodnotit XPath dotazy velice spolehlivěa v podobných
č
asech, její využ
ití bych ale pro ukládání geodat pro nepodporu XQuery nevolila.
atributové XQuery dotazy
4Suite
Berkeley DB XML
eXist
x
4 min 42,786 s
27 min 4,165 s
prostorové XQuery dotazy
x
"nelze vyhodnotit"
7 h 26 min 41,639 s
Xpath dotazy
12,338 s
5,259 s
13,768 s
Tabulka 5.4: Sumarizace č
asůjednotlivých databází po vyhodnocení vš
ech dotazů
- 105 -
ZÁVĚR
Vzhledem k výsledkům, ke kterým jsem dospě
la, považ
uji využ
ití nativních XML databází
pro ukládání geodat na počítač
i s podobnou konfigurací (1,8 GHz, 768 RAM) jako ne př
íliš
vhodné. Pevněvě
ř
ím, ž
e na výkonně
jš
ích počítač
ích by např
íklad databáze Berkeley DB
XML byla schopná vyhodnotit vš
echny dotazy a databáze eXist by slož
itě
jš
í dotazy ř
eš
ila
poně
kud rychleji.
Negativní výsledky vš
ak neovlivnila pouze konfigurace počítač
e, hlavní př
íč
inou byla
podle mého názoru š
patná vnitř
ní struktura zdrojových dokumentů, kde obrovský poč
et
hranič
ních souř
adnic jednotlivých státůbyl uveden v jednom elementu s nadbyteč
nými
mezerami (pro jednu dvojici souř
adnic cca 25 mezer), proto k problémům docházelo
př
edevš
ím př
i prostorových dotazech, kde bylo nutné jednotlivé souř
adnice porovnávat.
Vlastní velikost souboru samozř
ejmětaké hrála významnou roli. S velkými velikostmi
souborůse vš
ak v oblasti geověd musí poč
ítat. Pro zmenš
ení velikostí by bylo možné
využít např
íklad binárního XML. Dalš
í možností by mohlo být nahrazení názvůelementů
kratš
ími názvy, č
ímžby se zmenš
il počet znakův souboru, a tím by klesla i jeho velikost.
Po optimalizaci struktury i velikosti jednotlivých souborůvě
ř
ím, že nativní XML databáze
by na výkonně
jš
ích poč
ítač
ích bylo mož
né v praxi využít. Jejich vlastnímu využ
ití by vš
ak
musel př
edcházet slož
itý výbě
r z existujících databází, protož
e pro geodata, jejich správu
a zpracování, by mě
la databáze podporovat co mož
ná nejvíce XML technologií, a to
př
edevš
ím dotazovací jazyky (zejména XQuery), transformač
ní jazyky a jazyky pro
aktualizaci.
- 106 -
Seznam použ
ité literatury a zdrojů
1. Použ
itá literatura
[1]
XML kompletní průvodce / Neil Bradley ; [př
elož
il Jiř
í Bráza]. -- 1. vyd. -- Praha
: Grada, 2000. -- 537 s. :. -- Kniha byla napsána a zformátována v programu
Microsoft Word 7 pro Windows 95. -- Slovníč
ek. -- ISBN 80-7169-949-7 (brož
.)
[2]
XML Bible / Elliotte Rusty Harold. -- Foster City : IDG Books Worldwide, c1999.
-- xxxiii, 1015 s. : il. ISBN 0-7645-3236-7 (brož
.)
[3]
XML v kostce : pohotová referenč
ní př
íruč
ka / Elliotte Rusty Harold, W. Scott
Means ; [př
eklad Martin Blažík]. -- Vyd. 1. -- Praha : Computer Press, 2002. -- xvi,
439 s. ;. -- ISBN 80-7226-712-4 (brož
.)
[4]
XML data management : native XML and XML-enabled database systems / Akmal
B. Chaudhri, Awais Rashid, Roberto Zicari, editors. -- Boston : AddisonWesley, c2003. -- xxxvi, 641 s. : il. ISBN 0-201-84452-4 (brož.)
[5]
Technologie XML / Irena Mlýnková ... [et al.]. -- 1. vyd.. -- Praha
: Karolinum, 2006. -- 186 s. :. -- (Uč
ební texty Univerzity Karlovy v Praze). -- 500
výt.. -- ISBN 80-246-1272-0 (brož.) :
[6]
Př
ednáš
ky z př
edmě
tu Databázové systémy 1 (KIV/DB1).
[7]
Př
ednáš
ky z př
edmě
tu Poč
ítač
ová kartografie (KMA/POK).
[8]
Př
ednáš
ky z př
edmě
tu Úvod do GIS (KMA/UGI).
2. Internetové odkazy
[9]
Bourret, Ronald. XML and Databases [online]. c2006 [cit. 2006-08-15].
<http://www.rpbourret.com/index.htm>
[10]
Braeutigam, Falko; Mueller, Gerd; Nyfelt, Per; Mekenkamp, Leo. Ozone Users
Guide. c2002,2003.
<http://sourceforge.net/project/showfiles.php?group_id=39695&package_id=14355
1&release_id=303748 ... user-guide.html>
[11]
Bř
íza, Petr. Kompletní průvodce XSLT – Úvod do problematiky [online]. c2004.
[cit. 2007-01-13].
<http://interval.cz/clanky/kompletni-pruvodce-xslt-uvod-do-problematiky/>
[12]
Crews, Nathan. LandXML.org 2006.
<http://www.landxml.org/Workshops/Workshops.htm ... LandXML.org_2006.ppt >
[13]
CRS4. The compact GML for mobile devices [online]. c2003-2005 [cit.
2007-01-23].
<http://www.crs4.it/nda/cgml/index.html>
- 107 -
[14]
Čerba, Otakar. Kapitola 1. XML formáty pro práci s geografickými daty [online].
c2005 [cit. 2007-01-23].
<www.gis.zcu.cz/studium/pok/Materialy/xml_geodata.html>
[15]
Český úř
ad země
mě
ř
ický a katastrální. Základní báze geografických dat
ZABAGED®.[cit. 2007-03-15].
<http://www.cuzk.cz/Dokument.aspx?PRARESKOD=998&MENUID=0&AKCE=
DOC:30-ZU_ZABAGED>
[16]
Dorninger, Peter. XML Technologies and Geodata.
<www.ipf.tuwien.ac.at/MarsExpress/docs/corp03/article0302.pdf >
[17]
GBorg. The xpsql Project [online]. C2000-2006 [cit. 2006-10-11].
< http://gborg.postgresql.org/project/xpsql/projdisplay.php>
[18]
Institute for System Programming RAS. SEDNA – Native XML Database System
[online]. c2003-2006 [cit. 2006-10-11].
< http://modis.ispras.ru/sedna/>
[19]
ITER. ITER[online].c2000[cit. 2006-09-05].
<http://dbdom.sourceforge.net/>
[20]
Japan Information Processing Development Corporation/ Database Promotion
Center, Japan. G-XML Milestones [online]. c1999-2006 [cit. 2007-01-23].
<http://www.dpc.jipdec.jp/gxml/contents-e/history.htm>
[21]
Japan Information Processing Development Corporation/ Database Promotion
Center, Japan. G-XML PROJECT HOMEPAGE [online]. c1999-2006 [cit.
2007-01-23].
<http://www.dpc.jipdec.jp/gxml/contents-e/>
[22]
Jupitermedia Corporation. Bowerbird Computing Release XDBM v1.0 [online].
c2006 [cit. 2006-10-11].
< http://www.internetnews.com/dev-news/article.php/278811>
[23]
Kosek, Jiř
í. Seriál o XML pro Sortwarové noviny [online]. c2000-2001 [cit.
2007-01-13].
<http://www.kosek.cz/clanky/swn-xml/index.html>
[24]
Kosek, Jiř
í. XSLT v př
íkladech [online]. c2000-2001 [cit. 2007-01-13].
<http://www.kosek.cz/xml/xslt/index.html>
[25]
Murthi, Vijay. Native XML Databases – A Review.
<http:// www-d0.fnal.gov/computing/grid/xml_database.pdf >
[26]
myXMLDB. myXMLDB[online]. c2005 [cit. 2006-10-11].
<http://myxmldb.sourceforge.net>
[27]
Nguyen Viet Cuong. XML Native Database Systems - Review of Sedna, Ozone,
NeoCoreXMS.
<http://swing.felk.cvut.cz/index.php?option=com_docman&task=doc_view&gid=5
&Itemid=62>
- 108 -
[28]
Особе
ннос
т
иСУБДSedna. XML-СУБДSedna: те
х
ниче
с
киеособе
ннос
тии
в
ариантыис
пол
ьз
ов
ания[online]. c1992-2006 [cit. 2006-10-11].
< http://www.osp.ru/text/302/185085/>
[29]
Ogbuji, Uche; Ogbuji, Chimezie. Develop Python/XML with 4Suite, Part 5: The
repository features. c2002.
<https://www6.software.ibm.com/developerworks/education/x-4suite5/x-4suite5a4.pdf >
[30]
OpenDEN. Ozone [online]. c2006 [2006-10-11].
<http://www.openden.com/viewprod.php?pid=66206319950&mcatid=4665173621
38&scatid=73478219916&set=>
[31]
Oracle. Sleepycat Products: Berkeley DB XML[online]. c2006 [cit. 2006-08-15].
<http://sleepycat2.inetu.net/products/bdbxml.html >
[32]
O’Reilly Media, Inc. Introduction to dbXML [online]. c2006 [cit. 2006-10-11].
<http://www.xml.com/pub/a/2001/11/28/dbxml.html>
[33]
SGML Users' Group. A Brief History of the Development of SGML [online]. c1990.
[cit. 2007-03-15].
<http://www.sgmlsource.com/history/sgmlhist.htm>
[34]
Sleepycat Software. Introduction to Berkely DB XML.
<http://www.oracle.com/technology/documentation/berkeley-db/xml/intro_xml/Berkeley
DBXML-Intro.pdf>
[35]
Stylus Studio® and DataDirect XQuery™. Berkeley DB XML [online]. c2004-2007
[cit. 2006-08-15].
<http://www.stylusstudio.com/dbxml.html>
[36]
Stylus Studio® and DataDirect XQuery™. SQL/XML Tutorial: SQL/XML, XQuery
and Native XML Programming Languages [online]. c2004-2007 [cit. 2007-01-15].
<http://www.stylusstudio.com/sqlxml_tutorial.html>
[37]
The Apache Software Foundation. 4SUITE.org [online].c2000 [cit. 2006-09-05].
<http://4suite.org/index.xhtml >
[38]
The Apache Software Foundation. Apache Xindice [online]. c2001-2003 [cit.
2006-10-11].
< http://xml.apache.org/xindice/index.html>
[39]
The dbXML Group, L.L.C.dbXML (Native XML Database)[online].c2000-2003[cit.
2006-09-05].
<http://www.dbxml.com/product.html>
[40]
The XML:DB Initiative. XUpdate – Working Draft [online]. c2000-2003 [cit.
2007-01-13].
<http://xmldb-org.sourceforge.net/xupdate/xupdate-wd.html>
- 109 -
[41]
Yang, Yu. Benchmarking of Native XML Database Systems.
<http://www.library.uow.edu.au/adt-NWU/uploads/approved/adtNWU20051004.101038/public/01Front.pdf >
[42]
dbXML 2.0 - An Introduction [online]. [cit. 2006-09-05]
<http://www.xml-training-guide.com/dbxml.html>
[43]
eXist – Open Source Native XML Databáze[online].[cit. 2006-09-05].
<http://exist.sourceforge.net/>
[44]
ISO/TC 211/WG 4/PT 19136: Geographic information – Geography Markup
Language (GML)
<http://portal.opengeospatial.org/modules/admin/license_agreement.php?suppress
Headers=0&access_license_id=3&target=http://portal.opengeospatial.org/files/inde
x.php?artifact_id=4700 ... GML-3.1.pdf>
[45]
Ozone [online].[cit. 2006-10-11].
<http://www.ozone-db.org/noframes/ozonies/ozonexml.html>
[46]
Timber [online]. Poslední aktualizace: 2006-05-09 [cit. 2006-10-11].
<http://www.eecs.umich.edu/db/timber/>
[47]
WIKIPEDIA [online]. [cit. 2007-05-11].
<http://www.wikipedia.org/>
- 110 -
Př
íloha A
Konfigurač
ní soubor „4ss.conf“
<?xml version='1.0' encoding='UTF-8'?>
<rdf:RDF xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'
xmlns='http://xmlns.4suite.org/4ss/properties#'
xml:base=''
>
<Core rdf:ID='Core'>
<SystemContainer>ftss</SystemContainer>

<Driver rdf:parseType='Resource'>
<rdf:type
resource='http://xmlns.4suite.org/4ss/properties#FlatFile'/>
<Root>xmlserver</Root>
</Driver>

<!-User, Password, Host, Port are optional.
SECURITY NOTE: All info is stored here in plain text!
Omit whatever optional fields you would rather be prompted for.
-->
<!-<Password>dbpwd</Password>
<Host>dbhost</Host>
<Port>dbport</Port>
</Driver> -->

<PidFile>c:/Python23/Scripts/tmp/4ss.pid</PidFile>
<LogFile>c:/Python23/Scripts/tmp/4ss.log</LogFile>


<LogLevel>debug</LogLevel>
</Core>
</rdf:RDF>
- 111 -
Př
íloha B
Struktura př
ilož
eného CD

Geodata ... š
est zdrojových souborůs geodaty ve formátu JML

NXD_instalace
o
4Suite ... instalač
ní programy NXD 4Suite a programovacího jazyka Python 2.3
o
Berkeley_DB_XML ... instalač
ní program NXD Berkeley DB XML
o
eXist ... instalač
ní program NXD eXist

Text_DP ... vlastní text diplomové práce ve formátu PDF

XPath_dotazy
o
atributove_dotazy ... tř
i atributové XPath dotazy ("*.txt")

o
prostorove_dotazy ... dva prostorové XPath dotazy ("*.txt")


vystupy_dotazu ... výsledky atributových XPath dotazů("*.txt")
vystupy_dotazu ... výsledky prostorových XPath dotazů("*.txt")
XQuery_dotazy
o
atributove_dotazy ... osm atributových XQuery dotazů("*.xquery")

o
vystupy_dotazu ... výsledky atributových XQuery dotazů("*.txt")
prostorove_dotazy ... č
tyř
i prostorové XQuery dotazy ("*.xquery")

vystupy_dotazu ... výsledky prostorových XQuery dotazů("*.txt")
- 112 -

Diplomová práce Ukládání geodat do XML nativních databází

Transkript

Podobné dokumenty

Zkratky

Seminár Java VIII

Implementace cásti jazyka XQuery v rámci projektu CellStore JanˇZák

Rezervace auta z Car Rate Features

XML - Západočeská univerzita