FR2967281A1 - Procede de formulation de criteres de recherche et procede d'extraction de donnees d'une base de donnees - Google Patents

Abstract

La présente invention concerne un procédé d'extraction de données d'une base de données à l'aide d'un procédé de formulation de critères de recherche sans avoir de connaissances préalables ni sur le modèle de données ni sur le langage d'interrogation SQL. Le procédé comportant les étapes de : Renseigner les informations de configuration nécessaires et suffisantes pour le procédé de formulation des critères de recherche et le procédé d'extraction des données. Renseigner la table privilégiée sur laquelle formuler la requête. Renseigner en langage naturel un ou plusieurs critères de recherche portant sur les champs de la table privilégiée Associer ou non à cette table privilégiée des informations de jointure Renseigner ou non des contraintes de dénombrement sur les informations de jointure Recommencer ou non de façon récursive sur chacune des tables jointes les opérations précédentes Reformuler une ou plusieurs requêtes à la base de données en langage SQL Appliquer l'ensemble de requêtes sur la base de données et consolider les résultats obtenus sous la forme d'une liste d'enregistrements de la table privilégiée Cette invention trouve des domaines d'application dans de nombreux secteurs d'activité en permettant au plus grand nombre de tirer parti des données des bases de données, ceci en leur permettant de formuler des requêtes sans connaissance préalable du modèle de données ni du langage SQL. Nous pouvons notamment citer les domaines d'activité liés à l'exploration de données (Data-Mining) et à l'informatique décisionnelle (Business-Intelligence ).

Description

La présente invention concerne un procédé d'extraction de données d'une base de données à l'aide d'un procédé de formulation de critères de recherche sans avoir de connaissances préalables ni sur le modèle de données ni sur le langage d'interrogation SQL.

Les bases de données sont couramment utilisées pour stocker un grand nombre d'informations issues de sources multiples. Il est connu que ces données soient stockées dans des tables comprenant une liste d'enregistrement, chacun composée de plusieurs champs de données. Des informations de jointures, encore appelées relations, permettent d'établir des liens entre les différentes tables. Il est connu que cet ensemble forme le modèle de données. Il est connu que ce modèle de données est modélisé suivant diverses méthodologies comme par exemple la méthodologie Merise. Afin d'interroger une base de données dans le but d'extraire une partie des informations qui y sont stockées, il est connu d'utiliser un langage de formulation des requêtes appelé SQL, normalisé par l'ISO (ISO/CEI 9075), ou l'un de ses dérivés non normalisé proposé par les logiciels de gestion de bases de données. Les requêtes SQL permettent de définir quels sont les enregistrements des tables et des champs dont on souhaite récupérer les valeurs, ainsi que les différents critères de recherche associés aux champs et tables. L'exécution d'une requête SQL sur le moteur de base de données renvoie un résultat sous la forme d'un tableau à deux dimensions: les champs sélectionnés sous la forme de colonnes, et les eregistrements sous la forme de lignes. Le langage SQL comporte une grammaire qui lui est propre et composée de nombreux mots clés. La complexité de la grammaire du langage SQL le réserve à des utilisateurs avertis ayant acquis une très bonne maitrise du langage et ayant une connaissance approfondie du modèle de données mis en place.

Pour remédier à cet inconvénient, on a proposé dans l'état de la technique la représentation et l'édition sous une forme graphique des requêtes SQL et donc des tables, des champs des tables, des relations entre les tables et des critères de recherche, permettant ainsi de formuler des requêtes SQL sans avoir une connaissance détaillée de la syntaxe du langage. L'inconvénient d'un tel système est qu'il est tout de même nécessaire d'avoir une connaissance approfondie du modèle de données pour modéliser les relations entre les tables ainsi qu'une connaissance adéquante du langage SQL pour éditer les critères de recherche.

L'invention a pour but de proposer un procédé et des moyens de requête d'une base de données permettant de formuler des critères de recherche sans avoir préalablement connaissance du modèle de données, ni avoir de connaissance du langage SQL. Cette invention trouve des domaines d'application dans de nombreux secteurs d'activité en permettant au plus grand nombre de tirer parti des données des bases de données, ceci en leur permettant de formuler des requêtes sans connaissance préalable du modèle de données ni du langage SQL. Nous pouvons notamment citer les domaines d'activité liés à l'exploration de données (Data-Mining) et à l'informatique décisionnelle (Business-Intelligence).

A cet effet, l'invention a pour objet un procédé d'interrogation d'une base de données comportant : Plusieurs tables, chacune avec un ou plusieurs champs Des relations entre les différentes tables Le procédé comportant les étapes de : - Renseigner les informations de configuration nécessaires et suffisantes pour le procédé de formulation des critères de recherche et le procédé d'extraction des données afin de permettre ensuite la formulation et l'exécution des requêtes SQL sans avoir de connaissance préalable ni sur le modèle de données ni sur le langage SQL. Cette étape est ainsi réalisée sous forme déclarative et une fois pour toute, pour un modèle de données sélectionné. Renseigner la table privilégiée sur laquelle formuler la requête. Les résultats de la requête étant ensuite exprimés sous la forme d'un ensemble de références vers des enregistrements de cette table. Renseigner ou non un ou plusieurs critères de recherche portant sur les champs 25 de la table privilégiée, des opérateurs logiques pouvant être positionnés entre les différents critères (ET, OU, NON) Associer ou non à cette table privilégiée des informations de jointure vers des tables sur lesquelles on souhaite positionner un ou plusieurs critères de recherche portant sur les champs de ces tables 30 - Renseigner ou non des contraintes de dénombrement sur les informations de jointure afin de prendre en compte le nombre de liens entre la table privilégiée et les tables associées (par exemple au moins n, au plus n, exactement n, ...).

