Clusterung - Qualitative und quantitative Evaluation von Varianten zur performanten Verwaltung

5.3 Primärspeichermessungen

5.3.2 Clusterung

Neben Schemata und Instanzen wurde auch die grobe Clusterung im Primärspeicher untersucht. Hierbei sind einerseits die Messwerte des Weiterschaltens zu beachten. Nach-dem diese vorgestellt wurden, werden die Messergebnisse der Laufzeit des Algorithmus preEvolveSelection betrachtet.

Die Tabelle in Abbildung91stellt die Messwerte des Weiterschaltens mit Neuberechnung der Clusterzugehörigkeit der ohne Neuberechnung aus Abbildung 89 gegenüber.

Lässt man die aufgrund von Schwankungen markierten Werte außer Acht, so bestätigt sich, dass das Weiterschalten mit Neuberechnung der Clusterzugehörigkeit langsamer ist als ohne Neuberechnung. Geht man davon aus, dass, wie bereits empfohlen, Schemata mit impliziter Blockstruktur und Instanzen mit expliziten Knotenmarkierungen zum Einsatz kommen, ist durch die Neuberechnung der Clusterzugehörigkeit eine Verschlechterung der Laufzeit des Weiterschaltens zwischen 35.7% und 41.4% zu erwarten.

Neben dem Weiterschalten ist bei der Messung der groben Clusterung die Laufzeit des Al-gorithmuspreEvolveSelection zu beachten, welche in Tabelle2 dargestellt ist. Hierbei wurde ein Schema vom Typ „evolve“ (siehe Abbildung63) eingesetzt und 20 Instanzen auf Basis dessen erstellt. Für jeden Knoten des Schemas existiert genau eine Instanz, welche diesen Knoten im Zustand RUNNING hat. Es wurden die Laufzeiten des Algorithmus auf Basis der Änderungen gemessen, welche aus Abbildung 92 ersichtlich sind.

Es ist zu erkennen, dass durch geringen Zeitaufwand meist der Großteil der Instanzen als

„migrierbar“ und „nicht migrierbar“ kategorisiert werden kann und nur ein Teil der In-stanzen nach den Methoden aus [Rin04,Jur06] genauer untersucht und somit eingelagert werden muss. Geht man davon aus, dass die in Abschnitt 5.2 empfohlene Sekundär-speicherrepräsentation von Instanzen mithilfe von PostgreSQL eingesetzt wird, hat das

mit Neuberechnung ohne Neuberechnung

Instanz Instanz

Knoten Schema explizit implizit explizit implizit NORMAL explizit 4.5 ^+18.4% 4.5 ^+32.4% 3.8 3.4

implizit 3.8 ^+35.7% 3.8 ^+52.0% 2.8 2.5

AND-Split explizit 5.8 5.7 ^+23.9% 9.8* 4.6

implizit 4.1 ^+41.4% 3.9 ^+50% 2.9 2.6

XOR-Split explizit 25.7 22.8 9.7* 10.7*

implizit 13.2 11.7 ^+138.8% 9.9* 4.9

AND-Join explizit 6.0 ^+11.1% 40.5 5.4 58.3*

implizit 4.3 ^+38.7% 29.8 3.1 33.5*

* sehr starke periodische Schwankungen im Ergebnis

Abbildung 91: Weiterschalten mit & ohne Clusterung (in Tausendstel)

Einlagern einer Instanz etwa einen Zeitaufwand von 2.7 Zeiteinheiten (vergleiche Ab-bildung 83). Somit lassen sich durch den Einsatz der groben Clusterung 16.2 bis 32.4 Zeiteinheiten sparen, da 6 bis 12 Instanzen weniger eingelagert werden müssen. Ohne die grobe Clusterung fallen 54 Zeiteinheiten an, es entsteht somit eine Zeitersparnis von 30%

bis 60%. Hierbei ist die Zeit nicht mit eingerechnet, die zur Untersuchung der Instanzen nach [Rin04, Jur06] nötig ist und somit durch Einsatz der groben Clusterung für 6 bis 12 Instanzen gespart werden kann.

