Structured Query Language

(SQL)

B.Tech 5th CE
Dr. Neelam Duhan
(Associate Prof, CE)

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

SQL Overview
◼ Structured Query Language

◼ The standard for relational database

management systems (RDBMS)

◼ RDBMS: A database management system

that manages data as a collection of tables in
which all relationships are represented by
common values in related tables

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

 History of SQL

◼ 1970–E. F. Codd develops relational database concept

◼ 1974-1979–System R with Sequel (later SQL) created at IBM
Research Lab
◼ 1979–Oracle markets first relational DB with SQL
◼ 1981 – SQL/DS first available RDBMS system on DOS/VSE
◼ Others followed: INGRES (1981), IDM (1982), DG/SGL
(1984), Sybase (1986)
◼ 1986–ANSI SQL standard released
◼ 1987- ISO SQL standard released
◼ 1989, 1992, 1999, 2003, 2006, 2008–Major ANSI standard
updates
◼ Current–SQL is supported by most major database vendors

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Purpose of SQL Standard
◼ Specify syntax/semantics for data definition
and manipulation
◼ Define data structures and basic operations
◼ Enable portability of database definition and
application modules
◼ Specify minimal (level 1) and complete (level
2) standards
◼ Allow for later growth/enhancement to
standard (referential integrity, transaction
management, user-defined functions,
extended join operations, national character
sets)
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Codd’s 12 Rules for RDBMS

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

 Codd’s Rules
◼ Rule 0: The Foundation Rule
The database must be in relational form. So that the system can handle the database
through its relational capabilities.
◼ Rule 1: Information Rule
A database contains various information, and this information must be stored in each cell
of a table in the form of rows and columns.
◼ Rule 2: Guaranteed Access Rule
Every single or precise data (atomic value) may be accessed logically from a relational
database using the combination of primary key value, table name, and column name.
◼ Rule 3: Systematic Treatment of Null Values
This rule defines the systematic treatment of Null values in database records. The null
value has various meanings in the database, like missing the data, no value in a cell,
inappropriate information, unknown data and the primary key should not be null.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

 Codd’s Rules (Contd..)
◼ Rule 4: Active/Dynamic Online Catalog based on the relational model
It represents the entire logical structure of the descriptive database that must be
stored online and is known as a database dictionary. It authorizes users to access
the database and implement a similar query language to access the database.
◼ Rule 5: Comprehensive Data Sub Language Rule
The relational database supports various languages, and if we want to access the
database, the language must be the explicit, linear or well-defined syntax,
character strings and supports the comprehensive: data definition, view
definition, data manipulation, integrity constraints, and limit transaction
management operations. If the database allows access to the data without any
language, it is considered a violation of the database.
◼ Rule 6: View Updating Rule
All views table can be theoretically updated and must be practically updated by
the database systems.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

 Codd’s Rules (Contd..)
◼ Rule 7: Relational Level Operation (High-Level Insert, Update and delete) Rule
A database system should follow high-level relational operations such as insert, update,
and delete in each level or a single row. It also supports union, intersection and minus
operation in the database system.
◼ Rule 8: Physical Data Independence Rule
All stored data in a database or an application must be physically independent to access
the database. Each data should not depend on other data or an application. If data is
updated or the physical structure of the database is changed, it will not show any effect
on external applications that are accessing the data from the database.
◼ Rule 9: Logical Data Independence Rule
It is similar to physical data independence. It means, if any changes occurred to the logical
level (table structures), it should not affect the user's view (application). For example,
suppose a table either split into two tables, or two table joins to create a single table,
these changes should not be impacted on the user view application.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

 Codd’s Rules (Contd..)
◼ Rule 10: Integrity Independence Rule
A database must maintain integrity independence when inserting data into table's cells
using the SQL query language. All entered values should not be changed or rely on any
external factor or application to maintain integrity. It is also helpful in making the
database-independent for each front-end application.
◼ Rule 11: Distribution Independence Rule
This rule represents a database that must work properly, even if it is stored in different
locations and used by different end-users. Suppose a user accesses the database through
an application; in that case, they should not be aware that another user uses particular
data, and the data they always get is only located on one site. The end users can access
the database, and these access data should be independent for every user to perform the
SQL queries.
◼ Rule 12: Non Subversion Rule
The non-subversion rule defines RDBMS as a SQL language to store and manipulate the
data in the database. If a system has a low-level or separate language other than SQL to
access the database system, it should not subvert or bypass integrity to transform data.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Benefits of a Standardized Relational
Language

◼ Reduced training costs

◼ Productivity
◼ Application portability
◼ Application longevity
◼ Reduced dependence on a single vendor
◼ Cross-system communication

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

 SQL Environment

◼ Catalog
◼ A set of schemas that constitute the description of a database
◼ Schema
◼ The structure that contains descriptions of objects created by a user
(base tables, views, constraints)
◼ Data Definition Language (DDL)
◼ Commands that define a database, including creating, altering, and
dropping tables and establishing constraints
◼ Data Manipulation Language (DML)
◼ Commands that maintain and query a database
◼ Data Control Language (DCL)
◼ Commands that control a database, including administering
privileges and committing data
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
A simplified schematic of a typical SQL environment, as
described by the SQL: 2008 standard

12
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
 SQL Data Types
Example

Name CHAR(20)
Max Chars= 255

Name VARCHAR(40)
Max Chars= 4000

Salary NUMBER(4,2)
Max Precision= 38 digits

Salary INT

Level BOOLEAN

Date DATE Stores date in the format of system Date, format DateofBirth DATE
may be YYYY-MM-DD
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
DDL, DML, DCL, and the database development process

14
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
SQL Database Definition
◼ Data Definition Language (DDL)
◼ Major CREATE statements:
◼ CREATE SCHEMA–defines a portion of the
database owned by a particular user
◼ CREATE TABLE–defines a new table and its
columns
◼ CREATE VIEW–defines a logical table from one or
more tables or views
◼ Other CREATE statements: CHARACTER SET,
COLLATION, TRANSLATION, ASSERTION,
DOMAIN
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
 Steps in Table Creation
1. Identify data types for attributes
2. Identify columns that can and cannot be null
3. Identify columns that must be unique (candidate keys)
4. Identify primary key–foreign key mates
5. Determine default values
6. Identify constraints on columns (domain specifications)
7. Create the table and associated indexes

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

CREATE TABLE
◼ Specifies a new base relation by giving it a name, and
specifying each of its attributes and their data types
(INTEGER, FLOAT, DECIMAL(i,j), CHAR(n),
VARCHAR(n))
◼ A constraint NOT NULL may be specified on an attribute
CREATE TABLE DEPARTMENT (
DNAME VARCHAR(10) NOT NULL,
DNUMBER INTEGER NOT NULL,
MGRSSN CHAR(9),
MGRSTARTDATE CHAR(9) );

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

CREATE TABLE
◼ In SQL2, can use the CREATE TABLE command for specifying the primary
key attributes, secondary keys, and referential integrity constraints (foreign
keys).
◼ Key attributes can be specified via the PRIMARY KEY and UNIQUE phrases
CREATE TABLE DEPT (
DNAME VARCHAR(10) NOT NULL,
DNUMBER INTEGER NOT NULL,
MGRSSN CHAR(9),
MGRSTARTDATE CHAR(9),
PRIMARY KEY (DNUMBER),
UNIQUE (DNAME),
FOREIGN KEY (MGRSSN) REFERENCES EMP );

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

DROP TABLE
◼ Used to remove a relation (base table) and its
definition
◼ The relation can no longer be used in queries,
updates, or any other commands since its
description no longer exists
◼ Example:

DROP TABLE DEPENDENT;

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

ALTER TABLE
◼ Used to add an attribute to one of the base
relations
◼ The new attribute will have NULLs in all the tuples of
the relation right after the command is executed;
hence, the NOT NULL constraint is not allowed for
such an attribute
◼ Example:
ALTER TABLE EMPLOYEE ADD JOB
VARCHAR(12);

◼ The database users must still enter a value for

the new attribute JOB for each EMPLOYEE tuple.
◼ This can be done using the UPDATE command.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

REFERENTIAL INTEGRITY
OPTIONS
◼ We can specify RESTRICT, CASCADE, SET NULL or SET
DEFAULT on referential integrity constraints (foreign keys)
CREATE TABLE DEPT (
DNAME VARCHAR(10) NOT NULL,
DNUMBER INTEGER NOT NULL,
MGRSSN CHAR(9),
MGRSTARTDATE CHAR(9),
PRIMARY KEY (DNUMBER),
UNIQUE (DNAME),
FOREIGN KEY (MGRSSN) REFERENCES EMP
ON DELETE SET DEFAULT ON UPDATE
CASCADE);

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

REFERENTIAL INTEGRITY
OPTIONS (continued)
CREATE TABLE EMP(
ENAME VARCHAR(30) NOT NULL,
ESSN CHAR(9),
BDATE DATE,
DNO INTEGER DEFAULT 1,
SUPERSSN CHAR(9),
PRIMARY KEY (ESSN),
FOREIGN KEY (DNO) REFERENCES DEPT
ON DELETE SET DEFAULT ON UPDATE
CASCADE,
FOREIGN KEY (SUPERSSN) REFERENCES EMP
ON DELETE SET NULL ON UPDATE CASCADE);

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Additional Data Types in SQL2 and
SQL-99
Has DATE, TIME, and TIMESTAMP data types
◼ DATE:

◼ Made up of year-month-day in the format yyyy-mm-dd

◼ TIME:
◼ Made up of hour:minute:second in the format hh:mm:ss
◼ TIME(i):
◼ Made up of hour:minute:second plus i additional digits
specifying fractions of a second
◼ format is hh:mm:ss:ii...i

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Retrieval Queries in SQL
◼ SQL has one basic statement for retrieving information
from a database; the SELECT statement
◼ This is not the same as the SELECT operation of the
relational algebra
◼ Important distinction between SQL and the formal
relational model:
◼ SQL allows a table (relation) to have two or more tuples that
are identical in all their attribute values
◼ Hence, an SQL relation (table) is a multi-set (sometimes
called a bag) of tuples; it is not a set of tuples
◼ SQL relations can be constrained to be sets by specifying
PRIMARY KEY or UNIQUE attributes, or by using the
DISTINCT option in a query

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Retrieval Queries in SQL (contd.)
◼ A bag or multi-set is like a set, but an element
may appear more than once.
◼ Example: {A, B, C, A} is a bag. {A, B, C} is also a
bag that also is a set.
◼ Bags also resemble lists, but the order is irrelevant
in a bag.
◼ Example:
◼ {A, B, A} = {B, A, A} as bags
◼ However, [A, B, A] is not equal to [B, A, A] as lists

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Retrieval Queries in SQL (contd.)
◼ Basic form of the SQL SELECT statement is called a
mapping or a SELECT-FROM-WHERE block

SELECT <attribute list>

FROM <table list>
WHERE <condition>

◼ <attribute list> is a list of attribute names whose values are

to be retrieved by the query
◼ <table list> is a list of the relation names required to process
the query
◼ <condition> is a conditional (Boolean) expression that
identifies the tuples to be retrieved by the query

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Relational Database Schema

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Populated Database--Fig.5.6

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Simple SQL Queries
◼ Basic SQL queries correspond to using the
following operations of the relational algebra:
◼ SELECT
◼ PROJECT
◼ JOIN
◼ All subsequent examples use the COMPANY
database

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Simple SQL Queries (contd.)
◼ Example of a simple query on one relation
◼ Query 0: Retrieve the birthdate and address of the
employee whose name is 'John B. Smith'.
Q0:SELECT BDATE, ADDRESS
FROM EMPLOYEE
WHERE FNAME='John' AND MINIT='B’
AND LNAME='Smith’

◼ Similar to a SELECT-PROJECT pair of relational algebra

operations:
◼ The SELECT-clause specifies the projection attributes and the
WHERE-clause specifies the selection condition
◼ However, the result of the query may contain duplicate
tuples

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Simple SQL Queries (contd.)
◼ Query 1: Retrieve the name and address of all employees
who work for the 'Research' department.

Q1:SELECT FNAME, LNAME, ADDRESS

FROM EMPLOYEE, DEPARTMENT
WHERE DNAME='Research' AND DNUMBER=DNO

◼ Similar to a SELECT-PROJECT-JOIN sequence of

relational algebra operations
◼ (DNAME='Research') is a selection condition (corresponds
to a SELECT operation in relational algebra)
◼ (DNUMBER=DNO) is a join condition (corresponds to a
JOIN operation in relational algebra)

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Simple SQL Queries (contd.)
◼ Query 2: For every project located in 'Stafford', list the project number,
the controlling department number, and the department manager's
last name, address, and birthdate.

Q2: SELECT PNUMBER, DNUM, LNAME, BDATE, ADDRESS

FROM PROJECT, DEPARTMENT, EMPLOYEE
WHERE DNUM=DNUMBER AND MGRSSN=SSN
AND PLOCATION='Stafford'

◼ In Q2, there are two join conditions

◼ The join condition DNUM=DNUMBER relates a project to its
controlling department
◼ The join condition MGRSSN=SSN relates the controlling
department to the employee who manages that department

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Aliases, * and DISTINCT, Empty
WHERE-clause
◼ In SQL, we can use the same name for two (or
more) attributes as long as the attributes are in
different relations
◼ A query that refers to two or more attributes with
the same name must qualify the attribute name
with the relation name by prefixing the relation
name to the attribute name
◼ Example:

◼ EMPLOYEE.LNAME, DEPARTMENT.DNAME

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

ALIASES
◼ Some queries need to refer to the same relation twice
◼ In this case, aliases are given to the relation name

◼ Query 8: For each employee, retrieve the employee's name, and the
name of his or her immediate supervisor.

Q8: SELECT E.FNAME, E.LNAME, S.FNAME, S.LNAME

FROM EMPLOYEE E S
WHERE E.SUPERSSN=S.SSN

◼ In Q8, the alternate relation names E and S are called aliases or

tuple variables for the EMPLOYEE relation
◼ We can think of E and S as two different copies of EMPLOYEE; E
represents employees in role of supervisees and S represents
employees in role of supervisors

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

ALIASES (contd.)
◼ Aliasing can also be used in any SQL query for
convenience
◼ Can also use the AS keyword to specify aliases

Q8: SELECT E.FNAME, E.LNAME,

S.FNAME, S.LNAME
FROM EMPLOYEE AS E,
EMPLOYEE AS S
WHERE E.SUPERSSN=S.SSN

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

UNSPECIFIED
WHERE-clause
◼ A missing WHERE-clause indicates no condition; hence,
all tuples of the relations in the FROM-clause are selected
◼ This is equivalent to the condition WHERE TRUE
◼ Query 9: Retrieve the SSN values for all employees.

◼ Q9: SELECT SSN

FROM EMPLOYEE

◼ If more than one relation is specified in the FROM-clause

and there is no join condition, then the CARTESIAN
PRODUCT of tuples is selected

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

UNSPECIFIED
WHERE-clause (contd.)
◼ Example:

Q10: SELECT SSN, DNAME

FROM EMPLOYEE, DEPARTMENT

◼ It is extremely important not to overlook specifying

any selection and join conditions in the WHERE-
clause; otherwise, incorrect and very large
relations may result

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

USE OF *
◼ To retrieve all the attribute values of the selected tuples, a
* is used, which stands for all the attributes
Examples:

Q1C: SELECT *
FROM EMPLOYEE
WHERE DNO=5

Q1D: SELECT *
FROM EMPLOYEE, DEPARTMENT
WHERE DNAME='Research' AND
DNO=DNUMBER

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

USE OF DISTINCT
◼ SQL does not treat a relation as a set; duplicate tuples
can appear
◼ To eliminate duplicate tuples in a query result, the
keyword DISTINCT is used
◼ For example, the result of Q11 may have duplicate
SALARY values whereas Q11A does not have any
duplicate values

Q11: SELECT SALARY

FROM EMPLOYEE
Q11A: SELECT DISTINCT SALARY
FROM EMPLOYEE

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

SET OPERATIONS
◼ SQL has directly incorporated some set operations
◼ There is a union operation (UNION), and in some
versions of SQL there are set difference (MINUS) and
intersection (INTERSECT) operations
◼ The resulting relations of these set operations are sets of
tuples; duplicate tuples are eliminated from the result
◼ The set operations apply only to union compatible
relations; the two relations must have the same attributes
and the attributes must appear in the same order

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

SET OPERATIONS (contd.)
◼ Query 4: Make a list of all project numbers for projects that involve an
employee whose last name is 'Smith' as a worker or as a manager of
the department that controls the project.

Q4: (SELECT PNAME

FROM PROJECT, DEPARTMENT,
EMPLOYEE
WHERE DNUM=DNUMBER AND
MGRSSN=SSN AND LNAME='Smith')
UNION
(SELECT PNAME
FROM PROJECT, WORKS_ON, EMPLOYEE
WHERE PNUMBER=PNO AND
ESSN=SSN AND NAME='Smith')

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

NESTING OF QUERIES
◼ A complete SELECT query, called a nested query, can be
specified within the WHERE-clause of another query,
called the outer query
◼ Many of the previous queries can be specified in an
alternative form using nesting
◼ Query 1: Retrieve the name and address of all employees
who work for the 'Research' department.

Q1:SELECT FNAME, LNAME, ADDRESS

FROM EMPLOYEE
WHERE DNO IN (SELECT DNUMBER
FROM DEPARTMENT
WHERE DNAME='Research' )

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

NESTING OF QUERIES (contd.)
◼ The nested query selects the number of the 'Research'
department
◼ The outer query select an EMPLOYEE tuple if its DNO
value is in the result of either nested query
◼ The comparison operator IN compares a value v with a
set (or multi-set) of values V, and evaluates to TRUE if v is
one of the elements in V
◼ In general, we can have several levels of nested queries
◼ A reference to an unqualified attribute refers to the
relation declared in the innermost nested query
◼ In this example, the nested query is not correlated with
the outer query

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

CORRELATED NESTED QUERIES
◼ If a condition in the WHERE-clause of a nested query references an
attribute of a relation declared in the outer query, the two queries are
said to be correlated
◼ The result of a correlated nested query is different for each tuple
(or combination of tuples) of the relation(s) the outer query
◼ Query 12: Retrieve the name of each employee who has a dependent
with the same first name as the employee.

Q12: SELECT E.FNAME, E.LNAME

FROM EMPLOYEE AS E
WHERE E.SSN IN
(SELECT ESSN
FROM DEPENDENT
WHERE ESSN=E.SSN AND
E.FNAME=DEPENDENT_NAME)

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

CORRELATED NESTED QUERIES
(contd.)
◼ In Q12, the nested query has a different result in the outer
query
◼ A query written with nested SELECT... FROM... WHERE...
blocks and using the = or IN comparison operators can
always be expressed as a single block query. For
example, Q12 may be written as in Q12A

Q12A: SELECT E.FNAME, E.LNAME

FROM EMPLOYEE E, DEPENDENT D
WHERE E.SSN=D.ESSN AND
E.FNAME=D.DEPENDENT_NAME

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

CORRELATED NESTED QUERIES
(contd.)
◼ The original SQL as specified for SYSTEM R also had a
CONTAINS comparison operator, which is used in
conjunction with nested correlated queries
◼ This operator was dropped from the language, possibly
because of the difficulty in implementing it efficiently
◼ Most implementations of SQL do not have this operator
◼ The CONTAINS operator compares two sets of values, and
returns TRUE if one set contains all values in the other set
◼ Reminiscent of the division operation of algebra

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

CORRELATED NESTED QUERIES
(contd.)
◼ Query 3: Retrieve the name of each employee who works
on all the projects controlled by department number 5.

Q3: SELECT FNAME, LNAME

FROM EMPLOYEE
WHERE ( (SELECT PNO
FROM WORKS_ON
WHERE SSN=ESSN)
CONTAINS
(SELECT PNUMBER
FROM PROJECT
WHERE DNUM=5) )

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

CORRELATED NESTED QUERIES
(contd.)
◼ In Q3, the second nested query, which is not
correlated with the outer query, retrieves the
project numbers of all projects controlled by
department 5
◼ The first nested query, which is correlated,
retrieves the project numbers on which the
employee works, which is different for each
employee tuple because of the correlation

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

NULLS IN SQL QUERIES
◼ SQL allows queries that check if a value is NULL (missing
or undefined or not applicable)
◼ SQL uses IS or IS NOT to compare NULLs because it
considers each NULL value distinct from other NULL
values, so equality comparison is not appropriate.
◼ Query 14: Retrieve the names of all employees who do
not have supervisors.
Q14: SELECT FNAME, LNAME
FROM EMPLOYEE
WHERE SUPERSSN IS NULL
◼ Note: If a join condition is specified, tuples with NULL values
for the join attributes are not included in the result

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

AGGREGATE FUNCTIONS
◼ Include COUNT, SUM, MAX, MIN, and AVG
◼ Query 15: Find the maximum salary, the minimum
salary, and the average salary among all
employees.
Q15: SELECT MAX(SALARY),
MIN(SALARY), AVG(SALARY)
FROM EMPLOYEE

◼ Some SQL implementations may not allow more

than one function in the SELECT-clause

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

AGGREGATE FUNCTIONS (contd.)
◼ Query 16: Find the maximum salary, the minimum
salary, and the average salary among employees
who work for the 'Research' department.
Q16: SELECT MAX(SALARY),
MIN(SALARY), AVG(SALARY)
FROM EMPLOYEE, DEPARTMENT
WHERE DNO=DNUMBER AND
DNAME='Research'

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

AGGREGATE FUNCTIONS (contd.)
◼ Queries 17 and 18: Retrieve the total number of
employees in the company (Q17), and the number of
employees in the 'Research' department (Q18).
Q17: SELECT COUNT (*)
FROM EMPLOYEE

Q18: SELECT COUNT (*)

FROM EMPLOYEE, DEPARTMENT
WHERE DNO=DNUMBER AND
DNAME='Research’

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

GROUPING
◼ In many cases, we want to apply the aggregate
functions to subgroups of tuples in a relation
◼ Each subgroup of tuples consists of the set of
tuples that have the same value for the grouping
attribute(s)
◼ The function is applied to each subgroup
independently
◼ SQL has a GROUP BY-clause for specifying the
grouping attributes, which must also appear in
the SELECT-clause

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

GROUPING (contd.)
◼ Query 20: For each department, retrieve the department
number, the number of employees in the department, and
their average salary.
Q20: SELECT DNO, COUNT (*), AVG (SALARY)
FROM EMPLOYEE
GROUP BY DNO

◼ In Q20, the EMPLOYEE tuples are divided into groups-

◼ Each group having the same value for the grouping attribute
DNO
◼ The COUNT and AVG functions are applied to each such
group of tuples separately
◼ The SELECT-clause includes only the grouping attribute
and the functions to be applied on each group of tuples
◼ A join condition can be used in conjunction with grouping

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

GROUPING (contd.)
◼ Query 21: For each project, retrieve the project number,
project name, and the number of employees who work on
that project.

Q21: SELECT PNUMBER, PNAME, COUNT (*)

FROM PROJECT, WORKS_ON
WHERE PNUMBER=PNO
GROUP BY PNUMBER, PNAME

◼ In this case, the grouping and functions are applied after

the joining of the two relations

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

THE HAVING-CLAUSE
◼ Sometimes we want to retrieve the values of
these functions for only those groups that satisfy
certain conditions
◼ The HAVING-clause is used for specifying a
selection condition on groups (rather than on
individual tuples)

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

THE HAVING-CLAUSE (contd.)
◼ Query 22: For each project on which more than
two employees work, retrieve the project number,
project name, and the number of employees who
work on that project.
Q22: SELECT PNUMBER, PNAME,
COUNT(*)
FROM PROJECT, WORKS_ON
WHERE PNUMBER=PNO
GROUP BY PNUMBER, PNAME
HAVING COUNT (*) > 2

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

SUBSTRING COMPARISON
◼ The LIKE comparison operator is used to
compare partial strings
◼ Two reserved characters are used: '%' (or '*' in
some implementations) replaces an arbitrary
number of characters, and '_' replaces a single
arbitrary character

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

