Datenbank statt Aktenschrank

dBASE gilt als der Standard bei Datenbankprogrammen. Mit dBMAN ist ein ernster Konkurrent geboren.

Längst vorbei sind die Zeiten, als man Programme für den ST mit der Lupe suchen mußte. Mittlerweile gibt es sie in allen klassischen PC-Anwendungsbereichen. Von der Textverarbeitung über die Tabellenkalkulation bis zur Dateiverwaltung gibt es Programme für unterschiedlichste Ansprüche und Geldbeutel.

Im Bereich der Dateiverwaltung hat sich in den letzten Jahren auf dem Sektor der Personal Computer ein »Fast-Standard« herausgebildet: dBASE II und die - für 16-Bit- Mikrocomputer - erweiterte Version dBASE. Sie bieten mehr als eine reine Dateiverarbeitung, nämlich eine eigene, einfach zu lernende, aber trotzdem leistungsfähige Programmiersprache. dBMAN bietet ähnliches nun auch auf dem Atari ST.

Datenbanken im Detail

Grundsätzlich läßt sich eine Dateiverwaltung in drei Teilbereiche gliedern:

Um es vorwegzunehmen: Jeder, der mit dBASE II oder III bereits gearbeitet hat, kommt auf Anhieb mit dBMAN zurecht. Alle wesentlichen Kommandos stehen mit gleicher Syntax zur Verfügung. Allerdings sind in dBASE III geschriebene Programme nicht hundertprozentig kompatibel, da einige Befehle fehlen oder durch andere - meist leistungsfähigere - ersetzt wurden. Die Struktur von dBASE wurde allerdings vollständig übernommen, es gibt sogar Kommandos, mit denen sich dBASE-Dateien unter dBMAN einiesen lassen. dBMAN wurde ursprünglich für den IBM-PC als dBASE III-kompatibles Programm entwickelt und dann später auf den Atari ST übertragen. Das ist eine Erklärung dafür, daß einige Merkmale des Atari nicht oder nur unzureichend genutzt werden.

Äußerlich wird die Umsetzung vom IBM bereits beim Start des Programms deutlich. dBMAN läuft unter TOS, unterstützt also keine Fenstertechnik oder Mausbedienung. Der Bildschirm ist in zwei Bereiche aufgeteilt. Die oberen drei Zeilen bilden eine Art Kommando-Ebene, abgeschlossen mit einem Balken, der zur Erinnerung die Belegung der Funktionstasten zeigt. Der Rest dient zur Darstellung von Ausgaben. Leider klappt die Verwaltung dieses geteilten Bildschirms nicht besonders gut: Bereits nach dem ersten Befehl verschwindet ein Teil des Hilfe-Balkens. Leider der, der die Informationen über die Funktionstasten enthält. Er strahlt fortan in sauberem, aber nichtssagendem Weiß. Wenn Ausgaben nicht auf den Bildschirm passen, wird gescrollt, einschließlich des Kommandobereiches, der auch nach Abschluß der Ausgabe nur teilweise wieder hergestellt wird. Es muß ja nicht immer GEM sein, aber ein bißchen »aufgeräumter« könnte es schon auf dem Bildschirm zugehen. Allerdings treten diese Schwächen nicht mehr auf, wenn man ein Programm unter dBMAN ablaufen läßt.

Ein Beispiel: Die Verwaltung von Adressen. Alle Fähigkeiten einer relationalen Datenbank - dieses Prädikat darf dBMAN durchaus für sich in Anspruch nehmen - hier vorzuführen, würde zu weit gehen. Statt dessen wollen wir Ihnen den Umgang mit dBMAN praktisch an einem kleinen Beispiel erläutern.

Unser Problem: Für einen Betrieb soll eine Auftragsverwaltung geschrieben werden. Dabei müssen die Namen und Adressen der Kunden mit ihren Bestellungen erfaßt werden, gleichzeitig brauchen wir das Lieferdatum sowie die Zahlungseingänge.

Wir legen also zunächst eine Datei mit Namen und Adressen an. Das entsprechende Kommando heißt »Create Adressen«. dBMAN fragt nun die Dateistruktur im Dialog ab.

Die einzelnen Felder eines Datensatzes werden später über ihre Feldnamen angesprochen. Es gibt mehrere Typen von Feldern: den Typ Character für Zahlen und Buchstaben, den Typ Numerisch für Zahlen, Datum für Termine und Logisch für Felder.

Ein Datensatz unserer Kundenverwaltung besteht aus elf Feldern mit insgesamt 196 Zeichen. Die Höchstgrenze liegt bei 128 Feldern mit 4000 Zeichen, also in jedem Fall genug. Und noch eine Spezialität sei hier bereits vermerkt. Sollte sich später einmal zeigen, daß die Dateistruktur verändert oder erweitert werden muß, ist das kein Problem, auch wenn bereits Daten erfaßt sind. Diese Eigenschaft hebt dBMAN über viele Dateiverwaltungen hinaus, denn normalerweise muß man in so einem Fall alle Daten neu eingeben. Hier zeigt sich bereits die Flexibilität, die in dem Programm steckt.

Die Dateistruktur ist jetzt fertig und ab sofort kann man Daten eingeben. Das Kommando dazu heißt »Append«. Auf dem Bildschirm erscheint eine einfache Maske, in der man mit den Cursortasten von einem zum anderen Feld gelangen kann. Bei numerischen Feldern sind natürlich nur Zahleneingaben möglich, ähnliches gilt für Felder mit Terminen. Soll ein Datensatz geändert werden, gibt man ein »Edit [Satznummer]« woraufhin wieder die Maske erscheint, diesmal bereits ausgefüllt. Einträge können mit »Delete« zum Löschen markiert und später mit »Pack« entfernt werden.

Alle Kunden werden in der Reihenfolge ihrer Eingabe in der Datei ADRESSEN.DBF gespeichert; dabei verübt dBMAN für interne Zwecke jeweils eine Datensatznummer, über die der Benutzer auf jeden gewünschten Satz zugreifen kann.

Zum Anzeigen der Daten gibt es die Befehle »List« und »Display«, die einen oder mehrere Datensätze auf Bildschirm oder Drucker ausgeben. Diese Kommandos sind sehr flexibel, zum Beispiel kann man mit

	List all for PLZ > = '2000' and PLZ < '3000'

alle Kunden im norddeutschen Raum sehen oder mit

	List all for bezahlt = 0 and Telefon < > ''

eine Liste aller säumigen Kunden, die man telefonisch erreichen kann, erhalten. An diesen Beispielen sieht man auch, wie sehr man sich um eine natürliche Sprachstruktur bemüht hat.

Selbstverständlich lassen sich die Daten auch nach verschiedenen Merkmalen sortieren. Zwei Arten stehen zur Wahl: Mit »Sort on Name to NADRESS« würde man eine vollständige, neu sortierte, Kopie der Datei erzeugen. Das braucht Zeit und Speicherplatz. Zudem würden neu hinzukommende Datensätze natürlich wieder nur angehängt, aber nicht einsortiert. Daher benutzt man statt »SORT« viel häufiger den Befehl »Index on Name to NAME«.

Damit wird eine Indexdatei erzeugt, die nur die Namen der Kunden enthält, und einen Verweis, wo der entsprechende Datensatz in der Datei zu finden ist. Das Arbeiten mit Indexdateien hat mehrere Vorteile:

Dazu genügt es, bei der Eröffnung der Datei zu sagen

	»Use Adressen Index Name, PLZ«.

Bis zu acht solcher Indexdateien können gleichzeitig geöffnet sein. Ein Index kann auch auf mehrere Datenfelder bezogen sein, man könnte mit »Index on Name + PLZ to Namepiz« gleichzeitig nach Postleitzahlen und innerhalb gleicher Postleitzahlen nach Namen sortieren.

Schließlich ist der Zugriff auf die Datei über Index extrem schnell. Auch bei großen Dateien dauert beispielsweise die Suche nach einem bestimmten Namen maximal 1,5 Sekunden.

dBMAN verfügt über eine Vielzahl von weiteren Fähigkeiten:

Alle bisher beschriebenen Befehle reichen bereits aus, um mit der Adreßverwaltung zu arbeiten. Das setzt aber voraus, daß der Benutzer sich mit allen Befehlen auskennt und sie richtig einsetzen kann. Häufig besteht das Problem aber gerade darin, daß eine Sekretärin, ein Buchhalter oder ein Sachbearbeiter, der keinerlei Kenntnisse über Computer hat, mit einer Kundendatenverwaltung arbeiten soll. Hier liegt der entscheidende Vorteil von dBMAN: Mit der integrierten Programmiersprache lassen sich Dateien und Arbeitsblätter einrichten, die optimal an ein Problem angepaßt sind. Das ist eben der Unterschied zwischen einem maßgeschneiderten und einem Konfektionsanzug. Solche Progamme sind leicht zu bedienen, weil sie in der Regel vollständig menügesteuert sind; sie sind auch verhältnismäßig einfach zu schreiben, weil dBMAN bereits sehr leistungsfähige Befehle zur Verfügung stellt.

Die Speisekarte: HMENU() und VMENU()

Die Funktion HMENU() ist ein echter Leckerbissen von dBMAN. Die Menüführung geschieht ähnlich komfortabel, wie man es von Programmen wie Multiplan, Lotus 1-2-3 oder Word kennt. Der Benutzer kann die einzelnen Punkte mit den Cursortasten oder mit den Anfangsbuchstaben anwählen; die entsprechenden Texte werden dann invers dargestellt.

Betätigt man die Return-Taste, ist die Funktion abgeschlossen. Sie liefert die Nummer des gewählten Menüpunktes zurück. Dabei ist HME-NU() äußerst flexibel. Der Programmierer kann entscheiden, welcher Menüpunkt beim Aufruf der Funktion invers markiert sein soll, welchen Abstand die einzelnen Texte voneinander haben. Sogar die automatische Anzeige eines Hilfe-Balkens ist möglich. Und alles das schafft ein einziger Befehl. Das Programmieren wird zum Kinderspiel.

Ähnliche »Super-Kommandos« gibt es auch an anderen Stellen. Von dBASE her bekannt ist der Befehl READ, der im Zusammenspiel mit GET in einer einzigen Anweisung die Verwendung von Bildschirmmasken erlaubt. Die bisherigen Beispiele zeigen aber schon, daß es eine Reihe von Befehlen gibt, die weit über die Leistungsfähigkeit von dBASE hinausgehen.

Natürlich gibt es auch in dBMAN die berühmten kleinen Ärgernisse, die dem Benutzer den Schweiß auf die Stirn und die Zornröte ins Gesicht treiben. dBASE hat allgemein den Ruf, zwar leistungsfähig, aber langsam zu sein. Und dBMAN ist auch in dieser Hinsicht durchaus ebenbürtig. Es sind die Diskettenzugriffe, die die Arbeit mit dem Programm zur Geduldsprobe werden lassen. Unverständlich, warum bei 1 MByte Speicher eine Datei und ein Programm von zusammen 30 KByte Länge nicht im RAM gehalten werden. Kurz, hier hat man zu wenig nachgedacht und schlicht die IBM-Version übernommen.

Mit einer RAM-Disk kann sich die Arbeitsgeschwindigkeit aber durchaus sehen lassen. Das zeigt, daß tatsächlich die Diskettenzugriffe die Bremse sind. Bildschirmausgaben laufen beispielsweise im Vergleich zu dBASE erfreulich schnell, vor allem, wenn man die neuen Befehle BOX oder BAR benutzt.

Vermissen wird man auch einen integrierten Editor. Erst nach längerem Suchen im Handbuch findet man den Hinweis, daß Programme für dBMAN mit jedem normalen Editor geschrieben werden können.

Wo Licht ist, ist auch Schatten

Einen letzten dicken Minuspunkt handelt sich dBMAN durch seine Hilfsprogramme ein. Den Label-Generator hat man vorsichtshalber gleich weggelassen; der Report-Generator ist zwar vorhanden, aber es ist im Test trotz aller Bemühungen nicht gelungen, damit eine brauchbare Ausgabe zu produzieren. Anstelle der Überschrift gab es nur einige Hieroglyphen. Auch dieses Hilfsprogramm scheint ohne Änderungen von der IBM-Version übernommen worden zu sein; nicht einmal die Steuertasten in der Hilfszeile stimmen - oder hat Ihr Atari eine PgUp-Taste ?

Das Konzept von dBMAN ist ausgezeichnet und läßt gegenüber dBASE keine Wünsche offen. Auf einfache Weise maßgeschneiderte Programme zu schreiben, ist zweifellos das stärkste Merkmal von dBMAN. Leistungsfähigkeit und Flexibilität werden von keinem anderen Dateiprogramm für den Atari ST erreicht. Zu wünschen bleibt eine besser auf den Atari zugeschnittene Version, die vielleicht auch noch den deutschen Zeichensatz verarbeitet. Ansonsten kann sich dBMAN mit seinem Preis von zirka 500 Mark auch gegenüber den großen Vorbildern, die das Dreifache kosten, sehen lassen.

(Dietrich Weineck/hb)


Aus: Happy Computer 07 / 1986, Seite 38
Links
Copyright-Bestimmungen: siehe Über diese Seite