Java API for XML Processing (JAXP)

1. Java API for XML Processing (JAXP) • For processing XML data using applications written in Java • JAXP APIs - javax.xml.parsers package • Leverages 2 parser standards : • SAX (Simple API for XML Parsing) • parse the data as a stream of events, a serial-access mechanism that does element-by-element processing • DOM (Document Object Model) (easier to use) • build a tree structure of objects to represent the data • org.w3c.dom • Detail review of the enrollment example (files posted on the course web page as JAXP example) • http://java.sun.com/j2ee/1.4/docs/tutorial/doc/JAXPIntro5.html

2. Ch. 7 Constraints and Triggers • Keys as constraint • Foreign key constraints and referential integrity • Constraints on attributes • Constraints on tuples • Assertions • Triggers

3. Keys as Constraint • One primary key per relation • Declared in CREATE TABLE • 2 ways: • List with attribute (when only 1 attribute in key) e.g. snum char (5) PRIMARY KEY • Add to the list of items declared in the schema. E.g. CREATE TABLE supplier ( snum CHAR(3), sname VARCHAR(15), status INT, city VARCHAR(15) CONSTRAINT pk_supplier PRIMARY KEY(snum) );

4. Keys (continued) • Primary Key attribute cannot be NULL • 2 tuples in R cannot agree on all of the attributes in the primary key. DBMS rejects violating insertions or updates. • Can also declare a key with UNIQUE • Can be used instead of PRIMARY KEY • Can have multiple UNIQUE in a table • UNIQUE attributes permit NULL • Key constraints are checked at insert and updates • Use of index created with key attributes for efficient key enforcement checks

5. Foreign-Key Constraints • To enforce referential integrity constraints • E.g. SPJ (type 1), S, P, J (type 2) • The reference attribute of the relation of type 2 must be declared PRIMARY or UNIQUE • Again 2 ways to declare in CREATE TABLE • Inline with declaration • Add to the list of items declared in the schema

6. FK as list of items declared in the schema e.g. CREATE TABLE spj ( snum CHAR(3), pnum CHAR(3), jnum CHAR(3), qty INT, CONSTRAINT fk_spj_1 FOREIGN KEY (snum) REFERENCES S(snum) DEFERRABLE INITIALLY DEFERRED, CONSTRAINT fk_spj_2 FOREIGN KEY (pnum) REFERENCES P(pnum) DEFERRABLE INITIALLY IMMEDIATE, CONSTRAINT fk_spj_3 FOREIGN KEY (jnum) REFERENCES J(jnum) -- this one just use default, i.e. not DEFERRABLE );

7. FK – maintaining referential integrity • 3 Policies: • Default : Reject violating Modifications • Cascade : changes to the referenced attributes are mimicked at the foreign key • Set Null : set the foreign key to null when the referenced attributes are changed (delete / update) • Declare for delete and update separately • Declare with the declaration of foreign key • Dangling tuples – violate referential integrity constraint for the foreign key. Dealt with the 3 policies.

8. Maintaining referential integrity - Example CREATE TABLE spj ( snum CHAR(3), pnum CHAR(3), jnum CHAR(3), qty INT, CONSTRAINT fk_spj_1 FOREIGN KEY (snum) REFERENCES S(snum) ON UPDATE CASCADE DEFERRABLE INITIALLY DEFERRED, CONSTRAINT fk_spj_2 FOREIGN KEY (pnum) REFERENCES P(pnum) ON DELETE SET NULL DEFERRABLE INITIALLY IMMEDIATE, CONSTRAINT fk_spj_3 FOREIGN KEY (jnum) REFERENCES J(jnum) -- just use default );

9. Constraints on Attributes and Tuples • Limits the values of some attributes. • Constraints within relations • Defined in relation's schema as: • Constraints on an attribute • Constraints on tuples

10. Constraints on the attributes • Not-null constraints e.g. pnum CHAR(3) NOT NULL, CONSTRAINT fk_spj_2 FOREIGN KEY (pnum) REFERENCES P(pnum) , • Attribute-Based CHECK • Checked whenever any tuple gets a new value for this attribute (e.g. update, insert) • Reject violating operations • The check is expressed as a conditional expression e.g. qty INT CHECK (qty <= 10000), • Invisible to other relations (so, can be violated if the relations referenced in the condition are changed) • More examples in text Pp. 328 ex. 7.8, 7.9