SUBSTRING COMPARISON (contd.)
◼ Query 25: Retrieve all employees whose
address is in Houston, Texas. Here, the value of
the ADDRESS attribute must contain the
substring 'Houston,TX‘ in it.
Q25: SELECT FNAME, LNAME
FROM EMPLOYEE
WHERE ADDRESS LIKE
'%Houston,TX%'

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

SUBSTRING COMPARISON (contd.)
◼ Query 26: Retrieve all employees who were born during
the 1950s.
◼Here, '5' must be the 8th character of the string (according
to our format for date), so the BDATE value is '_______5_',
with each underscore as a place holder for a single arbitrary
character.
Q26: SELECT FNAME, LNAME
FROM EMPLOYEE
WHERE BDATE LIKE '_______5_’

◼ The LIKE operator allows us to get around the fact that

each value is considered atomic and indivisible
◼ Hence, in SQL, character string attribute values are not
atomic

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

ARITHMETIC OPERATIONS
◼ The standard arithmetic operators '+', '-'. '*', and '/' (for
addition, subtraction, multiplication, and division,
respectively) can be applied to numeric values in an SQL
query result
◼ Query 27: Show the effect of giving all employees who
work on the 'ProductX' project a 10% raise.
Q27: SELECT FNAME, LNAME, 1.1*SALARY
FROM EMPLOYEE, WORKS_ON,
PROJECT
WHERE SSN=ESSN AND PNO=PNUMBER
AND PNAME='ProductX’

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

ORDER BY
◼ The ORDER BY clause is used to sort the tuples in a
query result based on the values of some attribute(s)
◼ Query 28: Retrieve a list of employees and the projects
each works in, ordered by the employee's department,
and within each department ordered alphabetically by
employee last name.
Q28: SELECT DNAME, LNAME, FNAME, PNAME
FROM DEPARTMENT, EMPLOYEE,
WORKS_ON, PROJECT
WHERE DNUMBER=DNO AND SSN=ESSN
AND PNO=PNUMBER
ORDER BY DNAME, LNAME

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

ORDER BY (contd.)
◼ The default order is in ascending order of values
◼ We can specify the keyword DESC if we want a
descending order; the keyword ASC can be used
to explicitly specify ascending order, even though
it is the default

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Summary of SQL Queries
◼ A query in SQL can consist of up to six clauses,
but only the first two, SELECT and FROM, are
mandatory. The clauses are specified in the
following order:

SELECT <attribute list>

FROM <table list>
[WHERE <condition>]
[GROUP BY <grouping attribute(s)>]
[HAVING <group condition>]
[ORDER BY <attribute list>]

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Summary of SQL Queries (contd.)
◼ The SELECT-clause lists the attributes or functions to be retrieved
◼ The FROM-clause specifies all relations (or aliases) needed in the
query but not those needed in nested queries
◼ The WHERE-clause specifies the conditions for selection and join of
tuples from the relations specified in the FROM-clause
◼ GROUP BY specifies grouping attributes
◼ HAVING specifies a condition for selection of groups
◼ ORDER BY specifies an order for displaying the result of a query
◼ A query is evaluated by first applying the WHERE-clause, then
GROUP BY and HAVING, and finally the SELECT-clause

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Specifying Updates in SQL
◼ There are three SQL commands to modify the
database: INSERT, DELETE, and UPDATE

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

INSERT
◼ In its simplest form, it is used to add one or more
tuples to a relation
◼ Attribute values should be listed in the same
order as the attributes were specified in the
CREATE TABLE command

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

INSERT (contd.)
◼ Example:
U1: INSERT INTO EMPLOYEE
VALUES ('Richard','K','Marini', '653298653', '30-DEC-52',
'98 Oak Forest,Katy,TX', 'M', 37000,'987654321', 4 )

◼ An alternate form of INSERT specifies explicitly the

attribute names that correspond to the values in the new
tuple
◼ Attributes with NULL values can be left out
◼ Example: Insert a tuple for a new EMPLOYEE for whom
we only know the FNAME, LNAME, and SSN attributes.
U1A: INSERT INTO EMPLOYEE (FNAME, LNAME,
SSN)
VALUES ('Richard', 'Marini', '653298653')

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

INSERT (contd.)
◼ Important Note: Only the constraints specified in
the DDL commands are automatically enforced
by the DBMS when updates are applied to the
database
◼ Another variation of INSERT allows insertion of
multiple tuples resulting from a query into a
relation

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

INSERT (contd.)
◼ Example: Suppose we want to create a temporary table that has the
name, number of employees, and total salaries for each department.
◼ A table DEPTS_INFO is created by U3A, and is loaded with the
summary information retrieved from the database by the query in
U3B.
U3A: CREATE TABLE DEPTS_INFO
(DEPT_NAME VARCHAR(10),
NO_OF_EMPS INTEGER,
TOTAL_SAL INTEGER);

U3B: INSERT INTO DEPTS_INFO (DEPT_NAME,

NO_OF_EMPS, TOTAL_SAL)
SELECT DNAME, COUNT (*), SUM (SALARY)
FROM DEPARTMENT, EMPLOYEE
WHERE DNUMBER=DNO
GROUP BY DNAME ;

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

INSERT (contd.)
◼ Note: The DEPTS_INFO table may not be up-to-
date if we change the tuples in either the
DEPARTMENT or the EMPLOYEE relations after
issuing U3B. We have to create a view (see later)
to keep such a table up to date.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

DELETE
◼ Removes tuples from a relation
◼ Includes a WHERE-clause to select the tuples to be deleted
◼ Referential integrity should be enforced
◼ Tuples are deleted from only one table at a time (unless
CASCADE is specified on a referential integrity constraint)
◼ A missing WHERE-clause specifies that all tuples in the
relation are to be deleted; the table then becomes an empty
table
◼ The number of tuples deleted depends on the number of
tuples in the relation that satisfy the WHERE-clause

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

DELETE (contd.)
◼ Examples:
U4A: DELETE FROM EMPLOYEE
WHERE LNAME='Brown’

U4B: DELETE FROM EMPLOYEE

WHERE SSN='123456789’

U4C: DELETE FROM EMPLOYEE

WHERE DNO IN
(SELECT DNUMBER
FROM DEPARTMENT
WHERE
DNAME='Research')

U4D: DELETE FROM EMPLOYEE

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

UPDATE
◼ Used to modify attribute values of one or more
selected tuples
◼ A WHERE-clause selects the tuples to be
modified
◼ An additional SET-clause specifies the attributes
to be modified and their new values
◼ Each command modifies tuples in the same
relation
◼ Referential integrity should be enforced

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

UPDATE (contd.)
◼ Example: Change the location and controlling
department number of project number 10 to
'Bellaire' and 5, respectively.
U5: UPDATE PROJECT
SET PLOCATION = 'Bellaire',
DNUM = 5
WHERE PNUMBER=10

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

UPDATE (contd.)
◼ Example: Give all employees in the 'Research'
department a 10% raise in salary.
U6: UPDATE EMPLOYEE
SET SALARY = SALARY *1.1
WHERE DNO IN (SELECT DNUMBER
FROM DEPARTMENT
WHERE DNAME='Research')

◼ In this request, the modified SALARY value depends on

the original SALARY value in each tuple
◼ The reference to the SALARY attribute on the right of =
refers to the old SALARY value before modification
◼ The reference to the SALARY attribute on the left of = refers
to the new SALARY value after modification

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Recap of SQL Queries
◼ A query in SQL can consist of up to six clauses, but only
the first two, SELECT and FROM, are mandatory. The
clauses are specified in the following order:

SELECT <attribute list>

FROM <table list>
[WHERE <condition>]
[GROUP BY <grouping attribute(s)>]
[HAVING <group condition>]
[ORDER BY <attribute list>]
◼ There are three SQL commands to modify the database:
INSERT, DELETE, and UPDATE

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Sources
◼ Elmasri Ramez, and Sham Navathe. Fundamentals of
Database Systems. Boston: Pearson/Addison Wesley, 7th
Edition
◼ SQL, PL/SQL THE PROGRAMMING LANGUAGE OF
ORECLE 4TH edition by IVAN BAYROSS

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe