Studienarbeit

Hierarchische Versionierung in relationalen Datenbanken“ ” Karsten Lohse

September 2007

Betreuer: Professor Dr. Ulf Leser

Arbeitsgruppe Wissensmanagement in der Bioinformatik Institut f¨ ur Informatik Humboldt-Universit¨at zu Berlin Unter den Linden 6 10099 Berlin

Erkl¨ arung

Hiermit erkl¨ are ich, die vorliegende Studienarbeit selbstst¨andig angefertigt zu haben. Es wurden nur die in der Arbeit ausdr¨ ucklich genannten Quellen und Hilfsmittel benutzt. W¨ortlich oder sinngem¨ aß u ¨bernommenes Gedankengut wurde als solches kenntlich gemacht.

Unterschrift:

Datum:

3

Inhaltsverzeichnis 1 Einleitung

9

1.1

Motivation

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

1.2

Ziel dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

1.3

Historie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

1.4

Aufbau dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2 Versionierungsstrategien

11

2.1

Unterschiede zwischen linearer und hierarchischer Versionierung . . . . . . . .

11

2.2

Arten der Versionierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

2.2.1

Versionierung mit Zeitstempel auf Tupelebene ohne Schattentabellen .

13

2.2.2

Versionierung mit Zeitstempel auf Tupelebene mit Schattentabellen .

13

2.2.3

Versionierung mit Deltas auf Tupelebene

. . . . . . . . . . . . . . . .

13

2.2.4

Versionierung auf Attributebene . . . . . . . . . . . . . . . . . . . . .

14

3 Entwicklung einer hierarchischen Versionierung

17

3.1

Einf¨ uhrung von Begriffen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

3.2

Idee einer hierarchischen Versionierung . . . . . . . . . . . . . . . . . . . . . .

18

3.3

Verwaltung der Versionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

3.3.1

Tabelle versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

3.3.2

Erzeugung einer neuen Version . . . . . . . . . . . . . . . . . . . . . .

20

3.4

Ver¨ anderungen an den Datentabellen . . . . . . . . . . . . . . . . . . . . . . .

20

3.5

Zugriff auf die versionierte Tabelle . . . . . . . . . . . . . . . . . . . . . . . .

21

3.6

Datenmanipulationen

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

3.6.1

insert data-Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

3.6.2

delete data-Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

3.6.3

update data-Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

4 Beispiel einer Versionierung

25

5

4.1

4.2

4.3

4.4

4.5

Ausgangstabelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

4.1.1

Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

4.1.2

Inhalt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

Umgewandelte und neu erzeugte Tabellen - Schritt 1 . . . . . . . . . . . . . .

26

4.2.1

Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

4.2.2

Inhalt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

4.2.3

Ver¨ anderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

Umgewandelte und neu erzeugte Tabellen - Schritt 2 . . . . . . . . . . . . . .

27

4.3.1

Inhalt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

4.3.2

Ver¨ anderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

Umgewandelte und neu erzeugte Tabellen - Schritt 3 . . . . . . . . . . . . . .

29

4.4.1

Inhalt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

Inhalte der angelegten Versionen der Tabelle data . . . . . . . . . . . . . . . .

30

4.5.1

Versionenbaum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

4.5.2

Version 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

4.5.3

Version 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

4.5.4

Version 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

4.5.5

Version 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

4.5.6

Version 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

4.5.7

Version 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

5 Vergleichende Messung

33

5.1

Swissprot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

5.2

Testumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

5.3

Einf¨ ugen der Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

5.4

Zugriff auf Versionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

5.4.1

Anfrage ganzer Relationen . . . . . . . . . . . . . . . . . . . . . . . . .

37

5.4.2

Anfrage von Bereichen aus Relationen . . . . . . . . . . . . . . . . . .

38

Optimierungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

5.5.1

Alternative Ermittlung der Vorg¨angerversionen 1 . . . . . . . . . . . .

45

5.5.2

Alternative Ermittlung der Vorg¨angerversionen 2 . . . . . . . . . . . .

45

5.5.3

Indizierung und Partitionierung . . . . . . . . . . . . . . . . . . . . . .

45

5.5.4

Ergebnisse der Optimierungen . . . . . . . . . . . . . . . . . . . . . .

46

5.5

6 Fazit

47

6.1

47

Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

6.2

Erweiterungsm¨ oglichkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

A API

48

B Algorithmus der Messung

53

C Struktur von SwissProt

55

7

Kapitel 1

Einleitung In einer fast unz¨ ahlbaren Zahl von Anwendungen werden heute Datenbanken zur Speicherung von Informationen eingesetzt. Dies sind unter anderem objektorientierte Datenbanken, Datendateien, XML-Dateien oder relationale Datenbanken.

1.1

Motivation

Relationale Datenbanken werden in allen Bereichen des t¨aglichen Gesch¨aftes eingesetzt. Als Beispiel m¨ ochte ich einmal den Lebensmittelhandel heraus greifen. In einem modernen Supermarkt entstehen st¨andig große Mengen an Daten. Dies k¨onnen unter anderem Bestelldaten, Wareneingangsdaten und Kassierdaten sein. Die entstehenden Daten werden heute meist in einem relationalem Datenbankmanagementsystem abgelegt. In diesem Datenbankmanagementsystem k¨onnen allerdings nicht alle Daten gespeichert werden, die je erfasst wurden. Dies w¨ urde schnell die Effizienz der operativen Systeme beeintr¨achtigen. Stattdessen werden die Daten in ein so genanntes DataWarehouse u ¨bertragen. Dies ist ein (meist zentrales) Datenlager, in dem alle entstandenen Daten archiviert werden. Dieser Prozess kann sowohl in Echtzeit sowie als regelm¨aßiger Bulk-Import realisiert sein. Die so gesammelten Daten dienen dann beispielsweise zur Analyse von Gesch¨aftsprozessen. Dabei sollen damit nur zur¨ uck liegende Prozesse analysiert werden, sondern es sollen auch operative Entscheidungen f¨ ur die Zukunft unterst¨ utzt werden. Hierf¨ ur ist eine Vorausberechnung mit vielen verschiedenen Parametern notwendig. Diese Vorausberechnung beruht auf den aktuellen Daten. Um verschiedene Szenarien durchspielen zu k¨onnen, will man aber eventuell auch die zugrunde liegende Datenbasis ver¨andern. Besser ist es, die Zukunftsbetrachtungen so auszuf¨ uhren, dass sie die aktuellen und realen Daten nicht beeinflussen. Dies kann man mit verschiedenen Herangehensweisen realisieren. Eine oft praktizierte L¨ osung ist, einen Dump der Datenbank anzufertigen und diesen in einer abgetrennten Umgebung wieder in eine neue Datenbank zu u uhren. In dieser kann ¨berf¨ dann die Zukunftsbetrachtung durchgef¨ uhrt werden. Bei großen Datenbest¨anden, wie sie in DataWarehouses nicht selten sind, kann dies allerdings sehr zeitaufw¨andig werden. Die Ver¨anderungen an den Daten kann man auch in einer Transaktion ausf¨ uhren. Dies wird schließlich mit einem Rollback beendet. Die eigentlichen Daten sind dadurch nicht ver¨andert worden. Dies f¨ uhrt zum Einen dazu, dass einige Tabellen mit einem Lock versehen werden, zum Anderen aber auch dazu, dass die Aktionen der Zukunftsbetrachtung bei einem erneuten 9

Aufruf auch erneut durchgef¨ uhrt werden m¨ ussen. Dies ist zeitaufw¨andig und fehleranf¨allig. Eine elegantere M¨ oglichkeit ist es, die Betrachtungen in einer auf den aktuellen Daten aufbauenden, aber logisch von ihr getrennten Version der Datenbank durchzuf¨ uhren. Hierf¨ ur ist eine Versionierung der Datenbank notwendig. Bei einer versionierten Datenbank wird nicht nur die aktuelle Version der Datenbank in einem DBMS verwaltet, sondern es werden durch geeignete Mechanismen unterschiedliche Versionen der Datenbank parallel zur Verf¨ ugung gestellt. Diese k¨onnen sich – je nach Wunsch und Konfiguration – gegenseitig beeinflussen oder komplett autark sein. Es wird zwischen linearer und hierarchischer Versionierung unterschieden. Genau genommen ist die lineare Versionierung ein Sonderfall der hierarchischen Versionierung. Die genauen Unterschiede werden im Abschnitt 2 Unterschiede zwischen linearer und hierarchischer Ver” sionierung“ im Kapitel 2 Versionierungsstrategien“ (auf Seite 11) erl¨autert. ”

1.2

Ziel dieser Arbeit

Das Ziel dieser Studienarbeit ist die Entwicklung einer leistungsf¨ahigen hierarchischen Versionierungsstrategie, die auch den Zugriff von Altanwendungen erm¨oglicht, die die Versionierung nicht unterst¨ utzen. Die zu entwickelnde Strategie soll mit den Daten von SwissProt [10] getestet werden. Die Performance soll durch Vergleichsmessung mit einer Datenbank ohne Versionierung und mit dem Oracle Workspace Manager verglichen werden.

1.3

Historie

Diese Arbeit baut auf der Diplomarbeit[1] vom Stephan Rieche mit dem Titel Versionierung ” in relationalen Datenbanken“ aus dem Jahre 2004 auf. Die dort untersuchten Ans¨atze werden auf ihre Tauglichkeit f¨ ur die hierarchische Versionierung hin untersucht und eine geeignete Strategie daraus entwickelt. Die Infrastruktur, die Stephan Rieche entwickelt hat, soll dabei genutzt und evtl. umgebaut werden. Dies betrifft vor allem das Tool swissparse zum Einf¨ ugen von Daten in die Datenbank.

1.4

Aufbau dieser Arbeit

Im Kapitel 2 werden m¨ ogliche Versionierungsstrategien vorgestellt. Das Kapitel 3 zeigt die Implementation und Funktionsweise der neu entwickelten Versionierungsstrategie. Ein Beispiel im Kapitel 4 soll die Funktionsweise nochmals genauer darstellen. Die abschließende vergleichende Messung im Kapitel 5 stellt die Zugriffszeiten der zu vergleichenden Systeme gegen¨ uber.

10

Kapitel 2

Versionierungsstrategien Bei der Versionierung wird grunds¨ atzlich zwischen zwei Arten unterschieden. • lineare Versionierung • hierarchische Versionierung

2.1

Unterschiede zwischen linearer und hierarchischer Versionierung

Bei der linearen Versionierung hat jede Version h¨ochstens einen Nachfolger. Somit ist f¨ ur jede Version sofort ersichtlich, welche Version ihr Vorg¨anger und welche, wenn vorhanden, ihr Nachfolger ist. In Abbildung 2.1 ist ein m¨oglicher Versionenbaum, genauer eine Versionenkette dargestellt.

Abbildung 2.1: Lineare Versionierung

