View 1

Lu Chaojun, SJTU 2 View Three-level vision of DB users Virtual DB views DB Designer Logical DB relations DBA DBA Physical DB stored info

Lu Chaojun, SJTU 3 What’s a View? An expression that defines a table without physically creating it. Base table vs. view –Base table: physically stored, persistent –(Virtual )View: not physically stored, defined on base tables. Query and even modify views like tables

Lu Chaojun, SJTU 4 Def. in SQL:2003 SQL-data consists entirely of table variables, called base tables. An operation that references zero or more base tables and returns a table is called a query. The result of a query is called a derived table. A view is a named query, which can be invoked by use of this name. The result of such an invocation is called a viewed table.

Lu Chaojun, SJTU 5 Why Views? To hide some data from the users To make certain queries easier or more natural to express For modularity

Lu Chaojun, SJTU 6 View Declaration CREATE VIEW viewname(A1,...,An) AS query; Example CREATE VIEW CS_S AS SELECT sno,name,age FROM Student WHERE dept = ‘CS’; Only definition of views are stored.

Lu Chaojun, SJTU 7 Querying Views Query a view as if it were a stored table. Queries on views are translated into queries on base tables. –Simplest: replace view by its definition (a subquery) Example SELECT name FROM CS_S WHERE age = 18; SELECT name FROM (SELECT sno,name,age FROM Student WHERE dept = ‘CS’) css WHERE age = 18; –Q: Two consecutive queries on CS_S always return the same result?

Lu Chaojun, SJTU 8 Example: Join View Creation of view SN_C CREATE VIEW SN_C AS SELECT name,cno FROM S,SC WHERE S.sno = SC.sno; Query on SN_C SELECT name FROM SN_C WHERE cno = ‘C2’; –no join?

Lu Chaojun, SJTU 9 Example: Renaming Attributes 1. CREATE VIEW CS_S(id,sn,sa) AS SELECT sno, name, age FROM Student WHERE dept = ‘CS’; 2. CREATE VIEW S_G(sno,avggrade) AS SELECT sno, AVG(grade) FROM SC GROUP BY sno;

Lu Chaojun, SJTU 10 Example: Views on Views CREATE VIEW CS_S_20 AS SELECT sno,name FROM CS_S WHERE age=20;

Lu Chaojun, SJTU 11 Modifying Views Updatable view: it’s possible to translate the modification of the view into an equivalent modification on a base table. –Complex rules in SQL standard Example: S_G is not an updatable view. INSERT INTO S_G VALUES (‘007’, 80); –Causes what tuple to be inserted into SC?

Updatable Views FROM only one relation R ( which may itself be an updatable view) WHERE must not involve R in a subquery SELECT (not SELECT DISTINCT) some attributes –Enough for insertion into the underlying R Lu Chaojun, SJTU 12

Example CS_S is updatable, but has anomaly: INSERT INTO CS_S VALUES (‘007’,’james’,18); –causes (‘007’,’james’,18,NULL) to be inserted into Student, which can’t be restored into CS_S –Attributes not enough Lu Chaojun, SJTU 13

Lu Chaojun, SJTU 14 Drop Views DROP VIEW viewname; Definition of view is dropped. Underlying base tables are not affected. DROP TABLE will affect views defined on it.

Instead-Of Triggers on Views Actions of trigger is done instead of the event (modification on a view) itself. The programmer can force whatever interpretation of a view modification is desired. Lu Chaojun, SJTU 15

Example CREATE TRIGGER insertCSS INSTEAD OF INSERT ON CS_S REFERENCING NEW ROW AS nr FOR EACH ROW INSERT INTO Student VALUES(nr.sno,nr.name,nr.age,’CS’); Lu Chaojun, SJTU 16

Materialized Views Views are logical descriptions of relations that are constructed from base tables by executing a query. –Querying a view = executing the query If a view is used frequently enough, it may be efficient to materialize it. CREATE MATERIALIZED VIEW CS_S AS SELECT sno,name,age FROM S WHERE dept=‘CS’; Lu Chaojun, SJTU 17

