WO2007098817A1

WO2007098817A1 - Method for securing the data consistency of interdependent data

Info

Publication number: WO2007098817A1
Application number: PCT/EP2006/069902
Authority: WO
Inventors: Birthe Böhm; Norbert Gewald; Gerold Herold
Original assignee: Siemens Aktiengesellschaft
Priority date: 2006-02-24
Filing date: 2006-12-19
Publication date: 2007-09-07
Also published as: DE102006008740A1

Abstract

The invention is substantially characterized in that, contrary to the conventional method for securing data consistency, dependencies and optional derivation regulations are stored in the data in a decentralized manner such that no prioritary detection and managemanet system is required thereby permitting the processing of data stocks which are not known to all participating systems. The latter means that the derived data can be added at will from any individual systems without the need that the other participating systems or a global system have to interpret said data. This is made possible due to the fact that the data are quasi themselves responsible for their actualisation. The integration of a transaction time stamp also enables a precise control of the data to be calculated and prevents redundant evaluations. It is obvious at any time with the aid of the above-mentioned methods, whether data values are valid or invalid. Due to the optional description of the derivation regulations, the data values can be recalculated.

Description

description

Method for securing the data consistency of interdependent data

The invention relates to a method for securing the data consistency of interdependent data, in which an explicit modeling of dependencies between data takes place in order to detect inconsistencies in dependent data after changes to their basic data or to restore the consistency immediately.

The problem of dependent data is currently solved by requiring that the entire system knows all the data and its dependencies and has direct access to all

Has data. If the base data changes then all dependent data will be updated by this global system. The dependency descriptions and change specifications are therefore managed globally. In database systems, for example, so-called

Defined triggers that make this update in case of changing base data. For each type or instance of a base date, the required updating functionality is defined centrally. However, this requires the knowledge of all data and their dependencies.

If a date changes, all data derived from it must also be changed to preserve data consistency within that data set.

An additional problem arises when multiple systems access a common database, but this can expand system-specific. In this case, proprietary data, ie data that only one system can interpret, is mixed with data known to all systems. It is also possible that dependencies between the proprietary and the common Data exists which can also lead to inconsistencies when changes are made to the basic data.

The object underlying the invention is now to provide a method for securing the data consistency of interdependent data, in which the above-mentioned disadvantages are avoided.

This object is achieved by the features of claim 1 according to the invention.

The further claims relate to advantageous embodiments of the method according to the invention.

Essentially, the invention is that, in contrast to the conventional method for ensuring data consistency, dependencies and optional derivation rules are deposited in the data in a decentralized manner, which does not require a higher-level acquisition and management system and makes it possible to process data stocks that are not shared by all Systems are known. The latter means that the derived data can be arbitrarily added to the database by individual systems without the other systems involved or an entire system having to interpret this data. This is possible because the data is almost responsible for updating itself. The inclusion of a transaction timestamp also allows precise control over the data to be calculated and avoids redundant evaluations. With the help of the methods described above, it can be seen at any time whether data values are valid or invalid. The optional description of the derivation rules allows the data values to be recalculated.

The invention will be explained in more detail below on the basis of preferred exemplary embodiments. It shows Figure 1 is a representation for explaining a first

Embodiment in which dependencies are stored based on the basic data,

FIG. 2 is an illustration for explaining a second exemplary embodiment in which dependencies are stored based on the derived data and

Figure 3 is a representation for explaining a third

Embodiment in which dependencies are stored both on the basis of basic data and on the basis of the derived data.

The prerequisite for detecting inconsistencies in dependent data after changes to their basic data or immediately restoring consistency is an explicit one

Modeling dependencies between data. In contrast to the previous solution, no superordinate overall system is necessary to manage these dependencies, but these dependencies are stored directly in the affected data. The validity of values is determined either at the time of changing base data via a note in the dependent data structures or by comparing transaction time stamps in the individual data. Unlike a normal timestamp, a transaction timestamp is each assigned for a set of consistent data changes, i. All data with an identical transaction timestamp is guaranteed to be consistent with each other and underlying data, that is, data on which the considered data is dependent, with an older transaction timestamp. If there is a dependency between two dates and the date of the underlying data is younger than the derived date, then the consistency of the derived date must be checked.

