Database Systems - SQL - DCL Statements (Chapter 3/4)

Editor's Notes

• #2: DCL Statements of SQL In this section we talk about Data Control Language statements of SQL. These statements are categorized into connection management statements, transaction management statements, access control statements and session management statements. In this section you will learn the following concepts along with various DCL statements: Connecting to databases Meaning of Transaction Transaction Phenomena Transaction Isolation Level Starting a transaction Making changes of a transaction permanent Undoing changes of a transaction Setting characteristics of a transaction Deferring execution of constraints to the end of a transaction Access Privileges Authorization Identifier Granting and revoking privileges
• #3: DCL Statements of SQL: The DCL statements are used for the following purpose: Connection management Transaction management Access control Session management Connection management statements are used to connect to a database, change connection to another database and disconnect from the database. Transaction management statements are used make current changes to the database permanent or undo the changes, to control granularity of transactions and isolation level of a transaction from other transactions. Access control statements are used to control access to the databases by various users. It has statements to give permissions to users and take away them from the users. Session management statements are used to change characteristics of a user session with an RDBMS. As the statements specified in SQL standard are not implemented by most of the RDBMSs, these statements will not be discussed further.
• #4: Data Control Language: Connection Management The connection management statements are used manage connections to an RDBMS. The connections are usually in the context of a database. In some cases, RDBMSs do allow connections without specifying a database name but to set to required database after a connection is made. We will study more about connection management in the next set of slides.
• #5: The connection management statements are: CONNECT statement SET CONNECTION statement DISCONNECT statement The CONNECT statement is used to connection to an RDBMS and/or a database so that you can execute many other SQL statements. The SET CONNECT statement allows you to connect to another database with the current user credentials or with another user credentials. The DISCONNECT statement allows you disconnect from current database connection. You execute this statement once you no longer wish to work current database. Various RDBMSs either implement these statements in their own way or do not implement these statements but some other statements. Hence we do not cover the SQL standard syntax here. Rather we cover syntax used to connect to databases using command line tools provided by MySQL. Connection management from applications using various drivers such as ODBC driver, JDBC driver or .NET data provider is fairly standard across many RDBMSs. We will study about the connection management when we cover the drivers.
• #6: Connection Management with MySQL: Connecting to MySQL server: mysql is a command line tool for MySQL RDBMS for executing SQL statements. Options -?, -I or --help all show help on the command line tool itself. There are quite a few options you can pass to the tool. Use –h option to connect to a MySQL server that runs on a different computer. host-name is the name of computer associated with its IP address. Use –u option to specify the name of MySQL user. The user name is “root” in case you are the super user. The users who can use MySQL should have user names created in MySQL by its administrator. Use –p to specify password. The tool will prompt for a password and if the entered password is correct, it will display a prompt “mysql>” for you to enter and execute any SQL statements. Use option --password if you want to specify password on the command line itself. db-name is the name of the database you want to use. If you do not specify a database name on the command line you can always execute a command called USE to specify name of the database you want to use once the login into MySQL is successful.
• #7: Connection Management with MySQL:Examples The first screenshot shows user “root” logged into MySQL using command line tool “mysql”, executed a command USE to use database “schdb” and exited from the tool. The second screenshot shows that user “root” specified database name “schdb” on the command line tool itself and hence no need to execute USE command explicitly to use the database.
• #8: Connection Management with MySQL: Examples The first screenshot shows how a super user can create a login information for a user to use a database. The super user or root user “root” logged into MySQL server without specifying any database name, created a user “suri” with password “suri123”, gave SELECT privilege on all tables of database “schdb” and exited from the command line tool. Without the SELECT privilege the new user will not be able to login into the database directly, i.e., by specifying database name on the command line. The second screenshot shows user “suri” logged into database “schdb” by specifying password on the command line of mysql itself, accessed a table “dept” and exited the tool.
• #9: Connection Management with MySQL: Connection Errors The screenshot shows that user can not use a database if he does not have privileges. With --password the login itself fails. First, the super user “root” logs into the MySQL server, revokes SELECT privilege on database “schdb” from user “suri”. Hence login of the user “suri” fails when the database name is specified on the mysql command line. Surprisingly mysql command did not allow the user to login with --password option even without specifying database name on the command line. However, user could login into the server with –p option but could not use the database as he does not have any privilege.
• #10: Data Control Language: Transaction Management The transaction management is very critical for any RDBMS. In this subsection you will learn the following concepts along with the DCL statements: What is a Transaction? Transaction Statements Transaction Phenomena Isolation Level Transaction Characteristics Deferring Execution of Constraints
• #11: What is a Transaction?: An SQL Transaction is a logical unit of work consisting of one or more SQL statements. The intention is that the database will be in a consistent state only if all statements of the transaction are executed successfully. If any one of the statements of a transaction results in execution error, effect of all previous statements that were successfully executed is undone and the database is brought back to the same state as it was before starting the transaction so that the database is always in a consistent state. Hence each SQL transaction is atomic, i.e., it works like a single operation though the transaction consists of usually more than one SQL statement. This is very important feature required for any database management system. For example if a bank customer has to transfer money from his account to some other account, the database application that allows the transfer functionality has to execute at least two statements: one statement to reduce the bank balance of the customer by the transfer amount and the second statement to add the transfer amount to the other account. In this case both statements are going to be DML statement UPDATE. If the transfer operation is not in a transaction, the customer will loose money if the first statement execution is successful but the second statement execution fails. The statement execution may fail for many reasons. Some of them are lost connectivity between the application and the database server, crash of the application, crash of the database server and crash of the computer itself. Hence, the transfer functionality has to be implemented as a transaction to avoid the problem of customer loosing the money in this example. Transactions begin automatically by the first SELECT, INSERT, UPDATE or DELETE statement or explicitly by START TRANSACTION statement. Transactions are completed using COMMIT statement. If the transaction has to be aborted and the database has to be brought back to the state before the transaction started for any reason the ROLLBACK statement has to be executed.
• #12: Transaction Examples: The slide shows two transactions. The first transaction starts with a SELECT statement and ends with COMMIT statement. The second transaction starts with the SELECT statement that is at the end of the slide. The first transactions selects eno, ename and salary columns of table emp. The salary is NULL for both employees. The first UPDATE statement updates salary of two employees having eno 555 and 556 with Rs 15000. The second UPDATE statement increases salary of an employee by 10% and commits the transaction. The second transaction shows the salaries of the two employees. This transaction is not yet completed.
• #13: DCL Transaction Management statements: The transaction management statements are as follows: START TRANSACTION COMMIT statement ROLLBACK statement SET TRANSACTION statement SET CONSTRAINTS statement
• #14: DCL Transaction Management statements: START TRANSACTION The START TRANSACTION statement starts a new transaction and sets its characteristics. It is an error to execute the statement while a transaction is already in progress. The READ ONLY option allows the transaction to execute only those SQL statements that do not modify database contents. Execution of statements such as INSERT, UPDATE or DELETE result in error. The READ WRITE option allows the transactions to read from the database as well as write to the database. It means all kinds of SQL statements can be executed. This is default. The ISOLATION LEVEL option defines how much level the transaction is isolated from other transactions with respect to the data the current transaction can access and the changes it can see of the changes done by other transactions. We will discuss more about the isolation level in the next set of slides. The DIAGNOSTICS SIZE option is used to specify size of the diagnostics area for the transaction for it store errors and other status information. ncond is a number 1 or greater that indicates the number of status or error information the transaction can store.
• #15: TRANSACTION ISOLATION LEVEL: Transaction Phenomena Whenever there are concurrent transactions, i.e., transactions being executed simultaneously, for example, transactions created by actions such as checking bank balances, withdrawing money, transfer money and pay money for purchases by various people through internet banking applications, one can see three kinds of phenomena depending on the isolation level used by the applications. These are as follows: Dirty read Non-repeatable read Phantom read
• #16: Here are the three phenomena that can occur with concurrent transactions: Dirty Read: Transaction T1 reads a row that has been changed by another transaction T2 which has not yet committed. If T2 rolls back the transaction, T1 will have read the data that never existed. This means transaction T1 did a dirty read. Non-repeatable Read: Transaction T1 reads a row. Transaction T2 then modifies or deletes that row and performs a COMMIT. If T1 then attempts to reread the row, it may receive the modified value or discover that the row has been deleted. This means T1 did a non-repeatable read. Phantom read: Transaction T1 reads a set of rows N that satisfy some search condition. Transaction T2 then executes SQL-statements that generate one or more rows that satisfy the search condition used by transaction T1. If transaction T1 then repeats the initial read with the same search condition, it obtains a different collection of rows. This means T1 experienced phantom read.
• #17: TRANSACTION ISOLATION LEVEL Versus PHENOMENA: The kind of phenomena that can occur depending on the isolation level you set for transactions using SET TRANSACTION ISOLATION LEVEL statement is shown in a table in the slide. If a transaction isolation level is set to READ UNCOMMITTED, all three phenomena – dirty read, non-repeatable read and phantom read - can occur. This means the transaction can get to read data that is not yet committed. If a transaction isolation level is set to READ COMMITTED, dirty-reads are not possible because it reads only committed data. However, non-repeatable and phantom reads can occur. If a transaction isolation level is set to REPEATABLE READ, only phantom reads can occur. It means the transaction can see some new rows or find that some old rows do not exist any more if same query is executed again. If a transaction isolation level is set to SERIALIZABLE, none of the phenomena will occur. It means the transaction is completely isolated from changes being done by other transactions.
• #18: DCL Transaction Management statements: COMMIT The COMMIT statement ends a transaction successfully by making database changes permanent. Syntax: COMMIT [ WORK ] The keyword WORK is optional. Once the statement is executed by an RDBMS (server), all database changes done by all other DDL or DML statements executed before the COMMIT statement are made permanent by the RDBMS.
• #19: DCL Transaction Management statements: ROLLBACK The ROLLBACK statement aborts a transaction by backing out all changes done in the transaction. Syntax: ROLLBACK [ WORK ] The keyword WORK is optional. Once the statement is executed by an RDBMS (server), all database changes done by all other DDL or DML statements executed before the ROLLBACK statement are backed out or undone by the RDBMS and the database is brought back to the state it was before starting of the transaction.
• #20: DCL Transaction Management statements: SET TRANSACTION The SET TRANSACTION statement sets characteristics of transactions that are going to be created after the statement is executed. It is an error to execute the statement while a transaction is in progress. The statement options are same as those that are available with START TRANSACTION statement.
• #21: DCL Transaction Management statements: SET CONSTRAINTS The SET CONSTRAINT statement is used to specify whether an integrity constraint has to be validated every time an SQL statement of a transaction is executed (IMMEDIATE) or whether it should be deferred till the end of the transaction (DEFERRED). This command is particularly useful when you have to execute statement to INSERT or UPDATE data into set of tables that have circular integrity constraint references. For example, employee table may have a foreign key on department number column of department table as each employee is expected to work in a department. The departments table also may have a reference to employee number of employee table as an employee has to be designated as manager of a department and hence need to store employee number of the manager employee in the departments table. Hence, you can not enter an employee row in employees table unless there is a row for the department with a manager. Similarly you can not enter a department rows unless there is a manager employee in the employees table. In such cases, you can defer the execution of the integrity constraints using SET CONSTRAINTS statement. The deferred constraints will be executed when a transaction is committed using COMMIT statement. It is possible to defer only specific constraints by specifying the constraint names on the SET command line instead of using key word ALL which means all constraints.
• #22: SET CONSTRAINTS EXAMPLE Schema: The slide shows a schema we use to show how SET CONSTRAINTS statement works. The first table is emptbl containing 3 columns eno, ename, dno for storing employee number, employee name and department number. The second table is depttbl containing 3 columns dno, dname, mno for storing department number, department name and manager employee number. A foreign key constraint dept_mno_fk is defined on mno column to refer to eno of emptbl. The ALTER statement defines a constraint on emptbl on column dno to refer to dno column of depttbl because any department number stored in emptbl should correspond to department number that exists in the depttbl. It is important to note that we specified both constraints as DEFERRABLE.
• #23: SET CONSTRAINTS EXAMPLE: INSERT Operation The first SQL command line window shows that INSERT statement execution failed on both tables emptbl and depttbl due to circular reference of foreign keys. Hence, SET CONSTRAINTS statement with DEFERRED operation was executed to defer validation of integrity constraints at the time of commit operation. After this, re-execution of the first two INSERT statements was successful. COMMIT also executed successfully because the row added to emptbl as well as the row added to depttbl satisfy both constraints. The second command window in the slide shows the contents of both tables are as expected. Note that the screenshots show Oracle SQLPLUS command line tool and not MySQL.
• #24: Access Control: In this section, we discuss SQL statements used to control access to database objects. You will learn the following concepts along with the related statements: Access Control Statements Authorization Identifier Privileges Granting and Revoking Privileges
• #25: Access control statements: SQL supports discretionary data access control through the following statements: GRANT REVOKE What it means is that users get certain powers when they create database objects such as tables, domains, etc. Users who own the database objects can grant privileges at their own discretion to other users for using the database objects. GRANT: The statement is used to give privileges to other users. REVOKE: The statement is used to take away already given privileges from the users.
• #26: ACCESS CONTROL: Authorization Identifiers An authorization identifier is an SQL identifier used to identify a database user. Examples: john, praveen, akhilm, user1 Each authorization identifier is usually associated with a password. Every SQL statement executed by the RDBMS on behalf of specific user. RDBMS uses authorization identifier to determine if the user has access to a database object and if so what kind access rights or privileges the user has. An authorization identifier is essentially a user ID or login ID used to login into a database or an RDBMS. Your super user or another designated user with special privileges can create authorization identifiers for other users. Note that the RDBMS SQLite does not have any support for authorization identifiers as it is a single user RDBMS.
• #27: ACCESS CONTROL: Privileges The privileges are permissions that decide what action a user can perform on a database table or view. The name of the privilege itself is an SQL key word taken from DDL and DML statements and hence denotes what kind of operation one can do with the privilege. Here is the list of privileges defined in SQL standard: SELECT: The SELECT privilege on a table given to a user allows the user to execute SELECT statements to retrieve rows from the table. INSERT: The INSERT privilege on a table given to a user allows the user to execute INSERT statements to insert rows into the table. UPDATE: The UPDATE privilege on a table given to a user allows the user to execute UPDATE statements to modify rows in the table. DELETE: The DELETE privilege on a table given to a user allows the user to execute DELETE statements to delete rows from the table. REFERENCES: The REFERENCES privilege on a table given to a user allows the user to reference columns of the table in integrity constraints defined in other tables. USAGE: The USAGE privilege on domains, collations, character sets and translations given to a user allows the user to use them in other definitions such as those of tables. EXECUTE: The EXECUTE privilege on stored procedure or functions given to a user allows the user to execute them. Note:- The privileges specified in the slide are the most commonly implemented privileges. SQL Standard defines some more privileges and some RDBMSs may implement less number or more number of privileges specified in the slide.
• #28: ACCESS CONTROL: GRANT statement. The GRANT statement grants specified privileges on specified database objects to specified users. To avoid confusion on the term user, we use the following terms: Grantor: The user who is granting the privileges by executing the GRANT statement. Grantee: The user to whom the grantor is giving the privileges. These are the user IDs present in the authorization ID list (auth_id_list). privilege_list: This is a list of one or more privileges. In case of SELECT, INSERT, UPDATE , REFERENCES privileges, the privilege can be followed by one or more columns. The user to whom the privilege is given will be able to do the specified operation SELECT, INSERT, UPDATE or REFERENCE involving only the specified columns. For example, if UPDATE privilege is given on specific columns, the user can update only those columns and not any other column of the table. ALL PRIVILEGES: This denotes all privileges, i.e., SELECT, INSERT, UPDATE, DELETE, REFERENCES , USAGE, TRIGGER and EXECUTE. object_name: The object name is a table or view in case of privileges SELECT, INSERT, UPDATE, DELETE and REFERENCES. It is domain name, collation name, character set name or translation name in case the privilege is USAGE. auth_id_list: This is a list of authorization identifiers or login user names (grantees) to whom the privileges are being given by grantor. col_name_list: List of names of columns of a table or view. PUBLIC: This keyword denotes all users of the RDBMS (present and future). WITH GRANT OPTION: This clause allows grantees to give the same privilege to other users.
• #29: GRANT statement: Users To demonstrate examples of GRANT statement we need a few authorization IDs of users (we refer to these as user names). Item (1) of the slide shows a table of users we are going to use. Here “system” is the user ID of super user. The user has all privileges. The user password is “system123”. We will use two more users with user name “akhil” and “john” with passwords “akhil123” and “john123”. The screen shot shows creation of the user using command “CREATE USER”. The screenshot also shows execution of GRANT statement to give CREATE SESSION privilege to the new users created. This is specific to Oracle and without this privilege, the new users won’t be able to even login into Oracle RDBMS. The screen shot of item (2) shows creation of users “akhil” and “john” using Oracle command line tool SQLPLUS. The screen shot of item (3) shows that the user akhil does not have any privileges to access tables “emptbl” and “depttbl” owned by the user “system”.
• #30: GRANT statement: Examples – Privileges The screen shot 1 shows user system giving SELECT privilege on table emptbl to user akhil and all privileges on depttbl to PUBLIC. The screen shot 2 shows usage of SELECT privilege by john on depttbl. The second select statement shows that john does not have any privilege on emptbl of user system. The screen shot 3 shows exercise of the SELECT privilege by akhil on table emptbl. But the UPDATE statement on the table fails as the user does not have the UPDATE privilege on the table.
• #31: ACCESS CONTROL: REVOKE statement. The REVOKE statement revokes privileges on specified database objects from specified users. The functionality of the statement is exactly opposite of the statement GRANT. To avoid confusion on the term user, we use the following terms: Grantor: The user who granted the privileges by executing the GRANT statement. Grantee: The user to whom the grantor gave the privileges. These are the user IDs present in the authorization ID list (auth_id_list). privilege_list: This is a list of one or more privileges. In case of SELECT, INSERT, UPDATE , REFERENCES privileges, the privilege can be followed by one or more columns. The user to whom the privilege is given will be able to do the specified operation SELECT, INSERT, UPDATE or REFERENCE involving only the specified columns. For example, if UPDATE privilege is given on specific columns, the user can update only those columns and not any other column of the table. ALL PRIVILEGES: This denotes all privileges, i.e., SELECT, INSERT, UPDATE, DELETE, REFERENCES , USAGE, TRIGGER and EXECUTE. object_name: The object name is a table or view in case of privileges SELECT, INSERT, UPDATE, DELETE and REFERENCES. It is domain name, collation name, character set name or translation name in case the privilege is USAGE. auth_id_list: This is a list of authorization identifiers or login user names (grantees) from whom the privileges are being revoked by grantor. col_name_list: List of names of columns of a table or view. PUBLIC: This keyword denotes all users of the RDBMS. GRANT OPTION FOR: This clause allows grantor revoke only the GRANT OPTION for the specified privilege from the grantees. The privilege itself will not be revoked from the grantee. Once the GRANT OPTION is revoked, the grantee will not be able to pass the privileges to others using GRANT statement. RESTRICT: The revoke operation is rejected if there are any other objects that depend on the privilege being revoked. CASCADE: The revoke operation proceeds removing dependent objects.
• #32: REVOKE statement: Examples – Privileges The screen shot of item 1 shows user system revoking SELECT privilege on table emptbl from user akhil and later the user not able to access the table. The screen shots of item 2 show user system revoking UPDATE privilege on table depttbl from PUBLIC. It also shows that the user john able to retrieve data from the table but not able to update any column of the table.
• #33: What Have You Learnt!: Connecting to Databases. How to connect to MySQL Databases. What is a Transaction? When Transactions begin ? Transaction Statements START TRANSACTION, COMMIT and ROLLBACK. SET TRANSACTION and SET CONSTRAINTS statements. Transaction Isolation Levels Transaction Phenomena – Dirty Read, Non-repeatable Read and Phantom Read Access Control, Authorization ID Privileges SELECT, INSERT, UPDATE, DELETE, REFERENCES, USAGE and EXECUTE. Granting and revoking privileges using GRANT and REVOKE statements.