Brevet FR3007548A1 — publié le 20141226

PRÉ ET POST-TRAITEMENT POUR INTERROGATION DE BASE DE DONNÉES DOMAINE DE L'INVENTION L'invention concerne les systèmes de gestion de base de données relationnelles et notamment à l'interrogation de tels systèmes par des utilisateurs. CONTEXTE DE L'INVENTION Les bases de données relationnelles sont des structures de données organisées sous la forme de tables au sein desquelles les données sont indexées au moyen de clés. Typiquement, une table comporte un ensemble d'enregistrements (ou « lignes ») indexés par une clé primaire. Les « colonnes » de la table représentent les champs. Un enregistrement comporte une valeur pour chacun des champs de la table. Les tables peuvent se référencer entre elles afin de structurer l'information, en comportant un champ ayant pour valeur une clé (dite alors « clé étrangère ») correspondant à un enregistrement d'une autre table. Il est bien connu d'associer une base de données relationnelle à un système de gestion afin d'assurer une interface destinée aux utilisateurs la base de données qui soit indépendante de la structure physique de la base de données. Ainsi un utilisateur U peut accéder à la base de données DB au travers d'un système de gestion de base de données DBS. La base de données DB et le système de gestion DBS peuvent appartenir à un même serveur fonctionnel. Le système de gestion de base de données permet notamment à l'utilisateur d'interroger la base par des requêtes et de recevoir des réponses via un langage d'interrogation structuré tel que le langage SQL (pour « Structure Query Language » en langue anglaise) qui est normalisé à la fois par l'ISO (International Standard Organization) et par l'ANSI (American National Standards Institute). Ce langage SQL permet, au moyen d'un ensemble de commandes (appelées « requêtes »), de manipuler les données au sein de la base de données DB. Ces commandes permettent d'effectuer notamment des recherches, d'ajouter des données, de mettre à jour (ou modifier) des données présentes, d'effacer des données, de créer ou de supprimer des tables, etc. Ce langage permet d'offrir une interface universelle, de sorte que sa connaissance permet à un utilisateur d'interagir avec toutes les bases de données. Toutefois, une telle interface n'offre aucun mécanisme de contrôle des données transmises entre l'utilisateur et la base de données. D'une part, celles-ci sont récupérées de la base de données et transmises de façon brute à l'utilisateur qui doit donc gérer les formats propres à la base de données avant de les présenter sur un écran ou de les traiter. D'autre part, les données sont insérées dans la base de données sous la forme transmise par l'utilisateur, sans qu'aucune cohérence ne soit vérifiée entre les données insérées par différentes requêtes, ni qu'il soit possible d'imposer un format particulier pour l'insertion des données. RESUME DE L'INVENTION Le but de la présente invention est de fournir une solution palliant au moins partiellement les inconvénients précités, en permettant une duplication et une duplication partielle facilitées d'un enregistrement d'une table. À cette fin, la présente invention propose un procédé d'interrogation d'une base de données relationnelles consistant à effectuer un traitement sur certaines données transmises par un échange de messages entre un utilisateur et ladite base de données relationnelle constitué d'une requête et d'une réponse, ledit traitement étant effectué en séquence dudit échange et en fonction de règles mémorisées dans un fichier de configuration et identifiées par le contenu dudit échange. Suivant des modes de réalisation préférés, l'invention comprend une ou plusieurs des caractéristiques suivantes qui peuvent être utilisées séparément ou en combinaison partielle entre elles ou en combinaison totale entre elles : lesdites règles indiquent si ledit traitement est effectué pour ladite requête ou pour ladite réponse. lesdites règles indiquent une table et un champ de ladite base de données et dans lequel ledit traitement est effectué si ledit contenue concerne ladite table et ledit champ. lesdites règles indiquent une fonction visant à traiter lesdites certaines données. Un autre aspect de l'invention concerne un programme d'ordinateur comprenant des instructions qui, une fois chargées sur un système de traitement de l'information, sont aptes à mettre en oeuvre le procédé précédemment décrit. Un autre aspect de l'invention concerne un dispositif pour l'interrogation d'une base de données relationnelles comportant des moyens pour effectuer un traitement sur certaines données transmises par un échange de messages entre un utilisateur et ladite base de données relationnelle constitué d'une requête et d'une réponse, ledit traitement étant effectué par ledit dispositif en séquence dudit échange et en fonction de règles mémorisées dans un fichier de configuration et identifiées par le contenu dudit échange. Suivant des modes de réalisation préférés, l'invention comprend une ou plusieurs des caractéristiques suivantes qui peuvent être utilisées séparément ou en combinaison partielle entre elles ou en combinaison totale entre elles : Le dispositif est adapté pour effectuer ledit traitement en fonction desdites règles qui indiquent si ledit traitement est effectué pour ladite requête ou pour ladite réponse. lesdites règles indiquent une table et un champ de ladite base de données et dans lequel ledit traitement est effectué si ledit contenu concerne ladite table et ledit champ. lesdites règles indiquent une fonction visant à traiter lesdites certaines données. le dispositif est adapté pour s'interfacer avec un système de gestion de base de données. D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description qui suit d'un mode de réalisation préféré de l'invention, donnée à titre d'exemple et en référence aux dessins annexés. BREVE DESCRIPTION DES DESSINS La figure 1 représente schématiquement une architecture fonctionnelle d'un système composé d'une base de données et dispositif s'interposant entre un utilisateur la base de données, conformément à l'état de la technique. Les figures 2a et 2b illustrent deux modes de réalisation de l'invention et les relations entre le dispositif et le système de gestion de base de données. DESCRIPTION DETAILLEE DE L'INVENTION La figure 1 illustre de façon générale une mise en oeuvre de l'invention. L'invention propose d'insérer un dispositif D entre les utilisateurs U et la base de données afin de mettre en oeuvre un traitement sur les données transmises entre la base de données et les utilisateurs. Ce traitement est effectué en séquence de la transmission des données. Autrement dit, deux types de traitement peuvent être possibles ; ces deux types pouvant se cumuler. Un premier type de traitement (dit « prétraitement ») peut être effectué par le dispositif D sur les requêtes R1 provenant de l'utilisateur U. Ce traitement peut traiter des données contenues dans la requête R1, et la requête est transmise, sous une forme éventuellement modifiée R2, à la base de données SB. Un second type de traitement (dit « post-traitement ») peut être effectué par le dispositif D sur les réponses Al provenant de la base de données DB. Ce traitement peut traiter des données contenus dans la réponse Al et la réponse est transmise, sous une forme éventuellement modifiée A2, à l'utilisateur U. Une requête Ri/R2 peut provoquer l'émission d'une réponse Al/A2 de la part de la base de données. La requête et la réponse correspondante constituent un échange. Par conséquent, le traitement sur les données est bien effectué en séquence de l'échange, soit avant dans le cas d'un prétraitement, soit après dans le cas d'un post-traitement. Les figures 2a et 2b illustrent deux modes de réalisation de l'invention. Dans la figure 2a, le dispositif D est indépendant du système de base de données DBS. Il peut alors s'interfacer avec différents types de bases de données via ce système de gestion de base de données DBS. Cela permet d'ajouter les fonctionnalités de l'invention de façon indépendante du fournisseur de base de données. Dans la figure 2b, le dispositif D est intégré dans le système de base de données DBS. Il fait partie intégrante des fonctionnalités qu'il peut offrir et l'invention est alors une évolution possible des systèmes de gestion de base de données existants. Dans les deux cas, la base de données DB et le système de gestion DBS peuvent appartenir à un même serveur fonctionnel S. Ce serveur fonctionnel S peut bien évidemment être mis en oeuvre de différentes façons. Il peut par exemple s'agir d'un seul serveur physique (c'est-à-dire d'un ordinateur), ou bien de plusieurs ordinateurs : notamment le système de gestion DBS peut être déployé sur une machine différente de celle sur laquelle est déployée la base de données DB. Il peut également être prévu de déployer la base de données (et le système de gestion DBS) sur une pluralité de machines reliées en réseau. Cette pluralité de machines connectées peut même former une ferme d'ordinateurs. D'autres mises en oeuvre sont bien évidemment possibles. Les requêtes R2 transmises à la base de données et les réponses Al reçues de celle-ci sont conformes à un langage d'interrogation structuré tel que le langage SQL (pour « Structure Query Language » en langue anglaise) qui est normalisé à la fois par l'ISO (International Standard Organization) et par l' ANSI (American National Standards Institute). Les requêtes R1 émises par l'utilisateur U, et les réponses qui lui sont transmises A2 peuvent également être conformes à ce langage SQL, mais elles peuvent aussi être conformes à d'autres langages ou protocoles, de sorte que le dispositif D ait une autre fonctionnalité d'interfaçage et traduction de protocoles. Cet aspect étant en dehors du spectre de l'invention, il ne sera pas davantage décrit. Le dispositif D peut effectuer un traitement sur des données transmises par un échange entre l'utilisateur U et la base de données DB en fonction de règles mémorisées dans un fichier de configuration CF. Le fichier de configuration CF peut contenir plusieurs règles. Le contenu de l'échange peut permettre d'identifier une ou plusieurs règles au sein du fichier de configuration CF. Une règle indique à la fois la ou les données de l'échange qui doivent être traitées ainsi que la façon dont elles doivent être traitées. Le fichier de configuration CF peut être un fichier contenant du texte de sorte que les règles puissent être lisible, ajoutées et modifiées par un utilisateur averti. Elles peuvent répondre à une syntaxe simple et non ambiguë permettant à la fois leur interprétation par le dispositif D et leur compréhension rapide par les utilisateurs chargés de les écrire et de les maintenir. Un exemple de syntaxe possible peut être : , . = : Le premier élément de cette règle indique si la règle concerne un prétraitement (« in ») ou un post-traitement (« out »). Autrement dit, il indique si le traitement est effectué pour une requête ou pour une réponse. Le deuxième élément indique une table de la base de données DB Le troisième élément indique un champ de la table en question. Ces trois premiers éléments (avant le signe «= ») permettent d'identifier quelles données des requêtes et réponses doivent être modifiées. Un traitement est effectué si le contenu de l'échange (requête ou réponse) concerne cette table et ce champ. Le quatrième et le cinquième éléments permettent d'indiquer quel traitement doit être appliqué, c'est-à-dire comment les données en question doivent être traitées. Le quatrième élément indique une fonction visant à traiter les données indiquées. Le cinquième élément indique d'éventuels paramètres de la fonction permettant de préciser son comportement et la façon dont elle traite les données. Lorsque le dispositif D reçoit un message, qu'il s'agisse d'une requête R1 ou d'une réponse Al, il consulte le fichier de configuration afin de déterminer un ensemble de règles à appliquer. Si le message est une requête R1, uniquement les règles dont le premier élément vaut « in » sont considérées. Ces règles indiquent les prétraitements qui sont effectués par le dispositif au début de l'échange, soit avant que la requête éventuellement modifiée R2 soit effectivement transmise à la base de données. Ce prétraitement impacte donc les données d'une requête préalablement, notamment, à leur insertion dans la base. Ces prétraitement peuvent être de diverses natures mais ils peuvent notamment mettre en forme des données afin qu'elles soient insérées de façon cohérente dans la base de données. Il peut également s'agir d'encoder ou d' encrypter des données, etc. Les requêtes R1 sont typiquement des requêtes impliquant une insertion ou modification de données dans la base de données DB : INSERT... Si le message est une réponse Al, uniquement les règles dont le premier élément vaut « out » sont considérées. Ces règles indiquent les post-traitements qui sont effectués par le dispositif à la fin de l'échange, soit après que la réponse Al soit effectivement émise par la base de données. Ce post-traitement impacte donc les données d'une réponse préalablement à leur transmission à l'utilisateur. Ces post-traitement peuvent être de diverses natures mais ils peuvent notamment mettre en forme des données afin qu'elles soient présentées à l'utilisateur sous une certaine forme. Il peut également s'agir décoder ou décrypter des données, etc. Parmi les fonctions possibles qui peuvent s'appliquer à des données d'une requête R1 ou d'une réponse Al, on peut mentionner : - « vérification-données », permettant de vérifier que les données respectent des critères fournis en paramètres ; - « encoder mot-de-passe », permettant d'encoder un mot de passe ; - « décoder mot-de-passe, permettant de décoder un mot de passe ; - « décoder champ-de-bit », permettant de décoder un champ de bits ; - « encoder champ-de-bit », permettant d'encoder un champ de bits ; « Modifier sortie », permettant de modifier la sortie d'un champ, c'est-à-dire comment la valeur de ce champ est transmis à l'utilisateur. « mettre majuscule », « mettre minuscule », permettant de changer la casse de la valeur d'un champ. Bien évidemment, le mécanisme proposé est ouvert à la mise en place de bien d'autres fonctions. Les fonctions « encoder champ-de-bit » et « décoder champ-de-bit » permettant de gérer des champs de tables dont la valeur est sous la forme d'un champ de bits. Ce format est très pratique et utilisé pour mémoriser certains types d'information, mais il est peu parlant pour un utilisateur U humain. Si l'on veut afficher une donnée mémorisée en champ de bit ou bien si on veut insérer une donnée en ce format. On considère un exemple d'une base de données DB comportant une table « equipment port » mémorisant des ports d'équipements d'un réseau de communication. Cette table comporte plusieurs champs : par exemple, une clé « Id », un champ « nom » et un champ « type ». Ce champ « type » est dans un format « champ de bits » et indique les différents types correspondant à ce port (Ethernet 1G, Ethernet 100M...). Le fichier de configuration CF contient notamment les deux lignes suivantes, qui définissent deux règles : in.equipment port.type=encoder champ-de-bit out.equipment port.type=decoder champ-de-bit La première règle indique que lorsqu'une requête (INSERT notamment) vise à modifier le champ « type » de cette table « equipment port », la fonction « encoder champ-de-bit » doit être appliquée. Cela permet ainsi à l'utilisateur d'entrer des données sous une forme claire pour lui (« Ethernet 1G ») sans avoir à se préoccuper du format interne à la base de données. La seconde règle indique que lorsqu'une réponse contient ce champ « type » (par exemple à la suite d'une requête de lecture de données comme « SELECT »..), la fonction « décoder champ-de-bit » est appliquée à la valeur du champ. On suppose que le contenu du champ « Type » de la table « Equipment port » a pour valeur le champ de bits suivant : 1000000000000000011100000000000000000000000000000000000000000000 1000000000000000011000000000000000000000000000000000000000000000 1000000000000000011100000000000000000000000000000000000000000000 Cette valeur est retournée par la base de données DB dans une réponse Al correspondant à une requête R1 de type « SELECT ». Elle serait retournée par la réponse A2 à l'utilisateur U en l'absence de la ligne appropriée dans le fichier de configuration. Si l'utilisateur U est un utilisateur humain utilisant une console d'interrogation, cette valeur lui est peu parlante et en tout cas nécessite un effort d'interprétation. Grâce au dispositif D et à la ligne appropriée insérée dans le fichier de configuration, la valeur du champ « Type » est modifiée dans la réponse modifiée A2. Cette valeur est « décodée » et peut valoir : Eth.1G Eth.100M Eth.1G Dans un autre exemple, on suppose que le fichier de configuration CF contient la ligne suivante : in.equipment port status.value=verification données:status,defined values30 Le premier élément de cette règle indique que la règle concerne un prétraitement : elle concerne donc les requêtes R1 (et non pas les réponses Al). Le deuxième élément indique une table « equipment port status » de la base de données DB, et le troisième élément indique un champ « value » de la table en question. Le quatrième élément indique une fonction « vérification données » visant à effectuer un traitement sur les données indiquées, c'est-à-dire la valeur du champ « value ». Ce traitement n'entraine pas de modification des données mais vérifie que les données correspondent à des critères passés en paramètres dans le cinquième élément « status.defined values ». Ce cinquième élément identifie une table « status » et un champ « defined values » de cette table. La fonction « vérification données » contrôle si les données contenues dans le champ « value » de la table « equipment port status » correspond aux valeurs indiquées dans le champ « defined values » de la table « status ». Il est ainsi possible d'indiquer des valeurs auxquels sont comparées les valeurs à insérer dans la base de données. Cela peut permettre par exemple de préciser un ensemble de valeurs possibles qui peuvent être prises par un champ. Si une valeur indiquée pour ce champ dans une requête en insertion est transmise, une erreur peut être générée et l'insertion peut être abandonnée. On peut également noter que le dispositif D permet ainsi de comparer non seulement la valeur d'un champ à une valeur de paramètre, mais aussi de comparer la valeur de deux champs, et même, comme dans l'exemple, la valeur de deux champs appartenant à deux tables différentes. Il s'agit là bien évidemment d'un avantage supplémentaire de l'invention qui permet ainsi d'offrir une fonctionnalité nouvelle et riche en possibilités. Bien entendu, la présente invention n'est pas limitée aux exemples et au mode de réalisation décrits et représentés, mais elle est susceptible de nombreuses variantes accessibles à l'homme de l'art. REVENDICATIONS1. Procédé d'interrogation d'une base de données relationnelles (DB) consistant à effectuer un traitement sur certaines données transmises par un échange de messages entre un utilisateur et ladite base de données relationnelle constitué d'une requête et d'une réponse, ledit traitement étant effectué en séquence dudit échange et en fonction de règles mémorisées dans un fichier de configuration et identifiées par le contenu dudit échange. 2. Procédé selon la revendication précédente dans lequel lesdites règles indiquent si ledit traitement est effectué pour ladite requête ou pour ladite réponse. 3. Procédé selon l'une des revendications précédentes, dans lequel lesdites règles indiquent une table et un champ de ladite base de données et dans lequel ledit traitement est effectué si ledit contenue concerne ladite table et ledit champ. 4. Procédé selon l'une des revendications précédentes, dans lequel lesdites règles indiquent une fonction visant à traiter lesdites certaines données. 5. Programme d'ordinateur comprenant des instructions qui, une fois chargées sur un système de traitement de l'information, sont aptes à mettre en oeuvre le procédé selon l'une des revendications 1 à 4. 6. Dispositif pour l'interrogation d'une base de données relationnelles (DB) comportant des moyens pour effectuer un traitement sur certaines données transmises par un échange de messages entre un utilisateur (U) et ladite base de données relationnelle constitué d'une requête et d'une réponse, ledit traitement étant effectué par ledit dispositif (D) en séquence dudit échange et en fonction de règles mémorisées dans un fichier de configuration (CF) et identifiées par le contenu dudit échange. 7. Dispositif selon la revendication précédente adapté pour effectuer ledit traitement en fonction desdites règles qui indiquent si ledit traitement est effectué pour ladite requête ou pour ladite réponse. 8. Dispositif selon l'une des revendications 6 ou 7, dans lequel lesdites règles indiquent une table et un champ de ladite base de données et dans lequel ledit traitement est effectué si ledit contenu concerne ladite table et ledit champ. 9. Dispositif selon l'une des revendications 6 à 8, dans lequel lesdites règles indiquent une fonction visant à traiter lesdites certaines données. 10. Dispositif selon l'une des revendications 6 à 9, adapté pour s'interfacer avec un système de gestion de base de données.15