In addition, if not only the consistency of data is to be checked, the optional Derivation rule that describes how the derived data is calculated from the base data. This allows an automatic calculation of the derived data.

The invention is based on a data structure which, in addition to the actual data, has the following components: 1. a validity mark and / or a

Transaction time stamp 2. Dependency descriptions

3. optional derivation rules

If calculation rules are formulated based only on the base data for the derived data, only basic data can be changed. This must go through

Labeling or access mechanisms are ensured. The direct modification of derived data is allowed when the calculation rules are bidirectionally filed, i. It is also known how a base date results from the derived date. This then results in additional conditions for the procedures, which will not be considered separately below.

Depending on the requirements in the system, one of the following three methods can be used. Here, an example is used, which calculates the body mass index (BMI) from a weight specification and a size specification, from which then a classification into a weight classification takes place. The BMI is calculated from the weight in kilograms divided by the size in meters squared. The

Weight classification refers to the BMI and uses a table to determine the classification in underweight, normal weight, overweight, etc.

For the exemplary embodiments illustrated below, examples of implementation in XML are given for better understanding. These examples are deliberately kept very simple or there are far more complex applications, for example with regard to the type of referencing, the storage of the time stamp or the presentation of the calculation rules.

Embodiment 1

The dependencies are stored here starting from the basic data.

In this case, any changes to the dependency baseline data will identify all derived data-recursively identifying data dependent on derived base date data. To determine the inconsistency, any change to a base date informs all dependent data that it is based on invalid values. This can e.g. This is done by setting a simple Boolean "switch" that is part of the data, so that when derived data is accessed, its validity can be determined to ensure that each value in the system is known to be valid.

This method can be used if only the validity of values has to be determined. An update of the derived data can then be system-dependent.

In Figure 1, this method is shown step by step. Step 1 represents the initial situation in which the dependencies are formulated from the basic data Bl and B2 to the derived data A. When a base value W2 changes, the dependent values WA must be marked as invalid, for example, with the aid of a validation switch G, as can be seen in steps 2a and 2b.

Simple implementation example in XML There are two applications that work on a common record. The applications should be able to determine if the data is up-to-date during shared access. The first application creates the following data record:

<? xml version = "1.0" encoding = "UTF-8"?> <Dataset xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi: noNamespaceSchemaLocation = "Dependency.xsd"> <Baseattributes Name = "Size" Valid = "true"> <Value> 190 </ Value>

</ Basic attributes>

</ Attributes>

<Attribute Name = "Weight Classification" Valid = "true"> <Value> Normal Weight <Λ / alue>

<Formula> look up in table: <20 = underweight; 20-25 = normal weight; 26-30 = overweight; ... </ Formula>

</ Attributes> </ dataset>

The second application now changes the base attribute Weight and applies the procedure described in 1. This will change the data as follows:

<? xml version = "1.0" encoding = "UTF-8"?><Dataset xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi: noNamespaceSchemaLocation = "Dependency.xsd"><Baseattributes Name = "Size" Valid = "true"><Value> 190 </ Value> <BaseToDependencyRef Target = "BMI"/></Baseattributes><Baseattributes Name = "Weight" Valid = "true">

</ Baseattributes>

</ Attributes>

<Attribute Name = "Weight Classification" Valid = "false"> <Value> Normal Weight <Λ / alue>

</ Attributes> </ dataset>

The first application checks according to the procedure before each read whether the data is still valid. When trying to read the weight classification attribute, the first application determines that this value is no longer valid and must trigger a recalculation.

Embodiment 2

