FR3047580B1 - DATA BASE TABLE INDEX - Google Patents

Abstract

An index for database table is provided. The index includes an index structure for each column of the database table. Each index structure includes a set of pointer tuples for each value that appears in the column, and a bitmap that indicates valueless cells. A first pointer tuple indicates a value and a second pointer indicates the row of the database table with the value. The index also indicates a specific order of rows in the database table. The computer system proceeds with a request using the bitmaps of the index structures to hold all rows of the valueless database table and the pointer tuples to filter all rows in the database table that do not include not the respective input value. The row that is the highest in the order of specificity is selected from the remaining rows and is returned.

Description

DATA BASE TABLE INDEX

FIELD OF THE INVENTION

In general, the present invention relates to database technology. More specifically, the present invention is directed to an index for accessing a database table in response to a request and for determining the most specific data record (row) of the request-compliant database table. .

CONTEXT

Index database tables are known to access data records in a direct or accelerated manner. An index is a metadata structure that improves the speed of data extraction operations on a data table, at the expense of storage space to maintain the structure of the index data. Indexes are used to quickly locate data without having to search each row in the database table each time you access the database table. Indexes can be created using one or more columns of the database table and provide both the basis for fast random browsing and efficient access to ordered records.

A particular task in various database-related applications is to retrieve only the row of the most specific database table responding to a pull request. Therefore, in response to a request, the database application therefore determines the row of the database table that corresponds to the parameters or input criteria in the most specific manner. For this purpose, a hierarchy of specificity within the row is usually present in the database table.

A known approach to determining the most specific row in the database table uses the Raite algorithm. The Raite algorithm is a pattern matching algorithm that is used eg. to implement production rule systems (eg automated planning, expert systems, and action selection systems). It is used to determine all rules that match the input criteria. An alleged "conflict resolution" is then carried out. It uses an order among the rules determined to identify the rule to be returned.

SUMMARY OF THE INVENTION The object of the present invention is to provide a database table index that particularly facilitates the determination of the most specific database table row that fills the input parameters of a request. extraction. The object of the present invention is also to provide a database table index that has a particularly compact data representation and thereby minimizes memory requirements. The object of the present invention is also to provide a database table index which deals specifically with the internal architecture and sizing memory of ultramodern computer systems and which is optimized to be kept in a cache of processor and thus facilitates the high-performance determination of the most specific database table row. The object of the present invention is also to provide a database table index for deterministic response processing.

In one aspect, these objects are solved by a method of determining the most specific row in the database table. The database table is maintained by a computer system. The database table consists of a plurality of rows and a plurality of columns. The rows and columns of the database table form cells. Each cell has either a value or at least one value. The computer system also maintains an index for the database table. The index includes a respective index structure for each column of the database table. Each index structure comprises two types of substructures, namely a respective set of pointer tuples for each value appearing in the respective column and a bitmap related to the cell of the valueless column. Each pointer tuple includes a first pointer indicating one of the values that appears in the column and a second pointer indicating the row of the database table in which the value appears. The bitmap indicates all cells in the respective column with no value. The index also indicates a specific order of rows in the database table.

The most specific row determination method includes the following activities:

The computer system receives a request indicating the columns of the database table associated with a respective input value. The computer system then processes the request incrementally for each column indicated in the request. For each column, the computer system uses the bitmap of the index structure for the column to maintain all rows in the database table that do not contain values in the cell of the column in question. In addition, for each column, the computer system uses the pointer tuple of the index structure for the column to filter all rows in the database table that do not understand the respective input value. Once all the columns with the respective input values of the request have been processed, the computer system selects the topmost row in the order of specificity among the remaining rows, i.e. the rows that have not been filtered during incremental column processing. Finally, the computer system returns the value of at least one cell of the determined row.

In another aspect, a computer system arranged to execute a respective method of determining the most specific row in the database table is provided.

In yet another aspect, a computer program for instructing a computer system to execute the method of determining the most specific row in the database table is provided.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be described with reference to the accompanying drawings. Similar reference numbers generally indicate identical or functionally similar elements.

Figure 1 illustrates a database with a database table.

Figure 2 is a generic example of a database table and a request.

Figure 3 illustrates the structure of an index as described herein.

Figure 4 is a generic example of an index for the database table of Figure 2.

Figure 5 gives a generic example of request processing using the index

Figure 6 is a flowchart of an example of request processing.

Fig. 7 is an exemplary arrangement of a set of pointer tuples in memory.

Figure 8 illustrates a binary search on a set of pointer tuples.

Figure 9 is an example of index generation.

Figure 10 is a high level flowchart of a general process including index generation and determination of the most specific row.

Figure 11 schematically shows the maintenance of a database table and the index in the memories of a computer system.

Figure 12 shows a routing table as an example of a database table.

FIG. 13 is an example of a schematic view of the internal architecture of a computer system implementing the database and / or a requesting client.

DETAILED DESCRIPTION The index described herein facilitates access to a database table maintained by a database system. The term database as used herein includes all kinds of data repositories retaining static or dynamic data in the form of tables. These kinds of data repositories include, for example, relational database systems such as Oracle® databases, Microsoft® SQL Server, Microsoft Access®, object relational database system such as PostgreSQL, systems production rules such as expert systems and action selection system engines (eg expert systems maintaining maintenance and repair actions for technical devices), control and network elements such as routers (with routing tables), network management nodes (with log and / or order data stored in tables) or SCADA systems (which also store the log and / or order data in the form of of tables) as well as the proprietary systems holding the data eg. in simple tables such as Microsoft Excel® tables or tab text files (eg csv files). Generally, the database is implemented on a computer system such as a database server or a network node. The database is arranged to receive retrieval requests (simply hereinafter referred to as "requests") specifying the search criteria (hereinafter-referred to as "input values") to process the request by checking the d entry to at least one database table to determine a data record of the database table that fills in the input values and returns one or more values of that data record. To this end, the database uses any type of database language and is equipped with any type of communication interface known in the art. The applicant, eg. a client (computer, mobile station, application, etc.) in a local area network (LAN) or in a remote network querying the database 1.

As shown in FIG. 1, a database 1 maintains at least one database table 2. The database table 2 consists of a number of rows 3 and a number of columns 4. Each row 3 of the database table includes a data record and each column 4 of the database table is an attribute of the data records, generally in accordance with a data model (such as a basic business model of relational data). The association of rows 3 and 4 forms cell 5. Generally, any number of rows 3 and 4 may be present in database table 2. Data records may be added or deleted, number of rows 3 in particular is not fixed, but it can change over time. Database 2 may also include mechanisms to redefine or modify the data model, ie the number of columns may also be adapted.

