Chapter 4 : Intermediate SQL

Database System Concepts, 7th Ed.

©Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use
 Outline

 Join Expressions
 Views
 Transactions
 Integrity Constraints
 SQL Data Types and Schemas
 Index Definition in SQL
 Authorization

Database System Concepts - 7th 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
 Three types of joins:
 Natural join
 Inner join
 Outer join

Database System Concepts - 7th Edition 4.3 ©Silberschatz, Korth and Sudarshan
 Natural Join in SQL
 Natural join matches tuples with the same values for all
common attributes, and retains only one copy of each
common column.
 List the names of instructors along with the course ID of
the courses that they taught
 select name, course_id
from students, takes
where student.ID = takes.ID;
 Same query in SQL with “natural join” construct
 select name, course_id
from student natural join takes;

Database System Concepts - 7th Edition 4.4 ©Silberschatz, Korth and Sudarshan
 Natural Join in SQL (Cont.)

 The from clause can have multiple relations combined

using natural join:
select A1, A2, … An
from r1 natural join r2 natural join .. natural join rn
where P ;

Database System Concepts - 7th Edition 4.5 ©Silberschatz, Korth and Sudarshan
 Student Relation

Database System Concepts - 7th Edition 4.6 ©Silberschatz, Korth and Sudarshan
 Takes Relation

Database System Concepts - 7th Edition 4.7 ©Silberschatz, Korth and Sudarshan
 student natural join takes

Database System Concepts - 7th Edition 4.8 ©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.
 Three forms of outer join:
 left outer join
 right outer join
 full outer join

Database System Concepts - 7th Edition 4.10 ©Silberschatz, Korth and Sudarshan
 Outer Join Examples

 Relation course

 Relation prereq

 Observe that
course information is missing CS-347
prereq information is missing CS-315

Database System Concepts - 7th Edition 4.11 ©Silberschatz, Korth and Sudarshan
 Left Outer Join

 course natural left outer join prereq

 In relational algebra: course ⟕ prereq

Database System Concepts - 7th Edition 4.12 ©Silberschatz, Korth and Sudarshan
 Right Outer Join

 course natural right outer join prereq

 In relational algebra: course ⟖ prereq

Database System Concepts - 7th Edition 4.13 ©Silberschatz, Korth and Sudarshan
 Full Outer Join

 course natural full outer join prereq

 In relational algebra: course ⟗ prereq

Database System Concepts - 7th Edition 4.14 ©Silberschatz, Korth and Sudarshan
 Joined Types and Conditions

 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.
 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 - 7th Edition 4.15 ©Silberschatz, Korth and Sudarshan
 Joined Relations – Examples

 course natural right outer join prereq

 course full outer join prereq using (course_id)

In this case, the FULL OUTER JOIN with USING will combine rows from both
tables, matching them on the course_id column and including all rows from both tables
where the course_id matches between them. The result will display all courses and their
prerequisites where available.

Database System Concepts - 7th Edition 4.16 ©Silberschatz, Korth and Sudarshan
 Joined Relations – Examples

 course inner join prereq on

course.course_id = prereq.course_id

An INNER JOIN selects records from both tables where the join condition specified
(course.course_id = prereq.course_id) is met. In this case, it retrieves rows where the course_id in the course
table matches the course_id in the prereq table.
Here's a breakdown of what happens:
1.SELECT *: This retrieves all columns from both tables involved in the query.
2.FROM course: Specifies the left table in the join, which is course.
3.INNER JOIN prereq ON course.course_id = prereq.course_id : This clause indicates the join operation. It
matches rows in the course table with rows in the prereq table where the course_id values are equal.
The result of this query will be a dataset that contains columns from both tables ( course and prereq) where there are matching
course_id values between the two tables. Rows that don’t have a match based on the course_id won’t be included in the output

Database System Concepts - 7th Edition 4.17 ©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 - 7th Edition 4.18 ©Silberschatz, Korth and Sudarshan
 Joined Relations – Examples

 course natural right outer join prereq

 course full outer join prereq using (course_id)

Database System Concepts - 7th Edition 4.19 ©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 - 7th Edition 4.20 ©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

Database System Concepts - 7th Edition 4.21 ©Silberschatz, Korth and Sudarshan
 View Definition and Use

 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 - 7th Edition 4.22 ©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 - 7th Edition 4.23 ©Silberschatz, Korth and Sudarshan
 Views Defined Using Other Views

 create view physics_fall_2017 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 = '2017’;

 create view physics_fall_2017_watson as

select course_id, room_number
from physics_fall_2017
where building= 'Watson';

Database System Concepts - 7th Edition 4.24 ©Silberschatz, Korth and Sudarshan
 View Expansion
 Expand the view :
create view physics_fall_2017_watson as
select course_id, room_number
from physics_fall_2017
where building= 'Watson'
 To:

create view physics_fall_2017_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 section.semester = 'Fall'
and section.year = '2017')
where building= 'Watson';

Database System Concepts - 7th Edition 4.25 ©Silberschatz, Korth and Sudarshan
 Materialized Views

 Certain database systems allow view relations to be

physically stored.
 Physical copy created when the view is defined.
 Such views are called Materialized 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 - 7th Edition 4.26 ©Silberschatz, Korth and Sudarshan
 Materialized Views
 Several relational database management systems support
materialized views. Here are a few popular ones:
 Oracle Database: Oracle has robust support for materialized
views, allowing them to be refreshed manually or on a
schedule, and offering various options for maintaining their
consistency with underlying data.
 PostgreSQL: Starting from certain versions, PostgreSQL
introduced support for materialized views, enabling users to
create and refresh them. However, the functionality might
have some limitations compared to other systems like
Oracle.
 Microsoft SQL Server: SQL Server offers indexed views,
which are similar to materialized views in other databases.
They can improve query performance but have restrictions
on their use and maintenance.
 IBM Db2: Db2 provides support for materialized query tables
(MQTs), which are similar to materialized views. They can
be defined and refreshed to improve query performance.
 MySQL and MariaDB: These databases have limited support
for materialized views. While they lack built-in materialized
views,- 7users
Database System Concepts
th
Edition often simulate this
4.27 functionality using triggers
©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 into
the instructor relation
 Must have a value for salary.
 Two approaches
 Reject the insert
 Insert the tuple
('30765', 'Green', 'Music', null)
into the instructor relation

Database System Concepts - 7th Edition 4.28 ©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');
 Issues
 Which department, if multiple departments in Taylor?
 What if no department is in Taylor?

Database System Concepts - 7th Edition 4.29 ©Silberschatz, Korth and Sudarshan
 Some Updates Cannot be Translated
Uniquely

You can't directly update or insert into a view that's based on multiple tables or complex queries involving joins and conditions,
especially if it doesn't directly map to a single underlying table. The reason is that a view might be defined using multiple tables and
conditions, making it ambiguous or impractical to update.
For your specific case, the instructor_info view is based on a join between the instructor and department tables.
When you attempt an INSERT into the instructor_info view, it's not immediately clear how to handle this operation because
the view combines data from multiple tables.
Regarding your concerns:
1.Multiple Departments for 'Taylor': If there are multiple departments with the name 'Taylor', the instructor_info view
wouldn't inherently know which department to assign the new record to. It might cause an ambiguity error or attempt to insert duplicate
rows, depending on how the view is defined.
2.No Department in 'Taylor': If there's no department named 'Taylor', the INSERT operation might fail or might insert a record
with NULL values for the ID and building columns (assuming those columns allow NULL).
To perform an INSERT in such scenarios where a view involves multiple tables and conditions, it's generally better to insert
directly into the underlying tables (instructor and department in this case) rather than into the view. This ensures that the
data is inserted into the appropriate tables, and any necessary integrity constraints or triggers can be properly enforced.

Database System Concepts - 7th Edition 4.30 ©Silberschatz, Korth and Sudarshan
 View Updates in SQL

 Most SQL implementations allow updates only on simple

views
 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.

Database System Concepts - 7th Edition 4.31 ©Silberschatz, Korth and Sudarshan
 Transactions
 A transaction consists of a sequence of query and/or
update statements and is a “unit” of work
 The SQL standard specifies that a transaction begins
implicitly when an SQL statement is executed.
 The transaction must end with one of the following
statements:
 Commit work. The updates performed by the
transaction become permanent in the database.
 Rollback work. All the updates performed by the SQL
statements in the transaction are undone.
 Atomic transaction
 either fully executed or rolled back as if it never
occurred
 Isolation from concurrent transactions

Database System Concepts - 7th Edition 4.32 ©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.
 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

Database System Concepts - 7th Edition 4.33 ©Silberschatz, Korth and Sudarshan
 Constraints on a Single Relation

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

Database System Concepts - 7th Edition 4.34 ©Silberschatz, Korth and Sudarshan
 Not Null Constraints

 not null
 Declare name and budget to be not null
name varchar(20) not null
budget numeric(12,2) not null

Database System Concepts - 7th Edition 4.35 ©Silberschatz, Korth and Sudarshan
 Not Null Constraints
In databases, NOT NULL is a constraint that can be applied to a column. When a column is marked as NOT
NULL, it means that the column must contain a value in every row and cannot store NULL (i.e., absence of a
value).
For example, when you define a table, you can specify that certain columns should not accept NULL values

In this students table, student_name and date_of_birth columns are marked as NOT NULL.
Every time you insert a new row into this table, you must provide a value for these columns; otherwise, the
database will raise an error.
Using NOT NULL constraints helps enforce data integrity by ensuring that essential information is always
present in specified columns. It helps prevent accidental omission of required information and can make queries
and data manipulation more predictable.

Database System Concepts - 7th Edition 4.36 ©Silberschatz, Korth and Sudarshan
 Unique Constraints

 unique ( A1, A2, …, Am)

 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).

Database System Concepts - 7th Edition 4.37 ©Silberschatz, Korth and Sudarshan
 Unique Constraints

The UNIQUE constraint in a database specifies that the combination of values across specified columns must
be unique across all rows in the table. This constraint doesn't allow duplicate combinations of values in the
designated columns.
Let's say we have a table named employees, and we want to ensure that the combination of employee_id
and email together is unique but still allows for null values in either column:

In this example, the UNIQUE constraint is applied to the combination of employee_id and email columns. This constraint
ensures that each combination of values in these columns is unique across all rows in the employees table.
This means:
•Each employee_id can have a unique email, and vice versa.
•The combination of both columns is what must be unique, allowing null values in either column as long as the combination itself doesn't
duplicate an existing combination in another row.
This constraint doesn't impose the NOT NULL requirement for individual columns. It's different from a primary key constraint where
columns are both unique and non-null.

Database System Concepts - 7th Edition 4.38 ©Silberschatz, Korth and Sudarshan
 The check clause
 The check (P) clause specifies a predicate P that must be
satisfied by every tuple in a relation.
 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')))

Database System Concepts - 7th Edition 4.39 ©Silberschatz, Korth and Sudarshan
 The check clause
In this scenario, the section table is being created with a CHECK constraint on the semester column, ensuring that
its value must be one among 'Fall', 'Winter', 'Spring', or 'Summer'.
Let's create the section table with the given constraints

-- Valid insertion
INSERT INTO section (course_id, sec_id, semester, year, building,
room_number, time_slot_id)
VALUES ('CSCI101', '001', 'Fall', 2023, 'Taylor Hall', '101', 'TS01');

-- Invalid insertion (semester value not in the specified list)

INSERT INTO section (course_id, sec_id, semester, year, building,
room_number, time_slot_id)
VALUES ('MATH201', '002', 'Autumn', 2023, 'Smith Building', '201', 'TS02');
Database System Concepts - 7th Edition 4.40 ©Silberschatz, Korth and Sudarshan
 Complex Check Conditions
 The predicate in the check clause can be an arbitrary
predicate that can include a subquery.
check (time_slot_id in (select time_slot_id from
time_slot))
The check condition states that the time_slot_id in each
tuple in the section relation is actually the identifier of a
time slot in the time_slot relation.
 The condition has to be checked not only when a tuple
is inserted or modified in section , but also when the
relation time_slot changes

Database System Concepts - 7th Edition 4.41 ©Silberschatz, Korth and Sudarshan
 Complex Check Conditions
In this scenario, the section table has a CHECK constraint that verifies whether the time_slot_id in each tuple
within the section table corresponds to an existing time_slot_id in the time_slot table. This constraint ensures
data integrity by validating references to the time_slot table.
Let's create the section and time_slot tables and set up the constraint:

Database System Concepts - 7th Edition 4.42 ©Silberschatz, Korth and Sudarshan
 Complex Check Conditions
This example assumes a foreign key relationship between the section table's time_slot_id column and the time_slot
table's time_slot_id column to maintain referential integrity. Now, let's insert and verify data:

-- Valid insertion (time_slot_id exists in time_slot table)

INSERT INTO time_slot (time_slot_id) VALUES ('TS01');

INSERT INTO section (course_id, sec_id, semester, year, building,

room_number, time_slot_id)
VALUES ('CSCI101', '001', 'Fall', 2023, 'Taylor Hall', '101', 'TS01');

-- Invalid insertion (time_slot_id doesn't exist in time_slot table)

INSERT INTO section (course_id, sec_id, semester, year, building,
room_number, time_slot_id)
VALUES ('MATH201', '002', 'Fall', 2023, 'Smith Building', '201', 'TS02');

•The first INSERT statement is valid because the time_slot_id 'TS01' exists in the time_slot table.
•The second INSERT statement is invalid because the time_slot_id 'TS02' does not exist in the time_slot
table, violating the CHECK constraint.

Database System Concepts - 7th Edition 4.43 ©Silberschatz, Korth and Sudarshan
 Built-in Data Types in SQL

 date: Dates, containing a (4 digit) year, month and date

 Example: date '2005-7-27'
 time: Time of day, in hours, minutes and seconds.
 Example: time '09:00:30' time '09:00:30.75'
 timestamp: date plus time of day
 Example: timestamp '2005-7-27 09:00:30.75'
 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

Database System Concepts - 7th Edition 4.44 ©Silberschatz, Korth and Sudarshan
 Built-in Data Types in SQL

Database System Concepts - 7th Edition 4.45 ©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 - 7th Edition 4.46 ©Silberschatz, Korth and Sudarshan
 User-Defined Types

 create type construct in SQL creates user-defined type

create type Dollars as numeric (12,2) final

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

Database System Concepts - 7th Edition 4.47 ©Silberschatz, Korth and Sudarshan
 User-Defined Types

Database System Concepts - 7th Edition 4.48 ©Silberschatz, Korth and Sudarshan
 User-Defined Types

Database System Concepts - 7th Edition 4.49 ©Silberschatz, Korth and Sudarshan
 Domains
 create domain construct in SQL-92 creates user-
defined domain types

create domain person_name char(20) not

null

 Types and domains are similar. Domains can have

constraints, such as not null, specified on them.
 Example:
create domain degree_level varchar(10)
constraint degree_level_test
check (value in ('Bachelors', 'Masters',
'Doctorate'));

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

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

Database System Concepts - 7th Edition 4.52 ©Silberschatz, Korth and Sudarshan
 Domains

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

Database System Concepts - 7th Edition 4.54 ©Silberschatz, Korth and Sudarshan
 Index Creation
 Many queries reference only a small proportion of the
records in a table.
 It is inefficient for the system to read every record to find a
record with particular value
 An index on an attribute of a relation is a data structure
that allows the database system to find those tuples in the
relation that have a specified value for that attribute
efficiently, without scanning through all the tuples of the
relation.
 We create an index with the create index command
create index <name> on <relation-name> (attribute);

Database System Concepts - 7th Edition 4.55 ©Silberschatz, Korth and Sudarshan
 Index Creation Example
 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)
 The query:
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

Database System Concepts - 7th Edition 4.56 ©Silberschatz, Korth and Sudarshan
 Index Creation Example

Database System Concepts - 7th Edition 4.57 ©Silberschatz, Korth and Sudarshan
 Index Creation Example

Database System Concepts - 7th Edition 4.58 ©Silberschatz, Korth and Sudarshan
 Authorization
 We may assign a user several forms of authorizations 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.
 Each of these types of authorizations is called a privilege.
We may authorize the user all, none, or a combination of
these types of privileges on specified parts of a database,
such as a relation or a view.

Database System Concepts - 7th Edition 4.59 ©Silberschatz, Korth and Sudarshan
 Authorization (Cont.)
 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 - 7th Edition 4.60 ©Silberschatz, Korth and Sudarshan
 Authorization Specification in SQL

 The grant statement is used to confer authorization

grant <privilege list> on <relation or view > to <user list>
 <user list> is:
 a user-id
 public, which allows all valid users the privilege granted
 A role (more on this later)
 Example:
 grant select on department to Amit, Satoshi
 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 - 7th Edition 4.61 ©Silberschatz, Korth and Sudarshan
 Authorization Specification in SQL

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

Database System Concepts - 7th Edition 4.64 ©Silberschatz, Korth and Sudarshan
 Authorization Specification in SQL

Database System Concepts - 7th Edition 4.65 ©Silberschatz, Korth and Sudarshan
 Authorization Specification in SQL

Database System Concepts - 7th Edition 4.66 ©Silberschatz, Korth and Sudarshan
 Authorization Specification in SQL

Database System Concepts - 7th Edition 4.67 ©Silberschatz, Korth and Sudarshan
 Authorization Specification in SQL

Database System Concepts - 7th Edition 4.68 ©Silberschatz, Korth and Sudarshan
 Revoking Authorization in SQL

 The revoke statement is used to revoke authorization.

revoke <privilege list> on <relation or view> from <user
list>
 Example:
revoke select on student 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 - 7th Edition 4.69 ©Silberschatz, Korth and Sudarshan
 Revoking Authorization in SQL

Database System Concepts - 7th Edition 4.70 ©Silberschatz, Korth and Sudarshan
 Revoking Authorization in SQL

Database System Concepts - 7th Edition 4.71 ©Silberschatz, Korth and Sudarshan
 Revoking Authorization in SQL

Database System Concepts - 7th Edition 4.72 ©Silberschatz, Korth and Sudarshan
 Revoking Authorization in SQL

Database System Concepts - 7th Edition 4.73 ©Silberschatz, Korth and Sudarshan
 Roles

 A role is a way to distinguish among various users as far as

what these users can access/update in the database.
 To create a role we use:
create a role <name>
 Example:
 create role instructor
 Once a role is created we can assign “users” to the role
using:
 grant <role> to <users>

Database System Concepts - 7th Edition 4.74 ©Silberschatz, Korth and Sudarshan
 Roles

Database System Concepts - 7th Edition 4.75 ©Silberschatz, Korth and Sudarshan
 Roles Example

 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 - 7th Edition 4.76 ©Silberschatz, Korth and Sudarshan
 Roles Example

Database System Concepts - 7th Edition 4.77 ©Silberschatz, Korth and Sudarshan
 Roles Example

Database System Concepts - 7th Edition 4.78 ©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?
If geo_staff Issues SELECT on geo_instructor:
•If geo_staff has been granted SELECT permission on the geo_instructor view, they can issue the SELECT statement on geo_instructor.
•Regardless of whether geo_staff has direct permissions on the instructor table, as long as they have been explicitly granted SELECT access to the
geo_instructor view, they can retrieve data from that view.

Database System Concepts - 7th Edition 4.79 ©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?
If geo_staff Does Not Have Permissions on instructor:
•If geo_staff does not have direct permissions on the instructor table, they won't be able to access the instructor table directly.
•if they've been granted SELECT permission on the geo_instructor view (which is based on the instructor table), they can retrieve data
from geo_instructor, but they won't be able to access the underlying instructor table directly.

Database System Concepts - 7th Edition 4.80 ©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?
•If the Creator of the View Did Not Have Some Permissions on instructor:
•If the creator of the geo_instructor view lacked some permissions on the instructor table when creating the view, the view creation might
have failed or been incomplete if the permissions were crucial for defining the view.
•In SQL, when creating a view, the user creating the view needs appropriate permissions on the underlying tables to define the view correctly. If
permissions were lacking during creation, it might result in an error or an incomplete/unusable view.

Database System Concepts - 7th Edition 4.81 ©Silberschatz, Korth and Sudarshan
 End of Chapter 4

Database System Concepts - 7th Edition 4.82 ©Silberschatz, Korth and Sudarshan