0% found this document useful (0 votes)
14 views

Module -III

Module-III covers functional dependencies and normalization in relational databases, emphasizing that attribute A determines attribute B if knowing A allows for the determination of B. It outlines informal design guidelines to improve schema quality, such as ensuring clear semantics, reducing redundancy and NULL values, and preventing spurious tuples. Normalization is introduced as a technique to minimize data redundancy through normal forms, with a focus on the importance of achieving at least third normal form (3NF) for effective database design.

Uploaded by

sunil
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
14 views

Module -III

Module-III covers functional dependencies and normalization in relational databases, emphasizing that attribute A determines attribute B if knowing A allows for the determination of B. It outlines informal design guidelines to improve schema quality, such as ensuring clear semantics, reducing redundancy and NULL values, and preventing spurious tuples. Normalization is introduced as a technique to minimize data redundancy through normal forms, with a focus on the importance of achieving at least third normal form (3NF) for effective database design.

Uploaded by

sunil
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 38

Module-III DBMS BCS403

Module -III
Chapter-I
Functional Dependencies & Normalization for Relational
Databases
Functional Dependence:
- The attribute B is functionally dependent on A if A determines B. “A determines B”
indicates that knowing the value of attribute A means that we can look up (determine)
the value of attribute B. In this case, attribute A is the called the determinant.

- For example, knowing the PROD_CODE in the PRODUCT table in Figure 1 means
we can look up the product’s description, product price and so on. The notation we use
for “A determines B” is:

A→B if A determines B
A → B, C, D if A determines B, C & D
Using the above example, we have

PROD_CODE → PROD_DESCRIPT

Table Name: PRODUCT


Primary Key: PROD_CODE
Foreign Key: VEND_CODE

PROD_CODE PROD_DESCRIPT PROD_PRICE PROD_ON_HAND VEND_CODE


001278-AB Claw Hammer 12.95 23 232
123-21UUY Chain Saw 189.49 4 235
QER-34256 Sledge Hammer 18.63 6 231
SRE-657OG Rat-Tail File 2.99 15 232
77x-3245Q Steel Tape 6.79 8 235
Figure 1: PRODUCT Table

- As another example, note that PROD_PRICE attribute is functionally dependent on


PROD_CODE since, for example, PROD_CODE value 001278-AB determines the
PROD_PRICE value 12.95 (that is, PROD_CODE determines PROD_PRICE).

- As a rule, note that the primary key determines every other attribute in the table.

- Question: is PROD_CODE functionally dependent on VEND_CODE?

SUNIL G L Asst. Professor, Dept of CSE(DS), RNSIT . Page 1


Module-III DBMS BCS403

Informal Design guidelines:


Four informal guidelines that may be used as measures to determine the quality of relation
schema design:
■ Making sure that the semantics of the attributes is clear in the schema
■ Reducing the redundant information in tuples
■ Reducing the NULL values in tuples
■ Disallowing the possibility of generating spurious tuples
1. Semantics of the Attributes
Whenever we are going to form relational schema there should be some meaning among
the attributes.This meaning is called semantics.This semantics relates one attribute to
another with some relation.

Eg:

USN No Student name Sem

Guideline 1. Design a relation schema so that it is easy to explain its meaning. Do not combine
attributes from multiple entity types and relationship types into a single relation. Intuitively, if a
relation schema corresponds to one entity type or one relationship type, it is straightforward to
explain its meaning. Otherwise, if the relation corresponds to a mixture of multiple entities and
relationships, semantic ambiguities will result and the relation cannot be easily explained.
2. Reducing the Redundant Value in Tuples
Mixing attributes of multiple entities may cause problems Information is stored
redundantly wasting storage Problems with update anomalies

Insertion anomalies
Deletion anomalies
Modification anomalies

Eg:

USN Student name Sem

SUNIL G L Asst. Professor, Dept of CSE(DS), RNSIT . Page 2


Module-III DBMS BCS403

Dept No Dept Name


If we integrate these two and is used as a single table i.e Student Table

USN No Student name Sem Dept No Dept Name


Here whenever if we insert the tuples there may be ‘N’ students in one department, so
Dept No,Dept Name values are repeated ‘N’ times which leads to data redundancy.

Another problem is updata anamolies ie if we insert new dept that has no students.

If we delet the last student of a dept,then whole information about that department will be
deleted

If we change the value of one of the attributes of aparticaular table the we must update the
tuples of all the students belonging to thet depy else Database will become inconsistent.

Guideline 2. Design the base relation schemas so that no insertion, deletion, or odification
anomalies are present in the relations. If any anomalies are present, note them clearly and make
sure that the programs that update the database will

3. Reducing Null values in Tuples.


Note: Relations should be designed such that their tuples will have as few NULL
values as possible

Attributes that are NULL frequently could be placed in separate relations (with the
primary key)

Reasons for nulls:

attribute not applicable or invalid attribute


value unknown (may exist)

value known to exist, but unavailable

Guideline 3. As far as possible, avoid placing attributes in a base relation whose values may
frequently be NULL. If NULLs are unavoidable, make sure that they apply in exceptional cases
only and do not apply to a majority of tuples in the relation. operate correctly.

SUNIL G L Asst. Professor, Dept of CSE(DS), RNSIT . Page 3


Module-III DBMS BCS403

4. Disallowing spurious Tuples


Bad designs for a relational database may result in erroneous results for certain JOIN operations
The "lossless join" property is used to guarantee meaningful results for join
operations
Note: The relations should be designed to satisfy the lossless join condition. No spurious
tuples should be generated by doing a natural-join of any relations.

Guideline 4. Design relation schemas so that they can be joined with equality conditions on
attributes that are appropriately related (primary key, foreign key) pairs in a way that guarantees
that no spurious tuples are generated. Avoid relations that contain matching attributes that are
not (foreign key, primary key) combinations because joining on such attributes may produce
spurious tuples.

- Normalization
- Normalization is a technique used to design table structures in which data redundancies
are minimized/eliminated.
- Normalization works through a series of stages called normal forms. The first three stages
are described as first normal form (1NF), second normal form (2NF), and third normal
form (3NF).
- From a structural point of view, 2NF is better than 1NF, and 3NF is better than 2NF.
- For most business database design purposes, 3NF is as high as we need to go in the
normalization process.
- You should not assume that the highest level of normalization is always the most
desirable. Generally, the higher the normal form, the more joins are required to produce a
specified output and the more slowly the database responds to end user demands.
Therefore, you will occasionally be expected to denormalize some table structures to
avoid performance degradation.
- Denormalization is the reverse process of normalization and it produces a lower normal
form; that is, 3NF can be denormalized to 2NF and 2NF can be denormalized to 1NF.

SUNIL G L Asst. Professor, Dept of CSE(DS), RNSIT . Page 4


