Part 1: Access Privileges

Transcription

1 Part 1: Access Privileges In database management systems, we often do not want to provide the users full control over our database for different reasons. For example, if Amazon.com customers could delete items from Amazon's inventory, no one would know what they have to offer. Worse, if customers had the capability of updating the inventory, they could potentially change the price of items and maybe purchase them for free. Therefore, to preserve integrity of data, certain users or groups need to have restrictions in place that will prevent them from performing unwanted/unauthorized actions on the database. Therefore database servers enforce privileges for database objects such as table, stored procedures, etc. The following exercise demonstrates the use of privileges. You will use the Firebird Employee database for this exercise. Therefore, log into your virtual machine. Next, open a terminal. Creating a user: You are going to try out granting and revoking certain privileges. You do not want to ruin the SYSDBA account, so you will create a new user. In Firebird 2.5, the only way to create a new user is via the gsec tool. To create a user, at the terminal prompt, enter the following command to start the Firebire gsec tool. $ sudo gsec -user SYSDBA -password coursework; Once you enter the command, you should see a GSEC> prompt. Next, at this prompt, enter the following command: GSEC> add USER1 -pw secknitkit-user1 You should see a message that the user was created. Exit the gsec tool by typing quit at the gsec command prompt. You will see the terminal prompt appear again. User Permissions: By default, new users are automatically put in a role called PUBLIC in the Employee database. Roles are a way to establish a set of privileges, and then give those privileges to multiple users. Everyone having a certain role gets all of the privileges of that role. The PUBLIC role gives a user all privileges on all objects in the database. The privileges are SELECT, INSERT, DELETE, UPDATE, and REFERENCES. Try a query on the COUNTRY table to prove that USER1 has SELECT privileges. To do so, run the isql-fb tool like the following: $ isql-fb -user USER1 -password 'secknitkit-user1' "localhost:/home/coursework/employee.fdb" You should see the SQL> prompt. Enter a query that shows all the rows in the COUNTRY table. The query should work. Take a screenshot of the terminal that shows the user being created and the COUNTRY table being successfully queried before continuing. Name the screenshot file hw5_part1_image1.png. Giving the PUBLIC role full access seem like poor security. So, you will remove all access from PUBLIC. To do so, quit the isql-fb tool, and the re-run the tool as SYSDBA, i.e.:

2 $ isql-fb -user SYSDBA -password 'coursework' "localhost:/home/coursework/employee.fdb" At the SQL> prompt, type the following command: SQL> revoke all on all from PUBLIC; Then quit the isql-fb tool, and re-run the tool as USER1. Query the COUNTRY table again. You should get an error message saying that you do not have the correct privileges. Take a screenshot of the terminal that shows PUBLIC having its privileges revoked, and the COUNTRY table being unsuccessfully queried before continuing. Name the screenshot file hw5_part1_image2.png. Granting Permissions Now you will give the PUBLIC the SELECT privilige only, so that the PUBLIC can query the COUNTRY table, but not modify it. Also, PUBLIC will not be able to query any other table. Exit the isql-fb tool if it is running, and re-run it again as SYSDBA. Then, at the SQL> prompt, enter the following: SQL>grant SELECT on COUNTRY to PUBLIC; Then exit isql-fb and re-run the tool as USER1. Query the COUNTRY table. You should see that the query works. Take a screenshot of the terminal that shows PUBLIC begin given the SELECT privilege, and the COUNTRY table being successfully queried before continuing. Name the screenshot file hw5_part1_image3.png. Next, you will grant only USER1, not PUBLIC, the INSERT privilege on the COUNTRY table. Again, exit the isql-fb tool and re-run it as SYSDBA. Next, at the SQL> prompt, enter the command to grant the INSERT privilege to USER1. The command will look like the previous grant command that you typed, but you will substitute INSERT for SELECT and USER1 for PUBLIC. Exit the isql-fb utility and re-run it as USER1. Insert a row into the COUNTRY table for the country 'Finland' and the currency 'Euro'. Your insert should succeed. Show that the new row was added to the table by doing a query on the COUNTRY table that shows all the rows. Take a screenshot of the terminal that shows USER1 being given the INSERT privilege, and the COUNTRY table being successfully modified before continuing. Include the query results that shows all rows of the table. Name the screenshot file hw5_part1_image4.png. Part 2: Triggers and Stored Procedures For Part 2, Your assignment is to create SQL scripts. These scripts will work on the Firebird employee database. You will be creating 4 script files, one for each one of the problems below. When grading your script files, I will submit them to my Firebird database server via the following command:

