4. Integration semistrukturierter Daten

Nachdem man semistrukturierte Daten modelliert und ein Schema generiert hat, möchte man sie oft in ein bestehendes Datenbanksystem einbinden. Man kann die Daten entweder in ihrem Speicher belassen und sie nur bei Bedarf holen, oder sie in die Datenbank integrieren, wie es zum Beispiel bei einem Data Warehouse der Fall ist.

4.1 Der External Data Manager des Lore DBS

Im Lore Datenbanksystem [MW97] werden diese beiden Ansätze kombiniert. Gleichbleibende Daten werden in der Datenbank abgelegt. Sich ständig verändernde Daten werden nur bei Bedarf von der externen Quelle geholt und für eine bestimmte Zeit in Lore gespeichert. Dadurch wird vermieden, daß man den Datenbestand ständig durch Abfragen der externen Quellen aktualisieren muß.
In Lore ist der External Data Manager für die Kommunikation des Datenbanksystem mit den externen Quellen verantwortlich. Wenn eine Anfrage Daten verlangt, die nicht in der Datenbank liegen, muß der External Data Manager zuerst aus der Nutzeranfrage Anfragen an die externen Quellen konstruieren, dann die erhaltenen Daten zwischenspeichern und sie schließlich in die Anfragebearbeitung integrieren. Zwischen dem External Data Manager und den Datenquellen liegen noch Wrapperprogramme, die mit bestimmten Argumenten, die aus der konkreten Anfrage abgeleitet werden, aufgerufen werden und den eigentlichen Datenzugriff realisieren. Dabei gibt es für jede Quelle ein spezielles Wrapperprogramm.
Auch wenn die Daten erst bei Bedarf geholt werden, müssen sie dann für eine bestimmte Zeit in der Datenbank gespeichert werden. Um Platz für sie zu reservieren, wird beim Erstellen der Datenbank ein sogenanntes externes Objekt für jedes Datenobjekt angelegt, das über den External Data Manager geladen werden soll. Dieses besteht wiederum aus mehreren Subobjekten. Eines davon ist das éFetched-Data'-Objekt, das die Werte aufnimmt, die von außerhalb geladen werden. Die übrigen lassen sich unter dem Begriff "Platzhalter für ein externes Objekt" zusammenfassen.
Diese Platzhalter sind ein Objekt Quantum, das den Gültigkeitszeitraum für externe Daten festlegt, ein Objekt Wrapper, das den Namen des Wrapperprogramms enthält, das für diese Datenquelle zuständig ist, und dann noch verschiedene Argumentobjekte, die die Argumente darstellen, die dem Wrapperprogramm übergeben werden. Bei diesen lassen sich drei Typen unterscheiden: hart kodierte Argumente, die konstante Werte repräsentieren, zum Beispiel Paßwörter; datendefinierte Argumente, die für Werte aus der Datenbank stehen und über relative Pfadausdrücke angegeben werden; durch Anfragen definierte Argumente, also Werte, die aus der aktuellen Anfrage übernommen werden. Der Typ und der Wert des Arguments bilden Subobjekte des Argumentobjekts.
Beispiel nach [MW97]:



[A und B sind Attributbezeichner von Objekten]

Abb. 7: External Data Manager


4.2 Araneus

Das Ziel des Araneusprojekts [AMM97] ist es, Webseiten in einer Datenbank zu speichern. Dazu werden als erstes die Seiten der Site mittels ADM, dem Araneus Data Model, als Seitenschemata dargestellt (s. Absatz 2.1.3). Dabei entspricht jede HTML-Seite einem Objekt und die einzelnen Elemente der Seite sind die Attribute des Objekts.
Um auf die Werte der Attribute, also zum Beispiel auf einen Text, zugreifen zu können, werden Programme in der Sprache EDITOR [AM97] verwendet, die für Textmanipulationen entwickelt wurde. Dabei wird jedem Attribut ein Wrapperprogramm zugeordnet.
Die einzelnen Attribute der Seitenobjekte erreicht man durch Navigation. Jeder mögliche Weg kann mit Pfadausdrücken beschrieben werden. Da in diesen Ausdrücken nur die Attributnamen und nicht die Werte angegeben werden, entspricht jeder Ausdruck einer Menge von möglichen Tupeln von Attributwerten. Diese kann man als Relation SEM(N) im Sinn einer relationalen Datenbank auffassen, wobei N der zugehörige Pfadausdruck ist. Man kann also auf diese Weise zu den HTML-Seiten Relationen definieren, die dann in einer Datenbank gespeichert werden können.
Zur Definition der Tabellen wird die Sprache ULIXES verwendet. Mit ihr kann man mit folgender Syntax zu einem Navigationsausdruck N über einem ADM-Schema S eine Relation R definieren:

DEFINE TABLER(B1, B2, ..., Bn)
AS N
IN S
USINGA1, A2, ..., An
WHEREc1, c2, ..., ck


Dabei ist R der Name der neuen Relation mit den Attributen B1, B2, ..., Bn, A1, A2, ..., An sind die Attribut von SEM(N) und c1, c2, ..., ck sind Bedingungen über die Attribute.

Ein Beispiel, das sich auf das Schema in Absatz 2.1.3 bezieht (nach [AMM97]):

DEFINE TABLE VLDBPapers (Authors, Title, Reference)
AS AuthorSearchPage. NameForm.Submit->AuthorPage.WorkList
IN DBLPScheme
USINGAuthorPage.WorkList.Authors,
AuthorPage.WorkList.Title,
AuthorPage.WorkList.Reference
WHERE AuthorSearchPage.NameForm.Name = éXYZ',
AuthorPage.WorkList.Reference LIKE é%VLDB%'


In dieser Tabelle werden die Autoren, Titel und Referenzen zu allen Vorträgen von Autor XYZ auf Konferenzen gespeichert, deren Name VLDB enthält.
Kapitel 3InhaltKapitel 5