FR 2844372 A1 20040312 FR 0211250 A 20020911 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 10 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 15 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 20 prise en charge de la traçabilité dans les couches logicielles du marché à un niveau de granularité satisfaisant: OS, SGBD, langage de développement * Cot très élevé de récriture des applications existantes et cot très élevé de prise en compte explicite 25 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 30 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 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 10 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. 15 Cette contrainte implique un cot en temps important. 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 25 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 30 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 5 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 10 suivants: * prise en compte de l'évolution structurelle (évolution de schéma); * prise en compte de l'évolution des applications; 15 * 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 20 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 25 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 30 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 10 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 15 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 20 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 30 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 à effectuer une requête originelle associée à l'identificateur unique de l'état visé, à 5 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 10 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 15 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 20 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 25 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 30 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 5 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 15 données principale. Selon un mode de mise en oeuvre 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 20 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 25 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 30 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 oeuvre 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 10 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 15 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 20 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 25 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 30 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 10 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 15 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 20 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 25 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 30 (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. 5 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 Clé Attributl Attribut2 1001 " aaa " 23/12/2001 1002 (SQL par exemple). Le gestionnaire de persistance permet également 15 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 20 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 reconstitution des données sous forme tabulaire. Précisons enfin qu'une base de données 10 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 15 particulières dites ACID (Atomicité, Cohérence, Isolation et Durabilité) qui garantissent un certain niveau de qualité. L'objectif poursuivi par l'invention est de 20 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) 25 que sur le plan collectif (évènements déclencheurs et liens d'interdépendance dynamiques issus des interactions entre les versions 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 il 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 5 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 15 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 oeuvre pour l'invention est illustrée figure 2 et est constituée comme 20 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 à 25 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 30 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 "c courante " ou 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 - insertion d'enregistrement - mise à jour d'un attribut - mise à jour d'un attribut - suppression d'un enregistrement ID Attribut UEID Valeur 110 0 52 53 i 853 1001 2 854 Ilaaa"I 0 981 0 Commentaire ID table " client " No du client Nom du client Code suppression Dans le langage d'échange avec une base de 15 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 20 * analyse syntaxique (parsing) de la requete * récupération depuis le schéma des identifiants pour la table client (53) ainsi que pour les attributs " noclient " (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 O pour la valeur). Exemples d'évolution de schéma creat Création d'une nouvelle table Ajout d'un attribut e table Client (noclient int ID Attribut UEID Valeur 53 O 252 8 53 1 253 " Clien t " 54 0 254 9 54 1 255 " no-cl ient " 54 2 256 Int 54 3 257 PK 54 4 258 53 primary key) Commentaire ID table des tables Nom de la table ID table des attributs Nom de l'attribut Domaine Clé primaire ID table 2844372 15 alter té Suppression d'un attribut able Client drop column no-client Suppression d'une table Autres cas: déplacement d'attribut 54 O 278 0 drop table Client 53 1 0 293 0 i 54 i 3 308 22 Code suppression Code suppression Mise à jour ID table 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 15 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 20 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 25 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 10 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 15 au préalable la sélection de l'événement 854 par le curseur d'événements (C). Par la suite, la requête "select * from Client" 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 25 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 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 15 à 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 20 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 25 virtuelle). add (2, 8) Invocation de ID l'opération Add avec les arguments 2 et 8 57 est 62 l'identificateur de l'opération " add " Attribut UEID Valeur O 401 57 Commentaire ID opération " Add " 2844372 18 62 est l'identificateur de cette invocation de l'opération " add " 62 1 402 2 62 2 403 8 62 999 4 04 10 Premier argument Second argument Valeur de retour 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 5 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 10 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 15 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 (nonreprésentées dans les tableaux) vers les opérations parentes de telle sorte que l'on puisse 20 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 cetaspect, en ajoutant à chaque 15 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-attributUEID, aux côtés de l'attribut valeur, et ceci pour chaque 25 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). 30 ID Attribut UE Valeur Sources ID 2 54 "aaa" 1103 54 2... .... ........DTD: 4 75 "aaa2" ID Attribut UEID 3 il 2 543 o il 3 544 o Commentaire La valeur de l'attribut 4 a été constituée à partir des attributs 2 et 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 5 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 10 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 15 l'opération Add (mentionnée précédemment) avec les arguments Client.Attr3 et la constante 7. 2844372 21 ID Attribut UEID Valeur Sources 62 0 401 57 62 i 402 2 ID| Attribut UEID il 3 543 62 2 403 7 62 999 404 10 Commentaire ID opération 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 15 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 20 l'application et qui permet implicitement l'assurance d'un suivi sans discontinuité du flux de fabrication. En réalité, ces techniques 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. 25 Cette technique 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é 5 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 à 10 celui d'exécution (des statistiques de performances peuvent être maintenues à titre informatif et exploitées efficacement). La notification automatique des " remises en 15 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 20 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 25 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 30 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 5 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 de gestion. * enfin, les purges très pertinentes peuvent être 10 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 20 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 pareexemple: * Arborescence: chaque événement a un événement 25 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 30 d'avoir plusieurs parents différents. Les ambiguté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 5 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 10 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 15 physiquement (la propagation est logique). L'architecture mise en oeuvre 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 25 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) 30 pré/post-processeur ou Machine virtuelle étendue * des composants visuels spécialisés dans la navigation et l'exploration des états de la base (nonrepré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 10 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 20 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 25 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é 30 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 10 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 15 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 20 dépendance dynamique et des liens de causalité entre les données de la base de données d'historisation (journalisée) Le spectre des applications de l'invention couvre la plupart des cas o il est utile de suivre 25 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 audelà des besoins de persistance, pour peu que le suivi de l'évolution est 30 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 à 2 7 même de réaliser différentes variantes de l'invention sans pour autant sortir du cadre du brevet. REVENDICATIONS 1. Procédé d'organisation d'une base de données numériques sous une forme traçable, comportant des étapes 5 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 15 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 20 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 à effectuer une requête originelle associée à l'identificateur unique de l'état visé, à procéder à une transformation de ladite requête originelle 30 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 10 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 15 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 20 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 30 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 5 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 15 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 20 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 25 é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 30 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 5 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 10 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 15 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. 20 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 25 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 5 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.