Maintaining a MV Problem: each time a base table changes, the materialized view may change. –Cannot afford to recompute the view with each change. –Incremental maintainence: Base table R  Materialized view V  R   V Example:  S vs  CS_S insert into S insert into CS_S values(a,b,c,’CS’) values(a,b,c) Lu Chaojun, SJTU 18

Periodic Maintainence of MV Data warehouse: create MV (of aggregations), but not to keep it up-to-date. –Frequent modification: expensive –Used for analysis: unnecessary Periodic maintainence is OK, say each night. Lu Chaojun, SJTU 19

Example Wal-Mart stores every sale at every store in a database. Overnight, the sales for the day are used to update the data warehouse = materialized views of the sales. The warehouse is used by analysts to predict trends and move goods to where they are selling best. Lu Chaojun, SJTU 20

Rewriting Queries to Use MV Given MV V: SELECT L V FROM R V WHERE C V ; and query Q: SELECT L Q FROM R Q WHERE C Q ; If i) R V  R Q ii) C Q = C V AND C iii) (L Q  R V )  L V Then rewrite Q: SELECT L Q FROM V, R Q  R V WHERE C; Lu Chaojun, SJTU 21

Indexes in SQL 22

What’s an Index? An index on R.A is a data structure that makes it efficient to find tuples having a fixed value for A. –A is the index key. –Index key can be any attribute or set of attributes, not necessarily the key of R. Implementation of index –B-tree or B+-tree Lu Chaojun, SJTU 23 key ptr a a b 23

Lu Chaojun, SJTU 24 Why Index? Speed up queries, especially of forms R.A = value R.A <= value Also speed up joins –Use index to find matching tuples Make queries faster, but modifications slower.

Declaring Indexes No standard! Typical syntax: CREATE INDEX nameInd ON S(name); CREATE INDEX scInd ON SC(sno,cno); Dropping a index: DROP INDEX nameInd; Lu Chaojun, SJTU 25

Selection of Indexes Design Issue: deciding which indexes to create. –Cost model: number of block I/O’s Pro: An index speeds up queries that can use it. Con: An index slows down modifications because the index must be modified too. Lu Chaojun, SJTU 26

Useful Indexes Index on key of relation: e.g. S(sno) –Queries are often of the form: SELECT … FROM … WHERE sno = … –At most return one location (page) Index on attribute which is almost a key: e.g. S(name) –Return few locations Index on attribute on which tuples are clustered: e.g. S(dept) –Few blocks Lu Chaojun, SJTU 27

Lu Chaojun, SJTU 28 Calculating the Best Indexes The more indexes the better? –No! Modification will be expensive. To create best indexes, we need information about which queries and modifications are most likely to be performed on DB. –Get info from history. –Get info from app code.

Example: Cost Estimation SC(sno,cno) Q 1 : SELECT cno FROM SC WHERE sno=‘xxx’; Q 2 : SELECT sno FROM SC WHERE cno=‘yyy’; I: INSERT INTO SC VALUES(‘xxx’,’yyy’); Prob(Q 1 ) = p 1, Prob(Q 2 ) = p 2, Prob(I ) = p 3 =1  p 1  p 2 SC occupies n blocks. On the average, ‘xxx’ takes c courses and ‘yyy’ is taken by s students. Lu Chaojun, SJTU 29 actionno indexindex on snoindex on cnoboth index Q1Q1 n1+cn Q2Q2 nn1+s I2446 Averagenp 1 +np 2 +2p 3 (1+c)p 1 +np 2 +4p 3 np 1 +(1+s)p 2 +4p 3 (1+c)p 1 +(1+s)p 2 +6p 3

Automatic Selection of Indexes Tuning advisor –Establish a query workload. According to history or application programs. –Specify constraints, if any. –Generates candidate indexes and evaluates each. Feed sample query to the query optimizer, which assumes only this one index is available. –The index set resulting the lowest cost is suggested, or automatically created. Lu Chaojun, SJTU 30

End