Az XML, mint láttuk tökéletes strukturált adatmegjelenítésre, használható adatok tárolására és archiválására, hasonlóan, mint egy relációs adatbázis. Az XML belső szerkezete lehetővé teszi különféle adatok kifinomult kapcsolatának ábrázolását egy egységen belül. Az XML dokumentumokat két kategóriába sorolhatjuk: hagyományos SGML alapú leíró dokumentumokra és a folyamatosan növekvő népszerűségnek örvendő adat-központú dokumentumokra.
A leíró dokumentumok szöveg dokumentumok, amelyekben jelölők segítik a formázást, indexelést, stb (például technikai kézikönyvek kollekciója, web oldalak, vagy online újságok és magazinok). Az ilyen dokumentumok tipikusan cikkekre, szekciókra vannak felosztva, vagy hasonló különálló, kerek egységekre. Az adat-központú XML dokumentumoknak többnyire nagyon kevés szabad formátumú szöveg adata van , és általában hasonló adat struktúrákat tartalmaznak, mint például olyan egységeket, amelyek mezőkből állnak ( vagy sorokból, oszlopokból).
Nézzünk egy példát leíró dokumentum szerkezetre. Tételezzük fel, hogy a sebészek orvosi kartonmásolatokat készítenek kézben hordozható készülékekkel. Egy olyan rendszert kell készítünk, amelyben a kartonokat el lehet tárolni későbbi megtekintés céljából és más rendszerekkel is meg lehet osztani ( mint például egy kórház számlázási rendszere). Ennél a példánál az XML-t használhatjuk például a kartonok bevitelére a készülékeken, de egészen biztosan használnánk még tárolóba való áthelyezésre ( ahol a tárolás történhet XML-ben, relációs adatbázisban, vagy ezeknek valamilyen kombinációjában). Nem számít, hogy a kartonok valójában hogyan vannak eltárolva, valószínűleg XML-t használnánk az adatok exportálásra más alrendszerekbe (számlázás, orvosi szakvélemények, HR , stb…). Egy minta karton így ábrázolhatunk:
<transcript> <physican id="MD-123456" /> <patient id="035-419-876" /> <procedure>2 cm-es bemetszéssel a <location>bal felső kar</location> bőrszövetéből a képződő góc eltávolítása <tool>szike</tool> segítségével. </procedure> </transcript>
Több opció is rendelkezésünkre állhat a tárolás során:
Van-e értelme ezt az XML dokumentumot sima fájlként tárolni a rendszerben?
Érdemes-e vissza bontanunk külön szekciókká, vagy értékekké, és inkább egy relációs adatbázisban tárolni?
És mi lenne, ha natív XML adatbázisban tárolnánk az adatokat?
Most változtassuk meg a példánkat egy kissé. Ugyanazt az alap struktúrát fogjuk használni, azzal a különbséggel, hogy most számladokumentumokat hozunk létre egy e-kereskedelmi rendszeren belül. A tranzakciós adatokat ( a számlákat ) későbbi megtekintés céljából kell elmentenünk és más rendszerekkel megosztható formában. Az alapszerkezet lényegében ugyanaz marad, de ez már egy sokkal inkább adat-centrikus megoldást eredményez, mert nem tartalmaz szöveges részt.
Az alap rendszer architektúrája az információ áramlás szempontjából ugyanaz mindkét esetben, tehát a kérdés marad: hogyan tudjuk optimalizálni az alrendszereket és az adat tárolási architektúrát ennél a két különböző dokumentumnál?
Ha egy szervezet elhatározta, hogy az XML-t integrálják vállalkozás-szintű architektúrájukba, az XML-t tervezők gyakran elköveti azt a hibát, hogy létrehoznak egy tároló réteget, ami pusztán XML alapú ( csak egyedülálló XML fájlokat tartalmaz).
Sok esetben ennek úgy tűnhet, van értelme. Végülis az adatok XML-ként lépnek be és lépnek ki a rendszerből, és XML-t használunk az adatok felhasználók felé való bemutatására ( XSL stíluslapok alkalmazásával az adatok többféle média megjelenítése céljából). Akkor miért is szednénk szét ezt a dokumentumot és tároljuk az adatokat valamilyen más formában, mint mondjuk egy relációs adatbázisban? Miért ne tartsunk mindent XML-ben?
Ahogy már kiderült, jelentősen limitált az információ kezelési lehetősége XML-ként – a legtöbb esetben, egy XML megjelenítés nem lesz megfelelő számos adat feldolgozási folyamatának kezeléséhez, amelyeket elvárnánk az eredeti XML dokumentumokban.
A tisztán XML alapú tárolási szinten való keresés lassú
Kivéve a legegyszerűbb eseteket, egy ilyen pusztán XML alapú tárolási réteg nem lesz elégséges. Ez csak néhány fájl egy mappában, amelyek mindegyike egy XML dokumentumnak felel meg. Az XML nem egy indexelt médium - nincs mód arra, hogy gyorsan beazonosítsuk, hogy egy XML dokumentum tartalmaz-e a programozási feladat szempontjából releváns információt. Az egyetlen módja, hogy megtaláljunk egy specifikus számlát, a dokumentumok parszolása, és olyan elem keresése, amely megfelel a keresési feltételeknek.
Például a már említett számlázó rendszerben a bejelentkezett vásárlók átnézhetik a számlatörténetüket. Ahhoz, hogy ez megtörténhessen, a rendszernek gyorsan be kell azonosítania melyik XML dokumentum felel meg az adott vevőnek, és használni ezeket a dokumentumokat (pl. egy XSLT réteg létrehozásához, mely mutatja az ezekben a dokumentumokban található információt a vevőnek). Mi alapján dönti el a rendszer, melyik dokumentum tartozik az adott vevőhöz? A rendszernek át kell fésülnie minden egyes dokumentumot a tárolási szinten, keresve a <customer> elemet az "id" attribútum értékkel, amely egyezik az éppen belépett vásárló id-jával. Tehát minden számlát és vásárlói információt meg kell vizsgálni, ami egy nagy rendszerben, ahol sok vásárló van és sok olyan dokumentumot kell átnézni, ami nem releváns az adott feladat szempontjából hatalmas feldolgozási időveszteséghez vezet - még egy olyan "streaming" parszolóval is,mint a SAX
A dokumentum aggregáció bonyolult
Hasonlóan nincsen egyszerű módja annak, hogy több XML dokumentumot egyszerre dolgozzunk fel az információ kinyeréséhez – mindet külön kell parszolni, a lényegi információt kiolvasni és elmenteni, azután ha szükséges, lehet az információt összesíteni.
Az előző példát folytatva mondjuk, hogy van egy számlázási rendszerünk, ahol most szeretnénk egy olyan egységes számlát létrehozni, amely az összes, egy vevőhöz tartozó számlát egyesíti. Hogy ezt elérjük, a számlázási rendszerünknek az előző példában leírt problémánkat egy szinttel tovább kell fejlesztenie. Nem csak azt kell tudnia beazonosítani, hogy melyik számla tartozik az adott vevőhöz ID-jához (és nincsen kifizetve), hanem ki is kell nyernie az adott feladathoz szükséges információt ezekből a számlákból (ebben az esetben létrehozni az egységes számlát), azután az egészet egyetlen formátumba összeolvasztani (a teljes fizetendő végösszeghez). ezt gyakran nevezik aggregációs feldolgozásnak, vagy dokumentum aggregációnak.
A dokumentum manipuláció hatástalan
Egy másik jelentős aggodalomra okot adó dolog a puszta XML tárolással az az, ahogy az XML dokumentumokat feldolgozzuk, és bizonyos információkhoz hozzáférünk. Tegyük fel, hogy a számlás példánkban ki szeretnénk deríteni, hogy mennyit adtak el a 123B27 egységből az előző hónapban. Miután kiderítettük, mely XML dokumentumok tartalmazzák a 123B27 utalást, ezután le kell hívnunk a mennyiség attribútumot is ebben a dokumentumban. Ezt nem könnyű megtenni, ha közvetlenül parszolunk XML dokumentumokat, mert az egész dokumentumot végig kell futtatni, és úgy az információt kinyerni. Ez akkor is igaz, ha az adatokat a memórián átfuttatjuk SAX parszoló segítségével, vagy akár DOM-al az egészet feldolgozzuk.
Az indexelés problémájának megoldása
Az általános megoldása a problémának eléggé egyértelmű – adnunk kell valamilyen fajta indexelést az XML tároló mechanizmusunkhoz, hogy képesek legyünk gyorsan keresni és aggregálni a dokumentumokban talált információt. Számos különböző megközelítés létezik az XML adatok indexelésére, mint például: a már bemutatott XML adatbázisok, hagyományos relációs megoldás, vagy objekt-orientált adatbázisok, illetve ezeknek hibrid kombinációja.
Amint már láttuk, a natív XML adatbázisok index információt adnak az XML tárolókhoz. Ezek jó választásnak bizonyulhatnak, ha meg akarjuk őrizni az információ eredeti XML megjelenését, feltéve, hogy az adatoknak csak limitáltabb feldolgozását tervezzük, mert jelenleg még túlzóan erőforrás igényesek - bár idővel ez csökkenni fog és valós alternatívát tudnak nyújtani. A következőekben nézzük meg, hogy milyen hibrid megoldások születtek a feldogozásra.
Egy másik megközelítése az indexelés témakörének, az információ nagy részének, vagy teljes egészének relációs adatbázisban való tárolása, és csomagoló réteg használata az adatok átvitelére a relációs illetve XML megjelenítés között. Ezt a megoldást könnyen lehet használni olyan repozitorikhoz, amelyek könnyen bonthatóak. Ebben a megközelítésben az XML dokumentumokat nem közvetlenül tárolják. Ehelyett, az információt parszolják, azután relációs adatbázisban tárolják és egyszerűen szerializálják, vagy deszerializálják XML-ből, ahogy éppen a körülmények diktálják (például a közvetítői, vagy megjelenítési szint irányításához).
Ez a megközelítés különösen akkor hatékony, amikor a rendszerbe belépő információ nem eleve XML-ben van megadva, vagy az információt nem XML formátumba kell rendezni a vállalkozási irányelvek részeként. Az ilyen architektúrát használó keresések nem is lehetnének egyszerűbbek. Mivel minden információ relációs adatbázisban van tárolva, minden mechanizmushoz hozzáférünk, melyet általában használnák egy relációs adatbázisban való keresésre: tábla indexelés, kulcs relációk, stb.. Hogy alkalmazhassuk az online vásárlói számla nézőkét, csak egy SQL lekérdezést kell írnunk, mely olyan számlákat keres, melyeknek egy bizonyos vásárlói ID-juk van. A kinyert számlákat azután át lehet transzformálni XML-be a megjelenítéshez, vagy beépített XML output támogatót használva, vagy általános procedurális kódot.
A natív XML adatbázisokkal ellentétben ez a megközelítés megkönnyíti az adatok aggregációját és kezelését. Mivel az információt széttördeli, mielőtt eltárolná az adatbázisban, használhatjuk a jól bevált SQL aggregációs parancsokat, hogy az adatokat közvetlenül kinyerjük. Hogy létrehozhassuk az egységes számlát például, csak egy olyan tárolt folyamatot kellene írnunk, ami előhozza az összes fizetetlen összeget a vásárló számláiról. Egy külön haszna még a dolognak, hogy ezt az információt szerializálhatjuk bármilyen alkalmas formába – semmilyen módon nem köt az eredeti XML szerkezet. Ez a megjelenítési rétegünket is sokkal egyszerűbbé teszi. Természetesen vannak, akik ezt hátrányként élik meg – de az XML nem egy csodaszer, és sok adatbázis számára a relációs tárolási modell használata alkalmasabb lehet, mint az XML fa szerkezete.
Egy hátránya az ilyen relációs-csomagolós megközelítésnek, hogy az XML szerializáció és deszerializáció lépései időt vesznek el. Ha egy bizonyos rendszer nagyban függ XML adatformátumtól (például egy bizonyos XML szabványt használnak adat átvitelre), akkor a tisztán relációs megközelítés sok feldolgozási időt fog elvenni az XML dokumentumok összeállításával és szétbontásával. Egy másik probléma lehet a további programozási ismeret - az XML és XPath helyett például a fejlesztőnek jártasnak kell lennie az RDBMS-ben és SQL-ben is. Sőt, a leíró stílusú XML dokumentumok esetében nehéz, vagy egyenesen lehetetlen az adatok relációs adatbázisban való tárolása bármilyen használható módon.
A tisztán relációs tárolási megközelítés ( egy XML csomagoló a relációs tárolási szint körül) jó választás lehet, ha egy rendszer nem túlzottan XML központú, nem tartalmaz leíró jelegű információt, vagy nem kell az információn jelentős aggregációs folyamatot végrehajtania.
A harmadik megközelítés alapján úgy rendelünk indexet egy tárolt XML dokumentumhoz, hogy az indexelést eltároljuk igaz relációs adatbázisban. Valójában két különböző mód létezik, mindkettőnek megvan a maga előnye.
Teljes XML dokumentumok és relációs adatok tárolása
A hibrid repozitorik első fajtájánál az XML dokumentumok pontosan úgy mentődnek el, ahogy belépnek a rendszerbe; más szóval, bármilyen struktúra, amit az adatokon létrehozunk ugyanúgy megmarad, mint a repozitoriban tárolt XML megjelenítésben. Amellett, hogy eltárolja az XML dokumentumot, a rendszer feldolgozza azt, és másolatot készít az index információról egy relációs adatbázisban. A rendszer követelményeitől függően az indexelés lehet minimális ( egyetlen kulcsot indexel, mint például a vásárlói ID a számlás példánknál), vagy kiterjedt ( minden egyes elem, vagy attribútum egy külön indexelt rész). A kivont indexelt információ egy relációs adatbázis indexben kerül eltárolásra, melynek segítségével azután hozzáférhetünk az egyéni dokumentumokhoz.
A rendszer alapos analízise dönti el az egyensúlyt a minimális indexelés és a sokkal költségesebb „mindent indexelés” megközelítés között. A követelmények, melyek a rendszeranalízist vezérlik idővel változhatnak, mivel a feldolgozási folyamat szabályozza, hogy az adatok mely részeit kell indexelni. Ezért, amikor a követelmények változnak és további indexelés szükséges az adatbázist újra lehet egyszerűen építeni egy XML dokumentum megváltoztatásával és az adatok újra-indexelésével. Ez egy újabb példa arra, hogy az XML hasznos lehet komplex rendszerek fenntartásánál - általában sokkal könnyebb megváltoztatni egy szöveges konfigurációs dokumentumot, mint a folyamatkódot.
Ahogy a relációs modellnél, ennél a hibrid repozitorinál is könnyű a keresés – feltéve, hogy azt az információt indexeljük, amelyre keresni akarunk. Ez hasonló ahhoz, amikor indexeket keresünk egy relációs adatbázison - indexelnünk kell az információt, amelyre előre láthatóan a rendszernek szüksége lesz a kereséshez. Az indexelt adatbázis olyan parancsot kap, hogy találja meg azon XML dokumentumok azonosítóját, melyekben szerepel a vásárlói azonosítónk (mondjuk a számlás példánk esetében). Majd ezeket az azonosítókat használja az XML dokumentumok eléréshez. Fontos kiemelni, hogy ez a módszer lehetővé teszi az XML szerializációs lépés elkerülését, amely elkerülhetetlen lenne egy szimplán relációs megoldásnál – ezzel is javítva a teljesítményt.
Az aggregáció és a dokumentum manipulációs feladatok is nagyban egyszerűsödnek ennek a módszernek köszönhetően. Egy jó tervezésénél, az az információ, amely gyakran használt aggregációra és dokumentum kezelésre indexelésre kerül – azaz, a szükséges információ kinyerhető a relációs adatbázisból anélkül, hogy az XML dokumentumokat magukat egyáltalán meg kellene nyitni. Ez a fajta rendszer analízis nagyon hasonlít ahhoz, amelyet hagyományos RDBMS index tervezésben használnak. Ahogy a tisztán relációs megközelítésnél, vehetjük ezt az adatot, és megépíthetjük az XML dokumentumunkat, hogy egyezzen a kimeneti követelményeinkkel.
Egy hátránya ennek a megoldásnak a plusz tárolási hely, melyet a repozitori emészt fel. Lényegében az adatot kétszer mentjük el: egyszer az eredeti (talán hosszúra nyúló) XML formátumában, és a relációs indexben. Egy ehhez kapcsolódó hátrány a járulékos bonyolultsága az adatbázis karbantartásának – bármilyen módosítást az adatokon végre kell hajtani az XML dokumentumban és a relációs index másolatában is, ezzel növelve a szinkronizáció nehézségét. Itt újra klasszikus kompromisszum kötésre kényszerülünk: annak a vágya, hogy elfogadunk komplexebb frissítés kódokat és több tárhelyet hagyunk dokumentumonként gyorsabb feldolgozást és egyszerűbb kód kinyerést eredményez. Az, hogy ez jó választás-e egy adott programozási feladathoz az alkalmazás természetétől függ, illetve a rendszer szoftveres és hardveres kötöttségein.
XML dokumentum töredékek és relációs adatok tárolása
A hibrid repozitori másik formájában minden indexelt tartalom egy relációs adatbázisban található, mint a legelső pusztán relációs példánknál. Azonban, a dokumentum azon részeit, amelyeket nem kell indexelni (mert ritkán keressük vagy aggregáljuk) XML dokumentum töredékként menti el a rendszer ahelyett, hogy szétbontaná egyedi elemekre és attribútumokra.
Vegyük ismét a számlákat, melyek egy online számla nyomon követési rendszerben szerepelnek. A rendszer követelményi szerint ha nem kell az egyes számaltételek alapján keresnie, akkor tárolhatjuk a számlákat egy olyan szerkezetben, amely úgy néz ki:
Vevő tábla Szamla tábla Tetelek tábla ---------- ------------ ------------- vevoid szamlaId tetelId Nev datum tetel cim vevoId szamlaId varos Ir.Szam
Ha egy tétel elem bizonyos információjára van szükségünk (prezentációs célokra például), egyszerűen kikérjük az XML töredéket, melyet a Tetelek tábla tárol egy adott számlával összefüggésben.
Ez a módszer, mint az első hibrid módszer is megkönnyíti a keresést indexelt mezőkön – hagyományos relációs adatbázis mechanizmusokat használhatunk az indexelt mezők elérésére, és a kritériumoknak megfelelő dokumentumok beazonosítására. Hasonlóan, ez a megoldás is könnyebbé teszi az aggregációs és a dokumentum kezelést is - egyszerűen tervezzük meg a gyakran használt aggregációnál és kezelési feladatoknál megkívánt adatok indexelését, és akkor nem lesz szükség XML feldolgozó kódra.
Hibrid megközelítések összehasonlítása
Tehát mi a különbség a két hibrid megoldás között? Az első több tárolási helyet igényel (mivel az adatok az eredeti XML dokumentumból ismétlődnek a relációs indexelésben), de nem kíván további feldolgozási időt és kódot, hogy visszanyerjük az információt az eredeti formájában. A második hibrid megoldás esetében kevesebb tárolási hely igényelt, mivel csak az eredeti dokumentum nem indexelt XML-je van megőrizve, és nincsen duplikáció az indexelés mentése miatt. A nagy hátránya viszont akkor mutatkozik meg, amikor vissza kell állítanunk az eredeti XML struktúrát – kódot és feldolgozási időt vesz igénybe az XML dokumentum visszaállítása az indexelt darabokból és töredékekből.
Vegyük figyelembe, hogy az ipari szabványok egyre inkább uralkodóvá válnak. Válasszunk egy tetszőleges ágat és már konzorcium létezik arra, hogy definiálják az XML struktúrákat, amely az adatok leírására és a rendszerek közötti adatcserére szolgál. Sok esetben a mérnökök megfelelő jártasság nélkül olyan dokumentum tárolókat terveznek, amelyek egyszerűen úgy tárolják az XML-t ahogy megkapták. Ez különösen igaz, ha egy rendszer olyan elven épült, amelyben az információt saját maga és más partnerek között egyazon XML formátumban továbbítja. Ennek számos hátulütője származhat.
Probléma az XML-ek eredetijének tárolásával
Ahogy korábban említettük már, a probléma az XML szabványokkal az az, hogy ezek nem felelnek meg egy az egyben egy egyéni üzleti adatok reprezentációjának, vagy esetleg a megjelenítési követelményeinek. Ahogy a szabványok fejlődnek egyre inkább megfelelhetnek az egyéni üzleti elvárásoknak és ez a szakasz érvényét veszti, de jelenleg még igaz.
Fontos kiemelni, hogy többnyire amely XML dokumentum jól működik egy cél érdekében, teljesen hasznavehetetlen egy másikban. Egyetlen XML szerkezetre hagyatkozni garantáltan megnövekedett feldolgozási időhöz és kód komplexitáshoz vezethet, mint ahogy súlyos problémákat okozhat, amikor karbantartjuk vagy frissítjük azt a szoftvert, amely létrehozza és keres abban.
Vegyük újra a számlázórendszert, amelyről korábban beszéltünk. Szeretnénk az egyéni számlákat úgy tárolni, ahogy az ügyfelek beadják őket (mint ahogy egy tipikus online tranzakciós feldolgozásnál, más néven OLTP rendszerben), és a vevőknek lehetőséget biztosítani arra, hogy ehhez az információhoz később közvetlenül hozzáférjenek. Sőt, szeretnénk annak a lehetőségét, hogy némi elemzést végrehajthassunk a beadott számlákon – mint például „ mennyit számláztunk egy adott ügyfélnek az év folyamán”, esetleg „mennyit rendeltek egy adott termékből 2012-ben” stb… Ezeket a rendszereket leginkább úgy ismerjük, hogy „online analízis folyamatok”, vagy OLAP rendszerek. Már definiáltunk egy XML formátumot az egyéni számláinknak, és szeretnénk őket egyszerű különálló XML formátumban elmenteni. Amíg ez hatékonyan támogatja a rendszer OLTP oldalát ( mivel a megjelenítés ugyanaz, mint az eredeti bemenet), ez több mint ideális az OLAP szemszögéből. Ha analízis szükségeltetik, a rendszernek a dokumentum tárolóját kell átdolgozni annak érdekében, hogy létrehozza az analitikus adatokat, és ez egyre lassabb és lassabb analitikus teljesítményhez vezet, ahogy az adatbázis növekszik.
Egy megoldása lehet ennek a problémának, hogy létrehozunk egy adatbázist, amely képes mind az OLTP és OLAP funkciókat képes ellátni. Azonban ez kevésbe kielégítő tranzakciós feldolgozás, vagy analízis szempontjából – az egyik vagy a másik majdnem mindig sérülni fog. Van egy másfajta megoldás, amit választhatunk – tervezhetünk egy osztott XML tároló réteget, hogy közvetlenül támogassa a rendszer analitikus és tranzakciós igényeit egyaránt.
A tárolás változtatása a feladat igényinek megfelelően
Ennél a megoldásnál, az OLTP dokumentumokat úgy dolgozzuk fel, ahogy belépnek a rendszerbe. Az információt ezekből az OLTP dokumentumokból olvassuk ki és használjuk fel az OLAP dokumentumok frissítésére. Például, meg szeretnénk mutatni a mennyiségét minden egyes darabnak havi szinten összesítve, amit megrendeltek a rendszerünkben. Ehhez tervezhetnénk egy dokumentumot saját szerkezettel. Ezután, ahogy a számlák tranzakciónkét belépnek a rendszerbe már feldolgozhatóak és a fontos információ felhasználható a megfelelő OLAP dokumentumok frissítésére. Miután megvannak az OLAP dokumentumaink, egyszerűen támaszkodhatunk egy fájl elnevezési konvencióra, vagy létrehozhatunk egy relációs indexet a dokumentumoknak.
A hátrányok egyértelműek – több tároló helyet emészt az ismételt információ, illetve megnövelt feldolgozási időre lesz szükség, hogy a megfelelő OLAP információt kinyerjük minden egyes dokumentumból amikor beérkezik. Az előnye, hogy az OLAP feldolgozás sokkal egyszerűbb, és az XML dokumentumok közvetlenül elérhetőek anélkül, hogy szükség lenne XML szerializációs lépésre.
Vegyük számításba a testreszabott XML struktúrák használatát, amelyek közvetlenül támogatják az XML adatátviteli és megjelenítési követelményeket. Ez a megoldás függ attól, hogy a három kritérium közül ( pl. tárolási hely, OLTP feldolgozási idő, vagy OLAP folyamat idő) melyik a legkritikusabb a saját egyéni architektúránkban és üzleti környezetünkben.
A strukturálatlan adatok kezelésének nehézségei
Egy másik probléma az XML dokumentumok relációs adatbázisra történő szétbontásánál a narratív elemek kérdése. Vegyük az orvosi kartonos példánkat. Nagyon nehéz lesz, hacsak nem lehetetlen, hogy megadjunk egy relációs adatbázis struktúrát, amely leírná a számtalan lehetséges variációját egy eredendően leíró dokumentumnak. Bár vannak strukturált szigetek a szövegben, olyan sok különböző kombinációban és sorozatban jelenhetnek meg, hogy nem szeretnénk őket egy bizonyos relációs szerkezetbe belekényszeríteni. Természetesen nem lehet csak úgy kihagyni szövegeket, csak mert nem illenek bele egy előre definiált szerkezetbe, mivel erre az adatra valószínűleg még később szükség lesz a feldolgozás során. Egyértelmű, hogy más megközelítést kell választanunk.
A legjobb megoldást erre előreláthatólag a hibrid modellezés első változata nyújtja: a dokumentum tartalma mindig elérhető XML-ben, míg az információ indexelése könnyen lehetővé teszi, hogy a gyors adatkinyerésre, amelyre éppen az adott feladatnál szükség van.
Az archiválás problémája
Archiválás alatt az adatok olyan hosszú távú tárolását értjük, amelyeknél már nincsen szükség közvetlen elérésre (szemben. mint mondjuk az online feldolgozás), de nem is lehet őket teljesen törölni (üzleti és/vagy jogi szempontok miatt). A megfelelően tervezett XML egyetlen dokumentumban képes teljes képet adni egy bizonyos adathalmazról. Amíg elegendő meta-információt tartalmaz (jó attribútum és elem nevek formájában), a dokumentum lehet önmagában zárt, és mégis interpretálható a szövegkörnyezet kívül bármilyen feldolgozó szoftver, adat szótár, vagy séma számára. Sőt, mivel az XML dokumentumok szöveg formátumúak, könnyen tömöríthetőek, lehetővé téve sok dokumentum és a kapcsolódó meta-információik tárolását egyetlen kötetben a későbbi visszanyerésre. Azonban az adatok XML-ben való archiválásának erőltetése – különösen, ha forrás információ még nem XML (mint mondjuk egy relációs adatbázis adatai) – nehézségeket eredményezhet amikor az archivált adatokhoz hozzá szeretnénk férni.
A legkézenfekvőbb módszer egy archiválási stratégia tervezésénél arról meggyőződni, hogy az információ visszanyerhető használható formátumban. A múltban ez általában abból állt, hogy átrakták a relációs adatokat egy olyan fájlba, amelynek a szerkezete az eredeti adatbázis szerkezetével megegyezett, így az adatokat könnyen be lehet tölteni (vagy részenként vagy kötegelve) az eredeti struktúrájukba a későbbi munka céljából. Azonban az XML megjelenésével már van lehetőségünk olyan archív dokumentumok készítésére, amelyek önmagukban is megállnak, vagy más néven önleíróak. Ez különösen fontos a mai gyorsan változó technikai világban – senki nem tudja ugyanis, hogy az egyedi igényekre szabott rendszer, ami generálta az archivált bejegyzést egyáltalán fog-e létezni húsz, tíz, vagy akár öt év múlva is. Ezt szem előtt tartva, az archiválási stratégiánkat arra kell irányítani, hogy önleíró dokumentumokat tervezzünk, melyek az összes információt képesek megadni, amikor az archivált anyaghoz hozzáférünk.
Archivált információ visszanyerése
Az XML-ben archivált dokumentumok ugyanabba a hibába eshetnek, mint amivel az XML tárolási rendszerben elmentett egyéni dokumentumoknak szembe kell nézniük. Ezek a dokumentumok sok-sok fájlban vannak eltárolva, mégis könnyen beazonosíthatónak kell maradniuk az adott dokumentumnak, vagy dokumentumoknak egy bizonyos visszaállítási feladatban.
Szerencsére már ismerünk egy módot az információ tárolásához – nevezetesen magát az XML-t. Használhatjuk az XML-t információ indexelésére, átalakítására és összefoglalására az archiválási folyamatunk részeként, csökkentve az átdolgozandó dokumentumok számát amikor az archivált anyaghoz hozzáférünk, de javítva az archiválási keresést és a visszanyerési teljesítményt. Amikor az XML dokumentumokban való keresés különböző módozatait vitattuk meg, mind az indexelés témája körül forgott – speciális információk kinyerésére a dokumentumokból és arra használva őket, hogy visszakapcsoljanak az eredeti XML dokumentumhoz. Az archívumokra alkalmazhatunk hasonló stratégiát – de az indexünket XML-ben fogjuk elkészíteni.
A korábbiakhoz képest többféle megoldás adódhat. Elsőként nézzünk egy olyan módot, amikor egyszerűen kiválasztunk pár fontos adattagot és az archívumba a megfelelő fájl hivatkozása mellé csatoljuk ezeket, pl. vevő vagy beteg nevét, a bejegyzés idejét. Amikor egy lekérés érkezik, akkor ezen indexinformációk alapján megkapjuk, hogy melyik tényleges fájlt kell átnéznünk a részletes adatok után kutatva.
A másik megoldás ennek egy haladottabb verziója, mert olyan dokumentumot is készíthetünk, amelyek aggregált információt szolgáltatnak. Tipikus eset ha az üzleti folyamatainkba gyakran érkezik lekérés összesített információkra, és nem csak a napi adatokról. Ebben az esetben készíthetünk összesítő dokumentumokat is. Ezek az összesítő dokumentumok átvehetnék az archivált dokumentumok szerepét, vagy (ami valószínűbb) azokkal együtt szerepelnének egy archívumban. Ez hasonlít az indexelési technikára, melyet már korábban elemeztünk a fejezetben – az összesített XML dokumentumok hatékonyan alkotnak egy fedő indexet a részdokumentumok számára, ezáltal lehetővé téve az összegzett információ visszanyerését anélkül, hogy bele kellene magunkat ásni az egyes archívumokba.
Zárásként pedig arról, amire ritkán gondol az ember. Az XML dokumentumot megjelenítő kódra vagy stíluslapra. Néhány esetben létezhet jogi vagy üzleti megkötése annak, hogy a dokumentumokat egy adott formátumban kell fenntartani akár évekig. Ha az XML adatbázis tervezésnél kihasználjuk a kívánatos szétbontását a szemantikai jelentésnek és a megjelenítésnek, lehet, hogy már nem lesz kielégítő információnk egy bizonyos forma visszaállításához a megfelelő kód vagy stíluslap hozzáadása nélkül. Emiatt erősen ajánlott az összes fő XML dokumentumhoz kapcsolódó stíluslap és kód archiválása.