Diese Werte können allerdings nur als Beispiel dienen. Es lässt sich keine allgemein gül-tige Aussage daraus ableiten, da die Ergebnisse sehr stark vom ursprünglichen Schema und den Änderungen darauf abhängen. So wird der Algorithmus zum Beispiel bei einem Schema, welches keinen Split-Knoten besitzt, also der Wurzelblock der einzige Block

5.3 Primärspeichermessungen

Abbildung 92: Die untersuchten Änderungen am evolve-Schema

Knoten einfügen zwischen Laufzeit Ergebnis

3→ 4 77.4 (0 - 12 - 8)

9→ 10 84.1 (6 - 0 - 14)

9→ 10 und 11→ 12 90.2 (6 - 6 - 8)

15→ 16 76.7 (12 - 0 - 8)

Ergebnis: (migrierbar - nicht migrierbar - genauer untersuchen)

Tabelle 2: Laufzeit von preEvolveSelection(in Tausendstel)

ist, keinen Vorteil bieten, da alle Instanzen als „genauer zu untersuchen“ kategorisiert werden, weil alle vom Wurzelcluster (dem einzigen Cluster) referenziert werden (ver-gleiche Abschnitt3.3.1.2). Allgemein kann die Aussage getroffen werden, dass die grobe Clusterung mehr Zeitersparnis bei einer Schemaevolution bieten kann, je mehr Split-Knoten im zugrunde liegenden Schema vorhanden sind. Dies folgt, weil jeder zusätzli-che Split-Knoten einen zusätzlizusätzli-chen Cluster bedeutet, anhand dessen Instanzen durch preEvolveSelection vor dem Einlagern kategorisiert werden können. Außerdem ist es vorteilhaft, wenn möglichst viele dieser Split-Knoten einen Block aufspannen, der dem Wurzelblock direkt untergeordnet ist, da diese potentiell Stellen aufspannen. Je mehr (potentielle) Stellen in einem Schema vorhanden sind, desto genauer kann die Position einer Änderung mithilfe der groben Clusterung bestimmt und damit mehr Instanzen aus anderen Clustern kategorisiert werden.

Aufgrund der starken Verschlechterung der Laufzeit des Weiterschaltens durch die Neu-berechnung der Clusterzugehörigkeit und der starken Abhängigkeit der Zeitersparnis bei einer Schemaevolution vom zugrunde liegenden Schema und den vorgenommenen Ände-rungen, kann keine allgemeine Empfehlung zum Einsatz der groben Clusterung in der Praxis gegeben werden. Es ist denkbar, dass diese von einem Benutzer des PMS beim Mo-dellieren eines Schemas manuell eingeschaltet wird, wenn sich das Schema für die grobe Clusterung eignet und/oder erwartet wird, dass Schemaevolutionen auf diesem Schema durchgeführt werden.

5.4 Fazit

Nachdem die Grundlagen und Konzepte und deren Umsetzung in den vorigen Kapiteln beschrieben wurden, runden die Messungen aus diesem Kapitel die Arbeit ab. Es wurden verschiedene Repräsentationen sowohl von Schemata als auch von Instanzen untersucht.

Bei Schemata wurde durch die Messungen festgestellt, dass die Vorteile, welche eine Repräsentation mit expliziter Blockstruktur bei Anfragen bezüglich dieser bietet, in der Praxis nicht zum Tragen kommen. Schemata mit impliziter Blockstruktur sind sowohl im Primär- als auch im Sekundärspeicher vorzuziehen, sofern die empfohlene XML-Datei-Speicherung eingesetzt wird. Dies wurde durch Messungen des Ein- und Auslagerns der Daten, als auch durch Messungen des Weiterschaltens von Instanzen bestimmt.

Für Instanzen wurden ebenfalls die beiden Repräsentationen untersucht. Hierbei stell-te sich heraus, dass diese im Sekundärspeicher mithilfe von PostgreSQL und einer Re-präsentation mit impliziten Knotenzuständen gespeichert werden sollten. Hierbei ist der Einsatz des XML-Datentyps für die Spalte der serialisierten Knotenzustände empfehlens-wert. Diese Variante bietet die performantesten Zugriffe auf Instanzen, sofern sowohl das Ein- und Auslagern als auch Anfragen auf Kollektionen beachtet werden. Im Primärspei-cher sollten Instanzen hingegen in einer Repräsentation mit expliziten Knotenzuständen dargestellt werden. Diese bietet eine bessere Performanz beim Weiterschalten, da die implizite Repräsentation hier bei AND-Join-Knoten sehr schlecht abschneidet.

