WO2004025507A2 - Procede d'organisation d'une base de donnees numeriques sous une forme traçable - Google Patents

Procede d'organisation d'une base de donnees numeriques sous une forme traçable Download PDF

Info

Publication number
WO2004025507A2
WO2004025507A2 PCT/FR2003/002675 FR0302675W WO2004025507A2 WO 2004025507 A2 WO2004025507 A2 WO 2004025507A2 FR 0302675 W FR0302675 W FR 0302675W WO 2004025507 A2 WO2004025507 A2 WO 2004025507A2
Authority
WO
WIPO (PCT)
Prior art keywords
database
data
main
main database
digital
Prior art date
Application number
PCT/FR2003/002675
Other languages
English (en)
Other versions
WO2004025507A3 (fr
Inventor
Michel Zamfiroiu
Original Assignee
Karmic Software Research
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 Karmic Software Research filed Critical Karmic Software Research
Priority to AU2003278287A priority Critical patent/AU2003278287A1/en
Priority to EP03769596A priority patent/EP1537497A2/fr
Priority to US10/527,516 priority patent/US20060123059A1/en
Publication of WO2004025507A2 publication Critical patent/WO2004025507A2/fr
Publication of WO2004025507A3 publication Critical patent/WO2004025507A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21—Design, administration or maintenance of databases
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2358—Change logging, detection, and notification

Definitions

  • the present invention relates to the field of persistent data management of an entity, for example a company.
  • the present invention relates to the monitoring of this persistent data in a database by means of a Database Management System. It is indeed difficult for a company to guarantee the monitoring of the evolution process of strategic persistent data because this monitoring presents some objective obstacles:
  • the prior art also knows, from PCT patent application WO 02/27561 (Oracle), a system and a method for providing access to a temporal database.
  • the invention described in this document relates to a system and method for selective visualization of data in temporary rows in a constant reading database.
  • the saved transactions causing changes in the data in rows of a database are tracked and a change number of the stored system is assigned to each saved transaction.
  • a requested selection of data values in rows from the database is performed as well as an interrogation time taking place before the save time of at least one saved transaction.
  • the values of the data in ordered rows contained in the cancellation segments storing a transaction identifier for at least one saved transaction are recovered.
  • access to a pending recording means that data relating to fields which differ from the corresponding fields of the up-to-date recording are superimposed on such up-to-date recording fields but with a video or video attribute. character different from the video attribute or default character.
  • a plurality of historical or pending records can be composed so that all fields modified for a record set from the end of a defined period can be superimposed on an updated record at one time.
  • European patent application EP 0 984 369 is a mechanism for storing dated versions of data.
  • the data is stored as a plurality of records, each record comprising at least minus an attribute, a time marker indicating the duration for which the attribute is valid, an insertion time indicating when the record was created and a type field.
  • the type field indicates whether the record is a concrete record, a delta record, or an archived record replacing one or more records which have been archived.
  • Data is accessed to find an attribute value from the point of view of a "specified time", by extracting the records which have insertion times earlier than the "specified time” and constructing an attribute value from the extracted records.
  • Data is updated only by adding concrete records or delta records, without changing attribute values in concrete records or delta records.
  • the present invention intends to remedy the drawbacks of the prior art by proposing a method for monitoring the evolution of data in an architecture based on a DBMS, consisting of:
  • the main object of the invention is to allow the exploitation of the data of the base according to successive versions, while limiting the needs for time and storage capacity and to authorize the restitution on the fly.
  • a usual approach consists in recording successive versions of the databases, for example in the form of periodic storage on a medium such as a magnetic cartridge of the entire database, in the state corresponding to the current version. .
  • the search for information requires restoration prior to the entire database, from the medium corresponding to the corresponding backup, then to interrogate the base thus restored.
  • the volume corresponding to a state can exceed the terabyte, which volume should be multiplied by the number of saved states.
  • the invention aims to respond to the technical problem of real-time operation of large volume databases.
  • the invention relates in its most general sense to a method of organizing a digital database in a traceable form, comprising steps for modifying a main digital database by adding or deleting or modifying of a recording of the main database and of the steps of reading the main database, characterized in that the step of modifying the main database comprises an operation of creating at least one digital recording comprising at least : the unique digital identifiers of the records and attributes concerned in the main database, a digital identifier of the state of the main database corresponding to said modification of the main database, the elementary values of the attributes which are assigned to them affected through elementary operations, without storing attributes or records unmodified, and adding said record to an internal history database composed of at least one internal history table, and in that the reading step relating to any final or previous state of the main database consists in receiving (or intercept) an original request associated with the unique identifier of the targeted state, to carry out a transformation of said original request to construct a modified request for addressing the historical database comprising the criteria of the original request and the identifie
  • said records from the historization database also contain references to other records from the internal database, with the aim of specifying the dynamic dependency links of source-destination type constituting the causal flow of interference between versions of data.
  • said operation for modifying the main base is a logical operation and said operation for adding to the history database consists in adding: a record identifying the state of the base corresponding to the logical operation, as many 'records as parameters of the logical operation, a record for the possible result of the logical operation and to specify by a family link the groupings of operations from the elementary level of modification to the level of the transaction, passing the number of semantic levels necessary for the applications.
  • the main database contains one or more table (s), organizing the evolution links between the identifiers of the successive and alternative states of the main database, intended to organize the records of the database. internal data.
  • said one or more tables of evolution links between the states of the main database contain records specifying the rules for correspondence between the records of the internal historization database and the states of the main database.
  • said read operation consists in determining said state of the main database by referring to said identifiers and to the tables of evolution links between the states of the main database.
  • an application interrogating the main database can specify the state of the desired main database.
  • the invention also relates to a database management architecture characterized in that said application can make modifications on any state of the main database and giving rise, in the case of the attempt to modify a state prior to, to the creation of new alternatives for base development main data whose data will be generated by the same internal historical database.
  • the dependency links serve as criteria for questioning said operations already carried out.
  • the updates carried out on different branches can be integrated or merged in the context of a new state "inheriting" from said branches.
  • the cases of evolution of data structure of the main database are treated as particular cases of evolution of the data of said database, provided that the structure / schema of said main database be described as mentioned for the data, as a dictionary.
  • the historization database is explored and interrogated by applications through the native mode of the DBMS in order to obtain information such as for example all the historical values of an attribute and all the incidences
  • FIG. 1 illustrates a conventional architecture of communication between an application and a database
  • FIG. 2 illustrates a communication architecture similar to that of FIG. 1 and comprising the elements necessary for the application of the invention
  • FIG. 3 illustrates the different means of access to a traceable organized database provided with a system according to the invention.
  • the management of persistent data of a company is generally entrusted to specific software also called DBMS.
  • Computer applications offer users interactive ergonomic means capable of visualizing and changing the data in the company's database by communicating with the DBMS.
  • Relational DBMS (but also object, network or hierarchical) on the market are good candidates for the role of persistence manager. This compatibility is also an advantage of our process which can also take advantage of the software base installed in the company.
  • a Relational DBMS This allows the representation of data in the form of tables (or relationships).
  • the columns indicate the attributes (or fields). Each column is characterized by a field (integer, character, date, float, etc.) and other possible information such as the maximum size (for character strings).
  • Certain attributes constitute the key or the identifier of the record.
  • each row of the same table represents a new record (or tuple) of uniform structure.
  • Each cell represents the value of the attribute. For example, "aaa” is the value of the Attributl attribute of the first record whose key is 1001. Table
  • the data is inserted, read, modified and deleted through a data manipulation language (SQL for example).
  • SQL data manipulation language
  • the persistence manager also allows the definition, the consultation and the evolution of the data structure, also called data schema.
  • the tables can be defined, deleted or restructured. In the latter case, columns can be added or removed. Sometimes it is even useful to change the domain of an attribute, or other similar characteristics, which may involve implicit or explicit processing of the conversion of the data concerned.
  • the table is the logical reference for data representation.
  • applications generally "see” data in the form of tables. It is important to emphasize that our system wants to preserve this logical representation in order to ensure the greatest compatibility with existing applications. For example, after having requested the connection to a particular database, an application can address a persistence manager with a request of type "select * from client" and receive in exchange a set of data allowing the reconstruction of the data in tabular form.
  • a database represents a coherent state of the real world represented.
  • the data in the database evolves in jerks triggered by events through operations (insertion, update or deletion) generally grouped into transactions. These are characterized by special properties called ACID (Atomicity, Coherence, Insulation and Durability) which guarantee a certain level of quality.
  • ACID Automaticity, Coherence, Insulation and Durability
  • Ensuring the traceability of persistent data amounts to providing means allowing upstream and downstream monitoring of the data evolution process.
  • the first level of traceability which can be described as elementary, is that of the representation and storage of data. It is therefore a question of describing the structure, then of storing and identifying the data, whether it is an order, an article or even a mechanical part, in order to be able to find it later. .
  • This type of functionality is already provided by specialized software, called Database Management Systems (DBMS).
  • DBMS Database Management Systems
  • the process of evolution is manifested by the successive application of elementary operations such as reading, insertion, updating and deletion. These elementary operations are generally grouped into transactions in order to maintain the consistency of the data under conditions of concurrent use or even fault recovery.
  • the updates have as a natural consequence the loss of existing values following their replacement by new values, since - by convention - to the same identifier can only correspond to a single datum (with its attributes).
  • This first so-called elementary level of traceability is essential but largely insufficient.
  • the second level of traceability authorizes data to have several versions at the same time (separate values). This improves traceability since it becomes possible to have at any time both the values preceding and those following the execution of an operation or a process, which makes it easier to understand the evolution.
  • the version introduces a precious quality, since irreversibility is no longer inescapable (data evolution is allowed, without loss of current values). In addition to successive versions, there are alternative versions.
  • a third level of traceability is that of operations. Tracing an operation is like leaving a persistent trace of the execution of said operation, allowing an even better understanding of how the data evolves. We can thus better explain the evolution of an order between two versions, if we know for example that there was a discount operation on the total price.
  • Most DBMS have logging mechanisms that allow viewing of operations performed at the elementary level. To be understandable by users, this information must be correlated with high-level operations, but the basic problem is that the log entries do not have the same persistence cycle as the data. Thus, the log is generally located outside the database and is regularly purged by the administrator.
  • PCT patent application WO 02/27561 provides an alternative solution to this problem, by proposing internal storage (in the database) of transactions and cancellation information of their effects (undo), which allows to recover any previous state of the database by executing in reverse order the reverse of the operations which have taken place since.
  • this technique can be very expensive in terms of execution time because, to find a precise version of a data, it undoes all the operations that take place since, including those that do not concern it.
  • it is also not suitable for obtaining the list of all the versions of a data item.
  • the inventors have opted for a strategy opposite: upon receipt of a request, the present invention proceeds to the transformation thereof then to an execution on the versioned data.
  • the need for higher level information for example provided by applications, in order to obtain an articulation between the semantics of the applications (application of a discount on an order) and that of the DBMS (update day of the attribute "amount" of the order).
  • the most advanced level of traceability is that of causality. It aims to materialize information transport links at the most basic level (the finest grain).
  • a particular case of evolution operation concerns the evolution of the schema which consists in changing the structure of the data without loss of information
  • One of the objectives of the present invention is to propose a slightly intrusive and progressive method of organizing a digital database in a traceable form. We aim to ensure the successive levels of traceability described above, without imposing the redesign of existing applications.
  • the objective pursued by the invention is to provide computer applications and their users with the ability to accurately track data throughout its evolution, by tracing their stories in a comprehensive manner, as well on the individual level (intermediate versions and links of succession) than on the collective level (triggering events and dynamic links of interdependence resulting from the interactions between the versions of the data), in the positioning it within the coherent framework of its original development.
  • the method according to the invention uses a flexible architectural framework, as unconstraining and intrusive as possible in order to provide very broad applicability to the proposed method and as wide compatibility as possible with the methods of storing and manipulating current data.
  • the method according to the invention makes it possible to ensure that it represents not only one but all the successive and / or alternative coherent states. necessary from the real world represented in its evolution, while preserving the ACID properties.
  • journal organized in the form of an “internal historization database” consisting of a table or a set of tables dedicated to monitoring evolution and based on a universal storage mode with a stable schema (independent of the logical representation of application data) and particularly suitable for on-the-fly data reconstruction.
  • a transaction and event monitor capable of detecting any request for changes in values and structure transmitted to the database, which gradually adds entries to the dedicated log characterizing the elementary evolution of the data (identity, attribute, value, triggering event and dynamic dependencies) a reconstitution module (R) on the fly of the state of the database according to a target event; the system is provided for this purpose with a cursor (C) dedicated to the selection of the desired state.
  • R reconstitution module
  • C dedicated to the selection of the desired state.
  • special case in some cases, it may be useful to materialize the view of the so-called "current" or "main” base in the form of specialized structure tables, for example to allow high performance and total compatibility with existing applications (in particular to allow the use of stored procedures and other triggers or triggers that an application may require to function properly).
  • the architecture also includes:
  • the event log (J) (or the internal history database) is made up mainly from a table with a structure independent of that of the application data.
  • the columns are:
  • the role of the monitor (M) is to correctly detect and interpret each change request by adding the corresponding information to the event log (J).
  • each event that tends to modify the logical database ends up creating one or more entries in the form of new lines (or records) in the log. This ensures that nothing is lost and that any logical deletion or update does not result in physical deletion. Thus, data from the past can be recovered.
  • One of the advantages of this organization is the concurrent creation of views such as account books which generally block the update access of other users.
  • the uniformity of the information storage structure the data is stored in identical fashion, whether it is the evolution of values or that of structures. This means that from a logical point of view, it is possible to reconstruct both logical tables and their structures, on the basis of the same mechanism.
  • the fact of including the journal in the same database as the main database makes it possible to guarantee its relative coherence by the transaction mechanism provided by the DBMS.
  • the reconstruction module (R) is in charge of restoring the data in logical format according to an event type parameter, from the event log (J).
  • the journal can accommodate invocations of operations. This can be done by representing the operations under the form of logical tables, where each operation corresponds to a logical table name and each argument corresponds to a logical attribute.
  • the application can send to the journal (for example, via an API: "Application Programming Interface") the information necessary for the traceability of calls to operation analogous to the manipulation of logical data (but this task can be automated and entrusted to a post-processor, to the compiler, to the processor or even to the virtual machine).
  • transaction validation points can be plotted in the form of operations. Indeed, it is recommended that the cursor is positioned exactly on these points and not between two operations of the same transaction. The consistency of the result depends on it.
  • applications such as design assistance tools may very well benefit from intermediate states, deemed to be incoherent, for explanatory purposes, and thus benefit from mechanisms of the “long transactions” type.
  • the invention also relates to the materialization of causal links.
  • attribute 4 was formed from attributes 2 and
  • the implementation of the sources in the journal can very well be carried out by the intermediary of an additional journal (or sub-table), organized in a tabular manner, and this for reasons of performance optimization, according to the techniques in force. in the discipline of databases.
  • the validity check of operations can be carried out against the data in force. For example, if the value of the Attr3 attribute of Client 110 changes after the execution of the "add" operation, the results sent by this operation can no longer be considered as compliant. It is said that there is “questioning”. In the case of an evolution without alternatives, this can be verified by a simple comparison of UEID between the sources of the arguments and the last values of the referenced sources.
  • This characteristic of the process also makes it possible to set up an automatic optimization system, which - on the basis of the systematic verification of the validity of the sources - makes it possible to return the result calculated previously, without actually re-executing the operation.
  • the implementation of such a solution involves the introduction of references to the calling operations (which can be done through additional arguments) and provided that the verification time is less than that of execution (statistics of performances can be maintained for information purposes and exploited effectively).
  • Automatic notification of "questioning” may be implemented on the basis of the information concerning the validity of the versions of the data in relation to the flows. So, for an operation, a class operation, a target or a given source, flow consistency alerters will be able to notify the applications by synchronous or asynchronous messages.
  • the re-execution consists of a new explicit invocation of a given operation on the model of a previous invocation, but on the basis of new values. In all cases, it will give rise to new values for the data, the operations and the traced sources.
  • the method according to the invention is specially designed to manage operationally the historization over the water and the restoration on the fly.
  • the management of storage volumes is facilitated and optimized by a set of factors:
  • the necessary volumes of additional storage increase linearly with the number of attributes modified or deleted and do not depend on the volumes of data inserted in the database; this factor allows very advantageous use for a very wide spectrum of applications.
  • the very relevant purges can be operated according to the data marked as called into question by the source-destination type traceability links, but this operation must be controlled by the applications according to the semantics of the called into question.
  • Tree structure each event has a parent event. The value of a datum associated with an event can be obtained by a logical ascent of the parents to the nearest value.
  • Graph oriented without circuit analogous to the tree structure, this organization allows a version to have several different parents. The ambiguities of resolution can be resolved by predefined rules, based on criteria of priority of the branches or on any other characteristic of the data (its type, etc.)
  • Virtual versions are predefined event branches that allow the creation of parallel configurations that can simultaneously benefit from events applied to one or more so-called “reference” branches.
  • the architecture implemented for the realization of the invention may also include the following modules • a system for monitoring compliance (SC) of the applications with the states of the database and its diagram.
  • SC system for monitoring compliance
  • the principle is based on the registration of a version identifier of the application in order to declare a level of compatibility with the state or states corresponding to the schema of the main database
  • the invention can be implemented in several ways depending on the context in which it is integrated into an application.
  • Figure 3 presents an architecture which allows three levels of integration of traceability, from bottom to top:
  • Existing applications can continue to access the (so-called “main”) database in the same way.
  • the database can either keep its original structure and redirect access to an associated log (called internal database), or evolve towards a physical log-type organization and offer views or a driver responsible for translating requests and results .
  • Existing applications can be very easily provided with a "cursor" provided that access to the data is centralized (which is generally the case, for example through a single driver).
  • the application may offer automatic means of access to the data in the database (now implemented in the form of a log) and allow users to activate a cursor which will position the readings on the desired event marker. Slight adaptations may take place in order to match the granularity of the events with the semantics of the application.
  • branches offer the possibility of creating alternatives for upgrading the database. At the same time, this raises new problems with regard to traceability. Indeed, supposing that after the separation of the branches A and B, the data X is modified in the branch A through the operation 0. One can then wish to return its new value in the branch B, as if it had had this value at the time of the separation of the branches.
  • This operation called refreshing, is very useful for many cases where institutional reference data are received at more or less regular intervals.
  • Their integration can then pose problems of interference with the operations carried out in the meantime. For example, if no operation having as source or destination the data X in the branch B has not been carried out in the meantime, we can calmly consider that there is no impact. On the other hand, if it is the case, it will then be necessary to decide
  • Virtual branches - which are by definition permanently refreshed by their “parent” branches - automatically benefit from data refresh in their parent branches, including disconnection operations (creation of new branches) which take place (virtually, of course ) at the same time on the virtual branches. For example, if branch B is virtual, then any operation carried out on branch A is automatically reflected on branch B. In addition, if we create a new branch A2 from A, this will have the effect creation of a similar B2 sub-branch from B. It is important to underline the virtual character of these refreshments. This means that in reality no treatment is actually carried out. The only effect is that a next request on branch B will have an enriched result (which takes into account the refreshed data). Finally, note that in the event of automatic propagation, there is no automatic conflict resolution, unless rules have been predefined. In some cases, it can be decided in advance that, by default, what has been explicitly modified in the virtual branch has priority over the data generated by refresh.

Landscapes

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

Abstract

Procédé d'organisation d'une base de données numériques sous une forme traçable, comportant des étapes de modification d'une base de données numériques principale par ajout, suppression ou modification d'un enregistrement de la base principale et des étapes de lecture de la base de données principale, caractérisé en ce que l'étape de modification de la base de données principale comprend une opération de création d'au moins un enregistrement numérique comportant : les identifiants numériques uniques des enregistrements et des attributs concernés de la base de données principale, un identifiant numérique unique de l'état de la base de données principale correspondant à ladite modification, de la base de données principale, les valeurs élémentaires des attributs qui leur sont affectées à travers les opérations élémentaires, sans procéder au stockage des attributs ou des enregistrements non modifiés, et d'ajout dudit enregistrement dans une base d'historisation interne composée d'au moins une table, et en ce que l'étape de lecture portant sur tout état final ou antérieur de la base de données principale consiste à recevoir une requête originelle associée à l'identificateur unique de l'état visé.

Description

PROCEDE D'ORGANISATION D'UNE BASE DE DONNEES NUMERIQUES SOUS UNE FORME TRAÇABLE
La présente invention se rapporte au domaine de la gestion des données persistantes d'une entité, par exemple une entreprise. En particulier, la présente invention se rapporte au suivi de ces données persistantes dans une base de données par l'intermédiaire d'un Système de Gestion de Base de Données. Il est en effet difficile pour une entreprise de garantir le suivi du processus d'évolution des données persistantes stratégiques car ce suivi présente quelques obstacles objectifs :
• Caractère asynchrone et collaboratif du déroulement du processus
• Caractère très exigeant du suivi pour constituer une réelle garantie : la présence d'un maillon faible compromet définitivement la fiabilité de toute réponse
• Non disponibilité de solutions génériques de prise en charge de la traçabilité dans les couches logicielles du marché à un niveau de granularité satisfaisant : OS, SGBD, langage de développement
• Coût très élevé de récriture des applications existantes et coût très élevé de prise en compte explicite de la traçabilité par chaque application.
L'art antérieur connaît déjà par la demande de brevet international WO 9935566 un procédé d'identification et de suivi des évolutions d'un ensemble de composants logiciels. Le procédé proposé par ce document de l'art antérieur permet de recenser des composants par leur nom et leur version. Cette classification au niveau fichier ne correspond pas au problème de conserver des traces de données de manière continue, c'est-à-dire à chaque modification desdites données. En particulier, le procédé proposé ne convient pas pour tracer une base de données modifiée à chaque accès en écriture.
Il est proposé, dans le brevet américain US 5,347,653 une méthode fournissant une perspective historique à une base de données d'objets grâce à un versionnement des objets stockés ainsi qu'à une indexation représentative des objets. Cette méthode de l'art antérieur propose de stocker intégralement la dernière version de la base de données et de stocker d'autre part les différences à appliquer à cette dernière version pour obtenir des versions antérieures. Le problème posé par ce document est la nécessité d'appliquer les différences une à une et en série pour trouver l'état de la base à une date donnée. Cette contrainte implique un coût en temps important.
L'art antérieur connaît également, par la demande de brevet PCT WO 02/27561 (Oracle) , un système et un procédé pour fournir un accès à une base de données temporelle. L'invention décrite dans ce document concerne un système et un procédé de visualisation sélective de données en rangées temporaires dans une base de données de lecture constante. Les transactions sauvegardées provoquant des changements dans les données en rangées d'une base de données sont pistées et un numéro de changement du système stocké est assigné à chaque transaction sauvegardée. Une sélection demandée de valeurs de données en rangées de la base de données est exécutée ainsi qu'un temps d'interrogation ayant lieu avant le temps de sauvegarde d'au moins une transaction sauvegardée. Les valeurs des données en rangées ordonnées contenues dans les segments d'annulation stockant un identificateur de transaction pour au moins une transaction sauvegardée sont récupérées . L'art antérieur connaît également, par la demande de brevet PCT WO 92/13310 (Tandem Télécommunications Systems) , un procédé de sélection et de représentation de données variant dans le temps à partir d'un système de gestion d'une base de données évoluant en fonction du temps, ledit procédé produisant une vue unifiée sur un écran d'ordinateur. Les données provenant d'un enregistrement maître relatif à une entité particulière sont affichées avec un attribut vidéo ou de caractère par défaut, et sont considérées comme étant l'enregistrement à jour. L'accès à un enregistrement historique relatif à cette entité fait que les données relatives à des champs qui diffèrent des champs correspondants de l'enregistrement à jour sont superposées à de tels champs d'enregistrement à jour mais avec un attribut vidéo ou de caractère différent de l'attribut vidéo ou de caractère par défaut. L'enregistrement à jour superposé devient un nouvel enregistrement à jour destiné à d'autres superpositions. De la même façon, l'accès à un enregistrement en suspens fait que les données relatives à des champs qui diffèrent des champs correspondants de l'enregistrement à jour sont superposées à de tels champs d'enregistrement à jour mais avec un attribut vidéo ou de caractère différent de l'attribut vidéo ou de caractère par défaut. Une pluralité d'enregistrements historiques ou en suspens peuvent être composés de sorte que tous les champs modifiés pour un jeu d'enregistrement à partir de la fin d'une période définie peuvent être superposés à un enregistrement à jour en une seule fois. On connaît également, par la demande de brevet européen EP 0 984 369 (Fujitsu), un mécanisme de stockage de versions datées de données. Dans ce mécanisme de stockage, les données sont stockées comme une pluralité d'enregistrements, chaque enregistrement comportant au moins un attribut, un marqueur de temps indiquant la durée pour laquelle l'attribut est valide, un temps d'insertion indiquant le moment où l'enregistrement a été créé et un champ de type. Le champ de type indique si l'enregistrement est un enregistrement concret, un enregistrement delta, ou un enregistrement d'archivé remplaçant un ou plusieurs enregistrements qui ont été archivés. On accède aux données pour trouver une valeur d'attribut du point de vue d'un « temps spécifié », en réalisant une extraction des enregistrements qui possèdent des temps d'insertion antérieurs au « temps spécifié » et en construisant une valeur d'attribut à partir des enregistrements extraits. Les données sont mises à jour uniquement en ajoutant des enregistrements concrets ou des enregistrements delta, sans modifier les valeurs d'attribut dans les enregistrements concrets ou les enregistrements delta.
La présente invention entend remédier aux inconvénients de l'art antérieur en proposant un procédé de suivi de l'évolution des données dans une architecture basée sur un SGBD, consistant en :
• la matérialisation des versions intermédiaires et des flux de données résultantes des opérations effectuées sur la base de données, au fur et à mesure de son évolution, au niveau de granularité élémentaire (enregistrement par enregistrement et attribut par attribut) ;
• la possibilité de reconstitution et restitution « rapide » de tout état cadre historique d'origine de chaque version de donnée et chaque opération (par « rapide » nous comprenons « sans temps additionnel perceptible lié à la restauration ») ; comprenant :
• des mécanismes de reconstitution de flux de dépendance causale (de type source-destination) entre les données concernées ;
• des mécanismes de notification de remise en cause des opérations du passé en cas d'évolution des données d'entrée ; • des mécanismes de ré-exécution ;
et couvrant les cas particuliers et les extensions suivants :
• prise en compte de l'évolution structurelle (évolution de schéma) ;
• prise en compte de l'évolution des applications ;
• prise en compte des applications existantes dans un cadre architectural flexible ; • schémas d'évolution graduelle d'une architecture à l'échelle de l'entreprise ;
• gestion de versions virtuelles (familles alternatives et hypothèses parallèles) .
Le but principal de l'invention est de permettre l'exploitation des données de la base selon des versions successives, tout en limitant les besoins de temps et capacité de stockage et à autoriser la restitution à la volée.
Une démarche habituelle consiste à enregistrer des versions successives des bases de données, par exemple sous la forme de stockage périodique sur un support telle qu'une cartouche magnétique de l'intégralité de la base de données, dans l'état correspondant à la version courante. La recherche d'une information nécessite la restauration préalable de toute la base, à partir du support correspondant à la sauvegarde correspondante, puis à interroger la base ainsi restaurée. Pour des bases de données importantes telles qu'exploitées dans le domaine bancaire, de l'assurance ou de la gestion, le volume correspondant à un état peut dépasser le téraoctet, volume qu'il convient de multiplier par le nombre d'états sauvegardés .
Cette solution est totalement inadaptée à l'exploitation en temps réel.
L'invention vise à répondre au problème technique de l'exploitation en temps réel de bases de données de grande volume .
A cet effet, l'invention concerne dans son acception la plus générale un procédé d'organisation d'une base de données numérique sous une forme traçable, comportant des étapes de modification d'une base de données numériques principale par ajout ou suppression ou modification d'un enregistrement de la base principale et des étapes de lecture de la base de données principale, caractérisé en ce que l'étape de modification de la base de données principale comprend une opération de création d'au moins un enregistrement numérique comportant au moins : les identifiants numériques uniques des enregistrements et des attributs concernés de la base de données principale, un identifiant numérique de l'état de la base de données principale correspondant à ladite modification de la base de données principale, les valeurs élémentaires des attributs qui leur sont affectées à travers les opérations élémentaires, sans procéder au stockage des attributs ou des enregistrements non modifiés, et d'ajout dudit enregistrement dans une base d'historisation interne composée d'au moins une table d'historisation interne, et en ce que l'étape de lecture portant sur tout état final ou antérieur de la base de données principale consiste à recevoir (ou intercepter) une requête originelle associée à l'identificateur unique de l'état visé, à procéder à une transformation de ladite requête originelle pour construire une requête modifiée d'adressage de la base d'historisation comprenant les critères de la requête originelle et l'identificateur de l'état visé, et de reconstruction du ou des enregistrements correspondant aux critères de la requête originelle et à l'état visé, ladite étape de reconstitution consistant à retrouver les valeurs élémentaires, contenues dans les enregistrements de la base d'historisation, correspondant aux critères de la requête originelle [afin de réduire les besoins de capacité de stockage et les temps de traitement] .
Selon une variante, lesdits enregistrements de la base de données d'historisation contiennent également des références à d'autres enregistrements de la base de données interne, dans le but de préciser les liens de dépendance dynamique de type source-destination constituant le flux causal des interférences entre les versions des données.
Avantageusement, ladite opération de modification de la base principale est une opération logique et ladite opération d'ajout dans la base de données d'historisation consiste à ajouter : un enregistrement identifiant l'état de la base correspondant à l'opération logique, autant d'enregistrements que de paramètres de l'opération logique, un enregistrement pour le résultat éventuel de l'opération logique et à préciser par un lien de parenté les regroupements d'opérations depuis le niveau élémentaire de modification jusqu'au niveau de la transaction, en passant le nombre de niveaux sémantiques nécessaires pour les applications .
Selon une autre variante, la base de données principale contient une ou plusieurs table (s), organisant les liens d'évolution entre les identifiants des états successifs et alternatifs de la base principale, destinée (s) à organiser les enregistrements de la base de données interne.
De préférence, ladite ou lesdites tables des liens d'évolution entre les états de la base principale contiennent des enregistrements spécifiant les règles de correspondance entre les enregistrements de la base de données interne d'historisation et les états de la base de données principale. Selon un mode de mise en œuvre particulier, ladite opération de lecture consiste à déterminer ledit état de la base de données principale en se référant aux dits identifiants et aux tables des liens d'évolution entre les états de la base principale. Avantageusement, une application interrogeant la base de données principale peut spécifier l'état de la base de données principale désiré.
L'invention concerne également une architecture de gestion de base de données caractérisée en ce que ladite application peut opérer des modifications sur tout état de la base principale et donnant lieu, dans le cas de la tentative de modification d'un état antérieur, à la création de nouvelles alternatives d'évolution de la base de données principale dont les données seront générées par la même base d'historisation interne.
Selon une variante, les liens de dépendances servent de critères de remise en cause desdites opérations déjà effectuées.
De préférence, les mises à jour effectuées sur des branches différentes pourront être intégrées ou fusionnées dans le cadre d'un nouvel état « héritant » desdites branches.
Selon un mode de mise en œuvre particulier, les cas d'évolution de structure des données de la base de données principale sont traités comme des cas particuliers d'évolution des données de ladite base, pour peu que la structure/schéma de ladite base principale soit décrite de la façon mentionnée pour les données, en tant que dictionnaire.
Selon une autre variante, la base de données d'historisation est explorée et interrogée par des applications à travers le mode natif du SGBD afin d'obtenir des informations comme par exemple toutes les valeurs historiques d'un attribut et toutes les incidences
(dynamiques) de toute mise à jour et de naviguer au long des versions et des flux de dépendance dynamique et ceci de façon classique, selon le langage d'interrogation en vigueur, exigé par le SGBD.
On comprendra mieux la présente invention à l'aide de la description, faite ci-après à titre purement explicatif, d'un mode de réalisation de l'invention, en référence aux figures annexées :
La figure 1 illustre une architecture classique de communication entre une application et une base de données ; La figure 2 illustre une architecture de communication similaire à celle de la figure 1 et comprenant les éléments nécessaires à l'application de l'invention ; La figure 3 illustre les différents moyens d'accès à une base de données organisée de façon traçable munie d'un système selon l'invention.
La gestion des données persistantes d'une entreprise (ou d'une organisation au sens large) est généralement confiée à un logiciel spécifique appelé aussi SGBD. Les applications informatiques proposent aux utilisateurs des moyens ergonomiques interactifs capables de visualiser et faire évoluer les données de la base de données de l'entreprise en communiquant avec le SGBD. Dans les paragraphes suivants, nous rappelons les principales caractéristiques de l'architecture afin de positionner le cadre de notre procédé de suivi de l'évolution des données et d'en fixer le vocabulaire minimal. Le gestionnaire de persistance nécessaire pour notre système autorise le stockage des données et leur reconstitution en mémoire en conformité avec leur structure
(définie comme un ensemble d'attributs) et les valeurs saisies ou calculées. Les principaux SGBD Relationnels (mais aussi bien de type objet, réseau ou hiérarchiques) du marché sont des bons candidats pour le rôle de gestionnaire de persistance. Cette compatibilité est d'ailleurs un atout de notre procédé qui peut aussi tirer ainsi profit de la base logicielle installée dans l'entreprise. Considérons par simplification - et uniquement à titre d'exemple - l'utilisation d'un SGBD Relationnel. Celui-ci permet la représentation des données sous forme de tables (ou relations) . Les colonnes indiquent les attributs (ou champs) . Chaque colonne est caractérisée par un domaine (entier, caractère, date, flottant, etc.) et d'autres informations éventuelles comme la taille maximale (pour les chaînes de caractères) . Certains attributs (un ou plusieurs) constituent la clé ou l'identifiant de l'enregistrement. Dans la figure suivante, nous avons représenté une table et nous avons indiqué les clés en mode souligné. Chaque ligne d'une même table représente un nouvel enregistrement (ou n-uplet) de structure uniforme. Chaque cellule représente la valeur de l'attribut. Par exemple, « aaa » est la valeur de l'attribut Attributl du premier enregistrement dont la clé est 1001. Table
Figure imgf000013_0001
Les données sont insérées, lues, modifiées et supprimées à travers un langage de manipulation de données (SQL par exemple) .
Le gestionnaire de persistance permet également la définition, la consultation et l'évolution de la structure des données, appelée aussi schéma de données. Ainsi, les tables peuvent être définies, supprimées ou restructurées. Dans le dernier cas, des colonnes peuvent être rajoutées ou supprimées. Parfois, il est utile même de changer le domaine d'un attribut, ou d'autres caractéristiques analogues, ce qui peut impliquer des traitements implicites ou explicites de conversion des données concernées .
Quelle que soit la représentation physique des données, la table est la référence logique de représentation des données. Ainsi, les applications « voient » généralement les données sous la forme de tables. Il est important de souligner que notre système tient à préserver cette représentation logique afin de s'assurer la plus grande compatibilité avec les applications existantes. Par exemple, après avoir demandé la connexion à une base de données particulière, une application peut s'adresser à un gestionnaire de persistance avec une requête de type "sélect * from client" et recevoir en échange un ensemble de données permettant la reconstitution des données sous forme tabulaire.
Précisons enfin qu'une base de données représente un état cohérent du monde réel représenté. Les données de la base évoluent par à-coups déclenchés par des événements à travers des opérations (insertion, mise à jour ou suppression) regroupées généralement en transactions. Ces dernières sont caractérisées par des propriétés particulières dites ACID (Atomicité, Cohérence, Isolation et Durabilité) qui garantissent un certain niveau de qualité.
Assurer la traçabilité des données persistantes revient à fournir des moyens permettant le suivi en amont et en aval du processus d'évolution des données.
Le processus d' évolution des données est une sui te généralement non prédict ible d ' exécut ions d' opérations élémentaires qui lisent , transforment et écrivent les données de façon répétée, donnant lieu le plus souvent à des interférences multiples et complexes qui rendent difficile et souvent impossible leur suivi . Assurer la traçabilité du processus revient à être capable de remonter à tout moment vers les origines (débuts ) du processus , retrouver les valeurs des données d' origine , pouvoir suivre et comprendre au fil des opérations leurs conséquences en termes d'impact de changements. En termes de qualité de l'information, la traçabilité est très précieuse car elle permet de garantir la conformité du résultat d'une opération appliqué avec le jeu de données d' entrée.
Pour mieux comprendre l'étendue de sa portée, nous présentons une classification de la traçabilité selon des niveaux de plus en plus avancés :
• le premier niveau de traçabilité, que l'on peut qualifier d'élémentaire, est celui de la représentation et du stockage des données. Il s'agit donc de décrire la structure, puis de stocker et d'identifier la donnée, qu'il s'agisse d'une commande, d'un article ou encore d'une pièce mécanique, afin de pouvoir la retrouver plus tard. Ce type de fonctionnalité est déjà assuré par des logiciels spécialisés, appelés Systèmes de Gestion de Bases de Données (SGBD) . Le processus d'évolution se manifeste par l'application successive d'opérations élémentaires comme la lecture, l'insertion, la mise à jour et la suppression. Ces opérations élémentaires sont généralement regroupées en transactions afin de maintenir la cohérence des données dans des conditions d'utilisation concurrente ou encore de reprise sur panne. A ce niveau, les mises à jour ont comme conséquence naturelle la perte des valeurs existantes suite à leur remplacement par des nouvelles valeurs, puisque - par convention - à un même identifiant ne peut correspondre qu'une seule donnée (avec ses attributs) . Ce premier niveau dit élémentaire de traçabilité est indispensable mais largement insuffisant. le second niveau de traçabilité autorise une donnée à disposer en même temps de plusieurs versions (valeurs distinctes) . Cela améliore la traçabilité puisqu' il devient possible de disposer à tout moment aussi bien des valeurs précédant que de celles suivant l'exécution d'une opération ou d'un processus, ce qui facilite davantage la compréhension de l'évolution. Le versionement introduit une qualité précieuse, puisque l'irréversibilité n'est plus incontournable (on permet l'évolution des données, sans perte des valeurs actuelles) . En plus des versions successives, il existe des versions alternatives. Il arrive souvent qu'un utilisateur - après avoir remonté le fil d'exécution d'un processus - souhaite opérer quelques changements sur l'état antérieur des données. Dans ces cas, les mécanismes de versionement permettent la prise en compte d'alternatives, ou des branches d'évolution qui autorisent plusieurs suites possibles à partir d'un même état de la base. Un système de traçabilité avancé doit donc intégrer cet aspect, d'autant plus qu'une nouvelle branche permet de ne pas détruire les précédentes et de préserver ainsi la traçabilité des processus antérieurs. Il existe des nombreux travaux qui prennent en compte les données dont les valeurs évoluent dans le temps . Le domaine des bases de données temporelles distingue clairement l'axe du temps de validité de celui du temps de transaction. Le temps de validité permet de préciser par exemple qu'un tarif est valable de telle à telle date. Cette information est totalement indépendante de la date de la mise à jour de la donnée qui la stocke dans la base et qui se situe dans le temps dit transactionnel. De par la nature spécifique de leurs problématiques, les mécanismes de prise en compte du temps de validité comprennent des solutions d'interrogation et de mise à jour [Publication de R. Snodgrass « The temporal query language Tquel » ACM Transactions on database Systems, Association for Computer Machinery. New York, USA] , proposent des opérateurs dédiés à la prise en compte d' intervalles (between, before, etc) , et traitent spécifiquement les cas de mise à jour d'intervalles de temps pour une même donnée qui impliquent la fusion ou la division [Demande de brevet européen EP 0 984 369 (Fujitsu)]. Par ailleurs, la représentation et l'affichage des différentes versions réclament à leur tour des solutions spécifiques [Demande de brevet PCT WO 92/13310 (Tandem Télécommunications Systems)] qui facilitent la compréhension de l'évolution de données individuelles, sans se préoccuper de branches ou encore du critère global de cohérence collective des données de la base dans l'espace de versionement. En effet, ces aspects se situent en dehors de la problématique de traçabilité qui maintient vis-à-vis du versionement une série d'exigences qui lui sont propres et qui restent toujours non résolues. Citons enfin l'archivage et la restauration comme mécanismes permettant de retrouver des états antérieurs de la base de données. Il est évident en revanche leur inadéquation face à la problématique de traçabilité, pour des raisons de granularité trop grossière de suivi de l'évolution engendrant des inconvénients insolubles de temps de réponse et d'espace de stockage. En conclusion, le versionement est également indispensable pour assurer la traçabilité, mais reste, comme nous le verrons plus bas, toujours insuffisant.
un troisième niveau de traçabilité est celui des opérations. Tracer une opération revient à laisser une trace persistante de l'exécution de ladite opération, permettant une encore meilleure compréhension de la façon dont les données évoluent. On peut ainsi mieux expliquer l'évolution d'une commande entre deux versions, si l'on sait par exemple qu'il y a eu une opération de remise sur le prix total. La plupart des SGBD disposent de mécanismes de journalisation qui autorisent la consultation des opérations effectuées au niveau élémentaire. Pour qu'elles soient compréhensibles par les utilisateurs, ces informations doivent être corrélées avec les opérations de haut niveau, or le problème de fond est que les entrées du journal n'ont pas le même cycle de persistance que les données. Ainsi, le journal se trouve généralement en dehors de la base de données et se voit régulièrement purgé par l'administrateur. La demande de brevet PCT WO 02/27561 (Oracle) apporte une solution alternative à ce problème, en proposant le stockage interne (dans la base de données) des transactions et des informations d'annulation de leurs effets (undo) , ce qui permet de retrouver tout état antérieur de la base de données par l'exécution dans l'ordre inversé de l'inverse des opérations qui ont eu lieu depuis. Bien qu'intéressante, cette technique peut être très onéreuse en termes de temps d'exécution car, pour retrouver une version précise d'une donnée, elle défait toutes les opérations qui ont lieu depuis, y compris celles qui ne la concernent pas. De plus, elle n'est pas appropriée non plus pour obtenir la liste de toutes les versions d'une donnée. Enfin, elle interdit toute mise à jour à partir d'un état antérieur de la base, ce qui écarte les variantes et les branches alternatives d'évolution. Comme nous le verrons plus loin, dans la présente invention, les inventeurs ont opté pour une stratégie opposée : à la réception d'une requête on procède dans la présente invention à la transformation de celle-ci puis à une exécution sur les données versionees. Notons enfin, la nécessité de disposer d'informations de plus haut niveau, fournies par exemple par les applications, afin d'obtenir une articulation entre la sémantique des applications (application d'une remise sur une commande) et celle du SGBD (mise à jour de l'attribut « montant » de la commande) . le niveau le plus avancé de la traçabilité est celui de la causalité. Il vise la matérialisation des liens de transport d'information au niveau le plus élémentaire (le grain le plus fin) . Par exemple, si une opération quelconque 0 procède à la lecture de l'attribut A de la donnée X, à la lecture de l'attribut B de la donnée Y, à l'addition des deux et au stockage de la valeur ainsi obtenue dans l'attribut C de la donnée Z, un lien causal serait capable de reconstituer ce transport d' information à travers les différentes versions des données X, Y et Z, ainsi qu'aux diverses exécutions de l'opération 0. Cette précieuse information permet de comprendre les détails des évolutions, d'expliquer transitivement les origines des modifications et de détecter les opérations qui sont à refaire en cas d'évolution des données d'origine. Elle est surtout importante parce que - contrairement aux techniques de journalisation - elle se défait de la contrainte séquentielle des opérations pour se concentrer sur les dépendances dynamiques engendrées par la causalité. On peut ainsi s'affranchir par exemple des milliers d'opérations qui n'interfèrent pas avec les données qui nous intéressent. Enfin, elle s'avère également extrêmement précieuse pour simplifier la fusion des données situées dans des branches différentes et mieux identifier les véritables conflits.
Un cas particulier d'opération d'évolution concerne l'évolution du schéma qui consiste à faire évoluer la structure des données sans perte d'information
[Roddick93 - Publication « A taxonomy for schéma versioning based on the relational and entity relationship models »
Roddick, J.F., Craske, N.G. and Richards, T.J. 1993.]. De façon analogue aux données, le suivi de l'évolution de leur structure sera mieux assuré si le mécanisme de versionement de suivi des opérations et des traces causales s'applique également aux informations décrivant la structure. Des mesures particulières d'organisation des données et des metadonnées [Publication « Extracting delta for incrémental data warehouse maintenance » Ram P et al. Data Engineering, 2000.] seront nécessaires.
Un des objectifs de la présente invention est de proposer un procédé faiblement intrusif et progressif d'organisation d'une base de donnée numérique sous une forme traçable. Nous visons l'assurance des niveaux successifs de traçabilité décrits ci-dessus, sans pour autant imposer la refonte des applications existantes.
En d'autres termes, l'objectif poursuivi par l'invention est de fournir aux applications informatiques et à leurs utilisateurs la capacité de suivre de façon précise les données tout au long de leur évolution, en traçant leurs histoires de façon complète, aussi bien sur le plan individuel (versions intermédiaires et liens de succession) que sur le plan collectif (événements déclencheurs et liens d'interdépendance dynamiques issus des interactions entre les versions des données) , en la positionnant dans le cadre cohérent de son déroulement originel .
Il s'agit donc de fournir des liens de causalité à un niveau élémentaire où l'on puisse suivre aisément le flux causal des transformations et vérifier la validité de chaque opération intermédiaire sous la base des données d'entrée, du traitement appliqué et des données résultantes, de telle façon que la reconstitution de tout état du passé soit immédiate.
De plus, le procédé selon l'invention utilise un cadre architectural flexible, aussi peu contraignant et intrusif que possible afin de fournir une très large applicabilité au procédé proposé et une aussi large compatibilité que possible avec les procédés de stockage et manipulation des données courantes.
Afin d'assurer le suivi de l'évolution d'une base de données dite « principale », le procédé selon l'invention permet de faire en sorte qu'elle représente non pas seulement un mais tous les états cohérents successifs et/ou alternatifs nécessaires du monde réel représenté dans son évolution, tout en préservant les propriétés ACID.
Dans ce but, l'architecture mise en œuvre pour l'invention est illustrée figure 2 et est constituée comme suit : un journal (J) organisé sous la forme d'une « base de données interne d'historisation » constitué d'une table ou d'un ensemble de tables dédiées au suivi de l'évolution et basées sur un mode de stockage universel à schéma stable (indépendant de la représentation logique des données applicatives) et particulièrement adapté à la reconstitution à la volée des données. un moniteur de transactions (M) et d'événements capable de détecter toute demande d'évolution de valeurs et de structure transmise à la base de données qui rajoute au fur et à mesure dans le journal dédié des entrées caractérisant l'évolution élémentaire des données (identité, attribut, valeur, événement déclencheur et dépendances dynamiques) un module de reconstitution (R) à la volée de l'état de la base de données selon un événement cible ; le système est muni dans ce but d'un curseur (C) dédié à la sélection de l'état recherché. cas particulier : dans certains cas, il peut s'avérer utile de matérialiser la vue de la base dite « courante » ou « principale » sous la forme des tables de structure spécialisée, par exemple pour permettre des performances élevées et une compatibilité totale avec des applications existantes (notamment afin de permettre l'usage des procédures stockées et autres déclencheurs ou triggers qu'une application peut exiger pour fonctionner correctement) .
Optionnellement , l'architecture comprend également :
• un système de suivi de la conformité (SC) des applications avec les états de la base et de son schéma
• des outils d'inoculation (I) automatique dans les applications d' instructions dédiées au suivi des dépendances dynamiques (capture des flux de données)
Le journal (J) d'événements (ou la base de données interne d'historisation) est constitué principalement d'une table à structure indépendante de celle des données applicatives. Les colonnes sont :
• un identifiant unique de l'enregistrement de la table logique concerné par la ligne de journal, appartenant à la clé principale
• un identifiant de l'attribut dans le schéma, ou 0 pour l'enregistrement lui-même, appartenant à la clé principale
• un identifiant universel d'événement, incrémenté automatiquement, appartenant également à la clé principale du journal et correspondant à l'état de la base principale
• un champ valeur dédié au stockage des valeurs
Le rôle du moniteur (M) est de détecter et d'interpréter correctement chaque demande d'évolution en rajoutant l'information correspondante dans le journal d'événements (J) .
Exemples d' évolution de valeur
Commentaire
- insertion ID table d' enregistrement « client »
- mise à jour No du client d'un attribut
- mise à jour Nom du d'un attribut client
Figure imgf000023_0001
- suppression Code d'un suppression enregistrement
Figure imgf000023_0002
Dans le langage d'échange avec une base de données SQL, les trois premières lignes du tableau peuvent être l'effet de la requête suivante :
insert into Client (no_client, nom_client) values (1001, "aaa")
Une telle requête est traitée comme suit :
• analyse syntaxique (parsing) de la requête
• récupération depuis le schéma des identifiants pour la table client (53) ainsi que pour les attributs « no_client » (1) et « nom_client » (2)
• insertion des trois lignes dans le journal
La dernière ligne peut être obtenue par l'instruction suivante : delete' fro Client where No_client=1001
Une telle requête est traitée comme suit :
• analyse syntaxique (parsing) de la requête
• récupération depuis le schéma des identifiants pour la table client (53) ainsi que pour l'attribut « no_client » (1) .
• récupération de l'identifiant de l'enregistrement du journal ayant la valeur 1001 pour l'attribut no 1
• insertion dans le journal de la dernière ligne (en utilisant le code 0 pour la valeur) . Exemples d' évolution de schéma create table Client (no__client int primary key)
Création d'une Commentaire nouvelle table
ID table des tables
Nom de la table
Ajout d'un ID table attribut des attributs
Nom de l' attribut
Domaine
Clé primaire ID table
Figure imgf000025_0001
alter table Client drop column no_client Suppression Code d'un attribut suppression
Figure imgf000025_0002
drop table Client
Suppression Code d'une table suppression
Figure imgf000025_0003
Autres cas : Mise à jour déplacement ID table d' attribut
Figure imgf000025_0004
L'exemple décrit ci-dessus concerne un cas complexe, sans équivalence en une seule opération SQL. Un outil de gestion interactive peut en revanche permettre de tirer un réel bénéfice de cette caractéristique.
Comme on peut le remarquer, chaque événement qui tend à modifier la base de données logique finit par créer une ou plusieurs entrées sous la forme de nouvelles lignes (ou enregistrements) dans le journal. Ceci garantit que rien ne se perd et que toute suppression ou mise à jour logique ne se traduit pas en une suppression physique. Ainsi, les données du passé peuvent être récupérées. Un des avantages de cette organisation est la constitution concurrente de vues comme les livres de comptes qui bloquent généralement l'accès en mise à jour d'autres utilisateurs .
Remarquons également l'uniformité de la structure de stockage des informations : les données sont stockées en effet de façon identique, qu'il s'agisse de l'évolution des valeurs ou de celle des structures. Ceci veut dire que du point de vue logique, il est possible de reconstituer aussi bien les tables logiques que leurs structures, sur la base d'un même mécanisme. Par ailleurs, le fait d'inclure le journal dans la même base de données que la base principale permet de garantir sa cohérence relative de par le mécanisme transactionnel assuré par le SGBD.
Le module de reconstitution (R) a en charge justement la restitution en format logique des données en fonction d'un paramètre de type événement, à partir du journal d'événements (J) .
Par exemple, considérons que l'application souhaite obtenir les données de la table Client telle qu'elle était juste lors de l'événement 854. Cela implique au préalable la sélection de l'événement 854 par le curseur d'événements (C) . Par la suite, la requête "sélect * from Cl ient " est transmise au SGBD mais transformée par le module (R) en une requête plus complexe, obtenue de la façon suivante :
• reconstitution du schéma correspondant : la requête porte sur la table Client ; le système doit donc vérifier l'existence de la table Client au moment historique positionné par l'événement cible et récupérer les attributs de cette table logique ; (une optimisation est possible en gardant le schéma en cache)
• récupération des enregistrements dont le champ Attribut = 0 créés et non supprimés « avant » l'événement correspondant à l'état cible, (valeur = 0 pour le code de suppression) et attachés à cette table. Dans le cas des alternatives, « avant » ne concerne que les événements situés sur la même branche.
• récupération de tous les enregistrements dont le champ Attribut <> 0 attachés aux précédents et antérieurs à l'événement cible.
• réorganisation du flux de données restituées et regroupement par enregistrement logique, c'est-à-dire dans notre cas, par client.
Dans un mode de réalisation de l'invention, il est possible de faire des requêtes de modification sur des états passés de la base de données principale de façon à créer une arborescence des versions de la base de données traitée.
En plus des valeurs et des événements, le journal peut accueillir les invocations d'opérations. Cela peut être réalisé par la représentation des opérations sous la forme de tables logiques, où chaque opération correspond à un nom de table logique et chaque argument correspond à un attribut logique. En appliquant ce schéma de correspondance, l'application peut envoyer au journal (par exemple, par l'intermédiaire d'une API : « Application Programming Interface », interface de programmation d'applications) les informations nécessaires à la traçabilité des appels d'opération de façon analogue à la manipulation des données logiques (mais cette tâche peut être automatisée et confiée à un post-processeur, au compilateur, au processeur ou encore à la machine virtuelle) .
add (2, 8) Invocation de Commentaire l'opération Add avec les arguments 2 et 8
57 est ID opération l' identificateur « Add » de l'opération
« add »
Premier argument
62 est Second argument l' identificateur de cette invocation de l' opération
« add »
Valeur de retour
Figure imgf000028_0001
Les appels d'opération permettent de raccorder la sémantique des actions de l'application aux événements enregistrés dans le journal. Comme nous le verrons plus tard, cela facilitera le positionnement du curseur sur des repères significatifs du point de vue de l'utilisateur.
De surcroît, les points de validation des transactions peuvent être tracés sous la forme d'opérations. En effet, il est recommandé que le curseur se positionne exactement sur ces points et non pas entre deux opérations d'une même transaction. La cohérence du résultat en dépend. En revanche, des applications comme les outils d'aide à la conception peuvent très bien bénéficier des états intermédiaires, réputés incohérents, dans un but explicatif, et bénéficier ainsi de mécanismes de type « transactions longues ».
Précisons enfin que les opérations sont reliées par des références (non-représentées dans les tableaux) vers les opérations parentes de telle sorte que l'on puisse tracer également leur appartenance à l'exécution d'une opération de plus haut niveau. Ainsi, il sera possible de reconstituer l'appartenance des opérations, depuis le niveau élémentaire des événements et jusqu'au niveau des transactions, en passant par autant de niveaux d'invocation que nécessaire pour les applications.
L'invention concerne également la matérialisation des liens de causalité.
Le flux des dépendances causales doit être constitué dynamiquement par les opérations de lecture et mise à jour en respectant les règles suivantes :
La manipulation des données doit systématiquement considérer aux côtés des données lues leurs références d'origine et les transporter tout au long du flux de données et contrôle. L'application doit donc prendre en charge cet aspect, en ajoutant à chaque instruction de manipulation son équivalent de transport de références, par exemple par l'intermédiaire d'une API. L'automatisation de cette tâche peut être réalisée par un post-processeur et/ou par des extensions du processeur ou de la machine virtuelle.
Lors de l'insertion d'une donnée physique, les références du flux l'ayant alimentée doivent être stockées sous la forme d'une liste d'éléments de type ID-attribut- UEID, aux côtés de l'attribut valeur, et ceci pour chaque enregistrement physique du journal. Le tableau suivant en fait l'illustration. Une liste vide correspondrait à l'introduction d'une valeur de l'extérieur du système (par exemple, par la saisie effectuée par un utilisateur à travers une Interface-Homme-Machine) .
Commentaire
La valeur de 1 ' attribut 4 a été constituée à partir des attributs 2 et
3
Figure imgf000030_0001
L' implémentation des sources dans le journal peut très bien être réalisée par l'intermédiaire d'un journal additionnel (ou sous-table) , organisé de façon tabulaire, et ceci pour des raisons d'optimisation de performances, selon les techniques en vigueur dans la discipline des bases de données.
L'interprétation du flux se fait de manière simple : la valeur d'une donnée dépend des valeurs des données sources lues aux moments référencés par les événements UEID correspondants. On peut donc dire que les sources matérialisent les liens de causalité élémentaires.
L' invocation des opérations peut être tracée de la même manière. Voici à titre d'exemple, l'appel de l'opération Add (mentionnée précédemment) avec les arguments Client.Attr3 et la constante 7.
Commentaire
ID opération « add » Premier argument
Second argument Valeur de retour
Figure imgf000031_0001
Le contrôle de validité des opérations peut être effectué par rapport aux données en vigueur. Par exemple, si la valeur de l'attribut Attr3 du Client 110 change après l'exécution de l'opération « add », les résultats envoyés par celle-ci ne peuvent plus être considérés comme conformes. On dit qu'il y a « remise en cause ». Dans le cas d'une évolution sans alternatives, cela peut être vérifié grâce à une simple comparaison d'UEID entre les sources des arguments et les dernières valeurs des sources référencées .
Pour que cette information de traçabilité soit entièrement efficace pour l'utilisateur, il est utile de minimiser les constantes, c'est-à-dire les valeurs saisies « arbitrairement ». L'application doit ainsi privilégier des systèmes d'identification par liste de choix, par pointage, par glisser-déplacer, etc., ou par toute autre technique qui améliore à la fois l'ergonomie de l'application et qui permet implicitement l'assurance d'un suivi sans discontinuité du flux informationnel. En réalité, ces techniques d'identification sont largement répandues car elles assurent des avantages de référencement statique prévu dans les bases de données de façon courante.
Cette caractéristique du procédé permet de surcroît la mise en place d'un système d'optimisation automatique, qui - sur la base de la vérification systématique de la validité des sources - permet de renvoyer le résultat calculé précédemment, sans réexécuter effectivement l'opération. La mise en place d'une telle solution implique l'introduction des références vers les opérations appelantes (ce qui peut être fait à travers des arguments supplémentaires) et à condition que le temps de vérification soit inférieur à celui d'exécution (des statistiques de performances peuvent être maintenues à titre informatif et exploitées efficacement) .
La notification automatique des « remises en cause » pourra être mise en place sur la base des informations de validité des versions des données par rapport aux flux. Ainsi, pour une opération, une classe d'opération, une cible ou une source donnée, des alerteurs de cohérence de flux pourront notifier les applications par des messages synchrones ou asynchrones .
La ré-exécution consiste en une nouvelle invocation explicite d'une opération donnée sur le modèle d'une invocation précédente, mais sur la base de nouvelles valeurs. Dans tous les cas, elle donnera lieu à des nouvelles valeurs pour les données, les opérations et les sources tracées.
Le procédé selon l'invention est spécialement conçu pour gérer de façon opérationnelle l' historisation au fil de l'eau et la restauration à la volée. De plus, la gestion des volumes de stockage est facilitée et optimisée par un ensemble de facteurs :
• seules les valeurs attributs qui changent sont stockées (la redondance est ainsi minimisée)
• les volumes nécessaires de stockage supplémentaires augmentent de façon linéaire avec le nombre des attributs modifiés ou supprimés et ne dépendent pas des volumes de données insérés dans la base ; ce facteur autorise une utilisation très avantageuse pour un très large spectre d'applications. • enfin, les purges très pertinentes peuvent être opérées selon les données marquées comme remises en cause par les liens de traçabilité de type source-destination, mais cette opération doit être pilotée par les applications en fonction de la sémantique des remises en cause.
Pour des raisons de simplification du discours, dans l'exemple précédent, nous avons fait l'hypothèse implicite d'une organisation séquentielle des événements et donc des états de la base principale (selon un ordre total) . Ainsi, pour vérifier la validité d'une source, nous avons évoqué comme solution la comparaison simple des identifiants universels d'événement (UEID).
En réalité, notre procédé autorise un vaste choix d'organisation des versions, comme par exemple :
• Arborescence : chaque événement a un événement parent. La valeur d'une donnée associée à un événement peut être obtenue par une remontée logique des parents jusqu'à la valeur la plus proche. • Graphe orienté sans circuit : analogue à l'arborescence, cette organisation permet à une version d'avoir plusieurs parents différents. Les ambiguïtés de résolution peuvent être levées par des règles prédéfinies, basées sur des critères de priorité des branches ou sur tout autre caractéristique de la donnée (son type, etc.)
Les évolutions des branches différentes peuvent être fusionnées en faisant appel à la ré-exécution des opérations .
Les versions virtuelles sont des branches d'événements prédéfinies qui permettent la constitution de configurations parallèles pouvant bénéficier simultanément des événements appliqués à une ou plusieurs branches dites « de référence ». Autres caractéristiques :
• Les éventuels conflits sont évités par la séparation des événements par nature en branches de référence selon le modèle évoqué dans l'organisation de graphe orienté sans circuit.
• La matérialisation de ces configurations n'est pas réelle car les événements ne sont pas dupliqués physiquement (la propagation est logique) .
L'architecture mise en œuvre pour la réalisation de l'invention peut aussi comporter les modules suivants • un système de suivi de la conformité (SC) des applications avec les états de la base et de son schéma. Le principe est basé sur l'enregistrement d'un identifiant de version de l'application afin de déclarer un niveau de compatibilité avec le ou les états correspondants au schéma de la base principale
• des outils d'inoculation (I) automatique dans les applications d'instructions dédiées au suivi des dépendances dynamiques (capture des flux de données) : pré/post-processeur ou Machine virtuelle étendue
• des composants visuels spécialisés dans la navigation et l'exploration des états de la base (non- reprêsentés) .
L' invention peut être implémentée de plusieurs manières selon le contexte dans lequel elle est intégrée à une application.
La figure 3 présente une architecture qui autorise trois niveaux d'intégration de la traçabilité, de bas en haut :
Les applications existantes peuvent continuer à accéder à la base de données (dite « principale ») de la même manière. La base peut soit garder sa structure d'origine et rediriger les accès à un journal associé (dit base interne) , soit évoluer vers une organisation physique de type journal et offrir des vues ou un driver ayant en charge la translation des requêtes et des résultats. Les applications existantes pourront être très facilement munies d'un « curseur » à condition que l'accès aux données soit centralisé (ce qui est généralement le cas, par exemple à travers un driver unique) . Dans ce cas, l'application pourra offrir des moyens d'accès automatiques aux données de la base (implémentée désormais sous la forme d'un journal) et permettre aux utilisateurs d'actionner un curseur qui positionnera les lectures sur le repère événementiel désiré. Des légères adaptations pourront avoir lieu afin d'accorder la granularité des événements avec la sémantique de l'application.
Les nouvelles applications, entièrement construites sur la base des technologies d' inoculation de génération de traces bénéficieront implicitement du niveau le plus avancé de traçabilité offert par ce procédé comprenant le suivi exhaustif de l'évolution des données et de leur structure. Pour que le suivi de l'évolution des applications soit assuré au même niveau, il suffira de recourir à des techniques déclaratives de représentation des sources, de les confier au même journal et de les faire manipuler par un outil d'assemblage muni lui-même d'un module de traçabilité selon ce même procédé.
Cette architecture permet d'atteindre graduellement des niveaux de traçabilité des données persistantes de plus en plus élevées :
• initial : représentation et persistance (indispensable, préalable) , assuré par le système initial de persistance
• journalisation des événements (utile, reprise sur panne à court terme, mais pose un problème de reconstitution rapide des états passés)
• historisation et versionnement (utile, car les valeurs stockées sont multiples et peuvent comporter des variantes mais cette fonctionnalité génère des problèmes de reconstitution en mode compatible avec le mode initial)
• évolution structurelle : le suivi des évolutions des données et du schéma de la base de données principale, compatible avec le mode initial • dépendance causale : la détection des flux de dépendance dynamique et des liens de causalité entre les données de la base de données d'historisation (journalisée)
L'utilisation de branches offre la possibilité de créer des alternatives d'évolution de la base de données. Dans le même temps, cela lève des nouveaux problèmes quant à la traçabilité. En effet, supposant qu'après la séparation des branches A et B, la donnée X soit modifiée dans la branche A à travers l'opération 0. On peut alors souhaiter renvoyer sa nouvelle valeur dans la branche B, comme si elle avait eu cette valeur au moment de la séparation des branches. Cette opération, appelée rafraîchissement est très utile pour des nombreux cas où des données institutionnelles de référence sont reçues à des intervalles plus ou moins réguliers. Leur intégration peut poser alors des problèmes d' interférence avec les opérations effectuées entre temps. Par exemple, si aucune opération ayant eu comme source ou destination la donnée X dans la branche B n'a pas été effectuée entre temps, on peut sereinement considérer qu'il n'y a pas d'impact. En revanche, si c'est le cas, il faudra alors décider
(explicitement ou implicitement) quelle est l'opération qui est prioritaire et refaire les autres. Ces conflits sont aisément détectables grâce aux liens de dépendance dynamique. La sémantique associée sera apportée quant à elle par celle des opérations ayant provoqué ces dépendances. La simple comparaison de l'identifiant universel des traces d'opérations permet d'évaluer l'antériorité et de la confirmer ou de l'infirmer. L'utilisateur (ou l'application, à travers un système de règles prédéfinies) peut ainsi trancher en connaissance de cause. Le cas de la fusion de branches est tout à fait analogue . Précisons que cette technique est plus intéressante que le verrouillage anticipé d'une donnée, puisque, dans des nombreux cas, les opérations à venir ne sont pas prévisibles et leurs données cibles encore moins. La possibilité de créer des branches est d'ailleurs un moyen qui vise l'évitement au moins temporaire des conflits et qui permet de repousser à plus tard leur résolution.
Les branches virtuelles - qui sont par définition rafraîchies en permanence par leurs branches « parentes » - bénéficient automatiquement du rafraîchissement des données dans leurs branches parentes, y compris des opérations de débranchement (création de nouvelles branches) qui s'opèrent (virtuellement, bien entendu) en même temps sur les branches virtuelles. Par exemple, si la branche B est virtuelle, alors toute opération effectuée sur la branche A se répercute automatiquement sur la branche B. De plus, si l'on crée une nouvelle branche A2 à partir de A, celle-ci aura comme effet la création d'une sous-branche analogue B2 à partir de B. Il est important de souligner le caractère virtuel de ces rafraîchissements. Cela veut dire qu'en réalité aucun traitement n'est réellement effectué. Le seul effet réside dans le fait qu'une prochaine requête sur la branche B aura un résultat enrichi (qui tient compte des données rafraîchies) . Précisons enfin qu'en cas de propagation automatique, il n'y a pas de résolution automatique de conflit, sauf si des règles ont été prédéfinies. Dans certains cas, on peut décider à l'avance que, par défaut, ce qui a été modifié explicitement dans la branche virtuelle reste prioritaire par rapport aux données provenues par rafraîchissement.
La fusion de données complexes est un cas à la fois plus sophistiqué et plus réaliste puisque le plus souvent, le critère de décision majeur du choix de versions en vue de la résolution du conflit est le contexte. Considérons que la donnée X est une commande et que les données Yl et Y2 sont deux de ses lignes de commande. Si un nouveau tarif pour l'article Zl est proposé dans la branche « parente », puis propagé dans la branche en question, on doit alors décider si celui-ci remet en cause la valeur de la commande X, sachant que la ligne Yl fait référence justement à l'article Zl. La réponse sera donnée par la règle de gestion en vigueur pour les commandes. Une telle règle pourrait s'exprimer par exemple sous la forme suivante : « si la commande se trouve dans l'état payé, la commande reste intacte, autrement, mes mises à jours tarifaires s'appliquent aussitôt ». Précisons que cette règle n'a pas à tenir compte des notions de version, branche ou encore de trace causale, ce qui souligne une nouvelle fois le très faible niveau d'intrusion de notre procédé .
En conclusion, la disponibilité des traces causales permet de configurer de façon plus fine les différentes possibilités de fusion, tout en respectant scrupuleusement les processus et tout en apportant la preuve irréfutable de ce respect.
Le spectre des applications de l'invention couvre la plupart des cas où il est utile de suivre l'évolution des données persistantes, des applications de gestion et jusqu'aux systèmes de gestion de fichiers, en passant par des outils de conception reposant sur des référentiels (ou repository) , ou au-delà des besoins de persistance, pour peu que le suivi de l'évolution est utile . L' invention est décrite dans ce qui précède à titre d'exemple. Il est entendu que l'homme du métier est à même de réaliser différentes variantes de l'invention sans pour autant sortir du cadre du brevet.