The dependencies R and possibly a derivation rule V are stored in the derived data. In addition, each datum must also include a timestamp or a transaction timestamp T, as shown in step 1 of FIG. If changes are now made to the basic data B1 or B2, this change, as can be seen from step 2, is not propagated to derived data. In this method, the base data need no knowledge of dependent data. In addition, the transaction ^¬ timestamp T to the base date is updated. The values of the derived data are not consistent at this time to their basic data, since their change has not yet been adopted. The amount of data is temporarily in an inconsistent state. Assuming that consistent data is always expected when reading the data, an adjustment must be made at the latest when accessing the derived data. In this case, based on dependency descriptions a or b of the derived date, all base data is determined, which may extend recursively over several levels. If only the validity of the current value is to be checked, an analysis of the transaction time stamps T of the basic data is sufficient. If their transaction timestamps are older or the same age as the transaction timestamps of the derived date A, their value is valid and can be used directly if necessary.

If not only the validity is to be checked, then the derivative value V must be used to determine the current value of the derived date. In addition, the current transaction timestamp must be set. This transaction timestamp may also correspond to the transaction timestamp of the most recent change to the base data. Thus, the current value of the date is known and documented to which level of the basic data the calculated value is consistent. This can be seen in FIG. 2 in step 3.

This method can be usefully applied to large amounts of data with rather few accesses to the derived data. The depth of dependencies between the data or their interconnectedness should be rather low in order to ensure an efficient update.

Simple implementation example in XML

There are again two applications that work on a common database. Application 1 generates the following data record: <? xml version = "1.0" encoding = "UTF-8"?><Dataset xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi: noNamespaceSchemaLocation = "Dependency.xsd">

</ Baseattributes>

<Attribute Name = "Weight Classification" Timestamp = "T1"> <Value> Normal Weight <Λ / alue> <DependencyToBaseRef Name = "String" Target = "BMI7>

</ Attributes> </ dataset>

Application 2 now changes the base attribute Weight and sets the transaction time stamp accordingly:

<? xml version = "1.0" encoding = "UTF-8"?> <Dataset xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi: noNamespaceSchemaLocation = "Dependency.xsd"> <Base attributes name = "size" timestamp = "T1">

Attributes Name = "BMI" Timestamp = "T1"><Value> 22 <Λ / alue> <DependencyToBaseRef Name = "a" Target = "Size"/><DependencyToBaseRef Name = "b" Target = "Weight"/><Formula> b / a ^Λ 2 </ Formula></Attribute><Attribute Name = "Weight Classification "Timestamp =" T1 "><Value> Normal weight <Λ / alue><DependencyToBaseRef Name =" String "Target =" BMI "/>

<Formula> look up in table: <20 = underweight; 20-25 = normal weight; 26-30 = overweight; ... </ Formula> </ attributes> </ dataset>

Application 1 now wants to read the value of the weight classification attribute and now has to check the validity. It tracks the dependencies via the attribute BMI up to the basic attributes size and weight. For the base attribute Weight Application 1 determines that the time stamp is newer than the weight attribute to be read and must now trigger a recalculation. First, the attribute BMI is recalculated from bottom to top according to the rule stored there, and then according to its rule the attribute weight classification. Application 1 then saves the newly calculated data as follows:

<? xml version = "1.0" encoding = "UTF-8"?> <Dataset xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi: noNamespaceSchemaLocation = "Dependency.xsd">

</ Baseattributes>

<Value> 100 </ Value></Baseattributes> Attributes Name = "BMI" Timestamp = "T3"><Value> 28 <Λ / alue><DependencyToBaseRef Name = "a" Target = "Size"/> <DependencyToBaseRef Name = "b" Target = "Weight"/>

<Attribute Name = "Weight Classification" Timestamp = "T3"> 5 <Value> Overweight </ Value>

<Formula> look up in table: <20 = underweight; 20-25 = normal weight; 26-30 = overweight; ... </ Formula> </ attributes> l o </ dataset>

Embodiment 3

This procedure is a combination of the previous two procedures. The dependencies are stored here starting from the basic data and the derived data. In addition, the derivation rules are also stored in the derived data.

In FIG. 3, in step 1, the double is

Dependency modeling. When the basic data is changed, the changes are propagated to the derived data as in the first method, where they are only noted that the current value belongs to the

25 base values is not consistent, which can be seen in Figure 3 in step 2. When accessing the derived data, their validity is then checked on the basis of this memorandum and then proceeded according to the second method. If the value is valid it can be used immediately

