Datenhaltung in Produktkon guratoren
Werbung
Friedrich-Schiller-Universität Jena Fakultät für Mathematik und Informatik Lehrstuhl für Datenbanken und Informationssysteme Prof. Dr. Klaus Küspert Seminar Datenhaltung in Produktkonguratoren von Grundlagen bis Aspektorientierung Sommersemester 2010 Thema 5: Referenzmodellierung Bearbeiter: Alexander Zimmermann Betreuer: Matthias Liebisch II Inhaltsverzeichnis 1 Einleitung 1 2 Aspektorientierte Datenhaltung 2 3 Realisierungsansätze 3 3.1 Bisherige Realisierungsansätze . . . . . . . . . . . . . . . . . . . . 3 3.2 Neuer Realisierungsansatz . . . . . . . . . . . . . . . . . . . . . . . 4 4 Aspektintegration 5 Bewertung der Referenzmodellierung 6 8 10 5.1 Erfüllung der Anforderungen der Aspektorientierten Datenhaltung 10 5.2 Vor- und Nachteile bezüglich des verwendeten EAV-Konzeptes . . . 11 Fazit Literatur- und Quellenverzeichnis 12 14 1 1 Einleitung Zur Speicherung der Daten von Anwendungssystemen bilden Relationale Datenbanksysteme (RDBMS) ein wesentliches Grundprinzip. Bei der relationalen Datenbankmodellierung steht die Abbildung fachlicher Anforderungen im Vordergrund. Über die fachlichen Anforderungen hinaus sind häug jedoch auch sogenannte funktionale Aspekte abzubilden. Beispielsweise ist in dem Modell aus Abbildung 1 neben der dargestellten fachlichen Modellierung auch die Integration eines funktionalen Aspektes, wie etwa eine Internationalisierung (länderspezische Bezeichnungen, Preise und Währungen), denkbar. Solche funktionalen Aspekte lassen sich nicht einem konkreten fachlichen Objekt zuordnen, sondern haben vielmehr einen querschnittlichen Einuss auf weite Teile des Datenmodells und somit auf eine Vielzahl der modellierten Objekte. Mit herkömmlichen Methoden lassen sich funktionale Aspekte demnach nicht als eine logische Einheit modellieren, was eine Vermischung fachlicher und funktionaler Anforderungen zur Folge hat. Aufgrund der damit verbundenen Anpassung einer Vielzahl von Tabellen unterschiedlicher Domänen ist ein erhöhter Abstimmungsaufwand notwendig. Darüber hinaus sind entsprechende Modelle schwer nachvollziehbar sowie schlecht wiederverwendbar und erfordern einen erhöhten Wartungsaufwand der einzelnen Modellierungseinheiten. [Lie 10] MODUL TeilNr Bezeichnung ... ... Preis ... MODULSTRUKTUR ID Oberteil Unterteil ... ... ... Währung ... Menge ... Flags ... Einheit ... Modellierung von Modulpaketen (Stückliste) mit den Integritätsbedingungen: • MODULSTRUKTUR.Oberteil sowie MODULSTRUKTUR.Unterteil sind jeweils Fremdschlüssel bezüglich MODUL.TeilNr • UNIQUE-Bedingung auf (MODULSTRUKTUR.Oberteil, MODULSTRUKTUR.Unterteil) Abbildung 1: Referenzbeispiel Quelle: [Lie 10]. 2 2 Aspektorientierte Datenhaltung Um die beschriebenen Probleme bei der Integration funktionaler Aspekte zu vermeiden, wird eine Datenmodellierung benötigt, die eine weitgehende Trennung (Modularisierung) sowohl der fachlichen als auch der funktionalen Anforderungen ermöglicht. Das Prinzip der Aspektorientierten Datenhaltung verfolgt demnach eine Integration funktionaler Aspekte unabhängig von dem zugrundliegenden fachlichen Datenmodell. Nach [Lie 10] verfolgt das Paradigma der Aspektorientierten Datenhaltung folgende Eigenschaften: Modularität: Alle aspektspezischen Informationen werden zu einer logischen Modellierungseinheit (beispielsweise Tabellen im relationalen Modell) zusammengefasst und sind somit getrennt von der fachlichen Abbildung integrierbar. Lokalität: Durch Integration eines Aspekts sollen Änderungen am Datenmodell möglichst geringfügig ausfallen und nur an den notwendigen Stellen stattnden. Orthogonalität: Unabhängig von der Reihenfolge, in der verschiedene Aspekte in ein gegebenes Datenmodell integriert werden, muss dieses in einen semantisch äquivalenten Zustand überführt werden. Auÿerdem dürfen keine Wechselwirkungen zwischen Aspekten entstehen, wenn diese gleiche Attribute beeinussen. Universalität: Das Modellierungskonzept ist nicht auf einen konkreten An- wendungsfall beschränkt. Dazu werden ausschlieÿlich Konzepte betrachtet, die den SQL:92-Standard verwenden, welcher auch zur Modellierung realer DBMSProdukte genutzt wird. Benutzbarkeit: Ein existierendes oder zu entwickelndes Datenmodell soll sich einfach um funktionale Aspekte erweitern lassen. Dazu ist eine Unterstützung des Nutzers durch einen Integrationsassistenten notwendig, welcher nach Abfrage anwendungsspezischer Informationen die eigentlichen Transformationen am Datenmodell vornimmt. 3 3 Realisierungsansätze Zunächst werden einige bisherige Realisierungsansätze zur Integration funktionaler Aspekte kurz vorgestellt. Dabei wird verdeutlicht, warum diese die in Abschnitt 2 aufgestellten Anforderungen jeweils nicht vollständig erfüllen. Anschlieÿend wird ein neuartiges Konzept zur Aspektorientierten Datenhaltung erläutert, welches sich einzelne Vorteile der bisherigen Ansätze zu Nutze macht und einen geeigneten Realisierungsansatz für das Paradigma der Aspektorientierten Datenhaltung darstellt. 3.1 Bisherige Realisierungsansätze Schlüsselerweiterung: Der Primärschlüssel in der betroenen Tabelle wird um eine Spalte erweitert, die die jeweilige Aspektausprägung des Objektes repräsentiert. Es wird somit eine Replizierung aller Objekte für den jeweiligen Aspekt vorgenommen. In diesem Ansatz verschmelzen die aspektspezischen Informationen mit den fachlichen Abbildungen des eigentlichen Datenmodells, was v. a. eine Verletzung der Modularität zur Folge hat. Schattentabelle: Das Prinzip der Schattentabelle ist ähnlich wie das der Schlüsselerweiterung, nur dass die Ursprungstabelle unbeeinusst bleibt. Stattdessen wird eine zusätzliche, sogenannte Schattentabelle angelegt, die für die betroenen Objekte die aspektspezischen Informationen speichert. Das Schema der Schattentabelle enthält nur diejenigen Attribute, die von dem Aspekt betroen sind. Das wesentliche Problem diese Ansatzes besteht darin, dass eine Schattentabelle immer nur einen Aspekt beinhalten kann, wodurch es bei Integration mehrerer Aspekte (was nur über mehrere Schattentabellen möglich ist) zu einer Verletzung der Orthogonalität kommt. Realisierungsansätze Partitionierung: 4 Der Ansatz der Partitionierung verfolgt eine Aufteilung der Daten. Die aspektunabhängigen Daten verbleiben in der Originaltabelle während die aspektabhängigen Daten in eine neue Tabelle ausgegliedert werden. Aufgrund der Ausgliederung von Attributen und den damit verbundenen Eingri in das Datenmodell liegt auch bei diesen Ansatz eine Verletzung der Modularität vor. Zudem ist das resultierende Datenmodell abhängig von der Integrationsreihenfolge der Aspekte (Verletzung der Orthogonalität). Dynamisierung: Wie bei der Partitionierung werden die aspektabhängigen Da- ten in eine separate Tabelle ausgegliedert. Diese werden dabei nach dem Prinzip von Entity-Attribute-Value (EAV) in gekippter Form abgelegt (siehe Abschnitt 3.2). Auch hier wird ein massiver Eingri in das ursprüngliche Datenmodell vorgenommen, was den Forderungen nach Modularität widerspricht. Desweiteren kann die Integration eines zusätzlichen Aspekts eine komplette Transformation der Attribute nach sich ziehen (Verletzung der Lokalität) und Wechselwirkungen zwischen Aspekten sind nicht auszuschlieÿen (Verletzung der Orthogonalität). 3.2 Neuer Realisierungsansatz Ähnlich wie der Ansatz der Dynamisierung (vgl. Abschnitt 3.1) baut der hier erläuterte Ansatz auf dem EAV-Konzept auf. Das Grundprinzip des EAV-Konzeptes ist die Modellierung von Informationen in drei Tabellen: Entity, Attribute und Value. Im Gegensatz zur üblichen Datenmodellierung werden die Attribute eines Objekts dabei nicht als Spalten in einer Tabelle abgebildet, sondern in gekippter Form als Zeilen in der Tabelle Value gespeichert. Jede Zeile der Value-Tabelle beinhaltet demnach die Wertausprägung, die ein konkretes Objekt hinsichtlich eines bestimmten Attributes besitzt. Die Zuordnung der Wertausprägung zu einem konkreten Objekt sowie des Attributes, zu dem das Objekt die entsprechende Wertausprägung besitzt, ndet über Fremdschlüssel mit Referenz zu den Tabellen Entity und Attribute statt. [DNB 06, Nad 99] Realisierungsansätze 5 Der groÿe Vorteil des EAV-Konzeptes hinsichtlich der Abbildung funktionaler Aspekte besteht darin, dass durch Aufnahme weiterer (in diesem Fall aspektspezischer) Attribute keine Schema-Evolution notwendig ist, da diese einfach als zusätzliche Zeilen in der Attribute-Tabelle gespeichert werden. [Gan 00] Eine direkte Anwendung des EAV-Konzeptes zur Modellierung funktionaler Aspekte würde jedoch zwei wesentliche Probleme mit sich bringen. Zum einen würde eine nachträgliche Umstellung eines bereits existierenden fachlichen Datenmodells einen massiven Eingri in dieses bedeuten. Zum anderen müsste zur Abbildung mehrerer Aspekte die EAV-Tabelle um den Aspektschlüssel erweitert werden. Die Unabhängigkeit der funktionalen Aspekte wäre somit zwar gewährleistet, allerdings können einzelne Aspekte nicht unabhängig voneinander integriert bzw. wieder entfernt werden. Um dem Paradigma der Aspektorientierten Datenhaltung gerecht zu werden, werden deswegen folgende Anpassungen vorgenommen: Bei der Aspektintegration bleibt die betroene fachliche Tabelle unverändert. Die von dem Aspekt beeinussten Attribute werden zusätzlich in weiteren Tabellen persistiert. Dies entspricht dem Prinzip der Schattentabelle (vgl. Abschnitt. 3.1), mit dem Unterschied, dass die aspektspezischen Informationen über das EAVKonzept abgebildet werden. Somit ist die Forderung nach Modularität gesichert und gleichzeitig können die Vorteile des EAV-Konzeptes genutzt werden. Um eine unabhängige Integration bzw. Elimination einzelner Aspekte zu unterstützen, muss vermieden werden, dass der Aspektschlüssel einen Teil des Schlüssels der EAV-Tabelle darstellt. Dies lässt sich durch eine Auslagerung der Aspektinformationen in eine separate Tabelle realisieren, sodass die aspektspezischen Attributwerte über eine Fremdschlüsselrelation den einzelnen Aspekten zugeordnet werden. Die genaue Ausgestaltung dieses Vorgehens wird am besten anhand des folgenden Referenzmodells für das Paradigma der Aspektorientierten Datenhaltung deutlich. Im Folgenden ist dieses Konzept auf das in Abbildung 1 vorgestellte Referenzbeispiel angewendet. Zur besseren Übersichtlichkeit wurde die Tabelle MODULSTRUKTUR dabei ausgeblendet. Realisierungsansätze 6 MODUL TeilNr Bezeichnung Preis Währung Flags 19780 20080 ... Schraube Kabel ... 0.75 0.10 ... EUR EUR ... AspectDenition AspDefID Name 1 2 ... Internationalisierung Versionierung ... AspectValue AspValID TabID RowID AttID 101 102 103 104 105 106 107 108 ... Modul Modul Modul Modul Modul Modul Modul Modul ... 19780 19780 19780 19780 20080 20080 20080 19780 ... Bezeichnung Preis Bezeichnung Preis Bezeichnung Bezeichnung Bezeichnung Preis ... 00110101 00110011 ... KeyVal Lokale Revision ... Value TypeID screw 0.45 bullone 0.78 X-Kabel Y-Kabel Z-Kabel 0.43 ... CHAR DEC CHAR DEC CHAR CHAR CHAR DEC ... us us it us us us us AspectAssign AspAssID AspDefID AspValID Value 1001 1002 1003 1004 1005 1006 1007 1008 ... 1 1 2 2 2 1 1 1 ... 101 102 105 106 107 106 103 104 ... us us 1 2 3 at it it ... Zusätzliche Integritätsbedingungen: • Unique-Bedingung in AspectValue über (TabID, RowID, AttID, Value, TypeID) • Unique-Bedingung in AspectAssign über (AspDefID, AspValID, Value) • AspectAssign.AspDefID ist Fremdschlüssel bezüglich AspectDenition.AspDefID • AspectAssign.AspValID ist Fremdschlüssel bezüglich AspectValue.AspValID Abbildung 2: Referenzmodell Quelle: [Lie 10]. Realisierungsansätze 7 Abbildung 2 veranschaulicht das resultierende Datenmodell. Im Mittelpunkt des Realisierungsansatzes stehen die drei (Aspekt-) Verwaltungstabellen AspectDenition, AspectValue und AspectAssign, die auf dem EAV-Konzept beruhen. Die Tabelle MODUL stellt die fachliche Tabelle des eigentlichen Datenmodells dar. Diese bleibt nach dem Prinzip der Schattentabelle unbeeinusst von der Aspektintegration. Voraussetzung für das beschriebene Konzept sind einattributige typgleiche Primärschlüssel, welche sich jedoch bei fehlender Existenz jederzeit durch Einführung eines zusätzlichen künstlichen Schlüssels erzeugen lassen. [Lie 10] AspectDenition: Diese Tabelle beinhaltet alle Stammdaten der funktionalen Aspekte, wie bspw. die Bezeichnung (Name) und eine Beschreibung der Schlüsselwerte (KeyVal). Die separate Abbildung der Aspekte dient der Kapselung dieser, um sie voneinander unabhängig in das Datenmodell integrieren bzw. aus diesem entfernen zu können. In dem Beispiel aus Abbildung 2 sind die Aspekte Internationalisierung und Versionierung hinterlegt. Es ist ersichtlich, dass das Modell beliebig um zusätzliche Aspekte erweitert werden kann, bzw. auch die Möglichkeit besteht, einzelne Aspekte problemlos wieder zu entfernen. AspectValue: Die AspectValue-Tabelle bildet die eigentlichen Informationen der fachlichen Datenobjekte bezüglich funktionaler Aspekte ab. Für eine bestimmte, vom Aspekt betroene Tabelle (TabID) wird zu einem konkreten Attribut (AttID) eines Objektes (RowID) der neue, aspektspezische Wert (Value) hinterlegt. Dabei muss der Datentyp des Wertes so allgemein wie möglich sein (VARCHAR), da verschiedenste Attribute referenziert werden und diese durchaus unterschiedliche Datentypen haben können. Diese untypisierte Speicherung würde allerdings einen Informationsverlust bedeuten, deswegen wird die Typinformation zusätzlich im Feld TypeID persistiert. Da ein Objekt durchaus für mehrere Aspekte dieselbe aspektspezische Information besitzen kann, ndet die Zuordnung der Wertausprägungen zu dem jeweiligen Aspekt nicht innerhalb dieser Tabelle statt, da es sonst zu einer redundanten Speicherung der Informationen mit den damit verbundenen Nachteile kommen 8 würde. Stattdessen erfolgt die Zuordnung zu Aspekten in der Tabelle AspectAssign, getrennt von der Speicherung der aspektspezischen Informationen. Dadurch können Wechselwirkungen zwischen den Aspekten ausgeschlossen werden. Zudem ist die Abbildung von mehr als einem Aspekt auf einem Attribut möglich, indem mehrere Aspektschlüssel dem Attributwert zugeordnet werden können. Im Beispiel lässt sich aus der ersten Zeile der Tabelle AspectValue demnach erkennen, dass das Objekt mit der Teilnummer 19780 aus der Tabelle MODUL bezüglich eines bestimmten Aspektes für das Attribut Bezeichnung (mit der eigentlichen Wertausprägung Schraube) den Wert screw erhält. AspectAssign: In dieser Tabelle ndet die tatsächliche Zuordnung aspektspe- zischer Attributwerte zu den funktionalen Aspekten statt. Die Zuordnung erfolgt dabei über den Fremdschlüssel AspDefID. Dieser setzt sich aus einem konkreten Aspekt aus der Tabelle AspectDenition (AspDefID), dem aspektspezischen Attributwert aus der Tabelle AspectValue (AspValID) sowie der Aspektausprägung (Value) zusammen. Als Beispiel sagt der Datensatz mit der AspAssID = 1001 aus, dass für den Aspekt der Internationalisierung und der zugehörigen Aspektausprägung us das Objekt mit Teilnummer 19780 aus der Tabelle Modul für das Attribut Bezeichnung den Wert screw besitzt und dieser vom Typ CHAR ist. Anhand der Datensätze mit der AspAssID = 1004 und AspAssID = 1006 wird auch noch einmal die Einhaltung der Orthogonalität in dem Konzept ersichtlich, da in getrennter Zuordnung zwei unterschiedliche Aspekte auf dieselbe aspektspezische Information zugreifen. 4 Aspektintegration Neben einer geeigneten Modellierung erfordert das Paradigma der Aspektorientierten Datenhaltung auch eine Unterstützung des Nutzers durch einen Integrations-Assistenten. Diese Forderung ist vor allem im Zusammenhang mit dem vorgestellten Konzept zur Aspektmodellierung von besonderer Bedeutung, da dieses Konzept von der üblichen relationalen Datenmodellierung (Speicherung Aspektintegration 9 der Attribute als Spalten einer Tabelle) abweicht. Dies erschwert die Integration des Realisierungskonzepts in ein fachliches Datenmodell zusätzlich. [Nad 99] Für das vorgestellte Realisierungskonzept hat [Lie 10] folgenden Algorithmus für die wichtigsten Funktionalitäten aufgestellt, die ein Integrations-Assistent bereitstellen muss: 1. Festlegung der Verbindungsparameter zur Datenbank 2. Auswahl des zu integrierenden funktionalen Aspektes 3. Festlegung von Tabellen und den jeweiligen Attributen, welche für den zu integrierenden Aspekt im Sinne der zugrundeliegenden Anwendung relevant sind. Beispielsweise ist beim Aspekt der Internationalisierung unter anderem die Entscheidung zu treen, welche Tabellenattribute zukünftig übersetzbar (mehrsprachig) sein sollen 4. Optional: Erstellen eines Backups der Datenbank 5. Sicherstellung des einattributigen Primärschlüssels in allen gewählten Tabellen, gegebenenfalls durch Hinzufügen eines künstlichen Schlüssels 6. Erstellung der zum Realisierungskonzept gehörenden Verwaltungstabellen AspectDenition, AspectValue und AspectAssign. Existieren diese Tabellen bereits, so ist nur ein zusätzlicher Eintrag in der Tabelle AspectDenition für den neuen funktionalen Aspekt notwendig 7. Optional: Bereitstellung einer View für jede zu Beginn ausgewählte Tabelle, welche in Verbindung mit den aspektspezischen Verwaltungstabellen eine Gesamtsicht auf die fachlichen Objekte inklusive der zusätzlichen Daten zu den funktionalen Aspekten ermöglicht 10 5 Bewertung der Referenzmodellierung An dieser Stelle wird der vorgestellte Realisierungsansatz bewertet und nachgewiesen, dass dieser alle formulierten Anforderungen für das Paradigma der Aspektorientierten Datenhaltung erfüllt. Anschlieÿend werden Vor- und Nachteile diskutiert, die sich aus der Verwendung des EAV-Konzepts als Grundlage dieses Realisierungsansatzes ergeben. 5.1 Erfüllung der Anforderungen der Aspektorientierten Datenhaltung Der Kerngedanke des vorgestellten Realisierungsansatzes liegt in der Kapselung aller aspektspezischen Informationen in den drei Verwaltungstabellen (AspectDenition, AspectValue und AspectAssign), welche vollkommen isoliert von dem eigentlichen fachlichen Datenmodell sind. Somit ist zum einen die Modularität sicherstellt und zum anderen auch die Universalität des Ansatzes, da die Verwaltungstabellen lediglich auf atomaren Attributen mit einfachen Domänen sowie Fremdschlüsseln basieren. Auch die Forderung nach Lokalität ist erfüllt, da eine Änderung der fachlichen Tabellen höchstens im Rahmen der Bildung einattributiger Primärschlüssel notwendig ist. Orthogonalität ist gewährleistet, da einerseits aufgrund der gekippten Speicherung durch Hinzufügen oder Entfernen von Aspekten keine Schemaänderungen an den initial angelegten Verwaltungstabellen notwendig sind und somit semantische Äquivalenz bezüglich der Integrationsreihenfolge einer Menge von Aspekten besteht. Andererseits können Wechselwirkungen zwischen verschiedenen Aspekten wegen der separaten Speicherung aspektspezischer Informationen zu fachlichen Daten (AspectValue) und der tatsächlichen Zuordnung zu Aspekten (AspectAssign) ausgeschlossen werden. Der Forderung nach Benutzbarkeit wird schlieÿlich durch Bereitstellung eines wie in Abschnitt 4 beschriebenen Integrations-Assistenten nachgekommen. Bewertung der Referenzmodellierung 11 5.2 Vor- und Nachteile bezüglich des verwendeten EAV-Konzeptes Aufgrund des verwendeten Grundprinzips des EAV-Konzepts in Form einer gekippten Speicherung von Attributen in Zeilen ergeben sich bestimmte Vor- aber auch Nachteile. [Nad 99, Gan 00, DNB 06, Ber 10] Ein wesentlicher Vorteil des EAV-Konzepts ist die Flexibilität bei der Datenhaltung. Die Aufnahme weiterer Attribute schlägt sich lediglich in zusätzlichen Zeilen des bestehenden Datenmodells nieder. Für das Hinzufügen weiterer Aspekte sind somit keine Änderungen der Tabellenstruktur notwendig. Auÿerdem erfordert die Speicherung zusätzlicher aspektspezischer Attribute keine Schemaevolution der Value-Tabelle. Aus dieser Sicht kann die Datenbank beliebig wachsen, was aufgrund der beschränkten maximalen Spaltenanzahl vieler Datenbankprodukte sonst nicht ohne weiteres möglich wäre. Die modulare Abgrenzung zum fachlichen Datenmodell ist insofern unabhängig von der Anzahl der Aspekte und aspektspezischen Attributausprägungen stets gewährleistet. Desweiteren ist die Methode speicherplatzezient, v. a. für schwach besetzte Tabellen (sogenannte sparse datasets), da für nicht erfasste Merkmale eines Objektes kein Platz in Form von NULL-Werten reserviert werden muss, sondern für diese einfach keine Zeile angelegt werden. Im Hinblick auf die Abbildung funktionaler Aspekte ist dies von besonderen Vorteil, wenn viele Objekte von einzelnen Aspekten unbetroen sind (z. B. wenn nur ein Teil der Produkte eines Unternehmens im Ausland angeboten werden und somit mehrsprachig gehalten werden müssen). Nachteile des EAV-Konzepts ergeben sich primär bei der Performance für Datenzugrie. Aufgrund der komplexeren Struktur der Verwaltungstabelle sind bei 1 Desweiteren müssen für bestimmte Ap- Abfragen zusätzliche Joins erforderlich. plikationen (z. B. zur statistischen Auswertung) die Daten zunächst in eine relationale Form (eine Spalte je Attribut) gebracht werden. Letztlich wird die Performance durch die Haltung verschiedener Datentypen in der Value-Tabelle belastet. Da der Datentyp der Wertausprägung möglichst allgemein gehalten werden muss, 1 Bspw. ist die Abfrage einer einzigen kompletten Zeile im eigentlichen Datenmodell sehr einfach und schnell; in der EAV-Struktur jedoch vergleichsweise sehr schwierig und aufwendig. 12 um Informationen zu verschiedensten Attributen aufnehmen zu können, wird der eigentliche Datentyp wie erläutert in einer zusätzlichen Spalte persistiert. Dadurch ist zum einen stets eine Typkonvertierung bei der Abfrage aspektspezischer Attributausprägungen notwendig und zum anderen gehen einige Vorteile 2 des relationalen DBMS verloren. Darüber hinaus ergeben sich Probleme aufgrund der unüblichen Datenmodellierung und der damit verbundenen komplizierten Bedienung. Eine Unterstützung bei der Integration des Realisierungskonzepts sowie ein geeignetes EAV-System für Datenbankzugrie sind somit nahezu unumgänglich. Dies verursacht einerseits Aufwand und Kosten (durch interne oder externe Lösung), andererseits ist mit dieser zusätzlichen Schicht wieder eine Performanceverschlechterung verbunden. 6 Fazit Mit dem vorgestellten Realisierungsansatz wurde ein Modellierungskonzept präsentiert, welches die grundsätzlichen Anforderungen für das Paradigma der Aspektorientierten Datenhaltung erfüllt. Dabei wurde auch die Notwendigkeit für einen Assistenten zur Integrationsunterstützung verdeutlicht. Mit Hilfe dieses Ansatzes wird eine, von dem eigentlichen Datenmodell getrennte, Integration querschnittlicher Belange ermöglicht. Somit ndet bei der Abbildung funktionaler Aspekte keine Vermischung mit dem fachlichen Datenmodell statt, was eine bessere Strukturierung, Wartbarkeit und Wiederverwendbarkeit des Datenmodells bewirkt. Durch das in dem Realisierungsansatz verwendete EAV-Konzept ergeben sich über die Betrachtung der geeigneten Abbildung funktionaler Aspekte hinaus grundsätzliche Vor- und Nachteile. Daraus resultiert ein Zielkonikt zwischen dem Nutzen des Paradigmas der Aspektorientierten Datenhaltung sowie den Vorteilen der exiblen und ezienten Speicherung, und der Probleme, die v. a. in Form von schlechterer Performance und Bedienung auftreten. Aufgrund dieser Probleme 2 Z. B. können keine Suchindexe verwendet werden und die Sicherstellung der referentiellen Integrität von AspectValue.Value kann nicht auf Datenbankebene stattnden. Fazit 13 ndet das EAV-Konzept in der Praxis eher selten Anwendung. Allerdings gibt es typische Anwendungsfelder, wie etwa in medizinischen Dokumentationsanwendungen (z. B. Oracle Health ), welche einen charakteristischen Vertreter von (highly) sparse datasets darstellen [Ber 10]. Auch einzelne allgemeine DBMS-Produkte nutzen das EAV-Konzept, wie bspw. das Opensource e-Commerce-System [Mag 10]. Magento 14 Literatur- und Quellenverzeichnis [Ber 10] Bernhart, M.; Strobl, S.; Trabitsch, R.; Grünberger, J.; Suppersberger, M. (2010): Fallbeispiele von Projekten. In: Grechenig, T.; Bernhart, M.; Brei- teneder, R.; Kappel, K. (Hrsg.): Softwaretechnik Mit Fallbeispielen aus realen Entwicklungsprojekten, Pearson, München u. a., S. 101-138. [DNB 06] Dinu, V.; Nadkarni, P.; Brandt, C. (2006): extraction of Entity-Attribute-Value data. Pivoting approaches for bulk In: Computer Methods and Pro- grams in Biomedicine, 82, S. 38-43. [Gan 00] Ganslandt, T.; Krieglstein, C. F.; Müller, L.; Senninger, N.; Prokosch H.U. Elektronische Dokumentation in der Medizin: Flexible Konzepte versus Einzellösungen. In: Zentralblatt für Gynäkologie, 122, S. 445-452. (2000): [Lie 10] Liebisch, M. (2010): Aspektorientierte Datenhaltung - ein Modellierungspa- radigma. In: Tagungsband zum 22. Workshop Grundlagen von Datenbanken, Bad Helmstedt. [Mag 10] Magentocommerce.com (2010): Magento Database. Online im Internet unter: http://www.magentocommerce.com/wiki/development/magento_ database_diagram (letzter Zugri 26.05.2010). [Nad 99] Nadkarni, P.; Marenco, L.; Chen, R.; Skoufos, E.; Shepherd, G.; Miller, P. Organization of Heterogeneous Scientic Data Using the EAV/CR Representation. In: Journal of the American Medical Informatics Association, (1999): 6 (6), S. 478-493.
