FR2851354A1 - Formulaire dynamique oriente utilisateur pour la generation de requetes sql maitrisees - Google Patents

Abstract

L'invention concerne un procédé d'interrogation par un utilisateur d'au moins une base de données relationnelle hébergée par au moins un serveur de données dans un système informatique et fournissant un résultat en réponse à des requêtes établies dans le langage structuré d'interrogation SQL, caractérisé en ce que l'utilisateur choisit à partir d'un poste de travail, un environnement d'interrogation correspondant à un ensemble de formulaires relatifs à un périmètre fonctionnel couvert par toute ou partie d'une base de données, sélectionne un formulaire adapté à son besoin et formule sa demande par l'intermédiaire de choix effectués dans le formulaire, lequel formulaire se présente sous la forme d'une interface homme-machine générée dynamiquement à partir d'un squelette de requêtes établissant un cadre prédéfini à la formulation de la demande par l'utilisateur par la mise en place de contrôles et de règles de gestion associés au formulaire, ledit squelette comprenant une structure arborescente dans laquelle sont intégrés d'une part, des objets destinés à la génération dynamique de l'interface homme-machine et, d'autre part, des objets destinés à la constitution du langage structuré d'interrogation SQL correspondant à la ou les requêtes SQL à exécuter en fonction des choix effectués par l'utilisateur dans le formulaire.

Description

La présente invention se rapporte à un procédé d'interrogation d'une base

de

données, et plus particulièrement à un procédé d'interrogation d'une base de données relationnelle.

Les systèmes de bases de données relationnelles sont bien connus dans l'état 5 de la technique et consistent en des bases de données dans lesquelles les données sont organisées en fonction des relations qui existent entre elles. Plus précisément, les systèmes de bases de données relationnelles présentent une structure tabulaire o le mode d'organisation des données est composé de colonnes et de lignes, dont chaque cellule contient des informations et des liens qui existent entre les données. Le 10 langage SQL (Structured Query Langage), largement reconnu et répandu, a été développé pour l'interrogation, la mise à jour et la gestion de ces bases de données relationnelles. Aussi, jusqu'à maintenant, le développement et l'utilisation des bases de données relationnelles restent limités aux utilisateurs qui possèdent une bonne connaissance du langage SQL, de même qu'une bonne compréhension des structures 15 de données relationnelles et donc des principes mathématiques de l'algèbre relationnelle.

Des outils d'interrogation des bases de données relationnelles masquant la complexité du langage SQL et des bases de données relationnelles ont donc été développés pour faciliter la constitution de requêtes par les utilisateurs de bases de 20 données relationnelles.

Une première approche consiste en des requêtes figées prédéfinies pour lesquelles l'utilisateur ne choisit que les valeurs de paramètres d'exécution qui lui sont imposés. On peut prendre comme exemple une requête permettant d'extraire la liste des employés d'une entreprise (Nom, Prénom, Montant de salaire) et o les 25 paramètres d'exécution demandés sont: Année, Catégorie de personnes (cadres, non cadres, par exemple). Cette approche, bien qu'elle présente l'intérêt de permettre à l'utilisateur d'être certain de la signification du résultat qu'il obtiendra, a cependant comme inconvénient d'être figée et ne permet pas de couvrir un périmètre fonctionnel vaste.

Une autre approche, telle que celle décrite dans le brevet US 5,555,403 (DI) de la société Business Objects, consiste en une libre constitution des requêtes à l'aide d'un méta-modèle constitué d'une liste d'objets organisés. Cette liste d'objets organisés est appelée " Univers " dans Dl et contient des objets de type dimension, mesures et conditions et une description des jointures à utiliser pour faire le lien automatiquement entre les différentes tables de la base de données et des associations interdites.

Par exemple, dans le cas o l'utilisateur veut constituer un modèle à partir du méta-modèle " RH " relatif à la base de données contenant les données Ressources Humaines d'une entreprise, il doit sélectionner les objets du méta-modèle correspondant aux informations qu'il attend, intégrer des conditions adaptées pour 10 répondre à sa problématique et s'assurer lui-même de la cohérence de la requête qu'il va générer. Cette approche est très bien adaptée à un utilisateur averti qui connaît parfaitement la base de données qu'il interroge. Il saura en effet éviter la sélection d'objets incompatibles entre eux qui empêche la génération d'une requête, il veillera à définir des conditions cohérentes et il pourra comprendre le résultat obtenu. 15 Cependant, cette méthode est très mal adaptée à un utilisateur qui ne connaîtrait pas parfaitement la base de données qu'il interroge. Notamment, dans un cas o le nombre d'objets et d'incompatibilités entre objets sont importants, un utilisateur non averti se verrait confronter à de grandes difficultés pour constituer sa requête.

Un tel utilisateur peut par exemple omettre des conditions et se retrouver avec 20 une requête dont les résultats sont trop volumineux et ne sont alors pas exploitables à l'aide d'outils informatiques d'usage courant tel Word ou Excelo. L'utilisateur peut encore sélectionner un ensemble de conditions mal adapté rendant le résultat difficilement compréhensible. De plus, il n'existe pas de limitation du nombre de valeurs choisies dans une liste de valeurs proposées à l'utilisateur et peu de contrôles 25 au niveau des zones de saisies proposées à l'utilisateur.

Aussi, au vu de l'état de la technique, en particulier de Dl, le problème qui se pose est de proposer une méthode d'interrogation des bases de données relationnelles permettant à un utilisateur non averti d'exprimer de façon très simple son besoin à l'intérieur d'un cadre prédéfini, répondant à une approche métier adaptée au contexte 30 de l'utilisateur, dans lequel des limites et des règles de gestion fines peuvent être imposées à l'expression du besoin de l'utilisateur.

La solution à ce problème consiste en un procédé d'interrogation par un utilisateur d'au moins une base de données relationnelle hébergée par au moins un serveur de données dans un système informatique et fournissant un résultat en réponse à des requêtes établies dans le langage structuré d'interrogation SQL, 5 caractérisé en ce que l'utilisateur choisit à partir d'un poste de travail, un environnement d'interrogation correspondant à un ensemble de formulaires relatifs à un périmètre fonctionnel couvert par toute ou partie d'une base de données, sélectionne un formulaire adapté à son besoin et formule sa demande par l'intermédiaire de choix effectués dans le formulaire, lequel formulaire se présente 1o sous la forme d'une interface homme-machine générée dynamiquement à partir d'un squelette de requêtes établissant un cadre prédéfini à la formulation de la demande par l'utilisateur par la mise en place de contrôles et de règles de gestion associés au formulaire, ledit squelette comprenant une structure arborescente dans laquelle sont intégrés d'une part, des objets destinés à la génération dynamique de l'interface 15 homme-machine et, d'autre part, des objets destinés à la constitution du langage structuré d'interrogation SQL correspondant à la ou les requêtes SQL à exécuter en fonction des choix effectués par l'utilisateur dans le formulaire.

D'autres caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture de la description qui suit, donnée à titre d'exemple 20 illustratif et non limitatif et faite en référence aux figures suivantes dans lesquelles: - la figure 1 illustre la structure et la composition d'un squelette de requêtes selon la présente invention, et - les figures 2, 3 et 4 illustrent un cas de formulation de demande selon la présente invention et représentent schématiquement des copies d'écran 25 correspondant aux premier, deuxième et troisième écrans d'un formulaire de demande.

Dans l'exemple de réalisation envisagée, une architecture informatique à plusieurs niveaux au sein d'un réseau informatique d'entreprise est retenue. Une ou plusieurs bases de données hébergées par un ou plusieurs serveurs de données sont 30 accédées. Un serveur d'applications héberge l'application mettant en oeuvre l'invention. Le poste de travail est un micro-ordinateur équipé d'un simple navigateur Internet accédant, via le réseau informatique de l'entreprise, au serveur d'applications en utilisant le protocole HTTP (pour " Hyper Text Transfert Protocol ").

Selon l'invention, un utilisateur va exprimer son besoin au niveau de son 5 poste de travail par l'intermédiaire du navigateur Internet. Un formulaire de demande correspondant à une interface homme-machine (IHM) est généré dynamiquement par l'application dans le langage HTML (pour " Hyper Text Markup Langage ") et diffusé sur le poste de travail au travers du réseau informatique. L'IHM se décompose en plusieurs écrans successifs, de préférence trois, liés entre eux par les 10 choix de l'utilisateur. Cette IHM va permettre de gérer l'interactivité entre l'utilisateur et l'application distante qui dispose de droits d'accès aux bases de données. Dans un premier écran, l'utilisateur va paramétrer sa demande en précisant ce qu'il souhaite obtenir en résultat. Il saisit les paramètres d'exécution de sa demande dans un second écran et il la soumet ensuite en choisissant le moment 15 d'exécution dans un troisième écran.

Ainsi, l'utilisateur va pouvoir préciser son besoin de manière simple en effectuant des choix parmi des éléments qui lui sont proposés au niveau des différents écrans du formulaire. Un même formulaire permet ainsi à l'utilisateur de constituer un nombre plus ou moins grand de requêtes SQL en fonction de ses choix 20 effectués dans le formulaire et en fonction de la liberté donnée à l'utilisateur dans le choix des éléments proposés et du nombre d'éléments proposés.

Le formulaire de demande par l'intermédiaire duquel l'utilisateur formule son besoin est généré dynamiquement à partir d'un squelette de requêtes. Le squelette de requêtes comprend les règles de gestion et l'ensemble des éléments nécessaires à la 25 construction des écrans du formulaire proposés à l'utilisateur et à la constitution du langage SQL de la ou des requêtes générées en fonction des choix effectués par l'utilisateur dans le formulaire. A la différence d'un méta-modèle, le squelette de requêtes permet de fournir un cadre prédéfini à la constitution d'une requête par l'utilisateur, dans lequel des limites et des règles de gestion fines peuvent être 30 imposés au niveau des choix effectués par l'utilisateur.

La présente invention est ainsi mise en oeuvre dans le cadre d'une application informatique dédiée à l'accès de bases de données relationnelles. Une unité fonctionnelle, appelée module d'administration, gérée par un ou plusieurs administrateurs fonctionnels, est prévue pour assurer la création et la maintenance s des environnements de travail proposés aux utilisateurs. Ainsi, par l'intermédiaire du module d'administration, les administrateurs fonctionnels de l'application, typiquement des utilisateurs disposant des droits nécessaires au module d'administration et d'une très bonne maîtrise du langage d'interrogation SQL ainsi que d'une connaissance approfondie du modèle de données accédé, vont tout d'abord 10 créer des squelettes de requêtes, faisant référence à des objets définis dans un dictionnaire d'objets qui seront précisés ciaprès.

Les différents formulaires de demande proposés aux utilisateurs se présentant sous la forme d'IHM se décomposant en plusieurs écrans successifs, sont donc définis par les administrateurs fonctionnels de l'application par l'intermédiaire des 15 squelettes de requêtes grâce auxquels il est possible de définir de manière précise l'environnement de travail qui sera proposé aux utilisateurs en fonction de leur profil respectif.

Pour concevoir un squelette de requêtes, l'administrateur fonctionnel dispose donc d'un dictionnaire d'objets qu'il a défini, et dans lequel deux catégories d'objets 20 ont été créées: des objets de type IHM et des objets de type SQL qui seront définis ci-après.

Dans le dictionnaire d'objets, les objets de type IHM sont destinés à la génération des écrans du formulaire de demande proposés aux utilisateurs. Les objets de type IHM se répartissent entre les objets aides et les objets invites.

Les objets aides correspondent à du texte, des liens, des images et des attributs d'affichage définis par l'administrateur fonctionnel dans le langage HTML et sont affichés à l'écran pour aider l'utilisateur dans la formulation de sa demande. Il peut s'agir par exemple d'informations sur les règles de gestion appliquées à un formulaire. Selon une caractéristique de l'invention, les aides sont adaptées au métier 30 de l'utilisateur.

Les invites correspondent typiquement à des listes de valeurs ou à des zones de saisie libre. Ces objets permettent de disposer d'une partie variable dans une requête destinée à être alimentée à partir d'un choix effectué par l'utilisateur dans une liste de valeurs ou à partir d'une saisie libre. Selon l'invention, des contrôles sont 5 associés à ces objets de façon à assurer une optimisation des requêtes générées. Les contrôles associés peuvent être les suivants: contrôle du type (numérique ou alphanumérique), de la longueur dans le cas d'une saisie alphanumérique (de n à m caractères), valeur minimum/maximum dans le cas d'une saisie numérique, choix unique ou multiple limité à n occurrences dans une liste.

Le dictionnaire d'objets comprend également les objets de type SQL qui sont destinés, d'une part à la génération des écrans du formulaire de demande proposé aux utilisateurs et, d'autre part, à la génération de la requête SQL en fonction des choix de l'utilisateur. Les objets de type SQL se répartissent entre des objets simples, des objets conditions et des objets jointures.

Les objets simples, de type dimension, libellé, mesure, correspondent d'une part, à des attributs restituables d'une requête SQL présents dans une clause SELECT et, d'autre part, à des objets utilisés dans une opération simple présents dans une clause WHERE ou HAVING, sous la forme objet simple + opérateur (=, <, >, IN...) + constante (ou invite). Lors de la restitution des résultats, les objets simples de type 20 dimension et libellé peuvent être restitués en ligne ou en colonne. Les objets de type mesure sont restitués au croisement des lignes et des colonnes et une opération (somme, minimum, maximum, moyenne) peut être demandée sur un objet de type mesure.

Les objets conditions correspondent à des conditions SQL présentes 25 principalement dans les clauses WHERE ou HAVING d'une requête.

Les objets jointures décrivent les jointures SQL entre deux tables présentes dans la clause WHERE d'une requête.

Le dictionnaire permet avantageusement de centraliser les objets créés pour gérer l'IHM et le SQL. Il permet ainsi une réutilisation des mêmes objets définis une 30 seule fois dans différents squelettes et une facilité de maintenance. De plus, i lorsqu'un objet est modifié, les formulaires générés dynamiquement à partir de squelettes référençant l'objet intègrent automatiquement la modification.

Selon l'invention, l'association dans un squelette de requêtes d'objets de type IHM et d'objets de type SQL issus du dictionnaire d'objets, permet la génération 5 dynamique d'un formulaire et donc d'une ou plusieurs requêtes SQL à partir des choix effectués par l'utilisateur dans les différents écrans du formulaire.

La figure l montre plus précisément la composition d'un squelette de requêtes. Un squelette présente ainsi une structure arborescente dans laquelle un administrateur fonctionnel insère et organise des objets issus du dictionnaire d'objets. 10 Un squelette définit également les contrôles et règles de gestion associés à ces objets qui permettent ainsi d'établir un cadre prédéfini à la génération dynamique de 1'IHM et d'une ou plusieurs requêtes SQL à partir des choix effectués par l'utilisateur.

Pour ce faire, un squelette est structuré principalement en cinq familles d'éléments, respectivement les axes, les groupes, les invites, les aides et le texte 15 SQL.

Les axes permettent de regrouper à l'écran plusieurs éléments correspondant à un même axe d'analyse. On peut avoir par exemple un axe géographique, un axe temps, un axe mesure... Chaque objet du squelette destiné à apporter une information à l'utilisateur est alors associé à un axe et porte un numéro d'ordre de 20 présentation à l'écran.

Les groupes correspondent à des ensembles d'objets pour lesquels une règle de gestion commune est définie. Ils permettent un regroupement logique des attributs de données à restituer et/ou des conditions à appliquer dans le premier écran du formulaire. Ainsi, l'administrateur définit une règle de gestion commune pour un 25 groupe donné, se traduisant par un nombre minimum et maximum d'objets pouvant être sélectionnés par l'utilisateur. Si le minimum et le maximum sont de 1, l'IHM se traduit pour ce groupe par l'affichage d'un radio-bouton. Si le minimum et le maximum sont différents, des cases à cocher sont proposées.

Les invites représentent quant à elles des parties variables de la requête pour 30 lesquelles la valeur sera celle saisie ou sélectionnée dans une liste par l'utilisateur dans un deuxième écran du formulaire généré à partir du squelette. L'administrateur peut définir, comme déjà vu précédemment, des contrôles et règles de gestion associés à une invite, à savoir une taille minimum et maximum dans le cas d'une saisie libre ou une sélection unique ou multiple limitée à n occurrences dans le cas d'une liste déroutante.

Avantageusement, l'administrateur peut associer à une invite une valeur par défaut prise dans le contexte personnel de l'utilisateur. Le contexte utilisateur correspond à des variables pour lesquelles le contenu est défini et modifié par l'utilisateur lui même ou bien pour lesquelles le contenu lui est imposé. Les variables du contexte utilisateur peuvent donc être utilisées dans un squelette de requêtes 10 comme condition ou bien associées à une liste de valeurs. De cette façon, lorsque l'utilisateur formule une demande, pour les variables présentes dans le squelette, le contenu du contexte de l'utilisateur est automatiquement appliqué. Il est ainsi possible de proposer des listes de valeurs pour lesquelles le contenu du contexte utilisateur est présélectionné ou bien encore d'imposer une restriction dans la requête 15 lorsque la variable est utilisée dans une condition imposée.

Il est à noter qu'une invite présente une seule fois dans un squelette peut être utilisée dans différents objets restituables et conditions du squelette.

On a vu que les objets aides du dictionnaire d'objet pouvaient être intégrés dans le squelette. Les aides peuvent, à la demande de l'administrateur, être affichées 20 dans le premier et/ou second écran d'un formulaire. Un numéro d'ordre est prévu pour être associé aux objets aides de façon à positionner de manière très précise les aides à l'écran.

Enfin, le texte SQL est le dernier élément selon lequel est structuré un squelette. Le texte SQL correspond en fait à la requête ou les requêtes SQL 25 potentiellement générées à partir d'un squelette. Dans le cas de requêtes ensemblistes (INTERSECT, UNION, MINUS), plusieurs requêtes distinctes sont présentes dans cette partie du squelette.

Ainsi, pour chaque requête potentielle, l'administrateur renseigne les différentes clauses de la requête en sélectionnant les objets correspondants dans le 30 dictionnaire d'objets et en les liant aux éléments de structure du squelette décrits précédemment (axes, groupes, invites).

La structure de chaque requête est classique. Pour ce qui est de la clause SELECT, l'administrateur peut préciser s'il s'agit d'un SELECT DISTINCT ou non et intègre les différents objets restituables à proposer à l'utilisateur dans le premier écran du formulaire. Pour chaque objet, il choisit de l'imposer ou de le rendre 5 optionnel, de l'afficher ou de le cacher, de le présélectionner ou non. Il rattache également l'objet à un groupe et un axe pour préciser les règles de gestion associées.

