Textmanagement auf neue Art

Die Forschungsgruppe Datenbanktechnik am Institut für
Informatik der Uni Zürich hat ein revolutionäres Dokumenten­management- und Textverarbeitungssystem entwickelt. Der Projektname Tendax steht für «Text Native Database Extension» und beschreibt die Grundidee gut: Tendax speichert Text nicht in Files, sondern in einer Datenbank; als Frontend dient ein kollaborativer Editor mit aussergewöhnlichen Features, die erst durch die datenbankbasierte Speicherung ­überhaupt möglich werden. Die Idee stammt von Dr. Thomas B. Hodel, der das Projekt mit
Hilfe von zahlreichen Studierenden inzwischen erfolgreich ­realisiert hat.

InfoWeek: Herr Hodel, worum geht es bei Tendax?

Hodel: Der wichtigste Aspekt ist gleichzeitig am schwierigsten zu vermitteln. Tendax bricht radikal mit dem herkömmlichen Vorgehen, ganze Textdokumente in Form von Dateien im Filesystem zu speichern. Stattdessen wird jedes Zeichen zusammen mit Metadaten als Objekt in einer Datenbank gespeichert, entweder einzeln und sofort bei der Eingabe (synchron) oder mehrere gleichzeitig, aber nach wie vor als einzelne Objekte (asynchron) – vergleichbar ist dies mit einer Buchhaltung, in der ja auch jede Transaktion in einem separaten Datensatz abgelegt wird. Ein Dokument ist dann so etwas wie eine Sicht auf ausgewählte Daten der Datenbank, gewissermassen ein Report. Dokumente im herkömmlichen Sinn gibt es nicht mehr: Ein «Tendax-Dokument» setzt sich aus einer beliebigen Anzahl verknüpfter und ver­schachtelter Ringe von Objekten zusammen.

Inwieweit bringt dies Vorteile?

Die Dokumentenverarbeitung profitiert von allen Möglichkeiten der Datenbank-Engine: Abfragemöglichkeiten, Repräsentation von Beziehungen zwischen Textstellen, Zugriffskontrolle, persistente Speicherung, Datenintegrität, Backup/Recovery und vieles mehr. Der Ansatz ist meiner Meinung nach sehr innovativ – ich habe sonst noch nirgends ein ähnliches Konzept gesehen und vergleiche es gern mit der im Grunde simplen Erfindung der Tabellenkalkulation, aus der sich nahezu unerschöpfliche Möglichkeiten ergeben haben.

Wie sind Sie auf die Idee
gekommen?

Ich war an verschiedenen Projekten mit jeweils zwanzig und mehr Teilnehmern beteiligt und musste immer wieder feststellen, dass bei der Dokumentation enorm viel Zeit verloren ging – Dokumente mussten hin- und her verschoben werden. Im besten Fall wurden sie durch ein DMS mit Check-In/Out-Mechanismus verwaltet, aber das macht die Sache nicht weniger kompliziert. Meine Erkenntnis: Eigentlich müssten Text und Dokumente genau gleich wie alle anderen wichtigen Daten im Unternehmen behandelt, also in einer Datenbank gehalten werden.

Wie hat die Umwelt auf Ihre Idee reagiert?

Am Anfang hat selbst im Institut für Informatik kaum jemand daran geglaubt, dass so etwas überhaupt realisierbar ist. Jetzt, wo das System als Prototyp mit akzeptabler Performance mehr oder weniger stabil läuft, sieht es anders aus. Ich konnte Tendax bei verschiedenen Firmen vorstellen, zum Beispiel in der Pharmaindustrie, die sich sehr interessiert zeigt: Hier geht es um die Unmengen an Dokumenten, die im Zulassungsverfahren für neue Medikamente anfallen. Vor allem die Bestimmbarkeit der Herkunft (Data-Lineage) und die Metadaten jedes einzelnen Zeichens, die Möglichkeit von gleichzeitigen, parallelen Workflows innerhalb des gleichen Dokuments, die Multistrukturierungs-Funktion einschliesslich Semantik sowie der durchgängig kollaborative Ansatz sind interessant.
Ein Tendax-Vortrag bei Microsoft hat folgende Reaktion ausgelöst: «Wenn wir jetzt nochmals von vorne mit Office beginnen könnten, käme sehr wahrscheinliche der gleichen Ansatz zum Zug.»

