Module 3

Chapter 1: Normalization: Database Design Theory - Introduction to Normalization using

Functional and Multivalued Dependencies: Informal design guidelines for relation schema,
Functional Dependencies, Normal Forms based on Primary Keys, Second and Third Normal Forms,
Boyce-Codd Normal Form, Multivalued Dependency and Fourth Normal Form, Join Dependencies
and Fifth Normal Form.

Chapter 2: SQL: SQL data definition and data types, specifying constraints in SQL, retrieval queries
in SQL, INSERT, DELETE, and UPDATE statements in SQL, Additional features of SQL.

CHAPTER 1

Database design may be performed using two approaches: bottom-up or top-down.

Abottom-up design methodology (also called design by synthesis)

. It considers the basic relationships among individual attributes as the start

point and uses those to construct relation schemas.
This approach is not very popular in practice because it suffers from the
problem of having to collect a large number of binary relationships among
attributes as the starting point.
" For practical situations, it is next to impossible to capture binary relationships
among allsuch pairs of attributes.

In contrast, a top-down design methodology (also called design by analysis)

. It starts with a number of groupings of attributes into relations that exist

together naturally, for example, on an invoice, a form, or a report.
The relations are then analyzed individually and collectively, leading to further
decomposition until all desirable properties are met.
 Top-down design approach, is more appropriate when performing design of
databases by analysis and decomposition of sets of attributes that appear
together in files, in reports, and on forms in real-life situations.

" Relational database design ultimately produces a set of relations.

. The implicit goals of the design activity are information preservation and
minimum redundancy.
The relational design must preserve all of these concepts, which are originally
captured in the conceptual design after the conceptual to logical design mapping.
Minimizing redundancy implies minimizing redundant storage of the same
information and reducing the need for multiple updates to maintain consistency
to real-world events that
across multiple copies of the same information in response
require making an update.

Informal Design Guidelines for Relation Schemas

as measures to determine the quality of
There are four informal guidelines that may be used
relation schema design:
attributes is clear in the schema.
1. Making sure that the semantics of the
schema, we assume that attributes
Whenever we group attributes to form a relation proper
real-world meaning and a
belonging to one relation have certain
interpretation associated with them.
resulting from the interpretation of
The semnantics of a relation refers to its meaning
attribute values in a tuple.
not
Guideline 1, Design a relation schema so
that it is easy to explain its meaning. Do
attributes from multiple entity types and relationship types into a single
combine type or one
Intuitively, if a relation schema corresponds to one entity
the
explain its meaning. Otherwise, if
relation.
relationship type, it is straightforward to semantic
entities and relationships,
relation corresponds to a mixture of multiple
cannot be easily explained.
ambiguities will result and the relation

Example of Violating
Guideline 1:
EMP_DEPT Dnumber Dname Dmgr ssn
Ename Ssn Bdate Address
 2. Reducing the redundant information in tuples.

" One goal of schema design is to minimize the storage space used by the base relations
(and hence the corresponding files).
" Grouping attributes into relation schemas has a significant effect on storage space.
Storing natural joins of base relations leads to an additional problem referred to as
update anomalies.
These can be classified into insertion anomalies, deletion anomalies, and modification
anomalies

> Insertion Anomalies. Insertion anomalies can be differentiated into two types,
illustrated by the following examples based on the EMP_DEPT relation:
To insert a new employee tuple into EMP_DEPT, we must include either the attribute
values for the department that the employee works for, or NULLs (if the employee
does not work for a department as yet). For example, to insert a new tuple for an
employee who works in department number 5, we must enter all the attribute values
of department 5 correctly so that they are consistent with the corresponding values
for department 5 in other tuples in EMP_DEPT.

V It is difficult to insert a new department that has no employees as yet in the

EMP_DEPT relation. The only way to do this is to place NULL values in the attributes
for employee. This violates the entity integrity for EMP_DEPT because its primary key
Ssn cannot be null. Moreover, when the first employee is assigned to that department,
we do not need this tuple with NULL values anymore.

> Deletion Anomalies. The problem of deletion anomalies is related to the second
insertion anomaly situation just discussed. If we delete from EMP_DEPT an employee
tuple that happens to represent the last employee working for a particular department,
the information concerning that department is lost inadvertently from the database.

> Modification Anomalies. In EMP_DEPT, if we change the value of one of the attributes
of a particular department-say, the manager of department 5-we must update the
tuples of all employees who work in that department; otherwise, the database will
become inconsistent. f we fail to update some tuples, the same department will be
shown to have two different values for manager in different employee tuples, which
would be wrong

" Guideline 2. Design the base relation schemas so that no insertion, deletion, or
modification anomalies are present in the relations. Ifany anomalies are present, note
 RBT: L1, L2, L3

CHAPTER 1

RELATIONAL DATA MODEL AND RELATIONAL DATABASE

