FR3006787A1 - METHOD AND DEVICE FOR FACILITATED INTERROGATION OF A RELATIONAL DATA BASE - Google Patents

Abstract

The invention relates to Device (D) for interrogating a relational database (DB) consisting in interpreting a command (M) for generating a set of queries (Rq) in SQL language intended for a management system (DBS) ) of the database, in which the command conforms to a grammar distinct from the SQL language and interpreted using a set of configuration files (CF).

Description

FIELD OF THE INVENTION The invention relates to relational database management systems and in particular to the interrogation of data bases. such systems by users.

BACKGROUND OF THE INVENTION Relational databases are data structures organized in the form of tables within which data is indexed by means of keys.

Typically, a table has a set of records (or "rows") indexed by a primary key. The "columns" of the table represent the fields. A record has a value for each of the fields in the table. The tables can refer to each other in order to structure the information, by including a field whose value is a key (then called "foreign key") corresponding to a record of another table. It is well known to associate a relational database with a management system to provide an interface for users of the database that is independent of the physical structure of the database. Figure 1 illustrates a typical high-level architecture for implementing a relational database. A user U can access the DB database through a DBS database management system. The DB database and the DBS management system can belong to the same functional server S. 852-EN-014146-patentapplication-final 2 From a functional point of view, this DBS database management system can decompose schematically into an access interface to the data AI and a processing interface of the requests RI. The AI data access interface aims to manage the physical implementation specificities of the DB database, for example to manage the aspects of redundancies, the distribution on remote and possibly multiple server machines, to manage the various protocols. possible access to manage potential access to competitors, etc. The RI request processing interface provides a unified interface to the user U, regardless of the underlying DB database. This interface conventionally makes it possible to interrogate the database with Rq requests and to receive Rp responses. The interrogation is generally in accordance with a structured query language such as the SQL language (for "Structure Query Language" in English) which is standardized by both the International Standard Organization (ISO) and the American National Standards Institute (ANSI). This SQL language allows, by means of a set of commands (called "requests"), to manipulate the data within the database DB. These commands can be used to search, add data, update (or modify) existing data, erase data, create or delete tables, and more. This language makes it possible to offer a universal interface, so that its knowledge allows a user to interact with all the databases. However, its use remains difficult because it requires a good knowledge of the topology of the underlying database DB, that is to say the name of the tables and the links that exist between the tables. Some DB databases can be very complex and contain a very large number of tables, and this knowledge can be difficult to acquire and requires a prior investment for the user U. In addition, even if you know the topological structure of the DB database, if it is at least a bit complex, querying the DB database may require several SQL queries. The process is therefore tedious, long and therefore expensive in the context of industrial or professional use. In addition, it can result in a significant risk of errors, including a risk of forgetting to fill a field in a query.

SUMMARY OF THE INVENTION The object of the present invention is to provide a solution at least partially overcoming the aforementioned drawbacks. To this end, the present invention provides a method of querying a relational database of interpreting a command to generate a set of SQL queries for a management system of said database, wherein said command is consistent with a distinct grammar of the SQL language and in which said queries are generated according to the structure of said relational database. According to preferred embodiments, the invention comprises one or more of the following features which can be used separately or in partial combination with one another or in total combination with one another: said command is intended to add data within said database relational and comprises at least one object, said at least one object having a type and a list of fields associated with said type, said type corresponding to a table of said 852-EN-014146-patentapplication-final 4 database and each of said fields corresponding to a field of said table; assigning a value to a field of a first object is automatically reused for a field of a second object, said first and second objects belonging to said at least one object; a value is assigned to a field of said database based on indications provided by configuration files associated with said device, said indications specifying a mechanism for determining said value.

Another aspect of the invention relates to a computer program comprising instructions which, when loaded onto an information processing system, are able to implement the previously described method.

Another aspect of the invention relates to a device for querying a relational database consisting of interpreting a command to generate a set of SQL queries for a management system of said database, wherein said The command conforms to a separate grammar of the SQL language and interpreted using a set of configuration files. According to preferred embodiments, the invention comprises one or more of the following characteristics that can be used separately or in partial combination with one another or in total combination with one another: the device has a command processing module for receiving said command intended to add data within said relational database and comprising at least one object, said at least one object having a type and a list of 852-EN-014146-patentapplication-final fields associated with said type, said type corresponding to a table of said database and each of said fields corresponding to a field of said table; the device has means for automatically reusing an assignment of a value to a field of a first object for a field of a second object, said first and second objects belonging to said at least one object; a value is assigned to a field of said database according to indications provided by configuration files associated with said device, said indications specifying a mechanism for determining said value; the device further comprises a generation module for processing a first configuration file of said configuration files and generating a second configuration file interpretable by said command processing module. Other features and advantages of the invention will appear on reading the following description of a preferred embodiment of the invention, given by way of example and with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 schematically represents a functional architecture of a system composed of a database and a management system, according to the state of the art. FIG. 2 diagrammatically represents a functional architecture of a system composed of a database and a database management system, according to the invention. Figure 3 illustrates an example structure of a relational database. FIG. 4 schematically represents a functional architecture of a system composed of a database and a management system, in accordance with an implementation of the invention. Figure 5 illustrates an example structure of a relational database. DETAILED DESCRIPTION OF THE INVENTION FIG. 2 represents a possible implementation of the invention in which a device D has been inserted between the DBS management system of one or more DB databases and the user (s) U. Through this device D, the user U can access the database DB via the database management system DBS.

The database DB and the management system DBS can belong to the same functional server S. This functional server S can of course be implemented in different ways. It can for example be a single physical server (that is to say a computer), or several computers: in particular the DBS management system can be deployed on a machine different from that on which is deployed the DB database. It can also be planned to deploy the database (and the DBS management system) on a plurality of machines connected to a network. This plurality of connected machines can even form a computer farm. Other implementations are of course possible. Also from a functional point of view, this DBS database management system can be schematically broken down into an AI data access interface and an RI request processing interface. 852-EN-014146-patentapplication-final 7 The AI data access interface aims to manage the physical implementation specificities of the DB database, for example to manage aspects of redundancy, distribution on server machines remote and possibly multiple, to manage the various possible access protocols, to manage the possible competitors access, etc. The RI request processing interface provides a unified interface to the user U, regardless of the underlying DB database. This interface conventionally makes it possible to interrogate the database with Rq requests and to receive Rp responses. The interrogation is generally in accordance with a structured query language such as the SQL language (for "Structure Query Language" in English) which is standardized by both the International Standard Organization (ISO) and the American National Standards Institute (ANSI). In practice, the access interfaces to the data AI and the processing of the requests RI can be implemented by software modules separate from the management system DBS or be integrated within the same software module. The architecture of the functional server S comprising the database DB and the management system DBS can be in accordance with the various solutions proposed by the state of the art and therefore different implementations are accessible to those skilled in the art. One aspect of the invention relates to this device D for interrogating a relational database DB. It can be realized in different ways and in particular it can be deployed on the same machine as the DBS management system or on a separate machine. This device makes it possible to present to users U a different interface of the SQL language and can thus act as a higher-level interpreter: the user can transmit M commands according to a given grammar, distinct from the SQL language, the device D has 852 -EN-014146-patentapplication-final 8 software means to interpret these commands and generate a set of SQL queries for the DBS management system. This interpretation can be done using a set of CF configuration files.

The set of configuration files, as well as the set of SQL Rq queries can be reduced to singletons. However, one of the advantages of the invention is to allow the user U to write a single command having the same effect as a plurality of SQL queries. It thus simplifies the task of the user U and also avoids errors inherent to the writing of complex and numerous SQL queries. According to one embodiment of the invention, the grammar makes it possible to specify one or more objects in an order M. For some object, it is possible to indicate a type and to associate a list of fields with it. The command M can for example be interpreted first by a software application type "Shell" on a operating system of the Unix family. In this case, it may include a keyword allowing this application "shell" to identify the device D and to transmit the command M received. In addition, the device D can implement different mechanisms including mechanisms distinct from those of the invention. Also, the command M may include a keyword to identify these mechanisms.

