Analyse und Vergleich von Zugriffstechniken fu¨ r funktionale Aspekte in RDBMS

Abstract

KURZFASSUNG Neben klassischen fachlichen Anforderungen existieren in Anwendungssystemen oft auch querschnittliche Belange, deren Funktionalitat sich nicht einfach kapseln bzw. modularisieren lasst. Vertreter dieser sogenannten funktionalen Aspekte sind beispielsweise die mehrsprachige oder versionierte Darstellung und Verwaltung von Anwendungsdaten. Nachdem sich in der Software-Entwicklung seit einigen Jahren die Aspektorientierte Programmierung als Losung etabliert hat, bietet das neuartige Paradigma der Aspektorientierten Datenhaltung ein entsprechendes Konzept zur Abbildung querschnittlicher Belange in einem relationalen Datenmodell. Dabei stehen vor allem die Unabhangigkeit vom Prozess der fachlichen Modellierung und ein hoher Wiederverwendungsgrad im Vordergrund. Basierend auf dem zu diesem Zweck entwickelten Referenzmodell untersucht der vorliegende Beitrag unterschiedliche Techniken fur den Zugri auf jene funktionalen Aspekte. Diese werden anschlieend anhand wesentlicher Bewertungskriterien einer Evaluation unterzogen und miteinander verglichen.

1. EINLEITUNG

Seit der Beschreibung des relationalen Modells[ 4 ] Anfang der 1970er Jahre ist die Bedeutung auf diesem Modell basierender Datenbankmanagementsysteme (RDBMS) als Persistierungsebene stetig gewachsen. Heutzutage bilden relationale Datenbanksysteme die Grundlage fur die vielfaltigsten Anwendungssysteme und sind damit aus den meisten alltaglichen Prozessen nicht mehr wegzudenken. Die Ent

2. REFERENZMODELL

Fur die vom fachlichen Datenmodell unabhangige und gekapselte Persistierung aspektspezi scher Daten wurde in [ 12 ] ein Referenzmodell vorgestellt und beschrieben, welches mit geringfugigen Anpassungen bezuglich der Fremdschlusseldenitionen in den Tabellen zur Aspektverknupfung auch in diesem Beitrag zum Einsatz kommt.

Aspect.Datatype PK AspTypeID

TypeName Length

Scale Aspect.Table PK AspTabID

Schema

TableName Aspect.Column PK AspColID FK Table

ColumnName FK Datatype Aspektmetadaten PK AspAssID FK KeyValue FK AspectValue Aspect.Value PK AspValID

RowID FK Column

Value

Aspect.KeyValue PK AspKeyID FK Aspect

KeyValue

Comment Aspect.Definition PK AspDefID

Name

Key FK Datatype Aspect.Additional PK AspAddID FK Aspect

FK Table Aspektverknüpfung

Aspektstammdaten

PK/FK: Primär−/Fremdschlüssel

Abbildung 1: Referenzmodell

Zentraler Bestandteil dieses in Abbildung 1 skizzierten Referenzmodells sind die beiden Tabellen Aspect.Value und Aspect.Assign, welche die Speicherung aspektspezi scher Attributwerte sowie deren Zuordnung zu einer konkreten Aspektauspragung (z.B. Locale 'en' im Aspekt Mehrsprachigkeit) fur eine Fachtabellenzelle realisieren. Daneben existieren weitere Tabellen zur Verwaltung von Metadaten, wie beispielsweise Aspect.KeyValue fur die Spezi kation von Auspragungswerten zu allen im System de nierten Aspekten oder Aspect.Column zur Hinterlegung aspektrelevanter Attribute der Fachtabellen.

Die Anforderungen aus dem Paradigma der Aspektorientierten Datenhaltung werden insbesondere durch das EntityAttribute-Value-Konzept[ 15 ] (EAV) gewahrleistet, welches fur Aspect.Value und Aspect.KeyValue zur Anwendung kommt. Die damit verbundenen Konsequenzen[ 7 ] bezuglich der Komplexitat von direkten SQL-Anfragen im Referenzmodell erfordern die Analyse alternativer Zugri sarten.

Mehrsprachigkeit

Demo.Modul PK TeilNr

Name Preis Flags

Demo.Struktur PK,FK Oberteil PK,FK Unterteil

Menge

PK/FK: Primär−/Fremdschlüssel IAnfrage: Ermittle fur das Modul mit TeilNr=4711 alle mehrsprachigen Daten ( Name und Preis) sowie den jeweiligen Aspektschlusselwert als Locale.