Module-III DBMS BCS403

- The Need For Normalization

- To understand the benefits of normalization, let us consider a poorly designed table of a


contracting company with many data redundancies as shown in Figure 2.

PROJ_NUM PROJ_NAME EMP_NUM EMP_NAME JOB_CLASS CHG_HOUR HOURS


15 Evergreen 103 J. Arbough E. Engineer $84.50 23.8
101 J. News DB Designer $105.00 19.4
105 A. Johnson DB Designer $105.00 35.7
106 W. Smithfield Programmer $35.75 12.6
102 D. Senior S. Analyst $96.75 23.8
18 Amber Wave 114 A. Jones A. Designer $48.10 24.6
105 A. Johnson DB Designer $105.00 20.0
118 J. Frommer G. Support $18.36 45.3
104 A. Ramoras S. Analyst $96.75 32.4
22 Rolling Tide 105 A. Johnson DB Designer $105.00 64.7
104 A. Ramoras S. Analyst $96.75 48.4
113 D. Joenbrood A. Designer $48.10 23.6
106 W. Smithfield Programmer $35.75 12.8
25 Starflight 107 M. Alonzo Programmer $35.75 24.6
115 T. Bawangi S. Analyst $96.75 45.8
101 J. News DB Designer $105.00 56.3
105 A. Johnson DB Designer $105.00 30.0
Figure 2: Poorly Designed Table

- The table in Figure 2 contains information about projects and employees working on
these projects. This table does not conform to the Relational Database Model we learned
in Chapter 5 for the following reasons:

1. It contains information about two entities: PROJECT and EMPLOYEE.


2. The project number (PROJ_NUM) is intended to be the primary key, or at least a
part of a primary key, but it contains nulls.
3. The table contains data redundancies: EMP_NAME, JOB_CLASS, CHG_HOUR,
etc.
4. Table entries invite data inconsistencies. For example, JOB_CLASS value
“E. Engineer” in one row may be accidentally entered as E.Engineer in another
row causing data inconsistencies.
5. The data redundancies yield the following anomalies (anamoly means that change
is made in multiple places):

SUNIL G L Asst. Professor, Dept of CSE(DS), RNSIT . Page 5


Module-III DBMS BCS403

a. Update anomalies: Modifying the CHG_HOUR for employee number


(EMP_NUM) 105 for the Evergreen project for example requires updating the
CHG_HOUR for the same employee in the other projects.
b. Insertion anomalies: Employee data for employee number 105 is inserted
many times in the table.
c. Deletion anomalies: If employee 105 quits, not only he will be deleted
from the Evergreen project, but he will also be deleted from the other projects
(that is, a total of 4 deletions are required).

- Conversion To First Normal Form (1NF)


- A table is said to be in 1NF if it satisfies the following conditions:
1. It contains a primary key to uniquely identify each row.
2. There are no repeating groups. In other words, each row/column intersection can
contain one and only one value, not a set of values. Note that the table in Figure 2
contains repeating groups because any project number (PROJ_NUM) can have a
group of several data entries. For example, the Evergreen project’s entries are
shown in Figure 3:

PROJ_NUM PROJ_NAME EMP_NUM EMP_NAME JOB_CLASS CHG_HOUR HOURS


15 Evergreen 103 J. Arbough E Engineer $84.50 23.8
101 J. News DB Designer $105.00 19.4
105 A. Johnson DB Designer $105.00 35.7
106 W. Programmer $35.75 12.6
Smithfield
102 D. Senior S. Analyst $96.75 23.8
Figure 3: Example Repeating Group
3. All attributes are dependent on the primary key. Note that the primary key
determines any other attribute in the table.
- Note that all tables conforming to the Relational Model we learned in Chapter 5 are in
1NF by default.

- Figure 4 below displays the conversion of the table in Figure 2 to 1NF by satisfying the above
three conditions.

SUNIL G L Asst. Professor, Dept of CSE(DS), RNSIT . Page 6


Module-III DBMS BCS403

PROJ_NUM PROJ_NAME EMP_NUM EMP_NAME JOB_CLASS CHG_HOUR HOURS


15 Evergreen 103 J. Arbough E Engineer $84.50 23.8
15 Evergreen 101 J. News DB Designer $105.00 19.4
15 Evergreen 105 A. Johnson DB Designer $105.00 35.7
15 Evergreen 106 W. Programmer $35.75 12.6
Smithfield
15 Evergreen 102 D. Senior S. Analyst $96.75 23.8
18 Amber Wave 114 A. Jones A. Designer $48.10 24.6
18 Amber Wave 105 A. Johnson DB Designer $105.00 20.0
18 Amber Wave 118 J. Frommer G. Support $18.36 45.3
18 Amber Wave 104 A. Ramoras S. Analyst $96.75 32.4
22 Rolling Tide 105 A. Johnson DB Designer $105.00 64.7
22 Rolling Tide 104 A. Ramoras S. Analyst $96.75 48.4
22 Rolling Tide 113 D. Joenbrood A. Designer $48.10 23.6
22 Rolling Tide 106 W. Programmer $35.75 12.8
Smithfield
25 Starflight 107 M. Alonzo Programmer $35.75 24.6
25 Starflight 115 T. Bawangi S. Analyst $96.75 45.8
25 Starflight 101 J. News DB Designer $105.00 56.3
25 Starflight 105 A. Johnson DB Designer $105.00 30.0
Figure 4: The Table in Figure 1 in 1NF

- Note that the table in Figure 4 satisfies the three conditions. The first condition is satisfied
because the table has a composite primary key consisting of the key attributes PROJ_NUM
and EMP_NUM. The second condition is satisfied because the table no longer contains
repeating groups. The third condition is satisfied because any attribute is dependent on the
primary key. For example, EMP_NAME is dependent on the primary key PROJ_NUM,
EMP_NUM because if we know PROJ_NUM and EMP_NUM (15 and 103 for example), we
can determine EMP_NAME (J. Arbough).

- Dependencies between attributes for the table in Figure 4 can be identified with the help of
the dependency diagram as shown in Figure 5 below:

SUNIL G L Asst. Professor, Dept of CSE(DS), RNSIT . Page 7


Module-III DBMS BCS403

PROJ_NUM PROJ_NAME EMP_NUM EMP_NAME JOB_CLASS CHG_HOUR HOURS


Partial Dependency Transitive
Dependency

Figure 5: A Dependency Diagram: First Normal Form (1NF)

- Note the following about the dependency diagram in Figure 5:

1. The primary key is bold and underlined.


2. The arrows above attributes include all desirable dependencies. These dependencies can
be expressed as follows:

PROJ_NUM, EMP_NUM → PROJ_NAME, EMP_NAME, JOB_CLASS, CHG_HOUR,


HOURS
PROJ_NUM → PROJ_NAME
EMP_NUM → EMP_NAME, JOB_CLASS, CHG_HOUR
JOB_CLASS → CHG_HOUR

3. The arrows below the dependency diagram indicate less desirable dependencies:

a. Partial Dependencies: This applies to composite primary keys (a composite


primary key is a primary key that consists of more that one attribute) where the
value of an attribute is only dependent on part of the primary key. For example,
PROJ_NAME is dependent on PROJ_NUM, which forms part of the primary key
(if we know PROJ_NUM, we can determine PROJ_NAME). Dependencies based
on only a part of a composite primary key are called partial dependencies.
b. Transitive Dependencies: Looking at Figure 5, note that CHG_HOUR is
dependent on JOB_CLASS. Because neither CHG_HOUR nor JOB_CLASS is a
key attribute, we have a condition known as transitive dependency. In other words,

SUNIL G L Asst. Professor, Dept of CSE(DS), RNSIT . Page 8


Module-III DBMS BCS403

a transitive dependency is a dependency of one nonkey attribute on another


nonkey attribute.

- Conversion To Second Normal Form (2NF)

- A table is said to be in second normal form (2NF) if it satisfies the following conditions:
1. It is in 1NF.
2. It includes no partial dependencies; that is, no attribute is dependent on a portion of the
primary key.
- Let us convert the table in Figure 4 from 1NF to 2NF. To do that, follow these steps:
1. Write each key attribute (recall from Chapter 2 that a key attribute is an attribute
that is part of the key) on a separate line, then write the primary key on the last
line:
PROJ_NUM
EMP_NUM
PROJ_NUM EMP_NUM
The attributes on each line will become keys in a new table. In other words, the
original table is now split into three tables. We’ll call these tables PROJECT,
EMPLOYEE and ASSIGN respectively.
2. The attribute(s) on each line will form the primary key for the new tables. The
rest of the attributes for each table can be determined from the dependency
diagram:
PROJECT(PROJ_NUM, PROJ_NAME) because in the dependency diagram in
Figure 5, PROJ_NUM → PROJ_NAME
EMPLOYEE(EMP_NUM, EMP_NAME, JOB_CLASS, CHG_HOUR) because
in the dependency diagram in Figure 5, EMP_NUM → EMP_NAME,
JOB_CLASS, CHG_HOUR
ASSIGN(PROJ_NUM, EMP_NUM, HOURS) because in the dependency
diagram in Figure 5, PROJ_NUM, EMP_NUM → HOURS

SUNIL G L Asst. Professor, Dept of CSE(DS), RNSIT . Page 9


Module-III DBMS BCS403

- Note that the new tables are in 2NF because each table is in 1NF and none of the tables
contain partial dependencies. The dependency diagram for the new tables is shown in Figure
6:

PROJ_NUM PROJ_NAME Table Name: PROJECT

EMP_NUM EMP_NAME JOB_CLASS CHG_HOUR Table Name: EMPLOYEE


Transitive
Dependency

EMP_NUM PROJ_NUM HOURS Table Name: ASSIGN


Figure 6: Second Normal Form (2NF) Conversion Results

- Note that the conversion to 2NF did not eliminate the transitive dependency (the conversion
to 3NF will eliminate it). This dependency causes data redundancy if multiple employees
have the same JOB_CLASS and it will therefore create the data anomalies we learned in
Chapter 1.

- Because a partial dependency applies only to tables with composite primary keys, a table
whose primary key consists of only a single attribute must automatically be in 2NF if it is in
1NF.

- Conversion To Third Normal Form (3NF)

- To eliminate the transitive dependency, the table must be converted to 3NF. A table is said to
be in 3NF if it satisfies the following two conditions:

1. It it is in 2NF.
2. It contains no transitive dependencies.

SUNIL G L Asst. Professor, Dept of CSE(DS), RNSIT . Page 10


Module-III DBMS BCS403

- Note that in Figure 6, the EMPLOYEE table is the one that contains transitive dependency:

EMPLOYEE(EMP_NUM, EMP_NAME, JOB_CLASS, CHG_HOUR)

EMP_NUM EMP_NAME JOB_CLASS CHG_HOUR Table Name: EMPLOYEE


Transitive
Dependency

- To eliminate the transitive dependency, simply move the attributes causing data redundancy
(namely JOB_CLASS and CHG_HOUR) into a new table called JOB. Then in the
EMPLOYEE table, define a foreign key that will be used to link it to the JOB table. In this
case, the foreign key will be JOB_CLASS. The result of the conversion to 3NF will be the
following tables:

PROJ_NUM PROJ_NAME Table Name: PROJECT

EMP_NUM EMP_NAME JOB_CLASS Table Name: EMPLOYEE

JOB_CLASS CHG_HOUR Table Name: JOB

EMP_NUM PROJ_NUM HOURS Table Name: ASSIGN

- Note that the conversion to 3NF has eliminated the original EMPLOYEE table’s transitive
dependency; the tables are now said to be in third normal form (3NF).

SUNIL G L Asst. Professor, Dept of CSE(DS), RNSIT . Page 11


Module-III DBMS BCS403

- The Boyce-Codd Normal Form (BCFN)

- A table T is said to be in Boyce-Codd Normal Form (BCFN) if every determinant in the


table is a superkey of T.
- Note that every table in BCNF is also in 3NF, however, a table in 3NF is not necessarily
in BCNF (see following example).
- A table that is in 3NF violates BCNF if it contains a nonkey that is the determinant of a
key attribute. This situation can be illustrated using the example in Figure 7 below:

A B C D

Figure 7: A Table That is In 3NF But Not In BCNF

- Note the following functional dependencies about Figure 7:

A, B → C, D
C→B

- Note that the table structure in Figure 7 has no partial dependencies nor does it contain
transitive dependencies (Note that C → B indicates that a nonkey attribute determines a
key attribute and this dependency is neither partial nor transitive).
- Therefore, the table structure in Figure 7 is in 3NF but not in BCNF because of the
dependency C → B.
- To convert the table structure in Figure 7 to BCNF, follow the following procedure:

1. Change the primary key to A, C and create table containing A, C and D.


2. Create another table containing C as the primary key and B. Note that C will also
serve as the foreign key to link this table to the table created in step 1.

SUNIL G L Asst. Professor, Dept of CSE(DS), RNSIT . Page 12


Module-III DBMS BCS403

- The conversion to BCNF is shown in Figure 8.

A C D

C B

Figure 8: The Decomposition of a Table Structure To Meet BCNF Requirements

- Let us apply this procedure to the table in Figure 9.

Primary Key: STU_ID,STAFF_ID


