W. Kim. On optimizing an SQL-like nested query. ACM Trans. on Database Systems, 7(3):443--469, Sep 82.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....the query plan ahead of the user while waiting for the next DOM traversal step, we do not consider such speculative execution in this paper. 4 The Decorrelation Plan Space Decorrelation has been studied in the context of generating equivalent executions for correlated SQL queries in [6, 11, 15, 24]. In all previous work of which we are aware, plans are decorrelated when possible on the heuristic assumption that the decorrelated execution can be optimized better. On the contrary in ROLEX, when the navigation profile indicates that a node will seldom be visited, correlated execution may be ....

....query would also be parametrized by z, that is Q x (z) The decorrelated query Q x (z) can then be decorrelated further to eliminate the parameter z and thereby obtain Q yz x . Each of these decorrelated queries may be a candidate for further query transformations like those described in [15]. Since these transformations are standard in the literature on query processing, we do not present details here. 4.2 Multi Parameter Decorrelation The extension of the technique above to tag queries with multiple parameters is straightforward. Consider a tag query Q x (s 1 ; s 2 ; s k ....

W. Kim. On optimizing an SQL-like nested query. ACM Transactions on Database Systems, 7(3):443--469, Sept. 1982.

....the query plan ahead of the user while waiting for the next DOM traversal step, we do not consider such speculative execution in this paper. 4 The Decorrelation Plan Space Decorrelation has been studied in the context of generating equivalent executions for correlated SQL queries in [6, 11, 15, 24]. In all previous work of which we are aware, plans are decorrelated when possible on the heuristic assumption that the decorrelated execution can be optimized better. On the contrary in ROLEX, when the navigation profile indicates that a node will seldom be visited, correlated execution may be ....

....above decorrelated query would also be parametrized by , that is . The decorrelated query can then be decorrelated further to eliminate the parameter and thereby obtain . Each of these decorrelated queries may be a candidate for further query transformations like those described in [15]. Since these transformations are standard in the literature on query processing, we do not present details here. 4.2 Multi Parameter Decorrelation The extension of the technique above to tag queries with multiple parameters is straightforward. Consider a tag , ....

W. Kim. On optimizing an SQL-like nested query. ACM Transactions on Database Systems, 7(3):443--469, Sept. 1982.

....i.e. setorientation was mostly out of their scope. The database was queried in a navigational manner along the references defined between the database objects (e.g. path expressions in OPAL [33] By now a lot of research focuses on full fledged query languages for object oriented database models [22, 44]. Seen from a more general point of view the upcoming object oriented query languages exploit facilities to query along predefined relationships (in [6] called functional join) as well as to use traditional value based relational join capabilities. The functional join facility resembles the ....

W. Kim, On Optimizing an SQL-like Nested Query, in: ACM TODS 7 (1982) 443-469.

....in pipeline. Each node operator in a pipe starts execution as soon as the operator(s) producing its input have output enough data for it to start; until these data are produced, the consumer waits. The initial query tree is built by a preoptimizer, which performs unnesting of nested queries [14], transforms disjunctions into unions, and places selection nodes below join nodes on the same relations. Set operations are placed below the root projection and separated from the nodes containing predicates by further projections. So, projections, selections, and joins form PSJ subtrees, in ....

....than the square root of the processor s memory size, the hash algorithm of Shapiro [24] is used. Otherwise, projections are introduced to sort the input relations, and the merge join is used. The inner relation or hash table for classic joins is selected as the largest one fitting in memory [14]. The inner relation for semijoins is the one not retained in the output. The inner relation of an antijoin or outerjoin is determined by the operator s semantics [14] 2] and cannot be changed. For restrictions, we consider two algorithms, one used when the input relation comes sorted on the ....

[Article contains additional citation context not shown here]

W. Kim, "On Optimizing an SQL-Like Nested Query," ACM Trans. Database Systems, vol. 7, no. 3, pp. 443--469, 1982.

....queries to concrete evaluation algorithms. We are presenting a new XML algebra and a query optimization framework based on query normalization and query unnesting (also known as query decorrelation) There are many proposals on query optimization that are focused on unnesting nested queries [23, 18, 26, 11, 12, 9, 28]. Nested queries appear more often in XML queries than in relational queries, because most XML query languages, including XQuery, allow complex expressions at any point in a query. Current commercial database systems typically evaluate nested queries in a nested loop fashion, which is unacceptable ....

W. Kim. On Optimizing an SQL-like Nested Query. ACM Transactions on Database Systems, 7(3):443{ 469, September 1982.

.... been noted that the nested form is often easier for users to formulate and to understand [12] Existing research (on nested queries) has sought methods of reducing the evaluation costs, typically by transforming a nested query into a logically equivalent form that can be evaluated more efficiently [2, 3, 10]. However, the class of nested queries with aggregates is especially interesting. First, such queries are commonly encountered. For example, to list employees who are high earners where highearners are defined as a certain factor of the average salaries of employees, requires a nested query ....

....with an example to reiterate the motivation behind online aggregation, i.e. to provide fast response of (approximate) answers to users. Before that, we shall review the two types of nested queries with aggregates that are relevant to our work. 2. 1 Types of Nested Queries with Aggregates In [10], Kim presented a classification of nested query types, two of which involve aggregates in the inner query block. For illustration, we shall use the example of a large admissions database that records information on persons (of different nationalities) applying to graduate business schools. The ....

[Article contains additional citation context not shown here]

W. Kim. On optimizing an sql-like nested query. ACM Transactions on Database Systmes, 7(3), September 1982.

....rules to guide semantic reasoning makes our optimizer extensible in a manner that is complementary to the extensibility benefits of existing rule based technology. 1 Introduction Query optimizers are hard to build. In the past, relational optimizers have proved to be brittle and error prone [17]. The added complexity of objects and hence object queries makes the task of building object (i.e. object oriented and object relational) database optimizers that much more difficult. It is now accepted practice to use software engineering techniques when building optimizers. For example, many ....

W. Kim. On optimizing an SQL-like nested query. ACM Transactions on Database Systems, 7(3):443--469, September 1982.

....list is considered each time) Furthermore, a set of types belonging to the set SourceSchema, denoting all the types found in the data sources, are treated as source nodes of a graph. For the rest of the types, we can derive an SQL expression by using existing view reduction algorithms, such as [33] corrected with the results of [19, 44, 45] 14, 11, 41, 48, 36] Our algorithm is applicable to graphs of activities that do not involve updates. In most cases, an update operation can be considered as the combination of insertions and deletions or as the application of the appropriate function ....

