Poradí si moderní databáze s formátem XML?

Vpřípadě, že byste mohli udělat jednu jedinou věc, která by zlepšila integraci a zautomatizovala procesy se zákazník...


Vpřípadě, že byste mohli udělat jednu jedinou věc, která by zlepšila integraci
a zautomatizovala procesy se zákazníky a obchodními partnery, byla by to
nejspíš implementace XML. Formát XML se stal standardem pro výměnu informací
mezi rozdílnými systémy, neboť jej lze snadno transformovat do libovolného
formátu. V následujícím textu jsme se rozhodli zjistit, jak dobře si rozumějí
současné moderní databáze IBM DB2, Microsoft SQL Server, Oracle Database 10g a
Sybase ASE se strukturovanými dokumenty, které jsou dnes hnací silou obchodu.
Schopnost slučovat, provádět dotazování a transformaci přenášených dat s
relačními daty se stává pro firmy stejnou nezbytností, jako samotné datové
sklady. Dobrou zprávou je, že čtyři hlavní relační databáze, tj. Oracle
Database 10g, IBM DB2, Sybase ASE (Adaptive Server Enterprise) a Microsoft SQL
Server, jsou schopny nejen XML data ukládat, ale současně také skrýt velkou
část komplexní povahy práce s tímto formátem. V závislosti na tom, kterou ze
zmíněných relačních databází používáte, však mohou být XML funkce, jež budete
mít k dispozici, buď extrémně bohaté, nebo naopak omezené, a to v mnoha
důležitých aspektech.
Co dnes moderní XML databáze nabízí? Čtyři základní funkce: schopnost používat,
ukládat, prohledávat a vytvářet XML. A právě rozsah, ve kterém tyto čtyři
funkce databáze podporují, a metody, které k tomu využívá, vypovídají o
úspěšnosti implementace XML v dané databázi.
Podporu XML jsme zkoumali v Oracle Database 10g, IBM DB2 Universal Database
8.1, Sybase ASE 12.5.1 a Microsoft SQL Serveru 2000. Test byl zaměřen na import
XML souborů, možnosti ukládání dat, indexování a schopnosti dotazování a také
dostupné funkce pro vytváření XML. U jednotlivých aplikací jsme také hodnotili
snadnost, flexibilitu a rychlost, s níž databáze zvládaly nejběžnější XML
operace.
Pochopitelně, že výše uvedené produkty nabízejí kromě zpracování XML celou řadu
dalších funkcí. Hodnocení v recenzích by proto nemělo být chápáno jako celkové
hodnocení testovaných databází.

