Chapter 4: Intermediate SQL - Faculty Website Listing · Chapter 4: Intermediate SQL. Database System Concepts - 6th Edition 4.2 ©Silberschatz, Korth and Sudarshan ... QUIZ: How

Database System Concepts, 6th Ed.

©Silberschatz, Korth and Sudarshan

See www.db-book.com for conditions on re-use

Chapter 4: Intermediate SQL

http://www.db-book.com/

©Silberschatz, Korth and Sudarshan4.2Database System Concepts - 6th Edition

4.1 Join Expressions

Let’s first review the joins from ch.3


SELECT *

FROM student, takes

WHERE student.ID = takes.ID;

1

What’s wrong with WHERE?

Why do we need anything beyond it?


SELECT *

FROM student, takes

WHERE student.ID = takes.ID AND

dept_name = 'Comp.Sci.‘;

1

Complicated queries are more readable if the join conditions

are kept separate from the other WHERE conditions.


SELECT *

FROM student NATURAL JOIN takes;

SELECT *

FROM student JOIN takes USING(ID);

2

3


SELECT *

FROM student JOIN takes ON

student.ID = takes.ID;

3’

New syntax

in ch.4!

QUIZ: How can be make the ID to be displayed only once

in the result?


To learn more …

More here about the history and motivations behind the join

options in SQL:

http://www.databasesoup.com/2013/08/fancy-sql-monday-

on-vs-natural-join-vs.html

(linked on our webpage)

http://www.databasesoup.com/2013/08/fancy-sql-monday-on-vs-natural-join-vs.html


QUIZ: Create a table of room numbers associated

with all the section IDs that were ever taught in

those rooms. Use JOIN … ON …


SELECT C.room_no, S.sec_id

FROM section AS S JOIN classroom AS C

ON (C.room_no = S.room_no AND

C.building = S.building);

Create a table of room numbers associated with

all the section IDs that were ever taught in those

rooms.


SELECT C.room_no, S.sec_id

FROM section AS S join classroom AS C

ON(C.room_no >= S.room_no AND

building LIKE 'Haunted %')

… but it’s almost always used with = (or LIKE).

Side note: The ON clause accepts any SQL predicate

(<>, AND, OR, LIKE, BETWEEN, <=, etc.)


Problems when joining tablescourse prerequisite

Write a query that returns all courses and their prerequisites.

What happens with CS-315?

Write a query that returns all courses in prereq and their

information. What happens with CS-437?

Conclusion: In either case, the tuples with unmatched

attributes are missing!


Another reason to use JOIN instead of WHERE

when joining tables:

We are about to extend the concept of a JOIN!


4.1.2 Outer Joins

They are extensions of the join operation that avoid the loss

of information.

After normally computing the join (now called inner join),

they add tuples from one or both tables that do not match

tuples in the other table.

To do so, NULL values are inserted.


Left Outer Join

SELECT *

FROM course NATURAL LEFT OUTER JOIN prereq ;

course prerequisite


Right Outer Joincourse prerequisite

SELECT *

FROM course NATURAL RIGHT OUTER JOIN prereq ;


Full Outer Joincourse prerequisite

SELECT *

FROM course NATURAL FULL OUTER JOIN prereq ;


QUIZ:

Outer

Joins

Write a query to display a list of all students (ID and name),

along with the courses they have taken.

Hint: SELECT student.ID, student.name

FROM student NATURAL JOIN takes

does not work for all cases (Why?)


solution

Write a query to display a list of all students (ID and name),

along with the courses they have taken.

SELECT student.ID, student.name

FROM student NATURAL LEFT OUTER JOIN takes ;


Conclusion on Outer Joins

Left Outer Join preserves tuples only on left relation

Right Outer Joinpreserves tuples only on right relation

Full Outer Join preserves tuples in both relations

Join type – defines how tuples in each relation that do not

match any tuple in the other relation (based on the join

condition) are treated.


Practice exercise 4.2

Rewrite

SELECT *


