Bei Datenbank-Frontends für Anwender gilt Microsoft Access als Maß aller Dinge. Rekall, Kexi, Knoda und OpenOffice Base treten gegen den Platzhirsch an.

Im Rechenzentrum stellen Open-Source-DBMS schon lange eine feste Größe dar. Auch der Linux-Desktop hat sich inzwischen etabliert. Was bislang fehlte, war das Bindeglied zwischen beiden: ein Programm, das es dem Anwender ermöglicht, mit geringem Aufwand Datenbankanwendungen zu erstellen. Für Windows positioniert sich Microsoft Access hier als Platzhirsch, der Open-Source-Bereich ließ bislang ein Pendant vermissen.

Die Lücke schmerzt besonders, weil gerade im privaten Einsatz und für kleine Unternehmen grafische Datenbank-Frontends die effiziente Verarbeitung von Datenbeständen und die Entwicklung einfacher Datenbankanwendungen erst ermöglichen. Aber auch im Profi-Umfeld scheitert die Umstellung von Windows auf Linux oft deswegen, weil sich entsprechende Fachanwendungen nur schwer portieren lassen.

Der Mangel an einem geeigneten Ersatz für Access beschäftig denn die Open-Source-Entwickler schon lange. Inzwischen bieten sich auch die ersten brauchbaren Access-Alternativen für Linux an. Dieser Artikel nimmt die aussichtsreichsten Kandidaten näher unter die Lupe: Rekall, Knoda, Kexi und OpenOffice Base.

Die grundlegenden Leistungsmerkmale haben alle diese Produkte gemein: Man kann Tabellen grafisch geführt anlegen, es gibt ein Datengitter zur Eingabe der Tabellendaten, es lassen sich Abfragen mit grafischer Aufbereitung erzeugen. Daneben bilden Formulare und Berichte (“Reports”) wichtige Komponenten: grafisch ausgestaltete und anpassbare Schnittstellen zur Ein- und Ausgabe der Daten. Schließlich bietet auch jedes Produkt ein quasi eingebettetes Datenbankmanagementsystem zur lokalen Datenspeicherung in Dateien, sowie die Möglichkeit, externe Datenbankserver anzusprechen.

Um Access funktionell ersetzen zu können, wären jedoch einige zusätzliche Fähigkeiten wünschenswert:

• Skriptfähigkeit, um eigene Anwendungen mit speziellen Code-Teilen zu ergänzen,
• Komponenten, um die Skripte zur Wiederverwendung in Module zusammenzufassen,
• ein Standalone-Modus für die erstellte Anwendung, um diese weiterzugeben,
• Assistenten oder Wizards zur Benutzerführung,
• die Möglichkeit, aus den Daten grafische Darstellungen zu erzeugen,
• die Integration mit Büro-Anwendungen, etwa um Serienbriefe zu erzeugen.

Unter diesen Gesichtspunkten müssen im folgenden Rekall, Knoda, Kexi und OpenOffice Base ihre Fähigkeiten beweisen.

Rekall

Rekall stellt 2002 den ersten ernstzunehmenden Versuch dar, eine Alternative zu Microsoft Access für Linux anzubieten. Ursprünglich gab theKompany.com [1] das Paket in Auftrag, zerstritt sich jedoch später mit den Entwicklern Mike Richardson und John Dean. Das Unternehmen vertreibt weiterhin veraltete Versionen; hat aber dem Vernehmen nach keine technischen Resourcen hat, um diese zu pflegen und zu unterstützen. Richardson und Dean entwicklen Rekall nach wie vor mit kommerziellem Hintergrund weiter [2], bieten daneben aber auch eine GPL-Version [3] an. Das Frontend lässt sich als KDE-Anwendung oder reines Qt-Programm bauen, wobei die Entwickler ersteres als primäre Variante betrachten.

Rekall unterstützt die DBMS MySQL, PostgreSQL, ODBC, IBM DB/2 und als “eingebautes” Datenbanksystem XBase. Für den Zugriff auf das Datenbanksystem verwendet Rekall eine eigene Treiberschicht. Seine Metadaten – also die angelegten Anfragen, Formulare und so weiter – speichert es entweder in der Datenbank selbst oder in einer eigenen Steuerdatei.

