CSC 261/461 Database Systems Lecture 14. Spring 2017 MW 3:25 pm 4:40 pm January 18 May 3 Dewey 1101

Transcription

1 CSC 261/461 Database Systems Lecture 14 Spring 2017 MW 3:25 pm 4:40 pm January 18 May 3 Dewey 1101

2 Announcement Midterm on this Wednesday Please arrive 5 minutes early; We will start at 3:25 sharp I may post a sitting arrangement tomorrow. Start studying for MT

3 Are you ready?

4 Night before the exam

5 During the exam

6 Or Finishing too early

7 MIDTERM REVIEW

8 Chapters to Read Chapter 1 Chapter 2 Chapter 3 Chapter 4 (Just the basics. Only ISA relationships. Even studying the slides is fine) Chapter 5, 6, 7 (SQL) Chapter 8 Chapter 9 Chapter 14 ( ) Chapter 15 ( ) 8

9 Exam Structure Problem 1 (20 pts) Short answers, True/False, or One liner Other problems (40 pts) Total: 60 pts 2 bonus points for writing the class id correctly.

10 Time distribution Time crunch Not really Should take more than 60 minutes to finish. Not as relaxed as the quiz

11 MATERIALS COVERED

12 Questions to ponder Why not Lists? Why database? How related tables avoid problems associated with lists?

13 Problems with Lists Multiple Concepts or Themes: Microsoft Excel vs Microsoft Access Redundancy Anomalies: Deletion anomalies Update anomalies Insertion anomalies

14 List vs Database Lists do not provide information about relations! Break lists into tables Facilitates: Insert Delete Update Input and Output interface (Forms and Reports) Query!

15 Again, Why database? To store data To provide structure Mechanism for querying, creating, modifying and deleting data. CRED (Create, Read, Update, Delete) Store information and relationships

16 Simplified Database System Environment

17 SQL

18 General form SQL SELECT S FROM R 1,,R n WHERE C 1 GROUP BY a 1,,a k HAVING C 2 Evaluation steps: 1. Evaluate FROM-WHERE: apply condition C 1 on the attributes in R 1,,R n 2. GROUP BY the attributes a 1,,a k 3. Apply condition C 2 to each group (may have aggregates) 4. Compute aggregates in S and return the result

19 Grouping and Aggregation Semantics of the query: 1. Compute the FROM and WHERE clauses 2. Group by the attributes in the GROUP BY 3. Compute the SELECT clause: grouped attributes and aggregates 19

20 1. Compute the FROM and WHERE clauses SELECT product, SUM(price*quantity) AS TotalSales FROM Purchase WHERE date > 10/1/2005 GROUP BY product FROM Product Date Price Quantity Bagel 10/ Bagel 10/ Banana 10/ Banana 10/

21 2. Group by the attributes in the GROUP BY SELECT product, SUM(price*quantity) AS TotalSales FROM Purchase WHERE date > 10/1/2005 GROUP BY product Product Date Price Quantity Bagel 10/ Bagel 10/ Banana 10/ Banana 10/ GROUP BY Product Date Price Quantity Bagel 10/ / Banana 10/ /

22 3. Compute the SELECT clause: grouped attributes and aggregates SELECT product, SUM(price*quantity) AS TotalSales FROM Purchase WHERE date > 10/1/2005 GROUP BY product Product Date Price Quantity Bagel 10/ / Banana 10/ / SELECT Product TotalSales Bagel 50 Banana 15 22

23 HAVING Clause SELECT product, SUM(price*quantity) FROM Purchase WHERE date > 10/1/2005 GROUP BY product HAVING SUM(quantity) > 100 HAVING clauses contains conditions on aggregates Same query as before, except that we consider only products that have more than 100 buyers Whereas WHERE clauses condition on individual tuples 23

24 Null Values Unexpected behavior: SELECT * FROM Person WHERE age < 25 OR age >= 25 Some Persons are not included! 24

25 Null Values Can test for NULL explicitly: x IS NULL x IS NOT NULL SELECT * FROM Person WHERE age < 25 OR age >= 25 OR age IS NULL Now it includes all Persons! 25

26 Inner Joins By default, joins in SQL are inner joins : Product(name, category) Purchase(prodName, store) SELECT Product.name, Purchase.store FROM Product JOIN Purchase ON Product.name = Purchase.prodName SELECT Product.name, Purchase.store FROM Product, Purchase WHERE Product.name = Purchase.prodName Both equivalent: Both INNER JOINS! 26

