©Silberschatz, Korth and Sudarshan1Database System Concepts Tuple and Domain Calculus Tuple Relational Calculus Domain Relational Calculus.

Slides:



Advertisements
Similar presentations
Database System Concepts, 5th Ed. ©Silberschatz, Korth and Sudarshan See for conditions on re-usewww.db-book.com Chapter 5: Other Relational.
Advertisements

Chapter 3 Tuple and Domain Relational Calculus. Tuple Relational Calculus.
©Silberschatz, Korth and Sudarshan5.1Database System Concepts Chapter 5: Other Relational Languages Query-by-Example (QBE) Datalog.
RELATIONAL CALCULUS Rohit Khokher. INTRODUCTION Relational calculus is a formal query language where the queries are expressed as variables and formulas.
©Silberschatz, Korth and Sudarshan3.1Database System Concepts Chapter 3: Relational Model Structure of Relational Databases Relational Algebra Tuple Relational.
E-R Diagram for a Banking Enterprise
Domain Relational Calculus and Query-by-Example CS157a John Eagle.
©Silberschatz, Korth and Sudarshan3.1Database System Concepts Chapter 3: Relational Model Structure of Relational Databases Relational Algebra Extended.
Relational Calculus Ameetinder Singh CS 157A. Tuple Relational Calculus  non-procedural query language as compared to relational algebra that is procedural.
©Silberschatz, Korth and Sudarshan3.1Database System Concepts Chapter 3: Relational Model Structure of Relational Databases Relational Algebra Tuple Relational.
©Silberschatz, Korth and Sudarshan4.1Database System Concepts Ordering the Display of Tuples List in alphabetic order the names of all customers having.
Midterm 2 Revision Prof. Sin-Min Lee Department of Computer Science San Jose State University.
©Silberschatz, Korth and Sudarshan3.1Database System Concepts Extended Relational-Algebra-Operations Generalized Projection Outer Join Aggregate Functions.
Database System Concepts, 5th Ed. ©Silberschatz, Korth and Sudarshan See for conditions on re-usewww.db-book.com Chapter 3: SQL.
©Silberschatz, Korth and Sudarshan4.1Database System Concepts Chapter 4: SQL Basic Structure Set Operations Aggregate Functions Null Values Nested Subqueries.
SQL Structured Query Language Meizhen Huang. Content (4.1 – 4.4) Background Parts of SQL Basic Structure Set Operations Aggregate Functions.
©Silberschatz, Korth and Sudarshan3.1Database System Concepts Chapter 3: Relational Model Structure of Relational Databases Relational Algebra Extended.
SPRING 2004CENG 3521 E-R Diagram for the Banking Enterprise.
Slides adapted from A. Silberschatz et al. Database System Concepts, 5th Ed. SQL - part 2 - Database Management Systems I Alex Coman, Winter 2006.
©Silberschatz, Korth and Sudarshan4.1Database System Concepts Aandachtspunten Deadlines – alles op tijd inleveren! n Lees goed wat van je verwacht wordt!
MySQL Tutorial (2) Introduction to Database. Banking Example branch (branch-name, branch-city, assets) customer (customer-name, customer-street, customer-city)
Database System Concepts, 5th Ed. ©Silberschatz, Korth and Sudarshan See for conditions on re-usewww.db-book.com Chapter 5: Other Relational.
©Silberschatz, Korth and Sudarshan3.1Database System Concepts Calculus Objectives  Tuple Calculus  Domain Calculus  QBE & SQL  Related Examples.
Dr. Alexandra I. Cristea CS 319: Theory of Databases: C6.
Chapters 2 & 6 The Relational Model. 2  A tabular data structure  Tables (relations) with unique names  rows (tuples/entities/records)  columns (attributes/fields)
©Silberschatz, Korth and Sudarshan4.1Database System Concepts Chapter 4: SQL Basic Structure Set Operations Aggregate Functions Null Values Nested Subqueries.
©Silberschatz, Korth and Sudarshan4.1Database System Concepts Null Values It is possible for tuples to have a null value for some of their attributes The.
©Silberschatz, Korth and Sudarshan3.1Database System Concepts Chapter 3: Relational Model Structure of Relational Databases Relational Algebra Tuple Relational.
©Silberschatz, Korth and Sudarshan3.1Database System Concepts Chapter 3: Relational Model Structure of Relational Databases Relational Algebra Tuple Relational.
©Silberschatz, Korth and Sudarshan3.1Database System Concepts Banking Example  branch (branch-name, branch-city, assets)  customer (customer-name, customer-street,
Lecture 6 Structured Query Language SQL Lecture 6 Structured Query Language SQL Instructor: Haya Sammaneh.
Chapter 5: Other Relational Languages. 5.2 Chapter 5: Other Relational Languages Tuple Relational Calculus Domain Relational Calculus Query-by-Example.
Relational Model: Examples. Banking Example branch (branch_name, branch_city, assets) customer (customer_name, customer_street, customer_city) account.
Relational Algebra Instructor: Mohamed Eltabakh 1.
Temple University – CIS Dept. CIS331– Principles of Database Systems V. Megalooikonomou Relational Model III (based on notes by Silberchatz,Korth, and.
Database System Concepts, 5 th Ed. ©Silberschatz, Korth and Sudarshan See for conditions on re-usewww.db-book.com Chapter 2: Relational.
©Silberschatz, Korth and Sudarshan2.1Database System Concepts - 5 th Edition, Oct 5, 2006 Outer Join n An extension of the join operation that avoids loss.
Database System Concepts, 6 th Ed. ©Silberschatz, Korth and Sudarshan See for conditions on re-usewww.db-book.com Chapter 6: Formal Relational.
Department of Computer Science, HKUST 1 Comp 231 Database Management Systems Comp 231 Database Management Systems 3. Relational Data Model.
©Silberschatz, Korth and Sudarshan5.1Database System Concepts Chapter 5: Other Relational Languages Query-by-Example (QBE)
CS 370 Database Systems Lecture 11 Relational Algebra.
Computing & Information Sciences Kansas State University Thursday, 08 Feb 2007CIS 560: Database System Concepts Lecture 11 of 42 Thursday, 08 February.
Midterm 2 Revision Prof. Sin-Min Lee Department of Mathematics and Computer Science San Jose State University.
Relational Model By Dr.S.Sridhar, Ph.D.(JNUD), RACI(Paris, NICE), RMR(USA), RZFM(Germany) DIRECTOR ARUNAI ENGINEERING COLLEGE TIRUVANNAMALAI.
©Silberschatz, Korth and Sudarshan5.1Database System Concepts Chapter 5: Other Relational Query Languages Tuple Relational Calculus Domain Relational Calculus.
ICOM 5016 – Introduction to Database Systems Lecture 8 Dr. Manuel Rodriguez Department of Electrical and Computer Engineering University of Puerto Rico,
©Silberschatz, Korth and Sudarshan3.1Database System Concepts, 5 th Edition, Oct 5, 2006 SQL Data Definition Basic Query Structure Set Operations Aggregate.
Chapter 8: SQL. Data Definition Modification of the Database Basic Query Structure Aggregate Functions.
©Silberschatz, Korth and Sudarshan2.1Database System Concepts - 5 th Edition, Oct 5, 2006 Example.
Source: Database System Concepts, Silberschatz etc Edited: Wei-Pang Yang, IM.NDHU, Introduction to Database CHAPTER 5 Other Relational Languages.
Chapter 2: Relational Model II Relational Algebra basics Relational Algebra basics.
2.1 Chapter 2: Relational Model. 2.2 Chapter 2: Relational Model Structure of Relational Databases Fundamental Relational-Algebra-Operations Additional.
©Silberschatz, Korth and Sudarshan3.1Database System Concepts Chapter 3: Relational Model Structure of Relational Databases Relational Algebra Extended.
Database System Concepts, 5 th Ed. ©Silberschatz, Korth and Sudarshan See for conditions on re-usewww.db-book.com Chapter 2: Relational.
Database System Concepts, 5th Ed. Bin Mu at Tongji University Chapter 5: Other Relational Languages.
©Silberschatz, Korth and Sudarshan3.1Database System Concepts Extended Relational-Algebra-Operations Generalized Projection Aggregate Functions Outer Join.
Midterm 2 Revision Prof. Sin-Min Lee Department of Computer Science San Jose State University.
Computing & Information Sciences Kansas State University Wednesday, 17 Sep 2008CIS 560: Database System Concepts Lecture 9 of 42 Wednesday, 18 September.
Database System Concepts, 5th Ed. ©Silberschatz, Korth and Sudarshan Chapter 5: Other Relational Languages.
Relational Algebra HW2 Turn in as a hardcopy at the start of next class period. You may work this assignment in groups.
©Silberschatz, Korth and Sudarshan3.1Database System Concepts Week 3: Relational Model Structure of Relational Databases Relational Algebra Extended Relational-Algebra-Operations.
ICOM 5016 – Introduction to Database Systems Lecture 6 Dr. Manuel Rodriguez Department of Electrical and Computer Engineering University of Puerto Rico,
1 Session 3 Welcome: To session 3-the fourth learning sequence “Relational algebra “ Recap : In the previous learning sequences, we discussed the four.
Database System Concepts, 5 th Ed. ©Silberschatz, Korth and Sudarshan See for conditions on re-usewww.db-book.com Chapter 2: Relational.
Database System Concepts, 5th Ed. ©Silberschatz, Korth and Sudarshan See for conditions on re-usewww.db-book.com Chapter 5: Other Relational.
Temple University – CIS Dept. CIS616– Principles of Database Systems V. Megalooikonomou Relational Model (based on notes by Silberchatz,Korth, and Sudarshan.
©Silberschatz, Korth and Sudarshan2.1Database System Concepts Chapter 2: Relational Model Structure of Relational Databases Relational Algebra Tuple Relational.
©Silberschatz, Korth and Sudarshan3.1Database System Concepts Chapter 3: Relational Model Structure of Relational Databases Relational Algebra Tuple Relational.
Query Languages Language in which user requests information from the database. Categories of languages Procedural Non-procedural, or declarative “Pure”
CS 480: Database Systems Lecture 16 February 20,2013.
Presentation transcript:

©Silberschatz, Korth and Sudarshan1Database System Concepts Tuple and Domain Calculus Tuple Relational Calculus Domain Relational Calculus

©Silberschatz, Korth and Sudarshan2Database System Concepts Banking Example Recall the banking database: branch (branch-name, branch-city, assets) customer (customer-name, customer-street, customer-city) account (account-number, branch-name, balance) loan (loan-number, branch-name, amount) depositor (customer-name, account-number) borrower (customer-name, loan-number)

©Silberschatz, Korth and Sudarshan3Database System Concepts Tuple Relational Calculus A nonprocedural query language, where each query is of the form: { t | P (t) }  Read as “the set of all tuples t such that predicate P is true for t”  P is a formula similar to that of the predicate calculus

©Silberschatz, Korth and Sudarshan4Database System Concepts Predicate Calculus Formula The predicate P(t) will contain several types of syntactic elements: Tuple and relation variables: t  customer -- t has all of the attributes of customer u  depositor-- u has all the attributes of depositor v  loan-- v has all the attributes of load

©Silberschatz, Korth and Sudarshan5Database System Concepts Predicate Calculus Formula Attribute names: t[customer-name]t[customer-street]t[customer-city] u[account-number]u[customer-name] v[amount]v[loan-number]v[branch-name]

©Silberschatz, Korth and Sudarshan6Database System Concepts Predicate Calculus Formula Comparisons: , , , , ,  t[customer-name] = “Smith” u[account-number] = A-175 v[amount]  1000 t[customer-city] = “Orlando” “Orlando” = t[customer-city] u[loan-number] = v[loan-number]

©Silberschatz, Korth and Sudarshan7Database System Concepts Predicate Calculus Formula Connectives: , v‚  u[account-number] = A-175  u[balance] > 1000 (t[customer-name] = “Smith”  t[city] = “Orlando”) v  (u[account-number] = A-175)

©Silberschatz, Korth and Sudarshan8Database System Concepts Predicate Calculus Formula Implication: x  y, if x is true, then y is true t[customer-name] = “Smith”  (t[city] = “Orlando” v u[amount] < 500) By the way, x  y  x v y

©Silberschatz, Korth and Sudarshan9Database System Concepts Predicate Calculus Formula Quantifiers:   t  r (Q(t))  ”there exists” a tuple t in relation r such that Q(t) is true   t  r (Q(t))  Q(t) is true “for all” tuples t in relation r  t  customer (t[customer-name] = “Smith”)  u  account (u[balance] > 1000  u[branch-name] = “Perryridge”)

©Silberschatz, Korth and Sudarshan10Database System Concepts Example Queries Find the loan-number, branch-name, and amount for loans of over $1200. How about the following? {t |  s  loan (t = s  s [amount]  1200)} {t | t  loan  t [amount]  1200} {t | t [amount]  1200}

©Silberschatz, Korth and Sudarshan11Database System Concepts Example Queries Find the loan number for each loan having an amount greater than $1200. Note a relation on [loan-number] is implicitly defined by the expression. {t |  s  loan (t[loan-number] = s[loan-number]  s[amount]  1200)}

©Silberschatz, Korth and Sudarshan12Database System Concepts Example Queries Find the names of all customers who have a loan and an account at the bank. Find the names of all customers having a loan, an account, or both at the bank. {t |  s  borrower( t[customer-name] = s[customer-name])   u  depositor( t[customer-name] = u[customer-name])} {t |  s  borrower( t[customer-name] = s[customer-name])   u  depositor( t[customer-name] = u[customer-name])}

©Silberschatz, Korth and Sudarshan13Database System Concepts Example Queries If someone has an account or a loan at the bank, shouldn’t their name appear in the customer relation? If it is the case that a name will appear in customer if and only if it appears in borrower or depositor, then: However, there is nothing in the text or schema description to indicate this is the case, so the depositor and borrower relations must be examined. {t |  s  customer( t[customer-name] = s[customer-name])}

©Silberschatz, Korth and Sudarshan14Database System Concepts Example Queries Find the names of all customers having a loan at the Perryridge branch. {t |  s  borrower( t[customer-name] = s[customer-name]   u  loan(u[branch-name] = “Perryridge”  u[loan-number] = s[loan-number]))    v  depositor (v[customer-name] = t[customer-name]) } Find the names of all customers who have a loan at the Perryridge branch, but no account at any branch of the bank. {t |  s  borrower(t[customer-name] = s[customer-name]   u  loan(u[branch-name] = “Perryridge”  u[loan-number] = s[loan-number]))}

©Silberschatz, Korth and Sudarshan15Database System Concepts Example Queries Find the names of customers and their cities of residence for those customers having a loan from the Perryridge branch. Note the above contains a mistake…and a couple of other issues too… {t |  s  loan(s[branch-name] = “Perryridge”   u  borrower (u[loan-number] = s[loan-number]  t [customer-name] = u[customer-name])   v  customer (u[customer-name] = v[customer-name]  t[customer-city] = v[customer-city])))}

©Silberschatz, Korth and Sudarshan16Database System Concepts Safety of Expressions Some tuple calculus expressions result in infinite relations. {t |  t  r} { t | t[A]=5  true } { t |   u  customer (t[customer-name] = u[customer-name])} Such expressions don’t make sense in the context of databases.

©Silberschatz, Korth and Sudarshan17Database System Concepts Safety of Expressions Hence, we restrict our use to what are called “safe” expressions. An expression {t | P(t)} in tuple calculus is said to be safe if every value in the result of the expression is a function of some value in the database, i.e., appears in, or is a modified version of a value in one of the relations, or is a tuple or constant that appears in P. In other words, the results have to come directly or indirectly out of the database.

©Silberschatz, Korth and Sudarshan18Database System Concepts Example Queries Find the names of all customers who have an account at all branches located in Brooklyn: Note that the above query is unsafe, but why? Consider a branch relation that consists of no Brooklyn branches.  Every customer is in the result.  Even “garbage” values are in the result. {t |  s  branch(s[branch-city] = “Brooklyn”   u  account(u[branch-name] = s[branch-name]   v  depositor(v[account-number] = u[account-number]  t[customer-name] = v[customer-name])))}

©Silberschatz, Korth and Sudarshan19Database System Concepts Another, Safe Version Find the names of all customers who have an account at all branches located in Brooklyn (safe version): Note how this solution eliminates the “garbage” values. {t |  c  customer (t[customer.name] = c[customer-name])   s  branch(s[branch-city] = “Brooklyn”   u  account(u[branch-name] = s[branch-name]   v  depositor(v[account-number] = u[account-number]  t[customer-name] = v[customer-name])))}

©Silberschatz, Korth and Sudarshan20Database System Concepts Example Queries What would happen if we changed the logical implication to a conjunction? More specifically, what would be the meaning of the tuple calculus expression? This is a more restrictive query (somewhat arbitrary) than the original, however, unlike the first expression, it is safe (why?). {t |  s  branch(s[branch-city] = “Brooklyn”   u  account(u[branch-name] = s[branch-name]   v  depositor(v[account-number] = u[account-number]  t[customer-name] = v[customer-name])))}

©Silberschatz, Korth and Sudarshan21Database System Concepts Example Queries Similarly one could ask what would happen if we changed the logical implication to a disjunction? Exercise:  What would be the meaning of the tuple calculus expression? More specifically, what would have to be true for a tuple to appear in the result?  Is the expression safe? {t |  s  branch(s[branch-city] = “Brooklyn”   u  account(u[branch-name] = s[branch-name]   v  depositor(v[account-number] = u[account-number]  t[customer-name] = v[customer-name])))}

©Silberschatz, Korth and Sudarshan22Database System Concepts Domain Relational Calculus A nonprocedural query language equivalent in power to the tuple relational calculus A query is an expression of the form: {  x 1, x 2, …, x n  | P(x 1, x 2, …, x n )}  x 1, x 2, …, x n represent domain variables  P represents a formula similar to that of the predicate calculus

©Silberschatz, Korth and Sudarshan23Database System Concepts Example Queries Find the loan-number, branch-name, and amount for loans of over $1200 {  c, a  |  l (  c, l   borrower   b(  l, b, a   loan  b = “Perryridge”))} or {  c, a  |  l (  c, l   borrower   l, “Perryridge”, a   loan)} Find the names of all customers who have a loan at the Perryridge branch; also include the loan amount: {  c  |  l, b, a (  c, l   borrower   l, b, a   loan  a > 1200)} Find the names of all customers who have a loan of over $1200 {  l, b, a  |  l, b, a   loan  a > 1200}

©Silberschatz, Korth and Sudarshan24Database System Concepts Example Queries Find the names of all customers having a loan, an account, or both at the Perryridge branch: {  c  |  s, n (  c, s, n   customer)   x,y,z((  x, y, z   branch  y = “Brooklyn”)   a,b(  a, x, b   account   c,a   depositor))} Find the names of all customers who have an account at all branches located in Brooklyn: {  c  |  l (  c, l   borrower   b,a(  l, b, a   loan  b = “Perryridge”))   a(  c, a   depositor   b,n(  a, b, n   account  b = “Perryridge”))}

©Silberschatz, Korth and Sudarshan25Database System Concepts Safety of Expressions As with tuple calculus, we restrict ourselves to those domain relational calculus expressions that are “safe,” i.e., whose resulting values come directly or indirectly from the database.