Bäume als Datenmodelle

Präsentation zum Thema: "Bäume als Datenmodelle"—  Präsentation transkript:

1 Bäume als Datenmodelle
Frank Schmidt Betreuer: Tim Priesnitz Proseminar "Logische Aspekte von XML" - SS 2003 Gert Smolka PS-Lab, Uni Saarland Bäume sind eine der wichtigsten Darstellungsformen in der Informatik. Anwendungsbereiche sind: Suchbäume zum Finden von Elementen in sortierten Datenstrukturen Entscheidungsbäume zur Organisation von Entscheidungen Strukturbäume zur Repräsentation der Struktur von Programmen und was wir nachfolgend betrachten werden: Bäume als Datenstruktur

2 Semistrukturierte Daten
{ person: { name: “Alan“, phone: 1234 } } person name phone Motivation: Darstellung und Verwendung semistrukturierter Daten Was sind semistrukturierte Daten? Mischung zwischen unstrukturierten und strukturierten Daten Daten, die nicht zu einem Schema konform sein müssen Daten mit irregulärer Struktur optionale Daten (können fehlen) ähnliche Konzepte mit unterschiedlichen Typen (z.B. Name, Vorname…) Datenstruktur soll teilweise explizit sein mit frei definierbaren Zusätzen (Attribute z.B.) Grundsätzlich gibt es 2 unterschiedliche Darstellungsweisen: serialisiert – zeigen, was Zahlen, Text, Labels sind (Basistypen) grafisch: Baumstruktur – erklären was unbeschränkt ist Vorteile von semistrukturierten Daten gegenüber "älteren" Datenstrukturen: Die Typen werden direkt mitdefiniert selbstbeschreibend (bezieht sich auf die Typen) maschinenlesbar + von Menschen lesbar Alan 1234 Serialisierte Darstellung: selbstbeschreibend Endlicher, unbeschränkter Baum

3 Überblick Sichtweisen auf Daten Graphen und Bäume XML Definitionen
Klassifizierungen Graph ↔ Baum XML XML-Syntax Baummodelle für XML XML-Typen Implementierungsmodelle Nachfolgend werden wir zunächst einige Vorgängermodelle semistrukturierter Daten kennen lernen und anschließend dann tiefer in die Graphen- und Baumtheorie einsteigen. Der letzte Teil des Vortrages beschäftigt sich mit XML als konkreter Darstellungsform für semistrukturierte Daten. Dort werden wir sehen, wie man Baummodelle anwenden kann.

4 Vorgänger: Monolytische Dateien
Im Internet gibt es eine riesige Anzahl, unterschiedlicher Datenimplementierungen. Die dargestellten Informationen unterscheiden sich in ihrer Datenstruktur oft grundlegend voneinander. Nachfolgend werden einige ältere Darstellungsmöglichkeiten vorgestellt: Die einfachste Form der Sicht auf Daten ist die Zerlegung der Informationen in einzelne Informationseinheiten, die Dateien. Vorteil: einfache Implementierung Nachteile: Operationen auf den Daten sehr langsam, da keine Relationen (z.B. Suchen) Eventuelle Redundanz Daten können in Datei 1 und Datei 2 unterschiedliche Werte haben (Konsistenz) Daten sehr unstrukturiert (nur Dateistruktur) Sehr flache Baumstruktur (auf Datenträger: Dateiebene, Verzeichnisse) Informationen werden in Einheiten (z.B. Dateien) zerlegt

5 Vorgänger: Relationale Datenbanken
Darstellung in Matrizenform Darstellung: Entity-Relationship-Modell Matrikel-nummer Vorname Nachname 123456 Arno Alt 143678 Berta Blau STUDENT Matrikelnummer Vorname Nachname… VORLESUNG VL-Nummer Dozent Semester… Darstellungsformen: als mathematisches Objekt (Matrix) wird zur übersichtlichen Darstellung von expliziten Dateneinträgen genutzt als ER-Modell wird zur Darstellung des Datenbankschemas genutzt man sieht die einzelnen Datenfelder, sowie die Relationen zwischen den Tabellen Vorteile von Datenbanken gegenüber monolytischen Dateien: sehr strukturierte Daten Keine Redundanz Beschränkung der Eingaben möglich (Typen, Größen, …) Überprüfung der Daten auf Gültigkeit (Typkonsistenz) Effizienteres Suchen Nachteil gegenüber semistrukturierten Daten: Typen müssen in einer Relation explizit definiert werden Darstellung der Entities als Bäume möglich, Problem: Darstellung der Relationen PROFESSOR Vorname Nachname Titel… [Codd]