Nicht empfehlenswert ist der Einsatz von JPA zur Persistierung von Daten, da das Ein-und Auslagern dabei wesentlich mehr Zeit benötigt als bei einer direkten Speicherung.

Ebenfalls nicht eingesetzt werden sollte Oracle, da die Performanz hierbei nicht ausrei-chend ist. Auffallend war dies besonders bei Anfragen, welche auf serialisierte XML-Daten getätigt wurden. Dies ist aber auch beim Betrachten der Abbildungen82 und87, welche die Ergebnisse der einzelnen Varianten zusammenfassen, leicht ersichtlich.

Mit den in Abschnitt 4.3.5 vorgestellten Zwischenspeicher-Implementierungen von TemplateStorage und InstanceStorage wurden keine Messungen durchgeführt. Dies liegt daran, dass der Vorteil, den ein „Zwischenschalten“ dieser Klassen bringt, stark vom Zugriffsverhalten auf Schemata und Instanzen abhängig ist und somit keine allgemeinen Messungen durch die Testumgebung möglich sind. Der Einsatz solcher Zwischenspeicher ist allerdings generell zu empfehlen, sofern genug Hauptspeicher vorhanden ist, da hier-durch „teure“ Zugriffe auf den Sekundärspeicher beim Laden von Daten unter Umständen verhindert werden.

Es kann keine allgemeine Empfehlung für den Einsatz der groben Clusterung aus Ab-schnitt 3.3 abgegeben werden. Für deren Einsatz ist es notwendig, die Clusterzugehö-rigkeit beim Weiterschalten neu zu berechnen, was diesen Vorgang stark verlangsamt.

Außerdem kann keine allgemeine Einschätzung über die Zeiteinsparungen getroffen wer-den, welche die grobe Clusterung bei einer Schemaevolution bringt. Diese hängt stark vom Schema und von den Änderungen daran ab. Somit ist denkbar, die grobe Cluste-rung durch manuelles Einschalten während dem Modellieren von Schemata einzusetzen.

5.4 Fazit Dadurch kann eine manuelle Einschätzung getroffen werden, ob die grobe Clusterung bei einer Schemaevolution dieses Schemas einen Vorteil bringt. Allgemein gilt die Aus-sage, dass die grobe Clusterung mehr Vorteile bietet, je mehr Split-Knoten im Schema vorhanden sind. Ebenso kann die grobe Clusterung manuell eingeschaltet werden, wenn bereits beim Modellieren des Schemas bekannt ist, dass Schemaevolutionen auf diesem durchgeführt werden.

6 Verwandte Konzepte

Im Rahmen dieser Arbeit wurde bisher von interpretierten Graphstrukturen als interne Repräsentation von Prozessen ausgegangen. Dieses Kapitel rekapituliert die Eigenschaf-ten einer solche Repräsentation und stellt andere mit deren EigenschafEigenschaf-ten vor.

Bei einer Repräsentation mit interpretierten Graphstrukturen modelliert der Benutzer einen Prozess als Graph, welcher intern vom PMS auch als solcher repräsentiert wird [Rei00,HJKW96]. Dieses interpretiert den Graph und führt auf dieser Basis Aktivitäten aus, welche den Knoten zugeordnet sind. Anfallende Daten werden ebenfalls durch in-terpretieren einer geeigneten Graphmodellierung abgebildet. Diese Funktionen führt das PMS auf einem zentralen Server aus, welcher gleichzeitig Mitarbeitern Überprüfungsmög-lichkeiten, wie zum Beispiel die Anfragen auf Kollektionen aus Abschnitt 2.4.3 anbieten kann. Neben der im Laufe dieser Arbeit betrachteten Anwendung der Schemareferenz von Instanzen, ist es auch möglich, die Schemadaten beim Erzeugen einer Instanz zu kopieren. Dieses Vorgehen beinhaltet eine einfachere Anwendung von instanzbasierten Änderungen. Hierbei ist keine Deltaschicht notwendig, welche die Änderungen gegenüber einem zugrunde liegendem Schema abbildet, sondern die Änderungen können direkt im instanzeigenen Graph realisiert werden. Nachteil dieser Repräsentation ist, dass diese sehr viel Speicher benötigt, da jede Instanz die volle Repräsentation der (redundante) Schemadaten hält.

