UNIT III

3.1 PITFALLS IN RELATIONAL-DATABASE DESIGN

The undesirable properties that a bad design may have are:

 Repetition of information
 Inability to represent certain information
We shall discuss these problems with the help of a modified database design for
our banking example: In contrast to the relation schema. Suppose the information
concerning loans is kept in one single relation, lending, which is defined over the
relation schema
Lending-schema = (branch-name, branch-city, assets, customer-name,
loan-number, amount)
A tuple t in the lending relation has the following intuitive meaning:
• t[assets] is the asset figure for the branch named t[branch-name].
• t[branch-city] is the city in which the branch named t[branch-name] is located.
• t[loan-number] is the number assigned to a loan made by the branch named
t[branch-name] to the customer named t[customer-name].
• t[amount] is the amount of the loan whose number is t[loan-number].
Suppose that we wish to add a new loan to our database. Say that the loan is
made by the Perryridge branch to Adams in the amount of $1500. Let the loan-number
be L-31. In our design, we need a tuple with values on all the attributes of Lending-
schema. Thus, we must repeat the asset and city data for the Perryridge branch, and
must add the tuple
(Perryridge, Horseneck, 1700000, Adams, L-31, 1500)

3.2 DECOMPOSITION

Decompose a relation schema that has many attributes into several schemas with
fewer attributes. Careless decomposition, however, may lead to another form of bad
design.
 Consider an alternative design in which we decompose Lending-schema into the
following two schemas:
Branch-customer-schema = (branch-name, branch-city, assets, customer-name)
Customer-loan-schema = (customer-name, loan-number, amount)
We construct our new relations branch-customer
(Branch-customer) and customer-loan (Customer-loan-schema):
branch-customer = Πbranch-name, branch-city, assets, customer-name(lending)
customer -loan = Πcustomer-name, loan-number, amount(lending)

3.3 PROPERTIES OF DECOMPOSITION

1. Lossless - Join Dependencies:

A decomposition of R into two schema with attribute sets X and Y is said to be
lossless-join decomposition with respect to F if for every instance r of R that satisfies the
dependencies in F,
CX(r) Y(r) = r. in other words we can recover the original relation from the
decomposed relations.
Example: The instance SP( r ) and PD( r ), we loss some information. In
particular, suppose that the tuples in r denote relationships.
We can no longer tell that the relationship (s1, p1,d3) and (s3, p1, d1) do not hold.
The decomposition of schema SPD into SP and PD is therefore lossy if the instance r
shown in the figure is legal, that is if this instance could arise in the enterprise being
modeled.
All decomposition used to eliminate redundancy must be lossless.
2. Dependency-preserving decomposition:
A dependency-preserving decomposition allows us to enforce all FDs by
examining a single relation instance on each insertion or modification of a tuple. To
define dependency-preserving decompositions we have to introduce the concept of a
projection of FDs.
The projection of F on X is the set of FDs in the closure F+ that involve only
attributes in X. we denote the projection of F on attributes X as FX. A dependency U V
in F+ is in FX only if all the attributes in U and V are in X.
The decomposition of relation schema R with FDs F into schemas with attribute
sets X and Y is dependency-preserving if (FXFY)+ = F+.

3.4 FUNCTIONAL DEPENDENCY

A functional dependency (FD) is a type of integrity constraint that generalizes

the concept of a key. Let R be a relation schema and let X and Y are nonempty sets of
attributes of R. An instance r or R satisfies the FD X → Y if the following holds for every
pair of tuples t1 and t2 in r, If t1.X = t2.X, then t1.Y = t2.Y

Example: A B C D
a1 B1 c1 d1
a1 B1 c1 d2
a1 B2 c2 d1
a2 B1 c3 d1

An instance that stratifies AB → C

Reasoning about FDs:
Closure of a set of FDs
The set of all FDs implied by given set F of FD’s is called the closure of F
and is denoted by F+. Armstrong’s Axioms can be applied to infer/compute all FDs,
implied by the set of FDs. We use X, Y, and Z as the set of attributes of R,
Reflexivity: If X  Y, then X → Y.
Augmentation: If X → Y, then XZ → YZ for any Z.
Transitivity: If X → Y & Y → Z then X → Z.
Union: If X → Y & X → Z, then X → YZ.
Decomposition: If X → YZ, then X → Y and X → Z.
 Trivial FD
A trivial FD is one in which the right side contains only attributes that also
appear on the left side. Using reflexivity, we can generate all trivial dependencies, X →
Y where Y  X, X  ABC and Y  ABC
Attribute closure:
We compute the attribute closure X+ with respect to F which is the set of
attribute A such that X→A can be inferred using the Armstrong Axioms.

3.5 NORMAL FORMS

Introduction:
Normalization is the process for deciding which attributes should be grouped
together in a relation. The process of normalization is developed by E.F. Codd. It is a
process of building database structure to store the data.
Normalization is performed as a series of tests on a relation to determine
whether it satisfies or violates.
Three normal forms were initially processed namely first, second & third. Next Boyce-
Codd nomal form was introduced by R.Boyce & E.F.Codd.
Properties of Normalized relations:
Ideal relations after normalization should have the following properties, so that
the problems mentioned above do not occur for relations in the ideal normalized form.
 No data value should be duplicated in different rows unnecessarily;
 A value must be specified and required for every attribute in a row;
 Each relation should be self contained, ie., if a row from a relation is deleted,
important information should not be accidentally lost.
 When a row is added to a relation other relations in the database should not be
affected.
 A value of an attribute in a tuple may be changed independent of other tuple in
the relation and other relations.
Types of Normal forms:
First Normal Form:
A relation is said to be in 1NF if every field contains
only atomic values, i.e, elimination the repeated groups.

Second Normal Form:

The partial functional dependencies have to be removed. (Elimination of the
redundant data).
Third normal form:
The transitive dependencies have to be removed (eliminate the columns not
dependencies are removed)
Boyce-Codd normal form:
The remaining anomalies that result from functional dependencies are removed.
Fourth normal form: multi valued dependencies are removed that is isolation of
independent multiple relationships.
Normal forms with examples:

3.6 FIRST NORMAL FORM

First normal form is a relation in which the intersection of each row and
column contains one and only one value. To transform the unnormalized table to fist
normal form, we identify and remove the repeating groups within the table. A
repeating group is a set of columns that store similar information that repeats in the
same table.
Example:
 Create table Contacts (
Contact_ID integer
L_name varchar(10)
F_name varchar(10)
Contact_date1 date
Contact_desc 1 varchar(50));

The above data structure contains a repeating group of the date and description
of two conversations.
To eliminate the repeating group is moved to another table (i.e using the
decomposition concept), which is then related to the parent table. The primary key of
the parent table (contact_id) is stored in the second table. Moving the repeating group
in to another table allows any number of conversations to be recorded and searched
easily.
Example:
1. Create table Contacts(
Contact_id integer (6) notnull
L_name Varchar(20) Notnull // relation (First part)
F_name varchar(20));

2. Create table Conversation(

Contact_id integer(6) notnull // relation (Second part)
Contact_date Date
Contact_desc Varchar(50)

3.7 SECOND NORMAL FORM

A relation scheme is in 2NF if it is in 1NF and if all nonprime attributes are

fully functionally dependent on the relation keys(i.e primary key)
The Second normal form conditions are,
o The primary key consists of only one attribute.
 o No non-key attributes exist in the relation. In other wards, all the attributes in
the relation are components of the primary key.
o Every non-key attribute is functionally dependent on the full set of primary key
attributes.
Example:
CREATE TABLE EMPLOYEE
(EMPNO INTEGER
NAME CHAR(20)
FNAME CHAR(20)
DEPTCODE INTEGER
DESCRIPTION CHAR(30))

To eliminate the data redundancy decompose the table like below

CREATE TABLE EMPLOYEE
(EMPNO INTEGER
NAME `CHAR(20)
FNAME CHAR(20)
DEPTCODE INTEGER)

CREATE TABLE DEPARTMENT

(DEPT-CODE INTEGER
DESCRIPTION CHAR(30))

3.8 THIRD NORMAL FORM:

A relation scheme is in 3NF if it is in 2NF form no transitive dependencies exit.

A transitive dependency in a relation is a functional dependency between two or more
non-key attributes. Take the following example,
 CREATE TABLE CONTACT
(CONT-ID INTEGER
NAME CHAR(20)
FNAME CHAR(20)
COM-NAME CHAR(20)
COM-LOCATION CHAR(20))

There is a transitive dependency - COM-LOCATION is dependent on COM-

NAME and COM-NAME is functional dependent on CONT-ID.
This transitive dependency can be removed by composing the above table into
two as shown below.
CREATE TABLE CONTACT
(CONT-ID INTEGER
NAME CHAR(20)
FNAME CHAR(20)
COM-NAME CHAR(20)
COMPANY-ID INTEGER)

CREATE TABLE COMPANY

(COMPANY-ID INTEGER
COM-NAME CHAR(20)
COM-LOCATION CHAR(20))

3.9 BOYCE-CODD NORMAL FORM

Boyce-codd normal Form (BCNF) is based on function dependencies that take

into account all candidate key in a relation. For a relation (table) with only one
candidate key, third normal form and BCNF are equivalent.
 Assume that a relation has more than one possible key. Further, the composite
keys have a common attribute. If an attribute of a composite key is dependent on an
attribute of the other composite key, a normalization called BCNF is needed. Consider
the relation of Professor.
Professor (Pcode, Dept., HOD, Part time)
1) A professor can work in more than one department;
2) The percentage of the time he spends in each department is given;
3) Each department has only one HOD;
The following table given the relation attributes; 2 possible composite keys are
pcode and department and HOD are not non-key attributes. They are a part of a
composite key.

code Department HOD % Time

P1 Phy SN 50
P1 Maths MR 50
P2 Che NM 25
P2 Phy SN 75
P3 Maths MR 100

The above table is in 3NF. Here the department and HOD are duplicated.
Further, if professor P2 resigns, 3rd and 4th row will be deleted.
The normalization of the relation is done by creating a new relation for department and
HOD of deleting HOD from professor relation, as shown below:
 Pcode Dept. %time
P1 Phy 50
P1 Maths 50
P2 Che 25
P2 Phy 75
P3 Maths 100
Dept. HOD
Phy SN
Maths MR
Che NM

Multivalued Dependencies
Let R be a relation schema and let X and Y be the subset of attributes of R.
Intuitively, the multivalued dependency X   Y is said to hold over R if, in every
legal instance r of R, each X values and this set is independent of the values in the other
attribute.
i.e, if t1 ε r, t2 ε r, and t1.X = t2.X, then there must be some t3 ε r such that t1.XY = t3.XY
and t2.Z = t3.Z
X Y Z
A B1 C1
A B2 C2
A B1 C2
A B2 C1
The rules on MVDs are,
 MVD Complementation: if X  Y, then X R – XY
 MVD Augmentation: if X Y and W  Z, then WX  YZ.
 MVD Transitivity: if X  Y and Y Z, then X  (Z-Y)
  Replication: if X  Y, then X Y
 Coalescence: if X  Y and there is a W such that W ∩ Y is empty, W  Z, and
Y  Z, then XZ.
Join Dependencies
A join dependency |X| {R1, R2, …, Rn} is said to hold over a relation R if
R1,R2,..,Rn is a lossless-join decomposition of R. An MVD X Y over a relation R can
be expressed as the join dependency |X| {XY, X(R-Y)}

3.10 FOURTH AND FIFTH NORMAL FORM

When attributes in a relation have multivalued dependency, further

normalization to 4NF and 5NF are required,. Consider the following example. A vendor
supplying many items to many projects in an organization. Assumptions made are
 A vendor is capable of supplying many items
 A project uses many items.
 A vendor supplies to many projects.
 An item may be supplied by many vendors.
It is shown in the following table:

Vcode Item code Project No

V1 I1 P1
V1 I2 P1
V1 I1 P3
V1 I2 P3
V2 I2 P1
V2 I3 P1
V3 I1 P2
V3 I1 P2

The relation given in the above table is in 3NF and also in BCNF. This relation is
reduced by expressing this relation as 2 relations in fourth normal form (4NF), which
has no more than one independent multivalued dependency or one dependent
multivalued dependency with a functional dependency.
Because, this can be expressed as the 4NF as below; ie., the fact that vendors are
capable of supplying certain items and that they are assigned to supply for some
projects in independently specified in the 4NF relation.
Vendor Supply Vendor Project
Vcode Item Code Vendor Code Project code

V1 I1 V1 P1

V1 I2 V1 P3

V2 I2 V2 P1

V2 I3 V3 P1

V3 I1 V3 P2
 Project No Item code
P1 I1
P1 I2
P2 I1
P3 I1
P3 I3

3.11 DENORMALIZATION:
De-normalization is the opposite of normalization. It is a process of increasing
redundancy in the database either for convenience or to improve performance.
DATABASE SECURITY:
The data stored in the database need protection from unauthorized action and
malicious destruction or alteration, in addition to the protection against accidental
introduction of inconsistency that integrity constraint provides.

3.12 DATABASE SECURITY REUIRMENT

 Confidentiality
 Privacy of Communications
 Secure Storage of Sensitive Data
 Authenticated user
 Granular Access Control
 Integrity
 Availability
(a)Security violations:
Among the form of malicious access are
o Unauthorized reading of data
 o Unauthorized modification of data
o Unauthorized destruction of data
Database security refers to protection from malicious access.
To protect the database, we must take security measure at several levels. They are
o Database system
o Network
o Physical
o Human
(b) Authorization:
We may assign user several forms authorization on parts of the database
For example,
 Read authorization
 Insert authorization
 Update authorization
 Delete authorization
In addition to the forms of authorization for access to data, we may grant a user
authorization to modify the database schema:
 Index authorization
 Resource authorization
 Alteration authorization
 Drop authorization
(c)Authorization and views:
Creation of view does not require resource authorization a user who creates a
view does not necessarily receive all privilege on that view. He/she receive only those
privileges that provide no additional authorization society and those that she already
had.
(d)Granting of privileges:
 A user who has been granted some form of authorization may be allowed to
pass on this authorization to other users.
  The passing of authorization from one user to another can be represented by an
authorization graph. The nodes of this graph are the users. The graph includes
an edge Ui -> Uj: if user Ui grants update authorization on to Uj.
 A user has an authorization if and only if there is a path from the root of the
authorization graph down to the node representing the user.
(e) Notion of roles:
A set of rules is created in the database, authorization can be granted to rules, in
exactly the same fashion as they we granted to individual users. Each database user is
granted to a set of rules that he or she is authorization to perform.
(f) Audit trails:
A audit trail is a lot of all changes to the database, along with information such as
which was performed the change and when the change was performed. By this, it aids
security.

3.13 PROTECTING THE DATA WITH IN THE DATABASE

(a) Privilege in SQL:

 The SQL standard includes the privileges delete, insert, select and update.
 The select privilege corresponds to the read privilege.
 The SQL DDL includes commands to grant and revoke privilege. The grant
statement is used to authorization.
 The privilege all privilege can be used as a short form for all the allowable
privilege.
(b) Roles:
The privilege of a user or a role consist of
 All privilege directly granted to the user/role.
 All privilege granted to roles that have been granted to the user/role.
3.14 THE PRIVILEGE TO GRANT PRIVILEGES

 If we wish to grant a privilege and to allow the recipient to pan the privilege on
to other users we append the with grant option, clause to the appropriate grant
command.
 For ex, if we wish to allow the select privilege on branch and allow U1 to grant
this privilege to others, grant select on branch to U1 with grant option.
 To revoke an authorization, we use the revoke statement
Revoke<privilege list> on <relation name or view name> from <user/role
list>[restrict/cascade]

 Create of an object (relation/view/role) set all privileges on the object,

including the privilege to grant privilege to other.
(d) Limitations of SQL authorization:
The problems are
 The code for checking authorization becomes intermixed with the rest of the
application code.
 Implementing authorization through application code, rather than specifying it
declaratively in SQL, makes it hand to ensure the absence of loop holes.
DATA ENCRYPTION
In order to provide more protection, the data may be stored n encrypted form. It
is not possible for encrypted data to be read unless the reader knows how to decipher
(decrypt).
(a)Encryption techniques:
A good encryption has the following properties:
 It is relatively simple for authorized user to encrypt and decrypt data.
  It depends not on the secrecy of the algorithm, but rather than on a parameter
of the algorithm called the encryption key.
 Its encryption key is extensively difficult for an intruder to determine.
 In 1977, the data encryption standards(DES) was issued, does the both a
substitution of character and rearrangement by their order on the basis of
encryption key.
 In order to provide stranger security level advanced encryption standard(AES)
was introduced by V. Rijmen and J. Darmon called RIJNOAEL ALGORITHM in
2000.
 Public key encryption is an alternative scheme that avoids some of the
problems faced with DES. It is based on 2 Keys. A public key and private key.
(b) Authentication:
 It refers to the task of verifying the identity of a person/software, connection to
a database, the simplest form of authentication consists of a secret password
which must be presented when a connection is opened to a database.
 A move secure scheme involves a challenge, response system.
 Another application of public key encryption is in digital signatures of varying
authenticity of a data
 Furthermore digital signatures who serve to ensure non reputation.