In Abbildung 2.2 ist ein m¨ oglicher Versionenbaum einer hierarchischen Versionierung dargestellt. Hier ist zu sehen, dass jede Version eine unterschiedliche Anzahl an Nachfolgern haben kann. Es handelt sich hier nicht zwingend um einen bin¨aren Baum. Das heißt ein Knoten kann auch mehr als 2 Kinder haben.

Abbildung 2.2: Hierarchische Versionierung

11

Bei der linearen Versionierung kann man eine automatische Erstellung der Versionen realisieren. Dies kann mit unterschiedlicher Frequenz als Reaktion auf bestimmte Ereignisse erfolgen. Die kann transaktionskontinuierlich, anweisungskontinuierlich oder tupelkontinuierlich erfolgen. Transaktionskontinuierlich bedeutet, dass jeweils nach einer erfolgreich ausgef¨ uhrten Transaktion eine neue Version angelegt wird. Anweisungskontinuierlich bedeutet, dass nach der Abarbeitung jedes einzelnen SQL–Statements eine neue Version entsteht. Bei der tupelkontinuierlichen Versionserstellung wird die Version durch Zeilentrigger ausgel¨ost, die bei jedem INSERT, UPDATE oder DELETE ausgef¨ uhrt werden. Die automatische Versionserstellung ist bei der hierarchischen Versionierung nicht mehr m¨oglich, da das Datenbankmanagementsystem nicht weiß, wann eine neue Verzweigung angelegt werden soll. Daher muss die Versionserstellung manuell unter Angabe der Elternversion erfolgen. ¨ Eine weitere Einschr¨ ankung betrifft die M¨oglichkeit, Daten zu ¨andern. Die Anderung ist nur in ¨ den Versionen m¨ oglich, die in den Bl¨ attern des Versionenbaumes zu finden sind. Anderungen an Versionen, die durch innere Knoten dargestellt werden, w¨ urden auch deren Nachfolgeversionen beeinflussen und sind somit nicht m¨oglich. Dies soll im folgenden Beispiel verdeutlicht werden, das den Versionenbaum aus Abbildung 2.2 verwendet: • in Version 2 wird ein neues Tupel eingef¨ ugt (id : 111, data: ’a’) • in Version 0 existiert kein Tupel mit der id 111 • in Version 0 wird ein neues Tupel eingef¨ ugt (id : 111, data: ’b’) • beim Zugriff auf die Version 2 und alle Versionen darunter gibt es nun einen Konflikt beim Tupel mit der id 111, dieses hat nun 2 verschiedene Attributwerte f¨ ur data (’a’ und ’b’)

2.2

Arten der Versionierung

Nach [1] wird in folgende drei Arten von Versionierungsstrategien unterschieden: • Versionierung mit Zeitstempel auf Tupelebene – Ohne Schattentabellen – Mit Schattentabellen • Versionierung mit Deltas auf Tupelebene • Versionierung auf Attributebene Diese Arten der (linearen) Versionierung werden im Folgenden etwas genauer beschrieben. F¨ ur die hierarchische Versionierung sind sie allerdings nicht alle geeignet.

12

2.2.1

Versionierung mit Zeitstempel auf Tupelebene ohne Schattentabellen

Im Falle der Versionierung mit Zeitstempel auf Tupelebene ohne Schattentabellen wird zu jedem Tupel noch dessen G¨ ultigkeitsbereich angegeben. Hierf¨ ur m¨ ussen zwei neue Attribute in die Relation eingef¨ ugt werden. Aus der Relation A A.id ...

A.attr ...

Tabelle 2.1: Tabelle A vor der Versionierung

wird nach der Umwandlung dies A.id ...

A.attr ...

A.Beginn ...

A.Ende ...

Tabelle 2.2: Tabelle A nach dem Einf¨ ugen der Versionierungsattribute

A.Beginn gibt an, in welcher Version das Tupel eingef¨ ugt wurde. A.Ende hingegen gibt an, bis zu welcher Version es in der Tabelle enthalten war. Ist es noch in der letzten (aktuellen) Version g¨ ultig, hat A.Ende den Wert -1. Somit k¨ onnen Anwendungen, die nichts von der Versionierung wissen, mit dem Zugriff auf eine View, die so definiert ist 1 2

CREATE VIEW A AS SELECT A neu . id , A neu . a t t r FROM A neu WHERE A neu . Ende = −1; auf die aktuellen Daten der Tabelle A zugreifen. Mit einer ¨ahnlich gestalteten View ist es auch m¨oglich, den Zugriff auf eine beliebige Version zu erm¨oglichen.

2.2.2

Versionierung mit Zeitstempel auf Tupelebene mit Schattentabellen

Bei der Versionierung mit Zeitstempel auf Tupelebene mit Schattentabellen wird nicht die Original-Relation ver¨ andert, sondern es wird eine zus¨atzliche Relation f¨ ur jede Tabelle angelegt. Diese neue Tabelle hat den gleichen Aufbau wie die ver¨anderte Tabelle aus der Versionierung mit Zeitstempel auf Tupelebene ohne Schattentabellen (Tabelle 2.2)

2.2.3

Versionierung mit Deltas auf Tupelebene

Bei der Versionierung mit Deltas auf Tupelebene werden nicht die kompletten Versionen, ¨ ¨ sondern nur ihre Anderungen gespeichert. Welche Anderungen gespeichert werden, wird im Folgenden beschrieben. KVR (vn ) bezeichnet im Folgenden die komplette Version der Relation R mit der Versionsnummer n. Die Ursprungsversion ist v0 . Die Unterschiede zwischen den Versionen i und j werden mit ∆R (vi , vj ) bezeichnet. Im Allgemeinen kann man dabei vier Strategien unterscheiden: 13

VS-1 KVR (vn ) = KVR (v0 ) + ∆R (v0 , v1 ) + . . . + ∆R (vn−2 , vn−1 ) + ∆R (vn−1 , vn ) Diese Strategie ist vorw¨ artsorientiert. Das heißt, es wird die Ursprungsversion abgespeichert. Wird eine neue Version eingef¨ ugt, m¨ ussen die Unterschiede von dieser zu ihrer direkten Vorg¨angerversion gespeichert werden. Die n–te Version erh¨alt man, indem man von der Ursprungsversion ausgehend alle Deltas aller Vorg¨angerversionen nacheinander anwendet. VS-2 KVR (vn ) = KVR (v0 ) + ∆R (v0 , vn ) Auch diese Strategie ist vorw¨ artsorientiert. Bei ihr werden nicht die Deltas zur unmittelbaren Vorg¨angerversion, sondern die Deltas zur Ursprungsversion abgespeichert. Dadurch kann man jede Version u ¨ber maximal zwei Versionen erzeugen. Die dabei entstehenden Deltas k¨onnen schnell recht groß werden. VS-3 KVR (v0 ) = KVR (vn ) + ∆R (vn , vn−1 ) + . . . + ∆R (v2 , v1 ) + ∆R (v1 , v0 ) Bei dieser Strategie wird die immer die letzte (aktuelle) Version gespeichert. F¨ ur jede Vorg¨angerversion wird immer das Delta zu deren Vorg¨angerversion gespeichert. Daher nennt man dieses Verfahren r¨ uckw¨ artsorientiert. VS-4 KVR (v0 ) = KVR (vn ) + ∆R (vn , v0 ) Auch hierbei handelt es sich um ein r¨ uckw¨artsorientiertes Verfahren. Es wird aber zu jeder Vorversion ein Delta zur letzten (aktuellen) Version gespeichrt. Das heißt aber auch, dass ¨ bei jeder Anderungen an der aktuellen Version die Deltas aller Vorg¨angerversion ver¨andert werden m¨ ussen.

2.2.4

Versionierung auf Attributebene

¨ Da sich bei Anderungen in Tupeln nicht unbedingt immer alle Attributwerte a¨ndern, ist es auch vorstellbar, nur die ge¨ anderten Attributwerte zu speichern. Um die Ver¨ anderungen auf Attributebene durchf¨ uhren zu k¨onnen, muss die Originalrelation in Teilrelationen zerlegt werden – eine f¨ ur jedes Attribut, das nicht zum Prim¨arschl¨ ussel geh¨ort. Diese Relationen enthalten den Prim¨arschl¨ ussel, ein Attribut und die Attribute f¨ ur Beginn und Ende der G¨ ultigkeit des Tupels. Die folgenden Tabellen sollen dies verdeutlichen. A.id ...

A.attr1 ...

A.attr2 ...

Tabelle 2.3: Tabelle A vor der Versionierung

14

A 1.id ...

A 1.attr1 ...

A 1.beginn ...

A 1.ende ...

Tabelle 2.4: Teil-Tabelle A 1 nach der Zerlegung

A 2.id ...

A 2.attr2 ...

A 2.Beginn ...

A 2.Ende ...

Tabelle 2.5: Teil-Tabelle A 2 nach der Zerlegung

Die Prim¨ arschl¨ ussel A 1.id und A 2.id der neuen Relationen sind mit dem Prim¨arschl¨ ussel der alten Relation identisch.

15

Kapitel 3

Entwicklung einer hierarchischen Versionierung Wie schon (weiter oben) beschrieben, gibt es verschiedene Strategien, wie man die Unterschiede der einzelnen Versionen im Datenbankmanagementsystem darstellt. Ich habe mich f¨ ur die Speicherung der Deltas zwischen zwei Versionen entschieden. Hierbei werden in der ¨ Repr¨asentation der Kind-Version lediglich die Anderungen zur Vorg¨angerversion gespeichert. Dies hat den Vorteil, dass die Daten, die in einer zeitigen Version ge¨andert oder eingef¨ ugt wurden, nicht in jeder nachfolgenden Version erneut gespeichert werden m¨ ussen. Allerdings muss ¨ man, um die Daten einer gew¨ unschten Version wiederherstellen zu k¨onnen, die Anderungen jede ihrer Vorg¨ angerversionen ausf¨ uhren.

3.1

Einfu ¨ hrung von Begriffen

Unter einem Versionenbaum versteht man einen gerichteten Baum, in dem alle existierenden Versionen und ihre Beziehungen untereinander ersichtlich sind. Ein Beispiel findet sich in Abbildung 3.1 auf Seite 18. Gespeichert wird allerdings nicht der Baum selbst, sondern eine Repr¨asentation des Baumes in der Relation versions. Deren Struktur ist in Tabelle 3.1 auf Seite 19 zu sehen. Unter inneren Knoten eines Baumes versteht man die Elemente (Knoten) eines Baumes, von denen Kinder existieren. Diese Knoten haben also mindestens einen Nachfolger. Im Beispiel in Abbildung 3.1 auf Seite 18 sind das die Konten 0, 2, 3, 4 und 5. Unter Bl¨ atter eines Baumes versteht man die Elemente (Knoten) eines Baumes, von denen keine Kinder existieren. Das heißt diese Knoten haben keinen Nachfolger. Im Beispiel in Abbildung 3.1 auf Seite 18 sind das die Konten 1, 6, 7, 8 und 9. Die Vorg¨ anger-Versionen einer Version (eines Knotens) sind alle Versionen, die auf dem direkten Weg von der entsprechenden Version zur Wurzel des Baumes passiert werden. Im Beispiel in Abbildung 3.1 auf Seite 18 sind die Vorg¨anger-Versionen von Version 4 die Versionen 3, 2 und 0. Nachfolger-Versionen von einer Version (einem Knoten) sind alle Versionen, die sich im Baum unterhalb der entsprechenden Version befinden. Im Beispiel in Abbildung 3.1 auf Seite 18 sind die Nachfolger-Versionen von Version 4 die Versionen 6 und 7.