Neben interpretierten Graphstrukturen können Prozesse auch als verteilte Prozesspar-tikel dargestellt werden [DKM⁺97, WWWK96]. Dieser Ansatz verfolgt die Idee, jeden Prozessschritt in einen eigenständigen Automaten [Sch01b] zu übersetzen. Diese Automa-ten kommunizieren unabhängig von einem zentralen Server über (Netzwerk-)NachrichAutoma-ten miteinander und bilden so den Kontroll- und Datenfluss ab. Jeder dieser Automaten be-sitzt neben der Logik zur Ausführung des eigentlichen Prozessschrittes Vorbedingungen und nachgelagerte Aktivitäten. Sind alle Vorbedingungen erfüllt, also alle Nachrichten von vorgelagerten Automaten korrekt eingetroffen, wird die Ausführung des Prozess-schrittes aktiviert. Danach werden alle nachgelagerten Aktivitäten abgearbeitet. Dies bedeutet, dass allen nachgelagerten Automaten die entsprechenden Nachrichten gesen-det werden. Der Vorteil dieser Variante besteht darin, dass sie ohne einen zentralen Server auskommt und die eigenständigen Automaten somit beliebig verteilt werden können: Es ist denkbar, diese auf beliebigen Rechnern an beliebigen Orten auszuführen, was zum Bei-spiel in Hinblick auf datenschutzrechtliche Bestimmungen von Vorteil sein kann. Hieraus folgt allerdings, dass keine einfache globale Steuerungsmöglichkeit des Prozesses besteht.

Ebenso sind instanzbasierte Änderungen nicht möglich, da das Verhalten der einzelnen verteilten Automaten nicht auf Instanzbasis verändert werden kann.

Als weitere Möglichkeit lassen sich Prozesse als Regelmenge repräsentieren [DHL90, BMR96,KPRR95, Joe99]. Hierbei wird der Prozess ebenfalls als Graph modelliert, zur Repräsentation im PMS allerdings zu einer Regelmenge übersetzt. Diese Regeln wer-den durch Eintreten von Ereignissen getriggert. Hierbei kann eine Regel zusätzliche Bedingungen enthalten, wie zum Beispiel die Überprüfung auf eine bestimmte

Tages-zeit. Sind alle Bedingungen erfüllt, wird eine Aktion ausgeführt, welche nach Abarbei-tung wiederum Ereignisse auslösen kann. Abgebildet werden können solche regelbasier-ten Systeme zum Beispiel durch (erweitere) RDBMS. Hierbei bilden Daregelbasier-tenbank-Trigger [Pos09b,Ora09b,IBM09b] die Regeln ab. Innerhalb dieser können verschiedene Bedin-gungen geprüft und Aktionen ausgeführt werden. Der Datenfluss wird bei diesem Kon-zept ebenfalls durch die Regeln definiert, so kann in Datenbank-Triggern zum Beispiel auf bestimmte Felder bestimmter Tabellen zugegriffen werden. Regelbasierte PMS be-nötigen wenig zusätzlichen Entwicklungsaufwand, da viele RDBMS die Möglichkeit von Datenbank-Triggern bereits bieten. Die Prozessmodellierung ist allerdings aufgrund der großen Zahl an Regeln, welche zur Modellierung benötigt werden, sehr komplex. Eine weitere Auswirkung der Größe der Regelmenge ist, dass diese schnell unübersichtlich und somit schlecht wartbar wird. Ebenso werden instanzbasierte Änderungen nur sehr bedingt unterstützt.

