EP2271985A2 - Datenverarbeitungseinrichtung und verfahren zum verarbeiten von daten - Google Patents

Datenverarbeitungseinrichtung und verfahren zum verarbeiten von daten

Info

Publication number
EP2271985A2
EP2271985A2 EP09737746A EP09737746A EP2271985A2 EP 2271985 A2 EP2271985 A2 EP 2271985A2 EP 09737746 A EP09737746 A EP 09737746A EP 09737746 A EP09737746 A EP 09737746A EP 2271985 A2 EP2271985 A2 EP 2271985A2
Authority
EP
European Patent Office
Prior art keywords
data
data processing
assigned
validity
data object
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP09737746A
Other languages
English (en)
French (fr)
Inventor
Norbert Peters
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hansa-Datenservice Gowarsch & Co
Original Assignee
Hansa-Datenservice Gowarsch & Co
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hansa-Datenservice Gowarsch & Co filed Critical Hansa-Datenservice Gowarsch & Co
Publication of EP2271985A2 publication Critical patent/EP2271985A2/de
Withdrawn legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs

Definitions

  • the present invention relates to a data processing device with implemented data processing processes and to a method for processing data by one or more data processing processes.
  • Data processing devices with data processing processes implemented therein for processing data, and in particular automated data processing devices, are known.
  • a sequence of individual calculation instructions or binary machine instructions controls the operation of the data processing device.
  • a set of individual calculation instructions is called a computer program or short program.
  • To create a computer program there are a variety of programming languages, which allow the formulation of the sequence of individual machine commands in a human-understandable form, wherein a program created in the programming language program is also referred to as source code.
  • a program created by means of a programming language in a form understandable to humans must now be converted into a binary machine program that can be read by the data processing device so that it can execute the sequence of individual machine commands.
  • compilers or interpreters there are special computer programs such as compilers or interpreters.
  • a compiler converts and stores a source code into a binary machine program, while an interpreter reads in the source code, converts it into binary machine instructions, and executes the machine instructions directly without storing them.
  • a data processing process implemented in a data processing device can only be changed with a certain effort. For this it is first necessary to modify the source code accordingly. If the data processing process is implemented in the data processing device by means of a binary machine program, the complete changed source code must be compiled and transferred to the memory of the data processing device in the event of a change. If the data processing device has an interpreter, compilation of the source code can indeed be dispensed with, nevertheless it is necessary in this case to transfer the complete changed source code into the memory of the data processing device.
  • a further increase in the speed and a further reduction in the cost of changes in data processing processes results from the fact that in particular for elongated and confusing source codes to be changed calculation instructions no longer need to be cumbersome to identify.
  • the individual data objects allow rather, a targeted access to a data object with the sequence of calculation instructions to be changed.
  • the method according to the invention can be a computer-implemented method, wherein the computer program product can provide for automated control of the data processing device or of a device comprising the data processing device and thereby for automated execution of the method.
  • Respective sequences of calculation instructions of at least two data objects can be respective sub-processes of the same data processing process or of two different data processing processes which are to be executed successively to execute an overall process. For example, as an outcome of executing a first sequence of calculation instructions of a first data object, an identification may be output, wherein the identification matches the identification of a second data object comprising a second sequence of calculation instructions to be subsequently executed to subsequently identify that second data object and the second one In addition, in the execution of the first sequence of calculation instructions, data may be generated that is at least partially processed when executing the second sequence of calculation instructions. In this way, the provision of corresponding data objects, the successive execution of any number of sequences of Kalkungsanan- instructions is possible.
  • conditional branches and loops as frequently occur in conventional computer programs, can be replaced by such successively executable sequences of calculation instructions.
  • the occurrence of conditional branches and loops is also possible within the sequence of calculation instructions of a single data object.
  • conditional branches and loops are preferably achieved by successively executable sequences of calculation instructions of different data objects. sets, since this significantly increases the computing speed of the data processing device.
  • sequences of calculation instructions of at least two data objects of the same data processing process or of two different data processing processes may also be alternative processes, whereby when executing the data processing process or both data processing processes exactly one of these sequences of calculation instructions can be executed.
  • Such a data processing process can be adapted, for example, to different processing modes, whereby a corresponding data object is identified depending on the processing mode.
  • the calculation instructions of at least one sequence of calculation instructions in a character-coded format are preferably present in the relevant data object. If the calculation instructions are in a character-coded format, there is no need to compile the source code. Furthermore, this allows a complete separation of basic technical calculation instructions, which are available as binary machine instructions, and calculation instructions, which concern the logical processing of the data and are available as parameters in the character-coded format. Previously necessary programming activities in the creation and maintenance of data processing processes account for such a separation.
  • the calculation instructions are particularly preferably in XML format, since this is a common and widespread format. Files in XML format are readable by most interpreters and thus platform-independent.
  • At least two data objects of two different data processing processes are assigned the same identification.
  • at least one predefined data processing category can be provided, wherein at least one of the data objects is assigned to at least one data processing category via its associated identification and the data processing device is furthermore set up to process data specifying a data processing category, wherein the data processing device identifies a respective data object when processing data by means of one data processing process or several different data processing processes only if the data object is assigned to the predetermined data processing category.
  • a hierarchy in the form of a branched tree structure may exist between the data processing categories, so that, for example, one or more data processing categories assigned to one data processing category are assigned to each data processing category, and each of these data processing categories in turn has one or more data processing categories even deeper in the hierarchy are assigned, and so on.
  • Data processing categories can also be used to categorize the data to be processed by the data processing processes and to ensure that corresponding data are processed according to the given data processing category.
  • a data processing device is particularly preferred in which at least part of the data to be processed is assigned to at least one data processing category and the data processing device is set up to process data specifying a data processing category by assigning at least part of those data assigned to a data processing category Processes data assigned to the given data processing category. Further, it is advantageous to provide a search function which, when specifying a data processing category, indicates all data objects and / or data assigned to that data processing category to allow quick access to data objects and data of a particular data processing category.
  • a data processing device can be set up in such a way that it assigns at least one data object or each data object a respectively unique identifier and / or a globally unique identifier and / or a GUID (Globally Unique Identifier).
  • the unique identifier may be an identifier that is unique within the device or within any given system to which the device belongs. In the simplest case, this can be an identification number, an identification code or a uniform source locator or URL (Uniform Resource Locator).
  • Globally unique identifiers are known from distributed computer systems. Thus, it is known in particular for globally unique identifiers to generate individual such identifiers involving time stamps.
  • identifiers with such low probability of a coincidence of the identifiers that a single identifier is very likely to occur only once in the whole world and is therefore designated as unique globally or globally.
  • An example of a globally unique identifier is Globally Unique Identifier or GUID.
  • the data processing device has a memory for storing the data objects while assigning a respective validity time, wherein the data processing device is set up by overwriting a first data object, which is assigned a first validity time by a second data object to the second Assign a second validity period to the data object that is younger than the first validity period, and the second data object, while retaining the storage of the first data object and assigning the same ben Identification as the first data object to store, and wherein the data processing device is further adapted to process data by the data processing process under specification of an identification and a reference time by identifying them based on the identification of the same associated data objects, of all identified data objects, which relative to the reference time, assigns the oldest validity period, executes the calculation instructions of the sequence of calculation instructions encompassed by the identified and selected data object, and processes the data by executing the calculation instructions, or, if all data objects identified have a more recent validity time relative to the reference time is, apart from processing the data.
  • a very particularly preferred embodiment of the invention is a data processing device which, in subsequent successive overwrites of data objects to which the same identification is assigned, assigns a new data objects, each new data object a respective validity time that is younger than the validity times of all stored data objects with this identification the same data processing process, and stores the new data object with the validity time assigned to it while assigning the same identification and retaining the storage of all data objects of this identification.
  • the first data object in the case of overwriting the first data object by the second data object, the first data object is not deleted, but instead the storage of the first data object is retained. Once a data object has been stored, it will not be deleted at any time even with any number of subsequent overwrites of data objects with the same identification. Any loss of data is therefore excluded.
  • the first data object thus overwritten can also be identified at any time after it has been overwritten.
  • a reference time is predetermined when identifying a data object, which is relatively older relative to the second validity time and relative to the first validity time.
  • a reference time is specified that is younger than the second one ⁇
  • any reference times can be specified, whereby the reference time can also be younger or older than all validity times of all stored data objects of an identification.
  • the data object with the most recently assigned validity time is identified; in the latter case, however, no data object is identified because there is no data object with a validity time older than the reference time.
  • validity times are assigned to the new data objects that are respectively younger than the validity time assigned to the respective overwritten data object, the respective identification is clearly defined for each reference time and even if several stored data objects are present The data objects of this identification when specifying a reference time is to be identified in each case.
  • the first validity time may correspond to a time that is arbitrarily far in the past relative to the time of storing the first data object, or that is arbitrarily far in the future relative to the time of storing the first data object.
  • the second validity time is not limited to such a time as is or corresponds to the time at which the second data object is stored; rather, it may be arbitrarily far in the future analogously relative to the time of storing the second data object.
  • a data object having an assigned validity time which is relative to the time of identification in the future is not read out either , Assuming that the reference time is always the current time at which the identification takes place. If such a data object is not read out until access occurs at a time after the validity time assigned to the data object.
  • this embodiment of the present invention proves to be flexible in overwriting stored data objects because it allows for future rewriting of stored data objects without the need to provide any special facilities designed to measure the time and execute the override at a given time.
  • the data processing device is set up for the automatic specification of a reference time, which corresponds to a time at which the identification of the data object takes place, provided that a specification for the reference time does not occur. This ensures that a data object is always identified with an assigned validity time that is older than the current time at which it is identified, and that of all data objects with assigned validity times that are older than the current time of access each most recent validity period is assigned.
  • At least one data object or each data object is assigned a respective time of storage of the relevant data object as validity time.
  • the validity period can, for example, be accurate to the second, to the minute, to the hour or to the exact day.
  • a data object is assigned, in addition to the current date to the second, exactly the time as validity time at which the data object was stored.
  • the data object is assigned, in addition to the current date to the minute or to the hour, exactly as the validity time at which the data object was stored.
  • day-specific validity times usually suffice, in which the data object is assigned the date of the day as the validity period at which the data object was stored.
  • At least one data object or each data object is preferably assigned a respectively unique identifier and / or a globally unique identifier and / or a GUID.
  • respective unique identifiers and respective validity periods can also be combined to form a routing identifier.
  • a routing identifier can be used to uniquely define which data object is to be identified from a plurality of stored data objects of the same identification, by identifying the data object whose routing identifier has the most recent validity period, and, on the other hand, by using data objects unique to the routing identifier Identification beyond unambiguously addressed. Because in the case of a Leitkennung only a single size for the addressing and identification of data objects instead of two as in separate use of identifier and Validity period must be provided, reduces the necessary administrative burden.
  • the data processing device is further configured to replace at least one given data object with an assigned validity time by a third data object by deleting the predetermined data object, storing the third data object and assigning the validity date previously assigned to the given data object to the third data object.
  • a replacement erroneously stored data objects can be corrected.
  • the sequence of calculation instructions of a data object present in the character-encoded format may have a typing or typing error, or the data object to be stored has been mistakenly mistakenly associated with another data object which, instead of the correct data object, is assigned to the correct data object validity period has been stored. Then, the erroneous or wrong data object can be easily replaced by the correct data object in the manner described.
  • the validity period assigned to the given data object is assigned a protocol
  • the data processing device is set up to note the replacement in the protocol when the predetermined data object is replaced by the third data object and thereby the specified data object or the sequence of calculation instructions included in it into the protocol copy.
  • the protocol can in particular have a character-coded format or an XML format. With such a protocol, all replacements made the given data object can be traced comprehensible. A log provides a quick and convenient overview of the historical history of completed data object replacements that have been assigned the applicable validity time.
  • the protocol is advantageously used in order to avoid data losses in the case of substitutions of stored data objects, since with a replacement the given or replaced data object in question is actually deleted.
  • the given data object is copied to the log, it is after Although the replacement is deleted outside of the protocol, no loss of data occurs because there is a copy of the deleted data object in the log.
  • respective times can also be noted in the protocol for which a replacement of the given data object took place.
  • a person can be noted, which has caused the override.
  • a log can be assigned to a validity period immediately after saving the data object to which the validity time is assigned.
  • a protocol can also be generated only when the replacement takes place and assigned to the validity time of the given data object.
  • the data processing device has a server for communication via a bi- or multidirectional network or via the Internet with one or more components of a client / server architecture.
  • a data processing device is capable of communicating over arbitrary distances with individual components of the client / server architecture, wherein connections between the data processing device and the individual components as well as the components with each other be any wired or wireless connections, such as air interfaces can.
  • a data processing device may be part of a device, which further comprises a database system for storing data elements of specific attributes and for accessing stored data elements, wherein the database system reads out the data element when accessing a stored data element and the read data element as to be processed Transfers data to the data processing device.
  • the database system generally includes a database, which is the database of stored data items, database management software called a database management system.
  • At least one data element can be assigned to at least one predefined data processing category and the database system can be set up to access the data element only if the data element is assigned to the predetermined data processing category when a data processing category is specified.
  • the database system of this device as in the case of the already described storage of data objects, can be set up with assignment of a validity period for the storage of data elements with assignment of a respective validity time and in the case of overwriting of a first data element of a given validity period.
  • the Database system is further set up for accessing data elements of the predetermined attribute under specification of a reference time and accesses in such an access of all stored data elements of the predetermined attribute, which is assigned relative to the reference time older validity time, the one with the most recent validity period access, or if all data elements of the given attribute are assigned a validity time that is younger relative to the reference time, disregards access to a data element.
  • the device or database system may be configured to access data elements of the given attribute for automatically specifying a reference time, absent a reference time reference which corresponds to a time to which access is made.
  • the database system of the device can be set up for historical storage by assigning at least one data element or each data element a respective time of storage of the relevant data element as validity time.
  • the assignment of a respective unique identifier and / or a globally unique identifier and / or a GUID to at least one data element or each data element can be done by the database system for the reasons already mentioned.
  • the database system is preferably set up to replace at least one given data element with an assigned validity time by a third data element by deleting the predetermined data element, storing the third data element and assigning the validity date previously assigned to the given data element to the third data element. Incorrectly stored data elements are thus corrected in an analogous manner, as is also possible with incorrectly stored data objects.
  • the protocol assigned to the given data element can also be assigned a protocol, and the device can be set up to record the replacement of the given data element by the third data element in the protocol and to copy the given data element into the protocol.
  • the protocol may be a character-encoded format or an XML format.
  • At least one data element and the validity period assigned to it or several data elements and the validity times assigned to them form at least one data group.
  • At least one or more data elements or one or more data groups may be associated with a respective unique identifier or a respective globally unique identifier or GUID.
  • data groups can be used to group and uniformly manage data elements with attributes that have a logical relationship.
  • a data processing process can repeatedly access data elements of a first attribute as well as data elements of a second attribute. In such a case, it is advantageous to combine the data elements of the first attribute and the data elements of the second attribute into a data group and to manage them uniformly as a data group.
  • a data group as such can be assigned a unique identifier or a globally unique identifier or a GUID for addressing them, so that data groups can be loaded between applications or modules without overwriting each other.
  • at least one of the data elements of at least one data group may be a unique identifier or a globally unique identifier or GUID of another data element or data group with which a logical relation of the data group exists, such that the identifier of the other data element or Data group in the data group is treated as a common data item.
  • an indicator may be a simple binary variable used to identify particular states. An indicator can also be set, deleted or read out.
  • an indicator may determine whether or not a data item or group of data is publicly available.
  • indicators may indicate the membership of the data element or the data group to the device or a component thereof, such as the database system.
  • An indicator may also be one that indicates whether the data item or group of data is currently being used by an application.
  • the indicator of at least one data element or of a data group is a validity end time, the database system, after exceeding the validity end time, refraining from reading out this data element or data group.
  • This makes it possible to specify a type of validity period for each data group or data element of a given attribute, during which it is possible to read out the data group or data element when accessing data groups or data elements of this attribute, whereby a readout does not take place after the validity period has expired or after the validity end time more is possible.
  • time-critical working or processing of data elements or data groups can be regulated with such an indicator.
  • the indicator can also be a period duration.
  • the validity period of a data item may be at least similar an indicator of at least one data group is a validity start time indicating when the data group in question has been released for working or processing.
  • the device has at least one inheritable pattern data group with predefined data elements, wherein the device is set up to provide a specific indicator for a data group generated by inheritance of the pattern data group via which a reference to the pattern data group can be established for the data group thus generated.
  • a pattern data group may be provided for groups of data which are repeatedly generated in the same form. Then, instead of completely regenerating a new data group each time, the corresponding pattern data group can simply be inherited, with the data elements contained in the inherited pattern data group being overwritten by corresponding data elements of the data group to be generated, thereby obtaining a data group with the desired data elements.
  • a specific indicator is provided for the data group generated by the inheritance of the pattern data group, via which at any time for the data group thus generated a reference to the respective pattern data group from which a data group has emerged can be produced. Changes in the pattern data group can then be transmitted via this indicator directly to the data group resulting from the pattern data group.
  • the database system of the device preferably comprises at least one database for storing data elements and / or data groups and at least one main memory and is adapted to read stored data elements and / or data groups from the database and write to the main memory and in the case of Memory takes place Replacement of the read-out data element and / or a data element comprised of the read data group by a fourth data element to overwrite the associated data item stored in the database in the database by the fourth data element.
  • Such a device ensures that in the case of unforeseen disruptions during the processing of the data group in the main memory, such as a system crash, changes to the data elements or data groups processed in the main memory are not lost and quickly re-stored in the main memory when restarting Are available.
  • the read-out data group and / or the data element is preferably converted into a character-encoded format or an XML format or binary serialized, and the data group thus converted or serialized and / or the data element is written to the main memory in order to process certain data processing processes or application programs - enable or read the data group and / or the data element.
  • the device may be implemented in any computer or computer system. In particular, it is not limited to a single computer, but may include at least two or more interconnected computers. These can be linked by a bi-directional or multidirectional network or via the Internet.
  • the device may have a client / server architecture.
  • the data processing device and the database system can each have a server which, for example, can communicate with one another synchronously or asynchronously. In synchronous communication, a sender waits for a response from the receiver when sending data and is thereby blocked during the time of the wait, while in asynchronous communication the sending and receiving of data takes place staggered and without any need for a response from the receiver , To ensure independent operation, asynchronous communication between the data processing device and the database system is preferred.
  • asynchronous communication can also occur between the servers then set up, if the servers are those which, from the technical point of view, are designed exclusively for synchronous communication, by providing that the servers immediately upon receipt of data send an acknowledgment of receipt to the sender and after termination of a reconnect to the sender by receiving the data-started process.
  • the server of the database system can either be an element of the database management system or the server of the database system can be identical to the database management system.
  • the device may have a user interface.
  • the user interface may include a server or user interface server that may be physically located arbitrarily far away from the computing device and the database system.
  • the communication between the servers can be basically synchronous or asynchronous, but here as well an asynchronous communication is preferred for reasons of independent operation of user interface, data processing device and database system.
  • the user interface server may be configured to communicate with a client. Communication between the UI server and client can be synchronous or asynchronous. Users can use the client to connect to the user interface over any distance and submit a request to the user interface.
  • Part of the request may be the identification of a data object and any data to be processed by the data processing process to which the data object belongs.
  • the request and the data are transmitted to the data processing device via the user interface server. If further data stored in the database system are necessary for the processing of the data, these are requested by the data processing device from the database system, which requests the requested data. th reads data from the database and transmits it to the data processing device. The data is then processed after identification of the data object in the manner described. A possible result of this processing is stored, depending on the calculation instructions of the data object, either in a memory of the data processing device and / or transmitted to the user interface and from there to the client.
  • FIG. 1 shows a device with a data processing device
  • FIG. 2 shows a data processing device
  • FIG. 3 shows a tree structure of hierarchical data processing categories
  • FIG. 4 shows a flow chart of the method according to the invention
  • FIG. 5b data objects after overwriting of the data object of FIG. 5a);
  • FIG. 5c data objects after a further overwriting of one of the data objects of FIG. 5b);
  • FIG. 6 a database system
  • FIG. 7a a data element
  • FIG. 7b data elements after overwriting the data element of FIG. 7a);
  • FIG. 7c data elements after a further overwriting of one of the data elements of FIG. 7b);
  • FIG. 8 shows a data element with indicators
  • Figure 9 is a data group
  • FIG. 10 shows the data group of FIG. 9 after overwriting of a data element.
  • FIG. 1 shows a basic embodiment of a device 1 with a data processing device 2, a database system 3 and a user interface 4.
  • the device 1 has a client / server architecture in which the data processing device 2, database system 3 and user interface 4 are respectively implemented on different, spatially separated computers, the data processing device 2 a server 5, the database system 3 a database system server 6 and the user interface 4 comprises a user interface server 7.
  • Server 5 is set up to communicate with both user interface server 7 and database system server 6.
  • communication between the database system server 6 and the user interface server 7 is provided.
  • the communication between the three servers 5, 6 and 7 is asynchronous.
  • the user interface server 7 may also communicate with a client 8 via a synchronous communication link.
  • various data processing processes for processing data are implemented.
  • FIG. 2 shows a schematic representation of the data processing device 2, which has an arithmetic unit or a processor 9 and a memory 10 in addition to the server 5.
  • FIG. 2 shows a first group of a plurality of data objects 11 stored in the memory 10, by which a first data processing process 12 is implemented in the data processing device 2, and a second group of several data objects 13 is shown by which a second data processing process 14 in FIG the data processing device 2 is implemented.
  • Each of the data objects 11, 13 comprises a respective sequence of calculation instructions.
  • each of the data objects 11, 13 is present in XML format, ie the sequences of calculation instructions are in character-coded form. In particular, they are not compiled and are not available as binary machine instructions or binary machine program, but as source code.
  • each individual of the data objects 11 of the first group is assigned a respective GUID 15, a GUID 16 is assigned to each one of the data objects 13 of the second group, and each GUID 17, 18 is assigned to each of the data processing processes 12, 14. namely the first data processing process 12, the GUID 17 and the second data processing process 14, the GUID 18.
  • data processing processes 12, 14 shown in the data processing device 2 more, not visible in Figure 2 data processing processes implemented by respective groups of data objects stored in the memory 10.
  • Each individual one of the data objects 11, 13 of each group is assigned a respective identification, which is a simple string.
  • the association between identifications and data objects 11, 13 is unambiguous in each case, ie different identifications are uniquely assigned to all data objects 11, 13 of the same data processing process 12, 14. It is always but possible that a data object 11 from the first group is assigned the same identification as a data object 13 from the second group or any number of data objects from respective other groups of data objects.
  • the device 1 is used in the personnel management of an organization with employees in two different federal states BL1 and BL2. Each employee is paid for exactly one out of three different collective agreements TV1, TV2 and TV3, whereby the employee can either be an employee or an intern.
  • the difference between its gross and net salary is now to be calculated for any of the employees.
  • this difference is calculated in different ways. If the possible combinations of state, collective agreement and status of the employee are organized in a hierarchically branched tree structure, then the structure shown in FIG. 3 results.
  • each of these twelve alternatives there are twelve different alternatives for calculating the difference between gross and net salary.
  • exactly one single data object is provided, which comprises a corresponding sequence of calculation instructions for calculating the difference between gross and net salary according to the respective alternative.
  • twelve different data objects 11 which together form the first group of data objects 11.
  • Each of the twelve data objects 11 is uniquely assigned an identification within the first group. In other words, the mapping between data objects 11 and identifications within the first group is bijective.
  • the second data processing process 14 is set up for the calculation of the tax payments of any employees. Because the possible combinations from federal states, collective agreements and status of the employee are the same as in the case of the first data processing process 12, namely the combinations shown in the tree structure of Figure 3, there are also twelve alternative ways of calculating the data processing process 14. Consequently, the data processing process 14 is also implemented by twelve data objects 13 forming the second group of data objects with respective identifications associated with the data objects 13, each data object 13 corresponding to one of the twelve alternatives comprising a respective sequence of calculation instructions.
  • the twelve identifications associated with the twelve data objects 13 of the second group are identical to those twelve identifications associated with the twelve data objects 11 of the first group , This results from the equality of the possible combinations of state, collective agreement and status of the employee, which are to be considered for both data processing processes 12 and 14.
  • the identifications are character strings which consist of the letters and numbers used in FIG. 3, which are arranged in the sequence assigned to it for the identification of a specific data object 11, 13 within the sequence assigned to it as shown in FIG when tracing a path within the tree up to that particular data object 11, 13.
  • the character string "BL1TV1A” is assigned as identification to the extreme left data object 11, 13
  • the character string "BL2TV3P” is assigned to the extreme right data object 11, 13 as identification.
  • a data object 11, 13 is identified whose sequence of calculation instructions is designed for an employee who is employed in the federal state BL1 under the collective agreement TV1 as an employee, while using the character chain "BL2TV3P" as identification a data object 11, 13 is designed whose sequence of calculation instructions is designed for an employee who, in the federal state BL2, is employed as a practical part of the collective agreement TV3. is busy.
  • the identifications of the intermediate data objects 11, 13 are formed accordingly.
  • step SO the data processing processes 12, 14 are implemented in the data processing device 2 by storing the data objects 11 and 13 with the respective identifications assigned to them in the memory 10 and grouping them into respective data processing processes 12, 14 with respective GUIDs 17, 18.
  • the client 8 establishes a connection with the user interface server 7 and transmits a request to the user interface 4.
  • the client 8 may request data stored in the database system 3.
  • the user interface server 7 communicates with the database system server 6, the requested data is read from a database of the database system 3, sent from the database system server 6 to the user interface server 7 and transmitted from this to the client 8.
  • the request from the client 8 requires processing of the data.
  • the client 8 transmits a request to the user interface server 7 for the tax levies of an employee employed in the state BL2 to whom the collective agreement TV2 applies and who is an intern P.
  • the user interface server 7 determines the identification of the data object 13 of the second data processing process 14 that contains the corresponding data
  • Sequence of calculation instructions for calculating these taxes includes and sends this identification, which is the string "BL2TV2P", together with further information about the employee, such as his name, to the server 5 of the data processing device 2. This corresponds to the step of predetermining an identification or the method step S2 in FIG. 4.
  • the server 5 From the database system server 6, the server 5 requests the data necessary for the calculation of the employee's income, which are stored in the database system 3 under the name of the employee.
  • the data on the employee's income are read from the database of the database system 3 and transmitted to the server 5.
  • the server 5 transfers both the data on the employee's income and the identification to the processor 9.
  • the processor 9 identifies the relevant data object 13 of the data processing process 14 on the basis of the identification, which corresponds to the step S3 in FIG in the following step S4, the calculation instructions of the sequence of calculation instructions encompassed by the identified data object 13.
  • the processor 9 reads, similar to an interpreter, the sequence of calculation instructions in XML format and, by executing the calculation instructions, processes the data on the employee's income. This corresponds to step S5 in FIG. 4.
  • step S6 the execution of a data processing process does not necessarily lead to the generation of any data as a result of the data processing process, which is why the inventive method according to FIG. 4 ends with step S6.
  • data processing process 14 when the data processing process 14 is executed, data is generated about the tax deductions of the employee in question, which after completion of the data processing process 14, which corresponds to the end of execution of the calculation instructions of the sequence of calculation instructions of the identified data object 13, as a result. Therefore, these computed data will, in extension of the basic procedure, 4, transferred from the processor 9 to the server 5 and transmitted by the latter to the user interface server 7, which forwards them to the client 8.
  • the calculated data may be stored in the memory 10 to hold it ready for eventual additions to the data stored in the database of the database system 3 or for the generation of later reports.
  • a special operating mode is provided which requires the specification of a data processing category.
  • the data stored in the database of the database system 3 are assigned to respective data processing categories.
  • a data processing category in the present example may be a specific state BL1 or BL2, a specific collective agreement TV1, TV2 and TV3 or a specific status of the employees. If the device 1 is operated in said operating mode and a specific data processing category is specified, then the identification of a data object 11, 13 and the reading out of data from the database system database 3 takes place only if the relevant data object 11, 13 or the data of the data object assigned data processing category is assigned or are.
  • FIG. 5 a shows a single data object 19 with a GUID 20 and a validity time 21, which was assigned to the data object 19 when it was stored in the memory 10.
  • the validity period 21 corresponds in the present case to the date on which the storage took place.
  • the data object 19 is now to be overwritten by a new data object with a new sequence of calculation instructions.
  • a new data object 22 is added to the data processing process to which the data object 19 belongs and stored in the memory 10, this new data object 22 being assigned a new validity time 23 which corresponds to the time at which the data object 22 is stored and consequently younger than that Validity period is 21.
  • the new data object 22 is assigned its own GUID 24, it is assigned the same identification as the data object 19.
  • the data object 19 remains unaffected, ie. the data object 19 is neither deleted nor changed in any other way, its memory state is instead retained.
  • the data processing process to which the data objects 19 and 22 belong is to be executed after the overwrite has been successful and the identification associated with the two data objects 19, 22 is specified, it is additionally necessary to specify a reference time in order to select one of the data objects 19, 22 to allow.
  • the current one automatically becomes Time of specification of the identification selected as the reference time and given. This is naturally younger than each of the validity times 21 and 23.
  • that of the two data objects 19 and 22 stored in the memory 10 to which the same identification is assigned is read out with the most recent validity time 23, in the present example the data element 22.
  • the effect of this override thus does not differ from the effect of conventional overrides, in which stored data objects are physically deleted: in the execution of the data processing process to which the data object belongs and in the specification of an identification associated with the data object, In both cases, the last stored data object is output, with which the previously stored data object has been overwritten.
  • the overwritten data object remains stored unchanged in the memory 10, while under conventional overwrites it may be physically erased and its information content thereby irretrievably lost.
  • the overwrite described permits access to the overwritten data object even after overwriting if necessary. Since the data object is assigned its own GUID, this facilitates the addressing of the data object when accessing the same. Unintentional deletion of data objects is therefore fundamentally excluded.
  • a reference time lying between the validity times 21 and 23 is specified when executing a data processing process
  • the device 1 selects the data object 19, since its validity period 21 is now the most recent of those validity times that are older than the reference time. If instead one specifies a reference time that is before the validity period 21 or is older than the validity time 21, no data object is selected because none of the validity times 21 and 23 are older than the reference time.
  • the data object 22 is again selected, since its validity time 23 is also the most recent of the validity times 21 and 23 in this case, which are both older than the reference time.
  • the data objects 19, 22, 25 are included, and given a reference time that lies before the validity period 21, as described above, none of the data objects 19, 22, 25 is selected, given a reference time between the validity period 21 and the validity time 23 If the data object 19 is read out, when a reference time between the validity period 23 and the validity period 26 is specified, the data object is kt 22 is selected, and given a reference time younger than the validity time 26, the data element 25 is selected.
  • the routing identifier instead of providing separate GUIDs and validity times, it is also possible to set up a routing identifier to which GUID and validity time are combined.
  • the device 1 is set up to replace stored data objects with other data objects. In order to avoid information losses in the replacement, the device 1 is also set up to generate a protocol in XML format, in which details of the replacement are noted.
  • FIGS. 5c) and 5d An example of a replacement is illustrated in FIGS. 5c) and 5d).
  • the data object 22 is to be replaced by a data object 28 without having to fear a loss of information.
  • a protocol 29 is generated and assigned to the validity period 23.
  • the replacement date and time an IP address of a computer from which the replacement was made, the replacement-causing user of the device 1, a copy of the sequence of calculation instructions included in the data object 22, and a note of change recorded.
  • the data object 22 is deleted and the data object 28 is stored with the assignment of the GUID 24 and the validity time 23 previously assigned to the data object 22.
  • the data element 22 no longer exists, its information content is not lost, since the sequence of calculation instructions included in it was noted in the protocol 29.
  • a protocol 29 is assigned.
  • the date and time of storage of the data object which need not necessarily coincide with the validity time assigned to the data object, is an IP address of a computer from which storage of the data object was initiated Storage of the data object inducing users and a note about the storage recorded in the protocol 29. If the data object is replaced by another data object at a later time, an additional corresponding note is made in the protocol 29, as explained above.
  • FIG. 6 shows the database system 3 of the device 1.
  • the database system 3 includes a database 30 and a main memory 31.
  • the database system server 6 is at the same time a database management system for managing the database system 3.
  • data elements 32 and data groups 33 are stored for the sake of clarity, only one data element 32 and 33 each data group.
  • Each data element 32 is assigned a GUID 34 and a validity time 35, while each data group 33 is assigned a GUID 36 and a validity start time 37.
  • a data element 38 in XML format which has been generated by reading out a data element 32 from the database 30 and converting it into an XML format, is shown by dashed lines. The reading out of the data element 32 has no influence on the storage of the data element 32 in the database 30.
  • a data group 39 in XML format by means of dashed lines is shown in the working memory 31 by reading a data group 33 has been generated from the database 30 and converting into an XML format, wherein here too the reading of the data group 33 has no influence on the memory state of the data group 33 in the database 30.
  • the data element 32 shown in FIG. 7 a) is stored in the database 30.
  • the data element 32 is a character string with the characters "Maier”, which denotes a last name. Since the data element 32 denotes a last name, it is a data element of the attribute "last name”.
  • the data element 32 is stored with the validity time 35 and the GUID
  • the validity time 35 in the present case has the value "24.09.2007” and corresponds to the day on which the data element 32 is stored in the database 30.
  • GUID 34 a four-digit number is assumed for simplicity, here the value "7777” Has.
  • the data element 32 of the attribute "last name” is now to be overwritten by a data element 40 of the same attribute "last name", which is a character string with the characters "miller.”
  • the data element 40 is stored in the database 30, whereby it the validity time 41 is assigned, which corresponds to the time of storing the data element 40 and in this case has the value "13.12.2007”.
  • the validity time 41 is therefore younger than the validity time 35.
  • the data element 40 is assigned its own GUID 42 with the value "7778."
  • the data element 32 remains untouched, ie the data element 32 is neither deleted nor otherwise changed, its memory state 7b) shows the situation after the data element 40 has been stored:
  • the data element 40 together with validity time 41 and GUID 42 is also stored in the database 30.
  • a reference time is given. According to a preset first operating mode of the database system 3, the current time of access is automatically selected and specified as the reference time. This is naturally younger than both validity times 35 and 41. This will subsequently be that of the two data elements stored in the database 30
  • the effect of the override thus does not differ from the effect of conventional overwriting methods in which stored data elements are overwritten and thereby physically deleted:
  • the overwritten data element remains stored unchanged in the database 30, whereas in conventional methods it may be physically deleted and its information content thereby irretrievably lost.
  • the described method allows to access the overwritten data item even after overwriting if necessary. If the data element is assigned its own identifier or, as in the present example, a GUID, this facilitates the addressing of the data element when accessing it. Unintentional deletion of data elements, for example when updating existing databases, is therefore fundamentally excluded.
  • other reference times can also be specified. If, for example, a reference time lying between the validity times 35 and 41 is specified when accessing data elements of the attribute "last name", then the database system 3 reads the data element 32, since its validity time 35 is now the most recent of those validity times that are older than the reference time. If instead one specifies a reference time which lies before the validity period 35 or which is older than the validity time 35, no data element is read out because none of the service times 35 and 41 are older than the reference time. Given a reference time which is relative to the time of access in the future, again the data element 40 is read out, since its validity time 41 in this case too is the most recent one of validity times 35 and 41, which are older than the reference time.
  • the access to data elements of the attribute "last name" becomes the one of the three stored data elements 32, 40, 43, which now has the most recent validity time 44 of all validity times 35, 41, 44 of the data elements 32, 40, 43 of the attribute "last name", ie the data element 43.
  • none of the data elements 32, 40, 43 output, when specifying a reference time between the validity time 35 and the validity time 41, the data element 32 is read out, given a reference time between the Validity period 41 and the validity period 44, the data element 40 is read out, and given a reference time which is younger than the validity time 44, For example, as in the first working mode of the database system 3, the time that is accessed or a relative to the access in the future time, the output of the data element 43 takes place.
  • the data element 32 could be assigned a routing identifier with the value "7777 24092007”
  • the data element 40 a routing identifier with the value "7778 13122007” instead of the GUID 42 and the validity period 41
  • Data element 43 instead of the GUID 45 and the validity time 44 a Leitkennung with the value "7779 04032008”.
  • the database system 3 is set up to replace stored data elements with other data elements. In order to avoid information losses in the replacement, the database system 3 is also set up to generate a protocol 46 in XML format, in which details of the replacement are noted.
  • FIGS. 7c) and 7d An example of a replacement will be made clear with reference to FIGS. 7c) and 7d).
  • the data element 40 is to be replaced by a data element 47 of the attribute "last name", which is the character string "Fischer”, without having to fear loss of information.
  • a log 46 is generated and assigned to the validity period 41.
  • the date and time of the replacement, an IP address of a computer from which the replacement was made, the replacement causing user of the database system 3, a copy of the character string "Mueller” and a note of change are kept outside of the protocol 46, the data element 40 is deleted and the data element 47 is stored with the GUID 42 and the validity time 41 assigned to the data element 40 being assigned
  • the data element 47 no longer exists outside the protocol 46, its information content is not lost since the character string "Mueller" was noted in the protocol 46.
  • a protocol 46 can alternatively be assigned to this validity period when a data element is first stored, if a validity period is assigned to the data element.
  • the date and time of storage of the data item which need not necessarily coincide with the validity time assigned to the data item, is an IP address of a computer from which storage of the data item storing the data item was initiated Data element causing user of the database system 3 and a note about the storage detained. If the data element is replaced by another data element at a later time, an additional corresponding note is made in the protocol as explained above.
  • FIG. 8 shows the data element 32 of FIG. 7a) with different indicators 48, 49, 50.
  • the indicator 48 with the value "3" indicates that the data element 32 is associated with the database system 3.
  • the indicator 49 with the value "P” allows public access to the data element 32. By means of appropriate changes of the indicator 49, the access to the data element 32 can be limited to a single person or groups of people or specific applications.
  • the indicator 50 designates a validity end time of the data element 32, in the present case "02.09.2008", beyond which the data element 32 loses its validity and is no longer read out. Further indicators may be provided to indicate, for example, that the data item in question is intended for deletion.
  • Such an indicator can be used to reduce the total volume of data stored in the database 30 by releasing data elements for which there is definitely no further interest by appropriately setting the aforementioned indicator for deletion. Further, an indicator may designate a period that indicates periodic accesses to the data element 32.
  • the indicators 48, 49, 50 can be assigned to the new data element 40 unchanged when the data element 32 is overwritten by the new data element 40, or the data element 40 can be assigned individual or all of the indicators 48, 49, 50 with new values. Furthermore, the data element 40 may be assigned fewer or more indicators 48, 49, 50 than the data element 32 overwritten by it.
  • Indicators as just described can also be provided correspondingly for individual or all of the data objects 11, 13 stored in the memory 10 of the data processing device 2.
  • FIG. 9 shows details of the data group 33.
  • the data group 33 comprises the data element 32 of Figure 7a) with the validity time assigned to it 35 and the GUID 34 and another data element 51 and its validity time 52 and GUID 53.
  • the data element 51 is a data element of the attribute
  • the data element 51 is assigned the validity time 52 with the value "11.02.2007” and the GUID 53 with the value "1389.”
  • the data group 33 as such is as above have been assigned the GUID 36, which according to Figure 9 has the value "2425".
  • the data group 33 is assigned as an indicator the validity start time 37, which in the present case coincides with the validity time 35.
  • the data group 33 is therefore stored of the data element 32 is enabled for reading.
  • the data group 33 can be extended by any number of data elements of any attributes, for example by a data element of the "address” attribute or by a data element of the "birthday” attribute. With the data group 33, personal data of individual persons can thus be conveniently managed.
  • FIG. 10 shows a situation after overwriting of the data element 32 of the data group 33 by the data element 40, as explained in connection with FIG. 7b).
  • the data group 33 comprises, in addition to the data element 32 and the data element 51, also the data element 40.
  • the GUID 36 of the data group 33 and its validity start time 37 have remained unchanged by the overwriting.
  • the data element 40 is read out as described above.
  • the data group 33 can also be used as a pattern data group for generating any number of data groups for managing data of different persons.
  • a data group for a particular person is then simply generated by copying the pattern data group and overwriting the data element 32 by the person's name and overwriting the data element 51 by the corresponding social security number of the respective person, the new data group thus generated having its own GUID and be assigned a separate validity start time.
  • an indicator is provided for the new data group, via which reference can be made at any time to the data group resulting from the inheritance of the pattern data group for the pattern data group. For example, I would like to use such an indicator to conveniently transfer changes in the pattern data group to the data group that has emerged from it.
  • the database system 3 shown in FIG. 6 is set up, substitutions or overwrites of the data elements 38 read into the main memory 31 or data elements of the data groups 39 read out into the main memory 31 immediately after successful replacement or overwriting in the main memory 31 corresponding to the data items 32 and data groups 33 stored in the database 30 according to one of the described methods. This prevents possible loss of information in the event of malfunctions of the database system 3, in which overwrites made in the volatile main memory 31, which have not yet been correspondingly stored in the database 30, are lost.
  • the device 1 Since both data objects and data elements are stored in the device 1 with the assignment of a respective validity period, a historical data management is achieved on the one hand. On the other hand, when a corresponding reference time is specified, the device 1 can be operated at any time together with data processing processes and data to be processed in a state in which the device was at the predetermined reference time. Signs list

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Es werden ein Datenverarbeitungsvorrichtung (2) und ein Verfahren zum Verarbeiten von Daten durch einen oder mehrere Datenverarbeitungsprozesse (12, 14) beschrieben, die es erlauben, implementierte Datenverarbeitungsprozesse schnell und mit möglichst geringem Aufwand zu ändern. In der Datenverarbeitungsvorrichtung (2) ist ein Datenverarbeitungsprozess (12, 14) durchwenigstens zwei Datenobjekte (11, 13, 19, 22, 25) mit jeweiligen den Datenobjekten (11, 13, 19, 22, 25) zugeordneten Identifikationen implementiert, wobei jedes Datenobjekt (11, 13, 19, 22, 25) eine jeweilige Sequenz von Kalkulationsanweisungen umfasst. Nach Vorgabe einer Identifikation wird eines der Datenobjekte (11, 13, 19, 22, 25) des Datenverarbeitungsprozesses (12, 14) anhand der Identifikation identifiziert. Kalkulationsanweisungen der vom identifizierten Datenobjekt (11, 13, 19, 22, 25) umfassten Sequenz von Kalkulationsanweisungen werden ausgeführt und die Daten werden mit Ausführen der Kalkulationsanweisungen verarbeitet.

