Top Banner
1 System Aspects of SQL
60
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: System Aspects of SQL 2

1

System Aspects of SQL

Page 2: System Aspects of SQL 2

2

Binding Styles• SQL2 implementations are required to support at least one of the following

seven host languages: ADA, C, Cobol, Fortran, M (Mumps), Pascal, PL/1

• Also, required to support at least one of the following binding-styles– direct SQL (Interactive SQL)

• refers to direct execution of SQL statements from an interactive terminal

– Module • Example

procedure delete_part(SQLSTATE, :PNO_PARAM CHAR(6));Delete from P where P.PNO= :PNO_PARAM;

This procedure can be invoked from host programming as below

…PNO_ARG = ‘p2’;CALL DELETE_PART(retcode, PNO_ARG);…

• Acts as an external procedure that is invoked by host program

– Embedded SQL (ESQL)

Page 3: System Aspects of SQL 2

3

Embedded SQL Approach

• Embed SQL statements directly into the text of host language program– ESQL/C, ESQL/Cobol, etc.

• Mostly commonly used

• Embedded SQL statements are prefixed by EXEC SQL

Host language

Embedded SQL+

Preprocessor

Host language

Function calls+

Host languagecompiler

Host languageprogram

SQL library

Page 4: System Aspects of SQL 2

4

Impedance Mismatch

• Data model of SQL differs from the models of programming languages– SQL uses the relational data model

– C or other program language use a data model with integers, reals, etc., and does not support a notion of set and bag

– a mechanism must be devised to allow the development of programs that use both SQL and another language

• What about a single-language approach ???

• Real database programming requires both SQL and a conventional language (host language)

Page 5: System Aspects of SQL 2

5

The SQL/host language interface

• Transfer of data bet. DBMS and host-language program is through shared variables of the host language– All shared variables are prefixed by a colon when they are referred to by

an SQL statement

– they appear without the colon in host-language statements

• Exception handling– After execution of a SQL statement, certain status code is placed in

special parameters

– Two state codes• SQLCODE of integer type: SQL1

• SQLSTATE of CHAR(5): SQL2

– SQLSTATE• class code: first two characters

• subclass code: the rest three characters

• example: 00000 (successful execution), 02000 (no tuple found)

Page 6: System Aspects of SQL 2

6

The DECLARE section

• EXEC SQL BEGIN DECLARE SECTION;Declaration of shared variables goes here …

EXEC SQL END DECLARE SECTION;

• Example– exec sql begin declare section;

char studioName[15], studioAddr[50];

char sqlstate[6]; // Note, it is of 6 chars

exec sql end declare section;

Page 7: System Aspects of SQL 2

7

Using shared variables

• Any SQL statement that does not return a result can be embedded (e.g. delete- and update-, etc)

– void getStudio() {

exec sql begin declare section;

char studioName[15], studioAddr[50];

char sqlstate[6];

exec sql end declare section;

/* print request that studio name and address be entered and

read response into variables studioName and studioAddr */

exec sql insert into Studio(name, address)

values (:studioName, :studioAddr);}

Page 8: System Aspects of SQL 2

8

Single-row select statements

• select-from-where queries are not directly embeddable due to impedance mismatch– Use shared variable for a query that produces a single tuple (single-row

select)

– Use cursor, otherwise

• Single-row select – SELECT <attribute-name(s)> INTO <shared variable(s)>

FROM <table-name> WHERE <condition>

– If result of the query is either no tuple or more than one tuple, no assignment and appropriate code is written in SQLSTATE

Page 9: System Aspects of SQL 2

9

Example of single-row select statements– void printNetWorth() { /* read the name of a studio and print the

netWorth of the studio’s president */ exec sql begin declare section;

char studioName[15];

int presNetWorth;

char sqlstate[6];

exec sql end declare section;

/* Receive studio name be entered. Read response into studioName*/

exec sql select netWorth into :presNetWorth

from Studio, MovieExec

where presC# = cert# and Studio.name = :studioName;

/* Check SQLSTATE. If all 0’s, print the value of presNetWorth*/}

Page 10: System Aspects of SQL 2

10

Cursor

• To create and use a cursor– Cursor declaration

EXEC SQL DECLARE <cursor_name> CURSOR FOR <query>

• <query> denotes a relation name or a select-from-where expression, whose value is a relation

– EXEC SQL OPEN <cursor_name>

– One or more uses of a fetch statement. EXEC SQL FETCH FROM <cursor_name> INTO <list of varia

bles>

– EXEC SQL CLOSE <cursor_name>

Page 11: System Aspects of SQL 2

11

Cursor Example• #define NO_MORE_TUPLES !(strcmp(SQLSTATE, “02000”))

void worthRanges() {int i, digits, counts[15];exec sql begin declare section;

int worth; char sqlstate[6];exec sql end declare section;exec sql declare execCursor cursor for

select netWorth from MovieExec;for (i = 0; i < 15; i++) counts[i] = 0;exec sql open execCursor;while (1) {exec sql fetch from execCursor into :worth;

if (NO_MORE_TUPLES) break;digits = 1;while (worth /= 10) > 0) digits++;if (digits <= 14) counts[digits]++;

}exec sql close execCursor;for (i = 0; i < 15; i++) printf(“digits = %d: number of execs = %d\n”, i, counts[i]);

}

Page 12: System Aspects of SQL 2

12

Modifications by cursor– void changeWorth() {

exec sql begin declare section; int worth; char sqlstate[6]; exec sql end declare section;

exec sql declare execCursor cursor for select netWorth from MovieExec;exec sql open execCursor;while (1) {

exec sql fetch from execCursor into :worth; if (NO_MORE_TUPLES) break; if (worth < 1000)

exec sql delete from MovieExec where current of execCursor;

else exec sql update MovieExec set netWorth = 2 * netWorth where current of execCursor;

} exec sql close execCursor; }

Page 13: System Aspects of SQL 2

13

Cursor options

• SQL2 offers a variety of options for cursors

• Summary:– the order in which tuples are fetched from the relation can be specified

– the effect of changes to the relation that the cursor ranges over can be limited

– the motion of the cursor through the list of tuples can be varied

Page 14: System Aspects of SQL 2

14

Ordering tuples for fetching

• To specify an order, use ORDER BY

– Exec sql declare movieStarCursor cursor for

select title, year, studio, starName

from Movie, StarsIn

where title = movieTitle and year = movieYear

order by year, title;

Page 15: System Aspects of SQL 2

15

What is correct behavior of myCursor?– int sumyear = 0;

exec sql declare myCursor cursor for select year from Movie where length > 100;

exec sql open myCursor;

loop:exec sql fetch from myCursor into :year;If no data found, go to finished;sumyear = sumyear + year;

exec sql delete from Movie where inColor = ‘F’;goto loop;

finished:exec sql close myCursor;compute something … ;

Page 16: System Aspects of SQL 2

16

Cursor sensitivity

• There are three types of cursors– Sensitive cursor

– Insensitive cursor

– Indeterminant cursor

• Insensitive cursor guarantees that the rows seen by the cursor will not be affected by other statement executed as part of the same transaction– Use keyword INSENSITIVE

EXEC SQL DECLARE myCursor INSENSITIVE CURSOR FOR …

– Only read-only cursor can be insensitive

– One way to implement insensitive cursor is to make a temporary table when the cursor is opened

– An absence of INSENSITIVE doesn’t mean that it is sensitive (in SQL2)

• Sensitive cursor will be a part of SQL3

Page 17: System Aspects of SQL 2

17

Read-only cursor

• if you do not have an intention to update relation through cursor, then declare it with “FOR READ ONLY”– An attempt to execute an UPDATE or DELETE through read-only cursor

would cause an error

– Exec sql declare movieStarCursor cursor for

select title, year, studio, starName

from Movie, StarsIn

where title = movieTitle and year = movieYear

order by year, titleFOR READ ONLY;

Page 18: System Aspects of SQL 2

18

Scrolling cursors

• When there are other orders in which tuples may be fetched, declare the cursor with SCROLL– Put the keyword SCROLL before the keyword CURSOR

– in a FETCH statement, follow the keyword FETCH by one of several options

• NEXT or PRIOR.

• FIRST or LAST

• RELATIVE followed by a positive or negative integer

• ABSOLUTE followed by a positive or negative integer

Page 19: System Aspects of SQL 2

19

Scrolling cursor example

– exec sql declare execCursor SCROLL cursor for

select netWorth from MovieExec;exec sql open execCursor;

exec sql fetch LAST from execCursor into :worth;

while(1) {

/* same as before form */

exec sql fetch prior from execCursor into :worth;}…

– exec sql fetch ABSOLUTE -3 from execCursor;

– exec sql fetch RELATIVE 4 from execCursor;

Page 20: System Aspects of SQL 2

20

Dynamic SQL• For some applications, it is much more convenient to construct parts of the

SQL query dynamically (i.e. at run time) and then to bind and execute them dynamically

– Such statements are not known at compile time, hence cannot be handled by an SQL preprocessor or a host-language compiler

• Possible applications

– ad hoc query utilities

– natural language interface

– on-line applications

– database design tools

Page 21: System Aspects of SQL 2

21

PREPARE statements

• Steps in dynamic SQL– Generate the necessary SQL statements dynamically (i.e. at run time, on

an “as-needed” basis)

– Compile (prepare) such statements dynamically by invoking the SQL compiler at run time

– Execute the newly compiled statements when necessary

• PREPARE statement

– Takes the source statement and prepares (i.e. compiles) it to produce an executable version

– May have placeholders

– Two modes: local, global• local: belong to the module containing the PREPARE statement

• global: belongs to SQL-session module

Page 22: System Aspects of SQL 2

22

EXECUTE statements

• EXECUTE statement

– Executes the prepared statement actually

– ExampleSQLSOURCE = ‘DELETE FROM SP WHERE QTY > ?’;

EXEC SQL PREPARE X FROM :SQLSOURCE;

ARG = 100;

EXEC SQL EXECUTE X USING :ARG;

• EXECUTE IMMEDIATE statement– Combines PREPARE and EXECUTE

– Doesn’t contain any placeholder

– Used when it is executed only once

Page 23: System Aspects of SQL 2

23

Dynamic SQL example

– void readQuery() {

exec sql begin declare section;

char *query;

exec sql end declare section;

/* prompt user for a query, allocate space (e.g., use malloc) and make shared variable :query point to the first character of the query */

exec sql prepare SQLquery from :query;

exec sql execute SQLquery;

}

Page 24: System Aspects of SQL 2

24

SQL Descriptor Area (1)

• An memory area that is used to transfer the input parameter or output parameter when the dynamic SQL statement is executed

• Generally speaking, SQLDA describes– a column of the table that results from executing some prepared statement

– an argument to replace some placeholder in some prepared statement

• Standard SQLDA is encapsulated; the internal structure is not visible to the user, and is not explicitly specified in the standard

Page 25: System Aspects of SQL 2

25

SQL Descriptor Area (2)

• relevant SQL statement– ALLOCATE DESCRIPTOR

– DEALLOCATE DESCRIPTOR

– DESCRIBE statement• to place descriptor information for the prepared statement into some specified

SQL descriptor area

• GET DESCRIPTOR statement

• SET DESCRIPTOR statement

Page 26: System Aspects of SQL 2

26

Transaction• a sequence of database operations that have ACID properties

• syntax in ESQL/C– start: most (but not all) SQL statements

– not transaction-initiating statements• CONNECT, DISCONNECT stmt

• SET stmt

• COMMIT, ROLLBACK

• DECLARE stmts

• GET DIAGNOSTICS

– end: COMMIT WORK, ROLLBACK WORK

• COMMIT– indicates successful end of a transaction

– all effects must be made permanently

• ROLLBACK– indicates abnormal termination of a transaction

– all effects must be obliterated

Page 27: System Aspects of SQL 2

27

Properties of a transaction: ACID

• atomicity– either all actions in a transaction occur successfully or nothing has

happened (all-or-nothing property)

• consistency– assumes that any successful transaction commits only legal result

– a transaction is a correct transformation of the state, i.e. from one valid state to another valid state

• isolation– events within a transaction must be hidden from other transaction running

concurrently

– the actions carried out by a transaction against a shared database cannot become visible to other transitions until the transaction commits

• durability– once a transaction has completed and has committed, the system must

guarantee that these results survive any subsequent failures

Page 28: System Aspects of SQL 2

28

Problems with nonserializable execution

• There are three cases in which nonserializable execution causes problems, concurrency anomalies

• dirty read– T2 has seen dirty data

• lost update– Effect (i.e. update)

of T2 is lost

• unrepeatable read

T1 T2UPDATE (A)

READ (A)A = A + 50WRITE (A)

ROLLBACK

T1 T2READ(A)A = A + 50

READ (A)A = A + 50WRITE (A)

WRITE (A)

T1 T2READ (A)

A = A + 50WRITE (A)

READ (A)

Page 29: System Aspects of SQL 2

29

Transaction in ESQL/C

exec sql begin declare section;int acct1, acct2; /* the two accounts */int balance1; /* the amount of money in the first account */int account; /* the amount of money to transfer */

exec sql end declare section;

void transfer() { /* C code to prompt the user to enter accounts 1 and 2 and an amount of

money to transfer, in variables acct1, acc2, and amount */ exec sql select balance into :balance1 from Accounts where acctNo = :acct1; if (balance1 >= amount) { exec sql update Accounts set balance = balance + :amount where acctNo = :acct2; exec sql update Accounts set balance = balance - :amount where acctNo = :acct1; exec sql commit; } else exec sql rollback; }

Page 30: System Aspects of SQL 2

30

Serial vs. serializable

• A complete history H is serial if, for every two transaction Ti and Tj that appear in H, either all operations of Ti appear before all operations of Tj or vice versa

– there is no interleaving of operations of different transactions

• A history H is serializable if its committed projection is equivalent to a serial history

Page 31: System Aspects of SQL 2

31

Why concurrency control?

• To provide a transaction with ACID properties– give each transaction the impression “there are no concurrent updates”

– hide concurrency anomalies

• Goal– Generate serializable executions only

• Concurrency control techniques– Locking

– Timestamps

– Multiversioning

– Optimistic approach

Page 32: System Aspects of SQL 2

32

Practice and theory

• Surprisingly, most systems do not provide true isolation!

• A compromise between correctness and performance

• Degree of isolation – degree 0: a degree-0 transaction does not overwrite another transaction’s

dirty data if the other transaction is degree-1 or greater

– degree 1: a degree-1 transaction has no lost updates

– degree 2: a degree-2 transaction has no lost updates and no dirty reads

– degree 3: a degree-3 transaction has no lost updates, no dirty reads, and repeatable read

• Most SQL system defaults to degree-2 and allow forms of degree-1 or degree-3

Page 33: System Aspects of SQL 2

33

Isolation degreeissue degree 0 degree 1 degree 2 degree 3

Commonname

chaos browse cursor stabilityisolated

serializablerepeatable read

Protectionprovided

lets others runat higherisolation

0 and no lostupdates

1 + no dirtyread

2 + repeatableread

Committeddata

writes visibleimmediately

writes visibleat EOT

same same

Dirty datayou don’t

overwrite dirtydata

0 and othersdon’t

overwrite yourdirty data

0, 1 and youdon’t readdirty data

0, 1, 2 andothers don’t

dirty data youread

Lockprotocol

set shortexclusive locks

on data youwrite

set longexclusive

locks on datayou write

1 and set shortshare locks ondata you read

1 and set longshare locks ondata you read

Concurrencygreatest: onlyset short write

locks

great: onlywait for write

locks

medium: holdfew read locks

lowest: any datatouched locked

to EOT

Page 34: System Aspects of SQL 2

34

Isolation theorem

• Isolation theorem: if a transaction observes the degree-1,2,3 lock protocol, then any legal history will give that transaction degree-1,2,3 isolation respectively as long as other transactions are at least degree-1

• Implication: each user can select the isolation degree appropriate to his transaction without causing other concurrent transactions to malfunction with inconsistent inputs, as long as everybody runs at degree-1or higher

• degree-1:– read dirty data!

– Usually for read-only transactions (e.g. UPDATE STATISTICS stmt)

Page 35: System Aspects of SQL 2

35

Transaction isolation in SQL2

• SET TRANSACTION [READ ONLY | READ WRITE] ISOLATION LEVEL …

– read uncommitted: degree-1

– read committed: degree-2

– repeatable read: degree-2.99 (degree-3 except phantom)

– serializable: degree-3

• Default values– READ WRITE

– SERIALIZABLE

– In case of READ UNCOMMITTED, READ ONLY

Page 36: System Aspects of SQL 2

36

Difference of isolation

• Transaction approach– Find an available seat and reserve it by setting occupied to 1

If none, abort– Ask the customer for approval. If so, commit. If not, release the seat by

setting occupied to 0 and repeat step 1 to get another seat

• Read Uncommitted– A transaction may be notified that all seats are booked up, but seats will be

released later.

• Read Committed– It may see a different set of available seats each time it queries, as other

transactions successfully book seats or cancel seats in parallel

• Repeatable read– A seat that is available on the first query at step 1 will remain available at

subsequent queries– If new seats are created during execution, a subsequent query for available

seats may also retrieve the new seats

Page 37: System Aspects of SQL 2

37

SQL environment

• SQL environment– A particular instance of a particular SQL DBMS with the collection of all

databases and the collection of all users and programs

Schema

Schema

Catalog

Environment =Installation of DBMS

Catalog

CatalogCluster =maximum scopeof a DB operation

Page 38: System Aspects of SQL 2

38

Schema

• A named collection of “descriptors” within a catalog

• SQL objects (such as base tables, views, integrity constraints, etc.) are always created within the context of some particular schema – domain descriptor

– base table descriptor

– view descriptor

– constraint descriptor

– privilege descriptor

– character set descriptor

– collation descriptor

– translation descriptor

• CREATE/DROP/SET SCHEMA statement

Page 39: System Aspects of SQL 2

39

Create schema statement

• CREATE SCHEMA [schema_name] [AUTHORIZATION user][DEFAULT CHARACTER SET character-set][schema-element-list];– [AUTHORIZATION user] : denotes owner of new schema

– The possible “schema elements’ are:• domain definitions

• base table definitions

• view definitions

• grant statements

• constraint definitions

• character set definitions

• collation definitions

• translation definitions

Page 40: System Aspects of SQL 2

40

Example of schema creation

– CREATE SCHEMA MovieSchema

CREATE DOMAIN CertDomain …

other domain declarations

CREATE TABLE MovieStar …

create-table statements for the four other tables

CREATE VIEW MovieProd …

other view declarations

CREATE ASSERTION RichPres ...

Page 41: System Aspects of SQL 2

41

Drop schema statement

• Not necessary to declare the schema all at once– One can modify or add to a schema using the appropriate CREATE,

DROP, ALTER statement

• One problem is that the SQL system needs to know to which schema the new table belongs

• To change the “current” schema, use SET SCHEMA statement– SET SCHMA <schema-name>;

• To drop schema– DROP SCHEMA schema {RESTRICT | CASCADE};

• RESTRICT: the operation will fail unless the specified schema is empty (i.e., contains no descriptor)

• CASCADE: the operation will succeed, and drop not only the specified schema per se but also all objects contained in that schema

Page 42: System Aspects of SQL 2

