UNIT - I

DBMS Concept Introduction:

DEFINITION :- "A database management system is a collection of interrelated data and a set of programs to access those
data. Collection of data is referred to as a database."
Primary goal of dbms is to provide a way to store and retrieve database information that is both convenient and efficient.
Dbms allows us to define structure for storage of information and also provides mechanism to manipulate this information.
Dbms also provides safety for the information stored despite system crashes or attempts of authorized access.
DATA ABSTRACTION :-
Major purpose of dbms is to provide users with abstract view of data i.e. the system hides certain details of how the data are
stored and maintained. Since database system users are not computer trained, developers hide the complexity from users
through levels of abstraction, to simplify user!s interaction with the system.
"# Physical level of data abstraction $
%his s the lowest level of abstraction which describes how data are actually stored.
&# 'ogical level of data abstraction $
%his level hides what data are actually stored in the database and what relationship exists among them.
# (iew 'evel of data abstraction $
(iew provides security mechanism to prevent user from accessing certain parts of database.
SCHEMAS :-
". %he internal level has an internal schema, which describes the physical storage structure of the database. %he internal
schema uses a physical data model and describes the complete details of data storage and access paths for the database.
&. %he conceptual level has a conceptual schema, which describes the structure of the whole database for a community of
users. %he conceptual schema hides the details of physical storage structures and concentrates on describing entities, data
types, relationships, user operations, and constraints. ) high*level data model or an implementation data model can be used at
this level.
. %he external or view level includes a number of external schemas or user views. +ach external schema describes the part
of the database that a particular user group is interested in and hides the rest of the database from that user group. ) high*level
data model or an implementation data model can be used at this level.
T!"ES OF DATABASE #SERS :-
"# ,aive users$
%hese are the unsophisticated users who interact with the system by invo-ing one of the application programs that have been
written previously.
+.g. consider a user who chec-s for account balance information over the .orld .ide .eb.
&# )pplication programmers$
%hese are computer professionals who write application programs, used to develop user interfaces. %he application
programmer uses /apid )pplication Development 0/)D# tool-it or special type of programming languages which include
special features to facilitate generation of forms and display of date on screen.
# Sophisticated users$
%hese users interact with the database using database 1uery language. %hey submit their 1uery to the 1uery processor. %hen
Data Manipulation 'anguage 0DM'# functions are performed on the database to retrieve the data. %ools used by these users
are 2')P02nline )nalytical Processing# and data mining tools.
3# Specialized users$
%hese users write specialized database applications to retrieve data. %hese applications can be used to retrieve data with
complex data types e.g. graphics data and audio data.
ENTIT! RE$ATIONSHI" MODE$ :-
%& Entit' :
4 %he basic object that the +/ model represents is an entity, which is a 5thing5 in the real world with a independent existence.
4 )n entity may be an object with a physical existence6a particular person, car, house, or employee6or it may be an object
with a conceptual existence6a company, a job, or a university course.
(& ATTRIB#TE :
4 +ach entity has attributes6the particular properties that describe it.
4 7or example, an employee entity may be described by the employee!s name, age, address, salary, and job.
4 ) particular entity will have a value for each of its attributes.
4 %he attribute values that describe each entity become a major part of the data stored in the database.
4 Several types of attributes occur in the +/ model$ simple versus composite8 single*valued versus multi*valued8 and stored
versus derived.
)& *E! :
4 )n important constraint on the entities of an entity type is the -ey or uni1ueness constraint on attributes.
4 ) -ey is an attribute 0also -nown as column or field# or a combination of attribute that is used to identify records.
4 Sometimes we might have to retrieve data from more than one table, in those cases we re1uire to join tables with the help of
-eys.
4 %he purpose of the -ey is to bind data together across tables without repeating all of the data in every table
4 Such an attribute is called a -ey attribute, and its values can be used to identify each entity uni1uely.
4 7or example, the ,ame attribute is a -ey of the 92MP),: entity type because no two companies are allowed to have the
same name.
4 7or the P+/S2, entity type, a typical -ey attribute is SocialSecurity,umber.
4 Sometimes, several attributes together form a -ey, meaning that the combination of the attribute values must be distinct for
each entity.
4 ;f a set of attributes possesses this property, we can define a composite attribute that becomes a -ey attribute of the entity
type.
T'pe+ O, *e'+:-
i- Super *e':.
)n attribute or a combination of attribute that is used to identify the records uni1uely is -nown as Super <ey. ) table can have
many Super <eys.
ii- Can/i/ate *e' :.
;t can be defined as minimal Super <ey or irreducible Super <ey. ;n other words an attribute or a combination of attribute that
identifies the record uni1uely but none of its proper subsets can identify the records uni1uely.
iii- "ri0ar' *e' :.
) 9andidate <ey that is used by the database designer for uni1ue identification of each row in a table is -nown as Primary
<ey. ) Primary <ey can consist of one or more attributes of a table.
iv- Forei1n *e' :.
) foreign -ey is an attribute or combination of attribute in one base table that points to the candidate -ey 0generally it is the
primary -ey# of another table. %he purpose of the foreign -ey is to ensure referential integrity of the data i.e. only values that
are supposed to appear in the database are permitted.
v- Co0po+ite *e' : .
;f we use multiple attributes to create a Primary <ey then that Primary <ey is called 9omposite <ey 0also called a 9ompound
<ey or 9oncatenated <ey#.
vi- Alternate *e' :.
)lternate <ey can be any of the 9andidate <eys except for the Primary <ey.
vii- Secon/ar' *e' :.
%he attributes that are not even the Super <ey but can be still used for identification of records 0not uni1ue# are -nown as
Secondary <ey.
3. )n +*/ diagram can express the overall logical structure of a database graphically. +*/ diagrams are simple and clear6
1ualities that may well account in large part for the widespread use of the +*/ model. Such a diagram consists of the
following major components$
4 /ectangles, which represent entity sets
4 +llipses, which represent attributes
4 Diamonds, which represent relationship sets
4 'ines, which lin- attributes to entity sets and entity sets to relationship sets
4 Double ellipses, which represent multi valued attributes
4 Dashed ellipses, which denote derived attributes
4 Double lines, which indicate total participation of an entity in a relationship set
4 Double rectangles, which represent wea- entity sets
RE$ATIONA$ MODE$ :-
%he relational model represents the database as a collection of relations. ;nformally, each relation resembles a table of values
or, to some extent, a 5flat5 file of records. .hen a relation is thought of as a table of values, each row in the table represents a
collection of related data values. ;n the relational model, each row in the table represents a fact that typically corresponds to a
real world entity or relationship. %he table name and column names are used to help in interpreting the meaning of the values
in each row. ;n 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. %he data type describing the types of values that can appear in each column is called a domain.
%o preserve the consistency and correctness of its stored data, a relational D=MS typically imposes one or more data integrity
constraints. %hese constraints restrict the data values that can be inserted into the database or created by a database update.
Several different types of data integrity constraints are commonly found in relational databases, including $
4 /e1uired data $
Some columns in a database must contain a valid data value in every row8 they are not allowed to contain missing or ,>''
values. ;n the sample database, every order must have an associated customer who placed the order. %he D=MS can be as-ed
to prevent ,>'' values in this column.
4 (alidity chec-ing $
+very column in a database has a domain, a set of data values that are legal for that column. %he D=MS can be as-ed to
prevent other data values in these columns.
4 +ntity integrity $
%he primary -ey of a table must contain a uni1ue value in each row, which is different from the values in all other rows.
Duplicate values are illegal, because they wouldn?t allow the database to distinguish one entity from another. %he D=MS can
be as-ed to enforce this uni1ue values constraint.
4 /eferential integrity $
) foreign -ey in a relational database lin-s each row in the child table containing the foreign -ey to the row of the parent table
containing the matching primary -ey value. %he D=MS can be as-ed to enforce this foreign -ey@primary -ey constraint.
4 2ther data relationships $
%he real*world situation modeled by a database will often have additional constraints that govern the legal data values that
may appear in the database. %he D=MS can be as-ed to chec- modifications to the tables to ma-e sure that their values are
constrained in this way.
4 =usiness rules $
>pdates to a database may be constrained by business rules governing the real*world transactions that are
represented by the updates.
4 9onsistency $
Many real*world transactions cause multiple updates to a database. %he D=MS can be as-ed to enforce this
type of consistency rule or to support applications that implement such rules.
DATABASE $AN2#A2ES :-
Data definition language * defines data types and the relationships among them
Data manipulation language * performs tas-s such as inserting, updating, or deleting data occurrences
Auery language * allows searching for information and computing derived information
A/vanta1e+ o, DBMS :-
". /edundancy is controlled.
&. >nauthorized access is restricted.
. Providing multiple user interfaces.
3. +nforcing integrity constraints.
B. Providing bac-up and recovery.
Di+a/vanta1e+ o, File "roce++in1 S'+te0 :-
". Data redundancy and inconsistency.
&. Difficult in accessing data.
. Data isolation.
3. Data integrity.
B. 9oncurrent access is not possible.
C. Security Problems.
T3ree level+ o, /ata a4+traction :-
". Physical level$ %he lowest level of abstraction describes how data are stored.
&. 'ogical level$ %he next higher level of abstraction, describes what data are stored in database and what relationship
among those data.
. (iew level$ %he highest level of abstraction describes only part of entire database.
Inte1rit' Rule+ :-
%here are two ;ntegrity rules.
+ntity ;ntegrity $ States that 5Primary -ey cannot have ,>'' value5.
/eferential ;ntegrity $ States that 57oreign <ey can be either a ,>'' value or should be Primary <ey value of other
relation.
T3ree $evel Data4a+e Arc3itecture
Data an/ Relate/ Structure+
Data are actually stored as bits, or numbers and strings, but it is difcult to work with data at this level.
It is necessary to view data at diferent levels of abstraction.
Schema:
Description of data at some level. ach level has its own schema.
!e will be concerned with three forms of schemas:
physical,
conceptual, and
e"ternal.





"3'+ical Data $evel
%he p3'+ical +c3e0a describes details of how data is stored$ files, indices, etc. on the random access dis- system. ;t also typically describes the record
layout of files and type of files 0hash, b*tree, flat#.
+arly applications wor-ed at this level * explicitly dealt with details. +.g., minimizing physical distances between related data and organizing the data
structures within the file 0bloc-ed records, lin-ed lists of bloc-s, etc.#
Problem$
/outines are hardcoded to deal with physical representation.
9hanges to data structures are difficult to ma-e.
)pplication code becomes complex since it must deal with details.
/apid implementation of new features very difficult.
Conceptual Data $evel
)lso referred to as the 'ogical level
Dides details of the physical level.
;n the relational model, the conceptual schema presents data as a set of tables.
%he D=MS maps data access between the conceptual to physical schemas automatically.
Physical schema can be changed without changing application$
D=MS must change mapping from conceptual to physical.
/eferred to as p3'+ical /ata in/epen/ence.
External Data $evel
;n the relational model, the external +c3e0a also presents data as a set of relations. )n external schema specifies a view of the data in terms of the
conceptual level. ;t is tailored to the needs of a particular category of users. Portions of stored data should not be seen by some users and begins to
implement a level of security and simplifies the view for these users
+xamples$
Students should not see faculty salaries.
7aculty should not see billing or payment data.
;nformation that can be derived from stored data might be viewed as if it were stored.
EP) not stored, calculated when needed.
)pplications are written in terms of an external schema. %he external view is computed when accessed. ;t is not stored. Different external schemas can be
provided to different categories of users. %ranslation from external level to conceptual level is done automatically by D=MS at run time. %he conceptual
schema can be changed without changing application$
Mapping from external to conceptual must be changed.
/eferred to as conceptual /ata in/epen/ence.

Data Mo/el
Sc3e0a$ description of data at some level 0e.g., tables, attributes, constraints, domains#
Mo/el$ tools and languages for describing$
9onceptual@logical and external schema described by the data definition language 0DD'#
;ntegrity constraints, domains described by DD'
2perations on data described by the data manipulation language 0DM'#
Directives that influence the physical schema 0affects performance, not semantics# are described by the storage definition language 0SD'#
Data In/epen/ence
'ogical data independence
;mmunity of external models to changes in the logical model
2ccurs at user interface level
Physical data independence
;mmunity of logical model to changes in internal model
2ccurs at logical interface level
Entit'-Relation+3ip Mo/el
) semantic model, captures meanings
E-R 0o/elin1 i+ a conceptual level 0o/el
Proposed by P.P. 9hen in "FGHs
Entitie+ are real*world objects about which we collect data
Attri4ute+ describe the entities
Relation+3ip+ are associations among entities
Entit' +et I set of entities of the same type
Relation+3ip +et I set of relationships of same type
/elationships sets may have descriptive attributes
/epresented by +*/ diagrams

Relational Mo/el
/ecord* and table*based model
Relational /ata4a+e 0o/elin1 i+ a logical-level 0o/el
Proposed by +.7. 9odd
=ased on mathematical relations
>ses relations, represented as tables
9olumns of tables represent attributes
%ables represent relationships as well as entities
Successor to earlier record*based models6networ- and hierarchical

O45ect-oriente/ Mo/el
>ses the +*/ modeling as a basis but extended to include encap+ulation, in3eritance
2bjects have both state and behavior
State is defined by attributes
Be3avior is defined by methods 0functions or procedures#
Designer defines classes with attributes, methods, and relationships
9lass constructor method creates object instances
+ach object has a uni1ue object ;D
9lasses related by class hierarchies
Database objects have persistence
Bot3 conceptual-level an/ logical-level model
O45ect-relational 0o/el
#dds new comple" datatypes to relational model
#dds ob$ects with attributes and methods
#dds inheritance
S%& e"tended to handle ob$ects in S%&:'(((
Se0i-+tructure/ Mo/el
)ollection of nodes, each with data, and with diferent schemas
ach node contains a description of its own contents
)an be used for integrating e"isting databases
*+& tags added to documents to describe structure
*+& tags identify elements, sub,elements, attributes in documents
*+& D-D .Document -ype De/nition0 or *+& Schema used to de/ne structure
.Discussed later in the course in greater detail0
Relational Algebra :
/elational database systems are expected to be e1uipped by a 1uery language that can assist its user to 1uery the database instances. %his way its user
empowers itself and can populate the results as re1uired. %here are two -inds of 1uery languages, relational algebra and relational calculus.
Relational al1e4ra
/elational algebra is a procedural 1uery language, which ta-es instances of relations as input and yields instances of relations as output. ;t uses operators
to perform 1ueries. )n operator can be either unary or binary. %hey accept relations as their input and yields relations as their output. /elational algebra is
performed recursively on a relation and intermediate results are also considered relations.
7undamental operations of /elational algebra$
Select
Project
>nion
Set different
9artesian product
/ename
%hese are defined briefly as follows$
Select Operation 67-
Selects tuples that satisfy the given predicate from a relation.
,otation J
p
0r#
.here p stands for selection predicate and r stands for relation. p is prepositional logic formulae which may use connectors li-e and, or and not. %hese
terms may use relational operators li-e$ K, L, M, N , O, P.
7or example$

subject="database"
(Books)
2utput $ Selects tuples from boo-s where subject is ?database?.

subject="database" and price="450"

(Books)
2utput $ Selects tuples from boo-s where subject is ?database? and ?price? is 3BH.

subject="database" and price < "450" or year > "2010"

(Books)
2utput $ Selects tuples from boo-s where subject is ?database? and ?price? is 3BH or the publication year is greater than &H"H, that is published after &H"H.
"ro5ect Operation 68-
Projects column0s# that satisfy given predicate.
,otation$ Q
)", )&, )n 0r#
.here a", a& , an are attribute names of relation r.
Duplicate rows are automatically eliminated, as relation is a set.
for example$

subject aut!or
(Books)
Selects and projects columns named as subject and author from relation =oo-s.
#nion Operation 6-
>nion operation performs binary union between two given relations and is defined as$
r 1 s = " t # t 2 r or t 2 s$
,otion$ r > s
.here r and s are either database relations or relation result set 0temporary relation#.
7or a union operation to be valid, the following conditions must hold$
r, s must have same number of attributes.
)ttribute domains must be compatible.
Duplicate tuples are automatically eliminated.

aut!or
(Books) 1
aut!or
(%rtic&es)
2utput $ Projects the name of author who has either written a boo- or an article or both.
Set Di,,erence 6 9 -
%he result of set difference operation is tuples which present in one relation but are not in the second relation.
,otation$ r R s
7inds all tuples that are present in r but not s.

aut!or
(Books) '
aut!or
(%rtic&es)
2utput$ /esults the name of authors who has written boo-s but not articles.
Carte+ian "ro/uct 6:-
9ombines information of two different relations into one.
,otation$ r S s
.here r and s are relations and there output will be defined as$
r S s K T 1 t U 1 2 r and t 2 sV

aut!or = (tutoria&spoint(
(Books ) %rtic&es)
2utput $ yields a relation as result which shows all boo-s and articles written by tutorialspoint.
Rena0e operation 6 ; -
/esults of relational algebra are also relations but without any name. %he rename operation allows us to rename the output relation. rename operation is
denoted with small gree- letter rho
,otation$ x 0+#
.here the result of expression + is saved with name of x.
)dditional operations are$
Set intersection
)ssignment
,atural join
Relational Calculu+
;n contrast with /elational )lgebra, /elational 9alculus is non*procedural 1uery language, that is, it tells what to do but never explains the way, how to do
it.
/elational calculus exists in two forms$
Tuple relational calculu+ 6TRC-
7iltering variable ranges over tuples
,otation$ T % U 9ondition V
/eturns all tuples % that satisfies condition.
7or +xample$
" *+na,e # %ut!or(*) %-. *+artic&e = (database( $
2utput$ returns tuples with ?name? from )uthor who has written article on ?database?.
%/9 can be 1uantified also. .e can use +xistential 0 3 #and >niversal Auantifiers 0 4 #.
7or example$
" /# 3* 2 %ut!ors(*+artic&e=(database( %-. /+na,e=*+na,e)$
2utput $ the 1uery will yield the same result as the previous one.
Do0ain relational calculu+ 6DRC-
;n D/9 the filtering variable uses domain of attributes instead of entire tuple values 0as done in %/9, mentioned above#.
,otation$
T a", a&, a, ..., an U P 0a", a&, a, ... ,an#V
where a", a& are attributes and P stands for formulae built by inner attributes.
7or example$
"< artic&e pa0e subject > # 2 *utoria&s1oint 5 subject = (database($
2utput$ :ields )rticle, Page and Subject from relation %utorialsPoint where Subject is database.
Wust li-e %/9, D/9 also can be written using existential and universal 1uantifiers. D/9 also involves relational operators.
+xpression power of %uple relation calculus and Domain relation calculus is e1uivalent to /elational )lgebra.
Normalization and Normal orm!:
Nor0ali<ation is one of the favorite topics of interviewee. ;t does not matter whether you have mentioned D=MS in your
resume or not .%his 1uestion is going to come and the funny part is that all of us -now
what is normalizationX
.hat are the different types of normalizationX
So when this 1uestion on being as-ed the interviewer who have already prepared for it start with the history of normalization
and end with the geography of normalization but when the next 1uestion for which they have not prepared i.e. apply
normalization in real case scenario.
,ow here comes the real part of normalization and just because of not proper concepts, people end up confusing themselves.
So the idea is to not only to get familiar with normalization but also how to apply it in real time scenario.
=3at i+ Nor0ali<ation>
Database designed based on +/ model may have some amount of inconsistency, ambiguity and redundancy. %o resolve these
issues some amount of refinement is re1uired. %his refinement process is called as Nor0ali<ation. ; -now all of you are clear
with the definition, let!s go with $
what is the need of normalizationX
.hat are the problems we can face if we proceed without normalizationX
.hat are the advantages of normalizationX
)s-ing 1uestion to oneself is the best way to get familiar with all the concepts.
T3e nee/ o, Nor0ali<ation
; am going to show you one simple +*/ model database.
Student Details 9ourse Details /esult details
"HH" /am ""@HF@"FYC M3 =asic Maths G ""@""@&HH3 YF )
"HH& Shyam "&@HY@"FYG M3 =asic Maths G ""@""@&HH3 GY =
"HH" /am &@HC@"FYG DC 3 ""@""@&HH3 YG )
"HH Sita "C@HG@"FYB 9 =asic 9hemistry "" ""@""@&HH3 FH )
"HH3 Eita &3@HF@"FYY = Y ""@""@&HH3 GY =
"HH& Shyam &@HC@"FYY P =asic Physics " ""@""@&HH3 CG 9
"HHB Sunita "3@HF@"FYG P =asic Physics " ""@""@&HH3 GY =
"HH Sita &@"H@"FYG =3 B ""@""@&HH3 CG 9
"HHB Sunita "@H@"FFH DC 3 ""@""@&HH3 BC D
"HH3 Eita &"@HY@"FYG M3 =asic Maths G ""@""@&HH3 GY =

;n first loo- the above table is loo-ing so arranged and well in format but if we try to find out what exactly this table is saying
to us , we can easily figure out the various anomalies in this table . 2- let me help you guys in finding out the same.
". In+ert Ano0al'$ .e cannot insert prospective course which does not have any registered student or we cannot insert
student details that is yet to register for any course.
&. #p/ate Ano0al'$ if we want to update the course M3!s name we need to do this operation three times. Similarly we
may have to update student "HH!s name twice if it changes.
. Delete Ano0al'$ if we want to delete a course M3 , in addition to M3 occurs details , other critical details of student
also will be deleted. %his -ind of deletion is harmful to business. Moreover, M3 appears thrice in above table and
needs to be deleted thrice.
3. Duplicate Data: 9ourse M3!s data is stored thrice and student "HH&!s data stored twice .%his redundancy will
increase as the number of course offerings increases.
"roce++ o, nor0ali<ation:
=efore getting to -now the normalization techni1ues in detail, let us define a few building bloc-s which are used to define
normal form.
". Deter0inant $ )ttribute Z can be defined as determinant if it uni1uely defines the value : in a given relationship or
entity .%o 1ualify as determinant attribute need ,2% be a -ey attribute .>sually dependency of attribute is represented
as Z*O: ,which means attribute Z decides attribute :.
+xample$ ;n /+S>'% relation, Mar-s attribute may decide the grade attribute .%his is represented as Mar-s*Ograde and read
as Mar-s decides Erade.
Mar-s *O Erade
;n the result relation, Mar-s attribute is not a -ey attribute .Dence it can be concluded that -ey attributes are determinants but
not all the determinants are -ey attributes.

&. Functional Depen/enc'$ :es functional dependency has definition but let!s not care about that. 'et!s try to
understand the concept by example. 9onsider the following relation $
/+P2/%0Student[,9ourse[,9ourse,ame,;,ame,/oom[,Mar-s,Erade#
.here$
Student[*Student ,umber
9ourse[*9ourse ,umber
9ourse,ame *9ourse,ame
;,ame* ,ame of the instructor who delivered the course
/oom[*/oom number which is assigned to respective instructor
Mar-s* Scored in 9ourse 9ourse[ by student Student [
Erade I2btained by student Student[ in course 9ourse [
Student[,9ourse[ together 0called composite attribute# defines +Z)9%': 2,+ value of mar-s .%his can be
symbolically represented as
Student[9ourse[ Mar-s
%his type of dependency is called ,unctional /epen/enc'. ;n above example Mar-s is functionally dependent on
Student[9ourse[.
2ther 7unctional dependencies in above examples are$
9ourse[ *O 9ourse,ame
9ourse[*O ;,ame0)ssuming one course is taught by one and only one instructor #
;,ame *O /oom[ 0)ssuming each instructor has his @her own and non shared room#
Mar-s *OErade
7ormally we can define functional dependency as$ ;n a given relation /, Z and : are attributes. )ttribute : is functional
dependent on attribute Z if each value of Z determines exactly one value of :. %his is represented as $
Z*O:
Dowever Z may be composite in nature.

. Full ,unctional /epen/enc': ;n above example Mar-s is fully functional dependent on student#Course# and not on
the sub set of Student#Course# .%his means mar-s cannot be determined either by student [ or 9ourse[ alone .;t can
be determined by using Student[ and 9ourse[ together. Dence Mar-s is fully functional dependent on
student[course[.
9ourse,ame is not fully functionally dependent on student[course[ because one of the subset course[ determines the course
name and Student[ does not having role in deciding 9ourse name .Dence 9ourse,ame is not fully functional dependent on
student [9ourse[.

Student[
Mar-s
9ourse[
7ormal Definition of full functional dependency $ ;n a given relation / ,Z and : are attributes. : is fully functionally
dependent on attribute Z only if it is not functionally dependent on sub*set of Z.Dowever Z may be composite in nature.

3. "artial Depen/enc'$ ;n the above relationship 9ourse,ame,;,ame,/oom[ are partially dependent on composite
attribute Student[9ourse[ because 9ourse[ alone can defines the coursename, ;,ame,/oom[.
/oom[
;,ame
9ourse,ame
9ourse[
Student[
7ormal Definition of Partial dependency$ ;n a given relation /, Z and : are attributes .)ttribute : is partially dependent on
the attribute Z only if it is dependent on subset attribute Z .Dowever Z may be composite in nature.

B. Tran+itive Depen/enc'$ ;n above example , /oom[ depends on ;,ame and in turn depends on 9ourse[ .Dere
/oom[ transitively depends on 9ourse[.
;,ame
/oom[
9ourse[
Similarly Erade depends on Mar-s,in turn Mar-s depends on Student[9ourse[ hence Erade
7ully transitively depends on Student[9ourse[.

C. *e' attri4ute+ : ;n a given relationship / ,if the attribute Z uni1uely defines all other attributes ,then the attribute Z
is a -ey attribute which is nothing but the candidate -ey.
+x$ Student[9ourse[ together is a composite -ey attribute which determines all attributes in relationship
/+P2/%0student[,9ourse[,9ourse,ame,;,ame,/oom[,Mar-s,Erade#uni1uely.Dence Student[ and 9ourse[ are -ey
attributes.

T'pe+ o, Nor0al For0+
%& Fir+t Nor0al For06%NF-
) relation / is said to be in first normal form 0",7# if and only if all the attributes of the relation / are atomic in nature
Student Details 9ourse Details /esult details
"HH" /am ""@HF@"FYC M3 =asic Maths G ""@""@&HH3 YF )
"HH& Shyam "&@HY@"FYG M3 =asic Maths G ""@""@&HH3 GY =
"HH" /am &@HC@"FYG DC 3 ""@""@&HH3 YG )
"HH Sita "C@HG@"FYB 9 =asic 9hemistry "" ""@""@&HH3 FH )
"HH3 Eita &3@HF@"FYY = Y ""@""@&HH3 GY =
"HH& Shyam &@HC@"FYY P =asic Physics " ""@""@&HH3 CG 9
"HHB Sunita "3@HF@"FYG P =asic Physics " ""@""@&HH3 GY =
"HH Sita &@"H@"FYG =3 B ""@""@&HH3 CG 9
"HHB Sunita "@H@"FFH DC 3 ""@""@&HH3 BC D
"HH3 Eita &"@HY@"FYG M3 =asic Maths G ""@""@&HH3 GY =

%able shown above Student Details ,9ourse Details and /esult Details can be further divided. Student Details attribute is
divided into Student[0Student ,umber# , Student ,ame and date of birth. 9ourse Details is divided into 9ourse[ ,9ourse
,ame,Prere1uisites and duration. Similarly /esults attribute is divided into Date2fexam,Mar-s and Erade.

(& Secon/ Nor0al For0 6(NF-
) relation is said to be in Second ,ormal 7orm if and only ;f $
;t is in the first normal form ,and
,o partial dependency exists between non*-ey attributes and -ey attributes.

'et us re*visit ",7 table structure.
Student[ is -ey attribute for Student ,
9ourse[ is -ey attribute for 9ourse
Student[9ourse[ together form the composite -ey attributes for result relationship.
2ther attributes are non*-ey attributes.
%o ma-e this table &,7 compliant, we have to remove all the partial dependencies.
Student,ame and Date2f=irth depends only on student[.
9ourse,ame,Pre/e1uisite and Duration;nDays depends only on 9ourse[
Date2f+xam depends only on 9ourse[.
%o remove this partial dependency we need to split Student\9ourse\/esult table into four separate tables ,S%>D+,%
,92>/S+,/+S>'% and +Z)M\D)%+ tables as shown in figure.
S%>D+,% %)='+
Student [ Student ,ame Dateof=irth
"HH" /am Some value
"HH& Shyam Some value
"HH Sita Some value
"HH3 Eeeta Some value
"HHB Sunita Some value

92>/S+ %)='+
9ourse[ 9ourse,ame Duration of days
9 =io 9hemistry
= =otany Y
P ,uclear Physics "
M3 )pplied Mathematics 3
DC )merican Distory B
=3 ]oology F
/+S>'% %)='+
Student[ 9ourse[ Mar-s Erade
"HH" M3 YF )
"HH& M3 GY =
"HH" DC YG )
"HH 9 FH )
"HH3 = GY =
"HH& P CG 9
"HHB P GY =
"HH =3 CG 9
"HHB DC BC D
"HH3 M3 GY =

+Z)M D)%+ %able
9ourse[ Date2f+xam
M3 Some value
DC Some value
9 Some value
= Some value
P Some value
=3 Some value

;n the first table 0S%>D+,%# ,the -ey attribute is Student[ and all other non*-ey attributes, Student,ame and
Date2f=irth are fully functionally dependant on the -ey attribute.
;n the Second %able 092>/S+# , 9ourse[ is the -ey attribute and all the non*-ey attributes, 9ourse,ame,
Duration;nDays are fully functional dependant on the -ey attribute.
;n third table 0/+S>'%# Student[9ourse[ together are -ey attributes and all other non -ey attributes, Mar-s and
Erade are fully functional dependant on the -ey attributes.
;n the fourth %able 0+Z)M D)%+# 9ourse[ is the -ey attribute and the non -ey attribute ,Date2f+xam is fully
functionally dependant on the -ey attribute.
)t first loo- it appears li-e all our anomalies are ta-en away ^ ,ow we are storing Student "HH and M3 record only once. .e
can insert prospective students and courses at our will. .e will update only once if we need to change any data in
S%>D+,%,92>/S+ tables. .e can get rid of any course or student details by deleting just one row.
'et us analyze the /+S>'% %able
Student[ 9ourse[ Mar-s Erade
"HH" M3 YF )
"HH& M3 GY =
"HH" DC YG )
"HH 9 FH )
"HH3 = GY =
"HH& P CG 9
"HHB P GY =
"HH =3 CG 9
"HHB DC BC D
"HH3 M3 GY =

.e already concluded that $
)ll attributes are atomic in nature
,o partial dependency exists between the -ey attributes and non*-ey attributes
/+S>'% table is in &,7

)ssume, at present, as per the university evaluation policy,
Students who score more than or e1ual to YH mar-s are awarded with _)` grade
Students who score more than or e1ual to GH mar-s up till GF are awarded with _=` grade
Students who score more than or e1ual to CH mar-s up till CF are awarded with _9` grade
Students who score more than or e1ual to BH mar-s up till BF are awarded with _D` grade

%he >niversity management which is committed to improve the 1uality of education, wants to change the existing grading
system to a new grading system .;n the present /+S>'% table structure ,
.e don!t have an option to introduce new grades li-e )a ,=* and +
.e need to do multiple updates on the existing record to bring them to new grading definition
.e will not be able to ta-e away _D` grade if we want to.
&,7 does not ta-e care of all the anomalies and inconsistencies.
. T3ir/ Nor0al For0 6)NF- ) relation / is said to be in ,7 if and only if
;t is in &,7
,o transitive dependency exists between non*-ey attributes and -ey attributes.
;n the above /+S>'% table Student[ and 9ourse[ are the -ey attributes. )ll other attributes, except grade are non*partially ,
non I transitively dependant on -ey attributes. %he grade attribute is dependant on _Mar-s _ and in turn _Mar-s` is dependent
on Student[9ourse[. %o bring the table in ,7 we need to ta-e off this transitive dependency.

Student[ 9ourse[ Mar-s
"HH" M3 YF
"HH& M3 GY
"HH" DC YG
"HH 9 FH
"HH3 = GY
"HH& P CG
"HHB P GY
"HH =3 CG
"HHB DC BC
"HH3 M3 GY

>pper=ound 'ower=ound Erade
"HH FB )a
F3 FH )
YF YB =a
Y3 YH =
GF GB =*
G3 GH 9
CF CB 9*

)fter ,ormalizing tables to ,7 , we got rid of all the anomalies and inconsistencies. ,ow we can add new grade systems, update the
existing one and delete the unwanted ones.
Dence the %hird ,ormal form is the most optimal normal form and FFb of the databases which re1uire efficiency in
;,S+/%
>PD)%+
D+'+%+
2perations are designed in this normal form.