1
a. ON event IF precondition THEN action.  SQL:1999.
b. ON inserting a row in a table of students registered for a course, IF the
   class is full, THEN delete something from the database.
c. A request to execute a database operation.
   The execution of an SQL INSERT, DELETE, and UPDATE statement as a whole
   or a change to individual rows made by such a statement.
d. When the precondition is checked.
   When the action is executed.
2
a. Statement-level interface:
   Call-level interface:
b. Embedded SQL: SQL statements are prepared at compile-time.
   Dynamic SQL: SQL statements are strings of host language that are processed
   at run-time.
c. Same: SQL statements are host language strings processed at run-time.
   Diff: Dynamic SQL is a statement-level interface, not a call-lvl interface.
d. Scrolling or not.  Insensitive or not.  Updatable or not
e. Database server.
   Intermediate data need not be communicated to application (more efficient).
   Application need not know database schema.
f. Transactions on each connection are committed separately.
   Default for a connection is autocommit mode, where each statement is a
   transaction.
   If autocommit is turned off, then transaction is committed or aborted using
   commit() or rollback() methods of the connection, and next transaction is 
   automatically initiated.
3
a. Minimize latency, and reduce number of page transfers.
   Store pages containing related information close together on disk.
   (Another one is to keep cache of recently accessed pages in main memory.)
b. 1000.  10.  4.
c. Integrated: index entries and rows are stored together, no pointer needs to
   be followed after an index entry is located.
   Separate: index entries and rows are stored in separately, a pointer needs
   to be followed after an index entry is located.
d. Yes.  With an integrated storage structure, index entries and rows are
   stored together, so they must have the same ordering.
e. No.  With a clustered index, index entries and rows are ordered in the same
   way.  If there was a second clustered index, it must be ordered in the same
   way as the first clustered index, so the two indices are the same.
f. No.  With unclustered index, index entries and rows are not ordered in the 
   same way.  Not indexed rows can not be located efficiently based on indexed
   rows.
4 
a. Multilevel (tree) indexing and hash indexing.
b. Former supports efficient range search, and partial key search.
   Latter is faster if good hash function can be used to elim overflow chains.
c. middle-level: left node, left square: acc; right node, left square: bce
   root, left square: bb
d.	 	   -------------------
		   | |  p  | |     | |
		   -/-------\---------
		   /         \
		  V           V
    -------------------    -------------------
    | |  f  | |     | |	   | |  t  | |     | |
    -/-------\---------	   -/-------|---------
    /         \            /        |
   V           V          V         V
  -----      -----      -----      -----
  |c|e|<---->|f|g|<---->|p|s|<---->|t| |
  -----      -----      -----      -----
e. mary, bill; john, tony; pete, jane; karl
f. k=3, and the bucket with john and tony is split into two:
   john and lucy in one, and tony in one.
5
a. SELECT P.name
   FROM Professor P, Teaching T
   WHERE P.id=T.profId AND P.deptId='CS' AND T.semester='F1994'
b. pi_name
     (sigma_{id=profId AND deptId='CS' AND semester='F1994'}
       (Professor x Teaching))
c. pi_name
     (sigma_{deptId='CS'} (Professor)
      join_{id=profId} 
      sigma_{semester='F1994'} (Teaching))
d. SELECT P.name
   FROM (SELECT * 
         FROM Professor 
	 WHERE deptId='CS') P,
        (SELECT * 
	 FROM Teaching 
	 WHERE semester='F1994') T
   WHERE P.id=T.profId
6
a. A. A. B.
b. Yes.  The intersection of S1 and S2 is B, and B is key of S2.
c. Yes and No.
   Yes if many rows in S have the same value of B, since for each value of B,
   the same value of C does not need to repeated that many times.
   No otherwise, since both S1 and S2 must contain B.
d. Yes and No.
   Yes if there are many records and there is much redundancy, since the table
   would be much bigger before decomposition and may lead to many more page
   faults and much slower query evaluation.  
   No, for queries otherwise.
   (Yes also for updates that involve only attributes B and A.)