Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Interoperable Informationssysteme - 1 Klemens Böhm Datenmodell 1: OEM.

Ähnliche Präsentationen


Präsentation zum Thema: "Interoperable Informationssysteme - 1 Klemens Böhm Datenmodell 1: OEM."—  Präsentation transkript:

1 Interoperable Informationssysteme - 1 Klemens Böhm Datenmodell 1: OEM

2 Interoperable Informationssysteme - 2 Klemens Böhm Semistrukturierte Daten (1) Was sind semistrukturierte Daten? l Daten, die nicht zu einem apriori definierten Schema konform sein müssen (bzw. können Schemata so wenig restriktiv sein, dass sie unwichtig werden - Beispiel: HTML-DTD), l selbstbeschreibende Daten, Einleitung/ Motivation OEM Definitionen

3 Interoperable Informationssysteme - 3 Klemens Böhm Semistrukturierte Daten (2) l Daten mit üblicherweise irregulärer Struktur: u Daten können fehlen, u ähnliche Konzepte werden durch unterschiedliche Typen repräsentiert, –NAME flach oder FIRSTNAME, LASTNAME, –Vorgesetzter: Referenz oder Name –Zweitname: CHAR vs. String Mengen können heterogen sein, u Struktur ist nicht vollständig bekannt. Beispiel: Jörg – Teil des Vornamens oder Zweitname? Einleitung/ Motivation OEM Definitionen

4 Interoperable Informationssysteme - 4 Klemens Böhm Semistrukturierte Daten - Motivation l Daten lassen sich i.a. nicht problemlos in Tabellen abbilden, Strukturierung ist aber trotzdem wünschenswert. Beispiel: Wörterbuch-Einträge u Optionale Bestandteile, u Wiederholungen von Strukturelementen, u Reihenfolge der Elemente vielleicht relevant. l Man möchte die Struktur von Daten nur teilweise explizit machen. Beispiel: Bestellungen haben strukturierten Anteil, aber auch frei definierbare Zusätze. Einleitung/ Motivation OEM Definitionen

5 Interoperable Informationssysteme - 5 Klemens Böhm Semistrukturierte Daten - Motivation (2) l Warum sind Daten nicht stets explizit strukturiert? u nicht erforderlich, u nicht eindeutig, u nicht bekannt, u Erstellung der Strukturierung zu aufwendig. l Man will Modell, mit dem explizite Strukturierung möglich, aber nicht obligatorisch ist. Einleitung/ Motivation OEM Definitionen

6 Interoperable Informationssysteme - 6 Klemens Böhm Semistrukturierte Daten - Fallunterscheidung Semistrukturierte Daten - unterschiedliche Verwendungen des Begriffs: l Schema existiert, Semistrukturiertheit heisst nur Irregularität oder teilweise strukturiert, teilweise nicht, Beispiel: SGML-/XML-DTDs l kein Schema, aber Struktur der Daten eindeutig erkennbar, z.B. valide Dokumente a la XML, l Struktur nicht einwandfrei identifizierbar, kann z.B. in HTML-Dokumenten vorkommen (pathologischer Fall). Einleitung/ Motivation OEM Definitionen

7 Interoperable Informationssysteme - 7 Klemens Böhm Object Exchange Model (OEM) l Forschungsergebnis der Stanford University, m.W. keine entsprechenden Produkte, l Objekt als elementares Bestandteil. l Jedes Objekt hat OID und Wert: u Atomarer Wert, z.B. int, string, u komplexer Wert: Menge von Subobjekten, Verknüpfung mit Parent durch Label. l OEM-Objekt heisst: Objekt + Subobjekte. Einleitung/ Motivation OEM Definitionen

8 Interoperable Informationssysteme - 8 Klemens Böhm OEM - Beispiel 2 1 3 4 5 6 7 8 9 10 11 Bar Restaurant Name Entree Telefon Inhaber Manager Name Entree Chili Burger 555-1234 Klein Darbar Lamm Rind Restaurant Plus Mehrere Parents und Zykel sind erlaubt. Aggregation Hierarchies Einleitung/ Motivation OEM Definitionen