Recommencer ou non de façon récursive sur chacune des tables jointes les opérations précédentes, à savoir : o Renseigner ou non sur les tables jointes un ou plusieurs critères de recherche portant sur les champs des tables jointes, des opérateurs logiques pouvant être positionnés entre les différents critères (ET, OU, NON) o Associer ou non aux tables jointes des informations de jointure vers des tables sur lesquelles on souhaite positionner un ou plusieurs critères de recherche portant sur les champs de ces tables o Renseigner ou non des contraintes de dénombrement sur les informations de jointure afin de prendre en compte le nombre de liens entre la table privilégiée et les tables associées (par exemple au moins n, au plus n, exactement n, ...). Reformuler, par un procédé automatique, une ou plusieurs requêtes à la base de données en langage SQL en mentionnant complètement : o Les tables identifiées contenant les champs sur lesquels des critères de recherche sont appliqués o Les jointures représentatives des relations entre les différentes tables o Les contraintes de dénombrement sur les différentes jointures o Les critères de recherche sur les champs Appliquer, par un procédé automatisé, l'ensemble de requêtes sur la base de données et consolider les résultats obtenus sous la forme d'une liste d'enregistrements de la table privilégiée Ce procédé est illustré par l'illustration 1. La première étape de ce procédé {1} n'est à réaliser qu'une fois lors du paramétrage initial du procédé. La formulation {2} et l'extraction {3} des données des requêtes ultérieures s'appuient sur ce paramétrage initial, de tel sorte qu'il n'est alors plus nécessaire de disposer d'une connaissance préalable du modèle de données ou du langage SQL. Cela est représenté par la boucle de rétroaction {4} entre les étapes « formulation des critères de requête » {2} et « procédé d'extraction des données » {3} de l'illustration 1. Des informations de configuration relatives au modèle de données sont renseignées afin de permettre aux utilisateurs du procédé d'interrogation de la base de données de 30

4 renseigner les différents critères et relations sans avoir ni de connaissance du modèle de données, ni de connaissance du langage SQL. Les informations de configuration ont pour objectif : De définir la liste des critères de recherche portant sur les champs des tables - De permettre la présentation des critères de recherche en langage naturel dans le procédé de formulation des critères de requête D'identifier les relations possibles entre les tables Les informations de configuration sont utilisées d'une part par le procédé de formulation des critères de recherche pour permettre une édition sans connaissance préalable du modèle de données et du langage SQL et d'autre part par le procédé d'extraction des données de la base de données. Le procédé d'extraction de la base de données s'appuie à cet effet sur les informations de configuration pour reconstituer des requêtes en langage SQL sur la base des requêtes paramétrées par le dispositif de formulation des critères de recherche.

Les informations de configuration peuvent prendre par exemple la forme d'un fichier au format XML. Ce fichier contient alors, pour chaque table privilégiée la description de l'ensemble des critères qui peuvent être appliqués, ainsi que la description de l'ensemble des relations vers les autres tables privilégiées. Chaque table privilégiée est renseignée dans le fichier de configuration sous la forme 20 suivante : <query name="account" entity="Account" displayname="Comptes utilisateurs"> </query> Où . le paramètre « name » est un identifiant unique de la table privilégiée dans les informations de configuration le paramètre « entity » est le nom de la table dans la base de données SQL le paramètre « displayname » est le nom tel qu'il va apparaitre dans le procédé de formulation des critères de recherche. Chaque élément <query> contient un ensemble d'éléments <criteria> définissant les critères qui peuvent être appliqués sur la table privilégiée. Chaque critère est renseigné dans le fichier de configuration sous la forme suivante : 25 30 <criteria name="egUserName" displayname=" le nom d'utilisateur du compte est égal à {userNameParam} " category=" Critères sur l'utilisateur du compte "> </criteria> Où . 5 - le paramètre « name » est un identifiant unique du critère le paramètre « displayname » est la description du critère telle qu'elle va apparaitre dans le procédé de formulation des critères de requête. Cette description est en langage naturel. le paramètre « category » est le nom de la catégorie du critère tel qu'il va apparaitre dans le procédé de formulation des critères de requête Les critères peuvent accepter des paramètres en entrée, les paramètres des critères sont symbolisés par des textes entre accolades au sein du paramètre « displayname ». Dans l'exemple ci-dessus, le critère prend en paramètre l'information « userNameParam ». L'information « userNameParam » est valorisée au travers du procédé de formulation des critères de requête. Chaque élément <criteria> peut contenir un ou plusieurs éléments <criteriaparam> définissant les paramètres du critère, tels qu'ils sont identifiés entre accolades dans le champ « displayname » de l'élément <criteria>. Chaque paramètre de critère est renseigné dans le fichier de configuration sous la forme 20 suivante : <criteriaparam name="identifierParam" type="String" displayname=" identifiant " edit="singlestring" pickerattribute="identifier"/> Où. - le paramètre « name » est un identifiant unique du paramètre du critère 25 - le paramètre « displayname » est le nom du paramètre du critère tel qu'il va apparaitre dans le procédé de formulation des critères de requête - le paramètre «type» est le type de données du paramètre du critère. Ce paramètre peut par exemple prendre les valeurs suivantes : o « String » pour chaine de caractères 30 0 « Integer» pour valeur entière o « Float » pour valeur à virgule o « Boolean » pour valeur binaire (Vrai ou Faux) o « Date » pour une date Le paramètre « edit » est l'éditeur graphique qui va être utilisé par le procédé de formulation des critères de requête pour saisir la valeur du paramètre du critère. Ce paramètre peut par exemple prendre les valeurs suivantes : 0 « singlestring » pour un éditeur qui permet de renseigner une unique chaine de caractères o « multistring » pour un éditeur qui permet de renseigner une collection de chaines de caractères o « singlewildcard » pour un éditeur qui permet de renseigner une valeur unique comprenant des caractères de recherche o « singledate » pour un éditeur qui permet de renseigner une date o « singleperiod » pour un éditeur qui permet de renseigner une période de temps - Le paramètre « pickerattribute » est utilisé par le procédé de formulation des critères de requête pour proposer une aide à la saisie du critère en suggérant des valeurs existantes. La valeur du paramètre « pickerattribute » est le nom du champ dans la table privilégiée. Chaque élément <criteria> contient un ou plusieurs éléments <restriction> qui définissent la façon dont les critères de la requête SQL vont être formatés afin d'appliquer le critère.

