77 lines
3.5 KiB
Markdown
77 lines
3.5 KiB
Markdown
# Query Optimisation Revision
|
||
|
||
1. Obtaining the desired information from a database system in a predictable and reliable fashion is Query Processing. Getting these results back in a timely manner deals with the technique of Query Optimization.
|
||
2. r(rID, rName, rDescription), 5000 tuples.
|
||
tuple header(24b)
|
||
rID(6b)
|
||
rName(10b)
|
||
rDescription(100b)
|
||
Disc Block(1024b)
|
||
Disc Block Header(24b)
|
||
Block Space 1000b
|
||
1. (24+6+10+100)=140b
|
||
We can fit 7 tuples in 1 block.
|
||
5000/7 = 715 blocks required.
|
||
2. (24+6+10) = 40b
|
||
25 tuples per block
|
||
5000/25 = 200 blocks required.
|
||
3. Since the projection uses significantly less blocks, we access the disc less in queries compared to using every attribute. 715/200 = 3.6x less disc block accesses.
|
||
3. Write relational algebra expressions for the following SQL query.
|
||
SELECT lecturers.name, students.name, courses.name
|
||
FROM lecturers, students, assessors, courses
|
||
WHERE lecturers.lid=assessors.lid
|
||
AND students.sid=assessors.sid
|
||
AND students.cid=courses.cid
|
||
AND courses.cid=“CS”;
|
||
π lecturers.name, students.name, courses.name (
|
||
σ courses.cid = "CS" (
|
||
lecturers ⨝ (
|
||
assessors ⨝ (
|
||
students ⨝ courses))))
|
||
Or,
|
||
π lecturers.name, students.name, courses.name
|
||
(σ lecturers.lid=assessors.lid
|
||
(σ students.sid=accessors.sid
|
||
(σ courses.cid=students.did
|
||
(σ courses.cid='CS'(courses\*students)
|
||
)\* assessors
|
||
)\* lecturers
|
||
)
|
||
1. Draw query tree
|
||
|
||
4. List heuristics that optimisers apply to reduce cost of optimisation.
|
||
- Begin with initial query tree for SQL
|
||
- Move SELECT operations down the tree
|
||
- Apply more restrictive SELECT operations first ( eg. equalities before range queries )
|
||
- Replace Cartesian products followed by selection with theta joins ( eg. *sigma(f) ( RxS )* -> *R theta(f) S* )
|
||
- Move PROJECT operations down the query tree ( add project operations as inputs to theta joins ).
|
||
5. Draw a near optimal query tree for the following:
|
||
SELECT hotels.name
|
||
FROM hotels, ratings
|
||
WHERE hotels.rid=ratings.rid
|
||
AND hotels.hid=10
|
||
AND ratings.rating>7;
|
||
1. Write relational algebra expressions for this tree
|
||
|
||
|
||
# Precedence Graphs Revision
|
||
|
||
1. State True / False
|
||
1. A transaction in which all steps must be completed successfully or none of them will be completed is called a durable transaction.
|
||
False, this is the definition of an atomic transaction
|
||
2. Two-phased locking can be used to ensure that transactions are serializable
|
||
True
|
||
3. Although two transactions may be correct in themselves, interleaving of operations may produce an incorrect result.
|
||
True
|
||
4. Transactions should be written to the log before they are applied to the database itself.
|
||
True
|
||
2. Consider the following precedence graph for a non-serial schedule consisting of four transactions. Is the corresponding schedule conflict serializable? Justify your answer. If it is conflict-serializable give a corresponding serial schedule.
|
||
|
||
The following is serialisable, since there are no cycles in the precedence graph. T1, T2, T3, T4.
|
||
3. For each of the schedules shown in Table 36.1, draw a precedence graph, determine whether it is conflict serializable and justify your answer.
|
||
|
||
|
||
Not serialisable, directed cycle in graph.
|
||
|
||
Not serialisable, directed cycle in graph
|
||
|