1. Module Coordinator Tan Szu Tak School of Information and Communication Technology, Politeknik Brunei Semester 3 2014

2. 2  Sequences  Views  Advantages of Views  Views for Authorization Example  Query Modification  Virtual VS. Materialized Views  Materialized Views *Words with underline can be clicked on

3. 3  Updating Materialized Views  Trade-offs in view implementation  Updates on Base Tables VS. Views  View Updateability  SQL Standard for View Updateability  Complex Integrity Constraints  The CHECK Clause *Words with underline can be clicked on

4. 4  CHECK Constraint and DOMAIN  CHECK: attribute VS tuple-based  Naming Constraints  Constraint Management  Assertions  Triggers  Triggers VS Assertions  Events *Words with underline can be clicked on

5. Often we want to assign each row with an unique number. These are useful as primary keys. Using integers to reference rows is more efficient than any other type. example: 1, 2, 3,.., 12… compare with i, ii, iii, … xii,… OR a, b, c, … aa, ab, ac… We would like the DBMS to do this AUTOMATICALLY 5

6. In most versions of SQL, we can use auto-incrementing fields to do this. The details will differ between versions. Usually the first entry is assigned 1, the next 2, and so on, but Oracle lets you change this. 6

7. In Oracle we use a Sequence A sequence is a source of numbers We can declare several sequences, giving each a name, a start point, and a step size We can then generate unique numbers by asking for the next element from a sequence. 7

8. To declare a sequence CREATE SEQUENCE [START WITH ] [INCREMENT BY ] If no START WITH or INCREMENT BY values are given, they default to 1. To get the next value from a sequence.nextVal 8

9.  Create a sequence CREATE SEQUENCE mySeq START WITH 1;  Using a sequence SELECT mySeq.nextVal FROM DUAL; INSERT INTO Student (stuID, stuName, stuAddress) Values (mySeq.nextVal, ‘Steve Mills’, ‘13 Elm Street’); 9

10.  To find the details of a table use DESCRIBE Example SQL> DESCRIBE Student; 10

11. What is a view?  It is a table ◦ as it can be queried just like a table.  It is NOT a table ◦ as it does not physically exist!  A view is a “virtual table” derived from base tables.  A view is a “named query” 11

12. SQL command: CREATE VIEW Follow by: ◦ A view name ◦ A query to specify the table contents 12

13. Creating a view: CREATE VIEW IT_Students AS SELECT name, class FROM Student WHERE Major = “IT”; Using a view:SELECT class, COUNT(*) FROM IT_Students GROUP BY class; 13

14. 14

15. 1. Logical independence 2. For convenience and clarity when writing queries ◦ Views can be used just like tables 3. For security ◦ Different data access privileges can be given to different users (i.e., authorization) 15

16. SQL>CREATE VIEW IT_Students AS SELECT name, class FROM Student WHERE Major = ‘IT’; GRANT SELECT ON IT_Students TO PUBLIC; GRANT UPDATE ON IT_Students TO faculty; CREATE ROLE faculty; GRANT faculty TO Sharaf; GRANT faculty TO Sutton; 16

17. Query Modification present the view query in terms of a query on the underlying base tables. Disadvantage: ◦ re-compute the view with every query.  E.g. Multiple queries SELECT name FROM IT_Students where age > 19, 20, 21. ◦ Inefficient for views defined via complex queries:  E.g. aggregate queries. 17

18. 18

19.  Views: ◦ Virtual tables ◦ Evaluating a view (query) creates its data  Materialized Views: ◦ Stored tables ◦ Physically store the view (query) and its data 19

20. Involves physically creating and keeping a temporary table. Advantages:  Avoid re-computing the view with every query  Assumption: more queries can use the same view But, materialized view maintenance is needed A materialized view should be updated when any base table used in the view definition is updated. 20

21. Efficient strategies for automatically updating the materialized view when base tables are updated  Avoid re-computing the view from “scratch”  Increment update: ◦ determines what new tuples must be inserted, deleted, or modified in the view when an update is applied to the base tables. 21

22. 22

23. All updates on base tables are reflected in corresponding views  In virtual views: query evaluation  In materialized views: view maintenance How about updates to views?  A user expects that updates on a view will also be reflected in base table(s)  View updatability 23

24. In general, a view is called updateable if:  All updates on the view can be unambiguously translated back to tuples in the base tables. A view update is unambiguous only if:  Only one update on the base tables can accomplish the desired update effect on the view. In general, a view is not updateable if:  an update on a view can be mapped to more than one possible update on the base tables. 24

25. 25

26. 26

27. 27

28. 1. A view with a single defining table is updatable if the view attributes contain the primary key. 2. Views defined using aggregate functions are not updatable. 3. Views defined on multiples tables using joins are generally not updatable. 28

29. Three DDL constraints:  Checks  Assertions  Triggers 29

30. check (P) where P is a predicate Example: ensure that semester is one of fall, winter, spring or summer: create table section ( course_id varchar (8), sec_id varchar (8), semester varchar (6), year numeric (4,0), building varchar (15), room_number varchar (7), time slot id varchar (4), primary key (course_id, sec_id, semester, year), check (semester in (’Fall’, ’Winter’, ’Spring’, ’Summer’)) ); 30

31. 31

32. 32

33. 33

34. CREATE DOMAIN M_Code AS CHAR(10) CHECK (M_Code IN (‘IT’, ‘Cinema’, ‘History’)); CREATE TABLE Student ( Sid INTEGER, Name CHAR(20), Age INTEGER, GPA REAL, Major M_Code, PRIMARY KEY (Sid)); 34

35. CHECK prohibits an operation on a table that would violate a constraint. CHECK clause restricts acceptable attribute values according to some definition ◦ attribute-based CHECK is also used as a tuple-based constraint: ◦ Apply to each tuple individually ◦ Checked whenever a tuple is inserted or modified 35

36. CREATE DOMAIN M_Code AS CHAR(10) CHECK (M_Code IN (‘IT’, ‘Cinema’, ‘History’)); CREATE TABLE Student ( Sid INTEGER, Name CHAR(20), Age INTEGER, GPA REAL, Major M_Code, Minor …., what constraints are needed for Minor? PRIMARY KEY (Sid)); 36 IC1: Minor IN …. IC2: Minor ≠ Major IC1: Minor IN …. IC2: Minor ≠ Major

37. CREATE DOMAIN M_Code AS CHAR(10) CHECK (M_Code IN (‘IT’, ‘Cinema’, ‘History’)); CREATE TABLE Student ( Sid INTEGER, Name CHAR(20), Age INTEGER, GPA REAL, Major M_Code, Minor M_Code,  IC1: attribute-based PRIMARY KEY (Sid)); 37

38. CREATE DOMAIN M_Code AS CHAR(10) CHECK (M_Code IN (‘IT’, ‘Cinema’, ‘History’)); CREATE TABLE Student ( Sid INTEGER, Name CHAR(20), Age INTEGER, GPA REAL, Major M_Code, Minor M_Code,  IC1: attribute-based CHECK (Major <> Minor);  IC1: tuple-based PRIMARY KEY (Sid)); 38

39. A constraint may be given a name using the keyword CONSTRAINT E.g. CONSTRAINT Major_Minor Advantages of naming a constraint:  Facilitates editing  Identifies a particular constraint ◦ For reporting ◦ For constraint management 39

40. CREATE DOMAIN M_Code AS CHAR(10) CHECK (M_Code IN (‘IT’, ‘Cinema’, ‘History’)); CREATE TABLE Student ( Sid INTEGER, Name CHAR(20), Age INTEGER, GPA REAL, Major M_Code, Minor M_Code, CONSTRAINT Major_Minor CHECK (Major <> Minor); ); 40

41. To modify a constraint: 1. Drop the existing one first 2. Add a new one Example ALTER TABLE Student DROP CONSTRAINT Major_Minor; ALTER TABLE Student ADD CONSTRAINT Major_Minor CHECK (Major <> Minor); 41

42. Similar to CHECK but they are global constraints CREATE ASSERTION CHECK ; Global: schema-based must be TRUE for each database state. Examples:  # of IT students cannot exceed 1800  # of students in a prac cannot exceed lab capacity 42

43. The syntax for assertion: CREATE ASSERTION CHECK NOT EXISTS (vquery); 1. Specify a query such that: ◦ vquery: selects any tuple that violates 2. Include vquery inside a NOT EXISTS clause 43

44. The syntax for assertion: CREATE ASSERTION CHECK NOT EXISTS (vquery); 44

45. Number of students in any major cannot exceed 1800 CREATE ASSERTION Major_Limit CHECK NOT EXISTS ( SELECT Major_Code, COUNT (*) FROM Student GROUP BY Major_Code HAVING COUNT(*) > 1800 ); 45

46. A trigger consists of 3 parts: 1. Event(s), 2. Condition 3. Action E.g. notify the Head of School whenever the number of students in any major exceeds 1800 46

47. Assertion  Condition must be true for each database state  DBMS rejects operations that violate such condition Trigger  DBMS takes a certain action when condition is true  Action could be: stored procedure, SQL statements, Rollback, etc. 47

48. Notify the HOS when the # of students in any major exceeds 1800 48

49. Notify the HOS when the # of students in any major exceeds 1800 49

50. Notify the HOS when the # of students in any major exceeds 1800 50

51. Notify the HOS when the # of students in any major exceeds 1800 51

52. Events = operations = INSERT, DELETE, UPDATE time = BEFORE or AFTER ◦ BEFORE: the trigger is executed before the operation. ◦ AFTER: the trigger is executed after the operation. A Trigger might allow operations that violate a constraint! 52

53. Reference: INFS 2200, The University of Queensland Lecture Slides by Tan Szu Tak, SICT, Politeknik Brunei