Such a command can for example have the form: Command adds objetl, object2, objet3 ... The keyword "command" indicates that it is a command addressed to the device D. 852-FR- 014146-patentapplication-final 9 The keyword "add" indicates that this is a command to add data to the DB relational database. It allows to implement the mechanisms of the invention. The command M then comprises at least one object, objectl, object2, object3 ... These objects make it possible to specify the data that must be added within the database DB. They can have a type and a list of fields associated with this type. A possible syntax is for example in the following form: Type = (fields1, fields2, fields3 ...) The type is used to identify a table in the DB database. The fields correspond to the fields (or column) of this table. A field in the command can contain the name of the table field and either a value or a filter. A field can therefore have one of the following forms: Name field = value Name field, [filter] The right sides can thus make it possible to indicate that one is dealing with a filter and not with a value. A filter allows you to select one or more records in the DB database.

For example, the field next to equipment, [name = node *] means that one wishes to select all the equipment whose field "name" has a value starting the string "node".

Figure 3 shows an example structure of the database DB, containing 7 tables, T1, T2, T3, T4, T5, T6, T7. Each table is identified by a name (indicated in the shaded area at the top of each table) and has several fields (or lines, shown below). Key-shaped symbols indicate the keys for each table-852-EN-014146-patentapplication-final. The tables are linked together in a conventional manner in a relational database. For the purpose of this example, it is assumed that the "Type" table already contains the following records: Aircraft Type Capability Id A340 200 2 A320 400 2 B747 500 1 B787 250 1 It is also assumed that the "Constructor" table also contains the corresponding records. primary keys 1 and 2 (respectively with the value of BuilderName, Airbus and Boeing). It is also assumed that we want to create a new airport, "Strasbourg Entzheim", assign it A300 series aircraft (ie A320, A340 ...), and assign two flights, one in from Paris and one to Paris. A possible command can be: Command add airport = (name = SXB, ServicedCityName = StrabourgEntzheim), plane, (plane, [airplane type = A31), flight = (Departing airport = SXB, departureTime = 1230, arrivalTime = 1500, AirportArrivee = ORY) , flight = (Departing airport = ORY, departureTime = 1630, arrivalTime = 1800, arrivalPort = SXB) This command therefore contains a first object concerning the type "Airport". This type corresponds to the "Airport" table and is associated with the list of fields enclosed in parentheses. In this first object, two fields are present that contain a field name and a value. The device D can check if there are missing mandatory fields for the type / table "Airport". Indeed, the device D can process the 852-EN-014146-patentapplication-final 11 command M according to the structure of the relational database. According to the invention, the device maintains a knowledge of the structure of the database DB in order to be able to interpret the commands M without these (and therefore the user M) needs to make them correspond exactly to this structure : the device allows to make an intelligent mediation to "hide" the structure of the database. This is not the case here: all fields are present. If a required field was missing, the device may be provided to reuse an assignment of a value to a field of another object for that field. According to one implementation, the device will search in the previous objects within the command M if this field has already been filled (by a value or by a filter). In other words, each assignment of a value or a filter to a given field is stored in memory by the device D so that it can be used again for a next object. This mechanism allows U users to not have to specify the same data multiple times, contrary to what is necessary when writing queries in SQL. This advantage will appear more clearly later. The first object can generate a query in the following SQL language: INSERT INTO airport (AirportName, ServicedCityName) SELECT 'S XB', 'S trasb ourgEntzheim' The second object, 'airplane, (airplane4typeAplane, A31)' populates the table ' Plane ". A filter has been specified for the "aircraftType" field to select all types of aircraft whose type name begins with the string "A3". As a result, two "aircraft" are added to the "Airplane" table, one for the "A320" type and one for the "A340" type. The device checks whether the required fields are all present in the corresponding object. Here, the "BaseAirport" field is missing. However, the airport was mentioned in the previous object. According to the mechanism previously described, this assignment can be reused here in order to assign the value "SXB" to the "Base Airport" field. An SQL query of the following form is then generated: INSERT INTO plane (AircraftType, BaseAeroport) SELECT tO.TypeAvion, '56' FROM type tO WHERE airplaneType = 'A3 %%' As previously, device D can use its knowledge of the structure of the database DB to generate such a request.

This knowledge may be partially prior to the receipt of the command M (in particular on the topological structure) but also updated and completed upon receipt of each command M (including the content of the database DB). Thus, the device automatically generates a predicted SQL query to search for information and link to the "Type" table. This is done transparently for the user U. Similarly, the foreign key "56" corresponding to the field "BaseAeroport" is automatically assigned by the device D. It corresponds to the primary key of the registration associated with the airport name "SXB". This key can be found by a simple request in the database DB or it was stored when adding the airport "SXB" in the database. The following two objects relate to the "Flight" type. Two flights are added and the device D can generate two requests in SQL language: 852-EN-014146-patentapplication-final 13 INSERT INTO flight (airportpart, AerorportArrivee, startTime, hourArrivee) SELECT `SXB ',' ORY '1230', ' 1500 'INSERT INTO flight (airportDepart, AerorportArrivee, StartTime, HourArrivee) SELECT' ORY, `SXB '1800', '1930' In case a request omits a mandatory field but it can not be found on the base of the previous objects of the request, it is possible to generate an error message for the user U. The device D can then interrupt the processing or invite the user to indicate the value (or the filter) for the field missing and, once informed, continue the treatment. In addition, it may be provided to implement an acronym system to further facilitate the use of the invention.

The configuration files CF can indeed contain a table mapping an acronym to a table or field in the database. The command C can then mention the acronyms instead of the names of tables or fields, and the device D can use the correspondence table contained in the configuration files CF to generate the SQL queries with the names corresponding to these acronyms. Thus, the device D may make it possible to propose a more abstract view of the database to the user U: the names are dependent on the designer of the database DB and are not necessarily very meaningful and practical for the user U. It can define in a configuration file these acronyms especially for the tables and fields it uses most often. It can write M commands faster, more efficiently and with much less chance of errors. Consequently, a type within an M command corresponds to a table of the database but this correspondence can be indirect 852-EN-014146-patentapplication-final 14 and go through the use of a correspondence table or by other mechanisms of indirection. The same goes for the correspondence between the fields associated with the types in the command M and the fields of the tables of the database DB.

A second embodiment of the invention consists in making use of configuration files CF previously prepared in a particular way for interpreting the commands M and generating the commands in the SQL language, Rq.

In particular, these configuration files can be used to make it possible to decide on a behavior to adopt in case of absence of assignment of a value to a field for a given object. It can then be indicated within these CF configuration files to ask the user to indicate the value for the missing field, or a method to automatically determine this value. According to one embodiment, when a field of an object is not filled in the command and this field is however mandatory, so as not to introduce inconsistency in the database DB, the device D can be intended to - reuse an assignment of a value in another object for that field, as previously described. Use the indications provided by the configuration files to determine this value. These two options can be implemented in sequence by the device D so that the indications of the configuration files are used only in the absence of the supply of a value of this field in the set of objects of the command M. The indications provided by the configuration files CF make it possible to specify a mechanism for determining said value. 852-EN-014146-patentapplication-final 15 These indications can be determined from other configuration files and the structure of the DB database. The device D can therefore have two distinct functions: the generation of these indications and the generation of the SQL queries. These two functions can be implemented by two functional modules of the device D, as indicated in FIG. 4. These two modules can be separate computer programs or two modules of the same computer program. An MI generation module is used to generate the indications in one (or more) first CFI configuration files from one (or more) seconds of CFO configuration files and the structure of the DB database. Figure 5 shows an example structure of the database DB, containing 5 tables, T1, T2, T3, T4, T5. This example is simplistic since it contains only a small number of tables but it makes it possible to clearly understand the mechanisms involved in the invention. It can apply to a database for an article trade. Each article belongs to a category of articles (for example a brand, a series ...). The database also stores item orders. A command maps an article to a person: the "Correspondence" table contains foreign keys from the "Article" table and the "Person" table, as well as a quantity and a price. Finally, a "Transaction" table is added; a transaction can reference multiple item orders. A first CFO configuration file can be as follows: 30 852-EN-014146-patentapplication-final 16 Person.CommandArticle.research.type = intelligent Person.CommitArticle.research.value = same (Person.name = Def ault ) Person.default = name: Lastname, firstname: Firstname, login: Lastname- Firstname, lastname: 0000 ArticleCommand.ArticlesSearching.type = smart OrderArticle.Articlesresearch.value = no longer present (ItemControl.id article) ItemCommand.Transaction.research .type = intelligent ArticleOrder.Transaction.research.value = evaluates (item ID, quantity) ItemControl.No.customer.research.type = smart ItemControl.No.customer.research.value = same (Person.name = No m) ItemControl.default = quantity : 0, price quote: 0 Transaction.CommitArticle.research.type = smart Transaction.CommitArticle.research.value = most recent () Trans action.default = transaction price: 100, date: 01/01/2001 Article. Category.Search.Type = Smart Article.Category. search.value = identical (category name = Default) Article.default = article name: Article, price: 100, description: none Category.Article.research.type = intelligent Category.Article.research.value = identical Category.name category = test) Category.default = name category = test, description: none, unit: none This CFO configuration file can be written once and for all by a database user, but can be modified easily at any time. It is an advantage of the invention to be able to easily modify this configuration file without having to touch the content or the structure of the DB database. 852-EN-014146-patentapplication-final 17 This CFO configuration file makes it possible to specify by means of indications the mechanism to be used to determine a missing field value. These indications are introduced, in this example of implementation, according to the following grammar: Table.champ.recherche.X = value For each table, one can thus indicate a distinct behavior according to the fields. The keyword "search" introduces the indications in question. The character "X" indicates that several indications are possible.