STU_ID STAFF_ID CLASS_CODE ENROLL_GRADE
125 25 21334 A
125 20 32456 C
135 20 28458 B
144 25 27563 C
144 20 32456 B
Figure 9: Sample Data For a BCNF Conversion

- Note the following dependencies in Figure 9:

STU_ID, STAFF_ID → CLASS_CODE, ENROLL_GRADE


CLASS_CODE → STAFF_ID

STU_ID STAFF_ID CLASS_CODE ENROLL_GRADE

- The table structure above is in 3NF but not BCNF because CLASS_CODE is a
determinant but not a superkey key. Why? To convert this table structure, we apply the
above procedure by creating two tables. The first table will contain STU_ID,
CLASS_CODE and ENROLL_GRADE (with STU_ID and CLASS_CODE as the primary
key). The second table will contain the attributes CLASS_CODE and STAFF_ID with

SUNIL G L Asst. Professor, Dept of CSE(DS), RNSIT . Page 13


Module-III DBMS BCS403

CLASS_CODE as the primary key. The result of the conversion to BCNF is shown in
Figure 10 below.

STU_ID CLASS_CODE ENROLL_GRADE

CLASS_CODE STAFF_ID

Figure 10: Conversion To BCNF

SUNIL G L Asst. Professor, Dept of CSE(DS), RNSIT . Page 14


Module-III DBMS BCS403

Examples

SUNIL G L Asst. Professor, Dept of CSE(DS), RNSIT . Page 15


Module-III DBMS BCS403

SUNIL G L Asst. Professor, Dept of CSE(DS), RNSIT . Page 16


Module-III DBMS BCS403

Multivalued Dependencies
For example, consider the relation EMP shown in Figure below:

■ A tuple in this EMP relation represents the fact that an employee whose name is
Ename works on the project whose name is Pname and has a dependent whose
name is Dname
■ An employee may work on several projects and may have several dependents

■ The employee's projects and dependents are independent of one another

■ To keep the relation state consistent, and to avoid any spurious relationship
between the two independent attributes, we must have a separate tuple to
represent every combination of an employee's dependent and an employee's
project

■ In the relation state shown in the EMP, the employee Smith works on two
projects 'X' and 'Y' and has two dependents 'John' and 'Anna' and therefore there
are 4 tuples to represent these facts together

■ The relation EMP is an all-key relation (with key made up of all attributes) and

■ therefore no f.d's and as such qualifies to be a BCNF relation

■ There is a redundancy in the relation EMP-the dependent information is


repeated for every project and project information is repeated for every
dependent

■ To address this situation, the concept of multivalued dependency(MVD)


was

■ proposed and based on this dependency, the fourth normal form was defined

SUNIL G L Asst. Professor, Dept of CSE(DS), RNSIT . Page 17


Module-III DBMS BCS403

■ Multivalued dependencies are a consequence of 1NF which disallows an


attribute in a tuple to have a set of values, and the accompanying process of
converting an unnormalized relation into 1NF

■ Informally, whenever two independent 1:N relationships are mixed in the same
relation, R(A, B, C), an MVD may arise.

Formal Definition of Multivalued Dependency

Definition. A multivalued dependency x->Y specified on relation schema R,


where X and Y are both subsets of R, specifies the following constraint on any
relation state r of R: If two tuples t1 and t2 exist in r such that t1[X] = t2[X], then two
tuples t3 and t4 should also exist in r with the following properties where we use Z to

denote (R -> (X u Y))

■ t3[X] = t4[X] = t1[X] = t2[X].


• t3[Y] = t1[Y] and t4[Y] = t2[Y].
• t3[Z] = t2[Z] and t4[Z] = t1[Z].

The process of normalizing a relation involving the nontrivial MVDs that is not in
4NF consists of decomposing it so that each MVD is represented by a separate
relation where it becomes a trivial MVD

■ We decompose EMP into EMP_PROJECTS and EMP_DEPENDENTS


■ Both EMP_PROJECTS and EMP_DEPENDENTS are in 4NF, because the

SUNIL G L Asst. Professor, Dept of CSE(DS), RNSIT . Page 18


Module-III DBMS BCS403

MVDs Ename -- Pname in EMP_PROJECTS and Ename -- Dname in


EMP_DEPENDENTS are trivial MVDs
■ No other nontrivial MVDs hold in either EMP_PROJECTS or
EMP_DEPENDENTS. No FDs hold in these relation schemas either
Fifth normal form (5NF)
Condition : A relation is in 5NF if it is in 4NF and not contains any join dependency and
joining should be lossless.
• 5NF is satisfied when all the tables are broken into as many tables as possible in order to avoid
redundancy.
• 5NF is also known as Project-join normal form (PJ/NF).

SUNIL G L Asst. Professor, Dept of CSE(DS), RNSIT . Page 19


Module-III DBMS BCS403

First we decompose relation R to R1 and R2 , where if we join R1* R2 , we get a spurious tuple
(any new record is arised) as in fig shown so If we can decompose table further to eliminate
redundancy and anomaly, and when we re-join the decomposed tables by means of candidate
keys, we should not be losing the original data or In simple words, joining two or more
decomposed table should not lose records nor create new.
Example 2:

SUNIL G L Asst. Professor, Dept of CSE(DS), RNSIT . Page 20


MODULE –III DBMS BCS403
Chapter -II SQL
The SQL language may be considered one of the major reasons for the commercial success of
relational databases. The name SQL is presently expanded as Structured Query Language.
Originally, SQL was called SEQUEL (Structured English QUEry Language) and was designed
and implemented at IBM Research as the interface for an experimental relational database
system called SYSTEM R. SQL is now the standard language for commercial relational DBMSs.

SQL is a comprehensive database language: It has statements for data definitions, queries, and
updates. Hence, it is both a DDL and a DML. It also has rules for embedding SQL statements
into a general-purpose programming language such as Java,COBOL,or C/C++.

4.1 SQL Data Definition and Data Types

SQL uses the terms table, row, and column for the formal relational model terms
relation,tuple,andattribute,respectively.We will use the corresponding terms interchangeably.
The main SQL command for data definition is the CREATE statement, which can be used to
create schemas, tables (relations), and domains (as well as other constructs such as views,
assertions, and triggers).

4.1.1 Schema and Catalog Concepts in SQL

The concept of an SQL schema was incorporated starting with SQL2 in order to group together
tables and other constructs that belong to the same database application. An SQL schema is
identified by a schema name, and includes an authorization identifier to indicate the user or
account who owns the schema,as well as descriptors for each element in the schema.Schema
elements include tables,constraints,views,domains,and other constructs (such as authorization
grants) that describe the schema.

A schema is created via the CREATE SCHEMA statement,which can include all the schema
elements’ definitions. Alternatively, the schema can be assigned a name and authorization
identifier, and the elements can be defined later. For example, the following statement creates a
schema called COMPANY,owned by the user with authorization identifier ‘Jsmith’.Note that
each statement in SQL ends with a semicolon.

