Ein grandioser Londoner Wissenschaftler behauptet eines Abends vor seinen Freunden, er könne mit Hilfe einer neu erfundenen Zeitmaschine in der Zeit, der 4. Dimension, beliebig vor und zurück reisen. Niemand glaubt ihm, viele lachen ihn sogar aus.
Eine Woche später erzählt der Zeitreisende eine noch viel ausgefallenere Geschichte. Sie handelt von einer Reise in die Zukunft der Erde: in das Jahr 802701. Dort findet er eine traumhafte Idylle, gesunde, üppige Natur und sehr sanfte feingliedrige und sorgenfreie Geschöpfe, die sich selbst "Eloy" nennen. Doch schnell bemerkt er, dass hier nicht alles einem Paradies gleicht, denn da sind noch die "Morlocks", schaurige, bleiche und blinde Wesen, mit denen nicht zu spaßen ist. Nur mit knapper Not kann der Zeitreisende entkommen und seinen Freunden so von seinen Erlebnissen berichten. Doch die glauben ihm immer noch nicht und verlangen Beweise …

Dieses Sujet bezieht sich auf den Roman "Die Zeitmaschine" von H.G. Wells, einen der bekanntesten und besten utopischen Science-Fiction-Romane der Weltgeschichte. 
Der Traum von der Zeitreise hat die Menschheit jedoch nicht erst seit 1905, dem Entstehungsjahr des Romans beschäftigt, sondern die gesamte Entwicklungsgeschichte begleitet. Heute beschäftigen sich neben den Science-Fiction-Autoren auch mehr oder minder seriöse Wissenschaftler mit dem Thema. Während reale Reisen in die Vergangenheit und in die Zukunft wohl trotzdem ein Wunschtraum bleiben werden, kann man aufregende virtuelle Zeitreisen heute in jedem Kino buchen oder am Computer unternehmen.

Wenn nun auch ein Informations- und Datenverwaltungs-System Zeitreisen anbietet, mag das weniger spektakulär sein; schließlich werden dem Reisenden am Zielort statt bunter Filmsequenzen lediglich Texte und Zahlen geboten. Erfahrene Anwender von Informationssystemen tragen ihre Zeitreise-Wünsche trotzdem mit steigender Vehemenz vor. Zwar liefern gute Informationssysteme heute per Knopfdruck auf fast jede Frage eine befriedigende Antwort in Form eines komplexen Berichtes oder einer anschaulichen Grafik, solange die Fragestellung sich auf gegenwärtige Zusammenhänge beschränkt. In der ersten Einsatzphase eines neuen Systemes muss dies notgedrungen akzeptiert werden, da in der Datenbank zunächst ausschließlich Daten der Gegenwart gespeichert sind. Später erwachen neue Begehrlichkeiten: Kann man die vorhandenen hochwertigen Auswertungsmöglichkeiten nicht für beliebige Zeitpunkte der Vergangenheit oder Zukunft benutzen? Einfach einen Stichtag eingeben und die Zeitreise starten?

Man kann, jedenfalls beim Personalverwaltungssystem PVS. 
Und der Reisekomfort ist unübertroffen: Zwar verfügen die meisten Informationssysteme heute über Archivierungs- und Historisierungsfunktionen; diese bilden eine spezifische Erweiterung des funktionalen Kernes, mit der allerdings auch nur spezifische Fragestellungen beantwortet werden können. 
Im Gegensatz zu diesen Systemen benötigt das PVS derartige Funktionen gar nicht, weil sämtliche Daten historisiert gespeichert werden und sämtliche Auswertungsfunktionen mit beliebigen Stichtagen aufgerufen werden können.

So könnte eine Sightseeing-Tour aussehen:

• 1. Station: Die Organisationsstruktur und Aufgabenverteilung Ihrer Dienststelle zum Jahresbeginn vor 3 Jahren; zu erreichen mit dem Geschäftsverteilungsplan
• 2. Station: Die verfügbaren Stellen und ihre Besetzung im Zeitraum der letzten 2 Jahre; zu erreichen mit der Stellenbesetzungsliste
• 3. Station: Die Altersstruktur Ihrer Dienststelle in 5 Jahren; zu erreichen mit der Statistik Altersstruktur

Diese Folge ist beliebig erweiterbar. Betrachten Sie den Abschnitt Berichte und Statistiken des PVS-Handbuches als einen Katalog für Zeitreisen – alle angebotenen Auswertungen erwarten einen Stichtag als Parameter.
Und Reisen bildet: Wenn man einmal Reisen in unterschiedliche Zeiten unternommen hat, kann man auch Vergleiche anstellen und Tendenzen analysieren. Und man kann die Auswirkungen von Organisationsveränderungen, der Personalentwicklung und des Personalhaushaltes über längere Phasen quantifizieren.

Im folgenden soll kurz dargestellt werden, mit welchen strukturellen und funktionellen Mitteln diese Möglichkeiten erreicht werden. Der Aufwand ist enorm – schließlich besteht die PVS-Datenbank aus mehr als 100 Datentabellen und über 1000 Datenfeldern.

Jeder einzelne Datensatz verfügt über zwei spezielle Datumsfelder, die den Anfang und das Ende seiner Gültigkeit registrieren. Zu jeder historisierten Datentabelle gesellt sich eine Ordnungstabelle, welche die historische Reihenfolge zusammengehöriger Datensätze in der Datentabelle verwaltet.

Und weiter: Was bei nicht historisierten relationalen Datenbanken nur unter bestimmten Bedingungen notwendig wird, ist bei dem PVS obligatorisch: Für jede Relation zwischen zwei historisierten Datentabellen existiert eine Verbindungstabelle. Deren Notwendigkeit ist darin begründet, dass die Historisierung in keiner Weise vorbestimmt ist: Die Gültigkeitszeiträume aller Datensätze sind völlig unabhängig. Damit unter diesen Umständen Relationen vollständig abgebildet werden können, müssen in die Verbindungstabelle die Identifikatoren aller zusammengehöriger Datensätze eingetragen werden, die sich zeitlich überschneiden, und sei es auch nur teilweise.

Damit für jedes Datenobjekt mehrere historische Versionen verwaltet werden können, muss der PVS-Benutzer über besondere Funktionen verfügen, Funktionen, wie sie in keinem vergleichbaren System angeboten werden.

• Um eine neue historische Version zu einem vorhandenen Datenobjekt zu erstellen, verwendet man die Funktion Gültigkeitszeitbereich splitten. Die aktivierte historische Version eines Datenobjektes wird zeitlich gesplittet. Dabei muss der Benutzer zunächst den Stichtag angeben, zu dem die Änderung erfolgen soll. Danach wird automatisch eine Kopie des angezeigten Datensatzes erzeugt, an der die gewünschten Datenfeld-Änderungen vorgenommen werden können. Die neue und die zuvor angezeigte historische Version des Objektes werden automatisch in der Ordnungstabelle als Nachfolger und Vorgänger registriert.
• Die Umkehrung zur Splittung ist die Funktion Gültigkeitszeitbereich vereinigen. Dabei wird die aktivierte historische Version eines Datenobjektes mit ihrem Nachfolger zeitlich vereinigt. Die angezeigten Datenfelder werden mit den Werten des Nachfolgers überschrieben und der Nachfolger wird gelöscht. Der Gültigkeitszeitbereich der vereinigten Version ergibt sich aus der Vereinigung der Zeitbereiche der beiden betroffenen Datensätze.
• Damit der Benutzer zwischen den vorhandenen historischen Versionen eines Datenobjektes navigieren kann, existieren zwei weitere Funktionen: Mit der Funktion Vorgänger anzeigenwird der zeitliche Vorgänger der aktivierten historischen Version aufgerufen;
  mit der Funktion Nachfolger anzeigen wird der zeitliche Nachfolger der aktivierten historischen Version aufgerufen.

Mit dieser Menge von vier Bearbeitungsfunktionen können alle Situationen abgebildet werden.
Allerdings ist die Anwendung nicht immer trivial. Ein Beispiel: Eine Historisierung von Datenobjekten kann auch sinnvoll sein, wenn sich deren Relationen und hierarchischen Unterordnungen verändert haben (etwa bei der Umsetzung eines Dienstpostens in ein anderes Referat oder der Zusammenlegung zweier Abteilungen). In solchen Fällen müssen die betroffenen Datenobjekte zunächst historisiert werden; danach wird die Zuordnungs-Veränderung an den neuen historischen Versionen vorgenommen.

Auch bei der Datenabfrage sind Besonderheiten zu beachten: Grundsätzlich ist jede Datenabfrage mit einem Stichtag oder einem Abfrage-Zeitraum auszuführen. Bei jeder in die Abfrage einbezogenen historisierten Datentabelle müssen die Datumsfelder für den Anfang und das Ende der Gültigkeit mit dem Stichtag oder dem Abfrage-Zeitraum verglichen werden.
Die Anzahl der in eine Abfrage einbezogenen Datentabellen ist regelmäßig höher als bei nicht historisierten Datenbanken, da alle Relationen zwischen Datentabellen durch Verbindungstabellen abgebildet werden müssen.

Es ist leicht erkennbar, dass ein erheblicher struktureller und funktioneller Aufwand notwendig ist, damit Zeitreisen in Datenbanken möglich werden. 
Man kann diesen Aufwand begrenzen, wenn man folgende Tatsache beachtet: Während die benötigten Strukturen in gleicher Weise für jede historisierte Datentabelle bereit gestellt werden müssen, kann die funktionelle Lösung leicht verallgemeinert werden und ist somit wiederverwendbar. Das gilt übrigens auch für "normale" Reisen: Während für jedes neue Reiseziel ein neuer Verkehrsweg angelegt werden muss, kann man mit einem einzigen geeigneten Verkehrsmittel alle Reiseziele erreichen.

zurück