In the example above, these indications are "type" and "value". The "Type" indication indicates the type of behavior to be used to search for the value. It allows to specify whether to interrogate the user in interactive mode or, as here with the keyword "smart", whether to automatically determine this value, or other behaviors again. The indication "Value" makes it possible to specify how the value must be determined. It is not useful in the "interactive" mode but allows, in the "intelligent" mode to indicate several possibilities to automatically determine the value.

For example, keyword representatives of functions can be embedded in the grammar to help indicate rich behaviors. For example: "identical (diltre>)" allows to select an element of the table according to the given filter. "No longer present (<column>)": selects the most present element in the given column "uses existing (<table>, <filter>)": uses an already existing element in the input table 852-EN- 014146-patentapplication-final 18 "copy (<table>, <filter>, <difference>)": copy of an existing item into the table by changing something according to what has been given in <difference> "available ( <table>, <filter>): list the elements of a table with a filter if necessary (set to NULL if not necessary) It is also possible to specify default values for the creation of a new record. a table according to the grammar: Table.defaut = valeurl, valeur2 ...

This default value can be used if the chosen behavior is a "default" mode, or if the search triggered by the "smart" behavior does not succeed. This first configuration file CFO can be processed by the module MI of the device D. This module MI will generate interpretable indications by the command processing module MR of the device D. These interpretable indications are inserted into second CFI configuration files. For example, they can conform to an XML ("eXtensible Markup Language") grammar, standardized by the W3C (World Wide Web Consortium). The generation of these indications is carried out also from the knowledge of the structure of the DB database that owns (or acquires on demand) the generation module MI of the device D. It can be generated a file (or a part of it). CFI configuration file) for each table in the database, or at least for each "main" table in the database: the user can specify the tables for which he wants to generate a CFI configuration file . For a given table, the MI retrieves the fields from the table from its knowledge of the DB database and uses the first 852-EN-014146-patentapplication-final 19 CFO configuration file to generate rows (in XLM ) of the second CFI configuration file. Then, recursively, it processes in the same way, the tables of the base which are related to this first table.