CREATE SCHEMA COMPANY AUTHORIZATION ‘Jsmith’;

SUNIL G L Asst. Professor, Dept of CSE(DS), RNSIT . Page 1


MODULE –III DBMS BCS403
In general,not all users are authorized to create schemas and schema elements.The privilege to
create schemas, tables, and other constructs must be explicitly granted to the relevant user
accounts by the system administrator or DBA.

4.1.2 The CREATE TABLE Command in SQL

The CREATE TABLE command is used to specify a new relation by giving it a name and
specifying its attributes and initial constraints.The attributes are specified first, and each attribute
is given a name, a data type to specify its domain of values, and any attribute constraints, such as
NOT NULL. The key, entity integrity, and referential integrity constraints can be specified
within the CREATE TABLE statement after the attributes are declared, or they can be added
later using the ALTER TABLE command. we can explicitly attach the schema name to the
relation name, separated by a period.

For example,by writing

CREATE TABLE COMPANY.EMPLOYEE ...

rather than

CREATE TABLE EMPLOYEE ...

we can explicitly (rather than implicitly) make the EMPLOYEEtable part of the COMPANY
schema.

The relations declared through CREATE TABLE statements are called base tables (or base
relations); this means that the relation and its tuples are actually created and stored as a file by
the DBMS.Base relations are distinguished from virtual relations, created through the CREATE
VIEWstatement which may or may not correspond to an actual physical file.

Example:

CREATE TABLE EMPLOYEE ( Fname VARCHAR(15) NOT NULL, Minit CHAR, Lname
VARCHAR(15) NOT NULL, Ssn CHAR(9) NOT NULL, Bdate DATE, Address
VARCHAR(30), Sex CHAR, Salary DECIMAL(10,2), Super_ssn CHAR(9), Dno INT NOT
NULL, PRIMARY KEY (Ssn), FOREIGN KEY (Super_ssn) REFERENCES
EMPLOYEE(Ssn), FOREIGN KEY (Dno) REFERENCES DEPARTMENT(Dnumber)) ;

SUNIL G L Asst. Professor, Dept of CSE(DS), RNSIT . Page 2


MODULE –III DBMS BCS403
CREATE TABLE DEPARTMENT ( Dname VARCHAR(15) NOT NULL, Dnumber INT NOT
NULL, Mgr_ssn CHAR(9) NOT NULL, Mgr_start_date DATE, PRIMARY KEY (Dnumber),
UNIQUE (Dname), FOREIGN KEY (Mgr_ssn) REFERENCES EMPLOYEE(Ssn));

4.1.3 Attribute Data Types and Domains in SQL

The basic data types available for attributes include numeric, character string, bit
string,Boolean,date,and time.

■Numeric data types include integer numbers of various sizes (INTEGER or INT, and
SMALLINT) and floating-point (real) numbers of various precision (FLOAT or REAL, and
DOUBLE PRECISION). Formatted numbers can be declared by using DECIMAL(i,j)—or
DEC(i,j) or NUMERIC(i,j)—where i, the precision, is the total number of decimal digits and j,
the scale, is the number of digits after the decimal point.

■Character-string data types are either fixed length—CHAR(n) or CHARACTER(n), where n


is the number of characters—or varying length— VARCHAR(n) or CHAR VARYING(n) or
CHARACTER VARYING(n),where nis the maximum number of characters.When specifying a
literal string value,it is placed between single quotation marks (apostrophes), and it is case
sensitive (a distinction is made between uppercase and lowercase).3 For fixedlength strings, a
shorter string is padded with blank characters to the right. For example, if the value ‘Smith’ is for
an attribute of type CHAR(10), it is padded with five blank characters to become ‘Smith ’ if
needed.

■Bit-string data types are either of fixed length n—BIT(n)—or varying length—BIT
VARYING(n), where n is the maximum number of bits. The default for n, the length of a
character string or bit string, is 1. Literal bit strings are placed between single quotes but
preceded by a B to distinguishthem from character strings;

for example,B‘10101’

■A Boolean data type has the traditional values of TRUE or FALSE. In SQL, because of the
presence of NULL values, a three-valued logic is used, so a third possible value for a Boolean
data type is UNKNOWN.

SUNIL G L Asst. Professor, Dept of CSE(DS), RNSIT . Page 3


MODULE –III DBMS BCS403
■ The DATE data type has ten positions, and its components are YEAR, MONTH, and DAY in
the form YYYY-MM-DD.

The TIME data type has at least eight positions,with the components HOUR,MINUTE,and
SECOND in the form HH:MM:SS.

■ A timestamp data type (TIMESTAMP) includes the DATE and TIME fields, plus a minimum
of six positions for decimal fractions of seconds and an optional WITH TIME ZONE
qualifier.Literal values are represented by singlequoted strings preceded by the keyword
TIMESTAMP, with a blank space between data and time;

for example, TIMESTAMP ‘2008-09-27 09:12:47.648302’.

■Another data type related to DATE, TIME, and TIMESTAMP is the INTERVAL data type.
This specifies an interval—a relative value that can be used to increment or decrement an
absolute value of a date, time, or timestamp. Intervals are qualified to be either YEAR/MONTH
intervals or DAY/TIME intervals.

It is possible to specify the data type of each attribute directly,as in Figure 4.1;alternatively, a
domain can be declared, and the domain name used with the attribute specification. This makes it
easier to change the data type for a domain that is used by numerous attributes in a schema,and
improves schema readability.For example, we can create a domain SSN_TYPE by the following
statement:

CREATE DOMAIN SSN_TYPE AS CHAR(9);

We can use SSN_TYPE in place of CHAR(9) in the above create table for the attributes Ssn and
Super_ssn of EMPLOYEE, Mgr_ssn of DEPARTMENT, Essn of WORKS_ON, and Essn of
DEPENDENT.

4.2 Specifying Constraints in SQL

SUNIL G L Asst. Professor, Dept of CSE(DS), RNSIT . Page 4


MODULE –III DBMS BCS403
Now will describe the basic constraints that can be specified in SQL as part of table creation.
These include key and referential integrity constraints, restrictions on attribute domains and
NULLs,and constraints on individual tuples within a relation.

4.2.1 Specifying Attribute Constraints and Attribute Defaults

Because SQL allows NULLs as attribute values,a constraint NOT NULLmay be specified if
NULLis not permitted for a particular attribute.This is always implicitly specified for the
attributes that are part of the primary key of each relation,but it can be specified for any other
attributes whose values are required not to be NULL.

It is also possible to define a default value for an attribute by appending the clause
DEFAULT<value> to an attribute definition.

Another type of constraint can restrict attribute or domain values using the CHECK clause
following an attribute or domain definition.

For example, suppose that department numbers are restricted to integer numbers between 1 and
20; then, we can change the attribute declaration of Dnumber in the DEPARTMENT table to the
following: Dnumber INT NOT NULL CHECK (Dnumber> 0 AND Dnumber< 21);

Ex:

CREATE TABLE EMPLOYEE ( Dno INT NOT NULL DEFAULT 1, CONSTRAINT EMPPK
PRIMARY KEY (Ssn), CONSTRAINT EMPDEPTFK FOREIGN KEY(Dno) REFERENCES
DEPARTMENT(Dnumber) ON DELETE SET DEFAULT ON UPDATE CASCADE);

TheCHECKclause can also be used in conjunction with the CREATE DOMAINstatement.

For example,we can write the following statement:

CREATE DOMAIN D_NUM AS INTEGER CHECK (D_NUM > 0 AND D_NUM <21 );

We can then use the created domain D_NUM as the attribute type for all attributes that refer to
department numbers In create table , such as Dnumber of DEPARTMENT, Dnum of
PROJECT,Dno of EMPLOYEE,and so on.

4.2.2 Specifying Key and Referential Integrity Constraints

SUNIL G L Asst. Professor, Dept of CSE(DS), RNSIT . Page 5


MODULE –III DBMS BCS403
The PRIMARY KEY clause specifies one or more attributes that make up the primary key of a
relation. If a primary key has a single attribute, the clause can follow the attribute directly.

Ex: Dnumber INT PRIMARY KEY;

The UNIQUE clause specifies alternate (secondary) keys, as illustrated in the DEPARTMENT
and PROJECT table declarations.

Ex: DnameVARCHAR(15) UNIQUE;

Referential integrity is specified via the FOREIGN KEY clause. A referential integrity constraint
can be violated when tuples are inserted or deleted, or when a foreign key or primary key
attribute value is modified. The default action that SQL takes for an integrity violation is to reject
the update operation that will cause a violation, which is known as the RESTRICT option.
However, the schema designer can specify an alternative action to be taken by attaching a
referential triggered action clause to any foreign key constraint. The options include SET NULL,
CASCADE, and SET DEFAULT. An option must be qualified with either ON DELETE or ON
UPDATE. We illustrate this with the examples shown in create table Here, the database
designer chooses ON DELETE SET NULL and ON UPDATE CASCADE for the foreign key
Super_ssn of EMPLOYEE. This means that if the tuple for a supervising employee is deleted,
the value of Super_ssnis automatically set to NULLfor all employee tuples that were referencing
the deleted employee tuple.On the other hand,if the Ssnvalue for a supervising employee is
updated (say,because it was entered incorrectly),the new value is cascaded to Super_ssn for all
employee tuples referencing the updated employee tuple.8

4.2.3 Giving Names to Constraints

A constraint may be given a constraint name,following the keyword CONSTRAINT. The names
of all constraints within a particular schema must be unique. A constraint name is used to
identify a particular constraint in case the constraint must be dropped later and replaced with
another constraint. Giving names to constraints is optional.

Ex: CONSTRAINT EMPPK PRIMARY KEY (Ssn).

4.2.4 Specifying Constraints on Tuples Using CHECK

SUNIL G L Asst. Professor, Dept of CSE(DS), RNSIT . Page 6


MODULE –III DBMS BCS403
In addition to key and referential integrity constraints, which are specified by special keywords,
other table constraints can be specified through additional CHECK clauses at the end of a
CREATE TABLE statement. These can be called tuple-based constraints because they apply to
each tuple individually and are checked whenever a tuple is inserted or
modified.Forexample,suppose that the DEPARTMENTtable in Figure 4.1 had an additional
attribute Dept_create_date, which stores the date when the department was created. Then we
could add the following CHECK clause at the end of the CREATE TABLE statement for the
DEPARTMENT table to make sure that a manager’s start date is later than the department
creation date.

CHECK (Dept_create_date<= Mgr_start_date);

4.3 Basic Retrieval Queries in SQL

SQL allows a table (relation) to have two or more tuples that are identical in all their attribute
values.Hence,in general, an SQL table is not a set of tuples, because a set does not allow two
identical members; rather,it is a multiset (sometimes called a bag) of tuples.

SUNIL G L Asst. Professor, Dept of CSE(DS), RNSIT . Page 7


MODULE –III DBMS BCS403

4.3.1 The SELECT-FROM-WHERE Structure of Basic SQL Queries

The basic form of the SELECT statement, sometimes called a mapping or a select-from-where
block, isformed of the three clauses SELECT, FROM, and WHERE and has the following form:

SELECT <attribute list>


FROM <table list>
WHERE <condition>;
where
■<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.
In SQL,the basic logical comparison operators for comparing attribute values with one another
and with literal constants are =, <, <=, >, >=, and <>(not equal operator).

Query 1.

Ex:Retrieve the birth date and address of the employee(s) whose name is ‘John B.Smith’.

SELECTBdate, Address FROM EMPLOYEE WHEREFname=‘John’ AND Minit=‘B’ AND


Lname=‘Smith’;

SUNIL G L Asst. Professor, Dept of CSE(DS), RNSIT . Page 8


MODULE –III DBMS BCS403

Query 1.a.

Retrieve the name and address of all employees who work for the ‘Research’department.

SELECT Fname, Lname, Address FROM EMPLOYEE, DEPARTMENT WHERE


Dname=‘Research’ AND Dnumber=Dno;

In the WHERE clause of query, the condition Dname = ‘Research’is a selection condition that
chooses the particular tuple of interest in the DEPARTMENT table,becauseDname is an attribute
of DEPARTMENT. The condition Dnumber = Dno is called a join condition, because it
combines two tuples: one from DEPARTMENT and one from EMPLOYEE, whenever the value
of Dnumber in DEPARTMENT is equal to the value of Dno in EMPLOYEE.

A query that involves only selection and join conditions plus projection attributes is known as a
select-project-join query. The next example is a select-project-join query with two join
conditions.

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 birth date.

SELECT Pnumber, Dnum, Lname, Address, Bdate FROM PROJECT, DEPARTMENT,


EMPLOYEE WHERE Dnum=Dnumber AND Mgr_ssn=Ssn AND Plocation=‘Stafford’;

SUNIL G L Asst. Professor, Dept of CSE(DS), RNSIT . Page 9


MODULE –III DBMS BCS403

The join condition Dnum = Dnumber relates a project tuple to its controlling department
tuple,whereas the join condition Mgr_ssn=Ssnrelates the controlling department tuple to the
employee tuple who manages that department.

4.3.2 Ambiguous Attribute Names, Aliasing, Renaming, and Tuple Variables

In SQL,the same name can be used for two (or more) attributes as long as the attributes are in
different relations.If this is the case,and a multitable query refers to two or more attributes with
the same name, we must qualify the attribute name with the relation name to prevent ambiguity.
This is done by prefixing the relation name to the attribute name and separating the two by
a period.

SELECT Fname, EMPLOYEE.Name, Address FROM EMPLOYEE, DEPARTMENT WHERE


DEPARTMENT.Name=‘Research’ AND DEPARTMENT.Dnumber=EMPLOYEE.Dnumber;

We can also create an alias for each table name to avoid repeated typing of long table names.

For each employee, retrieve the employee’s first and last name and the first and last name of
his or her immediate supervisor.

SELECT E.Fname, E.Lname, S.Fname, S.Lname

FROM EMPLOYEE AS E, EMPLOYEE AS S WHERE E.Super_ssn=S.Ssn;

SUNIL G L Asst. Professor, Dept of CSE(DS), RNSIT . Page 10


MODULE –III DBMS BCS403
In this case, we are required to declare alternative relation names E and S, called aliases or tuple
variables, for the EMPLOYEE relation. An alias can follow the keyword AS, as shown in
Query,or it can directly follow the relation name—for example, by writing EMPLOYEE E,
EMPLOYEE S in the FROM clause of Query.

It is also possible to rename the relation attributes within the query in SQL by giving them
aliases. For example,if we write EMPLOYEE AS E(Fn, Mi, Ln, Ssn, Bd, Addr, Sex, Sal, Sssn,
Dno) in the FROMclause,Fn becomes an alias for Fname,Mi for Minit,Ln for Lname,and so on.

In Query,we can think of E and S as two different copies of the EMPLOYEErelation;the first, E,
represents employees in the role of supervisees or subordinates; the second, S, represents
employees in the role of supervisors.

4.3.3 Unspecified WHERE Clause and Use of the Asterisk

A missing WHERE clause indicates no condition on tuple selection; hence, all tuples of the
relation specified in the FROM clause qualify and are selected for the query result.If more than
one relation is specified in the FROM clause and there is no WHERE clause, then the CROSS
PRODUCT—all possible tuple combinations—of these relations is selected.

Queries 9 and 10.

Select all EMPLOYEE Ssns (Q9) and all combinations of EMPLOYEE Ssn and
DEPARTMENT Dname (Q10) in the database.

Q9: SELECT Ssn FROM EMPLOYEE;

SUNIL G L Asst. Professor, Dept of CSE(DS), RNSIT . Page 11


MODULE –III DBMS BCS403
Q10: SELECT Ssn, Dname FROM EMPLOYEE, DEPARTMENT;

It is extremely important to specify every selection and join condition in the WHERE clause; if
any such condition is overlooked, incorrect and very large relations may result.

4.3.4 Tables as Sets in SQL

SQL usually treats a table not as a set but rather as a multiset; duplicate tuples can appear more
than once in a table,and in the result of a query. SQL does not automatically eliminate duplicate
tuples in the results of queries.

If we do want to eliminate duplicate tuples from the result of an SQL query, we use the keyword
DISTINCT in the SELECT clause, meaning that only distinct tuples should remain in the result.

Query 11. Retrieve the salary of every employee (Q11) and all distinct salary values

(Q11A).

SUNIL G L Asst. Professor, Dept of CSE(DS), RNSIT . Page 12


MODULE –III DBMS BCS403
Q11: SELECT ALL Salary FROM EMPLOYEE;

Q11A: SELECT DISTINCT Salary FROM EMPLOYEE;

In general, a query with SELECT DISTINCT eliminates duplicates, whereas a query with
SELECT ALL does not.

SQL has directly incorporated some of the set operations from mathematical set theory,which are
also part of relational algebra (see Chapter 6).There are set union (UNION), set difference
(EXCEPT) and set intersection (INTERSECT) operations. The relations resulting from these
set operations are sets of tuples; that is, duplicate tuples are eliminated from the result. These set
operations apply only to union-compatible relations, so we must make sure that the two relations
on which we apply the operation have the same attributes and that the attributes appear in the
same order in both relations.The next example illustrates the use of UNION.

Query 4. Make a list of all project numbers for projects that involve an employee whose last
name is ‘Smith’, either as a worker or as a manager of the department that controls the project.

(SELECT DISTINCT Pnumber FROM PROJECT, DEPARTMENT, EMPLOYEE WHERE


Dnum=Dnumber AND Mgr_ssn=Ssn AND Lname=‘Smith’)

UNION

( SELECT DISTINCT Pnumber FROM PROJECT, WORKS_ON, EMPLOYEE WHERE


Pnumber=Pno AND Essn=Ssn AND Lname=‘Smith’);

SUNIL G L Asst. Professor, Dept of CSE(DS), RNSIT . Page 13


MODULE –III DBMS BCS403

4.3.5 Substring Pattern Matching and Arithmetic Operators

In this section we discuss several more features of SQL.The first feature allows comparison
conditions on only parts of a character string, using the LIKE comparison operator.This can be
used for string pattern matching. Partial strings are specified using two reserved characters: %
replaces an arbitrary number of zero or more characters,and the underscore (_) replaces a single
character.Forexample,consider the following query.

Query 12.Retrieve all employees whose address is in Houston,Texas.

SELECT Fname, Lname FROM EMPLOYEE WHERE Address LIKE ‘%Houston,TX%’;

Query 12A.Find all employees who were born during the 1950s.

SELECT Fname, Lname FROM EMPLOYEE WHERE Bdate LIKE ‘_ _ 5 _ _ _ _ _ _ _’;

Another feature allows the use of arithmetic in queries. The standard arithmetic operators for
addition (+), subtraction (–), multiplication (*), and division (/) can be applied to numeric values
or attributes with numeric domains.

Query 13.Show the resulting salaries if every employee working on the ‘ProductX’project is
given a 10 percent raise.

SELECT E.Fname, E.Lname, 1.1 * E.Salary AS Increased_sal FROM EMPLOYEE AS E,


WORKS_ON AS W, PROJECT AS P WHERE E.Ssn=W.Essn AND W.Pno=P.Pnumber AND
P.Pname=‘ProductX’;

SUNIL G L Asst. Professor, Dept of CSE(DS), RNSIT . Page 14


MODULE –III DBMS BCS403
Another comparison operator, which can be used for convenience,isBETWEEN, which is
illustrated in Query 14.

Query 14.Retrieve all employees in department 5 whose salary is between $30,000 and
$40,000.

SELECT * FROM EMPLOYEE WHERE (Salary BETWEEN 30000 AND 40000) AND
Dno = 5;
The condition (Salary BETWEEN30000AND40000) in Q14is equivalent to the condition

((Salary >= 30000) AND (Salary <= 40000)).

4.3.6 Ordering of Query Results

