Die Diplomarbeit beschäftigt sich thematisch mit der Untersuchung und Darstellung unterschiedlicher Abhängigkeiten der einzelnen Datenbankobjekte. Die Motivation war die Visualisierung dieser ermittelten Abhängigkeiten aus einem Datenbankschema in einer geeigneten Art und Weise. Dies sollte als Softwareanwendung mit der Sprache Java und zunächst primär für das Datenbanksystem Oracle in der Version 11g entwickelt werden.

Eine Analyse der Aufgaben und Funktionen an die Anwendung ergab, dass drei verschiedene Ansichten implementiert werden müssen: die View-Hierarchie, die Triggeraktivitäten und das Entity-Relationship-Diagramm. Die View-Hierarchie beinhaltet alle Views und deren Beziehungen untereinander. Dabei wird zwischen positiven und negativen Abhängigkeiten unterschieden. Potenzielle Triggerrekursionen und -anomalien werden in der Triggeransicht dargestellt. Schließlich werden die einzelnen Fremdschlüsselbeziehungen in dem ER-Diagramm visualisiert.

Eine Evaluation bestehender Werkzeuge im Bereich des Datenbankmanagements ergab, dass nahezu keine Anwendung derartige Funktionalitäten¹ aufweist. Zwar können die meisten Anwendungen die Informationen über die Abhängigkeiten der Views ermitteln und (tabellarisch) anzeigen, aber keine Anwendung bietet eine visuelle und anspruchsvolle Darstellung an. Der SQL Developer bietet eine “Diagramm”-Funktion mit integrierter Anzeige der Viewabhängigkeiten an, jedoch nicht im Kontext der hierarchischen Abhängigkeitsstruktur. Des Weiteren schweigt sich der SQL Developer sowohl über die Details einer View-Abhängigkeit als auch Trigger im Allgemeinen aus.

Zur Ermittlung eines geeigneten SQL Parsers wurden verschiedene Parser miteinander verglichen und auf die Tauglichkeit in Bezug zur Aufgabenstellung hin bewertet. Dabei hat sich herausgestellt, dass ein Großteil der untersuchten Parser Probleme mit verschachtelten Abfragen (Unterabfragen) hat. Da der Parser Sqljep rein tokenbasiert und für eine Integration in Java verfügbar ist, haben wir uns für dessen Verwendung entschieden. Zwar reicht Sqljep einerseits für das reine syntaktische Analysieren (Lesen) von SQL-Anweisungen aus. Spezielle Herstellererweiterungen wie PL/SQL machen jedoch individuelle Anpassungen nötig. Leider gibt es dafür bisher² keine vernünftige und universell einsatzfähige Lösung, die uns bekannt ist. Daher war es in Teilen notwendig, individuelle und meist datenbankherstellerabhängige Workarounds in die Analyse und das Parsen zu integrieren.

Bei der Evaluation eines brauchbaren Graphenframeworks war es unter Anderem von Bedeutung, dass es sich gut in Komponenten der grafischen Swing-Bibliothek von Java integrieren ließ. Die Betrachtung der unterschiedlichen Frameworks, Dokumentationen und Beispiele zeigte, dass einige Frameworks nur eine mäßig gute Dokumentation vorweisen können. Wir stellten fest, dass die Frameworks JUNG und JGraph die für unsere Zwecke nützlichsten Voraussetzungen und Funktionalitäten anbieten. Die Wahl auf JUNG wurde schließlich auf Basis der internen API-Struktur, dem Informationsgehalt vorhandener Dokumentationsquellen und dem Vorhandensein fertiger Layouts getroffen. Alle Frameworks besitzen eine teils breit gefächerte Auswahl an Layoutvarianten. Die kommerziellen Produkte bieten als Mehrwerte in Teilen eine bessere Optik des Graphen verbunden mit leistungsfähigeren Layoutalgorithmen.

Die Analyse der Metadaten konnte in Teilen zügig mit Hilfe des JDBC-Pakets von Java umgesetzt werden. Mittels einem herstellerabhängigen Datenbanktreiber, der die Spezifikationen und Konzepte von JDBC realisiert, werden die Abfragen an das Data Dictionary in einzelnen Methodenaufrufe und Ergebnismengen gekapselt. Allerdings wurde bei der Implementierung des universellen Analysecodes festgestellt, dass der aktuelle Datenbanktreiber³ von Oracle falsche Ergebnisse oder sogar Fehlermeldungen wirft: im konkreten Fall bei der Abfrage der Indexe und Unique-Bedingungen für Tabellen. Aber auch die fehlermeldungsfreien Ergebnisse sind ungenügend, da neben den einfachen Unique-Bedingungen ebenfalls die Primärschlüssel angezeigt werden. Daher wird anstelle der dafür im JDBC-Paket vorgesehen Methoden zum Laden der Indexe und Primärschlüssel eine eigene Anfrage an das Data Dictionary geschrieben.⁴

Nach kleineren Anpassungen für das Auslesen eines Triggerrumpfes in PL/SQL konnte der SQL-Parser Sqljep ohne weitere Probleme in die Anwendung integriert werden. Durch eine tokenbasierte Arbeitsweise kann dieser Parser für jedes Datenbanksystem eingesetzt werden. Es wird für jedes Datenbanksystem durch die verschiedenen Datenbankdialekte eine entsprechende Grammatik benötigt. Die Datenbankobjekte in Oracle werden zuerst formal in einer Backus-Naur-Form beschrieben und die Grammatik wird hiervon abgeleitet. Durch die Implementierung dieser Grammatik kann der Parser, und daher auch die Anwendung, jeder Zeit für andere Datenbanksysteme erweitert werden.

Die Implementierung der Graphenvisualisierung mit JUNG war überschaubar und durch Beispiele und eigene Prototypen gut lösbar. Mangels technischer Unterstützung von zusätzlichen Events⁵ konnten leider bereits früher erstellte Prototypen nicht verwendet werden. Dennoch bietet die nun implementierte Darstellung neben Zoom- & Verschiebemöglichkeiten auch filterbare Darstellungen sowie kontextsensitive Popupmenüs.

Dieser Text entstammt aus der abgegebenen Diplomarbeit, Kapitel “Fazit”, und wurde für das Web link-technisch aufgewertet.