11. Tuple-Based CHECK Constraints • Applies to one or more attributes of a table • Checked when a tuple is inserted or updated. Reject if it's a violating operation. • Invisible to other relations (so, can be violated if the relations referenced in the condition are changed) • E.g. CREATE TABLE MovieStar( name CHAR(30) PRIMARY KEY, gender CHAR(1), CHECK (gender = 'F' OR name NOT LIKE'Ms.%') );

12. Modification of Constraints • Only to constraints that are named. • Naming of constraints examples: • snum char (5) CONSTRAINT pk_supplierPRIMARY KEY , • CONSTRAINT fk_spj_1 FOREIGN KEY (snum) REFERENCES S(snum) DEFERRABLE, • Gender CHAR(1) CONSTRAINT NoAndroCHECK (gender in ('F', 'M')),

13. Modifications • Delete constraints ALTER TABLE <tableName> DROP CONSTRAINT <constraintName>; • Add constraint ALTER TABLE <tableName> ADD CONSTRAINT <constraintName> <constraint specification>; e.g. ALTER TABLE student ADD CONSTRAINT PK_student PRIMARY KEY (studentkey); • Set constraint – to change a deferrable constraint from immediate to deferred and vise versa SETCONSTRAINT <constraintName> DEFERRED;

14. Assertions • An assertion is a schema level CHECK constraint. • Exist independent of any particular table. • It's condition can refer to any table in the db schema • Declaring an assertion: CREATE ASSERTION <constraintName> CHECK <condition> [constraint attributes]; • constraint attributes: [NOT] DEFERRABLE; INITIALLY IMMEDIATE; INITIALLY DEFERRED • The constraint is violated if the condition is false • Any db modifications that causes a violation will be rejected

15. Triggers • Available in Oracle and SQL99 • Event-Condition-Action rules: define an action the db should take when some db-related events occurs • Triggers are useful for: • To maintain complex integrity constraints • To audit changes made to table • To signal to other programs that changes were made to a table

16. Trigger vs. other constraints • Triggers are awakened when certain events, specified by db programmer, occur. E.g. update, insert, delete to a relation; end of a transaction • Other constraints immediately prevent the event if the constraint is violated. For trigger, it's condition is tested when the event occurs, if the condition does not hold, then the action associated with the trigger will not happen (I.e. trigger will not be fired) • If the trigger condition is true, the action is performed by the DBMS (I.e. trigger fired). So, it's transparent to the user

