DE10348665B4

DE10348665B4 - Computergestütztes Datenbanksystem und Verfahren zum Betrieb hiervon

Info

Publication number: DE10348665B4
Application number: DE10348665A
Authority: DE
Inventors: Andreas Kemmler
Original assignee: SAP SE
Current assignee: SAP SE
Priority date: 2003-10-15
Filing date: 2003-10-15
Publication date: 2006-05-18
Anticipated expiration: 2023-10-16
Also published as: US20050086668A1; DE10348665A1; US7072906B2

Abstract

Computergestütztes Datenbanksystem mit einer Anwendungsschicht (1), in der unabhängig voneinander Anwendungen (3) zum Verbuchen von Datenobjekten (4) verschiedener Datenobjekttypen in eine der jeweiligen Anwendung (3) zugeordnete Datenbank (5) ausführbar sind, dadurch gekennzeichnet, daß eine gegenüber der Anwendungsschicht (1) gekapselte Belegschicht (2), in der eine Anzahl von Belegschreibern (7) mit jeweils einer dynamischen Schnittstelle (9) implementiert ist, eine Tabelle (8), in der einem Datenobjekttyp jeweils ein Belegschreiber (7) zugeordnet ist, wobei die jeweils angesprochene Anwendung (3) der Anwendungsschicht (1) in Reaktion auf einen Verbuchungsvorgang Information über das zu verbuchende Datenobjekt (4) sowie über die Verbuchung in Form einer Referenz vorgegebener Struktur erzeugt und der über die Tabelle (8) zugeordnete Belegschreiber (7) zum Zugriff auf die Referenz und damit auf die Information über die Schnittstelle (9) ausgestaltet ist, und ein Belegverbucher (11) zum dauerhaften Ablegen von durch einen Belegschreiber (7) übergebenen Belegobjektdaten mit Information über das zu verbuchende Datenobjekt (4) sowie...

Description

Die Erfindung betrifft ein computergestütztes Datenbanksystem sowie ein Verfahren zum Betrieb eines computergestützten Datenbanksystems nach dem Oberbegriff des Anspruchs 1 bzw. 11.

Bei einem computergestützten Datenbanksystem, wie es z.B. im Rahmen von SAP R/3 Verwendung findet, laufen in einer Anwendungsprogrammschicht unabhängig voneinander verschiedene Anwendungen, die Datenobjekte verschiedener Datenobjekttypen in einer der jeweiligen Anwendung zugeordneten Datenbank verbuchen, d.h. erzeugen, ändern oder löschen. Derartige Anwendungen sind z.B. Teilapplikationen des HR-Moduls der SAP R/3 für das Personalwesen, also Personaladministration, Organisationsmanagement, Personalentwicklung, Public Sektor u.dgl. Um feststellen zu können, welcher Benutzer wann welche Datenobjekte verbucht hat, ist eine Belegschreibung vorgesehen. Diese Belegschreibung legt das Datenobjekt vor sowie nach einer Verbuchung zusammen mit weiteren Informationen beispielsweise betreffend die Verbuchungszeit und den die Verbuchung durchführenden Benutzer automatisiert in einer Datenbank ab. Hierbei ist wegen der verschiedenen Datenobjekte und Beleganforderungen für jede Anwendung und jeden Datenobjekttyp eine eigene Belegschreibung fest zu implementieren. Die fest implementierten Belegschreibungen weisen dabei eine erhebliche Redundanz auf, so daß Systemresourcen wie Speicherplatz verschwendet werden und zudem ein erheblicher Wartungsaufwand entsteht. Zudem ist die feste Implementierung inflexibel, da datenbankbenutzerseitig nicht änderbar. Werden Anforderungen betreffend die Belegschreibung oder Datenobjekte geändert oder neu definiert, ist dies mit einem hohen Aufwand verbunden. Dies um so mehr, als die festen Belegschreibungen je nach Datenobjekttyp eine andere Schnittstelle aufweisen und damit unterschiedlich aufzurufen sind. Schließlich kann die Anwendung während der Ausführung der fest implementierten Belegschreibung nicht weiter benutzt werden, sondern muß zunächst auf deren Abschluß warten.