The cells 5 of the database table contain either at least one value or no value (FIG. 2). The values in the cells generally conform to a data type defined for the respective column, as prescribed by the data model. Data types include, for example, Boolean data (ie, values are "true" or "false"), integers, floating point numbers, characters, strings, pointers, and so on. than complex, functional data types such as dates. More than one value may be present in a cell 5, i.e. a cell 5 may comprise a vector or a list of values, e.g. as a set, record, series, enumeration, or value object according to a data type. In some embodiments, the computer system is a router, the database table is a routing table, each row of the routing table is a routing rule for routing an incoming request to a destination, the routing table includes a destination column with possible destination values and a routing column with the corresponding values indicating a route to the destination

The valueless cells may include wildcards such as NUL or *. These wildcards specify the absence of a value, ie, a respective cell is considered to include any value in the range of values allowed for the data type of the corresponding columns, as prescribed in the data model. An example of a data record using wildcards is the standard route in an IP routing table that uses the network address "0.0.0.0" in the destination address columns and the subnet mask in the subnet mask columns as a wild card for any possible destination IP address (see example of the routing table in Figure 12).

Figure 2 shows a generic example of database table 2 with six rows 3 (ie, six data records) and seven columns 4 (ie, the data records have seven attributes). The columns of this exemplary database table define any kind of attributes for the data records held by the rows. The first column 4A defines a key attribute of the data records. The first row 3A defines, for example, a default data record with wildcards "*" in columns 4B to 4F and a "yes" in the last column 4G which is a Boolean data type. Therefore, the first row 3A specifies "yes" as the default answer. The other rows define more specific data records. For example, the second row 3B specifies a tuple of values "A, B" as attribute in the second column 4B and "no" as the last attribute of the data record, while all other cells contain wildcards ( neglecting key column 4A), ie any value for these attributes falls in the data record of row 3B. For example, the data model may define F, G, H, I, J, and K values as the allowed data range for the third column 4C. Therefore, the wild card character in the third cell of the second data record (row 3B, column 4C) represents all possible values F, G, H, I, J, and K of this attribute of the second data record.

The database table 2 is generally stored in the computer system memory, for example in the main memory (RAM).

As explained at the outset, the index of the database table described herein is in particular arranged to determine the most specific row corresponding to a request. In general, rows containing more wildcards (ie more nonvalues, fewer cells with values) than the other rows are considered less specific than rows with fewer wildcards (c-). to less than no values, no more cells with value). In other words, the rows comprising more general data records are defined to be less specific than the rows with more accurate content; these are defined to be more specific. In order to facilitate the determination of the most specific row that corresponds to the input values of a request, an order of specificity among the rows of the database table 2 is either given or established. Optionally, the order of specificity is implicit in sorting the row. For example, the rows are sorted in the nonspecific to very specific table, as in the example of the database table shown in Figure 2. In some embodiments, the order of specificity is explicitly defined, eg. by a specific column indicating the respective level of row specificity, such as the key values in key column 4A of database table 2 in Figure 2. As an option, the strictly monotonic order of specificity, c-to -d that each row of the database table has a unique order of specificity. In other examples, the categories of specificity are defined, and multiple rows may share a common level of specificity. In the last examples, a mechanism is present to ensure that a single row of multiple rows member of the same level of specificity fills the input values in the request, e.g. the rows mutually define exclusive data records and the values are indicated in the request for a minimum number of rows of the database table.

In response to receiving a request indicating at least respective columns and input values, the database 1 proceeds with the request with the input values included in the request and compares the input values with the database table 2 to determine the most specific row that fills the input values. Referring again to Figure 2, a generic example of incoming request 9 is received. In the example of Figure 2, the order of specificity is explicitly defined by column 4A which sorts the rows according to the key values, while row 3A is the least specific row (since it contains five characters replacement and only one value in column 4G) and row 3F is the most specific value (since it contains no wildcards but only cells with values). In the example of FIG. 2, the incoming request 9 indicates the five columns 4B, 4C, 4D, 4E and 4F as well as the respective input values. The database 1 determines that the last row 3F is the most specific row corresponding to the incoming request 9, since the value "A" in the cell 4B / 3F corresponds to the input value A for the column 4B , the value "F" in cell 4C / 3F corresponds to the input value F for column 4C, the values "P, R" in cell 4D / 3F correspond to the input value P for column 4D the value "W" in cell 4E / 3F corresponds to the input value W for column 4E and the value "Z" in cell 4F / 3F corresponds to the input value Z for column 4F. The other two rows 3A and 3B which also correspond to the input values 6 of the incoming request 9 are less specific than the row 3F, since they are classified lower in the specificity of the implicitly defined order of the database table 2.

Once the most specific row 3 is determined, at least one value (attribute) of the most specific row is returned. In the example of FIG. 2, the value of column 4G of row 3F is returned, ie the Boolean value "no".

The determination of the most specific row corresponding to a request uses the index 10 described in this document (FIG. 3). The index of the database table 2 comprises the following elements: - There is an index structure 11 for each column 4 of the database table for which the input values in a request are expected. An index structure 11 therefore also refers to an index structure specific to the column below. Each column-specific index structure 11 has two elements, namely o a set of pointer tuples 12 and o a bitmap 13 (as usually understood by the qualified person, a bitmap is a collection of contiguous bits, c- to a bit array). The set of pointer tuples 12 has the function of referring to all the values in the cells of the column to which the respective column-specific index structure 11 refers. Each pointer tuple 14 in the set 12 includes a first pointer 15 and a second pointer 16. o The first pointer 15 refers to one of the values included in the column. The value is stored at a particular location in the memory of the computer system hosting the database 1. The first pointer refers to this memory location. o The second pointer 16 indicates the row of the database table 2 in which the value appears. For example, the row is identified by a key value that is still stored at a particular memory location in the memory of the computer system hosting the database 1. The second pointer refers to that memory location.

Thus, the number of pointer tuples 14 included in the set 12 corresponds to the number of values appearing in the column to which the column-specific, respective index structure 11 refers. Bitmap 13 specifies the cells in the column to which the respective column-specific index structure 11 refers and which has no values, i.e. it includes wildcards. Bitmap 13 is therefore also called "valueless bitmap". The number of bits in the valueless bitmap 13 corresponds to the number of rows 3 of the database table 2.

Fig. 4 is an example of an index 10. The exemplary index given with Fig. 4 is related to the generic example of database table of Fig. 2. The index 10 indicated by Fig. 4 is composed of five index structures 11 corresponding to columns 4B to 4F of database table 2 of FIG. 2 for which input values 6 are expected (column 4G with the Boolean data type can not be asked in the example of Figure 2: the values of this column are return values). Each of the index structures 11 contains a set of pointer tuples 12 and the valueless bitmap 13. The set of pointer tuples 12 in each column-specific index structure 11 is a compact list of all the values in the respective column of database table 2. For example, the set 12B in the structure 11B index list the presence of all the values A, B and C appearing in column 4B. The value A appears in the rows with the key values R2, R4 and R6; the value B is present in the rows with the key values R2 and R5 and the value C is present in the rows with the key values R3 and R4 (see Figure 2). As mentioned above, the first pointers in the pointer tuples refer to the respective memory address of the values A, B and C in the computer memory, while the second pointers in the pointer tuples indicate the corresponding row c. -ref refer to the key values of the row in this example. The same is true for the other sets 12C to 12F in the index structures 1 IC to 11F.

Optionally, pointer tuples 14 in sets 12 are sorted by the value referenced by the first pointers. In Fig. 4, for example, the pointer tuples in the set 12B are sorted by the values A, B and C appearing in column 4B. Therefore, the first three pointer tuples in the set 12B define the appearance of the value A in column 4B; the next two tuples of pointers define the appearance of the value B in column 4B and the last two tuples of pointers define the appearance of the value C in column 4B. Sorting the pointer tuples 14 in the set facilitates efficient memory access, if using the index 10, e.g. to carry out a linear search on the pointer tuples 14 because the respective values only need to be loaded once from the memory, if the first pointer tuple which defines the appearances of a value is processed, and are then available eg in the processor cache for the following pointer tuples always linked to the same value. Sorting the pointer tuples 14 also facilitates a binary search on the pointer tuples that are used in some embodiments (more fully explained below with reference to Figure 8).

The bitmap 13 provides a compact representation of the occurrence of the valueless cell in the database table 2. Each bitmap 13 comprises six bits that coincide with the number of rows 3 in the database table 2 in the example of FIG. 2. By definition, the sequence of the bits in the respective bitmaps corresponds to the sequence of the rows with key values R1 to R6, ie the first bit of each bitmap 13 refers to the row with the key value RI, the second bit in each of the bitmaps refers to the row with the key value R2 and so on and the last bit in each bitmap 13 refers to the last row with the key value R6. In the example of FIG. 4, the bits set to "1" denote all the rows in the respective column with no value (ie with replacement characters) while the bits set to "0" denote rows. in the respective column with values (ie without wildcard). For example, bitmap 13B indicates that only the first row (key value RI) in column 4B does not include a value while the other rows (key values R2 to R6) include values. The same applies to the other bitmaps 13C to 13F analogously for the valueless cells in columns 4C to 4F. Index 10 as described above represents a particularly compact metadata structure (if compared to currently known ultramodern indexes). In some embodiments, the index is stored in a processor cache of the computer system and remains stored in the processor cache after the value of at least one cell of the determined row has been returned to be available for use. other treatment requests. The location of the valueless cells is not stored as pointer tuples 14 but in the form of bitmaps 13 which decreases the number of tuples of pointers 14. The size of a pointer tuple 14 is always a power of 2. For example, a pointer has the size of 8 bytes in a 64-bit memory architecture, which increases the size to 16 bytes for a pointer tuple 14. Since the multiplication of integers for the number of size in the power of 2 is more efficient than for non-power size numbers of 2, the random accesses in the index 10 are effective. For certain categories of database tables (eg tables with 1000 entries or less), the index 10 enters the CPU cache LI and / or L2 and can therefore be permanently available in an access memory very fast and the overall performance of demand processing and row determination is improved. In addition, index 10 facilitates a binary search algorithm to determine the most specific row, as described further below (with reference to FIG. 8). The index 10 also indicates a specific order of the rows 3 of the database table 2. Different ways are envisaged for this indication. For example, as mentioned above with reference to FIG. 2, the database table 2 itself is already sorted according to its order of specificity e.g. from the lowest specificity to the highest specificity (see also activity 38 in Figure 9 and activity 17 in Figure 10). In such embodiments, the order of specificity of the rows of the database table is implicitly present in the index 10 in the valueless bitmaps 13. As explained above, the valueless bitmaps 13 include one bit for each database table row 2 and the bit order in bitmaps 13 corresponds to the order of rows 3 of the database table. 2. Thus, the first respective bit in the bitmaps 13 refers to the first row (eg row 3A in Fig. 2) which is e.g. the least specific row and the last respective bit in the valueless bitmaps 13 refer to the last row (eg row 3F in Fig. 2) which is e.g. the most specific row of the database table 2. In other embodiments, the rows of the database table 2 are not sorted by specificity but the index 10 includes a separate data structure defining the order of specificity of the rows 3. For example, the weighting values 7 (see FIG. 3) are associated with the rows 3 when they generate the index 10 (see also activity 44 in FIG. 9) and are explicitly maintained as as metadata defining the order of specificity of rows 3 in index 7.

In response to receiving an incoming request 9, the computer system hosting the database 1 uses the index 10 to determine the most specific row as follows. In general, an incremental process is performed. It processes the request column by column, for each column (and the respective input value 6) indicated in the incoming request 9.

Starting with the first column 4 indicated in the incoming application 9 (column 4B with the input value "A" in the example of FIG. 2), the computer system uses the bitmap 13 of the index structure 11 to the first column (index structure IB 1 with bitmap 13B in the example of Figure 2) to ensure that all rows 3 of database table 2 that do not contain any value are not rejected because these rows include wildcards that include any input value. Therefore, in the example of Figures 2 and 4, the row RI (indicated by the "1" in bitmap 13B) is permanently maintained. At this stage, no decision is made regarding the maintenance or rejection of the other rows marked with a "0" in bitmap 13B.

Then, in addition to keeping the rows in accordance with the use of the valueless bitmap, the pointer tuples 14 of the index structure 11 for the first column (IB index structure 1 with a set of pointer tuples 12B in the example of Figure 2) are used to maintain all rows 3 which include the respective input value (input value "A" in the example of Figure 2) and to filter all rows 3 of the database table 1 which does not include the input value 6. In the example of FIGS. 2 and 4, all the rows which comprise the value "A" (namely the rows R2, R4 and R6) are maintained while the remaining rows that do not contain the input value "A" in column 4B (rows R3 and R5) are discarded.

Accounting for hold or reject decisions throughout this incremental process is, in some embodiments, based on additional temporary bitmaps (referred to as bitmaps result, described in more detail below) indicating the rows that are still maintained and rows that have already been rejected.

This process is repeated for each column 4 indicated in the incoming request 9. At each iteration, none, one or more rows 3 of the database table 2 is / are rejected. Once all the columns 4 indicated in the incoming application 9 have been processed, one or more rows 3 conforming to the input values indicated in the application remain. The computer system then selects, using the index 10, the row 3 from the remaining rows which is the highest in the order of specificity. In the example of FIGS. 2 and 4, the rows 3A, 3B and 3F (ie the rows with the key values R1, R2 and R6) fill the input values 6 of the incoming request 9 as an example at Figure 2. The most specific row is row 3F (key value R6). In the example of FIGS. 2 and 4, the order of specificity is given by the sorting of the rows which is also reflected in the index 10 (in the bitmaps 13 as well as in the bitmaps results described below). Thus, in the example of FIGS. 2 and 4, the computer system chooses the remaining row with the highest key value (which is the most right in the bitmaps 13 and in the result bitmap described below).

Then, an example of implementation of the incremental request processing and the row determination process is described in Figure 5. This example reuses the example of the database table 2 of Figure 2 and the corresponding index 10 as shown in Figure 4, the latter being shown on the left of Figure 5. In general, the example of processing the request is based on two additional bitmaps to use pointer tuples 14 and valueless bitmaps , ie a column bitmap 23 and a result bitmap 25. Both the column bitmap 23 and the result bitmap 25 comprise a number of bits that corresponds to the number of rows in database table 2. The object bitmap column 23 is to indicate, during each iteration through column 4 and the corresponding input value 6, indicated in the incoming request 9, the rows 3 of the database table which include the value of enter e respective. The object of the result bitmap 25 is to indicate, through the processing of the incremental request, the remaining rows 3 of the database table which are still candidate rows possibly filling all the input values 6 in the request. incoming 9 and, at the same time, indicate all the rows 3 of the database table 2 that have been filtered because they do not correspond to one or more input values 6.

The processing of the request starts with the initialization of the bitmap result 25, e.g. set all the bits of the bitmap result 25 to "1", while each "1" indicates that the row 3 associated with the respective bit in the result bitmap 25 has not yet been filtered, ie it is still a candidate row that eventually fills all the input values 6 included in the incoming request 9. Therefore, at the beginning of the request processing, all rows 3 of the database table are valid candidates.

Then, the first iteration concerning the first column and the respective input value 6 (in the example of FIGS. 2 and 4: column 4B with input value 6B = "A") is traversed. It consists of two activities using the respective index structure (here: index structure 11 B). The first activity concerns the determination of the rows 3 of the database table 2 which fill the current input value 6B. The second activity is the counting of remaining candidate rows maintained across all iterations.

Concerning the first activity, the column bitmap 23B is initialized with the bit values of the no-value bitmap 13 of the column 4 considered during the current iteration (here: column 4B, bitmap with no value 13B). Thus, in the example, the column bitmap 23B is set to 1-0-0-0-0-0 and therefore indicates that row 3A (key value RI) must absolutely be maintained (because it includes a character filling in column 4B). Then, the set of pointer tuples 12B is searched for all rows including the input value "A". In some embodiments, the search is a binary search (explained further below in Figure 8). In other embodiments, the search is a linear search. In the example, searching in a set of pointer tuples 12B indicates that the rows with key values R2, R4 and R6 include an "A" in the currently contemplated column 4B. The bits in the column bitmap 23B corresponding to the rows that have been determined to include the input value 6B are therefore set to "1", since they fill the first input value 6B and therefore must be maintained. Therefore, in the example, the second, fourth and sixth bits of the column bitmap 23B are set to "1", the column bitmap 23B is now set to 1-1 -0-1 -0-1; which means that the first, second, fourth and sixth rows (key values RI, R2, R4 and R6) are always candidate rows while the third and fifth rows (key values R3 and R5) are filtered. At this point, the column bitmap 23B indicates, for the current iteration, that all the rows which fill the first input value 6B are included in the incoming request 9.

For the second activity, the established column bitmap 23B is associated with the current version of the result bitmap 25 to include the row-determination result of the current iteration in the global accounting of the candidate rows. In the example, all the remaining candidate rows are indicated by bits set to "1", while all the filtered rows are indicated by bits set to "0". Therefore, a bitwise logical AND operation is performed between the column bitmap 23B and the current version of the result bitmap 25, derived from a version 25B of the updated result bitmap. In the example, version 25B of the update result bitmap is set to 1-1-0-1-0-1.

This concludes the first iteration concerning the first column indicated in the incoming application 9 and the corresponding input value 6. The following iterations are performed in the same way. Once again, during each subsequent iteration, the column bitmap 23 is reinitialized with the bit values of the respective bitmaps with no value (in the example, the bitmaps with no value 13C to 13F, the initialization versions 23C to 23F of the bitmaps columns). Next, occurrences of the respective input values included in the incoming request 9 (in the example, input values 6C to 6F) are searched for in the respective set of pointer tuples (in the example, sets 12C to 12F). The respective bits corresponding to the rows including the input value 6 are set to "1" in the column bitmap 23. The respective resulting version 23C-23F of the bitmap column is associated with the respective current version 25C-25F of the result bitmap. by bitwise AND operation.

In the example, the final version of the result bitmap 25F indicates that the first row, the second row and the sixth row fill all the input values 6 included in the incoming request 9. The last activity of the request processing concerns the selecting the most specific row from the remaining rows after the end of the iterations. For this purpose, the indication of the order of specificity in the index 10 is used. In the example, the order of specificity is given by the sorting of rows 3 of database table 2 which is reflected in the sequence of bits (corresponding to the rows) in the bitmaps 13 with no value, in the bitmap column 23 and in the result bitmap 25. Thus, in the example, the most specific row among the remaining candidate rows is given by the rightmost "1" (reference number 27) in the final version 25F of the result bitmap.

Although the processing of the request involves a number of O (n) complexity operations, it has many advantageous technical characteristics. Limited memory space is sufficient to execute the operations. The two additional bitmaps, the column bitmap 23 and the result bitmap 25 comprise a number of bits which corresponds to the number of rows in database table 2. Therefore, for a database table with eg. 1024 rows, the 23 column bitmap and the 25 bitmap result have a size of 128 bytes each. In addition, the processing of the request is deterministic because the number of column iterations of the database is predetermined by the number of columns of the database table and columns indicated in the request, respectively. Therefore, for database tables with a number of rows, the response time for each request processing is deterministic.

In addition, the number of search operations and value compare operations (comparing the input values to the values referenced by the respective first pointers) to search for sets of pointer tuples 12 in the presence of the values of Input 6 is reduced in favor of bitmap operations (such as bit-to-bit logical AND operations). Although bitmap operations involve operations O (n), n is relatively small (corresponds to the number of rows 3) and the bitmap operation generally exploits fully the capabilities of modern computer hardware. For example, the individual assembly instructions for 64-bit architectures process 64 bits at a time. In addition, the processing of the present application is specifically adapted to CPUs equipped with OOO (out-of-order) computer units which have the ability to perform multiple calculations per clock cycle on a single kernel, to provided that there is no dependence between these calculations. The last condition applies the bitmap operations because each individual AND bitwise operation in a general AND operation between the column bitmap 23 and the result bitmap 25 is independent. Reducing the share of search and search operations to the benefit of an increased share of bitmap operations specifically relates to a CPU vector extension arrangement. CPUs equipped with a set of SSE2 instructions (SIMD continuous extensions, SIMD = one instruction, multiple data) include the ability to process 128 bits into an assembly instruction, an AVX2 instruction set (Advanced Vector Extensions, Advanced Vector Expansion) to process 256 bits into an assembly instruction or AVX-512 (eg Intel's "Knights Landing" generation) allowing 512-bit processing into an assembly instruction. For example, with the last set of instructions, a bitwise AND operation between the column bitmap 23 and the result bitmap 25 for a database table 2 with 1000 rows can be performed in two CPU cycles.

The operation of this request processing is illustrated in the graph of Fig. 6. First, at 20, the computer system hosting the database 1 receives an incoming request 9. In response to receiving the request, the result bitmap 25 is initialized to 22. Thus, the incremental process 24 is performed. In the column-by-column iteration for each column and respective input value 6 indicated in the incoming request 9, the column bitmap 23 is initialized to 24A, based on the respective bitmap 13 with no value. Then, at 24B, the set of pointer tuples 12 is searched for all rows 3 of the current column 4 which include the respective input value 6 and the column bitmap 23 is updated accordingly. Then, at 24C, the column bitmap 23 and the current version of the result bitmap 25 are associated, e.g. by bitwise AND logic operation to obtain an updated bitmap result. Once all the columns 4 and the respective input values 6 indicated in the incoming request 9 have been processed in this incremental manner, the most specific row among the remaining rows indicated in the final version of the result bitmap 25 is selected. 26. Finally, at 35, at least one value of the most specific row determined is returned. It is also possible that the result bitmap contains only "0" bit after the last iteration of the request processing. In this case, none of the rows in the database table fills the request, so the return value is a "non-match" value.

In some embodiments, the assignment of bits in the valueless bitmaps 13 is inverse (compared to the example of FIG. 4), ie the bits set to "0" designate all the rows in the respective column with no value (that is, with wildcards) while the bits set to "1" refer to rows in the respective column with values (ie without wildcards). In these embodiments, the bit assignment in the column bitmap 23 and the result bitmap 25 is reversed, ie all bits set to "0" in the column bitmap 23 indicate the rows 3 of the column considered which include the respective input value 6 and each "0" in the result bitmap 25 indicates that row 3 associated with the respective bit has not yet been filtered, ie it is still a row candidate which potentially fulfills all the input values 6 included in the incoming request 9. Therefore, in these embodiments, the column bitmap 23 and the result bitmap 25 are associated by a bitwise OR logical operation.

In some embodiments, the processing of the incremental request (activity 24 in FIG. 6) and in particular the search of the sets of pointer tuples 12 for checking the presence of an input value (activity 24B in FIG. 6) includes a binary search within the pointer tuples 14 stored adjacently in a memory of the computer system hosting the database 1 (FIGS. 7 and 8). Figure 7 provides a generic example of pointer tuples 14 which are stored adjacent to a location in the memory 28 of the computer system hosting the database 1. As shown schematically in Figure 7, each pointer tuple 14 is consecutively disposed in memory 28 in a set of pointer tuples 14 without holes between. This arrangement of the pointer tuples 14 in the memory 28 facilitates direct access to the nth pointer tuple (ie any arbitrary pointer tuple with the set 12) and thus facilitates a binary search for each column-by-column iteration. the incoming demand 9.

FIG. 8 is a generic example of a binary search for the activity 24B of FIG. 6. For example, as mentioned above in FIG. 4, the pointer tuples 14 in the set 12 are sorted by the values referenced by the first pointers 15 (which sort for the respective data types in column 4, eg alphabetical order for characters and strings). This allows the execution of a binary search on the pointer tuples 14. In accordance with the principle of "divide and conquer", the binary search algorithm enters the middle of the set 12 and examines whether the value referenced by the first pointer 15D of the pointer tuple 14D located in the middle of the set 12 or not corresponds to the input value 6. In the example of Figure 8, the input value "A" is compared to the value " D "referenced by the first pointer 15D. If the input value 6 is smaller than the value referenced by the first pointer 15 considered, the same procedure is repeated in the upper half (left half of a set 12 in Fig. 8, ie with the first pointer 15B). If the input value 6 is higher than the value referenced by the first pointer 15 considered, the same procedure is repeated in the lower half (right half of a set 12 in Fig. 8, ie with the first pointer 15B).

As shown in the examples of FIGS. 4 and 5, it is possible that the first multiple pointers 15 refer to the same value. In the example of FIGS. 7 and 8, the first pointers 15A and 15B both refer to the value "A". If the comparison between the input value 6 and the value referenced by the first pointer 15 currently considered at a particular stage of the binary search shows that the two values are equal, the binary search is not yet complete at this stage. The binary search continues to determine other possible pointer tuples 14 and the first pointers 15 which also refer to the input value 6. Therefore, after finding a match between the input value 6 and the referenced value by a first pointer 15, the neighboring pointer tuples 14 to the left and right of the currently considered pointer tuple (to the extent that they are present) are examined until there is a mismatch between input value 6 and the value referenced by the respective first pointer is determined or until the algorithm arrives at a pointer tuple 14 already considered before. In the example of FIG. 8, the examination of the first pointer 15B (which is carried out after the examination of the first pointer 15D) generates a correspondence between the input value "A" and the value "A" referenced by the first pointer 15B. In this situation, it is then determined whether the first pointers 15A and 15C also refer to the value "A" or not. The answer is affirmative for the first pointer 15A and negative for the first pointer 15C. Therefore, the binary search in the example of Fig. 8 ends after the value "A" has been found as present in the rows R1 and R4 of the column 4 under consideration. The first pointers 15D, 15B, 15A and 15C were checked during the execution of the binary search.

The binary search used by some embodiments has the computational complexity of O (log n) and is therefore generally more efficient than eg. a linear search of complexity of O (n). In some embodiments, the binary search is implemented recursively. In some embodiments, the binary search is implemented iteratively.

In some embodiments, the computer system hosting the database 1 is arranged to generate the index 10 from the database table 2. The index 10 generated after the database table 2 has been established for the first time then thereafter, in response to a change in the database table 2 such as a change of one or more values in the cells 5, the replacement of one or more values by a character of replacement and vice versa, add or delete a row 3 or column 4, etc.

In general, the index generation comprises the establishment of an index structure 11 for each column 4 of the database table 2 for which the incoming requests 9 may include input values 6. Corresponding to the index structure 10, this process mainly comprises two activities, namely the initialization and the establishment of valueless bitmaps 13 of each index structure 11 and the establishment of a set of pointer tuples 12 with the first one. respective pointer 15 and the second pointer 16 in the pointer tuples 14.

Figure 9 is an example of index generation. Optionally, for embodiments with an explicit or implicit order of specificity given by sorting the rows 3 of the database table 2 according to the order of specificity, the rows of the database table 2 are sorted to 38 (if this has not been done beforehand). In general, sorting the rows of the database table depends on the number of cells in each row 3 without value (eg with wildcards) and / or the specificity of the values in cells 5 of row 3 More specifically, in some embodiments, the rows 3 of the database table 2 are weighted. Each cell contributes weight to a row in which a worthless row adds less weight than each cell with at least one value and, in some more specific embodiments, cells with a higher number of values / values more Specific ones add less weight to the row than cells with a smaller number of values / less specific values. The sequence of rows with identical weighting values is chosen arbitrarily. In some embodiments, the indication of the order of specificity is given by a single row indicating the sorted rows, such as in the example of Figure 2 (column 4A). This row order can function as a primary key of database table 2.

The actual index generation then begins with the initialization of the first valueless bitmap 13 to which an incoming request 9 can be returned (eg bitmap 13 linked to column 4B, referring to the example of FIG. 4). The initialization of the bitmap is eg. related to the allocation of the required amount of memory eg. in the main memory of the computer system hosting the database 1 and e.g. setting all bits in bitmap 13 to "0" by initially not indicating any cells in column 4 without a value. Then, at 40, all of the pointer tuples 12 (eg, set 12B of Fig. 4) are filled with the pointer tuples. A pointer tuple 14 is added to the set 12 for each value appearing in the rows 3 of the column 4 in question. At 41, the valueless bitmap 13 is updated to reflect all cells in the valueless column. For example, all bits corresponding to invalid cells are set to "1". Optionally, at 42, the pointer tuples 14 in the set 12 are sorted by the values referenced by the respective first pointers. At this point, the index structure 11 for the first column (i.e., the index structure IB in the example of Fig. 4) is integrally generated. At 43, it is checked whether or not the database table 2 has another column for which an index structure 11 is to be established. If the answer is affirmative, activities 39 to 42 are repeated for this other column 4 (eg column 4C in the example of Figure 4) in the same way, until the index structures 11 have been generated for all columns 4 of the database table that can be specified in an incoming request 9.

Optionally, in tri-sorted non-row embodiments (e.g., activity 38 was not executed), a set of weighting values 7 explicitly indicating the order of specificity of rows 3 is set to 44. In embodiments that allow multiple rows to share the same weighting value and where multiple rows of an identical weight correspond to the incoming request 9, or an arbitrary row among the rows with the same weight is selected as the row more specific either a mechanism is present to allow only disjoint value associations for rows with the same weight, with the result that only one row at a certain level of weighting corresponds to an incoming request 9.

Fig. 10 is an example of the high-level flow of a general process performed by the computer system hosting the database 1 with at least one database table 2. At 17, the rows of the database table Sort to form the order of row specificity reflected in the index 10. At 18, the index 10 is generated (see example in Figure 9). Later, an incoming request 9 is received by the computer system, the request indicates at least one input value 6 for a column 4 of the database table 2. At 19, the request is processed on the basis of the index 10 to determine all the rows of the database table 2 that correspond to the input value (s) of the incoming request 9, e.g. by activity 22 and incremental activity 24 shown in FIG. 6. At 34, the most specific row is selected from the remaining rows which are the output of activity 19 using the order of specificity reflected in FIG. index 10, for example in the manner of activity 26 shown in FIG. 6. At 21, one or more values of the most specific row selected is / are returned (s).

The arrangement of the various data of the database table 1 in the memory of the computer system 100 hosting the database 1 is shown in FIG. 11. The computer system 100 has an addressable memory 30 which comprises e.g. the main memory or the operating memory (RAM) of the computer system 100. The computer system 100 keeps the database table 2 in the addressable memory 30, in some embodiments in the RAM. The processing of the request and the determination of the most specific row are performed by the central processing unit (CPU) 31. The CPU 31 comprises at least one processor cache level 32, in some embodiments at least three levels (LI cache, L2, cache, L3) of different sizes and access speeds. The index 10 with the index structures 11 for the columns 4 of the database table 2 is also in the addressable memory 30 of the computer system 100, in some embodiments in at least one of the cache levels of processor.

The implementation of the index presented in this document is superior to the other index mechanisms in terms of memory / compactness requirements, as will be the case from the following comparison with ultramodern index implementations. The comparison is based on a database table 2 with 1024 rows and five columns that can be submitted to an incoming request 9 with arbitrary values. The database table used for the comparison includes the standard reports of the number of cells with no value of 66%, the number of cells with more than a value of 10% and an average size of the values. The same database table 2 is used for the compared implementations. The implementation of indexes presented in this document is compared to two other known ways of indexing the rows of the database table. - Black red trees are a known associative data structure for indexing. The implementation is based on the C ++ std: map, provided with GCC 4.3.2 STL. - B trees are another associative data structure for indexing. They are used to improve the locality of the data in a memory or on a disk. The implementation is based on "klib" by attractive chaos which is known for its good performance (see https: //github.eom/attractivechaos/klib/blob/master/kbtree.h). An aggregation factor of the 256 elements that is a good compromise between efficiency and compactness was chosen.

The three approaches showed the following memory footprint (1 precision byte) for the different indexes (all values are in bytes).

Red trees

Index 10 black trees B

Index structure of column 1 13824 94720 51040

Index structure of column 2 13984 93504 50240

Index structure of column 3 11936 88320 48400

Index structure of column 4 13040 91776 50400

Index structure of column 5 13104 91968 50080

Total 65888 460288 250160

The size of the LI cache of the current ultramodern Intel CPU is 32 KB. Thus each index structure of the index 10 as presented in this document for a database table 2 with 1024 rows and more enters the LI cache of this size, whereas this is not the case for the stakes. Black Red Trees and B Trees.

The size of an L2 cache currently available is 256 KB. Thus each index structure of the index 10 as presented in this document for a database table 2 with 1024 rows and more enters the L2 cache of this size, whereas this is not the case for the stakes. Black Brees and Trees B. Although the T-tree-based index for a database table 2 with 1024 rows fits into the L2 cache of this size, there is virtually no space left in the cache. the L2 cache for the values of the database table 2 and the accounting data structures such as the column bitmap 23 and the result bitmap 25.

While the complete index metadata and the complete database table 2 go into the L3 cache (several MOs, depending on the CPU model) for the three index implementations compared above, it should be noted that the L3 cache is shared between the CPU cores and is subject to overhead synchronization. Access to the L3 cache is therefore considerably slower in general than access to the LI cache (typically 10 to 20 times slower) and slower than access to the L2 cache (typically 4 to 8 times slower ). Thus, the memory compactness inherent in the index 10 presented in this document makes it possible to maintain the full index or at least a significantly higher portion of the index (compared to the other two known index implementations mentioned above). in the LI cache and / or in the L2 cache which is a very enhanced performance of the request processing mechanism for determining the most specific row of the database table 2 corresponding to the incoming request 9. The index 10 and the request processing mechanisms based on the index 10 presented in this document can be applied to all kinds of different databases and database type systems, for example a router with a routing table. FIG. 12 shows a routing table 33 of an IP router (ie a router at the network layer of the OSI reference model) but the present index 10 is equally applicable to any other type of router or any type of more specific router such as logical routers and software routers (eg Enterprise Service Busses, ESB), hardware and backbone routers, high-end switches, DSL routers, WiFi routers, etc.

The routing table 33 of Figure 12 is a simple example of a database table 2 that has five rows and five columns. Columns, from left to right, define the destination address, the subnet mask, the next hop (eg the next router), the router's output network interface, and a metric indication. As known to the person skilled in the art, the destination address and the subnet mask together form a network address (the subnet mask indicates the prefix bit range that constitutes the network address while the bits The incoming IP packets to be routed to a destination form the incoming requests 9. The router examines the destination IP address of an incoming IP packet and compares it to the routing table 33. In this regard, the router determines the most specific row of the routing table 33 with a network address (i.e., a destination address in the first column covered by the subnet mask in the second column) including the destination IP address of the incoming IP packet An index 10 with at least one index structure 11 representing the addresses of the destination network (consisting of the destination address of the first column covered by the subnetwork in the second column of the routing table 33) and the request processing described in detail above are used to determine the most specific row corresponding to the destination IP address in an incoming request. For example, an IP packet with a destination address of 192.168.1.23 is recognized as being directed to the 192.168.1.0/24 network (24 = subnet mask 225.225.225.0), ie the fourth row is the most specific row of the routing table 33 corresponding to this incoming request 9. On the other hand, for an IP packet with a destination number 123.123.123.123, the first row of the routing table 33 specifying the route standard will be determined as the most specific row of routing table 33 corresponding to this incoming request 9. Therefore, this IP packet will be routed to the next hop 192.168.1.1 via the 192.168.1.2 output network interface. Index 10 and demand-response mechanisms based on the index 10 presented in this document are also applicable to other databases or database-like systems, such as firewalls with data tables. filtering (eg packet filters with or without state inspection, proxy filter, content filter), production engines, rule engines, (eg repair repositories specifying repair procedures for any type of technical device error symptoms), streaming engines, transaction verification engines, etc.

Therefore, the computer system 100 is, for example, a network node hosting a firewall, in which case the database table 2 is a filter table, the incoming request 9 is an incoming data packet, and each row The filter table is a filtering rule to allow or prevent the incoming data packet from being routed to a destination. The values of the incoming data packet (eg an IP packet carrying a TCP or UPC segment that carries a packet of application layers such as an HTTP request) such as a destination IP address, source port addresses and destination and the characteristics of the data packet, such as whether or not the data packet belongs to an existing connection, are checked against the filtering rules defined by the rows of the filtering table. The filtering table comprises e.g. at least one destination column with possible destination addresses (such as IP addresses and / or port addresses), e.g. one or more source columns with possible source addresses (such as IP addresses and / or port addresses), e.g. one or more columns with values specifying the characteristics of the incoming data packet (such as "established" referring to packets belonging to an established connection) and a column with Boolean values indicating whether the incoming data packet should be forwarded or discarded . The most applicable (ie the most specific) filter rule (ie, row) is determined based on the input values 6 in the data packet and the corresponding value of the last column mentioned. (ie yes or no = accept or reject) is returned.

In the case where the computer system 100 is, for example, a rule engine, the database table 2 is a rule table and each row of the rule table is a rule for responding to the request. The columns in the rule table define the criteria for the rules. The input values 6 of the request that define particular rule criteria are checked against the rule table, the most specific rule conforming to the input values 6 is determined, and the requested return values of the row more specific specific from the rule table are returned.

Finally, Fig. 13 is a schematic representation of a computer system 100 that provides the functionality of the database 1 with at least one database table 2. The database 1 may comprise a set of instructions for bringing a database the computer system to execute any method or activity performed by the database table 1 as elaborated above. The computer system 100 comprises a processor 101, a main memory 102 and a network interface device 103 which communicate with each other via a bus 104. The processor 101 comprises at least one CPU cache containing at least a portion of the index 10 as shown in Fig. 11 and Fig. 13. The main memory 102 includes the database 1 (ie the executed software implementing the database system as well as a database table). 2 at least) and, optionally, parts of the database table 2 are also maintained in the CPU cache of the processor 101. Optionally, the computer system 100 may further include a static memory 105 and a drive unit. A video screen 107, an alphanumeric input device 108, and a cursor control device 109 form a human-machine interface for operating the computer system 100. The interface device network 103 is a wired and / or wireless interface that connects the database 1 to any number and type of devices and client applications sending incoming requests 9 to the database 1. The client may reside on the Internet and / or any other network. The network interface device 103 uses either standard communication protocols such as an HTTP / TCP / IP, IEEE 802.11 protocol stack and / or proprietary communication protocols. An instruction set (ie software) 100 embodying all or all of the methodologies described above resides entirely or at least partially in or on a machine-readable medium, e.g. the main memory 102 and / or the processor 101 with at least one CPU cache. Among others, the instructions can implement the functions of the database 1 to process the incoming requests 9, to determine the most specific row 3 of the database table 2 corresponding to an incoming request 9, such as shown in FIG. 6, as well as the index generation of FIG. 9. A machine-readable medium on which the software 110 resides may also be a nonvolatile data carrier 111 (for example a non-removable magnetic hard disk or an optical or magnetic removable disk) which is part of the disk drive unit 106. The software 110 may further be transmitted or received as a signal 112 propagated via the Internet through the network interface device 103.

Although some products and methods constructed in accordance with the teachings of the invention have been described herein, the scope of coverage of this patent is not limited thereto. On the contrary, this patent covers all the embodiments of the teachings of the invention which fall within the scope of the appended claims either literally or under the doctrine of equivalents.

Claims (17)

1. A method of determining the most specific row in a database table maintained by a computer system, the database table consists of a plurality of rows and a plurality of columns, rows and the columns of the database table form cells, each cell includes at least one value or no value; the computer system also maintains an index for the database table; each index includes a respective index structure for each column of the database table; each index structure comprises a respective set of pointer tuples for each value appearing in the respective column and a bitmap in which each pointer tuple comprises a first pointer indicating one of the values that appears in the column and a second pointer indicating the row. of the database table in which the value appears, and where the bitmap indicates cells in the respective column with no value; the index indicates an order of specificity of the rows of the database table; the method comprises: - receiving by the computer system a request indicating at least one column of the database table associated with a respective input value; incrementally, for each column, the computer system: uses the bitmap of the index structure for the column to maintain all the rows of the database table that do not contain any value in the cell of the column considered, and - uses the pointer tuple of the index structure so that the column filters all the rows of the database table that do not understand the respective input value, - the selection, by the computer system, from the remaining rows from the top row in the order of specificity; - returning, by the computer system, the value of at least one cell of the determined row. 2. The method of claim 1 further comprises: - in response to the receipt of the request, the initialization of a result bitmap indicating the remaining rows; in which the use of the pointer tuples and the bitmap of the index structure for each column indicated in the request includes: - the establishment of a column bitmap indicating all the rows that fill the respective input value for the respective column, and - updating the result bitmap by associating the result bitmap and the column bitmap. The method of claim 1 wherein the respective set of pointer tuples is contiguously stored in a memory of the computer system. 4. The method of any one of claims 1 to 3, wherein the use of the pointer tuples and the bitmap of the index structure for each column indicated in the request further comprises performing a binary search. on the respective set of pointer tuples. 5. The method according to any of claims 2 to 4 wherein all the rows that fill the respective input value are indicated by a "1" in the column bitmap, all remaining rows are indicated by "1" in the result bitmap and the association of the result bitmap and the bitmap column includes a bitwise AND operation; 6. The method according to any one of claims 1 to 5 further comprising: - the generation of the index by: - the initialization of the bitmap indicating all the cells in the respective column without value, - the addition of a pointer tuple to the set of pointer tuples of the respective index structure for each value in the column, - updating the bitmap of the respective index structure to reflect all the valueless cells. The method of claim 6 wherein the index generation further comprises: sorting the pointer tuples of each index structure by the value designated by the first pointer. The method according to any one of claims 1 to 7 wherein the indication of the order of row specificity of the database table is performed by sorting the rows of the database table according to the number of rows of the database table. cells in each row with no value and / or a specificity of the values in the cells of the row. The method of claim 8 wherein the indication of the order of specificity is given by a single row order indicating the sorted rows. The method of any one of claims 1 to 7 wherein the indication of the specificity is given by weighting values included in the index of the database table. The method of any one of claims 1 to 10 wherein the computer system is a router, the database table is a routing table, each row of the routing table constitutes a routing rule for routing a request. Inbound to a destination, the routing table includes a destination column with possible destination values and a routing column with corresponding values indicating routing to the destination. The method of any one of claims 1 to 10 wherein the computer system is a firewall, the database table is a filter table, the request is an incoming data packet and each row of the table filter is a filtering rule for allowing or preventing the incoming data packet from being transmitted to a destination, where the filtering table comprises at least one destination column with the possible destination addresses, at least one column with values specifying the characteristics of the incoming data packet and a column with Boolean values indicating whether the incoming data packet should be transmitted or rejected. The method of any one of claims 1 to 10 wherein the computer system is a rules engine, the database table is a rules table, each row of the rules table is a rule for responding to the request. , the columns of the rule table define the rule criteria. The method of any one of claims 1 to 13 wherein the index is stored in a processor cache of the computer system and remains stored in the processor cache after the value of at least one cell of the determined row. has been returned to be available for other treatment requests. 15. A computer system for determining the most specific row in a database table maintained by the computer system, the database table consists of a plurality of rows and a plurality of columns, rows, and columns of the database table form a cell, each cell includes at least one value or no value; the computer system also maintains an index for the database table; each index includes a respective index structure for each column of the database table; each index structure comprises a respective tuple of pointers for each value appearing in the respective column and a bitmap in which each tuple of pointer comprises a first pointer indicating one of the values that appears in the column and a second pointer indicating the row of the database table in which the value appears, and where the bitmap indicates cells in the respective column with no value; the index indicates an order of specificity of the rows of the database table; the computer system is configured to: - receive a request indicating at least one column of the database table associated with a respective input value; - incrementally, for each column indicated in the request: - use the pointer tuples of the index structure so that the column filters all the rows of the database table that do not understand the respective input value, and - use the bitmap of the index structure for the column to maintain all the rows in the database table that do not contain any value in the cell of the column in question; - select, from the remaining rows, the top row in the order of specificity; - return the value of at least one cell of the determined row. The computer system of claim 15 is arranged to carry out the method of any one of claims 2 to 14. A computer program comprising program code instructions for performing the steps of the method of claims 1 to 14 when said program is run on a computer.