Objektorientiertes dynamisches Web-Publishing mit semistrukturierten Daten

Transkript

1 Objektorientiertes dynamisches Web-Publishing mit semistrukturierten Daten Bodo Rieger, Heike Dalinghaus, Eitel von Maur Institut für Informationsmanagement und Unternehmensführung Universität Osnabrück Katharinenstraße 3, D Osnabrück {brieger hdalingh Abstract. Dieser Beitrag beschreibt einen vollständig objektorientierten Ansatz zur integrativen Verwaltung und dynamischen Web-Präsentation unterschiedlich strukturierter Daten aus einer gemeinsamen, konsistenten und redundanzfreien Datenbasis. Als Entwicklungsumgebung wurden VisualWave 2.0a und GemStone verwendet. Aus dem ODBMS heraus ist es möglich, durch Kombination verschiedener Objekte unterschiedliche Dokumente unter Beachtung der Trennung von Inhalt, Struktur und Layout zu erstellen. Hierzu wurde ein Objektmodell aus drei interagierenden Teilmodellen entwickelt. Durch die konsequente Trennung der drei Komponenten wird gewährleistet, dass gleiche Inhalte beliebig oft in unterschiedlichen Strukturen in verschiedenen Dokumenten vorkommen und mit alternativen Layouts präsentiert werden können, ohne redundant verwaltet werden zu müssen. 1 Motivation Das Internet hat sich, speziell mit dem Dienst des World Wide Web (WWW), zu einer universellen Plattform entwickelt, auf der Unternehmen zur Produktpräsentation, Kundenakquisition und Geschäftsabwicklung (E-Commerce) zunehmend unverzichtbar präsent sein müssen. Für eine auch kundenindividuelle Präsentation ist eine explosionsartig steigende Anzahl von WWW-Seiten (synonym: WWW-Dokumente) erforderlich, deren Dateninhalte stets aktuell und konsistent gehalten werden müssen. Hierzu ist der Einsatz von datenbankgestützten Systemen unumgänglich. Nur diese können die großen Datenmengen, die bei der Erstellung der WWW-Seiten anfallen, bewältigen und ihre Aktualität und Konsistenz gewährleisten. Die WWW-Seiten werden dabei stets dynamisch auf Basis der in der Datenbank enthaltenen Daten generiert. Während beim statischen Web-Publishing ohne Datenbankunterstützung eine Datenänderung in allen Web-Seiten, in denen die Daten vorkommen, durchgeführt werden muss, brauchen die Daten bei einer datenbankgestützten Lösung nur einmal in der Datenbank geändert werden. Die redundanzfrei in der Datenbank gespeicherten Daten können ferner beliebig (oft) in verschiedene Kontexte (Web-Seiten) eingearbeitet werden, ohne die Konsistenz der Daten zu gefährden. Für ein effizientes Web- Publishing ist daher ein zentraler und einheitlicher Datenpool notwendig, aus dem die WWW-Seiten dynamisch generiert werden können [RBK+98]. veröffentlicht in: Net.ObjectDays-Forum (Hrsg.), Tagungsband Net.ObjectDays 2000, , Erfurt 2000, S

2 Konventionelle Datenbanksysteme sind auf strukturierte Daten beschränkt. Unternehmensrelevante Informationen und damit auch Web-Dokumente sind hingegen durch einen hohen Anteil semistrukturierter und unstrukturierter Dateninhalte geprägt [Sch99, S. 564]. Für einen Entscheidungsträger sind diese qualitativen Daten meistens von größerer Bedeutung als die quantitativen Daten aus der Datenbank, da sie einen höheren Informationsgehalt bieten [RBK+98] bzw. da erst sie eine Bewertung und damit effektive Nutzung der quantitativen Daten ermöglichen. Sollen aus diesen unterschiedlich strukturierten Daten dynamisch Webseiten generiert werden, muss auch das Datenbanksystem mächtig genug sein, unterschiedlich strukturierte Daten in einer gemeinsamen Struktur zu integrieren und zu verwalten. Mit der extensible Markup Language (XML) wird ein möglicher Ansatz der Datenintegration speziell für das Web beschrieben. Durch den Dokumentenstandard können Merkmale definiert werden, mit denen die unterschiedlichen Daten strukturiert und in Form von Dokumenten zusammengefasst werden können. XML geht dabei richtigerweise bereits von der Trennung von Inhalt, Struktur und Layout eines Dokuments aus. Da XML jedoch einen statischen Anwendungscharakter hat, d. h. die Dateninhalte stets eng mit der Struktur verbunden repräsentiert werden, bleibt das Datenverwaltungsproblem ungelöst. Das objektorientierte Paradigma ist besonders gut für die Umsetzung der Integration geeignet, da es die Möglichkeit bietet, sehr einfach beliebige und beliebig komplexe Datentypen zu definieren. Dies kann einerseits durch die Referenzierung der Objekte auf verschiedene andere Objekte erfolgen. Andererseits können aber auch Konstruktoren wie List, Array, Set oder Bag zur Definition von komplexen Typen verwendet werden. Des Weiteren zeichnet sich das objektorientierte Modell im Gegensatz zu anderen Modellen (wie z. B. Relationenmodell, NF²-Modell, Netzwerkmodell und deduktives Modell) durch eine starke semantische Ausdruckskraft aus, da es zusätzlich zur Abbildung von komplexen Strukturen auch noch die Modellierung von Beziehungen (Generalisierung, redundanzfreie Aggregation) und Rekursion ermöglicht [LL95, S. 175]. Durch Implementierung in einem objektorientierten Datenbankmanagementsystem (ODBMS) und Kombination mit Klassen, die eine dynamische Web-Server-Funktionalität realisieren, können alle beschriebenen Anforderungen gesamtheitlich und ohne Strukturbruch erfüllt werden. Der Beitrag gliedert sich in 6 Abschnitte. Im zweiten Abschnitt werden die notwendige Zerlegung von WWW-Dokumenten in Inhalt, Struktur und Layout und die sich daraus ergebenden Konsequenzen bezüglich des Datenmanagements beschrieben. Der dritte Abschnitt stellt eine diesbezüglich geeignete, objektorientierte Lösung durch drei interagierende Teilmodelle vor. Nach einer Beschreibung der eingesetzten Entwicklungswerkzeuge VisualWave und GemStone in Abschnitt 4 wird im fünften Abschnitt der entwickelte Prototyp vorgestellt. Abschnitt 6 gibt als Ausblick eine Bewertung tiefergehender Anwendungsmöglichkeiten des Objektparadigmas. 2 Modellzerlegung von WWW-Dokumenten Gemäß den Anforderungen aus Abschnitt 1 ist ein (WWW-)Dokument in die drei Komponenten Inhalt, Struktur und Layout zu zerlegen. Während Inhalt alle Informa-

3 tionen bzw. Daten, die ein Dokument enthält, also Texte, Bilder, Grafiken, Klänge usw. umfasst [Lar95, S. 172], wird mit der Struktur die Anordnung bzw. Reihenfolge der Daten im Dokument festgelegt. Beispielsweise können nach einem bestimmten Text ein weiterer Text oder aber eine Grafik oder beliebige andere Daten folgen. Mit dem Layout wird die reine graphische Darstellung der einzelnen Daten bzw. Elemente eines Dokuments bezeichnet. Durch Formatierungen wie Schriftgröße, Schriftart, Ausrichtung usw. werden das Layout des Dokuments beschrieben und so das visuelle Erscheinungsbild des Dokuments bestimmt [BM98, S ]. Abbildung 1 zeigt diese Architektur, auf der jedes Dokument grundsätzlich basiert. Abb. 1. Komponenten eines Dokuments (in Anlehnung an [BM98, S. 31]). Unter Integrationsgesichtspunkten ist die Strukturkomponente von herausragender Bedeutung. Bezüglich der Struktur der einzelnen Daten können verschiedene Grade unterschieden werden, deren Anzahl und Grenzen aber nicht eindeutig festgelegt werden können. In der Literatur sind in diesem Zusammenhang unter anderem Begriffe wie unstrukturiert, schwach strukturiert, semistrukturiert und schlecht strukturiert zu finden. Der Grund für diese unterschiedlichen Bezeichnungen ist, dass die Datenstruktur immer von der Sichtweise des Einzelnen und seiner Modellierungsintention abhängt. In diesem Beitrag werden nur drei Strukturiertheitsgrade bezüglich der Daten betrachtet: unstrukturiert, semistrukturiert und strukturiert. Zu den unstrukturierten Daten werden hier Binärdaten wie Bilder, Töne und Videos gezählt. Da der Aufwand, um alle notwendigen Daten für eine detailliertere Strukturbeschreibung dieser Daten zu erfassen, sehr hoch ist, werden diese Daten nicht bezüglich ihrer Struktur analysiert, sondern jeweils als eine elementare Einheit angesehen. Abiteboul [Abi97] bezeichnet diese Daten daher auch als raw data (d. h. Rohdaten). Strukturierte Daten sind Daten, die eine feste, vorgegebene Struktur besitzen. Dazu gehören z. B. die Daten aus den operativen Anwendungssystemen. Die Strukturinformation kann direkt aus der Quelldatenbank (relational oder objektorientiert) übernommen werden.

4 Zwischen den beiden Extremformen stehen die semistrukturierten Daten. Darunter fallen alle Daten, die weder Rohdaten sind, noch einer strikten Typisierung unterliegen, wie es bei den Daten in relationalen und objektorientierten Datenbanken der Fall ist [Abi97]. Lange Texte sowie graphische Daten sind Beispiele für semistrukturierte Daten. Abiteboul hat mehrere Merkmale aufgestellt, mit denen sie charakterisiert werden können [Abi97]. Danach besitzen semistrukturierte Daten wie z. B. Texte eine gewisse, partielle Struktur. Diese ist jedoch nur implizit vorhanden und damit ausschließlich der Interpretation des Betrachters überlassen. Während bei den Daten aus der Datenbank stets eine eindeutige Strukturbeschreibung vorliegt, verschwindet bei semistrukturierten Daten die Struktur im Kontext der Daten. Bei der Interpretation von semistrukturierten Daten existieren somit Freiheitsgrade, die zur Modellierung genutzt werden können. Gegenüber den unstrukturierten Daten, die hier nicht weiter strukturiert werden, besteht bei semistrukturierten Daten die Möglichkeit, eine tiefere Strukturierung zu erreichen. Durch Interpretation des Dateninhalts kann die sonst nur implizit vorliegende Struktur explizit gemacht werden. In Form eines Strukturierungsprozesses werden dabei zunächst die vorhandenen (semantischen und/oder syntaktischen) Strukturen der Daten identifiziert. Anschließend werden Merkmale bzw. Attribute bestimmt, die diese Struktur explizit beschreiben. Anhand der Attribute findet dann die Unterteilung und Abgrenzung der Daten statt. Die so identifizierte Struktur eines Dokuments kann mittels eines Hierarchiebaums abgebildet werden. Durch die getrennte Verwaltung von Inhalt, Struktur- und Layoutinformationen eines Dokuments wird eine höhere Flexibilität bezüglich ihrer Gestaltung bereitgestellt. Auf der einen Seite ist es dann möglich, gleiche Inhalte in verschiedenen Strukturen einzubauen und sie unterschiedlich zu präsentieren. Andererseits können aber auch unterschiedliche Inhalte gleich strukturiert und/oder dargestellt werden, um so eine einheitliche Präsentation zu erreichen. Mit einer klaren Trennung von Inhalt, Struktur und Layout wird außerdem die Wiederverwendung vereinfacht [FST99] und erhöht. Beispielsweise besteht dann die Möglichkeit, ein für ein bestimmtes Dokument definiertes Layout ohne weiteres auch für die Darstellung anderer Dokumente einzusetzen. Ein weiterer Grund für die Trennung ist, dass dadurch eine bessere Wartung und Pflege der Daten gewährleistet werden kann. Da ein Inhalt an verschiedenen Stellen bzw. in verschiedenen Strukturen in unterschiedlichen Dokumenten vorkommen kann, müssten bei einer Änderung alle Dokumente nach dem zu ändernden Inhalt durchsucht werden und korrigiert werden. Wenn jedoch eine Trennung von Inhalt, Struktur und Layout vorliegt, muss der Inhalt nur an einer Stelle korrigiert werden. Die Änderung wird dann automatisch in allen Dokumenten und an allen Stellen bzw. in jeder Struktur (Kapitel, Absatz, Definition, Zitat, usw.) wirksam, in der der Inhalt vorkommt. 3 Das objektorientierte Integrationskonzept Um die unstrukturierten, semistrukturierten und strukturierten Daten in einer Struktur zu vereinen, die dann vielseitig genutzt werden kann (z. B. für Recherchen), müssen sie bezüglich ihrer Strukturierung in irgendeiner Form angeglichen werden. Die Inte-

5 gration der verschieden strukturierten Daten erfolgt hier durch die Erstellung eines objektorientierten Modells, in dem die unterschiedlichen Strukturen einheitlich beschrieben werden (siehe Abbildung 2). Abb. 2. Integration von Daten unterschiedlicher Strukturiertheitsgrade in einem oo-modell. Für die strukturierten Daten aus der Datenbank liegen bereits Attribute zur Beschreibung der Objektstruktur vor. Beispielsweise wird ein Auftragsobjekt durch die Instanzvariablen datum, kunde und auftragspositionsliste beschrieben, in denen die Referenzen zu den entsprechenden Objekten gespeichert werden. Da die Strukturbeschreibung der strukturierten Daten sehr genau ist, können sie direkt in das oo- Modell aufgenommen werden. Unstrukturierte Daten lassen sich, wie bereits erwähnt, nur mit einem sehr hohen Aufwand in ihrer Struktur beschreiben. Sie werden daher aus Vereinfachungsgründen in diesem Modell nur in Form einer Referenz auf den Dateinamen berücksichtigt. Für jeden Typ von unstrukturierten Daten, also Bilder, Videos und Töne, wird jeweils eine Klasse definiert, die eine Instanzvariable z. B. dateiname enthält, in der der Dateipfad als Wert gespeichert wird. Um beispielsweise ein Bild mit in das Objektmodell aufzunehmen, wird eine Instanz der Klasse Bild erzeugt und der Variablen dateiname der entsprechende Dateipfad zugewiesen. Semistrukturierte Daten werden im Gegensatz zu den unstrukturierten Daten in ihrer Struktur genauer analysiert und modelliert. Hierzu muss eine Menge von strukturbeschreibenden Elementen zur Verfügung gestellt werden, die die typischerweise sichtenspezifische Heterogenität verschiedener Anwendersichten abbilden kann. Elemente sind dabei unter anderem Absatz, Kapitel, Fußnote, Beispiel, Definition, Liste oder Aufzählung. Für jedes Element wird dabei eine eigene Klassendefinition angelegt, die spezifische Eigenschaften beinhaltet. Das Strukturelement Kapitel kann z. B. durch die zwei Instanzvariablen nummer und titel beschrieben werden, während dagegen die Klassendefinition Aufzaehlung aus einer Instanzvariablen vom Typ Liste

6 besteht, in der dann die einzelnen Textstücke, genauer die Verweise darauf, gespeichert werden. Ein zu integrierender, semistrukturierter Text muss also gemäß der jeweiligen Sichtweise des Anwenders nach den vorliegenden Strukturelementen analysiert werden. Anschließend wird von der Klasse jedes gefundenen oder ausgewählten Strukturelements eine Instanz erzeugt und der Instanzvariablen die entsprechende Textstelle (d. h. der Inhalt) zugewiesen. Der semistrukturierte Text wird auf diese Weise strukturiert modelliert. Für die Umsetzung des Prinzips der Trennung von Inhalt, Struktur und Layout in die Objektorientierung spielt insbesondere die Identitäts-Eigenschaft der Objekte eine große Rolle. Hiermit stellt die Objektorientierung einen starken Mechanismus bereit, der die Konsistenz der Daten jedes einzelnen Objektes gewährleistet. Werden die Daten eines Objektes geändert, dann wird die Änderung überall dort übernommen, wo das Objekt auftritt bzw. wo es referenziert wird, da es nur einmal vorliegt. Durch die Möglichkeit der mehrfachen Referenzierung eines Objektes durch andere Objekte wird außerdem eine redundanzfreie Speicherung gewährleistet. Während bei den strukturierten Daten der Inhalt stets eindeutig zu einem Objekt zugeordnet ist, kann bei semistrukturierten Daten derselbe Inhalt in unterschiedlichen Strukturelementen enthalten sein. Ohne diese insbesondere bei XML fehlende Trennung des Inhalts von der Struktur ist es daher bei den semistrukturierten Daten nicht möglich, die Konsistenz der Daten zu erhalten. Aus diesem Grund wurde für den Inhalt der Daten generell eine eigene Klasse definiert. Diese besitzt nur eine Instanzvariable inhalt, in der (bei Textdaten) der Inhalt in Form eines Strings gespeichert wird. Bei der Festlegung eines Strukturelementes für eine bestimmte Textstelle wird dann der Inhalt als Inhaltsobjekt bzw. als Liste von Inhaltsobjekten dem Strukturobjekt in der Instanzvariable inhalte zugewiesen. Ändert sich der Inhalt, muss nur die Instanzvariable des Inhaltsobjekts aktualisiert werden bzw. einen neuen Wert zugeordnet bekommen. Die Änderung wird dann in allen Strukturelementen, in der das Inhaltsobjekt referenziert wird, übernommen. Während die Strukturobjekte eine Referenz auf die Inhaltsobjekte besitzen, existiert für jedes Strukturobjekt ein entsprechendes Layoutobjekt, das eine Referenz auf das Strukturobjekt bzw. im Fall der strukturierten Daten auf das darzustellende Objekt beinhaltet. Ein Layoutobjekt setzt sich dabei aus einer Instanzvariable struktur- Element, in der der Zeiger auf das Strukturobjekt gespeichert ist, und beliebigen anderen Instanzvariablen, in denen Layoutinformationen wie beispielsweise Schriftgröße oder Ausrichtung festgehalten werden, zusammen. In der Abbildung 3 wird das Zusammenspiel von Inhalts-, Struktur- und Layoutmodell in Gestalt eines Objektmodells veranschaulicht. Gemäß dem Modell besteht nun jedes Dokument (bzw. Dokumentenobjekt) aus einer Bezeichnung (name), einer Struktur (struktur), die sich wiederum aus einer Vielzahl an einzelnen Strukturelementen zusammensetzt, und einer Layoutvorlage (layoutvorlage), die einzelne Layoutmuster enthält. Durch die Umsetzung dieses Konzeptes, kommt der Vorteil der Trennung von Inhalt, Struktur und Layout vollständig zur Geltung. Derselbe Inhalt kann dann in mehreren unterschiedlichen Strukturen in unterschiedlichen Dokumenten eingebunden sein. Die entstandenen Strukturen mit ihren referenzierten Inhalten können wiederum mittels unterschiedlicher Layouts dargestellt werden. Auf der anderen Seite können unterschiedliche Strukturen auch mit dem gleichen Layout präsentiert werden und so eine

7 einheitliche Darstellung bieten. Insgesamt wird mit dem Konzept eine sehr große Flexibilität bereitgestellt und die Wartung der Daten erleichtert. Abb. 3. Zusammenspiel von Inhalts-, Struktur- und Layoutmodell. 4 Die Entwicklungsumgebung VisualWave und GemStone Zur Implementierung des Modells aus Abschnitt 3 unter gleichzeitiger Bereitstellung einer dynamischen Web-Anbindung wurden VisualWave und GemStone kombiniert eingesetzt. Bei VisualWave 2.0a von Cincom handelt es sich um eine Erweiterung der objektorientierten Entwicklungsumgebung VisualWorks, mit der Client/Server- Anwendungen erstellt werden können. Die in VisualWave implementierte Erweiterung des VisualWorks-Systems umfasst dabei die Integration eines Web- Servers. Damit können die in VisualWave entwickelten Anwendungen im Gegensatz zu VisualWorks auch im World Wide Web betrieben werden [PPD96, S. 1-2]. VisualWave besitzt somit das komplette Smalltalk-Environment, d. h. die gesamte Klassenbibliothek von VisualWorks, erweitert um Klassen, die eine Konvertierung in eine Web-Anwendung erlauben und einen im Smalltalk-Image integrierten Web- Server, über den VisualWave mit verschiedenen Web-Browsern kommunizieren kann [OS98, S. 17]. Der Web-Server hat dabei die Aufgabe, die Kommunikation zwischen VisualWave und dem WWW zu verwalten und zu überwachen. Er ist unter anderem für die Bearbeitung eingehender HTTP-Anfragen (Requests) und die Verwaltung und Überwachung von Benutzersitzungen zuständig. Nach Eingang eines Requests von einem Web-Browser wird vom Web-Server die Anfrage interpretiert und an die Web- Anwendung weitergeleitet. Die Anwendung verarbeitet schließlich die übermittelten Informationen und bestimmt die Ergebnisse. Diese werden dann vom Web-Server in HTML kodiert und an den Browser zurückgesendet [WK96, S. 39]. Die Kommunikation zwischen dem Web-Server und der Web-Anwendung erfolgt über spezielle Auflöser-Objekte, sogenannte Resolver. Diese sind im Image enthalten und werden

8 vom Web-Server dazu benutzt, die in der Uniform Resource Locator (URL) gelieferten Informationen zu übersetzen und eine entsprechende Aktion auszulösen [OS98, S. 38]. Ihre Aufgabe ist es somit, auf die vom Web-Browser angeforderte URL zu reagieren [WK96, S. 39] und eine Web-Session zu starten. Durch die Generierung von einzelnen Sessions ist es möglich, dass mehrere Benutzer Zugriff auf den gleichen Web-Server haben und getrennte Instanzen der gleichen VisualWave- Anwendung laufen lassen können, ohne dass es zu Konflikten kommt [PPD96, S. 34]. Jeder Benutzer kommuniziert somit mit der laufenden Anwendung in seinem eigenen Kontext [Knö97, S. 43]. Des Weiteren bietet VisualWave auch die Möglichkeit der Datenbankanbindung. VisualWave stellt Schnittstellen zu relationalen Datenbanken wie Sybase und Oracle sowie zu der objektorientierten Datenbank GemStone bereit [AGW98, S. 141]. Die Schnittstelle für GemStone ist das GemStone-Smalltalk-Interface (GSI). GSI ermöglicht den direkten Zugriff von VisualWave auf die GemStone-Datenbank. Bei der Architektur von GemStone handelt es sich um ein Singleserver-multipleclients- System. Auf der einen Seite gibt es den Server-Prozess (Stone), dessen Aufgabe es unter anderem ist, die Steuerung von Transaktionen zu verwalten sowie das Ein- und Ausloggen der Benutzer zu regeln. Demgegenüber stehen die einzelnen Client- Prozesse (auch Gems genannt), die für jede neu angebundene Sitzung am Server erzeugt werden. Ihre Aufgabe liegt beispielsweise darin, eine effiziente Speicherung der Daten, eine performante Datenabfrage, sowie die Datensicherheit zu gewährleisten [AGW98, S ]. GemStone ist ebenso wie VisualWave eine Smalltalk-Implementation und basiert somit auf den gleichen Konzepten. Bei einer Anwendungsentwicklung auf Grundlage beider Systeme entfällt daher eine aufwendige Überführung bzw. Abbildung der zugrundeliegenden Objektmodelle (impedance mismatch). Der Übergang von Visual- Wave zu GemStone (und umgekehrt) erfolgt transparent [AGW98, S. 142]. Über VisualWave erhält GemStone andererseits eine Kopplung an das Internet. Das bringt den Vorteil, dass die Interaktion, Präsentation und die Speicherung voneinander getrennt werden können. Während GemStone für die Speicherung der Daten zuständig ist, übernimmt die Web-Server-Komponente die Verwaltung und Zuordnung der Dialoge zwischen der Anwendung und dem Web-Browser. Außerdem bietet der Web-Server die Möglichkeit, Teile der Web-Seiten bei jedem Aufruf unterschiedlich zu gestalten, da der HTML-Code und damit die HTML-Repräsentation zur Laufzeit neu generiert wird [Ass97]. 5 Der objektorientierte Prototyp Mit dem in VisualWave entwickelten Prototypen ist es möglich, über einen Browser WWW-Dokumente zu erstellen. Die Strukturierung des Dokumenteninhalts wird dabei vom Prototypen mittels einer vorgegebenen Liste von Strukturelementen unterstützt, mit denen der Anwender den Inhalt beliebig tief strukturieren kann. Der Prototyp ermöglicht es, sowohl unstrukturierte, semistrukturierten, als auch strukturierte Daten in einem Dokument zu integrieren und sie konsistent und redundanzfrei zu verwalten. Des Weiteren lassen sich mit dem Prototypen unterschiedliche Layout-

9 vorlagen erzeugen, die der Anwender gemäß seinen eigenen Präferenzen editieren kann. Für die Ausgabe eines Dokuments als HTML-Seite muss dem Dokument nur eine der Vorlagen zugewiesen werden. Will der Anwender die Darstellung des Dokuments ändern, muss er nur die Layoutvorlage austauschen. Die Darstellung der Dokumente wird dabei nicht gespeichert. In Abbildung 4 ist das Anwendungsfenster des Prototypen zum Editieren bzw. zum Erstellen der Dokumentenstruktur dargestellt. In der Liste links oben wird der Strukturteil der ausgewählten Dokumenteninstanz angezeigt. Gleich darunter befinden sich die Liste mit den vom Prototypen zur Verfügung gestellten Strukturelementen und die Liste mit den bereits vorliegenden Inhaltsobjekten. Für die Ergänzung eines bestimmten Inhalts (z. B. Das elementare Modell ) in ein Dokument muss der Anwender gemäß seiner Sichtweise ein zu dem Inhalt passendes Strukturelement (z. B. Kapitel) markieren und dann die Funktion hinzufügen aufrufen. Hierdurch wird von dem selektierten Strukturelement eine neue Instanz generiert, die einen Verweis auf das ebenfalls ausgewählte Inhaltsobjekt speichert. Das Strukturelement wird anschließend an der Stelle der Markierung im Strukturteil der Dokumenteninstanz eingefügt. Falls der Inhalt, der in das Dokument mit aufgenommen werden soll, noch nicht vorhanden ist oder nur teilweise vorliegt, bietet der Prototyp die Möglichkeit, die einzelnen Inhalte über die Funktion Inhalt editieren zu editieren. Abb. 4. Fenster zum Editieren der Dokumentenstruktur. Die Erstellung einer Dokumentenstruktur durch die Kombination von Inhaltsobjekt und Strukturelement beschreibt nur die Integration von unstrukturierten und semistrukturierten Daten in ein Dokument. Um strukturierte Daten zu integrieren, ist im Prototypen ein anderes Vorgehen anzuwenden. Da der Inhalt dieser Daten schon in strukturierter Form vorliegt, wird kein weiteres Strukturelement benötigt. Die Daten

10 können daher direkt in die Struktur eingefügt werden. In den beiden Listen auf der rechten Seite werden somit die strukturierten Daten separat von den Inhaltsobjekten verwaltet. Die erste Liste enthält dabei die einzelnen Listen der unterschiedlichen Datentypen wie Kunde und Wein. Wird ein Datentyp selektiert, können dann in der anderen Liste alle von diesem Datentyp existierenden Instanzen angezeigt werden. Beim Hinzufügen von strukturierten Daten in das Dokument, bietet der Prototyp dem Anwender die Auswahl, entweder ein ganz bestimmtes Objekt eines bestimmten Datentyps zu integrieren oder alle Instanzen eines Typs mit in die Struktur aufzunehmen. Ist die Dokumentenstruktur durch das Hinzufügen von Strukturelementen aufgebaut worden, können die einzelnen Strukturelemente im Prototypen noch bezüglich ihrer Strukturbeschreibung editiert werden. Für jedes Strukturelement gibt es ein spezielles Anwendungsfenster, das eine für das Element typische Strukturbeschreibung beinhaltet und den referenzierten Inhalt anzeigt. Ein Strukturelement Kapitel kann beispielsweise zusätzlich zu dem Inhalt, den es referenziert, noch durch einen Gliederungspunkt beschrieben werden, während eine Grafik noch eine Beschriftung beinhalten kann. Abb. 5. Beispiel einer mit dem Prototypen erzeugten HTML-Seite. Der objektorientierte Prototyp unterstützt des Weiteren die Verwaltung und Bearbeitung von Layoutvorlagen für die Darstellung der erstellten Dokumente. Um eine neue Layoutvorlage zu erstellen, wird über einen bestimmten Funktionsaufruf von jedem Layoutmuster, das vom Prototypen unterstützt wird, eine neue Instanz gebildet, die schon mit bestimmten Formateigenschaften ausgestattet ist. Da ein Layoutmuster gemäß dem darzustellenden Strukturelement durch verschiedene und unterschiedlich viele Formateigenschaften gekennzeichnet ist, gibt es für jedes Muster ein eigenes

11 Anwendungsfenster zum Setzen der Formateigenschaften. Das Layoutmuster Absatz stellt z. B. für die Formatierung des Inhalt des gleichnamigen Strukturelements dem Anwender vier Anweisungen zur Verfügung. Es können sowohl Schriftgröße, Schriftfarbe und bestimmte weitere Optionen zur Formatierung der Schrift als auch die Ausrichtung des Inhalts gesetzt werden. Mittels des Prototypen ist es zum einen möglich, den Inhalt und die Struktur eines Dokuments zu definieren, auf der anderen Seite erlaubt er aber auch, dessen Darstellung zu gestalten. Damit ein Dokument weiß, nach welcher Layoutvorlage es sich darstellen soll, wird ihm durch eine bestimmte Funktion das gewünschte Layout zugewiesen. Um eine Vorschau auf das Layout des erstellten Dokuments zu bieten, wurde die Funktion Als HTML-Seite darstellen im Prototypen eingebaut. Mit dieser wird ein neues Fensters geöffnet, in dem das gerade selektierte Dokument dynamisch in HTML konvertiert und dann als HTML-Seite dargestellt wird. Für die Darstellung eines Dokuments wird dabei eine Anwendung, konkret eine Instanz von Dokument, gestartet, die die Oberfläche für das Dokument bereitstellt. Die Abbildung 5 zeigt ein Beispiel für eine so entstandene HTML-Seite. 6 Ausblick Mit dem Dokumentenstandard XML wird eine Integration der Daten unterschiedlicher Strukturiertheitsgrade, vor allem von semistrukturierten Daten, unterstützt. Bezüglich der Datenspeicherung ist jedoch ein größerer Aufwand durch die Definition von Mappings zu betreiben. Da sich die Dokumentenstruktur und die Datenbankstruktur fast immer voneinander unterscheiden, müssen die Strukturen für einen gegenseitigen Datentransfer mittels Mappings aufeinander abgebildet werden. Der entwickelte Prototyp, der ebenfalls in der Lage ist, unterschiedlich strukturierte Daten in einer gemeinsamen Struktur zu integrieren, besitzt dieses Abbildungsproblem nicht. Durch die Kombination einer objektorientierten Entwicklungsumgebung mit einem ODBMS, die beide noch auf derselben Programmiersprache basieren, liegen keine Unterschiede in den abzubildenden Strukturen vor. Es findet daher im Gegensatz zu XML kein Strukturbruch statt. Das Konzept der Trennung von Inhalt, Struktur und Layout eines Dokuments bietet eine sehr hohe Flexibilität bezüglich der Gestaltung der Dokumente. Bei einer noch konsequenteren Umsetzung als beim vorgestellten, objektorientierten Prototypen könnten der Wartungsaufwand weiter verringert und die Konsistenz der Daten stärker gewährleistet werden. Die im Prototypen verwaltete kleinste Einheit von semistrukturierten Daten ist ein String bzw. eine Zeichenkette in Form von Sätzen. Es wäre jedoch auch denkbar, eine noch tiefere Zerlegung zu unterstützen und zwar die Aufspaltung der Sätze in einzelne Wörter. Ein Satz besteht schließlich aus der Aneinanderreihung von einzelnen Wörtern, diese könnten beispielsweise in Form einer Liste gesammelt werden. Durch die strikte Trennung des Inhalts eines Wortes und der Struktur (also das Strukturelement Wort) wäre es schließlich kein Problem mehr, eine Änderung der Schreibweise der Wörter zu ändern, da nur noch an einer Stelle und zwar dem Inhalt, das Wort geändert werden muss. Bei der Einführung einer neuen Rechtschreibreform würde bei solch einer Implementation der Aufwand der Korrektur

12 der einzelnen Dokumente auf ein Minimum sinken. Die Inhalte der Wörter müssten nur an einer Stelle aktualisiert werden, damit in allen Dokumenten die Änderungen übernommen werden. Für die Inhalte der einzelnen Wörter könnte beispielsweise ein komplettes Wörterbuch gespeichert sein, d. h. jedes Wort entspricht genau einem Inhaltsobjekt. Da jedoch die Satzbildung dadurch um ein Vielfaches verkompliziert wird, dass jeder Satz mühsam aus der Kombination von Inhalt und Strukturelement Wort zusammengesetzt werden müsste, ist davon auszugehen, dass diese Granularität sich nicht durchsetzen wird. Dies wäre nur denkbar, wenn es eine Art Konverter geben würde, der die einzelnen Sätze selbständig in die einzelnen Wörter zerlegt und als solche speichert. In diesem Zusammenhang ist jedoch zu beachten, dass bei jedem Wort nachgeschaut werden muss, ob das Wort schon einmal existiert, damit ein Wort nicht mehrfach erfasst wird. Ob ein Wort schon existiert oder nicht wird dabei mittels eines Vergleichs überprüft, indem alle bereits existierenden Inhalte nach dem bestimmten Wort durchsucht werden. Es muss nun abgewogen werden, ob der Vorteil der einfacheren Datenpflege dem größeren Aufwand bei der Erstellung der Dokumente vorgezogen werden sollte. Literatur [Abi97] [AGW98] Abiteboul, S.: Quering Semi-Structured Data, in: Proceedings of the International Conference on Database Theory, Delphi Greece, 1997, <ftp://ftp.inria.fr/inria/projects/verso/versoreport-103.ps.gz> ( ). Assfalg, R./Goebels, U./Welter, H.: Internet-Datenbanken, Konzepte, Modelle, Werkzeuge, Addison-Wesley Longman, [Ass97] Assfalg, R.: OODB-Unterstützung für Internet-Applikationen, Datenbank-Rundbrief, Ausgabe 20, 1997, < ( ). [BM98] Behme, H./Mintert, S.: XML in der Praxis, Professionelles Web-Publishing mit der Extensible Markup Language, Addison-Wesley Longman, [FST99] Fernandez, M./Suciu, D./Tatarinov, I.: Declarative Specification of Data-intensive Web sites, in: USENIX Conference on Domain-Specific Language, 1999, < ( ). [Knö97] Knöfel, S.: Smalltalk im World Wide Web, in: OBJEKTspektrum, Heft , S [Lar95] Larson, J. A.: Database Directions: From Relational to Distributed, Multimedia, and Object- Oriented Database Systems, Prentice Hall PTR, [LL95] Lang, S. M./Lockemann, P. C.: Datenbankeinsatz, Springer, [OS98] ObjectShare: VisualWave: Application Developer s Guide, ObjectShare Inc. Release 3.0, [PPD96] ParcPlace-Digital: Getting Started with VisualWave, ParcPlace-Digital, Inc., Revision 2.0, [RBK+98] Rieger, B./Brodmann, K./Krüger, D./von Maur, E./Postert, S.: UniWeb, Ein integratives Konzept zur datenbank-gestützten Verwaltung, Navigation und Distribution semistrukturierter Informationsobjekte, in: Uhr, W./Breuer, S.-E. (Hrsg.): Integration externer Informationen in Management Support Systems, Tagungsband, 1998, S [Sch99] Schoop, E.: Informationsmanagement, in: WISU, Heft , S [WK96] Wasserschaff, M./Kaul, M.: Erfahrungen mit VisualWave 1.0 Entwicklung eines Projektmanagementsystems im WWW, in: OBJEKTspektrum, Heft , S