Das ATOS-Magazin 2/99
ATOS Programmierpraxis
Moderne Zeiten
Wie man sieht, lasse sich die Attribute aus dem ER-Diagramm 1:1 in diese Listen übertragen. Die Informationen, die über die Relationen ausgedrückt werden (in diesem Fall also, welche Spieler bei welchen Vereinen unter Vertrag stehen), müssen aber natürlich ebenfalls irgendwo gesichert werden.
Eine unersetzliche Hilfe ist dabei die Möglichkeit, Verweise auf Objekte sichern zu können. Als GFA-Programmierer kennen Sie Verweise von der Übergabe von Parametern an Unterprogramme. Dort gibt es nämlich die Möglichkeit, Parameter als VAR-Parameter zu deklarieren. Bei so deklarierten Parametern wird der Paramter für das Unterprogramm nicht kopiert, sondern es wird ein Verweis auf ihn übergeben. Wenn aus dem Unterprogramm heraus dann auf den Parameter zugegriffen wird, geht GFA-Basic zunächst diesem Verweis nach, landet dann an der Stelle, an der das Original des Eingabeparamters liegt und greift auf diesen direkt zu. Bei Schreibzugriffen durch das Unterprogramm hat das dann natürlich zur Folge, daß nach Verlassen des Unterprogrammes im Hauptprogramm der Wert des Paramters dem veränderten Wert entpricht, während bei der Kopie eines nicht-VAR-Parameters vom Unterprogramm ja nur diese Kopie verändert wurde, das Original also unverändert blieb.
Dynamische Speicherverwaltungen, wie man sie bei der Realisierung von Objektspeichern benötigt, geben überlicherweise ebenfalls stets Verweise auf die gespeicherten Objektdaten zurück. Auf diese Weise funktioniert auch die Zusammenarbeit mit der OT/OB-Lib. Nachdem man der OT/OB-Lib beschrieben hat, wie Speicherobjekte eines bestimmten Typs aufgebaut sind, kann man durch die Bibliothek solche Speicherobjekte anlegen lassen und erhält dabei jeweils einen Verweis auf das angelegt Objekt, den man sich merken muß. Möchte man auf das Objekt zugreifen und Daten daraus lesen oder darin sichern, ist dieser Verweis auf das Objekt wieder anzugeben. Objekte werden demnach stets über Verweise identifiziert.
Die Verweise - bei der OT/OB-Lib handelt es sich dabei um einfache Fließkommazahlen, deren Bedeutungen allerdings nur der Bibliothek bekannt sind - lassen sich nun aber natürlich auch kopieren. Dies macht man sich zunutze, um die Informationen aus den Relationen zu sichern.
Hier noch einmal die beispielhafte Spielerverträge-Relation von oben:
| Verein \ Spieler | Matthäus | Klinsmann | Kahn |
| Dortmund | |||
| Stuttgart | X | ||
| München | X | X |
Die Speicher für Spieler- und Vereinsdaten wurden ja bereits entworfen, folglich fehlt nur noch ein Speicher, der aufnimmt, welche Kreuzchen in der obigen Tabelle gesetzt sind. Jedes Kreuzchen in der Tabelle steht dabei für einen Spielervertrag. Es bietet sich daher an, auch ein Speichersystem zur Aufnahme der Spielerverträge zu entwerfen:
Dabei lassen sich nun sogar noch weitere Attribute zu jedem Element des Relationsspeichers - also zu jedem Spielervertrag - angeben, beispielsweise die Laufzeit des Vertrages oder das vereinbarte Gehalt.
Im ER-Diagramm stellt man dies überlicherweise wie in folgender Abbildung gezeigt dar:
Diese Art, den Relationsspeicher zu realisieren, hat jedoch auch Nachteile. Will man, ausgehend von einem Verein, eine Liste seiner Spieler ausgeben, müsste man die Liste aller Verträge nach Verträgen durchsuchen, die auf diesen Verein verweisen. Will man umgekehrt von einem Spieler auf seinen Verein schließen, muß man ebenfalls suchen.
Hier hat man zwar die Möglichkeit, die Spielerverträge sortiert (oder in anderer, das Suchen erleichternder Weise strukturiert) abzulegen, es gibt aber auch Möglichkeiten, das Suchen gänzlich zu vermeiden.