FR 3007549 A1 20141226 FR 1355801 A 20130619 PROCEDE ET DISPOSITIF POUR L'INTERROGATION D'UNE BASE DE DONNEES RELATIONNELLES PERMETTANT LA DUPLICATION DE DONNEES DOMAINE DE L'INVENTION L'invention concerne les systèmes de gestion de base de données relationnelles et notamment à l'interrogation de tels systèmes par des utilisateurs. CONTEXTE DE L'INVENTION Les bases de données relationnelles sont des structures de données organisées sous la forme de tables au sein desquelles les données sont indexées au moyen de clés. Typiquement, une table comporte un ensemble d'enregistrements (ou « lignes ») indexés par une clé primaire. Les « colonnes » de la table représentent les champs. Un enregistrement comporte une valeur pour chacun des champs de la table. Les tables peuvent se référencer entre elles afin de structurer l'information, en comportant un champ ayant pour valeur une clé (dite alors « clé étrangère ») correspondant à un enregistrement d'une autre table. Il est bien connu d'associer une base de données relationnelle à un système de gestion afin d'assurer une interface destinée aux utilisateurs la base de données qui soit indépendante de la structure physique de la base de données. La figure 1 illustre une architecture haut-niveau typique de mise en oeuvre d'une base de données relationnelle. Un utilisateur U peut accéder à la base de données DB au travers d'un système de gestion de base de données DBS. La base de données DB et le système de gestion DBS peuvent appartenir à un même serveur fonctionnel S. D'un point de vue fonctionnel, ce système de gestion de bases de données DBS peut se décomposer schématiquement en une interface d'accès aux données AI et une interface de traitement des requêtes RI. L'interface d'accès aux données AI vise à gérer les spécificités physiques d'implémentation de la base de données DB, par exemple à gérer les aspects de redondances, la répartition sur des machines serveurs distantes et éventuellement multiples, à gérer les différents protocoles d'accès possibles, à gérer les éventuels accès concurrents, etc. L'interface de traitement des requêtes RI permet d'assurer une interface unifiée à l'utilisateur U, quel que soit la base de données DB sous-j acente. Cette interface permet classiquement d'interroger la base par des requêtes Rq et de recevoir des réponses Rp. L'interrogation est généralement conforme à un langage d'interrogation structuré tel que le langage SQL (pour « Structure Query Language » en langue anglaise) qui est normalisé à la fois par l'ISO (International Standard Organization) et par l' ANSI (American National Standards Institute). Ce langage SQL permet, au moyen d'un ensemble de commandes (appelées « requêtes »), de manipuler les données au sein de la base de données DB. Ces commandes permettent d'effectuer notamment des recherches, d'ajouter des données, de mettre à jour (ou modifier) des données présentes, d'effacer des données, de créer ou de supprimer des tables, etc. Ce langage permet d'offrir une interface universelle, de sorte que sa connaissance permet à un utilisateur d'interagir avec toutes les bases de données. Toutefois, son utilisation reste difficile car elle nécessite une bonne connaissance de la topologie de la base de données sous-jacente DB, c'est- à-dire du nom des tables et des liens qui existent entre les tables. Certaines base de données DB peuvent être très complexes et comporter un très grand nombre de tables, et cette connaissance peut être difficile à acquérir et demande un investissement préalable pour l'utilisateur U. En outre, même bon connaisseur de la structure topologique de la base de données DB, si celle-ci est au moins un peu complexe, l'interrogation de la base de données DB peut nécessiter plusieurs requêtes en SQL. Le processus est donc fastidieux, long et donc coûteux dans le cadre d'une utilisation industrielle ou professionnelle. En outre, il peut en résulter un risque d'erreurs non-négligeable, notamment un risque d'oublier de renseigner un champ dans une requête. Par ailleurs, certaines opérations courantes et qui peuvent paraître simples de prime abord s'avèrent difficile à réaliser à partir d'une interface en langage SQL. C'est par exemple le cas de la copie d'un enregistrement. En effet, l'utilisateur U peut être amené à dupliquer des enregistrements d'une table en ne changeant que quelques champs. Un tel cas peut survenir dans le cadre d'une base de données gérant un parc de dispositifs de télécommunication : chaque dispositif peut comporter un grand nombre de champs communs (marque, numéro de modèle, quelques données de configurations...) ainsi que des champs différents. Il n'existe aucun mécanisme dans le langage SQL pour faciliter cette opération qui est donc entièrement manuelle et, par conséquent, coûteuse, fastidieuse et source d'erreurs. RE SUME DE L'INVENTION Le but de la présente invention est de fournir une solution palliant au moins partiellement les inconvénients précités, en permettant une duplication et une duplication partielle facilitées d'un enregistrement d'une table. À cette fin, la présente invention propose un procédé d'interrogation d'une base de données relationnelle consistant à interpréter une commande pour générer un ensemble de requêtes en langage SQL destinées à un système de gestion de ladite base de données, ladite commande comportant des paramètres et ledit procédé consistant à Déterminer une table au sein de ladite base de données et un enregistrement à dupliquer au sein de ladite table, à partir desdits paramètres; Déterminer au moins un nouvel enregistrement sur la base des données dudit au moins un enregistrement à dupliquer ; Insérer ledit au moins nouvel enregistrement dans ladite base de données. Suivant des modes de réalisation préférés, l'invention comprend une ou plusieurs des caractéristiques suivantes qui peuvent être utilisées séparément ou en combinaison partielle entre elles ou en combinaison totale entre elles : Lesdits paramètres peuvent indiquer des champs de ladite table associés à des valeurs, et dans lequel ledit nouvel enregistrement est déterminé en attribuant lesdites valeurs auxdits champs. Le procédé peut comprendre en outre : la détermination d'un ensemble de tables liées à ladite table, la détermination au sein dudit ensemble de tables liées, d'un ensemble d'enregistrements liés à dupliquer associés audit enregistrement à dupliquer ; la détermination de nouveaux enregistrements liés sur la base desdits enregistrements liés à dupliquer ; et l'insertion desdits nouveaux enregistrements liés dans lesdites tables liées. La détermination d'un ensemble de tables liées à ladite table peut être basée sur des indicateurs identifiant des tables à ne pas traiter. Les indicateurs peuvent être stockés dans un fichier de configuration. Un autre aspect de l'invention concerne un programme d'ordinateur comprenant des instructions qui, une fois chargées sur un système de traitement de l'information, sont aptes à mettre en oeuvre le procédé précédemment décrit. Un autre aspect de l'invention concerne un dispositif pour l'interrogation d'une base de données relationnelle consistant interpréter une commande pour générer un ensemble de requêtes en langage SQL destinées à un système de gestion de ladite base de données, ladite commande comportant des paramètres et ledit dispositif étant prévu pour : Déterminer une table au sein de ladite base de données et un enregistrement à dupliquer au sein de ladite table, a partir desdits paramètres; Déterminer au moins un nouvel enregistrement sur la base des données dudit au moins un enregistrement à dupliquer Insérer ledit au moins nouvel enregistrement dans ladite base de données. Suivant des modes de réalisation préférés, l'invention comprend une ou plusieurs des caractéristiques suivantes qui peuvent être utilisées séparément ou en combinaison partielle entre elles ou en combinaison totale entre elles : Le dispositif peut être prévu pour déterminer ledit nouvel enregistrement en attribuant des valeurs à des champs, lesdites valeurs et lesdits champs étant indiqués par lesdits paramètres Le dispositif peut être adapté pour en outre déterminer un ensemble de tables liées à ladite table, déterminer au sein dudit ensemble de tables liées, d'un ensemble d'enregistrements liés à dupliquer associés audit enregistrement à dupliquer ; déterminer de nouveaux enregistrements liés sur la base desdits enregistrements liés à dupliquer ; et insérer lesdits nouveaux enregistrements liés dans lesdites tables liées. La détermination d'un ensemble de tables liées à ladite table peut être basée sur des indicateurs identifiant des tables à ne pas traiter. D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description qui suit d'un mode de réalisation préféré de l'invention, donnée à titre d'exemple et en référence aux dessins annexés. BREVE DESCRIPTION DES DESSINS La figure 1 représente schématiquement une architecture fonctionnelle d'un système composé d'une base de données et d'un système de gestion, conformément à l'état de la technique. La figure 2 représente schématiquement une architecture fonctionnelle d'un système composé d'une base de données et d'un système de gestion de la base de données, conformément à l'invention. La figure 3 illustre un exemple de structure de base de données relationnelle. DESCRIPTION DETAILLEE DE L'INVENTION La figure 2 représente une mise en oeuvre possible de l'invention dans lequel un dispositif D a été inséré entre le système de gestion DBS d'une ou plusieurs bases de données DB et le ou les utilisateurs U. À travers ce dispositif D, l'utilisateur U peut accéder à la base de données DB via le système de gestion de bases de données DBS. La base de données DB et le système de gestion DBS peuvent appartenir à un même serveur fonctionnel S. Ce serveur fonctionnel S peut bien évidemment être mis en oeuvre de différentes façons. Il peut par exemple s'agir d'un seul serveur physique (c'est-à-dire d'un ordinateur), ou bien de plusieurs ordinateurs : notamment le système de gestion DBS peut être déployé sur une machine différente de celle sur laquelle est déployée la base de données DB. Il peut également être prévu de déployer la base de données (et le système de gestion DBS) sur une pluralité de machines reliées en réseau. Cette pluralité de machines connectées peut même former une ferme d'ordinateurs. D'autres mises en oeuvre sont bien évidemment possibles. D'un point de vue fonctionnel également, ce système de gestion de bases de données DBS peut se décomposer schématiquement en une interface d'accès aux données AI et une interface de traitement des requêtes RI. L'interface d'accès aux données AI vise à gérer les spécificités physiques d'implémentation de la base de données DB, par exemple à gérer les aspects de redondances, la répartition sur des machines serveurs distantes et éventuellement multiples, à gérer les différents protocoles d'accès possibles, à gérer les éventuels accès concurrents, etc. L'interface de traitement des requêtes RI permet d'assurer une interface unifiée à l'utilisateur U, quel que soit la base de données DB sous- jacente. Cette interface permet classiquement d'interroger la base par des requêtes Rq et de recevoir des réponses Rp. L'interrogation est généralement conforme à un langage d'interrogation structuré tel que le langage SQL (pour « Structure Query Language » en langue anglaise) qui est normalisé à la fois par l'ISO (International Standard Organization) et par l'ANSI (American National Standards Institute). En pratique, les interfaces d'accès aux données AI et de traitement des requêtes RI peuvent être mises en oeuvre par des modules logiciels distincts du système de gestion DBS ou bien être intégrées au sein d'un même module logiciel. L'architecture du serveur fonctionnel S comprenant la base de données DB et le système de gestion DBS peut être conforme aux différentes solutions proposées par l'état de la technique et donc différentes mises en oeuvre sont accessibles à l'homme du métier. Un aspect de l'invention concerne ce dispositif D pour l'interrogation d'une base de données relationnelle DB. Il peut être réalisé de différentes façons et notamment il peut être déployé sur une même machine que le système de gestion DBS ou bien sur une machine distincte. Ce dispositif permet de présenter aux utilisateurs U une interface différente du langage SQL et peut ainsi agir comme un interpréteur de plus haut niveau : l'utilisateur peut transmettre des commandes M conforme à une grammaire donnée, distincte du langage SQL, le dispositif D dispose des moyens logiciels pour interpréter ces commandes et générer un ensemble de requêtes SQL destinées au système de gestion DBS. Cette interprétation peut notamment se faire à l'aide d'un ensemble de fichiers de configuration CF. Ce fichier de configuration peut être unique. La commande M peut par exemple être interprétée d'abord par une application logicielle de type « Shell » sur un système d'exploitation de la famille Unix. En ce cas, elle peut comporter un mot-clé permettant à cette application « shell » d'identifier le dispositif D et de lui transmettre la commande M reçue. En outre, le dispositif D peut mettre en oeuvre différents mécanismes y compris des mécanismes distincts de ceux de l'invention. Aussi, la commande M peut comporter un mot-clé permettant d'identifier ces mécanismes. Dans les exemples donnés ci-dessous le mot-clé est « copie ». Une telle commande peut par exemple avoir pour forme : Commande copie --filtre Le mot-clé « commande » permet d'indiquer qu'il s'agit d'une commande adressée au dispositif D. Le mot clé « copie » indique qu'il s'agit d'une commande de duplication (complète ou partielle) de données dans la base de données relationnelle DB. Il permet de mettre en oeuvre les mécanismes de l'invention. La commande M comprend ensuite au moins un filtre. Il peut y avoir plusieurs filtres. Le ou les filtres permettent de déterminer un enregistrement au sein de la base de données DB. Ce filtre peut être introduit au moyen de caractères d'échappement comme dans cet exemple les deux tirets « ». Ces caractères d'échappement permettent de distinguer au sein des paramètres les filtres des arguments. Le ou les filtres sont obligatoires afin de pouvoir déterminer un unique enregistrement. Cet enregistrement représente l'enregistrement à dupliquer. Les arguments représentent des différences qui peuvent être introduite dans la duplication qui est alors partielle. En effet, il est possible de souhaiter un enregistrement mais de faire varier la valeur d'un ou plusieurs champs. En passant un identifiant de ce ou de ces champs ainsi que la ou les valeurs associés, l'utilisateur peut effectuer cette duplication partielle en une unique commande M. Le dispositif D attribue alors au champ concerné du nouvel enregistrement la valeur indiquée pour ce champ (indépendamment donc de la valeur de ce champs dans l'enregistrement à dupliquer). Cette possibilité ainsi que la mention de ces arguments dans la commande M sont toutefois optionnels. Selon un mode de réalisation de l'invention, la table peut être déterminée de façon implicite ou par d'autres moyens comme par exemple le nom de la commande : le nom de la commande peut en effet viser une action, un mode d'utilisation de la base de données DB et donc, implicitement ou explicitement, la table concernée. Selon un autre mode de réalisation, la table est indiquée de façon explicite parmi les paramètres de la commande M. La commande peut alors avoir pour forme : Commande copie --filtre L'exemple représenté sur la figure 3 comprend 3 tables : Ti (« equipment »), T2 (« port »), T3 (« equipment status ») e t T 4 (« container »). D'autres tables peuvent exister dans la base de données DB mais nous nous intéresserons qu'a ces 4 tables dans les explications de cet exemple. La table Ti comporte 5 champs (ou colonnes) : - Id : l'identifiant ou clé primaire de la table. - Name : une chaine de caractères indiquant un nom pour l'équipement. - Type : un chaîne de caractères indiquant le type d'équipement (par exemple, un commutateur, « switch », un routeur, etc.) - Container id : un identifiant ou clé étrangère pointant sur un enregistrement de la table T4 et indiquant un système contenant l'équipement en question. - Description : une chaine de caractères décrivant plus librement l'équipement. La table T2 comporte 2 champs : - Hwaddr : l'adresse MAC (Media Access Control) associé au port. Une adresse MAC étant unique, elle peut servir d'identifiant ou clé primaire pour la table. - Equipment id : un identifiant ou clé étrangère pointant vers l'équipement auquel ce port appartient. La table T3 comporte 4 champs : - Name : identifie un statut qui peut être associé à un équipement. - Value : donne la valeur associée au statut définit par « name ». - Equipment id : un identifiant ou clé étrangère pointant vers l'équipement concerné par ce statut. - Description : une chaine de caractères décrivant plus librement le statut. La table T4 comporte 3 champs - Id : l'identifiant ou clé primaire de la table - Name : une chaine de caractères indiquant un nom pour le système contenant. - Description : une chaine de caractères décrivant plus librement le système contenant (« container »). L'utilisateur U souhaite ajouter un nouvel équipement de type « Switch » dans la base de données. Il souhaite nommer cet équipement « switch2 » et il sait qu'il est similaire à un équipement déjà installé et nommé « switchl ». Il peut alors rédiger une commande M et la transmettre au dispositif D. Cette commande M peut être de la forme : Commande copie equipment `name=switch2, description=switch2' -filtre `name=switchl AND type=switch' Comme nous l'avions expliqué plus haut, les paramètres de la commande comportent à la fois le nom de la table concerné, un filtre et des arguments. À la réception de cette commande M, le dispositif D doit - déterminer un enregistrement à dupliquer au sein de la table Ti partir des paramètres et plus précisément du filtre `name=switchl AND type=switch', puis - déterminer un nouvel enregistrement sur la base des données de cet enregistrement à dupliquer et, car il y en a ici, des arguments `name=switch2, description=switch2'. Pour ce faire, le dispositif peut d'abord déterminer la structure de la table Ti, c'est-à-dire les champs et colonnes de la table Ti. Cette étape peut être nécessaire afin de pouvoir rédiger les requêtes en SQL subséquentes qui vont renseigner ainsi tous les champs nécessaires de la table Ti. La détermination de la structure d'une table peut se faire de différentes façons en fonction du type de base de données. Dans le cadre d'une base de données DB de type « postgresql », elle peut se faire par une requête de la syntaxe suivante : select column name from information schema.columns where table name='equipment'; Cette requête retourne la liste des champs (ou colonnes) de la table, soit : « id, name, type, container id, description ». La connaissance du nom des champs permet au dispositif D de déterminer le nouvel enregistrement et de construire une requête valable et permettant de l'insérer dans la base de données. La détermination de l'enregistrement à dupliquer, du nouvel enregistrement et l'insertion dans la base de données peuvent se faire par l'élaboration et la transmission d'une requête vers la base de données DB. Dans l'exemple, une telle requête peut être de la forme suivante : INSERT INTO equipment (name,type,container id,description) SELECT 'switch2',type,container id,'switch 2' FROM equipment WHERE name = 'switchl' AND type = 'switch' ; Dans cette requête, la partie « FROM equipment WHERE name = 'switchl' AND type = 'switch' ; » permet d' extraire de la table Ti (« equipment ») l'enregistrement à dupliquer déterminé par le filtre passé dans la commande M. On suppose ici, bien sûr, que l'enregistrement correspondant avait été au préalable inséré dans la table Tl. La partie «INSERT INTO equipment (name, type, container id, description) » permet d'identifier les champs de la table Ti et d'indiquer que des valeurs vont être associées à ces champs-là (dans cet ordre-là). Le nom des champs provient de la détermination qui a été fait au préalable de la structure de la table Tl. Cette commande « INSERT » permet de créer un nouvel enregistrement. Enfin, la partie « SELECT 'switch2',type,container id,'switch 2'» indique les valeurs renseignées pour le nouvel enregistrement. Elle comprend des données provenant de l'enregistrement à dupliquer (type, container id) ainsi que des valeurs indiquées comme argument de la commande (« switch2 », « switch 2 »). Ces valeurs passées en argument ont priorité sur les valeurs récupérées de l'élément à dupliquer puisqu'elles indiquent les différences que l'utilisateur U veut imposer dans le cadre d'une duplication partielle. La table Ti contient alors un enregistrement (ou ligne) suivant : Id Name Type Container id Description 35 Switch2 Switch 1 Switch2 Bien sûr, d'autres requêtes auraient pu être écrite pour parvenir au même résultat, et il est également possible de décomposer le processus en plusieurs requêtes indépendantes. L'invention ne se limite évidemment pas à une implémentation particulière. Selon un mode de réalisation de l'invention, le dispositif D traite également les tables qui pointent sur la table Ti afin de dupliquer, totalement partiellement, des enregistrements de ces tables liées. Plus précisément, le dispositif D met en oeuvre des étapes visant à déterminer cet ensemble de tables liées à la table Ti, déterminer au sein de cet ensemble un ensemble d'enregistrements liés à dupliquer associés à l'enregistrement à dupliquer de la table Ti ; déterminer de nouveaux enregistrements liés sur la base des enregistrements liés à dupliquer ; et insérer ces nouveaux enregistrements liés dans les tables liées en question. Il peut en outre être prévu de ne pas traiter l'ensemble des tables liées. Pour ce faire des indicateurs peuvent identifier des tables à ne pas traiter. La détermination de l'ensemble de tables liées peut alors se faire sur la base de ces indicateurs. Les indicateurs peuvent être stockés dans un fichier de configuration associée à la commande. Il est en outre possible d'indiquer dans la commande elle-même d'autres indicateurs pour contourner ces premiers indicateurs. Ainsi, une règle générale peut être stockée dans le fichier de configuration afin de ne pas traiter une certaine table. Mais ponctuellement, l'utilisateur peut rédiger une commande pour passer outre cette règle générale et demander explicitement à ce que cette table soit traitée. Une telle indication peut être introduite dans la syntaxe de la commande par un mot-clé dédié (par exemple -autoriser ). Ce mécanisme d'indicateurs établissant une règle générale de ne pas traiter certaines tables répond à un problème supplémentaire d'éviter des duplications de données inutiles en cascade dans la base de données. Par exemple, si l'utilisateur souhaite dupliquer les données d'un équipement possédant 28 ports pour créer un nouvel équipement, il peut être inutile de dupliquer les 28 ports si l'on sait que seuls quelques-uns seront utilisés. Une duplication « aveugle » créerait trop d'informations dans la base de données et à terme pourrait l'engorger et la rendre moins efficace. Une autre mise en oeuvre consiste à permettre la duplication d'un (ou plusieurs) enregistrement d'une table liée mais de contrôler ou imposer sa valeur. Dans ce cas également, il est possible d'indiquer cette règle dans le fichier de configuration. Elle peut prendre la syntaxe suivante : Copie. . .regle= [ ...] On peut donc ainsi imposer une valeur au champ de la table lié . Dans l'exemple d'un équipement possédant 28 ports, on peut ainsi choisir de vouloir dupliquer les enregistrements liés dans la table T2, « port », mais imposer que le champ « Hwaddr » (l'adresse MAC du port) soit mise à zéro (sa duplication serait source d'erreur puisqu'il s'agirait de données fausses). Le fichier de configuration peut alors comporter une ligne : Copie. equipment. port. regle=hwaddr=NULL Les adresses MAC pourront être fournies par l'utilisateur ultérieurement et par d'autres moyens. Pour rechercher et déterminer les tables qui pointent vers la table Ti, différentes méthodes sont possibles, notamment en fonction de la technologie utilisée par la base de données DB. Dans le cadre d'une base de données de type « postgresql », une telle requête peut s'écrire : SELECT tc.table name as fk table,kcu.column name as fk column,ccu.table name as pk table,ccu.column name as pk column FROM information schema.table constraints tc LEFT JOIN information schema.key column usage kcu ON tc.constraint catalog = kcu.constraint catalog AND tc.constraint schema = kcu.constraint schema AND tc.constraint name = kcu.constraint name LEFT JOIN information schema.referential constraints rc ON tc.constraint catalog = rc.constraint catalog AND tc.constraint schema = rc.constraint schema AND tc.constraint name = rc.constraint name LEFT JOIN information schema.constraint column usage ccu ON rc.unique constraint catalog = ccu.constraint catalog AND rc.unique constraint schema = ccu.constraint schema AND rc.unique constraint name = ccu.constraint name WHERE ccu.table name = 'equipment' AND tc.table name <> 'equipment', Le résultat de cette requête, reçue par le dispositif D, peut être, dans l'exemple illustré par la figure 3 : Fk table Fk column Pk table Pk column Port Equipment id Equipment Id Equipment status Equipment id Equipment id Cette table contient autant de lignes (ici 2) que de tables pointant sur la table Ti (« equipment »). La première colonne indique le nom de la table ; la seconde colonne indique le champ pointant sur Ti ; la troisième colonne le nom de la table pointé (ici, donc, « equipment » correspondant bien à la table Ti), et la quatrième colonne correspond au champ pointé par le champ de la deuxième colonne. On suppose que le fichier de configuration contient une indication pour exclure le traitement de la table « port ». Le fichier de configuration peut par exemple contenir une ligne : Copie.equipment.exception=port Cette ligne indique que pour la fonctionnalité de duplication (« copie ») portant sur la table « equipment », il existe une règle général dérogeant au traitement normal selon laquelle la table « port » ne doit pas être traitée. Par conséquent, uniquement la table « equipment status » doit ici être traitée. Comme précédemment pour la table Ti, « equipment », les étapes de détermination d'un enregistrement à dupliquer, de détermination d'un (ou plusieurs) nouvel enregistrement et d'insertion de ce (ou ces) nouvel enregistrement peuvent être effectuées de différentes façons. Une de ces façons consiste en une première requête SQL qui permet de déterminer les données d'un enregistrement à dupliquer : SELECT * FROM equipement status es LEFT OUTER JOIN equipment e ON e.id = es.equipment id WHERE e.name = 'switchl' AND e.type = 'switch'; Cette première requête retourne comme résultat l'enregistrement suivant (dans le cas de notre exemple) : Name Value Equipment id Description état ON 10 Équipement sous tension On/Off Une fois l'enregistrement à dupliquer déterminé, le dispositif D peut mettre en oeuvre les étapes suivantes de déterminer au moins un nouvel enregistrement dans cette table « equipment status » puis à l'insérer dans la base de données DB. Dans l'exemple de requête suivant, ces deux actions sont réalisées en même temps : INSERT INTO equipement status (name,value,equipement id,description) VALUES ('etat','ON',35,' équipement sous tension ON/OFF') ; Le nouvel enregistrement se base sur les données de l'enregistrement à dupliquer : 'état', 'ON', 'équipement sous tension ON/OFF'. La valeur de « equipment id » est évidemment différente et correspond à la clé primaire de l'équipement inséré « switch2 » sur lequel doit pointer ce nouveau enregistrement de la table « equipment status ». De la même manière, s'il y avait d'autres tables liées à l'équipement dupliqué, elles seraient traitées de même et des enregistrements de ces tables seraient égarements dupliquées. Ainsi, un minimum de données et d'actions ont été nécessaires pour l'utilisateur U pour entrer des données complexes dans la base de données DB. En outre, l'automatisation de l'évaluation de valeurs ou la réutilisation automatique de valeurs précédemment déterminées permet de minimiser les risques d'erreurs et d'incohérences. Bien entendu, la présente invention n'est pas limitée aux exemples et au mode de réalisation décrits et représentés, mais elle est susceptible de nombreuses variantes accessibles à l'homme de l'art. REVENDICATIONS1. Procédé d'interrogation d'une base de données relationnelle (DB) consistant à interpréter une commande (M) pour générer un ensemble de requêtes (Rq) en langage SQL destinées à un système de gestion (DBS) de ladite base de données, ladite commande comportant des paramètres et ledit procédé consistant à Déterminer une table au sein de ladite base de données et un enregistrement à dupliquer au sein de ladite table, à partir desdits paramètres; Déterminer au moins un nouvel enregistrement sur la base des données dudit au moins un enregistrement à dupliquer Insérer ledit au moins nouvel enregistrement dans ladite base de données. 2. Procédé selon la revendication précédente, dans lequel lesdits paramètres indiquent des champs de ladite table associés à des valeurs, et dans lequel ledit nouvel enregistrement est déterminé en attribuant lesdites valeurs auxdits champs. 3. Procédé selon l'une des revendications précédentes, comprenant en outre : la détermination d'un ensemble de tables liées à ladite table, la détermination au sein dudit ensemble de tables liées, d'un ensemble d'enregistrements liés à dupliquer associés audit enregistrement à dupliquer ; la détermination de nouveaux enregistrements liés sur la base desdits enregistrements liés à dupliquer ; et l'insertion desdits nouveaux enregistrements liés dans lesdites tables liées. 4. Procédé selon la revendication précédente dans lequel la détermination d'un ensemble de tables liées à ladite table est basée sur des indicateurs identifiant des tables à ne pas traiter. 5. Procédé selon la revendication précédente dans lequel lesdits indicateurs sont stockés dans un fichier de configuration. 6. Programme d'ordinateur comprenant des instructions qui, une fois chargées sur un système de traitement de l'information, sont aptes à mettre en oeuvre le procédé selon l'une des revendications 1 à 5. 7. Dispositif (D) pour l'interrogation d'une base de données relationnelle (DB) consistant à interpréter une commande (M) pour générer un ensemble de requêtes (Rq) en langage SQL destinées à un système de gestion (DBS) de ladite base de données, ladite commande comportant des paramètres et ledit dispositif étant prévu pour : Déterminer une table au sein de ladite base de données et un enregistrement à dupliquer au sein de ladite table, à partir desdits paramètres; Déterminer au moins un nouvel enregistrement sur la base des données dudit au moins un enregistrement à dupliquer Insérer ledit au moins nouvel enregistrement dans ladite base de données. 8. Dispositif (D) selon la revendication précédente, prévu pour déterminer ledit nouvel enregistrement en attribuant des valeurs à des champs, lesdites valeurs et lesdits champs étant indiqués par lesdits paramètres 9. Dispositif selon l'une des revendications 7 ou8, adapté pour en outredéterminer un ensemble de tables liées à ladite table, déterminer au sein dudit ensemble de tables liées, d'un ensemble d'enregistrements liés à dupliquer associés audit enregistrement à dupliquer ; déterminer de nouveaux enregistrements liés sur la base desdits enregistrements liés à dupliquer ; et insérer lesdits nouveaux enregistrements liés dans lesdites tables liées. 10. Dispositif selon la revendication précédente dans lequel la détermination d'un ensemble de tables liées à ladite table est basée sur des indicateurs identifiant des tables à ne pas traiter.