WO2009141162A1

WO2009141162A1 - Method for storing a plurality of revisions of data families linked tree structure-like

Info

Publication number: WO2009141162A1
Application number: PCT/EP2009/003680
Authority: WO
Inventors: Marc Yves Maria Kramis
Original assignee: Universität Konstanz
Priority date: 2008-05-23
Filing date: 2009-05-25
Publication date: 2009-11-26
Also published as: WO2009141161A1; DE102008024809B3

Abstract

The invention relates to a method for storing a plurality of revisions (R_r) of data family parts which are linked tree structure-like and each have a number of tree-like linked data pages (P_r,p) with a central parent data page (PP_r,0) and originating therefrom child data pages (PP_r,x). For each revision (R_r), a main reference pointer (RR_r) is provided on the parent data page (PP_r,0) of the respective data page (P_r) in a separately stored list (NDL_r,p). The data pages (P_r) have at least one page reference pointer (PP_r,x) on logically linked child data pages (PP_r,x). Node change information about a reference to changes of nodes of the structure of tree-like linked data family parts defining logically directly subsequently linked child data pages (PP_r,x) are stored for each revision (R_r).

Description

Method for storing a plurality of revisions of tree-structured data families

The invention relates to a method for storing a plurality of revisions of tree-structured data families, each of which has a number of tree-like linked data pages with a central parent data page and child data pages emanating therefrom, wherein for each revision a main reference pointer to the Parent data page of the respective data page is provided in a separately stored list and the data page have at least one page reference pointer to logically immediately following linked child data pages.

Information can be stored digitally in a hierarchical structure using the so-called Extensible Mark-Up-Language XML. XML is a recording language for displaying hierarchically structured data in the form of text files. The XML format is used in particular for the exchange of data between different computer systems. An XML document consists of elements, attributes, their value assignments, and the content of the elements, which can be text or children. The subordinate

Elements can in turn have attributes with value assignments and content. An XML document can contain elements with and without attributes. Furthermore, there may be elements which in turn contain many other elements. Furthermore, elements can only have text or even no content. The elements, attributes, and value assignments form a tree structure that resembles a directory and file structure of conventional computer systems. An XML file is processed by a so-called XML Paser, following the hierarchy that results from the tree structure of the data. Each element, each attribute, each value assignment to an attribute and each character content of an element is a separate part of the tree, which is individually addressable. These components are also called nodes. Each XML document begins with a root node that forms the origin of the data. The root node points to an outmost element, that is, the topmost node, that encompasses the entire rest of the XML file. One or more child nodes are connected to such a node, from the perspective of which the parent node forms a parent node.

With such an XML document, in which parent and child data pages are linked to one another hierarchically, system-independent data can be managed and, in particular, revisions of data collections stored in such a way that the revision history can be traced. This is particularly useful when a plurality of agents work on the same object, such as the creation of text documents.

There are a variety of native XML databases that represent encoding for the internal representation of XML data as an unordered, ordered tree, with the constraint that the order of the children of each node is stable. The encoded tree is stored in a memory system. The native XML databases make the stored tree accessible via an interface.

There are four main classes for encoding. Encoding with a fixed-size key assigns each node a unique, nonvolatile, fixed-size key. A comparison of two keys does not reflect necessary se the global order of the two related nodes. Each node stores keys of its immediate neighbor nodes. Updates are not scaled if a node contains a large number of children. Encoding with a variable-size key assigns each node a unique, nonvolatile variable-sized key. A comparison of two keys always reflects the global order of the two related nodes. Depending on an insertion position, the size of the key may increase indefinitely. Updates are not scaled for persistent inserts in the adjacent neighborhood of a single node.

The position coding assigns each node a unique, volatile key of fixed size. A comparison of two keys always reflects the global order of the two related nodes. The key of a node corresponds to the current position of the node, while updates change the position of all nodes following the inserted or deleted node. Updates are not scaled if additional indexes, such as a full-text index, are involved. The fourth type of coding is an index-based method in which one or more indexes exist for each node to speed up typical queries. To do this, the original XML document must be kept available for correct reconstruction. Updates are not scaled, so the original XML document and all nodes must be updated after inserting or deleting nodes. Furthermore, there are two basic classes of storage systems. The first class of storage system overwrites existing data when executing current updates. For this purpose, a tree copy or a field is usually partially or completely held in memory and written back to the storage medium during the update. Old data is partially or completely overwritten or deleted.

The second storage class makes updates to copies while writing without overwriting old data. Here, an index and the revision of the data is kept. A new index and new data are just appended to the old information. The index points on data correspond to a revision and can be used either on a full data content or on a sequence of incremental changes, that is, the difference between the data contents of two consecutive revisions that can be used to reconstruct the full data content.

There are also four basic interface classes, namely an application programming interface (API), integrated interaction (embedded interaction) of a user-interface API for stand-alone interaction, a user-interface API for web-based interaction and a Text and / or graphical user interface for human-machine interaction.

C. Green, A. Holupirek, M. Kramis, MH Scholl, M. Waldvogel: "Pushing XPath Accelerator to Its Limits", in Proceedings of the First International Workshop and Performance and Evaluation of Data Management Systems, June 30, 2006 Chicago, Illinois, USA, describes the structure of XML data and concepts for encoding, through a set of index tuples and index block structures, the update time can be reduced.The file structure is managed with a name list, a node list, and a list of values.

A problem is the efficient storage and search of tree-linked data family revisions, particularly in view of the size and structure of the linked families of data being unpredictably different from revision to revision.

The object is achieved with the method of the aforementioned type according to the invention by storing node change information for each revision via changes of a reference to logically immediately following linked child data pages defining nodes of tree-like linked data family parts.

It is thus proposed to store for each data page of a revision information about the changes with respect to the previous revision in a separate node list as node change information. By storing the node change information for each revision, another searchable and evaluable list from which immediately the changes of the nodes of a data page are recognizable. There, the revision is already recognizable on the basis of the versioning of the tree structure, which is accessible via the stored node change information as an information field. This has the advantage that the change instruction does not first have to be evaluated cumbersomely via the main and page reference pointers starting from a root node. Non-persistent pages in memory can be derived from persistent pages.

The node change information may indicate adding new nodes, deleting nodes, and / or changing nodes. By separately storing node change information in an additional list containing the change of the nodes of a data page, it is thus noted whether an additional node has been added, deleted or changed in comparison to the previous revision.

The child data pages may contain the change of the corresponding child data page on an immediately preceding revision in the form of difference data. This has the advantage that it is not necessary to store the complete content of the data page, but only the non-binary change information, which leads to a reduced storage requirement and requires no complex calculations.

The data pages can also contain the complete data content, which was optionally modified in the respective revision.

In a preferred embodiment, the main reference pointers or copies of the main reference pointers are stored on a further data storage medium separately from the referenced data pages. This not only has the advantage of increased data security through redundancy, but also allows for faster data access, since the search in the main reference pointers on the separate data storage medium can be done in parallel with the reading or writing of data pages. However, it is also conceivable that the main reference pointers or copies thereof are stored in sectors of a data storage medium separate from the sectors of the same data storage medium in which the referenced data records are stored. The division into sectors ensures that the tree-like structures of the data can be consecutively stored, as well as the main reference pointers, without the storage locations being scrambled.

Furthermore, it is advantageous if the storage of the revision of data families is secured by encryption. However, encryption should not significantly limit performance. It is therefore proposed to set up a cryptographic method based on a coded hash message authentication code, in which a cryptographic hash function is used in combination with a secret key. In addition, a symmetric encryption is used. For this purpose, a secret master key is defined and an additional identifier is generated independently of the master key. This generation of the additional identifier, which is also called salt, is also referred to as salting. A key is derived from the master key and the additional identifier. This is also called stretching. For each data page then a unique ad hoc key and a counter from results of encryption / decryption algorithms superordinate data page for encryption, decryption and authentication of at least the associated main reference pointers, data pages and at least one header for the entirety of the revision stored families of data derived.

