System Aspects of SQL 2

Preview:

Citation preview

1

System Aspects of SQL

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)

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

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)

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)

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;

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);}

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

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*/}

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>

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]);

}

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; }

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

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;

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 … ;

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

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;

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

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;

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

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

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

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;

}

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

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

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

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

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)

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; }

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

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

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

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

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)

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

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

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

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

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

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

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

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>

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

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

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”

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

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

48

Session-related statements

• session manipulation– SET SESSION AUTHORIZATION statement

– SET CATALOG statement

– SET SCHEMA statement

– SET TIME ZONE statement

– SET NAMES statement

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

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.

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

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;

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

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

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;

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

*

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.

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

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)

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)

Recommended