Les éléments <restriction> sont donc une correspondance entre le critère et sa traduction en langage SQL. Chaque restriction est renseignée dans le fichier de configuration sous la forme suivante : <restriction name="mailFilter" operation="in"> </restriction> Où. le paramètre « name » est un identifiant unique de la restriction. le paramètre « operation » identifie la contrainte à appliquer au niveau de la requête SQL o « between » contraint la valeur d'un champ de la table entre deux valeurs 0 « eq » contraint la valeur d'un champ de la table à une valeur exacte o « ge » contraint la valeur d'un champ de la table à être plus grand ou égal à une valeur o « gt » contraint la valeur d'un champ de la table à être plus grand qu'une valeur o « ilike » contraint la valeur d'un champ de la table à ressembler à une chaine de caractères, sans tenir compte des différences majuscules/minuscules o « in » contraint la valeur d'un champ de la table à être égal à une des valeurs fournies o « isEmpty » contraint la valeur d'un champ de la table à être vide o «isNotEmpty» contraint la valeur d'un champ de la table à ne pas être vide o « isNotNull » contraint la valeur d'un champ de la table à être initialisé o « isNull » contraint la valeur d'un champ de la table à ne pas être initialisé o « le » contraint la valeur d'un champ de la table à être inférieur ou égal à une valeur 0 « like » contraint la valeur d'un champ de la table à ressembler à une chaine de caractères o « It » contraint la valeur d'un champ de la table à être inférieur à une valeur o « ne » contraint la valeur d'un champ de la table à ne pas être égal à une valeur Chaque élément <restriction> peut contenir un ou plusieurs éléments <restrictionparam> qui définissent les paramètres de la restriction. Le type et le nombre de paramètres dépend du paramètre « opération » renseigné au niveau de l'élement <restriction>. Chaque paramètre de restriction est renseigné dans le fichier de configuration sous la forme suivante : <restrictionparam name="left" value="identifier" property="true"/> Où: le paramètre « name » est un identifiant unique du paramètre de la restriction le paramètre « value » correspond à la valeur à indiquer à l'opération. La valeur peut soit prendre la forme o D'une chaine de caractères simple 2967281 a o D'une chaine de caractères entourée d'accolades, cette chaine est alors considérée par le procédé d'extraction des données comme un script retournant la valeur, par exemple : ^ « {identifierParam.value} » pour indiquer la valeur d'un paramètre 5 du critère nommé « identifierParam » ^ «{convertPeriodToDate(IastLoginDatePeriodParam.value)}» pour exécuter la méthode issue d'une librairie informatique afin de convertir une période en date sur la valeur du paramètre du critère nommé « IastLoginDatePeriodParam » 10 II peut arriver que l'on souhaite appliquer des critères suivant des algorithmes qui ne sont pas présents nativement dans langage SQL. Par exemple la recherche par approximation phonétique, ou encore la recherche par expression régulière. Dans ce cas il est possible de définir des restrictions particulières dans le fichier de configuration. Chaque restriction particulière est renseignée dans le fichier de configuration sous la 15 forme suivante : <customrestriction name="userNameFilter" function="FuzzyMatchingFilter"> </ customrestriction > Où. le paramètre « name » est un identifiant unique de la restriction particulière 20 - le paramètre «function» est une référence vers une fonction d'une librairie informatique externe au logiciel de gestion de bases de données opérant l'opération de recherche Chaque élément <customrestriction> peut contenir un ou plusieurs éléments <restrictionparam> qui définissent les paramètres de la restriction particulière. Le type et 25 le nombre de paramètres dépend du paramètre «function» renseigné au niveau de l'élement <customrestriction>. Chaque paramètre de restriction particulière est renseigné dans le fichier de configuration sous la même forme que les paramètres de <restriction>.

30 La description d'un critère de requête peut donc au final, par exemple, prendre la forme suivante :

9 <criteria name="egUserName" displayname=" le nom d'utilisateur du compte est égal à {userNameParam} " category=" Critères sur l'utilisateur du compte "> <criteriaparam name="userNameParam" type="String" displayname=" nom d'utilisateur " edit="singlestring" pickerattribute="userName"/> <restriction name="userNameFilter" operation="eq"> <restrictionparam name="left" value="userName" property="true"/> <restrictionparam name="right" value="{userNameParam.value}"/> </restriction> </criteria> Il est aussi possible de formuler des critères sur des valeurs de champs qui ne font pas directement partie de la table privilégiée, mais qui font partie d'une table référencée par une relation avec la table privilégiée. Chaque élément <criteria> peut alors contenir un ou plusieurs éléments <link> définissant 15 une relation avec une autre table du modèle de données. Chaque relation est renseignée dans le fichier de configuration sous la forme suivante : <link name="reconciliationJoin" entity="Reconciliation" attribute="reconciliations"/> Où. - le paramètre « name » est un identifiant unique de la relation 20 - le paramètre «entity» est le nom de la table sur laquelle effectuer la relation dans le modèle de données - le paramètre « attribute » est le champ permettant d'effectuer l'opération de jointure avec la table nommée dans le paramètre « entity » Dans le cas ou plusieurs relations sont nécessaires pour accéder à un champ d'une table, 25 plusieurs éléments <link> sont alors indiqués séquentiellement dans le fichier de configuration. Dans le cas ou plusieurs ensembles disjoints de relations sont nécessaires pour accéder à des champs de différentes tables, les éléments <link> du premier ensemble sont indiqués séquentiellement dans le fichier de configuration. Ces éléments sont suivis des éléments 30 <link> du deuxième ensemble. Le premier élément <link> du deuxième ensemble contient l'attribut « restart » avec la valeur « true », indiquant le démarrage d'un deuxième ensemble.

10 Par exemple : <criteria name="sharedAccounts" displayname=" le compte est partagé (compte réconcilié ou non) " category="Critères sur la réconciliation et les usages "> <link name="reconciliationJoin" entity="Reconciliation" attribute="reconciliations"/> <link name="usageJoin" entity="Usage" attribute="usages" restart="true"/> </criteria> Il est enfin possible de renseigner les liens entre la table privilégiée et les autres tables du modèle de données, permettant ainsi au procédé de formulation des critères de requête de proposer de positionner des critères de recherche sur les valeurs et/ou des contraintes de dénombrement sur les relations avec d'autres tables du modèle de données. Chaque élément <query> contient à cet effet un ensemble d'éléments <join> définissant les liens qui peuvent être appliqués par rapport à la table privilégiée. Chaque lien est renseigné dans le fichier de configuration sous la forme suivante : 15 <join name="applicationusage" query="application" displayname="lien avec les applications" comment="usages"> </join> Où: - le paramètre « name » est un identifiant unique du lien - le paramètre « displayname » est le nom du lien tel qu'il va apparaitre dans le 20 procédé de formulation des critères de recherche - le paramètre «comment» est le commentaire tel qu'il va apparaitre dans le procédé de formulation des critères de recherche Chaque élément <join> peut alors contenir un ou plusieurs éléments <link> définissant une relation avec une autre table du modèle de données. 25 Chaque relation est renseignée dans le fichier de configuration sous la forme suivante : <link name="reconciliationJoin" entity="Reconciliation" attribute="reconciliations"/> Où . le paramètre « name » est un identifiant unique de la relation - le paramètre « entity » est le nom de la table sur laquelle effectuer la relation 30 dans le modèle de données - le paramètre « attribute » est le champ permettant d'effectuer l'opération de jointure avec la table nommée dans le paramètre « entity » Dans le cas ou plusieurs relations sont nécessaires pour accéder à un champ d'une table, plusieurs éléments <link> sont alors indiqués séquentiellement dans le fichier de configuration. Par exemple : <join name="applicationusage" query="application" displayname="lien avec les applications" comment="usages"> </criteria> <link name="usageJoin" entity="Usage" attribute="usages"/> <link name="applicationJoin" entity="Application" attribute="application"/> </join> Afin de permettre aux utilisateurs d'effectuer des recherches dans la base de données sans avoir une connaissance préalable ni du modèle de données, ni du langage SQL, l'invention définit un procédé de formulation des critères de recherche. Ce dispositif se présente sous la forme d'une série d'interfaces homme-machine permettant la mise en oeuvre de définitions de requêtes. Les requêtes ainsi définies peuvent être par exemple représentées sous la forme de fichiers XML. Nous détaillons ici le procédé de formulation des critères de recherche ainsi que le fichier définissant les requêtes.

Le procédé de formulation des critères de recherche s'appuie sur le fichier de configuration préalablement défini. L'objet du procédé de formulation des critères de recherche est d'assister l'utilisateur dans la sélection et la combinaison des différents critères qui vont composer la requête, et ceci sans qu'il ait connaissance ni du modèle de données, ni du langage SQL. Pour ce faire, le procédé de formulation des critères de recherche présente à l'utilisateur les critères sous la forme d'éléments de phrases dans la langue de l'utilisateur sur la base des éléments du fichier de configuration. Eléments de phrases qui peuvent-eux même accepter des paramètres. Ces éléments de phrases sont définis dans le paramètre « displayname » des éléments <criteria> du fichier de configuration. Le procédé de mise en oeuvre de la définition d'une requête comporte les étapes de : Sélection de la table privilégiée sur laquelle on souhaite définir une requête, ces tables correspondent aux sections <query> du fichier de configuration 30 Affichage de la liste des critères applicables à cette table sous la forme d'une liste triée par catégorie. Les libellés des critères sont indiqués en langage naturel - Sélection et ajout des critères dans la définition de la requête Dans le cas ou plusieurs critères sont associés directement à une même table, Sélection au niveau de la table de la combinaison logique à opérer entre ces critères (et, ou, non) Association de combinaison logique entre les critères sous la forme de sous-ensembles de critères o II est possible d'associer une combinaison logique à une table et d'associer alors des critères de la table non plus à la table directement mais à cette combinaison logique. La combinaison logique accepte de la même façon que la table la sélection d'une combinaison logique (et, ou, non) dans le cas ou plusieurs critères lui sont associés. Il est enfin possible d'associer une combinaison logique à une combinaison logique. Cette opération permet de gérer la préséance entre les opérateurs logiques. - Association d'une autre table à la table privilégiée. Cette opération se réalise en positionnant sur la table privilégiée la table correspondante. La table correspondante apparait alors avec un lien vers la table privilégiée. cette opération de jointure implicite s'appuie sur les éléments <join> du fichier de configuration. - Association de contraintes de dénombrement sur la jointure précédemment paramétrée. Les contraintes sont les suivantes : o Exactement N résultats o Au moins N résultats o Au plus N résultats o Différent de N résultats o De N1 à N2 résultats o En dehors des limites de N1 à N2 résultats - Association à la table privilégiée du résultat d'une autre règle portant sur la table privilégiée, cette association est réalisée de la même façon qu'une jointure et offre les mêmes caractéristiques et possibilités

13 Sélection d'une table autre que la table privilégiée pour faire apparaitre la liste des critères et des liens associés à cette table. Cette opération est réalisée à l'aide du fichier de configuration. - Réalisation des mêmes opérations sur les tables associées à la table privilégiée qu'à la table privilégiée elle-même o Association de critères o Icônes de combinaison logique o Associations de tables de jointure o Résultats de règles Cette opération est récursive

Afin d'illustrer le procédé de mise en couvre de la définition d'une requête, nous proposons de nous appuyer sur le modèle de données d'exemple fournit dans l'illustration 2.

Le modèle de données d'exemple concerne une application d'audit et de contrôle des habilitations informatiques d'une entreprise. Le modèle présenté est partiel. Il n'a comme propos que d'illustrer la mise en oeuvre de la définition d'une requête. Ainsi, dans notre exemple, la table « identités » {5} contient les utilisateurs des ressources informatiques de l'entreprise.

Ces utilisateurs ont un certain nombre de traits caractéristiques soit directement positionnés sous la forme de champs dans la table {12} {13}, soit positionnés sous la forme de champs dans des tables de jointures {7} {8} {9} {10} : Nom {13} - Prénom {12} - Mail - Téléphone Civilité {7} - Domaine de compétence {9} Métiers et organisations d'appartenance {10} Ces utilisateurs disposent en outre d'un accès aux systèmes informatiques de l'entreprise, ceci est caractérisé par la table : 14 « compte » : Comptes utilisateurs {14} dans les référentiels d'applications de l'entreprise {15} La sélection de la table « identités » comme table privilégiée fait apparaitre l'illustration 3. Les critères sont affichés sous forme d'éléments de question de telle sorte qu'ils soient 5 directement compréhensibles par les utilisateurs {16}. La sélection des critères conduit à définir une requête {17}, telle qu'illustrée dans l'illustration 4. On voit apparaitre des critères paramétrés {18} {19} {20}, des opérateurs logiques {21} et une icône de combinaison logique {22}. La requête paramétrée en figure 5 permet ainsi 10 de rechercher les utilisateurs « interne » {18} de l'entreprise qui ont un matricule qui commence par ID {19} ou un matricule qui commence par AZ {20}. La liste des critères disponible fait aussi apparaitre la liste des liens possibles depuis cette table {23}, la sélection du lien « liens avec les comptes » {24} permet de paramétrer des critères supplémentaires sur les comptes associés à l'utilisateur. 15 Ainsi l'illustration 5 ajoute une contrainte supplémentaire : les utilisateurs doivent en plus des conditions précédentes disposer d'au moins un compte {25} dont l'identifiant est «Administrateur» {26}. Il est à noter que les critères qui apparaissent sur l'illustration 5 sont maintenant des critères de « comptes » {27}, dans la mesure où le paramétrage s'effectue maintenant au niveau de la sous table « comptes » de la table privilégiée. 20 Le procédé graphique de formulation des requêtes permet, en suivant les contraintes ainsi définies, de reformuler l'ensemble des critères composant la requête sous une forme textuelle compréhensible sans une connaissance préalable du modèle de données ou du langage SQL. Ainsi l'exemple précédent donne, lorsque l'invention parcourt les différents noeuds composants les contraintes : 25 Recherche des Identité(s) dont - la personne est interne {18} - et {21} au moins une des conditions suivantes est respectée {22} o le matricule ressemble à'ID%' {19} ^ ou le matricule ressemble à 'AZ%' {20} 30 - et {21} il existe au moins un Compte, respectant la condition suivante {25} o l'identifiant du compte est égal à 'Administrateur' {26}