Otherwise, the basic data will be about the

Dependency descriptions determined and calculated from this basic data, the current value. The validity notes are then reset. The result of this process is shown in FIG. 3 in step 3

35 can be seen as an example. This method is useful for large amounts of data with numerous accesses to the derived data. The depth of dependencies is not relevant here.

A variant of this embodiment is that the data are not marked as invalid, but are recalculated immediately, so that the data is always up-to-date and consistent.

Simple implementation example in XML

As with the previous examples, two applications work on a common database, and application 1 generates the following data record:

</ Baseattributes>

Attributes Name = "BMI" Valid = "true" Timestamp = "T1">

<Attribute Name = "Weight Classification" Valid = "true" Timestamp = "T1"> <Value> Normal Weight <Λ / alue>

<DependencyToBaseRef Name = "String" Target = "BMI7> <Formula> look up in table: <20 = underweight; 20-25 = normal weight; 26-30 = overweight; ... </ Formula></attributes></dataset>

5

Application 2 changes the value of the Weight attribute and additionally identifies the tree that has become invalid:

<? xml version = "1.0" encoding = "UTF-8"?> 0 <dataset xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi: noNamespaceSchemaLocation = "Dependency.xsd" >

<Value> 100 </ Value> <BaseToDependencyRef Target = "BMI7> </ Baseattributes> o Attributes Name =" BMI "Valid =" false "Timestamp =" T1 "> <Value> 22 <Λ / alue>

</ Attributes>

<Attribute Name = "Weight Classification" Valid = "false" Timestamp = "T1"> <Value> Normal Weight <Λ / alue> <DependencyToBaseRef Name = "String" Target = "BMI7> 0 <Formula> look up in table: < 20 = underweight, 20-25 = normal weight, 26-30 = overweight;

... </ Formula> </ attributes> </ dataset>

5 Application 1 now wants to read the value of the attribute BMI and first checks the validity of the value by means of the Valid property of the attribute. Because the attribute BMI is invalid, it must be recalculated starting from the base values using the calculation rule stored in the Formula property. Application 1 writes back the new date and updates record 5 as follows:

<? xml version = "1.0" encoding = "UTF-8"?> <Dataset xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi: noNamespaceSchemaLocation = "Dependency.xsd"> 0 <base attributes name = "size" Valid = "true" timestamp = "T1"> <Value> 190 </ Value> <BaseToDependencyRef Target = "BMI" /> </ baseattributes>

<DependencyToBaseRef Name = "a" Target = "Size"/><DependencyToBaseRef Name = "b" Target = "Weight"/><Formula> b / a ^Λ 2 </ Formula></Attribute> 5 <Attribute Name = " Weight classification "Valid =" false "Timestamp =" T1 "><Value> Normal weight <Λ / alue><DependencyToBaseRef Name =" String "Target ="BMI7>

<Formula> look up in table: <20 = underweight; 20-25 = normal weight; 26-30 = overweight; ... </ Formula> 0 </ attributes> </ dataset>

Claims

claims

1. A method for securing the data consistency of interdependent data, in which a modeling of the dependencies between data takes place in that a data structure is generated, in addition to the respective actual data (WA, W2), a validity mark (G) and / or a Transaction time stamp (T) and at least one dependency description (R) contains.

2. The method of claim 1, wherein the validity of values either at the time of changing basic data about an endorsement in the dependent data structures or via a comparison of

Transaction timestamps are determined in the individual data, wherein a transaction timestamp is awarded for a set of consistent data changes, in which the consistency of the data is checked, if a dependency exists between at least two dates and a base date is younger than a derived date.

3. The method of claim 1, wherein in the data structure additionally at least one derivation rule is included.

4. The method of claim 3, wherein at least one derivation rule (V) describes how the derived data (A) from the basic data (Bl, B2) are calculated and in which an automatic calculation of the derived data using the derivation rule.

5. The method according to any one of the preceding claims, is ensured by labeling or access mechanisms that only basic data can be changed, provided that only calculation rules from the basic data to the derived data and direct modification of derived data is only allowed if the calculation rules specify how a base date results from the derived date.