0% found this document useful (0 votes)
2 views64 pages

Intermediate SQL Concepts Explained

Uploaded by

nayanrai.90
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
2 views64 pages

Intermediate SQL Concepts Explained

Uploaded by

nayanrai.90
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd

Chapter 4: Intermediate SQL

Database System Concepts, 6 th Ed.


©Silberschatz, Korth and Sudarshan
See [Link] for conditions on re-use
Chapter 4: Intermediate SQL

Join
Expressions
Views
Transactions
Integrity
Constraints
SQL Data Types and
Schemas Authorization

Database System Concepts - 6 th Edition 4.2 ©Silberschatz, Korth and Sudarshan


Joined Relations

Join operations take two relations and return as a


result another relation.
A join operation is a Cartesian product which
requires that tuples in the two relations match
(under some condition).
It also specifies the attributes that are present in
the result of the join
The join operations are typically used as
subquery expressions in the from clause

Database System Concepts - 6 th Edition 4.3 ©Silberschatz, Korth and Sudarshan


Join operations – Example
Relation
course

Relation
prereq

Observe that
prereq information is missing for CS-
315 and course information is missing
Database System Concepts - 6 th Edition 4.4 ©Silberschatz, Korth and Sudarshan
Outer Join

An extension of the join operation that avoids


loss of information.
Computes the join and then adds tuples form one
relation that does not match tuples in the other
relation to the result of the join.
Uses null values.

Database System Concepts - 6 th Edition 4.5 ©Silberschatz, Korth and Sudarshan


Left Outer Join

course natural left outer join prereq

Database System Concepts - 6 th Edition 4.6 ©Silberschatz, Korth and Sudarshan


Right Outer Join

course natural right outer join prereq

Database System Concepts - 6 th Edition 4.7 ©Silberschatz, Korth and Sudarshan


Joined Relations
Join operations take two relations and return as a
result another relation.
These additional operations are typically used as
subquery expressions in the from clause
Join condition – defines which tuples in the two
relations match, and what attributes are present in
the result of the join.
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.

Database System Concepts - 6 th Edition 4.8 ©Silberschatz, Korth and Sudarshan


Full Outer Join

course natural full outer join


prereq

Database System Concepts - 6 th Edition 4.9 ©Silberschatz, Korth and Sudarshan


Joined Relations – Examples

course inner join prereq on


course.course_id = prereq.course_id

What is the difference between the above, and a


natural join?
course left outer join prereq on
course.course_id = prereq.course_id

Database System Concepts - 6 th Edition 4.10 ©Silberschatz, Korth and Sudarshan


Joined Relations – Examples
course natural right outer join prereq

course full outer join prereq using (course_id)

Database System Concepts - 6 th Edition 4.11 ©Silberschatz, Korth and Sudarshan


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, in SQL, by

select ID, name, dept_name


from instructor

A view provides a mechanism to hide certain data


from the view of certain users.
Any relation that is not of the conceptual model but
is made visible to a user as a “virtual relation” is
called a view.

Database System Concepts - 6 th Edition 4.12 ©Silberschatz, Korth and Sudarshan


View Definition
A view is defined using the create view statement
which has the form

create view v as < query expression >

where <query expression> is any legal SQL


expression.
The view name is represented by v.
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, a view definition causes the saving of an
expression; the expression is substituted into queries
using the view.

Database System Concepts - 6 th Edition 4.13 ©Silberschatz, Korth and Sudarshan


Example Views
A view of instructors without their salary
create view faculty as
select ID, name, dept_name
from instructor
Find all instructors in the Biology department
select name
from faculty
where dept_name = ‘Biology’
Create a view of department salary totals
create view departments_total_salary(dept_name, total_salary)
as
select dept_name, sum (salary)
from instructor
group by dept_name;

Database System Concepts - 6 th Edition 4.14 ©Silberschatz, Korth and Sudarshan


Views Defined Using Other Views
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 [Link] = ’Fall’
and [Link] = ’2009’;
create view physics_fall_2009_watson as
select course_id, room_number
from physics_fall_2009
where building= ’Watson’;

Database System Concepts - 6 th Edition 4.15 ©Silberschatz, Korth and Sudarshan


View Expansion
Expand use of a view in a query/another view

create view physics_fall_2009_watson as


(select course_id, room_number
from (select course.course_id, building,
room_number
from course, section
where course.course_id = section.course_id
and course.dept_name = ’Physics’
and [Link] = ’Fall’
and [Link] = ’2009’)
where building= ’Watson’;

Database System Concepts - 6 th Edition 4.16 ©Silberschatz, Korth and Sudarshan


Views Defined Using Other Views
One view may be used in the expression defining
another view A view relation v1 is said to depend directly
on a view relation v2
if v2 is used in the expression defining v1

A view relation v1 is said to depend on view relation v2


if either v1 depends directly to v2 or there is a path of
dependencies from v1 to v2
A view relation v is said to be recursive if it
depends on itself.

Database System Concepts - 6 th Edition 4.17 ©Silberschatz, Korth and Sudarshan


View Expansion
A way to define the meaning of views defined in terms
of other views.
Let view v1 be defined by an expression e1 that
may itself contain uses of view relations.
View expansion of an expression repeats the
following replacement step:
repeat
Find any view relation vi in e1
Replace the view relation vi by the
expression defining vi
until no more view relations are present in e1
As long as the view definitions are not recursive, this
loop will terminate

Database System Concepts - 6 th Edition 4.18 ©Silberschatz, Korth and Sudarshan


Update of a View
Add a new tuple to faculty view which we defined
earlier
insert into faculty values (’30765’, ’Green’,
’Music’);
This insertion must be represented by the insertion of
the tuple (’30765’, ’Green’, ’Music’, null)
into the instructor relation

Database System Concepts - 6 th Edition 4.19 ©Silberschatz, Korth and Sudarshan


Some Updates cannot be Translated
Uniquely
create view instructor_info as
select ID, name, building
from instructor, department
where instructor.dept_name=
department.dept_name;
insert into instructor_info
values (’69987’, ’White’,
’Taylor’);
 which department, if
multiple departments
in Taylor?
 what if no department
is in Taylor?
Most SQL implementations allow updates only on
simple views The from clause has only one
database relation.
Database System Concepts - 6 th Edition 4.20 ©Silberschatz, Korth and Sudarshan
And Some Not at All
create view history_instructors as
select *
from instructor
where dept_name= ’History’;
What happens if we insert (’25566’, ’Brown’, ’Biology’,
100000) into history_instructors?

Database System Concepts - 6 th Edition 4.21 ©Silberschatz, Korth and Sudarshan


Materialized Views
Materializing a view: create a physical table containing all
the tuples in the result of the query defining the view
If relations used in the query are updated, the materialized
view result becomes out of date
Need to maintain the view, by updating the view
whenever the underlying relations are updated.

Database System Concepts - 6 th Edition 4.22 ©Silberschatz, Korth and Sudarshan


Transactions
Unit of work
Atomic
transaction
either fully executed or rolled back as if it never
occurred Isolation from concurrent transactions
Transactions begin implicitly
Ended by commit work or rollback work
But default on most databases: each SQL
statement commits automatically
Can turn off auto commit for a session (e.g.
using API) In SQL:1999, can use: begin
atomic …. end
 Not supported on most databases

Database System Concepts - 6 th Edition 4.23 ©Silberschatz, Korth and Sudarshan


Integrity Constraints
Integrity constraints guard against accidental damage to the database,
by ensuring that authorized changes to the database do not result in a
loss of data consistency.
1. A checking account must have a balance greater than
$10,000.00
CREATE TABLE Account (
account_no INT PRIMARY KEY,
balance DECIMAL(10,2),
CHECK (balance > 10000.00));
2. A salary of a bank employee must be at least $4.00 an hour
CREATE TABLE Employee (
emp_id INT PRIMARY KEY,
emp_name VARCHAR(50),
salary_per_hour DECIMAL(5,2),
CHECK (salary_per_hour >= 4.00)
);

Database System Concepts - 6 th Edition 4.24 ©Silberschatz, Korth and Sudarshan


Integrity Constraints on a Single Relation

not null
primary key
unique
check (P),
where P is a
predicate

Database System Concepts - 6 th Edition 4.25 ©Silberschatz, Korth and Sudarshan


Not Null

not null
A customer must have a (non-null) phone number
CREATE TABLE Customer (
cust_id INT PRIMARY KEY,
cust_name VARCHAR(50),
phone_number VARCHAR(15) NOT NULL
);
Declare name and budget to be not null
name varchar(20) not null
budget numeric(12,2) not null

Database System Concepts - 6 th Edition 4.26 ©Silberschatz, Korth and Sudarshan


Unique Constraints
unique ( A1, A2, …, Am): The UNIQUE constraint ensures that
all values in a column (or group of columns) are different
— i.e., no duplicates are allowed.
The unique specification states that the attributes A1, A2, …, Am
form a candidate key.
Candidate keys are permitted to be null (in contrast to primary keys).
CREATE TABLE Customer (
cust_id INT PRIMARY KEY,
cust_name VARCHAR(50),
phone_number VARCHAR(15) UNIQUE NOT NULL);

CREATE TABLE Employee (


emp_id INT PRIMARY KEY,
emp_name VARCHAR(50),
email VARCHAR(100) UNIQUE,
salary_per_hour DECIMAL(5,2) CHECK (salary_per_hour >= 4.00));

Database System Concepts - 6 th Edition 4.27 ©Silberschatz, Korth and Sudarshan


The check clause

check (P)
where P is a predicate/a logical condition
that must be TRUE for all rows in the table.

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’,
Database System Concepts - 6 th Edition 4.28 ©Silberschatz, Korth and Sudarshan
The check clause

check (P):
CREATE TABLE STUDENT (
roll_no INT PRIMARY KEY,
age INT,
CHECK (age >= 18)
);
CREATE TABLE Account (
acc_no INT PRIMARY KEY,
cust_name VARCHAR(50),
balance DECIMAL(10,2),
CHECK (balance >= 1000)
);

Database System Concepts - 6 th Edition 4.29 ©Silberschatz, Korth and Sudarshan


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 of the tuples in the instructor
relation, then there exists a tuple in the department
relation for “Biology”.
Let A be a set of attributes. Let R and S be two
relations that contain attributes A and where A is the
primary key of S. A is said to be a foreign key of R
if for any values of A appearing in R these values
also appear in S.

Database System Concepts - 6 th Edition 4.30 ©Silberschatz, Korth and Sudarshan


Cascading Actions in Referential Integrity
create table course (
course_id char(5) primary
title key, varchar(20),
dept_name varchar(20) references department )
CREATE TABLE Course (
course_id VARCHAR(10) PRIMARY KEY,
title VARCHAR(50),
dept_name VARCHAR(20),
FOREIGN KEY (dept_name) REFERENCES
Department(dept_name)
ON DELETE CASCADE
ON UPDATE CASCADE
);
alternative actions to cascade: set null, set
default
Database System Concepts - 6 th Edition 4.31 ©Silberschatz, Korth and Sudarshan
Referential Integrity
Action Effect on DELETE / UPDATE Example / Explanation

If Department 'CSE' is deleted, all


Automatically delete or update all
CASCADE Course rows with
matching child rows
dept_name='CSE' are deleted too.

If Department 'CSE' is deleted, all


Set the foreign key column in child
SET NULL Course.dept_name = NULL (if
table to NULL
column allows NULL).

If Department 'CSE' is deleted, all


Set the foreign key column to its
SET DEFAULT Course.dept_name reset to the
default value
default (e.g., 'General').

Reject the delete or update if matching You cannot delete a department that
NO ACTION (default)
rows exist in child table still has courses.

Similar to NO ACTION (check Prevents delete/update when related


RESTRICT
immediately, not deferred) child rows exist.

Database System Concepts - 6 th Edition 4.32 ©Silberschatz, Korth and Sudarshan


Cascading Actions in Referential Integrity
alternative actions to cascade: set null, set default
Set Null:
FOREIGN KEY (dept_name) REFERENCES Department(dept_name)
ON DELETE SET NULL
ON UPDATE CASCADE

CREATE TABLE Course (


course_id VARCHAR(10) PRIMARY KEY,
title VARCHAR(50),
dept_name VARCHAR(20) DEFAULT 'General',
FOREIGN KEY (dept_name) REFERENCES Department(dept_name)
ON DELETE SET DEFAULT
ON UPDATE CASCADE );

Database System Concepts - 6 th Edition 4.33 ©Silberschatz, Korth and Sudarshan


Cascading Actions in Referential Integrity
Two of the options are NO ACTION and RESTRICT — both mean that the
DBMS will not allow the delete or update if dependent (child) rows exist.
CREATE TABLE Department (
dept_name VARCHAR(20) PRIMARY KEY,
location VARCHAR(20)
);
CREATE TABLE Course (
course_id VARCHAR(10) PRIMARY KEY,
title VARCHAR(50),
dept_name VARCHAR(20),
FOREIGN KEY (dept_name) REFERENCES Department(dept_name)
ON DELETE RESTRICT
ON UPDATE NO ACTION );

Database System Concepts - 6 th Edition 4.34 ©Silberschatz, Korth and Sudarshan


Cascading Actions in Referential Integrity
ON DELETE RESTRICT
If a department still has related courses, you cannot delete that
department.
The DBMS will raise an error.
Example:
DELETE FROM Department WHERE dept_name = 'CSE';
-- ❌ Error: Cannot delete, Course table still references this dept_name

ON UPDATE NO ACTION
Similar to RESTRICT, but the integrity check may be deferred until the end
of the transaction (depends on DB system).
Effectively, it prevents updates to dept_name in Department if related rows
exist in Course.
Example:
UPDATE Department SET dept_name = 'CS' WHERE dept_name = 'CSE';
-- ❌ Error: Cannot update, Course table still references old dept_name

Database System Concepts - 6 th Edition 4.35 ©Silberschatz, Korth and Sudarshan


Integrity Constraint Violation During
Transactions
E.g.
create 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
INSERT INTO Person VALUES ('F001', 'Ravi', NULL, NULL); --
Father
Database System Concepts - 6 th Edition 4.36 ©Silberschatz, Korth and Sudarshan
Integrity Constraint Violation During
Transactions
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)
-- Step 1: Insert all persons without relationships
INSERT INTO Person VALUES ('C001', 'Rahul', NULL,
NULL);
INSERT INTO Person VALUES ('M001', 'Sita', NULL,
NULL);
INSERT INTO Person VALUES ('F001', 'Ravi', NULL,
NULL);

-- Step 2: After all persons exist, update relationships


UPDATE Person SET mother = 'M001', father = 'F001'
WHERE ID = 'C001';

Database System Concepts - 6 th Edition 4.37 ©Silberschatz, Korth and Sudarshan


Integrity Constraint Violation During
Transactions
OR defer constraint checking (next slide)
Some SQL systems (like PostgreSQL, Oracle) allow
deferrable constraints, meaning the foreign key
constraint is checked at the end of the transaction
instead of after each statement.
CREATE TABLE Person (
ID CHAR(10) PRIMARY KEY,
name CHAR(40),
mother CHAR(10),
father CHAR(10),
FOREIGN KEY (father) REFERENCES Person(ID)
DEFERRABLE INITIALLY DEFERRED,
FOREIGN KEY (mother) REFERENCES Person(ID)
DEFERRABLE INITIALLY DEFERRED
);
Database System Concepts - 6 th Edition 4.38 ©Silberschatz, Korth and Sudarshan
Integrity Constraint Violation During
Transactions
OR defer constraint checking (next slide)
BEGIN;

INSERT INTO Person VALUES ('C001', 'Rahul', 'M001',


'F001');
INSERT INTO Person VALUES ('M001', 'Sita', NULL, NULL);
INSERT INTO Person VALUES ('F001', 'Ravi', NULL, NULL);

COMMIT;

Database System Concepts - 6 th Edition 4.39 ©Silberschatz, Korth and Sudarshan


Complex Check Clauses
check (time_slot_id in (select time_slot_id from time_slot))
why not use a foreign key here?
CREATE TABLE section (
section_id INT PRIMARY KEY,
course_id VARCHAR(10),
time_slot_id VARCHAR(10),
FOREIGN KEY (time_slot_id) REFERENCES
time_slot(time_slot_id));
Every section has at least one instructor teaching the section.
how to write this?
Unfortunately: subquery in check clause not supported by
pretty much any database

Database System Concepts - 6 th Edition 4.40 ©Silberschatz, Korth and Sudarshan


Complex Check Clauses
Alternative: triggers (later)
CREATE TRIGGER check_instructor_exists
AFTER INSERT OR UPDATE ON section
FOR EACH ROW
BEGIN
IF NOT EXISTS (SELECT * FROM teaches WHERE
teaches.section_id = NEW.section_id) THEN
RAISE_APPLICATION_ERROR(-20000, 'Every section
must have at least one instructor');
END IF;
END;
create assertion <assertion-name> check <predicate>;
Also not supported by anyone
CHECK (EXISTS (SELECT * FROM teaches WHERE
teaches.section_id = section.section_id))
Database System Concepts - 6 th Edition 4.41 ©Silberschatz, Korth and Sudarshan
Built-in Data Types in SQL
date: Dates, containing a (4 digit) year, month and
date
Format: 'YYYY-MM-DD’
Example: date ‘2005-7-27’
time: Time of day, in hours, minutes and seconds.
Stores time of day — hours, minutes, seconds, and
optionally fractions of a second.
Format: 'HH:MI:SS' or 'HH:MI:[Link]'
Example: time ‘09:00:30’ time ‘09:00:30.75’
timestamp: date plus time of day
Format: 'YYYY-MM-DD HH:MI:SS'
Example: timestamp ‘2005-7-27 09:00:30.75’

Database System Concepts - 6 th Edition 4.42 ©Silberschatz, Korth and Sudarshan


Built-in Data Types in SQL
interval: period of time
Example: interval
‘1’ day
Subtracting a date/time/timestamp value from another
gives an interval value
Interval values can be added to date/time/timestamp
values
-- Subtracting gives an interval
SELECT DATE '2025-10-09' - DATE '2025-10-01';
-- Result: INTERVAL '8' DAY

-- Adding an interval to a date/time


SELECT DATE '2025-10-01' + INTERVAL '7' DAY;
-- Result: 2025-10-08
Database System Concepts - 6 th Edition 4.43 ©Silberschatz, Korth and Sudarshan
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)
Indices are data structures used to speed up access to
records with specified values for index attributes
e.g. select *
from student
where ID = ‘12345’
can be executed by using the index to find the
required record, without looking at all records of
student
More on indices in unit-5
Database System Concepts - 6 th Edition 4.44 ©Silberschatz, Korth and Sudarshan
User-Defined Types

create type construct in SQL creates user-defined type

CREATE TYPE type_name AS base_type;

create type Dollars as numeric (12,2) final


create table department
(dept_name varchar (20), building varchar (15), budget Dollars);

Defines a new data type named Dollars, which behaves like a


numeric value with 12 digits in total and 2 digits after the
decimal point.
FINAL: Means this user-defined type cannot be subclassed or
extended further

Database System Concepts - 6 th Edition 4.45 ©Silberschatz, Korth and Sudarshan


Domains
create domain construct in SQL-92 creates user-defined domain
types

CREATE DOMAIN domain_name AS base_type

[DEFAULT default_value]

[CONSTRAINT constraint_name CHECK (condition)];

create domain person_name char(20) not null

Types and domains are similar. Domains can have


constraints, such as not null, specified on them.
create domain degree_level varchar(10) constraint
degree_level_test
check (value in (‘Diploma’, ‘Bachelors’, ‘Masters’,
‘Doctorate’));
Database System Concepts - 6 th Edition 4.46 ©Silberschatz, Korth and Sudarshan
Domains

CREATE TABLE student (


student_id INT PRIMARY KEY,
degree degree_level
);

INSERT INTO student VALUES (101, 'Diploma');

Database System Concepts - 6 th Edition 4.47 ©Silberschatz, Korth and Sudarshan


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 (whose
interpretation is left to an application outside of the
database 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.

Database System Concepts - 6 th Edition 4.48 ©Silberschatz, Korth and Sudarshan


Authorization

Forms of authorization on parts of 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 to modify the database schema


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.
Database System Concepts - 6 th Edition 4.49 ©Silberschatz, Korth and Sudarshan
Authorization Specification in SQL

The grant statement is used to confer authorization


grant <privilege list>
on <relation name or view name> to <user list>
<user list>
is: a
user-id
public, which allows all valid users the privilege
granted A role (more on this later)
Granting a privilege on a view does not imply
granting any privileges on the underlying relations.
The grantor of the privilege must already hold the
privilege on the specified item (or be the database
administrator).

Database System Concepts - 6 th Edition 4.50 ©Silberschatz, Korth and Sudarshan


Privileges in SQL

select: allows read access to relation,or the ability


to query using the view
Example: grant users U1, U2, and U3 select
authorization on the instructor relation:
grant select on instructor to U1, U2, U3
insert: the ability to insert tuples
update: the ability to update using the SQL
update statement
delete: the ability to delete tuples.
all privileges: used as a short form for all the
allowable privileges

Database System Concepts - 6 th Edition 4.51 ©Silberschatz, Korth and Sudarshan


Revoking Authorization in SQL

The revoke statement is used to revoke authorization.


revoke <privilege list>
on <relation name or view name> from
<user list> Example:
revoke select on branch from U1, U2, U3
<privilege-list> may be all to revoke all privileges
the revokee may hold.
If <revokee-list> includes public, all users lose the
privilege except those granted it explicitly.
If the same privilege was granted twice to the
same user by different grantees, the user may
retain the privilege after the revocation.
All privileges that depend on the privilege being
revoked are also revoked.
Database System Concepts - 6 th Edition 4.52 ©Silberschatz, Korth and Sudarshan
Roles
create role instructor;
grant instructor to Amit;
Privileges can be granted to roles:
grant select on takes to instructor;
Roles can be granted to users, as well as to other
roles
create role teaching_assistant
grant teaching_assistant to instructor;
 Instructor inherits all privileges of
teaching_assistant
Chain of roles
create role dean;
grant instructor to dean;
grant dean to Satoshi;

Database System Concepts - 6 th Edition 4.53 ©Silberschatz, Korth and Sudarshan


Authorization on Views
create view geo_instructor as
(select *
from instructor
where dept_name = ’Geology’);
grant select on geo_instructor to geo_staff
Suppose that a geo_staff member issues
select *
from geo_instructor;
What if
geo_staff does not have permissions on
instructor?
creator of view did not have some
permissions on
instructor?

Database System Concepts - 6 th Edition 4.54 ©Silberschatz, Korth and Sudarshan


Other Authorization Features
references privilege to create foreign key
grant reference (dept_name) on department to
Mariano;
why is this
required? transfer of
privileges
grant select
on department to
Amit with grant
option;
revoke select
on department
from Amit,
Satoshi
cascade;
revoke select
Database System Concepts - 6 th Edition 4.55 ©Silberschatz, Korth and Sudarshan
End of Chapter 4

Database System Concepts, 6 th Ed.


©Silberschatz, Korth and Sudarshan
See [Link] for conditions on re-use
Figure 4.01

Database System Concepts - 6 th Edition 4.57 ©Silberschatz, Korth and Sudarshan


Figure 4.02

Database System Concepts - 6 th Edition 4.58 ©Silberschatz, Korth and Sudarshan


Figure 4.03

Database System Concepts - 6 th Edition 4.59 ©Silberschatz, Korth and Sudarshan


Figure 4.04

Database System Concepts - 6 th Edition 4.60 ©Silberschatz, Korth and Sudarshan


Figure 4.05

Database System Concepts - 6 th Edition 4.61 ©Silberschatz, Korth and Sudarshan


Figure 4.07

Taylor

Database System Concepts - 6 th Edition 4.62 ©Silberschatz, Korth and Sudarshan


Figure 4.06

Database System Concepts - 6 th Edition 4.63 ©Silberschatz, Korth and Sudarshan


Figure 4.03

Database System Concepts - 6 th Edition 4.64 ©Silberschatz, Korth and Sudarshan

You might also like