Ebenso lässt sich eine weitere Repräsentationdirekt auf RDBMS definieren. Hierbei be-steht eine Instanz aus einem Eintrag in einer Tabelle. Diese besitzt außer den Daten des Prozesses an sich noch eine weitere Spalte, welche den Zustand angibt. Auf Basis dieses Zustandsfelds kann eine Selektion zur Ansicht für den Benutzer generiert werden. Dies ist zum Beispiel durch Einsatz von Views möglich [ISO92]. Hierbei existiert für jeden Benut-zer eine View, welche die Einträge in der Tabelle auf Basis des Zustandsfelds filtert. Somit bekommt der Benutzer diejenigen Instanzen in genau den Zuständen angezeigt, für die er als Bearbeiter vorgesehen ist. Nachteil ist, dass auch hier instanzbasierte Änderungen nur sehr schwierig umsetzbar sind.

Prozesse lassen sich intern auch als Menge von Operationen repräsentieren, wobei die ein-zelnen (Prozess-)Instanzen als Datenobjekte von Operation zu Operation weitergereicht werden [KRW90, BMR96]. Hierbei ist allerdings die Realisierung von Parallelverzwei-gungen sehr schwierig, da die Instanz nur mithilfe eines Datenobjekts repräsentiert wird.

Somit kann nicht das gleiche Datenobjekt an zwei unterschiedliche Operationen geleitet werden. Dies wäre durch eine Duplizierung des Datenobjekts zwar möglich, diese Date-nobjekte müssten beim Zusammenführen der Parallelverzweigung allerdings aufwändig vereint werden. Auch die Unterstützung von instanzbasierten Änderungen ist nur sehr eingeschränkt möglich.

In diesem Kapitel wurden verschiedene Konzepte vorgestellt, Prozesse zu repräsentie-ren. Hierzu zählen die in dieser Arbeit untersuchten interpretierten Graphstrukturen, aber auch eine Repräsentation als verteilte Prozesspartikel oder als Regelmenge. Eben-so lassen sich Prozesse direkt auf RDBMS mithilfe von Views repräsentieren. Als letzte Möglichkeit wurde eine Repräsentation mithilfe von Datenobjekten vorgestellt, welche zwischen Operationen einer festen Menge weitergereicht werden.

7 Zusammenfassung und Ausblick

PMS erlangen aufgrund der anwachsenden Globalisierung in den letzten Jahren immer mehr Aufmerksamkeit. Die Systeme müssen in Zukunft auch von weltumspannenden Firmen eingesetzt werden können. Hierzu ist eine performante Verarbeitung von Anfra-gen, welche an die Systeme gestellt werden, von zentraler Bedeutung. Dies muss auch gewährleistet sein, wenn viele Prozesse gleichzeitig ablaufen. Neben der eingesetzten Soft-warearchitektur spielt hierbei die Repräsentation der Prozessdaten eine zentrale Rolle.

In dieser Arbeit wurden verschiedene Varianten der Repräsentation von Prozessdaten untersucht. Durch die Untersuchungen wurden optimal geeignete Repräsentationen der Prozessdaten, welche sich in Schema- und Instanzdaten gliedern, sowohl im Primär- als auch im Sekundärspeicher ermittelt. Dieses Kapitel fasst die Arbeit zusammen und stellt Ideen zu weiteren Untersuchungen des Themengebiets vor.

7.1 Zusammenfassung

Im Rahmen dieser Arbeit wurden Varianten zur Repräsentation von Prozessdaten unter-sucht. Diese gliedern sich in Schemata und Instanzen. Hierbei existieren für diese beiden jeweils zwei Repräsentationen, welche sowohl qualitativ als auch quantitativ untersucht wurden.

Nach der Vorstellung der Grundlagen wurden darauf aufbauende Konzepte erläutert.

