FR3001067A1 - METHOD AND SYSTEM FOR PROCESSING DATA FOR SORTING WITHIN A SET OF DIGITAL ENTITIES - Google Patents

Abstract

The invention relates to a data processing method for sorting within a set (104) of digital entities, called records, each of said records being represented by at least one numerical data, called value, associated with at least a criterion, called sorting, and stored in a database (102), said source, in association with at least one identification data of said record, said method comprising: a step of receiving a request, said sorting, comprising at least one filtering relation relating to a sorting criterion, and - a phase of obtaining, on the fly and from said source database (102), a database (108), so-called sorting cube, comprising a dimension associated with each sorting criterion referred to in said sorting request, each dimension: ▪ being independent of the other dimensions of said cube (108), and ▪ comprising one or more members, each corresponding to a value which can be taken by the sorting criterion associated with said dimension and storing an identifier of at least one record having said value for said sorting criterion, - a filtering phase of said sorting cube (108) with the at least one filtering relation composing said sorting request; and a phase of determining a sorting result, as a function of said filtering. It also relates to a system implementing such a method.

Description

The present invention relates to a method for processing digital data to perform a sorting within a set of entities. digital, and more particularly digital entities representing each of the characteristics of a physical product or service. The invention relates more particularly to a method of sorting information relating to products or services each represented by a digital entity comprising a digital representation of the characteristics of the product or service. More particularly, the invention relates to a digital data processing for sorting in an electronic catalog of products and / or services, or more particularly to navigate in such a catalog, according to sorting criteria relating to product information. present in the catalog and each represented by a digital entity stored in one or more databases.

State of the art Currently, many websites offer tools for sorting information of products offered for sale in electronic catalogs, with the objective of providing a product or products corresponding to criteria entered by the user. These tools make it easier and more user-friendly to navigate through a catalog of thousands of products and reach a group of products that interests and is likely to buy. Sorting tools allow users to sort products from the same family according to several sorting criteria, such as price, brand, color, etc. For each of the sorting criteria proposed, several sorting values are available, such as, for example, price bands when the sorting criterion is the price. A known sorting method comprises, prior to any sorting request from a user, a preliminary pre-sorting step, generating from one or more product databases, called databases. source, a multidimensional database, called cube, in which all products are sorted according to all sort criteria, each sort criterion corresponding to a dimension of the cube. Then, upon receiving a sort request, the method accesses the cube to the dimensions concerned and the result of sorting is provided. This method has several drawbacks including the need to require significant computing power during the generation of the multidimensional cube. In addition, to take into account a modification of a piece of data in the source database, the multidimensional cube must be regenerated with each modification, which makes it difficult, if not impossible, in such a sorting process, to take account frequently changing data, such as for example a quantity available for sale for a particular product and possibly in a particular point of sale. Finally, this method makes it possible to carry out a sorting with predetermined sorting values for the sorting criteria. Other known sorting methods do not include a preliminary pre-sorting step. These methods access the source database each time a sort request is received and test all the sorting criteria of the sort request on each of the products. These sorting methods have several drawbacks, including the need to require large computer resources and a long response time, these drawbacks worsening with site traffic and the complexity of sorting requests.

An object of the invention is to overcome the aforementioned drawbacks. Another object of the invention is to provide a method and a data processing system performing sorting within a set of digital entities more flexible than known methods and systems. Another object of the invention is to propose a method and a data processing system performing a sorting within a set of digital entities, allowing the taking into account of changing data while requiring fewer computer resources than the current processes. Another object of the invention is to propose a method and a data processing system performing a sorting within a set of digital entities, allowing the taking into account of changing data while proposing a time of response shorter than current processes.

SUMMARY OF THE INVENTION The invention proposes to achieve at least one of these objects by a data processing method for sorting within a set of digital entities, called recordings, each of said records being represented by less a numerical data, called value, associated with at least one criterion, called sorting, and stored in a database, said source, in association with at least one identification data of said record, said method comprising: a step of receiving a request, said sorting, comprising at least one filtering relation targeting a sorting criterion, and - a phase of obtaining, on the fly and from said source database, a database of data, said sorting cube, comprising a dimension associated with each sorting criterion referred to in said sorting request, each dimension: ^ being independent of the other dimensions of said cube, and ^ comprising, one or more members, cor each responding to a value that can be taken by the sorting criterion associated with said dimension and storing an identifier of at least one record having said value for said sorting criterion; a filtering phase of said sorting cube with the at least one filtering relation composing said sorting request; a phase of determining a sorting result, as a function of said filtering. Thus, the method according to the invention makes it possible to obtain, on the fly and following the reception of a sorting request, from a source database, a multidimensional cube comprising a dimension for each of the criteria of said sort request received. According to the method according to the invention, a dimension of the cube associated with a sorting criterion is constructed / generated / obtained only on receipt of a first sorting request concerning this sorting criterion. In other words, in the case where a sorting criterion is not concerned by any sorting request received, no dimension associated with this sorting criterion will be present in the multidimensional cube.

The method according to the invention thus makes it possible to avoid the construction of a multidimensional cube comprising a dimension for each sorting criterion of all the sorting criteria available, before receiving any sorting request. Thus, the sorting method according to the invention requires a lower computation power for the generation of the multidimensional cube compared to the methods of the state of the art performing a pre-sorting. In addition, the multidimensional cube generated in the method according to the invention is smaller than that generated in the methods of the state of the art rereading a pre-sorting. Therefore, when changing data in the source database, the regeneration of the multidimensional cube can be performed frequently without requiring computing power as large as that required by the methods of the state of the art realizing a pre-sorting. In the method according to the invention, a dimension associated with a sorting criterion is constructed only following a request concerning this sorting criterion. It is therefore possible with the sorting method according to the invention to perform a more flexible and customizable sorting, with sorting values chosen by the user, compared to the methods of the state of the art performing a pre-sorting with predetermined sorting values imposed on the user.

In addition, when data relating to a sorting criterion is modified before the generation of the dimension associated with this sorting criterion, such a modification does not require the regeneration of the sort cube. In addition, the method according to the invention does not test all the criteria for sorting a sort query on all the entities of the source database but only on those present in the dimensions of the sorting cube. Therefore, the method according to the invention makes it possible to perform sorting in a shorter response time, while using fewer computer resources, compared to the sorting methods of the state of the art not performing pre-sorting. According to the invention, the "identifier" of a record stored by a member of a dimension may be the identification data of said record stored in the source database, or a datum, different from said identification data calculated from said identification data with a predetermined function. Advantageously, the sorting request may furthermore comprise a so-called output relationship used to classify the records obtained after the filtering phase, and in particular the records whose identifiers are stored in a final group of identifiers provided by the phase. filtering. In this case, the method according to the invention may further comprise, after the filtering phase, a classification phase of the records verifying the filtering relations, in particular the records whose identifiers are stored in the final group provided by the phase. filtering. In a similar way, even identical to a filtering relation, each output relation aims at a sorting criterion, i.e. a dimension of the cube. An output relationship may have the same architecture as a filtering relationship. In this case, the difference between said relationships can be concretized by formalism for example. Alternatively, the sort request may comprise two separate lists: a first list including the filtering relations and a second list including the output relationships.

Preferentially, each dimension of the cube may comprise as many members as there are different values in the source database, on the set of records, for the criterion to which said dimension is associated.

For example, and without limitation, for the sorting criterion "COLOR" each different color, present in the source database on all records, constitutes a member. For example, if for the "COLOR" sorting criterion, all the records present in the source database have the value "RED", "GREEN" or "BLUE" then the dimension - 6 - associated with the criterion COLOR sorting consists of three members, namely "RED", "GREEN" and BLUE ". According to another non-limiting example, for the sorting criterion "MARK", each different mark, present in the source database on all the records, constitutes a member. For example, if for the "BRAND" sorting criterion, all records in the source database are marked as "BMW®" or "AUDI®" or "PORSCHE®", then the dimension associated with sorting criterion "BRAND" has three members, namely "BMW®", "AUDI®" and "PORSCHE®". In a particularly preferred version of the method according to the invention, the phase of obtaining the sorting cube may comprise the following steps: determining all the sorting criteria referred to in the sorting request, namely the sorting criteria referred to in the filtering relations and the output relations of the sorting request, - consulting an existing cube to determine whether said existing cube comprises, for each of the sorting criteria referred to in the sorting request, a dimension associated with said sorting criterion if so, use of said existing cube as a sort cube, otherwise, completion of said existing cube with each of the missing dimensions from the source database and use of said existing cube thus completed as a sort cube. Thus, when after receiving the sorting request, an existing cube includes for each sorting criterion referred to in the sorting request a dimension associated with said sorting criterion, the existing cube is used as a sort cube. Such use of an existing cube avoids any generation of a dimension or any consultation of the source database and thus reduces the computing resources and the response time to obtain the sort cube. In addition, when after receiving the sort request, an existing cube includes dimensions associated with only some of the sorting criteria referred to in the sorting request, this existing cube may be completed with the associated dimension (s). to each of the missing sort criteria to get the sort cube. Such use of an existing cube limits the number of dimensions to be generated and therefore, the consultation of the source database, the computing resources and the response time for obtaining the sorting cube. When several existing cubes each include one or more dimensions associated with one or more sorting criteria referred to by the sorting request, it is the existing cube that lacks the least number of dimensions, which is completed. to get the sort cube. Each of the existing cubes may be a sort cube previously generated or obtained for one or more sort requests previously processed (s). When, following the reception of a sorting request, no sorting cube exists, then the obtaining phase may comprise a step of creating a sorting cube comprising one or more dimensions, each dimension of the cube thus created being then powered by access to the source database.

The method according to the invention may preferentially comprise a storage, more particularly in RAM, of a sorting cube used for a given sorting request, with a view to its future use for a future sorting request, or such that it is either having been previously completed by adding at least one dimension, as described above. Thus, the computing resources and the response time to obtain the sorting cube, and consequently to perform the sorting, are reduced compared to the methods of the state of the art. The method according to the invention may further comprise a step of removing a sort cube, or a dimension of a sort cube, previously generated and loaded into memory, if this ( this last) is not used for a predetermined duration, which may be adjustable. In a version of the method according to the invention where an existing cube is reused as a sort cube, either as it is, or after being completed by adding at least one missing dimension, the sorting request received may include identification data of such an existing cube. Such a cube can be stored in a base of cubes comprising at least one cube.

For more responsiveness and a lower response time, such an existing cube or such a cube base may preferentially be stored in living storage means, direct access storage means or volatile storage means. . Thus, it is possible to create and manipulate several cubes, each cube concerning a point of sale, a product family, etc. According to the invention, the filtering phase provides a group, termed final, comprising the identifiers of the records verifying the filtering relation (s).

In a particular version, the filtering phase may comprise, for each filtering relationship targeting a sorting criterion, a filtering step, according to said filtering relation, of the members of the dimension of the sort cube associated with said sorting criterion, independently other filtering relationships, each filtering step providing a group, said intermediate, comprising one or more identifiers of one or more records stored in said dimension and checking said filtering relation. Thus, the application of each filtering relation on the sorting cube, and more particularly to the dimension associated with the sorting criterion targeted by the filtering relation, returns an intermediate group of record identifiers whose values for the criterion sorting referred to by the filtering relation verify the filtering relation. Advantageously, for at least one filtering relationship, and preferably for each filtering relationship, the intermediate group provided by said filtering relation can be obtained by performing the union of all the record identifiers stored by the one or more members of the filtering relationship. said dimension satisfying said filtering relation. Such a union makes it possible to eliminate the multiple occurrences of the same record in the intermediate group, due to the fact that this record is memorized by several members of the dimension satisfying the filtering relation. According to a nonlimiting example, a sorting criterion "PRICE" is associated with a dimension "PRICE" comprising three members: "M1: 10E", "M2: 30E" and "M3: 60E". Each member of the dimension stores the identifier of at least one record whose price is equal to the member: M1 = {2,3}, M2 = {3,4} and M3 = {1,5}. A filtering relationship "RF1: PRICE <50E" is applied to the "PRICE" dimension independently. The members of the dimension D1 verifying the relation of filtering are M1 and M2 and the intermediate group provided by the filtering relation, denoted GI1, is obtained by realizing the union of the identifiers memorized by the members M1 and M2, namely GI1 = {2,3,4}. Thus, the union makes it possible to eliminate an occurrence of the record 3 which appears both in the member M1 and in the member M2. Advantageously, the method according to the invention may comprise a use of a hash table to achieve the union of at least two members.

In this case, each member of each dimension can comprise a hash table in which are memorized the identifiers memorized by this member. In other words, each member includes a hash table and an identifier is stored in the box of this hash table corresponding to the hash value calculated for this identifier.

Such a member's hash table can be generated at the time of the member's generation, and can be updated each time the member is updated. In the case where a hash table is used to achieve the union of two members of a dimension, and more generally to obtain the intermediate group, the intermediate group may also comprise a hash table, in which are stored all the identifiers intermediate group. In all cases, to memorize an identifier in a hash table, the hash value of this identifier is calculated with a predetermined hash function that is common to all members of the dimension. Then, the box of the hash table is identified by said hash value. The identifier is then stored in said box thus identified.

Advantageously, the hash function used for each dimension may be a function of the type of data stored in this dimension, in particular of the type and / or the number of members of this dimension. In other words, the hash function used by each dimension can be specific to that dimension.

When several filtering relations of a sorting request are aimed at the same sorting criterion, and consequently the same dimension of the sort cube, each of these filtering relations: - is applied to the dimension concerned independently of each of the other relations of filtering, and provides an intermediate group of record identifiers independent of each of the record identifier intermediate groups provided by each of the other filtering relationships.

According to a nonlimiting example, when two filtering relations RF2: COLOR = blue "and" RF3: COLOR = red "refer to the sorting criterion" CT2 = COLOR "then each of the RT2 and RT3 filtering relations is applied to the dimension" COLOR "associated with the sort criterion CT2 independently and returns an intermediate group, respectively GI2 and GI3. The intermediate group GI2 includes all the identifiers of the blue color records, ie stored by the member "Blue" of the dimension "COLOR", and the intermediate group GI3 includes all the identifiers of the red color records, ie stored by the member " Red "of the" COLOR "dimension. When the sorting request comprises several filtering relations, said request also comprises one or more Boolean operators linking said filtering relations to one another. The filtering phase may then comprise a step applying said Boolean operators to the intermediate groups of record identifiers provided by each of the filtering relationships, and providing the final group of record identifiers verifying the filtering relationships. In other words, when the sorting request includes two filtering relations the result of the filtering phase of the sorting cube is obtained by applying the Boolean relation between these two filtering relations to the intermediate groups of record identifiers returned by each of said filtering relations. two filtering relationships. According to a nonlimiting example, if the sorting request R comprises the filtering relations "(RF2: COLOR = Blue) OR (RF3: COLOR = Red)" with G12 the intermediate group provided by the filtering relation RF2 and G13 the intermediate group provided by the filtering relation RF3, then, the final group GF provided by the application of the two filtering relations RF2 and RF3 is given by "GF = G12 OR G13", that is to say the union of the identifiers in G12 and G13. On the other hand, if the sorting query includes the filtering relations "(RF2: COLOR = Blue) AND (RF3: COLOR = Red)", then the final group is given by "GF = G12 AND G13", that is, ie the intersection of the registration identifiers present in G12 and in G13. In a preferred version of the invention, the method according to the invention may comprise, following a reception of a sorting request, a step grouping the filtering relations targeting the same dimension, and therefore the same sorting criterion. The Boolean relation used to link these filtering relations targeting the same dimension, and therefore the same sorting criterion, is then an "OR". The Boolean relation used to link two filtering relations, or two groups of filtering relations, aimed at two different dimensions, and therefore two different sorting criteria, is then an "AND". Advantageously, the method according to the invention can comprise a use of a hash table to apply a Boolean operator to two intermediate groups, and more generally to apply, the Boolean operators linking filtering relations in a sorting request. , to the intermediate groups provided by each of these filtering relationships. In this case, each intermediate group provided by a filtering relation may comprise a hash table in which are stored the identifiers belonging to this intermediate group, as described above. The final group can then also include a hash table in which are stored the identifiers composing the result of the application of the sorting request.

In a preferred version, the ranking phase may comprise an independent and unitary application of each output relationship to the final group of identifiers provided by the filtering step. According to the invention, at least one output relationship is for a sorting criterion and may include a sort operator and a sort value. In this case, and according to a particular version, the application of an output relationship, and preferably of each output relation, can comprise the following steps: filtering the dimension concerned by the output relationship, that is, that is, the dimension associated with the sorting criterion targeted by the output relationship, said filtering providing an intermediate group of identifiers checking the output relationship; and - determining the intersection of said intermediate group thus obtained with the final group provided by the filtering phase, said intersection providing the identifiers present both in the intermediate group and in the final group. The step of filtering a dimension with an output relationship may advantageously be performed in a similar manner, or in the same manner as, the step of filtering a dimension with a filtering relation, as described above. top, including the use of a hash table. The step of determining the intersection can be performed using hash tables as described above in the context of an intersection, i.e. in the context of the application of a Boolean operator "AND". The application of an output relationship may include, after the step of determining the intersection, a step associating the identifiers provided by the intersection with the output relationship. When the sort request includes several output relationships, each output relationship is applied independently to the final group provided by the filtering phase. The classification phase can then include a step of concatenating the results provided by each of the output relationships, said classification phase then providing a list obtained by said concatenation step.

More generally, according to the invention, when a Boolean operator is applied to two sets of identifiers: each set of identifiers can be: stored by a member of a dimension, or an intermediate group provided by a filtering relation applied to a dimension, an intermediate group provided by an output relation applied to a dimension, or the final group provided by the filtering step, - each Boolean operator being: a union, hence an "OR", or ^ an intersection, hence an "AND"; at least one, preferably each, of these sets may comprise a hash table in which the identifiers of this set are stored and, the boolean operator can be applied to these two sets using the hash table of at least one one of said two sets. In this case, the set obtained by the application of the Boolean operator may also comprise a hash table in which the identifiers are stored.

Advantageously, at least one dimension of the sorting cube may comprise at least one list in which members of said dimension may be ordered according to a predetermined function applying to member audits. - 14 - According to a nonlimiting example, the members of a dimension associated with the sorting criterion "PRICE", ie all the different values of price that the sorting criterion "PRICE" takes in the source database on the set records, can be ordered according to a rising price value or a decreasing price value. According to another nonlimiting example, the members of a dimension associated with the sorting criterion "MARK", ie all the different brand names that the sorting criterion "MARK" takes in the source database on all the records , can be ordered in alphabetical order. In other words, members can be classified in the "BRAND" dimension in alphabetical order. Thus, in the case of the non-limiting example given above, the "BMW®", "AUDI®" and "PORSCHE®" members of the "BRAND" dimension will be ordered in the following alphabetical order: "AUDI®" "BMW®"; "PORSCHE®". In a particular version, at least one dimension, and preferably each of the dimensions, may comprise a list in which the members of said dimension are ordered according to an order, said filtering order, using a comparison function considering all the variants of a same value as equal. In a non-limiting example, according to the filtering order, the values 7 and 7.0 are equal.

In a preferred version of the invention, at least one dimension, and preferably each dimension, may comprise an ordered list in which the members of said dimension are ordered according to an order, called an output order, using a comparison function considering all variants of the same value as different.

According to a nonlimiting example, according to the output order, the values 7 and 7.0 are different and the value 7.0 is greater than the value 7. An ordered list according to the output order is therefore necessarily ordered according to the filtering order . In other words, two equal records according to the filtering order are necessarily contiguous according to the output order. According to the invention, at least one filtering relation and / or an output relation relating to a sorting criterion can be composed of an operator, called sorting operator. More particularly, a filtering relation and / or an output relationship targeting a sorting criterion can be composed of a sorting operator and at least one sorting value for said operator and / or said sorting criterion. In the case where a dimension, associated with a sorting criterion targeted by a relation, of filtering or of output, comprises an ordered list, in particular according to the output order, the filtering of this dimension according to said relation can advantageously comprise the following steps: identification, in said ordered list, of at least one member, said edge member, of said dimension which respects or no longer respects said relationship, selection based on said at least one edge member of each identifier registered by each member respecting said relationship. The identification of at least one edge member may comprise an identification of the index of this edge member, the other members respecting said relationship being determined according to said index.

For a relation comprising two sorting values, such as for example a relation composed of the operator "BETWEEN A and B" with A and B two sorting values, the filtering of the dimension may comprise an identification of two edge members in the sorted list. In a particular version, the filtering of the dimension may comprise, before the identification of an edge member, an identification of a reference member, respecting the relation in the ordered list and in particular of its index in the ordered list. In this case, the edge member (s) are identified starting from said reference member, in particular his index, by browsing the sorted list in one direction and / or in the other. The reference member may for example be the member of the dimension corresponding to the sorting value entered in the relation. In a particular version, the identification of the reference member in the ordered list may preferably be performed by binary search in said ordered list. Preferably, the phase of determining the sorting result may comprise a step of counting the number of different record identifiers verifying the sorting request, in particular the number of different record identifiers checking each output relationship. . The phase of determining the sorting result may further comprise a step of displaying the number of different registration identifiers verifying the sorting request, in particular the number of different registration identifiers checking each output relationship in association with each output relationship. Such a counting step and / or such a display step may include counting / displaying a number of different record identifiers present in the final group of record identifiers provided by the filtering phase.

The supply of such a counting result and / or the display can be performed dynamically each time a filter relationship and / or an output relationship is added or deleted, for example through an interface user. Thus, it is possible for a user to visualize whether or not the result of the sorting that is being performed corresponds to the records proposed in the catalog and to avoid formulating sorting queries resulting in zero records. The phase of determining the sorting result may further comprise a step of displaying at least one datum relating to at least one record verifying the sorting request, in particular to at least one record checking an output relationship in association with said output relationship. Such a display step may comprise a display of at least one datum relating to at least one record whose identifier is in the final group of registration identifiers provided by the filtering phase or an identifier returned by the application of an exit relationship. Advantageously, the display step can perform a display of a list comprising at least a part, or a predetermined number, of records whose identifiers are in the final group provided by the filtering phase or provided by an exit relationship. The information displayed for each record may include a summary, or some or all of the features of said record, loaded from the source database using the record's identifier. The information or data displayed may include one or more information / data previously selected (s). Such a display can be realized preferentially once the sorting request is entirely formulated by the user. Alternatively, such a display can be dynamically performed whenever adding or deleting a filter relationship and / or an output relationship.

An output relationship providing a zero record number may be ignored during display, and more particularly during the result determination phase. The sorting method according to the invention may further comprise, following a modification in said source database, a phase of updating a sorting cube previously obtained and concerned by said modification, said update phase. comprising the following steps: identification of said former sorting cube previously obtained, said old sorting cube, for example by consulting a repository of loaded cubes, such a referential listing for all the cubes loaded the dimensions of the cube, - recovery of a list of dimensions of said old sort cube, - loading a new cube according to said dimensions and from said modified source database, and - replacing said old sorting cube with the new cube. Advantageously, during the replacement step, the method according to the invention may include a prohibition of any operation on the old sorting cube. - 18 - When a dimension is added to the old sort cube during the update phase then this dimension can be ignored when loading the new cube. This dimension will have to be added again, this time directly to the new cube.

When a dimension of the old sort cube no longer exists when the new cube is loaded, for example because the change to the source database includes / causes a deletion of that dimension, that dimension is ignored when loading the new cube.

Such an update makes it possible to limit the time during which a sort cube is not accessible and to optimize the update time of a cube. Such an update makes it possible to carry out data updates frequently without blocking access to the sorting cube, ie without blocking the sorting process, and while maintaining a high availability of the sorting cube. to perform sorting. Such an update also makes it possible to carry out data updates without terminating a sorting request during processing. A sort query always uses the sort cube on which it began to be applied. The sorting method according to the invention may further comprise, following a modification in said source database, a phase of updating a dimension of a sort cube previously obtained and concerned by said modification, said phase update comprising the following steps: identification of said dimension, said old dimension, of said sorting cube, for example by consulting a repository of loaded cubes, such a referential listing for all the sorting cubes the dimensions of the cube of sorting, - loading a new dimension according to said modified source database, and replacing the old dimension with the new dimension in said sorting cube. Advantageously, during the replacement step, the method according to the invention may include a prohibition of any operation on the dimension concerned. When the dimension no longer exists in the source database, this dimension is removed from the previously loaded cube. Such an update makes it possible to carry out data updates frequently without blocking access to the sorting cube, ie without blocking the sorting process, and while maintaining a high availability of the sorting cube. to perform sorting.

Such an update also makes it possible to carry out data updates without terminating a sorting request during processing. In addition, during such an update, all other dimensions of the cube that are not affected by the update are accessible and can be used to apply filtering or output relationships. In addition, such an update makes it possible to update only the dimension concerned, and avoids regenerating the entire sort cube. IT resources are optimized and the update time is limited.

The sorting method according to the invention may further comprise, following a modification in said source database of a record, a phase of updating said record in one dimension, said updated phase comprising the following steps: - obtaining a so-called dimension, new dimension, by copy of the old dimension; - identification of all the members of the said new dimension concerned by the said update; for each of said identified members of said new dimension: deletion of the identifier of said record stored by said member, and if said identifier was the only identifier stored by said member then deletion of said member of said dimension, or storage of identifying said record by said member, and if said member does not exist, adding said member to the correct position in said dimension; when at least one member is deleted / added in said new dimension, updating the position of all the members following said member in said new dimension, - replacing said old dimension with the new dimension thus modified.

The step of identifying all the members of the new dimension concerned by the updating of a recording can be carried out by identifying all the members memorizing the identifier of said record, and preferably the index of all the members in the record. the new dimension storing the identifier of said record. Advantageously, each dimension can comprise a hash table, called dictionary, specific to this dimension and comprising for each record whose identifier is stored by at least one member of this dimension, a list of all the members of this dimension storing the identifier of this record. With such a dictionary hash table, the step of identifying all the members concerned by the update of a record may comprise the following steps: calculation of a hash value for the identifier of the record, identification of the box of the hash dictionary corresponding to this value of hash, identification in this box, of a list of members corresponding to this identifier, and storing this identifier, preferably, the list stored for a record in the hash table, can include the index, in the dimension, of each member storing the identifier of the record. The hash table can be created when creating the dimension and populated each time a member is added to a dimension of a cube. - 21 - The hash table can be updated whenever a member of the dimension is updated. In addition, when a member is added or removed from a dimension, the index of all members following the added / deleted member is also updated. According to a preferred but non-limiting embodiment of the method according to the invention, each member of a dimension may comprise a meta-member, the meta-member comprising the member and its index within said dimension. Such an architecture allows a simplified and rapid realization of the update operations of a record within a dimension. When the update of a record in the database concerns several dimensions of a cube in this case, the method according to the invention may comprise an update step comprising the following steps: - identification of all the dimension of the cube to be updated, - updating each of said dimension by an update phase of a dimension as described more. In an advantageous version that is in no way limitative, the method according to the invention may comprise a realization of a single update at a time. Thus, it is possible to better control the updates to be made and not to devote all the computer resources to make updates. To do this, the method according to the invention may comprise, for each update to be performed, a determination of a value associated with said update.

The method according to the invention may further comprise an inscription of this value in a queue of updates. As soon as an update is processed, the value associated with this update and stored in the queue is deleted from the waiting list. Then the corresponding update to the next value in the queue is performed. - 22 - The update queue can be a FIFO (for "First In First Out"). The value associated with an update may correspond to the update request constructed according to a given model. For example, the value of an update can be obtained by concatenating any combination of at least two of the following data in a predetermined order: - a verb describing the update, for example "Update" - at least a word describing the type of element to be updated, for example "cube", or "dimension", or "registration", etc. - the identification data of the element to be updated, for example: ^ for a cube: a cube identification data, ^ for a dimension of a cube: a cube identification data and the criterion of sort corresponding to the dimension, ^ for a record in the set of dimensions of the same cube: a data of identification of the cube and the identifier of the recording, and for a recording in a dimension of a cube : a cube identification data, the sorting criterion corresponding to the dimension and the identifier of the recording.

The method according to the invention may further comprise, for each update to be performed, a verification of the uniqueness of said update. For this, the method according to the invention may include an inscription of all the values associated with all the updates to be made in a hash table, in addition to their registration in the queue of updates. This hash table can be created at the same time as the creation of the update queue. The verification of the uniqueness of an update can then be performed in the following way: -23- - determination of a value associated with said update, - determination of a value of hash from said value associated with said update and a predetermined hash function, and - checking, according to said hash value, whether or not said value associated with the update is in a hash table storing a value associated with at least one pending update. If the update corresponds to an update already pending then, then it is ignored. Otherwise, the value associated with the update is added: - in the update queue, and - in the hash table, to the box corresponding to the calculated hash value.

When a value associated with an update is deleted from the update queue, for example because the corresponding update is about to be made, then it is also cleared from the update table. hash.

According to another aspect of the invention, there is provided a system comprising means arranged to perform all the steps of the method according to the invention.

Other advantages and characteristics of the invention will appear on examining the detailed description of an embodiment which is in no way limitative, and the appended drawings in which: FIG. 1 is a schematic representation of an example of embodiment of a system according to the invention; FIG. 2 is a schematic representation of an example of a dimension of a sorting cube according to the invention; FIG. 3 is a schematic representation of an example of a sorting method according to the invention; FIG. 4 is a diagrammatic representation of an example of a phase for obtaining, on the fly, a sorting cube that can be used in the method according to the invention; FIG. 5 is a diagrammatic representation of an example of a filtering phase or of a classification phase that can be implemented in the sorting method according to the invention; FIG. 6 is a schematic representation of an exemplary verification of the uniqueness of an update that can be implemented in the method according to the invention; and FIG. 7 is a schematic representation of an example of an update processing that can be implemented in the method according to the invention. It is understood that the modes / embodiments which are described below are in no way limiting. It will be possible, in particular, to imagine variants of the invention comprising only a selection of characteristics described subsequently isolated from the other characteristics described, if this selection of characteristics is sufficient to confer a technical advantage or to differentiate the invention with respect to the state of the art. This selection comprises at least one feature preferably functional without structural details, or with only a part of the structural details if this part alone is sufficient to confer a technical advantage or to differentiate the invention from the state of the prior art.

In particular all the variants and all the modes / examples of embodiment described are combinable with each other if nothing stands in the way of this combination on a technical level. In the figures, the elements common to several figures retain the same references.

FIGURE 1 is a schematic representation of a sorting system according to the invention. The sorting system 100 according to the invention shown in FIG. 1 makes it possible to perform a data processing to perform sorting within a set of records stored in a source database 102. Each record is a digital representation of a product or service and includes at least one numerical value representing a characteristic of that product or service according to a sorting criterion, such as price, color, size, availability for sale, or stock at a point of sale, etc. Each record is identified by identification data within the source database 102 and may be defined for a product record 104 for example. The source database 102 may be stored on one or more devices arranged on the same site or several sites. The system 100 comprises a module 106, called a data provider, for accessing the source database 102 and generating, from the database, and on the fly, at least one sorting cube 108, comprising at least one dimension, each dimension being associated with one for a sorting criterion. The system 100 further comprises a repository of cubes 110 in which is / are stored (s) the sort cubes 108. Preferably, the cube repository 110 is stored in a RAM memory of a computer device. The system 100 further comprises a user interface 112 enabling a user to formulate a sorting request 114 comprising one or more sorting relations 116 each relating to a sorting criterion.

The system 100 also includes a module 118, manager, for receiving and applying a sort request 114 on a sort cube 108. The system 100 further comprises a list of waiting lists of updates storing for each update a data item. identification of the update and a hash table 122 associated with the list of waiting updates 120, each storing an identification data of each update to be performed, and used respectively to make a single bet update both in the 110 cube database and to ensure the uniqueness of each update to be made. When an update has to be performed, an identification data is determined for this update according to a predetermined rule, for example by concatenation of data constituting the update request. This identification data is then tested to determine if it is not already stored in the update list 120. To do this, the identification data is provided at the input of a hash function associated with the table. hash 122 that provides a hash value. With the hash value thus determined, a box 124 of the hash table 122 is identified. Then, the identification data of the update is searched in this box 124,. If this identification data is already present in this box 124 ,, then this update is not considered because it is already in the update queue. Otherwise, it is on the one hand written in this box 124 of the hash table 122 and secondly put in the queue 120 in the last position. The queue 120 may be a FIFO queue. When an update is about to be made then its identification data is removed from the queue 120 and the hash table 122. The system 100 further comprises an update module 126 managing the updates according to one or more update requests 128 received for example from an update interface 130 which may be an administration interface of the database source 102. FIGURE 2 is a schematic representation of an example of a dimension of a sort cube, for example a dimension of the sort cube 108 of FIGURE 1. The dimension 200 shown in FIGURE 2 includes a list 202 of meta-members, noted 2041-204n. Each meta-member 204 comprises a member 206 and an index 208 of this member 206 in the dimension 200. Each member 206 of the dimension corresponds to a different value that can be taken by the sorting criterion with which the dimension 200 is associated, on the other hand. set of records present in the source database. For example, if the sorting criterion is the "PRICE" and for this sorting criterion all the records in the database have only three different values which are 100E, 200E and 300E then the associated dimension 200 this criterion will have three members who are member 100E, member 200E and member 300E. For each member 206, the dimension includes a meta-member 204 including that member. Each member 206 of the dimension 200 stores the identifier of each record of the source database which has, for the sorting criterion with which the dimension 200 is associated, a value equal to this member. For example, the member 100E stores the identifier of each record presenting for the sorting criterion "PRICE" a value of 100E, i.e. the identifier of each record whose price is 100E. For each member 206, the identifier of a record is stored in a hash table 210, and more particularly in a box 212, of the hash table 210 corresponding to the hash value calculated for this identifier according to a hash function predetermined, and common to all dimensions of the sort cube comprising the dimension 200. In other words, to register an identifier of a record in a member 206, first of all a hash value is calculated with a predetermined hash function taking into account input the identifier of the record. Once the hash value has been calculated, the box 212 of the hash table 210 in which the identifier must be stored. Once the box has been identified, the identifier is written in this box 212, of the hash table 210. The dimension 200 comprises an ordered list 214 of the meta-members, and therefore members, of the dimension 200 according to an order, said output, using a comparison function, called output comparison, performing a comparison of values, in particular numerical values, considering all the variants of the same value as different. For example, the output comparison assumes that the values 7 and 7.0 are different. This ordered list according to the output order is necessarily ordered according to an order, called filtering, using a comparison function, called filtering comparison, performing a comparison of values, in particular numerical values, considering all the variants of a - 28 - same value as equal. For example, the filter comparison assumes that the values 7 and 7.0 are equal. The dimension 200 further comprises a hash table 216, called dictionary, common to all the members 206 of the dimension 200, therefore common to all the meta-members 204 of the dimension 200. This hash dictionary table 216 stores for each record whose identifier is registered by at least one of the members 206 of the dimension 200, the identifier of the record in association with a list of the indexes, in the sorted list 202, of all the members 206 of the dimension, storing the identifier of this record. To do this, a hash value is calculated for each identifier. Then, according to this hash value, a box 218 is identified in the dictionary hash table 216. Then the identifier and the list of indexes 15 associated with this identifier are stored in this box 218 of the table 216 The dimension 200 further comprises a conversion function, associated with this dimension, for converting a string to a member and vice versa. FIGURE 3 is a schematic representation of an exemplary embodiment of a sorting method according to the invention. The method 300 comprises a step 302 for receiving a sorting request, for example by the manager module 118 from a user interface 112. The sorting request can be received through a wired communication network or not. The sorting request comprises at least one filtering relation, each filtering relation is aimed at a sorting criterion and comprises a sorting operator and a sorting value. When the sorting request includes several filtering relations, it also comprises at least one Boolean operator linking these filtering relations to one another. The Boolean operator can for example be the Boolean operator "AND" corresponding to an intersection or the Boolean operator "OR" corresponding to a union. The sort request also includes at least one output relationship, each output relationship is for a sorting criterion and includes a sort operator and a sort value. The filtering relationships are grouped in the sort request into a first list and the output relationships are grouped in the sort request in a second list. Then, a phase 304 for obtaining a sort cube is performed. The obtaining phase 304 of the sorting cube comprises a step 306 performing an analysis of the sorting request to determine all the sorting criteria targeted by the sorting request, namely all the sorting criteria targeted by the filtering relations and by the relations of exit. The phase of obtaining the sorting cube 304 then comprises, a step 308, of generating a sorting cube, for example the sorting cube 108, comprising a dimension for each sorting criterion referred to in said sorting request and determined in step 306. Each dimension of the sorting cube thus obtained is independent of the other dimensions of the sort cube and may have an architecture identical or similar to that of dimension 200 of FIGURE 2, namely that: - each dimension comprises one or more members, each corresponding to a different value that the sorting criterion associated with said dimension may have on the set of records of the source database, and each member of a dimension stores an identifier of at least one record showing for said criterion a value corresponding to that member. A filtering phase 310 applies each filtering relation of the sorting request, independently of the other filtering relations, to the members of the dimension of the sort cube concerned by the filtering relation. Each filtering relation returns an intermediate group of numerical identifiers, preferentially stored in a hash table as well. The set of groups thus created is then used to provide a final group of numerical identifiers. A ranking phase 312 applies each output relationship of the sort request, independently of the other output relationships, to the final group provided by the filtering phase 310 in order to classify the identifiers of the final group. This phase 312 provides a list obtained by concatenation of the pairs (output relationship / records) obtained by unitary application of the output relations of the sorting request. During a phase 314, a filtering result is provided depending on the final group of digital identifiers provided by the filtering phase 310 and / or the list provided by the classification phase 312.

The result determination phase may comprise a measurement comprising a count, and possibly a display, of the total number of digital identifiers present in the final group or in each pair (output relationship / records).

FIGURE 4 is a schematic representation of an example of a phase of obtaining on the fly a sort cube, which can be implemented in the context of the method according to the invention. The example shown in FIG. 4 may, for example, constitute the obtaining phase 304 of the method 300 of FIG. 3. The obtaining phase 400 of a sorting cube, represented in FIG. 4, comprises a step 306 of FIG. query analysis and a step 308 of generating the sort cube as described above. Step 308 of generating the sort cube includes the following steps. A step 402 determines whether the received sort request comprises an identification data item, called a key, of an existing cube to be used. If in step 402 a cube key is specified in the sort request, in step 404, the cube key specified in the sort request is used to determine the cube to be used, for example by looking up the cube. a repository of the sorting cubes, such as the cubes repository 110 of FIG. 1. If, in step 404, no cube corresponds to this key or the cube corresponding to this key no longer exists / not, then a new Sort cube is created and loaded based on the data of the source database at step 406, for example through the data provider 106 of FIG. 1. This new cube, created then loaded, is then used as a sort cube. If, at step 404, an existing cube is identified for the key specified in the sort request, for example in the cube repository 110 of FIGURE 1, then a step 408 tests the existing cube to determine if the existing cube includes all the dimensions targeted by the sorting request, for example by consulting the existing dimensions and loaded into the existing cube. If all the dimensions targeted by the sorting request exist, ie no dimension referred to in the sorting request is missing in the existing cube, the existing cube is adopted as the sort cube in step 410 and the sorting request can be to be applied to the sort cube. If at step 408, at least one dimension targeted by the sorting request is missing in the cube identified then at step 412, each missing dimension is constructed, loaded, and finally added to the existing cube from the database data. source data, for example by the data provider 106 of FIG. 1. The cube thus completed in step 412 is adopted as a sort cube in step 414.

If at step 402, no cube key is specified in the sort request, then step 416 determines whether there is a previously loaded cube, for example by viewing a cube repository, which can be the cubes repository 110 of FIG. 1. Such a consultation can be performed by the manager module 118 of FIG. 1. Thus, it is determined whether an existing and loaded cube comprises at least one dimension targeted by the request. If multiple cubes with at least one dimension targeted by the query exist and are loaded, then the existing cube that contains the most dimensions of the query is used.

If at step 416 at least one existing cube is identified, then step 408 is performed. If at step 416 no existing cube is identified then step 406 previously described is performed and a new sort cube is generated entirely. It is important to note that the new cube generated in step 406 includes only the dimensions referred to in the received sort request. It is also important to note that the dimension (s) added in step 412 each corresponding to a dimension referred to in the sort request and absent from the existing cube. Each dimension generated, in step 406 or step 412, may preferentially present the architecture of dimension 200 of FIG. 2.

FIGURE 5 is a schematic representation of an example of a phase applying one or more filtering relations, that is to say a filtering phase, or a phase applying one or more output relationships, that is to say a classification phase, which can be implemented in the method according to the invention. The phase 500 shown in FIG. 5 may be the filtering phase 310 of FIG. 3 when the applied relationships are filtering relationships. The phase 500 shown in FIGURE 5 may be the rank phase 312 of FIGURE 3 when the applied relationships are output relationships. As a reminder, a sort request includes one or more filtering relationships and one or more output relationships. When the sorting request comprises several filtering relations, it also comprises one or more Boolean operators each linking two filtering relations to one another. Boolean operators are most often a Boolean "AND" corresponding to an intersection or a Boolean "OU" corresponding to a union. Each relationship, filtering or output, is a sorting criterion and therefore applies to a dimension associated with said sorting criterion. Each relationship includes a sort operator, and possibly at least one sort value. Phase 500 is performed once the sort cube is obtained, i.e., a sort cube comprising one dimension for each sort criterion. Each dimension of the sort cube to which the sort request applies preferably has the architecture of dimension 200 of FIG. 2. Step 500 comprises a step 502 unitarily applying a relation to a dimension of the cube of sorting.

This step 502 is performed independently for each of the relationships in the sort request, even if two relations, filtering or output, are aimed at the same dimension. Step 502 applying a one-dimensional relationship may include an optional step 504 of identifying a dimension member, referred to as a reference member, corresponding to the sort value specified in the relationship. The step 504 of identifying, in an ordered list of members, the reference member corresponding to the sorting value, that is to say the reference member. Preferably, this identification step can be performed by binary search. The index of the reference member is stored. Such an index can be the index 208 of FIG. 2. Then, during a step 506, at least one member, referred to as edge, is identified in the ordered list of the members of the dimension in a direction and / or in the other way. Once at least one identified edge member, all the members satisfying the relation are identified in this step 506. The step 502 comprises, after the step 506, an optional step 508, performing the union of the identifiers of stored in each of the members satisfying the relationship, when several members of the same dimension satisfy the relationship. According to a nonlimiting preferred example, a hash table stored in each member is used, such as for example the hash table 210 of FIG. 2. To do this, a hash table of a member chosen from the members satisfying the The relationship is copied, for example, the hash table of the reference member or a member of the board. Then, for each of the other members checking the relation, the following operations are performed: - for each identifier of the member, calculates the value of hash for this identifier, - 34 - the hash table obtained by copy contains a memorized identifier in the box associated with this value of hash: - if not, registration of this identifier in this box, - if yes, this identifier is already present in the intermediate group and will not be memorized. The hash table obtained by copy and thus completed includes the union of record identifiers stored by all the members of the dimension respecting the relationship. In step 510 an intermediate group comprising or corresponding to this hash table is provided for the relationship. It is important to remember that step 502, comprising steps 504-510, is performed for each relation of the sorting request and provides, for each relation, an intermediate group of record identifiers stored in a table. hash.

When the phase 500 is a filtering phase, for example the phase 310 of FIGURE 3, the step 502 is followed by a step 512 applying the Boolean operators connecting two filtering relations to the intermediate groups provided by the application of each filtering relationship, that is, by performing step 502 for each filtering relationship. When the Boolean operator connecting two or more filtering relations is a Boolean "OU" then the union of the intermediate groups provided for these filtering relations is determined. To do this, a hash table of one of the intermediate groups is chosen and the algorithm described above with reference to step 508 is performed with each of the other intermediate groups. When the Boolean operator connecting two or more filtering relations is a Boolean "AND" then it is the intersection of the intermediate groups provided for these filtering relationships that is determined. To do this, a hash table of one of the intermediate groups is chosen. Then the following operations are performed: - for each identifier of the hash table chosen, calculates the hash value for this identifier, - each of the hash tables of the other intermediate groups contains an identifier stored in the associated box to this hash value: - if no, delete this identifier from the chosen hash table, and more specifically from the box associated with its hash value, if yes, keep this identifier, which already exists in the hash table chosen . Step 512 thus provides a final group of identifiers stored in a hash table. These identifiers are those of the records verifying the sort request. In the case where the phase 500 is a classification phase, the step 502 is followed by the following steps: a step 514, performed for each output relationship, and determining, for each output relationship, the intersection of the intermediate group provided by the unitary application of this one-dimensional output relationship, with the final group previously provided by the filtering phase: a pair (output relationship, end group identifiers verifying the output relationship) is then obtained, and a step 516, providing a list of couples (output relationship; records) obtained by concatenation of the pairs (output relationship; records) provided by the output relations of the sort request. The intersection of an intermediate group provided by the application of a one-dimensional output relationship with the final group provided by the filtering phase can be performed in the same way as the application of the Boolean operator "AND Described above.

FIGURE 6 is a schematic representation of an example of a verification of the uniqueness of an update, which can be implemented in the method according to the invention. Such a verification can be carried out after receiving an update request, following a modification made at the source database level. The check 600 shown in FIGURE 6 includes a step 602 of receiving an update request. Then a step 604 of checking the uniqueness of the update is performed. This step 604 includes a step 606, computing an identification data for the update. This data is calculated by concatenating the elements of the update request. A hash value is calculated for this identification data using a hash function at step 608. A step 610 consults a hash table, for example, the hash table 122 of FIGURE 1, in which the hash values are computed. credentials for updates awaiting completion are stored. The following operations are performed: identification of a box of the hash table corresponding to the calculated hash value, comparison of the identification data with each of the identification data already stored in this box: if it does not correspond no identification data already stored then storing the identification data in this box of the hash table and in an update queue, for example the queue of updates 120 of the FIGURE 1 ; if it corresponds to an identification data already stored, then the update request is ignored.

FIGURE 7 is a schematic representation of an example of an update processing that can be implemented in the method according to the invention. The processing example 700 shown in FIGURE 7 includes a step 702 consulting an update waiting list, for example the waiting list 120 of FIGURE 1, and selecting the update to be performed. who is in first position on the waiting list. In step 704, the update is analyzed to determine the type of update, namely an update of a cube, a dimension of a cube or a record in a dimension, or a record for each dimension of a cube. If at step 704, it is determined that the update to be processed is an update of a dimension or a cube then, a step 706 performs an identification of the cube or dimension concerned, then a copy of this cube or dimension to update. In a step 708, the copy of the cube or dimension is updated. During a step 710, the cube or dimension to be updated is replaced by the updated copy of the cube, respectively the dimension.

If in step 704, it is determined that the update to be processed is an update of a record in a dimension, respectively in a cube, then the following steps are performed for this dimension, respectively for each dimension of cube.

A step 712 makes a copy of this dimension. In a step 713 the list of the new members concerned by the updated recording is retrieved, for example by consulting the data provider 106 of FIGURE 1. The list of new members corresponds to the list of the members who memorize a identifier of the record after updating the record. Then, during a step 714, the list of the old members containing the record are identified, by consulting a hash table, called dictionary, such as the dictionary hash table 216 of FIGURE 2, storing for each record a list of the indexes of the members of this dimension memorizing this record. To do this, the following operations are performed: calculation of a hash value for the identifier of the record, identification of the box of the hash table corresponding to this hash value, and identification in the this box, a list of members corresponding to this identifier, and memorizing this identifier. Based on the list of new members and the list of old members, the members to be updated are determined and updated at a step 716, working on the copy, made at step 712, of the dimension affected by the update. The updated members are the members who differ between the two previously determined lists, namely: - the members who were in the list of the old members, but more in the new ones: in this case the identifier of the registration is deleted from each of these members. If an existing member in the copy no longer includes any record identifier then that member is removed from the copy of the dimension; and the members who were not in the list of old members, but who are now included in the list of new members: in this case the identifier of the registration is added to each of these members. If a new member is missing in the copy then this new member is added to the copy of the dimension. At each update of a record, the dictionary hash table 216 is also updated in a step 718. If the dimension includes an ordered list of the members of the dimension, for example list 214 of FIGURE 2 sorted according to the output order, and that a member update causes that member to be created or deleted, then the ordered list is also updated in step 718. Then in a step 720, the dimension to be updated is replaced by its copy thus modified during steps 716 and 718.

We will now describe some nonlimiting examples of filtering relation and, for each filtering relation, an example of non-limiting application of said filtering relation on a dimension of the sorting cube.35 - 39 - "Equal" filtering relation This Filtering relation includes an "Equal" operator and a text sorting value, which represents the member (s) containing the records to be returned.

This value is converted using a conversion function associated with the dimension and allowing the conversion of a string into a member. This gives us the reference member to search. If the value can not be converted, filtering does not apply, and an "All" value is returned. Otherwise, the following steps are performed: search for the index, also called reference position, by performing a binary search of the reference member in the ordered list according to the output order; o if the reference position is negative, then it is replaced by its binary complement; starting from the reference position, in ascending order, successively test each member of the list until finding the last member respecting the equality condition, according to the order of filtering. - starting from the reference position, in descending order, successively test each member until finding the last member respecting the equality condition, using the filtering order.

The two members thus found are the members on board. The members located between the two members of board, them included, are the members satisfying the relation of filtering, and contain the recordings to return: the intermediary group returned corresponds to the union of all these recordings.

"Superior" filtering relationship This filtering relationship includes a "Top" operator and a text sorting value, which represents the lower bound of the list of dimension members. - 40 - This value is converted using the conversion function associated with the dimension and allowing the conversion of a string to a member. This conversion gives the reference member. If the value can not be converted, filtering does not apply, and an "All" value is returned. Otherwise, the following steps are performed: - search for the reference position by performing a binary search of the reference member in the ordered list according to the output order; ^ if the position is positive, then it is incremented (position = position + 1). ^ if the position is negative, then it is replaced by its binary complement. - starting with the reference position, in ascending order, successively test each member until finding the first member respecting the condition of superiority, in application of the filtering order: this member is the edge member. This board member, along with all subsequent members, are the 20 members satisfying the filtering relationship and contain the records to be returned: the returned intermediate group is the union of all these records. This filtering relationship includes an "Inferior" operator and a text sorting value, which represents the upper bound of the list of dimension members. This value is converted using the dimension conversion function to convert a string to a member. This conversion gives the reference member. If the value can not be converted, filtering does not apply, and an "All" value is returned. Otherwise the following steps are applied: -41- - search for the reference position by performing a binary search of the reference member in the ordered list according to the output order; - if the position is positive, then it is decremented (position = position - 1). - if the position is negative, then it is replaced by its binary complement minus 1 (position = -position - 1). starting from the reference position, in descending order, successively testing each member until finding the first member respecting the inferiority condition, in application of the filtering order. This member is the member on board. This board member and all the previous members satisfy the filtering relation and contain the records to be returned: the returned intermediate group corresponds to the union of all these records. "Greater than or equal" filtering relationship This filtering relationship includes a "Greater than or equal" operator and a text sorting value, which represents the lower bound of the list of dimension members. This value is converted using the conversion function of the dimension reading a conversion from the string to a member. This conversion gives the reference member. If the value can not be converted, filtering does not apply, and an "All" value is returned. Otherwise, the following steps are performed: - search for the reference position by performing a binary search of the reference member in the ordered list according to the output order: ^ if the position is negative, then it is replaced by its binary complement ; - starting with the reference position, in descending order, successively test each member until finding the last member respecting the condition of superiority or equality, in application of the filtering order; - 42 - This member is the member on board. This member and all subsequent members satisfy the sort condition and contain the records to return: the returned intermediate group is the union of all these records.

"Less than or equal" filtering relationship This filtering relationship includes a "Less than or equal" operator and a text sorting value, which represents the upper bound of the list of dimension members.

This value is converted using the conversion function from a string to a member, associated with the dimension. This conversion gives the reference member. If the value can not be converted, filtering does not apply, and an "All" value is returned.

Otherwise, the following steps are performed: - search for the reference position by performing a binary search of the reference member in the ordered list according to the output order: ^ if the position is negative, then it is replaced by its binary complement minus 1 (position = -position - 1); starting from the reference position, in ascending order, successively testing each member to find the first member respecting the condition of inferiority or equality, in application of the filtering order. This member is the member on board. This board member and all the previous members satisfy the filtering relation and contain the records to be returned: the returned intermediate group corresponds to the union of all these records.

"Between" filtering relationship This filtering relationship is a combination of the "Greater or equal" and "Lower" filtering relationships. This filtering relation comprises two sorting values in text format, which respectively represent the lower bound and the upper bound to be applied. The operation is then identical to the two above-mentioned filtering relations. These filtering relationships are described above.

We will now describe some non-limiting examples of output relationships and for each output relationship an example of non-limiting application on one dimension. "Equal" output relationship This output relationship includes the "Equal" operator and requires a text value, which represents the member (s) containing the records to be returned. This value is converted using the function of converting a string into a member associated with the dimension. This gives the reference member. If the value can not be converted, the output relationship is ignored (nothing is returned). The following steps are performed: search for the reference position by performing a binary search of the reference member in the ordered list according to the output order; If the position is negative, then it is replaced by its binary complement, starting from the reference position, in ascending order, successively testing each member of the list until finding the last member complying with the condition. equality, in application of the filtering order. starting from the reference position, in descending order, successively testing each member up to find the last member respecting the equality condition, in application of the filtering order. The two members thus found are the edge members. These edge members as well as the members between them contain the records to be returned and make up the intermediate group for this output relationship. - 44 - To obtain the set of output relationship pairs / records to return, the following transformations must be applied to each of the members found previously: - convert the member to text using the conversion function, associated with the dimension, allowing the conversion of a member into a string of characters, - to make the intersection of the records of the member with the records resulting from the application of the filtering relations, - to create an output relation composed of the sorting criterion of the dimension, the 'Equal' operation, and a sort value corresponding to the member in text format, - create a pair containing the output relationship and the records provided by the intersection. The result of the application of this output relationship is the list of output relationship pairs / records thus created. "Superior" output relationship The output relationship includes the "Superior" operator and requires a text value, which represents the lower bound of the ordered list of the members of the dimension. This value is converted using the conversion function from a string to a member, associated with the dimension. This gives the reference member. If the value can not be converted, the output relationship is ignored (nothing is returned). The following steps are applied: - search for the reference position by performing a binary search of the reference member in the ordered list according to the output order, 30 - if the position is positive, then it is incremented (position = position + 1). - if the position is negative, then it is replaced by its binary complement. starting from the reference position, in ascending order, successively testing each member until the first member satisfying the superiority condition is applied, in application of the filtering order. This member is the member on board. This member and all subsequent members contain the information to return.

To obtain the set of output relationship pairs / records to return, perform the following operations: - calculate the union of the records contained in the previously found members, - make the intersection of the previously calculated union and the records from the application of filtering relations, - create a couple containing the output relationship and the records provided by the intersection. The result of applying this output relationship is the unique output relationship / record pair thus created.

"All" output relationship This output relationship includes the "All" operator and does not require any value. It means that all members of the target dimension are an output relationship, i.e. all members of the dimension are checking the output relationship. To obtain the set of output relationship pairs / records to be returned, the following transformations must be applied to each of the members of the targeted dimension: - convert the member to text using the conversion function, associated with the dimension, allowing the conversion of a member into a string of characters, - making the intersection of the member's records with the records resulting from the application of the filtering relations. - create an output relationship composed of the dimension sort criterion, the "Equal" operation, and a sort value corresponding to the member in text format, - create a pair containing the output relationship and the records provided by the intersection. The result of the application of this output relationship is the list of output relationship pairs / records thus created. Of course, the invention is not limited to the examples which have just been described and many adjustments can be made to these examples without departing from the scope of the invention.

Claims (17)

REVENDICATIONS1. A method (300) of data processing for sorting within a set (104) of digital entities, called records, each of said records being represented by at least one numerical data item, called value, associated with at least one criterion , said sorting, and stored in a database (102), said source, in association with at least one identification data of said record, said method (300) comprising: - a step (302) of receiving a query, called sorting, comprising at least one filtering relation targeting a sorting criterion, and - a phase (304, 400) for obtaining, on the fly and from said source database (102), a database (108), called sort cube, comprising a dimension (200) associated with each sorting criterion referred to in said sorting request, each dimension (200): ^ being independent of the other dimensions (200) of said cube ( 108), and comprising ^, one or more members (204,206), co each corresponding to a value that can take the sorting criterion which is associated with said dimension (200) and storing an identifier of at least one record having said value for said sorting criterion, - a phase (310,500) for filtering said cube of sorting (108) with the at least one filtering relation composing said sorting request; and a phase (314) for determining a sorting result, as a function of said filtering. 2. Method (300) according to claim 1, characterized in that: the filtering phase (310,500) provides at least one identifier of at least one record which verifies the at least one filtering relation, and - The sorting request further comprises at least one relationship, called output, for a sorting criterion; and in that said method further comprises, after the filtering phase, a so-called classification phase (312,500) of said at least one record as a function of said at least one output relationship. 3. Method (300) according to any one of the preceding claims, characterized in that the phase (304,400) for obtaining the sort cube (108) comprises the following steps: - determination (306) of all sorting criteria referred to in the sorting request, - consulting (408) an existing cube to determine if said existing cube comprises, for each of the sorting criteria referred to in the sorting request, a dimension associated with said sorting criterion: - if yes, using (410) said existing cube as a sort cube, - otherwise, completing (412) said existing cube with each of the missing dimensions from the source database (102) and using said existing cube thus completed as a sort cube. 4. Method (300) according to claim 3, characterized in that the sorting request comprises an identification data of said cube existing in a base of cubes (110) comprising at least one cube (108). 5. Method (300) according to any one of the preceding claims, characterized in that the filtering phase (310,500) comprises, for each filtering relationship targeting a sorting criterion, a filtering step (502), according to said relation filtering, members of the dimension (200) of the sort cube (108) associated with said sorting criterion, independently of the other filtering relationships, said filtering step (502) providing a group, said intermediate, comprising the identifiers of all records stored in said dimension (200) and verifying said filtering relation. 6. Method (300) according to claim 5, characterized in that, when the sorting request comprises several filtering relations, said request also comprises one or more Boolean operators connecting said filtering relations with each other, the filtering phase (310,500 ) further comprising a step (512) applying said Boolean operators to the intermediate groups of identifiers provided by each of the filtering relationships, and providing a group, said final, of record identifiers. 7. Method (300) according to claims 2 and 6, characterized in that the classification phase (312,500) comprises, for at least one, and preferably for each, output relationship, the following steps: - filtering (502) in said output relationship, members of the dimension (200) targeted by the output relationship, said filtering providing an intermediate group of record identifiers checking said output relationship; and - determining (514) the intersection of said intermediate group thus obtained with the final group provided by the phase (310,500) of filtering said sorting cube (108) according to the at least one filtering relation. 25 A method (300) according to claim 7, characterized in that, when the sorting request comprises a plurality of output relationships, the ranking phase (312,500) comprises a unitary and independent application of each of said output relationships, said phase of ranking (312,500) further comprising a step (516) of concatenating the results provided by each of the output relationships, said ranking step (312,500) providing a list obtained by said concatenation. 9. Method (300) according to any one of the preceding claims, characterized in that the phase (314) for determining the sorting result comprises a step of counting the number of different records verifying the sorting request. 10. Method (300) according to any one of the preceding claims, characterized in that the phase (314) for determining the sorting result further comprises a step of displaying at least one item relating to at least one record. checking the sort request. 11. Method (300) according to any one of the preceding claims, characterized in that at least one dimension (200) of the sort cube (108) comprises at least one ordered list (214) in which the members (204,206) of said dimension (200) are ordered according to a predetermined relationship applying to member audits (204,206). 12. Method (300) according to claim 11, characterized in that, at least one filtering relationship, respectively at least one output relationship, targeting a sorting criterion is composed of an operator, said sorting, and at least one so-called sorting value for said sorting criterion, and in that the filtering of a dimension (200) according to said filtering relation, respectively said output relation, comprises the following steps: - identification (506 ), in said ordered list (214), at least one member, said edge member, of said dimension (200) which respects or no longer respects said relation, and - selection (506-510) according to said at least least one edge member of each record identifier stored by each member respecting said relationship. 13. Method (300) according to any one of the preceding claims, characterized in that it comprises, following a modification in said source database (102), a phase (700) for updating a cube. sort (108) previously obtained and concerned by said modification, said phase (700) of updating a sort cube (108) comprising the following steps: - 51 - - identification (706) of said previously obtained sorting cube , said old sort cube, - retrieving a list of dimensions of said old sorting cube, - loading a new cube according to said dimensions and from said modified source database, and - replacing (710) said old sorting cube by said new cube. 10 14. Method (300) according to any one of the preceding claims, characterized in that it comprises, following a modification in said source database (102), a phase (700) for updating a dimension. (200) of a sort cube (108) previously obtained and concerned by said modification, said update phase (700) of a dimension (200) comprising the following steps: - identification (706) of said dimension (200), said old dimension, said sorting cube (108), - loading a new dimension according to said modified source database, and - replacing (710) the old dimension by the new dimension in said sort cube. 15. Method (300) according to any one of the preceding claims, characterized in that it comprises, following a modification in said source database (102) of a record, a phase (700) of setting day of said recording in a dimension (200) comprising the steps of: - obtaining (712) a so-called dimension, new dimension, by copying the old dimension; - identification (713,714,716) of all the members of the said new dimension concerned by the said update; for each of said identified members of said new dimension: deletion of the identifier of said record stored by said member, or storage of the identifier of said record by said member; - when at least one member is deleted / added in said new dimension, updated (718) of the position of all the members following said member in said new dimension, - replacement (720) of said old dimension by the new dimension thus modified. 10 16. Method (300) according to any one of claims 13 to 15, characterized in that it comprises, for each update, a check (604) of the uniqueness of said update, said check (604 ) comprising the steps of: - determining (606) a value associated with said update, - determining (608) a hash value from said value associated with said update, and - checking ( 610), depending on said hash value, whether or not said value associated with updating in a hash table (122) storing a value associated with at least one update waiting to be realized . 17. System (100) comprising the means arranged to carry out all the steps of the method (300) according to any one of the preceding claims.