Dette er vår tredje obligatoriske oppgave i kurset Moderne Databaseteknologi.

Transkript

1 Innledning Dette er vår tredje obligatoriske oppgave i kurset Moderne Databaseteknologi. Vi har valgt oppgave 1, Database Management og extensive Markup Language (XML). I denne oppgaven skal vi utarbeide en rapport der vi belyser status og utvikling i forhold til XML og database management. Vi skal også gi en kortfattet oversikt over Lores funksjonalitet og vise dens funksjonalitet med et eksempel. Vi har starter denne rapporten med å gi en beskrivelse av XML. Momenter vi har tatt for oss er historikk, definisjon, XML mot Hypertext Markup Language (HTML), hvilke fordeler XML gir, hva XML ikke er og hvor man kan bruke XML. For å kunne forstå hvordan XML kan virke sammen med database management, må man forstå XML og database management hver for seg. Neste del i rapporten tar derfor for seg database management og XML-baserte databaser samt en kort beskrivelse av XML Path Language (Xpath) og XML Query Language (XQuery). I punktet om Lightweight Object Repository (Lore) beskriver vi Lores arkitektur og funksjonalitet. Tilslutt har vi laget et eksempel hvor vi bruker Lore. Her har vi prøvd å få frem Lores funksjonalitet ved å lage ulike spørringer mot XML-dokumentet. Moderne databaseteknologi ved Høgskolen i Østfold våren

2 Innholdsfortegnelse 1 XML Historikk Definisjon XML - HTML Velformet og validert Fordelene til XML Bruksområder Database management system Historikk/utvikling XML-baserte databaser Spørringer i XML-databaser XPath XQuery XML-databaser Native XML Databaser XML Enabled Databaser Fremtiden for XML-baserte databaser Historie Lore komponenter Lores arkitektur OEM Lores XML Data Modell Lorel Query Language Query og Update Processing Lorel Query process Query Operators Update processing Query Indexing DataGuides Eksempel på database i Lore Innledning: Bruk av Lore Opprette database Loade database Bruke databasen Avslutte Lore Slette database Spørringer Konklusjon XML-fil (kurs_eks.xml) Konklusjon Ordliste Kilder Moderne databaseteknologi ved Høgskolen i Østfold våren

3 1 XML Ettersom forretninger vokser og utvides ved å bruke nye medier for å koble seg sammen, er det nødvendig å dele et felles språk ikke et naturlig språk som norsk eller engelsk, men et felles PC-språk. Et av disse språkene er extensive Markup Language eller XML. 1.1 Historikk For å forstå XML så trenger man å forstå det grunnleggende angående markupspråk og dens bruk. Et markupspråk er et sett av regler som definerer layout, format og struktur av tekst innenfor et dokument. Etter at markupinstruksjonene er lagt til et dokument så må det leses, eller prosesseres av et program som kan tolke markupelementene. Markupspråk og programmer som formaterer tekst er blitt brukt i mange år, for eksempel Microsoft Word. Rundt 1960 startet man arbeidet med å utvikle et standardisert markupspråk for dokumenter som ikke skulle være avhengig av en bestemt plattform eller program. Standard Generalized Markup Language (SGML) var det første standardiserte markupspråket som ble laget og er stamfaren til både HTML og XML. SGML ble utviklet for å lage et standard format og struktur for store dokumenter, som for eksempel tekniske dokumenter. SGML ble en ISO-standard i 1986 og er blitt brukt av for eksempel bilindustrien og helsevesenet. Det som var problemet med SGML, og som gjorde at det ikke fikk stor utbredelse, var at det var utrolig komplekst, og det ble derfor dyrt å utvikle software som skulle prosessere koden. Når World Wide Web (WWW) fikk sin utbredelse i og 1990-årene vurderte man om SGML kunne brukes til å bygge markupspråket som skulle brukes til å opprette dokumenter. Man tok heller i bruk HTML siden det var lite og enkelt. Etter som årene gikk ble det en ulempe at HTML var så enkelt. HTML hadde et fastsatt sett med elementer, og siden det ikke kunne utvides var det begrenset hva webutviklere kunne gjøre. Ikke bare fant man ut at HTML var for begrenset, informasjonen som ble lagt ut på Internett ble også forandret. Flere og flere bedrifter og personer startet å bruke flere dynamiske funksjoner på websitene sine. Man fant ganske fort ut at man trengte et nytt og bedre språk. Dette gjorde at W3C startet å jobbe med XML på midten av 1990-tallet. Den første godkjente utgaven, XML versjon 1.0, ble utgitt 10 februar 1998 av W3C. XML ble raskt populært fordi den kombinerte HTML sin enkelhet og SGML sin fleksibilitet og utvidbarhet. Den andre utgaven av XML versjon 1.0 ble utgitt i oktober Moderne databaseteknologi ved Høgskolen i Østfold våren

4 W3C har identifisert 10 hovedpoeng som er nødvendige for å forstå XML: 1. XML er for strukturerte data 2. XML ser nesten ut som HTML 3. XML er tekst, men ikke ment for å lese. Fordi XML-dokumenter er ren tekst så kan de lages, editeres og vises i vanlige teksteditorer. 4. XML er ordrik ved design 5. XML er en familie av teknologi 6. XML er nytt, men ikke helt nytt 7. XML tar HTML til XHTML 8. XML er modulær 9. XML er basisen for Resource Description Format (RDF) og Semantic Web 10. XML er gratis, plattformuavhengig (er ikke avhengig av et bestemt operativsystem eller applikasjoner) og godt støttet (supported) På mange måter er XML det mest portable og fleksible dokumentformatet som er designet siden ASCII. Informasjon som hadde vært lagret i dokumentsystemer og databaser er nå tilgjengelig på samme format, og kan prosesseres med samme verktøy. XML har utviklet seg siden den ble utgitt og i tillegg fått andre spesifikasjoner som for eksempel XML Namespaces, XML Stylesheet Language Transformations (XSLT), XML Schema og XML Linking. Siden XML ble så populært startet softwarebedrifter å lage verktøy for XML og dette gjorde at XML ble mer kjent og ikke minst mer populært. XML har ikke bare forandret måten mennesker publiserer dokumenter på nettet, men også hvordan bedrifter håndterer intern informasjon. 1.2 Definisjon Å prøve å definere XML er vanskelig. Bare se på disse definisjonene: XML blir brukt for å forbedre kompatibiliteten mellom businesspartnere ved å definere meningen med dataene i businessdokumentene. (Turban, 2002) [5] XML er et språk som tillater utveksling av strukturert data. (Bouneffa, 2001) [5] XML er en forkortelse for extensible Markup Language, som er utviklet av W3C, og er en forenklet versjon av SGML. XML tillater at designere lager sine egne tagger, muliggjør definisjon, transmisjon, validering og fortolkning av data mellom applikasjoner og organisasjoner. (Balas, 2002) [5] Hver av disse beskrivelsene lager sin egen vri på hvordan man skal definere XML, men de prøver å si det sammen nemlig at XML er et metaspråk. Det har et vokabular som består av syntaksregler og struktur som tillater data å bli oversatt fra et applikasjonssystem til et annet og så bli retolket av det opprinnelige systemet. Åltså, XML er ikke et markupspråk, men et sett av regler som kan brukes til å definere og lage et nytt språk. Moderne databaseteknologi ved Høgskolen i Østfold våren

5 1.3 XML - HTML Fordi det er mange ulike definisjoner av XML og fordi utviklerne har vanskeligheter med å komme med en definisjon, er det ikke lett for en vanlig person å skjønne XML. Den vanligste feilen er at mange tror at XML er det samme som HTML. Begge språkene inneholder noenlunde samme markupsymboler. Den store forskjellen er at HTML beskriver hvordan dataene skal bli presentert, mens XML separerer dataen i et dokument fra presentasjonen og formateringen. XML elementer er utviklet for å beskrive data, ikke til å formatere data. XML er ikke ment som å erstatte HTML på webben. XML er et annet, mer fleksibelt verktøy som man kan bruke for webutviklling. Eksempelet under viser likhetene og samtidig ulikhetene HTML XML <p> Denne boken heter: </p> <i> The e-business (r)evolution </i> Den er skrevet av <br /> <b> Daniel Amor. </b> <boktittel> The e-business (r)evolution </ boktittel> <forfatter> Daniel Amor </forfatter> <forlag> Prentice Hall PTR </forlag> <copydato> 2002 </copydato> <pris> </pris> <ISBN> </ISBN> Tabell 1: Viser likheter/ulikheter mellom XML og HTML For eksempel så definerer HTML-taggene <p> start og </p> stopp for en paragraf, men disse taggene sier ingenting om innholdet i paragrafen. Selv om XML ser ut som HTML, er det å lage et godt XML-dokument mer som å designe en database enn å lage en webside. XML tar i bruk tagger og attributter som HTML, men meningen med taggene og attributtene bestemmes av applikasjonen som leser XML-dokumentet. Dette er nyttig for databasedesignere fordi det tillater dem den fleksibiliteten å gi navn til deres elementer som gir mening for systemet og for brukerne. Det at XML er utvidbar betyr at språket kan utvides og tilpasses til å møte mange forskjellige behov. 1.4 Velformet og validert XML-dokumenter har en syntaks man må følge. Syntaksen er regler som må følges for at program skal kunne prosessere informasjonen. Syntaksreglene til XML er: Dokumentet kan kun inneholde ett rotelement Hvert element må ha en start og slutt-tag Elementene må nestes skikkelig Alle attributter må ha en verdi, og verdien må skrives i Attributter må plasseres i start-taggen og samme attributt kan kun forekomme en gang Navnene på elementene er case-sensitive Enkelte tegn for eksempel < eller > kan ikke brukes som innhold i et element Navnet på elementene kan starte med bokstaver eller _ (underscore) og kan inneholde bokstaver, tall, punktum og _ Et XML-dokumentet som følger disse syntaksreglene kalles et velformet XMLdokumentet. Dokumentet må være velformet for å kunne brukes av programmer (for eksempel internett browsere). Moderne databaseteknologi ved Høgskolen i Østfold våren

6 Hvis du ønsker å dele ditt XML-dokument med andre holder det ikke at dokumentet er velformet, det bør også være gyldig (valid). Du kan validere et XML-dokument mot en dokumentmodell som for eksempel en Document Type Definition (DTD) eller XML Schema. Ved å bruke en dokumentmodell kan du: Definere elementene XML-dokumentet kan inneholde Definere rekkefølgen på elementene Definere at noen elementer er obligatoriske Definere hvor mange ganger et element kan forekomme Definere hvilken type data elementer kan inneholde Definere barnelementer Definere attributter til elementene Tilegne restriksjoner til attributtverdier 1.5 Fordelene til XML Det er mange gode grunner til hvorfor man ønsker å bruke XML. Her er noen av dem: Du er ikke begrenset til et predefinert sett med elementer Du kan lage regler for hvilken type data elementene kan inneholde Du kan lage datastrukturer som er tilpasset forskjellige behov Side XML beskriver data, så kan data presenteres på forskjellige former Inneholder verktøy for linking Kan brukes til å utveksle data mellom proprietære formater og mellom databaser Verktøyene i XML kan brukes til å definere en standard syntaks for mange forskjellige markupspråk XML inneholder en robust og pålitelig søkemulighet 1.6 Bruksområder Det er 3 ulike måter å bruke XML på webben. Den første er XHTML. Dette er en XMLvariant av HTML 4.0 som strammer opp/skjerper HTML slik at den matcher syntaksen til XML. Den andre er direkte visning av XML-dokumenter. Generelt så kobler man til et stylesheet (css eller xslt) som formaterer/transformaterer dokumentet. Den tredje måten er å mikse XML-vokabular som for eksempel MathML og Scalable Vector Graphics (SVG) ved å bruke Modular XHTML. Modular XHTML lar deg innkapsle MathML-likninger og SVGbilder inne i XML-dokumentet. I utgangspunktet ble XML designet for å brukes på web, men man fant raskt ut at XML hadde flere bruksområder. Det man mest bruker XML til i dag er å lagre og sende informasjon som brukes av forskjellige applikasjoner og systemer. Før man fikk XML måtte hver programmerer finne ut hvordan data skulle formateres når det skulle lagres eller sendes. Nå når vi har XML er det et enkelt valg for programmerere. Dette fordi XML: har enkel syntaks som gjør det enkelt å generere og parse støtter nesting og dette gjør at du på en enkel måte kan representere ulike strukturer er enkel å feilsøke er språk og plattformuavhengig Moderne databaseteknologi ved Høgskolen i Østfold våren

7 Siden XML har blitt godkjent som et W3C-standardspråk, begynner bedrifter å bli varme for ideen om å implementere forretningssystemer som bruker XML-teknologi. All tradisjonell- og e-business har behov for å spore data, som for eksempel informasjon om kunder og ansatte, produksjon eller inventar-records og økonomiske faktorer. Behovet for å spore data fører oss videre til neste teknologi som er nødvendig i en XML-basert database nemlig database managementsystem eller DBMS. Moderne databaseteknologi ved Høgskolen i Østfold våren