Dokumenty a tabulky
Relační databáze a XML dokumenty představují dva silné způsoby reprezentace
vztahu mezi údaji, nicméně jejich silné stránky se liší. Například položením
dotazu na identifikační číslo pacienta v relační databázi můžete rychle získat
údaje o tom, kdy pacient navštívil nemocnici, jaké u něj byly zjištěny choroby
a jaká byla naordinovaná léčba. Zmíněný dotaz vám ale pravděpodobně nepomůže
při otázkách typu, jaká léčba byla naordinována na tu kterou chorobu, kdy léčba
probíhala; ty totiž mohou nabídnout pouze XML verze těchto záznamů.
To, zda budete schopni zkombinovat přínosy relačních a XML dat, závisí na tom,
jak XML ukládáte. Existují tři metody fyzického ukládání XML údajů v relační
databázi: zpracování, nestrukturované a strukturované ukládání. Ukládání
zpracovaných dat a nestrukturované ukládání jsou užitečné metody, nicméně mají
jistá omezení. Strukturovaná metoda naproti tomu umožňuje využít síly jak
relačních dat, tak XML hierarchií.
Při metodě zpracování se data ukládají do sloupců relační databáze, ale jsou
zbavena své XML povahy, což znamená, že údaje o hierarchických vztazích mezi
údaji původního XML dokumentu jsou ztraceny. Tato metoda je užitečná tehdy,
pokud nepotřebujete data zachovat v XML formátu. Řekněme, že máte webovou
stránku, která zákazníkům umožňuje zadávat objednávky, které je třeba zpracovat
v celé řadě různých databázových systémů. Vytvoření XML souboru a jeho
zpracování těmito systémy ze sdíleného síťového prostředku bude pravděpodobně
nejefektivnější variantou, jak data bez chyb dostat tam, kam potřebujete.
Nestrukturovaná metoda využívá k ukládání celého XML dokumentu jako jediné
jednotky datového typu zvaného CLOB (Character Large OBject). Databáze to umí
již mnoho let a zacházejí takto s nejrůznějšími typy dokumentů nejedná se tedy
o žádnou novinku. Nestrukturované ukládání přináší omezené možnosti
vyhledávání, ale přesto je poměrně užitečné. Dotazy sice nelze pokládat, ale
struktura původních dat je zachována. Dobrým příkladem využití
nestrukturovaného ukládání XML by bylo třeba uchovávání originálů dokumentů
vyžadovaných zákonem. Pokud by například finanční instituce přijímaly dokumenty
o úvěrech ve formátu XML, mohly by takto vytvářet relační záznamy o každé
půjčce a v rámci těchto záznamů také ukládat originál žádosti o úvěr.
Strukturovaná metoda umožňuje ukládat XML data uvnitř databáze a zachovat
jejich hierarchii. Strukturované ukládání, nebo též ukládání nativního XML, je
cílem snažení každého výrobce. Nejzjevnějším přínosem zachování hierarchických
vztahů mezi XML údaji je možnost přijmout XML dokument, zkombinovat jej nebo
zpracovat s relačními údaji a získat výsledek ve formátu XML. Toho nelze
dosáhnout při využití samotného jazyka relačního dotazování.
Ze čtyř testovaných databází jedině Microsoft SQL Server 2000 nepodporuje
strukturované ukládání XML. Všechny čtyři produkty pak nabízejí možnost využít
výhod zpracování a nestrukturovaných metod, avšak přístup a nabízená
flexibilita se u testovaných databází značně liší.

Oracle nastavuje laťku
Oracle Database 10g představuje nové možnosti v oblasti podpory XML
technologie. Nabízí velmi bohaté funkce pro import, ukládání, dotazování a
vytváření XML dat. Poskytuje jak nativní, strukturované ukládání XML, tak
podporu pro nestrukturované ukládání a zpracování dokumentů. Database 10g
dovoluje získávat XML data ze souborů a spojovat je v pohledech s relačními
údaji. Ještě než se však rozhodnete pro upgrade, měli byste si uvědomit, že
většina těchto funkcí je k dispozici i v Database 9i.
Oracle Database umí číst a zapisovat do WebDAV (Web Distributed Authoring and
Versioning) úložišť, takže uživatelé mají k dispozici pěkný pohled na webové
složky XML dat, které mohou požadovat. Podpora WebDAV dovoluje správcům
nastavit přístup k tisícům a tisícům XML souborů, aniž by to vyžadovalo příliš
mnoho místa na disku. To je způsobeno tím, že WebDAV soubory, byť se jeví jako
běžné XML soubory, jsou ve skutečnosti pouze zástupci, tj. jsou dotazy, které
směřují zpět na databázi. Data, z nichž se tyto soubory skládají, se zhmotňují
teprve tehdy, jsou-li požadována při otevření souboru nebo když dochází k
jejich kopírování na jiné místo. Kromě WebDAV Oracle podporuje také přenos XML
dokumentů pomocí FTP a HTTP.
Zřejmě nejdůležitějším zlepšením Database 10g je vývoj XML schématu. Tato
funkce umožňuje implementovat změny XML schématu pomocí mapování stávajících
dat do nového schématu. Namísto nutného exportu a následného opětovného importu
veškerých XML dat tak postačí vytvořit styly XSLT (XSL Transformation), které
slouží k transformaci starých dokumentů na nové schéma. O zbytek se postará
databáze. Vývoj schématu ohromně usnadňuje správu XML dat, protože jestli mohou
správci považovat něco za zaručené, pak to jsou neustále se měnící požadavky.
Oracle Database 10g nabízí některé výborné možnosti pro ukládání XML dat.
Datový typ XMLType skrývá většinu složitostí ukládání a dotazování v XML
údajích, což správcům dovoluje zpracovávat data pomocí důvěrně známých SQL
nástrojů a postupů. Je například možné vytvořit XMLType tabulku nebo XMLType
sloupec uvnitř relační tabulky. Vytváření XMLType tabulek je způsobem, jak
implementovat strukturovanou metodu ukládání a zachovat XML hierarchii.
Vytváření XMLType sloupců v relačních databázích představuje způsob
implementace metody nestrukturovaného ukládání, která je vhodná pro ukládání
celých XML dokumentů jakožto příloh relačních záznamů.
Totéž, co lze provádět s tabulkou, lze realizovat i s pohledem.
Jak snadná je správa dat s Oraclem? Za předpokladu, že již rozumíte všem
záležitostem týkajícím se XML, včetně SQL/ /XML, XQuery a DTD (Document Type
Definition), je správa XML procesů v Oracle Database velmi jednoduchá. Ve
skutečnosti, stejně jako u vývoje schématu, zvládá databáze provádění mnoha
procesů pro správu dat sama, jen s minimální nutnou intervencí administrátora.
Při testech rychlosti, jež zahrnovaly import a vytváření tisíců souborů a
import velmi rozsáhlých dokumentů, se Database 10g ukázala jako velmi rychlý
produkt. Při importu porazila všechny konkurenty a při testu vytváření souborů
skončila těsně druhá za IBM.