CONSTRAINTS

Relational Model Concepts:

The relational model represents the database as a collection of relations.

Informally, each relation resembles a table of values or, to some extent, a flat file
of records.
It is called a flat file because each record has a simple linear or flat structure.
When a relation is thought of as a table of values, each row in the table
represents a collection of related data values.
A row represents a fact that typically corresponds to a real-world entity or
relationship.
The table name and column names are used to help to interpret the meaning of
the values in each row.
For example, the first table is STUDENT, each row represents facts about a
particular student entity. The column names-Name, Student_number, Class, and
Major-specify how to interpret the data values in each row, based on the
column each value is in.
All values in a column are of the same data type.

In the formal relational model terminology, a row is called a TUPLE, a

column header is called an ATTRIBUTE, and the table is called a RELATION.
Veena MS Assistant professor RRIT CSE Page 1 of 40
 DOMAIN:

The data type describing the types of values that can appear in each column is
represented by a DOMAIN of possible values.
A domain D is a set of atomic values.
" By atomic we mean that each value in the domain is indivisible as far as the
formal relational model is concerned.
Acommon method of specifying a domain is to specify a data type from which
the data values forming the domain are drawn.
It is also useful to specify a name for the domain, to help in interpreting its
values.
Adata type or format is also specified for each domain.
Example 1: the data type for the domain Usa_phone_numbers can be declared
as a character string of the form (ddd)ddd-dddd, where each d is a numeric
(decimal) digit and the first three digits form avalid telephone area code.
" Example 2: The data type for Employee_ages is an integer number between 15
and 80.

RELATION SCHEMA and RELATION STATE:

. Arelation schema R, denoted by R(A1, A2, .., A), is made up of arelation name
Rand a list of attributes, A1, Az,.. An. Each attribute Ai is the name ofa role
played by some domain D in the relation schema R. D is called the domain of A
and is denoted by dom(A).
A relation schema is used to describe a relation; R is called the name of this
relation.
The degree (or arity) of a relation is the number of attributes n of its relation
schema.
" A relation of degree seven, which stores information about university students,
would contain seven attributes describing each student as follows:
STUDENT(Name, Ssn, Home_phone, Address, Office_phone, Age, Gpa)
" A relation (or relation state)4 r of the relation schema R(A1, Az, .. , An), also
denoted by r(R), is a set of n-tuples r= (ti, t2, .., tm).
" Each n-tuple tis an ordered list of n values t=<VL V2, ..., Vn>, where
each value vi,
1<=i<=n, is an element of dom (A) or is aspecial NULL value.
The i th value in tuple t, which corresponds to the attribute A,, is referred to as
t[A] or t. A(or t[] if we use the positional notation).
The terms relation intension for the schema R and relation
extension for a
relation state r(R) are also commonly used.

Veena MS Assistant professor RRIT CSE Page 2 of 40

 DBMS MODULE 2

The earlier definition of a relation can be restated more formally using set theory
concepts as follows.
Arelation (or relation state) r(R) is a mathematical relation of degree n on the
domains dom(A1), dom(A2), ...,dom(An), which is a subset of the Cartesian
product (denoted by x) of the domains that define R:
r(R)e (dom(A1) x dom(Az) x... x (dom(An)
Attnbutes
Relation Name

STUDENT
Name Ssr Home phone Address Ofice phone Age Gpa
Benjamin Bayer305-61-2435 (817)373-1616 2918 Bluebonnet Lane NULL 19321
Chung cha Kim 381-62-1245 (817)3754409 125 Kirby Road NULL 18 289

3452 Elgin Road (817)749-1253

Tuples Dick Davidson 422-11-2320 NULL 25

Rohan Panchal480 22 1100 (817)376 9821 265 Lark Lane (817)749 6492 28 R93

Barbara Bonson533 69-1238 (817)839 84617384 Fontana Lane NUL 1G 26

CHARACTERISTICS OF RELATIONS

a. Ordering of Tuples in a Relation.

Alternative Definition of a
b. Ordering of Values within a Tuple and an
Relation.
C. Values and NULLS in the Tuples.
d. Interpretation (Meaning) of a Relation.

a. Odering of Tuples in a Relation:

Mathematically, elements of a set have no
A relation is defined as a set of tuples.
have any particular order.
order among them; hence, tuples in a relation do not
ordering of tuples. However, in a
In other words, a relation is not sensitive to the
in memory), so there always is an
file, records are physically stored on disk (or
order among the records.
This ordering indicates first, second, ith,
and last records in the file. Similarly,
rows are displayed in a certain order.
when we display a relation as a table, the
definition because a relation attempts to
Tuple ordering is not part of a relation
represent facts at a logical or
abstract level.
same relation.
Many tuple orders can be specified on the no preference for
The definition ofa relation does not specify any order: There is
one ordering over another.

Page 3 of 40