17

Unter der Versions-Nummer versteht man die eineindeutige Repr¨asentation einer Version im Versionenbaum. Ein Pre-Post-Order-Index ist eine einfache, aber effiziente Art der Indizierung eines Baumes. Hierbei wird bei einem depth-first-Ablaufen des Baumes jeder Knoten bei seinem ersten und letzten Kontakt mit einer steigenden Zahl beschriftet. Hier ist ein Beispiel zu sehen:

Abbildung 3.1: Pre–Post–Order–Index

Eine solche Indizierung ist notwendig, um effizient die Vorg¨anger-Nachfolger-Beziehungen der existierenden Versionen ermitteln zu k¨ onnen. Beim Start einer neuen Session wird dieses Package initialisiert. Dabei wird die aktuelle Version auf die Version 0 gesetzt. Ist eine andere Start-Version gew¨ unscht, so muss dies in der Zeile 191 des Package eingetragen werden. Bei jedem Aufruf der set version wird die Variable aktuelle version gesetzt und die zu der entsprechenden Version geh¨ orenden Werte f¨ ur Pre- und Post-Order-Index in die Variablen actual pre und actual post geschrieben.

3.2

Idee einer hierarchischen Versionierung

Ziel einer hierarchischen Versionierung ist es, effizient auf alle existierenden Versionen zugreifen zu k¨onne, ohne das sp¨ urbare Performaceverluste beim Zugriff auf tief im Versionenbaum liegende Versionen zu erkennen sind. Ausgehend von einer nicht versionierten Tabelle sieht man, dass einige Bedingungen unbedingt zu beachten sind. Zum Beispiel muss es ausgeschlossen sein, dass es zu Inkonsistenzen in den Daten kommt. Da s¨ amtliche Daten (aller existierenden Versionen) in einer Datentabelle gespeichert werden, ist es notw¨andig, eine Verwaltungsinformationen zu den Tupeln hinzuzuf¨ ugen. Dies ist vor allem die Information, zu welcher Version das entsprechende Tupel geh¨ort. Wenn in einer Version, die nicht die Wurzel des Versionenbaumes darstellt, ein Tupel gel¨oscht werden soll, so darf dieses nicht einfach aus der Tabelle entfernt werden. Dies w¨ urde das entsprechende Tupel auch in allen anderen Versionen mit l¨oschen. Dies ist allerdings nicht gew¨ unscht. Somit muss ein zu l¨ oschendes Tupel lediglich als gel¨oscht gekennzeichnet werden. Auch hier ist wieder eine zus¨ atzliche Verwaltungsinformation notwendig. Es muss gespeichert 18

werden, welche Aktion mit einem Tupel durchgef¨ uhrt wurde. Die kann das Einf¨ ugen eines neuen Tupels oder das L¨ oschen eines bestehenden Tupels sein. Diese Information, verbunden ¨ mit der Versionsnummer, in der diese Anderung g¨ ultig ist, wird mit in das entsprechende Tupel geschrieben. Es ist vollkommen ausreichend, wenn man die Aktionen Einf¨ ugen und ¨ L¨oschen einf¨ uhrt. Ein Andern der Daten kann u ugen ¨ber ein L¨oschen und anschließendes Einf¨ abgebildet werden. Um die Menge der gespeicherten Informationen so gering wie m¨oglich zu halten, werden lediglich die Deltas zur Vorg¨ angerversion gespeichert. Dies bedeutet aber auch, dass beim Zugriff auf eine Version etwas Rechenaufwand notwendig ist. Ausgehen von der gew¨ unschten Version muss eine Versionenkette mit den jeweiligen Vorg¨angerversionen ermittelt werden. Dies kann mittels beispielsweise unter Verwendung des Pre-Post-Oreder-Index erfolgen. Beginnend mit der Ursprungsversion (Wurzel des Versionenbaumes) wird nun, der Versionenkette entlang, jede Zwischenversion erzeugt, bis schließlich die gew¨ unschte Version berechnet wird. Diese wird, ohne den Verwaltungsinformationen, als View zur Verf¨ ugung gestellt. Somit ist es m¨oglich, dass auch Altanwendungen, die keine Kenntnis von der Versionierung haben, auf diese Daten zugreifen k¨ onnen. Alle Anfragen werden an diese View gestellt und intern durch das Datenbankmanagementsystem umgewandelt. Die genaue Funktion der hier entwickelten Versionierungsstrategie wird im Folgenden n¨aher erl¨autert.

3.3

Verwaltung der Versionen

Bei der linearen Versionierung ist es nicht notwendig, die Vorg¨anger-Nachfolger-Beziehung zwischen den einzelnen Versionen abzuspeichern, da jede neue Version automatisch die n¨achste Versions-Nummer erh¨ alt. Somit ist klar, dass zum Beispiel die Version 4 der Nachfolger der Version 3 ist. Bei der hierarchischen Versionierung hingegen ist es notwendig, die Vorg¨angerNachfolger-Beziehungen der einzelnen Versionen zu speichern. Diese sind in einem Baum darstellbar. Um auf die einzelnen Versionen wieder zugreifen zu k¨onnen, muss jeder Knoten des Baumes effizient ansprechbar“ sein. Das heißt, es muss m¨oglich sein, jede Version ” ohne große Zeitverz¨ ogerung ausrufen zu k¨onnen. Um die gew¨ unschte Version berechnen zu k¨onnen, muss es m¨ oglich sein, die Liste der Vorg¨angerversionen ermitteln zu k¨onnen. Dies ist notwendig, da zu jeder Version lediglich die Ver¨anderungen zur Vorg¨anger-Version gespeichert werden. Auch muss man ermitteln k¨onnen, ob es sich um ein Blatt oder um einen Knoten handelt. Mittels des Pre-Post-Order-Index ist dies m¨oglich.

3.3.1

Tabelle versions

Die Versionen werden in der Tabelle versions verwaltet, die folgende Struktur besitzt. versions id versions pre versions post

INTEGER INTEGER INTEGER

NOT NULL NOT NULL NOT NULL

Tabelle 3.1: Tabelle versions

19

Jede erzeugte Version wird in diese Relation automatisch mit ihrer Versions-Nummer und den Werten des Pre-Post-Order-Index eingetragen. Initialisiert wird diese Tabelle beispielsweise mit dem folgenden Eintrag: (0, 0, 10 ). Hierbei wird der Version 0 der Pre-Index 0 und der Post-Index 10 zugeordnet.

3.3.2

Erzeugung einer neuen Version

Die PL/SQL–Prozedur make child(parent version integer) erzeugt einen neuen Knoten unterhalb der als Parameter u ¨bergebenen Version parent version. Es wird die gr¨ oßte bisher vergebene Versionsnummer ermittelt. Aus dieser wird die Versionsnummer f¨ ur die neue Version ermittelt. Der Pre-Index und der Post-Index von parent version, also der Eltern-Version, wird ermittelt. Es wird festgestellt, ob die Eltern-Version (parent version) schon eine Nachfolgerversion besitzt. Ist dies der Fall, hat die neue Version bereits eine Nachbarversion. Wenn Pre– und Post–Index der neuen Version ermittelt sind, wird gepr¨ uft, ob die neue Version mit diesen Daten eingef¨ ugt werden kann. Ist dies nicht der Fall, muss zuerst der gesamte Index erweitert werden. Hierzu wird automatisch die Prozedur make tree bigger(faktor integer) mit dem Faktor 10 aufgerufen. Dabei wird in der Tabelle versions jeder Wert f¨ ur Pre- und Post-Index mit dem Faktor 10 multipliziert. Somit werden wieder Zwischenr¨ aume zwischen den Indizes geschaffen. Ein weiteres Einf¨ ugen von Versionen ist damit m¨ oglich. Dies kann solange gemacht werden, bis beim gr¨oßtem Index, also dem Post-Index der Ursprungsversion, der Wert von MaxInt erreicht wird. Anschließend wird die Prozedur make child(parent version integer) erneut aufgerufen. Die Versions-Nummer der neu erzeugten Version wird ausgegeben. Sie kann auch mit der Funktion show last version ermittelt werden.

3.4

Ver¨ anderungen an den Datentabellen

F¨ ur die Betrachtung der entwickelten hierarchischen Versionierung nehmen wir folgende Ausgangsdatentabelle data an: data id data attr

INTEGER ...

NOT NULL

Tabelle 3.2: Tabelle data (alt)

Hierbei handelt es sich bei der Spalte data id um den Prim¨arschl¨ ussel der Tabelle. Der Prim¨arschl¨ ussel der Tabelle kann auch mehrteilig sein. Dies ist dann allerdings in der Triggern und in der Generatorfunktion auch zu ber¨ ucksichtigen. Das Attribut data attr steht hier nur exemplarisch f¨ ur eine unbekannte Anzahl an Spalten von beliebigem Typ. F¨ ur die Verwaltung der Versionierungsinformationen werden in der Tabelle data drei zus¨atzliche Attribute ben¨ otigt.

20

data id data attr data version data action data counter

INTEGER ... INTEGER INTEGER INTEGER

NOT NULL NOT NULL NOT NULL NOT NULL

Tabelle 3.3: Tabelle data (neu)

Im Attribut data version wird die Versionsnummer abgelegt, zu der das entsprechende Tupel geh¨ort. Im Feld data action wird die mit dem Tupel durchgef¨ uhrte Aktion als INTEGERWert gespeichert. Ein Einf¨ ugen wird mit der Zahl 1, ein L¨ oschen mit der Zahl 2 dargestellt. ¨ Ein Andern wird als L¨ oschen und Einf¨ ugen simuliert. In der Spalte data counter wird jeder Aktion eine Sequenznummer als Zeitstempel zugeordnet. Dies wird ben¨otigt, um sp¨ater zu pr¨ ufen, ob es sp¨ atere Aktionen f¨ ur ein bestimmtes Tupel in einer Version gibt. Soll eine bereits bestehende Tabelle f¨ ur die Versionierung erg¨anzt werden, so m¨ ussen diese drei Spalten eingef¨ ugt werden und mit folgenden Standardwerten gef¨ ullt werden: Attribut data version data action data counter

Wert 0 1 0

Bemerkung Ursprungsversion Aktion Einf¨ ugen hier ist es wichtig, dass die n¨achste vergebene Zahl gr¨oßer als die Initialisierung ist

Tabelle 3.4: Initialwerte

Zus¨atzlich sollte auch noch die Tabelle umbenannt werden.

3.5

Zugriff auf die versionierte Tabelle

Beim Connect mit der Datenbankinstanz wird f¨ ur jede Session eine neue Instanz des Packages h versions erzeugt. Bei dessen Initialisierung wird die Variable actual version auf 0 gesetzt, ur die Version 0 gesetzt. sowie die Variablen actual pre und actual post mit den Werten f¨ Um die Version zu wechseln, muss folgender Befehl ausgef¨ uhrt werden: 1

exec h v e r s i o n s . s e t v e r s i o n ( 3 ) ; Dabei wird durch die Prozedur set version(version integer) die Variable actual version ge¨andert und die Werte f¨ ur actual pre und actual post aktualisiert. F¨ ur jede versionierte Tabelle muss eine Generatorfunktion im Package h versions enthalten sein, die die Daten der gew¨ unschten Version aus den Informationen der Tabellen hv data und versions generiert. In unserem Beispiel ist dies die Funktion data alt. Diese Funktion liefert als R¨ uckgabewert eine Pipeline des Typs data tabellentyp. Die Funktion data alt berechnet mittels Cursor alle Eintr¨age der gew¨ unschten Version und ihrer Vorg¨ angerversionen. Der entsprechende SQL-Code ist im Listing des Package h versions in den Zeilen 92 bis 135 zu sehen.

21

Die Berechnung muss in zwei Schritten erfolgen. Im ersten Schritt werden alle Eintr¨age ermittelt, die in der gew¨ unschten Version und deren Vorg¨angerversionen eingef¨ ugt werden (data action = 1 ), ohne dass sie wieder gel¨oscht werden (NOT EXISTS ... data action = 2 ). Der zweite Schritt ermittelt f¨ ur jedes Tupel, das in der Versionsgeschichte gel¨oscht und wieder ¨ eingef¨ ugt wird, mithilfe des Attributes data counter den aktuellen Wert. Da Anderungen immer nur in Bl¨ attern m¨ oglich sind, ist somit garantiert, dass dies auch immer der gew¨ unschte Wert ist. Diese Selektion wird durch Negation der Bedingung (NOT EXISTS ... data action = 2 ) aus dem ersten Teil in (EXISTS ... data action = 2 ) und Kombination mit (NOT EXISTS ... data 3.data counter > data 1.data counter ) erreicht. Die ben¨otigten Daten (data id und data attr ) des so erhaltenen Cursor werden in der Funktion data alt solange in die Pipeline gesendet, wie noch Elemente im Cursor verf¨ ugbar sind. Somit sind die Daten der gew¨ unschten Version der versionierten Tabelle data als Ergebnis der PL/SQL-Funktion erh¨ altlich. Um auch den Zugriff von Altanwendungen zu erm¨oglichen, wird das Ergebnis noch in eine View namens data gepackt. Diese ist so definiert: SELECT ∗ FROM TABLE( h v e r s i o n s . d a t a a l t )

1

Somit k¨onnen auch Anwendungen, die keinerlei Kenntnis von der Versionierung haben, noch auf die Daten aus einer beliebigen Version zugreifen. Es muss lediglich sichergestellt werden, dass die entsprechende Version zuvor ausgew¨ahlt wurde.

3.6

Datenmanipulationen

Um auch Altanwendungen die Manipulation von Daten zu erm¨oglichen, wurden Trigger implementiert, die die Manipulation von Daten in der View data abfangen und regelkonform in die versionsverwaltende Tabelle hv data u ur INSERT, ¨bertragen. Hierbei sind Trigger f¨ UPDATE und DELETE notwendig. In den folgenden Triggern wird bei jedem Insert auch der Wert f¨ ur data counter mit geschrieben. Dieser wird durch die Funktion next seqnumber erzeugt. Die Trigger sind wie folgt definiert:

3.6.1 1 2 3 4 5 6 7 8 9 10 11 12 13 14

insert data-Trigger

TRIGGER ”INSERT DATA” INSTEAD OF INSERT ON DATA REFERENCING NEW AS added BEGIN IF ( h v e r s i o n s . h a s c h i l d = 0 ) THEN INSERT INTO h v d a t a ( d a t a i d , d a t a v e r s i o n , data action , data attr , data counter ) VALUES ( : added . d a t a i d , h v e r s i o n s . a c t u a l v e r s i o n , 1 , : added . d a t a a t t r , h v e r s i o n s . next seqnumber ) ; ELSE raise application error ( −20001 , ’ Es koennen nur V e r s i o n e n i n B l a e t t e r n ’ | | ’ v e r a e n d e r t werden ! ’ ) ; 22

15 16

END IF ; END; Der insert data-Trigger ersetzt das Einf¨ ugen in die View data. Nach der Pr¨ ufung, ob es sich um eine Blattversion handelt, wird in die Tabelle hv data ein neuer Datensatz eingef¨ ugt, der die aktuelle Versionsnummer (data version), die Original-Tupel-ID (data id ), die Aktionskennung 1 (f¨ ur Einf¨ ugen) (data action) und alle Tupel-Attribute (data attr ) enth¨alt. Sollte es sich bei der aktuellen Version nicht um ein Blatt handeln, wird lediglich eine Fehlermeldung ausgegeben.

3.6.2 1 2 3 4 5 6 7 8 9

delete data-Trigger

TRIGGER ”DELETE DATA” INSTEAD OF DELETE ON DATA REFERENCING OLD AS d e l e t e d BEGIN IF ( h v e r s i o n s . h a s c h i l d = 0 ) THEN DELETE FROM h v d a t a WHERE d a t a i d = : d e l e t e d . d a t a i d AND d a t a v e r s i o n = h v e r s i o n s . a c t u a l v e r s i o n AND d a t a a c t i o n = 2 ;

10 11 12 13 14 15 16 17 18 19 20

INSERT INTO h v d a t a ( data id , data version , data action , data counter ) VALUES ( : d e l e t e d . d a t a i d , h v e r s i o n s . a c t u a l v e r s i o n , 2 , h v e r s i o n s . next seqnumber ) ; ELSE raise application error ( −20001 , ’ Es koennen nur V e r s i o n e n i n B l a e t t e r n ’ | | ’ v e r a e n d e r t werden ! ’ ) ; END IF ; END; Der delete data-Trigger ersetzt das L¨ oschen in der View data. Nach der Pr¨ ufung, ob es sich um eine Blattversion handelt, werden in der Tabelle hv data zun¨achst alle Tupel gel¨oscht, die sich bereits auf die entsprechende Version, Prim¨arschl¨ ussel (data id ) und Aktion (data action = 2 ) beziehen. Somit wird sichergestellt, dass keine doppelten L¨oscheintr¨age Probleme bei der Wiederherstellung der Daten machen. Danach wird ein neuer Datensatz eingef¨ ugt, der die aktuelle Versionsnummer (data version), die Original-Tupel-ID (data id ) und die Aktionskennung 2 (f¨ ur L¨ oschen) (data action) enth¨alt. Eine Fehlermeldung wird ausgegeben, wenn sich das L¨ oschen auf eine Version bezieht, die keine Blatt-Version ist.

3.6.3

update data-Trigger

Der update data-Trigger ist eine Kombination aus dem delete data-Trigger und dem insert data-Trigger.

23

Kapitel 4

Beispiel einer Versionierung 4.1 4.1.1

Ausgangstabelle Struktur data id data attr

INTEGER VARCHAR2(200)

NOT NULL

Tabelle 4.1: Struktur der Tabelle data

Die Tabelle data enth¨ alt zwei Spalten. data id ist der Prim¨arschl¨ ussel der Tabelle.

4.1.2

Inhalt data id 1 2 3

data attr ‘1.0’ ‘2.0’ ‘3.0’

Tabelle 4.2: Inhalt der Tabelle data

Diese Daten befinden sich bereits vor der Versionierung in der Tabelle data.

25

4.2

Umgewandelte und neu erzeugte Tabellen - Schritt 1

4.2.1

Struktur data id data attr data version data action data counter

INTEGER VARCHAR2(200) INTEGER INTEGER INTEGER

NOT NULL NOT NULL NOT NULL NOT NULL

Tabelle 4.3: Struktur der Tabelle hv data

Es wurden die Versionsverwaltungsspalten data version, data action und data counter eingef¨ ugt und die Tabelle wurde nach hv data umbenannt. versions id versions pre versions post

INTEGER INTEGER INTEGER

NOT NULL NOT NULL NOT NULL

Tabelle 4.4: Struktur der Tabelle versions

Die Tabelle versions wurde neu erstellt.

4.2.2

Inhalt data id 1 2 3

data attr ‘1.0’ ‘2.0’ ‘3.0’

data version 0 0 0

data action 1 1 1

data counter 0 0 0

Tabelle 4.5: Inhalt der Tabelle hv data

Die vorhandenen Tupel der Tabelle hv data wurden durch die initialen Versionsverwaltungsinformationen (data version = 0, data action = 1, data counter=0 ) erg¨anzt. versions id 0

versions pre 0

versions post 10

Tabelle 4.6: Inhalt der Tabelle versions

In die Tabelle versions wurde die Ursprungsversion mit den Werten versions pre = 0 und ugt. versions post = 10 eingef¨ Es werden nacheinander drei Unterversionen (1, 2, 3 ) von der Version 0 gebildet. Hierf¨ ur werden folgende Befehle ausgef¨ uhrt: exec h_versions.set_version(0);

26

exec h_versions.make_Child(0); exec h_versions.make_Child(0); exec h_versions.make_Child(0);

4.2.3

Ver¨ anderungen

Die aktuelle Version wird auf 2 gesetzt. exec h_versions.set_version(2); Es werden folgende Tupel eingef¨ ugt: data id 4 5 6

data attr ‘4.2’ ‘5.2’ ‘6.2’

Tabelle 4.7: neue Tupel f¨ ur der Tabelle data

Die Inserts werden direkt an die View data gerichtet: INSERT INTO data (data_id, data_attr) VALUES (4, ‘4.2’); (usw.) Durch den Trigger insert data wird dies abgefangen und stattdessen an die Tabelle hv data weitergereicht. Dort wird folgendes ausgef¨ uhrt: INSERT INTO hv_data (data_id, data_version, data_action, data_attr) VALUES (4, 2, 1, ‘4.2’); (usw.) Dieses Statement wird wiederum durch den Trigger insert hv data erweitert zu: INSERT INTO hv_data (data_id, data_version, data_action, data_counter, data_attr) VALUES (4, 2, 1, 1, ‘4.2’); (usw.)

4.3 4.3.1

Umgewandelte und neu erzeugte Tabellen - Schritt 2 Inhalt

Nach dem Einf¨ ugen sind folgende Tabellen im Datenbankmanagementsystem gespeichert.

27

data id 1 2 3 4 5 6

data attr ‘1.0’ ‘2.0’ ‘3.0’ ‘4.2’ ‘5.2’ ‘6.2’

data version 0 0 0 2 2 2

data action 1 1 1 1 1 1

data counter 0 0 0 1 2 3

Tabelle 4.8: Inhalt der Tabelle hv data

versions id 0 1 2 3

versions pre 0 30 70 86

versions post 100 60 80 93

Tabelle 4.9: Inhalt der Tabelle versions

Beim Anlegen der drei Unterversionen der Ursprungsversion 0 passierte folgendes: Version 0 1 2 3

p pre

v pre v post 0 10     1 2 0 10 0 10 0 + 10 · 13 = 3 0 + 10 · 23 = 6 0 10 6 4 6 + 4 · 31  = 7 6 + 4 · 32  = 8 8+2· 3 =8 8+2· 3 =9 0 10 8 2 Eintrag 3 kann nicht geschrieben werden, (neighbour post = versions post) der Baum muss zuerst erweitert werden, die Werte versions pre und versions post der bestehenden Eintr¨ age werden mit dem Faktor 10 multipliziert

0 1 2 3

0

p post

n post

Diff.

Es ergeben sich folgende Eintr¨age: 0 30 70 neuer Versuch des Einf¨ ugens der Version 3   100 80 20 80 + 20 · 13 = 86

100 60 80 

80 + 20 ·

Tabelle 4.10: Anlegen der Versionen 1 bis 3 unter der Version 0

28

2 3



= 93

Spaltenname Version p pre p post n post Diff. v pre v post

Beschreibung Versions-Id Pre–Index der Eltern–Version Post–Index der Eltern–Version Post–Index der Geschwister–Version oder 0 Differenz zwischen p pre bzw. n post und p post Pre–Index der neuen Version Post–Index der neuen Version

Tabelle 4.11: Erl¨ auterung der Spaltennamen von Tabelle 4.10

4.3.2

Ver¨ anderungen

Es werden nacheinander 2 Unterversionen (4, 5 ) von der Version 2 gebildet. Die aktuelle Version wird auf 4 gesetzt. Das Tupel mit data id = 5 wird gel¨oscht. data attr wird beim Tupel mit data id = 6 auf data attr=’6.4’ ge¨andert. Es werden folgende Tupel eingef¨ ugt: data id 7

data attr ‘7.4’

Tabelle 4.12: neue Tupel f¨ ur der Tabelle data

4.4 4.4.1

Umgewandelte und neu erzeugte Tabellen - Schritt 3 Inhalt data id 1 2 3 4 5 6 5 5 6 7

data attr ‘1.0’ ‘2.0’ ‘3.0’ ‘4.2’ ‘5.2’ ‘6.2’

‘6.4’ ‘7.4’

data version 0 0 0 2 2 2 4 4 4 4

data action 1 1 1 1 1 1 2 2 1 1

Tabelle 4.13: Inhalt der Tabelle hv data

29

data counter 0 0 0 1 2 3 4 5 6 7

versions id 0 1 2 3 4 5

versions pre 0 30 70 86 73 77

versions post 100 60 80 93 76 78

Tabelle 4.14: Inhalt der Tabelle versions

4.5 4.5.1

Inhalte der angelegten Versionen der Tabelle data Versionenbaum

Abbildung 4.1: Versionenbaum

4.5.2

Version 0 data id 1 2 3

data attr ‘1.0’ ‘2.0’ ‘3.0’

Tabelle 4.15: Inhalt der Tabelle data – Version 0

4.5.3

Version 1 data id 1 2 3

data attr ‘1.0’ ‘2.0’ ‘3.0’

Tabelle 4.16: Inhalt der Tabelle data – Version 1

30

4.5.4

Version 2 data id 1 2 3 4 5 6

data attr ‘1.0’ ‘2.0’ ‘3.0’ ‘4.2’ ‘5.2’ ‘6.2’

Tabelle 4.17: Inhalt der Tabelle data – Version 2

4.5.5

Version 3 data id 1 2 3

data attr ‘1.0’ ‘2.0’ ‘3.0’

Tabelle 4.18: Inhalt der Tabelle data – Version 3

4.5.6

Version 4 data id 1 2 3 4 6 7

data attr ‘1.0’ ‘2.0’ ‘3.0’ ‘4.2’ ‘6.4’ ‘7.4’

Tabelle 4.19: Inhalt der Tabelle data – Version 4

4.5.7

Version 5 data id 1 2 3 4 5 6

data attr ‘1.0’ ‘2.0’ ‘3.0’ ‘4.2’ ‘5.2’ ‘6.2’

Tabelle 4.20: Inhalt der Tabelle data – Version 5

31

Kapitel 5

Vergleichende Messung Neben der Entwicklung einer Methode f¨ ur die hierarchische Versionierung war auch deren vergleichende Messung ein Ziel dieser Studienarbeit. Zum Vergleich stehen eine Datenbank ohne Versionierung, die neu entwickelte Versionierungsstrategie dieser Studienarbeit und der Oracle Workspace Manager.

5.1

Swissprot

Da f¨ ur einen aussagekr¨ aftigen Vergleich eine große Menge an Daten verarbeitet werden muss, wurde auf die Daten vom Swissprot [10] zur¨ uckgegriffen, die auch schon in [1] Verwendung fanden. F¨ ur das Einf¨ ugen wurden die Releases 37 und 44 verwendet. Das Release 37 enth¨ alt 77977 und das Release 44 153871 Entries. Es wurden die Geschwindigkeiten f¨ ur das Einf¨ ugen und das Zugreifen auf die beiden Versionen gemessen. Beim Einf¨ ugen von Release 44 wurde mit dem Einf¨ ugetools stets gepr¨ uft, ob das einzuf¨ ugende Tupel bereits in der Vorg¨angerVersion (Release 37 ) vorhanden war. Wenn es identisch vorhanden ist, wurde es nicht erneut eingef¨ ugt. War es mit Unterschiedlichen Daten enthalten, wurde ein Update ausgef¨ uhrt. Nach dem Einf¨ ugen von Release 44 wurde eine neue Version unterhalb von Release 44 erstellt. In dieser wurden 10000 Entries ver¨ andert. Dieses Release wird als Release 44-1 bezeichnet. Unterhalb dieser Version wurde ebenfalls eine neue Version angelegt. Hier wurden 5000 Entries gel¨oscht. Dieses Release wird als Release 44-2 bezeichnet.

5.2

Testumgebung

Alle Messungen wurden unter den gleichen Software- und Hardwarebedingungen durchgef¨ uhrt. Allerdings kann es durch automatische Hintergrundprozesse des Betriebssystems zu leichten Schwankungen kommen. Es wurde die Oracle Datenbank in Version 10g Release 2 (10.2) f¨ ur Microsoft Windows (32-Bit) verwendet. Gemessen wurde auf einen PC mit einem Intel Core2Duo 6600 mit 2,40 GHz und 2048 MB RAM. Als Betriebssystem wurde Windows Vista Ultimate eingesetzt. Als Client wurde der Oracle SQL Developer eingesetzt.

33

5.3

Einfu ¨ gen der Daten

Zur Messung der Einf¨ ugegeschwindigkeit kam das von Stephan Rieche in [1] entwickelte JavaProgramm swissparse zum Einsatz, das um die Funktionalit¨at des Zugriffs auf die hierarchischen Versionen erweitert wurde. Das Programm liest die Datendateien der einzuf¨ ugenden Relation und erstellt daraus die n¨ otigen SQL-Statements zum Einf¨ ugen der Daten in die Datenbank. Dabei wird die Zeit gemessen, die f¨ ur das Einf¨ ugen ben¨otigt wird. Die entsprechenden Geschwindigkeiten in eingetragenen Bl¨ocken pro Sekunde, bzw. die Dauer des Eintragens sind in den Tabellen 5.1 und 5.2 sowie in den Diagrammen in den Abbildungen 5.1 und 5.2 zu sehen. Etwaige Schwankungen in den Geschwindigkeiten sind u.a. durch Hintergrundaktivit¨aten des Betriebssystems zu begr¨ unden.

ohne Versionierung mit Versionierung mit Workspace Manager

Release 37 56,4 13,2 9,3

Release 44 52,5 7,3 7,1

Tabelle 5.1: Entries pro Sekunde beim Einf¨ ugen

ohne Versionierung mit Versionierung mit Workspace Manager

Release 37 00:23:23 01:39:41 02:20:37

Release 44 00:49:11 06:58:23 06:20:22

Tabelle 5.2: Dauer des Einf¨ ugens Einf¨ ugen in hh:mm:ss

34

70,0

Einfügen Relation 37

60,0

Einträge pro Sekunde

50,0

40,0 ohne Versionierung mit Versionierung WSM

30,0

20,0

10,0

0,0 0

10000

20000

30000

40000

50000

60000

70000

Eintrag

Abbildung 5.1: Geschwindigkeit des Einf¨ ugens des Release 37

35

80000

70,0

Einfügen Relation 44

60,0

Einträge pro Sekunde

50,0

40,0 ohne Versionierung mit Versionierung

30,0

mit Workspace Manager

20,0

10,0

0,0 -5000

15000

35000

55000

75000

95000

115000

135000

155000

Eintrag

Abbildung 5.2: Geschwindigkeit des Einf¨ ugens des Release 44

Es ist hier zu sehen, dass das Einf¨ ugen in die Datenbank ohne Versionierung deutlich schneller vonstatten geht. Es handelt sich hier ungef¨ahr um den Faktor 7. Das war so zu erwarten, da beim reinen Einf¨ ugen keine zus¨ atzlichen Trigger ausgef¨ uhrt werden m¨ ussen. Man sieht auch, dass die Leistungsf¨ ahigkeit des neu entwickelten Systems an die des Oracle Workspace Managers herankommt. F¨ ur das Einf¨ ugen des Release 44 wird mehr Zeit ben¨otigt, da dieses auch mehr einzutragende Entries enth¨ alt.

5.4

Zugriff auf Versionen

Beim Zugriff auf die Relationen einer Datenbank kann es durch den Buffer zu unterschiedlichen Zugriffszeiten f¨ ur eine identische Anfrage kommen. Um diesen Effekt nahezu auszuschalten, wurde bei der Messung der Geschwindigkeiten bei lesenden Zugriffen 4 Einzelanfragen nacheinander gestellt und die Messergebnisse gemittelt. Da nur die reine Zeit f¨ ur den Datenzugriff ermittelt werden sollte, wurde in Anlehnung an [1] wiederum mit Cursors gearbeitet. ¨ Somit konnte die Ubertragungszeit der Ergebnisse zum Client eliminiert werden. Es werden die folgenden SQL-Statements verwendet: 1

SQL 1 : SELECT ∗ FROM i d e n t i f i c a t i o n ;

2 3 4

SQL 2 : SELECT ∗ FROM i d e n t i f i c a t i o n a j o i n r e f e r e n c e b on ( a . i d=b . i d ) ;

5

36

SQL 3 : SELECT ∗ FROM i d e n t i f i c a t i o n a j o i n r e f e r e n c e b on ( a . i d=b . i d ) j o i n d t t a b l e c on ( a . i d = c . i d ) ;

6 7 8 9

SQL 4 : SELECT ∗ FROM i d e n t i f i c a t i o n a j o i n r e f e r e n c e b on ( a . i d=b . i d ) j o i n d t t a b l e c on ( a . i d = c . i d ) j o i n s e q u e n c e l i n e d on ( a . i d = d . i d ) ;

10 11 12 13 14

SQL 5 : SELECT ∗ FROM i d e n t i f i c a t i o n a where a . s e q u e n c e l e n g t h < 2 ;

15 16 17

SQL 6 : SELECT ∗ FROM i d e n t i f i c a t i o n a j o i n de b on ( a . i d=b . i d ) where a . s e q u e n c e l e n g t h < 2 ;

18 19 20 21

SQL 7 : SELECT ∗ FROM i d e n t i f i c a t i o n a j o i n de b on ( a . i d=b . i d ) j o i n o s c on ( a . i d=c . i d ) where a . s e q u e n c e l e n g t h < 2 ;

22 23 24 25 26

SQL 8 : SELECT ∗ FROM i d e n t i f i c a t i o n a j o i n de b on ( a . i d=b . i d ) j o i n o s c on ( a . i d=c . i d ) j o i n a c c e s s i o n n u m b e r s d on ( a . i d=d . i d ) where a . s e q u e n c e l e n g t h < 2 ;

27 28 29 30 31

5.4.1

Anfrage ganzer Relationen

Bei den Anfragen SQL 1 bis SQL 4 wurden die in Tabelle 5.3 und Abbildung 5.3 dargestellten Zeiten gemessen. Die Werte f¨ ur die Messungen ohne Versionierung sind erwartungsgem¨ aß kleiner als die f¨ ur die Messungen mit den beiden Versionierungssystemen. Es ist auch hier zu sehen, dass die entwickelte Versionierung in etwa gleich schnell wie der Oracle Workspace Manager ist.

SQL SQL SQL SQL

1 2 3 4

ohne Versionierung

mit Versionierung

2957 10227 51656 141770

7617 48156 90070 197426

ms ms ms ms

ms ms ms ms

mit Workspace Manager 6041 ms 50996 ms 83467 ms 192471 ms

Tabelle 5.3: Dauer der Anfragen SQL 1 bis SQL 4

37

200000

SQL 1 bis 4 (1) SELECT * FROM identification; (2) SELECT * FROM identification a join reference b on (a.id=b.id); (3) SELECT * FROM identification a join reference b on (a.id=b.id) join dt_table c on (a.id = c.id); (4) SELECT * FROM identification a join reference b on (a.id=b.id) join dt_table c on (a.id = c.id) join sequence_line d on (a.id = d.id);

180000

160000

Dauer der Abfrage [ms]

140000

120000

100000

80000

60000

40000 ohne Versionierung 20000

mit Versionierung mit Workspace Manager

0 1

2

3

4

SQL-Statement

Abbildung 5.3: Dauer der Anfragen SQL 1 bis SQL 4

5.4.2

Anfrage von Bereichen aus Relationen

Um die Zugriffsgeschwindigkeiten in Abh¨angigkeit von der Selektivit¨at einer Anfrage messen zu k¨onnen, wurde zuerst bestimmt, mit welchen Sequenzl¨angen man die Relationen am besten partitionieren“ kann. In den folgenden Tabellen und Diagrammen kann man die Dauer der ” durchgef¨ uhrten Anfragen ersehen. Auch hier ist wiederum zu erkennen, dass das Einf¨ ugen ohne Versionierung am schnellsten gearbeitet hat. Die Werte f¨ ur die Versionierierung und den Oracle Workspace Manager sind weitestgehend ¨ ahnlich.

38

L¨ ange sequence line

Anzahl Treffer

Selektivit¨at

2 98 146 195 244 300 354 420 506 691 10000

0 15433 30893 46189 61616 76980 92182 107611 123119 138497 153871

0,00% 10,03% 20,08% 30,02% 40,04% 50,03% 59,91% 69,94% 80,01% 90,01% 100,00%

ohne Versionierung 16 391 590 969 1156 1516 1719 2016 2398 2563 2840

mit Versionierung

ms ms ms ms ms ms ms ms ms ms ms

3637 4024 4266 4691 5028 5543 5898 6391 6680 7055 7516

ms ms ms ms ms ms ms ms ms ms ms

mit Workspace Manager 3360 ms 3527 ms 4120 ms 4514 ms 5198 ms 5624 ms 5849 ms 6190 ms 6803 ms 7132 ms 7371 ms

Tabelle 5.4: Dauer der Anfrage SQL 5

8000

SQL 5 (SELECT * FROM identification a where a.sequence_length < x)

7000

Dauer der Abfrage [ms]

6000

5000

4000

ohne Versionierung mit Versionierung mit Workspace Manager

3000

2000

1000

0 0,00%

10,00%

20,00%

30,00%

40,00%

50,00%

60,00%

70,00%

Selektivität (rel44)

Abbildung 5.4: Dauer der Anfrage SQL 5

39

80,00%

90,00%

100,00%

L¨ange sequence line

Anzahl Treffer

Selektivit¨at

2 98 146 195 244 300 354 420 506 691 10000

0 15433 30893 46189 61616 76980 92182 107611 123119 138497 153871

0,00% 10,03% 20,08% 30,02% 40,04% 50,03% 59,91% 69,94% 80,01% 90,01% 100,00%

ohne Versionierung 188 668 1445 1422 1789 2379 2547 2934 3281 3766 4129

mit Versionierung

ms ms ms ms ms ms ms ms ms ms ms

3594 7684 8031 8547 8977 9977 10106 10586 10969 11414 11813

ms ms ms ms ms ms ms ms ms ms ms

mit Workspace Manager 3324 ms 6337 ms 7822 ms 8193 ms 9076 ms 9566 ms 10067 ms 10653 ms 12540 ms 15438 ms 17004 ms

Tabelle 5.5: Dauer der Anfrage SQL 6

18000

SQL 6 (SELECT * FROM identification a join DE b on (a.id=b.id) where a.sequence_length < x)

16000

14000

Dauer der Abfrage [ms]

12000

10000 ohne Versionierung mit Versionierung

8000

mit Workspace Manager 6000

4000

2000

0 0,00%

10,00%

20,00%

30,00%

40,00%

50,00%

60,00%

70,00%

Selektivität (rel44)

Abbildung 5.5: Dauer der Anfrage SQL 6

40

80,00%

90,00%

100,00%

L¨ ange sequence line

Anzahl Treffer

Selektivit¨at

2 98 146 195 244 300 354 420 506 691 10000

0 15433 30893 46189 61616 76980 92182 107611 123119 138497 153871

0,00% 10,03% 20,08% 30,02% 40,04% 50,03% 59,91% 69,94% 80,01% 90,01% 100,00%

ohne Versionierung 231 902 1285 2961 2938 3965 4559 6024 6180 6586 6945

mit Versionierung

ms ms ms ms ms ms ms ms ms ms ms

10297 15442 15606 15770 16762 16906 18176 18664 18848 19121 19652

ms ms ms ms ms ms ms ms ms ms ms

mit Workspace Manager 10005 ms 13510 ms 16256 ms 16495 ms 16837 ms 17076 ms 17755 ms 18804 ms 19251 ms 19429 ms 21465 ms

Tabelle 5.6: Dauer der Anfrage SQL 7

25000

SQL 7 (SELECT * FROM identification a join DE b on (a.id=b.id) join os c on (a.id=c.id) where a.sequence_length < x)

Dauer der Abfrage [ms]

20000

15000

ohne Versionierung mit Versionierung mit Workspace Manager

10000

5000

0 0,00%

10,00%

20,00%

30,00%

40,00%

50,00%

60,00%

70,00%

Selektivität (rel44)

Abbildung 5.6: Dauer der Anfrage SQL 7

41

80,00%

90,00%

100,00%

L¨ange sequence line

Anzahl Treffer

Selektivit¨at

2 98 146 195 244 300 354 420 506 691 10000

0 15433 30893 46189 61616 76980 92182 107611 123119 138497 153871

0,00% 10,03% 20,08% 30,02% 40,04% 50,03% 59,91% 69,94% 80,01% 90,01% 100,00%

ohne Versionierung 160 2418 2879 4758 5274 5840 6438 6824 7426 8483 8816

mit Versionierung

ms ms ms ms ms ms ms ms ms ms ms

15250 19965 20059 20902 21563 22070 22715 24395 24520 25160 26254

ms ms ms ms ms ms ms ms ms ms ms

mit Workspace Manager 14428 ms 16654 ms 18428 ms 20014 ms 22136 ms 22185 ms 22909 ms 23277 ms 24332 ms 26050 ms 26671 ms

Tabelle 5.7: Dauer der Anfrage SQL 8

30000

SQL 8 (SELECT * FROM identification a join de b on (a.id=b.id) join os c on (a.id=c.id) join accession_numbers d on (a.id=d.id ) where a.sequence_length < x)

25000

Dauer der Abfrage [ms]

20000

15000

ohne Versionierung mit Versionierung mit Workspace Manager

10000

5000

0 0,00%

10,00%

20,00%

30,00%

40,00%

50,00%

60,00%

70,00%

Selektivität (rel44)

Abbildung 5.7: Dauer der Anfrage SQL 8

42

80,00%

90,00%

100,00%

Um die Auswirkungen der Versionierung auf die Performance bewerten zu k¨onnen, wurde die ¨ Abfrage SQL8 auch jeweils an den durch Andern von 10000 Entries (Release 44-1) und zus¨atzliches L¨oschen von 5000 Entries (Release 44-2) entstandenen Releases ausgef¨ uhrt. Die dabei gemessenen Werte sind in den Tabellen 5.8 und 5.9, sowie im Diagramm in der Abbildung 5.8 zu sehen. L¨ ange sequence line

Anzahl Treffer

Selektivit¨at

2 98 146 195 244 300 354 420 506 691 10000

0 15433 30893 46189 61616 76980 92182 107611 123119 138497 153871

0,00% 10,03% 20,08% 30,02% 40,04% 50,03% 59,91% 69,94% 80,01% 90,01% 100,00%

mit Versionierung 17865 20037 22602 23604 24360 25060 25977 27306 28326 29054 30317

ms ms ms ms ms ms ms ms ms ms ms

mit Workspace Manager 19639 ms 21588 ms 23724 ms 24934 ms 25708 ms 26338 ms 27606 ms 28841 ms 30095 ms 31254 ms 32004 ms

Tabelle 5.8: Dauer der Anfrage SQL 8 (Release 44-1)

L¨ ange sequence line

Anzahl Treffer

Selektivit¨at

2 98 146 195 244 300 354 420 506 691 10000

0 14933 29893 44689 59616 74480 89182 104111 119119 133997 148871

0,00% 10,03% 20,08% 30,02% 40,05% 50,03% 59,90% 69,93% 80,02% 90,01% 100,00%

mit Versionierung 19548 21845 24843 25751 26985 27845 28877 30211 31124 31897 33245

ms ms ms ms ms ms ms ms ms ms ms

mit Workspace Manager 21125 ms 23315 ms 25545 ms 26842 ms 27754 ms 28422 ms 29700 ms 31124 ms 32333 ms 33749 ms 34613 ms

Tabelle 5.9: Dauer der Anfrage SQL 8 (Release 44-2)

43

40000

SQL 8 an den Releases 44, 44-1 und 44-2

35000

Dauer der Abfrage [ms]

30000

25000

20000

15000

Release 44 (mit Versionierung) Release 44-1 (mit Versionerung) Release 44-2 (mit Versionierung)

10000

Release 44 (WSM) Release 44-1 (WSM) Release 44-2 (WSM)

5000

0 0,00%

10,00%

20,00%

30,00%

40,00%

50,00%

60,00%

70,00%

80,00%

90,00%

100,00%

Selektivität

Abbildung 5.8: Dauer der Anfrage SQL 8 (Release 44-1)

¨ Hier ist zu sehen, dass sowohl das Andern von Daten, wie auch das L¨oschen, den Zugriff auf die versionierten Releases etwas verlangsamt. Dies ist sowohl in der neu entwickelten Versionierunsstrategie, wie auch im Oracle Workspace-Manager zu erkennen.

44

5.5

Optimierungen

Zwar wurden mit der neu entwickelten Versionierunsstrategie ¨ahnliche Zugriffszeiten wie beim Oracle Workspace-Manager erreicht, doch war es auch Ziel dieser Studienarbeit, diese Zeiten zu unterbieten. Daher wurden noch einige Optimierungsvarianten getestet.

5.5.1

Alternative Ermittlung der Vorg¨ angerversionen 1

Bisher wurden die Vorg¨ angerversionen mit folgenden Vergleichen ermittelt: versions pre = actual post Die Vorg¨ angerversionen k¨ onnen allerdings auch durch versions pre 0) then l a s t v e r s i o n d i f f := p a r e n t p o s t − n e i g h b o u r p o s t ; n e w v e r s i o n p r e := trunc ( neighbour post + ( l a s t v e r s i o n d i f f / 3 ) ) ; n e w v e r s i o n p o s t := trunc ( neighbour post + (2 ∗ l a s t v e r s i o n d i f f / 3 ) ) ; else l a s t v e r s i o n d i f f := p a r e n t p o s t − p a r e n t p r e ; n e w v e r s i o n p r e := trunc ( parent pre + ( l a s t v e r s i o n d i f f / 3 ) ) ; n e w v e r s i o n p o s t := trunc ( parent pre + (2 ∗ l a s t v e r s i o n d i f f / 3 ) ) ; end i f ;

49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67

i f ( n e w v e r s i o n p r e = n e w v e r s i o n p o s t ) then make tree bigger (10); make child ( version parent ) ; else INSERT INTO v e r s i o n s ( versions id , versions pre , versions post ) VALUES ( new version , new version pre , new version post ) ; dbms output . p u t l i n e ( ’ Neue V e r s i o n mit ID ’ | | v e r s i o n s i d | | ’ erstellt . ’); end i f ; commit ; END m a k e c h i l d ;

68 69 70 71 72 73 74 75 76 77

p r o c e d u r e m a k e t r e e b i g g e r ( m u l t i p l i e r INTEGER) AS BEGIN UPDATE v e r s i o n s SET v e r s i o n s p r e = v e r s i o n s p r e ∗ m u l t i p l i e r , versions post = versions post ∗ multiplier ; commit ; dbms output . p u t l i n e ( ’ Der Versionenbaum wurde um de Faktor ’ | | multiplier | | ’ erweitert . ’ ) ; END m a k e t r e e b i g g e r ;

78 79 80

p r o c e d u r e s e t v e r s i o n ( v e r s i o n n r INTEGER) AS BEGIN

49

81 82 83 84 85 86 87 88

a c t u a l v e r s i o n := v e r s i o n n r ; SELECT v e r s i o n s p r e INTO a c t u a l p r e FROM v e r s i o n s WHERE v e r s i o n s i d=a c t u a l v e r s i o n ; SELECT v e r s i o n s p o s t INTO a c t u a l p o s t FROM v e r s i o n s WHERE v e r s i o n s i d=a c t u a l v e r s i o n ; dbms output . p u t l i n e ( ’ E r f o l g r e i c h in Version ’ | | versionnr | | ’ gewechselt . ’ ) ; END s e t v e r s i o n ;

89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129

f u n c t i o n d a t a a l t RETURN d a t a t a b e l l e n t y p PIPELINED AS CURSOR p r i o r v e r s i o n s IS SELECT ∗ FROM data d a t a 1 WHERE ( d a t a v e r s i o n IN ( SELECT v e r s i o n s i d FROM v e r s i o n s WHERE v e r s i o n s p r e = a c t u a l p o s t ) ) AND (NOT EXISTS ( SELECT d a t a i d FROM data d a t a 2 WHERE ( ( d a t a 2 . d a t a a c t i o n =2) AND ( d a t a 2 . d a t a v e r s i o n IN ( SELECT v e r s i o n s i d FROM v e r s i o n s WHERE v e r s i o n s p r e = a c t u a l p o s t ) ) AND ( d a t a 2 . d a t a i d=d a t a 1 . d a t a i d ) ) )) UNION SELECT ∗ FROM data d a t a 1 WHERE ( ( d a t a a c t i o n =1) AND ( d a t a v e r s i o n IN ( SELECT v e r s i o n s i d FROM v e r s i o n s WHERE v e r s i o n s p r e = a c t u a l p o s t )) AND ( EXISTS ( SELECT d a t a i d FROM data d a t a 2 WHERE ( ( d a t a 2 . d a t a a c t i o n =2) AND ( d a t a 2 . d a t a v e r s i o n IN ( SELECT v e r s i o n s i d FROM v e r s i o n s WHERE v e r s i o n s p r e = a c t u a l p o s t ) ) AND ( d a t a 2 . d a t a i d=d a t a 1 . d a t a i d ) )) ) AND NOT EXISTS ( SELECT d a t a i d FROM data d a t a 3 WHERE ( ( d a t a 3 . d a t a 2 a c t i o n =2) AND ( d a t a 3 . d a t a 2 v e r s i o n IN (

50

130 131 132 133 134 135

SELECT v e r s i o n s i d FROM v e r s i o n s WHERE v e r s i o n s p r e = a c t u a l p o s t ) ) AND ( d a t a 3 . d a t a i d=d a t a 1 . d a t a i d ) AND ( d a t a 3 . d a t a c o u n t e r > d a t a 1 . d a t a 2 c o u n t e r ))));

136 137

p r i o r v e r s i o n s d a t a data%ROWTYPE;

138 139 140 141 142

BEGIN OPEN p r i o r v e r s i o n s ; LOOP FETCH p r i o r v e r s i o n s INTO p r i o r v e r s i o n s d a t a ;

143 144 145 146 147

IF ( p r i o r v e r s i o n s%FOUND) THEN PIPE ROW ( d a t a s p a l t e n t y p ( p r i o r v e r s i o n s d a t a . d a t a i d , prior versions data . data attr ) ) ; END IF ;

148 149 150 151 152 153

EXIT WHEN ( not p r i o r v e r s i o n s%FOUND) ; END LOOP; CLOSE p r i o r v e r s i o n s ; RETURN; END d a t a a l t ;

154 155 156 157 158 159 160

f u n c t i o n next seqnumber r e t u r n INTEGER AS next number INTEGER; BEGIN SELECT v nummer seq . n e x t v a l INTO next number FROM d u a l ; r e t u r n next number ; END next seqnumber ;

161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178

f u n c t i o n h a s c h i l d r e t u r n INTEGER AS CURSOR c h i l d r e n IS SELECT v e r s i o n s i d FROM v e r s i o n s WHERE v e r s i o n s p r e > a c t u a l p r e AND v e r s i o n s p o s t < a c t u a l p o s t ; o n e c h i l d INTEGER; c h i l d e x i s t s INTEGER; BEGIN c h i l d e x i s t s := 0 ; OPEN c h i l d r e n ; LOOP FETCH c h i l d r e n INTO o n e c h i l d ; IF ( c h i l d r e n%FOUND) THEN c h i l d e x i s t s := 1 ; END IF ; EXIT WHEN ( not c h i l d r e n%FOUND) ; END LOOP; CLOSE c h i l d r e n ;

51

179 180

return c h i l d e x i s t s ; END h a s c h i l d ;

181 182 183 184 185 186 187 188

f u n c t i o n s h o w l a s t v e r s i o n r e t u r n INTEGER AS l a s t v e r s i o n INTEGER; BEGIN SELECT MAX( v e r s i o n s i d ) INTO l a s t v e r s i o n FROM v e r s i o n s ; dbms output . p u t l i n e ( ’ L e t z t e V e r s i o n s −ID : ’ | | l a s t v e r s i o n ) ; return l a s t v e r s i o n ; END s h o w l a s t v e r s i o n ;

189 190 191 192

BEGIN set version (0); END h v e r s i o n s ;

52

Anhang B

Algorithmus der Messung F¨ ur die Messung wurde folgendes Skript benutzt: Listing B.1: Algorithmus der Messung 1 2 3 4 5 6

SET SERVEROUTPUT ON; DECLARE t s 1 TIMESTAMP; t s 2 TIMESTAMP; CURSOR r e t v a l c u r s i s SELECT ∗ FROM IDENTIFICATION ; r e t v a l r e t v a l c u r s%ROWTYPE;

7 8 9 10 11 12 13 14 15 16 17 18 19 20

BEGIN −−e r s t m a l ohne B u f f e r SELECT SYSTIMESTAMP INTO t s 1 FROM DUAL; OPEN r e t v a l c u r s ; LOOP FETCH r e t v a l c u r s INTO r e t v a l ; EXIT WHEN ( not r e t v a l c u r s%FOUND) ; END LOOP; CLOSE r e t v a l c u r s ; SELECT SYSTIMESTAMP INTO t s 2 FROM DUAL; DBMS OUTPUT. PUT LINE( ’ Z e i t ( ohne B u f f e r ) : ’ ) ; DBMS OUTPUT. PUT LINE(TO CHAR( ( t s 2 −t s 1 ) , ’YYYY−MM−DD HH: MI : SSXFF ’ ) ) ;

21 22 23 24 25 26 27 28 29 30 31 32

−−mit B u f f e r SELECT SYSTIMESTAMP INTO t s 1 FROM DUAL; OPEN r e t v a l c u r s ; LOOP FETCH r e t v a l c u r s INTO r e t v a l ; EXIT WHEN ( not r e t v a l c u r s%FOUND) ; END LOOP; CLOSE r e t v a l c u r s ; SELECT SYSTIMESTAMP INTO t s 2 FROM DUAL; DBMS OUTPUT. PUT LINE( ’ Z e i t ( mit B u f f e r ) : ’ ) ; DBMS OUTPUT. PUT LINE(TO CHAR( ( t s 2 −t s 1 ) , 53

33

’YYYY−MM−DD HH: MI : SSXFF ’ ) ) ;

34 35 36 37 38 39 40 41 42 43 44 45

SELECT SYSTIMESTAMP INTO t s 1 FROM DUAL; OPEN r e t v a l c u r s ; LOOP FETCH r e t v a l c u r s INTO r e t v a l ; EXIT WHEN ( not r e t v a l c u r s%FOUND) ; END LOOP; CLOSE r e t v a l c u r s ; SELECT SYSTIMESTAMP INTO t s 2 FROM DUAL; DBMS OUTPUT. PUT LINE( ’ Z e i t ( mit B u f f e r ) : ’ ) ; DBMS OUTPUT. PUT LINE(TO CHAR( ( t s 2 −t s 1 ) , ’YYYY−MM−DD HH: MI : SSXFF ’ ) ) ;

46 47 48 49 50 51 52 53 54 55 56 57 58

SELECT SYSTIMESTAMP INTO t s 1 FROM DUAL; OPEN r e t v a l c u r s ; LOOP FETCH r e t v a l c u r s INTO r e t v a l ; EXIT WHEN ( not r e t v a l c u r s%FOUND) ; END LOOP; CLOSE r e t v a l c u r s ; SELECT SYSTIMESTAMP INTO t s 2 FROM DUAL; DBMS OUTPUT. PUT LINE( ’ Z e i t ( mit B u f f e r ) : ’ ) ; DBMS OUTPUT. PUT LINE(TO CHAR( ( t s 2 −t s 1 ) , ’YYYY−MM−DD HH: MI : SSXFF ’ ) ) ; END; Die entsprechenden SQL-Abfragen SQL 1 bis SQL 8 wurden jeweils in Zeile 5 eingef¨ ugt.

54

Anhang C

Struktur von SwissProt Listing C.1: Struktur von SwissProt 1 2 3 4 5 6 7

CREATE TABLE IDENTIFICATION( ID CHAR( 1 0 ) PRIMARY KEY, ENTRY NAME CHAR( 1 0 ) , DATA CLASS CHAR( 1 1 ) , MOLECULE TYPE CHAR( 3 ) , SEQUENCE LENGTH INTEGER );

8 9 10 11 12 13 14 15 16

CREATE TABLE DT TABLE( ID CHAR( 1 0 ) REFERENCES IDENTIFICATION ON DELETE CASCADE, N INTEGER, DT DATE, COM CHAR( 4 0 ) , PRIMARY KEY( ID ,N) );

17 18 19 20 21 22 23 24

CREATE TABLE ACCESSION NUMBERS( ID CHAR( 1 0 ) REFERENCES IDENTIFICATION ON DELETE CASCADE, N INTEGER, ACCESSION NUMBER CHAR( 1 0 ) , PRIMARY KEY( ID ,N) );

25 26 27 28 29 30 31

CREATE TABLE DE( ID CHAR( 1 0 ) REFERENCES IDENTIFICATION ON DELETE CASCADE, DESCRIPTION VARCHAR2( 2 0 0 0 CHAR) , PRIMARY KEY( ID ) );

32 33 34

CREATE TABLE OS( 55

ID CHAR( 1 0 ) REFERENCES IDENTIFICATION ON DELETE CASCADE, N INTEGER, ORGANISM SPECIES CHAR( 1 0 0 ) , PRIMARY KEY( ID ,N)

35 36 37 38 39 40

);

41 42 43 44 45 46 47 48

CREATE TABLE OG( ID CHAR( 1 0 ) REFERENCES IDENTIFICATION ON DELETE CASCADE, N INTEGER, ORGANELLE CHAR( 1 0 0 ) , PRIMARY KEY( ID ,N) );

49 50 51 52 53 54 55

CREATE TABLE OC( ID CHAR( 1 0 ) REFERENCES IDENTIFICATION ON DELETE CASCADE, ORGANISM CLASSIFICATION VARCHAR2( 1 0 0 0 ) , PRIMARY KEY( ID ) );

56 57 58 59 60 61 62 63 64 65 66

CREATE TABLE REFERENCE( ID CHAR( 1 0 ) REFERENCES IDENTIFICATION ON DELETE CASCADE, RN INTEGER, RP CHAR( 1 0 0 ) , RX CHAR( 1 0 0 ) , RA VARCHAR2( 4 0 0 0 CHAR) , RL VARCHAR2( 2 0 0 0 CHAR) , PRIMARY KEY( ID ,RN) );

67 68 69 70 71 72 73 74 75

CREATE TABLE REFERENCE COMMENT( ID CHAR( 1 0 ) , RN INTEGER, TEXT VARCHAR( 1 0 0 0 ) , PRIMARY KEY( ID ,RN) , FOREIGN KEY( ID ,RN) REFERENCES REFERENCE ON DELETE CASCADE );

76 77 78 79 80 81 82 83

CREATE TABLE SEQUENCE LINE( ID CHAR( 1 0 ) REFERENCES IDENTIFICATION ON DELETE CASCADE, MOLECULAR WEIGHT INTEGER, CONTROLL NUMBER CHAR( 3 0 ) , SEQUENCE DATA CLOB, PRIMARY KEY( ID )

56

84

);

85 86 87 88 89 90 91

CREATE TABLE COMMENTS( ID CHAR( 1 0 ) REFERENCES IDENTIFICATION ON DELETE CASCADE, TEXT CLOB, PRIMARY KEY( ID ) );

57

Literaturverzeichnis [1] Rieche, St.: Diplomarbeit Versionierung in relationalen Datenbanken“, 2004 ” [2] T¨ urscher, G.: PL/SQL – Lernen, Verstehen und Einsetzen, Springer 1997 [3] Raymans, H.–G.: ORACLE Programmierung, Addison–Wesley 2001 [4] Feuerstein, St., Pribyl, B.: Oracle PL/SQL, O´Reilly 1999 [5] Abrahamson, I., Abbey, M., Corey, M.: Oracle Database 10g f¨ ur Einsteiger, Oracle Press 2004 [6] Loney, K., Koch, G.: Oracle 9i Die umfassende Referenz, Oracle Press 2003 [7] Zhu, N.: Data Versioning Systems, Stony Brook, 2003 [8] Klahold, P., Schlageter, G., Wilkes, W.: A General Model for Version Management in Databases, Proceedings of 12th International Conference on Very Large Databases, 1986 [9] Bebel, B., Eder, J., Koncilia, Ch., Morzy, T., Wrembel, R.: Creation and Management of Versions in Multiversion Data Warehouse, ACM Symposium on Applied Computing, 2004 [10] Swiss Institute of Bioinformatics - University of Geneva, EMBL Outstation, EBI: SwissProt, Protein knowledgebase., URL: http://www.expasy.org/sprot/

59

Abbildungsverzeichnis 2.1

Lineare Versionierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

2.2

Hierarchische Versionierung . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

3.1

Pre–Post–Order–Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

4.1

Versionenbaum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

5.1

Geschwindigkeit des Einf¨ ugens des Release 37 . . . . . . . . . . . . . . . . . .

35

5.2

Geschwindigkeit des Einf¨ ugens des Release 44 . . . . . . . . . . . . . . . . . .

36

5.3

Dauer der Anfragen SQL 1 bis SQL 4 . . . . . . . . . . . . . . . . . . . . . .

38

5.4

Dauer der Anfrage SQL 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

5.5

Dauer der Anfrage SQL 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40

5.6

Dauer der Anfrage SQL 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

5.7

Dauer der Anfrage SQL 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

5.8

Dauer der Anfrage SQL 8 (Release 44-1) . . . . . . . . . . . . . . . . . . . . .

44

5.9

Dauer der Anfrage SQL 8 (Release 44-2) . . . . . . . . . . . . . . . . . . . . .

46

61

Tabellenverzeichnis 2.1

Tabelle A vor der Versionierung . . . . . . . . . . . . . . . . . . . . . . . . . .

13

2.2

Tabelle A nach dem Einf¨ ugen der Versionierungsattribute . . . . . . . . . . .

13

2.3

Tabelle A vor der Versionierung . . . . . . . . . . . . . . . . . . . . . . . . . .

14

2.4

Teil-Tabelle A 1 nach der Zerlegung . . . . . . . . . . . . . . . . . . . . . . .

15

2.5

Teil-Tabelle A 2 nach der Zerlegung . . . . . . . . . . . . . . . . . . . . . . .

15

3.1

Tabelle versions

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

3.2

Tabelle data (alt) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

3.3

Tabelle data (neu) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

3.4

Initialwerte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

4.1

Struktur der Tabelle data . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

4.2

Inhalt der Tabelle data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

4.3

Struktur der Tabelle hv data

. . . . . . . . . . . . . . . . . . . . . . . . . . .

26

4.4

Struktur der Tabelle versions . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

4.5

Inhalt der Tabelle hv data . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

4.6

Inhalt der Tabelle versions

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

4.7

neue Tupel f¨ ur der Tabelle data . . . . . . . . . . . . . . . . . . . . . . . . . .

27

4.8

Inhalt der Tabelle hv data . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

4.9

Inhalt der Tabelle versions

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

4.10 Anlegen der Versionen 1 bis 3 unter der Version 0 . . . . . . . . . . . . . . . .

28

4.11 Erl¨ auterung der Spaltennamen von Tabelle 4.10 . . . . . . . . . . . . . . . . .

29

4.12 neue Tupel f¨ ur der Tabelle data . . . . . . . . . . . . . . . . . . . . . . . . . .

29

4.13 Inhalt der Tabelle hv data . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

4.14 Inhalt der Tabelle versions

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

4.15 Inhalt der Tabelle data – Version 0 . . . . . . . . . . . . . . . . . . . . . . . .

30

4.16 Inhalt der Tabelle data – Version 1 . . . . . . . . . . . . . . . . . . . . . . . .

30

4.17 Inhalt der Tabelle data – Version 2 . . . . . . . . . . . . . . . . . . . . . . . .

31

63

4.18 Inhalt der Tabelle data – Version 3 . . . . . . . . . . . . . . . . . . . . . . . .

31

4.19 Inhalt der Tabelle data – Version 4 . . . . . . . . . . . . . . . . . . . . . . . .

31

4.20 Inhalt der Tabelle data – Version 5 . . . . . . . . . . . . . . . . . . . . . . . .

31

5.1

Entries pro Sekunde beim Einf¨ ugen . . . . . . . . . . . . . . . . . . . . . . . .

34

5.2

Dauer des Einf¨ ugens Einf¨ ugen in hh:mm:ss . . . . . . . . . . . . . . . . . . .

34

5.3

Dauer der Anfragen SQL 1 bis SQL 4 . . . . . . . . . . . . . . . . . . . . . .

37

5.4

Dauer der Anfrage SQL 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

5.5

Dauer der Anfrage SQL 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40

5.6

Dauer der Anfrage SQL 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

5.7

Dauer der Anfrage SQL 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

5.8

Dauer der Anfrage SQL 8 (Release 44-1) . . . . . . . . . . . . . . . . . . . . .

43

5.9

Dauer der Anfrage SQL 8 (Release 44-2) . . . . . . . . . . . . . . . . . . . . .

43

5.10 Tabelle versionsrel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

5.11 Dauer der Anfrage SQL 8 (Release 44-2) . . . . . . . . . . . . . . . . . . . . .

46

64

65