Database

Management
Systems

1
 What Is a DBMS?

• A Database Management System (DBMS)

is a collection of inter related data and a set of
programs to access and manage the data
efficiently .

2
 Keys

• Super Key -> A super key is set of one or more

attribute which taken collectively, allows us to
identify uniquely an entity in the entity set.

Example: Customer (Social_securityno ,

Cust_name, Street , City )
 Social_securityno is a Super Key
 Combination of {Social_securityno ,
Cust_name } is also a super key

 Super key may contain extraneous attributes.

3
• Candidate key :-> super key whose proper
subset is not a super key. Such minimal super
keys are called candidate keys.

Example: In customer relation combination

of { Cust_name, street } is sufficient to
distinguish among members of the customer
entity set.
Candidate keys are 1.
{ Social_security no }
2.
{Cust_name , Street }
4
• Primary Key : -> Key which uniquely determine the entity
in entity set. The minimum candidate key is called primary
key. We use term primary key to denote a candidate key that
is chosen by the database designer.
Example: Customer (Social_securityno ,
Cust_name, Street , City )
» Social_securityno is a Primary Key
• Alternate Key : -> One candidate key of a relation would
be selected as a primary key and the remaining candidate
key would be considered as alternate key.
Example: Customer (Social_securityno ,
Cust_name, Street , City )
» {Cust_name , Street} is a Alternate Key

5
• Foreign Key : -> A foreign key is an attribute that
appears in one table but is the primary key in other
table.
Example: Emp{emp_no, e_name, dept_no, sal }
Dept{dept_no,d_name,loc }
 dept_no is a Primary Key in Dept table
 dept_no is a Foreign Key in Emp table

• Composite Key : -> A composite key is candidate key

with two or more attributes.
Example: Customer (Social_securityno ,
Cust_name, Street , City )
 {Cust_name , Street} is a composite key.

6
 Normalization
• Normalization is a database design technique. It is a

process in which a step by step approach is taken to

achieve the database design, which is not having

any anomalies.
Anomalies
• The problem that we face in relational database
design are known as anomalies.

1. Duplication of data or repetition of data

2. Insertion anomalies
3. Deletion anomalies

7
Example: Student Activity table
SID Activity Fee

100 SKING 200

150 SWIMMING 50
175 SQUASH 50
200 SWIMMING 50

•Deletion anomalies : -> If we delete the tuple for

student 100, we will lose not only the fact that student 100 opted
SKING but also the fact that SKING fee is 200.

•Insertion anomalies:-> If we want to enter the fact fee of

SCUBA is 175. We cannot enter this data into the relation until a
student enrolls in a SCUBA .

8
 First normal Form : -> A table is in the first normal form
when ever intersection of a row & column contains 1 value. In other
words no attribute value represent a set of values.

Example: LIBRARY
M_code M_nam M_addre M_type M_fees B_code B_name Author I_date R_date
e ss

Anomalies:->
1. Every members details are repeated the number of times equal to the
number of books taken by that member.
2. A book cannot be added within file until any member is issued that book.
3. While modifying the details about a particular member, it is required to
modified the details for all the record of that member.
4. While deleting details about a particular member, details about the
books taken by that member also get deleted.
9
 Second normal Form:-> A table is in second normal
form if non key attributes are fully dependent on the whole key.

Step to go in 2NF
1. Find out functional dependency and try to achieve full functional
dependency.
2. Create separate tables for each fully functionally dependent set.

1. BOOK B_code B_name Author

( Primary key )

2.Transaction M_code B_code I_date R_date

( Primary key )

3.Member M_code M_name M_addres M_type M_fees

s
( Primary key)

Anomalies -> Redundancy is not completely removed as

membership_fees attribute is repeated for every member record. 10
Third Normal Form : -. A relation is in 3NF when it
is full fill the condition of 2NF and there is no transitive
dependencies.
Steps : ->
1.Search for transitive dependency
2.Map the transitive dependency into separate tables

Example:-
Member M_code M_name M_address M_type
( Primary key )

Member ship
M_type M_fees
( Primary key )

11
 Boyce-Codd Normal Form :
Consider the relation ADVISOR
SID MAJOR FNAME
100 MATH CAUCHY
100 PHYSICS JUNG
150 PHYSICS JUNG
200 MATH CAUCHY
300 PHYSICS PERL

•FNAME is the unique name of a faculty person.

•Faculty member can advise in only one MAJOR.
•There may be several advisor in each MAJOR.
*Functional dependency FNAME → MAJOR exist

1. Deletion anomaly -> suppose student 300 drops out. If we delete student
300 tuple we lose the fact that PERL advise PHYSICS this is deletion
anomalies.
2. If we want to store the fact that KEYNES advises in ENGLISH ? we can’t
insert until a student major is ENGLISH . this is an insertion anomaly.

12
To remove this we use BCNF- A relation is in BCNF if every
determinant is Candidate key.
If relation is in BCNF then there is no anomalies regarding functional
dependence.

STU_ADV ADV_SUB

SID FNAME FNAME MAJOR

100 CAUCHY
CAUCHY MATH
100 JUNG
150 JUNG JUNG PHYSICS

200 CAUCHY
PERL PHYSICS
200 PERL

13
 Functional Dependencies
Functional Dependencies (FD) generalizes the concept of a
key. It can also be thought of as a constraint between two
sets of attributes. In other words, FD is a constraint that is to
be satisfied by every desirable relation instance. It is a
constraint on the behavior of attributes in a schema.
Functional Dependencies are constraint on the set of legal
relations.

14
Let r be a relations schema and let X and Y be non-empty sets of
attributes in r. We say that for a relation instance R of the schema r has
a Functional Dependency X  Y if the following conditions holds for
every pairs of tuples t1 and t2 in R.

If t1 [X] = t2 [X] then t1 [Y] = t2 [Y]

By considering X Y, we say that X functionally determines Y, or Y is
functionally dependent on X.

To illustrate the concept of FD, let us consider the example. Let –

X = {Managerid, Manager Name} and Y = {ManagerAge}

Tuple t1 and t2 having same Managerid value and same Manager

Name, we must have same ManagerAge. Else the data is inconsistent.
Thus we can say that –
{Managerid, ManagerName}  {ManagerAge}

15
 Inference Rules for FDs

• The following are the inference rules to generate new FDs from a
given set of FDs. For the rules described below, we assume X, Y and Z
are the subset of attributes in the schema r.

1. Reflexive Rule
If X ⊇ Y, then X  Y
2. Augmentation
If X  Y then XZ  YZ
3. Transitive Rule
If X  Y and Y  Z, then X  Z
4. Decomposition
If X  YZ then X  Y, and X  Z
5. Union
If X  Y and X  Z, then X  YZ

16
Thanks

17