8 2 Database management system Database management system (DBMS) er en software applikasjon som gjør at du kan lagre, endre og hente ut informasjon fra en database. I vår vanlige hverdag har vi hele tiden mange ulike typer av DBMS rundt oss. Vi kan for eksempel nevne minibanker, reserveringssystemer på flyplasser og inventar systemer. Disse systemene kan skreddersys for å passe en bedrifts spesielle ønsker og krav. Bedrifter kjører ut ulike rapporter hele tiden for å holde seg oppdatert på for eksempel kundeordre eller aksjekurs. Disse rapportene fås av DBMS gjennom å utføre spørringer. En spørring tillater en bruker å velge et nøkkelord eller en setning for å instruere databasen til å hente ut all informasjon som man spør etter. Dette er et viktig verktøy for bedriftene. Søket, som blir utført av maskinen, henter ut de aktuelle dataene og dermed slipper en person å søke gjennom endeløse data for å finne det han er ute etter. DBMS er nyttig fordi det sparer ansatte den tiden de ville ha brukt til å finne den samme informasjonen. Dette er tid som bedrifter kan bruke annerledes. DBMS har vært på markedet siden 1960-årene. De var først laget for å overvinne begrensningene som fantes i filprosesseringssystemene. I tillegg ble DBMS designet for å tilfredstille følgende: Behovet for å oppnå større uavhengighet mellom programmer og data og dermed redusere vedlikeholdskostnadene. Behovet for å behandle stadig større og komplekse datatyper og strukturer. Behovet for at personer som ikke hadde programmeringsbakgrunn og/eller som ikke hadde en detaljert forståelse for hvordan data ble lagret i en database, lett skulle få tak i de dataene som de ønsket. Selv om disse tre begrunnelsene ble laget for over fire tiår siden, er de like aktuelle for bedrifter i dag. Med tanke på hvordan forretningslivet er i dag, må de ulike selskapene ha tilgang til komplekse real-time rapporter. En løsning for dette og mange andre kommende krav/nødvendigheter bli dekket med XML-baserte databaser. 2.1 Historikk/utvikling DBMS er for mange det viktigste som har hendt innen informasjonsteknologien. Nesten alle organisasjoner, enten det er forretninger, staten eller forskningsinstitusjoner, er avhengig av et eller annet databasesystem. "data base" kom trolig til rundt 1960 som en del av Semiautomatic Ground Environment (SAGE) antiluftfart kommando- og kontrollsentral. SAGE var mer kompleks enn noe annet datasystem, og var det første systemet som kjørte i real-time. Som et resultat av dette måtte systemet presentere en up-to-date og konsistent representasjon av ulik informasjon for alle brukerne. Rand Corporation Group (SDC) begynte å utvikle softwaren og adopterte termlogien "data base" for å beskrive denne delte kolleksjonen av informasjon. Moderne databaseteknologi ved Høgskolen i Østfold våren

9 Fil-management systemer, ulikt "data base" konseptet, ble introdusert til verden som administrativt dataprosessering og har utviklet seg siden midten av Enkle og vanlige operasjoner som lesning og skriving av records og få det til å virke sammen med hullkortmaskiner ble veldig tidskrevende. Profesjonelle programmere brukte mye av sin tid til å lage rutiner, som fungerte meget dårlig, for å lese records fra tapes og printe linjer ut på papir. Som et resultat av dette ble gjenbrukbare "subrutinebiblioteker" for file management og rapportgenerering noe av det første som ble utviklet. Disse rutinene ble delt mellom programmerere og selskaper, og senere bygget inn i operativsystemer. Når termlogiene "data base" og "file management" ble standardisert av The Database Technology Group (DBTG) i 1968, ble de knyttet sammen og den nye termlogien ble "database management". Dette ble en kjærkommen "gave" til industrien. Programmer ble billigere å utvikle og lettere å vedlikeholde. Figur 1: Viser tidslinje på utviklingen av databaser. Hierarkiske databaser Ble utviklet midt på 60-tallet Sammenhenger mellom data kan struktureres som et hierarki Opererer med foreldre og barn (eier og medlem) Et barn har en forelder Information Management System (IMS) var det mest dominerende systemet Nettverksdatabaser Utviklet på slutten av 60- tallet/begynnelsen av 70-tallet Sammenhenger mellom data på den måten at en post i en fil kan eies av flere poster i flere filer Et barn kan ha flere foreldre Standardisert som Conference on Data Systems Languages (CODASYL-modellen) COBOL vanlig programmeringsspråk Relasjonsdatabaser Sammenheng mellom data bygger på en naturlig logisk sammenheng i stedet for fysiske pekere De første relasjonsdatabasene inneholdt: o Structured Query Language (SQL) o Query Language (QUEL) o Query-by-example (QBE) Moderne databaseteknologi ved Høgskolen i Østfold våren

10 Klient/tjener-arkitektur Organisering av et database-system slik at: o Flere kan arbeide mot samme database o Maskinvare-ressurser utnyttes bedre o Oppgaver fordeles mellom ulike maskiner Svært vanlig i dag Objekt-orienterte databaser Databasemodell som har fremstått som følge av behov for å lagre ustrukturerte data (lyd, bilder, video etc.) Få DBMS som er rent objekt-orienterte Har ikke fått særlig utbredelse o Mest innenfor spesialiserte anvendelser! Tegningsarkiv! Multimedia! geographic information system (GIS) Objekt-relasjonelle databaser Databasemodell som har hentet det beste fra objekt-orientering og relasjonsmodellen Oppstått fordi objekt-orienterte databaser har en del svakheter som ikke relasjonelle databaser har Web-databaser Databasesystemer med webgrensesnitt o Variant av klient/tjener arkitekturen Styrker: o Lett tilgjengelighet o Plattformuavhengig Farer: o Sikkerhet? Datavarehus Oppstått på grunn av behov for bedre rapporteringsmuligheter OLAP - On-line Analytical Processing Bruker flerdimensjonale databaser eller vanlige relasjonsdatabaser der databasen er designet som en dimensjonsmodell Moderne databaseteknologi ved Høgskolen i Østfold våren

11 3 XML-baserte databaser Som nevnt tidligere, kan et DBMS skreddersys for å møte en bedrifts spesielle behov. La oss se på et eksempel med e-business. E-business burde være koblet til en database hvis de skal spore kjøp eller tilbud. Databaser blir bruk av e-business til å lagre store mengder data på en strukturert måte. Det er ofte slik at kunder har behov for å få tilgang til data som allerede foreligger i databasen. En måte å gjøre dette på er å etablere kommunikasjon mellom e-business og den aktuelle applikasjonen. Her er det XML kommer inn i bildet. XML kan linke disse applikasjonene sammen slik at kunder og bedriften kan aksessere e-businessdatabasen. Siden ikke alle kunder og/eller bedriftene vil benytte den samme applikasjonen er det nødvendig å ha en oversetter. Selv om det finnes andre metoder, så er XML-databaser det mest ideelle for applikasjoner som krever en datamodell som er dynamisk av natur. XML-databaser passer også best for applikasjoner som må enkelt imøtekomme forandringer i strukturen, og for de applikasjoner der enkelhet og utviklingstiden er viktige faktorer. XML har flere funksjoner som gjør den til det mest naturlige valget når man skal vurdere en generell språkstruktur for en database. XML er et metaspråk som blir brukt for å definere andre språk og støtte flere plattformer. XML fungerer som en oversetter og databeskriver for dataen slik at systemer som vanligvis ikke kan kommunisere, kommuniserer. Fleksibiliteten til XML hjelper flere organisasjoner å koble seg sammen selv om de ikke snakker samme språk. Dette er veldig viktig for forretninger fordi det medfører at de kan koble seg til andre forretninger, likså som de kan koble sin egen organisasjon sammen. Dette medfører at de øker effektiviteten mot kommunikasjon og skaper fleksibilitet mellom applikasjonene. XML er nyttig for å linke sammen datasystemer som man vanligvis ikke kan linke sammen. Ved å utnytte funksjonaliteten i XML kan man spare betraktelige beløp. XML er lett å lære og har en bratt læringskurve. Ved å bringe inn et nytt språk, i en bedrift, som er både intuitivt og lett å lære kan hjelpe en bedrift til å lykkes. Samtidig er det slik at når man har lært seg XML, så vil man lære nærliggende språk som XHTML, HTML og WML mye lettere. XML er flyttbar. Flyttbarheten til XML gjør denne mer fordelaktig over andre mer tungvinte databasespråk. Siden XML er flyttbar kan den bli utviklet mye raskere enn andre språk. Moderne databaseteknologi ved Høgskolen i Østfold våren

12 Database: XML <SalesOrder SONumber="12345"> <Customer CustNumber="543"> <CustName>ABC Industries</CustName> <Street>123 Main St.</Street> <City>Chicago</City> <State>IL</State> <PostCode>60609</PostCode> </Customer> <OrderDate>981215</OrderDate> <Item ItemNumber="123"> <Description> <p><b>turkey wrench:</b><br /> Stainless steel, one-piece construction, lifetime guarantee.</p> </Description> <Price>9.95</Price> </Item> <Quantity>10</Quantity> </SalesOrder> Database : SalesOrder Order Item SONumber OrderDate CustNumber ItemNumber ItemNumber Price Description Quantity <p><b>turkey wrench:</b><br /> Customer CustNumber CustName Street City State PostCode 543 ABC Industries 123 Main St. Chicago IL Figur 2, XML koden I den øverste boksen forklarer dataelementet. Informasjonen som er skrevet med XML, blir transformert til en relasjonsdatabase slik som tabellene i den nederste boksen. Informasjonen går fram og tilbake mellom relasjonsdatabasen og XML. 3.1 Spørringer i XML-databaser Det er mange forskjellige språk, men vi har valgt å konsentrer oss om XPath og XQuery XPath W3C har utviklet denne spesifikasjonen og den inneholder en nodebasert modell for XMLdokumenter. Den definerer et XML-dokument som en trestruktur bestående av forskjellige typer noder som har forskjellige egenskaper. Xpath er et språk som kan brukes for å adressere deler av et XML-dokument. Det kan også brukes til å manipulere strenger, tall og booleans. Moderne databaseteknologi ved Høgskolen i Østfold våren

13 XPath inngår som en viktig del av XSLT. Dette er et språk for å spesifisere transformasjoner av et XML-dokument til en annen form (f.eks. til en annet XMLdokument eller html-dokument). I XSLT skjer enhver identifikasjon av XML-komponenter som skal gjøres til gjenstand for oversettelse/transformasjon, ved hjelp av Xpathuttrykk. XPath låner funksjoner til xslt og gjør det mulig å spesifisere nøyaktig hva en vil hente ut av et dokument. XPath har syntaktiske likheter med unix- og dos-"path"- spesifikasjoner og regulære uttrykk. XPath ble opprinnelig laget som en del av XSL, men ble generalisert som en egen anbefaling fordi den er generelt nyttig for navigering i trær. Et XPath uttrykk kan bestå av inntil tre deler: Axis, nodetest og predicate. For eksempel, child::bok[position()=1] som angir "det første elementet av typen bok som er barn av kontekstnoden". child bok axis angir hva slags relasjon vi ønsker i forhold til kontekstnoden nodetest angir hva slags type node vi er interesserte i position()=1 predicate plukker ut et utvalg av de nodene vi har kvalifisert ved axis og nodetest Hvis du ønsker å velge ut et sett med noder så kan man bruke følgende uttrykk for å navigere i treet i forhold til kontekstnoden (den noden vi befinner oss på) ancestor ancestor-or-self attribute child descendant descendant-orself following following-sibling namespace parent preceding preceding-sibling self Forfedre til kontekstnoden Forfedre til kontekstnoden og kontekstnoden selv Attributt til kontekstnoden Barn av konteksnoden Etterkommere av kontekstnoden Etterkommere av kontekstnoden og kontekstnoden selv Elementer som begynner etter konteksnoden Etterfølgende søsken til kontekstnoden Elementer som er i angitt namespace og er etterkommere av kontekstnoden Far til kontekstnoden Elemeneter som er avsluttet før kontekstnoden Tidligere søsken til kontekstnoden Konteksnoden Moderne databaseteknologi ved Høgskolen i Østfold våren

14 Noe eksempler på bruk av eller - Velger innholdet i attributtet show som ligger et steg opp (foreldrenoden) i forhold til konteksnoden child::name - Velger innholdet i elementet name som er en barnenode til konteksnoden child::dato[position()>1] - Alle elementene av typen date som er barn av konteksnode, untatt det første child::node() - Alle barn av kontekstnoden, uansett type Noen eksempler på bruk av funksjoner. position() - Posisjonen til kontekstnoden i det aktuelle nodesettet last() - Antall noder i det aktuelle nodesettet XQuery XQuery er et spørrespråk utviklet av W3C for å prosessere XML data. Xquery ble utviklet for å samle det positive fra de XML-spørrespråkene som allerede var kommet og for å tilfredsstille de krav og behov som brukerne av XML hadde. I følge spesifikasjonen til XQuery er XQuery designet for å være et lite og enkelt språk som er lett å implementere. Videre skal det være så fleksibelt at det dekker store deler av de XML-dokumenter som blir skrevet. XQuery gjør spørringer på XML uansett hvordan de er lagret: i databaser, filer, meldinger osv. Språket bygger på et annet XMLspørrespråk som heter Quilt. Quilt har hentet inspirasjon fra andre standarder som for eksempel Xpath, XML Query Language (XQL) og Structured Query Language (SQL). Eksperter forventer at XQuery skal gjøre for XML og XML-databaser som SQL gjorde for relasjonsdata og RDBMS: skaffe en leverandøruavhengig og kraftfull metode som er enkel å bruke for spørring og gjenfinning av XML-data.[12] XQuery er et funksjonelt språk hvor hver spørring er et uttrykk (expression). Det finnes syv typer uttrykk i XQuery: Path-uttrykk Element-konstruksjon FLWR-uttrykk Uttrykk som omfatter operatører og funksjoner Betingede-uttrykk Kvantifiserte-uttrykk Datatype-uttrykk Syntaks og semantikk til de forskjellige typene uttrykk varierer en del, noe som kan skyldes at designet har blitt påvirket fra mange hold. Moderne databaseteknologi ved Høgskolen i Østfold våren

15 W3C arbeider også med en alternativ versjon av XQuery, XQueryX, som har den samme semantikken, men som i stedet bruker XML basert syntaks. Flertallet av XML-databaseutviklere og noen relasjonsdatabaseutviklere har utviklet eller planlegger XQuery implementasjoner. Eksempler på dette er X-Hive Corporation som har utviklet en XQuery implementasjon på toppen av sin native XML-database, X-Hive/DB, mens IBM planlegger at deres DB2 skal ha støtte for XQuery. 3.2 XML-databaser Native XML Databaser De fleste bedrifter benytter en relasjonsdatabase for å lagre og spørre ut i fra deres data. Når man benytter XML så blir gjerne en hierarkisk database implementert og en Native XML database er ett eksempel på en slik modell. En Native XML database Definerer en modell for et XML dokument, i motsetning til dataene i dokumentet, og lagrer og henter dokumenter i henhold til modellen. Har et XML dokument som sin fundamentale lagringsenhet. Relasjonelle databaser har rader i tabeller som sitt fundamentale lagringsenhet. Det er ikke påkrevd at man har en underliggende fysisk lagringsmodell. For eksempel: Den kan bli bygget på en relasjonell-, hierarkisk- eller objektorientert database, eller så kan man bruke lagringsformater som indekserte komprimerte filer. En Native XML database er ikke en stand-alone database. Den forsterker DBMS med XML kode som resulterer en mer fleksibel og bedre presentasjoner av XML management systemer. Noen eksempler på hvor man kan benytte en Native XML database er ved medisinsk informasjonslagring, katalogdata, dokument management systemer, B2B logginformasjon og personlige databaser. Det er to måter en Native XML database kan lagre dokumenter. Den ene måten er tekstbaserte lagring og den andre måten er modellbasert lagring. Tekstbasert lagring lagrer hele XML dokumentet i tekstform, men modellbasert lagring lager en modell som består av 0 ere og 1 ere. Det er selvfølgelig fordeler og ulemper ved begge disse lagringssystemene. Tekstbasert lagring har muligheten til å lagre hele dokumentet og inkludere alle XML detaljer. På den andre siden kan et modellbasert system kun ha en oversikt over ha som finnes på overflaten av XML dokumentet og dermed lage et kart av dokumentet. En annen forskjell mellom de to lagringsmetodene er hastigheten på informasjonen som blir returnert. Tekstbasert lagring returnerer dokumentet i tekstform mens modellbasert lagring returnerer fragmenter av modellen. Moderne databaseteknologi ved Høgskolen i Østfold våren

16 Ut ifra definisjonen så er XML dokumenter ordrike. Grunnen til dette er fordi XML dokumentet definerer alle dataelementer gjennom taggene som man benytter. Lagring kan være et problem siden det er så ordrik, allikevel så må man vurdere prosessering hastigheten og størrelsen på XML dokumentet når man skal velge hvilken lagringsmetode man vil benytte. Det er også ulemper ved å benytte Native XML databaser. Sterke XML data i en relasjonell database management system har blitt bevist å være vanskelige, ueffektive, komplekse. Man introduserer også utførelse og utvidelses problemer etter hvert som man lagrer mer XML data i databasen. Samtidig så er ikke Native XML database det som er best å bruke hvis systemet til bedriften er veldig strukturert og ubøyelig. Figur 3, Denne figuren viser Tamino Native XML database Moderne databaseteknologi ved Høgskolen i Østfold våren

17 3.2.2 XML Enabled Databaser En XML enabled database er forskjellig fra en Native XML database og dens applikasjoner er mer gjenkjennelige for den vanlige IT-brukeren. Eksempler på applikasjoner er Microsoft Access 2002, FileMaker Pro og Oracle. XML enabled databaser er vanligvis relasjonelle databaser som inneholder forlengelse av data mellom XML dokumentet og seg selv. Det finnes to typer av XML dokumenter. Dette er data orienterte og dokument orienterte. XML enabled databaser er vanligvis designet for å lagre og returnere datasentrale dokumenter. Hvis man trenger å overføre data og ikke formatet eller hele dokumentet, så er XML enabled databaser ett bedre valg enn Native XML databaser. XML enabled databser skiller seg fra Native XML databaser på tre forskjellige måter: Native XML databser inneholder den fysiske strukturen av XML dokumentet XML enabled databaser sier at vi også tilbyr denne tjenesten, men dette er ikke tilfellet. [Bourret] Native XML databaser kan lagre XML dokumenter uten å vite organiseringen av dataene i XML dokumentet. Native XML databaser kan bare snakke på XML. XML enabled databaser kan tilby direkte datatilgang. For å finne ut hvilken type av XML database som passer for din bedrift, må kan ta hensyn til punktene over. For eksempel: Hvis bedriftens XML dokumenter ikke har noen ubøyelig organisasjon av dataene (schema), så er kanskje en Native XML Database tingen for bedriften. Dette på grunn av at den kan lagre uten å vite schemaet. Et annet eksempel kan gjelde integriteten til dataene. Referanseintegritet er kjernen til en relasjonell database modell system. For XML så er integriteten mindre veldefinert. Hvis dataintegritet er viktig for bedriftens database, så er en XML enabled database en god løsning siden den benytter seg av det beste fra en relasjonell DBMS og XML teknikkene. Moderne databaseteknologi ved Høgskolen i Østfold våren

