Brevet FR2842002A1 — publié le 20040109

La présente invention concerne un procédé de stockage et d'accès à des données dans des bases de données d'un système de réservation de voyage par ordinateur. Elle concerne également un dispositif apte à mettre en oeuvre ce procédé. L'invention trouvera particulièrement son application pour des systèmes informatiques de réservation de transports aériens. A l'heure actuelle, les entreprises se chargeant de la gestion de tels systèmes de réservation par ordinateur ont besoin d'un grand nombre de personnes pour assurer la maintenance des données nécessaires à la vente des produits de 1o réservation. Ces données sont chacune liées à des plannings de réservation qui doivent être disponibles à la publication auprès des systèmes informatiques adhérant au système global. Cela peut inclure aussi bien des systèmes internes que des systèmes externes aux systèmes de ces entreprises. La maintenance des données nécessaire au système de réservation par ordinateur, telle qu'elle est opérée actuellement, pose plusieurs inconvénients. En premier lieu, les données sont appliquées aux différents plannings de vols, planning par planning. Cependant, l'organisation des systèmes de réservation par ordinateur a une logique actuellement tournée vers une représentation de marchés en terme géographique et non de planning. Un autre inconvénient actuel est que les données sont organisées par numéro de vol et non en terme d'origine et de destination du vol. Un autre inconvénient des techniques actuelles est le temps nécessaire pour générer les changements dans les bases de données. Une personne est en effet nécessaire pour la mise à jour de chaque vol individuel mais les changements affectés à un vol peuvent impliquer de multiples modifications, notamment dans différentes périodes de vol. Ainsi, un simple changement de vol peut entraîner plusieurs centaines de changements de lignes dans les plannings ou les enregistrements d'inventaire de réservations. Un autre inconvénient est que les modifications actuellement opérées impliquent une forte intervention humaine, ce qui augmente le risque d'erreur et les problèmes d'incohérence entre les plannings de vol et les inventaires. La présente invention permet de pallier les inconvénients des techniques connues jusqu'à présent et, pour ce faire, elle introduit de nouvelles logiques pour la gestion des bases de données afin de générer des changements plus rapides avec une plus grande précision et mieux adaptés aux besoins de la clientèle. Dans ce cadre, la présente invention propose un procédé de stockage et d'accès à des données qui utilise un mode et des critères de sélection permettant de mettre à jour ou de rechercher des contenus correspondant à un type d'information de façon plus efficace et appropriée en terme de marché correspondant à des zones géographiques distinctes. D'autres buts et avantages apparaîtront au cours de la description qui suit d'un mode préféré de réalisation de l'invention qui n'est cependant pas limitatif. La présente invention concerne un procédé de stockage et d'accès à des données dans des bases de données d'un système de réservation de voyages par ordinateur. Selon l'invention: - pour chaque type d'information à stocker, on crée des règles associant: ò un ensemble de critères définissant les voyages auxquels l'information s'applique, ò un contenu représentant la valeur de l'information à appliquer; - l'ensemble de critères d'une règle comporte une paire de marchés avec un marché d'origine que l'on définit par la zone géographique de départ du voyage et un marché de destination que l'on définit par la zone géographique d'arrivée du voyage, - on stocke les marchés définis dans une base de données, - on stocke les règles créées dans une base de données. Selon des modes préférés de réalisation, ce procédé est tel que: - on définit chaque marché par une zone géographique choisie parmi les types de zones géographiques suivants: aéroport, ville, état et pays, pays, région géographique, monde ou une combinaison de ces types de zones géographiques. - on crée une table dans laquelle on affecte à chaque type de zone géographique un rang de priorité décroissant en fonction de la précision de la zone géographique. - on détermine la priorité de chaque marché selon le rang de priorité du type de zones géographiques qui le définit ou de la combinaison des rangs de priorité des types de zones géographiques qui le définit. - on détermine la priorité de chaque paire de marchés en sommant la priorité du marché d'origine et la priorité du marché de destination. - on utilise des critères additionnels dans l'ensemble des critères, - on affecte un poids à chaque critère additionnel définissant son degré d'importance. - on accède à la règle stockée correspondant à une recherche de voyage en: * entrant le lieu d'origine et le lieu de destination du voyage, * recherchant les paires de marchés qui concordent avec lesdits lieux d'origine et de destination, * calculant la priorité de chaque paire de marchés concordant pour lesdits lieux d'origine et de destination, * retournant le contenu de la règle ayant la paire de marché dont la priorité a la valeur la plus faible. - si deux paires de marché concordant ont une même valeur de priorité, on retourne le contenu de la règle dont le marché d'origine a la plus faible valeur de priorité. A titre préféré, pour l'accès aux règles: 10. on entre des critères additionnels de recherche de voyage, 2 . pour chaque règle dont les paires de marché concordent avec les lieux d'origine et de destination, on calcule le poids de la règle correspondant à la somme des poids des critères additionnels de la règle, 30. on sélectionne la règle qui a le poids le plus élevé, 40. si les critères additionnels de recherche de voyage ne concordent pas avec les critères additionnels de la règle sélectionnée, on sélectionne la règle qui a le poids immédiatement inférieur, 50. si les critères additionnels de recherche de voyage concordent avec les critères additionnels de la règle sélectionnée en dernier lieu, on stocke le contenu de la règle, 60. tant que la contenu stocké ne répond que partiellement aux critères additionnels de recherche de voyage, on réitère les étapes 30 à 50, 70. on retourne le contenu des règles qui a été stocké. L'invention concerne également un dispositif de stockage et d'accès à des données dans des bases de données d'un système de réservation de voyages par ordinateur apte à mettre en ceuvre le procédé décrit précédemment. Selon l'invention, ce dispositif: - comporte des moyens de stockage de marchés d'origine définis par les zones géographiques de départ des voyages et des marchés de destination définis par les zones géographiques d'arrivée des voyages, - pour chaque type d'information à stocker, il comporte des moyens de saisie de règles associant: * un ensemble de critères définissant les voyages auxquels l'information s'applique, ò un contenu représentant la valeur de l'information à appliquer - il comporte des moyens de stockage des règles saisies. Les dessins ci-joints sont donnés à titre d'exemples et ne sont pas limitatifs de l'invention. Ils représentent seulement un mode de réalisation de l'invention et permettront de la comprendre aisément. La figure 1 est une vue schématique générale de certains composants d'un système de réservation par ordinateur. La figure 2 présente un diagramme illustrant l'ajout d'une paire de marchés. La figure 3 est un autre diagramme illustrant l'ajout de critères additionnels dans une règle. La figure 4 montre un exemple de recherche de règle applicable dans le cadre d'une recherche de voyage. En référence à la figure 1, un utilisateur peut mettre en oeuvre le procédé de l'invention par l'intermédiaire d'une interface utilisateur graphique 6 qui permet d'accéder à d'autres constituants d'un système de réservation par ordinateur 1. Parmi ces constituants, un serveur central 2 assurant la gestion des règles du système est présent et relié à une base de données centrale 3. La base de données centrale 3 est apte à stocker les règles qui seront définies ci-après. Par ailleurs, un serveur de définition de marche géographique 4 est également présent et comporte une base de données de marche 5 apte à stocker une liste de marchés qui seront également définis ci-après. Selon l'invention, on gère de façon nouvelle le stockage d'informations de différents types. Les types d'information sont relatifs aux données attribuées aux différents voyages. Dans la suite de la description, on donne un exemple correspondant à une application préférée à des transports aériens o les voyages correspondent à des vois. On entend par vol un transport de passagers entre un point d'origine (lieu d'origine) et un point de destination (lieu de destination). Dans cet exemple différents types d'information sont nécessaires et notamment: - les numéros de terminaux d'embarquement, - des renseignements concernant les restrictions de trafic, - des règles relatives à la distribution de tickets par Internet, - des règles relatives à la fourniture de repas, - les types de classes de réservation qui sont admissibles Pour gérer le contenu affecté à chaque type d'information pour chaque élément de vol contenu dans les bases de données du système de réservation, la présente invention utilise la création de règles. Ces règles comportent un premier volet correspondant aux critères utilisés pour la sélection de voyages auxquels s'applique le type d'information. Un autre volet de la règle est constitué par le contenu correspondant à la description de la valeur attribuée aux types d'information pour les voyages correspondants à la règle. On utilise, à cet effet, un ensemble de critères de définition de chaque règle. En premier lieu, un critère utilisé consiste en la création de paires de marchés. Dans chaque paire de marchés, on distingue un marché d'origine et un marché de destination relatifs respectivement à la zone géographique de départ et à la zone géographique d'arrivée des voyages. Chaque marché peut être un aéroport, une ville, un état, un pays, une région ou encore le monde entier. On affecte ainsi aux règles une définition géographique, par marché,. Les marchés peuvent ne pas être homogènes, à savoir qu'ils peuvent être constitués par une combinaison de différents types de zones géographiques. Bien entendu, la définition des marchés doit être cohérente. Par exemple, la zone géographique NICE ne peut être incluse à la fois dans la zone géographique française et dans la zone géographique italienne. Les différents marchés créés sont répertoriés dans une table dans laquelle on leur affecte une valeur de priorité. La valeur de la priorité d'un marché est fonction du rang de priorité de la zone géographique qui le définit ou de la combinaison des rangs de priorité des zones géographiques qui le définit (si le marché n'est pas homogène). En affectant un rang de priorité aux différents types de zones géographiques, on reflète la précision ou la large étendue de la zone géographique correspondante. On donne dans le tableau ci-après un exemple d'affectation de rangs de priorité à différents types de zones géographiques. Type de zone géographique Rang de priorité Aéroport i Ville 2 Pays et état 3 Pays 4 Région géographique 5 Monde 6 En utilisant cette table, on peut associer, au niveau du serveur 4, la valeur de priorité à chaque marché correspondant à un paramètre d'entrée. Par exemple, l'utilisation considère la définition de marché non homogène suivante: Ml = Londres + France, si la saisie effectuée par un utilisateur en entrée est: aéroport Charles de Gaulle, le marché Ml concorde avec ce critère de recherche avec une valeur de priorité de 4 car l'aéroport Charles de Gaulle concorde avec la définition de pays: France dont le rang de priorité pour ce type de zone géographique est de 4. Si on considère une entrée de l'utilisateur lors d'une opération de recherche correspondant à l'aéroport d'Heathrow, le marché 1 concorde avec une valeur de priorité de 2 car l'aéroport d'Heathrow est inclus dans la zone géographique de Londres qui est un type de zone géographique ayant un rang de priorité de 2. Par ce calcul de priorité de chaque marché, on peut obtenir la valeur de la priorité d'une paire de marchés par simple somme des valeurs de priorité de chaque marché la constituant. A titre d'exemple supplémentaire à ce sujet, si on considère la paire de marchés suivante qui a été créée: FRANCE - NICE + GRANDE-BRETAGNE -i NOUVELLE-ZELANDE + SYDNEY + MELBOURNE, Les deux marchés qui composent la paire sont hétérogènes. Leur priorité se fait en référence avec une paire de lieux d'origine et de destination rentrés par l'utilisateur, par exemple lors d'une opération de recherche. Ainsi, l'utilisateur rentrant le lieu d'origine AEROPORT CHARLES DE GAULLE, obtiendra une valeur de priorité du marché d'origine de 4 (rang de la zone géographique FRANCE). Par ailleurs, s'il saisit comme lieu de destination l'aéroport de SYDNEY, le marché de destination aura une valeur de priorité de 1 (correspondant au rang de priorité de la zone géographique SYDNEY). En conséquence, la valeur de priorité de la paire de marchés ainsi constituée io estégaleà4+ 1=5. On comprend aisément que la définition de telles paires de marchés et l'affectation de contenus de types d'information n'est pas toujours suffisant à la définition de règles précises. Pour affiner la sélection ainsi opérée par les paires de marchés, on utilise iS avantageusement des critères additionnels qui font partie intégrante de l'ensemble des critères définissant les voyages auxquels l'information s'applique dans la règle. En outre, on affecte un poids à chaque critère additionnel afin de définir son degré d'importance. On donne dans le tableau ci-après un exemple de critères additionnels utilisables avec leur poids respectif. Critère additionnel Poids Groupe de vol 64 Type de partage d'occupation 32 Période de vol 16 Jour de la semaine 8 Type d'avion 4 Heure de départ 2 Durée du vol I Un ensemble de critères associés à une règle peut comporter une combinaison de critères additionnels tels qu'ils ont été présentés précédemment. Dans ce cadre, le poids total des critères additionnels affectés à une règle correspond à la somme des poids individuels de ces critères. Par exemple, pour une règle dont le seul critère additionnel est le groupe de vol, le poids total est de 64. Ce poids est donc supérieur à celui d'une règle dont les critères additionnels sont période de vol + jour de la semaine + heure de départ du vol (dont le poids est 16+8+2 = 26). L'association de ces critères additionnels et de la définition de paires de marchés assure une création sans ambiguté de règles permettant d'affecter un contenu d'un type d'information aux données relatives aux voyages. Bien entendu, on vérifie l'intégrité et la cohérence des données ainsi contenues dans chaque règle. En particulier, si des critères additionnels sont de 1o même type et ont le même poids pour définir des règles différentes, le système va vérifier qu'il n'y a pas de chevauchement entre les valeurs affectées à ces différents critères. En référence successivement aux figures 2 à 4, on donne ci-après différents exemples de mise en oeuvre du procédé, pour différentes fonctionnalités. La figure 2 illustre une possibilité d'ajout ou de mise à jour de règles. Dans un premier temps, le processus démarre par une vérification que la paire de marchés saisie n'existe pas déjà pour le type d'information considéré. Si tel est le cas, une information d'erreur est retournée par un indicateur de conflit. Si cette paire n'existe pas encore pour le type d'information considéré, on vérifie qu'elle n'implique pas de chevauchement avec d'autres paires de marchés. A cet effet, on recherche les origines et les destinations communes dans d'autres éléments de marchés. Si un tel chevauchement existe, on retourne une information de conflit par un indicateur de conflit. Sinon, on ajoute la règle ainsi constituée par défaut. On met ensuite à jour l'historique et on termine l'opération. Pour ajouter des critères additionnels à une règle ainsi prédéfinie, on effectue le processus illustré à la figure 3. Dans ce cadre, la règle prédéfinie obtenue par les étapes de la figure 2 est ouverte. Si elle n'est pas retrouvée dans le système, une information d'erreur est retournée. Si elle est retrouvée, on calcule la priorité du critère additionnel saisi en entrée. On recherche alors si des critères additionnels ayant la même priorité existent déjà. On recherche ensuite s'il y a un éventuel chevauchement entre la valeur des critères dans un tel cas de critères additionnels avec la même priorité. S'il n'y a pas de chevauchement, on peut ajouter le critère additionnel à la règle. S'il y a chevauchement, on retourne une information " règles en conflit ". On donne ci-après une troisième fonctionnalité possible du procédé de l'invention selon laquelle on recherche une règle applicable à des données en entrée. Cet exemple est illustré à la figure 4. En entrée, l'utilisateur saisit une paire de lieux correspondant au lieu d'origine et au lieu de destination souhaités pour sa recherche. Eventuellement, io d'autres critères additionnels de recherche peuvent être saisis telle que la période de vol souhaitée. Généralement, les lieux d'origine et de destination sont constitués par des noms d'aéroport. A ce stade, on demande au serveur 2 la liste des paires de marchés correspondant aux critères saisis ainsi que leur valeur de priorité. On ouvre les règles correspondantes à ces paires de marchés qui concordent pour le type d'information recherché. On détermine alors le poids des critères additionnels de chaque règle pour définir le poids total de la règle. On peut ainsi classer l'ordre de traitement des différentes règles qui ont été retournées. A cet effet, on commence par sélectionner la règle qui comporte le poids total le plus élevé. S'il s'avère que plusieurs règles ont un même poids, on commence par sélectionner celle qui a la priorité la plus précise pour la paire de marchés. En outre, s'il s'avère également que les règles ont un même niveau de priorité de paire de marchés, on sélectionne d'abord celle qui a le niveau de priorité du marché d'origine le plus précis. Une fois que la règle est ainsi sélectionnée, on vérifie si les critères additionnels concordent avec les critères de recherche saisis par l'utilisateur. S'il s'avère que ces critères concordent, on stocke le contenu associé à la règle. Sinon, on réitère l'étape de sélection d'une autre règle, en commençant par la règle de poids immédiatement inférieur. Lorsqu'on a stocké le contenu de règle apte à renseigner l'utilisateur pour répondre à sa requête, on retourne le contenu final ainsi stocké. Il est possible que le contenu d'une règle ne renseigne que partiellement l'utilisateur dans sa recherche. Par exemple, le contenu d'une règle ne peut concerner qu'une période de vol particulière ne couvrant pas totalement la période de vol recherchée par l'utilisateur. Dans ce cadre, une fois stocké le contenu de la règle sélectionnée, on réitère encore les opérations de sélection de règle pour rechercher dans les règles successives le complément de contenu nécessaire à la réponse. Afin d'illustrer encore le fonctionnement de la présente invention, on présente ci-après deux exemples détaillés dans la recherche de règle correspondant à une io demande utilisateur. Dans un premier exemple, 4 marchés sont définis comme suit: Ml = GrandeBretagne + France - Charles de Gaulle M2 = Grande-Bretagne + Bangkok + Singapour M3 = Europe M4 = Bangkok Dans le cadre d'une règle de type restriction de trafic, les règles suivantes sont définies: Critères Identification de la règle Contenu de la règle Poids Paire de marchés: M3 -- M4 R5 K 64+16 = 80 Groupe de vol BAl-10 Période de vol 20 janvier Paire de marchés: M1l- M2 R4 R, L 64+16 = 80 Groupe de vol: International Période de vol: 1er au 15 Janvier Paire de marchés: M1l- M2 R3 W 64+8 = 72 Groupe de vol: Intérieur Jour de la semaine: 7 Paire de marchés: M3 -- M4 R2 L 16 Période de vol: 10 au 20 janvier Paire de marchés: Ml -- M2 Rl K 0 La période de vol entrée est: LONDRES HEATHROW -- BANGKOK - BA9 - 1 OJAN-31 JAN - 1234567 Deux règles ont la même priorité (80) et l'entrée concorde avec tous les critères. Le procédé détermine quelle règle va être sélectionnée en sélectionnant la paire de marchés la plus précise: il M3 fait concorder Londres Heathrow avec une priorité de 5 M4 fait concorder Bangkok avec une priorité de 1 Ml fait concorder Londres Heathrow avec une priorité de 4 M2 fait concorder Bangkok avec une priorité de 5 De ce fait la paire de marchés M3-M4 a une priorité de 5+1=6 et la paire de marchés M1-M2 a une priorité de 4+1=5. Le procédé va donc sélectionner la paire de marchés Ml-M2 (règle R4) qui est la paire de marchés la plus précise. La règle R4 s'applique car BA9 fait partie d'un groupe de vol international. 1o Par contre, comme il y a une période de vol, la règle R4 ne s'applique que du 10 au janvier. Le procédé doit donc trouver une autre règle. Il sélectionne la deuxième règle qui a la même priorité mais dont la paire de marchés est moins précise (à savoir la règle R5) qui ne s'applique que le 20 janvier. Comme le vol n'est pas complètement défini, le procédé va rechercher la règle qui a la meilleure priorité, à savoir la règle 3 qui a une priorité égale à 72. Par contre, comme un des critères de cette règle est intérieur et que l'entrée est international (BA9 fait partie d'un groupe de vol international), cette règle R3 ne s'applique pas. Le procédé regarde alors la règle R2 qui a une priorité de 16 et note qu'elle s'applique du 16 au 19 janvier. La règle Rl, qui n'a pas de priorité, s'applique du 21 au 31 janvier. De ce fait, les règles qui seront retournées sont: - R5 qui s'applique uniquement le 20 janvier - R4 qui s'applique du 10 au 15janvier - R2 qui s'applique du 16 au 19 janvier - RI qui s'applique du 21 au 31 janvier Dans un deuxième exemple, les 4 marchés sont définis comme suit: Ml = Japon + France M2 = Australie M3 = Monde M4 = Asie Dans le cadre d'une règle de type restriction de trafic, les règles suivantes sont définies: Critères Identification de la règle Contenu de la règle Poids Paire de marchés: M3 -* M4 Ri K 64+16 = 80 Groupe de vol: BAl-10 Période de vol: 10 au 15 janvier Paire de marchés: M3-* M4 R2 R, L 16 Période de vol: 10 au 20 Janvier Paire de marchés: M2-> MI R3 W 16 Période de vol: 10 au 20 Janvier Paire de marchés: M3 -* M3 R4 L 0 La période de vol entrée est: MELBOURNE -> TOKYO - BAI - 1 OJAN-20JAN - 1234567 Le procédé va sélectionner la règle RI ayant une priorité de 80. Toutefois, comme la règle a une période de vol qui ne couvre pas la totalité des paramètres de l'entrée, l'utilisateur va devoir chercher une autre règle. Deux règles ont une même priorité de 16 et concordent avec tous les critères. Le procédé va déterminer quelle règle va être sélectionnée en sélectionnant i0 la paire de marchés la plus précise: M3 fait concorder Melbourne avec une priorité de 6 M4 fait concorder Tokyo avec une priorité de 5 M2 fait concorder Melbourne avec une priorité de 4 MI fait concorder Tokyo avec une priorité de 4 De ce fait la paire de marchés M3- M4 a une priorité de 5+6= 11 et la paire de marchés MI-M2 a une priorité de 4+4=8. Le procédé va donc sélectionner la paire de marchés M2-Ml correspondant à la règle 3 du fait que c'est la paire de marché la plus précise. Le vol est complètement défini car la totalité des paramètres de l'entrée est couverte par le critère de la période de vol. De ce fait, les règles qui seront retournées sont: - RI qui s'applique 10 au 15 janvier - R3 qui s'applique du 15 au 20 janvier Bien entendu, le procédé de l'invention peut comporter d'autres fonctionnalités par exemple liées à l'effacement de règles précédemment créées. REFERENCES 1. Système de réservation par ordinateur 2. Serveur central 3. Base de données centrale 4. Serveur de points de vente 5. Base de données de points de vente 6. Interface utilisateur graphique REVENDICATIONS 1. Procédé de stockage et d'accès à des données dans des bases de données d'un système de réservation de voyages par ordinateur, caractérisé par le fait que - pour chaque type d'information à stocker, on crée des règles associant: * un ensemble de critères définissant les voyages auxquels l'information s'applique, * un contenu représentant la valeur de l'information à appliquer; - l'ensemble de critères d'une règle comporte une paire de marchés avec un marché d'origine que l'on définit par la zone géographique de départ du voyage et un marché de destination que l'on définit par la zone géographique d'arrivée du voyage, - on stocke les marchés définis dans une base de données, - on stocke les règles créées dans une base de données. 2. Procédé selon la revendication 1 caractérisé par le fait qu'on définit chaque marché par une zone géographique choisie parmi les types de zones géographiques suivants: aéroport, ville, état et pays, pays, région géographique, monde ou une combinaison de ces types de zones géographiques. 3. Procédé selon la revendication 2 caractérisé par le fait qu'on crée une table dans laquelle on affecte à chaque type de zone géographique un rang de priorité décroissant en fonction de la précision de la zone géographique. 4. Procédé selon la revendication 3 caractérisé par le fait qu'on détermine la priorité de chaque marché selon le rang de priorité du type de zones géographiques qui le définit ou de la combinaison des rangs de priorité des types de zones géographiques qui le définit. 5. Procédé selon la revendication 4 caractérisé par le fait qu'on détermine la priorité de chaque paire de marchés en sommant la priorité du marché d'origine et la priorité du marché de destination. 6. Procédé selon l'une quelconque des revendications 1 à 5 caractérisé par le fait - qu'on utilise des critères additionnels dans l'ensemble des critères, - qu'on affecte un poids à chaque critère additionnel définissant son degré d'importance. 7. Procédé selon la revendication 5 caractérisé par le fait qu'on accède à la règle stockée correspondant à une recherche de voyage en: entrant le lieu d'origine et de lieu de destination du voyage, * recherchant les paires de marchés qui concordent avec lesdits lieux d'origine et de destination, * calculant la priorité de chaque paire de marchés concordant pour lesdits lieux d'origine et de destination, * retournant le contenu de la règle ayant la paire de marché dont la priorité à a la valeur la plus faible. 8. Procédé selon la revendication 7 caractérisé par le fait que si deux paires de marché concordant ont une même valeur de priorité, on retourne le contenu de la règle dont le marché d'origine a la plus faible valeur de priorité. 9. Procédé selon la revendication 7 ou la revendication 8 en combinaison avec la revendication 6 caractérisé par le fait que 10. on entre des critères additionnels de recherche de voyage, 20. pour chaque règle dont les paires de marché concordent avec les lieux d'origine et de destination, on calcule le poids de la règle correspondant à la somme des poids des critères additionnels de la règle, 30. on sélectionne la règle qui a le poids le plus élevé, 4 . si les critères additionnels de recherche de voyage ne concordent pas avec les critères additionnels de la règle sélectionnée, on sélectionne la règle qui a le poids immédiatement inférieur, 50. si les critères additionnels de recherche de voyage concordent avec les critères additionnels de la règle sélectionnée en dernier lieu, on stocke le contenu de la règle, 60. tant que la contenu stocké ne répond que partiellement aux critères additionnels de recherche de voyage, on réitère les étapes 30 à 50, 7 . on retourne le contenu des règles qui a été stocké. 10. Dispositif de stockage et d'accès à des données dans des bases de données d'un système de réservation de voyages par ordinateur apte à mettre en oeuvre le procédé selon l'une quelconque des revendications 1 à 9 caractérisé par le fait - qu'il comporte des moyens de stockage de marchés d'origine définis par les zones géographiques de départ des voyages et des marchés de destination définis par les zones géographiques d'arrivée des voyages, que pour chaque type d'information à stocker, il comporte des moyens de saisie de règles associant: * un ensemble de critères définissant les voyages auxquels l'information s'applique, ò un contenu représentant la valeur de l'information à appliquer - qu'il comporte des moyens de stockage des règles saisies.