Abbildung 2: Beispiel fur Datenmodell mit Anfrage Zur Veranschaulichung der in Abschnitt 3 folgenden Techniken soll das in Abbildung 2 dargestellte Beispiel eines vereinfachten Datenmodells zur Verwaltung von Stucklisten dienen, in dem der Aspekt "Mehrsprachigkeit\ fur die Attribute Demo.Modul.Name sowie Demo.Modul.Preis aktiviert wurde. Darauf aufbauend soll jeweils die Beantwortung der zugehorigen Beispiel-Anfrage erlautert werden, welche das Prinzip fur den Zugri auf aspektspezi sche Attributwerte in einem konkreten fachlichen Anwendungskontext verdeutlichen soll.

3. ZUGRIFFSTECHNIKEN

Dieser Abschnitt beschreibt verschiedene Moglichkeiten fur den Zugri auf funktionale Aspekte, welche mit Hilfe des in Abbildung 1 prasentierten Referenzmodells in ein fachliches Datenmodell integriert werden. Aufgrund der Tatsache, dass das relationale Modell als Grundlage dient, ist der direkte Zugri mittels SQL auf die entsprechenden Strukturen die naheliegendste Moglichkeit. Allerdings stellt die zentrale Tabelle Aspect.Value eine neue Herausforderung fur die Anfragegenerierung dar, weil darin enthaltene Daten durch das verwendete EAV-Prinzip[ 15 ] einer sogenannten unpivotisierten ("gekippten\) Speicherungsform unterliegen. Dies hat zur Konsequenz, dass zu jedem Attribut (Column) eines traditionellen Tupels (identi zierbar uber RowID) der jeweilige Wert (Value) in einer eigenen Zeile gespeichert wird. Da jedoch die klassische relationale Verarbeitung von Datensatzen mit zugehorigen Attributen als Tabellenspalten ausgeht, ist eine Pivotisierung ("rows to columns\) notwendig, sobald in der Anfrage die Tabelle Aspect.Value involviert wird. Die anschlie enden Abschnitte beschreiben drei Konstrukte in SQL sowie einen applikativen Ansatz, um die genannte Transformation zu unterstutzen.

3.1 SQL mit JOIN

Bei einer Beschrankung auf normierte Sprachmittel ist die erforderliche Transformation nur mittels JOIN-Operatoren realisierbar, da weder im SQL:92-Standard[ 6 ] als Grundlage fur das Paradigma der Aspektorientierten Datenhaltung[ 11 ] noch in der aktuellen SQL:2008-Norm[ 10 ] dedizierte Operatoren zur Pivotisierung einer Tabelle existieren. Das prinzipielle Vorgehen ist exemplarisch fur die in Abbildung 2 formulierte Anfrage in Abbildung 3 dargestellt. Dabei wurde auf die Formatierung der Ergebnisattribute entsprechend den zugeordneten Datentypen in Tabelle Aspect.Datatype verzichtet und zwecks Ubersichtlichkeit die Kenntnis gewisser Metadaten wie Idents von Aspekten und Tabellenspalten als bekannt vorausgesetzt.

SELECT T1.Value AS Name, T2.Value AS Preis,

T5.KeyValue AS Locale

FROM Aspect.Value T1

INNER JOIN Aspect.Value T2

ON T1.RowID = T2.RowID

INNER JOIN Aspect.Assign T3

ON T1.AspValID = T3.AspectValue

INNER JOIN Aspect.Assign T4

ON T2.AspValID = T4.AspectValue

INNER JOIN Aspect.KeyValue T5

ON T3.KeyValue = T5.AspKeyID WHERE T1.Column = 1 -- /* 'Name' */

AND T2.Column = 2 -- /* 'Preis' */ AND T3.KeyValue = T4.KeyValue AND T5.Aspect = 1 -- /* 'Mehrsprachigkeit' */ AND T1.RowID = 4711

Abbildung 3: Anfrage mit JOIN Bereits fur das simple in Abbildung 3 prasentierte Beispiel ist die Komplexitat der Anfragegenerierung inklusive Pivotisierung der Tabelle Aspect.Value erkennbar. Insbesondere skalieren die notwendigen JOIN-Operatoren linear mit den Attributen im Ergebnisschema. Dabei werden jeweils die Tabellen Aspect.Value und Aspect.Assign miteinander verbunden, welche fur die Speicherung aller aspektspezi schen Auspragungen von Attributwerten in Fachtabellen zustandig sind und dadurch mit Abstand die umfangreichsten Mengengeruste aufweisen. Erwartungsgema haben derartige Anweisungen eine oft inakzeptable Verarbeitungszeit wie entsprechende Analysen gezeigt haben[ 13 ].

3.2 SQL mit PIVOT

Verlasst man die SQL-Norm auf der Suche nach adaquater Unterstutzung fur die Pivotisierung von EAV-Tabellen, dann zeigt sich, dass DBMS-Hersteller bereits produktspezische SQL-Erweiterungen mit den Operatoren PIVOT und UNPIVOT[ 20 ] anbieten. Unter anderem nden sich derartige Implementierungen in Datenbanksystemen wie Microsoft SQL Server 2005[ 18 ] oder Oracle 11g[ 14 ]. Ein typisches Anwendungsgebiet fur diese Transformationen sind OLAPAnfragen im Bereich Data Warehouse[ 17 ], deren Blickwinkel geandert werden soll (beispielsweise die Gruppierung nach Regionen statt Produkten in einer Umsatzubersicht). Durch Nutzung von PIVOT und UNPIVOT kann eine gezielte Optimierung auf Basis der klassischen Operatoren wie Verbund oder Projektion erfolgen[ 5 ].

SELECT PivotedData.[1] AS Name,

PivotedData.[2] AS Preis,

PivotedData.KeyValue AS Locale

FROM (

SELECT T1.RowID, T1.Column, T1.Value,

T3.KeyValue

FROM Aspect.Value T1

INNER JOIN Aspect.Assign T2

ON T1.AspValID = T2.AspectValue

INNER JOIN Aspect.KeyValue T3

ON T2.KeyValue = T3.AspKeyID WHERE T3.Aspect = 1 -- /*'Mehrsprachigkeit'*/

AND T1.RowID = 4711 ) AS JoinData

PIVOT (

MAX(JoinData.Value)

FOR JoinData.Column IN ([1], [2]) -- /* 1 und 2 = relevante Column-IDs */ ) AS PivotedData

Abbildung 4: Anfrage mit PIVOT Aber auch die Verarbeitung von EAV-Tabellen wie hier im Kontext der Aspektorientierten Datenhaltung ist mit Hilfe des PIVOT-Operators moglich. Abbildung 4 demonstriert dessen Verwendung unter Microsoft SQL Server 2005 fur die Beispielanfrage in Abbildung 2. Auf den ersten Blick verwirrt dabei der Ausdruck MAX(JoinData.Value), welcher die notwendige Aggregatbildung bei der Pivotisierung ubernimmt. Diese Funktion lasst das Ergebnis jedoch inhaltlich korrekt, solange jede Gruppe bezuglich der gruppierten Attribute (T1.RowID, T3.KeyValue) und den zu Spalten umgewandelten Werten aus T1.Column nur einen Datensatz enthalt. Um dies unter Beachtung der getrennten Speicherung der aspektspezi schen Werte (Aspect.Value) und den tatsachlichen Fachtabellen-Zuordnungen (Aspect.Assign) sicherzustellen, mussen die beiden genannten Tabellen zusammen mit der Tabelle Aspect.KeyValue verbunden werden. Anschlie end kann uber die projezierte Attributmenge sinnvoll pivotisiert werden.

Zusatzlich ist bei der Nutzung des PIVOT-Operators zu beachten, dass fur die IN-Klausel nur eine fest de nierte Spaltenmenge angegeben werden kann. Ein Ausdruck der Form SELECT Column FROM Aspect.Value ist beispielsweise nicht zulassig. Dies gilt sowohl fur Microsoft SQL Server 20051 als auch fur Oracle 11g2. Wird eine derartige Dynamik dennoch benotigt, lasst sich diese nur uber eine Stored Procedure, vorgeschalteten Anwendungscode oder im Fall von Oracle unter Verwendung von XML realisieren.

3.3 SQL mit Spracherweiterung

Aufgrund der fehlenden Normierung des PIVOT-Operators einerseits und dessen Nutzungs-Einschrankungen im Kontext der Aspektorientierten Datenhaltung andererseits, verfolgt dieser Abschnitt die Idee einer SQL-Erweiterung fur einen adaquaten Zugri auf funktionale Aspekte im Referenzmodell. Die neuen Sprachelemente beein ussen sowohl den DML-Teil als auch den DDL-Bereich, um beispielsweise fur eine Tabellenspalte relevante Aspekte de nieren zu konnen. Hier soll jedoch aus Platzgrunden nur das SELECTStatement im Fokus stehen. <table reference> ::=

<table name> [ <correlation specification> ] | <derived table> <correlation specification> | <joined table> | <aspect view> <aspect view> ::=

ASPECTVIEW <identifier> BASED ON <table name>

GROUP BY <aspect key> [{, <aspect key>} ... ] <aspect key> ::=

ASPECTKEY(<character string literal>)

AS <identifier>

Abbildung 5: SQL-Erweiterung ASPECTVIEW Aufbauend auf dem SQL:92-Standard[ 6 ] wird das Nichtterminalsymbol <table reference>3 um eine weitere Alternative <aspect view> erganzt, deren De nition in Abbildung 5 dargestellt ist. Das neue Schlusselwort ASPECTVIEW erzeugt dabei eine Sicht auf alle aspektspezi schen Daten der uber BASED ON angegebenen (fachlichen) Basistabelle. Da es moglich ist, einer Tabellenspalte verschiedene Aspekte zuzuordnen, erfolgt die Aufbereitung der Daten in gruppierter Form bezuglich des einattributigen Primarschlussels[ 11 ] und der uber <aspect key> spezi zierten Aspekte. Diese stehen anschlie end im Rahmen der Anfrageformulierung als regulare Attribute der Sicht zur Verfugung, fur eine Tabelle mit n Attributen und insgesamt k zugeordneten Aspekte ergibt sich also das in Abbildung 6 dargestellte Relationsschema. Voraussetzung hierfur ist eine im Referenzmodell ver1http://msdn.microsoft.com/en-us/library/ms177634.aspx 2http://download.oracle.com/docs/cd/B28359_01/server.111/b28286/ statements_10002.htm#CHDFAFIE 3http://savage.net.au/SQL/sql-92.bnf ankerte UNIQUE-Bedingung auf Aspect.Definition.Key, dessen Werte uber den Ausdruck ASPECTKEY(<character string literal>) referenziert werden. der Aspekte inklusive ihrer Metadaten als auch zur Abfrage und Anderung aspektspezi scher Attributwerte unter Beachtung sogenannter Aspekt lter und Aspektkontexte.

Basistabelle Aspekte (zAtt1; :}:|: ; Attn{ ;zAsp1; : : : ; Aspk{) }| Abbildung 6: Relationsschema von ASPECTVIEW Angewendet auf das in Abbildung 2 skizzierte Beispiel ergibt sich eine gegenuber den bisherigen Zugri stechniken sehr kompakte Anfrage, wie Abbildung 7 zeigt. Neben dem Aufwand zur Pivotisierung fur die Aspektsicht T1 ist unabhangig von der Anzahl der Attribute oder Aspekte nur noch eine JOIN-Operation erforderlich, um fur die Idents in Aspi die eigentlichen Aspektschlusselwerte anzeigen zu konnen.

SELECT T1.Name, T1.Preis, T2.KeyValue AS Locale

FROM Aspect.KeyValue T2 INNER JOIN (

ASPECTVIEW ModulAspects

BASED ON Demo.Modul

GROUP BY ASPECTKEY('Locale') AS AspLoc ) T1 ON T2.AspKeyID = T1.AspLoc WHERE T1.TeilNr = 4711

AND T2.Aspect = 1 -- /*'Mehrsprachigkeit'*/ Abbildung 7: Anfrage mit ASPECTVIEW m m a r g o r p s g n u d n e w n A

JDBC−Schnittstelle Funktionsbaustein ("Aspekt−API")

DB (inkl. Referenz− modell)

Abbildung 8: Anwendungs-Integration der API Um einen moglichst plattformunabhangigen und universellen Funktionsbaustein bereitstellen zu konnen, ist dieser inklusive seiner API in Java spezi ziert. Da in den meisten Fallen bei Verwendung einer Java-Bibliothek das umgebende Anwendungsprogramm ebenfalls auf Java basiert und fur Datenbankzugri e die JDBC-Schnittstelle genutzt wird, zeigt Abbildung 8 ein typisches Integrations-Szenario. Dabei konnen in einer ersten Ausbaustufe uber die API tatsachlich nur aspektspezi sche Daten abgefragt und geandert werden, die Verarbeitung der fachlichen Daten erfolgt unverandert uber die bereits existierende Datenbank-Schnittstelle. Aufgabe der Anwendung ist damit also die Zusammenfuhrung der Ergebnisse beider Datenquellen, abhangig naturlich von den inhaltlichen Anforderungen.

1 // Deklarationen

AspectManager am = /* Verweis auf Instanz holen */ 3 AspectCatalogManager acm =

am.getAspectCatalogManager(); 5 int aspLang = acm.lookupAspectID("Language");

int tID = acm.lookupTableID("Demo","Modul"); 7 int cNameID = acm.lookupColumnID(tID, "Name"); int cPriceID = acm.lookupColumnID(tID, "Preis"); Sollte sich eine derartige Spracherweiterung wie angedeutet fur alle Bereiche (DDL und DML) als geeignetes Ausdrucksmittel im Umgang mit funktionalen Aspekten beweisen, bleibt die praktische Nutzung stark eingeschrankt, so9 lange eine Umsetzung in SQL-Norm oder DBMS-Produkten // Anfragespezifikation fehlt. In solch einem Szenario kann der Einsatz sogenann- 11 QueryStatement st = am.createQueryStatement(tID); ter Proxys[ 1 ] oder Query Transformation Layer[ 2 ] zwischen st.setRowIDs(new long[] {4711}); Anwendung und Datenbank eine Losung darstellen. Im vor- 13 st.setColumnSet(am.createColumnSet( liegenden Fall mussten alle neu de nierten SQL-Ausdrucke, new int[] {cNameID, cPriceID})); beispielsweise ASPECTVIEW, durch einen Parser auf e ziente 15 Art und Weise in genormte oder produktspezi sche SQLAnweisungen transformiert werden. Damit ware zumindest eine benutzerfreundliche Schnittstelle im Umgang mit funktionalen Aspekten unter Nutzung der trivialen Umformung (Anfrage mit JOIN, siehe Abschnitt 3.1) gescha en. Die nachfolgend beschriebene Zugri stechnik ist ebenfalls ein Vertreter dieser Kategorie, allerdings erfolgt die Anfrageformulierung nicht auf Basis von SQL.

// Ergebnisverarbeitung 17 ResultRows result = st.execute();

AspectSet aSet = st.getAspectSet(); 19 ColumnSet cSet = st.getColumnSet();

int aspLangIdx = aSet.getIndex(aspLang); 21 int cNameIdx = cSet.getIndex(cNameID);

int cPriceIdx = cSet.getIndex(cPriceID); 23 while (result.next()) { 3.4 Funktionsbaustein mit API 25 Gegenuber den bisher vorgestellten Moglichkeiten, den Zugri auf funktionale Aspekte allein mit SQL-Mitteln auf der 27 Persistierungsebene zu realisieren, wird mit dem vierten Ansatz eine applikationsseitige Verarbeitung verfolgt. Analog 29 zum Konzept mit JDBC[ 9 ] eine einheitliche Schnittstelle fur relationale Datenbanken zu etablieren, ermoglicht der hier 31 } vorgestellte Funktionsbaustein den Zugri auf funktionale Aspekte, welche im Referenzmodell persistiert sind. Die zugehorige API[ 16 ] umfasst Methoden sowohl zur Verwaltung long rowID = result.getRowID(); AspectContextElement e =

result.getContext().getElement(); String name = result.getValueString(cNameIdx); String price = result.getValueString(cPriceIdx); int localeID = e.getIndexKeyValue(aspLangIdx);

Abbildung 9: Anfrage mit Funktionsbaustein Eine Abfrage aspektspezi scher Daten wie fur das ReferenzBeispiel wird prinzipiell durch das in Abbildung 9 dargestellte Code-Fragment realisiert. Der Einstieg erfolgt mit einer implementierungsspezi schen Instanz der zentralen Klasse AspectManager (Zeile 2), welche im nachsten Schritt zur Erzeugung einer AspectCatalogManager-Instanz benotigt wird und zudem auch fur die Verwaltung einer Datenbank-Session zustandig ist. Schlie lich werden zum Aspekt Mehrsprachigkeit sowie fur die Attribute Name und Preis der Tabelle Modul die Idents ermittelt (Zeilen 5-8). Hierfur konnen entsprechende Methoden an der Aspektkatalogmanager-Klasse genutzt werden, damit sind alle fur die Anfrage notwendigen Metadaten bekannt.

Fur die Anfragespezi kation wird uber den AspectManager eine Instanz der Klasse QueryStatement angelegt (Zeile 11).

Da in der relevanten Fachtabelle Demo.Modul das Attribut TeilNr bereits die Anforderung eines einattributigen Primarschlussels erfullt, entspricht die Filterung mit der Methode setRowIDs in Zeile 12 genau der Einschrankung auf das Modul mit TeilNr=4711 in einer WHERE-Klausel. Die zu projezierenden Spalten werden analog in Zeile 13 festgelegt. Weitere zusatzliche aspektspezi sche Beschrankungen beispielsweise uber die AspectFilter-Klasse entfallen, da alle mehrsprachigen Daten fur die Attribute Name und Preis bereitzustellen sind.

Die Ausfuhrung der Anfrage erzeugt ein ResultRows-Objekt (Zeile 17), welches analog zum entsprechenden Konstrukt in JDBC zeilenweise uber den next-Iterator verarbeitet werden kann (Zeile 23). Zuvor sind fur die korrekte Auswertung der Ergebnisstruktur die darin enthaltenen Indexe des Mehrsprachigkeits-Aspekts sowie der beiden angefragten Attribute zu ermitteln (Zeilen 18-22). Mit Hilfe dieser Indexe kann nun auf die entsprechenden Informationen zugegriffen werden (Zeilen 25-29). Weiterfuhrende Details zu Datenstrukturen, Klassen und Methoden sowie zu deren Verwendung nden sich bei Pietsch[ 16 ].

4. VERGLEICH

Nachdem der vorangegangene Abschnitt 3 die unterschiedlichen Zugri stechniken prasentiert hat, dient dieser Abschnitt der Bewertung und dem Vergleich jener Techniken. Zuerst werden die dafur notwendigen Kriterien im Folgenden beschrieben und anschlie end fur jeden Ansatz evaluiert.

4.1 Kriterien

Ausgehend vom Paradigma der Aspektorientierten Datenhaltung spiegelt sich die Forderung nach Universalitat[ 11 ] bezuglich SQL:92 im Kriterium der Standardisierung wider, welches hier jedoch auch bezuglich der Existenz einer ISO-Norm erweitert werden soll. In direktem Zusammenhang dazu stellt sich die Frage der Praxisrelevanz eines Ansatzes, d.h. ob mit diesem der Zugri auf funktionale Aspekte unter den aktuellen Gegebenheiten uberhaupt praktisch realisierbar ist. Eine gro e Bedeutung spielen naturlich auch Ausagen zur Performance, allerdings liegen nur fur den ersten Ansatz (SQL mit JOIN) tatsachlich konkrete Messwerte[ 13 ] vor, sodass fur alle anderen Varianten nur eine qualitative Abschatzung moglich ist. Inwieweit die Strukturen des Referenzmodells zur Persistierung funktionaler Aspekte dem Nutzer bzw. der Anwendung im Rahmen der Verarbeitung bekannt sein mussen oder verborgen bleiben konnen, zeigt sich in der Transparenz einer Technik. Weiterhin wird gepruft, ob im jeweiligen Ansatz auf die bereits vorhandene Machtigkeit eines zu Grunde gelegten RDBMS in angemessener Weise zuruckgegriffen wird (Funktionsadaquatheit) oder ob Funktionalitat, wie beispielsweise das Parsen von Sprachausdrucken und das Caching von Daten, reimplementiert werden muss. Hierbei spielen auch prinzipielle Moglichkeiten zur Erweiterbarkeit des Funktionsumfangs eine Rolle, erwartungsgema werden diese durch Standardisierung beschrankt. Schlie lich soll noch mit der Benutzerfreundlichkeit beurteilt werden, wie sich letztlich die gesamte Auswertung funktionaler Aspekte fur den Anwendungsentwickler darstellt.

4.2 Bewertung

Eine detaillierte Bewertung jeder einzelnen Zugri stechnik bezuglich der zuvor aufgestellten Kriterien kann hier aus Platzgrunden nicht beschrieben werden. Stattdessen enthalt Tabelle 1 einen Uberblick mit den Ergebnissen. g n u r e i s m i iitrreuK traaddnS z n a v e l e r s i x a r P e c n a m r o f r e P z n e r a p s n a r T t i e h t a u q a d a s n o i t k n u F

Zugri stechnik

JOIN PIVOT ASPECTVIEW API + : ja/hoch + + { { o1 o1 o o { o3 o + o2 + +4 + o : neutral/mittel + { + { o3 + { + { : nein/niedrig t i e k r a b r e t i e w r E { o + o t i e k h c i l d n u e r f r e z t u n e B

Tabelle 1: Bewertung der Zugri stechniken Dabei fallt auf, dass zwar der JOIN-Ansatz (Abschnitt 3.1) als einziger Vertreter auf standardisierte Sprachkonstrukte zuruckgreift und damit eine gro e Praxisrelevanz bzw. Produktunterstutzung besitzt, allerdings weder performant noch benutzerspezi sch erweiterbar ist. Zudem erzwingt die Nutzung des Verbund-Operators genaue Kenntnisse uber die Aspekt-Tabellen, wodurch die Transparenz und Benutzerfreundlichkeit verloren geht.

Dagegen verspricht die PIVOT-Methode (Abschnitt 3.2) sowohl den transparenteren Zugang als auch eine performantere Verarbeitung der aspektspezi schen Daten in den EAVTabellen[ 5 ]. Dennoch fehlt hier ebenfalls die Moglichkeit zur Erweiterbarkeit, zudem ist die Anwendbarkeit aufgrund der (noch) fehlenden Normierung an Hersteller wie Oracle oder Microsoft und deren DBMS-Produkte gekoppelt. Ahnliche Charakteristik besitzt auch der ASPECTVIEWVorschlag (Abschnitt 3.3), er soll jedoch als Erweiterung von SQL die Konsequenzen der Aspektorientierten Datenhaltung berucksichtigen. Daher ist der praktische Einsatz momentan nur uber die genannten Zwischenschichten realisierbar. Andererseits wird dem Anwendungsentwickler ein intuitives und adaquates Konstrukt zur Verfugung gestellt, um transparent auf funktionale Aspekte von Fachtabellen zugreifen zu konnen.

Schlie lich ergibt sich fur den API-Ansatz (Abschnitt 3.4) eine mindestens ebenso gute oder bessere Bewertung gegenuber den anderen Zugri stechniken in vielen Kriterien, insbesondere ist ein performanter Aspekt-Zugri moglich. Der fehlenden Standardisierung lasst sich z.B. durch Portierung auf die gangigsten Programmiersprachen begegnen. Gro er Aufwand ist zudem notwendig, um der Machtigkeit von SQL auf Seiten der API gerecht zu werden.

5. ZUSAMMENFASSUNG

Der vorliegende Beitrag hat vier verschiedene Techniken fur den Zugri auf funktionale Aspekte aufgezeigt, welche im Kontext der Aspektorientierten Datenhaltung uber ein ebenfalls kurz beschriebenes Referenzmodell auf relationalen Datenbanken abgebildet werden konnen. Durch die Fokussierung auf RDBMS und deren hohen Verbreitungsgrad ist die Grundlage fur den praktischen Einsatz gewahrleistet. Die anschlie ende Bewertung anhand zuvor aufgestellter Kriterien sollte weitere Klarheit uber die Potentiale der einzelnen Ansatze liefern. Dabei hat sich herausgestellt, dass vor allem fur eine performante und transparente Auswertung funktionaler Aspekte die standardisierten Mittel von SQL nicht ausreichen.

Unter den moglichen Alternativen erscheinen der Vorschlag zur Erweiterung von SQL mit ASPECTVIEW und die applikative Verarbeitung in einem Funktionsbaustein vielversprechend. Dabei ist der Aufwand zur Erweiterung der SQLNorm ungleich hoher und nicht automatisch von Erfolg gekront bzw. wie bereits vorgeschlagen nur durch Implementierung einer transformierenden Zwischenschicht praktikabel. Aus diesem Grund werden sich nachfolgende Arbeiten vor allem der prototypischen Realisierung, quantitativen Performance-Vergleichen sowie funktionellen Weiterentwicklungen bezuglich aktueller Einschrankungen der vorgestellten API fur funktionale Aspekte widmen.

References

1 unterstutzt durch Oracle 11g und MS SQL Server 2005

2 de-facto Standard[8] aufgrund enormer Verbreitung

3 nur bei Nutzung von Zwischenschichten[1 , 2]

4 begrundet durch Ergebnisse in [7] 6 . LITERATUR

[1] A. Adam , S. Leuoth , and W. Benn . Nutzung von Proxys zur Erganzung von Datenbankfunktionen . In Proceedings of the 22nd GI Workshop Grundlagen von Datenbanken (GvDB 2010 ), pages 31 { 35 , Bad Helmstedt , Germany, May 2010 .

[2] S. Aulbach , T. Grust , D. Jacobs , A. Kemper , and J. Rittinger . Multi-tenant databases for software as a service: schema-mapping techniques . In SIGMOD Conference , pages 1195 { 1206 , 2008 .

[3] R. Chitchyan , I. Sommerville, and A. Rashid . An Analysis of Design Approaches for Crosscutting Concerns . In Workshop on Aspect- Oriented Design (held in conjunction with the 1st Aspect Oriented Software Development Conference (AOSD 2002 ), 2002 .

[4] E. F. Codd . A relational model of data for large shared data banks . CACM , 13 ( 6 ): 377 { 387 , 1970 .

[5] C. Cunningham , G. Graefe, and C. A. Galindo-Legaria . PIVOT and UNPIVOT: Optimization and Execution Strategies in an RDBMS . In (e)Proceedings of the 30th International Conference on Very Large Data Bases (VLDB 2004 ), pages 998 { 1009 , 2004 .

[6] C. Date and H. Darwen. SQL - Der Standard . SQL/92 mit den Erweiterungen CLI und PSM. Addison-Wesley , 1998 .

[7] V. Dinu , P. Nadkarni , and C. Brandt . Pivoting approaches for bulk extraction of Entity-Attribute-Value data . Computer Methods And Programs in Biomedicine, 82 ( 1 ): 38 { 43 , 2006 .

[8] T. Egyedi . Why Java Was Not Standardized Twice. Hawaii International Conference on System Sciences , 5 ( 1 ): 5015 { 5025 , 2001 .

[9] M. Fisher , J. Ellis, and J. Bruce. JDBC API Tutorial and Reference (Java Series) . Addison-Wesley , 2003 .

[10] ISO/IEC 9075-2: 2008 . Information technology { Database languages { SQL { Part 2: Foundation (SQL/Foundation) . ISO, Geneva, Switzerland, 2008 .

[11] M. Liebisch. Aspektorientierte Datenhaltung - ein Modellierungsparadigma . In Proceedings of the 22nd GI Workshop Grundlagen von Datenbanken (GvDB 2010 ), pages 13 { 17 , Bad Helmstedt , Germany, May 2010 .

[12] M. Liebisch . Supporting functional aspects in relational databases . In Proceedings of the 2nd International Conference on Software Technology and Engineering (ICSTE 2010 ), pages 227 { 231 , San Juan , Puerto Rico, USA, Oct. 2010 .

[13] M. Liebisch and M. Plietz . Performance-Analysen fur Realisierungsansatze im Kontext der Aspektorientierten Datenhaltung . Institut fur Informatik, Friedrich- Schiller-Universitat Jena, Nov. 2010 .

[14] D. Lorentz . Oracle Database SQL Language Reference 11g Release 1 . Oracle , Aug. 2010 .

[15] P. Nadkarni , L. Marenco , R. Chen , E. Skoufos, G. Shepherd, and P. Miller . Organization of Heterogeneous Scienti c Data Using the EAV/CR Representation . In JAMIA, 6 , pages 478 { 493 , 1999 .

[16] B. Pietsch . Entwurf einer Zugri sschicht fur funktionale Aspekte in DBMS . Studienarbeit, Institut fur Informatik, Friedrich- Schiller-Universitat Jena, Mar. 2011 .

[17] A. B. Rashid and M. Islam . Role of Materialized View Maintenance with PIVOT and UNPIVOT Operators . In Proceedings of the 1st IEEE International Advance Computing Conference (IACC 2009 ), pages 915 { 955 , Mar . 2009 .

[18] T. Rizzo , A. Machanic , and J. Skinner . Pro SQL Server 2005 . Apress, 2005 .

[19] T. Schilling . Realisierungskonzepte fur die Aspektorientierte Datenhaltung . Studienarbeit, Institut fur Informatik, Friedrich- Schiller-Universitat Jena, Apr. 2011 .

[20] C. M. Wyss and E. L. Robertson . A formal characterization of PIVOT/UNPIVOT . In Proceedings of the 14th ACM international conference on Information and knowledge management , pages 602 { 608 , 2005 .