Phoenix 5.0 in der Praxis: Aufbau einer Datenbankstruktur

In der mit dieser Ausgabe startenden Artikelreihe möchten wir Sie Schritt für Schritt in die Funktionen und Bedienung der Phoenix Datenbank 5.0 von Application Systems Heidelberg einführen.

Für diese Artikelreihe ist, aufgeteilt in drei Teile, die Erstellung einer „einfachen" Datenbankstruktur, die Gestaltung von Reports und im abschließenden Teil eine Übersicht in die programmierbaren Rechenfunktionen geplant. Eventuell werden wir auch einen kleinen Exkurs nach SQL unternehmen.

Erste Schritte

Die erste Arbeit, die bei der Erstellung einer Datenbank anfällt, wird nicht am Computer vollzogen, sondern auf Papier am Schreibtisch.

Zuerst muß man sich darüber Gedanken machen,- was für Funktionen die Datenbank übernehmen soll. In unserem Fall wollen wir eine Verwaltung von Fußballvereinen erstellen, in der einzelne Vereine mit den dazugehörigen Spielern, Managern und Trainern erfaßt werden sollen. Außerdem soll durch das Eintragen von Punkten, erzielten und „kassierten" Toren eine Tabelle in der richtigen Sortierreihenfolge, gleichbedeutend mit den korrekten Tabellenplätzen, erzeugt werden.

Ich selbst bin kein allzu großer Fußballfan und andere Leser, die ebenfalls nicht fußballbegeistert sind, mögen mir unser Beispiel verzeihen, aber diese Datenbank bietet gute Erklärungsmöglichkeiten, ohne überdimensioniert zu sein. Nachdem wir das Ziel definiert haben, ist nun die eigentliche Struktur zu konkretisieren. Welche Felder benötige ich, wie sollen diese verknüpft werden. Um später beim Erfassen der Daten unnötigen Ärger zu vermeiden, sollte man sehr gründlich planen und testen. Eine mit Daten gefüllte Datenbank nachträglich umzubauen ist in der Regel mit großen Schwierigkeiten und ggf. Datenverlusten verbunden.
Um nicht in blanker Theorie unterzugehen, werden wir unser Beispiel direkt in Phoenix umsetzen, wobei wir die Planung als gegeben voraussetzen.

Tabellen generieren

Starten Sie den Designer entweder direkt oder aus dem Manager im Menüpunkt 'Optionen'. Legen Sie eine neue Datenbank unter 'Datei' an, und ziehen Sie das Tabellensymbol auf die Fensterfläche. Alternativ können Sie auch unter dem betreffenden Menüpunkt alle diese Optionen aufrufen. In dem sich jetzt öffnendem Fenster geben Sie den Tabellennamen ein, in unserem Beispiel wäre das 'Verein'. Jetzt fehlen noch die einzelnen Felder, aus denen sich ein Datensatz zusammensetzt. Auch hier wird mit Drag & Drop gearbeitet, in dem Sie das ab-Icon auf unsere neue Tabelle Verein ziehen. Ein neues Fenster öffnet sich, in dem festgelegt werden muß, welchen Datentyp das Feld später enthalten soll (Abb. 1).

In der Tabelle 'Verein' sollen die Namen des Vereins, des Managers und des Trainers erfaßt werden. Dazu benötigen wir also drei Felder des Typs Text. Die Länge des Feldes bezieht sich auf die Anzahl der Buchstaben. Dabei sollte der Programmierer der Datenbank einen vernünftigen Mittelwert zwischen der erwarteten Länge und der Performance finden, denn der erforderliche Speicherplatz auf der Festplatte und die Geschwindigkeit der Datenbank sind von der Größe desjeweiligen Datenfeldes abhängig.

In unserem Beispiel wird ein Feld 'Vereinsname' als Text mit 30 Zeichen definiert, außerdem bestimmen wir dieses Feld als Primärschlüssel der Tabelle, womit automatisch ein Mußfeld aktiviert wird. Das bedeutet, es wird bei der späteren Eingabe zwingend vorgeschrieben, daß der Vereinsname keinen NULL-Wert (leeres Feld) enthalten darf. Über den Primärschlüssel wird ein Datensatz eindeutig identifiziert.

