SQL II : Advanced Features and Database Administration

TOPIC 6: ADVANCED SQL AND DATABASE ADMINISTRATION

1

Topic 6

SQL II : Advanced Features and Database Administration Learning Objectives

Be aware of the further features of SQL beyond the DML. Be able to manipulate the database using SQL DDL statements. Understand the diversity of datatypes supported. Understand how and when constraints are tested by the database. Understand how database views can be created and used. Be aware of the role of the database administrator and how that user can control access

to other users. Be aware that all data in and about the database is stored in tables. Be aware of advanced SQL features. Gain further practice in the evaluation and writing of SQL queries.

Contents 6.1 Data Definition Language ............................................................................................................ 4

6.1.1 Creating Tables ..................................................................................................................... 4

6.1.2 Altering Existing Tables ........................................................................................................ 5

6.2 Data Types ................................................................................................................................... 6

6.3 Database Constraints .................................................................................................................. 8

6.4 Views ........................................................................................................................................... 8

6.5 Database Administration .......................................................................................................... 10

6.6 Other Useful Bits of SQL ............................................................................................................ 11

6.7 Advanced SQL Features............................................................................................................. 11

6.7.1 Embedded SQL (E/SQL) ...................................................................................................... 11

6.7.3 Procedural SQL (PL/SQL) .................................................................................................... 13

6.7.4 Transactions ....................................................................................................................... 14


2

6.8 Advanced SQL Tutorial .............................................................................................................. 15

6.8.1 Evaluating Queries ................................................................................................................ 18

6.8.2 Defining Queries ................................................................................................................... 18

6.8.3 Database Administration ...................................................................................................... 19

6.9 Answers to questions and activities ............................................................................................ 22

6.9.1 Preliminaries ......................................................................................................................... 22

6.9.2 Evaluating Queries ................................................................................................................ 24

6.9.3 Defining Queries ................................................................................................................... 25

6.9.4 Database Administration ...................................................................................................... 26

This topic is the second of two that provide an introduction to the Structured Query Language (SQL). It is recommended that you work through the first of the two topics, SQL I : Basic SQL, before proceeding with this topic. The relevant sections of the recommended course texts are El Masri and Navathe, Chapters 8 and 9 you may also like to consult C J Date Chapters 5 and 6. If you are unable to locate the above text books there are other sources of information that may prove useful. Remember to check out the details of the recommended reading that were detailed in Topic 1. Topic 5 provided an introduction to SQL query language. More specifically it introduced the Data Manipulation Language (DML) subset of SQL. DML is used by the database user to access data; and there are different levels of user that we can consider. For example, we might want to restrict which users are able to delete items from the database. The database administrator (DBA) is a high level user of the database who allocates roles, and consequently levels of access, to other users. The role of the DBA is more complex than we can go into here; for example, creating databases (as distinct from creating tables in an existing database), creating user IDs, changing passwords, creating indexes etc. Our interest here is that the DBA is the person who can alter the database schema by creating, modifying and deleting tables. To create and modify the database schema, the DBA uses a different part of SQL - this subset is referred to as the Data Definition Language (DDL). This DDL, and the role of the DBA, are explored through this topic. There are seven main subtopics that cover the core material: Data Definition Language: introduces the key DDL part of the SQL. Data Types: SQL supports a diverse range of data types for attributes. This subtopic introduces the key ones you will require.


3

Database Constraints: reviews the key constraints that we can place on data, and considers when and how they are checked. Views: considers the concept of the database view introduced in Topic 2, and the view can be used in practice. Database Administration: introduces the concept of the database administrator, and how that user can control the access of other user roles to the database. Other Useful Bits of SQL: All data in the database is stored in tables - this includes details of the database schema itself. This subtopic provides a brief insight to show you how to find out more from the database itself. Advanced SQL Features: considers some more advanced features of the SQL. These are beyond the scope of this topic to consider in detail, but will provide further areas that you might like to explore further. In addition there is a substantial tutorial at the end of this topic, which provides an opportunity for you to develop and test the skills and knowledge acquired. It contains a number of key activities aimed at providing practical experience using SQL:

1. Evaluating queries 2. Defining queries 3. Database administration

Please note that there may be difficulties when you try and execute certain of the suggested SQL contained in this topic. We have endeavoured to ensure examples that we provide in the text or example solutions to questions conform to the SQL2 standard. This means that slight changes in SQL syntax may be required depending on the version of SQL that you are using locally, or variations introduced as a result of particular vendors implementations of the standard.


4

6.1 Data Definition Language

Learning Objective Be able to manipulate the database using SQL DDL statements. Topic 5 introduced the SQL language, and in particular the DML. The DML is the part of SQL that is used to manipulate the data items stored in the database, and concerns the SELECT, INSERT, UPDATE and DELETE statements. This topic concerns the second part of SQL, which is referred to as the Data Definition Language (DDL). DDL is used to manipulate the database schema itself and therefore contains statements to create, alter and delete tables from the database. This is considered further through the following three subtopics: Creating Tables, Altering Existing Tables, and Removing Tables. DDL also supports statements that control access to the data - this takes the form of granting and revoking access to tables. These statements are the concern of the DBA and are considered under a later subtopic heading.

