US5870747A - Generalized key indexes - Google Patents

Generalized key indexes Download PDF

Info

Publication number
US5870747A
US5870747A US08/677,490 US67749096A US5870747A US 5870747 A US5870747 A US 5870747A US 67749096 A US67749096 A US 67749096A US 5870747 A US5870747 A US 5870747A
Authority
US
United States
Prior art keywords
index
query
relational database
tables
cust
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
US08/677,490
Inventor
Prakash Sundaresan
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
Informix Software Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Informix Software Inc filed Critical Informix Software Inc
Priority to US08/677,490 priority Critical patent/US5870747A/en
Priority to AU28361/97A priority patent/AU713109C/en
Priority to MXPA/A/1997/005043A priority patent/MXPA97005043A/en
Priority to JP18194797A priority patent/JP4132136B2/en
Priority to CA002209978A priority patent/CA2209978A1/en
Priority to BR9703939A priority patent/BR9703939A/en
Priority to EP97305022A priority patent/EP0818743A3/en
Assigned to INFORMIX SOFTWARE, INC. reassignment INFORMIX SOFTWARE, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: SUNDARESAN, PRAKASH
Application granted granted Critical
Publication of US5870747A publication Critical patent/US5870747A/en
Assigned to INTERNATIONAL BUSINESS MACHINES CORPORATION reassignment INTERNATIONAL BUSINESS MACHINES CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: INFORMIX CORPORATION AND/OR INFORMIX SOFTWARE INC.
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28Databases characterised by their database models, e.g. relational or object models
    • G06F16/284Relational databases
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22Indexing; Data structures therefor; Storage structures
    • G06F16/2228Indexing structures
    • G06F16/2237Vectors, bitmaps or matrices
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99941Database schema or data structure
    • Y10S707/99942Manipulating data structure, e.g. compression, compaction, compilation