Aus WO 00/68785A1 ist ein System und ein Verfahren zum kundenspezifischen Anpassen der Visualisierung von Interfaces für Geschäftsobjekte bekannt. Es wird ein Smartcode-Generator oder eine Laufzeitumgebung benötigt, um den resultierenden Code der kundenspezifisch angepaßten Verfahren zu erzeugen, die das Interface umfassen.

Aus DE 697 00 770 T2 ist eine zirkuläre größenbegrenzte Dateienstruktur für ein Rechnerbetriebssystem bekannt, das für Administrationsanwender einen speziellen Dateityp zum effizienten Speichern von Prüfpfaden oder "Protokollen" in dem System schafft.

Der Erfindung liegt deshalb die Aufgabe zugrunde, ein computergestütztes Datenbanksystem sowie ein Verfahren zum Betrieb eines computergestützten Datenbanksystems nach dem Oberbegriff des Anspruchs 1 bzw. 11 zu schaffen, die im Betrieb flexibel an neue Anforderungen anpaßbar sind, wobei eine redundante Codierung weitgehend vermieden wird und die Anwendung durch die Belegschreibung nicht verlangsamt wird.

Diese Aufgabe wird entsprechend den Merkmalen des Anspruchs 1 bzw. 11 gelöst.

Hierdurch wird ein computergestütztes Datenbanksystem bzw. ein Verfahren zum Betrieb eines computergestützten Datenbanksystems geschaffen, bei dem in einer Anwendungsschicht unabhängig voneinander Anwendungen ausführbar sind, die Datenobjekte verschiedener Datenobjekttypen in eine der jeweiligen Anwendung zugeordnete Datenbank verbuchen, wobei die jeweils angesprochene Anwendung der Anwendungsschicht in Reaktion auf einen Verbuchungsvorgang Information über das zu verbuchende Datenobjekt sowie über die Verbuchung in Form einer Referenz vorgegebener Struktur erzeugt, einen dem Datenobjekttyp mittels einer Tabelle zugeordneten Belegschreiber einer Anzahl von in einer gegenüber der Anwendungsschicht gekapselten Belegschicht implementierten Belegschreibern mit einer dynamischen Schnittstelle aufruft, der Belegschreiber über die Schnittstelle auf die Referenz und damit auf die Information zugreift und Belegobjektdaten mit Information über das zu verbuchende Datenobjekt sowie über die Verbuchung zum dauerhaften Ablegen an einen Belegverbucher übergibt.

Die Informationsübergabe über eine Referenz auf Daten ermöglicht eine Schnittstelle, die für alle Datenobjekttypen und Belegschreiber unabhängig von deren spezifischer Implementienang offen ist. Dadurch sind die Belegschreiber unverändert für verschiedene Anwendungen und Datenobjekttypen verwendbar. Die Schnittstelle ist dabei dynamisch ausgeführt, kann also je nach Datenobjekttyp anders auf die übergebenen Daten zugreifen. Zusammen mit der Tabelle, die eine einfache Änderung der Zuordnung eines Datenobjekttyps zu verschiedenen Belegschreibern gestattet, kann die Belegschreibung datenbanknutzerseitig einfach gerändert werden. Beispielsweise kann die Verbuchung gewisser Datenobjekte durch Zuordnung zu einem Belegschreiber, der keine Belege erstellt, nicht mehr oder durch Zuordnung zu einem anderen Belegschreiber anders belegt werden. Es ergibt sich eine flexiblere Anpaßbarkeit unter Vermeidung redundanter Codierung. Da zudem die Belegschicht gegenüber der Anwendungsschicht gekapselt ist, wird eine asymmetrische Ausführung der Belegschreibung ermöglicht. Die Belegschreibung kann daher unabhängig von der Anwendung insbesondere im Hintergrund arbeiten, während die Anwendung uneingeschränkt weiterbenutzbar ist. Die Kapselung der Belegschicht erfolgt durch einen Programmteil, insbesondere einen ABAP-Funktionsbaustein, der von der Anwendungsschicht aufgerufen wird, anwendungsspezifische Transformationen der Information durchführt und eine Referenz vorgegebener Struktur an die eigentliche Belegschreibung übergibt.

