• DBMSs
• Query Evaluation
• Mapping SQL to RA
• Mapping Example
• Query Cost Estimation
• Implementations of RA Ops
• DBMS Architecture

❖ DBMSs

DBMS = DataBase Management System

Our view of the DBMS so far ...

A machine to process SQL queries.

❖ DBMSs (cont)

One view of DB engine: "relational algebra virtual machine"

Machine code for such a machine:

For each of these operations:

• various data structures and algorithms are available
• DBMSs may provide only one, or may provide a choice

❖ Query Evaluation

The path of a query through its evaluation:

❖ Mapping SQL to RA

Mapping SQL to relational algebra, e.g.

-- schema: R(a,b) S(c,d)
select a as x
from   R join S on (b=c)
where  d = 100
-- could be mapped to
Tmp1(a,b,c,d) = R Join[b=c] S
Tmp2(a,b,c,d) = Sel[d=100](Tmp1)
Tmp3(a)       = Proj[a](Tmp2)
Res(x)        = Rename[Res(x)](Tmp3)

In general:

• SELECT clause becomes projection
• WHERE condition becomes selection or join
• FROM clause becomes join

❖ Mapping Example

Consider the database schema:

Person(pid, name, address, ...)
Subject(sid, code, title, uoc, ...)
Terms(tid, code, start, end, ...)
Courses(cid, sid, tid, ...)
Enrolments(cid, pid, mark, ..)

and the query: Courses with more than 100 students in them?

which can be expressed in SQL as

select s.sid, s.code
from   Course c join Subject s on (c.sid=s.sid)
       join Enrolment e on (c.cid=e.cid)
group  by s.sid, s.code
having count(*) > 100;

❖ Mapping Example (cont)

The SQL might be compiled to

Tmp1(cid,sid,pid)   = Course Join[c.cid = e.cid] Enrolment
Tmp2(cid,code,pid)  = Tmp1 Join[t1.sid = s.sid] Subject
Tmp3(cid,code,nstu) = GroupCount[cid,code](Tmp2)
Res(cid,code)       = Sel[nstu > 100](Tmp3)

or, equivalently

Tmp1(cid,code)      = Course Join[c.sid = s.sid] Subject
Tmp2(cid,code,pid)  = Tmp1 Join[t1.cid = e.cid] Enrolment
Tmp3(cid,code,nstu) = GroupCount[cid,code](Tmp2)
Res(cid,code)       = Sel[nstu > 100](Tmp3)

Which is better?

❖ Query Cost Estimation

The cost of evaluating a query is determined by

• the operations specified in the query execution plan
• size of relations   (database relations and temporary relations)
• access mechanisms   (indexing, hashing, sorting, join algorithms)
• size/number of main memory buffers   (and replacement strategy)

Analysis of costs involves estimating:

• the size of intermediate results
• then, based on this, cost of secondary storage accesses

Accessing data from disk is the dominant cost in query evaluation

❖ Query Cost Estimation (cont)

Consider execution plans for:    σ_c (R  ⋈_d  S  ⋈_e  T)     where R(c,d), S(d,e), T(e)

Tmp1(c,d,e)  :=  hash_join[d](R,S)
Tmp2(c,d,e)  :=  sort_merge_join[e](tmp1,T)
Res(c,d,e)   :=  binary_search[c](Tmp2)

or

Tmp1(d,e)    :=  sort_merge_join[e](S,T)
Tmp2(c,d,e)  :=  hash_join[d](R,Tmp1)
Res(c,d,e)   :=  linear_search[c](Tmp2)

or

Tmp1(c,d)    :=  btree_search[c](R)
Tmp2(c,d,e)  :=  hash_join[d](Tmp1,S)
Res(c,d,e)   :=  sort_merge_join[e](Tmp2,T)

All produce same result, but have different costs.

❖ Implementations of RA Ops

Sorting   (quicksort, etc. are not applicable)

• external merge sort   (cost O(Nlog_BN) with B memory buffers)

Selection   (different techniques developed for different query types)

• sequential scan   (worst case, cost O(N))
• index-based   (e.g. B-trees, cost O(logN), tree nodes are pages)
• hash-based   (O(1) best case, only works for equality tests)

Join   (fast joins are critical to success of relational DBMSs)

• nested-loop join   (cost O(N.M), buffering can reduce to O(N+M))
• sort-merge join   (cost O(NlogN+MlogM))
• hash-join   (best case cost O(N+M.N/B), with B memory buffers)

❖ DBMS Architecture

Most RDBMSs are client-server systems:

❖ DBMS Architecture (cont)

Layers within the DBMS server: