FR 3001067 A1 20140718 FR 1350313 A 20130114 - 1 - « Procédé et système de traitement de données pour effectuer un tri au sein d'un ensemble d'entités numériques » La présente invention concerne un procédé de traitement de données numériques pour réaliser un tri au sein d'un ensemble d'entités numériques, et plus particulièrement d'entités numériques représentant chacune des caractéristiques d'un produit physique ou d'un service. L'invention concerne plus particulièrement un procédé de tri d'informations relatives à des produits ou services représentés chacun par une entité numérique comprenant une représentation numérique des caractéristiques du produit ou du service. Plus particulièrement, l'invention concerne un traitement de données numériques pour réaliser un tri dans un catalogue électronique de produits et/ou de services, ou plus particulièrement de naviguer dans un tel catalogue, selon des critères de tri portant sur des informations relatives aux produits présents dans le catalogue et représentés chacun par une entité numérique mémorisées dans une ou des bases de données. Etat de la technique Actuellement, de nombreux sites Internet proposent des outils de tri d'informations de produits proposés à la vente dans des catalogues électroniques, avec l'objectif de fournir un ou des produits correspondant à des critères renseignés par l'utilisateur. Ces outils permettent à l'utilisateur de naviguer plus facilement et de manière plus ergonomique au sein d'un catalogue comprenant des milliers de produits et d'atteindre un groupe de produits qui l'intéresse et qu'il est susceptible d'acheter. Les outils de tri permettent aux utilisateurs de trier les produits d'une même famille selon plusieurs critères de tri proposés, tel que par exemple prix, marque, couleur, etc. Pour chacun des critères de tri proposés plusieurs valeurs de tri sont disponibles, telles que par exemple des tranches de prix lorsque le critère de tri est le prix. Un procédé de tri connu comprend, préalablement à toute requête de 35 tri d'un utilisateur, une étape préliminaire de pré-tri réalisant une - 2 - génération, à partir d'une ou plusieurs bases de données de produits, appelées bases de données source, d'une base de donnés multidimensionnelle, appelée cube, dans lequel tous les produits sont triés suivant tous les critères de tri, chaque critère de tri correspondant à une dimension du cube. Puis, lors de la réception d'une requête de tri, le procédé accède le cube aux dimensions concernées et le résultat du tri est fourni. Ce procédé présente plusieurs inconvénients dont celui de nécessiter une puissance de calcul importante lors de la génération du cube multidimensionnelle. De plus, pour prendre en compte une modification d'une donnée dans la base de données source, le cube multidimensionnel doit être régénéré à chaque modification, ce qui rend difficile, voire impossible, la possibilité, dans un tel procédé de tri, de prendre en compte des données changeant fréquemment, telles que par exemple une quantité disponible à la vente pour tel ou tel produit et éventuellement dans tel ou tel point de vente. Enfin, ce procédé permet de réaliser un tri avec des valeurs de tri prédéterminées pour les critères de tri. D'autres procédés de tri connus, ne comprennent pas une étape préliminaire de pré-tri. Ces procédés accèdent la base de données source à chaque réception d'une requête de tri et testent tous les critères de tri de la requête de tri sur chacun des produits. Ces procédés de tri présentent plusieurs inconvénients dont celui de nécessiter d'importantes ressources informatiques et un temps de réponse long, ces inconvénients s'empirant avec la fréquentation du site et la complexité des requêtes de tri. Un but de l'invention est de pallier les inconvénients précités. Un autre but de l'invention est de proposer un procédé et un système de traitement de données réalisant un tri au sein d'un ensemble d'entités numériques plus flexible que les procédés et systèmes connus. Un autre but de l'invention est de proposer un procédé et un système de traitement de données réalisant un tri au sein d'un ensemble d'entités numériques, permettant la prise en compte de données changeant tout en nécessitant moins de ressources informatiques que les procédés actuels. Un autre but de l'invention est de proposer un procédé et un système de traitement de données réalisant un tri au sein d'un ensemble d'entités - 3 - numériques, permettant la prise en compte de données changeant tout en proposant un temps de réponse moins long que les procédés actuels. Enoncé de l'invention L'invention propose d'atteindre au moins un de ces buts par un procédé de traitement de données pour effectuer un tri au sein d'un ensemble d'entités numériques, dits enregistrements, chacun desdits enregistrements étant représenté par au moins une donnée numérique, dite valeur, associée à au moins un critère, dit de tri, et mémorisée dans une base de données, dite source, en association avec au moins une donnée d'identification dudit enregistrement, ledit procédé comprenant : - une étape de réception d'une requête, dite de tri, comprenant au moins une relation de filtrage visant un critère de tri, et - une phase d'obtention, à la volée et à partir de ladite base de données source, d'une base de données, dite cube de tri, comprenant une dimension associée à chaque critère de tri visé dans ladite requête de tri, chaque dimension : ^ étant indépendante des autres dimensions dudit cube, et ^ comprenant, un ou plusieurs membres, correspondant chacun à une valeur que peut prendre le critère de tri auquel est associée ladite dimension et mémorisant un identifiant d'au moins un enregistrement présentant ladite valeur pour ledit critère de tri ; - une phase de filtrage dudit cube de tri avec l'au moins une relation filtrage composant ladite requête de tri ; - une phase de détermination d'un résultat de tri, en fonction dudit filtrage. Ainsi, le procédé selon l'invention permet d'obtenir, à la volée et suite à la réception d'une requête de tri, à partir d'une base de données source, un cube multidimensionnel comprenant une dimension pour chacun des critères de ladite requête de tri reçue. Suivant le procédé selon l'invention, une dimension du cube associée à un critère de tri est construite/générée/obtenue uniquement lors de la réception d'une première - 4 - requête de tri concernant ce critère de tri. Autrement dit, dans le cas où un critère de tri n'est concerné par aucune requête de tri reçue aucune dimension associée à ce critère de tri ne sera présente dans le cube multidimensionnel. Le procédé selon l'invention permet donc d'éviter la construction d'un cube multidimensionnel comprenant une dimension pour chaque critère de tri de l'ensemble des critères de tri disponibles, préalablement à la réception de toute requête de tri. Ainsi, le procédé de tri selon l'invention nécessite une puissance de calcul moins grande pour la génération du cube multidimensionnel comparé aux procédés de l'état de la technique réalisant un pré-tri. De plus, le cube multidimensionnel généré dans le procédé selon l'invention est plus petit que celui généré dans les procédés de l'état de la technique relisant un pré-tri. Par conséquent, lors du changement d'une donnée dans la base de données source, la régénération du cube multidimensionnel peut être réalisée fréquemment sans pour autant nécessiter une puissance de calcul aussi grande que celui demandé par les procédés de l'état de la technique réalisant un pré-tri. Dans le procédé selon l'invention, une dimension associée à un critère de tri est construite uniquement suite à une requête concernant ce critère de tri. Il est donc possible avec le procédé de tri selon l'invention de réaliser un tri plus flexible et plus personnalisable, avec des valeurs de tri choisies par l'utilisateur, comparé aux procédés de l'état de la technique réalisant un pré-tri avec des valeurs de tri prédéterminées et imposées à l'utilisateur. De plus, lorsqu'une donnée concernant un critère de tri est modifiée avant la génération de la dimension associée à ce critère de tri, une telle modification ne nécessite pas la régénération du cube de tri. En outre, le procédé selon l'invention ne teste pas tous les critères de tri d'une requête tri sur toutes les entités de la base de données source mais uniquement sur celles présentes dans les dimensions du cube de tri. Par conséquent, le procédé selon l'invention permet de réaliser un tri en un temps de réponse plus court, tout en utilisant moins de ressources informatiques, comparés aux procédés de tri de l'état de la technique ne réalisant pas de pré-tri.35 - 5 - Selon l'invention, l'« identifiant » d'un enregistrement mémorisé par un membre d'une dimension peut être la donnée d'identification dudit enregistrement mémorisée dans la base de données source, ou une donnée, différente de ladite donnée d'identification calculée à partir de ladite donnée d'identification avec une fonction prédéterminée. Avantageusement, la requête de tri peut en outre comprendre une relation, dite de sortie, utilisée pour classer les enregistrements obtenus après la phase de filtrage, et en particulier les enregistrements dont les identifiants sont mémorisés dans un groupe final d'identifiants fournis par la phase de filtrage. Dans ce cas, le procédé selon l'invention peut en outre comprendre, après la phase de filtrage, une phase de classement des enregistrements vérifiant les relations de filtrage, en particulier les enregistrements dont les identifiants sont mémorisés dans le groupe final fourni par la phase de filtrage. D'une manière similaire voire identique à une relation de filtrage, chaque relation de sortie vise un critère de tri, i.e. une dimension du cube. Une relation de sortie peut présenter la même architecture qu'une relation de filtrage. Dans ce cas, la différence entre lesdites relations peut être concrétisée par formalisme par exemple. En variante, la requête de tri peut comprendre deux listes séparées : une première liste comprenant les relations de filtrage et une deuxième liste comprenant les relations de sortie. Préférentiellement, chaque dimension du cube peut comprendre autant de membres qu'il existe de valeurs différentes dans la base de données source, sur l'ensemble des enregistrements, pour le critère auquel ladite dimension est associée. Par exemple, et de manière non limitative, pour le critère de tri « COULEUR » chaque couleur différente, présente dans la base de données source sur l'ensemble des enregistrements, constitue un membre. Par exemple, si pour le critère de tri « COULEUR », l'ensemble des enregistrements présents dans la base de données source présente comme valeur soit « ROUGE », soit « VERT » soit « BLEU » alors la dimension - 6 - associée au critère de tri « COULEUR » comporte trois membres, à savoir « ROUGE », « VERT » et BLEU ». Selon un autre exemple non limitatif, pour le critère de tri « MARQUE » chaque marque différente, présente dans la base de données source sur l'ensemble des enregistrements, constitue un membre. Par exemple, si pour le critère de tri « MARQUE », l'ensemble des enregistrements présents dans la base de données source présente comme marque soit « BMW® », soit « AUDI® », soit « PORSCHE® » alors la dimension associée au critère de tri « MARQUE » comporte trois membres, à savoir « BMW® », « AUDI® » et « PORSCHE® ». Dans une version particulièrement préférée du procédé selon l'invention, la phase d'obtention du cube de tri peut comprendre les étapes suivantes : - détermination de tous les critères de tri visés dans la requête de tri, à savoir les critères de tris visés par les relations de filtrage et les relations de sortie de la requête de tri, - consultation d'un cube existant pour déterminer si ledit cube existant comprend, pour chacun des critères de tri visé dans la requête de tri, une dimension associée audit critère de tri : si oui, utilisation dudit cube existant comme cube de tri, sinon, complétion dudit cube existant avec chacune des dimensions manquantes à partir de la base de données source et utilisation dudit cube existant ainsi complété comme cube de tri. Ainsi, lorsqu'après la réception de la requête de tri, un cube existant comprend pour chaque critère de tri visé dans la requête de tri une dimension associée audit critère de tri, le cube existant est utilisé comme cube de tri. Une telle utilisation d'un cube existant évite toute génération d'une dimension ou toute consultation de la base de données source et permet ainsi de diminuer les ressources informatiques et le temps de réponse pour l'obtention du cube de tri. En outre, lorsqu'après la réception de la requête de tri, un cube existant comprend des dimensions associées à certains seulement des - 7 - critères de tri visés dans la requête de tri, ce cube existant peut être complété par la ou les dimensions associées à chacun des critères de tri manquants pour obtenir le cube de tri. Une telle utilisation d'un cube existant limite le nombre de dimensions à générer et par conséquent, la consultation de la base de données source, les ressources informatiques et le temps de réponse pour l'obtention du cube de tri. Lorsque plusieurs cubes existants comprennent chacun une ou des dimensions associée(s) à un ou plusieurs critères de tri visé(s) par la requête de tri, c'est le cube existant auquel il manque le moins grand nombre de dimensions, qui est complété pour obtenir le cube de tri. Chacun des cubes existant peut être un cube de tri préalablement généré ou obtenu pour une ou des requêtes de tri précédemment traitée(s). Lorsque suite à la réception d'une requête de tri aucun cube de tri n'existe, alors la phase d'obtention peut comprendre une étape de création d'un cube de tri comprenant une ou plusieurs dimensions, chaque dimension du cube ainsi créée étant ensuite alimentée par accès à la base de données source. Le procédé selon l'invention peut préférentiellement comprendre, une mémorisation, plus particulièrement en mémoire vive, d'un cube de tri utilisé pour une requête de tri donnée, en vue de son utilisation future pour une requête de tri à venir, soit tel qu'il est soit en ayant été préalablement complété par ajout d'au moins une dimension, tel que décrit plus haut. Ainsi, les ressources informatiques et le temps de réponse pour obtenir le cube de tri, et par conséquent pour réaliser le tri, sont diminués comparés aux procédés de l'état de la technique. Le procédé selon l'invention peut en outre comprendre une étape de 30 suppression d'un cube de tri, ou d'une dimension d'un cube de tri, préalablement généré(s) et chargé(s) en mémoire, si ce (cette) dernier(e) n'est pas utilisé(e) pour une durée prédéterminée, qui peut être ajustable. Dans une version du procédé selon l'invention où un cube existant est 35 réutilisé comme cube de tri, soit tel qu'il est, soit après avoir été complété - 8 - par ajout d'au moins une dimension manquante, la requête de tri reçue peut comprendre une donnée d'identification d'un tel cube existant. Un tel cube peut être mémorisé dans une base de cubes comprenant au moins un cube. Pour plus de réactivité et un temps de réponse plus faible, un tel cube existant ou une telle base de cube peut préférentiellement être mémorisé(e) dans des moyens de mémorisation vive, des moyens de mémorisation à accès direct ou encore des moyens de mémorisation volatiles. Ainsi, il est possible de créer et manipuler plusieurs cubes, chaque cube concernant un point de vente, une famille de produit, etc. Selon l'invention, la phase de filtrage fournit un groupe, dit final, comprenant les identifiants des enregistrements vérifiant la ou les relations de filtrage. Dans une version particulière, la phase de filtrage peut comprendre, pour chaque relation de filtrage visant un critère de tri, une étape de filtrage, selon ladite relation de filtrage, des membres de la dimension du cube de tri associée audit critère de tri, indépendamment des autres relations de filtrage, chaque étape de filtrage fournissant un groupe, dit intermédiaire, comprenant un ou des identifiants d'un ou des enregistrements mémorisé(s) dans ladite dimension et vérifiant ladite relation de filtrage. Ainsi, l'application de chaque relation de filtrage sur le cube de tri, et plus particulièrement à la dimension associée au critère de tri visé par la relation de filtrage, retourne un groupe intermédiaire d'identifiants d'enregistrements dont les valeurs pour le critère de tri visé par la relation de filtrage vérifient la relation de filtrage. Avantageusement, pour au moins une relation de filtrage, et préférentiellement pour chaque relation de filtrage, le groupe intermédiaire fourni par ladite relation de filtrage, peut être obtenu en réalisant l'union de tous les identifiants d'enregistrements mémorisés par le ou les membres de ladite dimension satisfaisant ladite relation de filtrage. Une telle union permet d'éliminer les multiples occurrences d'un même enregistrement dans le groupe intermédiaire, dues au fait que cet - 9 - enregistrement est mémorisé par plusieurs membres de la dimension satisfaisant la relation de filtrage. Selon un exemple non limitatif, un critère de tri « PRIX » est associé à une dimension « PRIX » comprenant trois membres : « M1 :10E », « M2 :30E » et « M3 :60E ». Chaque membre de la dimension mémorise l'identifiant d'au moins un enregistrement dont le prix est égal au membre : M1={2,3}, M2={3,4} et M3={1,5}. Une relation de filtrage « RF1 :PRIX Dans ce cas, chaque membre de chaque dimension peut comprendre une table de hash dans laquelle sont mémorisées les identifiants mémorisés par ce membre. Autrement dit, chaque membre comprend une table de hash et un identifiant est mémorisé dans la case de cette table de hash correspondant à la valeur de hash calculée pour cet identifiant. Une telle table de hash d'un membre peut être générée au moment de la génération du membre, et peut être mise à jour à chaque mise à jour du membre. Dans le cas où une table de hash est utilisée pour réaliser l'union de deux membres d'une dimension, et plus généralement pour obtenir le groupe intermédiaire, le groupe intermédiaire peut également comprendre une table de hash, dans laquelle sont mémorisés tous les identifiants du groupe intermédiaire. Dans tous les cas, pour mémoriser un identifiant dans une table de hash, la valeur de hash de cet identifiant est calculée avec une fonction de - 10 - hash prédéterminée et commune à tous les membres de la dimension. Ensuite, la case de la table de hash est identifiée grâce à ladite valeur de hash. L'identifiant est ensuite mémorisé dans ladite case ainsi identifiée. Avantageusement, la fonction de hash utilisée pour chaque dimension peut être fonction du type des données mémorisées dans cette dimension, en particulier du type et/ou du nombre de membres de cette dimension. Autrement dit, la fonction de hash utilisée par chaque dimension peut être spécifique à cette dimension. Lorsque plusieurs relations de filtrage d'une requête de tri visent un même critère de tri, et par conséquent une même dimension du cube de tri, chacune de ces relations de filtrage : - est appliquée à la dimension concernée indépendamment de chacune des autres relations de filtrage, et fournit un groupe intermédiaire d'identifiants d'enregistrements indépendant de chacun des groupes intermédiaires d'identifiants d'enregistrements fourni par chacune des autres relations de filtrage. Selon un exemple non limitatif, lorsque deux relations de filtrage RF2 : COULEUR=bleu » et « RF3 : COULEUR=rouge » visent le critère de tri « CT2=COULEUR » alors chacune des relations de filtrage RT2 et RT3 est appliquée à la dimension « COULEUR » associée au critère de tri CT2 de manière indépendante et retourne un groupe intermédiaire, respectivement GI2 et GI3. Le groupe intermédiaire GI2 comprend tous les identifiants des enregistrements de couleur bleue, i.e. mémorisés par le membre « Bleu » de la dimension « COULEUR », et le groupe intermédiaire GI3 comprend tous les identifiants des enregistrements de couleur rouge, i.e. mémorisés par le membre « Rouge » de la dimension « COULEUR ». Lorsque la requête de tri comprend plusieurs relations de filtrage, ladite requête comprend également un ou plusieurs opérateurs booléens reliant lesdites relations de filtrage entre-elles. - 11 - La phase de filtrage peut alors comprendre une étape appliquant lesdits opérateurs booléens aux groupes intermédiaires d'identifiants d'enregistrements fournis par chacune des relations de filtrage, et fournissant le groupe final d'identifiants d'enregistrements vérifiant les relations de filtrage. Autrement dit, lorsque la requête de tri comprend deux relations de filtrage le résultat de la phase de filtrage du cube de tri est obtenu en appliquant la relation booléenne entre ces deux relations de filtrage aux groupes intermédiaires d'identifiants d'enregistrements retournés par chacune desdites deux relations de filtrage. Selon un exemple non limitatif, si la requête tri R comprend les relations de filtrage « (RF2 :COULEUR=Bleue) OU (RF3 :COULEUR=Rouge) » avec G12 le groupe intermédiaire fourni par la relation de filtrage RF2 et G13 le groupe intermédiaire fourni par la relation de filtrage RF3, alors, le groupe final GF fourni par l'application des deux relations de filtrage RF2 et RF3 est donné par « GF = G12 OU G13 », c'est-à-dire l'union des identifiants d'enregistrement présents dans G12 et dans G13. Par contre, si la requête tri comprend les relations de filtrage « (RF2 :COULEUR=Bleue) ET (RF3 :COULEUR=Rouge) », alors, le groupe final est donné par « GF = G12 ET G13 », c'est-à-dire l'intersection des identifiants d'enregistrement présents dans G12 et dans G13. Dans une version préférée de l'invention, le procédé selon l'invention peut comprendre, suite à une réception d'une requête de tri, une étape regroupant les relations de filtrage visant une même dimension, et donc un même critère de tri. La relation booléenne utilisée pour relier ces relations de filtrage visant une même dimension, et donc un même critère de tri, est alors un « OU ». La relation booléenne utilisée pour relier deux relations de filtrage, ou deux groupes de relations de filtrage, visant deux dimensions différentes, et donc deux critères de tri différents, est alors un « ET ». Avantageusement, le procédé selon l'invention peut comprendre une utilisation d'une table de hash pour appliquer un opérateur booléen à deux groupes intermédiaires, et plus généralement pour appliquer, les opérateurs - 12 - booléens reliant des relations de filtrage dans une requête de tri, aux groupes intermédiaires fournis par chacune de ces relations de filtrage . Dans ce cas, chaque groupe intermédiaire fourni par une relation de filtrage peut comprendre une table de hash dans laquelle sont mémorisés les identifiants faisant partie de ce groupe intermédiaire, tel que décrit plus haut. Le groupe final peut alors également comprendre une table de hash dans laquelle sont mémorisés les identifiants composant le résultat de l'application de la requête de tri. Dans une version préférée, la phase de classement peut comprendre une application indépendante et unitaire de chaque relation de sortie au groupe final d'identifiants fourni par l'étape de filtrage. Selon l'invention, au moins une relation de sortie vise un critère de tri et peut comprendre un opérateur de tri et une valeur de tri. Dans ce cas, et selon une version particulière, l'application d'une relation de sortie, et préférentiellement de chaque relation de sortie, peut comprendre les étapes suivantes : - filtrage de la dimension concernée par la relation de sortie, c'est-à-dire la dimension associée au critère de tri visé par la relation de sortie, ledit filtrage fournissant un groupe intermédiaire d'identifiants vérifiant la relation de sortie ; et - détermination de l'intersection dudit groupe intermédiaire ainsi obtenu avec le groupe final fournit par la phase de filtrage, ladite intersection fournissant les identifiants présents à la fois dans le groupe intermédiaire et dans le groupe final. L'étape de filtrage d'une dimension avec une relation de sortie peut avantageusement être réalisée d'une manière similaire, ou de la même manière que, l'étape de filtrage d'une dimension avec une relation de filtrage, telle que décrite plus haut, y compris l'utilisation d'une table de hash. L'étape de détermination de l'intersection peut être réalisée par utilisation de tables de hash telle que décrite plus haut dans le cadre d'une intersection, i.e. dans la cadre de l'application d'un opérateur booléen « ET ». - 13 - L'application d'une relation de sortie peut comprendre, après l'étape de détermination de l'intersection, une étape associant les identifiants fournis par l'intersection avec la relation de sortie. Lorsque la requête de tri comprend plusieurs relations de sortie, chaque relation de sortie est appliquée indépendamment au groupe final fourni par la phase de filtrage. La phase de classement peut alors comprendre une étape de concaténation des résultats fournis par chacune des relations de sortie, ladite phase de classement fournissant alors une liste obtenue par ladite étape de concaténation. Plus généralement, selon l'invention, lorsqu'un opérateur booléen est appliqué à deux ensembles d'identifiants : - chaque ensemble d'identifiants pouvant être : mémorisé par un membre d'une dimension, ou un groupe intermédiaire fourni par une relation de filtrage appliquée à une dimension, un groupe intermédiaire fourni par une relation de sortie appliquée à une dimension, ou le groupe final fourni par l'étape de filtrage, - chaque opérateur booléen pouvant être : ^ une union, par conséquent un « OU », ou ^ une intersection, par conséquent un « ET » ; au moins un, préférentiellement chacun, de ces ensembles peut comprendre une table de hash dans laquelle sont mémorisés les identifiants de cet ensemble et, l'opérateur booléen peut être appliqué à ces deux ensembles en utilisant la table de hash d'au moins l'un desdits deux ensembles. Dans ce cas, l'ensemble obtenu par l'application de l'opérateur booléen peut également comprendre une table de hash dans laquelle sont mémorisés les identifiants. Avantageusement, au moins une dimension du cube de tri, peut comprendre au moins une liste dans laquelle les membres de ladite dimension peuvent être ordonnés selon une fonction prédéterminée s'appliquant audits membres. - 14 - Selon un exemple non limitatif, les membres d'une dimension associée au critère de tri « PRIX », i.e. toutes les valeurs différentes de prix que prend le critère de tri « PRIX » dans la base de données source sur l'ensemble des enregistrements, peuvent être ordonnés selon une valeur de prix croissante ou une valeur de prix décroissante. Selon un autre exemple non limitatif, les membres d'une dimension associée au critère de tri « MARQUE », i.e. tous les noms différents de marque que prend le critère de tri « MARQUE » dans la base de données source sur l'ensemble des enregistrements, peuvent être ordonnées selon un ordre alphabétique. Autrement dit, les membres peuvent être classés dans la dimension « MARQUE » par ordre alphabétique. Ainsi, dans le cas de l'exemple non limitatif donné plus haut, les membres « BMW® », « AUDI® » et « PORSCHE® » de la dimension « MARQUE » seront ordonnés dans l'ordre alphabétique suivant : « AUDI® » ;« BMW® » ; « PORSCHE® ». Dans une version particulière, au moins une dimension, et préférentiellement chacune des dimensions, peut comprendre une liste dans laquelle les membres de ladite dimension sont ordonnées selon un ordre, dit ordre de filtrage, utilisant une fonction de comparaison considérant toutes les variantes d'une même valeur comme égales. Dans un exemple non limitatif, selon l'ordre de filtrage les valeurs 7 et 7.0 sont égales. Dans une version préférée de l'invention, au moins une dimension, et préférentiellement chacune des dimensions, peut comprendre une liste ordonnée dans laquelle les membres de ladite dimension sont ordonnées selon un ordre, dit ordre de sortie, utilisant une fonction de comparaison considérant toutes les variantes d'une même valeur comme différentes. Selon un exemple non limitatif, selon l'ordre de sortie les valeurs 7 et 7.0 sont différentes et la valeur 7.0 est supérieure à la valeur 7. Une liste ordonnée selon l'ordre de sortie est par conséquent forcément ordonnée selon l'ordre de filtrage. Autrement dit, deux enregistrements égaux selon l'ordre de filtrage sont forcément contigus selon l'ordre de sortie. - 15 - Selon l'invention, au moins une relation de filtrage et/ou une relation de sortie visant un critère de tri peut être composé d'un opérateur, dit de tri. Plus particulièrement, une relation de filtrage et/ou une relation de sortie visant un critère de tri peut être composée d'un opérateur de tri et au moins une valeur, dite de tri, pour ledit opérateur et/ou ledit critère de tri. Dans le cas où une dimension, associée à un critère de tri visé par une relation, de filtrage ou de sortie, comprend une liste ordonnée, en particulier selon l'ordre de sortie, le filtrage de cette dimension selon ladite relation peut avantageusement comprendre les étapes suivantes : - identification, dans ladite liste ordonnée, d'au moins un membre, dit membre de bord, de ladite dimension qui respecte ou qui ne respecte plus ladite relation, - sélection en fonction dudit au moins un membre de bord de chaque identifiant d'enregistrement mémorisé par chaque membre respectant ladite relation. L'identification d'au moins un membre de bord peut comprendre une identification de l'index de ce membre de bord, les autres membres respectant ladite relation étant déterminés en fonction dudit index. Pour une relation comprenant deux valeurs de tri, telle que par exemple une relation composée de l'opérateur « ENTRE A et B » avec A et B deux valeurs de tri, le filtrage de la dimension peut comprendre une identification de deux membres de bords dans la liste triée. Dans une version particulière, le filtrage de la dimension peut comprendre, avant l'identification d'un membre de bord, une identification d'un membre, dit de référence, respectant la relation dans la liste ordonnée et en particulier de son index dans la liste ordonnée. Dans ce cas, le ou les membres de bord sont identifiés en partant dudit membre de référence, en particulier de son index, en parcourant la liste triée dans un sens et/ou dans l'autre. Le membre de référence peut par exemple être le membre de la dimension correspondant à la valeur de tri renseignée dans la relation. Dans une version particulière, l'identification du membre de référence dans la liste ordonnée peut être préférentiellement réalisée par recherche binaire dans ladite liste ordonnée. - 16 - Préférentiellement, la phase de détermination du résultat de tri peut comprendre une étape de comptage du nombre d'identifiants d'enregistrements différents vérifiant la requête de tri, en particulier du nombre d'identifiants d'enregistrement différents vérifiant chaque relation de sortie. La phase de détermination du résultat de tri peut en outre comprendre une étape d'affichage dudit nombre d'identifiants d'enregistrement différents vérifiant la requête de tri, en particulier du nombre d'identifiants d'enregistrement différents vérifiant chaque relation de sortie en association avec chaque relation de sortie. Une telle étape de comptage et/ou une telle étape d'affichage peut comprendre un comptage/un affichage d'un nombre d'identifiants d'enregistrement différents présents dans le groupe final d'identifiants d'enregistrement fourni par la phase de filtrage. La fourniture d'un tel résultat de comptage et/ou l'affichage peuvent être réalisés de manière dynamique à chaque ajout ou suppression d'une relation de filtrage et/ou d'une relation de sortie, par exemple au travers d'une interface utilisateur. Ainsi, il est possible pour un utilisateur de visualiser si le résultat du tri qu'il est en cours de réaliser correspond ou non à des enregistrements proposés dans le catalogue et d'éviter de formuler des requêtes de tri ayant pour résultat zéro enregistrements. La phase de détermination du résultat de tri peut en outre comprendre une étape d'affichage d'au moins une donnée relative à au moins un enregistrement vérifiant la requête de tri, en particulier à au moins un enregistrement vérifiant une relation de sortie en association avec ladite relation de sortie. Une telle étape d'affichage peut comprendre un affichage d'au moins une donnée relative à au moins un enregistrement dont l'identifiant se trouve dans le groupe final d'identifiants d'enregistrement fourni par la phase de filtrage ou un identifiant retourné par l'application d'une relation de sortie. Avantageusement, l'étape d'affichage peut réaliser un affichage d'une liste comprenant au moins une partie, ou un nombre prédéterminé, - 17 - d'enregistrements dont les identifiants se trouvent dans le groupe final fourni par la phase de filtrage ou fourni par une relation de sortie. L'information affichée pour chaque enregistrement peut comprendre un résumé, ou une partie ou la totalité des caractéristiques dudit enregistrement, chargé(es) depuis la base de données source en utilisant l'identifiant de l'enregistrement. L'information ou la donnée affichée peut comprendre une ou plusieurs informations/données préalablement choisie(s). Un tel affichage peut être réalisé préférentiellement une fois que la requête de tri est entièrement formulée par l'utilisateur. Alternativement, un tel affichage peut être réalisé de manière dynamique à chaque ajout ou suppression d'une relation de filtrage et/ou d'une relation de sortie. Une relation de sortie fournissant un nombre d'enregistrement nul peut être ignorée lors de l'affichage, et plus particulièrement lors de la phase de détermination du résultat. Le procédé de tri selon l'invention peut en outre comprendre, suite à une modification dans ladite base de données source, une phase de mise à jour d'un cube de tri préalablement obtenu et concerné par ladite modification, ladite phase de mise à jour comprenant les étapes suivantes : - identification dudit ancien cube de tri préalablement obtenu, dit ancien cube de tri, par exemple par consultation d'un référentiel de cubes chargés, un tel référentiel listant pour tous les cubes chargés les dimensions du cube, - récupération d'une liste des dimensions dudit ancien cube de tri, - chargement d'un nouveau cube en fonction desdites dimensions et à partir de ladite base de données source modifiée, et - remplacement dudit ancien cube de tri par le nouveau cube. Avantageusement, pendant l'étape de remplacement, le procédé selon l'invention peut comprendre une interdiction de toute opération sur l'ancien cube de tri. - 18 - Lorsqu'une dimension est ajoutée à l'ancien cube de tri pendant la phase de mise à jour alors cette dimension peut être ignorée lors du chargement du nouveau cube. Cette dimension devra alors être à nouveau ajoutée, cette fois directement au nouveau cube. Lorsqu'une dimension de l'ancien cube de tri n'existe plus lors du chargement du nouveau cube, par exemple parce que la modification apportée à la base de données source comprend/provoque une suppression de cette dimension, cette dimension est ignorée lors du chargement du nouveau cube. Une telle mise à jour permet de limiter le temps pendant lequel un cube de tri n'est pas accessible et d'optimiser le temps de mise à jour d'un cube. Une telle mise à jour permet de réaliser des mises à jour de données de manière fréquente sans pour autant bloquer l'accès au cube de tri, i.e. sans pour autant bloquer le processus de tri, et tout en maintenant une grande disponibilité du cube de tri pour réaliser des tris. Une telle mise à jour permet en outre de réaliser des mises à jour de données sans pour autant mettre fin à une requête de tri en cours de traitement. Une requête de tri utilise toujours le cube de tri sur lequel elle a commencé à être appliquée. Le procédé de tri selon l'invention peut en outre comprendre, suite à une modification dans ladite base de données source, une phase de mise à jour d'une dimension d'un cube de tri préalablement obtenu et concerné par ladite modification, ladite phase mise à jour comprenant les étapes suivantes : - identification de ladite dimension, dite ancienne dimension, dudit cube de tri, par exemple par consultation d'un référentiel de cubes chargés, un tel référentiel listant pour tous les cubes de tri les dimensions du cube de tri, - chargement d'une nouvelle dimension en fonction de ladite base de données source modifiée, et remplacement de l'ancienne dimension par la nouvelle dimension dans ledit cube de tri. - 19 - Avantageusement, pendant l'étape de remplacement, le procédé selon l'invention peut comprendre une interdiction de toute opération sur la dimension concernée. Lorsque la dimension concernée n'existe plus dans la base de données source, cette dimension est supprimée du cube préalablement chargé. Une telle mise à jour permet de réaliser des mises à jour de données de manière fréquente sans pour autant bloquer l'accès au cube de tri, i.e. sans pour autant bloquer le processus de tri, et tout en maintenant une grande disponibilité du cube de tri pour réaliser des tris. Une telle mise à jour permet en outre de réaliser des mises à jour de données sans pour autant mettre fin à une requête de tri en cours de traitement. Par ailleurs, lors d'une telle mise à jour, toutes les autres dimensions du cube qui ne sont pas concernées par la mise à jour sont accessibles et peuvent être utilisées pour appliquer des relations de filtrage ou de sortie. De plus, une telle mise à jour permet de mettre à jour uniquement la dimension concernée, et évite de régénérer l'ensemble du cube de tri. Les ressources informatiques sont ainsi optimisées et le temps de mise à jour limité. Le procédé de tri selon l'invention peut en outre comprendre, suite à une modification dans ladite base de données source d'un enregistrement, une phase de mise à jour dudit enregistrement dans une dimension, ladite phase mise à jour comprenant les étapes suivantes : - obtention d'une dimension dite, nouvelle dimension, par copie de l'ancienne dimension ; - identification de tous les membres de ladite nouvelle dimension concernés par ladite mise à jour ; - pour chacun desdits membres identifiés de ladite nouvelle dimension : suppression de l'identifiant dudit enregistrement mémorisé par ledit membre, et si ledit identifiant était le seul identifiant mémorisé par ledit membre alors suppression dudit membre de ladite dimension, ou - 20 - mémorisation de l'identifiant dudit enregistrement par ledit membre, et si ledit membre n'existe pas, ajout dudit membre à la bonne position dans ladite dimension ; lorsqu'au moins un membre est supprimée/ajouté dans ladite nouvelle dimension, mise à jour de la position de tous les membres suivant ledit membre dans ladite nouvelle dimension, - remplacement de ladite ancienne dimension par la nouvelle dimension ainsi modifiée. L'étape d'identification de tous les membres de la nouvelle dimension concernés par la mise à jour d'un enregistrement peut être réalisée par identification de tous les membres mémorisant l'identifiant dudit enregistrement, et préférentiellement l'index de tous les membres dans la nouvelle dimension mémorisant l'identifiant dudit enregistrement. Avantageusement, chaque dimension peut comprendre une table de hash, dite dictionnaire, spécifique à cette dimension et comprenant pour chaque enregistrement dont l'identifiant est mémorisé par au moins un membre de cette dimension, une liste de tous les membres de cette dimension mémorisant l'identifiant de cet enregistrement. Avec une telle table de hash dictionnaire, l'étape d'identification de tous les membres concernés par la mise à jour d'un enregistrement peut comprendre les étapes suivantes : - calcul d'une valeur hash pour l'identifiant de l'enregistrement, - identification de la case de la table de hash dictionnaire correspondant à cette valeur de hash, - identification dans cette case, d'une liste de membres correspondant à cet identifiant, et mémorisant cet identifiant, Préférentiellement, la liste mémorisée pour un enregistrement dans la table de hash, peut comprendre l'index, dans la dimension, de chaque membre mémorisant l'identifiant de l'enregistrement. La table de hash peut être créée lors de la création de la dimension et alimentée à chaque ajout d'un membre dans une dimension d'un cube. - 21 - La table de hash peut être mise à jour à chaque mise à jour d'un membre de la dimension. De plus, lorsqu'un membre est ajouté ou est supprimé d'une dimension l'index de tous les membres suivant le membre ajouté/supprimé est également mis à jour. Suivant un exemple de réalisation préféré mais non limitatif du procédé selon l'invention, chaque membre d'une dimension peut comprendre un méta-membre, le méta-membre comprenant le membre et son index au sein de ladite dimension. Une telle architecture permet une réalisation simplifiée et rapide des opérations de mise à jour d'un enregistrement au sein d'une dimension. Lorsque la mise à jour d'un enregistrement dans la base de données concerne plusieurs dimensions d'un cube dans ce cas, le procédé selon l'invention peut comprendre, une étape de mise à jour comprenant les étapes suivantes : - identification de toutes les dimensions du cube à mettre à jour, - mise à jour de chacune desdites dimension par une phase de mise à jour d'une dimension telle que décrite plus. Dans une version avantageuse nullement limitative, le procédé selon l'invention peut comprendre une réalisation d'une seule mise à jour à la fois. Ainsi, il est possible de mieux contrôler les mises à jour à réaliser et ne pas consacrer toutes les ressources informatiques à réaliser des mises à jour. Pour ce faire, le procédé selon l'invention peut comprendre, pour chaque mise à jour à réaliser, une détermination d'une valeur associée à ladite mise à jour. Le procédé selon l'invention peut en outre comprendre une inscription de cette valeur dans une file d'attente de mises à jour. Dès qu'une mise à jour est traitée, la valeur associée à cette mise à jour et mémorisée dans la file d'attente, est effacée de la liste d'attente. Puis, la mise à jour correspondante à la valeur suivante dans la file d'attente est réalisée. - 22 - La file d'attente de mises à jour peut être une file FIFO (pour « First In First Out » en anglais). La valeur associée à une mise à jour peut correspondre à la requête de mise à jour construite selon un modèle donné. Par exemple la valeur d'une mise à jour peut être obtenue par concaténation d'une combinaison quelconque d'au moins deux des données suivantes dans un ordre prédéterminé : - un verbe décrivant la mise à jour, par exemple « Update » - au moins un mot décrivant le type d'élément à mettre à jour, par exemple « cube », ou « dimension », ou « enregistrement », etc. - la donnée d'identification de l'élément à mettre à jour, par exemple : ^ pour un cube : une donnée d'identification du cube, ^ pour une dimension d'un cube : une donnée d'identification du cube et le critère de tri correspondant à la dimension, ^ pour un enregistrement dans l'ensemble des dimensions d'un même cube : une donnée d'identification du cube et l'identifiant de l'enregistrement, et pour un enregistrement dans une dimension d'un cube : une donnée d'identification du cube, le critère de tri correspondant à la dimension et l'identifiant de l'enregistrement. Le procédé selon l'invention peut en outre comprendre, pour chaque mise à jour à réaliser, une vérification de l'unicité de ladite mise à jour. Pour cela, le procédé selon l'invention peut comprendre une inscription de toutes les valeurs associées à toutes les mises à jour à réaliser dans une table de hash, en plus de leur inscription dans la file d'attente de mises à jour. Cette table de hash peut être créée en même temps que la création de la file d'attente de mises à jour. La vérification de l'unicité d'une mise à jour peut alors être réalisée de la manière suivante : -23- - détermination d'une valeur associée à ladite mise à jour, - détermination d'une valeur de hash à partir de ladite valeur associée à ladite mise à jour et d'une fonction de hachage prédéterminée, et - vérification, en fonction de ladite valeur de hash, de l'existence ou non de ladite valeur associée à la mise à jour dans une table de hash mémorisant une valeur associée à au moins une mise à jour en attente de réalisation. Si la mise à jour correspond à une mise à jour déjà en attente alors, alors elle est ignorée. Sinon, la valeur associée à la mise à jour est ajoutée : - dans la file d'attente de mises à jour, et - dans la table de hash, à la case correspondant à la valeur de hash calculée. Lorsqu'une valeur associée à une mise à jour est effacée de la file d'attente de mises à jour, par exemple parce que la mise à jour correspondante est sur le point d'être réalisée, alors elle est également effacée de la table de hash. Selon un autre aspect de l'invention, il est proposé un système comprenant des moyens agencés pour réaliser toutes les étapes du procédé selon l'invention. D'autres avantages et caractéristiques de l'invention apparaîtront à l'examen de la description détaillée d'un mode de mise en oeuvre nullement limitatif, et des dessins annexés sur lesquels : - la FIGURE 1 est une représentation schématique d'un exemple de réalisation d'un système selon l'invention ; - la FIGURE 2 est une représentation schématique d'un exemple d'une dimension d'un cube de tri selon l'invention ; - la FIGURE 3 est une représentation schématique d'un exemple d'un procédé de tri selon l'invention ; - 24 - - la FIGURE 4 est une représentation schématique d'un exemple d'une phase d'obtention, à la volée, d'un cube de tri pouvant être mise en oeuvre dans le procédé selon l'invention ; - la FIGURE 5 est une représentation schématique d'un exemple d'une phase de filtrage ou d'une phase de classement pouvant être mise en oeuvre dans le procédé de tri selon l'invention ; - le FIGURE 6 est une représentation schématique d'un exemple de vérification de l'unicité d'une mise à jour pouvant être mise en oeuvre dans le procédé selon l'invention ; et - le FIGURE 7 est une représentation schématique d'un exemple de traitement d'une mise à jour pouvant être mis en oeuvre dans le procédé selon l'invention. Il est bien entendu que les modes/exemples de réalisation qui sont décrits dans la suite ne sont nullement limitatifs. On pourra notamment imaginer des variantes de l'invention ne comprenant qu'une sélection de caractéristiques décrites par la suite isolées des autres caractéristiques décrites, si cette sélection de caractéristiques est suffisante pour conférer un avantage technique ou pour différencier l'invention par rapport à l'état de la technique antérieur. Cette sélection comprend au moins une caractéristique de préférence fonctionnelle sans détails structurels, ou avec seulement une partie des détails structurels si cette partie uniquement est suffisante pour conférer un avantage technique ou pour différencier l'invention par rapport à l'état de la technique antérieur. En particulier toutes les variantes et tous les modes/exemples de réalisation décrits sont combinables entre eux si rien ne s'oppose à cette combinaison sur le plan technique. Sur les figures, les éléments communs à plusieurs figures conservent les mêmes références. La FIGURE 1 est une représentation schématique d'un système de tri selon l'invention. Le système de tri 100 selon l'invention représenté sur la FIGURE 1 permet de réaliser un traitement de données pour réaliser un tri au sein d'un - 25 - ensemble d'enregistrements mémorisés dans une base de données sources 102. Chaque enregistrement est une représentation numérique d'un produit ou d'un service et comprend au moins une valeur numérique représentant une caractéristique de ce produit ou de service selon un critère de tri, tel que le prix, la couleur, la taille, la disponibilité à la vente ou le stock dans un point de vente, etc. Chaque enregistrement est identifié par une donnée d'identification au sein de la base de donnes source 102 et peut être définie pour une fiche produit 104 par exemple. La base de données source 102 peut être mémorisée sur un ou plusieurs appareils disposés sur un même site ou plusieurs sites Le système 100 comprend un module 106, dit fournisseur de données, pour accéder la base de données source 102 et générer, à partir de la base de données, et à la volée, au moins un cube 108, dit de tri, comprenant au moins une dimension, chaque dimension étant associée à un pour un critère de tri. Le système 100 comprend en outre un référentiel de cubes 110 dans laquelle est/sont mémorisé(s) le ou les cubes de tri 108. Préférentiellement, le référentiel de cube 110 est mémorisé dans une mémoire RAM d'un appareil informatique. Le système 100 comprend en outre une interface utilisateur 112 permettant à un utilisateur de formuler un requête de tri 114 comprenant une ou plusieurs relations de de tri 116 portant chacune sur un critère de tri. Le système 100 comprend également un module 118, gestionnaire, pour recevoir et appliquer une requête tri 114 sur un cube de tri 108. Le système 100 comprend en outre une liste 120 d'attente de mises à jour mémorisant pour chaque mise à jour une donnée d'identification de la mise à jour et une table de hash 122 associée à la liste 120 d'attente de mises à jour, mémorisant chacun une donnée d'identification de chaque mise à jour à réaliser, et utilisés respectivement pour réaliser une seule mise à jour à la fois dans la base de données de cube 110 et pour s'assurer de l'unicité de chaque mise à jour à réaliser. Lorsqu'une mise à jour doit être réalisée, une donnée d'identification est déterminée pour cette mise à jour selon une règle prédéterminée, par - 26 - exemple par concaténation de données composant la requête de mise à jour. Cette donnée d'identification est ensuite testée pour déterminer si elle n'est pas déjà mémorisée dans la liste de mise à jour 120. Pour ce faire, la donnée d'identification est fournie en entrée d'une fonction de hachage associée à la table de hash 122 qui fournit une valeur de hash. Avec la valeur de hash ainsi déterminée, une case 124, de la table de hash 122 est identifiée. Ensuite, la donnée d'identification de la mise à jour est recherchée dans cette case 124,. Si cette donnée d'identification est déjà présente dans cette case 124,, alors cette mise à jour n'est pas considérée car elle est déjà dans la file d'attente de mise à jour. Sinon, elle est d'une part inscrite dans cette case 124, de la table de hash 122 et d'autre part mise dans la file d'attente 120 en dernière position. La file d'attente 120 peut être une file FIFO. Lorsqu'une mise à jour est sur le point d'être réalisée alors sa donnée d'identification est supprimée de la file d'attente 120 et de la table de hash 122. Le système 100 comprend en outre un module 126 de mise à jour réalisant la gestion des mises à jour en fonction d'une ou des requêtes de mise(s) à jour 128 reçue(s) par exemple depuis une interface 130 de mises à jour qui peut être une interface d'administration de la base de données source 102. La FIGURE 2 est une représentation schématique d'un exemple d'une dimension d'un cube de tri, par exemple une dimension du cube de tri 108 de la FIGURE 1. La dimension 200 représentée sur la FIGURE 2 comprend une liste 202 de méta-membres, notés 2041-204n. Chaque méta-membre 204 comprend un membre 206 et un index 208 30 de ce membre 206 dans la dimension 200. Chaque membre 206 de la dimension correspond à une valeur différente que peut prendre le critère de tri auquel est associée la dimension 200, sur l'ensemble des enregistrements présents dans la base de données source. - 27 - Par exemple, si le critère de tri est le « PRIX » et que pour ce critère de tri l'ensemble des enregistrements de la base de données présentent uniquement trois valeurs différentes qui sont 100E, 200E et 300E alors la dimension 200 associée à ce critère aura trois membres qui sont le membre 100E, le membre 200E et le membre 300E. Pour chaque membre 206, la dimension comprend un méta-membre 204 comprenant ce membre. Chaque membre 206 de la dimension 200 mémorise l'identifiant de chaque enregistrement de la base de données source qui présente, pour le critère de tri auquel est associée la dimension 200, une valeur égale à ce membre. Par exemple, le membre 100E mémorise l'identifiant de chaque enregistrement présentant pour le critère de tri « PRIX » une valeur de 100E, i.e. l'identifiant de chaque enregistrement dont le prix est de 100E. Pour chaque membre 206, l'identifiant d'un enregistrement est mémorisé dans une table de hash 210, et plus particulièrement dans une case 212, de la table de hash 210 correspondant à la valeur de hash calculée pour cet identifiant selon une fonction de hachage prédéterminée et commune à toutes les dimensions du cube de tri comprenant la dimension 200. Autrement dit, pour inscrire un identifiant d'un enregistrement dans un membre 206, tout d'abord une valeur de hash est calculée avec une fonction de hachage prédéterminée prenant en entrée l'identifiant de l'enregistrement. Une fois la valeur de hash calculée, la case 212, de la table de hash 210 dans laquelle l'identifiant doit être mémorisé. Une fois la case identifié, l'identifiant est inscrite dans cette case 212, de la table de hash 210. La dimension 200 comprend une liste ordonnée 214 des méta-membres, et donc des membres, de la dimension 200 selon un ordre, dit de sortie, utilisant une fonction de comparaison, appelée comparaison de sortie, réalisant une comparaison de valeurs, en particulier numériques, en considérant toutes les variantes d'une même valeur comme différentes. Par exemple, la comparaison de sortie considère que les valeurs 7 et 7.0 sont différentes. Cette liste ordonnée selon l'ordre de sortie est forcément ordonnées selon un ordre, dit de filtrage, utilisant une fonction de comparaison, appelée comparaison de filtrage, réalisant une comparaison de valeurs, en particulier numériques, en considérant toutes les variantes d'une - 28 - même valeur comme égales. Par exemple, la comparaison de filtrage considère que les valeurs 7 et 7.0 sont égales. La dimension 200 comprend en outre une table de hash 216, dit dictionnaire, commune à tous les membres 206 de la dimension 200, par 5 conséquent commune à tous les méta-membres 204 de la dimension 200. Cette table de hash dictionnaire 216 mémorise pour chaque enregistrement dont l'identifiant est enregistré par au moins l'un des membres 206 de la dimension 200, l'identifiant de l'enregistrement en association avec une liste des index, dans la liste triée 202, de tous les 10 membres 206 de la dimension, mémorisant l'identifiant de cet enregistrement. Pour ce faire, une valeur de hash est calculée pour chaque identifiant. Puis, en fonction de cette valeur de hash, une case 218, est identifiée dans la table de hash dictionnaire 216. Puis l'identifiant ainsi que la liste des index 15 associée à cet identifiant sont mémorisés dans cette case 218, de la table 216. La dimension 200 comprend en outre une fonction de conversion, associée à cette dimension, et permettant de convertir une chaine de caractère en membre et vice versa. 20 La FIGURE 3 est une représentation schématique d'un exemple de réalisation d'un procédé de tri selon l'invention. Le procédé 300 comprend une étape 302 de réception d'une requête 25 de tri, par exemple par le module gestionnaire 118 depuis une interface utilisateur 112. La requête de tri peut être reçue au travers d'un réseau de communication filaire ou non. La requête de tri comprend au moins une relation de filtrage, chaque relation de filtrage vise un critère de tri et comprend un opérateur de tri et 30 une valeur de tri. Lorsque la requête de tri comprend plusieurs relations de filtrage, elle comprend également au moins un opérateur booléen reliant ces relations de filtrage entre-elles. L'opérateur booléen peut par exemple être l'opérateur booléen « ET » correspondant à une intersection ou l'opérateur booléen « OU » correspondant à une union. - 29 - La requête de tri comprend également au moins une relation de sortie, chaque relation de sortie vise un critère de tri et comprend un opérateur de tri et une valeur de tri. Les relations de filtrage sont regroupées dans la requête de tri dans une première liste et les relations de sortie sont regroupées dans la requête de tri dans une deuxième liste. Puis, une phase 304 d'obtention d'un cube de tri est réalisée. La phase d'obtention 304 du cube de tri comprend une étape 306 réalisant une analyse de la requête de tri pour déterminer tous les critères de tri visés par la requête de tri, à savoir tous les critères de tri visés par les relations de filtrage et par les relations de sortie. La phase d'obtention du cube de tri 304 comprend ensuite, une étape 308, de génération d'un cube de tri, par exemple le cube de tri 108, comprenant une dimension pour chaque critère de tri visé dans ladite requête de tri et déterminé lors de l'étape 306. Chaque dimension du cube de tri ainsi obtenu est indépendante des autres dimensions du cube de tri et peut présenter une architecture identique ou similaire à celle de la dimension 200 de la FIGURE 2, à savoir que : - chaque dimension comprend un ou plusieurs membres, correspondant chacun à une valeur différente que peut prendre le critère de tri auquel est associée ladite dimension sur l'ensemble des enregistrements de la base de données source, et - chaque membre d'une dimension mémorise un identifiant d'au moins un enregistrement présentant pour ledit critère une valeur correspondant à ce membre. Une phase 310 de filtrage applique chaque relation de filtrage de la requête de tri, indépendamment des autres relations de filtrage, aux membres de la dimension du cube de tri concernée par la relation de filtrage. Chaque relation de filtrage retourne un groupe intermédiaire d'identifiants numériques, préférentiellement mémorisé dans une table de hash également. L'ensemble des groupes ainsi créés est ensuite utilisé pour fournir un groupe final d'identifiants numériques. - 30 - Une phase 312 de classement applique chaque relation de sortie de la requête de tri, indépendamment des autres relations de sortie, au groupe final fourni par la phase de filtrage 310 afin de classer les identifiants du groupe final. Cette phase 312 fournit une liste obtenue par concaténation des couples (relation de sortie/enregistrements) obtenue par application unitaire des relations de sortie de la requête de tri. Lors d'une phase 314, un résultat de filtrage est fourni en fonction du groupe final d'identifiants numériques fourni à par la phase de filtrage 310 et/ou de la liste fournie par la phase de classement 312. La phase de détermination du résultat peut comprendre une mesure comprenant un comptage, et éventuellement un affichage, du nombre total d'identifiants numériques présents dans le groupe final ou dans chaque couple (relation de sortie/enregistrements). La FIGURE 4 est une représentation schématique d'un exemple d'une phase d'obtention à la volée d'un cube de tri, pouvant être mise en oeuvre dans le cadre du procédé selon l'invention. L'exemple représenté sur la FIGURE 4 peut par exemple constituer la phase d'obtention 304 du procédé 300 de la FIGURE 3. La phase d'obtention 400 d'un cube de tri, représentée sur le FIGURE 4, comprend une étape 306 d'analyse de la requête et une étape 308 de génération du cube de tri telle que décrite plus haut. L'étape 308 de génération du cube de tri comprend les étapes 25 suivantes. Une étape 402 détermine si la requête de tri reçue comprend une donnée d'identification, dite clef, d'un cube existant à utiliser. Si à l'étape 402 une clef de cube est spécifiée dans la requête de tri, à l'étape 404, la clef du cube spécifiée dans la requête de tri est utilisée pour 30 déterminer le cube à utiliser, par exemple par consultation d'un référentiel des cubes de tri, tel que le référentiel de cubes 110 de la FIGURE 1. Si, à l'étape 404 aucun cube ne correspond à cette clef ou le cube correspondant à cette clef n'existe plus/pas, alors un nouveau cube de tri est créé et chargé en se basant sur les données de la base de données 35 source à l'étape 406, par exemple par l'intermédiaire du fournisseur de - 31 - données 106 de la FIGURE 1. Ce nouveau cube, créé puis chargé, est ensuite utilisé comme cube de tri. Si, à l'étape 404, un cube existant est identifié pour la clef spécifiée dans la requête de tri, par exemple dans le référentiel de cubes 110 de la FIGURE 1, alors une étape 408 teste le cube existant pour déterminer si le cube existant comprend toutes les dimensions visées par la requête de tri, par exemple par consultation des dimensions existantes et chargées dans le cube existant. Si toutes les dimensions visées par la requête de tri existent, i.e. aucune dimension visée dans la requête de tri n'est manquante dans le cube existant, le cube existant est adopté comme cube de tri à l'étape 410 et la requête de tri peut être appliquée au cube de tri. Si à l'étape 408, au moins une dimension visée par la requête de tri est manquante dans le cube identifié alors à l'étape 412 chaque dimension manquante est construite, puis chargée et enfin ajoutée au cube existant à partir des données de la base de données source, par exemple par le fournisseur de données 106 de la FIGURE 1. Le cube ainsi complété à l'étape 412 est adopté comme cube de tri lors de l'étape 414. Si à l'étape 402, aucune clef de cube n'est spécifiée dans la requête de tri, alors l'étape 416 détermine s'il existe un cube préalablement chargé, par exemple par consultation d'un référentiel de cubes, qui peut être le référentiel de cubes 110 de la FIGURE 1. Une telle consultation peut être réalisée par le module gestionnaire 118 de la FIGURE 1. Ainsi, on détermine si un cube existant et chargé comprend au moins une dimension visée par la requête. Si plusieurs cubes comprenant au moins une dimension visée par la requête existent et sont chargées, alors c'est le cube existant qui comprend le plus de dimensions visées par la requête qui est utilisé. Si à l'étape 416 au moins un cube existant est identifié, alors l'étape 408 est réalisée. Si à l'étape 416 aucun cube existant n'est identifié alors l'étape 406 préalablement décrite est réalisée et un nouveau cube de tri est généré entièrement. - 32 - II est important de noter que le nouveau cube généré à l'étape 406 ne comprend que les dimensions visées dans la requête de tri reçue. Il est également important de noter que la ou les dimensions ajoutée(s) à l'étape 412 correspondant chacune à une dimension visée dans la requête de tri et absente du cube existant. Chaque dimension générée, à l'étape 406 ou à l'étape 412, peut préférentiellement présenter l'architecture de la dimension 200 de la FIGURE 2. La FIGURE 5 est une représentation schématique d'un exemple d'une phase appliquant une ou des relations de filtrage, c'est-à-dire une phase de filtrage, ou d'une phase appliquant une ou des relations de sortie, c'est-à-dire une phase de classement, pouvant être mise en oeuvre dans le procédé selon l'invention. La phase 500 représentée sur la FIGURE 5 peut être la phase de filtrage 310 de la FIGURE 3, lorsque les relations appliquées sont des relations de filtrage. La phase 500 représentée sur la FIGURE 5 peut être la phase de classement 312 de la FIGURE 3, lorsque les relations appliquées sont des relations de sortie. Pour rappel, une requête de tri comprend une ou plusieurs relations de filtrage et une ou plusieurs relations de sortie. Lorsque la requête de tri comprend plusieurs relations de filtrage, elle comprend également un ou des opérateurs booléens reliant, chacun, deux relations de filtrage entre-elles. Les opérateurs booléens sont la plupart du temps un « ET » booléen correspondant à une intersection ou un « OU » booléen correspondant à une union. Chaque relation, de filtrage ou de sortie, vise un critère de tri et donc s'applique à une dimension associée audit critère de tri. Chaque relation comprend un opérateur de tri, et éventuellement au moins une valeur de tri. La phase 500 est réalisée une fois que le cube de tri est obtenu, c'est-à-dire un cube de tri comprenant une dimension pour chaque critère de tri. Chaque dimension du cube de tri à laquelle s'applique la requête de tri - 33 - présente préférentiellement l'architecture de la dimension 200 de la FIGURE 2. L'étape 500 comprend une étape 502 appliquant unitairement une relation à une dimension du cube de tri. Cette étape 502 est réalisée indépendamment pour chacune des relations se trouvant dans la requête de tri, même si deux relations, de filtrage ou de sortie, visent la même dimension. L'étape 502 appliquant une relation à une dimension peut comprendre une étape optionnelle 504 d'identification d'un membre de la dimension, dit membre de référence, correspondant à la valeur de tri spécifiée dans la relation. L'étape 504 d'identification, dans une liste ordonnée des membres, du membre de référence correspondant à la valeur de tri, c'est-à-dire du membre de référence. Préférentiellement, cette étape d'identification peut être réalisée par recherche binaire. L'index du membre de référence est mémorisé. Un tel index peut être l'index 208 de la FIGURE 2. Ensuite, lors d'une étape 506, au moins un membre, dit de bord, est identifié dans la liste ordonnée des membres de la dimension dans un sens et/ou dans l'autre sens. Une fois au moins un membre de bord identifié, tous les membres satisfaisant la relation sont identifiés lors de cette étape 506. L'étape 502 comprend, après l'étape 506, une étape 508, optionnelle, réalisant l'union des identifiants d'enregistrement mémorisés dans chacun des membres satisfaisant la relation, lorsque plusieurs membres d'une 25 même dimension satisfont la relation. Selon un exemple préféré non limitatif, une table de hash mémorisée dans chaque membre est utilisée, telle que par exemple la table de hash 210 de la FIGURE 2. Pour ce faire, une table de hash d'un membre choisi parmi les membres satisfaisant la relation est copiée, par exemple la table de hash du 30 membre de référence ou d'un membre de bord. Puis, pour chacun des autres membres vérifiant la relation, les opérations suivantes sont réalisées : - pour chaque identifiant du membre, calcule de la valeur de hash pour cet identifiant, - 34 - la table de hash obtenue par copie contient-elle un identifiant mémorisé dans la case associée à cette valeur de hash : - si non, inscription de cet identifiant dans cette case, - si oui, cet identifiant est déjà présent dans le groupe intermédiaire et ne sera pas mémorisé. La table de hash obtenue par copie et ainsi complétée comprend l'union des identifiants d'enregistrements mémorisés par l'ensemble des membres de la dimension respectant la relation. A l'étape 510 un groupe intermédiaire comprenant ou correspondant à cette table de hash est fourni pour la relation. Il est important de rappeler que, l'étape 502, comprenant les étapes 504-510, est réalisée pour chaque relation de la requête de tri et fournit, pour chaque relation, un groupe intermédiaire d'identifiants d'enregistrements mémorisés dans une table de hash. Lorsque la phase 500 est une phase de filtrage, par exemple la phase 310 de la FIGURE 3, l'étape 502 est suivie d'une étape 512 appliquant les opérateurs booléens reliant deux relations de filtrage aux groupes intermédiaires fournie par l'application de chaque relation de filtrage, c'est- à-dire par la réalisation d'une étape 502 pour chaque relation de filtrage. Lorsque l'opérateur booléen reliant deux ou plusieurs relations de filtrage est un « OU » booléen alors c'est l'union des groupes intermédiaires fournis pour ces relations de filtrage qui est déterminée. Pour ce faire, une table de hash d'un des groupes intermédiaire est choisie et l'algorithme décrit plus haut en référence à l'étape 508 est réalisée avec pour chacun des autres groupes intermédiaires. Lorsque l'opérateur booléen reliant deux ou plusieurs relations de filtrage est un « ET » booléen alors c'est l'intersection des groupes intermédiaires fournis pour ces relations de filtrage qui est déterminée. Pour ce faire, une table de hash d'un des groupes intermédiaire est choisie. Puis les opérations suivantes sont réalisées : - pour chaque identifiant de la table de hash choisie, calcule de la valeur de hash pour cet identifiant, - 35 - chacune des table de hash des autres groupes intermédiaires contient-elle un identifiant mémorisé dans la case associée à cette valeur de hash : - si non, suppression de cet identifiant de la table de hash choisie, et plus particulièrement de la case associée à sa valeur de hash, si oui, conserver cet identifiant, lequel existe déjà dans la table de hash choisie. L'étape 512 fournit ainsi un groupe final d'identifiants mémorisés dans une table de hash. Ces identifiants sont ceux des enregistrements vérifiant la requête de tri. Dans le cas où la phase 500 est une phase de classement, l'étape 502 est suivie des étapes suivantes : - une étape 514, réalisée pour chaque relation de sortie, et déterminant, pour chaque relation de sortie, l'intersection du groupe intermédiaire fourni par l'application unitaire de cette relation de sortie à une dimension, avec le groupe final préalablement fourni par la phase de filtrage : un couple (relation de sortie ; identifiants du groupe final vérifiant la relation de sortie) est alors obtenu, et - une étape 516, fournissant une liste de couples (relation de sortie ; enregistrements) obtenu par concaténation des couples (relation de sortie ; enregistrements) fournis par les relations de sortie de la requête de tri. L'intersection d'un groupe intermédiaire fourni par l'application d'une relation de sortie à une dimension avec le groupe final fourni par la phase de filtrage peut être réalisée de la même manière que l'application de l'opérateur booléen « ET » décrite ci-dessus. La FIGURE 6 est une représentation schématique d'un exemple d'une vérification de l'unicité d'une mise à jour, pouvant être mise en oeuvre dans le procédé selon l'invention. - 36 - Une telle vérification peut être réalisée après réception d'une requête de mise à jour, suite à une modification réalisée au niveau de la base de données source. La vérification 600 représentée en FIGURE 6 comprend une étape 602 de réception d'une requête de mise à jour. Ensuite une étape 604 de vérification de l'unicité de la mise à jour est réalisée. Cette étape 604 comprend une étape 606, calculant une donnée d'identification pour la mise à jour. Cette donnée est calculée en concaténant les éléments de la requête de mise à jour. Une valeur de hash est calculée pour cette donnée d'identification en utilisant une fonction de hachage, à l'étape 608. Une étape 610, consulte une table de hash, par exemple la table de hash 122 de la FIGURE 1, dans laquelle les données d'identification des mises à jour en attente de réalisation sont mémorisées. Les opérations suivantes sont réalisées : - identification d'une case de la table de hash correspondant à la valeur de hash calculée - comparaison de la donnée d'identification à chacune des données d'identification déjà mémorisées dans cette case : ^ si elle ne correspond à aucune donnée d'identification déjà mémorisée alors mémorisation de la donnée d'identification dans cette case de la table de hash et dans une file d'attente de mises à jour, par exemple la file d'attente de mises à jour 120 de la FIGURE 1 ; ^ si elle correspond à une donnée d'identification déjà mémorisée, alors la requête de mise à jour est ignorée. La FIGURE 7 est une représentation schématique d'un exemple de traitement d'une mise à jour pouvant être mise en oeuvre dans le procédé selon l'invention. L'exemple de traitement 700 représenté sur la FIGURE 7 comprend une étape 702 consultant une liste d'attente de mise à jour, par exemple la - 37 - liste d'attente 120 de la FIGURE 1, et sélectionnant la mise à jour à réaliser qui est en première position dans la liste d'attente. A l'étape 704, la mise à jour est analysée pour déterminer le type de mise à jour, à savoir une mise à jour d'un cube, d'une dimension d'un cube ou d'un enregistrement dans une dimension ou d'un enregistrement pour chaque dimension d'un cube. Si à l'étape 704, il est déterminé que la mise à jour à traiter est une mise à jour d'une dimension ou d'un cube alors, une étape 706 réalise une identification du cube ou de la dimension concernée, puis une copie de ce cube ou de cette dimension à mettre à jour. Lors d'une étape 708, la copie du cube ou de la dimension est mise à jour. Lors d'une étape 710 le cube ou la dimension à mettre à jour est remplacée par la copie mise à jour du cube, respectivement la dimension. Si à l'étape 704, il est déterminé que la mise à jour à traiter est une mise à jour d'un enregistrement dans une dimension, respectivement dans un cube, alors les étapes suivantes sont réalisées pour cette dimension, respectivement pour chaque dimension du cube. Une étape 712 réalise une copie de cette dimension. Lors d'une étape 713 la liste des nouveaux membres concernés par l'enregistrement mis à jour sont récupérés, par exemple par consultation du fournisseur de données 106 de la FIGURE 1. La liste des nouveaux membres correspond à la liste des membres qui mémorisent un identifiant de l'enregistrement après mise à jour de l'enregistrement. Puis, lors d'une étape 714, la liste des anciens membres contenant l'enregistrement sont identifiés, par consultation d'une table de hash, dit dictionnaire, telle que la table de hash dictionnaire 216 de la FIGURE 2, stockant pour chaque enregistrement une liste des index des membres de cette dimension mémorisant cet enregistrement. Pour ce faire les opérations suivantes sont réalisées : - calcul d'une valeur hash pour l'identifiant de l'enregistrement, - identification de la case de la table de hash dictionnaire correspondant à cette valeur de hash, et -38- - identification dans cette case, d'une liste de membres correspondant à cet identifiant, et mémorisant cet identifiant. En fonction de la liste des nouveaux membres et de la liste des anciens membres, les membres à mettre à jour sont déterminés et sont mis à jour lors d'une étape 716, en travaillant sur la copie, réalisée à l'étape 712, de la dimension concernée par la mise à jour. Les membres mis à jour sont les membres qui diffèrent entre les deux listes préalablement déterminées, à savoir : - les membres qui se trouvaient dans la liste des anciens membres, mais plus dans les nouveaux : dans ce cas l'identifiant de l'enregistrement est supprimé de chacun de ces membre. Si un membre existant dans la copie ne comprend plus aucun identifiant d'enregistrement alors ce membre est supprimé de la copie de la dimension ; et les membres qui ne se trouvaient pas dans la liste des anciens membres, mais qui figurent désormais dans la liste des nouveaux : dans ce cas l'identifiant de l'enregistrement est ajouté à chacun de ces membres. Si un nouveau membre manque dans la copie alors ce nouveau membre est ajouté à la copie de la dimension. A chaque mise à jour d'un enregistrement, la table de hash dictionnaire 216 est également mise à jour lors d'une étape 718. Si la dimension comprend une liste ordonnée des membres de la dimension, par exemple la liste 214 de la FIGURE 2 triée selon l'ordre de sortie, et qu'une mise à jour d'un membre provoque la création de ce membre ou la suppression de ce membre, alors la liste ordonnée est également mise à jour lors de l'étape 718. Puis lors d'une étape 720, la dimension à mettre à jour est remplacée par sa copie ainsi modifiée lors des étapes 716 et 718. Nous allons maintenant décrire quelques exemples non limitatifs de relation de filtrage et, pour chaque relation de filtrage un exemple d'application non limitative de ladite relation de filtrage sur une dimension du cube de tri.35 - 39 - Relation de filtrage « Egal » Cette relation de filtrage comprend un opérateur « Egal » et une valeur de tri au format texte, laquelle représente le ou les membres contenant les enregistrements à retourner. Cette valeur est convertie en utilisant une fonction de conversion associée à la dimension et permettant la conversion d'une chaine de caractère en membre. Ceci nous donne le membre de référence à rechercher. Si la valeur ne peut pas être convertie, le filtrage ne s'applique pas, et une valeur « Tous » est retournée. Sinon, les étapes suivantes sont réalisées : - recherche de l'index, également appelée position, de référence en effectuant une recherche binaire du membre de référence dans la liste ordonnée selon l'ordre de sortie ; o si la position de référence est négative, alors elle est remplacée par son complément binaire ; en commençant par la position de référence, dans l'ordre croissant, tester successivement chaque membre de la liste jusqu'à trouver le dernier membre respectant la condition d'égalité, selon l'ordre filtrage. - en commençant par la position de référence, dans l'ordre décroissant, tester successivement chaque membre jusqu'à trouver le dernier membre respectant la condition d'égalité, en utilisant l'ordre filtrage. Les deux membres ainsi trouvés sont les membres de bord. Les membres situés entre les deux membres de bord, eux compris, sont les membres satisfaisant la relation de filtrage, et contiennent les enregistrements à retourner : le groupe intermédiaire retourné correspond à l'union de tous ces enregistrements. Relation de filtrage « Supérieur » Cette relation de filtrage comprend un opérateur « Supérieur » et une valeur de tri au format texte, laquelle représente la borne inférieure de la liste des membres de la dimension. - 40 - Cette valeur est convertie en utilisant la fonction de conversion associée à la dimension et permettant la conversion d'une chaine de caractère en membre. Cette conversion donne le membre de référence. Si la valeur ne peut pas être convertie, le filtrage ne s'applique pas, et une valeur « Tous » est retournée. Sinon, les étapes suivantes sont réalisées : - recherche de la position de référence en effectuant une recherche binaire du membre de référence dans la liste ordonnée selon le l'ordre de sortie ; ^ si la position est positive, alors elle est incrémentée (position = position + 1). ^ si la position est négative, alors elle est remplacée par son complément binaire. - en commençant par la position de référence, dans l'ordre croissant, tester successivement chaque membre jusqu'à trouver le premier membre respectant la condition de supériorité, en application de l'ordre de filtrage : ce membre est le membre de bord. Ce membre de bord, ainsi que tous les membres suivants, sont les 20 membres satisfaisant la relation de filtrage et contiennent les enregistrements à retourner : le groupe intermédiaire retourné correspond à l'union de tous ces enregistrements. Relation de filtrage « Inférieur » 25 Cette relation de filtrage comprend un opérateur « Inférieur » et une valeur de tri au format texte, laquelle représente la borne supérieure de la liste des membres de la dimension. Cette valeur est convertie en utilisant la fonction de conversion de la dimension permettant la conversion d'une chaine de caractère en membre. 30 Cette conversion donne le membre de référence. Si la valeur ne peut pas être convertie, le filtrage ne s'applique pas, et une valeur « Tous » est retournée. Sinon les étapes suivantes sont appliquées : -41- - recherche de la position de référence en effectuant une recherche binaire du membre de référence dans la liste ordonnée selon l'ordre de sortie ; - si la position est positive, alors elle est décrémentée (position = position - 1). - si la position est négative, alors elle est remplacée par son complément binaire moins 1 (position = -position - 1). en commençant par la position de référence, dans l'ordre décroissant, tester successivement chaque membre jusqu'à trouver le premier membre respectant la condition d'infériorité, en application de l'ordre de filtrage. Ce membre est le membre de bord. Ce membre de bord ainsi que tous les membres précédents satisfont la relation de filtrage et contiennent les enregistrements à retourner : le groupe intermédiaire retourné correspond à l'union de tous ces enregistrements. Relation de filtrage « Supérieur ou égal » Cette relation de filtrage comprend un opérateur « Supérieur ou égal » et une valeur de tri au format texte, laquelle représente la borne inférieure de la liste des membres de la dimension. Cette valeur est convertie en utilisant la fonction de conversion de la dimension relisant une conversion de la chaine de caractère en membre. Cette conversion donne le membre de référence. Si la valeur ne peut pas être convertie, le filtrage ne s'applique pas, et une valeur « Tous » est retournée. Sinon, les étapes suivantes sont réalisées : - recherche de la position de référence en effectuant une recherche binaire du membre de référence dans la liste ordonnée selon l'ordre de sortie : ^ si la position est négative, alors elle est remplacée par son complément binaire ; - en commençant par la position de référence, dans l'ordre décroissant, tester successivement chaque membre jusqu'à trouver le dernier membre respectant la condition de supériorité ou d'égalité, en application de l'ordre de filtrage ; - 42 - Ce membre est le membre de bord. Ce membre ainsi que tous les membres suivants satisfont la condition de tri et contiennent les enregistrements à retourner : le groupe intermédiaire retourné correspond à l'union de tous ces enregistrements. Relation de filtrage « Inférieur ou égal » Cette relation de filtrage comprend un opérateur « Inférieur ou égal » et une valeur de tri au format texte, laquelle représente la borne supérieure de la liste des membres de la dimension. Cette valeur est convertie en utilisant la fonction de conversion d'une chaine de caractère en membre, associée à la dimension. Cette conversion donne le membre de référence. Si la valeur ne peut pas être convertie, le filtrage ne s'applique pas, et une valeur « Tous » est retournée. Sinon, les étapes suivantes sont réalisées : - recherche de la position de référence en effectuant une recherche binaire du membre de référence dans la liste ordonnée selon l'ordre de sortie : ^ si la position est négative, alors elle est remplacée par son complément binaire moins 1 (position = -position - 1) ; - en commençant par la position de référence, dans l'ordre croissant, tester successivement chaque membre jusqu'à trouver le premier membre respectant la condition d'infériorité ou d'égalité, en application de l'ordre de filtrage. Ce membre est le membre de bord. Ce membre de bord ainsi que tous les membres précédents satisfont la relation de filtrage et contiennent les enregistrements à retourner : le groupe intermédiaire retourné correspond à l'union de tous ces enregistrements. Relation de filtrage « Entre » Cette relation de filtrage est une combinaison des relations de filtrage « Supérieur ou égal » et « Inférieur ». Cette relation de filtrage comprend deux valeurs de tri au format texte, lesquelles représentent respectivement la borne inférieure et la borne supérieure à appliquer. - 43 - Le fonctionnement est ensuite identique aux deux relations de filtrage précitées. Ces relations de filtrage sont décrites plus haut. Nous allons maintenant décrire quelques exemples non limitatifs de relation de sortie et, pour chaque relation de sortie un exemple d'application non limitative sur une dimension. Relation de sortie « Egal » Cette relation de sortie comprend l'opérateur « Egal » et nécessite une valeur au format texte, laquelle représente le ou les membres contenant les enregistrements à retourner. Cette valeur est convertie en utilisant la fonction de conversion d'une chaine de caractère en membre associé à la dimension. Ceci donne le 15 membre de référence. Si la valeur ne peut pas être convertie, la relation de sortie est ignorée (rien n'est retourné). Les étapes suivantes sont réalisées : - recherche de la position de référence en effectuant une 20 recherche binaire du membre de référence dans la liste ordonnée selon l'ordre de sortie ; ^ si la position est négative, alors elle est remplacée par son complément binaire, - en commençant par la position de référence, dans l'ordre 25 croissant, tester successivement chaque membre de la liste jusqu'à trouver le dernier membre respectant la condition d'égalité, en application de l'ordre de filtrage. - en commençant par la position de référence, dans l'ordre décroissant, tester successivement chaque membre jusqu'à 30 trouver le dernier membre respectant la condition d'égalité, en application de l'ordre de filtrage. Les deux membres ainsi trouvés sont les membres de bords. Ces membres de bord ainsi que les membres situés entre eux, contiennent les enregistrements à retourner et composant le groupe intermédiaire pour 35 cette relation de sortie. - 44 - Pour obtenir l'ensemble des couples relation de sortie/enregistrements à retourner, il faut appliquer les transformations suivantes à chacun des membres trouvés précédemment : - convertir le membre en texte en utilisant la fonction de conversion, associée à la dimension, permettant la conversion d'un membre en chaine de caractère, - réaliser l'intersection des enregistrements du membre avec les enregistrements issus de l'application des relations de filtrage, - créer une relation de sortie composée du critère de tri de la dimension, de l'opération « Egal », et d'une valeur de tri correspondant au membre au format texte, - créer un couple contenant la relation de sortie et les enregistrements fournis par l'intersection. Le résultat de l'application de cette relation de sortie est la liste des couples relation de sortie/enregistrements ainsi créés. Relation de sortie « Supérieur » La relation de sortie comprend l'opérateur « Supérieur » et nécessite une valeur au format texte, laquelle représente la borne inférieure de la liste 20 ordonnée des membres de la dimension. Cette valeur est convertie en utilisant la fonction de conversion d'une chaine de caractère en membre, associée à la dimension. Ceci donne le membre de référence. Si la valeur ne peut pas être convertie, la relation de sortie est 25 ignorée (rien n'est retourné). Les étapes suivantes sont appliquées : - recherche de la position de référence en effectuant une recherche binaire du membre de référence dans la liste ordonnée selon l'ordre de sortie, 30 - si la position est positive, alors elle est incrémentée (position = position + 1). - si la position est négative, alors elle est remplacée par son complément binaire. - en commençant par la position de référence, dans l'ordre 35 croissant, tester successivement chaque membre jusqu'à trouver - 45 - le premier membre respectant la condition de supériorité, en application de l'ordre de filtrage. Ce membre est le membre de bord. Ce membre ainsi que tous les membres suivants, contiennent les informations à retourner. Pour obtenir l'ensemble des couples relation de sortie/enregistrements à retourner, il faut effectuer les opérations suivantes : - calculer l'union des enregistrements contenus dans les membres précédemment trouvés, - réaliser l'intersection de l'union précédemment calculé et des enregistrements issus de l'application des relations de filtrage, - créer un couple contenant la relation de sortie et les enregistrements fournis par l'intersection. Le résultat de l'application de cette relation de sortie est l'unique couple relation de sortie/enregistrements ainsi créé. Relation de sortie « Tous » Cette relation de sortie comprend l'opérateur « Tous » et ne nécessite aucune valeur. Elle signifie que tous les membres de la dimension visée constituent une relation de sortie, i.e. tous les membres de la dimension vérifient la relation de sortie. Pour obtenir l'ensemble des couples relation de sortie/enregistrements à retourner, il faut appliquer les transformations suivantes à chacun de tous les membres de la dimension visée : - convertir le membre en texte en utilisant la fonction de conversion, associée à la dimension, permettant la conversion d'un membre en chaine de caractère, - réaliser l'intersection des enregistrements du membre avec les enregistrements issus de l'application des relations de filtrage. - créer une relation de sortie composée du critère de tri de la dimension, de l'opération « Egal », et d'une valeur de tri correspondant au membre au format texte, - créer un couple contenant la relation de sortie et les enregistrements fournis par l'intersection. Le résultat de l'application de cette relation de sortie est la liste des couples relation de sortie/enregistrements ainsi créés. -46- Bien sûr, l'invention n'est pas limitée aux exemples qui viennent d'être décrits et de nombreux aménagements peuvent être apportés à ces exemples sans sortir du cadre de l'invention. REVENDICATIONS1. Procédé (300) de traitement de données pour effectuer un tri au sein d'un ensemble (104) d'entités numériques, dits enregistrements, chacun desdits enregistrements étant représenté par au moins une donnée numérique, dite valeur, associée à au moins un critère, dit de tri, et mémorisée dans une base de données (102), dite source, en association avec au moins une donnée d'identification dudit enregistrement, ledit procédé (300) comprenant : - une étape (302) de réception d'une requête, dite de tri, comprenant au moins une relation de filtrage visant un critère de tri, et - une phase (304, 400) d'obtention, à la volée et à partir de ladite base de données source (102), d'une base de données (108), dite cube de tri, comprenant une dimension (200) associée à chaque critère de tri visé dans ladite requête de tri, chaque dimension (200) : ^ étant indépendante des autres dimensions (200) dudit cube (108), et ^ comprenant, un ou plusieurs membres (204,206), correspondant chacun à une valeur que peut prendre le critère de tri auquel est associée ladite dimension (200) et mémorisant un identifiant d'au moins un enregistrement présentant ladite valeur pour ledit critère de tri, - une phase (310,500) de filtrage dudit cube de tri (108) avec l'au moins une relation de filtrage composant ladite requête de tri ; et - une phase (314) de détermination d'un résultat de tri, en fonction dudit filtrage. 2. Procédé (300) selon la revendication 1, caractérisé en ce que :-48- - la phase de filtrage (310,500) fournit au moins un identifiant d'au moins un enregistrement qui vérifie l'au moins une relation de filtrage, et - la requête de tri comprend en outre au moins une relation, dite de sortie, visant un critère de tri ; et en ce que ledit procédé comprend en outre, après la phase de filtrage, une phase (312,500), dite de classement, dudit au moins un enregistrement en fonction de ladite au moins une relation de sortie. 3. Procédé (300) selon l'une quelconque des revendications précédentes, caractérisé en ce que la phase (304,400) d'obtention du cube de tri (108) comprend les étapes suivantes : - détermination (306) de tous les critères de tri visés dans la requête de tri, - consultation (408) d'un cube existant pour déterminer si ledit cube existant comprend, pour chacun des critères de tri visés dans la requête de tri, une dimension associée audit critère de tri : - si oui, utilisation (410) dudit cube existant comme cube de tri, - sinon, complétion (412) dudit cube existant avec chacune des dimensions manquantes à partir de la base de données source (102) et utilisation dudit cube existant ainsi complété comme cube de tri. 4. Procédé (300) selon la revendication 3, caractérisé en ce que la requête de tri comprend une donnée d'identification dudit cube existant dans une base de cubes (110) comprenant au moins un cube (108). 5. Procédé (300) selon l'une quelconque des revendications précédentes, caractérisé en ce que la phase de filtrage (310,500) comprend, pour chaque relation de filtrage visant un critère de tri, une étape (502) de filtrage, selon ladite relation de filtrage, des membres de la dimension (200) du cube de tri (108) associée audit critère de tri, indépendamment-49- des autres relations de filtrage, ladite étape de filtrage (502) fournissant un groupe, dit intermédiaire, comprenant les identifiants de tous les enregistrements mémorisés dans ladite dimension (200) et vérifiant ladite relation de filtrage. 6. Procédé (300) selon la revendication 5, caractérisé en ce que, lorsque la requête de tri comprend plusieurs relations de filtrage, ladite requête comprend également un ou plusieurs opérateurs booléens reliant lesdites relations de filtrage entre elles, la phase de filtrage (310,500) comprenant en outre une étape (512) appliquant lesdits opérateurs booléens aux groupes intermédiaires d'identifiants fournis par chacune des relations de filtrage, et fournissant un groupe, dit final, d'identifiants d'enregistrements. 7. Procédé (300) selon les revendications 2 et 6, caractérisé en ce que la 15 phase de classement (312,500) comprend, pour au moins une, et préférentiellement pour chaque, relation de sortie, les étapes suivantes : - filtrage (502), selon ladite relation de sortie, des membres de la dimension (200) visée par la relation de sortie, ledit filtrage fournissant un groupe intermédiaire d'identifiants 20 d'enregistrements vérifiant ladite relation de sortie ; et - détermination (514) de l'intersection dudit groupe intermédiaire ainsi obtenu avec le groupe final fourni par la phase (310,500) de filtrage dudit cube de tri (108) selon l'au moins une relation de filtrage. 25 8. Procédé (300) selon la revendication 7, caractérisé en ce que, lorsque la requête de tri comprend plusieurs relations de sortie, la phase de classement (312,500) comprend une application unitaire et indépendante de chacune desdites relations de sortie, ladite phase de classement 30 (312,500) comprenant en outre une étape (516) de concaténation des résultats fournis par chacune des relations de sortie, ladite phase de classement (312,500) fournissant une liste obtenue par ladite concaténation.- 50 - 9. Procédé (300) selon l'une quelconque des revendications précédentes, caractérisé en ce que la phase (314) de détermination du résultat de tri comprend une étape de comptage du nombre d'enregistrements différents vérifiant la requête de tri. 10. Procédé (300) selon l'une quelconque des revendications précédentes, caractérisé en ce que la phase (314) de détermination du résultat de tri comprend en outre une étape d'affichage d'au moins une donne relative à au moins un enregistrement vérifiant la requête de tri. 11. Procédé (300) selon l'une quelconque des revendications précédentes, caractérisé en ce qu'au moins une dimension (200) du cube de tri (108) comprend au moins une liste ordonnée (214) dans laquelle les membres (204,206) de ladite dimension (200) sont ordonnés selon une relation prédéterminée s'appliquant audits membres (204,206). 12. Procédé (300) selon la revendication 11, caractérisé en ce que, au moins une relation de filtrage, respectivement au moins une relation de sortie, visant un critère de tri est composée d'un opérateur, dit de tri, et d'au moins une valeur, dite de tri, pour ledit critère de tri, et en ce que le filtrage d'une dimension (200) selon la dite relation de filtrage, respectivement ladite relation de sortie, comprend les étapes suivantes : - identification (506), dans ladite liste ordonnée (214), d'au moins un membre, dit membre de bord, de ladite dimension (200) qui respecte ou qui ne respecte plus ladite relation, et - sélection (506-510) en fonction dudit au moins un membre de bord de chaque identifiant d'enregistrement mémorisé par chaque membre respectant ladite relation. 13. Procédé (300) selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend, suite à une modification dans ladite base de données source (102), une phase (700) de mise à jour d'un cube de tri (108) préalablement obtenu et concerné par ladite modification, ladite phase (700) de mise à jour d'un cube de tri (108) comprenant les étapes suivantes :- 51 - - identification (706) dudit cube de tri préalablement obtenu, dit ancien cube de tri, - récupération d'une liste des dimensions dudit ancien cube de tri, - chargement d'un nouveau cube en fonction desdites dimensions et à partir de ladite base de données source modifiée, et - remplacement (710) dudit ancien cube de tri par ledit nouveau cube. 10 14. Procédé (300) selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend, suite à une modification dans ladite base de données source (102), une phase (700) de mise à jour d'une dimension (200) d'un cube de tri (108) préalablement obtenu et concerné par ladite 15 modification, ladite phase de mise à jour (700) d'une dimension (200) comprenant les étapes suivantes : - identification (706) de ladite dimension (200), dite ancienne dimension, dudit cube de tri (108), - chargement d'une nouvelle dimension en fonction de ladite 20 base de données source modifiée, et - remplacement (710) de l'ancienne dimension par la nouvelle dimension dans ledit cube de tri. 15. Procédé (300) selon l'une quelconque des revendications précédentes, 25 caractérisé en ce qu'il comprend, suite à une modification dans ladite base de données source (102) d'un enregistrement, une phase (700) de mise à jour dudit enregistrement dans une dimension (200) comprenant les étapes suivantes : - obtention (712) d'une dimension dite, nouvelle dimension, par 30 copie de l'ancienne dimension ; - identification (713,714,716) de tous les membres de ladite nouvelle dimension concernés par ladite mise à jour ; - pour chacun desdits membres identifiés de ladite nouvelle dimension :- 52 - ^ suppression de l'identifiant dudit enregistrement mémorisé par ledit membre, ou ^ mémorisation de l'identifiant dudit enregistrement par ledit membre ; - lorsqu'au moins un membre est supprimé/ajouté dans ladite nouvelle dimension, mise à jour (718) de la position de tous les membres suivant ledit membre dans ladite nouvelle dimension, - remplacement (720) de ladite ancienne dimension par la nouvelle dimension ainsi modifiée. 10 16. Procédé (300) selon l'une quelconque des revendications 13 à 15, caractérisé en ce qu'il comprend, pour chaque mise à jour, une vérification (604) de l'unicité de ladite mise à jour, ladite vérification (604) comprenant les étapes suivantes : 15 - détermination (606) d'une valeur associée à ladite mise à jour, - détermination (608) d'une valeur de hash à partir de ladite valeur associée à ladite mise à jour, et - vérification (610), en fonction de ladite valeur de hash, de l'existence ou non de ladite valeur associée à la mise à jour dans 20 une table de hash (122) mémorisant une valeur associée à au moins une mise à jour en attente de réalisation. 17. Système (100) comprenant les moyens agencés pour réaliser toutes les étapes du procédé (300) selon l'une quelconque des revendications 25 précédentes.