Die Belegschreiber sind vorzugsweise als ABAP-Klassen ausgeführt, die jeweils die dynamische Schnittstelle und wenigstens eine Methode zur weiteren Verarbeitung der übergebenen Information enthalten. Hierbei ist wenigstens eine Basis-ABAP-Klasse vorgesehen. Abweichende Lösungen können von dieser Basis-ABAP-Klasse erben, Methoden ergänzen, überdefinieren oder komplett neu implementieren, wodurch sich eine weitergehende Anpaßbarkeit der Belegschreiber an geänderte Anforderungen ergibt, insbesondere im Zusammenspiel mit der Tabelle.

Ferner kann eine Customizing-Tabelle für weitere datenbanknutzerseitige Einstellungen vorgesehen sein. Hiermit läßt sich die Belegschreibung für bestimmte Datenobjekttypen und gegebenenfalls -subtypen zweckmäßigerweise abhängig von Differenzierungsparametern detailliert aktivieren oder deaktivieren. Die Customizing-Tabelle wird dabei vorzugsweise ausgewertet, bevor ein Belegschreiber aufgerufen wird, so daß für Daten, deren Verbuchung nicht belegt werden soll, ein Aufruf des Belegschreibers unterbleiben kann.

Das Verfahren kann durch ein Computerprogramm ausgeführt werden, das von einem insbesondere austauschbaren Datenträger und/oder einer Datenverbindung abrufbar ist.

Weitere Ausgestaltungen der Erfindung sind der nachfolgenden Beschreibung und den Unteransprüchen zu entnehmen.

Die Erfindung wird nachstehend anhand eines in der beigefügten Abbildung dargestellten Ausführungsbeispiels näher erläutert.
Das dargestellte Datenbanksystem umfaßt eine Anwendungsschicht 1 und eine gegenüber dieser gekapselte Belegschicht 2, die als Computerprogramm in einem Rechnersystem implementiert sind. Beispielsweise ist die Belegschicht 2 in ABAP-OO implementiert und gehört zur SAP BASIS, d.h. der Softwareschicht, die fast allen SAP Anwendungen zugrunde liegt, wobei das SAP System z.B. auf Windows NT einsetzbar ist.
In der Anwendungsschicht 1 laufen unabhängig voneinander Anwendungen 3, die in Reaktion auf Benutzeraktionen oder automatisiert Datenobjekte 4 in Datenbanken 5 verbuchen. Im SAP R/3 HR Modul sind die Datenobjekte 4 die Infotypen.
Die Verbuchung erfolgt zweckmäßigerweise über Anwendungsverbucher 6. Wird ein Datenobjekt 4 durch einen Datenbankbenutzer oder einen Prozeß verbucht, d.h. erstellt, geändert oder gelöscht, ruft die angesprochene Anwendung 3 einen zugehörigen Anwendungsverbucher 6 auf. Die Anwendungsverbucher 6 sind in der Anwendungsschicht 1 ablaufende, vorzugsweise mehreren Anwendungen 3, die gleiche Datenobjekte 4 verbuchen, zugeordnete Programmteile, die neben ihrer Hauptaufgabe, der Verbuchung von Datenobjekten 4 in Datenbanken 5, auch für die Übergabe von Information über den Verbuchungsvorgang aus der Anwendungsschicht 1 in die Belegschicht 2 verantwortlich sind. Hierzu ruft ein Anwendungsverbucher 6 einen gekapselten Programmteil auf, hier einen Funktionsbaustein, der Teil der Belegschreibung ist und die Verbuchung für die Belegschreibung aufbereitet. Dieser Programmteil erzeugt eine Referenz entsprechend einer einheitlichen Vorgabe, beispielsweise in Form eines Zeigers auf eine Datenstruktur aus Zeigern auf das Datenobjekt 4 vor der Änderung, das Datenobjekt 4 nach der Änderung, die Änderungszeit, die Kennung des die Änderung veranlassenden Benutzers oder Prozesses, usw. Eine mögliche Datenstruktur ist:
Hierbei werden in OLD_VALUE_REF eine Referenz auf ein Datenobjekt 4 vor der Änderung und in NEW_VALUE_REF eine Referenz auf das Datenobjekt 4 nach der Änderung übergeben, wobei CHG_INDICATOR die Art der Verbuchung anzeigt. Bei einem Aufruf kann beispielsweise in OLD_VALUE_REF eine Referenz auf ein Objekt oder auf eine Struktur aus mehreren Objekten übergeben. Die Informationsübergabe ist damit offen für alle Datenobjekttypen unabhängig von deren Aufbau. Lediglich der interne Aufbau der Struktur HRCDOC_VALUES_REF ist dabei für alle Anwendungsverbucher 6 verbindlich.
Nachdem die Referenz erstellt ist, kann ein dem Datenobjekttyp zugeordneter Belegschreiber 7 aufgerufen werden. Der zugeordnete Belegschreiber 7 wird durch Zugriff auf eine Tabelle 8 ermittelt, die im wesentlichen eine Spalte mit Datenobjekttypen und eine Spalte mit zugeordneten Belegschreibern 7 aufweist. Dabei kann ein Belegschreiber 7 mehreren Datenobjekttypen zugeordent sein, jedoch nicht umgekehrt.
Datenobjekttypen, deren Verbuchung nicht belegt zu werden braucht, können entweder in der Tabelle 8 nicht aufgeführt oder einem Belegschreiber 7 zugeordnet sein, der keinen Beleg erstellt.
Ferner kann eine Customizing-Tabelle für weitere datenbanknutzerseitige Einstellungen vorgesehen sein. Die Customizing-Tabelle wird dabei vorzugsweise in der Anwendungsschicht 1 ausgewertet, bevor die Tabelle 8 zwecks Zuordnung eines Belegschreibers 7 ausgewertet wird. Die Customizing-Tabelle hat beispielsweise folgenden vereinfachten Aufbau:
Hierbei ist für eine Datenkennung MANDT 001, mit der Daten einem bestimmten Bereich, hier dem Mandanten 001, zugeordnet sind, und für verschiedene Datenobjekttypen, die hier beispielhaft mit den Differenzierungsparametern Infotyp INFTY und Subtyp SUBTY klassifiziert sind, in der Spalte CDOC_ACTIVE angegeben, ob die Belegschreibung aktiviert (+) oder deaktiviert (–) ist, wobei * ein Platzhalter für alle Typen ist. Weitere Differenzierungsparameter können je nach Anwendungsfall verwendet werden.
Die Belegschreiber 7 sind hier als ABAP-Klasse implementiert, umfassen eine Schnittstelle 9 sowie wenigstens eine Methode 10 und legen für den jeweiligen Belegobjekttyp fest, welche Belege mit welchen Informationen in welcher Form dauerhaft abzulegen sind.
Die Schnittstelle 9 ist flexibel, d.h. es werden keine Objekte oder Variablen sondern lediglich wie vorstehend beschrieben eine Referenz darauf übergeben. Die Schnittstelle 9 ist auch dynamisch und implementiert Methoden für die Entgegennahme der Information aus der Anwendungsschicht 1, für die Ermittlung des der Information zugehörigen Datenobjekttyps, für das Aufbereiten von Belegobjektdaten mit Information über das zu verbuchende Datenobjekt 4 und die Verbuchung und ggf. weitere Daten und für den Aufruf eines Belegverbuchers 11 zur Erzeugung und dauerhaften Ablage eines Änderungsbelegs auf Basis der Belegobjektdaten beispielsweise in der dem Datenobjekt 4 entsprechenden Datenbank 5, einer besonderen Datenbank oder auch in Form eines Ausdrucks od.dgl.
Die im Belegschreiber 7 implementierten Methoden 10 können neben den Methoden der Schnittstelle 9 Methoden für den Aufbau von Parametertabellen für die Belegobjekte enthalten. Dabei ist jedem Belegobjekt eine Parametertabelle für eine Datenübergabe an den Belegverbucher 11 zugeordnet, wobei der Aufruf generisch je nach Belegobjekt in Form des ABAP-Statements CALL FUNCTION func parameter_tables erfolgt. Die Parametertabellen müssen hierbei die richtigen Formalparameter des zu aufzurufenden Belegverbuchers 11 enthalten. Ferner können eine Methode 10 zur Erzeugung eines Schlüssels, der wesentliche Informationen zwecks schneller Suche zusammenfaßt, und zweckmäßigerweise eine Methode 10 zur Überprüfung, ob der Belegschreiber 7 tatsächlich für den Datenobjekttyp des übergebenen Datenobjekts 4 zuständig ist, vorgesehen sein, so daß eine Fehlzuordnung in der Tabelle 8 erkannt wird.
Zweckmäßigerweise ist als Default-Lösung für die Belegschreiber 7 eine Basis-ABAP-Klasse vorgesehen, die für einen Großteil der Datenobjekttypen verwendbar ist. Die Basis-ABAP-Klasse enthält zweckmäßigerweise mehrere verschiedene Methoden für verschiedene Datenobjekttypen. Sie generiert aus der in Form einer Referenz übergebenen Information entsprechende Belegobjektdaten und gegebenenfalls zugehörige Parametertabellen und stellt Methoden zum Aufrufen eines jeweils geeigneten Belegverbuchers 11 zur Verfügung.
Auf Basis dieser Basis-ABAP-Klasse sind spezielle ABAP-Klassen erzeugbar, die Besonderheiten eines jeweiligen Datenobjekttyps berücksichtigen. Die speziellen ABAP-Klassen erben dabei von der Basis-ABAP-Klasse die Schnittstelle 9 und die Methoden 10, wobei zusätzliche Methoden 10 definiert und/oder die geerbten Methoden 10 entsprechend den Anforderungen überdefiniert werden können.
In der Anwendungsebene 1 kann ferner ein Verwaltungsmodul 12 zum Verwalten und Erzeugen der Instanzen der die Belegschreiber 6 bildenden ABAP-Klassen und gegebenenfalls zum Pflegen der Tabelle 8 und/oder der Customizing-Tabelle vorgesehen sein. Das Verwaltungsmodul 12 kann von einem entsprechend berechtigten Benutzer des Datenbanksystems verwendet werden. Im Verwaltungsmodul 12 sind zweckmäßigerweise auch die zentrale Metohoden gekapselt, die von Anwendungen, Anwendungsverbuchern, Belegschreibern usw. benutzt werden, indem sie dort aufgerufen werden, z.B. Methoden für den Aufbau von Parametertabellen für den generischen Aufruf der Belegverbucher 11, Methoden zum Erkennen der für alle Belegverbucher 11 und/oder Belegschreiber 7 einheitlich geltenden Parameter wie TCODE, UTIME, UDATE etc.