9 Interoperable Informationssysteme - 9 Klemens Böhm Pfade im OEM-Kontext l Label Path eines OEM Objekts o - Folge von Labels, separiert durch Punkte, l 1.l 2 …l n, so dass man von o aus den Pfad (e 1, …, e n ) traversieren kann, und Kante e i hat Label l i. l Data Path eines OEM Objekts o - Alternierende Folge von Labels und OIDs, separiert durch Punkte, l 1.o 1.l 2.o 2 …l n.o n, so dass man von o aus den Pfad (e 1, …, e n ) durch Objekte (x 1, …, x n ) traversieren kann, Kante e i hat Label l i, und Objekt x i hat OID o i. l Ein Data Path d ist Instanz eines Label Paths l, wenn die Folgen der Labels übereinstimmen. Alle Instanzen von Restaurant.Entrée? Einleitung/ Motivation OEM Definitionen

10 Interoperable Informationssysteme - 10 Klemens Böhm Target Set l Das Target Set in einem OEM Objekt s von einem label path l von s ist die Menge t ={o|l 1.o 1.l 2.o 2 …l n.o ist Instanz von l} Target Set von Resaurant.Entrée? Label Paths des Target Sets {8}? l Label Paths eines Target Sets sowie Label Paths einer Menge von Label Paths – Beispiele: u L({8}) = {Restaurant.Inhaber, Restaurant.Manager}, u L({Restaurant.Inhaber}) = {Restaurant.Inhaber, Restaurant.Manager}, Einleitung/ Motivation OEM Definitionen

11 Interoperable Informationssysteme - 11 Klemens Böhm Schema l Sehr vage Definition im folgenden; der Vollständigkeit halber… l Ein Schema ist eine endliche Menge von Namen. l Eine Instanz eines Schemas besteht aus u einem endlichen gelabelten Graphen (V a V c,E) –V a enthält die atomic objects, –V c enthält die complex objects, –Labels der Kanten sind Strings, u Abbildung der Namen zu Knoten, u Abb. von atomic objects zu atomaren Werten. Ausserdem gilt: u keine ausgehenden Kanten von atomic objects, u jd. Knoten ist von einem mit Namen erreichbar. l Was wäre ein Schema für das Restaurant- Beispiel? Einleitung/ Motivation OEM Definitionen

12 Interoperable Informationssysteme - 12 Klemens Böhm Queries 1: Deklarativer Zugriff auf semistrukturierte Daten

13 Interoperable Informationssysteme - 13 Klemens Böhm OEM - Datenbank 19 12 35 17 13 14 66 18 23 25 restaurant category name address category name address gourmet Chef Chu Mountain View restaurant 44 15 16 street city zipcode El Camino Real Palo Alto 92310 77 55 79 80 name Vietna- mese Saigon Menlo Park cheap fast food McDonalds price category price 54 92310 zipcode nearby Guide Anforde- rungen Query- sprache Semantik

14 Interoperable Informationssysteme - 14 Klemens Böhm Unregelmässigkeiten in der Beispiel-Datenbank und Zsh. zum deklarativen Zugriff l Restaurants haben beliebig viele Adressen, l Adressen sind manchmal Strings, haben manchmal aber auch explizite Struktur, l zipcode kann String oder Integer sein, l zipcode ist manchmal direkter Bestandteil von restaurant, manchmal Bestandteil von address. l Man kann bzw. möchte Struktur der Daten nicht immer genau spezifizieren, l manchmal haben die Daten aber Struktur, und sie ist dem Benutzer bekannt. Anforde- rungen Query- sprache Semantik

15 Interoperable Informationssysteme - 15 Klemens Böhm Anforderungen Anforderungen gemäss [ABS00]: l Ausdrucksmächtigkeit, l Semantik, l Zusammensetzbarkeit, l Schema, l Einfache Erzeugung von Anfragen aus Programmen. Anforde- rungen Query- sprache Semantik

16 Interoperable Informationssysteme - 16 Klemens Böhm Ausdrucksmächtigkeit l Mindestens das, was Sprache für das relationale Modell kann. l Sprache sollte ausdrucksmächtig sein, aber nicht zu ausdrucksmächtig. l Denn: u Optimierungen sind teilweise nicht möglich, u keine Garantien für Ausführungszeiten. Anforde- rungen Query- sprache Semantik

