Datenverarbeitungseinrichtunq und Verfahren zum Verarbeiten von Daten
Die vorliegende Erfindung betrifft eine Datenverarbeitungseinrichtung mit im- plementierten Datenverarbeitungsprozessen sowie ein Verfahren zum Verarbeiten von Daten durch einen oder mehrere Datenverarbeitungsprozesse.
Datenverarbeitungseinrichtungen mit darin implementierten Datenverarbeitungsprozessen zur Verarbeitung von Daten, und insbesondere automatisiert arbeitende Datenverarbeitungseinrichtungen, sind bekannt. Bei solchen Datenverarbeitungseinrichtungen steuert eine Folge einzelner Kalkulationsanweisungen oder binärer Maschinenbefehle den Betrieb der Datenverarbeitungseinrichtung. Eine Gesamtheit einzelner Kalkulationsanweisungen wird als Computerprogramm oder kurz Programm bezeichnet. Zum Erstellen eines Computerprogramms existieren verschiedenste Programmiersprachen, welche die Formulierung der Folge einzelner Maschinenbefehle in einer für den Menschen verständlichen Form erlauben, wobei ein in der Programmiersprache erstelltes Programm auch als Quellcode bezeichnet wird. Ein mittels einer Programmiersprache in einer für den Menschen verständlichen Form erstell- tes Programm muss nun in ein für die Datenverarbeitungseinrichtung lesbares binäres Maschinenprogramm umgewandelt werden, damit diese die Folge einzelner Maschinenbefehle ausführen kann. Für diese Umwandlung existieren wiederum spezielle Computerprogramme wie zum Beispiel Compiler oder Interpreter. Ein Compiler wandelt einen Quellcode in ein binäres Maschinen- programm um und speichert dieses ab, während ein Interpreter den Quellcode einliest, in binäre Maschinenbefehle umwandelt und die Maschinenbefehle unmittelbar ausführt, ohne sie zu speichern.
Zum Implementieren eines Datenverarbeitungsprozesses in einer Datenverar- beitungseinrichtung mittels eines Computerprogramms ist es daher bekannt, zunächst mittels einer Programmiersprache einen Quellcode des Datenverarbeitungsprozesses als Folge von Kalkulationsanweisungen zu erstellen. Dieser ist anschließend mit einem Compiler in ein binäres Maschinenprogramm
umzuwandeln, was gemeinhin auch als Kompilieren bezeichnet wird, und das binäre Maschinenprogramm muss dann in der Datenverarbeitungseinrichtung implementiert werden. Alternativ dazu kann der Quellcode direkt in der Datenverarbeitungseinrichtung implementiert werden, sofern ein Interpreter zum Analysieren und Ausführen des Quellcodes in der Datenverarbeitungseinrichtung vorgesehen ist. Beim Implementieren werden im ersten Fall das binäre Maschinenprogramm und im zweiten Fall der Quellcode in einem lokalen Speicher der Datenverarbeitungseinrichtung gespeichert, auf den lesend zugegriffen werden kann.
Ein in einer Datenverarbeitungseinrichtung implementierter Datenverarbei- tungsprozess kann in der Regel nur mit einem gewissen Aufwand geändert werden. Hierfür ist es zunächst notwendig, den Quellcode entsprechend abzuändern. Ist der Datenverarbeitungsprozess mittels eines binären Maschi- nenprogramms in der Datenverarbeitungseinrichtung implementiert, so muss bei einer erfolgten Änderung der komplette geänderte Quellcode kompiliert und in den Speicher der Datenverarbeitungseinrichtung übertragen werden. Sofern die Datenverarbeitungseinrichtung über einen Interpreter verfügt, kann auf ein Kompilieren des Quellcodes zwar verzichtet werden, nichtsdestotrotz ist es aber auch in diesem Falle notwendig, den kompletten geänderten Quellcode in den Speicher der Datenverarbeitungseinrichtung zu übertragen. Insbesondere dann, wenn von der Gesamtzahl der Kalkulationsanweisungen eines Quellcodes nur ein geringer Teil zu ändern ist oder wenn im Verhältnis zur Gesamtzahl der Kalkulationsanweisungen nur wenige Kalkulationsanwei- sungen des Quellcodes geändert werden oder nur wenige Kalkulationsanweisungen zum Quellcode hinzugefügt oder aus diesem entfernt werden, ist es von Nachteil, wenn bei jeder Änderung eines Datenverarbeitungsprozesses stets der gesamte Quellcode kompiliert und der gesamte kompilierte bzw. stets der gesamte unkompilierte Quellcode in den Speicher der Datenverar- beitungseinrichtung übertragen werden muss, da bei jeder Übertragung erhebliche Datenmengen anfallen können und unnötig viel Zeit für die Übertragung aufzuwenden ist. Dieser Nachteil nimmt mit der Anzahl der im Quellcode enthaltenen Kalkulationsanweisungen in der Regel zu.
Es ist daher die Aufgabe der vorliegenden Erfindung, eine Datenverarbeitungseinrichtung zum Verarbeiten von Daten durch Datenverarbeitungsprozesse, eine Vorrichtung mit einer solchen Datenverarbeitungseinrichtung, ein Verfahren zum Verarbeiten von Daten durch Datenverarbeitungsprozesse, ein Computerprogrammprodukt zum Steuern einer Datenverarbeitungseinrichtung oder Vorrichtung und ein Speichermedium mit darauf gespeichertem Computerprogrammprodukt zu schaffen, die es erlauben, implementierte Datenverarbeitungsprozesse schnell und mit möglichst geringem Aufwand zu ändern.
Diese Aufgabe wird durch eine Datenverarbeitungseinrichtung gemäß dem Anspruch 1 , eine Vorrichtung gemäß dem Anspruch 20, ein Verfahren nach Anspruch 47, ein Computerprogrammprodukt nach Anspruch 58 und ein Speichermedium nach Anspruch 59 gelöst.
Mit der vorliegenden Erfindung ist es nicht mehr länger notwendig, bei einer Änderung des Datenverarbeitungsprozesses den kompletten Quellcode zu kompilieren, bzw. das gesamte Maschinenprogramm oder den kompletten Quellcode in den Speicher der Datenverarbeitungseinrichtung zu übertragen, da bei Änderungen des Datenverarbeitungsprozesses jeweils nur eines oder wenige Datenobjekte in den Speicher der Datenverarbeitungseinrichtung zu übertragen sind. Mitunter kann eine Übertragung von Datenobjekten auch vollständig entfallen, sofern die Änderung des Datenverarbeitungsprozesses beispielsweise im Löschen einer bestimmten Sequenz von Kalkulationsanwei- sungen, also eines Datenobjekts, besteht. Da kleinere Datenmengen übertragen werden, reduziert sich der Aufwand bei Änderungen eines Datenverarbeitungsprozesses und Änderungen können schneller vorgenommen werden. Eine weitere Erhöhung der Schnelligkeit sowie eine weitere Verringerung des Aufwands bei Änderungen von Datenverarbeitungsprozessen ergibt sich aus dem Umstand, dass insbesondere bei länglichen und unübersichtlichen Quellcodes betreffende zu ändernde Kalkulationsanweisungen nicht mehr umständlich identifiziert werden müssen. Die einzelnen Datenobjekte erlauben
vielmehr einen gezielten Zugriff auf ein Datenobjekt mit der zu ändernden Sequenz von Kalkulationsanweisungen.
Bei dem erfindungsgemäßen Verfahren kann es sich insbesondere um ein computerimplementiertes Verfahren handeln, wobei das Computerprogrammprodukt für ein automatisiertes Steuern der Datenverarbeitungseinrichtung oder einer die Datenverarbeitungseinrichtung umfassenden Vorrichtung und dabei für ein automatisiertes Ausführen des Verfahrens sorgen kann.
Jeweilige Sequenzen von Kalkulationsanweisungen wenigstens zweier Datenobjekte können jeweilige Teilprozesse desselben Datenverarbeitungsprozesses oder zweier verschiedener Datenverarbeitungsprozesse sein, die zur Ausführung eines Gesamtprozesses sukzessiv auszuführen sind. Als Ergebnis des Ausführens einer ersten Sequenz von Kalkulationsanweisungen eines ersten Datenobjekts kann beispielsweise eine Identifikation ausgegeben werden, wobei die Identifikation mit der Identifikation eines zweiten Datenobjektes übereinstimmt, das eine nachfolgend auszuführende zweite Sequenz von Kalkulationsanweisungen umfasst, um nachfolgend dieses zweite Datenobjekt zu identifizieren und die zweite Sequenz von Kalkulationsanweisungen auszufüh- ren. Daneben können bei der Ausführung der ersten Sequenz von Kalkulationsanweisungen Daten erzeugt werden, die bei Ausführen der zweiten Sequenz von Kalkulationsanweisungen wenigstens zum Teil verarbeitet werden. Auf diese Weise ist bei Vorsehen entsprechender Datenobjekte die sukzessive Ausführung einer beliebigen Anzahl von Sequenzen von Kalkulationsan- Weisungen möglich. Insbesondere bedingte Verzweigungen und Schleifen, wie sie bei herkömmlichen Computerprogrammen häufig auftreten, lassen sich durch derartige sukzessiv ausführbare Sequenzen von Kalkulationsanweisungen ersetzen. Gleichwohl ist das Auftreten bedingter Verzweigungen und Schleifen jedoch auch innerhalb der Sequenz von Kalkulationsanweisun- gen eines einzigen Datenobjekts möglich. Im Allgemeinen werden aber bedingte Verzweigungen und Schleifen bevorzugt durch sukzessiv ausführbare Sequenzen von Kalkulationsanweisungen verschiedener Datenobjekte er-
setzt, da dies die Rechengeschwindigkeit der Datenverarbeitungseinrichtung wesentlich erhöht.
Andererseits kann es sich bei den Sequenzen von Kalkulationsanweisungen wenigstens zweier Datenobjekte desselben Datenverarbeitungsprozesses oder zweier verschiedener Datenverarbeitungsprozesse auch um Alternativprozesse handeln, wobei bei Ausführen des Datenverarbeitungsprozesses oder beider Datenverarbeitungsprozesse genau eine dieser Sequenzen von Kalkulationsanweisungen ausführbar ist. Ein solcher Datenverarbeitungspro- zess lässt sich beispielsweise an verschiedene Verarbeitungsmodi anpassen, wobei je nach Verarbeitungsmodus ein entsprechendes Datenobjekt identifiziert wird.
Bevorzugt liegen die Kalkulationsanweisungen wenigstens einer Sequenz von Kalkulationsanweisungen in einem zeichenkodierten Format in dem betreffenden Datenobjekt vor. Liegen die Kalkulationsanweisungen in einem zeichenkodierten Format vor, so entfällt die Notwendigkeit, den Quellcode zu kompilieren. Ferner ist damit eine vollständige Trennung von grundlegenden technischen Kalkulationsanweisungen, die als binäre Maschinenbefehle vorliegen, und Kalkulationsanweisungen, welche die logische Verarbeitung der Daten betreffen und als Parameter im zeichenkodierten Format vorliegen, möglich. Bisher notwendige Programmiertätigkeiten bei Erstellung und Wartung von Datenverarbeitungsprozessen entfallen bei einer solchen Trennung. Besonders bevorzugt liegen die Kalkulationsanweisungen im XML-Format vor, da dieses ein gängiges und verbreitetes Format ist. Dateien im XML-Format sind von den meisten Interpretern lesbar und somit plattformunabhängig.
Bei einer bevorzugten Ausführungsform der Erfindung ist wenigstens zwei Datenobjekten zweier verschiedener Datenverarbeitungsprozesse die gleiche Identifikation zugeordnet. Bei einer derartigen Ausführungsform kann insbesondere wenigstens eine vordefinierte Datenverarbeitungskategorie vorgesehen sein, wobei wenigstens eines der Datenobjekte über die ihm zugeordnete Identifikation wenigstens einer Datenverarbeitungskategorie zugewiesen ist
und die Datenverarbeitungseinrichtung ferner zum Verarbeiten von Daten unter Vorgabe einer Datenverarbeitungskategorie eingerichtet ist, wobei die Datenverarbeitungseinrichtung bei Verarbeiten von Daten mittels eines Datenverarbeitungsprozesses oder mehrerer unterschiedlicher Datenverarbeitungs- prozesse ein jeweiliges Datenobjekt nur dann identifiziert, wenn das Datenobjekt der vorgegebenen Datenverarbeitungskategorie zugewiesen ist. Die Einrichtung von Datenverarbeitungskategorien ermöglicht es, dass von den Sequenzen von Kalkulationsanweisungen mehrerer Datenobjekte, die auch von verschiedenen Datenprozessen stammen können, jeweils nur solche ausge- führt werden, die logisch zusammenhängen. Dabei kann zwischen den Datenverarbeitungskategorien eine Hierarchie in Form einer verzweigten Baumstruktur existieren, so dass beispielsweise einer Datenverarbeitungskategorie eine oder mehrere in der Hierarchie tiefer gestellte Datenverarbeitungskategorien zugewiesen sind, und jeder dieser tiefer gestellten Datenverarbeitungska- tegorien wiederum eine oder mehrere in der Hierarchie noch tiefer gestellte Datenverarbeitungskategorien zugewiesen sind, und so weiter. Mittels Datenverarbeitungskategorien lassen sich auch die von den Datenverarbeitungsprozessen zu verarbeitenden Daten kategorisieren und dafür sorgen, dass je nach vorgegebener Datenverarbeitungskategorie entsprechende Daten verar- beitet werden. Dementsprechend ist eine Datenverarbeitungseinrichtung ganz besonders bevorzugt, bei der wenigstens ein Teil der zu verarbeitenden Daten wenigstens einer Datenverarbeitungskategorie zugewiesen ist und die Datenverarbeitungseinrichtung zum Verarbeiten von Daten unter Vorgabe einer Datenverarbeitungskategorie eingerichtet ist, indem sie von den einer Datenve- rarbeitungskategorie zugewiesenen Daten wenigstens einen Teil derjenigen Daten verarbeitet, die der vorgegebenen Datenverarbeitungskategorie zugewiesen sind. Ferner ist es vorteilhaft, eine Suchfunktion vorzusehen, die bei Vorgabe einer Datenverarbeitungskategorie alle Datenobjekte und/oder Daten anzeigt, die dieser Datenverarbeitungskategorie zugewiesen sind, um einen schnellen Zugriff auf Datenobjekte und Daten einer bestimmten Datenverarbeitungskategorie zu ermöglichen.
Eine Datenverarbeitungseinrichtung gemäß der vorliegenden Erfindung kann derart eingerichtet sein, dass sie wenigstens einem Datenobjekt oder jedem Datenobjekt eine jeweils eindeutige Kennung und/oder eine weltweit eindeutige Kennung und/oder eine GUID (Globally Unique Identifier) zuweist. Dabei kann es sich bei der eindeutigen Kennung um eine Kennung handeln, die innerhalb der Vorrichtung oder innerhalb eines beliebigen gegebenen Systems, zu dem die Vorrichtung gehört, eindeutig ist. Diese kann im einfachsten Fall eine Identifikationsnummer, ein Identifikationscode oder ein einheitlicher Quellenanzeiger bzw. URL (Uniform Resource Locator) sein. Weltweit eindeu- tige Kennungen sind von verteilten Computersystemen her bekannt. So ist es insbesondere bei weltweit eindeutigen Kennungen bekannt, einzelne solcher Kennungen unter Einbeziehung von Zeitstempeln zu erzeugen. Es handelt sich dabei um Kennungen mit einer derart niedrigen Wahrscheinlichkeit für eine Koinzidenz der Kennungen, dass eine einzelne Kennung mit sehr hoher Wahrscheinlichkeit auf der ganzen Welt nur einmal vorkommt und daher als global bzw. weltweit eindeutig bezeichnet wird. Ein Beispiel für eine weltweit eindeutige Kennung sind sogenannte Globally Unique Identifier oder GUID. Mittels eindeutiger Kennungen ist eine eindeutige Adressierung und Identifizierung eines Datenobjekts innerhalb der Datenverarbeitungseinrichtung, in- nerhalb einer die Datenverarbeitungseinrichtung umfassenden Vorrichtung, innerhalb eines gegebenen die Vorrichtung umfassenden Systems oder, bei Verwendung weltweit eindeutiger Kennungen, sogar weltweit möglich. Außerdem können dadurch Datenobjekte verschiedener Vorrichtungen miteinander gemischt werden, ohne dass dabei Datenobjekte gelöscht würden.
Gemäß einer besonders bevorzugten Ausführung der Erfindung weist die Datenverarbeitungseinrichtung einen Speicher zum Speichern der Datenobjekte unter Zuweisung einer jeweiligen Validitätszeit auf, wobei die Datenverarbeitungseinrichtung eingerichtet ist, bei Überschreiben eines ersten Datenob- jekts, dem eine erste Validitätszeit zugewiesen ist, durch ein zweites Datenobjekt dem zweiten Datenobjekt eine zweite Validitätszeit zuzuweisen, die jünger ist als die erste Validitätszeit, und das zweite Datenobjekt unter Beibehaltung der Speicherung des ersten Datenobjekts und unter Zuordnung dersel-
ben Identifikation wie dem ersten Datenobjekt zu speichern, und wobei die Datenverarbeitungseinrichtung ferner zum Verarbeiten von Daten durch den Datenverarbeitungsprozess unter Vorgabe einer Identifikation sowie einer Bezugszeit eingerichtet ist, indem sie anhand der Identifikation derselben zu- geordnete Datenobjekte identifiziert, von allen identifizierten Datenobjekten, denen eine relativ zur Bezugszeit ältere Validitätszeit zugewiesen ist, dasjenige mit der jeweils jüngsten Validitätszeit auswählt, die Kalkulationsanweisungen der vom identifizierten und ausgewählten Datenobjekt umfassten Sequenz von Kalkulationsanweisungen ausführt und die Daten mit Ausführen der Kalkulationsanweisungen verarbeitet oder, sofern allen identifizierten Datenobjekten eine relativ zur Bezugszeit jüngere Validitätszeit zugewiesen ist, von einer Verarbeitung der Daten absieht. Eine ganz besonders bevorzugte Ausführung der Erfindung ist eine Datenverarbeitungseinrichtung, die bei nachfolgenden sukzessiven Überschreibungen von Datenobjekten, denen die gleiche Identifikation zugeordnet ist, ein neue Datenobjekte, jedem neuen Datenobjekt eine jeweilige Validitätszeit zuweist, die jünger ist als die Validitätszeiten aller gespeicherten Datenobjekte mit dieser Identifikation desselben Datenverarbeitungsprozesses, und das neue Datenobjekt mit der ihm zugewiesenen Validitätszeit unter Zuordnung derselben Identifikation und unter Beibehaltung der Speicherung aller Datenobjekte dieser Identifikation speichert. Bei diesen Ausführungen wird im Falle eines Überschreibens des ersten Datenobjekts durch das zweite Datenobjekt das erste Datenobjekt nicht gelöscht, vielmehr wird stattdessen die Speicherung des ersten Datenobjekts beibehalten. Ein einmal gespeichertes Datenobjekt wird auch bei beliebig vielen nachfolgenden Überschreibungen von Datenobjekten mit derselben Identifikation zu keiner Zeit gelöscht. Jeglicher Datenverlust ist somit grundsätzlich ausgeschlossen. Selbst im Falle eines irrtümlichen Überschreibens bleibt das jeweilige über- schriebene Datenobjekt physikalisch existent und geht nicht verloren. Das so überschriebene erste Datenobjekt kann auch nach dem Überschreiben jeder- zeit identifiziert werden. Dabei wird beim Identifizieren eines Datenobjekts eine Bezugszeit vorgegeben, die relativ zur zweiten Validitätszeit älter und relativ zur ersten Validitätszeit jünger ist. Zum Identifizieren des zweiten Datenobjekts wird dagegen eine Bezugszeit vorgegeben, die jünger ist als die zweite
θ
Validitätszeit. Grundsätzlich können beliebige Bezugszeiten vorgegeben werden, wobei die Bezugszeit auch jünger oder älter sein kann als alle Validitäts- zeiten aller gespeicherten Datenobjekte einer Identifikation. Im ersteren Fall wird dasjenige Datenobjekt mit der jüngsten zugewiesenen Validitätszeit iden- tifiziert, im letzteren Fall wird hingegen kein Datenobjekt identifiziert, da kein Datenobjekt vorliegt, dem eine Validitätszeit zugeordnet ist, die älter ist als die Bezugszeit. Weil bei Überschreibungen gespeicherter Datenobjekte durch neue Datenobjekte derselben Identifikation den neuen Datenobjekten Validi- tätszeiten zugewiesen werden, die jeweils jünger sind als die dem jeweiligen überschriebenen Datenobjekt zugewiesene Validitätszeit, ist für jede Bezugszeit und auch bei Vorhandensein mehrerer gespeicherter Datenobjekte der betreffenden Identifikation eindeutig definiert, welches der Datenobjekte dieser Identifikation bei Vorgabe einer Bezugszeit jeweils zu identifizieren ist.
Grundsätzlich können den Datenobjekten beliebige Validitätszeiten zugewiesen werden. Zum Beispiel kann die erste Validitätszeit einer Zeit entsprechen, die relativ zur Zeit des Speicherns des ersten Datenobjekts beliebig weit in der Vergangenheit liegt oder die relativ zur Zeit des Speicherns des ersten Datenobjekts beliebig weit in der Zukunft liegt. Insbesondere ist es möglich, dem ersten Datenobjekt eine Validitätszeit zuzuweisen, die relativ zu wenigstens einer Validitätszeit eines gespeicherten Datenobjekts der betreffenden Identifikation oder relativ zu mehreren oder allen Validitätszeiten bereits gespeicherter Datenobjekte dieser Identifikation älter ist. Entsprechend ist die zweite Validitätszeit nicht auf eine solche Zeit beschränkt, die in Bezug auf diejenige Zeit, zu der das zweite Datenobjekt gespeichert wird, in der Vergangenheit liegt oder ihr entspricht; sie kann vielmehr analog relativ zur Zeit des Speicherns des zweiten Datenobjekts beliebig weit in der Zukunft liegen. Folglich wird beim Identifizieren eines Datenobjekts einer bestimmten Identifikation, wobei beispielsweise eine Bezugszeit vorgegeben wird, die einer aktuellen Zeit entspricht, zu der die Identifikation stattfindet, ein Datenobjekt mit einer zugewiesenen Validitätszeit, die relativ zur Zeit der Identifikation in der Zukunft liegt, auch nicht ausgelesen. Unter der Annahme, dass als Bezugszeit stets die gerade aktuelle Zeit vorgegeben wird, zu der die Identifikation statt-
findet, wird ein solches Datenobjekt erst dann ausgelesen, wenn der Zugriff zu einer Zeit nach der dem Datenobjekt zugewiesenen Validitätszeit erfolgt. Wird dem zweiten Datenobjekt zum Beispiel als zweite Validitätszeit eine relativ zur Zeit des Speicherns des zweiten Datenobjekts zukünftige Zeit zugewie- sen, so wird beim Identifizieren von Datenobjekten der vorgegebenen Identifikation das zweite Datenobjekt ohne weiteres Tun anstelle des ersten Datenobjekts einfach nach Überschreiten der zweiten Validitätszeit identifiziert. Insofern erweist sich diese Ausführungsform der vorliegenden Erfindung als flexibel bei der Überschreibung gespeicherter Datenobjekte, da sie zukünftige Überschreibungen gespeicherter Datenobjekte ohne die Notwendigkeit ermöglicht, dafür irgendwelche besonderen Einrichtungen vorzusehen, die zur Messung der Zeit und zur Ausführung der Überschreibung zu einem vorgegebenen Zeitpunkt ausgelegt sind. Da bei den beschriebenen Ausführungsformen kein physikalisches Löschen überschriebener Datenobjekte stattfindet, wächst zwar das in der Datenverarbeitungseinrichtung gespeicherte Datenvolumen kontinuierlich an, doch ist dieser Umstand angesichts der Speicherkapazitäten heutiger moderner Speichervorrichtungen vernachlässigbar und wird durch den Vorteil der beliebigen Zugreifbarkeit auf überschriebene Datenobjekte und der Nachvollziehbarkeit von Überschreibungsvorgängen mehr als wieder aufgewogen.
Vorteilhafterweise ist die Datenverarbeitungseinrichtung zur automatischen Vorgabe einer Bezugszeit eingerichtet, die einer Zeit entspricht, zu der die Identifikation des Datenobjekts erfolgt, sofern eine Vorgabe für die Bezugszeit ausbleibt. Damit wird sicher gestellt, dass stets ein Datenobjekt mit einer zugewiesenen Validitätszeit identifiziert wird, die älter ist als die aktuelle Zeit, zu der die Identifizierung erfolgt, und dem von allen Datenobjekten mit zugewiesenen Validitätszeiten, die älter sind als die aktuelle Zeit des Zugriffs, die jeweils jüngste Validitätszeit zugewiesen ist.
Bei einer weiteren bevorzugten Ausführungsform wird wenigstens einem Datenobjekt oder jedem Datenobjekt ein jeweiliger Zeitpunkt des Speicherns des betreffenden Datenobjekts als Validitätszeit zugeordnet. Man erhält dadurch
eine Art historischer Speicherung der Datenobjekte, bei der die Zeit, zu der ein Datenobjekt gespeichert wurde, an dessen Validitätszeit ablesbar ist. Die Validitätszeit kann zum Beispiel sekundengenau, minutengenau, stundengenau oder tagesgenau sein. Bei sekundengenauen Validitätszeiten wird einem Datenobjekt neben dem Tagesdatum auf die Sekunde genau die Zeit als Validitätszeit zugewiesen, zu der das Datenobjekt gespeichert wurde. Entsprechend wird bei minutengenauen oder stundengenauen Validitätszeiten dem Datenobjekt neben dem Tagesdatum auf die Minute bzw. auf die Stunde genau die Zeit als Validitätszeit zugewiesen, zu der das Datenobjekt gespeichert wurde. In der Praxis genügen jedoch meist bereits tagesgenaue Validitätszeiten, bei denen dem Datenobjekt das Datum desjenigen Tages als Validitätszeit zugewiesen wird, an dem das Datenobjekt gespeichert wurde.
Grundsätzlich ist es nicht ausgeschlossen, dass zwei Datenobjekten mit glei- eher Identifikation gleiche Validitätszeiten zugewiesen werden. Insbesondere dann, wenn es sich um tagesgenaue Validitätszeiten handelt, kann es vorkommen, dass mehreren am selben Tag gespeicherten Datenobjekten derselben Identifikation gleiche Validitätszeiten zugewiesen werden. Validitätszeiten und Identifikationen allein können daher unter Umständen zur eindeutigen Adressierung oder Identifizierung von Datenobjekten ungeeignet sein. Bevorzugt wird daher auch bei Zuweisung einer Validitätszeit zu den Datenobjekten wenigstens einem Datenobjekt oder jedem Datenobjekt eine jeweils eindeutige Kennung und/oder eine weltweit eindeutige Kennung und/oder eine GUID zugewiesen. Dabei können jeweilige eindeutige Kennungen und jeweilige Va- liditätszeiten auch zu einer Leitkennung zusammengefasst sein. Mit einer Leitkennung lässt sich einerseits eindeutig festlegen, welches Datenobjekt aus einer Mehrzahl gespeicherter Datenobjekte derselben Identifikation identifiziert werden soll, indem bestimmt wird, dasjenige Datenobjekt zu identifizieren, dessen Leitkennung die jüngste Validitätszeit aufweist, andererseits kön- nen Datenobjekte über die in der Leitkennung enthaltene eindeutige Kennung darüber hinaus eindeutig adressiert werden. Weil im Falle einer Leitkennung nur eine einzige Größe für die Adressierung und die Identifizierung von Datenobjekten statt deren zwei wie bei getrennter Verwendung von Kennung und
Validitätszeit vorgesehen werden muss, reduziert sich der notwendige Verwaltungsaufwand.
Vorteilhafterweise ist die Datenverarbeitungseinrichtung ferner dazu einge- richtet, wenigstens ein vorgegebenes Datenobjekt mit einer zugewiesenen Validitätszeit durch ein drittes Datenobjekt zu ersetzen, indem sie das vorgegebene Datenobjekt löscht, das dritte Datenobjekt speichert und dem dritten Datenobjekt die zuvor dem vorgegebenen Datenobjekt zugewiesene Validitätszeit zuweist. Mittels einer derartigen Ersetzung können fehlerhaft gespei- cherte Datenobjekte korrigiert werden. Zum Beispiel kann die im zeichenkodierten Format vorliegende Sequenz von Kalkulationsanweisungen eines Datenobjektes einen Schreib- oder Tippfehler aufweisen, oder das zu speichernde Datenobjekt als solches ist fälschlicherweise mit einem anderen Datenobjekt verwechselt worden, das anstatt des richtigen Datenobjekts unter Zuwei- sung der für das richtige Datenobjekt vorgesehenen Validitätszeit gespeichert worden ist. Dann kann das fehlerhafte oder falsche Datenobjekt auf die beschriebene Weise einfach durch das richtige Datenobjekt ersetzt werden.
Bevorzugt ist der dem vorgegebenen Datenobjekt zugewiesenen Validitätszeit ein Protokoll zugeordnet und die Datenverarbeitungseinrichtung ist eingerichtet, bei Ersetzen des vorgegebenen Datenobjekts durch das dritte Datenobjekt die Ersetzung im Protokoll zu vermerken und dabei das vorgegebene Datenobjekt bzw. die von ihm umfasste Sequenz von Kalkulationsanweisungen in das Protokoll zu kopieren. Das Protokoll kann insbesondere ein zeichenko- diertes Format oder ein XML-Format aufweisen. Mit einem solchen Protokoll können alle vorgenommenen Ersetzungen des vorgegebenen Datenobjekts nachvollziehbar festgehalten werden. Ein Protokoll gibt eine schnelle und bequeme Übersicht über den historischen Verlauf erfolgter Ersetzungen von Datenobjekten, denen die betreffende Validitätszeit zugewiesen worden ist. Das Protokoll wird vorteilhaft verwendet, um im Falle von Ersetzungen gespeicherter Datenobjekte Datenverluste zu vermeiden, da bei einer Ersetzung das betreffende vorgegebene bzw. ersetzte Datenobjekt tatsächlich gelöscht wird. Weil das vorgegebene Datenobjekt in das Protokoll kopiert wird, ist es nach
der Ersetzung außerhalb des Protokolls zwar gelöscht, es tritt aber trotzdem kein Datenverlust ein, da eine Kopie des gelöschten Datenobjekts im Protokoll vorhanden ist. Insbesondere können in dem Protokoll auch jeweilige Zeiten vermerkt werden, zu denen eine Ersetzung des vorgegebenen Datenobjekts stattfand. Darüber hinaus kann auch eine Person vermerkt werden, welche die Überschreibung veranlasst hat. Ein Protokoll kann einer Validitätszeit unmittelbar mit Speichern des Datenobjekts zugeordnet werden, dem die Validitätszeit zugewiesen wird. Andererseits kann ein Protokoll auch erst bei Stattfinden der Ersetzung erzeugt und der Validitätszeit des vorgegebenen Daten- Objekts zugeordnet werden. Weil eine Zuordnung des Protokolls zur Validitätszeit des vorgegebenen Datenobjekts vorgesehen ist, wird bei einer nachfolgenden Ersetzung des dritten Datenobjekts, dem dieselbe Validitätszeit zugewiesen wird, durch ein weiteres Datenobjekt diese Ersetzung zusammen mit einer Kopie des dritten Datenobjekts im selben Protokoll wie die vorherige Ersetzung des vorgegebenen Datenobjekts vermerkt. Nachfolgende sukzessive Ersetzungen von Datenobjekten, denen diese Validitätszeit zugewiesen wird, werden ebenfalls allesamt im selben dieser Validitätszeit zugeordneten Protokoll mitsamt einer Kopie der jeweiligen ersetzten Datenobjekte vermerkt. Somit sind in ein und demselben Protokoll alle stattgefundenen Ersetzungen von Datenobjekten vermerkt, denen diejenige Validitätszeit zugewiesen wurde, die ursprünglich dem vorgegebenen Datenobjekt zugewiesen worden ist.
Wird beim Speichern eines Datenobjekts dem Datenobjekt irrtümlich eine falsche Validitätszeit zugewiesen, so lässt sich dieser Fehler durch Löschen das gespeicherten Datenobjekts mitsamt seiner Validitätszeit und erneutes Speichern des Datenobjekts mit korrekter Validitätszeit berichtigen. Sowohl das Speichern des Datenobjekts mit der falschen Validitätszeit als auch das Speichern des Datenobjekts mit der richtigen Validitätszeit kann in einem Protokoll, das wie erläutert erzeugt wird, festgehalten werden. Durch Löschen des Datenobjekts mit der falschen Validitätszeit und erneutes Speichern des Datenobjekts mit der richtigen Validitätszeit ist gewährleistet, dass zu jeder Zeit eindeutig bestimmt ist, welchem Datenobjekt relativ zur Bezugszeit die jüngste Validitätszeit zugewiesen ist.
Bei einer bevorzugten Ausführungsform der Datenverarbeitungseinrichtung weist die Datenverarbeitungseinrichtung einen Server zur Kommunikation über ein bi- oder multidirektionales Netzwerk oder über das Internet mit einer oder mehreren Komponenten einer Client/Server-Architektur auf. Eine solche Datenverarbeitungseinrichtung ist in der Lage, über beliebige Distanzen mit einzelnen Komponenten der Client/Server-Architektur zu kommunizieren, wobei Verbindungen zwischen der Datenverarbeitungseinrichtung und den einzelnen Komponenten sowie den Komponenten untereinander beliebige draht- gebundene oder drahtlose Verbindungen, wie zum Beispiel Luftschnittstellen, sein können.
Eine Datenverarbeitungseinrichtung gemäß der vorliegenden Erfindung kann Teil einer Vorrichtung sein, die ferner ein Datenbanksystem zum Speichern von Datenelementen spezifischer Attribute sowie zum Zugreifen auf gespeicherte Datenelemente umfasst, wobei das Datenbanksystem bei einem Zugriff auf ein gespeichertes Datenelement das Datenelement ausliest und das ausgelesene Datenelement als zu verarbeitende Daten an die Datenverarbeitungseinrichtung übergibt. Das Datenbanksystem umfasst im Allgemeinen ne- ben einer Datenbank, bei der es sich um den Datenbestand der gespeicherten Datenelemente handelt, eine Software zur Verwaltung der Datenbank, die Datenbankmanagementsystem genannt wird.
Analog zum bereits beschriebenen Vorgeben einer Datenverarbeitungskate- gorie kann wenigstens ein Datenelement wenigstens einer vordefinierten Datenverarbeitungskategorie zugewiesen sein und das Datenbanksystem kann eingerichtet sein, bei Vorgabe einer Datenverarbeitungskategorie nur dann auf das Datenelement zuzugreifen, wenn das Datenelement der vorgegebenen Datenverarbeitungskategorie zugewiesen ist. Das Datenbanksystem die- ser Vorrichtung kann wie beim bereits beschriebenen Speichern von Datenobjekten unter Zuweisung einer Validitätszeit zur Speicherung von Datenelementen unter Zuweisung einer jeweiligen Validitätszeit eingerichtet sein und im Falle eines Überschreibens eines ersten Datenelements eines vorgegebe-
nen Attributs, dem eine erste Validitätszeit zugewiesen ist, durch ein zweites Datenelement des vorgegebenen Attributs dem zweiten Datenelement eine zweite Validitätszeit zuweisen, die jünger ist als die erste Validitätszeit, und das zweite Datenelement unter Beibehaltung der Speicherung des ersten Da- tenelements speichern, wobei das Datenbanksystem ferner für Zugriffe auf Datenelemente des vorgegebenen Attributs unter Vorgabe einer Bezugszeit eingerichtet ist und bei einem solchen Zugriff von allen gespeicherten Datenelementen des vorgegebenen Attributs, denen eine relativ zur Bezugszeit ältere Validitätszeit zugewiesen ist, auf dasjenige mit der jeweils jüngsten Validi- tätszeit zugreift oder, sofern allen Datenelementen des vorgegebenen Attributs eine relativ zur Bezugszeit jüngere Validitätszeit zugewiesen ist, von einem Zugriff auf ein Datenelement absieht.
Aus denselben Gründen, die im Zusammenhang mit dem Ausbleiben einer Vorgabe für die Bezugszeit beim Identifizieren von Datenobjekten erläutert wurden, kann die Vorrichtung oder das Datenbanksystem bei Ausbleiben einer Vorgabe für die Bezugszeit bei einem Zugriff auf Datenelemente des vorgegebenen Attributs zur automatischen Vorgabe einer Bezugszeit eingerichtet sein, die einer Zeit entspricht, zu der der Zugriff erfolgt. Ferner kann das Da- tenbanksystem der Vorrichtung für eine historische Speicherung eingerichtet sein, indem sie wenigstens einem Datenelement oder jedem Datenelement einen jeweiligen Zeitpunkt des Speicherns des betreffenden Datenelements als Validitätszeit zuordnet. Auch die Zuweisung einer jeweils eindeutigen Kennung und/oder einer weltweit eindeutigen Kennung und/oder einer GUID zu wenigstens einem Datenelement oder jedem Datenelement kann durch das Datenbanksystem aus den bereits genannten Gründen erfolgen.
Das Datenbanksystem ist vorzugsweise eingerichtet, wenigstens ein vorgegebenes Datenelement mit einer zugewiesenen Validitätszeit durch ein drittes Datenelement zu ersetzen, indem sie das vorgegebene Datenelement löscht, das dritte Datenelement speichert und dem dritten Datenelement die zuvor dem vorgegebenen Datenelement zugewiesene Validitätszeit zuweist. Fehlerhaft gespeicherte Datenelemente werden damit auf analoge Weise korrigiert,
wie es auch bei fehlerhaft gespeicherten Datenobjekten möglich ist. Ebenso kann wie bei Datenobjekten auch der dem vorgegebenen Datenelement zugewiesenen Validitätszeit ein Protokoll zugeordnet sein und die Vorrichtung kann eingerichtet sein, die Ersetzung des vorgegebenen Datenelements durch das dritte Datenelement im Protokoll zu vermerken und dabei das vorgegebene Datenelement in das Protokoll zu kopieren. Das Protokoll kann ein zeichenkodiertes Format oder ein XML-Format aufweisen.
Bevorzugt bilden wenigstens ein Datenelement und die ihm zugewiesene Va- liditätszeit oder mehrere Datenelemente und die ihnen zugewiesenen Validi- tätszeiten wenigstens eine Datengruppe. Wenigstens einem oder mehreren Datenelementen oder einer oder mehreren Datengruppen können eine jeweilige eindeutige Kennung oder eine jeweilige weltweit eindeutige Kennung oder eine jeweilige GUID zugeordnet sein. Mit Datengruppen lassen sich zum Bei- spiel Datenelemente mit Attributen, zwischen denen eine logische Beziehung besteht, gruppieren und einheitlich verwalten. Beispielsweise kann ein Daten- verarbeitungsprozess wiederholt auf Datenelemente eines ersten Attributs sowie auf Datenelemente eines zweiten Attributs zugreifen. In einem solchen Fall ist es vorteilhaft, die Datenelemente des ersten Attributs und die Daten- elemente des zweiten Attributs zu einer Datengruppe zusammenzufassen und sie als Datengruppe einheitlich zu verwalten. Einer Datengruppe als solcher kann zu deren Adressierung wiederum eine eindeutige Kennung oder eine weltweit eindeutige Kennung oder eine GUID zugeordnet werden, damit Datengruppen zwischen Anwendungen oder Modulen geladen werden können, ohne sich gegenseitig zu überschreiben. Ferner kann wenigstens eines der Datenelemente wenigstens einer Datengruppe eine eindeutige Kennung oder eine weltweit eindeutige Kennung oder eine GUID eines anderen Datenelements oder einer anderen Datengruppe sein, mit dem bzw. mit der eine logische Relation der Datengruppe besteht, so dass die Kennung des anderen Datenelements oder Datengruppe in der Datengruppe wie ein gewöhnliches Datenelement behandelt wird.
Darüber hinaus ist es möglich, wenigstens einem Datenelement und/oder wenigstens einer Datengruppe wenigstens einen Indikator zuzuweisen. Ein Indikator kann beispielsweise eine einfache binäre Variable sein, die zur Kennzeichnung bestimmter Zustände benutzt wird. Ein Indikator kann ferner ge- setzt, gelöscht oder ausgelesen werden. Beispielsweise kann vorgesehen sein, ein Datenelement zu löschen bzw. physikalisch zu löschen, sofern wenigstens einer der ihm zugewiesenen Indikatoren einen vorgegebenen Wert annimmt. Andererseits kann, wenn der Indikator einen bestimmten Wert annimmt, anstatt das betreffende Datenelement tatsächlich zu löschen dieses auch nur als gelöscht behandelt werden, obwohl ein tatsächliches Löschen desselben nicht stattfindet. Wenigstens einer der Indikatoren kann für Zugriffsrechte bestimmend sein. Zum Beispiel kann ein Indikator festlegen, ob ein Datenelement oder eine Datengruppe öffentlich zugänglich ist oder nicht. Weiter können Indikatoren die Zugehörigkeit des Datenelements oder der Da- tengruppe zur Vorrichtung oder einer Komponente derselben wie zum Beispiel dem Datenbanksystem anzeigen. Bei einem Indikator kann es sich auch um einen solchen handeln, der angibt, ob das betreffende Datenelement oder die Datengruppe aktuell von einer Applikation benutzt wird.
Bei einer Ausführungsform der Erfindung ist der Indikator wenigstens eines Datenelements oder einer Datengruppe jedoch eine Validitätsendzeit, wobei das Datenbanksystem nach Überschreiten der Validitätsendzeit von einem Auslesen dieses Datenelements oder dieser Datengruppe absieht. Damit ist es möglich, jeder Datengruppe oder jedem Datenelement eines vorgegebenen Attributs eine Art Gültigkeitsdauer vorzugeben, während der ein Auslesen der Datengruppe oder Datenelements bei Zugriffen auf Datengruppen oder Datenelemente dieses Attributs möglich ist, wobei nach Ablauf der Gültigkeitsdauer bzw. nach der Validitätsendzeit ein Auslesen nicht mehr möglich ist. Insbesondere zeitkritische Be- oder Verarbeitungen von Datenelementen oder Datengruppen lassen sich mit einem solchen Indikator regeln. Für Datenelemente oder Datengruppen, die zum Beispiel in periodischen Abständen be- oder verarbeitet werden, kann der Indikator auch eine Periodendauer sein. Entsprechend kann ähnlich der Validitätszeit eines Datenelements wenigstens
ein Indikator wenigstens einer Datengruppe eine Validitätsstartzeit sein, die angibt, ab wann die betreffende Datengruppe für Be- oder Verarbeitungen freigegeben ist.
Vorteilhafterweise weist die Vorrichtung wenigstens eine vererbbare Musterdatengruppe mit vorgegebenen Datenelementen auf, wobei die Vorrichtung eingerichtet ist, für eine durch Vererbung der Musterdatengruppe erzeugte Datengruppe einen spezifischen Indikator vorzusehen, über den sich für die so erzeugte Datengruppe ein Bezug zu der Musterdatengruppe herstellen lässt. Eine solche Musterdatengruppe kann für Datengruppen vorgesehen sein, die in derselben Form wiederholt erzeugt werden. Dann kann anstatt jedesmal eine neue Datengruppe vollständig neu zu generieren die entsprechende Musterdatengruppe einfach vererbt werden, wobei die in der vererbten Musterdatengruppe enthaltenen Datenelemente durch entsprechende Da- tenelemente der zu erzeugenden Datengruppe überschrieben werden, um dadurch ein Datengruppe mit den gewünschten Datenelementen zu erhalten. Dabei wird für die durch Vererbung der Musterdatengruppe erzeugte Datengruppe ein spezifischer Indikator vorgesehen, über den sich jederzeit für die so erzeugte Datengruppe ein Bezug zu der jeweiligen Musterdatengruppe, aus der eine Datengruppe hervorgegangen ist, herstellen lässt. Änderungen in der Musterdatengruppe lassen sich dann über diesen Indikator unmittelbar auf die aus der Musterdatengruppe hervorgegangene Datengruppe entsprechend übertragen.
Im Allgemeinen können in einem flüchtigen Arbeitsspeicher mit kurzen Zugriffszeiten enthaltene Daten schneller bearbeitet und gelesen werden als im Permanentspeicher einer Datenbank mit wesentlich längeren Zugriffszeiten gespeicherte Daten. Aus diesem Grund umfasst das Datenbanksystem der erfindungsgemäßen Vorrichtung bevorzugt wenigstens eine Datenbank zum Speichern von Datenelementen und/oder Datengruppen sowie wenigstens einen Arbeitsspeicher und ist eingerichtet, gespeicherte Datenelemente und/oder Datengruppen aus der Datenbank auszulesen und in den Arbeitsspeicher zu schreiben und im Falle einer im Arbeitsspeicher stattfindenden
Ersetzung des ausgelesenen Datenelements und/oder eines von der ausgelesenen Datengruppe umfassten Datenelements durch ein viertes Datenelement das zugehörige in der Datenbank gespeicherte Datenelement in der Datenbank durch das vierte Datenelement zu überschreiben. Bei einer solchen Vor- richtung ist gewährleistet, dass im Falle unvorhergesehener Störungen während der Bearbeitung der Datengruppe im Arbeitsspeicher, wie zum Beispiel einem Systemabsturz, bis dahin erfolgte Änderungen der im Arbeitsspeicher bearbeiteten Datenelemente oder Datengruppen nicht verloren gehen und bei einem Neustart rasch wieder im Arbeitsspeicher verfügbar sind. Dabei wird vorzugsweise die ausgelesene Datengruppe und/oder das Datenelement in ein zeichenkodiertes Format oder ein XML-Format umgewandelt oder binär serialisiert und die so umgewandelte bzw. serialisierte Datengruppe und/oder das Datenelement wird in den Arbeitsspeicher geschrieben, um bestimmten Datenverarbeitungsprozessen oder Anwendungsprogrammen eine Bearbei- tung oder ein Lesen der Datengruppe und/oder des Datenelements zu ermöglichen.
Die Vorrichtung kann in jedem beliebigen Computer oder Computersystem implementiert sein. Sie ist insbesondere nicht auf einen einzigen Computer beschränkt, sondern kann auch wenigstens zwei oder mehr miteinander verbundene Computer umfassen. Diese können durch ein bi- oder multidirektio- nales Netzwerk oder über das Internet miteinander verbunden sein. Insbesondere kann die Vorrichtung eine Client/Server-Architektur aufweisen. Die Datenverarbeitungseinrichtung und das Datenbanksystem können jeweils ei- nen Server aufweisen, die zum Beispiel synchron oder asynchron miteinander kommunizieren können. Bei der synchronen Kommunikation wartet ein Sender beim Senden von Daten auf eine Antwort des Empfängers und ist dabei während der Zeit des Wartens blockiert, während bei der asynchronen Kommunikation das Senden und Empfangen von Daten zeitlich versetzt und ohne War- ten auf eine Antwort des Empfängers stattfinden. Um eine voneinander unabhängige Arbeitsweise zu gewährleisten, wird eine asynchrone Kommunikation zwischen Datenverarbeitungseinrichtung und Datenbanksystem bevorzugt. Dabei kann zwischen den Servern eine asynchrone Kommunikation auch
dann eingerichtet sein, wenn es sich bei den Servern um solche handelt, die von der technischen Seite her ausschließlich für eine synchrone Kommunikation ausgelegt sind, indem vorgesehen wird, dass die Server beim Empfang von Daten unmittelbar eine Empfangsbestätigung an den Sender schicken und nach Beendigung eines durch den Empfang der Daten gestarteten Prozesses mit dem Sender erneut Verbindung aufnehmen. Beim Server des Datenbanksystems kann es sich entweder um ein Element des Datenbankmanagementsystems handeln oder der Server des Datenbanksystems kann mit dem Datenbankmanagementsystem identisch sein.
Als Schnittstelle zwischen der Vorrichtung und Benutzern derselben kann die Vorrichtung über eine Benutzerschnittstelle verfügen. Auch die Benutzerschnittstelle kann einen Server oder Benutzerschnittstellenserver aufweisen, der sich physikalisch beliebig weit der Datenverarbeitungseinrichtung und dem Datenbanksystem entfernt befinden kann. Es kann eine Kommunikation zwischen dem Benutzerschnittstellenserver mit entweder dem Server der Datenverarbeitungseinrichtung und/oder dem Server des Datenbanksystems vorgesehen sein. Die Kommunikation zwischen den Servern kann grundsätzlich synchron oder asynchron sein, es wird aber auch hier eine asynchrone Kommunikation aus Gründen der unabhängigen Arbeitsweise von Benutzerschnittstelle, Datenverarbeitungseinrichtung und Datenbanksystem bevorzugt. Ferner kann der Benutzerschnittstellenserver zur Kommunikation mit einem Client eingerichtet sein. Die Kommunikation zwischen Benutzerschnittstellenserver und Client kann synchron oder asynchron erfolgen. Benutzer können damit mittels des Clients über beliebige Distanzen eine Verbindung mit der Benutzerschnittstelle herstellen und eine Anfrage an die Benutzerschnittstelle übertragen. Teil der Anfrage kann die Identifikation eines Datenobjektes sein sowie eventuelle durch den Datenverarbeitungsprozess, dem das Datenobjekt angehört, zu verarbeitende Daten. Über den Benutzerschnittstellenserver werden die Anfrage und die Daten an die Datenverarbeitungseinrichtung übertragen. Sofern für die Verarbeitung der Daten weitere im Datenbanksystem gespeicherte Daten notwendig sind, werden diese von der Datenverarbeitungseinrichtung vom Datenbanksystem angefordert, welches die angeforder-
ten Daten aus der Datenbank ausliest und an die Datenverarbeitungseinrichtung überträgt. Die Daten werden daraufhin nach Identifikation des Datenobjektes auf die beschriebene Weise verarbeitet. Ein eventuelles Ergebnis dieser Verarbeitung wird abhängig von den Kalkulationsanweisungen des Daten- Objektes entweder in einem Speicher der Datenverarbeitungseinrichtung gespeichert und/oder an die Benutzerschnittstelle und von dieser an den Client übertragen.
Die Erfindung wird nachfolgenden anhand von bevorzugten Ausführungsbei- spielen unter Zuhilfenahme von Zeichnungen näher erläutert. Es zeigen:
Figur 1 eine Vorrichtung mit einer Datenverarbeitungseinrichtung;
Figur 2 eine Datenverarbeitungseinrichtung;
Figur 3 eine Baumstruktur hierarchischer Datenverarbeitungskategorien;
Figur 4 ein Flussdiagramm des erfindungsgemäßen Verfahrens;
Figur 5a) ein Datenobjekt;
Figur 5b) Datenobjekte nach erfolgter Überschreibung des Datenobjekts der Figur 5a);
Figur 5c) Datenobjekte nach einer weiteren Überschreibung eines der Datenobjekte der Figur 5b);
Figur 5d) Datenobjekte nach einer Ersetzung eines der Datenobjekte der Figur 5c);
Figur 6 ein Datenbanksystem;
Figur 7a) ein Datenelement;
Figur 7b) Datenelemente nach erfolgter Überschreibung des Datenelements der Figur 7a);
Figur 7c) Datenelemente nach einer weiteren Überschreibung eines der Datenelemente der Figur 7b);
Figur 7d) Datenelemente nach einer Ersetzung eines der Datenelemente der Figur 7c);
Figur 8 ein Datenelement mit Indikatoren;
Figur 9 eine Datengruppe; und
Figur 10 die Datengruppe der Figur 9 nach Überschreiben eines Datenelements.
In der Figur 1 ist eine grundlegende Ausführung einer Vorrichtung 1 mit einer Datenverarbeitungseinrichtung 2, einem Datenbanksystem 3 und einer Benut- zerschnittstelle 4 zu sehen. Die Vorrichtung 1 weist eine Client/Server- Architektur auf, bei der Datenverarbeitungseinrichtung 2, Datenbanksystem 3 und Benutzerschnittstelle 4 jeweils auf verschiedenen, räumlich voneinander beabstandeten Computern implementiert sind, wobei die Datenverarbeitungseinrichtung 2 einen Server 5, das Datenbanksystem 3 einen Datenbanksys- temserver 6 und die Benutzerschnittstelle 4 einen Benutzerschnittstellenserver 7 aufweist. Server 5 ist eingerichtet, um sowohl mit dem Benutzerschnittstellenserver 7 als auch mit dem Datenbanksystemserver 6 zu kommunizieren. Darüber hinaus ist eine Kommunikation zwischen dem Datenbanksystemserver 6 und dem Benutzerschnittstellenserver 7 vorgesehen. Die Kom- munikation zwischen den drei Servern 5, 6 und 7 verläuft asynchron. Der Benutzerschnittstellenserver 7 kann ferner über eine synchron arbeitende Kommunikationsverbindung mit einem Client 8 kommunizieren.
In der Datenverarbeitungseinrichtung 2 sind verschiedene Datenverarbeitungsprozesse zum Verarbeiten von Daten implementiert. Mittels der Datenverarbeitungsprozesse werden vordefinierte Abfolgen von Aktivitäten in einer Organisation realisiert, die gemeinhin als Arbeitsabläufe oder Workflows be- zeichnet werden. Figur 2 zeigt eine schematische Darstellung der Datenverarbeitungseinrichtung 2, die neben dem Server 5 ein Rechenwerk oder einen Prozessor 9 und einen Speicher 10 aufweist. Beispielhaft ist in Figur 2 eine erste Gruppe mehrerer im Speicher 10 gespeicherter Datenobjekte 11 gezeigt, durch die ein erster Datenverarbeitungsprozess 12 in der Datenverar- beitungseinrichtung 2 implementiert ist, und es ist eine zweite Gruppe mehrerer Datenobjekte 13 gezeigt, durch die ein zweiter Datenverarbeitungsprozess 14 in der Datenverarbeitungseinrichtung 2 implementiert ist. Jedes der Datenobjekte 11 , 13 umfasst eine jeweilige Sequenz von Kalkulationsanweisungen. Ferner liegt jedes der Datenobjekte 11 , 13 im XML-Format vor, d.h. die Se- quenzen von Kalkulationsanweisungen liegen in zeichenkodierter Form vor. Sie sind insbesondere nicht kompiliert und liegen nicht als binäre Maschinenbefehle oder binäres Maschinenprogramm vor, sondern als Quellcode. Darüber hinaus ist jedem einzelnen der Datenobjekte 11 der ersten Gruppe eine jeweilige GUID 15 zugeordnet, jedem einzelnen der Datenobjekte 13 der zweiten Gruppe ist eine GUID 16 zugeordnet, und es ist auch jedem einzelnen der Datenverarbeitungsprozesse 12, 14 eine jeweilige GUID 17, 18 zugeordnet, und zwar dem ersten Datenverarbeitungsprozess 12 die GUID 17 und dem zweiten Datenverarbeitungsprozess 14 die GUID 18. Neben den gezeigten Datenverarbeitungsprozessen 12, 14 sind in der Daten verarbeitungs- einrichtung 2 weitere, in der Figur 2 nicht zu sehende, Datenverarbeitungsprozesse durch jeweilige Gruppen von Datenobjekten implementiert, die im Speicher 10 gespeichert sind. Jedem einzelnen der Datenobjekte 11 , 13 jeder Gruppe ist eine jeweilige Identifikation zugeordnet, bei der es sich um eine einfache Zeichenkette handelt. Dabei ist innerhalb der Gruppe von Datenob- jekten 11, 13 eines jeweiligen der Datenverarbeitungsprozesse 12, 14 die Zuordnung zwischen Identifikationen und Datenobjekten 11 , 13 jeweils eindeutig, d.h. allen Datenobjekten 11 , 13 desselben Datenverarbeitungsprozesses 12, 14 sind jeweils verschiedene Identifikationen eindeutig zugeordnet. Es ist je-
doch möglich, dass einem Datenobjekt 11 aus der ersten Gruppe dieselbe Identifikation zugeordnet ist wie einem Datenobjekt 13 aus der zweiten Gruppe oder beliebig vielen Datenobjekten aus jeweiligen anderen Gruppen von Datenobjekten.
Ein einfaches Beispiel soll diesen Sachverhalt verdeutlichen.
Gemäß dem Beispiel wird die Vorrichtung 1 in der Personalverwaltung einer Organisation mit Mitarbeitern in zwei verschiedenen Bundesländern BL1 und BL2 eingesetzt. Jeder dieser Mitarbeiter ist nach genau einem von drei verschiedenen Tarifverträgen TV1 , TV2 und TV3 zu entlohnen, wobei der Mitarbeiter entweder Angestellter oder Praktikant sein kann. Mittels des Datenverarbeitungsprozesses 12 soll nun für einen beliebigen der Mitarbeiter die Differenz aus dessen Brutto- und Nettolohn berechnet werden. Abhängig vom Bundesland, in dem der Mitarbeiter beschäftigt ist, vom für den Mitarbeiter geltenden Tarifvertrag und vom Status des Mitarbeiters, also davon, ob der Mitarbeiter Angestellter oder Praktikant ist, berechnet sich diese Differenz jeweils auf unterschiedliche Weise. Organisiert man die möglichen Kombinationen aus Bundesland, Tarifvertrag und Status des Mitarbeiters in einer hierar- chisch verzweigten Baumstruktur, so ergibt sich die in der Figur 3 gezeigte Struktur. Gemäß dieser Struktur bestehen zwölf verschiedene Alternativen für die Berechnung der Differenz aus Brutto- und Nettolohn. Für jede einzelne dieser zwölf Alternativen ist genau ein einziges Datenobjekt vorgesehen, das eine entsprechende Sequenz von Kalkulationsanweisungen zur Berechnung der Differenz aus Brutto- und Nettolohn nach der jeweiligen Alternative um- fasst. Insgesamt liegen somit zwölf verschiedene Datenobjekte 11 vor, die zusammen die erste Gruppe von Datenobjekten 11 bilden. Jedem der zwölf Datenobjekte 11 ist innerhalb der ersten Gruppe eindeutig eine Identifikation zugeordnet. Mit anderen Worten ist die Abbildung zwischen Datenobjekten 11 und Identifikationen innerhalb der ersten Gruppe bijektiv.
Der zweite Datenverarbeitungsprozess 14 ist für die Berechnung der Steuerabgaben beliebiger Mitarbeiter eingerichtet. Da die möglichen Kombinationen
aus Bundesländern, Tarifverträgen und Status des Mitarbeiters dieselben sind wie im Falle des ersten Datenverarbeitungsprozesses 12, nämlich die in der Baumstruktur der Figur 3 gezeigten Kombinationen, gibt es auch für den Da- tenverarbeitungsprozess 14 zwölf alternative Möglichkeiten der Berechnung. Folglich ist auch der Datenverarbeitungsprozess 14 durch zwölf die zweite Gruppe von Datenobjekten bildende Datenobjekte 13 mit jeweiligen den Datenobjekten 13 zugeordneten Identifikationen implementiert, wobei jedes Datenobjekt 13 entsprechend einer der zwölf Alternativen eine jeweilige Sequenz von Kalkulationsanweisungen umfasst. Obwohl auch innerhalb der zweiten Gruppe von Datenobjekten 13 die Zuordnung zwischen Datenobjekten 13 und jeweiligen Identifikationen eineindeutig oder bijektiv ist, sind die den zwölf Datenobjekten 13 der zweiten Gruppe zugeordneten zwölf Identifikationen mit denjenigen zwölf Identifikationen identisch, die den zwölf Datenobjekten 11 der ersten Gruppe zugeordnet sind. Dies resultiert aus der Gleichheit der Kombinationsmöglichkeiten aus Bundesland, Tarifvertrag und Status des Mitarbeiters, die für beide Datenverarbeitungsprozesse 12 und 14 zu berücksichtigen sind.
Bei den Identifikationen handelt es sich vorliegend um Zeichenketten, die aus den in der Figur 3 verwendeten Buchstaben und Zahlen bestehen, die für ein bestimmtes Datenobjekt 11, 13 innerhalb der ihm als Identifikation zugeordneten Zeichenkette in der Reihenfolge angeordnet sind, wie sie in der Figur 3 bei Verfolgen eines Pfades innerhalb der Baumstruktur bis zu diesem bestimmten Datenobjekt 11 , 13 auftreten. So ist beispielsweise dem äußersten linken Da- tenobjekt 11, 13 die Zeichenkette „BL1TV1A" als Identifikation zugeordnet und dem äußersten rechten Datenobjekt 11 , 13 ist die Zeichenkette „BL2TV3P" als Identifikation zugeordnet. Mit der Zeichenkette „BL1TV1A" als Identifikation wird demnach ein Datenobjekt 11, 13 identifiziert, dessen Sequenz von Kalkulationsanweisungen für einen Mitarbeiter ausgelegt ist, der im Bundesland BL1 nach dem Tarifvertrag TV1 als Angestellter beschäftigt ist, während mit der Zeichen kette „BL2TV3P" als Identifikation ein Datenobjekt 11, 13 identifiziert wird, dessen Sequenz von Kalkulationsanweisungen für einen Mitarbeiter ausgelegt ist, der im Bundesland BL2 nach dem Tarifvertrag TV3 als Prakti-
kant beschäftigt ist. Die Identifikationen der dazwischenliegenden Datenobjekte 11 , 13 werden entsprechend gebildet.
Das Verfahren gemäß der vorliegenden Erfindung wird nun mittels des in der Figur 4 gezeigten Flussdiagrammes erläutert. Im Zusammenhang damit wird zugleich die Arbeitsweise der Vorrichtung 1 beschrieben.
Das Verfahren startet mit dem Schritt SO. Im nachfolgenden Schritt S1 werden die Datenverarbeitungsprozesse 12, 14 in der Datenverarbeitungseinrichtung 2 implementiert, indem die Datenobjekte 11 und 13 mit den jeweiligen ihnen zugeordneten Identifikationen im Speicher 10 gespeichert und gruppenweise zu jeweiligen Datenverarbeitungsprozessen 12, 14 mit jeweiligen GUIDs 17, 18 zusammengefasst werden.
Nachdem die Datenverarbeitungsprozesse 12, 14 implementiert worden sind, stellt der Client 8 eine Verbindung mit dem Benutzerschnittstellenserver 7 her und übermittelt eine Anfrage an die Benutzerschnittstelle 4. Beispielsweise kann der Client 8 Daten anfordern, die im Datenbanksystem 3 gespeichert sind. Um diese Daten zu liefern, setzt sich der Benutzerschnittstellenserver 7 mit dem Datenbanksystemserver 6 in Verbindung, die angeforderten Daten werden aus einer Datenbank des Datenbanksystems 3 ausgelesen, vom Datenbanksystemserver 6 an den Benutzerschnittstellenserver 7 gesendet und von diesem an den Client 8 übertragen.
Häufig erfordert die Anfrage des Clients 8 jedoch eine Verarbeitung der Daten. Ein solcher Fall liegt beispielsweise vor, wenn die Anfrage des Clients 8 Informationen über die Steuerabgaben eines bestimmten Mitarbeiters betrifft. Ohne Beschränkung der Allgemeinheit sei angenommen, dass der Client 8 eine Anfrage nach den Steuerabgaben eines im Bundesland BL2 beschäftig- ten Mitarbeiters, für den der Tarifvertrag TV2 gilt und der ein Praktikant P ist, an den Benutzerschnittstellenserver 7 übermittelt. Der Benutzerschnittstellenserver 7 ermittelt aus diesen Angaben die Identifikation desjenigen Datenobjekts 13 des zweiten Datenverarbeitungsprozesses 14, das die entsprechende
Sequenz an Kalkulationsanweisungen zur Berechnung dieser Steuerabgaben umfasst und sendet diese Identifikation, bei der es sich um die Zeichenkette „BL2TV2P" handelt, zusammen mit weiteren Angaben über den Mitarbeiter, wie zum Beispiel dessen Namen, an den Server 5 der Datenverarbeitungsein- richtung 2. Dies entspricht dem Schritt des Vorgebens einer Identifikation oder dem Verfahrensschritt S2 in der Figur 4.
Vom Datenbanksystemserver 6 fordert der Server 5 die für die Berechnung notwendigen Daten über das Einkommen des Mitarbeiters an, die im Daten- banksystem 3 unter dem Namen des Mitarbeiters gespeichert sind. Die Daten über das Einkommen des Mitarbeiters werden aus der Datenbank des Datenbanksystems 3 ausgelesen und an den Server 5 übertragen. Der Server 5 übergibt sowohl die Daten über das Einkommen des Mitarbeiters als auch die Identifikation an den Prozessor 9. Anschließend identifiziert der Prozessor 9 anhand der Identifikation das betreffende Datenobjekt 13 des Datenverarbeitungsprozesses 14, was in der Figur 4 dem Schritt S3 entspricht, und führt gemäß dem nachfolgenden Schritt S4 die Kalkulationsanweisungen der vom identifizierten Datenobjekt 13 umfassten Sequenz von Kalkulationsanweisungen aus. Hierzu liest der Prozessor 9 vergleichbar einem Interpreter die im XML-Format vorliegende Sequenz von Kalkulationsanweisungen und verarbeitet mit Ausführen der Kalkulationsanweisungen die Daten über das Einkommen des Mitarbeiters. Dies entspricht dem Schritt S5 in der Figur 4.
Im Allgemeinen muss die Ausführung eines Datenverarbeitungsprozesses nicht zwangsläufig zur Erzeugung irgendwelcher Daten als Resultat des Datenverarbeitungsprozesses führen, weshalb das erfindungsgemäße Verfahren gemäß der Figur 4 mit dem Schritt S6 endet. Im gewählten Beispiel werden bei Ausführung des Datenverarbeitungsprozesses 14 jedoch Daten über die Steuerabgaben des betreffenden Mitarbeiters erzeugt, die nach Beendigung des Datenverarbeitungsprozesses 14, was dem Ende der Ausführung der Kalkulationsanweisungen der Sequenz von Kalkulationsanweisungen des identifizierten Datenobjekts 13 entspricht, als dessen Resultat vorliegen. Daher werden diese berechneten Daten in Erweiterung des grundlegenden Verfah-
rens der vorliegenden Erfindung, wie es in der Figur 4 dargestellt ist, vom Prozessor 9 an den Server 5 übergeben und von diesem an den Benutzerschnittstellenserver 7 übermittelt, der sie an den Client 8 weiterleitet. Zusätzlich können die berechneten Daten im Speicher 10 gespeichert werden, um sie für eventuelle Ergänzungen der in der Datenbank des Datenbanksystems 3 gespeicherten Daten oder für die Erstellung von späteren Berichten bereit zu halten.
Für die Vorrichtung 1 ist ein spezieller Betriebsmodus vorgesehen, der die Vorgabe einer Datenverarbeitungskategorie erfordert. Hierfür sind die in der Datenbank des Datenbanksystems 3 gespeicherten Daten jeweiligen Datenverarbeitungskategorien zugeordnet. Eine Datenverarbeitungskategorie kann im vorliegenden Beispiel ein spezifisches Bundesland BL1 oder BL2, ein spezifischer Tarifvertrag TV1, TV2 und TV3 oder ein spezifischer Status der Mi- tarbeiter sein. Wird die Vorrichtung 1 in besagtem Betriebsmodus betrieben und wird eine bestimmte Datenverarbeitungskategorie vorgegeben, so erfolgt die Identifizierung eines Datenobjekts 11 , 13 sowie das Auslesen von Daten aus der Datenbank des Datenbanksystems 3 nur dann, wenn das betreffende Datenobjekt 11, 13 bzw. die Daten der vorgegebenen Datenverarbeitungska- tegorie zugewiesen ist bzw. sind. Wird beispielsweise als Datenverarbeitungskategorie der Tarifvertrag TV3 vorgegeben, so kommt es nur dann zur Identifizierung eines Datenobjekts 11 , 13, wenn dieses für den Tarifvertrag TV3 vorgesehen ist. Dies ist genau dann der Fall, wenn die einem Datenobjekt 11 , 13 als Identifikation zugeordnete Zeichenkette die drei Zeichen „TV3" aufweist, wobei alle anderen in dieser Zeichenkette vorkommenden Zeichen unerheblich sind. In der Figur 3 ist dies bei genau vier Datenobjekten 11, 13 der Fall, und zwar bei einem Datenobjekt, das für einen Mitarbeiter im Bundesland BL1 vorgesehen ist, der Angestellter A ist, bei einem Datenobjekt, das für einen Mitarbeiter im Bundesland BL1 vorgesehen ist, der Praktikant P ist, bei einem Datenobjekt, das für einen Mitarbeiter im Bundesland BL2 vorgesehen ist, der Angestellter ist, und bei einem Datenobjekt, das für einen Mitarbeiter im Bundesland BL2 vorgesehen ist, der Praktikant P ist. Ebenso
werden Daten aus der Datenbank des Datenbanksystems 3 nur dann ausgelesen, wenn sie dem Tarifvertrag TV3 zugewiesen sind.
Eine weitere Besonderheit der Vorrichtung 1 liegt in der Speicherung der Da- tenobjekte 11 , 13 unter Zuweisung einer Validitätszeit sowie deren datenver- lustfreiem Überschreiben. Als Beispiel zeigt Figur 5a) ein einzelnes Datenobjekt 19 mit einer GUID 20 und einer Validitätszeit 21 , die dem Datenobjekt 19 beim Speichern desselben in den Speicher 10 zugeordnet wurde. Die Validitätszeit 21 entspricht im vorliegenden Fall dem Tagesdatum, an dem das Speichern stattfand. Das Datenobjekt 19 soll nun durch ein neues Datenobjekt mit einer neuen Sequenz von Kalkulationsanweisungen überschrieben werden. Dazu wird dem Datenverarbeitungsprozess, dem das Datenobjekt 19 angehört, ein neues Datenobjekt 22 hinzugefügt und im Speicher 10 gespeichert, wobei diesem neuen Datenobjekt 22 eine neue Validitätszeit 23 zuge- wiesen wird, die dem Zeitpunkt des Speicherns des Datenobjekts 22 entspricht und folglich jünger als die Validitätszeit 21 ist. Dem neuen Datenobjekt 22 wird zudem zwar eine eigene GUID 24 zugewiesen, es wird ihm aber dieselbe Identifikation zugeordnet wie dem Datenobjekt 19. Dabei bleibt das Datenobjekt 19 unberührt, d.h. das Datenobjekt 19 wird weder gelöscht noch an- derweitig verändert, sein Speicherzustand wird vielmehr beibehalten. Figur 5b) zeigt die Situation nach Speichern des neuen Datenobjekts 22: Neben dem Datenobjekt 19, seiner Validitätszeit 21 und seiner GUID 20 liegt nunmehr auch das neue Datenobjekt 22 mitsamt Validitätszeit 23 und GUID 24 im Speicher 10 gespeichert vor, wobei beiden Datenobjekten 19 und 22 dieselbe Identifikation zugeordnet ist und beide Datenobjekte 19, 22 zum selben Datenverarbeitungsprozess gehören.
Sofern nach Erfolgen der Überschreibung der Datenverarbeitungsprozess ausgeführt werden soll, zu dem die Datenobjekte 19 und 22 gehören, und da- bei die den beiden Datenobjekten 19, 22 zugeordnete Identifikation vorgegeben wird, ist zusätzlich die Vorgabe einer Bezugszeit notwendig, um die Auswahl eines der Datenobjekte 19, 22 zu ermöglichen. Gemäß einem voreingestellten ersten Arbeitsmodus der Vorrichtung 1 wird automatisch die aktuelle
Zeit der Vorgabe der Identifikation als Bezugszeit gewählt und vorgegeben. Diese ist naturgemäß jünger als jede der Validitätszeiten 21 und 23. Damit wird dasjenige der beiden im Speicher 10 gespeicherten Datenobjekte 19 und 22, denen dieselbe Identifikation zugeordnet ist, mit der jüngsten Validitätszeit 23 ausgelesen, im vorliegenden Beispiel also das Datenelement 22.
Außerhalb des Speichers 10 unterscheidet sich die Wirkung dieser Überschreibung somit nicht von der Wirkung herkömmlicher Überschreibungen, bei denen gespeicherte Datenobjekte physikalisch gelöscht werden: Bei Ausfüh- ren des Datenverarbeitungsprozesses, dem das Datenobjekt angehört, und bei Vorgabe einer Identifikation, die dem Datenobjekt zugeordnet ist, wird in beiden Fällen das jeweils zuletzt gespeicherte Datenobjekt ausgegeben, mit dem das zuvor gespeicherte Datenobjekt überschrieben worden ist. Dagegen bleibt bei dem hier beschriebenen datenverlustfreien Überschreiben eines Da- tenobjekts das überschriebene Datenobjekt unverändert im Speicher 10 gespeichert, während es bei herkömmlichen Überschreibungen unter Umständen physikalisch gelöscht wird und sein Informationsgehalt dadurch unwiederbringlich verloren geht. Somit erlaubt es das beschriebene Überschreiben, auch nach dem Überschreiben bei Bedarf auf das überschriebene Datenob- jekt zuzugreifen. Da dem Datenobjekt eine eigene GUID zugewiesen ist, erleichtert diese die Adressierung des Datenobjekts bei einem Zugriff auf dasselbe. Ein unbeabsichtigtes Löschen von Datenobjekten ist folglich grundsätzlich ausgeschlossen.
In einem zweiten Arbeitsmodus der Vorrichtung 1 können auch andere Bezugszeiten vorgegeben werden. Wird bei Ausführen eines Datenverarbeitungsprozesses beispielsweise eine zwischen den Validitätszeiten 21 und 23 liegende Bezugszeit vorgegeben, so wählt die Vorrichtung 1 das Datenobjekt 19 aus, da dessen Validitätszeit 21 nun die jüngste derjenigen Validitätszeiten ist, die älter sind als die Bezugszeit. Gibt man stattdessen eine Bezugszeit vor, die vor der Validitätszeit 21 liegt bzw. älter als die Validitätszeit 21 ist, wird kein Datenobjekt ausgewählt, weil keine der Validitätszeiten 21 und 23 älter ist als die Bezugszeit. Bei Vorgabe einer Bezugszeit, die relativ zur Zeit
der Vorgabe der Identifikation in der Zukunft liegt, wird wiederum das Datenobjekt 22 ausgewählt, da dessen Validitätszeit 23 auch in diesem Fall die jüngste der Validitätszeiten 21 und 23 ist, die beide älter als die Bezugszeit sind.
Bei einer späteren Überschreibung des Datenobjekts 22 in der Figur 5b), welches wie erwähnt bis dahin dasjenige der beiden Datenobjekte 19 und 22 desselben Datenverarbeitungsprozesses und derselben zugeordneten Identifikation mit der jüngsten Validitätszeit 23 ist, wird analog verfahren. Zum Überschreiben des Datenobjekts 22, beispielsweise durch ein Datenobjekt 25, wird das Datenobjekt 25 dem Datenverarbeitungsprozess der Datenobjekte 19 und 22 hinzugefügt und im Speicher 10 gespeichert. Dabei wird ihm eine Validitätszeit 26 zugewiesen, bei der es sich um den Tag handelt, an dem das Datenelement 25 in den Speicher 10 gespeichert wurde, und es wird ihm eine GUID 27 zugwiesen. Die dem Datenobjekt 25 zugeordnete Identifikation ist mit der Identifikation, die den Datenobjekten 19 und 22 zugeordnet wurde, identisch. Figur 5c) zeigt die Situation nach Überschreiben des Datenobjekts 22 durch das Datenobjekt 25. Nach Erfolgen der Überschreibung wird bei Ausführen des Datenverarbeitungsprozesses, dem die drei Datenobjekte 19, 22, 25 angehören, und bei Vorgabe einer Identifikation, die den Datenobjekten 19, 22, 25 zugeordnet ist, dasjenige der drei gespeicherten Datenobjekte 19, 22, 25 ausgewählt, das nunmehr die jüngste Validitätszeit 26 von allen Validitätszeiten 21 , 23, 26 der Datenobjekte 19, 22, 25 hat, also das Datenobjekt 25. Bei Ausführen des Datenverarbeitungsprozesses, dem die Datenob- jekte 19, 22, 25 angehören, und bei Vorgabe einer Bezugszeit, die vor der Validitätszeit 21 liegt, wird wie oben erläutert keines der Datenobjekte 19, 22, 25 ausgewählt, bei Vorgabe einer Bezugszeit zwischen der Validitätszeit 21 und der Validitätszeit 23 wird das Datenobjekt 19 ausgelesen, bei Vorgabe einer Bezugszeit zwischen der Validitätszeit 23 und der Validitätszeit 26 wird das Datenobjekt 22 ausgewählt, und bei Vorgabe einer Bezugszeit, die jünger ist als die Validitätszeit 26, wird das Datenelement 25 ausgewählt.
Im erläuterten Beispiel kann alternativ statt jeweils getrennte GUID und Validi- tätszeiten vorzusehen auch eine Leitkennung eingerichtet werden, zu der GUID und Validitätszeit zusammengefasst sind.
Unter gewissen Umständen ist es wünschenswert, ein gespeichertes Datenobjekt durch ein anderes Datenobjekt zu ersetzen, wobei das ersetzte Datenobjekt gelöscht wird. Beispielsweise könnte das Datenobjekt 22 beim Speichern irrtümlich mit einem anderen Datenobjekt verwechselt worden sein, das anstatt des Datenobjekts 22 hätte gespeichert werden müssen. Für solche Fälle ist die Vorrichtung 1 zum Ersetzen gespeicherter Datenobjekte durch andere Datenobjekte eingerichtet. Zur Vermeidung von Informationsverlusten bei der Ersetzung ist die Vorrichtung 1 darüber hinaus zur Generierung eines Protokolls im XML-Format eingerichtet, in welchem Einzelheiten der Ersetzung vermerkt werden.
Ein Beispiel für eine Ersetzung ist in den Figuren 5c) und 5d) verdeutlicht. In der Situation gemäß der Figur 5c) soll das Datenobjekt 22 durch ein Datenobjekt 28 ersetzt werden, ohne dass ein Informationsverlust befürchtet werden muss. Dazu wird ein Protokoll 29 erzeugt und der Validitätszeit 23 zugeord- net. In diesem werden zum Beispiel der Tag und die Uhrzeit der Ersetzung, eine IP-Adresse eines Computers, von dem aus die Ersetzung getätigt wurde, der die Ersetzung veranlassende Benutzer der Vorrichtung 1 , eine Kopie der vom Datenobjekt 22 umfassten Sequenz von Kalkulationsanweisungen sowie ein Änderungsvermerk festgehalten. Das Datenobjekt 22 wird gelöscht und das Datenobjekt 28 wird unter Zuweisung der GUID 24 und der Validitätszeit 23, die zuvor dem Datenobjekt 22 zugewiesen waren, gespeichert. Somit ist das Datenelement 22 zwar nicht mehr existent, gleichwohl ist dessen Informationsgehalt nicht verloren, da die von ihm umfasste Sequenz von Kalkulationsanweisungen im Protokoll 29 vermerkt wurde.
Anstatt ein derartiges Protokoll 29 erst bei Erfolgen einer Ersetzung eines Datenobjekts durch ein anderes zu generieren, kann alternativ bereits beim erstmaligen Speichern eines Datenobjekts, wenn dem Datenobjekt eine Validi-
tätszeit zugewiesen wird, dieser Validitätszeit ein Protokoll 29 zugeordnet werden. In diesem Protokoll 29 werden zum Beispiel der Tag und die Uhrzeit des Speicherns des Datenobjekts, die nicht notwendigerweise mit der dem Datenobjekt zugewiesenen Validitätszeit übereinstimmen müssen, eine IP- Adresse eines Computers, von dem aus das Speichern des Datenobjekts ver- anlasst wurde, der die Speicherung des Datenobjekts veranlassende Benutzer und ein Vermerk über die Speicherung im Protokoll 29 festgehalten. Wird das Datenobjekt zu einem späteren Zeitpunkt durch ein anderes Datenobjekt ersetzt, so erfolgt wie oben erläutert ein zusätzlicher entsprechender Vermerk im Protokoll 29.
Figur 6 zeigt das Datenbanksystem 3 der Vorrichtung 1. Das Datenbanksystem 3 umfasst neben dem Datenbanksystemserver 6 eine Datenbank 30 und einen Arbeitsspeicher 31. Der Datenbanksystemserver 6 ist zugleich Daten- bankmanagementsystem zur Verwaltung des Datenbanksystems 3. In der Datenbank 30 sind Datenelemente 32 und Datengruppen 33 gespeichert, wobei der Übersichtlichkeit halber jeweils nur ein Datenelement 32 und eine Datengruppe 33 dargestellt sind. Jedem Datenelement 32 sind eine GUID 34 und eine Validitätszeit 35 zugeordnet, während jeder Datengruppe 33 eine GUID 36 und eine Validitätsstartzeit 37 zugeordnet sind.
Zum Bearbeiten und Lesen der in der Datenbank 30 gespeicherten Datenelemente 32 und Datengruppen 33 kann entweder direkt auf die in der Datenbank 30 gespeicherten Datenelemente 32 und Datengruppen 33 zurückgegrif- fen werden, oder diese werden aus der Datenbank 30 ausgelesen, in ein XML-Format umgewandelt und in den Arbeitsspeicher 31 geschrieben. Im in der Figur 6 gezeigten Arbeitsspeicher 31 ist mittels gestrichelter Linien ein Datenelement 38 im XML-Format dargestellt, das durch Auslesen eines Datenelements 32 aus der Datenbank 30 und Umwandeln desselben in ein XML- Format erzeugt worden ist. Das Auslesen des Datenelements 32 hat keinen Einfluss auf die Speicherung des Datenelements 32 in der Datenbank 30. Entsprechend ist im Arbeitsspeicher 31 eine Datengruppe 39 im XML-Format mittels gestrichelter Linien dargestellt, das durch Auslesen einer Datengruppe
33 aus der Datenbank 30 und Umwandeln in ein XML-Format erzeugt worden ist, wobei auch hier das Auslesen der Datengruppe 33 keinen Einfluss auf den Speicherzustand der Datengruppe 33 in der Datenbank 30 hat.
Im Folgenden wird das Speichern von Datenelementen 32 spezifischer Attribute sowie das Überschreiben von in der Datenbank 30 gespeicherten Datenelementen 32 erläutert. Zunächst wird das in der Figur 7a) gezeigte Datenelement 32 in der Datenbank 30 gespeichert. Bei dem Datenelement 32 handelt es sich um eine Zeichenkette mit den Zeichen „Maier", die einen Nach- namen bezeichnet. Weil das Datenelement 32 einen Nachnamen bezeichnet, handelt es sich bei ihm um ein Datenelement des Attributs „Nachname". Dem Datenelement 32 werden beim Speichern die Validitätszeit 35 und die GUID
34 zugeordnet. Die Validitätszeit 35 hat im vorliegenden Fall den Wert „24.09.2007" und entspricht dem Tag, an dem das Datenelement 32 in der Datenbank 30 gespeichert wird. Als GUID 34 wird der Einfachheit halber eine vierstellige Zahl angenommen, die hier den Wert „7777" hat.
Das Datenelement 32 des Attributs „Nachname" soll nun durch ein Datenelement 40 desselben Attributs „Nachname" überschrieben werden, bei dem es sich um eine Zeichenkette mit den Zeichen „Müller" handelt. Dazu wird das Datenelement 40 in der Datenbank 30 gespeichert, wobei ihm die Validitätszeit 41 zugewiesen wird, die dem Zeitpunkt des Speicherns des Datenelements 40 entspricht und vorliegend den Wert „13.12.2007" hat. Die Validitätszeit 41 ist folglich jünger als die Validitätszeit 35. Zusätzlich wird dem Daten- element 40 eine eigene GUID 42 mit dem Wert „7778" zugewiesen. Dabei bleibt das Datenelement 32 unberührt, d.h. das Datenelement 32 wird weder gelöscht noch anderweitig verändert, sein Speicherzustand wird vielmehr beibehalten. Figur 7b) zeigt die Situation nach Ausführen der Speicherung des Datenelements 40: Neben dem Datenelement 32, seiner Validitätszeit 35 und seiner GUID 34 liegt auch das Datenelement 40 mitsamt Validitätszeit 41 und GUID 42 in der Datenbank 30 gespeichert vor.
Sofern nach Erfolgen der Überschreibung auf ein Datenelement des Attributs „Nachname" zugegriffen wird, um dieses Datenelement in den Arbeitsspeicher
31 auszulesen, wird eine Bezugszeit vorgegeben. Gemäß einem voreingestellten ersten Arbeitsmodus des Datenbanksystems 3 wird automatisch die aktuelle Zeit des Zugriffs als Bezugszeit gewählt und vorgegeben. Diese ist naturgemäß jünger als beide Validitätszeiten 35 und 41. Damit wird nachfolgend dasjenige der beiden in der Datenbank 30 gespeicherten Datenelemente
32 und 40 des Attributs „Nachname" mit der jüngsten Validitätszeit 41 ausgelesen, im vorliegenden Beispiel also das Datenelement 40.
Außerhalb der Datenbank 30 unterscheidet sich die Wirkung der Überschreibung somit nicht von der Wirkung herkömmlicher Verfahren zum Überschreiben, bei denen gespeicherte Datenelemente überschrieben und dabei physikalisch gelöscht werden: Bei Zugriffen auf Datenelemente des betreffenden Attributs wird in beiden Fällen das jeweils neu gespeicherte Datenelement ausgegeben, mit dem das ursprüngliche Datenelement überschrieben worden ist. Innerhalb der Datenbank 30 dagegen bleibt bei Überschreiben eines Datenelements gemäß dem beschriebenen Verfahren das überschriebene Datenelement unverändert in der Datenbank 30 gespeichert, während es bei herkömmlichen Verfahren unter Umständen physikalisch gelöscht wird und sein Informationsgehalt dadurch unwiederbringlich verloren geht. Somit erlaubt es das beschriebene Verfahren, auch nach dem Überschreiben bei Bedarf auf das überschriebene Datenelement zuzugreifen. Sofern dem Datenelement eine eigene Kennung oder wie im vorliegenden Beispiel eine GUID zugewiesen wird, erleichtert diese die Adressierung des Datenelements bei einem Zugriff auf dasselbe. Ein unbeabsichtigtes Löschen von Datenelementen, beispielsweise bei Aktualisierungen bestehender Datenbestände, ist folglich grundsätzlich ausgeschlossen.
In einem zweiten Arbeitsmodus des Datenbanksystems 3 können auch andere Bezugszeiten vorgegeben werden. Wird bei einem Zugriff auf Datenelemente des Attributs „Nachname" beispielsweise eine zwischen den Validitätszeiten 35 und 41 liegende Bezugszeit vorgegeben, so liest das Datenbanksystem 3
das Datenelement 32 aus, da dessen Validitätszeit 35 nun die jüngste derjenigen Validitätszeiten ist, die älter sind als die Bezugszeit. Gibt man stattdessen eine Bezugszeit vor, die vor der Validitätszeit 35 liegt bzw. die älter ist als die Validitätszeit 35, wird kein Datenelement ausgelesen, weil keine der VaIi- ditätszeiten 35 und 41 älter ist als die Bezugszeit. Bei Vorgabe einer Bezugszeit, die relativ zur Zeit des Zugriffs in der Zukunft liegt, wird wiederum das Datenelement 40 ausgelesen, da dessen Validitätszeit 41 auch in diesem Fall die jüngste der Validitätszeiten 35 und 41 ist, die beide älter als die Bezugszeit sind.
Bei einer späteren Überschreibung des Datenelements 40 in der Figur 7b), welches wie erwähnt bis dahin dasjenige der beiden Datenelemente 32 und 40 des Attributs „Nachname" mit der jüngsten Validitätszeit 41 ist, wird analog verfahren. Zum Überschreiben des Datenelements 40, beispielsweise durch ein Datenelement 43 desselben Attributs „Nachname", bei dem es sich um die Zeichenkette „Schmidt" handelt, wird das Datenelement 43 in der Datenbank 30 gespeichert, dabei wird ihm eine Validitätszeit 44, im vorliegenden Fall „04.03.2008" zugewiesen, bei der es sich um den Tag handelt, an dem das Datenelement 43 in der Datenbank 30 gespeichert wurde, und es wird ihm eine GUID zugewiesen, vorliegend die GUID 45 mit dem Wert „7779". Figur 7c) zeigt die Situation nach Überschreiben des Datenelements 40 durch das Datenelement 43. Nach Erfolgen der Überschreibung wird im ersten Arbeitsmodus des Datenbanksystems 3 bei Zugriffen auf Datenelemente des Attributs „Nachname" dasjenige der drei gespeicherten Datenelemente 32, 40, 43 ausgelesen, das nunmehr die jüngste Validitätszeit 44 von allen Validitätszeiten 35, 41, 44 der Datenelemente 32, 40, 43 des Attributs „Nachname" hat, also das Datenelement 43. Im zweiten Arbeitsmodus wird bei Zugriffen mit Vorgabe einer Bezugszeit, die zeitlich vor der Validitätszeit 35 liegt, wie oben erläutert keines der Datenelemente 32, 40, 43 ausgegeben, bei Vorgabe einer Bezugszeit zwischen der Validitätszeit 35 und der Validitätszeit 41 wird das Datenelement 32 ausgelesen, bei Vorgabe einer Bezugszeit zwischen der Validitätszeit 41 und der Validitätszeit 44 wird das Datenelement 40 ausgelesen, und bei Vorgabe einer Bezugszeit, die jünger ist als die Validitätszeit 44, bei-
spielsweise wie im ersten Arbeitsmodus des Datenbanksystems 3 die Zeit, zu der zugegriffen wird oder einer relativ zum Zugriff in der Zukunft liegenden Zeit, erfolgt die Ausgabe des Datenelements 43.
Im erläuterten Beispiel kann alternativ statt jeweils getrennte GUID und Validi- tätszeiten vorzusehen auch eine Leitkennung eingerichtet werden, zu der GUID und Validitätszeit zusammengefasst sind. So könnte zum Beispiel dem Datenelement 32 statt der GUID 34 und der Validitätszeit 35 eine Leitkennung mit dem Wert „7777 24092007" zugeordnet werden, dem Datenelement 40 statt der GUID 42 und der Validitätszeit 41 eine Leitkennung mit dem Wert „7778 13122007", und dem Datenelement 43 statt der GUID 45 und der Validitätszeit 44 eine Leitkennung mit dem Wert „7779 04032008".
Unter gewissen Umständen ist es wünschenswert, ein gespeichertes Daten- element durch ein anderes Datenelement zu ersetzen, wobei das ersetzte Datenelement gelöscht wird. Beispielsweise könnte das Datenelement 40 beim Speichern irrtümlich mit einem anderen Datenelement verwechselt worden sein, und anstatt der Zeichenkette „Müller" hätte richtigerweise die Zeichenkette „Fischer" mit der Validitätszeit 42 gespeichert werden müssen. Für sol- che Fälle ist das Datenbanksystem 3 zum Ersetzen gespeicherter Datenelemente durch andere Datenelemente eingerichtet. Zur Vermeidung von Informationsverlusten bei der Ersetzung ist das Datenbanksystem 3 darüber hinaus zur Generierung eines Protokolls 46 im XML-Format eingerichtet, in welchem Einzelheiten der Ersetzung vermerkt werden.
Ein Beispiel für eine Ersetzung wird anhand der Figuren 7c) und 7d) verdeutlicht. In der Situation gemäß der Figur 7c) soll das Datenelement 40 durch ein Datenelement 47 des Attributs „Nachname", bei dem es sich um die Zeichenkette „Fischer" handelt, ersetzt werden, ohne dass ein Informationsverlust be- fürchtet werden muss. Dazu wird ein Protokoll 46 erzeugt und der Validitätszeit 41 zugeordnet. In diesem werden zum Beispiel der Tag und die Uhrzeit der Ersetzung, eine IP-Adresse eines Computers, von dem aus die Ersetzung getätigt wurde, der die Ersetzung veranlassende Benutzer des Datenbanksys-
tems 3, eine Kopie der Zeichenkette „Müller" sowie ein Änderungsvermerk festgehalten. Außerhalb des Protokolls 46 wird das Datenelement 40 gelöscht und das Datenelement 47 wird unter Zuweisung der GUID 42 und der Validi- tätszeit 41, die zuvor dem Datenelement 40 zugewiesen waren, gespeichert. Somit ist das Datenelement 47 zwar außerhalb des Protokolls 46 nicht mehr existent, gleichwohl ist dessen Informationsgehalt nicht verloren, da die Zeichenkette „Müller" im Protokoll 46 vermerkt wurde.
Anstatt ein derartiges Protokoll 46 erst bei Erfolgen einer Ersetzung eines Da- tenelements durch ein anderes zu generieren, kann alternativ bereits beim erstmaligen Speichern eines Datenelements, wenn dem Datenelement eine Validitätszeit zugewiesen wird, dieser Validitätszeit ein Protokoll 46 zugeordnet werden. In diesem Protokoll 46 werden zum Beispiel der Tag und die Uhrzeit des Speicherns des Datenelements, die nicht notwendigerweise mit der dem Datenelement zugewiesenen Validitätszeit übereinstimmen müssen, eine IP-Adresse eines Computers, von dem aus das Speichern des Datenelements veranlasst wurde, der die Speicherung des Datenelements veranlassende Benutzer des Datenbanksystems 3 und ein Vermerk über die Speicherung festgehalten. Wird das Datenelement zu einem späteren Zeitpunkt durch ein anderes Datenelement ersetzt, so erfolgt wie oben erläutert ein zusätzlicher entsprechender Vermerk im Protokoll.
Für ein Datenelement können beliebige Indikatoren zum Anzeigen unterschiedlicher Zustände von Datenelementen vorgesehen sein. Figur 8 zeigt das Datenelement 32 der Figur 7a) mit verschiedenen Indikatoren 48, 49, 50. Der Indikator 48 mit dem Wert „3" zeigt an, dass das Datenelement 32 dem Datenbanksystem 3 zugeordnet ist. Der Indikator 49 mit dem Wert „P" ermöglicht öffentliche Zugriffe auf das Datenelement 32. Mittels entsprechender Änderungen des Indikators 49 lässt sich der Zugriff auf das Datenelement 32 auf eine einzelne Person oder Personengruppen bzw. bestimmte Applikationen beschränken. Schließlich bezeichnet der Indikator 50 eine Validitätsendzeit des Datenelements 32, vorliegend „02.09.2008", bei deren Überschreiten das Datenelement 32 seine Gültigkeit verliert und nicht mehr ausgelesen wird.
Weitere Indikatoren können vorgesehen sein, um beispielsweise anzuzeigen, dass das betreffende Datenelement zur Löschung vorgesehen ist. Mit einem solchen Indikator lässt sich das in der Datenbank 30 gespeicherte Gesamtvolumen an Daten reduzieren, indem Datenelemente, an denen definitiv kein Interesse mehr besteht, durch entsprechendes Setzen des genannten Indikators zur Löschung freigegeben werden. Ferner kann ein Indikator eine Periodendauer bezeichnen, die periodisch erfolgende Zugriffe auf das Datenelement 32 angibt.
Die Indikatoren 48, 49, 50 können bei einer Überschreibung des Datenelements 32 durch das neue Datenelement 40 dem neuen Datenelement 40 unverändert zugewiesen werden, oder dem Datenelement 40 können einzelne oder alle der Indikatoren 48, 49, 50 mit neuen Werten zugewiesen werden. Ferner können dem Datenelement 40 weniger oder mehr Indikatoren 48, 49, 50 als dem von ihm überschriebenen Datenelement 32 zugewiesen werden.
Indikatoren wie eben beschrieben können entsprechend auch für einzelne oder alle der im Speicher 10 der Datenverarbeitungseinrichtung 2 gespeicherten Datenobjekte 11 , 13 vorgesehen werden.
Praktischerweise werden zwei oder mehrere Datenelemente, zwischen denen eine logische Beziehung besteht, zu einer Datengruppe 33 zusammengefasst. Figur 9 zeigt Einzelheiten der Datengruppe 33. Die Datengruppe 33 umfasst das Datenelement 32 der Figur 7a) mit der ihm zugewiesenen Validitätszeit 35 und der GUID 34 sowie ein weiteres Datenelement 51 und dessen Validitätszeit 52 sowie GUID 53. Das Datenelement 51 ist ein Datenelement des Attributs „Sozialversicherungsnummer" und ist damit von einem anderen Attribut als das Datenelement 32. Dem Datenelement 51 ist die Validitätszeit 52 mit dem Wert „11.02.2007" und die GUID 53 mit dem Wert „1389" zugeordnet. Der Datengruppe 33 als solcher ist wie oben beschrieben die GUID 36 zugewiesen, die gemäß Figur 9 den Wert „2425" hat. Außerdem ist der Datengruppe 33 als Indikator die Validitätsstartzeit 37 zugeordnet, die vorliegend mit der Validitätszeit 35 koinzidiert. Die Datengruppe 33 wird deshalb mit Speichern
des Datenelements 32 zum Auslesen freigegeben. Die Datengruppe 33 kann darüber hinaus um beliebig viele Datenelemente beliebiger Attribute erweitert werden, beispielsweise um ein Datenelement des Attributs „Adresse" oder um ein Datenelement des Attributs „Geburtstag". Mit der Datengruppe 33 lassen sich somit personenspezifische Daten einzelner Personen bequem verwalten.
Figur 10 zeigt eine Situation nach Überschreiben des Datenelements 32 der Datengruppe 33 durch das Datenelement 40, wie im Zusammenhang mit der Figur 7b) erläutert. Nach Überschreiben umfasst die Datengruppe 33 neben dem Datenelement 32 und dem Datenelement 51 auch das Datenelement 40. Die GUID 36 der Datengruppe 33 und deren Validitätsstartzeit 37 sind durch das Überschreiben unverändert geblieben. Bei Zugriffen auf Datenelemente des Attributs „Nachname" in der Datengruppe 33 wird wie oben beschrieben nunmehr das Datenelement 40 ausgelesen.
Die Datengruppe 33 kann auch als Musterdatengruppe zur Erzeugung beliebig vieler Datengruppen zur Verwaltung von Daten verschiedener Personen verwendet werden. Eine Datengruppe für eine bestimmte Person wird dann einfach durch Kopieren der Musterdatengruppe und Überschreiben des Da- tenelements 32 durch den betreffenden Namen der Person und Überschreiben des Datenelements 51 durch die entsprechende Sozialversicherungsnummer der jeweiligen Person erzeugt, wobei der so erzeugten neuen Datengruppe eine eigene GUID und eine eigene Validitätsstartzeit zugewiesen werden. Dabei wird für die neue Datengruppe ein Indikator vorgesehen, über den sich jederzeit ein Bezug der durch Vererbung der Musterdatengruppe hervorgegangenen Datengruppe zur Musterdatengruppe herstellen lässt. Ein solcher Indikator lässt ich beispielsweise dazu verwenden, um Änderungen in der Musterdatengruppe bequem auf die aus ihm hervorgegangene Datengruppe zu übertragen. Wird beispielsweise in der Musterdatengruppe zusätzlich zu den bereits vorhandenen Datenelementen 32 und 51 ein weiteres Datenelement des Attributs „Firmenzugehörigkeit" eingefügt, dann erfolgt eine entsprechende Einfügung automatisch auch in allen bisher aus der Musterdatengruppe hervorgegangenen und über den genannten Indikator mit diesem in Bezie-
hung stehenden Datengruppen. Sollte für einzelne der Datengruppen das so eingefügte Datenelement des Attributs „Firmenzugehörigkeit" nicht mit den übrigen Datenelementen 32 und 51 kompatibel sein, so kann das neu eingefügte Datenelement des Attributs „Firmenzugehörigkeit" in diesen einzelnen Datengruppen durch ein jeweils kompatibles Datenelement des Attributs „Firmenzugehörigkeit" auf die beschriebene Weise überschrieben werden. Insgesamt reduziert sich dadurch der Arbeitsaufwand beim Einpflegen neuer Datenelemente in Datengruppen in solchen Fällen, in denen eine große Anzahl von Datengruppen vorliegt und das neu eingepflegte Datenelement mit den allermeisten Datengruppen kompatibel ist.
Ferner ist das in der Figur 6 dargestellte Datenbanksystem 3 eingerichtet, im Arbeitsspeicher 31 erfolgende Ersetzungen bzw. Überschreibungen der in den Arbeitsspeicher 31 ausgelesenen Datenelemente 38 oder von Datenelemen- ten der in den Arbeitsspeicher 31 ausgelesenen Datengruppen 39 unmittelbar nach Erfolgen der Ersetzung oder Überschreibung im Arbeitsspeicher 31 entsprechend für die in der Datenbank 30 gespeicherten zugehörigen Datenelemente 32 und Datengruppen 33 nach einem der beschriebenen Verfahren auszuführen. Dies beugt eventuellen Informationsverlusten bei Störfällen des Datenbanksystems 3 vor, bei denen im flüchtigen Arbeitsspeicher 31 erfolgte Überschreibungen, die noch nicht entsprechend in der Datenbank 30 gespeichert wurden, verloren gehen.
Da in der Vorrichtung 1 sowohl Datenobjekte als auch Datenelemente unter Zuweisung einer jeweiligen Validitätszeit gespeichert werden, wird einerseits eine historische Datenhaltung erreicht. Andererseits kann die Vorrichtung 1 bei Vorgabe einer entsprechenden Bezugszeit jederzeit mitsamt Datenverarbeitungsprozessen und zu verarbeitenden Daten in einem Zustand betrieben werden, in dem sich die Vorrichtung zur vorgegebenen Bezugszeit befand.
Bezuαszeichen liste
1. Vorrichtung
2. Datenverarbeitungseinrichtung
3. Datenbanksystem
4. Benutzerschnittstelle
5. Server
6. Datenbanksystemserver
7. Benutzerschnittstellenserver
8. Client
9. Prozessor
10. Speicher
11. Datenobjekte
12. Datenverarbeitungsprozess
13. Datenobjekte
14. Datenverarbeitungsprozess
15. GUID
16. GUID
17. GUID
18. GUID
19. Datenobjekt
20. GUID
21. Validitätszeit
22. Daten Objekt
23. Validitätszeit
24. GUID
25. Datenobjekt
26. Validitätszeit
27. GUID
28. Datenobjekt
29. Protokoll
30. Datenbank
31. Arbeitsspeicher
32. Datenelement
33. Datengruppe
34. GUID
35. Validitätszeit
36. GUID
37. Validitätsstartzeit
38. Datenelement
39. Datengruppe
40. Datenelement
41. Validitätszeit
42. GUID
43. Datenelement
44. Validitätszeit
45. GUID
46. Protokoll
47. Datenelement
48. Indikator
49. Indikator
50. Indikator
51. Datenelement
52. Validitätszeit
53. GUID