Außerdem wurde die Anwendung um die Fähigkeit von Prozeduren (nur Oracle) und dem Feature “Einzelansicht” erweitert. Desweiteren wurden einige Fehler im Zusammenhang mit Trigger-SQL-Parsen behoben.

Sowohl die Anwendung als auch die Bachelorarbeit ist zum Download verfügbar.

Prof. Dr. Heide Faeskorn-Woyke wird nächste Woche auf der DOAG 2010 Konferenz als Dozentin im Themenbereich Hochschulprojekte “visualDependencies” vorstellen.

Raum: Singapur, Zeit: 15:00

Die erstellte Anwendung beschränkt sich in der vorliegenden Version auf die Schemaanalyse der Datenbanksysteme Oracle und MySQL. Dabei werden die Oracle-Versionen 9i, 10g und 11g für die Zwecke der Anwendung vollständig unterstützt. Das Plugin für eine MySQL-Datenbank ist in einem experimentellen Zustand und daher nicht vollstän- dig. Durch ein geeignetes Abstraktionslevel lassen sich jederzeit weitere Datenbanksysteme unterstützen. Auch eine individuelle Implementierung aufgrund verschiedener Da- tenbankdialekte oder spezieller Features ist möglich. Prinzipiell ist jedoch ein JDBC- Treiberplugin für ein entsprechendes Datenbanksystem notwendig.

Für eine geeignete Darstellung der Knoten und Kanten eines Graphen sind weitere Alternativlayouts möglich. Insbesondere die Problematik der sich überschneidenden Kanten kann durch effizientere Algorithmen gelöst werden. Ein Beispiel für solche Algorithmen ist der Algorithmus von Sugiyama zur Minimierung von Kantenschnitten^[1]. Für eine optimalere Darstellung ist auch die Bildung von Clustern, also zusammenhängenden Untermengen, eine mögliche Option.

Das dargestellte Entity-Relationship-Diagramm beinhaltet keine zusätzlichen Informationen wie die Kardinalität, die Optionalität und identifizierende Beziehungen. Die da- für notwendigen Informationen sind bereits durch die Analyse ermittelt worden. Dabei werden die Zwischentabellen von m:n-Beziehungen zu zwei 1:n-Beziehungen aufge- schlüsselt. Nur durch Interpretationen lassen sich echte m:n-Beziehungen nachweisen und anzeigen.

Im Zusammenhang mit der Analyse und Visualisierung der View-Hierarchien sind auch die rekursiven Views interessant. Diese sind zwar als RECURSIVE VIEW bereits im SQL- Standard SQL:1999 vorhanden, allerdings werden sie noch nicht von allen Datenbankherstellern unterstützt. Im Gegensatz zu DB2 von IBM bietet Oracle bisher nur die CONNECT BY-Klausel^[2] an, die mit komplett anderer Vorangehensweise ähnliche Er- gebnisse liefert. Als Grundlage für die Darstellung rekursiver Viewabhängigkeiten kann die visuelle Veranschaulichung der Triggeraktivitäten dienen.

Bei der Visualisierung der Abhängigkeiten in einer Datenbank gibt es weitere, für diese Anwendung interessante Objekte: Integritätsbedingungen, Assertions, Funktionen, Prozeduren und Typen. Ähnlich wie Trigger enthalten Funktionen und Prozeduren SQL- Code, der sowohl vordefinierte als auch dynamisch zusammengesetzte SQL-Anwei- sungen enthalten kann. Damit ergeben sich weitere direkte oder indirekte Abhängigkeiten auf andere Objekte in der Datenbank. Auch die Aufschlüsselung einer objektrelationalen Typhierarchie kann in Erwägung gezogen werden.

Im Rahmen dieser Arbeit wird nur eine statische Analyse der Objekte und deren Abhängigkeiten verfolgt. Eine tiefergehende Untersuchtung der Abhängigkeiten kann durch die Betrachtung der spaltenbezogenen ON-Klausel oder der Bedingungsklausel WHEN in PL/SQL-Triggern ermöglicht werden.

