DBMS unit-2.pdf

Database Management System
Part-2
Dr. K ADISESHA

Introduction
E-R model Components
E-R diagram
Relation Algebra
Relational Keys
2
Entity-Relationship model
Prof. K. Adisesha
Prof. K. Adisesha

Introduction
Prof. K. Adisesha
3
Data Models in DBMS:
Data modeling (data modelling) is the process of creating a data model for the data to
be stored in a database.
➢ The Data Model is defined as an abstract model that organizes data description, data
semantics, and consistency constraints of data.
➢ Data Model is like an architect’s building plan, which helps to build conceptual models
and set a relationship between data items.
➢ The two types of Data Modeling Techniques are
❖ Entity Relationship (E-R) Model
❖ UML (Unified Modelling Language)

Introduction
Prof. K. Adisesha
4
Types of Data Models in DBMS:
The data models are used to represent the data and how it is stored in the database and
to set the relationship between data items.
➢ There are mainly three different types of data models:
❖ Conceptual data models
❖ Logical data models
❖ Physical data models

Introduction
Prof. K. Adisesha
5
Types of Data Models in DBMS:
The data models are used to represent the data and how it is stored in the database and
to set the relationship between data items.
➢ Conceptual Data Model: This Data Model defines WHAT the system contains. This model is
typically created by Business stakeholders and Data Architects. The purpose is to organize,
scope and define business concepts and rules.
➢ Logical Data Model: Defines HOW the system should be implemented regardless of the
DBMS. This model is typically created by Data Architects and Business Analysts. The purpose
is to developed technical map of rules and data structures.
➢ Physical Data Model: This Data Model describes HOW the system will be implemented using
a specific DBMS system. This model is typically created by DBA and developers. The purpose
is actual implementation of the database.

Introduction
Prof. K. Adisesha
6
Conceptual Data Model:
A Conceptual Data Model is an organized view of database concepts and their
relationships. The purpose of creating a conceptual data model is to establish entities,
their attributes, and relationships.
➢ In this data modeling level, there is hardly any detail available on the actual database
structure. Business stakeholders and data architects typically create a conceptual data
model.
➢ The 3 basic tenants of Conceptual Data Model are
❖ Entity: A real-world thing
❖ Attribute: Characteristics or properties of an entity
❖ Relationship: Dependency or association between two entities

Introduction
Prof. K. Adisesha
7
Logical Data Model:
The Logical Data Model is used to define the structure of data elements and to set
relationships between them. The logical data model adds further information to the
conceptual data model elements.
➢ At this Data modeling level, you need to verify and adjust the connector details that were
set earlier for relationships.
➢ At this Data Modeling level, no primary or secondary key is defined.

Introduction
Prof. K. Adisesha
8
Physical Data Model:
A Physical Data Model describes a database-specific implementation of the data model. It
offers database abstraction and helps generate the schema.
➢ This is because of the richness of meta-data offered by a Physical Data Model.
➢ The physical data model also helps in visualizing database structure by replicating
database column keys, constraints, indexes, triggers, and other RDBMS features.

ROLL_NO NAME ADDRESS PHONE AGE
1 SUNNY BANGALORE 9449081542 18
Introduction
Prof. K. Adisesha
9
Relational Model:
Relational Model represents how data is stored in Relational Databases. A relational
database stores data in the form of relations (tables).
➢ Relational Model was proposed by E.F. Codd to model data in the form of relations or
tables.
➢ After designing the conceptual model of Database using ER diagram, we need to
convert the conceptual model in the relational model which can be implemented using
any RDBMS languages like Oracle SQL, MySQL etc,.
➢ Consider a relation STUDENT with attributes ROLL_NO, NAME, ADDRESS, PHONE
and AGE represented as table.

Introduction
Prof. K. Adisesha
10
ER model:
ER model stands for an Entity-Relationship model. It is a high-level data model.
➢ This model is used to define the data elements and relationship for a specified system.
➢ It develops a conceptual design for the database. It also develops a very simple and
easy to design view of data.
➢ In ER modeling, the database structure is portrayed as a diagram called an entity-
relationship diagram.
➢Example, Suppose we design a school database. In
this database, the student will be an entity with
attributes like address, name, id, age, etc.

E-R diagram
Prof. K. Adisesha
11
Components of E-R model:
ER-Diagram is a visual representation of data that describes how data is related to each
other.
➢ Entity
➢ Attribute
➢ Relationship