Description

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

Claims

Ansprüche
1. Datenverarbeitungseinrichtung (2) zum Verarbeiten von Daten durch einen oder mehrere Datenverarbeitungsprozesse (12, 14), in der wenigstens ein Datenverarbeitungsprozess (12, 14) durch wenigstens zwei Datenobjekte (11, 13, 19, 22, 25) mit jeweiligen den Datenobjekten (11, 13, 19, 22, 25) zugeordneten Identifikationen implementiert ist, wobei jedes Datenobjekt (11 , 13, 19, 22, 25) eine jeweilige Sequenz von Kalkulationsanweisungen umfasst und wobei die Datenverarbeitungseinrichtung (2) zum Verarbeiten von Daten durch den Datenverarbeitungsprozess (12, 14) unter Vorgabe einer Identifikation eingerichtet ist, indem sie anhand der Identifikation eines der Datenobjekte (11 , 13, 19, 22, 25) identifiziert, die Kalkulationsanweisungen der vom identifizierten Datenobjekt (11, 13, 19, 22, 25) umfassten Sequenz von Kalkulationsanweisungen ausführt und die Daten mit Ausführen der Kalkulationsan- Weisungen verarbeitet.
2. Datenverarbeitungseinrichtung (2) nach Anspruch 1 , bei der jeweilige Sequenzen von Kalkulationsanweisungen wenigstens zweier Datenobjekte (11 , 13, 19, 22, 25) desselben Datenverarbeitungsprozesses (12, 14) oder zweier verschiedener Datenverarbeitungsprozesse (12, 14) sukzessiv ausführbar sind.
3. Datenverarbeitungseinrichtung (2) nach Anspruch 1 oder 2, bei der bei Ausführen des Datenverarbeitungsprozesses (12, 14) die Sequenzen von Kalkulationsanweisungen wenigstens zweier Datenobjekte (11, 13, 19, 22, 25) desselben Datenverarbeitungsprozesses (12, 14) oder zweier verschiedener Datenverarbeitungsprozesse (12, 14) alternativ ausführbar sind.
4. Datenverarbeitungseinrichtung (2) nach einem der vorhergehenden Ansprüche, bei der die Kalkulationsanweisungen wenigstens einer Sequenz von Kalkulationsanweisungen in einem zeichenkodierten Format in dem betreffenden Datenobjekt (11, 13, 19, 22, 25) vorliegen.
5. Datenverarbeitungseinrichtung (2) nach Anspruch 4, bei der die Kalkulationsanweisungen im XML-Format vorliegen.
6. Datenverarbeitungseinrichtung (2) nach einem der vorhergehenden Ansprüche, bei der wenigstens zwei Datenobjekten (11 , 13, 19, 22, 25) zweier verschiedener Datenverarbeitungsprozesse (12, 14) die gleiche Identifikation zugeordnet ist.
7. Datenverarbeitungseinrichtung (2) nach einem der vorhergehenden Ansprüche mit wenigstens einer vordefinierten Datenverarbeitungskategorie, wobei wenigstens eines der Datenobjekte (11 , 13, 19, 22, 25) über die ihm zugeordnete Identifikation wenigstens einer Datenverarbeitungskategorie zugewiesen ist und die Datenverarbeitungseinrichtung (2) ferner zum Verarbeiten von Daten unter Vorgabe einer Datenverarbeitungskategorie eingerichtet ist, wobei die Datenverarbeitungseinrichtung (2) bei Verarbeiten von Daten mittels eines Datenverarbeitungsprozesses (12, 14) oder mehrerer unterschiedlicher Datenverarbeitungsprozesse (12, 14) ein jeweiliges Datenobjekt (11, 13, 19, 22, 25) nur dann identifiziert, wenn das Datenobjekt (11 , 13, 19, 22, 25) der vorgegebenen Datenverarbeitungskategorie zugewiesen ist.
8. Datenverarbeitungseinrichtung (2) nach Anspruch 7, bei der zwischen den Datenverarbeitungskategorien eine Hierarchie in Form einer verzweigten Baumstruktur existiert.
9. Datenverarbeitungseinrichtung (2) nach einem der Ansprüche 7 oder 8, bei der wenigstens ein Teil der zu verarbeitenden Daten wenigstens einer Datenverarbeitungskategorie zugewiesen ist und die Datenverarbeitungseinrichtung (2) zum Verarbeiten von Daten unter Vorgabe einer Datenverarbeitungskategorie eingerichtet ist, indem sie von den einer Datenverarbeitungskatego- rie zugewiesenen Daten wenigstens einen Teil derjenigen Daten verarbeitet, die der vorgegebenen Datenverarbeitungskategorie zugewiesen sind.
10. Datenverarbeitungseinrichtung (2) nach einem der Ansprüche 7 bis 9, bei der eine Suchfunktion vorgesehen ist, die bei Vorgabe einer Datenverarbeitungskategorie alle Datenobjekte (11 , 13, 19, 22, 25) und/oder Daten anzeigt, die dieser Datenverarbeitungskategorie zugewiesen sind.
11. Datenverarbeitungseinrichtung (2) nach einem der vorhergehenden Ansprüche, die wenigstens einem Datenobjekt (11 , 13, 19, 22, 25) oder jedem Datenobjekt (11 , 13, 19, 22, 25) eine jeweils eindeutige Kennung und/oder eine weltweit eindeutige Kennung und/oder eine GUID (20, 24, 27) zuweist.
12. Datenverarbeitungseinrichtung (2) nach einem der vorhergehenden Ansprüche mit einem Speicher (10) zum Speichern der Datenobjekte (11 , 13, 19, 22, 25) unter Zuweisung einer jeweiligen Validitätszeit (21, 23, 26), wobei die Datenverarbeitungseinrichtung (2) eingerichtet ist, bei Überschreiben ei- nes ersten Datenobjekts (11 , 13, 19, 22, 25), dem eine erste Validitätszeit (21 , 23, 26) zugewiesen ist, durch ein zweites Datenobjekt (11 , 13, 19, 22, 25) dem zweiten Datenobjekt (11 , 13, 19, 22, 25) eine zweite Validitätszeit (21, 23, 26) zuzuweisen, die jünger ist als die erste Validitätszeit (21, 23, 26), und das zweite Datenobjekt (11 , 13, 19, 22, 25) unter Beibehaltung der Speiche- rung des ersten Datenobjekts (11 , 13, 19, 22, 25) und unter Zuordnung derselben Identifikation wie dem ersten Datenobjekt (11 , 13, 19, 22, 25) zu speichern, und wobei die Datenverarbeitungseinrichtung (2) ferner zum Verarbeiten von Daten durch den Datenverarbeitungsprozess (12, 14) unter Vorgabe einer Identifikation sowie einer Bezugszeit eingerichtet ist, indem sie anhand der Identifikation derselben zugeordnete Datenobjekte (11 , 13, 19, 22, 25) identifiziert, von allen identifizierten Datenobjekten (11 , 13, 19, 22, 25), denen eine relativ zur Bezugszeit ältere Validitätszeit (21 , 23, 26) zugewiesen ist, dasjenige mit der jeweils jüngsten Validitätszeit (21 , 23, 26) auswählt, die Kalkulationsanweisungen der vom identifizierten und ausgewählten Datenobjekt (11, 13, 19, 22, 25) umfassten Sequenz von Kalkulationsanweisungen ausführt und die Daten mit Ausführen der Kalkulationsanweisungen verarbeitet oder, sofern allen identifizierten Datenobjekten (11 , 13, 19, 22, 25) eine relativ zur Bezugszeit jüngere Validitätszeit (21, 23, 26) zugewiesen ist, von einer Verarbeitung der Daten absieht.
13. Datenverarbeitungseinrichtung (2) nach Anspruch 12, die bei nachfol- genden sukzessiven Überschreibungen von Datenobjekten (11, 13, 19, 22,
25), denen die gleiche Identifikation zugeordnet ist, durch neue Datenobjekte (11 , 13, 19, 22, 25), jedem neuen Datenobjekt (11 , 13, 19, 22, 25) eine jeweilige Validitätszeit (21 , 23, 26) zuweist, die jünger ist als die Validitätszeiten (21, 23, 26) aller gespeicherten Datenobjekte (11, 13, 19, 22, 25) mit dieser Identifikation desselben Datenverarbeitungsprozesses (12, 14), und das neue Datenobjekt (11 , 13, 19, 22, 25) mit der ihm zugewiesenen Validitätszeit (21 , 23, 26) unter Zuordnung derselben Identifikation und unter Beibehaltung der Speicherung aller Datenobjekte (11 , 13, 19, 22, 25) dieser Identifikation speichert.
14. Datenverarbeitungseinrichtung (2) nach einem der Ansprüche 12 oder
13, die bei Ausbleiben einer Vorgabe für die Bezugszeit zur automatischen Vorgabe einer Bezugszeit eingerichtet ist, die einer Zeit entspricht, zu der die Identifikation des Datenobjekts (11 , 13, 19, 22, 25) erfolgt.
15. Datenverarbeitungseinrichtung (2) nach einem der Ansprüche 12 bis
14, die wenigstens einem Datenobjekt (11 , 13, 19, 22, 25) oder jedem Datenobjekt (11 , 13, 19, 22, 25) einen jeweiligen Zeitpunkt des Speicherns des betreffenden Datenobjekts (11, 13, 19, 22, 25) als Validitätszeit zuordnet.
16. Datenverarbeitungseinrichtung (2) nach einem der Ansprüche 12 bis
15, die ferner eingerichtet ist, wenigstens ein vorgegebenes Datenobjekt (22) mit einer zugewiesenen Validitätszeit (23) durch ein drittes Datenobjekt (28) zu ersetzen, indem sie das vorgegebene Datenobjekt (22) löscht, das dritte Datenobjekt (28) speichert und dem dritten Datenobjekt (28) die zuvor dem vorgegebenen Datenobjekt (22) zugewiesene Validitätszeit (23) zuweist.
17. Datenverarbeitungseinrichtung (2) nach Anspruch 16, wobei der dem vorgegebenen Datenobjekt (22) zugewiesenen Validitätszeit (23) ein Protokoll (29) zugeordnet ist und die Datenverarbeitungseinrichtung (2) eingerichtet ist, bei Ersetzen des vorgegebenen Datenobjekts (22) durch das dritte Datenob- jekt (28) die Ersetzung im Protokoll (29) zu vermerken und dabei das vorgegebene Datenobjekt (22) in das Protokoll (29) zu kopieren.
18. Datenverarbeitungseinrichtung (2) nach Anspruch 17, bei der das Protokoll (29) ein zeichenkodiertes Format oder ein XML-Format aufweist.
19. Datenverarbeitungseinrichtung (2) nach einem der vorhergehenden Ansprüche, die einen Server (5) zur Kommunikation über ein bi- oder multidi- rektionales Netzwerk oder über das Internet mit einer oder mehreren Komponenten (3, 4) einer Client/Server-Architektur (1) aufweist.
20. Vorrichtung (1) mit einer Datenverarbeitungseinrichtung (2) nach einem der vorhergehenden Ansprüche und einem Datenbanksystem (3) zum Speichern von Datenelementen (32, 40, 43, 51) spezifischer Attribute sowie zum Zugreifen auf gespeicherte Datenelemente (32, 40, 43, 51), wobei das Daten- banksystem (3) bei einem Zugriff auf ein gespeichertes Datenelement (32, 40, 43, 51) das Datenelement (32, 40, 43, 51) ausliest und das ausgelesene Datenelement (32, 40, 43, 51) als zu verarbeitende Daten an die Datenverarbeitungseinrichtung (2) übergibt.
21. Vorrichtung (1) nach Anspruch 20 mit einer Datenverarbeitungseinrichtung (2) nach einem der Ansprüche 7 bis 10, bei der wenigstens ein Datenelement (32, 40, 43, 51) wenigstens einer vordefinierten Datenverarbeitungskategorie zugewiesen ist und das Datenbanksystem (3) eingerichtet ist, bei Vorgabe einer Datenverarbeitungskategorie nur dann auf das Datenelement (32, 40, 43, 51) zuzugreifen, wenn das Datenelement (32, 40, 43, 51) der vorgegebenen Datenverarbeitungskategorie zugewiesen ist.
22. Vorrichtung (1) nach einem der Ansprüche 20 oder 21 , bei der das Datenbanksystem (3) zur Speicherung von Datenelementen (32, 40, 43, 51) unter Zuweisung einer jeweiligen Validitätszeit (35, 41, 44, 52) eingerichtet ist und die im Falle eines Überschreibens eines ersten Datenelements (32, 40, 43, 51) eines vorgegebenen Attributs, dem eine erste Validitätszeit (35, 41 , 44, 52) zugewiesen ist, durch ein zweites Datenelement (32, 40, 43, 51) des vorgegebenen Attributs dem zweiten Datenelement (32, 40, 43, 51) eine zweite Validitätszeit (35, 41 , 44, 52) zuweist, die jünger ist als die erste Validitätszeit (35, 41, 44, 52), und das zweite Datenelement (32, 40, 43, 51) unter Bei- behaltung der Speicherung des ersten Datenelements (32, 40, 43, 51) speichert, wobei das Datenbanksystem (3) ferner für Zugriffe auf Datenelemente (32, 40, 43, 51) des vorgegebenen Attributs unter Vorgabe einer Bezugszeit eingerichtet ist und bei einem solchen Zugriff von allen gespeicherten Datenelementen (32, 40, 43, 51) des vorgegebenen Attributs, denen eine relativ zur Bezugszeit ältere Validitätszeit (35, 41 , 44, 52) zugewiesen ist, auf dasjenige mit der jeweils jüngsten Validitätszeit (35, 41 , 44, 52) zugreift oder, sofern allen Datenelementen (32, 40, 43, 51) des vorgegebenen Attributs eine relativ zur Bezugszeit jüngere Validitätszeit (35, 41 , 44, 52) zugewiesen ist, von einem Zugriff auf ein Datenelement (32, 40, 43, 51) absieht.
23. Vorrichtung (1) nach Anspruch 22, bei der das Datenbanksystem (3) bei Ausbleiben einer Vorgabe für die Bezugszeit bei einem Zugriff auf Datenelemente (32, 40, 43, 51) des vorgegebenen Attributs zur automatischen Vorgabe einer Bezugszeit eingerichtet ist, die einer Zeit entspricht, zu der der Zu- griff erfolgt.
24. Vorrichtung (1) nach einem der Ansprüche 22 oder 23, bei der das Datenbanksystem (3) wenigstens einem Datenelement (32, 40, 43, 51) oder jedem Datenelement (32, 40, 43, 51) einen jeweiligen Zeitpunkt des Speicherns des betreffenden Datenelements (32, 40, 43, 51) als Validitätszeit (35, 41 , 44, 52) zuordnet.
25. Vorrichtung (1) nach einem der Ansprüche 20 bis 24, bei der das Datenbanksystem (3) wenigstens einem Datenelement (32, 40, 43, 51) oder jedem Datenelement (32, 40, 43, 51) eine jeweils eindeutige Kennung und/oder eine weltweit eindeutige Kennung und/oder eine GUID (34, 42, 45, 53) zu- weist.
26. Vorrichtung (1) nach einem der Ansprüche 20 bis 25, bei der das Datenbanksystem (3) ferner eingerichtet ist, wenigstens ein vorgegebenes Datenelement (40) mit einer zugewiesenen Validitätszeit (41) durch ein drittes Datenelement (47) zu ersetzen, indem sie das vorgegebene Datenelement (40) löscht, das dritte Datenelement (47) speichert und dem dritten Datenelement (47) die zuvor dem vorgegebenen Datenelement (40) zugewiesene Validitätszeit (41) zuweist.
27. Vorrichtung (1) nach Anspruch 26, wobei der dem vorgegebenen Datenelement (40) zugewiesenen Validitätszeit (41) ein Protokoll (46) zugeordnet ist und das Datenbanksystem (3) eingerichtet ist, die Ersetzung des vorgegebenen Datenelements (40) durch das dritte Datenelement (47) im Protokoll (46) zu vermerken und dabei das vorgegebene Datenelement (40) in das Protokoll (46) zu kopieren
28. Vorrichtung (1) nach Anspruch 27, bei der das Protokoll (46) ein zeichenkodiertes Format oder ein XML-Format aufweist.
29. Vorrichtung (1) nach einem der Ansprüche 20 bis 28, bei der wenigstens ein Datenelement (32, 51) und die ihm zugewiesene Validitätszeit (35, 52) oder mehrere Datenelemente (32, 51) und die ihnen zugewiesenen Validi- tätszeiten (35, 52) eine Datengruppe (33) bilden.
30. Vorrichtung (1) nach Anspruch 29, bei der wenigstens einer oder mehreren Datengruppen (33) eine jeweilige eindeutige Kennung oder eine jeweilige weltweit eindeutige Kennung oder eine jeweilige GUID (36) zugeordnet ist.
31. Vorrichtung (1) nach einem der Ansprüche 29 oder 30, wobei wenigstens eines der Datenelemente wenigstens einer Datengruppe eine eindeutige Kennung oder eine weltweit eindeutige Kennung oder eine GUID (34, 42, 45, 53) eines anderen Datenelements (32, 40, 43, 51) oder einer anderen Daten- gruppe (33) ist, mit dem oder mit der eine logische Relation der Datengruppe besteht.
32. Vorrichtung (1) nach einem der Ansprüche 20 bis 31, wobei wenigstens einem Datenelement (32) und/oder wenigstens einer Datengruppe (33) we- nigstens ein Indikator (48, 49, 50) zugewiesen ist.
33. Vorrichtung (1) nach Anspruch 32, die ein Datenelement (32, 40, 43, 51) und/oder eine Datengruppe (33) löscht, wenn wenigstens ein Indikator wenigstens einen vorgegebenen Wert annimmt.
34. Vorrichtung (1) nach einem der Ansprüche 32 oder 33, bei der wenigstens einer der Indikatoren (49) für Zugriffsrechte auf das Datenelement (32, 40, 43, 51) oder die Datengruppe (33) bestimmend ist.
35. Vorrichtung (1) nach einem der Ansprüche 32 bis 34, bei der wenigstens ein Indikator (48) eine Zugehörigkeit des Datenelements (32, 40, 43, 51) oder der Datengruppe (33) zur Vorrichtung (1) oder einer Komponente (3) derselben anzeigt.
36. Vorrichtung (1) nach einem der Ansprüche 32 bis 35, bei der wenigstens ein Indikator eine aktuelle Benutzung des Datenelements (32, 40, 43, 51) oder der Datengruppe (33) durch eine Applikation anzeigt.
37. Vorrichtung (1) nach einem der Ansprüche 32 bis 36, wobei wenigstens ein Indikator (50) wenigstens eines Datenelements (32) oder einer Datengruppe (33) eine Validitätsendzeit ist und das Datenbanksystem (2) nach Überschreiten der Validitätsendzeit von einem Auslesen dieses Datenelements (32) oder der Datengruppe (33) absieht.
38. Vorrichtung (1) nach einem der Ansprüche 32 bis 37, wobei wenigstens ein Indikator wenigstens eines Datenelements (32, 40, 43, 51) oder einer Datengruppe (33) eine Periodendauer zur Regelung periodischer Zugriffe auf das Datenelement (32, 40, 43, 51) oder die Datengruppe (33) ist.
39. Vorrichtung (1) einem der Ansprüche 32 bis 38, bei der wenigstens ein Indikator wenigstens einer Datengruppe (32, 40, 43, 51) eine Validitätsstart- zeit ist.
40. Vorrichtung (1) nach einem der Ansprüche 29 bis 39, die wenigstens eine vererbbare Musterdatengruppe mit vorgegebenen Datenelementen (32,
40, 43, 51) aufweist, wobei die Vorrichtung (1) eingerichtet ist, für eine durch Vererbung der Musterdatengruppe erzeugte Datengruppe (33) einen spezifi- sehen Indikator vorzusehen, über den sich für die so erzeugte Datengruppe (33) ein Bezug zu der Musterdatengruppe herstellen lässt.
41. Vorrichtung (1) nach einem der Ansprüche 20 bis 40, bei der das Datenbanksystem (3) wenigstens eine Datenbank (30) zum Speichern von Da- tenelementen (32, 40, 43, 51) und/oder Datengruppen (33) sowie wenigstens einen Arbeitsspeicher (31) umfasst und eingerichtet ist, gespeicherte Datenelemente (32, 40, 43, 51) und/oder Datengruppen (33) aus der Datenbank (30) auszulesen und in den Arbeitsspeicher (31) zu schreiben und im Falle einer im Arbeitsspeicher (31) stattfindenden Ersetzung des ausgelesenen Da- tenelements (38) und/oder eines von der ausgelesenen Datengruppe (39) um- fassten Datenelements durch ein viertes Datenelement das zugehörige in der Datenbank (30) gespeicherte Datenelement (32) in der Datenbank (30) durch das vierte Datenelement zu überschreiben.
42. Vorrichtung (1) nach Anspruch 41, die die ausgelesene Datengruppe (33) und/oder das Datenelement (32) in ein zeichenkodiertes Format oder ein XML-Format umwandelt oder binär serialisiert und die so umgewandelte oder serialisierte Datengruppe (39) und/oder das Datenelement (38) in den Arbeitsspeicher (31) schreibt.
43. Vorrichtung (1) nach einem der Ansprüche 20 bis 42, die wenigstens zwei oder mehr miteinander verbundene Computer umfasst.
44. Vorrichtung (1) nach Anspruch 43, wobei die Computer durch ein bi- oder multidirektionales Netzwerk oder über das Internet miteinander verbindbar sind.
45. Vorrichtung (1) nach einem der Ansprüche 43 oder 44, bei der die Datenverarbeitungseinrichtung (2) und das Datenbanksystem (3) jeweils einen Server (5, 6) aufweisen, die eingerichtet sind, asynchron miteinander zu kommunizieren.
46. Vorrichtung (1) nach einem der Ansprüche 43 bis 45, die eine Benutzerschnittstelle (4) mit einem Benutzerschnittstellenserver (7) aufweist, der eingerichtet ist, mit der Datenverarbeitungseinrichtung (2) und/oder dem Datenbanksystem (3) zu kommunizieren.
47. Verfahren zum Verarbeiten von Daten durch einen oder mehrere Datenverarbeitungsprozesse (12, 14) mit den Schritten:
(a) Implementieren eines Datenverarbeitungsprozesses (12, 14) durch Vorsehen wenigstens zweier Datenobjekte (11 , 13, 19, 22, 25) mit jeweiligen den Datenobjekten (11 , 13, 19, 22, 25) zugeordneten Identifikationen, wobei jedes Datenobjekt (11 , 13, 19, 22, 25) eine jeweilige Sequenz von Kalkulationsanweisungen umfasst;
(b) Vorgeben einer Identifikation;
(c) Identifizieren eines der Datenobjekte (11, 13, 19, 22, 25) des Da- tenverarbeitungsprozesses (12, 14) anhand der Identifikation;
(d) Ausführen von Kalkulationsanweisungen der vom identifizierten Datenobjekt (11, 13, 19, 22, 25) umfassten Sequenz von Kalkulationsanweisungen; und (e) Verarbeiten der Daten mit Ausführen der Kalkulationsanweisungen.
48. Verfahren nach Anspruch 47, bei dem ferner im Schritt (a) wenigstens eine Datenverarbeitungskategorie vordefiniert wird und wenigstens eines der Datenobjekte (11 , 13, 19, 22, 25) über die ihm zugeordnete Identifikation wenigstens einer Datenverarbeitungskategorie zugewiesen wird, bei dem im Schritt (b) eine Datenverarbeitungskategorie vorgegeben wird und bei dem im Schritt (c) ein jeweiliges Datenobjekt (11 , 13, 19, 22, 25) nur dann identifiziert wird, wenn das Datenobjekt (11, 13, 19, 22, 25) der vorgegebenen Datenve- rarbeitungskategorie zugewiesen wurde.
49. Verfahren nach Anspruch 48, bei dem im Schritt (a) Datenverarbeitungskategorien in einer hierarchisch verzweigten Baumstruktur organisiert werden.
50. Verfahren nach einem der Ansprüche 48 oder 49, bei dem wenigstens ein Teil der zu verarbeitenden Daten wenigstens einer Datenverarbeitungskategorie zugewiesen wird und bei Vorgabe einer Datenverarbeitungskategorie von den dieser Datenverarbeitungskategorie zugewiesenen Daten wenigstens ein Teil verarbeitet wird.
51. Verfahren nach einem der Ansprüche 47 bis 50, bei dem wenigstens einem Datenobjekt (11 , 13, 19, 22, 25) oder jedem Datenobjekt (11 , 13, 19, 22, 25) eine jeweils eindeutige Kennung und/oder eine weltweit eindeutige Kennung und/oder eine GUID (20, 24, 27) zugewiesen wird.
52. Verfahren nach einem der Ansprüche 47 bis 51, bei dem Datenobjekte (11, 13, 19, 22, 25) unter Zuweisung einer jeweiligen Validitätszeit (21, 23, 26) gespeichert werden, und bei dem zum Überschreiben eines ersten Datenob- jekts (11, 13, 19, 22, 25), dem eine erste Validitätszeit (21 , 23, 26) zugewiesen wurde, durch ein zweites Datenobjekt (11 , 13, 19, 22, 25) dem zweiten Datenobjekt (11 , 13, 19, 22, 25) eine zweite Validitätszeit (21 , 23, 26) zugewiesen wird, die jünger ist als die erste Validitätszeit (21 , 23, 26), und das zweite Datenobjekt (11 , 13, 19, 22, 25) unter Beibehaltung der Speicherung des ersten Datenobjekts (11 , 13, 19, 22, 25) und unter Zuordnung derselben Identifikation wie dem ersten Datenobjekt (11 , 13, 19, 22, 25) gespeichert wird, und wobei zum Verarbeiten von Daten durch den Daten verarbeitungs- prozess (12, 14) eine Identifikation sowie eine Bezugszeit vorgegeben wird, anhand der Identifikation dem Datenverarbeitungsprozess (12, 14) zugeordnete Datenobjekte (11 , 13, 19, 22, 25) identifiziert werden, von allen identifizierten Datenobjekten (11 , 13, 19, 22, 25), denen eine relativ zur Bezugszeit ältere Validitätszeit (21 , 23, 26) zugewiesen wurde, dasjenige mit der jeweils jüngsten Validitätszeit (21 , 23, 26) ausgewählt wird, die Kalkulationsanweisungen der vom identifizierten und ausgewählten Datenobjekt (11 , 13, 19, 22,
25) umfassten Sequenz von Kalkulationsanweisungen ausgeführt werden und die Daten mit Ausführen der Kalkulationsanweisungen verarbeitet werden oder, sofern allen identifizierten Datenobjekten eine relativ zur Bezugszeit jüngere Validitätszeit (21 , 23, 26) zugewiesen wurde, von einer Verarbeitung der Daten abgesehen wird.
53. Verfahren nach Anspruch 52, bei dem bei nachfolgenden sukzessiven Überschreibungen von Datenobjekten (11 , 13, 19, 22, 25), denen die gleiche Identifikation zugeordnet wurde, durch ein neues Datenobjekt (11, 13, 19, 22, 25), dem neuen Datenobjekt (11 , 13, 19, 22, 25) eine jeweilige Validitätszeit (21, 23, 26) zugewiesen wird, die jünger ist als die Validitätszeiten (21, 23,
26) aller Datenobjekte (11 , 13, 19, 22, 25) mit dieser Identifikation, und das neue Datenobjekt (11, 13, 19, 22, 25) mit der ihm zugewiesenen Validitätszeit (21 , 23, 26) unter Zuordnung derselben Identifikation und unter Beibehaltung der Speicherung aller Datenobjekte (11 , 13, 19, 22, 25) dieser Identifikation gespeichert wird.
54. Verfahren nach einem der Ansprüche 52 oder 53, bei dem bei Ausblei- ben einer Vorgabe für die Bezugszeit automatisch eine Bezugszeit vorgegeben wird, die einer Zeit entspricht, zu der die Identifikation des Datenobjekts (11 , 13, 19, 22, 25) erfolgt.
55. Verfahren nach einem der Ansprüche 52 bis 54, bei dem wenigstens einem Datenobjekt (11 , 13, 19, 22, 25) oder jedem Datenobjekt (11 , 13, 19, 22, 25) ein jeweiliger Zeitpunkt des Speicherns des betreffenden Datenobjekts (11, 13, 19, 22, 25) als Validitätszeit (21, 23, 26) zugeordnet wird.
56. Verfahren nach einem der Ansprüche 52 bis 55, bei dem ferner wenigstens ein vorgegebenes Datenobjekt (22) mit einer zugewiesenen Validitätszeit (23) durch ein drittes Datenobjekt (28) ersetzt wird, indem das vorgegebene Datenobjekt (22) gelöscht, das dritte Datenobjekt (28) gespeichert und dem dritten Datenobjekt (28) die zuvor dem vorgegebenen Datenobjekt zugewiesene Validitätszeit (23) zugewiesen wird.
57. Verfahren nach Anspruch 56, bei dem der dem vorgegebenen Datenobjekt (22) zugewiesenen Validitätszeit (23) ein Protokoll (29) zugeordnet, die Ersetzung des vorgegebenen Datenobjekts (22) durch das dritte Datenobjekt (28) im Protokoll (29) vermerkt und dabei das vorgegebene Datenobjekt (22) in das Protokoll (29) kopiert wird.
58. Computerprogrammprodukt mit Steueranweisungen zum Steuern einer Datenverarbeitungseinrichtung (2) nach einem der Ansprüche 1 bis 19 und/oder zum Steuern einer Vorrichtung (1) nach einem der Ansprüche 20 bis 46.
59. Speichermedium, auf dem das Computerprogrammprodukt nach Ans- pruch 58 gespeichert ist.
EP09737746A 2008-04-30 2009-04-28 Datenverarbeitungseinrichtung und verfahren zum verarbeiten von daten Withdrawn EP2271985A2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE200810021642 DE102008021642A1 (de) 2008-04-30 2008-04-30 Datenverarbeitungseinrichtung und Verfahren zum Verarbeiten von Daten
PCT/DE2009/000609 WO2009132638A2 (de) 2008-04-30 2009-04-28 Datenverarbeitungseinrichtung und verfahren zum verarbeiten von daten

