WO2010086523A1 - Systeme informatique de gestion de donnees historisees dans un outil de gestion de versions - Google Patents

Systeme informatique de gestion de donnees historisees dans un outil de gestion de versions Download PDF

Info

Publication number
WO2010086523A1
WO2010086523A1 PCT/FR2010/000052 FR2010000052W WO2010086523A1 WO 2010086523 A1 WO2010086523 A1 WO 2010086523A1 FR 2010000052 W FR2010000052 W FR 2010000052W WO 2010086523 A1 WO2010086523 A1 WO 2010086523A1
Authority
WO
WIPO (PCT)
Prior art keywords
model
file
metadata
data
version
Prior art date
Application number
PCT/FR2010/000052
Other languages
English (en)
Inventor
Joris Thomassin
Original Assignee
Joris Thomassin
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 Joris Thomassin filed Critical Joris Thomassin
Publication of WO2010086523A1 publication Critical patent/WO2010086523A1/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
    • G06F16/219—Managing data history or versioning

Definitions

  • the present invention relates to a computer system for managing data stored and historized in a version management tool.
  • DBMS Database Management Systems
  • relational databases are used in which the data is structured into tables, each table having a number of fields.
  • the fields are of different types: Boolean, numeric, strings, etc.
  • Each table consists of a set of records, each record corresponding to a set of particular values of the fields in the table.
  • each table is conventionally represented by a two-dimensional matrix in which each column represents a field and each line a record.
  • the table usually provides an index field that has a unique value for each record.
  • a record of a table can then refer to a record from another table by including in a field a reference to the table and index of the referenced record.
  • Relational database software is developed by many companies. The best known are the ORACLE company
  • Relational databases are used to store and manage the most diverse business information: production management, business and financial data, personnel data, and so on.
  • log files are processed by search functions specific to the application when it becomes necessary to search for information about a modification.
  • the data is structured as a plurality of records called records, said records are structured according to a plurality of models such that a record is an instantiation of a template, and at least a first template has a relation to a second model, characterized in that each model comprises a structured set of metadata of a version manager.
  • Particular characteristics or embodiments are: • a file corresponding to a file generated in versions and historized for the version manager. • Each form has an empty file.
  • the automated method for managing historical data comprises the steps of:
  • each model comprising at least one field corresponding to a metadata of a version manager
  • At least one first model of the plurality of models comprises a link field to a second model such that a file instantiating the first model comprises in its corresponding metadata a pointer to a file instantiating the second model.
  • a computer program product includes program code instructions for performing the steps of the preceding method when said program is executed on a computer.
  • the historized data management system advantageously makes it possible to structure the data as in a conventional relational database while enjoying the advantages of the version management, which is the management of versions and their history, branch management in parallel, the storage of large amounts of information with fast response times, these features having already been well debugged by many uses earlier.
  • version management which is the management of versions and their history, branch management in parallel
  • storage of large amounts of information with fast response times these features having already been well debugged by many uses earlier.
  • FIGS. 1A and 1B are schematic views of software architectures using databases according to the prior art
  • FIG. 2 is a schematic view of a software architecture according to one embodiment of the invention
  • FIG. 3A is a schematic view of two database tables connected according to the prior art
  • FIG. 3B is a schematic view of connected plugs according to one embodiment of the invention.
  • FIG. 4 is a schematic view of the link between a "task” form and a "resource” form.
  • FIG. 5 is a schematic view of the display screens of the plugs of FIG. 4.
  • two conventional software architectures of a data management computer system 1 are represented: a software development architecture of FIG. application, FIG. 1A, and a software operating architecture of an application using a database, FIG. 1B.
  • They comprise a database management system 3 managing low-level storage structures on magnetic hard disk drives 5.
  • the database system 3 is, for example, one of the systems mentioned previously or an embedded system. such as Berkeley DB.
  • the application developer uses a development environment 7 known to those skilled in the art in the form of Integrated Development Environment EDI, or IDE for "Integrated Development Environment” in English.
  • EDI Integrated Development Environment
  • IDE Integrated Development Environment
  • the Eclipse software www.eclipse.org
  • This software groups together under a homogeneous graphical interface a certain number of tools software development such as, for example, a text editor with syntax highlighting, access to a compiler and a linker, a debugger, etc.
  • This EDI 7 interfaces with a Version Control System 9 or VCS.
  • Version Manager 9 is a tool typically used by software developers to manage their source files as part of an IT development project.
  • Repository to which the developers of the project have access. Before working, each developer typically makes a copy in a working folder of all or part of the files contained in the central repository in their latest version. He is working on this copy and, when finished, sends the modified files to the central repository for his fellow developers to use.
  • the version manager manages in particular the successive versions of the development files, that is to say that every time a developer makes a modification on a file, when the modified file is integrated in the central repository, the manager keeps the previous version and increments a version number at the same time as it stores the new file. Thus, in case of error, it is easy to return to an earlier version.
  • the version manager can also handle different concurrent changes to global versions of the software under development.
  • versioning software therefore manage a tree of files that are text or binary files containing the source code of the developed application. Each file is associated with one or more metadata containing information useful to the manager, for example, the name of the developer who has modified and deposited the file in the central repository.
  • the version manager 9 uses the database 3. This is a free or commercial database as indicated above or a database developed especially for the database manager. version 9.
  • a conventional data processing application 11 using a database notably comprises an interface 13 making it possible to manipulate the data stored in the database 3.
  • the interface 13 typically transforms SQL rules for computer objects such as words, strings, etc. in objects modeling the business data to be manipulated and vice versa.
  • FIG. 2 the application 11 'interfaces with a version manager 9' and not, as in the prior art of FIG. 1B, directly with a database.
  • the version manager 9 uses its traditional storage tools 3', generally a database, to store, read and write the data.
  • the data management application 11 'therefore uses the functionalities of the version manager 9' to store its data in the database 3 'underlying.
  • the interface 13 'then transforms the objects modeling the business data into computer objects that can be manipulated by the version manager 9 'and vice versa.
  • FIG. 3A represents a simple data structure such as can be represented in a conventional relational database.
  • This structure comprises two tables 110, 112 each having several fields including an index field 114, 116 in the first column.
  • Field 118 of table 110 contains pointers to records in table 112 as the content of the index of the pointed record.
  • the record 120 contains, for the field 118, a pointer 122 on one of the records of the table 112 as the content of the index of the pointed record.
  • This structure is performed in the interface 13 'using the metadata managed by the version manager 5', FIG. 3B.
  • a model 210, 212 corresponds to a type of file managed by the version manager 9 .
  • This model 210, 212 is instantiated through versioned files 214, 216, preferably of zero size with which metadata 218, 220 are associated with one metadata per field.
  • a table record such as record 120 of Figure 3A, that is, a set of data having the structure of the table in terms of number and quality of fields, is a copy of the template. 210 in which each metadata has a value specific to that record. In order to differentiate this copy from the model, it is called a form.
  • a model is an empty file associated with a metadata structure, these metadata having no defined value or a default value.
  • a form is an empty file associated with an identical structure of metadata, but each metadata contains a value specific to this form.
  • the records 120 initially stored in a table 110 of a conventional relational database are now stored as attributes 218 in an instance, or record, 222 of a template 210, that instance having an associated file 214 empty. From the functionalities of the version manager 9 ', it is understood that each form 222 is versioned: the history of changes of the different values of the attributes is managed directly by the version manager 9'.
  • the method for managing historized data thus consists in defining, step S230, at first, models in the form of a metadata structure, then, for each structured set of data, instantiating, step S232, a form corresponding to the model adapted for this dataset.
  • the manipulation of the data thus stored in the metadata of a file is carried out via the tools of the version manager.
  • the structures of a relational database are reproduced using a version manager.
  • This therefore advantageously allows classically structuring data, as in the context of a database development, while taking advantage of the native features of the version manager and, in particular, its ability to manage and version the history of the databases. changes.
  • the version manager in the use of the version manager as described the role and importance of the file and associated metadata are reversed from conventional use in software development as described with reference to FIG. 1A. .
  • the important element is the content of the file that contains part of the source code of the application being developed.
  • the metadata as their name suggests, are only present to qualify the file.
  • the metadata contains the useful information of the form and the contents of the file is empty or contains possibly text or unstructured data equivalent to a BLOB structure in a relational database.
  • a form is an object intended to record and track change requests.
  • practice shows that these cards are conventionally managed by the configuration management software using a database, as illustrated, for example, in Figure 1B. It will be understood that a plug in the sense of the embodiment described is much more versatile than a modification file in the sense of a configuration manager.
  • res_test representing the result of a past test, resource representing information about a person of the project,
  • CMMI complementary metal-oxide-semiconductor
  • ITIL Information Technology Infrastructure Library
  • - status status reflecting the level of progress of the task, for example in the context of a procedure.
  • - assigned resource defines the people in charge of the task.
  • the above attributes will be defined as strings, date, and so on.
  • FIG. 4 shows in the same representation as FIG. 3B the link between a "task” card 300 and a "resource” card 302.
  • the "assigned resource” attribute 304 contains a pointer under the "Resource” card 302 under the "resource” 302. form of the name of it.
  • FIG. 5 shows the screen for viewing and modifying a "task" sheet with the attributes above and that of the associated resource sheet.

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (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

L'invention concerne un système informatique de gestion de données historisées, les données étant structurées sous forme d'une pluralité d'enregistrements appelés fiches (222, 224), lesdites fiches étant structurées selon une pluralité de modèles (210, 212) telles qu'une fiche est une instanciation d'un modèle, et au moins un premier modèle comportant une relation à un second modèle (226), chaque modèle comportant un ensemble structuré de métadonnées (218, 220) d'un gestionnaire de versions.

Description

SYSTEME INFORMATIQUE DE GESTION DE DONNEES HISTORISEES DANS UN OUTIL DE GESTION DE VERSIONS
La présente invention concerne un système informatique de gestion de données stockées et historisées dans un outil de gestion de versions.
Dans les technologies de l'information, les techniques de bases de données, communément appelées Systèmes de Gestion de Base de Données ou SGBD, sont utilisées pour gérer de grande quantité de données structurées.
Dans la plupart des applications, on utilise des bases de données relationnelles dans lesquelles les données sont structurées en tables, chaque table comportant un certain nombre de champs. Les champs sont de différents types : booléens, numériques, chaînes de caractères, etc. Chaque table se compose d'un ensemble d'enregistrements, chaque enregistrement correspondant à un ensemble de valeurs particulières des champs de la table.
Ainsi chaque table est classiquement représentée par une matrice à deux dimensions dans laquelle chaque colonne représente un champ et chaque ligne un enregistrement.
Pour accéder aisément à un enregistrement, la table prévoit en général un champ d'index qui a une valeur unique à chaque enregistrement.
Un enregistrement d'une table peut alors faire référence à un enregistrement d'une autre table en incluant dans un champ une référence à la table et à l'index de l'enregistrement référencé.
Un langage spécifique de gestion des données dans une base de données relationnelle a été développé et normalisé sous le nom SQL (« Structured Query Language » - langage de requête structurée). Le standard est référencé ISO/CEI 9075.
La théorie et la pratique des bases de données relationnelles font partie des connaissances générales des étudiants en informatique et ne seront donc pas présentées plus en détail dans le présent document.
Les logiciels de bases de données relationnelles sont développés par de nombreuses sociétés. Les plus connues sont la société ORACLE
Corporation dont le système de gestion de bases de données se nomme Oracle, MICROSOFT Corporation avec SQL Server et SUN Corporation avec MySqI, cette liste n'étant pas limitative.
Les bases de données relationnelles sont utilisées pour stocker et gérer les informations les plus diverses des entreprises : la gestion de la production, les données commerciales et financières, les données du personnel, etc.
Dans de nombreuses applications, il existe un besoin d'enregistrer l'historique des modifications apportées à un enregistrement. Par exemple, dans une application de carnet d'adresses, il pourrait être souhaitable, lorsqu'un correspondant change d'adresse, de garder l'ancienne adresse ainsi que des informations sur le changement tel que la date du changement et la personne qui a effectué la modification. Ce type de suivi des modifications devient vite complexe à gérer et nécessite de nombreuses ressources de développement car les systèmes de gestion de bases de données n'ont pas de fonctions natives pour gérer aisément le suivi des modifications.
Lorsque le suivi de modifications est mis en œuvre, celui-ci est géré par les applications elles-mêmes, le plus souvent sous forme de fichiers enregistrant au fil de l'eau les modifications effectuées. Ces fichiers, appelés « fichiers log », sont traités par des fonctions de recherche particulières à l'application quand il devient nécessaire de rechercher des informations sur une modification.
Bien que relativement simple à mettre en œuvre, cette technique ne donne pas de résultat satisfaisant quand les besoins de recherche historique sont permanents car les « fichiers log » deviennent lourds à manipuler et les temps de réponse médiocres. Une amélioration de la technique des « fichiers de log » consiste à stocker les informations dans des « tables historiques ». Cette technique améliore en partie les temps de réponse sans que les résultats soient très satisfaisants.
Aussi serait-il particulièrement avantageux d'avoir un système informatique de gestion de données dans lequel la gestion des modifications et des historiques soit aisée à mettre en œuvre tout en gardant la versatilité des gestionnaires de bases de données classiques.
Pour résoudre un ou plusieurs des inconvénients cités précédemment, le système informatique de gestion de données historisées, les données sont structurées sous forme d'une pluralité d'enregistrements appelés fiches, lesdites fiches sont structurées selon une pluralité de modèles de telle sorte qu'une fiche est une instanciation d'un modèle, et au moins un premier modèle comporte une relation à un second modèle, caractérisé en ce que chaque modèle comporte un ensemble structuré de métadonnées d'un gestionnaire de versions.
Des caractéristiques ou des modes de réalisation particuliers sont : • une fiche correspondant à un fichier généré en versions et historisé pour le gestionnaire de versions. • chaque fiche comporte un fichier vide.
Selon un deuxième mode de réalisation, le procédé automatisé de gestion de données historisées comporte les étapes de :
- définition d'une pluralité de modèles, chaque modèle comportant au moins un champ correspondant à une métadonnée d'un gestionnaire de versions ;
- instanciation d'au moins un modèle sous forme d'un fichier géré en version et historisé par le gestionnaire de versions, la structure des métadonnées associées à ce fichier étant une copie de la structure de métadonnées du modèle correspondant et au moins une métadonnée associée audit fichier comportant une donnée à gérer en historique, le fichier et ses métadonnées étant appelée fiche.
Des caractéristiques et modes particuliers de réalisation sont :
- au moins un premier modèle de la pluralité de modèles comporte un champ de lien vers un second modèle de telle sorte qu'une fiche instanciant le premier modèle comporte dans sa métadonnée correspondante un pointeur vers une fiche instanciant le second modèle.
- le pointeur est l'adresse de la fiche instanciant le second modèle. Selon un troisième mode de réalisation, un produit programme d'ordinateur comporte des instructions de code de programme pour l'exécution des étapes du procédé précédent lorsque ledit programme est exécuté sur un ordinateur.
Ainsi, le système de gestion de données historisées permet avantageusement de structurer les données comme dans une base de données relationnelle classique tout en profitant des avantages du gestionnaire de versions que sont la gestion des versions et des historiques de celles-ci, la gestion de branche en parallèle, le stockage de grande quantité d'information avec des temps de réponse rapides, ces fonctionnalités ayant déjà été bien déboguées par de nombreux usages antérieurs. L'invention sera mieux comprise à la lecture de la description qui suit, faite uniquement à titre d'exemple, et en référence aux figures en annexe dans lesquelles :
- les figures 1A et 1B sont des vues schématiques d'architectures logicielles utilisant des bases de données selon l'art antérieur ; - la figure 2 est une vue schématique d'une architecture logicielle selon un mode de réalisation de l'invention ;
- la figure 3A est une vue schématique de deux tables de base de données reliées selon l'art antérieur ;
- la figure 3B est une vue schématique de fiches reliées selon un mode de réalisation de l'invention ;
- la figure 4 est une vue schématique de lien entre une fiche « tâche » et une fiche « ressource » ; et
- la figure 5 est une vue schématique des écrans de visualisation des fiches de la figure 4. En référence aux figures 1A et 1B, deux architectures logicielles classiques d'un système informatique 1 de gestion de données sont représentées : une architecture logicielle de développement d'application, figure 1A, et une architecture logicielle de fonctionnement d'une application utilisant une base de données, figure 1B. Elles comportent un système de gestion de bases de données 3 gérant des structures de stockage de bas niveau sur des disques durs magnétiques 5. Le système de bases de données 3 est, par exemple, un des systèmes cités en exemple précédemment ou bien un système embarqué tel que Berkeley DB.
Dans le cadre d'une architecture de développement, le développeur d'application utilise un environnement de développement 7 connu de l'homme du métier sous la forme d'Environnement de Développement Intégré EDI, ou IDE pour « Integrated Development Environment » en anglais. A titre d'exemple le logiciel Eclipse (www.eclipse.org) est un tel EDI. Ce logiciel regroupe sous une interface graphique homogène un certain nombre d'outils de développement de logiciel tels que, par exemple, un éditeur de texte avec coloration syntaxique, un accès à un compilateur et un éditeur de liens, un débogueur, etc.
Cet EDI 7 s'interface avec un gestionnaire de versions 9, appelé en anglais « Version Control System » ou VCS.
Le gestionnaire de versions 9 est un outil généralement utilisé par les développeurs de logiciel pour gérer leurs fichiers source dans le cadre d'un projet de développement informatique.
Dans le cadre d'un développement de logiciel, le principe général consiste à préparer une base centrale dite reposoir central (en anglais
« repository ») à laquelle ont accès les développeurs du projet. Avant de travailler, chaque développeur fait classiquement une copie dans un dossier de travail de la totalité ou d'une partie des fichiers contenus dans le reposoir central dans leur dernière version. Il travaille sur cette copie et, quand il a terminé, il envoie les fichiers modifiés dans le reposoir central pour que ses collègues développeurs puissent les utiliser.
Le gestionnaire de versions gère en particulier les versions successives des fichiers de développement, c'est-à-dire que chaque fois qu'un développeur fait une modification sur un fichier, lorsque le fichier modifié est intégré dans le reposoir central, le gestionnaire garde la version précédente et incrémente un numéro de version en même temps qu'il stocke le nouveau fichier. Ainsi, en cas d'erreur, il est facile de revenir sur une version antérieure.
Le gestionnaire de versions permet également de gérer différentes modifications simultanées de versions globales du logiciel en développement.
Par exemple, une modification d'une version stable de production dans laquelle seules des corrections d'erreur sont apportées et une version de développement dans laquelle sont implémentées de nouvelles fonctionnalités.
L'homme du métier appelle ces fonctionnalités la gestion des branches ou d'espaces de travail.
Il est également possible de mémoriser des états stables de version globale au travers de « photos » (en anglais « baseline », « label » ou « tag ») permettant de garder une vue globale de l'état de développement d'un logiciel à un moment donné. De nombreux logiciels de gestion de version existent actuellement. Parmi les plus connus, on peut citer CVS et Subversion qui sont des logiciels libres et Synergy, Dimensions et Perforce qui sont des logiciels commerciaux. Certains de ces logiciels gèrent également les demandes de modification du système à faire évoluer ainsi que la mise en correspondance de ces demandes de modification avec les changements apportés au système. L'homme du métier les appelle alors des logiciels de gestion de configuration (en anglais « Software Configuration Management » ou SCM).
Typiquement les logiciels de gestion de versions gèrent donc une arborescence de fichiers qui sont des fichiers de texte ou binaire contenant le code source de l'application développée. A chaque fichier est associé une ou plusieurs métadonnées contenant des informations utiles au gestionnaire comme, par exemple, le nom du développeur ayant modifié et déposé le fichier dans le reposoir central. Pour stocker l'ensemble de ces informations, fichiers et métadonnées, le gestionnaire de versions 9 utilise la base de données 3. Celle-ci est une base de données libres ou commerciales comme indiquée précédemment ou une base de données développée spécialement pour le gestionnaire de version 9. En fonctionnement, figure 1 B, une application 11 de traitement de données classique utilisant une base de données comporte en particulier une interface 13 permettant de manipuler les données stockées dans la base de données 3. Dans une logique de programmation objet, l'interface 13 transforme typiquement des règles SQL portant sur des objets informatiques de type mots, chaînes de caractères, etc. en objets modélisant les données métier à manipuler et réciproquement.
Dans un mode de réalisation de l'invention, figure 2, l'application 11' s'interface à un gestionnaire de version 9' et non, comme dans l'art antérieur de la figure 1 B, directement à une base de données. Le gestionnaire de versions 9' utilise ses outils classiques de stockage 3', en général une base de données, pour stocker, lire et écrire les données.
L'application 11 ' de gestion de données utilise donc les fonctionnalités du gestionnaire de versions 9' pour stocker ses données dans la base de données 3' sous-jacentes. L'interface 13' transforme alors les objets modélisant les données métier en objets informatiques manipulables par le gestionnaire de versions 9' et réciproquement.
L'organisation des données gérée par l'interface 13' va maintenant être décrite en référence aux figures 3A et 3B. Cette organisation a pour but de recréer les structures connues des bases de données relationnelles pour permettre les manipulations habituelles et connues des données.
A titre illustratif, la figure 3A représente une structure simple de données telle que pouvant être représentée dans une base de données relationnelle classique. Cette structure comporte deux tables 110, 112 comportant chacune plusieurs champs dont un champ d'index 114, 116 en première colonne. Le champ 118 de la table 110 contient des pointeurs sur des enregistrements de la table 112 sous la forme du contenu de l'index de l'enregistrement pointé. Ainsi, par exemple, l'enregistrement 120 contient, pour le champ 118, un pointeur 122 sur un des enregistrements de la table 112 sous la forme du contenu de l'index de l'enregistrement pointé.
Cette structure est réalisée dans l'interface 13' en utilisant les métadonnées gérées par le gestionnaire de version 5', figure 3B.
La structure d'une table, c'est-à-dire principalement le nombre et la qualité des champs, est décrite dans un modèle 210, 212. Ce modèle 210, 212 correspond à un type de fichier géré par le gestionnaire de versions 9'. Ce modèle 210, 212 est instancié au travers de fichiers versionnés 214, 216, de préférence de taille nulle auquel sont associés des métadonnées 218, 220 à raison d'une métadonnée par champ. Ainsi, un enregistrement de table, tel que l'enregistrement 120 de la figure 3A, c'est-à-dire un ensemble de données ayant la structure de la table en termes de nombre et de qualité de champs, est une copie du modèle 210 dans laquelle chaque métadonnée a une valeur spécifique à cet enregistrement. Afin de différencier cette copie du modèle, celle-ci est appelée fiche. On comprend donc qu'un modèle est un fichier vide associé à une structure de métadonnées, ces métadonnées n'ayant pas de valeur définie ou bien une valeur par défaut. Et une fiche est un fichier vide associé à une structure identique de métadonnées mais donc chaque métadonnée contient une valeur spécifique à cette fiche. Ainsi, les enregistrements 120 initialement stockés dans une table 110 d'une base de données relationnelle classique sont maintenant stockés sous la forme d'attributs 218 dans une instance, ou fiche, 222 d'un modèle 210, cette instance ayant un fichier associé 214 vide. De par les fonctionnalités du gestionnaire de versions 9', on comprend que chaque fiche 222 est versionnée : l'historique des changements des différentes valeurs des attributs est géré directement par le gestionnaire de versions 9'.
Pour réaliser un lien entre deux fiches, par exemple le lien 122 de la figure 3A, il suffit alors de prévoir dans un modèle une métadonnée 226 qui contiendra, lors de l'instanciation, l'adresse ou l'identifiant de la fiche pointée 224.
Le procédé de gestion de données historisées consiste donc à définir, étape S230, dans un premier temps des modèles sous forme d'une structure de métadonnées puis, pour chaque ensemble structuré de données, instancier, étape S232, une fiche correspondant au modèle adaptée pour cet ensemble de données. La manipulation des données ainsi stockées dans les métadonnées d'une fiche étant réalisée par l'intermédiaire des outils du gestionnaire de versions.
Ainsi, les structures d'une base de données relationnelle sont reproduites en utilisant un gestionnaire de versions. Cela permet donc avantageusement de structurer classiquement les données, comme dans le cadre d'un développement de bases de données, tout en profitant des fonctionnalités natives du gestionnaire de versions et, en particulier, de sa capacité à gérer et à versionner l'historique des modifications. On peut comprendre que dans l'utilisation du gestionnaire de versions telle que décrit le rôle et l'importance du fichier et des métadonnées associées sont inversés par rapport à une utilisation classique lors d'un développement de logiciel comme décrit en référence à la figure 1A. Dans une utilisation classique, l'élément important est le contenu du fichier qui contient une partie du code source de l'application en cours de développement. Les métadonnées, comme leur nom l'indique, sont seulement présentes pour qualifier le fichier. Dans l'utilisation décrite ici, les métadonnées contiennent l'information utile de la fiche et le contenu du fichier est vide ou contient éventuellement des données de type texte ou non structurées équivalentes à une structure BLOB dans une base de données relationnelle.
Les différents types de fichier pouvant être gérés par un outil de gestion de versions sont appelés par l'homme du métier « éléments de configuration » (en anglais « Configuration Items » ou Cl). Ces entités représentent la partie atomique la plus fine pouvant être gérée dans un système de gestion de versions, ou même un système de gestion de configuration. Ces éléments sont aujourd'hui limités à des types de fichier source (comme les *.c, *.h, *.java, etc. et les produits de compilation comme les *.exe, *.dll, etc.). L'utilisation des modèles et fiches telle que présentée ci- dessus complète cette liste avec des objets de type « fiche » au sens des gestionnaires de configuration dont chaque type a ses métadonnées propres. Il faut en effet distinguer la notion de fiche telle qu'expliquée ci-dessus en relation avec les figures 3A et 3B de la notion de fiche telle qu'elle est utilisée dans les gestionnaires de configuration. En effet, dans un gestionnaire de configuration, une fiche est un objet destiné à noter et suivre les demandes de modification. La pratique montre que ces fiches sont gérées classiquement par les logiciels de gestion de configuration en utilisant une base de données, comme illustré, par exemple, sur la figure 1B. On comprend qu'une fiche au sens du mode de réalisation décrit est beaucoup plus versatile qu'une fiche de modification au sens d'un gestionnaire de configuration.
A titre illustratif de cette versatilité du système décrit, les bases d'un gestionnaire intégré de données pour une direction des systèmes d'information d'une entreprise vont maintenant être décrites.
Un tel gestionnaire doit modéliser différents objets tels que :
- avenant représentant une demande de modification d'un périmètre projet,
- compétence représentant une description de connaissance et savoir-faire,
- décision représentant une décision actée par des décideurs sur un projet,
- environnement représentant la description d'un environnement d'une machine, - exigence représentant la description d'une exigence sur un produit,
- test représentant la description d'un test à passer pour vérifier une exigence,
- res_test représentant le résultat d'un test passé, - ressource représentant des informations sur une personne du projet,
- incident représentant la description d'un incident et de sa résolution,
- news représentant un événement marquant ayant eu lieu sur un projet,
- projet représentant la description des informations relatives à un projet,
- risque représentant la description d'un risque et des actions associées,
- tâche représentant l'ensemble des actions à réaliser pour accomplir la tâche, - etc.
Cette modélisation se base avantageusement sur des modélisations bien connues de l'homme du métier telles que CMMI (acronyme de « Capability Maturity Model Intégration » ou Intégration de modèle de mûrissement) pour le développement de logiciels et ITIL (« Information Technology Infrastructure Library » ou Bibliothèque d'infrastructures de technologie de l'information) pour la gestion de systèmes informatiques. Par une homogénéisation du vocabulaire et des concepts de ces modèles particuliers, elle permet de modéliser l'ensemble des activités d'une direction informatique. A titre d'exemple, le modèle de « tâche » définit les attributs suivants :
- identifiant : descripteur unique de référence de la tâche,
- titre : description synthétique de la tâche,
- description : description complète de la tâche,
- réalisation : description de ce qui a été effectivement réalisé, - date_début : date de début de réalisation de la tâche,
- date_fin : date de fin de la tâche,
- charge_prévue : charge prévue pour réaliser la tâche,
- charge_consommée : charge effectivement consommée par la tâche, - reste_à_faire : reste à faire sur la tâche,
- statut : état reflétant le niveau d'avancement de la tâche, par exemple dans le cadre d'une procédure.
- ressource assignée : définie les personnes en charge de la tâche. Selon le gestionnaire de versions utilisé et en particulier des types de données supportés comme attribut, les attributs ci-dessus seront définis comme chaînes de caractères, date, etc.
Par exemple, avec le gestionnaire de versions Dimension, les attributs « Titre », « Description », « Réalisation », seront de type « Char », les attributs « date-début » et « date-fin », seront de type « Date » et les attributs concernant la charge de travail de type « Number ».
L'attribut « ressource assignée » jointe sur une ou des fiche(s) ressource contenant la description de celle-ci.
La figure 4 montre sous la même représentation que la figure 3B, le lien entre une fiche « tâche » 300 et une fiche « ressource » 302. L'attribut « Ressource assignée » 304 contient un pointeur sous la fiche « Ressource » 302 sous la forme du nom de celle-ci.
A titre illustratif, la figure 5 montre l'écran de visualisation et de modification d'une fiche « tâche » avec les attributs ci-dessus et celui de la fiche ressource associée.
A partir de cette description, l'homme du métier saura reproduire toutes les liaisons entre tables classiques des bases de données relationnelles telles que les liaisons « un-plusieurs » et « plusieurs-plusieurs ».
On constate ainsi qu'il est possible d'offrir les mêmes capacités d'enregistrement et de manipulation que pour des données stockées classiquement dans une base de données relationnelle.
L'invention a été illustrée et décrite en détail dans les dessins et la description précédente. Celle-ci doit être considérée comme illustrative et donnée à titre d'exemple et non comme limitant l'invention a cette seule description. De nombreuses variantes de réalisation sont possibles.
Dans les revendications, le mot « comprenant » n'exclue pas d'autres éléments et l'article indéfini « un/une » n'exclue pas une pluralité.

