Recap of Feb 11: SQL “*” is an abbreviation for all attributes in the from list implicit tuple variables; table names as tuple variables Set operators:

Slides:



Advertisements
Similar presentations
COP4540 Database Management System Midterm Review
Advertisements

Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke1 Relational Calculus Chapter 4, Part B.
The Relational Calculus
Chapter 3 Tuple and Domain Relational Calculus. Tuple Relational Calculus.
Manipulating Functional Dependencies Zaki Malik September 30, 2008.
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke1 SQL: Queries, Programming, Triggers Chapter 5 Modified by Donghui Zhang.
Chapter 11 Functional Dependencies. Copyright © 2004 Pearson Addison-Wesley. All rights reserved.11-2 Topics in this Chapter Basic Definitions Trivial.
1 541: Relational Calculus. 2 Relational Calculus  Comes in two flavours: Tuple relational calculus (TRC) and Domain relational calculus (DRC).  Calculus.
Temple University – CIS Dept. CIS616– Principles of Data Management V. Megalooikonomou Functional Dependencies (based on notes by Silberchatz,Korth, and.
Carnegie Mellon Carnegie Mellon Univ. Dept. of Computer Science Database Applications C. Faloutsos Integrity Constraints.
Database Management COP4540, SCS, FIU Functional Dependencies (Chapter 14)
1 Lecture 11: Basic SQL, Integrity constraints
1 Relational Algebra & Calculus. 2 Relational Query Languages  Query languages: Allow manipulation and retrieval of data from a database.  Relational.
1 Theory, Practice & Methodology of Relational Database Design and Programming Copyright © Ellis Cohen Extended SQL & The Relational Calculus.
Recap of Feb 13: SQL, Relational Calculi, Functional Dependencies SQL: multiple group bys, having, lots of examples Tuple Calculus Domain Calculus Functional.
Chapter 7: Relational Database Design. ©Silberschatz, Korth and Sudarshan7.2Database System Concepts Chapter 7: Relational Database Design First Normal.
Chapter 7: Relational Database Design. ©Silberschatz, Korth and Sudarshan7.2Database System Concepts Chapter 7: Relational Database Design First Normal.
Relational Calculus. Another Theoretical QL-Relational Calculus n Comes in two flavors: Tuple relational calculus (TRC) and Domain relational calculus.
Relational Calculus CS 186, Spring 2007, Lecture 6 R&G, Chapter 4 Mary Roth   We will occasionally use this arrow notation unless there is danger of.
1 CMSC424, Spring 2005 CMSC424: Database Design Lecture 9.
SQL Basic format of the select command select[distinct] target_list fromtuple_variable_list wherequalification [order by target_list_subset]; Simple query.
1 Functional Dependency and Normalization Informal design guidelines for relation schemas. Functional dependencies. Normal forms. Normalization.
Chapter 5 Other Relational Languages By Cui, Can B.
1 SQL: Structured Query Language Chapter 5. 2 SQL and Relational Calculus relationalcalculusAlthough relational algebra is useful in the analysis of query.
Cs3431 Relational Algebra : #I Based on Chapter 2.4 & 5.1.
1 Relational Algebra and Calculus Yanlei Diao UMass Amherst Feb 1, 2007 Slides Courtesy of R. Ramakrishnan and J. Gehrke.
Still More Operators: Outer Join outer join is an extension of the join operation to deal with missing information –three types: left outer join, right.
Rutgers University Relational Calculus 198:541 Rutgers University.
Chapter 8: Relational Database Design First Normal Form First Normal Form Functional Dependencies Functional Dependencies Decomposition Decomposition Boyce-Codd.
©Silberschatz, Korth and Sudarshan7.1Database System Concepts Chapter 7: Relational Database Design First Normal Form Pitfalls in Relational Database Design.
Functional Dependencies Prof. Yin-Fu Huang CSIE, NYUST Chapter 11.
1 Relational Algebra and Calculus Chapter 4. 2 Relational Query Languages  Query languages: Allow manipulation and retrieval of data from a database.
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke1 Relational Calculus Chapter 4, Section 4.3.
Relational Model Concepts. The relational model represents the database as a collection of relations. Each relation resembles a table of values. A table.
1 ICS 184: Introduction to Data Management Lecture Note 10 SQL as a Query Language (Cont.)
Database System Concepts, 5th Ed. ©Silberschatz, Korth and Sudarshan See for conditions on re-usewww.db-book.com Chapter 7: Relational.
CSE314 Database Systems The Relational Algebra and Relational Calculus Doç. Dr. Mehmet Göktürk src: Elmasri & Navanthe 6E Pearson Ed Slide Set.
Database Management Systems, R. Ramakrishnan1 Relational Calculus Chapter 4.
Normalization Ioan Despi 2 The basic objective of logical modeling: to develop a “good” description of the data, its relationships and its constraints.
Computing & Information Sciences Kansas State University Tuesday, 27 Feb 2007CIS 560: Database System Concepts Lecture 18 of 42 Tuesday, 27 February 2007.
Relational Calculus R&G, Chapter 4. Relational Calculus Comes in two flavors: Tuple relational calculus (TRC) and Domain relational calculus (DRC). Calculus.
1 Relational Algebra & Calculus Chapter 4, Part A (Relational Algebra)
1 Relational Algebra and Calculas Chapter 4, Part A.
Functional Dependencies. FarkasCSCE 5202 Reading and Exercises Database Systems- The Complete Book: Chapter 3.1, 3.2, 3.3., 3.4 Following lecture slides.
1 Dept. of CIS, Temple Univ. CIS616/661 – Principles of Data Management V. Megalooikonomou Integrity Constraints (based on slides by C. Faloutsos at CMU)
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide
COMP3030 Database Management System Final Review
1 Copyright © Kyu-Young Whang Relational Calculus Chapter 4, Part B.
CSC 411/511: DBMS Design Dr. Nan WangCSC411_L5_Relational Calculus 1 Relational Calculus Chapter 4 – Part B.
MIS 3053 Database Design And Applications The University Of Tulsa Professor: Akhilesh Bajaj Normal Forms Lecture 1 © Akhilesh Bajaj, 2000, 2002, 2003.
Relational Calculus Jianlin Feng School of Software SUN YAT-SEN UNIVERSITY courtesy of Joe Hellerstein for some slides.
Database Management Systems, R. Ramakrishnan1 Relational Calculus Chapter 4, Part B.
Database System Concepts, 6 th Ed. Chapter 6: Formal Relational Query Languages.
Chapter 8 Relational Database Design. 2 Relational Database Design: Goals n Reduce data redundancy (undesirable replication of data values) n Minimize.
©Silberschatz, Korth and Sudarshan6.1Database System Concepts Chapter 6: Integrity Constraints Domain Constraints Referential Integrity Assertions Triggers.
Database System Concepts, 6 th Ed. ©Silberschatz, Korth and Sudarshan See for conditions on re-usewww.db-book.com Chapter 6: Formal Relational.
Relational Calculus Database Management Systems, 3rd ed., Ramakrishnan and Gehrke, Chapter 4.
Relational Calculus Chapter 4, Section 4.3.
Relational Algebra & Calculus
Relational Normalization Theory
Relational Algebra - Part 1
Relational Calculus Chapter 4, Part B
RELATIONAL ALGEBRA (Chapter 2)
Temple University – CIS Dept. CIS331– Principles of Database Systems
Instructor: Mohamed Eltabakh
Chapter 2: Intro to Relational Model
Relational Algebra & Calculus
Relational Calculus Chapter 4, Part B 7/1/2019.
Relational Calculus Chapter 4, Part B
Presentation transcript:

Recap of Feb 11: SQL “*” is an abbreviation for all attributes in the from list implicit tuple variables; table names as tuple variables Set operators: union, intersect, minus, contains, exists, in, not Insert command and semantics Delete command and semantics Update command and semantics Aggregate functions: avg, min, max, sum, count group by clause having clause

SQL: Multiple Group Bys Example: using relation emp(ss#, ename, dept, cat, sal) Count the employees and average monthly salary for each employee category in each department selectdept, cat, count(*), avg(sal)/12 fromemp group bydept, cat

SQL: Multiple Group Bys Select … from emp group by cat Select … from emp group by dept

SQL: Multiple Group By Select … from emp group by dname, cat note that some dname/cat groups are empty.

SQL: Examples on Having Find the average salary of employees under 30 for each department with more than 10 such employees selectdname, avg(sal) fromemp whereage<30 (employee age under 30) group by dname (group by department) having10 10)

SQL: Examples on Having Find the average salary of employees under 30 for each department with more than 10 employees selecte.dname, avg(e.sal) fromemp e wheree.age<30 (employee age under 30) group by e.dname (group by department) having10<any (selectcount(ee.ename) (number of employees in group) fromemp ee whereee.dname=e.dname) (… from the same dept as e) (why is this query different from the previous one?)

SQL: Examples on Having Find categories of employees whose average salary exceeds that of programmers selectcat, avg(sal) fromemp group bycat havingavg(sal)> (select avg(sal) from emp where cat=“programmer”)

SQL: Examples on Having Find all departments with at least two clerks selectdname fromemp wherejob=“clerk” group bydname havingcount(*) >= 2

SQL: Examples Find the names of sailors with the highest rating selectsname fromsailors whererating = (selectmax(rating) from sailors)

SQL: Examples For each boat, find the number of sailors of rating >7 who have reserved this boat selectbid, bname, count(s.sid) fromsailors s, boats b, reserve r wheres.sid=r.sid and r.bid=b.bid and rating>7 group byb.bid

SQL: Examples For each red boat, find the number of sailors who have reserved this boat selectbid, bname, count(s.sid) fromsailors s, boats b, reserve r wheres.sid=r.sid and r.bid=b.bid group byb.bid havingcolour=“red”

SQL: Examples Difference between the last two queries? –First one gave a qualification on the tuples (take all tuples of the multijoin discard tuples that do not fulfill ratings>7 then group them by boat id then find the cardinality of each group) –Second one gave a qualification for the groups (take all tuples of the multijoin group them by boat id discard groups representing boats that are non-red find the cardinality of remaining groups)

And Now, For Something Completely Different... The recent SQL material largely covers chapter 4, at least sections 4.1 through 4.6 and some of 4.9. Earlier we examined Relational Algebra, covering sections 3.1 through 3.3 Now we leave chapter 4 and head back to examine sections 3.6 and 3.7, covering Relational Calculi –based upon predicate calculus –non-procedural query languages (descriptive rather than prescriptive) –we will examine two relational calculi: tuple calculus and domain calculus

Tuple Calculus Query: {t | P(t)} P: is a predicate associated with some relation R t: is a tuple variable ranging over the relation R t[A]: is the value of attribute A in tuple t –students in CMSC 424 {t | t  enroll  t[course#] = CMSC424} – students in CMSC 424 conforming with the CMSC-420 prerequisite {t | t  enroll   s  enroll  t[course#] = CMSC424  s[course#] = CMSC420  t[ss#] = s[ss#]}

Tuple Calculus Quantifiers and free variables – ,  quantify the variables following them, binding them to some value. (in the previous slide, s was bound by  ) –A tuple variable that is not quantified by  or  is called a free variable. (in the previous slide, t was a free variable) Atoms –R(t)where t is a tuple variable –t[x]  s[y]where t,s are tuple variables and   { , , , , ,  }

Tuple Calculus Formulas –an Atom is a Formula –If P and Q are Formulas, then so are (P),  P, P  Q, P  Q, and P  Q –If P(t) is a Formula, then so are  t P(t) and  t P(t) Equivalences –  (P  Q)   P   Q –  (P  Q)   P   Q –  t P(t)   (  t (  P(t))) –  t P(t)   (  t (  P(t)))

Tuple Calculus Safety –Math is too powerful; we can easily phrase expressions that describe infinite sets {t | t  enroll} –These expressions are called unsafe –When we are dealing with finite sets, unsafe expressions happen in expressions that involve negation (  ) –We can avoid this problem by using an entirely positive (non- negated) scope as the first operand of any conjunction where we use negation. The first operand establishes the scope and the second one filters the established scope. {t | t  enroll  t[course#]  CMSC-420}

Domain Calculus Another form of relational calculus Uses domain variables that take values from an attribute’s domain, rather than values representing an entire tuple Closely related to tuple calculus Domain Calculus serves as the theoretical basis for the query language QBE, just as the relational algebra we examined earlier forms the basis for SQL Expressions are of the form: { | P( x 1, x 2, x 3,..., x n ) }

Domain Calculus Atoms –  R –x  ywhere x,y are domain variables and   { , , , , ,  } –x  cwhere c is a constant Formulas –an atom is a formula –If P and Q are formulas, then so are (P),  P, P  Q, P  Q, and P  Q –If P(x) is a formula and x is a domain variable, then  x P(x) and  x P(x) are also formulas

Domain Calculus Queries are of the form: { | P( x 1, x 2, x 3,..., x n ) } Examples { | Enroll(ss#, course#, semester)} { | Enroll(x, y, z)  y = CMSC-424}

Reductions of Relational Algebra and Calculi Relational Algebra (sections ), Tuple Calculus (section 3.6), and Domain Calculus (section 3.7) can be reduced to each other: they have equivalent expressive power. For every expression in one, we can compute an equivalent expression in the others.

Functional Dependencies Important concept in differentiating good database designs from bad ones FD is a generalization of the notion of keys An FD is a set of attributes whose values uniquely determine the values of the remaining attributes. Emp(eno, ename, sal) key FDs:eno => ename Dept(dno, dname, floor) eno => sal Works-in(eno, dno, hours) (eno,dno) => hours dno => dname dno => floor

Functional Dependencies If   R and   R, then  =>  holds in the extension r(R) of R iff for any pair t1 and t2 tuples of r(R) such that t1(  )=t2(  ), then it is also true that t1(  ) = t2(  ) We can use FDs as –constraints we wish to enforce (e.g., keys) –for checking to see if the FDs are satisfied within the database R(A BC D) A => Bsatisfied?no A => Csatisfied?yes C => Asatisfied?no AB => Dsatisfied?yes

Functional Dependencies Trivial dependencies:  =>   =>  if    Closure –we need to consider all FDs –some are implied by others; e.g., FDs are transitive; if A=>B and B=>C, then A=>C –Given F = set of FDs, we want to find F’ (the closure of all FDs logically implied by F)

Armstrong’s Axioms Reflexivityif    then  =>  Augmentationif  =>  then    Transitivityif  =>  and  =>  then  =>  Armstrong’s Axioms can be used to derive three additional useful rules: Union ruleif  =>  and  =>  then  =>  Decomposition ruleif  =>  then  =>  and  =>  Pseudotransitivity ruleif  =>  and  =>  then  => 

FD Example R(A, B, C, G, H, I) F=(A=>B A=>C CG => H CG => I B => H ) F+=(A => H transitivity: A => B => H CG => HI union rule: CG => H, CG => I AG => I augmentation: A=> C, AG => CG => I AG => H ) augmentation: A=> C, AG => CG => H

Closure of Attribute Sets Useful to test if an attribute set is a superkey the closure  + of a set of attributes  under F is the set of all attributes that are functionally determined by  there is an algorithm to compute the closure R(A, B, C, G, H, I) F=(A=>B, A=>C, CG => H, CG => I, B => H ) Example: Algorithm to compute (AG)+ starts withresult=(AG) A=>B expandsresult=(AGB) A=>C expandsresult=(AGBC) CG=>H expandsresult=(AGBCH) CG=>I expandsresult=(AGBCHI) B=>H causes no more expansion

Uses of Attribute Closure Testing for superkey –to test if  is a superkey, compute  + and determine if  + contains all attributes of R Testing functional dependencies –to check if a functional dependency  =>  holds, (is in F+) just check to see if    + –in other words, we compute  + using attribute closure, and then check if the result contains . –Simple, cheap, and useful test.