MetaDataViewer (MDV)

Designentscheidungen

werden oft in einem Spannungsverhältnis getroffen. Einerseits strebt man einen möglichst geringen Entwicklungaufwand an, andererseits möchte man hohen Nutzen erreichen. Oder wie es Kent Beck in seinem Buch "extreme Programming explained" formuliert, es gibt vier Variablen:

Für drei dieser Variablen (oder Anforderungen) ist die Gewichtung frei wählbar, die vierte ist dann eine abgeleitete Größe. Der MetaDataViewer ist ein schlankes Programm, sein Entwicklungsaufwand liegt im Bereich von Mannwochen. Sehen Sie die im Folgenden erläuterten Entscheidungen auch in diesem Licht.

Datenquelle für das DB-Schema sind ausschließlich (SQL-)Dateien.
Das Auslesen der Systemtabellen einer laufenden Datenbank setzt eine aktive, komplexe Systemlandschaft voraus. Die Spezifika des RDBMS selbst und der Connectivity zum DB-Server müssen Berücksichtigung finden. Jede zusätzliche Version einer lebenden Datenbank ist teuer. Und: Der Zugriff auf eine laufende Datenbank bringt das Risiko einer Beeinträchtigung der Produktion mit sich. Der Zugriff allein auf Testdatenbanken würde die Möglichkeiten zur zeitnahen Qualitätssicherung beschränken.
Weitaus genügsamer ist der Zugriff auf Dateien. Einen Mehraufwand für lexikalische und semantische Textanalyse nehme ich dafür in Kauf.
HTML als Ausgabeformat stellt minimale Anforderungen an die Ausstattung des Betrachters.
Jeder beliebige Browser ist ausreichend. Im Intranet reicht das Dateisystem, ein Webserver ist nicht erforderlich. Ein in sich geschlossener Satz von Dateien ist leicht transportierbar.
Die HTML-Dateien werden statisch erstellt.
Bei einer Datenbank in nichttrivialer Größe wäre eine dynamische Erstellung nicht schnell genug, um dem Benutzer zufriedenstellende Antwortzeiten zu bieten. Interferenzen zum produktiven Betrieb werden so sicher vermieden.
Ein reiner Lesezugriff bedeutet hohe Sicherheit für die Datenbank.
Die Einfachheit und Klarheit des Tools MDV wäre dahin, würde es mit vielen anderen um das Erzeugen und Ausführen von DDL- und DML-Anweisungen konkurrieren.
Tagesaktualität ist ausreichend.
Im nächtlichen Batch wird ein Schema der Datenbank erstellt und anschließend die Hypertext-Generierung angestoßen. Natürlich ist auch ein Stundenzyklus auf Testdatenbanken möglich, scheint mir aber nicht sehr sinnvoll zu sein.
Mehrteilige Hierarchien werden auf mehrere Seiten verteilt.
Andernfalls wäre die Einzelseite überladen. Es ist für mich in der Regel nicht sinnvoll, mehr Informationen in eine HTML-Seite zu packen, als auf eine Bildschirmseite paßt.
Auf die grafische Darstellung der Abhängigkeiten wird verzichtet.
Bei Datenbanken nennenswerter Größe wird der Maßstab dieser Grafiken entweder sehr klein oder der Bildausschnitt deckt nur einen winzigen Bereich ab. Beides rechfertigt nicht den Aufwand für die Generierung von Grafiken, in jedem Fall nicht bei einem so jungen Programm.
Stored Procedures sind keine Black Boxes.
Die Universalität der Textanalyse nutzend, wird der Quellcode der Prozeduren komplett ausgewertet. Alle Beziehungen der Typen ruft-auf / wird-aufgerufen sowie das Ansprechen von Tabellen oder Views in lesender oder schreibender Weise werden hoch differenziert dargestellt.
Nie betretene Code-Zweige werden nicht erkannt.
Der Aufwand wäre unverhältnismäßig hoch und das Ergebnis wäre trotzdem nicht 100%ig.
Der vollständige SQL-Code wird (auf separaten Seiten) dargestellt.
Eine Forderung von Entwicklerseite, der ich leicht nachkommen konnte. Copy & Paste erhöhen die Produktivität.
Datenbankobjekte werden durch ihre Namen identifiziert.
Dieser Ansatz besticht durch seine Einfachheit und hat sich in der Praxis bewährt.
Andere Datenquellen sind leicht integrierbar.
Dies reicht vom Anwendungs-Quellcode in diversen Sprachen bis zu strings-Extrakten aus Binaries. Filter zum Entfernen von Kommentaren sind leicht ergänzbar.
Eigentümernamen werden nicht berücksichtigt bei der Unterscheidung der DB-Objekte.
In den meisten Fällen ist dies keine wesentliche Einschränkung. Spätere Versionen sollen sie dennoch überwinden.
Die Sicht ist auf genau eine Datenbank begrenzt.
Spätere Versionen sollen diese Beschränkung überwinden. Es sollen Verweise sowohl auf Datenbanken auf dem gleichen Server als auch auf solche auf anderen Servern erkannt und mittels Hyperlinks auf Nachbarverzeichnisse abgebildet werden.
Implementationssprache ist Perl.
Dies bringt den Vorteil der Plattformunabhängigkeit bei kurzen Entwicklungszyklen. Das Laufzeitverhalten ist gut und bezüglich regulärer Ausdrücke sogar sehr gut.

[ Sitemap | MetaDataViewer | MDV-Glossar | DemoDB ]

Haben sie Fragen oder Anmerkungen? Schreiben Sie mir: technik(at)tarohloff.de
Autor: Thomas A. Rohloff, 28.11.2000, aktualisiert am 14.10.2006