Die Wiedergeburt: Phoenix 2.0 von Application Systems
Nachdem wir uns in der letzten Ausgabe sehr ausführlich mit allgemeinen Fragen und Betrachtungen zum Programm befaßt haben, reichen wir dieses Mal den »Designer«- und den »Reorganizer«-Teil nach«
Mit dem Designer entwerfen Sie neue Datenbanken oder ändern vorhandene. Die Arbeit mit ihm ist gewöhnungsbedürftig, dafür steckt er voller Überraschungen und erlaubt Dinge, die Sie auf dem PC-Markt suchen können. Ähnlich komfortable Datenbanken lassen sich wohl nur noch mit dem Macintosh anlegen. Datenbanken werden in Fenstern entworfen, die am linken Rand eine Toolbox mit allen erforderlichen Elementen und im Kopf eine Leiste für PopUp-Menüs enthalten. Sie dürfen mehrere Datenbanken gleichzeitig bearbeiten. Dann hat jedes Fenster seine eigene Toolbox. Komplizierte Datenbankstrukturen passen zwar in ein Fenster, sind dann aber oft nicht komplett sichtbar. Hat man keinen Großbildschirm, muß man vertikal oder horizontal scrollen (vgl. Bild 1). Aus diesem Grund fände ich persönlich eine einzige Toolbox günstiger, die für alle Fenster gilt und auf Wunsch auch vom Datenbankfenster überdeckt werden darf.
Für jede logische Datei (Karteikasten) muß man eine Tabelle anlegen. Dazu ziehen Sie einfach das Tabellensymbol in das entsprechende Fenster. Den Tabelleninhalt sollten Sie sich vorher sehr genau überlegen. Fs gilt nämlich die Grundregel, daß die Feldfolge in der Tabelle auch Eingabereihenfolge bei der Bearbeitung ist, egal wo die Felder in der Maske plaziert sind. Dieser Grundsatz läßt sich zwar später mit einer Sortierfunktion durchbrechen, aber er hat auch seine Vorteile. Oft folgen optimal gestaltete Maskenbilder in ihrer Feldfolge (von links oben nach rechts unten) nicht der Reihenfolge, die bei Eingabe von Vorlagen wünschenswert ist. Die Kunden-Nummer einer Adressmaske kann ggf. erst nach vollständiger Eingabe der Adresse gebildet werden, dennoch möchte man sie ganz oben stehen haben.
Zur Anlage eines Feldes ziehen Sie das Feldsymbol in die Tabelle. Ktierauf öffnet sich ein Feldfenster (vgl. Bild 2), in dem Datentyp, Attribute und eventuell Formatangaben zu definieren sind. Flf Datentypen stehen zur Verfügung, von Text bis Blob. Der Typ »externe Datei« ist nötig, falls Sie Dateinamen (mit voller Pfadangabe) in die Maske übernehmen wollen. Für diesen Fall sind bestimmte Dateiendungen (.gern, .img, .sam, .) vorgeschrieben. Der Typ »Grafik« ist für das feste Ein binden von Bildern vorgesehen. Interessant ist der Typ »Blob«. Er dient zur festen Einbindung von Bit-, Wort- oder Langwort-Folgen, wie sie z.B. für Sprache oder Musik nötig sind. Und noch ein Datentyp ist außergewöhnlich: »DB-Adresse«. Zur Zeit wird er nur intern für das sequentielle Sortieren benutzt, das muß aber nicht so bleiben.
Bei den Attributen fällt »Ausgabefeld« auf. Solche Felder sind für die Eingabe gesperrt, falls sie nämlich intern errechnete Daten aufnehmen sollen, die für das Editieren zu sperren sind. Das Attribut »in Wertetabelle einfügen« bedeutet, daß eine Eingabe in so ein Feld automatisch auch in das verbundene Feld einer anderen Tabelle kommt. Primärschlüssel dürfen in einer Datei genau einmal Vorkommen, um Datensätze eindeutig zu definieren. Eine Postleitzahl darf in einer PLZ-Tabelle Primärschlüssel sein, nie aber in einer Adress-Tabelle. »Eindeutig« ist ein Analogon zu »Primärschlüssel«, mit dem Unterschied, daß sich Datensätze darüber nicht eindeutig definieren lassen. Mittels »Format« ordnet man Feldern bestimmte Ein/Ausgabeformate zu, etwa DD.MM.YY, DD.Month.YYYY, 99.9999,00, Aa...a, .* 0,00 usw. Ein besonderer Index ist der Multi-Index, in der Toolbox als Schlüsselpaar dargestellt. Mit ihm stellen Sie zwischen Tabellen Verbindungen her, die aus Bestandteilen mehrerer Felder bestehen. Die Definition erfolgt in einer eigenen Dialogbox. Den Tabellen dürfen eigene Sinnbilder zugeordnet sein, den Feldern unterschiedliche Schriftarten, -attribute und -großen. Außerdem lassen sich Dokumentgrößen frei variieren und Zugriffsrechte nach Benutzern auf Tabellen bzw. Felder festlegen.
Nach dem Anlegen aller erforderlichen Tabellen (logischen Dateien bzw. Karteikästen) müssen Sie die Verbindungen herstellen. Auch hierfür gibt es eine Dialogbox, in der u.a. festzulegen ist, ob, wie und wann beim Löschen oder Ändern Datensätze verbundener Tabellen mitbetroffen sein sollen.
Der individuellen Maskengestaltung (vgl. Bild 3) sind Tür und Tor geöffnet. Sie kann Boxen, Muster und Kommentare enthalten. Die Felder dürfen unterstrichen, umrahmt, als Checkbox, Radio-Button oder PopUp-Listbox definiert sein. Ein umrahmtes Feld kann auch mehrzeilig sein, mit automatischem Wortumbruch. Für Felder mit viel Inhalt lassen sich sogar horizontale oder vertikale Schieber definieren. Für eine Tabelle darf es verschiedene Masken geben, wobei Sie sogar die Feldnamen durch neue ersetzen dürfen.
Sollten Sie in bestimmten Feldern den Inhalt der vorhergehenden Eingabe beibehalten wollen, ist auch das möglich. Sie dürfen die senkrechte und waagerechte Feld-größe angeben, oder die Objektgröße von Bildrahmen.
Der absolute Clou sind aber die Aktionsknöpfe. Hierzu dient das OK-Sinnbild der Toolbox. Der Knopf wird mit der Maus auf die vermutete Größe gezogen, anschließend erscheint eine Dialogbox (vgl. Bild 4), in der alle notwendigen Definitionen einzutragen sind. Text erhält die Knopfbezeichnung, Parameter die auszuführende Aktion. Diese darf auch in einer Prozeßdatei beschrieben sein. Die zugehörige Funktion wird mit einer Pop Up- Listbox eingestellt. Vorgesehen sind 26 Einzelfunktionen, von Einfügen bis Verzweigen. Diese Knopf-Funktion ist wirklich überzeugend. Bei der Größeneinstellung von Rahmen und Knöpfen wünschte ich mir, daß ein nachträgliches Ändern mit der Maus möglich wäre, vergleichbar ähnlichen Routinen in Zeichenprogrammen. Statt dessen muß man bisher solche Änderungen in Form neuer Absoluteingaben für Höhe und Breite bewerkstelligen. Das ist etwas lästig.
Der Reorganizer
Datenbanken, in die häufig Datensätze neu eingegeben, geändert oder gelöscht werden, sehen intern nach kurzer Zeit wie ein Schweizer Käse aus. Wo einmal Datensätze waren, sind Löcher. Im Datenbank-Info des Managers ist eine Eintragung, die die Größe solcher Löcher beschreibt. Spätestens wenn diese Löcher auf ca. 20% der Datenbankgröße angewachsen sind, sollte man eine Reorganisation vornehmen. Es empfiehlt sich, daß auf dem Massenspeicher, der die Datenbank enthält, wenigstens soviel KByte freier Speicher vorhanden sind, wie Daten- und Index-Datei belegen. Außerdem sollte der Cache groß genug gewählt sein, mindestens so groß wie beim Datenbankstart empfohlen. Die Normal-Reorganisation ist das »Daten-Datei packen«. Dabei werden alle Löcher entfernt und die Indexdatei völlig neu aufgebaut. Eine Reorganisation über »Flags zurücksetzen« empfiehlt sich nur, wenn man keine Löcher beseitigen will und sicher ist, daß vorhandene Daten nicht beschädigt sind. Dafür ist sie wesentlich schneller.
Wurde mit dem Designer nachträglich ein vorhandenes Feld zum Schlüssel gemacht, ist ebenfalls ein Reorganisieren nötig. Jetzt reicht aber »Index-Datei aufbauen«, was ebenfalls sehr schnell geht. Schließlich dürfen Daten nachträglich verschlüsselt werden, um sie vor unberechtigtem Zugriff (etwa mit einem Diskmonitor) zu schützen.
Die Reorganisationszeit hängt stark vom Datentyp der Schlüsselfelder, dem vorhandenen Cache, der Zugriffsgeschwindigkeit Ihrer Festplatte und deren Füllgrad ab, insbesondere beim Packen und Verschlüsseln. Viele und lange Text-Schlüssel kosten relativ viel Zeit, ebenso ein zu kleiner Cache. Wer mit großen Datenbanken arbeitet, sollte sich eine Festplatte mit möglichst kurzen mittleren Zugriffszeiten zulegen, es sei denn, für die Reorganisation stehen lange Pausen zur Verfügung.
Manager, Designer und Reorganizer sind ausgereifte Programme für den professionellen Einsatz. Die Güte der Datenbankanwendung hängt natürlich vom Programmierer ab. Der Designer erlaubt durch seine Funktionalität auf jeden Fall professionelle Anwendungen. Das neue Phoenix läßt kaum Wünsche offen. Der Preis von 448 Mark ist für ein Produkt dieser Güte absolut gerechtfertigt. (wk)
Application Systems Heidelberg, Postfach 102646, Englerstraße 3. D-6900 Heidelberg 1
Literaturhinweise
Datenbank-Konzepte, M Gillenson, SYBEX-Verlag 1990/91, ISBN 3-88745-789-7
Gut bei allem ist die Ordnung. Datenbank-Planung und Realisierung, Hans Körner, TOS 3-5/91
Phoenix, Der Schnelleinstieg. P. Geelhaar, Data-BeckerVerlag 1991, ISBN 3-89011-782-1
Vm Anfänger zum GEM-Profi, D.&J.Geiß, Hüthig Verlag 1992, ISBN 3-7785-2049-0
Ein endbenutzerorientiertes Datenbanksystem auf der grafischen Benutzeroberfläche GEM, Diplomarbeit D. Geiß, Technische Hochschule Karlsruhe, 1987 Eine Datenbankprogrammierschmttstelle für die Benutzeroberfläche GEM, Diplomarbeit J. Geiß. Technische Hochschule Karlsruhe. 1987
WERTUNG
Name: Phoenix
Preis: 448 Mark, Update zu V1.0 100 Mark, Update zu V1.5 50 Mark
Hersteller: DMC
Stärken: Programmierbar □ universelles Datenformat □ Oberfläche □ Multitasking
Fazit: Für große Datenbankanwendungen und im professionellen Bereich zu empfehlen.
Hans Körner