Unit 2 DBMS

CS8492 – Database Management
Systems – UNIT II
MS.S.DHIVYA,
AP/CSE,
KNCET

UNIT II DATABASE DESIGN
Entity-Relationship model – E-R Diagrams –
Enhanced-ER Model – ER-to-Relational apping –
Functional Dependencies – Non-loss Decomposition –
First, Second, Third Normal Forms, Dependency
Preservation – Boyce/Codd Normal Form – Multi-
valued Dependencies and Fourth Normal Form – Join
Dependencies and Fifth Normal Form

Entity-Relationship model
a model for identifying entities to be
represented in the database and representation
of how those entities are related.

 Design Phases - Requirement Analysis:
 to understand what data need to be stored in the
database, what applications must be built, what are
all those operations that are frequently used by the
system.
 requires proper communication with user groups.

 Design Phases – Conceptual database design:
 E-R Model is built.
 a high level model used in database design.
 to create a simple description of data that matches
with the requirements of users.

 Design Phases – Logical database design:
 ER model is converted to relational database
schema.
Design Phases – Schema refinement:
 to identify the potential problems and to refine it.
 normalizing and restructuring the relations.

 Design Phases – Physical database design:
 building indexes on tables and clustering tables,
redesigning some parts of schema obtained from
earlier design steps.

 Design Phases – Application and Security
Design:
 UML – design of the database can be accomplished.
 the role of each entity in every process must be
reflected in the application task.
 some access rules must be enforced on the application
to protect the security features.

 provides a means for representing
relationships between entities.
 It is an aid for database design.
It is easy to visualize and understand.

ER Model - Concepts
 Entity Sets:
 Entity: a “thing” or “object” in the real world that is
distinguishable from all other objects.
 Example: a particular person, car, house, etc.
 An entity has set of properties, and the values for some set
of properties may uniquely identify an entity.
 An entity set is a collection of entities having the same
properties

ER Model - Concepts
Attributes:
 The properties that describe an entity are called
attributes.
 In the customer entity customer id, name, street
are the attributes

ER Model - Concepts
Attributes – Types:
 Simple attribute:
 An attribute that cannot be divided into further
subparts (atomic).
 Example: Customer-id of customer entity

ER Model - Concepts
 Composite attribute:
 An attribute that can be divided into a set of
subparts. Employee
Address
Name
Salary
Number Street City

ER Model - Concepts
 Single value attribute:
 An attribute having only one value in a particular
entity.

ER Model - Concepts
 Multi-valued attribute:
 An attribute having more than one value for a
particular entity. Employee
Address
Name
Degrees
Number Street City

ER Model - Concepts
Derived attribute:
 An attribute that is derived from other related
attributes or entities. Employee
Address
Birthdate
Age
Number Street City

ER Model - Concepts
 Relationship set:
 an association among several entities.
 a set of relationships of the same type.

ER Model
 Mapping Cardinality:
 the number of entities to which another entity can
be associated via a relationship set.
 For a binary relationship set R between entity sets
A and B

ER Model
 Mapping Cardinality - One-to-one (1 : 1)
 An entity in A is associated with at most one entity in B,
and an entity in B is associated with at most one entity in
A.
 One-to-many (1 : M)
 An entity in A is associated with any number of entities in
B. An entity in B can be associated with at most one entity
in A.

ER Model
 Mapping Cardinality - Many-to-Many (M : N)
 An entity in A is associated with any number of entities in
B, and an entity in B is associated with any number of
entities in A.
 Many to one (M : 1)
An entity in A is associated with at most one entity in B. An
entity in B can be associated with any number of entities in
A.

ER Model
 Ternary relation:
 If a relationship connects three connects three
entities.
 Entities: Product, Supplier and customer
 Relationship: buy

ER Model
Weak Entity Set:
 Entity types that do not have key attributes of their
own are called weak entity types.
 Strong Entity Set:
 Entity types that have key attributes of their own
are called strong entity types

Components of ER Diagram
Component Description Symbol
Entity Rectangle
Relationship Diamond
Attributes for
any Entity Ellipse
Key Attribute
for any Entity
the attribute
name inside
the Ellipse is
underlined.

Components of ER Diagram
Derived
Attribute for
any Entity
dotted
ellipse is
created
inside the
main ellipse
Multivalued
Attribute for
any Entity
Double
Ellipse

ER Diagram - Entity
Component Example Symbol
Entity
Employee,
Manager,
Department
Weak Entity
depends on
another
entity

ER Diagram - Attribute
Attribute
(Name, Age,
Address)
property or
characteristic
of an entity
Key Attribute
main
characterstic
of an Entity
Composite
Attribute
have their
own
attributes

ER Diagram - Relationship
One to One
Relationship
one student can enroll
only for one course
and a course will also
have only one Student
One to Many
Relationship
1 student can opt for
many courses
Many to One
Relationship
Student enrolls for
only one Course but a
Course can have
many Students

ER Diagram - Relationship
Many to Many
Relationship
one student can enroll
for more than one
courses. And a course
can have more than 1
student enrolled in it

Enhanced ER Model
Specialization and Generalization -
 The process of making subclass from a general concept –
specialization.(top – down process)
 The process of making superclass from subclass –
Generalization. (bottom up process)
 Superclass: An entity type that represents a general concept at a
high level
 Subclass: An entity type that represents a specific concept at a
low levels

Enhanced ER Model
 Constraints on Specialization and Generalization
 Several specializations can be defined on an entity
type.
 Entities may belong to subclasses in each of the
specializations.

Enhanced ER Model
 Constraints on Specialization and Generalization:
 Types of Specializations - Condition-defined
specialization:
 determine exactly the entities of each sub class by placing a
condition of the value of an attribute in the super class.

ER to Relational Mapping
Mapping of Entity Set to Relationship:
 Each attribute of entity set becomes an attribute of
the table.
 The primary key attribute of entity set becomes an
entity of the table.
 ER Diagram into Relation Model

Mapping of Entity Set to Relationship:
 create table employee (Empid char(11),Ename
char(30),salary int,primary key(Empid))

 Mapping Relationship sets(without constraints) to
tables:
 Create a table for the relationship set.
 Add all primary keys of the participating entity sets as
fields of the table.
 Add a field for each attribute of the relationship
 Declare a primary key using all key fields from the entity
sets.

Mapping Relationship sets(without
constraints) to tables:
 Employee works for department.
 where empid and deptid are primary key

Mapping Relationship sets(without constraints)
to tables:
Create table works_In(Empid char(10), Deptid char(10),
ename char(10), salary int,Deptname char(20), primary
key(empid,deptid), foreign key(empid) references
Employee, foreign key(deptid) references department)

 Mapping Relationship sets(with constraints) to tables:
 Employee manages departments:
 relation with Manages- Approach 1
 Create table manages(Empid char(10), Deptid char(10),since
date, primary key(deptid), foreign key(empid) references
Employee, foreign key(deptid) references department)

Mapping Relationship sets(with constraints) to
tables:
 Employee manages departments:
 relation with Manages- Approach 2
 Create table dep_mgr(Deptid int, Dname char(20),
budget REAL, empid int,since date, primary key(deptid),
foreign key(empid) references Employee)

Mapping weak entity sets to relational
mapping;
 create table Department(Deptid int, Deptname
char(20), Roomno int, primary key
(deptid,roomno), foreign key(roomno)
references roomno)

Concept of Relational Database Design
 to generate a set of relation schema that allows us to
store information without unnecessary redundancy
 to allows us to retrieve information easily.
 For checking the normal form of the schema, it is
necessary to check the functional dependencies and
other data dependencies that exists within the schema.

FUNCTIONAL DEPENDENCY
 It requires that the value for a certain set of attributes
determines uniquely the value for another set of attributes.
 In a given relation R, X and Y are attributes. Attributes Y is
functionally dependent on attribute X if each value of X
determines exactly one value of Y, which is represented as
X  Y
X  Y does not imply Y  X
Marks  Grade, Reg.No  Name

 Armstrong’s Axioms:
 Reflection: if X ⸧ Y, then X  Y
 Augmentation: if X  Y, then XZ  YZ, for any Z
 Transitivity: if X  Y and Y  Z, then X  Z
 Decomposition: If X  YZ, then X  Y and X  Z
 Union: If X  Y and X  Z, then X  YZ
 Pseudotransitivity: If X  Y and WY  Z, then WX  Z

Closure Dependencies:
 F – Functional Dependencies
 F+ - Closure Functional Dependencies
 X – Attributes of F
 X+ - Attributes of F +
 F covers G, if G+ ⸦ F+
 F and G are equivalent if F+ = G+

Minimal Cover – a set of F of FD is a set of G
of FD such that:
 Every dependencies in G is of the form X -> A,
where a is a single attribute.
 The closure F+ is equal to the closure G+.

 Types:
 Full functional dependency
 Partial functional dependency
 Transitive functional dependency

 Types - Full functional dependency
 In a relation R, X and Y are attributes. X functionally determines
Y. Subset of X should not functionally determine Y.
 Marks cannot be determined either by student_no or course_no
alone. It can be determined only using student_no and course_no
together.
 Marks is fully functionally dependent on {student_no,
course_no}
 RegisterNo. -> Name

 Types - Partial functional dependency
 Attribute Y is partially dependent on the attribute X only if
it is dependent on a subset of attribute X.
For example course_name, Instructor_name are partially
dependent on composite attributes {student_no, course_no}
because course_no alone defines course_name,
Instructor_name.
 (RegisterNo., Gender) -> Name

 Types - Transitive Dependencies functional
dependency
 X, Y and Z are 3 attributes in the relation R.
X -> Y, Y -> Z, X -> Z
 For example, grade depends on marks and in turn make
depends on {student_no course_no}, hence Grade depends
fully transitively on {student_no & course_no}.

 Types - Transitive Dependencies functional
dependency
 X, Y and Z are 3 attributes in the relation R.
X -> Y, Y -> Z, X -> Z
 RegisterNo. -> Deptid
 Deptid -> HoD
RegisterNo. -> HoD

 Uses:
 Test relations to see if they are legal under a
given set of functional dependencies.
 Specify constraints on the set of legal relations
 A specific instance of a relation schema must satisfy a
functional dependency even if the functional dependency
does not hold on all legal instances.

Concept of redundancy and anomalies
 Redundancy is a condition created in database in which same piece of data
is held at two different places.
Problems:
 Redundant storage – some information is stored repeatedly.
 Update Anomalies – if one copy of repeated data is updated the
inconsistency is created unless all other copies are similarly updated.
 Insertion Anomalies - Due to insertion of new record repeated information
get added to the relation schema.
 Deletion Anomalies – Deletion of a record may leads to delete the
information associated with that record.

Decomposition
 The process of breaking up or dividing a single
relation into two or more sub relations is called as
decomposition of a relation.

Loss –less Join Decomposition:
• when the join of the sub relations results in the same
relation R that was decomposed.

Lossy Join Decomposition:
• when the join of the sub relations does not result in
the same relation R that was decomposed.
• Lossy join decomposition is also known as careless
decomposition.

NORMALIZATION
 A process of organizing the data in database
to avoid data redundancy
Forms:
First normal form(1NF)
Second normal form(2NF)
Third normal form(3NF)
Boyce & Codd normal form (BCNF)

NORMALIZATION
 First normal form(1NF) :
An attribute (column) of a table cannot hold multiple
values. It should hold only atomic values.
emp_id emp_name emp_address emp_mobile
101 Herschel New Delhi 8912312390
102 Jon Kanpur
8812121212
9900012222
103 Ron Chennai 7778881212
104 Lester Bangalore
9990000123
8123450987

NORMALIZATION
 First normal form(1NF) :
 Each attribute of a table must have atomic (single)
values.
emp_id emp_name emp_address emp_mobile
101 Herschel New Delhi 8912312390
102 Jon Kanpur 8812121212
102 Jon Kanpur 9900012222
103 Ron Chennai 7778881212
104 Lester Bangalore 9990000123
104 Lester Bangalore 8123450987

NORMALIZATION
 Prime Attribute:
 Member of some candidate Key.
 Example: RegisterNo.
 Non-prime Attribute:
 not a member of any candidate key

NORMALIZATION
 Second normal form(1NF) : A table is said to
be in 2NF if both the following conditions hold:
Table is in 1NF (First normal form)
All the non-key columns are dependent on the table’s
primary key.

NORMALIZATION – 2NF

Candidate Keys: {teacher_id, subject}
Non prime attribute: teacher_age
teacher_id subject teacher_age
111 Maths 38
222 Physics 38
333 Biology 38
444 Physics 40
555 Chemistry 40

NORMALIZATION – 2NF

The table is in first normal form and all the columns depend on the
table’s primary key
teacher_id subject teacher_age
111 Maths 38
222 Physics 38
333 Biology 38
444 Physics 40
555 Chemistry 40
teacher_id teacher_age
111 38
222 38
333 38
444 40
555 40
teacher_id subject
111 Maths
222 Physics
333 Biology
444 Physics
555 Chemistry

NORMALIZATION
Third normal form 3NF:
A table design is said to be in 3NF if both the
following conditions hold:
Table must be in 2NF
Transitive functional dependency of non-prime attribute
on any super key should be removed.
OR
Every non prime attribute
 fully FD on every key, and
 non transitively FD on every key

NORMALIZATION
sid sname zipcode cityname state
1 AAA 111111 Chennai Tamilnadu
2 BBB 222222 Pune Maharastra
3 CCC 333333 Jaipur Rajasthan
4 DDD 444444 Trichy Tamilnadu
5 EEE 555555 Mumbai Maharastra
sid -> sname
sid-> zipcode
zipcode->cityname
cityname->state

NORMALIZATION
– After 3NF
– The table divided as the below
Student zip
sid sname zipcode
1 AAA 111111
2 BBB 222222
3 CCC 333333
4 DDD 444444
5 EEE 555555
zipcode cityname state
111111 Chennai Tamilnadu
222222 Pune Maharastra
333333 Jaipur Rajasthan
444444 Trichy Tamilnadu
555555 Mumbai Maharastra

NORMALIZATION
 Boyce Codd Normal Form
it is in 3NF and for every functional dependency
X->Y, X should be the super key of the table.
(sid,course)->teacher
teacher->course
sid course teacher
1 C Aruna
2 Java Kani
3 C Aruna
4 C++ Anjana
5 C Vani

sid teacher
1 Aruna
2 Kani
3 Aruna
4 Anjana
5 Vani
teacher course
Aruna C
Kani Java
Aruna C
Anjana C++
Vani C

Multivalued Dependencies
 Conditions:
 A -> B, if for a single value of A, multiple values of B
exists, then table may have multi-values dependency.
 a table have at-least 3 columns for it to have a multi-valued
dependency.
 For a relation R(A,B,C), if there is a multi-valued
dependency between, A and B, then B and C should
independent of each other.

 Example:
Sid ->> Course
Sid ->> Skill
Sid Course Skill
1
C
C++
English
German
2 Java
English
French

 Example:
Sid Course Skill
1 C English
1 C++ German
1 C German
1 C++ English
2 Java English
2 Java French

Fourth Normal Form
 Conditions:
 It should be in the Boyce-Codd normal Form.
 the table should not have any multi-valued
dependency.

Fourth Normal Form
 Student Table:
Sid Course Skill
1 C English
1 C++ German
1 C German
1 C++ English
2 Java English
2 Java French

Fourth Normal Form
 Student_Course Table:
 Student_Skill Table:
Sid Course
1 C
1 C++
2 Java
Sid Skill
1 English
1 German
2 English
2 French

Join Dependencies
 If the join of R1 and R2 over C is equal to relation R,
then we can say that a Join Dependency(JD) exists.
 where R1 and R2 are the decompositions R1(A,B,C)
and R2(C,D) of a given relations R(A,B,C,D).
 R1 and R2 are a lossless decomposition of R.
 the *(A,B,C,D),(C,D) will be a JD of R if the join of
join’s attribute is equal to the relation R.

Fifth Normal Form
 It is in 4th Normal Form
 If we can decompose table further to eliminate
redundancy and anomalies and when we rejoin
the table we should not be losing the original data
or get a new record(Join Dependency Principle)
 also called as Project Join Normal Form(PJNF).

SUPPLIER-> CUSTOMER
PRODUCT-> CUSTOMER
SUPPLIER-> PRODUCT
SUPPLIER CUSTOMER PRODUCT
A 111 laptop
B 222 Pen-drive
B 333 memory card
B 444 CD
C 555 DVD
C 666 floppy

• DECOMPOSE THE TABLE INTO 3.

Unit 2 DBMS

Recommended

More Related Content

What's hot (20)

Similar to Unit 2 DBMS (20)

Recently uploaded (20)

Unit 2 DBMS