15 Le procédé de formulation des critères de recherche définit les requêtes sous la forme, par exemple, de fichiers XML. Ce sont ces fichiers, associés au fichier de configuration, qui vont indiquer au procédé d'extraction des données de quelle façon formater les requêtes SQL sur la base de données. Une requête est renseignée dans le fichier de définition de requête sous la forme suivante : <Request name="br_gapanalysis_orphanaccounts" operator="and" query="account" displayname="Comptes orphelins"> </Request> Où. le paramètre « name » est un identifiant unique de la requête le paramètre «query» identifie la table privilégiée sur laquelle effectuer la requête. La valeur de ce paramètre correspond à la valeur du champ « name » de 15 l'élement <query> du fichier de configuration. Le paramètre « displayname » correspond au libellé qui est affiché dans les interfaces utilisateurs du procédé d'extraction des données. - Le paramètre « operator » identifie la combinaison logique à effectuer entre l'ensemble des critères qui dépendent directement de cette requête. 20 Chaque requête peut contenir un ensemble de critères paramétrés. Ces critères sont renseignés dans le fichier sous la forme : <RequestCriteria name="C1287156116796_10" criteria="egHrCode"> </RequestCriteria> Où. - le paramètre « name » est un identifiant unique du critère paramétré - le paramètre « criteria » est une référence au champ « name » d'un élément <criteria> du fichier de configuration Lorsqu'un critère paramétré accepte des paramètres, ces paramètres sont renseignés dans le fichier sous la forme : <RequestCriteriaParam name="hrCodeParam" ignoreifempty="false"> <Value name="0" data="ID0000100"/> </RequestCriteriaParam> 25 30 16 Où. - le paramètre « name » est un identifiant unique du paramètre du critère paramétré le paramètre « ignoreifempty » indique si ce critère est pris en compte quand bien 5 même aucune valeur n'a été affectée au paramètre - Le paramètre « data » des sous éléments <value> indiquent les valeurs paramétrées pour ce paramètre de critère Une requête peut recevoir le résultat d'une autre requête paramétrée. La requête à intégrer est renseignée dans le fichier sous la forme : 10 <Requestlmport name="11287156213700_18" request=-"br_caracteristic_isorg"> </Requestlmport> Où. - le paramètre «name » est un identifiant unique du paramètre du critère paramétré 15 - le paramètre « request » est l'identifiant de la requête dont le résultat est à intégrer. La valeur de ce paramètre correspond à la valeur du champ « name » de l'élément <Request> de la requête dont le résultat est à intégrer. Une requête peut s'appuyer sur des informations des jointures pour définir des contraintes supplémentaires. La jointure est renseignée dans le fichier sous la forme : 20 <RequestJoin urne-11287156195718" operator="and" join="uporganisation" countOperator="least" countNumberl="1" countNumber2="0"> </RequestJoin> Où. le paramètre « name » est un identifiant unique du paramètre du critère paramétré Le paramètre «operator» identifie la combinaison logique à effectuer entre l'ensemble des critères qui dépendent directement de cette jointure - le paramètre « join » fait référence à la jointure paramétrée dans le fichier de configuration : le paramètre « name » de l'élément <join> le paramètre «countOperator» s'il est présent définit la contrainte de dénombrement à appliquer sur la jointure, il peut prendre les valeurs suivantes : o least : Au moins « countNumberl » résultats 25 30 o most : Au plus « countNumberl » résultats o exact : Exactement « countNumberl » résultats o different : Différent de « countNumberl » résultats o in : De « countNumberl » à « countNumber2 » résultats ^ out : En dehors des limites de « countNumberl » à « countNumber2 » résultats Les paramètres « countNumberl » et « countNumber2 » sont présents si et seulement si une contrainte de dénombrement est à appliquer sur la jointure. Ces paramètres contiennent des valeurs numériques qui permettent de paramétrer la contrainte de dénombrement Une requête peut aussi recevoir une icône de combinaison logique entre critères. Ces combinaisons logiques sont renseignées dans le fichier sous la forme : <RequestGroup name="G1287156138557" operator="or" inverse="true"> </RequestGroup> Où . - le paramètre « name » est un identifiant unique de la combinaison logique - Le paramètre « operator » identifie la combinaison logique à effectuer entre l'ensemble des critères qui dépendent directement de cette combinaison Le paramètre « inverse » identifie s'il faut effectuer un « non logique » entre l'ensemble des critères qui dépendent directement de cette combinaison

Les éléments <RequestGroup> peuvent accepter indifféremment des sous éléments <RequestCriteria>, <Requestlmport>, <RequestJoin> ou <RequestGroup>. Les éléments <RequestJoin> peuvent accepter indifféremment des sous éléments <RequestCriteria>, <Requestlmport>, <RequestJoin> ou <RequestGroup>.

