Brevet FR3006787A1 — publié le 20141212

852-FR-014146-patentapplication-final 1 PROCÉDÉ ET DISPOSITIF POUR L'INTERROGATION FACILITÉE D'UNE BASE DE DONNÉES RELATIONNELLES 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. La figure 1 illustre une architecture haut-niveau typique de mise en oeuvre d'une base de données relationnelle. 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 S. 852-FR-014146-patentapplication-final 2 D'un point de vue fonctionnel, ce système de gestion de bases de données DBS peut se décomposer schématiquement en une interface d'accès aux données AI et une interface de traitement des requêtes RI. L'interface d'accès aux données AI vise à gérer les spécificités physiques d'implémentation de la base de données DB, par exemple à gérer les aspects de redondances, la répartition sur des machines serveurs distantes et éventuellement multiples, à gérer les différents protocoles d'accès possibles, à gérer les éventuels accès concurrents, etc. L'interface de traitement des requêtes RI permet d'assurer une interface unifiée à l'utilisateur U, quel que soit la base de données DB sous- j acente. Cette interface permet classiquement d'interroger la base par des requêtes Rq et de recevoir des réponses Rp. L'interrogation est généralement conforme à 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, son utilisation reste difficile car elle nécessite une bonne connaissance de la topologie de la base de données sous-jacente DB, c'est-à-dire du nom des tables et des liens qui existent entre les tables. Certaines base de données DB peuvent être très complexes et comporter un très grand 852-FR-014146-patentapplication-final 3 nombre de tables, et cette connaissance peut être difficile à acquérir et demande un investissement préalable pour l'utilisateur U. En outre, même bon connaisseur de la structure topologique de la base de données DB, si celle-ci est au moins un peu complexe, l'interrogation de la base de données DB peut nécessiter plusieurs requêtes en SQL. Le processus est donc fastidieux, long et donc coûteux dans le cadre d'une utilisation industrielle ou professionnelle. En outre, il peut en résulter un risque d'erreurs non-négligeable, notamment un risque d'oublier de renseigner un champ dans une requête. 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. À cette fin, la présente invention propose un procédé d'interrogation d'une base de données relationnelle consistant à interpréter une commande pour générer un ensemble de requêtes en langage SQL destinées à un système de gestion de ladite base de données, dans lequel ladite commande est conforme à une grammaire distincte du langage SQL et dans lequel lesdites requêtes sont générées en fonction de la structure de ladite base de données relationnelle. 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 : ladite commande est prévue pour ajouter des données au sein de ladite base de données relationnelle et comporte au moins un objet, ledit au moins un objet comportant un type et une liste de champs associée audit type, ledit type correspondant à une table de ladite 852-FR-014146-patentapplication-final 4 base de données et chacun desdits champs correspondant à un champ de ladite table ; une affectation d'une valeur à un champ d'un premier objet est automatiquement réutilisée pour un champ d'un second objet, lesdits premier et second objets appartenant audit au moins un objet ; une valeur est affectée à un champ de ladite base de données en fonction d'indications fournies par des fichiers de configuration associés audit dispositif, lesdites indications précisant un mécanisme pour déterminer ladite valeur. 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 relationnelle consistant à interpréter une commande pour générer un ensemble de requêtes en langage SQL destinées à un système de gestion de ladite base de données, dans lequel ladite commande est conforme à une grammaire distincte du langage SQL et interprétée à l'aide d'un ensemble de fichiers de configuration. 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 dispose d'un module de traitement de commandes pour recevoir ladite commande prévue pour ajouter des données au sein de ladite base de données relationnelle et comportant au moins un objet, ledit au moins un objet comportant un type et une liste de 852-FR-014146-patentapplication-final champs associée audit type, ledit type correspondant à une table de ladite base de données et chacun desdits champs correspondant à un champ de ladite table ; le dispositif dispose des moyens pour réutiliser automatiquement une 5 affectation d'une valeur à un champ d'un premier objet pour un champ d'un second objet, lesdits premier et second objets appartenant audit au moins un objet ; une valeur est affectée à un champ de ladite base de données en fonction d'indications fournies par des fichiers de configuration associés audit dispositif, lesdites indications précisant un mécanisme pour déterminer ladite valeur ; le dispositif comporte en outre un module de génération pour traiter un premier fichier de configuration desdits fichiers de configuration et générer un second fichier de configuration interprétable par ledit module de traitement de commandes. 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 d'un système de gestion, conformément à l'état de la technique. La figure 2 représente schématiquement une architecture fonctionnelle d'un système composé d'une base de données et d'un système de gestion de la base de données, conformément à l'invention. La figure 3 illustre un exemple de structure d'une base de données relationnelle. 852-FR-014146-patentapplication-final 6 La figure 4 représente schématiquement une architecture fonctionnelle d'un système composé d'une base de données et d'un système de gestion, conformément à une mise en oeuvre de l'invention. La figure 5 illustre un exemple de structure d'une base de données relationnelle. DESCRIPTION DETAILLEE DE L'INVENTION La figure 2 représente une mise en oeuvre possible de l'invention dans lequel un dispositif D a été inséré entre le système de gestion DBS d'une ou plusieurs bases de données DB et le ou les utilisateurs U. À travers ce dispositif D, l'utilisateur U peut accéder à la base de données DB via le système de gestion de bases de données DBS. 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. D'un point de vue fonctionnel également, ce système de gestion de bases de données DBS peut se décomposer schématiquement en une interface d'accès aux données AI et une interface de traitement des requêtes RI. 852-FR-014146-patentapplication-final 7 L'interface d'accès aux données AI vise à gérer les spécificités physiques d'implémentation de la base de données DB, par exemple à gérer les aspects de redondances, la répartition sur des machines serveurs distantes et éventuellement multiples, à gérer les différents protocoles d'accès possibles, à gérer les éventuels accès concurrents, etc. L'interface de traitement des requêtes RI permet d'assurer une interface unifiée à l'utilisateur U, quel que soit la base de données DB sous-jacente. Cette interface permet classiquement d'interroger la base par des requêtes Rq et de recevoir des réponses Rp. L'interrogation est généralement conforme à 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). En pratique, les interfaces d'accès aux données AI et de traitement des requêtes RI peuvent être mises en oeuvre par des modules logiciels distincts du système de gestion DBS ou bien être intégrées au sein d'un même module logiciel. L'architecture du serveur fonctionnel S comprenant la base de données DB et le système de gestion DBS peut être conforme aux différentes solutions proposées par l'état de la technique et donc différentes mises en oeuvre sont accessibles à l'homme du métier. Un aspect de l'invention concerne ce dispositif D pour l'interrogation d'une base de données relationnelle DB. Il peut être réalisé de différentes façons et notamment il peut être déployé sur une même machine que le système de gestion DBS ou bien sur une machine distincte. Ce dispositif permet de présenter aux utilisateurs U une interface différente du langage SQL et peut ainsi agir comme un interpréteur de plus haut niveau : l'utilisateur peut transmettre des commandes M conforme à une grammaire donnée, distincte du langage SQL, le dispositif D dispose 852-FR-014146-patentapplication-final 8 des moyens logiciels pour interpréter ces commandes et générer un ensemble de requêtes SQL destinées au système de gestion DBS. Cette interprétation peut notamment se faire à l'aide d'un ensemble de fichiers de configuration CF. L'ensemble de fichiers de configuration, de même que l'ensemble de requêtes SQL Rq peuvent éventuellement se réduire à des singletons. Toutefois, un des avantages de l'invention est de permettre à l'utilisateur U de rédiger une commande unique possédant le même effet qu'une pluralité de requêtes SQL. Elle permet ainsi de simplifier la tâche de l'utilisateur U et en outre d'éviter des erreurs inhérentes à l'écriture de requêtes SQL complexes et nombreuses. Selon un mode de réalisation de l'invention, la grammaire permet de spécifier un ou plusieurs objets dans une commande M. Pour quelque objet, il est possible d'indiquer un type et de lui associer une liste de champs. La commande M peut par exemple être interprétée d'abord par une application logicielle de type « Shell » sur un système d'exploitation de la famille Unix. En ce cas, elle peut comporter un mot-clé permettant à cette application « shell » d'identifier le dispositif D et de lui transmettre la commande M reçue. En outre, le dispositif D peut mettre en oeuvre différents mécanismes y compris des mécanismes distincts de ceux de l'invention. Aussi, la commande M peut comporter un mot-clé permettant d'identifier ces mécanismes. Une telle commande peut par exemple avoir pour forme : Commande ajoute objetl, objet2, objet3... Le mot-clé « commande » permet d'indiquer qu'il s'agit d'une commande adressée au dispositif D. 852-FR-014146-patentapplication-final 9 Le mot clé « ajoute » indique qu'il s'agit d'une commande d'ajouts de données dans la base de données relationnelle DB. Il permet de mettre en oeuvre les mécanismes de l'invention. La commande M comprend ensuite au moins un objet, objetl, objet2, objet3... Ces objets permettent de préciser les données qui doivent être ajoutées au sein de la base de données DB. Ils peuvent comporter un type et une liste de champs associée à ce type. Une syntaxe possible est par exemple sous la forme suivante : Type=(champsl, champs2, champs3...) Le type permet d'identifier une table dans la base de données DB. Les champs correspondent aux champs (ou colonne) de cette table. Un champ de la commande peut contenir le nom du champ de la table et soit une valeur, soit un filtre. Un champ peut donc selon une des formes suivantes : Nom champ=valeur Nom champ,[filtre] Les crochés droits peuvent ainsi permettre d'indiquer qu'on a affaire à un filtre et non à une valeur. Un filtre permet sélectionner un ou plusieurs enregistrements dans la base de données DB. Par exemple, le champ suivant equipement,[nom=node*] signifie que l'on souhaite sélectionner l'ensemble des équipements dont le champ « nom » a une valeur commençant la chaîne de caractères « node ». La figure 3 montre un exemple de structure de la base de données DB, contenant 7 tables, Ti, T2, T3, T4, T5, T6, T7. Chaque table est identifiée par un nom (indiqué dans la zone grisée en haut de chaque table) et comporte plusieurs champs (ou lignes, indiquées au-dessous). Des symboles en forme de clés indiquent les clés pour chaque 852-FR-014146-patentapplication-final 10 table. Les tables sont liées entre elle de façon classique en soi dans une base de données relationnelle. Dans le cadre de cet exemple, on suppose que la table « Type » comporte déjà les enregistrements suivants : TypeAvion Capacité IdConstructeur A340 200 2 A320 400 2 B747 500 1 B787 250 1 On suppose également que la table « Constructeur » comporte également les enregistrements correspondant aux clés primaires 1 et 2 (respectivement avec pour valeur de NomConstructeur, Airbus et Boeing). On suppose également que l'on souhaite créer un nouvel aéroport, « Strasbourg Entzheim », lui assigner les avions de la série A300 (c'est-à- dire A320, A340...), et lui assigner deux vols, un en provenance de Paris et un à destination de Paris. Une commande possible peut être : Commande ajouter aeroport=(nom=SXB, NomVilleDesservie=StrabourgEntzheim), avion,(avion,[typeAvion=A31), vol=(AéroportDépart=SXB, heureDépart=1230, heureArrivée=1500, AeroportArrivee=ORY), vol=(AéroportDépart=ORY, heureDépart=1630, heureArrivée=1800, aeroportArrivée=SXB) Cette commande comporte donc un premier objet concernant le type « Aéroport ». Ce type correspond à la table « Aéroport » et il est associé à la liste de champs placés entre parenthèses. Dans ce premier objet, deux champs sont présents qui contiennent un nom de champs et une valeur. Le dispositif D peut vérifier s'il manque des champs obligatoires pour le type / table « Aéroport ». En effet, le dispositif D peut traiter la 852-FR-014146-patentapplication-final 11 commande M en fonction de la structure de la base de données relationnelle. Selon l'invention, en effet, le dispositif maintient une connaissance de la structure de la base DB afin de pouvoir interpréter les commandes M sans que celles-ci (et donc l'utilisateur M) ait besoin de les faire correspondre exactement à cette structure : le dispositif permet donc de faire une médiation intelligente afin de « masquer » la structure de la base. Ce n'est pas le cas ici : tous les champs sont bien présents. Si un champ obligatoire était manquant, le dispositif peut être prévu pour réutiliser une affectation d'une valeur à un champ d'un autre objet pour ce champ. Selon une mise en oeuvre, le dispositif va rechercher dans les objets précédents au sein de la commande M si ce champ a déjà été renseigné (par une valeur ou par un filtre). Autrement dit, chaque affectation d'une valeur ou d'un filtre à un champ donné est conservée en mémoire par le dispositif D afin de pouvoir être utilisée de nouveau pour un objet suivant. Ce mécanisme permet aux utilisateurs U de ne pas avoir à indiquer plusieurs fois une même donnée, contrairement à ce qui est nécessaire lorsqu'on doit écrire des requêtes en langage SQL. Cet avantage apparaîtra plus clairement plus loin. Le premier objet peut générer une requête en langage SQL suivante : INSERT INTO aeroport (NomAéroport, NomVilleDesservie) SELECT ' S XB ' , ' S trasb ourgEntzheim' Le second objet, « avion,(avion4typeAvion,A31) » permet de peupler la table « Avion ». Un filtre a été précisé pour le champ « typeAvion » afin de sélectionner l'ensemble des types d'avions dont le nom de type commence par la chaîne de caractères « A3 ». Par conséquent, deux « avions » sont 852-FR-014146-patentapplication-final 12 ajoutés dans la table « Avion », un pour le type « A320 » et un pour le type « A340 ». Le dispositif vérifie si les champs obligatoires sont tous présent dans l'objet correspondant. Ici, le champ « BaseAéroport » est absent. Toutefois, l'aéroport a été mentionné dans l'objet précédent. Selon le mécanisme précédemment décrit, cette assignation peut être ici réutilisée afin d'affecter la valeur « SXB » au champ « BaseAéroport ». Une requête en langage SQL de la forme suivante pour être alors générée : INSERT INTO avion (TypeAvion, BaseAeroport) SELECT tO.TypeAvion, '56' FROM type tO WHERE typeAvion='A3%%" Comme précédemment, le dispositif D peut utiliser sa connaissance de la structure de la base de données DB afin générer une telle requête. Cette connaissance peut être partiellement préalable à la réception de la commande M (notamment sur la structure topologique) mais aussi réactualisée et complétée lors de la réception de chaque commande M (notamment sur le contenu de la base DB). Ainsi, le dispositif génère automatiquement une requête SQL prévue pour rechercher les informations et créer la liaison avec la table « Type ». Ceci est effectué de façon transparente pour l'utilisateur U. De même, la clé étrangère « 56 » correspondant au champ « BaseAeroport » est automatiquement assignée par le dispositif D. Elle correspond à la clé primaire de l'enregistrement associé à l'aéroport de nom « SXB ». Cette clé peut être retrouvée par une requête simple dans la base DB ou bien elle a été mémorisé lors de l'ajout de l'aéroport « SXB » dans la base. Les deux objets suivants concernent le type « Vol ». Deux vols sont ajoutés et le dispositif D peut générer deux requêtes en langage SQL : 852-FR-014146-patentapplication-final 13 INSERT INTO vol (aeroportDepart, AerorportArrivee, HeureDepart, HeureArrivee) SELECT `SXB', 'ORY"1230', '1500'. INSERT INTO vol (aeroportDepart, AerorportArrivee, HeureDepart, HeureArrivee) SELECT 'ORY, `SXB"1800', '1930' Dans le cas où une requête omet un champ obligatoire mais que celui-ci ne peut pas être retrouvé sur la base des objets précédents de la requête, il est possible de générer un message d'erreur pour l'utilisateur U. Le dispositif D peut alors interrompre le traitement ou bien inviter l'utilisateur à indiquer la valeur (ou le filtre) pour le champ manquant et, une fois celui-ci renseignée, poursuivre le traitement. En outre, il peut être prévu de mettre en oeuvre un système d'acronyme afin de faciliter encore davantage l'utilisation de l'invention. Les fichiers de configuration CF peuvent en effet contenir une table mettant en correspondance un acronyme avec une table ou un champ de la base de données. La commande C peut alors faire mention des acronymes à la place des noms de tables ou de champs, et le dispositif D peut utiliser la table de correspondance contenue dans les fichiers de configuration CF pour générer les requêtes SQL avec les noms correspondants à ces acronymes. Ainsi, le dispositif D peut permettre de proposer une vue plus abstraite de la base à l'utilisateur U : les noms sont dépendants du concepteur de la base de données DB et ne sont pas forcément très parlants et pratiques pour l'utilisateur U. Celui-ci peut définir dans un fichier de configuration ces acronymes notamment pour les tables et champs qu'il utilise le plus souvent. Il peut ainsi écrire des commandes M plus rapidement, plus efficacement et avec bien moins de risques d'erreurs. Par conséquent, un type au sein d'une commande M correspond à une table de la base de données mais cette correspondance peut être 852-FR-014146-patentapplication-final 14 indirecte et passer par l'utilisation d'une table de correspondance ou par d'autres mécanismes d'indirection. Il en va de même pour la correspondance entre les champs associés aux types dans la commande M et les champs des tables de la base de données DB. Un second mode de réalisation de l'invention consiste à faire usage de fichiers de configuration CF préalablement élaborées d'une façon particulière pour interpréter les commandes M et générer les commandes en langage SQL, Rq. Notamment, ces fichiers de configuration peuvent être utilisés pour permettre de décider d'un comportement à adopter en cas d'absence d'affectation d'une valeur à un champ pour un objet donné. Il peut alors être indiqué au sein de ces fichiers de configuration CF de demander à l'utilisateur d'indiquer la valeur pour le champ manquant, ou bien une méthode pour déterminer automatiquement cette valeur. Selon un mode de réalisation, lorsqu'un champ d'un objet n'est pas renseigné dans la commande et que ce champ est toutefois obligatoire, afin de ne pas introduire d'incohérence dans la base de données DB, le dispositif D peut être prévu pour - réutiliser une affectation d'une valeur dans un autre objet pour ce champ, ainsi qu'il a été décrit précédemment. Utiliser les indications fournies par les fichiers de configuration pour déterminer cette valeur. Ces deux options peuvent être mises en oeuvre en séquence par le dispositif D de sorte que les indications des fichiers de configuration ne sont utilisés qu'en l'absence de la fourniture d'une valeur de ce champ dans l'ensemble des objets de la commande M. Les indications fournies par les fichiers de configuration CF permettent de préciser un mécanisme pour déterminer ladite valeur. 852-FR-014146-patentapplication-final 15 Ces indications peuvent être déterminées à partir d'autres fichiers de configuration et de la structure de la base de données DB. Le dispositif D peut donc avoir deux fonctions distinctes : la génération de ces indications et la génération des requêtes SQL. Ces deux fonctions peuvent être mises en oeuvre par deux modules fonctionnels du dispositif D, ainsi qu'indiqué sur la figure 4. Ces deux modules peuvent être des programmes d'ordinateurs distincts ou bien deux modules d'un même programme d'ordinateur. Un module de génération MI permet de générer les indications dans un (ou plusieurs) premiers fichiers de configuration CFI à partir d'un (ou plusieurs) seconds de fichiers de configuration CFO et de la structure de la base de données DB. La figure 5 montre un exemple de structure de la base de données DB, contenant 5 tables, Ti, T2, T3, T4, T5. Cet exemple est simpliste puisque ne comportant qu'un petit nombre de tables mais il permet de comprendre clairement les mécanismes mis en jeu par l'invention. Il peut s'appliquer à une base de données pour un commerce d'articles. Chaque article appartient à une catégorie d'articles (par exemple une marque, une série...). La base de données permet de stocker également les commandes d'articles. Une commande met en correspondance un article et une personne : la table « Correspondance » comporte donc des clés étrangères de la table « Article » et de la table « Personne », ainsi qu'une quantité et qu'un prix. Enfin, une table « Transaction » est ajoutée ; une transaction peut référencer plusieurs commandes d'articles. Un premier fichier de configuration CFO peut être tel que ci-dessous :30 852-FR-014146-patentapplication-final 16 Personne.CommandeArticle.recherche.type=intelligente Personne.CommandeArticle.recherche.valeur=identique(Personne.nom=Def ault) Personne.défaut=nom:Nom,prenom:Prenom,login:Nom- Prenom,mot pas s:0000 CommandeArticle.Articlesecherche.type=intelligente CommandeArticle.Articlesecherche.valeur=plus présent(CommandeArticle .id article) CommandeArticle.Transaction.recherche.type=intelligente CommandeArticle.Transaction.recherche.valeur=évalue(id article, quantité) CommandeArticle.Personne.recherche.type=intelligente CommandeArticle.Personne.recherche.valeur=identique(Personne.nom=No m) CommandeArticle.défaut=quantite:0,prix commande:0 Trans action.CommandeArticle.recherche.type=intelligente Trans action.CommandeArticle.recherche.v aleur=plus récente() Trans action.défaut=prix transaction:100,date:01/01/2001 Article.Catégorie.recherche.type=intelligente Article.Catégorie.recherche.valeur=identique(nom catégorie=Défaut) Article.défaut=nom article:Article,prix unitaire:100,description:aucune Catégorie.Article.recherche.type=intelligente Catégorie.Article.recherche.valeur=identique Catégorie.nom catégorie=test) Catégorie.défaut=nom catégorie=test,description: aucune,unite: aucune Ce fichier de configuration CFO peut être écrit une fois pour toute par un utilisateur de la base données, mais peut être modifié facilement à tout moment. 11 s'agit d'un avantage de l'invention de pouvoir facilement modifier ce fichier de configuration sans avoir à toucher au contenu ou à la structure de la base de données DB. 852-FR-014146-patentapplication-final 17 Ce fichier de configuration CFO permet notamment de préciser au moyen d'indications le mécanisme à mettre en oeuvre pour déterminer une valeur de champs manquante. Ces indications sont introduites, dans cet exemple d'implémentation, selon la grammaire suivante : Table.champ.recherche.X=valeur Pour chaque table, on peut ainsi indiquer un comportement distinct en fonction des champs. Le mot-clé « recherche » introduit les indications en question. Le caractère «X » indique que plusieurs indications sont possibles. Dans l'exemple ci-dessus, ces indications sont « type » et « valeur ». L'indication « Type » indique le type de comportement à adopter pour rechercher la valeur. Elle permet de préciser s'il s'agit d'interroger l'utilisateur en mode interactif ou bien, comme ici avec le mot-clé « intelligente », s'il s'agit de déterminer automatiquement cette valeur, ou bien d'autres comportements encore. L'indication « Valeur » permet de préciser comment la valeur doit être déterminée. Elle n'est pas utile dans le mode « interactif » mais permet, dans le mode « intelligent » d'indiquer plusieurs possibilités pour déterminer automatiquement la valeur. Par exemple, des mots-clés représentants des fonctions peuvent être intégrés dans la grammaire afin de permettre d'indiquer des comportements riches. Par exemples : « identique(diltre>) » permet de sélectionner un élément de la table selon le filtre donné. « plus présent( ) » : sélectionne l'élément le plus présent dans la colonne donnée « utilise existant( , ) » : utilise un élément déjà existant dans la table donnée en entrée 852-FR-014146-patentapplication-final 18 « copie( , , ) » :copie d'un élément existant dans la table en changeant quelque chose conformément à ce qui a été donné dans « disponible( , ) » : liste les éléments d'une table avec un filtre si besoin (mettre à NULL si non nécessaire) Il est également possible d'indiquer des valeurs par défaut pour la création d'un nouvel enregistrement d'une table selon la grammaire : Table.defaut=valeurl, valeur2... Cette valeur par défaut peut être utilisée si le comportement choisi est un mode « par défaut », ou bien si la recherche déclenchée par le comportement « intelligent » n' aboutit pas. Ce premier fichier de configuration CFO peut être traité par le module MI du dispositif D. Ce module MI va générer des indications interprétables par le module de traitement de commande MR du dispositif D. Ces indications interprétables sont insérées dans des seconds fichiers de configuration CFI. Ceux-ci peuvent par exemple être conformes à une grammaire XML (« eXtensible Markup Language »), standardisé par le W3C (World Wide Web Consortium). La génération de ces indications est effectuée également à partir de la connaissance de la structure de la base de données DB que possède (ou acquiert à la demande) le module de génération MI du dispositif D. Il peut être généré un fichier (ou une partie de fichier) de configuration CFI pour chaque table de la base de données, ou tout du moins pour chaque table « principale » de la base de données : l'utilisateur peut indiquer les tables pour lesquelles il souhaite que soit généré un fichier de configuration CFI. Pour une table donnée, le module MI récupère les champs de la table à partir de sa connaissance de la base de données DB et utilise le premier 852-FR-014146-patentapplication-final 19 fichier de configuration CFO pour générer des lignes (en XLM) du second fichier de configuration CFI. Puis, de façon récursive, il traite de la même façon, les tables de la base qui sont liées à cette première table. La grammaire du fichier généré peut par exemple être alors sous la forme suivante : A quel table2 voulez-vous lier ce tablel ? le plus présent disponible( , ) colonnel,xxx,colonne2=yyy,colonne3=zzz Le terme « occurrence » représente le nombre d'éléments pouvant être ajoutés à la table (ce chiffre est soit 1 si c'est la table courante qui contient la clé qui pointe vers une autre table, soit multiple si c'est une clé d'une autre table qui pointe sur la table courante) Le terme « obligatoire » indique si le champ est obligatoire ? (s'il ne l'est pas, alors il ne sera pas ajouté s'il n'y a pas de méthode de recherche précisé). Le terme « fk » est la clé étrangère vers laquelle la table initiale pointe Le terme « pk » est la clé primaire de la table pointée Le terme « sortie » est la colonne à afficher, s'il faut afficher une colonne du nouvel élément ajouté (il peut y en avoir plusieurs). 852-FR-014146-patentapplication-final 20 Le terme « interactif » indique la question à poser à l'utilisateur si l'on est dans le mode interactif. Le terme « recherche » indique la méthode de recherche du champ à ajouter (non utilisé en cas de mode interactif). Le terme « disponible » indique les éléments montrés à l'utilisateur en cas de mode interactif pour l'aider à connaître les éléments disponibles (par défaut l'algorithme recherche le plus présent dans la table). Enfin le terme « défaut » indique une valeur par défaut des colonnes (si applicable) Ainsi, pour l'exemple donné ci-dessous, un fichier de configuration CFI en langage XML peut être : A quel Article voulez-vous lier CommandeArticle ? plus présent(CommandeArticle.id article ) disponible(Article, NULL) A quel Transaction voulez-vous lier CommandeArticle ? évalue(id article, quantité) disponible(Transaction, NULL) 852-FR-014146-patentapplication-final 21 A quel Personne voulez-vous lier CommandeArticle ? identique(Personne.nom,Nom) disponible(Personne, NULL) quantité=0,prix commande=0 Ce fichier de configuration CFI peut ensuite être utilisé pour permettre au module MR de gérer les commandes M et générer les requêtes Rq en langage SQL correspondantes. La grammaire de la commande M peut prendre plusieurs formes, mais est distincte de celle du langage SQL. Elle peut être similaire à celle décrite précédemment. L'exemple ci- dessous donne une autre mise en oeuvre de cette grammaire. Dans cet exemple, la commande M est de la forme : Ajouter{ Personne (nom,'Dupont', prénom=' Martin', login,'DupontMartin', mot passe,'0000') CommandeArticle(quantité=' 1') 1 Cette commande M vise à ajouter une personne (c'est-à-dire un client) dans la base de données et, dans le même temps, une commande d'article. Il s'agit-là d'une action typique pour une activité commerciale et le fait de 852-FR-014146-patentapplication-final 22 permettre un ajout simple d'une commande concernant un nouveau client en une seule commande confère un avantage substantiel au mécanisme de l'invention. La commande M comporte deux objets : Un objet introduit par le type « Personne » et avec une liste de champs associés ; Un objet introduit par le type « CommandeArticle » et avec un unique champ associé, « quantité=1 ». Comme précédemment expliqué, ces champs d'objets correspondent directement ou indirectement à des champs des tables correspondant (directement ou indirectement aussi) aux types. Le premier objet est d'abord analyser par le module MR du dispositif D. Ce premier objet vise à ajouter un nouveau client dans la base et les champs passés en paramètres renseignent tous les champs obligatoires de la table « Personne ». Le module de traitement de commandes MR peut donc aisément générer la requête Rq en langage SQL pour ajouter ce client. Le second objet vise à ajouter une nouvelle commande. Le module MR détecte que certains champs obligatoire de la table « CommandeArticle » ne sont pas renseignés. Seul le champ « quantité » a été renseigné, alors que la table doit comporter l'identifiant (ou clé) d'une personne (un client), d'un article, et d'une transaction, ainsi que le prix. Comme il a été mentionné plus haut, une valeur manquante de ce champ peut être recherchée dans les autres objets de la commande M, et notamment dans l'objet précédent. Ici, un identifiant (ou clé) de personne a été renseigné par l'objet précédent. Le lien est donc automatiquement effectué par le dispositif D entre le client qui a été ajouté et la commande d'article : la commande 852-FR-014146-patentapplication-final 23 d'article concerne, implicitement, le client qui est ajouté dans la même commande M. Son identifiant est donc utilisé pour renseigner le champ Id personne de la table « CommandeArticle ». Le champ « id article » n'est renseigné dans aucun des objets de la commande M. Le fichier de configuration CFI indique que ce champ est obligatoire (« Article obligatoire=oui ») et un mode intelligent est disponible. Une indication précise que la recherche doit concerner l'article le plus présent : « plus présent(CommandeArticle.id article) » Le dispositif D peut alors effectuer une recherche pour déterminer l'article le plus vendu à partir de la base de données DB et renseigner le champ « id article » à partir du résultat de cette recherche. De même, le champ « id transaction » n'est renseigné dans aucun des objets de la commande M. Le fichier de configuration CFI indique que ce champ est obligatoire (« Transaction obligatoire=oui ») et un mode intelligent est disponible. Une indication précise que la recherche fait appel à une fonction d'évaluation : évalue(id article, quantité) Cette fonction d'évaluation consiste à multiplier la quantité par la valeur « Article.prix unitaire », de l'article identifié par la clé « id article ». Le dispositif D crée alors un nouvel enregistrement dans la table « Transaction » avec pour valeurs de champs, le prix de la transaction ainsi évalué, la date courant et un nouvel identifiant. Ce nouvel identifiant est ensuite utiliser pour renseigner le champ « Id transaction » de la table « CommandeArticle ». De la même façon, le champ « prix commande » est obligatoire et il peut être rempli en utilisant l'évaluation préalablement faite pour le champ « prix transaction ». 852-FR-014146-patentapplication-final 24 Ainsi, un minimum de données et d'actions ont été nécessaire pour l'utilisateur U pour entrer des données complexes dans la base de données DB. En outre, l'automatisation de l'évaluation de valeurs ou la réutilisation automatique de valeurs précédemment déterminées permet de minimiser les risques d'erreurs et d'incohérences. 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 relationnelle (DB) consistant à interpréter une commande (M) pour générer un ensemble de requêtes (Rq) en langage SQL destinées à un système de gestion (DBS) de ladite base de données, dans lequel ladite commande est conforme à une grammaire distincte du langage SQL et dans lequel lesdites requêtes sont générées en fonction de la structure de ladite base de données relationnelle. 2. Procédé selon la revendication 1, dans lequel ladite commande est prévue pour ajouter des données au sein de ladite base de données relationnelle (DB) et comporte au moins un objet, ledit au moins un objet comportant un type et une liste de champs associée audit type, ledit type correspondant à une table de ladite base de données et chacun desdits champs correspondant à un champ de ladite table. 3. Procédé selon la revendication 2, dans lequel une affectation d'une valeur à un champ d'un premier objet est automatiquement réutilisée pour un champ d'un second objet, lesdits premier et second objets appartenant audit au moins un objet. 4. Procédé selon l'une des revendications 2 ou 3, dans lequel une valeur est affectée à un champ de ladite base de données (DB) en fonction d'indications fournies par des fichiers de configuration (CF), lesdites indications précisant un mécanisme pour déterminer ladite valeur. 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.30852-FR-014146-patentapplication-final 26 6. Dispositif (D) pour l'interrogation d'une base de données relationnelle (DB) consistant à interpréter une commande (M) pour générer un ensemble de requêtes (Rq) en langage SQL destinées à un système de gestion (DBS) de ladite base de données, dans lequel ladite commande est conforme à une grammaire distincte du langage SQL et interprétée à l'aide d'un ensemble de fichiers de configuration (CF). 7. Dispositif selon la revendication 6, disposant d'un module de traitement de commandes (RM) pour recevoir ladite commande (M) prévue pour ajouter des données au sein de ladite base de données relationnelle (DB) et comportant au moins un objet, ledit au moins un objet comportant un type et une liste de champs associée audit type, ledit type correspondant à une table de ladite base de données et chacun desdits champs correspondant à un champ de ladite table. 8. Dispositif selon la revendication 7, disposant des moyens pour réutiliser automatiquement une affectation d'une valeur à un champ d'un premier objet pour un champ d'un second objet, lesdits premier et second objets appartenant audit au moins un objet. 9. Dispositif selon l'une des revendications 7 ou 8, dans lequel une valeur est affectée à un champ de ladite base de données (DB) en fonction d'indications fournies par des fichiers de configuration (CF) associés audit dispositif (D), lesdites indications précisant un mécanisme pour déterminer ladite valeur. 10. Dispositif selon la revendication précédente, comportant en outre un module de génération (MI) pour traiter un premier fichier de configuration (CFO) desdits fichiers de configuration et générer un second852-FR-014146-patentapplication-final 27 fichier de configuration (CFI) interprétable par ledit module de traitement de commandes (MR).5