27 Inner Joins + NULLS = Lost data? By default, joins in SQL are inner joins : Product(name, category) Purchase(prodName, store) SELECT Product.name, Purchase.store FROM Product JOIN Purchase ON Product.name = Purchase.prodName SELECT Product.name, Purchase.store FROM Product, Purchase WHERE Product.name = Purchase.prodName However: Products that never sold (with no Purchase tuple) will be lost! 27

28 Product INNER JOIN: Purchase name category prodname store Gizmo gadget Gizmo Wiz Camera Photo Camera Ritz OneClick Photo Camera Wiz SELECT Product.name, Purchase.store FROM Product INNER JOIN Purchase ON Product.name = Purchase.prodName Note: another equivalent way to write an INNER JOIN! name Gizmo Camera Camera store Wiz Ritz Wiz 28

29 Product LEFT OUTER JOIN: Purchase name category prodname store Gizmo gadget Gizmo Wiz Camera Photo Camera Ritz OneClick Photo Camera Wiz SELECT Product.name, Purchase.store FROM Product LEFT OUTER JOIN Purchase ON Product.name = Purchase.prodName name Gizmo Camera Camera OneClick store Wiz Ritz Wiz NULL 29

30 Other Outer Joins Left outer join: Include the left tuple even if there s no match Right outer join: Include the right tuple even if there s no match Full outer join: Include the both left and right tuples even if there s no match 30

31 Also read Triggers Views Operations on Databases Create, Drop, and Alter Operations of Tables Create, Delete and Update Constraint: Key constraint Foreign key On Delete cascade, Set Null, Set Default;

32 DATABASE DESIGN

33 Database Design Process 1. Requirements Analysis 2. Conceptual Design 1. Requirements analysis What is going to be stored? 3. Logical, Physical, Security, etc. Technical and nontechnical people are involved How is it going to be used? What are we going to do with the data? Who should access the data?

34 Database Design Process 1. Requirements Analysis 2. Conceptual Design 3. Logical, Physical, Security, etc. 2. Conceptual Design A high-level description of the database Sufficiently precise that technical people can understand it But, not so precise that non-technical people can t participate This is where E/R fits in.

35 Database Design Process 1. Requirements Analysis 2. Conceptual Design 3. Logical, Physical, Security, etc. 3. Implementation: Logical Database Design Physical Database Design Security Design

36 Database Design Process 1. Requirements Analysis 2. Conceptual Design 3. Logical, Physical, Security, etc. E/R Model & Diagrams used name category price Product Makes name Company This process is iterated many times E/R is a visual syntax for DB design which is precise enough for technical points, but abstracted enough for non-technical people

37 Requirements Become the E-R Data Model After the requirements have been gathered, they are transformed into an Entity Relationship (E-R) Data Model E-R Models consist of 1. Entities 2. Attributes a) Identifiers (Keys) b) Non-key attributes 3. Relationships

38 1. E/R BASICS: ENTITIES & RELATIONS

39 Entities and Entity Sets An entity set has attributes Represented by ovals attached to an entity set Shapes are important. Colors are not. name category price Product

40 Keys A key is a minimal set of attributes that uniquely identifies an entity. Denote elements of the primary key by underlining. price name Product category Here, {name, category} is nota key (it is not minimal). The E/R model forces us to designate a single primary key, though there may be multiple candidate keys

41 Relationships A relationship connects two or more entity sets. It is represented by a diamond, with lines to each of the entity sets involved. The degree of the relationship defines the number of entity classes that participate in the relationship Degree 1 is a unary relationship Degree 2 is a binary relationship Degree 3 is a ternary relationship

42 Conceptual Unary Relationship Person Marries

43 Conceptual Binary Relationship Person Owns Cars

44 Conceptual Ternary Relationship Doctor Patient Prescription Drug

45 The R in E/R: Relationships E, R and A together: name category name price Product Makes Company

46 What is a Relationship? name category name price Product Makes Company A relationship between entity sets P and C is a subset of all possible pairs of entities in P and C, with tuples uniquely identified by P and C s keys