6.1.1 Creating Tables Earlier topics covered the areas of data analysis and database design which result in a relational schema. The relational schema can be represented as a number of tables in a relational database. (DDL is the subset of the SQL language that allows the the creation, modification and deletion of tables). This brings us to consider the first component of SQL DDL - the CREATE TABLE statement. In order to create a table we require the following information:

1. Attribute Definitions: The names and types of attributes are required. The attribute definitions become the columns of the table.

2. Attribute Properties: Knowing the type of attribute is not sufficient. It is important to know

its size as this will help in validating the data input to the database. It is also important to know if the attribute can be NULL or not, i.e. must that attribute have a value other than NULL. These form constraints on the data in the tables.

3. Uniqueness: It is important to know which data items will form the primary key to the data

in the table. In order to form the primary key the data items must be unique, i.e. to allow an individual tuple in the relation (i.e. row in the table) to be identified.

As an example, consider the CREATE TABLE statement shown below:

CREATE TABLE crs (c# CHAR(5) NOT NULL, cname VARCHAR(20) NOT NULL, dname VARCHAR(22) NOT NULL, year NUMBER NOT NULL, PRIMARY KEY (c#),


5

FOREIGN KEY (dname) REFERENCES dept); This example shows the SQL DDL statement required to create the CRS table introduced in Topic 5. The CREATE TABLE statement begins with the keywords followed by the name of the table to be created. This table name must not already exist in the target database - if it does the DBMS will complain when the statement is executed. Following the initial line, the brackets contain a comma separated definition of each of the attributes in the CRS relation - these form the columns of the CRS table. Each attribute is defined by a name, for example c#. Each attribute is allocated a datatype and size, for example CHAR(5) which defines a basic character datatype of length 5. Datatypes will be discussed further in this topic. Finally the NULL status of each attribute is defined - all attributes are defined as NOT NULL. This means that when rows are added to the database, the database will check that each attribute has a value - the insert will not be allowed if any attribute is missing a value. If, in fact, a NULL value is allowed, then the NOT NULL clause should be omitted. Q1: Can you remember why NULL values are a potential problem in a database. Why should they be avoided? After the definition of each column in the CREATE TABLE statement, additional clauses define the PRIMARY KEY and FOREIGN KEY information (these clauses are optional). The respective attributes which form the keys are placed in round brackets after the KEY keyword. Although a single attribute is shown for the primary and foreign keys, a number of attributes could be used. In this case the respective attributes would be included, separated by commas. In the case of the FOREIGN key, the REFERENCE clause identifies the table that the foreign key accesses. In this case the foreign key DNAME is a link into the DEPT table.

A more general form of the CREATE TABLE statement is shown below:

CREATE TABLE <tablename> (<attributename1> <datatype> [NOT NULL], <attributename2> <datatype> [NOT NULL], ... [PRIMARY KEY (<attributename>, attributename> . .. ),] {FOREIGN KEY (<attributename>, attributename> . .. ) REFERENCES <tablename>} );

The general style shown above is referred to as Bacus-Naur Form (BNF). This is a general form of notation that allows the structure of syntax to be shown outside of a specific example. The specifics that you would substitute are shown in the angle brackets, such as the table name, attribute names and data types. Optional items and clauses of the CREATE statements are shown in square brackets.

6.1.2 Altering Existing Tables


6

Once a table has been created it may be necessary to alter the table schema. This can be achieved by the ALTER TABLE statement, which allows columns to be added (using the ADD clause) or removed (using the DROP clause). It also supports changing the NULL status of columns. For example, the SQL statement given below alters the existing STD table and adds a column to store a telephone number. ALTER TABLE std ADD phone_no VARCHAR(15)

Note that the NOT NULL keyword is missing in this case, allowing the phone number attribute to have NULL values. 6.1.3 Removing Tables Tables can be removed from a database schema by using the SQL DDL statement DROP TABLE. In dropping a table, the entire table is removed from the schema. For example, the SQL statement shown below would delete the table CRS. DROP TABLE crs; There are two further variants of the DROP command. These are CASCADE and RESTRICT. These are shown in below: DROP TABLE crs CASCADE;

DROP TABLE crs RESTRICT;

The CASCADE clause results in the removal from the database of all constraints and views that use the CRS table. In contrast, the RESTRICT clause will only allow the CRS table to be removed if there are no constraints (including foreign key references in other tables) or views that reference the CRS table, i.e. it will only allow the table to be removed if it is not referenced by any other database component. This DROP command is a very powerful yet simple statement. It is wise to restrict the authority to execute the DROP TABLE statements. Depending on the configuration of the actual database, the DROP TABLE statement can be restricted to work on empty tables, thus avoiding the possibility of removing the wrong table from the database. Q2: The DROP command can be applied to database components other than TABLE; it can be applied to whole database schemas, views and constraints. Consult an SQL reference source and find out what the required commands are to achieve this.

