Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
  • G06F16/24—Querying
  • G06F16/242—Query formulation
  • G06F16/2433—Query languages
  • G06F16/2448—Query languages for particular applications; for extensibility, e.g. user defined types
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
  • G06F16/24—Querying
  • G06F16/245—Query processing
  • G06F16/2457—Query processing with adaptation to user needs
  • G06F16/24578—Query processing with adaptation to user needs using ranking
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
  • G06F16/33—Querying
  • G06F16/332—Query formulation
• • Y—GENERAL 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
  • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
  • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
  • Y10S707/00—Data processing: database and file management or data structures
  • Y10S707/99931—Database or file accessing
  • Y10S707/99932—Access augmentation or optimizing
• • Y—GENERAL 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
  • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
  • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
  • Y10S707/00—Data processing: database and file management or data structures
  • Y10S707/99931—Database or file accessing
  • Y10S707/99933—Query processing, i.e. searching
• • Y—GENERAL 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
  • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
  • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
  • Y10S707/00—Data processing: database and file management or data structures
  • Y10S707/99931—Database or file accessing
  • Y10S707/99933—Query processing, i.e. searching
  • Y10S707/99934—Query formulation, input preparation, or translation
• • Y—GENERAL 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
  • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
  • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
  • Y10S707/00—Data processing: database and file management or data structures
  • Y10S707/99931—Database or file accessing
  • Y10S707/99933—Query processing, i.e. searching
  • Y10S707/99935—Query augmenting and refining, e.g. inexact access

Definitions

• This invention relates to methods of searching and browsing databases using remote clients.
• a large database application will typically support a feature whereby a user may enter a search key that only approximates the actual value for which the user is searching. Frequently, this is done using a "wildcard” character such as "*".
• the "*" character represents all possible character strings. Accordingly, a search for "jon*” will retrieve any values beginning with the string “jon” followed by any other string of characters. "Jon”, “Jones”, and “Jonathan” would all be retrieved as a result of using "jon*" as a search key.
• the advantages of this search method are that it is flexible, easy to explain to users, and easy to implement. However, the method is somewhat limited.
• this method allows users to unwittingly or maliciously submit overly broad queries — queries so broad that an unacceptably large portion of the database is returned. For example, a user might type a query such as "a*", which would return all values starting with "a”.
• the prior art includes a database lookup scheme that addresses these problems to some degree.
• two tables were maintained in addition to the actual database.
• a first table had a plurality of rows, each corresponding to an individual set of data records. Each row contained fields for three values: a first value, a last value, and an ID.
• the first and last values defined sets or pages of data, similarly to the index entries at the top of a telephone directory or dictionary.
• a data page corresponding to a particular table entry would include data values in the range between the first value and the last value, inclusive. This data page was placed in another table that was pre-generated.
• a corresponding table (referred to as a page definition table) might appear as shown in Table 1 below:
• an information page having ID 0 would include 10 names, beginning with “Ableson” and ending with “Baxter.” Page 1 would have the next 10 names, beginning with “Beaver” and ending with “Bowman.”
• the page definition table was created so that each page had an approximately equal number of names.
• a second table was also maintained. This table had actual data from the database, arranged by ID number. In the example, such a table (referred to as a page data table) would have appeared as follows:
• the ID value of this table corresponded to the ID value of the page definition table (Table 1).
• the PAGEDATA values comprised the actual data that was to be returned to a user for particular page, taken from the database.
• the data consists merely of the names themselves. In actual applications, other data might also have been included, such as telephone numbers or addresses.
• To perform a search under this scheme a user would enter the beginning portion of a name, or some string that the user believed approximated the name. Suppose, for example, that the user entered "fie" as a search string. This string would be used to query Table 1, to find the ID for a row spanning the search string.
• the search might appear as follows: select ID from page_defini tion_table where ⁇
• a user submits a search value to a server or service provider.
• the search value is the user's best guess regarding the data that is sought. Wildcards are not required to be entered by users.
• the server maintains a database in a conventional format.
• the database has a plurality of records, each including a plurality of fields. At least one field of each record is a key field, used to search the records of the database. Standard queries can be performed against the database using specified key values.
• the server also maintains a plurality of page definitions in a page table.
• Each page definition defines a page of database records in terms of lower and upper key values.
• each page definition indicates a single pair of lower and upper key values.
• the server examines the page definitions to find one having key values that surround the search value. It then uses these key values to search the database, and to find all records whose key values fall between the key values of the page definition.
• the upper and lower key values of the page definitions do not specify the first and last key values of the database records that are to be returned to the user. Rather, the lower key value specifies the key value of the first database record to be returned, while the upper key value specifies the key value of the first database record of a subsequent page of records.
• each page definition has two pairs of key values: a first pair that is used to identify the page definition corresponding to a search value, and a second pair that is used to query the database once the correct page definition has been found.
• the information returned to the user does not need to correspond in range to the index scheme used to identify page definitions.
• the first pair defines a range of key values that is a subset of the range defined by the second pair.
• Fig. 1 is a block diagram of an information retrieval system in accordance with the invention.
• Fig. 2 is a block diagram showing pertinent components of a client or server computer in accordance with the invention.
• Fig. 3 is a flowchart showing preferred steps in accordance with the invention.
• Fig. 1 shows an information retrieval computer system in accordance with one embodiment of the invention, generally designated by reference numeral 10.
• Information retrieval system 10 includes a server 12 and a plurality of clients 14. Communications between the clients and the server is provided through a " data communications network such as a local-area network, a wide-area network, or a public network such as the Internet.
• a data communications network such as a local-area network, a wide-area network, or a public network such as the Internet.
• Server 12 has or has access to one or more data storage media such as hard disks or hard disk arrays.
• the server maintains a database 16 on one of these hard disks.
• the database is formatted and arranged in a conventional format, having a plurality of database records. Each record has a plurality of fields containing variable data. The records can be searched and or sorted based on values contained in one or more key fields. Values in key fields are referred to herein as key values.
• the server has a database management system (DBMS) 18 for manipulating the database. Queries can be submitted to the DBMS in SQL (standard query language) format or a similar language that allows access to a relational database.
• SQL standard query language
• Fig. 2 shows pertinent hardware components of an example client computer generally referenced by numeral 40.
• Computer 40 can be any one of a variety of different types of devices including consumer appliances such as set-top boxes, handheld or pocket computers, Internet terminals, desktop computers, and laptop or notebook computers.
• a server computer is configured similarly to the configuration of Fig. 2, although it is optimized for server functions such as file access, application sharing, and database access.
• Computer 40 includes a microprocessor 41 and a computer-readable storage medium such as electronic memory 42.
• Processor 40 is a conventional, off-the-shelf microprocessor such as an x86 series microprocessor, manufactured by Intel Corporation of Santa Clara, California.
• Computer system 40 also includes other typical computer hardware, such as I/O component 38 including interface electronics, as well as multimedia rendering devices 39 such as audio and video components.
• Physical memory 42 preferably comprises randomly accessible read/write electronic memory (RAM), as well as secondary storage such as a magnetic hard disk or other data recording media.
• Memory 42 might also include other types of computer-readable storage media on which executable components are distributed and stored, including floppy disks, CD-ROMs, and non-volatile electronic memory such as EPROMs.
• Database 16 can be stored in memory 42, or in other disk-based memory that is accessible only through network resources.
• computer system 40 includes an operating system 43 and one or more application programs 44 that execute in conjunction with the operating system.
• the Windows 95® operating system available from Microsoft Corporation of Redmond, Washington, is an example of an operating system suited for use in a client computer.
• Microsoft's Windows NT® operating system is an example of an operating system suitable for a server computer.
• a plurality of application programs typically execute from memory 42.
• active application programs include an Internet browser such as Microsoft's Internet ExplorerTM.
• active applications include a database management system such as SQL*Server, Oracle, and Internet Information Server.
• the invention includes a method of finding data in the server-maintained database 16.
• one of clients 14 submits a search value to server 12.
• the search value is of the information type contained in one of the key fields of database records.
• the server is responsive to the submission of the search value to identify and return data from a limited set of database records which are likely to most closely match the submitted search value.
• Such a set of database records is referred to as a page of database records, and the data return from " this record page is referred to as a data page.
• the server To identify a single record page in response to a search value, the server maintains and references a plurality of page definitions. Each page definition indicates at least one pair of key values. When given a particular search value, the server performs a step of identifying one of the page definitions that corresponds to the search value. The server then searches the database to find a page or set of database records whose key values are bounded by the key values indicated by the identified page definition. Data from these records is then returned to the client as a data page. The records are optionally sorted before they are returned to the user. For instance, names might be sorted alphabetically before returning them to the user.
• the page definitions are preferably stored in a searchable table on a storage media accessible by the server and serviced by the DBMS and referred to herein as a page definition table.
• a page definition table Such a table is designated by reference numeral 20 in Fig. 1.
• the page definition table has a plurality of individual entries or rows. Each entry contains a pair of key values: a LOWER key value and an UPPER key value. In this embodiment of the invention, these key values are used as both index key values and as bounding key values. The difference between these types of key values will become apparent in the discussion below relating to a second embodiment of the invention.
• Table 3 illustrates an example of a page definition table that corresponds to the example database used in the discussion above:
• Each entry of the page definition table corresponds to a set of database records having key values that are bounded by the LOWER and UPPER key values of the entry. More specifically, a single set of database records corresponding to a particular entry of the page definition table comprises all records having a key values that are (a) equal to or greater than the LOWER key value of the entry and (b) less than the UPPER key value of the entry.
• the first entry has a LOWER key value of "a” because "a” is the lexicographically first possible key value in this system (this value will differ depending on the type of data). It has an UPPER key value of "Beaver.”
• a set of database records corresponding to this entry thus includes all names prior to Beaver in an alphabetical list.
• a set of database records corresponding to the second entry includes all names in the range between "Beaver” and "Bowman” ("Bowman” is the name in the database that precedes "Bratsanos”).
• the LOWER key value for the first entry is a value that is equal to or less than any possible search value.
• the UPPER key value for the last entry of the table is a value that is equal to or greater than any possible search value (again, this value will differ depending on the type of data contained in the database).
• the page definition table is defined based on a desired size and division of information. With alphabetical information, it might be desired to have a single page of information for each letter of the alphabet, which would eliminate the need for the page definition table. However, it will often be desired to have coarser or finer divisions, so that an appropriate or approximately equal amount of data will correspond to each page table entry. This is especially true for large data sets. Good examples of simple page definition tables are the tabs of dictionaries or address books (A-B XYZ etc).
• this table is different than the table shown above in Table 1.
• Table 3 does not specify an ID number. Just the LOWER and UPPER key values are specified. In addition, the UPPER key value of each row is the same as the LOWER value for the next row. This prevents certain search values from falling between table entries — any possible and allowed search value will fall within the key values of one of the entries.
• the server searches the page definition table to identify a row or entry that corresponds to the search value. Specifically, the server finds the entry having LOWER and UPPER key values that surround the search value. Even more specifically, the server finds the single entry for which it is true that (a) the search value is equal to or greater than the LOWER key value of the entry and (b) the search value is strictly less than the UPPER key value of the entry.
• the server performs a search or query of the database to identify the set of database records whose key values are bounded by the key values of the identified table entry.
• This set comprises all records having a key values that are (a) equal to or greater than the LOWER key value of the entry and (b) less than the UPPER key value of the entry. Data "from these records is returned as a response to the client's request for data.
• the database will in most cases have a plurality of fields other than the key fields.
• the values returned to the client are not necessarily the key values from the identified set of database records. Rather, any group of field values can be returned from the set of database records once the appropriate set of database records is identified. In most cases, however, the group of field values returned for each record will include values from the key field.
• the server returns the LOWER and UPPER key values that were used to identify the set of database records. This state information is then stored by the client, and used by the client to formulate subsequent queries or requests for finding additional sets or pages of database records that neighbor the set that was initially found.
• a step 100 comprises submitting a search value from a server to a client.
• the search value corresponds to a key field in a database maintained by the server.
• the server performs a step 102 of referencing a plurality of page definitions to identify one of the page definitions that corresponds to the supplied search value.
• each page definition indicates a pair of key values, wherein each pair includes an UPPER key value and a LOWER key value.
• the page definitions are preferably stored as entries in a table.
• step 102 comprises searching for a table entry whose pair of key values surrounds the supplied search value — where the search value falls between a range defined by the LOWER and UPPER key values, inclusive of the LOWER key value.
• a step 104 comprises searching the database to find a set of database records whose key values are bounded by the key values of the page definition identified in step 102. Specifically, this step is formulated to return all records having key values between the LOWER and UPPER key values of the identified page definition, inclusive of the LOWER key value.
• a step 106 comprises returning data from the identified set of database records to the client. This step includes returning the key values from the page definition identified in step 102.
• the client can derive new search values based on the returned key values. Such new search values are submitted to the server in order to browse through different page of database records.
• the latter of the two preceding query statements can return any data contained in the database records, without requiring regeneration of any tables. There is no need to predefine the returned fields, as is the case in the prior art.
• the query is formulated to return a full name and address for each record in the selected page of database records.
• queries can be formulated and submitted by the server, or they can be formulated and submitted directly from a client.
• the queries are performed by the server, and data is returned in HTML format.
• LOWER previous_upper
• the closest matches to the search value can be positioned consistentl near the beginning, near the middle, or near the end of the returned data, although typically it would be desired to display the data near the beginning. For example, once a targeted data page is determined, that data page and the following data page could be returned. For further user convenience, it is also desirable to highlight the closest match to the user-specified key value.
• the page definitions can be configured to include two pairs of key values: a pair of index key values and a pair of bounding key values.
• the index key values are used to find the page definition corresponding to the search value, and the bounding key values are used to define the bounds of database records to be returned to the client.
• This alternative scheme can also be used to position the closest matching records near arbitrary location in the returned data, such as near the beginning, middle, or end.
• Table 4 illustrates a page definition table in accordance with this alternative embodiment of the invention:
• Each page definition table entry includes both a pair of index key values and a pair of bounding key values.
• the index key values are used when identifying which table entry corresponds to a search value. Specifically, the entry whose LOWER index key value is equal to or less than the search value and whose UPPER index key value is greater than the search value is the entry that corresponds to the search value.
• the index key values are configured exactly as in Table 3: the pairs form an ordered sequence, wherein the UPPER key value of a particular pair is the same as the LOWER key value of a subsequent pair. This prevents search values from falling between pairs of index key values.
• the bounding key values are used when querying the database for a set of records. Once a table entry is identified, the database is queried for all records whose key values fall between the bounding entries of the identified table entry.
• the bounding values of a particular table entry preferably span the index entries of the same entry.
• the index key values are "Bratsanos" and "Cheng.” Search values between these values (inclusive of "Bratsanos") will result in this table entry being selected. However, the data returned will correspond to all database records whose key values are between "Borgman” and "Conway.” Thus, the bounding range is larger than the index range for any particular entry.
• the bounding key values for a particular entry might be identical to the index key values for the entry. This special case is actually implemented by the previous example of Table 3; where the index key values and the bounding key values are equal to each other, only one pair of values needs to be listed in the page definition table.
• data that most closely matches the search value can be biased toward one portion of the search results. For example, if the LOWER bounding key value is equal to the LOWER index key value and the UPPER bounding key value is much greater than the UPPER index key value, the closest matches will be biased toward the beginning of the returned data.
• the client When returning data, either the bounding keys, the index keys, or both are returned to the client.
• the client can then submit a new search criterion to the server, based on these values, to browse to a different set of database records as described above.
• returned index key values are used to formulate a new search query.
• the server can control the position of the searched word in the data returned to the client. If it is desired for the key value (or its closest match) to be the first record returned, earlier records can simply be omitted from the returned search results. In other words, the earlier records can be "truncated" off of the results of the second query before returning them to the client. In order to do this, selecting the "previous" records must return those records that were truncated off. So the first request for a previous set of records would probably not return the previous set, but rather the original untruncated first set.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Physics & Mathematics (AREA)
• Computational Linguistics (AREA)
• Data Mining & Analysis (AREA)
• Databases & Information Systems (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Mathematical Physics (AREA)
• Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Priority Applications (3)

Applications Claiming Priority (2)

Publications (1)

Family

ID=25356680

Family Applications (1)

Country Status (5)

Families Citing this family (21)

Citations (2)

Family Cites Families (10)

• 1997
  • 1997-06-09 US US08/871,079 patent/US6061677A/en not_active Expired - Lifetime
• 1998
  • 1998-06-01 AU AU78065/98A patent/AU7806598A/en not_active Abandoned
  • 1998-06-01 JP JP50271199A patent/JP4425355B2/ja not_active Expired - Fee Related
  • 1998-06-01 EP EP98926166A patent/EP1010101A1/en not_active Withdrawn
  • 1998-06-01 WO PCT/US1998/011199 patent/WO1998057278A1/en not_active Ceased
• 2000
  • 2000-03-28 US US09/538,854 patent/US6519587B1/en not_active Expired - Lifetime
• 2009
  • 2009-10-02 JP JP2009230853A patent/JP4542195B2/ja not_active Expired - Lifetime

Patent Citations (2)

Also Published As

Similar Documents

Legal Events