47 What is a Relationship? Company Product name name category price GizmoWorks Gizmo Electronics $9.99 GadgetCorp GizmoLite Electronics $7.50 Gadget Toys $5.50 name category name price Product Makes Company Company C Product P C.name P.name P.category P.price GizmoWorks Gizmo Electronics $9.99 GizmoWorks GizmoLite Electronics $7.50 GizmoWorks Gadget Toys $5.50 GadgetCorp Gizmo Electronics $9.99 GadgetCorp GizmoLite Electronics $7.50 GadgetCorp Gadget Toys $5.50 A relationship between entity sets P and C is a subset of all possible pairs of entities in P and C, with tuples uniquely identified by P and C s keys

48 What is a Relationship? Company name GizmoWorks GadgetCorp price name Product Product name category price Gizmo Electronics $9.99 GizmoLite Electronics $7.50 Gadget Toys $5.50 category Makes name Company A relationship between entity sets P and C is a subset of all possible pairs of entities in P and C, with tuples uniquely identified by P and C s keys Company C Product P C.name P.name P.category P.price GizmoWorks Gizmo Electronics $9.99 GizmoWorks GizmoLite Electronics $7.50 GizmoWorks Gadget Toys $5.50 GadgetCorp Gizmo Electronics $9.99 GadgetCorp GizmoLite Electronics $7.50 GadgetCorp Gadget Toys $5.50 Makes C.name P.name GizmoWorks Gizmo GizmoWorks GizmoLite GadgetCorp Gadget

49 Relationships and Attributes Relationships may have attributes as well. name category since name price Product Makes Company For example: since records when company started making a product Note: since is implicitly unique per pair here! Why?

50 Summary Summary Identifying Relationship

51 Design Theory (ER model to Relations)

52 Entity Sets to Tables name ssn name lot ssn lot Alex Bob John 12 Employees CREATE TABLE Employees ( ssn char(11), name varchar(30), lot Integer, PRIMARY KEY (ssn))

53 Other Conversions (ER model to Tables) Relationships: Many to Many One to Many One to One

54 Scenario One customer can have at max 2 loans. One loan can be given to multiple customers. What it really means: One customer can have (0,2) loans One loan can be given to (1,n) customer This is a many to many scenario

55 Crow s foot Notation Chen Notation

56 FUNCTIONAL DEPENDECIES

57 Prime and Non-prime attributes A Prime attribute must be a member of some candidate key A Nonprime attribute is not a prime attribute that is, it is not a member of any candidate key.

58 Back to Conceptual Design Now that we know how to find FDs, it s a straight-forward process: 1. Search for bad FDs 2. If there are any, then keep decomposing the table into sub-tables until no more bad FDs 3. When done, the database schema is normalized 58

59 Boyce-Codd Normal Form (BCNF) Main idea is that we define good and bad FDs as follows: X à A is a good FD if X is a (super)key In other words, if A is the set of all attributes X à A is a bad FD otherwise We will try to eliminate the bad FDs! Via normalization

60 Normalizing into 2NF and 3NF

61 Figure Normalization into 2NF and 3NF Figure Normalization into 2NF and 3NF. (a) The LOTS relation with its functional dependencies FD1 through FD4. (b) Decomposing into the 2NF relations LOTS1 and LOTS2. (c) Decomposing LOTS1 into the 3NF relations LOTS1A and LOTS1B. (d) Progressive normalization of LOTS into a 3NF design. Slide 14-61

62 Normal Forms Defined Informally 1 st normal form All attributes depend on the key 2 nd normal form All attributes depend on the whole key 3 rd normal form All attributes depend on nothing but the key Slide 14-62

63 General Definition of 2NF and 3NF (For Multiple Candidate Keys) A relation schema R is in second normal form (2NF) if every non-prime attribute A in R is fully functionally dependent on every key of R A relation schema R is in third normal form (3NF) if it is in 2NF and no non-prime attribute A in R is transitively dependent on any key of R Slide 14-63

64 1. BOYCE-CODD NORMAL FORM 64

65 Figure A relation TEACH that is in 3NF but not in BCNF Two FDs exist in the relation TEACH: fd1: { student, course} -> instructor fd2: instructor -> course {student, course} is a candidate key for this relation So this relation is in 3NF but not in BCNF A relation NOT in BCNF should be decomposed so as to meet this property, while possibly forgoing the preservation of all functional dependencies in the decomposed relations. Slide 14-65