Claims

REVENDICATIONS
1. Procédé d'organisation d'une base de données numériques sous une forme traçable, comportant des étapes de modification d'une base de données numériques principale par ajout ou suppression ou modification d'un enregistrement de la base principale et des étapes de lecture de la base de données principale, caractérisé en ce que l'étape de modification de la base de données principale comprend une opération de création d'au moins un enregistrement numérique comportant au moins : les identifiants numériques uniques des enregistrements et des attributs concernés de la base de données principale, un identifiant numérique unique de l'état de la base de données principale correspondant à ladite modification de la base de données principale, les valeurs élémentaires des attributs qui leur sont affectées à travers les opérations élémentaires, sans procéder au stockage des attributs ou des enregistrements non modifiés, et d'ajout dudit enregistrement dans une base d'historisation interne composée d'au moins une table, et en ce que l'étape de lecture portant sur tout état final ou antérieur de la base de données principale consiste à recevoir (ou intercepter) une requête originelle associée à l'identificateur unique de l'état visé, à procéder à une transformation de ladite requête originelle pour construire une requête modifiée d'adressage de la base d'historisation comprenant les critères de la requête originelle et l'identificateur de l'état visé, et de reconstruction du ou des enregistrements correspondant aux critères de la requête originelle et à l'état visé, ladite étape de reconstitution consistant à retrouver les valeurs élémentaires, contenues dans les enregistrements de la base d'historisation, correspondant aux critères de la requête originelle [afin de réduire les besoins de capacité de stockage et les temps de traitement] .
2. Procédé d'organisation d'une base de données numérique sous une forme traçable selon la revendication 1, caractérisé en ce que lesdits enregistrements de la base de données d'historisation contiennent également des références à d'autres enregistrements de la base de données interne, dans le but de préciser les liens de dépendance dynamique de type source-destination constituant le flux causal des interférences entre les versions des données
3. Procédé d'organisation d'une base de données numérique sous une forme traçable selon l'une quelconque des revendications précédentes, caractérisé en ce que ladite opération de modification de la base principale est une opération logique et que ladite opération d'ajout dans la base de données d'historisation consiste à ajouter : un enregistrement identifiant l'état de la base correspondant à l'opération logique, autant d'enregistrements que de paramètres de l'opération logique, un enregistrement pour le résultat éventuel de l'opération logique et à préciser par un lien de parenté les regroupements d'opérations depuis le niveau élémentaire de modification jusqu'au niveau de la transaction, en passant le nombre de niveaux sémantiques nécessaires pour les applications .
4. Procédé d'organisation d'une base de données numérique sous une forme traçable selon l'une quelconque des revendications précédentes, caractérisé en ce que la base de données principale contient une ou plusieurs table (s), organisant les liens d'évolution entre les identifiants des états successifs et alternatifs de la base principale, destinée (s) à organiser les enregistrements de la base de données interne .
5. Procédé d'organisation d'une base de données numérique sous une forme traçable selon la revendication 4, caractérisé en ce que ladite ou lesdites tables des liens d'évolution entre les états de la base principale contiennent des enregistrements spécifiant les règles de correspondance entre les enregistrements de la base de données interne d'historisation et les états de la base de données principale.
6. Procédé d'organisation d'une base de données numérique sous une forme traçable selon l'une des revendications 4 à 5, caractérisé en ce que ladite opération de lecture consiste à déterminer ledit état de la base de données principale en se référant aux dits identifiants et aux tables des liens d'évolution entre les états de la base principale.
7. Architecture de gestion de base de données utilisant le procédé d'interrogation de l'une quelconque des revendications précédentes, caractérisée en ce qu'une application interrogeant la base de données principale peut spécifier l'état de la base de données principale désiré.
8. Architecture de gestion de base de données selon la revendication 7, caractérisée en ce que ladite application peut opérer des modifications sur tout état de la base principale et donnant lieu, dans le cas de la tentative de modification d'un état antérieur, à la création de nouvelles alternatives d'évolution de la base de données principale dont les données seront générées par la même base d'historisation interne.
9. Procédé d'organisation d'une base de données numérique sous une forme traçable selon l'une quelconque des revendications 3 à 6, caractérisé en ce que les liens de dépendances servent de critères de remise en cause desdites opérations déjà effectuées.
10. Procédé d'organisation d'une base de données numérique sous une forme traçable selon l'une quelconque des revendications 3 à 6, caractérisé en ce que les mises à jour effectuées sur des branches différentes pourront être intégrées ou fusionnées dans le cadre d'un nouvel état « héritant » desdites branches.
11. Procédé d'organisation d'une base de données numérique sous une forme traçable selon l'une quelconque des revendications 3 à 6, caractérisé en ce que les cas d'évolution de structure des données de la base de données principale sont traités comme des cas particuliers d'évolution des données de ladite base, pour peu que la structure/schéma de ladite base principale soit décrite de la façon mentionnée pour les données, en tant que dictionnaire .
12. Procédé d'organisation d'une base de données numérique sous une forme traçable selon l'une quelconque des revendications 3 à 6, caractérisé en ce que la base de données d'historisation est explorée et interrogée par des applications à travers le mode natif du SGBD afin d'obtenir des informations comme par exemple toutes les valeurs historiques d'un attribut et toutes les incidences (dynamiques) de toute mise à jour et de naviguer au long des versions et des flux de dépendance dynamique et ceci de façon classique, selon le langage d'interrogation en vigueur, exigé par le SGBD.
PCT/FR2003/002675 2002-09-11 2003-09-09 Procede d'organisation d'une base de donnees numeriques sous une forme traçable WO2004025507A2 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
AU2003278287A AU2003278287A1 (en) 2002-09-11 2003-09-09 Method for organizing a digital database in a traceable form
EP03769596A EP1537497A2 (fr) 2002-09-11 2003-09-09 Procede d'organisation d'une base de donnees numeriques sous une forme tracable
US10/527,516 US20060123059A1 (en) 2002-09-11 2003-09-09 Method for organizing a digital database in a traceable form

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0211250A FR2844372B1 (fr) 2002-09-11 2002-09-11 Procede d'organisation d'une base de donnees numeriques sous une forme tracable
FR02/11250 2002-09-11

Publications (2)

Publication Number Publication Date
WO2004025507A2 true WO2004025507A2 (fr) 2004-03-25
WO2004025507A3 WO2004025507A3 (fr) 2004-05-06

Family

ID=31726006

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2003/002675 WO2004025507A2 (fr) 2002-09-11 2003-09-09 Procede d'organisation d'une base de donnees numeriques sous une forme traçable

Country Status (5)

Country Link
US (1) US20060123059A1 (fr)
EP (1) EP1537497A2 (fr)
AU (1) AU2003278287A1 (fr)
FR (1) FR2844372B1 (fr)
WO (1) WO2004025507A2 (fr)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080059949A1 (en) * 2006-09-01 2008-03-06 Sap Ag System and method for implementing a safe framework
US20080120309A1 (en) * 2006-11-17 2008-05-22 Microsoft Corporation Storing, maintaining and locating information
US7818292B2 (en) * 2007-04-05 2010-10-19 Anil Kumar Nori SQL change tracking layer
US10013277B2 (en) * 2009-05-29 2018-07-03 Red Hat, Inc. Rolling back state changes in distributed transactions
US9886490B1 (en) * 2014-03-17 2018-02-06 Numerify, Inc. Common extract store
CN105095457B (zh) * 2015-07-28 2019-08-09 驰众信息技术（上海）有限公司 历史数据存储管理方法
CN105677889A (zh) * 2016-01-30 2016-06-15 武汉大学 一种空间数据的局部更新、整体还原增量更新方法
CN108897794B (zh) * 2018-06-12 2020-11-27 东软集团股份有限公司 无主键数据表的同步方法、装置、存储介质和电子设备
CN109189783B (zh) * 2018-08-03 2023-10-03 北京涛思数据科技有限公司 一种时序数据库表结构改变处理方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1992013310A1 (fr) * 1991-01-23 1992-08-06 Tandem Telecommunications Systems, Inc. Procede de selection et de representation de donnees
EP0984369A2 (fr) * 1998-08-29 2000-03-08 International Computers Limited Mécanisme de stockage de versions datées de données
WO2002027561A2 (fr) * 2000-09-29 2002-04-04 Oracle Corporation Systeme et procede d'acces a une base de donnees temporaire a grain fin

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5347653A (en) * 1991-06-28 1994-09-13 Digital Equipment Corporation System for reconstructing prior versions of indexes using records indicating changes between successive versions of the indexes

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1992013310A1 (fr) * 1991-01-23 1992-08-06 Tandem Telecommunications Systems, Inc. Procede de selection et de representation de donnees
EP0984369A2 (fr) * 1998-08-29 2000-03-08 International Computers Limited Mécanisme de stockage de versions datées de données
WO2002027561A2 (fr) * 2000-09-29 2002-04-04 Oracle Corporation Systeme et procede d'acces a une base de donnees temporaire a grain fin

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
DAVIS J P ET AL: "EDICT-an enhanced relational data dictionary: architecture and example" DATA ENGINEERING, 1988. PROCEEDINGS. FOURTH INTERNATIONAL CONFERENCE ON LOS ANGELES, CA, USA 1-5 FEB. 1988, WASHINGTON, DC, USA,IEEE COMPUT. SOC. PR, US, 1 février 1988 (1988-02-01), pages 184-191, XP010011415 ISBN: 0-8186-0827-7 *
RAM P ET AL: "Extracting delta for incremental data warehouse maintenance" DATA ENGINEERING, 2000. PROCEEDINGS. 16TH INTERNATIONAL CONFERENCE ON SAN DIEGO, CA, USA 29 FEB.-3 MARCH 2000, LOS ALAMITOS, CA, USA,IEEE COMPUT. SOC, US, 29 février 2000 (2000-02-29), pages 220-229, XP010378715 ISBN: 0-7695-0506-6 *
SNODGRASS R: "THE TEMPORAL QUERY LANGUAGE TQUEL" ACM TRANSACTIONS ON DATABASE SYSTEMS, ASSOCIATION FOR COMPUTING MACHINERY. NEW YORK, US, vol. 12, no. 2, 1 juin 1987 (1987-06-01), pages 247-298, XP000718765 ISSN: 0362-5915 *

Also Published As

Publication number Publication date
WO2004025507A3 (fr) 2004-05-06
FR2844372A1 (fr) 2004-03-12
FR2844372B1 (fr) 2005-01-14
US20060123059A1 (en) 2006-06-08
AU2003278287A1 (en) 2004-04-30
EP1537497A2 (fr) 2005-06-08

Similar Documents

Publication Publication Date Title
US11188556B2 (en) Correlated incremental loading of multiple data sets for an interactive data prep application
US11061534B2 (en) Generating and applying data transformations in a data import engine
US8640086B2 (en) Graphical user interface system and method for presenting objects
FR2698977A1 (fr) Système d&#39;information multimédia.
FR2764719A1 (fr) Dispositif d&#39;analyse et d&#39;organisation de donnees
AU2019356745B2 (en) Correlated incremental loading of multiple data sets for an interactive data prep application
Haeusler et al. ChronoSphere: a graph-based EMF model repository for IT landscape models
WO2004025507A2 (fr) Procede d&#39;organisation d&#39;une base de donnees numeriques sous une forme traçable
Rooney et al. Kafka: the database inverted, but not garbled or compromised
Schönig Mastering PostgreSQL 12: Advanced techniques to build and administer scalable and reliable PostgreSQL database applications
Nielsen Microsoft Sql Server 2000 Bible (W/Cd)
WO2008043392A1 (fr) Procede pour traiter des informations
Schönig Mastering PostgreSQL 11: Expert techniques to build scalable, reliable, and fault-tolerant database applications
Pietri Organizing the graph of public software development for large-scale mining
Sarkar Learning Spark SQL
Rizzo et al. Pro SQL Server 2005
van der Lans Creating an agile data integration platform using data virtualization
Darmawan et al. Database Performance Tuning on AIX
Meurice Analyzing, understanding and supporting the evolution of dynamic and heterogeneous data-intensive software systems
HANSEN An accounting tool for inner source contributions
Hellman Study and Comparison of Data Lakehouse Systems
Grossmann et al. Data Provisioning
WO2010086523A1 (fr) Systeme informatique de gestion de donnees historisees dans un outil de gestion de versions
Dhiman An Approach to Solving Current and Future Data Warehousing Big Data Problems
FR2963124A1 (fr) Procede de gestion de donnees, dispositif, et produit programme d&#39;ordinateur correspondant.

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2003769596

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2006123059

Country of ref document: US

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 10527516

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 2003769596

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 10527516

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP