SQL Unit 6
Views and Temporary Tables
Kirk Scott
1
•
•
•
•
•
•
6.1
6.2
6.3
6.4
6.5
6.6
Introduction
Enabling Database Content in MS Access
Temporary Tables
Views
Inline Views
Details
2
6.1 Introduction
• It is possible to write relatively complex SQL
queries.
• Queries can include more than one table, have
multiple conditions, etc.
• When queries become complex, people don't just
sit down and write them from beginning to end.
• They break the problem into pieces, try to solve
the pieces, and then put the solutions together
into a whole.
3
• In previous units some examples have come
up where something can't be done in Access
SQL.
• For example, this query won't work:
•
• SELECT COUNT(DISTINCT stickerprice)
• FROM Car
4
• It is perfectly reasonable to want to count the
number of distinct values of the stickerprice
field in the Car table, but this syntax isn't
supported.
• This obviously has two parts, count, and
distinct, and it is reasonable to think that you
could get the solution by doing it in steps.
5
• This would be a plan of action:
• 1. Create a new table which would just hold
stickerprice values.
• 2. Write a query to find the distinct
stickerprices and enter them into the table.
• 3. Write a query that would count the
number of stickerprices in the new table.
6
• Step two, entering the results of the first
query into a table, is obviously impractical as
given.
• If you're going to enter the results of the
query into the new table by hand, you might
as well just count them by hand.
• However, as you will see, there is SQL syntax
for creating a table in mid-stream, using the
results of a query
7
• Creating tables midstream is a stepping-stone
• If you can do things step-by-step, it will turn
out that you can eventually combine multiple
steps into a single, more complicated query
which consists of multiple parts corresponding
to the steps
8
6.2 Enabling Database Content in MS
Access
9
• Using SQL it will be possible to create a new table
out of the results of a query
• If you try to run a query in MS Access that creates
a table you may not have success.
• In this situation, it will be apparent that the query
won’t run, and the only indication of what's
wrong will consist of a temporary message that
appears at the bottom of the Access window:
• "The action or event has been blocked by
Disabled Mode."
10
• The overheads in this section explain how to
deal with this situation
• You will not be tested on this stuff
• It is just presented in case you run into
problems when doing homework
• If you forget the steps shown below, all you
have to do is go to Help in the menu and
search for "Disabled Mode" for an
explanation.
11
• The screen shot on the next overhead shows
the “blocked by Disabled Mode” message as it
appears at the bottom of the Access screen
12
13
• It is possible that in your installation of MS Access the
so-called Message Bar already appears
• If so, you can just breeze through the following steps
• If the Message Bar doesn’t appear, then the first step in
dealing with the “blocked by Disabled Mode” problem
is to make sure that the Message Bar appears on the
screen.
• To show the Message Bar, go to the Database Tools tab
and check the Message Bar box.
• See the screen shot below and find the Tools/Message
Bar check box.
14
15
• The screen shot below shows the window
with the Message bar showing
• It has a Security Warning which you would see
after you’d tried to run a query in Disabled
Mode.
16
17
• The Message bar includes an Options button.
• Once you’ve got the Options button showing,
the next step is to click on it.
• When you do so, you’ll get a Security Alert box
with an option allowing you to “Enable this
content”
• You should select that option.
18
19
• After selecting the option, you should click OK.
• After taking all of these steps, it should be
possible to run the query—but not necessarily
immediately.
• After clicking OK in the Security Alert, it may
be necessary to close the query and then try
to run it again before it will work.
20
6.3 Temporary Tables
• There is SQL syntax which makes it possible to
create a table directly from query results.
• Such a table is known as a temporary table.
• The table is not really temporary, but it is
different from the tables that exist in the
original database design
21
• It is convenient to be able to create a table
from query results.
• The goal is to divide and conquer, obtaining a
complex query result by working with two
parts.
• The first part consists of making the
temporary table.
• The second part consists of writing a query
that uses the temporary table.
22
• This is the example of syntax that doesn’t
work in Access:
• SELECT COUNT(DISTINCT stickerprice)
• FROM Car
• It should be possible to find the distinct
stickerprices first and then count them
23
• 1. The following query accomplishes the first
part.
• It selects the distinct stickerprices from the
Car table, creating the temporary table
Distinctpricetable in the process.
• SELECT DISTINCT stickerprice INTO
Distinctpricetable
• FROM Car
24
• 2. The following query accomplishes the
second part.
• It selects the count of the stickerprices in the
temporary table, Distinctpricetable.
•
• SELECT COUNT(stickerprice)
• FROM Distinctpricetable
25
• It is important to understand that even though
the intermediate table created by this process,
Distinctpricetable, is known as a temporary
table, it is persistent.
• It will show up in Access under the table tab
as a real live table containing data.
• It will contain a snapshot based on the
contents of the Car table at the time the query
was run that created it.
26
• Once Distinctpricetable has been created,
subsequent changes to the Car table will have
no effect its contents
• On the other hand, if you run the query that
creates Distinctpricetable again, you will wipe
out whatever it previously contained
• If changes to the Car table have been made in
the meantime, then the new version of
Distinctpricetable will reflect them
27
6.4 Views
• 1. The topic of views will be introduced by
solving the problem of the previous example
in a different way.
• The following query generates results
containing the distinct stickerprices of the Car
table
•
• SELECT DISTINCT stickerprice
• FROM Car
28
• Let the query itself be saved under the name
Distinctpricequery.
• Notice that the results of the query are not
saved as a temporary table.
• A saved, named query is a view.
• In SQL syntax you can define something which
is known as a view
• In MS Access, you simply save the query that
defines the view
29
• 2. A view, the saved query, can play the role of a
table in another query.
• You use the name of the view in place of the
name of a table
• This query counts the number of stickerprices in
the results of the saved query.
•
• SELECT COUNT(stickerprice)
• FROM Distinctpricequery
30
• Distinctpricequery is playing the same role
here as Distinctpricetable did in the previous
approach.
• It appears after FROM, and is the thing that
this query selects results from
• It is important to understand that although
the results are the same, the two approaches
work differently.
31
• 3. Views will now be explained in detail.
• In SQL the term "view" is used to describe
defining a query and saving that query for
future use.
• The SQL syntax happens to start with "CREATE
VIEW".
32
• Because Microsoft Access supports the
naming and saving of queries directly, there is
no need to use the SQL syntax.
• A view is by definition a saved query.
• The idea will be illustrated with more
examples.
33
• The query below selects the vin and all of the
monetary fields from the Car table.
• Let the query be saved under the name
Carmoneyview.
•
• SELECT vin, stickerprice, dealercost
• FROM Car
34
• 4. It is the SQL code that is saved under the
name Carmoneyview, not the results of the
query.
• This saved query can be used just like a table
in another query.
•
• SELECT vin, stickerprice
• FROM Carmoneyview
35
• 5. To emphasize the point that what you’re
using is a saved query (not a temporary table),
suppose that the query above was run.
• Then the following new record is entered into
the base table, Car.
•
• 'qqqqq', 'Chevrolet', 'Impala', 2002, 8000.00,
7500
36
• 6. Then suppose the same query which selects
from the saved query is run again.
•
• SELECT vin, stickerprice
• FROM Carmoneyview
• The results of this query on Carmoneyview will be
different from what they were before the
insertion of the new record into Car.
37
• The results of the query will include a record
with the values 'qqqqq' and 8000.00.
• The results change because every time this
query is run, the underlying saved query,
Carmoneyview, is run again
38
• The results of the Carmoneyview query will
always reflect the current state of the Car
table, including any changes that have been
made in it since the last time the query was
run.
• Notice how this is different from temporary
tables
• Temporary tables are static
• Views are dynamic
39
• 7. Now consider changing the saved query,
Carmoneyview, so that its results would be
ordered.
•
• SELECT vin, stickerprice, dealercost
• FROM Car
• ORDER BY stickerprice
40
• 8. Then if you ran this query again, which uses
the saved query like a table, its results would
also be ordered.
•
• SELECT vin, stickerprice
• FROM Carmoneyview
41
• 9. It may be convenient to rename the fields
when defining a view.
• Let Carmoneyview be redefined in this way
using column aliases.
•
• SELECT vin AS v, stickerprice AS sp, dealercost
AS dc
• FROM Car
42
• 10. Then if you used the view in another
query, you would have to use the new field
names.
•
• SELECT v, sp
• FROM Carmoneyview
43
• 11. It is important to understand that you can use a
view in a query in any way that a table can be used.
• Here is a join query that uses the view Carmoneyview.
•
• SELECT v, sp, salesprice
• FROM Carmoneyview, Carsale
• WHERE v = vin
•
• Notice that the names of the fields in the joining
condition don't have to be qualified with table names
because vin was given the alias v in Carmoneyview.
44
• 12. As noted earlier, if you change the base
table, the next time you make use of a saved
query on that table, any changes in the base
table will be reflected.
• This process also goes in the other direction.
• If you insert, update, or delete records in the
view, these changes go directly to the base
table.
45
• The base table name and the view name are
equally valid handles for doing anything that
it's possible to do in SQL, including changing
the contents of a table.
• The SQL syntax for inserting, updating, and
deleting will be covered in full in Unit 10.
• However, a small example will be given here
that uses that syntax and illustrates the power
of a view as a handle on a table
46
• This example has the effect of finding a
specified record using the view and then
changing one of the field values for it:
•
• UPDATE Carmoneyview
• SET sp = 5000
• WHERE v = 'qqqqq'
47
• 13. If you then ran the following query on the
Car table, you would discover that the
stickerprice for the car with vin = 'qqqqq' is
now 5000.
•
• SELECT vin, stickerprice
• FROM Car
• WHERE vin = 'qqqqq'
48
• A view is always based on one or more real
tables.
• If you make changes to the fields selected in
the view, the changes are actually made in the
table that the view is based on.
• The name of the view is just as valid a handle
for referring to the base table as the name of
the table itself is.
49
• A student asked once whether this
functionality of a view depends on its
containing the primary key value
• In theory it doesn’t, and in practice, in Access,
it doesn’t
• An example emphasizing this idea follows
50
• The following could be saved as MyView:
• SELECT stickerprice AS sp, dealercost AS dc
• FROM Car
51
• This query updates all of the relevant rows of
the Car table even though the view doesn’t
contain the primary key of the Car table:
• UPDATE MyView
• SET sp = 5000
• WHERE dc = 16500
52
• 14. A final way of describing what is happening
with saved queries is that any results generated
by a saved query are completely transient.
• The query is saved, but the results are not saved.
• Every time a query is run which uses a saved
query in the role of a table, the results of the
saved subquery are generated again at run time
based on the values in the table or tables
contained in the saved query’s definition.
53
• Temporary tables and views can both be used
to divide and conquer a problem
• In a sense, their uses in this regard are similar
• However, there is a big difference between
temporary tables and views.
54
•
•
•
•
Temporary tables are misnamed.
They aren’t temporary, they’re persistent.
They are also static.
Once they’ve been created, changes to the
tables that they were based on don’t affect
the contents of the temporary table.
55
• Views are saved queries.
• What is saved is the SQL syntax, not the
results of running it.
• The saved syntax is persistent, but the results
are not.
56
• Every time the view is used, its results are
generated or materialized again.
• This means that views are dynamic.
• Changes to the tables that they were based on
are reflected in the results every time a view is
used.
57
6.5 Inline Views
• 1. The term "inline view" refers to the idea that
any query that makes use of a view could be
rewritten with the view simply appearing as a
parenthesized, nested subquery in the overall
query.
• As above, let this query be saved as
Carmoneyview:
•
• SELECT vin, stickerprice, dealercost
• FROM Car
58
• Then, as shown, it's possible to write this
query:
•
• SELECT vin, stickerprice
• FROM Carmoneyview
59
• The query shown below is literally what is
executed at run time.
• It is also a perfectly legitimate query in its own
right.
•
• SELECT vin, stickerprice
• FROM
• (SELECT vin, stickerprice, dealercost
• FROM Car)
60
• At run time, the inner query inside the
parentheses is run first, bringing its results
into existence in real time, and then the outer
query operates on those results to produce
the final results.
• The inner, parenthesized part of the query is a
subquery
• This subquery is an inline view.
61
• So when solving a problem by dividing and
conquering, the first part of the solution
doesn’t have to be saved as a separate query
or view
• All you have to do is remember it, and write
the second part of the solution using it
• The example query isn’t particularly useful,
but it could literally be written and run as
shown.
62
• The inline view has another important
characteristic that stems from the way views
work.
• The inline view, the complete, parenthesized
subquery, is playing the role of a table in the
FROM clause of the outer query.
• Even though the inline view is contained
within parentheses, its fields are available for
use in the outer query.
63
• 2. The problem of counting the distinct
salesprices gives a more useful example.
• As shown earlier, let this query be saved as
Distinctpricequery:
•
• SELECT DISTINCT stickerprice
• FROM Car
64
• Then it's possible to write this query:
•
• SELECT COUNT(stickerprice)
• FROM Distinctpricequery
65
•
•
•
•
•
•
•
•
This is literally what is executed at run time:
SELECT COUNT(stickerprice)
FROM
(SELECT DISTINCT stickerprice
FROM Car)
The outer query is free to make use of the field
stickerprice, which is defined in the Car table and
selected in the results of the inline view
66
• 3. Nested queries in general are an important
topic.
• Here are a few more examples.
• You would probably not write these queries
using inline views, but they do illustrate in
greater detail how inline views work.
67
• Here is a query that accomplishes the same thing
that could be done with a query using the
keyword AND:
•
• SELECT vin, stickerprice
• FROM
• (SELECT vin, stickerprice, dealercost
• FROM Car
• WHERE dealercost < 10000)
• WHERE stickerprice > 10000
68
• Here is a query that accomplishes the same thing
that could be done with a non-nested join:
•
• SELECT vin, stickerprice, salesprice
• FROM Carsale,
• (SELECT vin AS v, stickerprice, dealercost
• FROM Car)
• WHERE vin = v
69
• In this query, the joining fields vin and v "cross"
parenthesis boundaries.
• Fields defined in the inner query can be used in
the outer query.
• It's convenient to give vin the alias v in the nested
query.
• This makes it possible to SELECT vin and write the
joining condition in the WHERE clause as vin = v
without having to qualify vin with the respective
tables it appears in.
70
• It would also be possible to write the query
this way:
•
• SELECT Car.vin, stickerprice, salesprice
• FROM Carsale,
• (SELECT vin, stickerprice, dealercost
• FROM Car)
• WHERE Carsale.vin = Car.vin
71
6.6 Details
• Inline views are one of those cases where the
Microsoft Access design view can become
inconvenient.
• In all of the examples in this set of notes, the
simplest possible syntax was shown.
• Unfortunately, if you save the query and then
go back later to edit it, it will frequently look
different from the way you typed it in.
72
• For example, table or field aliases may be set
off with square brackets or quotes, dot
notation may be used in unexpected places,
and so on.
• The original inline view query is shown below,
followed by what you might see if you saved it
and opened it again in the SQL view.
73
• SELECT vin, stickerprice
• FROM
• (SELECT vin, stickerprice, dealercost
• FROM Car)
• SELECT vin, stickerprice
• FROM (SELECT vin, stickerprice, dealercost
• FROM Car) AS [%$##@_Alias];
74
• It doesn't make sense to try to master this
complex (and needless) notation, but you
shouldn't be surprised when you run into it.
• Unfortunately, it’s potentially unavoidable.
75
• You may write an inline query and find that it
doesn't produce the desired results.
• If you saved it and reopen it to fix it, you will
have a choice:
• Try to deal with Access’s crazy changes to
what you wrote, or try to write the correct
query again from scratch.
76
The End
77