Won Kim. On Optimizing an SQL-like Nested Query. ACM Trans. On Database Systems 7(3): 443-469 (1982)

....P Fig. 26. Application of Partial Evaluation Techniques to Agent Programs Another area of research that is very closely related to ours is query optimization in relational and deductive databases [Graefe 1995; Haas et al. 1989; Ioannidis and Kang 1990; Graefe 1993; Ibaraki and Kameda 1984; Kim 1982; Mumick et al. 1996] and in mediators [Adali et al. 1996; Levy et al. 1996a; Haas et al. 1997; Ambite Improving Performance of Heterogeneous Agents Delta 47 and Knoblock 2000; Duschka et al. 2000] It is worth noting that this list is not exhaustive since over the last decades, enormous effort ....

Kim, W. 1982. On optimizing an sql-like nested query. ACM Transactions on Database Systems 7, 3 (September), 443--469.

....oo perspective. The optimization of nested queries in the oo context should clearly use the vast body of knowledge on optimizing nested relational queries. Departing from the evaluation of nested SQL queries through nested loops [1] Kim proposed transforming SQL nested queries at the SQL level [19]. The leading tread behind the proposed transformations is to convert nested queries into joins so that a standard optimizer can work efficiently. However, there exist some major differences between nested queries and joins that are, as stated in [12] the creation of duplicates and the way empty ....

.... may appear in any clause: the result clause (typically select, or retrieve) the range clause (typically from or range) and the selection clause (typically where) This implies that we have to consider queries that do not match any of the types introduced for classifying nested relational queries [19]. Third, nested queries in the oo context do not always correspond to algebraic operations (e.g. method calls, path expressions) and we have to find an appropriate treatment for these nested expressions as well. While the above considerations seem to complicate the issues, there also exists one ....

[Article contains additional citation context not shown here]

W. Kim. On optimizing an SQL-like nested query. ACM Trans. on Database Systems, 7(3):443--469, Sep 82.

....description of the class of queries for which it is safe. Correctness then requires ensuring that the transformation is safe for each query in its associated class. For complex transformations, identification of this class can be difficult, even if queries are confined to queries over relations. Kim82] proposed transformations to unnest four different classes of nested queries over relations. Kie84] later showed that the classes of queries proposed contained some whose semantics were changed by their corresponding transformations. The most famous example of this is the well known COUNT ....

....will not be represented in the preprocessed collection Temp. Thus, Rep. Sanders will fail to satisfy the join predicate with all entries in Temp and will be excluded from the second query s result. This discrepancy in query results is very similar to that which led to the COUNT bug of [Kim82] In fact, the transformation demonstrated in Figure 5 generalizes the faulty Type JA transformation which contains the bug. The subtlety of this bug illustrates the difficulty of determining the conditions that are required for queries to be safely transformed. This particular transformation is ....

[Article contains additional citation context not shown here]

Won Kim. On optimizing an SQL-like nested query. ACM Transactions on Database Systems, 7(3):443--469, September 1982. 143

....algorithm. This situation becomes apparent if we consider all the di erent forms that e can take. For each such form there is a normalization rule, thus leaving the only form that cannot be reduced, namely a path. Performance: Our normalization algorithm unnests all type N and J nested queries [Kim 1982] (using Rules (N8) and (N9) respectively) The important question, though, is whether normalization always improves performance. Unfortunately not: Consider the term [f (v; v) v [f E [ w X gg, where E is an expensive query. This term is normalized into [f (E; E) w X g, which performs the ....

....set must be embedded in the result of every iteration of the outer set comprehension. Similarly, the universal quanti cation (the comprehension) and the aggregation (the max comprehension) cannot be unnested by the normalization algorithm. These cases (which are types A and JA nested queries [Kim 1982]) require the use of outer joins and grouping and they will be treated properly in Section 7. 5. MODEL EXTENSIONS 5.1 Handling Inconsistencies due to Idempotence In Section 2.2 we showed that if we allow homomorphisms from idempotent to non idempotent monoids, such as set cardinality, hom[ ....

[Article contains additional citation context not shown here]

Kim, W. 1982. On Optimizing an SQL-like Nested Query. ACM Transactions on Database Systems 7, 3 (Sept.), 443-469.

....algorithm. This becomes apparent if we consider all the di erent forms that e can take. For each such form there is a normalization rule, thus leaving the only form that cannot be reduced, namely a path. Performance: Our normalization algorithm unnests all type N and J nested queries [Kim82] using Rules (N8) and (N9) respectively) The important question, though, is whether normalization always improves performance. Unfortunately this may not be the case for the term [f (v; v) v [f E [ w X gg, where E is an expensive query. This term is normalized into [f (E; E) w X g, ....

....must be embedded in the result of every iteration of the outer set comprehension. Similarly, the universal quanti cation (the comprehension) 18 and the aggregation (the max comprehension) cannot be unnested by the normalization algorithm. These cases (which are types A and JA nested queries [Kim82] require the use of outer joins and grouping and they will be treated properly in Section 7. 5 Model Extensions 5.1 Handling Inconsistencies due to Idempotence In Section 2.2 we showed that if we allow homomorphisms from idempotent to non idempotent monoids, such as set cardinality, hom[ ....

[Article contains additional citation context not shown here]

W. Kim. On Optimizing an SQL-like Nested Query. ACM Transactions on Database Systems, 7(3):443{ 469, September 1982.

....semantics. Their work (once modified to take grouping constraints into account) can be used as a preprocessing step that allows our transformations to be applied. The work in this thesis is also related to the work on transforming nested query blocks in SQL into equivalent queries with no nesting [KIM82]. The style of transformation is similar. KIM82] starts with a simple kind of nested query and shows how to transform it into a join query that does not have a nested query in the where clause. Other transformations take a more complicated nested query and produce two or more subqueries that ....

....constraints into account) can be used as a preprocessing step that allows our transformations to be applied. The work in this thesis is also related to the work on transforming nested query blocks in SQL into equivalent queries with no nesting [KIM82] The style of transformation is similar. [KIM82] starts with a simple kind of nested query and shows how to transform it into a join query that does not have a nested query in the where clause. Other transformations take a more complicated nested query and produce two or more subqueries that compute the same result. Some subqueries are not ....

Won Kim. On Optimizing an SQL-like Nested Query. ACM Trans. Database Syst. 7,3 (September 1982), 443-469.

.... relational optimizers focus on queries involving the Select, Project and Join operators (see [Ull89] for a discussion of the theory upon which such strategies are based) Further work in relational optimization looked at extending optimization to include other operators, for example aggregators [Kim82, Day87] Optimization results have also been extended to include more expressive models, such as nested [S 89, Kor88] and network models [RR85, R 83] Object oriented databases are extensible systems which support (among other features) abstract data types, type inheritance (subtyping) ....

Won Kim. On Optimizing an SQL-like Nested Query. ACM Transactions on Database Systems, 7(3):443--469, Sept 1982.

....Another line of work has proceeded in an orthogonal direction, introducing execution plans which correspond to alternative structures of nesting. In particular, these approaches consider the possibilities of merging query blocks, denesting queries, and commuting aggregation blocks with joins [Day87, GW87, Kim82, Mur92, PHH92, YL94, HG94]. In this paper we propose an approach which unifies and generalizes the approaches mentioned above. We apply the selection propagation idea to certain data dependencies that are implicit in aggregation blocks. Propagation of SQL predicates [MFPR90a, MFPR90b, MPR90, LMS94] is a special case of ....

....dependencies that are implicit in aggregation blocks. Propagation of SQL predicates [MFPR90a, MFPR90b, MPR90, LMS94] is a special case of propagation of these dependencies. At the same time, propagating these 1 dependencies can produce execution plans with alternative nesting structure, as in [Day87, GW87, Kim82, Mur92, PHH92, YL94, HG94]. In addition to expressing in a common framework previously proposed query transformations which seemed unrelated, our approach incorporates naturally general data dependencies that may be given in the database schema. It extends transformations which commute joins with aggregation operators and ....

[Article contains additional citation context not shown here]

W. Kim. On optimizing an SQL-like nested query. ACM TODS 7(3), 1982.

....of early RDBMSs such as System R [ABC 76] and INGRES [SWK76] recognized the importance of merging views, and achieved this under limited circumstances. In spite of the acknowledged importance of such transformations, few systems have expanded upon these early transformation designs. Kim [Kim82] originally studied the question of when quantified subqueries could be replaced by joins (or anti joins) Ganski and Wong [GW87] and Dayal [Day87] did additional work on eliminating nested subqueries. These papers recognize the importance of merging of subqueries. Kim82, GW87] also deal with ....

....designs. Kim [Kim82] originally studied the question of when quantified subqueries could be replaced by joins (or anti joins) Ganski and Wong [GW87] and Dayal [Day87] did additional work on eliminating nested subqueries. These papers recognize the importance of merging of subqueries. Kim82, GW87] also deal with subqueries containing aggregation. We have reported our set of rules that deal with such subqueries in [MFPR90a, MPR90, MFPR90b] Ganski s paper illustrates the complexity of query rewrite, since it has to emend some previous transformations which were incorrect. This ....

[Article contains additional citation context not shown here]

W. Kim. On Optimizing an SQL-like Nested Query. ACM Transactions on Database Systems, 7(3), September 1982.

....Their work (once modified to take grouping constraints into account) can be used as a preprocessing step that allows our transformations to be applied. The work in this paper is also related to the work by Won Kim on transforming nested query blocks in SQL into equivalent queries with no nesting [KIM82]. The style of transformation is similar. He starts with a simple kind of nested query and shows how to transform it into a join query that does not have a nested query in the where clause. Other transformations take a more complicated nested query and produce two or more subqueries that compute ....

Won Kim. On Optimizing an SQL-like Nested Query. ACM Trans. Database Syst. 7,3 (September 1982), 443-469.

....is even more powerful and is used to more elegantly unnest queries where an outerjoin followed by a unary grouping is needed. The binary grouping operator generalizes the nest join operator of [29] The optimization of relational nested queries has been studied thoroughly in the last decade [20, 19, 13, 10, 14, 24, 26, 25]. Naturally, our research has been influenced by this body of work. The classification of relational nested queries introduced in [20] proved to be useful for relational unnesting. Based on this observation, we extended this classification to the oo context. This extension is necessary due to the ....

....generalizes the nest join operator of [29] The optimization of relational nested queries has been studied thoroughly in the last decade [20, 19, 13, 10, 14, 24, 26, 25] Naturally, our research has been influenced by this body of work. The classification of relational nested queries introduced in [20] proved to be useful for relational unnesting. Based on this observation, we extended this classification to the oo context. This extension is necessary due to the following observations. As opposed to SQL where the where clause is the only place for occurring nested queries, all clauses are ....

[Article contains additional citation context not shown here]

W. Kim. On optimizing an SQL-like nested query. ACM Trans. on Database Systems, 7(3):443--469, Sep 82.

....required to iterate over base tables and nesting required to iterate over set valued attributes. Ideally, nesting over base tables should be translated to some kind of join so that a choice can be made between various efficient join implementations. Of course, this problem already occurred in SQL [Kim82] In general, nested SQL queries can be translated to a join in the relational algebra to get a better execution than the nested loop execution. However, not all SQL queries can be translated to a join due to loss of dangling tuples in the join, a phenomenon known as the COUNTbug. In [StAB94] we ....

....of nested OOSQL queries with nesting in the where clause in the presence of set valued attributes. Nesting in the where clause is an important (and only) type of nesting allowed in the flat relational model; in complex object models it is considered equally important. The goal here, as in [Kim82] is to rewrite nested queries into join queries without unnesting set valued attributes, so that instead of performing a naive nestedloop execution, the optimizer may choose from a number of different join processing strategies. The general format of a two block OOSQL query with nesting in the ....

[Article contains additional citation context not shown here]

Kim, W., "On Optimizing an SQL-like Nested Query," ACM TODS, 7(3), pp. 443-469, September 1982.

....other components of Figure 2. Similarly, if we later decided to process Query Lite queries over a di erent backbone than DB2, this would require us only to replace the KOLA SQL translator and not every component illustrated in Figure 2. Correctness: Query rewriting is an error prone process [11]. COKO KOLA de nes a framework by which query rewrites can be veri ed with an automated theorem prover. In this section, we provide background on COKO KOLA and San Francisco required for this paper. 2.1 COKO KOLA COKO KOLA is a two tiered framework for the building of correct and e cient ....

Won Kim. On optimizing an SQL-like nested query. ACM Transactions on Database Systems, 7(3):443{ 469, September 1982.

....and Q 1 are logically equivalent if and only if their canonical form representations are identical. The canonical form representation is based on a strongly typed object algebra, which is presented in [Florescu96b] It is similar in spirit to the canonical form for nested SQL queries presented in [Kim82]. Specifying such a canonical form is an extremely hard problem. In order to solve all syntactical dissimilarities, one must integrate all the algebraic properties of 1 We presume that logical equivalence is undecidable, but we have not provided a proof in this paper. 2 Such problems do not ....

W. Kim, "On Optimizing an SQL-like Nested Query." ACM TODS, 7(3), pages 443-469, September 1982.

....by the normalization algorithm. This becomes apparent if we consider all the different forms that e can take. For each such form there is a normalization rule, thus leaving the only form that cannot be reduced, namely a path. Our normalization algorithm unnests all type N and J nested queries [Kim82] using Rules (N8) and (N9) respectively) The important question, though, is whether normalization always improves performance. Unfortunately not: consider the term [f (v; v) v [fE [ w X gg, where E is a very expensive query. This term is normalized into [f (E; E) w X g. That is, it ....

....set must be embedded in the result of every iteration of the outer set comprehension. Similarly, the universal quantification (the comprehension) and the aggregation (the max comprehension) cannot be unnested by the normalization algorithm. These cases (which are types A and JA nested queries [Kim82] require the use of outer joins and grouping and they will be treated properly in Section 7. 5 Model Extensions 5.1 Handling Inconsistencies due to Idempotence In Section 2.2 we showed that if we allow homomorphisms from idempotent to non idempotent monoids, such as set cardinality, hom[ ....

[Article contains additional citation context not shown here]

W. Kim. On Optimizing an SQL-like Nested Query. ACM Transactions on Database Systems, 7(3):443-- 469, September 1982.

....to the oo perspective. The optimization of nested queries in the oo context should clearly use the vast body of knowledge on optimizing nested relational queries. Departing from the evaluation of nested SQL queries through nested loops [1] Kim proposed unnesting of SQL queries at the SQL level [16]. The main motivation was a demonstrated substantial gain in efficiency due to unnesting. In order to eliminate some bugs which where subsequently detected, outer joins were used [14, 7, 9, 17] Reordering of outer joins became an important topic [7, 17, 19] Last, a unifying framework for ....

.... may appear in any clause: the result clause (typically select, or retrieve) the range clause (typically from or range) and the selection clause (typically where) This implies that we have to consider queries that do not match any of the types introduced for classifying nested relational queries [16]. Third, nested queries in the oo context do not always correspond to algebraic operations (e.g. method calls, path expressions) and we have to find an appropriate treatment for these nested expressions as well. While the above considerations seem to complicate the issues, there also exists one ....

[Article contains additional citation context not shown here]

W. Kim. On optimizing an SQL-like nested query. ACM Trans. on Database Systems, 7(3):443--469, Sep 82.

....mapping between tables and classes. We show that the translation of SQL queries benefits considerably from these extra semantics. ffl Since Meng et al. focus on the operational aspects of query translation, they do not discuss the translation of nested queries, as there exist unnesting algorithms [12,14] that transform nested queries into an equivalent collection of simple queries. We show that this approach would be inadequate for our purposes, as it would obscure the meaning of the original query. Existing work on schema translation is of course still relevant in our approach, as we assume the ....

....Ph Name : string i) collect h Name = x.name i for x in self iff not exists y in x.dependents j y.sex= F Figure 6: Two translations of the example query Translating nested queries In [13] Meng et al. do not consider the translation of nested queries explicitly. Existing unnesting algorithms [8,12,14] are relied upon to first flatten unnested queries; subsequently a general translation procedure for unnested queries is applied. In our context, such a procedure would be unsatisfactory. These algorithms in general result in collections of simple queries, with temporary relations holding ....

W. Kim, "On optimizing an SQL-like nested query," ACM Transactions on Database Systems 7 (September 1982), 443--469.

....by nested (parameterized) subexpressions. As indicated in [MZD94] it is not easy to find a general way to reduce parameterized subexpressions. So far [CM94, SABB94] are the papers we have seen to address this problem. Their idea is similar to the approach of reducing nested queries of SQL [Ki82]. That is, when a nested query matches a certain pattern, then it can be rewritten into an equivalent query without nested queries. Nested queries which do not match the known patterns remain untouched. This is the limitation of these methods. In this paper, we present a general solution to reduce ....

W. Kim, "On optimizing an SQL-like nested query," In ACM Transactions on Database system,7(3), September 1982.

....uses the underlying database system catalogs (or metadata) to enforce the correctness of data members, method invocations, or path expressions. Some query rewriting techniques should be performed to do query optimization at the MOQL level, such as renaming variables or eliminating nested queries [Kim82] Then, an MOQL query is transformed into an object query algebra and an initial query tree, called canonical query tree, is generated. Many object query optimization techniques [ OB95] can be applied to this canonical tree. Figure 2 (b) shows such a canonical query tree generated from Query 6. ....

W. Kim. On optimizing an SQL-like nested query. ACM Transaction on Database Systems, 7(3):443---469, September 1982.

.... strategies employed focus on queries involving the Select, Project and Join operators (see [149] for a discussion of the theory upon which such strategies are based) Subsequent work in relational optimization looked at extending optimization to include other operators, for example aggregators [38, 83]. Optimization results have also been extended to include more expressive models, such as nested [86, 126] and network models [118, 123] The relational optimizers make extensive use of heuristics based on logical query transformation rules, such as commutativity of join and pushing select past ....

....other hand, if the query is initially the Project expression it would be useful to generate the Join query, especially if there are efficient techniques for dealing with Join operations. Processing of nested query expressions in SQL addresses situations where queries are nested in Where predicates [51, 38, 83, 109]. Proposals for handling nested queries in object oriented SQL like languages address nesting in From and Where clauses [31, 115] The problem discussed here is equivalent to a query expression nested in an SQL Select clause. This problem is addressed by a new optimization strategy discussed in ....

Won Kim. On Optimizing an SQL-like Nested Query. ACM Transactions on Database Systems, 7(3):443--469, Sept 1982.

....of such an algorithm is in [CS96] Relationship to Correlated Nested Queries We note that the Join Aggregate class of nested queries is closely related to that of optimizing queries containing views with aggregates. This follows from the past work in flattening nested queries, pioneered by Kim [Kim82] For example, the result of Kim s transformation is a query that is a join 1 of base tables and one or more aggregate views, i.e. views containing aggregates. Therefore, the result of optimizing queries containing views with aggregates can be used for optimizing queries with correlated nested ....

W. Kim. On optimizing an SQL-Like nested query. ACM TODS, Sept 1982.

....move around improves the ability to determine the optimal join order. The magic set transformation can be applied after predicate move around in order to move join predicates in the direction of the join order. There has been a lot of work on optimizing subqueries and eliminating correlations [Kim82, GW87, Day87, Mur92]. Our technique complements well with that work by providing a new powerful means of pushing predicates after correlations are removed. A predicate is said to be expensive if the cost of applying the predicate is high. Placement of expensive predicates has been studied by [HS93, Hel94] The ....

W. Kim. On optimizing an SQL-like nested query. ACM TODS, 7(3), September 1982.

....there are still many queries which we don t want to rewrite for either semantic or implementation reasons. For example, correlated queries with nested predicate using a noninclusion operator (NOT IN) are almost impossible to rewrite unless new types of operators are introduced as specified in [Kim82] Another example is that an OUTER JOIN may be introduced in some query rewriting transformations. But this may not be desirable for systems that don t support OUTER JOIN directly. We enumerate several types of queries that have no existing ways (without introducing new operators) of being ....

....SG90] As we have seen, the rewritten queries usually involve views being shared. Techniques for multiple query optimization on an intra query (as opposed to inter query) basis are desirable to improve the performance of the rewritten queries. Other query rewriting related work has been done in [Kim82, Day87, GW87, PHH92] A comparison of the performance among these techniques can be found in [SPL96] 8 Conclusion In this paper, we first discussed various ways of evaluating a correlated query. We then presented the technique of caching and reusing invariants and showed how to incorporate the ....

Won Kim. On optimizing an sql-like nested query. ACM Transactions on Database Systems, 7(3):443--469, 1982.

....stated, without proof, that the necessary condition for such technique is that the group by columns must be a primary key of the outer table in the join. This is the only work we know of which attempts to reduce the cost of group by by utilizing information about primary keys. Several researchers ([5, 4, 3, 10, 9]) have investigated when a nested query can be transformed into a semantically equivalent query that does not contain nesting. As part of this work, techniques to handle aggregate functions in the nested query were discussed. However, none considered interchanging the order of joins and group by. ....

Won Kim. On optimizing an SQL-like nested query. ACM Transactions on Database Systems, 7(3):443--469, September 1982.

....issue is given in Chapter 8 where the support of views is discussed. Nested queries are crucial in the construction of new objects especially complex objects. It has been shown that many nested queries which appear only in the where clause (the filters) can be eliminated from SQL queries [Kim82, GW87] In an object oriented query language supporting free nesting of queries, it it not obvious how nested queries can be eliminated without other language constructs such as query functions. Query nesting can also be considered as an issue of generality. Quantifiers can simplify queries and ....

W. Kim. On Optimizing an SQL-like Nested Query. ACM Transactions on Database Systems, 7(3):443--469, 1982.

No context found.

W. Kim. On optimizing an SQL-like nested query. ACM Trans. on Database Systems, 7(3):443--469, Sep 82.

No context found.

W. Kim. On optimizing an SQL-like nested query. ACM Trans. on Database Systems, 7(3):443--469, Sep 82.

No context found.

W. Kim. On optimizing an SQL-like nested query. ACM Trans. on Database Systems, 7(3):443--469, Sep 82.

No context found.

Won Kim. On Optimizing an SQL-like Nested Query. ACM Trans. Database Syst., 7(3):443--469, 1982.

No context found.

W. Kim. On Optimizing an SQL-like Nested Query. In ACM Transactions on Database Systems, Vol 7, No.3, 1982.

No context found.

W. Kim. On optimizing an SQL-like nested query. ACM Trans. on Database Systems, 7(3):443--469, Sept. 1982.

No context found.

W. Kim. On Optimizing an SQL-like Nested Query. ACM Transactions on Database Systems, 7(3):443-- 469, September 1982.

No context found.

W. Kim. On optimizing an sql-like nested query. TODS, 7(3):443--469, 1982.

No context found.

W. Kim. On optimizing an SQL-like nested query. ACM Trans. on Database Systems, 7(3):443--469, Sep 82.

No context found.

W. Kim. On optimizing an SQL-like nested query. ACM Trans. on Database Systems, 7(3):443--469, Sep 82.

No context found.

W. Kim. On Optimizing an SQL-like Nested Query. ACM Transactions on Database Systems, 7(3):443-- 469, September 1982.

No context found.

W. Kim. On optimizing an SQL-like nested query. ACM Trans. on Database Systems, 7(3):443--469, Sep 82.

No context found.

W. Kim. On optimizing an SQL-like nested query. ACM Trans. on Database Systems, 7(3):443--469, Sep 82.

No context found.

W. Kim. On optimizing an SQL-like nested query. ACM Transactions on Database Systems, 7(3):443--434, September 1982.

No context found.

15 Won Kim. On Optimizing an SQL-like Nested Query. ACM Transactions on Database Systems, 7(3):443--469, September 1982.

No context found.

Kim, W., "On optimizing an SQL-like nested query," ACM Trans. on Database Systems 7(3), Sept., 1982, pp. 443--469.

No context found.

Won Kim. On Optimizing an SQL-like Nested Query. TODS 7(3): 443-469 (1982)

First 50 documents  Next 50

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC