Query-based searching using a virtual table

A method of searching all tables in a data model is disclosed, using a non-materializing virtual table interface that acts as a view into the underlying data model. The virtual table is virtually built on the fly at query execution time, and maps to all columns and rows within the data model. A query on the virtual table is translated into a set of data model queries for searching the data model, based on columns selected from the virtual table and other specified search parameters, as well as the virtual table definition. The search process works in conjunction with data domains, and uses compaction and tokenization of data.

BACKGROUND

The present invention pertains generally to the field of database querying. Many business enterprises generate large amounts of electronic data that are archived for a variety of purposes. Examples include archiving transaction data for auditing, customer service or data mining uses. A business enterprise may also be required to archive electronic data for regulatory purposes.

The enterprise data typically is created and stored within one or more data warehouses spread out over multiple tables in a database or multiple databases. Searching these multiple sources typically requires that the data storage is built and indexed in full, at which point queries can be run against the data, often in a piecemeal format querying each column of the database. Thus, queries of all tables in a database or across database often requires knowledge of the underlying database structure, maintenance to keep tables in sync, pre-processing, and index building. In addition, queries using a typical model often require heavy processing and are redundant over data common between the tables. In the context of keyword searching, searches alternatively can be performed on documents, but this process requires data extraction and synchronization to ensure data integrity.

SUMMARY

A method of searching all tables in a database uses a non-materializing virtual table interface that acts as a view into the underlying data model of the database. In this way, multiple tables can be consolidated into a virtual table without having to build and maintain a new table structure in the database. The virtual table is virtually built on the fly at query execution time, so no pre-processing is required and no additional procedures are needed to keep data in synch. In addition, because the virtual table maps to all columns and rows within the data model, there is no need for the querying user to know the underlying data structure.

A query on the virtual table is translated into a set of data model queries for searching the data model, based on columns selected from the virtual table, data type of searched constant and other specified search parameters, as well as the virtual table definition. The search process works in conjunction with data domains, which store only unique values, to prevent redundant searching of data duplicated across tables. In addition, compaction and tokenization of data speeds up the search process.

The method is performed using a set of computer-executable modules according to one embodiment. A virtual table module defines a virtual table that is not physically present in the data model. A query translation module receives a query indicating the virtual table, and translates the query into a set of data model queries, and passes the set of data model queries to a search process. An ID files module uses a metadata database to identify which compacted files may have archived data that will satisfy a received query. A search agent module accesses each identified stored compacted file to determine if there are any actually data stored in the compacted file that will satisfy the original query. A result module builds a search result based on the search results received from the search agents. A result processing module receives results of the set of data model queries and processes the results based on the selected one or more columns of the virtual table and any ordering rules to produce a result set.

DETAILED DESCRIPTION

FIG. 1is a block diagram of a searchable archive system in an archiving mode in accordance with one embodiment of the present invention. A searchable archive system includes a searchable archive host100. The searchable archive host hosts an archiving process102. The archiving process receives or gets archive data104from a database106, such as a tabular file in a format such as a Comma Separated Value (CSV) formatted text file, coupled to the searchable archive host. The archiving process extracts metadata107describing the archive data from the archive data and stores the metadata in a metadata database108. The archiving process also generates one or more compacted files, such as compacted files109aand109b, that are stored in one or more compacted file data storage devices, such as compacted file storage devices110aand110b.

As illustrated inFIG. 1, the storage devices are coupled directly to the searchable archive host. In other embodiments, the storage devices are loosely coupled to the storage devices through a communications network. This enables the searchable archive to be distributed across as many storage devices as necessary to storage the compacted files. In addition, the loose coupling between the metadata and the compacted files allows the searchable archive to be added to in an incremental manner without requiring reconstituting the original archive data using the compacted files.

FIG. 2Ais a block diagram of a searchable archive system in a data retrieval mode in accordance with one embodiment of the present invention. Once an archive is created, a user200or an automated process may access the compacted files without reconstituting the entire original archive data structure. To do so, the user uses a search process204hosted by the searchable archive host. The user submits a query202to the search process. According to another embodiment, the query202is one or more data model queries received from a separate process203, e.g., via the process1200as described in conjunction withFIG. 12. The search process uses a metadata database108to identify which compacted files may have archived data that will satisfy the query. The search process then accesses each identified stored compacted file to determine if there are any actually data stored in the compacted file that will satisfy the original query. The search process does so through the use of one or more search agents, such as search agents205aand205b, that independently access one or more compacted files stored in the compacted file storage devices, such as storage devices110aand110b.

Each search agent conducts an independent search, such as search206aby search agent205aand search206bby search agent205b, of one or more compacted files identified by the search process. Each search agent also independently reports search results, such as search results208aand208b, back to the search process. The search process uses the search results received from the search agents to build a search result210that is presented to the user.

FIG. 2Bis a flow diagram of a searchable archive creation process in accordance with one embodiment of the present invention. A searchable archive creation process218receives archive data104including one or more columns of values, such as columns220,222, and224. The number of columns in the archive data, and the number of values in the columns, is arbitrary as indicated by ellipses227. The process associates (225) the columns of data in one or more domains, such as domains226and228. Each domain may then be associated with one or more columns of data from the archive data.

After associating the columns to domains, each domain is processed separately to generate columns of tokens corresponding to the value columns in a tokenization process. For example, token column230is associated with domain226and corresponds to value column220in the archive data. In a similar manner, token column232is associated with domain226and corresponds to value column222. In this example, two domains are shown. Domain228is associated with only a single token column234corresponding to value column224in the archive data. Ellipses236indicate that the number of domains and associated token columns is arbitrary as the number of columns in the archive is arbitrary.

Once the domains and token columns have been created, they are compressed in a compaction process237to create a compacted file238. Within the compacted file, information about the domains included in the compacted file is stored in a domains header240. In addition, domain data for each domain is stored in the compacted file. For example, domain data242corresponds to domain226created during the tokenization process and domain data248corresponds to domain228. The domain data includes a domain structure associating unique values from the archive data to token values used to generate the token columns. The compacted file further includes compressed token column data, such as compressed token column data244,246, and250for each token column associated to a domain. For example: compressed token column data244corresponds to token column230; compressed token column data246corresponds to token column232; and compressed token column data250corresponds to token column234. Ellipses252indicated that the size of the compacted file is arbitrary as it is dependent on the size of the original archive data set.

During the tokenization and compaction process, archive metadata and segment metadata107is extracted236for use as an index for accessing the compacted file. The metadata may exported in a variety of formats that may be useful an archive retrieval process.

FIG. 3is a block diagram of a compacted file creation process in accordance with one embodiment of the present invention. In a compacted file creation process, a portion of an archive data set104associated with a domain includes one or more value columns, such as value columns300aand300b, of tabulated values. Ellipses300cindicate that the number of value columns in the archive data set is arbitrary. Each value column may be characterized by a value column header302and one or more rows of tabulated values, such as rows306aand306b. Ellipses306cindicate that the number of rows in the value columns are arbitrary.

During the archive creation process, the archive data set is tokenized308. During tokenization, the values in a value column are replaced with tokens to create a token column. If the length of the token is less than the length of the unique value, then the overall size of the column of data will be reduced, thus compressing the archive data set. For example, in the block diagram, a tokenized data set310is generated from the archive data set104during tokenization. The tokenized data set retains the column formation of the archive data set. In the example, token column312acorresponds to archive value column300aand token column312bcorresponds to archive value column300b. Ellipses312cindicate that the number of token columns correspond to the number of value columns in the original archive data. In each token column, a token exists for each value in the original corresponding archive data value column. For example, token314acorresponds to value306aand token314bcorresponds to value306b. Ellipses314cindicate that the number of tokens in a token column correspond to the number of values in the archive data's corresponding column.

In addition to a tokenized data set, tokenization creates a domain structure316associating the token values and the unique values. The domain structure includes the sorted unique values318extracted from the archive data. Their position inside the list is their associated token value. In addition, as the unique values are stored in sorted form, their position in the table also indicates a lexical id for their corresponding token values. This feature of a domain structure is illustrated by lexical id column320shown in phantom.

Once the tokenized data set has been created, opportunities exist to optimize323the size of the tokenized data set. For example, before the domain structure is complete, it is difficult to determine the optimal size of the tokens because the number of tokens needed to represent the unique values in the archive data is unknown. However, after the domain structure316is complete, the total number of tokens, and therefore the optimal size for the tokens, can be easily calculated. Once the optimal token size is determined, the tokens in the tokenized data set may be replaced with a new set of optimally sized tokens thus creating an optimized token data set325.

