, SICS
2004-04-01
Sammanfattning:Då användningen av XML exploderat, och XML-orienterade verktyg levereras i allt stridare ström, har behovet av XML-orienterad databaslagring blivit alltmer viktigt. De två tekniska huvudfårorna är: XML-gränssnitt mot traditionella databashanteringssystem, respektive databashanteringssystem dedicerade för XML (NXDB).
Databassystem speciellt konstruerade för XML gör det möjligt att operera på databaslagrad XML med hjälp av redan kända språk för XML. Till exempel finns stöd för XPath och XQuery som tekniker att extrahera information från XML-databaser. XUpdate är ett språk som utvidgar XPath med operationer för ändring av XML-databaser -- tillägg, borttag och uppdatering. Till skillnad från den kända relationella databasmodellen med sina definierade (och därmed fixerade) tabellstrukturer kan man i XML-databaser enkelt spara dokument med varierande struktur. Dessutom är tillägg och uttag av hela XML-dokument enkla operationer i XML-databaser, medan man för relationella databaser måste bryta isär dokumentet i enkla delar vid tillägg och bygga samman delarna till dokument vid uttag.
Beroende på vilken typ av data/information som man vill databaslagra, finns det situationer där XML-databaser ger fördelar, respektive situationer där relationella databaser ger fördelar. Det betyder att man måste analysera sina informations- och datastrukturer då man väljer vilken typ av databashanterare man ska använda.
XML-orienterade databashanteringssystem finns i olika former. En huvudtyp är relationella databashanterare som byggts ut med ett XML-orienterat gränssnitt, så att applikationer kan utnyttja XML-operationer för att operera på data som bakom kulisserna lagras i tabeller. En annan huvudtyp är dedicerade XML-databaser, som lagrar XML-data på ett sätt som direkt bibehåller strukturen på XML-dokument. Det finns ett antal implementationer av den senare typen, dels open-source (t.ex. Xindice, eXist, dbXML) och dels kommersiella (t.ex. Tamino, DBXML, 4Suite).
Debatten om vilken ansats som är den "rätta" och om vilka fördelar och nackdelar de olika ansatserna har i praktiken, den debatten är livlig och ännu inte avslutad.
XML är ett nu fullt ut acceperat format för representation av information av olika slag -- text-dokument, strukturerad data, metadata, m.m. Dess första användning var som ett leverantörsoberoende transportformat, definierat för att kunna utnyttjas på webben, och kunna utnyttja webbens möjligheter. Det är där vi ser den klassiska formen av XML, som en textström innehållande balanserade taggar -- <elementnamn-och-attribut> ... <elementnamn>. Genom sin definition kan man därmed uppfylla ett av kraven på interoperabilitet: att olika tillämpningsprogram skall kunna uppfatta samma struktur i det data som kommuniceras.
Ett annat sammanhang där XML-dokument används är i den interna hanteringen av sådana dokument inom enskilda applikationsprogram. Där behandlar programmen XML-dokumentet i termer av dess Domain Object Model (DOM). Via definierade API:n och dessas bindning till specifika programmeringsspråk (t.ex. Java), kan man även uttrycka programlogik på ett leverantörsoberoende sätt. Programmet accessar delar av dokumentet i termer av dess struktur: navigera till något element i XML-dokumentets trädstruktur, och hämta innehållet i eller attributvärden hos detta element.
Dessa två sammanhang gränslar in två viktiga aspekter på användning av XML -- kommunikation av XML-dokument och behandling av XML-dokument. Det finns ytterligare ett sammanhang som i praktiken är nödvändigt att stödja: lagring av XML-dokument (på någon dator någonstans). Detta område har inom praktisk IT gått under namnet databaslagring, och det består då av två konceptuella komponenter. Dels den fysiska lagringen av data, den data som man vill spara undan för att vid senare tillfälle komma åt igen, och dels de mekanismer som tillåter tillämpningsprogram att komma åt sådana lagrad data (databashanteringssystem). Unde de senaste decennierna har relationsdatabaser enligt SQL-standarden (SQLDB) varit förhärskande, även om alternativa paradigmer har fått viss användning -- t.ex. så kallade objektorienterade databaser (OODB).
Varje databasparadigm baseras på en viss syn på vad det är som lagras och hur lagrad data skall åtkommas. Inom SQL-världen ses data som tabellorienterat -- en tabell som består av ett antal rader, som i sin tur innhåller ett antal värden. Access till data sker typiskt genom att i en viss tabell söker man efter en rad, och sedan får man tillbaka de datavärden som ligger i denna rad.
Inom OODB-världen ser man data som objektstrukturerat -- databasen innehåller objekt med attribut och relationer till andra objekt. Data hämtas typiskt genom att navigera över relationerna mellan objekt till dess man hittar rätt objekt, och då kan man få tillbaka de datavärden som attributen har.
I XML-världen är situationen inte lika klar. I många fall användes det vanliga filsystemet som en databas, där enskilda dokument sparas som enskilda datafiler, och åtkomst sker genom vanliga fil-orienterade operationer. Ett typexempel på detta är vanliga webbservrar, som i normal drift returnerar innehåll i filer som pekas ut genom en URL (URI). I detta fall har vi en situation som karaktäriseras som: ett XML-dokument som enskilt intressant objekt svarar en-entydigt mot en fil.
Ett annat sätt att organisera datalagring på är att i ett och samma XML-dokument spara information om flera intressanta objekt. Det kan vara ett XML-dokument som är en produktkatalog, och denna produktkatalog innehåller ett antal produktbeskrivningar, var och en som ett väldefinierat XML.element. Om en applikation behöver komma åt information om en produkt, så kan den läsa in XML-dokumentet som är produktkatalogen, och sedan i detta dokument söka sig fram till elementet för den intressanta produkten. Här har vi alltså situationen att ett XML-dokument i sig innehåller en mängd enskilda intressanta objekt, men att hela XML-dokumentet svarar mot en fil.
Men inget av de ovanstående alternativen har acceptabel skalbarhet -- dvs när mängden information ökar så ger dessa alternativ inte bra prestanda. Därför måste man använda databassystem för XML. Sådana förekommer i olika former:
Den tredje typen, dedicerade XML-databaser, kallas på engelska "Native XML DataBases", NXDB. Av praktiska skäl använder vi i denna artikel förkortningen NXDB.
Vi kommer i denna artikel kort beskriva vad NXDB är, hur de typiskt är strukturerade och något om när de kan vara lämpliga att använda. Slutligen ges ett antal referenser till vidare litteratur i området.
Det finns klara likheter mellan olika realiseringar av NXDB. En likhet är att en databas ses som en hierarkisk struktur, där de övre lagren består av samlingar ("collections") av dokument eller av andra samlingar. I trädets "löv" återfinns XML-dokumenten, som i sin tur naturligtvis har en hierarkisk struktur (i termer av nästade XML-element). Denna hierarki gör att man kan se hela databasen som ett virtuellt XML-dokument -- och därmed kan man operera på hela databasen nästan som om det vore ett existerande XML-dokument.
I vanlig ordning finns stöd för transaktioner och låsning, även om olika implementationer till viss del har valt skilda principer för hur mycket en transaktion omfattar/hur stor del av databasen som låses. Behörighet och behörighetskontroll är även det ett område där stöd ges, liksom fleranvändaraccess. Backup, vilket är viktigt för administration av databaser, ges också stöd.
Med databashantering vill man inte bara uppnå uniformitet och enkelhet i operationerna mot databasinnehållet, utan även uppnå tekniska prestandavinster. Sådana prestandavinster kan erhållas med indexering av innehållet, vilket också stöds av NXDB-implementeringar. Typiskt erbjuds möjligheter att indexera elementnamn, attributvärden och ord i textinnehåll, men de olika implementationerna skiljer sig något åt vad gäller flexibilitet i indexering.
Två standarder för att söka och extrahera delar av XML-dokument finns redan definierade i XML-världen, och användning av dessa blir viktiga vid hantering av XML-databaser.
XQuery ( XQuery 1.0: An XML Query Language , W3C Working Draft 12 November 2003 ) har definierats för att ge generellt stöd för frågor mot XML-dokument. Utformingen av XQuery har bl.a. influerats av SQL-Query, vilket bl.a. betyder att det har en textuell notation som påminner om SQL-frågor. För att erbjuda ett mer ensat gränssnitt mot funktionaliteten i XQuery har en alternativ syntax i XML-form tagits fram, XQueryX ( XML Syntax for XQuery 1.0 (XQueryX) , W3C Working Draft 19 December 2003 ). Ett exempel på användning av XQuery är följande:
|
som betyder: hämta fram alla "town" i det andra "adress"-elementet i rot-elementet "addresses", och bygg ett <result> element som innehåller dessa.
En annan standard för extraktion av information är XPath ( XML Path Language, Version 1.0 , W3C Recommendation 16 November 1999 ), som är ett språk varmed man kan peka ut delar av XML-dokument, genom att beskriva vägen ("path") genom dokumentet för att nå den önskade delen. XPath har fördelen att vanligt förekommande sökningar har en form och kan uttryckas mer eller mindre direkt i XPath. XPath var inte avsett att vara ett universellt frågespråk, så även om det finns extraktionsbehov som inte kan uttryckas i detta språk är det ändå ett både praktiskt och enkelt redskap för att uttrycka vanliga extraktionsbehov.
Ett enkelt exempel på ett XPath-uttryck är:
|
som betyder: välj "town" i det andra "adress"-elementet i rot-elementet "addresses".
Eftersom vi således har två standarder för extraktion av information ur XML-dokument (XQuery och XPath), och eftersom den viktigaste operationen vid access till data lagrad i databas är just extraktion, så är dessa två språk stödda av API:er i NXDB-system. Vi har alltså en situation där samma paradigm (XQuery resp XPath) kan användas såväl för operationer på dokument inlästa i tillämpningprogrammet som för operationer på dokument hanterade i en NXDB.
Vi har dock inte sådan direkt symmetri vad gäller uppdatering av dokument, symmetri mellan hanteringen av interna (in-core) dokument respektive dokument i NXDB. Till viss del beror detta på att vad som prioriterats i arbetet med att ta fram standards är extraktion av data -- generella språk för uppdatering har kommit in senare i bilden. En förslag för hur modifieringar av XML-dokument kan uttryckas är XUpdate ( XML Update Language ) från XML:DB , ett fristående samarbetsforum. XUpdate kombinerar XPath med konstrukter som uttrycker vilka förändringar som skall genomföras på element i ett dokument. På samma sätt som XPath har omtolkats till NXDB-världen, har XUpdate anammats av denna värld, så att ändringar i databasen kan beskrivas på ett mer deklarativt sätt. Ett exempel på användning av XUpdate är uttrycket:
|
som medför att innehållet i det element som identifieras av spåret "/addresses/address[2]/town" sätts till "New York". Resultatet av denna operation på en databas med innehållet:
|
blir då:
|
Eftersom den data som kommuniceras mellan tillämpningsprogram och databashanterare är XML, känns det naturligt att tillhandahålla, via databashanteraren, vissa kända XML-mekanismer. En sådan mekanism är den som ges av Extensible Stylesheet Language Family (XSL), t.ex. XSLT ( XSL Transformations , W3C Recommendation 16 November 1999) varmed XML-innehåll kan transformeras med hjälp av regler -- något som kan vara både praktiskt och effektivt då speciella format skall genereras från databasinnehåll.
För att underlätta för applikationsprogram som skall behandla data hämtade från en databas kan applikationen ta emot data inte bara som en XML-text, utan även via DOM- och SAX-gränssnitt tillhandahållna av databashanteringssystemet..
Bland de tekniker för kommunikation mellan ett tillämpningsprogram och databashanteraren återfinns bl.a. HTTP, XML-RPC , XML:DB XML Database API och SOAP Version 1.2 Part 0: Primer (W3C Recommendation 24 June 2003).
När är det lämpligt att använda en NXDB? Dvs vilka är fördelarna respektive nackdelarna då man vill hantera data via en NXDB eller via en relationell databashanterare?
Då XML-access skall stödjas av ett databassystem som i grunden är en SQL-databas kräver att den hierarkiska trädstrukturen i XML-data avbildas på SQL:s tabellstruktur. Detta innebär modelleringsarbete, dvs transformationen mellan XML:s trädstruktur och tabellstruktur måste definieras. Sådana transformationer kan vara automatiska, eller de kan vara manuella. Nackdelen med en automatisk transformation är att ineffektiviteter kan uppstå, genom att förekomstmängd av element och användningsfrekvens av operationer inte styr avbildningen till tabeller. Som är känt i SQL-världen är indexering viktigt av effektivitetsskäl, och indexen definieras på basis av insikt i vilka data som skall representeras och hur de skall åtkommas. Vid automatisk avbildning av XML på SQL tappar man ofta denna möjlighet till optimering.
Manuellt definierade transformationer från XML till SQL ger naturligvis stora möjligheter till optimering. Men arbetet med att definiera och förvalta manuellt definierade transformationer skall inte underskattas.
Generellt kan man säga att om ens data är välstrukturerade enligt klara scheman, dataobjekt är ganska grunda, och scheman är stabila, så kan det vara lämpligt att använda sig av en traditionell databas med ett tillagt XML-orienterat API.
Men om den XML-data som skall hanteras har en öppen/flexibel struktur, objekten kan ha varierande djup, scheman kan vara föränderliga, och om det är viktigt att kunna utföra operationer på hela XML-objekt, i så fall kan en NXDB vara lämplig.
Det har snabbt kommit fram ett inte föraktligt antal NXDB-produkter på marknaden. Naturligtvis har XML:s snabba genomslag, inte bara för webben utan även inom den allmänna IT-sektorn, varit den dominerande orsaken till detta. En effekt av att flera produkter tagits fram parallellt är att det ännu inte finns en officiell och heltäckande standard för vilken funktionalitet en NXDB kan erbjuda och hur funktionaliteten skall kommas åt (dvs hur API:er skall se ut). Genom att en stor del av det initiala intensiva arbetet med NXDB:er drevs i open-source-form, och ett antal olika parallella initiativ hade utbyte i öppna fora (såsom news-groups), finns det ändå en tillräckligt stor enighet om grundprinciperna, så vi kan förvänta oss att standarder (om inte formella, så åtminstone de facto) kommer att stämma väl överens med den konsensus som vi nu ser mellan olika implementationer av NXDB.
Som en indikation om vad som för närvarande finns, ges här några exempel.
eXist är et Java-implementerat open-source NXDB, ett av projekten under SourceForge . Den stöder XPath, XQuery och XUpdate.
Xindice är en annat Java-implementerat open-source NXDB, från Apache Software Foundation . Det kan vara viktigt att betona att Xindice är ett fristående NXDB, oberoende av den kända Apace webservern, även om Xindice naturligtvis kan användas i serversammanhang som lagringsmekanism för webbinnehåll. Xindice stöder XPath och XUpdate, men ännu inte XQuery.
dbXML är ytterligare ett exempel på en Java-baserad open-source NXDB, utvecklat av dbXML Group, men som även finns tillgänglig på kommersiella villkor. dbXML stöder bl.a. XPath och XUpdate.
Det finns ett stort utbud av kommersiella NXDB:er. Några slumpmässigt valda exempel är:
Flera större produktleverantörer har för närvarande inte NXDB:er i sitt utbud. Istället har de (t.ex. IBM med DB2, Microsoft med SQL Server 2000, Sybase med Sybase ASE 12.5 och Oracle med Oracle 8i, 9i) utrustat sina vanliga SQL-orienterade system med tilläggskomponenter som ger ett XML-orienterat API mot databaser.
Aktuell information om olika typer av produkter som stöder XML i databaser hittas på Ronald Bourrets sida "XML Database Products.
För den som vill läsa mer om detta område ges här några länkar. Eftersom det är ett livaktigt område, så publiceras kontinuerligt ny information på webben. Det kan vara lämpligt att söka på webben efter "Native XML Database", för att inte missa information.