lOMoARcPSD|22191715

CB3401-UNIT 2 - UNIT WISE NOTES

Database Management System and Security (Anna University)

Scan to open on Studocu

Studocu is not sponsored or endorsed by any college or university

Downloaded by sneha sivalingam ([email protected])
 lOMoARcPSD|22191715

IV- SEM/II B.E. CSE (CS) Prepared By: R. Reshma/AP/CSE

CB3401: DATABASE MANAGEMENT SYSTEMS AND SECURITY

LECTURE NOTES
UNIT II DATABASE DESIGN 9
ER Diagrams – Functional Dependencies – Non-Loss Decomposition Functional Dependencies – First Normal Form –
Second Normal Form – Third Normal Form – Dependency Preservation – Boyce/Codd Normal Form – Multi-Valued
Dependencies and Fourth Normal Form – Join Dependencies and Fifth Normal Form

INTRODUCTION
Database Design can be defined as a set of procedures or collection of tasks involving various steps taken to implement a
database. Following are some critical points to keep in mind to achieve a good database design:
1. Data consistency and integrity must be maintained.
2. Low Redundancy
3. Faster searching through indices
4. Security measures should be taken by enforcing various integrity constraints.
5. Data should be stored in fragmented bits of information in the most atomic format possible.

The Design Process

The design process consists of the following steps:

• Determine the purpose of your database

This helps prepare you for the remaining steps.
• Find and organize the information required
Gather all of the types of information you might want to record in the database, such as product name and
order number.
• Divide the information into tables
Divide your information items into major entities or subjects, such as Products or Orders. Each subject then
becomes a table.
• Turn information items into columns
Decide what information you want to store in each table. Each item becomes a field and is displayed as a
column in the table. For example, an Employee table might include fields such as Last Name and Hire Date.
• Specify primary keys
Choose each table’s primary key. The primary key is a column that is used to uniquely identify each row.
An example might be Product ID or Order ID.
• Set up the table relationships
Look at each table and decide how the data in one table is related to the data in other tables. Add fields to
tables or create new tables to clarify the relationships, as necessary.
• Refine your design
Analyze your design for errors. Create the tables and add a few records of sample data. See if you can get
the results you want from your tables. Make adjustments to the design, as needed.
• Apply the normalization rules
Apply the data normalization rules to see if your tables are structured correctly. Make adjustments to the
tables, as needed.

Primary Terminologies Used in Database Design

Following are the terminologies that a person should be familiar with before designing a database:

Department of Computer Science and Engineering Dhanalakshmi Srinivasan College of Engineering

Downloaded by sneha sivalingam ([email protected])
 lOMoARcPSD|22191715

IV- SEM/II B.E. CSE (CS) Prepared By: R. Reshma/AP/CSE

• Redundancy: Redundancy refers to the duplicity of the data. There can be specific use cases when we need or don’t
need redundancy in our Database. For ex: If we have a banking system application then we may need to strictly
prevent redundancy in our Database.
• Schema: Schema is a logical container that defines the structure & manages the organization of the data stored in
it. It consists of rows and columns having data types for each column.
• Records/Tuples: A Record or a tuple is the same thing, basically its where our data is stored inside a table
• Indexing: Indexing is a data structure technique to promote efficient retrieval of the data stored in our database.
• Data Integrity & Consistency: Data integrity refers to the quality of the information stored in our database and
consistency refers to the correctness of the data stored.
• Data Models: Data models provide us with visual modeling techniques to visualize the data & the relationship that
exists among those data. Ex: model, Network Model, Object Oriented Model, Hierarchical model, etc.
• Functional Dependency: Functional Dependency is a relationship between two attributes of the table that
represents that the value of one attribute can be determined by another. Ex: {A -> B}, A & B are two attributes and
attribute A can uniquely determine the value of B.
• Transaction: Transaction is a single logical unit of work. It signifies that some changes are made in the database.
A transaction must satisfy the ACID or BASE properties (depending on the type of Database).
• Schedule: Schedule defines the sequence of transactions in which they’re executed by one or multiple users.
• Concurrency: Concurrency refers to allowing multiple transactions to operate simultaneously without interfering
with one another.

Database Design Lifecycle

The database design lifecycle goes something like this:

Lifecycle of Database Design

1. Requirement Analysis
It’s very crucial to understand the requirements of our application so that you can think in productive terms. And imply
appropriate integrity constraints to maintain the data integrity & consistency.

2. Logical & Physical Design

This is the actual design phase that involves various steps that are to be taken while designing a database. This phase is
further divided into two stages:
• Logical Data Model Design: This phase consists of coming up with a high-level design of our database based on
initially gathered requirements to structure & organize our data accordingly. A high-level overview on paper is made
of the database without considering the physical level design, this phase proceeds by identifying the kind of data to
be stored and what relationship will exist among those data.
Entity, Key attributes identification & what constraints are to be implemented is the core functionality of this phase.
It involves techniques such as Data Modeling to visualize data, normalization to prevent redundancy, etc.
• Physical Design of Data Model: This phase involves the implementation of the logical design made in the previous
stage. All the relationships among data and integrity constraints are implemented to maintain consistency & generate
the actual database.

Department of Computer Science and Engineering Dhanalakshmi Srinivasan College of Engineering

Downloaded by sneha sivalingam ([email protected])
 lOMoARcPSD|22191715

IV- SEM/II B.E. CSE (CS) Prepared By: R. Reshma/AP/CSE

3. Data Insertion and testing for various integrity Constraints

Finally, after implementing the physical design of the database, we’re ready to input the data & test our integrity. This phase
involves testing our database for its integrity to see if something got left out or, if anything new to add & then integrating it
with the desired application.

Logical Data Model Design

The logical data model design defines the structure of data and what relationship exists among those data. The following
are the major components of the logical design:

1. Data Models: Data modeling is a visual modeling technique used to get a high-level overview of our database. Data
models help us understand the needs and requirements of our database by defining the design of our database through
diagrammatic representation. Ex: model, Network model, Relational Model, object-oriented data model.

2. Entity: Entities are objects in the real world, which can have certain properties & these properties are referred to as
attributes of that particular entity.
There are 2 types of entities:
• Strong and weak entities:
o Weak entities do not have a key attribute to identify them, their existence solely depends on one 1-specific
strong entity & also has full participation in a relationship whereas strong entities do have a key attribute
to uniquely identify them.
Weak entity example: Loan -> Loan will be given to a customer (which is optional) & the load will be identified by the
customer_id to whom the lone is granted.

3. Relationships: How data is logically related to each other defines the relationship of that data with other entities. In
simple words, the association of one entity with another is defined here.
A relationship can be further categorized into – unary, binary, and ternary relationships.
• Unary: In this, the associating entity & the associated entity both are the same. Ex: Employee Manages themselves,
and students are also given the post of monitor hence here the student themselves is a monitor.
• Binary: This is a very common relationship that you will come across while designing a database.
Ex: Student is enrolled in courses, Employee is managed by different managers, One student can be taught by many
professors.
• Ternary: In this, we have 3 entities involved in a single relationship. Ex: an employee works on a project for a
client. Note that, here we have 3 entities: Employee, Project & Client.

4. Attributes: Attributes are nothing but properties of a specific entity that define its behavior. For example, an employee
can have unique_id, name, age, date of birth (DOB), salary, department, Manager, project id, etc.

5. Normalization: After all the entities are put in place and the relationship among data is defined, we need to look for
loopholes or possible ambiguities that may arise as a result of CRUD operations. To prevent various Anomalies such as
INSERTION, UPDATION, and DELETION Anomalies.
Data Normalization is a basic procedure defined for databases to eliminate such anomalies & prevent redundancy.

Department of Computer Science and Engineering Dhanalakshmi Srinivasan College of Engineering

Downloaded by sneha sivalingam ([email protected])
 lOMoARcPSD|22191715

IV- SEM/II B.E. CSE (CS) Prepared By: R. Reshma/AP/CSE

An Example of Logical Design

Physical Design
The main purpose of the physical design is to actually implement the logical design that is, show the structure of the
database along with all the columns & their data types, rows, relations, relationships among data & clearly define how
relations are related to each other.

Following are the steps taken in physical design

Step 1: Entities are converted into tables or relations that consist of their properties (attributes)
Step 2: Apply integrity constraints: establish foreign key, unique key, and composite key relationships among the data.
And apply various constraints.
Step 3: Entity names are converted into table names, property names are translated into attribute names, and so on.
Step 4: Apply normalization & modify as per the requirements.
Step 5: Final Schemes are defined based on the entities & attributes derived in logical design.

ER Diagrams
An Entity Relationship (ER) Diagram is a type of flowchart that illustrates how “entities” such as people, objects or concepts
relate to each other within a system. ER Diagrams are most often used to design or debug relational databases in the fields
of software engineering, business information systems, education and research. Also known as ERDs or ER Models, they
use a defined set of symbols such as rectangles, diamonds, ovals and connecting lines to depict the interconnectedness of
entities, relationships and their attributes. They mirror grammatical structure, with entities as nouns and relationships as

Department of Computer Science and Engineering Dhanalakshmi Srinivasan College of Engineering

Downloaded by sneha sivalingam ([email protected])
 lOMoARcPSD|22191715

IV- SEM/II B.E. CSE (CS) Prepared By: R. Reshma/AP/CSE

verbs. ER diagrams are related to data structure diagrams (DSDs), which focus on the relationships of elements within
entities instead of relationships between entities themselves. ER diagrams also are often used in conjunction with data flow
diagrams (DFDs), which map out the flow of information for processes or systems.