17. Trigger Syntax CREATE [OR REPLACE] TRIGGER <triggerName> {BEFORE | AFTER | INSTEADOF} {DELETE | INSERT | UPDATE [of column, …] } [OR {DELETE | INSERT | UPDATE [of column, …] } ON {tableName | viewName} [REFERENCING { OLD [AS] <oldName> , NEW [AS] <newName> …] FOR EACH {ROW | STATEMENT} [WHEN (condition) ] <action>;

18. Oracle Triggers • <action> is PL/SQL block Simplest is : BEGIN <SQL statement> END; In the PL/SQL action block, variables OLD and NEW are preceded by : e.g. :OLD • Follow the create trigger statement with a Dot (.) and then RUN to store the definition in the db • The action cannot change the relation that triggers the action, nor to relations connected to the triggering relation by a constraint e.g. FK constraint • Read 7.4.2 – 7.4.4

19. SQL3 Triggers • <action> can be: • a single SQL statement • A SQL statements, separated by ; enclosed in a BEGIN <SQL statements> END;

20. Constraints Summary • Primary Key declaration • Foreign Key – referential integrity constraint • Constraints within relations: • Attribute constraints: 1. NOT NULL; 2. CHECK • Tuple based CHECKs • Schema level constraints – SQL2 assertions (not in Oracle) • Triggers – Oracles's and SQL99's

21. Ch. 8 - System Aspects of SQL • SQL in programming environments • Statement Level Interface • Embedded SQL, SQLJ • Dynamic SQL • PSM • Oracle’s PL/SQL • Call Level Interface • SQL environment

22. Host Language Interface • Host language: conventional language that applications are written in. e.g C, Java, C#, Visual Basic .Net • Statement level interface • Static: Embedded SQL, SQLJ • Dynamic SQL • Call level interface (CLI) • Use of CLI (e.g. JDBC) for static transaction is less efficient at run time than statement-level interfaces because CLI’s preparation and execution generally involve separate communications with the DBMS, which is costly.

23. Embedded SQL • Shared variables • Host language variables that can be read/written by SQL statement • Serves as interface between the host language and the SQL execution system • When used in embedded SQL statements, precede the variable with a : e.g. :name • Embedded SQL statements are prefixed with EXEC SQL • Preprocessor translate the EXEC SQL statements into function calls in host language, then compile, linked with SQL-related library to form executable code. Fig. 8.1 pp 351

24. Embedded SQL (continued) • SQLSTATE • a special variable (an array of 5 char) • Serves to connect the host-language program with the SQL execution system • updated each time a SQL library function is called • Some of the codes are: • ‘00000’ = no error • ‘02000’ = no tuple found

25. Embeddable SQL statements • Any SQL statement that does not return a result (I.e. not a select-from-where query) can be embedded. E.g. insert, delete, create, update. • select-from-where queries are not embeddable directly. • For connecting the result of queries with a host-language program, must use one of the following methods: • Use single-row select for query that produces a single tuple : select-into-from-where. Ref. fig. 8.3 pp 355 EXEC SQL SELECT A INTO :var FROM R WHERE <cond>; • Use CURSOR for queries producing more than one tuple Fig. 8.4 pp 357

26. CURSOR - Ref. Fig. 7.4 pp.379 (Fig. 8.4 pp 357) • An object used to store the output of a query for processing in an application. It provides the mechanism to reference the current position in a result set, and to do positioned updates and deletes. • Declare cursor in embedded SQL by: EXEC SQL DECLARE <cursor> CURSOR FOR <query> • Open cursor before use: EXEC SQL OPEN <cursor> • Use Fetch statement to get the next tuple of the relation over which the cursor range EXEC SQLFETCH FROM <cursor> INTO <list of shared variables> SQLSTATE of ‘02000’ means no more tuples found • To close a cursor when done: EXEC SQL CLOSE

27. Cursor options • INSENSITIVE guarantee that changes to underlying relation made between one opening and closing of cursor will not affect the set of tuples already fetched. • FOR READ ONLY DBMS will prevent modifications to the underlying relation through this cursor • SCROLL The cursor may be accessed with any one of the : FETCH {NEXT / PRIOR/ FIRST / LAST /RELATVE n/ ABSOLUTE n} • ResultSet in JDBC is a cursor

28. SQLJ • ANSI standard Statement-level Interface to JAVA • A dialect of embedded SQL that can be included in JAVA program • Goal: To obtain the run-time efficiency of embedded SQL for Java applications while retaining the advantage of accessing DBMS through JDBC • Embedded SQLJ constructs are replaced by calls to an SQLJ run-time package, which access database using JDBC. • Benefit: the pre-compiler (translator in Oracle) can check SQL syntax and the number and types of arguments and results.

29. Differences between SQLJ, Embedded SQL and JDBC • SQLJ supports essentially SQL-92, much more portable across DBMS vendors. For embedded SQL, each DBMS vendor supports its own proprietary version of SQL. • An SQLJ clause in a JAVA program begin with #SQL instead of EXEC SQL, and can contain select-from-where statement inside { } • Any JAVA variables can be included as a parameter in an SQL statement (prefix the variable with : ) , same as in embedded SQL • In SQLJ, a query returns an SQLJ interator object instead of a ResultSet object (as in JDBC). But, it’s similar to ResultSet in that they provide a cursor mechanism. • Both SQLJ statement and JDBC calls can be included in the same Java program

30. Oracle’s SQLJ script • To use: sqlj file.sqlj • Many command lines options are availabe, refer to Oracle developer guide at http://otn.oracle.com/tech/java/sqlj_jdbc/pdf/a96655.pdf • Invokes translator to preprocess java programs with SQLJ clauses (suffix of those files can be .sqlj, .java). Translator generates .java file which contains the JDBC calls for the SQL statements • Invokes javac to compile • Invokes JVM to execute

31. Dynamic SQL • Used when the SQL statement is not known at compile time • E.g. an application that prompt the user for an SQL query, read, and then execute the query (can you think of an application?) • Host language program must instruct SQL to: • Take a string and turn it into an executable SQL statement: EXEC SQL PREPARE sqlvar FROM sharedVar; • Execute the prepared statement: EXEC SQL EXECUTE sqlvar;

32. Dynamic SQL (continued) • Steps 1 and 2 can be combined by: EXEC SQL EXECUTE IMMEDIATE sharedVar; • The 2 steps approach is beneficial if a prepared statement is execute multiple times. • Ref. Fig. 8.7 pp. 368