WO2005013145A2 - Procede permettant a un utilisateur de developper des applications informatiques appliquees a des donnees qualifiees dans un systeme de gestion de donnees (sgd) - Google Patents

Procede permettant a un utilisateur de developper des applications informatiques appliquees a des donnees qualifiees dans un systeme de gestion de donnees (sgd) Download PDF

Info

Publication number
WO2005013145A2
WO2005013145A2 PCT/FR2004/050360 FR2004050360W WO2005013145A2 WO 2005013145 A2 WO2005013145 A2 WO 2005013145A2 FR 2004050360 W FR2004050360 W FR 2004050360W WO 2005013145 A2 WO2005013145 A2 WO 2005013145A2
Authority
WO
WIPO (PCT)
Prior art keywords
data
language
management system
data management
sentences
Prior art date
Application number
PCT/FR2004/050360
Other languages
English (en)
Other versions
WO2005013145A3 (fr
Inventor
Hugues De Fougieres
Original Assignee
Hugues De Fougieres
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 Hugues De Fougieres filed Critical Hugues De Fougieres
Publication of WO2005013145A2 publication Critical patent/WO2005013145A2/fr
Publication of WO2005013145A3 publication Critical patent/WO2005013145A3/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/24—Querying
    • G06F16/245—Query processing
    • G06F16/2453—Query optimisation
    • G06F16/24534—Query rewriting; Transformation
    • 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/24—Querying
    • G06F16/245—Query processing
    • G06F16/2452—Query translation

Definitions

  • 1 invention relates to a method allowing a user to develop computer applications applied to qualified data in a data management system (SGD), in particular of DBMS type.
  • SGD data management system
  • the solution according to the invention relates to a method allowing a user to develop computer applications applied to qualified data in a data management system (SGD), in particular of DBMS type.
  • the method implements computer equipment associated with the data management system (DMS).
  • the process includes the following stages: - the stage of qualifying the data in the data management system (SGD), in particular by implementing criteria of the list type, true / false, numerical value, character strings, binary strings , - the stage of grouping the data in the data management system (SGD) in particular by using bases, tables, indexes, - the stage of generating, by means of a first language in particular of SQL type, first sentences making it possible to manage the data thus qualified and grouped, in particular by listing and / or inserting and / or modifying and / or deleting the data, - the stage of translating the first sentences thus generated into first instructions compatible with a second specific language, - the stage of writing second sentences by implementing the second specific language and the first instructions, - the stage of transforming the
  • the data are qualified in the data management system in which the method is implemented and can also be qualified in another data management system.
  • a local data management system for example, in a travel agency
  • data management for example, an airline's data management system
  • the method is characterized in that it is implemented, by the user, to describe the data and write the second sentences allowing additional treatments and / or steps to be added to the method. according to claim 1. It results from the combination of technical features that the process is implemented to be enriched and develop with itself.
  • the invention also relates to a data management system in which a method as described above is implemented.
  • FIG. 1 graphically represents tables and their relationships .
  • FIG. 2 illustrates the way in which the elements allowing the description of the databases are stored.
  • FIG. 3 illustrates the way in which the first sentences according to the invention are stored.
  • FIG. 4 illustrates the way in which the second sentences according to the invention are stored.
  • FIG. 5 gives an overview of the databases as obtained by implementing the invention.
  • the solution consists of a development tool combining an OMS and the language of the tool.
  • This development tool is in fact itself a data management system.
  • This tool allows, first, to describe and store the format of the data to be processed in a manner compatible with the OMS.
  • Data management systems for example of the type of systems known under the brand name Oracle or ySql, use qualified data and descriptions of this data within the management system itself.
  • a database processing invoices drawn up for a customer, for a product reference, at a given price ... includes tables, respectively, for invoices, for customers, for product references ... Each table has a certain number of columns which make it possible to qualify the customer, the product reference ...
  • the customer can be qualified by his name (type of character data), his address (type of character data), a characteristic of the type "exempt from VAT” or not (type of indicator data) ...
  • the data is then described in the data management system and in the tool. It is customary to graphically represent the tables and their relationships in the form of the diagram shown in Figure 1.
  • the second sentences are then placed in the database, in the form of tables containing data called syntactic units.
  • the format of the table will for example have the representation in the form of the diagram of FIG. 4.
  • the set of FIGS. 1 to 4 is represented in FIG. 5, representing the two databases, one at the top in the figure. , for the data to be managed and the other, below, for the description of the data to be managed with which the invention can be implemented.
  • Such a table contains linked syntactic units making it possible to distinguish said first instructions
  • the identification of instructions (data access functions) in a program and therefore in a second sentence is facilitated by the fact that we know which instructions use which data since the translation into the language of the tool is provided for each instruction and that each instruction uses referenced data.
  • the depth of the data is for example defined, in the following case, by a degree of depth 3 when a product appearing on an invoice depends on an invoice which itself depends on a customer because we go through three tables linked hierarchically.
  • the invention allows access to the data to be linear as a function of the number of data and not of the depth (from an invoice line one can go up in a single request to the invoice and to the customer because the DBMS takes care of managing indexes to access data in an optimized manner).
  • Tac (// Take and call: put values in the // call stack and / or call of functions Cst (30), // constant 30 put in a call stack R_1012_Select (// select list of these people ( 1 parameter xxx // taken from the call stack) Do (Take (Name), // put the content of the Name field in the call stack out (l) // display the first element contained in the call stack call) // Name is removed from the call stack at this level) // 30 is removed from the call stack at this level
  • We r - mark therefore that the data access functions (R_1012_Select in the example) concerning the data are not enough, we must also combine these verbs with each other.
  • This table is thus stored in the database. It is also possible to describe this program data so that this table includes comments. In this case, one or more columns are added to this table. Each row of this table corresponds to a language instruction or a data access function.
  • the instruction "R_1012_Select" is an SQL query translated into a data access function. Its presence makes it possible to identify directly that the program uses the selected data. This allows in particular to spot erroneous calls, a common error in application development. Indeed, in this format we can analyze and know the processing with the impacted data because all the characteristics of the 1012 query are present in the system (type / tables / fields / conditions). In other words, we can reverse engineer.
  • modifications by programs are facilitated by the presentation in table form.
  • the tabular format stored in a table in the database makes it easy to modify the program because the tool is made to process data stored in table format. Indeed, the tool then allows you to regenerate a source program from the tabular form. There is a bijection between the source assembly and the tabular assembly. From the tabular form, the tool generates source programs for example in binary, assembler, PHP, C or Java language, which finally allows the processor to execute the instructions.
  • the tool therefore performs, like the compilers, firstly a syntactic analysis of the source programs (phase in table format) and secondly of writing instructions compatible with the processor.
  • the kernel takes care of translating the instructions of the language of the tool as well as the verbs linked to the data in intermediate language or in processor language.
  • the kernel is written mostly with the language of the tool. This proportion tends to change in a positive way because this part concerns access to data while the part concerning internal processing does not change much. Indeed, once we are able to write, read, modify or delete data on a device, doing the same operations on another device is not functionally very different (we can say that it is the same, functionally to write "hello" on the screen and on the printer) If we have to add a new device (for example a scanner), the part of the kernel to be completed will be reduced. It is necessary that the tool is written with its own means for all access to the data in writing, reading, modification or deletion.
  • a kernel allowing to execute instructions not related to data manipulation is written in any other language that can finally be executed by the processor.
  • the kernel is in a way the equivalent of an operating system such as Linux, Windows, Unix on which we run programs such as text editor, spreadsheet, graphics, sound or image processing.
  • certain elements of the kernel written directly in language other than that of the tool can be rewritten in the language of the tool because this language evolves and makes it possible to do certain operations which were not possible in the first versions: the functionalities of the language also evolving, they make it possible to greatly simplify this rewriting. It only takes time to translate programs written in language other than that of the tool into the language of the tool.
  • the kernel can be reduced to data access on devices other than the processor (hard disks, screen, mouse, printers, components managing these devices ). Indeed, only a part of the kernel is still and will remain written manually with a language which "speaks" the language of the heart of the processing system that is the processor and its peripherals.
  • the use of a known intermediate language will facilitate the work because there are already tools (compilers or interpreters) allowing to pass from the intermediate language to the processor language.
  • the rest of the kernel and the programs written with this tool are written in the language of the tool, as well as, for example, compilers in C language are developed in C language.

Landscapes

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

Abstract

L'invention concerne un procédé pour développer des applications informatiques appliquées à des données d'un système de gestion de données (SGD) comprenant: - l'étape de qualifier les données dans le SGD, - l'étape de regrouper les données du SGD, - l'étape de générer, des premières phrases permettant de gérer les données qualifiées et regroupées, - l'étape de traduire les premières phrases en premières instructions compatibles avec un deuxième langage, - l'étape d'écrire des deuxièmes phrases en mettant en oeuvre le deuxième langage et les premières instructions, - l'étape de transformer les deuxièmes phrases en unités syntaxiques, - l'étape de générer à nouveau les deuxièmes phrases du deuxième langage à partir des unités syntaxiques, - l'étape d'intégrer les unités syntaxiques dans le SGD, - l'étape d'appliquer aux unités syntaxiques un traitement pour retrouver une utilisation des données dans les deuxièmes phrases, - l'étape de traduire les unités syntaxiques en instructions finales exécutables par l'équipement informatique et de les exécuter, l'étape d'utiliser le procédé pour développer le procédé.

Description

PROCEDE PERMETTANT A UN UTILISATEUR DE DEVELOPPER DES APPLICATIONS INFORMATIQUES APPLIQUEES A DES DONNEES QUALIFIEES DANS UN SYSTEME DE GESTION DE DONNEES (SGD)
1 invention concerne un procédé permettant à un utilisateur de développer des applications informatiques appliquées à des données qualifiées dans un système de gestion de données (SGD) , notamment de type SGBD.
Lors de développements de systèmes d'informations, l'utilisation de systèmes de gestion de données (SGD) et de langages informatiques indépendants des SGD donne lieu à des déclarations redondantes du système d'information à gérer. En effet on va jusqu'à trouver une modélisation des données à gérer à la fois dans le SGD et dans la partie traitement de ces données . Cette redondance provoque des difficultés à synchroniser les modèles de données, alourdit la partie traitement. Le résultat est que, même pour gérer un système d'information simple, les couches techniques peuvent devenir si nombreuses que les développements doivent faire appel à des spécialistes pour chaque couche. Ce phénomène est encore renforcé quand on cherche à réaliser des systèmes d'information indépendants du SGD. On trouve alors d'autres couches qui représentent des modélisations des traitements dans les SGD. L'utilisateur final ou le maître d'ouvrage qui définit les données à gérer perd la maîtrise du système d'information car les couches techniques sont des boîtes noires et il est difficile de faire du reverse ingeneering. Le maître d'ouvrage qui, par définition, est capable de décrire les traitements à réaliser à partir des données donne la main au maître d'œuvre et ne peut que constater le résultat car il n'est pas censé avoir la maîtrise technique du système et ne peut pas contrôler les moyens mis en œuvre. L'utilisation d'outils de type Ateliers de Génie
Logiciels (AGL) permettant de modéliser les systèmes d'information permet en partie de gérer ces problèmes, mais, d'une part, les traitements ne sont que partiellement produits par ces outils et un grand nombre d'entre eux sont écrits manuellement par la maîtrise d'œuvre et, d'autre part, la redondance est encore présente. Quand ces outils permettent de réaliser ces systèmes d'information, ils sont souvent propriétaires et constituent des boîtes noires qui rendent les systèmes d'information dépendants d'eux. Les migrations vers d'autres technologies sont difficiles et comportent une grande partie d'opérations manuelles, le reverse ingeneering n'est pas automatique. Les SGD les plus courants utilisent un langage d'accès aux données (notamment SQL) qui est différent du langage utilisé pour construire le système d'information (C, Java, Basic, ...) . Donc on trouve au sein du langage du système d'information des éléments du langage des SGD avec des systèmes parfois complexes pour passer les informations d'un langage à un autre. L' invention se propose de palier à de tels inconvénients . La solution, selon l'invention, concerne un procédé permettant à un utilisateur de développer des applications informatiques appliquées à des données qualifiées dans un système de gestion de données (SGD), notamment de type SGBD. Le procédé met en œuvre un équipement informatique associé au système de gestion de données (SGD) . Le procédé comprend les étapes suivantes : - l'étape de qualifier les données dans le système de gestion de données (SGD) , notamment en mettant en œuvre des critères du type liste, vrai/faux, valeur numérique, chaînes de caractères, chaînes binaires, - l'étape de regrouper les données dans le système de gestion de données (SGD) notamment en utilisant des bases, des tables, des index, - l'étape de générer, au moyen d'un premier langage notamment de type SQL, des premières phrases permettant de gérer les données ainsi qualifiées et regroupées, notamment en listant et/ou en insérant et/ou en modifiant et/ou en supprimant les données, - l'étape de traduire les premières phrases ainsi générées en premières instructions compatibles avec un deuxième langage spécifique, - l'étape d'écrire des deuxièmes phrases en mettant en œuvre le deuxième langage spécifique et les premières instructions, - l'étape de transformer les deuxièmes phrases en unités syntaxiques liées en distinguant lesdites premières instructions, - l'étape de générer à nouveau les deuxièmes phrases du deuxième langage spécifique à partir des unités syntaxiques liées, - l'étape d'intégrer les unités syntaxiques liées dans le système de gestion de données (SGD) , - l'étape d'appliquer aux unités syntaxiques liées un traitement permettant de retrouver une utilisation de chacune des données dans les deuxièmes phrases. Il résulte de la combinaison des traits techniques qu'on réalise un traitement des données par les programmes et un traitement des programmes à la manière dont on traite les données. Ainsi, une boucle de retour d'information apparaît. Un tel procédé sert au développement de tous types d'applications informatiques qui peuvent être notamment un programme unique ou un groupe de programmes. Le procédé comprend en outre les étapes suivantes : - l'étape de traduire les unités syntaxiques liées en instructions finales pouvant être exécutées par l'équipement informatique, notamment en instructions écrites en langage binaire, langage assembleur, langage C, langage PHP, langage Java, - l'étape d'exécuter les instructions finales. Il résulte de la combinaison des traits techniques que les données sont traitées par la mise en œuvre d'applications informatiques associées au système de gestion de données (SGD) . On note que les données sont qualifiées dans le système de gestion de données dans lequel le procédé est mis en œuvre et peuvent être également qualifiées dans un autre système de gestion de données. C'est ce qui se passe par exemple quand un système de gestion de données local (par exemple, dans une agence de voyage) fait appel et qualifie, pour son fonctionnement, à une partie seulement de la totalité des données qualifiées dans un autre système de gestion de données (par exemple, le système de gestion de données d'une compagnie aérienne) . De préférence, selon l'invention, le procédé est caractérisé en ce qu'il est mis en œuvre, par l'utilisateur, pour décrire les données et écrire les deuxièmes phrases permettant d'ajouter des traitements et/ou des étapes complémentaires au procédé selon la revendication 1. Il résulte de la combinaison des traits techniques que le procédé est mis en œuvre pour être enrichi et se développer avec lui-même. L' invention concerne également un système de gestion de données dans lequel est mis en œuvre un procédé tel que décrit ci-dessus.
D'autres caractéristiques et avantages de l'invention apparaîtront avec la description faite ci-dessous, cette dernière étant effectuée à titre descriptif et non limitatif en faisant référence aux dessins ci-après sur lesquels: La figure 1 représente graphiquement des tables et leurs relations. La figure 2 illustre la façon dont sont stockés les éléments permettant la description des bases de données . La figure 3 illustre la façon dont sont stockées les premières phrases selon l'invention. La figure 4 illustre la façon dont sont stockées les deuxièmes phrases selon l'invention. La figure 5 donne une vue d'ensemble des bases de données telles qu'obtenues en mettant en œuvre l'invention.
La solution est constituée d'un outil de développement combinant un SGD et le langage de l'outil. Cet outil de développement est en fait, lui-même, un système de gestion de données . Cet outil permet, d'abord, de décrire et de stocker le format des données à traiter d'une façon compatible avec le SGD. Les systèmes de gestion de données, par exemple du type des systèmes connus sous la marque Oracle ou ySql, utilisent des données qualifiées et des descriptions de ces données au sein du système de gestion lui-même. Par exemple, une base de données traitant des factures établies pour un client, pour une référence de produit, à un prix donné... inclut des tables, respectivement, pour les factures, pour les clients, pour les références des produits... Chaque table possède un certain nombre de colonnes qui permettent de qualifier le client, la référence de produit... Par exemple, le client pourra être qualifié par son nom (type de donnée caractère) , son adresse (type de donnée caractère) , une caractéristique du type « exonéré de TVA » ou pas (type de donnée indicateur)... Les données sont alors décrites dans le système de gestion de données et dans l'outil. Il est d'usage de représenter graphiquement les tables et leurs relations sous la forme du schéma représenté sur la figure 1. Tous les éléments permettant la description des bases de données (base de données factures dans le cas du schéma ci dessus) , des tables (client, Facture, Produits, Produits_Factures) , des champs (Pour la table Client : ID, Nom, Exonere-tva, pour la table Produits produit : Id, Nom, Prix_Unitaire, ...) , des liens entre les champs (les flèches) , des types de champs (Date, nombre, indicateur ....) sont stockés dans l'outil selon le schéma représenté sur la figure 2. Les données peuvent ensuite être listées, insérées, modifiées ou supprimées à l'aide de premières phrases dans un premier langage spécifique au SGD, par exemple de type requêtes SQL. Ce premier langage sert pour insérer, lire, modifier ou supprimer les données. Les premières phrases seront stockées dans l'outil selon le schéma simplifié de la figure 3. L' outil traduit ensuite les instructions du premier langage (requêtes SQL) , celui du SGD, dans le langage de l'outil, dit deuxième langage. Ces traductions sont des premières instructions (fonctions d'accès aux données en écriture, lecture, modification, suppressions) qui sont compatibles avec le deuxième langage. Des programmes peuvent alors être écrits sous forme de phrases, dite deuxièmes phrases, en utilisant le langage de 1' outil qui comprend les instructions classiques des langages (boucles, tests, déclarations) et les premières instructions. Ces programmes écrits selon un format appelé format source sont stockés dans l'outil. Selon l'invention, l'outil peut transformer les programmes écrits dans le langage source de l'outil en données compatibles avec le SGD (c'est à dire par exemple au format table) pour lier le langage de l'outil aux données. Ainsi les deuxièmes phrases sont ensuite placées dans la base de données, sous la forme de tables contenant des données appelées unités syntaxiques. Le format de la table aura par exemple la représentation sous forme du schéma de la figure 4. L'ensemble des figures 1 à 4 est représenté sur la figure 5, représentant les deux bases de données, l'une, en haut sur la figure, pour les données à gérer et l'autre, en bas, pour la description des données à gérer avec lesquelles l'invention peut être mise en œuvre. Une telle table contient des unités syntaxiques liées permettant de distinguer lesdites premières instructions
(fonctions d'accès aux données) . Chaque fonction d'accès aux données possède un nom particulier, et est alors représentée sur une ligne de la table. Les caractéristiques de ces fonctions d'accès aux données sont décrites dans le système de gestion de données. Donc, selon l'invention, les unités syntaxiques sont intégrées dans le système de gestion de données et donc qualifiées en données du système de gestion. Elles sont avantageusement aussi regroupées. Cela permet de modifier aisément lesdites deuxièmes phrases. En effet, les caractéristiques des fonctions d'accès aux données étant stockées sous un format de données, on peut écrire des programmes permettant d'ajouter, de lire, de modifier ou de supprimer des données de cette table, ainsi qu'il l'était pour modifier une donnée d'un client, par exemple, son adresse dans la base de données . Selon l'invention, l'outil peut transformer de façon inverse les programmes écrits au format table en programmes écrits au format source (deuxièmes phrases) permettant ainsi la lecture, la modification des programmes source par le programmeur. En outre, le repérage des instructions (fonctions d'accès aux données) dans un programme et donc dans une deuxième phrase est facilité par le fait que l'on sait quelles instructions utilisent quelles données puisque la traduction dans le langage de l'outil est fournie pour chaque instruction et que chaque instruction fait appel à des données référencées. La profondeur des données est par exemple définie, dans le cas suivant, par un degré de profondeur 3 quand un produit figurant sur une facture dépend d'une facture qui dépend elle même d'un client car on passe par trois tables liées hiérarchiquement. En utilisant les moyens fournis par les SGBG, l'invention permet que l'accès aux données soit linéaire en fonction du nombre de données et pas de la profondeur (à partir d'une ligne de facture on peut remonter en une seule requête à la facture et au client car le SGBD s'occupe de gérer des indexes pour accéder aux données de façon optimisée) . Le résultat est que l'on peut traiter un grand nombre de données de façon optimisée et le temps de traitement n'est plus lié au degré de profondeur mais seulement au nombre de données, sachant que le SGBD optimise énormément les temps d'accès, c'est d'ailleurs un des objets du discours commercial des concepteurs de ces programmes. L'invention permet d'exploiter ces qualités pour le développement des applications. Lors d'un développement d'une application avec cet outil, il faut d'abord définir les données. Par exemple, on s'intéresse à un modèle de données avec une table de produits contenant leur nom et leur coût unitaire. Le SGD permet ensuite d'exécuter les traitements de base sur ces données (ajout, lecture, modification, suppression) . Ces traitements de base sont alors traduits par l'outil en verbes du langage permettant de manipuler ces données . Ainsi, des requêtes sont générées par le système. Si une requête portant le numéro 1012 a été définie pour donner ceci : SELECT Nom, PrixJJnitaire FROM Produits TO WHERE Prix_Unitaire >= xxx Le système a généré à partir de cette requête une instruction (fonction d' accès aux données) compatible avec le langage de l' outil s ' appelant R_1012_Select () . Cette requête accepte un paramètre qui est le coût unitaire (xxx) . Une utilisation de cette fonction pourra par exemple servir à afficher tous les produits dont le coût unitaire est >= 30. C ' est le système qui doit ensuite générer les requêtes complètes de manière à rendre les instructions exécutables . Il commence alors par stocker toutes les caractéristiques de la requête selon les exigences du programmeur (tables impactées, champs utilisés, critères, liens entre les champs, ordre d' affichage, de tri...) et à partir de ces caractéristiques, le système génère la requête SQL et la fonction d' accès aux données utilisant la phrase SQL traduite. Cela donnera un programme qui ressemble à ceci (les commentaires sont précédés par //) :
Tac ( // Take and call : met des valeurs dans la // pile d'appel et/ou appeldes fonctions Cst (30) , // constante 30 mise dans une pile d'appel R_1012_Select ( // sélect liste de ces gens (1 paramètre xxx // pris dans la pile d'appel) Do ( Take (Nom) , // mettre le contenu du champ Nom dans la pile d' appel out (l) // afficher le premier élément contenu dans la pile d'appel ) // Nom est retire de la pile d'appel a ce niveau ) // 30 est retire de la pile d'appel a ce niveau On r--marque donc que les fonctions d'accès aux données (R_1012_Select dans l'exemple) concernant les données ne suffisent pas, il faut aussi combiner ces verbes entre eux. Ceci passe par le langage de l'outil contenant des verbes prédéfinis permettant d'une part de combiner les verbes des données entre eux selon les conditions imposées par les fonctionnalités voulues dans les programmes (Test, boucles, opérations mathématiques...) et, d'autre part, permettant d'exécuter les traitements ne passant pas obligatoirement par le SGD comme par exemple la lecture ou l'écriture de données hors SGD (lecture ou écriture de données sur des interfaces de types écrans, fichiers, souris, ports de communication réseau...) . Les programmes résultants de la combinaison de ces verbes sont des deuxièmes phrases qui doivent être écrites sous une forme syntaxique représentant des actions, mais qui peuvent' être transformées par l'outil sous une forme qui puisse être stockée sous la forme de table, compatible avec le SGD. Ces deuxièmes phrases sont donc, syntaxiquement, des suites imbriquées d'éléments du langage de l'outil et de fonctions d'accès aux données, et elles peuvent être transformées en unités syntaxiques permettant de distinguer les fonctions d'accès aux données. Les unités syntaxiques sont donc qualifiées et décrites dans le système de données de manière à être stockées sous forme de données, compatible avec le SGD. Les données dans cette table peuvent être ensuite lues, modifiées, ajoutées ou supprimées par d'autres programmes. Ainsi le système offre un vrai potentiel pour le développement informatique d' applications fiables car elles peuvent être contrôlées et éventuellement modifiées par d'autres programmes/applications qui vérifient, signalent ou même corrigent les règles d'accès aux données. En d'autres termes, les programmes deviennent des données exploitables de la même manière que les données gérées. Les données et les programmes sont liés . Dans l'exemple de programme donné ci-dessus, le programme aura alors la forme tabulaire suivante :
Figure imgf000012_0001
Cette table est stockée ainsi dans la base de données . II est aussi possible de décrire ces données de programmes de manière à ce que cette table inclut des commentaires . Dans ce cas, une ou plusieurs colonnes sont ajoutées dans cette table. Chaque ligne de cette table correspond à une instruction du langage ou une fonction d'accès aux données. On note qu'en ligne 4, l'instruction « R_1012_Select » est une requête SQL traduite en une fonction d'accès aux données . Sa présence permet de repérer directement que le programme fait appel aux données sélectionnées . Cela permet notamment de repérer des appels erronés, erreur courante dans le développement d'applications. En effet, sous ce format on pourra analyser et connaître les traitements avec les données impactées car toutes les caractéristiques de la requête 1012 sont présentes dans le système (type/tables/champs/conditions) . En d'autres termes, on pourra faire du reverse-engineering. De plus, les modifications par des programmes sont facilitées par la présentation sous forme de table. Le format tabulaire stocké dans une table de la base de données permet de modifier le programme aisément car l'outil est fait pour traiter des données stockées au format table. Effectivement, l'outil permet de régénérer ensuite un programme source à partir de la forme tabulaire. Il y a une bijection entre l'ensemble source et l'ensemble tabulaire. A partir de la forme tabulaire, l'outil génère des programmes sources par exemple en langage binaire, assembleur, PHP, C ou Java, ce qui permet finalement au processeur d'exécuter les instructions. L'outil effectue donc, comme les compilateurs, premièrement une analyse syntaxique des programmes source (phase de mise au format table) et deuxièmement une écriture d'instructions compatibles avec le processeur. Le noyau se charge de traduire les instructions du langage de 1 'outil ainsi que les verbes liés aux données en langage intermédiaire ou en langage processeur. Le noyau est écrit en majorité avec le langage de l'outil. Cette proportion tend à évoluer de façon positive car cette partie concerne l'accès aux données alors que la partie concernant les traitements internes évolue peu. En effet, une fois que l'on est capable d'écrire, de lire, de modifier ou de supprimer des données sur un périphérique, faire les mêmes opérations sur un autre périphérique n'est pas fonctionnellement très différent (on peut dire qu'il revient au même, fonctionnellement d'écrire "bonjour" à l'écran et sur l'imprimante) Si on doit ajouter un nouveau périphérique (par exemple un scanner) , la partie du noyau à compléter sera réduite. Il est nécessaire que l'outil soit écrit avec ses propres moyens pour tous les accès aux données en écriture, lecture, modification ou suppression. Un noyau permettant d'exécuter les instructions non liées à la manipulation des données est écrit dans tout autre langage pouvant être finalement exécuté par le processeur. Le noyau est en quelque sorte l'équivalent d'un système d'exploitation comme par exemple Linux, Windows, Unix sur lequel on fait fonctionner des programmes du type éditeur de texte, tableur, traitement graphiques, de sons ou d'images... De plus, certains éléments du noyau écrits directement en langage autre que celui de l'outil peuvent être réécrits dans le langage de l'outil car ce langage évolue et permet de faire certaines opérations qui n'étaient pas possibles dans les premières versions : les fonctionnalités du langage évoluant elles aussi, elles permettent de simplifier grandement cette réécriture. Il faut seulement du temps pour traduire les programmes écrits dans le langage autre que celui de l'outil en langage de l'outil. Mais à terme, le noyau pourra être réduit aux accès aux données sur les périphériques autres que le processeur (disques durs, écran, souris, imprimantes, composants gérant ces périphériques ... ) . En effet, seule une partie du noyau est encore et restera écrite manuellement avec un langage qui "parle" le langage du cœur du système de traitement qu'est le processeur et ses périphériques. Pour écrire ce noyau, l'utilisation d'un langage intermédiaire connu facilitera le travail car il existe déjà des outils (compilateurs ou interpréteurs) permettant de passer du langage intermédiaire au langage processeur. Le reste du noyau et les programmes écrits avec cet outil sont écrits avec le langage de l'outil, ainsi que, par exemple, les compilateurs en langage C sont développés en langage C. La combinaison des deux principes qui sont, d'une part, obtenir à partir du système de gestion des données les verbes du langage permettant d'accéder aux données et, d'autre part, utiliser un langage qui peut être mis sous forme de données permettant de relier, grâce au système de gestion des données, les traitements aux données constitue le cœur de la solution. La solution bénéficie pleinement de l'organisation systématique réalisée sur les données dans un système de base de données . Le système ci-dessus constitue un système bouclé qui garantit un contrôle des données et des traitements. Le fait que l'outil soit écrit avec ses propres moyens garantit un autocontrôle. Seul le noyau écrit dans un langage autre que celui de l'outil doit être contrôlé mais, comme il est de taille réduite et évolue peu, son contrôle est facile. Par ailleurs, les instructions standard du langage de l'outil (déclarations, tests, boucles...) autres que les fonctions d'accès aux données sont elles mêmes mises en base de données ce qui permet d'exécuter des transformations sur les sources telles que par exemple traductions dans une autre langue, modification des traitements, enrichissement des commentaires... Par exemple, pour effectuer une boucle, le terme utilisé est "Loop" et il suffira de traduire ce terme en "Boucle" dans la base pour ensuite utiliser ce terme à la place de Loop dans les programmes . Ce qui fait qu'un système peut évoluer sans limites est lié au principe de récursivité d'après lequel, par retour ou récursivité sur tout ou partie des éléments de départ, un petit nombre d'éléments finis suffit à construire une série infinie d'événements. C'est ce principe qui est mis en oeuvre dans cet outil, par la rétro analyse de ce crue l'outil produit (des applications) par les moyens de l'outil et par le fait que l'outil est développé en partie avec lui même. Un produit utilise ce principe grâce à un système de gestion de base de données (SGBG) , un serveur de données permettant de les visualiser et un langage pour écrire le noyau. Bien qu'il soit toujours en cours de d'amélioration, il a déjà été utilisé pour développer des systèmes d'information utiles aux entreprises.

Claims

REVENDICATIONS
1. Procédé permettant à un utilisateur de développer des applications informatiques appliquées à des données qualifiées dans au moins un système de gestion de données (SGD) , notamment de type SGBD ; ledit procédé mettant en œuvre un équipement informatique associé audit système de gestion de données (SGD) ; ledit procédé comprenant les étapes suivantes : - l'étape de qualifier lesdites données dans ledit système de gestion de données (SGD) , notamment en mettant en œuvre des critères du type liste, vrai/faux, valeur numérique, chaînes de caractères, chaînes binaires, - l'étape de regrouper lesdites données dudit système de gestion de données (SGD,) notamment en utilisant des bases, des tables, des index, - l'étape de générer, au moyen d'un premier langage notamment de type SQL, des premières phrases permettant de gérer lesdites données ainsi qualifiées et regroupées, notamment en listant et/ou en insérant et/ou en modifiant et/ou en supprimant lesdites données, - l'étape de traduire lesdites premières phrases ainsi générées en premières instructions compatibles avec un deuxième langage spécifique, - l'étape d'écrire des deuxièmes phrases en mettant en œuvre ledit deuxième langage spécifique et lesdites premières instructions, - l'étape de transformer lesdites deuxièmes phrases en unités syntaxiques liées en distinguant lesdites premières instructions, - l'étape de générer à nouveau lesdites deuxièmes phrases dudit deuxième langage spécifique à partir desdites unités syntaxiques liées, - l'étape d'intégrer lesdites unités syntaxiques liées dans ledit système de gestion de données (SGD) , l'étape d'appliquer auxdites unités syntaxiques liées un traitement permettant de retrouver une utilisation de chacune desdites données dans lesdites deuxièmes phrases ; de sorte qu'on réalise un traitement des données par les applications et un traitement des applications à la manière dont on traite les données et qu'une boucle de retour d'information apparaît ; ledit procédé comprenant en outre les étapes suivantes : - l'étape de traduire lesdites unités syntaxiques liées en instructions finales pouvant être exécutées en tant qu'application par ledit équipement informatique, notamment en instructions écrites en langage binaire, langage assembleur, langage C, langage PHP, langage Java, - l'étape d'exécuter lesdites instructions finales; de sorte que les données sont traitées par la mise en œuvre d'applications informatiques associées au système de gestion de données (SGD) .
2. Procédé selon la revendication 1 ; ledit procédé étant caractérisé en ce qu'il est mis en œuvre, par ledit utilisateur, pour décrire lesdites données et écrire des deuxièmes phrases permettant d'ajouter des traitements et/ou des étapes complémentaires audit procédé selon la revendication 1 ; de sorte que le procédé est mis en œuvre pour être enrichi et se développer avec lui-même.
3. Système de gestion de données destiné à mettre en œuvre un procédé selon l'une des revendications 1 et 2.
PCT/FR2004/050360 2003-07-28 2004-07-27 Procede permettant a un utilisateur de developper des applications informatiques appliquees a des donnees qualifiees dans un systeme de gestion de donnees (sgd) WO2005013145A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0350377A FR2858439A1 (fr) 2003-07-28 2003-07-28 Procede permettant a un utilisateur de developper des applications informatiques appliquees a des donnees qualifiees dans un systeme de gestion de donnees(sgd)
FR03/50377 2003-07-28

Publications (2)

Publication Number Publication Date
WO2005013145A2 true WO2005013145A2 (fr) 2005-02-10
WO2005013145A3 WO2005013145A3 (fr) 2005-06-16

Family

ID=34043804

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2004/050360 WO2005013145A2 (fr) 2003-07-28 2004-07-27 Procede permettant a un utilisateur de developper des applications informatiques appliquees a des donnees qualifiees dans un systeme de gestion de donnees (sgd)

Country Status (2)

Country Link
FR (1) FR2858439A1 (fr)
WO (1) WO2005013145A2 (fr)

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
JIA LIANG HAN: "A Multiparadigm Programming Method in Database Systems" SOFTWARE ENGINEERING AND APPLICATIONS. PROCEEDINGS OF THE FIFTH IASTED INTERNATIONAL CONFERENCE, 21 août 2001 (2001-08-21), - 24 août 2001 (2001-08-24) pages 13-18, XP008045965 ANAHEIM, CA, USA ISBN: 0-88986-305-9 *
JIA LIANG HAN: "An Approach to Multiparadigm Programming Database Systems" DATABASE AND EXPERT SYSTEMS APPLICATIONS, 1996. PROCEEDINGS, SEVENTH INTERNATIONAL WORKSHOP, 9 septembre 1996 (1996-09-09), pages 326-331, XP010200892 ISBN: 0-8186-7662-0 *
RICHARDSON J D ET AL: "Ada and SQL: The Two Layer Approach" PROCEEDINGS OF EIGHTH ANNUAL NATIONAL CONFERENCE ON ADA TECHNOLOGY, 5 mars 1990 (1990-03-05), - 8 mars 1990 (1990-03-08) pages 36-48, XP008045992 ATLANTA, GA, USA *

Also Published As

Publication number Publication date
WO2005013145A3 (fr) 2005-06-16
FR2858439A1 (fr) 2005-02-04

Similar Documents

Publication Publication Date Title
EP1880325B1 (fr) Méthode dynamique de génération de documents xml á partir d'une base de données
US10242061B2 (en) Distributed execution of expressions in a query
FR2888018A1 (fr) Procede et systeme de realisation d'une base de donnees virtuelle a partir de sources de donnees presentant des schemas heterogenes
CA2110538A1 (fr) Systeme d'information multimedia
FR2909198A1 (fr) Procede et disositif de filtrage d'elements d'un document structure a partir d'une expression.
WO2010009996A1 (fr) Procede de compilation de programme informatique
WO2016061576A1 (fr) Api pour l'implémentation de fonctions de notation
US11321314B2 (en) Query content-based data generation
EP1046104A1 (fr) Creation dynamique de classes d'objets
EP1537497A2 (fr) Procede d'organisation d'une base de donnees numeriques sous une forme tracable
EP2738674A1 (fr) Déploiement d'objet complexe de base de données de mémoire
Harrison Code generation with roslyn
WO2005013145A2 (fr) Procede permettant a un utilisateur de developper des applications informatiques appliquees a des donnees qualifiees dans un systeme de gestion de donnees (sgd)
EP1046102B1 (fr) Derivation d'une classe d'objets par heritage, instanciation ou clonage
Cheron Conception, maintenance et évolution non-cassante des API REST
EP3874368A1 (fr) Executer des portions de code sur des ressources d´execution
Turis Domain-driven design with architectural patterns
EP2558932A1 (fr) Procédé d'enregistrement de données, dispositif, et produit programme d'ordinateur correspondant
Sharma et al. Three Layered Crud API Architecture
Mouratidis Implementation of a web-based platform for Data Analysis, Visualization and Machine Learning
WO2010086523A1 (fr) Systeme informatique de gestion de donnees historisees dans un outil de gestion de versions
WORTHINGTON Oracle Bids for BEA
FR2963123A1 (fr) Procede de gestion de donnees, dispositif, et produit programme d'ordinateur correspondant
Pisarenko The integration of JasperReports to MHG ERP System
EP1441294A1 (fr) Procédé en ligne de publication de documents informatiques sur l'internet

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 BW 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 NA 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): GM KE LS MW MZ NA 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 PL 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
122 Ep: pct application non-entry in european phase