For example, Suppose we design a school database. In this database, the student will be an entity with attributes like
address, name, id, age, etc. The address can be another entity with attributes like city, street name, pin code, etc and there
will be a relationship between them.

Component of ER Diagram

1. Entity:

An entity may be any object, class, person or place. In the ER diagram, an entity can be represented as rectangles. Consider
an organization as an example- manager, product, employee, department etc. can be taken as an entity.

a. Weak Entity

An entity that depends on another entity called a weak entity. The weak entity doesn't contain any key attribute of its own.
The weak entity is represented by a double rectangle.

Department of Computer Science and Engineering Dhanalakshmi Srinivasan College of Engineering

Downloaded by sneha sivalingam ([email protected])
 lOMoARcPSD|22191715

IV- SEM/II B.E. CSE (CS) Prepared By: R. Reshma/AP/CSE

2. Attribute

The attribute is used to describe the property of an entity. Eclipse is used to represent an attribute. For example, id, age,
contact number, name, etc. can be attributes of a student.

a. Key Attribute

The key attribute is used to represent the main characteristics of an entity. It represents a primary key. The key attribute is
represented by an ellipse with the text underlined.

b. Composite Attribute

An attribute that composed of many other attributes is known as a composite attribute. The composite attribute is represented
by an ellipse, and those ellipses are connected with an ellipse.

c. Multivalued Attribute

An attribute can have more than one value. These attributes are known as a multivalued attribute. The double oval is used
to represent multivalued attribute.

Department of Computer Science and Engineering Dhanalakshmi Srinivasan College of Engineering

Downloaded by sneha sivalingam ([email protected])
 lOMoARcPSD|22191715

IV- SEM/II B.E. CSE (CS) Prepared By: R. Reshma/AP/CSE

For example, a student can have more than one phone number.

d. Derived Attribute

An attribute that can be derived from other attribute is known as a derived attribute. It can be represented by a dashed ellipse.

For example, A person's age changes over time and can be derived from another attribute like Date of birth.

3. Relationship

A relationship is used to describe the relation between entities. Diamond or rhombus is used to represent the relationship.

Types of relationship are as follows:

a. One-to-One Relationship

When only one instance of an entity is associated with the relationship, then it is known as one to one relationship. For
example, A female can marry to one male, and a male can marry to one female.

b. One-to-many relationship

When only one instance of the entity on the left, and more than one instance of an entity on the right associates with the
relationship then this is known as a one-to-many relationship.

For example, Scientist can invent many inventions, but the invention is done by the only specific scientist.

Department of Computer Science and Engineering Dhanalakshmi Srinivasan College of Engineering

Downloaded by sneha sivalingam ([email protected])
 lOMoARcPSD|22191715

IV- SEM/II B.E. CSE (CS) Prepared By: R. Reshma/AP/CSE

c. Many-to-one relationship

When more than one instance of the entity on the left, and only one instance of an entity on the right associates with the
relationship then it is known as a many-to-one relationship.

For example, a Student enrolls for only one course, but a course can have many students.

d. Many-to-many relationship

When more than one instance of the entity on the left, and more than one instance of an entity on the right associates with
the relationship then it is known as a many-to-many relationship.

For example, Employee can assign by many projects and project can have many employees.

Notation of ER diagram
Database can be represented using the notations. In ER diagram, many notations are used to express the cardinality. These
notations are as follows:

Functional Dependencies
The functional dependency is a relationship that exists between two attributes. It typically exists between the primary key
and non-key attribute within a table.
1. X → Y
The left side of FD is known as a determinant, the right side of the production is known as a dependent.

For example:

Department of Computer Science and Engineering Dhanalakshmi Srinivasan College of Engineering

Downloaded by sneha sivalingam ([email protected])
 lOMoARcPSD|22191715

IV- SEM/II B.E. CSE (CS) Prepared By: R. Reshma/AP/CSE

Assume we have an employee table with attributes: Emp_Id, Emp_Name, Emp_Address. Here Emp_Id attribute can
uniquely identify the Emp_Name attribute of employee table because if we know the Emp_Id, we can tell that employee
name associated with it.

Functional dependency can be written as:

1. Emp_Id → Emp_Name

We can say that Emp_Name is functionally dependent on Emp_Id.

Types of Functional dependency

1. Trivial functional dependency

o A → B has trivial functional dependency if B is a subset of A.
o The following dependencies are also trivial like: A → A, B → B
Example:
1. Consider a table with two columns Employee_Id and Employee_Name.
2. {Employee_id, Employee_Name} → Employee_Id is a trivial functional dependency as
3. Employee_Id is a subset of {Employee_Id, Employee_Name}.
4. Also, Employee_Id → Employee_Id and Employee_Name → Employee_Name are trivial dependencies too.

2. Non-trivial functional dependency

o A → B has a non-trivial functional dependency if B is not a subset of A.
o When A intersection B is NULL, then A → B is called as complete non-trivial.
Example:
1. ID → Name,
2. Name → DOB
Lossless Decomposition in DBMS
The original relation and relation reconstructed from joining decomposed relations must contain the same number of tuples
if the number is increased or decreased then it is Lossy Join decomposition.
Lossless join decomposition ensures that never get the situation where spurious tuples are generated in relation, for every
value on the join attributes there will be a unique tuple in one of the relations. Lossless join decomposition is a decomposition
of a relation R into relations R1, and R2 such that if we perform a natural join of relation R1 and R2, it will return the
original relation R. This is effective in removing redundancy from databases while preserving the original data. In other

Department of Computer Science and Engineering Dhanalakshmi Srinivasan College of Engineering

Downloaded by sneha sivalingam ([email protected])
 lOMoARcPSD|22191715

IV- SEM/II B.E. CSE (CS) Prepared By: R. Reshma/AP/CSE

words by lossless decomposition, it becomes feasible to reconstruct the relation R from decomposed tables R1 and R2 by
using Joins.

Only 1NF,2NF,3NF, and BCNF are valid for lossless join decomposition.

In Lossless Decomposition, we select the common attribute and the criteria for selecting a common attribute is that the
common attribute must be a candidate key or super key in either relation R1, R2, or both.
Decomposition of a relation R into R1 and R2 is a lossless-join decomposition if at least one of the following functional
dependencies is in F+ (Closure of functional dependencies)

Example of Lossless Decomposition

— Employee (Employee_Id, Ename, Salary, Department_Id, Dname)

Can be decomposed using lossless decomposition as,

— Employee_desc (Employee_Id, Ename, Salary, Department_Id)
— Department_desc (Department_Id, Dname)

Alternatively, the lossy decomposition would be as joining these tables is not possible so not possible to get back original
data.
– Employee_desc (Employee_Id, Ename, Salary)
– Department_desc (Department_Id, Dname)
R1 ∩ R2 → R1
OR
R1 ∩ R2 → R2

In a database management system (DBMS), a lossless decomposition is a process of decomposing a relation schema into
multiple relations in such a way that it preserves the information contained in the original relation. Specifically, a lossless
decomposition is one in which the original relation can be reconstructed by joining the decomposed relations.

To achieve lossless decomposition, a set of conditions known as Armstrong’s axioms can be used. These conditions ensure
that the decomposed relations will retain all the information present in the original relation. Specifically, the two most
important axioms for lossless decomposition are the reflexivity and the decomposition axiom.

The reflexivity axiom states that if a set of attributes is a subset of another set of attributes, then the larger set of attributes
can be inferred from the smaller set. The decomposition axiom states that if a relation R can be decomposed into two
relations R1 and R2, then the original relation R can be reconstructed by taking the natural join of R1 and R2.

There are several algorithms available for performing lossless decomposition in DBMS, such as the BCNF (Boyce-Codd
Normal Form) decomposition and the 3NF (Third Normal Form) decomposition. These algorithms use a set of rules to
decompose a relation into multiple relations while ensuring that the original relation can be reconstructed without any loss
of information.

Advantages of Lossless Decomposition

1. Reduced Data Redundancy: Lossless decomposition helps in reducing the data redundancy that exists in the original
relation. This helps in improving the efficiency of the database system by reducing storage requirements and
improving query performance.
2. Maintenance and Updates: Lossless decomposition makes it easier to maintain and update the database since it
allows for more granular control over the data.
3. Improved Data Integrity: Decomposing a relation into smaller relations can help to improve data integrity by
ensuring that each relation contains only data that is relevant to that relation. This can help to reduce data
inconsistencies and errors.
4. Improved Flexibility: Lossless decomposition can improve the flexibility of the database system by allowing for
easier modification of the schema.

Department of Computer Science and Engineering Dhanalakshmi Srinivasan College of Engineering

Downloaded by sneha sivalingam ([email protected])
 lOMoARcPSD|22191715

IV- SEM/II B.E. CSE (CS) Prepared By: R. Reshma/AP/CSE

Disadvantages of Lossless Decomposition

• Increased Complexity: Lossless decomposition can increase the complexity of the database system, making it harder
to understand and manage.
• Increased Processing Overhead: The process of decomposing a relation into smaller relations can result in increased
processing overhead. This can lead to slower query performance and reduced efficiency.
• Join Operations: Lossless decomposition may require additional join operations to retrieve data from the
decomposed relations. This can also result in slower query performance.
• Costly: Decomposing relations can be costly, especially if the database is large and complex. This can require
additional resources, such as hardware and personnel.