17 Interoperable Informationssysteme - 17 Klemens Böhm Semantik Genaue Definition der Semantik ist erforderlich. Einfache Erzeugung von Anfragen aus Programmen karg, aber einfach Anforde- rungen Query- sprache Semantik

18 Interoperable Informationssysteme - 18 Klemens Böhm Schema l Structure-Consciousness l Keine Eigenschaft der Querysprache, sondern der Implementierung. Anforde- rungen Query- sprache Semantik

19 Interoperable Informationssysteme - 19 Klemens Böhm Zusammensetzbarkeit l Query sollte auf anderes Queryergebnis anwendbar sein. l Konsequenz auf der semantischen Ebene: Queryergebnis sollte wieder Instanz des Ausgangsdatenmodells sein, l Beispiel: Querysprache LOREL erzeugt Relationen aus OEM-Instanz, d.h. LOREL genügt der Anforderung nicht. l Konsequenz auf der syntaktischen Ebene: Referentielle Transparenz Name, Variable für semistrukturierte Daten Ausdruck Anforde- rungen Query- sprache Semantik

20 Interoperable Informationssysteme - 20 Klemens Böhm Beispiel l Textuelle Beschreibung: Finde die Adressen aller Restaurants mit PLZ 92310. (D.h. man sucht address-Objekt, das zipcode-Objekt enthält. Zipcode direkt unter Restaurant wäre – in diesem Beispiel – nicht OK.) l Query: select a: X.address from Guide.restaurant X where X.address.zipcode = 93210 l Anmerkung: Vorgestellt wird eine spezielle Querysprache, andere Semantik wäre denkbar (Beispiel s.o.). Anforde- rungen Query- sprache - Einstieg - Pfadausdr. - Coercion - komplexe Ergebnisse - Label-/ Path-Var. Semantik

21 Interoperable Informationssysteme - 21 Klemens Böhm Erläuterungen zum Beispiel l Identische Präfixe von Pfadausdrücken sollen den gleichen Datenpfaden entsprechen, l Query abstrahiert davon, ob zipcode String oder Integer (wird im folgenden beschrieben), l address ohne zipcode verursacht keine Fehlermeldung, im Gegensatz zu anderen Querysprachen, l address, zipcode können mehrmals vorkommen. Anforde- rungen Query- sprache - Einstieg - Pfadausdr. - Coercion - komplexe Ergebnisse - Label-/ Path-Var. Semantik

22 Interoperable Informationssysteme - 22 Klemens Böhm Pfadausdrücke l Graph-Struktur der Daten erfordert Pfadausdrücke, l Unstrukturiertheit der Daten erfordert Flexibilität bei der Formulierung von Pfadausdrücken (vgl. mit Folie Beispiel OEM …), wird im folgenden illustriert. l Pfadausdrücke können Bestandteil aller Query-Bestandteile sein, d.h. select-, from-und where-Klausel. Anforde- rungen Query- sprache - Einstieg - Pfadausdr. - Coercion - komplexe Ergebnisse - Label-/ Path-Var. Semantik

23 Interoperable Informationssysteme - 23 Klemens Böhm Pfadausdrücke in der from-Klausel l Pfadausdruck in der from-Klausel: fromGuide.restaurant.address.zipcode Z, Guide.restaurant.name N l Äquivalente from-Klausel: fromGuide.restaurant R, R.address A, A.zipcode Z, R.name N l D.h. zipcode Z und name N müssen zum gleichen Restaurant gehören. Anforde- rungen Query- sprache - Einstieg - Pfadausdr. - Coercion - komplexe Ergebnisse - Label-/ Path-Var. Semantik

24 Interoperable Informationssysteme - 24 Klemens Böhm Pfadausdrücke in der select-Klausel l Query mit Pfadausdruck in der select-Klausel: select z: R.address.zipcode from Guide.restaurant R l Sind die folgenden Queries äquivalent? u select Guide.restaurant.address.zipcode from Guide.restaurant.address u select Guide.restaurant.address.zipcode from Guide Anforde- rungen Query- sprache - Einstieg - Pfadausdr. - Coercion - komplexe Ergebnisse - Label-/ Path-Var. Semantik

