In der heutigen Zeit ist Software in allen Lebenssituationen präsent. Mit dem Einzug der digitalen Welt werden auch die Softwaresysteme immer komplexer; sie leisten, kontrollieren und speichern immer mehr. Mit der Funktionsvielfalt und der Komplexität steigen auch die Anforderungen an die Speicherstrukturen. Es müssen nicht nur viele Daten gespeichert werden – die abgelegten Daten müssen auch wiedergefunden, aggregiert, umsortiert, gefiltert oder in Teilen verändert werden. Seit über 30 Jahren werden dafür vorwiegend relationale Datenbanksysteme verwendet1.
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 optimieren2.
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 Software 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 Zusammenarbeit 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.