SQL allows the user to order the tuples in the result of a query by the values of one or more of
the attributes that appear in the query result, by using the ORDER BY clause.

Ex: SELECT Salary FROM EMPLOYEE ORDER BY Salary ;

The default order is in ascending order of values.We can specify the keyword DESC if we want
to see the result in a descending order of values.The keyword ASCcan be used to specify
ascending order explicitly.

4.3.7 Discussion and Summary of Basic SQL Retrieval Queries

A simple retrieval query in SQL can consist of up to four clauses, but only the first two—
SELECT and FROM—are mandatory. The clauses are specified in the following order,with the
clauses between square brackets [ ... ] being optional:

SELECT <attribute list> FROM <table list>[ WHERE<condition> ] [ ORDER BY <attribute


list> ];

The SELECTclause lists the attributes to be retrieved,and the FROMclause specifies all relations
(tables) needed in the simple query. The WHERE clause identifies the conditions for selecting
the tuples from these relations, including join conditions if needed.ORDERBYspecifiesan order
for displaying the results of a query.

SUNIL G L Asst. Professor, Dept of CSE(DS), RNSIT . Page 15


MODULE –III DBMS BCS403
4.4 INSERT, DELETE, and UPDATE Statements in SQL
4.4.1 The INSERT Command

In its simplest form,INSERTis used to add a single tuple to a relation.We must specify the
relation name and a list of values for the tuple.The values should be listed in the same order in
which the corresponding attributes were specified in the CREATE TABLE command.

Ex: INSERT INTO EMPLOYEE VALUES ( ‘Richard’,‘K’,‘Marini’,‘653298653’,‘1962-12-


30’,‘98 Oak Forest, Katy, TX’,‘M’, 37000,‘653298653’, 4 );

A second form of the INSERT statement allows the user to specify explicit attribute names that
correspond to the values provided in the INSERTcommand.This is useful if a relation has many
attributes but only a few of those attributes are assigned values in the new tuple.

INSERT INTO EMPLOYEE (Fname, Lname, Dno, Ssn) VALUES (‘Richard’,‘Marini’,


4,‘653298653’);

Attributes not specified in the above query are set to their DEFAULT or to NULL, and the
values are listed in the same order as the attributes are listed in the INSERTcommand itself.

A variation of the INSERT command inserts multiple tuples into a relation in conjunction with
creating the relation and loading it with the result of a query.

CREATE TABLE WORKS_ON_INFO (Emp_nameVARCHAR(15), Proj_name


VARCHAR(15), Hours_per_week DECIMAL(3,1) );

INSERT INTO WORKS_ON_INFO ( Emp_name, Proj_name, Hours_per_week )


SELECT E.Lname, P.Pname, W.Hours FROM PROJECT P, WORKS_ON W, EMPLOYEE E
WHERE P.Pnumber=W.Pno AND W.Essn=E.Ssn;

4.4.2 The DELETE Command

The DELETE command removes tuples from a relation.It includes a WHERE clause, similar to
that used in an SQL query, to select the tuples to be deleted. Tuples are explicitly deleted from
only one table at a time. However, the deletion may propagate to tuples in other relations if
referential triggered actions are specified in the referential integrity constraints of the DDL.

SUNIL G L Asst. Professor, Dept of CSE(DS), RNSIT . Page 16


MODULE –III DBMS BCS403
Depending on the number of tuples selected by the condition in the WHERE clause, zero, one, or
several tuples can be deleted by a single DELETE command. A missing WHERE clause
specifies that all tuples in the relation are to be deleted; however, the table remains in the
database as an empty table.

Ex: DELETE FROM EMPLOYEE WHERE Lname=‘Brown’;

DELETE FROM EMPLOYEE WHERE Ssn=‘123456789’;

DELETE FROM EMPLOYEE WHERE Dno=5;

DELETE FROM EMPLOYEE;

The above DELETE commands if applied independently to the database in Figure 3.6,will
delete zero,one,four,and all tuples,respectively,from the EMPLOYEErelation:

4.4.3 The UPDATE Command

The UPDATE command is used to modify attribute values of one or more selected tuples. As in
the DELETE command, a WHERE clause in the UPDATE command selects the tuples to be
modified from a single relation. However, updating a primary key value may propagate to the
foreign key values of tuples in other relations if such a referential triggered action is specified in
the referential integrity constraints of the DDL. An additional SET clause in the UPDATE
command specifies the attributes to be modified and their new values.

For example, to change the location and controlling department number of project number
10 to ‘Bellaire’and 5,respectively,we use the below query

UPDATE PROJECT SET Plocation = ‘Bellaire’,Dnum =5 WHERE Pnumber=10;

Several tuples can be modified with a single UPDATE command. An example is to give all
employees in the ‘Research’department a 10 percent raise in salary.

UPDATE EMPLOYEE SET Salary = Salary * 1.1 WHERE Dno = 5;

It is also possible to specify NULLor DEFAULTas the new attribute value.

SUNIL G L Asst. Professor, Dept of CSE(DS), RNSIT . Page 17


MODULE –III DBMS BCS403
4.5 Additional Features of SQL

SQL has a number of additional features .These are as follows:

SQL has various techniques for specifying complex retrieval queries, including nested queries,
aggregate functions, grouping, joined tables,outerjoins,and recursive queries; SQL
views,triggers,and assertions; and commands for schema modification.

■ SQL has various techniques for writing programs in various programming languages that
include SQL statements to access one or more databases. These include embedded (and
dynamic) SQL, SQL/CLI (Call Level Interface) and its predecessor ODBC (Open Data Base
Connectivity), and SQL/PSM (Persistent Stored Modules).

■ Each commercial RDBMS will have,in addition to the SQL commands,a set of commands for
specifying physical database design parameters, file structures for relations, and access paths
such as indexes.

SQL has transaction control commands. These are used to specify units of database processing
for concurrency control and recovery purposes.

. ■ SQL has language constructs for specifying the granting and revoking of privileges to
users.Privileges typically correspond to the right to use certain SQL commands to access certain
relations. Each relation is assigned an owner, and either the owner or the DBA staff can grant to
selected users the privilege to use an SQL statement—such as SELECT, INSERT, DELETE, or
UPDATE—to access the relation.

In addition, the DBA staff can grant the privileges to create schemas, tables, or views to certain
users. These SQL commands—called GRANT and REVOKE—

■ SQL has language constructs for creating triggers. These are generally referred to as active
database techniques, since they specify actions that are automatically triggered by events such as
database updates.

■ SQL has incorporated many features from object-oriented models to have more powerful
capabilities,leading to enhanced relational systems known as object-relational.

■ SQL and relational databases can interact with new technologies such as XML

SUNIL G L Asst. Professor, Dept of CSE(DS), RNSIT . Page 18

You might also like