CSC 453 Database Systems Lecture Tanu Malik College of CDM DePaul University

Last time SQL Basic SQL on two tables Subqueries Nested subqueries Correlated subqueries

Today Grading SQL Functional Dependencies Review Update, Delete statements Creating Views Temporary Tables Functional Dependencies

SQL

SQL Queries General form of a query: SELECT list of attributes to report FROM list of tables [CROSS JOIN| [LEFT|REIGHT] OUTER JOIN] [WHERE tuple condition] [GROUP BY list of grouping attributes] [HAVING group condition] [ORDER BY list of ordering attributes] ; [UNION|INTERSECT|EXCEPT] Result is an ordered set of ordered tuples

Subqueries The result of one query may be needed by another to compute its result. There are two kinds of subqueries

Nested Subquery Vs Correlation SELECT LastName, FirstName, SID, (SELECT count(*) FROM enrolled WHERE SID = StudentID) AS EnrCrs FROM student; SELECT Student.* FROM Student WHERE started = (SELECT min(started) FROM student WHERE city = ‘Chicago’)

Subquery check Different ways of checking: Within the inner query set Not within the inner query set Against all members of the inner query set Against any one member of the inner query set Does the set exists

Subquery Practice

Update/Delete Statements UPDATE table_name SET column1 = value1, column2 = value2, ... WHERE condition; DELETE FROM table_name WHERE condition; INSERT INTO table2 SELECT * FROM table1 WHERE condition;

SQL Views

Create View base tables (CREATE TABLE) stored in database CREATE OR REPLACE VIEW CSstudents AS SELECT * FROM student WHERE Program = 'COMP-SCI'; FROM CSstudents; base tables (CREATE TABLE) stored in database views (CREATE VIEW) dependent on base tables or other views, may or may not be stored (virtual vs materialized) temporary tables (subquery, etc.) limited lifetime

Reasons for Creating Views CREATE VIEW studentview AS SELECT LastName, FirstName, SID, Career, Program FROM student; Hide information (grant access to relevant info) SELECT name FROM studentgroup WHERE name NOT IN (SELECT groupname FROM CSstudents, memberof WHERE StudentID = SID); Simplify queries (improve readability) not necessarily a good reason to create a view in general, if temporary table is sufficient

Improving Readability CREATE VIEW enrollment(SID, LName, CID, CNR, Dpt) AS SELECT SID, LastName, CID, CourseNr, Department FROM student, enrolled, course WHERE SID = studentID AND CourseID = CID; SELECT count(*) FROM enrollment WHERE CNR = 440 AND Dpt = 'CSC';

Temporary Tables or “on commit preserve rows” create global temporary table gradstudent( LASTNAME VARCHAR2(40), SID NUMBER(5,0), PROGRAM VARCHAR2(10), primary key(sid) ) on commit delete rows; insert into gradstudent select lastname, sid, program from student where career = ‘GRD'; or “on commit preserve rows” lifetime of temporary data is limited to session table exists beyond session on the database corresponding to different information organizations, avoiding the need for data duplication or information consistency problems Physical DB Database Files Conceptual database Employee, Department, Salary, Birth Date Views Employee, Salary, Age

Common Table Expression (CTE) WITH GradStudents AS (SELECT SID, LastName, SSN FROM student WHERE Career = ‘GRD') SELECT * FROM enrolled WHERE StudentID NOT IN (SELECT SID FROM GradStudents); Temporary table, exists only for lifetime of query, cannot be used in other queries can create multiple such tables

CTE Example WITH StudentEnrollment(SID, Quarter, Year, crs_nbr) AS (SELECT StudentID, Quarter, Year, count(CourseID) FROM enrolled GROUP BY StudentID, Quarter, Year), StudentMax(SID, maxcrs) (SELECT SID, max(crs_nbr) FROM StudentEnrollment GROUP BY SID) SELECT * FROM student S, StudentMax SM WHERE S.SID = SM.SID; temporary table can refer to previous temporary table mutual recursion not allowed (in Oracle)

Modifying Views DROP VIEW Csstudents; What about other objects that depend on it (e.g other views)? How is/are the underlying base table(s) affected? INSERT INTO CSstudents(LastName, FirstName, SID) VALUES ('Crackenden', 'Gloria', 123); What do INSERT, DELETE, UPDATE mean for a view?

Updateable Views “An updatable view is one you can use to insert, update, or delete base table rows.” Roughly: FROM contains only a single relation no DISTINCT, aggregation, set, calculated value WHERE clause may not contain a sub-query involving the relation the view is based on Statement can still fail (e.g. if primary key is missing in INSERT or non-null attributes are not included)

Functional Dependencies

ssn name projectID rating hourly_wages hours_worked 123-22-3666 Alice 48 8 10 40 231-31-5368 Bob 22 30 131-24-3650 Charlie 35 5 7 434-26-3751 Don 32 612-67-4134 Ellie hourly_wages attribute is determined by the rating attribute. Integrity Constraint: for a given rating value, there is only one permissible hourly_wages value.

Create Table statement CREATE TABLE EmployeeRec ( ssn number(10) primary key, name varchar2(100), projectid number(2), rating number(1), hourly_wages number(3), hours_worked float, unique (rating,hourly_wages) );

UPDATE EmployeeRec SET hourly_wages = 11 WHERE name = ‘Alice’

Anomalies Update Anomaly: The hourly_wages in the first tuple could be updated without making a similar change in the second tuple. Insertion Anomaly: Cannot insert a tuple for the hourly_wages unless have an employee with that wage. Deletion Anomaly: If we delete all tuples with a given rating value (e.g., we delete the tuples for Charlie and Don) we lose the association between that rating value and its hourly_wage value.

Better way? Decomposition ssn name ProjectID rating hours_worked 123-22-3666 Alice 48 8 40 231-31-5368 Bob 22 30 131-24-3650 Charlie 35 5 434-26-3751 Don 32 612-67-4134 Ellie rating hourly_wages 8 10 5 7

Functional Dependencies Set of attributes Y is functionally dependent on set of attributes X if and only if the values of X uniquely determine the values of Y Also “X determines Y”, “X  Y” X is called the determinant A functional dependency must hold for all possible relation states to be valid

Search notion of a f.d Accessing ‘x’ requires a column name and rowid B C 1 a x 2 b y 3 4 c A BC BC A

Inference Rules Reflexivity: If X includes Y, then X  Y Augmentation: If X  Y, then XZ  YZ Transitivity: If X  Y and Y  Z, then X  Z [Decomposition: If X  YZ, then X  Y and X  Z ] [Union: If X  Y and X  Z, then X  YZ] [Pseudo-transitivity: If X  Y and WY  Z, then WX  Z]

Closures For a set of functional dependencies F, the closure of F (F+) is the set of all functional dependencies that can be derived from F F+ can be constructed from the closures under F of all possible sets of attributes X For F and a set of attributes X, the closure of X under F (X+) is the set of all attributes that can be determined from X

Finding a Closure of X under F To find the closure of X under F: set X+ = X repeat set oldX+ = X+ for each Y  Z in F do if X+ includes Y, then set X+ = X+ U Z until oldX+ = X+

Attribute Closures: Example 1 Given: R = {A, B, C, D, E, H} F = {A → BC, B → CE, A → E, AC → H, D → B} What is the closure of CD (i.e., (CD)+)?

Attribute Closures: Example 1 Given: R = {A, B, C, D, E, H} F = {A → BC, CD → E, CD → H, B → E, D → B} What is the closure of AD (i.e., (AD)+)?

SuperKey=Key For each set X, find the closure of X under F If X+ contains all attributes, then X is a superkey

Candidate Key If X is a superkey, but no subset Y of X is a superkey, then X is a candidate key Why candidate key? Because they are minimal.

SuperKey Vs Candidate Key Example F = {A → BCD, AB → CD, ABC → D,BD → AB,C → AD} F.Ds SuperKey Candidate Key A → BCD AB → CD ABC → D BD → AB C → AD

SuperKey Vs Candidate Key Example F = {A → BCD, AB → CD, ABC → D,BD → AB,C → AD} F.Ds SuperKey Candidate Key Primary Key A → BCD AB → CD ABC → D BD → AB C → AD

Primary Key Choose a candidate key to be the primary key

More closure examples R(ABCDEHI) R(ABCDEG) F = {A → B,BC → DE,AEI → I}. Find (AC)+ R(ABCDEG) F = {AB → C,BC → AD,D → E,CG → B}. Find (AB)+

Example 1: Keys Given: R = {A, B, C, D, E, H} F = {A → BC, CD → E, CD → H, B → E, D → B}

Determining Keys What is (ACD)+? (ACD)+ → R How can you determine if ACD is a super key? It is if (ACD)+ → R How can you determine if ACD is a candidate key? It is if: (ACD)+ → R, but NOT (AC)+ → R, (AD)+ → R, (CD)+ → R

Find Candidate Keys R(ABCDEFGH) F = {AB →C, A → DE, B → F, F → GH} F = {AB →C, BD → EF, AD → G, A → H} R(ABCDE) F = {BC → ACE, D →B} F = {AB → CD, D →A, BC →DE}

More examples R(WXYZ) Z → W Y → XZ WX → Y

Equivalent Set of F.Ds Given a relation R and two set of functional dependencies F and G on R, the equivalence question is if F ⊆ G, G ⊆ F, F = G, or F ̸= G.

Example F={A→B,AB→C,D→AC,D→E} G={A→BC,D→AE}

Algorithm Must bring F and G on the same starting point. How? Compute the closure set of left hand attributes in F, but by using the f.ds in G. Compute the closure set of left hand attributes in G but using the f.ds in F. Compare F’s search power as stated by its f.d set is equivalent to the search power of G.

Minimal Cover F is a minimal cover if F no dependency can be removed from F In other words, F is an irreducible funcitonal dependency set

Finding Minimal Cover Find a minimal cover by eliminating the redundant/extraneous set of attributes in the set F . Given a f.d α → β, 3 kinds of redundancies: the redundancy is on the r.h.s, the redundancy is on l.h.s, or the entire f.d is redundant.

Eliminate redundancy on R.H.S Use decomposition rule to decompose all f.d’s in F. α → βγ to α → β, and α → γ We have only one attribute on r.h.s, either the entire f.d will be redundant or the f.d will not be redundant.

Eliminate entire f.d Eliminate a f.d if you see it exactly repeated again or can be inferred transitively. Given a α → β in F, Find α+ first using F, compute α+ but this time using F − {α → β}. If α+ does not change then surely the f.d is redundant.

Eliminate redundancy on l.h.s Given a f.d such αγ → β, determine if α → γ holds in F′ = F −{αγ → β}. If γ can be searched by just α in F’ without the given f.d, then clearly γ is redundant in the given f.d to search for β.