Definitions

  • the invention relates generally to relational database systems, and more particularly to indexing in relational database systems.
  • a relational database As a collection of tables, each of which arranges data for items and item attributes in rows and columns: a table row corresponds to an item (referred to as a record); a table column corresponds to an attribute of the item (referred to as a field).
  • a table record can generally be identified by a record identifier (RID), indicating the page and offset within the page where the record is stored.
  • RID record identifier
  • FIGS. 1-3 illustrate examples of tables in a relational database. Data stored in the tables can be accessed using indexes such as those illustrated in FIGS. 4-6, which aid in accessing data by providing a logical ordering of the table records.
  • FIG. 4 illustrates a conventional index 400 on the CUST table 100 of FIG. 1, using the customer name 410a as the index key. Index 400 provides an alphabetical ordering of the records of CUST table 100 by customer name 120, and associates each name 410a with record identifiers 410b for table records having the customer name in their cust -- name field 120.
  • a query for phone numbers of customers named Smith would normally be processed by searching index 400 for an entry having the key value "Smith" 440a, using the associated record identifier 440b to retrieve a record in CUST table 100, and extracting data in the cust -- phone field 140 of the retrieved record. Because index 400 is ordered by customer name, the index search is faster than the linear search of CUST table 100 that would be required without an index. Indexes may be implemented using various methods such as B-Trees and hash functions.
  • index entries generally have two attributes: an index key value, and record identifiers of table records.
  • An index key generally is a field or a combination of fields from a table, and each index entry associates a key value with record identifiers of table records.
  • index 400 of FIG. 4 is an example of a single-table index.
  • FIG. 7 illustrates an example of a "virtual column" index, created by defining the index key as an expression using one or more fields of a table record. For example, to order the records of the order table ("ORD table") of FIG. 2 by price including discount, a virtual column index is created using the index key (ORD.price-ORD.discount).
  • FIG. 8 illustrates an index associating values for ORD.date only with record identifiers of table records having a price of at least $50,000.00.
  • an index may also be multi-table, using fields from a first table in its index key, and associating index key values with record identifiers of records of a second table.
  • Multi-table indexes are generally referred to as join indexes.
  • FIGS. 4-6 together illustrate an implementation of an index for retrieving index records based on customer name, created on the ITEM table 300 (FIG. 3), using the name field 120 from the CUST table 100 as an index key (CUST.cust -- name).
  • this index has three levels.
  • the first level (index 400, FIG. 4) associates values for CUST.cust -- name 410a with record identifiers of records of the CUST table 410b;
  • the second level associates values for CUST.cust -- no 510a with record identifiers of records of the ORD table 510b having the same value for ORD.cust -- no;
  • the third level associates values for ORD.ord -- no 610a with record identifiers of records of the ITEM table 610b having the same value for the ITEM.ord -- no.
  • Indexes 400-600 aid in retrieving item records corresponding to a customer name. For example, to retrieve item records for a customer Smith, index 400 is used to retrieve the CUST.cust -- no (1002) of the CUST records corresponding to Smith (002); index 500 is used to retrieve the ORD.ord -- no (002, 003) of the ORD records (101, 102) corresponding to the CUST.cust -- no (1002); and finally, index 600 is used to retrieve the ITEM records (201, 202, 203) corresponding to the ORD.ord -- no (002, 003).
  • a conventional index associating key values of fields of a first table with record identifiers of records of a second table generally has more than one level, as illustrated by FIGS. 4-6.
  • indexes require more memory space than single-table indexes.
  • Another consequence of having multiple levels is that more processing is required to handle queries. For example, retrieving item records corresponding to a customer name "Smith" requires multiple processing steps.
  • the invention features a computer-implemented method for creating an index for a first table in a multi-table relational database based on an index key and index conditions by determining index key values, wherein if the index key references tables other than the first table, the method further comprises retrieving data from the other tables to determine the index key values; associating each determined index key value with record identifiers of records of the first table satisfying the index conditions, wherein if the index conditions reference tables other than the first table, the method further comprises retrieving data from the other tables to determine the associated record identifiers; and storing the index key values and the associated record identifiers in an index.
  • Embodiments of the invention may include one or more of the following features.
  • the index key references at least a second table and a third table.
  • the index conditions reference at least a second table and a third table.
  • the index key is an expression referencing at least a second table.
  • the invention features a computer-implemented method for creating an index for a first table in a multi-table relational database based on an index key by determining index key values, wherein the index key comprises an expression referencing at least a second table; associating each determined key value with record identifiers of the records of the first table; and storing the index key values and the associated record identifiers in an index.
  • the invention features a computer-implemented method for determining the applicability of an index for processing a query in a multi-table relational database, wherein the index indexes an index table based on an index key and index conditions, the query is based on query conditions referencing a set of query tables, and each of the tables are tables of the multi-table relational database.
  • This method comprises determining whether the index table is one of the query tables; determining whether the index conditions are less or equally restrictive as compared with the query conditions; and determining the index to be applicable for processing the query if the index table is one of the query tables and the index conditions are less or equally restrictive as compared with the query conditions.
  • Embodiments of the invention may include a method in which determining whether the index conditions are less or equally restrictive as compared with the query conditions comprises determining whether each index condition is satisfied by at least one query condition.
  • the invention features a computer-implemented method of processing a query on a set of query tables in a relational database by retrieving an index comprising index entries having index key values and associated record identifiers of records of a first query table in the set of query tables, wherein the association between index entries and associated record identifiers is based on at least a second query table and a third query table in the set of query tables; determining an index key value based on the query; determining an index entry corresponding to the determined index key value; and retrieving records of the first query table based on the associated record identifiers of the determined index entry.
  • the invention features a computer-implemented method of processing a query on a set of query tables in a relational database by retrieving an index comprising index entries having index key values and associated record identifiers of records of a first query table in the set of query tables, wherein the index key values are based on an expression referencing at least a second query table in the set of query tables; determining an index key value based on the query; selecting an index entry corresponding to the determined index key value; and retrieving records of the first query table based on the selected index entry.
  • the invention features an index stored on a processor-readable medium, for enabling a programmable processor to order records of a first table of a multi-table relational database based on an index key and index conditions, the index comprising index key values and associated record identifiers for records of the first table satisfying the index conditions, where at least one of the index key and the index conditions reference a second and a third table of the multi-table relational database.
  • the invention features an index stored on a processor-readable medium, for enabling a programmable processor to order records of a first table of a multi-table relational database based on an index key, the index comprising index key values and associated record identifiers for records of the first table, where the index key is an expression referencing at least a second table of the multi-table relational database.
  • the advantages of the invention include one or more of the following.
  • the generalized key indexing system may be implemented in a single level, achieving efficient storage and enabling efficient query processing.
  • the generalized key indexes also enable indexing on a variety of index keys, including, for example, expressions using fields of more than one table.
  • generalized key indexes are flexible enough to encompass a variety of index formats, including conventional single-table indexing.
  • Relational database systems may be readily adapted to create and handle both generalized key indexes and conventional indexes.
  • FIGS. 1-3 illustrate tables of a relational database.
  • FIGS. 4-8 illustrate indexes.
  • FIG. 9 is a flow diagram of a method of creating a generalized key index.
  • FIGS. 10-12 illustrate indexes.
  • FIG. 13 is a flow diagram of a method of determining applicability of a generalized key index.
  • FIGS. 14 and 15 illustrate indexes.
  • FIG. 16 shows the applicability of indexes to given queries.
  • FIGS. 17 and 18 illustrate indexes.
  • FIG. 19 illustrates a programmable processing system.
  • GK indexes encompass conventional indexes--including single-table indexes such as virtual column indexes and partial indexes, as well as multi-table indexes--and enable different techniques used in conventional indexes to be combined in a single index.
  • GK indexes further provide enhanced capabilities to create customized indexes that are efficiently stored and enable efficient query processing.
  • a GK index is created by a user command having the general format:
  • One embodiment creates a GK index from such a statement as if processing a query and storing the results.
  • the general format for creating a GK index may be expressed as the query:
  • GK indexes may be used to create conventional single-table indexes, including virtual column indexes and partial indexes.
  • single-table GK indexes are created by statements such as:
  • the virtual column index 700 discussed above with reference to FIG. 7 may be created by the statement:
  • partial index 800 discussed with reference to FIG. 8 may be created by:
  • GK indexes encompass conventional single-table indexes. GK indexes may also be multi-table. In processing the query corresponding to a multi-table GK index, intermediate tables are referenced in determining the final association of GK index key values with record identifiers of records of the indexed table, but the GK index stores the end results.
  • FIG. 9 is a flow diagram illustrating a method for creating a GK index.
  • Determining associated record identifiers of records of table T for an index key value can reference an intermediate table (one of the tables in the ⁇ other-table-list>) other than T. For example, if a table in the ⁇ other-table-list> is referenced by the index key or in a condition of ⁇ C ⁇ , data from that other table will need to be retrieved. However, whether intermediate tables are referenced, the index stores the result of the mapping, directly correlating an index key value with associated record identifiers of records of indexed table T.
  • FIG. 10 shows a GK index 1000 associating customer names with record identifiers of item records, performing the same function as the indexes of FIGS. 4-6.
  • a command such as:
  • GK index 1000 associates customer names with record identifiers of item records. However, as shown, GK index 1000 has only a single level, directly associating values for customer names from the CUST table with record identifiers of records of the ITEM table, eliminating reference to the ORD table.
  • Conventional multi-table indexes such as the indexes of FIGS. 4-6 have multiple levels referencing intermediate records to associate key values with record identifiers of table records. Not only do multiple levels result in larger memory requirements and slower access times, they also place some limitations on the types of indexes that can be created. For example, conventional multi-level multi-table indexing does not permit an index key to be based on fields of more than one table.
  • GK index 1100 of FIG. 11 may be created as follows:
  • GK index keys can also be created on fields from more than one table. For example, the following command would create GK index 1200 of FIG. 12, associating a combination of a customer name and an order date with record identifiers of the items purchased in that order:
  • the GK index To ensure continuing accuracy of a GK index after data is added, deleted, or altered in a table that was referenced to create that GK index, the GK index must be updated to verify that its entries are still accurate after the data change has occurred.
  • One embodiment reconstructs a GK index when any of the referenced fields are altered, or deletes the GK index if the alteration is incompatible with the GK index (e.g., the field is deleted or changed to an incompatible data type). This method is especially suitable for data warehousing environments, in which data is not frequently updated.
  • a database system uses a GK index to access data by finding the GK index key value in the GK index and following associated record identifiers to the relevant table records. For example, using GK index 1000 of FIG. 10 to find item records for a customer named Smith, GK index 1000 is first searched for an entry for Smith 1030a, and the item records are retrieved by the corresponding record identifiers 1030b.
  • relational database systems To use an index, relational database systems first determine whether that particular index is appropriately used to process a given query.
  • database systems typically have a query optimizer responsible for determining which indexes, if any, are used to process a given query.
  • query optimizers determine whether to use a particular index for a given query by determining (1) whether the index is applicable to the query; and (2) whether the index is optimally used to process the query.
  • FIG. 13 is a flow diagram illustrating the process in one embodiment of determining applicability. If the table T, indexed by GK index GKI, is not one of the tables in the ⁇ query-table-list> (1310), GK index GKI is not applicable to the query (1315). Similarly, if the ⁇ index-condition-list> is more restrictive than the ⁇ query-condition-list> (1320), GK index GKI is not applicable to the query (1315). Otherwise, GK index GKI is applicable to the query (1325).
  • the restrictiveness evaluation (1320) ensures that using the index GKI will not produce incomplete results, which could occur if the index GKI is created on more restrictive conditions than are required by the query.
  • whether the restrictiveness condition is satisfied is determined by evaluating whether each condition in the ⁇ index-condition-list> is satisfied by at least one condition of the ⁇ query-condition-list>.
  • cust -- items index 1000 associates a customer name with record identifiers of item records for items purchased by that customer.
  • cust -- big -- items 1400 associates a customer name with record identifiers of item records for items purchased by that customer in orders having a price of at least $50,000.00. This index may be created by:
  • cust -- many -- big -- items 1500 associates a customer name with record identifiers of item records for items which were purchased in quantities of at least ten, purchased by that customer in orders having a price of at least $50,000.00.
  • This index may be created by:
  • indexes 1000, 1400, and 1500 The applicability of indexes 1000, 1400, and 1500 to queries Q1, Q2, and Q3 is illustrated in FIG. 16.
  • Q1 requests information about all items purchased by Smith. Only index 1000 is applicable because the index conditions of indexes 1400 and 1500 are more restrictive than the query conditions and would not lead to complete results:
  • the condition in index 1400 that ORD.price ⁇ 50,000 is not satisfied by any condition of Q1. Accordingly, index 1400 indicates only items purchased by Smith in orders of at least $50,000.00.
  • Index 1500 includes conditions both that ORD.price ⁇ 50,000 and that ITEM.quantity ⁇ 10, neither of which are satisfied by any conditions of Q2. Thus, index 1500 indicates only items purchased by Smith in orders of at least $50,000.00.
  • index 1500 produces only item 201.
  • Q2 requests items purchased by Smith in orders of at least $60,000.00.
  • Index 1400 is applicable for Q2 because its condition that ORD.price ⁇ 50,000.00 is satisfied by Q2 query condition that ORD.price ⁇ 60,000.00.
  • Index 1500 is not applicable because although its condition that ORD.price ⁇ 50,000 is satisfied, its condition that ORD.quantity ⁇ 10 is not satisfied by any condition of Q2.
  • Index 1400 is applicable for the same reason it is applicable for Q2.
  • Index 1500 is also applicable because the condition that ITEM.quantity ⁇ 10 is satisfied by Q3 query condition that ITEM.quantity ⁇ 25.
  • query optimizers generally determine whether the index is optimally used in processing the query. Although methods of optimization vary among query optimizers, a commonly used method is based on the Selinger optimizer algorithm, discussed in P. G. Selinger et al., An Access Specification Language for a Relational Data Base System, 1979 ACM SIGMOD INT'L CONF. ON MANAGEMENT OF DATA 23-34 (May/June 1979).
  • Selinger algorithm The basic idea of the Selinger algorithm is to enumerate possible execution plans for processing a given query, estimating the cost of each possible plan, and selecting the best plan (the plan having the least cost).
  • ⁇ query-table-list> is the set ⁇ T1, T2, . . . , Tn ⁇ , requires that all of the tables in ⁇ query-table-list> be joined.
  • One possible Selinger optimizer generates plans for all permutations of tables of the query table set and estimates the cost for each permutation by starting with the first table in the permutation and estimating the cost of joining that table with a second table, adding that cost to the estimate of the cost of joining the result of the first join to a third table, and continues joining all tables of the tables set and calculating the accumulated estimated cost.
  • the total cost also considers the cost of incorporating single-table conditions that do not require any joins. This process is repeated for every possible permutation.
  • Indexes can reduce the plan cost. Selinger optimizers generally use indexes to reduce the cost of joining a table, or to reduce the cost of determining a condition on a single table.
  • the table set is ⁇ CUST, ORD, ITEM ⁇ ; the plans include the following possible permutations:
  • Index 1700 of FIG. 17 associates the field ITEM.quantity with ITEM.RID, and is helpful to process the condition ITEM.quantity ⁇ 25. This condition references only the ITEM table, and therefore does not require that any other table be previously joined. Thus index 1700 can be used in each of plans (1)-(6) when the ITEM table is added.
  • GK indexes may be used to adapt Selinger optimizers to incorporate GK indexes into this algorithm. For example, in one embodiment, like conventional single-table indexes, a single-table GK index on a table T will always be considered when that table is joined. Multi-table GK-indexes will be considered when all of the tables referenced in the key-list have already been joined.
  • Query optimizers based on algorithms other than the Selinger algorithm can be similarly adapted to handle GK indexes, although the specific modifications may vary.
  • GK key indexes including b-trees and bit-mapped indexes.
  • the invention is described in terms of a software implementation, the invention may be implemented in hardware or software, or a combination of both.
  • the invention is implemented in a software program executing on a programmable processing system comprising a processor, a data storage system, an input device, and an output device.
  • FIG. 19 illustrates one such programmable processing system 1900, including a CPU 1910, a RAM 1920, and an I/O controller 1930 coupled by a CPU bus 1940.
  • the I/O controller 1930 is also coupled by an I/O bus 1950 to input devices such as a keyboard 1960, and output devices such as displays 1970.

Abstract

Generalized key indexes enable a first table of a relational database to be indexed using an index key and index conditions, wherein either or both of the index key and index conditions may reference multiple tables of the database or may be an expression using fields of one or more tables other than the first table. The generalized key indexes directly associate generalized index key values with record identifiers of records of the first table, thus enabling efficient storage and data retrieval.

Description