66 Achieving the BCNF by Decomposition (2) n Three possible decompositions for relation TEACH nd1: {student, instructor} and {student, course} nd2: {course, instructor } and {course, student} nd3: {instructor, course } and {instructor, student} ü Slide 14-66

67 4.3 Interpreting the General Definition of Third Normal Form (2) n ALTERNATIVE DEFINITION of 3NF: We can restate the definition as: A relation schema R is in third normal form (3NF) if, whenever a nontrivial FD XàA holds in R, either a) X is a superkey of R or b) A is a prime attribute of R The condition (b) takes care of the dependencies that slip through (are allowable to) 3NF but are caught by BCNF which we discuss next. Slide 14-67

68 1. BOYCE-CODD NORMAL FORM 68

69 What you will learn about in this section 1. Boyce-Codd Normal Form 2. The BCNF Decomposition Algorithm 69

70 5. BCNF (Boyce-Codd Normal Form) Definition of 3NF: A relation schema R is in 3NF if, whenever a nontrivial FD XàA holds in R, either a) X is a superkey of R or b) A is a prime attribute of R A relation schema R is in Boyce-Codd Normal Form (BCNF) if whenever an FD X A holds in R, then a) X is a superkey of R b) There is no b Each normal form is strictly stronger than the previous one Every 2NF relation is in 1NF Every 3NF relation is in 2NF Every BCNF relation is in 3NF Slide 14-70

71 Boyce-Codd normal form Figure Boyce-Codd normal form. (a) BCNF normalization of LOTS1A with the functional dependency FD2 being lost in the decomposition. (b) A schematic relation with FDs; it is in 3NF, but not in BCNF due to the f.d. C B. Slide 14-71

72 A relation TEACH that is in 3NF but not in BCNF Two FDs exist in the relation TEACH: X à A {student, course} à instructor instructor à course {student, course} is a candidate key for this relation So this relation is in 3NF but not in BCNF A relation NOT in BCNF should be decomposed Slide 14-72

73 Achieving the BCNF by Decomposition Three possible decompositions for relation TEACH D1: {student, instructor} and {student, course} D2: {course, instructor } and {course, student} ü D3: {instructor, course } and {instructor, student} Slide 14-73

74 Boyce-Codd Normal Form BCNF is a simple condition for removing anomalies from relations: A relation R is in BCNF if: if {X 1,..., X n } à A is a non-trivial FD in R then {X 1,..., X n } is a superkey for R In other words: there are no bad FDs 74

75 Example Name SSN PhoneNumber City Fred Seattle Fred Seattle Joe Westfield Joe Westfield {SSN} à {Name,City} This FD is bad because it is not a superkey Not in BCNF What is the key? {SSN, PhoneNumber} 75

76 Example Name SSN City Fred Seattle Joe Madison SSN PhoneNumber Now in BCNF! {SSN} à {Name,City} This FD is now good because it is the key Let s check anomalies: Redundancy? Update? Delete? 76

77 BCNF Decomposition BCNFDecomp(R): If Xà A causes BCNF violation: Decompose R into R1= XA R2 = R A (Note: X is present in both R1 and R2) Return BCNFDecomp(R1), BCNFDecomp(R2)

78 Example BCNFDecomp(R): If Xà A causes BCNF violation: Decompose R into R1= XA R2 = R A (Note: X is present in both R1 and R2) R(A,B,C,D,E) {A} à {B,C} {C} à {D} Return BCNFDecomp(R1), BCNFDecomp(R2)

79 Example R(A,B,C,D,E) R(A,B,C,D,E) {A} + = {A,B,C,D} {A,B,C,D,E} {A} à {B,C} {C} à {D} R 1 (A,B,C,D) {C} + = {C,D} {A,B,C,D} R 11 (C,D) R 12 (A,B,C) R 2 (A,E) 79

80 2. DECOMPOSITIONS 80

81 Recap: Decompose to remove redundancies 1. We saw that redundancies in the data ( bad FDs ) can lead to data anomalies 2. We developed mechanisms to detect and remove redundancies by decomposing tables into BCNF 1. BCNF decomposition is standard practice- very powerful & widely used! 3. However, sometimes decompositions can lead to more subtle unwanted effects When does this happen? 81

82 Decompositions in General R(A 1,...,A n,b 1,...,B m,c 1,...,C p ) R 1 (A 1,...,A n,b 1,...,B m ) R 2 (A 1,...,A n,c 1,...,C p ) R 1 = the projection of R on A 1,..., A n, B 1,..., B m R 2 = the projection of R on A 1,..., A n, C 1,..., C p 82

