ZUSAMMENFASSUNG Relationalen Datenbanksystemen kommt seit Jahrzehnten eine zentrale Rolle bezuglich der Speicherung von Anwendungsdaten zu. Im Fokus der nicht nur initial zu bewaltigenden Aufgabe einer Datenbankmodellierung steht vor allem die strukturierte und modularisierte Abbildung von fachlichen Anforderungen aus den zugehorigen Anwendungen. In vielen Fallen storen jedoch sogenannte funktionale Aspekte, wie beispielsweise die Internationalisierung oder Versionierung von Nutzdaten, diesen Prozess, da sie als querschnittliche Belange weite Teile des Datenmodells betre en und sich mit herkommlichen Methoden nicht als eine logische Einheit modellieren lassen. Durch den damit verbundenen Verlust der Modularisierung entstehen weitere Nachteile wie eine schlechtere Wiederverwendbarkeit, Nachvollziehbarkeit und Wartung. Diese Arbeit prasentiert das Paradigma der Aspektorientierten Datenhaltung als Losungsansatz fur die beschriebene Problematik. In Analogie zum Konzept der Aspektorientierten Programmiersprachen (AOP) zur Bewaltigung der Cross-Cutting Concerns wird dabei das Ziel einer weitestgehenden Modularisierung sowohl der fachlichen als auch funktionalen Aspekte wahrend der Datenbankmodellierung verfolgt. Hierfur werden Anforderungen und Eigenschaften formuliert, die spater als Spezi kationsgrundlage fur mogliche Realisierungsstrategien dienen. Abschlie end beschreibt die Arbeit einen Implementierungsansatz am geeigneten Beispiel sowie dessen Bewertung.
. . . . . .
. . .
. . .
. . . . . .
. . .
Oberteil sowie Unterteil sind Fremdschlussel bezogen auf Modul.TeilNr
Abbildung 1: Modellierung von Stucklisten
Vertreter solcher funktionalen Aspekte sind insbesondere
die Versionierung, Internationalisierung und
Tenantfahigkeit von Datenmodellen, wobei letztgenannter Aspekt
gerade auch im Kontext von Database as a Service eine
wichtige Rolle spielt[
Eine derartige Vermischung von fachlichen und funktionalen Anforderungen bei der Modellierung bringt einige Probleme mit sich. Eine direkte Folge ist die fehlende Abgrenzung von Zustandigkeiten, da eine Kapselung der funktionalen Aspekte nicht ohne weiteres moglich ist, wie beispielsweise bei der Modellierung verschiedener Business-Objekte durch die jeweiligen Experten bzw. Fachabteilungen. Stattdessen kann sich der Wirkungsbereich eines funktionalen Aspektes uber das gesamte Datenmodell erstrecken und zur Anpassung einer Vielzahl von Relationen fuhren. Dadurch ist neben der eigentlichen Arbeit zur Realisierung des fachlich orientierten Datenbankmodells zusatzlicher Abstimmungsaufwand notwendig, um die Anforderungen bezuglich der funktionalen Aspekte adaquat zu berucksichtigen. Aufgrund einer solch engen Verzahnung ist weiterhin sowohl mit einem geringen Wiederverwendungsgrad als auch mit erhohtem Wartungsaufwand der einzelnen Modellierungsobjekte zu rechnen, d.h. es ist beispielsweise nicht einfach moglich ein implementiertes Modul "Mehrsprachkeit\ aus einem Datenmodell zu isolieren und in einem anderen Anwendungskontext zu verwenden.
Nachfolgend wird in Abschnitt 2 ein Konzept zur Losung der einleitend beschriebenen Probleme bezuglich der Integration funktionaler Aspekte vorgestellt, welches die Entwicklung strukturierterer Datenmodelle ermoglicht. Hierfur notwendige Strategien und Methoden zur Realisierung werden anschlie end in Abschnitt 3 vorgestellt und in Abschnitt 4 bewertet, bevor Abschnitt 5 die vorliegende Arbeit zusammenfasst.
Dieser Abschnitt stellt das Konzept der Aspektorientierten Datenhaltung vor, welches bezugnehmend auf die Beschreibung funktionaler Aspekte (siehe De nition 1) wie folgt formuliert werden kann.
IDe nition 2. Die Aspektorientierte Datenhaltung
ist ein Paradigma, welches eine Datenbankmodellierung
unterstutzt, in der funktionale Aspekte unabhangig von der
fachlichen Modellierung integriert werden konnen.
Vordergrundig wird dabei das Ziel einer weitestgehenden
Modularisierung sowohl der fachlichen als auch funktionalen
Anforderungen verfolgt, sodass es zu einer moglichst minimalen
Uberschneidung dieser beiden Modellierungsebenen kommt.
Dabei grenzt sich das hier vorgestellte Konzept gegenuber
den von Rashid postulierten Aspect-Oriented
Database Systems (AODB) durch die grundsatzliche Zielstellung
ab. Auf der einen Seite werden die AODB als
Weiterentwicklung objektrelationaler bzw. -orientierter
Datenbanksysteme dargestellt, wobei Techniken der AOP sowohl zur
System-Implementierung selbst als auch fur die
Bereitstellung notwendiger Hilfsmittel zur Speicherung und Abfrage
von Aspekten aus einer entsprechenden
Programmiersprache heraus (z.B. AspectJ[
In einem ersten Unterabschnitt wird auf die Entstehung und Bedeutung des Begri s der Aspektorientierten Datenhaltung eingegangen, deren Ziele und Eigenschaften anschlieend Gegenstand der Betrachtung sind.
Fundamentale Konzepte der Informationstechnologie sind
die Modularisierung und Kapselung von Daten und
Funktionalitat in logische Einheiten. Dies au ert sich neben der
Denition von Architekturen und Schichtenmodellen wie dem
ANSI/SPARC-Modell[
Seit uber einem Jahrzehnt hat sich als Weiterentwicklung
der OOP das Paradigma der Aspektorientierten
Programmierung[
Aufgrund der Analogie zwischen Cross-Cutting Concerns und den einleitend in Abschnitt 1 beschriebenen funktionalen Aspekten sowie der damit verbundenen Probleme bei der Integration in Applikationscode bzw. in ein Datenmodell wird das hier vorgestellte Modellierungsparadigma als "dAerspBeekgtroirie"nDtiaetretnehDaalttuenngh\alatunn,gd\asbsezdeaischPnaerta.dDigambeai sdoewuotehtl Konzepte fur die reine Modellierung (SQL-DDL) als auch bezuglich der Interaktion von Anwendungen mit einem solchen Datenmodell (SQL-DML) beinhaltet muss.
Entsprechend der einleitenden De nition 2 fur die Aspektorientierte Datenhaltung werden im Folgenden zur Spezi zierung des Paradigmas wichtige Anforderungen und Eigenschaften formuliert.
Modularitat: Die Integration funktionaler Aspekte soll in einer Form moglich sein, dass alle zu einem Aspekt gehorenden Informationen in einer logischen Modellierungseinheit (z.B. einem Relationsschema) zusammengefasst werden konnen und sich dadurch die Vermischung mit der fachlichen Abbildung vermeiden lasst. Orthogonalitat: Diese Eigenschaft umfasst zwei Dimensionen bei der Betrachtung von funktionalen Aspekten. Einerseits ergeben sich bei einer Menge von n verschiedenen Aspekten insgesamt n! mogliche Reihenfolgen fur deren Integration in ein Datenmodell. Andererseits ist zu erwarten, dass ein konkretes Attribut fur beliebig viele [0; : : : ; n] Aspekte eine Relevanz besitzt. Dadurch gilt fur zwei Aspekte Ai und Ak bezuglich ihrer beein ussten Attributmengen M: jM(Ai) \ M(Ak)j wobei m = c (0 c
m); =
max(jM(Ai)j; jM(Ak)j) Orthogonalitat fordert nun fur die Aspektintegration, dass sowohl alle potentiellen Reihenfolge-Varianten ein gegebenes Datenmodell in einen semantisch aquivalenten Zustand uberfuhren als auch, dass es zu keinen Wechselwirkungen zwischen den Aspekten bezuglich ihrer beein ussten Attributmengen kommt.
Lokalitat: Die Abbildung von funktionalen Aspekten sollte derart gestaltet sein, dass bei der Integration eines Aspektes nicht das gesamte Datenmodell einer Transformation unterzogen werden muss, sondern moglichst minimale Anderungen nur an den notwendigen Stellen (Modellierungseinheiten) ausreichen.
Universalitat: Das Konzept der Aspektorientierten
Datenhaltung ist nicht auf einen konkreten
Anwendungsbereich eingeschrankt. Um in der Praxis ein maximal
breites Einsatzgebiet bezuglich realer DBMS-Produkte
zu erreichen, werden zur Implementierung
funktionaler Aspekte nur Konzepte der Datenbankmodellierung
auf Basis des SQL:92 -Standards[
Basierend auf den beschriebenen Anforderungen konnen nun Ansatze zur Implementierung entworfen werden, der nachfolgende Abschnitt 3 vermittelt hierzu einen Uberblick.
Nachdem im bisherigen Verlauf der Arbeit das Paradigma der Aspektorientierten Datenhaltung motiviert und naher beschrieben wurde, widmet sich dieser Abschnitt der Prasentation geeigneter Ansatze fur die Realisierung. Neben der eigentlichen Abbildung funktionaler Aspekte in einem Datenmodell (Abschnitt 3.1) umfasst dieses Thema entsprechend der Anforderung der Benutzbarkeit auch Strategien fur die Unterstutzung bei der Integration eines Aspekts (Abschnitt 3.2).
Zur Gewahrleistung der in Abschnitt 2.2 formulierten
Eigenschaften bietet sich das EAV -Konzept[
AspectAssign: Uber diese Tabelle ndet die tatsachliche Zuordnung aspektspezi scher Attributwerte zu funktionalen Aspekten statt. Dazu enthalt ein Datensatz neben dem Primarschlussel (AspAssID) einen Verweis sowohl auf den konkreten Aspekt (AspDefID) als auch den gep egten Attributwert (AspValID) sowie den Wert (Value) bezuglich des Schlusselkriteriums des referenzierten Aspektes. Beispielsweise stehen die Eintrage mit AspAssID 2 f1004; 1005g fur die Versionierung (AspDefID = 2) des Attributes Bezeichnung desjenigen Datensatzes in Modul mit dem Primarschlusselwert 20080. Gleichzeitig ist mit Y-Kabel\ ei" ne dieser Versionen (AspAssID = 1006) auch ubersetzter Attributwert fur die Lokale at\ im Kontext " des Aspektes der Internationalisierung.
Voraussetzung fur das beschriebene Konzept ist die Existenz einattributiger typgleicher Primarschlussel in allen fur funktionale Aspekte potentiell relevanten Tabellen, damit diese in AspectValue.RowID einheitlich referenziert werden konnen. Diese Forderung lasst sich jedoch immer gewahrleisten, da entweder die betre ende Tabelle bereits einen solchen Primarschlussel besitzt oder um einen zusatzlichen kunstlichen Schlussel mit der Option auto increment erweitert werden kann.
Fur den praxistauglichen Einsatz des in Abschnitt 3.1 vorgestellten Realisierungskonzeptes ist wie in den Anforderungen erlautert zusatzlich eine Unterstutzung des Nutzers bzw. Administrators im Prozess der Integration von funktionalen Aspekten in ein bestehendes oder neu zu entwickelndes Datenmodell notwendig. Der im Folgenden dargestellte Algorithmus umfasst die wichtigsten Schritte fur einen solchen Integrations-Assistenten. Werden andere Realisierungskonzepte verwendet, konnen Abweichungen oder komplett neue Teilschritte notwendig sein.
1. Festlegung der Verbindungsparameter zur Datenbank. 2. Auswahl des zu integrierenden funktionalen Aspektes. 3. Festlegung von Tabellen und den jeweiligen Attributen, welche fur den zu integrierenden Aspekt im Sinne der zugrundeliegenden Anwendung relevant sind. Beispielsweise ist beim Aspekt der Internationalisierung unter anderem die Entscheidung zu tre en, welche Tabellenattribute zukunftig ubersetzbar (mehrsprachig) sein sollen. 4. Optional: Erstellung eines Backups der Datenbank. 5. Sicherstellung des einattributigen Primarschlussels in allen gewahlten Tabellen, gegebenenfalls durch Hinzufugen eines kunstlichen Schlussels wie am Ende von Abschnitt 3.1 beschrieben. 6. Erstellung der zum Realisierungskonzept gehorenden
lue und AspectAssign. Existieren diese Tabellen bereits, so ist nur ein zusatzlicher Eintrag in der Tabelle AspectDefinition fur den neuen funktionalen Aspekt notwendig.
Abschlie end soll der prasentierte Realisierungsansatz
anhand der fur die Aspektorientierte Datenhaltung
formulierten Anforderungen und Eigenschaften (Abschnitt 2.2)
bewertet werden. Daruber hinaus erlaubt der Ansatz aufgrund
des verwendeten EAV-Konzeptes unabhangig von
funktionalen Aspekten die Abbildung beliebiger zusatzlicher
Tabellenattribute auf Datensatzebene ohne Schemaanderung.
Damit wird eine Semistrukturiertheit ermoglicht, wie sie vor
allem bei der XML-Notation[
Aufgrund der Kapselung aller notwendigen Informationen zur Abbildung von funktionalen Aspekte in den Tabellen AspectDefinition, AspectValue und AspectAssign ist die Modularitat diesbezuglich sichergestellt. Eine Veranderung fachlicher Tabellen ist nur im Rahmen der Voraussetzung eines einattributigen typgleichen Primarschlussels notwendig. Damit ist auch gleichzeitig die Eigenschaft der Lokalitat erfullt. Die Modellierung dieser drei beschriebenen Verwaltungstabellen basiert allein auf atomaren Attributen mit einfachen Domanen (int, varchar) sowie Fremdschlusseln, dies genugt der Forderung nach Universalitat.
Die Bewertung der Orthogonalitat gliedert sich entsprechend der hier getro enen De nition in zwei Teile. Einerseits ist fur eine Menge funktionaler Aspekte die semantische Aquivalenz bezuglich ihrer moglichen Reihenfolgen gesichert, da sich die Integration aller Aspekte nur als zusatzliche Datenzeilen in den gemeinsam genutzten initial angelegten Verwaltungstabellen niederschlagen. Dabei sind keine aspektspezische Anderungen an den fachlichen Tabellen notwendig. Andererseits konnen fur zwei verschiedene Aspekte Wechselwirkungen in Hinblick auf die beein ussten Attributmengen ausgeschlossen werden aufgrund der getrennten Speicherung aspektspezi scher Informationen zu fachlichen Daten (AspectValue) und der tatsachlichen Zuordnung zu Aspekten (AspectAssign) wie beispielhaft in Abschnitt 3.1 erlautert.
Schlie lich ist mit dem in Abschnitt 3.2 vorgestellten Algorithmus die Grundlage fur einen Integrations-Assistenten gelegt, um die Benutzbarkeit des gesamten Realisierungsansatz zu gewahrleisten.
Die vorliegende Arbeit prasentierte das Modellierungsparadigma der Aspektorientierten Datenhaltung mit dem Ziel, funktionale Aspekte als Vertreter von querschnittlichen Belangen in einer modularisierten Form im Datenmodell abzubilden. Dadurch lasst sich die Vermischung von fachlicher und funktionaler Modellierungsebene vermeiden, dies fuhrt letztlich zur besseren Strukturierung, Wartbarkeit und Wiederverwendbarkeit eines Datenmodells.
Mit den Eigenschaften der Modularitat, Orthogonalitat, Lokalitat, Universalitat und Benutzbarkeit wurden grundsatzliche Anforderungen formuliert. Diese dienten anschlie end TeilNr 19780 20080 . . . 101 102 103 104 105 106 107 108 . . .
0.75 0.10 . . .
e e . . .
00110101 00110011 . . .
Modul Modul Modul Modul Modul Modul Modul . . . 19780 19780 19780 19780 19780 19780 20080 20080 . . .
Bezeichnung Preis Wahrung Bezeichnung Preis Wahrung Bezeichnung Bezeichnung . . .
Value screw 0.45 $ bullone 0.78 e X-Kabel Y-Kabel . . .
DEC CHAR CHAR DEC CHAR CHAR CHAR . . . 1 2 . . . 1001 1002 1003 1004 1005 1006 1007 1008 . . .
101 102 103 107 108 108 104 105 . . .
Revision . . .
us us us 1 2 at it it . . .
Unique-Bedingung in Tabelle AspectValue uber (TabID, RowID, AttID, Value, TypeID) Unique-Bedingung in Tabelle AspectAssign uber (AspDefID, AspValID, Value) AspectAssign.AspDefID ist Fremdschlussel bezuglich AspectDefinition.AspDefID AspectAssign.AspValID ist Fremdschlussel bezuglich AspectValue.AspValID
Abbildung 2: Modellierungsansatz fur funktionale Aspekte als Spezi kationsgrundlage fur das am Beispiel vorgestellte Realisierungskonzept. Die abschlie ende Bewertung zeigte die Verwendbarkeit dieses Konzeptes fur das Paradigma der Aspektorientierten Datenhaltung.
Zukunftige Arbeiten werden sich mit der Vervollstandigung des skizzierten Realisierungsansatzes beschaftigen, wobei sowohl fur die angedeuteten Probleme bezuglich des EAVKonzeptes als auch fur einen generischen applikationsseitigen Zugri auf funktionale Aspekte Losungsstrategien bewertet werden mussen. Parallel dazu besteht die Aufgabe einer prototypischen Implementierung des hier vorgestellten Konzeptes. Dies betri t sowohl die reale Modellierung (relationale Abbildung) in einem existierenden DBMS-Produkt als auch die Entwicklung des Assistenten zur Integration von funktionalen Aspekten.