BACKGROUND
The invention relates generally to relational database systems, and more particularly to indexing in relational database systems.
Users perceive a relational database as a collection of tables, each of which arranges data for items and item attributes in rows and columns: a table row corresponds to an item (referred to as a record); a table column corresponds to an attribute of the item (referred to as a field). A table record can generally be identified by a record identifier (RID), indicating the page and offset within the page where the record is stored.
FIGS. 1-3 illustrate examples of tables in a relational database. Data stored in the tables can be accessed using indexes such as those illustrated in FIGS. 4-6, which aid in accessing data by providing a logical ordering of the table records. FIG. 4 illustrates a conventional index 400 on the CUST table 100 of FIG. 1, using the customer name 410a as the index key. Index 400 provides an alphabetical ordering of the records of CUST table 100 by customer name 120, and associates each name 410a with record identifiers 410b for table records having the customer name in their cust-- name field 120.
A query for phone numbers of customers named Smith would normally be processed by searching index 400 for an entry having the key value "Smith" 440a, using the associated record identifier 440b to retrieve a record in CUST table 100, and extracting data in the cust-- phone field 140 of the retrieved record. Because index 400 is ordered by customer name, the index search is faster than the linear search of CUST table 100 that would be required without an index. Indexes may be implemented using various methods such as B-Trees and hash functions.
As exemplified by index 400, index entries generally have two attributes: an index key value, and record identifiers of table records. An index key generally is a field or a combination of fields from a table, and each index entry associates a key value with record identifiers of table records.
Conventional indexes are single-table, associating key values based on table fields with record identifiers of records of that same table. Index 400 of FIG. 4 is an example of a single-table index. Various types of single-table indexes exist. FIG. 7 illustrates an example of a "virtual column" index, created by defining the index key as an expression using one or more fields of a table record. For example, to order the records of the order table ("ORD table") of FIG. 2 by price including discount, a virtual column index is created using the index key (ORD.price-ORD.discount).
Another type of single-table index is a "partial index," which indexes only those table records satisfying a specified condition. For example, FIG. 8 illustrates an index associating values for ORD.date only with record identifiers of table records having a price of at least $50,000.00.
In relational database systems, an index may also be multi-table, using fields from a first table in its index key, and associating index key values with record identifiers of records of a second table. Multi-table indexes are generally referred to as join indexes.
FIGS. 4-6 together illustrate an implementation of an index for retrieving index records based on customer name, created on the ITEM table 300 (FIG. 3), using the name field 120 from the CUST table 100 as an index key (CUST.cust-- name). As shown, this index has three levels. The first level (index 400, FIG. 4) associates values for CUST.cust-- name 410a with record identifiers of records of the CUST table 410b; the second level (index 500, FIG. 5) associates values for CUST.cust-- no 510a with record identifiers of records of the ORD table 510b having the same value for ORD.cust-- no; and the third level (index 600, FIG. 6) associates values for ORD.ord-- no 610a with record identifiers of records of the ITEM table 610b having the same value for the ITEM.ord-- no.
Indexes 400-600 aid in retrieving item records corresponding to a customer name. For example, to retrieve item records for a customer Smith, index 400 is used to retrieve the CUST.cust-- no (1002) of the CUST records corresponding to Smith (002); index 500 is used to retrieve the ORD.ord-- no (002, 003) of the ORD records (101, 102) corresponding to the CUST.cust-- no (1002); and finally, index 600 is used to retrieve the ITEM records (201, 202, 203) corresponding to the ORD.ord-- no (002, 003).
Although such multi-table indexes do simplify accessing data in relational database systems, conventional indexing for relational databases has limitations. For example, a conventional index associating key values of fields of a first table with record identifiers of records of a second table generally has more than one level, as illustrated by FIGS. 4-6.
A consequence of having multiple levels in multi-table indexes is that such indexes require more memory space than single-table indexes. Another consequence of having multiple levels is that more processing is required to handle queries. For example, retrieving item records corresponding to a customer name "Smith" requires multiple processing steps.
SUMMARY
In general, in one aspect, the invention features a computer-implemented method for creating an index for a first table in a multi-table relational database based on an index key and index conditions by determining index key values, wherein if the index key references tables other than the first table, the method further comprises retrieving data from the other tables to determine the index key values; associating each determined index key value with record identifiers of records of the first table satisfying the index conditions, wherein if the index conditions reference tables other than the first table, the method further comprises retrieving data from the other tables to determine the associated record identifiers; and storing the index key values and the associated record identifiers in an index.
Embodiments of the invention may include one or more of the following features. The index key references at least a second table and a third table. The index conditions reference at least a second table and a third table. The index key is an expression referencing at least a second table.
In another aspect, the invention features a computer-implemented method for creating an index for a first table in a multi-table relational database based on an index key by determining index key values, wherein the index key comprises an expression referencing at least a second table; associating each determined key value with record identifiers of the records of the first table; and storing the index key values and the associated record identifiers in an index.
In another aspect, the invention features a computer-implemented method for determining the applicability of an index for processing a query in a multi-table relational database, wherein the index indexes an index table based on an index key and index conditions, the query is based on query conditions referencing a set of query tables, and each of the tables are tables of the multi-table relational database. This method comprises determining whether the index table is one of the query tables; determining whether the index conditions are less or equally restrictive as compared with the query conditions; and determining the index to be applicable for processing the query if the index table is one of the query tables and the index conditions are less or equally restrictive as compared with the query conditions.
Embodiments of the invention may include a method in which determining whether the index conditions are less or equally restrictive as compared with the query conditions comprises determining whether each index condition is satisfied by at least one query condition.
In another aspect, the invention features a computer-implemented method of processing a query on a set of query tables in a relational database by retrieving an index comprising index entries having index key values and associated record identifiers of records of a first query table in the set of query tables, wherein the association between index entries and associated record identifiers is based on at least a second query table and a third query table in the set of query tables; determining an index key value based on the query; determining an index entry corresponding to the determined index key value; and retrieving records of the first query table based on the associated record identifiers of the determined index entry.
In another aspect, the invention features a computer-implemented method of processing a query on a set of query tables in a relational database by retrieving an index comprising index entries having index key values and associated record identifiers of records of a first query table in the set of query tables, wherein the index key values are based on an expression referencing at least a second query table in the set of query tables; determining an index key value based on the query; selecting an index entry corresponding to the determined index key value; and retrieving records of the first query table based on the selected index entry.
In another aspect, the invention features an index stored on a processor-readable medium, for enabling a programmable processor to order records of a first table of a multi-table relational database based on an index key and index conditions, the index comprising index key values and associated record identifiers for records of the first table satisfying the index conditions, where at least one of the index key and the index conditions reference a second and a third table of the multi-table relational database.
In another aspect, the invention features an index stored on a processor-readable medium, for enabling a programmable processor to order records of a first table of a multi-table relational database based on an index key, the index comprising index key values and associated record identifiers for records of the first table, where the index key is an expression referencing at least a second table of the multi-table relational database.
The advantages of the invention include one or more of the following. The generalized key indexing system may be implemented in a single level, achieving efficient storage and enabling efficient query processing. The generalized key indexes also enable indexing on a variety of index keys, including, for example, expressions using fields of more than one table.
Furthermore, the generalized key indexes are flexible enough to encompass a variety of index formats, including conventional single-table indexing. Relational database systems may be readily adapted to create and handle both generalized key indexes and conventional indexes.
Additional objects and advantages of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. The objects and advantages of the invention may be realized and obtained by means of the instrumentalities and combinations particularly pointed out in the claims.
BRIEF DESCRIPTION OF THE DRAWINGS
The accompanying drawings, which are incorporated in and constitute a part of the specification, schematically illustrate the invention and, together with the general description given above and the detailed description given below, serve to explain the principles of the invention.
FIGS. 1-3 illustrate tables of a relational database.
FIGS. 4-8 illustrate indexes.
FIG. 9 is a flow diagram of a method of creating a generalized key index.
FIGS. 10-12 illustrate indexes.
FIG. 13 is a flow diagram of a method of determining applicability of a generalized key index.
FIGS. 14 and 15 illustrate indexes.
FIG. 16 shows the applicability of indexes to given queries.
FIGS. 17 and 18 illustrate indexes.
FIG. 19 illustrates a programmable processing system.
DESCRIPTION OF THE PREFERRED EMBODIMENT
The invention provides a generalized use of indexing in relational database systems. Generalized key indexes ("GK indexes") encompass conventional indexes--including single-table indexes such as virtual column indexes and partial indexes, as well as multi-table indexes--and enable different techniques used in conventional indexes to be combined in a single index. GK indexes further provide enhanced capabilities to create customized indexes that are efficiently stored and enable efficient query processing.
In one embodiment, a GK index is created by a user command having the general format:
______________________________________
CREATE GK-INDEX      <index-name>
ON                   <table-name>
(SELECT AS KEY       <key-list>
FROM                 <other-table-list>
WHERE                <condition-list>)
______________________________________
where the parameters are as follows:
______________________________________
index-name:
          identifies the index being created
table-name:
          identifies the table whose records are being indexed.
key-list: includes one or more fields from one or more tables
          of the relational database.
other-table-list:
          includes each table, other than the table
          corresponding to table-name, having a field
          referenced either in the key-list or the condition-list.
          If the index being defined is a single-table index,
          this list may be empty.
condition-list:
          includes zero or more conditions (expressions) to be
          satisfied. This list may be empty.