Hierzu zählt die Partitionierung von Schemata. Mithilfe dieser ist es möglich, nur vom System benötigte Daten im Primärspeicher zu halten. Momentan nicht benötigte Da-ten können dynamisch aus dem Sekundärspeicher nachgeladen und in die vorhandenen Primärspeicherdaten eingegliedert werden. Hierfür wurde zunächst eine konzeptionelle Umsetzung beschrieben. Im Anschluss wurde die grobe Clusterung vorgestellt, mit deren Hilfe die Laufzeit der Schemaevolution verringert werden kann. Hierbei werden Instanzen in einem Clusterbaum gehalten, welcher die grobe Position angibt, an der die Instanz in ihrer Ausführung steht. Es wurden Algorithmen vorgestellt, mit deren Hilfe die nötige zustandsbasierte Verträglichkeit allein anhand der Einordnung einer Instanz im Cluster-baum überprüft werden kann. Da die grobe Clusterung den Zustand einer Instanz nicht genau angibt, können auf dieser Basis nicht alle Instanzen bewertet werden und ein Teil muss weiterhin mit den bekannten Methoden [Rin04, Jur06] untersucht werden. Dafür wird bei Einsatz der groben Clusterung nur wenig Speicherplatz benötigt, was das Ver-fahren praxistauglich macht.

Der konzeptionellen Untersuchung schloss sich eine Umsetzung an, welche die vorge-stellten Grundlagen und Konzepte implementiert. Hierbei wurden die verschiedenen er-mittelten Repräsentationen mithilfe von Java™ im Primärspeicher umgesetzt. Da auch eine persistente Speicherung der Prozessdaten in der Praxis notwendig ist, wurden die verschiedenen Repräsentationen auch als Sekundärspeicherstrukturen umgesetzt. Hierbei

wurde auf eine XML-Datei-Speicherung und die Persistierung mithilfe verschiedener, am Markt erhältlicher relationalen Datenbanksysteme zurückgegriffen.

Mithilfe dieser Implementierung wurden Messungen anhand von verschiedenen Anwen-dungsszenarien durchgeführt. Hierbei wurden neben dem Ein- und Auslagern der Pro-zessdaten auch Anfragen auf Kollektionen betrachtet. Diese Sekundärspeichermessungen wurden für die verschiedenen Sekundärspeichervarianten durchgeführt. Deren Ergebnisse wurden anschließend verglichen und sowohl die optimale Sekundärspeicherrepräsentation, als auch die optimale Sekundärspeichervariante ermittelt. Es wurden ebenfalls Messungen der verschiedenen Primärspeicherrepräsentationen durchgeführt. Hierbei wurde ebenfalls eine optimale Repräsentation anhand eines Anwendungsszenarios sowohl für Schemata als auch Instanzen ermittelt. Abschließend wurde die Performanz der groben Clusterung gemessen und überprüft, ob diese den konzeptionellen Erwartungen gerecht wird.

Aufgrund der qualitativen und quantitativen Untersuchungen wurden optimale Reprä-sentationen der einzelnen Datenstrukturen ermittelt. Mithilfe dieser RepräReprä-sentationen ist eine Implementierung eines PMS’ mit einer optimalen internen Darstellung der Pro-zessdaten möglich.

7.2 Ausblick

Dieser Abschnitt gibt abschließend einen Ausblick auf Themen, welche in zukünftigen Arbeiten untersucht werden können.

Es kann die Realisierung benutzerdefinierter Blöcke untersucht werden. Blöcke wurden im Rahmen dieser Arbeit anhand von Split-Knoten und deren zugehörigen Join-Knoten definiert. Auf dieser Idee basiert sowohl die Partitionierung von Schemata als auch die grobe Clusterung von Instanzen. Es ist denkbar, dass Blöcke manuell beim Modellie-ren des Schemas definiert werden. Setzt man dann auf Basis dieser Blöcke die grobe Clusterung um, so sind unter Umständen wesentlich bessere Ergebnisse von der groben Clusterung bei einer Schemaevolution zu erwarten, da der Modellierer die Zusammen-hänge von Knoten besser feststellen kann. Bedacht werden muss hierbei allerdings, dass durch Einführung benutzerdefinierter Blöcke weitere Strukturen im Schema notwendig werden, die diese Blockstruktur abbilden. Eine implizite Darstellung der Blockstruktur ist unter Umständen nicht mehr möglich.

Ebenfalls untersucht werden kann, ob instanzbasiert geänderte Instanzen trotz des Wi-derspruchs in Abschnitt3.4.4 im Clusterbaum gehalten werden können. Hierbei könnte eine Art „Clusterdelta“ eingesetzt werden, welches die strukturellen Änderungen der in-stanzbasiert geänderten Instanz abbildet und zusätzlich zur Instanz vom Clusterbaum referenziert wird. Hiermit ist es unter Umständen möglich, die Verträglichkeit dieser instanzbasiert geänderten Instanzen bei einer Schemaevolution auch ohne Einlagerung festzustellen.