83 Theory of Decomposition Name Price Category Gizmo Gadget OneClick Camera Gizmo Camera Sometimes a decomposition is correct I.e. it is a Lossless decomposition Name Price Name Category Gizmo Gizmo Gadget OneClick OneClick Camera Gizmo Gizmo Camera 83

84 Lossy Decomposition Name Price Category Gizmo Gadget OneClick Camera Gizmo Camera However sometimes it isn t What s wrong here? Name Gizmo OneClick Gizmo Category Gadget Camera Camera Price Category Gadget Camera Camera 84

85 Lossless Decompositions R(A 1,...,A n,b 1,...,B m,c 1,...,C p ) R 1 (A 1,...,A n,b 1,...,B m ) R 2 (A 1,...,A n,c 1,...,C p ) A decomposition R to (R1, R2) is lossless if R = R1 Join R2

86 Lossless Decompositions R(A 1,...,A n,b 1,...,B m,c 1,...,C p ) R 1 (A 1,...,A n,b 1,...,B m ) R 2 (A 1,...,A n,c 1,...,C p ) If {A 1,..., A n } à {B 1,..., B m } Then the decomposition is lossless Note: don t need {A 1,..., A n } à {C 1,..., C p } BCNF decomposition is always lossless. Why? 86

87 A relation TEACH that is in 3NF but not in BCNF Two FDs exist in the relation TEACH: X à A {student, course} à instructor instructor à course {student, course} is a candidate key for this relation So this relation is in 3NF but not in BCNF A relation NOT in BCNF should be decomposed Slide 14-87

88 Achieving the BCNF by Decomposition (2) Three possible decompositions for relation TEACH D1: {student, instructor} and {student, course} D2: {course, instructor } and {course, student} ü D3: {instructor, course } and {instructor, student} Slide 14-88

89 A problem with BCNF Problem: To enforce a FD, must reconstruct original relation on each insert!

90 A Problem with BCNF Unit Company Product {Unit} à {Company} {Company,Product} à {Unit} Unit Company Unit Product We do a BCNF decomposition on a bad FD: {Unit} + = {Unit, Company} {Unit} à {Company} We lose the FD {Company,Product} à {Unit}!! 90

91 So Why is that a Problem? Unit Company Galaga99 UW Bingo UW Unit Galaga99 Bingo Product Databases Databases No problem so far. All local FD s are satisfied. {Unit} à {Company} Unit Company Product Galaga99 UW Databases Bingo UW Databases Let s put all the data back into a single table again: Violates the FD {Company,Product} à {Unit}!! 91

92 The Problem We started with a table R and FDs F We decomposed R into BCNF tables R 1, R 2, with their own FDs F 1, F 2, We insert some tuples into each of the relations which satisfy their local FDs but when reconstruct it violates some FD across tables! Practical Problem: To enforce FD, must reconstruct R on each insert! 92

93 Possible Solutions Various ways to handle so that decompositions are all lossless / no FDs lost For example 3NF- stop short of full BCNF decompositions. Usually a tradeoff between redundancy / data anomalies and FD preservation BCNF still most common- with additional steps to keep track of lost FDs 93

94 RELATIONAL ALGEBRA & CALCULUS

95 1. Selection (σ) Students(sid,sname,gpa) Returns all tuples which satisfy a condition Notation: σ c (R) Examples σ Salary > (Employee) σ name = Smith (Employee) The condition c can be =, <,, >,, <> SQL: SELECT * FROM Students WHERE gpa > 3.5; RA: σ %&' ().+ (Students)

96 Another example: SSN Name Salary John Smith Fred σ Salary > (Employee) SSN Name Salary Smith Fred

97 2. Projection (Π) Students(sid,sname,gpa) Eliminates columns, then removes duplicates Notation: Π A1,,An (R) Example: project socialsecurity number and names: Π SSN, Name (Employee) Output schema: Answer(SSN, Name) SQL: SELECT DISTINCT sname, gpa FROM Students; RA: Π 67'89,%&' (Students)

98 Another example: SSN Name Salary John John John Π Name,Salary (Employee) Name Salary John John

99 Note that RA Operators are Compositional! Students(sid,sname,gpa) SELECT DISTINCT sname, gpa FROM Students WHERE gpa > 3.5; How do we represent this query in RA? Π 67'89,%&' (σ %&'().+ (Students)) σ %&'().+ (Π 67'89,%&' ( Students)) Are these logically equivalent?

100 3. Cross-Product ( ) Students(sid,sname,gpa) People(ssn,pname,address) Each tuple in R1 with each tuple in R2 Notation: R1 R2 Example: Employee Dependents Rare in practice; mainly used to express joins SQL: SELECT * FROM Students, People; RA: Students People

101 Another example: People ssn pname address John 216 Rosse Bob 217 Rosse Students sid sname gpa 001 John Bob 1.3 Students People ssn pname address sid sname gpa John 216 Rosse 001 John Bob 217 Rosse 001 John John 216 Rosse 002 Bob Bob 216 Rosse 002 Bob 1.3

102 Renaming (ρ) Students(sid,sname,gpa) Changes the schema, not the instance A special operator- neither basic nor derived Notation: ρ B1,,Bn (R) SQL: SELECT sid AS studid, sname AS name, gpa AS gradeptavg FROM Students; Note: this is shorthand for the proper form (since names, not order matters!): ρ A1àB1,,AnàBn (R) RA: ρ 6@ABCB,7'89,%D'B9E@FG% (Students) We care about this operator because we are working in a named perspective

103 Another example: Students sid sname gpa 001 John Bob 1.3 ρ (Students) Students studid name gradeptavg 001 John Bob 1.3

104 Natural Join ( ) Note: Textbook notation is * Students(sid,name,gpa) People(ssn,name,address) Notation: R 1 R 2 Joins R 1 and R 2 on equality of all shared attributes If R 1 has attribute set A, and R 2 has attribute set B, and they share attributes A B = C, can also be written: R 1 C R 2 Our first example of a derived RA operator: Meaning: R 1 R 2 = Π A U B (σ C=D (ρ K M (R 1 ) R 2 )) Where: The rename ρ K M renames the shared attributes in one of the relations The selection σ C=D checks equality of the shared attributes The projection Π A U B eliminates the duplicate common attributes SQL: SELECT DISTINCT sid, S.name, gpa, ssn, address FROM Students S, People P WHERE S.name = P.name; RA: Students People

105 Another example: Students S sid S.name gpa 001 John Bob 1.3 People P ssn P.name address John 216 Rosse Bob 217 Rosse Students People sid S.name gpa ssn address 001 John Rosse 002 Bob Rosse

106 Natural Join Given schemas R(A, B, C, D), S(A, C, E), what is the schema of R S? Given R(A, B, C), S(D, E), what is R S? Given R(A, B), S(A, B), what is R S?

107 Example: Converting SFW Query -> RA Students(sid,name,gpa) People(ssn,name,address) SELECT DISTINCT gpa, address FROM Students S, People P WHERE gpa > 3.5 AND S.name = P.name; Π %&','BBD966 (σ %&'().+ (S P)) How do we represent this query in RA?

108 Logical Equivalece of RA Plans Given relations R(A,B) and S(B,C): Here, projection & selection commute: σ FN+ (Π F (R)) = Π F (σ FN+ (R)) What about here? σ FN+ (Π Q (R))? = Π Q (σ FN+ (R))

109 Relational Algebra (RA) Five basic operators: 1. Selection: σ 2. Projection: Π 3. Cartesian Product: 4. Union: 5. Difference: - Derived or auxiliary operators: Intersection Joins (natural,equi-join, theta join, semi-join) Renaming: ρ Division We ll look at these And also at some of these derived operators

110 1. Union ( ) and 2. Difference ( ) R1 R2 Example: ActiveEmployees RetiredEmployees R 1 R 2 R1 R2 Example: AllEmployees -- RetiredEmployees R 1 R 2

111 What about Intersection ( )? It is a derived operator R1 R2 = R1 (R1 R2) Also expressed as a join! Example UnionizedEmployees RetiredEmployees R 1 R 2

112 Theta Join ( θ ) Students(sid,sname,gpa) People(ssn,pname,address) A join that involves a predicate R1 θ R2 = σ θ (R1 R2) Here θ can be any condition SQL: SELECT * FROM Students,People WHERE θ; Note that natural join is a theta join + a projection. RA: Students S People

113 Equi-join ( A=B ) A theta join where θ is an equality R1 A=B R2 = σ A=B (R1 R2) Example: Students(sid,sname,gpa) People(ssn,pname,address) SQL: Employee SSN=SSN Dependents SELECT * FROM Students S, People P WHERE sname = pname; Most common join in practice! RA: S 67'89N&7'89 P

114 Semijoin ( ) R S = Π A1,,An (R S) Where A 1,, A n are the attributes in R Example: Students(sid,sname,gpa) People(ssn,pname,address) SQL: Employee Dependents SELECT DISTINCT sid,sname,gpa FROM Students,People WHERE sname = pname; RA: Students People

115 Divison ( ) T(Y) = R(Y,X) S(X) Y is the set of attributes of R that are not attributes of S. For a tuple t to appear in the result T of the Division, the values in t must appear in R in combination with every tuple in S.

116 Example R(Y,X) S(X) = T(Y) SELECT PS1.pilot_name FROM PilotSkills AS PS1, Hangar AS H1 WHERE PS1.plane_name = H1.plane_name GROUP BY PS1.pilot_name HAVING COUNT(PS1.plane_name) = (SELECT COUNT(plane_name) FROM Hangar);

117 Complete Set of Relational Operations The set of operations including Select σ, Project π Union Difference Rename ρ, and Cartesian Product X is called a complete set because any other relational algebra expression can be expressed by a combination of these five operations. For example: R S = (R S ) ((R S) (S R)) R <join condition> S = σ <join condition> (R X S)

118 Table 8.1 Operations of Relational Algebra continued on next slide

119 Table 8.1 Operations of Relational Algebra (continued)

120 Examples of Queries in Relational Algebra : Procedural Form Q1: Retrieve the name and Address of all Employees who work for the Research department. Research_dept σ Dname= Research (Department) Research_emps (RESEARCH_DEP Result π Fname, Lname, Address (Research_emps) DNumber= Dno Employee) As a single expression, this query becomes: π Fname, Lname, Address (σ Dname= Research (Department) Dnumber=Dno Employee) Slide 8-120

121 Examples of Queries in Relational Algebra : Procedural Form Q6: Retrieve the names of Employees who have no dependents. ALL_EMPS π SSN(Employee) EMPS_WITH_DEPS(SSN) π Essn(DEPENDENT) EMPS_WITHOUT_DEPS (ALL_EMPS - EMPS_WITH_DEPS) RESULT π Lname, Fname (EMPS_WITHOUT_DEPS * Employee) As a single expression, this query becomes: π Lname, Fname ((π Ssn (Employee) ρ Ssn (π Essn (Dependent))) Employee) Slide 8-121

122 Division T(Y) = R(Y,X) S(X) The complete division expression: R S = π W R π W π W R S R Ignoring the projections, there are just three steps: Compute all possible attribute pairings Remove the existing pairings Remove the non answers from the possible answers

123 Division Example Y R(Y,X) S(X) π W R S π W R S R X X Y X Y X y1 x1 x1 y1 x1 y2 x2 y1 x2 x2 y1 x2 y2 x1 y2 x1 y3 x1 y2 x2 y3 x2 y3 x1 y3 x3 y3 x2 π W π W R S R Y y2 R S = π W R π W π W R S R Y y1 y3

124 What is First Order Logic (Informally)

125 Relational Algebra vs Relational Calculus In a calculus expression, there is no order of operations to specify how to retrieve the query result. A calculus expression specifies only what information the result should contain. A calculus expression specifies what is to be retrieved rather than how to retrieve it.

126 Relational Algebra vs Relational Calculus (cont.) Relational calculus is considered to be a nonprocedural or declarative language. This differs from relational algebra In relational algebra, we need to write a sequence of operations to specify a retrieval request hence relational algebra can be considered as a procedural way of stating a query. relational calculus can be considered as a declarative way of stating a query.

127 Tuple Relational Calculus The tuple relational calculus is based on specifying a number of tuple variables. Each tuple variable usually ranges over a particular database relation, meaning that the variable may take as its value any individual tuple from that relation. A simple tuple relational calculus query is of the form {t COND(t)} where t is a tuple variable and COND (t) is a conditional expression or formula involving t. The result of such a query is the set of all tuples t that satisfy COND (t). Slide 8-127

128 Formula and Atoms A formula is made up of atoms An atom can be one of the following: R(t) where R is a relation and t is a tuple variable t i.a op t j.b op can be: =, <,, >,, t i.a op c c is a constant.

129 Formula A formula (boolean condition) is made up of one or more atoms. Atoms are connected via AND, OR, and NOT Rules: Rule 1: Every atom is a formula Rule 2: If F 1 and F 2 are formulas, then so are: (F 1 AND F 2 ), (F 1 OR F 2 ), NOT(F 1 ), NOT(F 2 )

130 Tuple Relational Calculus (continued) Example: Find the first and last names of all Employees whose salary is above $50,000 Tuple calculus expression: {t.fname, t.lname Employee(t) AND t.salary > 50000} π Fname, Lname σ SALARY >50000 Slide 8-130

131 The Existential and Universal Quantifiers Two special symbols called quantifiers can appear in formulas; these are the universal quantifier ( ) and the existential quantifier ( ). Informally, a tuple variable t is bound if it is quantified meaning that it appears in an ( t) or ( t) clause otherwise, it is free.

132 Rule 3 and 4 If F is a formula, then so are ( t)(f) and ( t)(f) The formula ( t)(f) is true if the formula F evaluates to true for some (at least one) tuple assigned to free occurrences of t in F otherwise ( t)(f) is false. The formula ( t)(f) is true if the formula F evaluates to true for every tuple assigned to free occurrences of t in F otherwise ( t)(f) is false.

133 The Existential and Universal Quantifiers (continued) is called the universal or for all quantifier is called the existential or there exists quantifier Slide 8-133

134 Example Query Using Existential Quantifier Example: List the name of each employee who works on some project controlled by department number 5. Tuple calculus expression: {e.lame, e.fname Employee(e) AND(( x)( w) (Project (x) AND Works_on(w) AND x.dnum = 5 AND w.essn = e.ssn AND x.pnumber = w.pno))} Slide 8-134

135 Example Query Using Universal Quantifier Example: List the name of each employee who works on all project controlled by department number 5. Tuple calculus expression: { e.lame, e.fname Employee(e) AND ( ( x) ( NOT (Project (x)) OR NOT (x.dnum = 5) OR (( w) (Works_on(w) AND w.essn = e.ssn AND x.pnumber = w.pno)) ) ) }

136 Example Query Using Universal Quantifier Example: List the name of each employee who works on all project controlled by department number 5. Tuple calculus expression: { e.lame, e.fname Employee(e) AND F } where F = ( ( x) ( NOT (Project (x)) OR NOT (x.dnum = 5) OR (( w) (Works_on(w) AND w.essn = e.ssn AND x.pnumber = w.pno)) ) )

137 Example Query Using Universal Quantifier Example: List the name of each employee who works on all project controlled by department number 5. Tuple calculus expression: { e.lame, e.fname Employee(e) AND F } where F = ( ( x) ( NOT (Project (x)) OR F1)) Where F1 = NOT (x.dnum = 5) OR (( w) (Works_on(w) AND w.essn = e.ssn AND x.pnumber = w.pno))

138 Example Query Using Universal Quantifier Example: List the name of each employee who works on all project controlled by department number 5. Tuple calculus expression: { e.lame, e.fname Employee(e) AND F } where F = ( ( x) ( NOT (Project (x)) OR F1)) Where F1 = NOT (x.dnum = 5) OR (( w) (Works_on(w) AND w.essn = e.ssn AND x.pnumber = w.pno))

139 A à B A B = NOT A OR B A B A à B NOT A OR B XY Z = NOT X OR NOT Y OR Z

140 Example Query Using Universal Quantifier Example: List the name of each employee who works on all project controlled by department number 5. Tuple calculus expression: { e.lame, e.fname Employee(e) AND F } where F = ( ( x) ((Project (x) AND x.dnum = 5) (( w) (Works_on(w) AND w.essn = e.ssn AND x.pnumber = w.pno))

141 The Domain Relational Calculus Another variation of relational calculus is called the domain relational calculus Domain calculus differs from tuple calculus in the type of variables used in formulas: Rather than having variables range over tuples, the variables range over single values from domains of attributes. Slide 8-141

142 Acknowledgement Some of the slides in this presentation are taken from the slides provided by the authors. Many of these slides are taken from cs145 course offered by Stanford University. Thanks to YouTube, especially to Dr. Daniel Soper for his useful videos.