Enfin, l'administrateur peut préciser si l'objet restituable doit être intégré à une clause GROUP BY à ajouter à la requête.

La clause FROM est alimentée automatiquement à partir des objets intégrés 10 dans les différentes clauses de la requête. En effet, lors de la création d'un objet dans le dictionnaire, l'administrateur fonctionnel précise la table de rattachement de l'objet.

La clause WHERE est alimentée à partir d'objets du dictionnaire qui sont principalement les objets conditions et les objets jointures. Il est possible d'y créer 15 des conditions associant des objets du dictionnaire et des opérateurs de comparaison.

L'administrateur peut également créer des requêtes imbriquées et combiner les différentes conditions avec les opérateurs ET (AND) et OU (OR). Une requête imbriquée peut correspondre à une liste de requêtes liées entre elles par des liens du type UNION, MINUS, INTERSECT ou bien à une requête ayant une structure 20 classique.

Pour chaque objet condition ou requête imbriquée, l'administrateur choisit de l'imposer ou de le rendre optionnel, de l'afficher ou de le cacher, de le présélectionner ou non dans le premier écran du formulaire. Il rattache alors l'objet à un axe et à un groupe pour préciser les règles de gestion.

Il est à noter que les jointures présentes dans la requête ne sont pas visibles de l'utilisateur final au travers du formulaire.

La structure d'une requête peut encore comprendre la clause HAVING, dont le fonctionnement est très proche de celui de la clause WHERE sauf qu'on y trouve pas de jointures.

Pour optimiser une requête, l'administrateur peut y associer une commande d'optimisation, du type de la commande HINT sous le logiciel Oracle.

On va maintenant décrire un cas concret de formulation de demande d'interrogation d'une source de données de type base de données relationnelle, qui reprend et illustre les principes décrits ci-dessus, en référence aux figures 2, 3 et 4.

Tout d'abord, l'utilisateur est amené à choisir une base de données hébergée 5 au niveau d'un serveur de données et à sélectionner un formulaire correspondant à sa demande, à partir de son poste de travail. Pour ce faire, un système de navigation simple est proposé à l'utilisateur pour l'aider à sélectionner le formulaire le mieux adapté à sa demande parmi les environnements d'interrogation et les formulaires auxquels il est habilité. Le système de navigation proposé à l'utilisateur est en fait 10 basé sur une démarche logique simple et itérative utilisant le vocabulaire et la logique métier de l'utilisateur, et se présente sous la forme d'une arborescence à plusieurs niveaux sur le principe du déplier/plier par simple clic de souris.

Plus précisément, différentes arborescences sont proposées à un utilisateur et une arborescence permet de classer un ensemble de squelettes correspondant à un 15 même environnement d'interrogation et une même base de données selon une approche métier cohérente avec le raisonnement de l'utilisateur face à sa demande.

Le classement des squelettes dans l'arborescence utilise donc le vocabulaire et la logique métier de l'utilisateur pour lui permettre de trouver facilement le formulaire adapté à sa demande.

Une fois qu'un squelette est sélectionné dans une arborescence, l'application génère dynamiquement l'IHM du formulaire de demande correspondant en analysant le squelette sélectionné et en interrogeant le dictionnaire d'objets afin de disposer de la dernière version du contenu des objets.

La formulation d'une demande à partir du squelette sélectionné se décompose 25 alors en trois écrans successifs représentés schématiquement aux figures 2, 3 et 4 qui décrivent un cas concret de formulation de demande. Dans cet exemple, l'environnement d'interrogation choisi est relatif à la base de données contenant les données Chiffre d'affaires 2002 d'une entreprise et le formulaire choisi est intitulé " Données facturées ".

Dans les deux premiers écrans, les éléments sont classés par axes, qui permettent de regrouper à l'écran plusieurs éléments correspondant à un même axe d'analyse: Axe géographique, Axe clients, Axe produits, Axe temps et Axe mesures.

Des commentaires d'aide sont également affichés pour guider l'utilisateur dans ses choix: Aide 1, Aide n.

Dans un premier temps, l'utilisateur doit paramétrer sa demande en précisant 5 ce qu'il souhaite obtenir comme résultat. Ainsi, en référence avec la figure 1, le premier écran du formulaire, généré dynamiquement à partir des règles de gestion définies dans le squelette de requêtes sélectionné, est constitué de deux colonnes. La colonne de gauche correspond aux éléments que l'utilisateur souhaite voir restituer par sa demande et permet donc à l'utilisateur de choisir les attributs de données 10 restituables, et la colonne de droite correspond aux critères de sélection proposés et permet donc à l'utilisateur de choisir les conditions à appliquer.

