St.

Philomena's College (Autonomous), Mysore

MCA Department
Course Name: Advanced DBMS

Course Content
UNIT- III - Introduction to SQL
Overview of the SQL Query Language, SQL Data Definition, Basic structure of SQL Queries, Additional Basic
Operations, Null values, Aggregate Functions, nested Sub queries, Modification of the Database, Join
Expressions, Views, Transactions, Integrity Constraints, SQL Data Types and Schemas, Authorization.
Database programming issues and techniques, Embedded SQL

The above concepts are taken from the textbook called

Database System Concepts by Abraham Silberschatz, H. Korth, Sudarshan
Overview of the SQL Query Language

➔ IBM developed the original version of SQL, originally called Sequel in the early 1970s.

➔ The Sequel language has evolved since then, and its name has changed to SQL (Structured

Query Language).

➔ Many products now support the SQL language. SQL has clearly established itself as the standard

relational database language.

The SQL language has several parts:

➔ Data-definition language (DDL): The SQL DDL provides commands for defining relation schemas,

deleting relations, and modifying relation schemas.

➔ Data-manipulation language (DML): The SQL DML provides the ability to query information from

the database and to insert tuples into, delete tuples from, and modify tuples in the database.
➔ Integrity: The SQL DDL includes commands for specifying integrity constraints that the data stored in

the database must satisfy. Updates that violate integrity constraints are disallowed.

➔ View definition: The SQL DDL includes commands for defining views.

➔ Transaction control: SQL includes commands for specifying the beginning and end points of

transactions.

➔ Embedded SQL and dynamic SQL: Embedded and dynamic SQL define how SQL statements can be

embedded within general-purpose programming languages, such as C, C++, and Java.

➔ Authorization: The SQL DDL includes commands for specifying access rights to relations and views.
SQL Data Definition

➔ The set of relations in a database are specified using a data-definition language (DDL). The

SQL DDL allows specification of not only a set of relations, but also information about each

relation, including:

◆ The schema for each relation.

◆ The types of values associated with each attribute.

◆ The integrity constraints.

◆ The set of indices to be maintained for each relation.

◆ The security and authorization information for each relation.

◆ The physical storage structure of each relation on disk.

Basic Types

➔ The SQL standard supports a variety of built-in types, including:

➔ char(n): A fixed-length character string with user-specified length n. The full form, character, can

be used instead.

➔ varchar(n): A variable-length character string with user-specified maximum length n. The full form,

character varying, is equivalent.

➔ int: An integer (a finite subset of the integers that is machine dependent). The full form, integer, is

equivalent.

➔ smallint: A small integer (a machine-dependent subset of the integer type).

 ➔ Numeric(p, d): The notation numeric(p, d) is used to define a number with a fixed precision and scale:

➔ p (precision): This is the total number of digits that the number can have, including both the digits

before and after the decimal point.

➔ d (scale): This is the number of digits that can be to the right of the decimal point.

Example: numeric(3, 1)

➔ Precision (p) = 3: This means the total number of digits (both before and after the decimal point) can

be up to 3.

➔ Scale (d) = 1: This means that 1 digit can be after the decimal point.

➔ real, double precision: Floating-point and double-precision floating-point numbers with machine-

dependent precision.

➔ float(n): A floating-point number with precision of at least n digits.

 ➔ Each type may include a special value called the null value. A null value indicates an absent

value that may exist but be unknown or that may not exist at all. In certain cases, we may wish

to prohibit null values from being entered.

Char Data Type: Fixed-Length Strings

➔ When you define a string attribute as char(n), you specify that every string stored in this field

will be exactly n characters long.

➔ Example: If you have an attribute A defined as char(10), every string stored in A must occupy

10 characters of space.

Varchar Data Type: Variable-Length Strings

➔ When you define a string attribute as varchar(n), you specify the maximum length the string can

have, but the actual storage used is only as much as the string's length.

➔ Example: If attribute B is of type varchar(10), and you store "Avi" in B, it will just store "Avi"

without any extra spaces.

Basic Schema Definition

➔ We define an SQL relation by using the create table command. The following command creates a

relation department in the database.

create table department

(dept_name varchar (20),

building varchar (15),

budget numeric (12,2),

primary key (dept_name));

➔ The relation created above has three attributes,

◆ dept name, which is a character string of maximum length 20,

◆ building, which is a character string of maximum length 15, and

◆ budget, which is a number with 12 digits in total, two of which are after the decimal

point.
➔ The general form of the create table command is:
create table r
(A1 D1,
A2 D2,
...,
An Dn,
⟨integrity-constraint 1⟩,
…,
⟨integrity-constraint k⟩);

➔ where r is the name of the relation, each Ai is the name of an attribute in the schema of

relation r, and Di is the domain of attribute Ai; that is, Di specifies the type of attribute Ai

along with optional constraints that restrict the set of allowed values for Ai.

➔ The semicolon shown at the end of the create table statements, as well as at the end of other

SQL statements.
➔ Primary key: The primary-key specification says that attributes form the primary key for the

relation. The primary-key attributes are required to be nonnull and unique; that is, no tuple can

have a null value for a primary-key attribute, and no two tuples in the relation can be equal

on all the primary-key attributes. Although the primary-key specification is optional, it is

generally a good idea to specify a primary key for each relation.

➔ Foreign key: The foreign key specification says that the values of attributes for any tuple in the

relation must correspond to values of the primary key attributes of some tuple in relation s.

➔ not null: The not null constraint on an attribute specifies that the null value is not allowed for

that attribute; in other words, the constraint excludes the null value from the domain of that

attribute.

➔ Figure presents a partial SQL DDL definition of the university database

➔ To remove a relation from an SQL database, we use the drop table command. The drop table

command deletes all information about the dropped relation from the database. The

command

drop table r;

➔ is a more drastic action than

delete from r;

➔ The latter retains relation r, but deletes all tuples in r. The former deletes not only all tuples

of r and also the schema for r. After r is dropped, no tuples can be inserted into r unless it is

re-created with the create table command.

➔ We use the alter table command to add attributes to an existing relation. All tuples in the

relation are assigned null as the value for the new attribute. The form of the alter table command

is

alter table r add A D;

➔ where r is the name of an existing relation, A is the name of the attribute to be added, and D
Basic Structure of SQL Queries

➔ The basic structure of an SQL query consists of three clauses: select, from, and where.

➔ A query takes as its input the relations listed in the from clause, operates on them as

specified in the where and select clauses, and then produces a relation as the result.

Queries on a Single Relation

➔ Let us consider a simple query using university example, “Find the names of all instructors.”

Instructor names are found in the instructor relation, so we put that relation in the from

clause. The instructor’s name appears in the name attribute, so we put that in the select

clause.

select name

from instructor;

➔ The result is a relation consisting of a single attribute with the heading name.
➔ Now consider another query, “Find the department names of all instructors,” which can be

written as:

select dept_name

from instructor;

➔ Since more than one instructor can belong to a department, a department name could

appear more than once in the instructor relation.

➔ In these cases where we want to force the elimination of duplicates, we insert the keyword

distinct after select. We can rewrite the preceding query as:

select distinct dept_name

from instructor;

➔ if we want duplicates removed.

➔ The select clause may also contain arithmetic expressions involving the operators +, −, ∗, and /

operating on constants or attributes of tuples. For example, the query:

select ID, name, dept_name, salary * 1.1

from instructor;

➔ returns a relation that is the same as the instructor relation, except that the attribute salary is

multiplied by 1.1.
where clause

➔ The where clause allows us to select only those rows in the result relation of the from clause

that satisfy a specified predicate.

➔ Consider the query “Find the names of all instructors in the Computer Science department

who have salary greater than $70,000.” and the query is as follows

select name

from instructor

where dept_name = 'Comp. Sci.' and salary > 70000;

➔ SQL allows the use of the logical connectives and, or, and not in the where clause. The operands

of the logical connectives can be expressions involving the comparison operators <, <=, >, >=, =,

and <>.
Queries on Multiple Relations

➔ Suppose we want to answer the query “Retrieve the names of all instructors, along with their

department names and department building name.”

➔ Looking at the schema of the relation instructor, we realize that we can get the department name

from the attribute dept_name, but the department building name is present in the attribute

building of the relation department.

➔ To answer the query, each tuple in the instructor relation must be matched with the tuple in

the department relation whose dept name value matches the dept name value of the

instructor tuple.

➔ The above query can be written in SQL as

select name, instructor.dept_name, building

from instructor, department

where instructor.dept name= department.dept name;

➔ The above query can be written in SQL as

select name, instructor.dept_name, building

from instructor, department

where instructor.dept name= department.dept name;

➔ Note that the attribute dept_name occurs in both the relations instructor and department, and

the relation name is used as a prefix (in instructor.dept_name, and department.dept name) to