6 Vorgänger: Objektorientierte Systeme
Objekte der realen Welt  Objekte im System Vererbung (Klassen und Methoden) Student Matrikelnummer Fachsemester getMatrikel() setMatrikel() … Person Name Adresse getName() setName() … Professor Titel Fachrichtung getTitel() setTitel() … Grundsatz von objektorientierten Systemen: Implementierung eines relevanten Ausschnitts der realen Welt Wichtigstes Konzept dabei: Vererbung Realisierung dieses Konzeptes: Klassen und Methoden Objekte werden zu Gruppen (=Klassen) zusammengefasst. Eine Oberklasse enthält alle Attribute und Methoden, die auch all ihre Unterklassen besitzen. Für die Darstellung als Baum, bedeutet das: Unterklassen sind eine erweiterte Baumstruktur der Oberklassen Nachteile gegenüber semistrukturierten Daten: Die Typen der Attribute sind auch hier explizit festgelegt

7 Bäume basieren auf Graphen
Definition: Ein gerichteter Graph G=(V,E) V - Menge von Knoten E: V  V - Menge von Kanten aus N F V 1 1 1 MA Pfad 111 an V (Pfade sind aus N*) N SB Um Bäume exakt definieren zu können, benötigen wir die Definition eines gerichteten Graphen Zeigen: Knoten Kanten Pfade Zyklus azyklischer Graph Beispiel für einen Graphen (von SB nach M): Problematik: Es gibt keinen eindeutigen Pfad, der jeden Knoten miteinander verbindet. Lösung über Pfaddefinition, z.B. Pfad soll gehen: SB, MA, F, N, MA, S, M Beschriftung der Kanten zur Vereinfachung weggelassen Wir sehen: hat der Graph einen Zyklus, ist der Pfad von Knoten A nach Knoten B nicht mehr eindeutig! Wie ein Graph/Baum beschriftet wird, sehen wir später! S M Graph mit Zyklus Anwendungsbeispiel: Routenplan

8 Gewurzelte Bäume Definition: Baum ist zusammenhängender, azyklischer, gerichteter Graph Alternative Definition Bäume: Menge von Pfaden (D) A B E C D 2 1 Zur Definition: nicht ganz korrekt: Problem: ein Knoten hat zwei eingehende Kanten… Zur eindeutigen Darstellung von Daten als Baum: azyklisch! Zusammenhängend: Jede Komponente steht in einem Zusammenhang mit der anderen, es gibt keinen Knoten, der keine eingehende Kante besitzt (außer der Wurzel) Gerichtet: Wäre der Graph ungerichtet, so wüsste man nicht, wo sich seine Wurzel befindet. Definition über ungerichtete Graphen ist möglich, jedoch nur über die Zusatzangabe, welcher Knoten die Wurzel ist. Alternative Definition: Menge von Pfaden, im Beispiel: {ε,1,11,12,2} (Beschriftung der Kanten soll nach Initialisierung des Baumes fortlaufend sein zwei Kanten eines Knotens haben nie dieselbe Beschriftung, eindeutig) zwei Kanten von unterschiedlichen Knoten können unterschiedlich beschriftet sein.

9 Klassifizierung von Bäumen
endliche Bäume ω-Bäume 1 2 1 2 1 1 2 1 D = { ε, 1, 2, 11, 12 } D = { ε, 2 }  1* Strings beschränkte Bäume unbeschränkte Bäume ω-ranked Bäume a Es gibt 2 Dimensionen, nach denen sich Bäume klassifizieren lassen: Nach der "Endlichkeit" Nach den Anzahl der Nachfolgeknoten Beide Dimensionen lassen sich beliebig miteinander kombinieren Strings: immer nur ein Nachfolgeknoten Beschränkt: Label des Knotens gibt die Anzahl der Kanten vor Unbeschränkt: Label des Knotens gibt die Kantenanzahl NICHT vor ω-ranked: ein Knoten besitzt unendlich viele Nachfolger 1 1 1 3 1 f 2 2 3 4 1 1 2 c c Term über Σ = { f/2, a/1, c/0 }