6.2 Data Types Learning Objective Understand the diversity of datatypes supported in SQL. Every column in a table must be allocated a datatype, and SQL supports a wide range of different datatypes. Character data, such as strings or individual characters, can be stored using the CHAR or VARCHAR datatypes:


7

CHAR: This is the basic character based datatype. The length of the CHAR attribute is denoted in brackets following the CHAR key word. For example, a column requiring four characters would be defined CHAR(4). If no length is provided, then the attribute defaults to a single character length. The CHAR datatype is fixed length - this means that if the value 'S1' is stored in an attribute specified as CHAR(4), then the DBMS will pad out the remaining characters with spaces, i.e. the whole four characters will always be used.

VARCHAR: This is a more flexible character datatype. VARCHAR is a variable length type; the maximum number of characters is again denoted in brackets following the keyword - for example, VARCHAR(30) would provide an attribute with a maximum of 30 characters. However, if fewer than 30 characters are used, the DBMS does not pad out the remaining characters. The VARCHAR datatype can therefore make significant savings on space.

A range of numeric datatypes are provided to support integers and decimal numbers.

INTEGER: This datatype is useful for general number columns, supporting negative and positive numbers.

NUMBER: This more general numeric datatype supports decimal places. The number of units can be specified; for example NUMBER(4) allowing a maximum of four digits, or NUMBER(4,2) allowing two of those digits after the decimal point (e.g. 12.45).

A number of specific data types are provided to support date and time data items. The following are the key ones :

DATE: This is useful for storing values which are numeric in nature, but that we know are of type date. An attribute of type DATE has 10 positions - these are split to represent the YEAR, MONTH and DAY components, typically in the form YYYY-MM-DD. The DATE type supports a wide variety of formatting options, which can be very helpful for data output purposes. There are also built in functions that allow manipulation of attributes of DATE type - examples are ADD_MONTHS, MONTHS_BETWEEN, NEXT_DAY. If you require to manipulate dates you should consult an SQL reference to check the full list of functions supported. TIME: An attribute of type TIME has 8 positions which are split to represent the HOUR, MINUTE and SECOND components, typically in the form HH:MM:SS. As with DATE, the TIME datatype provides additional formatting options that can be used to output the time data in alternative formats.

Q3: There are many formatting options available for the output and input of DATE and TIME attributes. Consult a local SQL reference and find out how this works (this is important for your coursework). Other datatypes exist, for example FLOAT, BIT. You should consult a local SQL reference for such information. Be aware that although notionally standard in SQL2, different relational DBMS, like Oracle or MySQL, support different datatypes in practice.


8

6.3 Database Constraints

Learning Objective Understand how and when constraints are tested by the database. Constraints are properties that must be true of every instance of data in a given table. Typically, constraints are checked every time the database changes; for example, after every INSERT, UPDATE or DELETE statement is executed against the data in a particular table in the database. Constraints on the table primary key and foreign key are a powerful mechanism. These constraints are identified in the PRIMARY KEY and FOREIGN KEY clauses of the CREATE TABLE statement:

Primary Key: If the PRIMARY KEY clause is used when a table is created, the DBMS will check each row added to the given table to ensure that the attribute value provided (i.e. the attribute identified in the PRIMARY KEY clause) is both unique and not null. Foreign Key: If the FOREIGN KEY clause is used when a table is created, the DBMS will ensure that there is always a row in the referenced table. This row must have a primary key matching the specified foreign key value.

It is also possible to make general assertions about the values in the database. These assertions may be included in the CREATE TABLE statement at the time the table is created. Alternatively, they can be added to an existing table using the respective clause of the ALTER TABLE statement. This can be achieved using the CHECK clause. The CHECK clause can be applied to individual columns, either when the table is created, or using the ALTER TABLE statement after the table has been created. For example, the SQL statement shown below adds a simple assertion to the GRADE column of the SCH table. This validates that the students grade is between 0 and 100. ALTER TABLE scl MODIFY grade CHECK (grade > 0 AND grade <= 100) Q4: The ALTER command is very useful in supporting changes to the database schema. In addition to adding and altering a CONSTRAINT, it can also be used to add, move or modify columns in the table. Consult a local SQL reference and find out how this works.

6.4 Views Learning Objective Understand how database views can be created and used in SQL. As we saw in Topic 2, a database view allows different users to see different parts of the data,


9

typically restricting the rows and columns that are visible. Tables accessed via a view appear to contain data. Whenever the view is accessed, the database constructs a table of data using the base table of the view. For example, Figure 6.1 illustrates a view called CEE_COURSE. The base table for this view is the CRS table. We may assume that the CEE_COURSE view is to be used to provide some restricted access to the data held in the CRS table.

Figure 6.1: An Example View The CEE_COURSE view could be created using the SQL statement CREATE VIEW. An example is shown below: CREATE VIEW cee_course AS SELECT c#, cname, level FROM crs WHERE dname = 'Computing and Elec Eng'

The contents of the CRS table is illustrated here again in Figure 6.2 for information.

C# CNAME DNAME LEVEL C1 Compilers Computing 3 C2 Networks Computing 3 C3 Electrodynamics Physics 4 C4 Inflation Economics 4

Figure 6.2: Contents of CRS table

The CEE_COURSE view contains only the course code, name and level of courses taught by the Computing department. We can select data from a view in the same way as we select data from a table. For example, executing the statement SELECT * FROM CEE_COURSE would produce the table in Figure 6.3.

C# CNAME LEVEL C1 Compilers 3 C2 Networks 3

Figure 6.3: Contents of View

Compared to the data in the CRS table, the CEE_COURSE view shows a restriction in terms of both columns and rows. The purpose of a view is primarily to support query access to data, i.e. it will typically be used to support SELECT statements. However, if a view is based on a single table, then the view can be used to update the underlying base table data. A view can be based on data from multiple tables, e.g. the result of a join operation. If a view is based on multiple table joins then it cannot be used to update the data in the underlying tables.


10

6.5 Database Administration

Learning Objective Be aware of the role of the database administrator and how that user can control the access of other users. This subtopic introduces the concept of the database administrator (DBA). It is important to manage the access to the data in the database - this is the primary role and responsibility of the DBA. The relevant sections of the recommended course texts are El Masri and Navathe, Chapter 23. All database users have a user identifier, which is the user name recognised within the database. This user name acts as authorisation for the DBMS and is used to control access to data. Examples relevant to the student database may be dba, faculty or admin.

Creating Tables: Tables created by a user are owned by that user. A table name is prefixed by the identifier of the user who created the table. All other users must use that qualifier in order to see the table. For example, if the dba user created the CRS table, then the DBA user can just access the CRS table. All other users must access the table as dba.CRS. Having created the CRS table only the DBA user has unrestricted access. In order for other users to access the data in the CRS table they must be granted access.

� Granting Access: A user can GRANT and REVOKE access privileges on

tables they have created to other users. The access privileges are as follows:

– SELECT: controls who can retrieve data from a given table, i.e. which users can execute DML SELECT statements against data in a table.

– INSERT: controls who can add data to a given table, i.e. which users can

execute DML INSERT statements against data in a table.

– UPDATE: controls who can modify data once it is stored in a given table, i.e. which users can execute DML UPDATE statements against data in a table.

– DELETE: controls who can remove data from a given table., i.e. which users

can execute the DML DELETE statement against data in a table. This does not give permission to remove the table from the schema - only the data held by the table.

– ALL PRIVILEGES: takes into account all the individual privileges above.

The example below shows the SQL to allow the faculty and admin users to query and add rows to the CRS table.

GRANT SELECT, INSERT ON crs TO admin, faculty

PUBLIC user: the example below shows a further example which grants ALL PRIVILEGES on the DEPT table to all users in the PUBLIC user.

GRANT ALL PRIVILEGES ON dept TO PUBLIC

Synonyms: Even though a user has been granted some level of access to a table, they still have to refer to that table by the full reference of user .


11

table; for example the admin user would still have to refer to the dba.CRS table.

A way around this is to create a synonym for the table. A synonym is an alternative name for a table. The example below shows the SQL syntax for creating a synonym for the CRS table created by the dba user.

CREATE PUBLIC SYNONYM crs FOR dba.CRS

The synonym name can be anything - although it is a good convention to give the synonym the same name as the underlying table. In addition, the synonym need not be PUBLIC, although that is the most common use, i.e. to provide the user community with a simple name with which to access the table.

6.6 Other Useful Bits of SQL

Learning Objective Be aware that all data in and about the database is stored in tables. Everything in an RDBMS is stored in a table. This includes the actual data as well as the information concerning the schema, such as database users, grant information, synonyms, views, available tables etc. All this is also stored in appropriate tables which can also be queried. Examples include: SELECT * FROM ALL_OBJECTS ; SELECT * FROM ALL_USERS ; It is recommended that you become familiar with the particular RDBMS that you are using for this module and examine the other tables that may be of help to you.

6.7 Advanced SQL Features

Learning Objective Be aware of advanced SQL features. Standard SQL is good at extracting data, but it lacks the expressive power of more general programming languages. In particular, standard SQL lacks:

Computational Power: The SQL2 standard lacks any facility for looping or recursion. Interfaces: There is a lack of interfaces for calling components written in other languages, for example interfacing to GUI based applications. Sophisticated Types: There is no support for complex data structures such as trees or graphs.

These problems are addressed by a number of advanced SQL features.

6.7.1 Embedded SQL (E/SQL)


12

The standard SQL language lacks many of the constructs, such as conditional test or loops, that we expect from a general programming language. One way around this would have been to extend SQL to include these features. A more acceptable solution has been adopted which allows a general programming language to have SQL statements embedded within it. Languages like C, C++, Java, C#, Haskell, and Smalltalk are examples of languages that can contain embedded SQL and are often referred to as the host language. SQL statements are embedded into a program written in the host programming language at appropriate points to interface to the database and manipulate the data in the required manner - for example to select or delete rows from one or more tables. An example of an SQL statement embedded in an extract of C++ code is shown below:

cout << “Enter Student ID: “; cin.getline(stuid, sizeof(stuid)); EXEC SQL SELECT sname, dep INTO ::stuname, :department FROM std WHERE :stuid = s# ; cout << “Student name is ” << stuname; cout << “ and Department is “ << department << endl ;

This example shows just an extract of a possible program to take in a student identifier from the user. This is read into a string variable stuid which is then used to carry out a query against the database, and return the values of the student name and department. The SELECT statement can access a variable defined in the C++ program by prefixing the variable name with a colon - hence the stuid variable is reference by :stuid in the WHERE clause. The values from the database are then returned to the C++ program, where a simple output statement displays the result. In practise the C++ program would also have to handle the situation where the corresponding row in the table was not found. Host programs with embedded SQL need to be passed through an appropriate precompiler. This translates the embedded SQL into appropriate statements for the host language compiler to understand. In order to readily identify the SQL code segments, the SQL is prefixed by the keyword EXEC. 6.7.2 Open Database Connectivity (ODBC) SQL is a standard language that allows a database to be queried and its data content manipulated. This has the advantage of a user or database developer learning one common language that will allow them to access data in any database implementation, for example Oracle or Sybase. SQL is also supported by a range of tools that act as interfaces to DBMS. These tools support users in data maintenance, or extracting reports from the database, or designing GUI interfaces for end user access. ODBC is used to communicate between DBMS systems. This can be helpful for supporting access to data across multiple databases - each database can be provided by a different DBMS, as shown in Figure 6.4.


13

For example, consider how a global picture of weather patterns could be obtained by extracting weather data from different databases across the world. Oracle DBMS SQLServer DBMS Sybase DBMS Figure 6.4: User Program Accessing Multiple RDBMS via ODBC Interface To allow components to interact using SQL, they each support a common interface, called the Open Database Connectivity (ODBC), which is carefully defined. In essence the ODBC defines procedures such as the one shown below, where a command is a string representing an SQL statement. Execute SQL(command: string)

6.7.3 Procedural SQL (PL/SQL)

This subtopic introduces PL/SQL - the Procedural Language extension to SQL. PL/SQL originates from an extension developed by Oracle. See also relevant sections of the recommended course texts. PL/SQL syntax, structure and data types are similar to that of the ADA programming language, as well as having similarities with other procedural programming languages. PL/SQL includes object oriented programming techniques such as encapsulation, function overloading, information hiding (all but inheritance) and is commonly used to write data-centric programs to manipulate data. PL/SQL provides an alternative to using the embedded SQL that was introduced in a previous subtopic. However, just to complicate matters, PL/SQL can itself be embedded into a general programming language.


14

PL/SQL is described as a block-structured language: the basic unit of code that makes up a PL/SQL program is the block. Each block of code has three parts:

declaration part, where variables and objects are declared. PL/SQL supports all the accepted SQL datatypes, as well as supporting a number of additional ones.

executable part, which contains the program code, manipulating variables declared in the declaration part, etc. PL/SQL supports sequential, conditional and iterative constructs; e.g. IF-THEN-ELSE, FOR-LOOP, WHILE-LOOP, EXIT-WHEN and GO-TO.

exception part, where exceptions and errors raised during the executable part can be trapped and handled. The exceptions can be user defined as well as standard ones supported by the database.

PL/SQL blocks can be nested; the key point is that each block can itself have the above three parts. An illustration of the layout of a PL/SQL block is shown below. The square brackets indicate that the declaration part and exception part are optional.

[ DECLARE --- Declarations appear here ] BEGIN --- executable statements [ EXCEPTION --- exception handling code placed here ] END

6.7.4 Transactions This subtopic introduces the concept of a database transaction. See also relevant sections of the recommended course texts. Sometimes it is important to group together operations on a database. For example, in a bank transfer, the money must be both withdrawn from one account and deposited into another account. These two operations together describe a transaction - in this example the transaction is the transfer of money between two accounts. Ensuring that these two operations do occur as a pair is not simple. Many problems can arise between the two - for example, machine failure, such as a disk crash, or access of an account by another customer/user after the withdrawal has taken place but before the deposit into the second account.

The transaction is the mechanism to control these events and ensure that operations that need to occur together do so without interference. Transactions have a number of properties - these are described as the ACID properties:

A for Atomicity: either all of the operations in the transaction are executed or none are. C for Consistency: each transaction takes the database from one consistent state to another consistent state.


15

I for Isolated: A transaction cannot be interfered with by another transaction which may be executing at the same time. For example, a transaction that attempts to access the account balance while a transfer is taking place will have incorrect results. These transactions should be isolated from one another. D for Durable: once a transaction has been committed, the changes made cannot be lost through any failure.

SQL supports transactions by grouping the associated operations. An example of the SQL TRANSACTION statement is shown below:

EXEC SQL WHENEVER SQL ERROR GOTO UNDO; EXEC SQL BEGIN TRANSACTION; EXEC SQL UPDATE dept SET head = “A.Brown” WHERE dname = “Computing”; EXEC SQL COMMIT WORK; GOTO THE_END; UNDO: EXEC SQL ROLLBACK WORK THE_END: EXEC SQL END TRANSACTION;

The example above shows the general structure of an SQL TRANSACTION. Note the use of the labels UNDO and THE_END to control the flow through the transaction in the event of some error happening during the UPDATE operation. If the SQL statement executed successfully, then the changes are stored in the database - this is done using the COMMIT keyword. If, however, a problem occurred and the changes are not to be committed then a ROLLBACK takes place. This causes the database to reset the values in the database to those at the start of the TRANSACTION. Note that the keyword WORK is optional in following the COMMIT and ROLLBACK commands.

6.8 Advanced SQL Tutorial

Learning Objective Gain further practice in the evaluation and writing of SQL queries.


16

This tutorial provides an opportunity to develop and test the skills and knowledge acquired. It contains a number of key activities aimed at providing with practical experience using SQL:

1. Evaluating queries

2. Defining queries

3. Database administration The questions in this tutorial concern the University database used throughout this module. To help you visualise the database, an example instance is provided in this tutorial through the following figures:

The STUDENT table (illustrated in Figure 6.5). The STAFF table (illustrated in Figure 6.6). The COURSE table (illustrated in Figure 6.7). The ENROLMENT table (illustrated in Figure 6.8). The ASSIGNMENT table (illustrated in Figure 6.9). The TELEPHONE table (illustrated in Figure 6.10).

It is recommended that you use the SQL style adopted in these notes, i.e. capitalise the SQL keywords. studentId name registered counsellorNo region s01 Atkinson 1994 3158 3 s02 MacFarlane 1997 5212 4 s05 Stewart 1998 5212 4 s07 MacKenzie 1997 3158 3 s09 Lewis 1998 5212 4 s10 Bloggs 1997 5212 4 s57 Moodley 1998 5212 4

Figure 6.5: Example STUDENT table staffId name region 3158 Jennings 3 3678 Smyth 1 4219 Stewart 4 5212 Robertson 4 5324 Singh 4

Figure 6.5: Example STAFF table


17

Figure 6.6: Example STAFF table courseCode title credit quota

c1 Java 60 null

c2 Databases 30 24

c3 Software Engineering 60 20

c4 Logic 30 null

c7 Circuit Design 60 24

Figure 6.7: Example COURSE table

studentId courseCode tutorNo

s01 c4 null

s05 c2 5324

s05 c1 5324

s07 c4 3158

s09 c2 4219

s09 c3 4219

s09 c4 5324

s10 c3 5324

s10 c7 5324

s57 c3 4219

s57 c4 5324

Figure 6.8: Example ENROLMENT table

studentId courseCode assignmentNorade

s01 c4 1 44

s01 c4 2 58

s01 c4 3 67

s05 c2 1 75

s05 c2 2 55

s07 c4 1 88

s09 c2 1 85

s09 c2 2 69

s09 c3 1 97

s09 c4 1 87

s09 c4 2 76

Figure 6.9: Example ASSIGNMENT table

studentId phoneNo

s01 0131 678 5443

s02 0131 453 7722

s09 0131 322 7335

Figure 6.10: Example TELEPHONE table


18

6.8.1 Evaluating Queries

Learning Objective To provide experience in analysing the form of queries. This activity can be carried out against the database, or can equally well be carried out as a paper based exercise given the example database table contents illustrated in Figure 6.5, Figure 6.6, Figure 6.7, Figure 6.8 and Figure 6.9. Are the following queries well formulated? If you think that the query is well formulated then give a simple sentence describing the request that the query answers. Illustrate the rows that the query would return.

Q5: SELECT name, registered FROM student

WHERE student_id = `s01' Q6: SELECT course_code, AVG(grade)

FROM assignment

Q7: SELECT name FROM staff, student WHERE region = `3'

A naive SQL programmer has written the following query. (SELECT * FROM student WHERE region = ‘3’) UNION (SELECT * FROM student WHERE region = ‘4’) Q8: Can you suggest a simpler alternative? Q9: Why is your version better?

6.8.2 Defining Queries

Learning Objective To provide experience in forming queries based on an English language specification.


19

For each of the following requests, write an SQL query that provides exactly the data required. Give the output produced for the example database instance in the tables above.

Q10: What are the names and staff numbers of all staff in region 4?

Q11: List the title and code of any course that has students who have not been allocated a tutor.

Q12: List the names of staff who counsel students from region 4. Make sure that your query only returns each staff name once, irrespective of how many students they counsel.

Why not formulate some other queries of your own devising that answer similar

questions from the sample database?

6.8.3 Database Administration

Learning Objective To provide some experience of the effect of executing DML statements, to create tables and views and control user access.

The following questions help you to develop an understanding of database administration, and the impact of administration activities on the database manipulation. Answers the questions in relation to the university database instance presented in Figure 6.5, Figure 6.6, Figure 6.7, Figure 6.8 and Figure 6.9. You should assume that the tables are owned by the dba user. Region 4 of the university plans to make a new view of the student table available which will include only the student identifier, name and registration year of the students in region 4. The view is to be name R4_STUDENT. Q13: Give an SQL statement to create this view and a listing of its apparent contents. Q14: A copy of the contents of R4_STUDENT view is required in a new table called R4_STUDENT_ORIG.Assuming suitable types for the columns, give SQL statements to create the R4_STUDENT_ORIG table ,and insert data from the R4_STUDENT view. Q15: Provide an SQL statement that allows everyone access to query the R4_STUDENT view. Q16: Provide an SQL statement that allows the faculty user the privileges to insert, delete and update the R4_STUDENT view. Q17: Assuming that the R4_STUDENT view is created by the user dba and is the only table of student data available to faculty and admin users, complete the following table detailing the operations and student data available to these different users.


20

dba faculty admin

Operations

SELECT Y

INSERT Y Y

UPDATE N

DELETE Y Y

Columns

studentId Y Y

name Y

registered Y Y

counsellorNo Y N

region N

Rows All

Region 4 also requests a new table to record students who participate in self-help groups on particular courses. The new table, R4_SUPPORT, records the student id of the participant and the course code of the course that the self-help group covers. Q18: Give an SQL statement to create the table R4_SUPPORT, with both columns as the primary key. Q19: Give SQL statements to insert the following rows into R4_SUPPORT:

's10' 's10' 's57' 's57'

'c3' 'c7' 'c3' 'c4'


21

Q20: Give an SQL statement to capture the requirement that every member of the self-help group must be enrolled on the course that the group covers. The following sub-parts use the tables and view defined above, together with the constraints. Explain the effects, and the technical reasons for those effects, of the following operations. Q21: INSERT INTO R4_support VALUES ('s05', 'c2') Q22: UPDATE R4_support SET course_code = 'c5' WHERE student_id = 's10' AND course_code = 'c3' Q23: INSERT INTO R4_support VALUES ('s07','c4') Q24: UPDATE R4_student SET name = 'McFarlane' WHERE student_id = 's02'

Q25: Considering the semantics of the R4_SUPPORT table,shouldthe following insert statement (repeated from a previous question) be permitted? INSERT INTO R4_support VALUES ('s07','c4') If not, why not? Q26: Give an SQL statement that includes a constraint to avoid any inconsistency you have identified.


22

6.9 Answers to questions and activities

6.9.1 Preliminaries Q1: This was discussed in Topic 5. NULL values can be misleading - it can mean that either a value is not known or not applicable. In either event, it is better practice to have an actual value that makes this clear in the context of the relevant attribute. Q2: The following are typical variants of the DROP command that allows the schema, view or constraint to be removed.

DROP SCHEMA university CASCADE; DROP CONSTRAINT someconstraint CASCADE; DROP VIEW cee_course;

Note that the DROP CASCADE and RESTRICT options exist for the SCHEMA and CONSTRAINT commands, but not for the DROP VIEW statement. Can you think why? Q3: The example considered here concerns the display of DATE values, but the same applies to TIME. When outputting a DATE value, the database must first convert that value from the special internal format to a printable string. This conversion is done by a function TO_CHAR, according to a DATE format. A typical default output format for DATE is "DD-MON-YY". Therefore, if the query below were issued against the table in the University database from Topic 5 the corresponding output would be as in Figure 6.11.

SELECT born FROM std;

BORN ————- 19-SEP-69 19-SEP-71 4-AUG-70 30-MAR-68

Figure 6.11: Results from Example DATE Output

Whenever a DATE value is displayed, the database will call TO_CHAR automatically with the default DATE format. However, you may override the default behaviour by calling TO_CHAR explicitly with your own DATE format. The general usage of the TO_CHAR function is shown below TO_CHAR(<date>,”<format>”)


23

There are many different options available for the output format. A number are summarised in Figure 6.12 - but you should consult an SQL reference for the database that you are using.

Format Description MON or Mon Abbreviated month name (e.g. JUL or Jul) MONTH or Month Full month name (e.g. JULY or July) DY or Dy Abbreviated name of day (e.g. FRI or Fri) YYYY 4-digit year (e.g. 1998) HH24 Hour of day (0-23)

Figure 6.12: Common Format Options for DATE and TIME Output

An example of how the above formatting options are used is shown in the SQL statement below. The corresponding output is shown in Figure 6.13. Note how the combination of upper and lower case spelling of the formatting keywords shown in Figure 6.12 can be used to determine the case of the text formatting of the month and day fields.

BORN ———————– 19 September 1969 19 September 1971 4 August 1970 30 March 1968

Figure 6.13: Results from Example DATE Output Using Formatting

Now check out a local SQL reference and see how the counterpart of the TO_CHAR command allows you to input DATE and TIME data - the command you are looking for is TO_DATE.

Q4: The following are typical variants of the ALTER TABLE command that allows a column in a table to be removed or added. The example given first removes and then adds the BORN column of the STUDENT table.

