Gründlich analysiert: Datenbank Phoenix - Der Wundervogel (Teil 1)

Phoenix ist ein Vogel aus der griechischen Sage, der sich im hohen Alter selbst verbrannte und aus der Asche verjüngt hervorging; ein Sinnbild der Unsterblichkeit. Gereicht die gleichnamige, brandneue Datenbank-Software von Application Systems Heidelberg dem antiken Vorbild zur Ehre?

Wer die Zwillinge Dieter und Jürgen Geiß kennt, stellt an ein Werk aus dieser Software-Schmiede hohe Erwartungen: Haben sich die beiden mit ihrer Portierung der Datenbank »Adimens« auf den ST vor fünf Jahren doch einen hohen Rang in der Atari-Szene verschafft. Zwei Trümpfe spielten die beiden aus: Datenbank-Know-How sowie das Verständnis, daß Anwender eben Anwender und keine Informatiker sind. Damit gelang es ihnen, ein Datenbanksystem zu entwickeln, das auf dem Atari ST und TT seinesgleichen sucht: Phoenix. Der erste Teil dieses Tests bringt Ihnen das revolutionäre Konzept und den Leistungsumfang des Datenbankgiganten näher. Im zweiten Teil gehen wir auf die Arbeitsgeschwindigkeit ein - auch im Vergleich zur Konkurrenz.

Die Entwickler investierten in die Benutzerführung des Programms sehr viel Zeit und Aufwand. Da GEM den Anforderungen, zum Beispiel in puncto Dialogboxen, Kontrollelementen oder Prozeßverwaltung nicht gewachsen war, mußten sie einen Großteil dieser Routinen selbst realisieren. Beim Entwickeln dieser neuen Bestandteile der Benutzerschnittstelle hielten sich die Entwickler erfreulicherweise an bereits definierte Standards, die teilweise von Apple und IBM (Microsoft) stammen.

Auch die Dialoge sind kontextbezogen, ein Verlassen der Dialogbox ist also nur erlaubt, wenn alle Eingaben syntaktisch in Ordnung sind. Bestimmte Funktionen sind nur dann zur Anwahl freigegeben, wenn bestimmte Voraussetzungen erfüllt sind.

Somit haben Sie schon einen groben Überblick über die Mensch-Computer-Schnittstelle, die in Phoenix integriert ist. Diese Elemente ziehen sich durch das gesamte System, vom Anlegen bis zum Bearbeiten einer Datenbank. Mit Phoenix zu arbeiten macht Spaß. Die Arbeit geht flüssig von der Hand - Verzeihung, Maus -und der Einarbeitungsaufwand hält sich durch die intuitive Bedienung ebenfalls in Grenzen. Ein Appell an die Entwickler: Stellt doch bitte die erweiterte Entwicklungsumgebung wieder interessierten Programmierern zur Verfügung (Update des »Inside GEM«), damit viele neue Programme sich ebenfalls an diese Konzepte anlehnen können.

Da Phoenix in erster Linie Daten verwalten und nicht nur »bedient« werden soll, wenden wir uns nun der Funktionalität des Wundervogels zu. Beginnen wir mit einer bemerkenswerten Liste der technischen Daten des Datenbankkerns.

Hierzu nun einige Erläuterungen: Phoenix ist eine relationale Datenbank, es verwaltet also die Daten in tabellarischer Form. Pro Datenbank legt es eine oder mehrere Tabellen an. Existieren mehrere Tabellen, so kann man zwischen diesen Tabellen bestimmte Beziehungen (Relationen) definieren.

Hier ist das Thema Datenbank-Design gefragt, das den Umfang dieses Artikels allerdings sprengen würde. Ein Beispiel verdeutlicht diese »Beziehungskiste«: Stellen Sie sich vor, Sie verwalten in Ihrer Datenbank Kundenadressen und Rechnungsdaten. Somit haben Sie zwei Tabellen in Ihrer Datenbank: »Kunden« und »Rechnungen«.

Das oben erwähnte Merkmal mit dem Zungenbrecher-Namen »Referentielle Integrität« ist ein Überwachungsmechanismus, der alle Beziehungen einer offenen Datenbank kontrolliert. So ist es ausgeschlossen, einen Kunden, der noch offene Rechnungen hat, aus seiner Tabelle zu löschen, wenn diese Freiheit nicht bei der Beziehungsdefinition zugelassen wurde.

Ein weiterer Begriff aus der obigen Liste lautet »Index-Caching«. Verfügt der Computer über genügend RAM, lädt Phoenix die gesamte Schlüssel-Tabelle in den Hauptspeicher. Dies spart bei Suchvorgängen viel Zeit und steigert die Verarbeitungsgeschwindigkeit. Kommen wir nun zum eigentlichen Programm. Phoenix besteht aus zwei Hauptprogrammen. Zum einem dem Designer, mit dem Sie Datenbanken und Masken definieren, und zum anderen dem Manager, der für die spätere Bearbeitung der Datenbank zuständig ist. Beginnen wir mit dem Designer. Nach dem Start fordert er eine Datenbank an, die man anlegen oder ändern möchte. Ist dies geschehen, so öffnet sich das Fenster, in dem Sie die Datenbankstruktur definieren. Das Designer-Arbeitsfenster zeigt Bild 1.

Bild 1. Arbeitsfenster im Phoenix-Designer
Bild 2. Anlegen von neuen Feldern

Auf der linken Seite im Fenster befindet sich die Toolbox. Sie stellt alle grundlegenden Werkzeuge zur Verfügung, die zum Aufbau einer Datenbank nötig sind. In diesem Fall sind das: Tabellen, Felder, Indizes, Masken sowie Beziehungspfeile. Im einfachsten Fall ziehen Sie das Tabellensymbol in den Arbeitsbereich, worauf Phoenix eine leere Tabelle anlegt. Um diese mit Feldern zu füllen, ziehen Sie das Feldsymbol in die leere Tabelle. Nun erscheint ein Dialog, der vielfältige Einstellungen erlaubt (Bild 2).

Hier fallen zunächst die elf Datentypen ins Auge. Neben den Standardtypen (Text, Zahl, Datum, etc.) bietet Phoenix hier einiges mehr. Da wäre zunächst der Typ »Externe Datei«. Mit ihm verwalten Sie beliebige Dateinamen, die sich sinnvollerweise auf Ihrer Festplatte befinden sollten. Phoenix ist sogar in der Lage, Dateien des Typs ».IMG«, ».GEM« und ASCII-Texte auf Anforderung anzuzeigen. Anders verwalten Sie Grafiken mit dem Feldtyp »Grafik«. Hier arbeiten Sie ebenfalls mit den beiden GEM-Standard-Grafiktypen, allerdings mit dem Unterschied, daß Phoenix die Grafikinformationen direkt in der Datenbank ablegt.

Das letzte interessante Feld heißt »BLOB«. BLOB ist ein echter Datentyp mit Zukunft. Er akzeptiert beliebige unstrukturierte Daten. Zur Zeit ist die Verwendung dieses Typs allerdings nur mit Sound-Sample-Dateien ».SAM« sinnvoll. Für diese Art von Daten ist in Phoenix ein Modul zum Abspielen von Sounds integriert. Die mitgelieferte Beispieldatenbank demonstriert dies überzeugend. Dies ist jedoch nur der Anfang für den flexiblen BLOB. In einer späteren Version gibt es eine Schnittstelle zu externen Programmen, die dann die Interpretation der erfaßten Daten vornehmen. Dem Einfallsreichtum sind keine nennenswerten Grenzen gesetzt.

Leider ist es nicht vorgesehen, multiple Felder zu erzeugen. Dieser Nachteil kommt zwar in einer Phoenix-Datenbank nicht direkt zum Tragen, da sich ein Feld über mehrere Zeilen ausdehnen läßt.

Probleme treten jedoch beim Importieren aus fremden Datenbanken auf, in denen solche Mehrfachausprägungen von bestimmten Feldern existieren.

Neben dem Datentyp definieren Sie hier diverse Feldattribute wie »Mußfeld« oder »Index«. Über den Knopf »Format...«gelangen Sie in einen weiteren Dialog, in dem Sie beliebige Formate zu jedem individuellen Feld angeben. Die hier erlaubten Kombinationen sind sehr umfangreich. Einige Beispiele verdeutlichen dies:

DD. MONTH YY  
HH:MI:mmmmmm  
*.***.***0,00 
Aaaaaaaaaaaaa

Sind die definierten Schlüssel einer Tabelle in ihrer Urform nicht ausreichend, so bietet Phoenix auch sogenannte Multi-Indizes. Ein Multi-Index besteht aus mindestens zwei normalen Index-Feldern, die zusammengesetzt einen neuen Index ergeben.

Haben Sie so Ihre Tabellen mit den entsprechenden Feldern definiert, so können Sie diverse Beziehungen zwischen den Tabellen aufbauen. Dazu wählen Sie in der Toolbox den gezackten Pfeil und zeichnen die gewünschten Strecken zwischen den Tabellen. Den ersten Typ einer Beziehung habe ich oben bereits beschrieben. Bei der Definition solch einer Beziehung erscheint die in Bild 3 dargestellte Dialogbox.

Hier geht's dann schon ins Eingemachte. Sie müssen bestimmte Regeln für verschiedene Fälle angeben. Dabei kommt man anfangs leicht durcheinander. Doch wie überall macht Übung auch hier den Meister. Wer schon einmal auf großen kommerziellen Datenbanken solche Regeln definieren mußte, ist über die Erleichterung erfreut, die Phoenix hier durch die intuitive Bedienung bietet.

Neben der obigen Beziehung gibt es noch einen zweiten Relationstyp im Land des Phoenix. Dieser trägt den Namen »Wertetabelle«. Stellen Sie sich vor, Sie haben tausende von Adressen zu erfassen. Bei solch einer Aufgabe ist es lästig, ständig den Ort zu einer bestimmten Postleitzahl oder immer die selbe Anrede einzugeben. Für solche Fälle sind die genannten Wertetabellen zuständig. Eine Wertetabelle ist zunächst einmal eine ganz normale Tabelle in der Datenbankdefinition.

Das Festlegen von Integritätsregeln entfällt in diesem Fall. Bleibt noch zu erwähnen, daß eine solche Wertetabelle selbständig lernfähig ist. Der Anwender muß also nicht in mühevoller Arbeit am Anfang die Postleitzahltabelle füllen. Diese füllt sich im Laufe der Zeit automatisch aus der Adressen-Tabelle.

Als letzten Punkt im Designer wenden wir uns dem Masken-Editor zu. Dieser erlaubt uns, die von Phoenix benutzten Masken ganz individuell zu gestalten. Wer sich diese Arbeit nicht machen möchte, läßt sich beim Speichern der Datenbank eine Standardmaske von Phoenix erzeugen. Diese Standardmaske dürfen Sie später noch korrigieren oder verschönern. Erwähnenswert ist auch die Tatsache, daß die Masken in einer Multiuser-Umgebung für jeden Benutzer einzeln definierbar sind. So sieht jeder nur das, was ersehen soll oder darf. Haben Sie den Maskeneditor aufgerufen, bietet sich zum Beispiel der in Bild 4 gezeigte Anblick. Links im Fenster finden wir wieder eine Toolbox. Sie bietet folgende Elemente zur optischen Aufbereitung einer Maske: Linien, Rechtecke, abgerundete Rechtecke, Texte sowie Grafiken. Das Einbinden von Grafiken gestattet es, Firmenlogos oder ähnliches in eine Maske einzuflechten. Auch Füllmuster, Farbe, Linienart sowie die Schrift (hallo GDOS) sind variabel. Nur das Ändern der Objekte könnte komfortabler sein. Die Maus dient bei der Nachbearbeitung nur noch zum Verschieben. Die Größe eines Objekts läßt sich in der Definitionsbox nur durch Ändern der Werte »Zeichen« und »Zeilen« nachträglich modifizieren. Ein Feld aus der Datenbank erreichen Sie übrigens wieder intuitiv, indem Sie aus dem Tabellendefinitionsfenster den Eintrag in das Maskenfenster hineinziehen. Betrachten wir die Datenbankfelder intensiver, so stoßen wir auf den Dialog Feldattribute (Bild 5).