Claims

REVENDICATIONS
1. Système informatique de gestion de données historisées, les données étant structurées sous forme d'une pluralité d'enregistrements appelés fiches (222, 224), lesdites fiches étant structurées selon une pluralité de modèles
(210, 212) de telle sorte qu'une fiche est une instanciation d'un modèle, et au moins un premier modèle comportant une relation à un second modèle
(226), caractérisé en ce que chaque modèle comporte un ensemble structuré de métadonnées (218, 220) d'un gestionnaire de versions (9'), d'une arborescence de fichiers, chaque fichier étant associé à une ou plusieurs métadonnées.
2. Système selon la revendication 1 , caractérisé en ce qu'une fiche correspond à un fichier géré en versions et historisé par le gestionnaire de versions.
3. Système selon la revendication 1 , caractérisé en ce que la relation avec le second modèle est une métadonnée de telle sorte que, pour toute fiche instanciant ledit premier modèle, la valeur de la métadonnée est un pointeur vers une fiche instanciant le second modèle.
4. Système selon la revendication 1 ou 2, caractérisé en ce que chaque fiche comporte un fichier vide.
5. Procédé automatisé de gestion de données historisées comportant les étapes de :
- définition (S230) d'une pluralité de modèles, chaque modèle comportant au moins un champ correspondant à une métadonnée d'un gestionnaire de versions d'une arborescence de fichiers, chaque fichier étant associé à une ou plusieurs métadonnées ;
- instanciation (S232) d'au moins un modèle sous forme d'un fichier géré en version et historisé par le gestionnaire de versions, la structure des métadonnées associées à ce fichier étant une copie de la structure de métadonnées du modèle correspondant et au moins une métadonnée associée audit fichier comportant une donnée à gérer en historique, le fichier et ses métadonnées étant appelée fiche.
6. Procédé selon la revendication 5, caractérisé en ce qu'au moins un premier modèle de la pluralité de modèles comporte un champ de lien vers un second modèle de telle sorte qu'une fiche instanciant le premier modèle comporte dans sa métadonnée correspondante un pointeur vers une fiche instanciant le second modèle.
7. Procédé selon la revendication 6, caractérisé en ce que le pointeur est l'adresse de la fiche instanciant le second modèle.
8. Produit programme d'ordinateur comportant des instructions de code de programme pour l'exécution des étapes du procédé selon l'une quelconque des revendication 5 à 7 lorsque ledit programme est exécuté sur un ordinateur.
PCT/FR2010/000052 2009-01-29 2010-01-20 Systeme informatique de gestion de donnees historisees dans un outil de gestion de versions WO2010086523A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0950564 2009-01-29
FR0950564A FR2941550B1 (fr) 2009-01-29 2009-01-29 Systeme informatique de gestion de donnees historiseees dans un outil de gestion de versions