make clear to which attribute we are referring.

➔ As we have seen earlier, an SQL query can contain three types of clauses, the select clause, the

from clause, and the where clause. The role of each clause is as follows:

◆ The select clause is used to list the attributes desired in the result of a query.

◆ The from clause is a list of the relations to be accessed in the evaluation of the query.

● The from clause by itself defines a Cartesian product of the relations listed in the

clause.

◆ The where clause is a predicate involving attributes of the relation in the from clause.

➔ Note: The clauses must be written in the order select, from, where, the easiest way to

understand the operations.

Additional Basic Operations

The Rename Operation

➔ Consider the query

select name, course_id

from instructor, teaches

where instructor.ID= teaches.ID;

➔ The result of this query is a relation with the following attributes: name, course_id

➔ The names of the attributes in the result are derived from the names of the attributes in the

relations in the from clause.

➔ We cannot, however, always derive names in this way, for several reasons.
➔ First, two relations in the from clause may have attributes with the same name, in which case

an attribute name is duplicated in the result.

➔ Second, if we use an arithmetic expression in the select clause, the resultant attribute does

not have a name.

➔ Third, even if an attribute name can be derived from the base relations as in the preceding

example, we may want to change the attribute name in the result. Hence, SQL provides a

way of renaming the attributes of a result relation.

➔ It uses the as clause, taking the form: old-name as new-name

➔ The as clause can appear in both the select and from clauses.

➔ For example, if we want the attribute name name to be replaced with the name

instructor_name, we can rewrite the preceding query as:

select name as instructor_name, course_id
from instructor, teaches
where instructor.ID= teaches.ID;
String Operations

➔ SQL specifies strings by enclosing them in single quotes, for example, 'Computer'.

➔ The SQL standard specifies that the equality operation on strings is case sensitive; as a result,

the expression “'comp. sci.' = 'Comp. Sci.'” evaluates to false. However, some database systems,

such as MySQL and SQL Server, do not distinguish uppercase from lowercase when matching strings

➔ SQL also permits a variety of functions on character strings, such as concatenating (using “∥”),

extracting substrings, finding the length of strings, converting strings to uppercase (using

the function upper(s) where s is a string) and lowercase (using the function lower(s)), removing

spaces at the end of the string (using trim(s)), and so on.

➔ Pattern matching can be performed on strings using the operator like. We describe patterns by using

two special characters: Percent (%) and Underscore (_).

Percent Sign (%)

➔ Usage: The % character is used in SQL with the LIKE operator to match any sequence of zero or

more characters. Example

➔ If you have a query SELECT * FROM users WHERE name LIKE 'Sam%', this will match any records

where the name starts with "Sam", followed by any characters or no character at all. This

means it could match "Sam", "Samantha", "Samuel", etc.

Underscore (_)

➔ Usage: The _ character is used in SQL with the LIKE operator to match any single character.

Example

➔ If you use a query SELECT * FROM users WHERE name LIKE 'Sam_', this will match any records

where the name starts with "Sam" and has exactly one more character. This means it would

match "Samy" or "Sam4", but not "Sam" or "Samantha".

Escape Keyword

➔ ESCAPE keyword in SQL is used to define an escape character for LIKE pattern matching. This is

particularly useful when you need to search for a string that contains the % or _ characters

themselves.

➔ Example: Let's say you want to find all records where a column contains the string "100%

effort".

SELECT * FROM table WHERE column LIKE '100\% effort' ESCAPE '\';

➔ '100\% effort': The pattern to match, where \% indicates that the % should be treated as a literal

character.

➔ ESCAPE '\': This specifies that the backslash \ is the escape character.
Attribute Specification in the Select Clause

➔ The asterisk symbol “ * ” can be used in the select clause to denote “all attributes.” Thus, the use of

instructor.* in the select clause of the query:

select instructor.*

from instructor, teaches

where instructor.ID= teaches.ID;

➔ indicates that all attributes of instructor are to be selected. A select clause of the form select

* indicates that all attributes of the result relation of the from clause are selected.
Ordering the Display of Tuples

➔ SQL offers the user some control over the order in which tuples in a relation are displayed. The

order by clause causes the tuples in the result of a query to appear in sorted order. To list in

alphabetical order all instructors in the Physics department, we write

select name

from instructor

where dept name = 'Physics'

sname;

➔ By default, the order by clause lists items in ascending order. To specify the sort order, we may

specify desc for descending order or asc for ascending order.

Set Operations and NULL Values are Assignment