Zu erwähnen ist beim Designer noch die Tatsache, daß im Phoenix-Datenbanksystem auch ein ausgefeilter Benutzer- und Zugriffsschutz enthalten ist. Der Schutzmechanismus von Phoenix geht bis auf Feldebene herab.

Wer auf seinem Computer GDOS installiert hat, bringt auch seine Datenbankdefinition grafisch ansprechend zu Papier.

Eine C-Schnittstelle zu Phoenix ist angekündigt. Mit diesem Modul entwickeln interessierte Programmierer Anwendungen, die als Basis den Phoenix-Datenbank-Kern benutzen. Für diesen Zweck ist im Designer vorgesehen, eine C-Struktur der erzeugten Datenbank zu exportieren.

Kommen wir nun zum zweiten großen Teil des Phoenix-Systems: dem Manager. Wie bereits erwähnt dient dieser der Pflege und Auswertung Ihrer Daten. In diesem Programm halten Sie sich normalerweise auf, wenn Sie mit Phoenix arbeiten.

Die große Besonderheit des Managers ist der implementierte Multitasking-Kern, der diverse Aufgaben in den Hintergrund legen kann, während Sie noch in der Datenbank arbeiten. Zu diesen Aufgaben zählen zum Beispiel Ausführen von Reports, Drucken von Listen, Importieren/Exportieren von Daten, Ausführen von Abfragen und Löschen von Datensätzen. Bis zu sechs solcher Prozesse können parallel ablaufen.

Ein Beispiel-Desktop des Managers enthält neben den üblichen Icons für Papierkorb, Drucker und Laufwerk auch wieder eine Toolbox. Diesmal ist es die Datenbank-Tool box, die folgendes festlegt:

Alle diese Angaben berücksichtigt der nächste »Öffnen... «-Befehl. Dieser stellt die aktuelle Tabelle in der gewünschten Sortierreihenfolge tabellarisch auf dem Bildschirm dar (Bild 6).

Bild 3. Definition der referentiellen Integrität
Bild 4. Der Maskeneditor mit Beispielmaske
Bild 5. Diese Feldattribute kennt der Datenbank-Designer von Phoenix

Diese Tabellenfenster beweisen wieder einmal, wie schön vernünftig programmiertes GEM sein kann. Spaltenbreiten verändern Sie mit der Maus quasi in Echtzeit, auch das Umordnen der Spalten erreichen Sie mit dem kleinen Nager durch einfaches Verschieben.

Das Erfassen der Datensätze geht in Phoenix sehr bequem von der Hand. Alle Elemente (auch Buttons oder List-Boxen) erreichen Sie ohne die Maus, was den geübten Anwender flüssig arbeiten läßt. Eine Eingabemaske zeigt Bild 7.

Da es mit dem munteren Erfassen von Datensätzen nicht getan ist, hat Phoenix für das Auswerten und Ausgeben der Datensätze einiges zu bieten.

Fangen wir mit dem Modul an, mit dem Sie Abfragen definieren und ausführen. Zum Definieren einer Abfrage öffnet sich ein Tabellenfenster, dasauf den ersten Blick wie eine leere Datenbanktabelle aussieht. Oben sind die Feldnamen als Spaltentitel zu sehen, darunter sind kleine Kästchen mit Kreuzen plaziert (Bild 8).

Die Abfrage bestimmen Sie durch das einfache Einträgen von Beispielen in die entsprechenden Spalten. Das Kreuzchen unter dem Feldnamen gibt an, ob diese Spalte überhaupt interessiert und damit gewünscht wird. Zu guter Letzt geben Sie die Sortierreihenfolge der Abfrage an. Da Sie diese Angaben beispielhaft in die leere Tabelle eintragen, nennt man diese Art der Abfrage auch »Query By Example«, kurz QBE. Phoenix bildet aus der QBE-Definition eine Reihe von SQL-Befehlen (SQL = Structured Query Language), die die Datenbank intern abarbeitet. Für den Anwender bleibt SQL somit im Hintergrund verborgen - und das ist auch gut so.

Haben Sie so Ihre Daten ausgewählt, gilt es oft, diese vernünftig auszugeben. Auch hier läßt uns Phoenix nicht im Stich. Der integrierte Reportgenerator kommt fast allen Wünschen entgegen. Neben dem sturen Auflisten von Feldnamen beherrscht er eine Reihe von Tormatierungsarten. Hier zeigt sich wieder deutlich, daß Phoenix aus der Praxis entstand. Die Liste der Formatierungs-Variationen würde diesen Rahmen leider sprengen, daher hier nur ein paar Beispiele.

{TABELLE—A > TABELLE_B.Feldname}

Dies verweist auf eine in Relation stehende Tabelle; bis zu 64 Verschachtelungen sind erlaubt.

{Feld__A,";"} {Feld_B}

Das »;«-Zeichen wird nur dann ausgegeben, wenn »Feld_A« auch belegt ist.

{%Feld__A}

Die Zeile mit dem Feld »Feld_A« erscheint nur dann, wenn ein Eintrag dafür existiert.

{+}

Das »+«-Zeichen leitet eine Summierung von numerischen Feldern ein.

Übrigens müssen Sie keine externe Textverarbeitung starten, um Ihren Report zu schreiben. In Phoenix ist ein vollständiger Texteditor integriert. Mit diesem können Sie auch beliebige ASCII-Texte bearbeiten. Haben Sie etwas anderes erwartet?

In den meisten Fällen wollen Sie einen solchen Report auch ausdrucken. Die Druckerausgabe ist auch im Manager tabellarisch organisiert, es existiert also eine Drucker-Warteschlange.

Der nächste Funktionsblock betrifft die Rechenoperationen. In einem ähnlichen Fenster wie dem des Report-Generators bestimmen Sie beliebige Rechenoperationen, die Sie in einer bestimmten Tabelle durchführen wollen. Dabei stehen Ihnen neben den vier Grundrechenarten auch Klammerhierarchien, Systemdatum und -zeit, der Datensatzzähler sowie Funktionen zur Verfügung, die den kleinsten oder größten Schlüssel eines Feldes liefern. Haben Sie Ihre Rechnung definiert oder aus der bereits angelegten Bibliothek abgerufen, so starten Sie den Rechenprozeß. Dieser läuft selbstredend im Hintergrund ab. Wichtig für Umsteiger aus anderen Datenbanksystemen ist die Importfunktion. Diese ist ebenfalls sehr flexibel ausgefallen. Auch eine Exportfunktion gibt es. Sie ist notwendig, um Daten in andere Programme zu übertragen, Sicherheits-Backups der fertigen Tabellen anzulegen und vor allem, um mit Textverarbeitungsprogrammen Serienbrief-Aktionen durchzuführen.

Bild 6. So präsentiert sich eine Tabelle auf dem Monitor
Bild 7. Die Eingabemaske von Phoenix
Bild 8. So definieren Sie Abfragen in Phoenix

Generell weisen wir noch einmal darauf hin, daß alle beschriebenen Operationen (Abfrage, Report, Drucken, Rechnen, Im- und Export) als Prozeß im Hintergrund ablaufen und den Anwender bei seiner weiteren Arbeit nicht behindern. Auf einem Computer, der bisher Multitasking nur sehr eingeschränkt kannte, sind dies wirklich neue, faszinierende Dimensionen. Auch das Löschen von Datensätzen aus einer Tabelle wird als Prozeß gestartet. Gelöschte Datensätze entfernt Phoenix beim ersten Löschvorgang nicht physikalisch aus der Datenbank. Sie können diese jederzeit aus dem Papierkorb herausholen, bis Sie diesen entleeren. Versehentlich gelöschte Daten gehören somit - hoffentlich - der Vergangenheit an.