Publications (1)

Publication Number Publication Date
WO2010086523A1 true WO2010086523A1 (fr) 2010-08-05

Family

ID=40792603

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2010/000052 WO2010086523A1 (fr) 2009-01-29 2010-01-20 Systeme informatique de gestion de donnees historisees dans un outil de gestion de versions

Country Status (2)

Country Link
FR (1) FR2941550B1 (fr)
WO (1) WO2010086523A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040210607A1 (en) * 2003-04-17 2004-10-21 Oracle International Corporation Metamodel-based metadata change management

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040210607A1 (en) * 2003-04-17 2004-10-21 Oracle International Corporation Metamodel-based metadata change management

Non-Patent Citations (7)

* Cited by examiner, † Cited by third party
Title
CAREY M ET AL: "O-O, What Have They Done to DB2?", PROCEEDINGS OF THE INTERNATIONAL CONFERENCE ON VERY LARGEDATA BASES, 1 January 1999 (1999-01-01), XP002304516 *
DE CASTRO C ET AL: "Schema versioning for multitemporal relational databases", INFORMATION SYSTEMS ELSEVIER UK, vol. 22, no. 5, July 1997 (1997-07-01), pages 249 - 290, XP002535452, ISSN: 0306-4379 *
HAN-CHIEH WEI ET AL: "PMTV: a schema versioning approach for bi-temporal databases", PROCEEDINGS SEVENTH INTERNATIONAL WORKSHOP ON TEMPORAL REPRESENTATION AND REASONING. TIME 2000 IEEE COMPUT. SOC LOS ALAMITOS, CA, USA, 2000, pages 143 - 151, XP002535453, ISBN: 0-7695-0756-5 *
MELTON J ET AL: "SQL and management of external data", SIGMOD RECORD, ACM, NEW YORK, NY, US, vol. 30, no. 1, 1 March 2001 (2001-03-01), pages 70 - 77, XP002492859, ISSN: 0163-5808 *
PEREIRA MOREIRA V ET AL: "Schema versioning: queries to the generalized temporal database system", DATABASE AND EXPERT SYSTEMS APPLICATIONS, 1999. PROCEEDINGS. TENTH INT ERNATIONAL WORKSHOP ON FLORENCE, ITALY 1-3 SEPT. 1999, LOS ALAMITOS, CA, USA,IEEE COMPUT. SOC, US, 1 September 1999 (1999-09-01), pages 458 - 459, XP010352402, ISBN: 978-0-7695-0281-6 *
ROBERT WREMBEL ET AL: "Managing and Querying Versions of Multiversion Data Warehouse", ADVANCES IN DATABASE TECHNOLOGY - EDBT 2006 LECTURE NOTES IN COMPUTER SCIENCE;;LNCS, SPRINGER, BERLIN, DE, vol. 3896, 1 January 2006 (2006-01-01), pages 1121 - 1124, XP019029251, ISBN: 978-3-540-32960-2 *
RODDICK J F: "A SURVEY OF SCHEMA VERSIONING ISSUES FOR DATABASE SYSTEMS", INFORMATION AND SOFTWARE TECHNOLOGY, ELSEVIER, AMSTERDAM, NL, vol. 37, no. 7, 1 July 1995 (1995-07-01), pages 383 - 393, XP000881233, ISSN: 0950-5849 *

Also Published As

Publication number Publication date
FR2941550B1 (fr) 2017-12-22
FR2941550A1 (fr) 2010-07-30

Similar Documents

Publication Publication Date Title
Bouman et al. Pentaho solutions
US8972872B2 (en) Building computing applications based upon metadata
US7681185B2 (en) Template-driven approach to extract, transform, and/or load
US8407235B2 (en) Exposing and using metadata and meta-metadata
EP2297681A1 (fr) Procede de gestion de donnees pour atelier oriente service collaboratif
Laurent et al. Data lakes
Weisinger Alfresco 3 records management
EP1537497A2 (fr) Procede d'organisation d'une base de donnees numeriques sous une forme tracable
EP2281271A1 (fr) Procede de gestion de processus dans un atelier oriente service collaboratif
Zimmermann Challenges in the collaborative evolution of a proof language and its ecosystem
Rizzo et al. Professional SharePoint 2010 Development
WO2010086523A1 (fr) Systeme informatique de gestion de donnees historisees dans un outil de gestion de versions
Vailiev Oracle business intelligence: The condensed guide to analysis and reporting
Kimmel Professional DevExpress ASP. NET Controls
Languedoc Build iOS database apps with Swift and SQLite
McClure et al. Professional ADO. NET 2: Programming with SQL Server 2005, Oracle, and MySQL
Jansma Scoops and Brushes for Software Archaeology: Metadata Dating
FR2963124A1 (fr) Procede de gestion de donnees, dispositif, et produit programme d'ordinateur correspondant.
Dhiman An Approach to Solving Current and Future Data Warehousing Big Data Problems
US20070118495A1 (en) Inverse hierarchical approach to data
Kumar Documentum 6.5 Content Management Foundations
FR2963123A1 (fr) Procede de gestion de donnees, dispositif, et produit programme d'ordinateur correspondant
Mcclure et al. Professional Ado. Net 2 Prog. With Sql Server 2005
Dalen et al. Microsoft Dynamics AX 2009 Programming: Getting Started
Bromley et al. Museum of London--Collections Information Integration Module

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10704950

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: COMMUNICATION NOT DELIVERED. NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112 EPC (EPO FORM 1205A DATED 27.12.2011)

122 Ep: pct application non-entry in european phase

Ref document number: 10704950

Country of ref document: EP

Kind code of ref document: A1