The optimized domain structure is compacted369by dividing the domain structure into one or more compressed domain structure segments, such as compressed domain structure segments370and371, in compacted file375. The number and size of the domain structure segments depends on the number of unique values in the domain structure. During compaction, the domain structure is examined to determine how to divide the domain structure into individual compressed domain structure segments. The determination is based on the desired size of the compressed domain structure segments and the number of unique values in the domain structure. For example, if a domain structure has very few unique token values, it may compress to a small size and may fit within one compressed domain structure segment. In contrast, if a domain structure contains many unique values, more than one compressed domain structure segment is used to hold the compacted domain structure.

For each domain structure segment, the minimum and maximum values are kept for the domain structure segment. As no value exists in more than one domain structure segment, the minimum and maximum values constitute a coarse index that is used to determine which domain structure segments should be used when searching for a particular unique value. The segments are then individually compressed using a prediction by partial matching (PPM) algorithm. This type of algorithm uses the last few characters of a value to predict the next character and is well suited for compression of the domain structure because the unique values are already sorted.

In the illustrated compacted file375, the compacted file includes domain D1 having a domain structure divided into two compressed domain structure segments370and371. An offset372indicates the position in the compacted file of a compressed domain structure segment. In addition, a minimum value374and a maximum value376indicate the range of unique values included in the compressed domain structure segment.

After tokenization and optimization, the optimized tokenized data set is compacted (326) and stored in the compacted file375as well. For each token column in the tokenized data set one or more compressed token column segments are created. The number and size of the compressed token column segments depends of the numbers of tuples (records) of the archive data set. For each compressed token column segment, starting and ending tupleid are recorded. As there is a low degree of correlation between the tokens stored in the token columns, a statistic algorithm based on arithmetic coding is used for the creation of the compressed token column segments.

As an example, in the illustrated compacted file375, the compacted file includes compressed token column segments358,360, and362corresponding to token column312awhich corresponds to value column300a. For each compressed token column segment, a minimum tupleid366and a maximum tupleid368are indicated. Compressed token column segments are located in the compacted file for each token column associated with the domain.

Once completed, the compacted file375includes compressed domain structure and token column data. During the tokenization and compaction process, domain metadata, token column metadata, and segment metadata is extracted (390) from the domain structure and the token columns. Portions of the extracted metadata is included in the compacted file as a header accessible without decompressing any of the segments in the compacted file. Portions of the archive metadata are also included in a metadata file332. The metadata file may be used by a data processing system to access data stored in the compacted files.

An exemplary metadata file332is illustrated in an eXtensible Markup Language (XML) format; however, any format may suffice. In the metadata file, metadata is included to show metadata extracted from a first and second domain; however, the number of domains is arbitrary. Within an XML format metadata file, a “Domains” tag346includes one or more domain tags348. Each domain tag includes a “Domain name” attribute350and a “columns” attribute352. The columns attribute indicates the number of token columns in a domain. A “count” attribute353indicates the number of total unique values stored in the domain structure. A “length” attribute355indicates the length of the unique value storage locations within the domain structure.

A “Columns” tag354includes one or more column tags356. Each column tag includes a “Column name” attribute357indicating the name of a value column from the archive data included in the compacted file. The column tag further includes a “domId” attribute359indicating the domain to which the column belongs. A “min” attribute361indicates the minimum unique value found in the column. A “max” attribute363indicates the maximum unique value found in the column.

Referring again toFIG. 1once the compaction process is completed, a compacted file375(ofFIG. 3) is stored in a file system having one or more compacted file data stores, such as compacted file data store110aand110b. Metadata file332(ofFIG. 3) is used to populate a metadata database108. As the compacted files are stored in a file system, new archive data may be added to the archive system to the capacity of the file system. In addition, metadata may be added to the metadata database to the extent of the capacity of the metadata database.

FIG. 4is a block diagram of a tokenization process in accordance with one embodiment of the present invention. In the illustrated tokenization process, an archive data set400includes a “First Name” column402. In this illustration, each unique First Name column entry is replaced by an eight bit token. For the First Name column, a “First Name Tokens” domain structure406is created. The domain structure has a name column408for storage of unique first names encountered in the archive data set. The domain structure includes a token column410for storage of tokens assigned to the unique values.

In this example, the name “John”412is the first unique value in the column and is replaced by the token “00000010”414in the tokenized data set416. An entry is made into the domain structure for the unique value “John”418and the assigned token value “00000010”420. For each subsequent unique value in the column, a new token value is generated, associated with the unique value in the domain structure, and used to replace the unique value in the tokenized data set.

In the case where the unique value is encountered in the archive data again, a new token value is not generated. Instead, the token value is read from the domain structure and inserted into the tokenized data set. In the illustrated example, the unique value “Susan”422appears in the archive data more than once. The value Susan is associated in the domain structure with the token “00000101”424. This token is then inserted into the tokenized data set two times, at location426and428, to represent the two instances of Susan in the original archive data.

FIG. 5is a block diagram of a token optimization process and tokenized data set compaction process in accordance with one embodiment of the present invention. Once a tokenized data set is created from the archive data, the number of tokens needed to represent all of the unique values in the archive data is known. Therefore, an optimal size can be determined for the size of the tokens used. In the example ofFIG. 4, an eight bit token is used. An eight bit token can represent up to 256 unique values. However, at the end of the tokenization process, it can be seen that the number of unique values in the example was only six. Therefore, a three bit token is all that is required to give each unique value a unique token value. Referring again toFIG. 5, domain structure406is optimized by replacing eight bit tokens500in the token column with three bit tokens. This generates an optimized domain structure having three bit tokens502. In a similar manner, tokenized data set416from the example inFIG. 4is optimized by replacing eight bit tokens504with three bit tokens506.

Once the tokenized data set has been optimized, it may be compacted508to generate a compacted file510. During the compaction process, previously described metadata512is extracted from the tokenized data set.

FIG. 6is a process flow diagram of a search process employing search agents in accordance with one embodiment of the present invention. As previously described, search agents, such as search agents205aand205b(ofFIG. 2), are used within the archive system to access the compacted files and retrieve archive data. The search agents are invoked by a search process204(ofFIG. 2). At the start601of a search process, the search process receives602a query603from a user or an automated process. The search process uses a domain structure605to decompose606the query into an equivalent tokenized query. According to one embodiment, the query received602is from a set of data model queries604produced by the process described in conjunction withFIG. 12, transmitted to the search process in step1245.

The search process accesses metadata107to determine611which compacted files, domains, and columns need to be searched to find archived data that may satisfy the query. The search process does so by using the minimum and maximum token values extracted from the columns in a compacted file before the columns were segmented and compressed. These minimum and maximum values are compared to the token values in the tokenized query to make the determination. Once the determination is complete and compacted files have been selected, the search process invokes612one or more search agents, such as search agents613aand613b, that will independently access the identified compacted files. Ellipses613cindicate that an arbitrary number of independently functioning search agents may be invoked by the search process. This allows the search process to search a plurality of compacted files independently. In addition, as search agents are used to access the compacted files, the compacted files may be maintained in any convenient manner and loosely coupled to the search process.

The following search agent process is described for a single search agent; however, each invoked search agent will perform similar search processes in parallel. Once invoked, each search agent accesses616a compacted file614and searches the compacted for archived data that may satisfy the query. To do so, the search agent reads the compacted file's header to determine which domain structure segments may contain data that may satisfy the query. As the compacted file's header includes the minimum and maximum token values stored in each compressed domain structure segment, the search agent may determine which segments may include data that will satisfy the query. Once a compressed segment has been identified as possibly containing the desired data, the search agent decompresses618the selected compressed segment and searches the decompressed segment for the requested data and identifies the token associated with the values involved into the request criteria. The process is repeated for each compressed segment identified by the search agent as potentially containing the desired archive data. After that process, token representation of the request criteria is used to analyze each tokenized dataset segment involved. The search agent returns620any result data found during the search to the search process. The search process collects all of the returned results to generate a final search result624and stops626searching. According to one embodiment, the result624is transmitted625back to the process described in conjunction withFIG. 12, where it is received at step1250.

FIG. 7is a block diagram illustrating a bit vector based compaction method in accordance with one embodiment of the present invention. In this compaction method, the compacted file may be searched in its entirety without decompressing any of the data stored in the compacted file. Archive data700having multiple columns of data is tokenized and optimized as previously described. In this example, the archive data is a listing of first and last names of a group of individuals with the first names in a first archive value column702and the last names in a last name archive value column704. The result of the tokenization and optimization process is a tokenized and optimized data set706. The tokenized data set includes a first name token column708corresponding to the first name archive value column and a last name token column710corresponding to the last name archive value column. The tokenized data set may be compressed through the generation of a set of bit vectors712.

