LEARNING SQL english

Naveen Ashish Calit2 & ICS UC Irvine LEARNING SQL SQL historical Perspective  Dr. Edgar Codd (IBM)  “A Relational Model of Data for Large Shared Data Banks"  CACM June 1970  Standardized  1986 by ANSI SQL1  Revised in 1992 SQL2.  Approx 580 page document describing syntax and semantics  1999: SQL3  2003: 2003 SQL3  Players  IBM, Relational Software (Oracle), ….  Every vendor has a slightly different version of SQL  Simple and declarative Portability  Many different implementations  Need not completely conform to standard  Own specialized versions  PL/SQL, SQL PL, Transact-SQL, …  Portability (of application) in one SQL implementation to another is usually messy  Standard implementation left to vendor  Not break backward compatibility for user base  “Vendor Lock-in” SQL in Different Roles  Data Definition language:  allows users to describe the relations and constraints.  Constraint specification language:  commands to specify constraints ensured by DBMS  Query language:  relationally complete, supports aggregation and grouping  declarative you specify what you want and not how to retrieve, easy to learn and program  Updates in SQL:  allows users to insert, delete and modify tables  View definition language:  commands to define rules  updates through views generally not supported SQL in Different Roles  Embedded SQL:  has been embedded in a variety of host languages C, C+ +, PERL, Smalltalk, Java (vendor dependent)  Impedance mismatch: SQL manipulates relations that are sets programming languages do not handle sets as efficiently.  Transaction Control:  commands to specify beginning and end of transactions. SQL as Data Definition Language  Allows users to  specify the relation schemas  domain of each attribute  integrity constraints  set of indices to be maintained on the relation  we will learn what indices are later  security and authorization information for each relation  the physical storage structure for each relation on disk. Domain Types  char(n): fixed length char string  varchar(n): variable length char string  int or integer  smallint  numeric(p,d): fixed-point number of given precision  real, double precision  float(n): floats with a given precision  date: containing year,month, date  time: in hours, minutes and seconds  Null value is part of each domain  Define new domains:  create domain person-name char(20) Schema Definition Create table r ( A1 D1 [not null] [default V1] A2 D2 [not null] [default V2] … An Dn [not null] [default Vn] <integrity constraint 1> <integrity constraint 2> … <integrity constraint k> ) Integrity constraints 1 … k could be:  primary key  candidate key  foreign key  check(predicate) specifies predicate that must be satisfied by each tuple SQL as DDL create table Employee ( name char[15] not null age smallint sex (M,F) default M ss# integer not null spouse_ss# integer dept# integer )  Primary Key (ssno)  Unique(spouse_ss#)  Check (age >=20 and age <=70)  Foreign key (dept#) references Dept(dept#) on delete cascade on update cascade Don’t allow null values Default value is Male • if dept# updated/deleted in Dept table, cascade update/delete to Employee • if null/default instead of cascade, null/default value taken by dangling tuples in Employee SQL as DDL  Attributes in primary key required to be not null  Attributes in candidate key can take null values unless specified otherwise  Unique constraint violated if two tuples have exactly same values for attributes in unique clause provided values are not null  Null also permitted for attributes in foreign key.  Foreign key constraint automatically satisfied if even one attribute in foreign key is null.  Predicate in check clause can be very complex and can include SQL queries inside them  Other DDL Statements:  drop table r  alter table r add A D  alter table r drop A [...]... product = “Brooklyn Bridge” Factoid about SQL: there is no way to delete only a single occurrence of a tuple that appears twice in a relation SQL as a Query Language Basic SQL Query: select A1, A2, …, An from R1 , R2, … , Rm where < sel-cond> ; Equivalent RA expression: Proj[A1, A2, …An] ( select[sel-cond] ( R1 x R2 x … xRm)) Difference between SQL and RA: SQL does not automatically remove duplicates... remove duplicates Example Relations: E(ename, dno, proj#) , D(dno, dname, mgr) keys: E ename D dno, mgr dname, mgr SQL Select ename, dname from E, D where D.dno = E.dno; RA Proj[ename,dname]( select[D.dno=E.dno]( (E x D)) find employees and the department they work for First Unintuitive SQLism SELECT R.A FROM R,S,T WHERE R.A=S.A OR R.A=T.A R, S, T are tables with a single attribute A Looking for R... union T) But what happens if T is empty? Select Clause Projection Select ename, dname from E, D where D.dno = E.dno;    SQL does not automatically eliminate duplicates if Sam works for manufacturing department on 2 projects, (sam, manufacturing) will be returned 2 times in SQL Keyword distinct used to explicitly remove duplicates Select distinct ename, dname from E, D where D.dno = E.dno;  Asterisk... and the sum of their salaries in toy department Could have said count(sal) instead of count(*) What about select count( sal), sum( DISTINCT sal) from E, D where E.dno = D.dno and D.dname = “Toy”; This SQL query will not be correct since it removes duplicates salaries Group By Clause  Group by used to apply aggregate function to a group of sets of tuples Aggregate applied to each group separately ... count(*) from E, D where E.dno = D.dno group by dname having count(*) > 5 list the department name and the number of employees in the department for all departments with more than 5 employees General SQL Query select e1.ename, sum(e2.sal) #4 from E e1, D, E e2 where e1.dno = D.dno AND e2.ename = D.mgr #1 group by e1.ename #2 having count(*) > 1 #3 order by ename; #5 For each employee in two or more... (select sal from E, D where E.dno = D.dno AND D.dname = “Toy”); Who makes more than someone in the Toy department? some =some, some also permitted any is a synonym of some in SQL . ICS UC Irvine LEARNING SQL SQL historical Perspective  Dr. Edgar Codd (IBM)  “A Relational Model of Data for Large Shared Data Banks"  CACM June 1970  Standardized  1986 by ANSI SQL1  Revised. version of SQL  Simple and declarative Portability  Many different implementations  Need not completely conform to standard  Own specialized versions  PL /SQL, SQL PL, Transact -SQL, …  Portability. 1970  Standardized  1986 by ANSI SQL1  Revised in 1992 SQL2 .  Approx 580 page document describing syntax and semantics  1999: SQL3  2003: 2003 SQL3  Players  IBM, Relational Software (Oracle),