Normalization
A large database defined as a single relation may result in data duplication. This repetition of data may result in:
o Making relations very large.
o It isn't easy to maintain and update data as it would involve searching many records in relation.
o Wastage and poor utilization of disk space and resources.
o The likelihood of errors and inconsistencies increases.

So to handle these problems, we should analyze and decompose the relations with redundant data into smaller, simpler, and
well-structured relations that are satisfy desirable properties. Normalization is a process of decomposing the relations into
relations with fewer attributes.
What is Normalization?
o Normalization is the process of organizing the data in the database.
o Normalization is used to minimize the redundancy from a relation or set of relations. It is also used to eliminate
undesirable characteristics like Insertion, Update, and Deletion Anomalies.
o Normalization divides the larger table into smaller and links them using relationships.
o The normal form is used to reduce redundancy from the database table.

Why do we need Normalization?

The main reason for normalizing the relations is removing these anomalies. Failure to eliminate anomalies leads to data
redundancy and can cause data integrity and other problems as the database grows. Normalization consists of a series of
guidelines that helps to guide you in creating a good database structure.

Data modification anomalies can be categorized into three types:

o Insertion Anomaly: Insertion Anomaly refers to when one cannot insert a new tuple into a relationship due to lack
of data.
o Deletion Anomaly: The delete anomaly refers to the situation where the deletion of data results in the unintended
loss of some other important data.
o Updatation Anomaly: The update anomaly is when an update of a single data value requires multiple rows of data
to be updated.

Types of Normal Forms:

Normalization works through a series of stages called Normal forms. The normal forms apply to individual relations. The
relation is said to be in particular normal form if it satisfies constraints.

Department of Computer Science and Engineering Dhanalakshmi Srinivasan College of Engineering

Downloaded by sneha sivalingam ([email protected])
 lOMoARcPSD|22191715

IV- SEM/II B.E. CSE (CS) Prepared By: R. Reshma/AP/CSE

Following are the various types of Normal forms:

Normal Description
Form

1NF A relation is in 1NF if it contains an atomic value.

2NF A relation will be in 2NF if it is in 1NF and all non-key attributes are fully functional dependent
on the primary key.

3NF A relation will be in 3NF if it is in 2NF and no transition dependency exists.

BCNF A stronger definition of 3NF is known as Boyce Codd's normal form.

4NF A relation will be in 4NF if it is in Boyce Codd's normal form and has no multi-valued dependency.

5NF A relation is in 5NF. If it is in 4NF and does not contain any join dependency, joining should be
lossless.

Advantages of Normalization
o Normalization helps to minimize data redundancy.
o Greater overall database organization.
o Data consistency within the database.
o Much more flexible database design.
o Enforces the concept of relational integrity.
Disadvantages of Normalization
o You cannot start building the database before knowing what the user needs.
o The performance degrades when normalizing the relations to higher normal forms, i.e., 4NF, 5NF.
o It is very time-consuming and difficult to normalize relations of a higher degree.
o Careless decomposition may lead to a bad database design, leading to serious problems.

Department of Computer Science and Engineering Dhanalakshmi Srinivasan College of Engineering

Downloaded by sneha sivalingam ([email protected])
 lOMoARcPSD|22191715

IV- SEM/II B.E. CSE (CS) Prepared By: R. Reshma/AP/CSE

First Normal Form (1NF)

o A relation will be 1NF if it contains an atomic value.
o It states that an attribute of a table cannot hold multiple values. It must hold only single-valued attribute.
o First normal form disallows the multi-valued attribute, composite attribute, and their combinations.

Example: Relation EMPLOYEE is not in 1NF because of multi-valued attribute EMP_PHONE.

EMPLOYEE table:

EMP_ID EMP_NAME EMP_PHONE EMP_STATE

14 John 7272826385, UP
9064738238

20 Harry 8574783832 Bihar

12 Sam 7390372389, Punjab

8589830302

The decomposition of the EMPLOYEE table into 1NF has been shown below:

EMP_ID EMP_NAME EMP_PHONE EMP_STATE

14 John 7272826385 UP

14 John 9064738238 UP

20 Harry 8574783832 Bihar

12 Sam 7390372389 Punjab

12 Sam 8589830302 Punjab

Second Normal Form (2NF)

o In the 2NF, relational must be in 1NF.
o In the second normal form, all non-key attributes are fully functional dependent on the primary key

Example: Let's assume, a school can store the data of teachers and the subjects they teach. In a school, a teacher can teach
more than one subject.

TEACHER table

TEACHER_ID SUBJECT TEACHER_AGE

25 Chemistry 30

25 Biology 30

Department of Computer Science and Engineering Dhanalakshmi Srinivasan College of Engineering

Downloaded by sneha sivalingam ([email protected])
 lOMoARcPSD|22191715

IV- SEM/II B.E. CSE (CS) Prepared By: R. Reshma/AP/CSE

47 English 35

83 Math 38

83 Computer 38

In the given table, non-prime attribute TEACHER_AGE is dependent on TEACHER_ID which is a proper subset of a
candidate key. That's why it violates the rule for 2NF.

To convert the given table into 2NF, we decompose it into two tables:

TEACHER_DETAIL table:

TEACHER_ID TEACHER_AGE

25 30

47 35

83 38

TEACHER_SUBJECT table:

TEACHER_ID SUBJECT

25 Chemistry

25 Biology

47 English

83 Math

83 Computer

Third Normal Form (3NF)

o A relation will be in 3NF if it is in 2NF and not contain any transitive partial dependency.
o 3NF is used to reduce the data duplication. It is also used to achieve the data integrity.
o If there is no transitive dependency for non-prime attributes, then the relation must be in third normal form.

A relation is in third normal form if it holds atleast one of the following conditions for every non-trivial function dependency
X → Y.
1. X is a super key.
2. Y is a prime attribute, i.e., each element of Y is part of some candidate key.

Department of Computer Science and Engineering Dhanalakshmi Srinivasan College of Engineering

Downloaded by sneha sivalingam ([email protected])
 lOMoARcPSD|22191715

IV- SEM/II B.E. CSE (CS) Prepared By: R. Reshma/AP/CSE

Example:
EMPLOYEE_DETAIL table:

EMP_ID EMP_NAME EMP_ZIP EMP_STATE EMP_CITY

222 Harry 201010 UP Noida

333 Stephan 02228 US Boston

444 Lan 60007 US Chicago

555 Katharine 06389 UK Norwich

666 John 462007 MP Bhopal

Super key in the table above:
1. {EMP_ID}, {EMP_ID, EMP_NAME}, {EMP_ID, EMP_NAME, EMP_ZIP}....so on
Candidate key: {EMP_ID}

Non-prime attributes: In the given table, all attributes except EMP_ID are non-prime.

Here, EMP_STATE & EMP_CITY dependent on EMP_ZIP and EMP_ZIP dependent on EMP_ID. The non-prime
attributes (EMP_STATE, EMP_CITY) transitively dependent on super key(EMP_ID). It violates the rule of third normal
form.

That's why we need to move the EMP_CITY and EMP_STATE to the new <EMPLOYEE_ZIP> table, with EMP_ZIP as a
Primary key.
EMPLOYEE table:

EMP_ID EMP_NAME EMP_ZIP

222 Harry 201010

333 Stephan 02228

444 Lan 60007

555 Katharine 06389

666 John 462007

EMPLOYEE_ZIP table:

EMP_ZIP EMP_STATE EMP_CITY

201010 UP Noida

02228 US Boston

60007 US Chicago

06389 UK Norwich

Department of Computer Science and Engineering Dhanalakshmi Srinivasan College of Engineering

Downloaded by sneha sivalingam ([email protected])
 lOMoARcPSD|22191715

IV- SEM/II B.E. CSE (CS) Prepared By: R. Reshma/AP/CSE

462007 MP Bhopal

Boyce Codd normal form (BCNF)

o BCNF is the advance version of 3NF. It is stricter than 3NF.
o A table is in BCNF if every functional dependency X → Y, X is the super key of the table.
o For BCNF, the table should be in 3NF, and for every FD, LHS is super key.

Example: Let's assume there is a company where employees work in more than one department.
EMPLOYEE table:

EMP_ID EMP_COUNTRY EMP_DEPT DEPT_TYPE EMP_DEPT_NO

264 India Designing D394 283

264 India Testing D394 300

364 UK Stores D283 232

364 UK Developing D283 549

In the above table Functional dependencies are as follows:

1. EMP_ID → EMP_COUNTRY
2. EMP_DEPT → {DEPT_TYPE, EMP_DEPT_NO}

Candidate key: {EMP-ID, EMP-DEPT}

The table is not in BCNF because neither EMP_DEPT nor EMP_ID alone are keys.

To convert the given table into BCNF, we decompose it into three tables:
EMP_COUNTRY table:

EMP_ID EMP_COUNTRY

264 India

264 India

EMP_DEPT table:

EMP_DEPT DEPT_TYPE EMP_DEPT_NO

Designing D394 283

Testing D394 300

Stores D283 232

Developing D283 549

Department of Computer Science and Engineering Dhanalakshmi Srinivasan College of Engineering

Downloaded by sneha sivalingam ([email protected])
 lOMoARcPSD|22191715

IV- SEM/II B.E. CSE (CS) Prepared By: R. Reshma/AP/CSE

EMP_DEPT_MAPPING table:

EMP_ID EMP_DEPT

D394 283

D394 300

D283 232

D283 549
Functional dependencies:
1. EMP_ID → EMP_COUNTRY
2. EMP_DEPT → {DEPT_TYPE, EMP_DEPT_NO}

Candidate keys:
For the first table: EMP_ID
For the second table: EMP_DEPT
For the third table: {EMP_ID, EMP_DEPT}
Now, this is in BCNF because left side part of both the functional dependencies is a key.

Fourth normal form (4NF)

o A relation will be in 4NF if it is in Boyce Codd normal form and has no multi-valued dependency.
o For a dependency A → B, if for a single value of A, multiple values of B exists, then the relation will be a multi-
valued dependency.
Example
STUDENT

STU_ID COURSE HOBBY

21 Computer Dancing

21 Math Singing

34 Chemistry Dancing

74 Biology Cricket

59 Physics Hockey

The given STUDENT table is in 3NF, but the COURSE and HOBBY are two independent entity. Hence, there is no
relationship between COURSE and HOBBY.

In the STUDENT relation, a student with STU_ID, 21 contains two courses, Computer and Math and two
hobbies, Dancing and Singing. So there is a Multi-valued dependency on STU_ID, which leads to unnecessary repetition
of data.

So to make the above table into 4NF, we can decompose it into two tables:

Department of Computer Science and Engineering Dhanalakshmi Srinivasan College of Engineering

Downloaded by sneha sivalingam ([email protected])
 lOMoARcPSD|22191715

IV- SEM/II B.E. CSE (CS) Prepared By: R. Reshma/AP/CSE

STUDENT_COURSE

STU_ID COURSE

21 Computer

21 Math

34 Chemistry

74 Biology

59 Physics

STUDENT_HOBBY

STU_ID HOBBY

21 Dancing

21 Singing

34 Dancing

74 Cricket

59 Hockey

Fifth normal form (5NF)

o A relation is in 5NF if it is in 4NF and not contains any join dependency and joining should be lossless.
o 5NF is satisfied when all the tables are broken into as many tables as possible in order to avoid redundancy.
5NF is also known as Project-join normal form (PJ/NF).
o
Example

SUBJECT LECTURER SEMESTER

Computer Anshika Semester 1

Computer John Semester 1

Math John Semester 1

Math Akash Semester 2

Chemistry Praveen Semester 1

In the above table, John takes both Computer and Math class for Semester 1 but he doesn't take Math class for Semester 2.
In this case, combination of all these fields required to identify a valid data.

Department of Computer Science and Engineering Dhanalakshmi Srinivasan College of Engineering

Downloaded by sneha sivalingam ([email protected])
 lOMoARcPSD|22191715

IV- SEM/II B.E. CSE (CS) Prepared By: R. Reshma/AP/CSE

Suppose we add a new Semester as Semester 3 but do not know about the subject and who will be taking that subject so we
leave Lecturer and Subject as NULL. But all three columns together acts as a primary key, so we can't leave other two
columns blank.

So, to make the above table into 5NF, we can decompose it into three relations P1, P2 & P3:
P1

SEMESTER SUBJECT

Semester 1 Computer

Semester 1 Math

Semester 1 Chemistry

Semester 2 Math
P2

SUBJECT LECTURER

Computer Anshika

Computer John

Math John

Math Akash

Chemistry Praveen
P3

SEMSTER LECTURER

Semester 1 Anshika

Semester 1 John

Semester 1 John

Semester 2 Akash

Semester 1 Praveen

Relational Decomposition
o When a relation in the relational model is not in appropriate normal form then the decomposition of a relation is
required.
o In a database, it breaks the table into multiple tables.

Department of Computer Science and Engineering Dhanalakshmi Srinivasan College of Engineering

Downloaded by sneha sivalingam ([email protected])
 lOMoARcPSD|22191715

IV- SEM/II B.E. CSE (CS) Prepared By: R. Reshma/AP/CSE

o If the relation has no proper decomposition, then it may lead to problems like loss of information.
o Decomposition is used to eliminate some of the problems of bad design like anomalies, inconsistencies, and
redundancy.

Types of Decomposition

Lossless Decomposition
o If the information is not lost from the relation that is decomposed, then the decomposition will be lossless.
o The lossless decomposition guarantees that the join of relations will result in the same relation as it was decomposed.
o The relation is said to be lossless decomposition if natural joins of all the decomposition give the original relation.

Example:
EMPLOYEE_DEPARTMENT table:

EMP_ID EMP_NAME EMP_AGE EMP_CITY DEPT_ID DEPT_NAME

22 Denim 28 Mumbai 827 Sales

33 Alina 25 Delhi 438 Marketing

46 Stephan 30 Bangalore 869 Finance

52 Katherine 36 Mumbai 575 Production

60 Jack 40 Noida 678 Testing

The above relation is decomposed into two relations EMPLOYEE and DEPARTMENT
EMPLOYEE table:

EMP_ID EMP_NAME EMP_AGE EMP_CITY

22 Denim 28 Mumbai

33 Alina 25 Delhi

46 Stephan 30 Bangalore

52 Katherine 36 Mumbai

60 Jack 40 Noida

Department of Computer Science and Engineering Dhanalakshmi Srinivasan College of Engineering

Downloaded by sneha sivalingam ([email protected])
 lOMoARcPSD|22191715

IV- SEM/II B.E. CSE (CS) Prepared By: R. Reshma/AP/CSE

DEPARTMENT table

DEPT_ID EMP_ID DEPT_NAME

827 22 Sales

438 33 Marketing

869 46 Finance

575 52 Production

678 60 Testing

Now, when these two relations are joined on the common column "EMP_ID", then the resultant relation will look like:
Employee ⋈ Department

EMP_ID EMP_NAME EMP_AGE EMP_CITY DEPT_ID DEPT_NAME

22 Denim 28 Mumbai 827 Sales

33 Alina 25 Delhi 438 Marketing

46 Stephan 30 Bangalore 869 Finance

52 Katherine 36 Mumbai 575 Production

60 Jack 40 Noida 678 Testing

Hence, the decomposition is Lossless join decomposition.

Dependency Preserving
o It is an important constraint of the database.
o In dependency preservation, at least one decomposed table must satisfy every dependency.
o If a relation R is decomposed into relation R1 and R2, then the dependencies of R either must be a part of R1 or R2
or must be derivable from the combination of functional dependencies of R1 and R2.
o For example, suppose there is a relation R (A, B, C, D) with a functional dependency set (A->BC). The relational
R is decomposed into R1(ABC) and R2(AD) which is dependency preserving because FD A->BC is a part of
relation R1(ABC).
Multivalued Dependency
o Multivalued dependency occurs when two attributes in a table are independent of each other but, both depend on a
third attribute.
o A multivalued dependency consists of at least two attributes that are dependent on a third attribute that's why it
always requires at least three attributes.
Example: Suppose there is a bike manufacturer company which produces two colors(white and black) of each model every
year.

Department of Computer Science and Engineering Dhanalakshmi Srinivasan College of Engineering

Downloaded by sneha sivalingam ([email protected])
 lOMoARcPSD|22191715

IV- SEM/II B.E. CSE (CS) Prepared By: R. Reshma/AP/CSE

BIKE_MODEL MANUF_YEAR COLOR

M2011 2008 White

M2001 2008 Black

M3001 2013 White

M3001 2013 Black

M4006 2017 White

M4006 2017 Black

Here columns COLOR and MANUF_YEAR are dependent on BIKE_MODEL and independent of each other.
In this case, these two columns can be called as multivalued dependent on BIKE_MODEL. The representation of these
dependencies is shown below:
1. BIKE_MODEL → → MANUF_YEAR
2. BIKE_MODEL → → COLOR
This can be read as "BIKE_MODEL multidetermined MANUF_YEAR" and "BIKE_MODEL multidetermined COLOR".

Join Dependency
o Join decomposition is a further generalization of Multivalued dependencies.
o If the join of R1 and R2 over C is equal to relation R, then we can say that a join dependency (JD) exists.
o Where R1 and R2 are the decompositions R1(A, B, C) and R2(C, D) of a given relations R (A, B, C, D).
o Alternatively, R1 and R2 are a lossless decomposition of R.
o A JD ⋈ {R1, R2,..., Rn} is said to hold over a relation R if R1, R2,....., Rn is a lossless-join decomposition.
o 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.
o Here, *(R1, R2, R3) is used to indicate that relation R1, R2, R3 and so on are a JD of R.

Inclusion Dependency
o Multivalued dependency and join dependency can be used to guide database design although they both are less
common than functional dependencies.
o Inclusion dependencies are quite common. They typically show little influence on designing of the database.
o The inclusion dependency is a statement in which some columns of a relation are contained in other columns.
o The example of inclusion dependency is a foreign key. In one relation, the referring relation is contained in the
primary key column(s) of the referenced relation.
o Suppose we have two relations R and S which was obtained by translating two entity sets such that every R entity
is also an S entity.

Department of Computer Science and Engineering Dhanalakshmi Srinivasan College of Engineering

Downloaded by sneha sivalingam ([email protected])
 lOMoARcPSD|22191715

IV- SEM/II B.E. CSE (CS) Prepared By: R. Reshma/AP/CSE

o Inclusion dependency would be happen if projecting R on its key attributes yields a relation that is contained in the
relation obtained by projecting S on its key attributes.
o In inclusion dependency, we should not split groups of attributes that participate in an inclusion dependency.
o In practice, most inclusion dependencies are key-based that is involved only keys.

*************

Department of Computer Science and Engineering Dhanalakshmi Srinivasan College of Engineering

Downloaded by sneha sivalingam ([email protected])