Each bit vector in the set of bit vectors corresponds to a token. The length of each bit vector is equal to the number of token values in a token column. The values in the bit vector reflect the presence or absence of the corresponding token at a particular position in the token column. For example, bit vector718corresponds to the token “011” in the first name token column. Token “011” appears at the fifth position in the first name token column; therefore, a “1” appears in the fifth position in bit vector718. As token “011” corresponds to the name “Mary” in the first name column of the archive data, this means that the name “Mary” is the fifth entry in the first name value column of the archive data set. In a similar manner, bit vector724corresponds to the last name “Adams” in the last name value column of the archive data set. Upon completion of the vectorization process, the compacted file consists of subsets of bit vectors with each subset corresponding to a token column in the tokenized data set and thus a column in the archive data set. In this example, bit vector subset714corresponds to the first name value column702in the archive data and bit vector subset716corresponds to the last name value column704in the archive data.

One feature of the tokenization process is that it creates a lexical ordering of the values in a column of an archive data set. As such, the bit vectors need not be stored with header information identifying which bit vector is associated with which token. Instead, the bit vectors are stored in a compact fashion in the lexical order of the tokens.

FIG. 8Ais block diagram illustrating the use of Boolean operations on bit vectors to generate query results in accordance with one embodiment of the present invention. The bit vectors ofFIG. 7may be used directly in Boolean operations to satisfy queries. As an example, a query for the name “Mary Adams” may be decomposed into a query expression800of “First Name=Mary” AND “Last Name=Adams.” This expression may be evaluated for the entire compacted file712(ofFIG. 7) by selecting bit vector716corresponding to the first name “Mary” and bit vector724corresponding to the last name “Adams”. These bit vectors may be combined in a Boolean AND operation802to yield a result bit vector804. This bit vector has a “1”806in the fifth position indicating that the name “Mary Adams” is found in the compacted file.

FIG. 8Bis a block diagram showing a different illustration of a bit vector based compaction method according to one embodiment, as used in conjunction with selection criteria for a query. As inFIG. 7, this method allows the compacted file to be searched in its entirety without decompressing any of the data stored in the compacted file. Domain810shows Domain1(D1 as later described in conjunction withFIGS. 15 and 16). An abbreviated list of domain values are shown, with their corresponding entity IDs (EIDs).

Selection criteria corresponding to a query are applied to the domain to provide an entity selection vector (ESV)820. In this example the SQL query is:

SELECT *FROM DATA_DISCOVERY.FAS_DDWHERE VALUE LIKE ‘%10%’
Thus, a criterion is that the value include “10” (wild cards on each side). The ESV820is a bit vector, with each bit value representing the presence or absence of a value in each row corresponding to the selection criteria. For example, since the rows corresponding to EIDs1,5,6, and10of domain810are the rows that include a value corresponding to “like %10%,” those rows have a 1 in the ESV, whereas the other rows have a 0.

Next, the ESV820is promulgated to the underlying customer table830to create the row selection vector (RSV)840, which will be used to select rows to return as results based on the query parameters. Again, EIDs1,5,6, and10correspond to ESV820values of 1, thus the corresponding rows in RSV840for these EIDs in the D_D1 column are shown as 1, i.e., the third, fourth, sixth, and seventh entries in RSV840. The remaining rows are shown as 0, and thus will not be selected. Referring also toFIG. 16, a result set for a query specifying a parameter “value like %10%” across three domains is shown, with the top four rows corresponding to the rows selected via RSV840inFIG. 8B.

FIG. 9is a process flow diagram of a search agent process for an archive system using compacted files having bit vectors in accordance with one embodiment of the present invention. The operation of a search process204(ofFIG. 2) is similar whether or not a compacted file uses bit vectors or compressed segments. However, the operations of a search agent, such as search agent205a(ofFIG. 2), are different depending on whether or not the compacted file accessed by the search agent includes bit vectors or compressed segments. A search agent900used with compacted files having bit vectors is invoked901by a search process. The search agent accesses a compacted file902selected by the search process. The search agent then selects (904) one or more bit vectors corresponding to a datum that the search agent is searching for. The search agent then performs a Boolean operation on the selected bit vectors to determine if the data in the compacted file satisfies a query received from the search process204(ofFIG. 2). At the completion of the Boolean operation, a bit vector is created to act as a selector which is used to identify which tuples should be returned. Based on the projection list, list of columns or attributes to be returned in the request, and the bit vector record selector, the search agent materializes the result data. The materialization of the result data is executed doing an inversion process where the token ID of the desired tuples are replaced with the value using a lookup function is used to implement it. At the completion of that materialization process, the search agent returns906any results to the invoking search process. Bit vector processing in general is discussed in greater detail in U.S. Pat. No. 5,036,457 issued to Glaser et al. the contents of which are hereby incorporated by reference as if stated in full herein.