Eine andere visuelle Darstellungsmöglichkeit, eventuell auch dreidimensional, wäre, die Tabellen mehr in das Zentrum der Betrachtung zu stellen. Dabei würden alle drei Ansichten der Anwendung – Views, Trigger und das ERD mit Fremdschlüsseln – vereinigt und bei Bedarf im Graphen jeweils zu den Tabellenobjekten auf unterschiedliche Weise angezeigt.

vdb: Mutating-Table-Trigger

Als einen zusätzlichen Ansatz zur Visualisierung könnte die Darstellung eines dynamischen Kontrollflusses dienen. Ähnlich wie in einem UML-Aktivitätsdiagramm zeigt das Kontrollflussdiagramm einzelne Aktivitäten und Kontrollflüsse an. Dabei sind die Aktivitäten die einzelnen Objekte der Datenbank und die Kontrollflüsse resultieren aus den Abhängigkeiten. Damit ergibt sich ein weiteres und interessantes Anwendungsszenario. Nach der Spezifizierung einer DML-Anweisung durch den Benutzer zeigt die Visualisierung die einzelnen Kontrollflüsse durch alle benutzten und verwendeten Datenbankobjekte mit den entsprechend konkreten Daten und Entscheidungen an. Diese teils indirekten Implikationen, beispielsweise auch kaskadierendes Löschen bei Integritätsbedingungen, können somit ebenfalls in einem Graphen dargestellt werden. Dafür ist es allerdings notwendig, dass der Parser den Inhalt des Triggerkörpers komplett einliest und verarbeitet. Für dynamische Kontrollflüsse sind alle Blöcke (Compoundtrigger, Bedingungen, Schleifen) notwendig zu betrachten und bei Ausführung auszuwerten.

Mit Hilfe dieser Software – und unter Berücksichtigung der möglichen Erweiterungen – gibt es nun ein hilfreiches Werkzeug, um die direkten und indirekten Abhängigkeiten von Objekten in einem Datenbanksystem sowohl zu erkennen als auch grafisch darzustellen. Durch eine flexible und erweiterbare Architektur ist das Softwareprodukt auch für neue Anforderungen gut einzusetzen.

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

1. ^[1] Für weitere Informationen zu Graphenlayouts: http://ftp.informatik.uni-stuttgart.de/iste/ps/Lehre/S_Graphen/kopp.pdf (ebenfalls im Literaturverzeichnis). ↩
2. ^[2] In Oracle nur in Verbindung mit einer rekursiven Select-Abfrage möglich. ↩

Eine Analyse der Aufgaben und Funktionen an die Anwendung ergab, dass drei verschiedene Ansichten implementiert werden müssen: die View-Hierarchie, die Triggerakti- vitä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.

SQLDeveloper Übersicht

Eine Evaluation bestehender Werkzeuge im Bereich des Datenbankmanagements ergab, dass nahezu keine Anwendung derartige Funktionalitäten^[1] 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.

TOAD View-Abhängigkeiten

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^[2] 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.

Mockup: View-Hierarchie mit Satellit

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^[3] 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.^[4]

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.

vdb: Negative View-Abhängigkeit

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^[5] 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.

1. ^[1] Ausgenommen sind davon die ER-Diagramme. ↩
2. ^[2] Stand Juli 2009 ↩
3. ^[3] Oracle Database 11g Release 1 (11.1.0.7.0) JDBC Drivers, Stand Juli 2009 ↩
4. ^[4] Ergänzung: Mittlerweile hat sich ebenfalls herausgestellt, dass die Abfrage nach Indexspalten über Oracles JDBC-Metadata-Implementierung zu impliziten, ungewollten und nicht performanten Statements führt. ↩
5. ^[5] An dieser Stelle sind damit die abfragbaren Mausklicks für zusätzliche Popups oder Buttons eines Graphenknotens gemeint. ↩

Bereits heute sind viele der Softwarelösungen mit integrierten Datenbanken ausgestattet. Von den offensichtlichen Datenbanken in Webanwendungen oder der Literaturfunktion im Textverarbeitungsprogramm abgesehen, besitzen sogar vereinzelte Anwendungen wie Internet-Browser, E-Mail-Clients oder Hardwaregeräte wie Handys und Smartphones eigene, autonome Datenbanksysteme. Zurzeit sind dies oft rein speicherorientierte Da- tenbanklösungen auf der Basis von HSQLDB oder SQLite. Mit neuen funktionalen Erweiterungen und fortschreitender Technik werden diese Systeme künftig immer komplexer.

Schon in den 90er Jahren wurden vermehrt die so genannten Data-Warehouses entwickelt, welche je nach Unternehmen eine oft unvorstellbare Menge an Daten vorhalten. Da diese Daten per Definition aus unterschiedlichen Quellen stammen, müssen sie bei der späteren Verwendung häufig mehrfach gefiltert, aggregiert, reorganisiert und verändert werden: So müssen etwa bestimmte Daten wechselseitig ergänzt werden; manche Daten dürfen aus rechtlichen, persönlichen oder sonstigen speziellen Interessen nur bestimmten Abteilungen eines Unternehmens zugänglich gemacht werden; wieder andere Daten hängen unter genau spezifizierten Bedingungen voneinander ab. Die Datenbanksysteme lösen diese Probleme, indem sie virtuelle Sichten (sprich: Views) auf die Datenbestände (sprich: Tabellen) bereitstellen. Diese werden durch Datenbankanwender angelegt und je nach Einsatzziel mit entsprechenden Benutzerrechten verknüpft. Bei hoch komplexen Strukturen werden diese Sichten wiederum miteinander verknüpft und verschachtelt. Das Endresultat ist eine komplexe Vermischung von Verknüpfungen, Vermengung, Sortierung und Filterung der Daten. Dies sind die Grundfunktionalitäten der Structured Query Language (SQL) und damit auch die Basis der Views.

Zur Optimierung der Abfrageperformanz und des Datenaufkommens können zwischengespeicherte Sichten auch für oft angeforderte Anfragen dienen. Je nach Komplexität der unterliegenden Daten kann eine geeignete Projektion und Selektion die Geschwindigkeit zulasten der redundanten Speicherung optimieren^[2].

Welche konkrete Relevanz hat nun aber das Hinzufügen, Löschen oder Ändern eines Datums in einer Tabelle? Wann und wo treten Veränderungen welcher Art auf?

Um der steigenden Komplexität der Datenbanken gerecht zu werden, helfen oft automatische, interne Aufträge (Trigger) im Datenbanksystem. Die Trigger definieren ein Stück Programmcode und führen ihn zu einem bestimmten Zeitpunkt und unter einer bestimmten Bedingung aus. Der Zweck eines Triggers ist es, die Datenintegrität aufrecht zu erhalten oder in Verknüpfung mit materialisierten Views für konsistente Daten zu sorgen. Allerdings ist es nicht so ohne Weiteres ersichtlich, ob die Ausführung eines Triggers erfolgreich sein kann, wenn dadurch weitere Trigger ebenfalls aktiv werden. Erst zur Laufzeit, also nach dem statischen Analysieren und gegebenenfalls auch Parsen des Triggers, kann ein Fehler auftreten. Damit stößt man jedoch schnell an die Grenzen des Machbaren. Dies ist auch ein Grund, warum beispielsweise Oracle trotz der beschriebenen Problematik anstandslos das Anlegen von Triggern akzeptiert, welche aber zu rekursiven Abläufen führen oder das Mutating Table-Problem auslösen könnten.

In der Regel behilft man sich mit einer Umgehung der Problematik. Beispielsweise kann man das Mutating-Table-Problem durch das Aufteilen in zwei Triggereinheiten mit einer temporären Tabelle lösen. Allerdings wird dadurch die Komplexität der Abhängigkeitsstruktur nochmals verstärkt: Was passiert konkret, wenn man ein Datum einer Tabelle oder View ändert? Kann man das Auftreten des Fehlers vorher schon erkennen? Lassen sich potenzielle Zyklen und Rekursionen im Ablauf im Vorfeld erkennen?

Es gibt eine Reihe von visuellen Werkzeugen für Datenbanksysteme oder Anwendungen, die einige grafische Zusatzfunktionen anbieten. Nahezu alle beschränken sich dabei auf die Darstellung der Fremdschlüsselbeziehungen und zielen daher auf die referentielle Integrität. Für die Entwicklung eines Datenbankmodells und auch für das Verständnis des Modells ist eine solche Darstellung oft hilfreich und deshalb auch sehr sinnvoll. Hingegen verschafft es dem Datenbankadministrator oder einem interessierten Anwender nicht die gewünschte Transparenz, um die komplexen, wechselseitigen Abhängigkeiten der Views und Tabellen nachvollziehen zu können.

Im Rahmen dieser Diplomarbeit wird eine Software entwickelt, welche die Abhängigkeiten von Objekten einer Datenbank transparent für den Anwender darstellt. Die Tabellen, Trigger und Views werden dazu zunächst analysiert und anschließend mittels Graphen visualisiert. Eine Software, welche hilfreich bei der Erkennung komplexer Viewabhängigkeiten und rekursiver Triggeraktivitäten ist, gibt es weder mit der analytischen noch der grafischen Komponente.

Ein Teil der Arbeit beschäftigt sich zusätzlich mit einer Evaluation und Bewertung verschiedener vorhandener Frameworks und Werkzeuge, die für die Entstehung der Softwa- re von Bedeutung sind. Außerdem wird bewertet, inwieweit die Software erweiterungsfähig ist.

Die Diplomarbeit entstand aus einer Idee von Dr. Andreas Behrend und wurde in Zu- sammenarbeit mit der Universität Bonn erstellt. Die Autoren Andre Kasper und Jan Philipp haben diese Arbeit zusammen an der Fachhochschule Köln, Campus Gummersbach, erstellt.

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

1. ^[1] Nur relationale Datenbanksysteme sind im Rahmen dieser Diplomarbeit von Bedeutung. ↩
2. ^[2] In der Informatik wird ein derartiges Speicherverfahren für temporäre Daten „Caching“ genannt. Der Umfang eines Caches ist abhängig vom Datenbanksystem, Hardware und speziellen Anforderungen. ↩

Obwohl – oder vielleicht auch gerade weil? – das Thema sehr abstrakt formuliert war, klang es für uns beide sehr interessant. In den ersten Gesprächen konnten wir das Thema weiter eingrenzen: Wir stellten fest, dass auch Evaluationen von möglichen Analysen, Darstellungen sowie vorhandener Software Bestandteil der Arbeit werden würden.

Als “Abhängigkeiten” bezeichneten wir damit:

• Beziehungen unter Views und Tabellen (Grafisch: Anfangs- und Endknoten) sowie die Bewertung jeder Beziehung (grafisch: Kante) anhand der Abhängigkeitsbenutzung (reduziert, erweitert, verändert die Abhängigkeit die ursprüngliche Menge?)
• rekursive Abhängigkeiten einer View
• (rekursive) Abhängigkeiten zwischen Triggern und ihre Auswirkungen. Hierbei ist bei Oracle das Mutating-Table das Beispiel schlechthin.

Mockup: View-Hierarchie

Damit würde die Diplomarbeit im Wesentlichen aus drei Teilen bestehen:

1. Die Evaluation vorhandener Software oder Verfahren hinsichtlich der Erkennung oder Darstellung von Abhängigkeiten zwischen Views, Triggern oder Tabellen;
2. die Entwicklung eines SQL-Parsers am Beispiel von Oracle zur Bestimmung eben solcher Abhängigkeiten;
3. die Entwicklung einer geeigneten, grafischen und wohlmöglich interaktiv bedienbaren Präsentation der ermittelten Abhängigkeiten am Bildschirm.

Es stand von vorne herein fest, dass die Arbeit auch ein Endprodukt in Form eines Java-Programmes beinhalten würde.