Download Database Design: DBS CB, 2nd Edition

Introduction to
Database Systems,
CS420
SQL Views and Indexes
1
Agenda



2
View Definition
Materialized View
Indexes
Views


A view is a relation defined in terms of
stored tables (called base tables ) and
other views.
Two kinds:
Virtual = not stored in the database; just a
query for constructing the relation.
2. Materialized = actually constructed and
stored.
1.
3
Declaring Views

Declare by:
CREATE [MATERIALIZED] VIEW
<name> AS <query>;

Default is virtual.
4
Example: View Definition

CanDrink(drinker, beer) is a view “containing”
the drinker-beer pairs such that the drinker
frequents at least one bar that serves the beer:
CREATE VIEW CanDrink AS
SELECT drinker, beer
FROM Frequents, Sells
WHERE Frequents.bar = Sells.bar;
5
View Usage - Restricting Access

6
Provide an additional level of table security
by restricting access to a predetermined
set of rows or columns of a table
Example

7
the staff view does not show the salary or
commission_pct columns of the base table employees
View Usage - Hide Data Complexity

A single view can be defined with a join, which
is a collection of related columns or rows in
multiple tables



8
However, the view hides the fact that this
information actually originates from several tables
A query might also perform extensive
calculations with table information
Thus, users can query a view without knowing
how to perform a join or calculations
Example – Complex Query
A view can
be created
for it

9
View Usage - Different Presentation

Present the data in a different perspective
from that of the base table

For example, the columns of a view can
be renamed without affecting the tables on
which the view is based
10
View Usage - Independence
Isolate applications from changes in
definitions of base tables
 Example


A view references three columns of a four
column table
 A fifth column is added to the table
 The definition of the view is not affected
 All applications using the view are not affected
11
Example: Accessing a View

Query a view as if it were a base table.


12
Also: a limited ability to modify views if it
makes sense as a modification of one
underlying base table.
Example query:
SELECT beer FROM CanDrink
WHERE drinker = ’Sally’;
Triggers on Views
Generally, it is impossible to modify a
virtual view, because it doesn’t exist.
 But an INSTEAD OF trigger lets us
interpret view modifications in a way
that makes sense.
 Example: View Synergy has (drinker,
beer, bar) triples such that the bar
serves the beer, the drinker frequents
the bar and likes the beer.

13
Example: The View
Pick one copy of
each attribute
CREATE VIEW Synergy AS
SELECT Likes.drinker, Likes.beer, Sells.bar
FROM Likes, Sells, Frequents
WHERE Likes.drinker = Frequents.drinker
AND Likes.beer = Sells.beer
AND Sells.bar = Frequents.bar;
Natural join of Likes,
Sells, and Frequents
14
Interpreting a View Insertion
We cannot insert into Synergy --- it is a
virtual view.
 But we can use an INSTEAD OF trigger to
turn a (drinker, beer, bar) triple into three
insertions of projected pairs, one for each
of Likes, Sells, and Frequents.


15
Sells.price will have to be NULL.
The Trigger
CREATE TRIGGER ViewTrig
INSTEAD OF INSERT ON Synergy
REFERENCING NEW ROW AS n
FOR EACH ROW
BEGIN
INSERT INTO LIKES VALUES(n.drinker, n.beer);
INSERT INTO SELLS(bar, beer) VALUES(n.bar, n.beer);
INSERT INTO FREQUENTS VALUES(n.drinker, n.bar);
END;
16
Materialized View
17
Materialized Views (MVs)



18
Materialized views are query results that have
been stored or "materialized" in advance as
schema objects
The FROM clause of the query can name tables,
views, and materialized views
Collectively these objects are called master
tables (a replication term) or detail tables (a data
warehousing term)
A MV with 3 Tables

19
Creates and populates a materialized
aggregate view based on three master
tables
Base Table Dropped

Lets now drop table sales, which is a
master table for sales_mv

Then queries sales_mv.
20
Data Selected

21
The query selects data because the rows
are stored (materialized) separately from
the data in the master tables
Replication Environment

In a replication
environment, a
MV shares data
with a table in a
different
database, called
a master
database
22
MV Usage
Materialized views are used to summarize,
compute, replicate, and distribute data
 In data warehouses, you can use
materialized views to compute and store
data generated from aggregate functions
such as sums and averages

23
Example: A Data Warehouse
Wal-Mart stores every sale at every
store in a database.
 Overnight, the sales for the day are
used to update a 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.

24
What to Materialize?
Store in warehouse results useful for
common queries
total sales
 Example: day 2
...

day 1
c1
c2
c3
p1
44
4
p2 c1
c2
c3
p1
12
50
p2
11
8
p1
p2
materialize
25
c1
56
11
c2
4
8
c3
50
p1
c1
67
c2
12
c3
50
129
p1
p2
c1
110
19
Materialized Views Refresh

Problem: each time a base table changes,
the materialized view may change.


26
Cannot afford to recompute the view with each
change.
Solution: Periodic reconstruction of the
materialized view, which is otherwise “out
of date.”
Indexes
27
Indexes
Index = data structure used to speed
access to tuples of a relation, given values
of one or more attributes.
 Could be a hash table, but in a DBMS it is
always a balanced search tree with giant
nodes (a full disk page) called a B-tree.

28
Declaring Indexes
No standard!
 Typical syntax:
CREATE INDEX BeerInd ON
Beers(manf);

CREATE INDEX SellInd ON
Sells(bar, beer);
29
Using Indexes
Given a value v, the index takes us to only
those tuples that have v in the attribute(s)
of the index.
 Example: use BeerInd and SellInd to find
the prices of beers manufactured by
Pete’s and sold by Joe. (next slide)

30
Using Indexes - (2)
SELECT price FROM Beers, Sells
WHERE manf = ’Pete’’s’ AND
Beers.name = Sells.beer AND
bar = ’Joe’’s Bar’;
1.
2.
31
Use BeerInd to get all the beers made by
Pete’s.
Then use SellInd to get prices of those
beers, with bar = ’Joe’’s Bar’
Database Tuning
A major problem in making a database
run fast is deciding which indexes to
create.
 Pro: An index speeds up queries that can
use it.
 Con: An index slows down all
modifications on its relation because the
index must be modified too.

32
Example: Tuning

Suppose the only things we did with our
beers database was:
Insert new facts into a relation (10%).
2. Find the price of a given beer at a given bar
(90%).
1.

33
Then SellInd on Sells(bar, beer) would be
wonderful, but BeerInd on Beers(manf)
would be harmful.
Tuning Advisors

A major research thrust.


Because hand tuning is so hard.
An advisor gets a query load, e.g.:
Choose random queries from the history of
queries run on the database, or
2. Designer provides a sample workload.
1.
34
Tuning Advisors - (2)

The advisor generates candidate indexes
and evaluates each on the workload.

Feed each sample query to the query
optimizer, which assumes only this one index
is available.
 Measure the improvement/degradation in the
average running time of the queries.
35
Summary



36
View and MV definition
Usage cases
Indexes
END
37