A Abbildungsverzeichnis

1 Ein Schema mit zwei Instanzen . . . 3 2 Ein ADEPT2-Schema . . . 4 3 Die Blockstruktur eines ADEPT2-Schemas . . . 5 4 Knotenzustände und -übergänge (in Anlehnung an [Rei00]) . . . 6 5 Eine ADEPT2-Instanz während Knoten 10 ausgeführt wird . . . 7 6 Die Knoten eines Schemas und deren Knotenattribute . . . 8 7 Schemakopie vs. Schemareferenz . . . 9 8 Instanz mit impliziter und expliziter Markierung . . . 10 9 Clusterung. . . 11 10 Instanzbasierte Änderungen mit Deltaschicht . . . 11 11 Kapselung bei Einsatz einer strukturellen Deltaschicht . . . 12 12 Die ADEPT2-Architektur [RDR⁺09] . . . 13 13 Die verschiedenen Fälle des Weiterschaltens . . . 16 14 Beispiel einer Schemaevolution . . . 17 15 Exemplarische Organisation eines Unternehmens . . . 18 16 Speicherhierarchie . . . 19 17 Vertikale Partitionierung eines Schemas . . . 22 18 Horizontale Partitionierung eines Schemas . . . 22 19 Partitionierungsschwierigkeiten bei Bearbeiterzuordnungen . . . 24 20 Blockstruktur mit Hierarchie . . . 24 21 Knoten ohne Vorgänger-/Nachfolgerbeziehung . . . 27 22 Verschiedene Wege vom Start-Knoten zu Knoten 12 . . . 27 23 Schemarepräsentation mit expliziter Blockstruktur . . . 30 24 Hierarchiedarstellung bei expliziter Blockstruktur . . . 31 25 Hierarchie der Blockstruktur und Clusterbaum . . . 33 26 Beispiel für die grobe Clusterung . . . 35 27 Beispiel einer Schemaevolution bei grober Clusterung . . . 36 28 Zuordnung von Änderungen zu einer Stelle . . . 37 29 COMPACT und LEAKY . . . 38 30 Änderung im Wurzelblock . . . 39 31 Kapselung bei Einsatz der erweiterten Deltaschicht . . . 42 32 Deltaschicht mit expliziter Blockinformation . . . 45 33 Schemaevolution mit instanzbasierten Änderungen . . . 47 34 Test- undDatabase-Schnittstelle . . . 50 35 Architektur der Workflow-Testumgebung mit Schnittstellen . . . 51 36 Speicherverbrauch von Maps . . . 52 37 Template-Schnittstelle . . . 54 38 Die KlasseDeltaLayer . . . 56 39 Instance-Schnittstelle . . . 57 40 Die KlasseCluster . . . 58 41 Speichertrennung anhand von Storage-Schnittstellen . . . 61 42 Schemarepräsentationen im Primär- und Sekundärspeicher . . . 62

45 XML-Repräsentationen von Schemata . . . 64 46 Schemata mit expliziter Blockstruktur im RDBMS . . . 66 47 Schemata mit expliziter Blockstruktur in XML im RDBMS . . . 66 48 Schemata mit impliziter Blockstruktur im RDBMS . . . 67 49 Schemata mit expliziter Blockstruktur mit JPA . . . 67 50 Schemata mit impliziter Blockstruktur mit JPA . . . 68 51 InstanceStorage-Schnittstelle . . . 68 52 Instanzrepräsentation im Primär- und Sekundärspeicher . . . 69 53 InstanceSerialization-Schnittstelle . . . 69 54 XML-Repräsentationen von Instanzen . . . 70 55 Instanzen mit expliziten Knotenzuständen im RDBMS . . . 71 56 Instanzen mit expl. Knotenzuständen in XML im RDBMS . . . 71

Im Dokument Qualitative und quantitative Evaluation von Varianten zur performanten Verwaltung von Prozessdaten in einem Hochleistungs-PMS (Seite 119-157)