probabilistic ranking


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

probabilistic ranking

  1. 1. Supporting Ranking in Queries Score-based Paradigm Russell Greenspan CS 411 Spring 2004
  2. 2. Supporting Ranking in Queries Talk Outline <ul><li>What </li></ul><ul><li>Why </li></ul><ul><li>How </li></ul><ul><ul><li>“Out-of-the-box” support </li></ul></ul><ul><ul><li>“Smart” top- k processing </li></ul></ul>
  3. 3. Ranking in Queries What is ranking in queries? <ul><li>A mechanism to return only the top- k results </li></ul><ul><ul><li>Closest matches to user-specified boolean criteria </li></ul></ul><ul><ul><li>Scoring results based on user-specified predicates </li></ul></ul><ul><ul><ul><li>SELECT Address FROM HousesForSale ORDER BY Best(Size, Price) </li></ul></ul></ul><ul><li>Express similarity, relevance, or preference to a given query </li></ul>
  4. 4. What is ranking in queries? Definitions <ul><li>Intuitive </li></ul><ul><ul><li>Output an ordered list of k items such that the list includes only those items whose scored rank is greater than the items not included </li></ul></ul><ul><li>Formal </li></ul><ul><ul><li>“ Given retrieval size k and scoring function F , a ranked query returns a list K of k objects (i.e. | K | = k ) with query scores, sorted in a descending order, such that F(t 1 , ..., t n ) [u] > F(t 1 , ..., t n ) [ v ] for all u in K and all v not in K .” [Chang, Hwang, 2002] </li></ul></ul>
  5. 5. What is ranking in queries? Differences from traditional queries <ul><li>How does this differ from traditional queries? </li></ul><ul><ul><li>Traditional queries: </li></ul></ul><ul><ul><ul><li>Do not stop processing until all results are computed </li></ul></ul></ul><ul><ul><ul><li>Do not focus on ranking tuples to best match the input query </li></ul></ul></ul><ul><ul><li>Traditional boolean queries: </li></ul></ul><ul><ul><ul><li>Do not return “close” matches </li></ul></ul></ul><ul><ul><ul><li>Can “over” or “under” match, producing too few or too many results </li></ul></ul></ul>
  6. 6. Ranking in Queries Why use ranking in queries? <ul><li>Exact matches not required </li></ul><ul><ul><li>Often times something “close enough” satisfies a user’s demands </li></ul></ul><ul><li>Fuzzy matches desired </li></ul><ul><ul><li>Multimedia/image matching, where the very nature of the query does not involve an exact match </li></ul></ul><ul><li>Avoid unnecessary computations </li></ul><ul><ul><li>Find the “best” answers quickly as opposed to all answers </li></ul></ul>
  7. 7. Ranking in Queries How do we use execute ranked queries? <ul><li>“Out-of-the-box” support </li></ul><ul><ul><li>Perform query as any other, then perform sort and return only first k rows </li></ul></ul><ul><ul><li>Why is this bad? </li></ul></ul><ul><ul><ul><li>Lots of unnecessary processing </li></ul></ul></ul><ul><ul><ul><li>Waste of resources in intermediate results </li></ul></ul></ul><ul><ul><ul><li>If scoring function is expensive, could result in computation of unneeded scores </li></ul></ul></ul><ul><li>Can we do better? </li></ul>
  8. 8. How do we use execute ranked queries? “Smart” Ranked Query Execution <ul><li>Query Processing </li></ul><ul><ul><li>Try to achieve significant reduction in query execution time </li></ul></ul><ul><ul><li>Use mid-query (i.e. as query executes) techniques to optimize query plan for top- k results </li></ul></ul><ul><ul><li>Consider minimal amount of tuples necessary to return k results </li></ul></ul><ul><li>Scoring Predicate </li></ul><ul><ul><li>Consider expense of scoring function in determining optimal query plan </li></ul></ul>
  9. 9. “ Smart” Ranked Query Execution Two Areas of Research Focus <ul><li>Top- k processing </li></ul><ul><ul><li>Reducing number of tuples considered at each intermediate step </li></ul></ul><ul><ul><ul><li>Assume minimal work necessary to retrieve items sorted by score (i.e. indexes on simple attributes) </li></ul></ul></ul><ul><li>Rank function </li></ul><ul><ul><li>Reducing number of calls to ranking function </li></ul></ul><ul><ul><ul><li>Assume rank calculation is expensive </li></ul></ul></ul><ul><ul><li>Implementing unusual ranking function </li></ul></ul>
  10. 10. “ Smart” Ranked Query Execution Research and Techniques <ul><li>Reducing number of tuples considered </li></ul><ul><ul><li>Middleware/Multimedia </li></ul></ul><ul><ul><ul><li>Garlic [Fagin, 1999] </li></ul></ul></ul><ul><ul><ul><li>CHITRA [Nepal, Ramakrishna, 1999] </li></ul></ul></ul><ul><ul><li>Relational </li></ul></ul><ul><ul><ul><li>STOP Operator [Carey, Kossmann, 1997] </li></ul></ul></ul><ul><ul><ul><li>Probabilistic [Donjerkovic, Ramakrishnan, 1999] </li></ul></ul></ul><ul><ul><ul><li>Statistical [Chaudhuri, Gravano, 1999] </li></ul></ul></ul><ul><li>Reducing number of calls to ranking function </li></ul><ul><ul><li>MPro [Chang, Hwang, 2002] </li></ul></ul><ul><li>Implementing unusual ranking function </li></ul><ul><ul><li>AutoRank [Agrawal, Chaudhuri, Das, Gionis, 2003] </li></ul></ul>
  11. 11. “ Smart” Ranked Querying (Middleware) – Garlic [Fagin, 1999] <ul><li>Integrates data from different database systems or non-database data servers </li></ul><ul><ul><li>Relational Query Set vs. “Sorted List” </li></ul></ul><ul><ul><ul><li>Example: “Return the reddest covers of Beatle’s albums” i.e. (Artist = ‘Beatles’) AND (AlbumColor LIKE ‘red’) , where Artists are stored relationally and Album colors in a multimedia database </li></ul></ul></ul><ul><li>Assign grade to each object </li></ul><ul><ul><li>Boolean grade either 0 or 1 </li></ul></ul><ul><ul><li>Fuzzy value 0<= x <=1 indicating closeness </li></ul></ul>
  12. 12. Garlic [Fagin, 1999] Rank Processing Methods <ul><li>How to combine two fuzzy values to retrieve top- k objects? </li></ul><ul><ul><li>Inefficient </li></ul></ul><ul><ul><ul><li>Consider graded sets of all objects by color and shape </li></ul></ul></ul><ul><ul><ul><li>Compute combined score for every object, then output top k objects </li></ul></ul></ul><ul><ul><li>Efficient </li></ul></ul><ul><ul><ul><li>Retrieve objects (sorted by grade) from each subsystem until there are at least k of the same objects in each set </li></ul></ul></ul><ul><ul><ul><li>Compute combined score for each of these k objects </li></ul></ul></ul>
  13. 13. Garlic [Fagin, 1999] Example Query <ul><li>Example: (use combined scoring function = x * y) Return Top 2 Color = ‘red’ AND Shape = ‘round’ </li></ul>.4 H .7 G .1 F .9 E .2 D .3 C .8 B .6 A Roundness Object .3 H .9 G .5 F .3 E .8 D .1 C .6 B .2 A Redness Object
  14. 14. Garlic [Fagin, 1999] Inefficient vs. Efficient Processing <ul><li>Inefficient </li></ul><ul><ul><li>Calculate combined score for every object </li></ul></ul><ul><ul><li>Sort by score </li></ul></ul><ul><ul><li>Return top k objects </li></ul></ul><ul><ul><ul><li>{G, B} </li></ul></ul></ul>.12 H .63 G .05 F .27 E .16 D .03 C .48 B .12 A Score Object
  15. 15. Garlic [Fagin, 1999] Inefficient vs. Efficient Processing <ul><li>Efficient (Fagin’s A 0 algorithm) </li></ul><ul><ul><li>Consider ordered members from each set until there are k of the same object in each set </li></ul></ul><ul><ul><ul><li>A 1 = {G (.9) , D (.8) , B (.6) } </li></ul></ul></ul><ul><ul><ul><li>A 2 = {E (.9) , B (.8) , G (.7) } </li></ul></ul></ul><ul><ul><li>Calculate combined score for each of the k objects </li></ul></ul><ul><ul><ul><li>G = .9 * .7 = .63 </li></ul></ul></ul><ul><ul><ul><li>B = .6 * .8 = .48 </li></ul></ul></ul><ul><ul><li>Return these objects ordered by combined score </li></ul></ul><ul><ul><ul><li>{G, B} </li></ul></ul></ul>
  16. 16. Garlic [Fagin, 1999] Conclusions <ul><li>Why is this more efficient? </li></ul><ul><ul><li>Incur expense of scoring function k times, as opposed to n times (where n is the total number of items) </li></ul></ul><ul><ul><li>Access each subsystem at least k and at most n times, as opposed to n times (again, where n is the total number of items) </li></ul></ul>
  17. 17. “ Smart” Ranked Querying (Middleware) – CHITRA [Nepal, Ramakrishna, 1999] <ul><li>Expands on Fagin’s GARLIC system by proposing new “multi-step” processing algorithm </li></ul><ul><li>Experimental results show 50% improvement </li></ul>
  18. 18. CHITRA [Nepal, Ramakrishna, 1999] “Multi-step” Algorithm <ul><li>Consider first sorted item x from each subsystem i </li></ul><ul><li>Perform random access into every other subsystem to obtain other rankings of x </li></ul><ul><li>Add object to result set if its rank is greater than the threshold grade, quit when we have k objects </li></ul><ul><ul><li>Threshold is score of all objects considered each iteration </li></ul></ul>
  19. 19. CHITRA [Nepal, Ramakrishna, 1999] Example Query <ul><li>Back to our example... Return Top 2 Color = ‘red’ AND Shape = ‘round’ </li></ul>.4 H .7 G .1 F .9 E .2 D .3 C .8 B .6 A Roundness Object .3 H .9 G .5 F .3 E .8 D .1 C .6 B .2 A Redness Object
  20. 20. CHITRA [Nepal, Ramakrishna, 1999] Example Scoring Functions Results <ul><li>Consider two scoring functions as examples: </li></ul><ul><ul><li>min[x, y] </li></ul></ul><ul><ul><li>[x * y] </li></ul></ul>B = min[.6, .8] = .6 G = min[.7, .9] = .7 D = min[.8, .2] = .2 B = min[.8, .6] = .6 G = min[.9, .7] = .7 E = min[.9, .3] = .3 Grade {G, B} min[.6, .7] = .6 i1 = {B(.6)} i2 = {G(.7)} 3 min[.8, .8] = .8 i1 = {D(.8)} i2 = {B(.8)} 2 min[.9, .9] = .9 i1 = {G(.9)} i2 = {E(.9)} 1 Resultset Threshold Items Iter. B = [.6 * .8] = .48 G = [.7 * .9] = .63 D = [.8 * .2] = .16 B = [.8 * .6] = .48 G = [.9 * .7] = .63 E = [.9 * .3] = .27 Grade {G, B} [.6 * .7] = .43 i1 = {B(.6)} i2 = {G(.7)} 3 [.8 * .8] = .64 i1 = {D(.8)} i2 = {B(.8)} 2 [.9 * .9] = .81 i1 = {G(.9)} i2 = {E(.9)} 1 Resultset Threshold Items Iter.
  21. 21. CHITRA [Nepal, Ramakrishna, 1999] Conclusions <ul><li>Why is this more efficient? </li></ul><ul><ul><li>Requires fewer accesses to each subsystem </li></ul></ul><ul><li>How do we know this algorithm is correct? </li></ul><ul><ul><li>Proof by contradiction </li></ul></ul><ul><ul><ul><li>Assume object z which should have been included </li></ul></ul></ul><ul><ul><ul><li>If Rank(z) > Rank(y) , either: </li></ul></ul></ul><ul><ul><ul><ul><li>y must have at least one subsystem rank smaller than all subsystem ranks of z </li></ul></ul></ul></ul><ul><ul><ul><ul><li>z must have at least one subsystem rank greater than all subsystem ranks of y </li></ul></ul></ul></ul><ul><ul><ul><li>However, since Rank(z) < Threshold and Rank(y) >= Threshold , Rank(z) cannot be greater than Rank(y) </li></ul></ul></ul>
  22. 22. “ Smart” Ranked Querying (Relational) – STOP Operator [Carey, et al, 1997] <ul><li>Specifies extension to SQL-92 standard to allow limit on cardinality of result </li></ul><ul><ul><li>STOP AFTER </li></ul></ul><ul><li>Return subset of results from each section of query plan </li></ul><ul><li>Implement with STOP operator </li></ul><ul><ul><li>STOP(N, D, E) where N is the number of desired tuples, D is the Sort Directive [asc, desc, none], and E is the Sort Expression </li></ul></ul><ul><ul><li>Heuristically determine when and how to apply </li></ul></ul>
  23. 23. STOP Operator [Carey, et al, 1997] Example query plans <ul><li>Fig a shows traditional JOIN </li></ul><ul><ul><li>Join all EMP to DEPT, sort, output top k </li></ul></ul><ul><li>Fig b shows implementation of STOP operators </li></ul><ul><ul><li>Based on cardinality estimates, only 20 rows of EMP need be joined with 30 rows of DEPT to produce top- k of 10 </li></ul></ul>
  24. 24. STOP Operator [Carey, et al, 1997] Conservative Heuristic <ul><li>Ensures that every tuple in each intermediate result is guaranteed to generate at least one tuple of the overall query result </li></ul><ul><li>Advantages </li></ul><ul><ul><li>No restarts from intermediate processing returning fewer than k results </li></ul></ul><ul><ul><li>Intermediate STOP operators take their N value from overall query k value </li></ul></ul><ul><li>Disadvantages </li></ul><ul><ul><li>Only inserts STOP operators where all remaining predicates are non-reductive (cannot use with multi-way joins) </li></ul></ul>
  25. 25. STOP Operator [Carey, et al, 1997] Aggressive Heuristic <ul><li>Applies STOP operator wherever it may be beneficial, thus reducing intermediate results to a greater degree </li></ul><ul><li>Choose N value using cardinality estimates </li></ul><ul><li>Requires RESTART operator when intermediate processing returns too few results </li></ul>
  26. 26. STOP Operator [Carey, et al, 1997] Experimental Results <ul><li>Which heuristic is better? </li></ul><ul><ul><li>Depends on cardinality, expense of processing intermediate results, accuracy of prediction, etc. </li></ul></ul><ul><ul><li>With low expense of processing intermediate results, experimental results show aggressive overestimation the best: </li></ul></ul>18.5 sec 63.1 sec 63.9 sec 128.3 sec Aggressive, Overestimate (10) Aggressive, Underestimate (1/10) Conservative Traditional
  27. 27. STOP Operator [Carey, et al, 1997] Experimental Results <ul><li>Performance vs. Traditional (“out-of-the-box”) processing shows benefits in both indexed and non-indexed situations </li></ul>
  28. 28. “ Smart” Ranked Querying (Relational) – Probabilistic [Donjerkovic, et al, 1999] <ul><li>Introduces idea of ‘selection cutoff’ to produce top k results without requiring SORT </li></ul><ul><li>Quantifies the risk of fewer than k results being generated using inherent database statistics </li></ul><ul><ul><li>List the top 10 paid employees becomes List the employees whose salary is greater than x where x is determined by the distribution of employees’ salaries </li></ul></ul>
  29. 29. Probabilistic [Donjerkovic, et al, 1999] Comparison with STOP Operator <ul><li>In theory, likely to be cheaper to simply ‘select’ the necessary intermediate rows using cutoff (fig b) rather than performing sort and returning top- k (fig a) </li></ul>
  30. 30. Probabilistic [Donjerkovic, et al, 1999] Implementation <ul><li>Leverage same statistics used by traditional query optimizer to guess cutoff </li></ul><ul><ul><li>Histograms </li></ul></ul><ul><ul><li>Selectivity factors </li></ul></ul>
  31. 31. Probabilistic [Donjerkovic, et al, 1999] Performance <ul><li>For simple query using no indexes (return k highest paid employees, no index on ‘Salary’ attribute), easily outperforms traditional (scan, sort, return top k ) </li></ul><ul><li>Also provides benefit to JOIN queries due to complexity of estimating join selectivity </li></ul>
  32. 32. “ Smart” Ranked Querying (Relational) – Statistical [Chaudhuri, Gravano, 1999] <ul><li>Expansion of probabilistic model </li></ul><ul><li>Maps rank queries into boolean range queries </li></ul><ul><li>Works with a variety of scoring functions, including Min , Euclidean , and Sum </li></ul>
  33. 33. Statistical [Chaudhuri, Gravano, 1999] Expansion of probabilistic model <ul><li>Consider multiple levels of ‘selection cutoff’, here referred to as ‘search score’ (S q ) </li></ul><ul><ul><li>NoRestarts – score low enough to guarantee no restarts are even needed </li></ul></ul><ul><ul><li>Restarts – score high enough that restarts might result </li></ul></ul><ul><ul><li>Intermediate – score between NoRestarts and Restarts </li></ul></ul>
  34. 34. Statistical [Chaudhuri, Gravano, 1999] Implementation <ul><li>Determine S q from histograms </li></ul><ul><ul><li>Choose bounding tuples in each bucket to ensure NoRestarts (fig a) or tight tuples to minimize selection but potentially require Restarts (fig b) </li></ul></ul>
  35. 35. Statistical [Chaudhuri, Gravano, 1999] Implementation <ul><li>Determine relational query to retrieve all tuples that score above S q </li></ul><ul><ul><li>Compute n -rectangle bounding such tuples </li></ul></ul><ul><ul><li>SELECT * FROM R WHERE (a 1 <=A 1 <=b 1 ) ... AND ... (a n <=A n <=b n ) </li></ul></ul><ul><li>Compute score for all returned tuples </li></ul><ul><li>Output top- k tuples with score > S q or rerun query with lower search score </li></ul>
  36. 36. Statistical [Chaudhuri, Gravano, 1999] Expansion of Fagin’s model <ul><li>Expands Fagin’s ideas to relational queries </li></ul><ul><ul><li>Substitute ‘search score’ query to determine top tuples for each subsystem </li></ul></ul><ul><ul><li>Use NoRestarts strategy to ensure that expensive re-querying is avoided </li></ul></ul>
  37. 37. “ Smart” Ranked Querying (Rank) – MPro [Chang, Hwang, 2002] <ul><li>Extends consideration of top- k querying to expensive predicates (monotonic only) </li></ul><ul><ul><li>As opposed to other work, which assumes the expense of score calculation to be minimal </li></ul></ul><ul><li>Attempt to minimize the number of scores calculated </li></ul><ul><ul><li>Consider only Necessary Probes , i.e. only those calculations without which the top- k results cannot be found </li></ul></ul>
  38. 38. MPro [Chang, Hwang, 2002] Determining if probe is necessary <ul><li>An object’s lowest calculated score represents “ceiling score” (i.e. it is impossible for any other score for that object to raise its lowest score) </li></ul><ul><li>If “ceiling score” falls below top- k object’s complete score, object is ruled out and no further calculations on the object need be performed </li></ul><ul><li>Simple Example: </li></ul><ul><ul><li>Consider scoring function like Min and top-1 results desired </li></ul></ul><ul><ul><li>If we know object A’s combined rank with respect to F(x) and F(y) is .8, and we calculate object B’s score with respect to F(x) to be .7, B’s score with respect to F(y) need not be calculated (its Min value cannot be higher than .7) </li></ul></ul>
  39. 39. MPro [Chang, Hwang, 2002] Determining all necessary probes <ul><li>Only objects with ceiling scores in the top- k need be further evaluated </li></ul><ul><li>If objects are kept in sorted order by current ceiling scores: </li></ul><ul><ul><li>For any object u in the top- k slots, its next probe is necessary </li></ul></ul>
  40. 40. MPro [Chang, Hwang, 2002] Minimal Probes Algorithm (MPro) <ul><li>Priority queue initialization </li></ul><ul><ul><li>Evaluate each object over first predicate (same as sequentially accessing objects sorted by x ) </li></ul></ul><ul><li>Necessary probing </li></ul><ul><ul><li>Request from queue the object with highest ceiling score </li></ul></ul><ul><ul><li>Evaluate object over next predicate y </li></ul></ul><ul><ul><li>Update ceiling score and reinsert into queue </li></ul></ul><ul><li>Stop when at least k objects have been completely scored (and output these objects) </li></ul>
  41. 41. MPro [Chang, Hwang, 2002] Further Applications <ul><li>Incremental results </li></ul><ul><ul><li>Output top k , resume processing where it left off for next k as user requests </li></ul></ul><ul><li>Fuzzy joins </li></ul><ul><ul><li>Consider join predicate in same manner </li></ul></ul><ul><li>Parallel processing </li></ul><ul><ul><li>Distribute necessary probes across multiple servers </li></ul></ul><ul><ul><li>Distribute data, calculate top-n over each chunk, merge results </li></ul></ul>
  42. 42. MPro [Chang, Hwang, 2002] Experimental Results <ul><li>On experimental dataset, over 96% of complete probes found to be unnecessary </li></ul><ul><li>Elapsed time significantly improved (see below), from 21009 to 408 seconds for k = 10 </li></ul>
  43. 43. “ Smart” Ranked Querying (Rank) – AutoRank [Agrawal, et al, 2003] <ul><li>Consider ranking of relational attributes in similar way to Information Retrieval (IR) </li></ul><ul><ul><li>IDF Similarity </li></ul></ul><ul><ul><ul><li>Extend TF-IDF based on frequency of occurrence of attribute values </li></ul></ul></ul><ul><ul><li>QF Similarity </li></ul></ul><ul><ul><ul><li>Use database workload to determine frequency with which attributes and attribute values are referenced </li></ul></ul></ul><ul><ul><ul><li>“Poor man’s relevance feedback” </li></ul></ul></ul><ul><ul><li>ITA </li></ul></ul><ul><ul><ul><li>Index-based top- k algorithm that exploits above ranking functions </li></ul></ul></ul>
  44. 44. AutoRank [Agrawal, et al, 2003] IDF Similarity <ul><li>Extend TF (term frequency) </li></ul><ul><ul><li>IR – frequency of terms in a document </li></ul></ul><ul><ul><li>Relational – frequency of values for an attribute </li></ul></ul><ul><li>Extend IDF (inverse document frequency) </li></ul><ul><ul><li>IR – total documents / documents containing term </li></ul></ul><ul><ul><li>Relational – tuples / tuples where attribute = value </li></ul></ul><ul><li>For all tuples matching the queried value, IDF Similarity is the attribute’s IDF (for the queried value), and 0 otherwise </li></ul>
  45. 45. AutoRank [Agrawal, et al, 2003] Q F Similarity <ul><li>Consider problem of IDF where desired result is also the most frequent </li></ul><ul><ul><li>Realty database where homes built in the last three years are most desired, but the few entries existing for old homes (with higher IDF ) will be considered “top” </li></ul></ul><ul><li>Instead, use frequency of occurrence of attribute values in executed queries to determine ranking (by examining workload) </li></ul><ul><li>Can extend workload analysis to draw comparative conclusions from attribute values queried together </li></ul><ul><ul><li>Assume similarity between ‘Honda’ and ‘Toyota’ if users frequently look for cars by either of these manufacturers </li></ul></ul>
  46. 46. AutoRank [Agrawal, et al, 2003] Implementation <ul><li>Store approximate representations of IDF and QF values using smooth function </li></ul><ul><ul><li>Minimal storage required </li></ul></ul><ul><ul><li>IDF and QF values can be quickly retrieved at runtime </li></ul></ul><ul><li>ITA (Index-based Threshold Algorithm) </li></ul><ul><ul><li>Use available, existing indexes (B+ trees) </li></ul></ul><ul><ul><li>Define threshold by computing best tuple in data not yet examined </li></ul></ul><ul><ul><li>Stop processing when similarity of this tuple is no greater than similarity of lowest ranking tuple in top- k buffer </li></ul></ul>
  47. 47. AutoRank [Agrawal, et al, 2003] Experimental Results <ul><li>Used large realtor database from and MS- SQL Server </li></ul><ul><li>Measured result-quality via user studies </li></ul><ul><ul><li>For each test query, asked users to identify relevant and irrelevant tuples and compared results of QF and IDF queries to users’ responses </li></ul></ul><ul><li>ITA judged to be more efficient than SQL Server’s Top- k operator when indexes exist </li></ul>
  48. 48. Conclusions <ul><li>Clearly, an exciting and worthwhile field </li></ul><ul><li>Research has gone in several directions but all shares roots in Fagin and Carey’s work </li></ul><ul><li>Combines many areas of computer science </li></ul><ul><ul><li>Artificial Intelligence (Fuzzy Logic) </li></ul></ul><ul><ul><li>Information Retrieval </li></ul></ul>
  49. 49. The Future <ul><li>Implementation in major RDBMS vendors </li></ul><ul><ul><li>Microsoft should be among the first to revamp their Top-K operator, as in-house research [Agrawal, et al, 2003] has provided a smarter, faster technique </li></ul></ul><ul><li>Explore more complex ranking functions that cannot be easily mapped to range queries or used with indexes </li></ul>
  50. 50. References <ul><li>M. J. Carey and D. Kossmann. On saying “enough already!&quot; in SQL . 1997 SIGMOD Conference: 219-230, 1997. </li></ul><ul><li>D. Donjerkovic, R. Ramakrishnan. Probabilistic Optimization of Top N Queries . VLDB 1999: 411-422, 1999. </li></ul><ul><li>R. Fagin. Combining Fuzzy Information from Multiple Systems . PODS 1996: 216-226, 1996. </li></ul><ul><li>S. Nepal, M. V. Ramakrishna. Query Processing Issues in Image (Multimedia) Databases . ICDE 1999: 22-29, 1999. </li></ul><ul><li>Surajit Chaudhuri, Luis Gravano. Evaluating Top-k Selection Queries . VLDB 1999: 397-410, 1999. </li></ul><ul><li>K.C. Chang, S. Hwang. Minimal Probing: Supporting Expensive Predicates for Top-k Queries . SIGMOD Conference 2002: 346-357, 2002. </li></ul><ul><li>Sanjay Agrawal, Surajit Chaudhuri, Gautam Das, Aristides Gionis. Automated Ranking of Database Query Results . CIDR 2003, 2003. </li></ul>