25 Interoperable Informationssysteme - 25 Klemens Böhm Pfadausdrücke in der where-Klausel l Beispielquery: select n: R.name from Guide.restaurant R where R.address.zipcode = 93210 or (R.address.street = Palm and R.address.city = Palo Alto) l Äquivalente Query: select n: R.name from Guide.restaurant R where exists A in R.address: ((exists Z in A.zipcode: Z = 93210) or ((exists S in A.street: S = Palm) and (exists C in A.city: C = Palo Alto))) Existenzquantor für address enthält alle drei Bedingungen, im Gegensatz zu den anderen Quantoren. Es handelt sich um die gleiche Adresse. Anforde- rungen Query- sprache - Einstieg - Pfadausdr. - Coercion - komplexe Ergebnisse - Label-/ Path-Var. Semantik

26 Interoperable Informationssysteme - 26 Klemens Böhm Beispiel 2 l Beispiel greift Szenario von eben wieder auf. l Textuelle Beschreibung: Finde Namen und Zipcodes aller billigen Restaurants. (String cheap als Wert eines Objekts enthält diese Information.) l Probleme - Anfrager kennt/weiss nicht: u die genaue Position der zipcode-Objekte, u welches Objekt den String cheap enthält. l Query: selectGuide.restaurant.name, Guide.restaurant(.address)?.zipcode whereGuide.restaurant.% grep cheap l Erläuterungen: u ? identifiziert optionalen Pfad-Bestandteil, u % ist Wildcard, grep hat übliche Semantik. Anforde- rungen Query- sprache - Einstieg - Pfadausdr. - Coercion - komplexe Ergebnisse - Label-/ Path-Var. Semantik

27 Interoperable Informationssysteme - 27 Klemens Böhm Allgemeine Pfad-Ausdrücke - gpe-Komponenten l Charakterisierung: u Bestandteile allgemeiner Pfad-Ausdrücke, u Verallgemeinerung von Labels in einfachen Pfad-Ausdrücken; l Definition (rekursiv) - u wenn l ein Label ist, ist.l eine gpe-Komponente u wenn s 1, s 2 gpe-Komponenten sind, dann sind es die folgenden Ausdrücke auch: s 1 s 2, s 1 |s 2, (s 1 ), (s 1 )?, (s 1 )+, (s 1 )* u wenn X ein String-Objekt ist, dann ist.unquote(X) eine gpe-Komponente. Wofür kann das gut sein? Was sind Unterschiede zwischen OEM + Querysprache und objektorientierten Modellen? Anforde- rungen Query- sprache - Einstieg - Pfadausdr. - Coercion - komplexe Ergebnisse - Label-/ Path-Var. Semantik

28 Interoperable Informationssysteme - 28 Klemens Böhm Vergleich von Objekten unterschiedlichen Typs l Ziel: Man möchte Bedingungen akzeptieren wie Z=1.0 oder Z> 0.9, egal ob Z mit 1 oder 1 belegt ist. l Typumwandlung: l Beispiel: 4.3 < 5 - beide Werte konvertieren. l Achtung: Gleichheit ist nicht mehr transitiv: 05 = 5, 5 = 5, aber 05 5 Anforde- rungen Query- sprache - Einstieg - Pfadausdr. - Coercion - komplexe Ergebnisse - Label-/ Path-Var. Semantik

29 Interoperable Informationssysteme - 29 Klemens Böhm Vergleich komplexer Objekte unterschiedlichen Typs l Typumwandlung: l Beispiel: select X.address from Guide.restaurant X where X.name = Chef Chu where-Klausel interpret. als where exists Z in X: Z.name=Chef Chu Anforde- rungen Query- sprache - Einstieg - Pfadausdr. - Coercion - komplexe Ergebnisse - Label-/ Path-Var. Semantik

30 Interoperable Informationssysteme - 30 Klemens Böhm Erzeugung eines Queryergebnisses mit beliebiger Struktur Queries müssen Instanzen des zugrundeliegenden Datenmodells generieren (d.h. z.B. OEM-Instanzen). Anforde- rungen Query- sprache - Einstieg - Pfadausdr. - Coercion - komplexe Ergebnisse - Label-/ Path-Var. Semantik

