FR 3004268 A1 20141010 FR 1353117 A 20130408 PROCÉDÉ ET DISPOSITIF D'INTERROGATION D'UNE BASE DE DONNÉES PERMETTANT L'ANNULATION D'UNE REQUÊTE ANTÉRIEURE 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 au moyen de requêtes. 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é 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 de 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 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. SASCH\Bull-04139-final.doc D'un point de vue fonctionnel, ce système de gestion de bases de données DB peut se décomposer en une interface d'accès aux données AI et en une interface de traitement des requêtes RI. L'interface d'accès aux données AI vise à gérer les spécificités d'implémentation de la base de données physiques, 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 permet d'assurer une interface unifiée à l'utilisateur U. 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 « Structured 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, 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. Certaines requêtes permettent donc de modifier le contenu de la base de données DB. C'est le cas, par exemples, des commandes d'insertion d'un enregistrement (commande « Insert »), de mise à jour d'un enregistrement (commande « Update ») et des commandes de suppression (commande « Delete »). Toutefois, l'utilisateur U peut être une application logicielle ou bien un humain et dans les deux cas des erreurs peuvent être commises. Dans le cas où l'utilisateur U est un humain, il est tout à fait possible que celui-ci commette une erreur notamment sur les paramètres de la commande. La syntaxe des commandes en langage SQL est en effet assez lourde et nécessite de bien connaître également l'architecture de la base de données SASCH\Bull-04139-final.doc DB, de sorte qu'une erreur peut être assez facilement commise sur le nom d'une table, le nom d'un champ, etc. Il est donc possible d'insérer une information erronée dans la base de données DB, mais aussi de modifier ou de supprimer une information et donc de la perdre sans possibilité de la retrouver. Une telle situation est encore plus dommageable dans le cas d'un effet de bord appelé « delete cascade », c'est-à-dire une cascade de suppressions effectuées par la base de données. Cet effet de suppression en cascade est illustré par la figure 2 qui représente un exemple simple d'architecture d'une base de données DB, constitué de 4 tables, Ti, T2, T3, T4. Selon cette architecture un hôtel possède une clé « HotelNo » et un nom « Name ». Une réservation est en enregistrement de la table T2 contenant une clé « ResNo », un nom de client, un hôtel (qui est donc une clé pointant vers la table Ti), une chambre (qui est donc une clé pointant vers la table T3) et des dates d'entrée « DateIn » et de sortie « DateOut »). La table T3 contient des chambres « Rooms ». Chaque chambre comprend une clé « RoomNo », un type de chambre « RoomType » (qui est une clé pointant vers la table T4), un hôtel (qui est une clé pointant vers la table T1) et un prix. Enfin, la table T4 contient les types de chambre « RoomTypes ». Chaque type comprend une clé « RoomType », des informations sur les lits, « Beds » et un type « Type ». Si l'utilisateur supprime un enregistrement dans la table Ti, c'est-à-dire un hôtel, automatiquement les enregistrements liés dans les tables T2 et T3 seront supprimées. Il apparaît ainsi clairement qu'une erreur ponctuelle peut avoir d'importantes conséquences pour l'intégrité de la base de données DB. Afin de minimiser les risques d'erreurs, il est possible d'utiliser le mécanisme des transactions : lorsqu'une transaction est ouverte, les requêtes encapsulées dans cette transaction ne sont effectivement effectuées qu'à la terminaison de la transaction (« commit »). Tant que la transaction n'est pas SASCH\Bull-04139-final.doc terminée, il est toujours possible de revenir en arrière via le mécanisme dit du « roll-back ». Toutefois un tel mécanisme, quoiqu'utile, est bien insuffisant car l'utilisation systématique des transactions alourdit considérablement l'utilisation des systèmes de base de données, et, surtout, car l'utilisateur U peut réaliser avoir commis une erreur bien plus tard, notamment lors d'une utilisation ultérieure de la base de données. Le mécanisme de transaction est donc totalement insuffisant pour fournir un garde-fou efficace. RÉSUMÉ DE L'INVENTION Le but de la présente invention est de fournir une solution palliant au moins partiellement les inconvénients précités. À cette fin, la présente invention propose un procédé d'interrogation d'un système de gestion associé à une base de données, comportant une étape d'interception des requêtes destinés audit système de gestion et de détermination si une requête entrante est une requête en modification, destinée à modifier des donnés dans ladite base de données, une étape de mémorisation de ladite requête en modification dans un registre, et une étape de transmission de ladite requête entrante vers ledit système de gestion, 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 procédé peut comporter en outre, si ladite requête en modification est destinée à supprimer des données de ladite base de données, une étape d'interrogation de ladite base de données pour récupérer des informations comprenant au moins lesdites données et les mémoriser dans ledit registre en association avec ladite requête entrante. SASCH\Bull-04139-final.doc Les informations peuvent comprendre les numéros d'enregistrement correspondants auxdites données. L'étape d'interrogation peut comprendre la transmission d'un ensemble de requêtes afin de récupérer des informations comprenant au moins des données pouvant être supprimés par une cascade de suppressions. Le procédé peut comporter en outre une étape de réception d'une requête en restauration, identifiant au moins un élément au sein dudit registre, et une étape de restauration consistant à transmettre audit système de gestion au moins une requête pour rétablir au sein de ladite base de données les informations correspondant audit au moins un élément. La requête en modification peut correspondre en langage SQL à une commande appartenant à un groupe comprenant au moins une commande d'insertion INSERT, une commande de mise-à-jour UPDATE et une commande de suppression DELETE. 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'un système de gestion (DBS) associé à une base de données (DB), comprenant des moyens (P) pour intercepter des requêtes destinés audit système de gestion et pour déterminer si une requête entrante est une requête en modification, destinée à modifier des donnés dans ladite base de données (DB), et pour transmettre ladite requête entrante vers ledit système de gestion, et un registre pour mémoriser ladite requête en modification. Suivant des modes de réalisation préférés, le dispositif selon 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 : SASCH\Bull-04139-final.doc Les moyens peuvent être adaptés pour, si ladite requête en modification est destinée à supprimer des données de ladite base de données, à interroger ladite base de données pour récupérer des informations comprenant au moins lesdites données et les mémoriser dans ledit registre en association avec ladite requête. Les informations peuvent comprendre les numéros d'enregistrement correspondants auxdites données. Les moyens peuvent être prévus pour la transmission d'un ensemble de requêtes afin de récupérer des informations comprenant au moins des données pouvant être supprimés par une cascade de suppressions. Les moyens peuvent être prévus pour recevoir une requête en restauration, identifiant au moins un élément au sein dudit registre, et pour transmettre audit système de gestion au moins une requête pour rétablir au sein de ladite base de données les informations correspondant audit au moins un élément. La requête en modification peut correspondre en langage SQL à une commande appartenant à un groupe comprenant au moins une commande d'insertion INSERT, une commande de mise-à-jour UPDATE et une commande de suppression DELETE. Ainsi, l'invention permet de résoudre un premier problème de connaître les données qui ont été effacées de la base de données. Elle permet également d'annuler une requête antérieure. 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. SASCH\Bull-04139-final.doc 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 un exemple de structure d'une base de données relationnelle. La figure 3 représente une architecture fonctionnelle d'un système composé d'une base de données et d'un système de gestion, conformément à une mise en oeuvre de l'invention. La figure 4 représente une architecture fonctionnelle d'un système composé d'une base de données et d'un système de gestion, conformément à une mise en oeuvre de l'invention. La figure 5 représente un organigramme illustratif d'une mise en oeuvre du procédé selon l'invention. DESCRIPTION DETAILLEE DE L'INVENTION Les figures 3 et 4 représentent 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 base de données DB et le ou les utilisateurs U. À travers le dispositif D, l'utilisateur U peut accéder à la base de données DB au travers d'un 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 mise 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) sur une pluralité de machines reliées en réseau. SASCH\Bull-04139-final.doc Cette pluralité de machines connectées peut même former une ferme d'ordinateurs. D'autres mises en oeuvre sont encore possibles. D'un point de vue fonctionnel également, le système de gestion de bases de données DB peut se décomposer en une interface d'accès aux données AI et en une interface de traitement des requêtes RI. L'interface d'accès aux données AI vise à gérer les spécificités d'implémentation de la base de données physiques, 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. 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 « Structured Query Language » en langue anglaise). 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és au sein d'un même module logiciel. L'architecture du serveur 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 le dispositif D pour l'interrogation du système de gestion DBS associé à la base de données DB. Ce dispositif D 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 peut permettre de présenter aux utilisateurs une interface différente du langage SQL et agir comme interpréteur de plus haut niveau : SASCH\Bull-04139-final.doc l'utilisateur peut transmettre des requêtes M1 selon un protocole donné et le dispositif D peut disposer des moyens pour les convertir en requêtes conformes au langage SQL, par exemple, pour transmission à l'interface de traitement des requêtes RI. Cet aspect étant en dehors du cadre de l'invention, il ne sera pas décrit davantage. Selon l'invention, le dispositif D comprend des moyens P permettant : d'intercepter des requêtes M1 destinés au système de gestion DBS ; déterminer si une requête entrante, parmi celles-ci, est une requête en modification, et - transmettre la requête entrante M4 vers le système de gestion DBS. Le dispositif D comprend en outre un registre RM pour mémoriser la requête entrante s'il a été déterminé que celle-ci est une requête en modification. Si la requête en modification est destinée à supprimer des données de ladite base de données DB, les moyens P peuvent interroger la base de données DB en lui transmettant des requêtes M2 pour récupérer des informations M3 comprenant au moins les données qui vont être supprimées et les mémoriser, via une requête interne M5, dans le registre RM en association avec la requête entrante qui y a été mémorisée. Les moyens P peuvent en oeuvre être prévus pour recevoir une requête en restauration M6, identifiant au moins un élément au sein du registre RM, et pour transmettre au système de gestion DBS au moins une requête M9 pour rétablir au sein de ladite base de données DB les informations correspondant à ce au moins un élément identifié dans le registre RM. Ces moyens P peuvent être mis en oeuvre de différentes façons. Il peut notamment s'agir d'un module logiciel au sein du dispositif D ou bien de lignes de code au sein d'un module logiciel plus général contenu ou constituant le dispositif D. La figure 5 illustre d'une autre façon l'enchaînement des étapes du procédé selon l'invention, mis notamment en oeuvre par ces moyens P du SASCH\Bull-04139-final.doc dispositif D. La description qui va suivre fera également référence aux figures 3 et 4 précédemment décrites. L'étape El consiste à intercepter les requêtes destinés au système de gestion DBS, et de détermination si une requête entrante donnée M1 est une requête en modification, c'est-à-dire qui est destinée à modifier des données dans la base de données DB. Cette requête en modification peut correspondre en langage SQL à une commande comme une commande d'insertion INSERT, une commande de mise-à-jour UPDATE, une commande de suppression DELETE, etc. Les commandes de création de tables, de modification de la structure de base de données peuvent également être considérées. A contrario, les commandes visant à ne faire qu'une opération de recherche (commandes SELECT en langage SQL, par exemple) ne sont pas considérées comme des requêtes en modification. Comme il a été évoqué précédemment, les requêtes M1 interceptées par le dispositif D peuvent ne pas être des requêtes SQL mais être conforme à un autre protocole de commandes, correspondant notamment à une application utilisant la base de données. À titre d'exemple, une commande peut prendre la forme #dbm-equipment delete port --filter node=nodel Cette ligne peut être interprétée comme une commande « dbmequipment » qui permet d'identifier une application et une base de données DB par le module logiciel traitant la commande. Cette commande peut typiquement être interprétée et traitée par une application de type « shell » sur un système d'exploitation de la famille Unix. Dans cet exemple, on comprend que la commande #dbm-equipment vise à gérer une base données DB relatif à un ensemble d'équipements d'un réseau d'ordinateurs. Le mot-clé « delete » qui suit fait référence à une opération de suppression dans la base de données DB. Il correspond à une requête SQL SASCH\Bull-04139-final.doc « Delete ». D'autres mots-clés peuvent être définis pour d'autres requêtes SQL. Le mot-clé suivant « port » signifie que la suppression concerne une table contenant les ports des équipements. L'expression suivante « --filter node=nodel » indique un filtre sur les noeuds (« node » en langue anglaise) du réseau. La commande signifie donc un ordre de suppression des ports relatifs au noeud « nodel ». Une telle ligne de commandes correspond à une requête en langage SQL et peut être traduite par le dispositif D avant transmission à l'interface de traitement des requêtes RI du système de gestion DBS, lors d'une étape E4, sous la forme de la requête M4. Les requêtes en modification sont traitées à l'étape E3, tandis que les requêtes qui ne sont pas considérées comme des requêtes en modification n'entrainent pas d'autre traitement une fois leur transmission effectuée. Cette étape de mémorisation E3 peut être effectuée avant ou après ou en parallèle de l'étape de transmission E4 de la requête M4. L'étape E3 consiste à mémoriser les requêtes en mémorisation dans le registre RM. Une requête interne M5 peut être adressée au registre RM afin de mémoriser la requête en modification Ml. Différentes mises en oeuvre sont bien évidemment possibles pour la structure du registre RM ainsi que pour le protocole de communication qui peut être mis en place entre les moyens P et le registre RM. Selon un mode de réalisation, le registre RM peut être un fichier textuel dans lequel les requêtes sont insérés les unes à la suite des autres. À chaque requête entrante M1 mémorisée correspond donc un élément ajouté dans ce registre RM, qui peut être une simple « ligne », c'est-à-dire une suite de caractères délimitée par un marqueur tel que le caractère « retour chariot » (ou « carnage return » en langue anglaise). Un tel élément peut avoir pour forme : SASCH\Bull-04139-final.doc Jan 12 23:34:45 localhost dbm-equipment lprogram="cdbm@clmBull" id="31" command="delete port --filter node=nodel" action="deletel A cdbm-equipment delete has been correctly performed. Dans cet exemple de réalisation, cet élément comprend la date (Jan 12) et l'heure (23:34:45) auxquels la requête a été reçue et traitée, la machine de provenance de la requête (ici, l'hôte local, « localhost »), la requête telle que reçue (« dbm-equipment"), l'application qui a déclenché la transmission de cette commande (ici « cdbm @c1mBull >>) un numéro pour cette requête qui, par conséquent, identifie aussi cet élément (id="31") ; et la requête proprement dite (« command=-delete port --filter node=nodel action="delete" ») ; un texte de statut indiquant que la requête de suppression a correctement effectuée. Le numéro de l'élément (ici 31) peut être fourni de façon séquentiel : chaque nouvelle insertion dans le registre RM est associé à un numéro suivant immédiatement le précédent. 11 peut être prévu un compteur, séparément du registre RM, qui maintient un numéro courant. Par ailleurs, si la requête en modification M1 est destinée à supprimer des données de la base de données DB, une étape d'interrogation E2 de la base de données pour récupérer des informations comprenant au moins ces données et les mémoriser dans le registre RM peut être mise en oeuvre. Par conséquent, la requête en modification M4 est temporisée au moins pendant la durée de l'étape d'interrogation E2. SASCH\Bull-04139-final.doc Elle peut également être effectuée avant même l'étape de mémorisation E3 afin qu'une unique requête interne M5 puisse viser à mémoriser à la fois la requête en modification M1/M4 et les données Une telle requête en modification peut correspondre à une requête « Delete » en langage SQL mais également à une requête « Update » puisque cette requête remplace une ancienne donnée par un nouvelle donnée. Elle est donc bien destinée à supprimer une ancienne donnée (ou un ensemble d'anciennes données). À ces fins, les moyens P sont prévus pour transmettre une ou plusieurs requêtes d'interrogation M2 à destination du système de gestion DBS. Cette requête vise à récupérer les données qui vont être supprimées par la requête M4. Ces données sont récupérées par un message de réponse M3 provenant du système de gestion DBS. Ce message de réponse contient des informations qui comprennent au moins les données en question mais également d'autres données, comme par exemple les numéros d'enregistrements correspondant aux données, le nom ou identifiant de la table concernée, etc. Ainsi dans l'exemple précédent correspondant à la ligne de commande « #dbm-equipment delete port --filter node=node 1 », la requête M2 consiste à récupérer les données de « port » correspondant au filtre « node=nodel ». Une requête en SQL peut être formée en ce sens. Par exemple : SELECT * FROM equipment port ep LEFT OUTER JOIN equipment e ON eld=ep.equipment id WHERE e.name='node l' ; Le message de réponse M3 fournit alors les informations correspondant à cette requête. Selon un mode de réalisation de l'invention, l'étape d'interrogation E2 comprend la transmission d'un ensemble de requêtes M2 afin de récupérer SASCH\Bull-04139-final.doc des informations comprenant au moins des données pouvant être supprimés par une cascade de suppressions. Le mécanisme de la cascade de suppression a été expliqué préalablement. Afin de résoudre la problématique engendrée par ce mécanisme automatique de suppression, les moyens P peuvent être adaptés pour, à la réception de la réponse M3 contenant des informations « de premier niveau », les analyser et déterminer des liens avec d'autres tables au sein de ses informations. Il s'ensuit un processus récursif qui, en quelque sorte, simule la cascade afin de récupérer tous les enregistrements qui pourraient être impactés et supprimés. À titre d'exemple illustratif, une première requête M2 pour générer les informations récupérées dans un premier message de réponse M3 suivantes : equipmen t_port(id: 15,h w addr: AA: AA: AA: AA: AA,equipment_port p rofile_id:3) Les moyens P peuvent alors analyser ces informations et transmettre une nouvelle requête M2 pour rechercher au sein de la base de données DB les enregistrements qui "pointent" vers cet enregistrement et qui pourraient donc être supprimés. Un exemple de requête pour trouver les tables reliées à 'equipment port' dans une base de données de type postgreSQL : SELECT kcu.column name, ccu.column name AS references table 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 SASCH\Bull-04139-final.doc = 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 lower(tc.constraint type) in ('foreign key') AND kcu.table name='equipment port' order by tc.table name; Cette requête va nous renvoyer la liste des tables qui pointent vers equipment port. Le nouveau message de réponse M3 peut contenir la ligne suivante : inter_equipment_link(id:5,equipmentl_port_id:15,network id:3) dans lequel le champ (ou colonne) « equipmentl_port_id » a pour valeur 15, c'est-à-dire le numéro de l'enregistrement précédemment récupéré de la table « equipment-port ». Une fois ce nouveau message de réponse reçu et analyser, une troisième requête M2 pourrait être transmise au système de gestion afin de récupérer les enregistrements, parmi l'ensemble des tables de la base DB, qui auraient une valeur de champ pointant vers l'enregistrement numéro 5 de la table « inter_equipment-link ». On obtient ainsi, dans cet exemple, les informations récupérées suivantes : equipment_port(id:15 h addr:AA:AA:AA:AA:AA,equipment port profile id:3) inter equipmen link(id:5,equip ntl _port id:15,net orkid:3) Chaque ligne comprend les données supprimées correspondant à un enregistrement (ou « ligne ») dans une table, ainsi que le nom des tables concernées : « equipment port » et « inter equipment link ». Pour chaque enregistrement, les données pour chaque colonne (ou champs) sont récupérées. Dans le format utilisé dans cet exemple, les noms SASCH\Bull-04139-final.doc (ou identifiant) de chaque champs sont donnés suivi par le délimiteur « : » et par la valeur de ce champ. Les données qui vont être supprimées sont les valeurs de ces champs, mais l'information comprend donc d'autres éléments comme notamment les noms de tables et de champs qui permettent de faciliter l'intelligibilité des données récupérées et de les situer au sein de la base de données DB. Les numéros des enregistrements sont également récupérés. Ces numéros (« id ») sont les clés primaires qui permettent d'identifier de façon unique un enregistrement au sein d'une table. Dans l'exemple, l'enregistrement id=15 de la table « equipment port » et l'enregistrement id=5 de la table « inter_equipment link » sont récupérés et transmis dans les messages de réponse M3. Les informations récupérées peuvent alors être mémorisées dans le registre RM. Elles peuvent être mémorisées en même temps que la requête en modification Ml. Un même élément au sein de ce registre peut alors comprendre à la fois la requête Ml et les informations récupérées qui lui correspondent. En reprenant le même exemple que précédement, le registre RM peut comprendre un élément comme suit : Jan 12 23:34:45 localhost dbm-equipment [program="cdbm@cimBull" command="delete port --filter node=node 1" action="delete" rows="equipment_port(id:l5,hwaddr:AA:AA:AA:AA:AA,equipmen t_port_profile_id:3),inter_equipment link(id:5,equipmentl_port_id: 15,network_id:3)"] A cdbm-equipment delete has been correctly performed Le mot-clé « rows = » permet d'introduire les informations comprenant les données des enregistrements qui vont (ou peuvent) être supprimés par la requête M1 « delete port --fiiter nocle=node 1 ». De cette SASCH\Bull-04139-final.doc sorte, ces informations sont facilement et naturellement associées à la requête en modification correspondante Ml. Les moyens P peuvent également être prévus pour permettre l'interrogation du registre RM par des utilisateurs U pour différentes finalités. La figure 4 illustre plus particulièrement cette phase d'utilisation du contenu du registre RM. Les moyens R du dispositif D peuvent recevoir une requête M6. Cette requête M6 peut viser différents buts. Il peut s'agit d'une requête visant à obtenir le contenu du registre RM en partie ou totalement afin de pouvoir soit simplement l'afficher, soit le traiter par un moyen logiciel (non représenté). Il peut en effet être intéressant pour l'utilisateur U d'avoir un état des requêtes en modification qui ont eu lieu sur la base de données depuis l'origine ou durant une fenêtre temporelle, ou pour un utilisateur donné, etc. Le traitement par un moyen logiciel peut consister à effectuer des calculs statistiques, etc. Par ailleurs, la requête M6 peut également être une requête en restauration. Cette requête en restauration M6 peut avoir pour forme : #dbm-equipment undo 31 Cette syntaxe est conforme aux exemples précédemment donnés et indique la base concernée DB, qu'une action de restauration (« undo » pour défaire, en langue anglaise) est demandée et un numéro identifiant l'élément concerné dans le registre RM. Ce numéro 31 correspond bien au terme « id="31" » indiqué dans l'exemple de contenu du registre RM donné ci-dessus. La requête identifie donc l'élément 31 au sein du registre RM. L'utilisateur peut connaître ce numéro 31 de différentes façons. Il peut notamment avoir transmis une requête M6 visant à afficher le contenu du SASCH\Bull-04139-final.doc registre RM. Il peut aussi accéder au registre RM directement. Celui-ci peut être un simple fichier texte formaté, de sorte qu'il peut être facilement accessible et lisible par un simple éditeur de texte. Parmi les informations contenues dans le registre RM figurent en effet des informations permettant d'identifier une requête par l'utilisateur U : il peut retrouver le type de requête (« Delete »...), sa date, les différents paramètres (filtre comme ici « --filter node=nodel »), etc. Les moyens P peuvent donc transmettre une requête M7 au registre RM pour récupérer les informations correspondant à l'élément 31, par un message de réponse M8. Il est à noter que « requête M7 » et « message de réponse M8 » doivent ici être compris dans un sens très général. S'agissant d'une communication interne au sein du dispositif D, différentes mises en oeuvre sont possibles. Notamment comme nous l'avons évoqué plus haut, le registre peut être un simple fichier texte. Auquel cas, les requête M7 et message de réponse M8 doivent être compris comme de simples opérations de lecture. Il en va de même de la requête interne M5 décrite en rapport avec la figure 3. L'élément récupéré dans la registre RM permet ensuite aux moyens P de mettre en oeuvre une étape de restaurant consistant à transmettre au système de gestion au moins une requête M9 pour rétablir au sein de la base de données DB les informations correspondant à cet élément. Dans l'exemple, ces requêtes M9 peuvent être, conformément au langage SQL, de la forme : INSERT INTO equipment port (id,hwaddr,equipment port profile id) VALUES (15,'AA:AA:AA:AA:AA',3) ; et INSERT INTO inter_equipment_link (ici, equipment l_port_id, network ici) SASCH\Bull-04139-final.doc VALUES (5, 15 De cette façon, la base de données DB est restaurée dans un état équivalent à celui où la requête en modification M1 n'aurait pas eu lieu. Il est à noter que selon un mode de réalisation de l'invention, l'identifiant de l'enregistrement (la clé primaire) est également restauré de sorte que la base est exactement rétablie. Selon un mode de réalisation, il est également possible de considérer les requêtes en restauration comme des requêtes en modification, puisque elles visent à modifier le contenu courant de la base de données DB. Elles seront donc traitées pareillement et il est alors possible de traiter une requête en restaurant sur une requête en restauration. Cette action correspond à une commande de type « redo » (refaire). 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. SASCH\Bull-04139-final.doc REVENDICATIONS1. Procédé d'interrogation d'un système de gestion (DBS) associé à une base de données (DB), comportant une étape d'interception (El) des requêtes destinés audit système de gestion et de détermination si une requête entrante est une requête en modification, destinée à modifier des donnés dans ladite base de données (DB), une étape de mémorisation (E3) de ladite requête en modification dans un registre (RM), et une étape (E4) de transmission de ladite requête entrante vers ledit système de gestion, 2. Procédé selon la revendication précédente, comportant en outre, si ladite requête en modification est destinée à supprimer des données de ladite base de données (DB), une étape d'interrogation (E2) de ladite base de données pour récupérer des informations comprenant au moins lesdites données et les mémoriser dans ledit registre (RM) en association avec ladite requête entrante. 3. Procédé selon la revendication précédente, dans lequel lesdites informations comprennent les numéros d'enregistrement correspondants auxdites données. 4. Procédé selon l'une des revendications 2 et 3, dans lequel ladite étape d'interrogation comprend la transmission d'un ensemble de requêtes afin de récupérer des informations comprenant au moins des données pouvant être supprimés par une cascade de suppressions. 5. Procédé selon l'une des revendications précédentes comportant en outre une étape de réception d'une requête en restauration, identifiant au moins un élément au sein dudit registre (RM), et une étape de restauration consistant à transmettre audit système de gestion au moins SASCH\Bull-04139-final.docune requête pour rétablir au sein de ladite base de données (DB) les informations correspondant audit au moins un élément. 6. Procédé selon l'une des revendications précédentes, dans lequel ladite requête en modification correspond en langage SQL à une commande appartenant à un groupe comprenant au moins une commande d'insertion INSERT, une commande de mise-à-jour UPDATE et une commande de suppression DELETE. 7. 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 à 6. 8. Dispositif (D) pour l'interrogation d'un système de gestion (DBS) associé à une base de données (DB), comprenant des moyens (P) pour intercepter des requêtes destinés audit système de gestion et pour déterminer si une requête entrante est une requête en modification, destinée à modifier des donnés dans ladite base de données (DB), et pour transmettre ladite requête entrante vers ledit système de gestion, et un registre pour mémoriser ladite requête en modification. 9. Dispositif selon la revendication précédente, dans lequel lesdits moyens (P) sont adaptés pour, si ladite requête en modification est destinée à supprimer des données de ladite base de données (DB), à interroger ladite base de données pour récupérer des informations comprenant au moins lesdites données et les mémoriser dans ledit registre (RM) en association avec ladite requête. 10. Dispositif selon la revendication précédente, dans lequel lesdites informations comprennent les numéros d'enregistrement correspondants auxdites données. SASCH\Bull-04139-final.doc11 Dispositif selon l'une des revendications 9 et 10, dans lequel lesdits moyens (P) sont prévus pour la transmission d'un ensemble de requêtes afin de récupérer des informations comprenant au moins des données pouvant être supprimés par une cascade de suppressions. 12. Dispositif selon l'une des revendications 8 à 11, dans lequel lesdits moyens sont prévus pour recevoir une requête en restauration, identifiant au moins un élément au sein dudit registre (RM), et pour transmettre audit système de gestion au moins une requête pour rétablir au sein de ladite base de données (DB) les informations correspondant audit au moins un élément. 13. Dispositif selon l'une des revendications 8 à 12, dans lequel ladite requête en modification correspond en langage SQL à une commande appartenant à un groupe comprenant au moins une commande d'insertion INSERT, une commande de mise-à-jour UPDATE et une commande de suppression DELETE. SASCH\Bull-04139-final.doc