______________________________________
One embodiment creates a GK index from such a statement as if processing a query and storing the results. For example, the general format for creating a GK index may be expressed as the query:
______________________________________
SELECT         <key-list>, <table-name>.RID
FROM           <other-table-list>, <table-name>
WHERE          <condition-list>
ORDER BY       <order-list>
______________________________________
where <table-name>.RID references the table records and the <order-list> generally reflects the fields as ordered in the key-list.
GK indexes may be used to create conventional single-table indexes, including virtual column indexes and partial indexes. In an implementation using the above format, single-table GK indexes are created by statements such as:
______________________________________
CREATE GK-INDEX      <index-name>
ON                   <table-name>
(SELECT AS KEY       <key-list>
WHERE                <condition-list>)
______________________________________
which may be expressed as the query:
______________________________________
SELECT          <key-list>, <table-name>.RID
FROM            <table-name>
WHERE           <condition-list>
ORDER BY        <order-list>
______________________________________
Thus, for example, the standard one-table index discussed with reference to FIG. 4 indexing the CUST table by name would be created by a statement such as:
______________________________________
CREATE GK-INDEX      Cust.sub.-- Name.sub.-- Index
ON                   CUST
(SELECT AS KEY       CUST.cust.sub.-- name)
______________________________________
which may be expressed as the query:
______________________________________
SELECT         CUST.cust.sub.-- name, CUST.RID
FROM           CUST
ORDER BY       CUST.cust.sub.-- name
______________________________________
The virtual column index 700 discussed above with reference to FIG. 7 may be created by the statement:
______________________________________
CREATE GK-INDEX   VC.sub.-- Index
ON                ORD
(SELECT AS KEY    (ORD.price - ORD.discount)
______________________________________
which may be expressed as the query:
______________________________________
SELECT          (ORD.price - ORD.discount)
                ORD.RID
FROM            ORD
ORDER BY        (ORD.price - ORD.discount)
______________________________________
Similarly, the partial index 800 discussed with reference to FIG. 8 may be created by:
______________________________________
CREATE GK-INDEX    Partial.sub.-- Index
ON                 ORD
(SELECT AS KEY     ORD.date
WHERE              ORD.price ≧ 50,000.00)
______________________________________
which may be expressed as the query:
______________________________________
SELECT           ORD.date, ORD.RID
FROM             ORD
WHERE            ORD.price ≧ 50,000.00
ORDER BY         ORD.date
______________________________________
As indicated above, GK indexes encompass conventional single-table indexes. GK indexes may also be multi-table. In processing the query corresponding to a multi-table GK index, intermediate tables are referenced in determining the final association of GK index key values with record identifiers of records of the indexed table, but the GK index stores the end results.
Query processing methods have been extensively studied, and a variety of methods can be used to process a query corresponding to a "Create GK Index" command.
FIG. 9 is a flow diagram illustrating a method for creating a GK index. After receiving a command to create a GK index GKI on a table T (referred to above as <table-name>), using an index key K (referred to above as <key-list>) and index conditions {C} (referred to above as <condition-list>) (910), values for index key K are determined (920). For each index key value, associated record identifiers of table T satisfying the conditions {C} are determined (930). Index key values and their associated record identifiers are stored as index entries (940).
Determining associated record identifiers of records of table T for an index key value can reference an intermediate table (one of the tables in the <other-table-list>) other than T. For example, if a table in the <other-table-list> is referenced by the index key or in a condition of {C}, data from that other table will need to be retrieved. However, whether intermediate tables are referenced, the index stores the result of the mapping, directly correlating an index key value with associated record identifiers of records of indexed table T.
FIG. 10 shows a GK index 1000 associating customer names with record identifiers of item records, performing the same function as the indexes of FIGS. 4-6. As a result of a command such as:
______________________________________
CREATE GK-INDEX
               cust.sub.-- items
ON             ITEM
(SELECT AS KEY CUST.cust.sub.-- name
FROM           CUST
WHERE          CUST.cust.sub.-- no = ORD.cust.sub.-- no AND
               ORD.ord.sub.-- no = ITEM.ord.sub.-- no)
______________________________________
the corresponding query:
______________________________________
SELECT       CUST.cust.sub.-- name, ITEM.RID
FROM         CUST, ORD, ITEM
WHERE        CUST.cust.sub.-- no = ORD.cust.sub.-- no AND
             ORD.ord.sub.-- no = ITEM.ord.sub.-- no
ORDER BY     CUST.cust.sub.-- name
______________________________________
is processed, creating the GK index 1000 of FIG. 10.
Like the index 400 of FIG. 4, GK index 1000 associates customer names with record identifiers of item records. However, as shown, GK index 1000 has only a single level, directly associating values for customer names from the CUST table with record identifiers of records of the ITEM table, eliminating reference to the ORD table.
Conventional multi-table indexes such as the indexes of FIGS. 4-6 have multiple levels referencing intermediate records to associate key values with record identifiers of table records. Not only do multiple levels result in larger memory requirements and slower access times, they also place some limitations on the types of indexes that can be created. For example, conventional multi-level multi-table indexing does not permit an index key to be based on fields of more than one table.
In contrast, because GK indexes have only a single level, directly associating GK index key values with record identifiers of table records, users have great flexibility in determining how the association is defined. For example, a GK index key may be created on a first table, using an index key that includes an expression using one or more fields of a second table. Referring to the tables of FIGS. 1-3, to determine customers who had made single order purchases having a particular total cost, GK index 1100 of FIG. 11 may be created as follows:
______________________________________
CREATE GK-INDEX  cust.sub.-- expenditure
ON               CUST
(SELECT AS KEY   ((ORD.price - ORD.discount) *
                 (1 + ORD.tax))
FROM             ORD
WHERE            ORD.cust.sub.-- no = CUST.cust.sub.-- no)
______________________________________
which would be processed as:
______________________________________
SELECT         ((ORD.price - ORD.discount) *
               (1 + ORD.tax)), CUST.RID
FROM           ORD, CUST
WHERE          ORD.cust.sub.-- no = CUST.cust.sub.-- no
______________________________________
GK index keys can also be created on fields from more than one table. For example, the following command would create GK index 1200 of FIG. 12, associating a combination of a customer name and an order date with record identifiers of the items purchased in that order:
______________________________________
CREATE GK-INDEX
               cust.sub.-- date.sub.-- item
ON             ITEM
(SELECT AS KEY (CUST.cust.sub.-- name,
               ORD.date)
FROM           CUST, ORD
WHERE          CUST.cust.sub.-- no = ORD.cust.sub.-- no AND
               ORD.ord.sub.-- no = ITEM.ord.sub.-- no)
______________________________________
which may be created by:
______________________________________
SELECT       (CUST.cust.sub.-- name,
             ORD.date), ITEM.RID
FROM         CUST, ORD, ITEM
WHERE        CUST.cust.sub.-- no = ORD.cust.sub.-- no AND
             ORD.ord.sub.-- no = ITEM.ord.sub.-- no
ORDER BY     CUST.cust.sub.-- name, ORD.date
______________________________________
These examples reflect the flexibility of generalized key indexing to create indexes customized to a user's specific needs.
To ensure continuing accuracy of a GK index after data is added, deleted, or altered in a table that was referenced to create that GK index, the GK index must be updated to verify that its entries are still accurate after the data change has occurred.
Various update methods exist and may be adapted to update GK indexes. One embodiment reconstructs a GK index when any of the referenced fields are altered, or deletes the GK index if the alteration is incompatible with the GK index (e.g., the field is deleted or changed to an incompatible data type). This method is especially suitable for data warehousing environments, in which data is not frequently updated.
A database system uses a GK index to access data by finding the GK index key value in the GK index and following associated record identifiers to the relevant table records. For example, using GK index 1000 of FIG. 10 to find item records for a customer named Smith, GK index 1000 is first searched for an entry for Smith 1030a, and the item records are retrieved by the corresponding record identifiers 1030b.
To use an index, relational database systems first determine whether that particular index is appropriately used to process a given query. Typically, database systems have a query optimizer responsible for determining which indexes, if any, are used to process a given query.
Generally, query optimizers determine whether to use a particular index for a given query by determining (1) whether the index is applicable to the query; and (2) whether the index is optimally used to process the query.
Consider, for example, the following query Q:
______________________________________
SELECT            <query-select-list>
FROM              <query-table-list>
WHERE             <query-condition-list>
______________________________________
and GK index GKI, created as follows:
______________________________________
CREATE GK-INDEX    GKI
ON                 T
(SELECT AS KEY     <index-key-list>
FROM               <index-other-table-list>
WHERE              <index-condition-list>)
______________________________________
Generally, for a GK index to be applicable to a query, the table it indexes must be referenced by the query. FIG. 13 is a flow diagram illustrating the process in one embodiment of determining applicability. If the table T, indexed by GK index GKI, is not one of the tables in the <query-table-list> (1310), GK index GKI is not applicable to the query (1315). Similarly, if the <index-condition-list> is more restrictive than the <query-condition-list> (1320), GK index GKI is not applicable to the query (1315). Otherwise, GK index GKI is applicable to the query (1325).
The restrictiveness evaluation (1320) ensures that using the index GKI will not produce incomplete results, which could occur if the index GKI is created on more restrictive conditions than are required by the query. In one embodiment, whether the restrictiveness condition is satisfied is determined by evaluating whether each condition in the <index-condition-list> is satisfied by at least one condition of the <query-condition-list>.
The following example illustrates the concept of applicability. Using the tables of FIGS. 1-3, the following indexes are created:
(1) cust-- items index: as illustrated in FIG. 10, cust-- items index 1000 associates a customer name with record identifiers of item records for items purchased by that customer.
(2) cust-- big-- items index: illustrated in FIG. 14, cust-- big-- items 1400 associates a customer name with record identifiers of item records for items purchased by that customer in orders having a price of at least $50,000.00. This index may be created by:
______________________________________
CREATE GK-INDEX
               cust.sub.-- big.sub.-- items
ON             ITEM
(SELECT AS KEY CUST.cust.sub.-- name
FROM           CUST, ORD
WHERE          CUST.cust.sub.-- no = ORD.cust.sub.-- no AND
               ORD.ord.sub.-- no = ITEM.ord.no AND
               ORD.price ≧ 50,000.00)
______________________________________
3. cust-- many-- big-- items: illustrated in FIG. 15, cust-- many-- big-- items 1500 associates a customer name with record identifiers of item records for items which were purchased in quantities of at least ten, purchased by that customer in orders having a price of at least $50,000.00. This index may be created by:
______________________________________
CREATE GK-INDEX
             cust.sub.-- many.sub.-- big.sub.-- items
ON           ITEM
(SELECT AS KEY
             CUST.cust.sub.-- name
FROM         CUST, ORD
WHERE        CUST.cust.sub.-- no = ORD.cust.sub.-- no AND
             ORD.ord.sub.-- no = ITEM.ord.no AND
             ORD.price ≧ 50,000.00 AND
             ITBM.quantity ≧ 10)
______________________________________
The following queries are submitted on the database including the tables of FIGS. 1-3:
(1) Q1: Find item numbers and item quantities in orders by customer Smith. This query is formatted as:
______________________________________
SELECT       ITEM.item.sub.-- no, ITEM.quantity
FROM         CUST, ORD, ITEM
WHERE        CUST.cust.sub.-- name = "Smith" AND
             CUST.cust.sub.-- no = ORD.cust.sub.-- no AND
             ORD.ord.sub.-- no = ITEM.ord.sub.-- no
______________________________________
(2) Q2: Find item numbers and quantities of items in orders of at least $60,000.00 by customer Smith. This query is formatted as:
______________________________________
SELECT       ITEM.item.sub.-- no, ITEM.quantity
FROM         CUST, ORD, ITEM
WHERE        CUST.cust.sub.-- name = "Smith" AND
             CUST.cust.sub.-- no = ORD.cust.sub.-- no AND
             ORD.ord.sub.-- no = ITEM.ord.sub.-- no AND
             ORD.price ≧ 60,000.00
______________________________________
(3) Q3: Find item numbers and quantities of items purchased in quantities of at least 25 orders of at least $60,000.00 by customer Smith. This query is formatted as:
______________________________________
SELECT       ITEM.item.sub.-- no, ITEM.quantity
FROM         CUST, ORD, ITEM
WHERE        CUST.cust.sub.-- name = "Smith" AND
             CUST.cust.sub.-- no = ORD.cust.sub.-- no AND
             ORD.ord.sub.-- no = ITEM.ord.sub.-- no AND
             ORD.price ≧ 60,000.00 AND
             ITEM.quantity ≧ 25
______________________________________
The applicability of indexes 1000, 1400, and 1500 to queries Q1, Q2, and Q3 is illustrated in FIG. 16. Q1 requests information about all items purchased by Smith. Only index 1000 is applicable because the index conditions of indexes 1400 and 1500 are more restrictive than the query conditions and would not lead to complete results: The condition in index 1400 that ORD.price ≧50,000 is not satisfied by any condition of Q1. Accordingly, index 1400 indicates only items purchased by Smith in orders of at least $50,000.00. Index 1500 includes conditions both that ORD.price ≧50,000 and that ITEM.quantity ≧10, neither of which are satisfied by any conditions of Q2. Thus, index 1500 indicates only items purchased by Smith in orders of at least $50,000.00.
This example also illustrates that an index having conditions more restrictive than query conditions can lead to incorrect results: the proper response to Q1, requesting all items purchased by Smith, corresponds to items 201, 202, 203; index 1400 would produce only items 201 and 202; index 1500 produces only item 201.
The concept of applicability is further illustrated by queries Q2 and Q3. Q2 requests items purchased by Smith in orders of at least $60,000.00. Index 1400 is applicable for Q2 because its condition that ORD.price ≧50,000.00 is satisfied by Q2 query condition that ORD.price ≧60,000.00. Index 1500 is not applicable because although its condition that ORD.price ≧50,000 is satisfied, its condition that ORD.quantity ≧10 is not satisfied by any condition of Q2.
Q3 requests items purchased by Smith in quantities greater than 25 in orders of at least $60,000.00. Index 1400 is applicable for the same reason it is applicable for Q2. Index 1500 is also applicable because the condition that ITEM.quantity ≧10 is satisfied by Q3 query condition that ITEM.quantity ≧25.
Once determining that an index is applicable to a given query, query optimizers generally determine whether the index is optimally used in processing the query. Although methods of optimization vary among query optimizers, a commonly used method is based on the Selinger optimizer algorithm, discussed in P. G. Selinger et al., An Access Specification Language for a Relational Data Base System, 1979 ACM SIGMOD INT'L CONF. ON MANAGEMENT OF DATA 23-34 (May/June 1979).
The basic idea of the Selinger algorithm is to enumerate possible execution plans for processing a given query, estimating the cost of each possible plan, and selecting the best plan (the plan having the least cost). Thus, processing the query:
______________________________________
SELECT            <query-select-list>
FROM              <query-table-list>
WHERE             <query-condition-list>)
______________________________________
where <query-table-list> is the set {T1, T2, . . . , Tn}, requires that all of the tables in <query-table-list> be joined. One possible Selinger optimizer generates plans for all permutations of tables of the query table set and estimates the cost for each permutation by starting with the first table in the permutation and estimating the cost of joining that table with a second table, adding that cost to the estimate of the cost of joining the result of the first join to a third table, and continues joining all tables of the tables set and calculating the accumulated estimated cost. The total cost also considers the cost of incorporating single-table conditions that do not require any joins. This process is repeated for every possible permutation.
Indexes can reduce the plan cost. Selinger optimizers generally use indexes to reduce the cost of joining a table, or to reduce the cost of determining a condition on a single table.
Referring the tables 100, 200, 300 of FIGS. 1-3, consider the query:
______________________________________
SELECT       CUST.name, ITEM.quantity
FROM         CUST, ORD, ITEM
WHERE        CUST.cust.sub.-- name = "Smith" AND
             CUST.cust.sub.-- no = ORD.cust.sub.-- no AND
             ORD.ord.sub.-- no = ITEM.ord.sub.-- no AND
             ITEM.quantity ≧ 25
______________________________________
The table set is {CUST, ORD, ITEM}; the plans include the following possible permutations:
______________________________________
          (1) {CUST, ORD, ITBM}
          (2) {CUST, ITEM, ORD}
          (3) {ORD, CUST, ITEM}
          (4) {ORD, ITEM, CUST}
          (5) {ITEM, CUST, ORD}
          (6) {ITEM, ORD, CUST}
______________________________________
Index 1700 of FIG. 17 associates the field ITEM.quantity with ITEM.RID, and is helpful to process the condition ITEM.quantity ≧25. This condition references only the ITEM table, and therefore does not require that any other table be previously joined. Thus index 1700 can be used in each of plans (1)-(6) when the ITEM table is added.
Index 1800 of FIG. 18 associates the field ITEM.ord-- no with ITEM.RID, and is useful to effect the condition ORD.ord-- no=ITEM.ord-- no, joining the ITEM table to the ORD table by the common ord-- no fields. However, because this condition references the ORD table, index 1800 is used only to join the ITEM table if the ORD table has already been joined. Thus, index 1800 is used only in plans (1), (3), and (4).
Various methods of determining when to use GK indexes may be used to adapt Selinger optimizers to incorporate GK indexes into this algorithm. For example, in one embodiment, like conventional single-table indexes, a single-table GK index on a table T will always be considered when that table is joined. Multi-table GK-indexes will be considered when all of the tables referenced in the key-list have already been joined.
Query optimizers based on algorithms other than the Selinger algorithm can be similarly adapted to handle GK indexes, although the specific modifications may vary.
Other embodiments are within the scope of the following claims. For example, other embodiments may use different update methods. One embodiment, rather than deleting a GK index when an underlying table is altered, updates or recalculates the index.
Other possible variations include use different types of data structures may be used to represent the GK key indexes, including b-trees and bit-mapped indexes.
While the invention is described in terms of a software implementation, the invention may be implemented in hardware or software, or a combination of both. Preferably, the invention is implemented in a software program executing on a programmable processing system comprising a processor, a data storage system, an input device, and an output device.
FIG. 19 illustrates one such programmable processing system 1900, including a CPU 1910, a RAM 1920, and an I/O controller 1930 coupled by a CPU bus 1940. The I/O controller 1930 is also coupled by an I/O bus 1950 to input devices such as a keyboard 1960, and output devices such as displays 1970.
The present invention has been described in terms of an embodiment. The invention, however, is not limited to the embodiment depicted and described. Rather, the scope of the invention is defined by the appended claims.

Claims (14)

What is claimed is:
1. A processor-readable medium having code for Processing a multi-table relational database based on an index key, comprising:
index key values associated with the relational database; and
record identifiers associated with the index key values for identifying records of the first table,
wherein the index key is an expression referencing at least a second table of the multi-table relational database in ordering records of the multi-table relational database.
2. The index of claim 1, wherein the index key expression further references a third table.
3. A processor-readable medium having code for processing a multi-table relational database based on an index key and index conditions, comprising:
index key values associated with the relational database; and
record identifiers associated with the index key values for identifying records of a first table satisfying the index conditions,
wherein at least one of the index key values and the index conditions reference a second and a third table of the multi-table relational database in ordering records of the multi-table relational database.
4. A computer-implemented method of processing a query on a set of query tables in a relational database, comprising:
retrieving an index for the relational database comprising index entries having index key values and associated record identifiers of records of a first query table in the set of query tables, wherein the index key values are based on an expression referencing at least a second query table in the set of query tables;
determining an index key value based on the query;
selecting an index entry corresponding to the determined index key value; and
retrieving records of the first query table based on the selected index entry.
5. A computer-implemented method for creating an index for a first table in a multi-table relational database based on an index key, the method comprising:
determining index key values of the relational database, wherein the index key comprises an expression referencing at least a second table;
associating each determined key value with record identifiers of the records of the first table; and
storing the index key values and the associated record identifiers in an index.
6. The method of claim 5, wherein the index key expression further references a third table.
7. A computer-implemented method of processing a query on a set of query tables in a relational database, comprising:
retrieving an index for the relational database comprising index entries having index key values and associated record identifiers of records of a first query table in the set of query tables, wherein the association between index entries and associated record identifiers is based on at least a second query table and a third query table in the set of query tables;
determining an index key value based on the query;
determining an index entry corresponding to the determined index key value; and
retrieving records of the first query table based on the associated record identifiers of the determined index entry.
8. A computer-implemented method for determining the applicability of an index for processing a query in a multi-table relational database, wherein the index indexes an index table based on an index key and index conditions, the query is based on query conditions referencing a set of query tables, and each of the tables are tables of the multi-table relational database, the method comprising:
determining whether the index table of the relational database is one of the query tables;
determining whether the index conditions are less or equally restrictive as compared with the query conditions; and
determining the index to be applicable for processing the query if the index table is one of the query tables and the index conditions are less or equally restrictive as compared with the query conditions.
9. The method of claim 8, wherein determining whether the index conditions are less or equally restrictive as compared with the query conditions comprises determining whether each index condition is satisfied by at least one query condition.
10. A computer-implemented method for creating an index for a first table in a multi-table relational database based on an index key and index conditions, the method comprising:
determining index key values of the relational database, wherein if the index key references tables other than the first table, the method further comprises retrieving data from the other tables to determine the index key values;
associating each determined index key value with record identifiers of records of the first table satisfying the index conditions, wherein if the index conditions reference tables other than the first table, the method further comprises retrieving data from the other tables to determine the associated record identifiers; and
storing the index key values and the associated record identifiers in an index.
11. The method of claim 10, wherein the index key value references at least a second table and a third table.
12. The method of claim 10, wherein the index conditions reference at least a second table and a third table.
13. The method of claim 10, wherein the index key is an expression referencing at least a second table.
14. The method of claim 13, wherein the index key expression further references a third table.
US08/677,490 1996-07-09 1996-07-09 Generalized key indexes Expired - Lifetime US5870747A (en)

Priority Applications (7)

Application Number Priority Date Filing Date Title
US08/677,490 US5870747A (en) 1996-07-09 1996-07-09 Generalized key indexes
AU28361/97A AU713109C (en) 1996-07-09 1997-06-27 Generalized key indexes
MXPA/A/1997/005043A MXPA97005043A (en) 1996-07-09 1997-07-03 Generalized cla indices
CA002209978A CA2209978A1 (en) 1996-07-09 1997-07-08 Generalized key indexes
JP18194797A JP4132136B2 (en) 1996-07-09 1997-07-08 Methods for forming relational database indexes
BR9703939A BR9703939A (en) 1996-07-09 1997-07-09 Generalized index keys
EP97305022A EP0818743A3 (en) 1996-07-09 1997-07-09 Generalized key indexes

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US08/677,490 US5870747A (en) 1996-07-09 1996-07-09 Generalized key indexes

Publications (1)

Publication Number Publication Date
US5870747A true US5870747A (en) 1999-02-09

Family

ID=24718929

Family Applications (1)

Application Number Title Priority Date Filing Date
US08/677,490 Expired - Lifetime US5870747A (en) 1996-07-09 1996-07-09 Generalized key indexes

Country Status (5)

Country Link
US (1) US5870747A (en)
EP (1) EP0818743A3 (en)
JP (1) JP4132136B2 (en)
BR (1) BR9703939A (en)
CA (1) CA2209978A1 (en)