E-R diagram
Prof. K. Adisesha
12
Components of E-R model:
other.
Entity:
✓ An Entity can be any object, place, person or class.
Attribute:
✓ An Attribute describes a property or characteristic of an entity.
✓ Example: Roll_No, Name and Birth date can be attributes of a student
Relationship:
✓ A relationship type is a meaningful association between entity types.
✓ Relationship types are represented on the E-R diagram by a series of lines.

E-R diagram
Prof. K. Adisesha
13
Different notations of E-R diagram:
other.
➢ Different notations of E-R diagram:
❖ Entity: An entity is represented using rectangles.
❖ Attribute: Attributes are represented by means of eclipses.
❖ Relationship: Relationship is represented using diamonds shaped box.

E-R diagram
Prof. K. Adisesha
14
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.
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.

E-R diagram
Prof. K. Adisesha
15
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.
➢ Different types of Attributes are:
❖ Key Attribute
❖ Composite Attribute
❖ Multivalued Attribute
❖ Derived Attribute

E-R diagram
Prof. K. Adisesha
16
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.
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.

E-R diagram
Prof. K. Adisesha
17
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.
➢ For example, a student can have more than one phone number.
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.

E-R diagram
Prof. K. Adisesha
18
Relationship:
A Relationship describes relations between entities. Relationship is represented using
diamonds shaped box.
➢ There are three types of relationship that exist between entities:
❖ Binary Relationship
❖ Recursive Relationship
❖ Ternary Relationship

E-R diagram
Prof. K. Adisesha
19
Binary Relationship:
It means relation between two entities.
➢ This is further divided into three types.
❖ One to One
❖ One to Many
❖ Many to Many
➢ One to One:
✓ This type of relationship is rarely seen in real world.
✓ The above example describes that one student can enroll only for one course and a
course will have only one Student. This is not what you will usually see in relationship.

E-R diagram
Prof. K. Adisesha
20
Binary Relationship:
➢ One to Many:
✓ It reflects business rule that one entity is associated with many number of same
entity.
✓ For example, Student enrolls for only one Course but a Course can have many
Students.
➢ Many to Many:
✓ It reflects business rule that many entity are associated with many number of same
entity.
✓ The above diagram represents that many students can enroll for more than one
course.

E-R diagram
Prof. K. Adisesha
21
Database can be represented using the notations. In ER diagram, many notations are
used to express the cardinality.
➢ These notations are as follows:

E-R diagram
Prof. K. Adisesha
22
Recursive relationship:
A relationship between two entities of a similar entity type is called a recursive
relationship.
➢ Here the same entity type participates more than once in a relationship type with a
different role for each instance.
➢ The person who is a supervisor for many other
employees also come under employees category
➢ Student can be a class monitor and handle other
students but a person who is working as a class leader
is itself a student of the class and hence a class
monitor has a recursive relationship of entity student

E-R diagram
Prof. K. Adisesha
23
Ternary relationship:
When there are exactly three entity sets participating in a relationship then such type of
relationship is called ternary relationship.
➢ n the real world, a patient goes to a doctor and doctor prescribes the medicine to the
patient, three entities Doctor, patient and medicine are involved in the relationship
“prescribes”.

Relational Keys
Prof. K. Adisesha
24
Keys used in database:
Keys play an important role in the relational database. It is used to uniquely identify any
record or row of data from the table.
➢ It is also used to establish and identify relationships between tables.
➢ Types of keys:

Relational Keys
Prof. K. Adisesha
25
Different Types Of Keys In Database:
There are mainly 7 types of Keys, that can be considered in a database.
➢ Candidate Key – A set of attributes which can uniquely identify a table can be termed as a
Candidate Key.
➢ Super Key – The set of attributes which can uniquely identify a tuple is known as Super Key.
➢ Primary Key – A set of attributes which are used to uniquely identify every tuple is also a primary key.
➢ Alternate Key – Alternate Keys are the candidate keys, which are not chosen as a Primary key.
➢ Unique Key – The unique key is similar to the primary key, but allows one NULL value in the
column.
➢ Foreign Key – An attribute that can only take the values present as the values of some other
attribute, is the foreign key to the attribute to which it refers.
➢ Composite Key – A composite key is a combination of two or more columns that identify each tuple
uniquely.

Relational Keys
Prof. K. Adisesha
26
➢ Primary key:
✓ It is a field in a table which uniquely identifies each row/record in a database table.
Primary keys must contain unique values.
✓ A primary key column cannot have NULL values.
✓ Ex: In the EMPLOYEE table, ID can be the primary key since it is unique for each
employee.
1.CREATE TABLE SAMPLE_TABLE
2.(COL1 integer,
3.COL2 nvarchar(30),
5.PRIMARY KEY (COL1));

Relational Keys
Prof. K. Adisesha
27
➢ Candidate Key:
✓ When more than one or group of attributes serve as a unique identifier, they are
each called as candidate key.
✓ In the EMPLOYEE table, id is best suited for the primary key. The rest of the
attributes, like SSN, Passport_Number, License_Number, etc., are considered a
candidate key.

Relational Keys
Prof. K. Adisesha
28
➢ Super Key:
✓ Super key is an attribute set that can uniquely identify a tuple. A super key is a
superset of a candidate key.
✓ In the EMPLOYEE table, for(EMPLOEE_ID, EMPLOYEE_NAME), the name of
two employees can be the same, but their EMPLYEE_ID can't be the same. Hence,
this combination can also be a key.

Relational Keys
Prof. K. Adisesha
29
➢ Alternate Key:
✓ The alternate key of any table are those candidate keys, which are not currently
selected as the primary key. This is also known as secondary key.
✓ example, employee relation has two attributes, Employee_Id and PAN_No, that act
as candidate keys. In this relation, Employee_Id is chosen as the primary key, so the
other candidate key, PAN_No, acts as the Alternate key.

Relational Keys
Prof. K. Adisesha
30
➢ Foreign key:
✓ A key used to link two tables together is called a foreign key, also called as
referencing key.
✓ Foreign key is a field that matches the primary key column of another table.
✓ In the EMPLOYEE table, Department_Id is the foreign key, and both the tables are
related. CREATE TABLE Employee
( Emp_Id int NOT NULL PRIMAY KEY,
EName Varchar(255) NOT NULL,
P_No int NOT NULL,
Dept_Id int FOREIGN KEY REFERENCES
Department(Dept_Id)
)

Relational Keys
Prof. K. Adisesha
31
➢ Composite key:
✓ Whenever a primary key consists of more than one attribute, it is known as a
composite key. This key is also known as Concatenated Key.
✓ in employee table, an employee may be assigned multiple roles, and an employee
may work on multiple projects simultaneously. So the primary key will be
composed of all three attributes, namely Emp_ID, Emp_role, and Proj_ID in
combination. Syntax:
1.CREATE TABLE SAMPLE_TABLE
2.(COL1 integer,
5.PRIMARY KEY (COL1, COL2));

Relational Keys
Prof. K. Adisesha
32
Relational Keys

Integrity Constraints
Prof. K. Adisesha
33
Integrity Constraints:
Integrity constraints are pre-defined set of rules that are applied on the table
fields(columns) or relations to ensure that the overall validity, integrity, and consistency
of the data present in the database table is maintained.
➢ It is used to maintain the quality of information.
➢ It ensures that the data insertion, updating, and other processes have to be performed in
such a way that data integrity is not affected.
➢ Types of integrity constraints in relational data model:
❖ Domain Constraint
❖ Entity Constraint
❖ Referential Integrity Constraint
❖ Key Constraint

Prof. K. Adisesha
34
Constraints Used In Database:
Constraints are used in a database to specify the rules for data in a table. The following are
the different types of constraints:
➢ NOT NULL: This constraint ensures that a column cannot have a NULL value.
➢ UNIQUE: This constraint ensures that all the values in a column are unique.
➢ CHECK: This constraint ensures that all the values in a column satisfy a specific condition.
➢ DEFAULT: This constraint consists of a set of default values for a column when no value is
specified
➢ INDEX: This constraint is used to create indexes in the table, through which you can create and
retrieve data from the database very quickly.

Prof. K. Adisesha
35
Integrity Constraints Types:
Domain integrity constraint :
➢ Domain constraints can be defined as a valid set of values for an attribute.
➢ The data type of domain includes string, character, integer, time, date, currency, etc.
The value of the attribute must be available in the corresponding domain.
ID NAME SEMESTER AGE
10001 PRAJWAL 2 19
10002 SUNNY 1 18
10003 SHAILU 3 A

Prof. K. Adisesha
36
Entity integrity constraints:
➢ The entity integrity constraint states that primary key value can't be null.
➢ This is because the primary key value is used to identify individual rows in relation and
if the primary key has a null value, then we can't identify those rows.
➢ A table can contain a null value other than the primary key field.
10001 PRAJWAL 2 19
10002 SUNNY 1 18
SHAILU 3 20

Prof. K. Adisesha
37
Referential Integrity Constraints: A referential integrity constraint is specified between
two tables.
➢ In the Referential integrity constraints, if a foreign key in Table 1 refers to the Primary
Key of Table 2, then every value of the Foreign Key in Table 1 must be null or be
available in Table 2.

Prof. K. Adisesha
38
Key constraints: Keys are the entity set that is used to identify an entity within its entity
set uniquely.
➢ An entity set can have multiple keys, but out of which one key will be the primary key.
A primary key can contain a unique and null value in the relational table..
10001 PRAJWAL 2 19
10002 SUNNY 1 18
10002 SHAILU 3 20

Generalization
Prof. K. Adisesha
39
Generalization:
Generalization is a bottom-up approach in which two lower level entities combine to
form a higher level entity.
➢ In generalization, a number of entities are brought together into one generalized entity
based on their similar characteristics.
➢ For example, Student and Parent details can all be generalized as a group ‘Person’ as
Personal details.

Specialization
Prof. K. Adisesha
40
Specialization:
Specialization is a Top-down approach in which one higher level entity can be broken
down into two lower level entities.
➢ Specialization is the opposite of generalization.
➢ In specialization, a group of entities is divided into sub-groups based on their
characteristics.
➢ Consider an entity employee which can be
further classified as sub-entities Technician,
Engineer & Accountant because these sub
entities have some distinguish attributes.

Aggregation
Prof. K. Adisesha
41
Aggregation:
In aggregation, the relation between two entities is treated as a single entity. In
aggregation, relationship with its corresponding entities is aggregated into a higher level
entity.
➢ Center entity offers the Course entity act as a single entity in the relationship which is in
a relationship with another entity visitor. If a visitor visits a coaching center then he will
enquiry about both Course and Center.

Aggregation
Prof. K. Adisesha
42
Aggregate function:
Aggregate functions in DBMS take multiple rows from the table and return a value
according to the query.
➢ Common aggregate functions include:
❖ Average (i.e., arithmetic mean)
❖ Count
❖ Maximum
❖ Median
❖ Minimum
❖ Mode
❖ Range
❖ Sum

ER diagram
Prof. K. Adisesha
43
ER diagram Design:
The database can be represented using the notations, and these notations can be reduced
to a collection of tables.

ER diagram
Prof. K. Adisesha
44
Case Study:
Sunny Travels: It is in Travel business since 2000 with several buses connecting different
places in India. Its main office is located in Bangalore. The company wants to computerize
its operations in the following areas:
❖ Reservations and Ticketing
❖ Cancellations
➢ Reservations &Cancellation: Reservations are directly handled by booking office.
Reservations can be made 30 days in advance and tickets issued to passenger. One
Passenger/person can book many tickets (to his/her family).
➢ Cancellations are also directly handed at the booking office. In the process of computerization of
Roadway Travels you have to design and develop a Database which consists the data of Buses,
Passengers, Tickets, and Reservation and cancellation details. You should also develop query's
using SQL to retrieve the data from the database.

ER diagram
Prof. K. Adisesha
45
Case Study:
AIM: Analyze the problem and come with the entities in it. Identify what Data has to be
persisted in the databases.
The Following are the entities:
1.Bus
2. Reservation
3. Ticket
4. Passenger
5. Cancellation

ER diagram
Prof. K. Adisesha
46
Case Study: ER Diagram
The Following are the entities:
❖ Bus
❖ Reservation
❖ Ticket
❖ Passenger
❖ Cancellation

ER diagram
Prof. K. Adisesha
47
Reduction of ER diagram to Table:
Table structure for the given ER diagram is as below:

ER diagram
Prof. K. Adisesha
48
Steps to convert Table structure from the given ER diagram is as below:
➢ Entity type becomes a table.
❖ In the given ER diagram, LECTURE, STUDENT, SUBJECT and COURSE forms
individual tables.
➢ All single-valued attribute becomes a column for the table.
❖ In the STUDENT entity, STUDENT_NAME and STUDENT_ID form the column of
STUDENT table. Similarly, COURSE_NAME and COURSE_ID form the column of
COURSE table and so on.
➢ A key attribute of the entity type represented by the primary key.
❖ In the given ER diagram, COURSE_ID, STUDENT_ID, SUBJECT_ID, and LECTURE_ID
are the key attribute of the entity.