The grammar of the generated file can for example be in the following form: <table 1 occurrence, "1"> <table2 mandatory, "no" occurrence, "1" fk, "table2 id" pk, "id" output = " name "> <interactive> Which table2 do you want to link to this table? </ interactive> <type search =" smart "> the most present </ search> <available> available (<table>, <filter>) </ available> <default> colonnel, xxx, column2 = yyy, column3 = zzz </ default> </ table2> </ tablel> The term "occurrence" represents the number of items that can be added to the table (this number is either 1 if the current table contains the key that points to another table, ie multiple if it is a key from another table that points to the current table) The term "mandatory" indicates if the field is mandatory ? (If it is not, then it will not be added if there is no specified search method). The term "fk" is the foreign key to which the initial table points The term "pk" is the primary key of the pointed table The term "output" is the column to be displayed, if it is necessary to display a column of the new added element (There may be several) 852-EN-014146-patentapplication-final 20 The term "interactive" indicates the question to ask the user if one is in the interactive mode. The term "search" indicates the search method of the field to be added (not used in interactive mode).

The term "available" indicates the elements shown to the user in interactive mode to help him know the available elements (by default, the algorithm searches the most present in the table). Finally, the term "default" indicates a default value of the columns (if applicable). Thus, for the example given below, a CFI configuration file in XML language can be: <ArticleCommand occurrence = 1> <Mandatory article = yes instance = 1 fk = article id pk = article ID output = article name> <interactive> To which Article do you want to link ArticleOrder? </ interactive> <type search = intelligent> no longer present (ArticleOrder.id article) </ search> <available> available (Article, NULL) </ available> </ Article> <Required transaction = yes occurrence = 1 fk = transaction id pk = transaction id output = article name> <interactive> To which Transaction do you want to bind ArticleOrder? </ interactive> <type search = intelligent> evaluates (article ID, quantity) </ search> <available> available (Transaction, NULL) </ available> 852-EN-014146-patentapplication-final 21 </ Transaction> <Person mandatory = yes occurrence = 1 fk = id person pk = person_id output = article name> <interactive> At which Pe Do you want to bind ArticleOrder? </ interactive> <type search = intelligent> same (Person.name, Name) </ search> available <available> (Person, NULL) </ available> </ Person> <default> quantity = 0, order price = 0 </ default> </ ArticleOrder> This CFI configuration file can then be used to allow the MR module to handle the M commands and generate the corresponding SQL Rq queries. The grammar of the M command can take many forms, but is distinct from that of the SQL language. It may be similar to that described above. The example below gives another implementation of this grammar. In this example, the M command is of the form: Add {Person (name, 'Dupont', first name = 'Martin', login, 'DupontMartin', password, '0000') ItemCommand (quantity = '1') 1 This M command aims to add a person (that is, a client) to the database and, at the same time, an article order. This is a typical action for a commercial activity and the fact of allowing a simple addition of an order for a new customer in a single order confers a substantial advantage on the customer. mechanism of the invention. The M command has two objects: An object introduced by the "Person" type and with a list of associated fields; An object introduced by the type "ArticleControl" and with a single associated field, "quantity = 1".

As previously explained, these object fields correspond directly or indirectly to fields of the corresponding tables (directly or indirectly also) to the types. The first object is first analyzed by the MR module of the device D. This first object aims to add a new client in the database and the fields passed in parameters fill in all the mandatory fields of the "Person" table. The command processing module MR can therefore easily generate the query Rq in SQL language to add this client.

The second object is to add a new command. The MR module detects that some mandatory fields in the "ItemControl" table are not filled. Only the "quantity" field has been entered, whereas the table must include the identifier (or key) of a person (a customer), an article, and a transaction, as well as the price.

As mentioned above, a missing value of this field can be found in the other objects of the command M, and in particular in the previous object. Here, an identifier (or key) of person has been filled in by the previous object. The link is thus automatically performed by the device D between the customer that has been added and the article order: the order 852-EN-014146-patentapplication-final 23 article relates, implicitly, the customer who is added in the same command M. Its identifier is used to populate the Person Id field of the "ArticleControl" table. The "article id" field is not filled in any of the M command objects. The CFI configuration file indicates that this field is mandatory ("Required item = yes") and a smart mode is available. An indication that the search should be for the most current article: "<type search = smart> no longer present (ArticleOrder.id article) </ search>" Device D can then perform a search to determine the most sold from the database DB and fill in the field "article id" from the result of this search. Similarly, the field "id transaction" is not filled in any of the objects of the order M. The CFI configuration file indicates that this field is mandatory ("Mandatory transaction = yes") and a smart mode is available. A precise indication that the search uses an evaluation function: <type search = intelligent> evaluates (item ID, quantity) </ search> This evaluation function consists of multiplying the quantity by the value "Article.unit price" ", Of the article identified by the key" id article ". The device D then creates a new record in the "Transaction" table with field values, the price of the transaction thus evaluated, the current date and a new identifier. This new identifier is then used to fill in the "Transaction ID" field of the "ArticleControl" table. In the same way, the field "price order" is obligatory and it can be filled using the evaluation previously made for the field "price transaction". 852-EN-014146-patentapplication-final 24 Thus, a minimum of data and actions were necessary for the user U to enter complex data in the DB database. In addition, automating the evaluation of values or automatic re-use of previously determined values minimizes the risk of errors and inconsistencies. Of course, the present invention is not limited to the examples and to the embodiment described and shown, but it is capable of numerous variants accessible to those skilled in the art.

Claims (10)

REVENDICATIONS1. A method of querying a relational database (DB) comprising interpreting a command (M) for generating a set of queries (Rq) in SQL for management system (DBS) of said database, in wherein said command is in accordance with a distinct grammar of the SQL language and wherein said requests are generated according to the structure of said relational database. 2. Method according to claim 1, wherein said command is intended to add data within said relational database (DB) and comprises at least one object, said at least one object having a type and a list of associated fields. type audit, said type corresponding to a table of said database and each of said fields corresponding to a field of said table. The method of claim 2, wherein assigning a value to a field of a first object is automatically reused for a field of a second object, said first and second objects belonging to said at least one object. 4. Method according to one of claims 2 or 3, wherein a value is assigned to a field of said database (DB) according to indications provided by configuration files (CF), said indications specifying a mechanism to determine said value. 5. Computer program comprising instructions which, when loaded onto an information processing system, are able to implement the method according to one of claims 1 to 4.30852-EN-014146-patentapplication-final 26 6. Device (D) for querying a relational database (DB) consisting of interpreting a command (M) to generate a set of queries (Rq) in SQL for a management system (DBS) of said database, wherein said command conforms to a grammar distinct from the SQL language and interpreted using a set of configuration files (CF). 7. Device according to claim 6, having a command processing module (RM) for receiving said command (M) provided for adding data within said relational database (DB) and comprising at least one object, said at least one object having a type and a list of fields associated with said type, said type corresponding to a table of said database and each of said fields corresponding to a field of said table. 8. Device according to claim 7, having means for automatically reusing an assignment of a value to a field of a first object for a field of a second object, said first and second objects belonging to said at least one object. 9. Device according to one of claims 7 or 8, wherein a value is assigned to a field of said database (DB) according to indications provided by configuration files (CF) associated with said device (D) , said indications specifying a mechanism for determining said value. 10. Device according to the preceding claim, further comprising a generation module (MI) for processing a first configuration file (CFO) of said configuration files and generate a second852-EN-014146-patentapplication-final 27 configuration file (CFI) ) interpretable by said command processing module (MR) .5