18 3.3 Fremtiden for XML-baserte databaser XML-baserte databaser går en lys framtid i møte. Fra 2000 til 2001 vokste markedet med XML-baserte databasesystemer med 163.8%. [6] Da tradisjonelle bedrifter vokser og endrer sine forretningsmodeller, som for eksempel å legge funksjonalitet til en bedrifts webside slik at den kan ta for seg kunde transaksjoner, er det behov for programmeringsspråk som kan få databaser til å arbeide sammen. XML er ikke lenger bare en datatransport mellom bedrifter. XML har blitt et rammeverk for å utvikle løsninger som vil utvikle seg etter hvert som bedriftsmodellen forandrer seg når ulike organisasjoner gjør forretninger sammen. Om fremtiden til databaser er den tradisjonelle, relasjonell og SQL-modell med XMLteknologi lagt inni den, eller en ny XML-basert modell er et debattemne. Nettopp dette temaet ble diskutert på Software Development Conference & Expo Skjebnen til XML og SQL dominerte diskusjonen mellom representantene fra bedrifter som Oracle, Sun Microsystems og IBM. Don Chamerlain som er databaseteknologiforsker tror at XML vil bli det dominerende formatet for datautveksling. Han mener at relasjonelle databaser vil bli tilpasset med front ends for å støtte XML som et native format. Videre mener han at teknologer er i et tidlig stadium når det kommer til utvikling av XML-teknologier og han tror at det må jobbes mye med hvordan man skal indeksere XML-data. Rick Cattel, en meget anerkjent ingeniør på Sun og grunnleggeren til Object Database Consortium (ODCM), mener der i mot at XML ikke vil bli så dominerende som Don Chamberlain tror. Grunnen til dette mener han er at veldig få personer vil lagre XQuery data i et XML-format. Teknologisjefen på XQrl, Daniela Florescu, er optimistisk til utførelsen til XML-databaser. Hun tror at dokumenter vil bli lagret natively i XML og hun tror at en utvidelse av XQuery vil erstatte både Java og SQL. Diskusjonen kan oppsummeres slik: XML er/vil bli det dominerende formatet for datautveksling. Det er fleksibelt og selvbeskrivende. Applikasjoner vil ønske å kjøre spørringer på data på samme format som de utveksler dem. Det vil si at de ønsker å se alle kildene som XML. RDBMSer og SQL vil ikke forsvinne. De er gode for homogene data og i stedet vil de legge til XML front ends. Andre datakilder vil legge til XML front ends. Store RDMBS utviklere vil gjøre XML til en førsteklasseborger. Moderne databaseteknologi ved Høgskolen i Østfold våren

19 XML-RPC (Communication between components or service XML for communication between applications XML XML for presentation ( XSL,XSLT, Stylesheet ) XML for configuration (EJB,Tomcat) XML for communication between B-to-B Figur 4: XML i dag Moderne databaseteknologi ved Høgskolen i Østfold våren

20 4 Lore Lore er et DBMS for XML og semistrukturerte data. Det fokuserer på å definere et deklarativt språk for XML, utvikle ny teknologi for interaktive søk på XML-data og bygge en effektiv XML-spørringsprosessor. Tradisjonelle databasesystemer tvinger all data til å tilpasse seg et eksplisitt spesifisert, fast skjema. For mange nye databaseapplikasjoner er det to ulemper ved dette: 1. Data kan være uregelmessige og ikke passe til et fast skjema. I relasjonelle systemer er nullverdier typisk brukt når data er uregelmessige. Komplekse typer og arv i objekt-orienterte databaser gir mer fleksibilitet, men det er vanskelig å designe et passende objekt-orientert skjema for uregelmessige data. 2. Det kan være vanskelig å velge et korrekt skjema på forhånd. Strukturen på data kan utvikle seg raskt, dataelementer kan skifte type, eller data som ikke passer til tidligere strukturer kan bli lagt til. På grunn av disse begrensningene vil mange applikasjoner som bruker semistrukturerte data unngå å bruke DBMSer, selv om mange egenskaper ved et DBMS (ad-hoc spørringer, effektiv tilgang, samtidighets kontroll, crash recovery, sikkerhet osv.) ville være nyttige for slike applikasjoner. Dataene i Lore er ikke begrenset til et skjema og de kan være uregelmessige og ukomplette. 4.1 Historie Lore ble utviklet på Stanford University i 1995 av databasegruppen og ble erklært en suksess i år Lore ble først utviklet under en datamodell kalt Object Exchange Model (OEM). OEM er grunnleggende lik XML, men OEM støtter ikke DTD. DTD begrenser taggene og nested regler. Etter hvert ble Lore utviklet seg til å fullt ut støtte XML. Allikevel er videre utvikling av Lore nå et avsluttet kapittel. Lore er en full funksjonell DBMS-prototype, komplett med spørrespråk, sammensatte indekseringsteknikker, en cost-based query optimizer, flerbrukerstøtte, logging og gjenoppretting. Lore inkluderer også novel teknologier som DataGuides, håndtering av ytre data og Proximity søk. 4.2 Lore komponenter Lores arkitektur Arkitekturen til Lore er bygget opp slik at man kan få tilgang til databasen gjennom en rekke applikasjoner eller via Lore Application Program Interface (API). Det finnes et enkelt tekstbasert interface som primært blir brukt av systemutviklere, men det er også passende for å lære om systemets funksjonalitet og for å utforske små databaser. Moderne databaseteknologi ved Høgskolen i Østfold våren

21 Det grafiske interfacet er det primære interfacet for sluttbrukerne. Det tilbyr kraftige verktøy for å browse gjennom spørreresultater og en DataGuide for å se strukturen til data og for å formulere enkle spørringer. Et eksempel på DataGuide er å lagre ofte gjentatte spørringer og mekanismer for å vise multimedia atomic-typer som video, audio og java. Disse to interfacemodulene, i tillegg til andre applikasjoner, kommuniserer med Lore gjennom API. Resultatet blir returnert som et XML-objekt til APIen. Datainput kan være Update statement eller load files (for eksempel XML). Det er ingen beskrankninger på størrelse og struktur (tekst og multimedia). textual interface HTML GUI applications API Lore results queries query parsing preprocessing (Lorel to OQL) query plan generator query optimizer nonquery request data engine OEM object manager query operations utilities -dataguide mgr -loader -index mgr external data manager external read-only data src physical storage Figur 5, Viser Lores arkitektur Moderne databaseteknologi ved Høgskolen i Østfold våren

22 Query Compilation Layer parsing preprocessing (Lorel to OQL) query plan generator query optimizer Figur 6, Viser Query Compilation Layer Parser: Aksepterer en tekstlig representasjon av en spørring, transformerer den til et parsetre og sender parsetreet til preprocessor. Preprocessor: Transformerer Lorel-spørringer til OQL-lignende spørringer (OQL er enklere å prosessere). Query plan generator: Generer en spørringsplan og gir den til query optimizer. Query optimizer: Bestemmer om, og hvordan man skal bruke indekser. Data Engine Layer OEM object manager query operations utilities -dataguide mgr -loader -index mgr external data manager Figur 7, Viser Data Engine Layer OEM object manager: Oversetter mellom OEM-data og lavnivå fildata. Query operator: Eksekverer genererte spørreplaner. External data manager: Håndterer gjenervervelse av data fra eksterne kilder. 4.3 OEM Lores opprinnelige modell, OEM, er en enkel, selvbeskrivende, nested objektmodell som intuitivt kan bli sett på som en merket, direkte graf. OEM er spesielt nyttig for å representere semistrukturerte data [2]. Moderne databaseteknologi ved Høgskolen i Østfold våren

23 I OEM er alle entiteter objekter og hvert objekt har en Object Identifier (OID). Objektene kan enten være: Atomic: Ingen utgående piler og den inneholder verdier fra en av Lores grunnleggende atomictyper (integer, real, string, gif, java, audio osv.) Complex: Har utgående piler og verdien er et sett av <label, subobject>-par, hvor hver label gir en tekstlig beskrivelse av forbindelsen mellom objektet og dets subobjekt. L & oid X X = objektet L = label Figur 8, Viser hvordan et complex-object er bygget opp I en OEM-database er det ikke et bestemt skjema. All skjematisk informasjon er inkludert i labels og denne informasjonen kan skiftes dynamisk. I det grafiske bildet av en OEM-database er objektene noder i grafen. Complex objekter har utgående piler merket med relasjonen til deres subobjekter og atomic objekter inneholder deres verdier. Complex Atomic Figur 9, Viser en grafisk OEM-database Et enkelt objekt i OEM kan ha flere roller hvis det har flere innkommende piler, muligens med forskjellige navn (labels). Moderne databaseteknologi ved Høgskolen i Østfold våren

24 Eksempler på spørringer mot OEM: 1) Finn alle adressene til restauranter med zipkode (se figur 7). Lorel spørringen: SELECT Guide.restaurant.address WHERE Guide.restaurant.address.zipcode = ) Finn navnene og zip-kodene til alle cheap /billige restauranter (se figur 7). Lorel spørringen: Guide.restaurant.name, SELECT Guide.restaurant(.address)?.zipcode WHERE Guide.restaurant.% grep cheap? betyr at adressen er valgfri % vil matche alle subobjekter av restauranten grep vil returnere true hvis stringen cheap finnes 4.4 Lores XML Data Modell I Lores XML-baserte datamodell er et XML-element et par <eid, value>, hvor eid er en unik elementidentifikator og value er enten en atomic tekststreng eller en complex verdi som kan inneholde følgende fire komponenter: 1. En stringverditag som er lik XML-taggen for det elementet. 2. En ordnet liste med attributtnavn/atomic-valuepar, hvor hvert attributtnavn er en string og hver atomic-value har en atomisk type som for eksempel integer, real, string, ID, IDREF eller IDREFS. 3. En ordnet liste med krysslink-subelementer på formen <label,eid>, hvor label er en string. Krysslink-subelementer er introdusert via et attributt av typen IDREF eller IDREFS. 4. En ordnet liste med normale subelementer på formen <label, eid>, hvor label er en string. Normale subelementer er introdusert via leksikal nesting innenfor et XML-dokument. Det skilles mellom normale subelementer (punkt 4) og krysslink-subelementer (punkt 3) fordi modellen skal kunne støtte både litteral og semantisk modus. Semantisk modus blir brukt når brukeren eller applikasjonen ønsker å se databasen som en sammenkoblet graf. Grafen som representerer den semantiske modusen hopper over attributter av typen IDREF og IDREFS, og forskjellen mellom subelement og krysslinkpiler er borte. Litteral modus er tilgjengelig når brukeren ønsker å se databasen som et XML-dokument. IDREF og IDREFS attributter er synlige som tekstlige strenger, mens krysslinkpiler er usynlige. I litteralt modus er databasen alltid et tre. Moderne databaseteknologi ved Høgskolen i Østfold våren