FIG. 10is an architecture diagram of a data processing apparatus used as an archive system host in accordance with one embodiment of the present invention. The data processing apparatus includes a processor1000operably coupled to a main memory1002by a system bus1004. The processor is further coupled to a storage device1012through an Input/Output (I/O) control unit1006, an I/O local bus1008, and a storage device controller1010. The storage device may be used to store programming instructions1016.

In operation, the processor loads the programming instructions (which may take the form of software modules as described in conjunction withFIG. 11below) from the storage device into the main memory. The programming instructions are then executable by the processor to implement the features of an archiving system as described herein. The storage device may also be used to store data1014used by the processor to implement the features of the archive system.

The processor may be further coupled to a communications device1018via the Input/Output (I/O) control unit, the I/O local bus1008, and a communications device controller1018. The processor may then communicate with other data processing systems or file system for retrieval of compacted files.

FIG. 11is a block diagram showing software modules for orchestrating the processes described herein according to one embodiment. The modules in this embodiment include archiving modules1120, search modules1130, and mapping modules1140.

The archiving modules1120provide functionality for the archiving process102as discussed in conjunction withFIGS. 1 and 2B. The archiving modules1120include a data retrieval module1150, a domain and metadata module1155, and a compaction module1160.

The data retrieval module1150retrieves archive data as described herein, e.g., from database106, and is one means for performing this function. The domain and metadata module1155extracts metadata from the archive data as described herein and stores the metadata, e.g., in metadata database108, and is one means for performing this function. The domain and metadata module1155also associates columns of data into one or more domains, and processes each separately to generate columns of tokens corresponding to the value columns in a tokenization process, e.g., as described in conjunction withFIGS. 7,8A, and8B.

The compaction module1160generates compacted files as described herein, which are stored in one or more compacted file data storage devices, e.g., devices110aand110b, and is one means for performing this function. The domains and token columns created by the domain and metadata module1155are compressed to create the compacted file(s).

The search modules1130provide functionality for the search process204as discussed in conjunction withFIG. 2A. The search modules1130include an ID files module1165, a search agent module1170, and a result module1175.

The ID files module1165uses a metadata database to identify which compacted files may have archived data that will satisfy a received query as described herein, e.g., a query received at step602ofFIG. 6, and is one means for performing this function.

The search agent module1170accesses each identified stored compacted file to determine if there are any actually data stored in the compacted file that will satisfy the original query as described herein, and is one means for performing this function. The search agent module1170uses one or more search agents, which independently access one or more compacted files stored in the compacted file storage devices, and independently reports search results back to the search process.

The result module1175builds a search result based on the search results received from the search agents as described herein, and is one means for performing this function. The result module1175then presents the results back to the querying user or process.

The mapping modules1140provide functionality for the virtual table-based searching process1200as discussed in conjunction withFIG. 12. The mapping modules1140include a virtual table module1180, a query translation module1185, and a result processing module1190.

The virtual table module1180defines a virtual table that maps to data but is not physically present in the data model as described herein, and is one means for performing this function. Explicit creation of the virtual table is not required. A module called <Data_Discovery_Module> is called with the search query as a parameter, e.g., using SQL as described in conjunction with step1210ofFIG. 12.

The query translation module1185receives a query indicating the virtual table, and translates the query into a set of data model queries as described herein, and is one means for performing this function. The query translation module1185also may pass the set of data model queries to the search process204ofFIG. 6, according to one embodiment.

The result processing module1190receives results of the set of data model queries, e.g., from the search process204ofFIG. 6, and processes the results based on the selected one or more columns of the virtual table and any ordering rules to produce a result set as described herein, and is one means for performing this function.

One skilled in the art will recognize that the system architecture illustrated herein is merely exemplary, and that the invention may be practiced and implemented using many other architectures and environments. In addition, the processes performed by the system architecture require an implementation on a computer, and cannot be performed in the human mind by mental steps alone.

FIG. 12is a flowchart describing a method of searching a data model using a virtual table according to one embodiment. The method allows a keyword search to be performed on the tables and columns of an underlying data model, e.g., the archive data set104as described herein.

The method begins by obtaining1210a definition of a virtual table. In one embodiment, the virtual table module1180performs this step. As known in the art, a virtual table is “virtual” in the sense that it is not physically present in the data model. Rather, it is an interface to existing storage that appears to be, and functions as if it is, a table, but it does not store any data. The virtual table thus can be thought of as a “view” into the underlying data model.