Rekall ermöglicht, Tabellen anzulegen (Abbildung 1), Daten zu bearbeiten und Anfragen mit dem Query-Designer zu entwerfen (Abbildung 2). Beim Erstellen der Tabelle bietet das Programm alle vom zugrundeliegenden Datenbanksystem unterstützten Datentypen an. Es lassen sich Formulare (Abbildung 3) und Berichte erstellen, beides auch mittels Wizards. Als Skriptsprache nutzt Rekall Python und bietet dazu sogar einen integrierten Editor sowie einen Debugger. Der erstellte Code lässt sich in wiederverwendbare Komponenten zusammenfassten. Zum Betrieb der so erstellten Anwendungen gibt es eine Rekall Runtime genannte Standalone-Variante.

Abbildung 1: Der Dialog zum Erstellen von Tabellen in Rekall.

Abbildung 2: Die Schnittstelle zum Anlegen von Anfragen in Rekall.

Abbildung 3: Formulare lassen sich in Rekall wie hier direkt bearbeiten oder in einem Wizard erstellen.

Der große Nachteil von Rekall: Die langfristige Entwicklung des Produkts ist nicht gesichert. Die beiden Entwickler haben den Aufbau einer größeren Developer-Community stets abgelehnt, um sich die Möglichkeit zum Verkauf kommerzieller Lizenzen nicht zu verderben. Allerdings läuft dieses Geschäft dem Vernehmen nach bei weitem nicht profitabel genug, worauf auch die schleppende Entwicklung in der letzten Zeit sowie die mangelhaft gepflegte Website hindeuten.

Das Produkt bietet durchaus beeindruckende Leistungsmerkmale, an der Bedienung scheiden sich jedoch oft die Geister: Hier zeigen sich durchweg große Unterschiede zu Access, aber auch zu anderen typischen KDE-Anwendungen. An der technischen Einbindung in die KDE-Oberfläche hapert es ebenso wie an der Integration mit Büro-Anwendungen, etwa zum Erzeugen von Serienbriefen oder Diagrammen. Im übrigen gelang es dem Autor bisher nicht, Rekall zur Verwendung eines deutschen Formats für Datumsfelder zu überreden.

Knoda

Jenseits des großen Hypes um Linux-Office-Pakete und Linux-Startups entwickelte Horst Knorr das Paket Knoda [4] (“Knorr’s Datenbank”). Das KDE-Programm läuft offiziell auf Linux und FreeBSD, inoffiziell aber sicher auch auf anderen Unix-Derivaten. Knoda kommt mit den DBMS MySQL, PostgreSQL, Firebird, ODBC, SQLite und dBase zurecht; daneben kann es Access- und Paradox-Datenbanken lesen. Die Zugriff nimmt es über eine eigene Treiberschicht (hk-classes) vor, die auch als Bibliothek verfügbar ist.

Knoda bietet alle für diese Anwendungsklasse üblichen Fähigkeiten: Es lassen sich Tabellen anlegen (Abbildung 4), Daten bearbeiten und Abfragen erstellen (Abbildung 5). Dabei beschränkt sich Knoda auf eigene Datentypen, die es dann intern in vom Datenbankserver unterstützte Typen umwandelt. Das fördert zwar die Unabhängigkeit vom DBMS, schränkt den Benutzer aber in gewissem Sinn ein. Daneben kann Knoda auch Formulare und Berichte erstellen, wenn auch ohne Assistent. Als Skriptsprache steht Python zur Verfügung.

Abbildung 4: Der Dialog zum Anlegen von Tabellen in Knoda ist gewöhnungsbedürftig und fehleranfällig.

Abbildung 5: Der Editor zum Erstellen von Abfragen in Knoda erinnert sehr an das von Microsoft Access bekannte Muster.

Eine Besonderheit von Knoda: Es speichert die erstellten Datenbankanwendungen implizit und automatisch im Verzeichnis ~/.hk_classes/ macht. Dieses ungewöhnliche Konzept erschwert den Austausch oder den Versand der erstellten Datenbanken. Dafür arbeitet Knoda auch auf Datenbanken, die nicht mit dem Programm angelegt oder gewartet worden sind, und kann deren Tabellen einfach im Abfrageneditor verwenden. Insofern stellt Knoda ein wirkliches Datenbank-Frontend dar, weniger eine eigene Applikationsplattform.