25 XML-dokumentet blir enkelt kartlagt av datamodellen. Kommentarer og blanke rom mellom elementer blir oversett. Tekst mellom elementer blir oversatt til et atomic tekstelement brukt i XML for å unngå tekst som kan bli tolket som markup. Et dokumentelement blir oversatt til et complex dataelement slik at: 1. Taggen til dataelementet er taggen til dokumentelementet. 2. Listen av attributtnavn/atomic-valuepar i dataelementet blir avledet direkte fra dokumentelementets attributtliste. 3. For hver attributtverdi i av typen IDREF i dokumentelementet eller komponent i til en attributtverdi av typen IDREFS, er det et krysslink subelement <label, eid> i dataelementet, hvor label er det korresponderende attributtnavnet og eid identifiserer det unike dataelementet hvor ID attributtverdien er lik i. 4. Subelementene til dokumentelementet opptrer i rekkefølge som normale subelementer av dataelementet. Labelet for hvert datasubelement er taggen av dokumentsubelementet, eller Text hvis dokument subelementet er atomic. Når et XML-dokument er kartlagt av datamodellen er det passende å visualisere dataene som en direkte, labeled og ordnet graf. Nodene i grafen representerer dataelementer og pilene representerer subelementforbindelsen. Hver node som representerer et complex dataelement inneholder en tag og en ordnet liste av attributtnavn/atomic-valuepar. Atomic dataelementer inneholder stringverdier. Det er to typer piler i grafen: 1. Normale subelementpiler; labeled med taggen til destinasjons-subelementet. 2. Krysslinkpiler; labeled med navnet til attributtet som introduserer krysslinken. Figur 10, Viser et lite XML-dokument og en grafisk representasjon i datamodellen. Elementidentifikatorene (eids) opptrer inne i nodene og er skrevet som &1, &2 osv. Attributtnavn/atomic-value par er vist ved siden av assosierte noder (omgitt med {}), med IDREF attributter i italic. Subelementpilene er hele og krysslink pilene er stiplet. Rekkefølgen til subelementene er venstre-til-høyre. I semantisk modus ville ikke figuren inkluderer IDREF attributtene og i literalt modus ville ikke krysslinkene vært inkludert. Moderne databaseteknologi ved Høgskolen i Østfold våren

26 4.5 Lorel Query Language Lorel er spørrespråket til Lore DBMS. Det er et brukervennlig språk i SQL/OQL-stil. Lorel er et språk utviklet spesifikt for spørringer mot XML eller annen semistrukturert data. Lorel er basert på OQL og inneholder kraftige traverseringsoperatorer. Lorel foretar også utbredt bruk av typetvang for å gi intuitive resultater på alle spørringer på XML-data. Lorel har en utbredt bruk av automatisk typetvang for å håndtere heterogene og/eller typeløse data uten feil. Språket har også deklarativ path expression for å traversere semistrukturerte data. tuple / object assignment Treatment of singleversus setvalued attributes Type checking Type of value returned Wildcards Range variables Lorel OQL XSQL SQL Partial Total Total Total (outerjoins and nullvalued attributes allowed) Uniform Different syntax. Single-valued and setvalued N/A treatment (y.x versus v in path expression through y.x) treated differently implicit existential quantification None Strong Several options discussed Heterogeneous set of objects Over attribute lables An object or literal which may be a homogeneous set Homogeneous set of objects or a relation Explicit casts required in several cases Relation None Over attribute lables Over attributes of a single relation in a select clause Implicit Explicit Explicit Implicit Tabell 2: Viser en sammenligning mellom Lorel og andre query språk Når Lore gikk over til å støtte XML var den en rekke modifiseringer som ble foretatt i Lorel for å tilpasse seg til forskjellene mellom XML og OEM, og for å utnytte XMLfinessene. Moderne databaseteknologi ved Høgskolen i Østfold våren

27 Nedenfor er den en oversikt over disse modifiseringene: Skille mellom attributter og subelementer. Path expressions er de grunnleggende byggeblokkene i Lorel. En path expression i Lorel er en sekvens av labels, for eksempel DBGroup.Member.Project.Title (se figur 7), som kan inneholde wildcards og regulære uttrykk. Når spørringen blir evaluert blir path expressions sammenliknet med paths i databasegrafen. I XML utvides path expressions til å navigere både attributter og subelementer, og path expressions introduserer path expression qualifiers for å kunne skille mellom de to, når det er ønskelig. Qualification Symbol Eksempel (se figur 7) I semantisk modus I literalt modus Kun subelementer > DB.Member.>Name DB.Member.>Advisor &6 &3, &7 &6 &7 Kun DB.Member.@Name Smith Smith DB.Member.@Advisor empty (tom) m1 None (både subelementer og attributter) None DB.Member.Advisor &3, &7 &7, m1 Tabell 3: viser Path expression qualifiers Comparisons. Det er mange forskjellige sammenligninger som kan være brukbare i spørringer på XML-data. For eksempel kan konstanter bli sammenlignet mot attributtverdier eller mot tekst. Det kan være ønskelig å sammenligne mot serialisering av alle tekstelementer i et XML-subtre, og ignorere markup. I grafisk strukturerte data kan man ønske å se etter eid likheter. I motsetning til å støtte mange atskilte sammenligningsoperatorer behandler man i stedet hvert XML-komponent som en type, atomic value, enten gjennom default oppførsel eller via eksplisitt transformasjonsfunksjoner. Funksjon Beskrivelse Flatten(e) Ignorer alle tagger og serialiserer alle tekstverdier rekursivt i subtree med element e som rot. Concateneate(e) Konkatenerer alle umiddelbare tekstbarn av element e og ignorerer alle andre subelementer. Tag(e) Returner XML-tag til element e. Eid(e) Returner en stringrepresentasjon av eid til element e. XML(e) Transformer grafen ved å begynne med element e, til et XMLdokument. Tabell 4: Viser Innebygde funksjoner som brukes til å transformere elementer til strenger Siden det er upraktisk at en bruker må spesifisere funksjoner for hver sammenligning så settes det en defaultsemantikk basert på de mest vanlige og intuitive bruk: 1. For atomic (Text) element, er default verdien tekst. 2. For elementer som ikke har attributter og kun ett eller flere Textelementer som barn, er defaultverdien konkatineringen av barnas tekstverdier. 3. For alle andre elementer er default verdien elementets eid representert som en streng. Eksempel (se figur 7): Anta at vi ser etter en gruppe medlemmer som har advisor Ullman. I den originale versjonen av Lorel (til OEM) kan vi skrive DBGroup.Member.Advisor= Ullman. For XML-datamodellen må man skrive DBGroup.Member.Advisor.Text= Ullman. Det siste uttrykket vil gi det korrekte svaret, men den forrige sammenligningen vil gir også det korrekte svaret ved å ta fordel av punkt 2 i semantikken over. Moderne databaseteknologi ved Høgskolen i Østfold våren

28 De fleste Lorel-spørringer designet for en OEM-database kan umodifisert bli brukt på en lignende XML-database, slik som i eksempelet over. Range qualifiers. Lorel har blitt utvidet slik at uttrykket [range] kan bli lagt til hvilket som helst path expression komponent eller variabel. Range er en liste av enkeltnumre og/eller områder, for eksempel [2-4,7]. Når en slik range qualifier er lagt til en label i en path expression begrenser man matchene til dette området. For eksempel: SELECT y FROM DBGroup.Member x, x.office[1-2] y returnerer de to første Office-subelementene til hvert gruppemedlem. Når en range qualifier blir lagt til en variabel begrenses hele settet av bindende variabler til et spesifisert område. For eksempel SELECT y[1-2] FROM DBGroup.Member.x, x.office y returnerer de to første Office-elementene til alle medlemmene i databasen. Order-by clause. Resultatet av en spørring er en ordnet liste av eids som identifiserer de elementene valgt av spørringen. Hvis det ikke er en order-by klausul i spørringen er rekkefølgen uspesifisert. I noen applikasjoner kan det være viktig for spørringsresultatet at rekkefølgen er basert på XML-dokumentet, document-order. Funksjonaliteten i Lore er utvidet med et order-by document-order uttrykk. Transformations and structured results. Det er mer vanlig å bruke spørringer til å restrukturere XML-data enn det var i OEM. Det er derfor blitt introdusert to nye spørrespråk-konstruksjoner for å transformere data og returnere struktrurerte spørringsresultater. Den første konstruksjonen, with, er lagt til standarden select-fromwhere spørringsformen og var opprinnelig inkludert i Lorels view spesifikasjonsspråk. Når en with setning er tilstedet i en spørring vil resultatet vise alle data valgt av select setningen og all data som kan nås via hvilket som helst sett av path expressions med with setningen. Lorel har også blitt utvidet til å kunne støtte Skolem functions, en mer uttrykksfull restrukturering av data enn den som tidligere var i Lorel. I Lorel aksepterer en Skolem function en (valgfri) liste av variabler som argumenter og produserer et unikt element for hver tilknytning av elementene og/eller attributtene til argumentet/-ene. Når et nytt sett av tilknytninger til argumentene blir sendt inn i en Skolem function vil et nytt databaseelement bli opprettet og returnert. Skolem functions er ikke nytt med tanke på semistrukturert-spørrespråk, men de er nye til XML-versjonen av Lorel. Updates. I motsetning til mange andre semistrukturerte og objekt-orienterte spørrespråk støtter Lorel et utrykksfullt, deklarativt oppdateringsspråk. Moderne databaseteknologi ved Høgskolen i Østfold våren