Bereits zu Zeiten der Version 1.2 war von vielen "laut darüber nachgedacht" worden, daß möglicherweise eine Datenbank von einem Dritthersteller (im Gespräch war Certified Software) in Arbeit sei. Schließlich war eine universelle Dateiverwaltung (eine spezielle Adressdatenbank gab es ja schon) genau das, was neben einer Tabellenkalkulation noch zum kompletten integrierten Paket fehlte.

Das Geoworks 2.0 auch über eine eingebaute Datenbank verfügen sollte, gehörte dann auch zu den ersten Ankündigungen, die trotz aller Schweigepolitik von Hersteller und Distributor offiziell bestätigt wurden. Allerdings sollte die Datenbank nun eine Eigenentwicklung von Geoworks sein - man konnte also gespannt sein, was die Entwickler in Berkeley sich zu diesem Thema einfallen ließen.

Alle Anmerkungen in diesem Artikel beziehen sich auf die freigegebene amerikanische Presse-Betaversion 2.0.22, Abweichungen gegenüber dem deutschen Update sind also in einigen Details noch möglich - aus diesem Grund wurde auch auf Aussagen über Stabilität und eventuelle Fehler verzichtet, da eine Beurteilung nach einer Beta hier einfach unfair wäre.

Klassische Datenbanken

Das Icon von GeoFile zeigt schon, daß man sich eine Datenbank am einfachsten als Karteikasten vorstellen kann, in dem man seine Daten in Form von einzelnen Karteikarten (Datensätzen, z. B. ein Datensatz pro Person) speichert, auf denen unter verschiedenen Rubriken irgendwelche Informationen stehen (Datenfelder, z. B. Name, Kundennummer, Adresse, usw. ). Alle Karteikarten zusammen bilden die Datenbank, die man mit einem Programm sortieren, ausdrucken, ... kann.

Wer sich bereits mit "klassischen" DOS-Datenbanken beschäftigt hat (typische Vertreter sind natürlich dBASE und kompatible Systeme), wird in GeoFile vor allem aus zwei Gründen umdenken müssen: Der erste ist der, daß die Entwickler wohl gar keine Ambitionen hatten, sich mit den "Dinosauriern" der Datenbankwelt anzulegen, sondern statt dessen einen einfach zu bedienenden "elektronischen Karteikasten" liefern wollten. Zum zweiten hat man die gewohnte Struktur eines Datenbank-Entwurfs durch ein vereinfachtes, aber ziemlich flexibles Konzept ersetzt. Normalerweise geht man beim Aufbau einer kleineren Datenbank etwa so vor:

1. Definition der Datenfelder: Hier muß gewöhnlich auch festgelegt werden, wieviele Zeichen die einzelnen Felder maximal enthalten dürfen, und welcher Typ von Daten (Text, Zahl, Datum etc.) im Feld gespeichert werden soll.
2. Festlegen einer Eingabemaske (wie sind die Felder auf dem Bildschirm angeordnet?)
3. Eingeben von Datensätzen (klar...)
4. Ausgeben, Sortieren usw. der Daten nach bestimmten Kriterien. Dazu müssen sogenannte Reports ("Berichte") erstellt werden, die festlegen, welche Teile der Daten im Ausdruck erscheinen und wie sie dargestellt werden sollen (z. B. Liste aller Adressen, nach Geburtsdatum sortiert und in Tabellenform).

Diese Schritte sind mehr oder weniger klar voneinander abgegrenzt, d. h., sobald man einmal angefangen hat, Daten in eine Maske einzutippen, sind keine weiteren Änderungen am Datenformat mehr möglich (außer, indem man eine andere Datenbank mit neuen Feldern aufbaut und die Daten dort hineinkopiert). Auch das Ausgabeformat der Daten hat nichts mit der Eingabemaske auf dem Bildschirm zu tun.

Das Konzept von GeoFile

Natürlich muß man auch in GeoFile bei einer neuen Datenbank damit anfangen, irgendwelche Felder zu definieren, damit es überhaupt etwas abzuspeichern gibt. Diese Felder werden aber sofort in eine Bildschirmmaske aufgenommen und man kann durch Anklicken des "Erstellen"-Buttons gleich anfangen, Daten in diese Maske zu tippen. Durch Auswahl des "Drucken..." Menüpunktes kann man die Daten in der Form ausdrucken, in der man sie eingetippt hat.

Besonders interessant ist jedoch die Möglichkeit, auch während der Eingabe von Daten jederzeit in den "Erstellen"-Modus zurückschalten zu können, um vergessene Datenfelder nachträglich ergänzen zu können. Natürlich kann auch die Definition eines Feldes später wieder geändert werden, wobei schon existierende Daten (wenn möglich) umgewandelt werden.

Bei den Möglichkeiten, die für die Angabe von Feldtypen zur Verfügung stehen, hat sich Geoworks nicht lumpen lassen: Neben Text, Ganzzahlen und Zahlen mit Nachkommastellen stehen auch spezielle Typen für Datum und Zeit zur Verfügung. Außerdem lassen sich über Formeln auch Felder erzeugen, die automatisch das Ergebnis einer Berechnung enthalten, entweder als editierbare Vorgabe oder als nichtveränderbarer Wert.

Während in GeoFile nur eine Liste der dabei verwendbaren Funktionen auftaucht, kann man sich in GeoCalc auch kurze Erklärungen zu diesen anzeigen lassen, was (auch ohne Handbuch) schon ahnen läßt, was für Möglichkeiten in diesen Berechnungen stecken: Neben Mathematik, Bedingungen und Vergleichen können auch Stringmanipulationen durchgeführt werden - damit kann man schon teilweise das Manko wettmachen, daß GeoFile nicht über eine eigene Programmiersprache verfügt.

Layouts

Neben der leichten Veränderbarkeit der Datenbank ist die zweite Stärke von GeoFile das "Layout"-Konzept, das so weit wie möglich versucht, die WYSIWYG-Idee (möglichst wenig Unterschied zwischen Bildschirmanzeige und Ausdruck) auch auf Datenbanken zu übertragen: Sobald man zu einer Datenbank eine Reihe von Feldern definiert hat, kann man beliebig viele Layouts für die Daten anlegen. Ein Layout legt fest, welche der Felder überhaupt angezeigt werden und in welchem Format das geschieht (z. B. als Geldbetrag, als Prozentwert, usw.). Außerdem kann man ein solches Layout mit grafischen Elementen (Trennlinien, Erklärungen, etc.) anreichern, wobei natürlich alle Möglichkeiten von GeoDraw zur Verfügung stehen.

Ein Layout legt außerdem fest, wie groß der Datensatz bei einem späteren Ausdruck erscheint. Mehrere Sätze auf einer Seite können in Spalten angeordnet werden, womit z. B. auch der Ausdruck auf mehrbahnige Etiketten möglich ist. Auch das Seitenlayout kann wieder mit Grafik aufpoliert werden - Seitenüberschriften sind kein Problem.

Typischerweise wird man sich eine Eingabemaske mit allen Feldern anlegen, mit der man schnell neue Daten in die Datenbank bekommt. Es ist aber auch möglich, für verschiedene Typen von Datensätzen, für die jeweils nur einen Teil der Felder interessant ist, unterschiedliche Layouts zu definieren.
Eine Frage in den amerikanischen Datennetzen nach dem Erscheinen der 2.0 war: "Wie kann ich denn meine Daten als Tabelle anzeigen lassen?". Auch darauf lautet die Antwort (natürlich): Mit einem Layout - man definiert sich ein Layout, das mehrere Sätze auf einer Seite darstellen kann, indem man die Satzhöhe entsprechend klein einstellt und ordnet in diesem Streifen die gewünschten Felder nebeneinander an. Leider gibt es hierfür keine Layout-Hilfe, die einem diese Arbeit erleichtert oder z. B. die Felder automatisch anordnet. Auch für die Spaltenüberschriften habe ich bisher keine bessere Methode gefunden, als sie durch ständiges Umschalten zwischen Einzel- und Mehrsatzmodus möglichst schön zu plazieren.

