Datenbankdesign in der Praxis

Wer in der Praxis ein Datenbankdesign modellieren und erstellen muss, hat es nicht einfach: Die Anwender erklären ihre Probleme und Vorstellungen oft in einer Sprache, die der Datenbankentwickler nur schwer versteht.

Die Überlegungen und Wünsche der Anwender kann er in der Regel nur zu einem geringen Bruchteil nachvollziehen. Der Anwender kann es einfach nicht besser: Das Denken in Datenstrukturen, die Bedeutung der Konzeptionsphase für das Einrichten einer Datenbank sowie Sicherheits- und Performance-Überlegungen der Datenbankentwickler sind ihm fremd.

Die Voraussetzung für die Erstellung eines Datenbankkonzepts ist, die Bereitschaft der Anwender und der Datenbankentwickler, die im Anwendungsbereich auftretenden Datenstrukturen detailliert, vollständig und fehlerlos zusammenzustellen.

Der Datenbankentwickler muss dabei zeigen, dass er zuhören kann, dass er sich in fremde Fachgebiete einarbeiten kann und will, dass er seine eigenen Überlegungen ständig revidieren können muss, dass er ein geduldiger und geschickter Fragesteller ist und jegliche Arroganz beiseite lässt.

Obwohl es kaum einem Anwender schnell genug geht und fast alles immer sofort fertig sein soll, muss das Datenbankdesign systematisch aufgebaut werden. Wer einfach mit einer Tabelle anfängt und hofft, dass sich der Rest durch Hinzufügen weiterer Tabellen schon lösen wird, baut sein Schloss auf Sand:

„Laufende Re-Designs, der Kampf mit den lästigen Folgen von Änderungsanomalien und ein weit schlimmerer Zeitverzug als bei einem ordnungsgemäßen Vorgehen sind die Folge!“

Checkliste für ein Datenbankdesign in der Praxis

Folgende Checkliste hat sich für ein Datenbankdesign in der Praxis bewährt und sollte eingehalten werden:

  1. Einarbeitung in den Fachbereich
  2. Entwurf einer Datenstruktur
  3. Visualisierung der Datenstruktur
  4. Besprechung der Datenstruktur mit den künftigen Fachanwendern
  5. Falls die Besprechung zu Änderungen führt: Zurück zu Schritt Nr. 1 oder 2. Die Datenstruktur muss neu konzipiert werden.
  6. Überführung in die Normalform und Entwurf der einzelnen Relationen
  7. Schreibtischtest:
    1. Kann das Problem des Anwenders so gelöst werden?
    2. Treten Änderungsanomalien auf?
    3. Sind Weiterentwicklungen möglich?
    4. Manche Änderungsanomalien kann man in Kauf nehmen. Dabei muss aber ganz sicher sein, dass der Anwender mitmacht und die Konsequenzen versteht. Falls der Schreibtischtest Fehler oder Probleme aufzeigte, müssen die ersten Schritte wiederholt werden.
  8. Realisierung: Hierbei empfiehlt es sich, zuerst mit Hilfe der SQL-Kommandos die Relationen einzurichten. Das erleichtert Änderungen, ggfls. das Erstellen von Fehlermeldungen an den Hersteller eines Datenbanksystems und den Export (die Portierung) einer Software auf andere Rechner.
  9. Praktischer Test: Alle SQL-Kommandos auf logische Richtigkeit prüfen und die konkrete Datenmodellierung bzw. -optimierung einleiten.

Weiterführende Artikel

Autor: Markus
4 Bewertungen 1 Stern2 Sterne3 Sterne4 Sterne5 Sterne
Loading...
0