Claims

Computergestütztes Datenbanksystem mit einer Anwendungsschicht (1), in der unabhängig voneinander Anwendungen (3) zum Verbuchen von Datenobjekten (4) verschiedener Datenobjekttypen in eine der jeweiligen Anwendung (3) zugeordnete Datenbank (5) ausführbar sind, dadurch gekennzeichnet, daß eine gegenüber der Anwendungsschicht (1) gekapselte Belegschicht (2), in der eine Anzahl von Belegschreibern (7) mit jeweils einer dynamischen Schnittstelle (9) implementiert ist, eine Tabelle (8), in der einem Datenobjekttyp jeweils ein Belegschreiber (7) zugeordnet ist, wobei die jeweils angesprochene Anwendung (3) der Anwendungsschicht (1) in Reaktion auf einen Verbuchungsvorgang Information über das zu verbuchende Datenobjekt (4) sowie über die Verbuchung in Form einer Referenz vorgegebener Struktur erzeugt und der über die Tabelle (8) zugeordnete Belegschreiber (7) zum Zugriff auf die Referenz und damit auf die Information über die Schnittstelle (9) ausgestaltet ist, und ein Belegverbucher (11) zum dauerhaften Ablegen von durch einen Belegschreiber (7) übergebenen Belegobjektdaten mit Information über das zu verbuchende Datenobjekt (4) sowie über die Verbuchung vorgesehen sind.
Datenbanksystem nach Anspruch 1, dadurch gekennzeichnet, daß die Belegschreiber (7) die gleiche Schnittstelle (9) aufweisen.
Datenbanksystem nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß der Belegverbucher (11) zum Erzeugen und Ablegen eines Änderungsbelegs aus wenigstens einem Teil der Belegobjektdaten ausgestaltet ist.
Datenbanksystem nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß eine der Tabelle (8) vorgeschaltete Customizing-Tabelle vorgesehen ist, in der die Belegschreibung für verschiedene Datenobjekttypen aktivierbar ist.
Datenbanksystem nach Anspruch 4, dadurch gekennzeichnet, daß die Customizing-Tabelle Differenzierungsparameter enthält.
Datenbanksystem nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, daß ein Verwaltungsmodul (12) in der Anwendungsschicht (1) zum Erstellen, Ändern oder Löschen eines Tabelleneintrags vorgesehen ist.
Datenbanksystem nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, daß der Belegschreiber (7) als ABAP-Klasse mit Methoden (10) und einer Schnittstelle (9) implementiert ist.
Datenbanksystem nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, daß verschiedene, von einem Standard-Belegschreiber für einen Standard-Datenobjekttyp abgeleitete Belegschreiber (7) vorgesehen sind, die wenigstens eine seiner Methoden (10) und/oder seine Schnittstelle (9) erben.
Datenbanksystem nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, daß die Belegschreiber (7) im Betrieb des Datenbanksystems erstell- oder änderbar sind.
Datenbanksystem nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, daß die Information das Datenobjekt (4) vor der Verbuchung, das Datenobjekt (4) nach der Verbuchung, die Verbuchungszeit und die Kennung des veranlassenden Benutzers oder Prozesses umfaßt.
Verfahren zum Betrieb eines computergestützten Datenbanksystems mit einer Anwendungsschicht (1), in der unabhängig voneinander Anwendungen (3) ausführbar sind, die Datenobjekte (4) verschiedener Datenobjekttypen in eine der jeweiligen Anwendung (3) zugeordnete Datenbank (5) verbuchen, dadurch gekennzeichnet, daß die jeweils angesprochene Anwendung (3) der Anwendungsschicht (1) in Reaktion auf einen Verbuchungsvorgang Information über das zu verbuchende Datenobjekt (4) sowie über die Verbuchung in Form einer Referenz vorgegebener Struktur erzeugt, einen dem Datenobjekttyp mittels einer Tabelle (8) zugeordneten Belegschreiber (7) einer Anzahl von in einer gegenüber der Anwendungsschicht (1) gekapselten Belegschicht (2) implementierten Belegschreibern (7) mit einer dynamischen Schnittstelle (9) aufruft, der Belegschreiber (7) über die Schnittstelle (9) auf die Referenz und damit auf die Information zugreift und Belegobjektdaten mit Information über das zu verbuchende Datenobjekt (4) sowie über die Verbuchung zum dauerhaften Ablegen an einen Belegverbucher (11) übergibt.
Verfahren nach Anspruch 11, dadurch gekennzeichnet, daß die Belegschreiber (7) die gleiche Schnittstelle (9) verwenden.
Verfahren nach Anspruch 11 oder 12, dadurch gekennzeichnet, daß der Belegverbucher (11) aus wenigstens einem Teil der Belegobjektdaten einen Änderungsbeleg erzeugt und diesen ablegt.
Verfahren nach einem der Ansprüche 11 bis 13, dadurch gekennzeichnet, daß vor dem Auswerten der Tabelle (8) eine Customizing-Tabelle ausgewertet wird, in der die Belegschreibung für verschiedene Datenobjekttypen aktivierbar ist.
Verfahren nach Anspruch 14, dadurch gekennzeichnet, daß die Customizing-Tabelle Differenzierungsparameter enthält.
Verfahren nach einem der Ansprüche 11 bis 15, dadurch gekennzeichnet, daß ein Tabelleneintrag durch ein Verwaltungsmodul (12) in der Anwendungsschicht (1) erstellt, geändert oder gelöscht wird.
Verfahren nach einem der Ansprüche 11 bis 16, dadurch gekennzeichnet, daß der Belegschreiber (7) als ABAP-Klasse mit Methoden (10) und einer Schnittstelle (9) implementiert wird.
Verfahren nach einem der Ansprüche 11 bis 17, dadurch gekennzeichnet, daß verschiedene Belegschreiber (7) verwendet werden, die von einem Standard-Belegschreiber für einen Standard-Datenobjekttyp abgeleitet sind und wenigstens eine seiner Methoden (10) und/oder seine Schnittstelle (9) erben.
Verfahren nach einem der Ansprüche 11 bis 18, dadurch gekennzeichnet, daß ein Belegschreiber (7) im Betrieb des Datenbanksystems erstellt oder geändert wird.
Verfahren nach einem der Ansprüche 11 bis 19, dadurch gekennzeichnet, daß als Information das Datenobjekt (4) vor der Verbuchung, das Datenobjekt (4) nach der Verbuchung, die Verbuchungszeit und die Kennung des veranlassenden Benutzers oder Prozesses verwendet werden.