In Sekundenbruchteilen findet der Rechner, wozu ein Mensch (ohne CPU, RAM und Harddisk) wohl Tage benötigen würde: z.B. ein einziges Stichwort in einer Riesenansammlung von Daten. Es macht ja auch Sinn, das Verwalten großer Datenbestände, das schnelle Suchen und das gezielte Sortieren jenen zu überlassen, die das mit logischer Präzision hervorragend und blitzschnell erledigen können: unseren „Rechenknechten". Datenbankprogramme gehören deshalb zur Software-Standardausrüstung auf jedem Computer.
Um später einige Zusammenhänge besser verstehen zu können, müssen wir am Anfang etwas weit ausholen (typische Angewohnheit des Autors - Berufskrankheit). Wenn Sie die Grundlagen der Datenbanken beherrschen, können Sie gerne ab der Überschrift „TOPICS, die visuelle Datenbank“ weiterlesen (der Autor ist Ihnen deswegen nicht böse).
Wie eine Karteikarte aussieht, kann man sich leicht vorstellen. Auf jeder Karte existieren ja immer die gleichen Begriffe (in einer Adreßkartei wären das z.B. Name, Vorname, Straße, Ort usw.), hinter denen sich ständig ändernde (variable) Eintragungen (Maier, Müller, Schmidt, Schulz) vorgenommen werden. Eine Datenbank ist nun ein System, das sich dieses Vorbildes bedient. In einem elektronischen Karteikasten werden Informationen strukturiert (sequentiell) abgelegt. Die Ordnungsbegriffe, unter denen Informationen abgelegt (und auch wiedergefunden) werden, nennt man Feldnamen, Feldbezeichner, Kategorien. Diese Begriffe wiederholen sich auf jeder Karteikarte, dahinter stehen die eigentlichen Daten, Eintragungen (Feldinhalte, Merkmale).
Im Computer nimmt man eine gedachte Schablone und legt sie für neue Einträge auf neue, völlig leere (gedachte) Karteikarten. Auf der Schablone (die als Maske bezeichnet wird) stehen die Feldbezeichner. Der Platz für die Feldinhalte ist gewissermaßen aus der Maske „ausgestanzt“. Alle Daten, die auf einer (elektronischen) Karteikarte zusammengehören, nennt man Datensatz.
Eine Datendatei einer relationalen Datenbank wäre vergleichbar mit einem Karteikasten, der alle gleichartigen „Karteikarten“ aufnimmt, z.B. die Adressen eines Kundenstamms. Eine andere Datei könnte nun Datensätze einer anderen Struktur aufnehmen, z.B. irgendwelche Lieferscheine oder Überweisungsbelege. Alle Datei en, die zum geregelten Ablauf des geplanten Arbeitsvorgangs benötigt werden (z.B. Adressen, Liefer- und Preislisten), bilden letztendlich die Datenbank.
Jede dieser Dateien besitzt einen anderen Aufbau (Struktur), die Datensätze sehen also völlig verschieden aus. Trotzdem müssen sich Zusammenhänge zwischen den einzelnen Dateien bilden lassen, wenn beispielsweise eine Rechnung gedruckt werden soll. Diese Zusammenhänge (Relationen genannt) müssen über ein Merkmal hergestellt werden, das in mindestens zwei Dateien existiert und gleich ist. Im aktuellen Beispiel wäre das mit einer Kundennummer für Adreß- und Lieferdatei, mit einer Artikelnummer für Liefer- und Preisliste zu lösen.
Der Vorteil: Name, Straße, Wohnort usw. müssen pro Datenbank nur einmal in die Adreßdatei eingegeben werden. In der Lieferdatei steht nur die Kundennummer, und für den Ausdruck einer Rechnung verzweigt das Programm mit dem Verbindungselement „Kundennummer“ in die Adreßdatei und holt sich von dort die benötigte Anschrift.
In der Struktur der relationalen Datenbank wird dann noch eine sogenannte Indexliste mitgeführt, die die Relationen katalogisiert. Der Verwaltungsaufwand wird demnach umso größer, je mehr Verzweigungen zwischen Dateien aufgebaut werden. Und: Es muß nicht nur eine Verbindung (Verknüpfung) zwischen zwei Dateien bestehen. Relationale Datenbanken sind gewissermaßen die Urform eines Datenbanksystems und deswegen auch heute noch mehrheitlich anzutreffen.
Relationale Datenbanken haben u.a. den Nachteil, daß Informationen nur in endlosen Listen gespeichert werden, wodurch die Übersicht schnell verlorengeht. Assoziative Datenbanken begegnen diesem Nachteil dadurch, daß sich übergeordnete Themenbereiche definieren lassen. Datensätze können dann einem oder mehreren dieser Themen (oder Begriffe) zugeordnet werden, z. B. „männlich“ oder „schiefe Zähne“, wodurch der Datensatz charakterisiert wird. Man grenzt bei der Suche mit möglichst vielen solcher Oberbegriffe den gesuchten Datensatz ein. Dadurch fallen alle Datensätze weg, die diesen Oberbegriffen nicht entsprechen, der gesuchte Satz bleibt übrig. Natürlich kann auch mehr als ein Datensatz übrig bleiben, wenn die Suchthemen (Assoziationen) sehr allgemein gehalten sind.
Es kommt also darauf an, möglichst viele möglichst geschickte Assoziationen herzustellen und schon bei der Planung möglichst viele Themen zur Verfügung zu stellen. Assoziationen wie „Deutscher“, „Deutschland“ oder „Germany“ wären nicht sinnvoll in einer Themenliste, da sie sich sehr ähneln. Die Zahl der Suchbegriffe würde unübersichtlich anwachsen, ohne die gesuchten Daten effektiv auszusieben. Lange Rede kurzer Sinn: Assoziativ heißt, sich durch geschicktes Eingrenzen mit Hilfe von Eigenschaften dem gesuchten Datensatz zu nähern.
Relationale Datenbanken haben mit vielen assoziativen Datenbanken gemeinsam, daß sich die Struktur einer Datenbank nach der Dateneingabe nur unter erheblichem Aufwand ändern läßt. Sie erfordern also sehr sorgfältige Vorausplanung. Es gibt bei Datenbanken also immer ein Ordnungsprinzip, das gleichartige Informationen miteinander verbindet, sie quasi zusammenhält: Indexlisten bei den relationalen, Themenlisten bei den assoziativen. Wenn man es genau nimmt, sind assoziative Datenbankmodelle von den relationalen abgeleitet worden.
Natürlich gibt es bei Datenbanken noch andere Ordnungsmechanismen, die wir hier und heute aber nicht auch noch betrachten müssen. Nur eines sei gesagt: Programmierer sind derzeit dabei, eine Abart aus der objektorientierten Programmierung (OOP) in Datenbankmodelle („OODBMen“) einzubauen. Die Standards für eine objektorientierte Datenbank (OOD) sind derzeit in der Diskussion und in der Springer-Zeitschrift „Offene Systeme“, Heft 2, Mai 1992, ausführlich nachzulesen.
Die Besonderheiten der gewohnten Datenbankprogramme sollen uns später durchaus wiederbegegnen. Bei einem Text gibt es auch ein Ordnungsprinzip, das natürlich mit denen der Datenbank kaum etwas gemeinsam hat. Texte sind meist streng linear, also in einer sturen „Geradeausfolge“ strukturiert. So macht es kaum Sinn, beim Lesen eines Romans ständig zwischen den Seiten hin- und herzublättern. Ähnlich verhält es sich bei einem Lehrbuch: Man beginnt vorne zu lesen und arbeitet sich (hoffentlich) bis zum letzten Kapitel durch. Nichts weicht von der festen Seitenabfolge ab, die Textabfolge ist fest vorgegeben. Ein ablaufender Film ist ebenfalls ein gutes Beispiel für eine streng lineare Folge.
Auch beim Programmablauf (Stapelbetrieb) hat sich lange Zeit das „Perlenschnurverfahren“ gehalten: Immer brav Zeile für Zeile, Befehl für Befehl abarbeiten, und wenn es einmal eine Schleife oder ein GOTO gab, irgendwie kam das Programm zum Absprungpunkt zurück.
Neuerdings weichen einige Arbeitsprinzipien davon ab: Interaktion ist das Stichwort. Ich möchte hier nicht unbedingt in die noch nicht beendete Diskussion um das CeBIT-Schlagwort „Multimedia“ eintreten, aber eines wird sich als Neuheit in den bisherigen Arbeitsablauf von CPU und Software einmischen: die Idee der Interaktion.
Bald wird man nicht mehr gezwungen sein, eine strenge Abfolge einhalten zu müssen. Ähnlich wie man in einem Lehrbuch bekannte Sachverhalte überblättert, steuert man in Lernprogrammen die Lektionen selbst, legt Geschwindigkeit und Abfolge individuell fest.
Eine Vorstufe hierzu ist bei sogenannten Hypertexten zu finden. Ein Hypertext ist nicht mehr so streng aufgebaut, wie man dies von Romanen her kennt. In der Abarbeitung sind Verzweigungen möglich -durchaus vergleichbar mit den Verknüpfungen der Datenbankdateien mit (relationalen) Indexwörtern oder mit (assoziativen) Themenbereichen.
So befinden sich im Hypertext Schlüsselwörter, über die man aus dem laufenden Text an eine völlig andere Stelle springen kann, wo dieses Schlüsselwort erneut vorkommt. Dieses Spiel läßt sich dann so lange wiederholen, bis man an die Ausgangsstelle zurückgekommen ist. Ein anderes Verfahren von Hypertexten legt die Texte wie nach einer Baumstruktur ab. Ausgehend vom Haupttext, kann man über ein Schlüsselwort in immer tiefere Ebenen verzweigen, die z.B. immer weiterführende Erklärungen bereithalten. Das wäre vielleicht eine Vorgehensweise für ein Lexikon in Hypertext.
Nun sind wir auch schon gleich bei einem anderen Ordnungsprinzip, das die Verwaltung einer Festplatte zu eigen hat: dem hierarchischen. Ganz oben steht immer eine Gesamtheit, also die Festplatte selbst (physikalisches Laufwerk), darunter befinden sich die Partitionen (logische Laufwerke), und dann kommen Ordner (Verzeichnisse) mit Unterordnern (2. Ebene) und Unter-Unter-Ordnern ...
Nach den vielen Vorworten (ich bitte um Verständnis) ist es nun an der Zeit, das neue Programm vorzustellen: TOPICS. Wie in assoziativen Datenbanken lassen sich Informationen nach Themenbereichen ordnen, wie in relationalen Datenbanken sind Datensätze innerhalb eines Themenbereichs in Listen geordnet, und wie mit File-Systemen lassen sich mit Topics beliebige Files verwalten. Aber alle diese Daten, Programme, Bilder, Texte, Grafik-Files soll TOPICS verwalten können?
In der Tat ist dieses Programm angetreten, alles unter einen Hut zu bringen und dem Bediener den visuellen Zugriff auf diese Informationen zu gestatten. Verwechseln Sie dies bitte nicht mit dem Begriff „integriertes Paket“, dort sind ja verschiedene Abarbeitungsmechanismen unter ein Dach gebracht worden (Tabelle, Datenbank, Textprogramm, Grafik, Telekommunikation usw.). TOPICS ist viel mehr als ein übergeordneter Verwalter von Daten zu verstehen, also eine Datenbank für wahlfreien Zugriff auf Medien und Dateien, in die sich beliebige andere Programme einbinden lassen. Das muß im folgenden etwas genauer erklärt werden, wobei die anfangs gepflegte Ausführlichkeit (leider) wieder nötig ist (ich hoffe, ich langweile Sie nicht).
Man kann jetzt nicht einfach sagen, TOPICS sei so ähnlich aufgebaut wie „XYZ-Base“ oder funktioniere wie „ABC-DATA“. Um es wirklich vergleichen zu wollen, müßte man Funktionsmechanismen aus vielen verschiedenartigen Programmen heranziehen. Am Anfang des Artikels habe ich ja einige Grundprinzipien vorgestellt, die man nun alle in TOPICS wiederfinden kann.
Zunächst ist TOPICS auf jeden Fall eine Datenbank. Was in einer (relationalen) Datenbank ein Datensatz ist, heißt in Topics ein „Info“. Ein Info macht Aussagen über ein „Objekt“. Beispiel: Wäre das Objekt z.B der Kunde Maier (er möge mir verzeihen), so nimmt das, über ihn angelegte Info, Einträge wie Name, Vorname, Straße usw. auf (das kennen wir ja).
Ein Objekt kann eigentlich alles sein, ein Buch, eine Person, ein Kaufgegenstand oder aber ein File (eines beliebigen Formats) und das Info gibt über einzelne Merkmale (Ausprägungen) dieses Objekts Auskunft. Die einzelnen Angaben eines Infos entsprechen durchaus den Feldern einer Datenbank. Während jedoch in herkömmlichen, relationalen Datenbanken für verschiedene Datensatztypen (z.B. Adresse, Artikel) verschiedene Dateien angelegt werden müssen, kann TOPICS pro Datenbank bis zu 100 Infotypen gleichzeitig verwalten, z.B. „Buch“, „Adresse“, „DTP-File“ (jeweils mit eigener Eingabemaske). Falls das zum Info gehörige Objekt ein File ist, lassen sich der File-Name und ein Programm angeben, mit dem dieses File bearbeitet werden kann. Da dann per Doppelklick auf dieses File zugegriffen werden kann und Files von Topics aus kopiert und verschoben werden können, eignet sich Topics als GEM-Shell. Durch die so gegebene Möglichkeit, andere Programme einzubinden, kann Topics Files beliebigen Formats verwalten (Text-, Grafik-, DTP-, Sound-Files).
Ein weiterer grundlegender Begriff ist „Bereich“. Ein Bereich ist dazu gedacht, verschiedenartige Infos nach thematischen Gesichtspunkten zu ordnen. Bereiche sind in TOPICS durch ein längliches Achteck gekennzeichnet (s. Bild 3). Bereiche spielen ungefähr die gleiche Rolle wie Ordner im Dateiensystem unserer Massenspeicher. So ist eine Datei im TOS-File-System immer jenem Verzeichnis zugeordnet, in das sie kopiert wurde. Genauso wie Ordnern Files zugeordnet sind, sind Bereichen Infos zugeordnet, und genauso, wie Files kopiert und verschoben werden können, können auch Infos per Maus (durch „Drag und Drop“) kopiert und verschoben werden. Zugleich entsprechen Bereiche aber auch den Themenlisten, wie Sie in assoziativen Datenbanken Vorkommen (siehe oben). Deshalb ist es möglich und durchaus gewollt, daß ein Info mehreren Bereichen (Themen) zugeordnet wird. Obwohl ein Info nur ein Mal existiert, gibt es damit Verknüpfungen zu mehreren Bereichen, über die es dann erreichbar ist.
Auskunft über die Inhalte eines Bereiches (ihm zugeordnete Infos) gibt das „Bereichsfenster“. Es kann geöffnet werden und liegt rechts neben dem Bereich. Obwohl dieses Bereichsfenster kein echtes GEM-Fenster ist, sieht es ihm durchaus ähnlich und erlaubt auch fast alle Vorgänge, die in GEM-Fenstern möglich sind: Scrollen, Größe verändern. Öffnen und Schließen. Die Anzahl dieser Beinahe-GEM-Fenster ist nicht beschränkt. Wem es Freude macht, gleich tausend auf den Bildschirm zu zaubern, kann dies gerne tun. Aber einen Unterschied zu GEM gibt es dennoch: Wo auf dem normalen Desktop die Fenster unabhängig voneinander verschoben werden, sind sie in TOPICS abhängig. Das Verschieben eines Fensters zieht alle abhängigen Unter-Fenster mit sich. Dadurch hat jedes Fenster „seinen Platz“, und der Bediener behält durch die Gesamtansicht auch bei hunderten und tausenden von Fenstern noch die Übersicht.
Ähnlich wie es im File-System neben Ordnern (Directories) auch Unter-Ordner (Subdirectories), Unter-Unter-Ordner usw. gibt, kann man in TOPICS Unter- bzw. Teilbereiche anlegen, die dann (weil thematisch abhängig) immer eine Untermenge des übergeordneten Bereiches sein sollen. Insofern verfolgt TOPICS damit ein hierarchisches Prinzip. Auf dem Bildschirm sieht das dann so aus, daß rechts neben den übergeordneten die (hierarchisch) untergeordneten „Teilbereiche“ kommen und so weiter (immer eine Hierarchiestufe tiefer nach rechts), bis nichts mehr kommt.
Die Struktur der Bereiche läßt sich ebenfalls (auch nach Eingabe von Daten) durch einfaches Verschieben der Achtecke mit der Maus sehr schnell und ohne Einschränkungen verändern, wie Topics überhaupt sehr flexibel ist. So können z.B. in Eingabemasken problemlos Felder hinzugefügt bzw. gelöscht werden, auch nachdem bereits Daten eingegeben wurden.
Nach so viel Theorie und Definitionen wäre es sicher interessant, das Arbeitsprinzip von TOPICS anhand eines Beispiels zu erläutern. Betrachten Sie bitte Bild 2. Dort ist die Infobank „Alles“ in Gesamtüberblick wiedergegeben. In dieser Gesamtansicht sind alle Bereiche, aber keine Infos sichtbar. In ihr kann gezoomt werden. Ganz deutlich sind die Bereiche zu erkennen, die sich nach rechts immer mehr verfeinern. Es handelt sich dabei um eine Datenbank, die einfach alles enthält, was an Daten irgendwie gespeichert wurde.
Bild 3 zeigt die Datenbank „Musik“ in der Arbeitsansicht. In dieser Ansicht können Bereiche und Infos angesehen, bearbeitet, angelegt und umgeordnet werden. Ganz links der kräftige Balken mit dem Namen „Privates“ ist quasi der Ausgangspunkt, während sich rechts davon die jeweiligen Untergruppen anordnen. Die Teilbereiche „Videos“, „MCs“, „CDs“ und „LPs“ in der nächsttieferen Hierarchiestufe sind gleichwertig, d.h. sie haben die gleiche Priorität zum übergeordneten Bereich. Es handelt sich in diesem Beispiel ja lediglich um andere Tonträger, die sich üblicherweise in der Möglichkeit, Musik zu speichern, kaum unterscheiden (lediglich in der Art und Weise). Eine Stufe weiter wird die nächste Verfeinerung aufgezeigt, das Trennen in drei verschiedene Musikrichtungen. „Klassik“ könnte man weiter unterteilen in „Orchesterdarbietung“, „Chor“ oder „Oper“ usw. Eigentlich ist dann nur noch mangelnde Phantasie die Grenze für weitere oder anders angeordnete Verfeinerungsstufen.
Gerade bei der 2. Unterstufe mit den jeweiligen Titeln „Klassik“, „Rock“ und „Jazz“ wird eine Besonderheit deutlich: Würde ein Info von „Klassik“ unter „MCs“ in den Breich „Klassik“ unter „LPs“ kopiert werden, dann existieren in beiden Bereichen zwei (nunmehr) völlig unabhängige Infos - halt weil ich diese Musik sowohl als LP als auch als MC besitze. Wenn ich beispielsweise eine Aufnahme von einem Musikvideo auf eine MC überspiele, existiert die Aufnahme ja auch zweimal, auf zwei verschiedenen Medien.
Wenn Sie jedoch ein und dasselbe Info den beiden Bereichen „Rock“ und „Jazz“ zuordnen möchten (weil sich diese Musik nicht genau zuordnen läßt), kann das Info von dem einen in den anderen Bereich dupliziert (statt kopiert) werden (die Hierarchiestufe der Bereiche spielt keine Rolle). Es existiert dann nur ein Mal. Im Grunde ist damit in beiden Bereichen eine „Referenz gelegt“ worden, die beide auf einen einzigen Datensatz zeigen. Wenn nun Einträge in einem Info geändert werden, ändert sich das Info in dem anderen Teilbereich auch - es ist ja nur ein Datensatz vorhanden, der in zwei Teilbereiche „projiziert“ wird.
Früher, als das glorreichste Betriebssystem aller Zeiten (Most-Stuffy-DOS) noch per Kommandozeile gesteuert wurde, mußte man sich alle Befehle nebst Ordnerstrukturen irgendwo aufschreiben, um nicht ständig den meistbenutzten Befehl DIR bemühen zu müssen. Irgendwann in den siebziger Jahren hatte dann jemand die Idee, den Textbildschirm abzuschaffen und Grafik darauf darzustellen. Was daraus wurde, sehen ST-, Mac- und AMIGA-Freunde schon seit fast 10 Jahren auf ihrem Schirm, glücklicherweise zieht die MS-DOS-Welt mit Windows seit 2 Jahren nach.
Auch TOPICS gibt sich mit „Oberflächlichkeiten“ ab, denn laut Werbebrief und Handbuch läßt sich Topics als GEM-Shell zur File-Verwaltung nutzen. Eigentlich macht das Programm überhaupt keinen Unterschied zwischen benutzererstellten Daten (Texte, Bilder, Adressen usw.) und ablauffähigen Programmen. Sie sind als Objekte in Infos sogar völlig gleichwertig. Deshalb ist es möglich, den gesamten Inhalt einer Festplatte oder auch nur Teile davon in einer TOPICS-Infobank zu organisieren und Topics als Shell zu verwenden. Das hat sogar noch die Vorteile, daß Dateien ein beliebig langer Titel zugeordnet werden kann (zusätzlich zu den auf 8 Buchstaben und 3 Erweiterungszeichen begrenzten Dateinamen), und daß ein Programm XYZ in vielen verschiedenen „Ordnern“ eingetragen sein könnte, obwohl es physikalisch doch nur einmal existiert.
Weiterhin würde beispielsweise die Suche nach einem bestimmten Objekt in einem riesigen Massenspeicher stark vereinfacht, denn wie jede Datenbank besitzt TOPICS eine Suchfunktion. So läßt sich eine Volltextsuche sowohl nach diesen umfangreichen Dateibezeichnungen als auch nach den Dateinamen oder auch den -inhalten durchführen. Natürlich kann man die gesamte Infobank oder Teile davon per „Report“ auch zu Papier bringen. Reports lassen sich dazu frei gestalten (s. Bild 6).
Angelehnt an die Vorgabe, eine GEM-ähnliche Shell zu sein, muß TOPICS selbstverständlich per Maus zu bedienen sein. Die Steuerung der Aktionen und Darstellungen läßt sich auf drei Wegen realisieren: 1. Maus und Menüleiste, 2. Maus und Icon-Leiste (siehe Bild 2 unten links) und 3. per Hotkey (Tastaturkürzeln). Man darf natürlich nicht verschweigen, daß zwar alle Menüeinträge auch ein alternatives Tastaturkürzel verstehen, aber in der Icon-Leiste wirklich nur die allerwichtigsten Funktionen für das Auf- und Zuklammen der Bereiche und Bereichsfenster und die Eingabemasken für Bereiche und Infos vorhanden sind.
Es kommt wirklich selten vor, daß ein Autor ein relativ interessantes Programm herausbringt und ebenso viel Sorgfalt auf das Handbuch verwendet. Mit 216 Seiten, gedruckt auf Karton, mit einer relativ großen Schrift, ist das Handbuch sehr erfreulich geworden. Der Bilderdurchsatz ist ausreichend und die Erklärsprache verständlich, wenn auch gelegentlich etwas zu sehr in Fachbegriffen vertieft.
TOPICS wird zu einem Preis von 598,- DM angeboten. Darin inbegriffen ist für Kunden, die TOPICS bis zum 31.12.1992 erwerben, die Garantie auf kostenlose Updates bis zum 30.06.1995! Um ehrlich zu sein: Seit 14.02.1992, dem Tag der erstmaligen Einsendung an die Redaktion, haben mich drei Updates erreicht. Ich habe mir die früheren Versionen deshalb nicht sehr ausführlich betrachtet, aber die jeweils beigefügten Update-Informationen zeigen, daß der Programmautor sehr fleißig ist und mit viel Elan an Verbesserungen und Weiterentwicklungen arbeitet. Insofern ist das ungewöhnliche Update-Angebot sehr zu begrüßen - ein Beispiel übrigens, das in der gesamten Branche Schule machen sollte.
Angesichts der Konkurrenz am ATARI-Markt wäre der Preis für ein neues und neuartiges Datenbankprogramm doch etwas zu hoch gegriffen, doch bei Topics handelt es sich ja nicht nur um ein neues Datenbanksystem. Außerdem kann sich das Programm durch die visuelle Oberfläche und die große Flexibilität (und den damit bei manchen Anwendungen verbundenen Zeitgewinn z.B. gegenüber relationalen Datenbanken) für professionelle Anwender auch sehr schnell bezahlt machen. Es gibt eine Demo-Version, die zum Preis von 25,- DM beim Autor erhältlich ist. Diese Demo schließt ein vollständiges Handbuch mit ein. Beim Kauf einer Vollversion wird der Demo-Preis angerechnet. Im Unterschied zu früheren Demo-Versionen kann man nun auch eigene Datenbanken abspeichern, allerdings nur 40 Bereiche in 3 Ebenen und 500 Datensätze. Als Demo-Datenbank wird u.a. ein Register der Zeitschrift „Spektrum der Wissenschaft“ mitgeliefert (1984 - 1991).
TOPICS läuft auf allen ATARI ST/STE/TT mit mindestens 1 MByte Arbeitsspeicher und allen Bildschirmen (Großbild-, Multisync-Monitore, auch in Farbe). Eine Festplatte wird dringendst empfohlen. Bei 4 MByte Arbeitsspeicher können maximal 5000 Themenbereiche mit 100000 Infos angelegt werden. Pro Info sind bis zu 8 Eingabefelder erlaubt, die jeweils einen beliebig langen Text aufnehmen können.
Am Ende bleibt die Frage, für wen ein solches Programm sinnvoll ist, denn ein Desktop besitzen unsere Computer ohnehin, und Datenbankprogramme gibt es auch nicht gerade wenig auf dem ATARI-Markt.
Die typischen Anwendungsgebiete von Datenbanken (Verwaltung von Adressen, Rechnungen, Aufträgen u.ä) sind auch sicherlich nicht die Hauptaufgabengebiete für Topics. Doch durch die Möglichkeit, verschiedene Informationstypen (u.a. Files beliebigen Formats) gleichzeitig und gemischt zu verwalten, seine große Flexibilität und die visuelle Oberfläche ist Topics überall dort sinnvoll einsetzbar, wo die zu verwaltenden Informationen zu reich strukturiert sind, als daß man diese nach Schema F in eine relationale Datenbank pressen könnte, z.B. zur Literatur- oder Dokumentenverwaltung. Durch die (offene) Schnittstelle zum File-System ist aber auch der Aufbau einer Grafik-, DTP-, ja selbst Sound-Datenbank mit Topics vorstellbar.
TOPICS ist mehr als eine Datenbank, es ist eine Verwaltungsoberfläche, unter deren Fittichen alle Arten von Informationen vorstellbar sind. Durch Verknüpfen von relationalen, assoziativen und hierarchischen Strukturen vereinigt TOPICS alle Arbeitsprinzipien, die derzeit Standard sind. Fast schon an Genialität grenzt es, diese Strukturen quasi in einem Aufwasch zugänglich und bedienbar zu machen. Dabei verläßt das Programm die üblichen Beschränkungen und ist eigentlich nur noch durch die Kapazität des Massenspeichers begrenzt.
DK
Bezugsquelle:
SDS
Software Dirk Sandhörst
Peterskampweg 15
2000 Hamburg 76