1 xml und datenbanken kapitel 7: modellierung, teil 2 meike klettke universität rostock fakultät...

1

XML und DatenbankenKapitel 7: Modellierung, Teil 2

Meike Klettke

Universität Rostock

Fakultät für Informatik und Elektrotechnik

[email protected]

www.xml-und-datenbanken.de

2Meike Klettke


Vorlesung “XML und Datenbanken”

4) Generieren von XML-Dokumenten aus Datenbanken

Inhalt

Teil 1: Motivation, warum ein Schema erforderlich ist Schemata für XML-Dokumente

– DTDs– XML Schema

Teil 2: konzeptuelle Modellierung

– 1. Vorteile einer Modellierung– Methoden zur konzeptuellen Modellierung

• 2. Verwendung des Entity-Relationship-Modells• 3. Einsatz von UML• 4. Graphbasierte Verfahren• 5. eigener Ansatz

6. Ableitung von Schemainformationen aus XML-Dokumenten 7. Metriken 8. Weiterführende Literatur

- Vorteile der Modellierung- ERM- UML- Editoren- EMX- Reverse- Engineering- Metriken - Literatur

3Meike Klettke




1. Vorteile einer konzeptuellen Modellierung

Wunschvorstellung:– Modellierung auf einem höheren Niveau, das von der konkreten

Realisierung im Schema zunächst unabhängig ist– soll von Domainexperten verstanden werden– direkte Übersetzung in ein XML-Schema möglich– Enthält keine Implementierungsdetails– Schrittweise Konkretisierung– Graphische Darstellung

Ziel: – höhere Qualität der Dokumente - exakteres Vorgehen

es gibt noch keine akzeptierte Modellierungssprache für denEntwurf von XML/DTD/XML-Schemata. Häufig wird auch „Reverse-Engineering“ angewendet, aus XML-Dokumenten erfolgt die Ableitung der DTD durch Tools.


4Meike Klettke




Modelle

Modelle werden heute in allen Wissenschaftsgebieten eingesetzt

weit akzeptierte allgemeine Modelltheorie wurde 1973 von Herbert Stachowiak vorgeschlagen.

Modellbegriff darin ist domänenübergreifend anwendbar, Modell hat drei Eigenschaften:– Abbildung: Modell ist immer ein Abbild von etwas, eine

Repräsentation natürlicher oder künstlicher Originale, die selbst wieder Modelle sein können.

– Verkürzung: Ein Modell erfasst nicht alle Attribute des Originals, sondern nur die jeweils relevanten

– Pragmatismus: Orientierung am Nützlichen, Fragen wie Für wen?, Warum? und Wozu? werden berücksichtigt

5Meike Klettke




Beispiel eines Modells

maßstabgetreues 1:100-Modell des Stephansdoms originalgetreue, detailreiche Modell für blinde und sehbehinderte

Menschen Auch Kindern wird es damit erleichtert, die Dimensionen der Kirche zu

"begreifen"

6Meike Klettke




Modellierungsmethode für XML

einige Vorschläge für XML-Modelle und Modellierungmethoden

Ziele dabei sollen sein:– so einfach wie möglich– so komplex wie nötig– Vollständige XML-Schema-Unterstützung– Verwendung von Defaultwerten und Voreinstellungen

entgegengesetzte Eigenschaften

7Meike Klettke




Möglichkeiten zur Modellierung

??konzeptuelle

Ebene

date

nzen

trie

rtse

mi-

stru

ktur

iert

dok-

zent

riert

XML-Editorenbaumbasierte

ORMER

Modellierung vonStruktur

UML

Struktur und InhaltModellierung von

Struktur und InhaltModellierung von

??konzeptuelleEbene

Konzeptueller

Entwurf von XML-Dokumenten


8Meike Klettke




2. Entity-Relationship-Modell für den Datenbankentwurf/ 1

Für den DatenbankentwurfName Ort

Name ISBN

Titel ISBN

Verlag

gibt_heraus

Buch

schreibt

Autor

ISBN ID

Name Vorname ID

ISBNBuch

Autor

Verlag

schreibt

[1,n]

[1,1]

[1,n]

Name

Ort

Titel

gibt_heraus

[0,n]

Name

VornameID


9Meike Klettke




Entity-Relationship-Modell für den Datenbankentwurf/ 2

jede Darstellung im ER findet Entsprechung in relationalen Datenbanken

Entwurf auf einen abstrakteren Level (konzeptuell) Eindeutige Abbildung der Entity-Relationship-Diagrammes

Alle relevanten Informationen einer relationalen Datenbank können aus dem Entwurf abgeleitet werden


10Meike Klettke




Entity-Relationship Modell für DTDs

Für den Entwurf von DTDs

ISBNBuch

Autor

Verlag

schreibt

[1,n]

[1,1]

[1,n]

Name

Ort

Titel

gibt_heraus

[0,n]

Name

VornameID

<!ELEMENT Buchanwendung (schreibt*, Verlag*,Autor*)>

<!ELEMENT Verlag (gibt_heraus*)>

<!ATTLIST Verlag Name ID #REQUIRED

Ort CDATA #REQUIRED>

<!ELEMENT gibt_heraus (Buch)>

<!ELEMENT Buch EMPTY>

<!ATTLIST Buch Titel CDATA #REQUIRED

ISBN ID #REQUIRED>

<!ELEMENT schreibt EMPTY>

<!ATTLIST schreibt Buch_ref IDREF #REQUIRED

Autor_ref IDREF #REQUIRED >

<!ELEMENT Autor EMPTY>

<!ATTLIST Autor Name CDATA #REQUIRED

Vorname CDATA #REQUIRED

ID ID #REQUIRED>


11Meike Klettke




Entity-Relationship Modell für XML-Schemata /1

<Buchanwendung>

<schreibt Buch_ref="i1234-5678-9" Autor_ref="a0007"/>



<Verlag Name="dpunkt" Ort="Heidelberg">

<gibt_heraus>

<Buch Titel="XML und Datenbanken" ISBN="i1234-5678-9"/>

</gibt_heraus>

<gibt_heraus>

<Buch Titel="Web und Datenbanken" ISBN="i9876-5432-1"/>

</gibt_heraus>

</Verlag>

<Autor Name="Meyer" Vorname="Holger" ID="a0007"/>

<Autor Name="Rahm" Vorname="Erhard" ID="a0008"/>

<Autor Name="Vossen" Vorname="Gottfried" ID="a0009"/>

</Buchanwendung>

ISBNBuch

Autor

Verlag

schreibt

[1,n]

[1,1]

[1,n]

Name

Ort

Titel

gibt_heraus

[0,n]

Name

VornameID


12Meike Klettke




Entity-Relationship Modell für XML-Schemata/ 2

Abbildung nicht einfach nachvollziehbar Unterschiedliche Behandlung der Kardinalitäten 1:n und n:m Abbildung der Schlüssel auf ID (nicht das identische

Konzept) Keine Möglichkeit zur Darstellung von Alternativen, Mixed

Content und ANY Entity-Relationship-Modell bietet Konzepte, die sich nicht

einfach abbilden lassen und es gibt Konzepte in XML, die sich nicht im Entity-Relationship-Modell darstellen lassen

Verwendet werden kann also „erweiterte Untermenge“


13Meike Klettke




3. Einsatz von UML – Klassendiagrammen /1

Darstellung von Elementdeklarationen durch Klassen

ortplzstrassehausnummerpostfach [0..1]

adresse

hausnummer, postfach?><!ELEMENT (ort, plz, strasse,


14Meike Klettke




Einsatz von UML –Klassendiagrammen /2

Darstellung vom Inhaltsmodell Sequenz Deklaration von Attributen (UML-Konstrukt: Aggregation, Teil-Ganzes-Beziehungen zwischen einem Aggregat

und seinen Teilen)

autor CDATA #IMPLIED> datum CDATA #IMPLIED<!ATTLIST hotel url CDATA #REQUIRED

<!ELEMENT hotel (hotelname, kategorie?, adresse>

hotelname kategorie adresse0..1

hotel<<meta>> url:CDATA<<meta>> datum[0..1]:CDATA<<meta>> autor [0..1] CDATA


15Meike Klettke




Einsatz von UML –Klassendiagrammen /3

Darstellung von Alternativen (UML-Konstrukt: Generalisierung, Ist-Ein-Beziehungen zwischen Klassen)

pension | ferienwohnung )><!ELEMENT unterkunft ( hotel |

{disjoint}

unterkunft

ferienwohnungpensionhotel


16Meike Klettke




Komplexeres Beispiel

preisehotelname telefon0..1

adresse1..n

kategorie

{choice : 0 .. n}

plz ort strasse hausnummer doppelzimmer apartment<<content>>#PCDATA

einzelzimmer

{sequence : 1}

hotel<<meta>> url:CDATA<<meta>> datum[0..1]:CDATA<<meta>> autor [0..1] CDATA

{sequence : 1}

<!ELEMENT hotel (hotelname, kategorie?, adresse, telefon+, preise)>

<!ATTLIST hotel url CDATA #REQUIRED><!ATTLIST hotel datum CDATA #IMPLIED><!ATTLIST hotel autor CDATA #IMPLIED><!ELEMENT hotelname (#PCDATA)><!ELEMENT kategorie (#PCDATA)><!ELEMENT telefon (#PCDATA)>

<!ELEMENT adresse (ort, plz, strasse, hausnummer)><!ELEMENT ort (#PCDATA)><!ELEMENT plz (#PCDATA)><!ELEMENT strasse (#PCDATA)><!ELEMENT hausnummer (#PCDATA)><!ELEMENT preise (#PCDATA | einzelzimmer | doppelzimmer | apartment )*><!ELEMENT einzelzimmer (#PCDATA)><!ELEMENT doppelzimmer (#PCDATA)><!ELEMENT apartment (#PCDATA)>


17Meike Klettke




Bewertung

In beiden Fällen „erweiterte Untermenge“ wird eingesetzt, das heißt: Einige Konstrukte des ERM bzw. aus UML lassen sich nicht

adäquat abbilden– Beispiel n:m-Kardinalitäten

Andere Bestandteile einer DTD oder eines XML Schemas lassen sich nicht geeignet darstellen– Beispiel mixed content


18Meike Klettke




4. Verwendung von Editoren

Visualisierung der Baumstruktur der XML-Dokumente oder der Graphstruktur der Schemata

Beispiel

XML Spy


19Meike Klettke




5. CoDEX-Modell (für Entwurf und Evolution)

Grundbestandteile:

– Elemente,

– Attributgruppen,

– einfache und komplexe Typen,

– Module weitere spezielle Knoten für Inhaltsmodelle

– Sequenz, Alternative, mixed Content Verbindungen dazwischen: gerichtete und

ungerichtete Kanten Rootknoten= „Einstiegsknoten“ Beschreibungen zu den Knoten (z.B.

Wertebereichsbeschreibungen, facets)

20Meike Klettke




CoDEX - Beispiel

Graph, verschiedene Knotenarten von Knoten (Elemente, Module, Inhaltsmodelle, Typen)

Rootknoten (ausgezeichnete Elemente oder Module)

Operationen darauf: – Eigenschaften testen

(erlaubte Zustände)– Übersetzung in XML-

Schema, dazu Übersetzungsreihenfolge bestimmen

21Meike Klettke




Verwendung von Modulen im CoDEX-Modell Graphische Notation: wie UML-packages Zuordnung von XML-Schemata (können auch durch den

CoDEX-Editor erzeugt sein)

22Meike Klettke




Model Driven Engineering

Automatische Modellvervollständigung Beispiel:

Ergänzen von – simple Types– complex Types– Inhaltsmodellen

23Meike Klettke




Eigenschaften der Modellierungsmethode

Einfache graphische und formale Notation Übersetzung in XML-Schemata Vorteile:

– Vollständige Modellierung von XML-Schemata möglich (einiges fehlt in der Implementierung: Typhierarchien, list, union)

– Modularisierung möglich Nachteile:

– kein richtiges „konzeptionelles“ Modell, es fehlt die Vereinfachung dafür aber automatische Vervollständigung vereinfachter Modelle Weitere Eigenschaften

– Reverse-Engineering: vorhandenes XML-Schema -> CoDEX

– Einsatz des Verfahrens zur Evolution (Weiterentwicklung, Propagieren der Änderungen, ...)

24Meike Klettke




Formales Modell von CoDEX

Graph, mehrere Arten von Knoten – Elemente– Attributgruppen, – Module– einfache Typen– komplexe Typen– Inhaltsmodelle (sequence, choice, all)

zwei Arten von Kanten: gerichtet und ungerichtet– ungerichtete Kanten nur während des Entwurfes

Rootknoten (gekennzeichnete Elemente oder Module)


25Meike Klettke




Übersetzung: CoDEX in XML-Schema

zunächst: – Modellprüfung und

– Modellvervollständigung dann Übersetzung:

– Darstellen der Adjazenzmatrix zum Graphen, in dieser sind die Knoten und ihre Kanten enthalten

– Übersetzung beginnt bei den Rootkonzepten

– im nächsten Schritt Übersetzung der Konzepten, von denen eine Kante zu den Rootkonzepten besteht

– Übersetzung erfolgt bis alle Knoten des Graphen übersetzt sind

– erzeugt wird Schema im Modellierungsstil Venetian Blind


26Meike Klettke




Weitere Eigenschaften des Entwurfstools

Reverse-Engineering ist möglich erster Schritt:

– Umwandlung eines Schemas in Modellierungsstil Venetian Blind

zweiter Schritt:– Erstellen des zugehörigen CoDEX-Modells (Verwenden

eines automatischen Layouts)


27Meike Klettke




damit

verschiedene Entwurfsverfahren vorgestellt alle haben auch Nachteile

– entweder nicht alles darstellbar, was XML-Schema darstellen kann oder

– nicht einfach genug, weil zu detailliert bisher außer den XML-Editoren keine Methode etabliert

jetzt: weiterer Punkt, wenn zu XML-Dokumenten kein Schema bekannt ist, so kann dieses aus den Dokumenten abgeleitet werden

Verfahren dazu folgen anschließend

28Meike Klettke




Ableitung von Schema-Informa-tionen aus Dokumentkollektionen

Ableitung eines Schemas für ein oder mehrere gegebene XML-Dokumente

Reverse-Engineering

Beispielkollektion ausreichend groß und vielfältig Sonst ist die abgeleitete DTD zu speziell abgeleitete Schemabeschreibung soll durch einen

Anwender überprüft werden


29Meike Klettke




Schemaableitung (DTD)

Die folgenden 7 Folien stammen im Wesentlichen aus dem Hauptseminarvortrag von Matthias Brückner.

Mögliche Herangehensweisen Umwandlung der textuellen Repräsentation der

Dokumente (XTRACT) Betrachtung der Dokumente als XML–Trees (DTD-Miner)Eingabe Menge von XML-DokumentenAusgabe DTD für die gegebene Dokumentkollektion Ergebnis soll

– allgemein gehalten sein (für weitere XML-Dokumente), aber– auch speziell genug für die betreffende XML-Kollektion


30Meike Klettke




DTD-Miner

DTD Generation Module– Document Tree Extraction Sub-Module

• Umwandlung der XML Dokumente in eine Baumstruktur

– Spanning Graph Construction Sub-Module• Zusammensetzen der Dokumentbäume zu einem

zusammenhängenden Graphen– DTD Construction Sub-Module

• Ableiten einer DTD aus dem zusammenhängenden Graphen

• Anwendung von Heuristiken


31Meike Klettke




DTD-Miner (2)

XMLTrees– Elemente Knoten– Parent-Child Beziehungen gerichtete Kanten– Jeder Baum erhält eine Eindeutige DocID– Jedem Knoten wird eindeutige NodeID zugeordnet


32Meike Klettke




DTD-Miner (3)


33Meike Klettke




DTD-Miner (4)

Der zusammenhängende Graph– XMLTrees werden nacheinander zusammengelegt– Gleiche Childelemente auf gleichen Knoten abgebildet– Abspeichern der NodeIDs in den Knoten und in den

entspringenden Kanten– beim mehrfachen Auftreten eines Childelementes wird

eine zusätzliche Kante eingefügt


34Meike Klettke




DTD-Miner (5)


35Meike Klettke




DTD-Miner (6)

Heuristische Regeln

1. Define Optionality• Bestimmung, ob Element opional ist, oder nicht

2. Merge Repeat• Bestimmung sich wiederholender Alternativen

3. Define Group• Bestimmung sich wiederholender Gruppen


36Meike Klettke




DTD-Miner (7)

optionales Element, wennfür alle Kanten, die zwischen zwei Knoten existieren gilt:die Vereinigung der Kantenlabels ist eine echte Teilmenge der Labels des Startknoten(der Zielknoten ist dann optional)

mehrfach auftretendes Element,Mehrere Kanten zwischen zwei Knoten


37Meike Klettke




DTD-Miner (8)

Zur Bestimmung der optionalen Elemente:

• Zwischen Knoten a und d existiert eine Kante mit dem Kantenlabel 1. Die (Mengen-) Vereinigung aller Kantenlabels ist dann {1} und es gilt: {1} ⊂ {1,7}, also ist d optional.

• Weiteres Beispiel: Zwischen b und c existieren 3 Kanten, die Vereinigung der Kantenlabels ist {2,8} {2} {2} = {2,8} ∪ ∪Diese Menge ist keine echte Teilmenge der Knotenlables({2,8} {2,8}), ⊄damit ist das Element c nicht optional.


38Meike Klettke




Beispiel zur Schemaableitung /1

<buch>

<autor><vorname></vorname><nachname></nachname></autor>

<autor><vorname></vorname><nachname></nachname></autor>

<titel></titel>

<verlag></verlag>

<jahr></jahr>

</buch>


39Meike Klettke





<buch>

<editor><vorname></vorname><nachname></nachname></editor>

<titel></titel>

<verlag></verlag>

<jahr></jahr>

<auflage></auflage>

</buch>


40Meike Klettke





mehrfaches Auftreten: mehrfache Kanten zwischen zwei Knoten

optionales Auftreten: Kantenbeschriftung enthält nicht alle IDs des Knotens, von dem die Kante ausgeht


41Meike Klettke





abgeleitete DTD<!ELEMENT buch (autor*, editor?, titel, verlag, jahr, auflage?)

<!ELEMENT autor (vorname, nachname)>

<!ELEMENT editor (vorname, nachname)>


42Meike Klettke




Teilaufgaben

XML-Dokumente

beschreibungSchema- Schema-

beschreibung

ÜberprüfungÄnderung

Erweiterung

AbleitungSchema-

durch Tools

durch denBenutzer


43Meike Klettke




Differenzen zwischen abgeleiteter DTD und Original-DTD

Original-DTD Abgeleitete DTD

zu spezieller Quantifizierer

<!ELEMENT buch

(.., editor*, ..).>

<!ELEMENT buch

(.., editor?, ...>)

fehlende Elemente

<!ELEMENT buch (..untertitel?..)>

anderes Inhaltsmodell

<!ELEMENT buch

( _ | _ | _ | _ )*>

<!ELEMENT buch

( _ , _ , _ , _)>

Ursache: • zu wenige XML-Dokumente, • enthalten nicht alle Spezialfälle der Anwendung


44Meike Klettke




Metriken - Motivation /1

Viele XML Anwendungen benötigen ein Schema,

es gibt verschiedene Möglichkeiten, es zu bekommen:

Benutzer kann dieses direkt definieren es kann mit Hilfe von Entwurfswerkzeugen

abgeleitet werden, z.B. aus einem ERM ein existierendes Schema kann verwendet (und

angepasst) werden es kann aus Beispiel-XML-Dokumenten abgeleitet

werden


45Meike Klettke





Evaluation des Schema

Dabei stellen sich Fragen wie: Ist das Schema einfach zu verstehen? Ist das Schema einfach zu verwenden? Ist das Schema einfach zu verändern?

Metriken versuchen, diese Fragen zu beantworten und

verschiedene Eigenschaften eines Schemas abzuschätzen


46Meike Klettke





Zwei Fragestellungen existieren:

1. Erfüllt ein Schema die Anforderungen einer Anwendung

2. Ist das Schema einfach zu verstehen/zu warten/..

Metriken beantworten (nur) die zweite Frage.

Schema1

Schema2

Metriken

XML

Anwendung


47Meike Klettke




Softwaremetriken

Verwendung von Metriken zur Qualitätsbewertung

Qualitätsmodell

Metriken

Merkmal

Teilmerkmal

ISO/IEC9126

FunktionalitätZuverlässigkeitBenutzbarkeitEffizienzÄnderbarkeitÜbertragbarkeit

Merkmale der ISO 9126

48Meike Klettke




Software Metriken

Die gleiche Methode gibt es im Bereich Software

Merkmale Untermerkmale Metriken

FunktionalitätZuverlässigkeitBenutzbarkeitEffizienzÄnderbarkeitÜbertragbarkeit

AnalysierbarkeitVeränderbarkeit StabilitätTestbarkeit

Verständlichkeit ErlernbarkeitBedienbarkeit

McCabe-Metrik

Fan-Out-Metrik

Halstedt Metrik

49Meike Klettke




Klassifikation von Software Metriken

Produktmetriken

bewerten das Schema von XML-Dokumenten Ressourcenmetriken

bewerten die Ressourcen, die zur Verarbeitung von XML-Dokumenten erforderlich sind

Prozessmetriken

bewerten den Entwurfsprozess eines Schemas


50Meike Klettke




Produktmetriken -1

Visualisieren einer DTD durch einen Graphen<!ELEMENT publications (book | article)*>

<!ELEMENT book (author, title, content)>

<!ATTLIST book isbn CDATA #REQUIRED>

<!ELEMENT article (title, author+,

content, conference)>

<!ELEMENT title (#PCDATA)>

<!ELEMENT author (#PCDATA)>

<!ELEMENT conference (#PCDATA)>

<!ELEMENT content (section+, references*)>

<!ELEMENT section (#PCDATA)>

<!ELEMENT references (publications)>

Ableitung von Produktmetriken aus dem Graphen

public.

section

conf.

ref.

contenttitleauthors

articlebook

isbn


51Meike Klettke




Produktmetriken - 2

Folgende Produktmetriken werden im nächsten Teil

vorgestellt: Größe Strukturkomplexität Strukturtiefe Fan-In Fan-Out

Sie bewerten die Eigenschaften Verwendbarkeit und

Änderbarkeit.


52Meike Klettke




Größe

Bewertet wird Anzahl der Knoten (Elemente, Attribute, Entities) Diese beeinflusst die Verständlichkeit und Verwendbarkeit

public.

section

conf.

ref.

contenttitleauthors

articlebook

isbn


53Meike Klettke




Strukturkomplexität

(Alle Merkmale, die ein Schema komplex machen)

Quantifizierer + und * same content elements Rekursionen und IDREF-Attribute

beeinflusst die Verständlichkeit und Verwendbarkeit

public.

section

conf.

ref.

contenttitleauthors

articlebook

isbn


54Meike Klettke




Strukturtiefe

Tiefe=0

Tiefe=1

Tiefe=2

Tiefe=3

Tiefe für jeden Knoten Maximale Tiefe des Graphen

beeinflusst Effizienz, Verwendbarkeit (Pfadlänge zur Adressierung von Elementen/Attribute hängt davon ab)

public.

section

conf.

ref.

contenttitleauthors

articlebook

isbn


55Meike Klettke




Fan-Out-Metrik

Anzahl von Kindknoten

Gibt an, welche Elementdeklarationen komplex sind beeinflusst die Verständlichkeit und Verwendbarkeit

public.

section

conf.

ref.

contenttitleauthors

articlebook

isbn


56Meike Klettke




Fan-In-Metrik

Anzahl der Vorgängerknoten

Wie oft wird ein Element wiederverwendet Beeinflusst die Veränderbarkeit eines Schemas

public.

section

conf.

ref.

contenttitleauthors

articlebook

isbn


57Meike Klettke




Produktmetriken für das Beispiel

Größe Komplexität Max Tiefe Max Fan-Out

Max-Fan-In

10 9 3 4 2

public. book isbn article title author conf. content section ref.

Tiefe 3 2 0 2 0 0 0 1 0 (Zyklus)

Fan-Out 2 4 0 4 0 0 0 2 0 1

Fan-In 1 1 1 1 2 2 1 2 1 1

Metriken des gesamten Schemas:

Metriken der einzelnen Elemente und Attribute


58Meike Klettke




Ressourcenmetriken

Bewerten die Ressourcen, die erforderlich sind, um Schema

auswerten zu können:

Speicherplatzbedarf Zugriff durch XPath (Zeit) Auswertung durch DOM-Prozessoren (Zeit, Speicherplatz) Auswertung durch SAX-Prozessoren (Zeit)

und damit die Eigenschaften Funktionalität und Effizienz


59Meike Klettke




Speicherplatzbedarf

Kurze Tagnamen (für Elemente und Attribute verringern den Speicherplatzbedarf)

Dieses Merkmal ist aber gegenläufig zur

Lesbarkeit,

sorgfältiges Abwägen beider Eigenschaften

Darstellung von Attributen ist kompakter als von Elementen

Keine tiefen Schachtelungen


60Meike Klettke




Zugriff durch XPath

Flache Hierarchien bedeuten auch keine langen Pfade zum Zugriff auf Elemente und Attribute (Eigenschaft Tiefe der Produktmetriken)

Wichtig ist, dass alle Informationen, die ausgewertet werden sollen, mit Markup versehen sind (feingranular getagt)

Beispiel (oder besser Gegenbeispiel)<preise>

Von Mai bis September 99 Euro, Im Winterhalbjahr ab 79 Euro.</preise>

Das ist bei Preisberechnungen nicht auswertbar


61Meike Klettke




Abschätzung XPath/XQuery-Anfragen

bestimmte Eigenschaften der Produktmetriken lassen sich einsetzen, um den Aufwand von XPath/XQuery-Anfragen abzuschätzen

Beispiel: – Tiefe = maximale Pfadlänge = Anzahl der einzelnen

Schritte = Anzahl der Joins bei generischer Speicherung

– Größe: Anzahl der zu speichernden Tupel bei generischer Speicherung


62Meike Klettke




Auslesen mit DOM- und SAX-Prozessoren

Attribute leichter als Elemente auslesbar

Besonders bei SAX wichtig:– Eindeutige Tagnamen, damit das Auslesen möglichst

unabhängig von den Umgebungsinformationen erfolgen kann


63Meike Klettke




Zusammenfassung

Hier gibt es noch sehr wenige Arbeiten Universelle Metriken sind schwer zu bestimmen Metriken sind besonders im Zusammenhang mit einer

Anwendung (Speicherung von XML, Anfragerealisierung, Transformation, ...) sinnvoll.

„Not everything that counts can be counted,

and not everything that can be counted counts.“

Albert Einstein


64Meike Klettke




Tools

Editoren (Transformation von Schemasprachen, Ableiten von Schema aus Dokumenten, Test der Gültigkeit bzgl. eines Schemas) XMLSpy (www.xmlspy.com) XML Authority (

www.extensibility.com/xml_resources/modeling.htm)

XML-Prozessoren XML Schema Quality Checker von IBM alphaworks (

www.alphaworks.ibm.com/tech/xmlsqc) XML Schema Validator von Oracle (technet.oracle.com

/tech/xml/)


65Meike Klettke




Literatur /1

XML Schema:– www.w3.org– „Web & Datenbanken“ – Erhard Rahm, Gottfried Vossen,

Kapitel 2 oder– Harald Schöning „XML und Datenbanken“– Eric van der Vilst: „XML Schema“

konzeptueller Entwurf– mit ER: Sebastian Dolke, Hauptseminar 2002– mit UML Alf-Christian Schering, Hauptseminar 2002– Kazakos et al: "Datenbanken und XML"– ...

XML-Editoren– Vergleich verschiedener Editoren: Mintert, Wilde, Behme: iX

(8)2002


66Meike Klettke




Literatur /2

Schemaableitung „XTRACT: A System for Extracting Document Type

Descriptors from XML Documents“ – Minos Garofalakis, Aristides Gionis, Rajeev Rastogi, S. Seshadri, Kyuseok Shim

„DTD-Miner : A Tool for Mining DTD from XML Documents“Chuang-Hue Moh, Ee-Peng Lim, Wee-Keong Ng

Diplomarbeit: Christian Romberg Matthias Brückner, Hauptseminar 2002Metriken Sahuguet/Choi Diplomarbeit: Lars Schneider
