• Keine Ergebnisse gefunden

XML Datenmodelle

N/A
N/A
Protected

Academic year: 2022

Aktie "XML Datenmodelle"

Copied!
5
0
0

Wird geladen.... (Jetzt Volltext ansehen)

Volltext

(1)

XML Datenmodelle

Web Informationssysteme Wintersemester 2002/2003

Donald Kossmann

Semistrukturierte Datenmodelle

• Beispiel: OEM (Objekt Exchange Model)

• Repräsentiere Dokument als annotierten Baum

– Knoten werden mit Ids, Typen, Werten annotiert – Kanten werden mit Tagnamen annotiert

– Referenzen (IDREFs) werden mit Kanten repräsentiert

• Entwickelt 1995, vor XML!

• Modell sieht keine Ordnung vor! (Wieso?)

• Modell sieht keinen Mixed Content vor! (Wieso?)

• Modell kann XML-mäßig erweitert werden

– Attribute, Kommentare, PIs, Ordnung, ...

– Siehe Lore Projekt in Stanford (Jenifer Widom)

OEM Beispielbaum

&o1

&o12 &o24 &o29

&o43

&96

&243 &206

&25

“Serge” “Abiteboul”

1997

“Victor” “Vianu” 122 133

paper book paper

references

references references

authortitle yearhttp author author

author title publisherauthor

authortitle page

firstname

lastname firstname lastname first

last Bib

complex object

atomic object

XML Infoset

• Ordne zu jedem Information Item Properties zu

• Information Items ~ Knoten eines OEM Baums

• Es gibt insgesamt 11 Information Items

– Document, Element, Attribute, ...

• Es gibt > 10 Properties

– Children, base URI, version, namespace, ...

– Properties bestimmen ein InfoItem eindeutig

• Verschiedene InfoItems haben andere Properties

• Werte von Properties werden durch Schemavalidierung beeinflusst

• (Für uns nur Durchgangsstation für Xquery DM.)

Beispiel

<?xml version = „1.0“ ?>

<book price = „69.95“ curr = „EUR“>

<title>Die wilde Wutz</title>

<author>D.A.K.</author>

</book>

Document InfoItem

• Children -> Liste von InfoItems

– InfoItems der PIs, Comments, Wurzelelement – Im Beispiel nur InfoItem von [book]

• Document Element -> Element InfoItem

– Im Beispiel InfoItem von [book]

• Notation, Unparsed entitities: ... Hier leer

• Base URI: URI des Dokumentes

– Vorsicht bei „streaming data“ (z.B. SOAP Nachricht)

• Standalone: leer (ansonsten „yes“ oder „no“)

• Version: im Beispiel 1.0

• Encoding scheme: default UTF-8

(2)

Element InfoItem (z.B. [book])

• Namespace Name: falls Elementtype zu NS geh.

– im Beispiel leer

• Local name: im Beispiel „book“

• Prefix: im Beispiel leer

• Children: im Beispiel: [title] und [author]

• Attributes: im Beispiel: [price] und [curr]

• Namespace Attributes: lokale NS Definitionen – Im Beispiel leer

• In-scope Namespaces: anwendbare NS Defs, ...

• Base-URI: ...

• Parent: im Beispiel: das Dokument InfoItem

Element InfoItem [title]

• Title hat als „children“ ein Char Info Item (Text)

• (Ansonsten keine Überraschungen)

• Das Char Info Item hat die folgenden Properties

– Wert des Textes (Wilde Wutz) in ISO 10646 Code – Whitespace handling des Elementes (yes or no) – Parent ist im Beispiel [title]

Attribute InfoItem (z.B. [price])

• Namespace Name, local name, prefix: ...

• Normalized value:

– Wert nach Normalisierung – Im Beispiel „69.95“

• Attribute Type:

– Nur DTD Typen erlaubt – Im Beispiel: PCDATA

• References:

– Bei IDREFs, die referenzierten InfoItems – Im Beispiel: leer

• Owner Element: Im Beispiel [book]