Nach der Idee kommt die Umsetzung: Wie haben Sie das Konzept realisiert? br>
Mit dem Ziel einer «operativen Textdatenbank» im Hinterkopf habe ich mir zunächst im Detail die nötige Funktionalität aufgelistet und verschiedene Datenbanken evaluiert. Zusammen mit einem Diplomanden wurde dann das Fundament gebaut: Eine dreischichtige Architektur (Datenbank, Business-Logik, Präsentation) mit einer klaren Trennung von Core-Services (Datenbankoperationen, Message Propagator und kollaborativer Editor) und erweiterter Funktionalität (Data-Lineage, Metadaten-Visualisierung, Suche...), die sich modular durch Plug-Ins hinzufügen lässt. Am Aufbau des Grundgerüsts haben wir zu zweit etwa ein halbes Jahr gearbeitet.

Laut der Tendax-Website haben auch zahlreiche Studierende mitgearbeitet...

Richtig, die Plug-Ins wurden von Diplomanden und Diplomandinnen entwickelt. Dafür standen jeweils sechs Monate zur Verfügung: Zwei Monate zum Einarbeiten, zwei Monate Programmieren und zwei Monate zum Schreiben der Diplomarbeit. Dabei mussten Abhängigkeiten vermieden werden, zum Beispiel, dass jemand seine Arbeit nicht abschliessen kann, weil er auf Ergebnisse eines anderen Teilnehmers warten muss. Das ist fast immer gelungen.

Welche Tools kamen zum Einsatz?

Es wurde alles mit Java programmiert, als Entwicklungsumgebung haben wir Eclipse eingesetzt. Für das Source-Code-Management haben wir einen CVS-Server aufgesetzt.

Stand auch etwas anderes zur Diskussion?

Wir haben uns vor allem deshalb für Java entschieden, weil die Studierenden darin am besten ausgebildet sind. Ich selbst hätte vielleicht lieber mit C++ oder auf der .Net-Plattform gearbeitet, aber da hätten die Studierenden bei Null anfangen müssen. Eclipse als IDE stand mehr oder weniger von Anfang an fest, für unsere Zwecke war es klar die beste Umgebung.

Als Datenbank haben Sie ein eher wenig bekanntes Produkt gewählt. Was hat Caché, das andere DBMS nicht haben?

Zu Beginn haben wir mehrere Datenbanken evaluiert, sowohl kommerzielle als auch Open-Source-Software. Für Caché sprachen drei Punkte: Erstens wollten wir uns auf die Herausforderung konzentrieren und möglichst wenig Zeit mit Konfiguration und Wartung verbringen. Im Haus wäre zwar viel DB2-Know-how vorhanden, und ich selbst habe gute Oracle-Kenntnisse. Auf diesen Plattformen wäre der Verwaltungsaufwand aber viel höher; die Studierenden hätten einen Grossteil ihrer Zeit mit unproduktiven Administrationsaufgaben zubringen müssen. Zweitens lassen sich in Caché Java-Objekte direkt speichern – andere Datenbanken erledigen dies meist über optionale Mapper, bei Caché kommt diese Funktionalität out-of-the-box, da Caché eben gleichzeitig objektorientiert und relational arbeitet. Drittens die Performance: Caché bewältigt die Aufgaben, die bei Tendax zu lösen sind, enorm schneller als die anderen evaluierten Systeme. Neben der SQL- und der Objektsicht auf die gespeicherten Daten erlaubt Caché überdies auch den gerade für ein Forschungsprojekt wichtigen direkten Zugriff auf einer tieferen Ebene, unter Umgehung der üblichen «Datenbank-Gesetze». Wir konnten zwar letztlich alle Aufgaben mit den Standardfunktionen bewältigen; ein Test hat aber gezeigt, dass sich die Performance bei direkter Datenmanipulation nochmals um die Hälfte steigern liesse – wir haben also noch Reserven.

Was für eine Zukunft steht
Tendax bevor?

In der Schublade soll das Projekt nicht verschwinden, auch wenn die Idee nicht ganz einfach zu verkaufen ist – viele Gesprächsparter meinen, Textmanagement funktioniere doch auch auf File-Basis, wieso es denn eine Datenbank brauche. Wie es konkret weitergeht, weiss ich aber noch nicht. Das weitere Vorgehen wird vermutlich in den nächsten Monaten entschieden. Eine Variante wäre die Weiterführung als EU- oder KTI-Projekt. Vielleicht werden Ex-Diplomanden zusammen ein Unternehmen gründen und Venture-Kapital aufnehmen. Möglicherweise wird der Prototyp der Open-Source-Gemeinde übergeben, oder aber das Projekt und die Publikationen bleiben liegen, bis ein Unternehmen die Idee aufnimmt und das «Textverarbeitungsprogramm der Zukunft» entwickelt. Ich bin fest davon überzeugt, dass in Zukunft alle Daten in einer Tendax-ähnlichen Art und Weise in einer Datenbank gespeichert und verarbeitet werden, nur schon aus Sicherheitsüberlegungen. Das ist nur eine Frage der Zeit.

(ubi)