ALTER TABLE student DROP born CASCADE; ALTER TABLE student ADD (born DATE NOT NULL);

Note that the CASCADE and RESTRICT option is required when removing a column - this works the same as for the DROP TABLE command.


24

6.9.2 Evaluating Queries

Q5: This is well formulated. The query will return a row from the STUDENT table. The row returned will be the student with STUDENTID equal to 's01' - the only column values returned by this query will be the student name and date registered.

NAME ——————– Atkinson

REGISTERED ——————— 1994

Q6: This query is not well formulated. It is attempting to return the average student grade for each course code. In order to be able to return the course code and execute the AVG function, the GROUP BY clause would be required. Q7: Although this query may look innocent enough, it is ambiguous. The reference to NAME is ambiguous because it appears as a column in both the STUDENT and STAFF tables. Q8: A simpler way of carrying out an equivalent query would be to use the IN clause or an OR comparison, e.g. SELECT * FROM student WHERE region IN ('3','4') Q9: These alternatives are better because they are shorter - this is an important advantage in keeping SQL easy to read. Also, it is likely that they will be more efficient than the UNION, which may cause the RDBMS to scan the same table twice to complete the query, i.e. carrying out both SELECT statements independently then evaluating the result. The alternatives only contain a single SELECT statement. The efficiency depends on the RDBMS to a large extent, and how it optimizes queries.


25

6.9.3 Defining Queries

Q10:

SELECT name, staffId FROM staff WHERE region = '4'

NAME STAFFID ——————– ——————— Stewart 4219 Robertson 5212 Singh 5324

Q11: The SQL to answer this question needs a join between the COURSE and ENROLMENT tables. For simplicity this requires aliases for the WHERE clause to avoid having to state COURSE.COURSECODE = ENROLMENT.COURSECODE, due to the use of the same column name in both tables.

SELECT title, c.course_code FROM course c, enrolment e WHERE tutor_no IS NULL AND c.course_code = e.course_code

TITLE ——————– Logic

COURSECODE ——————— c4


26

Q12: The SQL to answer this question needs a join between the STUDENT and STAFF tables. In this case the full table names have been used to clarify which columns are being referred to. This could have been achieved using aliases for the tables specified in the FROM clause. SELECT DISTINCT staff.name FROM student, staff WHERE sounsellor_no = staff_no AND student.region = '4' NAME ——————– Robertson

6.9.4 Database Administration

Q13: CREATE VIEW R4_student AS SELECT student_id, name, registered FROM student WHERE region = '4'

STUDENTID NAME REGISTERED

——————– ——————— ———————

s02 MacFarlane 1997

s05 Stewart 1998

s09 Lewis 1998

s10 Bloggs 1997

Moodley

s57 1998

Q14: CREATE TABLE R4_student_orig( student_id CHAR(3), name VARCHAR(12), registered SMALLINT, PRIMARY KEY student_id) INSERT INTO R4_student_orig SELECT * FROM R4_student Q15: GRANT SELECT, ON R4_student TO PUBLIC


27

Q16: GRANT INSERT, DELETE, UPDATE ON R4_student TO fa culty Q17:

dba faculty admin

Operations

SELECT Y Y Y

INSERT Y Y N

UPDATE Y Y N

DELETE Y Y N

Columns

studentId Y Y Y

name Y Y Y

registered

Y Y Y

counsellorNo Y N N

region Y N N

Rows All Only region 4 Only region 4

Q18:

CREATE TABLE R4_support( student_id CHAR(3), course_code CHAR(2), PRIMARY KEY (student_id, course_code))

Q19: INSERT INTO R4_support VALUES (`s10', `c3') INSERT INTO R4_support VALUES (`s10', `c7') INSERT INTO R4_support VALUES (`s57', `c3') INSERT INTO R4_support VALUES (`s57', `c4')

Q20: ALTER TABLE R4_support ADD FOREIGN KEY (student_id, course_code) REF ERENCES enrolment

Q21: This SQL statement will successfully insert a row into the R4_support table.

Q22: This statement will fail because the row ('s10','c3') of the R4_support table breaks the constraint established earlier. Namely, that the student should be enrolled on a course. Q23: This SQL statement will successfully insert a row into the R4_support table.


28

Q24: This SQL statement will change the name of the student with studentId equal to 's02' in the STUDENT table on which the R4_STUDENT view is based. The STUDENT table is modified as it is the base table on which the R4_STUDENT view is defined. Note that only the base STUDENT table is updated - a view reflects the update, but cannot be technically updated itself. The R4_STUDENT_ORIG table is unchanged as there is no connection maintained between the STUDENT table and the R4_STUDENT_ORIG table.

Q25: The insertion should not be allowed because it violates the semantics of the R4_support table by inserting a student from the wrong region (student 's07' is in region 3).

Q26:

ALTER TABLE R4_support CHECK (student_id IN (SELECT student_id FROM R4_s tudent))

SQL II : Advanced Features and Database Administration

Documents

Transcript of SQL II : Advanced Features and Database Administration