Während die bisherigen Aufgaben weitgehend der Phase der Systemplanung zugeordnet waren, handelt es sich bei den folgenden um solche, die je nach Ansicht und Vorgehensweise bereits der Phase der Detailorganisation zugewiesen werden können. Es geht dabei im wesentlichen um Punkte die die Designarbeit vervollständigen und somit Voraussetzung für die nachfolgende Phase der Programmierung sind.

22. Ergänzung des Datenbankdesigns.

Zu folgenden Punkten sind hier Festlegungen zu treffen:

- Welche physischen Datenstrukturen werden endgültig implementiert?

- Welche logischen Datenstrukturen werden benötigt?

- Beschreibung des Inhalts der Datenstrukturen.

- Welche Pointer werden erforderlich?

- Welche Datenbankorganisationsform wird gewählt?

- Welche Zugriffsform ist am zweckmäßigsten?

- Welche Zugriffsregeln sind anzuwenden?

- Welche Schlüsselfelder und Sortierkriterien werden endgültig implementiert?

In der konkreten Arbeit des Datenbankadministrators ist diese Liste möglicherweise noch um den einen oder anderen Punkt zu ergänzen. Prinzipiell geht es jedoch darum, daß die Designarbeit soweit abgeschlossen wird, daß daraus dann in der Folge die Datenbankbeschreibung mit der Jeweils zur Verfügung stehenden Datenbankbeschreibungssprache vorgenommen werden kann.

23. Beachtung von Designkriterien.

Wie bereits beim Grobdesign gibt es auch hier einige Kriterien, die bei den Festlegungen zum Detaildesign berücksichtigt werden müssen. Teilweise handelt es sieh um solche, die bereits erläutert wurden, wie z. B.

- sachlogische Zusammengehörigkeit der Daten innerhalb einer Datenstruktur

- Benötigte Datenstrukturen pro Anwendungsmodul bzw.: pro Transaktion - Benutzungshäufigkeit für Datenstrukturen.

Die nochmalige Heranziehung dieser Punkte ist deshalb erforderlich, weil aus mancherlei Gründen und Einflußfaktoren wie

- Forderungen hinsichtlich der Antwortzeit

- Ergebnisse der Betriebsartenplanung

- Integration zu bestehenden Anwendungen und Datenbanken

Änderungen am bisherigen Design notwendig wurden. Durch die weitere Überprüfung mit diesen Kriterien soll insbesondere die Richtigkeit des Designs noch mal abgesichert werden. Der Datenbankadministrator sollte deshalb diese Punkte zusammen mit dem Projektleiter der Anwendung sorgfältig untersuchen, um somit die Notwendigkeit von Änderungen am Design während der Programmierung und/oder Einführung soweit wie möglich zu vermeiden.

24. Designumformung in Datenbankparameter.

Je nach dem wie weit nun die Arbeiten am Design abgeschossen sind kann jetzt an eine Übernahme der Ergebnisse in Form von Datenbankparametern gedacht werden. Zur Verfügung steht dazu die jeweilige Datenbankbeschreibungssprache.Mit ihr werden unter anderem folgende Punkte beschrieben:

- physische Struktur des Datenbanksatzes.

- logische Struktur des Datenbanksatzes

- Speicherungsform

- Zugriffsform

- Größe der Datenstrukturen

- Speichermedium

- Puffergröße

- Blockgröße

- Randomizing Module

- Schlüsselfelder

- Sortierkriterien

- logische Pointer

Durch diese und andere Angaben mehr wird somit die Existenz der Datenbank außerhalb der jeweiligen Anwendungsprogramme beschrieben. In Abhängigkeit davon, welches Datenbanksystem eingesetzt ist, wird diese Beschreibung entweder als Teil der Datenbank selbst oder einer dafür vorgesehenen Bibliothek geführt, Die Datenbankbeschreibungssprache ist ausschließliches Instrument des Datenbankadministrators.

25. Zustimmung zu logischen Verknüpfungen.

Logische Verknüpfungen liegen immer dann vor, wenn sich ein definierter Datenbanksatz aus zwei oder mehr physischen Datenstrukturen zusammensetzt, die in zwei oder mehr physischen Datenbanken vorzufinden sind. Damit ist auch sofort das Problem ersichtlich, denn diese Datenstrukturen müssen aufeinander Bezug nehmen, sie müssen trotz physischer Gedrängtheit aufeinander verweisen. Verweise dieser Art werden durch Pointer realisiert und müssen mittels der Datenbankbeschreibungssprache erklärt werden. Würden im den Datenbanken keine Veränderungen vorgenommen, wäre daß eine einmalige und relativ harmlose Angelegenheit. Da dies eine mehr theoretische Situation ist, muß man davon ausgehen, daß solche Pointer durch das Datenbanksystem laufend auf den neuesten Stand gebracht werden müssen. Hinzu kommt noch die Problematik bei erforderlichen Reorganisationsläufern. Es ist in solchen Fällen nicht möglich, daß man nur eine Datenbank reorganisiert. Würde man so verfahren, wären die Pointerverbindungen mit Sicherheit nicht mehr zu gebrauchen. Sie müssen deshalb in den Datenbanken, die mit der reorganisierten logisch verknüpft sind auf den nunmehr gültigen Stand geändert werden.