Trotz der verwendeten KDE-Technologie fehlt Knoda die Anbindung an Office-Anwendungen zum Weiterverwenden der Daten. Die Datenbanktreiber erweisen sich zum Teil als unausgereift. So weigert sich Knoda beim Verwenden von PostgreSQL, die Typen einmal angelegter Spalten zu ändern, obwohl aktuelle Versionen von PostgreSQL dies sehr wohl beherrschen. Auch an anderen Stellen des Programms fallen Instabilitäten und mangelnde Robustheit gegenüber ausgefallenen Benutzungsversuchen auf. Letzten Endes bleibt fraglich, ob ein Ein-Mann-“Team” eine derartige Anwendung langfristig effektiv warten kann.

Kexi

Längerfristig vielversprechender erscheint Kexi ([5], [6]), das Datenbankprogramm des KOffice-Projekts. Es läuft sowohl unter Linux wie auch Windows und bietet alle grundlegenden Features: Tabellen anlegen, Daten bearbeiten, Anfragen erstellen (Abbildung 6). Wie Knoda beschränkt sich auch Kexi beim Anlegen von Tabellen auf eine eingeschränkte Auswahl an Datentypen. Das Programm bringt einen eigenen Formulareditor (Abbildung 7) mit; das Erzeugen von Berichten überlässt es dagegen dem ebenfalls zur KOffice-Familie gehörenden Programm Kugar [7] vorbehalten.

Auch Kexi verwendet Python als Skriptsprache, wobei die Entwickler hier als Status noch Technology Preview (BETA) angeben. Hinzu dürfte früher oder später im Rahmen einer entsprechenden KDE-weiten Bewegung auch JavaScript kommen. Aktuell greift Kexi lediglich auf die DBMS MySQL, PostgreSQL und SQLite zu, wobei es eigene Treiber verwendet. SQLite dient dabei als DBMS mit lokalem Dateispeicher. Schließlich importiert Kexi auch Access-Datenbanken – jedoch nur die Tabellen und Daten, nicht aber die darum gebauten Anwendungen.

Abbildung 6: Der Editor zum Erstellen von Abfragen in Kexi bietet eine vertraute Benutzerführung.

Abbildung 7: Beim Anlegen von Formulaten in Kexi gilt es Hand anzugelegen: Ein Assistent fehlt derzeit noch.

Abbildung 8: Zur Auswahl der Datenbankverbindung bietet Kexi 1.0 endlich einen gut gelungenen grafischen Dialog.

Kexi ist aktuell noch keine besonders ausgereifte Software. Die erste vorgeblich stabile und vollständige Version 1.0 wurde im April diesen Jahres als Teil von KOffice 1.5 veröffentlicht. Bei ersten Tests fiel gegenüber den früheren Versionen positiv auf, dass zuvor vermisste Features wie Fremdschlüssel Einzug gefunden haben und ein sehr funktioneller Verbindungseditor (Abbildung 8) hinzugekommen ist und eine wenn auch minimale Dokumentation beiliegt. Allerdings “gelang” es im Test, auch diese Versionnur wenige Klicks nach dem Start ohne Absicht zum Absturz zu bringen. Anderseits verspricht Kexi durch seine enge Integration mit KDE enormes technisches Potenzial. So tauscht es Daten mit anderen KOffice-Anwendungen wie Kugar, KSpread, KChart und KWord aus. Zudem entwickelt sich die KDE-Komponenten-Technologie rasch weiter.

OpenOffice.org

Am ausgereiftesten (und wohl auch mit der größten Marketing-Maschinerie) präsentiert sich OpenOffice.org [8]. Die Bürosuite ist auf Linux, Solaris, Windows und Mac OS X verfügbar. Auf Linux bietet OpenOffice.org optional KDE- oder GNOME-Integration, was sich aber hauptsächlich auf die Optik und Benutzerführung beschränkt. Seit Version 2.0 bringt OpenOffice.org als Datenbank-Frontend die Komponente Base mit.