10 Beschriftung von Bäumen
Labels für Knoten Beschriftungsfunktion L1 : V  Σ Labels für Kanten L2 : E  Σ f 1 2 c c Beschriftungen können an den Knoten sowie an den Kanten angebracht werden. Sigma ist das Alphabet der Beschriftungen, V Knoten, E Kanten Wichtig: Die Beschriftungen der Initialisierung (z.B. Kanten 1,2) werden NICHT überschrieben, sondern eine zusätzliche Beschriftung erstellt. Eindeutigkeit: zusätzliche Labels dürfen den gleichen Namen haben, die Kantennummerierung bleibt jedoch gleich (gleiches für die Knoten) Warum brauchen wir Beschriftungen an Knoten UND an Kanten? Informationen (Knoten / Kanten) sind verschiebbar, es gibt Darstellungsformen, die knotenbeschriftet sind und welche, die kantenbeschriftet sind – beide drücken dasselbe aus – Beispiel dazu später! L1 und L2 sind isomorph – es gibt einen Übergang zwischen beiden name vorname phone phone 1 2 1 2 funktional: Kantenlabels eindeutig nicht funktional

11 Graphen als Bäume von zyklischen zu azyklischen Graphen: o1 o1
zyklischer Graph Baum o1 o1 Auffalten o1 zyklische Kante effizientere Darstellung o1 Mit dem Konzept unendlicher Bäume, kann man auch zyklische Graphen als Bäume darstellen. Umgekehrte Richtung geht natürlich auch (Kompression)

12 Bäume erweitert mit Zeigern
{ person: &o1 { name: “Mary“, age: 45, child: &o2 } person: &o2 { name: "John", mother: &o1 } } person person child &o1 &o2 Um auf bestimmte Knoten verweisen zu können, brauchen diese zunächst eine eindeutige Bezeichnung (mit der Label-Funktion) – im Beispiel o1 und o2 Zeiger zeigt dann auf den entsprechenden Knoten Ermöglich effiziente Datenstruktur, da man ansonsten Unterknoten erstellen müsste und falls mehrere Knoten den selben Unterknoten haben, man bei einer Änderung überall ändern müsste. Außerdem: geringer Speicherbedarf, da die Daten nur einmal erfasst werden (keine Redundanz) Durch die beiden Zeiger wird der Baum zu einem Graphen Bekannte Anwendung: HTML-Links Baum  Graph mother name name age "Mary" 45 "John" [Links (HTML)]