L'utilisateur choisit donc les attributs de données à restituer et les conditions à appliquer dans le premier écran du formulaire. Le premier écran du formulaire est généré dynamiquement à partir des règles de gestion définies dans le squelette de 15 requêtes. Les règles de gestion ainsi que l'ordre d'affichage des éléments à l'écran ont été déterminées par l'administrateur qui a créé le squelette, comme expliqué précédemment.

L'utilisateur dispose donc dans le premier écran du formulaire d'une liberté plus ou moins grande en fonction des règles et limitations définies par 20 l'administrateur.

Dans le cas de la figure 1, l'utilisateur a choisi de restituer, par l'intermédiaire des cases cochées dans la colonne de gauche, les objets suivants: segment Client, Famille de produits, Année, Trimestre, Chiffre d'affaires, Quantité.

Ces objets sont à restituer en tenant compte des conditions suivantes qui ont 25 été sélectionnées par l'intermédiaire des cases cochées dans la colonne de droite: Une ou plusieurs région(s), Tous les clients, Un ou plusieurs produit(s) élémentaire(s), Une période, ce dernier choix étant un choix obligatoire.

Les règles de gestion mises en place dans le squelette de requêtes pour la génération dynamique du premier écran du formulaire consistent, comme vu plus 30 haut, à regrouper à l'écran les attributs restituables et les conditions correspondant à un même axe d'analyse. Ces règles de gestion consistent également à rattacher chaque attribut restituable et chaque condition du premier écran à un groupe, chaque groupe assurant un regroupement logique dans le premier écran des attributs restituables et des conditions pour lesquelles une règle de gestion commune est définie, concernant le nombre minimum et maximum d'objets du groupe pouvant 5 être sélectionné par l'utilisateur. Les différents objets restituables et les différentes conditions sont donc rassemblés par groupe dans le premier écran du formulaire: Groupel, Groupe n. Les groupes permettent donc de définir les règles devant s'appliquer aux choix de l'utilisateur à l'écran.

Lorsque l'utilisateur a effectué ses choix à l'aide des cases à cocher et des 10 radio-boutons proposés, il valide le premier écran. Des contrôles sont alors effectués afin de vérifier que les règles de gestion associées sont bien respectées. Si ce n'est pas le cas, la validation est refusée et un message informe l'utilisateur de la (ou des) règle(s) non respectée(s) et du (ou des) groupe(s) d'objets concerné(s) par ce non respect.

Après validation du premier écran, le deuxième écran du formulaire est généré dynamiquement à partir du squelette de requêtes sélectionné au départ et des choix effectués par l'utilisateur dans le premier écran du formulaire. Le deuxième écran permet alors à l'utilisateur de préciser les paramètres d'exécution de sa demande grâce aux invites proposées à l'écran du type zone de saisie et/ou liste de 20 valeurs, voir figure 3. Au niveau du deuxième écran du formulaire, l'utilisateur visualise donc les conditions sélectionnées (ou imposées) dans le premier écran et choisit les valeurs des paramètres d'exécution pour les conditions faisant l'objet de saisie de paramètres par l'intermédiaire des invites qui lui sont proposées.

Pour ce faire, des invites sont proposées à l'utilisateur sous la forme desaisie 25 libre ou de liste déroutante de valeurs, pour lesquelles divers contrôles sont définis dans le squelette de requêtes, comme vu plus haut.

Les invites peuvent être pré-renseignées avec des valeurs par défaut définies dans le squelette ou bien avec des valeurs faisant référence au contexte personnel de l'utilisateur. Egalement, pour les conditions ne nécessitant pas une invite du type 30 zone de saisie ou liste de valeurs, il est prévu d'afficher dans le deuxième écran une confirmation de prise en compte, sous la forme d'un libellé.

Ainsi, dans l'exemple de la figure 3, l'utilisateur doit choisir au maximum deux régions dans une liste de valeurs, est informé que tous les clients sont pris en compte, a saisi les codes produits " Abts " et " Traf " et a sélectionné le mois de début " 200201 " et le mois de fin " 200212 ".

Lorsque l'utilisateur valide le deuxième écran, l'application contrôle la conformité avec les règles de gestion associées aux invites telles que définies dans le squelette, des saisies et des sélections effectuées par l'utilisateur (saisie numérique entre deux bornes, saisie alphanumérique comprenant un nombre minimum et un nombre maximum de caractères, sélection unique ou multiple limité à n occurrences 10 dans une liste de valeurs). La validation n'est effective que si les règles de gestion définies par l'administrateur dans le squelette sont respectées. Dans le cas contraire, l'utilisateur est informé des règles de gestion non satisfaites. Il peut alors modifier ses choix et valider à nouveau le deuxième écran.

Après validation du deuxième écran, un troisième écran, voir figure 4, est 15 généré, permettant à l'utilisateur de soumettre sa demande en choisissant le moment de son déclenchement. Plus précisément, le troisième écran du formulaire permet à l'utilisateur de saisir le titre de sa demande ainsi qu'éventuellement un commentaire et de choisir le moment d'exécution de la requête correspondant à sa demande.

L'utilisateur peut choisir que l'exécution de la requête soit effectuée dès que possible 20 ou en différé. Il peut également choisir de ne pas exécuter la requête dans l'immédiat. Dans le cas d'une exécution en différé, l'utilisateur doit choisir la date et l'heure de déclenchement.

Dans tous les cas, la demande est sauvegardée pour permettre à l'utilisateur de retravailler dessus ultérieurement.

Dans l'exemple de la figure 4, l'utilisateur a donné pour titre à sa demande " Analyse CA 2002 ", n'a pas saisi de commentaires et souhaite un déclenchement de sa demande dès que possible.

Après validation du troisième écran, la demande est sauvegardée. Puis, le texte SQL correspondant à la ou les requêtes à exécuter est généré par l'application 30 en fonction des choix effectués par l'utilisateur dans le formulaire. Les parties variables de la requête sont ainsi complétées par les choix effectués par l'utilisateur dans le deuxième écran du formulaire, au travers des invites.

La requête SQL est alors soumise pour exécution à un module de traitement asynchrone, implanté au niveau du serveur de données afin de libérer le poste de 5 travail de l'utilisateur, le serveur d'applications et de gérer l'ordonnancement des travaux en fonction des ressources disponibles sur le serveur de données.

La présente invention permet donc une maîtrise totale des possibilités offertes à l'utilisateur pour formuler sa demande grâce à la mise en oeuvre du squelette de requêtes et au principe de génération dynamique du formulaire de demande et de la 10 requête SQL en fonction des choix de l'utilisateur. Ainsi, derrière une IHM simple pour l'utilisateur, il est possible de générer des requêtes complexes incluant notamment des requêtes imbriquées ou plusieurs requêtes combinées, le squelette permettant de maîtriser le SQL généré grâce aux contraintes qu'il définit d'une part, au niveau des choix proposés dans le premier écran du formulaire et, d'autre part, au 15 niveau des saisies ou choix dans des listes de valeurs dans le deuxième écran du formulaire. De cette façon, en laissant libre l'utilisateur dans un cadre prédéfini, un même squelette permet de générer un grand nombre de requêtes.

De nombreux autres avantages découlent de la présente invention.

Notamment, les utilisateurs sont rendus plus autonomes dans la constitution de leur 20 demande, même complexe. La formulation d'une demande selon l'invention permet de plus aux utilisateurs d'être certains des résultats qu'ils obtiennent et de leur cohérence et permet de dégager du temps pour l'analyse des données restituées en diminuant la charge nécessaire à l'obtention des données. Enfin, l'invention permet de diminuer la charge liée à la maintenance et à l'administration des environnements 25 de travail proposés aux utilisateurs.

Claims (25)

REVENDICATIONS

1. Procédé d'interrogation par un utilisateur d'au moins une base de données relationnelle hébergée par au moins un serveur de données dans un système informatique et fournissant un résultat en réponse à des requêtes établies dans le langage structuré 5 d'interrogation SQL, caractérisé en ce que l'utilisateur choisit à partir d'un poste de travail, un environnement d'interrogation correspondant à un ensemble de formulaires relatifs à un périmètre fonctionnel couvert par toute ou partie d'une base de données, sélectionne un formulaire adapté à son besoin et formule sa demande par l'intermédiaire de choix effectués dans le formulaire, lequel formulaire se présente sous la forme d'une interface homme10 machine générée dynamiquement à partir d'un squelette de requêtes établissant un cadre prédéfini à la formulation de la demande par l'utilisateur par la mise en place de contrôles et de règles de gestion associés au formulaire, ledit squelette comprenant une structure arborescente dans laquelle sont intégrés d'une part, des objets destinés à la génération dynamique de l'interface homme-machine et, d'autre part, des objets destinés à la constitution 15 du langage structuré d'interrogation SQL correspondant à la ou les requêtes SQL à exécuter en fonction des choix effectués par l'utilisateur dans le formulaire.

2. Procédé selon la revendication 1, caractérisé en ce que le squelette de requêtes utilise un contexte personnel de l'utilisateur correspondant à des variables pour lesquelles la valeur est définie par l'utilisateur lui-même ou pour lesquelles la valeur lui est imposée.

3. Procédé selon la revendication 1 ou 2, caractérisé en ce que le formulaire se décompose en plusieurs écrans successifs liés entre eux par les choix de l'utilisateur.

4. Procédé selon la revendication 3, caractérisé en ce que l'utilisateur choisit des attributs de données à restituer et des conditions à appliquer dans un premier écran du formulaire généré dynamiquement à partir des règles de gestion définies dans le squelette de 25 requêtes.

5. Procédé selon la revendication 4, caractérisé en ce que les règles de gestion mises en place dans le squelette de requêtes pour la génération dynamique du premier écran du formulaire consistent à regrouper à l'écran les attributs restituables et les conditions correspondant à un même axe d'analyse.

6. Procédé selon la revendication 4 ou 5, caractérisé en ce que les règles de gestion mises en place dans le squelette de requêtes pour la génération dynamique du premier écran du formulaire consistent à rattacher chaque attribut restituable et chaque condition dudit premier écran à un groupe, chaque groupe assurant un regroupement logique dans ledit premier écran des attributs restituables et des conditions pour lesquelles une règle de gestion commune est définie.

7. procédé selon la revendication 6, caractérisé en ce que la règle de gestion commune pour un groupe donné définit un nombre minimum et un nombre maximum d'éléments pouvant être choisis par l'utilisateur.

8. Procédé selon l'une quelconque des revendication 4 à 7, caractérisé en ce que l'utilisateur visualise les conditions choisies dans le premier écran du formulaire et choisit des valeurs de paramètres d'exécution pour lesdites conditions, dans un deuxième écran généré dynamiquement à partir du squelette de requêtes et des choix effectués par l'utilisateur dans le 10 premier écran du formulaire.

9. Procédé selon l'une quelconque des revendications 3 à 8, caractérisé en ce que l'utilisateur choisit dans un troisième écran du formulaire, soit le moment d'exécution de la requête correspondant à sa demande, soit de ne pas exécuter ladite requête dans l'immédiat.

10. Procédé selon la revendication 9, caractérisé en ce que l'exécution de la requête est 15 effectuée dès que possible ou en différé.

11. Procédé selon la revendication 10, caractérisé en ce que l'utilisateur choisit la date et l'heure de l'exécution de la requête dans le cas d'une exécution en différé.

12. Procédé selon l'une quelconque des revendications 9 à 11, caractérisé en ce que l'utilisateur choisit un titre à sa demande dans le troisième écran du formulaire.

13. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que la demande de l'utilisateur est sauvegardée.

14. Procédé selon l'une quelconque des revendications précédentes, caractérisée en ce que la requête SQL générée en fonction des choix de l'utilisateur est soumise pour exécution à un module de traitement asynchrone implanté au niveau du serveur de données.

15. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que les objets destinés à la génération dynamique de l'interface homme-machine et les objets destinés à la constitution du langage structuré d'interrogation SQL sont centralisés dans un dictionnaire d'objets de façon à permettre une utilisation d'un même objet dans différents squelettes.

16. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que les objets destinés à la génération dynamique de l'interface homme-machine comprennent des aides correspondant à du texte, des liens, des images et des attributs d'afichage restitués au niveau de l'interface homme-machine pour aider l'utilisateur dans la formulation de sa demande.

17. Procédé selon la revendication 16, caractérisé en ce que les aides sont adaptées au métier de l'utilisateur.

18. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que les objets destinés à la génération dynamique de l'interface homme-machine comprennent des invites sollicitant un choix de l'utilisateur dans une liste de valeurs ou sous la forme d'une saisie.

19. Procédé selon les revendications 18 et 8, caractérisé en ce que le choix par 10 l'utilisateur des valeurs des paramètres d'exécution pour les conditions à appliquer est effectué par l'intermédiaire des invites.

20. procédé selon la revendication 18 ou 19, caractérisé en ce que des contrôles et des règles de gestion associés aux objets de type invite sont définis dans le squelette de requêtes.

21. Procédé selon la revendication 20, caractérisé en ce que les contrôles et les règles 15 de gestion associés aux objets de type invite consistent à définir une valeur minimum et une valeur maximum dans le cas d'une saisie numérique.

22. Procédé selon la revendication 20, caractérisé en ce que les contrôles et les règles de gestion associés aux objets de type invite consistent à définir un nombre de caractères minimum et maximum dans le cas d'une saisie alphanumérique.

23. Procédé selon la revendication 20, caractérisé en ce que les contrôles et les règles de gestion associés aux objets de type invite consistent à imposer à l'utilisateur un choix unique ou un choix multiple limité à n occurrences dans une liste.

24. Procédé selon les revendications 2 et 20, caractérisé en ce que les contrôles et les règles de gestion associés aux objets de type invite consistent à associer à une invite une 25 valeur par défaut prise dans le contexte personnel de l'utilisateur.

25. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le formulaire est sélectionné par l'intermédiaire d'une arborescence o est classé un ensemble de squelettes correspondant à un même environnement d'interrogation et une même base de données, le classement des squelettes dans l'arborescence utilisant un vocabulaire et 30 une logique métier de l'utilisateur.