Xpath + Xquery Datenmodell

• Erweiterung vom XML InfoSet

• Formale Grundlage: „ordered trees“ (OEM + Ordnung)

• Entwickelt für Ergebnisse von Anfragen

• Anstatt 11 InfoItems - 7 Knotentypen

• Erlaubt Sequenzen

– Wichtig für Ergebnisse von Anfragen

• Hat das Konzept eines Fehlers (ERROR)

• Unterstützt Identität eines Knotens (z.B. für Vergleiche)

• Ordnung von Knoten unterschiedlicher Dokumente

• Wesentlich eleganter als InfoSet

• Voll kompatibel mit XML Schema; eigenes Typsystem

Vorsicht!!! Noch kein Standard. Letzter Stand: 8/02

Instanzen des Datenmodells

• Jede Instanz ist eine Sequence von Items

• Sequences sind Listen: Notation ( i1 i2 ... )

• Sequences sind immer flachgeklopft – ( 0 ( 1 2 ) 3 ) = ( 0 1 2 3 )

• Items sind entweder Knoten oder Atomic Values

• Es gibt 7 Arten von Knoten (siehe später)

• Atomic Values sind Instanzen eines primitiven (oder abgeleiteten) Typen: keine Listen!

• Sequences mit einem Item gleich Item – ( item ) = item

• Erstes Item einer Sequence hat den Index 1. (Nicht 0!)

Knoten und Accessors

• 7 Typen von Knoten

– Document, Element, Attribute, Namespace Processing Instruction, Comment, Text

– (Unexpanded Entity Reference, DTD, Unparsed Entity, Notation InfoItems fehlen)

• Jeder Knoten hat 11 Accessors (~ Property) – Node-kind: z.B. Document

– Name: z.B. „Book“

– String-Value, typed-value: siehe später

– Base-URI, Parent, Children, Attributes, Namespace: wie IS – Type: Instanz des Typsystems

– Unique-ID: siehe später

• Jeder Knoten hat Constructoren

(3)

Beispiel

<?xml version = „1.0“ ?>

<bo:book price = „69.95“ lang = „DE EN“

xmlns:bo = „http://www.Book.com“>

<title>Die wilde Wutz</title>

<author>D.A.K.</author>

<author>N.N.</author>

</bo:book>

• Annahme: Schema in www.Book.com fordert unqualifizierte Attribute und Subelemente

Document Node

- (?) Unique-ID

- Type

- Namespaces

- Attributes

( [book] [whitespace]) Children

- Parent

- Typed-Value

„whitespace“

String-Value

http://www.amazon.com Base-URI

- Name

„document“

Node-kind

Element Node: [book]

( 3 ) Unique-ID

anyType oder Book.com:BookType (PSV) Type

( [bo] ) Namespaces

( [price] [lang] ) Attributes

( [title] [author1] [author2] ) Children

( [document] ) Parent

() Typed-Value

„whitespace“

String-Value

http://www.amazon.com Base-URI

http://www.Book.com : book Name

„element“

Node-kind

Element Node: [title]

( 7 ) Unique-ID

anyType oder xsd:string (PSV) Type

( ) Namespaces

( ) Attributes

( [text] ) Children

( [book] ) Parent

( „Die wilde Wutz“ ) Typed-Value

„Die wilde Wutz“

String-Value

http://www.amazon.com Base-URI

title Name

„element“

Node-kind

Attribute Node: [lang]

( 5 ) Unique-ID

anySimpleType oder xsd:string* (PSV) Type

- Namespaces

- Attributes

- Children

( [book] ) Parent

( „DE EN“ ) oder ( „DE“ „EN“ ) (PSV) Typed-Value

„DE EN“

String-Value - Base-URI

lang Name

„attribute“

Node-kind

Namespace Node: [bo]

- (?) Unique-ID

- Type

- Namespaces

- Attributes

- Children

- Parent

- Typed-Value

„http://www.Book.com“

String-Value - Base-URI

bo Name

„namespace“

Node-kind

(4)

String Value vs. Typed Value

• Daumenregel: String Value entsteht durch Concatenation der String Values der Text Kinder

• Whitespace steckt in Text Knoten (s. [book])

• String Value, Type --> Typed Value

– Durch Schemavalidierung !!!

• Beispiele

– „DE EN“, anySimpleType -> ( „DE EN“ ) – „DE EN“, xsd:string* -> ( „DE“ „EN“ )

• Allerdings kann man vom Typed Value nicht auf den String Value schließen. Wieso???

Node ID, Equality, Order

• DM ordnet jedem Knoten eine ID zu

• ID bestimmt den Knoten eindeutig

– Vergleiche in Xquery verwenden somit die ID

• ID für totale Ordnung von Knoten

– Innerhalb eines Dokumentes: prefix – Zwischen Dokumenten:

• Implementationsabhängig aber konsistent

• Wenn Knoten k1 von Dokument d1 kleiner als Knoten k2 von Dokument d2, dann sind alle Knoten von Dokument d1 kleiner als alle Knoten von d2

DM in Baumrepräsentation

1. document

2. Text (WS) 3. book

7. Text (WS) 5. price

6. lang 8. title

9. Text

. . . 4. namespace

Typsystem

• Angelehnt an XML Schema

– Komplexe Typen

– Simple Typen

• anyType ist die Mutter aller Typen

• Inhalt von Elementen: Subtyp von „anyType“

• Inhalt von Attributen: Subtyp von „anySimpleType“

• Simple Type vs. Atomic Type

– Krücke gegen List Typen

Error

• War bis August noch eine gültige Instanz des Datenmodells und gültiges itemeiner Sequence

– ( 1 2 3 ERROR ) = ( ERROR )

• Ist jetzt verschwunden ...

• ???

Fazit

• OEM: saubere Theorie, idealisiert semi-strukt.

– Nicht mächtig genug für XML – In der akademischen Welt geblieben

• InfoSet: Einfaches Prinzip

– Nicht ausreichend für Anfragebearbeitung

• Xpath/Xquery Datenmodell

– Saubere Theorie aus der „OEM“ Tradition – Klares Mapping zum InfoSet (s. Übung) – Kein klares Mapping zu DOM (s. Kapitel 5)

• (Wir halten uns an Xpath/Xquery Datenmodell)

(5)

Übungsaufgaben

• Betrachten Sie eine (komplizierte) „book“ Instanz (aus Kapitel 1) und repräsentieren Sie diese in den drei Datenmodellen.

• Validieren Sie die „book“ Instanz mit einem „book“

Schema (nehmen Sie eine komplizierte Version mit Defaultwerten und Namespaces) und repräsentieren Sie die validierte Instanz in den drei Datenmodellen.

• Wie kann man generell das InfoSet auf das Xquery DM abbilden und umgekehrt? Gehen Sie die wichtigsten Properties der folgenden InfoItems durch: Document, Element, Attribute.

Referenzen

ÄHNLICHE DOKUMENTE

Element Node: price NodeList Text Node: 11.95 NodeList. Element

alle Zeichen erlaubt, die nicht ausdrücklich verboten.

Wer hat Kontrolle über das Parsen: die Anwendung oder der

• Sobald der Parser eine syntaktische Einheit analysiert hat, benachrichtigt er die Anwendung und übergibt die entsprechende Analyse.. • Beachte: „Push” bezieht sich wiederum

ƒ verallgemeinerte Auszeichnungssprache (generalized markup language): keine Tags vorgegeben, beliebige Tags möglich. ƒ Vorteil: beliebige

Wer hat Kontrolle über das Parsen: die Anwendung oder der

XSLT: nicht unbedingt nötig, da Transformation auf eigenem Server durchgeführt wird. XSLT: nicht unbedingt nötig, da Transformation auf eigenem Server

ƒ Beachte: Sowohl für xlink:actuate als auch für xlink:show können eigene Werte definiert werden... Klaus Schild, ©