without using the OUTER JOIN clause.

Hint: An outer join is an inner join with some extra tuples

added → use UNION.


Rewrite

SELECT *


without using the OUTER JOIN clause.

Practice Exercise 4.2

(

(

)

)


4.2 Views

Remember the idea of abstraction from Ch.1!


4.2 Views

In some cases, it is not desirable for all users to see the

entire logical model (that is, all the actual relations stored

in the database.)

Consider a person who needs to know an instructors name

and department, but not the salary. This person should

see a relation described by

SELECT ID, name, dept_name

FROM instructor ;


4.2 Views


FROM instructor ;

A view provides a mechanism to hide certain

data from the view of certain users.

Any relation that is not in the DM schema, but

is made visible to a user as a “virtual relation”

is called a view.


View Definition

CREATE VIEW v AS < query expression >

where:

<query expression> is any legal SQL query.

The view name is v.

example


Example

The view is

listed in the

catalog!

Parentheses are optional, but

they increase readability!


QUIZ: Create a view with all course sections offered by

the Physics dept. in the Fall 2009 semester, with the

building and room number of each section.

CREATE VIEW phys_Fall_2009 AS (

?

);


QUIZ: Create a view with all course sections offered by

the Physics dept. in the Fall 2009 semester, with the

building and room number of each section.

CREATE VIEW phys_Fall_2009 AS (

);


Extra-credit QUIZ


Once a view is defined, the view name can be used to

refer to the virtual relation that the view generates.

View definition is not the same as creating a new relation

by evaluating the query expression

• Rather, the view definition causes only the saving of the

SQL query expression

• The expression will later be substituted into any query

that uses that view.

A view is permanently deleted from the catalog using

DROP VIEW v

example

View nitty-gritty


Find all instructors in the Biology department:

SELECT name

FROM faculty

WHERE dept_name = ' Biology ‘ ;

CREATE VIEW faculty AS (


FROM instructor );

We can now use the view as a table to write queries, e.g.


Views can also be used to define other views:

CREATE VIEW phys_fall_2009 AS …

CREATE VIEW phys_fall_2009_watson AS

SELECT course_id, room_number

FROM phys_fall_2009

WHERE building= ’Watson’;

View nitty-gritty


How is this process implemented in SQL?

Think about the C preprocessor …

create view physics_fall_2009 as

select course.course_id, sec_id, building,

room_number

from course, section

where course.course_id = section.course_id

and course.dept_name = ’Physics’

and section.semester = ’Fall’

and section.year = ’2009’;

create view physics_fall_2009_watson as

select course_id, room_number

from physics_fall_2009

where building= ’Watson’;

This is called view expansion


The attribute names in a view can be specified explicitly:

CREATE VIEW dept_sal (dept_name, total_salary) AS (

SELECT dept_name, SUM (salary)

FROM instructor

GROUP BY dept_name

);

View nitty-gritty


Read and take notes:

4.2.3 Materialized Views

SQL does not define a standard way of specifying that a

view is materialized, but many DBMSs provide their own

SQL extensions for this task. In PostgreSQL:

(Details in the lab)


4.2.4 Updating Views

Add a new tuple to this view:

INSERT INTO faculty VALUES (’30765’, ’Green’, ’Music’);

This insertion requires insertion of the tuple

(’30765’, ’Green’, ’Music’, NULL)

into the instructor relation.

CREATE VIEW faculty AS (


FROM instructor );


NULL here!


Problem: Some updates cannot be translated

uniquely!

CREATE VIEW instructor_info AS

SELECT ID, name, building

FROM instructor NATURAL JOIN department ;

INSERT INTO instructor_info VALUES

(’69987’, ’White’, ’Taylor’);

Which department, if multiple

departments in Taylor?

What happens if there is no

department in Taylor?


Next problem: Some updates should not be

allowed at all!

create view history_instructors as

select *

from instructor

where dept_name= ’History’;

What happens if we insert into this view the tuple

(’25566’, ’Brown’, ’Biology’, 100000) ?