The encryption method may, for example, make use of the standardized Advanced Encryption standard, e.g. CTR-AES-256 and the hash authentication method, e.g. HMAC-SHA-256. The reading out of the stored revisions of data pages can preferably take place by the steps:

a) Verify the match of stored copies of a header for the

Totality of revision of stored data families; b) verifying the compliance of a data storage medium stored in a separate data storage medium or on a separate sector of a data storage medium. a copy of a main reference pointer for the current revision with a main reference pointer of the current revision stored on a sector of the data storage medium together with the associated data pages of the revision, c) accessing data pages of desired revisions via pointers contained in the main pointer for the corresponding revision and the page reference pointer and d) evaluating node change information for each revision via changes from a reference to child children pages logically linked immediately thereafter.

The access to a desired revision can be made by means of the binary search algorithm via the list of main reference pointers, it being equally possible to search for the revision number and / or the time stamp stored in the main reference pointer.

The invention will be explained in more detail with reference to embodiments with the accompanying drawings. Show it:

Figure 1 - Memory scheme for storing a plurality of

5 revisions of tree-structured data families with two separate data stores;

Figure 2 - Memory scheme storing a plurality of

Revisions of tree-structured data families O using two sectors of a single data store;

Figure 3 - exemplary representation of the logical and physical page and page subtree for four revisions;

5 Figure 4 - representation of the state diagram of a method for

Storing a plurality of revisions of tree-structured data families;

FIG. 5 shows a flow chart of the method for serializing a data page stored in O memory onto a read-only memory.

Figure 6 - exemplary representation of a way to store nodes.

FIG. 1 shows the memory division using two logical data memories LDi and LD ₂ . Each data memory LDd with d = 0,1, ... n consists of a field of sectors S _d , _s with the maximum number of max (s) of sectors. Each sector may be 512 bytes wide, for example. The data memories LD _d support random read and write access to each sector S _d , i, where

D the data storage should be optimized for random read and sequential write activities. The required storage space on the data storage LDd is constantly growing at any time by adding further sectors, wherein the number of write accesses to each sector S _d , ι may be limited. It can be seen that all data and metadata are stored on the primary logical data memory LDi. In the exemplary embodiment illustrated in FIG. 1, the metadata is also stored on the second logical data memory LD ₂ 5 in order to speed up the storage and read-out of revisions and the search for revisions. Due to the redundant storage in the second data memory LD ₂ , the data content of the second data memory LD ₂ can be reconstructed at any time from the first data memory LDi and checked for consistency. Incremental backups of the data content on the first and / or second data memory LDi and / or LD ₂ can be stored synchronously or asynchronously on one or more other further data memories LDd for data backup. As metadata so-called header data H _h (header) are initially provided, for salting an additional identifier SLT _h (salt), for example, 32 bytes, a configuration CONFh, for example, 448 bytes and a token HT _h of 32 bytes 5 contain the authentication the configuration CONF _{h is} used. The token HT _h corresponds to the authentication algorithm HMAC-SHA-256k (CONF _h ). The algorithm is from the secure hash standard: Federal Information Processing Standards Publication 180-2, National Institute of Standards and Technology, August 2002, from the Advanced Encryption Standard (AES): Federal Information Processing Standards Publication 197, National Institute of Standards and Technology, November 2001, and The Keyed Hash-Message Authentication Code (HMAC): Federal Information Processing Standards Publication 198, National Institute of Standards and Technology, March 2002.

.5 The additional identifiers SLTh, ie the first 32 bytes of the header H _h are not encrypted. H _h is stored twice on the first data memory LDi as Ho and Hi and twice on the second data memory LD ₂ as H ₂ and H3.

As metadata, revision references RR _{r are also} stored, which contain an iθ page sub-reference PPR _r , o (eg 32 bytes) and the token RRT _r (eg 32 bytes), which is used to authenticate the page sub-reference PPR _r , o is used. The token

RRT _r corresponds to the authentication algorithm HMAC-SHA-256 "(PPR _r , o). Further The revision references (RR _r ) contain information about the author as well as the time of the creation of the revision R _r .

In order to find the previous revision reference RR _ma χ (r) -i on the second data memory LD ₂ starting from the most recent revision R _{maX (} r ₎ , a binary search is made on the sectors S2, 2, -S2, maχ (s). -i performed. Each time the median of sector S2, _{s is} selected, it is assumed that it contains some page subrefs PPRr.p at a byte offset of zero. If the token RRT _r equal to HMAC-SHA-256 _k (PPR _r, o) is the search in the direction to the right is continued, and otherwise in the leftward direction. If there are some revision references RRmax (r) -i to the revision R _ma χ (r) -i, the binary search will eventually select them.

If the second data memory LD _{2 is} not available, again a binary search is carried out with the first data memory LDi as described above. If the median does not return a revision reference RR _r , _p to a revision at a zero byte offset in a sector S _s , i, the search continues to the right and left as follows. The revision reference RR _{r, b} is started in the sectors S ₁ , m + icj-1,... Si, m + kj starting from ko = 1. If it is not found, an adaptation of kj = -2 • ^ k, _j to k reaches a configurable limit. Then proceed as described above.

From a logical point of view, a revision R _r stored in the first data memory LDi consists of a tree of data pages. The data pages are listed starting with the root data page P _r , o. Initially, the revision R _r includes all data pages from the previous revision R _r -i. Subsequent changes will only be made on copies of the data pages and not on the originals. The copies are visible only for the revision R _r and stored in the back order as data side parts PPr.x ..., PP _r , o. If the entire data page is stored, the copy of the page portion is referred to as a page snapshot PS _{r, p} . If only one change to the last revision is stored, this is referred to as a page change PD _r , _Pl ie as a non-binary difference or delta. From Figure 1 it can be seen that for each revision R _r a data page reference RR _{r is} provided which references the data page P _r , o equal to PP _r , o, which must be a page snapshot. All other data pages are referenced by a page reference PR_ (r, p) which references either a single page snapshot PS _{r, p} or a sequence of page changes PD _r , _p , the page changes to an initial data page snapshot PS _{r, p} be applied to derive a data page PP _r , p. The page count counter PPC _r , _P denotes the number of page changes to be applied to the initial page snapshots. Each page is bound to a revision r and a page number p, which uniquely distinguishes the page from all other pages. A page section thus receives the same page number for all revisions. Each page sub-reference in a page reference PR_ (r, p) is associated with the revision number during which this page sub-page was created. A page reference with the page counter PPC _r , _p equal to zero indicates a deleted page reference.

A non-persistent page P _r , _p contains two fields, the page reference field PRAr.p and the node field NDA _r , _p . Both fields are the result of all changes from all page parts, which are related to the page P _{r, p} . The size of the two fields is fixed or defined for each page according to their corresponding position in the page tree. The maximum size of the two fields is limited to 256, for example. Each entry in one of the fields is marked by its absolute position n. If n is negative, this means that the entry was changed in an earlier revision. The entry θ is not used. The first field, ie, the page reference field PRAr.p stores the nth page references PR _{rp \} ..., PR _Φ * pointing to the child data pages Pr, ..., Pr. P ^* . The second field, ie the node field NDAr, _p stores node ND _p , _n

A node ND _p , _n consists of an eg one-byte position in the node field NDA _ri p a node type of eg one byte and a payload of variable size. The node type less than 0 indicates a deleted node and contains no payload. Therefore, for example, 127 different node children are available. A page part PP _r , _P is either a page snapshot PS _{r, p} or a page change PD _{r, p} . A page snapshot PS _r , _p stores the result of all past changes as well as the changes during the revision R _r . The node change PD _r , _p contains only the changes made during the revision R _r .

The persistently-made page part PP _r , _p contains two variable-size lists which reflect the changes made to the data page P _r , _p during the revision R _r . Each list initially contains the list size of one byte. For example, the maximum size of both lists is limited to 256. The first list, the so-called page reference list PRL _r , _p stores changes to any page reference PRr, _P '..., PRr.p * pointing to the child pages P _r , _P ' ..., P _r , _P * where p <p ¹ <... <p ^* . The second list, the so-called node list NDL _riP stores changes to each node ND _riP , n. If the page part PP _r , _{p is} a side snapshot PS _r , _P , the node list NDL _r , _p also stores the current state of the node, if it was not modified during the revision R _r .

It can be seen from FIG. 1 that the references RR _r to the revisions followed by the headers H ₂ and H ₃ are stored in succession with the first reference RRo to the first revision R ₀ .

In the first data memory LDi, the revisions Ro, Ri,..., Rmax "are likewise stored one after the other using one or more sectors S _d , _s . The data to be a reference RR _r in the unused sectors, however, backward stored, whereby first the reference RR _r R _r to the respective revision is stored at the end of the last sector. The side parts PP _{r, p of} the revision R _r are stored starting from the beginning of the first sector S _d , _{s of} the revision R _r with the last child data page, ie the data page part PP _r , _x up to the root data part PP _r , o such that the sequence of data parts PP _r , _p ends with the root data part PP _r , o.

FIG. 2 shows another embodiment for storing a plurality of revisions R _r of tree-structured data families using a single logical storage medium LD ₀ . The copies of the revision references RR _r referring to the page parts to the revisions R _r as well as the Copies hb and H3 of the headers Ho and Hi are stored in sectors So, _ma χ (s) -i separated from the sectors S ₀ - for the revisions R ₁ -.

During the data memory area for the header Ho, Hi and the revisions R _r are se- 5 quentiell stored sequentially starting from a first sector So.o in forward order, the redundant storage of the metadata is carried in the reverse direction starting with the headers H ₂ and H ₃ at the end of the sectors for the second memory area, ie at the end of sector So, max (s) -i as sketched in FIG. 0

Figure 3 shows the structure of logically and physically storing side and side-part trees for four consecutive revisions Ro, Ri, R2 and R3. 5 The first revision Ro is based on the source data page Po, o, which is referenced with the revision reference RR ₀ . The originating data page Po.o in turn points to the data page P _Oi1 .

As changes to the revised data page P _ol i, the changes OA and 1 B0 were made. These are marked in the side part PP _OlP , so that from this side part PPo, _P the changes in the revision is immediately apparent.

The physical page-sub tree consists of the revision reference RRo which is based on the copy of the page Po.o, i. refers to the page snapshot PSo.o, which in turn refers5 to the page snapshot PSo.i with the changes.

In the following revision Ri, another data page has been added so that the data page Pi, o now branches into the data pages Pi, i and Pi, 2. Starting from the revision reference RRi, which points to the root data page ιθ Pi _{ι0 of} the revision Ri, the logical page tree is now structured in a tree-like _manner such that the data page Pi, o contains two child data pages Pi _, i and Pi, ₂ . As changes, in the child data page Pi _, i, the change "2C" and "0" and in the second child data page P _{1 | 2} "OD" and JE "were made. These changes are noted accordingly in the side part PP _{1 iP} , wherein the revision also contains the changes of the previous side part PPo, _{P of} the first revision R ₀ 5.

From the representation of the physical page partial tree in Figure 3 it can be seen that the revised data page children PD ₁ is ₁ related to the children's data page PSo, i. However, this child data page of the revision Ri does not contain complete data contents but only the changed data, so that the complete content of the child data page is derived from the child data page PS ₀ , i of the previous revision R ₀ and the change information can.

In the following revision R ₂ , the data tree has remained unchanged. Therefore 5 data pages were not deleted or added. As changes, J B "and" OD "were made in the child data pages P2, i and P ₂ , ₂ . These changes are recorded together with the change history in the page parts PP ₀ , PPi, _P and PP2, p.

It can be seen from the physical page sub-tree that the first child data page again only contains the changes to the preceding child data page PDi, i as change information PD ₂ , i. Also, the second modified child data page PD _2i2 contains only the change _information in the form of the deltas to the previous data page PSi, 2 of the previous reference R ₁ .

> 5

In the next revision R ₃ , the first child data page P _3§1 to the previous revision P ₂ , i was not changed. However, a snapshot PS ^ _{1 was} derived from the change information PDu and PD _2ι i on the basis of the last available snapshot PS0.1, which now contains the complete data content of the child

SO data page contains P _3i1 . In the second children's data page P _3ι2 a change was made "OD" compared to the previous revision These children Data Page ₃ P _{|. 2} was physically stored only as change data page PD _3I2.

Furthermore, a third child data page P _{3 | 3 was added} with the changes "OF" and "1 G".

FIG. 4 shows a state diagram in the implementation of the method for storing a plurality of revisions of tree-structured data file parts.

For example, in the so-called "wipe" state, all sectors are overwritten once with random data that is not encoded.

In the initialization state "init", the data stores LDi, LD ₂ and a master key MK are selected by the user Furthermore, an additional identifier SLT _h is selected using the salting process and a key K from the master key MK and the additional identifier derived SLT _h. a token HTh is set to by the HMAC-SHA-256 _k (CONF _h) algorithm predetermined value. the n-th copy of the header H _h is set to a linked by the condition SLTh with CTR AES 256 _k (CONF _h ) linked with HT _h set value.

The headers Ho, Hi, H ₂ and H ₃ are then synchronously written and verified.

In the case of a verification error, a restart of the initialization state is initiated.

The so-called start state "Start" occurs after the initialization, whereby the data memory LDi, the data memory LD ₂ and the master key MK are provided by the user, then the headers Ho, Hi, H ₂ and H _{3 are} read out and the additional identifier SLT _h is verified by comparison with the additional identifiers stored in the headers Ho, Hi, H ₂ and H _3. A node key is derived from the master key MK and the additional identifier SLT _h and the headers Ho, Hi, ter key MK and the additional identifier SLT _h derived and the headers H ₀ , H ₁ , H ₂ and H ₃ for checking the token HT _h with the algorithm HMAC-SHA- 256 _k (CONF _h ) verified.

Furthermore, the revision reference RR _ma χ (r) -i is searched for the second data memory LD2 and verified by comparison with the stored on the first data memory LD ₁ revision reference RR _ma χ (r) -i. An error in the verification causes a transition to the recover state "recover".

In the recover state "recover", header H is restored, this can be done from the available copies of the header, and the content is restored to the first and / or second data stores LD ₁ and LD ₂ using the available redundant data Restoration of the information takes place a jump in the stop state "stop".

The execution state "run" is executed each time a revision is passed, whereby the following points are processed.

In the first point the last revision Rmax "is written synchronously on the first data memory rather LD ₁ . In the following step, the revision _reference RR _maX (r _{) is} _verified to the last revision R _ma χ (r) on the first data memory LD ₁ . Then the revision reference RRmax "is synchronously written to the second data memory LD ₂ and verified there. Then, in the fifth step, the number of the available revision R _m ax (r), ie the consecutive number of the current revision, is incremented to max (r) +1.

An error in the check results in a second serialization beginning with step 1 of the execution state "run".

Again, at the end of a jump in the stop state, in which new changes are no longer allowed. So far unsaved changes are stored as described in the execution state. If, in the execution state, the fifth point of incrementing the number for the current revision has not been reached within an adjustable time, a stop occurs immediately.

Figure 5 omits the method of serialization of a data page stored in memory to a device such as e.g. recognize a hard disk as a flowchart.

A data page stored in memory is serialized. The serialized data page parts are compressed and the compressed data page parts are authenticated, encrypted, and then written to the device, such as a hard disk or other disk.

The readout of data page parts from the device takes place by first reading the data contents and decrypting and authenticating the encrypted data page parts. The compressed data page parts are then decompressed and are now available as unencrypted serialized data page parts. After deserialization, the data page can then be stored in a memory, in particular a volatile data memory RAM.

FIG. 6 shows a sketch for an exemplary way of storing nodes.

The first column shows the state of the data pages P ₃ , o at the time of the revision R3. The page P ₃ , o corresponds to the page _copy PS _3i0 . The node at position 1 was set before revision R ₃ . The node is of type 22 and has the value <example>. The node at the 2-position is set before the revision R. ₃ The node is of type 33 and has the value "text." The node at position 6 was deleted during revision R _3. The deleted node was of type 33.

In the second column, the state of the data page P _4ι o at the time of revision R4 is shown. The changes are stored in the difference data page PD ₄ , o. The node at position 1 was set before revision R ₄ . The node is of the type 22 and has the value <example>. The node at position 2 was set during revision R ₄ . The node is now of type 33 and has the value "new text".

Claims

claims

1. A method for storing a plurality of revisions (R _r ) of tree-structured data families, each of which has a number of data pages (P _r ) connected to each other in a tree-like manner with a central parent data page (P _r , o) and at least one child page originating therefrom. Data page (P _r , _P ', ..., P _r , p *), wherein for each revision (R _r ) a main reference pointer (RR ₁ -) to the central parent data page (P _r , o) of the respective data family is provided in a separately stored list and each parent data page (P _rp ) has at least one page reference pointer (PR _r , p) to logically immediately following linked child data pages (P _r , _P ', ..., Pr, p. ), characterized by storing node change information for each revision (R ₁ -) about changes in nodes of the tree-like linked data pages (P ₁ -, P _r , o, Pr.p - P _r , p *) -

2. The method according to claim 1, characterized in that the node change information identifying the addition of new nodes, the deletion of nodes and / or the change of nodes.

3. The method according to claim 1 or 2, characterized in that the

Data pages (P _n P _r , o, Pr.p-Pr, _P *) the change of the corresponding data page

(Pr, Pr, o _> Pr.p ¹ P _r , p *) of an immediately preceding revision (RM) in the form of non-binary difference data (PD _r , _x ).

4. The method according to any one of the preceding claims, characterized in that a data page (P _r ) contains the complete, optionally in the respective revision (R _r ) modified data content.

5. The method according to any one of the preceding claims, characterized in that the main reference pointer (RR _r ) or copies thereof on a another data storage medium (LD ₂ ) are stored separately from the referenced data pages (P _r ).

6. The method according to any one of claims 1 to 4, characterized in that the main reference pointers (RR _r ) or copies thereof in sectors (So, _s ) of a data storage medium (LDo) separated from the sectors (So, _s ) of the same data storage medium (LD ₀ ) are stored, in which the referenced data pages (P _r ) are stored.

7. The method according to any one of the preceding claims, characterized by securing the storage of revisions (R _r ) of data families by encryption by a secret master key (MK) defines and independent of the master key (MK) generates a supplementary identifier (SLT) (Salting) and from the master key (MK) and the additional recognition (SLT) a key (K) is derived (stretching), and for each data page (PP _r , x) a unique ad hoc key (N) and a counter (CTR ) is derived from results of the encryption / decryption algorithms of higher-level nodes for encryption, decryption and authentication of at least the assigned main reference pointers, data pages and at least one header (H _h ) for the entirety of the revision (R ₁ -) of stored data families.

8. The method according to any one of the preceding claims, characterized by reading stored revisions (R _r ) of data pages (P _r ), characterized by - verifying the match of stored copies of a header (H _h ) stored for the entirety of the revision (R _r ) Data families, - verifying the compliance of a copy of a main reference _pointer (RR _r ) for the current revision (R _ma χ (r)) stored in a separate data storage medium (LD ₂ ) or on a separate sector (S _OlS ) of a data storage _medium (LD ₀ ) with a main reference pointer (RRr) of the current revision (Rm _a ψ)) stored on a sector (S ₀ , _s ) of the data storage medium (LD ₂ ) together with the associated data pages (P _r ) of the revision (R _r ), Accessing data pages (PP _r , x) of desired revisions (R _r ) via pointers contained in the main reference pointer (RR _r ) for the corresponding revision (R _r ) and the page reference pointers (PR _r , _p ) and

Evaluating node change information for each revision (R _r ) about changes of nodes of the tree-like linked data pages (P _n P _r , ₀ , P _r , _P '

Pr, p ^* ) -

9. The method of claim 8, characterized by accessing desired revisions (R _r ) by means of a binary search algorithm on the list of main reference pointers (RR _r ), wherein a search on the basis of the revision number and / or one in the main reference pointer (RR _r ) stored timestamp he follows.

10. A method for storing a plurality of revisions (R ₁ -) of tree-structured, hierarchically linked data, the data being stored in a memory system as a node of a tree encoded for internal representation and made accessible via an interface, each node (ND _r , _p , n) is stored in a node field (NDA _rp ) of a data page (P _r , _p ) at a position (n), and wherein for each revision (R ₁ -) a revision reference (RRr) is applied to the data page (P _r , _p ), wherein for each revision (R ₁ -) with respect to the previous revision (R _r- i), changes of nodes (ND _r , _p , _n ) of the data page (P _rp ) in a node list (NDL _r , _p ) of a data page part (PP _r , _P ) are stored in such a way that the changes of nodes (ND _r , _p , _n ) of the data page (P _r , _p ) made during the revision (R _r ) are taken directly from the data page part (PP _r , _P ) are recognizable; and wherein the revision reference (RR _r ) contains at least one page sub-reference (PPR _r , _P ) on the data page part (PP _r , _P ) stored for this revision (R _r ).

11. The method of claim 10, wherein the data page (P _r , _p ) includes a page reference field (PRA _rp ) in which at least one position (n) at least one page reference (PR _r , _P 'PR _r , _P *) on at least another data page (P _r , p _' , ..., P _{r, p} ") which is a child data page of the data page (P _r , _p ) is stored; and where for each revision (R _r ) relative to the previous revision (R _r- i) changes of page references (PR _r , _P ', • ■., PRr, _P *) to child data pages (P _r , _P ' P _r , _P *) of the data page (P _{r, p} ) in a page reference list (PRL _r , _p ) of the data page part (PP _r , _p ) are stored.

12. The method of claim 11, wherein for each revision (R ₁ -) with respect to the previous revision (RM) changes of nodes (ND _r , _p , _n ) of the child data pages (P _r , _P ', ..., P _r , _p *) are stored in a node list (NDL _r , _p ) of a data page part (PP _r , _P ) in such a way that the changes made during the revision (R ₁ -) by nodes (ND _riP , _n ) of the child _page Data pages (P _r , _P 'P _r , _P *) directly from the data page part

(PP _rp ) are recognizable; and wherein the page reference (PR _r , _P 'PRr, _P *) at least one page sub-reference

(PPR _r , _p ) to the data page part (PP _r , _P ) stored for this revision (R _r ).

13. The method according to any one of claims 10 to 12, wherein the node list (NDL _rp ) of the data page part (PP _r , _P ) only during the revision (R _r ) made changes of nodes (ND _r , _p , _n ) of the data side ( P _{r, p} ), so that it is in particular a data page part (PD _{r, p} ), or the node list (NDL _rp ) of the data page part (PP _r , _P ) and the state of nodes (ND _r , _p , _n ) of the data page (P _r , _p ) which were not modified during the revision (Rr), in particular being a data page part (PS _rp ) representing the result of all past changes as well as the changes during the revision (R ₁ -) stores and thus contains the complete data content of the data page (P _r , _p ).

14. The method according to any one of claims 10 to 13, wherein the revision reference (RR _r ) contains information about the author and the time of the preparation of the revision (R ₁ -).

15. The method according to any one of claims 10 to 14, wherein each data page (P _r , _p , P _r , _P '_> •••, Pr, p *) to a revision number (r) and a

Page number (p) is bound to uniquely identify the data page from all others

Data pages, each data page part (PP _r , _P ) during all

Revisions (Rr) receives the same page number (p), and each page subreference (PPR _r , _p ) to a data page part (PP _r , _P ) with the

Revision number (r) of the revision (R _r ) during which this data page part

(PPr.p) was created.