Jetzt fehlt noch ein Datenfeld 'Managername' mit einem 40 Zeichen umfassenden Textfeld, das wir als Index festlegen. Zusätzlich definieren wir es als eindeutig, damit stellen wir sicher, daß ein Manager nicht mehrfach in der Tabelle eingegeben wird. Nachteilig ist dabei, daß der Datensatz bei der Eingabe nicht gespeichert werden kann, wenn dieses Feld leer bleibt. Der Manager muß also bekannt sein. Aus diesem Grund erstellt Phoenix automatisch ein Mußfeld. Ein Indexfeld wird benötigt, um später eine Beziehung zwischen den Tabellen herzustellen, fernerläuft eine Suchfunktion im betreffenden Indexfeld bedeutend schneller ab, da Teile davon beim Öffnen der Datenbank in den Arbeitsspeicher geladen werden. Wie Sie vielleicht erkannt haben, ist der Primärschlüssel letztendlich ein eindeutiges Indexfeld.

Als letztes fehlt für die Vereinstabelle noch der 'Trainername'. Hier können Sie die Definitionen des Managerfeldes übernehmen. Zu einem Fußballverein gehören natürlich auch Spieler, für die eine gesonderte Tabelle angelegt wird, die wir über eine Beziehung mit dem Verein verknüpfen.

Wie oben beschrieben erstellen Sie eine neue Tabelle mit dem Namen Spieler. Als Verknüpfungsfeld fügen Sie wieder ein Feld 'Vereinsname' ein, diesmal mit dem Unterschied, daß es kein Primärschlüssel wird, sondern nur als Indexfeld, das kein Mußfeld darstellt und nicht eindeutig ist. Ein Verein umfaßt schließlich mehrere Spieler, daraus resultiert also ein mehrfaches Vorkommen des Vereinsnamens in dieser Tabelle, mit der Möglichkeit, Daten von vereinslosen Spielern (daher kein Mußfeld) aufzunehmen.

Eingefügt werden muß jetzt noch der 'Spielername' mit einem Textfeld von 40 Zeichen, auch hier als Index zur schnelleren Suche (nach Spielern wird wohl häufiger gesucht) und abschließend noch ein Textfeld von 10 Zeichen, das mit Position benannt wird und diese beinhalten wird.

Weiter geht es mit einer Tabelle 'Trainer', in der alle Trainernamen verwaltet werden. Fügen Sie hier bitte ein Phmämchlüsselfeld 'Trainername' mit gleicher Länge des Feldes wie in der Vereinstabelle ein, die in der Fachsprache auch oft Masterta belle genannt wird, da hier alle „Fäden" zusammenlaufen. Für den Manager wird ebenfalls eine Tabelle erstellt, die ein Primärschlüsselfeld 'Managername' beinhaltet. Auch hier gilt es, die gleiche Länge wie in der Mastertabelle einzuhalten. Die gleichen Längen sind für die späteren Beziehungen untereinander eminent wichtig!

Abschließend fehlt uns noch eine Tabelle, in der die Tabellenplätze der Vereine erfaßt werden. Diese benennen wir 'Tabelle' und fügen als erstes wieder ein Primärschlüsselfeld 'Vereinsname?' mit identischer Länge ein. Nun folgen die Felder 'Spiele', 'TorePlus', 'ToreMinus', 'ToreDiff' und 'Punkte' mit Zahl als Datentyp (wird in anderen Datenbanken und Programmiersprachen oft als integer bezeichnet). Dieser Typ umfaßt ganze Zahlen im Bereich von -32767 bis 32767. Die unterschiedlichen Datentypen werde ich kurz im letzten Teil unserer Artikelreihe beschreiben.

Alle diese Felder werden als Mußfeld ohne Indexattribute definiert. Eine Ausnahme bietet hier das Feld 'ToreDiff', welches zusätzlich als Ausgabefeld für eine später Berechnung markiert wird.

Ihre Datenbankstruktur sollte jetzt fast der Abb.2 entsprechenden.

Um die Feldlängen angezeigt zu bekommen, müssen Sie unter dem Menüpunkt Sicht auf 'Ausführlich' gehen.

Beziehungen herstellen

Um die erstellten Tabellen zu nutzen, müssen Beziehungen zwischen den Datensätzen aufgebaut werden. Beginnen wir mit der Verknüpfung von 'Verein' und 'Spieler'. Aktivieren Sie das geschlängelte Pfeil-Icon und wählen Sie unter 'Sicht' 'Beziehungen' aus. Ziehen Sie mit gedrückter Maustaste eine Verbindung von 'SpieIer.Vereinsname' nach 'Verein.Vereins name' und lassen dort die Maustaste Ios. In dem sich öffnenden Fenster (Ab b.3) müssen die Regeln für die referentielle Integrität aufgestellt werden.

In unserem Beispiel bietet sich als Regel für 'Löschen' die Option 'NULL' an. Sollen die Daten eines Fußballvereins gelöscht werden, wird durch diese Regel sichergestellt, daß alle Felder mit dem zutreffenden Vereinsnamen in der Spielertabelle auf einen NULL-Wert gesetzt werden. Die restlichen Daten der Spieler bleiben dabei erhalten. Bei der Datenpflege kann es erforderlich sein, einen Vereinsnamen zu ändern. Die Regel 'Kaskadiert' für 'Ändern' bewirkt eine Aktualisierung aller abhängigen Datensätze, d.h. aller Felder, in denen der Primärschiüssel ('Verein.Vereinsname') mit dem Fremdschlüssel ('Spieler.Vereinsname') identisch ist.

Um einen vereinslosen Spieler in die Datenbank aufzunehmen, wird die Regel für 'Löschen' auf 'Keine Regel' gesetzt. 'Verboten' würde keine Eingabe ohne einen zugehörigen übergeordneten Datensatz zulassen. Als Beziehungstyp bietet sich die '1:n' Verbindung an. Mehrere Datensätze in der Spielertabelle werden einem eindeutigen Datensatz in der Vereinstabelle zugewiesen.

Stellen Sie jetzt eine Beziehung von 'Verein.Managername' nach 'Manager.Managername' her. Die Regel für 'Löschen' wird in diesem Fall auf 'Verboten' gesetzt. Befindet sich ein Manager in einem Verein, kann dieser in der Managertabelle nicht versehentlich gelöscht werden.

Die 'Ändern' Regel wird wieder auf 'Kaskadiert' gestellt, um die oben beschriebene Funktionalität zu erhalten. Mit 'Verboten' bei 'Einfügen' verhindern wir eine Eingabe des Namens in der Vereinstabelle, wenn kein identischer Datensatz in der Managertabelle vorhanden ist.

Da immer nur ein Manager einem Verein zugeordnet sein kann (zumindest sollte es so sein), trifft hier die '1:1'Beziehung zu.

Für die Verknüpfung zwischen 'Trainer' und 'Verein' übernehmen Sie bitte die gleichen Einstellungen. Abschließend wird eine Beziehung von 'Tabelle.Vereinsname' nach 'Verein. Vereinsname' hergestellt. Auch hier können Sie fast alle Einstellungen der Manager-Verknüpfung übernehmen. Die Ausnahme bildet in dieser Abhängigkeit die Regel 'Löschen'. Aktivieren Sie bitte stattdessen 'Kaskadiert', um ein automatisches Entfernen eines gelöschten Vereins aus der 'Tabelle' zu garantieren.

Damit sind alle generierten Tabellen in sinnvolle Beziehungen zueinander gebracht worden, und Ihre Datenbankstruktur müßte jetzt endgültig der Abb.2 entsprechen.

Sichern Sie nun Ihre Datenbank unter einem beliebigen Namen. Bei diesem Vorgang werden Sie gefragt, ob Standardeingabemasken erzeugt werden sollen. Diese Frage sollten Sie bejahen. Das Verändern der Standardmasken werde ich im nächsten Teil unserer Artikelreihe vorstellen.

Mit unserer erstellten Datenbank ist es jetzt schon möglich, Daten im Phoenix-Manager einzugeben. Bevor eine Eingabe vorgenommen wird, ist es ratsam, die Datenbank einmal zu reorganisieren. Experimentieren Sie ruhig ein wenig mit den Einstellungen, und üperprüfen Sie die Auswirkungen bei der Dateneingabe, dann erzielen Sie den größten Lernerfolg.

Bei Bedarf können Sie mich unter meiner E-Mail Adresse dstender@lhsystemsas.de erreichen. Ich lasse Ihnen dann gerne die komplette Datenbank (allerdings noch ohne Reports, Abfragen etc.) zukommen. Für weitere Fragen stehe ich Ihnen ebenfalls gerne zur Verfügung.

Anmerkung der Redaktion:
Da sich die ST-Computer & ATARI-Inside als lesernahes Informations-Medium versteht, möchten wir gerne von Ihnen wissen, ob Sie weiterhin Interesse an diversen Praxiskursen haben. Diese haben wir eingeführt, da vielfach darum gebeten wurde, nicht nur Neuheiten des Soft- und Hardwaremarktes, sondern auch praxisgerechte Informationen abzuliefern. Zu welchen Programmen hätten Sie gerne weitere Kurse? Bitte senden Sie uns Ihre Meinung per Fax, Post oder Email an die Redaktionsanschirft (siehe Seite 66).


Detlev Stender
Aus: ST-Computer 06 / 1998, Seite 22

Links

Copyright-Bestimmungen: siehe Über diese Seite