42

Catalog, cluster

• Cluster– A collection of catalogs

– Maximum scope over which a query can be issued• SQL operations are not allowed to span clusters

– Each SQL-session has exactly one associated cluster

– SQL2 is not very precise about what a cluster is

• Catalog – A named collection of schema within an SQL environment

– Each catalog contains a special schema INFORMATION_SCHEMA that contains information about all the schemas in the catalog

– No explicit mechanism for creating and dropping catalogs in SQL2, i.e. implementation-dependent

• CREATE CATALOG <catalog name>

– SET CATALOG <catalog name>

Page 43: System Aspects of SQL 2

43

Clients and servers in the SQL environment

• Within an SQL environment are two special kinds of processes:– SQL server: supports operations on the database elements

– SQL client: allows a user to connect to a server

• A module is the SQL2 term for an application program

• An execution of a module is called an SQL agent

SQL-agent Module

SQL-client SQL-serverConnection

Session

Environment

Page 44: System Aspects of SQL 2

44

SQL-Connection

• In order to perform any database operation, the SQL-agent must first cause the SQL-client to establish an SQL-connection to some SQL-server – by executing an (implicit or explicit) CONNECT statement

• SQL-connection also initiates an SQL-session over SQL-connection

• Each session has a current catalog and a current schema within that catalog

• SQL-agent can establish any number of SQL-connections, and thus initiate any number of SQL-sessions

Page 45: System Aspects of SQL 2

45

CONNECT statements• Connection manipulation

– CONNECT statement

– SET CONNECTION statement

– DISCONNECT statement

• CONNECT statement– CONNECT TO {DEFAULT | server_name [AS connection_name]

[USER string3]};

– DEFAULT: an SQL-connection is established to a ‘”default SQL-server”

Page 46: System Aspects of SQL 2

46

DISCONNECT statement

• SQL2 allows several connections to be opened by the user, but only one can be active at any time

• To switch among connections – SET CONNECTION {DEFAULT | string};

• To drop the connection,– DISCONNECT {DEFAULT | CURRENT | ALL | string}

• DEFAULT : the default SQL-connection is terminated

• CURRENT : the current SQL-connection is terminated

• ALL : the current SQL-connection (if any) and all dormant SQL-connections (if any) are terminated

Page 47: System Aspects of SQL 2

47

Session

• The SQL operations that are performed while a connection is active form a session

• the session is coextensive with the connection that created it– An SQL-session takes place in when the necessary SQL-connection is esta

blished and terminates when the last SQL-statement or the DISCONNECT statement is executed

• Each session has a number of associated default values– a default authorization identifier

– a default catalog name

– a default schema name

– a default time zone

– a default character set name

Page 48: System Aspects of SQL 2

48

Session-related statements

• session manipulation– SET SESSION AUTHORIZATION statement

– SET CATALOG statement

– SET SCHEMA statement

– SET TIME ZONE statement

– SET NAMES statement

Page 49: System Aspects of SQL 2

49

Security and user authorization in SQL2

• SQL2 postulates authorization ID

• A special ID PUBLIC which includes any user

• authorization vs. authentication

• SQL objects to be protected– table, column, view, domain, character set, collation, translation

Page 50: System Aspects of SQL 2

50

Privileges

• Six types of privileges– SELECT, INSERT, DELETE, UPDATE, REFERENCES, USAGE

– The REFERENCES privilege is the right to refer to the relation in an integrity constraints.

– The USAGE privilege on a domain, or on several other kind of schema elements other than relations and assertions, is the right to use that element in one’s own declarations

• domain, character, collation, translation

– The INSERT, UPDATE and REFERENCES privileges may also be given a single attribute as an argument.

Page 51: System Aspects of SQL 2

51

Privilege example

– Insert into Studio(name) select distinct studioName

from Movie

where studioName not in

(select name

from Studio);

– the INSERT privilege on either Studio or attribute name of the Studio(name)

– the SELECT privileges on Movie and Studio

Page 52: System Aspects of SQL 2

52

Creating privileges

• SQL elements such as schemas or modules has an owner

• There are three points at which ownership is established in SQL2– when a schema is created

– When a session is initiated by a CONNECT statement• connect to Startfleet-sql-server AS conn1 user kirk;

– when a module is created• authorization picard;

Page 53: System Aspects of SQL 2

53

The privilege-checking process

• Any SQL operation has two parties– the database elements upon which the operation is performed

– the agent that causes the operation

• The privileges available to the agent derive from a particular authorization ID called the current authorization ID– The module authorization ID if the module has an authorization ID

– The session authorization ID if not

• SQL operation may be executed only if the current authorization ID possesses all the privileges needed to carry out the operation

Page 54: System Aspects of SQL 2

54

Granting privileges

• SQL2 provides a GRANT statement to allow one user to give a privilege to another.

• GRANT <privilege list> ON <database element> TO <user list>[WITH GRANT OPTION];– <privilege list>

• SELECT, INSERT(name), etc.

• ALL PRIVILEGES

– <user list>• list of one or more authorization IDs

– WITH GRAND OPTION

Page 55: System Aspects of SQL 2

55

Example of Grant statements– Movie (title, year, length, inColor, studioName, producerC#)

Studio (name, address, presC#)

– User “Janeway” is the owner • grant select, insert on Studio to kirk, picard with grant option;

• grant select on Movie to kirk, picard with grant option

– “picard” grants to user “sisko” • grant select, insert on Studio to sisko;

• grant select on Movie to sisko;

– “kirk” grants to “sisko” • grant select, insert(name) on Studio to sisko;

• grant select on Movie to sisko;

Page 56: System Aspects of SQL 2

56

Grant diagrams

– “*” indicates the grant option

– “**” indicates ownership of the database element

JanewaySELECTon Movie

**

JanewayINSERTon Movie

**

JanewayINSERTon Studio

**

JanewaySELECTon Studio

**

KirkINSERTon Studio

*

KirkSELECTon Studio

*

KirkSELECTon Movie

*

SiskoINSERT (name)

on Studio

SiskoINSERTon Studio

SiskoSELECTon Movie

SiskoSELECTon Studio

PicardSELECTon Movie

*

PicardSELECTon Studio

*

PicardINSERTon Studio

*

Page 57: System Aspects of SQL 2

57

Revoking privileges

• A granted privilege can be revoked at any time– REVOKE <privilege list> ON <database element> FROM <user list>

[CASCADE | RESTRICT];

– CASCADE:

– RESTRICT: • the revoke statement cannot be executed if the cascading rule described in the

previous item would result in the revoking of any privileges due to the revoked privileges having been passed on to others

– REVOKE GRANT OPTION FOR instead of REVOKE• the privileges themselves remain

• the option to grant them to others is removed.

Page 58: System Aspects of SQL 2

58

Example of revoking privileges– Revoke select, insert on Studio from picard cascade;

Revoke select on Movie from picard cascade;

JanewaySELECTon Movie

**

JanewayINSERTon Movie

**

JanewayINSERTon Studio

**

JanewaySELECTon Studio

**

KirkINSERTon Studio

*

KirkSELECTon Studio

*

KirkSELECTon Movie

*

SiskoINSERT (name)

on Studio

SiskoINSERTon Studio

SiskoSELECTon Movie

SiskoSELECTon Studio

Page 59: System Aspects of SQL 2

59

Example

Step By Action1 U grant insert on R to V2 U grant insert (A) on R to V3 U revoke insert on R from V restrict

UINSERT

on R**

VINSERT(A)

on R

VINSERT

on R

After step (2)

UINSERT

on R**

VINSERT(A)

on R

After step (3)

Page 60: System Aspects of SQL 2

60

Another example

Step By Action1 U grant p to V with grant option2 V grant p to W3 U revoke grant option for p from V cascade

Up**

Vp*

Wp

Up**

Vp

After step (2) After step (3)