create view history_instructors as

select *

from instructor

where dept_name= ’History’;

What happens if we insert into this view the tuple

(’25566’, ’Brown’, ’Biology’, 100000) ?

If we allow insertion, the inserted tuple does not appear in

the view!

Should someone using this view even be allowed to insert

instructors working in a different department?


Conclusion on updating views

Most SQL implementations allow updates only on simple

views, e.g.

The from clause has only one database relation.

The select clause contains only attribute names of the

relation, and does not have any expressions, aggregates,

or distinct specification.

Any attribute not listed in the select clause can be set to

null

The query does not have a group by or having clause.


Updating views in PostgreSQL

PostgreSQL has a proprietary extension to the CREATE

VIEW syntax:

(Details in the lab)


To do for next time:

Read sections covered: 4.1, 4.2

Solve end-of-chapter exercises 4.3, 4.5

EOL 1


QUIZ

Write a query to return all sections, along

with the ID of the instructor teaching

them, even those not yet assigned to an

instructor.


QUIZ

Write a view to display only the sections taught in the Science

building.


4.3 Transactions

Transaction = Atomic unit of work = Sequence of

operations that are either fully executed or rolled back as

if none of them occurred

Why do we need atomicity? Example: transferring money

from account A to account B:

• Subtract amount from A

• Add amount to B

What happens if

the computer

crashes here?


4.3 Transactions

Aside from Atomicity, transaction-processing DBMSs

must also ensure:

Consistency

Isolation

Durability

These are called the ACID properties

(See Chs. 14, 15, 16 for details)


Transactions in PostgreSQL

In PostgreSQL, a transaction is set up by surrounding the

SQL commands of the transaction with BEGIN and

COMMIT commands, e.g.:

BEGIN;

UPDATE accounts SET balance = balance - 100.00

WHERE name = 'Alice';

UPDATE accounts SET balance = balance + 100.00

WHERE name = ‘Bob';

COMMIT;

Not in text

This example is based on the tutorial at https://www.postgresql.org/docs/current/static/tutorial-transactions.html

https://www.postgresql.org/docs/current/static/tutorial-transactions.html


PostgreSQL treats every SQL statement as being executed

within a transaction.

If we don’t issue a BEGIN command, then each individual

statement has an implicit BEGIN and (if successful)

COMMIT wrapped around it.

A group of statements surrounded by BEGIN and COMMIT

is called a transaction block.

Not in text




If, partway through the transaction, we decide we do not want

to commit (perhaps we just noticed that Alice's balance went

negative), we can issue the command ROLLBACK instead of

COMMIT, and all our updates so far will be canceled, e.g.:

BEGIN;

UPDATE accounts SET balance = balance - 150.00

WHERE name = 'Alice';

UPDATE accounts SET balance = balance + 100.00

WHERE name = ‘Bob';

-- Oops, now realizing the amount 150 was wrong

ROLLBACK;

Not in text




QUIZ: Transactions in PostgreSQL

Write a PostgreSQL query that increases the salaries

of all instructors in the CS dept. by 6%, and those of

all instructors in the Biology dept. by 5% atomically.


solution

BEGIN;

UPDATE instructor SET salary = salary * 1.06

WHERE dept_name = 'CS';

UPDATE instructor SET salary = salary * 1.05

WHERE dept_name = 'Biology';

COMMIT;

Write a PostgreSQL query that increases the salaries

of all instructors in the CS dept. by 6%, and those of

all instructors in the Biology dept. by 5% atomically.


4.4 Integrity Constraints

They guard against accidental damage to the DB, by

ensuring that changes do not result in a loss of data

consistency, e.g.

A checking account must have a balance greater than

$10,000.00

A salary of a bank employee must be at least $4.00 an

hour

A customer must have a (non-null) phone number


Integrity Constraints on a Single Relation

NOT NULL

PRIMARY KEY

UNIQUE

CHECK(P), where P is a predicate

They can all be included in CREATE TABLE,

or added later with ALTER TABLE.

