Basic SQL

Implementation Schemes: Once we have a set of relation schemes, we can translate them into implementation schemes. We use to express implementation schemes a Data-Definition Language (DDL). The DDL in next slide is written in SQL, a standardized commercial database language for specifying updating, and querying a database.

CREATE TABLE Library ( 1 L_Code VCHAR(10) NOT NULL UNIQUE 2 L_City VCHAR(10) NOT NULL 3 L_Size INTEGER NOT NULL 4 B_Code INTEGER 5 6 PRIMARY KEY (L_Code), 7 FOREIGN KEY (B_Code ) ); CREATE TABLE Library ( 1 L_Code VCHAR(10) NOT NULL UNIQUE 2 L_City VCHAR(10) NOT NULL 3 L_Size INTEGER NOT NULL 4 B_Code INTEGER 5 6 PRIMARY KEY (L_Code), 7 FOREIGN KEY (B_Code ) );

What is update operation: Update operations insert tuples into relations, delete tuples form relations,and modify tuples in relations.

What is Retrieval operation: Retrieval operations obtain tuples from relations that satisfy certain conditions and combine these tuples in various ways to produce result relations.

Basic Structure w The SELECT clause is used to list the attributes desired in the result of a query. w The FROM clause lists the relations (tables) to be scanned in the evaluation of the expression. w The WHERE clause consists of a predicate involving attributes of the relations that appear in the FROM clause.

Form w A typical SQL query has the form: SELECT A 1, A 2,..., A n FROM r 1, r 2,..., r 3 WHERE P w Each A 1 represents an attribute and each r 1 a relation. P is a predicate.

Form w If the WHERE clause is omitted, the predicate P is true. The list of attributes may be replaced with a star (*) to select all attributes of all relations appearing in the FROM clause.

Some Examples of SQL Queries w Find the names of all the branches in the deposit relation (relation): SELECT branch-name FROM deposit w Now, we want no duplicates in the list so we add the DISTINCT clause: SELECT DISTINCT branch-name FROM deposit

More Examples w If we want to make sure duplicates are not removed, we can add the ALL clause. SELECT ALL branch-name FROM deposit

Constraints w If we want to find all the customers in the deposit relation who bank at the branch "Perryridge." SELECT DISTINCT customer-name FROM deposit WHERE branch-name = "Perryridge"

Constraints - continued w Or we can pull the customers in the borrow relation who bank at the branch "Perryridge." SELECT DISTINCT customer-name FROM borrow WHERE branch-name = "Perryridge"

Constraints - continued w We can use operators to find balances between $90,000 and $100,000. SELECT customer-name FROM deposit WHERE balance BETWEEN AND w This is the same as: SELECT customer-name FROM deposit WHERE balance  AND balance  90000

Operators w Other operators such as, +, /, *, = etc work the same as does the OR constraint.

Substrings w As part of the WHERE clause we can do substrings. For example, we can find the customers who live on Main Street, even though their address only includes Main as part of the address. SELECT customer-name FROM customer WHERE street LIKE "%Main%"

Joining Relations w We can find the name and city of all customers from the CUSTOMER relation who have deposits at the Perryridge branch (from the DEPOSIT relation) w To do this, you can specify the entire relation name or make a pseudonym for it with a letter: SELECT DISTINCT customer-name, customer-city FROM deposit, customer WHERE deposit.customer-name = customer.customer-name

Joining w This is the same as: SELECT DISTINCT customer-name, customer-city FROM deposit D, customer C WHERE D.customer-name = C.customer-name

Other Functions w AVG = Average, MIN = Minimum, MAX = Maximum, SUM = Total, COUNT = Count w Order by = sort order for result w Group by = places the result in groups

Insert and Delete w Adds and deletions to relations can be made with the INSERT and DELETE clauses. For example: INSERT INTO deposit VALUES ("Perryridge", 9732, "Smith", 1200) w This will put the values into the relation in order, if you wish be more specific: INSERT INTO deposit (branch-name, account-number, customer-name, balance) VALUES ("Perryridge", 9732, "Smith", 1200)

Creating a Table CREATE TABLE r (A 1, D 1, A 2, D 2,... A n, D n ) w Each A is the name of an attribue in the relation r and D is the data type. w The DROP clause eliminates a table (relation). w The DROP clause differs from the DELETE clause in that DELETE only eliminates tuples in r leaving the relation itself, DROP eliminates the relation and all information relating to it.

Data Definition The SQL Data Definition Language (DDL) allows us to create and destroy database objects such as schemas, domains, tables, views, and indexes. The ISO standard also allows the creation of assertions, character sets, collations and translations.

The main SQL data definition language statements are: w CREATE SCHEMA w DROP SCHEMA w CREATE DOMAIN w ALTER DOMAIN w DROP DOMAIN

w CREATE TABLE w ALTER TABLE w DROP TABLE w CREATE VIEW w DROP VIEW While CREATE INDEX and DROP INDEX are provided by DBMS

Joins: Combining Data from Multiple Tables w Inner Joins w Equi-Joins and Natural Joins w Self Joins w Outer Joins (Left, Right and Full), Nulls w Union Operators w Merge Joins w Hash Joins

Inner Joins w Inner join is the default join type. Therefore, you are not required to specify it. But, I recommend that you do for clarity. w The SELECT clause says which columns to output, the FROM clause lists the tables, and the WHERE clause tells SQL Server how to join the tables. SELECT pub_name, title FROM titles INNER JOIN publishers ON titles.pub_id = publishers.pub_id

Equi-Joins w An equijoin is an INNER JOIN in which you ask for the join columns from both tables. This join will return redundant data. The whole premise of this join is that the data in the join column is the same in both tables. An equijoin would look like this: SELECT pub_name, publishers.pub_id, titles.pub_id, title FROM publishers INNER JOIN titles ON publishers.pub_id = titles.pub_id

Natural Joins w Natural Join is the same as equi-join except you show the join criteria field only once. Since we want to see the publishers info, here is the natural join query. SELECT pub_name, publishers.pub_id, title FROM titles INNER JOIN publishers ON titles.pub_id = publishers.pub_id

Self-Joins w Useful join to identify multiple names for same address. SELECT au1.au_fname, au1.au_lname, au2.au_fname, au2.au_lname FROM authors au1, authors au2 WHERE au1.state = 'UT' AND au1.au_lname = au2.au_lname AND au1.au_id < au2.au_id w Notice the table name aliases au1 and au2 for same table, named authors.

Left Outer Joins (*=) w Left Outer Join means, "Give me all the data from the table to the left of the Join (in this case, titles) and the matching data from the table to the right of the Join (in this case, sales)." So you see all the titles, including those with no sales. Where sales data exists for a title, it is output. Where no sales data exists, you see Nulls. SELECT substring (title,1,40) AS Book, stor_id, ord_num, qty, ord_date FROM titles, sales WHERE titles.title_id *= sales.title_id

Left verses Right Joins w In the Left Outer Join example, no sales data could appear if no entries were in the titles table. w Thus, if you just change Left to Right and run the query, you see what is really an Inner Join.

Right Outer Joins (=*) w But if you flip the tables SELECT substring (title,1,40) AS Book, stor_id, ord_num, qty, ord_date FROM sales RIGHT OUTER JOIN titles ON sales.title_id = titles.title_id then you have a RIGHT OUTER JOIN. In other words, titles Left Join sales produces the same results as sales Right Join titles. In fact, internally, SQL Server doesn't process Right Joins. It just flips them around and handles them as Left Joins. w Right Outer Join returns all the rows from the table to the right of the join and only the matching rows from the table on the left.

Full Outer Joins (*=*) w The Full Outer Join combines the left and right outer joins; and it gives you all the data from both table A and table B, matching rows when appropriate and filling in NULLS when there is no match. Select v.VendorName, i.InventoryDscr FROM tblInventory i FULL OUTER JOIN tblVendor v ON i.VendorId = v. VendorID Order by V.VendorName

Outer Joins with Nulls  When results show nulls, does that indicate that the table really doesn ’ t have that data or does it just not show because of the join?

Union Operators w The UNION operator combines two tables in a single result set that contains all rows appearing in either or both tables. w UNION processing is different depending on whether you use the ALL option. w If you specify ALL, the optimizer displays all resulting rows, including duplicates. w If you don't specify ALL, the optimizer processes UNION the same way it processes the DISTINCT clause, removing all duplicate rows.

Union Operators.. example SELECT Name, City, 'Supplier' AS Source FROM Suppliers WHERE Country = 'Canada' UNION SELECT Name, City, 'Customer' FROM Customers WHERE Country = 'Canada' ORDER BY City, Source;

Merge Joins w The SQL Server query optimizer uses a variety of algorithms and new join techniques to find the best available plan for your queries. w If the optimizer decides that a merge join is optimal, the query execution scans two sorted inputs and merges them. w For a merge join, the query processor sorts both inputs on the join column; if the two inputs to the join are already sorted on the join column (for example, if each has a clustered index on the join column), merge join is a logical choice. w SQL Server scans both the Orders table and the OrderDetails table. For each row in Orders, the matching rows in OrderDetails are merged.

Merge Joins.. logic w If a one-to-many relationship exists between the inputs, SQL Server follows a series of steps for an inner join executed with a merge join strategy. w First, it gets a row from each input, then compares the join columns of the rows. w If the join columns match, SQL Server returns the requested columns from each row. w If the columns don't match, SQL Server discards the row with the lower value and gets the next row from that input. w SQL Server repeats these steps until it has processed all rows in both inputs, scanning both inputs only once.

Merge Joins.. An example w To demonstrate a situation in which the optimizer will choose merge join, we inserted 10,000 rows into the Orders table. For each Order, we inserted five products into the OrderDetails table, resulting in 50,000 rows. Both Orders and OrderDetails have clustered indexes on the OrderID column. Then we executed the following query against the tables: SELECT O.OrderID, O.OrderDate, OD.ProductID, OD.Quantity FROM Orders O INNER JOIN OrderDetails OD ON O.OrderID = OD.OrderID

Hash Joins w The main reason why the SQL Server optimizer chooses the hash join algorithm is a lack of adequate indexes on the join columns. w If the optimizer chooses a hash join, the execution plan involves building a hash table, which is like building a special index on the fly. w The hash join strategy has two phases: build and probe.

Hash Joins.. w During the build phase, the query processor builds a hash table by scanning each value in the build input (usually the smaller table) and applying the hashing algorithm to the key. The hash table consists of linked lists called hash buckets. The hash function applied to each hash key in the build input determines the relevant hash bucket. w During the probe phase, the query processor scans each row from the probe input (the second table) and computes the same hash value on the hash key to find any matches in the corresponding hash bucket.

Hash Joins.. demonstration w To demonstrate a situation in which the optimizer usually chooses a hash join, drop the constraints and both clustered indexes from the Orders and OrderDetails tables. Now execute the same query we ran in the merge join example: SELECT O.OrderID, O.OrderDate, OD.ProductID, OD.Quantity FROM Orders O INNER JOIN OrderDetails OD ON O.OrderID = OD.OrderID

Hash Joins.. Demo explained.. w The Orders table is the best candidate for the build input because it's considerably smaller. The linked lists start with the function's possible results; in this case, there are only five. Linked to each bucket are records containing all the values the query will return from the build input table that correspond to the bucket. Applying the hash function to the join column of each build input record determines the correspondence. OrderID and OrderDate are the only columns you need from the build input (the Orders table), so these values are the only ones that stay in each record of the hash table.

Hash Joins.. Demo explained …  SQL Server performs a table scan on the smaller table, Orders, which is the build input. Then it builds a hash table with the values that result from applying the hash function to each scanned row. SQL Server also performs a table scan on the probe — the OrderDetails table — and looks for the matching values in the hash table by applying to each scanned row the same formula that it used to build the hash table.