Ainsi, le paramétrage effectué en exemple et illustré par l'illustration 5 conduit à générer le fichier de requête suivant : <Request name="rb2" operator="and" query="identity" displayname="Regle exemple"> <RequestCriteria name="C1287390260133_9" criteria="eglnternal"> </RequestCriteria> <RequestGroup name="G1287390267341" operator="or"> 30 5 10 15 20 2530 18 <RequestCriteria name="C1287390272660_10" criteria="IikeHrCode"> <RequestCriteriaParam name="hrCodeParam" ignoreifempty="false"> <Value name="0" data="ID%"/> </RequestCriteriaParam> </RequestCriteria> <RequestCriteria name="C1287390275235_11" criteria="IikeHrCode"> <RequestCriteriaParam name="hrCodeParam" ignoreifempty="false"> <Value name="0" data="AZ%"/> </RequestCriteriaParam> </RequestCriteria> </RequestGroup> <RequestJoin name="J1287390296436" operator="and" countOperator="least" countNumberl="1" countNumber2="0" join="accountreconciliation"> <RequestCriteria name="C1287390301797_14" criteria="egldentifier"> <RequestCriteriaParam name="identifierParam" ignoreifempty="false"> <Value name="0" data="Administrateur"/> </RequestCriteriaParam> </RequestCriteria> </RequestJoin> </Request>

Afin de permettre aux utilisateurs d'effectuer des recherches dans la base de données sans avoir une connaissance préalable ni du modèle de données, ni du langage SQL, l'invention définit un procédé d'extraction des données de la base de données. Ce procédé s'appuie sur les différents fichiers de paramétrage mis en oeuvre à l'aide du procédé de formulation des critères de recherche. Nous détaillons ici le procédé d'extraction des données de la base de données.

Le procédé d'extraction de la base de données a pour objectif d'extraire de la base de données un ensemble de références vers la table privilégiée en appliquant les différents critères de recherche d'une requête paramétrée. Pour ce faire, le procédé d'extraction de la base de données comporte les étapes de : - analyse le fichier de requête paramétrée. o Pour chaque élément du fichier de requête de type <RequestCriteria> ou <RequestJoin> le procédé d'extraction de la base de données récupère dans le fichier de configuration les éléments de configuration correspondant lui permettant de formuler les critères SQL ainsi que les contraintes de jointure de la requête. o Pour chaque élément du fichier de requête de type <RequestGroup> le procédé d'extraction de la base de données réalise une combinaison logique sur les critères SQL formulés par le procédé d'extraction de la base de données. o Pour chaque élément du fichier de requête de type <Requestlmport> le procédé d'extraction de la base de données formule les critères SQL ainsi que les contraintes de jointure de la requête visés par la règle à importer avant de les réintégrer dans la requête en cours de construction. Ce procédé est récursif de telle sorte qu'au final, une seule requête SQL est générée et envoyée pour exécution au système de base de données. o Pour chaque élément de type <customrestriction> du fichier de configuration, une requête SQL particulière est générée par le procédé d'extraction de la base de données et exécutée auprès du système de base de données. Le résultat de cette requête SQL est réintégré dans la requête en cours de construction. - Exécution de 1 à n requêtes SQL auprès du système de base de données afin de consolider la liste des références vers les éléments de la table privilégiée correspondant aux différents critères de la requête.

30 Ainsi, l'exemple illustré en figure 6 conduit le procédé d'extraction de la base de données à reformuler la requête en générant la requête SQL suivante : 10 15 20 25 5 20 select distinct this_.CRECORDUID as y0_ from TIDENTITY this_ left outer join TRECONCILIATION x1x1_ on this_.CRECORDUID=x1x1_.CIDENTITYFK left outer join TACCOUNT x2x2 on x1x1 .CA00OUNTFK=x2x2 .CRECORDUID where this .CENDDATE is null and ((this_.CINTERNAL=? and (lower(this_.CHRCODE) like 'az%' or lower(this_.CHRCODE) like 'az%')) and (x2x2_.CIDENTIFIER='Administrateur' and x2x2_.CRECORDUID is not null)) Cette requête retourne une liste de référence vers les éléments de la table privilégiée « identités » sur la base de critères de recherche paramétrés à l'aide du procédé de formulation des critères de recherche. 10 15 20 25 30

Claims (4)

1. REVENDICATIONS1- Procédé d'interrogation d'une base de données à l'aide de requêtes SQL exécutées sur un système de base de données, ladite base de données comportant : plusieurs tables, chacune avec un ou plusieurs champs ; des relations entre les différentes tables ; Le procédé comportant les étapes de : dans une étape de configuration, renseigner d'informations de configuration comportant les étapes consistant à :; o renseigner la table privilégiée sur laquelle formuler la requête, les résultats de la requête étant ensuite exprimés sous la forme d'un ensemble de références vers des enregistrements de cette table ; o renseigner un ou plusieurs critères de recherche portant sur les champs de la table privilégiée à l'aide d'une description de chaque critère dans un langage naturel et d'une traduction correspondante en langage SQL, des opérateurs logiques pouvant être positionnés entre les différents critères (ET, OU, NON); o associer ou non à cette table privilégiée des informations de jointure vers des tables sur lesquelles on souhaite positionner un ou plusieurs critères de recherche portant sur les champs de ces tables ; o renseigner ou non des contraintes de dénombrement sur les informations de jointure afin de prendre en compte le nombre de liens entre la table privilégiée et les tables associées (par exemple au moins n, au plus n, exactement n, ...) ; o recommencer ou non de façon récursive sur chacune des tables jointes les opérations précédentes, à savoir : ^ renseigner ou non sur les tables jointes un ou plusieurs critères de requête portant sur les champs des tables jointes, des opérateurs logiques pouvant être positionnés entre les différents critères (ET, OU, NON) ;^ associer ou non aux tables jointes des informations de jointure vers des tables sur lesquelles on souhaite positionner un ou plusieurs critères de recherche portant sur les champs de ces tables ; ^ renseigner ou non des contraintes de dénombrement sur les informations de jointure afin de prendre en compte le nombre de liens entre la table privilégiée et les tables associées (par exemple au moins n, au plus n, exactement n, ...) ; - dans une étape de définition d'une ou plusieurs requêtes : sélection d'une table privilégiée, affichage de la description dans un langage naturel des critères de recherche renseignés pour la table privilégiée sélectionnée, et sélection parmi lesdits critères, des critères associés à la requête ; - dans une étape d'extraction : o reformuler, par un procédé automatique, ladite ou lesdites requêtes en langage SQL, en fonction des requêtes définies et des traductions en langage SQL correspondant dans les informations de configuration aux critères sélectionnés, en mentionnant complètement: ^ les tables identifiées contenant les champs sur lesquels des critères de recherche sont appliqués ; ^ les jointures représentatives des relations entre les différentes tables ; ^ les contraintes de dénombrement sur les différentes jointures ; ^ les critères de recherche sur les champs ; o appliquer, par un procédé automatisé, l'ensemble de requêtes SQL sur la base de données et consolider les résultats obtenus sous la forme d'une liste d'enregistrements de la table privilégiée.
2. 2 - Procédé selon la revendication 1, caractérisé en ce que les informations de configuration contiennent pour chaque table privilégiée la description de l'ensemble des critères qui peuvent être appliqués, ainsi que la description de l'ensemble des relations vers les autres tables privilégiées.
3. 3 - Procédé selon la revendication 1 ou 2, caractérisé en ce que les informations de configuration sont définies sous forme déclarative une fois pour toute, pour un modèle de données sélectionné 20 25 30
4. 4 - Procédé selon l'une des revendications précédentes, selon lequel l'étape de définition d'une ou plusieurs requêtes comporte les étapes de : sélection de la table privilégiée sur laquelle on souhaite définir une requête ; affichage de la liste des critères applicables à cette table sous la forme d'une liste triée par catégorie ; les libellés des critères étant affichés en langage naturel ; sélection et ajout des critères dans la définition de la requête ; dans le cas ou plusieurs critères sont associés directement à une même table, sélection au niveau de la table de la combinaison logique à opérer entre ces critères parmi les combinaisons logiques « et », « ou », « non » ; association de combinaison logique entre les critères sous la forme de sous-ensembles de critères, - association d'une autre table à la table privilégiée ; cette opération se réalisant en positionnant sur la table privilégiée la table correspondante et la table correspondante apparaissant alors avec un lien vers la table privilégiée ; association de contraintes de dénombrement sur la jointure précédemment paramétrée ; Les contraintes étant les suivantes : o exactement N résultats o au moins N résultats o au plus N résultats o différent de N résultats o de N1 à N2 résultats o en dehors des limites de N1 à N2 résultats association à la table privilégiée du résultat d'une autre règle portant sur la table privilégiée, cette association est réalisée de la même façon qu'une jointure et offre les mêmes caractéristiques et possibilités ; - sélection d'une table autre que la table privilégiée pour faire apparaitre la liste des critères et des liens associés à cette table ; - réalisation des mêmes opérations sur les tables associées à la table privilégiée qu'à la table privilégiée elle-même : o association de critères ; o combinaisons logique ; o associations de tables de jointure ; 4 o résultats de règles Cette opération étant récursive. - Procédé selon la revendication selon l'une des revendications précédentes, caractérisé en ce que l'étape de définition de requête définit les requêtes sous la forme de fichiers et 5 que dans l'étape d'extraction, le formatage des requêtes en langage SOL est réalisé en fonction de ces fichiers et des informations de configuration. 6 - Procédé selon l'une des revendications précédentes, selon lequel l'étape d'extraction de la base de données comporte les étapes de : - analyse de la requête définie sous la forme d'un fichier de requête paramétrée : o pour chaque élément du fichier de requête de type <RequestCriteria> ou <RequestJoin>, récupération dans les informations de configuration des éléments de configuration correspondant permettant de formuler les critères SQL ainsi que les contraintes de jointure de la requête ; o pour chaque élément du fichier de requête de type <RequestGroup>, combinaison logique sur les critères SQL formulés par l'étape d'extraction de la base de données ; o Pour chaque élément du fichier de requête de type <Requestlmport>, fomulation des critères SQL ainsi que des contraintes de jointure de la requête visées par la règle à importer avant de les réintégrer dans la requête en cours de construction ; ce procédé étant récursif de telle sorte qu'au final, une seule requête SQL est générée et envoyée pour exécution au système de base de données ; pour chaque élément de type <customrestriction> des informations de configuration, formulation d'une requête SQL particulière lors de l'étape d'extraction de la base de données et exécution auprès du système de base de données ; le résultat de cette requête SQL étant réintégré dans la requête en cours de construction. - exécution de 1 à n requêtes SQL auprès du système de base de données afin de consolider la liste des références vers les éléments de la table privilégiée 30 correspondant aux différents critères de la requête. 7 - Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il est possible d'appliquer des critères suivant des algorithmes qui ne sont pas présents nativement dans le langage SQl en faisant référence vers une fonction d'une librairie informatique externe au logiciel de gestion de bases de données 5 10 15 20 25 30