Ebenso kann man sich spezielle Layouts für verschiedene Ausgabezwecke festlegen, also beispielsweise eines für eine Adreßliste, eines für den Etikettendruck, eine komplette Liste, die alle Daten enthält und eine verkürzte, die "geheime" Angaben wie das Geburtsdatum nicht aufführt.

Natürlich kann man die Daten auch sortieren oder alle Daten, die einem bestimmten Kriterium genügen, markieren lassen und die Anzeige dann auf die markierten Sätze beschränken. In Verbindung mit berechneten Feldern (auch solchen, die nicht angezeigt werden) kann man mit etwas Überlegung bereits recht komplexe Probleme mit diesen Instrumenten lösen. Sortier- und Markierkriterien beziehen sich aber immer auf die gesamte Datenbank und können nicht separat für jedes Layout gespeichert werden, so daß eine Sammlung von Ausgabevorschriften für verschiedene Zwecke etwas eingeschränkt wird.

Nicht möglich sind komplexere Ausgaben, die Sätze mit unterschiedlicher Satzgröße enthalten. Klassisches Beispiel dafür ist eine Adreßliste, die nach Postleitzahlen geordnet ist und beim Wechsel der ersten Ziffer eine Zwischenüberschrift wie etwa "PLZ-Bereich 5" produziert.

Das volle Angebot solcher Möglichkeiten würde allerdings auch leicht den Rahmen eines Programms sprengen, das wie Geoworks eher eine Grundausstattung als ein Universalprogramm darstellen soll. Aus dem gleichen Grund wurde vermutlich auch völlig auf den Bereich "verknüpfte Datenbanken" (Relationen) verzichtet, also die Verbindung von Daten in mehreren Datenbanken untereinander, um z. B. bei jedem Datensatz für eine Rechnung durch die Kundennummer auch sofort die Adresse aus der Kundendatei zur Verfügung zu haben.

Durchaus ins Konzept passen würde dagegen eine echt "visuelle" Erweiterung der Datenbank mit Feldern, die auch Grafikobjekte enthalten könnten. Solche Objekte ließen sich leicht aus anderen Applikationen (vor allem GeoDraw) importieren und einfach über "Kopieren & Einkleben" in Datensätze einfügen lassen.

Nicht vergessen sollte man auch, daß die GeoFile-Datenbank die Grundlage für die lang erwartete Serienbrief-Funktion in GeoWrite ist. Für diesen Zweck wird eine spezielle Muster-Datei (Dateivorlage mit fertiger Eingabemaske, die nur noch ausgefüllt werden muß) mitgeliefert, mit deren Hilfe man schnell Serienbriefe erstellen kann, indem Daten aus bestimmten Feldern beim Ausdruck in den GeoWrite-Text eingefügt werden.
Ebenso wie in den anderen Programmen der Version 2.0 gibt es in GeoFile Möglichkeiten zum Import und Export von Dateien anderer Formate, hier dBASE, Lotus 1-2-3 und CSV (durch Komma getrennte Werte im ASCII-Format).

Insgesamt sollte man den "Neuankömmling" im Geoworks-Paket GeoFile nicht leichtfertig unterschätzen, zumindest für solche Aufgaben, die im Privatbereich und auch in kleinen Geschäften anfallen können. Man sollte aber auch nicht übersehen, daß für ein zukünftiges "GeoBase" (wenn es denn kommt...) noch reichlich Raum für Erweiterungen gelassen wurde.

Marcus Gröber