LU05 – SQL SELECT S TATEMENT A GGREGATES AND S UB -Q UERIES / SQL V IEWS
C ONTENTS
LU04 – SQL SELECT Statement Aggregates and Sub-Queries / SQL Views ....................................................................1
Learning Objectives ...................................................................................................................................................1
SQL Goals ...............................................................................................................................................................2
Part 1: SELECT Aggregates .........................................................................................................................................2
Recall: SQL Aggregate functions ............................................................................................................................3
Part2: Sub-Selects: Queries within Queries ...............................................................................................................5
Derived Queries .....................................................................................................................................................6
Part 3: External Model 101 - SQL Views ....................................................................................................................7
References .................................................................................................................................................................7
L EARNING O BJECTIVES
Last week we were introduced to the SQL SELECT statement. This week we’ll take the covers off and dive really
deep into the SELECT statement. We explore some additional SQL capabilities; aggregate (summarize) data, and
write sub queries. f you look at our methodology below you can see that we are still in the implementation phase
of the SDLC. Upon completion of this learning unit you should be able to:

Compare, contrast scalar and aggregate functions.

Describe and use various ways to join tables.

Solve problems using aggregate functions and joins.

Compare join and sub queries.

Understand how to use special constructs on the SELECT statement.
1/7
SQL G OALS
Our SQL goals for this learning unit will be to:
1. Understand aggregates and using the GROUP BY and HAVING clauses on the SELECT
statement.
2. Understand sub-SELECTS and sub-queries
P ART 1: SELECT A GGREGATES
Aggregates allow you to group and/or summarize rows of data. The syntax diagram for the basic select statement
is as follows:
SELECT {colname [, ..n] | * }
FROM tablename
[WHERE pre-group-by-condition]
[GROUP BY colname [DESC] [, ..n]]
[HAVING post-group-by-condition]
[ORDER BY colname [DESC] [, ..n]]
Some notes on the select statement:

Every column included in the select statement must either appear in GROUP BY or use an aggregate
function.
2/7

The HAVING clause is like the WHERE clause, only it applied to the output after the GROUP BY clause,
as opposed to WHERE clause.

When using aggregate functions, the HAVING is optional but the GROUP BY is not.
R ECALL : SQL A GGREGATE
FUNCTIONS
Count(column)
Count the values of column
sum(column)
Total the values in column
min(column)
Retrieve the smallest value in column
max(column)
Retrieve the largest value in column
avg(column)
Retrieve average of column
Example 1: Some basic aggregates in action:
3/7
Example 2: Illustrating the need for group by over non-aggregates (Incorrect)
Example 3: Illustrating the need for group by over non-aggregates (Correct)
Example 4: Illustrating the use of HAVING.
Notice the AVG(employee_hourlywage) is used in the HAVING clause and not the alias name of
average_hourlywage. That is because column aliasing occurs last in the SELECT process:
4/7
P ART 2: S UB -S ELECTS : Q UERIES
WITHIN
Q UERIES
Sub queries are The easiest way to explain why you’d need a sub-query is to give you an example. Its easy to write
a SELECT statement to output all employees making more than a specific value, such as $50,000:
But what about showing all employees making more than the average? We learned in the pervious section, we can
use aggregates to determine the average salary:
5/7
Okay, but how to we display all employees making more than the average, and what does this have to do with subselects? Consider the following:
And viola! You have your answer to both questions!
You can place a sub select anywhere SQL is normally looking for a column name or expression. You can also use the
IN or NOT IN keywords retrieve data based on the condition of data in another table. For example, this query
displays all employees who work in a store with zip code 12345:
Consider the following example. Fudgemart employees who are ‘Department Managers’ are salaried, and thus get
paid for no more than 40 hours, regardless of how many they work. So, you might need SQL like this to update
their timecards to 40 hours based on their job title:
It should be noted this can also be done using a join:
Why use the sub-select query when the name data can be express with a join? That is a matter of personal
preference and readability, but not all queries can be expressed with joins (the first example is a good example of
this) so sub-selects do have their place. BTW: Most DBMS’s are good at optimizing SQL queries so that both
queries, which in effect accomplish the same thing, perform in the same manner.
D ERIVED Q UERIES
A derived query is a type of sub-select which contains an SQL SELECT statement in the FROM clause of a main
SELECT statement. In the example below, the SELECT statement in parenthesis is executed first and then the
output is aliased as the table fmap. This aliased table is then used as part of the main query, which displays the
product_id and product_name.
While the example you see could be implemented without a derived query, there are several examples of queries
where this is the only way to accomplish the task. How do you know? Well in my experience when I can’t get the
results I want through a join or a sub-select in the where clause.
6/7
P ART 3: E XTERNAL M ODEL 101 - SQL V IEWS
Part of building a database involves creating SQL Select statements to display output matching the end-user’s
requirements. Queries such as “Total quantity on hand by region”, and “Employees, departments, and managers”
are easy to understand in concept, but can be quite difficult for the end-user to implement in SQL because of the
inherent complexity of the SELECT statement. If we could abstract the complexity of these SQL statements into
their own virtual tables it would be easier for the end user to digest that complexity. This is the fundamental
purpose of the SQL View.
An SQL View is a type of meta-data. It allows you to store an SQL SELECT statement under an object name, which
in turn can be queried as a table. Since views are meta-data, they reside in the DML family of SQL statements, and
have corresponding CREATE VIEW, ALTER VIEW and DROP VIEW statements. Here’s the syntax of the CREATE VIEW
statement:
CREATE VIEW viewname AS select-query-statement
Once you’ve created your view you can access it just like it was a normal table. In addition you can update, delete,
and insert data into a view as long the SELECT statement defined in the view does not contain aggregates, joins,
and calculated columns or violate any table constraints. The benefit of the View to the external model cannot be
overlooked; views are the vehicle a database designer uses to abstract the complexities of the internal model from
the users of the database.
Example: Creating a view
R EFERENCES

Rob, Ch 6

Bordodli Ch 5,6,7

Whitehorn, Ch 28

Microsoft SQL 2005 Books online

Home of SQL Cookbook and Recipies http://www.sqlrecipes.com/
7/7