Cited By (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5966703A (en) * 1996-08-09 1999-10-12 Digital Equipment Corporation Technique for indexing information stored as a plurality of records
US6014670A (en) * 1997-11-07 2000-01-11 Informatica Corporation Apparatus and method for performing data transformations in data warehousing
US6167399A (en) * 1998-05-05 2000-12-26 Ncr Corporation Join index for relational databases
US6339775B1 (en) * 1997-11-07 2002-01-15 Informatica Corporation Apparatus and method for performing data transformations in data warehousing
US20020194380A1 (en) * 2001-06-04 2002-12-19 Gateway, Inc. System and method for leveraging networked computers to view windows based files on linux platforms
US6499033B1 (en) * 1998-05-09 2002-12-24 Isc, Inc. Database method and apparatus using hierarchical bit vector index structure
US6505189B1 (en) 2000-06-15 2003-01-07 Ncr Corporation Aggregate join index for relational databases
US6505188B1 (en) 2000-06-15 2003-01-07 Ncr Corporation Virtual join index for relational databases
US6618720B1 (en) 2000-06-15 2003-09-09 Ncr Corporation Common spool files for maintaining join indexes
US6643636B1 (en) * 2001-06-05 2003-11-04 Ncr Corporation Optimizing a query using a non-covering join index
US20030212701A1 (en) * 2002-05-10 2003-11-13 International Business Machines Corporation Method, system, and program for selecting a join order for tables subject to a join operation
US20030225924A1 (en) * 2002-02-12 2003-12-04 Edward Jung Logical routing system
US20040030707A1 (en) * 2002-08-01 2004-02-12 Oracle International Corporation Partial evaluation of rule sets
US20040034618A1 (en) * 2002-08-01 2004-02-19 Oracle International Corporation Utilizing rules in a distributed information sharing system
US6711563B1 (en) * 2000-11-29 2004-03-23 Lafayette Software Inc. Methods of organizing data and processing queries in a database system, and database system and software product for implementing such methods
US20040088293A1 (en) * 2002-10-31 2004-05-06 Jeremy Daggett Method and apparatus for providing aggregate object identifiers
US20040153464A1 (en) * 2001-03-26 2004-08-05 Groves Glenn John Developing and maintaining customised computer information systems
US6778534B1 (en) 2000-06-30 2004-08-17 E. Z. Chip Technologies Ltd. High-performance network processor
US20050125436A1 (en) * 2003-12-03 2005-06-09 Mudunuri Gautam H. Set-oriented real-time data processing based on transaction boundaries
US6934706B1 (en) 2002-03-22 2005-08-23 International Business Machines Corporation Centralized mapping of security credentials for database access operations
US20050222996A1 (en) * 2004-03-30 2005-10-06 Oracle International Corporation Managing event-condition-action rules in a database system
US20060074964A1 (en) * 2004-09-30 2006-04-06 Emc Corporation Index processing
US20060085481A1 (en) * 2004-09-30 2006-04-20 Emc Corporation File index processing
US20060112112A1 (en) * 2004-10-06 2006-05-25 Margolus Norman H Storage system for randomly named blocks of data
US20060218194A1 (en) * 2002-05-10 2006-09-28 Oracle Internation Corporation Determining interest in an XML document
US7117215B1 (en) 2001-06-07 2006-10-03 Informatica Corporation Method and apparatus for transporting data for data warehousing applications that incorporates analytic data interface
US20060224542A1 (en) * 2005-03-16 2006-10-05 Aravind Yalamanchi Incremental evaluation of complex event-condition-action rules in a database system
US7162643B1 (en) 2001-06-15 2007-01-09 Informatica Corporation Method and system for providing transfer of analytic application data over a network
US7177856B1 (en) 2001-10-03 2007-02-13 International Business Machines Corporation Method for correlating data from external databases
US20070078909A1 (en) * 2004-03-08 2007-04-05 Masaharu Tamatsu Database System
US20070185838A1 (en) * 2005-12-29 2007-08-09 Thomas Peh Efficient calculation of sets of distinct results
US20070233718A1 (en) * 2006-03-31 2007-10-04 Microsoft Corporation Generating and utilizing composite keys in lieu of compound keys
US20080033907A1 (en) * 2006-08-02 2008-02-07 Johannes Woehler Business object search using multi-join indexes and extended join indexes
US20080071769A1 (en) * 2006-08-23 2008-03-20 Govindarajan Jagannathan Efficient Search Result Update Mechanism
US7349949B1 (en) 2002-12-26 2008-03-25 International Business Machines Corporation System and method for facilitating development of a customizable portlet
US7359982B1 (en) 2002-12-26 2008-04-15 International Business Machines Corporation System and method for facilitating access to content information
US7421458B1 (en) 2003-10-16 2008-09-02 Informatica Corporation Querying, versioning, and dynamic deployment of database objects
US7483979B1 (en) 2001-01-16 2009-01-27 International Business Machines Corporation Method and system for virtualizing metadata between disparate systems
US20090060024A1 (en) * 2007-08-31 2009-03-05 Samsung Electronics Co., Ltd. Method and apparatus for encoding/decoding media signal
US20090077260A1 (en) * 2000-11-16 2009-03-19 Rob Bearman Application platform
US7509332B1 (en) * 2005-12-16 2009-03-24 Tevaclata Us, Inc. Customized indexes for user defined data types
US7720842B2 (en) 2001-07-16 2010-05-18 Informatica Corporation Value-chained queries in analytic applications
US7877372B1 (en) * 2004-05-24 2011-01-25 Teradata Us, Inc. Method and system for querying tables stored on multiple processing modules
US20110087954A1 (en) * 2009-10-09 2011-04-14 Microsoft Corporation Data analysis expressions
US20110093770A1 (en) * 2008-06-18 2011-04-21 Kunio Kamimura Program for displaying and operating table
US20110320451A1 (en) * 2010-06-23 2011-12-29 International Business Machines Corporation Apparatus and method for sorting data
US20130066850A1 (en) * 2011-09-02 2013-03-14 International Business Machines Corporation Using a partially built index in a computer database system
USRE44478E1 (en) 2002-02-22 2013-09-03 Informatica Corporation Method and system for navigating a large amount of data
US9355127B2 (en) 2012-10-12 2016-05-31 International Business Machines Corporation Functionality of decomposition data skew in asymmetric massively parallel processing databases
US20170220656A1 (en) * 2016-02-03 2017-08-03 Adp, Llc Information Access System
US10078648B1 (en) 2011-11-03 2018-09-18 Red Hat, Inc. Indexing deduplicated data
US10289980B2 (en) * 2015-11-24 2019-05-14 Ariba, Inc. In-memory index for evaluating a complex expression
CN110321344A (en) * 2019-05-20 2019-10-11 平安普惠企业管理有限公司 Information query method, device, computer equipment and the storage medium of associated data
US11650967B2 (en) 2013-03-01 2023-05-16 Red Hat, Inc. Managing a deduplicated data index
CN110321344B (en) * 2019-05-20 2024-03-15 深圳市晶测科技有限公司 Information query method and device for associated data, computer equipment and storage medium

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2833095B1 (en) * 2001-11-30 2004-01-30 Penbase PDA-TYPE COMPUTER DEVICE FOR STORING AND PROCESSING RELATIONAL DATABASES
WO2005004001A1 (en) * 2003-06-04 2005-01-13 M-Penbase Pda-type computer device for storing and processing relational databases
DE102008059098A1 (en) * 2008-11-26 2010-06-10 Continental Automotive Gmbh Infotainment system and computer program product
US11196567B2 (en) 2018-11-26 2021-12-07 Amazon Technologies, Inc. Cryptographic verification of database transactions
US11119998B1 (en) 2018-11-26 2021-09-14 Amazon Technologies, Inc. Index and view updates in a ledger-based database
US11036708B2 (en) * 2018-11-26 2021-06-15 Amazon Technologies, Inc. Indexes on non-materialized views
US10942910B1 (en) 2018-11-26 2021-03-09 Amazon Technologies, Inc. Journal queries of a ledger-based database

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5278978A (en) * 1990-03-26 1994-01-11 International Business Machines Corporation Method and system for describing and exchanging data between heterogeneous database systems with data converted by the receiving database system
US5440730A (en) * 1990-08-09 1995-08-08 Bell Communications Research, Inc. Time index access structure for temporal databases having concurrent multiple versions
US5440732A (en) * 1993-02-05 1995-08-08 Digital Equipment Corp., Pat. Law Gr. Key-range locking with index trees
US5604899A (en) * 1990-05-21 1997-02-18 Financial Systems Technology Pty. Ltd. Data relationships processor with unlimited expansion capability
US5625815A (en) * 1995-01-23 1997-04-29 Tandem Computers, Incorporated Relational database system and method with high data availability during table data restructuring
US5732270A (en) * 1994-09-15 1998-03-24 Visual Edge Software Limited System and method for providing interoperability among heterogeneous object systems

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2711204B2 (en) * 1992-03-09 1998-02-10 インターナショナル・ビジネス・マシーンズ・コーポレイション How to generate a relational database user interface

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5278978A (en) * 1990-03-26 1994-01-11 International Business Machines Corporation Method and system for describing and exchanging data between heterogeneous database systems with data converted by the receiving database system
US5604899A (en) * 1990-05-21 1997-02-18 Financial Systems Technology Pty. Ltd. Data relationships processor with unlimited expansion capability
US5440730A (en) * 1990-08-09 1995-08-08 Bell Communications Research, Inc. Time index access structure for temporal databases having concurrent multiple versions
US5440732A (en) * 1993-02-05 1995-08-08 Digital Equipment Corp., Pat. Law Gr. Key-range locking with index trees
US5732270A (en) * 1994-09-15 1998-03-24 Visual Edge Software Limited System and method for providing interoperability among heterogeneous object systems
US5625815A (en) * 1995-01-23 1997-04-29 Tandem Computers, Incorporated Relational database system and method with high data availability during table data restructuring

Non-Patent Citations (14)

* Cited by examiner, † Cited by third party
Title
Antoshenkov, Gennady "Dynamic Optimization of Index Scans Restricted by Booleans", Data Engineering, 1996 12th Int'l Conf., pp. 430-440.
Antoshenkov, Gennady Dynamic Optimization of Index Scans Restricted by Booleans , Data Engineering, 1996 12th Int l Conf., pp. 430 440. *
Elmasri et al. "A Temporal Model and Query Language for ER Databases", Data Engineering, 1990 6th Int'l Conf., pp. 76-83.
Elmasri et al. A Temporal Model and Query Language for ER Databases , Data Engineering, 1990 6th Int l Conf., pp. 76 83. *
Fotouhi et al., "The Generalized Index Model for Object-Oriented Database Systems", Computers and Communications, 1991 Int'l Phoenix Conf., pp. 302-308.
Fotouhi et al., The Generalized Index Model for Object Oriented Database Systems , Computers and Communications, 1991 Int l Phoenix Conf., pp. 302 308. *
Kolovson et al. "Indexing Techniques for Historical Databases", Data Engineering, 1989 5th Int'Conf., pp127-137.
Kolovson et al. Indexing Techniques for Historical Databases , Data Engineering, 1989 5th Int Conf., pp127 137. *
Kuno et al. "Augmented Inherited Multi-Index Structure for Maintenance of Materilized Path Query Views", Research Issues in Data Engineering, 1996 Workshop, pp. 128-137.
Kuno et al. Augmented Inherited Multi Index Structure for Maintenance of Materilized Path Query Views , Research Issues in Data Engineering, 1996 Workshop, pp. 128 137. *
Sartori et al. "Partial Indexing for Nonuniform Data Distribution in Relational DBMS's", IEEE Transactions on Knowledge and Data Engineering, v. 6, n. 3, pp. 420-429, Jun. 1994.
Sartori et al. Partial Indexing for Nonuniform Data Distribution in Relational DBMS s , IEEE Transactions on Knowledge and Data Engineering, v. 6, n. 3, pp. 420 429, Jun. 1994. *
Seshadri et al. "Generalized Partial Indexes", Data Engineering, 1995 11th Int'l Conf., pp. 420-427.
Seshadri et al. Generalized Partial Indexes , Data Engineering, 1995 11th Int l Conf., pp. 420 427. *

Cited By (88)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5966703A (en) * 1996-08-09 1999-10-12 Digital Equipment Corporation Technique for indexing information stored as a plurality of records
US6014670A (en) * 1997-11-07 2000-01-11 Informatica Corporation Apparatus and method for performing data transformations in data warehousing
US6339775B1 (en) * 1997-11-07 2002-01-15 Informatica Corporation Apparatus and method for performing data transformations in data warehousing
US6167399A (en) * 1998-05-05 2000-12-26 Ncr Corporation Join index for relational databases
US6499033B1 (en) * 1998-05-09 2002-12-24 Isc, Inc. Database method and apparatus using hierarchical bit vector index structure
US6505189B1 (en) 2000-06-15 2003-01-07 Ncr Corporation Aggregate join index for relational databases
US6505188B1 (en) 2000-06-15 2003-01-07 Ncr Corporation Virtual join index for relational databases
US6618720B1 (en) 2000-06-15 2003-09-09 Ncr Corporation Common spool files for maintaining join indexes
US6778534B1 (en) 2000-06-30 2004-08-17 E. Z. Chip Technologies Ltd. High-performance network processor
US8583745B2 (en) 2000-11-16 2013-11-12 Opendesign, Inc. Application platform
US20090077260A1 (en) * 2000-11-16 2009-03-19 Rob Bearman Application platform
US6711563B1 (en) * 2000-11-29 2004-03-23 Lafayette Software Inc. Methods of organizing data and processing queries in a database system, and database system and software product for implementing such methods
US7483979B1 (en) 2001-01-16 2009-01-27 International Business Machines Corporation Method and system for virtualizing metadata between disparate systems
US8819273B2 (en) 2001-02-12 2014-08-26 Opendesign, Inc. Logical routing system
US20110029688A1 (en) * 2001-02-12 2011-02-03 Open Design, Inc. Logical routing system
US20040153464A1 (en) * 2001-03-26 2004-08-05 Groves Glenn John Developing and maintaining customised computer information systems
US7383249B2 (en) * 2001-03-26 2008-06-03 The Futuren Is Freedom Pty Ltd. Developing and maintaining customised computer information systems
US7231460B2 (en) * 2001-06-04 2007-06-12 Gateway Inc. System and method for leveraging networked computers to view windows based files on Linux platforms
US20020194380A1 (en) * 2001-06-04 2002-12-19 Gateway, Inc. System and method for leveraging networked computers to view windows based files on linux platforms
US6643636B1 (en) * 2001-06-05 2003-11-04 Ncr Corporation Optimizing a query using a non-covering join index
US20060242160A1 (en) * 2001-06-07 2006-10-26 Firoz Kanchwalla Method and apparatus for transporting data for data warehousing applications that incorporates analytic data interface
US7117215B1 (en) 2001-06-07 2006-10-03 Informatica Corporation Method and apparatus for transporting data for data warehousing applications that incorporates analytic data interface
US7162643B1 (en) 2001-06-15 2007-01-09 Informatica Corporation Method and system for providing transfer of analytic application data over a network
US7720842B2 (en) 2001-07-16 2010-05-18 Informatica Corporation Value-chained queries in analytic applications
US7177856B1 (en) 2001-10-03 2007-02-13 International Business Machines Corporation Method for correlating data from external databases
US7809854B2 (en) * 2002-02-12 2010-10-05 Open Design, Inc. Logical routing system
US20030225924A1 (en) * 2002-02-12 2003-12-04 Edward Jung Logical routing system
USRE44478E1 (en) 2002-02-22 2013-09-03 Informatica Corporation Method and system for navigating a large amount of data
US6934706B1 (en) 2002-03-22 2005-08-23 International Business Machines Corporation Centralized mapping of security credentials for database access operations
US20030212701A1 (en) * 2002-05-10 2003-11-13 International Business Machines Corporation Method, system, and program for selecting a join order for tables subject to a join operation
US20060218194A1 (en) * 2002-05-10 2006-09-28 Oracle Internation Corporation Determining interest in an XML document
US6980981B2 (en) * 2002-05-10 2005-12-27 International Business Machines Corporation Method, system, and program for selecting a join order for tables subject to a join operation
US7590650B2 (en) 2002-05-10 2009-09-15 Oracle International Corporation Determining interest in an XML document
US20040030707A1 (en) * 2002-08-01 2004-02-12 Oracle International Corporation Partial evaluation of rule sets
US7613741B2 (en) 2002-08-01 2009-11-03 Oracle International Corporation Utilizing rules in a distributed information sharing system
US20040034618A1 (en) * 2002-08-01 2004-02-19 Oracle International Corporation Utilizing rules in a distributed information sharing system
US8005802B2 (en) 2002-08-01 2011-08-23 Oracle International Corporation Partial evaluation of rule sets
US20040088293A1 (en) * 2002-10-31 2004-05-06 Jeremy Daggett Method and apparatus for providing aggregate object identifiers
US7047254B2 (en) * 2002-10-31 2006-05-16 Hewlett-Packard Development Company, L.P. Method and apparatus for providing aggregate object identifiers
US20080162499A1 (en) * 2002-12-26 2008-07-03 International Business Machines Corporation System and Method for Facilitating Access to Content Information
US7349949B1 (en) 2002-12-26 2008-03-25 International Business Machines Corporation System and method for facilitating development of a customizable portlet
US7359982B1 (en) 2002-12-26 2008-04-15 International Business Machines Corporation System and method for facilitating access to content information
US7421458B1 (en) 2003-10-16 2008-09-02 Informatica Corporation Querying, versioning, and dynamic deployment of database objects
US20050125436A1 (en) * 2003-12-03 2005-06-09 Mudunuri Gautam H. Set-oriented real-time data processing based on transaction boundaries
US7254590B2 (en) 2003-12-03 2007-08-07 Informatica Corporation Set-oriented real-time data processing based on transaction boundaries
US20070078909A1 (en) * 2004-03-08 2007-04-05 Masaharu Tamatsu Database System
US20050222996A1 (en) * 2004-03-30 2005-10-06 Oracle International Corporation Managing event-condition-action rules in a database system
US7877372B1 (en) * 2004-05-24 2011-01-25 Teradata Us, Inc. Method and system for querying tables stored on multiple processing modules
US20060074964A1 (en) * 2004-09-30 2006-04-06 Emc Corporation Index processing
US7716262B2 (en) * 2004-09-30 2010-05-11 Emc Corporation Index processing
CN101031907B (en) * 2004-09-30 2012-03-07 Emc公司 Index processing
US7801922B2 (en) 2004-09-30 2010-09-21 Emc Corporation File index processing
US20060085481A1 (en) * 2004-09-30 2006-04-20 Emc Corporation File index processing
US20060112112A1 (en) * 2004-10-06 2006-05-25 Margolus Norman H Storage system for randomly named blocks of data
US7457800B2 (en) * 2004-10-06 2008-11-25 Burnside Acquisition, Llc Storage system for randomly named blocks of data
US7457813B2 (en) 2004-10-06 2008-11-25 Burnside Acquisition, Llc Storage system for randomly named blocks of data
USRE45350E1 (en) * 2004-10-06 2015-01-20 Permabit Technology Corporation Storage system for randomly named blocks of data
US20060116990A1 (en) * 2004-10-06 2006-06-01 Margolus Norman H Storage system for randomly named blocks of data
US7567975B2 (en) * 2005-03-16 2009-07-28 Oracle International Corporation Incremental evaluation of complex event-condition-action rules in a database system
US20060224542A1 (en) * 2005-03-16 2006-10-05 Aravind Yalamanchi Incremental evaluation of complex event-condition-action rules in a database system
US7509332B1 (en) * 2005-12-16 2009-03-24 Tevaclata Us, Inc. Customized indexes for user defined data types
US20070185838A1 (en) * 2005-12-29 2007-08-09 Thomas Peh Efficient calculation of sets of distinct results
US8027969B2 (en) * 2005-12-29 2011-09-27 Sap Ag Efficient calculation of sets of distinct results in an information retrieval service
US7809741B2 (en) 2006-03-31 2010-10-05 Microsoft Corporation Generating and utilizing composite keys in lieu of compound keys
US20070233718A1 (en) * 2006-03-31 2007-10-04 Microsoft Corporation Generating and utilizing composite keys in lieu of compound keys
US7562073B2 (en) * 2006-08-02 2009-07-14 Sap Ag Business object search using multi-join indexes and extended join indexes
US20080033907A1 (en) * 2006-08-02 2008-02-07 Johannes Woehler Business object search using multi-join indexes and extended join indexes
US7979453B2 (en) * 2006-08-23 2011-07-12 Innovative Solutions, Inc. Efficient search result update mechanism
US20080071769A1 (en) * 2006-08-23 2008-03-20 Govindarajan Jagannathan Efficient Search Result Update Mechanism
US20090060024A1 (en) * 2007-08-31 2009-03-05 Samsung Electronics Co., Ltd. Method and apparatus for encoding/decoding media signal
US8422560B2 (en) * 2007-08-31 2013-04-16 Samsung Electronics Co., Ltd. Method and apparatus for encoding/decoding media signal
US8271867B2 (en) * 2008-06-18 2012-09-18 Kunio Kamimura Program for displaying and operating table
US20110093770A1 (en) * 2008-06-18 2011-04-21 Kunio Kamimura Program for displaying and operating table
US9665555B2 (en) 2009-10-09 2017-05-30 Microsoft Technology Licensing, Llc Data analysis expressions
US20110087954A1 (en) * 2009-10-09 2011-04-14 Microsoft Corporation Data analysis expressions
US9275031B2 (en) * 2009-10-09 2016-03-01 Microsoft Technology Licensing, Llc Data analysis expressions
US10762289B2 (en) 2009-10-09 2020-09-01 Microsoft Technology Licensing, Llc Data analysis expressions
US20110320451A1 (en) * 2010-06-23 2011-12-29 International Business Machines Corporation Apparatus and method for sorting data
US8725734B2 (en) * 2010-06-23 2014-05-13 International Business Machines Corporation Sorting multiple records of data using ranges of key values
US20130066850A1 (en) * 2011-09-02 2013-03-14 International Business Machines Corporation Using a partially built index in a computer database system
US9342545B2 (en) * 2011-09-02 2016-05-17 International Business Machines Corporation Using a partially built index in a computer database system
US10078648B1 (en) 2011-11-03 2018-09-18 Red Hat, Inc. Indexing deduplicated data
US9355127B2 (en) 2012-10-12 2016-05-31 International Business Machines Corporation Functionality of decomposition data skew in asymmetric massively parallel processing databases
US11650967B2 (en) 2013-03-01 2023-05-16 Red Hat, Inc. Managing a deduplicated data index
US10289980B2 (en) * 2015-11-24 2019-05-14 Ariba, Inc. In-memory index for evaluating a complex expression
US20170220656A1 (en) * 2016-02-03 2017-08-03 Adp, Llc Information Access System
CN110321344A (en) * 2019-05-20 2019-10-11 平安普惠企业管理有限公司 Information query method, device, computer equipment and the storage medium of associated data
CN110321344B (en) * 2019-05-20 2024-03-15 深圳市晶测科技有限公司 Information query method and device for associated data, computer equipment and storage medium

Also Published As

Publication number Publication date
EP0818743A2 (en) 1998-01-14
EP0818743A3 (en) 1999-08-18
MX9705043A (en) 1998-07-31
BR9703939A (en) 1998-09-08
JPH10143538A (en) 1998-05-29
JP4132136B2 (en) 2008-08-13
AU2836197A (en) 1998-01-15
CA2209978A1 (en) 1998-01-09
AU713109B2 (en) 1999-11-25

Similar Documents

Publication Publication Date Title
US5870747A (en) Generalized key indexes
US7805465B2 (en) Metadata management for a data abstraction model
US7747640B2 (en) Method for regenerating selected rows for an otherwise static result set
US6374252B1 (en) Modeling of object-oriented database structures, translation to relational database structures, and dynamic searches thereon
US6078926A (en) Method and apparatus for performing multi-class object fetch in a database management system
US5761653A (en) Method for estimating cardinalities for query processing in a relational database management system
US6233573B1 (en) System and method for selecting rows from dimensional databases having temporal dimention
US5926820A (en) Method and system for performing range max/min queries on a data cube
EP1425682B1 (en) Database processor for on-line analytical processing of multidimensional data
US7257599B2 (en) Data organization in a fast query system
US5761654A (en) Memory structure and method for tuning a database statement using a join-tree data structure representation, including selectivity factors, of a master table and detail table
US6594653B2 (en) Server integrated system and methods for processing precomputed views
JP2972928B2 (en) Digital data processing system
KR101153139B1 (en) Durable Storage of .NET Data Types and Instances
US7844623B2 (en) Method to provide management of query output
US20130254171A1 (en) Query-based searching using a virtual table
US6122644A (en) System for halloween protection in a database system
JP2003527642A (en) System and method for rewriting relational database queries
US9477729B2 (en) Domain based keyword search
US6636846B1 (en) Method for providing a system maintained materialized functionally dependent column for a database management system
US7062496B2 (en) Automatic data abstraction generation using database schema and related objects
US20050138024A1 (en) Method and infrastructure for processing queries in a database
EP2164007A1 (en) Data storage and fusion layer
Tsotras et al. A notation for spatiotemporal queries
MXPA97005043A (en) Generalized cla indices

Legal Events

Date Code Title Description
AS Assignment

Owner name: INFORMIX SOFTWARE, INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SUNDARESAN, PRAKASH;REEL/FRAME:008730/0742

Effective date: 19970623

STCF Information on status: patent grant

Free format text: PATENTED CASE

AS Assignment

Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:INFORMIX CORPORATION AND/OR INFORMIX SOFTWARE INC.;REEL/FRAME:012581/0221

Effective date: 20010701

FPAY Fee payment

Year of fee payment: 4

FPAY Fee payment

Year of fee payment: 8

FPAY Fee payment

Year of fee payment: 12