ER diagram
Prof. K. Adisesha
49
Steps to convert Table structure from the given ER diagram is as below:
➢ The multivalued attribute is represented by a separate table.
❖ In the student table, a hobby is a multivalued attribute. So it is not possible to represent
multiple values in a single column of STUDENT table. Hence we create a table
STUD_HOBBY with column name STUDENT_ID and HOBBY. Using both the column, we
create a composite key.
➢ Composite attribute represented by components.
❖ In the given ER diagram, student address is a composite attribute. It contains CITY, PIN, DOOR#,
STREET, and STATE. In the STUDENT table, these attributes can merge as an individual column.
➢ Derived attributes are not considered in the table.
❖ In the STUDENT table, Age is the derived attribute. It can be calculated at any point of time by
calculating the difference between current date and Date of Birth.

Relation Algebra
Prof. K. Adisesha
50
Relation Algebra:
Relational algebra is a procedural query language. It gives a step by step process to
obtain the result of the query. It uses operators to perform queries.
➢ Types of Relational operation:
❖ Select Operation
❖ Project Operation
❖ Union Operation
❖ Set Different Operation
❖ Cartesian Product Operation
❖ Rename Operation

Relation Algebra
Prof. K. Adisesha
51
Relation Algebra:
Relational algebra is a procedural query language that consists of a set of operations
that take one or more relations as input and result into a new relation as an output.
➢ The relational algebraic operations can be divided into:
❖ Basic set-oriented operations:
✓ Union, Set different, Cartesian product
❖ Relational-oriented operations:
✓ Selection, Projection, Division, Joins

Relation Algebra
Prof. K. Adisesha
52
Relation Algebra:
Select Operation: The select operation selects tuples that satisfy a given predicate.
➢ It is denoted by sigma (σ).
❖ Notation: σ p(r)
➢ Where:
❖ σ is used for selection prediction
❖ r is used for relation
❖ p is used as a propositional logic formula which may use connectors like: AND OR and
NOT. These relational can use as relational operators like =, ≠, ≥, <, >, ≤.
➢ Example:
❖ σsubject = “Books” and cost = “150” or year > “2021”(DBMS)
➢ The output: Selecting tuples from the Text_Books wherever the subject happens to be ‘Books’ and the
‘Cost’is 150 or those DBMS have been published after 2021.

Relation Algebra
Prof. K. Adisesha
53
Relation Algebra:
Project Operation (or ∏): This operation shows the list of those attributes that we wish to
appear in the result. Rest of the attributes are eliminated from the table.
➢ It is denoted by ∏.
❖ Notation: ∏ A1, A2,.., An (r)
➢ Where:
❖ A1, A2, A3 is used as an attribute name of relation r.
➢ Example:
❖ ∏subject, writer (Text_books)
➢ The output: Selecting and projecting columns named as writer as well as the subject from the relation
Text_Books.

Relation Algebra
Prof. K. Adisesha
54
Relation Algebra:
Union Operation (∪ ): Suppose there are two tuples R and S. The union operation
contains all the tuples that are either in R or S or both in R & S.
➢ It eliminates the duplicate tuples. It is denoted by ∪.
❖ Notation: R ∪ S R
➢ Where: S
❖ R and S must have the attribute of the same number.
❖ Duplicate tuples are eliminated automatically.
➢ Example: Using the above DEPOSITOR table and BORROW table
❖ ∏ CUSTOMER_NAME (BORROW) ∪ ∏ CUSTOMER_NAME (DEPOSITOR)
➢ The output: Selecting and projecting columns named as Customer_Name from the relations Borrow &
Depositors.
CUSTOMER_NAME ACCOUNT_NO
CUSTOMER_NAME LOAN_NO
CUSTOMER_NAME

Relation Algebra
Prof. K. Adisesha
55
Relation Algebra:
Intersection Operation (∩): Suppose there are two tuples R and S. The set intersection
operation contains all tuples that are in both R & S.
➢ It is denoted by intersection ∩.
❖ Notation: R ∩ S
➢ Where:
❖ All tuples that are in both R & S selected automatically.
➢ Example: Using the above DEPOSITOR table and BORROW table.
❖ ∏ CUSTOMER_NAME (BORROW) ∩ ∏ CUSTOMER_NAME (DEPOSITOR)
➢ The output: Selecting and projecting columns named as Customer_Name from the relations present in
only in Borrow & Depositors.
CUSTOMER_NAME ACCOUNT_NO
CUSTOMER_NAME LOAN_NO
CUSTOMER_NAME

Relation Algebra
Prof. K. Adisesha
56
Relation Algebra:
Cartesian product (X): The Cartesian product is used to combine each row in one table
with each row in the other table. It is also known as a cross product.
➢ It is denoted by X.
❖ Notation: R X S
➢ Where:
❖ All tuples that are in both R & S selected automatically.
➢ Example: Using the above DEPOSITOR table and BORROW table.
❖ EMPLOYEE X DEPARTMENT
➢ The output: Selecting and projecting all columns named from the relations present in EMPLOYEE &
DEPARTMENT EMP_ID EMP_NAME EMP_DEPT DEPT_NO DEPT_NAME

Relation Algebra
Prof. K. Adisesha
57
Joins (⋈):
Joins in Database Management System are used in relational algebra and SQL to
join/combine more than one table to get some specific results out of those tables.
➢ A Join operation combines related tuples from different relations, if and only if a given
join condition is satisfied. It is denoted by ⋈.
➢ Different types of the JOINs in SQL:
❖ (INNER) JOIN
❖ LEFT (OUTER) JOIN
❖ RIGHT (OUTER) JOIN
❖ FULL (OUTER) JOIN

Relation Algebra
Prof. K. Adisesha
58
Joins:
Joins in Database Management System are used in relational algebra and SQL to
join/combine more than one table to get some specific results out of those tables.
➢ Different types of the JOINs in SQL:
❖ (INNER) JOIN: Returns records that have matching values in both tables
❖ LEFT (OUTER) JOIN: Returns all records from the left table, and the matched records from
the right table
❖ RIGHT (OUTER) JOIN: Returns all records from the right table, and the matched records
from the left table
❖ FULL (OUTER) JOIN: Returns all records when there is a match in either left or right table

Normalization
Prof. K. Adisesha
59
Normalization:
A large database defined as a single relation may result in data duplication. This
repetition of data may result in:
❖ Making relations very large.
❖ It isn't easy to maintain and update data as it would involve searching many records
in relation.
❖ Wastage and poor utilization of disk space and resources.
❖ 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
Prof. K. Adisesha
60
Normalization:
Normalization is a process of decomposing the relations into relations with fewer
attributes.
➢ Normalization is the process of organizing the data in the database.
➢ 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.
➢ Normalization divides the larger table into smaller and links them using relationships.
➢ The normal form is used to reduce redundancy from the database table.

Normalization
Prof. K. Adisesha
61
Normalization:
The main reason for normalizing the relations is removing these anomalies.
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:
❖ Insertion Anomaly: Insertion Anomaly refers to when one cannot insert a new tuple
into a relationship due to lack of data.
❖ Deletion Anomaly: The delete anomaly refers to the situation where the deletion of
data results in the unintended loss of some other important data.
❖ Updatation Anomaly: The update anomaly is when an update of a single data value
requires multiple rows of data to be updated.

Normalization
Prof. K. Adisesha
62
Normalization:
Normalization is a step by step process of removing the different kinds of redundancy
and anomaly one step at a time from the database.
➢ E.F Codd developed for the relation data model in 1970.
➢ Normalization rules are divided into following normal form:

Normalization
Prof. K. Adisesha
63
Normalization:
Normalization is a step by step process of removing the different kinds of redundancy
and anomaly one step at a time from the database.

Normalization
Prof. K. Adisesha
64
1st Normal Form (1NF):
By applying the First Normal Form, you achieve atomicity, and also every column has
unique values.
➢ A table is referred to as being in its First Normal Form if atomicity of the table is 1.
➢ Here, atomicity states that a single cell cannot hold multiple values. It must hold only a
single-valued attribute.
➢ The First normal form disallows the multi-valued attribute, composite attribute, and
their combinations.
First normal form

Normalization
Prof. K. Adisesha
65
Second Normal Form (2NF):
The first condition for the table to be in Second Normal Form is that the table has to be
in First Normal Form. The table should not possess partial dependency.
➢ The partial dependency here means the proper subset of the candidate key should give a
non-prime attribute.
➢ To bring the table to Second Normal Form, you need to split the table-1 into two parts.
This will give you the below tables:
Second normal form

Normalization
Prof. K. Adisesha
66
Third Normal Form (3NF):
The third Normal Form ensures the reduction of data duplication. It is also used to
achieve data integrity.
➢ The first condition for the table to be in Third Normal Form is that the table should be
in the Second Normal Form.
➢ The second condition is that there should be no transitive dependency for non-prime
attributes, which indicates that non-prime attributes (which are not a part of the
candidate key) should not depend on other non-prime attributes in a table. Therefore, a
transitive dependency is a functional dependency in which A → C (A determines C)
indirectly, because of A → B and B → C (where it is not the case that B → A).:

Normalization
Prof. K. Adisesha
67
Third Normal Form (3NF):
The third Normal Form ensures the reduction of data duplication. It is also used to
achieve data integrity.
➢ Below is a student table that has student id, student name, subject id, subject name, and
address of the student as its columns.
➢ Now to change the table to the third normal form, you need to divide the table as shown
below:
Third normal form

Normalization
Prof. K. Adisesha
68
Boyce CoddNormal Form (BCNF):
Boyce Codd Normal Form is also known as 3.5 NF. It is the superior version of 3NF and
was developed by Raymond F. Boyce and Edgar F. Codd to tackle certain types of
anomalies which were not resolved with 3NF.
➢ The first condition for the table to be in Boyce Codd Normal Form is that the table
should be in the third normal form.
➢ Secondly, every Right-Hand Side (RHS) attribute of the functional dependencies should
depend on the super key of that particular table.
➢ For example : You have a functional dependency X → Y.
In the particular functional dependency, X has to be the
part of the super key of the provided table.

Normalization
Prof. K. Adisesha
69
Boyce Codd Normal Form (BCNF):
The subject table follows these conditions:
❖ Each student can enroll in multiple subjects.
❖ Multiple professors can teach a particular subject.
❖ For each subject, it assigns a professor to the student.
➢ In the above table, student_id and subject together form the primary key because using
student_id and subject; you can determine all the table columns.
➢ However, there exists yet another dependency - professor → subject.
BCNF normal form

Normalization
Prof. K. Adisesha
70
Fourth normal form (4NF):
If no database table instance contains two or more, independent and multivalued data
describing the relevant entity, then it is in 4th Normal Form.
➢ A relation will be in 4NF if it is in Boyce Codd normal form and has no multi-valued
dependency.
➢ 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.
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.

Normalization
Prof. K. Adisesha
71
Fourth normal form (4NF):
If no database table instance contains two or more, independent and multivalued data
describing the relevant entity, then it is in 4th Normal Form.
➢ 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:.
4NF normal form

Normalization
Prof. K. Adisesha
72
Fifth normal form (5NF):
A table is in 5th Normal Form only if it is in 4NF and it cannot be decomposed into any
number of smaller tables without loss of data.
➢ A relation is in 5NF if it is in 4NF and not contains any join dependency and joining
should be lossless.
➢ 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).
➢ In the 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.

Normalization
Prof. K. Adisesha
73
Fifth normal form (5NF):
A table is in 5th Normal Form only if it is in 4NF and it cannot be decomposed into any
number of smaller tables without loss of data.
➢ 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:

Questions
Important Questions:
➢ Define the following database terms:
a. Data Model b. Tuple c. Domain d. Primary key e. Foreign key
➢ Write the difference between manual and electronic data processing.
➢ Explain any five applications of database.
➢ Briefly explain the data processing cycle.
➢ Write the difference between Hierarchical data model and network data model.
➢ What is normalization? Explain second normal form with an example.
➢ What is database model? Explain Hierarchical model.
➢ Explain 3-level DBMS architecture.
➢ .
Prof. K. Adisesha
74

Discussion
Prof. K. Adisesha (Ph. D)
75
Queries ?
Prof. K. Adisesha
9449081542

DBMS unit-2.pdf

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to DBMS unit-2.pdf

Similar to DBMS unit-2.pdf (20)

More from Prof. Dr. K. Adisesha

More from Prof. Dr. K. Adisesha (20)

Recently uploaded

Recently uploaded (20)

DBMS unit-2.pdf