Pushing Predicates into Recursive SQL Common Table Expressions
|
|
- Prosper Mason
- 6 years ago
- Views:
Transcription
1 Pushing Predicates into Recursive SQL Common Table Expressions Marta Burzańska, Krzysztof Stencel, and Piotr Wiśniewski Faculty of Mathematics and Computer Science, Nicolaus Copernicus University, Toruń Poland Abstract. A recursive SQL-1999 query consists of a recursive CTE (Common Table Expression) and a query which uses it. If such a recursive query is used in a context of a selection predicate, this predicate can possibly be pushed into the CTE thus limiting the breadth and/or depth of the recursive search. This can happen e.g. after the definition of a view containing recursive query has been expanded in place. In this paper we propose a method of pushing predicates and other query operators into a CTE. This allows executing the query with smaller temporary data structures, since query operators external w.r.t. the CTE can be computed on the fly together with the CTE. Our method is inspired on the deforestation (a.k.a. program fusion) successfully applied in functional programming languages. 1 Introduction Query execution and optimisation is a well-elaborated topic. However, the optimisation of recursive queries introduced by SQL-1999 is not advanced yet. A number of techniques is known in the general setting (e.g. the magic sets [1]), but they are not applied to SQL Since, the recursive query processing is very time-consuming, new execution and optimisation methods for such queries are needed. It seems promising to push selection predicates from the context of a usage of a recursive query, into the sole query (in fact into its CTE). The method of predicate-move-around [2] is very interesting. It allows pushing and pulling predicates to places where their execution promises biggest gain in terms of the query running time. However, this method applies to non-recursive queries only. Recursive queries are much more complex, since predicates external to them must be applied to all nodes reached during the execution, but not necessarily to all visited nodes. It could be useful to push such predicates into the initial step or into the recursive step. However, we cannot do it straightforwardly, since the predicate holding for the result does not need to hold for all nodes visited on the path to the result In this paper we propose a method of pushing predicates into CTEs subtle enough not to change the semantics of the query. Together with pushing predicates our method also tries to push other operators into the recursive CTE so that as much as possible part of computing is performed J. Grundspenkis, T. Morzy, and G. Vossen (Eds.): ADBIS 2009, LNCS 5739, pp , c Springer-Verlag Berlin Heidelberg 2009
2 Pushing Predicates into Recursive SQL Common Table Expressions 195 on the fly together with the recursive processing. This reduces the space needed for temporary data structures and the time needed to store and retrieve data from them. This part of our optimisation method is inspired by the deforestation developed for functional languages [3]. This method is also known as program fusion, because the basic idea behind it is to fuse together two functions of which one consumes an intermediate structure generated by the other. This algorithm has been successfully implemented in Glasgow Haskell Compiler (GHC [4]) and proved to be very effective. But it has to be mentioned, that GHC is not equipped with the original deforestation technique. The algorithm of [3], although showing a great potential, was still too complicated and did not cover all of the possible intermediate structures. This is why many papers on deforestation s enhancements have been prepared. The most universal, and the simplest at the same time is known as the short-cut fusion, cheap deforestation or foldr-build rule [5,6]. Unfortunately it is not suitable for dealing with recursive functions. The problem of deforesting recursive function has been addressed in [7]. There has been work done on how to translate operators of an object query language into its foldr equivalent. Although most of them have dealt only with OQL operators, they are successful in showing that OQL can be efficiently optimised with short-cut deforestation ([8]). But still the issue of optimising recursive queries is open. One of the works in this field is [9].It presents three optimization techniques, i.e. deleting duplicates, early evaluation of row selection condition and defining an enhanced index. This paper is organized as follows. In Section 2 we show an example which pictures the possible gains of our method. In Section 3 we explain some small utility optimisation steps used by our method. Section 4 explains and justifies the main optimisation step of pushing selection predicates into CTE. Section 5 shows the measured gain of our optimisation method together with the original query execution plan and the plan after optimisation. We show plans and measures for IBM DB2. Section 6 concludes. 2 Motivating Example Let us consider a database table Emp that consists of the attributes: (EID Z, ENAME String, MGR Z, SALARY R). The column eid is the primary key, while mgr is a foreign key which references eid. Thecolumnmgr stores data on managers of individual employees. Top managers have NULL in this column. We define also a recursive view which shows the subordinate-manager transitive relationship, i.e. it prints pairs of eids, such that the first component of the pair is a subordinate while, the second is his/her manager. From 1999 one can formulate this query in standard SQL: CREATE VIEW subordinates (seid, meid) AS WITH subs(seid, meid) AS ( SELECT e.eid AS seid, e.eid AS meid FROM Emp e
3 196 M. Burzańska, K. Stencel, and P. Wiśniewski SELECT e3.eid AS seid, s.meid AS meid FROM Emp e3, subs s WHERE e3.mgr = s.seid ) SELECT * FROM subs; This view can then be used to find the total salary of all subordinate employees of,say,smith: SELECT SUM(e2.salary) FROM subordinates s2 JOIN Emp e2 ON (e2.eid = s2.seid) JOIN Emp e1 ON (e1.eid = s2.meid) Anaïve execution of such a query consists in materializing the whole transitive subordinate relationship. However, we need only a small fraction of this relationship which concerns Smith and her subordinates. In order to avoid materializing the whole view, we start from a standard technique of query modification. We expand the view definition in line: WITH subs(seid, meid) AS ( SELECT e.eid AS seid, e.eid AS meid FROM Emp e SELECT e3.eid AS seid, s.meid AS meid FROM Emp e3,subs s WHERE e3.mgr = s.seid ) SELECT SUM(e2.salary) FROM subs s2 JOIN Emp e2 ON (e2.eid = s2.seid) JOIN Emp e1 ON (e1.eid = s2.meid) The execution of this query can be significantly improved, if we manage to push the predicate e1.ename = Smith to the first part of the CTE. In this paper we show a general method of identifying and optimising queries which allow such a push. After this first improvement it is possible to get rid of the join with e1 and push the join with e2 as well as the retrieval of the salary into the CTE. After all this changes we get the following form of our query: WITH subs(seid, meid, salary) AS ( SELECT e.eid AS seid, e.eid AS meid, e.salary FROM Emp e WHERE e.ename = Smith SELECT e3.eid AS seid, s.meid AS meid, e3.salary FROM Emp e3, subs s WHERE e3.mgr = s.seid ) SELECT SUM(s2.salary) FROM subs s2;
4 Pushing Predicates into Recursive SQL Common Table Expressions 197 The result of the predicate push and the query fusion is satisfactory. Now we traverse only the Smith s hierarchy. Further optimisation is not possible, by rewriting SQL query to another SQL query (SQL-1999 severely limits the form of recursive CTEs). However, we do need to accumulate neither eids nor salaries. We just need to have one temporary structure, i.e. a number register to sum the salaries on the fly as we traverse the hierarchy. This is the most robust plan (traverse the hierarchy and accumulate salaries). This is a simple application of deforestation and can be done by a DBMS on the level of query execution plans even if its is not expressible in SQL Utility Optimisations The first step that should be done after expanding the view definition is purely syntactic. We add alias names for tables lacking them, and we change aliases that are assigned more than once, so that all tables have different aliases. This is done by a simple replacement of alias names (α-conversion). The second technique is the elimination of vain joins. This technique is usually applied after some other query transformation. When in one of the parts of the CTE, or in the main part of the query a table is joined by its primary key to the a foreign key of another table, but besides the joining condition it is not used it may be deleted. This is done by removing this table from the FROM clause at the same time removing the join condition in which it is used. There is one subtle issue. The foreign key used to join with the removed table cannot have the value of NULL. Such rows cannot be matched. The join with the removed table plays the role of the selection predicate IS NOT NULL. Thus, if the foreign key is not constrained to be NOT NULL, the selection predicate that foreign key IS NOT NULL must be added. If the schema determines the foreign key to be NOT NULL, this condition is useless and is not added. Another simple conversion is a self-join elimination when the join is one-toone (primary key to primary key). When encountering such a self-join we choose one of the two aliases used in this join, and then substitute every occurrence of one of them (besides its definition and joining condition) by another. When this is done we can delete the self-joining condition and the redundant occurrence of the doubled table from the FROM clause. This technique is illustrated by the following example. Starting from a query: WITH subs(seid, meid, salary) AS ( SELECT e.eid AS seid, e.eid AS meid, e2.salary as salary FROM Emp e, Emp e2 WHERE e.eid = e2.eid SELECT e3.eid AS seid, s.meid AS meid,e2.salary as salary FROM Emp e3,subs s, Emp e2 WHERE (e3.mgr = s.seid) AND e.eid = e2.eid ) SELECT SUM(e2.salary)
5 198 M. Burzańska, K. Stencel, and P. Wiśniewski FROM subs s2 JOIN Emp e1 ON (e1.eid = s2.meid) Using self-join elimination we obtain the query: WITH subs(seid, meid, salary) AS ( SELECT e.eid AS seid, e.eid AS meid, e.salary as salary FROM Emp e SELECT e3.eid AS seid, s.meid AS meid,e2.salary as salary FROM Emp e3,subs s, Emp e2 WHERE (e3.mgr = s.seid) AND e.eid = e2.eid ) SELECT SUM(e2.salary) FROM subs s2 JOIN Emp e1 ON (e1.eid = s2.meid) Self-join elimination can be applied to both parts of CTE definition and to the main part of the query. In the mentioned example it was applied to the first part of the CTE. 4 Predicate Push into CTE In this section we describe the main part of our technique, i.e. how to find predicates which can be pushed into a CTE and how to rewrite the query to push selected predicates into CTE. In subsequent steps we analyse each table used joined to the result of a CTE. Such a table may be simply used in the query surrounding the CTE or may appear to be joined with CTE after e.g. expansion of the definition of a view (as in the example from Section 2). In the following paragraphs we will call such a table marked for analysis. Let us assume that we have marked for analysis a table that does not appear in any predicate besides the join conditions. If this table is joined to the CTE using its primary key, we can mark it for pushing into CTE. This table s alias may appear in three parts of the query surrounding the CTE: in the SELECT clause pointing to specific columns, in the condition joining it with CTE or in the condition joining it with some other table. Let us analyse those cases. The first case is the simplest we just need to push the columns into both SELECT statements inside CTE. To do it, we need to follow a short procedure: after copying the table declaration into both inner FROM clauses, we copy the columns calls into both inner SELECT clauses, assigning those columns new alias names. We now have to expand CTE s header using new columns aliases. Finally in the outer SELECT clause we replace marked table alias with the outer alias of the CTE. Second case is when the marked table alias is in the condition joining the marked table with CTE. The first step is to copy the joining condition into the
6 Pushing Predicates into Recursive SQL Common Table Expressions 199 first part of the CTE. While doing this we need to translate the CTE s column used for joining into its equivalent within the first part. Let us assume that the joining column from the CTE was named cte alias.col1. In the first SELECT clause of the CTE we have: alias1.some column AS Col1. Having this information we substitute the column name cte alias.col1 with alias1.some column. We proceed analogically when copying the join condition into the recursive part of the CTE. The third case, when marked alias occurs within a join clause that does not involve CTE s alias, is very similar to the case of copying column names from the SELECT clause. Firstly we need to push columns connected with marked table into CTE (according to the procedure described above). Secondly we replace those columns names by corresponding CTE s columns. All those three cases are illustrated by the following example: Having the query: WITH subs(seid, meid) AS ( SELECT e.eid AS seid, e.eid AS meid FROM Emp e SELECT e3.eid AS seid, s.meid AS meid FROM Emp e3, subs s WHERE e3.mgr = s.seid ) SELECT e2.salary, d1.name FROM subs s2 JOIN Emp e2 ON (e2.eid = s2.seid) JOIN Emp e1 ON (e1.eid = s2.meid) JOIN Dept d1 ON (e1.dept = d1.did) The table to be analysed is Emp e2. This table is used in two join conditions (with the CTE, and with the Dept table) and once in the SELECT clause. Therefore we copy the table name into both FROM clauses existing in the CTE definition, also we copy twice the join with the CTE condition and the column call. Then we replace the aliases as described above. Finally we remove the marked table with its references from the outer selection query. The resulting query is of the form: WITH subs(seid, meid, dept, salary) AS ( SELECT e.eid AS seid, e.eid AS meid, e2.dept AS dept, e2.salary AS salary FROM Emp e, Emp e2 WHERE e2.eid = e.eid SELECT e3.eid AS seid, s.meid AS meid, e2.dept AS dept, e2.salary AS salary FROM Emp e3, subs s, Emp e2 WHERE e3.mgr = s.seid AND e2.eid = e3.eid ) SELECT s2.salary, d1.name FROM subs s2 JOIN Emp e1 ON (e1.eid = s2.meid) JOIN Dept d1 ON (s2.dept = d1.did)
7 200 M. Burzańska, K. Stencel, and P. Wiśniewski This form may undergo further optimisations like elimination of self-join. One thing has to be mentioned: if the marked table is not joined with CTE, is should be skipped and returned to later, after other modifications to CTE. Now let us analyse the situation when a table from the outer query is referenced within a predicate. It should be marked for pushing into CTE, undergo moving into CTE like described above, but without deletion from its original place. We have to check if moving the predicate into CTE is possible. There are many predicates, for which pushing them into CTE would put too big restrictions on the CTE resulting in loss of data. During the research on recursive queries we found that the predicate can be pushed into the CTE only if we can isolate a subtree of the result tree that contains only the elements fulfilling the predicate and no other node outside this subtree fulfils this predicate. This may be only verified by checking for the existence of the tree invariant. So a general method for pushing a predicate into CTE is based on checking CTE for the existence of tree invariant and if found, checking if the predicate can be attached to CTE through this invariant. To perform this check we use induction rules. We start by analysing tuple schema generated in the initial step of CTE materialisation. We need to fetch the metadata information on the tables used in FROM clauses. First we create the schema of the initial tuples, so we simply use the SELECT clause and fill the columns with the values found in this clause. Next we analyse the FROM clause and join predicates in the recursion step and from the metadata information we create a general tuple schema that would be created out of a standard tuple. Analysing SELECT clause we perform proper projection onto the newly generated tuple schema thus creating a new schema of a tuple that would be a result of the recursive step. By comparing input and output tuples we may pinpoint the tuple s element which is the loop invariant. If there is no loop invariant we cannot push the predicates. If there is an invariant, then in order to push the predicate we have to check if it is a restriction on a table joined to the invariant (one of the invariants when many). An easy observation shows that it is sufficient to push the predicate only to the initial step, because, based on the induction, it will be recursively satisfied in all of the following steps. Let us now observe how this method is performed on an example. Let us analyse a following query (with already pushed the join condition): WITH subs(seid, meid, salary) AS ( SELECT e.eid AS seid, e.eid AS meid, e.salary as salary FROM Emp e, Emp e1 WHERE e1.eid = e.eid SELECT e3.eid AS seid, s.meid AS meid,e3.salary as salary FROM Emp e3, subs s, Emp e1 WHERE e3.mgr = s.seid AND e1.eid = s.meid ) SELECT SUM(s2.salary) FROM subs s2 JOIN Emp e1 ON (e1.eid = s2.meid)
8 Pushing Predicates into Recursive SQL Common Table Expressions 201 The table Emp e1 occurs in the predicate e1.ename = Smith. In the CTE definition we reference the table Emp four times and once the CTE itself. From the metadata we know that the Emp table consists of the attributes: (EID, ENAME, MGR, SALARY) and that the EID attribute is a primary key. This means that every tuple belonging to the relation Emp has the form: (e, n e,m e,s e ). All of the tuple s elements are functionally dependent on the first element. By analysing SELECT clauses of the CTE we know that its attributes are: (SEID Z, MEID Z, SALARY R). The initial step generates tuples of the form: (e, e, s e ) Let us assume that tuple (a, b, c) CTE. During the recursion step from this tuple the following tuples are generated: ((a, b, c), (e1,f e1,l e1,a,s e1 ), (b, f b,l b,m b,s b )) Next by projection on the elements 4-th,2-nd,8-th we get a tuple: (e1,b,s e1 ) Comparing this tuple with the initial tuple template we see, that the second parameter is a tree invariant, so we may attach to this parameter table with predicate limiting the size of the result collection. Because the predicate e1.ename = Smith references a table that is joined to the element b, so it can be pushed into the initial step of CTE. Because all of the information from the outer selection query connected with Emp e1 have been included in the CTE definition, they may be removed from the outer query. Using the transformations described in 3 to simplify the recursive step, we get as a result: WITH subs(seid, meid, salary) AS ( SELECT e.eid AS seid, e.eid as meid, e.salary as salary FROM Emp e WHERE e.ename = Smith SELECT e3.eid AS seid, s.meid as meid, e3.salary as salary FROM Emp e3, subs s WHERE e3.mgr = s.seid ) SELECT SUM(s2.salary) FROM subs s2; This way we have obtained a query which traverses only a fraction of the whole hierarchy. It is the final query of our motivating example (see Section 2). The predicate e1.ename = Smith has been successfully pushed into the CTE. The general procedure of optimising recursive SQL query is to firstly push in all the predicates and columns possible and then to use simplification techniques described in 3.
9 202 M. Burzańska, K. Stencel, and P. Wiśniewski 5 Measured Improvement In this section we present the results of tests performed on the motivating example of this paper. The tests were performed on two machines: first one is equipped with Intel core 2 duo u2500 processor and 2GB RAM memory (let us call it machine A), the other one has phenom x4 9350e processor and 2GB RAM memory (let us call it machine B). Each one of them has IBM DB2 DBMS v. 9.5 installed on MS Vista operating system. The test data is stored within a table Emp(eid, ename, mgr, salary) and consists of 1000 records. This means that the size of the whole materialised hierarchy can be counted in hundreds thousands (its upper bound is half the square of the size of the Emp table). The hierarchy itself was created in such a way to eliminate cycles (which is a common company hierarchy). Tests where performed within two series. The first one tested a case when Emp table had index placed only on the primary key. In the second series indices where placed on both the primary key and the ename column. Fig. 1. Basic query s plan using index on the Emp table s primary key. Includes five full table scans, one additional index scan and 2 hash joins that also take some time to be performed Fig. 2. Optimized query s plan with index on the Emp s primary key. This plan has no need for hash joins, also one full table scan and index scan have been eliminated Let us start by analysing the case when the set of tests was performed on the Emp table that had an index placed on its primary key. The original query was estimated to be performed within timeron units and evaluated in 2.5s on machine A. The query acquired using the method described in this paper (it will be further called the optimised query) was estimated by the DBMS to be performed in timeron units. As for the evaluation plan for the original query 1 it indicates the use of many full table scans in the process of materializing the
10 Pushing Predicates into Recursive SQL Common Table Expressions 203 Fig. 3. Basic query s plan using indices on the Emp table s primary key and ename column. In comparison to Fig. 1 one of the full table scans has been replaced by less costly index scan. Still two hash joins and four other full table scans remain. Fig. 4. Optimized query s plan using indices on the Emp table s primary key and ename column. In comparison to Fig. 3 one full table scan, one index scan and two hash joins have been eliminated. Also this plan has the least amount of full table scans and join operations, therefore it is the least time consuming. hierarchy and also two full table scans in the outer select subquery. This indicates that firstly, DBMS does not possess any means to optimise the query using already implemented algorithms. Secondly, the bigger the Emp table, the runtime and resources consumption increase dramatically. The only benefit of having an index placed on the primary key was in the initial step of materializing the CTE. In the global aspect, this is a small profit, because the initial step in the original query still consists of 1000 records, and the greatest resources consumption takes place during the recursive steps. In comparison, the evaluation plan for the optimised query 2 although also having full table scans, benefited in elimination of two hash joins (HSJOIN), that needed full table scans in order to attach Emp table to the materialized CTE. On the machine A this query was evaluated under 1s. The time was so small, because the initial step of CTE was materialized not for all of the 1000 records, but for only a few. The second set of tests was performed with indices placed on both the primary key and the ename column. The original query was evaluated in 2s and the cost in timeron units was estimated at As for the optimised query the corresponding results were timeron units and evaluation time under 1s. As in previous case, the index placed on the primary key was used only in the initial step of materializing CTE. As for the index placed on the ename column it
11 204 M. Burzańska, K. Stencel, and P. Wiśniewski Table 1. Results of the described test in timeron units and real time mesurements tests original optimised opt/orig one real time 2.5 s <1 s > 40% index timeron % two real time 2s <1s > 50% indices timeron % was used to reduce the amount of records attached to the materialized hierarchy. This way hash join took less time to be evaluated. Nevertheless the evaluation plan still contains many full scans that deal with huge amount of data. As for the optimised query the index placed on the primary key is not used, but the index placed on the ename column speeded up the materialization of the initial step. The results of the test have been placed for comparison in Table 1. It is worth noting, that the timeron cost of original query, despite indexing, is greater than in case of the optimised query. Also basing on this estimation the profit of our method varies between 4 and 5 percent. It may not seem much, but when thinking of bigger initial tables, this is quite a good result. What is more, because this is a method of rewriting SQL into SQL further optimisation (like placement of indices) may be performed. 6 Conclusion In this paper we have show an optimisation method of recursive SQL queries. The method consists of selecting the predicates which can be pushed into the CTE and moving them. The condition that needs to be satisfied is the existance of tree invariant. The benefit of the usage of our method depends on the selectivity of the predicates being pushed and the recursion depth. A highly selective filter condition which may indirectly reduce the amount of recursion steps will improve the evaluation time in a significant way. Even experiments with small tables proved the high potential of the method, since for such small number of rows the reduction of the execution time is substantial. References 1. Bancilhon, F., Maier, D., Sagiv, Y., Ullman, J.D.: Magic sets and other strange ways to implement logic programs. In: PODS, pp ACM, New York (1986) 2. Levy, A.Y., Mumick, I.S., Sagiv, Y.: Query optimization by predicate move-around. In: Bocca, J.B., Jarke, M., Zaniolo, C. (eds.) VLDB, pp Morgan Kaufmann, San Francisco (1994) 3. Wadler, P.: Deforestation: Transforming programs to eliminate trees. Theor. Comput. Sci. 73(2), (1990) 4. Jones, S.P., Tolmach, A., Hoare, T.: Playing by the rules: rewriting as a practical optimisation technique in GHC. In: Haskell Workshop, ACM SIGPLAN, pp (2001)
12 Pushing Predicates into Recursive SQL Common Table Expressions Gill, A.J., Launchbury, J., Jones, S.L.P.: A short cut to deforestation. In: FPCA, pp (1993) 6. Johann, P.: Short cut fusion: Proved and improved. In: Taha, W. (ed.) SAIG LNCS, vol. 2196, pp Springer, Heidelberg (2001) 7. Ohori, A., Sasano, I.: Lightweight fusion by fixed point promotion. In: Hofmann, M., Felleisen, M. (eds.) POPL, pp ACM, New York (2007) 8. Grust, T., Grust, T., Scholl, M.H., Scholl, M.H.: Query deforestation. Technical report, Faculty of Mathematics and Computer Science, Database Research Group, University of Konstanz (1998) 9. Ordonez, C.: Optimizing recursive queries in SQL. In: SIGMOD 2005: Proceedings of the 2005 ACM SIGMOD international conference on Management of data, pp ACM, New York (2005)
Recursive query facilities in relational databases: a survey
Recursive query facilities in relational databases: a survey Aleksandra Boniewicz 1, Marta Burzanska 1, Piotr Przymus 1, and Krzysztof Stencel 1,2 1 Faculty of Mathematics and Computer Science, Nicolaus
More informationQUERY OPTIMIZATION [CH 15]
Spring 2017 QUERY OPTIMIZATION [CH 15] 4/12/17 CS 564: Database Management Systems; (c) Jignesh M. Patel, 2013 1 Example SELECT distinct ename FROM Emp E, Dept D WHERE E.did = D.did and D.dname = Toy EMP
More informationRecursive Queries Using Object Relational Mapping
Recursive Queries Using Object Relational Mapping Marta Burzańska 1, Krzysztof Stencel 1,2, Patrycja Suchomska 1, Aneta Szumowska 1,andPiotrWiśniewski 1 1 Faculty of Mathematics and Computer Science, Nicolaus
More informationCOMP7640 Assignment 2
COMP7640 Assignment 2 Due Date: 23:59, 14 November 2014 (Fri) Description Question 1 (20 marks) Consider the following relational schema. An employee can work in more than one department; the pct time
More informationUniversity of Massachusetts Amherst Department of Computer Science Prof. Yanlei Diao
University of Massachusetts Amherst Department of Computer Science Prof. Yanlei Diao CMPSCI 445 Midterm Practice Questions NAME: LOGIN: Write all of your answers directly on this paper. Be sure to clearly
More informationExtending HQL with Plain Recursive Facilities
Extending HQL with Plain Recursive Facilities Aneta Szumowska, Marta Burzańska, Piotr Wiśniewski, and Krzysztof Stencel Abstract The mismatch between relational databases and object-oriented programming
More informationCOSC 304 Introduction to Database Systems SQL. Dr. Ramon Lawrence University of British Columbia Okanagan
COSC 304 Introduction to Database Systems SQL Dr. Ramon Lawrence University of British Columbia Okanagan ramon.lawrence@ubc.ca SQL Queries Querying with SQL is performed using a SELECT statement. The general
More informationImplementing Common Table Expressions for MariaDB
Implementing Common Table Expressions for MariaDB Galina Shalygina Mathematics and Mechanics Department Saint Petersburg State University Saint-Petersburg, Russia galashalygina@gmail.com Boris Novikov*
More informationCS2 Current Technologies Note 1 CS2Bh
CS2 Current Technologies Note 1 Relational Database Systems Introduction When we wish to extract information from a database, we communicate with the Database Management System (DBMS) using a query language
More informationEncyclopedia of Database Systems, Editors-in-chief: Özsu, M. Tamer; Liu, Ling, Springer, MAINTENANCE OF RECURSIVE VIEWS. Suzanne W.
Encyclopedia of Database Systems, Editors-in-chief: Özsu, M. Tamer; Liu, Ling, Springer, 2009. MAINTENANCE OF RECURSIVE VIEWS Suzanne W. Dietrich Arizona State University http://www.public.asu.edu/~dietrich
More informationPhysical Design. Elena Baralis, Silvia Chiusano Politecnico di Torino. Phases of database design D B M G. Database Management Systems. Pag.
Physical Design D B M G 1 Phases of database design Application requirements Conceptual design Conceptual schema Logical design ER or UML Relational tables Logical schema Physical design Physical schema
More informationSQL Queries. COSC 304 Introduction to Database Systems SQL. Example Relations. SQL and Relational Algebra. Example Relation Instances
COSC 304 Introduction to Database Systems SQL Dr. Ramon Lawrence University of British Columbia Okanagan ramon.lawrence@ubc.ca SQL Queries Querying with SQL is performed using a SELECT statement. The general
More informationDatabase Management Systems (COP 5725) Homework 3
Database Management Systems (COP 5725) Homework 3 Instructor: Dr. Daisy Zhe Wang TAs: Yang Chen, Kun Li, Yang Peng yang, kli, ypeng@cise.uf l.edu November 26, 2013 Name: UFID: Email Address: Pledge(Must
More informationData Manipulation Language (DML)
In the name of Allah Islamic University of Gaza Faculty of Engineering Computer Engineering Department ECOM 4113 DataBase Lab Lab # 3 Data Manipulation Language (DML) El-masry 2013 Objective To be familiar
More informationMANAGING DATA(BASES) USING SQL (NON-PROCEDURAL SQL, X401.9)
Technology & Information Management Instructor: Michael Kremer, Ph.D. Class 6 Professional Program: Data Administration and Management MANAGING DATA(BASES) USING SQL (NON-PROCEDURAL SQL, X401.9) AGENDA
More informationQuery Optimization Overview
Query Optimization Overview parsing, syntax checking semantic checking check existence of referenced relations and attributes disambiguation of overloaded operators check user authorization query rewrites
More informationDATABASE THEORY. Lecture 12: Evaluation of Datalog (2) TU Dresden, 30 June Markus Krötzsch
DATABASE THEORY Lecture 12: Evaluation of Datalog (2) Markus Krötzsch TU Dresden, 30 June 2016 Overview 1. Introduction Relational data model 2. First-order queries 3. Complexity of query answering 4.
More informationQuery Rewriting Based on Meta-Granular Aggregation
Query Rewriting Based on Meta-Granular Aggregation Piotr Wiśniewski 1 and Krzysztof Stencel 2 1 Faculty of Mathematics and Computer Science Nicolaus Copernicus University Toruń, Poland pikonrad@mat.uni.torun.pl
More informationNew Requirements. Advanced Query Processing. Top-N/Bottom-N queries Interactive queries. Skyline queries, Fast initial response time!
Lecture 13 Advanced Query Processing CS5208 Advanced QP 1 New Requirements Top-N/Bottom-N queries Interactive queries Decision making queries Tolerant of errors approximate answers acceptable Control over
More informationInterview Questions on DBMS and SQL [Compiled by M V Kamal, Associate Professor, CSE Dept]
Interview Questions on DBMS and SQL [Compiled by M V Kamal, Associate Professor, CSE Dept] 1. What is DBMS? A Database Management System (DBMS) is a program that controls creation, maintenance and use
More informationPhysical Database Design and Tuning. Chapter 20
Physical Database Design and Tuning Chapter 20 Introduction We will be talking at length about database design Conceptual Schema: info to capture, tables, columns, views, etc. Physical Schema: indexes,
More information(Storage System) Access Methods Buffer Manager
6.830 Lecture 5 9/20/2017 Project partners due next Wednesday. Lab 1 due next Monday start now!!! Recap Anatomy of a database system Major Components: Admission Control Connection Management ---------------------------------------(Query
More information8. Secondary and Hierarchical Access Paths
8. Secondary and Access Paths Theo Härder www.haerder.de Main reference: Theo Härder, Erhard Rahm: Datenbanksysteme Konzepte und Techniken der Implementierung, Springer, 2, Chapter 8. Patrick O Neil, Elizabeth
More informationPhysical Database Design and Tuning. Review - Normal Forms. Review: Normal Forms. Introduction. Understanding the Workload. Creating an ISUD Chart
Physical Database Design and Tuning R&G - Chapter 20 Although the whole of this life were said to be nothing but a dream and the physical world nothing but a phantasm, I should call this dream or phantasm
More informationQ.1 Short Questions Marks 1. New fields can be added to the created table by using command. a) ALTER b) SELECT c) CREATE. D. UPDATE.
ID No. Knowledge Institute of Technology & Engineering - 135 BE III SEMESTER MID EXAMINATION ( SEPT-27) PAPER SOLUTION Subject Code: 2130703 Date: 14/09/27 Subject Name: Database Management Systems Branches:
More informationHorizontal Aggregations for Mining Relational Databases
Horizontal Aggregations for Mining Relational Databases Dontu.Jagannadh, T.Gayathri, M.V.S.S Nagendranadh. Department of CSE Sasi Institute of Technology And Engineering,Tadepalligudem, Andhrapradesh,
More informationPart V. Working with Information Systems. Marc H. Scholl (DBIS, Uni KN) Information Management Winter 2007/08 1
Part V Working with Information Systems Marc H. Scholl (DBIS, Uni KN) Information Management Winter 2007/08 1 Outline of this part 1 Introduction to Database Languages Declarative Languages Option 1: Graphical
More informationDatabase Design and Tuning
Database Design and Tuning Chapter 20 Comp 521 Files and Databases Spring 2010 1 Overview After ER design, schema refinement, and the definition of views, we have the conceptual and external schemas for
More information}Optimization Formalisms for recursive queries. Module 11: Optimization of Recursive Queries. Module Outline Datalog
Module 11: Optimization of Recursive Queries 11.1 Formalisms for recursive queries Examples for problems requiring recursion: Module Outline 11.1 Formalisms for recursive queries 11.2 Computing recursive
More information}Optimization. Module 11: Optimization of Recursive Queries. Module Outline
Module 11: Optimization of Recursive Queries Module Outline 11.1 Formalisms for recursive queries 11.2 Computing recursive queries 11.3 Partial transitive closures User Query Transformation & Optimization
More informationQuery Processing: an Overview. Query Processing in a Nutshell. .. CSC 468 DBMS Implementation Alexander Dekhtyar.. QUERY. Parser.
.. CSC 468 DBMS Implementation Alexander Dekhtyar.. Query Processing: an Overview Query Processing in a Nutshell QUERY Parser Preprocessor Logical Query plan generator Logical query plan Query rewriter
More informationTotalCost = 3 (1, , 000) = 6, 000
156 Chapter 12 HASH JOIN: Now both relations are the same size, so we can treat either one as the smaller relation. With 15 buffer pages the first scan of S splits it into 14 buckets, each containing about
More informationRelational Databases
Relational Databases Jan Chomicki University at Buffalo Jan Chomicki () Relational databases 1 / 49 Plan of the course 1 Relational databases 2 Relational database design 3 Conceptual database design 4
More informationRelational Model History. COSC 416 NoSQL Databases. Relational Model (Review) Relation Example. Relational Model Definitions. Relational Integrity
COSC 416 NoSQL Databases Relational Model (Review) Dr. Ramon Lawrence University of British Columbia Okanagan ramon.lawrence@ubc.ca Relational Model History The relational model was proposed by E. F. Codd
More informationDATABASE THEORY. Lecture 15: Datalog Evaluation (2) TU Dresden, 26th June Markus Krötzsch Knowledge-Based Systems
DATABASE THEORY Lecture 15: Datalog Evaluation (2) Markus Krötzsch Knowledge-Based Systems TU Dresden, 26th June 2018 Review: Datalog Evaluation A rule-based recursive query language father(alice, bob)
More informationIntroduction to Data Management. Lecture #10 (Relational Calculus, Continued)
Introduction to Data Management Lecture #10 (Relational Calculus, Continued) Instructor: Mike Carey mjcarey@ics.uci.edu Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 1 Announcements v
More informationXQuery Optimization Based on Rewriting
XQuery Optimization Based on Rewriting Maxim Grinev Moscow State University Vorob evy Gory, Moscow 119992, Russia maxim@grinev.net Abstract This paper briefly describes major results of the author s dissertation
More informationSemantic Errors in Database Queries
Semantic Errors in Database Queries 1 Semantic Errors in Database Queries Stefan Brass TU Clausthal, Germany From April: University of Halle, Germany Semantic Errors in Database Queries 2 Classification
More informationHash-Based Indexing 165
Hash-Based Indexing 165 h 1 h 0 h 1 h 0 Next = 0 000 00 64 32 8 16 000 00 64 32 8 16 A 001 01 9 25 41 73 001 01 9 25 41 73 B 010 10 10 18 34 66 010 10 10 18 34 66 C Next = 3 011 11 11 19 D 011 11 11 19
More informationEndterm Exam (Version B) CS 122A Spring 2017
NAME: SOLUTION SEAT NO.: STUDENT ID: Endterm Exam (Version B) CS 122A Spring 2017 Max. Points: 100 (Please read the instructions carefully) Instructions: - The total time for the exam is 120 minutes; be
More informationChapter 19 Query Optimization
Chapter 19 Query Optimization It is an activity conducted by the query optimizer to select the best available strategy for executing the query. 1. Query Trees and Heuristics for Query Optimization - Apply
More informationCopyright 2016 Ramez Elmasri and Shamkant B. Navathe
CHAPTER 19 Query Optimization Introduction Query optimization Conducted by a query optimizer in a DBMS Goal: select best available strategy for executing query Based on information available Most RDBMSs
More informationIntroduction. 1. Introduction. Overview Query Processing Overview Query Optimization Overview Query Execution 3 / 591
1. Introduction Overview Query Processing Overview Query Optimization Overview Query Execution 3 / 591 Query Processing Reason for Query Optimization query languages like SQL are declarative query specifies
More informationI. Khalil Ibrahim, V. Dignum, W. Winiwarter, E. Weippl, Logic Based Approach to Semantic Query Transformation for Knowledge Management Applications,
I. Khalil Ibrahim, V. Dignum, W. Winiwarter, E. Weippl, Logic Based Approach to Semantic Query Transformation for Knowledge Management Applications, Proc. of the International Conference on Knowledge Management
More informationJoin (SQL) - Wikipedia, the free encyclopedia
페이지 1 / 7 Sample tables All subsequent explanations on join types in this article make use of the following two tables. The rows in these tables serve to illustrate the effect of different types of joins
More informationDiscuss physical db design and workload What choises we have for tuning a database How to tune queries and views
TUNING AND DB DESIGN 1 GOALS Discuss physical db design and workload What choises we have for tuning a database How to tune queries and views 2 STEPS IN DATABASE DESIGN Requirements Analysis user needs;
More informationQuerying Data with Transact SQL
Course 20761A: Querying Data with Transact SQL Course details Course Outline Module 1: Introduction to Microsoft SQL Server 2016 This module introduces SQL Server, the versions of SQL Server, including
More informationReal-World Performance Training SQL Introduction
Real-World Performance Training SQL Introduction Real-World Performance Team Basics SQL Structured Query Language Declarative You express what you want to do, not how to do it Despite the name, provides
More informationQUERY OPTIMIZATION FOR DATABASE MANAGEMENT SYSTEM BY APPLYING DYNAMIC PROGRAMMING ALGORITHM
QUERY OPTIMIZATION FOR DATABASE MANAGEMENT SYSTEM BY APPLYING DYNAMIC PROGRAMMING ALGORITHM Wisnu Adityo NIM 13506029 Information Technology Department Institut Teknologi Bandung Jalan Ganesha 10 e-mail:
More informationQuery Optimization Overview
Query Optimization Overview parsing, syntax checking semantic checking check existence of referenced relations and attributes disambiguation of overloaded operators check user authorization query rewrites
More informationIntroduction to Query Processing and Query Optimization Techniques. Copyright 2011 Ramez Elmasri and Shamkant Navathe
Introduction to Query Processing and Query Optimization Techniques Outline Translating SQL Queries into Relational Algebra Algorithms for External Sorting Algorithms for SELECT and JOIN Operations Algorithms
More information192 Chapter 14. TotalCost=3 (1, , 000) = 6, 000
192 Chapter 14 5. SORT-MERGE: With 52 buffer pages we have B> M so we can use the mergeon-the-fly refinement which costs 3 (M + N). TotalCost=3 (1, 000 + 1, 000) = 6, 000 HASH JOIN: Now both relations
More informationEstimating Result Size and Execution Times for Graph Queries
Estimating Result Size and Execution Times for Graph Queries Silke Trißl 1 and Ulf Leser 1 Humboldt-Universität zu Berlin, Institut für Informatik, Unter den Linden 6, 10099 Berlin, Germany {trissl,leser}@informatik.hu-berlin.de
More informationDOWNLOAD PDF INSIDE RELATIONAL DATABASES
Chapter 1 : Inside Microsoft's Cosmos DB ZDNet Inside Relational Databases is an excellent introduction to the topic and a very good resource. I read the book cover to cover and found the authors' insights
More informationStatic checking of domain constraints in applications interacting with relational database by means of dependently-typed lambda calculus
Static checking of domain constraints in applications interacting with relational database by means of dependently-typed lambda calculus Maxim Aleksandrovich Krivchikov Ph.D., senior researcher, Lomonosov
More informationFollow these steps to get started: o Launch MS Access from your start menu. The MS Access startup panel is displayed:
Forms-based Database Queries The topic presents a summary of Chapter 3 in the textbook, which covers using Microsoft Access to manage and query an Access database. The screenshots in this topic are from
More informationSQL STRUCTURED QUERY LANGUAGE
STRUCTURED QUERY LANGUAGE SQL Structured Query Language 4.1 Introduction Originally, SQL was called SEQUEL (for Structured English QUery Language) and implemented at IBM Research as the interface for an
More informationCSE 344 Final Review. August 16 th
CSE 344 Final Review August 16 th Final In class on Friday One sheet of notes, front and back cost formulas also provided Practice exam on web site Good luck! Primary Topics Parallel DBs parallel join
More informationTechno India Batanagar Computer Science and Engineering. Model Questions. Subject Name: Database Management System Subject Code: CS 601
Techno India Batanagar Computer Science and Engineering Model Questions Subject Name: Database Management System Subject Code: CS 601 Multiple Choice Type Questions 1. Data structure or the data stored
More informationDatabase Technology Introduction. Heiko Paulheim
Database Technology Introduction Outline The Need for Databases Data Models Relational Databases Database Design Storage Manager Query Processing Transaction Manager Introduction to the Relational Model
More informationCS698F Advanced Data Management. Instructor: Medha Atre. Aug 04, 2017 CS698F Adv Data Mgmt 1
CS698F Advanced Data Management Instructor: Medha Atre Aug 04, 2017 CS698F Adv Data Mgmt 1 Recap Database Mgmt Sys Schema generation & normalization SQL query parsing, relational algebra File Sys, Indexes,
More informationAssignment #2. CS Spring 2015 Due on Friday, June 19, 2015, 9 AM For instructions on how to submit your assignment check the course website.
Assignment #2 CS 348 - Spring 2015 Due on Friday, June 19, 2015, 9 AM For instructions on how to submit your assignment check the course website. 1 CS 348 - Spring 2015 : Assignment #2 QUESTION 1. Question
More information1 SQL Structured Query Language
1 SQL Structured Query Language 1.1 Tables In relational database systems (DBS) data are represented using tables (relations). A query issued against the DBS also results in a table. A table has the following
More informationINDEX. 1 Basic SQL Statements. 2 Restricting and Sorting Data. 3 Single Row Functions. 4 Displaying data from multiple tables
INDEX Exercise No Title 1 Basic SQL Statements 2 Restricting and Sorting Data 3 Single Row Functions 4 Displaying data from multiple tables 5 Creating and Managing Tables 6 Including Constraints 7 Manipulating
More informationQuery optimization. Elena Baralis, Silvia Chiusano Politecnico di Torino. DBMS Architecture D B M G. Database Management Systems. Pag.
Database Management Systems DBMS Architecture SQL INSTRUCTION OPTIMIZER MANAGEMENT OF ACCESS METHODS CONCURRENCY CONTROL BUFFER MANAGER RELIABILITY MANAGEMENT Index Files Data Files System Catalog DATABASE
More informationSlicing and Dicing Data in CF and SQL: Part 2
Slicing and Dicing Data in CF and SQL: Part 2 Charlie Arehart Founder/CTO Systemanage carehart@systemanage.com SysteManage: Agenda Slicing and Dicing Data in Many Ways Cross-Referencing Tables (Joins)
More informationCPSC 421 Database Management Systems. Lecture 19: Physical Database Design Concurrency Control and Recovery
CPSC 421 Database Management Systems Lecture 19: Physical Database Design Concurrency Control and Recovery * Some material adapted from R. Ramakrishnan, L. Delcambre, and B. Ludaescher Agenda Physical
More informationChapter 11: Indexing and Hashing
Chapter 11: Indexing and Hashing Database System Concepts, 6 th Ed. See www.db-book.com for conditions on re-use Chapter 11: Indexing and Hashing Basic Concepts Ordered Indices B + -Tree Index Files B-Tree
More informationChapter 11: Indexing and Hashing
Chapter 11: Indexing and Hashing Database System Concepts, 6 th Ed. See www.db-book.com for conditions on re-use Chapter 11: Indexing and Hashing Basic Concepts Ordered Indices B + -Tree Index Files B-Tree
More informationµz An Efficient Engine for Fixed Points with Constraints
µz An Efficient Engine for Fixed Points with Constraints Kryštof Hoder, Nikolaj Bjørner, and Leonardo de Moura Manchester University and Microsoft Research Abstract. The µz tool is a scalable, efficient
More information1 SQL Structured Query Language
1 SQL Structured Query Language 1.1 Tables In relational database systems (DBS) data are represented using tables (relations). A query issued against the DBS also results in a table. A table has the following
More informationObjectives. After completing this lesson, you should be able to do the following:
Objectives After completing this lesson, you should be able to do the following: Write SELECT statements to access data from more than one table using equality and nonequality joins View data that generally
More informationSql Server Syllabus. Overview
Sql Server Syllabus Overview This SQL Server training teaches developers all the Transact-SQL skills they need to create database objects like Tables, Views, Stored procedures & Functions and triggers
More informationSubquery: There are basically three types of subqueries are:
Subquery: It is also known as Nested query. Sub queries are queries nested inside other queries, marked off with parentheses, and sometimes referred to as "inner" queries within "outer" queries. Subquery
More informationCSIT5300: Advanced Database Systems
CSIT5300: Advanced Database Systems L11: Physical Database Design Dr. Kenneth LEUNG Department of Computer Science and Engineering The Hong Kong University of Science and Technology Hong Kong SAR, China
More informationDetecting Logical Errors in SQL Queries
Detecting Logical Errors in SQL Queries Stefan Brass Christian Goldberg Martin-Luther-Universität Halle-Wittenberg, Institut für Informatik, Von-Seckendorff-Platz 1, D-06099 Halle (Saale), Germany (brass
More informationPhysical Database Design and Tuning
Physical Database Design and Tuning CS 186, Fall 2001, Lecture 22 R&G - Chapter 16 Although the whole of this life were said to be nothing but a dream and the physical world nothing but a phantasm, I should
More informationData Manipulation (DML) and Data Definition (DDL)
Data Manipulation (DML) and Data Definition (DDL) 114 SQL-DML Inserting Tuples INSERT INTO REGION VALUES (6,'Antarctica','') INSERT INTO NATION (N_NATIONKEY, N_NAME, N_REGIONKEY) SELECT NATIONKEY, NAME,
More informationPASSWORDS TREES AND HIERARCHIES. CS121: Relational Databases Fall 2017 Lecture 24
PASSWORDS TREES AND HIERARCHIES CS121: Relational Databases Fall 2017 Lecture 24 Account Password Management 2 Mentioned a retailer with an online website Need a database to store user account details
More informationKing Fahd University of Petroleum and Minerals
1 King Fahd University of Petroleum and Minerals Information and Computer Science Department ICS 334: Database Systems Semester 041 Major Exam 1 18% ID: Name: Section: Grades Section Max Scored A 5 B 25
More informationIntegrity constraints, relationships. CS634 Lecture 2
Integrity constraints, relationships CS634 Lecture 2 Foreign Keys Defined in Sec. 3.2.2 without mentioning nulls. Nulls covered in Sec. 5.6 First example: nice not-null foreign key column: create table
More informationDatabase Languages and their Compilers
Database Languages and their Compilers Prof. Dr. Torsten Grust Database Systems Research Group U Tübingen Winter 2010 2010 T. Grust Database Languages and their Compilers 4 Query Normalization Finally,
More informationGIFT Department of Computing Science. CS-217/224: Database Systems. Lab-5 Manual. Displaying Data from Multiple Tables - SQL Joins
GIFT Department of Computing Science CS-217/224: Database Systems Lab-5 Manual Displaying Data from Multiple Tables - SQL Joins V3.0 5/5/2016 Introduction to Lab-5 This lab introduces students to selecting
More informationTechnical aspects of VTL to SQL translation Prepared by Regional Statistical Office in Olsztyn, Poland
Working Paper. UNITED NATIONS ECONOMIC COMMISSION FOR EUROPE CONFERENCE OF EUROPEAN STATISTICIANS Work Session on Statistical Data Editing (The Hague, Netherlands, 24-26 April 2017) I. Introduction A.
More informationCSE 544 Principles of Database Management Systems. Magdalena Balazinska Fall 2007 Lecture 7 - Query execution
CSE 544 Principles of Database Management Systems Magdalena Balazinska Fall 2007 Lecture 7 - Query execution References Generalized Search Trees for Database Systems. J. M. Hellerstein, J. F. Naughton
More informationCS122 Lecture 4 Winter Term,
CS122 Lecture 4 Winter Term, 2014-2015 2 SQL Query Transla.on Last time, introduced query evaluation pipeline SQL query SQL parser abstract syntax tree SQL translator relational algebra plan query plan
More informationDATABASE MANAGEMENT SYSTEMS
www..com Code No: N0321/R07 Set No. 1 1. a) What is a Superkey? With an example, describe the difference between a candidate key and the primary key for a given relation? b) With an example, briefly describe
More informationKey Points. COSC 122 Computer Fluency. Databases. What is a database? Databases in the Real-World DBMS. Database System Approach
COSC 122 Computer Fluency Dr. Ramon Lawrence University of British Columbia Okanagan ramon.lawrence@ubc.ca Key Points 1) allow for easy storage and retrieval of large amounts of information. 2) Relational
More informationQuery Optimization in OODBMS using Query Decomposition & Query Caching
Query Optimization in OODBMS using Query Decomposition & Query Caching Atul Thakare M.E (C.S.E) persuing Sipna s COET, Amravati (M.H) India aothakare@rediff.com Prof. Ms. S.S. Dhande Asso. Professor CSE
More informationCOSC 304 Introduction to Database Systems SQL DDL. Dr. Ramon Lawrence University of British Columbia Okanagan
COSC 304 Introduction to Database Systems SQL DDL Dr. Ramon Lawrence University of British Columbia Okanagan ramon.lawrence@ubc.ca SQL Overview Structured Query Language or SQL is the standard query language
More information2 Forms of Wasted Work In this section, we discuss ve example queries that illustrate ways in which a traditional DBMS, which does not have built-in s
Processing Top N and Bottom N Queries Michael J. Carey IBM Almaden Research Center San Jose, CA 95120 Donald Kossmann University of Passau 94030 Passau, Germany 1 Introduction In certain application areas,
More informationVisual Explain Tutorial
IBM DB2 Universal Database Visual Explain Tutorial Version 8 IBM DB2 Universal Database Visual Explain Tutorial Version 8 Before using this information and the product it supports, be sure to read the
More informationOptimising Functional Programming Languages. Max Bolingbroke, Cambridge University CPRG Lectures 2010
Optimising Functional Programming Languages Max Bolingbroke, Cambridge University CPRG Lectures 2010 Objectives Explore optimisation of functional programming languages using the framework of equational
More informationCS2 Current Technologies Lecture 3: SQL - Joins and Subqueries
T E H U N I V E R S I T Y O H F R G E D I N B U CS2 Current Technologies Lecture 3: SQL - Joins and Subqueries Chris Walton (cdw@dcs.ed.ac.uk) 11 February 2002 Multiple Tables 1 Redundancy requires excess
More informationMTA Database Administrator Fundamentals Course
MTA Database Administrator Fundamentals Course Session 1 Section A: Database Tables Tables Representing Data with Tables SQL Server Management Studio Section B: Database Relationships Flat File Databases
More informationAdministrivia. Physical Database Design. Review: Optimization Strategies. Review: Query Optimization. Review: Database Design
Administrivia Physical Database Design R&G Chapter 16 Lecture 26 Homework 5 available Due Monday, December 8 Assignment has more details since first release Large data files now available No class Thursday,
More informationChapter 1: Introduction
Chapter 1: Introduction Database System Concepts, 6 th Ed. See www.db-book.com for conditions on re-use Outline The Need for Databases Data Models Relational Databases Database Design Storage Manager Query
More informationPart XII. Mapping XML to Databases. Torsten Grust (WSI) Database-Supported XML Processors Winter 2008/09 321
Part XII Mapping XML to Databases Torsten Grust (WSI) Database-Supported XML Processors Winter 2008/09 321 Outline of this part 1 Mapping XML to Databases Introduction 2 Relational Tree Encoding Dead Ends
More informationA. It executes successfully and displays rows in the descending order of PROMO_CATEGORY.
Volume: 75 Questions Question No: 1 Evaluate the following SQL statement: Which statement is true regarding the outcome of the above query? A. It executes successfully and displays rows in the descending
More informationTemporal Aggregation and Join
TSDB15, SL05 1/49 A. Dignös Temporal and Spatial Database 2014/2015 2nd semester Temporal Aggregation and Join SL05 Temporal aggregation Span, instant, moving window aggregation Aggregation tree, balanced
More information