RHEINISCHE FRIEDRICH-WILHELMS- UNIVERSITÄT BONN

RHEINISCHE FRIEDRICH-WILHELMSUNIVERSITÄT BONN
INSTITUT FÜR INFORMATIK III
Diplomarbeit
Ein datenbankgestütztes Werkzeug
zur Exploration von ontologischen Daten
und deren Evolution
Tim Sondermann
13. März 2006
Betreuer: Prof. Dr. Manthey
Inhaltsverzeichnis
1. Einleitung ..............................................................................................................5
2. Datenbanken..........................................................................................................7
2.1. Relationale Datenbanken ...............................................................................7
2.2. Microsoft Access............................................................................................9
2.3. Visual Basic for Applications (VBA) ..........................................................10
2.4. SQL ..............................................................................................................11
2.4.1 Data Definition Language (DDL) ..........................................................12
2.4.2 Data Manipulation Language (DML) ....................................................14
2.5. Versionsmanagement ...................................................................................19
2.5.1 Übersicht ................................................................................................19
2.5.2 Differenzspeicherung .............................................................................19
2.5.3 Versionen und Updates in Datenbanken................................................21
3. Ontologien...........................................................................................................23
3.1. Begriffsdefinition .........................................................................................23
3.2. Beispiele für Ontologien ..............................................................................25
3.2.1 Foundational Model of Anatomy (FMA)...............................................26
3.2.2 General Ontology for Linguistic Description (GOLD) .........................26
3.2.3 Semantic Web ........................................................................................26
3.3. Repräsentation von Ontologien in Datenbanken .........................................27
3.3.1 Modellierung von Vererbung.................................................................27
3.3.2 Modellierung von Axiomen ...................................................................29
3.4. Die Gene Ontology ......................................................................................30
4. Konzept eines Versionsmanagement am Beispiel der Gene Ontology ..............32
4.1. Untersuchung des Änderungsverhaltens der Gene Ontology ......................33
4.2. Probleme bei fehlendem Versionsmanagement...........................................36
4.2.1 Ineffizienter Datenaustausch..................................................................36
4.2.2 Mangelnde Informationen über Änderungen.........................................37
4.2.3 Mangelnder Zugriff auf alte Versionen .................................................39
4.3. Konzept eines effizienten Versionsmanagements........................................39
4.3.1 Historisierung.........................................................................................40
4.3.1.1 Gewinnung der Deltadaten..............................................................40
4.3.1.2 Speicherung der Deltadaten ............................................................44
4.3.2 Rekonstruktion .......................................................................................49
4
4.3.3 Analyse der Deltadaten ..........................................................................51
4.4. Das „Schlüsselproblem“...............................................................................51
5. Das System VerIS ...............................................................................................54
5.1. Architektur und Funktionalität.....................................................................55
5.2. Importmanager .............................................................................................58
5.3. Keymanager .................................................................................................58
5.4. Historymanager ............................................................................................59
5.5. Versionmanager ...........................................................................................60
5.6. Querymanager ..............................................................................................62
5.7. Bewertung des Systems................................................................................63
6. Ausgewählte Probleme der Implementierung.....................................................64
6.1. Import des Tabellenschemas ........................................................................64
6.2. Differenzspeicherung ohne Schlüssel ..........................................................65
6.3. Das „UPDATE-Problem“ bei der Rekonstruktion.......................................67
7. Zusammenfassung und Ausblick ........................................................................70
8. Literatur...............................................................................................................72
5
1. Einleitung
Die von Biologen entwickelte Gene Ontology ([GEN07]) ist ein gutes Beispiel
für eine schnell gewachsene und schnell wachsende Ontologie. Sie stellt ein zentrales „Wörterbuch“ für das Indizieren und das Annotieren von Genen und Genprodukten (z.B. Proteinen) unterschiedlichster Arten und Gattungen dar. Diese
Informationen werden durch eine Datenbank repräsentiert. Die Daten der Gene
Ontology sind in verschiedenen Formaten und Release-Kategorien jederzeit im
Internet abrufbar. Da sich diese Daten unter Umständen rasch ändern können
und der Benutzer der Gene Ontology möglichst mit sehr aktuellem Datenmaterial arbeiten möchte, wird täglich eine neue Version der kompletten Datenbasis bereitgestellt und kann in das vom Anwender genutzte Datenbanksystem integriert werden.
Dem Benutzer, der diese Daten anfordert, fehlen jedoch jegliche Informationen,
ob und in welchem Umfang sich die Daten geändert haben. Meist ist ein Austausch der Daten komplett unnötig, da sich gar kein Datensatz geändert hat. Es
ist jedoch auch möglich, dass sich zwischen Versionen zweier Tage relativ viele
Daten ändern und eine neue Version der Daten für den Benutzer unabdingbar ist.
Da Informationen über Änderungen der Daten jedoch nicht zugänglich sind,
muss häufig ein sinnloser Austausch der Daten, die sich bereits auf dem Datenbanksystem des Anwenders befinden, mit den von der Gene Ontologie bereitgestellten Daten im Internet vollzogen werden. Die Gene Ontology bietet nämlich
keine Möglichkeit, nur die geänderten Daten zu erneuern, sondern bietet nur eine
Bereitstellung der gesamten Datenbasis.
Da ontologische Daten häufigen Änderungen unterzogen sind und diese Änderungen für alle Anwender von großem Interesse sind, versucht diese Arbeit am
Beispiel der Gene Ontology Konzepte und Lösungen für OntologieDatenbanken zu entwickeln, bei denen ein Versionsmanagement, also ein effizienter Umgang mit Änderungen der Datenbasis, fehlt. Die erarbeiteten
6
Konzepte und deren technischen Umsetzung lassen sich aber auch
durchaus auf andere große Informationssysteme übertragen, so dass sie nicht
allein auf die Datenbank der Gene Ontology anwendbar sind.
Es wird ein System basierend auf einem relationalen Datenbanksystem entwickelt, welches die Konzepte und Methoden eines Versionsmanagements für Datenbanken verwirklicht. Mit Hilfe des entwickelten Systems VerIS wird aufgezeigt, wie ein Versionsmanagement für die Gene Ontology aussehen könnte. Das
System arbeitet zwar mit Daten aus der Gene Ontology, die entwickelten Methoden lassen sich aber – durch leichte Modifikationen - auch auf andere Datenbanken anwenden.
Das System VerIS wurde mit MS Access entwickelt. Es bietet die Möglichkeit,
Daten aus der Gene Ontology zu integrieren und den Änderungsverlauf dieser
Daten zu protokollieren, so dass der Benutzer dieses Systems diverse Informationen über den Verlauf der Änderungen erhält. Außerdem bietet das System die
Möglichkeit, alte Versionen des Datenbestands zu generieren, ohne dass diese
alten Versionen physisch im System vorhanden sein müssen.
Die Arbeit hat den folgenden Aufbau: In Kapitel 2 werden zunächst die Grundlagen der in der Arbeit verwendeten Datenbankentechnologien vermittelt. Außerdem wird das Prinzip des Versionsmanagements für Datenbanken beleuchtet.
Kapitel 3 gibt einen Überblick über Ontologien mit besonderem Augenmerk auf
die Gene Ontology. In Kapitel 4 wird ein Konzept eines Versionsmanagements
für Datenbanken am Beispiel der Gene Ontology erarbeitet. Kapitel 5 befasst
sich mit der technischen Umsetzung eines solchen Versionsmanagements. Hier
wird die Implementierung und der Aufbau des Systems VerIS beschrieben. Kapitel 6 erörtert einige interessante Probleme der Implementierung. Eine Zusammenfassung und ein kurzer Ausblick in Kapitel 7 schließen die Diplomarbeit ab.
7
2. Datenbanken
In diesem Kapitel sollen die notwendigen Grundlagen zum technischen und
konzeptionellen Verständnis der in dieser Arbeit verwendeten Technologien
vermittelt werden.
In dieser Arbeit wird ein System vorgestellt, das ein Versionsmanagement für
Datenbanken und durch Datenbanken repräsentierte Ontologien ermöglicht, bei
denen ein solches fehlt bzw. nicht ausgereift ist. Dieses System wird mit dem
relationalen Datenbankmanagementsystem Microsoft Access entwickelt und
arbeitet mit Beispieldaten aus der Gene Ontology. Dieses Kapitel enthält somit
alle erforderlichen Voraussetzungen, um die Konzeption und Umsetzung eines
solchen Systems zu verstehen.
In Kapitel 2.1 bis 2.4 wird auf die technischen, datenbankbezogenen Grundlagen
eingegangen. Die notwendigen Voraussetzungen für ein Arbeiten mit dem relationalen Datenbanksystem MS Access sowie dessen Werkzeuge SQL und VBA
werden erläutert. In Kapitel 2.5 werden Intention und Konzeption eines Versionsmanagements für Datenbanken und die damit zusammenhängende Differenzspeicherung erklärt.
2.1. Relationale Datenbanken
Für die Verwaltung und Verarbeitung großer Informationsmengen werden Datenbankmanagementsysteme (DBMS) eingesetzt ([KEM97]). Insbesondere relationale Datenbankmanagementsysteme (RDBMS) haben mit ihrer standardisierten Abfragesprache SQL [DAT97] die weiteste Verbreitung gefunden.
Eine relationale Datenbank ist eine Datenbank, die auf dem relationalen Datenmodell basiert. Grundlage des relationalen Datenmodells ist die Relation, ein im
8
mathematischen Sinn wohldefinierter Begriff. Man kann sich Relationen praktisch als Tabellen vorstellen, die aus einzelnen Datensätzen bestehen, die alle
dieselbe (homogene) Feldstruktur aufweisen ([MAN02]).
Das relationale Datenbankmodell ist heute ein etablierter Standard zum Speichern und Verarbeiten von Daten. Ein entsprechendes Datenbankmanagementsystem wird als relationales Datenbankmanagementsystem (RDBMS) bezeichnet. Ein bekanntes und häufig eingesetztes RDBMS ist MS Access. Zum Abfragen und Manipulieren der Daten wird die deklarative Datenbanksprache SQL
genutzt, auf die in Kapitel 2.4 noch näher eingegangen wird.
In einer relationalen Datenbank werden solche Relationen mittels zweidimensionaler Tabellen repräsentiert. Eine relationale Datenbank ist daher eine Kollektion von Tabellen (den Relationen), in welchen die Datensätze abgespeichert werden. Jeder Datensatz ist somit eine Zeile (Tupel) in einer Tabelle. Jedes Tupel
besteht aus einer Menge von Attributwerten, den Spalten der Tabelle. Operationen auf diesen Relationen werden durch die relationale Algebra bestimmt
([KEM97]). Die Umsetzung dieser Operationen (z.B. Abfragen, Einfügeoperationen, Löschoperationen) erfolgt mittels der deklarativen Datenbanksprache
SQL.
Der Vorteil des relationalen Datenmodells liegt vor allem darin, dass Daten, die
an verschiedenen Stellen benötigt werden, nicht mehrmals gespeichert werden
müssen, da die Tabellen über Beziehungen miteinander verbunden werden können. Dadurch kann man Verbindungen von einmal erfassten Daten zu immer
neuen Informationen aufbauen([BB97]).
Zu den Haupteigenschaften von relationalen Datenbanksystemen gehören :
•
•
•
•
•
•
Speichern großer Datenmengen
Datensicherheit
Mehrbenutzerbetrieb durch Transaktionsverwaltung
Sicherstellung von Datenintegrität
Anfrageoptimierung
Indizierung von Daten
9
2.2. Microsoft Access
Microsoft Access (kurz MS Access) ist ein relationales Datenbankmanagementsystem (RDBMS) der Firma Microsoft ([MIC07]). Es dient der Verwaltung und
Verarbeitung von Daten und ermöglicht die direkte Entwicklung von Datenbankanwendungen. MS Access basiert auf dem relationalen Datenmodell und
unterstützt SQL-92.
Es existieren verschiedene, meist durch einen Jahreszusatz gekennzeichnete
Versionen von MS Access (z.B. Access 97, Access 2000). In dieser Arbeit wird
MS Access 2000 verwendet. Da die Versionen von Access jeweils abwärtskompatibel sind, besteht kein Versionsproblem, so dass das in dieser Arbeit entwickelte System auch von neueren Access-Versionen genutzt und weiterentwickelt
werden kann.
MS Access ist ein weitverbreitetes Datenbanksystem, welches alle Eigenschaften eines RDBMS stabil und effizient erfüllt. In dieser Arbeit wird MS Access
als DBMS verwendet, da es im Gegensatz zu den meisten üblichen DBMS zusätzliche Funktionalitäten wie eine leicht zu handhabende graphische Benutzeroberfläche bietet. Außerdem ermöglicht es einen schnellen und unkomplizierten
automatisierten Import von Textdateien, wie sie bei der Gene Ontology als Datenquelle zur Verfügung gestellt werden. Durch die Bereitstellung von visuellen
Programmierobjekten, die speziell im Hinblick auf den Datenbankzugriff optimiert sind, ist es mit Access möglich, innerhalb von kurzer Zeit
datenbankbasierte Anwendungen zu erstellen ([BB02]).
Die Entwicklungsumgebung von MS Access benutzt als Programmiersprache
VBA (Visual Basic for Applications). Mittels VBA werden z.B. die Funktionen
der graphischen Steuerelemente ausgeführt und Abfragen und Änderungen auf
den Daten gestartet. MS Access verwendet die JET-Engine (Joint Engine Technology) als Datenbank-Backend, über die die Daten verwaltet und als Datenbankoperationen abgewickelt werden.
Im Folgenden wird kurz auf die wichtigsten Werkzeuge zur Entwicklung und
Steuerung eingegangen, die MS Access zur Verfügung stehen und in dieser Arbeit verwendet wurden. Die von MS Access verwendete Programmiersprache
VBA sowie die Abfragesprache SQL werden in den nächsten beiden Unterkapiteln ebenfalls vorgestellt.
10
Abfragen: Microsoft hat mit seiner Implementierung und Erweiterung von QBE
(Query-by-Example) auf sogenannte Aktionsabfragen innerhalb der Entwicklungsumgebung von MS ACCESS einen graduellen Fortschritt bei der
Handhabung von Datenbanken durch einen breiten Nutzerkreis erzielt
([SCH05]). Access übersetzt diese graphischen, beispielhaften Abfragen intern
in den korrespondierenden SQL-Code, welcher dann auf den Daten ausgeführt
wird. Der Benutzer hat jedoch auch die Möglichkeit, seine Abfragen in herkömmlicher SQL-Form abzusetzen, mit welcher sich kompliziertere Abfragen
ausdrücken lassen. Falls sich die SQL-Statements in QBE ausdrücken lassen, ist
eine Ansicht des graphischen QBEs möglich. Darüber hinaus lassen sich in
VBA geschriebene Funktionen in die Abfragen integrieren. Durch diesen Umstand erweitert sich die Mächtigkeit von Datenbank-Anfragen.
Formulare: Formulare werden hauptsächlich zur Eingabe, Anzeige oder Manipulation von Daten der Datenbank verwendet. Sie können direkt an Datenbankobjekte wie Tabellen oder Abfragen gebunden werden, um die entsprechenden Daten anzuzeigen bzw. Benutzereingaben zu verarbeiten. Steuerelemente wie Auswahlboxen, Knöpfe oder Eingabefelder innerhalb der Formulare stellen verschiedene Funktionen zur Verfügung und reagieren auf vom Benutzer ausgelöste
Ereignisse wie neue Eintragungen oder Mausklicks. Diese Ereignisse (z.B. bei
Klick oder beim Verlassen eines Feldes) können an VBA-Prozeduren und Funktionen gekoppelt werden, so dass der Entwickler Einfluss auf den Verlauf und
die Wirkungsweise dieser Ereignisse hat und direkt beeinflussen kann.
Module: Module stellen benutzerdefinierte Erweiterungen von Access dar, die in
der Programmiersprache VBA implementiert werden. Ein Modul besteht aus
Subroutinen und Funktionen (Funktionen geben Werte zurück, Subroutinen führen ausschließlich Code aus). Ebenfalls ist eine Kapselung in Klassen und ein
definierter Einsatzbereich (Private oder Public) der Prozeduren und Funktionen
möglich.
2.3. Visual Basic for Applications (VBA)
Das in MS Access verwendete VBA (Visual Basic for Applications) ist eine von
der Firma Microsoft entwickelte Skriptsprache zur Steuerung von Programmabläufen in MS-Office-Produkten. Es gleicht in der Syntax dem von Microsoft
entwickelten Basic-Dialekt Visual Basic, wurde aber für die Anwendung mit
MS-Office-Produkten optimiert und in seinen Funktionen und der
11
Leistungsfähigkeit gegenüber Visual Basic reduziert ([KOF99]). VBA stellt somit den „Unterbau“ für MS Access-Anwendungen dar.
Mit VBA-Code lassen sich Ereignisse der Steuerelemente wie „bei Klick“ oder
„nach Auswahl“ steuern. Darüber hinaus können VBA-Funktionen in SQLAbfragen integriert werden.
In VBA-Funktionen oder Subroutinen können Abfragen und Views direkt angesteuert werden oder SQL-Statements abgesetzt werden. Darüber hinaus hat der
Entwickler jedoch auch die Möglichkeit, einen Recordset, das heißt eine Kopie,
bestehend aus einer Tabelle oder Abfrage, direkt im Code zwischenzuspeichern,
ihn mittels Schleifen und Abfragen zu ändern und zurück in die Datenbank zu
schreiben. Dieser Vorgang ist natürlich längst nicht so effizient wie ein SQLStatement, ist aber in besonderen Fällen nicht zu umgehen, da diese Möglichkeit
in SQL zum Teil nicht ausgedrückt werden kann.
2.4. SQL
Die Structured Query Language, kurz SQL, wird verwendet, um relationale Datenbanken anzusprechen. SQL ist dabei sehr umfangreich und umfasst nicht nur
Anweisungen und Befehle zum Abfragen der Daten - wie man aus dem Namen
schließen könnte - sondern auch die Möglichkeit, Daten zu ändern und die Datenbank selbst zu beschreiben ([HES06]). Somit liefert SQL ein geeignetes
Werkzeug zur Administration und Benutzung von Datenbanken.
1986 wurde der erste SQL-Standard von ANSI (American National Standards
Institute) verabschiedet, welcher dann 1987 von der ISO (International Organization for Standardization) ratifiziert wurde. 1992 wurde der Standard deutlich
überarbeitet und als SQL-92 (oder auch SQL2) veröffentlicht. Alle aktuellen
Datenbanksysteme orientieren sich im Wesentlichen an diese Standardversion
([MAT03]).
Durch seine Rolle als Quasi-Standard für die Arbeit mit relationalen Datenbanksystemen ist SQL von großer Bedeutung, da eine weitgehende Unabhängigkeit
von der benutzten Software erzielt werden kann. Die meisten SQLImplementierungen bieten darüber hinaus allerdings noch herstellerspezifische
Erweiterungen, die nicht dem Standard-Sprachumfang entsprechen, was zur
Folge hat, dass von den Herstellern parallel entwickelte gleiche Funktionen unterschiedliche Sprachelemente benutzen ([WIK07]). Diese meist leichten
12
Abwandlungen des SQL-Standards werden häufig auch als SQL-Dialekte bezeichnet. Es handelt sich dabei aber in der Regel nur um geringfügige syntaktische Abweichungen. In den folgenden Abschnitten wird daher die Syntax des
von MS Access verwendeten Dialektes Jet-SQL verwendet. Außerdem liegt das
Hauptaugenmerk auf den in der Arbeit verwendeten Konstrukten von SQL.
SQL hat eine relativ einfache Syntax, die an die englische Umgangssprache angelehnt ist. Die beiden Hauptbestandteile sind die Data Definition Language
(DDL), die verwendet wird, um Datenstrukturen zu beschreiben, zu ändern oder
zu entfernen, und die Data Manipulation Language (DML), die einerseits für
Abfragen auf den Daten zuständig ist, anderseits für das Ändern, Hinzufügen
und Löschen von Daten benutzt wird. Diese beiden Teilaspekte von SQL werden
in den folgenden beiden Abschnitten kurz eingeführt und sind im Wesentlichen
an [KEM97] und [TEI07] orientiert.
2.4.1 Data Definition Language (DDL)
Die Datendefinitionssprache (Englisch: Data Definition Language oder kurz
DDL) ist der Teil von SQL, der die Datenstrukturen definiert. Im Einzelnen
kann man mit der DDL neue "leere" Datenbankstrukturen wie Tabellen, Indizes,
Views und weitere Objekte einrichten, die Strukturdefinition existierender Datenbank-Objekte verändern und Objekte löschen ([PHI02]).
Wie bereits in Kapitel 2.1 vorgestellt wurde, ist die grundlegende Struktur innerhalb einer Datenbank die Tabelle. Um Daten innerhalb einer Tabelle eindeutig
identifizieren zu können, wird die Tabelle mit einem Primärschlüssel (primary
key) ([HES06]) versehen. Der Primarschlüssel wird über ein oder mehrere Attribute der betreffenden Tabelle definiert, mit der Folge, dass die Datensätze innerhalb der Tabelle bei diesen Attributen, den Primärschlüsselattributen, keine
Duplikate enthalten dürfen. Die Identifikation der Datensätze kann daher über
diese Primärschlüsselattribute stattfinden. Häufig werden für Primärschlüssel
sogenannte Autowerte benutzt. Hierbei handelt es sich um Zahlenwerte, die von
DBMS verwaltet werden und autoinkrementell sind.
Man spricht von einem Fremdschlüssel (foreign key) bei einer Tabellenspalte,
wenn sie die Werte des Primärschlüsselattributs einer anderen Tabelle enthält.
Über den Fremdschlüssel einer Tabelle können also Datensätze einer anderen
Tabelle identifiziert werden. Durch einen Fremdschlüssel werden Relationen
zwischen Tabellen ausgedrückt.
13
Im Folgenden werden die wichtigsten Befehle zur Definition der Tabellenstruktur kurz beschrieben. Die Beispiele sind zum Teil aus dem der Arbeit zugrunde
liegenden System VerIS entnommen und damit besonders praxisnah.
CREATE TABLE: Mit diesem Befehl werden die Tabellen angelegt und dadurch ihr Schema bestimmt. Eine Tabelle besteht aus dem Tabellennamen sowie
den Attributen der Tabelle, welche unterschiedliche Datentypen (z.B. INT für
Ganzzahlen oder VARCHAR(x) für ein Textfeld mit der maximalen Länge x)
besitzen können. Die dem Datentyp hinten angestellte Integritätsbedingung NOT
NULL bedeutet, dass leere Einträge für dieses Attribut unzulässig sind. Der Befehl PRIMARY KEY hinter einem Attribut legt dieses als Primärschlüssel der
Tabelle an. Im Beispiel wird das Schema der Tabelle term definiert. Eine Tabelle
kann man mit dem Befehl DROP TABLE (Syntax: DROP TABLE [Tabellenname]) wieder aus der Datenbank entfernen.
CREATE TABLE [term](
myid INT PRIMARY KEY,
id INT NOT NULL ,
name VARCHAR(255) NOT NULL,
term_type VARCHAR(55) NOT NULL,
acc VARCHAR(255) NOT NULL,
is_obsolete LONG NOT NULL,
is_root LONG NOT NULL);
ALTER TABLE: Um nach der Erstellung einer Tabelle ihre Datenstruktur zu
ändern, wird dieser Befehl genutzt. Spalten lassen sich hinzufügen (ADD) und
löschen (DROP). Außerdem kann der Datentyp der Spalte geändert werden
(ALTER, siehe Beispiel).
ALTER TABLE [Tabellenname] ALTER COLUMN [Spaltenname] INT
Ist bei der Konzeption einer Datenbank oder in deren späterem Einsatz klar, dass
gewisse Spalten einer Tabelle häufig zu Abfragezwecken genutzt werden, ist es
möglich, auf diese Attribute einen Index zu setzen. Dabei werden die Werte des
14
entsprechenden Attributs in einer speziellen Indexstruktur, wie zum Beispiel
einem B+-Baum, abgelegt. Damit kann sich der Zeitaufwand für die Suche nach
Werten des mit einem Index belegten Attributs von linear (O(n)) auf logarithmisch (O(log n)) reduzieren. Dadurch wird die Suche nach diesen Feldern zum
Teil enorm bescheunigt. Indizes werden vom DBMS verwaltet. Das folgende
Beispiel erläutert die Erstellung eines Index:
CREATE INDEX: Hiermit wird ein Index auf ein bestimmtes Argument einer
Tabelle gesetzt, um spätere Abfragen zu beschleunigen. Im Beispiel wird ein
Index mit Namen t1 auf das Argument name der Tabelle term gesetzt. Ein Index
kann mit dem Befehl DROP INDEX wieder entfernt werden. Durch das Schlüsselwort UNIQUE wird sichergestellt, dass es sich um einen eindeutigen, also
duplikatfreien Index handelt.
CREATE
([name]);
INDEX
[t1]
ON
[term]
2.4.2 Data Manipulation Language (DML)
Mit der Datenmanipulationssprache von SQL (Englisch: Data Manipulation
Language oder kurz DML) werden Datensätze in die Datenbank eingefügt, in ihr
geändert oder aus ihr gelöscht. Außerdem können die Inhalte der Datenbank ermittelt werden, wobei es möglich ist, über Selektionsbedingungen gezielt Datensätze zu filtern.
Das Einfügen von Datensätzen in die Datenbank kann auf zwei Arten geschehen: entweder durch Angabe der Werte, die ein neuer Datensatz enthalten soll,
oder aber über die Selektion anderer Inhalte der Datenbank. Bei der Einfügeoperation sind vorhandene Integritätsbedingungen zu beachten. So müssen beispielsweise solche Attribute zwingend belegt werden, die entweder als Primärschlüsselattribut oder mit einer Integritätsbedingung NOT NULL definiert sind,
bei den restlichen Attributen darf ein Wert fehlen und wird in der Regel als
NULL-Wert angesehen. Außerdem darf der neu eingefügte Datensatz nicht zu
einer Verletzung der Primärschlüsseleigenschaft führen, das heißt, dass bei Primärschlüsselattributen keine zwei Datensätze identische Inhalte haben dürfen.
Die Verletzung einer Integritätsbedingung führt zum Abbruch der Einfügeoperation.
15
Bei einer Änderung von bereits in der Datenbank gespeicherten Datensätzen
kann der Wert für ein Feld oder für mehrere Felder durch einen neuen, eindeutigen Wert ersetzt werden. Über eine Selektionsbedingung wird dabei eine Menge
von Datensätzen einer Tabelle ausgewählt, deren Feldinhalte dann geändert werden. Sollte mit dieser Selektionsbedingung kein vorhandener Datensatz ermittelt
werden, dann wird die Operation ohne Datenänderung beendet. Für die Änderungsoperation gilt ebenso wie für das Einfügen neuer Datensätze, dass Integritätsbedingungen beachtet werden müssen, was zur Folge hat, dass deren Verletzung auch bei einer Änderung zum Abbruch der Operation führt.
Mit der Löschoperation können vorhandene Datensätze einer Tabelle aus der
Datenbank entfernt werden. Diese Datensätze können ebenfalls über eine Selektionsbedingung ausgewählt werden, ansonsten werden alle Datensätze der genannten Tabelle aus der Datenbank gelöscht. Die Operation wird ohne Änderung
der Datenbasis beendet, wenn keine vorhandenen Datensätze für das Löschen
ermittelt werden können, sei es durch die Angabe einer Selektionsbedingung
oder auch, weil die Tabelle leer ist.
Der folgende Abschnitt zeigt die SQL-Definitionen der bisher beschriebenen
Operationen:
INSERT : Mit diesem Kommando wird eine Menge von Datensätzen in eine
Tabelle der Datenbank eingefügt. Im folgenden Beispiel wird ein einzelner Datensatz in die Tabelle term eingefügt, wobei die Werte der einzelnen Felder vorgegeben werden. Wie bereits geschildert wurde, kann das Einfügen von Datensätzen auch mit Hilfe einer Selektion anderer Inhalte der Datenbank erfolgen –
dies wird hier nicht weiter aufgezeigt.
INSERT INTO term
(myid, id, name, term_type, acc, is_obsolete, is_root)
VALUES
(1, 1, ‘Name’, ‘Type’, ‘acc’, 1, 1);
UPDATE : Über das UPDATE-Kommando kann eine Menge von bereits in der
Datenbank vorhandener Datensätze einer Tabelle geändert werden. Das Beispiel
zeigt die Änderung des Inhalts für das Feld is_obsolete eines Datensatzes der
Tabelle term:
UPDATE term SET is_obsolete = 0 WHERE myid = 1;
16
DELETE: Über das DELETE können in einer Tabelle vorhandene Datensätze
gelöscht werden. Mit der Angabe einer Selektionsbedingung lassen sich die zu
löschenden Datensätze einschränken. Wenn keine Selektionsbedingung verwendet wird, dann wird die entsprechende Tabelle komplett geleert. Das Beispiel
zeigt das Löschen eines Datensatzes (was durch die Verwendung eines Primärschlüsselattributs in der Selektionsbedingung sichergestellt ist) der Tabelle term:
DELETE * FROM term WHERE myid = 1;
Ein weiterer, umfangreicher Einsatzbereich von SQL ist die Formulierung von
Abfragen auf der Datenbank. Bei diesen Abfragen können Felder verschiedener
Tabellen wiedergegeben und komplexe Selektionen formuliert werden. Die
Möglichkeiten werden im Folgenden mit Hilfe von Beispielen aufgezeigt:
SELECT: Über das SELECT-Kommando werden Abfragen von Datenbankinhalten formuliert. Das Ergebnis eines solchen Kommandos ist eine Menge von
Datensätzen, der Ausgabemenge bzw. Ergebnismenge der Abfrage. Die Grundstruktur sieht wie folgt aus:
SELECT <Feldliste>
FROM <Tabellenliste>
WHERE <Selektionsbedingung>;
Die Tabellenliste führt die Tabellen auf, auf die sich die Anfrage bezieht. Mit
der Feldliste werden die Felder benannt, die in der Ausgabemenge aufgeführt
werden sollen. Die benannten Felder müssen sich dabei auf Tabellen der Tabellenliste beziehen, die Werte der Felder können dabei aber auch über Aggregation
gewonnen werden. Über die Selektionsbedingung wird eine Auswahl der Datensätze getroffen, die in die Ausgabemenge übernommen werden sollen. Dabei
können auch mehrere Bedingungen über logische Operatoren (AND, OR) verknüpft werden.
17
Das Beispiel zeigt eine einfache Anfrage, mit der die ID’s aller Datensätze der
Tabelle D_Term ausgegeben werden, deren Eigenschaft Delta_typ den Wert ‚P’
oder den Wert ‚M’ hat:
SELECT ID
FROM D_Term
WHERE Delta_typ = ‘P’ OR Delta_typ = ‘M’;
Aggregationsfunktionen: Wie bereits bei der Beschreibung des SELECTKommandos aufgeführt wurde, kann die Ausgabemenge einer Datenbankabfrage
auch aggregierte Werte enthalten. Hierfür stehen in SQL verschiedene Aggregationsfunktionen zur Verfügung. Damit lassen sich beispielsweise die Anzahl von
Datensätzen, aber auch die Summe oder das Maximum eines Feldes für die selektierten Datensätze ermitteln. Als Beispiel wird eine Abfrage formuliert, die
den höchsten Datumswert (also das letzte Datum) der Spalte datum in der Tabelle D_Term für Datensätze mit dem Wert ‚P’ für das Feld Aenderungstyp angibt:
SELECT MAX([datum]) as Max_Datum
FROM D_term
WHERE Delta_typ = 'P';
JOIN: Bei einer Abfrage über die Inhalte mehrerer Tabellen kann sich die Selektion auf einzelne Attribute der beteiligten Tabellen beziehen, es ist aber auch
möglich, die Relationen von zwei Tabellen mit Hilfe eines Joins auszuwerten.
Dabei werden die Inhalte der entsprechenden Attribute der beteiligten Tabellen
miteinander in Beziehung gebracht. Zum Beispiel findet eine Selektion auf die
Datensätze der beiden beteiligten Tabellen statt, die eine Übereinstimmung in
den für den Join verwendeten Attributen haben. Ohne die Formulierung eines
derartigen Joins würde bei der Anfrage über zwei Tabellen deren Kreuzprodukt
in die Ergebnismenge aufgenommen.
18
Als Beispiel wird die Selektion über die Tabellen term und D_Term auf die Datensätze eingeschränkt, die eine Übereinstimmung für das Feld ID haben:
SELECT term.Name, D_Term.Name_old, D_Term.Name_new
FROM term INNER JOIN D_term
ON term.ID = D_term.ID;
UNION: Wie bereits erwähnt wurde, besteht das Ergebnis einer Abfrage aus
seiner Ergebnismenge. Man kann eine Abfrage aber auch strukturieren und die
Zwischenergebnisse einzelner Unterabfragen, die aus voneinander unabhängigen
SELECT-Kommandos bestehen, über Mengenoperationen miteinander zu einer
einzelnen Ergebnismenge verknüpfen. Dabei wird die Mengen-Vereinigung über
einen UNION-Operator ermöglicht. Voraussetzung für dessen Anwendung ist,
dass die Ergebnismengen der beteiligten Unterabfragen jeweils die gleichen Felder enthalten. Als Beispiel wird hier die Vereinigung aller Datensätze der Tabelle D_Term des Änderungstyps ‚P’ mit denen des Änderungstyps ‚M’ ermittelt:
SELECT D_Term.Name_old as Name
FROM D_Term
WHERE D_Term.Delta_typ= ‘M’
UNION
SELECT D_Term.Name_new as Name
FROM D_Term
WHERE D_Term.Delta_typ= ‘P’;
IN / NOT IN: Eine weitere Form der Mengenoperation ist die Bedingung, dass
ein Wert in einer Menge, beispielsweise der Ergebnismenge einer Unterabfrage,
enthalten ist, bzw. über die logische Verneinung, dass ein Wert in einer Menge
nicht enthalten ist. Als Beispiel werden die Namen aller Datensätze der Tabelle
term ausgegeben, die nicht in der Tabelle D_term enthalten sind:
SELECT term.Name
FROM term
WHERE term.ID NOT IN
(SELECT D_term.ID
FROM D_term);
19
2.5. Versionsmanagement
2.5.1 Übersicht
Ein Versionsmanagement dient allgemein dazu, einen historischen Verlauf über
gleichartige, veränderbare ‚Einheiten’ beschreiben zu können. Über ein Versionsmanagement lassen sich beispielsweise im Rahmen der Softwareentwicklung
die Quelldateien für ein Computer-Programm verwalten. Dabei werden die von
den Programm-Entwicklern freigegebenen Entwicklungsstände einzelner Quelldateien in einem Versionsmanagement-System (auch version control system)
verwaltet. Dies ist damit ein wesentlicher Bestandteil des SoftwareKonfigurations-Managements.
Jede über das Versionsmanagement verwaltete Einheit kann in mehreren Versionen vorliegen, wobei eine einzelne Version jeweils eine zeitliche Gültigkeit hat.
Bei der Software-Entwicklung liegt beispielsweise eine Quelldatei in mehreren
Versionen vor. Der Gültigkeitsbeginn der Version einer Quelldatei ist dann der
Moment, an dem ein Entwickler den Stand der Quelldatei, der seine Änderungen
enthält, in das Repository des Versionsmanagements eingefügt hat, und das Gültigkeitsende liegt an dem Zeitpunkt, an dem eine neue Version der Quelldatei
eingefügt wurde.
Mit dieser Abfolge der einzelnen Versionen lassen sich über ein Zeitintervall
jeweils eindeutige Zustände der verwalteten Einheiten feststellen. Das verfügbare Zeitintervall kann dabei beispielsweise bei der Softwareentwicklung von dem
Beginn der Entwicklung bis in die Gegenwart laufen. Auch eine Reproduktion
alter Versionen der Quelldateien, das heißt durch neuere Versionen bereits ersetzte Zustände, ist mit Hilfe des Versionsmanagements möglich.
2.5.2 Differenzspeicherung
Um den Speicherverbrauch eines Versionsmanagement-System gering zu halten,
werden für die einzelnen verwalteten Einheiten, sofern deren Art dies erlaubt,
nicht alle vorhandenen Versionen jeweils komplett gespeichert, da dies zu einem
extrem großen Bedarf an Speicherplatz führen würde. Ein gängiges Verfahren,
den Speicheraufwand zum Beispiel von textuellen Informationen erheblich zu
20
reduzieren, ist die Delta-Kodierung oder auch Differenzspeicherung (ebenfalls
delta encoding oder delta compression).
Bei der Differenzspeicherung handelt es sich um eine Möglichkeit der Datenkompression. Hierbei liegt nur die aktuelle Version einer Daten-Einheit,
beispielsweise einer Textdatei, in ihrem vollen Umfang vor, darüber hinaus werden die Differenzen zwischen jeweils zwei aufeinander folgenden Versionen der
Daten-Einheit gespeichert. Praktische Einsatzbereiche der Differenzspeicherung
sind beispielsweise die bereits erwähnten Versionsmanagement-Systeme für die
Software-Entwicklung, aber auch Komprimierungsverfahren von Filmdateien
wie MPEG-Formate nutzen dieses Vorgehen.
Mit Hilfe der Differenzspeicherung ist die Rekonstruktion alter Versionen der
Daten möglich. Ausgehend von einem vorhandenen Datenstamm und unter
Ausnutzung der gespeicherten Differenz-Informationen kann die Version eines
beliebigen Zeitpunkts wiederhergestellt werden.
In dem Bereich von Datenbanken kann man mittels der Differenzspeicherung die
Änderungen einzelner Datensätze innerhalb einer Datenbank erfassen. Dazu
wird zu einer einzelnen Tabelle zusätzlich eine so genannte Delta-Tabelle eingerichtet, die allein der Aufnahme von Datenänderungen innerhalb ihrer Referenztabelle dient. Eine solche Delta-Tabelle enthält neben einem Attribut für einen
Zeitstempel, an dem also die Änderung wirksam wurde, auch Informationen über die Art der Datenänderung (Einfüge-, Änderungs- oder Löschoperation) sowie die Inhalte der Änderung, also die Inhalte der geänderten Attribute im Zustand vor und nach der Änderung.
Delta-Tabellen dienen aber nicht nur der platzsparenden Speicherung
sequenzieller Daten (=Daten, die in mehreren Versionen vorliegen), denn mit
Hilfe der Delta-Tabellen erhält der Benutzer zudem Informationen über Art und
Ausmaß aller vorgenommenen Änderungen. Durch gezielte Abfragen auf diesen
Tabellen wird es dem Benutzer zum Beispiel ersichtlich, wie viele Datensätze
sich in einem bestimmten Zeitraum geändert haben und um welchen Typ von
Änderung (hinzugefügte Daten, gelöschte Daten, modifizierte Daten) es sich
hierbei handelt.
Im folgenden Schaubild wird an einem Beispiel veranschaulicht, wie eine solche
Differenzspeicherung aussehen könnte. Es gibt jedoch verschiedenste Möglichkeiten, eine Differenzspeicherung und eine Rekonstruktion alter Versionen der
Daten durchzuführen. Sie werden im Kapitel 4 genauer erläutert.
21
Abbildung : Differenzspeicherung
2.5.3 Versionen und Updates in Datenbanken
Für das Versionsmanagement von Datenbanken müssen zwei Versions-Arten
unterschieden werden: der Versionsstand einer gesamten Datenbasis und der
Versionsstand eines einzelnen Datensatzes innerhalb der Datenbank. Während
eine Datenbasis beispielsweise täglich einen neuen Gültigkeitsstand repräsentieren kann, ist es möglich, dass die Anzahl der Datensätze, die zwischen zwei aufeinander folgenden Tagen geändert wurden, gering ist. Ein einzelner Datensatz
kann also einen größeren Gültigkeitszeitraum haben, als dies durch das Versionierungsinterval der Datenbasis nahegelegt wird.
Bei unterschiedlichen Versionen einer Datenbasis handelt es sich um vollkommen voneinander getrennte Daten. Der Benutzer erhält keine Informationen darüber, ob und in welchem Ausmaß sich die Daten geändert haben. Wenn also eine
lokale Datenbank mit einer solchen Datenbasis synchronisiert werden soll, dann
müssen die bereits existierenden Daten im vollen Umfang durch die aktuelle
Version der Daten ersetzt werden. Dies hat natürlich einen erheblichen und unnötigen Mehraufwand zur Folge, da die Daten immer im Ganzen ersetzt werden
müssen.
Wenn hingegen eine Datenbank Updates ihrer Daten zur Verfügung stellt, dann
wird eine vorhandene Datenbasis alleine durch das Einspielen dieser Aktualisie-
22
rungen auf den neuesten Stand gebracht. Es werden dabei nur die Datensätze
ausgetauscht, hinzugefügt oder gelöscht, welche von tatsächlichen Änderungen
betroffen sind. Mittels des Zeitstempels der Änderungen und der Datenbasis
lässt sich genau bestimmen, bis zu welchem Zeitpunkt die Änderungen auf den
Daten erfolgen müssen.
Im Falle der Gene Ontology liegen die Daten lediglich in Form von Versionen
vor. Updates für vorhandene Daten sind nicht erhältlich. Der Anwender hat die
Möglichkeit zwischen Datensätzen zu wählen, die täglich, wöchentlich oder monatlich neu erstellt und im Internet verfügbar gemacht werden, aber unabhängig
von vorherigen Daten für sich alleine stehen. Um ein Versionsmanagement zu
konzipieren und zu erstellen, ist also zunächst ein Vergleich zwischen zwei bzw.
mehreren Versionen notwendig, um die Unterschiede zwischen diesen Versionen sichtbar und nutzbar zu machen. Hierzu wird in der vorliegenden Arbeit die
Differenzspeicherung mit Zeitstempeln verwendet.
23
3. Ontologien
In diesem Kapitel wird der Begriff Ontologie definiert und näher erläutert. Insbesondere wird dabei auf die Gene Ontology eingegangen, die als Datengrundlage für das im Rahmen dieser Diplomarbeit entwickelte Versionsinformationssystem (VerIS) dient und an deren Beispiel ein Konzept für ein Versionsmanagement entwickelt werden soll. Des Weiteren werde ich in diesem Abschnitt
Beispiele anderer Ontologien vorstellen und die Repräsentation von Ontologien
in relationalen Datenbanken bzw. die Abbildung einer Ontologie auf ein ERSchema beschreiben.
3.1. Begriffsdefinition
Der Begriff Ontologie stammt aus dem Griechischen und bezeichnet wörtlich
übersetzt die Lehre vom Seienden. Die philosophische Disziplin Ontologie erklärt die Grundstrukturen des Seienden [PÖG82]. Methodisch geht diese Richtung der Philosophie meist den Weg, allgemeine Strukturen der Wirklichkeit
mittels Sprachanalyse zu erfassen, die Wirklichkeit also durch Kategorien wie
Ding, Eigenschaft oder Ereignis und Attribute der Kategorien wie Teil oder
Ganzes darzustellen. Dabei kommt man zu Fragen wie „Ist eine Entität nur ein
Bündel ihrer Attribute?“
In der Informatik wird der Begriff Ontologie entsprechend verwendet, um einen
Teil der Wirklichkeit durch eine Menge von Begriffen und Beziehungen dieser
Begriffe untereinander darzustellen. Dem liegt folgendes Problem zugrunde:
Der Mangel an einem gemeinsamen Verständnis (shared understanding) führt oft
zu Kommunikationsproblemen zwischen Menschen, Organisationen, Systemen
24
und kann die Interoperationsfähigkeit, die Wiederverwendbarkeit und die gemeinsame Nutzung von Daten behindern oder gar verhindern ([UG96]).
Ein gemeinsames Verständnis meint in diesem Zusammenhang eine verständliche Terminologie und ein einheitliches Konzept. Eine Ontologie wird gekennzeichnet durch folgende Merkmale:
•
•
•
•
•
Formale Spezifikation
Definiertes Basisvokabular
Explizite Definition von Entitäten und deren Attributen, Eigenschaften
Festlegung der Beziehungen, Relationen zwischen den Entitäten
Definition von Axiomen, d.h. Aussagen, die innerhalb der Ontologie immer wahr sind
• Angabe von Vererbungsbeziehungen zwischen den Entitäten: Eine Entität
erbt alle Attribute und Relationen einer anderen Entität
Eine Definition des Begriffs Ontologie hat Tom Gruber gegeben:
„An ontology is a specification of a conceptualization.“ [GRU93]
Eine andere Definition geben Professor Dr. Rudi Studer et al.:
„Eine Ontologie stellt [..] ein formalisiertes Modell der Welt oder eines Teils
der Welt dar [...].“ [STU01]
Nachfolgende Abbildung aus [WIK07] zeigt an einem Beispiel den Aufbau einer
Ontologie und den Unterschied zwischen Instanzen einer Ontologie und der Ontologie selbst.
25
Abbildung : Aufbau einer Ontologie
Der Erstellung einer Ontologie liegt immer ein Zweck zugrunde, so dass zwei
Ontologien zum gleichen Bereich sich nicht nur durch eine verschiedene Terminologie, sondern auch durch eine unterschiedliche Konzeptualisierung auszeichnen können. So können beispielsweise einige Attribute oder Entitäten für einen
bestimmten Zweck sinnlos oder überflüssig sein.
3.2. Beispiele für Ontologien
In einigen Bereichen haben sich de facto Standardontologien etabliert. Sie sollen
an dieser Stelle kurz beschrieben werden.
26
3.2.1 Foundational Model of Anatomy (FMA)
Die FMA Ontologie ([FMA07]) wird von der medizinischen Fakultät der University of Washington entwickelt und verfolgt das Ziel, ein Modell der Struktur
des menschlichen Körpers zu erstellen. Die Ontologie selbst kann dazu verwendet werden nicht nur die Instanz Mensch darzustellen, sondern auch jedes andere
Lebewesen.
Die Ontologie besteht aus vier Grundkomponenten:
• Den anatomischen Entitäten mit ihren Attributen
• Den Relationen der Entitäten untereinander, d.h. die part-of-Beziehungen
(z.B. ein bestimmter Knochen oder Muskel ist Teil des Unterarms) und
den räumlichen Beziehungen der Entitäten untereinander (z.B. der Kopf
ist über und verbunden mit dem Hals)
• Zeitlichen Veränderungen der Entitäten (z.B. die Veränderungen der Organe im Verlauf der Entwicklung des Fötus im Mutterleib)
• Prinzipien und Regeln, die die anderen drei Komponenten betreffen.
Die FMA enthält momentan über 120000 Entitäten und 2.1 Millionen Relationen.
3.2.2 General Ontology for Linguistic Description (GOLD)
Die Idee GOLD wurde 2003 im Rahmen seiner Dissertation von Scott Farrar
erdacht, um die Struktur von aussterbenden Sprachen festzuhalten. Die erste
Version von GOLD entwickelte Will Lewis an der Universität Arizona. Seit November 2004 wurde GOLD stetig von der neu gegründeten GOLD Community
([GOL07]) weiterentwickelt. GOLD bildet die Struktur einer Sprache auf die
Aspekte Fall, Geschlecht, Zeit, Aussprache, Vokabeln, etc. ab. Jede Sprache
kann als Instanz dieser Ontologie dargestellt werden.
3.2.3 Semantic Web
Das Semantic Web ist eine Erweiterung des WWW. Neben für Menschen lesbarem Text enthalten Web-Seiten auch maschinenlesbare Informationen, die die
Semantik der Seite automatisch auch für Programme verarbeitbar macht. Diese
27
Daten werden in der Wissens-Repräsentationssprache Web Ontology Language
(OWL) ausgedrückt. Das Semantic Web und OWL wurden vom W3C spezifiziert und gehen auf eine Initiative von Tim Berners-Lee zurück.
3.3. Repräsentation von Ontologien in Datenbanken
Entitäten und Relationen sind bekannte Konzepte der relationalen Datenbankmodellierung. Allein das Axiomensystem und das Vererbungskonzept der Ontologien bilden bei der relationalen Modellierung ein Problem.
3.3.1 Modellierung von Vererbung
Die Abbildung von Vererbung in relationalen Datenbanken wurde im Rahmen
der EJB3.0 Spezifikation [MK06] eingehend untersucht. Es gibt grundlegend
drei Strategien, Vererbung in einem Datenbankschema zu persistieren. Die verschiedenen Strategien werden nachfolgend an einem Beispiel verdeutlicht. Gegeben sei folgende Ontologie und diese soll in einem Datenbankschema abgebildet werden :
String
Farbe
Fahrzeug
Fahrrad
Gänge
Integer
Auto
PS
Integer
Schiff
BRT
Integer
28
Ein-Tabellen-Strategie
Bei Anwendung dieser Strategie werden alle Instanzen, die zu einer Vererbungshierarchie gehören, in einer Tabelle abgelegt.
Farbe
Gänge
PS
BRT
Typ
Die Spalte „Typ“ gibt an, welche Entität die jeweilige Zeile vertritt. Der Typ
kann Fahrzeug, Fahrrad, Auto oder Schiff sein.
Tabelle-pro-Enität-Strategie
Für jede Entität wird eine eigene Tabelle erzeugt.
Tabelle Fahrzeug
Farbe
Tabelle Fahrrad
Farbe
Gänge
Tabelle Auto
Farbe
PS
Tabelle Schiff
Farbe
BRT
29
Join-Strategie
Jede Entität kann nur mittels eines Joins abgefragt werden. Die Eltern-KindKind-Beziehung wird über einen Fremdschlüssel realisiert.
Tabelle Fahrzeug
PrimaryKey_FahrzeugID
Fahrzeug
Tabelle Fahrrad
Gänge
ForeignKey_FahrzeugID
Tabelle Auto
PS
ForeignKey_FahrzeugID
Tabelle Schiff
BRT
ForeignKey_FahrzeugID
Jede der drei Strategien hat Vor- und Nachteile, die den Speicherplatzverbrauch,
die Abfragegeschwindigkeit und Wartbarkeit betreffen. Eine Diskussion dieser
Strategien soll an dieser Stelle vermieden werden, da hier nur die grundsätzliche
Realisierung der Abbildung von Ontologien in eine relationale Datenbank gezeigt werden soll.
3.3.2 Modellierung von Axiomen
Axiome einer Ontologie können durch Kreuztabellen und Constraints in die relationale Welt überführt werden. Gerade weil Axiome in einer gegebenen Ontologie unveränderbar sind, ist es stets möglich, ein relationales Schema so zu realisieren, dass ein Verstoß gegen die Axiome unmöglich gemacht wird.
30
3.4. Die Gene Ontology
Das Human Genome Project und andere Projekte zur Entschlüsselung des Erbguts verschiedener Arten erfordern die Zusammenarbeit zwischen Biochemie
und Genetik, die aufgrund der großen Datenvolumina in erheblichem Maße
durch automatisierten Datenaustausch unterstützt werden muss [SK].
Deswegen ist gerade in diesem Bereich eine standardisierte Ontologie, die Begriffe wie Art, Spezies, Prozess, Sequenz etc. definiert, wichtig. Das Gene Ontology Consortium hat mit dem Aufbau der Gene Ontology [GEN07] einen Beitrag zur Integration der gesamten Biologie und Genetik geleistet. Die Gene Ontologie umfasst Termini und Definitionen, die unabhängig von Spezies sind,
sich auf zentrale biologische Kategorien wie Zellen, Wachsen, Sterben, … beziehen.
Die Gene Ontology ist in drei Domänen unterteilt:
• Cellular Component (ca. 1900 Terme),
• Biological Process (ca. 11000 Terme) und
• Molecular Function (ca. 8000 Terme).
Alle Begriffe dieser drei Domäne können durch die zwei Relationen „part_of“
und „is_a“ verknüpft werden. Verknüpfungen zwischen den Domänen existieren
nicht – nur innerhalb einer Domäne. Die Gene Ontology ist auf eine relationale
mySQL Datenbank abgebildet.
Die Betrachtung des Versionierungsproblems bzw. der Verfolgung von Änderungen der Gene Ontology Datenbankeinträge wird sich auf die Haupttabelle
„term“ beziehen, daher wird an dieser Stelle nicht weiter auf das Schema der
Gene Ontology eingegangen. Alle Daten der Gene Ontology sind frei zugänglich
und können kostenlos von der Web-Seite des Gene Ontology Consortiums bezogen werden.
Die Daten der Gene Ontology sind in den Formaten mySQL und GO RDF-XML
verfügbar. Für einen Transfer in eine Access-Datenbank ist das mySQL-Format
am geeignetsten.
31
Die Daten können in drei verschiedenen „Release-Zuständen“ bezogen werden :
Monthly Release: Die Daten werden zu Beginn jedes Monats (gewöhnlich der 6.-8. Tag des Monats) zur Verfügung gestellt. Sie enthalten über
die Basisdaten hinaus noch zusätzliche IEA-Annotationen, die allerdings
für ein Versionsmanagement und daher auch für diese Arbeit nicht von
Interesse sind. Alle monatlichen Veröffentlichungen von Dezember 2002
an sind im Archiv der Website zugänglich.
Weekly Release: Die wöchentlichen Versionen der Daten enthalten die
Basisdaten ohne die IEA-Annotationen. Alle wöchentlichen Versionen
der letzten 6 Monate können im Archiv abgerufen werden. Für die Zeit
davor steht lediglich ein wöchentliches Release pro Monat (meist in der
Monatsmitte) zur Verfügung. Außerdem sind nur Daten bis ca. 2 Jahre
vor dem aktuellen Datum verfügbar.
Daily Release: Auch die täglichen Versionen der Daten beinhalten nur
die Basisdaten. Abrufbar sind die letzten 3-4 Monate. In der Zeit gibt es
pro Woche nur eine tägliche Version. Und dies gilt auch nur für den Zeitraum eines Jahres. Tägliche Versionen, die älter als ein Jahr sind, werden
nicht bereitgestellt.
Unabhängig von Format und Release der Daten ist es aber nur möglich, die
Basisdaten komplett, also als Versionen zu erhalten. Updates der Datenbasis
sind nicht verfügbar.
32
4. Konzept eines Versionsmanagement
Beispiel der Gene Ontology
am
Die Datenbestände großer Ontologien werden dem Anwender meist in verschiedenen Formaten über das Internet zugänglich gemacht. Dieser kann nun die Daten in ein beliebiges Datenbanksystem einspeisen, um mit ihnen zu arbeiten. Da
sich die Datenbestände aber unter Umständen in sehr kurzen Abständen ändern
können und der Benutzer mit möglichst aktuellen Daten arbeiten möchte, ist ein
Abgleich der vorhandenen, bereits eingelesenen Datenbasis mit den neuen, aktuellen Daten notwendig. Verfügt eine Datenbank über ein Versionsmanagement,
werden Informationen über die Änderungen, die zwischen den beiden Versionen
der Datenbank aufgetreten sind, genutzt, um nur diejenigen Daten auszutauschen, die sich tatsächlich geändert haben. Es werden also Updates und Änderungsinformationen für die Daten bereitgestellt.
Bei der Gene Ontology handelt es sich um eine schnell gewachsene und schnell
wachsende Ontologie, die vor allem von Biologen genutzt und entworfen wurde.
Leider treten bei solchen Projekten in der Praxis oftmals konzeptuelle Fehler
bzw. Unzulänglichkeiten auf. Ein Konzept im Umgang mit den verschiedenen
Versionen und Änderungen der Datenbasis ist für eine Ontologie dieser Größenordnung eigentlich unverzichtbar. Die Gene Ontology verfügt jedoch nicht über
ein solches Versionsmanagement.
Es sind nur Versionen der Daten verfügbar. Das heißt, dass der Benutzer ausschließlich dazu gezwungen ist, den gesamten Datenbestand aus der Gene Ontology wieder in das von ihm genutzte Datenbanksystem zu importieren. Oftmals
ist dies aber unnötig, da sich kein Datensatz oder nur eine sehr geringe Anzahl
von Datensätzen geändert hat. Dagegen kann jedoch ein Datenaustausch bei vielen Änderungen auf einmal absolut notwendig sein. Da dem Benutzer aber Informationen über das Änderungsverhalten der Daten (z.B. „Wann haben sich wie
viele Datensätze geändert?“) fehlen, muss ein oft sinnloser Austausch der Daten
33
vorgenommen werden. Dieser Vorgang ist sehr ineffizient, da der gesamte Datenbestand einer großen Ontologie unter Umständen sehr mächtig sein kann. Im
Fall der Gene Ontology hat der komplette Datenbestand die Größe von ca. 9
Megabyte.
Sinnvoller wäre es daher, nur die tatsächlichen Änderungen der Daten neu in das
vom Benutzer verwendete Datenbanksystem zu integrieren. Da sich zwischen
zwei Versionen üblicherweise nur ein geringer Prozentsatz der Daten ändert,
bliebe die Mehrzahl der unveränderten Daten unangetastet. Dies würde zu einem
effizienteren Datenaustausch führen.
In diesem Kapitel wird ein Konzept für eine mögliche Umsetzung eines Versionsmanagements für die Gene Ontology vorgestellt. Es wird herausgearbeitet,
wie ein Abgleich der vorhandenen Daten mit den aktuellen Daten aussehen
kann. Besonderes Augenmerk gilt hierbei der Gewinnung und der Speicherung
der Änderungen, die durch einen solchen Abgleich ermittelt werden. Ziel ist es,
diese Änderungsdaten sinnvoll zu speichern, um daraus nützliche Informationen
über das Änderungsverhalten zu erhalten. Darüber hinaus soll ein schneller
Zugriff auf alte Versionen der Daten möglich gemacht werden, die sich mit Hilfe
der Datenbasis und den Änderungsdaten bestimmen lassen.
Zunächst wird das Änderungsverhalten der Daten der Gene Ontology am Beispiel der Haupttabelle term analysiert (4.1). Die daraus gewonnenen Erkenntnisse motivieren den Abschnitt über die Effizienzprobleme bei Datenbanken, bei
denen ein Versionsmanagement nicht vorhanden ist (4.2). In Kapitel 4.3 wird
dann ein Konzept einer möglichen Umsetzung eines Versionsmanagement erarbeitet. Bei dem „Schlüsselproblem“ in Kapitel 4.4 handelt es sich um ein spezifisches Problem der Gene Ontology, welches im Verlauf der Arbeit deutlich
wurde.
4.1. Untersuchung
Ontology
des
Änderungsverhaltens
der
Gene
Die Gene Ontology besteht aus einer Vielzahl von Tabellen und Relationen zwischen diesen Tabellen. Eine genaue Analyse des Änderungsverhaltens der gesamten Gene Ontology würde daher den Rahmen dieser kurzen Untersuchung
sprengen. An dieser Stelle sei lediglich eine Übersicht über die Anzahl der Datensätze der größten Tabellen der Gene Ontology gegeben :
34
Tabellenname
graph_path
term_dbxref
dbxref
term
term_definition
Anzahl der
Datensätze
1.848.357
91.559
36.123
22.342
21.446
Abbildung : Die größten Tabellen der
Gene Ontology (Stand September 2006)
In diesem Abschnitt soll das Änderungsverhalten der Gene Ontology am Beispiel der Tabelle term genauer untersucht werden. Es handelt dabei um die
Haupttabelle der Gene Ontology, in der die Termnamen der drei Domänen („biological_process“, „cellular_component“ und „molecular_function“), sowie eine
vierte Gruppe von unterschiedlichen Typen (z.B. „part_of“-Beziehung) abgelegt
sind. Die Tabelle term enthält ca. 20.000 Datensätze.
Abbildung :Auszug der Tabelle term
Diese Tabelle wird auch exemplarisch als Datenquelle für das dieser Arbeit
zugrundeliegende Datenbanksystem VerIS genutzt. Da Informationen über das
Änderungsverhalten der Gene Ontology nicht vorliegen, wurden die Daten für
die folgende Untersuchung durch das System VerIS gewonnen.
35
Einen ersten Überblick über das Änderungsverhalten erhält man, indem
Um einen ersten Überblick zu bekommen, betrachtet man die Versionen von
Beginn der Bereitstellung der Daten bis zum jetzigen Zeitpunkt. Versionen der
Daten der Gene Ontology sind ab dem Stand Januar 2003 im Internet verfügbar.
Unten stehende Tabelle zeigt die Gesamtanzahl der Änderungen seit diesem
Zeitpunkt. Ein Vergleich der Versionen wurde am 1. Januar eines jeden Jahres
durchgeführt.
Jahr
Anzahl der Änderungen
2003
8947
2004
2844
2005
3169
2006
3086
Abbildung : Jährliche Änderungen
Diese Tabelle zeigt jedoch nicht die gesamte Anzahl der Änderungen in diesem
Zeitraum. Ein Datensatz kann sich innerhalb eines Jahres unter Umständen
mehrfach ändern, diese Änderungen würden bei einem jährlichen Abgleich mit
den Daten nur als eine einzige gezählt werden. Da die täglichen Versionen aber
nur im Zeitraum der letzten 3 Monate erhältlich sind, ist eine genaue Bestimmung der gesamten Änderungen nicht möglich. Um dennoch das Vorhandensein
von Mehrfachänderungen der Datensätze zu belegen, wird folgender Vergleich
angestellt: Summiert man die Änderungen in oben genannter Tabelle (jährlicher
Abgleich) auf, so erhält man 18.046 Änderungen. Führt man im gleichen Zeitraum, aber im 3-monatlichen Abgleich, dieselbe Abfrage durch, so beträgt die
Anzahl der Änderungen 45.351. Dies zeigt, dass es zu einer erheblichen Mehrfachänderungen von Datensätzen kommt.
Um den genauen Verlauf der Änderungen zu verfolgen, muss also ein täglicher
Abgleich mit den Daten erfolgen. Folgendes Schaubild zeigt die Anzahl der Änderungen, die im September 2006 durchgeführt wurden.
36
Abbildung : Änderungen im September 2006
Es ist deutlich zu erkennen, dass das Änderungsverhalten der Tabelle term erheblichen Schwankungen unterliegen kann. Dieses Beispiel wurde extra ausgewählt, um zu zeigen, dass es wichtig ist einen täglichen Abgleich mit den Daten
der Gene Ontologie durchzuführen, um stets mit aktuellen Daten zu arbeiten.
Darüber hinaus zeigt dieses Beispiel jedoch auch, dass eine tägliche neue Version der Daten oftmals sinnlos in ein Datenbanksystem eingebunden wird, da an
vielen Tagen keine Änderungen auftreten.
4.2. Probleme bei fehlendem Versionsmanagement
Anhand der im letzten Abschnitt gesammelten Informationen über das Änderungsverhalten der Gene Ontology wird in diesem Abschnitt deutlich gemacht,
zu welchen Problemen bezüglich der Effizienz und des Informationsmangels es
bei fehlendem Versionsmanagement kommen kann. Im Wesentlichen gibt es
drei Hauptprobleme, die im weiteren Verlauf dieses Kapitel kurz skizziert werden sollen.
4.2.1 Ineffizienter Datenaustausch
Nutzt eine Datenbank kein Versionsmanagement, werden nur Versionen und
keine Updates der Datenbank angeboten. Das bedeutet, dass man einzelne Tabellen bzw. die komplette Datenbasis nur als Ganzes und nicht nur die tatsächlich geänderten Datensätze der Datenbank erhält. Falls sich die Daten jedoch
kaum bzw. nur sporadisch ändern, führt dies zu einem unnötigen Aufwand
37
bezüglich der Netzlast für Downloads der Datenbank und vor allem zu einer Flut
sinnloser Datenbankzugriffe. Das Problem wird durch ein kleines Beispiel aus
der Gene Ontology deutlich:
Über einen (statistisch relevanten) Zeitraum von einem Jahr will ein Benutzer
mit den Daten der Gene Ontology in einem eigenen Datenbanksystem arbeiten.
Er möchte stets mit den aktuellsten Daten arbeiten. Daher müssen täglich die
Daten via Internet bezogen werden und in das Datenbanksystem des Nutzers
eingebunden werden. Betrachtet man nun ausschließlich die Haupttabelle term,
so müssen täglich ca. 20.000 Datensätze zunächst gelöscht und dann wieder einfügt werden (also ca. 40.000 Datenbankänderungen pro Tag). Das entspricht im
Jahr ca. 15 Millionen Datensätzen, die verändert werden müssen. Dem gegenüber stehen allerdings nur ca.3.000 bis 8.000 tatsächlich veränderte Datensätze,
die im Falle eines vorhandenen Versionsmanagements hätten geändert werden
müssen, da mit dem Prinzip der Updates nur tatsächlich geänderte Datensätze
ausgetauscht werden.
Das bedeutet, dass über 99 Prozent der Daten sinnlos ausgetauscht wurden bzw.
weniger als ein Prozent der Änderungen notwendig waren. In diesem Zeitraum
wäre zusätzlich eine Netzlast durch Downloads der Datenbank von ca. 3 GB entstanden (für die komplette Datenbank jeweils ca. 9 Megabyte pro Tag), die ebenfalls deutlich und im ähnlichen Verhältnis hätte reduziert werden können. Zu
beachten ist ebenfalls, dass dieses Beispiel sich ausschließlich auf die Tabelle
term bezog. Wenn man diese Betrachtungen auf die komplette Datenbasis der
Gene Ontology erweitern würde, so wäre die Anzahl sinnloser Datenbankzugriffe deutlich höher.
Um also nicht immer die komplette Datenbasis (meist unnütz) auszutauschen
und damit enorme Kosten bezüglich Netzauslastung und Datenbankzugriffen zu
verursachen, sollte man die Änderungen an der Datenbasis so organisieren, dass
möglichst nur die geänderten Datensätze ausgetauscht werden und dem Benutzer
damit die Möglichkeit von Updates der Daten gegeben wird.
4.2.2 Mangelnde Informationen über Änderungen
Dem Benutzer der Daten der Gene Ontology stehen zwar sämtliche Daten zur
Verfügung, Informationen über den Verlauf der Änderungen in Art und Anzahl
werden jedoch gar nicht angeboten. So sind zum Beispiel sämtliche Informationen über Änderungen aus Kapitel 4.1 (Untersuchung des Änderungsverhaltens)
38
nicht aus der Gene Ontology entnommen, sondern wurden mit dem in dieser
Arbeit entwickelten System VerIS ermittelt. Der Benutzer muss also ohne jegliche Kenntnis über den zeitlichen Verlauf der Änderungen arbeiten.
Wie die Untersuchung des Änderungsverhalten gezeigt hat, wird die Datenbasis
nicht kontinuierlich geändert, sondern unterliegt Schwankungen im Änderungsverhalten, die bei Ontologien durchaus üblich sind. An dieser Stelle sei einmal
das Änderungsverhalten der Tabelle term im September 2006 veranschaulicht:
Abbildung : Anzahl der Änderungen im September 2006
An nur 8 Tagen werden die Daten der Tabelle term überhaupt geändert, und dabei ist meistens nur eine sehr geringe Anzahl von Datensätzen betroffen. An einem Tag (19.09.2006) jedoch werden 828 Änderungen vorgenommen, was sogar 25% der Änderungen entspricht, die im gesamten Jahr 2006 stattgefunden
haben.
Da dem Benutzer jedoch diese wichtigen Informationen fehlen, ist nach wie vor
ein täglicher Austausch der Datenbasis nötig, um mit den aktuellsten Daten zu
arbeiten. An zwei Dritteln der Tage ist dies allerdings nicht notwendig. Stünden
dem Anwender also diese und ähnliche Informationen zur Verfügung, könnte er
anhand dieser Informationen selbst entscheiden, wann und ob ein Abgleich mit
der Datenbasis im Internet notwendig ist.
Darüber hinaus sind keine Informationen über die Art der Änderungen verfügbar. Diese wichtigen Angaben sind aber für Informationen über Verlauf und
Entwicklung der Gene Ontology entscheidend.
• Wie viel Datensätze haben sich geändert?
• Welche Arten von Änderungen (Einfügungen, Löschungen, Modifikationen) gab es? Wie viele waren es?
39
• Wurde ein Datensatz mehrmals modifiziert?
• Welches Argument des Datensatzes wurde modifiziert?
Diese und andere Fragen können ohne ein klares Konzept für das Änderungsverhalten nicht beantwortet werden.
4.2.3 Mangelnder Zugriff auf alte Versionen
In manchen Fällen ist es wünschenswert, mit verschiedenen Versionen der Daten
zu arbeiten, um Unterschiede in deren Verhaltensweisen zu ergründen. Diese
unterschiedlichen Versionen der Tabellen muss man ohne Versionsmanagement
stets im Datenbanksystem als materialisierte Tabellen halten. Es ist sehr schwer.
bei der „Flut“ von Versionen den Überblick zu behalten.
Außerdem sind nicht alle täglichen Versionen von Daten der Gene Ontology im
Internet verfügbar. Je weiter das Datum der gewünschten Version zurückliegt,
desto weniger Releases werden angeboten, so können etwa Versionen, die bereits mehr als 6 Monate zurückliegen, nur noch in monatlichen Releases bezogen
werden.
Mit Hilfe eines Versionsmanagements und dadurch einer Speicherung der Änderungsdaten ließen sich alte Datenbestände durch Abfragen und Views rekonstruieren, so dass eine physische, materialisierte Vorhaltung aller Versionen
nicht mehr notwendig wäre. Mit der aktuellen Version der Daten und der
Änderungsspeicherung wäre man in der Lage, eine Version zu einem gewünschten Zeitpunkt wiederherzustellen.
Für das Jahr 2006 etwa benötigt man, um alle täglichen Versionen der Tabelle
term zu rekonstruieren, lediglich einen Datenstamm von 20.000 Datensätzen
sowie eine oder mehrere Tabellen, in denen die Datenänderungen des Jahres
2006 (für das gesamte Jahr ca. 3.000), enthalten sind. Dem gegenüber stehen –
ohne Versionsmanagement – 365 Tabellen mit 20.000 Einträgen.
4.3. Konzept eines effizienten Versionsmanagements
Wie im letzten Abschnitt beschrieben wurde, treten massive Probleme bei fehlendem Versionsmanagement großer Datenbanken auf. Eine durchdachte Organisation der verschiedenen Versionen der Daten sowie ein effizienter Umgang
40
mit den Änderungen dieser Daten sind also für eine große, viel frequentierte und
sich schnell verändernde Datenbank wie der Gene Ontology unablässig.
Im Folgenden wird daher ein Konzept vorgestellt, mit dem man den Verlauf der
Änderungen auf den Daten effizient gewinnen und speichern kann (Kapitel
4.3.1), Informationen über diese Änderungen erhält (Kapitel 4.3.3) und beliebige
Zustände der Datenbank rekonstruieren kann (Kapitel 4.3.2). Ziel ist es, in einem
Datenbankmanagementsystem (DBMS) jeweils nur einen Datenstamm sowie die
Änderungen, die auf diesen Daten durchgeführt wurden, vorzuhalten. Mit diesen
Daten ist es dann möglich, Zustände der Datenbank zu rekonstruieren und weitreichende Informationen über Art, Verlauf und Auswirkungen der Änderungen
zu erhalten.
In diesem Abschnitt sollen vor allem die Vor- und Nachteile möglicher technischer Realisierungen diskutiert werden. Mit Hilfe dieser Ergebnisse wird im Kapitel 5 eine adäquate Umsetzung des Konzepts erläutert.
4.3.1 Historisierung
Unter der Historisierung von Daten versteht man die Speicherung des Verlaufs
der Änderungen, die auf den Daten durchgeführt wurden. Dies sollte in einer
möglichst effizienten und praktikablen Form geschehen. Es handelt sich dabei
um eine Differenzspeicherung, also den Vergleich zweier Versionen einer Tabelle, um die Änderungen, die zwischen diesen beiden Versionen entstanden sind,
herauszufiltern und abzuspeichern. In den Naturwissenschaften und der Mengentheorie wird für die Differenz häufig der griechische Buchstabe Delta (∆) benutzt. Daher werden diese Änderungsdaten meist als Deltas oder Delta-Daten
bezeichnet. Zunächst befasst sich dieses Kapitel mit der Gewinnung der Änderungs- bzw. Deltadaten. Danach wird auf die Speicherung dieser Daten eingegangen.
4.3.1.1 Gewinnung der Deltadaten
Änderungen zwischen zwei Versionen von Daten sind in drei Änderungstypen
aufgeteilt. In Klammern stehen die Datenbankbezeichnung und die wissenschaftliche Notation für die jeweiligen Änderungstypen :
41
Hinzugefügte Datensätze (PLUS, ∆+): Datensätze, die in der neuen Version vorhanden sind, nicht jedoch in der alten Version.
Gelöschte Datensätze (MINUS, ∆-): Datensätze, die in der alten Version vorhanden sind, allerdings nicht mehr in der neuen Version.
Geänderte Datensätze (PLUSMINUS, ∆+/-): Datensätze, die in beiden Versionen
vorhanden sind, bei denen sich aber mindestens Argument geändert hat.
Um die Änderungstypen kurz zu verdeutlichen, sei folgendes Beispiel gegeben.
Es handelt sich um zwei Versionen der Tabelle T. Told ist die alte Version der
Daten, Tnew bezeichnet die neue Version der Daten. Das Schlüsselargument ist
ID, die anderen Attribute sind Name und Ort.
Tabelle Told
ID
1
2
3
4
8
Name
Müller
Schmidt
Meyer
Weber
Holtmann
Tabelle Tnew
ID
1
2
4
5
8
Ort
Bonn
Bonn
Köln
Münster
Essen
Name
Müller
Schmidt
Weber
Schuster
Kemper
Ort
Bonn
Köln
Münster
Dortmund
Essen
PLUS : Datensatz mit der ID 5
MINUS : Datensatz mit der ID 3
PLUSMINUS : Datensätze mit den IDs 2 und 8
Die gesamten Delta-Daten (oder Deltas) zweier Versionen einer Tabelle T lassen
sich als Vereinigung aus den Deltas der drei Änderungstypen, bestehend aus
hinzugefügten Daten, gelöschten Daten und modifizierten Daten, darstellen :
∆ (T) = ∆+ (T)
U
∆- (T)
U ∆+/- (T)
Wichtig für die Gewinnung der Deltadaten ist, dass die betreffenden Tabellen
einen Primärschlüssel besitzen. Dieser Primärschlüssel muss den Datensatz nicht
nur bezüglich einer Version der Tabelle eindeutig identifizieren, sondern darf
auch beim „Übergang“ zwischen den beiden Versionen nicht geändert werden.
Ansonsten kommt es zu Phantomänderungen, die im Abschnitt 4.4 beschrieben
werden. Die Existenz eines Primärschlüssels ist Voraussetzung für die Gewinnung der Deltadaten, da dieser für alle Änderungstypen als Vergleichsargument
42
zu Rate gezogen wird. Existiert ein solcher Primärschlüssel nicht, ist eine Deltaerstellung unmöglich, da nicht festzustellen ist, ob sich ein Datensatz geändert
hat oder hinzugefügt wurde, da eine eindeutige Identifikation eines Datensatzes
nicht möglich ist. Ein Vergleich zweier Tabellen ist somit nicht durchführbar.
Um einen Primärschlüssel formal zu definieren, müssen weitreichende Definitionen (z.B. funktionelle Abhängigkeit) und Erklärungen geliefert werden. An
dieser Stelle sei also eine eher praktische Definition gegeben, die an die formale
Definition aus [KEM97] angelehnt ist:
Die Menge von Attributen primk ist Primärschlüssel, wenn
1. jede Zeile der Tabelle durch primk eindeutig identifiziert werden kann
und
2. die Menge der Attribute von primk nicht mehr verkleinert werden kann,
ohne dass Eigenschaft 1 verletzt wird.
Die Deltas der hinzugefügten und gelöschten Daten ∆+ und ∆- sind diejenigen
Datensätze, die in einer Version der Tabelle vorhanden sind, nicht jedoch in der
anderen. Sie lassen sich also mengentheoretisch als Differenz der beiden Versionen der Tabellen beschreiben. Tnew beschreibt dabei die neue Version der Tabelle T, und Told die alte Version:
∆+ (T) = Tnew - Told
bzw.
∆- (T) = Told – Tnew
Um diesen Ausdruck in der Datenbanksprache SQL auszudrücken und damit
innerhalb einer Datenbank zu verwenden, benötigt man den SQL-Operator
MINUS. Der MINUS-Operator wird allerdings durch den von MS Access verwendeten Jet-SQL-Dialekt nicht unterstützt. Daher werden obige Ausdrücke in
den folgenden äquivalenten Ausdruck transferiert.
„Nimm alle Elemente (Datensätze) aus Tnew, für die es kein Element (Datensatz)
in Told gibt, bei dem der Primärschlüssel gleich dem Primärschlüssel aus dem
Element aus Tnew ist“ (für ∆+ (T), äquivalent wird der Ausdruck für ∆- gebildet)
43
formal:
∆+ (T) = {x | x ∈ Tnew : ¬ (∃ y ∈ Told : primk(x) = primk(y))}
bzw.
∆- (T) = {x | x ∈ Told : ¬ (∃ y ∈ Tnew : primk(x) = primk(y))}
Diese beiden mathematischen Ausdrücke lassen sich nun auch in JET-SQL ausdrücken und daher im Datenbanksystem MS Access verwenden (ID ist dabei der
Primärschlüssel) :
DELTA PLUS
DELTA MINUS
SELECT *
FROM Tnew
WHERE Tnew.ID NOT IN (
SELECT ID
FROM Told)
SELECT *
FROM Told
WHERE Told.ID NOT IN (
SELECT ID
FROM Tnew)
Nachdem formale Definitionen und SQL-Befehle, die Änderungen für hinzugefügte und gelöschte Datensätze abfragen, gefunden wurden, müssen nun die Änderungsabfragen für modifizierte Datensätze erarbeitet werden.
Bei modifizierten Datensätzen (PLUSMINUS, ∆+/-) handelt es sich um Datensätze, bei denen sich mindestens ein Nicht-Schlüsselargument geändert hat. Als
Vergleichsargument wird auch hier wieder der Primärschlüssel der Tabellen genutzt. Modifiziert sind also diejenigen Datensätze aus Tnew, für die es ein Element in Told gibt, welches denselben Primärschlüssel besitzt, aber nicht gleich
dem Element aus Tnew ist (demnach muss also mindestens ein NichtSchlüsselargument unterschiedlich sein):
∆+- (T) = {x | x ∈ Tnew : ∃
y ∈ Told
∧ primk(x) = primk(y)
∧ x ≠ y}
44
Um die PLUSMINUS-Änderungen des Vergleichs in SQL darzustellen, müssen
die Tabellen über das Schlüsselargument gejoint werden und ein Vergleich (mit
„<>“ als Vergleichsoperator) aller restlichen Argumente (durch OR getrennt)
durchgeführt werden. Der SQL-Code für die Tabellen Tnew und Told mit den Primärschlüsseln ID und Nicht-Schlüsselargumenten Arg1 bis Argn sieht wie folgt
aus :
SELECT *
FROM Tnew INNER JOIN Told
ON Tnew. ID = Told. ID
WHERE
(Tnew.Arg1 <> Told.Arg1) OR
(Tnew.Arg2 <> Told. Arg2) OR
...
new
(T .Argn <> Told. Argn)
Wie bereits oben erwähnt wurde, bestehen die gesamten Deltadaten aus einer
Vereinigung der Deltas der einzelnen Änderungstypen. Ein solcher Vereinigungsoperator wird in SQL mit UNION dargestellt. Je nachdem wie die Speicherung der Delta-Daten organisiert ist, wird eine solche Union-Anweisung
entweder im Rahmen der Speicherung der Deltas verwendet, oder sie kommt bei
der Gewinnung von Informationen über die Änderung bzw. Rekonstruktion alter
Versionen zum Einsatz.
4.3.1.2 Speicherung der Deltadaten
Nachdem die SQL-Abfragen für die drei Änderungstypen herausgearbeitet wurden, muss nun über die Speicherung der aus den Abfragen gewonnenen Daten
nachgedacht werden.
Die Ergebnisse der Abfragen zur Deltagewinnung werden in sogenannten DeltaTabellen gespeichert, in denen nur die Änderungen abgelegt werden. Mit den
Daten der Deltatabelle werden später Informationen über das Änderungsverhalten der Tabelle ermittelt und alte Datenstände (zusammen mit einem Datenstamm, z.B. der aktuellen Tabelle) rekonstruiert. Dies sollte man bereits bei einem Konzept für die Speicherung der Deltadaten im Hinterkopf haben, um die
Deltadaten möglichst effizient bezüglich späterer Abfragen zu speichern.
45
Es gibt verschiedene Möglichkeiten für die Konzeption dieser Delta-Tabellen.
Im Folgenden werden drei Möglichkeiten der Speicherung der Änderungsdaten
kurz skizziert und auf Effizienz und Tauglichkeit hin überprüft. Um den Aufbau
der Delta-Tabellen zu verdeutlichen wird Bezug auf das Beispiel aus 4.3.1.1 genommen und die möglichen Umsetzungen der Delta-Tabellen für dieses Beispiel
werden veranschaulicht. Als Vergleichsdatum bzw. dem Datum der neueren
Version sei der 15.09.2006 angenommen.
1.Delta-Plus, Delta-Minus und Delta-Plusminus-Argument :
Bei dieser Organisationsform der Delta-Tabellen gibt es eine Tabelle Delta-Plus
und eine Tabelle Delta-Minus zur Aufnahme der eingefügten und der gelöschten
Datensätze sowie für jedes Nicht-Schlüssel-Attribut eine Delta-PlusminusTabelle, in der Änderungen auf der Ebene des entsprechenden Attributs gespeichert werden.
Die Tabellen Delta-Plus und Delta-Minus, in denen die Änderungstypen PLUS
und MINUS, also Informationen über die neu eingefügten und die gelöschten
Datensätze, gespeichert werden sollen, unterscheiden sich in Art und Beschaffenheit von der ursprünglichen Tabelle nur durch ein eingefügtes Datumsfeld,
welches den Zeitpunkt des aktuellen Vergleichs mitschreibt und mit dem ursprünglichen Schlüssel zusammen den Schlüssel dieser Delta-Tabellen bildet.
Dies ist notwendig, da ein Datensatz gelöscht und zu einem späteren Zeitpunkt
wieder eingefügt werden kann. Der Primärschlüssel der Tabelle, die verglichen
wird, verliert dadurch seine Eindeutigkeit. Zusammen mit dem Zeitstempel (Datum) ist jedoch wieder eine eindeutige Identifizierung des Datensatzes möglich,
da sich ein Datensatz innerhalb eines Vergleich nur höchstens einmal ändern
kann.
Delta-PLUS_T
ID
5
Datum
15.09.2006
Name
Schuster
Ort
Dortmund
Delta-MINUS_T
ID
3
Datum
15.09.2006
Name
Meyer
Ort
Köln
46
Da sich im Gegensatz zu den bisher betrachteten Änderungstypen PLUS und
MINUS bei dem Änderungstyp PLUSMINUS die Argumente ändern, müssen
die beiden Werte (der alte und der neue Wert des Arguments) in irgendeiner
Form in der Datenbank gespeichert werden. Man kann dies durch die Zusätze
„_old“ und „_new“ hinter den Spaltennamen kenntlich machen.
Für jedes (Nicht-Schlüssel-)Argument wird eine eigene Tabelle mit der Endung
des Argumentnamens erstellt. Diese Delta-Plusminus-Tabellen beinhalten nur
den Schlüssel, das Datum, sowie die beiden Werte des jeweiligen Arguments.
Für obiges Beispiel ergeben sich also neben den Tabellen Delta-PLUS_T und
Delta-MINUS_T zwei weitere PLUSMINUS-Tabellen, da es in T zwei NichtSchlüssel gibt.
Delta-PLUSMINUS-Name_T
ID
8
Datum
15.09.2006
Name_old
Holtmann
Name_new
Kemper
Delta-PLUSMINUS-Ort_T
ID
2
Datum
15.09.2006
Ort_old
Bonn
Ort_new
Köln
Fazit: Dies ist die platzsparendste der drei Möglichkeiten, da sie die Speicherungen der Änderungen auf ein Minimum reduziert und keine redundanten Daten
speichert. Diese Art der Speicherung ist aber im Allgemeinen nicht praktikabel,
da Tabellen großer Datenbanken unter Umständen eine sehr große Anzahl an
Spalten besitzen. Für eine Tabelle mit einer Anzahl von 10 (Nicht-Schlüssel)Argumenten, die durchaus nicht selten sind, sondern eher an der unteren Grenze
für große Datenbanken liegen, würden allein 12 Delta-Tabellen entstehen. Diese
Menge an Tabellen ist aber für eine Informationsgewinnung und Rekonstruktion
alter Daten-Versionen nicht effizient, da unzählige UNION-Abfragen nötig sind.
Außerdem wären viele dieser PLUSMINUS-Tabellen leer, da viele Argumente
vorstellbar sind, die sich selten oder nie ändern.
47
2.Delta-Plus, Delta-Minus, Delta-Plusminus :
Hierbei entstehen pro ursprünglicher Tabelle drei Delta-Tabellen, die jeweils für
eine Art von Änderung zuständig sind. Die Tabellen Delta-Plus und Delta-Minus
werden wie in der ersten Möglichkeit beschrieben gebildet.
In der Tabelle Delta-Plusminus kommt es zu einer Verdoppelung der NichtSchlüssel-Argumente. Jedes dieser Argumente wird mit dem Zusatz „_old“ und
„_new“ versehen. In ihnen werden die Werte aus den beiden Versionen der ursprünglichen Tabelle abgelegt. Außerdem wird auch hier ein Datumsfeld des
Vergleichs eingefügt, das zusammen mit dem Schlüssel der ursprünglichen Tabelle den Schlüssel der Delta-Tabelle bildet. Für obiges Beispiel würden sich
also folgende Delta-Tabellen ergeben.
Delta-PLUSMINUS_T
ID
2
8
Datum
15.09.2006
15.09.2006
Name_old
Schmidt
Holtmann
Name_new
Schmidt
Kemper
Ort_old
Bonn
Essen
Ort_new
Köln
Essen
Fazit: Die Anzahl der entstehenden Delta-Tabellen pro verglichener Tabelle ist
konstant (3) und eignet sich daher (im Gegensatz zu Möglichkeit 1) prinzipiell
für die Informationsgewinnung und die Rekonstruktion. Natürlich werden bei
dieser Möglichkeit einige redundante Werte gespeichert (die Argumente, die
sich nicht verändert haben), aber diese Redundanzen lassen sich nur durch eine
Vielzahl von Delta-Tabellen umgehen (Möglichkeit 1).
3.Eine Delta-Tabelle mit Typbezeichnung :
In dieser Umsetzung wird pro Tabelle nur eine Delta-Tabelle angelegt. Sie beinhaltet Schlüssel, Datum sowie die durch „_old“ und „_new“ verdoppelten Argumente. Um kenntlich zu machen, um welchen Änderungstyp es sich handelt,
wird das Feld „Deltatyp“ eingefügt, welches die Werte „P“, „M“ und „PM“
(Abkürzungen der Änderungstypen) haben kann. Es handelt sich also um eine
Zusammenlegung der drei Tabellen aus Möglichkeit 2. Im Falle des Beispiels
entsteht also die Delta-Tabelle:
48
Delta_T
ID
Datum
Name_old
Name_new
Ort_old
Ort_new
Deltatyp
2
3
5
8
15.09.2006
15.09.2006
15.09.2006
15.09.2006
Schmidt
Meyer
Schuster
Holtmann
Schmidt
Meyer
Schuster
Kemper
Bonn
Köln
Dortmund
Essen
Köln
Köln
Dortmund
Essen
PM
P
M
PM
Fazit: In dieser Möglichkeit existiert nur eine Delta-Tabelle pro ursprünglicher
Tabelle. Sie enthält viele redundante Werte, da selbst für Einfügungen und Löschungen neue und alte Werte für die Argumente gespeichert werden, die sich
jedoch bei diesen beiden Änderungstypen überhaupt nicht verändern.
Die letztgenannten Möglichkeiten eignen sich beide zur Speicherung der Deltadaten. Auf den ersten Blick scheint die Möglichkeit mit drei Delta-Tabellen
sinnvoller, weil mit ihr weniger redundante Daten bzw. Nullwerte gespeichert
werden (man könnte auch Nullwerte statt der doppelten Einträge speichern). Der
Umgang mit der späteren Rekonstruktion und vor allem mit der Gewinnung von
Informationen aus den Deltadaten wird in der Regel jedoch sehr komplizierter.
So ist man häufig an der Zahl der Änderungen unabhängig vom Änderungstyp
interessiert. Mit drei Delta-Tabellen muss man dann jedoch stets UNIONAbfragen kreieren, statt einfacher Abfragen. Die Tabellen werden meist über
das Datum abgefragt. Dieser Index (da Schlüssel) wird für jede Tabelle einzeln
vom DBMS verwaltet und kann bei einer Tabelle schneller zugegriffen werden.
Außerdem vergrößert sich natürlich der Aufwand in der Handhabung bei mehreren Tabellen sowie für den Entwickler als auch für das DBMS.
Ich habe mich bei der Entwicklung des Systems VerIS für die Möglichkeit entschieden, alle Änderungen, die auf einer Tabelle wirksam werden in eine einzelne Delta-Tabelle zu schreiben. Daher beziehen sich die folgenden Abschnitte
über die Rekonstruktion und die Analyse der Deltadaten auch für diese Möglichkeit der Speicherung. Die Rekonstruktion und Analyse sind aber durch leichte Modifikationen prinzipiell auch mit Möglichkeit 2 durchführbar.
49
4.3.2 Rekonstruktion
Speichert eine Datenbank die Änderungen, die auf den Tabellen vollzogen wurden, z.B. mittels der Methoden, die im letzten Abschnitt erläutert wurden, so ist
es nicht mehr notwendig, eine Vielzahl von Versionen der Daten vorrätig zu halten. Aus den Deltadaten und einem Datenstamm lassen sich nämlich beliebige
alte (oder neue) Versionen der Daten erzeugen. Zunächst sei zwischen Vorwärtsund Rückwärtsrekonstruktion unterschieden:
• Vorwärtsrekonstruktion: Die Datenbank speichert den „ersten“ bzw. den
ältesten Datenbestand sowie die Änderungsdaten und erzeugt dadurch
Versionen. Diese Rekonstruktionsart geht also von der Vergangenheit
zeitlich gesehen „nach vorne“.
• Rückwärtsrekonstruktion: Die Datenbank hält den jeweils aktuellsten Datenbestand vor und die Änderungsdaten. So lassen sich vom aktuellen
Stand alte Versionen der Datensätze (zeitlich gesehen „rückwärts“) erzeugen.
Im Allgemeinen ist ein Benutzer einer Datenbank vorwiegend an den aktuellsten
Daten interessiert. Da diese Daten im Falle der Vorwärtsrekonstruktion jedoch
nicht materialisiert vorliegen, muss dieser Datenbestand vor jedem Gebrauch
rekonstruiert werden. Das ist natürlich wenig effizient und auch nicht praktikabel. In der Praxis kommen solche Vorwärtsrekonstruktionen daher praktisch
nicht vor. Für das Prinzip der Rekonstruktion spielt diese Unterscheidung der
Rekonstruktionen jedoch keine Rolle. Ich werde mich im Weiteren also auf die
Rückwärtsrekonstruktion beschränken.
Gegeben seien also die Tabelle T mit den aktuellen Daten sowie die DeltaTabelle Delta_T mit den Änderungen, die auf der Tabelle T - mit Zeitstempel
versehen - durchgeführt wurden.
Will man nun die Version der Daten des gewünschten Datums D erhalten, so
müssen alle Änderungen, die vom jetzigen Zeitpunkt bis zum Datum D durchgeführt wurden, in der umgekehrten Reihenfolge der Änderungen, also von „jetzt“
an rückwärts, rückgängig gemacht werden, d.h.
• Einfügungen werden aus der aktuellen Tabelle gelöscht,
• Löschungen werden in die aktuelle Tabelle eingefügt und
• Änderungen werden rückgängig gemacht, indem die Attribute durch die
alten Attributwerte („_old“) ersetzt werden.
50
Wichtig dabei ist, dass man unbedingt die zeitliche Reihenfolge der Änderungen
beachtet, da Datensätze mehrfach geändert werden können und der zeitliche
Verlauf der Änderungen beachtet werden muss. So sollten die Daten der Deltatabelle nach Datum sortiert bzw. gruppiert sein.
Die technische Umsetzung dieses Prinzips kann z.B. erreicht werden, indem die
Deltatabelle nach Datum sortiert wird (Datum größer des gewünschten Datums)
und mittels eines Recordsets mit einer Schleife durchlaufen wird. Je nach Änderungstyp wird dann die dazu korrespondierende Datenbankaktion (INSERT,
DELETE, UPDATE) ausgeführt. Ein kurzes Beispiel soll dieses Prinzip deutlich
machen:
ID
12
12
12
12
Datum
12.12.06
15.11.06
06.09.06
03.06.06
Name_old
Holtmann
Meyer
Müller
Müller
Name_new
Holtmann
Holtmann
Meyer
Müller
Deltatyp
M
PM
PM
P
Der Datensatz mit der ID 12 wurde eingefügt, daraufhin zweimal geändert und
schließlich gelöscht. Möchte man nun eine Version der Daten vom 01.07.06 erhalten, muss man also diesen Datensatz der aktuellen Tabelle hinzufügen, danach das Attribut Name von „Holtmann“ auf „Meyer“ ändern und danach das
Attribut Name von „Meyer“ auf „Müller“ ändern. Der letzte Eintrag wird nicht
beachtet, da das Datum vor dem gewünschten Datum der Version der Daten
liegt.
Dieser „naive Rollback“ der Daten lässt sich jedoch stark verbessern. Es ist nämlich überhaupt nicht nötig, die Änderungen eines Datensatzes auf Attribut-Ebene
(Deltatyp ‚PM’) über den kompletten Zeitraum (von “Jetzt“ bis zu dem gewünschten Datum) zurückzuverfolgen. Lediglich die früheste Änderung ist für
die Rekonstruktion interessant, also die Änderung, die zeitlich gesehen dem gewünschten Datum am nächsten liegt. Änderungen, die danach ausgeführt wurden, sind für die Rekonstruktion dieser einen Version nicht von Bedeutung.
Mit diesem Wissen kann nun eine Abfrage erstellt werden, die für jede ID aus
der Delta-Tabelle jeweils nur den Eintrag einer Argument-Änderung aus der
Delta_Tabelle liefert mit dem dem gewünschten Datum am nächst gelegenen
51
Datum. Mit einer solchen Projektion der Deltatabelle muss nun für jeden Änderungstyp nur ein SQL-Statement (INSERT, DELETE, UPDATE) abgesetzt werden, und nicht wie im Falle des naiven Rollbacks für jeden Eintrag in der Deltatabelle. Im obigen Beispiel muss also nur noch ein Updatebefehl ausgeführt
werden, um das Argument Name zu modifizieren.
Auf eine genaue technische Umsetzung der Rekonstruktionen geht das Kapitel
5.5 ein. Ein Access-spezifisches Problem der Rekonstruktion wird in Kapitel 6.3
beschrieben.
4.3.3 Analyse der Deltadaten
Durch die Speicherung des Änderungsverlaufs in Delta-Tabellen lassen sich
wertvolle Informationen über die Art, den Verlauf und die Bedeutung der Änderungen gewinnen. Im Verlauf dieser Arbeit wurde des Öfteren auf den Mangel
an Informationen über Änderungen geschrieben. Nun können verschiedenste
Fragen mit Hilfe einfacher SQL-Befehle beantwortet werden, wie zum Beispiel:
• Wie viele Datensätze haben sich innerhalb eines bestimmten Zeitraums
geändert?
• An welchem Datum haben die häufigsten Änderungen stattgefunden?
• Wie war der zeitliche Verlauf der Änderungen (in MS Access durch eingebaute Diagrammfunktion sehr einfach zu realisieren)?
• Welche Datensätze wurden modifiziert?
• Welche Attribute wurden modifiziert?
• usw.
Die Antworten auf diese Fragen liefern einfache SQL-Abfragen, sind sehr
schnell umzusetzen sind.
4.4. Das „Schlüsselproblem“
Bei der technischen Umsetzung der Konzepte für ein Versionsmanagement und
bei ersten Versuchen die Änderungen der Tabelle term der Gene Ontology zu
ermitteln, wurde eine ungewöhnlich hohe Anzahl von Änderungen festgestellt.
So änderten sich bereits zwischen zwei aufeinanderfolgenden Tagen ca. 18.000
Datensätze (bei existierenden 20.000 Datensätzen). Nach genauer Analyse der
Datensätze, die geändert wurden, wurde festgestellt, dass sich bei nahezu allen
52
Datensätzen lediglich der Schlüssel geändert hat, alle anderen Argumente aber
gleichgeblieben sind. Folgendes Beispiel der Tabelle term soll dies klarmachen:
Auszug aus term vom 18.09.2006
Auszug aus term vom 19.09.2006
Die Datensätze der alten Version von term mit den IDs 1194 bis 1198 sind (bis
auf den Primärschlüssel ID) genau identisch mit den Datensätzen der neuen Version der IDs 1920 bis 1924. Diese Daten haben sich also semantisch nicht verändert. Aus Datenbanksicht handelt es sich aber dennoch um zwei komplett unterschiedliche Datensätze. Daher wurde diese Menge an „Phantomänderungen“
bei der Differenzspeicherung ausgegeben. Es wird angenommen, dass die Gene
Ontology intern mit anderen Schlüsselargumenten arbeitet und bei der
Bereitstellung der Daten im Internet diese nicht verwendet, sondern den automatisch generierten Schlüssel „id“ hinzufügt.
In der Informatik wird der Primärschlüssel als ein oder mehrere Argumente definiert, die einen Datensatz eindeutig identifizieren. Er kann zwar geändert werden, semantisch meint dies jedoch, dass es sich dann um einen anderen Datensatz handelt. Das Prinzip der Primärschlüssel wurde von der Gene Ontology
(zumindest bezüglich der bereitgestellten Daten) nicht richtig umgesetzt.
Der Schlüssel identifiziert zwar einen Datensatz bezüglich einer Version von
Daten eindeutig, verliert aber seine Schlüsseleigenschaft beim Arbeiten mit
mehreren Versionen. Um eine (sinnvolle) Differenzspeicherung durchzuführen,
wird jedoch unbedingt ein den Datensatz eindeutig identifizierendes Argument
53
zum Vergleich benötigt. Eine Kombination aus mehreren Argumenten, die die
Schlüsseleigenschaft besitzen ist ebenfalls zum Vergleich zweier Versionen von
Tabellen möglich.
Ist ein solcher angenommener Schlüssel gefunden, wird dieser als Vergleichsargument für die Differenzspeicherung verwendet. Vor jeder Durchführung der
Differenzspeicherung muss aber zunächst ein Test erfolgen, ob der angenommene Schlüssel nach wie vor die Schlüsseleigenschaft besitzt, da diese Integritätsbedingung nicht vom DBMS übernommen wird, weil es sich technisch gesehen
nicht um einen Schlüssel handelt.
Es ist sinnvoll statt über den angenommenen Schlüssel selbst, über einen künstlichen Schlüssel zu vergleichen, wenn es sich bei dem angenommenen Schlüssel
um kein Zahlenfeld handelt oder er sich um mehrere Argumente zusammensetzt.
Ein Vergleich wird dadurch effizienter. Eine technische Umsetzung dieses Prinzips der Differenzspeicherung ohne Schlüsselargument findet sich in Kapitel 6.2.
54
5. Das System VerIS
Das Informationssystem VerIS (VersionsInformationsSystem) ist eine in MSAccess entwickelte Anwendung zur Steuerung und Auswertung von Versionen
von Daten. Es soll zeigen, wie ein Versionsmanagement für große Datenbanken
realisiert werden kann und dient als Beispiel für die Implementation der in der
Arbeit entwickelten Konzepte über Historisierung von Daten-Versionen und Rekonstruktion alter Daten.
Die Daten der Gene Ontology dienen als Grundlage für dieses System. Die Gene
Ontology selbst verfügt über kein Versionsmanagement und stellt genannte Daten, die in verschiedenen Formaten vorliegen, in sehr schnellen Releases im Internet bereit. Versionen dieser Daten können nur in ihrer Gesamtheit bezogen
werden. Zunächst ist die Anwendung VerIS also auf die Gene Ontology-Daten
beschränkt. Die entwickelten Methoden und Vorgehensweisen des Systems lassen sich allerdings schnell auf andere Datenbanken erweitern.
VerIS verfügt über einen automatisierten Import der Rohdaten der Gene Ontology, eine effiziente Speicherung der Historie der Änderungen der Daten und einen
Rekonstruktionsmechanismus, um alte Versionen der Daten wiederherzustellen.
Das bedeutet, dass lediglich die aktuellen Daten sowie eine Tabelle mit Änderungen dauerhaft in der Datenbank gespeichert werden müssen, was im Umgang
mit einer Fülle von Versionen zu einer enormen Platzersparnis führt. Darüber
hinaus ist eine Analyse der Historiendaten möglich.
Exemplarisch werden in VerIS die Daten der Tabelle „term“ der Gene Ontology
verwendet. VerIS kann also nicht als Versionsmanagementsystem für die gesamten Daten der Gene Ontology verwendet werden. Anhand der Tabelle „term“
können aber alle Methoden für ein Versionsmanagement gut erklärt und veranschaulicht werden. Diese Tabelle ist die Haupttabelle der Gene Ontology und
unterliegt einer hinreichend großen Menge an Änderungen mit hohem
55
exemplarischem Wert. Darüber hinaus enthält sie eine ausreichende Anzahl von
Datensätzen (ca. 20.000), um Performanzprobleme zu erkennen und zu lösen.
Außerdem tritt in dieser Tabelle das „Schlüsselproblem“ (siehe Kapitel 4.4) auf,
welches auch erst während der Entwicklung von VerIS deutlich und letztlich
gelöst wurde.
5.1. Architektur und Funktionalität
Das System VerIS ist in verschiedene Module (oder manager) aufgeteilt. Diese
Module sind alle durch VBA-Code und mit SQL-Abfragen realisiert und wurden
in MS Access entwickelt. Sie werden in den nächsten Abschnitten genauer erklärt:
• Importmanager: dient zum Einlesen der Daten der Gene Ontology aus
dem Internet in das System VerIS,
• Historymanager: speichert die Änderungen der Daten,
• Keymanager: integriert neue künstliche Schlüssel, die zur Differenzspeicherung benötigt werden,
• Versionmanager: rekonstruiert alte Versionen der Daten,
• Querymanager: ermöglicht Informationsgewinnung aus den Änderungsdaten.
Der Aufbau des Systems VerIS und das Zusammenspiel der einzelnen Module
untereinander mit der Datenbank und dem Benutzer werden an folgendem
Schaubild verdeutlicht:
56
Abbildung : Das System VerIS
Zunächst werden die Daten der Gene Ontology, die vom Benutzer aus dem Internet bezogen wurden, in die Datenbank geschrieben. Dies geschieht im Importmanager (Kapitel 5.2). Aufgrund irreführender Schlüsselbezeichnungen der
Rohdaten müssen künstliche Schlüssel eingeführt werden. Dazu wird der Keymanager (Kapitel 5.3) verwendet. Dieses Modul arbeitet eng mit dem Modul zur
Historienführung (Historymanager, Kapitel 5.4) zusammen, welches für die
Speicherung der Änderungen, die auf den Daten vorgenommen wurden, verwendet wird. Um vorherige Versionen der Daten zu erlangen, rekonstruiert der
Versionmanager (Kapitel 5.5) aus dem aktuellen Datenbestand und der Historientabelle alte Datenstände. Für die Analyse der Historiendaten sowie zur Gewinnung relevanter Informationen aus diesen Daten wird der Querymanager
(Kapitel 5.6) verwendet.
57
Der Anwender interagiert über drei Formulare mit dem System:
Zunächst das Importformular, welches den Importmanager und Historymanager,
der den Keymanager benutzt, zusammenfasst. Der Import und die Erstellung der
Historie läuft nach Angabe der Datenquelle (Ordner, in dem die von der Webseite der Gene Ontology heruntergeladene Text-Datei „term.txt“ liegt) und des Datums der Datei automatisch ab. Ein weiterer Eingriff seitens des Anwenders ist
nicht nötig. Der Fortschritt des Imports und der Historisierung wird über ein Statusfeld angegeben.
Abbildung : Importformular
Der zweite Bereich für den Nutzer ist das Rekonstruktionsformular, welches mit
Hilfe des Versionmanagers alte Versionen der Datenbank wiederherstellt. Möchte man nun einen alten Stand der Datenbank rekonstruieren, ist nur das Datum
der gewünschten Version und eine Tabellenbezeichnung nötig.
Das Queryformular dient zur Analyse der Historiendaten und soll die Einsatzmöglichkeiten der interaktiven Abfragen und Darstellungsformen der Informationen exemplarisch zeigen.
58
5.2. Importmanager
Die Daten der Gene Ontology sind in den Formaten mySQL und GO RDF-XML
verfügbar. Für einen Transfer in eine Access-Datenbank ist das mySQL-Format
am geeignetsten und wird daher verwendet. Um die Tabellenschemata (Schlüssel, Indizes, Datentypen) genau wie von der Gene Ontology vorgesehen auch in
VerIS abzubilden, müssen Tabellenschemata einmalig in VerIS verankert werden. Leider sind die Schemata der Tabellen nur als mySQL-Standard zugänglich. MS-Access benutzt jedoch Jet SQL, was zunächst eine manuelle Transformation des mySQL-Schemas in den Jet SQL-Standard nötig machte. Genauere
Informationen zum Transfer der beiden Schema-Formate werden in 6.1 gegeben.
Zunächst wird eine temporäre Tabelle auf Basis des gespeicherten und in VerIS
verankerten Jet SQL-Schemas angelegt. Danach werden die Daten der Textdatei
mittels des Access-internen Importmechanismus in diese temporäre Tabelle geschrieben. Der Tabelle wird noch ein Feld „myID“ hinzugefügt, welches vorläufig noch leer bleibt, später jedoch als Schlüssel benutz wird.
5.3. Keymanager
Einige Tabellen der Gene Ontology haben Schlüssel, die zwar auf eine Version
bezogen eindeutig sind, in einer Abfolge von Versionen aber ihre Schlüsseleigenschaft verlieren und sich daher nicht als Vergleichsargument für die Historisierung der Daten eignen. Aus diesem Grund wird es nötig, eigene, wirkliche
Schlüssel („myID“) in die Tabelle zu integrieren. Dieses „Schlüsselproblem“
tritt auch in der exemplarisch verwendeten Tabelle „term“ auf.
In der Tabelle „term“ gibt es jedoch ein Argument („acc“), das den Datensatz
eindeutig identifiziert und sich darüber hinaus über verschiedene Versionen
nicht ändert. Da es sich hierbei allerdings technisch nicht um das Schlüsselargument handelt, muss nach jedem Import eine durch eine Abfrage realisierte
Schlüsselverifizierung durchgeführt werden, um zu prüfen, ob das Argument
„acc“ die Schlüsseleigenschaften der Eindeutigkeit erfüllt.
Nach diesem Test werden die neuen Schlüssel („myID“) für die temporäre Tabelle angepasst. Hierzu wird ein Vergleich der temporären Tabelle mit der aktuellen Tabelle durchgeführt. Als Join-Argument wird das angenommene
59
Schlüsselargument „acc“ benutzt. Bei Gleichheit wird der Wert des neuen
Schlüsselarguments „myID“ aus der aktuellen Tabelle übernommen. Den Datensätzen der temporären Tabelle, welche keinen Joinpartner in der aktuellen Tabelle haben (also neu hinzugefügt wurden), werden neue, inkrementelle Schlüsselwerte zugeordnet. Als Startwert wird der maximale Schlüsselwert der aktuellen
Tabelle plus 1 verwendet.
Nachdem nun der temporären Tabelle alle neuen Schlüsselwerte zugeordnet
wurden, wird das Argument „myID“ als Schlüssel dieser Tabelle gesetzt. Nun
sind ein Vergleich der temporären und aktuellen Tabelle und eine daraus resultierende Differenzspeicherung möglich. In Kapitel 6.2 wird der genaue technische Ablauf des Keymanagers erklärt.
5.4. Historymanager
Die Historisierung ist ein Vergleich der gerade importierten, temporären Tabelle
mit der Tabelle, die die aktuellen Daten enthält. Änderungen zwischen diesen
beiden Tabellen (also Änderungen, Einfügungen und Löschungen) werden in der
Delta-Tabelle gespeichert.
Zur Speicherung der Deltadaten wurde das Prinzip mit nur einer Delta-Tabelle
genutzt, das in 4.3.1.2 vorgestellt wurde. Die Tabelle enthält:
• den Schlüssel der ursprünglichen Tabelle („myid“),
• den Zeitstempel der Differenzspeicherung („datum“), der zusammen mit
dem ursprünglichen Schlüssel den Schlüssel der Deltatabelle bildet,
• das Pro Nicht-Schlüssel-Argument, je ein Feld mit den Zusätzen „_old“
und „_new“,
• den Typ der Änderungen („P“, „M“, „PM“).
Die Anfügeabfrage, um die Deltatabelle zu füllen, ist eine Union-Abfrage, bestehend aus drei Teilabfragen, welche die Änderungsdaten für die drei
Änderungstypen (hinzugefügte Daten, gelöschte Daten, modifizierte Daten)
abfragen. Diese drei Teilabfragen wurden nach dem in Kapitel 4.3.1.1
erarbeiteten Schema entwickelt. Das Vergleichsargument für diese Abfragen ist
der im Keymanager integrierte, neue Schlüssel „myid“.
60
Nachdem die Deltatabelle gefüllt wurde, ist es nicht mehr nötig, die (vormals)
aktuelle Tabelle im System vorzuhalten. Sie wird daher gelöscht und die temporäre Tabelle wird durch Umbenennung zur aktuellen Tabelle.
Folgendes Schaubild verdeutlicht den „Weg“ der Gene Ontology Daten durch
den automatisierten Import und die Historisierung:
Gene Ontology
term.txt
Import
term_Temp
+“myID“
1. Differenzspeicherung mit term_Aktuell
Deltatabelle
D_Term
2. wird durch umbenennen zu
term_Aktuell
5.5. Versionmanager
Da ältere Versionen der Datenbank nicht in VerIS gespeichert werden, benötigt
man den Versionmanager, um alte Versionen der Daten zu rekonstruieren. Der
Anwender muss lediglich das Datum angeben, bis zu dem die Rückwärtsrekonstruktion durchgeführt werden soll und eine Endung für den Tabellenname der
Tabelle, die durch die Rekonstruktion entsteht.
61
Abbildung : VerIS Rekonstruktionsformular
Mit Hilfe der aktuellen Daten und der Delta-Tabelle ist eine Rekonstruktion bis
zu einem beliebigen Zeitpunkt möglich. Für jeden Datensatz ist nur die letzte
Änderung, die noch im angegebenen Zeitfester liegt, relevant. Wenn ein Datensatz zum Beispiel mehrfach geändert wurde, ist nur die letzte, vom jetzigen Datum aus rückwärts gesehene Änderung interessant.
Zunächst wird die aktuelle Tabelle kopiert. Auf dieser sogenannten Arbeitstabelle („T_inwork“) werden die Rückwärtsänderungen durchgeführt. Für die Änderungstypen P und M (also Einfügungen und Löschungen) gestaltet sich die
Transformation recht einfach. Mittels zweier Abfragen werden die letzten Änderungen pro Datensatz der Delta-Tabelle ermittelt, die als Deltatyp den Wert „P“
bzw. „M“ in der Spalte „Delta_typ“ haben und das angegebene Datum noch
nicht unterschritten haben. Dann werden sie mit einem einzigen UPDATE- oder
DELETE-Befehl der Arbeitstabelle entweder hinzugefügt oder aus dieser entfernt. Dabei verhält sich das Löschen und Einfügen umgekehrt zum Wert des
Deltatyps. Das bedeutet, dass alle Einträge, die ein „P“ als Deltatyp haben, gelöscht werden, da sie zwischenzeitlich eingefügt wurden, in der alten Version
also noch nicht vorhanden waren.
Bei den geänderten Datensätzen (Deltatyp „PM“) gestalten sich die Änderungen
an der Arbeitstabelle nicht so einfach. In diesem Fall müssen die passenden Datensätze der Delta-Tabelle mittels eines Recordsets durchlaufen werden, um
dann die Änderungen in die Arbeitstabelle durchzuführen. Dieses Problem sowie
die technische Umsetzung werden in Kapitel 6.3 ausführlicher beleuchtet.
62
Sind alle Änderungen an der Arbeitstabelle durchgeführt worden, wird sie in den
vom Benutzer gewünschten Namen umbenannt.
5.6. Querymanager
Der Querymanager soll anhand dreier ausgewählter Beispiele die verschiedenen
Möglichkeiten der interaktiven Abfragen durch den Benutzer und die unterschiedlichen Darstellungsformen der dadurch gewonnenen Informationen deutlich machen. Es werden zwei Möglichkeiten der benutzerinteraktiven Abfragen
sowie eine Möglichkeit der graphischen Darstellung der Ergebnisse der Abfragen aufgezeigt.
Abbildung : VerIS Queryformular
Die Benutzerangaben der interaktiven Abfragen werden in globalen Variablen
gespeichert und dann (mittels Funktionen) in die der Darstellung zugrundeliegenden Abfrage integriert. Durch die Schaltfläche „Wert anzeigen“ werden die
globalen Variablen aktualisiert und die Abfrageergebnisse verändert. Im rechten
Teil des Formulars wird die Darstellungsform durch ein Diagramm gezeigt. Solche Diagramme lassen sich durch in MS Access eingebaute Funktionen sehr
schnell und problemlos erstellen.
63
Es wurde im System VerIS mehr Arbeit darauf verwendet, die Daten zu importieren, historisieren und zu rekonstruieren, als auf die Darstellung der meist
trivialen SQL-Abfragen, die den Informationen zugrunde liegen. Es soll an
dieser Stelle nicht unerwähnt bleiben, dass eine Vielzahl anderer Abfragen und
Darstellungsformen möglich sind, die alle auf einfache Weise realisiert werden
können.
5.7. Bewertung des Systems
Das System VerIS bietet eine gute Möglichkeit, Konzepte und Methoden eines
Versionsmanagement zu verdeutlichen. Natürlich kann ein in einer Diplomarbeit
entwickeltes System nicht ein Versionsmanagement in der Praxis ersetzen. Dies
gilt schon allein deshalb, weil dieses System lediglich anhand einer Tabelle die
Methoden eines Versionsmanagements ausführt. Die entwickelten Methoden zur
Differenzspeicherung und Rekonstruktion sowie die gewonnenen Erkenntnisse
über die Lösung unvorhersehbarerer Probleme wie dem „Schlüsselproblem“ lassen sich jedoch sehr gut als Grundlage für die Entwicklung eines Versionsmanagement nutzen.
Durch die Anwendung der Konzepte zur effizienten Differenzspeicherung sowie
der Verbesserung der Rekonstruktionsabfragen arbeitet das System VerIS zufriedenstellend effektiv. Da es jedoch zu häufigen Einfügungen und Löschungen
beim Import der Tabelle aus der Gene Ontology kommt, sollte die Datenbank
des öfteren komprimiert bzw. eine automatische Komprimierung der Datenbank
(in neueren Access-Versionen) eingestellt werden.
64
6. Ausgewählte Probleme der Implementierung
Im Folgenden sollen drei ausgewählte Probleme und deren Lösungen beschrieben werden, die während der Entwicklung des Versionsmanagementsystems
VerIS aufgetreten sind.
6.1. Import des Tabellenschemas
Ein automatischer Import von mySQL-Daten, wie sie die Gene Ontology anbietet ist mit MS Access problemlos durchführbar. Allerdings werden die Datentypen der entsprechenden Spalten der Tabelle auf Grund ihrer Beschaffenheit von
Access selbst bestimmt, da die Daten keinerlei Informationen über den von der
Gene Ontology vorgesehenen Datentyp in den mySQL-Daten enthalten. Außerdem müssen die Schlüsselargumente vom Benutzer bestimmt werden und vorgesehene Indizes bleiben unbeachtet.
Um das von der Gene Ontology vorgesehene Tabellenschema in einer AccessDatenbank abzubilden, ist also ein Import des mySQL-Tabellenschemas in Access nötig. MS Access bietet aber keinen automatisierten Import von mySQLTabellenschemata an. Da eine automatisierte Einbindung eines mySQL-Schemas
in eine Access Datenbank den Rahmen dieser Arbeit gesprengt hätte, wurden die
Schemata manuell transformiert.
Es mussten lediglich einige syntaktische Unterschiede zwischen der mySQLSchemadefinition und dem von MS Access verwendeten SQL-Dialekt JET-SQL
beachtet werden ( z.B. „CREATE TABLE [term] ...“ statt „CREATE TABLE
term ...„).
65
6.2. Differenzspeicherung ohne Schlüssel
Während der Entwicklung von VerIS wurde herausgefunden, dass das in der
Tabelle term verwendeten Schlüsselargument id über den Verlauf der verschiedenen Versionen seine Eigenschaft einen Datensatz eindeutig zu identifizieren
verliert („Schlüsselproblem“).
Ein solcher versionsunabhängiger Schlüssel ist jedoch Vorrausetzung für die
dem System zugrundeliegende Differenzspeicherung. Daher wurde versucht, ein
anderes Argument zu finden, welches diese versionsunabhängige Schlüsseleigenschaft besitzt. Nach Analyse der Argumente der Tabelle term und den Änderungen, die auf den Daten auftraten, wurde festgestellt, dass das Argument acc
ein Kandidat für einen solchen angenommenen Schlüssel ist.
Bei der Differenzspeicherung ohne Schlüssel wird über den angenommenen
Schlüssel verglichen. Es ist jedoch vor jeder Differenzspeicherung ein Test nötig, ob der angenommene Schlüssel in der neuen Version immer noch die
Schlüsseleigenschaft der Eindeutigkeit besitzt, da dieser Integritätsheck nicht
vom DBMS übernommen wird (da acc im datenbanksinne gar kein Schlüssel
ist). Dieser Test wurde in VerIS durch die Abfrage keycheck_term realisiert:
SELECT acc
FROM term_Temp
GROUP BY term_Temp.acc
HAVING (((Count(term_Temp.acc))>1));
Abfrage keycheck_term
Die Abfrage keycheck_term liefert Werte, wenn das Argument acc mehr als
einmal („> 1“) in der zu importierenden, temporären Tabelle term_Temp vorkommt. Im VBA-Code wird die Anzahl der Ergebnisse dieser Abfrage mit der
Funktion DCount abgefragt. Ist es gleich 0, so enthält die Tabelle keine doppelten Werte von acc und acc erfüllt weiterhin die Eigenschaft der Eindeutigkeit.
If DCount("*", "keycheck_term") = 0 Then keycheck = True
66
Ist der Test auf Eindeutig nicht erfolgreich, so kann keine Historisierung der Daten erfolgen. Während der gesamten Arbeit mit dem System VerIS ist dieser
Test jedoch immer positiv ausgefallen. Daher ist davon auszugehen, dass acc
auch weiterhin die Eigenschaft der Eindeutigkeit besitzt. Da dies jedoch keine
gesicherten Erkenntnisse und acc deshalb nicht im Tabellenschema als Primärschlüssel definiert werden kann, muss der Test weiterhin vor jeder Differenzspeicherung durchgeführt werden.
Bei den Abfragen zur Rekonstruktion alter Daten-Versionen wird die aktuelle
Tabelle über den Schlüssel mit der Deltatabelle verglichen. Da ein solcher Vergleich (z.B. durch JOIN angewendet) mit Interger-Werten um einiges effizienter
durchgeführt werden kann, als mit Text-Werten, in denen das Argument acc definiert ist, wurden in VerIS ein neuer, künstlicher Schlüssel myid mit einem Zahlenwert eingeführt.
Zunächst haben alle späteren Schlüsselargumente myid der zu importierenden
Tabelle term_Temp den Wert 0, da dieser Wert als Standardwert in dem Tabellenschema festgeschrieben wurden und dieses Argument beim Import der Daten
nicht gefüllt wird, da es in der ursprünglicher Tabelle der Gene Ontology nicht
vorkommt.
Danach werden die zu importierende Tabelle term_Temp und die aktuelle Tabelle term_Aktuell über das Attribut acc miteinander verglichen und die korrespondierenden Werte des Arguments myid der aktuellen Tabelle in die Tabelle
term_Temp geschrieben. Dies geschieht mittels folgendem UPDATE-Befehl:
UPDATE term_Temp INNER JOIN term_Aktuell
ON term_Temp.acc =term_Aktuell.acc
SET term_Temp.myid =term_Aktuell.myid;
Falls noch keine aktuelle Tabelle vorhanden ist (kein vorheriger Import von Daten wurde durchgeführt), werden den Attributen myid inkrementelle Werte beginnend mit 1 zugeordnet.
Alle Argumente myid, die nach dieser Änderung immer noch den Wert 0 besitzen, wurden hinzugefügt. Sie erhalten inkrementelle Werte beginnend mit dem
höchsten Wert von myid der aktuellen Tabelle.
67
Nun besitzt die zu importierenden Tabelle einen zu acc korrespondierenden
künstliche Zahlenwert-Schlüssel. Mit dem Befehl
„ALTER TABLE term_Temp ADD constraint [myid] primary key(myid)”
wird dem Attribut myid die Schlüsseleigenschaft zugewiesen.
Anhand dieser Schlüssel kann nun eine effektivere Differenzspeicherung und
Rekonstruktion erfolgen.
6.3. Das „UPDATE-Problem“ bei der Rekonstruktion
Im Rahmen meiner Diplomarbeit bin ich auf eine Unzulänglichkeit von MS Access bezüglich der Bearbeitung von UPDATE-Anweisungen gestoßen. Dieses
Problem soll im Folgenden erläutert werden.
Die Anfüge- und Löschabfragen für die Rekonstruktion alter Daten-Versionen
lassen sich durch einfache INSERT- und DELETE-Befehle in VerIS realisieren.
Als Beispiel sei hier die Abfrage zum Entfernen ehemalig eingefügter Datensätze gegeben :
DELETE * FROM T_inwork
WHERE myid IN
(SELECT myid FROM D_term_P)
Aus der Arbeitstabelle T_inwork werden also diejenigen Einträge gelöscht, deren Schlüssel auch in der Abfrage D_term_P vorhanden sind. Bei der Abfrage
D_term_P handelt es sich um für die Rekonstruktion aufbereitete Daten aus der
Delta-Tabelle (datum größer der gewünschten Daten-Version, nur das kleinste
Datum pro ID, Deltatyp =“P“).
Versucht man nun aber das gleiche Prinzip auf die UPDATE-Anweisung der
Rekonstruktion (also auf die Änderung der Argumente der Arbeitstabelle) anzuwenden, tritt ein Fehler auf. Die folgende Anweisung kann von MS Access nicht
bearbeitet werden (D_term_PM seien auch hier wieder die aufbereiteten Daten
aus der Delta-Tabelle, aus Gründen der Übersichtlichkeit wird nur das Argument
name versucht auszutauschen):
68
UPDATE T_inwork
SET T_inwork.name =
(SELECT D_term_PM.name_old
FROM D_term_PM
WHERE D_term_PM.myid = T_inwork.myid)
WHERE Tabelle_akt.ID=
(select D_term_PM.myid
from D_term_PM
where D_term_PM.myid = T_inwork.myid)
Bei genauer Betrachtung der Anweisung wird klar warum. Es wird versucht das
Element name auf eine Menge bestehend aus der SELECT-Anweisung zu setzen.
Dem Entwickler ist jedoch klar, dass diese SELECT-Anweisung nur einen Wert
zurückliefert, da es sich bei D_term_PM um eine nach myid gruppierte Abfrage
handelt. Eine Idee wäre, mittels einer Aggregatfunktion im SELECT-Teil eine
Ein-Elementigkeit der SELECT-Abfrage zu erzwingen, etwa
„…SELECT MAX(D_term_PM.name_old)…”
Doch auch diese Abfrage führt zum selben Fehler. Es wurde festgestellt, dass
solche SQL Konstrukte in MS Access nicht ausdrückbar sind. So kann selbst
eine UPDATE-Anweisung mit einer Konstanten im SELECT-Teil nicht ausgeführt werden:
UPDATE TabelleA
SET TabelleA.name =
(SELECT 'Müller' FROM TabelleB)
In anderen Datenbanksystemen, wie z.B. Oracle ist aber sowohl eine solche Abfrage, als auch die oben erwähnte Möglichkeit mit einer Aggregatfunktion zulässig([PRI04]).
69
Da die Änderungen der Rekonstruktion mittels SQL-Code in MS Access nicht
zu realisieren waren, wurde das Problem gelöst, indem die Abfrage D_term_PM
mittels eines Recordsets geöffnet und mit eine Schleife durchlaufen wurde. Für
jeden Eintrag in D_term_PM wurde dann ein UPDATE-Befehl abgesetzt, der die
Werte dieses Eintrags des Recordsets enthielt. Diese Variante ist zwar nicht so
effizient, wie ein einziger UPDATE-Befehl, führt aber auch nicht zu merklichen
Verschlechterung der Performanz. Außerdem ließ sich dieser Weg wegen oben
beschriebener Unzulänglichkeiten nicht umgehen.
70
7. Zusammenfassung und Ausblick
In dieser Arbeit wurden Konzepte für ein effizientes Versionsmanagement für
Datenbanken im Allgemeinen und Ontologie-Datenbanken im Speziellen entwickelt. Es wurden Methoden zur effizienten Gewinnung von Änderungsdaten, die
zwischen zwei Versionen von Daten auftreten sowie der effizienten Speicherung
dieser Änderungsdaten diskutiert. Darüber hinaus wurde das Konzept der Rekonstruktion alter Daten-Versionen erörtert, wodurch eine Speicherung vieler
Daten-Versionen überflüssig wird und lediglich eine stark minimierte Anzahl an
Daten gespeichert werden muss.
Diese Konzepte und Methoden wurden in dem mit MS Access entwickelten System VerIS angewendet und verwirklicht. Das System VerIS zeigt exemplarisch,
wie ein Versionsmanagement für Datenbanken mit großen Datenbeständen aussehen kann. Da ontologische Daten häufigen Änderungen unterzogen sind und
diese Änderungen für die Anwender der Ontologie von großem Interesse sind,
arbeitet des Versionierungssystem VerIS auf der Grundlage der Daten der Gene
Ontology. Mit Hilfe dieses Systems wurde es möglich, den Änderungsverlauf
der Daten der Gene Ontology herauszufiltern und abzuspeichern. Unter Verwendung dieser Änderungsdaten konnten alte Datenstände rekonstruiert und nützliche Informationen über den Verlauf und die Art der Änderungen gewonnen
werden. Da die Gene Ontology nicht über ein Versionsmanagement verfügt, waren diese Änderungsdaten und die daraus resultierenden Informationen bisher
nicht abrufbar.
Während der Entwicklung des Systems VerIS wurde ein Problem der Daten der
Gene Ontology offenbar: Die Primärschlüssel einiger von der Gene Ontology im
Internet bereitgestellter Tabellen verlieren über den zeitlichen Verlauf der Versionen ihre Eigenschaft, einen Datensatz eindeutig zu identifizieren („Schlüsselproblem“). Durch diese Unzulänglichkeit entstanden zunächst eine Menge von
„Phantomänderungen“, die zwar aus Datenbanksicht Änderungen sind, jedoch
71
nicht als solche zu verstehen sind. Ohne einen durchgängig gültigen, versionsunabhängigen Primärschlüssel ist aber keine sinnvolle Differenzspeicherung der
Änderungsdaten möglich. Daher wurde eine Methode entwickelt, die mittels eines anderen, den Datensatz identifizierenden Arguments der Tabelle und unter
Einsatz künstlicher Schlüssel die Differenzspeicherung und damit ein Versionsmanagement dennoch möglicht macht.
Das System VerIS arbeitet beispielhaft mit der Haupttabelle „term“ der Gene
Ontology. Diese, im Zuge meiner Diplomarbeit entwickelte Anwendung kann
den Anforderungen eines in der Praxis eingesetzten Versionsmanagementsystems nicht entsprechen. Die Konzepte und Methoden einer effizienten Versionsverwaltung wurden aber verdeutlicht.
Für den Einsatz auf den kompletten Datenbestand der Gene Ontology müssten
die Methoden bezüglich der Historisierung auf alle Tabellen ausgeweitet werden. Eine weitere mögliche Erweiterung von VerIS betrifft die Automatisierung
der in dieser Arbeit vorgestellten Schema-Transformation von mySQL nach
JET-SQL, um manuelle Transformationen zwischen diesen beiden SQLDialekten zu vermeiden. Allgemein sollten die Methoden etwas universeller
einsetzbar gemacht werden und sich nicht nur auf einzelne Tabellen beziehen,
sondern aus den Schemata der Tabellen automatisiert Änderungsabfragen und
Deltatabellen generieren. Darüber hinaus wäre eine direkte Verbindung der Datenbank mit den im Internet zugänglichen Daten sinnvoll, um einen vollautomatisierte Historienführung zu gewährleisten.
Es ist durchaus möglich, dass das „Schlüsselproblem“ der Gene Ontology auch
in anderen Datenbanken auftritt. Daher wäre eine theoretische Herangehensweise an dieses Problem interessant. Eine detaillierte Diskussion der Fragen „Wie
könnte eine Differenzspeicherung ohne Schlüssel im Generellen Aussehen?“
und „Wie kann eine identifizierende Eigenschaft mehrerer Argumente am effizientesten gefunden werden?“ hätte jedoch den Rahmen dieser Arbeit gesprengt.
72
8. Literatur
[BB02]
Irene Bauder, Jürgen Bär : Access 2002 und MS SQL Server.
Hanser Verlag 2000
[DAT97]
C.J. Date : A Guide to the SQL Standard fourth Edition. Addison Wesley 1997
[FMA07]
http://sig.biostr.washington.edu/projects/fm/ (Februar 2006)
[GEN07]
www.geneontology.org (Februar 2006)
[GOL07]
http://www.linguistics-ontology.org/ (Februar 2006)
[GRU93]
T. R. Gruber: A translation approach to portable ontologies.
In: Knowledge Acquisition, Band 5, Nummer 2, Seite 199220, 1993
[HES06]
Prof. Dr. Michael Hess : Kleine Einführung in SQL. 2006
[KEM97]
A. Kemper, A. Eickler : Datenbanksysteme - Eine Einführung (2. Auflage). Oldenburg Verlag 1997
[KOF99]
Michael Kofler : Visual Basic 6. Addison Wesley 1999
[MAN02]
Prof. Dr. Rainer Manthey : Vorlesungsfolien Informationssysteme, Kapitel 2 : Relationale Datenbanken. 2002
[MAT03]
Daniel H Mattes : SQL - Der Einsatz im Intra- und Internet,
C&L. 2003
73
[MIC07]
www.microsoft.com (Februar 2006)
[MK06]
Linda DeMichiel, Sun Microsystems und Michael Keith,
Oracle Corporation :JSR 220: Enter-prise JavaBeansTM,
Version 3.0 Java Persistence API, Kapitel 2.1.10, Mai 2006
[PHI02]
Klaus Rüdiger Phillip : SQL, die Standard-Abfragesprache
für Datenbanken. 2002
[PÖG82]
Otto Pöggeler, M.Heidegger: Sein und Zeit. In: Grundprobleme der großen Philosophen. Philosophie der Gegenwart
IV, (UTB) Göttingen 1982
[PRI04]
Jason Price: Oracle Database 10g SQL. McGraw-Hill, 2004
[SCH05]
Hartmut Schmelling : Access effektiv nutzen. 2005
[SK]
Barry Smith,Bert R.E. Klagges: Philosophie und biomedizinische Forschung. Department of Philosophy, University
Buffalo, Institut für Biologie II – Lehrstuhl für Genetik, Universität Leipzig
[STU01]
Prof. Dr. Rudi Studer, Henrik Oppermann, Hans-Peter
Schnurr : Die Bedeutung von Ontologien für das Wissensmanagement. Institut AIFB, Universität Karlsruhe, Ontoprise
GmbH, 2001
[TEI07]
TEIA Teles European Internet Academy : SQL. 2007
[UG96]
M. Uschold & M. Gruninger Ontologies: Principles, methods
and applications Knowledge Engineering Review, 1996
[WIK07]
www.wikipedia.org (Februar 2006)
74
Erklärung:
Hiermit erkläre ich, dass die vorliegende Diplomarbeit selbständig von
mir durchgeführt wurde und keine anderen als die angegebenen Quellen
und Hilfsmittelbenutzt wurden. Zitate sind durch entsprechende Literaturstellen als solche kenntlich gemacht.
Bonn, 13. März 2007 Tim Sondermann