31 Interoperable Informationssysteme - 31 Klemens Böhm Erzeugung eines Queryergebnisses mit komplexer Struktur - Beispiele Anforde- rungen Query- sprache - Einstieg - Pfadausdr. - Coercion - komplexe Ergebnisse - Label-/ Path-Var. Semantik selectauthor: X frombiblio.book.author X Erzeugt Baum der Tiefe 1; alle Kanten haben Label author. selectrow:(selectauthor: Y fromX.author Y) frombiblio.book X Strukturiertes Anfrageergebnis – ein Teilbaum für die Autoren jedes Buchs. select(selectY fromX.author Y) frombiblio.book X

32 Interoperable Informationssysteme - 32 Klemens Böhm Queryergebnis mit komplexer, unregelmässiger Struktur l Subqueries mit leerem Ergebnis führen nicht zu Fehler; vielmehr lässt sich unregelmässig strukturiertes Queryergebnis erzeugen. Beispiel: select r:{number: N, (select title: T where {number: N, title: T} in db1.report), (select postscript: P where {num: N, postscript: P} in db2.myrep)} where N in db1.report.number union db2.myrep.num Anforde- rungen Query- sprache - Einstieg - Pfadausdr. - Coercion - komplexe Ergebnisse - Label-/ Path-Var. Semantik

33 Interoperable Informationssysteme - 33 Klemens Böhm Label-Variablen l Label-Variablen ermöglichen Übergang zwischen Schema-Information und Daten. l Beispiele: u select publication: {type: L, title: T} from biblio.L X, X.title T where X.Year > 1989 u select npers: (selectL: Y fromX.L Y wherenot (L = salary)) from db.person X Gruppierung mit Hilfe von Label-Variablen (umgekehrte Richtung wie oben) – Beispiel: select Y: (select X from biblio.paper X where X.year = Y) from biblio.paper.year Y Anforde- rungen Query- sprache - Einstieg - Pfadausdr. - Coercion - komplexe Ergebnisse - Label-/ Path-Var. Semantik

34 Interoperable Informationssysteme - 34 Klemens Böhm Path-Variablen l Statt einzelner Labels können auch ganze Paths zu Daten werden. Beispiel: select@P fromdb1 @P.X wherematches(".*ubiquit.*", X) l Problem: Was geschieht bei Zykeln im Data Graph? Anforde- rungen Query- sprache - Einstieg - Pfadausdr. - Coercion - komplexe Ergebnisse - Label-/ Path-Var. Semantik

35 Interoperable Informationssysteme - 35 Klemens Böhm Semantik der Querysprache l Semantik der Querysprache muss formal definiert sein. l Vorgehen: u Beschreibung des Data Graphs mit einfacher relationaler Struktur. u Abbildung (eines Teils) der Querysprache auf Logik-Ausdrücke über dieses relationale Modell. u Alternativ: Abbildung der Querysprache auf Datalog-Ausdrücke über dieses Modell. Anforde- rungen Query- sprache Semantik - Vorgehen - Objekterz.

36 Interoperable Informationssysteme - 36 Klemens Böhm 1. Schritt: Generische relationale Beschreibung des Data Graphs Schema: ref(source: oid, label: dom, destination: oid) val(obj: oid, value: dom) l Constraints: u Oid ist entweder atomar oder komplex. u Jedes Objekt ist von einer Wurzel erreichbar. oid Attribut ist Schlüssel in der Relation val. Anforde- rungen Query- sprache Semantik - Vorgehen - Objekterz.

37 Interoperable Informationssysteme - 37 Klemens Böhm 2. Schritt: Abbildung Querysprache logischer Ausdruck l Beispiel: Anfrage in der Querysprache: select author: X from biblio.book Y, Y.author X where "Database" in Y.title Entsprechender logischer Ausdruck: {X| Y, Z, V, W(ref(db, "biblio", W) ref(W, "book", Y) ref(Y, "author", X) ref(Y, "title", V) val(V, "database"))} l Auf diese Art lässt sich kein neuer Data Graph konstruieren, der Queryergebnis repräsentiert. Anforde- rungen Query- sprache Semantik - Vorgehen - Objekterz.

38 Interoperable Informationssysteme - 38 Klemens Böhm 3. Schritt: Abbildung Querysprache Datalog biblio db book &o1 author &o3 Smith &o9 book &o2 paper &o4 title &o8 date &o7 author &o6 author &o5 date &o10 title &o11 author&o12 1999 Data Production Cassio Database Systems 1976 Combalusier Roux title ans Anforde- rungen Query- sprache Semantik - Vorgehen - Objekterz.

39 Interoperable Informationssysteme - 39 Klemens Böhm 3. Schritt: Abbildung Querysprache Datalog l Neue Tupel, aus denen die Antwort besteht, werden in die generische Kanten-Relation eingefügt. l Beispiel: Anfrage in der Querysprache (wiederholt): select author: X from biblio.book Y, Y.author X where "Database" in Y.title Entsprechender Datalog-Ausdruck: ref(ans, " author ", X) (ref(db, "biblio", W), ref(W, "book", Y), ref(Y, "author", X), ref(Y, "title", V), val(V, "database") Anforde- rungen Query- sprache Semantik - Vorgehen - Objekterz.

40 Interoperable Informationssysteme - 40 Klemens Böhm 3. Schritt: Abbildung Querysprache Datalog (Forts.) l Abbildung von Pfadausdrücken erfordert i.d.R. Rekursion. l Beispiel: Anfrage in der Querysprache: select part: X from product X, X.(subpart)* Y Entsprechender Datalog-Ausdruck: ref(ans, part ", Y) q(Y) q(Y) ref(db, product", Y) q(Y) q(Z), ref(Z, subpart", Y) Anforde- rungen Query- sprache Semantik - Vorgehen - Objekterz.

41 Interoperable Informationssysteme - 41 Klemens Böhm Erzeugung von Objekten l Erzeugung von Anfrageergebnissen erfordert i.a. die Erzeugung von Objekten. l Erzeugung der neuen Objekte erfordert auch Erzeugung von OIDs – Verwendung von Skolem-Funktion. l Skolem-Funktion u benötigt als Parameter eine Zeichenkette, u erzeugt daraus eine einmalige, reproduzierbare ID. Anforde- rungen Query- sprache Semantik - Vorgehen - Objekterz.

42 Interoperable Informationssysteme - 42 Klemens Böhm Erzeugung von Objekten l Beispiel für Verwendung von Skolem-Funktion: Anfrage in der Querysprache: selectrow: {title: T, year: Y} frombiblio.book X, X.title T, X.year Y Entsprechender Datalog-Ausdruck: ref(ans, row ", f(X)) ref(db, biblio", B), ref(B, book", X) ref(f(X), title ", T) ref(X, title", T) ref(f(X), year ", Y) ref(X, year", Y) l Nur erster Aufruf der Skolem-Funktion mit bestimmten Parametern führt zur Erzeugung eines neuen Objekts. Anforde- rungen Query- sprache Semantik - Vorgehen - Objekterz.

43 Interoperable Informationssysteme - 43 Klemens Böhm Erzeugung von Objekten l Weiteres Beispiel – Anfragen über mehrere Datenbanken. Anfragen in der Querysprache (ohne Object Fusion): select row: {num: N, title: Y} where {number: N, title: Y} in db1.report select row: {num: N, postscript: P} where {num: N, postscript: P} in db2.myrep Entsprechendes Datalog-Programm: ref(ans, row", f(N)) ref(db1, report", X), ref(X, number", Y), val(Y, N) ref(f(X), title", T) val(Y, N), ref(X, number", Y) ref(X, title", T) … l I.d.R. ein Objekt, das Einträge aus unterschiedlichen Datenbanken zusammenfasst (Object Fusion). Anforde- rungen Query- sprache Semantik - Vorgehen - Objekterz.

44 Interoperable Informationssysteme - 44 Klemens Böhm Erzeugung von Objekten Gleiche Anfrage in unserer Querysprache – ist möglich, aber kompliziert: select report: {number: N, ( select title: T where {number: N, title T} in db1.report), ( select postscript: P where {num: N, postscript P} in db2.myrp)} where N in db1.report.number union db2.myrp.num Anforde- rungen Query- sprache Semantik - Vorgehen - Objekterz.


Herunterladen ppt "Interoperable Informationssysteme - 1 Klemens Böhm Datenmodell 1: OEM."

Ähnliche Präsentationen


Google-Anzeigen