Publications (1)

Publication Number Publication Date
EP2271985A2 true EP2271985A2 (de) 2011-01-12

Family

ID=41128059

Family Applications (1)

Application Number Title Priority Date Filing Date
EP09737746A Withdrawn EP2271985A2 (de) 2008-04-30 2009-04-28 Datenverarbeitungseinrichtung und verfahren zum verarbeiten von daten

Country Status (3)

Country Link
EP (1) EP2271985A2 (de)
DE (1) DE102008021642A1 (de)
WO (1) WO2009132638A2 (de)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7246361B1 (en) * 2003-03-20 2007-07-17 Intuit, Inc. Supporting multiple late binding objects with the same identifier

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7246361B1 (en) * 2003-03-20 2007-07-17 Intuit, Inc. Supporting multiple late binding objects with the same identifier

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
IRA R FORMAN ET AL: "Release-to-release binary compatibility in SOM", ACM SIGPLAN NOTICES, ACM, 2 PENN PLAZA, SUITE 701 NEW YORK NY 10121-0701 USA, vol. 30, no. 10, 17 October 1995 (1995-10-17), pages 426 - 438, XP058387913, ISSN: 0362-1340, DOI: 10.1145/217839.217880 *
JACKY ESTUBLIER, RUBBY CASALLAS: "The Adele Configuration Manager", 1994, Retrieved from the Internet <URL:https://grosskurth.ca/bib/1995/estublier-adele.pdf> [retrieved on 20180503] *
KAMITA ET AL: "A database architecture and version control for group work", SYSTEM SCIENCES, 1994. VOL. I: ARCHITECTURE, PROCEEDINGS OF THE TWENTY-SEVENTH HAWAII INTERNATION CONFERENCE ON, IEEE COMPUT. SOC. PRESS, LOS ALAMITOS, CA, USA, 4 January 1994 (1994-01-04), pages 438 - 447, XP031940192, ISBN: 978-0-8186-5090-1, DOI: 10.1109/HICSS.1994.323328 *
NEWELL D ET AL: "Interoperable object models for large scale distributed systems", 19951030; 19951030 - 19951031, vol. 1, 30 October 1995 (1995-10-30), pages 14/1 - 14/6, XP006503559 *