4.4 Integrity Constraints


UNIQUE clause

UNIQUE ( A1, A2, …, Am)

States that the attributes A1, A2, … Am form a candidate

super key.

Candidate keys are permitted to be null (in contrast to

primary keys). If we want, we can add NOT NULL.

Note: We have encountered the keyword UNIQUE in ch.3

(subqueries), but there it was part of the DML, whereas here

it’s part of the DDL.

Typo on

p.130 of text!


CHECK clausecheck (P)

where P is a predicate

Example: ensure that semester is one of Fall, Winter, Spring or Summer:

CREATE TABLE section (

course_id varchar (8),

sec_id varchar (8),

semester varchar (6),

year numeric (4,0),

building varchar (15),

room_number varchar (7),

time slot id varchar (4),

PRIMARY KEY (course_id, sec_id, semester, year),

CHECK (semester in (’Fall’, ’Winter’, ’Spring’, ’Summer’))

);


Constraints on two relations:

Referential Integrity

Ensures that a value that appears in

one relation for a given set of

attributes also appears for a certain

set of attributes in another relation.

Example: If “Biology” is a department

name appearing in one (or more) of

the tuples in the instructor relation,

then there exists a (unique!) tuple in

the department relation for “Biology”.


What if an update (INSERT, DELETE,

UPDATE) leads to violation of

referential integrity?

The normal procedure is to reject the

action that caused the violation (the

transaction performing the update

action is rolled back).

However, a foreign key clause can

specify that instead of rejecting the

action, the system must take steps to

change the tuple in the referencing

relation to restore the constraint.

example


CREATE TABLE course (

course_id CHAR(5) PRIMARY KEY,

title VARCHAR(20),

dept_name VARCHAR(20) REFERENCES department

);

CREATE TABLE course (

. . . .

dept_name VARCHAR(20) REFERENCES department

ON DELETE CASCADE,

ON UPDATE CASCADE

);

Alternative actions: SET NULL, SET DEFAULT


Exercise 4.9

What happens when a tuple is deleted? (any tuple!)


Exercise 4.9

What happens when a tuple is deleted? (any tuple!)

A: Due to cascading, all the “tree” of employees under the

manager employee_name is deleted.


Integrity Constraint Violation

During Transactionscreate table person (

ID char(10),

name char(40),

mother char(10),

father char(10),

primary key ID,

foreign key father references person,

foreign key mother references person);

How to insert a tuple without causing constraint violation ?

insert father and mother of a person before inserting person

OR, set father and mother to null initially, update after

inserting all persons (not possible if father and mother

attributes declared to be not null)

OR defer constraint checking (next slide)


Deferred Constraints in PostgreSQL

Upon creation, a constraint is given one of three characteristics:

DEFERRABLE INITIALLY DEFERRED

DEFERRABLE INITIALLY IMMEDIATE

NOT DEFERRABLE.

create table person (

ID char(10),

name char(40),

mother char(10),

father char(10),

primary key ID,

foreign key father references person

DEFERRABLE INITIALLY DEFERRED,

foreign key mother references person)

DEFERRABLE INITIALLY DEFERRED;

Source: https://www.postgresql.org/docs/9.1/static/sql-set-constraints.html

https://www.postgresql.org/docs/9.1/static/sql-set-constraints.html


Deferred Constraints in PostgreSQL

Inside a transaction, the check will de deferred until right before

the COMMIT, e.g. this transaction will succeed:

BEGIN;

INSERT INTO person VALUES (‘01’, ‘Kal-El’, ‘Jor-El’, ‘Lara’ );

INSERT INTO person VALUES (‘02’, ‘Jor-El’, NULL, NULL );

INSERT INTO person VALUES (‘03’, ‘Lara’, NULL, NULL );

COMMIT;


Complex CHECK conditions

CHECK (time_slot_id IN ( SELECT time_slot_id

FROM time_slot));

However, few DBMSs support subqueries in CHECK clause!

(PostgreSQL doesn’t.)

“CHECK is meant to handle constraints on a row's value in

isolation.”

Alternatives:

Triggers and functions (Ch.5)

Assertions

SQL standard says that the predicate can

be anything, including a subquery!


Assertions

CREATE ASSERTION <assertion-name> CHECK <predicate>;

What integrity condition is enforced here?


Assertions

CREATE ASSERTION <assertion-name> CHECK <predicate>;

A: All tuples in student must have total credit equal to the

sum of credits for the classes successfully completed.


QUIZ: Assertions

Write an assertion to ensure that an instructor doesn’t teach two

different sections in the same year, semester and time slot.

Use the previous assertion for example:


solution

An instructor cannot teach two different sections in the same

year, semester and time slot.

CREATE ASSERTION non-ubiquity CHECK (

UNIQUE (

SELECT T.ID, T.semester, T.year, S.time_slot_id

FROM teaches AS T NATURAL JOIN section AS S

)

);


4.5 SQL Data Types and Schemas

Remember the basic data types (Sec.3.2):

char(n)

varchar(n)

int

smallint

numeric(p,d) (user-specified precision)

real, double precision (machine-dependent precision)

float(n) (user-specified precision)


More data types: date and time

date → calendar date yyyy-mm-dd

time → hh:mm:ss

timestamp → combination date + time

Example: 2013-02-21 9:10:59.45-6

Fractions of a

second are

optional

Timezone

is

optional


interval → period of time

Subtracting a date/time/timestamp value from

another gives an interval value

Interval values can be added to date/time/timestamp

values, e.g.

Source: http://www.postgresql.org/docs/9.1/static/functions-datetime.html


Default values

create table student (

ID varchar (5),

name varchar (20) not null,

dept_name varchar (20) default ‘qwerty’

tot_cred numeric (3,0) default 0,

primary key (ID)

)


Index Creation

create table student

(ID varchar (5),

name varchar (20) not null,

dept_name varchar (20),

tot_cred numeric (3,0) default 0,

primary key (ID));

create index studentID_index on student(ID);

Index = data structure used to speed up access to

records with specified values for index attributes, e.g.

SELECT * FROM student WHERE ID = ‘12345’;

More details on indices in Chapter 11


Large-Object Types

Large objects (photos, videos, CAD files, etc.) are stored as a

large object:

BLOB: binary large object -- object is a large collection of

uninterpreted binary data (i.e. its interpretation is left to an

application outside of the DB system)

CLOB: character large object -- object is a large collection

of character data

When a query returns a large object, a pointer is returned

rather than the large object itself.

CLOB is implemented as text

in PostgreSQL (up to 1 GB)


Read and take notes:

4.5.5 User-Defined Types

4.5.7 Schemas, Catalogs, and Environments


4.5.6 CREATE TABLE Extensions

When writing a complex query, it is often useful to store the result

of a query as a new table:

Applications often require creation of tables that have the same

schema as an existing table:

How it this

different from

a view?


4.6 Authorization

Forms of authorization on the data in the database:

Read - allows reading, but not modification of data.

Insert - allows insertion of new data, but not modification of existing

data.

Update - allows modification, but not deletion of data.

Delete - allows deletion of data.

Forms of authorization on the schema of the database:

Index - allows creation and deletion of indices.

Resources - allows creation of new relations.

Alteration - allows addition or deletion of attributes in a relation.

Drop - allows deletion of relations.


4.6 Authorization

Read over lightly the remainder of this section


Homework for Ch.4Due Thursday, Feb.23

- End of chapter 1, 3, 12, 14, 16 (Hint:

CHECK), 18

- Table with all SQL constructs from ch.4,

each used in an example (OK if example is

from text)


Schema for University database


Schema for Bank database (fig.3.19)

Documents

Chapter 4: Intermediate SQL - Faculty Website Listing · Chapter 4: Intermediate SQL. Database System Concepts - 6th Edition 4.2 ©Silberschatz, Korth and Sudarshan ... QUIZ: How