3 isql-fb -user SYSDBA -password coursework "localhost:/home/coursework/employee.fdb" < problemx.sql Note in "problemx.sql", the X will be replaced with a 1,2, 3, or 4 for each of the problems below. In other words, you will create files named problem1.sql, problem2.sql, problem3.sql, and problem4.sql. Turn them in via Moodle zipped up in one file called yourmoodlename_hw4.zip (where "yourmoodlename" is replace by your Moodle user name). The Firebird syntax is different from the syntax given on the slide in class (the SQL standards). Therefore, you will need to look in the Firebird manual to learn the syntax differences. Here are some links that will help you on this assignment: o The PDF Interbase 6 user manual in a zip file o Other Firebird references, including documents describing the changes in Firebird for 2.0 and 2.5. o A a web site by Janus Software that is a good HTML resource (Firebird 2.0) Preparation:In this assignment, you will be creating a table and then using stored procedures and triggers to manipulate it. To make it easy for you to test your scripts, execute the following code (either using isql-fb or Flamerobin) once you have connected to the employee database. set term # ; create procedure drop_if_exists(thing varchar(50), name varchar(50)) as -- don't need to declare anything here begin execute statement 'drop ' thing ' ' name; when any do begin end end # commit work # Executing the above code will create a stored procedure. The stored procedure will drop database objects without throwing an exception if the object does not exist. You can make calls to it at the top of your scripts to drop tables, procedures, and triggers before you (re)create them. Therefore, you can run your scripts multiple times without Firebird complaining that your tables, triggers, and procedures are already defined. You call it like the following in Firebird: execute procedure drop_if_exists('procedure', 'f_class'); execute procedure drop_if_exists('trigger', 'tr_salary_class_update'); execute procedure drop_if_exists('trigger', 'tr_salary_class_insert');

4 execute procedure drop_if_exists('trigger', 'tr_salary_class_delete'); execute procedure drop_if_exists('table', 'salary_class'); Note that the arguments to the stored procedure are strings (varchar). The first parameter is the type of object to drop (must be valid SQL syntax for the corresponding drop statement, i.e. 'trigger' for a 'drop trigger', 'procedure' for 'drop procedure', and 'table' for 'drop table'). Also, before you begin problem 1, create a table called employee_tester. You will make modifications to the employee_tester table so that we do not destroy the original employee table. So, execute the following SQL command (either in isql-fb or Flamerobin): CREATE TABLE EMPLOYEE_TESTER ( EMP_NO EMPNO primary key, FIRST_NAME FIRSTNAME NOT NULL, LAST_NAME LASTNAME NOT NULL, PHONE_EXT varchar(4), HIRE_DATE timestamp DEFAULT 'NOW' NOT NULL, DEPT_NO DEPTNO NOT NULL, JOB_CODE JOBCODE NOT NULL, JOB_GRADE JOBGRADE NOT NULL, JOB_COUNTRY COUNTRYNAME NOT NULL, SALARY SALARY DEFAULT 0 NOT NULL ); commit work; Problems: 1. Create a SQL script called problem1.sql that creates a table called salary_class with two columns. The first column is named classand is of type varchar(5), and the second column is called occurrences and is of type int. Next, insert values for ELITE, HIGH, MID, and LOW, all with the occurrences column set to 0. Next, define a helper function that you will use in the next problem. The function is called f_class. It takes has one parameter called salary. The function should return the string 'LOW' for a salary less than 40000, 'MID' for a salary less than 68000, 'HIGH' for a salary less than , and 'ELITE' for a salary and above. Show that you created the salary_class table correctly by including a query in your script that shows all the rows in the table. Also demonstrate your function by including a query that calls the function for each of the following salaries: 20000, 67999, 68000, and Notes: o o Due to how Firebird implements transactions, once you create the salary_class table, you will have to commit the transaction before you execute the insert statements. You may need to change the statement terminator (see the definition of drop_if_exists above for an example, or the definition of f_ten_percent_raise below), so that you can use the semi-colon to separate your statements within your trigger definition.

5 o Unfortunately, Firebird does not implement functions according to the standard (surprise, surprise). Instead, Firebird stored procedures can return table values. However, again, Firebird syntax differs from the standard. Here is an example: set term # ; create procedure f_ten_percent_raise(salary SALARY) returns (amt SALARY) as begin amt = salary * 1.10; suspend; end # set term ; # The above store procedure returns a table with only one row and one column called amt. The suspend statement acts like a return in C/C++. Invoke the procedure as follows: select amt from f_ten_percent_raise(50000); o o The syntax for the IF statement differs from the standard. Following is an example: if (expression) then statement1; else statement2; 2. Create a script called problem2.sql, and in the script define a trigger called tr_salary_class_insert that, when a new employee is inserted into the employee_tester table, updates the corresponding occurrences column in the salary_class table. For example, if a new employee that has a dollar salary is entered into the employee_tester table, the trigger should increment the how_many column for the class 'LOW' salaries in the salary_class table by 1. To show that your script works, include in your script SQL commands to copy all the data from the employee table into the employee_tester table. Finally, include in your script a query that shows the salary_class table after all the rows from the employee table are copied. Notes:

6 o Firebird trigger syntax differs slightly from the standard. An example follows: set term # ; create trigger trigger_name for table_name after insert -- replace trigger_name with the trigger name and -- replace table name with the table's name as -- variable declarations go here -- syntax is: DECLARE variable_name type DEFAULT value; begin -- below is an example for calling the stored procedure and -- putting the return value in a variable. select class from f_class(new.salary) into :new_class; -- Notice that the variable name is preceded by a colon when -- used in an SQL statement. -- Also notice that the INTO goes at the end of the -- select, unlike the standard. -- Finally, NEW holds value of the new row that was inserted into the table. -- delete triggers have an OLD variable that holds the value of the -- deleted row, and update triggers have both NEW and OLD. -- rest of trigger definition goes here end # set term ; # 3. Create a SQL script called problem3.sql that defines a trigger tr_salary_class_delete that, when an employee is deleted from the employee_tester table, updates the corresponding occurrences column in the salary_class table. For example, if an employee that has a dollar salary is deleted from the employee_tester table, the trigger should decrement the how_many column for the class 'LOW' salaries in the salary_class table by 1. To show that your trigger works, delete the employees with employee ids 24 and 61, and execute a query that shows all the rows in the salary_class table.

7 4. Create an SQL script called problem4.sql that updates the salary_class table if a salary is changed (an update statement is executed on the employee_tester table). The update trigger should be fairly easy because it does what both the delete and insert triggers do, and has OLD and NEW row variables that have the column values for the row's values before the update and after the update, respectively. Lastly, include, in your script, an SQL command that updates the salary to dollars for the employee with an employee id of 65. Finally, include an SQL query that shows the salary_class table. Part 3: Normalization Consider the following Relation and functional dependencies: Student: Student_i Student_na d me Course_ id Course_na me Dep t Colleg Semest e er Grad e 01 Joe CSC101 Intro to Computers CSC ARTSC S08 I A 02 Jan MAT105 Calculus 1 MA T ARTSC S10 I B 03 Mary ECE200 Computer Hardware ECE ENG S08 B 01 Joe CSC102 Intro to Programming ARTSC CSC F09 I C {Student_id, Course_id, Semester} Grade Student_id Student_name Course_id {Course_name, Dept} Dept College 1. Show a set of relations that is in second normal form and is a decomposition of the above Student relation. Make sure that your decomposition is not in third normal form. Put your relations in the format that you have use throughout the semester, i.e. relation1(attribute1, attribute2,...) realtion2(attribute3, attribute4...) and so on. Give the relations names that make sense. Do not change the attribute names. 2. Show a set of relations that is in third normal form and is a decomposition of the above Student relation. Turn-in:

8 Create a directory structure with directories called part1, part2, and part3. In part1, put you screenshots for part 1, puts your SQL scripts for part 2 in part2, and put your text file for the answers to part 3 in part3. Create a tarball or zip file containing the three sub-directories. Call the tarball your id_hw4.tar.gz or the zip file yourmoodleid_hw4.zip. Where "your id" is your id. Submit it via ilearn.