XML a DB2
IBM DB2 implementuje XML jako kolekci možností nazvaných XML Extender. Druhou
důležitou součástí XML funkcionality je Information Integrator; tato komponenta
je licencována odděleně od DB2. Ačkoliv XML Extender může vypadat jako
samostatný program, který běží mimo databázi, ve skutečnosti se jedná pouze o
souhrnné označení úložných procedur a funkcí, které mají na starosti XML
funkcionalitu v rámci DB2. Tyto úložné procedury a funkce sídlí uvnitř
relačního enginu, stejně jako všechny ostatní objekty databáze, a jsou k
dispozici všem uživatelům, kteří je potřebují. Jediným mírně rušivým prvkem u
DB2 je oddělení instalace komponenty Information Integrator. Ta je umístěna
mimo relační engine a rozšiřuje XML funkcionalitu DB2 o tzv. XML Wrapper, který
umožňuje zacházet s XML dokumenty stejně jako s relačními zdroji. Jedná se o
velmi silný nástroj, který může být užitečný při příjmu přenášených XML
souborů, pokud chcete provádět dotazování a případně vytvářet zprávy, které ale
nechcete importovat do databáze.
Obdobně jako Oracle Database také DB2 dovoluje ukládání strukturovaného XML,
nestrukturovaných dokumentů nebo zpracovaných dat. Analogicky XML datový typ
DB2 umožňuje skrýt detaily ukládání XML dat jak před uživateli, tak před
administrátory. Lze zde také vytvářet pohledy slučující relační a XML data do
jediné výsledné sady. Tuto výslednou sadu lze spojovat s XML dokumenty
uloženými v souborovém systému nebo s jinými XML či relačními daty uvnitř
databáze.
Jakožto hlavní jazyk pro tvorbu XML dokumentů z relačních dat slouží SQL/XML;
SQL/XML funkce lze použít pro tvorbu XML značek, atributů apod. SQL/XML také
dovoluje provádět při tvorbě dokumentu řetězení a agregace.
Podpora SQL/XML není v produktu DB2 úplná, nicméně pokrývá nejvýznamnější
funkce. Využíváte-li dnes DB2, s největší pravděpodobností budete schopni při
tvorbě XML dokumentů realizovat veškeré své požadavky.
Oproti tomu podpora XQuery v DB2 zcela chybí. IBM bezpochyby s implementací
nedokončeného standardu vyčkává, než W3C upevní specifikace. Nicméně absence
XQuery přestavuje značná omezení v oblasti možností XML vyhledávání. Výrazně
bychom uvítali byť jen jeho částečnou implementaci.
XQuery je jazyk, který se používá pro procházení strukturovaných datových cest,
přičemž oproti SQL nabízí výrazně rozšířené možnosti. Jelikož XQuery je
dotazovacím jazykem založeným na identitě, zatímco SQL je založen na hodnotách,
XQuery lze využívat ke zjišťování existence určitého prvku; oproti tomu SQL vám
řekne, zda známý prvek obsahuje určitou hodnotu. Na rozdíl od SQL obsahuje
XQuery znalost atributů uvnitř jednotlivých značek a má k dispozici silnější
datové typy než SQL, tím pádem máte i větší kontrolu nad typem zapisovaných
nebo dotazovaných dat.
Pomineme-li XQuery, je angažovanost IBM v oblasti XML zjevná už z pouhého
pohledu na vylepšení, kterých se produktu DB2 8.1 dostalo. Nejenže produkt
podporuje "on-the-fly" (za letu) XSLT překlad XML dat, ale naleznete zde také
na tisícovku změn v SQL syntaxi, jen pokud se týče zpracování XML.
Správa XML v DB2 je velmi snadná. Pohledy spravují dynamická data, jež se
nacházejí pod nimi, a nabízejí vrstvu abstrakce, kterou klient potřebuje pro
efektivní dotazování v databázi. Problémem nicméně bude aktualizace XML
schématu. Jelikož DB2 nepodporuje vývoj schématu, bude nutné fyzicky namapovat
stará data do každého nového schématu, které vznikne na základě změny požadavků.
Po pomalejším začátku, způsobeném zmatky ohledně toho, co lze a co nelze
provádět bez využití nástroje Information Integrator, proběhly naše testy
hladce. Vývojové rozhraní DB2 je velmi intuitivní, dokonce silnější než u
Oraclu a Sybase. Navzdory absenci XQuery disponuje DB2 velmi silnými XML
funkcemi a zvládla vše, co jsme od ní požadovali, a to velmi rychle.

Chvalitebná Sybase
Způsob implementace XML v rámci Sybase ASE se nám velmi líbil. Nativní podpora
XML je plně integrována s relační databází, nejsou tak vyžadovány žádné externí
programy.
Sybase ASE umožňuje ukládání zpracovaných, strukturovaných a nestrukturovaných
XML dat. Správci tak mohou do databáze importovat XML data nebo provádět
dotazování XML souborů přímo ze souborového systému. Bohužel ani ASE
nepodporuje XQuery, takže trpí v oblasti vyhledávání v XML stejnými omezeními
jako DB2.
Podobně jako Oracle a DB2 také ASE dovoluje velmi bohaté indexování XML dat, ať
již zpracovaných nebo nestrukturovaných. Samodefiniční mechanismus indexování
se v ASE stará o zpracování vyvíjejících se XML formátů a struktur, aniž by
vyžadoval jakýkoliv vstup od uživatele. Hodnoty prvků jsou automaticky
indexovány k urychlení provádění predikátového vyhledávání (XML obdoba dotazu
typu "select phone from customers where lastname = smith") a různé druhy indexů
(XML nebo relační indexy) volí databáze na základě typu predikátu daného
dotazu. Dotazy mohou být založeny na relačních prvcích, na XML prvcích nebo na
obou současně.
ASE zvládne většinu správy dat za vás. Pohledy, uložené procedury a funkce na
bázi XML dat je nejen snadné vytvářet, ale i spravovat. Avšak chybějící podpora
vývoje schémat bude na překážku rostoucím projektům. A nejedná se o jediný
nedostatek ASE. Při tvorbě XML souborů neumí ASE provádět "on-the-fly" překlad.
Od koncového uživatele se očekává, že nově vytvořené XML následně zpracuje
pomocí XSLT (Extensible Stylesheet Language Transformations) procesoru, což
brání libovolným snahám o včasné vytváření XML souborů. Jakákoliv firma, které
potřebuje pravidelně vytvářet XML soubory, by se měla poohlédnout po jiném
řešení (podle našeho názoru tento úkol velmi dobře plní Microsoft .Net.)
Nebýt chybějící podpory XSLT a XQuery, bylo by možno implementaci XML u Sybase
označit za stejně zdařilou jako v případě IBM či dokonce Oraclu. Firma Sybase
dala dohromady vynikající produkt, který si zaslouží pozornost každé firmy,
která v současné době využívá ASE.
Co se týče testů rychlosti, ASE se držel dobře, až na tvorbu XML souborů, která
byla ovlivněna nutností vytvoření skriptu starající se o zpracování XSLT. Pokud
by ASE obsahoval metodu pro využívání XSLT, vedl by si v porovnání s ostatními
lépe.

Microsoft dostává lekci
Co se týče XML, Microsoft SQL Server 2000 naprosto nestačí na Oracle, IBM a
Sybase. SQL Server dovoluje pouze ukládání XML dokumentů v podobě
nestrukturovaných objektů databáze nebo zpracování XML dat do relačních tabulek.
Mohli byste se domnívat, že absence podpory strukturovaného XML znamená, že SQL
Server je v tomto testu odepsaný, ale to není tak úplně pravda. SQL Server
nabízí mnoho funkcí, které umožňují zpracování a zápis XML dokumentů. Především
lze snadno generovat sady výsledků ve formě XML pomocí zadání For XML v rámci
T-SQL dotazu. To je užitečné samo o sobě, ale ještě užitečnější je možnost
během toho zpracovat data přes tabulku stylů (style sheet) XSLT.
SQL Server má pro tvorbu XML dokumentů k dispozici další bohaté možnosti, které
umožňují rozdělování pohledů a prezentaci XML dat v prakticky libovolné podobě,
jakou uživatelé požadují. SQL Server lze také využít jako určité obousměrné
úložiště XML dat pomocí mapování XML dokumentů přímo do relačních tabulek s
využitím tzv. Updategrams, umístěných mezi XML dokumentem a databází a
umožňujících stanovit, jak prvky vypadají před a po změně. Takto lze pomocí XML
dokumentů aktualizovat, vkládat a mazat v databázích, přičemž výsledek rovněž
obdržíte v podobě XML.
Ještě sofistikovanější funkce nabízí SQL Server při čtení XML dokumentů. Umí
například předávat XML dokumenty jakožto parametry pro uložené procedury a tyto
dokumenty jsou následně zpracovány do databáze. Funkce OpenXML umožňuje z XML
dokumentů vytvářet řady a ty pak vládat do relační databáze. S pomocí OpenXML
máte k dispozici některé šikovné metody pro manipulaci s XML daty. S použitím
příznaků lze vyhledávat atributy a prvky, definovat schémata sady řad pomocí
šablon sloupců nebo názvů tabulek.
Nicméně, jelikož SQL Server zachází s XML dokumentem jako s jediným kusem dat,
databáze neví o existenci XML prvků až do chvíle, než je začnete analyzovat
přes uloženou proceduru. Neznamená to konec světa. I tak lze vytvářet dotazy a
pohledy využívající hierarchických vztahů v XML souborech; pouze to vyžaduje
mnohem více práce (tj. programování). Následující verze SQL Serveru, která by
měla být uvolněna v roce 2005, již by měla ukládání strukturovaného XML
podporovat.
Jak dobře bude SQL Server plnit XML požadavky, to závisí na vašich potřebách.
Chcete-li pouze importovat nějaké XML dokumenty do relační databáze a nevadí
vám, že přijdete o strukturu XML dat, pak bude SQL Server vyhovovat bez
problémů. Nicméně při takovémto scénáři může být vhodnější volbou .Net.
Nástroje .Net prostě zvládají některé věci lépe, a to včetně tvorby XML souborů.
Při testech jsme zjistili, že import XML souborů zvládá SQL Server rychle, ale
tvorba XML je nejpomalejší ze všech testovaných produktů. Také čtení velkých
XML souborů bylo nejpomalejší, ale zde byl rozdíl oproti ostatním produktům
pouze malý.

Závěr
Všechny čtyři testované databázové produkty nabízejí užitečné XML funkce.
Dokonce i Microsoft SQL Server, jemuž chybí podpora strukturovaného ukládání
XML, umožňuje ukládání, zpracování a vytváření XML několika způsoby. Zatímco
Microsoft má na čem zapracovat, IBM DB2 a Sybase ASE trpí méně výraznými
omezeními. Absence podpory XQuery znamená oproti ostatním produktům v testu
méně detailní možnosti vyhledávání. Sybase ASE dále nezvládá nepřipravené XSLT
transformace, což při vytváření XML dokumentů nebo vývoji schémat, což od
administrátorů vyžaduje práci navíc.
I když IBM, Sybase i Microsoft dávají k dispozici významné XML funkce, všichni
o velký kus zaostávají za firmou Oracle. Ta odvádí nejen nejlepší práci při
skrytí složitosti správy XML dat, ale také nabízí nejlepší možnosti dotazování,
a to vše doplňuje o takové záležitosti, jako je podpora WebDAV úložišť a vývoje
schémat. Ale pokud používáte DB2, Sybase ASE nebo SQL Server 2000, budete také
schopni XML data dobře využít.

Testujeme betaverzi databáze Yukon
Yukon představuje pro Microsoft významný krok vpřed na poli XML, jde o
databázi, která by se na trhu měla objevit v polovině roku 2005. Ve snaze
vyrovnat se funkcím pro nativní ukládání XML v relačních databázích IBM, Oraclu
a Sybase bude konečně Yukon podporovat vedle zpracování a nestrukturovaného
ukládání XML, což jsou metody dostupné již v SQL Serveru 2000 také
strukturované ukládání XML dat.
Yukon přistupuje k ukládání vztahů hierarchických dat v XML dokumentech
odlišným způsobem než jeho konkurenti. Místo využívání vnořených tabulek
sloužících k uložení strukturovaného XML představuje Yukon cosi, co jsme
pracovně nazvali jako datový typ spravovaného BLOB (Binary Large Object). To
znamená, že i když jsou údaje mapovány na běžné datové typy BLOB, datový typ
XML, který je přidělen sloupcům tabulky, udržuje informace o hierarchii XML
dat. Jedním z důsledků tohoto přístupu je fakt, že u databáze Yukon je velikost
ukládaných XML souborů omezena na 2 GB. Je to důležité? Někteří se domnívají,
že 2GB limit bude znamenat neúspěch Microsoftu u velkých XML implementací,
nicméně náš názor je jiný... Nikdy jsme neviděli XML dokument, který by měl byť
jen poloviční velikost. XML je o vyhledávání záznamů v souboru, nikoliv o
překlopení celé databáze do jediného souboru, v němž bychom se poté pokoušeli
hledat pomocí XQuery.
Nativní ukládání není jediným zlepšením správy XML dat, které Yukon přinese. K
dispozici je také jednoduchá verze pro vývoj schématu. Zvolená cesta je jiná
než u Oraclu Microsoft umožňuje aktualizovat stávající dokumenty změnou
jmenného prostoru (namespace), nikoliv připojením nového schématu a zpracováním
existujících dat pomocí XSLT (XSL Transformation). Metoda Microsoftu ignoruje
validaci stávajících údajů, zatímco Oracle umožňuje doplnit chybějící údaje
podle nového schématu. Přinejmenším v tomto ohledu je implementace firmy Oracle
flexibilnější. Ověřit schéma lze celou řadu způsobů. Je možné explicitně
vytvořit soubor XML schémat, připojit schéma během vytváření tabulky nebo
využít automatické testovací funkce pro konverzi datových typů v rámci dotazu.
Naše zkušenosti z testování betaverze Yukonu ukazují, že neexistuje způsob, jak
vypnout validaci schématu poté, co jste ji aktivovali. I když to může vypadat
jako dobrý nápad, kompletní ověřování schémat je nákladné. V zájmu úspory času
a výpočetních zdrojů se může stát, že o jeho využití nebudete mít zájem,
zvláště pokud se jedná o důvěryhodné zdroje dat. Proto nás velmi zajímá, jak se
s tím výrobce vypořádá ve finální verzi.









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.