The virtual table concept is use to create an abstraction layer on the data model to enable search requests to be executed without knowledge of the data model. A simple table eliminates the need for the user to understand the underlying data model. The virtual table acts as a template for a search request built over the data model, which allows for construction of the data model queries and enables definition of the lookup scope, if required, so the user query can be received as a single conventional full text query, but then mapped to the underlying queries. This process enables the creation of selection criteria using a universal object, which can be analyzed and transformed into specific underlying queries. The virtual table enables a user to exclude/include portion of the data model via selection of virtual table columns. The use of the virtual table format also provides a uniform result set over distinct data models and formats.

In the examples described herein, the virtual table has the following virtual columns, based upon the information that will be included in the columns of the result data set following step1260below:SCHEMA (a schema name where the result is found);TABLE (a table name where the result is found);COLUMN (a column name where the result is found);UROWID (the UROWID of the row containing the result); andVALUE (the content of the column where the result is found).

The virtual table definition specifies a name, typically in the form SCHEMA_NAME.TABLE_NAME. The virtual table used in the examples herein is DATA_DISCOVERY.FAS_DD. A query to the name of the virtual table initiates the search process described below. This example shows a single FAS (File Archive Service) instance. However, the same FAS instance could support any number of databases and this process allows searching across the databases using this technique. To simplify the data type mapping explanation, the following exemplary virtual table creation is described. However, explicit creation of the virtual table is not required. A module called <Data_Discovery_Module> is called with the search query as a parameter, e.g., using the SQL form presented below.

In the next step, a query is received1220by query translation module1185, indicating the virtual table. According to one embodiment, the query is in the form of a Structured Query Language (SQL) query, and specifies a SELECT clause, FROM clause, and a WHERE clause. The SELECT clause may specify one or more of the virtual columns above: SCHEMA, TABLE, COLUMN, UROWID, and/or VALUE, or “*” to select all columns. The FROM clause is used to designate the virtual table by its predefined name. The virtual table is not physically present in the database, but its name triggers the virtual table mode.

The WHERE clause specifies one or more parameters for the query, and in one embodiment specifies keywords for the search of the underlying data model. The WHERE clause may contain any expressions involving any of the above-mentioned columns except for UROWID and sub-queries. Also, the GROUP BY clause is not allowed. The VALUE column has no data type explicitly associated with it but is mapped to a VarChar data type to be described and exported to standard SQL front end tools.

In order to narrow the lookup scope, the WHERE clause may specify constraints against the SCHEMA, TABLE and COLUMN virtual table columns. While processing the request, only those columns from archive tables which type satisfy the semantic correctness of the WHERE clause condition will be considered as the lookup candidates. Optionally, an ORDER BY clause may refer to SCHEMA and/or TABLE and/or COLUMN, and specify the ordering of the result set by column.

In addition, the type of columns optionally may be specified that are to be involved in the lookup by using function CheckType(<column>, <TYPE SPEC>). This function returns1if <column> has type of <TYPE SPEC> and 0 otherwise. <TYPE SPEC> specifies the type as one of the following: INTEGER; SMALLINT; DECIMAL[(prec[,scale])]—if prec or scale not specified, the type is not verified against the missing part; DOUBLE; REAL; CHARACTER[(wid)]—if wid not specified, the type is not verified against the missing part; VARCHAR[(wid)]—if wid not specified, the type is not verified against the missing part; DATE; TIME; or TIMESTAMP. Alternatively, the type verification function can be specified as: TYPE (<column>)=/< ><TYPE_SPEC> or TYPE (<column>) in/not in (<TYPE_SPEC>[,<TYPE_SPEC>, <TYPE_SPEC>, . . . ]).

By way of example, suppose the desired query will discover the values for which the rightmost four characters of each database entry, converted into integers, is greater than 10. In addition, the query will limit to tables which names contain CLT and inside the columns which names end in ID and which are of CHAR/VARCHAR/INTEGER/SMALLINT types only. Finally, the result should be sorted by table name in ascending order and by column name in descending order.

The corresponding SQL query would be:

In line 1, the SELECT clause is indicated and will limit the query to the columns TABLE, column, UROWID, and VALUE. Line 2 indicates the FROM clause, and indicates the DATA_DISCOVERY.FAS_DD virtual table, having a table definition as set forth above. Line 3 indicates the beginning of the WHERE clause, and indicates that the table names should be limited to those that have “CLT” in the title (% being wild cards on each side of “CLT”) and column names limited to those that end in ID (% as wild card before ID). Line 4 indicates that columns of the type CHAR, VARCHAR, INTEGER, and SMALLINT should be returned. Line 5 indicates that values for which the rightmost four characters converted into integers will be greater than 10. Line 6 indicates that the results will first be ORDERED BY table (ascending as default), and then by column (descending).

A second example is the SQL query:

In this example, all columns are selected (*), the DATA_DISCOVERY.FAS_DD virtual table is specified as above, and the data returned should be limited to integers with a value between 100 and 300 based on three (3) characters starting at the second (2) character in the value. The results that are returned by the result processing module1190after step1260for this example are shown inFIG. 13. Note that in the VALUE column, each value fits the above constraints, namely that starting with the second character, the next three characters have a value between 100 and 300. E.g., for row 1 value P11111 the value (underlined) is 111, for row 2, value P22222, the value (underlined) is 222, etc.

Referring again toFIG. 12, the query received1220is next translated1230into a set of data model queries. This step is performed by query translation module1185according to one embodiment. The data model queries are generated based on the search parameters specified in the WHERE clause, type checks (if any), and the underlying data model as specified by the definition of the virtual table. These queries rely upon the inter-relationship between domains and columns, as described elsewhere herein.

More specifically, a given search request is first parsed such that its constraints are classified into two groups: search expressions and data model scope. Search expressions are the constraints applied to the VALUE column of the virtual table DATA_DISCOVERY.FAS_DD. The data model scope includes the constraints applied to the SCHEMA_NAME, TABLE_NAME, OR COLUMN_NAME columns of the virtual table. Next, the search scope is defined. The search expression is evaluated to identify potential data type constraints for search pruning. For example, if the constant is of the type “Alpha Numeric,” which could not be translated into a Numeric or Date/Time data type, it is possible to eliminate from the search scope any Numerical or Date/Time domain/column data type. Continuing the search scope definition, the data model scope constraints, in conjunction with the data type constraint noted above, are applied to the data model to define the scope of the search. A look up request is executed on the system catalog to identify each potential column to analyze:

Next, the search request is executed:

For each Domain DiExecute the search expression to select the list of unique valueswhich qualify namedDi.ESVFor Each Column Cj in DiForm a query in the form ofINSERT INTO “Data_Discovery”.”Fas_DD” (“Schema”, “Table”,“Column”, “uRowId”, “Value”)SELECT ‘Schema_Name’, ‘Table_Name’, ‘Column_Name’,RowId, Column_NameFROM Schema_Name.Table_NameWHERE Column_Name in Di.ESV

By way of example, assume the following table/column/domain structure:

FIG. 14shows these three tables, i.e., T1, T2, and T3. The tables have been simplified to three rows each for purposes of this example.

In this example, the SQL query is:

Using this query, the data model queries that the received query is translated1230into are as follows:

For D2, where the data is of type DEC (decimal), in the translation the value is stated as “=10” instead of “%10%” as used in the CHAR (character strings). The replicated sub-queries (shown in parentheses) for a specific domain are executed only once to produce an entity selection vector (ESV). The ESV is then used on each table specified in the WHERE clause including a column associated with the domain to produce a row selection vector (RSV), e.g., via the process described in conjunction withFIG. 8a. The data shown inFIG. 8acorresponds to Domain D1 from the above example.

The result set for this example (i.e., the result of step1260) is shown inFIG. 16, and will be described in greater detail in conjunction with step1260below.

Once the received query is translated1230into data model queries, the data model is searched1240using the data model queries. According to one embodiment, the data model queries are provided1245as input into602of the search process as described in conjunction withFIG. 6. In this embodiment, the search modules1130provide the search functionality as described elsewhere herein. In this embodiment, the search is processed as inFIG. 6, and then results of the search are received1250from the search process.

Finally, the results of the data model queries are processed1260to produce a result set. This step is performed by result processing module1190according to one embodiment. One such result set was shown inFIG. 13, described above. In addition, the result set for the data model queries shown above is shown inFIG. 15. That result set has five columns: SCHEMA, TABLE, COLUMN, UROWID, and VALUE. Recall from the example that the parameter specified was WHERE “VALUE LIKE ‘%10%’.” Each row in the result set thus has a value that includes the digits10in it, in any location for D1 and D3 (character strings) and value equal to 10 for D2 (decimal). Thus, the result set shown inFIG. 16provides the SCHEMA, TABLE, COLUMN, UROWID, and VALUE for each value from T1, T2, and T3 that met the parameter “%10%” (D1 and D3) or “=10” (D2).