OOBase bietet für viele Aufgaben Assistenten, etwa zum Anlegen von Tabellen, Abfragen, Formularen und Berichten. So zumindest die Theorie: In der Praxis bleibt auch in der getesteten Version 2.0.1 ein Klick auf Abfrage unter Verwendung des Assistenten erstellen ohne Effekt, ebenso bei Formularen. Der Menüpunkt Bericht unter Verwendung des Assistenten erstellen öffnet die Textverarbeitung (“Writer”), was bei aller Fantasie nicht als Assistent durchgehen kann. Zumindest der Tabellen-Assistent funktioniert (Abbildung 9) aber und bietet als Einstiegshilfe eine Auswahl an Beispieltabellen an.

Abbildung 9: OOBase bietet als einziges Programm einen Tabellen-Assistenten.

Abbildung 10: Der Abfrageentwurf in OOBase scheint visuell eine Kopie des großen Bruders zu sein.

Die Fenster zum Eingeben von Daten und Erzeugen von Anfragen entsprechen den üblichen Mustern (Abbildung 10). Als Skriptsprachen bietet OpenOffice.org Python sowie eine Basic-Variante (OpenOffice.org Basic, auch als StarBasic bekannt). Beide Varianten sind nur mangelhaft und teilweise widersprüglich dokumentiert. Zumindest zu StarBasic gibt es aber umfangreiche Literatur, sodass dem professionellen Einsatz insofern nichts im Weg steht.

Zum Datenbankzugriff verwendet OOBase wahlweise die Schnittstellen JDBC oder ODBC, womit sich so gut wie jedes DBMS verwenden lässt. Alternativ steht ein eigenes Interface namens SDBC parat, für das es aktuell Treiber für Adabas D, ADO, dBase, Microsoft Access, MySQL und PostgreSQL gibt. Als natives DBMS nutzt OpenOffice seit Version 2.0 HSQLDB, ein vollständig in Java geschriebenes SQL-Datenbankmanagementsystem mit umfangreichen Features. Daneben kann OOBase auch auf LDAP-Adressbücher zugreifen.

OpenOffice Base wirkt im Vergleich zu den besprochenen Alternativen am ausgereiftesten, was es zur ersten Wahl für den Einsatz in Datenbankanwendungen macht. Zudem sprechen sowohl die Größe der Entwicklerorganisation als auch das hohe öffentliche Interesse am Openoffice-Projekt dafür, dass es auch die sicherste Wahl für die Zukunft darstellt.

Fazit

Bei den freien Datenbank-Frontends stehen mittlerweile einige respektable Lösungen zur Auswahl. Allen getesteten Produkte bieten ausreichende Basisfunktionen, die sie mehr oder weniger gleich abbilden. In vielen Aspekten allerdings unterscheiden siesich doch: in der Benutzerführung, bei den Editoren und Wizards, den Skriptsprachen (die zwar alle Python heißen, aber keine einheitliche API bieten) und auch in der Art und Weise, wie sie die verschiedenen DBMS unterstützen.

Mängel und Fehler gibt es bei allen Kandidaten noch in vielen Details, wovon einige hier genannt wurden, andere aber eher ein zwiespältiges Gefühl hinterlassen (“Warum geht das nicht, wenn ich hier klicke?”). Auch die Integration mit anderen Komponenten und Programmen aus den Bereichen Office, E-Mail und Web tut teilweise noch Not. Ohne die Möglichkeit, Daten auf vielfältige Art weiterzuverarbeiten, ist eine Datenbank letztendlich nur wenig wert. Aus technischer Sicht wäre zudem eine Vereinheitlichung der Datenbankschnittstellen wünschenswert.

Auch wenn es nun Open-Source-Alternativen zu Access gibt, ist an eine automatisierte Umstellung von Access-Datenbanken noch nicht zu denken. Dafür wäre in aller Regel Visual-Basic-Programmtext zu übernehmen, was technisch kaum verlässlich möglich ist. Auch den meisten Profis fällt dazu nur eine Lösung ein: Neu eintippen …