Abschließend noch ein paar Anmerkungen, die sich auf das gesamte System beziehen. An vielen Stellen des Programms können Sie bestimmte Fenster, Tabellen oder Prozesse zu Sinnbildern machen. Dies schafft auf dem Desktop mehr Ordnung und Übersicht. Beim Entfalten eines solchen Sinnbildes stellt sich das alte Bild wieder her. In der Sinnbildverwaltung ist Phoenix wiederum sehr flexibel. Jede Tabelle kann Ihr eigenes Bildchen bekommen, wenn Sie sich die Arbeit machen, dieses zu entwerfen. Eine Reihe von Sinnbildern sind auf den Originaldisketten enthalten. Beim Öffnen der Datenbank darf der Anwender die Größe des Index-Cache nach seinen Vorstellungen verändern. Phoenix gibt hier bei optimalen Speicherverhältnissen die maximale Größe der derzeitigen Indexdatei vor, so daß Korrekturen selten sind. Deshalb profitiert derjenige, der einen ordentlichen Speicherausbau hat, am meisten von der Cache-Funktion. Dies hängt auch von der Größe der verwendeten Datenbank ab. Nur ein komplexes System, mit sehr vielen Datensätzen, kann einen Mega ST4 in die Knie zwingen. Sollte der verfügbare Hauptspeicher wirklich nicht mehr ausreichen, um den gesamten Index aufzunehmen, so kürzt Phoenix den Hauptspeicherbedarf entsprechend. Es verwaltet den Bereich, der dann im Hauptspeicher liegt, nach einem intelligenten Algorithmus. Dieser stellt nur die am häufigsten gebrauchten Schlüssel bereit. Das ausgefeilte Cache-Management macht Phoenix unter den relationalen Datenbanken auf dem Atari ST/TT in puncto Geschwindigkeit konkurrenzlos. Über genaue Daten informieren wir in der nächsten Ausgabe.

Das mitgelieferte Handbuch rundet den positiven Gesamteindruck ab. Alle 400 Seiten sind sehr übersichtlich und reich illustriert.

Vor allem der Quick-Guide liest sich sehr flüssig, er führt den Datenbank-Neuling behutsam in die Materie ein. Die beiden ausführlichen Beschreibungen sind klar strukturiert aufgebaut und vermitteln dem Leser sachlich alles Wissenswerte. Der letzte Teil, das Tutorial, enthält von der einfachen Adreßkartei bis zur komplexen Büchereiverwaltung viele Beispiele und Regeln. Einige Passagen überladen den Leser mit etwas zu viel mathematischer Theorie. Diese Seiten sollten Sie zu einem späteren Zeitpunkt noch einmal durchgehen. Ein Glossar mit den wichtigsten Begriffen aus der Datenbank-Welt wäre für Einsteiger eine Hilfe, da es im Handbuch doch nicht immer ohne Fachausdrücke geht.

Alles in allem ist Phoenix ein Produkt, das den Datenbanksektor auf dem Atari ST/TT kräftig aufwirbelt. Die ausgefeilten Konzepte, in der Datenbankorganisation einerseits und in der vorbildlichen Benutzerführung andererseits, machen Phoenix zu meinem neuen Favoriten. Es ist nicht leicht, dem Zauber der sagenhaften Welt des Wundervogels zu widerstehen. (ts)

Application Systems Heidelberg, Englerstr. 3, 6900 Heidelberg 1

Literaturhinweise:

[1] Dieter & Jürgen Geiß, Vom Anfänger zum GEM-Profi, Hüthig Verlag, 1990

[2] Gut bei allem ist die Ordnung, TOS 3-5/91

TOS-INFO

Name: Phoenix
Preis: 398 Mark
Hersteller: ASH


Carsten Reinhardt
Aus: TOS 04 / 1991, Seite 20

Links

Copyright-Bestimmungen: siehe Über diese Seite