13 Syntax von XML: Elemente
Ideelles Konzept: ssd-Ausdrücke Unterschiede XML - HTML: Tags (=Elemente) können in XML beliebig definiert werden Elemente lassen sich in XML beliebig tief verschachteln Optionale Beschreibung der XML-Grammatik (DTD's) <name> Frank </name> { name: "Frank" } <person> <vorname> Frank </vorname> <nachname> Schmidt </nachname> </person> { person: { vorname: "Frank", nachname: "Schmidt" } } Elemente Unterelemente <ssd-expr> ::= <value> | pointer <value> | pointer <value> ::= atomicvalue | <complexvalue> <complexvalue> ::= {label: <ssd-expr>, … ,label: <ssd-expr>} Unterschiedliche serialisierte Darstellungsformen: mit Tags (speziell XML) – Syntax von XML eine kontextfreie Sprache beschreibt als Liste (allgemein für semistrukturierte Daten) Ideelles Konzept: Wie definiere ich allgemein einen ssd-Ausdruck? Wert Zeiger beides Werte sind atomar (z.B. Name) oder komplex (z.B. Vorname, Nachname) Unterschied XML-HTML: Tags: in HTML vordefiniert, in XML Definition von Elementen durch Tags Verschachtelung am Beispiel zeigen (Erweiterung z.B. durch <name>…) DTDs später

14 XML-Attribute Syntax XML-Attribute Semantik XML-Attribute
<person gender="m"> <name> Frank </name> < > </ > <married/> </person> Attribute: Zusatzinformationen zu Elementen <married/> Kurzform für <married> </married> (leer) Warum werden Attribute statt Elementen verwendet? Attribute tauchen oft nur sporadisch auf, also nicht in jedem Element. Man vermeidet durch diese Zusatzinformationen viele leere Unterelemente (spart Speicherplatz) Attribute als eingeschränkte Listen (z.B. m,f) Darstellung in der Baumstruktur: Elemente sind Blätter Attribute sind Unterbäume Problem: Unterscheidung Element – Attribut Aus Darstellungsform 1 nicht ersichtlich Durch Bauen eines Virtuelles Tags unter Verwendung eines Dummy-Tags sichtbar XML ist eine Darstellung der Datenstruktur. Um die Daten im Internet darstellen zu können, benötigt man "Übersetzer" – z.B. Stylesheets tag tag virtuelles Tag dum- my Unterelemente Attribute

15 Äquivalente Baummodelle für XML
gelabelte unbeschränkte Bäume XML-Graph: knotenbeschriftet ssd-Graph: kantenbeschriftet person person 1 3 2 1 3 name 2 name age age Frank In den Blättern stehen die Informationen, in den Schichten darüber die Elemente Von einer Darstellungsform zur anderen: Hochziehen der Informationen vom Knoten auf die Kante bzw. Herunterziehen von der Kante in den Knoten Bei allgemeinen Graphen gibt es Probleme mit diesem Äquivalenzbegriff (z.B. können Knoten in einer anderen Reihenfolge auftauchen (name, age, – age, , name) Inhaltlich stellt dies dasselbe dar, jedoch ist die grafische Darstellungsform eine andere. Bei XML spielt die Ordnung der Elemente eine Rolle, die der Attribute nicht Warum? historisch gewachsen (z.B. Inhaltsverzeichnis eines Buches) Allgemein ist die Ordnung in semistrukturierten Datenmodellen jedoch unerheblich. (da nur ein Datenkonzept) Vorteil ungeordnete Daten: können effizienter gehandhabt werden 24 Frank 24

16 Typen für XML Document Type Definition <!DOCTYPE db [
Reguläre Ausdrücke: person* - beliebige Anzahl von Personen person+ - eine oder mehrere Personen person? – keine oder eine Person e|e' - Regel e oder alternativ e' e,e' - Konkatenation von e und e' <!DOCTYPE db [ <!ELEMENT db (person*)> <!ELEMENT person (name, ,phone)> <!ELEMENT name (#PCDATA)> <!ELEMENT age (#PCDATA)> <!ELEMENT (#PCDATA)> <!ELEMENT phone (number | (phone,phone))> <!ELEMENT number (#PCDATA)> <!ATTLIS name age CDATA #REQUIRED (IMPLIED)> ]> DTDs sind kontextfreie Grammatiken Reihenfolge der Elemente MUSS eingehalten werden Unterschiedliche Datentypen: atomare Typen (z.B. PCDATA) komplexe Typen (z.B. phone) Attribute über ATTLIS (Syntax am Beispiel zeigen) Vorteile der regulären Ausdrücke: Optionale und sich wiederholende Daten sind sehr einfach zu beschreiben (z.B. mit a*) DTDs können innerhalb einer XML-Datei definiert werden oder auch in einer seperaten Datei Alternative zu DTDs: XML-Schemata Vorteile: benutzt XML-Syntax expressiver

17 DTD Ein XML-Elemente heißt wohlgeformt, falls alle Tags korrekt geschlossen und alle Attribute eindeutig sind. Grenzen von DTD's: Darstellung von ungeordneten Daten (ssd) DTD's unterstützen keine atomaren Typen (z.B. Integer) Elementtypen sind global, d.h. ein Feld "name" darf z.B. nur einmal vorkommen Listentypen können nicht weiter spezifiziert oder beschränkt werden gültig heißt: Dokument hat DTD und hält sich daran ungeordnete Daten: z.B. Vorname, Name und Name, Vorname benötigen zwei unterschiedliche Eingabemöglichkeiten Listentypen: Listen können vollkommen unterschiedliche Datentypen enthalten Beim Programmieren: eine Liste enthält Daten gleichen Typs

18 Implementierungsmodelle für XML
DOM versus SAX {a: {b: {d,e}, c} {a: {b: {d,e}, c} Parser a a b c b c DOM (document object modell): kompletter Baum wird als zyklische Struktur im Speicher abgelegt Nachteil: verbraucht also sehr viele Ressourcen und Zeit Vorteil: jeder Knoten hat alle Kanteninformationen SAX (simple API for XML): Parser "feuert" für jedes Tag On-the-fly Verarbeitung Vorteil: geringerer Speicherverbrauch Nachteil: keine Kanteninformationen verfügbar d e d e Baumtraversieren durch einen Automaten

19 Referenzen S. Abiteboul, P. Buneman und D.Suciu. Data on the Web: From Relations to Semistructured Data and XML. Morgan Kaufman, New York, 1999 S. Abiteboul. Semistructured Data: from Practice to Theory. LICS 2001 H. Lobin. Informationsmodellierung in XML und SGML. Springer Verlag, Berlin, 2001