Query Design Objectives of the Lecture : To learn a strategy for designing queries. To learn how to use relational algebra concepts to implement the strategy. To learn how to translate the resulting query design into SQL.

Relational Queries A query has two parts : l derive a relation whose contents are the answer to your query; l retrieve that derived relation. In SQL : SELECT ; Retrieve Derivation of relation Trivial ! Queries so far have retrieved relations whose derivations were relatively simple. Extremely sophisticated derivations - i.e. complex queries - can be written for relational DBs.

Query Design Strategy 1. Determine which relations in the DB hold relevant data : Which relation holds the Determinant data ? Which relation holds the Dependent data ? 2. Use relational algebra concepts to conceptually derive one relation that holds just the determinant & the dependent. This relation holds the answer to the query. Each algebra operator represents a conceptually natural manipulation of relations. Simpler to use than SQL clauses & phrases. 3. Translate design into SQL. Most (not all) relational DBMSs use SQL, so translate into SQL in order to execute query.

Example Database It is not necessary to know the data values in any relation, or any integrity constraints except attribute data types. EmpNoENameSalaryM-SDeptNo Employee DeptNoDNameBudgetMgrNo Dept ProjNoStartEnd Project ProjNoEmpNo Alloc

Example 1 : Determinant & Dependent Query : Get the names & salaries of all married & widowed employees. Determinant – who/what is it we want to know about ? Married & widowed employees. Dependent – what do we want to know about the ‘determinant’ ? Names & salaries. Q. In which relation(s) are the determinant & dependent ? A. Both in relation Employee. Need to form one relation from Employee with just the determinant & dependent data in. Do this by ‘reducing’ Employee to just the relevant attributes & tuples. Get rid of the rest.

Example 1 : Derive One Relation Get rid of all tuples except those containing the determinant (& dependent). Get rid of all attributes except those containing the determinant & dependent. Employee Restrict[ M-S = ‘M’ Or M-S = ‘W’ ] Project[ M-S, EName, Salary ] Answer !

Example 1 : Convert to SQL SELECT M_S, EName, Salary FROM Employee WHERE M_S = ‘M’ OR M_S = ‘W’ ; Employee Restrict[ M-S = ‘M’ Or M-S = ‘W’ ] Project[ M-S, EName, Salary ]

Example 1 : Result EName Salary M-S Jane3000 M Ali3100 M Sid4400 W Relation contains only the determinant & dependent. Determinant Dependant

Example 2 : Determinant & Dependent Query : Get the names, salaries & project numbers of employees who work on projects. Determinant – who/what is it we want to know about ? Employees who work on projects. Dependent – what do we want to know about the ‘determinant’ ? Names, salaries and project numbers. Q. In which relation(s) are the determinant & dependent ? A. Determinant in relation Alloc. Dependent in relations Employee and Alloc. Need to form one relation from Employee and Alloc with just the determinant & dependent data in. Do this by ‘merging’ Employee and Alloc together & ‘reducing’ the result to just the required attributes & tuples.

‘Merging’ Relations 1. ‘Horizontally’ ABCD ABCDE DE ‘Vertically’ Join ==> ABC Union ABC ABC Example needs a horizonta l merge.

Example 2 : Derive One Relation Merge relations ‘horizontally’. Get rid of all attributes except those containing the determinant & dependent. Answer ! Employee Join[ EmpNo ] Project[ ProjNo, EName, Salary ] Alloc

Example 2 : Convert to SQL SELECT ProjNo, EName, Salary FROM Employee NATURAL JOIN Alloc ; Employee Project[ ProjNo, EName, Salary ] Alloc Join[ EmpNo ]

Example 2 : Result Relation contains only the determinant & dependent. Determinant Dependant EName Salary ProjNo Joan2900 P2 Uli3200 P Ryan4400 P

Example 3 : Determinant & Dependent Query : Get the total salary of all married employees. Determinant – who/what is it we want to know about ? Married employees. Dependent – what do we want to know about the ‘determinant’ ? Salaries : but a calculation is needed to get the total ! Q. In which relation(s) are the determinant & dependent ? A. Both in relation Employee. Need to form one relation from Employee with just the determinant & calculated dependent data in. Do this by ‘reducing’ Employee to just the required tuples, and calculating what is required.

Calculating Data 1. ‘Horizontally’ ABCD ABCDE ‘Vertically’ Extend ==> AC ABC GroupBy Example needs a vertical calculation.

Example 3 : Derive One Relation Get rid of all tuples except those containing the determinant (& dependent). Calculate the dependent, & get rid of all other attributes except the determinant. Employee Restrict[ M-S = ‘M’ ] GroupBy[ M-S ] With[ Total <-- Bag[Salary] Sum ] Answer !

Example 3 : Convert to SQL SELECT M_S, SUM(ALL Salary) AS Total FROM Employee WHERE M_S = ‘M’ GROUP BY M_S ; Employee Restrict[ M-S = ‘M’ ] GroupBy[ M-S ] With[ Total <-- Bag[Salary] Sum ]

Example 3 : Result TotalM-S 120,000 M Relation contains only the determinant & dependent. Determinant Dependant

Determinants Always need a determinant and a dependent to design a query. However determinant does not always need to be in the answer. Typically there are 2 cases where this arises : 1. If the determinant is a single value, then it can be left out of the answer, because the query designer knows the determinant to which the dependent data refers, and so doesn’t need it in the answer. 2. If the query designer is not interested in distinguishing between different determining values, then they can be left out, because they don’t matter.

Revised E.G. 1 : Determinant/Dependent

Revised E.G. 1 : Required Result EName Salary Jane3000 Ali Relation contains only dependent data. No determinant because the query designer knows that all the dependent values now refer to ‘married’ people. Before some were married and some were widowed. Therefore they had to be distinguished.

Revised E.G. 1 : Derive One Relation Get rid of all tuples not containing the single ‘married’ determinant value. Get rid of all attributes except the dependent ones. Employee Restrict[ M-S = ‘M’ ] Project[ EName, Salary ]

Revised E.G. 1 : Convert to SQL SELECT EName, Salary FROM Employee WHERE M_S = ‘M’; Employee Restrict[ M-S = ‘M’ ] Project[ EName, Salary ]

Revised E.G. 2 : Determinant/Dependent

Revised E.G. 2 : Required Result Relation contains only dependent data. EName Salary Joan2900 Uli Ryan No determinant because the query designer is not interested in the particular projects that employees work on. Before the individual projects were relevant. Therefore they had to be distinguished.

Revised E.G. 2 : Derive One Relation Merge relations ‘horizontally’. Get rid of all attributes except the dependents. Employee Join[ EmpNo ] Project[ EName, Salary ] Alloc

Revised E.G. 2 : Convert to SQL SELECT EName, Salary FROM Employee NATURAL JOIN Alloc ; Employee Project[ EName, Salary ] Alloc Join[ EmpNo ]

Revised E.G. 3 : Determinant/Dependent Query : Get the total salary of all married employees. Determinant Married employees Dependent Salaries, but totalled. Q. In which relation(s) are the determinant & dependent ? A. Both in relation Employee. Need to form one relation from Employee with just the calculated dependent data in. Do this by ‘reducing’ Employee to just the required tuples, and calculating what is required. Don’t actually need to include ‘married’ in the result, since we know the employees referred to.

Revised E.G. 3 : Required Result Total 120,000 Relation contains only the calculated dependent. No determinant because the query designer knows that the dependent result refers to ‘married’ people. Didn’t really need to include the ‘married’ marital- status value before.

Revised E.G. 3 : Derive One Relation Get rid of all tuples except those referring to the ‘married’ determinant. Calculate the total from the whole result of the restriction, because it only holds data about ‘married’ employees. GroupBy[ ] With[ Total <-- Bag[Salary] Sum ] Employee Restrict[ M-S = ‘M’ ]

Revised E.G. 3 : Convert to SQL SELECT SUM(ALL Salary) AS Total FROM Employee WHERE M_S = ‘M’ ; Employee Restrict[ M-S = ‘M’ ] GroupBy[ ] With[ Total <-- Bag[Salary] Sum ] Nothing !

Dependants Always need a determinant and a dependent to design a query. If there are queries where only the dependant needs to be in the result, are there queries where only the determinant needs to be in the result ? The answer is, not very often. The typical case is a query to discover if a determinant exists. Such a query typically requires an answer of yes/no or true/false.

Example with No Dependant in Answer Query : Are there any married employees ? Determinant – who/what is it we want to know about ? Married employees. Dependent – what do we want to know about the ‘determinant’ ? Nothing ! Only whether they exist. Q. In which relation(s) is the determinant? A. Relation Employee : contains data for all employees, including their marital-status. Need to form one relation from Employee with just the determinant data in. Do this by ‘reducing’ Employee to just the marital-status attribute with tuples whose marital-status = ‘married’.

Required Result : First Attempt Relation(s) contain only the determinant. Dependant is of no interest. M-S M M M M M Answer if there are ‘married’ employees. Answer if there are no ‘married’ employees. OR

Result Really Required because the previous Yes answer could be very large (!) and the previous No answer could be misleading. OR Yes No Unfortunately, SQL has no easy way to derive Yes/No answers.  design the query to deliver the previous answer(s).

Derive One Relation Employee Restrict[ M-S = ‘M’ ] Project[ M-S ] Get rid of all tuples except those containing the determinant value ‘married’. Get rid of all attributes except the determinant value ‘married’. Answer ! Do we need this step ? Only to prevent a Yes answer from being too big.

Convert to SQL Employee Restrict[ M-S = ‘M’ ] Project[ M-S ] SELECTM_S FROMEmployee WHEREM_S = ‘M’ ;

Conclusion Strategy : l Determine which relations hold the determinant & dependent data. l Use relational algebra to derive one relation that holds both. l Decide whether determinant or dependant data can be pruned out. l Convert to SQL. Further Developments l Suppose determinant and/or dependent data is itself split over 2 or more relations ? Combine them into one relation using the above approach. Then continue as before. l May need both horizontal and vertical calculations in one query. l Even more advanced queries can be built on these foundations. Design them with the same approach, applied recursively.