Joining Relations in SQL Objectives of the Lecture : To consider the Natural & Generalised Joins using the SQL1 standard; To consider the Natural & Generalised Joins using the SQL2 standard.

Joins in SQL l Expressing joins in SQL has been particularly affected by two particular SQL standards : l SQL1 Standard SQL, introduced in this has no specific support for joins; l SQL2 Standard SQL introduced in this has special support for joins. The SQL3 Standard SQL introduced in 1999 maintains this support. l It is important to know how to use both variants of SQL. l As the SQL1 standard is a subset of SQL2, it is always possible to write an SQL1 style join in SQL2. l Oracle SQL 9i supports SQL2 standard joins, but earlier versions of Oracle only meet the SQL1 standard.

SQL1 : Generalised Join Syntax The Generalised Join of relations R and S has the syntax : Select* FromR, S Wheretheta-join condition ; Principles : l Put Select * to get all the attributes in the result. l Put both relation names in the From phrase. l Put the complete theta join condition in the Where phrase. The SQL statement also retrieves the result from the DB. SQL fulfills all the requirements of the Generalised Join operation.

SQL1 : Natural Join Syntax The Natural Join of relations R and S has the syntax : Selectthe result’s column names From R, S Where equi-join condition ; Principles : l Put Select COLUMN_NAMES to get all the columns in the result. l Put both relation names in the From phrase. l Put the complete equi join condition in the Where phrase. The SQL statement also retrieves the result from the DB. SQL fulfills all the requirements of the Natural Join operation. Prefixed by TABLE_NAME. Omit duplicate columns. Always prefixed with TABLE_NAME.

Examples : SQL1 Generalised Joins SQL1 equivalents of previous examples : l Select* FromR, S WhereB < C ; l Select* FromR, S WhereA > E And B <> D ; As the operands have no column names in common, it is safe to use “*” in the Select phrase and omit table name prefixes in the Where phrase.

Example : SQL1 Natural Join SQL equivalent of previous example : l Select PNo, Qty, SHIP.SNo, SName, From SHIP, SUPP Where SHIP.SNo = SUPP.SNo ; Or l Select PNo, Qty, SUPP.SNo, SName, From SHIP, SUPP Where SHIP.SNo = SUPP.SNo ; Doesn’t matter from which table the “SNo” column comes. The order in which the tables appear in the From phrase, and which “SNo” column appears on which side of the “=”, don’t matter.

Combining Algebra Operators l Typically we want to join together 2 relations holding relevant data, and then prune the result down with a projection and restriction to yield just the required data : R Join[ Att ] S Restrict[ condition ] Project[ AttNames ] l In SQL, put the Projected attributes in the Select phrase, the Joined relations in the From phrase, and And the Join and Restrict conditions together in the Where phrase, as follows : Select Distinct AttNames From R, S Where ( R.Att = S.Att ) And (condition ) ; l SQL’s built-in sequence of operations will execute a Cartesian Product of R and S, then a Restrict on the result using the entire Where condition, & finally a Project on that result using the Select attributes. Restrict condition Join condition

Examples of Combining Operators Example : Get the supplier’s name who supplies parts in quantities of 10. SHIP Join[ SNo ] SUPP Restrict[ Qty = 10 ] Project[ SName ] SelectDistinct Sname FromSHIP, SUPP WhereSHIP.SNo = SUPP.SNo And Qty = 10 ; Example : Get the names of employees who own a Corsa 1.3. CAR Gen[ Owner = ENo ] EMPLOYEE Restrict[ Type = ‘Corsa 1.3’ ] Project[ EName ] SelectDistinct EName FromCAR, EMPLOYEE WhereOwner = ENo And Type = ‘Corsa 1.3’ ;

Designing SQL Queries l Decide which DB relations contain data that will be required in the answer to the query, and join all those relations together with the appropriate Natural/Generalised Join operation(s). l Remove any unrequired tuples with Restrict operation(s). In principle only one Restrict operation is required, but it may be more convenient to use several. l Remove any unrequired attributes with a Project operation; only one Project operation will be necessary. l Complete the appropriate SQL phrases with the relevant information from the algebra operations : Select …… From.…… Where ( ……… ) And ( ……… ) ; Restrict condition Join condition Project attributes Tables to be joined

SQL : Cartesian Product l SQL1 executes a Cartesian Product operation given the following syntax : Select* FromR, S ; l Hence the absence of a join condition in the Where phrase causes SQL to execute a Cartesian Product : l If a Cartesian Product is actually needed in a query instead of a Natural or Generalised Join, then just omit the Join condition from the Where phrase. l If a Join condition is accidentally omitted from the Where phrase by error, then the result will be unexpectedly (very) large due to a Cartesian Product operation ! l SQL2 actually has a Cartesian Product operator, with syntax : Select* FromR Cross Join S ;

SQL2 : Generalised Join Syntax The Generalised Join of relations R and S has the syntax : Select* FromR Join S On ( theta-join condition ) ; Principles : l Put Select * to get all the attributes in the result. l Put R Join S On ( theta-join condition ) in the From phrase, where R and S are the operands and ( theta-join condition ) is the complete generalised join condition. l No Where phrase is required. The SQL statement also retrieves the result from the DB. SQL fulfills all the Generalised Join requirements.

Examples : SQL2 Generalised Joins SQL2 equivalents of previous examples : l Select* FromR Join S On ( B < C ) ; l Select* FromR Join S On ( A > E And B <> D ) ; As the operands have no column names in common, it is safe to use “*” in the Select phrase and omit table name prefixes in the Where phrase.

SQL2 : Natural Join Syntax There are 2 ways of writing a Natural Join of operands R and S in SQL2 : l Select* FromR Natural Join S ; l Select* FromR Join S Using ( AttributeName(s) ) ; Principles : l These are the same as for Generalised Join, except that a different required expression is put in the From phrase. The SQL statement also retrieves the result from the DB. Both variants fulfill all the Natural Join requirements. The attributes on which the ‘=‘ comparison(s) is/are made.

Examples : SQL2 Natural Joins SQL2 equivalents of a previous example : l Select * From SHIP Natural Join SUPP ; l Select * From SHIP Join SUPP Using ( SNo ) ;

SQL2 : Join Problem (1) l Select * From CAR Natural Join EMPLOYEE ; l Select * From CAR Join EMPLOYEE Using ( Owner, ENo ) ; Neither will work ! Columns “Owner “ and “ENo” don’t appear in both tables. So use an SQL Generalised Join to express the required join, & remove the duplicate data in the Select phrase : l Select RegNo, Type, Owner, EName, M-S, Sal From CAR Join EMPLOYEE On ( Owner = ENo ) ; Could have omitted “Owner” instead of “ENo” in Select phrase.

SQL2 : Join Problem (2) l Consider the join expressed as : R Join S Using ( J1 ) l Suppose there are two attributes, named J1 and J2, both of which appear in R and in S, and are type compatible. l The join will be carried out just using J1, as specified. ==> the result will have two attributes called J2 in it. l There are 2 considerations concerning the result : l If a real join requires both J1 and J2, then SQL will have generated the wrong result (unless by chance the data in the tables avoids this). l If the problem was unhelpful column names, so that the correct result was generated, the two columns can be distinguished with their table name prefix in the Select phrase.

Combining Algebra Operators Follow the same procedure is as before, but using SQL2 syntax. Example : SHIP Join[ SNo ] SUPP Restrict[ Qty = 10 ] Project[ SName ] Select Distinct Sname From SHIP Natural Join SUPP Where Qty = 10 ; Example : CAR Gen[ Owner = ENo ] EMPLOYEE Restrict[ Type = ‘Corsa 1.3’ ] Project[ EName ] Select Distinct EName From CAR Join EMPLOYEE On (Owner = ENo) Where Type = ‘Corsa 1.3’ ; Or SHIP Join SUPP Using(SNo) becomes