Also Published As

Publication number Publication date
WO2009132638A9 (de) 2009-12-23
WO2009132638A2 (de) 2009-11-05
DE102008021642A1 (de) 2009-11-05

Similar Documents

Publication Publication Date Title
DE69736748T2 (de) Editierumgebung für objektmodelle und verfahren zu deren anwendung
EP1258812B1 (de) Virtuelle Datenbank heterogener Datenstrukturen
DE68925746T2 (de) Versionen-Verwaltungswerkzeug
DE69214828T2 (de) Kodeserver.
DE10210280B4 (de) Steuerungen, Tools und diese umfassende Systeme
DE112004001775T5 (de) Verfahren und Vorrichtung zur Bereitstellung von automatischen Software-Updates
DE102005008520B4 (de) Verfahren, Computerprogramm-Produkt und Drucksystem zum Sortieren von Druckjobs in eienm solchen Drucksystem
EP1638028A2 (de) Rechnergestützte Erzeugung und Änderungsmanagement für Bedienoberflächen
DE102018111930A1 (de) Verfahren zum Bearbeiten eines Softwareprojekts
EP3809260A1 (de) System und verfahren zur administration von bildgebenden geräten
DE19910535A1 (de) Verfahren zur automatischen Wiedergewinnung von Engineeringdaten aus Anlagen
EP2271985A2 (de) Datenverarbeitungseinrichtung und verfahren zum verarbeiten von daten
DE4308291C2 (de) Verfahren und Vorrichtung zur vorgangsbezogenen Erstellung und Bearbeitung von Dokumenten
EP2479664A1 (de) System und Verfahren zum Erzeugen eines Quellcodes für ein Computerprogramm
EP1285315B1 (de) Informationsverarbeitungssystem und verfahren zu dessen betrieb
DE10233971A1 (de) Verfahren und Vorrichtung zur Erzeugung von Software
EP2272012A1 (de) Datenverlustfreies überschreiben gespeicherter datenelemente
EP1675045A1 (de) Austausch von Beschreibungsdaten zwischen Projekten mit Hilfe von Inter-Project-Interfaces
DE102020132332A1 (de) Verfahren zur Steuerung eines cloudbasierten landwirtschaftlichen Datenbanksystems
DE10339112B4 (de) Verfahren zum Erzeugen mindestens eines Projekt-Referenzmodells, Verfahren zur Generierung einer strukturierten Konfigurationsinformation mittels eines solchen Projekt-Referenzmodells sowie Vorrichtung zur Durchführung, Verwaltung und Organisation solcher Verfahren
DE112019007250T5 (de) Bildschirmdarstellungsdatenerzeugungssystem, Bildschirmdarstellungsdatenerzeugungsverfahren und Programm
WO2010026151A1 (de) Verfahren zur einräumung einer zugriffsberechtigung auf ein rechnerbasiertes objekt in einem automatisierungssystem, computerprogramm und automatisierungssystem
DE102005008519B4 (de) Verfahren zum Überwachen eines Verzeichnisses in einem Drucksystem, Computerprogramm-Produkt und Drucksystem zum Ausführen dieses Verfahrens
DE102019118757A1 (de) Verfahren zur Herstellung der Cachekohärenz in Mehrkernprozessoren
EP1044409B1 (de) Programmablaufverfahren und verfahren zur erweiterung eines programmkomponentensystems

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20101029

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA RS

DAX Request for extension of the european patent (deleted)
R17D Deferred search report published (corrected)

Effective date: 20091223

17Q First examination report despatched

Effective date: 20180514

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20180925